1. Eng. Sultan M. Al-Rushdan
Software Engineering
Chapter 2:
Software Development Life Cycle Models
Eng. Sultan M. Al-Rushdan

2. What is Software Life Cycle Model?
Software Life Cycle Model (Process Model) is a descriptive and diagrammatic representation of software life cycle.
Represent all Activities required to transit through its life cycle phases and the order in which they undertake.

3. The Need for a Software Life Cycle Model
A suitable life cycle model for a particular project should be identified.
Without using a life cycle model the development process would not be systematic and disciplined manner.
There must be a clear understanding between teem members about when and what to do.

4. Software Development Process Models
Software Development Process Models are approaches used or employed during development process of software.
Each Process model follow a life cycle to ensure success in software development.

5. Software Development Process Models
Four Essential phases of any Software Development Model
Requirements Elicitation, analysis, specification.
System Design.
Program Implementation.
Testing.

6. Software Development Process Models
Each phase has a phase output. Different projects may interpret these phases differently. Each style is called Life Cycle Model.
Phase
Output
Requirements Elicitation, analysis, specification.
Software Requirement Specification (SRS)
Use Case
System Design.
Design Documents.
Design Classes.
Program Implementation.
Code.
Testing.
Testing Report
Change Requests.

7. Different Software Life Cycle Models
Many Life Cycle Models have been proposed, each have advantages and disadvantages, Like:
Build and Fix model.
Classic Waterfall model.
Iterative Waterfall model.
Prototyping model.
Evolutionary model.
Spiral Model.

8. Build and Fix Model (Ad-hoc model)
This model is the worst model for developing a project, the product is built without proper specification and design steps, it build and modified until the client is satisfied. The cost of using this model is higher that any other model.

9. Waterfall Model
Waterfall Model is an approach that dominated software development for number of years due to its simplicity.
In waterfall model the development steps is divided to number of independent steps.
These steps are performed in sequence one after the other.
Each step is pursued until conclusion before next step can begin.

10. Waterfall Model
Waterfall model is intuitively the most obvious way to develop software. However it is not a practical model (it can not be used in actual development project) It is considered a theoretical way of developing software. But all other life cycle models are essentially derived from waterfall model.

11. Waterfall Model Phases of Waterfall Model: Feasibility Study
Requirement Analysis and specification
Design
Coding and Unit Testing
Integration and System Testing
Maintenance

12. Waterfall Model
Phases of Waterfall Model:

13. Waterfall Model Principles of Waterfall model are:
It is series of steps (like factory production line)
Each step is well defined
Each step creates a definite product
Each product form the basis for the next step
The correctness of each step can be checked(verification or validation)

14. Waterfall Model
1- Feasibility Study: The aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product.
At first project managers of team leaders try to have rough understanding of what is required to be done. They study different input and output data and what kind of processing is needed and what king of constraint exists.

15. Waterfall Model 1- Feasibility Study:
After having and overall understanding of problem they investigate the different possible solutions in term of what resources are needed, what would be the cost of development and what would be the development time.
Based in analysis the best solution is picked. Then determine wither the solution is feasible functionally and technically.

16. Waterfall Model 2- Requirements Analysis and Specification
Requirements are a set of functionalities and constraints that the end user is expect from the system.
The aim of this phase is to understand the exact requirements of the customer and document them properly. This phase consists of two main activities:
Requirements Gathering and analysis.
Requirements specification.

17. Waterfall Model Requirements Gathering and analysis.
The requirements regarding product development is collected by interviewing different types customers employees, these requirement then organized and any contradiction or ambiguities is removed.
Requirements specification.
The customer requirements collected and gathered in the previous activity are organized into Software requirements Specification (SRS) document. The main components of this document are functional requirements, non-functional requirements and goals of implementation.

18. Waterfall Model
3- Design: The goal of design is transform the requirement specification id SRS document into structure that is suitable for Implementation is some Programming Language. Two approaches are available:
Traditional design approach: where first perform a structure analysis of SRS document where detailed structure of problem is examined then followed by structured design.
Object-oriented design approach: where various objects and their relationships in the problem are identified, then perform an object structure process to obtain detailed design.

19. Waterfall Model 4- Coding and Unit Testing
on receiving design document the work is divided in to units/modules and actual coding is started.
The system first developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality.

20. Waterfall Model 5- Integration and System Testing
the system is divided into units which are developed and tested for its functionalities.
These units are integrated into a complete system during integration phase and tested to check if all modules/units coordinate between each other and the system as whole behaves as specification
the goal of system testing is to ensure the system confirm with requirements.

21. Waterfall Model 5- Integration and System Testing
System testing usually consists of three different types of testing activities:
α- testing: it is the system testing performed by development team.
β- testing: it is the system testing performed by friendly set of customers
Acceptance testing: it is the system testing performed by customer himself after the product delivery to determine wither to accept or reject the product.

22. Waterfall Model
6- Maintenance: this phase virtually is never ending phase.
Problems with system development which not found during system testing can come up during practical use. The problems arise from time to time. Maintenance involves:
Correcting Errors (Corrective Maintenance)
Improving the Implementation and enhance its functionalities (Perfective Maintenance)
Porting the system to work in new Environment (Adaptive maintenance)

23. Waterfall Model Strengths of Waterfall Model.
East to understand, easy to use.
Clear project objectives.
Provide structure to inexperienced staff.
Stable project requirements.
Progress of system is measurable.
Helps to plan schedule the project.
Milestones are well understood.
Work well when quality is more important than cost or schedule.

24. Waterfall Model Disadvantages of Waterfall model.
Requires all requirements explicitly, but some times it is difficult for customer to state all requirements explicitly.
Time consuming.
Can’t go backward.
Difficult in responding to change.
Difficult in iteration.

25. Waterfall Model When to use Waterfall Model.
Requirements are very well known.
Product definition is stable.
Technology is understood.
New version of an existing product.
Porting an Existing product to a new platform.

26. Modified Waterfall Life Cycle Model
A strict waterfall model do not go back in stages. To overcome this draw back a waterfall model with feedback was introduced.

27. Modified Waterfall Life Cycle Model

28. Modified Waterfall Life Cycle Model
The major extension in this model over original one are:
It introduces iteration between phases.
Provision for verification and validation of phase output are added.
Provide overlap and feedback between phases.

29. V-shaped Life Cycle Model
V-shaped model or verification and validation model.
Considered as an extension to waterfall model, because it is well structured where different phases progress sequentially.
After coding phase the model bent upward to form V shape to demonstrate a relationship between each phase of development and associated phase of testing.
In this model testing is planed along with project planning and the testing team will have c clear understanding of the system structure, also it helps save time.

30. V-shaped Life Cycle Model

31. V-shaped Life Cycle Model
Verification Phase.
Requirement Analysis: in this phase analyze the needs of the users, collect the requirements. This phase concern with what ideal system should perform. In this phase user requirement document is generated which describe system’s functional, physical, interface, performance, data, security requirements. This document is reviewed by user because it is the basis of user acceptance test
System Design: user requirement document are reviewed by engineers to find the possibilities and techniques by which the user requirements can be implemented. A solution is found, the software specification document is generated which is a blueprint for development phase which contain general system organization, menu structures, data structures, database ER model etc. also the document for system testing are prepared in this phase.

32. V-shaped Life Cycle Model
Verification Phase.
Architecture Design: or high level design. In this phase a system design which contains modules and brief functionality of each module, their interface relationships, dependencies, database table, architecture diagrams, technology details etc. the integration system design is carried out in this phase.
Module Design: or low-level design. The system is broken in to small units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specification will contain a detailed functional logic of the module, in pseudo code, database tables, with all elements type and size, all interfaces details with complete API references, all dependency issues, error messages and inputs and outputs of the module. The unit test design is developed in this stage.

33. V-shaped Life Cycle Model
Validation Phase:
Unit Testing: the first stage of dynamic testing process. It involves analysis of the written code with the intention of eliminating errors. It also verify that the code is efficient. Test is usually white box test based on unit test document generated during module design phase.
Integration Testing: the separate modules will be tested together to expose faults in interfaces and in interaction between integrated components. Testing is usually black box, and it is done using integration test design prepared during the architectural design.
System Testing: will compare system specification against the actual system. This test is derived from system design document, some time system design is automated using testing tools.

34. V-shaped Life Cycle Model
Validation Phase:
User Acceptance Test: the goals of this test are:
To determine wither the system satisfies its acceptance criteria or not
To enable the customer to determine whether to accept the system or not
To test the software in the “real world” by intended audience.

35. V-shaped Life Cycle Model
Validation Phase:
Procedures for conducting acceptance testing
Define Acceptance criteria:
Functionality requirements.
Performance requirement.
Interface quality requirements.
Overall software quality requirements.
Develop an acceptance plan:
Project description.
User responsibilities.
Acceptance description.
Execute the acceptance test plan.

36. V-shaped Life Cycle Model
Advantages of V-shaped Model:
Emphasis planning for verification and validation of the product in early stages.
Each deliverable must be testable.
Project management can track progress by milestones.
Easy to use.
Disadvantages of V-shaped Model:
Does not easily handle concurrent events.
Does not handle iteration of phases.
Does not easily handle dynamic change in requirements.
Does not contain risk analysis activity

37. V-shaped Life Cycle Model
When to use the V-shaped Module.
Excellent choice for systems that required high reliability such as hospital patient control application.
All requirement are known upfront
When modification of requirement are beyond analysis phase.
Solution and technology are known.
The biggest disadvantage of V-shaped Model that it is rigid and the least flexible. If any change occur in midway not only the requirements documents must be changed but also all test documents.
But V-shaped Module is the most favorable as it is simple and easy to use

38. Incremental Process Model
Incremental model is a model where the model is designed implemented and tested incrementally(a little more is added every time) until the product is finished.
It involves both development and maintenance.
The product is considered finished when it satisfies all requirements.

39. Incremental Process Model
Does not require start development with full specification of requirements.
Development begin by specifying and implemented part of the software which then can be reviewed to identify further requirements.
This process is then repeated.

40. Incremental Process Model

41. Incremental Process Model
A Requirement Phase: in which the requirements for the software are gathered and analyzed, iteration should eventually result a complete and final requirements.
A Design Phase: in which the software solution to meet requirements is designed, this may be initial design or an extension of existing design.

42. Incremental Process Model
An Implementation and Testing Phase: when the software is coded, Integrated and Tested.
A Review Phase: in which the software is evaluated, the current requirements are reviewed and change and additions to requirements proposed.

43. Incremental Process Model
For each cycle a decision must be made if the changes in software to be discarded or kept as a starting point to a new cycle, eventually a point will be reached where the requirements are complete and fulfilled.

44. Incremental Process Model

45. Incremental Process Model
In incremental Model the product is recomposed into modules each can be developed and delivered to customer when it is complete which will reduce the development time.

46. Incremental Process Model
Advantages:
Generate working software quickly and early.
More flexible-less costly to change scope and requirements
Easier to test and debug smaller iterations
Easier to manage risk because risky part are identified and handled during its iteration.
Limited number of persons can be put on project.

47. Incremental Process Model
Disadvantages:
Each phase of an iteration is rigid and not overlapped each other.
Model require well-defined project planning schedule to distinguish the work.
Problem may rise partitioned during system development.
Product is delivered in parts so the total development cost is higher.
Testing of modules results in overhead and increase costs.

48. Rapid Application Development (RAD) Model
Is a concept that software product can be developed faster and of higher quality through:
Gathering requirements using workshops or focus groups.
Prototyping and early reiterative user testing of design.
The reuse of software components.
A rigidly paced schedule that defers design improvement to the next product version.
Less formality in reviews and other team communication.

49. Rapid Application Development (RAD) Model
There are some product that provide tools for RAD which include:
Requirement gathering tools.
Prototyping tools.
Computer Added Software Engineering (CASE) tools.
Language development Environments.
Groupware for communication among development team members.
Testing tools.

50. Rapid Application Development (RAD) Model
RAD embraces OOP methodology so it foster software reuse.
RAD is sequential development model.
RAD contains extremely short life cycle.

51. Rapid Application Development (RAD) Model
RAD embraces OOP methodology so it foster software reuse.
RAD is sequential development model.
RAD contains extremely short life cycle.
RAD model is a high speed adaptation of linear sequential model.
RAD is achieved by using component based construction.
If requirement are well understood and project scope is constraint RAD enable the developers to create fully functional system in 60 to 90 days.

52. Rapid Application Development (RAD) Model

53. Rapid Application Development (RAD) Model
RAD Model Phases.
Business Modeling: The information flow among business functions is defined by answering question like what information drives the business process, what information is generated, who generate it, where does information go, who process it and so on.
Data Modeling: the information collected from business modeling is refined into a set of data objects (entities). The attributes are identified, and the relationships between entities is defined.

54. Rapid Application Development(RAD) Model
RAD Model Phases.
Process Modeling: Data object define in data modeling phase is transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving data object.
Application Generation: automated tools are used to facilitate construction of the software.
Testing and Turn over: since RAD emphasis reuse so many software components have been tested and that reduce overall testing time, but new components and all interfaces must be tested.

55. Rapid Application Development(RAD) Model
Advantages:
Less development time due powerful tools.
High customer satisfaction because customer is involved in all stages of development.
Feedback from customer/client as available at initial stages
It uses reusable components to reduce the life cycle time.
All function are modularized so it is easy to work with.

56. Rapid Application Development(RAD) Model
Disadvantages:
For large project RAD require highly skilled engineer in the team.
Absence of reusable components can lead to failure of the project( project may not complete in time)
If it is difficult to modularize the project then RAD may not work well.
RAD is not appropriate when technical risks are high this occurs when new application make heavy use of new technology or require high degree of interoperability with existing computer programs.

57. Rapid Application Development(RAD) Model
When to use RAD model
Reasonable well known requirements.
User involvement throughout the life cycle.
Project can be time-boxed.
Functionality delivered in incremens.
High performance not required.
Low technical risk.
System can be modularized.

58. Evolutionary Software Process Model
Evolutionary Model take the concept of evolution into software engineering( i.e this model is iterative)
Software are build in a manner that enable the developer to develop increasingly more complex version of software.
For specification based approach the main difficulty that customers find it difficult to articulate their requirement in advance and their requirement change during development process, evolutionary model integrate specification, design, and implementation.

59. Evolutionary Software Process Model
The stages in evolutionary approach are:
Formulate n outline of the system requirements, that neither complete nor consistence but should give developer guidance to what system should do.
Develop system as rapidly as possible, based on this outline specification.
Evaluate this system with user and modify the system until the system meets users’ needs which involves modifying the initial functionality of the system and add new functionality as required.

60. Evolutionary Software Process Model

61. Evolutionary Software Process Model
Evolutionary model is the most appropriate approach for interactive systems with a significant user interface components and for innovative systems(for example AI systems) where requirements cannot be anticipated
Evolutionary model also suitable for small and medium sized business system development.
The main idea of evolutionary model is to keep customer involve in development process. The developers gets ideas from users and make a prototype, expose this prototype to customer and get more refined requirements, and after several version final version is produced

62. Evolutionary Software Process Model
Evolutionary model is the most appropriate approach for interactive systems with a significant user interface components and for innovative systems(for example AI systems) where requirements cannot be anticipated
Evolutionary model also suitable for small and medium sized business system development.
The main idea of evolutionary model is to keep customer involve in development process. The developers gets ideas from users and make a prototype, expose this prototype to customer and get more refined requirements, and after several version final version is produced

63. Evolutionary Software Process Model
Types of Evolutionary development:
Exploratory Development: where the development is started from the requirements then produce initial version that fulfill the requirements, then show it to customer then ask them to add some features, requirements. Exploratory development is used to work with customers to explore requirement and develop a final version.
Throwaway Prototyping: in this type the goal is to understand the customer requirements, and to develop better requirements definition for the system. Developers create a prototype base on a vague requirements, show it to customer to check it and explain new requirements. Then use these information to develop new prototype.

64. Evolutionary Software Process Model
Problems in Evolutionary Development:
Development process is not visible, and it is not easy to develop documentation for each prototype as they are created rapidly, creating documentation for each prototype is not cost effective.
Due to continuous change in software coding and structure become poor that it become costly and difficult to evolution a system.
It has end user focus so the critical organization requirement such as interoperability may not given sufficient priority.

65. Prototype Model
The goal of prototype model is to overcome the limitation of waterfall model. In prototype model a throwaway prototype is build to understand user requirements, the prototype is developed based on the current known requirements, development goes through design, coding and testing but not very formally and thoroughly then the client examine the prototype to better understand the requirements.

66. Prototype Model
Prototype model is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determine the requirements.
It is an efficient method to demonstrate the feasibility of a certain approach.

67. Prototype Model

68. Prototype Model Steps for Prototyping Model
Identify the user basic requirements: in this stage developers work with users to understand users’ basic needs and requirements with respect to output of the system. The developers establishes user expectation, estimate the cost of developing working prototype, determine data elements required and determine data availability.

69. Prototype Model Steps for Prototyping Model
Develop the initial/working prototype: the developers develop an initial working prototype that meets the users’ basic requirements, the prototype perform only the basic functions. Then the prototype is delivered to user for evaluation.

70. Prototype Model Steps for Prototyping Model
Use the prototype for further refinements: in this step user will receive the initial prototype which he now put in use, the prototype help the user to have experience of the system and determine what specification, requirements are needed and decide what change to be made.

71. Prototype Model Steps for Prototyping Model
Revise and enhance prototype: the developers take notes from user about changes, enhancements and refinements that needs to be made. Then the prototype in revised and return to user and step 3 and 4 can take place again until the customer is satisfied

72. Prototype Model

73. Prototype Model Types of Prototypes:
Throwaway prototype: refer to creation of a model that will eventually be discarded rather than become a part of finally delivered software. The developers develop a working prototype for various parts of the system at a very early stage, this model is informal and quick and it helps the user and developers to re-examine and clarify their requirements

74. Prototype Model

75. Prototype Model Types of Prototypes:
Evolutionary prototype: the main goal is to build a very robust prototype in a structured manner and constantly refine it. The evolutionary model form the heart of the new system, and the improvements and new requirements will be built when developing the system. Using Evolutionary prototype the system is continually refined and rebuilt.

76. Prototype Model

77. Prototype Model Evolutionary prototype :
Allows the development team to add features, or make changes that couldn’t be conceived during that requirements and design phases.
Evolutionary prototype have an advantage over throwaway prototype in that they are functional systems.

78. Prototype Model Types of Prototypes:
Incremental prototype: in this model the final product is build as a separate prototypes. At the end the separate prototypes are being merged in an overall design.

79. Prototype Model

80. Prototype Model Advantages of prototyping:
Users are actively involved in the development
It provide a better system to user.
Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.
Errors can be detected much earlier.
Quicker user feedback is available leading to better solutions.
Interactive with prototype increase awareness of needed functionalities.

81. Prototype Model Advantages of prototyping:
Ability to tryout ideas without large cost
Lower overall costs when requirement change frequently.
Ability to get functional system it hand of users quickly.
Reduces time and cost as the defects can be detected much earlier.
Utilize scarce human resources.

82. Prototype Model Disadvantages of prototyping:
Risk of insufficient requirement analysis owing to too much dependency on the prototype.
Users may get confused in the prototypes and actual systems.
Developers may try to reuse the existing prototypes to build the actual system, even when it is not technically feasible.
Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.
The effort invested in building prototypes may be too much if it is not monitored properly.

83. The Spiral Model
Spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.
Using the spiral model software is developed in a series of incremental releases.
During early iterations the incremental release might be a paper model or prototype.
During later iteration increasingly more complete version of the system is produced
Spiral model is intended for large, expensive and complicated projects.

84. The Spiral Model
Spiral model is divided into number of activities called task regions:
Customer communication: tasks required establishing effective communication between developer and customer.
Planning: tasks required defining resources, timelines and other project related information.
Risk analysis: tasks required to assess both technical and management risks.

85. The Spiral Model
Spiral model is divided into number of activities called task regions:
Engineering: tasks required building one or more representations of the application.
Construction and release: tasks required to construct, test, install, and provide user support.
Customer evaluation: tasks required to obtain customer feedback based on an evaluation of the software.

86. The Spiral Model

87. The Spiral Model
The steps in spiral model can be generalized as following:
The new system requirements are defined in as much detail as possible.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design.
A second prototype is evolved by a fourfold procedure:
evaluating the first prototype in terms of its strengths, weaknesses, and risks.
defining the requirements of the second prototype.
planning and designing the second prototype.
constructing and testing the second prototype.

88. The Spiral Model
The steps in spiral model can be generalized as following:
At the customer's option, the entire project can be aborted if the risk is too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment.
The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it.
The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

89. The Spiral Model
The steps in spiral model can be generalized as following:
The final system is constructed, based on the refined prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

90. The Spiral Model

91. The Spiral Model
Quadrant 1 - Determine objectives, alternatives and constraints. Quadrant 2 - Evaluate alternatives, identify and resolve risks Quadrant 3 - Develop next-level product Quadrant 4 - Plan next phase

92. The Spiral Model The advantages are:−
Provides early indication of the risks, without involving much cost.
Users can view the system early because of the rapid prototyping tools.
Critical high-risk functions are developed first.
The design does not have to be perfect.
Users can be closely involved in all lifecycle steps.
Early and frequent feedback from users.
Cumulative costs assessed frequently.

93. The Spiral Model The disadvantages are: −
Time spent in planning, resetting objectives, doing risk analysis and prototyping may be an overhead.
Time spent for evaluating risks can be too large for small or low-risk projects.
Spiral model is complex to understand for new team members.
Risk assessment expertise is required.
Spiral may continue indefinitely.
Developers must be reassigned during non-development phase activities.

94. The Spiral Model When to Use Spiral Model?
Creation of a prototype is appropriate.
Risk evaluation is important.
A project is of medium to high-risk.
Users are unsure of their needs.
Requirements are complex.
Product-line is new.
Significant changes are expected during exploration.
Long-term project commitment unwise because of potential business changes.

95. Win-Win Spiral Model
Win-Win Spiral Process Model based on Theory W, which is a management theory "based on making winners of all of the systems key stakeholders as a necessary and sufficient condition for project success.“
win win spiral model is an adaptation of spiral model where emphasis is on involvement of the client in product life cycle.
Win win means the client get the product that satisfies the majority of his needs and the developer wins by working to realistic and achievable budget and deadlines

96. Win-Win Spiral Model

97. Win-Win Spiral Model Win win spiral model activities:
Identification of the system stakeholder.
Determine the stakeholder win condition.
Reconcile win condition. Establish next level objective, constraints and alternatives.
Evaluate product and process alternatives and resolve risks.
Define next level of product and process, including partitioning.
Validate product and process definitions.
Review commitment.

98. Object Oriented Life Cycle Model
object oriented development requires that object-oriented techniques be used during the analysis and implementation of the system
What object of the system are.
How they behave over Time or in response to event.
What responsibilities object have.
What relationships an object have with other objects.

99. Object Oriented Life Cycle Model
Characteristics of Object Design:
Software objects represent a real world object.
Object consists of classes and classes can inherit other classes which promote software reuse.

100. Object Oriented Life Cycle Model
Phases of Object Oriented Software Life Cycle Model:
Object Oriented Requirements Analysis
Object Oriented Analysis
Object Oriented Design
Object Oriented Programming

101. Object Oriented Life Cycle Model
Advantages of Object Oriented Software Life Cycle Model:
OOD closely represent the problem domain so it is easier to produce and understand design.
Object are immune to requirement change, so the changes are easier
Encourage more re-use therefore reduce development cost and time.
OOD is more natural and it provide nice structures for thinking and abstracting and leads to modular design.

102. Comparison and Selection of Life Cycle Model
Selection of life cycle model is based on:
Requirements.
Development Team.
Users.
Project Type and Associated Risk.

103. Comparison and Selection of Life Cycle Model
Based on characteristics of requirements

104. Comparison and Selection of Life Cycle Model
Based on status of development team

105. Comparison and Selection of Life Cycle Model
Based on User’s Participation.

106. Comparison and Selection of Life Cycle Model
Based on Type of Project Associated Risk

107. Chapter 2:
END of chapter