Software Project

Management
By
Dr Shivakumar C
 Contents
• Managing software project- • Process Decomposition,
• The Management Spectrum, • The Project ,
• The People , The Product , The Process , • The WHH Principle,
• The Project , People , The Stakeholders , • Software Cost Estimation – COCOMO Model –
• Team Leaders , The Software Team , • Project Scheduling
• Agile Teams, Coordination and Communication Issues , • Software Maintenance
• The Product ,Software Scope , • Project Planning – Project Scheduling– Risk
Management,
• Problem Decomposition ,
• CASE
• The Process , Melding the Product and the Process ,
 Managing software project

• Software Project Management is the discipline of planning, organizing, and

overseeing the development, testing, and maintenance of software systems.
• It involves defining project goals, estimating resources, scheduling tasks, and
coordinating the efforts of a team to ensure successful and timely delivery of
a software product.
• The key components include project planning, risk management,
communication, and quality assurance to meet specified requirements and
achieve customer satisfaction.
 The Management Spectrum

• The management spectrum

encompasses a range of approaches to • Scrum and Kanban for iterative
organizing and executing work within development,
an organization. • DevOps for seamless integration,
• It includes traditional/waterfall • Holacracy for a non-hierarchical structure,
management for structured planning, and Project Portfolio Management for
strategic alignment.
• Agile methodologies for flexibility,
• Organizations can choose the approach that
• Lean principles for efficiency, best fits their needs, project requirements,
and organizational culture.
 The People
• Focus on the human element of the project.
• Involves assembling a skilled and motivated team.
• Emphasizes effective communication, collaboration, and leadership.
• Addresses team dynamics, roles, and responsibilities.
 The Product
• Centers on defining, designing, and delivering the software product.
• Involves understanding and meeting customer requirements.
• Emphasizes quality assurance, testing, and continuous improvement.
• Addresses the product life cycle from conception to maintenance.
 The Process
• Involves planning, executing, and monitoring the steps to complete the
project.
• Includes methodologies such as Agile, Scrum, or traditional waterfall.
• Emphasizes efficient workflows, adaptability, and risk management.
• Addresses project scheduling, resource allocation, and optimization.
 The Project
• Refers to a temporary effort with a specific goal, set of tasks, and defined
timeline.
• Involves planning, execution, and closure phases.
• Emphasizes meeting project objectives within constraints such as time,
budget, and scope.
• Addresses the need for effective project management methodologies.
 Stakeholders

• Encompasses individuals or groups with an interest or influence in the

project.
• Includes project sponsors, team members, customers, end-users, and other
affected parties.
• Emphasizes communication and collaboration to understand and manage
expectations.
• Addresses stakeholder engagement, identification, and effective management
to ensure project success.
 Team Leaders
• Refers to individuals responsible for guiding and overseeing a subset of a project
team.
• Involves providing direction, support, and motivation to team members.
• Emphasizes effective communication and collaboration within the team.
• Addresses tasks such as task assignment, progress monitoring, conflict resolution,
and fostering a positive team culture.
• Plays a crucial role in translating the project vision into actionable tasks and
ensuring the team's success in achieving project goals.
 The Software Team
• A software team is a group of individuals with specialized roles and skills working
collaboratively on the development, testing, and maintenance of a software project.
• It involves diverse roles such as developers, testers, designers, and others,
emphasizing effective communication and collaboration.
• The team follows Agile principles, engages in activities throughout the software
development lifecycle, and adapts to changes, with leadership providing guidance.
• The team's success relies on technical expertise, teamwork, and a shared
commitment to delivering high-quality software.
 Agile Teams
• Agile teams are cross-functional groups that collaborate on iterative
development.
• Emphasizes adaptability, customer feedback, and continuous improvement.
• Comprises members with varied skills, fostering a collaborative and self-
organizing environment.
 Coordination and Communication Issues
• Coordination challenges can arise due • Communication gaps may occur with
to decentralization and autonomy in distributed teams or differing time
Agile teams. zones.
• Mitigated through regular stand-up • Addressed through frequent
meetings, sprint planning, and visual communication channels, such as
tools like Kanban boards. video conferencing and collaboration
• Encourages transparency and a shared tools.
understanding of project goals to • Emphasizes clear documentation, user
enhance coordination. stories, and constant feedback to
minimize misunderstandings.
 The Product - Software Scope
• Context: How does the software to be built fit into a larger system, product, or
business context and what constraints are imposed as a result of the context?
• Information objectives: What customer-visible data objects are produced as
output from the software? What data objects are required for input?
• Function and performance: What function does the software perform to
transform input data into output? Are any special performance characteristics to be
addressed?
• Software project scope must be unambiguous and understandable at the
management and technical levels.
 Problem Decomposition

• Sometimes called partitioning or problem elaboration

• Once scope is defined …
• It is decomposed into constituent functions
• It is decomposed into user-visible data objects
or
• It is decomposed into a set of problem classes
• Decomposition process continues until all functions or problem classes have been
defined
 The Process
• Once a process framework has been established
• Consider project characteristics
• Determine the degree of rigor required
• Define a task set for each software engineering activity
• Task set = Software engineering tasks
Work products
Quality assurance points
Milestones
Melding the Problem and the Process
 The Project
• Projects get into trouble when … • Deadlines are unrealistic.
• Software people don’t understand their • Users are resistant.
customer’s needs. • Sponsorship is lost [or was never
• The product scope is poorly defined. properly obtained].
• Changes are managed poorly. • The project team lacks people with
• The chosen technology changes. appropriate skills.
• Business needs change [or are ill- • Managers [and practitioners] avoid
defined]. best practices and lessons learned.
 Common-Sense Approach to Projects
• Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is
to be solved and then setting realistic objectives and expectations.
• Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an
absolute minimum, the team should emphasize quality in every task it performs, and senior management
should do everything possible to stay out of the team’s way.
• Track progress. For a software project, progress is tracked as work products (e.g., models, source code,
sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance
activity.
• Make smart decisions. In essence, the decisions of the project manager and the software team should be
to “keep it simple.”
• Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each
project.
 The W5HH Principle
• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they organizationally located?
• How will the job be done technically and managerially?
• How much of each resource (e.g., people, software, tools, database) will be needed?
 Software Cost Estimation
• Software cost and effort estimation will never be an exact science.
• Too many variables—human, technical, environmental, political—can affect
the ultimate cost of software and effort applied to develop it.
• However, software project estimation can be transformed from a black art to
a series of systematic steps that provide estimates with acceptable risk.
 Software Cost Estimation
• Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e
number of Lines of Code.
• It is a procedural cost estimate model for software projects and is often used
as a process of reliably predicting the various parameters associated with
making a project such as size, effort, cost, time, and quality.
• It was proposed by Barry Boehm in 1981 and is based on the study of 63
projects, which makes it one of the best-documented models.
 Software Cost Estimation
• The key parameters which define the quality of any software products, which
are also an outcome of the Cocomo are primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task.
• It is measured in person-months units.
• Schedule: Simply means the amount of time required for the completion of
the job, which is, of course, proportional to the effort put in.
• It is measured in the units of time such as weeks, and months.
 Software Cost Estimation
• Different models of Cocomo have been proposed to predict the cost estimation at
different levels, based on the amount of accuracy and correctness required.
• All of these models can be applied to a variety of projects, whose characteristics
determine the value of the constant to be used in subsequent calculations.
• These characteristics pertaining to different system types are mentioned below.
• Boehm’s definition of organic, semidetached, and embedded systems:
 Software Cost Estimation
• Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also
the team members have a nominal experience regarding the problem.
• Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and knowledge of the various programming
environment lie in between that of organic and Embedded.
• The projects classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience and better guidance and
creativity.
• Eg: Compilers or different Embedded Systems can be considered Semi-Detached types.
 Software Cost Estimation
• Embedded – A software project requiring the highest level of complexity,
creativity, and experience requirement fall under this category.
• Such software requires a larger team size than the other two models and also the
developers need to be sufficiently experienced and creative to develop such complex
models.
• Basic COCOMO Model
• Intermediate COCOMO Model
• Detailed COCOMO Model
 Project scheduling
• Software project scheduling is an action that distributes estimated effort across the
planned project duration by allocating the effort to specific software engineering
tasks.
• During early stages of project planning, a macroscopic schedule is developed. This
type of schedule identifies all major process framework activities and the product
functions to which they are applied.
• As the project gets under way, each entry on the macroscopic schedule is refined
into a detailed schedule.
• Specific software actions and tasks (required to accomplish an activity) are identified
and scheduled.
 Project scheduling
• Basic Principles
• Compartmentalization
• Interdependency
• Time allocation
• Effort validation
• Defined responsibilities
• Defined outcomes
• Defined milestones
 Software Maintenance
• Software Maintenance refers to the process of modifying and updating a software system
after it has been delivered to the customer.
• This can include fixing bugs, adding new features, improving performance, or updating the
software to work with new hardware or software systems.
• The goal of software maintenance is to keep the software system working correctly,
efficiently, and securely, and to ensure that it continues to meet the needs of the users.
• Software maintenance is a continuous process that occurs throughout the entire life cycle of
the software system.
• It is important to have a well-defined maintenance process in place, which includes testing
and validation, version control, and communication with stakeholders.
 Software Maintenance
• Several Key Aspects of Software Maintenance
• Bug Fixing: The process of finding and fixing errors and problems in the software.
• Enhancements: The process of adding new features or improving existing features to meet the evolving
needs of the users.
• Performance Optimization: The process of improving the speed, efficiency, and reliability of the software.
• Porting and Migration: The process of adapting the software to run on new hardware or software platforms.
• Re-Engineering: The process of improving the design and architecture of the software to make it more
maintainable and scalable.
• Documentation: The process of creating, updating, and maintaining the documentation for the software,
including user manuals, technical specifications, and design documents.
 Risk Management
• A risk is a probable problem- it might happen or it might not. There are main two characteristics of risk
• Uncertainty- the risk may or may not happen which means there are no 100% risks.
• loss – If the risk occurs in reality, undesirable results or losses will occur.
• Risk management is a sequence of steps that help a software team to understand, analyze, and manage
uncertainty.
• Risk management consists of:
• Risk Identification
• Risk analysis
• Risk Planning
• Risk Monitoring
 Risk Management
• There are mainly 3 classes of risks that may affect a computer code project:
• Project Risks: concern various sorts of monetary funds, schedules, personnel, resources, and
customer-related issues. a vital project risk is schedule slippage.
• Since computer code is intangible, it’s tough to observe and manage a computer code
project. it’s tough to manage one thing that can not be seen.
• For any producing project, like producing cars, the project manager will see the merchandise
taking form.
• Technical risks concern potential style, implementation, interfacing, testing, and
maintenance issues.
•
 Risk Management
• Technical risks conjointly embody ambiguous specifications, incomplete
specifications, dynamic specifications, technical uncertainty, and technical
degeneration.
• Most technical risks occur thanks to the event team’s lean information
concerning the project.
• Business Risks:
• This type of risk embodies the risks of building a superb product that
nobody needs, losing monetary funds or personal commitments, etc.
THE END