1. Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu university E-mail: Engmaisak@hotmail.com. Tell:0615648915 WWW.ENGMAISAK.BLOGSPOT.COM February – July 2016 SOFTWARE ENGINEERING (CS3529) TARGET CLASSES: CS14: A,B

2. Sequence one: The Software process Definition Plan driven and Agile Software Process Models (the eight Software Engineering Methodologies) The Waterfall Model Adv. and Disadvantages of waterfall model. Sequence two: Incremental development Model diagram Adv. and Disadvantages of Incremental development model. Reuse-oriented software engineering Adv. and drawbacks of reuse- oriented software engineering CHAPTER 2 – SOFTWARE PROCESS MODELS CHAPTER2 - SE 2

3. THE SOFTWARE PROCESS CHAPTER2 - SE 3 The software process is a structured set of activities required to develop a software system. There are 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.

4. PLAN-DRIVEN AND AGILE PROCESSES CHAPTER2 - SE 4 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. SOFTWARE PROCESS MODELS CHAPTER2 - SE 5 1.The waterfall model – is called also ” Software Development Life Cycle - SDLC” (1970s) 2.Incremental development 3.Reuse-oriented software engineering 4.Software Prototyping 5.Incremental delivery 6.Spiral Model 7.Rational Unified Process Model 8.Extreme programming In practice, most large systems are developed using a process that incorporates elements from all of these models.

6. THE WATERFALL MODEL CHAPTER2 - SE 6 The first published model of the software development process was derived from more general system engineering processes. The waterfall has been issued in 1970s. The waterfall model is used in systems engineering projects where a system is developed at several sites. The plan-driven nature of the waterfall model helps coordinate the work. The waterfall model This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.

7. THE WATERFALL MODEL PROCESSES/PHASES CHAPTER2 - SE 7

8. THE WATERFALL MODEL PROCESSES/PHASES (1/2) CHAPTER2 - SE 8 1.Requirements analysis and definition The system’s services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. 2.System and software design The systems design process allocates the requirements to either hardware or software systems by establishing an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. 3.Implementation and unit testing During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

9. THE WATERFALL MODEL PROCESSES/PHASES (2/2) CHAPTER2 - SE 9 4.Integration and system testing The individual program units 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. 5.Operation and maintenance Normally (although not necessarily), this is the longest life cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered.

10. ADVANTAGES OF WATERFALL MODEL CHAPTER2 - SE 10 The waterfall model is consistent with other engineering process models and documentation is produced at each phase. This makes the process visible so managers can monitor progress against the development plan. Software processes based on the waterfall model are still commonly used.

11. WATERFALL MODEL DRAWBACKS/PROBLEMS CHAPTER2 - SE 11 The difficulty of accommodating change after the process is underway. In principle, a phase has to be completed before moving onto the next phase. 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.

12. INCREMENTAL DEVELOPMENT CHAPTER2 - SE 12

13. INCREMENTAL DEVELOPMENT CHAPTER2 - SE 13 This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version. Incremental development is based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed. Incremental Development model - Best Practices 1.Sales System. 2.Banking System. The system will be developed in batches ; means it will be divided into functions and will be worked on them separately and in sequence sorted by importance of the function for the user and for the system.

14. INCREMENTAL DEVELOPMENT BENEFITS CHAPTER2 - SE 14 1.The cost of incremental is less than waterfall cost. Incremental model needs less developers and programmers. 2.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. 3.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. 4.Most basic services are implemented first → receives multiple testing throughout development.

15. INCREMENTAL DEVELOPMENT PROBLEMS CHAPTER2 - SE 15 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.

16. REUSE-ORIENTED SOFTWARE ENGINEERING CHAPTER2 - SE 16 ROSE is Based on systematic reuse where systems are integrated from existing components of another systems. Reuse-oriented software engineering This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch. This informal reuse takes place irrespective of the development process that is used. However, in the 21st century, software development processes that focus on the reuse of existing software have become widely used. Reuse-oriented approaches rely on a large base of reusable software components and an integrating framework for the composition of these components

17. REUSE-ORIENTED SOFTWARE ENGINEERING PHASES CHAPTER2 - SE 17

18. REUSE-ORIENTED SOFTWARE ENGINEERING PHASES (1/2) CHAPTER2 - SE 18 The phases of ROSE are the following stages: 1.Component analysis: Given the requirements specification, a search is made for components to implement that specification. Usually, there is no exact match and the components that may be used only provide some of the functionality required 2.Requirements modification: During this stage, the requirements are analyzed using information about the components that have been discovered. They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions

19. REUSE-ORIENTED SOFTWARE ENGINEERING PHASES (2/2) CHAPTER2 - SE 19 3.System design with reuse: During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components that are reused and organize the framework to cater for this. Some new software may have to be designed if reusable components are not available. 4.Development and integration: Software that cannot be externally procured is developed, and the components systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity. Reuse is now the standard approach for building many types of business system

20. REUSE-ORIENTED SOFTWARE ENGINEERING TYPES OF SOFTWARE COMPONENT CHAPTER2 - SE 20 The software components those can be used in Re-Use Oriented Model are: 1.Web services that are developed according to service standards and which are available for remote invocation. 2.Collections of objects that are developed as a package to be integrated with a component framework such as.NET. 3.Stand-alone software systems that are configured for use in a particular environment.

21. ADVANTAGES AND DISADVANTAGES OF REUSE-ORIENTED SOFTWARE ENG. CHAPTER2 - SE 21 The advantages are: 1.Reuse-oriented software engineering has the obvious advantage of reducing cost and risks. 2. It usually also leads to faster delivery of the software The most drawback of the model: 1.The requirements are expected not to be executed as the user needs and this may lead to a system that does not meet the real needs of the user.

22. CHAPTER2 - SE 22 END OF THIS SEQUENCE

23. CHAPTER 2 – SOFTWARE PROCESS MODELS Lecture 2 Coping with change Software Prototyping Incremental delivery Spiral Model Rational Unified Process Model Process activities 1.Specification activity 2. Development activity 3.Validation activity 4.Evolution activity

24. COPING WITH CHANGE ENGMAISAK@HOTMAIL.COM 24 Change is inevitable in all large software projects. Business changes lead to new and changed system requirements New technologies open up new possibilities for improving implementations Changing platforms require application changes Change leads to rework so the costs of change include both rework (e.g. re-analysing requirements) as well as the costs of implementing new functionality There are many ways of coping with change and changing system requirements and here are some of them: Software Prototyping Incremental delivery

25. SOFTWARE PROTOTYPING ENGMAISAK@HOTMAIL.COM 25 A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: The requirements engineering process to help with requirements elicitation and validation; In design processes to explore options and develop a UI design; In the testing process to run back-to-back tests.

26. BENEFITS OF PROTOTYPING ENGMAISAK@HOTMAIL.COM 26 Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort.

27. THE PROCESS OF PROTOTYPE DEVELOPMENT ENGMAISAK@HOTMAIL.COM 27 Establish Prototype objectives Define Prototype Functionality Develop Prototype Evaluate Prototype

28. PROTOTYPE DEVELOPMENT ENGMAISAK@HOTMAIL.COM 28 May be based on rapid prototyping languages or tools Prototype should focus on areas of the product that are not well-understood; Error checking and recovery may not be included in the prototype; Focus on functional rather than non-functional requirements such as reliability and security

29. DRAWBACKS OF SOFTWARE PROTOTYPING ENGMAISAK@HOTMAIL.COM 29 The developer must explain to the customer that the system will be ready after completing all the requirements because most customers request to be delivered the system when ever he see the first version. Low quality.

30. INCREMENTAL DELIVERY ENGMAISAK@HOTMAIL.COM 30 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. User requirements are prioritised and the highest priority requirements are included in early increments. Define outline requirements Assign requirements to increments Design System Architecture Develop system increment Validate increment Integrate increment Validate System Deploy increment Final system System Incomplete? System complete?

31. INCREMENTAL DEVELOPMENT VS DELIVERY ENGMAISAK@HOTMAIL.COM 31 Incremental development Develop the system in increments and evaluate each increment before proceeding to the development of the next increment; Normal approach used in agile methods; Evaluation done by user/customer. Incremental delivery Deploy an increment for use by end-users; More realistic evaluation about practical use of software;

32. INCREMENTAL DELIVERY ADVANTAGES ENGMAISAK@HOTMAIL.COM 32 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 customer has chance to keep going with the versions incrementally. The highest priority system services tend to receive the most testing.

33. INCREMENTAL DELIVERY PROBLEMS ENGMAISAK@HOTMAIL.COM 33 Most systems require a set of basic facilities that are used by different parts of the system. It can be hard to identify common facilities that are needed by all increments. Iterative development can also be difficult when a replacement system is being developed. Users want all of the functionality of the old system and are often unwilling to experiment with an incomplete new system. Therefore, getting use-full customer feedback is difficult. The essence of iterative processes is that the specification is developed in conjunction with the software. However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract.

34. SPIRAL MODEL ENGMAISAK@HOTMAIL.COM 34 Spiral model = Prototype model + Waterfall model 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. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process. 1 Planning phase 2 Risk Analysis Phase 4 Customer Evaluation phase 3 Engineering Phase Boehm’s spiral model of the software process

35. SPIRAL MODEL PHASES ENGMAISAK@HOTMAIL.COM 35 Planning Phase Define the problem – Determine objectives-Determine constraints-define specifications-determine alternatives. Risk Analysis Phase Specifying solution methods for requirement change – Define risks and solution methods. Engineering Phase Detailed design –Coding- Unit Testing – Integration Testing Customer Evaluation Phase The customer reviews the project and the feedback will be taken place in the next phase.

36. Customer can review and change requirements can take place as soon as the customer delivers. In every spiral (Circle) the risks become narrow. Spiral model has been very influential in helping people think about iteration in software processes and introducing the risk-driven approach to development. The model is good for the large and complicated projects SPIRAL MODEL USAGE AND ADVANTAGES USAGE ADVANTAGES ENGMAISAK@HOTMAIL.COM 36

37. PROBLEMS IN SPIRAL MODEL ENGMAISAK@HOTMAIL.COM 37 Can be costly model to useRisk analysis requires highly specific expertiseProject’s success is highly dependent on the risk analysis phaseDoesn’t work well with the smaller projects

38. THE RATIONAL UNIFIED PROCESS (RUP) ENGMAISAK@HOTMAIL.COM 38 A modern generic process derived from the work on the UML and associated process. Brings together aspects of the 3 generic process models (Prototype-Incremental delivery and Spiral model) discussed previously.

39. RUP PHASES ENGMAISAK@HOTMAIL.COM 39 1.Inception : Establish the business case for the system. 2.Elaboration : Develop an understanding of the problem domain and the system architecture. 3.Construction : System design, programming and testing. 4.Transition: Deploy the system in its operating environment.

40. ADVANTAGES OF (RUP) ENGMAISAK@HOTMAIL.COM 40 Executed As Components(subs)Limited TimeLarge Group Job Plus CustomerUsing OOP TechnologySurely, the Product will have Efficiency

41. THE SIX FUNDAMENTAL BEST PRACTICES IN THE RUP ENGMAISAK@HOTMAIL.COM 41 Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software

42. PROBLEMS OF RUP ENGMAISAK@HOTMAIL.COM 42 The RUP is not a suitable process for all types of development, e.g., embedded software development.

43. BASIC PROCESS ACTIVITIES ENG. MOHAMED ADAM ISAK 43 Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence, whereas in incremental development they are inter-leaved.

44. REQUIREMENTS ENGINEERING PROCESSES 1) SOFTWARE SPECIFICATION ENG. MOHAMED ADAM ISAK 44 Software specification is the process of establishing what services are required and the constraints on the system’s operation and development. Requirements Engineering process: 1)Feasibility study : It should answer three key questions: a)Does the system contribute to the overall objectives of the organization? b) Can the system be implemented within schedule and budget using current technology? c)Can the system be integrated with other systems that are used? 2)Requirements analysis: What do the system stakeholders require or expect from the system? 3)Requirements specification: Defining the requirements in detail 4)Requirements validation: Checking the validity of the requirements

45. REQUIREMENTS ENGINEERING PROCESSES 2) SOFTWARE DESIGN AND IMPLEMENTATION ENG. MOHAMED ADAM ISAK 45 Software design and implementation is the process of converting the system specification into an executable system. 1.Software design means to design a software structure that realises the specification. 2.Implementation means to translate this structure into an executable program. The activities of design and implementation are closely related and may be inter-leaved.

46. A GENERAL MODEL OF THE DESIGN PROCESS ENG. MOHAMED ADAM ISAK 46

47. DESIGN ACTIVITIES ENG. MOHAMED ADAM ISAK 47 Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed. Component design, where you take each system component and design how it will operate. Interface design, where you define the interfaces between system components. Database design, where you design the system data structures and how these are to be represented in a database.

48. REQUIREMENTS ENGINEERING PROCESSES 3) SOFTWARE VALIDATION ENG. MOHAMED ADAM ISAK 48 Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. Involves checking and review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. Testing is the most commonly used V & V activity.  ‘Validation: It answers the question of “Are we building the right product? “  ‘Verification: It answers the question of “Are we building the product right?”

49. TESTING STAGES ENG. MOHAMED ADAM ISAK 49 Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. Component or Development testing Testing of the system as a whole. Testing of emergent properties is particularly important. System testing Testing with customer data to check that the system meets the customer’s needs. Acceptance testing

50. REQUIREMENTS ENGINEERING PROCESSES 4) SOFTWARE EVOLUTION ENG. MOHAMED ADAM ISAK 50 Software is flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change.

51. KEY POINTS ENG. MOHAMED ADAM ISAK 51 The software prototype focuses on functional requirements rather than non- functional requirements. In Spiral Model the risks are explicitly assessed and resolved throughout the process. The Rational Unified Process is organized into phases (inception, elaboration, construction and transition) Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.

52. ENGMAISAK@HOTMAIL.COM All the assignments, projects and questions will be sent to: CHAPTER 1 INTRODUCTION - SE - ENGMAISAK@HOTMAIL.COM 52 www.Engmaisak.Blogspot.Com Download the lesson from the official blog of the lecturer: