Increment Modal
The incremental model is essentially a series of waterfall cycles. One variant is shown in Figure 2-3. The requirements. It’s also known at the beginning of the project and is divided into groups for incremental development. A core set of functions is identified in the first cycle and is built and deployed as the first release. The software development cycle is repeated, with each release adding more functionality until all requirements are met.
| Characteristics | Strengths | weaknesses | Applicability |
Provide progressively more functional for the customer. | Each linear sequences produces deliverable “increments” that is similar to the increments produced by an evolutionary process flow. | When incremental model are used, basic requirement are addressed but supplementary features remain undelivered. | Staffs are unavailable for a complete implementation by the business deadline that has been established for the project. |
Combine elements of linear and parallel process flow. | Early increments can be implemented with fewer people. | Require active customer participation. | Core product is well received, additional staff can be added to implement. |
Applies linear sequences in a staggered fashion as calendar time progresses. | Increments can be planned to manage technical risks. | Requires good planning and design. | Modification at the core product to better needs of additional features and functionalists. |
Spiral Model
The spiral model was developed with the goal of reducing risk in the software life cycle. It combines elements of the waterfall, evolutionary, and incremental models, and depending on how it is implemented can strongly resemble any combination of the others.
| Characteristics | Strengths | weaknesses | Applicability |
Also a hybrid model that support process iteration | Risk reduction mechanisms are in place. | Costly. | Internal development of large systems. |
The process is represented as a spiral, each loop in the spiral representing a process phase. | Supports iteration and reflects real-world practices. | Requires expertise in risk evaluation and reduction. | For smaller projects, the concept of agile software development is becoming a viable alternative. |
Risk is explicitly taken into consideration. | Systematic approach. | Applicable only to large systems. | The US military has adopted the spiral model for its Future Combat Systems program. |
Prototyping Model
The evolutionary model, like the incremental model, develops a product in multiple cycles. Unlike the incremental model, which simply adds more functionality with each cycle, this model produces a more refined prototype system with each iteration.
| Characteristics | Strengths | weaknesses | Applicability |
Evolve to the actual system. | Stakeholders can have more understanding what is to be built when requirements are fuzzy. | Stakeholders unaware that the prototype is held together haphazardly. | Can be used as a stand-alone process model. |
Help to develop increasingly more complex versions of the software. | User is actively involved in the development. | Long-term maintainability. | It can also be used by end users to describe and prove requirements that developers have not considered. |
Can be animated. | Quicker user feedback is available for better solution. | Time consuming is considered when the documentation. |
Extreme Programming
| Characteristics | Strengths | weaknesses | Applicability |
Pair programming - Ensures quality code. One programmer is thinking whether the approach will work, about testing, or ways to simplify the code while the other programmer writes the code. | XP allows you to focus on coding and avoid needless paperwork and meetings | Difficulty coordinating larger teams. | Extreme Programming (XP) was created in response to problem domains whose requirements change |
Simple design - Keep the design as simple as possible for the moment and don't add features that ar not needed for current functionality. | They can coordinate your schedule easier. XP creates working software faster, and that software tends to have very few defects. | Can result in a never-ending project if not managed properly. | XP was also set up to address the problems of project risk. If that system is a new challenge for your software group the risk is even greater. |
Small releases - There is a short time between versions. | For management, XP delivers working software for less money, and the software is more likely to do what the end users actually want. It cuts risk in a couple ways | Tendency to not document thoroughly. | XP is set up for small groups of programmers. Between 2 and 12, though larger projects of 30 have reported success. Your programmers can be ordinary |
No comments:
Post a Comment