THE PROCESS MODELS
characteristics | strengths | weaknesses | applicability |
*It suggests a systematic, sequential approach to SE, staring from requirements specification going through planning, modeling, construction, testing, deployment and support of the completed system. *Each major activity is marked by milestones and deliverables (artifacts i.e. documents). | *Simple and easy to use/explain to customers. *The staged development cycle enforces discipline: every phase has a defined start and end point, and progress can be conclusively identified (through the use of milestones) | * Real projects rarely follow the linear flow that the model proposes. Although iteration is indirectly allowed, changes are costly, involve significant rework and can cause confusion to project team and involve. *The model requires the customer to state all requirements explicitly, which is often very difficult to achieve. The working software will not available until late in the project, which can be disastrous for late discovery of major defects. Leads to “blocking states” in which some project team | * When requirements are well understood and unlikely to change radically during system development (e.g.: in a well-defined enhancement to an existing system). *When software development technologies and tools are well known. *The work tasks in the project are to proceed to completion in a linear manner. |
characteristics | strengths | weaknesses | applicability |
*Easy the traumatic effect introducing completely new system all at once. *Combine elements of both linear and parallel process flow. *Highest priority requirements need to be settle early | *Early increment can be implemented with few people. *Provide clients flexibility in making their decision. *New project can be stopped at any time after the first cycle. | *The project may be unfinished with the cost and the schedule overruns. *Problem may arise pertaining to system architecture. *The basic requirement is address but supplementary features remain undelivered. | *Core product is well received and additional staff can be added to implement. *Useful when insufficient can be planned to manage technical risk. *Essential part of the rational unified process |
*Spiral Model:
characteristics | strengths | weaknesses | applicability |
*A hybrid model that support process iteration. *Represented as spiral, each loop in the spiral representing a process phase. *Risk is explicitly taken into consideration. | *Risk reduction mechanisms are in place. *Supports iteration and reflects real-world practices. *Systematic approach. | *Hard to estimate time & budget at earlier stage. *Need specific expertise in risk evaluation and reduction for analysis. *Applicable only to large systems because it involve high costs in implementation. | *Internal development of large systems. *For smaller projects, the concept of agile software development is becoming a viable alternative. *Development of space exploration. |
*Prototype model:
Characteristic | Strengths | Weaknesses | Applicability |
* A prototype (early estimation of final software product) is built for user to test by trying them out, as oppose from user just interpreting the design based from description. *The prototype will be rebuilt again for improvement based on user feedback. *This process will be done several times until an acceptable prototype is achieved to produce complete software product. | * Can ensure that the developer, user and customer have a common understanding of what is needed and what is proposed. * Can be used by users to describe and proved requirements that developers have not considered. * Prevents misunderstanding between developer, user and customer that might occur particularly in the requirement analysis phase. | *The focus on a limited prototype can distract developers from properly analyzing the complete project. * Developers have the tendency to build complicated prototype (that in the end they have to throw it away) and thus results in lengthy development time. *Using prototype model is very costly because developers need to build many prototypes before right prototype is attained. | * When the requirements are unclear. *Most beneficial to system that will have many interaction with users. * Especially good for designing human-computer interface |
*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. *Simple design - Keep the design as simple as possible for the moment and don't add features that are not needed for current functionality. *Small releases - There is a short time between versions | *Emphasis on teamwork and communication: As with the TSP, this is very important in improving the performance of just about every software team. *Emphasis on customer involvement: A major help to projects where it can be applied. *Simple design: Though obvious, worth stressing at every opportunity | *As automated acceptance tests rather than specification documents leads to lack of necessary documentation. *Can be very inefficient if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. *Only works with senior-level developers (no chance for junior worker to gain experience). | *Used in Project Management *Used in XP and Web Development *Used for situations when customers may not have a firm idea of what the system should look like. |
No comments:
Post a Comment