1. Software Process By Sabeen Amjad Chapter-2

2. Objectives To comprehend  Software process  Software Engineering as layered technology  Generic view of Software Engineering  Defining a Common Process Framework  Intro to Capability Maturity Model

3. Software Process Process Series of predictable steps-a road map that helps create a timely and high quality entity Software Process is a framework for the tasks that are required to build high quality software

4. Software Process Is Software Process Software Engineering ? Answer: Yes and No Both…Why? Yes because it defines an approach which is known as Software Engineering No because Software Engineering also entails technologies that populate the process…technical methods and automated tools.

5. Software Engineering: A Layered Technology A Quality Focus Process Methods Tools

6. Generic Process Framework Communication: With customer for requirements gathering Planning: Establish a plan, tasks to be conducted, associated risks, required resources, work products and work schedule Modeling: Development of models for better understanding of requirements for customer and developer and their design

7. Generic Process Framework Requirements analysis include requirements gathering, elaboration, negotiation, specification and validation. Design include data design, architectural design, interface design and component level design Construction: Code generation and testing required Deployment: Software delivered to customer who evaluates and provides feedback

8. Task Sets Task sets consist of software engineering work tasks, related work products, quality assurance activities and milestones. Task sets depend on the specific needs of the project and characteristics of the project team.

9. Class Activity Write down Requirement Gathering task Sets for a simple project

10. Software Engineering: A Generic View Phases of Work Associated With Software Engineering Definition PhaseSupport PhaseDevelopment Phase Correction Enhancement Adaptation Prevention

11. Software Engineering: A Generic View Umbrella Activities Phases of Work Associated With Software Engineering Definition PhaseSupport PhaseDevelopment Phase Correction Enhancement Adaptation Prevention 1. Software project tracking control 4. Formal technical reviews 3. Software quality assurance 6. Software configuration management 8. Document preparation &production 7. Reusability management 5. Measurement 2. Risk Management

12. CMM-Introduction Comprehensive model developed by SEI based on a set of software engineering capabilities that should be present as organizations reach different level of maturity.

13. CMMI Representations Staged Five Maturity Levels (MLs)(1-5) Continuous Six Capability Levels (CLs)(0-5) for individually assessing each Process Area (PA) Process Areas are grouped in four Process Area Categories (PACs). Process Management, Project Management, Engineering And Support More flexibility for organizations that have to adjust their process improvement to their business goals

14. Comparing Model Representations Staged ML 1 ML2 ML3 ML4 ML5...for an established set of process areas across an organization Continuous...for a single process area or a set of process areas PA Process Area Capability 0 1 2 3 4 5 PA

15. Maturity Levels CMM defines key activities at different levels of maturity. CMM establishes five maturity levels 1. Initial 2. Repeatable 3. Defined 4. Managed 5. Optimizing Each level has a certain set of KPAs(Key Process Areas), which are software engineering functions needed at a particular level

16. CMM Summary

17. Maturity Levels Key Process Areas Goals Common Features Key Practices 2 3 4 5 The CMM Structure for Managed Level RMPPPTSMCMQA Commitment to Perform Ability to Perform Activities Performed Measurement and Analysis Verifying Implementation

18. CMMI Capabilities Level Level 0 - Incomplete Process area not performed or meet goals Level 1 - Performed level 0 tasks completed and work tasks for desired product. Level 2 - Managed Level 1 tasks completed and process area confirms to organization defined policy

19. CMMI Capabilities Level Level 3 – Defined Level 2 tasks completed and process improvement in organizational process assets Level 4 - Quantitatively Managed Level 3 tasks completed and quantitative objectives for quality and process performance Level 5 - Optimized Level 4 completed and process is adapted and optimized continuously

20. Software Process Models The strategy to adopt software engineering as a layered technology is referred to as Software Process Model Problem Definition Status Quo Solution Integration Technical

21. Linear Sequential model Also known as the classic life cycle or waterfall model, it suggests a systematic, sequential approach to software development that begins at the system level and progress through analysis, design, coding, testing and support.

22. Requirements Design Coding Testing Analysis Maintenance Linear Sequential model System/information engineering

23. Linear Sequential model System / Information Engineering AnalysisTestCodeDesign Linear Sequential model (Pressman 1997)

24. Linear Sequential model Real projects rarely follow the sequential flow and changes can cause confusion. This model has difficulty accommodating requirements change The customer will not see a working version until the project is nearly complete Developers are often blocked unnecessarily, due to previous tasks not being done Limitations

25. The incremental model This is a combination of the linear sequential model and the iterative model. The problem is broken into increments, and each increment is tackled as a linear sequence. Further increments can either be done after the previous ones, or can overlap with the previous ones. Incremental delivery focuses on the delivery of an operational product with each increment. Early increments are stripped-down versions of the final product.

26. Incremental model System / Information Engineering AnalysisTestCodeDesign AnalysisTestCodeDesign AnalysisTestCodeDesign AnalysisTestCodeDesign Increment 1 Increment 2 Increment 3 Increment 4 Incremental model (Pressman 1997)

27. Incremental model advantages Less staffing is required than in a RAD project Early delivery is guaranteed Progress of the whole project is not delayed if one of the resources is not available for part of it

28. The RAD model Rapid Application Development is a linear sequential software development process model that emphasises an extremely short development cycle. A component-based construction approach is used. To use this approach, the project scope must be constrained and the requirements should be well understood. A task that should take no more than ninety days to complete is modelled, generated and implemented. There can be several teams working on different components during this ninety day time-box.

29. The RAD model.The RAD model (Pressman 1997) 90 days Team 1 Testing & Turnover Application Generation Business modelling Data modelling Process modelling Team 2 Testing & Turnover Application Generation Business modelling Data modelling Process modelling Team 3 Testing & Turnover Application Generation Business modelling Data modelling Process modelling

30. Problems with RAD For large, scalable projects, RAD requires sufficient human resources to create the right number of RAD teams RAD requires developers and customers who are committed to the rapid-fire activities necessary to complete a system in this time frame, or failure will result. RAD is not suitable for many project types. If a system cannot be modularized properly, building components for RAD will be problematic. If high performance is to be achieved, RAD approach may not work. RAD may not be appropriate when technical risks are high

31. Evolutionary Software Process Models  Software Evolves  Business and product requirements change-Creeping requirements  Tight market deadlines compels for a limited version  Details of the product Above issues cannot be answered by Linear sequential or by prototyping approach

32. Prototyping The developer and customer define the overall objectives for the software. A quick design focuses on what the customer will see. From this, a prototype is constructed. The user evaluates it and improvements are made. This continues in an iterative fashion until a satisfactory product is achieved.

33. Prototyping The Prototyping Paradigm (Pressman 1997) Listen to customer Build / revise mock-up Customer test- drives mock-up

34. Requirements Engineer Product Quick Design Build Prototype Evaluate Prototype Refine Prototype Changes ? Yes No (Pressman, 1996) Prototyping

35. Problems with prototyping The customer sees a working version and expects the finished product to be available in a short time. This puts pressure on the developer to take short cuts, at the expense of quality and maintainability. The developer may make compromises for speed. Inappropriate tools may be used or inefficient algorithms may be used, which then become integral parts of the system. If the user isn’t focused on what they want, the system may never be completed.

36. The Spiral model Boehm’s (1988) spiral model couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. Software is developed in a series of incremental releases. During the early releases, there may be just a paper model, but the system becomes increasingly more complete. There are a number of framework activities (Customer communication, Planning, Risk analysis, Engineering, Construction and release, Customer evaluation). Unlike any of the other models, this model keeps revisiting the system throughout its lifetime.

37. Spiral model details Spiral model is divided into a number of framework activities, named as task regions.3-6 task regions. Each task region has its own task sets. Customer communication Construction and release Engineering Risk analysis Planning Customer evaluation

39. The Component assembly model This incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, it composes applications from pre- packaged software components. The “construction & release” activity in Boehm’s model is replaced by an “Engineering construction and release” activity.

40. Component Assembly Model Identify candidate components Construct nth iteration of system Put new components in library Look up components in library Extract components if available Build components if unavailable Component Assembly model – engineering construction and release activity (Pressman 1997)

41. The Formal Method Model Encompasses a set of activities that leads to formal mathematical specification of computer software Specify, develop and verify a computer based system by applying a rigorous mathematical notation.

42. Advantages Mechanism for eliminating ambiguity, incompleteness, and inconsistency Formal methods provide mathematical analysis for ensuring correct analysis and design

43. Disadvantages Quiet expensive and time consuming Extensive Training required Difficult to communicate for technically unsophisticated customer

44. Methods and tools There are many methodologies and tools that are available. The methodology should fit a particular process model that is suited to the task being undertaken, and the tool or set of tools should provide automated leverage at pertinent parts of the life cycle. The methodology should include diagrammatic techniques, such as SSADM (Downs et al. 1992) for linear sequential systems or OMT (Frost 1995) or Rational Unified Process (RUP).(Fowler&Scott 1997) for object-oriented systems.

45. Conclusion There are a variety of process models, each of which can be used successfully. Once a process model has been used to develop a system, documentation style, organisation and structure should either remain in the format of that process model, or all be converted to a different process model. This is particularly important where automated tools are used.