Software development PROCESS

Software development
PROCESS
Ivano Malavolta

Roadmap
Introduction
Classical software development processes
Agile
Open-source software development
Software development process research

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
Design
System
Te s t
Unit
Te s t
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

The role of standards
They are needed to achieve quality in both software
products and processes
They may be imposed internally or externally
– e.g., MIL-STD 2167A imposed to contractors for military
applications
Other examples: ISO series, IEEE

Main benefits
From the developers' viewpoint
– standards enforce a uniform behavior within an organization
– they facilitate communication among people, stabilizes the
production process, and makes it easier to add new people to
ongoing projects
From the customers' viewpoint
– they make it easier to assess the progress and quality of results
– they reduce the strict dependency of customers on specific
contractors

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 the 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
Feasibility study
Requirements engineering
Architecture and detailed design
Implementation and testing
Delivery, deployment, and maintenance
They must be performed independently of the model
The model simply affects the flow among activities

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 new wireless 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

What is needed
Understand interface between the application and the
external world
Understand the application domain
Identify the main stakeholders and understand
expectations
– different stakeholders have different viewpoints
– software engineer must integrate and reconcile 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
May be accompanied by the system test plan document
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
System testing
We will have a dedicated lecture on this activity
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
Assess existing
systems
Define system
requirements
Propose system
changes
Modify
systems
New
system
Existing
systems
Although there has been a demarcation between
development and evolution (maintenance), this is increasingly
irrelevant as fewer and fewer systems are completely new

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

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

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

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 know what 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
Risk
analysis
Risk
analysis
Risk
analysis
Prototype 2
Risk
analysis Proto-type
1
Evaluate alternatives,
identify, resolve risks
Prototype 3
REVIEW
Requirements plan
Life-cycle plan
Development
plan
Risks are explicitly assessed and resolved
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
Acceptance test
Service test Develop, verify
next-level product
Determine objectives,
alternatives and
constraints
Plan next phase
Integration
and test plan

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 cant be fixed early on
Complex products (Mlocs) with several interacting
components
Design hard to devise and freeze early on
Michael A. Cusumano and Richard W. 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
– external testing
– release

Planning phase
Vision Statement - Product Managers
– Define goals for the new product
– 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)
Buffer time between iterations (20%-50%)
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 SE 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

Roadmap
Introduction
Classical software development process
Agile
Software development process research

Waterfall vs agile: poor visibility

Waterfall vs agile: poor quality

Waterfall vs agile: can’t handle
change

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

Agile manifesto
We are uncovering better ways 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 over comprehensive 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

Anti-methodology?
The Agile movement is not anti-methodology, in fact, many of us want to
restore credibility to the word methodology.
We want to restore a balance. We embrace modeling, but not in order to
file some diagram in a dusty corporate repository.
We embrace documentation, but not hundreds of pages of never-maintained
and rarely-used tomes. We plan, but recognize the limits of
planning in a turbulent environment.
Jim Highsmith, History: The Agile Manifesto

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

A more critical evaluation of agile
principles
http://www.cs.york.ac.uk/staf/images/meyer-agile-forprint.pdf

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

Technical tools: unit tests
Snippet of test code for exercising some functionality of the
product à codified requirements
We will have two lectures 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

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
– no upfront tasks, e.g. requirements
– Tests as a replacement for specifications
– feature-based development & ignorance of dependencies
– no quality plan
– dismissal of a priori architecture work
– actually, dismissal of everything which is non-shippable

Open-source software
development process

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

Software development process
RESEARCH

Major trends and challenges
The Internet is the development environment
• Software is rarely developed in isolation
– it is more developed in teams, with even users involved
• see user-centered design
– radical change in the methods and techniques used to conceive,
design, develop, deploy, and evolve software
• e.g. our collaborative design platform for mobile apps
• Software is continuously changed and redeployed
– new challenges for configuration management, deployment, etc.
• e.g., continuous integration, continuous delivery, etc.
• Existing quality standard and models need to be extended
and adapted to very different situations
– e.g., safety-critical systems VS mobile apps

The Internet is the architecture and execution infrastructure
• Any software is directly or indirectly operating over the
Internet
– even control and SCADA systems
• The classical separation among different types of software
is tending to disappear
– Internet of things
– Smart services
• e.g., a connected car
– Disappearing computers
• Internet as the infrastructure for the development and
operation of modern software systems (cloud)

Users are mobile, nomadic, and “always on”
• Need to integrate software design techniques and
expertise with the true industrial designers’ skills and
methods
– it is not just a matter of “increasing usability”
• Designing software for mobile devices is not just a
variation of classical development processes
– it requires new and specific techniques, policies, and methods able
to effectively address challenges like mobile fragmentation,
intermitted connection, power consumption

The Internet is the basic distribution and business infrastructure
• Today software can be easily distributed and configured
over the Internet + users are always connected
– software updates can be done much more frequently
• Users and customers actually expect this
– software is global now, it must operate coherently with requirements
and constraints of each region/country
– e-commerce applied to software too (app stores)
• Apple app store is the only legal means to install software on iDevices
• new business models (e.g., in-app purchases)
– fragmentation problem (e.g., Android)
• Open APIs (very beyond the classical Open Data paradigm)
– e.g., E015 = full, bidirectional and direct interoperability among
autonomous distributed open services

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
Many research challenges to be explored out there!

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

Software development PROCESS

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Software development PROCESS

Ähnlich wie Software development PROCESS (20)

Mehr von Ivano Malavolta

Mehr von Ivano Malavolta (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Software development PROCESS