This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/. http://www.ivanomalavolta.com

1. Software development
PROCESS
Ivano Malavolta

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

4. 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?

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

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

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

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

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

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

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

12. 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?”

13. Process as a "black box"
Product
Process
Informal
Requirements

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

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

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

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

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

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

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

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

22. Requirements engineering
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

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

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

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

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

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

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

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

30. Architecture in CRAFTERS (1)

31. Design in CRAFTERS (2)

32. Design in CRAFTERS (3)

33. Design in CRAFTERS (4)

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

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

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

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

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

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

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

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

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

43. 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)

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

45. 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!)

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

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

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

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

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

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

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

53. 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)

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

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

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

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

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

59. Agile

60. Waterfall vs agile: poor visibility

61. Waterfall vs agile: poor quality

62. Waterfall vs agile: too risky

63. Waterfall vs agile: can’t handle
change

64. The agile approach

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

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

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

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

69. Agile official principles

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

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

72. Agile iterations

73. Technical tools: unit tests
Snippet of test code for exercising some functionality of the
product à codified requirements
We will have two lectures on testing

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

75. 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/

76. An implementation: SCRUM
AAA

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

78. An implementation: SCRUM

79. An implementation: SCRUM
Burndown chart = how much work is left

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

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

82. Open-source software
development process

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

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

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

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

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

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

89. Software development process
RESEARCH

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

91. Major trends and challenges
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)

92. Major trends and challenges
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

93. Major trends and challenges
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

94. 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!

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

96. References
http://www.agilenutshell.com

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