1. 1 Introduction to Software Development Process Lecture - 2

2. 2 References Chapter 12: Software Lifecycle from Object Oriented Software Engineering: Conquering Complex and Changing Systems. IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes, Software Engineering Standards Committee, December 1997.

3. 3 Software Lifecycle (SLC) Models Represent all the activities and work products necessary to develop a software system. Enable managers and developers to deal with the complexity of the process of developing software in the same way as an analysis or a design model assists a developer in dealing with the complexity of a software system. Used to better understand, measure and control the development process by making the activities and their dependencies visible and manageable.

4. 4 Modeling the Software Lifecycle Activity centered models –Models focusing on the activities of software development. Entity centered models –Models focusing on work products created by the software development activities. Activity centered view leads participants to focus on how work products are created. Entity centered view leads participants to focus on the content and structure of work products.

5. 5 A Simple Activity Centered SLC Problem Definition Activity System Development Activity System Operations Activity Sequential Activities in SLC Market Creation Activity System Development Activity System Upgrade Activity Concurrent Activities in SLC

6. 6 A Simple Entity Centered SLC System Development Project Market Survey Document Specification Document Executable System Test Results Consists of

7. 7 Relationship Between Types of SLC Models Complementary views of SLC. Each work product has one or more activity associated with it. Every activity may generate one or more work products.

8. 8 Relationship Between Types of SLC Models (Contd.) ActivityAssociated Work Products Problem DefinitionMarket Survey (Input), System Specs (Output) System DevelopmentSystem Specs (Input), Executable System (Output) System OperationLessons Learnt

9. 9 IEEE 1074: Standard for Developing Lifecycle Processes Describes sets of activities and processes mandatory for development and maintenance of software. Focuses on the establishment of a common framework for developing lifecycle models and providing examples for typical situations. Lists 17 processes grouped into 6 process groups. Each process consists of activities.

10. 10 Software Processes Defined in IEEE 1074 Process GroupsProcesses Lifecycle ModelingSelection of a lifecycle model Project ManagementProject Initiation, Project Monitoring & Control, Software Quality Management Pre-DevelopmentConcept Exploration, System Exploration DevelopmentRequirements, Design, Implementation Post-DevelopmentInstallation, Operations & Support, Maintenance, Retirement Integral ProcessesVerification & Validation, Software Configuration Management, Documentation, Training

11. 11 Lifecycle Modeling Project manager customises activities defined in IEEE 1074 for a specific project. Not all projects require same activities and the same sequence of activities. Selected lifecycle models serve as inputs to the project initiation phase.

12. 12 Project Management Activities that allow the project manager to initiate, monitor and control the project throughout the project lifecycle ProcessActivities Project Initiation Map Activities to Software Life Cycle Model Allocate Project Resources Establish Project Environment Plan Project Management Project Monitoring and Control Analyse Risks Perform Contingency Planning Manage Project, Retain Records Implement Problem Reporting Model Software Quality Management Plan Software Quality Management Define Metrics Manage Software Quality Identify Quality Improvement Needs

13. 13 Pre-Development A concept or an idea for development is formalised and its requirements are analysed to develop an architecture ProcessActivities Concept Exploration Identify Ideas or Needs Formulate Potential Approaches Conduct Feasibility Studies Plan System Transition (If Applicable) Refine or Finalise the Idea or Need System Allocation Analyse Functions Develop System Architecture Decompose System Architecture

14. 14 Development Directed towards the construction of the system. Results in the definition of design objects, their attributes, their operations and their organisation into packages ProcessActivities Requirements Define and Develop Software Requirements Define Interface Requirements Prioritise and Integrate Software Requirements Design Perform Architectural Design Design Database (If Applicable) Design Interfaces, Select or Develop Algorithms, Perform Detailed Design Implementation Create Test Data, Create Source Code, Generate Object Code, Create Operating Documentation, Plan Integration, Perform Integration

15. 15 Post-Development Consists of installation, maintenance, operations, support and retirement processes ProcessActivities Installation Plan Installation, Distribution of Software, Installation of Software, Accept Software in Operational Environment Operation and Support Operate the System, Provide Technical Assistance and Consulting, Maintain Support Request Log Maintenance Reapply Software Lifecycle Retirement Notify Users, Conduct Parallel Operations, Retire Systems

16. 16 Integral Processes (Cross Development) Activities that take place through out the project ProcessActivities Verification and Validation Plan Verification and Validation, Execute Verification and Validation Tasks, Collect and Analyse Metric Data, Plan Testing, Develop Test Requirements, Execute the Tests Software Configuration Management Plan Configuration Management, Develop Configuration Identification, Perform Configuration Control, Perform Status Accounting

17. 17 Integral Processes (Cross Development) ProcessActivities Documentation Development Plan Documentation, Implement Documentation, Produce and Distribute Documentation Training Plan the Training Programme, Develop Training Materials, Validate the Training Programme, Implement the Training Programme

18. 18 Software Lifecycle Models Dependencies exist between processes defined in IEEE-1074 Each process generates a work product that is consumed by another. Each dependency represents a formal communication channel between project participants supported by relevant work products.

19. 19 Software Lifecycle Models (Contd.) Software Lifecycle Models (SLCMs) form basic framework from which Software Lifecycle Processes (SLCPs) are developed. SLCMs define the framework for the selection of activities and the order of their execution. Different projects require different SLCMs, e.g., –Development based heavily on reuse may involve a largely sequential lifecycle. –Development of a new product may involve iterative processes with substantial concurrency.

20. 20 Waterfall SLCM An activity centered SLCM prescribing a sequential execution of a subset of the development and management processes. Requirements elicitation and analysis activities are completed before system design activity starts. A constant verification and validation activity required to ensure the development of functionally correct and error-free software.

21. 21 Waterfall SLCM (Contd.) Provides a simplistic view of the software development activity, measuring progress by the number of tasks that have been completed. Assumes that software development can be scheduled as a step by step process that transforms user needs into code.

22. 22 Waterfall SLCM (Contd.)

23. 23 DoD 2167A Waterfall SLCM Each development activity is followed by a review. Starts from the system requirements analysis activity with a goal to generate unambiguous system requirements. Design only starts once the requirements are considered to be complete, consistent and clear by the System Requirements Review. System design forms a basis for the software requirements analysis.

24. 24 DoD 2167A Waterfall SLCM (Contd.) Software requirements form the basis for software design and implementation activities. Implementation starts with the preliminary design activity. Preliminary design is followed by detailed design. Coding starts after a Critical Design Review.

25. 25 DoD 2167A Waterfall Model (Contd.)

26. 26 Spiral SLCM An activity centered SLCM devised to address the source of weaknesses in the Waterfall SLCM. Accommodates infrequent changes during the software development process. Adds activities related to risk management, reuse and prototyping to each activity. Activities are termed as cycles or rounds.

27. 27 Spiral SLCM (Contd.) Each quadrant of a cycle specifies particular tasks, i.e., –Top left: Determine objectives, alternatives and constraints. –Top right: Evaluate alternatives, identify and resolve risks. –Bottom right: Develop and verify next level of the product. –Bottom left: Plan next phase. Rounds follow the Waterfall SLCM.

28. 28 Spiral SLCM (Contd.) Distance from the center indicates the cost accumulated by the project. Angular distance indicates the progress accomplished in each phase

29. 29 Spiral SLCM (Contd.)

30. 30 Shark Tooth SLCM Waterfall and Spiral SLCMs emphasize the management of software developers and do not address the needs of customers and users. These models assume that software requirements do not change drastically within the duration of the project. Clients and users do not see an executing system before the clients’ acceptance test and therefore cannot correct any requirement errors.

31. 31 Shark Tooth SLCM (Contd.) At the requirements stage, developers and clients are at the same level of abstraction. While the users remain at the same level of abstraction, the developers’ perspective shifts. This model aims to reduce the gap between the users’ level of abstraction and the developers’ level of abstraction. A revolutionary (throwaway) prototype is demonstrated to the users early in the development stages.

32. 32 Shark Tooth SLCM (Contd.) The second evolutionary prototype is based on the design and is demonstrated later in the project when some functionality has been implemented. Design reviews and demonstrations of integration prototypes are held with the project manager. A simple integration prototype demonstrates the interaction between major components of the system.

33. 33 Shark Tooth SLCM (Contd.)

34. 34 Prototyping Process of using a prototype to seek information needed to make decisions. Reduces the risk of making mistakes in setting requirements or in designing system architecture. Prototype is a preliminary, intentionally incomplete or scaled down version of a system. –Used for demonstrating certain essential artifacts of the system being developed. Prototypes are not as robust or functionally complete as are the deliverable products.

35. 35 Prototyping (Contd.) Characteristics of prototypes –A requirements definition medium. –Means of providing the users with a physical representation of key parts of the system before its complete implementation. –Functional after a modest amount of effort. –Flexible to allow modifications conveniently. –Not necessarily complete or intended to be the final system.

36. 36 Categories of Prototypes Analysis prototypes –Partially executable mockups of the product. –Assists in clarification of requirements and solicitation of new ideas. Design prototypes –Developed to explore and understand a system’s implementation and architecture. –Forms the basis for storage and performance evaluations. –Assists in detecting redundancies and inconsistencies in the design.

37. 37 Categories of Prototypes (Contd.) Vertical prototyping –Used to understand a specific partition of a problem and to suggest a suitable solution. –Required for components whose concepts are not well understood and a complete functional model is required for explanatory and exploratory purposes. Feasibility prototyping –Used to demonstrate the applicability of a specific architecture, process or an implementation technique. –Used to measure and evaluate performance under specific load. –Used to evaluate the application of a specific technology in the product.