1. Software Engineering Processes Lecture 3

2. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 2 Terms & Definitions Process –A process describes the sequence of steps that a knowledgeable professional should follow to do a specified task. Defined Processes –A documented sequence of steps required to do a specific job. Processes are usually defined for jobs that are done repeatedly and need to be done in the same way each time that they are performed. Process & Plans –Processes and Plans include both the process steps and other elements required for a specific instantiation of that process: such as resources needed, roles of various project members, schedules, budget, goals and objectives, commitments, and identified risks. Process Phases –A defined process consists of a set of steps, Any process must have three phases: planning, development, and postmortem.

3. Software Process A software process can be defined as the coherent set of policies, organizational structures, technologies, procedures, and artifacts that are needed to conceive, develop, deploy, and maintain a software product. –Software Process: A Roadmap by Alfonso Fuggetta –Software development technology: Technological support used in the process (Tools, Techniques, infrastructure, envo etc). –Software development methods and techniques: organizations and people –Organizational behavior: Science of organizations and people –Marketing and economy. must address real customers’ needs in specific market settings. Software process models often represent a networked sequence of activities and events that represent strategies for accomplishing software evolution. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 3

4. 4 Essential Phases of any Software Development Process Essential Phases: –Requirements Elicitation, Analysis, Specification –System Design –Program Implementation –Test Each Phase has an “Output” –Software Requirements Specification (SRS), Use Cases –Design Document, Design Classes, –Code –Test Report, Change Requests Process Model –Different projects may interpret these phases differently. –Each particular style is called a “Software Life-Cycle Model” –Serve as a basis for planning, organizing, staffing, coordinating, budgeting, and directing software development activities How software is or should be developed.

5. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 5 SWEBOK Guide = 10 Knowledge Areas Mapped TO ISO/IEC 12207:1995 processes Software Quality Software Engineering Tools and Methods Software Engineering Process Software Engineering Management Software Configuration Management Maintenance TestingConstruction DesignRequirements Primary Processes Supporting Processes

6. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 6 Criticism Criticism on software development Counter criticism –widespread adaptation and use of software process methodologies

7. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 7 A structured framework for development Software Engineering Body of Knowledge (IEEE/ACM Stone-man Version 0.9 February 2001)… WWW.SWEBOK.ORG

8. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 8 Today’s Discussion The Software Engineering Process KA can be examined on two levels. –First level encompasses: The technical and managerial activities within the software life cycle processes that are performed during software acquisition, development, maintenance, and retirement. –Second is the meta-level, which is concerned with the: Definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle processes themselves. (IEEE/ACM Stone-man Version 0.9 February 2001)…

9. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 9 Software Engineering Process The term “software engineering process” can be interpreted in different ways, and this may cause confusion. –One meaning, where the word the is used (the software engineering process), could imply that there is only one right way of performing software engineering tasks. Avoid this interpretation, because no such process exists. –IEEE12207 standard  Software engineering processes, meaning: There are many processes involved, such as Development Process or Configuration Management Process.

10. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 10 Software Engineering Process- SWEBOK Another meaning refers to the general discussion of processes related to software engineering. Yet another meaning could signify the actual set of activities performed within an organization, which could be viewed as one process, especially from within the organization. Software engineering process related activities are relevant to and have been performed successfully: –Large organizations, Small Organizations, Teams, and Individuals.

11. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 11 Software Process  Many different software processes but all involve:  Specification – defining what the system should do;  Design and implementation – defining the organization of the system and implementing the system;  Validation – checking that it does what the customer wants;  Evolution – changing the system in response to changing customer needs.  A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. Basic Steps of Software Process The basic Software Process has three phases. 1. Planning: Produce a plan to do the work. 2. Development: Perform the work. a. Define the requirements b. Design the program c. Review the design and fix all defects d. Code the program e. Review the code and fix all defects f. Build / compile and fix all defects g. Test the program and fix all defects 3. Postmortem: Compare actual performance against the plan, record process data, produce a summary report, and document all ideas for process improvement.

12. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 12 Software Process Knowledge Area

13. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 13 Software Engineering Process Focuses on organizational change. It describes: –The infrastructure, activities, models, and practical considerations for process implementation and change Process evolution Process Infrastructure –The resources must be available and the responsibilities assigned Competent staff, tools, funding and commitment

14. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 14 Software Process Management Cycle The mgmt of SW processes consists of four activities sequenced in an iterative cycle: –Establish Process Infrastructure activity –The Planning activity: To understand the current business objectives To identify strengths and weaknesses To make a plan for process implementation and change. –The Process Implementation and Change activity: To execute the plan, deploy new processes (involve, the deployment of tools and training of staff) –Process Evaluation: Finding out how well the implementation and change went.

15. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 15 Process Infrastructure activity A team using a well structured Programming language to develop a system, effect of change ( from C to OOP): –Technical issues Effect of change e.g from C to OOP, requires education, training, techniques and appropriate time to get conversant –Management problem understand the implications of using the new technology plus the change in culture within the organization, secondly managing the current system, plus the time lost through all the training and education plus the change over to the new system. –Resourcing issues including: cost of training, loss of technical and managerial resource during training, cost of additional consultancy etc,

16. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 16 Process Definition Software Life Cycle Models –serve as a high-level definition of the phases that occur during development. –Aimed to highlight the key activities and their interdependencies Waterfall model, through away prototyping model, evolutionary development, incremental/iterative delivery, the spiral model, the reusable software model Software Life Cycle Processes –More detailed than software life cycle models Information Technology — Software Life Cycle Processes [IEEE 12207.0-96]. Some software life cycle processes emphasize rapid delivery and strong user participation, namely agile methods such as Extreme Programming

17. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 17 Development Vs Process models –Software process models based on the evolutionary development of applications are being recognized as important for success in the production of commercial software. (Argument #1) –Important aspect of software development is conformance to an appropriate process model? (Argument #2) Take any process model as example and view it from verity of following –Good technical team –Use of the right tools –Use of the right method of computation –Clear and stable set of requirements –Good configuration management and change control –Good project management (technical and personnel) –Good planning

18. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 18 IEEE Support to Process Lifecycle The IEEE 1074:1997 standard on developing life cycle processes: –Provides a list of processes and activities for software development and maintenance A list of life cycle activities which can be mapped into processes and organized in the same way as any of the software life cycle models –Standard identifies and links other IEEE software standards to these activities –Standard can be used to build processes conforming to any of the life cycle models Standards which focus on maintenance processes are IEEE Std 1219-1998 and ISO 14764: 1998 IEEE/EIA12207, contain mechanisms and recommendations for accomplishing the adaptation.

19. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 19 IEEE Std 1074: Standard for Software Lifecycle IEEE Std 1074 Project Management Project Management Pre- Development Pre- Development Develop- ment Develop- ment Post- Development Post- Development Cross- Development (Integral Processes) Cross- Development (Integral Processes) > Project Initiation >Project Monitoring &Control > Software Quality Management > Concept Exploration > System Allocation > Requirements Analysis > Design > Implemen- tation > Installation > Operation & Support > Maintenance > Retirement > V & V > Configuration Management > Documen- tation > Training Process Group Processes

20. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 20 IEEE/ISO 12207 ISO 12207 offers a framework for software life-cycle processes from concept through retirement. –Suitable for acquisitions: Recognizes the roles of acquirer and supplier –It is not applicable to the purchase of commercial-off-the-shelf (COTS) software products. –Provides a structure of processes using mutually accepted terminology “shall" to indicate mandatory provisions, "should" for recommendations, and "may" for permissible actions The standard is based on two basic principles: –modularity and responsibility. Modularity means processes with minimum coupling and maximum cohesion. Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved.

21. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 21 A Sample 12207 Development Process Process Implementation Activity Supporting Processes: Documentation, CM, QA, Verification, Validation, Joint Review, Audit, Problem resolution Organizational Processes: Management, Infrastructure, Improvement, Training One example of applying 12207 to the Waterfall development strategy System Qual Test System Integra- tion Software Installation Software Acceptance Support Software Item 1: Sys Arch Design System Reqts Analysis Software Qual Test Software Integra- tion Software Code & Test Software Detailed Design Software Arch. Design Software Reqts. Analysis Software Item 2: Software Qual Test Software Integra- tion Software Code & Test Software Detailed Design Software Arch. Design Software Reqts. Analysis Hardware items

22. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 22 Tailoring 12207 12207 should be tailored for a project - no two projects are the same Tailoring considerations: –Life cycle activity: prototyping, maintenance –Software characteristics: COTS, reuse, embedded firmware –Org’s policies, languages, hardware reserve, culture –Acquisition strategy: contract type, contractor involvement –Life cycle strategy: waterfall, evolutionary, spiral, etc. The Tailoring Process (12207.0 ) 1. Identify project environment - strategy, activity, requirements 2. Solicit inputs - from users, support team, potential bidders 3. Select processes, activities, documentation, responsibilities 4. Document tailoring decisions and rationale What CAN’T be tailored: the intent or objectives What CAN be tailored: number of phases/activities, roles, responsibilities, document formats, formality/frequency of reports or reviews

23. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 23 Example Process activities Software specification –The process of establishing what services are required and the constraints on the system’s operation and development. Software design and implementation –The process of converting the system specification into an executable system. Major Process activities are: Architectural design, Abstract specification, Interface design Component design, Data structure design, Algorithm design –Software design Design a software structure that realises the specification; –Implementation Translate this structure into an executable program;

24. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 24 Software specification Requirements engineering process –Feasibility study; –Requirements elicitation and analysis; –Requirements specification; –Requirements validation.

25. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 25 The software design process Deriving a solution which satisfies software requirements –Architectural design: Identify sub-systems. –Abstract specification: Specify sub-systems. –Interface design: Describe sub-system interfaces. –Component design: Decompose sub-systems into components. –Data structure design: Design data structures to hold problem data. –Algorithm design: Design algorithms for problem functions.

26. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 26 Process Activities Different processes organise activities in different ways & are described at different levels of details. –Real time software in aircraft has to be completely specified before the development –eCommerce system the development and the specification could be together Use of inappropriate process, –probably reduce the quality or the usefulness of the software product Generic process models –Waterfall –Evolutionary development –Integration from reusable components CBSE –Upper-CASE Tools to support the early process activities of requirements and design –Lower-CASE Tools to support later activities such as programming, debugging and testing There are many variants of these models

27. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 27 Plan-driven and agile processes  Plan-driven processes:  Processes where all of the process activities are planned in advance and progress is measured against this plan.  Agile processes:  Planning is incremental and it is easier to change the process to reflect changing customer requirements.  In practice, most practical processes include elements of both plan-driven and agile approaches.  There are no right or wrong software processes.

28. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 28 Why focus on process? Process provides a constructive, high-leverage focus... –as opposed to a focus on people Your work force is as good as it is trained to be. Working harder is not the answer. Working smarter, through process, is the answer. –as opposed to a focus on technology Technology applied without a suitable roadmap will not result in significant payoff. Technology provides the most benefit in the context of an appropriate process roadmap.

29. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 29 Software lifecycle Process Models Lifecycle - The steps through which the product progresses Software life cycle models serve as a high-level definition of the phases that occur during development. –They are not aimed at providing detailed definitions but at highlighting the key activities and their interdependencies. –Examples of software life cycle models are Build-and-fix model Waterfall model Rapid prototyping model Incremental model Extreme programming Synchronize-and-stabilize model Spiral model ………… Process Models Process Improvement

30. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 30 Build and Fix Model Problems –No specifications –No design Totally unsatisfactory for any reasonable size software Need life-cycle model –Phases –Milestones

31. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 31 Waterfall Model The only widely-used model until the early 80’s Characterized by –Feedback loops –Documentation-driven –Each phase needs to be approved by SQA Advantages –Enforced disciplined approach –Documentation –Maintenance easier Disadvantages –Specifications not easily understood by clients Deficiencies –All requirements must be known upfront –Deliverables created for each phase are considered frozen – inhibits flexibility –Can give a false impression of progress –Does not reflect problem-solving nature of software development – iterations of phases –Integration is one big bang at the end –Little opportunity for customer to preview the system (until it may be too late) When to use –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.

32. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 32 Rapid Prototyping Model Rapid prototype – a working model functionally equivalent to a subset of the product –Determine what the client needs –When developed, the client and users try using it –When they are satisfied, the process moves to the next phase Linear model –Specifications are drawn from the rapid prototype –Feedback loops are not used “Rapid” is the key

33. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 33 Integrating Waterfall and Rapid Prototyping Models Waterfall model –Many successes –Client needs may not be met Rapid prototyping model –Some success but not really proven –Has own problems Solution –Rapid prototyping for requirements phase –Waterfall for rest of life cycle

34. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 34 SDLC V-Shaped SDLC Model –A variant of the Waterfall that emphasizes the verification and validation of the product. –Testing of the product is planned in parallel with a corresponding phase of development Project and Requirements Planning – allocate resources Product Requirements and Specification Analysis – complete specification of the software system Architecture or High-Level Design – defines how software functions fulfill the design Detailed Design – develop algorithms for each architectural component Production, operation and maintenance – provide for enhancement and corrections System and acceptance testing – check the entire software system in its environment Integration and Testing – check that modules interconnect correctly Unit testing – check that each module acts as expected Coding – transform algorithms into software Strengths –Emphasize planning for verification and validation of the product in early stages of product development –Each deliverable must be testable –Project management can track progress by milestones –Easy to use Deficiencies –Does not easily handle concurrent events –Does not handle iterations or phases –Does not easily handle dynamic changes in requirements –Does not contain risk analysis activities When to use –Excellent choice for systems requiring high reliability – hospital patient control applications –All requirements are known up-front –When it can be modified to handle changing requirements beyond analysis phase –Solution and technology are known

35. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 35 Incremental Model The product is designed, implemented, integrated and tested as a series of builds A build consists of code pieces from various modules interacting to provide a specific functionality Too few builds can lead to build-and-fix model Too many builds can lead to inefficient development

36. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 36 Concurrent Incremental Model More risky version—pieces may not fit –CABTAB (code a bit and test a bit) and its dangers

37. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 37 Spiral Model Simplified Waterfall model plus risk analysis –Uses rapid prototypes Precede each phase by –Alternatives –Risk analysis Follow each phase by –Evaluation –Planning of next phase

38. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 38 Spiral SDLC Model Adds risk analysis, and RAD prototyping to the waterfall model Each cycle involves the same sequence of steps as the waterfall process model –Objectives: functionality, performance, hardware/software interface, critical success factors, etc. –Alternatives: build, reuse, buy, sub-contract, etc. –Constraints: cost, schedule, interface, etc. Spiral Quadrant Determine objectives, alternatives and constraints Spiral Quadrant Evaluate alternatives, identify and resolve risks Study alternatives relative to objectives and constraints Identify risks (lack of experience, new technology, tight schedules, poor process, etc. Resolve risks (evaluate if money could be lost by continuing system development Spiral Quadrant Develop next-level product Typical activities: –Create a design, Review design –Develop code, Inspect code –Test product Spiral Quadrant Plan next phase Typical activities –Develop project plan –Develop configuration management plan –Develop a test plan –Develop an installation plan Strength –Provides early indication of risks, without much cost –Users see the system early because of rapid prototyping tools –Critical high-risk functions are developed first –The design does not have to be perfect –Users can be closely tied to all lifecycle steps –Early and frequent feedback from users –Cumulative costs assessed frequently Deficiencies –Time spent for evaluating risks too large for small or low-risk projects –Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive –The model is complex –Risk assessment expertise is required –Spiral may continue indefinitely –Developers must be reassigned during non-development phase activities –May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration When to use –When creation of a prototype is appropriate –When costs and risk evaluation is important –For medium to high-risk projects –Long-term project commitment unwise because of potential changes to economic priorities –Users are unsure of their needs –Requirements are complex –New product line –Significant changes are expected (research and exploration) Suitability to modern SDLC –Appreciation of risk, –The possibility of stopping a project that exhibited too much risk, –knowledge of the phases (determine objectives, identify and assess risk, develop and verify next-level product, and plan next phase)

39. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 39 Agile SDLC’s Speed up or bypass one or more life cycle phases –Usually less formal and reduced scope –Used for time-critical applications –Used in organizations that employ disciplined methods Some Agile methods –Adaptive Software Development (ASD) –Feature Driven Development (FDD) –Crystal Clear –Dynamic Software Development Method (DSDM) –Rapid Application Development (RAD) –Scrum –Extreme Programming (XP) –Rational Unify Process (RUP)

40. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 40 Extreme Programming Approach based on the incremental model –Development team determines stories (features client wants) –Estimate duration and cost of each story –Select stories for next build –Each build is divided into tasks –Test cases for task are drawn up first –Pair programming –Continuous integration of tasks

41. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 41 Differences of Agile Focus on collaboration: –Less paperwork and more conversation –Stakeholders actively involved Focus on working software: –Greater feedback makes agile projects easier to manage –Less documentation is required –Less bureaucracy Agilists are generalizing specialists: –Less hand offs between people –Less people required –Specialists find it difficult at first to fit into the team Agile is based on practice, not theory: –This is a significant change from traditional –You need to see how agile works in practice to truly understand it Agile Common Practices Regular Deployment of Working Software Pair Programming Refactoring Continuous Integration Test Driven Development (TDD) Shared Code Ownership Active Stakeholder Participation Agile Common Practices Regular Deployment of Working Software Pair Programming Refactoring Continuous Integration Test Driven Development (TDD) Shared Code Ownership Active Stakeholder Participation

42. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 42 Agile Myths Vs Reality Myth 1.No Documentation 2.Undisciplined 3.No Planning 4.Not Predictable 5.Does Not Scale 6.Is a fashion 7.Silver Bullet 8.RUP isn’t agile 9.Not Fixed Price Reality 1.Agile Documentation 2.Requires great discipline 3.Just-in-time (JIT) planning 4.Far more predictable 5.Eclipse is agile 6.It’s quickly becoming the norm 7.It requires skilled people 8.RUP is agile 9.Agile provides stakeholders control over the budget, schedule, and scope

43. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 43 Agile vs. Plan Driven Processes 1.Small products and teams; scalability limited 2.Untested on safety- critical products 3.Good for dynamic, but expensive for stable environments. 4.Require experienced Agile personnel throughout 5.Personnel succeed on freedom and chaos 1.Large products and teams; hard to scale down 2.Handles highly critical products; hard to scale down 3.Good for stable, but expensive for dynamic environments 4.Require experienced personnel only at start if stable environment 5.Personnel succeed on structure and order

44. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 44 Organization & Meetings Roles & Responsibilities Processes Measures Policies & Standards Mission & Principles Agility - Set of Practices  Practical Governance Body  Staged Program Delivery  Simple And Relevant Metrics  Continuous Project Monitoring  Iterative Development  Adapt The Process  Risk-Based Milestones  Continuous Improvement  Embedded Compliance  Manage Project Pipeline By Business Value  Scenario-Driven Development  Self-Organizing Teams  Align HR Policies With IT Values  Align Organization Structure With Architecture  Integrated Lifecycle Environment  Valued Corporate Assets  Flexible Architectures

45. Advanced Software Engineering- Asst Prof Athar Mohsin, MSCS 19- MCS-NUST 45 References Guide to the Software Engineering Body of Knowledge: 2004 Trip, Leonard L., Professionalization of Software Engineering: Next Steps, “A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession”, “An Assessment of Software Engineering Body of Knowledge Efforts: A Report to the ACM Council“, Humphrey, W.S. (1990). Managing the Software Process. Addison-Wesley Publishing Company, New York, NY. Process Models in Software Engineering, Walt Scacchi, Institute for Software Research, University of California, Irvine M. B. Chrissis, M. Konrad and S. Shrum, CMMI: Guidelines for Process Integration and Product Improvement, Pearson Education Inc., Boston, 2003. Scott W. Ambler, www-306.ibm.com/software/rational/bios/ambler.html