1. Software Engineering I Session 2
Software Processes

2. Recap Software = source code + MAMY MAMY OTHERS
What are these?
Software engineering is the engineering discipline that is concerned with all aspects of software production
With ties to many other subjects
For this module, SE encompasses two parts
Processes, methodologies, techniques, and tools
Project management
There is no single software engineering approach that is applicable to all systems
Code, libraries
Documentation (requirements, architecture, specifications)
Configuration data/files
Tests
Version control history, issue tracker
Build system files
Support websites

3. Today What is a software process? Why do we need a software process?
What are the essential activities of software development?
Why do we need a software process?
Software process models and their trade-offs
Software process improvements
Based on : chapter 3,4 and : chapter 2

4. Software Processes
A software process is a structured set of activities, actions, and tasks required to develop a software system.
Activity: achieve a broad objective (e.g., communication with stakeholders)
applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which SE is to be applied.
Action (e.g., architectural design): encompasses a set of tasks that produce a major artifact (e.g., an architectural model).
Task: focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.
After this process, some work products (artifacts) must be built.

5. Remarks
In the context of SE, a process is not a rigid prescription for how to build computer software.
it is an adaptable approach
the software team picks and chooses the appropriate set of work actions and tasks.
The intent is to deliver software in a timely manner and with sufficient quality to satisfy customers/users.
In reality, 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
those who have sponsored its creation and those who will use it

6. Process framework
A process framework establishes the foundation for a complete SE process, which encompasses
a small number of framework activities
are applicable to all software projects, regardless of their size or complexity.
communication, planning, modelling, construction, deployment
a set of umbrella activities
that are applicable across the entire software process
help a software team manage and control progress, quality, change, and risk.
E.g., project tracking and control, risk management, quality assurance, technical reviews, measurement, configuration management, reusability management, software artifacts preparation and production
Framework that is used to structure, plan and control the process of developing a software system

7. Software Process Activities
All software processes include these four fundamental 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.

8. Software Process Stages
All of these fundamental activity are complex activities
A group of logically-related SE sub-activities in a software process is referred to as a stage or a phase.
Each stage/phrase in the software 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.
What sub-activities, deliverables, roles and responsibilities, and pre- and post-conditions, would you assume are associated with the software specification phase?
In practice, most large
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.
systems are developed using a process that incorporates elements from all of these models

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

10. To put it differently …
Software process is a series of stages/phrases through which software is produced
From conception to end-of-life
Can take months or years to complete
Goals of each phase:
mark out a clear set of steps to perform
produce a tangible item
allow for review of work
specify actions to perform in the next phase
Each phase requires different tools, knowledge, skill sets.
There are a lot of ways to split responsibilities

11. Key question
Virtually all soft processes share these steps/stages/phrases or framework activities
How do you combine them, in which order?
Lifecycle stages
• Virtually all lifecycles share these steps/stages/phases:
– Requirements
– Design
– Implementation
– Testing
– Maintenance
• Key question: how do you combine them, and in
what order?

12. Process flow
Describes how the framework activities and the actions and tasks that occur within each framework activity are organised with respect to sequence and time.
A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment
An iterative process flow repeats one or more of the activities before proceeding to the next.
An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software.
A parallel process flow executes one or more activities in parallel with other activities (e.g., modelling for one aspect of the software might be executed in parallel with construction of another aspect of the software).

13. Software process diversity
A process adopted for one project might be significantly different than a process adopted for another project, in that
Overall flow of activities, actions, and tasks and the interdependencies among them.
Degree to which actions and tasks are defined within each framework activity.
Degree to which software artifacts are identified and required.
Manner in which quality assurance activities are applied.
Manner in which project tracking and control activities are applied.
Overall degree of detail and rigor with which the process is described.
Degree to which the customer and other stakeholders are involved with the project.
Level of autonomy given to the software team.
Degree to which team organization and roles are prescribed.
the software engineering process is not a rigid prescription that must be followed dogmatically by a software team. Rather,
it should be agile and adaptable (to the problem, to the project, to the team and to the organizational culture). Therefore, a process adopted for one project
might be significantly different than a process adopted for another project.

14. Why do we need processes?
Fixing bugs later is
harder and more costly
The later a problem is found in software, the more costly it is to fix!

15. Life without software processes
Advantages:
nothing to learn or plan!
work on whatever is interesting, ignore the rest.
Disadvantages:
may ignore some important tasks (testing, design)
not clear when to start or stop doing each task
scales poorly to multiple people
hard to review or evaluate one's work
code may not match user's needs (no requirements!)
code was not planned for modification, not flexible

16. Life with software process
Advantages:
Provides structure in which to work
Forces you to think about the big picture and to follow steps to reach it
Without it, you may make decisions that are locally optimal but globally misdirected
It is a management tool
Disadvantages:
Can lead to compromises and artificial constraints
Risk of over-emphasising process rather than the product itself!

17. From process to process models
Process? a series of predictable steps—a road map that helps you create a timely, high-quality result.
Who does it? Software engineers and their managers adapt the process to their needs and then follow it.
But what if I ask you to come up with a software process …
Process models? A process model provides a specific roadmap for SE work.
It defines the flow of all activities, actions and tasks, the degree of iteration, the artifacts, and the organisation of the work
What is it? When you work to build a product or system, it’s important
to go through a series of predictable steps—a road map that
helps you create a timely, high-quality result. The road map that you follow is called a “software
process.”
Who does it? Software engineers and their managers adapt the process to their needs and
then follow it. In addition, the people who have requested the software have a role to play in
the process of defining, building, and testing it.
Why is it important? Because it provides stability, control, and organization to an activity
that can, if left uncontrolled, become quite chaotic. However, a modern software engineering
approach must be “agile.” It must demand only those activities, controls, and work products
that are appropriate for the project team and the product that is to be produced.
What are the steps? At a detailed level, the process that you adopt depends on the software
that you’re building. One process might be appropriate for creating software for an aircraft
avionics system, while an entirely different process would be indicated for the creation
of a website.
What is the work product? From the point
of view of a software engineer, the work products
are the programs, documents, and data
that are produced as a consequence of the activities
and tasks defined by the process.
How do I ensure that I’ve done it right?
There are a number of software process assessment
mechanisms that enable organizations
to determine the “maturity” of their software
process. However, the quality, timeliness, and
long-term viability of the product you build are
the best indicators of the effi cacy of the process
that you use.
Process models were originally proposed to bring order to the chaos of
software development. History has indicated that these models have
brought a certain amount of useful structure to software engineering
work and have provided a reasonably effective road map for software teams.
However, software engineering work and the products that are produced remain
on “the edge of chaos.”

18. Software Process models
represent software processes in an abstract way …
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 Life Cycle (SDLC) models
Each process model represents a process from a particular perspective (only partial information of the process)

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

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

21. For this module Waterfall model Incremental process model
Evolutionary process model
Prototyping
The spiral model
Integration and configuration
Concurrent models
Traditional (aka prescriptive) process models
Specialised process models: component-based development
In the sections that follow, we examine the prescriptive
process approach in which order and project consistency are dominant
issues. We call them “prescriptive” because they prescribe a set of process
elements—framework activities, software engineering actions, tasks, work products,
quality assurance, and change control mechanisms for each project. Each
process model also prescribes a process flow (also called a work flow )—that is,
the manner in which the process elements are interrelated to one another.

22. Differences
All software process models can accommodate the generic framework activities
but each applies a different emphasis to these activities
and defines a process flow that invokes each framework activity (as well as actions and tasks) in a different manner.

23. Code-and-fix model

24. Code-and-fix model Advantages: Disadvantages:
Little to no overhead, see progress quickly
Applicable for very small projects and short-lived prototypes
Disadvantages:
No way to asses progress, quality, or risks
Unlikely to accommodate changes without a major design overhaul
Unclear delivery features (scope), timing, and support

25. The Waterfall Model
Separates the development process into distinct and discrete stages.
Directly reflect the fundamental 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?

26. Waterfall model advantages
Suitable for projects that are very well understood but complex
Tackles all planning upfront
The ideal of no midstream changes equates to an efficient software development process
Supports inexperienced teams
Orderly, easy-to-follow sequential model
Reviews at each stage determine if the product is ready to advance

27. Waterfall model disadvantages
Requires a lot of planning up front (not always easy)
assumes requirements will be clear and well-understood
Rigid, linear; not adaptable to change in the product
costly to "swim upstream" back to a previous phase
No sense of progress until the very end
no code to show until almost done
Integration occurs at the very end
defies “integrate early and often” rule
solutions are inflexible, no feedback until end
Delivered product may not match customer needs
phase reviews are massive affairs
inertia means change is costly

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

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…
Three very related models
Incremental model
Evolutionary models: including Spiral model and Prototyping
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
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 development
system increments are delivered to the customer for comment and experimentation.

30. Incremental model
The incremental model combines the elements of linear and parallel process flows
applies linear sequences in a staggered fashion as calendar time progresses.
Each linear sequence produces deliverable “increments” of the software

31. Incremental model
In incremental model, 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?
There are many situations in which initial software requirements are reasonably
well defi ned, but the overall scope of the development effort precludes a purely linear process. In addition, there may be a compelling need to provide a limited
set of software functionality to users quickly and then refi ne and expand on that
functionality in later software releases. In such cases, you can choose a process
model that is designed to produce the software in increments.

32. Incremental model advantages
Can ship at the end of any release
Looks like success to customers, even if not original goal
Intermediate deliveries show progress, satisfy customers, and lead to feedback
Problems are visible early (e.g., integration)
Facilitates shorter, more predictable release cycles
Changing requirements can be more easily accommodated, with reduced cost
Very practical, widely used and successful!
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).

33. Incremental model disadvantage
However, incremental development
Product must be decomposable
can lead system structure to degrade
code to become over-complex and messy as multiple new increments are added.
Requires tight coordination with documentation management, marketing
Extra releases cause overhead
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?

34. Evolutionary models Evolutionary models are
iterative
characterised in a manner that enables you to develop increasingly more complete versions of the software.
Two common evolutionary process models
Prototyping
The Spiral model

35. When to use prototyping?
Often, a customer defines a set of general objectives for software,
but does not identify detailed requirements for functions and features.
Or, the developer may be unsure of
the efficiency of an algorithm,
the adaptability of an operating system, or
the form that human-machine interaction should take.
In these (and many other) situations, a prototyping paradigm may offer the best approach.
A prototype is an initial version of a system used to demonstrate concepts and try out design options.

36. Evolutionary prototyping model
Develop a skeleton system and evolve it for delivery
Requirements Definition/Collection
Design
Prototype Creation/Modification
Assessment
Prototype Refinement
System Implementation
Either the system is rewritten once requirements are understood
Or the Iterative process eventually produces a working system that can be the cornserstone for the fully functional system
Requirements Definition/Collection. Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements.
Design. Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype.
Prototype Creation/Modification. The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding.
Assessment. The prototype is presented to the customer for review. Comments and suggestions are collected from the customer.
Prototype Refinement. Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient.
System Implementation. In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornserstone for the fully functional system.
Different from incremental models in
that requirements are not known
ahead of time. Discovered by
feedback.

37. Prototyping Prototyping can be used as a stand-alone process model
But more commonly used as a technique that can be implemented within the context of any one of the process.
Regardless of the manner in which it is applied, the prototyping paradigm help better understand what is to be built when requirements are fuzzy.
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.
A popular variation of the Prototyping: Rapid Application Development (RAD).
RAD introduces strict time limits on each development phase and
relies heavily on rapid application tools which allow for quick development.

38. Pros and cons Addresses risks early
Requires close customer involvement
Assumes user's initial spec is flexible
Problems with planning
especially if the developers are inexperienced
feature creep, major design decisions, use of time, etc.
hard to estimate completion schedule or feature set
unclear how many iterations will be needed to finish
Integration problems
fails for separate pieces that must then be integrated
bridging; new software trying to gradually replace old
Temporary fixes become permanent constraints
Requires low friction deployment and experimentation
Addresses risks early
Steady signs of progress build customer confidence
Useful when requirements are unknown or changing
Participatory design/useful feedback loops
A closer match to users’ real needs
Improved design quality
Improved maintainability
Very practical, widely used and successful
Benefits
Improved system usability
A closer match to users’ real needs
Improved design quality
Improved maintainability
Reduced development effort

39. Spiral Model
Designed to include the best features from the Waterfall and Prototyping Models
introduces a new component : risk-assessment.
Similar to the Prototyping Model
an initial version of the system is developed,
then repetitively modified based on input received from customer evaluations.
Unlike the Prototyping Model
the development of each version of the system is carefully designed using the steps involved in the Waterfall Model.
With each iteration around the spiral (beginning at the centre and working outward), progressively more complete versions of the system are built
Barry Boehm
The term “spiral” is used to describe the process that is followed as the development of the system takes place.

40. Spiral model – risk oriented
Determine objectives and constraints
Identify and resolve risks
Evaluate options to resolve risks
Develop and verify deliverables
Plan next spiral
Commit (or not) to next spiral
Oriented towards phased reduction of risk • Take on the big risks early, make decisions – are we building the right product? – do we have any customers for this product? – is it possible to implement the product with the technology that exists today? tomorrow? • Progresses carefully to a result – tasks can be more clear each spiral

41. Advantages vs disadvantages
Especially appropriate at the beginning of the project, when the requirements are still fluid
Provides early indication of unforeseen problems
Accommodates change
As costs increase, risks decrease!
Always addresses the biggest risk first
But, a lot of planning and management
Frequent changes of task
But, get to stick with one product feature/goal
Requires customer and contract flexibility
Developers must be able to assess risk
Must address most important issues

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

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

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

45. Let’s revisit these Waterfall Prototyping The Spiral model
Throwaway prototyping, Evolutionary prototyping, Incremental prototyping, Extreme prototyping (web applications), Rapid application development (RAD)
The Spiral model
Waterfall+prototyping+risk analysis
Incremental Model
A series of mini-waterfall
The reuse model
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.

46. Why are there so many models?
The choice of a model depends on the project circumstances and requirements.
A good choice of a model can result in a vastly more productive environment than a bad choice.
A cocktail of models is frequently used in practice to get the best of all worlds. Models are often combined or tailored to environment.

47. What’s the best model for …
A system to control anti-lock braking in a car
A hospital accounting system that replaces an existing system
An interactive system that allows airline passengers to quickly find replacement flight times (for missed or bumped reservations) from terminals installed at airports
A mobile app for finding romantic partners

48. What’s the best model? Consider Aim for good, fast, and cheap.
The task at hand
Risk management
Quality / cost control
Predictability
Visibility of progress
Customer involvement and feedback
Aim for good, fast, and cheap.
But you can’t have all three at the same time.

49. Model category matrix (on a scale from 1 to 5)
Risk mgmt.
Quality/cost
control
Predictability
Visibility of progress
Customer
Involvement
Code-and-fix 1 3 2
Waterfall 4
Spiral 5
Prototyping
Incremental

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

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

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

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

54. 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 standardised and documented across the organisation. 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?