LESSON 2 : SOFTWARE PROJECT PLANNING

Contents
2.0.Aims and Objectives
2.1.Introduction
2.2.Planning a Software Project
2.3.Defining the problem
2.4.Developing a Solution Strategy
2.5.Planning the Development Process
2.6.Planning an Organization structure
2.7.Other Planning Activities
2.8.Review Questions
2.9.Let us Sum up
2.10. Lesson End Activities
2.11. Points for Discussion
2.12. References

2.0. AIMS AND OBJECTIVES

• To provide a broad outlook of the steps involved in a software project

planning
• To understand and define software Engineering Models
• To understand the project planning activities, scope and resources.

2.1. INTRODUCTION

The dictionary definition of Project is: a planned undertaking to present

results at a specified time. Note: there the word undertaking means: a. Making
a new product, or b. changing the old product.
The software project management process begins with a set of activities that
are collectively called project planning (see Figure 2.1.). The first of these
activities is estimation. Estimation of resources, cost, and schedule for a
software development effort requires experience, access to good historical
information, and the courage to commit to quantitative measures when only
qualitative data exists. Estimation carries inherent risk and risk leads to
uncertainty. Hence software project estimation must be viewed as an art and
science and must be done as accurately as possible.

19
2.2. PLANNING A SOFTWARE PROJECT

The objective of software project planning is to provide a framework that

enables the manager to make reasonable estimates of resources, cost, and
schedule. These estimates are made within a limited time frame at the

Fig. 2.1. Steps in Software Project Plan

beginning of a software project. Also they should be updated regularly as the
project progresses. The planning objective is achieved through a process of
information discovery that leads to reasonable estimates.
2.2.1. Software Scope
The first activity in software project planning is the determination of
software scope. Software scope describes function, performance, constraints,
interfaces, and reliability. Functions are evaluated and in some cases refined to
provide more detail prior to the beginning of estimation. Both cost and schedule
estimates are functionally oriented and hence some degree of decomposition is

20
often useful. Performance considerations encompass processing and response
time requirements. Constraints identify limits placed on the software by
external hardware, available memory, or other existing systems.
To define scope, it is necessary to obtain the relevant information and
hence get the communication process started between the customer and the
developer. To accomplish this, a preliminary meeting or interview is to be
conducted. The analyst may 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 next set of questions enable the analyst to gain a better
understanding of the problem and the customer to voice his or her perceptions
about a solution. The final set of questions, known as Meta questions, focus on
the effectiveness of the meeting.
A team-oriented approach, such as the Facilitated Application Specification
Techniques (FAST), helps to establish the scope of a project.
2.2.2. Resources
The development resources needed are:
1. Development Environment (Hardware/Software Tools)
2. Reusable Software Components
3. Human Resources (People)
Each resource is specified with four characteristics – description of the
resource, a statement of availability, chronological time that the resource will be
required, and duration of time that the resource will be applied. The last two
characteristics can be viewed as a time window. Availability of the resource for
a specified window must be established at the earliest practical time.
Human Resources: Both organizational positions (e.g. Manager, senior
software engineer, etc.) and specialty (e.g. Telecommunications, database, etc.)
are specified. The number of people required varies for every software project
and it can be determined only after an estimate of development effort is made.
Reusable Software Resources: These are the software building blocks that can
reduce development costs and speed up the product delivery. The four software
resource categories that should be considered as planning proceeds are:
1. Off-the-shelf components – Existing software that can be acquired from a
third-party or that has been developed internally for past project. These are
ready for use and have been fully validated. Generally, the cost for
acquisition and integration of such components will be less than the cost to
develop equivalent software.

21
2. Full-experience components – Existing specifications, designs, code, or
test data developed for past projects that are similar to the current project.
Members of the current software team have had full experience in the
application area represented by these components. Therefore modifications
will be relatively low risk.
3. Partial-experience components - Existing specifications, designs, code, or
test data developed for past projects that are related to the current project,
but will require substantial modification. Members of the current software
team have only limited experience in the application area represented by
these components. Therefore modifications will have a fair degree of low risk
and hence their use for the current project must be analyzed in detail.
4. New components – Software components that must be built by the
software team specifically for the needs of the current project.
Environmental Resources: The environment that supports the software
project, often called Software Engineering Environment (SEE), incorporates
hardware and software. Hardware provides a platform that supports the tools
required to produce the work products. A project planner must prescribe the
time window required for hardware and software and verify that these resources
will be available.
The phases of a software project
Software projects are divided into individual phases. These phases
collectively and their chronological sequence are termed the software life cycle
(see Fig. 2.2).
Software life cycle: a time span in which a software product is developed and
used, extending to its retirement.
The cyclical nature of the model expresses the fact that the phases can be
carried out repeatedly in the development of a software product.

Problem

Operation and Requirements

maintenance analysis

System
System test specification

Implementation System and

and component component
test design
Figure 2.2. The classical sequential software life-cycle
model
22
Requirements analysis and planning phase
Goal:

Determining and documenting:
 Which steps need to be carried out,
 The nature of their mutual effects,
 Which parts are to be automated, and
 Which recourses are available for the realization of the project.
Important activities:

Completing the requirements analysis,

Delimiting the problem domain,

Roughly sketching the components of the target system,

Making an initial estimate of the scope and the economic feasibility of the
planned project, and

Creating a rough project schedule.
Products:

User requirements,

Project contract, and

Rough project schedule.
System specification phase
Goal:

a contract between the client and the software producer (precisely
specifies what the target software system must do and the premises for its
realization.)
Important activities:

Specifying the system,

Compiling the requirements definition,

Establishing an exact project schedule,

Validating the system specification, and

Justifying the economic feasibility of the project.

23
Products:

Requirements definition, and

Exact project schedule.
System and components design
Goal:

Determining which system components will cover which requirements in
the system specification, and

How these system components will work together.
Important activities:

Designing system architecture,

Designing the underlying logical data model,

Designing the algorithmic structure of the system components, and

Validating the system architecture and the algorithms to realize the
individual system components.
Products:

Description of the logical data model,

Description of the system architecture,

Description of the algorithmic structure of the system components, and

Documentation of the design decisions.
Implementation and component test
Goal:

Transforming the products of the design phase into a form that is
executable on a computer.
Important activities:

Refining the algorithms for the individual components,

Transferring the algorithms into a programming language (coding),

Translating the logical data model into a physical one,

Compiling and checking the syntactical correctness of the algorithm, and

Testing, and syntactically and semantically correcting erroneous system
components.

24
Products:

Program code of the system components,

Logs of the component tests, and

Physical data model.
System test
Goal:

Testing the mutual effects of system components under conditions close to
reality,

Detecting as many errors as possible in the software system, and

Assuring that the system implementation fulfills the system specification.
Operation and maintenance
Task of software maintenance:

Correcting errors that are detected during actual operation, and

Carrying out system modifications and extensions.
This is normally the longest phase of the software life cycle.
Two important additional aspects:

Documentation, and

Quality assurance.
During the development phases the documentation should enable
communication among the persons involved in the development; upon
completion of the development phases it supports the utilization and
maintenance of the software product.
Quality assurance encompasses analytical, design and organizational
measures for quality planning and for fulfilling quality criteria such as
correctness, reliability, user friendliness, maintainability, efficiency and
portability.

2.3. DEFINING THE PROBLEM

Most software projects are undertaken to provide solution to business

needs. In the beginning of a software project the business needs are often
expressed informally as part of a meeting or a casual conversation. In a more
formal approach, a customer could send Request For Information (RFI) to
organizations to know their area of expertise and domain specifications. The
customer puts up a Request For Proposal (RFP) stating the business needs.
Organizations will to provide their services will send proposals and one of the
proposals is accepted by the customer.

25
2.4. DEVELOPING A SOLUTION STRATEGY

The business needs have to be understood and the role of software in

providing the solution has to be identified. Software development requires a
model to be used to drive it and tract it to completion. The model will provide
an effective roadmap for the software team.

2.5. PLANNING THE DEVELOPMENT PROCESS

Planning the software development process involves several important

considerations. The first consideration is to define a product life-cycle model. A
software project goes through various phases before it is ready to be used for
practical purposes. For every project, a framework must be used to define the
flow of activities such as define, develop, test, deliver, operate, and maintain a
software product. There are many well define models that can be use. There
could be variations to these models also, depending on the deliverables and
milestones for the project. A model has to be selected and finalized to start a
project.
The following section discusses the various models such as:
a. Waterfall Model
b. Prototype Model
c. Spiral Model
d. Object-oriented life-cycle model
2.5.1. The Waterfall Model
Developed in the 1970s [Royce 1970].
The Waterfall model is one of the oldest models available for software
development and also most widely used. It is also called the Classic Life Cycle
Model. It suggests a systematic and sequential approach to software
development. The different phases are System Engineering, Requirement
Analysis, Design, Coding, Testing and Deployment
Figure 2.3., describes the various stages of the waterfall model. The sequential
move from one phase to the next (as illustrated in figure) gave rise to the name
Waterfall model. The model mandates that each phase will be executed after the
completion of the previous phase. In the figure, the forward arrow describes the
flow between phases and backward arrows (unlike water fall) describe the
feedback mechanism that should exist between phases to provide information
for future development. Each of these phases will now be discussed in detail.

26
 Fig. 2.3. Waterfall Model

Feasibility or Defining a preferred concept for the software product,

Conception and determining its life-cycle feasibility and superiority
to alternative concepts. This phase makes clears certain
issues such as:
 The problem perceived
 The goals to be achieved by the solution
 The benefits from the solution
 The scope of the project.

Requirements or In this phase, the software engineers work with users to

Initiation carry out a macro level study of the user’s requirements.
The software engineers define the various alternatives
possible and the cost-benefit justification of these
alternatives.

Product Design In this phase, the software engineers carry out a detailed
or Analysis study of the user’s requirements. They then arrive at the
proposed system to be built. The model of this system is
used to freeze all requirements before the next phase
begins. This phase generates the functional

27
 specifications, which contain:
 Outputs to be produced
 Inputs that need to be received
 Procedures that will get the output from the input
 Audit and control requirements that the user can
carry out to ensure that the system is acceptable.

Detailed Design: In this phase, the functional specifications are used for
translating the model into a design of the desired
system. The purpose of the design phase is to specify a
particular software system that will meet the stated
requirements. The design specifications that get
generated at the end of this phase are technical in
nature and typically contain:
 User interfaces
 Databases and data structures
 Algorithms and program structures
 Equipment, personnel and other facilities required
 Manual procedures that will be part of the
implemented system

Coding or This phase produces the actual code that will be

Construction delivered to the customer as the running system.
Individual modules developed in this phase are tested
before being delivered to the next phase.

Integration or All the modules that have been developed before are
Testing integrated or put together in this phase, and tested as a
complete system.

Implementation: Once the system has passed all the tests, it is delivered
to the customer.

Maintenance: Modifications made after delivery are a part of this

phase.

Phase out: A clean transition of the functions performed by the

product to its successors.

The waterfall model is ideal in situations where the requirements are well
defined from the beginning. And undergo only minor changes. However, the

28
requirements for a large number of applications are less stable and not perfectly
known at the very beginning. Even in cases where the initial requirements are
clear, changes are still likely to occur. For example, changes in technology can
cause changes in the initial requirements. This is particularly turn of interactive
end user applications. Most software systems of this kind are dynamic – they
are required to change over time as they acquire more users. To constrain the
development of this kind of software in a rigid process, such as the Waterfall
model, can prove counter-productive. Due to these deficiencies in the Waterfall
model, an alternative – The Evolutionary model – was developed.
2.5.2. The prototyping-oriented life-cycle model
Developed in the 1990s [Pomberger 1991].
This model is an example of an iterative approach to software
development, which is useful when either the customer or the developer is
unsure of the exact requirements of the software. The developer creates a
model of the system to be built.
This model may be one of the following types:
a) Throwaway model: Discard the model once all requirements are
understood
b) Evolving model: Refine the model every time when the requirements
are clearer
Irrespective of whether it’s a Throwaway or Evolving model prototyping
starts with the communication phase as described in Figure 2.4. The software
engineer and the customer together define the overall objective for the software,
identify the requirements that are known and outline area for further definition.
The iteration is planned quickly and modeled in quick design. The design
focuses only in the aspects which are visible to the user. The quick design
leads to the construction of a prototype. The prototype is evaluated by the
customer. The feedback is taken and used to refine the requirements for the
software. The iterations continue, each time refining the software. Prototype
Model is extremely useful for doing proof of concepts. The rapid development
process can test out new concepts at minimal cost.

29
 Quick Plan
Modeling Quick
design

Communication Prototype
Model

Construction of
Prototype
Development or
Feedback

Fig. 2.4: Prototype Oriented-Life cycle Model

Advantages
 Changes can be made easily – An appreciable number of the changes in
requirement trigger modifications only in the prototype. Modifying a
prototype description is significantly simpler than modifying production
code.
 Costs are reduced – Modifying the prototype is much faster and cheaper
than modifying the production code.
 User’s requirements become clearer to the developer – Usually, the user’s
requirements are unclear, and the developer is uncertain about what the
user meant. Prototyping is the best solution in such cases. The developer
can build a prototype and demonstrate to the user his or her
understanding of the user’s requirements. The user can then verify if the
prototype represents his or her requirement.
 User involvement is higher – The user is involved in the development of
the system from the very beginning. The user gets a feel of what the real
system will look like and suggests changes that he or she desires.
Disadvantages
Disadvantage is that it may lead to indiscipline of development (which
the classic life cycle model tries to overcome). For example, if some new
requirements are received while in the construction phase, the engineer may
drop construction and go back to planning or communication with customer.
At some point of time the customer requirements has to be frozen in

30
conformance with the customer or else it becomes on unending processing,
consuming project’s time and resources.
When to Use Prototyping: Prototyping is fast becoming popular. It is best
suited in situations where:
 The user is unable to articulate his or her requirements.
 The user is unwilling or unable to look at abstract models of the system,
for example, data flow diagrams.
 The biggest problem area is the user interface. For example, report
formats and input screens. The developer can confirm the type of reports
that screens that the user wants. User interfaces are the most important
aspect of end user applications.
 Good tools are available for prototyping. Tools like screen painters and
fourth generation language aid the process of prototyping.
Check your Progress 1
State whether true of false:
a) The prototype is always required to be a small version of the entire
system.
b) The difference between the early approach to prototyping and the new
approach (Evolutionary model) is that in the latter the prototype is not
discarded. It is modified and enlarged to eventually become the real
system

31
2.5.3. The Spiral model
Developed in 1988 [Boehm 1988].
The spiral model is a software development model that combines the
above models or includes them as special cases. The model makes it possible to
choose the most suitable approach for a given project. Each cycle encompasses
the same sequence of steps for each part of the target product and for each
stage of completion. It is an evolutionary software process model (see Fig. 2.5).
The model has a series of evolutionary releases of the software as it is being
developed. Every iterative release might be a prototype. The later releases are
more complete versions of the software to be produced.
The development strategy behind the Spiral model has been stated as:
• Deliver something to the user.
• Measures the added value to the user in all critical dimensions.
• Adjust both the design and objectives based on observed realities.
The next step evaluates the proposed solution variant with respect to the
project goals and applicable constraints, emphasizing the detection of risks and
uncertainties. If such are found, measures and strategies are considered to
reduce these risks and their effects.

32

Important aspects of the spiral model: Each cycle has its own
validation step that includes all persons participating in the project and
the affected future users or organizational unit,

Validation encompasses all products emanating from the cycle, including
the planning for the next cycle and the required resources

Spiral model contains six task regions:

 Customer communication: tasks required to establish effective

communication between developer and customer.
 Planning-tasks required defining resources, timelines, and other project
–related information.
 Risk analysis – tasks required to assess both technical and management
risks.
 Engineering – tasks required to build one or more representations of the
application.
 Construction and release – tasks required to construct, test, install,
and provide user support (e.g., documentation and training).
 Customer evaluation – tasks required to obtain customer feedback
based on evolution of the software representations created during the
engineering.

Advantages and Disadvantages

The spiral model thus encompasses the earlier models and also introduces the
element of risk analysis. It is more realistic because real-world engineering
requires considerable iteration. The disadvantage of the spiral model is that it
requires considerable expertise in terms of risk assessment and project
management.

Check your progress

i. Compare waterfall model and spiral model of software development. Give
the advantages and disadvantages of each.

ii. Compare evolutionary prototyping and throw away prototyping.

33
2.5.4.. The object-oriented life-cycle model

• The usual division of a software project into phases remains intact with
the use of object-oriented techniques.
• The requirements analysis stage strives to achieve an understanding of
the client’s application domain.
• The tasks that a software solution must address emerge in the course of
requirements analysis.
• The requirements analysis phase remains completely independent of an
implementation technique that might be applied later.
• In the system specification phase the requirements definition describes
what the software product must do, but not how this goal is to be
achieved.
• One point of divergence from conventional phase models arises because
implementation with object-oriented programming is marked by the
assembly of already existing components.

The advantages of object-oriented life-cycle model:

• Design no longer is carried out independently of the later
implementation because during the design phase we must consider
which components are available for the solution of the problem.
Design and implementation become more closely associated, and even
the choice of a different programming language can lead to completely
different program structures.
• The duration of the implementation phase is reduced. In particular,
(sub) products become available much earlier to allow testing of the
correctness of the design. Incorrect decisions can be recognized and
corrected earlier. This makes for closer feedback coupling of the
design and implementation phases.
• The class library containing the reusable components must be
continuously maintained. Saving at the implementation end is
partially lost as they are reinvested in this maintenance. A new job
title emerges, the class librarian, who is responsible for ensuring the
efficient usability of the class library.

34
 • During the test phase, the function of not only the new product but
also of the reused components is tested. Any deficiencies in the latter
must be documented exactly. The resulting modifications must be
handled centrally in the class library to ensure that they impact on
other projects, both current and future.
• Newly created classes must be tested for their general usability. If
there is a chance that a component could be used in other projects as
well, it must be included in the class library and documented
accordingly. This also means that the new class must be announced
and made accessible to other programmers who might profit from it.
This places new requirements on the in-house communication
structures.
The class library serves as a tool that extends beyond the scope of an individual

Requirements
analysis

System

Design Implementation Test Operation/maintena

Planni Us Introduction
ng e

Implementatio

Documentation
Class
project because classes provided
Fig. 2.6: Objectby one projectcycle
Oriented-Life can increase
Model productivity in
subsequent projects.
The actual software life cycle recurs when new requirements arise in the
company that initiates a new requirements analysis stage.
The object and prototyping-oriented life-cycle model
The specification phase steadily creates new prototypes. Each time we
are confronted with the problem of having to modify or enhance existing
prototypes. If the prototypes were already implemented with object-oriented
technology, then modifications and extensions are particularly easy to carry out.
This allows an abbreviation of the specification phase, which is particularly
important when proposed solutions are repeatedly discussed with the client.
With such an approach it is not important whether the prototype serves solely
for specification purposes or whether it is to be incrementally developed to the
final product. If no prototyping tools are available, object-oriented programming
can serve as a substitute tool for modeling user interfaces. This particularly
applies if an extensive class library is available for user interface elements.

35
 For incremental prototyping (i.e. if the product prototype is to be used as the
basis for the implementation of the product), object-oriented programming also
proves to be a suitable medium. Desired functionality can be added stepwise to
the prototypes without having to change the prototype itself. These results in a
clear distinction between the user interfaces modeled in the specification phase
and the actual functionality of the program. This is particularly important for
the following reasons:
• This assures that the user interface is not changed during the
implementation of the program functionality. The user interface developed
in collaboration with the client remains as it was defined in the
specification phase.
• In the implementation of the functionality, each time a subtask is
completed, a more functional prototype results, which can be tested
(preferably together with the client) and compared with the specifications?
During test runs situations sometimes arise that require rethinking the
user interface. In such cases the software life cycle retreats one step and
a new user interface prototype is constructed.
Since the user interface and the functional parts of the program are largely
Requirements

User interface design Design of functional

parts

Prototyping User interface design

User interface classes Function-oriented

Product classes

Integration

Prototype

Test and validation

Product

Fig. 2.7: Software development with prototyping and object-orientation

decoupled, two cycles result that shares a common core. The integration of the
functional classes and the user interface classes creates a prototype that can be
tested and validated. This places new requirements on the user interface
and/or the functionality, so that the cycle begins.
Types of project planning:

Plan Type Description

36
Quality plan Describes the quality procedures and standards that will
be used in a project.

Validation plan Describes the approach, resources and schedule used for
system validation.

Configuration Describes the configuration management procedures and

management structures to be used.
plan

Maintenance Predicts the maintenance requirements of the system,

plan maintenance costs and effort required.

Staff Describes how the skills and experience of the project

development team members will be developed. See
plan

2.6. PLANNING AN ORGANIZATION STRUCTURE

Completing a software project is a team effort. The following options are

available for applying human resources to a project that will require ‘n’ people
working for ‘K’ years.
• ‘n’ individuals are assigned to ‘m’ different functional tasks.
• ‘n’ individuals are assigned to ‘m’ different functional tasks (m<n) so that
informal teams are established and coordinated by project manager.
• ‘n’ individuals are organized into ‘t’ teams and each team is assigned
one/more functional tasks.
Even though the above three approaches have their pros and cons, option 3
is most productive.
There are several roles within each software project team. Some of the roles
in a typical software project are listed below:

Designation Job Profile

Project Initiates, plans, tracks and manages resources of an entire

Manager project

Module A software engineer who manages and leads the team working
Leader on a particular module of the software project. The module
leader will conduct reviews and has to ensure the proper

37
 functionality of the module

Analyst A software engineer who analyzes the requirements gathered.

Analysis of the requirements is done to get a clear
understanding of the requirements.

Domain An expert who knows the system of which the software is a

Consultant part. This would involve the technical knowledge of how the
entities of the domain interface with the software being
developed. For example, a banking domain consultant or a
telecom domain consultant.

Reviewer A software engineer who reviews artifacts like project

documents or code. The review can be a technical review
which scrutinizes the technical details of the artifact. It could
be a review where the reviewer ascertains whether or not the
artifact adheres to a prescribed standard

Architect A software engineer involved in the design of the solution after

the analyst has clearly specified the business requirements

Developer A software engineer, who writes the code, tests it and delivers
it error free

Tester A software engineer who conducts tests on the completed

software or a unit of the software. If any defects are found
these defects are logged and a report is sent to the owner of
the tested unit.

Programming Team Structure

Every programming team must have an internal structure. The best team
structure for any particular project depends on the nature of the project and
the product, and on the characteristics of the individual team members. Basic
team structure includes:
a. Democratic team: Team Member participate in all decisions
b. Chief Programmer Team: A chief programmer is assisted and
supported by other team members.
c. Hierarchical Team: The project leader assigns tasks attend reviews and
walkthrough, detects problem areas, balances the workload and
participates in technical activities.
Democratic Team

38
 This was first described by Weinberg as the “egoless team”. In an egoless
team goals are set and decisions made by group consensus. Group leadership
rotates from member to member based on the tasks to be performed and the
differing abilities of the team members. Work products (requirements, design,
source code, user manual, etc) are discussed openly and are freely examined by
all team members.
Advantage:
 Opportunity for each team member to contribute to decision
 Opportunity for team members to learn from one another
 Increased Job satisfaction that results from good communication in open,
non-threatening work environments.
Disadvantages
 Communication overhead required in reaching decision,
 All team members must work well together,
 Less individual responsibility and authority can result in less initiative
and less personal drive from team members.
The chief programmer team
Baker's organizational model ([Baker 1972])

Important characteristics:
• The lack of a project manager who is not personally involved in
system development
• The use of very good specialists
• The restriction of team size

The chief programmer team consists of:
• The chief programmer
• The project assistant
• The project secretary
• Specialists (language specialists, programmers, test specialists).

The chief programmer is actively involved in the planning, specification and
design process and, ideally, in the implementation process as well.

The chief programmer controls project progress, decides all important
questions, and assumes overall responsibility.

The qualifications of the chief programmer need to be accordingly high.

39

The project assistant is the closest technical coworker of the chief
programmer.

The project assistant supports the chief programmer in all important
activities and serves as the chief programmer's representative in the latter's
absence. This team member's qualifications need to be as high as those of
the chief programmer.

The project secretary relieves the chief programmer and all other
programmers of administrative tasks.

The project secretary administrates all programs and documents and assists
in project progress checks.

The main task of the project secretary is the administration of the project
library.

The chief programmer determines the number of specialists needed.

Specialists select the implementation language, implement individual
system components, choose and employ software tools, and carry out tests.
Advantages
• The chief programmer is directly involved in system development and can
better exercise the control function.
• Communication difficulties of pure hierarchical organization are
ameliorated. Reporting concerning project progress is institutionalized.
• Small teams are generally more productive than large teams.
Disadvantages
• It is limited to small teams. Not every project can be handled by a small
team.
• Personnel requirements can hardly be met. Few software engineers can
meet the qualifications of a chief programmer or a project assistant.
• The project secretary has an extremely difficult and responsible job,
although it consists primarily of routine tasks, which gives it a
subordinate position. This has significant psychological disadvantages.
Due to the central position, the project secretary can easily become a
bottleneck.
The organizational model provides no replacement for the project secretary. The
loss of the project secretary would have failing consequences for the remaining
course of the project.
Hierarchical organizational model

There are many ways to organize the staff of a project. For a long time the
organization of software projects oriented itself to the hierarchical
organization common to other industrial branches. Special importance is

40
 vested in the decomposition of software development into individual phases.
A responsible leader is assigned to each of the phases, which are led and
controlled by the project leader and which, depending on the size of the
project, are led and controlled either by a single person or by a group leader.

The project manager normally also has a project management staff with
advisory and administrative tasks.

The larger the project, the greater is the number of hierarchy levels in the
organizational schema.
The project manager's tasks and responsibilities encompass
• personnel selection,
• assignment and management,
• planning of and division of labor for the project,
• project progress checks, and
• appropriate measures in case of cost or schedule overruns.

The project management staff includes personnel who advise the project
manager in task-specific questions, provide support in administrative tasks
concerning project progress checks, prepare project standards, provide the
necessary resources, and carry out training for project team members as
needed.

The managers at the middle management level are responsible for planning,
execution and control of phase-related activities of the software life cycle.

2.7. OTHER PLANNING ACTIVITIES

Project management is the discipline of defining and achieving targets

while optimizing the use of resources (time, money, people, materials, energy,
space, etc) over the course of a project (a set of activities of finite duration).
Project Management is quite often the province and responsibility of an
individual project manager. This individual seldom participates directly in the
activities that produce the end result, but rather strives to maintain the
progress and productive mutual interaction of various parties in such a way
that overall risk of failure is reduced.
In contrast to on-going, functional work, a project is "a temporary
endeavor undertaken to create a unique product or service." The duration of a
project is the time from its start to its completion, which can take days, weeks,
months or even years. Typical projects include the engineering and construction
of various public or consumer products, including buildings, vehicles, electronic
devices, and computer software.
Project Management is composed of several different types of activities such as:

41
 • Planning the work
• Assessing risk
• Estimating resources
• Organizing the work
• Acquiring human and material resources
• Assigning tasks
• Directing activities
• Controlling project execution
• Reporting progress
• Analyzing the results based on the facts achieved
Project control variables
Project Management tries to gain control over five variables:
Time - The amount of time required to complete the project. Typically broken
down for analytical purposes into the time required to complete the components
of the project, which is then further broken down into the time required to
complete each task contributing to the completion of each component.
Cost - Calculated from the time variable. Cost to develop an internal project is
time multiplied by the cost of the team members involved. When hiring an
independent consultant for a project, cost will typically be determined by the
consultant or firm's hourly rate multiplied by an estimated time to complete.
Quality - The amount of time put into individual tasks determines the overall
quality of the project. Some tasks may require a given amount of time to
complete adequately, but given more time could be completed exceptionally.
Over the course of a large project, quality can have a significant impact on time
and cost (or vice versa).
Scope - Requirements specified for the end result. The overall definition of what
the project is supposed to accomplish, and a specific description of what the
end result should be or accomplish.
Risk - Potential points of failure. Most risks or potential failures can be
overcome or resolved, given enough time and resources.
Three of these variables can be given by external or internal customers.
The value(s) of the remaining variable(s) is/are then set by project management,
ideally based on solid estimation techniques. The final values have to be agreed
upon in a negotiation process between project management and the customer.
Usually, the values in terms of time, cost, quality and scope are contracted.

2.8. REVIEW QUESTIONS

42
 1. Discuss project scheduling.
2. Discuss Human-resources planning.
3. What kind of team structure would you recommend for waterfall method
and prototyping?

2.9. LET US SUM UP

Defining the problem

1 Develop a definitive statement of the problem to be solved. Include a
description of the present situation, problem constraints, and a statement of
the goals to be achieved. The problem statement should be phrased in the
customer’s terminology
2 Justify a computerized solution strategy for the problem.
3 Identify the functions to be provided by, and the constraints on, the
hardware subsystem, the software subsystem, and the people subsystem.
4 Determine system-level goals and requirements for the development process
and the work products.
5 Establish high-level acceptance criteria for the system.
Developing a solution strategy
6 Outline several solution strategies, without regard for constraints.
7 Conduct a feasibility study for each strategy.
8 Recommend a solution strategy, indicating why other strategies were
rejected.
9 Develop a list of priorities for product characteristics.
Planning the development process
10 Define a life-cycle model and an organizational structure for the project
11 Plan the configuration management, quality assurance, and validation
activities.
12 Determine phase-dependent tools, techniques, and notations to be used

2.10. LESSON END ACTIVITIES

Suppose we wish to computerize the activities of Department, which offer

various programmes of the university. The activities are as follows:
 Forwarding the faculties bio-data to University
 Schedule the classes (both theory and practical)
 Identify Practical Centres

43
  Collect Assignments from students and get it evaluated by faculties
 Students enquiry
 Dispatch of grades to university
Develop a system requirement Specification, design DFDs, and identify modules
and its operations. Select appropriate data structures for the various modules.

2.11. POINTS FOR DISCUSSION

1. Akkash wants to build a restaurant. He calls upon Rithanya, a famous

architect and builder, for this task. Rithanya goes through the following steps:
a) She first talks to Akkash to understand the general specifications.
b) She then draws the complete plan on how to go about building the
structure.
c) Then, with the help of a contractor, she finishes the building in one year.
The steps that Rithanya has gone through are similar to some of the phases of
the Waterfall Model. Identify them.

2. As far as the new user is concerned, which approach do you think will be
more appreciated – Waterfall or Prototyping?

2.12. REFERENCES

1. Richard Fairley, “Software Engineering Concepts”, Tata McGraw-Hill, 1997.

2. Roger S.Pressman, Software engineering- A practitioner’s Approach,
McGraw-Hill International Edition, 5th edition, 2001.
3. IEEE, Standards Collection, Software Engineering, IEEE, New York, 1994

44
4. J.C. Wethebe and N.P. Vitalani, System Analysis and Design: Best Approach,
Ed.4, West, St. Paul 1994.

45