1. Software Process Models

2. Process model or software engineering paradigm – development strategy encompassing Process Method Tool Generic phases Chosen based on – Nature of the project and application – Methods and tools – Controls and deliverables that are required

3. Software Process Models S/W development is characterized as a problem solving loop – Status quo – Problem definition – Technical development – Solution integration

4. Software Process Models Problem Definition Technical Development Solution Integration Status Quo Phases of a problem solving loop Current state of affairs Specific problem to be solved Application of technology Deliver result

5. Software Process Models Problem solving loop works at different levels of resolution – Macro level – Entire Application – Mid level – Program Components – Micro level – Code Level

6. Software Process Models Status quo Status quo Status quo Status Quo The phases within phases of the problem solving loop

7. Software Process Models The Linear Sequential/Waterfall Model The Incremental Models – The Incremental model – The RAD Model Evolutionary Software Process Models – The Prototyping Model – Spiral Model – The WINWIN Spiral Model – The Concurrent Development Model Specialized Process Models – Component Based Development – The Formal Methods Model – Aspect Oriented Software Development The Fourth Generation Techniques

8. Linear Sequential Model Also called Classic Life cycle / Waterfall Model Suggest a systematic, sequential approach Begins at system level Progresses through analysis, design, coding, testing and support

9. Linear Sequential Model Communication Project initiation Requirements gathering Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking Planning Estimating Scheduling Tracking Modeling Analysis Design Modeling Analysis Design Construction Code Test Construction Code Test Deployment Delivery Support Feedback Deployment Delivery Support Feedback

10. Linear Sequential Model System/Information Engineering – Software is a part of a large system Establish requirements for all system elements Allocate subset of these requirements to software – Essential because s/w interacts with other elements such as h/w, people, and databases – Requirements gathered at system level, strategic business level and at the business area level

11. Linear Sequential Model Software Requirement Analysis – Requirements focused specifically on software – Nature of software Understand the information domain for the software, required function, behavior, performance and interface – Document requirements and review with customers

12. Linear Sequential Model Design – Multi step process focusing Data structure, software architecture, interface representations, and procedural detail – Translates requirements into representation of s/w that can be assessed for quality before doing – Design is documented, becomes part of SCM

13. Linear Sequential Model Code Generation – Design translated to machine-readable form – Can be accomplished mechanistically Testing – Focuses on the logical internals and on the functional externals Support/Maintenance – Software will undergo change Errors have been encountered – Software must be adapted – Customer requires functional or performance enhancements

14. Linear Sequential Model Suitability - When a set of high quality, stable user requirements exists Problems – Requires complete knowledge of all requirements at early stages of the life cycle – Customers do not state all requirements explicitly – Lack of flexibility to accept change to requirements – Commitment of all financial and other resources up front – Real projects rarely follow the sequential flow Customer must have patience

15. Incremental Process Models Incremental process models – Requirements are well defined – Compelling need to provide core functionality to users quickly – Produce software in increments Models – Incremental model – The RAD model

16. The Incremental Model Combines elements of the linear sequential model and iterative philosophy of prototyping Applies linear sequences in a staggered fashion as calendar time progresses Each sequence produces a deliverable increment of the s/w The first increment - Core product Deliverables are operational product Useful when staffing is unavailable for a complete implementation Increments can be planned to manage technical risks

17. The Incremental Model

18. The RAD Model Rapid Application Development Model A linear sequential software development process model Emphasizes an extremely short development cycle Is a “high-speed” adaptation of the Waterfall Model – using a component based construction approach – using “RAD tools” If requirements are well understood and the project scope is limited, the RAD process enables a development team to create a “fully functional system” within very short time periods.

19. The RAD model

20. The RAD Model Suitability - If a business application can be modularized and each major function to be completed in say, less than 3 months, it is a candidate for RAD. Each major function can be addressed by a separate RAD team and then integrated to form a whole application. Not suitable – If system cannot be properly modularized – If high performance is an issue – If the technical risks are high – If the extent of interoperability of the proposed application with existing programs is significant

21. The RAD Model Disadvantages – Requires sufficient human resources – Developers and customers must be committed to rapid fire activities

22. Evolutionary Process Models Iterative models – Characterized in a manner that enables developing increasingly more complete versions of the software Prototyping Spiral Model Concurrent Development Model

23. The Prototyping Model Customer does not identify detailed input, processing or output requirements Developer is unsure of the efficiency of an algorithm, adaptability of the operating system, form of human/machine interaction should take. Best approach is prototyping paradigm – mechanism for identifying software requirements

24. The Prototyping Model Begins with requirement gathering (whatever known) A quick design Construct a prototype based on design Evaluation of prototype by customer/user Refine requirements for the software Iterate If a working prototype is built, working programs are generated

25. The Prototyping Model

26. Prototype serves as the “first system” – Throw away Problems – Software development management relents – Implementation compromises are made Define rules of the game at the beginning

27. The Spiral Model Proposed by Boehm Couples iterative nature of prototyping with controlled and systematic aspects of the linear sequential model. Software is developed in a series of incremental releases

28. The Spiral Model Framework activities – Task regions – Customer communication – Planning – Modeling – Construction – Deployment Each region is populated by a set of work tasks – Task Set Team moves around the spiral in a clockwise direction First circuit – product specification Subsequent passes – develop prototype and more sophisticated versions of the software

29. The Spiral Model

30. Classical process models end when s/w is delivered Spiral model can be adapted to apply throughout the life of the computer Alternate view of the spiral model – project entry point axis Each cube represent the starting point for different types of projects – Concept development project – New development project – Product enhancement

31. The Spiral Model Suitability - For large-scale systems Problems – Difficult to convince customers that the evolutionary approach is controllable – Demands risk assessment expertise – Not popularly used

32. The WINWIN Spiral Model Customer wins by getting the system or product that satisfies the majority of the customer’s need and the developer wins by working to realistic and achievable budgets and deadlines Set of negotiation activities at the beginning of each pass around the spiral – Identification of the system or subsystem’s key “stakeholders” – Determination of the stakeholders “win conditions” – Negotiation of the stake holders win conditions to reconcile them into a set of win-win conditions for all concerned

33. The Concurrent Development Model Concurrent Engineering Series of major technical activities, tasks and associated states Used as the paradigm for the development of the client/server application Defines two dimension – System dimension System, assembly, use – Component dimension Design, realization Concurrency – System and component activities occur simultaneously

34. The Concurrent Development Model

35. Specialized Process Models Used when a narrowly defined software engineering approach is chosen – Component Based Development – Formal Methods model – Aspect-oriented software Development

36. The Component Assembly Model Object Oriented Programming provide technical framework for component based process model OOP emphasizes creation of classes Properly designed and implemented classes are reusable across different applications CBD incorporates many of the characteristics of spiral model It is evolutionary in nature

37. The Component Assembly Model

38. CBD leads to s/w reuse Benefits – 70% reduction in development cycle time – 84% reduction in project cost – Productivity index 26.2 compared to industry norm of 16.9

39. Formal Methods Set of activities leading to formal mathematical specification of computer software Rigorous mathematical representation of requirements Provides basis for automatic verification test generation Variation – Cleanroom software engineering

40. Formal Methods Formal Methods provide a mechanism for eliminating – Ambiguity – Incompleteness – Inconsistency Through mathematical analysis.

41. Formal Methods Advantage – Defect free software Disadvantage – Time consuming and expensive – Extensive training is required – Difficult to use the models as a communication mechanism for technically unsophisticated customers

42. Fourth Generation Techniques Encompasses a broad array of software tools – Enables the software engineer to specify some characteristic of software at a high level. – Automatically generates source code based on the developer's specification.

43. Fourth Generation Techniques Tools – Nonprocedural language for database query – Report generation – Data manipulation – Screen interaction and definition code generation – High-level graphics capability – Spreadsheet capability – Automated generation of HTML etc.

44. Fourth Generation Techniques 4GT begins with requirements gathering Small applications – Move directly from requirements to implementation using a nonprocedural 4GL Large applications – Develop a design strategy – Use of 4GT without design can cause poor Quality Maintainability Customer acceptance

45. Fourth Generation Techniques Current state of 4GT approaches – Offers a credible solution to many software problems – Development time is reduced for small and intermediate application – Demands much more analysis, design and testing to achieve substantial time savings that results from the elimination of coding

46. Aspect Oriented Software Development New software engineering paradigm Provides a process and approach for defining specifying, designing and constructing aspects – Mechanism for localizing the expression of a crosscutting concern Concerns- customer required properties or areas of technical interest Crosscutting concern – concern span the entire architecture and when cut across multiple system functions features and information

47. Case Study List the appropriate process model for the following situations. List your reasons for choosing the model. Scenario : – A hospital requires a laboratory management system and has contacted your firm. You have 20 programmers out of which 15 are busy with other projects for the time being. The hospital intends to acquire laboratory equipment, which they want to interface with the computer system. The annual evaluation of the hospital is due soon, in which computerization initiatives are appreciated.

48. Case Study Answer – Incremental process model – Reasons Small no. of people are available Laboratory equipment may become available at a later stage A core version may be developed for evaluation

49. Case study Scenario : – The owner of a video shop contacted you to develop a system to keep track of videos and rentals. He feels that with the growing number of customers, such a system will greatly help in managing accounts and providing better customer service