Software Engineering

Course Handbook 2017

Table of Contents
1 Introduction 5
1.1 Motivation: importance, diffusion and complexity of software 5
1.2 Definition and concepts 8
1.3 Process and product properties 12
1.4 Principles of software engineering 14

2 The software process 17

2.1 Activities of the software process 17
2.2 Phases 20
2.3 Comparison with traditional engineering 22
2.4 System and Software process 23
2.5 Software Engineering Approaches and Recent Trends 24

3 Requirements Engineering 27
3.1 Basic Concepts and Definitions 27
3.2 Context Diagrams and Interfaces 30
3.3 Requirement Types 32
3.4 Glossary 36
3.5 Scenarios and Use Cases 37
3.6 System Design 39

4 Object Oriented Approach and UML 41

4.1 Approaches to Modularity 41
4.2 UML Class Diagrams 44
4.3 Use Case Diagrams 50

5 Architecture and Design 55

5.1 The Design Process 55
5.2 Notations for Formalization of Architecture 58
5.3 Architectural Patterns 59
5.4 Design Patterns 65
5.5 Verification 69
5.6 Design of Graphical User Interfaces 70

6 Verification and Validation 75

6.1 Definitions and Concepts 75
6.2 Inspections 77
6.3 Testing 80
6.4 Static Analysis 97

7 Configuration Management 99
7.1 Motivation 99
7.2 Versioning 100
7.3 Change Control 103
7.4 Build 107
7.5 Configuration Management with Git 109

8 Project Management 111

8.1 Concepts and Techniques 111
8.2 Measures 115
8.3 Planning 117
8.4 Tracking 123
8.5 Post Mortem 124
8.6 Risk Management 126

9 Processes 129
9.1 Process Models 129
9.2 Agile Methodologies 137
9.3 Process selection 141
I INTRODUCTION

1.1 Motivation: Importance, diffusion and complexity of software

These times, software has a very prominent role inside economy and society. The economies of all the
developed nations are highly dependent on software: financial operations, manufactoring, distribution and
entertainment are, at least to some extent, aided by software and automated.

Therefore, ICT market has experienced an enormous growth and is still growing in recent years, as shown by
the followign graphs: figure 1 shows the continuously ascending revenue (in millions of dollars) of the ICT
market; figure 2 highlights the fact that revenues from ICT market have actually overtaken the ones of the
automotive market.

Figure 1 - ICT market revenues ($ millions)

Figure 2 - ICT market revenues compared with automotive domain

A correlation has also been proved between the wealth of countries and the diffusion of ICT in them. A
positive correlation is identified between the usage of technology and the per capita GDP (Gross Domestic
Product); ICT has also revolutionized the world of work, with the creation of new kinds of employment and
a significant improvement of productivity.

In a 2015 report about ICT made by WEF (World Economic Forum) it is stated that “as a general-purpose
technology, ICTs hold the potential of transforming economies and societies. They can help address some of
the most pressing issues of our time and support inclusive growth”.

WEF ICT report gives a classification of countries according to a Network Readiness Index (NRI) which is a key
indicator about how countries are performing in the digital world. The NRI index is based on a set of key
factors about the readiness of the network infrastructure, the usage of networks (by individuals, companies
and governments), and the social and economic impacts of ICT in countries. Figure 3 shows the top 15
countries by NRI, in 2015.

As shown in figure 4, there is an evident positive correlation between the GNI (Gross National Income) per
capita, and the NRI.

Figure 3 - The Networked Readiness Index 2015

Figure 4 - Networked Readiness and Income

WEF also defines a Global Competitivess Index (GCI), which measures the quality level of institutions, politics
and other factors determining economic prosperity on mid-long term. GCI is also influenced by innovation
and business sophistication, which are identified as keys for innovation-driven economies. Figure 5 shows
the top 15 countries by GCI, in 2015.

As shown in figure 6, there is an evident positive correlation between the GCI and the level of income of
countries: this is another prove of the positive influence that the massive dissemination of ICT has on
economies.

Figure 5 - Global Competitiveness Report 2014-2015

Figure 6 - Relationship between the GCI and level of income for 143 economies

Software has become highly pervasive, with a great number of high-complexity applications and services
being used daily by people with their personal devices, and with a very high level of interconnection between
systems. Figure 3 shows the growth in demand of new-generation devices (tablets and smartphones) by end
users during last years. It is worth mentioning that the yearly shipping of smartphones has largely overtaken
the demand for desktop computers. Software systems have a very high amount of variability: there are many
types of software systems, and each of them must be developed, deployed and managed in different ways.

Software, in addition to being more and more widespread, also has an increased complexity. Software costs
dominate the costs of the computer systems, and also high costs of maintenance are needed. Today complex
systems have to be built and delivered quickly, and reliability of software is mandatory when sensible
information and critical operations are aided (or wholly performed) by computers. Most typical software
problems are an excessive cost (up to a factor of 10 with respect to expectations), a late delivery (up to a
factor of 2 with respect to deadlines), and a lack in compliance with user expectations.

Figure 7 - Demand of technologic devices by end users

Software engineering coves all the aspects of software production, from development to management of
software and production of theories that can aid software development. The discipline of software
engineering allow to produce more trustable software, and the adoption of software engineering theories
can lower significantly the cost for development, testing, and maintenance of software systems on which
people, societies and economies rely.

1.2 Definitions and Concepts

This section defines a set of keywords that are crucial for the discipline of software engineering,

1.2.1. Definition and types of software

Software is a collection of computer programs, procedures, rules, associated documentation and data.
Software development covers all the elements related to software, and hence is more than merely the
development of software programs. Software incorporates documents that describe various views of the
same software elements for various stakeholders (for instance, users or developers).

According to “The Mythical Man Month” (Brooks, 1975), for solving a given problem, producing software is
approximately 10 times more expensive to produce than a simple program. On average, in software
development 10 to 50 LoC are produced per person day, and the number can be lowered down to 7 LoC in
critical systems.

Many different types of software exist, and the techniques for developing and maintain them are very
different. Some possible software types are:

 Stand Alone applications: software that can be run locally on a device, and that does not require
network connections to perform their functionalities (e.g., Notepad);
  Embedded software: software that is installed on hardware devices, to control them (e.g., ABS, digital
cameras, mobile phones);
 Process support software: software that supports production processes (industrial automation) or
the execution of business processes (management automation).

The eterogeneity of software and the emergence of new software types goes along with a massive diffusion
of software. In 1945-1980 software was confined to scientific communities, military forces, banks and large
private organizations. From 1980 onwards software became global, with a huge impact on everyday’s life of
common people.

1.2.2 Criticality and Complexity of software

Software can be classified according to a set of parameters; criticality identifies the relevance of software
inside a company, and the possible damage (to people or things) resulting from software malfunctions.
Different levels of criticality can be identified for software:

 Safety Critical (or Life Critical) software: a software which failure or malfunction may result on death
or serious injury to people, loss or severe damage to things, or environmental harm (for instance,
aerospace, military, medical software);
 Mission Critical software: software that are essential for a company or project, and that manage
important data, equipment of other resources (for instance, banking software, logistics, industrial
production control);
 Non Critical software: other kinds of software which malfunctionings are not harmful neither for
people wellness or business performance (for instance, entertainment and games).

As a human artifact, software can be characterized by its complexity, defined as the number of “Parts and
interactions among parts” (H. Simon, The sciences of the artificial, 1969). Software systems are probably the
most complex human artifacts: if the line of code is identified as their atomic part, some systems can be
composed by several millions of them, way more than an IKEA table (5-10 components), a bycicle (20-100
components), a car (about 30.000 components), an airplane (about 100.000 components). Table 1 reports
some examples of software complexity.

Software system Number of Lines of Code

Cell phone, printer driver 1 million
Linux 3.2 (2012) 15 million
Windows 7 50 million
F-22 Raptor (Us Air Force jet fighter) 1.7 million
F-35 Joint strie fighter (onboard systems) 5.7 million
Boeing 787 Dreamliner 6.5 million
Premium-class automotive software 100 million
Table 1 - software complexity examples

1.2.3 Misconceptions about software

Software is free: even though some typologies of software may be released without any costs for the final
users, it must be kept in mind that software is never free, and its production is very labor intensive. Assuming
a productivity of about 200 to 1000 lines of code per person month, software costs from $8 to $40 per single
line of code. A medium sized project, of about 50.000 lines of code, costs between $400.000 and $1.600.000
in personnel. For companies, the cost of software is dominant with respect to the cost of hardware, as shown
in figure 8.

Figure 8 - Relative cost of hardware supported by software (Boehm 1976)

Software is soft: Even if at a smaller extent than for hardware, changing and managing software is difficult
and often very costly, and change always happens. If the lifespan of a software system is long, the
maintenance costs become way higher than the development costs. At a certain point, due to architecture
erosion, the maintenance of software becomes nearly impossible.

Software is produced. Software is not mass produced, like machines are. The main difference between
software and hardware costs lies in the fact that the replication of software is almost effortless, while the
manifacturing of hardware is the most critical costs to be substained. Software is developed in a non-
deterministic, creative process due to human involvement that can introduce defects (which cannot be
introduced by production), and that can be controlled in a probabilistic manner only. In the case of sotware,
the description of the solution itself is the product.

Software ages. As opposed to hardware, software does not break as it ages, hence the hardware reliability
concepts cannot be applied to it. Failures in software do not occur due to material fatigue, but due to the
execution of logical faults. However, software cannot be perfect, and a chance of software faults is always
present: all software faults may not be removed before the execution of software. In addition to that,
software is not stable and may change, due to requirements changes, platform changes, and defect
correction; each change (even corrective ones) may add new faults to software.

1.2.4 Functional vs. Non Functional requirements

Functional Requirements describe functional characteristics of software, and behaviours that the system
must perform. In general, functional requirements describe what the system is supposed to do. For instance,
a functional requirement for a software may be:

 Add two integer numbers.

Non functional requirements specify how the system and its operations can be evaluated, rather than
behaviours of the system. In general, non-functional requirements describe how the system should be.
Examples of non-functional requirements are:

 User interface must be usable by not-computer expert;

 Precision: relative error < 10-9, absolute error < 10-8;
 Reliability: sum must be correct 99,9999999% times;
 Performance: sum must be performed in less than 0,01 milliseconds;
 Efficiency: sum must use lessthan 10 kbytes of RAM in memory.

Non-functional properties are sometimes harder to espress than functional properties, and in particular they
are harder to designe into software. They are rather emerging properties that depend on the system as a
whole, and that can be typically measured only on the finished and running system.

1.2.5 Software Engineering vs Solo Programming

Software Engineering supports professional software development, rather than individual (“solo”)
programming: “multi-person construction of multi-version software”, according to a definition given by
Parnas.

Solo programming can be sufficient only for solving a small niche of simple problems. In these cases, the size
of the projects is typically small, so that one person can manage all the development. The developer is
typically the user itself, so there are no communication problems in the definition of the requirements and
in the acceptance of the software, and typically only functional requirements (i.e., what the software must
do) are taken care of. Solo-programmed sotware have a limited cost (typically they are free) and they do not
need to be mantained for a long period of time.

On the other hand, projects needing practices of software engineering are typically large-sized, with teams
of developers that need to share documentation, and that must face communication and coordination
problems. User is not the developer, hence there are 3rd party requirements that must be communicated
with the user, and non-functional properties (e.g., performance and usability) must be taken care of.

Table 2 summarizes the differences between projects that are compatible with solo programming, and
projects that need software engineering techniques.

Solo programming Software Engineering

Size Small Large
User Developer Not the developer
Lifespan Short Long
Cost Development Development, operation, maintenance
Properties Functional Functional, Non Functional
Table 2 - Differences between solo programming and software engineering

The characteristics of projects managed by software engineering projects lead to a set of se-related issues.

 Large projects required team based development: efficient communication and coordination
between team members is needed;
 Long lifespan: maintenance, and communication between developers and maintainers, are required;
  Third party requirements: communication is required between computer specialists, and non-
computer specialists; non functional properties become essential, to measure the outcome of the
developers’ work.

1.3 Process and Product properties

A process is a defined set of activities, people and tools that are needed to obtain a certain product. Products
(that may be documents, data, or code, in the case of software production) are the outcome of a given
process. The quality of the product depends on the quality of the process. Parameters exist for characterizing
the quality of both process and product.

Figure 9 - Process and product

1.3.1 Process properties

Cost: direct and indirect costs of a given projects, in terms of money.

Effort: work that must be completed during the execution of a process, in terms of person-hours or machine-
hours.

Punctuality: capacity of the process to be on time, reaching its completion before a fixed deadline.

1.3.2 Product properties

Functionality: the product has a set of functions that currectly satisfy the needs at the base of its production
(both explicitly stated and implied needs).

Figure 10 - Traffic light controller example

Example: Traffic Light Controller. The device has to control 4 traffic lights in a road crossing, so that:
  When green light is shown in one direction, red light is shown in the other. Duration of green signal
is x seconds;
 While flashing yellow light is shown in one direction, red light is shown inthe other. Duration of yellow
signal is y seconds;
 Total duration of red light in a direction is z seconds.

Correctness: the capability of the product to provide the intended functionalities and perform their exact
tasks, as given in the specification, in all cases.

Example: for the Traffic Light Controller, Correctness would be the certainty that the intended sequence of
signals is always shown by the device.

Reliability: the ability of a system or component to perform its required functions under stated conditions,
for a specified period of time. Even though failures may be acceptable, a system or software should have a
long mean time between failures to be considered reliable. Reliability parameters can be expressed in terms
of the probability or count of failures during a given period of time.

Example: the Traffic Light Controller is considered reliable if the intended sequence of signance is given with
high probability (e.g., P = 99.9%) during a year. Or, if there is at most one failure every year.

Performance: measures how well the product carries out its main functionalities. In general, performance
measures pertain time (e.g., speed or delay in performing a function) or space (e.g., memory or CPU required
by a software to perform a specific function).

Safety: capability of a product to avoid hazards, that can compromise the security of people or other things.

Example: the Traffic Light Controller should never allow the contemporary exhibition of green light in both
directions.

Robustness: the capability of a product to exhibit a reduced set of all its functionalities when adverse
conditions are present, limiting the damages that such conditions can cause.

Example: in case of broken cable, the Traffic Light Controller should provide a safe behaviour, so not to harm
people in the street (for instance, only red lights, or only flashing yellow lights).

Usability: the ease of use a given function, measured in terms of the effort needed by a non-trained person
in using it. It is an assessment made by the user about using the product.

Figure 11 - Devices with different levels of usability

1.4 Principles of software Engineering
The principles of software engineering are fundamental, broad coverage ideas, that are capable of producing
positive and useful effects in the production of software.

1.4.1 Separation of concerns

Separation of concerns is the ability of splitting a large and difficult problem in many independent parts, that
can be considered and resolved individually. The concept is analogous to the “divide and conquer” approach
in war strategy.

In Software Engineering, the Separation of concerns translate in the concept of Software process:
concentrate first on what the system should do, then on how the system should be done, finally make the
actual system.

Separation of concerns can also apply to functionalities of the software itself. Software Engineering provides
design patterns for the production of software, that can help keeping separated the components of software
pertaining to different functions.

1.4.2 Abstraction

The ability of extract a simpler view of a difficult problem/system, aviding unnecessary details. Then,
reasoning is made only on the simpler view, which is called model.

Abstraction is a technique that allows to cope with the complexity of systems, and is one of the most
important principlesin object-oriented software engineering, for which it translates to the ability of
identifying atomic software artifacts (objects) that are able to model the problem domain.

Figure 12 - Abstraction: from plain code to models

1.4.3 Modularity

The ability of dividing a complex system in models, with high cohesion (i.e., the degree of similarity of
elements that are inside the same module) and low coupling (i.e., the degree of similarity of elements that
are in different modules).

In software development, modules can be divided based on their functionalities, and can be substituted with
other ones without affecting the functionalities of the whole system (e.g., developers can use prewritten
code). Having separate modules also allows to implement new functionalities in an additive way, without
taking care of the already present ones.

Figure 13 - Highly coupled and uncoupled modules

1.4.4 Information Hiding

The ability of hiding the internal mechanisms and design choices of each module to other modules. It can be
considered as another form of modularity, since less information exchanged between modules leads to minor
coupling. As modularity, information hiding provides additional flexibility.

As an example, a calculator software should expose the currect functionalities and the abilities of giving
inputs and receiving outputs (i.e., the calculation results) to the user, but the algorithms used for the
computations remain hidden.
II THE SOFTWARE PROCESS

2.1 Activities of the software process

The software process can be defined as a structured set of activities that are required for the production of
a software system. Many software process exist, but they however present similar activities.

2.1.1 Production Activities

The goal of the software process is to produce software with defined and predictable process properties
(cost, duration) and product properties (functionality, reliability, and so on). Code is not the only outcome of
the software process, since also documents and data are produced.

Software is made especially by executables, that are the final outcome of any software process. Developers
do not produce directly the executables, but the first intermediate artifact of the software process: the
source code. Hence, the coding phase is, from the bottom up, the first activity of the software process.

Source code is often large, with many lines of code, and needs to be organized in several physical units (like
files, directories, devices) and also logical units (functions, packages, subsystems, classes in object oriented
programming). The design phase of the software process is the activity of defining and organizing the units
of source code that must be developed.

To know exactly what software is made for and what it should do (e.g.: add numbers, count cars, forecast
weather, control mobile phones, support the administration of a company…) requirements must be looked
at.

Requirements Engineering What the software should do

Architecture and Design Which units, and how to organize them

Implementation Write source code (executables) and integrate

units

Table 3 – Three steps of the production activities

Thus, the production activities are divided in three steps: collecting the requirements and writing it in a
formal way (requirements engineering); identifying and organizing the units in which the software is
subdivided (architecture and design); writing source code, integrating different units and obtaining the
executable code (implementation).

Logically, each of the production activities depend on the previous ones: to create the design of the software,
requirements must be known in advance; to implement the code, both design and requirements are
necessary.
A first, simple approach to the production activities of the software process is to perform them in sequence
(see Waterfall Model). However, each phase may provide feedbacks to the previous ones, so that the process
may cycle again over phases that have already been performed.

The production activities create a set of documents, especially for what concerns the requirements and
design of the software system.

Figure 14 - The sequence of production activities

Figure 14 shows all the production activities of a software process, and the intermediate items that are
produced and exchanged between them. The Requirements engineering produces requirement documents,
that are used by the Design phase. Once the architecture and design is defined, design documents are
created. Based on the subdivision in units made in the Design phase and detailed in the design document,
the first step of the implementation activity is to separately implement the units of the software system.
Finally, the units are integrated to obtain the final software system.

2.1.2 Verification & Validation (V&V) Activities

The software process must include activities to verify the outcome of the production activities. Once the units
of the sotware are developed, questions similar to the ones following should always be answered.

 Does it work?
 Is it doing what it should do?
 Did we understand the requirements correctly?
 Did we implement the requirements correctly?

After each step, it is necessary to do the verification and validation (V&V) activities. Those are mandatory for
all steps, especially for the initial ones. In fact, an error in the first phases of the software process will
influence all the following phases.
 Figure 15 - Production + VV activities

Verification and Validation means that it must be controlled that the steps were correct both from the
external (if they are coherent with the previous phases or with stakeholders’ wills) and internal (if they are
inherently correct, e.g. if the coded units are behaving correctly) points of view.

Objective of V&V Externally Internally

Requirements Control that the Did we understand Is the requirements
engineering requirements are what the customer/user document consistent?
correct. wants?
Architecture and design Control that the design Is the design capable of Is the design consistent
of the system is correct. supporting the by itself?
requirements?
Implementation Control that the code is Is the code capable of Is the code consistent
correct. supporting the (syntactic code checks)?
requirements and the
design?
Table 4 - V&V Activities

2.1.3 The management activities

The final issue that is raised about the development of a software system is about the personnel that will
perform the activities, and about the organization of the workforce.

 Who does what, and when?

 Which resources will be used?
 How much will the project cost? When will it be finished?
 Where are the documents and units? Who can modify that?
 Are we doing it state of the art?
All those questions pose the need for management activities.

Project Management. Organization of all the activities related to a software project and its parts, in terms of
the assignation of work to people and monitoring of their progress, and estimation and control of the
available budget.

Configuration Management. Software projects evolve and change during time. Configuration management
is the activity of identifying and storing all documents and units pertaining to a software project, and keeping
track of the software versions and updates. Configuration management can also be called configuration
control.

Quality assurance. The activity of verifying whether the specifications are met from the finished software.
Measurable quality goals must be defined for the software project, and must be controlled (through V&V
activities) once the project is delivered. Also how the work will be done is defined within this activity.

Figure 16 - The whole picture

2.2 Phases

Development of software is just the first part of the game. In fact, the software must be first of all deployed
and put in an operative condition; then, the software must be maintained, and modified according to
incoming needs; finally, the when the software can not be maintained anymore, it must be retired.

Operate the software Deployment, Operation

Modify the software Maintenance
End up Retirement
Table 5 – Aims of the phases of the software process
 Figure 17 - Main phases of the software process

The aim of the Maintenance phase is to improve the software quality (e.g., for what concerns performance
or other attributes), meet changing customer needs, or perform corrective actions on the deployed software
to fix defects. Maintenance can be seen as a sequence of development phases (dev_1, dev_2, …. dev_N, with
dev_0 being the initial Development phase). Development and maintenance perform the same activities
(requirements, architecture, design, coding). At the end of each development phase, a release of the
software is obtained.

Indeed, the first maintenance is usually the longest, and the following are constrained by the previous ones.
In dev_0, requirements_0 are derived from scratch: this gives total freedom in defining the requirements for
the first development phase. design_0 and implementation_0 are based on requirements_0 only. In the next
development phase, dev_1, the requirements requirements_1 are derived from requirements_0, design_0,
and implementation_0. In the same way, the requirements of dev_N will have to be derived from the
requirements, design and implementation of all previous development phases, from dev_0 to dev_(N-1).

For instance, if in the dev_0 phase the programming language chosen is Java, all other development phases
will have to use Java. Likewise, if in dev_0 the client/server model is adopted for the software, all further
developments will have to keep it.

Figure 18 - Maintenance as a series of development phases

After years of operation of the software, the constraints posed by previous maintenances become too many,
and making changes becomes almost impossible. Maintenance is usually the most expenive phase of the
software process: for instance, in software that supports businesses, the cost for maintenance can be up to
60% of the overall costs.

Scenario Development Operation Maintenance

IT to support business Several months Years Years, up to 60% of costs
Consumer sw (games) Months Months (weeks) Virtually no maintenance
Operating System Years Years Years, up to 60% of costs
Commercial OS (MS) 2 – 3 years. Several years. Several years, with daily patches and
major releases (service packs) at long
intervals. Parallel development of a new
release.
Table 6 - scenarios in development

2.3 Comparison with Traditional Engineering

The software process is not an invention that has been created recently for software development: indeed,
it is just the application of the engineering approach to software production.

As a case study, in the following what is done by aeronautics engineers is shown, so to highlight the
equivalence with the individual phases of the software process described before.

Requirement definition (“what”) Airplane, civil usage;

Capacity > 400 people;
Range > 12000km;
Parameters about noise level, consumption,
acquisition and operation cost…
High level design (“how”) Blueprints of the airplane;
Production
Definition of subsystems (avionics, structures,
Activities
engines);
Mathematical models (structural for wings and
frames, thermodinamic for the engines).
Low level design Definition of further subsystems (in several cases
subcontracted or acquired, e.g. for the engine).
Implementation Implementation of each subsystem.
Unit test Verification that the subsystem complies to its
specification.
Test
Integration Put subsystems together (e.g., wings + frame).
Activities
Integration test Test the assemblies.
Acceptance test Does it fly?
Project Management Project planning;
Project Tracking;
Budgeting, accounting.
Management Configuration Management Parts and assemblies;
Activities Change control.
Quality Management Quality handbook;
Quality plan;
Roles management.
Table 7 - Aeronautic Engineering Process
It is evident that the engineering process for a traditional manufacturing sector follows the same phases that
are applied to software development: a preliminary phase in which requirements are defined; an architecture
and design phase in which the elements of the final output of the production process are specified; an
implementation and integration phase in which the individual elements are created and then put together;
a validation and verification phase; finally, a set of activities in charge of managing the product and the
process itself.

The difference between traditional engineering and software engineering lies principally in the fact that
software engineering is still a relatively new discipline: while traditional engineering techniques are hundreds
of years old, software engineering has been around for just about 50 years. The consequence of this fact is
that the maturity of customers and managers, that is ensured for traditional engineering, is highly variable
for software engineering.

In addition to that, traditional engineering bases its theories on a set of hard sciences, ranging from physics
to law, mathematical models and so on. By converse, software engineering is based on a limited set of
theories and law, and to some extent can be considered more a kind o social science.

2.4 System and Software Process

Since the nature of software may vary, also the nature of the process behind it varies accordingly. For
instance, a stand-alone software may be developed by a software process; on the contrary, the development
of an embedded software, which is tightly coupled to the hardware on which it is installed, requires the
execution of a System Process.

The phases of a System Process are initially close to those of a normal software process, with a first System
Requirements Engineering phase in which the requirements for the whole system are obtained, and a
System Design phase in which the architecture of the whole system are defined.

Figure 19 - The System Process

The process then forks, and two new processes start: an Hardware Development process, and a typical
Software Process. Both are full-stack processes, with their individual requirement, design, implementation
and test phases. The outcome of the two processes are the hardware and software component of the system,
that are then integrated in the final System Integration phase to form the system, and tested together.

2.5 Software Engineering Approaches and Recent Trends

Software engineering proposes a set of different approaches to the software development process. In
general, the activities that must be carried out for the development of any software do not change much,
with the typical phases of production, verification and validation and management that are always present.
In any software development process, information and decisions must be written, shared and controlled,
typically with the use of documents.

Software engineering codifies ways in which the information and decisions about software are written and
shared (with formal languages with which documents can be written) and offers techniques and models that
help supporting all the development activities and the process as a whole (e.g., CMM, CMM-I, Iso 900-3, and
so on).

2.5.1 Main approaches to software development

Even though the ways of putting together all the activities of a software process can be many, at least three
fundamental approaches can be recognized, in addition to the basic solo programming.

Cowboy Programming. Cowboy coding just focuses on code, with the philosophy that any other activity is
time lost, that should not be done by real programmers. It is a completely undisciplined approach to software
development, in which the control of the development process is fully given to the programmers.

Cowboy coding focuses only on quick development and fixes, with the objective of getting a finished product
as fast as possible. No formal process is adopted for requirements elicitation and testing, thus leading to a
higher possibility of errors and failures after deployment. The absence of clearly defined requirements and
design makes the cowboy-programmed software very difficult to integrate with other software, and to
maintain over time.

This approach to programming is still applied, especially when there is lack in resources or the project
deadlines are very tight.

Document Based, semiformal, UML. A semiformal language (UML) is used for writing documents.
Transformation and controls are not made automatically, but by humans.

This approach is typically adopted in normal industrial practice, by mature companies and domains that have
to manage large projects.

Formal / Model-Based. Formal languages are adopted for all the documents and specification of the software
to be developed. Controls and transformations of the deployed software is made automatically, and not by
humans.

This approach has a limited adoption in critical domains. It is typically used not for entire projects but for
small part of them that are then integrated: it does not scale up to large industrial projects.
Agile. The agile approach focuses on code and tests, trying to limit the use of documents: it is a light-weight
methodology, that encourages rapid iterations of the life-cycle of a project.

It is the latest approach being defined (introduced in 2001 in the Agile Manifesto) and there is still debate
about the advantages and disadvantages it offers. The adoption of agile methodologies is still limited, but
increasing.

2.5.2 Recent trends in sotware engineering

Component-based software engineering. Instead of being focused on just building the parts of the system to
develop, component-based development evaluates the possibility of buying and then integrating
components, either commercial or open source, i.e. the off-the-shelf components. The technique encourages
the reuse of components, and highlights the phase of definition of the software architecture. The key drivers
for the technique are saving time and money when building complex systems, and improve the quality of the
developed system by using reliable and tested components.

Offshored outsourcing. The process of moving the development and maintenance of software abroad, for
reasons related to time and money saving or different skills available. Offshoring guarantees enhanced cost
and time effectiveness, at the expense of a possibly lower quality and security of the outcomes of the
development.

2.5.3 Business models for software

Many business models are available for companies to monetize the software they develop, in addition to the
traditional scheme of selling licenses for an unlimited use of a software.

Traditional (on premise). The software is paid with a one-time license fee, i.e. the right to use a software.
Additional expenses may be asked for support and maintenance.

Open Source. The software is free, and the user is charged for support maintenance only.

ASP (pay per use). Software is run on the provider’s machines, and accessed by the users through a network,
typically internet. Users pay for using the software, rather than purchasing it (e.g., mySAP.com).

Freeware and pro versions. A light version of the software is distributed free of any charge to the user. The
professional version is charged.

Shareware. The software is distributed freely, to facilitate a trial use. Users pay for it if they decide to keep
and use it (e.g., WinRar).

Adware. The software isfree. The interface shows advertisement banners, that are refreshed by internet (e.g.,
Eudora).
III REQUIREMENTS ENGINEERING

3.1 Basic Concepts and Definitions

Requirements Engineering aims to collect and formalize the stakeholders’ wills. Also, this process involves
the analysis of the requirements, to be sure that they are correct and well formalized.

Requirements Engineering is a key phase of software development: most of the defects of the final product
come from this phase, and they are the most disruptive and expensive to fix. To avoid such errors, validation
and verification of the requirements is essential.

Figure 20 - Requirements phase in the software process

3.1.1 Domain

A Domain is a collectin of related functionality, and/or a collection of all applications with the same
functionalities. It defines a set of common requirements, terminology and functionality or all the software
programs that belong to it. Higher level domains can be specialized by subdomains, which pose additional
requirements for the applications belonging to them.

Example: Banking domain, that includes subdomains like account management, portfolio
management, etc.

Example: Telecommunication domain, that includes subdomains like switching, protocols,

telephony.

An Application is a software system supporting a specific set of functions, and that belongs to one or more
domains.
3.1.2 Stakeholders

A stakeholder is a role or a person with an interest (stake) in the system to be built, that can range from the
final user of the system, to the developers that are coding it. Each profile has a different interest in the
system, and that must be considered when the software is in the development phase. The following are the
typical staeholders for a software project:

 User: uses the final system. Different user profiles can be defined for the same system, each with
different expectations from it.
 Buyer: pays for the system.
 Administrator: manages the final system.
 Analyst: expert in requirements engineering, and/or in the domain the system belongs to.
 Developer: writes the code by which the system is built.

Often, the analyst and developers are the only ones involved in the software creation process, and the others
only need or use it. In recent Agile techniques, more cooperation is required between developers/analysts
and other stakeholders of the same system.

In the phase of requirement collection, it is always mandatory to identify all the involved stakeholders, and
understand their desires and needs.

User Cashier at Point of Sale (profile 1);

supervisor, inspector (profile 2);
Customer at Point of Sale (indirectly, through cashier).
Administrator POS application administrator (profile 3);
IT administrator, managing all the applications in the supermaret (profile 4);
Security manager, responsible for all security issues (profile 5);
DB administrator, managing DBMSs on which applications are based (profile 6).
Buyer CEO and/or CTO and/or CIO of supermaret.
Table 8 - stakeholders for a Point of Sale (POS) in a supermarket

3.1.3 Requirements

A requirement is a description of a system or a service and its constraints. Requirements describe what are
the goals and objectives of the software, how it will work, what are its properties. A requirement can have
different levels of abstraction and formality. It can be either functional or non functional.

For instance, taking into acount the Point of Sale example given before, an informal (set of) requirement can
be the following:

A POS (Point-of-Sale) system is a computer system typically used to manage the sales in retail stores.
It includes hardware components such as a computer, a bar code scanner, a printer and also software to
manage the operation of the store. The most basic function of a POS system is to handle sales.

Most of the requirements engineering phase has to do with the stakeholders –other than developers and
analysts- that are involved in the software process: requirements are tailored based on the needs of the
client. Because of that, lots of communication between stakeholders is involved in the phase of Requirements
Engineering. Initially, stakeholders give the requirements informally, and this is often source of mistakes and
misunderstandings, because ambiguous requirements may be interpreted in different ways by developers
and users (e.g., manage sales and handle sales are the same thing or not? What is a sale?).
Requirements should try to comply to two main characteristics, completeness and consistency.

 Requirements are complete when they include the descriptions of all the facilities required from the
system. It should be ensured that there is no information left aside from the specification of the
system.
 Requirements are consistent when there are no internal contradictions or conflicts in the
descriptions of the system facilities. If ambiguities are present, they should be eliminated and
properly signaled in the relative documents

Ideally, requirements should be both complete and consistent; however, in practice this is nearly impossible
to achieve; hence, a verification and validation procedure is essential for requirements.

Most common errors in requirements specification are:

 Omissions: when some functionalities that the system should provide are not covered by
requirements, or not well specified;
 Incorrect facts: when errors or wrong assumptions are present in the specifications of the system;
 Inconsistencies/contradictions: different behaviours are described for the same component;
 Ambiguities: the functionalities are specified, but in an unclear way;
 Extraneous information: information that are not fundamental for the requirements of the project;
 Redundancies: the same information is specified in more than one part of the requirements
document.

3.1.4 The Requirements Document

To overcome the issues presented before, a standard Requirements Document should be used, using
formalized techniques for writing the requirements. The requirements document provides a formalized
structure; within such structure, and in its parts, different techniques can be used. The following sections
should be provided in a Requirements Document.

 Overall Description: description of the need for the system, and brief description of the system
functions, and how the system fits among other similar systems and the business of the organization
requiring it.
 Stakeholders: description of all the stakeholders involved with the system.
 Context Diagram and Interfaces: definition of the boundaries between the system and its
environment, and how the system will communicate with other actors.
 Requirements: description of the functional and non functional requirements of the system, in detail.
 Use case diagram: descriptions of individual functions of the system, as perceived and used by actors.
 Scenarios: description of possible complete interactions of actors with the system, starting from a
goal and achieving a result.
 Glossary: definition of all the terms used in the requirement.
 System Design: description of the architecture and design of the system.

It is not mandatory to provide all the sections of the requirements document, and in a precise order: what is
fundamental is that the individual parts are described with sufficient precision.
Other structures are available for the Requirement Document; for instance, a simpler structure is given by
IEEE std 830 1994, which contemplates: Introduction, General Description, specific requirements,
Appendices, Index.

Overall Description Text

Stakeholders Text
Context Diagram UML UCD
Interfaces Text, PDL, XML, screenshots
Requirements Type, Numbering
Use Cases UML UCD
Scenarios Tables, Text
Glossary Text, UML CD
System Design UML CD
Table 9 - Requirements Document and Techniques

3.1.5 V&V of Requirements

Requirements verification and validation –useful for ensuring, for instance, completeness, consistency and
correctness- is a careful review process of all the requirements, that should be done as early as possible in
the development cycle, to avoid more costly expenses for fixing them later.

Verification and validation can be conducted in different ways, according to how the requirements have been
expressed. If the requirements are in natural language, or in UML, an inspection (proof reading) by the end
user or developer may be a first form of validation. Some tools exist to perform syntactic checks on
requirements expressed in UML form. If requirements are expressed using formal languages, model checking
tools are available for verification and validation.

3.2 Context Diagrams and Interfaces

The Context Diagram defines what is inside the system to be developed, and what is outside. The outside
entities are called actors and can either be other systems, external applications, or human users (the
stakeholders). Actors are not matter of development: they are just considered as black boxes, that take some
input and give some output (or vice-versa).

The Context Diagram also defines the interfaces between the system and the actors. Interfaces have two
levels:

 Physical Interface: addresses the specific means through which the interaction between the system
and the actor(s) has place.
 Logical Interface: defines the information flow of the human-computer interaction, without specifing
the actual means of the dialogue (i.e., protocols are specified).

It is also usually specified what are the data formats of the interface (e.g., format of the data sent for a credit
card, error messages).

Interfaces can also be classified in three types, each one having its formal notations that gives an effective
technique for interface specification: