BIE3443 Software Project Management

INTRODUCTION
Project management as a special form of management evolved from the work done on
large-scale military projects where an organized approach was necessary to manage
the complex interrelationships among an enormous number of different tasks performed
by many different specialists. In recent years project management emerged as a major
new form of management to deal with the complexities of knowledge-based teamwork
in organizations facing rapidly changing business environments. Project management
provides managers with powerful methods and tools for planning, organizing, and
managing team-based activities for accomplishing specific objectives. Software projects
are generally complex and their development takes place in a dynamic environment
where business conditions and technologies change during the project which makes
them more costly and complex than any other types of projects.

All these complications derives from the following software management complexity
dominating factors such as incomplete requirements specification, technological
changes, Costs estimation, Intangibility, Process Complexity and many more. This
project provides all the facts, which make software development projects more complex
than any other types of projects; it also summarizes the models used for risk reduction
purposes.

Individual assignment 1
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

(A) THE COMPLEX DIMENSIONS THAT MAKE THE MANAGEMENT OF

SOFTWARE PROJECTS DIFFERENT FROM OTHER TYPES OF PROJECTS

Start with incomplete requirements specifications

The software manager has to apply his knowledge, skill and techniques so that he can
be able to reach the requirements of the user In most cases especially in software
development projects it's not easy to get all the system requirements before the projects
start so most of the system requirements are basically obtained during the progression
of the system, in some cases this may happen as a result of technological changes or in
a situation whereby the users are unable to specify their system requirements more
clearly. While in other projects the situation is different in most cases getting the user
requirements is not a big deal since most the projects which needs to be developed like
house construction project, the users requirements are very clear and straight forward
since the tools and the equipments need are already known from the first place the only
thing needed is to get a house plan correct nothing new.

Software projects have several properties that make them very different to other kinds
of engineering project.

Getting Clear Requirements

No civil engineer would start the construction of a bridge without having the plans and
requirements in hand. Sadly, software projects can easily reach the coding stage before
the requirements are clearly defined. Even when there appears to be agreement,
customers will often ask for modifications later, unaware of the impact this can have on
the budget and the schedule. At its core, the definition of the product is not a knowledge
issue but a relationship issue, and a strong relationship with the customer and the
marketing staff will make definition of the requirements much simpler.

Individual assignment 2
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

Costs estimation

Cost estimation is an essential component of infrastructure projects. Accurate

estimation will assist project managers to choose adequate alternatives and to avoid
misjudging of technical and economic solutions. The accuracy of cost estimation
increases toward the end of the project due to detailed and precise information. The
conceptual phase is the first phase of a project in which the need is examined,
alternatives are assessed, the goals and objectives of the project are established and a
sponsor is identified (Wideman R. M, 1995).

Major difficulties, which arise while conducting cost estimation during the conceptual
phase, are lack of preliminary information, lack of database of road works costs, and
lack of up to date cost estimation methods. Additional difficulties arise due to larger
uncertainties as result of engineering solutions, socio-economical, and environmental
issues

The fact that user requirement keep on changing, estimating the cost of software
development project is a rather unexplored field in which one all too often relies on mere
guesstimates. The notation of total cost is usually taken to indicate the cost of initial
software effort that is the cost of the requirement engineering, design, implementation
and testing phases.

Costs estimation is basic constraint of software engineering that states software

engineering costs are incurred from both necessary and futility costs and from both
development and maintenance cost. Many manager use coast benefit analysis to
decide whether a software project is worthwhile on its own merits and also in
comparison with other proposed information projects.

Cost usually relate to hardware and software, salaries of the information system staff,
and the ongoing operation maintenance of the system. Software engineering costs are
incurred from the contribution of both the necessary development costs and sank into
the black hole of inappropriate project organization. Software system cost too much to
be built. Also user requirements can make the cost to be high or low, e.g. less and clear

Individual assignment 3
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

requirements means less expensive and more and unclear requirements means the
project will be expensive.

As said earlier, it is easy to estimate the costs of other projects because it can be
calculated looking at the materials used to produce the whole product but the fact that
no materials used in software projects it is difficult to estimate the costs. And also the
pricing of softwares is not standardized.

According to Schwalbe (2005) there are several cost estimation techniques, which may
be used to determine effort or total cost of a software development project. A brief
description of some of these estimation techniques is provided below:

1. Algorithm Cost Modeling this is a group methods which provide computation

procedures which give software cost estimates as a function depending on a
number of variables which are consider to be major cost drivers.
2. Expert judgment This technique involves consulting one or more experts to
use their experience and understanding of the proposed project to arrive at a
consensus with regards to the project cost estimate. The experts may use
expert-consensus mechanisms such as group consensus Delphi technique. It is
used during the initial tendering and contractual negotiations stage.
3. Pricing to win pricing to win involves estimating the software cost to be
whatever the client has available to spend on the particular project. This
technique also involves some negotiations between the developer and the client.
It is most suitable when the client has financial constraints, and is willing to settle
for basic system that evolves over time. The software functionality is designed to
correspond to the client budget.

Intangibility

Software, unlike hardware, is intangible. As a result, software projects are difficult to

manage because they contain no visible milestones to measure their progress and
quality. When a physical artefact such as a bridge or road is being constructed the
progress being made can actually be seen. With software, progress is not immediately
Individual assignment 4
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

visible. The intangible nature of software causes problems for management in planning,
estimating, scheduling and budgeting for accounting purposes. Since software project
is neither seen nor touched, one has to rely on the team hired for that particular project
to provide accurate documentation on time, which is needed to track progress of the
project and its efficiency or output.

Its hard to claim a bridge is 90%complete if there is not 90% of thebridge there but very
easy to estimate the cost of materials needed to build the project while on the other
side, It is easy to claim that a software projectis 90% complete, even if there are
nonvisible outcomes stated Tsunokawa, K. T. (1983:343).

Intangible nature of software causes problems for management in planning, estimating,

scheduling and budgeting for accounting purposes. In addition, software project
manager must also be aware of and sensitive to their teammates, their communication
style, and their customers' requirements. Engineers require a different kind of education
than do scientists; engineering education should focus on applying a core body of
knowledge to produce reliable products, as opposed to scientific education, which
should teach how to extend our knowledge of what is true.

Large software projects are often bespoke. Most large software systems are one-off,
with experience gained in one project being of little help in another.

The technology changes very quickly.

It is not easy to guarantee that software may be useful in the next 5 or 6 years because
of rapid technology growth. A technology change is a basic constraint of software
engineering that states software engineering is inevitable. The changes are the
capabilities of the software products to enable a specified modification to be
implemented. Users also need to think out of the box while writing the requirements in
order the time they need to use the software. On the other hand it is difficult to design
software that will be leaving in 10 years to come. But with clothes designers, they know
that we will always wear jackets and coats every winter so nothing much to think.

Individual assignment 5
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

Most large software projects employ new technology; for many projects, this is the
raison detre convenient indicated Waren S. S., (2002).

Often entirely new The fact that new technology is introduced almost every day, what
ever is about to be developed is mostly something new and that makes it very difficult to
make some cost estimation unlike in other types of projects whereby the projects to be
developed most of them are already in existence so cost estimation can be done based
on previous projects statistics. For example in textile production projects, like clothing
industry it is always known that in different times of the season, people wear different
styles of clothes the only change can be on the design, even though we already have a
knowledge that in winter people wear jackets while in summer T-shirts are mostly
weared.

FLEXIBILITY

Changes in requirements often result in new features being added to the program, but
those changes can be more challenges especially when they were not foreseen in the
original program design. To preserve the integrity of the design when an unforeseen
feature is added the program must be refectories, such that it must be changed
structurally to accommodate the addition of the new feature.

While designing a software, to leave room for changes is very difficult especially if the
user requirements were not specific again technology changes rapidly according to
Mores Law and its difficult to define the rank of changes unlike in house construction
project whereby it very easy to get the user requirements are easily obtained at early
stage and the product produced is tangible, if a change is required on the way it is very
easy because its in rear cases that the change can affect the whole project.

Process Complexity

Complexity is a basic constrain of software engineering that states software is naturally

complex and its intricate internal connections and external coupling make it extremely
difficult to be expressed or cognized. Meaning that there is no standard software
processes. Furthermore, no language, tool, or technology may reduce the complexity of
a given problem itself. There is no clear understanding of relationship between software
Individual assignment 6
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

process and product types the process is tried and tested. The complexity of software
project can be analyzed from the aspects of user requirement where by some user do
not know exactly what they want and it give the designer a difficult task. The designing
of a t-shirt or a wedding dress may be easily understood.

The complexity of software project refers to the complexities of its architectural

complexity that is not easy to analysis software system with its data objects and their
external or internal representations. Furthermore, the behavioral complexity is the
complexity of software system with its process and their inputs and outputs. And also,
the environment complexity it the complexity of software system with its platform,
related interacting process and users. The naturally inherited complexity of object of
study makes software project manager one of the most complicated project fields.

Software developer may design a newly system that never existed before that means
there will be no standards regulating the way it should be made. Unlike in other types of
projects whereby most of project developed already have rules and regulations or the
standards that needs to be followed in development and implementation processes.
This can save more money which be used in the process of coming out with those
standards.

(B) USER REQUIREMENTS COMPLICATING THE MANAGEMENT OF SOFTWRE

PROJECT

The user requirements document (URD) or user requirement(s) specification is a

document usually used in software engineering that specifies the requirements the user
expects from software to be constructed in a software project. Once the required
information is completely gathered it is documented in a URD, which is meant to spell
out exactly what the software must do and becomes part of the contractual agreement.

Analysts report that as many as 71% of software projects that faildo so because of poor
requirements management, making it the single biggest reason for project failure
bigger than bad technology, missed deadlines or change management fiascoes.

Individual assignment 7
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

Project requirements provide an obvious tool for evaluating the quality of a project,
because a final review should examine whether each requirement has been met.
Unfortunately, it is never quite that easy. Requirements tend to change through the
course of a project, with the result that the product as delivered may not adhere to the
available requirements this is a constant and annoying facet to the quality assurance
process. Moreover, meeting all of the requirements does not ensure a quality product,
per se, since the requirements may not have been defined with an eye towards the
quality of the end-users experience.

Moreover a requirement is an objective that mustbe met. Planners cast most

requirements in functional terms, leaving design and implementation details to the
developers. They may specify price, performance, and reliability objectives in fine detail,
along with some aspects of the user interface. Sometimes, they describe their
objectives more precisely than realistically.

Figure 1.1 shows the problems encountered during the requirements engineering
process.

Individual assignment 8
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

Figure 1.1

From figure 1.1, user involvement in the field of information system development is
usually considered as vital mechanism to enhance system quality and ensure
successful system implementation. However user requirements is a dominant factor that
complicates the management of software projects. It is recognized by software
developers that the process of involving users in the design of software projects is time-
consuming and costly and can politicize the issues surrounding development of
software projects. Somerville says user requirements are a dominant factor in
complicating user requirements because they never stable.

Continuing, the users do not know exactly what they want so this makes it really difficult
for software developers in a sense that the developer cannot decide for the user like
other projects like road constructing where the developer can decide to use tarred road
from a particular point to another point and all that is left is for the constructors own
discretion to conclude on what to use. Users often require or provide specifications
without even knowing having asked if what they want is something that is doable hence

Individual assignment 9
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

submitting requirements that are not stable and keep changing giving developers a
huge problem.

(C) RISK REDUCTION PLANNING IN SOFTWARE DEVELOPMENT

RISK REDUCTION PLANNING: An important aspect of risk reductionplanning involves

choosing a process model that offers a structure designedto reduce risk and
uncertainty. It aims to ensure manageability of the fussyhighly unstructured areas of the
project, thereby reducing the developmentproject's total risk exposure to a minimum.
Generally, the types of risksinvolved include: requirements failures, budget overruns,
late deliveries, technical competencies, product failures, skills shortages etc. The
problemof software development project risks are often managed through theadoption
of risk reduction software process models. The choice of oneprocess model largely
depends on the nature and scope of the software development project specified
Wideman, R. M., (1995:344).

This thesis proposes a Goal-driven Software Development Risk Management Model

(GSRM) that explicitly integrates into the requirements engineering phase. The
integration provides an early warning of potential problems so that both preventive and
corrective actions can be undertaken to avoid the causes of project failure. The
framework is comprised of four layers, i.e., goal, obstacle, assessment and treatment
that support the identification, assessment, treatment and documentation of risks in
relation to project-specific goals.

Hughes, B. and Cotterell, M., (2006:184) stipulates that risk aspects include:
requirements failures, budget overruns, late deliverables, technical competencies,
product failures, and skills shortage. The problem of software development project risks
is often managed through the adoption of risk reduction software process models. The
choice of one process model largely depends on the nature and scope of the software
development project.

Individual assignment 10
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

Goal-driven risk management model from holistic perspective: This research

contributes an integrated modeling framework for software development risk
management, called Goal-driven Software Development Risk Management Model
(GSRM). The framework is comprised of a conceptual model, analysis techniques and a
methodology to systematically identify, model, analyze and control risks to attain the
project specific goals.

The model considers goals beyond schedule, budget and quality and realizes the
importance of motivating project stakeholders in particular customer/user to take an
active part in the software project.

Systematic risk assessment and management during requirements engineering:

The proposed model supports an effective, systematic and straightforward way to
manage software risks. We define the activities, tasks, steps and underlying roles for a
detailed goal-driven risk management process models stated Pearce A. R., Gregory,
Rita A., and Williams L. (322: 1996). The early integration supports to assess and
manage risks related to the project execution, development environment, operational
constraints and project stakeholders even before elicitation of the system requirements.

(D) SOFTWARE PROCESS MODELS AND HOW THE RELATE TO RISK

DEDUCTION IN SOFTWARE PROJECT MANAGEMENT

A (software or system) process model is a description of the sequence of

activitiescarried out in a Software Engineering project, and the relative order of these
activities. It provides a fixed generic framework that can be tailored to a specific
project.

(a) The Evolutionary Development Process Model: This model involves

thedevelopment of a sequence of functional systems. Each system iscomplete in the
sense that it provides full functionality to the user, butthe aim is to evolve the system
over time through a series of versionswhich build upon existing functionality for
enhancement. This processmodel is most appropriate where the requirements are well
Individual assignment 11
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

known andclearly defined (to enable the construction of the first version of theentire
system). With the understanding that when the system becomesoperational, there shall
be need for significant improvements on thesystem, it is designed to incorporate
evolutionary changes.

(b) The incremental Deliver Process Model: This model involves thedevelopment and
delivery of a series of small increments of usable butpartially functional systems. The
last increment completes the deliveryof the fully functional system (incorporating all the
user requirements).It is most appropriate where only some of the functionality of
thesystem is required initially and the remaining functionality over anumber of
increments.

(c) The V Process Model Deliver Process Model: The V process modeldescribes a
software development project in terms of a progression ofstages from requirements
analyses, through to the system definition, system design and implementation, on
through unit testing, systemintegration and system acceptance. It emphasizes the fact
that activitiesin the latter half of the project are all about testing implementations ofthe
specifications produced in the earlier half. This process model ismost appropriate if the
project is well understood in that it is wellspecified and a development route can be
clearly mapped out from theonset.

Individual assignment 12
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

CONCLUSION

Software project management project is very complex more than any other type of
project ranging from equipment used, skills needed in the development even gathering
the system requirements ischallenging. The system to be developed is no tangible
which makes it hard to claim the completeness of the project and also to track the
milestone unlike other projects such as bridge construction whereby it is easy to track
the progress becausethe output is tangible.

For example, it is hard to claim a bridge is 90% complete if there is not 90% of the
bridge and very easy to estimate the cost of materials needed to build the project.
Moreover there comes problems with the requirements based on statistics whereby it is
proofed byAnalysts and their report states that 71% of software projects that fail do so
because of poor requirements management, making it the single biggest reason for
project failure bigger than bad technology, missed deadlines or change management
fiascoes.

Due to the fact that it is not easy identify all the risks in the system development but at
least their some ways used totackle those uncertainty which are risk reduction planning
method which involves choosing a process model that offers a structure designed to
reduce risks and uncertainties such as The V Process Model Deliver Process Model,
The incremental Deliver Process Model and The Evolutionary Development Process
Model.

Individual assignment 13
BSITY4S1 2017
Faculty of Information and Communication Technology
BIE3443 Software Project Management

REFFERENCES

Ian Sommerville., (2004). Software Engineering. Addison Wesley, 7th edition.

Hughes, B. and Cotterell, M., (2006). Software Project Management. 4th edition.
McGraw-Hill.

N. Whitten., (1995). Managing Software Development Projects, 4th Edition. New York.

Tsunokawa, K. T. (1983). Evaluation and Improvement of Road Construction Cost

Models: Unpublished draft working paper prepared for the World Bank. Washington,
D.C. World Bank.

Pearce A. R., Gregory, Rita A., and Williams L. (1996). Range Estimating for risk
management using artificial neural networks, Journal of Parametric Estimating, 14(1),
pp 88-93.

Schwalbe, K., (2005). Information Technology Project Management. 4th edition. Course
Technology.

Wideman, R. M., (1995). Cost Control of Capital Projects. Richmond, BC V7A, Canada:
BiTech Publishers Ltd.

Waren S. S., (2002), comp.ai.neural-nets FAQ, Available online:

http://www.faqs.org/faqs/ai-faq/neural-nets/ [Accessed: September 06, 2017].

Individual assignment 14
BSITY4S1 2017
Faculty of Information and Communication Technology