1.  Dr. Syed Noman Hasany

2.  Review of known methodologies  Analysis of software requirements  Real-time software  Software cost, quality, testing and measurements  Object programming  Knowledge engineering issues: knowledge representation using rules, frames & logic, basics of logical inference, and basics of search.

3.  Software Process Models

4.  A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective e.g. waterfall model 4

5. Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. In 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. 5

6. A. The waterfall model o Plan-driven model. Separate and distinct phases of specification and development. B. Incremental development o Specification, development and validation are interleaved. May be plan-driven or agile. C. Reuse-oriented software engineering o The system is assembled from existing components. May be plan- driven or agile. In practice, most large systems are developed using a process that incorporates elements from all of these models. 6

7. 7

8. The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. In principle, a phase has to be complete before moving onto the next phase. Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. ◦ Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. ◦ Few business systems have stable requirements. The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. ◦ In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work. 8

9. 9

10.  In outline description, customers identify the services to be provided by the system.  Concurrent means in parallel.  Incremental development in some form is now the most common approach for the development of application systems. This approach can be either plan-driven, agile, or, more usually, a mixture of these approaches. o In a plan-driven approach, the system increments are identified in advance; o if an agile approach is adopted, the early increments are identified but the development of later increments depends on progress and customer priorities. 10

11. The cost of accommodating changing customer requirements is reduced. (as users are almost involve in all phases) ◦ The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. It is easier to get customer feedback on the development work that has been done. ◦ Customers can comment on demonstrations of the software and see how much has been implemented. More rapid delivery and deployment of useful software to the customer is possible. ◦ Customers are able to use and gain value from the software earlier than is possible with a waterfall process. 11

12. The process is not visible. ◦ Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. System structure tends to degrade as new increments are added. ◦ Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. 12

13. Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the- shelf) systems. Process stages ◦ Component analysis; ◦ Requirements modification; ◦ System design with reuse; ◦ Development and integration. Reuse is now the standard approach for building many types of business system ◦ Reuse covered in more depth in Chapter 16. 13

14. 14

15. Web services that are developed according to service standards and which are available for remote invocation. Collections of objects that are developed as a package to be integrated with a component framework such as.NET or J2EE. Stand-alone software systems (COTS) that are configured for use in a particular environment. 15

16. Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the- shelf) systems. Process stages ◦ Component analysis; ◦ Requirements modification; ◦ System design with reuse; ◦ Development and integration. Reuse is now the standard approach for building many types of business system ◦ Reuse covered in more depth in Chapter 16. 16

17. 17

18. Web services that are developed according to service standards and which are available for remote invocation. Collections of objects that are developed as a package to be integrated with a component framework such as.NET or J2EE. Stand-alone software systems (COTS) that are configured for use in a particular environment. 18

19. A risk-driven software process framework proposed by Boehm (1988). Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process (the innermost loop might be concerned with system feasibility, the next loop with requirements definition, the next loop with system design, and so on) No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Chapter 2 Software Processes 19

20.  A cycle of the spiral begins by elaborating objectives such as performance and functionality.  Alternative ways of achieving these objectives, and dealing with the constraints on each of them, are then enumerated.  Each alternative is assessed against each objective and sources of project risk are identified.  The next step is to resolve these risks by information- gathering activities such as more detailed analysis, prototyping, and simulation.

21. 21

22.  Risk simply means something that can go wrong. For example, if the intention is to use a new programming language, a risk is that the available compilers are unreliable or do not produce sufficiently efficient object code.  Risks lead to proposed software changes and project problems such as schedule and cost overrun, so risk minimization is a very important project management activity.

23.  The main difference between the spiral model and other software process models is its explicit recognition of risk.  Risks are explicitly assessed and resolved throughout the process.  It assumes that changes are a result of project risks and includes explicit risk management activities to reduce these risks. Chapter 2 Software Processes 23

24. Objective setting ◦ Specific objectives for the phase are identified. Risk assessment and reduction ◦ Risks are assessed and activities put in place to reduce the key risks. Development and validation ◦ A development model for the system is chosen which can be any of the generic models. Planning ◦ The project is reviewed and the next phase of the spiral is planned. Chapter 2 Software Processes 24

25. A modern hybrid generic process model derived from the work on the UML and associated process. Hybrid because it brings together aspects of the 3 generic process models discussed previously. Phases in the RUP are more closely related to business rather than technical concerns. Normally described from 3 perspectives ◦ A dynamic perspective that shows phases over time; ◦ A static perspective that shows process activities; ◦ A practice perspective that suggests good practice. Chapter 2 Software Processes 25

26. Chapter 2 Software Processes 26

27. Inception ◦ Establish the business case for the system. Elaboration ◦ The goals of the elaboration phase are to develop an understanding of the problem domain, establish an architectural framework for the system, develop the project plan, and identify key project risks. On completion of this phase you should have a requirements model for the system, which may be a set of UML use-cases, an architectural description, and a development plan for the software. Construction ◦ System design, programming and testing. Transition ◦ Deploy the system in its operating environment. Chapter 2 Software Processes 27

28.  In-phase iteration o Each phase is iterative with results developed incrementally.  Cross-phase iteration o As shown by the loop in the RUP model, the whole set of phases may be enacted/passed incrementally. Chapter 2 Software Processes 28

29. Chapter 2 Software Processes 29

30. Chapter 2 Software Processes 30

31. Develop software iteratively ◦ Plan increments based on customer priorities and deliver highest priority increments first. Manage requirements ◦ Explicitly document customer requirements and keep track of changes to these requirements. Use component-based architectures ◦ Organize the system architecture as a set of reusable components. Chapter 2 Software Processes 31

32.  Visually model software o Use graphical UML models to present static and dynamic views of the software.  Verify software quality o Ensure that the software meets the organizational quality standards.  Control changes to software o Manage changes to the software using a change management system and configuration management procedures and tools.

33.  It recognizes that deploying software in a user’s environment is part of the process.  Workflows are static and are technical activities that are not associated with a single phase but may be used throughout the development to achieve the goals of each phase.  Not a suitable process for all types of development, e.g., embedded software development o Embedded software is computer software, written to control machines or devices that are not typically thought of as computers.