[2015/2016] Software development process

Ivano Malavolta
Software development
PROCESS

Roadmap
Introduction
Classical software development processes
Agile
Open-source software development

Discussion
If you need to develop a system with 10M LOCS,
• How many people do you need?
• How much time?
• How do they synchronize?
• How do you know that you are performing well?

Software development process
Developing software
without a defined process
is chaotic and inefficient
Following a defined
process makes software
development more orderly,
predictable and repeatable
. . . . . .
Slide by Cesar Augusto Nogueira, IBM

Life cycle
From inception of an idea for a product through:
• requirements gathering and analysis
• architecture design and specification
• coding and testing
• delivery and deployment
• maintenance and evolution
• retirement

Software process model
Attempt to organize the software life cycle by defining
– activities involved in software production
– order of activities and their relationships
Goals of a software process
– standardization, predictability, productivity, high product quality,
ability to plan time and budget requirements

Code & Fix: the naïve process model
• Write code
• Fix it to eliminate any errors that have been detected,
to enhance existing functionality, or to add new
features
• Source of difficulties and deficiencies
– impossible to predict
– impossible to manage

Models are needed
Symptoms of inadequacy: the software crisis
– scheduled time and cost exceeded
– user expectations not met
– poor quality
The size and economic value of software applications
required appropriate “process models”
VS

Process model goals
(B. Boehm 1988)
“determine the order of stages involved in software
development and evolution, and to establish the transition
criteria for progressing from one stage to the next.
These include completion criteria for the current stage
plus choice criteria and entrance criteria for the next stage.
Thus a process model addresses the following software
project questions:
What shall we do next?
How long shall we continue to do it?”

Process as a "black box"
Product
Process
Informal
Requirements

Problems
The assumption is that requirements can be fully
understood prior to development
Interaction with the customer occurs only at the beginning
(requirements) and end (after delivery)
Unfortunately this assumption almost never holds

Process as a "white box"
Product
Process
Informal
Requirements
feedback

Advantages
Reduce risks by improving visibility
Allow project changes as the project progresses
– based on feedback from the customer
Why a project may change?

The main activities
They must be performed independently of the model
The model simply affects the flow among activities
Requirements engineering
Feasibility study
Architecture and detailed design
Implementation and testing
Delivery, deployment, and maintenance

Example from an EU project
ConstRaint and Application driven Framework for Tailoring
Embedded Real-time Systems
http://www.crafters-project.org

Why CRAFTERS?
PROBLEMS
poorly interoperable proprietary technologies
à poor time to market + high costs
SOLUTION
Seamless connectivity and middleware
– by realizing a common middleware layer that is designed to
support newwireless communication standards
– portable across different platforms
Ability to develop powerful design time solutions with
notably shorter cycles
– thanks to the unique tool chain delivered with reference
middleware and hardware

Feasibility study
Why a new project?
• cost/benefits tradeoffs
• buy vs make
– Requires to perform preliminary requirements analysis
– Produces a feasibility study document
1. Definition of the problem
2. Alternative solutions and their expected benefits
3. Required resources, costs, and delivery dates in each proposed
alternative solution

CRAFTERS feasibility study
Project proposal submitted to the ARTEMIS Call 2011 Project

Involves
– eliciting
– understanding
– analyzing
– specifying
Feasibility
study
Requirements
elicitation and
analysis
Requirements
specification
Requirements
validation
Feasibility
report
System
models
User and system
requirements
Requirements
document
Focus on
– what qualities are needed,
– NOT on how to achieve them

The requirements specification
document (1)
Provides a specification for the interface between the
application and the external world
– defines the qualities to be met
Has its own qualities
– understandable, precise, complete, consistent,unambiguous,
easily modifiable

The requirements specification
document (2)
Must be analyzed and confirmed by the stakeholders
– may even include version 0 of user manual
As any large document, it must be modular
– "vertical" modularity
• the usual decomposition, which may be hierarchical
– "horizontal"modularity
• different viewpoints
Defines both functional and non functional requirements

Requirements in CRAFTERS (1)
Set of relevant use cases first

Requirements in CRAFTERS (2)
Then, requirements
collection and
formulation

Software architecture and detailed
design activity
Usually follows a company standard, which may include a
standard notation, such as UML
The result of this activity is:
– the software architecture description
– a design specification document
We will have a dedicated lecture on this activity

General model of the design process
Interface
design
Component
design
System
architecture
Database
specification
Interface
specification
Requirements
specification
Architectural
design
Component
specification
Platform
information
Data
description
Design inputs
Design activities
Design outputs
Database design

Verification and validation
Verification and validation (V & V) is intended to show that a
system conforms to its specification and meets the
requirements of the customer
Involves: checking and review processes AND system
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
Testing is the most commonly used V & V activity

Coding and module testing activity
Company wide standards often followed for coding
style
We will have a dedicated lecture on this activity
System testing
Component
testing
Acceptance
testing

Testing stages
Development or component testing
– Individual components are tested independently
– Components may be functions or objects or coherent groupings
of these entities
System testing
– Testing of the system as a whole. Testing of emergent properties
is particularly important
Acceptance testing
– Testing with customer data to check that the system meets the
customer’s needs

Coding and testing in CRAFTERS
Prototype implementation based on 3 different HW
platforms
For example:

Software evolution
Software is inherently flexible and can change
Although there has been a demarcation between
development and evolution (maintenance), this is increasingly
irrelevant as fewer and fewer systems are completely new
Assess existing
systems
Define system
requirements
Propose system
changes
Modify
systems
New
system
Existing
systems

What you need to remember
create the software specification
Design and implementation
requirements à executable software
Software verification and validation
to check that the system conforms to its specification and
that it meets the real needs of the users of the system
Software evolution
new requirements à the software must evolve to remain
useful

Roadmap
Introduction
Classical software development process
Agile
Open-source software development

Classical software process
models*
Waterfall model
Spiral model
Microsoft’s Synch-and-Stabilize
* these are the most known process models, it is not a complete list
Quality-oriented model

Waterfall model
Exist in many variants, all sharing sequential flow style
It is document-driven
Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance

Waterfall model
Organizations adopting them standardize the outputs
of the various phases (deliverables)
May also prescribe methods to follow in each phase
– organization of methods in frameworks often called
methodology
Example: Military Standard (MIL-STD-2167)

Alternative: the V model
Emphasis on V&V activities
Acceptance tests written with requirements
Unit/integration tests written during design

Critical evaluation of the waterfall
model
+ sw process subject to discipline, planning, and
management à standard-oriented
+ postpone implementation to after understanding
objectives
+ good documentation
– difficult to gather all requirements once and for all
– users may not knowwhat they want
– linear, rigid, monolithic
– no feedback from the customer
– no parallelism, all phases are blocking
– a single delivery date (at the end!)

Spiral model
Risks are explicitly assessed and resolved
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integration
test
Acceptance
testService Develop, verify
next-level product
Evaluate alternatives,
identify, resolve risks
Determine objectives,
alternatives and
constraints
Plan next phase
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW

Spiral model sectors
Objective setting
– Specific objectives for the phase are identified
Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the
key risks
Development and validation
– A development model for the system is chosen which can
be any of the generic models + implementation & validation
Planning
– postmortem of previous loop, planification of next loop

Critical evaluation of the spiral model
+ a good fit if requirements are not stable
+ flexible, but still with a plan
+ risks are assessed clearly
+ customer involvement
+ good documentation
– difficult to assess risks
– difficult to assess objectives and constraints

Quality-oriented model
Mathematical formalism to express requirements
Model checking to prove correctness + automatic
transformations to code = preserve correctness

Critical evaluation of the quality-
oriented model
+ a good fit for to safety/security critical parts
+ if requirements are correct, risks are totally controlled
+ verification is implicit à potentially, less testing needed
– math languages require specific skills, rarely available
– some parts (ex user interface) cannot be specified
formally
– validation of requirements still an issue
– customer does not understand math language
– specifier may misunderstand requirements

Microsoft’s Synch-and-Stabilize
CONTEXT
Time to market essential
Requirements can’t be fixed early on
Complex products (Mlocs) with several interacting
components
Design hard to devise and freeze early on
Michael A. Cusumano and RichardW. Selby. 1997. How Microsoft builds software. Commun.
ACM 40, 6 (June 1997), 53-61. DOI=10.1145/255656.255698

Microsoft’s S-and-S phases
Planning
– vision of the product
– Specification
– Teamwork schedule
Development
– team composed of 2 groups
• developers and testers (continuous testing)
Stabilization
– internal testing
– externaltesting
– release

Planning phase
Vision Statement - Product Managers
– Define goals for the newproduct
– Priority-order user activities that need to be supported by
product features
Deliverables:
– Specification document
– Schedule and “feature team” formation
• 1 program manager
• 3-8 developers
• 3-8 testers (1:1 ratio with developers)

Development phase
Plan 3-4 sequential subprojects (lasting 2-4 months each)
Subprojects -- design, code, debug
– starting with most critical features and shared components
– feature set may change by 30% or more
– each developer is committed only to his assigned tasks

Subproject development
Feature teams go through the complete cycle of
development, feature integration, testing and fixing
problems
Testers are paired with developers
Feature teams synchronize work by building the product,
finding and fixing errors on a daily and weekly basis
Code that breaks a build must be fixed immediately
At the end of a subproject, the product is stabilized

Stabilization
Internal testing of complete product
External testing
– beta sites
– ISVs (Independent SW vendors)
– OEMs (Original Equipment Manufacturers)
– end users
Release preparation

Critical evaluation of Microsoft’s
method
+ Responsiveness to marketplace: they always have a
release to ship
+ allows to ship preliminary versions early
+ allows to add features in subsequent releases
+ continuous customer feedback
+ breaks down large projects into manageable pieces (with
priorities)
– poor focus on product architecture
– no rigorous approach to design & code reviews
– e.g., Video on demand components have real-time constraints
that require precise mathematical models
– no focus on defect prevention

Waterfall vs agile: poor visibility

Waterfall vs agile: poor quality

Waterfall vs agile: can’t handle
change

Agile manifesto
We are uncoveringbetterways of developing software by doing it and
helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools 
Working software overcomprehensive documentation 
Customer collaboration over contract negotiation 
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
http://www.agilemanifesto.org

How does it work in practice?
You make a list You start executing
You estimate You update the plan
“@run-time”
You set priorities

Agile principles (extract)
Agile methods are iterative development processes with:
• frequent releases of the product
• continuous interaction between dev. team and customer
• reduce product documentation
• continuous and systematic assessment of produced
value and risks

Risks and features
http://www.testingthefuture.net/wp-
content/uploads/2011/12/waterfall_versus_agile_development.png

Technical tools: unit tests
Snippet of test code for exercising some functionality of the
product à codified requirements
We will have a dedicated core course on testing

Technical tools: test-driven
development
Write tests first
Refactoring is less risky now

Technical tools: continuous
integration
Merging all the developers’ working copies many times a
day à it allows to make sure that all the code integrates, all
the unit tests pass, and a warning if anything goes wrong
image from http://newmedialabs.com/

An implementation: SCRUM
http://www.flickr.com/photos/magia3e/6233729753/

An implementation: SCRUM
Burndown chart = how much work is left
Scope changes
• The engineering team
missed features in the UI
mockups when we
created the release
backlog
• Integrations into other
AdWords features were
overlooked
• The rate of change in
AdWords APIs is very
high.

Critical evaluation of the agile
method
+ Acceptance of change à less risky
+ Frequent and short iterations
+ Emphasis on working code
+ Associating a test with every piece of functionality
+ tests are a key resource within the project
+ Continuous integration (and delivery)
+ Planned
– Tests as a replacement for specifications
– feature-based development & ignorance of
dependencies
– no quality plan
– dismissal of a priori architecture work
– actually, dismissal of everythingwhich is non-shippable

Open source development process
As applied in successful projects:
– Apache
– Mozilla
– …
Tools
• GitHub (config management system)
• Mailing lists
• Bugzilla (Bug tracking)
Products
• Source code, test suites
• all related information, like mails, bugs, comments, etc.

It doesn't just mean access to the
source code
1. Free redistribution
2. Source code
3. Derived works
4. Integrity of the author's source code
5. No discrimination against persons or groups
6. No discrimination against fields of endeavor
7. Distribution of license
8. License must not be specific to a product
9. License must not restrict other software
10. License must be technology-neutral
www.opensource.org/docs/definition.php

Roles
• Core team (2-8 people)
– Architecture,requirements, integration/build, release
• Patch developers (10-100)
– Patch (evolutive + corrective)
• Bug providers (100 – 1000+)
– Signal bugs, may perform pull requests, etc.
• Others (thousands)
– Download and use

Overview of the process
The process is “public”
• everyone can participate
Releases are checked by
a revision board that tests
proposed code from the
community
Very frequent builds
Often quite frequent releases
• once a month

Critical evaluation of the open-
source model
+ simple and effective tools for bug/change tracking
+ continuous delivery
+ resiliency with respect to team members (openness)
+ “no maintainance”
– limited documentation (not always)
– no project plan
– no quality plan

What this lecture means to you?
No “silver bullet”
Linear processes: planned, not flexible
Iterative processes: planned, flexible, less risky
Quality-oriented processes: planned, not flexible, measured
Agile: not planned, test-driven

Suggested readings
1. Alfonso Fuggetta and Elisabetta Di Nitto. 2014. Software process.
In Proceedings of the on Future of Software Engineering (FOSE
2014). ACM, New York, NY, USA, 1-12.
2. Striebeck, M., "Ssh! We are adding a process... [agile practices],"
Agile Conference, 2006 , vol., no., pp.9 pp.,193, 23-28 July 2006
3. Nicolò Paternoster, Carmine Giardino, Michael Unterkalmsteiner,
Tony Gorschek, Pekka Abrahamsson, Software development in
startup companies: A systematic mapping study, Information and
Software Technology, Volume 56, Issue 10, October 2014, Pages
1200-1218,ISSN 0950-5849

References
http://www.agilenutshell.com

Contact
Ivano Malavolta |
Post-doc researcher
Gran Sasso Science Institute
iivanoo
ivano.malavolta@gssi.infn.it
www.ivanomalavolta.com

[2015/2016] Software development process

More Related Content

What's hot

Viewers also liked

Similar to [2015/2016] Software development process

More from Ivano Malavolta

Recently uploaded

[2015/2016] Software development process