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?
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:
1. Leader
A project manager must lead his team and should provide them direction to make them understand what is
expected from all of them.
2. Medium:
The Project manager is a medium between his clients and his team. He must coordinate and transfer all the
appropriate information from the clients to his team and report to the senior management.
3. Mentor:
He should be there to guide his team at each step and make sure that the team has an attachment. He
provides a recommendation to his team and points them in the right direction.
Responsibilities of a Project Manager:
1. Managing risks and issues.
2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.
Activities
Software Project Management consists of many activities, that includes planning of the project, deciding the
scope of product, estimation of cost in different terms, scheduling of tasks, etc.
The list of activities are as follows:
1. Project planning and Tracking
2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management
Now we will discuss all these activities -
1. Project Planning: It is a set of multiple processes, or we can say that it a task that performed before the
construction of the product starts.
2. Scope Management: It describes the scope of the project. Scope management is important because it
clearly defines what would do and what would not. Scope Management create the project to contain
restricted and quantitative tasks, which may merely be documented and successively avoids price and time
overrun.
3. Estimation management: This is not only about cost estimation because whenever we start to develop
software, but we also figure out their size(line of code), efforts, time as well as cost.
If we talk about the size, then Line of code depends upon user or software requirement.
If we talk about effort, we should know about the size of the software, because based on the size we can
quickly estimate how big team required to produce the software.
If we talk about time, when size and efforts are estimated, the time required to develop the software can
easily determine.
And if we talk about cost, it includes all the elements such as:
 Size of software
 Quality
 Hardware
 Communication
 Training
 Additional Software and tools
 Skilled manpower
4. Scheduling Management: Scheduling Management in software refers to all the activities to complete in
the specified order and within time slotted to each activity. Project managers define multiple tasks and
arrange them keeping various factors in mind.
For scheduling, it is compulsory –
 Find out multiple tasks and correlate them.
 Divide time into units.
 Assign the respective number of work-units for every job.
 Calculate the total time from start to finish.
 Break down the project into modules.
5. Project Resource Management: In software Development, all the elements are referred to as resources
for the project. It can be a human resource, productive tools, and libraries.
Resource management includes:
 Create a project team and assign responsibilities to every team member
 Developing a resource plan is derived from the project plan.
 Adjustment of resources.
6. Project Risk Management: Risk management consists of all the activities like identification, analyzing
and preparing the plan for predictable and unpredictable risk in the project.
Several points show the risks in the project:
 The Experienced team leaves the project, and the new team joins it.
 Changes in requirement.
 Change in technologies and the environment.
 Market competition.
7. Project Communication Management: Communication is an essential factor in the success of the
project. It is a bridge between client, organization, team members and as well as other stakeholders of the
project such as hardware suppliers.
From the planning to closure, communication plays a vital role. In all the phases, communication must be
clear and understood. Miscommunication can create a big blunder in the project.
 8. Project Configuration Management: Configuration management is about to control the changes in
software like requirements, design, and development of the product.
The Primary goal is to increase productivity with fewer errors.
Some reasons show the need for configuration management:
 Several people work on software that is continually update.
 Help to build coordination among suppliers.
 Changes in requirement, budget, schedule need to accommodate.
 Software should run on multiple systems.
Tasks perform in Configuration management:
 Identification
 Baseline
 Change Control
 Configuration Status Accounting
 Configuration Audits and Reviews
Software Metrics
A software metric is a measure of software characteristics which are measurable or countable. Software
metrics are valuable for many reasons, including measuring software performance, planning work items,
measuring productivity, and many other uses.
Within the software development process, many metrics are that are all connected. Software metrics are
similar to the four functions of management: Planning, Organization, Control, or Improvement.
Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various characteristics of the software product. The two
important software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics of the software development process.
For example, the efficiency of fault detection. They are used to measure the characteristics of methods,
techniques, and tools that are used for developing software.

Types of
Metrics
Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of
greater importance to a software developer. For example, Lines of Code (LOC) measure.
External metrics: External metrics are the metrics used for measuring properties that are viewed to be of
greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For
example, cost per FP where FP stands for Function Point Metric.
Project metrics: Project metrics are the metrics used by the project manager to check the project's progress.
Data from the past projects are used to collect various metrics, like time and cost; these estimates are used as
a base of new software. Note that as the project proceeds, the project manager will check its progress from
time-to-time and will compare the effort, cost, and time with the original effort, cost and time. Also
understand that these metrics are used to decrease the development costs, time efforts and risks. The project
quality can also be improved. As quality improves, the number of errors and time, as well as cost required, is
also reduced.
Advantage of Software Metrics
Comparative study of various design methodology of software systems.
For analysis, comparison, and critical study of different programming language concerning their
characteristics.
In comparing and evaluating the capabilities and productivity of people involved in software development.
In the preparation of software quality specifications.
In the verification of compliance of software systems requirements and specifications.
In making inference about the effort to be put in the design and development of the software systems.
In getting an idea about the complexity of the code.
In taking decisions regarding further division of a complex module is to be done or not.
In guiding resource manager for their proper utilization.
In comparison and making design tradeoffs between software development and maintenance cost.
In providing feedback to software managers about the progress and quality during various phases of the
software development life cycle.
In the allocation of testing resources for testing the code.
Disadvantage of Software Metrics
The application of software metrics is not always easy, and in some cases, it is difficult and costly.
The verification and justification of software metrics are based on historical/empirical data whose validity is
difficult to verify.
These are useful for managing software products but not for evaluating the performance of the technical
staff.
The definition and derivation of Software metrics are usually based on assuming which are not standardized
and may depend upon tools available and working environment.
Most of the predictive models rely on estimates of certain variables which are often not known precisely.

What is COCOMO model?

COCOMO or Constructive Cost Estimation Model is a model that estimates the effort and time taken to
complete the model based on the size of the source code. It includes 15 multiplying factors from different
attributes of the project, and finally calculates time and effort using this information.
The COCOMO model first divides the software based on its size. Let us first understand how each software
is differentiated.
Software Project Type
The Cocomo model divides software projects into 3 types-
 Organic
 Semi-detached
 Embedded
Let us learn about them one by one.
ORGANIC – A software development project comes under organic type if the development team is small,
the problem is not complex, and has been solved before. Also, a nominal experience of team members is
considered. Some of the projects that can be organic are- small data processing systems, basic inventory
management systems, business systems.

SEMIDETACHED – A software project that is in-between the organic and embedded system is a semi-
detached system. Its characteristics include – a middle-sized development team, with a mix of both-
experienced and inexperienced members, and the project complexity is neither too high nor too low.
The problems faced in this project are a few known and a few unknown, which have never been faced
before. Few such projects are- Database Management System(DBMS), new unknown operating system,
difficult inventory management system.

EMBEDDED – A project requiring a large team with experienced members, and having the highest level of
complexity is an embedded system. The members need to be creative enough to be able to develop complex
models. Such projects include- air traffic models, ATMs, complex banking systems, etc.
Types of COCOMO Model
The different types of COCOMO models define the depth of cost estimation is required for the project. It
depends on the software manager, what type of model do they choose.
According to Boehm, the estimation should be divided into 3 stages-
 Basic Model
 Intermediate Model
 Detailed Model
Boehm had set different expressions to calculate effort and development time through KLOC (Kilo line of
code). All these calculations are roughly correct and not exact because of the absence of sufficient factors.
Basic Model – This model is based on rough calculations thus, there is very limited accuracy. The whole
model is based on only lines of source code to estimate the calculation and other factors are neglected.
The following expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
Estimation of development effort
For the three classes of software products, the formulas for estimating the effort based on the code size are
shown below:
Organic: Effort = 2.4(KLOC) 1.05 PM
Semi-detached: Effort = 3.0(KLOC) 1.12 PM
Embedded: Effort = 3.6(KLOC) 1.20 PM
Estimation of development time
For the three classes of software products, the formulas for estimating the development time based on the
effort are given below:
Organic: Tdev = 2.5(Effort) 0.38 Months
Semi-detached: Tdev = 2.5(Effort) 0.35 Months
Embedded: Tdev = 2.5(Effort) 0.32 Months
Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for
different software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe
that the effort is somewhat superliner in the size of the software product. Thus, the effort required to develop
a product increases very rapidly with project size.
Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for
each of the three model i.e., organic, semi-detached & embedded.
Solution: The basic COCOMO equation takes the form:
Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
(i)Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
 E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM
2. Intermediate Model: The basic Cocomo model considers that the effort is only a function of the number
of lines of code and some constants calculated according to the various software systems. The intermediate
COCOMO model recognizes these facts and refines the initial estimates obtained through the basic
COCOMO model by using a set of 15 cost drivers based on various attributes of software engineering.
Classification of Cost Drivers and their attributes:
(i) Product attributes -
 Required software reliability extent
 Size of the application database
 The complexity of the product
Hardware attributes -
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
Personnel attributes -
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
Project attributes -
 Use of software tools
 Application of software engineering methods
 Required development schedule
Intermediate COCOMO equation:
E=ai (KLOC) bi*EAF
D=ci (E)di
3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard version with an
assessment of the cost driver’s effect on each method of the software engineering process. The detailed
model uses various effort multipliers for each cost driver property. In detailed cocomo, the whole software is
differentiated into multiple modules, and then we apply COCOMO in various modules to estimate effort and
then sum the effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model
The effort is determined as a function of program estimate, and a set of cost drivers are given according to
every phase of the software lifecycle.

Project Scheduling

Project-task scheduling is a significant project planning activity. It comprises deciding which functions
would be taken up when. To schedule the project plan, a software project manager wants to do the
following:

1. Identify all the functions required to complete the project.

2. Break down large functions into small activities.
 3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the duration of the
project.

The first method in scheduling a software plan involves identifying all the functions required to complete the
project. A good judgment of the intricacies of the project and the development process helps the supervisor
to identify the critical role of the project effectively. Next, the large functions are broken down into a valid
set of small activities which would be assigned to various engineers. The work breakdown structure
formalism supports the manager to breakdown the function systematically after the project manager has
broken down the purpose and constructs the work breakdown structure; he has to find the dependency
among the activities. Dependency among the various activities determines the order in which the various
events would be carried out. If an activity A necessary the results of another activity B, then activity A must
be scheduled after activity B. In general, the function dependencies describe a partial ordering among
functions, i.e., each service may precede a subset of other functions, but some functions might not have any
precedence ordering describe between them (called concurrent function). The dependency among the
activities is defined in the pattern of an activity network.

Once the activity network representation has been processed out, resources are allocated to every activity.
Resource allocation is usually done using a Gantt chart. After resource allocation is completed, a PERT
chart representation is developed. The PERT chart representation is useful for program monitoring and
control. For task scheduling, the project plan needs to decompose the project functions into a set of
activities. The time frame when every activity is to be performed is to be determined. The end of every
action is called a milestone. The project manager tracks the function of a project by audit the timely
completion of the milestones. If he examines that the milestones start getting delayed, then he has to handle
the activities carefully so that the complete deadline can still be met.

Organisation and team Structure

Software engineering teams can be complicated, and finding a solid approach to structure them for success
is not easy. Probably, because there is no single way of doing it. My experience taught me that whilst there
is no one-fix-all solution, some approaches have more pros and a higher success rate than others. I want to
share and review some of the most common team structures and dig a little bit into a solution that worked
well for me across different organisations of various sizes and specialisations. Whilst I don’t have the
perfect answer, it could be good as a starting point for any high-performance team of skilled individuals who
value contribution and meaning above politics and typical corporate BS, which creeps into organisations too
often.
Traits of good software engineering teams
Before we move forward, I want to summarise what a “good software team” means, as this might not be
obvious to everyone. Definitions are essential. If you disagree with mine, my conclusions might sound
stupid later, so let’s eliminate the assumptions.
 Clearly defined roles — Each team member brings value and expertise to support projects and
streamwork’s goals. It is clear why someone has been selected for the team and their role.
 Balanced seniority — There is enough work for different types of people. What seniors consider boring and
demotivating, juniors will likely find challenging and exciting. Unbalanced teams lead to poor results and a
lack of meaningful work, especially when everybody is senior.
 Responsibility and ownership — Every person is responsible for their work, and there is no room to stay
under the radar. Good teams keep themselves accountable on personal and group levels.
 Reasonable size — Big team = complex communication. The more people need to be kept in the loop, the
less work will be done and more confusion created. The perfect agile team is around 4–5 engineers +
product and/or designer to keep things smooth and simple.
 Trust — People need to know each other better than just from plannings, standups and arguments through
PRs. A good team is a group of people who trust each other and can have honest and constructive
discussions, even if they disagree. This is ultra-important in the remote-first world.
 Transparency — It is clear what the team is working on. Usually, that means having an updated board and
tasks connected with high-level company goals and workstreams (roadmap). A good team proactively share
what they do without being chased for updates.
 Strong leadership — The leaders are the single and most important predictor of a teams’ success. It is
much harder to understand their impact if some of the points I mentioned earlier are not in a place like
transparency, lack of well-defined roles or too many managers involved.
What is Risk?
 "Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a problem that could cause
some loss or threaten the progress of the project, but which has not happened yet.
 These potential issues might harm cost, schedule or technical success of the project and the quality of our
software device, or project team morale.
 Risk Management is the system of identifying addressing and eliminating these problems before they can
damage the project.
 We need to differentiate risks, as potential issues, from the current problems of the project.
Different methods are required to address these two kinds of issues.
For example, staff storage, because we have not been able to select people with the right technical skills is a
current problem, but the threat of our technical persons being hired away by the competition is a risk.
Risk Management
A software project can be concerned with a large variety of risks. In order to be adept to systematically
identify the significant risks which might affect a software project, it is essential to classify risks into
different classes. The project manager can then check which risks from each class are relevant to the project.
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and
customer-related problems. A vital project risk is schedule slippage. Since the software is intangible, it is
very tough to monitor and control a software project. It is very tough to control something which cannot be
identified. For any manufacturing program, such as the manufacturing of cars, the plan executive can
recognize the product taking shape.
2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and
maintenance issue. It also consists of an ambiguous specification, incomplete specification, changing
specification, technical uncertainty, and technical obsolescence. Most technical risks appear due to the
development team's insufficient knowledge about the project.
3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing
budgetary or personnel commitments, etc.
Principle of Risk Management
1. Global Perspective: In this, we review the bigger system description, design, and implementation. We look at the
chance and the impact the risk is going to have.
2. Take a forward-looking view: Consider the threat which may appear in the future and create future plans for
directing the next events.
3. Open Communication: This is to allow the free flow of communications between the client and the team members
so that they have certainty about the risks.
4. Integrated management: In this method risk management is made an integral part of project management.
5. Continuous process: In this phase, the risks are tracked continuously throughout the risk management paradigm.
Risk Assessment
The objective of risk assessment is to division the risks in the condition of their loss, causing potential. For
risk assessment, first, every risk should be rated in two methods:
 The possibility of a risk coming true (denoted as r).
 The consequence of the issues relates to that risk (denoted as s).
 Based on these two methods, the priority of each risk can be estimated:
p=r*s
Where p is the priority with which the risk must be controlled, r is the probability of the risk becoming true,
and s is the severity of loss caused due to the risk becoming true. If all identified risks are set up, then the
most likely and damaging risks can be controlled first, and more comprehensive risk abatement methods can
be designed for these risks.
1. Risk Identification: The project organizer needs to anticipate the risk in the project as early as possible
so that the impact of risk can be reduced by making effective risk management planning.
A project can be of use by a large variety of risk. To identify the significant risk, this might affect a project.
It is necessary to categories into the different risk of classes.
There are different types of risks which can affect a software project:
1. Technology risks: Risks that assume from the software or hardware technologies that are used to develop the
system.
2. People risks: Risks that are connected with the person in the development team.
3. Organizational risks: Risks that assume from the organizational environment where the software is being developed.
4. Tools risks: Risks that assume from the software tools and other support software used to create the system.
5. Requirement risks: Risks that assume from the changes to the customer requirement and the process of managing
the requirements change.
6. Estimation risks: Risks that assume from the management estimates of the resources required to build the system
2. Risk Analysis: During the risk analysis process, you have to consider every identified risk and make a
perception of the probability and seriousness of that risk.
There is no simple way to do this. You have to rely on your perception and experience of previous projects
and the problems that arise in them.
It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk.
Instead, you should authorize the risk to one of several bands:
1. The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%), high (50-
75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious (would cause
significant delays), tolerable (delays are within allowed contingency), or insignificant.
Risk Control
It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a plan are
determined; the project must be made to include the most harmful and the most likely risks. Different risks
need different containment methods. In fact, most risks need ingenuity on the part of the project manager in
tackling the risk.
There are three main methods to plan for risk management:
1. Avoid the risk: This may take several ways such as discussing with the client to change the requirements to
decrease the scope of the work, giving incentives to the engineers to avoid the risk of human resources
turnover, etc.
2. Transfer the risk: This method involves getting the risky element developed by a third party, buying
insurance cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk. For instance, if there is a risk
that some key personnel might leave, new recruitment can be planned.
Risk Leverage: To choose between the various methods of handling risk, the project plan must consider the
amount of controlling the risk and the corresponding reduction of risk. For this, the risk leverage of the
various risks can be estimated.
Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.
Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of reduction)
1. Risk planning: The risk planning method considers each of the key risks that have been identified and
develop ways to maintain these risks.
For each of the risks, you have to think of the behavior that you may take to minimize the disruption to the
plan if the issue identified in the risk occurs.
You also should think about data that you might need to collect while monitoring the plan so that issues can
be anticipated.
Again, there is no easy process that can be followed for contingency planning. It rely on the judgment and
experience of the project manager.
2. Risk Monitoring: Risk monitoring is the method king that your assumption about the product, process,
and business risks has not changed.