02 - Software Processes (Part 1).pdf

Chapter 2 – Software Processes Lecture 2 Source: SE10 by Ian Sommerville Chapter 2 Software Processes 1 Topics: Software Process:- ✧Software process activities (revision from Lecture 1) ✧Software process...

Chapter 2 – Software Processes Lecture 2 Source: SE10 by Ian Sommerville Chapter 2 Software Processes 1 Topics: Software Process:- ✧Software process activities (revision from Lecture 1) ✧Software process models Coping with change Source: SE10 by Ian Sommerville 2 Software Process Definition Software Process: A set of activities required to develop a software system. When we describe and discuss about software processes, we usually talk about the following:- ✧Software process activities (revision from Lecture 1) Including sub- activities such as specifying a data model, designing a user interface, etc ✧Software process model is a simplified representation of a software process activities and the ordering of these activities and sub-activities. (Example: Waterfall Model, Incremental Development, Reuse-oriented software engineering). Source: SE10 by Ian Sommerville Chapter 2 Software Processes 3 Software Process Descriptions ✧ When we describe and discuss about software processes, we also talk about: ▪ Products: outcomes of a software process activity. (Example: outcome of activity “designing graphical user interface” is “user graphical interface design”) https://www.pngwing.com/en/search?q=graphi cal+User+Interface#google_vignette ▪ Roles, who is responsible of a software process activity. (Example: requirements engineer is responsible of activity “designing graphical user interface”). ▪ Pre- and post-conditions, which are statements that are true before and after a software process activity. (Example: before activity “designing graphical user interface” begin, requirements engineer must understand the defined requirements, user preference related to GUI. Post-condition: user approve the design). Source: SE10 by Ian Sommerville Chapter 2 Software Processes 4  Software Process Descriptions Let’s test our understanding. Software process activity called “S/W development”. Products: (What is the outcome of S/W development activity) A software design and computer program Roles: (Who is responsible of S/W development activity?) Developer: Design and writes code Pre- and post-conditions, (What is the pre-condition and post condition of S/W development activity) Pre-conditions: Requirements for the software are defined. Development environment is set up. Developer are available. Post-conditions: The software is functional and meets requirements. Source: SE10 by Ian Sommerville Chapter 2 Software Processes 5 Software Process Descriptions (More example) Process Description: Software process activity called “S/W development” for Calculator Application ✧ Products: An application design and functional calculator application ✧ Roles: ▪ Developer: Design and writes code ✧ Pre-conditions: ▪ Requirements for the calculator application are defined. ▪ Development environment is set up. ▪ Developer are available. ✧ Post-conditions: ▪ The calculator application is functional and meets requirements. Source: SE10 by Ian Sommerville Chapter 2 Software Processes 6 Do you know that… There is no ideal software process. Most organizations have developed their own software development processes depending on: People involved in a software project Characteristic of the software being develop (Example: critical systems such as aircraft system required Plan-driven approach. For software with rapidly changing requirements, less formal, flexible software process like agile likely to be more effective. Source: SE10 by Ian Sommerville Chapter 2 Software Processes 7 Plan-driven and agile processes ✧ 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. Source: SE10 by Ian Sommerville Chapter 2 Software Processes 8 Software process models Related video: https://www.youtube.com/watch?v=laSrDtYtkXU&list=PLCku-ULHIQvlLC2gFqeoX-JtbEvmeoDhl&index=1 1. The waterfall model ▪ An example of a plan-driven process. ▪ Separate phases of specification and development. 2. Incremental development ▪ A fundamental part of agile approaches ▪ Specification, development and validation are interleaved. ▪ May be plan-driven or agile. 3. Reuse-oriented software engineering ▪ 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. Source: SE10 by Ian Sommerville Chapter 2 Software Processes 9 1. The waterfall model Take home assignment: Please watch this video on your own: https://edpuzzle.com/assignments/66d3ccda44a1a225db342edc/watch Source: SE10 by Ian Sommerville Chapter 2 Software Processes 10 Waterfall model limitations 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. But……! Inflexible partitioning of the project into phases makes it difficult to respond to changing customer requirements. Source: SE10 by Ian Sommerville Chapter 2 Software Processes 11 Waterfall model limitations – cont. The difficulty of accommodating change after the process is underway. In principle, a phase has to be complete 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. However, few business systems have stable requirements! :( Source: SE10 by Ian Sommerville Chapter 2 Software Processes 12 2. Incremental development Source: SE10 by Ian Sommerville Chapter 2 Software Processes 13 Incremental development benefits ✧ The cost of accommodating changing customer requirements is reduced as 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. Source: SE10 by Ian Sommerville Chapter 2 Software Processes 14 Incremental development problems ✧ 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. ✧ The specification is developed in conjunction with the software. In many organizations, the *complete* system specification is part of the system development contract!! Source: SE10 by Ian Sommerville Chapter 2 Software Processes 15 3. Reuse-oriented software engineering Reuse-Oriented Software Engineering - Based on systematic reuse where systems are integrated from existing components or COTS (Commercial- off-the-shelf) systems Source: SE10 by Ian Sommerville Chapter 2 Software Processes 16 Key process stages of reuse ✧ Requirements specification ✧ Software discovery and evaluation ✧ Requirements refinement ✧ Application system configuration ✧ Component adaptation and integration Source: SE10 by Ian Sommerville 30/10/2014 Chapter 2 Software Processes 17 Advantages and disadvantages ✧ Reduced costs and risks as less software is developed from scratch ✧ Faster delivery and deployment of system ✧ But requirements compromises are inevitable so system may not meet real needs of users ✧ Loss of control over evolution of reused system elements Source: SE10 by Ian Sommerville 30/10/2014 Chapter 2 Software Processes 18 Any Questions 19