Acropolis Institute of Technology &

Research, Indore
www.acropolis.in
Project Management
CS-604 (B)
Shraddha Sharma

2
3
Syllabus
Unit-1 Conventional Software Management.

Evolution of software economics. Improving software economics: reducing product size, software
processes, team effectiveness, automation through software environments. Principles of modern software
management.

Unit-2 Software Management Process

Framework,: Life cycle phases- inception, elaboration, construction and training phase. Artifacts of the
process- the artifact sets, management artifacts, engineering artifacts, pragmatics artifacts. Model based
software architectures. Workflows of the process. Checkpoints of the process.

Unit-3 Software Management Disciplines

Iterative process planning. Project organisations and responsibilities. Process automation. Project control
And process instrumentation- core metrics, management indicators, life cycle expectations. Process
discriminants.
4
Books

▪ Software Project management, Walker Royce, Addison Wesley, 1998.

▪ Project management 2/e ,Maylor.

▪ Managing the Software Process, Humphrey.

▪ Managing global software Projects, Ramesh, TMH,2001.

5
Course Outcomes
▪ Understanding the evolution and improvement of software economics according to the basic
parameters and transition to the modern software management.
▪ Learning the objectives, activities and evaluation criteria of the various phases of the life
cycle of software management process.
▪ Gaining knowledge about the various artifacts, workflows and checkpoints of the software
management process and exploring the design concept using model based architecture from
technical and management perspective.
▪ Develop an understanding of project planning, organization, responsibilities, automation and
control of the processes to achieve the desirable results.

6
Course Learning Objectives

▪ Understand the different activities in software project development i.e, planning, design and
management.

7
 Unit-1: Conventional Software Management
▪ Evolution of software economics.
▪ Improving software economics:

✔ Reducing product size,

✔ Software processes,
✔ Team effectiveness,
✔ Automation through software environments.

▪ Principles of modern software management.

8
What we will learn?
1. What is Project and Characteristics of Project.

2. What is Software Project?

3. What is Management?

4. What is Conventional Software Management?

5. Evaluation of Software Economics.

6. Improving Software Economics.

7. Modern principle of Software Project Management.

9
What is a Project?

✔ combination of interrelated activities

✔ defined objectives

✔ completed in a specific time period

✔ According to Project Management Institute (PMI), “Project can be defined

as a temporary work undertaken to accomplish a unique objective at goal.

10
What is Project?
❖Set of tasks that must be completed in order to arrive at a particular
goal or outcome.
❖Projects are temporary.
❖An activity to meet creation
of unique product or service.

11
Phases of Project lifecycle

12
Example

✔ Construction of a house.
✔ Writing a book.
✔ Building a dam.
✔ Introducing a new product in the market.
✔ Construction of a new bridge over a river.
✔ Organizing a seminar.

13
Characteristics of a Project
✔ Projects are unique.
✔ Planning is required.
✔ Specific objectives are to be met or a specific product is to be created.
✔ The project has a predetermined time span.
✔ Projects are purposeful.
✔ People are formed into a temporary work group to carry out the task.
✔ Work is carried out in several phases(project life cycle).
✔ The project is large or complex.

14
Types of Project

✔ Construction projects (Resulting in the erection of buildings, bridges, roads, tunnels

etc. Mining and petro-chemical projects can be included in this group.)

✔ Research projects (a scientific endeavor to answer a research question. In which the

objectives may be difficult to establish, and where the results are unpredictable. )

✔ Manufacturing projects ( Where the final result is a vehicle, ship, aircraft, a piece of
machinery etc.)

✔ Management projects ( Which include the organization or reorganization of work

without necessarily producing a tangible result. Examples would be the design and testing of a new
computer software package, relocation of a company’s headquarters or the production of a stage
show. )
Difference between Project and Other Regular Operations

Project Other Regular Operations

> Temporary > On Going process
> Create unique Product > Repetitive
> Use of wide variety of skills > Limited Skills
> Use of special purpose > Equipment's are in
equipment for short duration continuous use
> No revenue during Project stage > Revenues are there
> Revenues are
there
Reasons of Project Failure
❖Failure in Time Management
❖Failure in Cost Management
❖Failure in Scope Management
❖Failure in Quality
❖Lack of Supervision
❖Lack Of Resources
❖Poor Requirement

17
Need of Software Project Management
❖Incorporate user requirements along with budget and time
constraints.
❖Software will meet customer expectations.
❖Identifying task.
❖Quantifying the resources needed.
❖Determining budget and timeline for completion.
❖To implement actions where necessary.

18
What is Management?
Management involves:
✔ Planning – deciding what is to be done.
✔ Organizing – making arrangements.
✔ Staffing – selecting the right people for project.
✔ Directing – giving instructions.
✔ Monitoring – checking on progress.
✔ Controlling – taking action to find out solutions.
✔ Innovating – coming up with new solutions.
✔ Representing – connecting clients, users, developers and suppliers.

mahendra.verma@acropolis.in 19
Project Management
“Project Management is the discipline of organizing and managing
resources (e.g. people) in such a way that the project is completed
within defined scope, quality, time and cost constraints. A project is a
temporary and one-time endeavor undertaken to create a unique
product or service, which brings about beneficial change or added
value.”

20
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 the desired software product.

21
Software Project Management
❖Software project management is an art and discipline of planning
and supervising software projects.
❖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.

22
Why is Software Project Management important?
✔ Money at risk.

✔ Projects are not always successful.

✔ Projects are late.

✔ Project exceed budget.

23
Economics
❖Economics is the social science that studies the production,
distribution, and consumption of goods and services.
❖Economics is the study of use of scarce resources that have
alternative uses.
❖Economics is study of how
people make decisions in
resource limited situations.

24
Software Economics
❖Software economics is a mature research area that deals with the
ever challenging issue of valuing software and estimating the costs
involved in its production.
❖Software economics is the study of the dynamic economic aspects of
the software industry, including the cost of software development,
distribution, and marketing.
❖It is also used to refer to the economic implications of software
deployment and usage, including the cost of the software itself, the
cost of the hardware required to run the software, and the cost of
associated services.
25
Software Economics
❖Software economic is situated at interaction of economic, software
design and engineering.
❖The goal is to understand the relationship between economics,
objective, constrains and conditions and technical software issues.
❖Then use this issues to improve software productivity.

26
Software Cost Model is based on 5 Parameters of S/W
Economy

1. Size -- number of source instruction or number of function.

2. Process -- used to produce the end product.
3. Personnel -- experience with the computer science issues and the applications
domain issues of the project.

4. Environment -- made up of the tools and techniques available to support efficient

software development and to automate the process.

5. Quality -- of the product, including its features, performance, reliability, and

adaptability.

27
1. Size
❖Size is generally measured or qualified in term of number of source
instructions or in SLOC (Source line of code) or number of function
points required to realize desired capabilities.
❖The size of end product or result is required to develop or create
required functionality.

28
2.Process
❖The process is steps that are used to guide all of activities and
produce end products, in particular ability and capability of process
to avoid or ignore activities that are not adding any value.
❖It also supports heading towards the target or goal and eliminate
activities that are not essential or important.
Workers (roles), artifacts, activities…
Process critical in determining software economics

29
3.Personnel
❖ The capabilities of personnel of software engineering in general, and
particularly their experience with issues or problems regarding computer
science and issues regarding application domain of project
❖ It emphasizes on team and responsibilities of team.
Motherhood: get the right people; good people; Can’t always do this.
Much specialization nowadays. Some are terribly expensive.
Emphasize ‘team’ and team responsibilities…Ability to work in a team;
▪ Several newer light-weight methodologies are totally built around a team or very
small group of individuals…

30
4.Environment
❖It is simply made of various tools and techniques and automated
procedures that are available and used to support software
development and effort in an efficient way.
Integrated tools; automated tools for modeling, testing, configuration,
managing change, defect tracking, etc

31
5.Quality
❖The required quality along with its features, performance, reliability,
scalability, portability, usability, user interface utility, adaptability,
and many more.

32
The relationship among these parameters

33
Generations of Software Economics
❖There are three generations of software development
Conventional Development (1960s and 1970s)
Transition (1980s and 1990s)
Modern (2000 and later)

34
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.
35
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.
36
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.

37
38
Comparison between three generation of software
economics
S. No. Conventional Transition Modern

1. 1960s-1970s 1980s-1990s 2000 and on

2. Waterfall model Process management Iterative development

3. Functional design Encapsulation Based Component based

4. Diseconomy of Scale Diseconomy of scale ROI

5. Environment tools used are custom Off-the-shelf separate Off-the-shelf / integrated

built

6. Size is 100% custom 30% - Component based 30% - Custom based

70% - custom based 70& - component based

7. Process is Adhoc Process is repeatable Process is managed or measured

8. Typical project performance is always Infrequently on budget and on Usually on budget and on schedule
over budget and over schedule schedule

39
Improving Software Economics
Software economics improvements should come from
❖Reducing size
❖Improving software processes
❖Improving team effectiveness
❖Improving automation through software environments
❖Achieving the required quality.

40
Reducing software product size
❖Higher order languages( C++, Ada, Java, Visual Basic etc.)
❖SLOC(Source line of code) metrics: are useful estimators for software
after a candidate solution is formulated and implementation
language is known.
❖Object Oriented (analysis, design, programming)
❖Reuse

41
Improving Software Process
❖ For software-oriented organizations, there are many processes and sub
processes. Three distinct process perspectives are.
❖ Metaprocess(Business Process): An organization's policies, procedures, and
practices for pursuing a software business. The focus of this process is on
organizational economics, long-term strategies, and software ROI.
❖ Macroprocess(Project Level 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.
❖ Microprocess: 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.

42
Improving Team Effectiveness
❖COCOMO Model suggest that the combined efforts of personnel skill
and experience have an impact on productivity as much as a factor of
four over the unskilled personnel.
❖A good software development team should have two characteristics
one is balanced & other one is coverage. Whenever is in out of
balance it is helpless.

43
Rules of team management
❖Teamwork is much more important than the sum of the individuals.
❖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-architected system will have difficulty even with expert
team of builders.

44
Boehm Staffing Principles
❖The Principle of top talent : use better and fewer people.
❖The Principle of job Matching : Fit the task to the skills and
motivation of the people available.
❖The principle of Career progression : Helping those people to self
actualize which makes an organization in a progressive and best in
long run.
❖The Principle of team balance : Select people who will balance and
go with one another.
❖The Principle of phase out : keeping a misfit on the team does not
benefit anyone.
45
Improving Automation through Software Environments
❖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 modelling
tools, compilers, editors, debuggers, quality assurance analysis tools,
test tools, and user interfaces provide crucial automation support for
evolving the software engineering artifacts.
❖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.

46
ACHIEVING REQUIRED QUALITY
❖ 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 modelling 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

47
The principles of Conventional Software Engineering
❖ Make quality . Quality must be quantified and mechanisms put into place to
motivate its achievement
❖ High-quality software is possible. Techniques that have been demonstrated to
increase quality include involving the customer, prototyping, simplifying design,
conducting inspections, and hiring the best people
❖ Give products to customers early. No matter how hard you try to learn users'
needs during the requirements phase, the most effective way to determine real
needs is to give users a product and let them play with it
❖ Determine the problem before writing the requirements. When faced with what
they believe is a problem, most engineers rush to offer a solution. Before you try
to solve a problem, be sure to explore all the alternatives and don't be blinded by
the obvious solution
❖ Evaluate design alternatives. After the requirements are agreed upon, you must
examine a variety of architectures and algorithms. You certainly do not want to
use “architecture” simply because it was used in the requirements specification.
48
The principles of Conventional Software Engineering
❖Use an appropriate process model. Each project must select a
process that makes ·the most sense for that project on the basis of
corporate culture, willingness to take risks, application area, volatility
of requirements, and the extent to which requirements are well
understood.
❖Use different languages for different phases. Our industry's eternal
thirst for simple solutions to complex problems has driven many to
declare that the best development method is one that uses the same
notation throughout the life cycle.
❖Minimize intellectual distance. To minimize intellectual distance, the
software's structure should be as close as possible to the real-world
structure
49
The principles of Conventional Software Engineering
❖ Put techniques before tools. An undisciplined software engineer with a tool
becomes a dangerous, undisciplined software engineer
❖ Get it right before you make it faster. It is far easier to make a working program
run faster than it is to make a fast program work. Don't worry about optimization
during initial coding
❖ Inspect code. Inspecting the detailed design and code is a much better way to
find errors than testing
❖ Good management is more important than good technology. Good
management motivates people to do their best, but there are no universal
"right" styles of management.
❖ People are the key to success. Highly skilled people with appropriate experience,
talent, and training are key.
❖ Follow with care. Just because everybody is doing something does not make it
right for you. It may be right, but you must carefully assess its applicability to
your environment.
50
The principles of Modern Project Management
❖Define a Project Organization Structure
❖Set Clear Project Goals & Objectives
❖Create a Communication Plan
❖Define Roles & Responsibilities
❖Create a Risk Management Plan
❖Set a Project Performance Baseline
❖Create a Change Management Plan
❖Focus on Value Delivery

51
Define a Project Organization Structure
❖The project organization structure is the framework that facilitates
the planning, execution and tracking of project activities.
❖you’ll need to create a project organization chart that specifies the
roles and hierarchy of every team member.
❖Then, think about the procedures and guidelines that will be
followed by them.

52
Set Clear Project Goals & Objectives
❖We’ll need to define the main goals and objectives of your project.
❖ The project goals define the expected benefits of the project while
the project objectives are the steps that you’ll need to take to
achieve them.
❖Defining your goals and objectives will set the stage to plan your
project scope, schedule and budget.

53
Create a Communication Plan
❖ While reporting to the various participants in the project is key, there must
be a primary communication plan to regulate communications between
yourself and the project sponsor. This is the only way to ensure those
project decisions are properly implemented.
❖ Without having a singular way to disseminate what the sponsor wants to
the project manager, you’re not being effective in administrating the
project. Even if there are multiple sponsors, they must speak with one
voice or risk sending the project into chaos.
❖ You have the responsibility to set this line of communication in place. This
entails finding the right person with the right skills, experience, authority
and commitment in the executive team to facilitate this important task.

54
Define Roles & Responsibilities
❖To move forward, a project must have well-defined roles, policies
and procedures in place. That means everyone must know what
they’re responsible for and to whom they answer. There needs a
delegation of authority for any project to function.
❖It also means that you must know how you’re going to manage the
scope of work, maintain the quality of the project, define its
schedule and cost, etc. Without these things sorted from the jump,
you’re putting the project at risk.

55
Create a Risk Management Plan
❖Before the project even starts, figure out the potential risks inherent
in the work ahead.
❖It’s not enough to know that risk might rise at certain points in a
project; you also should put in place a plan to resolve the issue
before it becomes a problem.
❖The sooner you identify a risk, whether expected or not, the faster
you can resolve it and keep the project on track.

56
Set a Project Performance Baseline
❖As you progress through your project, you’ll need project
performance metrics to measure success.
❖The great thing about accountability in a project is that it gives you
the means to identify team members who are top performers and
reward them accordingly.
❖ Other team members may require more training or direction to
improve their performance.

57
Create a Change Management Plan
❖ As a project manager, you’ll need to know that project plans will likely
change as your team starts the project execution phase. Delays, issues,
and risks might make it necessary to make changes to your project scope,
budget or schedule.
❖ Keeping track of these changes and establishing an approval process it’s
called change management, a critical facet to project success as it helps to
avoid scope creep and other issues.
❖ The change management process is simple. You’ll simply need to create a
change management plan, a document where you specify how changes
will be handled.
❖ This will guarantee that whenever a stakeholder or a member of the
project management team wishes to make a change to the project plan,
there will be a change management process in place. In most projects a
change request must be created, filed and approved.
58
Focus on Value Delivery
❖In any project, it’s always important to focus on your clients’ and
stakeholders’ expectations and meet their project requirements. As a
project manager, you need to make sure that the project goals and
objectives are realistic and agreed upon by the project team and
project stakeholders.
❖Then once you’ve reached an agreement with clients and
stakeholders you can think about your value chain, supply chain,
milestones, deliverables and quality standards and evaluate whether
you’re delivering the expected value. During the project life cycle,
you’ll be constantly making decisions that could either increase or
hinder the value you deliver with your project.
59
❖ Base the process on an architecture-first approach.
❖ Establish an iterative life-cycle process that confronts risk early.
❖ Transition design methods to emphasize component-based development.
❖ Establish a change management environment.
❖ Enhance change freedom
❖ through tools that supports round-trip engineering.
❖ Capture design artifacts in rigorous, model-based notation.
❖ Instrument the process for objective quality control and progress assessment.
❖ Use a demonstration-based approach.
❖ Plan intermediate releases in groups of usage scenarios with evolving levels of
detail.
❖ Establish a configurable process that is economically scalable.

60
Conclusion

1. Project
2. Software Project
3. Management

4. Software Project Management

5. Improving Software Economy

6. Principles of Conventional Software Management

7. Principles of Modern Software Management

61
THANKS
62