Introduction to the Software development model

1. Side-by-side modification models (Build-and-fix model)

Well, in fact, many products are actually used in the "side-to-side change" model to develop, especially many small companies product cycle compression too short. In this model, there is neither specification nor design, and the software continues to be modified again and again as the customer needs.

In this model, the developer gets the project immediately, writes the program according to the requirement, and debugs the first version of the software after it is built. After being made available to the user, if the program has an error, or if the user requests a new request, the developer re-modifies the code until the user and the test are satisfied.

This is a similar to the development of a workshop, the advantages of doing edge modification model is no doubt that the early results are fast.

A small program that does not need to be too rigorous to write logic can be dealt with in the past, but this approach is unsatisfactory for development of any size, and the main problem is:

1) lack of planning and design links, the structure of the software with the continuous changes are getting worse, resulting in the inability to continue to modify;

2) Ignoring the demand link, the software development brings great risk;

3) It is difficult to maintain the software without considering the maintainability of the test and the program, and without any documentation.

2. Waterfall models (Waterfall model)

Waterfall model is a relatively old software development model, 1970 Winston Roys proposed the famous "Waterfall model", until the 80 's has been widely used model.

Waterfall model divides the software life cycle into six basic activities, such as planning, requirement analysis, software design, program writing, software testing and operation maintenance, and stipulates their top-down and cohesive fixed order, like waterfall flowing water and descending.

In the waterfall model, the activities of software development are conducted in a linear manner, and the current activity accepts 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, such as validation passed, and the result acts as an input to the next activity, continuing with the next activity, or the modification is returned.

Waterfall model advantages are strictly follow the pre-planned sequence of steps, all step-by more rigorous.

The waterfall model emphasizes the role of the document and requires careful verification at each stage. However, the linear process of this model is too idealistic, no longer suitable for modern software development model, almost abandoned by the industry, the main problem is:

1) The division of each stage is completely fixed, the stage produces a large number of documents, greatly increasing the workload;

2) Since the development model is linear, users can only see the development results at the end of the process, thus increasing the risk of development;

3) Early errors may not be discovered until the late stages of development, leading to serious consequences.

4) The life cycle of each software takes a long time to connect, and the team personnel exchange cost is great.

5) Waterfall methods are not feasible in situations where the requirements are unclear and may change during the course of the project.

3. Iterative models (Stagewise model) (also known as iterative incremental development or iterative evolutionary development)

is a software development process contrary to traditional waterfall development, which compensates for some of the weaknesses of traditional development methods, with higher success rates and productivity.

In an iterative development approach, the entire development effort is organized into a series of small, fixed-length items, such as 3 weeks, that are called a series of iterations. Each iteration includes requirements analysis, design, implementation, and testing. In this way, the development work can be initiated before the requirements are fully identified, and a part of the system's functionality or business logic development is completed in one iteration. We then refine the requirements through customer feedback and start a new round of iterations.

In teaching, the differences between iterations and versions can be understood as follows: iterations generally refer to a version of the production process, ranging from requirement analysis to testing completion , which generally refers to the results of a phase of software development, a deliverable product.

Compared with the traditional waterfall model, the iterative process has the following advantages:

1) reduces the risk of spending on an incremental. If the developer repeats an iteration, then the loss is just the cost of the wrong development iteration.

2) reduces the risk of products not being able to enter the market in accordance with established progress. By identifying risks early in the development, they can be resolved as early as possible without being rushed in the late stages of development.

3) Speed up the progress of the whole development work. Because developers know the focus of the problem, their work is more efficient.

4) Since the user's needs are not fully defined at the outset, they are often refined in the subsequent stages. As a result, this pattern of iterative processes makes it easier to adapt to changes in requirements. Higher reusability

4. Rapid prototyping (Rapid Prototype model)

The first step in a rapid prototyping model is to build a rapid prototype that enables customers or future users to interact with the system, and the user or customer evaluates the prototype to further refine the needs of the software to be developed. By gradually adapting the prototype to meet the customer's requirements, the developer can determine what the customer really wants, and the second step is to develop customer-satisfied software products based on the first step.

Obviously, the rapid prototyping method can overcome the shortcomings of the waterfall model, and reduce the development risk due to the unclear requirements of software, which has remarkable effect.

The key to rapid prototyping is to build software prototypes as quickly as possible, and once you have identified the real needs of your customers, the prototypes you build will be discarded. Therefore, the internal structure of the prototype system is not important, it is important to quickly set up prototypes, and then quickly modify the prototype to reflect the needs of customers.

The rapid prototyping model is somewhat integrated with the "edge-to-edge" and "Waterfall model" benefits.

5. Incremental models (Incremental model)

As with building buildings, software is built step-by-step. In an incremental model, software is designed, implemented, integrated, and tested as a series of incremental artifacts, each of which is made up of code fragments that provide specific functionality, formed by a variety of interacting modules.

Incremental models do not deliver a complete product that can be run at each stage, but rather deliver a running product that meets a subset of the customer's needs. As the entire product is broken down into several components, the developer is able to deliver the product individually, and the benefit is that software development can adapt well to change, and customers can constantly see the software being developed, thus reducing the risk of development. However, the incremental model also has the following drawbacks:

1) Since each component is gradually incorporated into the existing software architecture, the component must not break the already constructed system parts, which requires the software to have an open architecture.

2) in the development process, the change of demand is unavoidable. The flexibility of the incremental model can make it adapt to the change greatly better than the waterfall model and the rapid prototyping model, but it is also easy to degenerate into a side-by-side modification model, thus the control of software process loses its entirety.

When using an incremental model, the first increment is often the core product that implements the basic requirements. Once the core product is delivered to the user, it is evaluated to form the next incremental development plan, which includes modifications to the core product and 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.

6. Helical models (Spiral model)

In 1988, Barry Boehm formally published the "Spiral Model" of software system development, combining waterfall models and rapid prototyping models, highlighting risk analysis that other models have overlooked, particularly for large and complex systems.

The spiral model has several iterations along the Helix, and the four quadrants in the diagram represent the following activities:

1) Make a plan: Determine the software objectives, select the implementation plan, clarify the constraints of project development;

2) Risk Analysis: Analysis and evaluation of the selected program, consider how to identify and eliminate risk;

3) Implementation of the project: the implementation of software development and validation;

4) Customer Evaluation: evaluation of development work, the proposed amendments to make the next plan.

The Helix model, driven by risk, emphasizes the option and constraints to support software reuse, and helps to integrate software quality into product development as a special goal. However, the Helix model also has certain restrictions, specifically as follows:

1) The Spiral model emphasizes risk analysis, but it is not easy for many customers to accept and believe this analysis and to make relevant responses, so this model is often adapted to internal large-scale software development.

2) If performing a risk analysis will significantly affect the profitability of the project, then the risk analysis is meaningless, so the helix model is only suitable for large-scale software projects.

3) Software developers should be good at looking for possible risks and accurately analyzing risks, otherwise they will lead to greater risk

The first stage is to determine the objectives of the phase, to complete the selection of these objectives and constraints, and then from the perspective of risk analysis of the development strategy of the program, and strive to eliminate the potential risks, sometimes need to build prototypes to complete. If certain risks cannot be excluded, the scenario terminates immediately, otherwise the next development step is initiated. Finally, evaluate the results of this phase and design the next phase.

7. Agile Software Development (Agile development)

Agile development is a human-centered, iterative, progressive development approach. In agile development, the construction of software projects is divided into sub-projects, the results of each sub-project are tested, with integration and operational characteristics. In other words, a large project is divided into several interconnected, but also can be run independently of small projects, and completed, in the process of software has been in a state of use.

The main working methods of the Agile development team can be summed up as: work as a whole, work in short iterations, deliver results on each iteration, focus on business priorities, check and adjust.

Agile software Development to pay attention to project size, scale growth, team communication costs go up, so Agile software development temporarily suitable for not particularly large team development, more suitable for a group of teams to use.

8. Evolutionary models (evolutionary model)

Primarily for software development that does not have a complete definition of requirements in advance. Users can give the core requirements of the system to be developed, and when the core requirements are realized, they can effectively provide feedback to support the final design and implementation of the system. Software developers based on the needs of users, the first development of core systems. When the core system is put into operation, the user tries to finish their work, and puts forward the requirement of refinement system and system capability. The software developer implements the iterative process of development based on user feedback. The first iterative process consists of requirements, design, coding, testing, and integration phases, adding a definable, manageable subset to the entire system.

In the development model to take a batch cycle development approach, each cycle of development of a part of the function, they become a prototype of this product new features. As a result, the design continues to evolve into a new system. In fact, this model can be seen as multiple "waterfall models" of repeated executions.

The evolutionary model requires developers to be able to break down the product requirements of a project into different groups for batch cycle development. This grouping is not absolutely arbitrary, but depends on the importance of the function and the impact on the overall design of the infrastructure to make judgments. Experience has indicated that each development cycle takes six weeks to eight weeks for the appropriate length.

9. Fountain models (Fountain model, object-oriented lifetime model, object-oriented (ORIENTED,OO) model))

Compared with the traditional structured lifetime, fountain model has more increment and iterative properties, each stage of the lifetime can overlap and repeat multiple times, and it can embed the sub-lifetime in the whole life period of the project. Like water spray can fall down, can fall in the middle, can also fall on the bottom.

10. Intelligent model (four-generation technology (4GL))

The smart model has a set of tools (such as data query, report generation, data processing, screen definition, code generation, high-level graphics capabilities, and spreadsheets), each of which enables developers to define certain features of the software at a high level, and automatically generate the developer-defined software as source code. This approach requires support for four-generation languages (4GL). 4GL differs from the three-generation language, its main feature is the user interface is extremely friendly, even without trained non-professional programmers, can also use it to write programs, it is a declarative, interactive and non-procedural programming language. The 4GL also has efficient program code, intelligent default assumptions, complete database and application generators. At present, the popular 4GL (such as FoxPro) in the market has the above characteristics to varying degrees. However, 4GL is mainly limited to the development of small and medium-sized applications in transaction information systems.

11. Mixed models (hybrid model)

The process development model, also called the Hybrid model (hybrid model), or meta-model (Meta-Model), combines several different models into a hybrid model that allows a project to evolve along the most efficient path, which is the process development model (or hybrid model). In fact, some software development organizations use several different development methods to compose their own hybrid models.

Original address: http://www.cnblogs.com/liang--liang/p/3613815.html

the characteristics and application scope of some common software process models are outlined:  

model name	Technical Features	Scope of application
Waterfall model	Simple, phased, causal relationship between phases, All phases are reviewed, allow feedback, and do not support User involvement, requiring pre-determined requirements	Software systems with easy-to-define and easily-changing requirements
Rapid Prototyping Model	Does not require pre-complete definition of requirements, support user participation, Support the gradual improvement and validation of requirements to adapt to changes in user needs	Software systems with complex requirements, difficult to determine and dynamic changes
Incremental model	The SOFTWARE PRODUCT was developed by an incremental block, Allow development activities to be parallel and overlapping	Software system with greater technical risk and more stable user demand
Iterative Models	Does not require a one-time development of a complete software system, the software Development is regarded as a process of gradually acquiring and perfecting software products with wide demand.	Software systems with uncertain and changing requirements
Spiral Model	Combining waterfall model, rapid prototyping model and iterative mode The introduction of risk-analysis activities	Software systems with high risk of software development and difficult to obtain and identify requirements

Introduction to the Software development model (GO)