1. Chapter :Software Process Model

2. Chapter 4: Topic Covered About software process model Build and Fix Model Why Models are needed? ◦Process as a "black box“ & Problem ◦Process as a “white box“ & Advantage Prescriptive Model Waterfall Model or Linear Sequential Incremental Process Models ◦ Incremental Model ◦ RAD Model Evolutionary Process Models ◦Prototyping ◦Spiral Model ◦Concurrent Development Model ◦Fourth Generation Techniques (4GT) ◦Component based development (CBD)

3. Software process model Process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software. ◦Degree of iteration, organization of the work to be done Process models are not perfect, but provide roadmap for software engineering work. Software models provide stability, control, and organization to a process that if not managed can easily get out of control ◦Yet flexibility (agility) is important! Software process models are adapted to meet the needs of software engineers and managers for a specific project. ◦Customers are important

4. Build and Fix Model

5. The earlier approach Product is constructed without specification or any attempt at design. developers simply build a product that is reworked as many times as necessary to satisfy the client. model may work for small projects but is totally unsatisfactory for products of any reasonable size. Maintenance is high. Source of difficulties and deficiencies ◦impossible to predict ◦impossible to manage

6. Why Models are needed? Symptoms of inadequacy: the software crisis ◦scheduled time and cost exceeded ◦user expectations not met ◦poor quality

7. Process as a "black box" Quality? Uncertain / Incomplete requirement In the beginning

8. Problems The assumption is that requirements can be fully understood prior to development Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately the assumption almost never holds

9. Process as a "white box"

10. Advantages Reduce risks by improving visibility Allow project changes as the project progresses ◦based on feedback from the customer

11. Prescriptive Model Prescriptive process models advocate an orderly approach to software engineering ◦Organize framework activities in a certain order Process framework activity with set of software engineering actions. Each action in terms of a task set that identifies the work to be accomplished to meet the goals. The resultant process model should be adapted to accommodate the nature of the specific project, people doing the work, and the work environment. Software engineer choose process framework that includes activities like; ◦Communication ◦Planning ◦Modeling ◦Construction ◦Deployment

12. 12 Generic Process Framework Communication ◦Involves communication among the customer and other stake holders; encompasses requirements gathering Planning ◦Establishes a plan for software engineering work; addresses technical tasks, resources, work products, and work schedule Modeling (Analyze, Design) ◦Encompasses the creation of models to better understand the requirements and the design Construction (Code, Test) ◦Combines code generation and testing to uncover errors Deployment ◦Involves delivery of software to the customer for evaluation and feedback

13. 13 Modeling: Software Requirements Analysis Helps software engineers to better understand the problem they will work to solve Encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the software Uses a combination of text and diagrams to depict requirements for data, function, and behavior ◦Provides a relatively easy way to understand and review requirements for correctness, completeness and consistency

14. 14 Modeling: Software Design Brings together customer requirements, business needs, and technical considerations to form the “blueprint” for a product Creates a model that that provides detail about software data structures, software architecture, interfaces, and components that are necessary to implement the system Architectural design ◦Represents the structure of data and program components that are required to build the software ◦Considers the architectural style, the structure and properties of components that constitute the system, and interrelationships that occur among all architectural components User Interface Design ◦Creates an effective communication medium between a human and a computer ◦Identifies interface objects and actions and then creates a screen layout that forms the basis for a user interface prototype Component-level Design ◦Defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component

16. Prescriptive Model Defines a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software Strive for structure and order Called as “Prescriptive” because it recommend a set of process elements, activities, action task, work product & quality assurance and change control mechanisms. All elements are inter related to one another (called workflow).

17. 17 Waterfall Model Oldest software lifecycle model and best understood by upper management Used when requirements are well understood and risk is low Work flow is in a linear (i.e., sequential) fashion Used often with well-defined adaptations or enhancements to current software

18. Waterfall Model or Classic Life Cycle

19. V-model  Variation of waterfall model  Depicts quality assurance activities associates with each stage

20. Waterfall Model or Classic Life Cycle Requirement Analysis and Definition: What - The systems services, constraints and goals are defined by customers. Scheduling tracking - ◦Assessing progress against the project plan. ◦Require action to maintain schedule. System and Software Design: How –It establishes an overall system architecture. Software design involves fundamental system abstractions and their relationships. Integration and system testing: The individual program unit or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer. Operation and Maintenance: Normally this is the longest phase of the software life cycle. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life-cycle.

21. Limitations of the waterfall model 21  Requirements cannot change during development  Complete a given stage before moving on to the next stage  Does not account for the fact that requirements constantly change.  It also means that customers can not use anything until the entire system is complete.  Blocking states: some team members wait for others to finish their tasks  Once the product is produced, everything else is maintenance.  Surprises at the end are very expensive  Only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.

22. Waterfall Problems 1. Real projects rarely follow the sequential model. 2. Difficult for the customer to state all the requirement explicitly upfront 3. Assumes patience from customer - working version of program will not available until very late in the process.

23. 23 Incremental Model (Description) Used when requirements are well understood Multiple independent deliveries are identified Work flow is in a linear (i.e., sequential) fashion within an increment and is staggered between increments Iterative in nature; focuses on an operational product with each increment Provides a needed set of functionality sooner while delivering optional components later Useful also when staffing is too short for a full-scale development

24. Incremental Process Model C- Communication P - Planning M – Modeling C - Construction D - Deployment Delivers software in small but usable pieces, each piece builds on pieces already delivered

25. The Incremental Model Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. First Increment is often core product ◦Includes basic requirement ◦Many supplementary features (known & unknown) remain undelivered A plan of next increment is prepared ◦Modifications of the first increment ◦Additional features of the first increment It is particularly useful when enough staffing is not available for the whole project Increment can be planned to manage technical risks. Incremental model focus more on delivery of an operational product with each increment.

26. The Incremental Model User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing.

27. Rapid Application Development (RAD) Model Makes heavy use of reusable software components with an extremely short development cycle

28. RAD model Communication – to understand business problem. Planning – multiple s/w teams works in parallel on diff. system. Modeling – ◦Business modeling – Information flow among business is working. Ex. What kind of information drives? Who is going to generate information? From where information comes and goes? ◦Data modeling – Information refined into set of data objects that are needed to support business. ◦Process modeling – Data object transforms to information flow necessary to implement business.

29. Construction – Make use of pre-existing software component. Deployment – Deliver to customer basis for subsequent iteration. RAD model emphasize a short development cycle. “High speed” edition of linear sequential model. If requirement are well understood and project scope is constrained enables development team to create “ fully functional system” within a very short time period.

30. RAD Model If application is modularized (“Scalable Scope”), each major function to be completed in less than three months. Each major function can be addressed by a separate team and then integrated to form a whole. Drawback: For large but scalable projects ◦RAD requires sufficient human resources Projects fail if developers and customers are not committed in a much shortened time-frame Problematic if system can not be modularized Not appropriate when technical risks are high ( heavy use of new technology)

32. Evolutionary Process Model  Software system evolves over time as requirements often change as development proceeds. Thus, a straight line to a complete end product is not possible. However, a limited version must be delivered to meet competitive pressure.  Usually a set of core product or system requirements is well understood, but the details and extension have yet to be defined.  You need a process model that has been explicitly designed to accommodate a product that evolved over time.  It is iterative that enables you to develop increasingly more complete version of the software.

33. Evolutionary Process Model  Produce an increasingly more complete version of the software with each iteration.  Evolutionary Models are iterative.  An evolutionary process flow executes the activities in a circular manner. Each circuit leads to a more complete version of the software.  Evolutionary models are: ◦Prototyping ◦Spiral Model ◦Concurrent Development Model ◦Fourth Generation Techniques (4GT)

34. 34 Prototyping Model  Follows an evolutionary and iterative approach  Used when requirements are not well understood  Serves as a mechanism for identifying software requirements  Focuses on those aspects of the software that are visible to the customer/user  Feedback is used to refine the prototype

35. Evolutionary Process Models : Prototyping

36. Prototyping Best approach when: ◦Objectives defines by customer are general but does not have details like input, processing, or output requirement. ◦Developer may be unsure of the efficiency of an algorithm, O.S., or the form that human machine interaction should take. It can be used as standalone process model. Model assist software engineer and customer to better understand what is to be built when requirement are fuzzy. Prototyping start with communication, between a customer and software engineer to define overall objective, identify requirements and make a boundary. Going ahead, planned quickly and modeling (software layout visible to the customers/end- user) occurs.

37. Prototyping (cont..)  Quick design leads to prototype construction.  Prototype is deployed and evaluated by the customer/user.  Feedback from customer/end user will refine requirement and that is how iteration occurs during prototype to satisfy the needs of the customer.  Prototype can serve as “the first system”.  Both customers and developers like the prototyping paradigm. Customer/End user gets a feel for the actual system Developer get to build something immediately.

38. 38 Potential Problems of Prototyping Model The customer sees a "working version" of the software, wants to stop all development and then buy the prototype after a "few fixes" are made ◦software quality suffers as a result. Developers often make implementation compromises to get the software running quickly (e.g., language choice, user interface, operating system choice, inefficient algorithms) Lesson learned ◦Customer and developer both must be agree that the prototype is built to serve as a mechanism for defining requirement. ◦Define the rules up front on the final disposition of the prototype before it is built ◦In most circumstances, plan to discard the prototype and engineer the actual production software with a goal toward quality

39. 39 Spiral Model Invented by Dr. Barry Boehm in 1988 while working at TRW Follows an evolutionary approach Used when requirements are not well understood and risks are high Inner spirals focus on identifying software requirements and project risks; may also incorporate prototyping Outer spirals take on a classical waterfall approach after requirements have been defined, but permit iterative growth of the software Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order to react to risk determinations Requires considerable expertise in risk assessment Serves as a realistic model for large-scale software development

40. Evolutionary Model: Spiral Model

41. Spiral Model  Couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model It provide potential for rapid development of increasingly more complete version of the software. Using spiral, software developed in as series of evolutionary release. ◦Early iteration, release might be on paper or prototype. ◦Later iteration, more complete version of software. Divided into framework activities (C,P,M,C,D). Each activity represent one segment. Evolutionary process begins in a clockwise direction, beginning at the center risk. First circuit around the spiral might result in development of a product specification. Subsequently, develop a prototype and then progressively more sophisticated version of software. Unlike other process models that end when software is delivered. It can be adapted to apply throughout the life of software.

42. Spiral Model

43. Spiral Model (cont.) Concept Development Project: Start at the core and continues for multiple iterations until it is complete. If concept is developed into an actual product, the process proceeds outward on the spiral. New Product Development Project: New product will evolve through a number of iterations around the spiral. Later, a circuit around spiral might be used to represent a “Product Enhancement Project” Product Enhancement Project: There are times when process is dormant or software team not developing new things but change is initiated, process start at appropriate entry point.

44. Spiral models uses prototyping as a risk reduction mechanism but, more important, enables the developer to apply the prototyping approach at each stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but also incorporates it into an iterative framework activity. If risks cannot be resolved, project is immediately terminated Problem Area: It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. If a major risk is not uncovered and managed, problems will undoubtedly occur.

45. 45 General Weaknesses of Evolutionary Process Models 1)Prototyping poses a problem to project planning because of the uncertain number of iterations required to construct the product 2)Evolutionary software processes do not establish the maximum speed of the evolution If too fast, the process will fall into chaos If too slow, productivity could be affected 3)Software processes should focus first on flexibility and extensibility, and second on high quality We should prioritize the speed of the development over zero defects Extending the development in order to reach higher quality could result in late delivery

46. Concurrent Development Model  Concurrent modeling is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities, actions and tasks to a sequence of events, it defines a process network. Each activity, action or task on the network exists simultaneously with other activities, actions or tasks. Events generated at one point trigger transitions among the states.  It represented schematically as series of major technical activities, tasks, and their associated states.  It is often more appropriate for system engineering projects where different engineering teams are involved.  The activity-modeling may be in any one of the states for a given time.

47. Concurrent Development Model

48.  It represented schematically as series of major technical activities, tasks, and their associated states.  It is often more appropriate for system engineering projects where different engineering teams are involved.  The activity-modeling may be in any one of the states for a given time.  All activities exist concurrently but reside in different states.  Series of event will trigger transition from state to state. The analysis activity (existed in the none state while initial customer communication was completed) now makes a transition into the under development state. Analysis activity moves from the under development state into the awaiting changes state only if customer indicates changes in requirements. During initial stage there was inconsistency in design which was uncovered. This will triggers the analysis action from the Done state into Awaiting Changes state.

49. Concurrent Model  Allow a software team to represent iterative and concurrent elements of any of the process models. F  or example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the following actions: prototyping, analysis and design.  The Figure shows modeling may be in any one of the states at any given time. For example, communication activity has completed its first iteration and in the awaiting changes state. The modeling activity was in inactive state, now makes a transition into the under development state. If customer indicates changes in requirements, the modeling activity moves from the under development state into the awaiting changes state. 49

50. Concurrent Development (Cont.) Visibility of current state of project It define network of activities Each activities, actions and tasks on the network exists simultaneously with other activities,actions and tasks. Events generated at one point in the process network trigger transitions among the states.

51. Fourth Generation Techniques(4GT)

52. 4GT Like all other models, 4GT begins with a requirements gathering phase. Ideally, the customer would describe the requirements, which are directly translated into an operational prototype. Practically, however, the client may be unsure of the requirements, may be ambiguous in his specs or may be unable to specify information in a manner that a 4GT tool can use. For small applications, it may be possible to move directly from the requirements gathering phase to the implementation phase using a nonprocedural fourth generation language. However for larger projects a design strategy is necessary. Otherwise, the same difficulties are likely to arise as with conventional approaches.

53. 4GT  To transform a 4GT implementation into a product, the developer must conduct thorough testing, develop meaningful documentation.  In addition, the 4GT developed software must be built in a manner that enables maintenance to be performed quickly. Merits:  Dramatic reduction in software development time. (For small and intermediate application)  Improved productivity for software developers. Demerits:  Not much easier to use as compared to programming languages  The maintainability of large software systems built using 4GT is open to question.

54. 4GT 4GT Software tool is used to generate the source code for a software system from a high level specification representation Commonly used 4GT in development models are mentioned below: ◦Report Generation ◦Data base query language ◦Data Manipulation ◦Screen definition and interaction ◦Code Generation ◦Web engineering Tools ◦high-level graphics

55. Component Based Development component-based development (CBD) model incorporates many of the characteristics of the spiral model. It is evolutionary by nature and iterative approach to create software. CBD model creates applications from prepackaged software components (called classes).

56. CBD Model

57. CBD model (cont.) Modeling and construction activities begin with identification of candidate components. Classes created in past software engineering projects are stored in a class library or repository. Once candidate classes are identified, the class library is searched to determine if these classes already exist. If class is already available in library extract and reuse it. If class is not available in library, it is engineered or developed using object- oriented methods. Any new classes built to meet the unique needs of the application. Now process flow return to the spiral activity.

58. CBD model (cont.) CBD model leads to software reusability. Based on studies, CBD model leads to 70 % reduction in development cycle time. 84% reduction in project cost. Productivity is very high.