EngineeringProcess Pps
EngineeringProcess Pps
Software engineering
processes
Course objectives
Become familiar with the software
engineering processes
Have an image of the main software
life cycles
Place the testing processes into the
right place
Describe few classes of software
projects and their specifics
References
I. Sommerwille, Software Engineering, 8th
edition, Addison Wesley, 2006 (chapter 4)
G. Everett, R. McLeod: Software Testing. Testing
Across the Entire Software Development Life
Cycle, Wiley&Sons ,2007 (chapter 2)
C. Kaner, J. Falk, H.Q. Nguyen: Testing computer
software, Second edition, Wiley & Sons, 1999
(chapter 3)
K. Benk, C. Andress: Extreme Programming
Explained. Embrace Change. 2nd edition,
Addison-Wesley Professional, 2004
S. McConnell, Rapid Development:Taming Wild
Software Schedules, Microsoft Press,1996
Software projects
There are a potpourri of software projects
No single structure or process that
optimally applies to the requirements and
environments for all sorts of projects
The discipline and the art of managing
projects makes the project success
What makes the software projects
different?
Software Engineering
What is software engineering?
is an engineering discipline that is concerned
with all aspects of software production from
the early stages of system specification to
maintaining the system after it has gone into
use.[Sommerville, Software engineering, 8th
edition, 2007]
is the application of a systematic, disciplined,
quantifiable approach to the development,
operation, and maintenance of software[IEEE,
"Guide to the Software Engineering Body of
Knowledge" (February 6, 2004)]
Software Project Management
Software specification
The process of establishing what
services are required and the
constraints on the systems operation
and development.
Requirements engineering process
Feasibility study;
Requirements elicitation and analysis;
Requirements specification;
Requirements validation.
Software Project Management
Requirements Validation
Showing that the requirements define what the
customer wants
Checks:
Techniques:
Reviews
Prototyping
Test case generation
Software Project Management
Software design
The process of converting the system
specification into an executable
system.
Software design
Describes software structure that realises
the specification;
Describes data which is part of the system
Describes interfaces between the system
components
Describes the algorithms
Software Project Management
10
Programming and
debugging
Translating a design into a program and
removing errors from that program.
Programming is a personal activity there is no generic programming
process.
Programmers carry out some program
testing to discover faults in the
program and remove these faults in the
debugging process.
Software Project Management
11
Software testing
Verification and validation (V & V) is intended to
show that a system conforms to its specification
and meets the requirements of the system
customer.
Involves checking and review processes,
system testing and acceptance testing.
System testing involves executing the
system with test cases that are derived
from the specification of the real data to
be processed by the system.
Acceptance testing involves executing
tests intended to asses the way the
customer requirements were implemented.
Software Project Management
12
Software evolution
Software is inherently flexible and can
change.
As requirements change through changing
business circumstances, the software that
supports the business must also evolve and
change.
Although there has been a demarcation
between development and evolution
(maintenance) this is increasingly irrelevant
as fewer and fewer systems are completely
new.
Software Project Management
13
14
15
Waterfall
First applied software model
Basis for many other models
Orderly progress from initial concept
to system testing and maintenance
Review at each phase end. Return to
previous phase if no acceptance.
Document driven
Software Project Management
16
Waterfall
Phases are discontinuous: do not
overlap
Suitable for stable product definitions
and technologies
Find errors at early stages
Minimizes planning overhead
Suitable even for un-experienced
teams
Software Project Management
17
Waterfall Drawbacks
Risks not explicitly addressed
The product is not visible until final stages
The stability of requirements is not a valid
assumption in software development
Discovering missing features at the end of
the cycle is very expensive
Lack of flexibility
Costly
Longer schedules
Software Project Management
18
Waterfall testing
Testing at the end of the lifecycle
No interaction between testing activities
and the development activities
Consequence: keep the testing and
development departments separate
Software testing is considered as being a
destructive process
Programmers should not test their own
programs
Programming organizations should not
test their own programs.
V-Model
20
V-Model testing
Start testing activities early in the lifecycle
Clearly defines four kind of testing
activities and their chaining:
Unit testing
Integration testing
System testing
Acceptance testing
Spiral models
Spiral
Boehm 1988
(http://www.computer.org/portal/cms_docs_computer/co
mputer/homepage/misc/Boehm/r5061.pdf)
First major iterative model: planning spread across
iterations
Enhance waterfall by early risk identifications
Process is represented as a spiral rather than as a
sequence of activities with backtracking.
Each loop in the spiral represents a phase in the process.
Each spiral iteration consists in a major risk elimination.
No fixed phases such as specification or design - loops in
the spiral are chosen depending on what is required.
The last spiral iteration may be a waterfall cycle
24
Spiral
The result of each iteration are more refined
prototypes until the released version
Advantages:
Early addressing of risks: as costs increases the
risk decreases
The management control is at least as much as
in the waterfall case, improved by the existence
of checkpoints at the end of each spiral
iteration
Disadvantages
Rather complicated to manage
Can be difficult to define milestones to indicate
if you are ready to move to the next iteration
Software Project Management
25
Phaseiteration
Inception
Elaboration
Construction
Transition
27
RUP phases
Inception - Define the project scope, gain
agreement on project objectives, baseline
the product Vision
Elaboration - Address key technical risks,
produce an evolutionary prototype,
baseline the Architecture
Construction - Iteratively and
incrementally develop an operationaly
complete product
Transition - Deliver the product into the
live end-user environment
Software Project Management
28
29
RUP disciplines
RUP
32
RUP
33
RUP-Test Discipline
Finding and documenting defects in software
Generally advising about the perceived software
quality
Proving the validity of the assumptions made in
design and requirement specifications through
concrete demonstration
Verifying the software product functions as designed
Validating that the requirements have been
implemented appropriately
Focuses primarily on the evaluation or assessment of
quality realized through a number of core practices
Acts in many respects as a service provider to the
other disciplines
Agile Development
35
If code reviews are good, we'll review code all the time (pair
programming).
If testing is good, everybody will test all the time (unit
testing), even the customers (functional testing).
If design is good, we'll make it part of everybody's daily
business (refactoring).
If simplicity is good, we'll always leave the system with the
simplest design that supports its current functionality (the
simplest thing that could possibly work).
If architecture is important, everybody will work defining
and refining the architecture all the time (metaphor).
If integration testing is important, then we'll integrate and
test several times a day (continuous integration).
If short iterations are good, we'll make the iterations really,
really shortseconds and minutes and hours, not weeks
and months and years (the Planning Game).
Software Project Management
37
XP Promises(Beck)
To programmers:
They will be able to work on things that really matter, every day.
They won't have to face scary situations alone.
They will be able to do everything in their power to make their system
successful.
They will make decisions that they can make best, and they won't
make decisions they aren't best qualified to make.
To customers and managers:
They will get the most possible value out of every programming week.
Every few weeks they will be able to see concrete progress on goals
they care about.
They will be able to change the direction of the project in the middle
of development without incurring exorbitant costs.
In short, XP:
reduce project risk,
improve responsiveness to business changes,
improve productivity throughout the life of a system,
add fun to building software in teams
38
XP phases
Architectural Spike, where a prototype is created
to validate the primary concerns of an iteration:
reduces risk
Release planning phase, where the customer
writes stories, the programmers estimate them,
and the customer chooses the order in which
stories will be developed;
Iteration phase, where the customer writes tests
and answers questions, while the programmers
program. Versions are generated at few weeks.
Release phase, where the Programmers install
the software, and the Customer (hopefully)
accepts the result.
Software Project Management
39
XP
http://www.extremeprogramming.org/map/project.ht
ml
40
XP Iterations
41
XP testing
Test early. This principle states that you must not wait
with testing until the entire system is assembled. Instead,
run test cases as soon as a unit is implemented, and
assemble your system out of carefully tested units.
Test first. Write test cases before implementing the unit.
This is useful because test cases can serve as
specifications. Any program feature without an
automated test simply doesn't exist.(K. Beck)
Test often. At the minimum, run your tests with each
release of the system. Better yet, run your tests with every
change.
Have others test. Always have someone independent
test your program, and be open to criticism
Mostly perform Unit tests and Acceptance testing
Agile vs RUP:
http://www.agiledata.org/essays/rup.html
SCRUM
SCRUM: eight players rugby team with
different roles acting together for a specific
goal
Agile methodology
Iteration based: 1-4 weeks iterations
(Sprints)
Small teams: 7-9 people
SCRUM: practices and roles
http://www.infoq.com/minibooks/
scrum-xp-from-the-trenches
Software Project Management
43
http://scrumtraininginstitute.com/home/stream_download/scru
mprimer
44
SCRUM Roles
Product Owner: business representative
Scrum Master
helps the product group learn and apply Scrum to achieve business
value
help the Team and Product Owner be successful
cannot be the same with the product owner
he/she is not the leader of the team
45
Product backlog
Product vision: product owner building the
product backlog
46
Sprint backlog
47
Daily Scrum
Short (15 minutes or less) meeting that happens every
workday at an appointed time.
Everyone on the Team attends.
To keep it brief, it is recommended that everyone
remain standing.
It is the Teams opportunity to synchronize their work
and report to each other on obstacles.
No management involved.
Each member of the Team reports three (and only
three) things to the other members of the Team:
what they were able to get done since the last meeting;
what they are planning to finish by the next meeting;
any blocks or impediments that are in their way.
48
Sprint review
After the Sprint ends;
The Team and the Product Owner review the
Sprint;
An inspect and adapt activity for the product;
Product Owner learns what is going on with the
product and with the Team;
The Team learns what is going on with the
Product Owner and the market;
Attended by: Product Owner, Team members, and
Scrum Master, plus customers, stakeholders,
experts, executives, and anyone else interested.
Software Project Management
49
Sprint retrospective
Inspect and adapt regarding the process.
Its the main mechanism for taking the
visibility that Scrum provides into areas of
potential improvement, and turning it into
results.
Its an opportunity for the Team to discuss
whats working and whats not working, and
agree on changes to try.
The Team and Scrum Master will attend, and
the Product Owner is welcome but not
required to attend.
Software Project Management
50
Release sprint
Final sprint to complete the release
Integrate some elements, polish, etc
Sign of some development weakness
as ideally at the end of each sprint
the product should be good enough
for use
51
Mission-Critical Systems
Internet site
Embedded software
Avionics Software
Intranet site
Games
Embedded software
Inventory management
Internet site
Medical devices
Games
Packaged software
Operating Systems
Software tools
Packaged software
Payroll systems
Web services
53
Mission-Critical Systems
Staged delivery
Evolutionary prototyping
Evolutionary delivery
Spiral development
54
Mission-Critical Systems
As-needed QA planning
Extensive QA planning
55
Mission-Critical Systems
Architectural design
Architectural design
56
Mission-Critical Systems
Test-first development
Test-first development
Test-first development
57