Topic 3 Notes
Topic 3 Notes
Topic 3 Notes
Topic 3 Notes
Introduction
The job pattern of an IT company engaged in software development can be seen
split in two parts:
i. Software Creation
ii. Software Project Management
A project is well-defined task, which is a collection of several operations done in order to achieve
a goal (for example, software development and delivery). A Project can be characterized as:
i. Every project may have a unique and distinct goal.
ii. Project is not a routine activity or day-to-day operation.
iii. Project comes with a start and end time.
iv. Project ends when its goal is achieved. Hence, it is a temporary phase in
v. the lifetime of an organization.
vi. Project needs adequate resources in terms of time, manpower, finance,
material, and knowledge-bank.
Software Project
A Software Project is the complete procedure of software development from requirement gathering
to testing and maintenance, carried out according to the execution methodologies, in a specified
period of time to achieve intended software product.
The image above shows triple constraints for software projects. It is an essential part of software
organization to deliver quality product, keeping the cost within client’s budget constrain and
deliver the project as per scheduled. There are several factors, both internal and external, which
may impact this triple constrain triangle. Any of the three factors can severely impact the other
two.
Therefore, software project management is essential to incorporate user requirements along with
budget and time constraints.
The sum of time required to complete all tasks in hours or days is the total time invested
to complete the project.
Cost estimation
This might be considered as the most difficult of all because it depends on more elements
than any of the previous ones. For estimating project cost, it is required to consider -
i. Size of the software
ii. Software quality
iii. Hardware
iv. Additional software or tools, licenses etc.
v. Skilled personnel with task-specific skills
vi. Travel involved
vii. Communication
viii. Training and support
i. Decomposition Technique
This technique assumes the software as a product of various compositions. There are two main
models -
a) Line of Code: Here the estimation is done on behalf of number of line of codes in the
software product.
b) Function Points: Here the estimation is done on behalf of number of function points
in the software product.
Project Scheduling
Project Scheduling in a project refers to roadmap of all activities to be done with specified order
and within time slot allotted to each activity. Project managers tend to define various tasks, and
project milestones and then arrange them keeping various factors in mind. They look for tasks like
in critical path in the schedule, which are necessary to complete in specific manner (because of
task interdependency) and strictly within the time allocated. Arrangement of tasks which lies out
of critical path are less likely to impact over all schedule of the project.
For scheduling a project, it is necessary to -
i. Break down the project tasks into smaller, manageable form
ii. Find out various tasks and correlate them
iii. Estimate time frame required for each task
iv. Divide time into work-units
v. Assign adequate number of work-units for each task
vi. Calculate total time required for the project from start to finish
Resource management
All elements used to develop a software product may be assumed as resource for that project. This
may include human resource, productive tools, and software libraries.
The resources are available in limited quantity and stay in the organization as a pool of assets. The
shortage of resources hampers development of the project and it can lag behind the schedule.
Allocating extra resources increases development cost in the end. It is therefore necessary to
estimate and allocate adequate resources for the project.
Resource management includes -
i. Defining proper organization project by creating a project team and allocating
responsibilities to each team member
ii. Determining resources required at a particular stage and their availability
iii. Manage Resources by generating resource request when they are required and de-
allocating them when they are no more needed.
Configuration Management
Configuration management is a process of tracking and controlling the changes in software in
terms of the requirements, design, functions and development of the product.
IEEE defines it as “the process of identifying and defining the items in the system, controlling the
change of these items throughout their life cycle, recording and reporting the status of items and
change requests, and verifying the completeness and correctness of items”.
Generally, once the SRS is finalized there is less chance of requirement of changes from user. If
they occur, the changes are addressed only with prior approval of higher management, as there is
a possibility of cost and time overrun.
Baseline
A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement that defines
completeness of a phase. A phase is baselined when all activities pertaining to it are finished and
well documented. If it was not the final phase, its output would be used in next immediate phase.
Configuration management is a discipline of organization administration, which takes care of
occurrence of any changes (process, requirement, technological, strategical etc.) after a phase is
baselined. CM keeps check on any changes done in software.
Change Control
Change control is function of configuration management, which ensures that all changes made to
software system are consistent and made as per organizational rules and regulations.
A change in the configuration of product goes through following steps -
i. Identification - A change request arrives from either internal or external
source. When change request is identified formally, it is properly documented.
ii. Validation - Validity of the change request is checked and its handling
procedure is confirmed.
iii. Analysis - The impact of change request is analyzed in terms of schedule,
cost and required efforts. Overall impact of the prospective change on system is analyzed.
iv. Control - If the prospective change either impacts too many entities in the
system or it is unavoidable, it is mandatory to take approval of high authorities before
change is incorporated into the system. It is decided if the change is worth incorporation
or not. If it is not, change request is refused formally.
v. Execution - If the previous phase determines to execute the change
request, this phase takes appropriate actions to execute the change, through a thorough
revision if necessary.
vi. Close request - The change is verified for correct implementation and
merging with the rest of the system. This newly incorporated change in the software is
documented properly and the request is formally closed.
PERT Chart
PERT Chart
(Program Evaluation & Review Technique) (PERT) chart is a tool that depicts project as network
diagram. It is capable of graphically representing main events of project in both parallel and
consecutive ways. Events, which occur one after another, show dependency of the later event over
the previous one.
Events are shown as numbered nodes. They are connected by labeled arrows depicting the
sequence of tasks in the project.
Resource Histogram
This is a graphical tool that contains bar or chart representing number of resources (usually skilled
staff) required over time for a project event (or phase). Resource Histogram is an effective tool for
staff planning and coordination.