1. Practical Software Engineering Session 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. Interesting reading
The End of Software Engineering and the Last Methodologist
By Bertrand Meyer, January 17, 2018
engineering-and-the-last-methodologist/fulltext

4. Processes
A process is a systemised and logical sequence 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.
Can you think of examples of processes we encounter in our daily lives?

5. 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
What is meant by the term, abstract representation?
What is meant by the term high level description?

6. Software Process Activities
All software processes include the following four fundamental software engineering activities.
Software specification
Defining the software and specifying constraints on its use.
Software development
Designing and building the software.
Software validation
Testing the software to ensure it meets requirements, is safe, secure, dependable and reliable.
Software evolution
Modifying the software to meet changes in the business or organisational context.
Is there a necessary order for software engineering activities? Do they have to be performed in the order specified above?
Can any of the four fundamental software process be safely skipped?
Reliability means that the program doesn’t crash.
Dependability means that the program always gives correct results.

7. 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.

8. 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 processes are 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?
1. In what circumstances would it be important to plan all aspects of a software project are planned in detail in advance?

9. 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)

10. 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.
1. What sub-activities, deliverables, roles and responsibilities, and pre- and post-conditions, would you assume are associated with the software specification phase?

11. Software Process Stages – Example
Software Specification Stage
Sub-activities
Requirements analysis, requirements specification, constraints specification.
Deliverables
Specification of functional and non-functional requirements. Specification of system constraints.
Roles and responsibilities
Systems analysts, project manager.
Pre-conditions
Feasibility study finished. Business case approved. Resources allocated.
Post-conditions
Functional and non-functional requirements, and constraints, completed, reviewed and signed off.
What sub-activities, deliverables, roles and responsibilities, and pre- and post-conditions, would you assume are associated with the software development phase?

12. There are many models Waterfall model Iterative development
A number of process models have evolved from the iterative approach
Prototyping
Rapid application development (RAD), Throwaway prototyping, Evolutionary prototyping, Incremental prototyping, Extreme prototyping (web applications)
The exploratory model
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
The problems with the Waterfall Model created a demand for a new method of developing
systems which could provide faster results, require less up-front information, and offer greater
flexibility. With Iterative Development, the project is divided into small parts. This allows the
development team to demonstrate results earlier on in the process and obtain valuable feedback
from system users. Often, each iteration is actually a mini-Waterfall process with the feedback
from one phase providing vital information for the design of the next phase. In a variation of this
model, the software products which are produced at the end of each step (or series of steps) can
go into production immediately as incremental releases.
Rapid-application development (RAD) is both a general term used to refer to alternatives to the conventional waterfall model of software development as well as the name for James Martin's approach to rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on process. In contrast to the waterfall model, which calls for rigorously defined specification to be established prior to entering the development phase, RAD approaches emphasize adaptability and the necessity of adjusting requirements in response to knowledge gained as the project progresses. Prototypes are often used in addition to or sometimes even in place of design specifications.
RAD is especially well suited for (although not limited to) developing software that is driven by user interface requirements. Graphical user interface builders are often called rapid application development tools. Other approaches to rapid development include Agile methods and the spiral model.

13. There are really many many models ;-)
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).
Other high-level software project methodologies include:
Slow programming, as part of the larger Slow Movement, emphasizes careful and gradual work without (or minimal) time pressures. Slow programming aims to avoid bugs and overly quick release schedules.
UP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development: inception, elaboration, construction, and guidelines. Many tools and products exist to facilitate UP implementation. One of the more popular versions of UP is the Rational Unified Process (RUP).

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

15. 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
1. What would the drawbacks be of having to fully complete one stage of a software development project before the next stage begins?

16. The Waterfall Model

17. 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 ;-).
Give examples of embedded systems.
Give examples of critical systems.
Why do think system requirements are likely to change during the course of most software projects?

18. 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.

19. Linear model: waterfall and V-shaped
The usage
Software requirements clearly defined and known
Software development technologies and tools are well-known
Advantages
Disadvantages
Simple and easy to use
Each phase has specific deliverables.
Higher chance of success over the waterfall model
due to the development of test plans early on during
the life cycle.
Works well for where requirements are easily
understood.
Verification and validation of the product in early
stages of product development.
Very inflexible, like the waterfall model.
Adjusting scope is difficult and expensive.
The software is developed during the
implementation phase, so no early prototypes of
the software are produced.
The model doesn’t provide a clear path for
problems found during testing phases.
Costly and required more time, in addition to
detailed plan

20. Three Generic models Incremental development Waterfall
Integration and configuration

21. 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.
What would be the advantages of developing a software product in increments?
What might be the disadvantages?

22. Incremental Development

23. 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.
1. For what kind of software might an incremental plan-driven approach to development be applicable?

24. 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.
Why does an incremental approach to development pose less risk than a linear approach?
Why is user feedback during development so important?
Why might incremental development lead to system structure degrading and code becoming over-complex and messy?

25. Three Generic models Integration and configuration Waterfall
Incremental development
Integration and configuration

26. 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.
What are the advantages of using pre-existing software components and services during development?
What might the disadvantages of such an approach be?

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

28. 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
What is meant by standards compliance in software terms?
What is meant by interoperability?
Is it necessarily true that a software reuse approach to development improves standards compliance and promotes interoperability?

29. Let’s revisit these Waterfall model Iterative development
A number of process models have evolved from the iterative approach
Prototyping
Rapid application development (RAD), Throwaway prototyping, Evolutionary prototyping, Incremental prototyping, Extreme prototyping (web applications)
The exploratory model
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

30. 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. 1.

31. 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.
1. Which attributes of the software development process are measurable?

32. 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.

33. Process metrics Time taken for process activities to be completed
30/10/2014
Chapter 2 Software Processes
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.

34. 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.

35. 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.

36. The Capability Maturity Model
1. Initial
Ad-hoc. Chaotic. No processes or processes ignored. Missed deadlines. Poor quality end-product.
2. Managed
Basic project management in place. Able to repeat success based on prior experience. Basic software development activities carried out.
3. Defined
Management and engineering processes are standardized and documented across the organization. Projects use approved versions of standard process definitions.
4. Quantitatively managed
The software process is under statistical control. Strong knowledge and use of metrics and statistical techniques. Schedule and quality performance is predictable
5. Optimising
Continuous process improvement is enabled by quantitative feedback and from piloting innovative practices and new technologies.
Where on the CMM scale do you think the majority of organisations fall?
Where do you believe organisations you work for or have worked for fall on the scale?

37. Class activities THE four case studies Exercises in the textbook
Software process improvement case study