Unit-1

What is Project?
 A project is a group of tasks that need to complete to reach a clear
result.

 A project also defines as a set of inputs and outputs which are

required to achieve a goal.

 Projects can vary from simple to difficult and can be operated by

one person or a hundred.

 Projects usually described and approved by a project manager or

team executive. They go beyond their expectations and objects,
and it's up to the team to handle logistics and complete the project
on time.

 For good project development, some teams split the project into
specific tasks so they can manage responsibility and utilize team
strengths.

What Is Software Project Management?

 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.

 Software project management refers to the branch of project

management dedicated to the planning, scheduling, resource
allocation, execution, tracking and delivery of software and web
projects.
  Software project management is an art and discipline of planning
and supervising software projects.

 It is a sub-discipline of software project management in which

software projects planned, implemented, monitored and controlled.

 It is a procedure of managing, allocating and timing resources to

develop computer software that fulfills requirements.

 In software Project Management, the client and the developers

need to know the length, period and cost of the project.

Prerequisite of software project management?

There are three needs for software project management. These are:

1. Time
2. Cost
3. Quality

It is an essential part of the software organization to deliver a quality

product, keeping the cost within the client?s budget and deliver the
project as per schedule. There are various factors, both external and
internal, which may impact this triple factor. Any of three-factor can
severely affect the other two.

Project Manager

A project manager is a character who has the overall responsibility for

the planning, design, execution, monitoring, controlling and closure of a
project.

A project manager represents an essential role in the achievement of the

projects.

A project manager is a character who is responsible for giving decisions,

both large and small projects. The project manager is used to manage the
risk and minimize uncertainty. Every decision the project manager
makes must directly profit their project.

Role of a Project Manager:

Software project managers may have to do any of the following tasks:

1. Planning: This means putting together the blueprint for the

entire project from ideation to fruition. It will define the
scope, allocate necessary resources, propose the timeline,
delineate the plan for execution, lay out a communication
strategy, and indicate the steps necessary for testing and
maintenance.
2. Leading: A software project manager will need to assemble
and lead the project team, which likely will consist of
developers, analysts, testers, graphic designers, and technical
writers. This requires excellent communication, people and
leadership skills.
3. Execution: The project manager will participate in and
supervise the successful execution of each stage of the
project. This includes monitoring progress, frequent team
check-ins and creating status reports.
4. Time management: Staying on schedule is crucial to the
successful completion of any project, but it’s particularly
challenging when it comes to managing software projects
because changes to the original plan are almost certain to
occur as the project evolves. Software project managers must
be experts in risk management and contingency planning to
ensure forward progress when roadblocks or changes occur.
5. Budget: Like traditional project managers, software project
managers are tasked with creating a budget for a project, and
then sticking to it as closely as possible, moderating spend
and re-allocating funds when necessary.
 6. Maintenance: Software project management typically
encourages constant product testing in order to discover and
fix bugs early, adjust the end product to the customer’s
needs, and keep the project on target. The software project
manager is responsible for ensuring proper and consistent
testing, evaluation and fixes are being made.
Need of software project management:
Software is said to be an intangible product. Software development is a
kind of all new stream in world business and there’s very little
experience in building software products.
Most software products are tailor made to fit client’s requirements. The
most important is that the underlying technology changes and advances
so frequently and rapidly that experience of one product may not be
applied to the other one.
All such business and environmental constraints bring risk in software
development hence it is essential to manage software projects
efficiently.

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 three factor can severely impact the
other two.
Therefore, software project management is essential to incorporate user
requirements along with budget and time constraints.
Advantages of Software Project Management:
 It helps in planning of software development.
 Implementation of software development is made easy.
 Monitoring and controlling are aspects of software project
management.
 It overall manages to save time and cost for software
development.

Software Project Management consists of several different type of

managements:
1. Conflict Management:
Conflict management is the process to restrict the negative features
of conflict while increasing the positive features of conflict. The
goal of conflict management is to improve learning and group
results including efficacy or performance in an organizational
setting. Properly managed conflict can enhance group results.
2. Risk Management:
Risk management is the analysis and identification of risks that is
followed by synchronized and economical implementation of
resources to minimize, operate and control the possibility or effect
of unfortunate events or to maximize the realization of
opportunities.

3. Requirement Management:
It is the process of analyzing, prioritizing, tracing and documenting
on requirements and then supervising change and communicating
to pertinent stakeholders. It is a continuous process during a
project.
4. Change Management:
Change management is a systematic approach for dealing with the
transition or transformation of an organization’s goals, processes
or technologies. The purpose of change management is to execute
strategies for effecting change, controlling change and helping
people to adapt to change.
5. Software Configuration Management:
Software configuration management is the process of controlling
and tracing changes in the software, part of the larger cross-
disciplinary field of configuration management. Software
configuration management include revision control and the
inauguration of baselines.

6. Release Management:
Release Management is the task of planning, controlling and
scheduling the build in deploying releases. Release management
ensures that organization delivers new and enhanced services
required by the customer, while protecting the integrity of existing
services.
  Project As A System:s
It is also known as Project Management Information system (PMIS)
which is the coherent organization to execute projects successfully. 
 A PMIS is typically one or more software applications and depending
upon an organization's operational requirements a methodical process
for collecting and using project information. These electronic systems
help plan,execute and close project management goals.
A project is concerned with creating a new system and/or transforming
an old one and is itself a system.
Systems, subsystems and environments
A simple definition of the term system is 'a set of interrelated parts'. A
system will normally be part of a larger system and w ill itself comprise
subsystems.
Outside the system there will be the system's environment. This will be
made up of things that can affect the system but over w hich the system
has no direct control. In the case of Brightmouth College, the bankruptcy
of the main supplier of IT equipment would be an event happening in the
system's environment.
What important entities exist in the payroll system's environment?
Open versus closed systems
Open systems are those that interact with the environment. Nearly all
systems arc open. One reason that engineered systems and the projects
to construct them often fail is that the technical staff involved do not
appreciate the extent to which systems are open and are liable to be
affected by outside changes.
Sub-optimization
This is w here a subsystem is working at its optimum but is having a
detrimental effect on the overall system. An example of this might be
where software developers deliver to the users a system that is very
efficient in its use of machine resources, but is also very difficult to
modify.
Sociotechnical systems
Software projects belong to this category of systems. Any software
project requires both technological organization and also the
organization of people. Software project managers therefore need to have
both technical competence and the ability to interact persuasively w ith
other people.

 (Add in the management control topic in book)

Objectives
Project objectives should To have a successful software project, the
manager and the project team members be clearly defined. must know
what will constitute success. This will make them concentrate on what is
essential to project success.
There might be more than one set of users of a system and there might
be different groups of staff who are involved its development. There is a
need for well defined objectives that are accepted by all these people.
Where there is more than one user group, then a project authority needs
to be identified. Such a project authority has overall authority over what
the project is to achieve.
Measures of effectiveness
Effective objectives are concrete and well defined. Vague aspirations
such as 'to improve customer relations' are unsatisfactory. Objectives
should be such that it is obvious to all whether the project has been
successful or not. Ideally there should be measures of effectiveness,
which tell us how successful the project has been. For example, 'to
reduce customer complaints by 50%' would be more satisfactory as an
objective than 'to improve customer relations'.
Sub-objectives and goals
In order to keep things manageable, objectives might need to be broken
down into sub-objectives. Here we say that in order to achieve A we
must achieve B, C and D first. These sub-objectives are also known as
goals, steps on the way to achieving an objective, just as goals scored in
a football match are steps towards the objective of winning the match.
This committee is likely to contain user, development and management
representatives.
The measure can, in some cases, be an answer to simple yes/no question,
'Did we install the new software by 1 st June?' for example.

 What is Software Requirement Specification - [SRS]?

A software requirements specification (SRS) is a document that captures
complete description about how the system is expected to perform. It is
usually signed off at the end of requirements engineering phase.

The production of the requirements stage of the software development

process is Software Requirements Specifications (SRS) (also called a requirements
document).

This report lays a foundation for software engineering activities and is

constructing when entire requirements are elicited and analyzed. SRS is a
formal report, which acts as a representation of software that enables the
customers to review whether it (SRS) is according to their requirements.
Also, it comprises user requirements for a system as well as detailed
specifications of the system requirements.

The SRS is a specification for a specific software product, program, or

set of applications that perform particular functions in a specific
environment.

It serves several goals depending on who is writing it. First, the SRS
could be written by the client of a system. Second, the SRS could be
written by a developer of the system.
The two methods create entirely various situations and establish
different purposes for the document altogether. The first case, SRS, is
used to define the needs and expectation of the users. The second case,
SRS, is written for various purposes and serves as a contract document
between customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of

requirements stated in the SRS. SRS is said to be perfect if it covers all
the needs that are truly expected from the system.
2. Completeness: The SRS is complete if, and only if, it includes the
following elements:

(1). All
essential requirements, whether relating to functionality,
performance, design, constraints, attributes, or external interfaces.

(2). Definitionof their responses of the software to all realizable classes

of input data in all available categories of situations.

(3). Full
labels and references to all figures, tables, and diagrams in the
SRS and definitions of all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of

individual requirements described in its conflict. There are three types of
possible conflict in the SRS:

(1). The
specified characteristics of real-world objects may conflicts. For
example,

(a) The format of an output report may be described in one requirement

as tabular but in another as textual.

(b) One condition may state that all lights shall be green while another
states that all lights shall be blue.

(2). Theremay be a reasonable or temporal conflict between the two

specified actions. For example,

(a) One requirement may determine that the program will add two
inputs, and another may determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while
other requires that "A and B" co-occurs.

(3). Two or more requirements may define the same real-world object but
use different terms for that object. For example, a program's request for
user input may be called a "prompt" in one requirement's and a "cue" in
another. The use of standard terminology and descriptions promotes
consistency.

4. Unambiguousness: SRS is unambiguous when every fixed

requirement has only one interpretation. This suggests that each element
is uniquely interpreted. In case there is a method used with multiple
definitions, the requirements report should determine the implications in
the SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for

importance and stability if each requirement in it has an identifier to
indicate either the significance or stability of that particular requirement.

Typically, all requirements are not equally important. Some

prerequisites may be essential, especially for life-critical applications,
while others may be desirable. Each element should be identified to
make these differences clear and explicit. Another way to rank
requirements is to distinguish classes of items as essential, conditional,
and optional.

6. Modifiability: SRS should be made as modifiable as likely and should

be capable of quickly obtain changes to the system to some extent.
Modifications should be perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be

verified with a cost-effective system to check whether the final software
meets those requirements. The requirements are verified with the help of
reviews.

8. Traceability: The SRS is traceable if the origin of each of the

requirements is clear and if it facilitates the referencing of each
condition in future development or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement

explicitly referencing its source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS
having a unique name or reference number.

The forward traceability of the SRS is especially crucial when the

software product enters the operation and maintenance phase. As code
and design document is modified, it is necessary to be able to ascertain
the complete set of requirements that may be concerned by those
modifications.

9. Design Independence: There should be an option to select from

multiple design alternatives for the final system. More specifically, the
SRS should not contain any implementation details.

10. Testability: An SRS should be written in such a method that it is

simple to generate test cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in

his/her explicit domain but might not be trained in computer science.
Hence, the purpose of formal notations and symbols should be avoided
too as much extent as possible. The language should be kept simple and
clear.

12. The right level of abstraction: If the SRS is written for the
requirements stage, the details should be explained explicitly.
Whereas,for a feasibility study, fewer analysis can be used. Hence, the
level of abstraction modifies according to the objective of the SRS.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time,

unambiguous, consistent, and complete. Verbose and irrelevant
descriptions decrease readability and also increase error possibilities.

Structured: It should be well-structured. A well-structured document is

simple to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the user requirements.
Often, user requirements evolve over a period of time. Therefore, to
make the modifications to the SRS document easy, it is vital to make the
report well-structured.

Black-box view: It should only define what the system should do and
refrain from stating how to do these. This means that the SRS document
should define the external behavior of the system and not discuss the
implementation issues. The SRS report should view the system to be
developed as a black box and should define the externally visible
behavior of the system. For this reason, the SRS report is also known as
the black-box specification of a system.

Conceptual integrity: It should show conceptual integrity so that the

reader can merely understand it. Response to undesired events: It should
characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.

Verifiable: All requirements of the system, as documented in the SRS

document, should be correct. This means that it should be possible to
decide whether or not requirements have been met in an implementation.

Qualities of SRS:
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable
Types of Requirements:
The below diagram depicts the various types of requirements that are
captured during SRS.
  Information and control in organizations
Hierarchical information and control systems
With small projects, the project leaders are likely to be working very
closely w ith the other team members and might even be carrying out
many non-managerial tasks themselves.
Therefore they should have a pretty good idea of what is going on.
When projects are larger, many separate teams will be working on
different aspects of the project and the overall managers of the project
are not going to have day-to-day direct contact w ith all aspects of the
work.
larger projects are likely to have a hierarchical management structure
(Figure 1.3). Project team members will each have a group leader who
allocates them work and to whom they report progress. In turn the group
leader, along with several other group leaders, w ill report to a manager
at the next higher level. That manager might have to report to another
manager at a higher level, and so on.
There might be problems that cannot be resolved at a particular level.
l;or example, additional resources might be needed for some task, or
there might be a disagreement with another group. These will be referred
to the next higher level of management.
At each higher level more information will be received by fewer people.
There is thus a very real danger that managers at the higher levels might
be overloaded w ith too much information. To avoid this, at each level
the information will have to be summarized.
  Step Wise Project Planning:-
Planning is the most difficult process in project management. The
framework described is called the Stepwise method to help to
distinguish it from other methods.

Step 0: Select Project

Step 1: Identify project scope and objectives

Step 1.1 : Identify objectives and practical measures of the
effectiveness in meeting those objectives
Step 1.2 : Establish  a project authority
Step 1.3 : Stakeholder analysis - identify all stakeholders in the
project and their interests.
Step 1.4 : Modify objectives in the light of stakeholder analysis.
Step 1.5 : Establish methods of communication with all parties.

Step 2 : Identify project infrastructure

Step 2.2 : Identify installation standard and procedures
Step 2.3 : Identify project team organization

Step 3 : Analyse project characteristics

Step 3.1 : Distinguish the project as either objectives- or product-
driven.
Step 3.2 : Analyse other project characteristics
Step 3.3 : Identify high-level project risks
Step 3.4 : Take into account use requirements concerning
implementation
Step 3.5 : Select development methodology and life-cycle approach
Step 3.6 : Review overall resource estimates

Step 4 : Identify project products and activities

Step 4.1 : Identify and describe project products
Step 4.2 : Document generic product flows
Step 4.3 : Recognize product instances
Step 4.4 : Produce ideal activity network
Step 4.5 : Modify the ideal to take into account need for stages and
checkpoints
Step 5 : Estimate effort for each activity
Step 5.1 : Carry out bottom-up estimates
              - distinguish carefully between effort and elapsed time
Step 5.2 : Revise plan to create ontrollable activities 
              - breakup very long activities into a series of smaller ones
              - bundle up very short activities

Step 6 : Identify activity risks

Step 6.1 : Identify and quantify activity based risks 
              - damage if risk occurs
              - likelihood if risk occuring
Step 6.2 : Plan risk reduction and contingency measures
              - risk reduction : activity to stop risk occuring
              - contingency : action if risk does occurs
Step 6.3 : Adjust overall plans and estimates to take account of risks

Step 7 : Allocate resources

Step 7.1 : Identify and allocate resources
Step 7.2 : Revise plans and estimates to take into account resource
constraints

Step 8 : Review/ Publicize plans

Step 8.1 : Review quality aspects of the project plan
Step 8.2 : Documentr plans and obtain agreement

Step 9 and 10 : Execute plan. Lower levels of planning