Lecture 3.

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 7

АZERBAIJAN STATE UNIVERSITY OF

ECONOMICS
DEPARTMENT: DIGITAL
TECHNOLOGIES AND
APPLIED INFORMATION SCIENCE
PROFESSOR SHAHNAZ SHAHBAZOVA

Subject: Software Engineering


Lecture 3. Software Project
Management

Introduction
In this lecture, we first investigate why management of software projects is much
more complex than managing many other types of projects.Subsequently, we outline
the main responsibilities and activities of a software.Project manager. Next, we
provide an overview of the project planning and provide an overview of the risk and
configuration management activities.

Software Management Compexities


Invisibility:Software remains invisible, until its development is complete and it is
operational. Anything that is invisible, is difficult to manage and control. Consider a
house building project. For this project, the project Manager can very easily assess
the progress of the project through a visual examination of the building under
construction. Therefore, the manager can closely monitor the progress of the
project, and take remedial actions whenever he finds that the progress is not as per
plan. In contrast, it becomes very difficult for the manager of a software project to
assess the progress of the project due to the invisibility of software. The best that he
can do perhaps is to monitor the milestones that have been completed by the
development team and the documents that have been produced—which are rough
indicators of the progress achieved.
Changeability Because the software part of any system is easier to change as
compared to the hardware part, the software part is the one that gets most
frequently changed. This is especially true in the later stages of a project. As far as
hardware development is concerned, any late changes to the specification of the
hardware system under development usually amounts to redoing the entire project.
This makes late changes to a hardware project prohibitively expensive to carry out.
This possibly is a reason why requirement changes are frequent in software projects.
These changes usually arise from changes to the business practices, changes to the
hardware or underlying software (e.g. operating system, other applications),or just
because the client changes his mind.
Complexity: Even a moderate sized software has millions of parts (functions) that
interact with each other in many ways—data coupling, serial and concurrent runs,
state transitions, control dependency, file sharing, etc.
Due to the inherent complexity of the functioning of a software product in terms of
the basic parts making up the software, many types of risks are associated with its
development. This makes managing these projects much more difficult as compared
to many other kinds of projects.
Uniqueness: Every software project is usually associated with many unique features
or situations. This makes every project much different from the others. This is unlike
projects in other domains, such as car manufacturing or steel manufacturing where
the projects are more predictable. Due to the uniqueness of the software projects, a
project manager in the course of a project faces many issues that are quite unlike
the others he had encountered in the past. As a result, a software project manager
has to confront many unanticipated issues in almost every project that he manages.
Exactness of the solution: Mechanical components such as nuts and bolts typically
work satisfactorily as long as they are within a tolerance of 1 per cent or so of their
specified sizes. However, the parameters of a function call in a program are required
to be in complete conformity with the function definition. This requirement not only
makes it difficult to get a software product up and working, but also makes reusing
parts of one software product in another difficult. This requirement of exact
conformity of the parameters of a function introduces additional risks and
contributes to the complexity of managing software projects.

Team-oriented and intellect-intensive work: Software development projects are


akin to research projects in the sense that they both involve team-oriented, intellect-
intensive work. In contrast, projects in many domains are labour-intensive and each
member works in a high degree of autonomy.Examples of such projects are planting
rice, laying roads, assembly-line manufacturing, constructing a multi-storeyed
building, etc. In a software development project, the life cycle activities not only
highly intellect-intensive, but each member has to typically interact, review, and
interface
With several other members, constituting another dimension of complexity of
software project.
3. RESPONSIBILITIES OF A SOFTWARE PROJECT MANAGER

A software project manager takes the overall responsibility of steering a project to


success. This surely is a very hazy job description. In fact, it is very difficult to
objectively describe the precise job responsibilities of a project manager. The job
responsibilities of a project manager ranges from invisible activities like building up
of team morale to highly visible customer presentations. Most managers take the
responsibilities for project proposal writing, project cost estimation, scheduling,
project staffing, software process tailoring, project monitoring and control, software
configuration management,risk management, managerial report writing and
presentation, and interfacing with clients. These activities are certainly numerous
and varied. We can still broadly classify these activities into two major types—
project planning and project monitoring and control.

Project planning: Project planning is undertaken immediately after the feasibility


study phase and before the starting of the requirements analysis and specification
phase.The initial project plans are revised from time to time as the project
progresses and more project data become available.
Project monitoring and control: Project monitoring and control activities are
undertaken once the development activities start.While carrying out project
monitoring and control activities, a project manager may sometimes find it necessary
to change the plan to cope up with specific situations at hand.
METRICS FOR PROJECT SIZE ESTIMATION

Accurate estimation of project size is central to satisfactory estimation of all other


project parameters such as effort,completion time, and total project cost. Before
discussing the available metrics to estimate the size of a project, let us examine what
does the term “project size” exactly mean. The size of a project is obviously not the
number of bytes that the source code occupies, neither is it the size of the
executable code.The project size is a measure of the problem complexity in terms of
the effort and time required to develop the product.Currently, two metrics are
popularly being used to measure size—lines of code (LOC) and function point (FP).
Each of these metrics has its own advantages and disadvantages. Based on their
relative advantages, one metric may be more appropriate than the other in a
particular situation.

EMPIRICAL ESTIMATION TECHNIQUES


We have already pointed out that empirical estimation techniques have, over the
years, been formalised to a certain extent. Yet, these are still essentially euphemisms
for pure guess work. These techniques are easy to use and give reasonably accurate
estimates. Two popular empirical estimation techniques are—Expert judgement and
Delphi estimation techniques. We discuss these two techniques in the following
subsection.
Expert Judgement:
Expert judgement is a widely used size estimation technique. In this technique, an
expert makes an educated guess about the problem size after analysing the problem
thoroughly. Usually, the expert estimates the cost of the different components (i.e.
modules or subsystems) that would make up the system and then combines the
estimates for the individual modules to arrive at the overall estimate. However, this
technique suffers from several shortcomings. The outcome of the expert judgement
technique is subject to human errors and individual bias. Also, it is possible that an
expert may overlook some factors inadvertently. Further, an expert making an
estimate may not have relevant experience and knowledge of all aspects of a
project. For example, he may be conversant with the database and user interface
parts, but may not be very knowledgeable about the computer communication part.
Due to these factors, the size estimation arrived at by the judgement of a single
expert may be far from being accurate. A more refined form of expert judgement is
the estimation made by a group of experts. Chances of errors arising out of issues
such as individual oversight, lack of familiarity with a particular aspect of a project,
personal bias, and the desire to win contract through overly optimistic estimates is
minimised when the estimation is done by a group of experts. However, the estimate
made by a group of experts may still exhibit bias. For example, on certain issues the
entire group of experts may be biased due to reasons such as those arising out of
political or social considerations. Another important shortcoming of the expert
judgement technique is that the decision made by a group may be dominated by
overly assertive members.
Delphi Cost Estimation:
Delphi cost estimation technique tries to overcome some of the shortcomings of the
expert judgement approach. Delphi estimation is carried out by a team comprising a
group of experts and a co-ordinator. In this approach, the co-ordinator provides each
estimator with a copy of the software requirements specification (SRS) document
and a form for recording his cost estimate. Estimators complete their individual
estimates anonymously and submit them to the co-ordinator. In their estimates, the
estimators mention any unusual characteristic of the product which has influenced
their estimations. The co-ordinator prepares the summary of the responses of all the
estimators, and also includes any unusual rationale noted by any of the estimators.
The prepared summary information is distributed to the estimators. Based on this
summary, the estimators re-estimate. This process is iterated for several rounds.
However, no discussions among the estimators is allowed during the entire
estimation process. The purpose behind this restriction is that if any discussion is
allowed among the estimators, then many estimators may easily get influenced by
the rationale of an estimator who may be more experienced or senior. After the
completion of several iterations of estimations, the co-ordinator takes the
responsibility of compiling the results and preparing the final estimate. The Delphi
estimation, though consumes more time and effort,
overcomes an important shortcoming of the expert judgement technique in that the
results can not unjustly be influenced by overly assertive and senior members.

COCOMO—A HEURISTIC ESTIMATION TECHNIQUE


Constructive Cost estimation Model (COCOMO) was proposed by Boehm [1981].
COCOMO prescribes a three stage process for project estimation. In the first stage,
an initial estimate is arrived at. Over the next two stages, the initial estimate is
refined to arrive at a more accurate estimate. COCOMO uses both single and
multivariable estimation models at different stages of estimation. The three stages of
COCOMO estimation technique are—basic COCOMO, intermediate COCOMO, and
complete COCOMO.
Basic COCOMO Model:
Boehm postulated that any software development project can be classified into one
of the following three categories based on the development complexity—organic,
semidetached, and embedded. Based on the category of a software development
project, he gave different sets of formulas to estimate the effort and duration from
the size estimate.
Intermediate COCOMO:
The basic COCOMO model assumes that effort and development time are functions
of the product size alone. However, a host of other project parameters besides the
product size affect the effort as well as the time required to develop the product. For
example the effort to develop a product would vary depending upon the
sophistication of the development environment. Therefore, in order to obtain an
accurate estimation of the effort and project duration, the effect of all relevant
parameters must be taken into account. The intermediate COCOMO model
recognises this fact and refines the initial estimates.
Complete COCOMO:
A major shortcoming of both the basic and the intermediate COCOMO models is that
they consider a software product as a single homogeneous entity. However, most
large systems are made up of several smaller sub-systems. These sub-systems often
have widely different characteristics. For example, some sub-systems may be
considered as organic type, some semidetached, and some even embedded. Not
only may the inherent development complexity of the subsystems be different, but
for some subsystem the reliability requirements may be high, for some the
development team might have no previous experience of similar development, and
so on.
ORGANISATION AND TEAM STRUCTURES
Usually every software development organisation handles several projects at any
time. Software organisations assign different teams of developers to handle different
software projects. With regard to staff organisation, there are two important issues
—How is the organisation as a whole structured? And, how are the individual project
teams structured? There are a few standard ways in which software organisations
and teams can be structured. We discuss these in the following subsection.
Organisation Structure Essentially there are three broad ways in which a software
development organisation can be structured—functional format, project format, and
matrix format. We discuss these three formats in the following subsection.
Functional format: In the functional format, the development staff are divided based
on the specific functional group to which they belong to. This format has
schematically been shown in Figure 3.13(a). The different projects borrow
developers from various functional groups for specific phases of the project and
return them to the functional group upon the completion of the phase. As a result,
different teams of programmers from different functional groups perform different
phases of a project. For example, one team might do the requirements specification,
another do the design, and so on. The partially completed product passes from one
team to another as the product evolves. Therefore, the functional format requires
considerable communication among the different teams and development of good
quality documents because the work of one team must be clearly understood by the
subsequent teams working on the project. The functional organisation therefore
mandates good quality documentation to be produced after every activity.
Project format :In the project format, the development staff are divided based on
the project for which they work (See Figure 3.13(b)). A set of developers is assigned
to every project at the start of the project, and remain with the project till the
completion of the project. Thus, the same team carries out all the life cycle activities.
An advantage of the project format is that it provides job rotation. That is, every
developer undertakes different life cycle activities in a project. However, it results in
poor manpower utilisation, since the full project team is formed since the start of
the project, and there is very little work for the team during the initial phases of the
life cycle..
Matrix format: A matrix organisation is intended to provide the advantages of both
functional and project structures. In a matrix organisation, the pool of functional
specialists are assigned to different projects as needed. Thus, the deployment of the
different functional specialists in different projects can be represented in a matrix
(see Figure 3.14) In Figure 3.14 observe that different members of a functional
specialisation are assigned to different projects. Therefore in a matrix organisation,
the project manager needs to share responsibilities for the project with a number of
individual functional managers.

Team Structure
Team structure addresses organisation of the individual project teams. Let us
examine the possible ways in which the individual project teams are organised. In
this text, we shall consider only three formal team structures—democratic, chief
programmer, and the mixed control team organisations, although several other
variations to these structures are possible. Projects of specific complexities and sizes
often require specific team structures for efficient working.
Chief programmer team:
In this team organisation, a senior engineer provides the technical leadership and is
designated the chief programmer. The chief programmer partitions the task into
many smaller tasks and assigns them to the team members. He also verifies and
integrates the products developed by different team members. The structure of the
chief programmer team is shown in Figure 3.15. The chief programmer provides an
authority, and this structure is arguably more efficient than the democratic team for
well-understood problems. However, the chief programmer team leads to lower
team morale, since the team members work under the constant supervision of the
chief programmer. This also inhibits their original thinking. The chief programmer
team is subject to single point failure since too much responsibility and authority is
assigned to the chief programmer. That is, a project might suffer severely, if the chief
programmer either leaves the organisation or becomes unavailable for some other
reasons.
Democratic team:
The democratic team structure, as the name implies, does not enforce any formal
team hierarchy . Typically, a manager provides the administrative leadership. At
different times, different members of the group provide technical leadership. In a
democratic organisation, the team members have higher morale and job
satisfaction. Consequently, it suffers from less manpower turnover. Though the
democratic teams are less productive compared to the chief programmer team, the
democratic team structure is appropriate for less understood problems, since a
group of developers can invent better solutions than a single individual as in a chief
programmer team. A democratic team structure is suitable for research-oriented
projects requiring less than five or six developers. For large sized projects, a pure
democratic organisation tends to become chaotic. The democratic team organisation
encourages egoless programming as programmers can share and review each
other’s work. To appreciate the concept of egoless programming, we need to
understand the concept of ego from a psychological perspective. Most of you might
have heard about temperamental artists who take much pride in whatever they
create. Ordinarily, the human psychology makes an individual take pride in
everything he creates using original thinking. Software development requires original
thinking too, although of a different type. The human psychology makes one
emotionally involved with his creation and hinders him from objective examination
of his creations. Just like temperamental artists, programmers find it extremely
difficult to locate bugs in their own programs or flaws in their own design. Therefore,
the best way to find problems in a design or code is to have someone review it.
Often, having to explain one’s program to someone else gives a person enough
objectivity to find out what might have gone wrong. This observation is the basic
idea behind code walk throughs to be discussed in Chapter 10. An application of this,
is to encourage a democratic teams to think that the design, code, and other
deliverables to belong to the entire group. This is called egoless programming
because it tries to avoid having programmers invest much ego in the development
activity they do in a democratic set up. However, a democratic team structure has
one disadvantage—the team members may waste a lot time arguing about trivial
points due to the lack of any authority in the team to resolve the debates.
Mixed control team organisation
The mixed control team organisation, as the name implies, draws upon the ideas
from both the democratic organisation and the chief-programmer organisation.. This
team organisation incorporates both hierarchical reporting and democratic set up.
The mixed control team organisation is suitable for large team sizes. The democratic
arrangement at the senior developers level is used to decompose the problem into
small parts. Each democratic setup at the programmer level attempts solution to a
single part. Thus, this team organisation is eminently suited to handle large and
complex programs. This team structure is extremely popular and is being used in
many software development companies.

You might also like