Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Generic Software Process Models

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Generic Software Process Models

  1. 1. Introduction to Software Engineering (CSC291) Instructor Humaira Afzal Lecturer 1
  2. 2. Generic software process models • The waterfall model and V model ▫ Separate and distinct phases of specification and development • Evolutionary development ▫ Specification and development are interleaved • Component-based development ▫ The system is assembled from existing components
  3. 3. V Model • A variation of the waterfall model • It is also known as Verification and Validation model. • It is based on association of a testing phase for each corresponding development stage. • For every single phase in the development cycle there is a directly associated testing phase. • This is a highly disciplined model and next phase starts only after completion of the previous phase.
  4. 4. V Model Design
  5. 5. V Model Verification Phases Following are the Verification phases in V-Model Business Requirement Analysis: • This phase involves detailed communication with the customer to understand his expectations and exact requirement. • The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing. System Design: • System design would comprise of understanding and detailing the complete hardware and communication setup for the product under development. • System test plan is developed based on the system design.
  6. 6. V Model Verification Phases Architectural Design: • Based on the technical and financial feasibility the final decision is taken. • System design is broken down further into modules taking up different functionality. • High Level Design (HLD). • The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. • With this information, integration tests can be designed and documented during this stage. Module Design: • In this phase the detailed internal design for all the system modules is specified • Referred to as Low Level Design (LLD). • It is important that the design is compatible with the other modules in the system architecture and the other external systems. • Unit tests can be designed at this stage
  7. 7. V Model Coding Phase • The actual coding of the system modules designed in the design phase is taken up in the Coding phase. • The best suitable programming language is decided based on the system and architectural requirements. • The coding is performed based on the coding guidelines and standards. • The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.
  8. 8. V Model Validation Phases Following are the Validation phases in V-Model: Unit Testing: • Unit tests designed in the module design phase • Unit testing is the testing at code level and helps to eliminate bugs at an early stage Integration Testing: • Integration testing is associated with the architectural design phase. • Integration tests are performed to test the coexistence and communication of the internal modules within the system.
  9. 9. V Model Validation Phases System Testing: • System testing is directly associated with the System design phase. • System tests check the entire system functionality and the communication of the system under development with external systems. • Most of the software and hardware compatibility issues can be uncovered during system test execution. Acceptance Testing: • Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. • Acceptance tests uncover the compatibility issues with the other systems available in the user environment. • It also discovers the non functional issues such as load and performance defects in the actual user environment.
  10. 10. Advantages of V-model • Simple and easy to use. • Testing activities like planning, test designing ,happens well before coding. • Saves a lot of time. • Higher chances of success over the waterfall model. • Works well for small projects where requirements are easily understood.
  11. 11. V-Shaped Model Problems • No iteration of phases • Cannot handle dynamic changes in requirements throughout the life cycle • Requirements are tested too late to make changes without affecting the schedule • No risk analysis
  12. 12. When to use the V-model • The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed. • The V-Shaped model should be chosen when technical resources are available with needed technical expertise. • High confidence of customer is required for choosing the V-Shaped model approach. • Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.
  13. 13. Evolutionary Models Evolutionary Development: • Interleaves the activities of specification, development and validation • Initial system is developed from abstract specification • Then refined with customer input to produce a system that satisfies the customer’ s needs. Two types of evolutionary development 1. Exploratory 2. Prototyping 13
  14. 14. Evolutionary Models Exploratory Model • Systems development method ( SDM ) • Used to design and develop a computer system or product • Consists of planning and trying different designs until one of them seems to be the right one to develop. • This model works best in situations where few, or none, of the system or product requirements are known in detail. • Work with customers to explore their requirements and deliver a final system from an initial outline specification.
  15. 15. There are several steps in the exploratory model • Step 1: A project is launched based on prior best-development efforts and designed to shed light on the system or expected algorithm. • Step 2: A basic model determined before the project begins is employed with information gathered during Step 1, in addition to new project development team ideas. • Step 3: The basic model of Step 2 is tested to determine and reinforce strengths, while improving and resolving weaknesses. • Step 4: Based on Steps 2 and 3, a new model is developed to include any improvements or modifications. • Step 5: The model is tested to evaluate performance and determine future potential improvements or modifications. • Step 6: The testing process is repeated throughout the project to fulfill user satisfaction and predetermined requirements.
  16. 16. 16 Exploratory Model Concurrent Activities Outline Description Initial Version Intermediate Version Final Version Specification Development Validation
  17. 17. Prototyping Model • When a customer defines a set of general objectives for a software but does not identify detailed I/O or processing requirements. • A prototype is built to understand the requirements. • By using this prototype, the client can get an “actual feel” of the system • The interactions with prototype can enable the client to better understand the requirements of the desired system. • Prototyping is an attractive idea for complicated and large systems Consists of 4 iterating phases: ▫ Requirements gathering. ▫ Design and build SW prototype. ▫ Evaluate prototype with customer. ▫ Refine requirements. . Evolutionary Models
  18. 18. 18 Prototyping Model 1 / 4 Listen to Customer 2 Build / Revise prototypes 3 Customer Test-Drives prototypes 1. Requirements gathering. 2. Design and build SW prototype. 3. Evaluate prototype with customer. 4. Refine requirements.
  19. 19. Advantages of Prototype model • Users are actively involved in the development • 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.
  20. 20. Disadvantages of Prototype model • Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans. • Incomplete application may cause application not to be used as the full system was designed • Incomplete problem analysis.
  21. 21. When to use Prototype model • Prototype model should be used when the desired system needs to have a lot of interaction with the end users. • Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model. • They are excellent for designing good human computer interface systems.
  22. 22. Evolutionary development • Problems ▫ Lack of process visibility ▫ Systems are often poorly structured ▫ Special skills (e.g. in languages for rapid prototyping) may be required. • Applicability ▫ For small or medium-size interactive systems; ▫ For parts of large systems (e.g. the user interface); ▫ For short-lifetime systems.
  23. 23. Component-based software engineering • Based on systematic reuse where systems are integrated from existing components. • People working on the project  Know of design or code (similar to that required) Modify them as needed  incorporate them into their system • Process stages ▫ Component analysis ▫ Requirements modification ▫ System design with reuse ▫ Development and integration • This approach is becoming increasingly used as component standards have emerged.
  24. 24. Reuse-oriented development
  25. 25. Component-based software engineering Component analysis • Given the requirement specification • Search is made for components • Usually there is no exact match. Requirement Modification • Requirements are analyzed—using information of discovered components • If modifications are impossible— component analysis activity may be re-entered to search for alternate solution System Design with Reuse • Frame work of system is designed or an existing frame work is reused. Development and integration Software • Existing software /modified and newly developed components are integrated.
  26. 26. Component-based software engineering Advantages • Reduce the amount of software to be developed • Reducing cost and risk • Faster delivery of software Disadvantages • Requirement changes—may lead to a system that does not meet the real needs of users • Control over the system evolution is lost
  27. 27. Process iteration • Change is necessary in all large software projects. • Change? • What to do? • Iteration means earlier stages are reworked in the process for large systems • Iteration can be applied to any of the generic process models • Two (related) process models ▫ Incremental delivery ▫ Spiral development
  28. 28. Incremental delivery “The software specification, design and implementation are broken down into a series of increments that are each developed in turn” • Waterfall model & evolutionary approach? case of change • Incremental delivery—in-between approach • System development is decomposed into increments and each delivers a proportion of the system. • Increments are developed based on their requirement priorities.
  29. 29. Incremental development Validate increment Develop system increment Design system architecture Integrate increment Validate system Define outline requirements Assign requirements to increments System incomplete Final system
  30. 30. Incremental delivery(Steps) 1.Customer identify—services provided by the system 2. Then identify which of the services are most important and which are least important 3. No of delivery increments are then identified with sub-set of the system functionality 4.Highest priority services delivered first 5. Requirements for the first increment are defined in detail 6. First Increment is developed and delivered ..customer can put into service.(Benefit for customer?) 7.During development ….further requirements analysis for later increments can take place
  31. 31. Incremental development advantages • Customer do not have to wait until the entire system is delivered • Customers can use the early increments...gain experience that informs their requirements for later system increments • Lower risk of overall project failure..? • The high priority system services receive more
  32. 32. Incremental development Problems and example...?