software development process

Ivano Malavolta

Software development

PROCESS

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 Test

Unit Test

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

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

Requirements engineering

Involves –  eliciting –  understanding –  analyzing –  specifying

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

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

Interfacedesign

Componentdesign

Systemarchitecture

Databasespecification

Interfacespecification

Requirementsspecification

Architecturaldesign

Componentspecification

Platforminformation

Datadescription

Design inputs

Design activities

Design outputs

Database design

Architecture in CRAFTERS (1)

Design in CRAFTERS (2)

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 testingComponent

testingAcceptance

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 existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

What you need to remember Requirements engineering 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

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

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

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

Risks are explicitly assessed and resolved

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternatives,identify, resolve risks

Determine objectives,alternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-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 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


Agile



Waterfall vs agile: poor visibility

Waterfall vs agile: poor quality

Waterfall vs agile: too risky

Waterfall vs agile: can’t handle change

The agile approach

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

Agile official principles

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

Agile iterations

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

AAA


http://www.flickr.com/photos/magia3e/6233729753/


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

Roadmap

Introduction


Agile



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

Roadmap

Introduction


Agile



Software development process

RESEARCH

Major trends and challenges

•  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 development environment


•  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)

The Internet is the architecture and execution infrastructure


•  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

Users are mobile, nomadic, and “always on”


•  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

The Internet is the basic distribution and business infrastructure

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

[email protected]

www.ivanomalavolta.com

software development process

Technology

software process modelattempt

software crisis

theproduction process

nave process model

thusa process model

process model goalsb

software life cycle

defined process ischaotic