Software Project Management BIT715/Software Project Management CS615 book HANDOUTS in pdf
Handouts | Lectures | Contents | Books
Handouts | Lectures | Contents | Books
Software Project Management (CS615)
1
© Copyright Virtual University of Pakistan
LECTURE # 1
1. Introduction & Fundamentals
1.1 What is Management?
Basically, the management involves the following activities:
Planning- deciding what is to be done
Organizing- making arrangements
Staffing- selecting the right people for the job
Directing- giving instructions
Monitoring- checking on progress
Controlling- taking action to remedy hold-ups
Innovating- coming up with new solutions
Representing- liaising with users, etc.
1.2 What is Project Management?
Project Management is the art of maximizing the probability that a project
delivers its goals on Time, to Budget and at the required Quality.
The art of planning for the future has always been a human trait. In essence a
project can be captured on paper with a few simple elements: a start date, an end
date, the tasks that have to be carried out and when they should be finished, and
some idea of the resources (people, machines etc) that will be needed during the
course of the project.
Project management is the application of knowledge, skills, tools, and
techniques to project activities to meet project requirements. Project management
is accomplished through the use of the processes such as: initiating, planning,
executing, controlling, and closing. It is important to note that many of the
processes within project management are iterative in nature. This is in part due to
the existence of and the necessity for progressive elaboration in a project
throughout the project life cycle; i.e., the more you know about your project, the
better you are able to manage it.
Project management is also defined as a strategic competency that has successfully been
applied in such high profile projects as the construction of silk root, organizing and managing the
Olympics Games, and the construction of Islamabad-Lahore motorway, just to name a few. If
project management can play a major role in these success stories, just imagine what it might be
able to do for your own organization.
The term project management is sometimes used to describe an organizational
approach to the management of ongoing operations. This approach, more properly
called management by projects, treats many aspects of ongoing operations as
projects to apply project management techniques to them.
Software Project Management (CS615)
2
© Copyright Virtual University of Pakistan
Almost any human activity that involves carrying out a non- repetitive task
can be a project. So we are all project managers! We all practice project
management (PM). But there is a big difference between carrying out a very
simple project involving one or two people and one involving a complex mix of
people, organizations and tasks.
1.3 What is Software Project Management?
When the plan starts to involve different things happening at different times, some
of which are dependent on each other, plus resources required at different times
and in different quantities and perhaps working at different rates, the paper plan
could start to cover a vast area and be unreadable.
Nevertheless, the idea that complex plans could be analyzed by a computer to
allow someone to control a project is the basis of much of the development in
technology that now allows projects of any size and complexity, not only to be
planned, but also modeled to answer 'what if?' questions.
The original programs and computers tended to produce answers long after an
event had taken place. Now, there are many project planning and scheduling
programs that can provide real time information, as well as linking to risk
analysis, time recording, and costing, estimating and other aspects of project
control.
But computer programs are not project management: they are tools for
project managers to use. Project management is all that mix of components of
control, leadership, teamwork, resource management etc that goes into a
successful project.
Project managers can be found in all industries. Their numbers have grown
rapidly as industry and commerce has realized that much of what it does is project
work. And as project-based organizations have started to emerge, project
management is becoming established as both a professional career path and a way
of controlling business.
So opportunities in project management now exist not only in being a project
manager, but also as part of the support team in a project or program office or as a
team leader for part of a project. There are also qualifications that can be attained
through the professional associations.
Software Project Management (CS615)
3
© Copyright Virtual University of Pakistan
1.4 What is a Project?
A project is an activity with specific goals which takes place over a finite
period of time.
“A temporary organization that is needed to produce a unique and pre-defined
outcome or result at a pre-specified time using pre-determined resources”
Projects are often implemented as a means of achieving an organization’s
strategic plan. Operations and projects differ primarily in that operations are
ongoing and repetitive while projects are temporary and unique. A project can
thus be defined in terms of its distinctive characteristics—a project is a temporary
endeavor undertaken to create a unique product or service. Temporary means
that every project has a definite beginning and a definite end. Unique means that
the product or service is different in some distinguishing way from all other
products or services. For many organizations, projects are a means to respond to
those requests that cannot be addressed within the organization’s normal
operational limits.
Projects are undertaken at all levels of the organization. They may involve a
single person or many thousands. Their duration ranges from a few weeks to more
than five years. Projects may involve a single unit of one organization or may
cross organizational boundaries, as in joint ventures and partnering.
Examples of projects include:
• Developing a new product or service.
• Effecting a change in structure, staffing, or style of an organization.
• Designing a new transportation vehicle.
• Developing or acquiring a new or modified information system.
• Constructing a building or facility.
• Building a water system for a community in a developing country.
• Running a campaign for political office.
• Implementing a new business procedure or process.
1. Temporary
Temporary means that every project has a definite beginning and a definite end.
The end is reached when the project’s objectives have been achieved, or it
becomes clear that the project objectives will not or cannot be met, or the need for
the project no longer exists and the project is terminated. Temporary does not
necessarily mean short in duration; many projects last for several years. In every
case, however, the duration of a project is finite; projects are not ongoing efforts.
2. Unique, Product Service or Result
Projects involve creating something that has not been done in exactly the same
way before and which is, therefore, unique and distinct. Projects create:
Software Project Management (CS615)
4
© Copyright Virtual University of Pakistan
• A product or artifact that is produced, is quantifiable and can be either an
end item in itself or a component item
• A capability to perform a service, such as business functions supporting
production or distribution
• A result, such as new knowledge. For example, a research and
development project develops knowledge that can be used to determine
whether or not a trend is present or a new process will benefit society.
The presence of repetitive elements does not change the fundamental uniqueness
of the project work. For example:
• A project to develop a new commercial airliner may require multiple
proto-types.
• A project to bring a new drug to market may require thousands of doses of
the drug to support clinical trials.
• A real estate development project may include hundreds of individual
units.
• A development project (e.g., water and sanitation) may be implemented in
five geographic areas.
3. Aims/Tasks/Purpose
The projects are designed to achieve specific targets defined in terms of aims,
tasks or a purpose. The nature and size of the project depends upon
complexity of the task, realization of the aims and scope of the purpose any
organization wants to achieve. In short project has to be aimed for achieving
certain tasks in a given time frame.
4. Limited Time Scale
The projects are always designed considering time constraints. Extension to
the project completion dead lines are always discouraged as time overrun,
costs extra and in some cases opportunity cost for not completing a project is
too high.
Progressive, Elaboration
Progressive elaboration is a characteristic of projects that accompanies the
concepts of temporary and unique. “Progressively” means developing thoroughly
in steps, and continuing steadily by increments while elaborated means “worked
out with care and detail; developed thoroughly”
For example, the project scope will be broadly described early in the project, and
made more explicit and detailed as the project team develops a better and more
complete understanding of the objectives and deliverables.
Progressive elaboration of project specifications must be carefully coordinated
with proper project scope definition, particularly if the project is performed under
contract. When properly defined, the scope of the project—the work to be done—
Software Project Management (CS615)
5
© Copyright Virtual University of Pakistan
should be controlled as the project and product specifications are progressively
elaborated.
The following examples illustrate progressive elaboration in two different
application areas.
Example 1. Development of a chemical processing plant begins with process
engineering to define the characteristics of the process. These characteristics are
used to design the major processing units. This information becomes the basis for
engineering design, which defines both the detail plant layout and the mechanical
characteristics of the process units and ancillary facilities. All of this results in
design drawings that are elaborated to produce fabrication and construction
drawings. During construction, interpretations and adaptations are made as
needed and subject to proper approval. This further elaboration of the deliverables
is captured in as-built drawings, and final operating adjustments are made during
testing and turnover.
Example 2. The product of an economic development project may initially be
defined as: “Improve the quality of life of the lowest income residents of
community X.” As the project proceeds, the products may be described more
specifically as, for example: “Provide access to food and water to 500 low income
residents in community X.” The next round of progressive elaboration might
focus exclusively on increasing agriculture production and marketing, with
provision of water deemed to be a secondary priority to be initiated once the
agricultural component is well under way.
Software Project Management (CS615)
6
© Copyright Virtual University of Pakistan
LECTURE # 2
1. Introduction & Fundamentals
1.5 Goals of Project management
Project management is the discipline of defining and achieving a set of goals
while optimizing the use of allocated resources (time, money, people, space,
etc). This includes planning, scheduling and maintaining progress of the
activities that comprise the project. Project management is normally reserved for
focused, non-repetitive, time-limited activities with some degree of risk and that
are beyond the usual scope of program (operational) activities for which the
organization is responsible.
Project management software describes the tools to efficiently coordinate and
automate the various project management component processes. Project
management software generally offers extensive reporting features, such as dayto-
day status updates of project progress, scheduling and dependency trees, and
system-generated alerts when schedules slip beyond pre-set tolerances. Most
project management tools include web-accessible interfaces so that employees
can access features of the software relevant to their needs, and functionality to
allow managers to share resource pools without overbooking.
1.6 Project Characteristics
1. Temporary
Temporary means that every project has a definite beginning and a definite end.
The end is reached when the project’s objectives have been achieved, or it
becomes clear that the project objectives will not or cannot be met, or the need for
the project no longer exists and the project is terminated. Temporary does not
necessarily mean short in duration; many projects last for several years. In every
case, however, the duration of a project is finite; projects are not ongoing efforts.
2. Unique, Product Service or Result
Projects involve creating something that has not been done in exactly the same
way before and which is, therefore, unique and distinct. Projects create:
• A product or artifact that is produced, is quantifiable and can be either an
end item in itself or a component item
• A capability to perform a service, such as business functions supporting
production or distribution
Software Project Management (CS615)
7
© Copyright Virtual University of Pakistan
• A result, such as new knowledge. For example, a research and
development project develops knowledge that can be used to determine
whether or not a trend is present or a new process will benefit society.
The presence of repetitive elements does not change the fundamental uniqueness
of the project work. For example:
• A project to develop a new commercial airliner may require multiple
proto-types.
• A project to bring a new drug to market may require thousands of doses of
the drug to support clinical trials.
• A real estate development project may include hundreds of individual
units.
• A development project (e.g., water and sanitation) may be implemented in
five geographic areas.
5. Aims/Tasks/Purpose
The projects are designed to achieve specific targets defined in terms of aims,
tasks or a purpose. The nature and size of the project depends upon
complexity of the task, realization of the aims and scope of the purpose any
organization wants to achieve. In short project has to be aimed for achieving
certain tasks in a given time frame.
6. Limited Time Scale
The projects are always designed considering time constraints. Extension to
the project completion dead lines are always discouraged as time overrun,
costs extra and in some cases opportunity cost for not completing a project is
too high.
1.7 Four Project Dimensions
Software project management is an umbrella activity within software engineering.
It begins before any technical activity is initiated and continues throughout the
definition, development, and support of computer software.
Four P's have a substantial influence on software project management- people,
product, process, and project.
• People must be organized into effective teams, motivated to do high-quality
software work, and coordinated to achieve effective communication.
• The product requirements must be communicated from customer to
developer, partitioned (decomposed) into their constituent parts, and
positioned for work by the software team.
• The process must be adapted to the people and the problem. A common
process framework is selected, an appropriate software engineering paradigm
is applied, and a set of work tasks is chosen to get the job done.
Software Project Management (CS615)
8
© Copyright Virtual University of Pakistan
• The project must be organized in a manner that enables the software team to
succeed.
Effective software project management focuses on the four P’s: people, product,
process, and project. The order is not arbitrary. The manager who forgets that
software engineering work is an intensely human endeavor will never have
Success in project management. A manager who fails to encourage
comprehensive customer communication early in the evolution of a project risks
building an elegant solution for the wrong problem. The manager who pays little
attention to the process runs the risk of inserting competent technical methods and
tools into a vacuum. The manager who embarks without a solid project plan
jeopardizes the success of the product.
⇒ People
In a study published by the IEEE, the engineering vice presidents of three
major technology companies were asked the most important contributor to a
successful software project. They answered in the following way:
VP 1: I guess if you had to pick one thing out that is most important in our
environment. I’d say it’s not the tools that we use, it’s the people.
VP 2: The most important ingredient that was successful on this project was
having smart people…very little else matters in my opinion....The most
important thing you do for a project is selecting the staff...The success of the
software development organization is very, very much associated with the
ability to recruit good people.
VP 3: The only rule I have in management is to ensure I have good people –
real good people-and that I grow good people – and that I provide an
environment in which good people can produce.
Indeed, this is a compelling testimonial on the importance of people in the
software engineering process. And yet, all of us, from senior engineering vice
presidents to the lowliest practitioner, often take people for granted. Managers
argue (as the preceding group had) that people are primary, but their actions
sometimes belie their words. In this section we examine the players who
participate in the software process and the manner in which they are organized
to perform effective software engineering.
1. The Players
The software process (and every software project) is populated by players
who can be categorized into one of five constituencies:
1. Senior managers who define the business issues that often have
significant influence on the project.
Software Project Management (CS615)
9
© Copyright Virtual University of Pakistan
2. Project (technical) managers who must plan, motivate, organize,
and control the practitioners who do software work.
3. Practitioners who deliver the technical skills that are necessary to
engineer a product or application.
4. Customers who specify the requirements for the software to be
engineered and other stakeholders who have a peripheral interest in
the outcome.
2. End-users
Who interact with the software once it is released for production use.
Every software project is populated by people who fall within this
taxonomy. To be effective, the project team must be organized in a way
that maximizes each person’s skills and abilities. And that’s the job of the
team leader.
3. Team Leaders
Project management is a people-intensive activity, and for this reason,
competent practitioners often make poor team leaders. They simply don’t
have the right mix of people skills. And yet, as Edgemon states:
“unfortunately and all too frequently it seems, individuals just fall into a
project manager role and become accidental project managers.” [EDG95].
The cultivation of motivated, highly skilled software people has been
discussed since the 1960s (e.g., [COUBO] [WIT94} [DEM9B]). In fact,
the “people factor’ is so important that the Software Engineering Institute
has developed a people management capability maturity model (PMCMM),
“to enhance the readiness of software organizations to undertake
increasingly complex applications by helping to attract, grow, motivate,
deploy, and retain the talent needed to improve their software
development capability” [CUR94].
The people management maturity model defines the following key
practice areas for software people: recruiting, selection, performance
management, training, compensation, career development, organization
and work design, and team/culture development. Organizations that
achieve high levels of maturity in the people management area have a
higher likelihood of implementing effective software engineering
practices.
The PM-CMM is a companion to the software capability maturity model
that guides organizations in the creation of a mature software process.
⇒ The Process
Software Project Management (CS615)
10
© Copyright Virtual University of Pakistan
In a fascinating book that provides an economist’s view of software and
software engineering, Howard Baetjer. Jr, comments on the software process:
Software development is a social learning process. The process is a dialogue
in which the knowledge that must become the software is brought together and
embodied in the software. The process provides interaction between users and
designers: between users and evolving tools, and between designers and
evolving tools [technology] It is an iterative process in which the evolving tool
itself serves as the medium for communication, with each new round of the
dialogue eliciting more useful knowledge from the people involved.
When you build a product or system, it’s important to go through a series of
predictable steps – a road map that helps you create a timely, high-quality
result, The road map that you follow is called a ‘software process’ .
Software engineers and their managers adapt the process to their needs and
then follow it. In addition, the people who have ties defined by the process
requested the software play a role in the software process.
At a detailed level, the process that you adopt depends on the software you’re
building. One process might be appropriate for creating software for an
aircraft avionics system, while an entirely different process would be
indicated for the creation of a web site.
From the point of view of a software engineer, the work products are the
programs, documents and data produces as a consequence of the software
engineering activities defined by the process.
A software process provides the framework from which a comprehensive plan
for software development can be established.
A small number of framework activities are applicable to all software projects,
regardless of their size or complexity.
A number of different task sets-tasks, milestones, work products and; quality
assurance points-enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the project
team.
Finally, umbrella activities – such as software quality assurance, software
configuration management, and measurement – overlay the process model.
Umbrella activities are independent of anyone framework activity and occur
throughout the process.
Software Project Management (CS615)
11
© Copyright Virtual University of Pakistan
LECTURE # 3
1. Introduction & Fundamentals
1.8 Project Dimensions
⇒ Product and Technology
– The 80:20, rule was originated by Vilfredo Pareto, an Italian economist who
studies the distribution of wealth in a variety of countries around 1900. He
discovered a common phenomenon: about 80% of the wealth in most countries
was controlled by a consistent minority -- about 20% of the people. Pareto called
this a "predictable imbalance." His observation eventually became known as
either the "80:20 rule" or "Pareto's Principle."
The credit for adapting Pareto's economic observations to business goes to the
"Father of Total Quality Management," service quality consultant Joseph M.
Juran. In 1950, he published "The Quality Control Handbook," which first
recognized the applicability of the Pareto principle in the context of inventory
management, e.g.:
• 20% of the repair parts normally account for 80 percent of the total
inventory
• 80% of production volume usually comes from 20% of the producers
He subsequently recognized that this rule of thumb was universally applicable
across fields of endeavor. As a credit to Pareto's work, Juran named his finding
the Pareto Principle. This universal management theory became generalized as
"the 80-20 Rule":
The "80:20 rule" has become one of the best known "leadership shorthand terms"
reflecting the notion that most of the results (of a life, of a program, of a financial
campaign) come from a minority of effort (or people, or input).
The Rule, states that a small number of causes (20%) is responsible for a large
percentage (80%) of the effect. It means that in anything a few (20 percent) are
vital and many (80 percent) are trivial.
There is an inherent imbalance between cause and effect, effort and reward, inputs
and outputs, etc; and that imbalance tends to the ratio of 80:20. So, if we know
which 20% of our work produces 80% of our income, we can do more of it and
our income will increase proportionately!
Software Project Management (CS615)
12
© Copyright Virtual University of Pakistan
You know 20 percent of you stock takes up 80 percent of your warehouse space
and that 80 percent of your stock comes from 20 percent of your suppliers. Also
80 percent of your sales will come from 20 percent of your sales staff. 20 percent
of your staff will cause 80 percent of your problems, but another 20 percent of
your staff will provide 80 percent of your production. It works both ways.
Some Sample 80/20 Rule Applications
80% of process defects arise from 20% of the process issues.
20% of your sales force produces 80% of your company revenues.
80% of delays in schedule arise from 20% of the possible causes of the delays.
80% of customer complaints arise from 20% of your products or services.
How It Can Help You
– The value of the Pareto Principle for a manager is that it reminds you to focus on
the 20 percent that matters. Of the things you do during your day, only 20 percent
really matter. Those 20 percent produce 80 percent of your results. Identify and
Characteristic
focus on those things. When the fire drills of the day begin to sap your time,
remind yourself of the 20 percent you need to focus on. If something in the
schedule has to slip, if something isn't going to get done, make sure it's not part of
that 20 percent.
Pareto's Principle, the 80/20 Rule, should serve as a daily reminder to focus 80
percent of your time and energy on the 20 percent of you work that is really
important. Don't just "work smart", work smart on the right things.
– Size
The larger product, there will be more requirements and features to deliver,
eventually it will take more time in its production. So if you cut the size of the
produce to half it will save you 60% of the effort.
– Characteristic
– Development Tools
Software Project Management (CS615)
13
© Copyright Virtual University of Pakistan
Customer delivered value
1.9 Project Phases
Organizations performing projects will usually divide each project into several
Project phases to improve management control and provide for links to the
ongoing operations of the performing organization.
Collectively, the project phases are known as the project life cycle. Software
development, just like most other activities, has a beginning, middle and an end.
The end of one development activity is sometimes perceived as being linked to
the beginning of a new development activity thus producing a cycle of beginningmiddle-
end, link, beginning-middle-end, link, and so forth.
This view of software development is referred to as the software development
life cycle.
A project has five phases. Here's a brief summary of each:
⇒ Initiation
Articulate your vision for the project, establish goals, assemble your team,
and define expectations and the scope of your project.
⇒ Planning
Refine the scope, identify specific tasks and activities to be completed,
and develop a schedule and budget.
⇒ Executing
Accomplish your goals by leading your team, solving problems, and
building your project.
Value of products
Value of services
Financial cost
Personal value
Psychical cost
Image value
Time cost
Real value to
the customer
Total value
Total costs
Energy cost
+
-
Software Project Management (CS615)
14
© Copyright Virtual University of Pakistan
⇒ Controlling
Monitor changes to the project make corrections, adjust your schedule to
respond to problems, or adjust your expectations and goals.
⇒ Closing
Deliver your project to your audience, acknowledge results, and assess its
success. Take the time to compose a written evaluation of the project and
the development effort.
The middle three phases are not sequential. You will find that you are constantly
planning, executing, and controlling your project as necessary.
Aren't these phases really just common sense? In many ways, yes, but keep in
mind that software development, whether a few Web pages or a complex CDROM,
is a complex, unpredictable process.
Most software projects (something like 80 percent) are delivered late,
substantially over budget, and incomplete. The more effort you put into managing
your project, the more you increase your chances of success.
– Characteristics of Project Phases
Each project phase is marked by completion of one or more deliverables. A
deliverable is a tangible, verifiable work product such as a feasibility study, a
detail design, or a working prototype. The deliverables, and hence the phases, are
part of a generally sequential logic designed to ensure proper definition of the
product of the project.
The conclusion of a project phase is generally marked by a review of both key
deliverables and project performance to date, to a) determine if the project should
continue into its next phase and b) detect and correct errors cost effectively. These
phase-end reviews are often called phase exits, stage gates, or kill points.
Each project phase normally includes a set of defined deliverables designed to
establish the desired level of management control. The majority of these items are
related to the primary phase deliverable, and the phases typically take their names
from these items: requirements, design, build, test, startup, turnover, and others,
as appropriate.
– Characteristics of the Project Life Cycle
The project life cycle serves to define the beginning and the end of a project. For
example, when an organization identifies an opportunity to which it would like to
respond, it will often authorize a needs assessment and/or a feasibility study to
decide if it should undertake a project. The project life-cycle definition will
determine whether the feasibility study is treated as the first project phase or as a
separate, standalone project.
Software Project Management (CS615)
15
© Copyright Virtual University of Pakistan
The project life-cycle definition will also determine which transitional actions at
the beginning and the end of the project are included and which are not. In this
manner, the project life-cycle definition can be used to link the project to the
ongoing operations of the performing organization.
The phase sequence defined by most project life cycles generally involves some
form of technology transfer or handoff such as requirements to design,
construction to operations, or design to manufacturing. Deliverables from the
preceding phase are usually approved before work starts on the next phase.
However, a subsequent phase is sometimes begun prior to approval of the
previous phase deliverables when the risks involved are deemed acceptable. This
practice of overlapping phases is often called fast tracking.
Project life cycles generally define:
What technical work should be done in each phase (e.g., is the work of the
architect part of the definition phase or part of the execution phase?).
Who should be involved in each phase (e.g., implementers who need to be
involved with requirements and design).
Project life-cycle descriptions may be very general or very detailed. Highly
detailed descriptions may have numerous forms, charts, and checklists to
provide structure and consistency. Such detailed approaches are often called
project management methodologies.
Most project life-cycle descriptions share a number of common
characteristics:
Cost and staffing levels are low at the start, higher toward the end, and drop
rapidly as the project draws to a conclusion.
The probability of successfully completing the project is lowest, and hence
risk and uncertainty are highest, at the start of the project. The probability of
successful completion generally gets progressively higher as the project
continues.
The ability of the stakeholders to influence the final characteristics of the
project’s product and the final cost of the project is highest at the start and
gets progressively lower as the project continues. A major contributor to this
phenomenon is that the cost of changes and error correction generally
increases as the project continues.
Care should be taken to distinguish the project life cycle from the product life
cycle. For example, a project undertaken to bring a new desktop computer to
market is but one phase or stage of the product life cycle.
Although many project life cycles have similar phase names with similar
deliverables required, few are identical. Most have four or five phases, but some
Software Project Management (CS615)
16
© Copyright Virtual University of Pakistan
have nine or more. Even within a single application area, there can be significant
variations.
One organization’s software development life cycle may have a single design
phase while another’s has separate phases for functional and detail design.
Subprojects within projects may also have distinct project life cycles. For
example, an architectural firm hired to design a new office building is first
involved in the owner’s definition phase when doing the design, and in the
owner’s implementation phase when supporting the construction effort. The
architect’s design project, however, will have its own series of phases from
conceptual development through definition and implementation to closure. The
architect may even treat designing the facility and supporting the construction as
separate projects with their own distinct phases.
– Project Life Cycle includes the following Phases and activities:
A. Concept Phase
1. User Need
2. Initial Investigation
3. User Review
4. System Performance Design
5. Candidate Review
6. Study Phase Report
B. Requirements Phase
1. The software requirements specification document
2. The project development plan
3. The software test plan
C. Design Phase
1. General System Review
2. Processing Requirements Identification
3. Data Base Design
4. Control Requirements
5. Output Design
6. Input Design
7. Software Selection
8. Equipment Selection/Acquisition
9. People
10. Reference Manual Identification
11. Plans
12. Design Specifications Preparation
13. Design Phase Report Preparation
D. Development Phase
Software Project Management (CS615)
17
© Copyright Virtual University of Pakistan
1. Implementation Planning
2. Computer Program Design
3. User Review
4. Equipment Acquisition and Installation
5. Coding and Debugging
6. Computer Program Testing
7. System Testing
8. Reference Manual Preparation
9. Personnel Training
10. Changeover Plan Preparation
11. Development Phase Report Preparation
12. User Acceptance Review
E. Operation Phase
1. System Changeover
2. Routine Operation
3. System Performance Evaluation
4. System Changes/Enhancements
1.10 Software Development Lifecycle
⇒ Water Fall Theme
Software development, just like most other activities, has a beginning, middle and
an end. The end of one development activity is sometimes perceived as being
linked to the beginning of a new development activity thus producing a cycle of
beginning-middle-end, link, beginning-middle-end, link, and so forth. This view
of software development is referred to as the software development life cycle.
There are many variations of the software development life cycle. Figure 1
presents a simple life cycle that was common during the first few decades of
software development. In those early days of software development, the
programmer would create programs by iterating from code to fix then back to
code, and then to fix again, until something acceptable was (hopefully) produced.
At the start of the cycle, there was usually no clear concept of what was required,
and the basic development procedure was a form of 'let's see what we can do'
approach.
The software development method represented by the development cycle in Fig.1
is often referred to as the code and fix method (for obvious reasons). Software
development methodologies have come a long way since the days of code and fix,
though it is surprising how much software is still being developed this way.
Successful management of any project, especially software projects, requires
planning, and planning is impossible with code and fix, which is totally
unpredictable. Management of software development within an engineering
Software Project Management (CS615)
18
© Copyright Virtual University of Pakistan
discipline is based on a much more orderly set of development phases. These
phases are not implemented solely by programmers; they require software
engineers. In fact, programming has become a relatively small part of the modern
software development cycle, as is evident from Table 1.
The numbers in Table 1 are derived from the general shift in emphasis to software
planning (requirements and design) and testing. Commercial data processing
systems, with some exceptions, still spend a significant amount of development
time in the programming and unit testing phase. Real-time systems are often more
complex, and may include extensive hardware software integration. This usually
requires more planning and more integration and testing.
Figure 1: the code and fix method
Table 1 Estimated percentage of time spent in each major software development phase
Planning Code and unit test Integration and test
Commercial data processing 25% 40% 35%
Real-time systems 35% 25% 40%
Military systems 40% 20% 40%
Military systems require high reliability and are usually closely supervised by the
customer, leading to a significant increase in the time spent in planning.
The data in Table 1, of course, represents a generalization; commercial data
processing systems can be just as complex as a real-time system.
Figure 2 presents the basic phased model of a software development cycle. This
model, called the Waterfall model, gets its name from the way in which each
phase cascades into the next (due to overlapping), as demonstrated in Fig. 3.
Some interpretations of the Waterfall model, like the one that follows, combine
the top level design and the detailed design phases into a single design phase, and
the integration and test phases into a single phase. In fact, there are many
variations of the classic Waterfall model, but they are all based upon a systematic
transition from one development phase to the next, until the project is complete.
Concept Code Fix Test
Maintain
Software Project Management (CS615)
19
© Copyright Virtual University of Pakistan
Conception
Maintenance Software
Requirements
Test
Top level
Design
Integration Detailed
Design
Implementation
Figure 2: The phased model of the software development life cycle
Conception
Software requirements
Top level" design
Detailed design
Implementation
Integration
Test
Maintenance
T
Figure 3: The Waterfall model of the software development life cycle
⇒ Rapid prototyping There are other development methodologies that do not move
from one phase to the next like the Waterfall model. Rapid prototyping, for
Software Project Management (CS615)
20
© Copyright Virtual University of Pakistan
instance, iterates in a mini-development phase until a system prototype is
developed (see Fig. 4). After the prototype is complete, the Waterfall approach
can then be implemented to complete the full system. Rapid prototyping is
particularly helpful in projects where the requirements are difficult to specify. The
prototype can be used as a tool for analyzing and determining what the
requirements should be.
⇒ The Spiral model, described by Boehm (1988), is another development method
that iterates between the requirements, design and implementation phases.
However, the Spiral model continues iterating until the final system is complete.
Within each, iteration, the Spiral model follows a phased approach similar to the
Waterfall model.
Different models maybe suitable for different software projects or for different
software development organizations However, a good model must include certain
fundamental features. Some of these basic requirements are discussed in IEEE
Standard (IEEE 1993) Standard for Software Life Cycle Processes. This standard
describes the processes that are mandatory for the development of software and
specifies the activities that must be included in the life cycle model.
Most modern software development models, and certainly those following IEEE
Standard 1074, include some form of the basic phased model. It is therefore
important to understand the different phases and how they relate to one another.
Concept Prototype Requirements Design Implementation Test
The rapid prototyping cycle
Figure 4: Rapid prototyping followed by the phase method.
Software Project Management (CS615)
21
© Copyright Virtual University of Pakistan
LECTURE # 4
1. Introduction & Fundamentals
1.11 Costs and Cost Management
Project Cost Management includes the processes required to ensure that the
project is completed within the approved budget.
⇒ Resource Planning—determining what resources (people, equipment,
materials and what quantities of each should be used to perform project
activities.
⇒ Cost Estimating—developing an approximation (estimate) of the costs of
the resources needed to complete project activities.
⇒ Cost Budgeting—allocating the overall cost estimate to individual work
activities.
⇒ Cost Control—controlling changes to the project budget.
These processes interact with each other and with the processes in the other
knowledge areas as well.
Each process may involve effort from one or more individuals or groups of
individuals, based on the needs of the project.
Each process generally occurs at least once in every project phase.
Although the processes are presented here as discrete elements with well-defined
interfaces, in practice they may overlap and interact in ways not detailed here.
Project cost management is primarily concerned with the cost of the resources
needed to complete project activities.
However, project cost management should also consider the effect of project
decisions on the cost of using the project’s product.
For example, limiting the number of design reviews may reduce the cost of the
project at the expense of an increase in the customer’s operating costs. This
broader view of project cost management is often called life-cycle costing. Lifecycle
costing together with Value Engineering techniques are used to reduce cost
and time, improve quality and performance, and optimize the decision-making.
In many application areas, predicting and analyzing the prospective financial
performance of the project’s product is done outside the project.
Software Project Management (CS615)
22
© Copyright Virtual University of Pakistan
In others (e.g., capital facilities projects), project cost management also includes
this work. When such predictions and analyses are included, project cost
management will include additional processes and numerous general management
techniques such as return on investment, discounted cash flow, payback analysis,
and others.
Project cost management should consider the information needs of the project
stakeholders—different stakeholders may measure project costs in different ways
and at different times. For example, the cost of a procurement item may be
measured when committed, ordered, delivered, incurred, or recorded for
accounting purposes.
1.12 Project vs. Program Management
⇒ What is a Program?
“A coordinated portfolio of projects that change organizations to achieve benefits
of strategic importance”
Program management is the process of managing multiple on
going projects. An example would be that of designing, manufacturing and
providing support infrastructure for an automobile make.
It can be argued that Program Management has evolved from the complexities of
the more intricate aspects of Project Management.
As projects became larger; more interrelated; complex and multidimensional, the
need arose to have an approach that controlled Project Management whilst
remaining focused on the strategic objectives of the business. Whilst Project
Management focused on technical delivery, Program Management engaged on
relating design concepts to the business strategic vision of the future.
It is very important that you understand the concept of Program Management as a
method. Approaches may vary but definitions are relatively common. It is
appropriate to understand the ‘mission, goals and objectives’ of Program
Management and then relate these to the Program you propose to develop.
Definitions will fall within each of these headings and it is possible to develop
your own template which fits your organizational program. For example:
– Mission:
To co-ordinate a portfolio of projects to harmonize communications in
order to achieve a set of stated business objectives: Provision of strategy
alignment, with design objectives, in order to maintain control over a
Software Project Management (CS615)
23
© Copyright Virtual University of Pakistan
multiple project environment; ensuring quality end deliverables which
meet business operational needs.
The above is a fairly complex mission statement but provides a framework
to develop an intricate set of goals in order to utilize Program
Management. It is possible to develop an extensive list of goals,
depending upon the level of detail you wish to acquire. The following are
offered as suggestions:
– Goals:
1. Clearly defined roles and responsibilities
2. Established baselines and Terms of Reference statement
3. Type of program defined
4. Future business blueprint
5. Recognition of business transformation procedures
6. Defined structure of the Program
7. Route Map
8. Visible end deliverables — vision of the future
9. Identification of future benefits
10. Risk
11. Contingency planning
Software Project Management (CS615)
24
© Copyright Virtual University of Pakistan
Each of the goals would then be analyzed for providing objectives. For example:
• Managing a program embraces functions, risks and strategies outside of what a
project manager does.
• A program has goals beyond those of a project or group of projects. Program
outcomes are usually service delivery focused whereas a project is more likely
to be focused on the delivery of a 'product'.
• A program is more than a grouping of projects (that's just a program of works).
• The coordinated management of a portfolio of projects to achieve a set of
business objectives
• There are many more meanings of the term program management. Here are the
more common meanings:
– The Multi-Project Organization:
Program Management is the directing of a portfolio of projects that benefit
from a consolidated approach.
Jobbing engineering companies; software houses contracting for work; and
many other types of organization; run many simultaneous projects each of
which may or not contribute towards the corporate goals.
Typically the result of such a project is a deliverable which is eventually
delivered to a client for payment. After many delays the payment arrives and
Software Project Management (CS615)
25
© Copyright Virtual University of Pakistan
gets paid into the company’s bank account thereby increasing cash flow which
is achieving one of the company’s objectives.
Sometimes the projects are much more directly aimed at corporate goals -
opening a new factory or launching a new product - spring to mind.
The common elements of the projects are that they run simultaneously or at
least overlap with each other, they share resources and are supposed to
generate some income. One project being cancelled does not necessarily
change the organization’s general direction. These types of programs run for
ever and need have no end date. The projects are separate in that there need
not be logical links between projects. Whilst they share the same resources,
delays in one project need not cause delays in others.
– The Mega Project
The management of a portfolio of projects towards one specific objective;
Program management can also mean one very large project.
The USA’s Man on the Moon Project was such a program. In this sense the
term program indicates one very large project which is made up from a
number of components. Within the Apollo program there were many projects:
the Lunar Lander, the Orbiter, the Launcher and the Control Systems were all
projects which were large, complex and interesting. Polaris and the
Manhattan project (which resulted in the nuclear bomb) are other famous
projects large enough to be called programs. Therefore, particularly in USA,
the word program refers to a series of projects which make up one large
project.
The program is usually reflected in the management structure as there will be
a program manager to whom the project managers will report. Said program
manager or sometimes program director will concern himself with recruiting
and maintaining his project management teams and on integrating the
deliverables of each project into one overall program. In this meaning of
program management there is likely to be one physical deliverable.
These sorts of programs end. There will be a time when the overall objective
has been achieved and the program and all of its constituent projects are over.
The projects within this type of program are often linked. Delays with one
project often cause knock on effects with others due to logical links between
tasks in both projects.
For example if the moon rocket launch pad project was delayed, it would
delay the testing of the moon rocket itself. The Beirut Shopping Mall will be
of little use without the water treatment plant and the new sewer scheme. Such
Software Project Management (CS615)
26
© Copyright Virtual University of Pakistan
projects may not share the same resources but there are almost certain to be
linked through their logic.
1.13 Project Success
Project success is correlated with thorough analyses of the need for project
deliverables. Our research has shown that when a project results in deliverables
that are designed to meet a thoroughly documented need, then there is a greater
likelihood of project success. So managers should insist that there is a
documented business need for the project before they agree to consume
organizational resources in completing it.
We conduct planned and controlled software projects for one primary reason - it
is the only known way to manage complexity. And yet, we still struggle. In 1998,
industry data indicated that 26 percent of software projects failed outright and 46
percent experienced cost and schedule overruns [REE99].
Although the success rate for software projects has improved somewhat, our
project failure rate remains higher than it should be.
In order to avoid project failure, a software project manager and the software
engineers who build the product must avoid a set of common warning signs,
understand the critical success factors that lead to good project management, and
develop a common sense approach for planning, monitoring and controlling the
project.
In order to manage a successful software project, we must understand what can go
wrong (so that problems can be avoided) and how to do it right. In an excellent
paper on software projects, John Reel [REE99] defines ten signs that indicate that
an information systems project is in jeopardy:
1. Software people don't understand their customer's needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs change (or are ill-defined)
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost [or was never properly obtained).
9. The project team lacks people with appropriate skills.
10. Managers [and practitioners) avoid best practices and lessons learned.
Jaded industry professionals often refer to the 90-90 rule when discussing
particularly difficult software projects: The first 90 percent of a system absorbs 90
percent of the allotted effort and time. The last 10 percent takes the other 90
Software Project Management (CS615)
27
© Copyright Virtual University of Pakistan
percent of the allotted effort and time [ZAH94]. The seeds that lead to the 90-90
rule are contained in the signs noted in the preceding list.
But enough negativity! How does a manager act to avoid the problems just noted?
Reel [REE99] suggests a five-part commonsense approach to software projects:
1. Start on the right foot. This is accomplished by working hard (very hard)
to understand the problem that is to be solved and then setting realistic
objects and expectations for everyone who will be involved in the project.
It is reinforced by building the right team (Section 3.2.3) and giving the
team the autonomy, authority, and technology needed to do the job.
2. Maintain momentum. Many projects get off to a good start and then
slowly disintegrate. To maintain momentum, the project manager must
provide incentives to keep turnover of personnel to an absolute minimum,
the team should emphasize quality in every task it performs, and senior
management should do everything possible to stay out of (the team's way.
3. Track progress. For a software project, progress is tracked as work
products (e.g., specifications, source code, sets of test cases) are produced
and approved (using formal technical reviews) as part of a quality
assurance activation, software process and project measures can be
collected and used to assess progress against averages developed for the
software development organization.
4. Make smart decisions. In essence, the decisions of the project manager
and the software team should be to "keep it simple.” Whenever possible,
decide to use commercial off-the-shelf software or existing software
components, decide to avoid custom interfaces when standard approaches
are available, decide to identify and then avoid obvious risks, and decide
to allocate more time than you think is needed to complex or risky tasks
(you'll need every minute).
5. Conduct a postmortem analysis. Establish a consistent mechanism for
extracting lessons learned for each project. Evaluate the planned and
actual schedules, collect and analyze software project metrics, get
feedback from team members and customers, and record findings in
written form.
– Projects and Strategy
Projects are a means of organizing activities that cannot be addressed
within the organization’s normal operational limits.
Projects are therefore often utilized as a means of achieving an
organization’s strategic plan, whether the project team is employed by the
organization or is a contracted service provider.
Projects are typically authorized as a result of one or more of the
following strategic considerations:
Software Project Management (CS615)
28
© Copyright Virtual University of Pakistan
A market demand (e.g., an oil company authorizes a project to build a
new refinery in response to chronic gasoline shortages)
A business need (e.g., a training company authorizes a project to create a
new course in order to increase its revenues)
A customer request (e.g., an electric utility authorizes a project to build a
new substation to serve a new industrial park)
A technological advance (e.g., an electronics firm authorizes a new
project to develop a new generation of video game player after the
introduction of the corresponding new game format)
A legal requirement (e.g., a paint manufacturer authorizes a project to
establish guidelines for the handling of a new toxic material).
No project ever goes 100% as planned, so project managers must learn to adapt to
change. There are many things that can go wrong with project management.
These are commonly called barriers. Here are some possible barriers:
1. Poor Communication
– Many times a project may fail because the project team does not
know exactly what to get done or what's already been done.
2. Disagreement
– Project must meet all elements in a contract.
– Customer and project manager must agree on numerous
elements.
– Failure to comply with standards and regulations.
– Inclement weather.
– Union strikes.
– Personality conflicts.
– Poor management
3. Poorly defined project goals
1.14 Trade-Off Triangle
Good project management deals with three factors: time, cost and
performance.
Projects are successful if they are completed on time, within budget, and to
performance requirements. In order to bring the many components of a large
project into control there is a large toolkit of techniques, methodologies, and
tools.
Software Project Management (CS615)
29
© Copyright Virtual University of Pakistan
These techniques provide the tools for managing different components
involved in a project: planning and scheduling, developing a product;
managing financial and capital resources, and monitoring progress. However
the success of a project will always rest on the abilities of a project manager
and the team members.
In managing competing project requirements Project managers often talk of a
triple constraint:
– Project scope
– Time and
– Cost
Project quality is affected by balancing these three factors.
High quality projects deliver the required product or service within scope, on
time and within budget.
The relationship among these factors is such that if any one of the three
factors changes, at least one other factor must change.
Simply put: project success means completing all project deliverables on time,
within budget, and to a level of quality that is acceptable to sponsors and
stakeholders.
The project manager must keep the team's attention focused on achieving
these broad goals. Most people still want their projects to be on time, meet
quality objectives, and not cost more than the budget. These form the classic
time, quality, cost triangle.
In fact if you have an unlimited budget and unlimited time, project
management becomes rather easy. For most people, however, time and money
are critical and that is what makes project management so important today.
Project management is often summarized in a triangle. The three most
important factors are time, cost and scope. These form the vertices with
quality as a central theme.
Software Project Management (CS615)
30
© Copyright Virtual University of Pakistan
1. Projects must be delivered on time.
2. Projects must be within cost
3. Projects must be within scope
4. Projects must meet customer quality requirements
More recently, this has given way to a project management diamond, with
time, cost, scope and quality the four vertices and customer expectations as a
central theme. No two customers' expectations are the same so you must ask
what their expectations are.
A project goes through four phases during its life:
1. Project Definition: Defining the goals, objectives and critical success
factors for the project
2. Project Initiation: Everything that is needed to set-up the project before
work can start
3. Project Control: Ensuring that a project stays on track and taking
appropriate action to ensure it does
4. Project Closure: Disbanding of all the elements that were required to run
the project
Software Project Management (CS615)
31
© Copyright Virtual University of Pakistan
1.15 Project Management Skills
The role of the Leader in project management is one of great responsibility.
It's the project manager's job to direct and supervise the project from
beginning to end. Here are some other roles:
(a) Leadership
(b) Communications
(c) Problem Solving
(d) Negotiating
(e) Influencing the Organization
(f) Mentoring
(g) Process and technical expertise
(a) Leadership
Leadership is a complex phenomenon involving the leader, the followers,
and the situation. Perhaps the best way for you to begin to understand the
complexities of leadership is to see some of the ways leadership has been
defined. Leadership researchers have defined leadership in the following
different ways:
The creative and directive force of morale. (Munson, 1921)
The process by which an agent induces a subordinate to behave in a
desired manner. (Bennis, 1959)
The presence of a particular influence relationship between two or
more persons. (Hollander & Julian, 1969)
Directing and coordinating the work of group members. (Fiedler,
1967) An interpersonal relation in which others comply because they
want to, not because they have to. (Merton, 1969; Hogan, Curphy, &
Hogan, 1994)
Transforming followers, creating visions of the goals that may be
attained, and articulating for the followers the ways to attain those
goals. (Bass, 1985; Fichy & Devanna, 1986)
The process of influencing an organized group toward accomplishing
its goals. (Roach & Behling, 1984)
Actions that focus resources to create desirable opportunities.
(Campbell, 1991)
Software Project Management (CS615)
32
© Copyright Virtual University of Pakistan
The leader's job is to create conditions for the team to be effective.
(Ginnett, 1996)
Leading and managing are both essential management skills: one
without the other is likely to produce poor results. Managing is primarily
concerned with “consistently producing key results expected by
stakeholders,” while leading involves:
Establishing direction—developing both a vision of the future and
strategies for producing the changes needed to achieve that vision.
Aligning people—communicating the vision by words and deeds to
all those, whose cooperation may be needed to achieve the vision.
Motivating and inspiring—helping people energize themselves to
overcome political, bureaucratic, and resource barriers to change.
On a project, particularly a larger project, the project manager is generally
expected to be the project’s leader as well.
Leadership is not, however, limited to the project manager: it may be
demonstrated by many different individuals at many different times during
the project.
Leadership must be demonstrated at all levels of the project (project
leadership, technical leadership, and team leadership).
(b) Communicating
Communicating involves the exchange of information and the ability to
transmit and receive information with a high probability that the intended
message is passed from sender to receiver.
The sender is responsible for making the information clear, unambiguous,
and complete so that the receiver can receive it correctly. The receiver is
responsible for making sure that the information is received in its entirety
and understood correctly.
Few skills are more vital to leadership. Studies show that good leaders
communicate feelings and ideas, actively solicit new ideas from others,
and effectively articulate arguments, advocate positions, and persuade
others.
The quality of a Leader’s communication is positively correlated with
subordinate satisfaction as well as with productivity and quality of
services rendered.
Software Project Management (CS615)
33
© Copyright Virtual University of Pakistan
Effective communication skills are also important because they provide
leaders and followers with greater access to information relevant to
important organizational decisions.
Communicating has many dimensions:
– Written and oral, listening and speaking
– Internal (within the project) and external (to the customer, the
media, the public, etc.).
– Formal (reports, briefings, etc.) and informal (memos, ad hoc
conversations, etc.)
– Vertical (up and down the organization) and horizontal (with peers
and partner organization)
The general management skill of communicating is related to, but not the
same as, Project Communications Management.
Communicating is the broader subject and involves a substantial body of
knowledge that is not unique to the project context, for example:
– Sender-receiver models—feedback loops, barriers to
communications, etc.
– Choice of media—when to communicate in writing, when to
communicate orally, when to write an informal memo, when to
write a formal report, etc.
– Writing style—active versus passive voice, sentence structure,
word choice, etc.
– Presentation techniques—body language, design of visual aids,
etc.
– Meeting management techniques—preparing an agenda, dealing
with conflict, etc.
Project Communications Management is the application of these broad
concepts to the specific needs of a project—for example, deciding how;
when; in what form; and to whom to report project performance.
(c) Negotiating
Negotiating involves conferring with others to come to terms with them or
reach an agreement.
Agreements may be negotiated directly or with assistance; mediation and
arbitration are two types of assisted negotiation.
Negotiation is an approach that may help resolve some conflicts. Some
important tips on negotiation include; preparing for a negotiation session;
Software Project Management (CS615)
34
© Copyright Virtual University of Pakistan
keeping people and problems separate; focusing on issues, not positions
and seeking win-win outcomes.
Negotiations occur around many issues, at many times, and at many levels
of the project.
During the course of a typical project, project staff is likely to negotiate
for any or all of the following:
• Scope, cost, and schedule objectives.
• Changes to scope, cost, or schedule.
• Contract terms and conditions.
• Assignments.
• Resources.
(d) Problem Solving
There are three steps involved in this important leadership role; identifying
problem; analyzing its cause; and solving the problem.
Problem solving involves a combination of problem definition and
decision-making.
Problem definition requires distinguishing between causes and symptoms.
Problems may be:
– Internal (a key employee is reassigned to another project)
– External (a permit required to begin work is delayed).
– Technical (differences of opinion about the best way to design a
product)
– Managerial (a functional group is not producing according to
plan) or
– Interpersonal (personality or style clashes).
(e) Decision-making
Decision-making includes analyzing the problem to identify viable
solutions, and then making a choice from among them.
Decisions can be made or obtained (from the customer, from the team, or
from a functional manager).
Once made, decisions must be implemented.
Decisions also have a time element to them—the “right” decision may not
be the “best” decision if it is made too early or too late.
Software Project Management (CS615)
35
© Copyright Virtual University of Pakistan
(f) Influencing the Organization
Influencing the organization involves the ability to “get things done.”
It requires an understanding of both the formal and informal structures of
all the organizations involved—the performing organization, customer,
partners, contractors, and numerous others, as appropriate.
Influencing the organization also requires an understanding of the
mechanics of power and politics.
Both power and politics are used here in their positive senses.
Power is “the potential ability to influence behavior, to change the course
of events, to overcome resistance, and to get people to do things that they
would not otherwise do.”
In similar fashion, “politics is about getting collective action from a group
of people who may have quite different interests. It is about being willing
to use conflict and disorder creatively.
The negative sense, of course, derives from the fact that attempts to
reconcile these interests result in power struggles and organizational
games that can sometimes take on a thoroughly unproductive life of their
own.”
Influence can be exercised in a: variety of ways. It may be the 'bridge to
engine room' approach, where the leader commands and controls. Or the
influence can be exercised by guiding and facilitating the group's behavior
so that the goal is accomplished.
Finally, leadership implies that a leader motivates the group to spend
energy in attaining the goals of the group.
Influence without change or movement isn’t influence. Leaders make
change happen, a difficult but vitally important task.
(g) Mentoring
Mentoring or being a Transformational leadership is more concerned with
engagement between leaders and followers.
Leaders attempt to engage the full person of the subordinate and enthuse
them. They arouse in their subordinates a heightened awareness of the key
issues for the group or the organization. They seek to concern subordinates
with achievement, growth and development.
Software Project Management (CS615)
36
© Copyright Virtual University of Pakistan
Creating a new vision is something that almost all writers on
transformational leadership emphasize.
The vision points the way to a new state of affairs. It is an appealing
picture of a more desirable future. It inspires people to believe that the
future is worth the upheaval of undoing the present.
A vision needs to be a source of self-esteem and a common purpose for
members of the organization.
(h) Technical Skills:
A project manager must have technical skills. This relates to financial
planning, contract management, and managing creative thinking and
problem solving techniques are promoted.
Software Project Management (CS615)
37
© Copyright Virtual University of Pakistan
LECTURE # 5
1. Introduction & Fundamentals
1.16 PM’s nine Knowledge Areas
1. Project Integration Management
Project Integration Management includes the processes required to ensure that the
various elements of the project are properly coordinated. It involves making
tradeoffs among competing objectives and alternatives to meet or exceed stakeholder
needs.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
Project integration management comes into play when a cost estimate is needed
for a contingency plan, or when risks associated with various staffing alternatives
must be identified. However, for a project to be completed successfully,
integration must also occur in a number of other areas as well. For example:
The work of the project must be integrated with the ongoing operations of the
performing organization.
Product scope and project scope must be integrated.
One of the techniques used to both integrate the various processes and to measure
the performance of the project as it moves from initiation through to completion is
Earned Value Management (EVM).
• Earned value is the amount of work completed, measured according to the
budgeted effort that the work was supposed to consume.
• It is also called the budgeted cost of work performed.
• As each task is completed, the number of person-months originally planned
for that task is added to the earned value of the project.
– Earned value charts: An earned value chart has three curves:
• The budgeted cost of the work scheduled.
• The earned value.
• The actual cost of the work performed so far.
2. Project Scope Management
Software Project Management (CS615)
38
© Copyright Virtual University of Pakistan
Project Scope Management includes the processes required to ensure that the
project includes all the work required, and only the work required, to complete the
project successfully. It is primarily concerned with defining and controlling what
is or is not included in the project.
The processes, tools, and techniques used to manage product scope vary by
application area and are usually defined as part of the project life cycle
A project generally results in a single product, but that product may include
subsidiary components, each with its own separate but interdependent product
scopes. For example, a new telephone system would generally include four
subsidiary components—hardware, software, training, and implementation.
Completion of the project scope is measured against the project plan, but
completion of the product scope is measured against the product requirements.
Both types of scope management must be well integrated to ensure that the work
of the project will result in delivery of the specified product.
3. Project Time Management
Project Time Management includes the processes required to ensure timely
completion of the project. The followings are major processes in developing the
project time schedule:
(a) Activity Definition—identifying the specific activities that must be
performed to produce the various project deliverables.
(b) Activity Sequencing—identifying and documenting interactivity
dependencies.
(c) Activity Duration Estimating—estimating the number of work periods that
will be needed to complete individual activities.
(d) Schedule Development—analyzing activity sequences, activity durations,
and resource requirements to create the project schedule.
(e) Schedule Control—controlling changes to the project schedule.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
4. Project Cost Management
Software Project Management (CS615)
39
© Copyright Virtual University of Pakistan
Project Cost Management includes the processes required to ensure that the
project is completed within the approved budget.
Resource Planning—determining what resources (people, equipment, materials)
and what quantities of each should be used to perform project activities.
Cost Estimating—developing an approximation (estimate) of the costs of the
resources needed to complete project activities.
Cost Budgeting—allocating the overall cost estimate to individual work
activities.
Cost Control—controlling changes to the project budget.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
5. Project Quality Management
Project Quality Management includes the processes required to ensure that the
project will satisfy the needs for which it was undertaken. It includes “all
activities of the overall management function that determine the quality policy,
objectives, and responsibilities and implements them by means such as quality
planning, quality assurance, quality control, and quality improvement, within the
quality system.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
Project quality management must address both the management of the project and
the product of the project. The generic term product is occasionally used, in
literature regarding quality, to refer to both goods and services.
6. Project Human Resource Management
Project Human Resource Management includes the processes required to make
the most effective use of the people involved with the project. It includes all the
project stakeholders—sponsors, customers, partners, and individual contributors
Following are some major processes:
Software Project Management (CS615)
40
© Copyright Virtual University of Pakistan
Organizational Planning—identifying, documenting, and assigning project
roles, responsibilities, and reporting relationships.
Staff Acquisition—getting the human resources needed assigned to and
working on the project.
Team Development—developing individual and group competencies to
enhance project performance.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project.
There is a substantial body of literature about dealing with people in an
operational, ongoing context. Some of the many topics include:
Leading, communicating, negotiating, etc.
Key General Management Skills:
Delegating, motivating, coaching, mentoring, and other subjects related to
dealing with individuals.
Team building, dealing with conflict, and other subjects related to dealing
with groups.
Performance appraisal, recruitment, retention, labor relations, health and
safety regulations, and other subjects related to administering the human
resource function.
Most of this material is directly applicable to leading and managing people on
projects, and the project manager and project management team should be
familiar with it. However, they must also be sensitive as to how this knowledge is
applied on the project. For example:
Project Human Resource Management includes the processes required to make
the most effective use of the people involved with the project. It includes all the
project stakeholders—sponsors, customers, partners, and individual contributors.
Major processes include:
Organizational Planning—identifying, documenting, and assigning project
roles, responsibilities, and reporting relationships.
Staff Acquisition—getting the human resources needed assigned to and
working on the project.
Team Development—developing individual and group competencies to
enhance project performance.
Software Project Management (CS615)
41
© Copyright Virtual University of Pakistan
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project.
7. Project Communications Management
Project Communications Management includes the processes required to ensure
timely and appropriate generation, collection, dissemination, storage, and ultimate
disposition of project information. It provides the critical links among people,
ideas, and information that are necessary for success. Everyone involved in the
project must be prepared to send and receive communications, and must
understand how the communications in which they are involved as individuals
affect the project as a whole.
Major processes include:
Communications Planning—determining the information and
communications needs of the stakeholders: who needs what information,
when they will need it, and how it will be given to them.
Information Distribution—making needed information available to project
stakeholders in a timely manner.
Performance Reporting—collecting and disseminating performance
information. This includes status reporting, progress measurement, and
forecasting.
Administrative Closure—generating, gathering, and disseminating
information to formalize a phase or project completion.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
Communicating is a broader subject and involves a substantial body of knowledge
that is not unique to the project context. For example:
Sender-receiver models—feedback loops, barriers to communications, etc.
Choice of media—when to communicate in writing versus when to
communicate orally, when to write an informal memo versus when to write a
formal report, etc.
Writing style—active versus passive voice, sentence structure, word choice,
etc.
Presentation techniques—body language, design of visual aids, etc.
Meeting management techniques—preparing an agenda, dealing with
conflict, etc.
Software Project Management (CS615)
42
© Copyright Virtual University of Pakistan
8. Project Risk management
Project Risk management is the systematic process of identifying, analyzing, and
responding to project risk. It includes maximizing the probability and
consequences of positive events and minimizing the probability and consequences
of adverse events to project objectives.
Risk Management Planning—deciding how to approach and plan the risk
management activities for a project.
Risk Identification—determining which risks might affect the project and
documenting their characteristics.
Qualitative Risk Analysis—performing a qualitative analysis of risks and
conditions to prioritize their effects on project objectives.
Quantitative Risk Analysis—measuring the probability and consequences of
risks and estimating their implications for project objectives.
Risk Response Planning—developing procedures and techniques to enhance
opportunities and reduce threats to the project’s objectives.
Risk Monitoring and Control—monitoring residual risks, identifying new
risks, executing risk reduction plans, and evaluating their effectiveness
throughout the project life cycle.
These processes interact with each other and with the processes in the other
knowledge areas. Each process generally occurs at least once in every project.
9. Project Procurement Management
Project Procurement Management includes the processes required to acquire
goods and services, to attain project scope, from outside the performing
organization. For simplicity, goods and services, whether one or many, will
generally be referred to as a product.
An overview of the major processes includes:
Procurement Planning—determining what to procure and when.
Solicitation Planning—documenting product requirements and identifying
potential sources.
Solicitation—obtaining quotations, bids, offers, or proposals, as appropriate.
Source Selection—choosing from among potential sellers.
Contract Administration—managing the relationship with the seller.
Contract Closeout—completion and settlement of the contract, including
resolution of any open items.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project
Software Project Management (CS615)
43
© Copyright Virtual University of Pakistan
Project Procurement Management is discussed from the perspective of the buyer
in the buyer-seller relationship. The buyer-seller relationship can exist at many
levels on one project. Depending on the application area, the seller may be called
a subcontractor, a vendor, or a supplier.
The seller will typically manage its work as a project. In such cases:
The buyer becomes the customer, and is thus a key stakeholder for the seller.
The seller’s project management team must be concerned with all the
processes of project management, not just with those of this knowledge area.
The terms and conditions of the contract become a key input to many of the
seller’s processes. The contract may actually contain the input (e.g., major
deliverables, key milestones, cost objectives), or it may limit the project
team’s options (e.g., buyer approval of staffing decisions is often required on
design projects).
Software Project Management (CS615)
44
© Copyright Virtual University of Pakistan
LECTURE # 6
1. Introduction & Fundamentals
1.17 Team leader
Most definitions of leadership involve three components: influence group and
goal. First, leaders are individuals who influence the behavior of others. These
others are usually referred to as sub ordinates or followers. Second, leadership is
usually examined in the context of a group, especially work groups such as
managers and their teams or foremen and their subordinates. Third, research on
leadership stresses a group goal that has to be accomplished. So a definition is:
Leadership is the process in which an individual influences the group
members towards the attainment of group or organization goals.
Note that the influence can be exercised in a: variety of ways. It may be the
'bridge to engine room' approach, where the leader commands and controls. Or
the influence can be exercised by guiding and facilitating the group's behavior so
that the goal is accomplished. The notion of reciprocity is also part of man
definitions. Influencing is often two ways. Leaders may influence followers, but
followers influence leaders to lead in one way rather than another. An influencing
style appropriate for checkout assistant in a supermarket may be different from
that appropriate for rock scientists. The choice is open to the leader of how to
influence is one of the key aspects investigated by leadership researchers.
Another aspect of leadership is that the right to lead is often voluntarily conferred
on the leader by some or all members of the group. A group of friends may
recognize one, of their group as the leader, in the sense that she influences the
group more than any of the other members. There also may be informal leader.
While the nominal head of a department may have the formal leadership position,
the real leadership may be exercised by someone lower down the hierarchy who
influences the group towards goals that may not be those that the organization
whishes to be pursue.
Finally, leadership implies that a leader motivates the group to spend energy
in attaining the goals of the group. Influence without change or movement isn’t
influence. Leaders make change happen, a difficult but vitally important task.
1.18 Leaders and Managers
Although it is common to use the terms 'leader' and 'manager' interchangeably,
nowadays many writers point to a difference between the two.
Software Project Management (CS615)
45
© Copyright Virtual University of Pakistan
The difference is that to function as a leader, a person must exercise influence
over another person in the attainment of organizational goals, as described in the
definition above. Managerial ' functions of organizing, planning, scheduling,
processing information, communicating, and so on, do not necessarily involve
leadership. Some managers perform both types of function and can be described
as leaders, but others do not. There is no automatic link between the two concepts.
Note, too, that leaders are not necessarily just at the top of organizations.
Influence can be exerted in most job functions and at levels of seniority or
hierarchy. The distinction between managers and leaders was, developed by
Bennis and Nanus (1985) in their influential book Leaders. In it they put forward
the view that:
Leadership is path finding
Management is path following
Management is about doing things right
Leadership is about doing the right things
What they meant by this is that leadership is about having a vision. It involves
having a strategy or thinking strategically; it means having a view of where the
organization should go or be or do; it means deciding what is important for the
success of the organization; it involves envisaging the future, A leader's
responsibility is to think what are the key criteria for success of his or her part of
the business and not just now but for the future.
Managers, on the other hand, are more concerned with implementing others
strategies and plans, They are concerned with running their part of the
organization, making sure that the accounts get prepared, that invoices are sent
out, that the service is sold, that the traffic is directed, that the research paper is
written, or whatever the task that needs to be done.
A very similar view is put forward by Kotter (1990). He argues that management
is concerned with activities which are designed to produce 'consistency and order',
whereas leadership is concerned with, 'constructive or adaptive change'. Kotter
says there are four major ways that management and leadership differ:
1. Planning and budgeting versus establishing direction. Management
involves making detailed steps and timetables for achieving results, then
marshalling resources to make it happen. Leadership means developing a
vision of the future and strategies for achieving that vision.
2. Organizing and staffing versus aligning people. Management comprises the
allocation of tasks in line with plans, staffing them appropriately, delegating
responsibility and monitoring implementation. Leadership involves
communicating the vision so that others understand and agree with it.
3. Controlling and problem-solving versus motivating and inspiring.
Management involves monitoring results of a plan, identifying problems with
the plan and then solving them. Leadership involves 'energizing people'
Software Project Management (CS615)
46
© Copyright Virtual University of Pakistan
towards the vision. It means appealing to their needs and values so that they
overcome barriers to change.
4. Outcomes: predictability and order, or change. Management produces
predictability and order so that others, such as customers or shareholders can
rely on consistent results. Leadership produces change that is often a quantum
leap, such as new products or new approaches to managing people, that makes
the organization more competitive.
Kirkpatrick and Locke (1991) suggest that the following traits distinguish
leaders from non-leaders:
• Drive (achievement. ambition, energy, tenacity, initiative);
• Leadership motivation (personalized or socialized); .honesty and
integrity;
• Self-confidence (including emotional stability);
• Cognitive ability (the ability to marshal and interpret a wide variety
of information);
• Knowledge of the business
They point out, though, that there is much more to being an effective leader than
merely possessing a list of traits. While the traits may provide people with the
potential for leadership, it is the capacity to create a vision and implement it that
turns the potential into reality.
Strong leadership motivation may sound an obvious trait for a leader. After all,
only those who want the weighty responsibilities and grueling pressures of
leadership are likely to strive for it. McClelland (1985) distinguishes between two
types of power motivation. On the one hand, leaders may be interested in
personalized power, which describes the motivation of leaders who "seek power
for its own sake, who wish to dominate others and are often concerned with the
status and trappings of power. The late Robert Maxwell, former owner of the
Mirror Group allegedly displayed such traits. On the other hand, leaders who
show socialized power motivation are more interested in cooperating with others
to achieve desired goals. They work with others rather than attempting to
dominate or control them. From the point of view of subordinates and the
organization as a whole, the leader motivated by socialized power is obviously
preferable. On the question of cognitive ability; leaders must be able to gather,
integrate and interpret large amounts of information. Many
Many researchers have pointed out that it is not necessary to be brilliant, though;
leadership effectiveness is helped by above average intelligence, not genius. Of
Kirkpatrick and Locke’s six characteristics, some would argue that drive and
persistence are much more important than intelligence.
In conclusion, the trait approach has undergone a revival. Recent research
suggests that traits do matter. Yet the research shows that there are only a handful
Software Project Management (CS615)
47
© Copyright Virtual University of Pakistan
of traits which distinguish leaders from others, and a clear distinction between
effective and ineffective leaders has not yet emerged.
In an excellent book of technical leadership, Jerry Weinberg suggests a MOI
model of leadership:
Motivation: The ability to encourage (by "push or pull") technical people to
produce to their best ability.
Organization: The ability to mold existing processes (or invent new ones) that
will enable the initial concept to be translated into a final product.
Ideas or innovation: The ability to encourage people to create and feel creative
even when they must work within bounds established for a particular soft- ware
product or application.
Weinberg suggests that successful project leaders apply a problem solving
management style. That is, a software project manager should concentrate on
understanding the problem to be solved, managing the flow of ideas, and at the
same time, letting everyone on the team know (by words and, far more important,
by actions) that quality counts and that it will not be compromised.
Another view [EDG95] of the characteristics that define an effective project
manager emphasizes four key traits:
Problem solving An effective software project manager can diagnose the
technical and organizational issues that are most relevant, systematically structure
a solution or properly motivate other practitioners to develop the solution, apply
lessons learned from past projects to new situations, and remain flexible enough
to change direction if initial attempts at problem solution are fruitless.
Managerial identity
A good project manager must take charge of the project. She must have the
confidence to assume control when necessary and the assurance to allow good
technical people to follow their instincts.
Achievement
To optimize the productivity of a project team, a manager must reward initiative
and accomplishment and demonstrate through his own actions that controlled risk
taking will not be punished.
Influence and team building
An effective project manager must be able to "read" people; she must be able to
understand verbal and nonverbal signals and react to the needs of the people
sending these signals. The manager must remain under control in high-stress
situations.
Software Project Management (CS615)
48
© Copyright Virtual University of Pakistan
1.19 Project Organization
People are managed through an organizational structure. This hierarchical
structure is based on the four cornerstones of management: delegation,
authority, responsibility and supervision (see Fig.1). Delegation bestows
authority, and authority produces (and requires) responsibility. Both
authority and responsibility require supervision, and effective supervision
requires a suitable organizational structure:
Most projects are organized as teams, with each team assigned specific
functions within the project, Different types of project require different
types of team structure, as for example a team of junior programmers
requires a technical team leader while a team of experts may require only
an administrative team leader. It is the project manager's responsibility to
select the structure best suited for the project.
Basically an organization is a group of people intentionally organized to
accomplish an overall, common goal or set of goals. Business
organizations can range in size from two people to tens of thousands.
Figure 1: The four cornerstones of management
There are many ways to organize a software project. The larger the project
the more critical the organizational structure becomes. Badly organized
projects breed confusion, and confusion leads to project failure. Figure 2
describes the basic structure of a project in which below the project
manager are just two general functions: development and support. This
very basic software project structure was not uncommon in the 1950s and
1960s. It is still a valid project structure for very small projects (up to five
developers), though occasionally it can still be found today in larger
projects.
Delegation
1
Supervision
2
Authority
3
Responsibility
4
Software Project Management (CS615)
49
© Copyright Virtual University of Pakistan
Figure 2: Basic structure of a development project
Figure 3: Software project organizational chart
Project
Project
development
Project
support
Project
manager
Deputy
project
manager
System
engineer
Independent
test group
Secretary
Quality
assurance
Configuration
control
Development
team 1
Development
team 2
Development
team 3
Software Project Management (CS615)
50
© Copyright Virtual University of Pakistan
Project
manager
Deputy project
manager
Integration
Group
Independent
Group
Secretary
Quality
assurance
Configuration
control
SW sub-project
Manager 1
SW sub-project
Manager 2
SW sub-project
Manager 3
Team 1
Team 2
Team 3
Team 1
Team 2
Team 1
Team 2
Team 3
Figure 4: Large hardware/software project organizational chart
Project managers are just two general functions: development and support. This very
basic software project structure was not uncommon in the 1950s and 1960s. It is a project
structure for very small projects (up to five developers). Though occasionally, it can still
be found today in larger projects.
Figure 3 describes a detailed organizational chart including all major support functions.
This organizational structure is suitable for large projects (with a staff exceeding 20).
Smaller projects may not require a deputy project manager or separate configuration
control and quality assurance groups.
Very large projects (exceeding a staff of 40) can often be managed more easily by
dividing the project into sub-projects. Figure 4 presents the organizational chart for a
large project. This chart includes both software and hardware development teams, and an
integration group that is responsible for hardware/software integration as well as
integration within each group.
As an example, consider the organization of a large satellite project. The project manager
is in fact responsible for a number of projects: the ground control station, the rocket and
the satellite itself. The software for all of these sub-projects is managed within a single
project office. Each sub-project is then managed by a sub-project manager. An
organizational chart similar to the one described in Fig. 4 can be applied to the satellite
project; the resulting chart is described in Fig. 5.
Software Project Management (CS615)
51
© Copyright Virtual University of Pakistan
Satellite
PM
Sub-project
Coordinator
Scientific
Engineer
Integration
Team
Secretary
Quality assurance Ground control
Station sub-project
Rocket
Development
Sub-project
Satellite
Sub-project
Team 1
Team 2
Team 3
Team
1
Team
2
Team
1
Team
2
Team
3
Quality
Assurance
Independent
Group
Configuration
Control
Figure 5: Satellite project organizational chart
Clearly the project's organizational structure is dependent on the type of project being
developed. Some of the issues that must be considered are:
– Project size: the larger the project, the more important the organization. Large
projects have significant human communications and coordination overhead, and
therefore require more support functions.
– Hardware/software development projects. The simultaneous development of
hardware and software is not easy. Planning, integration and testing are much
more complicated, and require dedicated support groups.
– High reliability systems. Any system that is sensitive to issues of reliability (such
as military or life-saving systems) requires a major effort in quality assurance.
Quality is also an important consideration in many marketable software products
(e.g. communications packages). These types of project require a separate quality
assurance organization.
Software Project Management (CS615)
52
© Copyright Virtual University of Pakistan
The Organizational structure
The organization's structure, or design, is the overall arrangement of the
organization's various roles, processes and their relationships in the organization.
The design of an organization is a means to accomplishing the organization's
overall goal -- the structure is not an end in itself. In systems theory terms, the
design ensures that the appropriate inputs go through the necessary processes to
produce the required outputs to produce the intended outcomes.
The structure of the performing organization often constrains the availability of or
terms under which resources become available to the project. Organizational
structures can be characterized as spanning a spectrum from functional to
projectized, with a variety of matrix structures in between.
⇒ Corporate structure: The project's organization is largely dependent on the overall
structure of the company within which the project is being developed. Many of the
project support functions can be provided by centralized groups within the company.
In fact, basic services, such as financial, secretarial and legal services, are commonly
provided by the parent or corporate organization.
Corporate structure usually dictates one of two basic types of project organization:
matrix or pyramid. Figure 5 describes the structure of a matrix organization (compare
this to the pyramid structure in Fig. 4). Within a corporate matrix organization, the
project manager manages the technical activities of the project staff, while his or her
involvement in non-technical personnel issues (e.g. salary reviews, promotion, and
training) is minimal.
⇒ Matrix Structure
Think of the functional structure. Imagine if you took someone from each of the
major functions in the functional structure (the boxes along the bottom of the
organization chart), e.g., people from sales, engineering, etc., and organized them into
a separate group intended to produce and sell one certain kind of product or service.
Members of this group stay together until that product is produced or they continue to
sell and service it. This overall structure (made up of a functional structure that also
has groups assigned to products) is a matrix structure. This structure is useful because
it focuses highly skilled people from across the organization to work on a complex
product or service. It can be difficult though, because each person essentially reports
to two supervisors: the supervisor of the functional area (e.g., engineering) and the
product manager, as well. When the organization needs constant coordination of its
functional activities, then lateral relations do not provide sufficient integration.
Consider the matrix structure. To adopt the matrix structure effectively, the
organization should modify many traditional management practices.
Matrix organizations are a blend of functional and projectized characteristics. Weak
matrices maintain many of the characteristics of a functional organization, and the
Software Project Management (CS615)
53
© Copyright Virtual University of Pakistan
project manager role is more that of a coordinator or expediter than that of a manager.
In similar fashion, strong matrices have many of the characteristics of the projectized
organization—full-time project managers with considerable authority and full-time
project administrative staff.
Most modern organizations involve all these structures at various levels. For example,
even a fundamentally functional organization may create a special project team to
handle a critical project. Such a team may have many of the characteristics of a
project in a projectized organization. The team may include full-time staff from
different functional departments, it may develop its own set of operating procedures,
and it may operate outside the standard, formalized reporting structure.
Matrix Organizations are a blend of functional and projectized characteristics. Weak
matrices maintain many of the characteristics of a functional organization, and the
project manager role is more that of a coordinator or expediter than that of a manager.
In similar fashion, strong matrices have many of the characteristics of the projectized
organization—full-time project managers with considerable authority and full-time
project administrative staff.
Most modern organizations involve all these structures at various levels. For example,
even a fundamentally functional organization may create a special project team to
handle a critical project. Such a team may have many of the characteristics of a
project in a projectized organization. The team may include full-time staff from
different functional departments, it may develop its own set of operating procedures,
and it may operate outside the standard, formalized reporting structure.
• The advantages of a matrix organization are:
– More expertise: a matrix organization can maintain experts in specific fields
(communications, data bases, graphics etc.) who are then assigned to different
projects. A single project cannot always afford the luxury of maintaining
experts in all fields.
– Flexibility: it is easier to move people around from one project to another.
This results in better utilization of the available expertise.
– Emphasis on managing the project: the project manager is freed of many of
the staff management tasks, leaving more time to concentrate on the technical
aspects of the project.
However, matrix organizations also have significant disadvantages:
– Fewer management measures. One of the primary tools for generating
motivation, promotion, is taken out of the hands of the project manager. The
manager has little influence on the developer's salary and professional role in
the organization.
Software Project Management (CS615)
54
© Copyright Virtual University of Pakistan
– Lower staff loyalty. All employees like to know exactly who their superior is.
In a matrix organization, an employee has more than one superior. This causes
a division of loyalty, and a weaker bond between employee and manager.
These disadvantages often outweigh the advantages of the corporate matrix
organization.
Motivation is a major factor in the success of a project, and anything that
undermines motivation is usually contrary to the best interests of the project.
Unfortunately, the best interests of the project do not always completely coincide
with the best interests of the company.
Pyramid organizations provide a clear, well-defined hierarchy in which all
individuals know their own position and the positions of those above and below
them. When promotion and status play a major role in generating motivation (and
they often do), then the pyramid organization is most effective. Many other
factors generate motivation; Sense of achievement, praise and peer esteem, are
just a few.
Though promotion and status are not always the most effective motivators, a
project manager should rarely relinquish any effective management tool.
Therefore, from the perspective of a single project, the pyramid organization is
often the best.
⇒ Functional Structure
Most business organizations start out with a functional structure, or a small
variation of this structure. This is the basic "building block" for other structures.
In this structure, there is a central office which oversees various departments or
major functions, e.g., human resources, finances, sales, marketing, engineering,
etc. Think of a picture that has a box at the top labeled "Central Office". Think of
a row of boxes underneath the top box. Each box is labeled, e.g., sales,
engineering, human resources, etc. Connect the boxes with lines coming down
from the top box to each of the boxes below. Use functional structures when the
organization is small, geographically centralized, and provides few goods and
services. When the organization experiences bottlenecks in decision making and
difficulties in coordination, it has outgrown its functional structure.
The classic functional organization is a hierarchy where each employee has one
clear superior. Staff members are grouped by specialty, such as production,
marketing, engineering, and accounting at the top level, with engineering further
subdivided into functional organizations that support the business of the larger
organization (e.g., mechanical and electrical). Functional organizations still have
projects, but the perceived scope of the project is limited to the boundaries of the
function: the engineering department in a functional organization will do its work
Software Project Management (CS615)
55
© Copyright Virtual University of Pakistan
independent of the manufacturing or marketing departments. For example, when a
new product development is undertaken in a purely functional organization, the
design phase is often called a design project and includes only engineering
department staff. If questions about manufacturing arise, they are passed up the
hierarchy to the department head, who consults with the head of the
manufacturing department. The engineering department head then passes the
answer back down the hierarchy to the engineering project manager.
⇒ Project Structure
In this structure, there is a centralized corporate office and under it, are various
divisions each of which is dedicated to producing and / or selling a certain type of
business or product, e.g., product 1, product 2, etc. Each division that is dedicated
to a certain business or product is, in turn, is organized as its own functional
structure. So, for example, the division dedicated to making product 1 has its own
sales department, human resources, etc. Basically, project structure is a bunch of
functional structures each of which reports to one central office. Use a divisional
structure when the organization is relatively large, geographically dispersed,
and/or produces wide range of goods/services.
In a projectized organization, team members are often collocated. Most of the
organization’s resources are involved in project work, and project managers have
a great deal of independence and authority. Projectized organizations often have
organizational units called departments, but these groups either report directly to
the project manager or provide support services to the various projects.
Structural dimensions:
Centralization -the extent to which functions are dispersed in the
organization, either in terms of integration with other functions or
geographically
Formalization - regarding the extent of policies and procedures in the
organization
Hierarchy - regarding the extent and configuration of levels in the
structure
Routinization - regarding the extent that organizational processes are
standardized
Specialization - regarding the extent to which activities are refined
Training - regarding the extent of activities to equip organization
members with knowledge and skills to carry out their roles
Contextual Dimensions:
Culture - the values and beliefs shared by all (note that culture is often
discerned by examining norms or observable behaviors in the workplace)
Software Project Management (CS615)
56
© Copyright Virtual University of Pakistan
Environment - the nature of external influences and activities in the
political, technical, social and economic arenas
Goals - unique overall priorities and desired end-states of the organization
Size - number of people and resources and their span in the organization
Technology - the often unique activities needed to reach organizational
goals, including nature of activities, specialization, type of
equipment/facilities needed, etc.
Role and responsibility assignments
Project roles (who do what) and responsibilities (who decide what) must be
assigned to the appropriate project stakeholders. Roles and responsibilities may
vary over time. Most roles and responsibilities will be assigned to stakeholders who
are actively involved in the work of the project, such as the project manager, other
members of the project management team, and the individual contributors. The
roles and responsibilities of the project manager are generally critical on most
projects, but vary significantly by application area. Project roles and responsibilities
should be closely linked to the project scope definition. A Responsibility
Assignment Matrix (RAM) is often used for this purpose. On larger projects, RAMs
may be developed at various levels. For example, a high-level RAM may define
which group or unit is responsible for each component of the work breakdown
structure, while lower-level RAMs are used within the group to assign roles and
responsibilities for specific activities to particular individuals.
Organization chart
An organization chart is any graphic display of project reporting relationships. It
may be formal or informal, highly detailed or broadly framed, based on the needs of
the project. For example, the organization chart for a three- to four-person internal
service project is unlikely to have the rigor and detail of the organization chart for a
3,000-person disaster response team. An Organizational Breakdown Structure
(OBS) is a specific type of organization chart that shows; which organizational
units are responsible for which work packages.
Project Personnel
The staffing management plan describes when and how human resources will be
brought onto and taken off of the project team. The staffing plan may be formal or
informal, highly detailed or broadly framed, based on the needs of the project. It is a
subsidiary element of the overall project plan.
The staffing management plan often includes resource histograms. Particular
attention should be paid to how project team members (individuals or groups) will
be released when they are no longer needed on the project.
Appropriate reassignment procedures may:
Software Project Management (CS615)
57
© Copyright Virtual University of Pakistan
– Reduce costs by reducing or eliminating the tendency to “make work” to fill
the time between this assignment and the next.
– Improve morale by reducing or eliminating uncertainty about future
employment opportunities.
Supporting detail
Supporting detail for organizational planning varies by application area and
project size. Information frequently supplied as supporting detail includes, but is
not limited to:
– Job descriptions (position descriptions) —written outlines by job title of the
competencies; responsibilities, authority; physical environment, and other
characteristics involved in performing a given job.
– Training needs—if the staff to be assigned is not expected to have the
competencies
Needed by the project, those competencies will need to be developed as part of
the project.
Key Concepts in Design of Good Organization
Effective Organizational System provides assessment and training in
communication effectiveness through focus groups, retreats, workshops, and
experiential activities. Coaching addresses such skills as active listening,
constructive differing, conflict resolution, negotiation, mediation, persuasiveness,
and clarity in delivering a message. At the core of the training is the fundamental
premise that the role of communication is to create understanding. When
communication is effective, it promotes understanding and plays a fundamental role
in building interpersonal skills, leadership and strong teams.
An efficient organization is characterized by timely and productive systems and
procedures. At its extreme it has no spare capacity to plan ahead or to respond
easily to market changes.
An effective organization is characterized by the ability to pre-empt competitors,
respond swiftly and efficiently to changing situations, and display agility in its
structure and conduct of operations. It has efficient systems and procedures but has
the capacity to anticipate and plan ahead.
Organizational System provides assessment and training in communication
effectiveness through focus groups, retreats, workshops, and experiential activities.
Coaching addresses such skills as active listening, constructive differing, conflict
resolution, negotiation, mediation, persuasiveness, and clarity in delivering a
Software Project Management (CS615)
58
© Copyright Virtual University of Pakistan
message. At the core of the training is the fundamental premise that the role of
communication is to create understanding. When communication is effective, it
promotes understanding and plays a fundamental role in building interpersonal
skills, leadership and strong teams. Organizations that achieve high levels of
maturity in the people management area have a higher likelihood of implementing
effective software engineering practices.
– Span of control - the range of employees who to report to a managerial
position
– Authority - the formally-granted influence of a position to make decisions,
pursue goals and get resources to pursue the goals; authority in a managerial
role may exist only to the extent that subordinates agree to grant this authority
or follow the orders from that position
– Responsibility - the duty to carry out an assignment or conduct a certain
activity
– Delegation - process of assigning a task to a subordinate along with the
commensurate responsibility and authority to carry out the task
– Chain of command - the lines of authority in an organization, who reports to
whom
– Accountability - responsibility for the outcome of the process
– Line authority - the type of authority where managers have formal authority
over their subordinates' activities (the subordinates are depicted under the
manager on a solid line in the organization chart); departments directly
involved in producing services or products are sometimes called line
departments
– Staff departments - the type of authority where managers influence line
managers through staff's specialized advice; departments that support or
advise line departments are called staff departments and include, e.g., human
resources, legal, finance, etc.
Software Project Management (CS615)
59
© Copyright Virtual University of Pakistan
LECTURE # 7
2. Software Development Fundamentals
Management Fundamentals
2.1 Evolution of Software
The understanding about software and software development has come a long
way from the days of punch cards and Ada. In the first stage of computing,
hardware mattered the most. Computers themselves were the domains of the
government, and most software was developed in defense-funded labs, dedicated
to the advancement of science and technology in the national interest.
By the 1950s, large corporations realized the benefits of using computers. They
increasingly started using computers to process and analyze financial and
production data. These computers were huge in size. There was inadequate
software available for them. Even the software that existed was designed
essentially to function on a specific hardware product. The software was
developed and maintained by the company that manufactured the hardware.
Software design and documentation existed only in the developer's head. If the
developer left the company, you would find maintenance to be a nightmare.
In the second phase of software evolution, the corporate and academic sectors
increasingly started using computers, and the perspective about both software and
software development began to change. By the late 1960s and early 1970s,
concepts such as multi-sessions, multi-user systems, multiprogramming gained a
foothold. Soon computers were developed to collect, process, transform, and
analyze data in seconds. The focus of software development shifted from custom
software to product software. Now, multiple users on multiple computers could
use the same software. This phase of software evolution also saw the emergence
of software maintenance activities. These activities comprised fixing bugs, and
modifying the software based on changes in user requirements.
The third phase in software evolution was driven by the widespread use of
silicon-based microprocessors, which further led to the development of highspeed
computers, networked computers, and digital communication. Although, all
the advancement in software and hardware was still largely restricted to enterprise
applications manufacturers had begun to see the application of the microprocessor
in something as mundane as ovens to the robots used in car plants.
The fourth, and current, phase of software evolution began in the early 1990s.
This phase saw the growth of client-server environment, parallel computing,
distributed computing, network computing, and object-oriented programming.
Software Project Management (CS615)
60
© Copyright Virtual University of Pakistan
This phase also witnessed the growing popularity of personal computer (PC).
During this phase, the Internet facilitated easy accessibility of information. In
addition to complex software to support the advanced hardware, the scope of
software development widened to include software products for the common man.
Figure 1.1 sketches the path of software from the 1950s onwards.
• The Software Crisis
The rapid evolution of software design concepts and software development
methodology resulted in an ad hoc approach to software development. In the early
days of computing, stress was laid more on computer hardware than on software.
This happened mainly because hardware consumed the largest portion of the
project budget. Project managers closely followed the process of hardware
funding, budgeting, analysis and design, production, and implementation.
Software development, on the other hand, was left to the developers. There was
no training conducted, documentation maintained, or methodology followed for
software development. You will find that this attitude persisted until the 1970s,
when finally processes and methodologies for software design and development
began to be created. However, the ad hoc approach to software development that
Software Project Management (CS615)
61
© Copyright Virtual University of Pakistan
was prevalent in the early stages of software evolution hampered the application
of systematic processes. This conflict referred to as the software crisis. Some of
the reasons to which you can attribute the software crisis include:
– Software developers used-multiple programming languages.
– Software developers used multiple variations of standard programming
languages.
– Most of the requirements were complex with regard to the existing
capabilities,
– Users, who had little or no experience of developing or even using
software, formulated requirements.
– Software developers poorly mapped requirements to the actual product.
– Software developed had low interoperability.
– Software maintenance was costly.
– Hardware developed at a faster rate than software (better hardware
requires better software to operate it).
During the period of software crisis, you will find that software that was produced
was generally over budgeted, under scheduled, and of poor quality. The
immediate knee-jerk response to these problems was software maintenance,
which began to consume huge resources. During this period, maintaining software
was adopted as a short-term solution due to the costs involved in fixing software
regularly. This often resulted in the original software design approach getting lost
due to the lack of documentation.
In contrast, the situation in the present times has changed to a large extent.
Software costs have risen, although hardware is purchased easily off the shelf.
Now, the primary concerns regarding software projects are project delays, high
costs, and a large number of errors in the finished product.
2.2 Project Execution Fundamentals
Tracking
For the project manager, it is essential to be constantly informed of the true status
of the project. This is achieved by assuring the regular flow of accurate
information from the development teams. Many of the methods of acquiring
information are not objective and rely on the accuracy of the reports provided by
the project developers themselves. They include:
– Periodic written status reports
– Verbal reports
– Status meetings
– Product demonstrations (demos)
Product demonstrations are particularly subjective, because they demonstrate only
what the developer wishes to be seen. The project manager needs objective
Software Project Management (CS615)
62
© Copyright Virtual University of Pakistan
information. Such information can often be acquired from reports produced by
support groups, such as:
– Quality assurance reports
– Independent test reports
Although reports and meetings are indeed useful sources of information, nothing
can replace direct contact between the project manager and the development staff.
Frequent informal talks with the developers are excellent sources of information,
especially when held in an informal atmosphere (and not in the project manager's
office).
The project manager must keep on constant guard against an error commonly
referred to as the '90/50 syndrome’, which states that, 'it takes 50 percent of the
time to complete 90 percent of the work, and an additional 50 percent of the time
to complete the remaining 10 percent of the work'. This means that project
developers will begin to boast quite early that they have 'almost finished' their
tasks. Unfortunately, there is a great difference between 'almost finished' and
‘finished'.
Finishing a task -writing documentation, and polishing off the last few problems,
often takes longer than developers anticipate. This is because these activities
produce very few visible results, and developers tend (wrongly) to associate work
with results. Therefore, managers can obtain more information from developers
by asking them how long they estimate it will take to finish, and not how much of
their work has been completed.
• Status reports
Status reports should be required from every member of the development team,
without exception. The reports should be submitted periodically, usually weekly
or bi-weekly, and should contain at least the following three sections (see Fig.
5.8):
1. Activities during the report period
Each subsection within this section describes a major activity during the report
period. The description of each activity should span two to three lines. Activities
should be linked to the project task list or work breakdown structure (WBS) (see
Chapter 10 for a description of the WBS).
2. Planned activities for the next report period
Each subsection within this section describes a major activity planned for the next
report period. The description of each activity should span one to two lines.
3. Problems
Software Project Management (CS615)
63
© Copyright Virtual University of Pakistan
Each subsection within this section describes a major problem that either occurred
during the report period, or that was reported previously and has not yet been
resolved. This means that problems will be repeatedly reported until they are
resolved. In particular, this section must explain why this report's Section 1 does
not correspond to the previous report's Section 2.
All reports should also contain:
1. Date of report
2. Report period (e.g. 3 July to 10 July 1992)
3. Name of report (e.g. Communications team status report)
4. Name of person submitting the report
The preparation of a periodic status report should take about 20 minutes, but not
longer than 30 minutes. Developers should submit their status reports to their
team leader. The team leader then combines the reports of the team into a single
status report, while maintaining the same report structure. This activity should
take the team leader about 30 minutes, but not longer than 45 minutes (this is
easily done when the reports are prepared and submitted by electronic mail).
Each team leader submits the team status report to the project manager. The
individual status reports need not be submitted; these should be filed and
submitted to the project manager only on request.
Software Project Management (CS615)
64
© Copyright Virtual University of Pakistan
From: John Doe, Team leader
To: Frank Smith, Project Manager
Date: 15 June 1993
User interface team: Weekly status report
for the period 5-12 June 1993
1. Activities during the report period:
1.1 The design of the user help screens (activity 3.12.6) was completed on schedule.
The design specs were submitted to configuration control.
1.2 Coding of the command pass through modules (activity group 5.12) continues, and is
currently behind schedule by about 1 week.
2. Activities planned for next week:
2.1 Coding of the command pass through modules (activity group 5.12) will be
completed, and unit tests will be started.
2.2 Two members of the team (Ed and Joan) will attend a two day course on the
Programmer’s interface to the new user interface package. This is an unscheduled
activity that was approved at the last project meeting. This will not delay the
schedule, due to the early completion of the command pass through modules (see
Section 1.2 above).
3. Problems:
3.1 The user interface package we originally planned to use was found to be inadequate
for the project. Two team members will study the new proposed package (sec Section 2.2
above). If the new package is also found to be unsuitable, then this will severely impact
our development schedule.
3.2 One of our team members (Jack Brown) has been using an old VTI00 terminal
instead of a workstation for the past two weeks, due to the acute shortage of
workstations. This is the reason why Jack's task 5.12 was not completed this week, as
scheduled.
Figure 5.8: Example of a weekly status report
The project manager also receives status reports from other project support
personnel such as the project systems engineer or the deputy project manager. The
project manager then prepares the project status report by combining the
individual reports received into a single three-part report. The project status report
is then submitted to top management.
Software Project Management (CS615)
65
© Copyright Virtual University of Pakistan
Project status reports are not necessarily submitted at the same frequency as
internal project status reports. Project reports may be submitted bi-weekly or
monthly.
• Project status meetings
Project status meetings should be held periodically, usually once a week. A good
time for status meetings is either at the end of the last day of the week, or at the
beginning of the first day of the week. Status meetings also contribute to the
atmosphere of order and control within the project, and should be held regularly,
at a fixed time. Participants who cannot participate in the project status meeting
may, with the project manager's approval, delegate participation to another
member of their team.
The project manager prepares for the status meeting by reviewing the status
reports submitted by the key project members (particularly scrutinizing the
problem section). Therefore the status reports should be submitted at least two to
three hours before the status meeting. Project status meetings are attended by the
key project members. The meeting begins with a report of project activities and
general issues by the project manager. Then each participant should be given
about five to ten minutes to report on the activity of his or her team or area of
responsibility. The discussion of problems should not be restricted to the person
reporting the problem and the project manager. All problems may be addressed by
all participants, with possible assistance offered between team leaders, thus
making their experience available throughout the project. It is not the project
manager's role to provide solutions to the problems, but rather to guide the team
members toward solutions.
Solutions should be worked out whenever possible during the status meeting. Any
problem not resolved within five minutes should be postponed for discussion by
the relevant parties after the status meeting. The proceedings of all project status
meetings must be recorded. Verbatim minutes are not required, though the
following items should appear in the record:
1. Date of meeting
2. Name of meeting
3. Present (list of participants)
4. Absent (list of absent invited participants)
5. Action items (name, action, and date for completion)
6. Major decisions and items discussed
The record of the project status meeting should be typed and distributed as soon
as possible, but no later than by the end of the day. This is particularly important
when there are action items to be completed on the same day. When the project is
sufficiently large to justify a secretary, then the record will be taken and typed by
Software Project Management (CS615)
66
© Copyright Virtual University of Pakistan
the secretary. In smaller projects, the project manager can rotate this task each
week between the participants.
2.3 Software Project Management Framework
You all know that a project is much more than a collection of methodologies,
tasks, resources, and reviews. A project is a synchronized event where there is
perfect harmony and understanding between the participants. The participants are
equipped with the essential skills of planning, cooperating, helping, and
communicating. However, the most important activity here is to orchestrate the
movement of the participants. The onus lies with the project manager to
synchronize the activities of the project to result in a perfect presentation.
Although each project manager has a unique style of functioning, there are some
fundamental approaches that guide a project manager. These approaches are
traditional project management concepts and software engineering concepts. To
understand software projects and their dynamics, you must be aware of the
environment in which a software project is executed. This further requires an
understanding of the larger framework of software project management.
In this chapter, you will learn to, build a connection between traditional project
management concepts and software engineering concepts. Both traditional and
software projects share the same methodologies, techniques, and processes.
However, managing software projects requires a distinct approach. In this,
chapter, you will learn to apply traditional project management principles to
software projects. Further, you will learn about the responsibilities of a software
project manager. You will also learn about the phases in a software project and
the activities within each phase. Finally, the chapter will provide you an overview
of the problems that affect a software project and the myths prevalent about
software project management.
2.4 Software Development Life Cycle (SDLC)
The development of a software project consists of many activities spread across
multiple phases. Dividing a software project into phases helps you in managing
the complexities and uncertainties involved in the software project.
2.5 Phases of a Software project
Each phase represents the development of either a part of the software product or
something associated with the software project, such as user manual or testing.
Each phase is composed of various activities. You can consider a phase complete
when all activities are complete.
Software Project Management (CS615)
67
© Copyright Virtual University of Pakistan
A phase is named according to the primary deliverable set that is achieved at the
end of that phase. For example, if the requirements document is required as the
output, the phase is called the requirements phase. Similarly, most software
projects have phases for analysis, design, construction, implementation, and
testing.
A typical software project includes the following phases:
– Software requirement analysis phase
– Software Design Phase
– Software Planning Phase
– Software construction phase
– Software testing phase
– Software acceptance and maintenance phase
2.6 SDLC Models
Different organizations have different ways of assessing and arranging the phases
in a project. These are called process models. Process models define how a
software life cycle actually works. They provide you with a framework to plan
and execute the various phases in the project. Typically, project life cycles display
the following characteristics:
• The level of cost and effort required in a software project life cycle is small to
begin with but grows larger towards the end of the project. This happens
because the phases such as software construction and implementation, which
come at later stages in a software project, require more resources than the
initial phases of the project.
• At the start of the SDLC, external entities, such as the customer and the
organization, play an important role with regard to their effect on the
requirements. However, towards the end of the software project as the cost
and effort required to implement changes rise, the requests for change in
requirements decreases.
• The uncertainty faced by the software project is highest at the beginning of the
SDLC. Their level decreases as the project progresses.
There are a few standard software process models that you can use, with some
customization. Some standard process models are given below:
• The Waterfall model: This is the traditional life cycle model. It assumes that
all phases in a software project are carried out sequentially and that each
phase is completed before the next is taken up.
• The Prototyping Model: A model that works on an iterative cycle of gathering
customer requirements, producing a prototype based on the requirement
specifications, and getting the prototype validated by the customer. Each
Software Project Management (CS615)
68
© Copyright Virtual University of Pakistan
iteration of the life cycle builds on the prototype produced in the previous
iteration.
• The Incremental Model: The Incremental model is an example of an
evolutionary life cycle model. It combines the linear nature of the Waterfall
model and the iterative nature of the Prototyping model. The Incremental
model divided the development life cycle into multiple linear sequences, each
of which produces an increment of the final software product. In this model,
the software product is developed in builds. A build is defined as a selfcontained
unit of the development activity. The entire development cycle is
planned for a specific number of logical builds, each having a specific set of
features.
• The Spiral model: Another evolutionary life cycle model that combines the
linear nature of the Waterfall model and the iterative nature of the Prototyping
model. The project life cycle is divided into phases, and each phase is
executed in all of the iteration of the Spiral Model.
Software Project Management (CS615)
69
© Copyright Virtual University of Pakistan
LECTURE # 8
2. Software Development Fundamentals
Management Fundamentals
2.7 Organizational Issues and Project Management
Organizational issues have a deep influence on a software project, its progress,
and the role of the project manager. The policies of an organization can affect the
way the organization handles the customer, different types of technologies, and
different software projects. The organizational issues that can influence a software
project include:
• Reaction to external influences
• Interest in adherence to standards
• Definition of core competency area
• Existence of knowledge management system
• Interest in human resources
One organizational issue that can influence a software project is the reaction of
the organization to external influences.- As a project manager, it is important for
you to assess how the organization reacts to changes in the external environment,
For example, in the current technology environment that changes rapidly, an
organization should be proactive in strengthening its capability baseline by
adopting new technology and retraining its employees as per market
requirements.
Interest in adherence to standards is another organizational issue that can
influence a software project. The current technology environment is highly
dynamic. Various nonprofit and independent organizations have developed
protocols and standards for the standardization of software development and
measurement: For example; the Software Engineering Institute at the Carnegie
Mellon University has developed the Capability Maturity Model (SEI-CMM).
The CMM rates the processes of a software development organization and
classifies it into five maturity levels. Software development organizations can also
get the quality-related certifications issued by the International Standards
Organization smoothen your project management tasks by standardizing the
internal processes and optimizing performance.
Definition of core competency area also influences a software project. An
organization that creates software must understand how they are created and
establish processes accordingly For example, if the core competency of the
organization lies in manufacturing chemicals, it should preferably not attempt
Software Project Management (CS615)
70
© Copyright Virtual University of Pakistan
software development for such an organization, it is better to purchase an off-theshelf
software product.
An organizational issue that positively influences the tasks of software project
managers is the presence of a good knowledge management system within the
organization. Knowledge management is the collection of processes that control
the creation and utilization of knowledge within the organization. A good
knowledge management system allows you to access relevant information and
make informed decisions.
Another organizational issue that can influence a software project is the interest of
management in human resources. The human resources of an organization are its
primary resource. You need to ensure that the people in the development team
enjoy a comfortable work environment, which is conducive for smooth and
trouble-free work. This includes providing suitable compensations, a friendly
work environment, and smooth processes. The absence of these factors negatively
affects employee morale, and therefore, productivity.
2.8 Managing Processes
As a software project manager, you become the key player in a software project.
You not only manager the day-to-day activities of the project but also ensure that
the software product is delivered on time. What makes your role challenging is
the performance of project-related activities within a specified budget and time
constraint. At the same time, you need to keep the requirements and specifications
of the customer in mind.
To deliver expected results, you carry out three successive processes: studying the
feasibility of the project, planning to meet the requirement, and executing the
plan. These processes can be further broken down into activities, such as
planning, staffing, and monitoring.
You plan and organize the software development team to complete development
within the stipulated time and budget. To do this, you form a team of people who
have the required technical skills. Then, you ensure that all activities are carried
out as planned by the relevant people.
Your responsibilities include analyzing customer requirements, determining the
scope of the software project, allocating resources top the project, scheduling the
project, and executing the project. These responsibilities can be considered in
terms of the areas where management skills are required. The primary software
project management areas that you need to concentrate on include:
• Managing Resources
• Managing Cost
Software Project Management (CS615)
71
© Copyright Virtual University of Pakistan
• Managing Risk
• Managing Schedule
• Managing the project plan
• Managing quality
⇒ Managing Resources
The primary input required to create software are resources. Resources for a
software project may be of three kinds: human, hardware, "and software. Human
resource management is about effectively identifying the people with the
appropriate skills, assigning roles and responsibilities to these people, and
establishing reporting relationships. On the other hand, hardware and software
resource management relates to identifying and ensuring resources such as
workstations, disk space on servers, software tools, and software licenses. You
need to ensure that human resource identification and allocation is carried out;
simultaneously with hardware and software resource management.
To manage resources effectively, there are two areas that you require your
attention. These include:
• Management of human resource
• Identification of the critical hardware and software resources
Management of human resources calls for a number of actions. First, you define
reporting relationship for the software project. Reporting relationship can exist
within and across organizational units, technical areas, and hierarchical levels.
Next, determine the skills required for the software project, and identify the
appropriate people who possess the required skills. You can review the resource
pool and identify resources on the basis of their experience and availability. In
case the resources are unavailable, you request for their release from another
project or outsource the required resources. Depending upon the organizational
practices arid experiences from past projects, you can assign roles and
responsibilities to the development team. Finally, create a staff management plan
and an organizational chart to show the hierarchical structure of the development
team.
Management of human resources also requires efficient team development. This
is a complex activity because it combines managing people and organizing the
reporting structure within the team. You can build cohesion and commitment
within the team through team building activities. These activities include
conducting team meetings to involve people from areas other than management
into decision-making.
To manage human resources, you also need to implement a reward and
recognition system. This helps in promoting and reinforcing positive
performance. It is important that you make the link between the performance and
Software Project Management (CS615)
72
© Copyright Virtual University of Pakistan
reward explicit and achievable. You should also ensure that the training needs of
the development team are met.
A second resource management area that requires attention is identification of the
hardware and software resources that are critical for the project. As a software
project manager, you must identify all the critical hardware and software
resources and document them in the project plan. After the required resources are
identified, you define control limits for each resource. Control limits for a
resource are the upper and lower limit beyond which the resource is above or
below the required level. For example, if a software project requires disk space on
the central server, the control limits for the disk space are the required maximum
and minimum disk space. Note that not all hardware and software resources are
critical to the success of a software project. In some software projects, you may
not find any critical resource at the beginning. However, as the project progresses,
some resources might become critical. For efficient resource management, you
should periodically assess hardware and software resource requirements for the
software project. Just as a resource may become critical as a project progresses, a
resource might also become less critical over a period of time. Therefore; plan,
assess, and take corrective action for all the resources through the duration of the
software project.
⇒ Managing Cost
The cost factor has a considerable influence on the execution of a software
project. The budget of a software project is affected by factors, such as the current
orientation of the organization toward software development, number of skilled
personnel available, infrastructure, and computer hardware and software. The
budget can also be influenced by timely availability of resources. If a particular
resource is allocated to the project later than required, the costs involved could go
up drastically.
Quite often, when a software project starts to become too expensive, many project
managers also tend to start cutting costs. This can have a direct impact on
employee morale. When employee morale drops, so does the quality of work, and
the productivity. Therefore, as a project manager you must prepare for all
circumstances through proper estimation and allocation. To manage costs for
software projects, you need an accurate estimation of costs. To do that, there is a
sequence of steps that you need to perform.
• Identify the resources required for the project
• Estimate the cost of each activity
• Set cost baselines for each activity
• Implement a control system for cost changes
To estimate costs, you first identify and describe all the resources required in the
software project. You also estimate the duration for which the resources are used.
Software Project Management (CS615)
73
© Copyright Virtual University of Pakistan
Next, estimate the cost of each resource. To estimate the cost, you can use
mathematical tools. However, in the case where limited information is available
about resources, you can also use expert judgment to estimate costs.
After the costs of the required resources are estimated, you set cost baselines for
each activity. Cost baselines measure the performance of an activity with regard
to the cost and duration defined for the completion of the activity.
Finally, as the project manager you implement a control system for cost changes.
The cost control system defines cost baselines, identifies cost changes, and
modifies cost baselines to adjust cost changes.
⇒ Management Risk
Risk management is an integral part of project management. In software projects,
where uncertainties are very high, risk management and mitigation is even more
critical. Taking risks for high payoffs might bring in high profits but not without
the danger of losses. Risk on a small scale is acceptable to most project managers
as the element of loss is minimal. However, large risks pose a danger to the
progress of a software project and you need to manage them. Risk management
activities involve identifying potential risks, assessing them, and planning for
contingent actions if a risk materializes.
As a project manager, you perform two primary activities to manage risks for
software project:
• Risk Analysis
o Risk identification
o Risk quantification
• Risk management
The first activity in risk analysis is risk identification. Risk identification helps
you point out the, potential risks for a software project across all phases of the
project. Risks might evolve through the duration of a software project, and
therefore, risk identification is an ongoing activity. To identify potential risks for
a software project, you can analyze the activities in the software project, the
software product description, and risks faced by the development team in similar
past projects. This exercise allows you to identify the potential sources of risks to
the current software project, Assessing the factor influencing the different inputs
also allows you to identify the phases in the SDLC when risk might materialize.
After potential risks have been identified, you can quantify them. This is done to
ascertain their priority. If multiple risks materialize at the same time, then you
must assign a priority to each risk based on the degree of impact on the project
and handle the highest-risk events first. For example, the risk of change in client
Software Project Management (CS615)
74
© Copyright Virtual University of Pakistan
requirements during the software construction phase is a higher risk than a
deadline for a deliverable being missed. Therefore, you first manage the risk that
has a higher priority. To quantify project risks, you can use various mathematical
and statistical tools. You can also use expert judgment to assess and quantify
risks.
After you have identified and quantified the potential risks for a software project,
you create a risk mitigation plan. The purpose of the risk mitigation plan is to help
you identify procedures to choose the path of least damage and highest returns in
a case a risk materializes. To mitigate risks for a software project, you first need
to be aware of the opportunities and threats that can be pursued or ignored. This
enables you to focus on the risks that might have a negative impact on the
software project and develop contingent plans to deal with these risks. You can
also mitigate risks by evolving alternative strategies to altogether prevent
potential risks from materializing.
In case an unplanned risk materializes, you must be aware of the dependencies of
the project activities so that ad hoc solutions can be evolved. However, as the
project manager you can avoid unplanned risks from materializing by engaging in
an intensive risk identification and mitigation exercise before the software project
commences.
⇒ Managing Schedule
Time is a major constraint for a software project. With most software projects, the
delivery dates for the software product are already committed to the customer at
the time the project commences. As a software project manager you must perform
various tasks to balance time and deadlines. These are:
– Identify the different deliverables that constitutes the software product
– Define the activities that are required to produce the deliverables
– Identify the interdependencies between activities
– Define the duration of each activity
– Assess the project network diagram
– Create a schedule management and control plan
The first task is to identify the different deliverables that constitute the software
product. These deliverables also mark the completion of the different phases
within a software project.
Next, define the activities that are required to produce the deliverables. To do this,
you can break down the SDLC into phases, identify the deliverables at the end of
each phase, and the activities required for creating the deliverables.
Software Project Management (CS615)
75
© Copyright Virtual University of Pakistan
After the activities are defined, you identify the interdependencies between them.
The purpose of this exercise is to organize the activities and sequence them in the
form of a project schedule.
Next, you define the duration of each activity. The inputs that you need for
scheduling are the resources required to complete each activity. Then, assesses the
availability of these resources and the duration of each similar activity in similar
past projects.
After estimating the time required for each activity to complete, you assess the
project network diagram. This includes an assessment of the duration estimates,
resource requirements, resource pool description, and assumptions and constraints
for the software. You can use Mathematical tools to determine a schedule for the
project. The project schedule defines the activities within each phase, the team
members assigned to complete each activity, the duration of each activity, and the
start and end dates for all of the activities.
Finally, create a schedule management and control plan. The purpose of this plan
is to identify when changes occur, Implement the changes to the project schedule,
and ensure that the changes are beneficial to the software project. After the
changes are implemented, you might need to modify the sections of the project
plan to ensure that the project is completed on time.
Software Project Management (CS615)
76
© Copyright Virtual University of Pakistan
LECTURE # 9
2. Software Development Fundamentals
Management Fundamentals
2.8 Managing Processes
⇒ Managing the Project Plan
Preparing it project plan for a software project helps you ensure that the specified
requirements and objectives are met successfully. It is a collation of all planning
activities that have happened for a software project. This includes activities such
as design and analysis, activity definition, risk planning, and cost estimation. To
create the plan, you assess all planning activities, organizational policies
regarding the creation of the project plan and assumption and constraints for the
project. To implement the software project plan, you require management skills,
such as leadership, communication, and problem solving, along with the basic
knowledge about the software. You also need to ensure that the senior
management bf the company has authorized work on the software project.
Knowledge management techniques help you to make informed decision
regarding the project plan.
After the project plan is executed, you manage the changes to it in such a way that
the performance measurement baselines are not impacted, To manage the project
plan effectively you monitor the project plan, periodic performance status reports,
and requests for change. The primary tool that you can use to control the changes
in the project plan is the change control mechanism: This is a set of formal
procedures for changing the project plan.
⇒ Managing Quality
The quality of software development depends largely on the understanding of
‘quality’ and quality management within the software development team. In
software projects where each member has a different understanding of quality and
his or her role in implementing it, the software product is usually not of the
required quality.
Implementing software quality is often associated with the software developer.
However, the role of the project manager is crucial in implementing quality
awareness and a quality-producing work environment. When a software project
starts missing deadlines and is in danger of exceeding the budget, project
managers often lose the focus on quality and lay stress on meeting deadlines.
However, the focus should be the other way round. A focus on delivering a
Software Project Management (CS615)
77
© Copyright Virtual University of Pakistan
quality product, even at the cost of missing a deadline or two ensures that your
customer comes back for repeat orders. On the other hand, the price of nonconformance
(PONC) on quality standards simply translates into the loss of
goodwill and loss of business.
Modern quality management techniques compliment project management and the
role of the project manager. Quality management techniques ensure that a
software product conforms to the customer requirements. Quality management
further ensures that errors are prevented in the first round itself. Checks for errors
and effort for removing the errors consume much more time, effort, and cost than
it takes to prevent the errors in the first place. Therefore, maintaining quality in a
software project is the domain of all team members.
However, as the project manager you have a critical role in maintaining quality.
You provide the resources required to complete the activities of the software
project and ensure that quality levels are constantly monitored.
You first identify the areas that must be monitored for ensuring quality and the
quality measures to implement. Then, consider the quality policy of the
organization, the scope of the project, the applicable standards, and the software
product description. Next, use tools, such as a cost-benefit analysis and a
flowchart, to identify the areas where you need to monitor quality and the
subsequent actions for control. The output of this exercise is the quality plan for
the software project. In addition, this exercise allows you to create checklists to
help monitor quality.
As a software project manager, you also need to use a quality control mechanism
so that the quality of the software product does not suffer. The aim of the quality
control mechanism is to ensure compliance with quality standards.
2.9 Project Execution
You already learned in the beginning of the chapter that a software project is
divided into different phases. This division is done on the basis of the activities
performed in each phase. Similarly, project management activities are also
arranged in phases. As a project manager, you perform the activities that map to
each of these phases. The project management phases can be broadly categorized
as follows;
– Project initiation
– Project closedown
– Project planning, control, and tracking
– Product implementation
• Project Initiation
Software Project Management (CS615)
78
© Copyright Virtual University of Pakistan
The tasks performed for project initiation are mentioned below:
Requirement gathering: The first task is to gather the customer requirements.
Customer requirements may be spoken or unspoken. Therefore, the challenge for
the project manager is to elicit the requirements in such a way that both the
spoken and unspoken customer needs and wants are gathered. After collecting the
required information, you need to translate the customer requirements into
technical specifications for the software project.
Scope determination: The scope of a software project can be defined as the
combination of the software product arid services to be delivered to the customer.
You carry out the scope determination exercise to define the scope of the software
project. The scope determination exercise enables you to refine and understand
the customer requirements. You can refine the scope definition further by
breaking down each deliverable into smaller and more manageable activities. The
scope determination exercise also helps you identify the technology for creating
the software product.
Resource allocation: During project initiation, you identify the resources required
and allocate them to the software project. The resources identified may be people,
reusable software components, and hardware or software tools. You allocate the
resource to the software project on the basis of the activities defined in the scope
determination exercise. While allocating appropriate resources for a software
project, you also need to calculate the cost of each resource. The cost of a
resource is calculated according to the duration of the resource in the software
project. Estimating the cost of resources also helps you prepare a budget for the
software project.
Note:
Scope determination and resource allocation are discussed in more detail in later
chapters.
Initial project plan: Another exercise that you carry out during project initiation
is the creation of a rough project plan. This plan is a draft version and carries only
the primitive project plan features. This project plan carries the initial risk
analysis of the software project, the initial start and end dates, the duration of the
activities in the project, and the sequencing of these activities.
• Project Planning, Controlling, and Tracking
This activity of the project manager involves detailed tasks. These tasks are
mentioned below:
Detailed project plan: After the scope for the software project is determined and
the product design is ready, you prepare a detailed project plan. To create a
detailed project plan, you define a detailed list of all the elements that make up the
Software Project Management (CS615)
79
© Copyright Virtual University of Pakistan
project deliverables. Next, the deliverables are further broken up to help In the
calculation of durations, start dates and end dates for each activity mentioned in
the plan. Roles and responsibilities are assigned to people with the appropriate
skills to complete each activity within specified time.
Control mechanism: These are set up to control the impact of changes on the
software project. The control mechanism includes a detailed risk management and
mitigation plan, a detailed quality plan, and quality assurance activities. You also
implement a review and audit system for periodic assessment and measurement of
the software project activities. The review and audit system enables you to
evaluate the progress of the software project. It ensures that all necessary data is
collected, deviation from the planned baselines is checked, and corrective action
is taken at all checkpoints. In this way, the review and audit system ensures
compliance with the organizational processes for software development.
Software Project Management (CS615)
80
© Copyright Virtual University of Pakistan
LECTURE # 10
2. Software Development Fundamentals
Management Fundamentals
2.9 Project Execution
⇒ Product Implementation
Product implementation activities involve defining processes related to the
implementation of the software product at the customer site. Some of the tasks
that you perform for product implementation are mentioned below:
• Implementation plan creation: An implementation plan defines the duration of
implementation and the hard and software perquisites for implementing the
software product.
• Support plan creation: the project manager also needs to create a support plan for
the customer. The support plan includes consideration such as the postimplementation
support activities provided to the customer. Post-implementation
considerations include the number of support staff available to the customer, their
names, contact numbers, and the duration of their availability.
• Training plan creation: During product implementation, you create a training
plan to train the customer on the software product. The training plan includes
considerations such as the duration of training, the prerequisites for training
people, and the number of people that can be trained simultaneously.
• User acceptance plan: You also need to prepare a user acceptance plan. The user
acceptance plan provides a detailed outline on how and when the user acceptance
tests are performed. The primary focus of user acceptance test is to ensure that the
final software product offers all the functionality and performance that the
customer wanted. Therefore, the customer tests the software product for issues
such as aesthetics, user friendless, and scalability.
⇒ Project Closedown
The final activity for a project manager is project closedown. For most software
projects, the project closedown activities take place in the post-implementation
phase. However, in some software projects, the customer requests support
activities for a longer duration. In such cases, the software project is considered
Software Project Management (CS615)
81
© Copyright Virtual University of Pakistan
closed immediately after implementation. The tasks that you perform in project
closedown are mentioned below:
• Prepare closedown report: The project closedown report contains the results of
the causal analysis that you do for the project. This contains an analysis of what
went wrong, what went right, and what you could have done better in the software
project.
• Identify learning: You also need to assess the entire software project and the
results of the causal analysis to identify the key learning points from the software
project. This helps you identify areas of improvement for future projects. The
learning points can also be used by the organization as considerations while
planning and executing the next software project.
• Identify reusable software components: Reusing software components enables
you to lower the cost, time, and effort required to complete the software project
successfully. After project closedown, you identify the software components that
can be reused in future projects of similar nature. The software components
prepared for a software project may be complete, partially complete, or in the
design stage. These components or their designs can be assessed for usability in
future projects.
• Create reference material: After the project is complete, you can create white
papers and reference documents. This can be a significant contribution to the
organization and the application area of the software by creating an authoritative
knowledge base.
2.10 Project Management Myths
In most cases, you learn the skills required to manage a software project while on
the job. As a result, most software project managers practice a lot of management
techniques that are of doubtful authenticity. Many software project managers
learn about the so-called management skills and concepts that are actually myths.
⇒ Clarifying the Project Management Myths
The following list aims to clarify some of the more prevalent myths in software
project management.
1. Combining the best resources with the worst resources available for a
software project helps to complete the project successfully.
2. A general statement of objectives is sufficient to begin work on the software
project.
Software Project Management (CS615)
82
© Copyright Virtual University of Pakistan
3. Allocating extra resources to a late project allows it to catch up with the
project schedule.
4. As software by itself is flexible, you can change the requirements at any point
in the software project life cycle.
5. The management and the customer always impose an unrealistic deadline for
the software project.
6. A software project that meets all the stated objectives is a success.
7. Software maintenance is an easy task and requires less effort than actual
software development.
8. Identifying and reporting errors during the reviews makes the software
developer unhappy and spoils the work environment.
9. Web-enabling an application or adopting client/server; architecture helps to
run software projects smoothly.
Myth: Combining the best resources with the worst resources available for a project
helps to complete the project successfully.
In software projects, combining the best resources with the worst resources drags
down the efficiency and productivity of good resources. This invariably decreases
the speed of the software project, and the project ends much after the specified
deadline.
Myth: A general statement of objective is sufficient to begin work on the software
project.
Many software project managers and customers believe that a general statement
of objectives gives a reasonable idea of the requirements. However, a formal and
detailed description of the customer requirements is needed before the project
commences. The software project manager must ensure that all information
regarding the software project, such as the functions, performance, interfaces,
constraints, assumptions and validation criteria is gathered.
Myth: Allocating extra resources to a late project allows it to catch up with the
project schedule.
A software project is not a mechanical process such as, say; digging an artificial
lake. In case of creating an artificial lake, adding more people to the job can help
dig a larger area in the same time. However, in a software project, adding, more
people actually increases the time required to finish the project. This happens
because a new person joining the project requires time to understand the
Software Project Management (CS615)
83
© Copyright Virtual University of Pakistan
requirements of the client, software design, and standards. Moreover, the existing
people in the project need to devote time and effort to train the new people on the
software project. Therefore, allocating additional resources to a risky situation
increases the risk to the software project.
Myth: As software by itself is flexible, changes in the requirements can be made at
any point in the software project life cycle.
Requests for changes are common with all projects. However, the timing of the
change for requests is critical. This is because an untimely change adversely,
impacts the cost of the software project. For example, a change request during the
requirements gathering stage has a relatively low impact on costs. On the other
hand, a change request during, the software construction stage can be extremely
expensive to incorporate. The software project manager must decide with the
customer upon a set of objectives that must be achieved at the end of the project.
In addition, the project manager and the customer must decide on a specific
phase, beyond which only critical change requests are accepted.
Myth: The management and customer always impose an unrealistic deadline for the
software project.
The management and customer usually believe that project managers prepare cost
effort, and time estimates inclusive of buffers. The management and customers
rationalize that if they can cut the buffers by imposing a tight deadline or a low
budget on a project, the project manager would still complete the project on time.
Myth: A software project that meets all the stated objectives is a success.
Customer requirements for a software project are always in two forms, spoken
and unspoken. Usually, the objectives formed from the customer requirements are
based on the spoken requirements. The software project manager must to be
aware of the unspoken requirements and ensure that these are met.
Myth: Software maintenance is an easy task and requires less effort than actual
software development.
If change requests are made toward the end of the project, then maintenance
activities can contribute to large costs and effort overruns. Moreover, contrary to
the popular view, implementing changes in the software product in the
maintenance stage is a painstaking task.
Myth: Identifying and reporting errors during the reviews makes the software
developer unhappy and spoil the work environment.
Software Project Management (CS615)
84
© Copyright Virtual University of Pakistan
If a developer makes an error, it is important to point it out so that the error is
fixed in time. A project manager must communicate assertively so that the team
does not lose focus on quality. In addition, letting an error pass may have ripple
effects on the quality of the software product, frustrating the entire team.
Myth: Web-enabling an application or adopting client / server architecture helps to
run software projects smoothly.
No single technology platform, language, or architecture is a one-point solution
for all software projects. All approaches to software development have unique
merits and demerits. For example, if a marketing firm needs to make information
accessible to people at remote locations, then a, Web-based application is a good
option. However, mainframes are still preferred for applications created for the
banking industry.
Software Project Management (CS615)
85
© Copyright Virtual University of Pakistan
LECTURE # 11
2. Software Development Fundamentals
Management Fundamentals
2.11 Problems in Software Projects
Software projects are similar to traditional projects in the sense that the same
types of problems affect them both. However, the difference in managing these
problems lies in the approach that you take to the specific issue. For example, a
technology-related problem for a software project might be the low degree of
reuse of the software components created. However, for a car-manufacturing firm,
there is no chance of reusing a component such as a front axle.
You can classify the problems that affect software projects into the following four
categories:
• People-related problems
• Process-related problems
• Product-related problems
• Technology-related problems
⇒ People-related problems
People-related problems in a software project are:
• Low motivation: As the project manager it is your responsibility to ensure an
optimal level of motivation within the team. Lengthy projects, complex
activities1 and scarce resources often decrease the motivation level in a
software development team. However, you need to lead in such a way that the
team is constantly motivated to do a good job.
• Problem employees: Some members of any team always create a problem. For
example, an employee may carry a 'holier-than thou' attitude. Problem
employees raise the chances of conflicts and differences of opinions within
the development team. They lower the efficiency and productivity of other
team members and make it difficult to meet the objectives of the software
project within the specified time. You need to ensure that employees are not
allowed to create a pr9blem for the rest of the team. Even if the employee is
very competent, you need to assess the indispensability of such emp1oyees for
the project. Moreover, you refrain from playing favorite with certain
employees and treat everyone with the same measure.
Software Project Management (CS615)
86
© Copyright Virtual University of Pakistan
• Unproductive work environment: The work environment is a major factor
that affects the productivity of the development team. For example, a noisy or
cramped workspace decreases the motivation levels of the employees.
Similarly, unfriendly organizational policies also lower the motivation of the
team members. As the project manager, you need to ensure that the team is
protected from harmful external make the workspace friendly to work in.
• Inefficient project management style: the project manager needs to lead by
example. The team members absorb the work culture, work ethic, and attitude
of the project manager and implement it in their work style. If you display a
lack of leadership qualities and weak ideals, the motivation levels decrease
across software team.
• Lack of stakeholder interest: For a software project to be a success, each
stakeholder needs to take an active interest in the progress of the project. Al1
stakeholders, including the customer, the management, and the software
development team, need to commit to the success of the project. For example,
if the software development team is not committed to the project, then their
contribution may not be to the optimum level.
• Ineffective project sponsorship by management: Lack of commitment of the
senior management to a software project lowers the motivation level of the
team members. If the management commits to the progress of a software
project, and takes a keen interest in the progress, the confidence of the
software development team will increase.
⇒ Process- related Problems
The process-related problems in a software project are:
• Unrealistic schedule: Assigning unrealistic deadlines for a software project is
a primary reason why software projects are delayed. Often, the marketing or
the management team commit a delivery date to the customer in the hope of
getting the project contract. However, these dates are not decided in
consultation with the development team. The rationale for assigning the
deadlines is unfounded. You need to ensure that the deadlines match the
ability of the software team to deliver the software product. As it is not always
possible to shift deadlines committed to the customer, you also need to plan
the resource allocation and project execution such that the deadlines are met.
• Insufficient identification: Unidentified, partially identified, and unplanned
risks pose a threat to the success of a software project. You need to intensively
identify risks and evolve a risk management plan such that the project is
completed successfully, on time.
Software Project Management (CS615)
87
© Copyright Virtual University of Pakistan
• Unsuitable life cycle model selection: Different software projects require
different SDLC models. For example, a project to create banking .software is
different from software for a satellite where the concept needs to be
researched. For the former example, the Waterfall model is more applicable.
For the latter example, the Spiral model is more suitable. Selecting the correct
life cycle model is critical to the success of a software project.
• Abandoning quality under pressure of deadlines: Where a software project
faces a shortage of resources, time, and funds, project managers often push
away quality concerns and focus on meeting deadlines and staying within the
budget. Abandoning quality has a ripple effect that actually adds even more
time, effort, and costs to the software projects. The cost of doing things right
the first time is lower than the cost of inspection during product delivery.
Also, the cost of inspection is lower than the cost of debugging software after
the customer spots errors.
• Unstructured and hurried software development: When software project
progresses with more focus on meeting deadlines and staying within a budget,
the approach to the software development is unstructured and hurried. You
should plan the software project such that all the activities are identified,
sequenced properly, and roles and responsibilities assigned to the various
people on the project. You should also maintain the focus of the development
team toward a structured approach to software development.
⇒ Product-related Problems
There are many product-related problems that you can face in a software project.
These are:
• Product scope changed toward the end of the project life cycle: The project
time, effort, and cost estimates for a software project can go up dramatically
when the customer changes the scope 9f the product toward the end of the
project. In such situations, you should verify the criticality of the scope
change. However, if the change request is not critical, you should retain the
original scope with a proper explanation to the customer. If the change request
is critical, you should explain the situation to the customer. Usually, a
customer gives more time and funds to a software project if proper
justification is provided. In some cases, the scope change may also be because
of a change in government policy. It may become mandatory for you to
include such change requests.
• Research-oriented software development: Many software projects digress
from the original scope because of the nature of the software product or
technology used. When a totally new kind of software is developed or a new
Software Project Management (CS615)
88
© Copyright Virtual University of Pakistan
technology is used, the software development team can lose focus of the
objectives by getting into a research-oriented approach. It becomes your
responsibility as the project manager to maintain the focus on the objective.
Software Project Management (CS615)
89
© Copyright Virtual University of Pakistan
LECTURE # 12
2. Software Development Fundamentals
Management Fundamentals
2.10 Problems in Software Projects
⇒ Product-related Problems
• III-defined scope: You need to define the scope of the software product in the
initial stages of a software project. The scope of a software product is defined
in terms of the functionality requirements, the performance requirements, the
assumptions, and the constraints on the product. If the product scope is ill
defined, the software project does not have a proper focus on the features
required in the product.
• Fuzzy users: You also need to clarify the background characteristics of the
users of the final software product at the beginning of the software project. If
the description of the users is fuzzy, then the software analysis, design, and
development stages may reflect the ambiguity with regard to the functions and
performance of the final software product.
⇒ Technology-related problems
You may also encounter technology-related problems in a software project. These
include:
• Overestimated savings from reusable components and new tools and
methods: You can reuse software components in a software project to save
time, effort, and cost of creating the component again. It is important that you
assess the savings that the use of such a software component provides to a
software project. This expectation of both the customer and the management
might not be met, if you overestimate the savings from reusing software
components.
• Switching tools in mid way: The current technology environment offers new
tools and technologies for software development at a fast rate. All these tools
and technologies offer the benefits of a shorter development cycle, lower
costs, and under better functionality than earlier tools. You should identify
and commit to the tool and technology for the software project before the
project commences. Switching the tool or technology used during the software
development stage causes the developers to relearn a new tool. In addition,
Software Project Management (CS615)
90
© Copyright Virtual University of Pakistan
there is a chance that it might not be possible to integrate the software already
developed with the new tool.
• Integrating different software products in cross-platform implementation:
The modem software environment requires that all software should integrate
with each other. However, many software projects do not plan for integration
with existing software in the same or different domain. This limits the
applicationofsu9h software and reduces the shelf life drastically. They key to
the success of a software product is interoperability. The software project
manager needs to determine the scope for the software product such that is
can be integrated easily with existing software.
⇒ Summary
The phases in a software project can be organized into a project life cycle. Some
standard life cycle models are the Waterfall model, the Prototyping model, the
Incremental model, and the Spiral model.
Organizational policies and attitudes influence the progress of a software project
and the tasks of a software project manager. For smooth progress of software,
project, the organization should be proactive in adopting changes in technology
and market environments, focused on developing software, and accept software
projects that match the organizational capability baseline. In addition, the
organization should implement employee-friendly human resource policies and
good knowledge management system.
The role of a software project manager includes managing resources, cost, risk,
schedules, project plan, and quality. Software project management activities can
be divided into phases. The main phases and the associated activities are initiating
the project, planning, controlling, and tracking, implementing the product, and
project closedown.
Initiating the project includes gathering requirements, determining the scope,
allocating resources, and creating an initial project plan. Planning, controlling,
and tracking involve creating a detailed project plan, constructing software, and
implementing a control mechanism. Implementing the product comprises
implementation plan, support plan, training plan, and user acceptance plan.
Project closedown includes preparing closedown report, identifying learning for
future projects, and identifying reusable software components for future software
projects.
Problems- affecting software projects can be classified into people-related,
project-related, product-related, and technology-related.
Various myths regarding software project management are adding more people to
a late project can help to finish the project on time, combining the best resources
Software Project Management (CS615)
91
© Copyright Virtual University of Pakistan
with the worst resources results in optimal resource allocation, and changes to the
scope of the software project and the software product can be made at any-time in
the SDLC.
Software Project Management (CS615)
92
© Copyright Virtual University of Pakistan
LECTURE # 13
2. Software Development Fundamentals
Technical Fundamentals
2.11 Requirements Management
⇒ Preview
Software requirements engineering is a process of discovery, refinement,
modeling and specification. The system requirements and role allocated to
software-initially established by the system engineer-are refined in detail.
Models of the required data information and control flow and operational
behavior are created. Alternative solutions are analyzed and a complete
analysis model is created.
Requirements engineering is the systematic use of proven principles,
techniques, languages, and tools for the cost effective analysis,
documentation, and on-going evolution of user needs and the specification
of the external behavior of a system to satisfy those user needs. Notice that
like all engineering disciplines, requirements engineering is not conducted
in a sporadic random or otherwise haphazard fashion, but instead is the
systematic use of proven approaches.
Both the software engineer and customer take an active role in software
requirements engineering-a set of activities that is often referred to as
analysis. The customer attempts to reformulate a sometimes nebulous
system-level description of data, function and behavior into concrete
detail. The developer acts as interrogator, consultant, problem solver and
negotiator.
The overall role of Software in a larger system is identified during system
engineering. However, it's necessary to take a harder look at software's
role-to understand the specific requirements that must be achieved to build
high-quality software. That's the job of software requirements analysis. To
perform the job properly, you should follow a set of underlying concepts
and principles. Generally, a software engineer performs requirements
analysis However, for complex business applications a 'system analyst’
trained in the business aspects of the application domain may perform the
task. If you don't analyze, it's highly likely that you'll build a very elegant
software solution that solves the wrong problem. The result is wasted time
and money, personal frustration and unhappy customers.
Software Project Management (CS615)
93
© Copyright Virtual University of Pakistan
Data, functional, and behavioral requirements are identified by eliciting
information from the customer. Requirements are refined and analyzed to
assess their clarity, completeness, and consistency.
⇒ Requirements analysis
Requirements analysis is a software engineering task that bridges the gap
between system level requirements engineering and software design
(Figure 1). Requirements engineering activities result in the specification
of software's operational characteristics (function, data; and behavior),
indicate software's interface with other system elements, and establish
constraints that software must meet. Requirements analysis allows the
software engineer (sometimes called analyst in this. role) to refine the
software allocation and build models of the data, functional, and
behavioral domains that will be treated by software. Requirements
analysis provides the software designer with a representation of
information, function, and behavior that can be translated to data,
architectural, interface, and component-level designs. Finally, the
requirements specification provides the developer and the customer with
the means to assess quality once software is built.
Figure 1: a bridge between system engineering and software design
Software requirements analysis may be divided into five areas of effort:
(1) Problem recognition,
(2) Evaluation and synthesis,
(3) Modeling
(4) Specification, and
(5) Review
System
Engineerin
g
Software
Design
Software
Requirement
s
Analysis
Software Project Management (CS615)
94
© Copyright Virtual University of Pakistan
Initially, the analyst studies the System Specification (if one exists) and
the Software Project Plan. It is important to understand software in a
system context and to review the software scope that was used to generate
planning estimates. Next, communication for analysis must be established
so that problem recognition is ensured. The goal is recognition of the basic
problem elements as perceived by the customer/users.
Problem evaluation
Problem evaluation and solution synthesis is the next major area of
effort for analysis. The analyst must define all externally observable
data objects, evaluate the flow and content of information, define and
elaborate all software functions, understand software behavior in the
context of events that affect the system, establish system interface
characteristics, and uncover additional design constraints. Each of
these tasks serves to describe the problem so that an overall approach
or solution may be synthesized. For example, an inventory control
system is required for a major supplier of auto parts. The analyst finds
that problems with the current manual system include:
(1) Inability to obtain the status of a component rapidly
(2) Two or three-day turnaround to update a card file
(3) Multiple reorders to the same vendor because there is no way to
associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what
information is to be produced by the new system and what data will be
provided to the system. For instance, is the customer desires a daily
report that indicates what parts have been taken from inventory and
how many similar parts remain. The customer indicates that inventory
clerks will log the identification number of each part as it leaves the
inventory area.
Solution synthesis
Upon evaluating current problems and desired information (input and
output), the analyst begins to synthesize one or more solutions. To
begin, the data objects processing functions and behavior of the system
are defined in detail. Once this information has been established, basic
architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does the
software to support this architecture fall within the scope outlined in
the Software Plan? A database management system would seem to be
required, but is user/customer's need for associativity justified? The
process of evaluation and synthesis continues until both analyst and
Software Project Management (CS615)
95
© Copyright Virtual University of Pakistan
customer feel confident that software can be adequately specified for
subsequent development steps.
Throughout evaluation and solution synthesis, the analyst's primary
focus is on "what, not "how." What data does the system produce and
consume what functions the system must perform. What behaviors do
the system exhibit, what interfaces, are defined and what constraints
apply?
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data and
control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software. The customer may be unsure of precisely what is required.
The developer may be unsure that a specific approach will properly
accomplish function and performance. For these, and many other
reasons, an alternative approach to requirements analysis, called
Prototyping, may be conducted.
Software Project Management (CS615)
96
© Copyright Virtual University of Pakistan
LECTURE # 14
2. Software Development Fundamentals
Technical Fundamentals
2.11 Requirements Management
⇒ Requirements Analysis
• Evaluation and Synthesis
Upon evaluating current problems and desired information (input
and output), the analyst begins to synthesize one or more solutions.
To begin, the data objects processing functions and behavior of the
system are defined in detail. Once this information has been
established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does
the software to support this architecture fall within the scope
outlined in the Software Plan? A database management system
would seem to be required, but is user/customer's need for
associativity justified? The process of evaluation and synthesis
continues until both analyst and customer feel confident that
software can be adequately specified for subsequent development
steps.
Throughout evaluation and solution synthesis, the analyst's
primary focus is on "what, not "how." What data does the system
produce and consume what functions the system must perform.
What behaviors do the system exhibit, what interfaces, are defined
and what constraints apply?
• Models
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data
and control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software.
• Specification
Software Project Management (CS615)
97
© Copyright Virtual University of Pakistan
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data
and control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software. The customer may be unsure of precisely what is
required. The developer may be unsure that a specific approach
will properly accomplish function and performance. For these, and
many other reasons, an alternative approach to requirements
analysis, called Prototyping, may be conducted.
• Concerns for Review
The customer may be unsure of precisely what is required. The
developer may be unsure that a specific approach will properly
accomplish function and performance. For these, and many other
reasons, an alternative approach to requirements analysis, called
Prototyping, may be conducted.
For example, an inventory control system is required for a major
supplier of auto parts. The analyst finds that problems with the
current manual system include:
(1) Inability to obtain the status of a component rapidly,
(2) Two- or three-day turn- around to update a card file,
(3) Multiple reorders to the same vendor because there is no way to
associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what
information is to be produced by the new system and what data
will be provided to the system. For instance, customer desires a
daily report that indicates what parts have been taken from
inventory and how many similar parts remain. The customer
indicates that inventory clerks will log the identification number of
each part as it leaves the inventory area.
Upon evaluating current problems and desired information (input
and output), the analyst begins to synthesize one or more solutions.
To begin, the data objects, processing functions, and behavior of
the system are defined in detail. Once this information has been
established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does
the software to support this architecture fall within the scope
outlined in the Software Plan? A database management system
would seem to be required, but is the user/customer's need for
Software Project Management (CS615)
98
© Copyright Virtual University of Pakistan
associativity justified? The process of evaluation and synthesis
continues until both analyst and customer feel confident that
software can be adequately specified for subsequent development
steps.
⇒ Requirements Elicitation for Software
Before requirements can be analyzed, modeled, or specified they must be
gathered through an elicitation process. A customer has a problem that
may be amenable to a computer-based solution. A developer responds to
the customer's request for help.
Communication has begun. But, as we have already noted, the road from
communication to understanding is often full of potholes.
1. Initiating the Process
The most commonly used requirements elicitation technique is to
conduct a meeting or interview. The first meeting between a
software engineer (the analyst) and the customer can be likened to
the awkwardness of a first date between two adolescents. Neither
person knows what to say or ask; both are worried that what they
do say will be misinterpreted; both are thinking about where it
might lead (both likely have radically different expectations here);
both want to get the thing over with, but at the same time, both
want it to be a success. Yet, communication must be initiated.
Gause and Weinberg [GAU89] suggest that the analyst start by
asking context-free questions. That is, a set of questions that will
lead to a basic understanding of the problem, the people who want
a solution, the nature of the solution that is desired, and the
effectiveness of the first encounter itself. The first set of contextfree,
questions focuses on the customer, the overall goals, and the
benefits. For example; the analyst might ask:
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a successful solution?
– Is there another source for the solution that you need?
These questions help to identify all stakeholders who will have
interest in the software to be built. In addition, the questions
identify the measurable benefit of a successful implementation and
possible alternatives to custom software development.
Software Project Management (CS615)
99
© Copyright Virtual University of Pakistan
The next set of questions enables the analyst to gain a better
understanding of the problem and the customer to voice his or her
perceptions about a solution:
– How would you characterize "good" output that would be
generated by a successful solution?
– What problem(s) will this solution address?
– Can you show me (or describe) the environment in which the
solution will be used?
– Will special performance issues or constraints affect the way
the solution is approached?
The final set of questions focuses on the effectiveness of the
meeting. Gause and Weinberg call these meta-questions and
propose the following (abbreviated) list:
– Are you the right person to answer these questions? Are your
answers "official"?
– Are my questions relevant to the problem that you have?
– Am I asking too many questions?
– Can anyone else provide additional information?
– Should I be asking you anything else?
These questions (and others) will help to "break the ice" and
initiate the communication that is essential to successful analysis.
But a question and answer meeting format is not an approach that
has been overwhelmingly successful. In fact, the Q&A session
should be used for the first encounter only and then replaced by a
meeting format that combines elements of problem solving,
negotiation, and specification.
2. Facilitated Application Specification Techniques
Too often, customers and software engineers have an unconscious
"us and them" mind-set. Rather than working as a team to identify
and refine requirements, each constituency defines its own
"territory" and communicates through a series of memos, formal
position papers, documents, and question and answer sessions.
History has shown that this approach doesn't work very well.
Misunderstandings abound, important information is omitted, and
a successful working relationship is never established.
It is with these problems in mind that a number of independent
investigators have developed a team-oriented approach to
requirements gathering that is applied during early stages of
Software Project Management (CS615)
100
© Copyright Virtual University of Pakistan
analysis and specification. Called facilitated application
specification techniques "(FAST).
This approach encourages the creation of a joint team of customers
and developers who work together to:
Identify the problem
Propose elements of the solution
Negotiate different approaches and specify a preliminary set of
solution requirements.
FAST has been used predominantly by the information systems
community, but the technique offers potential for improved
communication in applications of all kinds.
Many different approaches to FAST have been proposed. Each
makes use of a slightly different scenario, but all apply some
variation on the following basic guidelines:
– A meeting is conducted at a neutral site and attended by both
software engineers and customers.
– Rules for preparation and participation are established.
– An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the free
flow of ideas.
– A ‘facilitator’ (can be a; customer, a developer, or an outsider)
controls the meeting.
– A "definition mechanism" (can be work sheets, flip charts, or
wall stickers or an electronic bulletin board, chat room or
virtual forum) is used.
The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a preliminary
set of solution requirements in an atmosphere that is conducive to
the accomplishment of the goal.
To better understand the flow of events as they occur in a typical
FAST meeting, we present a brief scenario that outlines the
sequence of events that lead up to the meeting, occur during the
meeting, and follow the meeting.
Initial meetings between the developer and customer occur and
basic questions and answers help to establish the scope of the
problem and the overall perception of a solution. Out of these
initial meetings, the developer and customer write a one- or twopage
"product request." A meeting place, time, and date for FAST
are selected and a facilitator is chosen. Attendees from both the
Software Project Management (CS615)
101
© Copyright Virtual University of Pakistan
development and customer/user organizations are invited to attend.
The product request is distributed to all attendees before the
meeting date.
3. Quality Function Deployment
A quality management technique that translates needs of customers
into technical requirements of software.
i. Normal Requirement: meeting objectives & goals stated for a
product or system during meeting
i. Expected Requirement: Implicit to products / system and may
be so fundamental that customer does not explicitly state them
i. Exciting Requirement: Features beyond customer’s expectation
and prove to be very satisfying when present
4. Use Cases
As requirements are gathered as part of:
• Informal meeting
• FAST or QFD
SW Engineer can create a set of scenario that identify a thread of
usage for system to be constructed; providing a description of how
system will be used.
5. Analysis Principles
A variety of modeling notations are developed by investigators.
Each analysis method has a unique point of view. However all
analysis methods are related by a set of operational principles like:
– The information domain of a problem must be represented and
understood.
– The functions that the software is to perform must be defined.
– The behavior of the software (as a sequence of external events)
must be represented.
– The models that depict information function and behavior must
be partitioned in a manner that uncovers details in a layered (or
hierarchical) fashion.
Software Project Management (CS615)
102
© Copyright Virtual University of Pakistan
– The analysis process should move from essential information
toward implementation detail.
6. Software Prototyping
Analysis should be conducted regardless of the SW engineering
paradigm. (Various approaches apply)
In some cases it is possible to apply operational analysis principles
and derive a model of SW from which a design can be developed.
In other situation Requirement Elicitation (FAST, QFD etc) is
conducted and a model is built, called Prototype.
Software Project Management (CS615)
103
© Copyright Virtual University of Pakistan
LECTURE # 15
2. Software Development Fundamentals
Technical Fundamentals
2.11 Requirements Management
⇒ The Software Requirements Specification
The Software Requirements Specification is produced at the culmination of the
analysis task, The function and performance allocated to software as part of
system engineering are refined by establishing a complete information
description, a detailed functional description, a representation of system behavior,
an indication of performance requirements and design constraints, appropriate
validation criteria, and other: information pertinent to requirements. The National
Bureau of Standards; IEEE (Standard No. 830-1984), and the U.S. Department of
Defense have all proposed candidate formats for software requirements
specifications (as well as other software engineering documentation).
Mode of specification has a great impact on quality of solution. Forcing SWE to
work with incomplete, inconsistence, or misleading specifications result in
frustration and confusion affecting:
– Quality
– Timeliness and
– Completeness of SW product
• Principles
i. Separate functionality from implementation.
ii. Develop a model of desired behavior of a system that encompasses data and
the functional response of a system to various stimuli from the environment.
iii. Establish the context in which SW operates by specifying the manner in which
other system components interact with software.
iv. Define the environment in which system operates and indicate how a highly
inter-wined collection of agents react to stimuli in the environment (changes
to objects) produced by those agents.
v. Create a cognitive model rather than a design or implementation model.
Cognitive model describes a system as perceived by its user community.
Software Project Management (CS615)
104
© Copyright Virtual University of Pakistan
vi. Recognize that; “the specifications must be tolerant of incompleteness and
augmentable.”
vii. A specification is always a model –an abstraction-of some real (or envisioned)
situation that is normally quite complex. Hence it will be incomplete and will exit
at many levels of detail.
i. Establish the content and structure of a specification in a way that will enable it to
be amenable to change.
• Representation
i. Representation format and content should be relevant to the problem. (A
general outline of SRS can be developed).
ii. Information contained within the specification should be nested.
iii. It should reveal layers of information so that reader can move to the level
of detail required. Paragraph & diagram number scheme to indicate level.
iv. Diagrams and other notational forms should be restricted in number and
consistent in use. (Confusing or inconsistent notations, whether graphical
or symbolic degrades understating and foster errors.)
v. Representation should be revisable.
vi. The content of specification will change. Ideally, CASE tools should be
available to update all representations that are affected by each change.
The function and performance allocated to software as part of system engineering
are refined by establishing:
1. A complete information description,
2. A detailed functional description,
3. A representation of system behavior,
4. An indication of performance requirements and design constraints,
5. Appropriate validation criteria, and other: information pertinent to
requirements.
The Introduction of the software requirements specification states the goals and
objectives of the software, describing it in the context of the computer-based
system; actually, the Introduction may be nothing more than the software scope of
the planning document.
Software Project Management (CS615)
105
© Copyright Virtual University of Pakistan
The Software Requirements Specification is produced at the culmination of the
analysis task. The function and performance allocated to software as part of
system engineering are refined by establishing:
– A complete information description
– A detailed functional description
– A representation of system behavior
– An indication of performance requirements and design constraints
– Appropriate validation criteria and other information pertinent to
requirements.
The Information Description provides a detailed description of the problem that
the software must solve. Information content, flow, and structure are documented.
Hardware, software, and human interfaces are described (or external system
elements: and internal software functions.
A description of each function required to solve the problem is presented in the
Functional Description.
A processing narrative is provided for each function:
– Design constraints are stated and justified
– Performance characteristics are stated, and
– One or more diagrams are included to graphically represent the overall
structure of the software and interplay among software functions and other
system elements
The Behavioral Description section of the specification examines the operation of
the software as a consequence of external events and internally generated control
characteristics.
Validation Criteria is probably the most important and, ironically, the most often,
neglected section of the Software Requirements specification.
– How do we recognize a successful implementation?
– What classes of tests must be conducted to validate function, performance,
and constraints?
We neglect this section because completing it demands a thorough understanding
of software requirements-something that we often do not have at this stage.
Yet, specification of validation criteria acts as an implicit review of all other
requirements. It is essential that time and attention be given to this section.
Finally, the specification includes a Bibliography and Appendix.
Software Project Management (CS615)
106
© Copyright Virtual University of Pakistan
Software Project Management BIT715/Software Project Management CS615 book HANDOUTS in pdf
1
© Copyright Virtual University of Pakistan
LECTURE # 1
1. Introduction & Fundamentals
1.1 What is Management?
Basically, the management involves the following activities:
Planning- deciding what is to be done
Organizing- making arrangements
Staffing- selecting the right people for the job
Directing- giving instructions
Monitoring- checking on progress
Controlling- taking action to remedy hold-ups
Innovating- coming up with new solutions
Representing- liaising with users, etc.
1.2 What is Project Management?
Project Management is the art of maximizing the probability that a project
delivers its goals on Time, to Budget and at the required Quality.
The art of planning for the future has always been a human trait. In essence a
project can be captured on paper with a few simple elements: a start date, an end
date, the tasks that have to be carried out and when they should be finished, and
some idea of the resources (people, machines etc) that will be needed during the
course of the project.
Project management is the application of knowledge, skills, tools, and
techniques to project activities to meet project requirements. Project management
is accomplished through the use of the processes such as: initiating, planning,
executing, controlling, and closing. It is important to note that many of the
processes within project management are iterative in nature. This is in part due to
the existence of and the necessity for progressive elaboration in a project
throughout the project life cycle; i.e., the more you know about your project, the
better you are able to manage it.
Project management is also defined as a strategic competency that has successfully been
applied in such high profile projects as the construction of silk root, organizing and managing the
Olympics Games, and the construction of Islamabad-Lahore motorway, just to name a few. If
project management can play a major role in these success stories, just imagine what it might be
able to do for your own organization.
The term project management is sometimes used to describe an organizational
approach to the management of ongoing operations. This approach, more properly
called management by projects, treats many aspects of ongoing operations as
projects to apply project management techniques to them.
Software Project Management (CS615)
2
© Copyright Virtual University of Pakistan
Almost any human activity that involves carrying out a non- repetitive task
can be a project. So we are all project managers! We all practice project
management (PM). But there is a big difference between carrying out a very
simple project involving one or two people and one involving a complex mix of
people, organizations and tasks.
1.3 What is Software Project Management?
When the plan starts to involve different things happening at different times, some
of which are dependent on each other, plus resources required at different times
and in different quantities and perhaps working at different rates, the paper plan
could start to cover a vast area and be unreadable.
Nevertheless, the idea that complex plans could be analyzed by a computer to
allow someone to control a project is the basis of much of the development in
technology that now allows projects of any size and complexity, not only to be
planned, but also modeled to answer 'what if?' questions.
The original programs and computers tended to produce answers long after an
event had taken place. Now, there are many project planning and scheduling
programs that can provide real time information, as well as linking to risk
analysis, time recording, and costing, estimating and other aspects of project
control.
But computer programs are not project management: they are tools for
project managers to use. Project management is all that mix of components of
control, leadership, teamwork, resource management etc that goes into a
successful project.
Project managers can be found in all industries. Their numbers have grown
rapidly as industry and commerce has realized that much of what it does is project
work. And as project-based organizations have started to emerge, project
management is becoming established as both a professional career path and a way
of controlling business.
So opportunities in project management now exist not only in being a project
manager, but also as part of the support team in a project or program office or as a
team leader for part of a project. There are also qualifications that can be attained
through the professional associations.
Software Project Management (CS615)
3
© Copyright Virtual University of Pakistan
1.4 What is a Project?
A project is an activity with specific goals which takes place over a finite
period of time.
“A temporary organization that is needed to produce a unique and pre-defined
outcome or result at a pre-specified time using pre-determined resources”
Projects are often implemented as a means of achieving an organization’s
strategic plan. Operations and projects differ primarily in that operations are
ongoing and repetitive while projects are temporary and unique. A project can
thus be defined in terms of its distinctive characteristics—a project is a temporary
endeavor undertaken to create a unique product or service. Temporary means
that every project has a definite beginning and a definite end. Unique means that
the product or service is different in some distinguishing way from all other
products or services. For many organizations, projects are a means to respond to
those requests that cannot be addressed within the organization’s normal
operational limits.
Projects are undertaken at all levels of the organization. They may involve a
single person or many thousands. Their duration ranges from a few weeks to more
than five years. Projects may involve a single unit of one organization or may
cross organizational boundaries, as in joint ventures and partnering.
Examples of projects include:
• Developing a new product or service.
• Effecting a change in structure, staffing, or style of an organization.
• Designing a new transportation vehicle.
• Developing or acquiring a new or modified information system.
• Constructing a building or facility.
• Building a water system for a community in a developing country.
• Running a campaign for political office.
• Implementing a new business procedure or process.
1. Temporary
Temporary means that every project has a definite beginning and a definite end.
The end is reached when the project’s objectives have been achieved, or it
becomes clear that the project objectives will not or cannot be met, or the need for
the project no longer exists and the project is terminated. Temporary does not
necessarily mean short in duration; many projects last for several years. In every
case, however, the duration of a project is finite; projects are not ongoing efforts.
2. Unique, Product Service or Result
Projects involve creating something that has not been done in exactly the same
way before and which is, therefore, unique and distinct. Projects create:
Software Project Management (CS615)
4
© Copyright Virtual University of Pakistan
• A product or artifact that is produced, is quantifiable and can be either an
end item in itself or a component item
• A capability to perform a service, such as business functions supporting
production or distribution
• A result, such as new knowledge. For example, a research and
development project develops knowledge that can be used to determine
whether or not a trend is present or a new process will benefit society.
The presence of repetitive elements does not change the fundamental uniqueness
of the project work. For example:
• A project to develop a new commercial airliner may require multiple
proto-types.
• A project to bring a new drug to market may require thousands of doses of
the drug to support clinical trials.
• A real estate development project may include hundreds of individual
units.
• A development project (e.g., water and sanitation) may be implemented in
five geographic areas.
3. Aims/Tasks/Purpose
The projects are designed to achieve specific targets defined in terms of aims,
tasks or a purpose. The nature and size of the project depends upon
complexity of the task, realization of the aims and scope of the purpose any
organization wants to achieve. In short project has to be aimed for achieving
certain tasks in a given time frame.
4. Limited Time Scale
The projects are always designed considering time constraints. Extension to
the project completion dead lines are always discouraged as time overrun,
costs extra and in some cases opportunity cost for not completing a project is
too high.
Progressive, Elaboration
Progressive elaboration is a characteristic of projects that accompanies the
concepts of temporary and unique. “Progressively” means developing thoroughly
in steps, and continuing steadily by increments while elaborated means “worked
out with care and detail; developed thoroughly”
For example, the project scope will be broadly described early in the project, and
made more explicit and detailed as the project team develops a better and more
complete understanding of the objectives and deliverables.
Progressive elaboration of project specifications must be carefully coordinated
with proper project scope definition, particularly if the project is performed under
contract. When properly defined, the scope of the project—the work to be done—
Software Project Management (CS615)
5
© Copyright Virtual University of Pakistan
should be controlled as the project and product specifications are progressively
elaborated.
The following examples illustrate progressive elaboration in two different
application areas.
Example 1. Development of a chemical processing plant begins with process
engineering to define the characteristics of the process. These characteristics are
used to design the major processing units. This information becomes the basis for
engineering design, which defines both the detail plant layout and the mechanical
characteristics of the process units and ancillary facilities. All of this results in
design drawings that are elaborated to produce fabrication and construction
drawings. During construction, interpretations and adaptations are made as
needed and subject to proper approval. This further elaboration of the deliverables
is captured in as-built drawings, and final operating adjustments are made during
testing and turnover.
Example 2. The product of an economic development project may initially be
defined as: “Improve the quality of life of the lowest income residents of
community X.” As the project proceeds, the products may be described more
specifically as, for example: “Provide access to food and water to 500 low income
residents in community X.” The next round of progressive elaboration might
focus exclusively on increasing agriculture production and marketing, with
provision of water deemed to be a secondary priority to be initiated once the
agricultural component is well under way.
Software Project Management (CS615)
6
© Copyright Virtual University of Pakistan
LECTURE # 2
1. Introduction & Fundamentals
1.5 Goals of Project management
Project management is the discipline of defining and achieving a set of goals
while optimizing the use of allocated resources (time, money, people, space,
etc). This includes planning, scheduling and maintaining progress of the
activities that comprise the project. Project management is normally reserved for
focused, non-repetitive, time-limited activities with some degree of risk and that
are beyond the usual scope of program (operational) activities for which the
organization is responsible.
Project management software describes the tools to efficiently coordinate and
automate the various project management component processes. Project
management software generally offers extensive reporting features, such as dayto-
day status updates of project progress, scheduling and dependency trees, and
system-generated alerts when schedules slip beyond pre-set tolerances. Most
project management tools include web-accessible interfaces so that employees
can access features of the software relevant to their needs, and functionality to
allow managers to share resource pools without overbooking.
1.6 Project Characteristics
1. Temporary
Temporary means that every project has a definite beginning and a definite end.
The end is reached when the project’s objectives have been achieved, or it
becomes clear that the project objectives will not or cannot be met, or the need for
the project no longer exists and the project is terminated. Temporary does not
necessarily mean short in duration; many projects last for several years. In every
case, however, the duration of a project is finite; projects are not ongoing efforts.
2. Unique, Product Service or Result
Projects involve creating something that has not been done in exactly the same
way before and which is, therefore, unique and distinct. Projects create:
• A product or artifact that is produced, is quantifiable and can be either an
end item in itself or a component item
• A capability to perform a service, such as business functions supporting
production or distribution
Software Project Management (CS615)
7
© Copyright Virtual University of Pakistan
• A result, such as new knowledge. For example, a research and
development project develops knowledge that can be used to determine
whether or not a trend is present or a new process will benefit society.
The presence of repetitive elements does not change the fundamental uniqueness
of the project work. For example:
• A project to develop a new commercial airliner may require multiple
proto-types.
• A project to bring a new drug to market may require thousands of doses of
the drug to support clinical trials.
• A real estate development project may include hundreds of individual
units.
• A development project (e.g., water and sanitation) may be implemented in
five geographic areas.
5. Aims/Tasks/Purpose
The projects are designed to achieve specific targets defined in terms of aims,
tasks or a purpose. The nature and size of the project depends upon
complexity of the task, realization of the aims and scope of the purpose any
organization wants to achieve. In short project has to be aimed for achieving
certain tasks in a given time frame.
6. Limited Time Scale
The projects are always designed considering time constraints. Extension to
the project completion dead lines are always discouraged as time overrun,
costs extra and in some cases opportunity cost for not completing a project is
too high.
1.7 Four Project Dimensions
Software project management is an umbrella activity within software engineering.
It begins before any technical activity is initiated and continues throughout the
definition, development, and support of computer software.
Four P's have a substantial influence on software project management- people,
product, process, and project.
• People must be organized into effective teams, motivated to do high-quality
software work, and coordinated to achieve effective communication.
• The product requirements must be communicated from customer to
developer, partitioned (decomposed) into their constituent parts, and
positioned for work by the software team.
• The process must be adapted to the people and the problem. A common
process framework is selected, an appropriate software engineering paradigm
is applied, and a set of work tasks is chosen to get the job done.
Software Project Management (CS615)
8
© Copyright Virtual University of Pakistan
• The project must be organized in a manner that enables the software team to
succeed.
Effective software project management focuses on the four P’s: people, product,
process, and project. The order is not arbitrary. The manager who forgets that
software engineering work is an intensely human endeavor will never have
Success in project management. A manager who fails to encourage
comprehensive customer communication early in the evolution of a project risks
building an elegant solution for the wrong problem. The manager who pays little
attention to the process runs the risk of inserting competent technical methods and
tools into a vacuum. The manager who embarks without a solid project plan
jeopardizes the success of the product.
⇒ People
In a study published by the IEEE, the engineering vice presidents of three
major technology companies were asked the most important contributor to a
successful software project. They answered in the following way:
VP 1: I guess if you had to pick one thing out that is most important in our
environment. I’d say it’s not the tools that we use, it’s the people.
VP 2: The most important ingredient that was successful on this project was
having smart people…very little else matters in my opinion....The most
important thing you do for a project is selecting the staff...The success of the
software development organization is very, very much associated with the
ability to recruit good people.
VP 3: The only rule I have in management is to ensure I have good people –
real good people-and that I grow good people – and that I provide an
environment in which good people can produce.
Indeed, this is a compelling testimonial on the importance of people in the
software engineering process. And yet, all of us, from senior engineering vice
presidents to the lowliest practitioner, often take people for granted. Managers
argue (as the preceding group had) that people are primary, but their actions
sometimes belie their words. In this section we examine the players who
participate in the software process and the manner in which they are organized
to perform effective software engineering.
1. The Players
The software process (and every software project) is populated by players
who can be categorized into one of five constituencies:
1. Senior managers who define the business issues that often have
significant influence on the project.
Software Project Management (CS615)
9
© Copyright Virtual University of Pakistan
2. Project (technical) managers who must plan, motivate, organize,
and control the practitioners who do software work.
3. Practitioners who deliver the technical skills that are necessary to
engineer a product or application.
4. Customers who specify the requirements for the software to be
engineered and other stakeholders who have a peripheral interest in
the outcome.
2. End-users
Who interact with the software once it is released for production use.
Every software project is populated by people who fall within this
taxonomy. To be effective, the project team must be organized in a way
that maximizes each person’s skills and abilities. And that’s the job of the
team leader.
3. Team Leaders
Project management is a people-intensive activity, and for this reason,
competent practitioners often make poor team leaders. They simply don’t
have the right mix of people skills. And yet, as Edgemon states:
“unfortunately and all too frequently it seems, individuals just fall into a
project manager role and become accidental project managers.” [EDG95].
The cultivation of motivated, highly skilled software people has been
discussed since the 1960s (e.g., [COUBO] [WIT94} [DEM9B]). In fact,
the “people factor’ is so important that the Software Engineering Institute
has developed a people management capability maturity model (PMCMM),
“to enhance the readiness of software organizations to undertake
increasingly complex applications by helping to attract, grow, motivate,
deploy, and retain the talent needed to improve their software
development capability” [CUR94].
The people management maturity model defines the following key
practice areas for software people: recruiting, selection, performance
management, training, compensation, career development, organization
and work design, and team/culture development. Organizations that
achieve high levels of maturity in the people management area have a
higher likelihood of implementing effective software engineering
practices.
The PM-CMM is a companion to the software capability maturity model
that guides organizations in the creation of a mature software process.
⇒ The Process
Software Project Management (CS615)
10
© Copyright Virtual University of Pakistan
In a fascinating book that provides an economist’s view of software and
software engineering, Howard Baetjer. Jr, comments on the software process:
Software development is a social learning process. The process is a dialogue
in which the knowledge that must become the software is brought together and
embodied in the software. The process provides interaction between users and
designers: between users and evolving tools, and between designers and
evolving tools [technology] It is an iterative process in which the evolving tool
itself serves as the medium for communication, with each new round of the
dialogue eliciting more useful knowledge from the people involved.
When you build a product or system, it’s important to go through a series of
predictable steps – a road map that helps you create a timely, high-quality
result, The road map that you follow is called a ‘software process’ .
Software engineers and their managers adapt the process to their needs and
then follow it. In addition, the people who have ties defined by the process
requested the software play a role in the software process.
At a detailed level, the process that you adopt depends on the software you’re
building. One process might be appropriate for creating software for an
aircraft avionics system, while an entirely different process would be
indicated for the creation of a web site.
From the point of view of a software engineer, the work products are the
programs, documents and data produces as a consequence of the software
engineering activities defined by the process.
A software process provides the framework from which a comprehensive plan
for software development can be established.
A small number of framework activities are applicable to all software projects,
regardless of their size or complexity.
A number of different task sets-tasks, milestones, work products and; quality
assurance points-enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the project
team.
Finally, umbrella activities – such as software quality assurance, software
configuration management, and measurement – overlay the process model.
Umbrella activities are independent of anyone framework activity and occur
throughout the process.
Software Project Management (CS615)
11
© Copyright Virtual University of Pakistan
LECTURE # 3
1. Introduction & Fundamentals
1.8 Project Dimensions
⇒ Product and Technology
– The 80:20, rule was originated by Vilfredo Pareto, an Italian economist who
studies the distribution of wealth in a variety of countries around 1900. He
discovered a common phenomenon: about 80% of the wealth in most countries
was controlled by a consistent minority -- about 20% of the people. Pareto called
this a "predictable imbalance." His observation eventually became known as
either the "80:20 rule" or "Pareto's Principle."
The credit for adapting Pareto's economic observations to business goes to the
"Father of Total Quality Management," service quality consultant Joseph M.
Juran. In 1950, he published "The Quality Control Handbook," which first
recognized the applicability of the Pareto principle in the context of inventory
management, e.g.:
• 20% of the repair parts normally account for 80 percent of the total
inventory
• 80% of production volume usually comes from 20% of the producers
He subsequently recognized that this rule of thumb was universally applicable
across fields of endeavor. As a credit to Pareto's work, Juran named his finding
the Pareto Principle. This universal management theory became generalized as
"the 80-20 Rule":
The "80:20 rule" has become one of the best known "leadership shorthand terms"
reflecting the notion that most of the results (of a life, of a program, of a financial
campaign) come from a minority of effort (or people, or input).
The Rule, states that a small number of causes (20%) is responsible for a large
percentage (80%) of the effect. It means that in anything a few (20 percent) are
vital and many (80 percent) are trivial.
There is an inherent imbalance between cause and effect, effort and reward, inputs
and outputs, etc; and that imbalance tends to the ratio of 80:20. So, if we know
which 20% of our work produces 80% of our income, we can do more of it and
our income will increase proportionately!
Software Project Management (CS615)
12
© Copyright Virtual University of Pakistan
You know 20 percent of you stock takes up 80 percent of your warehouse space
and that 80 percent of your stock comes from 20 percent of your suppliers. Also
80 percent of your sales will come from 20 percent of your sales staff. 20 percent
of your staff will cause 80 percent of your problems, but another 20 percent of
your staff will provide 80 percent of your production. It works both ways.
Some Sample 80/20 Rule Applications
80% of process defects arise from 20% of the process issues.
20% of your sales force produces 80% of your company revenues.
80% of delays in schedule arise from 20% of the possible causes of the delays.
80% of customer complaints arise from 20% of your products or services.
How It Can Help You
– The value of the Pareto Principle for a manager is that it reminds you to focus on
the 20 percent that matters. Of the things you do during your day, only 20 percent
really matter. Those 20 percent produce 80 percent of your results. Identify and
Characteristic
focus on those things. When the fire drills of the day begin to sap your time,
remind yourself of the 20 percent you need to focus on. If something in the
schedule has to slip, if something isn't going to get done, make sure it's not part of
that 20 percent.
Pareto's Principle, the 80/20 Rule, should serve as a daily reminder to focus 80
percent of your time and energy on the 20 percent of you work that is really
important. Don't just "work smart", work smart on the right things.
– Size
The larger product, there will be more requirements and features to deliver,
eventually it will take more time in its production. So if you cut the size of the
produce to half it will save you 60% of the effort.
– Characteristic
– Development Tools
Software Project Management (CS615)
13
© Copyright Virtual University of Pakistan
Customer delivered value
1.9 Project Phases
Organizations performing projects will usually divide each project into several
Project phases to improve management control and provide for links to the
ongoing operations of the performing organization.
Collectively, the project phases are known as the project life cycle. Software
development, just like most other activities, has a beginning, middle and an end.
The end of one development activity is sometimes perceived as being linked to
the beginning of a new development activity thus producing a cycle of beginningmiddle-
end, link, beginning-middle-end, link, and so forth.
This view of software development is referred to as the software development
life cycle.
A project has five phases. Here's a brief summary of each:
⇒ Initiation
Articulate your vision for the project, establish goals, assemble your team,
and define expectations and the scope of your project.
⇒ Planning
Refine the scope, identify specific tasks and activities to be completed,
and develop a schedule and budget.
⇒ Executing
Accomplish your goals by leading your team, solving problems, and
building your project.
Value of products
Value of services
Financial cost
Personal value
Psychical cost
Image value
Time cost
Real value to
the customer
Total value
Total costs
Energy cost
+
-
Software Project Management (CS615)
14
© Copyright Virtual University of Pakistan
⇒ Controlling
Monitor changes to the project make corrections, adjust your schedule to
respond to problems, or adjust your expectations and goals.
⇒ Closing
Deliver your project to your audience, acknowledge results, and assess its
success. Take the time to compose a written evaluation of the project and
the development effort.
The middle three phases are not sequential. You will find that you are constantly
planning, executing, and controlling your project as necessary.
Aren't these phases really just common sense? In many ways, yes, but keep in
mind that software development, whether a few Web pages or a complex CDROM,
is a complex, unpredictable process.
Most software projects (something like 80 percent) are delivered late,
substantially over budget, and incomplete. The more effort you put into managing
your project, the more you increase your chances of success.
– Characteristics of Project Phases
Each project phase is marked by completion of one or more deliverables. A
deliverable is a tangible, verifiable work product such as a feasibility study, a
detail design, or a working prototype. The deliverables, and hence the phases, are
part of a generally sequential logic designed to ensure proper definition of the
product of the project.
The conclusion of a project phase is generally marked by a review of both key
deliverables and project performance to date, to a) determine if the project should
continue into its next phase and b) detect and correct errors cost effectively. These
phase-end reviews are often called phase exits, stage gates, or kill points.
Each project phase normally includes a set of defined deliverables designed to
establish the desired level of management control. The majority of these items are
related to the primary phase deliverable, and the phases typically take their names
from these items: requirements, design, build, test, startup, turnover, and others,
as appropriate.
– Characteristics of the Project Life Cycle
The project life cycle serves to define the beginning and the end of a project. For
example, when an organization identifies an opportunity to which it would like to
respond, it will often authorize a needs assessment and/or a feasibility study to
decide if it should undertake a project. The project life-cycle definition will
determine whether the feasibility study is treated as the first project phase or as a
separate, standalone project.
Software Project Management (CS615)
15
© Copyright Virtual University of Pakistan
The project life-cycle definition will also determine which transitional actions at
the beginning and the end of the project are included and which are not. In this
manner, the project life-cycle definition can be used to link the project to the
ongoing operations of the performing organization.
The phase sequence defined by most project life cycles generally involves some
form of technology transfer or handoff such as requirements to design,
construction to operations, or design to manufacturing. Deliverables from the
preceding phase are usually approved before work starts on the next phase.
However, a subsequent phase is sometimes begun prior to approval of the
previous phase deliverables when the risks involved are deemed acceptable. This
practice of overlapping phases is often called fast tracking.
Project life cycles generally define:
What technical work should be done in each phase (e.g., is the work of the
architect part of the definition phase or part of the execution phase?).
Who should be involved in each phase (e.g., implementers who need to be
involved with requirements and design).
Project life-cycle descriptions may be very general or very detailed. Highly
detailed descriptions may have numerous forms, charts, and checklists to
provide structure and consistency. Such detailed approaches are often called
project management methodologies.
Most project life-cycle descriptions share a number of common
characteristics:
Cost and staffing levels are low at the start, higher toward the end, and drop
rapidly as the project draws to a conclusion.
The probability of successfully completing the project is lowest, and hence
risk and uncertainty are highest, at the start of the project. The probability of
successful completion generally gets progressively higher as the project
continues.
The ability of the stakeholders to influence the final characteristics of the
project’s product and the final cost of the project is highest at the start and
gets progressively lower as the project continues. A major contributor to this
phenomenon is that the cost of changes and error correction generally
increases as the project continues.
Care should be taken to distinguish the project life cycle from the product life
cycle. For example, a project undertaken to bring a new desktop computer to
market is but one phase or stage of the product life cycle.
Although many project life cycles have similar phase names with similar
deliverables required, few are identical. Most have four or five phases, but some
Software Project Management (CS615)
16
© Copyright Virtual University of Pakistan
have nine or more. Even within a single application area, there can be significant
variations.
One organization’s software development life cycle may have a single design
phase while another’s has separate phases for functional and detail design.
Subprojects within projects may also have distinct project life cycles. For
example, an architectural firm hired to design a new office building is first
involved in the owner’s definition phase when doing the design, and in the
owner’s implementation phase when supporting the construction effort. The
architect’s design project, however, will have its own series of phases from
conceptual development through definition and implementation to closure. The
architect may even treat designing the facility and supporting the construction as
separate projects with their own distinct phases.
– Project Life Cycle includes the following Phases and activities:
A. Concept Phase
1. User Need
2. Initial Investigation
3. User Review
4. System Performance Design
5. Candidate Review
6. Study Phase Report
B. Requirements Phase
1. The software requirements specification document
2. The project development plan
3. The software test plan
C. Design Phase
1. General System Review
2. Processing Requirements Identification
3. Data Base Design
4. Control Requirements
5. Output Design
6. Input Design
7. Software Selection
8. Equipment Selection/Acquisition
9. People
10. Reference Manual Identification
11. Plans
12. Design Specifications Preparation
13. Design Phase Report Preparation
D. Development Phase
Software Project Management (CS615)
17
© Copyright Virtual University of Pakistan
1. Implementation Planning
2. Computer Program Design
3. User Review
4. Equipment Acquisition and Installation
5. Coding and Debugging
6. Computer Program Testing
7. System Testing
8. Reference Manual Preparation
9. Personnel Training
10. Changeover Plan Preparation
11. Development Phase Report Preparation
12. User Acceptance Review
E. Operation Phase
1. System Changeover
2. Routine Operation
3. System Performance Evaluation
4. System Changes/Enhancements
1.10 Software Development Lifecycle
⇒ Water Fall Theme
Software development, just like most other activities, has a beginning, middle and
an end. The end of one development activity is sometimes perceived as being
linked to the beginning of a new development activity thus producing a cycle of
beginning-middle-end, link, beginning-middle-end, link, and so forth. This view
of software development is referred to as the software development life cycle.
There are many variations of the software development life cycle. Figure 1
presents a simple life cycle that was common during the first few decades of
software development. In those early days of software development, the
programmer would create programs by iterating from code to fix then back to
code, and then to fix again, until something acceptable was (hopefully) produced.
At the start of the cycle, there was usually no clear concept of what was required,
and the basic development procedure was a form of 'let's see what we can do'
approach.
The software development method represented by the development cycle in Fig.1
is often referred to as the code and fix method (for obvious reasons). Software
development methodologies have come a long way since the days of code and fix,
though it is surprising how much software is still being developed this way.
Successful management of any project, especially software projects, requires
planning, and planning is impossible with code and fix, which is totally
unpredictable. Management of software development within an engineering
Software Project Management (CS615)
18
© Copyright Virtual University of Pakistan
discipline is based on a much more orderly set of development phases. These
phases are not implemented solely by programmers; they require software
engineers. In fact, programming has become a relatively small part of the modern
software development cycle, as is evident from Table 1.
The numbers in Table 1 are derived from the general shift in emphasis to software
planning (requirements and design) and testing. Commercial data processing
systems, with some exceptions, still spend a significant amount of development
time in the programming and unit testing phase. Real-time systems are often more
complex, and may include extensive hardware software integration. This usually
requires more planning and more integration and testing.
Figure 1: the code and fix method
Table 1 Estimated percentage of time spent in each major software development phase
Planning Code and unit test Integration and test
Commercial data processing 25% 40% 35%
Real-time systems 35% 25% 40%
Military systems 40% 20% 40%
Military systems require high reliability and are usually closely supervised by the
customer, leading to a significant increase in the time spent in planning.
The data in Table 1, of course, represents a generalization; commercial data
processing systems can be just as complex as a real-time system.
Figure 2 presents the basic phased model of a software development cycle. This
model, called the Waterfall model, gets its name from the way in which each
phase cascades into the next (due to overlapping), as demonstrated in Fig. 3.
Some interpretations of the Waterfall model, like the one that follows, combine
the top level design and the detailed design phases into a single design phase, and
the integration and test phases into a single phase. In fact, there are many
variations of the classic Waterfall model, but they are all based upon a systematic
transition from one development phase to the next, until the project is complete.
Concept Code Fix Test
Maintain
Software Project Management (CS615)
19
© Copyright Virtual University of Pakistan
Conception
Maintenance Software
Requirements
Test
Top level
Design
Integration Detailed
Design
Implementation
Figure 2: The phased model of the software development life cycle
Conception
Software requirements
Top level" design
Detailed design
Implementation
Integration
Test
Maintenance
T
Figure 3: The Waterfall model of the software development life cycle
⇒ Rapid prototyping There are other development methodologies that do not move
from one phase to the next like the Waterfall model. Rapid prototyping, for
Software Project Management (CS615)
20
© Copyright Virtual University of Pakistan
instance, iterates in a mini-development phase until a system prototype is
developed (see Fig. 4). After the prototype is complete, the Waterfall approach
can then be implemented to complete the full system. Rapid prototyping is
particularly helpful in projects where the requirements are difficult to specify. The
prototype can be used as a tool for analyzing and determining what the
requirements should be.
⇒ The Spiral model, described by Boehm (1988), is another development method
that iterates between the requirements, design and implementation phases.
However, the Spiral model continues iterating until the final system is complete.
Within each, iteration, the Spiral model follows a phased approach similar to the
Waterfall model.
Different models maybe suitable for different software projects or for different
software development organizations However, a good model must include certain
fundamental features. Some of these basic requirements are discussed in IEEE
Standard (IEEE 1993) Standard for Software Life Cycle Processes. This standard
describes the processes that are mandatory for the development of software and
specifies the activities that must be included in the life cycle model.
Most modern software development models, and certainly those following IEEE
Standard 1074, include some form of the basic phased model. It is therefore
important to understand the different phases and how they relate to one another.
Concept Prototype Requirements Design Implementation Test
The rapid prototyping cycle
Figure 4: Rapid prototyping followed by the phase method.
Software Project Management (CS615)
21
© Copyright Virtual University of Pakistan
LECTURE # 4
1. Introduction & Fundamentals
1.11 Costs and Cost Management
Project Cost Management includes the processes required to ensure that the
project is completed within the approved budget.
⇒ Resource Planning—determining what resources (people, equipment,
materials and what quantities of each should be used to perform project
activities.
⇒ Cost Estimating—developing an approximation (estimate) of the costs of
the resources needed to complete project activities.
⇒ Cost Budgeting—allocating the overall cost estimate to individual work
activities.
⇒ Cost Control—controlling changes to the project budget.
These processes interact with each other and with the processes in the other
knowledge areas as well.
Each process may involve effort from one or more individuals or groups of
individuals, based on the needs of the project.
Each process generally occurs at least once in every project phase.
Although the processes are presented here as discrete elements with well-defined
interfaces, in practice they may overlap and interact in ways not detailed here.
Project cost management is primarily concerned with the cost of the resources
needed to complete project activities.
However, project cost management should also consider the effect of project
decisions on the cost of using the project’s product.
For example, limiting the number of design reviews may reduce the cost of the
project at the expense of an increase in the customer’s operating costs. This
broader view of project cost management is often called life-cycle costing. Lifecycle
costing together with Value Engineering techniques are used to reduce cost
and time, improve quality and performance, and optimize the decision-making.
In many application areas, predicting and analyzing the prospective financial
performance of the project’s product is done outside the project.
Software Project Management (CS615)
22
© Copyright Virtual University of Pakistan
In others (e.g., capital facilities projects), project cost management also includes
this work. When such predictions and analyses are included, project cost
management will include additional processes and numerous general management
techniques such as return on investment, discounted cash flow, payback analysis,
and others.
Project cost management should consider the information needs of the project
stakeholders—different stakeholders may measure project costs in different ways
and at different times. For example, the cost of a procurement item may be
measured when committed, ordered, delivered, incurred, or recorded for
accounting purposes.
1.12 Project vs. Program Management
⇒ What is a Program?
“A coordinated portfolio of projects that change organizations to achieve benefits
of strategic importance”
Program management is the process of managing multiple on
going projects. An example would be that of designing, manufacturing and
providing support infrastructure for an automobile make.
It can be argued that Program Management has evolved from the complexities of
the more intricate aspects of Project Management.
As projects became larger; more interrelated; complex and multidimensional, the
need arose to have an approach that controlled Project Management whilst
remaining focused on the strategic objectives of the business. Whilst Project
Management focused on technical delivery, Program Management engaged on
relating design concepts to the business strategic vision of the future.
It is very important that you understand the concept of Program Management as a
method. Approaches may vary but definitions are relatively common. It is
appropriate to understand the ‘mission, goals and objectives’ of Program
Management and then relate these to the Program you propose to develop.
Definitions will fall within each of these headings and it is possible to develop
your own template which fits your organizational program. For example:
– Mission:
To co-ordinate a portfolio of projects to harmonize communications in
order to achieve a set of stated business objectives: Provision of strategy
alignment, with design objectives, in order to maintain control over a
Software Project Management (CS615)
23
© Copyright Virtual University of Pakistan
multiple project environment; ensuring quality end deliverables which
meet business operational needs.
The above is a fairly complex mission statement but provides a framework
to develop an intricate set of goals in order to utilize Program
Management. It is possible to develop an extensive list of goals,
depending upon the level of detail you wish to acquire. The following are
offered as suggestions:
– Goals:
1. Clearly defined roles and responsibilities
2. Established baselines and Terms of Reference statement
3. Type of program defined
4. Future business blueprint
5. Recognition of business transformation procedures
6. Defined structure of the Program
7. Route Map
8. Visible end deliverables — vision of the future
9. Identification of future benefits
10. Risk
11. Contingency planning
Software Project Management (CS615)
24
© Copyright Virtual University of Pakistan
Each of the goals would then be analyzed for providing objectives. For example:
• Managing a program embraces functions, risks and strategies outside of what a
project manager does.
• A program has goals beyond those of a project or group of projects. Program
outcomes are usually service delivery focused whereas a project is more likely
to be focused on the delivery of a 'product'.
• A program is more than a grouping of projects (that's just a program of works).
• The coordinated management of a portfolio of projects to achieve a set of
business objectives
• There are many more meanings of the term program management. Here are the
more common meanings:
– The Multi-Project Organization:
Program Management is the directing of a portfolio of projects that benefit
from a consolidated approach.
Jobbing engineering companies; software houses contracting for work; and
many other types of organization; run many simultaneous projects each of
which may or not contribute towards the corporate goals.
Typically the result of such a project is a deliverable which is eventually
delivered to a client for payment. After many delays the payment arrives and
Software Project Management (CS615)
25
© Copyright Virtual University of Pakistan
gets paid into the company’s bank account thereby increasing cash flow which
is achieving one of the company’s objectives.
Sometimes the projects are much more directly aimed at corporate goals -
opening a new factory or launching a new product - spring to mind.
The common elements of the projects are that they run simultaneously or at
least overlap with each other, they share resources and are supposed to
generate some income. One project being cancelled does not necessarily
change the organization’s general direction. These types of programs run for
ever and need have no end date. The projects are separate in that there need
not be logical links between projects. Whilst they share the same resources,
delays in one project need not cause delays in others.
– The Mega Project
The management of a portfolio of projects towards one specific objective;
Program management can also mean one very large project.
The USA’s Man on the Moon Project was such a program. In this sense the
term program indicates one very large project which is made up from a
number of components. Within the Apollo program there were many projects:
the Lunar Lander, the Orbiter, the Launcher and the Control Systems were all
projects which were large, complex and interesting. Polaris and the
Manhattan project (which resulted in the nuclear bomb) are other famous
projects large enough to be called programs. Therefore, particularly in USA,
the word program refers to a series of projects which make up one large
project.
The program is usually reflected in the management structure as there will be
a program manager to whom the project managers will report. Said program
manager or sometimes program director will concern himself with recruiting
and maintaining his project management teams and on integrating the
deliverables of each project into one overall program. In this meaning of
program management there is likely to be one physical deliverable.
These sorts of programs end. There will be a time when the overall objective
has been achieved and the program and all of its constituent projects are over.
The projects within this type of program are often linked. Delays with one
project often cause knock on effects with others due to logical links between
tasks in both projects.
For example if the moon rocket launch pad project was delayed, it would
delay the testing of the moon rocket itself. The Beirut Shopping Mall will be
of little use without the water treatment plant and the new sewer scheme. Such
Software Project Management (CS615)
26
© Copyright Virtual University of Pakistan
projects may not share the same resources but there are almost certain to be
linked through their logic.
1.13 Project Success
Project success is correlated with thorough analyses of the need for project
deliverables. Our research has shown that when a project results in deliverables
that are designed to meet a thoroughly documented need, then there is a greater
likelihood of project success. So managers should insist that there is a
documented business need for the project before they agree to consume
organizational resources in completing it.
We conduct planned and controlled software projects for one primary reason - it
is the only known way to manage complexity. And yet, we still struggle. In 1998,
industry data indicated that 26 percent of software projects failed outright and 46
percent experienced cost and schedule overruns [REE99].
Although the success rate for software projects has improved somewhat, our
project failure rate remains higher than it should be.
In order to avoid project failure, a software project manager and the software
engineers who build the product must avoid a set of common warning signs,
understand the critical success factors that lead to good project management, and
develop a common sense approach for planning, monitoring and controlling the
project.
In order to manage a successful software project, we must understand what can go
wrong (so that problems can be avoided) and how to do it right. In an excellent
paper on software projects, John Reel [REE99] defines ten signs that indicate that
an information systems project is in jeopardy:
1. Software people don't understand their customer's needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs change (or are ill-defined)
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost [or was never properly obtained).
9. The project team lacks people with appropriate skills.
10. Managers [and practitioners) avoid best practices and lessons learned.
Jaded industry professionals often refer to the 90-90 rule when discussing
particularly difficult software projects: The first 90 percent of a system absorbs 90
percent of the allotted effort and time. The last 10 percent takes the other 90
Software Project Management (CS615)
27
© Copyright Virtual University of Pakistan
percent of the allotted effort and time [ZAH94]. The seeds that lead to the 90-90
rule are contained in the signs noted in the preceding list.
But enough negativity! How does a manager act to avoid the problems just noted?
Reel [REE99] suggests a five-part commonsense approach to software projects:
1. Start on the right foot. This is accomplished by working hard (very hard)
to understand the problem that is to be solved and then setting realistic
objects and expectations for everyone who will be involved in the project.
It is reinforced by building the right team (Section 3.2.3) and giving the
team the autonomy, authority, and technology needed to do the job.
2. Maintain momentum. Many projects get off to a good start and then
slowly disintegrate. To maintain momentum, the project manager must
provide incentives to keep turnover of personnel to an absolute minimum,
the team should emphasize quality in every task it performs, and senior
management should do everything possible to stay out of (the team's way.
3. Track progress. For a software project, progress is tracked as work
products (e.g., specifications, source code, sets of test cases) are produced
and approved (using formal technical reviews) as part of a quality
assurance activation, software process and project measures can be
collected and used to assess progress against averages developed for the
software development organization.
4. Make smart decisions. In essence, the decisions of the project manager
and the software team should be to "keep it simple.” Whenever possible,
decide to use commercial off-the-shelf software or existing software
components, decide to avoid custom interfaces when standard approaches
are available, decide to identify and then avoid obvious risks, and decide
to allocate more time than you think is needed to complex or risky tasks
(you'll need every minute).
5. Conduct a postmortem analysis. Establish a consistent mechanism for
extracting lessons learned for each project. Evaluate the planned and
actual schedules, collect and analyze software project metrics, get
feedback from team members and customers, and record findings in
written form.
– Projects and Strategy
Projects are a means of organizing activities that cannot be addressed
within the organization’s normal operational limits.
Projects are therefore often utilized as a means of achieving an
organization’s strategic plan, whether the project team is employed by the
organization or is a contracted service provider.
Projects are typically authorized as a result of one or more of the
following strategic considerations:
Software Project Management (CS615)
28
© Copyright Virtual University of Pakistan
A market demand (e.g., an oil company authorizes a project to build a
new refinery in response to chronic gasoline shortages)
A business need (e.g., a training company authorizes a project to create a
new course in order to increase its revenues)
A customer request (e.g., an electric utility authorizes a project to build a
new substation to serve a new industrial park)
A technological advance (e.g., an electronics firm authorizes a new
project to develop a new generation of video game player after the
introduction of the corresponding new game format)
A legal requirement (e.g., a paint manufacturer authorizes a project to
establish guidelines for the handling of a new toxic material).
No project ever goes 100% as planned, so project managers must learn to adapt to
change. There are many things that can go wrong with project management.
These are commonly called barriers. Here are some possible barriers:
1. Poor Communication
– Many times a project may fail because the project team does not
know exactly what to get done or what's already been done.
2. Disagreement
– Project must meet all elements in a contract.
– Customer and project manager must agree on numerous
elements.
– Failure to comply with standards and regulations.
– Inclement weather.
– Union strikes.
– Personality conflicts.
– Poor management
3. Poorly defined project goals
1.14 Trade-Off Triangle
Good project management deals with three factors: time, cost and
performance.
Projects are successful if they are completed on time, within budget, and to
performance requirements. In order to bring the many components of a large
project into control there is a large toolkit of techniques, methodologies, and
tools.
Software Project Management (CS615)
29
© Copyright Virtual University of Pakistan
These techniques provide the tools for managing different components
involved in a project: planning and scheduling, developing a product;
managing financial and capital resources, and monitoring progress. However
the success of a project will always rest on the abilities of a project manager
and the team members.
In managing competing project requirements Project managers often talk of a
triple constraint:
– Project scope
– Time and
– Cost
Project quality is affected by balancing these three factors.
High quality projects deliver the required product or service within scope, on
time and within budget.
The relationship among these factors is such that if any one of the three
factors changes, at least one other factor must change.
Simply put: project success means completing all project deliverables on time,
within budget, and to a level of quality that is acceptable to sponsors and
stakeholders.
The project manager must keep the team's attention focused on achieving
these broad goals. Most people still want their projects to be on time, meet
quality objectives, and not cost more than the budget. These form the classic
time, quality, cost triangle.
In fact if you have an unlimited budget and unlimited time, project
management becomes rather easy. For most people, however, time and money
are critical and that is what makes project management so important today.
Project management is often summarized in a triangle. The three most
important factors are time, cost and scope. These form the vertices with
quality as a central theme.
Software Project Management (CS615)
30
© Copyright Virtual University of Pakistan
1. Projects must be delivered on time.
2. Projects must be within cost
3. Projects must be within scope
4. Projects must meet customer quality requirements
More recently, this has given way to a project management diamond, with
time, cost, scope and quality the four vertices and customer expectations as a
central theme. No two customers' expectations are the same so you must ask
what their expectations are.
A project goes through four phases during its life:
1. Project Definition: Defining the goals, objectives and critical success
factors for the project
2. Project Initiation: Everything that is needed to set-up the project before
work can start
3. Project Control: Ensuring that a project stays on track and taking
appropriate action to ensure it does
4. Project Closure: Disbanding of all the elements that were required to run
the project
Software Project Management (CS615)
31
© Copyright Virtual University of Pakistan
1.15 Project Management Skills
The role of the Leader in project management is one of great responsibility.
It's the project manager's job to direct and supervise the project from
beginning to end. Here are some other roles:
(a) Leadership
(b) Communications
(c) Problem Solving
(d) Negotiating
(e) Influencing the Organization
(f) Mentoring
(g) Process and technical expertise
(a) Leadership
Leadership is a complex phenomenon involving the leader, the followers,
and the situation. Perhaps the best way for you to begin to understand the
complexities of leadership is to see some of the ways leadership has been
defined. Leadership researchers have defined leadership in the following
different ways:
The creative and directive force of morale. (Munson, 1921)
The process by which an agent induces a subordinate to behave in a
desired manner. (Bennis, 1959)
The presence of a particular influence relationship between two or
more persons. (Hollander & Julian, 1969)
Directing and coordinating the work of group members. (Fiedler,
1967) An interpersonal relation in which others comply because they
want to, not because they have to. (Merton, 1969; Hogan, Curphy, &
Hogan, 1994)
Transforming followers, creating visions of the goals that may be
attained, and articulating for the followers the ways to attain those
goals. (Bass, 1985; Fichy & Devanna, 1986)
The process of influencing an organized group toward accomplishing
its goals. (Roach & Behling, 1984)
Actions that focus resources to create desirable opportunities.
(Campbell, 1991)
Software Project Management (CS615)
32
© Copyright Virtual University of Pakistan
The leader's job is to create conditions for the team to be effective.
(Ginnett, 1996)
Leading and managing are both essential management skills: one
without the other is likely to produce poor results. Managing is primarily
concerned with “consistently producing key results expected by
stakeholders,” while leading involves:
Establishing direction—developing both a vision of the future and
strategies for producing the changes needed to achieve that vision.
Aligning people—communicating the vision by words and deeds to
all those, whose cooperation may be needed to achieve the vision.
Motivating and inspiring—helping people energize themselves to
overcome political, bureaucratic, and resource barriers to change.
On a project, particularly a larger project, the project manager is generally
expected to be the project’s leader as well.
Leadership is not, however, limited to the project manager: it may be
demonstrated by many different individuals at many different times during
the project.
Leadership must be demonstrated at all levels of the project (project
leadership, technical leadership, and team leadership).
(b) Communicating
Communicating involves the exchange of information and the ability to
transmit and receive information with a high probability that the intended
message is passed from sender to receiver.
The sender is responsible for making the information clear, unambiguous,
and complete so that the receiver can receive it correctly. The receiver is
responsible for making sure that the information is received in its entirety
and understood correctly.
Few skills are more vital to leadership. Studies show that good leaders
communicate feelings and ideas, actively solicit new ideas from others,
and effectively articulate arguments, advocate positions, and persuade
others.
The quality of a Leader’s communication is positively correlated with
subordinate satisfaction as well as with productivity and quality of
services rendered.
Software Project Management (CS615)
33
© Copyright Virtual University of Pakistan
Effective communication skills are also important because they provide
leaders and followers with greater access to information relevant to
important organizational decisions.
Communicating has many dimensions:
– Written and oral, listening and speaking
– Internal (within the project) and external (to the customer, the
media, the public, etc.).
– Formal (reports, briefings, etc.) and informal (memos, ad hoc
conversations, etc.)
– Vertical (up and down the organization) and horizontal (with peers
and partner organization)
The general management skill of communicating is related to, but not the
same as, Project Communications Management.
Communicating is the broader subject and involves a substantial body of
knowledge that is not unique to the project context, for example:
– Sender-receiver models—feedback loops, barriers to
communications, etc.
– Choice of media—when to communicate in writing, when to
communicate orally, when to write an informal memo, when to
write a formal report, etc.
– Writing style—active versus passive voice, sentence structure,
word choice, etc.
– Presentation techniques—body language, design of visual aids,
etc.
– Meeting management techniques—preparing an agenda, dealing
with conflict, etc.
Project Communications Management is the application of these broad
concepts to the specific needs of a project—for example, deciding how;
when; in what form; and to whom to report project performance.
(c) Negotiating
Negotiating involves conferring with others to come to terms with them or
reach an agreement.
Agreements may be negotiated directly or with assistance; mediation and
arbitration are two types of assisted negotiation.
Negotiation is an approach that may help resolve some conflicts. Some
important tips on negotiation include; preparing for a negotiation session;
Software Project Management (CS615)
34
© Copyright Virtual University of Pakistan
keeping people and problems separate; focusing on issues, not positions
and seeking win-win outcomes.
Negotiations occur around many issues, at many times, and at many levels
of the project.
During the course of a typical project, project staff is likely to negotiate
for any or all of the following:
• Scope, cost, and schedule objectives.
• Changes to scope, cost, or schedule.
• Contract terms and conditions.
• Assignments.
• Resources.
(d) Problem Solving
There are three steps involved in this important leadership role; identifying
problem; analyzing its cause; and solving the problem.
Problem solving involves a combination of problem definition and
decision-making.
Problem definition requires distinguishing between causes and symptoms.
Problems may be:
– Internal (a key employee is reassigned to another project)
– External (a permit required to begin work is delayed).
– Technical (differences of opinion about the best way to design a
product)
– Managerial (a functional group is not producing according to
plan) or
– Interpersonal (personality or style clashes).
(e) Decision-making
Decision-making includes analyzing the problem to identify viable
solutions, and then making a choice from among them.
Decisions can be made or obtained (from the customer, from the team, or
from a functional manager).
Once made, decisions must be implemented.
Decisions also have a time element to them—the “right” decision may not
be the “best” decision if it is made too early or too late.
Software Project Management (CS615)
35
© Copyright Virtual University of Pakistan
(f) Influencing the Organization
Influencing the organization involves the ability to “get things done.”
It requires an understanding of both the formal and informal structures of
all the organizations involved—the performing organization, customer,
partners, contractors, and numerous others, as appropriate.
Influencing the organization also requires an understanding of the
mechanics of power and politics.
Both power and politics are used here in their positive senses.
Power is “the potential ability to influence behavior, to change the course
of events, to overcome resistance, and to get people to do things that they
would not otherwise do.”
In similar fashion, “politics is about getting collective action from a group
of people who may have quite different interests. It is about being willing
to use conflict and disorder creatively.
The negative sense, of course, derives from the fact that attempts to
reconcile these interests result in power struggles and organizational
games that can sometimes take on a thoroughly unproductive life of their
own.”
Influence can be exercised in a: variety of ways. It may be the 'bridge to
engine room' approach, where the leader commands and controls. Or the
influence can be exercised by guiding and facilitating the group's behavior
so that the goal is accomplished.
Finally, leadership implies that a leader motivates the group to spend
energy in attaining the goals of the group.
Influence without change or movement isn’t influence. Leaders make
change happen, a difficult but vitally important task.
(g) Mentoring
Mentoring or being a Transformational leadership is more concerned with
engagement between leaders and followers.
Leaders attempt to engage the full person of the subordinate and enthuse
them. They arouse in their subordinates a heightened awareness of the key
issues for the group or the organization. They seek to concern subordinates
with achievement, growth and development.
Software Project Management (CS615)
36
© Copyright Virtual University of Pakistan
Creating a new vision is something that almost all writers on
transformational leadership emphasize.
The vision points the way to a new state of affairs. It is an appealing
picture of a more desirable future. It inspires people to believe that the
future is worth the upheaval of undoing the present.
A vision needs to be a source of self-esteem and a common purpose for
members of the organization.
(h) Technical Skills:
A project manager must have technical skills. This relates to financial
planning, contract management, and managing creative thinking and
problem solving techniques are promoted.
Software Project Management (CS615)
37
© Copyright Virtual University of Pakistan
LECTURE # 5
1. Introduction & Fundamentals
1.16 PM’s nine Knowledge Areas
1. Project Integration Management
Project Integration Management includes the processes required to ensure that the
various elements of the project are properly coordinated. It involves making
tradeoffs among competing objectives and alternatives to meet or exceed stakeholder
needs.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
Project integration management comes into play when a cost estimate is needed
for a contingency plan, or when risks associated with various staffing alternatives
must be identified. However, for a project to be completed successfully,
integration must also occur in a number of other areas as well. For example:
The work of the project must be integrated with the ongoing operations of the
performing organization.
Product scope and project scope must be integrated.
One of the techniques used to both integrate the various processes and to measure
the performance of the project as it moves from initiation through to completion is
Earned Value Management (EVM).
• Earned value is the amount of work completed, measured according to the
budgeted effort that the work was supposed to consume.
• It is also called the budgeted cost of work performed.
• As each task is completed, the number of person-months originally planned
for that task is added to the earned value of the project.
– Earned value charts: An earned value chart has three curves:
• The budgeted cost of the work scheduled.
• The earned value.
• The actual cost of the work performed so far.
2. Project Scope Management
Software Project Management (CS615)
38
© Copyright Virtual University of Pakistan
Project Scope Management includes the processes required to ensure that the
project includes all the work required, and only the work required, to complete the
project successfully. It is primarily concerned with defining and controlling what
is or is not included in the project.
The processes, tools, and techniques used to manage product scope vary by
application area and are usually defined as part of the project life cycle
A project generally results in a single product, but that product may include
subsidiary components, each with its own separate but interdependent product
scopes. For example, a new telephone system would generally include four
subsidiary components—hardware, software, training, and implementation.
Completion of the project scope is measured against the project plan, but
completion of the product scope is measured against the product requirements.
Both types of scope management must be well integrated to ensure that the work
of the project will result in delivery of the specified product.
3. Project Time Management
Project Time Management includes the processes required to ensure timely
completion of the project. The followings are major processes in developing the
project time schedule:
(a) Activity Definition—identifying the specific activities that must be
performed to produce the various project deliverables.
(b) Activity Sequencing—identifying and documenting interactivity
dependencies.
(c) Activity Duration Estimating—estimating the number of work periods that
will be needed to complete individual activities.
(d) Schedule Development—analyzing activity sequences, activity durations,
and resource requirements to create the project schedule.
(e) Schedule Control—controlling changes to the project schedule.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
4. Project Cost Management
Software Project Management (CS615)
39
© Copyright Virtual University of Pakistan
Project Cost Management includes the processes required to ensure that the
project is completed within the approved budget.
Resource Planning—determining what resources (people, equipment, materials)
and what quantities of each should be used to perform project activities.
Cost Estimating—developing an approximation (estimate) of the costs of the
resources needed to complete project activities.
Cost Budgeting—allocating the overall cost estimate to individual work
activities.
Cost Control—controlling changes to the project budget.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
5. Project Quality Management
Project Quality Management includes the processes required to ensure that the
project will satisfy the needs for which it was undertaken. It includes “all
activities of the overall management function that determine the quality policy,
objectives, and responsibilities and implements them by means such as quality
planning, quality assurance, quality control, and quality improvement, within the
quality system.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
Project quality management must address both the management of the project and
the product of the project. The generic term product is occasionally used, in
literature regarding quality, to refer to both goods and services.
6. Project Human Resource Management
Project Human Resource Management includes the processes required to make
the most effective use of the people involved with the project. It includes all the
project stakeholders—sponsors, customers, partners, and individual contributors
Following are some major processes:
Software Project Management (CS615)
40
© Copyright Virtual University of Pakistan
Organizational Planning—identifying, documenting, and assigning project
roles, responsibilities, and reporting relationships.
Staff Acquisition—getting the human resources needed assigned to and
working on the project.
Team Development—developing individual and group competencies to
enhance project performance.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project.
There is a substantial body of literature about dealing with people in an
operational, ongoing context. Some of the many topics include:
Leading, communicating, negotiating, etc.
Key General Management Skills:
Delegating, motivating, coaching, mentoring, and other subjects related to
dealing with individuals.
Team building, dealing with conflict, and other subjects related to dealing
with groups.
Performance appraisal, recruitment, retention, labor relations, health and
safety regulations, and other subjects related to administering the human
resource function.
Most of this material is directly applicable to leading and managing people on
projects, and the project manager and project management team should be
familiar with it. However, they must also be sensitive as to how this knowledge is
applied on the project. For example:
Project Human Resource Management includes the processes required to make
the most effective use of the people involved with the project. It includes all the
project stakeholders—sponsors, customers, partners, and individual contributors.
Major processes include:
Organizational Planning—identifying, documenting, and assigning project
roles, responsibilities, and reporting relationships.
Staff Acquisition—getting the human resources needed assigned to and
working on the project.
Team Development—developing individual and group competencies to
enhance project performance.
Software Project Management (CS615)
41
© Copyright Virtual University of Pakistan
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project.
7. Project Communications Management
Project Communications Management includes the processes required to ensure
timely and appropriate generation, collection, dissemination, storage, and ultimate
disposition of project information. It provides the critical links among people,
ideas, and information that are necessary for success. Everyone involved in the
project must be prepared to send and receive communications, and must
understand how the communications in which they are involved as individuals
affect the project as a whole.
Major processes include:
Communications Planning—determining the information and
communications needs of the stakeholders: who needs what information,
when they will need it, and how it will be given to them.
Information Distribution—making needed information available to project
stakeholders in a timely manner.
Performance Reporting—collecting and disseminating performance
information. This includes status reporting, progress measurement, and
forecasting.
Administrative Closure—generating, gathering, and disseminating
information to formalize a phase or project completion.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project. Each
process generally occurs at least once in every project phase.
Communicating is a broader subject and involves a substantial body of knowledge
that is not unique to the project context. For example:
Sender-receiver models—feedback loops, barriers to communications, etc.
Choice of media—when to communicate in writing versus when to
communicate orally, when to write an informal memo versus when to write a
formal report, etc.
Writing style—active versus passive voice, sentence structure, word choice,
etc.
Presentation techniques—body language, design of visual aids, etc.
Meeting management techniques—preparing an agenda, dealing with
conflict, etc.
Software Project Management (CS615)
42
© Copyright Virtual University of Pakistan
8. Project Risk management
Project Risk management is the systematic process of identifying, analyzing, and
responding to project risk. It includes maximizing the probability and
consequences of positive events and minimizing the probability and consequences
of adverse events to project objectives.
Risk Management Planning—deciding how to approach and plan the risk
management activities for a project.
Risk Identification—determining which risks might affect the project and
documenting their characteristics.
Qualitative Risk Analysis—performing a qualitative analysis of risks and
conditions to prioritize their effects on project objectives.
Quantitative Risk Analysis—measuring the probability and consequences of
risks and estimating their implications for project objectives.
Risk Response Planning—developing procedures and techniques to enhance
opportunities and reduce threats to the project’s objectives.
Risk Monitoring and Control—monitoring residual risks, identifying new
risks, executing risk reduction plans, and evaluating their effectiveness
throughout the project life cycle.
These processes interact with each other and with the processes in the other
knowledge areas. Each process generally occurs at least once in every project.
9. Project Procurement Management
Project Procurement Management includes the processes required to acquire
goods and services, to attain project scope, from outside the performing
organization. For simplicity, goods and services, whether one or many, will
generally be referred to as a product.
An overview of the major processes includes:
Procurement Planning—determining what to procure and when.
Solicitation Planning—documenting product requirements and identifying
potential sources.
Solicitation—obtaining quotations, bids, offers, or proposals, as appropriate.
Source Selection—choosing from among potential sellers.
Contract Administration—managing the relationship with the seller.
Contract Closeout—completion and settlement of the contract, including
resolution of any open items.
These processes interact with each other and with the processes in the other
knowledge areas as well. Each process may involve effort from one or more
individuals or groups of individuals, based on the needs of the project
Software Project Management (CS615)
43
© Copyright Virtual University of Pakistan
Project Procurement Management is discussed from the perspective of the buyer
in the buyer-seller relationship. The buyer-seller relationship can exist at many
levels on one project. Depending on the application area, the seller may be called
a subcontractor, a vendor, or a supplier.
The seller will typically manage its work as a project. In such cases:
The buyer becomes the customer, and is thus a key stakeholder for the seller.
The seller’s project management team must be concerned with all the
processes of project management, not just with those of this knowledge area.
The terms and conditions of the contract become a key input to many of the
seller’s processes. The contract may actually contain the input (e.g., major
deliverables, key milestones, cost objectives), or it may limit the project
team’s options (e.g., buyer approval of staffing decisions is often required on
design projects).
Software Project Management (CS615)
44
© Copyright Virtual University of Pakistan
LECTURE # 6
1. Introduction & Fundamentals
1.17 Team leader
Most definitions of leadership involve three components: influence group and
goal. First, leaders are individuals who influence the behavior of others. These
others are usually referred to as sub ordinates or followers. Second, leadership is
usually examined in the context of a group, especially work groups such as
managers and their teams or foremen and their subordinates. Third, research on
leadership stresses a group goal that has to be accomplished. So a definition is:
Leadership is the process in which an individual influences the group
members towards the attainment of group or organization goals.
Note that the influence can be exercised in a: variety of ways. It may be the
'bridge to engine room' approach, where the leader commands and controls. Or
the influence can be exercised by guiding and facilitating the group's behavior so
that the goal is accomplished. The notion of reciprocity is also part of man
definitions. Influencing is often two ways. Leaders may influence followers, but
followers influence leaders to lead in one way rather than another. An influencing
style appropriate for checkout assistant in a supermarket may be different from
that appropriate for rock scientists. The choice is open to the leader of how to
influence is one of the key aspects investigated by leadership researchers.
Another aspect of leadership is that the right to lead is often voluntarily conferred
on the leader by some or all members of the group. A group of friends may
recognize one, of their group as the leader, in the sense that she influences the
group more than any of the other members. There also may be informal leader.
While the nominal head of a department may have the formal leadership position,
the real leadership may be exercised by someone lower down the hierarchy who
influences the group towards goals that may not be those that the organization
whishes to be pursue.
Finally, leadership implies that a leader motivates the group to spend energy
in attaining the goals of the group. Influence without change or movement isn’t
influence. Leaders make change happen, a difficult but vitally important task.
1.18 Leaders and Managers
Although it is common to use the terms 'leader' and 'manager' interchangeably,
nowadays many writers point to a difference between the two.
Software Project Management (CS615)
45
© Copyright Virtual University of Pakistan
The difference is that to function as a leader, a person must exercise influence
over another person in the attainment of organizational goals, as described in the
definition above. Managerial ' functions of organizing, planning, scheduling,
processing information, communicating, and so on, do not necessarily involve
leadership. Some managers perform both types of function and can be described
as leaders, but others do not. There is no automatic link between the two concepts.
Note, too, that leaders are not necessarily just at the top of organizations.
Influence can be exerted in most job functions and at levels of seniority or
hierarchy. The distinction between managers and leaders was, developed by
Bennis and Nanus (1985) in their influential book Leaders. In it they put forward
the view that:
Leadership is path finding
Management is path following
Management is about doing things right
Leadership is about doing the right things
What they meant by this is that leadership is about having a vision. It involves
having a strategy or thinking strategically; it means having a view of where the
organization should go or be or do; it means deciding what is important for the
success of the organization; it involves envisaging the future, A leader's
responsibility is to think what are the key criteria for success of his or her part of
the business and not just now but for the future.
Managers, on the other hand, are more concerned with implementing others
strategies and plans, They are concerned with running their part of the
organization, making sure that the accounts get prepared, that invoices are sent
out, that the service is sold, that the traffic is directed, that the research paper is
written, or whatever the task that needs to be done.
A very similar view is put forward by Kotter (1990). He argues that management
is concerned with activities which are designed to produce 'consistency and order',
whereas leadership is concerned with, 'constructive or adaptive change'. Kotter
says there are four major ways that management and leadership differ:
1. Planning and budgeting versus establishing direction. Management
involves making detailed steps and timetables for achieving results, then
marshalling resources to make it happen. Leadership means developing a
vision of the future and strategies for achieving that vision.
2. Organizing and staffing versus aligning people. Management comprises the
allocation of tasks in line with plans, staffing them appropriately, delegating
responsibility and monitoring implementation. Leadership involves
communicating the vision so that others understand and agree with it.
3. Controlling and problem-solving versus motivating and inspiring.
Management involves monitoring results of a plan, identifying problems with
the plan and then solving them. Leadership involves 'energizing people'
Software Project Management (CS615)
46
© Copyright Virtual University of Pakistan
towards the vision. It means appealing to their needs and values so that they
overcome barriers to change.
4. Outcomes: predictability and order, or change. Management produces
predictability and order so that others, such as customers or shareholders can
rely on consistent results. Leadership produces change that is often a quantum
leap, such as new products or new approaches to managing people, that makes
the organization more competitive.
Kirkpatrick and Locke (1991) suggest that the following traits distinguish
leaders from non-leaders:
• Drive (achievement. ambition, energy, tenacity, initiative);
• Leadership motivation (personalized or socialized); .honesty and
integrity;
• Self-confidence (including emotional stability);
• Cognitive ability (the ability to marshal and interpret a wide variety
of information);
• Knowledge of the business
They point out, though, that there is much more to being an effective leader than
merely possessing a list of traits. While the traits may provide people with the
potential for leadership, it is the capacity to create a vision and implement it that
turns the potential into reality.
Strong leadership motivation may sound an obvious trait for a leader. After all,
only those who want the weighty responsibilities and grueling pressures of
leadership are likely to strive for it. McClelland (1985) distinguishes between two
types of power motivation. On the one hand, leaders may be interested in
personalized power, which describes the motivation of leaders who "seek power
for its own sake, who wish to dominate others and are often concerned with the
status and trappings of power. The late Robert Maxwell, former owner of the
Mirror Group allegedly displayed such traits. On the other hand, leaders who
show socialized power motivation are more interested in cooperating with others
to achieve desired goals. They work with others rather than attempting to
dominate or control them. From the point of view of subordinates and the
organization as a whole, the leader motivated by socialized power is obviously
preferable. On the question of cognitive ability; leaders must be able to gather,
integrate and interpret large amounts of information. Many
Many researchers have pointed out that it is not necessary to be brilliant, though;
leadership effectiveness is helped by above average intelligence, not genius. Of
Kirkpatrick and Locke’s six characteristics, some would argue that drive and
persistence are much more important than intelligence.
In conclusion, the trait approach has undergone a revival. Recent research
suggests that traits do matter. Yet the research shows that there are only a handful
Software Project Management (CS615)
47
© Copyright Virtual University of Pakistan
of traits which distinguish leaders from others, and a clear distinction between
effective and ineffective leaders has not yet emerged.
In an excellent book of technical leadership, Jerry Weinberg suggests a MOI
model of leadership:
Motivation: The ability to encourage (by "push or pull") technical people to
produce to their best ability.
Organization: The ability to mold existing processes (or invent new ones) that
will enable the initial concept to be translated into a final product.
Ideas or innovation: The ability to encourage people to create and feel creative
even when they must work within bounds established for a particular soft- ware
product or application.
Weinberg suggests that successful project leaders apply a problem solving
management style. That is, a software project manager should concentrate on
understanding the problem to be solved, managing the flow of ideas, and at the
same time, letting everyone on the team know (by words and, far more important,
by actions) that quality counts and that it will not be compromised.
Another view [EDG95] of the characteristics that define an effective project
manager emphasizes four key traits:
Problem solving An effective software project manager can diagnose the
technical and organizational issues that are most relevant, systematically structure
a solution or properly motivate other practitioners to develop the solution, apply
lessons learned from past projects to new situations, and remain flexible enough
to change direction if initial attempts at problem solution are fruitless.
Managerial identity
A good project manager must take charge of the project. She must have the
confidence to assume control when necessary and the assurance to allow good
technical people to follow their instincts.
Achievement
To optimize the productivity of a project team, a manager must reward initiative
and accomplishment and demonstrate through his own actions that controlled risk
taking will not be punished.
Influence and team building
An effective project manager must be able to "read" people; she must be able to
understand verbal and nonverbal signals and react to the needs of the people
sending these signals. The manager must remain under control in high-stress
situations.
Software Project Management (CS615)
48
© Copyright Virtual University of Pakistan
1.19 Project Organization
People are managed through an organizational structure. This hierarchical
structure is based on the four cornerstones of management: delegation,
authority, responsibility and supervision (see Fig.1). Delegation bestows
authority, and authority produces (and requires) responsibility. Both
authority and responsibility require supervision, and effective supervision
requires a suitable organizational structure:
Most projects are organized as teams, with each team assigned specific
functions within the project, Different types of project require different
types of team structure, as for example a team of junior programmers
requires a technical team leader while a team of experts may require only
an administrative team leader. It is the project manager's responsibility to
select the structure best suited for the project.
Basically an organization is a group of people intentionally organized to
accomplish an overall, common goal or set of goals. Business
organizations can range in size from two people to tens of thousands.
Figure 1: The four cornerstones of management
There are many ways to organize a software project. The larger the project
the more critical the organizational structure becomes. Badly organized
projects breed confusion, and confusion leads to project failure. Figure 2
describes the basic structure of a project in which below the project
manager are just two general functions: development and support. This
very basic software project structure was not uncommon in the 1950s and
1960s. It is still a valid project structure for very small projects (up to five
developers), though occasionally it can still be found today in larger
projects.
Delegation
1
Supervision
2
Authority
3
Responsibility
4
Software Project Management (CS615)
49
© Copyright Virtual University of Pakistan
Figure 2: Basic structure of a development project
Figure 3: Software project organizational chart
Project
Project
development
Project
support
Project
manager
Deputy
project
manager
System
engineer
Independent
test group
Secretary
Quality
assurance
Configuration
control
Development
team 1
Development
team 2
Development
team 3
Software Project Management (CS615)
50
© Copyright Virtual University of Pakistan
Project
manager
Deputy project
manager
Integration
Group
Independent
Group
Secretary
Quality
assurance
Configuration
control
SW sub-project
Manager 1
SW sub-project
Manager 2
SW sub-project
Manager 3
Team 1
Team 2
Team 3
Team 1
Team 2
Team 1
Team 2
Team 3
Figure 4: Large hardware/software project organizational chart
Project managers are just two general functions: development and support. This very
basic software project structure was not uncommon in the 1950s and 1960s. It is a project
structure for very small projects (up to five developers). Though occasionally, it can still
be found today in larger projects.
Figure 3 describes a detailed organizational chart including all major support functions.
This organizational structure is suitable for large projects (with a staff exceeding 20).
Smaller projects may not require a deputy project manager or separate configuration
control and quality assurance groups.
Very large projects (exceeding a staff of 40) can often be managed more easily by
dividing the project into sub-projects. Figure 4 presents the organizational chart for a
large project. This chart includes both software and hardware development teams, and an
integration group that is responsible for hardware/software integration as well as
integration within each group.
As an example, consider the organization of a large satellite project. The project manager
is in fact responsible for a number of projects: the ground control station, the rocket and
the satellite itself. The software for all of these sub-projects is managed within a single
project office. Each sub-project is then managed by a sub-project manager. An
organizational chart similar to the one described in Fig. 4 can be applied to the satellite
project; the resulting chart is described in Fig. 5.
Software Project Management (CS615)
51
© Copyright Virtual University of Pakistan
Satellite
PM
Sub-project
Coordinator
Scientific
Engineer
Integration
Team
Secretary
Quality assurance Ground control
Station sub-project
Rocket
Development
Sub-project
Satellite
Sub-project
Team 1
Team 2
Team 3
Team
1
Team
2
Team
1
Team
2
Team
3
Quality
Assurance
Independent
Group
Configuration
Control
Figure 5: Satellite project organizational chart
Clearly the project's organizational structure is dependent on the type of project being
developed. Some of the issues that must be considered are:
– Project size: the larger the project, the more important the organization. Large
projects have significant human communications and coordination overhead, and
therefore require more support functions.
– Hardware/software development projects. The simultaneous development of
hardware and software is not easy. Planning, integration and testing are much
more complicated, and require dedicated support groups.
– High reliability systems. Any system that is sensitive to issues of reliability (such
as military or life-saving systems) requires a major effort in quality assurance.
Quality is also an important consideration in many marketable software products
(e.g. communications packages). These types of project require a separate quality
assurance organization.
Software Project Management (CS615)
52
© Copyright Virtual University of Pakistan
The Organizational structure
The organization's structure, or design, is the overall arrangement of the
organization's various roles, processes and their relationships in the organization.
The design of an organization is a means to accomplishing the organization's
overall goal -- the structure is not an end in itself. In systems theory terms, the
design ensures that the appropriate inputs go through the necessary processes to
produce the required outputs to produce the intended outcomes.
The structure of the performing organization often constrains the availability of or
terms under which resources become available to the project. Organizational
structures can be characterized as spanning a spectrum from functional to
projectized, with a variety of matrix structures in between.
⇒ Corporate structure: The project's organization is largely dependent on the overall
structure of the company within which the project is being developed. Many of the
project support functions can be provided by centralized groups within the company.
In fact, basic services, such as financial, secretarial and legal services, are commonly
provided by the parent or corporate organization.
Corporate structure usually dictates one of two basic types of project organization:
matrix or pyramid. Figure 5 describes the structure of a matrix organization (compare
this to the pyramid structure in Fig. 4). Within a corporate matrix organization, the
project manager manages the technical activities of the project staff, while his or her
involvement in non-technical personnel issues (e.g. salary reviews, promotion, and
training) is minimal.
⇒ Matrix Structure
Think of the functional structure. Imagine if you took someone from each of the
major functions in the functional structure (the boxes along the bottom of the
organization chart), e.g., people from sales, engineering, etc., and organized them into
a separate group intended to produce and sell one certain kind of product or service.
Members of this group stay together until that product is produced or they continue to
sell and service it. This overall structure (made up of a functional structure that also
has groups assigned to products) is a matrix structure. This structure is useful because
it focuses highly skilled people from across the organization to work on a complex
product or service. It can be difficult though, because each person essentially reports
to two supervisors: the supervisor of the functional area (e.g., engineering) and the
product manager, as well. When the organization needs constant coordination of its
functional activities, then lateral relations do not provide sufficient integration.
Consider the matrix structure. To adopt the matrix structure effectively, the
organization should modify many traditional management practices.
Matrix organizations are a blend of functional and projectized characteristics. Weak
matrices maintain many of the characteristics of a functional organization, and the
Software Project Management (CS615)
53
© Copyright Virtual University of Pakistan
project manager role is more that of a coordinator or expediter than that of a manager.
In similar fashion, strong matrices have many of the characteristics of the projectized
organization—full-time project managers with considerable authority and full-time
project administrative staff.
Most modern organizations involve all these structures at various levels. For example,
even a fundamentally functional organization may create a special project team to
handle a critical project. Such a team may have many of the characteristics of a
project in a projectized organization. The team may include full-time staff from
different functional departments, it may develop its own set of operating procedures,
and it may operate outside the standard, formalized reporting structure.
Matrix Organizations are a blend of functional and projectized characteristics. Weak
matrices maintain many of the characteristics of a functional organization, and the
project manager role is more that of a coordinator or expediter than that of a manager.
In similar fashion, strong matrices have many of the characteristics of the projectized
organization—full-time project managers with considerable authority and full-time
project administrative staff.
Most modern organizations involve all these structures at various levels. For example,
even a fundamentally functional organization may create a special project team to
handle a critical project. Such a team may have many of the characteristics of a
project in a projectized organization. The team may include full-time staff from
different functional departments, it may develop its own set of operating procedures,
and it may operate outside the standard, formalized reporting structure.
• The advantages of a matrix organization are:
– More expertise: a matrix organization can maintain experts in specific fields
(communications, data bases, graphics etc.) who are then assigned to different
projects. A single project cannot always afford the luxury of maintaining
experts in all fields.
– Flexibility: it is easier to move people around from one project to another.
This results in better utilization of the available expertise.
– Emphasis on managing the project: the project manager is freed of many of
the staff management tasks, leaving more time to concentrate on the technical
aspects of the project.
However, matrix organizations also have significant disadvantages:
– Fewer management measures. One of the primary tools for generating
motivation, promotion, is taken out of the hands of the project manager. The
manager has little influence on the developer's salary and professional role in
the organization.
Software Project Management (CS615)
54
© Copyright Virtual University of Pakistan
– Lower staff loyalty. All employees like to know exactly who their superior is.
In a matrix organization, an employee has more than one superior. This causes
a division of loyalty, and a weaker bond between employee and manager.
These disadvantages often outweigh the advantages of the corporate matrix
organization.
Motivation is a major factor in the success of a project, and anything that
undermines motivation is usually contrary to the best interests of the project.
Unfortunately, the best interests of the project do not always completely coincide
with the best interests of the company.
Pyramid organizations provide a clear, well-defined hierarchy in which all
individuals know their own position and the positions of those above and below
them. When promotion and status play a major role in generating motivation (and
they often do), then the pyramid organization is most effective. Many other
factors generate motivation; Sense of achievement, praise and peer esteem, are
just a few.
Though promotion and status are not always the most effective motivators, a
project manager should rarely relinquish any effective management tool.
Therefore, from the perspective of a single project, the pyramid organization is
often the best.
⇒ Functional Structure
Most business organizations start out with a functional structure, or a small
variation of this structure. This is the basic "building block" for other structures.
In this structure, there is a central office which oversees various departments or
major functions, e.g., human resources, finances, sales, marketing, engineering,
etc. Think of a picture that has a box at the top labeled "Central Office". Think of
a row of boxes underneath the top box. Each box is labeled, e.g., sales,
engineering, human resources, etc. Connect the boxes with lines coming down
from the top box to each of the boxes below. Use functional structures when the
organization is small, geographically centralized, and provides few goods and
services. When the organization experiences bottlenecks in decision making and
difficulties in coordination, it has outgrown its functional structure.
The classic functional organization is a hierarchy where each employee has one
clear superior. Staff members are grouped by specialty, such as production,
marketing, engineering, and accounting at the top level, with engineering further
subdivided into functional organizations that support the business of the larger
organization (e.g., mechanical and electrical). Functional organizations still have
projects, but the perceived scope of the project is limited to the boundaries of the
function: the engineering department in a functional organization will do its work
Software Project Management (CS615)
55
© Copyright Virtual University of Pakistan
independent of the manufacturing or marketing departments. For example, when a
new product development is undertaken in a purely functional organization, the
design phase is often called a design project and includes only engineering
department staff. If questions about manufacturing arise, they are passed up the
hierarchy to the department head, who consults with the head of the
manufacturing department. The engineering department head then passes the
answer back down the hierarchy to the engineering project manager.
⇒ Project Structure
In this structure, there is a centralized corporate office and under it, are various
divisions each of which is dedicated to producing and / or selling a certain type of
business or product, e.g., product 1, product 2, etc. Each division that is dedicated
to a certain business or product is, in turn, is organized as its own functional
structure. So, for example, the division dedicated to making product 1 has its own
sales department, human resources, etc. Basically, project structure is a bunch of
functional structures each of which reports to one central office. Use a divisional
structure when the organization is relatively large, geographically dispersed,
and/or produces wide range of goods/services.
In a projectized organization, team members are often collocated. Most of the
organization’s resources are involved in project work, and project managers have
a great deal of independence and authority. Projectized organizations often have
organizational units called departments, but these groups either report directly to
the project manager or provide support services to the various projects.
Structural dimensions:
Centralization -the extent to which functions are dispersed in the
organization, either in terms of integration with other functions or
geographically
Formalization - regarding the extent of policies and procedures in the
organization
Hierarchy - regarding the extent and configuration of levels in the
structure
Routinization - regarding the extent that organizational processes are
standardized
Specialization - regarding the extent to which activities are refined
Training - regarding the extent of activities to equip organization
members with knowledge and skills to carry out their roles
Contextual Dimensions:
Culture - the values and beliefs shared by all (note that culture is often
discerned by examining norms or observable behaviors in the workplace)
Software Project Management (CS615)
56
© Copyright Virtual University of Pakistan
Environment - the nature of external influences and activities in the
political, technical, social and economic arenas
Goals - unique overall priorities and desired end-states of the organization
Size - number of people and resources and their span in the organization
Technology - the often unique activities needed to reach organizational
goals, including nature of activities, specialization, type of
equipment/facilities needed, etc.
Role and responsibility assignments
Project roles (who do what) and responsibilities (who decide what) must be
assigned to the appropriate project stakeholders. Roles and responsibilities may
vary over time. Most roles and responsibilities will be assigned to stakeholders who
are actively involved in the work of the project, such as the project manager, other
members of the project management team, and the individual contributors. The
roles and responsibilities of the project manager are generally critical on most
projects, but vary significantly by application area. Project roles and responsibilities
should be closely linked to the project scope definition. A Responsibility
Assignment Matrix (RAM) is often used for this purpose. On larger projects, RAMs
may be developed at various levels. For example, a high-level RAM may define
which group or unit is responsible for each component of the work breakdown
structure, while lower-level RAMs are used within the group to assign roles and
responsibilities for specific activities to particular individuals.
Organization chart
An organization chart is any graphic display of project reporting relationships. It
may be formal or informal, highly detailed or broadly framed, based on the needs of
the project. For example, the organization chart for a three- to four-person internal
service project is unlikely to have the rigor and detail of the organization chart for a
3,000-person disaster response team. An Organizational Breakdown Structure
(OBS) is a specific type of organization chart that shows; which organizational
units are responsible for which work packages.
Project Personnel
The staffing management plan describes when and how human resources will be
brought onto and taken off of the project team. The staffing plan may be formal or
informal, highly detailed or broadly framed, based on the needs of the project. It is a
subsidiary element of the overall project plan.
The staffing management plan often includes resource histograms. Particular
attention should be paid to how project team members (individuals or groups) will
be released when they are no longer needed on the project.
Appropriate reassignment procedures may:
Software Project Management (CS615)
57
© Copyright Virtual University of Pakistan
– Reduce costs by reducing or eliminating the tendency to “make work” to fill
the time between this assignment and the next.
– Improve morale by reducing or eliminating uncertainty about future
employment opportunities.
Supporting detail
Supporting detail for organizational planning varies by application area and
project size. Information frequently supplied as supporting detail includes, but is
not limited to:
– Job descriptions (position descriptions) —written outlines by job title of the
competencies; responsibilities, authority; physical environment, and other
characteristics involved in performing a given job.
– Training needs—if the staff to be assigned is not expected to have the
competencies
Needed by the project, those competencies will need to be developed as part of
the project.
Key Concepts in Design of Good Organization
Effective Organizational System provides assessment and training in
communication effectiveness through focus groups, retreats, workshops, and
experiential activities. Coaching addresses such skills as active listening,
constructive differing, conflict resolution, negotiation, mediation, persuasiveness,
and clarity in delivering a message. At the core of the training is the fundamental
premise that the role of communication is to create understanding. When
communication is effective, it promotes understanding and plays a fundamental role
in building interpersonal skills, leadership and strong teams.
An efficient organization is characterized by timely and productive systems and
procedures. At its extreme it has no spare capacity to plan ahead or to respond
easily to market changes.
An effective organization is characterized by the ability to pre-empt competitors,
respond swiftly and efficiently to changing situations, and display agility in its
structure and conduct of operations. It has efficient systems and procedures but has
the capacity to anticipate and plan ahead.
Organizational System provides assessment and training in communication
effectiveness through focus groups, retreats, workshops, and experiential activities.
Coaching addresses such skills as active listening, constructive differing, conflict
resolution, negotiation, mediation, persuasiveness, and clarity in delivering a
Software Project Management (CS615)
58
© Copyright Virtual University of Pakistan
message. At the core of the training is the fundamental premise that the role of
communication is to create understanding. When communication is effective, it
promotes understanding and plays a fundamental role in building interpersonal
skills, leadership and strong teams. Organizations that achieve high levels of
maturity in the people management area have a higher likelihood of implementing
effective software engineering practices.
– Span of control - the range of employees who to report to a managerial
position
– Authority - the formally-granted influence of a position to make decisions,
pursue goals and get resources to pursue the goals; authority in a managerial
role may exist only to the extent that subordinates agree to grant this authority
or follow the orders from that position
– Responsibility - the duty to carry out an assignment or conduct a certain
activity
– Delegation - process of assigning a task to a subordinate along with the
commensurate responsibility and authority to carry out the task
– Chain of command - the lines of authority in an organization, who reports to
whom
– Accountability - responsibility for the outcome of the process
– Line authority - the type of authority where managers have formal authority
over their subordinates' activities (the subordinates are depicted under the
manager on a solid line in the organization chart); departments directly
involved in producing services or products are sometimes called line
departments
– Staff departments - the type of authority where managers influence line
managers through staff's specialized advice; departments that support or
advise line departments are called staff departments and include, e.g., human
resources, legal, finance, etc.
Software Project Management (CS615)
59
© Copyright Virtual University of Pakistan
LECTURE # 7
2. Software Development Fundamentals
Management Fundamentals
2.1 Evolution of Software
The understanding about software and software development has come a long
way from the days of punch cards and Ada. In the first stage of computing,
hardware mattered the most. Computers themselves were the domains of the
government, and most software was developed in defense-funded labs, dedicated
to the advancement of science and technology in the national interest.
By the 1950s, large corporations realized the benefits of using computers. They
increasingly started using computers to process and analyze financial and
production data. These computers were huge in size. There was inadequate
software available for them. Even the software that existed was designed
essentially to function on a specific hardware product. The software was
developed and maintained by the company that manufactured the hardware.
Software design and documentation existed only in the developer's head. If the
developer left the company, you would find maintenance to be a nightmare.
In the second phase of software evolution, the corporate and academic sectors
increasingly started using computers, and the perspective about both software and
software development began to change. By the late 1960s and early 1970s,
concepts such as multi-sessions, multi-user systems, multiprogramming gained a
foothold. Soon computers were developed to collect, process, transform, and
analyze data in seconds. The focus of software development shifted from custom
software to product software. Now, multiple users on multiple computers could
use the same software. This phase of software evolution also saw the emergence
of software maintenance activities. These activities comprised fixing bugs, and
modifying the software based on changes in user requirements.
The third phase in software evolution was driven by the widespread use of
silicon-based microprocessors, which further led to the development of highspeed
computers, networked computers, and digital communication. Although, all
the advancement in software and hardware was still largely restricted to enterprise
applications manufacturers had begun to see the application of the microprocessor
in something as mundane as ovens to the robots used in car plants.
The fourth, and current, phase of software evolution began in the early 1990s.
This phase saw the growth of client-server environment, parallel computing,
distributed computing, network computing, and object-oriented programming.
Software Project Management (CS615)
60
© Copyright Virtual University of Pakistan
This phase also witnessed the growing popularity of personal computer (PC).
During this phase, the Internet facilitated easy accessibility of information. In
addition to complex software to support the advanced hardware, the scope of
software development widened to include software products for the common man.
Figure 1.1 sketches the path of software from the 1950s onwards.
• The Software Crisis
The rapid evolution of software design concepts and software development
methodology resulted in an ad hoc approach to software development. In the early
days of computing, stress was laid more on computer hardware than on software.
This happened mainly because hardware consumed the largest portion of the
project budget. Project managers closely followed the process of hardware
funding, budgeting, analysis and design, production, and implementation.
Software development, on the other hand, was left to the developers. There was
no training conducted, documentation maintained, or methodology followed for
software development. You will find that this attitude persisted until the 1970s,
when finally processes and methodologies for software design and development
began to be created. However, the ad hoc approach to software development that
Software Project Management (CS615)
61
© Copyright Virtual University of Pakistan
was prevalent in the early stages of software evolution hampered the application
of systematic processes. This conflict referred to as the software crisis. Some of
the reasons to which you can attribute the software crisis include:
– Software developers used-multiple programming languages.
– Software developers used multiple variations of standard programming
languages.
– Most of the requirements were complex with regard to the existing
capabilities,
– Users, who had little or no experience of developing or even using
software, formulated requirements.
– Software developers poorly mapped requirements to the actual product.
– Software developed had low interoperability.
– Software maintenance was costly.
– Hardware developed at a faster rate than software (better hardware
requires better software to operate it).
During the period of software crisis, you will find that software that was produced
was generally over budgeted, under scheduled, and of poor quality. The
immediate knee-jerk response to these problems was software maintenance,
which began to consume huge resources. During this period, maintaining software
was adopted as a short-term solution due to the costs involved in fixing software
regularly. This often resulted in the original software design approach getting lost
due to the lack of documentation.
In contrast, the situation in the present times has changed to a large extent.
Software costs have risen, although hardware is purchased easily off the shelf.
Now, the primary concerns regarding software projects are project delays, high
costs, and a large number of errors in the finished product.
2.2 Project Execution Fundamentals
Tracking
For the project manager, it is essential to be constantly informed of the true status
of the project. This is achieved by assuring the regular flow of accurate
information from the development teams. Many of the methods of acquiring
information are not objective and rely on the accuracy of the reports provided by
the project developers themselves. They include:
– Periodic written status reports
– Verbal reports
– Status meetings
– Product demonstrations (demos)
Product demonstrations are particularly subjective, because they demonstrate only
what the developer wishes to be seen. The project manager needs objective
Software Project Management (CS615)
62
© Copyright Virtual University of Pakistan
information. Such information can often be acquired from reports produced by
support groups, such as:
– Quality assurance reports
– Independent test reports
Although reports and meetings are indeed useful sources of information, nothing
can replace direct contact between the project manager and the development staff.
Frequent informal talks with the developers are excellent sources of information,
especially when held in an informal atmosphere (and not in the project manager's
office).
The project manager must keep on constant guard against an error commonly
referred to as the '90/50 syndrome’, which states that, 'it takes 50 percent of the
time to complete 90 percent of the work, and an additional 50 percent of the time
to complete the remaining 10 percent of the work'. This means that project
developers will begin to boast quite early that they have 'almost finished' their
tasks. Unfortunately, there is a great difference between 'almost finished' and
‘finished'.
Finishing a task -writing documentation, and polishing off the last few problems,
often takes longer than developers anticipate. This is because these activities
produce very few visible results, and developers tend (wrongly) to associate work
with results. Therefore, managers can obtain more information from developers
by asking them how long they estimate it will take to finish, and not how much of
their work has been completed.
• Status reports
Status reports should be required from every member of the development team,
without exception. The reports should be submitted periodically, usually weekly
or bi-weekly, and should contain at least the following three sections (see Fig.
5.8):
1. Activities during the report period
Each subsection within this section describes a major activity during the report
period. The description of each activity should span two to three lines. Activities
should be linked to the project task list or work breakdown structure (WBS) (see
Chapter 10 for a description of the WBS).
2. Planned activities for the next report period
Each subsection within this section describes a major activity planned for the next
report period. The description of each activity should span one to two lines.
3. Problems
Software Project Management (CS615)
63
© Copyright Virtual University of Pakistan
Each subsection within this section describes a major problem that either occurred
during the report period, or that was reported previously and has not yet been
resolved. This means that problems will be repeatedly reported until they are
resolved. In particular, this section must explain why this report's Section 1 does
not correspond to the previous report's Section 2.
All reports should also contain:
1. Date of report
2. Report period (e.g. 3 July to 10 July 1992)
3. Name of report (e.g. Communications team status report)
4. Name of person submitting the report
The preparation of a periodic status report should take about 20 minutes, but not
longer than 30 minutes. Developers should submit their status reports to their
team leader. The team leader then combines the reports of the team into a single
status report, while maintaining the same report structure. This activity should
take the team leader about 30 minutes, but not longer than 45 minutes (this is
easily done when the reports are prepared and submitted by electronic mail).
Each team leader submits the team status report to the project manager. The
individual status reports need not be submitted; these should be filed and
submitted to the project manager only on request.
Software Project Management (CS615)
64
© Copyright Virtual University of Pakistan
From: John Doe, Team leader
To: Frank Smith, Project Manager
Date: 15 June 1993
User interface team: Weekly status report
for the period 5-12 June 1993
1. Activities during the report period:
1.1 The design of the user help screens (activity 3.12.6) was completed on schedule.
The design specs were submitted to configuration control.
1.2 Coding of the command pass through modules (activity group 5.12) continues, and is
currently behind schedule by about 1 week.
2. Activities planned for next week:
2.1 Coding of the command pass through modules (activity group 5.12) will be
completed, and unit tests will be started.
2.2 Two members of the team (Ed and Joan) will attend a two day course on the
Programmer’s interface to the new user interface package. This is an unscheduled
activity that was approved at the last project meeting. This will not delay the
schedule, due to the early completion of the command pass through modules (see
Section 1.2 above).
3. Problems:
3.1 The user interface package we originally planned to use was found to be inadequate
for the project. Two team members will study the new proposed package (sec Section 2.2
above). If the new package is also found to be unsuitable, then this will severely impact
our development schedule.
3.2 One of our team members (Jack Brown) has been using an old VTI00 terminal
instead of a workstation for the past two weeks, due to the acute shortage of
workstations. This is the reason why Jack's task 5.12 was not completed this week, as
scheduled.
Figure 5.8: Example of a weekly status report
The project manager also receives status reports from other project support
personnel such as the project systems engineer or the deputy project manager. The
project manager then prepares the project status report by combining the
individual reports received into a single three-part report. The project status report
is then submitted to top management.
Software Project Management (CS615)
65
© Copyright Virtual University of Pakistan
Project status reports are not necessarily submitted at the same frequency as
internal project status reports. Project reports may be submitted bi-weekly or
monthly.
• Project status meetings
Project status meetings should be held periodically, usually once a week. A good
time for status meetings is either at the end of the last day of the week, or at the
beginning of the first day of the week. Status meetings also contribute to the
atmosphere of order and control within the project, and should be held regularly,
at a fixed time. Participants who cannot participate in the project status meeting
may, with the project manager's approval, delegate participation to another
member of their team.
The project manager prepares for the status meeting by reviewing the status
reports submitted by the key project members (particularly scrutinizing the
problem section). Therefore the status reports should be submitted at least two to
three hours before the status meeting. Project status meetings are attended by the
key project members. The meeting begins with a report of project activities and
general issues by the project manager. Then each participant should be given
about five to ten minutes to report on the activity of his or her team or area of
responsibility. The discussion of problems should not be restricted to the person
reporting the problem and the project manager. All problems may be addressed by
all participants, with possible assistance offered between team leaders, thus
making their experience available throughout the project. It is not the project
manager's role to provide solutions to the problems, but rather to guide the team
members toward solutions.
Solutions should be worked out whenever possible during the status meeting. Any
problem not resolved within five minutes should be postponed for discussion by
the relevant parties after the status meeting. The proceedings of all project status
meetings must be recorded. Verbatim minutes are not required, though the
following items should appear in the record:
1. Date of meeting
2. Name of meeting
3. Present (list of participants)
4. Absent (list of absent invited participants)
5. Action items (name, action, and date for completion)
6. Major decisions and items discussed
The record of the project status meeting should be typed and distributed as soon
as possible, but no later than by the end of the day. This is particularly important
when there are action items to be completed on the same day. When the project is
sufficiently large to justify a secretary, then the record will be taken and typed by
Software Project Management (CS615)
66
© Copyright Virtual University of Pakistan
the secretary. In smaller projects, the project manager can rotate this task each
week between the participants.
2.3 Software Project Management Framework
You all know that a project is much more than a collection of methodologies,
tasks, resources, and reviews. A project is a synchronized event where there is
perfect harmony and understanding between the participants. The participants are
equipped with the essential skills of planning, cooperating, helping, and
communicating. However, the most important activity here is to orchestrate the
movement of the participants. The onus lies with the project manager to
synchronize the activities of the project to result in a perfect presentation.
Although each project manager has a unique style of functioning, there are some
fundamental approaches that guide a project manager. These approaches are
traditional project management concepts and software engineering concepts. To
understand software projects and their dynamics, you must be aware of the
environment in which a software project is executed. This further requires an
understanding of the larger framework of software project management.
In this chapter, you will learn to, build a connection between traditional project
management concepts and software engineering concepts. Both traditional and
software projects share the same methodologies, techniques, and processes.
However, managing software projects requires a distinct approach. In this,
chapter, you will learn to apply traditional project management principles to
software projects. Further, you will learn about the responsibilities of a software
project manager. You will also learn about the phases in a software project and
the activities within each phase. Finally, the chapter will provide you an overview
of the problems that affect a software project and the myths prevalent about
software project management.
2.4 Software Development Life Cycle (SDLC)
The development of a software project consists of many activities spread across
multiple phases. Dividing a software project into phases helps you in managing
the complexities and uncertainties involved in the software project.
2.5 Phases of a Software project
Each phase represents the development of either a part of the software product or
something associated with the software project, such as user manual or testing.
Each phase is composed of various activities. You can consider a phase complete
when all activities are complete.
Software Project Management (CS615)
67
© Copyright Virtual University of Pakistan
A phase is named according to the primary deliverable set that is achieved at the
end of that phase. For example, if the requirements document is required as the
output, the phase is called the requirements phase. Similarly, most software
projects have phases for analysis, design, construction, implementation, and
testing.
A typical software project includes the following phases:
– Software requirement analysis phase
– Software Design Phase
– Software Planning Phase
– Software construction phase
– Software testing phase
– Software acceptance and maintenance phase
2.6 SDLC Models
Different organizations have different ways of assessing and arranging the phases
in a project. These are called process models. Process models define how a
software life cycle actually works. They provide you with a framework to plan
and execute the various phases in the project. Typically, project life cycles display
the following characteristics:
• The level of cost and effort required in a software project life cycle is small to
begin with but grows larger towards the end of the project. This happens
because the phases such as software construction and implementation, which
come at later stages in a software project, require more resources than the
initial phases of the project.
• At the start of the SDLC, external entities, such as the customer and the
organization, play an important role with regard to their effect on the
requirements. However, towards the end of the software project as the cost
and effort required to implement changes rise, the requests for change in
requirements decreases.
• The uncertainty faced by the software project is highest at the beginning of the
SDLC. Their level decreases as the project progresses.
There are a few standard software process models that you can use, with some
customization. Some standard process models are given below:
• The Waterfall model: This is the traditional life cycle model. It assumes that
all phases in a software project are carried out sequentially and that each
phase is completed before the next is taken up.
• The Prototyping Model: A model that works on an iterative cycle of gathering
customer requirements, producing a prototype based on the requirement
specifications, and getting the prototype validated by the customer. Each
Software Project Management (CS615)
68
© Copyright Virtual University of Pakistan
iteration of the life cycle builds on the prototype produced in the previous
iteration.
• The Incremental Model: The Incremental model is an example of an
evolutionary life cycle model. It combines the linear nature of the Waterfall
model and the iterative nature of the Prototyping model. The Incremental
model divided the development life cycle into multiple linear sequences, each
of which produces an increment of the final software product. In this model,
the software product is developed in builds. A build is defined as a selfcontained
unit of the development activity. The entire development cycle is
planned for a specific number of logical builds, each having a specific set of
features.
• The Spiral model: Another evolutionary life cycle model that combines the
linear nature of the Waterfall model and the iterative nature of the Prototyping
model. The project life cycle is divided into phases, and each phase is
executed in all of the iteration of the Spiral Model.
Software Project Management (CS615)
69
© Copyright Virtual University of Pakistan
LECTURE # 8
2. Software Development Fundamentals
Management Fundamentals
2.7 Organizational Issues and Project Management
Organizational issues have a deep influence on a software project, its progress,
and the role of the project manager. The policies of an organization can affect the
way the organization handles the customer, different types of technologies, and
different software projects. The organizational issues that can influence a software
project include:
• Reaction to external influences
• Interest in adherence to standards
• Definition of core competency area
• Existence of knowledge management system
• Interest in human resources
One organizational issue that can influence a software project is the reaction of
the organization to external influences.- As a project manager, it is important for
you to assess how the organization reacts to changes in the external environment,
For example, in the current technology environment that changes rapidly, an
organization should be proactive in strengthening its capability baseline by
adopting new technology and retraining its employees as per market
requirements.
Interest in adherence to standards is another organizational issue that can
influence a software project. The current technology environment is highly
dynamic. Various nonprofit and independent organizations have developed
protocols and standards for the standardization of software development and
measurement: For example; the Software Engineering Institute at the Carnegie
Mellon University has developed the Capability Maturity Model (SEI-CMM).
The CMM rates the processes of a software development organization and
classifies it into five maturity levels. Software development organizations can also
get the quality-related certifications issued by the International Standards
Organization smoothen your project management tasks by standardizing the
internal processes and optimizing performance.
Definition of core competency area also influences a software project. An
organization that creates software must understand how they are created and
establish processes accordingly For example, if the core competency of the
organization lies in manufacturing chemicals, it should preferably not attempt
Software Project Management (CS615)
70
© Copyright Virtual University of Pakistan
software development for such an organization, it is better to purchase an off-theshelf
software product.
An organizational issue that positively influences the tasks of software project
managers is the presence of a good knowledge management system within the
organization. Knowledge management is the collection of processes that control
the creation and utilization of knowledge within the organization. A good
knowledge management system allows you to access relevant information and
make informed decisions.
Another organizational issue that can influence a software project is the interest of
management in human resources. The human resources of an organization are its
primary resource. You need to ensure that the people in the development team
enjoy a comfortable work environment, which is conducive for smooth and
trouble-free work. This includes providing suitable compensations, a friendly
work environment, and smooth processes. The absence of these factors negatively
affects employee morale, and therefore, productivity.
2.8 Managing Processes
As a software project manager, you become the key player in a software project.
You not only manager the day-to-day activities of the project but also ensure that
the software product is delivered on time. What makes your role challenging is
the performance of project-related activities within a specified budget and time
constraint. At the same time, you need to keep the requirements and specifications
of the customer in mind.
To deliver expected results, you carry out three successive processes: studying the
feasibility of the project, planning to meet the requirement, and executing the
plan. These processes can be further broken down into activities, such as
planning, staffing, and monitoring.
You plan and organize the software development team to complete development
within the stipulated time and budget. To do this, you form a team of people who
have the required technical skills. Then, you ensure that all activities are carried
out as planned by the relevant people.
Your responsibilities include analyzing customer requirements, determining the
scope of the software project, allocating resources top the project, scheduling the
project, and executing the project. These responsibilities can be considered in
terms of the areas where management skills are required. The primary software
project management areas that you need to concentrate on include:
• Managing Resources
• Managing Cost
Software Project Management (CS615)
71
© Copyright Virtual University of Pakistan
• Managing Risk
• Managing Schedule
• Managing the project plan
• Managing quality
⇒ Managing Resources
The primary input required to create software are resources. Resources for a
software project may be of three kinds: human, hardware, "and software. Human
resource management is about effectively identifying the people with the
appropriate skills, assigning roles and responsibilities to these people, and
establishing reporting relationships. On the other hand, hardware and software
resource management relates to identifying and ensuring resources such as
workstations, disk space on servers, software tools, and software licenses. You
need to ensure that human resource identification and allocation is carried out;
simultaneously with hardware and software resource management.
To manage resources effectively, there are two areas that you require your
attention. These include:
• Management of human resource
• Identification of the critical hardware and software resources
Management of human resources calls for a number of actions. First, you define
reporting relationship for the software project. Reporting relationship can exist
within and across organizational units, technical areas, and hierarchical levels.
Next, determine the skills required for the software project, and identify the
appropriate people who possess the required skills. You can review the resource
pool and identify resources on the basis of their experience and availability. In
case the resources are unavailable, you request for their release from another
project or outsource the required resources. Depending upon the organizational
practices arid experiences from past projects, you can assign roles and
responsibilities to the development team. Finally, create a staff management plan
and an organizational chart to show the hierarchical structure of the development
team.
Management of human resources also requires efficient team development. This
is a complex activity because it combines managing people and organizing the
reporting structure within the team. You can build cohesion and commitment
within the team through team building activities. These activities include
conducting team meetings to involve people from areas other than management
into decision-making.
To manage human resources, you also need to implement a reward and
recognition system. This helps in promoting and reinforcing positive
performance. It is important that you make the link between the performance and
Software Project Management (CS615)
72
© Copyright Virtual University of Pakistan
reward explicit and achievable. You should also ensure that the training needs of
the development team are met.
A second resource management area that requires attention is identification of the
hardware and software resources that are critical for the project. As a software
project manager, you must identify all the critical hardware and software
resources and document them in the project plan. After the required resources are
identified, you define control limits for each resource. Control limits for a
resource are the upper and lower limit beyond which the resource is above or
below the required level. For example, if a software project requires disk space on
the central server, the control limits for the disk space are the required maximum
and minimum disk space. Note that not all hardware and software resources are
critical to the success of a software project. In some software projects, you may
not find any critical resource at the beginning. However, as the project progresses,
some resources might become critical. For efficient resource management, you
should periodically assess hardware and software resource requirements for the
software project. Just as a resource may become critical as a project progresses, a
resource might also become less critical over a period of time. Therefore; plan,
assess, and take corrective action for all the resources through the duration of the
software project.
⇒ Managing Cost
The cost factor has a considerable influence on the execution of a software
project. The budget of a software project is affected by factors, such as the current
orientation of the organization toward software development, number of skilled
personnel available, infrastructure, and computer hardware and software. The
budget can also be influenced by timely availability of resources. If a particular
resource is allocated to the project later than required, the costs involved could go
up drastically.
Quite often, when a software project starts to become too expensive, many project
managers also tend to start cutting costs. This can have a direct impact on
employee morale. When employee morale drops, so does the quality of work, and
the productivity. Therefore, as a project manager you must prepare for all
circumstances through proper estimation and allocation. To manage costs for
software projects, you need an accurate estimation of costs. To do that, there is a
sequence of steps that you need to perform.
• Identify the resources required for the project
• Estimate the cost of each activity
• Set cost baselines for each activity
• Implement a control system for cost changes
To estimate costs, you first identify and describe all the resources required in the
software project. You also estimate the duration for which the resources are used.
Software Project Management (CS615)
73
© Copyright Virtual University of Pakistan
Next, estimate the cost of each resource. To estimate the cost, you can use
mathematical tools. However, in the case where limited information is available
about resources, you can also use expert judgment to estimate costs.
After the costs of the required resources are estimated, you set cost baselines for
each activity. Cost baselines measure the performance of an activity with regard
to the cost and duration defined for the completion of the activity.
Finally, as the project manager you implement a control system for cost changes.
The cost control system defines cost baselines, identifies cost changes, and
modifies cost baselines to adjust cost changes.
⇒ Management Risk
Risk management is an integral part of project management. In software projects,
where uncertainties are very high, risk management and mitigation is even more
critical. Taking risks for high payoffs might bring in high profits but not without
the danger of losses. Risk on a small scale is acceptable to most project managers
as the element of loss is minimal. However, large risks pose a danger to the
progress of a software project and you need to manage them. Risk management
activities involve identifying potential risks, assessing them, and planning for
contingent actions if a risk materializes.
As a project manager, you perform two primary activities to manage risks for
software project:
• Risk Analysis
o Risk identification
o Risk quantification
• Risk management
The first activity in risk analysis is risk identification. Risk identification helps
you point out the, potential risks for a software project across all phases of the
project. Risks might evolve through the duration of a software project, and
therefore, risk identification is an ongoing activity. To identify potential risks for
a software project, you can analyze the activities in the software project, the
software product description, and risks faced by the development team in similar
past projects. This exercise allows you to identify the potential sources of risks to
the current software project, Assessing the factor influencing the different inputs
also allows you to identify the phases in the SDLC when risk might materialize.
After potential risks have been identified, you can quantify them. This is done to
ascertain their priority. If multiple risks materialize at the same time, then you
must assign a priority to each risk based on the degree of impact on the project
and handle the highest-risk events first. For example, the risk of change in client
Software Project Management (CS615)
74
© Copyright Virtual University of Pakistan
requirements during the software construction phase is a higher risk than a
deadline for a deliverable being missed. Therefore, you first manage the risk that
has a higher priority. To quantify project risks, you can use various mathematical
and statistical tools. You can also use expert judgment to assess and quantify
risks.
After you have identified and quantified the potential risks for a software project,
you create a risk mitigation plan. The purpose of the risk mitigation plan is to help
you identify procedures to choose the path of least damage and highest returns in
a case a risk materializes. To mitigate risks for a software project, you first need
to be aware of the opportunities and threats that can be pursued or ignored. This
enables you to focus on the risks that might have a negative impact on the
software project and develop contingent plans to deal with these risks. You can
also mitigate risks by evolving alternative strategies to altogether prevent
potential risks from materializing.
In case an unplanned risk materializes, you must be aware of the dependencies of
the project activities so that ad hoc solutions can be evolved. However, as the
project manager you can avoid unplanned risks from materializing by engaging in
an intensive risk identification and mitigation exercise before the software project
commences.
⇒ Managing Schedule
Time is a major constraint for a software project. With most software projects, the
delivery dates for the software product are already committed to the customer at
the time the project commences. As a software project manager you must perform
various tasks to balance time and deadlines. These are:
– Identify the different deliverables that constitutes the software product
– Define the activities that are required to produce the deliverables
– Identify the interdependencies between activities
– Define the duration of each activity
– Assess the project network diagram
– Create a schedule management and control plan
The first task is to identify the different deliverables that constitute the software
product. These deliverables also mark the completion of the different phases
within a software project.
Next, define the activities that are required to produce the deliverables. To do this,
you can break down the SDLC into phases, identify the deliverables at the end of
each phase, and the activities required for creating the deliverables.
Software Project Management (CS615)
75
© Copyright Virtual University of Pakistan
After the activities are defined, you identify the interdependencies between them.
The purpose of this exercise is to organize the activities and sequence them in the
form of a project schedule.
Next, you define the duration of each activity. The inputs that you need for
scheduling are the resources required to complete each activity. Then, assesses the
availability of these resources and the duration of each similar activity in similar
past projects.
After estimating the time required for each activity to complete, you assess the
project network diagram. This includes an assessment of the duration estimates,
resource requirements, resource pool description, and assumptions and constraints
for the software. You can use Mathematical tools to determine a schedule for the
project. The project schedule defines the activities within each phase, the team
members assigned to complete each activity, the duration of each activity, and the
start and end dates for all of the activities.
Finally, create a schedule management and control plan. The purpose of this plan
is to identify when changes occur, Implement the changes to the project schedule,
and ensure that the changes are beneficial to the software project. After the
changes are implemented, you might need to modify the sections of the project
plan to ensure that the project is completed on time.
Software Project Management (CS615)
76
© Copyright Virtual University of Pakistan
LECTURE # 9
2. Software Development Fundamentals
Management Fundamentals
2.8 Managing Processes
⇒ Managing the Project Plan
Preparing it project plan for a software project helps you ensure that the specified
requirements and objectives are met successfully. It is a collation of all planning
activities that have happened for a software project. This includes activities such
as design and analysis, activity definition, risk planning, and cost estimation. To
create the plan, you assess all planning activities, organizational policies
regarding the creation of the project plan and assumption and constraints for the
project. To implement the software project plan, you require management skills,
such as leadership, communication, and problem solving, along with the basic
knowledge about the software. You also need to ensure that the senior
management bf the company has authorized work on the software project.
Knowledge management techniques help you to make informed decision
regarding the project plan.
After the project plan is executed, you manage the changes to it in such a way that
the performance measurement baselines are not impacted, To manage the project
plan effectively you monitor the project plan, periodic performance status reports,
and requests for change. The primary tool that you can use to control the changes
in the project plan is the change control mechanism: This is a set of formal
procedures for changing the project plan.
⇒ Managing Quality
The quality of software development depends largely on the understanding of
‘quality’ and quality management within the software development team. In
software projects where each member has a different understanding of quality and
his or her role in implementing it, the software product is usually not of the
required quality.
Implementing software quality is often associated with the software developer.
However, the role of the project manager is crucial in implementing quality
awareness and a quality-producing work environment. When a software project
starts missing deadlines and is in danger of exceeding the budget, project
managers often lose the focus on quality and lay stress on meeting deadlines.
However, the focus should be the other way round. A focus on delivering a
Software Project Management (CS615)
77
© Copyright Virtual University of Pakistan
quality product, even at the cost of missing a deadline or two ensures that your
customer comes back for repeat orders. On the other hand, the price of nonconformance
(PONC) on quality standards simply translates into the loss of
goodwill and loss of business.
Modern quality management techniques compliment project management and the
role of the project manager. Quality management techniques ensure that a
software product conforms to the customer requirements. Quality management
further ensures that errors are prevented in the first round itself. Checks for errors
and effort for removing the errors consume much more time, effort, and cost than
it takes to prevent the errors in the first place. Therefore, maintaining quality in a
software project is the domain of all team members.
However, as the project manager you have a critical role in maintaining quality.
You provide the resources required to complete the activities of the software
project and ensure that quality levels are constantly monitored.
You first identify the areas that must be monitored for ensuring quality and the
quality measures to implement. Then, consider the quality policy of the
organization, the scope of the project, the applicable standards, and the software
product description. Next, use tools, such as a cost-benefit analysis and a
flowchart, to identify the areas where you need to monitor quality and the
subsequent actions for control. The output of this exercise is the quality plan for
the software project. In addition, this exercise allows you to create checklists to
help monitor quality.
As a software project manager, you also need to use a quality control mechanism
so that the quality of the software product does not suffer. The aim of the quality
control mechanism is to ensure compliance with quality standards.
2.9 Project Execution
You already learned in the beginning of the chapter that a software project is
divided into different phases. This division is done on the basis of the activities
performed in each phase. Similarly, project management activities are also
arranged in phases. As a project manager, you perform the activities that map to
each of these phases. The project management phases can be broadly categorized
as follows;
– Project initiation
– Project closedown
– Project planning, control, and tracking
– Product implementation
• Project Initiation
Software Project Management (CS615)
78
© Copyright Virtual University of Pakistan
The tasks performed for project initiation are mentioned below:
Requirement gathering: The first task is to gather the customer requirements.
Customer requirements may be spoken or unspoken. Therefore, the challenge for
the project manager is to elicit the requirements in such a way that both the
spoken and unspoken customer needs and wants are gathered. After collecting the
required information, you need to translate the customer requirements into
technical specifications for the software project.
Scope determination: The scope of a software project can be defined as the
combination of the software product arid services to be delivered to the customer.
You carry out the scope determination exercise to define the scope of the software
project. The scope determination exercise enables you to refine and understand
the customer requirements. You can refine the scope definition further by
breaking down each deliverable into smaller and more manageable activities. The
scope determination exercise also helps you identify the technology for creating
the software product.
Resource allocation: During project initiation, you identify the resources required
and allocate them to the software project. The resources identified may be people,
reusable software components, and hardware or software tools. You allocate the
resource to the software project on the basis of the activities defined in the scope
determination exercise. While allocating appropriate resources for a software
project, you also need to calculate the cost of each resource. The cost of a
resource is calculated according to the duration of the resource in the software
project. Estimating the cost of resources also helps you prepare a budget for the
software project.
Note:
Scope determination and resource allocation are discussed in more detail in later
chapters.
Initial project plan: Another exercise that you carry out during project initiation
is the creation of a rough project plan. This plan is a draft version and carries only
the primitive project plan features. This project plan carries the initial risk
analysis of the software project, the initial start and end dates, the duration of the
activities in the project, and the sequencing of these activities.
• Project Planning, Controlling, and Tracking
This activity of the project manager involves detailed tasks. These tasks are
mentioned below:
Detailed project plan: After the scope for the software project is determined and
the product design is ready, you prepare a detailed project plan. To create a
detailed project plan, you define a detailed list of all the elements that make up the
Software Project Management (CS615)
79
© Copyright Virtual University of Pakistan
project deliverables. Next, the deliverables are further broken up to help In the
calculation of durations, start dates and end dates for each activity mentioned in
the plan. Roles and responsibilities are assigned to people with the appropriate
skills to complete each activity within specified time.
Control mechanism: These are set up to control the impact of changes on the
software project. The control mechanism includes a detailed risk management and
mitigation plan, a detailed quality plan, and quality assurance activities. You also
implement a review and audit system for periodic assessment and measurement of
the software project activities. The review and audit system enables you to
evaluate the progress of the software project. It ensures that all necessary data is
collected, deviation from the planned baselines is checked, and corrective action
is taken at all checkpoints. In this way, the review and audit system ensures
compliance with the organizational processes for software development.
Software Project Management (CS615)
80
© Copyright Virtual University of Pakistan
LECTURE # 10
2. Software Development Fundamentals
Management Fundamentals
2.9 Project Execution
⇒ Product Implementation
Product implementation activities involve defining processes related to the
implementation of the software product at the customer site. Some of the tasks
that you perform for product implementation are mentioned below:
• Implementation plan creation: An implementation plan defines the duration of
implementation and the hard and software perquisites for implementing the
software product.
• Support plan creation: the project manager also needs to create a support plan for
the customer. The support plan includes consideration such as the postimplementation
support activities provided to the customer. Post-implementation
considerations include the number of support staff available to the customer, their
names, contact numbers, and the duration of their availability.
• Training plan creation: During product implementation, you create a training
plan to train the customer on the software product. The training plan includes
considerations such as the duration of training, the prerequisites for training
people, and the number of people that can be trained simultaneously.
• User acceptance plan: You also need to prepare a user acceptance plan. The user
acceptance plan provides a detailed outline on how and when the user acceptance
tests are performed. The primary focus of user acceptance test is to ensure that the
final software product offers all the functionality and performance that the
customer wanted. Therefore, the customer tests the software product for issues
such as aesthetics, user friendless, and scalability.
⇒ Project Closedown
The final activity for a project manager is project closedown. For most software
projects, the project closedown activities take place in the post-implementation
phase. However, in some software projects, the customer requests support
activities for a longer duration. In such cases, the software project is considered
Software Project Management (CS615)
81
© Copyright Virtual University of Pakistan
closed immediately after implementation. The tasks that you perform in project
closedown are mentioned below:
• Prepare closedown report: The project closedown report contains the results of
the causal analysis that you do for the project. This contains an analysis of what
went wrong, what went right, and what you could have done better in the software
project.
• Identify learning: You also need to assess the entire software project and the
results of the causal analysis to identify the key learning points from the software
project. This helps you identify areas of improvement for future projects. The
learning points can also be used by the organization as considerations while
planning and executing the next software project.
• Identify reusable software components: Reusing software components enables
you to lower the cost, time, and effort required to complete the software project
successfully. After project closedown, you identify the software components that
can be reused in future projects of similar nature. The software components
prepared for a software project may be complete, partially complete, or in the
design stage. These components or their designs can be assessed for usability in
future projects.
• Create reference material: After the project is complete, you can create white
papers and reference documents. This can be a significant contribution to the
organization and the application area of the software by creating an authoritative
knowledge base.
2.10 Project Management Myths
In most cases, you learn the skills required to manage a software project while on
the job. As a result, most software project managers practice a lot of management
techniques that are of doubtful authenticity. Many software project managers
learn about the so-called management skills and concepts that are actually myths.
⇒ Clarifying the Project Management Myths
The following list aims to clarify some of the more prevalent myths in software
project management.
1. Combining the best resources with the worst resources available for a
software project helps to complete the project successfully.
2. A general statement of objectives is sufficient to begin work on the software
project.
Software Project Management (CS615)
82
© Copyright Virtual University of Pakistan
3. Allocating extra resources to a late project allows it to catch up with the
project schedule.
4. As software by itself is flexible, you can change the requirements at any point
in the software project life cycle.
5. The management and the customer always impose an unrealistic deadline for
the software project.
6. A software project that meets all the stated objectives is a success.
7. Software maintenance is an easy task and requires less effort than actual
software development.
8. Identifying and reporting errors during the reviews makes the software
developer unhappy and spoils the work environment.
9. Web-enabling an application or adopting client/server; architecture helps to
run software projects smoothly.
Myth: Combining the best resources with the worst resources available for a project
helps to complete the project successfully.
In software projects, combining the best resources with the worst resources drags
down the efficiency and productivity of good resources. This invariably decreases
the speed of the software project, and the project ends much after the specified
deadline.
Myth: A general statement of objective is sufficient to begin work on the software
project.
Many software project managers and customers believe that a general statement
of objectives gives a reasonable idea of the requirements. However, a formal and
detailed description of the customer requirements is needed before the project
commences. The software project manager must ensure that all information
regarding the software project, such as the functions, performance, interfaces,
constraints, assumptions and validation criteria is gathered.
Myth: Allocating extra resources to a late project allows it to catch up with the
project schedule.
A software project is not a mechanical process such as, say; digging an artificial
lake. In case of creating an artificial lake, adding more people to the job can help
dig a larger area in the same time. However, in a software project, adding, more
people actually increases the time required to finish the project. This happens
because a new person joining the project requires time to understand the
Software Project Management (CS615)
83
© Copyright Virtual University of Pakistan
requirements of the client, software design, and standards. Moreover, the existing
people in the project need to devote time and effort to train the new people on the
software project. Therefore, allocating additional resources to a risky situation
increases the risk to the software project.
Myth: As software by itself is flexible, changes in the requirements can be made at
any point in the software project life cycle.
Requests for changes are common with all projects. However, the timing of the
change for requests is critical. This is because an untimely change adversely,
impacts the cost of the software project. For example, a change request during the
requirements gathering stage has a relatively low impact on costs. On the other
hand, a change request during, the software construction stage can be extremely
expensive to incorporate. The software project manager must decide with the
customer upon a set of objectives that must be achieved at the end of the project.
In addition, the project manager and the customer must decide on a specific
phase, beyond which only critical change requests are accepted.
Myth: The management and customer always impose an unrealistic deadline for the
software project.
The management and customer usually believe that project managers prepare cost
effort, and time estimates inclusive of buffers. The management and customers
rationalize that if they can cut the buffers by imposing a tight deadline or a low
budget on a project, the project manager would still complete the project on time.
Myth: A software project that meets all the stated objectives is a success.
Customer requirements for a software project are always in two forms, spoken
and unspoken. Usually, the objectives formed from the customer requirements are
based on the spoken requirements. The software project manager must to be
aware of the unspoken requirements and ensure that these are met.
Myth: Software maintenance is an easy task and requires less effort than actual
software development.
If change requests are made toward the end of the project, then maintenance
activities can contribute to large costs and effort overruns. Moreover, contrary to
the popular view, implementing changes in the software product in the
maintenance stage is a painstaking task.
Myth: Identifying and reporting errors during the reviews makes the software
developer unhappy and spoil the work environment.
Software Project Management (CS615)
84
© Copyright Virtual University of Pakistan
If a developer makes an error, it is important to point it out so that the error is
fixed in time. A project manager must communicate assertively so that the team
does not lose focus on quality. In addition, letting an error pass may have ripple
effects on the quality of the software product, frustrating the entire team.
Myth: Web-enabling an application or adopting client / server architecture helps to
run software projects smoothly.
No single technology platform, language, or architecture is a one-point solution
for all software projects. All approaches to software development have unique
merits and demerits. For example, if a marketing firm needs to make information
accessible to people at remote locations, then a, Web-based application is a good
option. However, mainframes are still preferred for applications created for the
banking industry.
Software Project Management (CS615)
85
© Copyright Virtual University of Pakistan
LECTURE # 11
2. Software Development Fundamentals
Management Fundamentals
2.11 Problems in Software Projects
Software projects are similar to traditional projects in the sense that the same
types of problems affect them both. However, the difference in managing these
problems lies in the approach that you take to the specific issue. For example, a
technology-related problem for a software project might be the low degree of
reuse of the software components created. However, for a car-manufacturing firm,
there is no chance of reusing a component such as a front axle.
You can classify the problems that affect software projects into the following four
categories:
• People-related problems
• Process-related problems
• Product-related problems
• Technology-related problems
⇒ People-related problems
People-related problems in a software project are:
• Low motivation: As the project manager it is your responsibility to ensure an
optimal level of motivation within the team. Lengthy projects, complex
activities1 and scarce resources often decrease the motivation level in a
software development team. However, you need to lead in such a way that the
team is constantly motivated to do a good job.
• Problem employees: Some members of any team always create a problem. For
example, an employee may carry a 'holier-than thou' attitude. Problem
employees raise the chances of conflicts and differences of opinions within
the development team. They lower the efficiency and productivity of other
team members and make it difficult to meet the objectives of the software
project within the specified time. You need to ensure that employees are not
allowed to create a pr9blem for the rest of the team. Even if the employee is
very competent, you need to assess the indispensability of such emp1oyees for
the project. Moreover, you refrain from playing favorite with certain
employees and treat everyone with the same measure.
Software Project Management (CS615)
86
© Copyright Virtual University of Pakistan
• Unproductive work environment: The work environment is a major factor
that affects the productivity of the development team. For example, a noisy or
cramped workspace decreases the motivation levels of the employees.
Similarly, unfriendly organizational policies also lower the motivation of the
team members. As the project manager, you need to ensure that the team is
protected from harmful external make the workspace friendly to work in.
• Inefficient project management style: the project manager needs to lead by
example. The team members absorb the work culture, work ethic, and attitude
of the project manager and implement it in their work style. If you display a
lack of leadership qualities and weak ideals, the motivation levels decrease
across software team.
• Lack of stakeholder interest: For a software project to be a success, each
stakeholder needs to take an active interest in the progress of the project. Al1
stakeholders, including the customer, the management, and the software
development team, need to commit to the success of the project. For example,
if the software development team is not committed to the project, then their
contribution may not be to the optimum level.
• Ineffective project sponsorship by management: Lack of commitment of the
senior management to a software project lowers the motivation level of the
team members. If the management commits to the progress of a software
project, and takes a keen interest in the progress, the confidence of the
software development team will increase.
⇒ Process- related Problems
The process-related problems in a software project are:
• Unrealistic schedule: Assigning unrealistic deadlines for a software project is
a primary reason why software projects are delayed. Often, the marketing or
the management team commit a delivery date to the customer in the hope of
getting the project contract. However, these dates are not decided in
consultation with the development team. The rationale for assigning the
deadlines is unfounded. You need to ensure that the deadlines match the
ability of the software team to deliver the software product. As it is not always
possible to shift deadlines committed to the customer, you also need to plan
the resource allocation and project execution such that the deadlines are met.
• Insufficient identification: Unidentified, partially identified, and unplanned
risks pose a threat to the success of a software project. You need to intensively
identify risks and evolve a risk management plan such that the project is
completed successfully, on time.
Software Project Management (CS615)
87
© Copyright Virtual University of Pakistan
• Unsuitable life cycle model selection: Different software projects require
different SDLC models. For example, a project to create banking .software is
different from software for a satellite where the concept needs to be
researched. For the former example, the Waterfall model is more applicable.
For the latter example, the Spiral model is more suitable. Selecting the correct
life cycle model is critical to the success of a software project.
• Abandoning quality under pressure of deadlines: Where a software project
faces a shortage of resources, time, and funds, project managers often push
away quality concerns and focus on meeting deadlines and staying within the
budget. Abandoning quality has a ripple effect that actually adds even more
time, effort, and costs to the software projects. The cost of doing things right
the first time is lower than the cost of inspection during product delivery.
Also, the cost of inspection is lower than the cost of debugging software after
the customer spots errors.
• Unstructured and hurried software development: When software project
progresses with more focus on meeting deadlines and staying within a budget,
the approach to the software development is unstructured and hurried. You
should plan the software project such that all the activities are identified,
sequenced properly, and roles and responsibilities assigned to the various
people on the project. You should also maintain the focus of the development
team toward a structured approach to software development.
⇒ Product-related Problems
There are many product-related problems that you can face in a software project.
These are:
• Product scope changed toward the end of the project life cycle: The project
time, effort, and cost estimates for a software project can go up dramatically
when the customer changes the scope 9f the product toward the end of the
project. In such situations, you should verify the criticality of the scope
change. However, if the change request is not critical, you should retain the
original scope with a proper explanation to the customer. If the change request
is critical, you should explain the situation to the customer. Usually, a
customer gives more time and funds to a software project if proper
justification is provided. In some cases, the scope change may also be because
of a change in government policy. It may become mandatory for you to
include such change requests.
• Research-oriented software development: Many software projects digress
from the original scope because of the nature of the software product or
technology used. When a totally new kind of software is developed or a new
Software Project Management (CS615)
88
© Copyright Virtual University of Pakistan
technology is used, the software development team can lose focus of the
objectives by getting into a research-oriented approach. It becomes your
responsibility as the project manager to maintain the focus on the objective.
Software Project Management (CS615)
89
© Copyright Virtual University of Pakistan
LECTURE # 12
2. Software Development Fundamentals
Management Fundamentals
2.10 Problems in Software Projects
⇒ Product-related Problems
• III-defined scope: You need to define the scope of the software product in the
initial stages of a software project. The scope of a software product is defined
in terms of the functionality requirements, the performance requirements, the
assumptions, and the constraints on the product. If the product scope is ill
defined, the software project does not have a proper focus on the features
required in the product.
• Fuzzy users: You also need to clarify the background characteristics of the
users of the final software product at the beginning of the software project. If
the description of the users is fuzzy, then the software analysis, design, and
development stages may reflect the ambiguity with regard to the functions and
performance of the final software product.
⇒ Technology-related problems
You may also encounter technology-related problems in a software project. These
include:
• Overestimated savings from reusable components and new tools and
methods: You can reuse software components in a software project to save
time, effort, and cost of creating the component again. It is important that you
assess the savings that the use of such a software component provides to a
software project. This expectation of both the customer and the management
might not be met, if you overestimate the savings from reusing software
components.
• Switching tools in mid way: The current technology environment offers new
tools and technologies for software development at a fast rate. All these tools
and technologies offer the benefits of a shorter development cycle, lower
costs, and under better functionality than earlier tools. You should identify
and commit to the tool and technology for the software project before the
project commences. Switching the tool or technology used during the software
development stage causes the developers to relearn a new tool. In addition,
Software Project Management (CS615)
90
© Copyright Virtual University of Pakistan
there is a chance that it might not be possible to integrate the software already
developed with the new tool.
• Integrating different software products in cross-platform implementation:
The modem software environment requires that all software should integrate
with each other. However, many software projects do not plan for integration
with existing software in the same or different domain. This limits the
applicationofsu9h software and reduces the shelf life drastically. They key to
the success of a software product is interoperability. The software project
manager needs to determine the scope for the software product such that is
can be integrated easily with existing software.
⇒ Summary
The phases in a software project can be organized into a project life cycle. Some
standard life cycle models are the Waterfall model, the Prototyping model, the
Incremental model, and the Spiral model.
Organizational policies and attitudes influence the progress of a software project
and the tasks of a software project manager. For smooth progress of software,
project, the organization should be proactive in adopting changes in technology
and market environments, focused on developing software, and accept software
projects that match the organizational capability baseline. In addition, the
organization should implement employee-friendly human resource policies and
good knowledge management system.
The role of a software project manager includes managing resources, cost, risk,
schedules, project plan, and quality. Software project management activities can
be divided into phases. The main phases and the associated activities are initiating
the project, planning, controlling, and tracking, implementing the product, and
project closedown.
Initiating the project includes gathering requirements, determining the scope,
allocating resources, and creating an initial project plan. Planning, controlling,
and tracking involve creating a detailed project plan, constructing software, and
implementing a control mechanism. Implementing the product comprises
implementation plan, support plan, training plan, and user acceptance plan.
Project closedown includes preparing closedown report, identifying learning for
future projects, and identifying reusable software components for future software
projects.
Problems- affecting software projects can be classified into people-related,
project-related, product-related, and technology-related.
Various myths regarding software project management are adding more people to
a late project can help to finish the project on time, combining the best resources
Software Project Management (CS615)
91
© Copyright Virtual University of Pakistan
with the worst resources results in optimal resource allocation, and changes to the
scope of the software project and the software product can be made at any-time in
the SDLC.
Software Project Management (CS615)
92
© Copyright Virtual University of Pakistan
LECTURE # 13
2. Software Development Fundamentals
Technical Fundamentals
2.11 Requirements Management
⇒ Preview
Software requirements engineering is a process of discovery, refinement,
modeling and specification. The system requirements and role allocated to
software-initially established by the system engineer-are refined in detail.
Models of the required data information and control flow and operational
behavior are created. Alternative solutions are analyzed and a complete
analysis model is created.
Requirements engineering is the systematic use of proven principles,
techniques, languages, and tools for the cost effective analysis,
documentation, and on-going evolution of user needs and the specification
of the external behavior of a system to satisfy those user needs. Notice that
like all engineering disciplines, requirements engineering is not conducted
in a sporadic random or otherwise haphazard fashion, but instead is the
systematic use of proven approaches.
Both the software engineer and customer take an active role in software
requirements engineering-a set of activities that is often referred to as
analysis. The customer attempts to reformulate a sometimes nebulous
system-level description of data, function and behavior into concrete
detail. The developer acts as interrogator, consultant, problem solver and
negotiator.
The overall role of Software in a larger system is identified during system
engineering. However, it's necessary to take a harder look at software's
role-to understand the specific requirements that must be achieved to build
high-quality software. That's the job of software requirements analysis. To
perform the job properly, you should follow a set of underlying concepts
and principles. Generally, a software engineer performs requirements
analysis However, for complex business applications a 'system analyst’
trained in the business aspects of the application domain may perform the
task. If you don't analyze, it's highly likely that you'll build a very elegant
software solution that solves the wrong problem. The result is wasted time
and money, personal frustration and unhappy customers.
Software Project Management (CS615)
93
© Copyright Virtual University of Pakistan
Data, functional, and behavioral requirements are identified by eliciting
information from the customer. Requirements are refined and analyzed to
assess their clarity, completeness, and consistency.
⇒ Requirements analysis
Requirements analysis is a software engineering task that bridges the gap
between system level requirements engineering and software design
(Figure 1). Requirements engineering activities result in the specification
of software's operational characteristics (function, data; and behavior),
indicate software's interface with other system elements, and establish
constraints that software must meet. Requirements analysis allows the
software engineer (sometimes called analyst in this. role) to refine the
software allocation and build models of the data, functional, and
behavioral domains that will be treated by software. Requirements
analysis provides the software designer with a representation of
information, function, and behavior that can be translated to data,
architectural, interface, and component-level designs. Finally, the
requirements specification provides the developer and the customer with
the means to assess quality once software is built.
Figure 1: a bridge between system engineering and software design
Software requirements analysis may be divided into five areas of effort:
(1) Problem recognition,
(2) Evaluation and synthesis,
(3) Modeling
(4) Specification, and
(5) Review
System
Engineerin
g
Software
Design
Software
Requirement
s
Analysis
Software Project Management (CS615)
94
© Copyright Virtual University of Pakistan
Initially, the analyst studies the System Specification (if one exists) and
the Software Project Plan. It is important to understand software in a
system context and to review the software scope that was used to generate
planning estimates. Next, communication for analysis must be established
so that problem recognition is ensured. The goal is recognition of the basic
problem elements as perceived by the customer/users.
Problem evaluation
Problem evaluation and solution synthesis is the next major area of
effort for analysis. The analyst must define all externally observable
data objects, evaluate the flow and content of information, define and
elaborate all software functions, understand software behavior in the
context of events that affect the system, establish system interface
characteristics, and uncover additional design constraints. Each of
these tasks serves to describe the problem so that an overall approach
or solution may be synthesized. For example, an inventory control
system is required for a major supplier of auto parts. The analyst finds
that problems with the current manual system include:
(1) Inability to obtain the status of a component rapidly
(2) Two or three-day turnaround to update a card file
(3) Multiple reorders to the same vendor because there is no way to
associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what
information is to be produced by the new system and what data will be
provided to the system. For instance, is the customer desires a daily
report that indicates what parts have been taken from inventory and
how many similar parts remain. The customer indicates that inventory
clerks will log the identification number of each part as it leaves the
inventory area.
Solution synthesis
Upon evaluating current problems and desired information (input and
output), the analyst begins to synthesize one or more solutions. To
begin, the data objects processing functions and behavior of the system
are defined in detail. Once this information has been established, basic
architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does the
software to support this architecture fall within the scope outlined in
the Software Plan? A database management system would seem to be
required, but is user/customer's need for associativity justified? The
process of evaluation and synthesis continues until both analyst and
Software Project Management (CS615)
95
© Copyright Virtual University of Pakistan
customer feel confident that software can be adequately specified for
subsequent development steps.
Throughout evaluation and solution synthesis, the analyst's primary
focus is on "what, not "how." What data does the system produce and
consume what functions the system must perform. What behaviors do
the system exhibit, what interfaces, are defined and what constraints
apply?
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data and
control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software. The customer may be unsure of precisely what is required.
The developer may be unsure that a specific approach will properly
accomplish function and performance. For these, and many other
reasons, an alternative approach to requirements analysis, called
Prototyping, may be conducted.
Software Project Management (CS615)
96
© Copyright Virtual University of Pakistan
LECTURE # 14
2. Software Development Fundamentals
Technical Fundamentals
2.11 Requirements Management
⇒ Requirements Analysis
• Evaluation and Synthesis
Upon evaluating current problems and desired information (input
and output), the analyst begins to synthesize one or more solutions.
To begin, the data objects processing functions and behavior of the
system are defined in detail. Once this information has been
established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does
the software to support this architecture fall within the scope
outlined in the Software Plan? A database management system
would seem to be required, but is user/customer's need for
associativity justified? The process of evaluation and synthesis
continues until both analyst and customer feel confident that
software can be adequately specified for subsequent development
steps.
Throughout evaluation and solution synthesis, the analyst's
primary focus is on "what, not "how." What data does the system
produce and consume what functions the system must perform.
What behaviors do the system exhibit, what interfaces, are defined
and what constraints apply?
• Models
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data
and control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software.
• Specification
Software Project Management (CS615)
97
© Copyright Virtual University of Pakistan
During the evaluation and solution synthesis activity, the analyst
creates models of the system in an effort to better understand data
and control flow, functional processing, operational behavior, and
information content. The model serves as a foundation for software
design and as the basis for the creation of specifications for the
Software. The customer may be unsure of precisely what is
required. The developer may be unsure that a specific approach
will properly accomplish function and performance. For these, and
many other reasons, an alternative approach to requirements
analysis, called Prototyping, may be conducted.
• Concerns for Review
The customer may be unsure of precisely what is required. The
developer may be unsure that a specific approach will properly
accomplish function and performance. For these, and many other
reasons, an alternative approach to requirements analysis, called
Prototyping, may be conducted.
For example, an inventory control system is required for a major
supplier of auto parts. The analyst finds that problems with the
current manual system include:
(1) Inability to obtain the status of a component rapidly,
(2) Two- or three-day turn- around to update a card file,
(3) Multiple reorders to the same vendor because there is no way to
associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what
information is to be produced by the new system and what data
will be provided to the system. For instance, customer desires a
daily report that indicates what parts have been taken from
inventory and how many similar parts remain. The customer
indicates that inventory clerks will log the identification number of
each part as it leaves the inventory area.
Upon evaluating current problems and desired information (input
and output), the analyst begins to synthesize one or more solutions.
To begin, the data objects, processing functions, and behavior of
the system are defined in detail. Once this information has been
established, basic architectures for implementation are considered.
A client/server approach would seem to be appropriate, but does
the software to support this architecture fall within the scope
outlined in the Software Plan? A database management system
would seem to be required, but is the user/customer's need for
Software Project Management (CS615)
98
© Copyright Virtual University of Pakistan
associativity justified? The process of evaluation and synthesis
continues until both analyst and customer feel confident that
software can be adequately specified for subsequent development
steps.
⇒ Requirements Elicitation for Software
Before requirements can be analyzed, modeled, or specified they must be
gathered through an elicitation process. A customer has a problem that
may be amenable to a computer-based solution. A developer responds to
the customer's request for help.
Communication has begun. But, as we have already noted, the road from
communication to understanding is often full of potholes.
1. Initiating the Process
The most commonly used requirements elicitation technique is to
conduct a meeting or interview. The first meeting between a
software engineer (the analyst) and the customer can be likened to
the awkwardness of a first date between two adolescents. Neither
person knows what to say or ask; both are worried that what they
do say will be misinterpreted; both are thinking about where it
might lead (both likely have radically different expectations here);
both want to get the thing over with, but at the same time, both
want it to be a success. Yet, communication must be initiated.
Gause and Weinberg [GAU89] suggest that the analyst start by
asking context-free questions. That is, a set of questions that will
lead to a basic understanding of the problem, the people who want
a solution, the nature of the solution that is desired, and the
effectiveness of the first encounter itself. The first set of contextfree,
questions focuses on the customer, the overall goals, and the
benefits. For example; the analyst might ask:
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a successful solution?
– Is there another source for the solution that you need?
These questions help to identify all stakeholders who will have
interest in the software to be built. In addition, the questions
identify the measurable benefit of a successful implementation and
possible alternatives to custom software development.
Software Project Management (CS615)
99
© Copyright Virtual University of Pakistan
The next set of questions enables the analyst to gain a better
understanding of the problem and the customer to voice his or her
perceptions about a solution:
– How would you characterize "good" output that would be
generated by a successful solution?
– What problem(s) will this solution address?
– Can you show me (or describe) the environment in which the
solution will be used?
– Will special performance issues or constraints affect the way
the solution is approached?
The final set of questions focuses on the effectiveness of the
meeting. Gause and Weinberg call these meta-questions and
propose the following (abbreviated) list:
– Are you the right person to answer these questions? Are your
answers "official"?
– Are my questions relevant to the problem that you have?
– Am I asking too many questions?
– Can anyone else provide additional information?
– Should I be asking you anything else?
These questions (and others) will help to "break the ice" and
initiate the communication that is essential to successful analysis.
But a question and answer meeting format is not an approach that
has been overwhelmingly successful. In fact, the Q&A session
should be used for the first encounter only and then replaced by a
meeting format that combines elements of problem solving,
negotiation, and specification.
2. Facilitated Application Specification Techniques
Too often, customers and software engineers have an unconscious
"us and them" mind-set. Rather than working as a team to identify
and refine requirements, each constituency defines its own
"territory" and communicates through a series of memos, formal
position papers, documents, and question and answer sessions.
History has shown that this approach doesn't work very well.
Misunderstandings abound, important information is omitted, and
a successful working relationship is never established.
It is with these problems in mind that a number of independent
investigators have developed a team-oriented approach to
requirements gathering that is applied during early stages of
Software Project Management (CS615)
100
© Copyright Virtual University of Pakistan
analysis and specification. Called facilitated application
specification techniques "(FAST).
This approach encourages the creation of a joint team of customers
and developers who work together to:
Identify the problem
Propose elements of the solution
Negotiate different approaches and specify a preliminary set of
solution requirements.
FAST has been used predominantly by the information systems
community, but the technique offers potential for improved
communication in applications of all kinds.
Many different approaches to FAST have been proposed. Each
makes use of a slightly different scenario, but all apply some
variation on the following basic guidelines:
– A meeting is conducted at a neutral site and attended by both
software engineers and customers.
– Rules for preparation and participation are established.
– An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the free
flow of ideas.
– A ‘facilitator’ (can be a; customer, a developer, or an outsider)
controls the meeting.
– A "definition mechanism" (can be work sheets, flip charts, or
wall stickers or an electronic bulletin board, chat room or
virtual forum) is used.
The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a preliminary
set of solution requirements in an atmosphere that is conducive to
the accomplishment of the goal.
To better understand the flow of events as they occur in a typical
FAST meeting, we present a brief scenario that outlines the
sequence of events that lead up to the meeting, occur during the
meeting, and follow the meeting.
Initial meetings between the developer and customer occur and
basic questions and answers help to establish the scope of the
problem and the overall perception of a solution. Out of these
initial meetings, the developer and customer write a one- or twopage
"product request." A meeting place, time, and date for FAST
are selected and a facilitator is chosen. Attendees from both the
Software Project Management (CS615)
101
© Copyright Virtual University of Pakistan
development and customer/user organizations are invited to attend.
The product request is distributed to all attendees before the
meeting date.
3. Quality Function Deployment
A quality management technique that translates needs of customers
into technical requirements of software.
i. Normal Requirement: meeting objectives & goals stated for a
product or system during meeting
i. Expected Requirement: Implicit to products / system and may
be so fundamental that customer does not explicitly state them
i. Exciting Requirement: Features beyond customer’s expectation
and prove to be very satisfying when present
4. Use Cases
As requirements are gathered as part of:
• Informal meeting
• FAST or QFD
SW Engineer can create a set of scenario that identify a thread of
usage for system to be constructed; providing a description of how
system will be used.
5. Analysis Principles
A variety of modeling notations are developed by investigators.
Each analysis method has a unique point of view. However all
analysis methods are related by a set of operational principles like:
– The information domain of a problem must be represented and
understood.
– The functions that the software is to perform must be defined.
– The behavior of the software (as a sequence of external events)
must be represented.
– The models that depict information function and behavior must
be partitioned in a manner that uncovers details in a layered (or
hierarchical) fashion.
Software Project Management (CS615)
102
© Copyright Virtual University of Pakistan
– The analysis process should move from essential information
toward implementation detail.
6. Software Prototyping
Analysis should be conducted regardless of the SW engineering
paradigm. (Various approaches apply)
In some cases it is possible to apply operational analysis principles
and derive a model of SW from which a design can be developed.
In other situation Requirement Elicitation (FAST, QFD etc) is
conducted and a model is built, called Prototype.
Software Project Management (CS615)
103
© Copyright Virtual University of Pakistan
LECTURE # 15
2. Software Development Fundamentals
Technical Fundamentals
2.11 Requirements Management
⇒ The Software Requirements Specification
The Software Requirements Specification is produced at the culmination of the
analysis task, The function and performance allocated to software as part of
system engineering are refined by establishing a complete information
description, a detailed functional description, a representation of system behavior,
an indication of performance requirements and design constraints, appropriate
validation criteria, and other: information pertinent to requirements. The National
Bureau of Standards; IEEE (Standard No. 830-1984), and the U.S. Department of
Defense have all proposed candidate formats for software requirements
specifications (as well as other software engineering documentation).
Mode of specification has a great impact on quality of solution. Forcing SWE to
work with incomplete, inconsistence, or misleading specifications result in
frustration and confusion affecting:
– Quality
– Timeliness and
– Completeness of SW product
• Principles
i. Separate functionality from implementation.
ii. Develop a model of desired behavior of a system that encompasses data and
the functional response of a system to various stimuli from the environment.
iii. Establish the context in which SW operates by specifying the manner in which
other system components interact with software.
iv. Define the environment in which system operates and indicate how a highly
inter-wined collection of agents react to stimuli in the environment (changes
to objects) produced by those agents.
v. Create a cognitive model rather than a design or implementation model.
Cognitive model describes a system as perceived by its user community.
Software Project Management (CS615)
104
© Copyright Virtual University of Pakistan
vi. Recognize that; “the specifications must be tolerant of incompleteness and
augmentable.”
vii. A specification is always a model –an abstraction-of some real (or envisioned)
situation that is normally quite complex. Hence it will be incomplete and will exit
at many levels of detail.
i. Establish the content and structure of a specification in a way that will enable it to
be amenable to change.
• Representation
i. Representation format and content should be relevant to the problem. (A
general outline of SRS can be developed).
ii. Information contained within the specification should be nested.
iii. It should reveal layers of information so that reader can move to the level
of detail required. Paragraph & diagram number scheme to indicate level.
iv. Diagrams and other notational forms should be restricted in number and
consistent in use. (Confusing or inconsistent notations, whether graphical
or symbolic degrades understating and foster errors.)
v. Representation should be revisable.
vi. The content of specification will change. Ideally, CASE tools should be
available to update all representations that are affected by each change.
The function and performance allocated to software as part of system engineering
are refined by establishing:
1. A complete information description,
2. A detailed functional description,
3. A representation of system behavior,
4. An indication of performance requirements and design constraints,
5. Appropriate validation criteria, and other: information pertinent to
requirements.
The Introduction of the software requirements specification states the goals and
objectives of the software, describing it in the context of the computer-based
system; actually, the Introduction may be nothing more than the software scope of
the planning document.
Software Project Management (CS615)
105
© Copyright Virtual University of Pakistan
The Software Requirements Specification is produced at the culmination of the
analysis task. The function and performance allocated to software as part of
system engineering are refined by establishing:
– A complete information description
– A detailed functional description
– A representation of system behavior
– An indication of performance requirements and design constraints
– Appropriate validation criteria and other information pertinent to
requirements.
The Information Description provides a detailed description of the problem that
the software must solve. Information content, flow, and structure are documented.
Hardware, software, and human interfaces are described (or external system
elements: and internal software functions.
A description of each function required to solve the problem is presented in the
Functional Description.
A processing narrative is provided for each function:
– Design constraints are stated and justified
– Performance characteristics are stated, and
– One or more diagrams are included to graphically represent the overall
structure of the software and interplay among software functions and other
system elements
The Behavioral Description section of the specification examines the operation of
the software as a consequence of external events and internally generated control
characteristics.
Validation Criteria is probably the most important and, ironically, the most often,
neglected section of the Software Requirements specification.
– How do we recognize a successful implementation?
– What classes of tests must be conducted to validate function, performance,
and constraints?
We neglect this section because completing it demands a thorough understanding
of software requirements-something that we often do not have at this stage.
Yet, specification of validation criteria acts as an implicit review of all other
requirements. It is essential that time and attention be given to this section.
Finally, the specification includes a Bibliography and Appendix.
Software Project Management (CS615)
106
© Copyright Virtual University of Pakistan
Software Project Management BIT715/Software Project Management CS615 book HANDOUTS in pdf
Post a Comment