HCT210 Lecture Notes - Unit 1

University of Zimbabwe
Department of Computer Science
HCT210: Software Engineering
Unit 1 : The Software Process
Lecturer: Gibson Mukarakate

Acknowledgements: main course text: “Roger Pressman , Software engineering: A practitioner’s approach”, 7th edition, 2010
Unit 1: The Software Process
Unit Outline
• Introduction
• The Software Process
• Software Process models
• Agile software development process
HCT210: Software Engineering Gibson Mukarakate 2

Introduction
• Software Engineering is the process, collection
of methods (practice) and tools that are used
to build high-quality computer software in a
timely manner.
• Software is now involved in almost every
aspect of modern life.
• Software comprises of instructions that are
executed, data structures and descriptive
information (in soft and hard form)
Software domains
1. System software
 Services other programs, e.g. operating systems,
compilers
2. Application software
 Stand-alone software to solve specific business
problems
3. Engineering/ Scientific software
 Usually numerical (“number crunching”)
4. Embedded software
 Resides within a product/system/device for
specific control features
Software domains
5. Product-line software
 Provides specific capability of line of
customers/businesses, e.g. accounting
6. Web applications (“Web Apps”)
 Use the browser as client, and are “client-server”
in nature
7. Artificial Intelligence (AI) software
 Mainly uses non-numerical algorithms to solve
complex problems not easily solved by
computation or straight-forward analysis
Software Process – Framework

Overview
Five (5) activities in the generic process
framework:
1. Communication: objectives, requirements
2. Planning: tasks, risks, resources
3. Modeling: detailed sketches of requirements
and the design to achieve them
4. Construction: solutions building, coding,
testing
5. Deployment: delivery, use, feedback, change
management
Software Process – Umbrella

activities
Activities that happen throughout the process:
1. Project tracking and control
2. Risk management
3. Quality assurance
4. Technical reviews
5. Measurement
6. Software configuration management (SCM)
7. Reusability management
8. Work product preparation and production
Software Process:
Generic Framework Summary
Framework Activities
Communication
Activities
Umbrella
Planning
Modeling
Construction
Deployment

Software engineering: Principles

Seven (7) key general principles:
1. The reason it all exists (to provide value to
stakeholders)
 All others support this one
2. Keep It Simple, Stupid! (KISS principle)
 Simple results in easier understanding and
maintenance
3. Maintain the Vision
 Complying to one, clear vision of the architecture
4. What you Produce, others will Consume
 Someone else will need to understand and use the
software

Software engineering: Principles

Seven (7) key general principles, continued:
5. Be Open to the Future
 Longer software lifetime means more value:
design for future capability and flexibility
6. Plan Ahead for Reuse
 Reuse saves time and effort
7. Think!
 Always think clearly and thoroughly before doing
any action. Learn if something is clear / known.

Process Models: Summary

1. Linear process flow
Communication Planning Modeling Construction Deployment
2. Iterative process flow

Communication Planning Modeling Construction Deployment

Process Models: Summary

3. Evolutionary process flow
Planning Modeling
Communication Construction
Increment Deployment
released
4. Parallel process flow

Communication Planning
Modeling
Construction Deployment

Process Models: 1. Prescriptive

• Originally proposed to address chaos that
was within software engineering … so were
among the first and oldest
• They define a prescribed set of process
elements and a predictable process workflow
• Examples are:
1. Waterfall model
2. Incremental models
3. Evolutionary models (prototyping, spiral)
4. Concurrent models


- Waterfall model
• Systematic, linear and sequential approach
through the framework activities
• Also called the classic life cycle
• Advantages:
i. Simple to understand and follow
ii. Effective for requirements that remain fixed, and
implementations of existing software
• Disadvantages:
i. Cannot accommodate changing requirements
ii. In many cases, customers cannot fully define all
requirements up front
iii. Mistakes are discovered too late (usually at deployment);
and it will be costly to correct
iv. Resources wasted by waiting (“blocking states”)

- Incremental models
• Applied were requirements are fairly well
defined from the start; ad there is need to
quickly deliver functionality to users
• Thus the functionality is defined into sets,
usually starting with the most high priority …
to define multiple releases / increments of
the software as time goes on
• First increment is called the core product
• Usually combines linear and parallel process
flows

- Evolutionary models
• Software and business requirements tend to
change over time … they are evolutionary
• Also, creating a comprehensive system that
covers everything at once is very difficult
• There is need for a model that also evolves;
and this is where evolutionary models come
in; e.g.
i. Prototyping
ii. Spiral
• Evolutionary models are typically iterative

- Evolutionary models: Prototyping
• Usually applies in the following scenarios:
i. Users have not yet identified detailed
requirements
ii. Developers unsure about facets of the software:
the algorithms, operating environment,
programming language, of efficiency
• Usually used with other models like; and
comprise of quick steps in delivering a
“prototype” to the customer; which then
serves to give more detailed requirements
for the final / actual system

- Evolutionary models: Prototyping
• Prototypes are typically discarded because
their quality and long-term maintainability
are compromised by their “quick” production
• Prototyping has the following drawbacks
i. When stakeholders see the prototype working,
they pressure the developers to convert it to the
full working product, compromising quality
ii. Developers may become “comfortable” with the
prototype, move it into production and
compromise quality

- Evolutionary models: Spiral model
• Provides for rapid development of increasingly
more complete (and thus more complex)
versions of the software
• Combines iterative nature of prototyping and
controlled and systematic aspects of the
waterfall model
• This risk-based approach has two key aspects:
i. Cyclic approach for incrementally growing a
system’s degree of definition / functionality
ii. Anchor point milestones to ensure stakeholder
commitment to feasible & satisfactory solutions

- Evolutionary models: Spiral model
• The spiral model is ideal for:
i. Use for whole lifecycle of a software system
ii. Use for large-scale software systems; that may
happen over a long time
iii. Risk reduction
• The disadvantages of the spiral model are
i. Maybe difficult to convince customers
ii. Demands excellent risk identification capabilities: if a
major risk is not identified, there will be issues with
the customer


- Concurrent models
• A model where various activities of the
software process being done concurrently
maybe in different states
• E.g. framework activities communication,
modeling and construction can happen
concurrently, but are in different states
• It reflects a proper state of the whole project,
not others that present it a sequence of
events
Process Models: 2. Specialised

• Applied to specialised / narrow cases, but
taking various facets from the traditional
models
• Examples are:
i. Component-based development
ii. Formal methods model
iii. Aspect-oriented software development


- Component-based development
• Approach is to take components from already
available off-the-shelf software that has parts
of required functionalities and integrating
them
• Similar to spiral: evolutionary and iterative
• Key steps are: identification of components,
overall architectural design, integration of
the components, and then testing


- the Formal Methods model
• Uses the formal mathematical specification
of software
• They help to eliminate some major
headaches of software engineering like
incompleteness, ambiguity and inconsistency
• It promises defect-free software
• Its challenges are: time-consuming, need for
highly specialised developers, difficult to
communicate with nontechnical users

- Aspect-oriented programming (AOP)
• Addresses cross-cutting concerns (aspects) in
software
• It focuses on identifying and constructing
aspects which are common “across
functionality” / “business logic”
• Example aspects are: security, access control,
logging, resource management
• The model uses approaches from the
concurrent models
Process Models: 3. The Unified Process

• Designed by Ivar Jacobson, Grady Booch &
James Rumbaugh as a “use case driven,
architecture centric, iterative and
incremental” approach
• Their work was influential and resulted in the
formation of the Unified Modeling Language
(UML) and the Rational Unified Process (RUP)
• UML is the de-facto standard for annotation
of artefacts in object-oriented analysis and
design

• UP may be seen as an attempt to take the
best characteristics of traditional models and
implement the agile approach
• It’s iterative and incremental and five (5) key
phases:
i. Inception
ii. Elaboration
iii. Construction
iv. Transition
v. Production

• The diagram below shows how the phases
are related to the generic framework
activities
Generic Framework Activities Unified Process Phases
Communication
Inception
Planning
Elaboration
Modeling
Construction
Construction
Transition
Deployment
Production

Process Models: 4. Personal and Team

Process Models
• Personal Software Process (PSP) aims to adapt the
software process to suit the person who is developing
the software, and to improve that person
• It gives responsibility for project planning (estimation
and scheduling) to the person (software practitioner)
• The following are the activities it defines to improve a
developer:
– Planning
– High-level design
– High-level design review
– Development
– Post-mortem
Process Models: 4. Personal and Team

Process Models
• In PSP, the post-mortem activity entails analysing
(including statistically) all the metrics collected in the
earlier activities so that improvements can be made
to produce high quality software
• It is thus a rigorous requires discipline of the
practitioner
• PSP is effective when adopted holistically, and this can
be its weakness
• Team Software Process (TSP) is an approach the uses
principles of PSP to scale (as most projects are done
by teams) to create “self-managing” teams that
produce high quality software
Process Models: summary

1. Prescriptive models
i. Waterfall model
ii. Incremental models
iii. Evolutionary models (prototyping, spiral)
iv. Concurrent models
2. Specialised models
i. Component-based development
ii. Formal methods
iii. Aspect-oriented programming
3. The Unified Process
4. Personal and Team process models
i. PSP
ii. TSP
Agile Development
• Established around 2001, when Kent Beck and
others came up with the “Manifesto for Agile
Software Development”
• It seeks to value:
 Individuals and interactions over processes and
tools
 Working software over comprehensive
documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
• While it values items on the right, it values those
items on the left more

Agile Development
• Definitions of agile development focus highlight
the following:
i. Agile is flexible to respond to change and
incorporates support for change in all aspects of
software
ii. Software teams are made up of people with human
frailties (they are not robots); thus they are different
in skills, orderliness, creativity, etc
iii. Emphasizes communication within project teams
and with the customer (in fact, customer is
embraced as part of the development team)
iv. Emphasis of delivery of working increments of the
system
What makes a process agile?

• Any agile is characterised by the following
assumptions of software projects
i. We cannot predict which software requirements will
change
ii. Usually, design and construction are interleaved …
they must be done in parallel so that design models
are proven when they are created
iii. Analysis, design, construction and testing are
difficult to predict in terms of planning
• Regular increments will then validate the
process; and also change is accommodated
from one increment to another
The 12 Agility Principles

(from the Agile Alliance)
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in

development. Agile processes harness change for the
customer’s competitive advantage.
3. Deliver working software frequently, from a couple of

weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together

daily throughout the project.

5. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying

information to and within a development team is
face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.

The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and
good design enhances agility.
10. Simplicity - the art of maximizing the amount of

work not done - is essential.
11. The best architectures, requirements, and

designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to

become more effective, then tunes and adjusts
its behaviour accordingly.

• Not every agile process will embrace all 12
principles with equal weight, but as different
agile teams tailor-make their processes, they
maintain the spirit of the principles
• There is also emphasis of human factors;
where proponents highlight the key traits
that should be within agile teams

Agile Development: Human traits

1. Competence
2. Common focus
3. Collaboration
4. Decision-making ability
5. Fuzzy problem-solving ability
6. Mutual trust and respect
7. Self-organisation

Agile Process Models

• Some agile models are:
1. Xtreme Programming (XP)
2. Adaptive software Development (ASD)
3. Scrum
4. Dynamic Systems Development Method (DSDM)
5. Crystal
6. Feature Driven Development
7. Lean software Development
8. Agile Modeling
9. Agile Unified Process

: Xtreme Programming (XP)
• The mostly used agile model, which uses the
object-oriented development paradigm
• Its key values are:
i. Communication : among all stakeholders :user stories
ii. Simplicity : design for immediate needs, refactor later
iii. Feedback : from customers, the implemented
software, and other team members: unit tests, use
cases, user tests
iv. Courage : discipline by the project team to stand for
the principles
v. Respect : will be inculcated as a result of following
the above values

: Xtreme Programming – Key activities
• The XP process has the following activities:
i. Planning : also called the planning game
 Listening, user stories, story value, story cost, commitment,
project velocity
ii. Design
 Keep it simple, CRC cards, spike solutions, refactoring
iii. Coding
 Unit testing, pair programming, continuous integration
iv. Testing
 Automated tests, regression testing, acceptance/customer
tests


: Scrum
• Incorporates activities: requirements, analysis,
design, evolution, delivery
• Within each activity, there is a sprint which
delivers deliverables. A sprint is a time-boxed set
of tasks
• A backlog keeps a prioritised list of features
• Regular scrum meetings where members
answer 3 basic questions:
 What did you do since the last meeting?
 what obstacles did you encounter?
 What do you plan to accomplish before next
meeting?

: Scrum
• A scrum master leads the scrum meetings
• There are demos that are used to show
customers the delivered software increments
• Scrum meetings are very short (typically 15
minutes) and happen at the same time at
regular intervals
• Teams may also a scrum sheet to track task
progress


: Lean Software Development
• Adopts principles of lean manufacturing into
software engineering and has the following
principles:
i. Eliminate waste
ii. Build quality in
iii. Create knowledge
iv. Defer commitment
v. Deliver fast
vi. Respect people
vii. Optimise the whole

: Criticism
• No model is the ultimate, and models continue
to evolve and improve.
• Some criticisms of Agile are:
i. Difficult to apply where users are not cooperative
ii. Requirements volatility maybe become
unmanageable due to customers being embedded
into the team
iii. May be difficult to control conflicting requirements
iv. Requirements that are expressed informally may
lead to omissions, errors, conflicts with customers
v. Lack of overall formal design (lack of emphasis on
overall architectural design)

HCT210 Lecture Notes - Unit 1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HCT210 Lecture Notes - Unit 1

Uploaded by

Copyright:

Available Formats

University of Zimbabwe

Department of Computer Science

HCT210: Software Engineering

Unit 1 : The Software Process

Lecturer: Gibson Mukarakate

HCT210: Software Engineering Gibson Mukarakate 2

Software Process – Framework

Software Process – Umbrella

HCT210: Software Engineering Gibson Mukarakate 8

Software engineering: Principles

HCT210: Software Engineering Gibson Mukarakate 9

Software engineering: Principles

HCT210: Software Engineering Gibson Mukarakate 10

Process Models: Summary

2. Iterative process flow

HCT210: Software Engineering Gibson Mukarakate 11

Process Models: Summary

4. Parallel process flow

HCT210: Software Engineering Gibson Mukarakate 12

Process Models: 1. Prescriptive

HCT210: Software Engineering Gibson Mukarakate 13

Process Models: 1. Prescriptive

Process Models: 1. Prescriptive

Process Models: 1. Prescriptive

Process Models: 1. Prescriptive

Process Models: 1. Prescriptive

Process Models: 1. Prescriptive

Process Models: 1. Prescriptive

HCT210: Software Engineering Gibson Mukarakate 20

Process Models: 1. Prescriptive

Process Models: 2. Specialised

HCT210: Software Engineering Gibson Mukarakate 22

Process Models: 2. Specialised

HCT210: Software Engineering Gibson Mukarakate 23

Process Models: 2. Specialised

Process Models: 2. Specialised

Process Models: 3. The Unified Process

Process Models: 3. The Unified Process

Process Models: 3. The Unified Process

HCT210: Software Engineering Gibson Mukarakate 28

Process Models: 4. Personal and Team

Process Models: 4. Personal and Team

Process Models: summary

HCT210: Software Engineering Gibson Mukarakate 32

What makes a process agile?

The 12 Agility Principles

2. Welcome changing requirements, even late in

3. Deliver working software frequently, from a couple of

4. Business people and developers must work together

The 12 Agility Principles

6. The most efficient and effective method of conveying

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development.

The 12 Agility Principles

10. Simplicity - the art of maximizing the amount of

11. The best architectures, requirements, and

12. At regular intervals, the team reflects on how to

The 12 Agility Principles

HCT210: Software Engineering Gibson Mukarakate 38

Agile Development: Human traits

HCT210: Software Engineering Gibson Mukarakate 39

Agile Process Models

Agile Process Models