Software Engineering I Session 2

1. Software Engineering ISession 2 Software Processes

2. Recap • Software = program + configuration files+ documentation+… • Software engineering is the engineering discipline that is concerned with all aspects of software production • Software engineering encompasses two parts • Processes, methodologies, techniques, and tools • Project management • There is no single software engineering approach that is applicable to all systems

3. Processes • A process is a systemised and logicalsequence of steps taken to achieve a pre-defined outcome. • Each step in a process has a known input and a known output. • Each step consumes a known set of resources. • Processes produce feedback. Feedback can be monitored. Processes can be improved.

4. Software Processes • A software process is a structured set of activities required to develop a software system • In reactivity, there are (already) many different software processes • Most software companies have their own development processes • Different characteristics of the systems that are being developed • There is no universally applicable software process

5. Software Process Activities • All software processes include the following four fundamental software engineering activities.

6. Remarks • All of these activities are complex activities • Each one includes sub-activities • When describing and discussing processes, we usually talk about the activities in these processes • such as specifying a data model, designing a user interface, etc • the ordering of these activities. • However, process descriptions may also include: • Products, which are the outcomes of a process activity; • Roles, which reflect the responsibilities of the people involved in the process; • Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.

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 • Agile processesare processes where 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. • Then how do we study these software processes?

8. Software Process models • Standard approach: we represent software processes in an abstract way • This is called modelling • A software process model is an abstract representation of the software development process • It represents a high-level description of the process. • In literature, also called Software Development Lift Cycle (SDLC) models • Each process model represents a process from a particular perspective (only partial information of the process)

9. Software Process Stages • A group of logically-related software engineering activities in a software process model is referred to as a stage or a phase. • Each stage in the software engineering process will normally include the following: • A set of products or deliverables that serve as the outcome of the stage. • A clearly defined set of roles and responsibilities for people involved in the stage. • A set of pre-conditions and post-conditions that must hold before the process is started and before it is considered complete.

10. Software Process Stages – Example

11. There are many models • Waterfall model • Iterative development • Prototyping (not standalone and complete, but handle selected portions) • Throwaway prototyping, Evolutionary prototyping, Incremental prototyping, Extreme prototyping (web applications) • The exploratory model • Rapid application development (RAD) • The Spiral model (emphasising risk analysis) • Iterative and Incremental Model • The reuse model • Creating and Combining Models • Parts and procedures from various process models are integrated to support system development

12. There are really many manymodels ;-) • Behaviour-driven development and business process management • Chaos model - The main rule is always resolve the most important issue first. • Incremental funding methodology - an iterative approach • Lightweight methodology - a general term for methods that only have a few rules and practices • Structured systems analysis and design method - a specific version of waterfall • Slow programming, as part of the larger Slow Movement, • V-Model (software development) - an extension of the waterfall model • Unified Process (UP) is an iterative software development methodology framework, based on Unified Modelling Language (UML).

13. Three Generic models • Our textbook: • Waterfall • Incremental development • Integration and configuration

14. The Waterfall Model • Separates the development process into distinct and discrete stages. • Directly reflect the fundamental software development activities: • Analysis, modelling, design, implementation, testing, deployment and maintenance. • In theory, one stage of the waterfall process must be completed before the next stage begins • In practice, there is often enforced overlap between stages, as well as feedback from later phases to earlier phases • e.g. the design phase reveals problems in the requirements specification and the requirements must be changed • Formal development

15. The Waterfall Model

16. The Waterfall Model • The waterfall model is most appropriate for: • Embedded systems, where the software has extensive interfaces with hardware. • Safety-Critical Systems, where safety and security requirements must be specified fully in advance of development. • Large systems engineering projects, where a system is developed at several sites. Here, the plan-driven nature of the waterfall model helps coordinate the work. • The waterfall model is not appropriate for any system where • requirements are not fully articulated upfront, • are ambiguous, or • are subject to change during development and testing • i.e. the vast majority of software projects ;-).

17. V-Shaped model • An extension of the waterfall model, • Instead of moving down in a linear way • the process steps are bent upwards after the implementation and coding phase, to form the typical V shape. • The major difference between V-shaped model and waterfall model is the early test planning in the V-shaped model.

18. Linear model: waterfall and V-shaped • The usage • Software requirements clearly defined and known • Software development technologies and tools are well-known

19. Three Generic models • Waterfall • Incremental development • Integration and configuration

20. Incremental Development • In incremental development,software is developed in a series of increments until complete. • Functionality is added increment by increment, with the most important functionality generally being added during earlier increments. • Each increment is available for testing by developers and users, and feedback is incorporated into subsequent increments. • Specification, development and validation activities are interleaved rather than separate, with rapid feedback across activities.

21. Incremental Development

22. Incremental Development • Incremental development can be either plan-driven or agile in nature. • In a plan-driven approach, system increments are identified in advance. • If an agile approach is adopted, only earlier increments are identified: the development of later increments depends on progress and customer priorities.

23. Incremental Development • With incremental development: • Changing requirements can be more easily accommodated. • The cost of accommodating changing requirements is reduced. • Customers and users can provide valuable feedback on successive increments. • Rapid delivery and deployment of useful software to the customer is possible. • There is considerably less risk than developing an entire system in a single increment (e.g. the waterfall process). • However, incremental development can • lead system structure to degrade and • code to become over-complex and messy as multiple new increments are added.

24. Three Generic models • Waterfall • Incremental development • Integration and configuration

25. Integration and Configuration • Integration and configuration based development involves creating new systems from existing software or software components. • Three types of software component are frequently (re)used: • Stand-alone application systems (sometimes called COTS, commercial off-the-shelf) that are configured for use in a particular environment. • Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. • Web services that are developed according to service standards and which are available for remote invocation.

26. Integration and Configuration • A general process model for reuse-based development.

27. Software reuse • Software reuse can follow a plan-driven or an agile approach • The development process for software reuse can also be either linear or incremental • A reuse approach to software development can: • Reduce development times and costs • Reduce risk • Improve standards compliance • Promote interoperability • However, software reuse may involve: • Compromise on requirements • Loss of control over system evolution

28. Let’s revisit these • Waterfall • Framework type: linear • Prototyping • Framework type: iterative • Throwaway prototyping, Evolutionary prototyping, Incremental prototyping, Extreme prototyping (web applications) • Rapid application development (RAD) • The Spiral model • Combination of linear and iterative • Waterfall+prototyping+risk analysis • Iterative and Incremental Model • Combination of linear and iterative • A series of mini-waterfall • The reuse model

29. Cope with changes • 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 • Coping with changing requirements • System prototyping • a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions • Incremental delivery • system increments are delivered to the customer for comment and experimentation.

30. Software prototyping • 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. • Benefits • Improved system usability • A closer match to users’ real needs • Improved design quality • Improved maintainability • Reduced development effort

31. Software Process Improvement • Many software companies have turned to software process improvement as a way of enhancing the quality of their software, reducing costs and accelerating their development processes. • Process improvement means • understanding existing processes, and • improving these processes to increase product quality and/or reduce costs and development time.

32. Software Process Improvement Cycle • Process measurement • One or more attributes of the software process is measured. Measurements form a baseline that helps decide if process improvements have been effective. • Process analysis • The current process is assessed, and process weaknesses and bottlenecks are identified. Process models that describe the process may be developed. • Process change • Process changes are proposed to address some of the identified process weaknesses. These are introduced and the cycle resumes to collect data about the effectiveness of the changes.

33. Process measurement • Wherever possible, quantitative process data should be collected • However, where organisations do not have clearly defined process standards this is very difficult as you don’t know what to measure. • A process may have to be defined before any measurement is possible. • Process measurements should be used to assess process improvements • But this does not mean that measurements should drive the improvements • The improvement driver should be the organisational objectives.

34. Process metrics • Time taken for process activities to be completed • E.g. Calendar time or effort to complete an activity or process. • Resources required for processes or activities • E.g. Total effort in person-days. • Number of occurrences of a particular event • E.g. Number of defects discovered.

35. Software Process Improvement Approaches • The process maturity approach, which focuses on improving process and project management, and introducing good software engineering practice. • The level of process maturity reflects the extent to which good technical and management practice has been adopted in organisational software development processes. • The agile approach, which focuses on iterative development and the reduction of overheads in the software process. • The primary characteristics of agile methods are rapid delivery of functionality and responsiveness to changing customer requirements.

36. The Capability Maturity Model • The Capability Maturity Model is a framework • for ascertaining the effectiveness of software development processes within an organisation. • The CMM describes the processes and practices that define a maturity level • but not the specifics of those processes and practices.

37. The Capability Maturity Model

38. Interesting reading • The End of Software Engineering and the Last Methodologist • By Bertrand Meyer, January 17, 2018 • https://en.wikipedia.org/wiki/Bertrand_Meyer • https://cacm.acm.org/blogs/blog-cacm/224352-the-end-of-software-engineering-and-the-last-methodologist/fulltext

39. (Post-) Class activities • THE four case studies • Exercises in the textbook • Software process improvement case study