Introduction to Software Project

Management

Chapter Two
 What is a Software Project 7

When we think about software projects, probably the first thing that comes
to mind is developing applications. Software Development Process:
One of the primary duties of the manager of a software development
project is to ensure that all of the
project activities follow a certain predefined process, i.e. that the activities
are organized as a series of actions conducing to a desirable end .
 Application Development
Application development might not be the only type of software-related project,
but it is probably one that is great fun.
□ One-offs or bespoke systems that are software systems specifically created for
a customer. A bespoke system often implements a specific need of a customer
Off-the-shelf applications are software systems implementing a function which
is useful to many different users.,
Process and Systems Reengineering Services
are projects related to improving the efficiency of an organization, by changing
the way in which they conduct their operational work.
System Integration Services
are projects and services related to automating the information flow among the
different and independent systems used by an organization.
Two types of integration are possible, vertical or horizontal.
 Software Requirements Definition 10

The first step of any nontrivial software development project is to form an

idea about the system that has to be developed.
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 (software) requirements of
a system, namely,
The requirement engineering discipline includes the activities
necessary to define and maintain requirements over time. the process is
composed of four steps:

[Link] elicitation
[Link] structuring
3. User experience design
[Link] validation.
 10

Design and Implementation

The goals of design (also system design or architectural
design in the rest of the book) and implementation are,
respectively, to draw the blueprint of the system to be
implemented and actually implement it.
System Design
System design defines the structure of the software to build or
system architecture. The output of this activity is one or
more documents which describe, with diagrams and text, the
structure of the system to
 11
✓ Pipe and filter, that is, a paradigm according to which the application
is structured as a chain of processing elements.
✓ Layered/hierarchical, by contrast, is an architectural style in which
the different elements of a
system are organized hierarchically
✓ Data-centric is an architecture used when data storage and elaboration
are central
✓ 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.
Figure 2.2 so me examples ofarchitectural styles.

C2
C1 C2 C3
C2 C2

Pipeline architecture C1 C3 C2

A layered architecture
Updates
V Response Request
Client 1
Modifies Request
Database Client 2 Server
V1
Response
V2
Client 3
A data-centric application with Response Request
two MVCs Client-server architecture
 Implementation
The goal of the implementation phase is writing the code implementing
12 the
components individuated in the architecture.
Verification and Validation
Verification is the set of activities performed on a system to ensure that the
system implements the requirements correctly.
Testing
Testing is one way of performing verification and validation. Other
methodologies include simulation, formal validation, and inspections.

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. The transition to
operations can be very simple for the project team..
we distingu is h between the follo wing:
A developme nt environme nt, where the actual develop m ent of the soft- ware takes
place.

A testing environme nt , where the team tests a system that is ready for deployment .
A productio n environme nt, where the system is actually used. Any change to the
productio n
enviro nm ent interferes (positively or negatively) with the operatio ns for whic h a system is

used .

Project development team Project testing team Employees

System Fake data

System Fake data System

System ready for testing System, project, and organization ready

for production

Figure 2.4 Development environments.

 Operations and Maintenance 15

Operations and maintenance include the activities to ensure that a product

remains functional after its release.
Supporting and Monitoring Operations
In general, operations are outside the scope of a project. The goals of this activity
typically include
□ Providing technical support. The support is meant to help users get acquainted
with the system and it can be organized as a help-desk collect-ing tickets from users.
□ System monitoring. A set of metrics might be collected on the system after its initial
release to monitor performances, issues, and other system features

.
 16

Maintenance
Maintenance occurs throughout the lifecycle of a system, before it is retired. It
can be framed either as a project or operational work and, as such, it often
poses a dilemma to the project manager.

Four categories of maintenance for software:

[Link], if relative to fixing an issue discovered after the release of
the system.
[Link], if relative to fixing an issue that was discovered but has
not
occurred (or at least signaled by users).
[Link], if relative to adapting a system to changed external
conditions. Adaptive maintenance includes, for instance, activities related
to updating
software to work with a new release of an operating system.
[Link], if relative to improving some characteristics of a system, like,
for instance, performances.
 17

2.4.3 Organizing Support and Maintenance Activities

One important aspect of support and maintenance activities is keeping formal track of the tickets.
This is usually achievedby
□ Defining a workflow for tickets, which describes how bug reports are
formally tracked and managed? Workflows can be very simple or more articulated, if a formal
quality control or configuration management process is in place.

[Bug is not present,

e.g., reported by
mistake]

Resolved Closed

[Solution is not
satisfactory]