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.

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.

Prerequisite of software project management?

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

Time
Cost
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:

Managing risks and issues.
Create the project team and assigns tasks to several team members.
Activity planning and sequencing.
Monitoring and reporting progress.
Modifies the project plan to deal with the situation.

Software project management: Software Project Management involves,

the application of knowledge skills, tools and techniques to Project con activities and
meet the Project, requirements within defined constraints such as scope, time, cost
and quality it cos encompasses Planning, Organizing, staffing, directing and
Controlling resources to achieves Specific software goals.

Advantages.
Improved Planning and Control :
● Helps in defining Clear Project Objectives; Scope and deliverable”s.
● Facilities better allocation and utilization of resources

Risk Management:
● Identities Potential risk's early and implements mitigation and Strategies an
● Reduces the likelihood of Project failure

Quality Assurance:-
● Ensures adherence to Standards the best 208 adherence Practices
● Improves the overall quality of the software Product.

Cost Management
● Monitors and controls Project costs to stay within budget
● Helps in identifying cost-Saving Opportunities
Time management :
● Creates realistic schedules and timelines
● Tracks Progress to ensure timely delivery
Stake holder Satisfaction
● Involves Stakeholder in the Planning Process
● Ensure their needs and expectations are met.
Enhanced Communication:-
● Facilitates Clear and effective communication, among team members and
stakeholders.
 ● Reduces misunderstandings and conflicts

Disadvantages
Resource Intensive
● Requires Significant time, effort, and resources for Planning and Control
activities.
● Can be Costly to implement and maintain
Complexity
● Managing large and Complex projects can be challenging
● Requires specialized skills and expertise.
Rigidity :
● Traditional methodologies can be inflexible in handling Changes
● May-not adapt well to evolving requirement
Overhead:
● Extensive documentation and format Processes can lead to project overhead
● May slow down the development Process
Dependency on Tools and Techniques
● Over-reliance Project Management tools and techniques can be Problematic if not
used effectively
● Requires Continuous training and updates

Uses and application

1. Software Development
Application:

● Building, designing, and deploying software applications for various purposes

like web development, mobile apps, enterprise software, and more.
 Iterative models like Agile, Devops, and Continuous Integration/Continuous
Deployment (CI/CD) are widely used.
Examples:

 Developing custom enterprise software for business operations.

 Creating mobile apps for consumer use.

2. IT Infrastructures
Application:

 Designing and managing the hardware and software frameworks that support an
organization's IT operations.
 Ensuring data security, network management, and server maintenance.
 Examples:

 Implementing cloud computing solutions.

 Managing data centers and network architecture.

3. Product Development
Application:

 The process of conceptualizing, designing, and developing a product from the initial
idea to the market ready product.
 Involves prototyping, testing, and iterating based on feedback.

Examples:

 Developing a new tech gadget or consumer electronic device.

 Creating a new software tool or application.

4. System Integration
Application:

 Combining different subsystems or components into one large system and ensuring
they function together effectively.
 Involves software and hardware components, ensuring interoperability and
communication between systems.

Examples:

 Integrating CRM software with an existing ERP system.

 Connecting IoT devices within a smart home environment.

5. Maintenance and Support

Application:

 Providing ongoing support, troubleshooting, and updates for existing systems and
software.
 Involves bug fixes, performance enhancements, and regular updates to ensure
systems remain functional and secure.

Examples:
Providing software patches and updates for an enterprise system.
Offering technical support for end users experiencing issues with software or
hardware.
Future Scope
1. Agile and Hybrid Methodologies.
 Greater flexibility
 Handling Changing requirement
2. Artificial intelligence and Automation
3. Remote and Distributed Teams
4. Emphasis on cyber security
5. Sustainability driven Decision making
6. Enhanced collaboration tools

Conventional software management

In the past, Organizations wed conventional utilized custom tools and Process
Software management utilized and virtually custom components built an- Primitive
Languages. Thus, the performance of the project was Very much Predictable in the
schedule, cost and quality It is a practically outdated technique and technology & For
this software economics, offers a Standard Scale of Performance The best thing
about Conventional Software is.the flexibility of Software The won't thing also
conventional, Software in flexibility.

They are three Primary analysis of a software industry's State and they are Listed
below

1) The development of Software in still in unpredictable

2) Management regulation is a discriminator in the failure or Success
3) The Level of rework and software scrap are Indicators of an undeveloped Process.

These analysis typically Provide the rules for management Performance

Conventional Software Management Barry Bohem's Top 10 List & a good of the
state Objective characterization of software development Performance

1) Finding and fixing a software problem after delivery costs 100 times more than
finding and fixing the Problem in early design phase
2) you can compress Software development Schedule 25% of nominal bud, no more
3) For every I solar, you spent on development,You will send $2 on maintenance..
4) Software development and maintenance cost are Primarily a function of the
number of source line of code.

5) Variations among people account for the biggest difference is Software

Productivity
6) The Overall ratio of software to hardware Cost a Still growing. In 1955 it was
15.85 in 1985 85:15
7) only about 15% of software development effort. & devoted to Programming

8) software system products cost 9 timer as much

9) walk through catch 60%. Of the errors

10) 80% of the contribution Comes From contributors.

Waterfall model:

The Waterfall Model was the first Process Model to be introduced. It is also referred
to as a linear-sequential life cycle model. It is very simple to understand and use. In
a waterfall model, each phase must be completed before the next phase can begin and
there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software
development.

The waterfall Model illustrates the software development process in a linear

sequential flow. This means that any phase in the development process begins only if
the previous phase is complete. In this waterfall model, the phases do not overlap.

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software

Engineering to ensure success of the project. In "The Waterfall" approach, the whole
process of software development is divided into separate phases. In this Waterfall
model, typically, the outcome of one phase acts as the input for the next phase
sequentially.

The following illustration is a representation of the different phases of the Waterfall

Model.
The sequential phases in Waterfall model are −

Requirement Gathering and analysis − All possible requirements of the

system to be developed are captured in this phase and documented in a
requirement specification document.
System Design − The requirement specifications from first phase are studied
in this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next
phase. Each unit is developed and tested for its functionality, which is referred
to as Unit Testing.
Integration and Testing − All the units developed in the implementation
phase are integrated into a system after testing of each unit. Post integration
the entire system is tested for any faults and failures.
Deployment of system − Once the functional and non-functional testing is
done; the product is deployed in the customer environment or released into the
market.
Maintenance − There are some issues which come up in the client
environment. To fix those issues, patches are released. Also to enhance the
product some better versions are released. Maintenance is done to deliver these
changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases. The next phase is started
only after the defined set of goals are achieved for previous phase and it is signed off,
so the name "Waterfall Model". In this model, phases do not overlap.

Waterfall Model - Application

Every software developed is different and requires a suitable SDLC approach to be

followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are −

 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
Advantages

The advantages of waterfall development are that it allows for departmentalization

and control. A schedule can be set with deadlines for each stage of development and
a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing,

installation, troubleshooting, and ends up at operation and maintenance. Each phase
of development proceeds in strict order.

Some of the major advantages of the Waterfall Model are as follows −

 Simple and easy to understand and use

 Easy to manage due to the rigidity of the model. Each phase has specific
deliverable’s and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

Disadvantages

The disadvantage of waterfall development is that it does not allow much reflection
or revision. Once an application is in the testing stage, it is very difficult to go back
and change something that was not well-documented or thought upon in the concept
stage.

The major disadvantages of the Waterfall Model are as follows −

 No working software is produced until late during the life cycle.

 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk
of changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
Evolution of software economics
Software Economics: Software economic is basically Situated at intersection of un-
formation economics and even Software design and Engineering Most software cost
models can be abstracted, in to a function of five basic Parameters: Size, Process,
personal, environment and required quality.

Here are the five steps for software economics:

Size: The Size of the end product, which es typically, quantified in terms of the
number of Source instructions (or) the number of functional Points required to
develop the required functionalities.

Process:It is wed to Produce the end product an Particular the ability of the Process
to avoid hon-value adding activities. Personal:The capability of Software
"engineering Personal and particularly their experience with the computer science
issues and the application domain issues of the Project.

Environment: Which is made up of the tools and techniques available to support

efficient Software development and to automate the process

Quality:The required quality of the product, including its features, Performance,

reliability and adaptability

The relationship among these Parameters the estimated cost can be written or follows
Effort = (Personal) (Environment) (quality) (Size product) One important aspect of
Software economic is that the relationship between effort and Size exhibits a dis-
economy of Scale.

Generations of Software Development –

There are three generations of software development as described below :

Conventional Development (1960s and 1970s) –

During this generation, organizations used various custom tools, custom processes,
and all components of custom that are built or developed in primitive languages. The
size is 100 % custom. At this generation, conventional development is generally
considered bad. It is because it was always costly and over budget and schedule. It
also does not fulfill requirements that are necessary such as some components,
symbolic languages, other languages like Fortran, PL/1, etc. The quality of
performance was always poor and less than great.

Transition (1980s and 1990s) –

During this generation, organizations used various repeatable processes and off-the-
shelf tools, and more likely to use custom components) that are generally developed
in high-level languages. The size is 30 % component-based and 70 % custom. It is
not predictable to decide whether it is bad or good. Transition development is
infrequently on budget and schedule. Some of commercial components were simply
available such as databases, networking along with operating system, database
management system, and graphical user interface. But due to an increase in
complexity, all languages and technologies available were not enough for desired
business performance.

Modern (2000 and later) –

Modern development processes are generally measured and managed, integrated

automated environments, 70% off-the-shelf components. The size is 70 %
component-based and 30 %custom. Modern development is usually in budget and in
schedule.

Improved “process” requires “tools” that are improved. The improved process
requires environmental support. Various technologies other for environment
automation, size reduction, and process improvement are not independent of each
other. In the new era, main key is only complementary growth in all these
technologies.

Pragmatic Cost Estimation Process

The pragmatic cost estimation process is a method used to estimate the cost of a
project or task based on practical considerations and real-world constraints. It takes
into account various factors such as resources, time, complexity, and risks involved
in completing the project.

Here are the steps involved in the pragmatic cost estimation process:

Define the project scope: Clearly define the objectives, deliverable’s, and
boundaries of the project. This helps in understanding the requirements and setting
realistic cost estimates.

Identify the tasks: Break down the project into smaller tasks or activities. This helps
in understanding the effort required for each task and estimating the cost accordingly.
Estimate effort: Estimate the effort required to complete each task. This can be done
by considering factors such as the complexity of the task, the skills and experience of
the team members, and any dependencies or constraints.

Estimate resources: Identify the resources required to complete each task. This
includes personnel, equipment, software, and any other resources needed for the
project. Consider the availability and cost of these resources while estimating the
overall cost.

Consider risks: Identify potential risks and uncertainties that may impact the project.
Assess the likelihood and impact of these risks and factor them into the cost
estimation. This helps in accounting for any additional effort or resources that may
be required to mitigate or address these risks.

Calculate the cost: Once the effort, resources, and risks have been estimated,
calculate the cost for each task and the overall project. This can be done by
multiplying the effort estimate by the cost of resources and factoring in any
additional costs associated with risks or contingencies.

Review and refine: Review the cost estimates and validate them against historical
data or benchmarks. Refine the estimates based on any new information or insights
gained during the review process.

Document and communicate: Document the cost estimates along with the
assumptions and considerations made during the estimation process. Communicate
the estimates to stakeholders and ensure they understand the basis and limitations of
the estimates.

The pragmatic cost estimation process, organizations can make informed decisions
about resource allocation, budgeting, and project planning. It helps in setting realistic
expectations and managing project costs effectively.

Improving Software Economics:

Software Economics

Software estimation is needed to be based on very careful analysis and should be

supported by all. Software economics improvements should come from reducing size,
improving software processes, improving team effectiveness, improving automation
through software environments, and achieving the required quality.

Five basic parameters of the software cost model are

1. Reducing the size or complexity of what needs to be developed

2. Improving the development process.
3. Using more-skilled personnel and better teams (not necessarily the same thing).
4. Using better environments (tools to automate the process).
5. Trading off or backing off on quality thresholds.

These parameters are given in priority order for most software domains. Table 3-1
lists some of the technology developments, process improvement efforts, and
management approaches targeted at improving the economics of software
development and integration.

REDUCING SOFTWARE PRODUCT SIZE

The most significant way to improve affordability and return on investment (ROI) is
usually to produce a product that achieves the design goals with the minimum
amount of human-generated source material.Component-based development is
introduced as the general term for reducing the "source" language size to achieve a
software solution.

Reuse, object-oriented technology, automatic code production, and higher order

programming languages are all focused on achieving a given system with fewer lines
of human-specified source directives (statements).

size reduction is the primary motivation behind improvements in higher order

languages automatic code generators reuse of commercial components and object-
oriented technologies

The reduction is defined in terms of human-generated source material. In

general, when size-reducing technologies are used, they reduce the number of
human-generated source lines.
Importance of Project Size Estimation

Here are some of the reasons why project size estimation is critical in project
management:

Financial Planning: Project size estimation helps in planning the financial aspects
of the project, thus helping to avoid financial shortfalls.

Resource Planning: It ensures the necessary resources are identified and allocated
accordingly.

Timeline Creation: It facilitates the development of realistic timelines and

milestones for the project.

Identifying Risks: It helps to identify potential risks associated with overall project
execution.

Detailed Planning: It helps to create a detailed plan for the project execution,
ensuring all the aspects of the project are considered.

Planning Quality Assurance: It helps in planning quality assurance activities and

ensuring that the project outcomes meet the required standards.

IMPROVING SOFTWARE PROCESSES

Process is an overloaded term. Three distinct process perspectives are.

Meta process: an organization's policies, procedures, and practices for pursuing a

software-intensive line of business. The focus of this process is on organizational
economics, long-term strategies, and software ROI.

Macro process: a project's policies, procedures, and practices for producing a

complete software product within certain cost, schedule, and quality constraints. The
focus of the macro process is on creating an adequate instance of the Meta process
for a specific set of constraints.

Micro process: a project team's policies, procedures, and practices for achieving an
artifact of the software process. The focus of the micro process is on achieving an
intermediate product baseline with adequate quality and adequate functionality as
economically and rapidly as practical.

Although these three levels of process overlap somewhat, they have different
objectives, audiences, metrics, concerns, and time scales
In a perfect software engineering world with an immaculate problem description, an
obvious solution space, a development team of experienced geniuses, adequate
resources, and stakeholders with common goals, we could execute a software
development process in one iteration with almost no scrap and rework. Because we
work in an imperfect world, however, we need to manage engineering activities so
that scrap and rework profiles do not have an impact on the win conditions of any
stakeholder. This should be the underlying premise for most process improvements.

IMPROVING TEAM EFFECTIVENESS

Teamwork is much more important than the sum of the individuals. With software
teams, a project manager needs to configure a balance of solid talent with highly
skilled people in the leverage positions. Some maxims of team management include
the following:

 A well-managed project can succeed with a nominal engineering team.

 A mismanaged project will almost never succeed, even with an expert team of
engineers.
 A well- architected system can be built by a nominal team of software builders.
 A poorly architect-ed system will flounder even with an expert team of builders.

Boehm five staffing principles are

1. The principle of top talent: Use better and fewer people

2. The principle of job matching: Fit the tasks to the skills and motivation of the
people available.
3. The principle of career progression: An organization does best in the long run by
helping its people to self-actualize.
4. The principle of team balance: Select people who will complement and harmonize
with one another
5. The principle of phase-out: Keeping a misfit on the team doesn't benefit anyone

Software project managers need many leadership qualities in order to enhance team
effectiveness. The following are some crucial attributes of successful software
project managers that deserve much more attention:

1. Hiring skills. Few decisions are as important as hiring decisions. Placing the right
person in the right job seems obvious but is surprisingly hard to achieve.
2. Customer-interface skill: Avoiding adversarial relationships among stakeholders
is a prerequisite for success.
3. Decision-making skill:The jillion books written about management have failed to
provide a clear definition of this attribute. We all know a good leader when we run
into one, and decision-making skill seems obvious despite its intangible definition.
4. Team-building skill: Teamwork requires that a manager establish trust, motivate
progress, exploit eccentric prima donnas, transition average people into top
performers, eliminate misfits, and consolidate diverse opinions into a team direction.
5. Selling skill: Successful project managers must sell all stakeholders (including
themselves) on decisions and priorities, sell candidates on job positions, sell changes
to the status quo in the face of resistance, and sell achievements against objectives. In
practice, selling requires continuous negotiation, compromise, and empathy

IMPROVING AUTOMATION

The tools and environment used in the software process generally have a linear
effect on the productivity of the process. Planning tools, requirements management
tools,visual modeling tools,compilers, editors, debuggers, quality assurance analysis
tools, test tools, and user interfaces provide crucial automation support for evolving
the software engineering artifacts. Above all, configuration management
environments provide the foundation for executing and instrument the process. At
first order, the isolated impact of tools and automation generally allows
improvements of 20% to 40% in effort. However, tools and environments must be
viewed as the primary delivery vehicle for process automation and improvement, so
their impact can be much higher.

Automation of the design process provides payback in quality, the ability to

estimate costs and schedules, and overall productivity using a smaller team.
Round-trip engineering describe the key capability of environments that support
iterative development. As we have moved into maintaining different information
repositories for the engineering artifacts, we need automation support to ensure
efficient and error-free transition of data from one artifact to another. Forward
engineering is the automation of one engineering artifact from another, more
abstract representation. For example, compilers and linker’s have provided
automated transition of source code into executable code.

Reverse engineering is the generation or modification of a more abstract

representation from an existing artifact (for example, creating a .visual design model
from a source code representation).

Economic improvements associated with tools and environments. It is common for

tool vendors to make relatively accurate individual assessments of life-cycle
activities to support claims about the potential economic impact of their
tools.

For example, it is easy to find statements such as the following from

companies in a particular tool.

 Requirements analysis and evolution activities consume 40% of life-cycle costs.

 Software design activities have an impact on more than 50% of the resources.
 Coding and unit testing activities consume about 50% of software
development effort andschedule.
 Test activities can consume as much as 50% of a project's resources.
 Configuration control and change management are critical activities that can
consume as much as25% of resources on a large-scale project.
 Documentation activities can consume more than 30% of project engineering
resources.
 Project management, business administration, and progress assessment can
consume as much as30% of project budgets.

ACHIEVING REQUIRED QUALITY :Software best practices are derived from

the development process and technologies. Table 3-5 summarizes some dimensions
of quality improvement.

Key practices that improve overall software quality include the following:

 Focusing on driving requirements and critical use cases early in the

life cycle, focusing on requirements completeness and traceability late in the
life cycle, and focusing throughout the life cycle on a balance between
requirements evolution, design evolution, and plan evolution
 Using metrics and indicators to measure the progress and quality of an
architecture as it evolves from a high-level prototype into a fully compliant
product
 Providing integrated life-cycle environments that support early and
continuous configuration control, change management, rigorous design methods,
document automation, and regression test automation
 Using visual modeling and higher level languages that support architectural
control, abstraction,reliable programming, reuse, and self-documentation Early
and continuous insight into performance issues through demonstration-based
evaluations

Conventional development processes stressed early sizing and timing estimates of

computer programme source utilization. However, the typical chronology of
events in performance assessment was as follows

 Project inception. The proposed design was asserted to be low risk with adequate
performance margin.
 Initial design review. Optimistic assessments of adequate design margin were
based mostly on paper analysis or rough simulation of the critical threads. In
most cases, the actual application algorithms and database sizes were fairly well
understood.
 Mid-life-cycle design review. The assessments started whittling away at
the margin, as early benchmarks and initial tests began exposing the optimism
inherent in earlier estimates.
 Integration and test. Serious performance problems were uncovered, necessitating
fundamental changes in the architecture. The underlying infrastructure was
 usually the scapegoat, but the real culprit was immature use of the infrastructure,
immature architectural solutions, or poorly under-stood early design trade-offs.

PEER INSPECTIONS: A PRAGMATIC VIEW

Peer inspections are frequently over hyped as the key aspect of a quality system. In
my experience, peer reviews are valuable as secondary mechanisms, but
they are rarely significant contributors to quality compared with the following
primary quality mechanisms and indicators, which should be emphasized in them
management process:

 Transitioning engineering information from one artifact set to another,

thereby assessing the consistency, feasibility, understand-ability, and
technology constraints inherent in the engineering artifacts
 Major milestone demonstrations that force the artifacts to be assessed against
tangible criteria in the context of relevant use cases Environment tools
(compilers, debuggers, analyzers, automated test suites) that ensure
representation rigor, consistency, completeness, and change control
 Life-cycle testing for detailed insight into critical trade-offs, acceptance criteria,
and requirements compliance
 Change management metrics for objective insight into multiple-perspective
change trends and convergence or divergence from quality and progress goals

Inspections are also a good vehicle for holding authors accountable for quality
products. All authors of software and documentation should have their
products scrutinized as a natural by-product of the process. Therefore, the
coverage of inspections should be across all authors rather than across all
components