Software Project

Management
Dr. Md. Nasim Adnan
The Basics: Software Development Activities
and Their Organization
• Software development projects range from the very small to the very
large and encompass a wide range of complexity, starting from
software developed by a small team in their spare time and ending
with projects lasting several years and involving the work of many
people.
Software Requirements Definition
• Software requirements definition includes the methods to identify
and describe the features of the system to be built.
• The main output of this activity is one or more artifacts describing the
requirements of a system, namely, the functions it has to implement
and the other properties it has to have.
• In more detail, the process is composed of four steps:
1. Requirements elicitation
2. Requirements structuring
3. User experience design
4. Requirements validation
Requirements elicitation and Requirements
structuring
• Requirements elicitation is the activity during which the list of
features of a system are elicited from the customer. This activity can
be performed with interviews, workshops, or the analysis of existing
documents.
• Requirements Structuring: Requirements structuring is the phase
during which the requirements are annotated to make their
management and maintenance simpler.
• During the process, requirements are:
• Isolated and made identifiable. Each requirement is clearly isolated and distinguished
from the others and is also assigned a unique identifier.
• This allows one to reason and manipulate each requirement more easily. Concerning
identification, a commonly used practice is that of assigning each requirement a
number or a combination of some characters (describing the type of requirements)
and a number.
• Organized and classified. A simple classification distinguishes between functional and
nonfunctional requirements. The former are requirements describing what the system
has to do.
• The latter are requirements describing what other properties the system should exhibit
(e.g., “the system will have to run on Windows devices”).
• Nonfunctional requirements are often organized in four groups: usability, reliability,
performance, and supportability.
• Annotated. Requirements are annotated to simplify their
management and to support planning activities, like, for instance,
which requirements should be implemented first.
• It is a good practice to assign each requirement at least two
properties, namely, the importance for the customer and the difficulty
to develop, for instance, using values from 1 to 5.
• Requirements evolve over time and a sound approach to requirement
management also necessitates defining a proper strategy to control the
evolution of requirements. For the time being, it is sufficient to mention
that requirements are often annotated with:
• Traceability information, which has the goal of highlighting where a
requirement originates from. Traceability shows the relationships
among requirements and other artifacts of software development. This
allows one to understand the impact of changes.
• History log, which records the changes each requirement has
undergone. The history log traces how requirements have changed over
time.
User Experience Design
• User experience design has the goal of providing a coherent and
satisfying experience on the different artifacts that constitute a
software system, including its design, interface, interaction, and
manuals.
• The typical user experience design activities include:
• User-centered analysis, which has the goal of understanding how
users will interact with the system.
• User-centered design, which has the goal of specifying how users will
actually interact with the system.
Requirements Validation
• Requirements validation is the phase during which the requirements
are analyzed to find:
• Inconsistencies, for example, two requirements require a system to
behave in contradictory ways.
• Incompleteness, when no information is given about a specific
situation.
• Duplicates, when one requirement describes a function already
described by another requirement.
Business Modeling
• Understanding how work is carried out in an organization is often
more relevant than eliciting the requirements of the system to be
built…
• This is where Business Analysts come into action…
Design and Implementation
• The goals of design (also system design or architectural design) and
implementation are, respectively, to draw the blueprint of the system
to be implemented and actually implement it.
Design
• System Design: The output of this activity is one or more documents
which describe, with diagrams and text, the structure of the system to
build, namely: what software components constitute the system,
which function each component implements, and how the
components are interconnected.
• The activity is particularly relevant for technical and managerial
reasons.
• Many different architectural designs have been proposed in the
literature. Among these, some of the most commonly used include:
• Pipe and filter, that is, a paradigm according to which the application is
structured as a chain of processing elements. Each element of the pipe
takes an input from the previous element, processes it, and passes it
onto the next element.
• Layered/hierarchical, by contrast, is an architectural style in which the
different elements of a system are organized hierarchically. Lower levels
of the architecture perform simpler functions, while higher levels are
responsible for the implementation of more complex functions.
• Data-centric is an architecture used when data storage and elaboration are
central. Many data-centric architectures rely on a database to store data
and are often based on the Model View Controller (MVC) pattern,
according to which, for each data to be processed by the application:
• The model defines how data are to be stored and manipulated.
• The view defines how data are to be presented to the user or other systems
interacting with the one we are developing. Multiple views can be associated with
a single model or, vice versa, some views can display the data of different models.
• The controller defines the logic of the operations, that is, what sequences of
transformations make sense of the data and what actions the users can perform.
• Client-server is an architecture in which the functions of a system are split
between a server, which performs the main functions, and various clients,
which interact with the server, requesting services.
Presentation of Architecture
• A popular way of presenting the architecture of a software system is the one
proposed in Kruchten (1995), which is based on the UML, and according to
which the architecture of a software system is described by “4+1” diagrams.
• Four diagrams describe the structure of the system. In particular:
1. The logical view identifies the main elements and data structures of the system to
build. It is best described with class diagram.
2. The component view provides a programmer-oriented view of the system. It is
mainly concerned with the components to be developed and is best described in
UML with component and package diagrams.
3. The process view provides a specification of the behavior of the system: interactions
among components and the sequence of actions that are required to implement the
user functions. It is best described with sequence diagram.
 4. The physical view provides a specification of the physical deployment of a
system, that is, on what computer or process each element of the
architecture will run. It is best described by a deployment diagram.
• The last view is the use case diagram view (for understanding
business…)
Implementation
• The goal of the implementation phase is writing the code implementing the
components individuated in the architecture.
• Some of the aspects of this activity that are more closely related to project
management include:
• Collection of productivity and size metrics, which allow one to measure the speed
at which code is delivered and the amount of work that has been performed.
• Collection of quality metrics, which allow one to measure the quality of the
system to be developed and trends in the development process.
• The use of coding standards, which are guidelines describing best practices and
the preferred styles to write code. Coding standards are adopted to ensure that
the work of different programmers is similarly structured.
Verification and Validation
• Verification is the set of activities performed on a system to ensure
that the system implements the requirements correctly. Validation
ensures that we are building the right system, while verification
ensures that we built the system right.
• Verification and validation are collectively known by the acronym
V&V. The main way of performing V&V of software systems is testing.
• Testing: Testing is one way of performing verification and validation.
Other methodologies include simulation, formal validation, and
inspections. Testing activities can be classified according to their
scope. In this case, we distinguish between the following:
• Unit testing, when the goal is to verify the behavior of a piece of code, such
as a class. Unit testing verifies that the code under investigation behaves as
specified by the system architecture.
• Integration testing, when the goal of the testing activity is to ensure that
the components of a system behave as expected when they are assembled.
Integration testing looks for inconsistencies in the way data are exchanged
between components.
• System testing, when the goal of the testing activity is to ensure that the
system behaves as expected and correctly implements all the requirements.
• Usability testing, running in parallel with the other testing activities, has
the goal of verifying whether the user experience and interaction are
intuitive, effective, and satisfying.
• Organizing Testing Activities: While unit tests are written and executed by
the developer writing the code being tested, integration and system test
are typically performed by an independent team and are organized in the
following two steps:
1. Test plan definition
2. Test execution and reporting
• Test Plan Definition: Starting from the requirements of a system, the goal
of the test plan definition is to write the tests that will be performed on
the system. The output of this activity is a document listing a set of test
cases, each of which describes how to perform a test on the system. Test
cases are structured natural language descriptions that specify all the
information needed to carry out a test, such as the initial state of the
system, the inputs to be provided, the steps to be performed, the expected
outputs, and the expected final state of the system.
• Test Execution and Reporting: Starting from the test plan definition,
test execution and reporting is the activity during which the team or
automated procedures execute tests and report on the outputs, that
is, which tests succeeded and which failed.
• Different strategies have been proposed to write effective test cases.
It has to be remarked, however, that testing is rarely complete and it
can only demonstrate that a system does not work, rather than
proving that a system is correct.
Deployment
• The final step of the development process is releasing and installing a
system so that it can be used by the customer and operations start.
• When a new software system replaces an obsolete system performing
business or mission-critical functions, deployment needs to be
carefully planned.
• In this situation, the goal is to move to the new technology without
interrupting the service.
• In doing so, the project team sets up three exact and independent
replicas of the same operating environment:
• A development environment, where the actual development of the
software takes place. The development environment is completely
isolated from production, and therefore there is no concern of
blocking any critical activity.
• If data are needed to verify the behavior of the software being
developed, a replica of the data in production is used. If there are
privacy concerns, like in the case of medical or banking systems, the
data on which developers operate are fake or an anonymized version
of the data in production.
• A testing environment, where the team tests a system that is ready
for deployment. The testing environment is isolated from the
development and the production environment, so that, on the one
hand, no changes made by developers interfere with testing and, on
the other, that testing activities can proceed without any risk of
interrupting production.
• Similar to the production environment, testing activities use replicas
of the production data or fake versions.
• A production environment, where the system is actually used. Any
change to the production environment interferes (positively or
negatively) with the operations for which a system is used.
• Even if we separate development and testing from production, it is
still necessary to ensure a smooth transition of operations when the
new system is ready.
• In general, three factors need to be taken into account when
deploying a new system. They are
1. The human factor: are the people ready to use the system?
2. The data factor: are all the data that are needed for the system to run
available to the new software?
3. The hardware factor: are all interfaces ready and functional?
• All these contribute to the selection of a migration strategy. The following
approaches are some examples:
• Cut-over, when the old system is replaced by the new one.
• Parallel approach, when the old and the new systems operate
simultaneously for a period. This allows the new system to be tested and
evaluated before the actual switch takes place.
• Piloting, when the system is installed for a limited number of users or for
a specific business unit. This approach reduces the burden to users (who
do not have to live with two systems), but it maintains the complexity of
having two environments—the old and the new systems—both alive.
• Phased approach, when functions are rolled out incrementally.
• When the strategy is agreed upon, the final step is the
implementation of the release process, which in turn consists of the
following steps:
1. Deliver training, to ensure that the users acquire the necessary skills to use
the new system.
2. Perform data migration, which includes updating the data used in the
production environment so that it can be used by the new system. This is a
delicate step, which requires a thorough testing of the migration scripts and
a backup of the existing data structures.
3. Install the new system, which puts the new system in production.
4. Set up the support infrastructure, namely, set up an infrastructure to
support operations.
Operations and Maintenance
• Operations and maintenance include the activities to ensure that a
product remains functional after its release.
• In general, operations are outside the scope of a project. However,
many one-off development projects plan a support activity after a
system is released to ensure that the project outputs meet the quality
goals and the transition to operations is as smooth as possible.
• The goals of this activity typically include:
• Providing technical support
• System monitoring
• Maintenance occurs throughout the lifecycle of a system, before it is
retired. ISO/IEC (2006) identifies four categories of maintenance for
software:
1. Corrective, if relative to fixing an issue discovered after the release of the
system.
2. Preventive, if relative to fixing an issue that was discovered but has not
occurred (or at least signaled by users)
3. Adaptive, if relative to adapting a system to changed external conditions.
Adaptive maintenance includes, for instance, activities related to updating a
software to work with a new release of an operating system.
4. Perfective, if relative to improving some characteristics of a system, like, for
instance, performances.