Software Engineering: Process and method of software engineering

Although programmers lead a good salary, they also pay a great deal of energy and time. With the increasing size of software, the uncertainty of user requirements and the rapid change, so that software development can not stay in the small workshop of the personal hero era, it has developed into today's reliance on teamwork behavior, conventional management methods have been unable to meet the actual needs of software development. and software engineering is to study how to develop and manage and maintain the cross-discipline of software with systematic, standardized and quantitative process method.

• What are the software engineering processes?
• What are the common software development process models?
• What are the general diagrams in UML

What are the software engineering processes?

Software engineering is a system science, is the research and application of how to develop and maintain software in a systematic, normative, and quantitative way, and how to combine time-tested and proven management techniques with the best technical methods currently available.
The standard software development process has a certain process, generally including the following aspects of the content: feasibility analysis, requirements analysis, design, coding and implementation, testing and operation and maintenance.
(1) Feasibility analysis
Feasibility analysis is a system must be carried out before the formal project, it is not intended to analyze the software development process problems, nor to solve the software development process may exist problems, but to determine whether the software system is valuable to do, can be at the lowest possible cost in the shortest possible time to solve the problem.

Specifically, in the feasibility analysis phase, to determine the development goals and general requirements of the software, so in the feasibility analysis, the general need to consider whether the technology is feasible, economic efficiency is feasible, user operation is feasible, law and society is feasible. For example, for a supermarket commodity price query system, you need to investigate whether customers want to use such software, supermarket commodity price source is? Is it technically possible to achieve such a process?

The feasibility analysis is generally carried out by strategic experts, and the documentation results for this phase are the feasibility analysis report.

(2) Demand analysis
Demand analysis is the key to the success or failure of a software project, it is to answer what the customer does, is a user's needs of the correct processing, correct understanding, and then it is used in software engineering development language to express the process. Demand analysis is not just about user needs, but also about all the requirements encountered in development. For example, when doing a demand analysis, the first thing you need to figure out is what the project is designed to solve, and then figure out what data should be entered in the test case, and finally figure out who needs to use the system.

The basic task of this stage is to work with the user to determine the problem to be solved, to establish the logical structure of the software, to write the requirement Specification document and finally to get the user's approval. The main methods of demand analysis are the methods of structural analysis, data flow chart and data dictionary. This stage generally can form the software requirement specification, the data request specification and the preliminary user manual.

Needs analysis needs domain experts and system architects to participate, the stage document results for the "Requirements Analysis manual" and so on.

(3) Design
The main task of software design is to decompose the software into modules, that is, the data and program description of a function and the program unit of executable program. This module can be a function, a procedure, a subroutine, a separate program and data with a program description, or it can be a composable, biodegradable, and replaceable functional unit.

Software design can be divided into two stages: summary design and detailed design.
The outline design is the structure design, the main goal is to give the software module structure. In the detailed design, the first is to design the program flow, algorithm and data structure of the module, followed by the design database, commonly used methods or structured programming methods.

The document results in this stage include "Summary Design Specification", "Business use case Document", "Detailed design Specification", "Technical use case document", etc.

(4) Coding and implementation
Coding refers to the conversion of software design to a computer acceptable program, which is written in a programming language expressed in a "source program list." The programming language can be C, C + +, C #, or Java. In the current software development, in addition to special occasions, has rarely used the the 1980s high-level language, instead of the object-oriented programming language, and the object-oriented development language and development environment are mostly integrated, greatly improving the speed of development. Projects developed by the object-oriented development language greatly enhance the scalability and maintainability of the system.

The documentation for this stage is "interface document", "Key algorithm document" and so on.

(5) test
Software testing runs through the entire process of software development, with the aim of discovering as many errors as possible at a lesser cost. The key to achieving this goal is to design an excellent set of test cases (test data and expected output results, which comprise test cases) based on the specifications and the internal structure of the program at each stage of software development, and use these test cases to test for errors and bugs that exist in the program. Different test methods have different test case design methods, and the common test methods are white box test and black box test.

White box testing is a test unit inside how to work, the purpose is to check the internal logic structure of the software to cover the logical path of testing, and the black box test does not consider the internal structure and characteristics of the program, only according to the program function or the external characteristics of the program design test cases, Both of these test methods are based on the function of the software or the description of the software, the interface, function and structure of the software are found to be wrong.
The results of this phase are "unit test Report", "Integration test Report", "System test Report" and so on.

(6) Operation and maintenance
Although the system is delivered to the user, the installation is run, but no system can fully meet the actual application requirements from the beginning, and it is often necessary to continuously re-develop after the delivery. Maintenance refers to the activities of software engineering that have been performed on the SOFTWARE PRODUCT after it has been completed and used for the development (analysis, design, coding and testing). That is, according to the software operation, the software should be modified and maintained, such as perfect maintenance, adaptive maintenance, to adapt to the new requirements, as well as correct the errors found in the operation, write software problems report, software Modification report. A system of high and low quality and system analysis, design has a great relationship, and the maintenance of the system also has a great relationship.
It is important to note that the software engineering comparison emphasizes the importance of documentation, so each stage is best documented, because each stage is based on the previous stage, and if the underlying problem arises, the subsequent stages may have a corresponding problem, and the document is available for future reference.

What are the common software development process models?

The software development process describes a method of software construction, deployment, and maintenance that specifies the steps required to complete each task. The theoretical basis of the software development process model is the software life cycle theory and the related engineering principles.

The core idea of the software development process is to divide the software development process into several stages, each of which follows the "high cohesion, low coupling" (coupling: Also known as the inter-block connection. A measure of the degree of connection between modules in a software system structure. The tighter the connection between the modules, the stronger the coupling, the less the module's independence. The coupling between modules depends on the complexity of the interface between modules, the mode of invocation and the information transmitted. Cohesion: Also known as intra-block contact. A measure of the functional strength of a module, a measure of the degree to which each element within a module is bound to each other. The more cohesive the elements within a module (between the names and the program segments), the higher the cohesion is. , which can help simplify the problem, help verify the success of a phased effort, and enhance the management of software development.

Common software development process models include waterfall model, Helix model, incremental model, prototype model and RUP model.

(1) Waterfall model
Waterfall model divides the software life cycle into 6 basic activities, such as feasibility analysis, requirement analysis, design, code realization, test, installation and maintenance, and stipulates their top-down fixed order, such as waterfall flowing water, falling by layer. Figure 11-1 shows a waterfall model structure diagram.

In the waterfall model, the activities of software development are carried out in strict accordance with the current mode, the current activities accept the work result of the previous activity, and the work required to complete the implementation. The work result of the current activity needs to be validated, and if the validation is passed, the result will continue with the next activity as input to the next activity, otherwise the modification is returned.

As one of the earliest software development models, the waterfall model provides a phase-by-stage checkpoint for the project, and after the current phase is complete, the developer only needs to pay attention to the next stage of work, so the use of waterfall model can strictly ensure that the software products can be delivered on time. However, due to the linear relationship of the waterfall model, the division of each stage is too fixed, the stage produces a large number of documents, which will increase the workload, in the waterfall model, users only wait until the end of the entire development process to see the development results, which will increase the risk of development, and will have a serious consequences, It is the early mistakes that may wait until the test is discovered, and the problem will be amplified and eventually lead to serious consequences.

(2) Prototype model

A prototype is a primitive model that simulates a product, and a prototype of a software system is an early version of a software system that can be run. Prototype model is a form of incremental model, before the development of real systems, the first need to build a simple system prototype, to achieve customer or future user and system interaction, customers or users in the use of the prototype in the process of using, and constantly find the problem, so as to further refine the system requirements. On the basis of the existing prototype, the developer can adapt the prototype to meet the needs of customers or users, determine the real needs of customers, and then develop a system of customer or user satisfaction. Figure 11-3 shows the prototype model structure diagram.

The prototype model overcomes the shortcomings of the waterfall model and reduces the development risk due to unclear software requirements. The key is to build software prototypes as quickly as possible, and once you have identified the real needs of the customer, the prototypes you build will be discarded. Therefore, using prototype models for software development, the most important thing is to quickly prototype, and then quickly modify the prototype to reflect the customer's needs, rather than the internal structure of the system.

(3) Spiral model
Spiral model is a model of software system development using periodicity method, which combines the characteristics of waterfall model and prototype model, emphasizes the risk analysis neglected by other models, and is often used in large complex systems. Figure 11-2 shows the spiral model structure diagram.

The advantages of the Helix model are mainly expressed in its design flexibility, it can be changed at all stages of the project, the construction of large-scale systems with small segments can make the cost calculation simple and clear, and risk analysis can make some extremely difficult problems and may lead to excessive costs of the problem is changed or canceled, At the same time, user evaluation provides flexibility for changes in demand, and customers can always master the progress of the project, thus improving the accuracy of the demand and the efficiency of development. The disadvantage of the helix model is that it emphasizes risk analysis, requires customers to accept and believe this analysis, and to make the relevant response is not easy, require developers have a considerable amount of risk credential experience and expertise, and require users to participate in stage evaluation, it is difficult for users, excessive number of iterations will increase development costs, Delay the time the software is delivered.

(4) Incremental model
An incremental model, also known as a cumulative model, is the development of a system in a series of incremental ways during the development of a project. In the incremental model, the software is designed, implemented, integrated and tested as a series of components. Each component is composed of code fragments that provide specific functionality, formed by multiple interacting modules. In incremental model development, the entire product is decomposed into several components, each time not delivering a complete product that can be run, but rather a part of the operational subsystem that is delivered to the system. The advantages of this method can be better adapted to customer or user needs change, customers or users can be in batches to see well-functioning subsystems, thereby reducing the development risk. Figure 11-4 shows the incremental model structure diagram

Defects:

• The system is incrementally developed, so the components of each addition have the potential to destroy the part of the system that has been built when added into the system.

• Inevitably, the flexibility of the incremental model can make it much better than the waterfall model and the rapid prototyping model, but it is also easy to lose the integrity of the software Process control.

  In an incremental model, the first increment is often the core product that implements the basic requirements. After the core product is delivered, it is evaluated to form the next incremental development plan, which includes the modification of the core product and the release of some new features. This process repeats after each incremental release until the final product is produced. For example, use the incremental model to develop word processing software. Consider the first incremental release of basic file management, editing, and document generation capabilities, the second incremental release of more sophisticated editing and document generation capabilities, the third incremental implementation of the spelling and grammar checker feature, and the fourth incremental completion of Advanced page layout features.

(5) Unified Software Process RUP model

RUP (Rational Unified process) is a set of software development process models proposed by rational company. It translates user requirements into a collection of activities required by the software system, and describes a series of related software engineering processes that have the same structure, the same process framework.

RUP absorbs the advantages of a variety of development models, with good operability and practicality. The unification process is not only a simple process, but also a general process framework. It can be used for a variety of different types of software systems, a variety of application areas, a variety of different project sizes.

RUP can be described by two-dimensional coordinates. The horizontal axis through time organization, is the process unfolds the life cycle characteristic, manifests the development process the dynamic structure, uses to describe its term mainly includes cycle (cycles), the stage (Phase), the iteration (iteration) and the milestone (Milestone) Vertical axes are organized into natural logical activities as content, reflecting the static structure of the development process, and the terminology used to describe it consists mainly of activities (activity), Products (Artifact), workers (worker), and Workflow (Workflow).

The software life cycle in RUP is decomposed into 4 phases, namely the initial phase (Inception), the refinement phase (elaboration), the build phase (construction), and the delivery phase (Transition). Each phase ends at a major milestone, and each phase is essentially a time span between two milestones. Figure 11-5rup shows the Rup workflow. Specifically, the four-phase functionality is shown below.

• Initial phase: The goal of the initial phase is to establish a business case for the system and define the project boundaries, at which point the final product view, the business model, and the system scope are defined. It takes the demand analysis as the main and establishes the whole system structure. The first important milestone at the end of the initial phase is the life cycle goal milestone, which is used to evaluate the basic viability of the project.
• Elaboration stage: Design and determine the system structure, make work plan and resource requirement. Design, code implementation, testing, and then feedback to the requirements analysis results for the first phase of the requirements analysis. The second important milestone at the end of the phase is the lifecycle structure milestone, which establishes a management baseline for the structure of the system and enables the project to be measured at the build stage
• Build phase: Build products and continue to evolve requirements, architectures, plans, and product submissions. Design, code implementation, testing, and feedback on the requirements of the initial phase. The process of repeating requirements, design, programming, testing. The milestone in the build phase is the initial feature milestone, which determines whether the product can be deployed in a test environment.
• Delivery phase: The product is submitted to the user for use, comprehensive testing, delivery of operational products. The milestone at the end of this phase is the product release milestone.

What are the general diagrams in UML

Software Engineering: Process and method of software engineering