Comparative analysis of common software development models

As with anything, software has its own process of gestation, birth, growth, maturation and decay, which is generally referred to as the "software life cycle". The software lifecycle is generally divided into 6 phases, namely planning, requirements analysis, design, coding, testing, operation and maintenance. The relationship between the stages of software development cannot be sequential and linear, but it should be an iterative process with feedback. In software engineering, this complex process is described and represented by a software development model. The software development model is the framework of all the work and tasks that the system develops, runs and maintains across the entire software life cycle, and it gives the relationship between the stages of software development activities. At present, the common software development model can be broadly divided into the following 3 kinds. ① is a waterfall model that is fully defined as a prerequisite for software requirements (Waterfall models). ② a progressive development model, such as a helical model, that can only be used to provide basic requirements during the initial stages of software development. ③ is a transformation model based on formal development methods (transformational models). This section will simply compare and analyze software development models such as waterfall models, helical models, and transformation models. 1.2.1 Waterfall Model Waterfall model is the life cycle model, whose core idea is to simplify the problem according to the process, separate the realization and design of the function, and facilitate the division and collaboration, that is, the logical realization is separated from the physical realization by the structured analysis and design method. The waterfall model divides the software life cycle into 6 stages of software planning, requirements analysis and definition, software design, software implementation, software testing, software operation and maintenance, and defines their top-down, interconnected fixed order, as if the waterfall is falling. The software process using the waterfall model is shown in Figure 1-3. Figure 1-3 Software process using a waterfall model Waterfall model is the first software development model, which occupies an important position in software engineering, and it provides the basic framework of software development. The nature of the waterfall model is one pass, that is, each activity is executed only once, and finally the software product, also known as the "linear sequential model" or "traditional life cycle". The process is the input of the work object that received the activity from the previous activity, and the content that the activity should be implemented by using this input gives the results of the activity and passes it as output to the next activity. At the same time review the implementation of the activity and, if confirmed, continue with the next activity, otherwise return to the previous, or even earlier, activity. Waterfall model is beneficial to the organization and management of large-scale software development process, and is beneficial to the research and use of software development methods and tools, thus improving the quality and efficiency of large-scale software project development. However, the practice of software development shows that the above activities are not completely top-down and linear schema, so the waterfall model has serious defects. ① because the development model is linear, users cannot see the effect of the software when the development results have not been tested. This allows the software to meet the user for a long time interval, but also increased a certain amount of risk. ② errors found during the end of software development are propagated to later development activities, which can potentially lead to a failure in the development of the entire software project. ③ in the software requirements analysis phase, it is difficult or even impossible to fully determine the needs of all users. 1.2.2 Spiral Model The Helix model combines the waterfall and the evolutionary model (Evolution model), which not only embodies the advantages of the two models, but also emphasizes risk analysis that is neglected in other models. Each cycle of this model includes the requirements definition, risk analysis, engineering implementation, and review 4 phases, which are iterated by these 4 phases. Software development process every iteration, software development and a level of progress. The software process using the Helix model is shown in Figure 1-4. Figure 1-4 Software process using a helical model The basic approach of the Helix model is to introduce a very rigorous risk identification, risk analysis and risk control before each development phase of the waterfall model, which breaks down the software project into small projects. Each small project identifies one or more major risks, until all the major risk factors are identified. The Spiral model emphasizes risk analysis, which allows developers and users to understand the risks of each evolution layer and then respond accordingly, making them particularly suitable for large, complex and risky systems. For these systems, risk is the software development can not be neglected and the potential disadvantage, it may damage the software development process to varying degrees, affecting the quality of software products. The goal of reducing software risk is to identify and analyze risks in a timely manner before causing harm, and decide what countermeasures to take to eliminate or mitigate the risk of damage. Compared with the waterfall model, the Helix model supports the dynamic change of user's requirements, which facilitates the user's participation in all the key decisions of software development, and helps to improve the adaptability of the target software. It also facilitates the timely adjustment of management decisions by project managers, thus reducing the risk of software development. However, we cannot say that the Helix model is absolutely superior to the other models, and in fact, this model has its own disadvantages as follows. ① the use of spiral models requires a considerable amount of experience and expertise in risk assessment, in the event of a large risk of project development, if not timely identification of the risk, will inevitably cause significant losses. ② an excessive number of iterations increases development costs and delays the submission time. 1.2.3 Transformation Model The transformation model is a software development model based on formal specification language and program transformation, which uses formal software development method to perform a series of automatic or semi-automatic program transformation for formal software specification, and finally maps to a program system acceptable to the computer system. The software process using the transform model is shown in Figure 1-5. Figure 1-5 Software process using a transform model In order to confirm the consistency between formal specification and software requirement, a software prototype is developed based on formal specification, and the user can review the prototype from the aspects of human-machine interface, main function and performance of the system. If necessary, you can modify the software requirements, formal specifications, and prototypes until the prototype is confirmed. The software developer can then perform a series of program transformations on the formal specifications until the object code acceptable to the computer system is generated. "Program Transformation" is another method of software development, and its basic idea is to divide the process of program design into the stage of generation and improvement. First, a formal specification is developed by analyzing the problem and a program is generated, usually a function-type "recursive equation". Then through a series of the source program to keep the correctness of the transformation of the source program, the functional style to transform into a process style and the data structure and algorithm refinement, and finally get an effective process-oriented program. This transformation process is a strict form derivation process, so only need to verify the program before the transformation, the correctness of the transformed program will be ensured by the correctness of the transformation law. The advantage of the transformation model is that it solves the problem that the code structure is changed by many times, and reduces many intermediate steps (such as design, coding, testing, etc.). But the transformation model still has the big limitation, the transformation model based on the formal development method needs the strict mathematics theory and the whole set of development environment support, at present the formal development method in the theory, the practice and the personnel training aspect from the engineering application still has some distance. 1.2.4 Fountain Model Fountain model is a model based on user's demand, which is driven by object, and is mainly used to describe object-oriented software development process. The model believes that the software development process from the bottom to the cycle of the stages are overlapping and repeated repeatedly, like water spray up and can fall down, similar to a fountain. Each development phase has no specific order requirements and can be interacted with, and can be supplemented at any time during a development phase with omissions from any other development phase. The software process using the Fountain model is shown in Figure 1-6. Fig. 1-6 Software process using fountain model Fountain model is mainly used for object-oriented software projects, a part of the software is often repeated several times, related objects in each iteration with the addition of progressive software components. There is no obvious boundary between activities, for example, there is no obvious boundary between the design and implementation, which is also known as the "no gap of the fountain model". Because of the introduction of the concept of objects, the expression analysis, design and implementation of the activities only use object classes and relationships, so that the activities can be more easily iterative and no gap. The fountain model is not like a waterfall model, where the design activity is not started until the analysis activity is finished, and the coding activity is not started until the design activity is finished. There is no clear boundary between the stages of the model, and developers can develop them synchronously. The advantage is that it can improve the efficiency of software project development, save development time and adapt to the object-oriented software development process. Because fountain models overlap at various stages of development, a large number of developers are needed in the development process and therefore are not conducive to project management. In addition, this model requires strict management of documents, making it more difficult to audit, especially in the face of the possibility to join a variety of information, needs and information. 1.2.5 Intelligent Model The intelligent model, also known as the "knowledge-based software development model", combines waterfall models with expert systems to help software developers work with expert system. The model applies the rule-based system and uses induction and inference mechanism to make maintenance at the system specification level. In the process of implementation, the knowledge system of generating rules based on software engineering knowledge is combined with expert systems containing application domain knowledge rules to form the development system of this application domain software. The software process using the intelligent model is shown in Figure 1-7. Figure 1-7 Software process with an intelligent model The problem that an intelligent model solves is a complex problem in a particular domain, involving a lot of expertise, and developers are generally not experts in the field, and their familiarity with a particular domain requires a process, so software requirements are difficult to define in the initial phase. Therefore, the prototype implementation model needs to be refined through multiple iterations to the software requirements. The intelligent model takes knowledge as the object of processing, which has both theoretical knowledge and specific field experience. In the development process, it is necessary to extract the knowledge from the books and the knowledge base of the specific domain (i.e. knowledge acquisition), and choose the appropriate method to encode (i.e. knowledge representation) to build the knowledge base. Storing models, software engineering knowledge, and knowledge of specific areas in a database is a process that requires close collaboration between system developers and domain experts. The software system developed by the intelligent model emphasizes the meaning of the data and attempts to use the real-world language to express the meaning of the data. The model can explore existing data and discover new factual methods to guide users to solve complex problems at the level of experts. It takes the waterfall model as the basic framework, introduces the prototype implementation method and the object-oriented technology in different development stages to overcome the disadvantage of waterfall model, and adapts to the development of specific domain software and expert decision system. 1.2.6 Incremental Model The incremental model incorporates the basic components of the waterfall model (repeated application) and the iterative characteristics of the prototype implementation, which uses a linear sequence that is staggered with the progress of the schedule, and each linear sequence produces a published "increment" of the software. When using the incremental model, the 1th increment is often the core product, that is, the 1th increment implements the basic requirements, but many of the supplemental features have not yet been released. The customer's use and evaluation of each increment is a new feature and feature for the next incremental release, which repeats every incremental release until the final product is produced. The incremental model emphasizes that each increment publishes an actionable product. The software process using the incremental model is shown in Figure 1-8. The incremental model, like the prototype implementation model and other evolutionary methods, is essentially iterative, but unlike the prototype implementation, it emphasizes that each increment publishes an actionable product. Early increments are "removable" versions of the final product, but provide the functionality to serve the user and provide a platform for the user to evaluate. The incremental model is characterized by the introduction of the concept of incremental packages, without waiting for all requirements to come out, as long as a demand for the incremental package out can be developed. While an incremental package may need to be further adapted to the customer's needs and changes, the impact is affordable for the entire project as long as the incremental package is small enough. Figure 1-8 Software process with incremental model The advantage of using an incremental model is that people are flexible and don't have to invest a lot of human resources at first. If the core product is popular, you can increase the manpower to achieve the next increment. When an equipped person cannot complete the product within a set deadline, it provides a way to launch the core product first. This allows the first release of some of the functions to the customer, the role of sedation to the customer. In addition, incremental can manage technical risks in a planned manner. The disadvantage of the incremental model is that if there is an intersection between the delta packages and is not well handled, then the overall system analysis must be done, and the model will be developed separately after the function refinement to adapt to the software development process that the requirements change frequently. 1.2.7 WinWin Model The WinWin model incorporates the basic components of the Helix model and the iterative characteristics of the prototype implementation, emphasizing risk analysis and identification. Through early negotiation, a consensus agreement between the client and the developer becomes a key criterion for progress to software and system definitions. The WinWin model introduces 3 milestones, called "anchor points." It helps to establish a life cycle of complete and provides a decision milestone before the software project progresses forward. The software process using the WinWin model is shown in Figure 1-9. Figure 1-9 Software process using the WinWin model Essentially, the anchor point represents 3 different progress views when the project traverses the Helix, and the 1th anchor Point, called the "life cycle Goal", defines a set of goals for each major software engineering activity; The 2nd Anchor Point, called the "Lifecycle Architecture," establishes the goals that must be met when the system and software architecture are defined The 3rd Anchor point is called the "initial operational capability", which represents a set of goals that are associated with the preparation of the installation/sale software and the help required by the parties that will use the software. The WinWin model emphasizes risk analysis and identification, which enables developers and users to understand the risks that occur at each evolution level and then respond to them as appropriate. The advantage of adopting the WinWin model is that the customer and the developer achieve a balance and achieve a win, but require additional negotiation skills. The Helix model presents a framework activity that emphasizes customer interaction, which is aimed at inducing project requirements from the customer. Ideally, the developer simply asks what the customer needs, and the customer provides enough detail to go on, unfortunately this situation rarely occurs. In the WinWin model, customers and developers enter a negotiation process in which customers are required to balance functionality, performance, and other product or system characteristics under constraints between cost and marketable. The best negotiation results in a "win" outcome, in which the client obtains most of the system's functionality, while the developer gains realistic and achievable budgets and timelines. 1.2.8 prototype Implementation Model The prototype implementation model starts with demand collection, where developers and customers define the overall objectives of the software, identify known requirements, and plan areas that need further definition. Then there is the "quick Design", which focuses on the representation of those parts of the software that are visible to the user/customer. This leads to the creation of prototypes and the need for users/customers to evaluate and further refined the software to be developed. Gradually adapt the prototype to meet the customer's requirements, while also enabling developers to better understand what will be done. The process is iterative, with the process starting with listening to the customer, followed by the build/modify prototype, the customer test run prototype. Then cycle until the customer is satisfied with the prototype. The software process using the prototype implementation model is shown in Figure 1-10. Figure 1-10 Software process with prototype implementation model The most important feature of the prototype implementation model is the ability to quickly implement a preliminary model of a system that can be actually run for communication and review by developers and users in order to obtain the user's needs more accurately. The model uses the gradual refinement method to improve the prototype, that is, each time after the user review after the revision, operation, and constantly repeated recognition by both parties. This process is an iterative process that avoids the appearance of product prototypes in the lengthy development process of waterfall models. The advantage is that the development tools are advanced, the development efficiency is high, the total development cost is reduced, and the time is shortened; the second is that the developer communicates with the user intuitively, can clarify the fuzzy demand, mobilize the active participation of the user, can expose some latent problems of the system early; Thirdly, the prototype system can be used as the training environment, which is , the development process is also the learning process. The disadvantage of prototype implementation model is that the product prototype restricts the innovation of the developers to a certain extent, and does not consider the overall quality and long-term maintainability of the software. The prototype implementation model is not suitable for the development of large-scale software systems such as embedded, real-time control, and scientific numerical calculation, because the product may be discarded due to the lack of quality requirements and the new model is redesigned. Both incremental and prototype models are developed from a summary requirement, but they are significantly different. Incremental models are developed from incomplete system requirements, and new requirements are discovered gradually in the development process. Then further enrich the system to make it a practical system; The purpose of prototyping is to discover and build a complete and proven specification of requirements, which is then used as a basis for the development of a formal system. Therefore, the output of the prototype development phase is a requirement specification, which is a way to pull up the demand analysis phase to reduce the cost of the entire software generation period, and most prototypes are "throw-out" types. 1.2.9 rad Model The RAD (Rapid application development) model is an incremental software development process model that emphasizes a very short development cycle. The model is a "high-speed" variant of the waterfall model, which has won rapid development by using a component-based construction method with a large number of reusable components. If the requirements are understood correctly and the scope of the project is constrained, using this model can quickly create a well-functioning information system. The process starts with business modeling, followed by data modeling, process modeling, application generation, testing, and iteration. The software process using the RAD model is shown in Figure 1-11. Figure 1-11 Software process using the RAD model The tasks to be accomplished by the RAD model during each active period are as follows. (1) Business modeling Determine the information that drives the operation of the business process, the information to be generated, how it is generated, the whereabouts of the information flow and its processing, etc., which can be supplemented by a streaming chart. (2) Data modeling Find a collection of data objects for the data flow that supports the business process, define the properties of the data objects, and form a data model with the relationships of other data objects, which can be supplemented by e-r diagrams. (3) Process modelling Enables the data object to complete each business function in the information flow, creates the procedure to describe the data object's increment, the modification, deletes, the lookup, namely refines the processing frame in the dataflow diagram. (4) Application generation Use the 4th generation language (4GL) to write out handlers, reuse existing artifacts or create new reusable artifacts, and use the tools provided by the environment to generate the entire application system automatically. (5) Testing and delivery Because of the large number of reuse, generally only the overall test, but the newly created artifacts are still to be tested. Compared with the waterfall model, the RAD model does not use the traditional 3rd generation programming language to create software, but instead uses a component-based development approach to reuse existing program structures (if possible) or use reusable artifacts and or create reusable artifacts, if needed. In all cases, automation tools are used to assist in the creation of software. Obviously, the time constraints on a RAD model project require "a scalable range." If a business can be modularized so that each of its main functions can be completed in less than 3 months, it is a candidate for Rad. Each of the main functions can be implemented by a single RAD group and finally integrated to form a whole. The RAD model accelerates the development speed through the use of reusable components and is particularly effective for the development of information systems. However, as with all other software process models, the RAD approach has the following drawbacks. ① not all applications are suitable for RAD. The RAD model requires a high level of modularity, and if any of the functions cannot be modularized, then the components needed to build rad are problematic. If high performance is an indicator and the indicator must be adjusted to fit the system artifacts, the RAD method may not be effective. ② developers and customers must complete a series of requirements analysis in a short period of time, and any failure of either side will lead to the RAD project. ③rad can only be used for information system development and is not suitable for high-tech risk situations. This happens when a new application is going to adopt many new technologies or when new software requires high interoperability with existing computer programs. 1.2.10 Concurrent Development Model The concurrency development model, also known as concurrent Engineering, focuses on concurrent execution of multiple tasks, expressed as a series of major technical activities, tasks, and their associated states. The concurrent process model is driven by customer requirements, management decisions, and review results, rather than limiting software engineering activities to a sequential sequence of events, but defining an active network in which each activity can occur concurrently with other activities. This model can provide an accurate view of the current state of a project. The schematic of an activity in the software process using the concurrency development model is shown in Figure 1-12. Figure 1-12 An activity of the concurrency process model The concurrency Process model defines a series of events that, for each software engineering activity, trigger the transition of one State to another. When it is applied to a client/server system, the concurrency process model defines the activity on a two-D, which is a system and a component dimension. Its concurrency is obtained in the following two ways. ① system and component dimension activities occur simultaneously and can be modeled using a state-oriented approach. ② A typical client/server application is implemented through multiple artifacts, each of which can be designed and implemented concurrently. The concurrency development model attempts to track the state of a project based on the main phases of the traditional life cycle, and it is impossible for project managers to understand the state of the project, thus requiring a relatively simple model to track very complex project activities. The Concurrency development model uses a state diagram (representing a machining state) to represent the concurrency relationship that exists between activities related to a particular event, such as a modification of a post-development requirement, but it does not capture a large amount of concurrency across all software development and management activities in a project. Most software development process models are time-driven, more to the back end of the model, and more to the latter stage of the development process, while a concurrent process model is driven by user requirements, management decisions, and results review. Concurrent development model in the software development of the whole process of parallelization, breaking the traditional software development of the various stages of the separation of the concept of closure. Emphasize the developer team collaboration, focus on the analysis and design of the previous development work, so as to avoid unnecessary rework. The advantage is that it can be used for all types of software development, and the client/server structure is more efficient and can be consulted at any time. 1.2.11 Component-based development model The component-based development model uses the Modularization method to modularize the whole system, and then, with the support of a certain component model, one or more software components in the component library are reused, and the process of applying software system is constructed efficiently and high quality by combining means. The component-based development model incorporates many characteristics of the helix model, which is evolutionary in nature and iterative in the development process. Component-based development model consists of software requirements analysis and definition, architecture design, component library establishment, application software construction, and test and release 5 phases, the software process using this development model is shown in Figure 1-13. Figure 1-13 Software process using a component-based development model As an important software technology and tool, the component has been greatly developed, such as Microsoft DCOM, Sun EJB, OMG CORBA and so on. The component-based development activity begins with identifying candidate components and verifies that the required artifacts exist by searching the existing component libraries. If it already exists, it is extracted from the component library and reused, otherwise it is developed using an object-oriented approach. After using the extracted components through the syntax and semantic inspection, these artifacts are assembled by gluing code together to implement the system, the process is iterative. The component-based development method makes software development no longer all from scratch, the process of development is the process of component assembly, and the process of maintenance is the process of component upgrading, substitution and expansion. The advantage is that the component assembly model leads to the reuse of software and improves the efficiency of software development. A component can be defined by one of its specifications and implemented by the other party. Then for third-party use, the component assembly model allows multiple projects to be developed at the same time, reduces costs, improves maintainability, and allows for step-up submission of software products. Because of the custom assembly structure standard, the lack of the General Assembly structure standard, thus introduced the large risk. Reusability and software efficiency is not easy to reconcile, requires a lean and experienced analysis and development staff, general developers plug-in. Customer satisfaction is low, and because of excessive reliance on components, so the quality of the component library affects product quality. 1.2.12 development model based on architecture The architecture-based development model is based on the software architecture and the component-based development method. Then the iterative increment method is used to analyze and design the function design space, and then the structure design space is mapped to the process of the system design space. The development model divides software life cycle into software definition, requirement analysis and definition, architecture design, software system design and software implementation 5 stages, the software process adopting this model is shown in Figure 1-14. Figure 1-14 Software process with an architecture-based development model In the architecture-based development process, the first is based on the architecture of demand acquisition and analysis, the concept of software architecture into the demand space, so that the analysis phase to the design phase of the transition to provide better support. Based on the results of demand analysis, the design of architecture is carried out. Considering the overall structure of the system and the constituent elements of the system, we find the matching components in the identified component libraries according to the syntax and semantics of the constituent elements. When there is no conforming component, it is necessary to assemble the new component according to the specific situation or to purchase new components or to develop new components as needed to meet the requirements. After syntax and semantic checking, these artifacts are assembled by gluing code together to implement the entire software system. In practice, the entire development process presents multiple iterations. In the traditional software life cycle, software requirements analysis and definition is completed immediately after the software system design and implementation. In this traditional development approach, if the requirements of the software are constantly changing, the final software PRODUCT may differ greatly from the initial prototype. The development model based on the architecture has the strict theory Foundation and the engineering principle, and it takes the system structure as the core. Architecture provides a bridge between software requirements and software design, which solves the smooth transition from requirement to realization of software system, and improves the quality and efficiency of software analysis design. The advantage of the architecture-based development model is that through the design of the architecture, the framework of the software system is clearer, which is beneficial to the design, development and maintenance of the system, and the reuse of software reuse from code-level to component and architecture-level reuse. Both the architecture-based development model and the component-based development model are assembled on the basis of the architecture to obtain the software system, the former focuses on the operational level components and their interoperability, provides a bottom-up and based on pre-customized components to construct the application system approach; the latter is confined to the specification of the component , lack of systematic methodology to guide the development process. The architecture-based development method starts from the overall structure of the system, and displays the architecture of a system to deal with design problems such as global organization and control structure, the allocation of functions to computing elements, and high-level interaction among computing elements at a high level of abstraction. 1.2.13 XP Method The agile approach is a lightweight development approach that has arisen in recent years, emphasizing adaptability rather than predictability, emphasis on human-centric, non-process-centric, adaptation to change, and attention to human nature, characterized by light-load, time-based, Just-enough, parallel, and component-based software processes. Of all agile methods, the XP (EXtreme programming) approach is the most compelling of a lightweight development approach. It sets out a set of core values and methods, eliminates unnecessary artifacts from most of the gravimetric processes, and establishes a progressive development process. This method mixes 4 activities (analysis, design, coding, and testing) in the development phase with iterative incremental development, feedback correction, and repeated testing throughout the process. It divides the software lifecycle into 6 stages of user stories, architectures, release plans, interactions, acceptance tests, and small releases, as shown in Figure 1-15. Figure 1-15 Software process using the XP method XP model through the traditional software development of the standard method of re-examination, proposed by a set of rules composed of some simple and easy process. Because these rules are derived by observing in practice the factors that make the software efficient or slow, it takes into account both the vitality and creativity of the developer and the organization, focus and sustainability of the development process. The XP model is a customer-oriented development model that focuses on the user's level of satisfaction. In the development process, the adaptability to the change of requirements is higher, even in the late development, it can adapt to the user's change to a higher degree. The XP development model differs greatly from the traditional model, whose core ideas are communication (communication), simple (simplicity), feedback (Feedback) and enterprising (aggressiveness). The XP development team includes not only developers, but also executives and customers. The model emphasizes the frequent communication between the members of the group and the simplification of the process and code as far as possible to ensure that the quality can be run; specific feedback from customers, developers and end users can provide more opportunities to adjust the design, ensure the correct development direction, and enterprising is included in the above 3 principles. There are many new ideas in the XP development approach, such as the use of "User stories" instead of the traditional model of demand analysis, "User Stories" by users in their own field of vocabulary and do not consider any technical details to accurately express their needs. The advantages of the XP model are as follows. ① uses a simple planning strategy that does not require long-term planning and complex models, and short development cycles. ② in the whole process using iterative incremental development, feedback correction and repeated testing methods, software quality is guaranteed. ③ is able to adapt to the changing needs of users, providing users with high-quality software. 1.2.14 4th generation technology 4th generation Technology (4GT) contains a series of software tools that have one thing in common, that is, to enable software engineers to regulate certain features of the software at a higher level, and then generate the source code automatically according to the developer's specifications. There is no doubt that the higher the software is, the faster it will be to construct the program. The 4th generation technical model of software engineering focuses on the ability to regulate software, even in the form of a special language or in a term that can be understood by the customer to describe the graphical symbology of the problem to be solved. As with other models, 4th generation technology starts with demand collection. Ideally, customers can describe the requirements that can be directly converted to operational prototypes. However, this is unrealistic, and the customer may not be able to determine exactly what is needed, and there may be two semantics when the facts are known in the Statute, so the user/developer dialogues described in other models are still a necessary part of the 4th generation technology. To turn a 4th-generation technology implementation into an end product, developers must also thoroughly test, develop meaningful documentation, and also complete all integration activities that are required in other models. In addition, software developed using 4th generation technology must also allow maintenance to be built in a way that can be done quickly. As with all other software process models, the 4th generation technology model has its advantages and disadvantages. The advantage is that it shortens software development time, improves the efficiency of building software, and provides a feasible way and solution for many different application areas. The disadvantage is that the source code generated by the tool may be "inefficient", and the maintainability of the generated large software is currently questionable and may take more time in some cases. In a word, the 4th generation technology has become an important method of software engineering. When combined with a component-based development approach, it may become a mainstream approach to software development. 1.2.15 Summary Software engineering is a discipline that integrates the process, method and tools of computer software development, and a series of software engineering process models have their own advantages and disadvantages, but they all have a series of common general stages. The development of software process model has undergone the following stages. ① is a 1th generation software process model, such as waterfall model, which is based on the complete determination of software requirements. This type of development model is characterized by the software requirements in the development phase has been fully determined, the life cycle of activities in order to focus on the development of the stage; its disadvantage is that in the late development to correct early problems need to pay a high price, users need to wait a long time to see software products, increase the risk factor. And if there is a blocking problem in the development process, the development efficiency is affected. ② can only provide incremental development models for basic requirements at the beginning, such as the Helix model and the prototype implementation model. This kind of development model is characterized by the basic requirements of the beginning of software development, and the various activities of the software development process are iterative. Through the iterative process to achieve the gradual evolution of software, the end of the software products. In this paper, risk management is introduced, early preventive measures are taken to increase project success rate, and software quality is improved, and the disadvantage is that the incompleteness of the requirements will bring difficulties to the overall design of the software and weaken the integrity of the product design, and require high requirements for the management of risk skills. ③ is an architecture-based development model, such as component-based development models and architecture-based development models. The characteristic of this kind of model is to use the result of demand analysis to design the general structure of software, and construct software system by component-based assembly method. The appearance of software architecture makes the framework of software structure clearer, which is beneficial to the design, development and maintenance of the system. To sum up, the software development model with the development of software design ideas, experienced by the first with the structural programming thought as the guidance of the waterfall model, to the object-oriented idea as the guidance of the Fountain model, to the concept of component development based on the development of the architecture model and so on, to the present 4GT technology. Every time the breakthrough of the new software design idea will appear the new software development process model, in order to improve the software production efficiency and quality as the goal, put forward a new solution to the "software crisis" problem. Article Source: http://hi.baidu.com/tomclub/blog/item/9dddd2a21a2c05aecaefd021.html