There has been a lack of a unified definition of software engineering, and many scholars and organizations have given their own definitions: software engineering (1) and BarryBoehm: using modern scientific and technological knowledge to design and construct computer programs and related documents necessary for developing, running and maintaining these programs. (2) The definition of IEEE in Glossary of Software Engineering Terms: software engineering is: 1. Apply systematic, strictly constrained and quantifiable methods to software development and operation and maintenance, that is, apply engineering to software; 2. Study the methods described in 1 (3), and the definition given by FritzBauer at the NATO conference: a series of methods to establish and use perfect engineering principles and obtain reliable software that can run effectively on actual machines by economic means. At present, an accepted definition holds that software engineering is the research and application of how to develop and maintain software by systematic, standardized and quantitative process methods, and how to combine the correct management technology that has stood the test of time with the best available technical methods. (4) Definition in Encyclopedia of Computer Science and Technology: Software engineering is a software development project based on the application principles of computer science, mathematics and management science. Software engineering uses the principles and methods of traditional engineering for reference to improve quality and reduce cost. Among them, computer science and mathematics are used to establish models and algorithms, engineering science is used to formulate specifications, design paradigms, evaluate costs and determine trade-offs, and management science is used to manage plans, resources, quality and costs.

[Edit this paragraph] target

The goal of software engineering is to develop software products with modifiability, effectiveness, reliability, understandability, maintainability, reusability, adaptability, portability, traceability and interoperability under the premise of given cost and schedule, and to meet the needs of users. Pursuing these goals will help to improve the quality and development efficiency of software products and reduce the difficulty of maintenance. These concepts are introduced below. (1) variability. It is allowed to modify the system without increasing the complexity of the original system. It supports software debugging and maintenance, which is an unattainable goal. (2) efficiency. Software system can make the most effective use of the time and space resources of the computer. All kinds of computer software take the time/space cost of the system as an important technical index to measure the software quality. On many occasions, the pursuit of time effectiveness and space effectiveness will be contradictory. At this time, we have to sacrifice time efficiency for space efficiency, or sacrifice space efficiency for time efficiency. Time/space tradeoffs often occur. Experienced software designers will skillfully use the concept of compromise to realize users' needs and their own designs in a specific physical environment. (3) Reliability. It can prevent software system failures caused by imperfect concept, design and structure, and has the ability to recover software system failures caused by improper operation. For real-time embedded computer systems, reliability is a very important goal. Because software should control a physical process in real time, such as the navigation of spacecraft, the operation of nuclear power plants and so on. If the reliability is not guaranteed, once there is a problem, it may be disastrous and the consequences will be unimaginable. Therefore, in the process of software development, coding and testing, reliability must be placed in an important position. (4) Understandability. The system has a clear structure and can directly reflect the needs of the problem. Understandability is helpful to control the complexity of software system and support the maintenance, transplantation or reuse of software. (5) maintainability. After the software product is delivered to users, it can be modified to correct potential errors, improve performance and other attributes, and make the software product adapt to changes in the environment, and so on. Because software is a logical product, it can be used indefinitely as long as users need it, so software maintenance is inevitable. Software maintenance costs account for a large proportion of software development costs. Maintainability is a very important goal in software engineering. The understandability and modifiability of software are beneficial to the maintainability of software. (6) reusability. Related modules or a group of modules with relatively independent concepts or functions are defined as software components. The degree to which soft components can be applied in various situations is called component reusability. Some reusable software can be used directly without modification, and some can be used only after modification. Reusable software components should have clear structure and comments, correct coding and low time/space overhead. Various reusable software components can also be stored in the software component library according to certain rules for software engineers to choose. Reusability is helpful to improve the quality and development efficiency of software products and reduce the cost of software development and maintenance. In a broader sense, the reusability of software engineering should also include the reuse of application projects, specifications (also known as specifications), designs, concepts and methods, and so on. Generally speaking, the higher the level of reuse, the greater the benefits. (7) adaptability. How easy it is for the software to meet the needs of users under different system constraints. Adaptable software should be written in popular programming languages, run in popular operating system environment, and write documents in standard terms and formats. Adaptable software is easier to popularize and use. (8) portability. The ease with which software can be transferred from one computer system or environment to another. In order to obtain high portability, software design usually adopts general programming language and running environment. Depending on the underlying (physical) characteristics of the computer system, such as the generation of the object code of the compilation system, it should be relatively independent and centralized. In this way, the processor-independent part can be transplanted to other systems for use. Portability supports the reusability and adaptability of software (9) Traceability. The ability to trace back software design and program according to software requirements, or the ability to trace back software requirements according to program and software design. Software traceability depends on the integrity, consistency and understandability of documents and procedures at all stages of software development. Reducing the complexity of the system will improve the traceability of the software. When there is a problem in the process of software testing or maintenance or program execution, all or part of the instructions in the program events or related modules should be recorded so as to analyze and track the causal relationship of the problem. (10) interoperability. The ability of multiple software elements to communicate with each other and cooperate to complete tasks. In order to achieve interoperability, software development usually follows certain standards, and an environment that supports compromise standards will promote interoperability among software elements. Interoperability is particularly important in distributed computing environment. Software engineering activities are "the steps needed to produce a software product that finally meets the requirements and achieves the engineering goals". It mainly includes requirements, design, implementation, confirmation, support and other activities. Demand activities include problem analysis and demand analysis. Problem analysis obtains the definition of requirements, also known as software requirements specification. Requirements analysis produces functional specifications. Design activities usually include overall design and detailed design. The outline design establishes the whole software architecture, including the description of subsystems, modules and related levels, as well as the interface definition of each module. Detailed design generates module descriptions available to programmers, including data structure descriptions and processing descriptions in each module. Implementation activities translate design results into executable program code. Confirmation activities run through the whole development process, realize the confirmation after completion, and ensure that the final product meets the requirements of users. Support activities include revision and improvement. Accompanied by the above activities, there are management processes, support processes, training processes and so on.

[Edit this paragraph] process

Steps required to produce software products that can finally meet the requirements and achieve the engineering goals. Software engineering process mainly includes development process, operation process and maintenance process. They cover activities such as requirements, design, implementation, verification and maintenance. Demand activities include problem analysis and demand analysis. Problem analysis obtains the definition of requirements, also known as software requirements specification. Requirements analysis produces functional specifications. Design activities usually include overall design and detailed design. The outline design establishes the whole software architecture, including the descriptions of subsystems, modules and related levels, as well as the interface definitions of each module. Detailed design generates module descriptions available to programmers, including data structure descriptions and processing descriptions in each module. Implementation activities translate design results into executable program code. Confirmation activities run through the whole development process, realize the confirmation after completion, and ensure that the final product meets the requirements of users. Maintenance activities include expansion, modification and improvement during use. Accompanied by the above processes, there are management processes, support processes, training processes and so on.

[Edit this paragraph] principle

The principle of software engineering refers to the principles that must be followed in the process of software development around engineering design, engineering support and engineering management. Software engineering principles include the following four basic principles of software engineers:

1) Select the appropriate development paradigm.

This principle is related to system design. In system design, software requirements, hardware requirements and other factors restrict and influence each other, and often need to be weighed. Therefore, we must understand the variability of requirements definition and adopt appropriate development paradigm to control it to ensure that software products meet the needs of users.

2) Adopt appropriate design methods.

In software design, the characteristics of modularization, abstraction, information concealment, localization, consistency and adaptability of software are usually considered. Appropriate design methods are helpful to realize these functions, thus achieving the goal of software engineering.

3) Provide high-quality engineering support.

Sharp tools make good work. In software engineering, software tools and environments that support software processes are very important. The quality and cost of software engineering projects directly depend on the quality and effectiveness of the support provided to software engineering.

4) Pay attention to the management of development process.

The management of software engineering directly affects the effective utilization of available resources, the production of software products that meet the objectives, and the improvement of the production capacity of software organizations. Therefore, only by effectively managing the software process can effective software engineering be realized. This software engineering framework tells us that the goal of software engineering is usability, correctness and cost-effectiveness; To implement a software project, it is necessary to choose an appropriate development paradigm, adopt an appropriate design method, provide high-quality engineering support, and effectively manage the development process; Software engineering activities mainly include requirements, design, implementation, confirmation and support, and each activity can adopt appropriate development paradigm, design method, supporting process and process management according to specific software engineering. According to the framework of software engineering, the research contents of software engineering discipline mainly include: software development paradigm, software development method, software process, software tools, software development environment, computer-aided software engineering (CASE) and software economics.

[Edit this paragraph] Basic principles

Since 1968 put forward the term "software engineering", experts and scholars who study software engineering have put forward more than 100 principles or creeds about software engineering. Barry Bohm, a famous American software engineering expert, synthesized the opinions of these experts and summarized TRW's experience in developing software for many years. In 1983, he put forward seven basic principles of software engineering. Bohm believes that these seven principles are the minimum set of principles to ensure the quality and development efficiency of software products. They are independent of each other and are an indispensable minimum set. At the same time, they are quite complete. Of course, people can't strictly prove that they are a complete set by mathematical methods, but it can be proved that more than 100 software engineering criteria that have been put forward before can contain or derive any combination of these seven principles. The following are seven principles of software engineering:

1, phased life cycle planning is strictly managed.

This paper is put forward on the basis of learning from predecessors. Statistics show that more than 50% of failed projects are caused by poor planning. In the long life cycle of software development and maintenance, many different kinds of work need to be completed. This principle is to divide the software life cycle into several stages, and make a feasible plan accordingly, and then manage the software development and maintenance in strict accordance with the plan. Bohm believes that six kinds of plans should be stipulated and strictly implemented in the whole software life cycle: project summary plan, milestone plan, project control plan, product control plan, verification plan and operation and maintenance plan.

2, adhere to the stage review.

Statistical results show that most errors are generated before coding, accounting for about 63%. The later you find an error, the greater the cost of correcting it, with a difference of 2 to 3 orders of magnitude. Therefore, the quality assurance of software can't wait until the end of coding, and we should adhere to strict stage review in order to find errors as soon as possible.

3. Implement strict product control.

One of the things that developers hate most is changing requirements. But practice tells us that changes in demand are often inevitable. This requires us to adopt scientific product control technology to meet this requirement. That is to say, change control, that is, benchmark configuration management, should be adopted. When the requirements change, the documents or codes in other stages also change to ensure the consistency of the software.

4. Adopt modern programming technology.

From the structured software development technology in the 1960s and 1970s to the recent object-oriented technology, and from the first and second generation languages to the fourth generation languages, people have fully realized that methods are as powerful as power. Adopting advanced technology can not only improve the efficiency of software development, but also reduce the cost of software maintenance.

5. The results should be clearly reviewed.

Software is an invisible and intangible logical product. The visibility of software development team's work progress is poor, and it is difficult to evaluate and manage. In order to better manage, the responsibilities of the development team and product standards should be clearly defined according to the overall goal and completion deadline of software development, so that the standards obtained can be clearly reviewed.

6. The staff of the development team should be few but fine.

The quality and quantity of developers are important factors that affect the quality and development efficiency of software, and should be few but good. This article is based on two reasons: the efficiency of high-quality developers is several times to dozens of times higher than that of low-quality developers, and the mistakes made in development work are much less; When the development team consists of n people, the possible communication channel is N(N- 1)/2, which shows that the communication cost will increase sharply with the increase of n people.

7, admit the necessity of continuous improvement of software engineering practice.

Following the above six basic principles can better realize the engineering production of software. However, they are only a summary and induction of existing experience, and cannot guarantee to catch up with the pace of continuous technological development. Therefore, Bohm proposed that the seventh principle of software engineering should be to recognize the necessity of continuous improvement in software engineering practice. According to this principle, we should not only actively adopt new software development technologies, but also pay attention to constantly summing up experience, collecting data such as progress and consumption, and counting error types and problems. These data can not only be used to evaluate the effect of new software technology, but also point out the problems that must be paid attention to and the tools and technologies that should be studied first.

[Edit this paragraph] method

The method of software engineering has many meanings. Including project management, analysis, design, programming, testing and quality control. Software engineers' software design methods can be divided into heavyweight method and lightweight way method. Heavyweight methods produce a large number of formal documents. Famous heavyweight development methods include RUP ISO9000, CMM and unified software development process. The lightweight development process does not require a large number of formal documents. Famous lightweight development methods include Extreme Programming (XP) and AgileProcesses. The article "New Methodology" holds that the heavyweight method presents a defensive posture. In software organizations that apply heavyweight methods, because software project managers don't participate or rarely participate in programming, they can't grasp the progress of the project in detail, so they will be afraid of the project and have to ask programmers to write many "software development documents" constantly. However, the lightweight approach presents an "offensive" attitude, which is embodied in the four principles that XP particularly emphasizes-"communication, simplicity, feedback and courage". At present, some people think that the heavyweight method is suitable for large software teams (more than dozens of people), while "lightweight way" is suitable for small software teams (several people, more than a dozen people). Of course, there are many arguments about the advantages and disadvantages of heavyweight mode and lightweight mode, and various modes are constantly developing. Some methodological scholars believe that people should strictly follow and implement these methods in development. But some people don't have the conditions to implement these methods. In fact, the method of developing software depends on many factors and is restricted by the environment.

[Edit this paragraph] Main course

Foreign languages, advanced mathematics, linear algebra, advanced algebra, electronic technology foundation, discrete mathematics, computer introduction (C language), data structure, C++ programming, JAVA programming, Delphi programming, assembly language programming, algorithm design and analysis, computer composition principle and architecture, database system, computer network, software engineering, software testing technology, software requirements and project management, and software design case analysis. In addition, it also includes operating system, software architecture introduction, design mode, multimedia technology foundation, UML modeling, probability theory, college English and so on. Some colleges will also include college physics, engineering drawing, numerical analysis and so on.

[Edit this paragraph] Development direction

Agile development is considered as an important development of software engineering. It emphasizes that software development should be able to fully cope with possible changes and uncertainties in the future. Agile development is considered as a "lightweight" method. The most famous lightweight method should be "extreme programming" (XP for short). Corresponding to the lightweight mode is the existence of the "heavyweight mode". The heavyweight method emphasizes the development process as the center, not the people as the center. Examples of heavyweight methods are CMM/PSP/TSP. AOP is regarded as another important development of software engineering in recent years. An aspect here refers to a collection of objects and functions that complete a function. There are generic programming and templates in this regard.

[Edit this paragraph] Demand analysis

Software engineering includes four stages: requirements, design, coding and testing, among which requirements engineering is the first and very important stage of software engineering. Taking the requirement analysis system of hospital management software engineering as an example, the composition and implementation method of requirement engineering are introduced in detail. First of all, people must understand the relationship between requirements engineering and other project processes: Figure 1 Relationship between requirements and other project processes Software requirements include three different levels-business requirements, user requirements and functional requirements-and non-functional requirements: business requirements explain the initial benefits provided by the new system to customers and product developers, and reflect the high-level target requirements of organizations or customers for systems and products, which are explained in project views and scope documents; The user requirements document describes the tasks that users must complete when using the product, and it is explained in the use case document or scheme script description; Functional requirements define the software functions that developers must implement so that users can complete tasks and meet business requirements. Requirements engineering is divided into two stages: requirements development and requirements management. These two stages are explained as follows: First, requirements development is divided into requirements acquisition, requirements analysis, specification writing and requirements verification. The general steps of analysis are listed and explained below. Of course, the appropriate steps should be determined according to the actual situation such as the size and characteristics of the project. 1. Requirements Acquisition: 1) Determine the requirements development process: determine how to organize the steps of requirements collection, analysis, refinement and verification in the requirements development process, and write them into documents. Giving some guidance on the important steps will help the analyst's work and make it easier to arrange and schedule requirements collection activities. 2) Prepare project views and scope documents: the project views and scope documents should include high-level product business objectives, and all use cases and functional requirements must meet the achievable business requirements. The project view description enables all project participants to understand the project objectives. Scope is used as a reference for evaluating requirements or potential characteristics. Table 1 Template A of Project View and Scope Document, 1 Background In this part, we summarize the theoretical basis of new products and provide a general description of the historical background or situation of product development. 2 business opportunities describe existing market opportunities or business problems being solved. Describe the market where goods compete and the environment where information systems will be used. It includes a brief relative evaluation of existing products and solutions, and points out why the proposed products are attractive and the competitive advantages they can bring. A.3 Business Objectives Summarize the important business profits brought by products in a quantitative and measurable way, and focus on the value given to the business. A.4 Customer or market demand describes the needs of some typical customers, including products or information systems that do not meet the existing market demand. This paper puts forward possible (or impossible) explanations for the problems that customers currently encounter in new products, and provides examples of how customers use products. The software and hardware platforms on which the product can run are determined. A, 5 The value provided to customers determines the value that products bring to customers, indicating how products can meet customers' needs. A.6 Business Risks Overview of the main business risks related to developing (or not developing) products, such as market competition, time problems, users' acceptance, implementation problems or possible negative impacts on business. Predict the severity of the risk and point out the measures you can take to mitigate it. B. 1 project concept statement Write a short project concept statement, summarizing the long-term goals and the purpose of developing new products. The project viewpoint statement will consider weighing the viewpoints of customers with different needs. It may be a bit idealistic, but it must be based on the existing or expected customer market, enterprise framework, strategic direction of the organization and resource constraints. B.2 Main functions include the list of main functions and user performance that the new product will provide. The focus is on the characteristics that are different from previous products and competitive products. These features can be obtained from user requirements and functional requirements. B.3 Assumptions and Related Environments When conceiving the project and writing the project view and scope document, record any assumptions made. Usually, one party should hold different assumptions from the other. C. 1 The scope of initial release summarizes the performance of the first batch of released products. Describe the quality characteristics of products, so that products can provide expected results for different customer groups. C.2 Scope of subsequent release If you imagine a periodic product evolution process, you should indicate which major functions will be delayed and predict the date of subsequent release. C.3 Limitations and particularities Clearly defining the boundaries of features and functions to be included and excluded is a way to deal with scope setting and customer expectations. List the features and functions that stakeholders expect but you don't intend to include in the product. D. 1 customer profile customer profile defines some essential characteristics of different types of customers of this product, as well as the characteristics of target market departments and different customers in these departments. D.2 Project Priorities Once the project priorities are defined, project stakeholders and project participants can focus on a series of * * * same goals. One way to achieve this goal is to consider five aspects of software projects: performance, quality, planning, cost and personnel. E factors of product success define and measure product success, and point out several factors that have great influence on product success. It should include not only the transactions within the direct control of the organization, but also external factors. If possible, a metric can be established to evaluate whether the business objectives are achieved. 3) Classification of user groups: users of products are different in many aspects, such as the frequency of users using products, their understanding of application fields and computer systems, the characteristics of products used, business processes, geographical layout, access priority, etc. According to these differences, you can group these different users. User classes do not necessarily refer to people. You can consider hardware components used by other applications or system interfaces as members of other user classes. Viewing the API in this way can help you determine the requirements related to external applications or components in the product. Classify the user groups and summarize their respective characteristics. In order to avoid ignoring the needs of a certain user group, we must do all possible differentiation. Detailed description of their personality characteristics and task conditions will help product design. 4) Selection of product representatives: Choose the product representatives of each type of users, and choose at least one person who can truly represent their needs as the representative of this type of users, and can make decisions. This is the easiest for the development of internal information system, because at this time, users are the staff around them. For commercial development, it is necessary to establish a good cooperative relationship between major customers or testers and determine appropriate product representatives. They must always participate in the development of the project and have the right to make decisions. Each product representative represents a specific user class and acts as the main interface between the user class and developers. 5) Establishment of core team: Establish a core team of typical users, gather user representatives of similar products or previous versions, and collect functional requirements and non-functional requirements of current products from them. Such a core team is particularly useful for business development, because you have a large and diverse customer base. Unlike product representatives, core team members usually have no decision-making power. 6) Determine the use case: let the user representatives determine the use case, collect the descriptions of the tasks they need to complete with software from the user representatives, and discuss the interaction mode and dialogue requirements between users and the system. Standard templates can be used when writing documents with examples, and functional requirements can be obtained based on examples. A use case may include many logically related tasks and interaction sequences to complete a task. Therefore, a usage example is a collection of related usage descriptions, and a description is an example of a usage example. When describing, list the interaction or dialogue order between the executor and the system. When this conversation ended, the executor also achieved the expected purpose. For some complex use cases, it is beneficial to draw graphical analysis models, including data flow diagram, entity relationship diagram, state transition diagram, object class and contact diagram. The description of use cases does not provide developers with the details of the functions they want to develop. To reduce this uncertainty, it is necessary to describe each use case as a detailed functional requirement. Each use case can lead to multiple functional requirements, which will enable the executor to perform related tasks; And multiple use cases may require the same functional requirements. The advantage of using use case method to obtain requirements comes from the view that this method is task-centered and user-centered. Compared with the function-centered method, the example method can make users more aware of what the new system allows them to do. Each use case describes a method by which users can interact with the system to achieve specific goals. Using instances can effectively capture most expected system behaviors, but you may have some requirements that are not specifically related to the interaction between user tasks or other performers. At this time, you need an independent requirement specification. 7) Holding an application development liaison meeting: Holding an application development liaison meeting is a broad and simple forum, and it is also a good way of cooperation between analysts and customer representatives, from which the draft requirements document can be drawn up. The conference can put the partnership between customers and developers into practice through close and focused discussions. 8) Analyze user workflow: analyze user workflow and observe the process of users performing business tasks. Draw a simple schematic diagram (preferably a data flow diagram) to describe when users get what data and how to use it. Writing business process documents helps to clarify the use examples and functional requirements of products. You may even find that customers don't really need a brand-new software system to achieve their business goals. 9) Determine quality attributes: Determine quality attributes and other non-functional requirements, and consider non-functional quality characteristics in addition to functional requirements, which will make your products meet and exceed customers' expectations. The statement of how the system can perform some behaviors well or let users take some measures is the quality attribute, which is a non-functional requirement. Listen to opinions describing reasonable characteristics: fast, simple, intuitive, user-friendly, steady, reliable, safe and efficient. You will discuss with users to precisely define the true meaning of their vague and subjective words. 10) View the problem report: By viewing the problem report of the current system, we can further improve the problem report of the demanding customers, supplement the requirements, and provide a lot of rich ideas for the improvement and addition of new products or versions. The person responsible for providing user support and help can provide very valuable information for the process of collecting requirements. 1 1) requirements reuse: cross-project reuse requirements If the functions required by customers are similar to existing products, we can check whether the requirements are flexible enough to allow some existing software components to be reused.