SOFTWARE

PROJECT
MANAGEMENT
PROFESSIONAL ELECTIVE-I
BY
DR S M ROY CHOWDARY ph.D
UNIT-1
TOPICS:

• CONVENTIONAL SOFTWARE MANAGEMENT

• EVOLUTION OF SOFTWARE ECONOMICS
• IMPROVING SOFTWARE ECONOMICS
• THE OLD WAY AND THE NEW
 CONVENTIONAL SOFTWARE
MANAGEMENT

• The waterfall model

• Conventional software management
performance
 What is CSM
• Conventional software management refers to
the traditional approach used in managing
software development projects. It involves a
set of practices and methodologies that have
been established over time and are widely
used in the industry.
 The waterfall model

• In conventional software management, the

waterfall model is one of the most commonly
used approaches. It is a sequential and linear
software development process that
progresses through several distinct phases.
Here are the typical phases involved in the
waterfall model:
• Requirements Gathering: In this initial phase,
project requirements are gathered and
documented in detail. This involves
understanding the needs of the stakeholders,
defining functional and non-functional
requirements, and establishing project goals.
• System Design: Once the requirements are
determined, the system design phase begins. The
software architecture, modules, and components
are defined, and the overall system design is
documented. This phase focuses on creating a
blueprint for the software solution.
• Implementation: In this phase, the actual coding
and development of the software take place.
Programmers write the code based on the design
specifications, and the software is developed
according to the predetermined plan.
• Testing: After the software is implemented,
testing is conducted to ensure that it functions
correctly and meets the specified requirements.
This phase involves various types of testing,
including unit testing, integration testing, system
testing, and user acceptance testing.
• Deployment: Once the software has passed all
the testing phases and is deemed ready, it is
deployed or released to the end-users or
customers. This involves installation,
configuration, and making the software available
for its intended use.
• Maintenance: The maintenance phase involves
addressing issues, fixing bugs, and making
updates or enhancements to the software. It
includes ongoing support, monitoring, and
ensuring the software remains usable and
efficient over time.
• One key characteristic of the waterfall model is that each
phase is typically completed in a linear fashion, and
progress flows strictly from one phase to the next. This
means that changes or modifications requested later in the
development process can be difficult and costly to
implement since the model assumes that requirements are
fixed at the beginning.
• While the waterfall model provides a structured and
systematic approach to software development, it has
limitations in terms of adaptability to changing
requirements and customer feedback. As a result,
alternative methodologies like Agile and iterative models
have gained popularity in recent years, offering more
flexibility and customer collaboration throughout the
development process.
Conventional software management
performance
• Conventional software management
performance can vary depending on several
factors. Here are some key aspects that can
impact the performance of conventional
software management:
• Efficiency: Conventional software management can be
efficient if the project requirements are well-defined
and stable from the beginning. When there is a clear
understanding of what needs to be developed and the
scope is well-defined, the sequential nature of the
waterfall model allows for a systematic and structured
approach to development.
• Predictability: Conventional software management
aims to provide predictability in terms of project
timelines, milestones, and deliverables. With a well-
defined project plan and schedule, stakeholders can
have a clear understanding of when certain features or
components of the software will be delivered.
• Documentation: Conventional software management
emphasizes comprehensive documentation of
requirements, design specifications, and testing
procedures. This documentation can aid in ensuring
that the software is developed according to the
desired specifications and can serve as a reference for
future maintenance or updates.
• Quality Assurance: The testing phase in conventional
software management is typically extensive and
thorough, which can contribute to ensuring the quality
and reliability of the software. By following a
structured testing approach, potential defects or issues
can be identified and resolved before deployment.
However, conventional software management also has
its limitations, which can affect performance:
• Rigidity: The linear and sequential nature of the
waterfall model can make it challenging to
accommodate changes in requirements or respond to
evolving customer needs. Once a phase is completed,
it is difficult to revisit and modify earlier decisions
without significant cost and effort.
• Limited Customer Involvement: Conventional
software management often involves limited customer
involvement until the final stages of development or
during user acceptance testing. This can result in a lack
of timely feedback and potential misalignment
between the developed software and the actual user
requirements.
• Adaptability: Conventional software
management may struggle to adapt to rapidly
changing technology landscapes or dynamic
market conditions. It may be less suited for
projects that require frequent updates,
iterations, or quick response to market demands.
• Communication and Collaboration: The
hierarchical communication structure in
conventional software management can lead to
slower decision-making processes and limited
collaboration among team members. This can
hinder agility and innovation in the development
process.
• To address some of these limitations,
alternative methodologies such as Agile,
DevOps, or hybrid approaches have emerged,
offering more flexibility, iterative
development, and customer collaboration
throughout the software development
lifecycle. These methodologies aim to improve
performance by embracing change, fostering
communication, and delivering value in
shorter iterations.
 EVOLUTION OF SOFTWARE
ECONOMICS
• Software Economics
• Pragmatic software cost estimation
 Software Economics

• Software economics refers to the study of the

economic aspects related to software
development, deployment, maintenance, and
usage. It involves analyzing the costs, benefits,
and risks associated with software projects
and evaluating their economic viability.

Key aspects of software economics include:

• Cost Estimation: Software economics involves
estimating the costs involved in developing
software, which includes factors such as
personnel, hardware, software tools,
infrastructure, and maintenance. Accurate cost
estimation is crucial for budgeting and resource
allocation.
• Return on Investment (ROI): Software economics
evaluates the potential return on investment by
considering the expected benefits and value that
the software will provide. This includes factors
such as increased efficiency, productivity gains,
revenue generation, cost savings, or improved
customer satisfaction.
• Total Cost of Ownership (TCO): TCO analysis
considers the entire lifecycle costs of software,
including development, implementation,
maintenance, support, upgrades, and eventual
retirement. It helps organizations understand the
long-term financial implications of software
investments.
• Risk Assessment: Software economics assesses
the risks associated with software projects, such
as project delays, budget overruns, technological
obsolescence, security vulnerabilities, or
changing market conditions. Risk analysis helps
organizations make informed decisions and
mitigate potential risks.
• Value Analysis: Software economics examines
the value that software brings to stakeholders,
including end-users, customers, and the
organization itself. It involves assessing the
impact on productivity, competitive advantage,
customer satisfaction, and revenue generation.
• Cost-Benefit Analysis: Cost-benefit analysis is a
method used in software economics to compare
the costs of developing and maintaining software
against the anticipated benefits. It helps in
evaluating whether the benefits outweigh the
costs and assists in decision-making regarding
software investments.
• Economic Models: Various economic models,
such as pricing models, subscription models,
licensing models, and revenue models, are
considered in software economics. These
models determine the financial aspects of
software deployment and monetization.
 Pragmatic software cost estimation

• Pragmatic software cost estimation is an

approach to estimating the cost of software
development projects that emphasizes
practicality and real-world considerations. It
takes into account the inherent uncertainties
and complexities involved in software
development and aims to provide estimates
that are realistic and useful for decision-
making.
Here are some key aspects of pragmatic software cost
estimation:
• Historical Data: Pragmatic cost estimation relies on
historical data from previous software projects as a
reference point. By analyzing data from similar
projects, including their size, complexity, and resources
utilized, estimators can make informed judgments and
projections for the current project.
• Expert Judgment: Expert judgment plays a crucial role
in pragmatic cost estimation. Experienced software
professionals, project managers, and domain experts
provide their insights and opinions based on their
knowledge and expertise. Their input helps in
considering the unique characteristics and challenges
of the current project.
• Decomposition: Pragmatic estimation involves
breaking down the software project into smaller,
manageable components or work packages. This
allows for a more granular estimation, considering the
effort, resources, and risks associated with each
component. Estimators can then aggregate the
estimates to determine the overall project cost.
• Risk Assessment: Pragmatic estimation acknowledges
the presence of uncertainties and risks in software
development. Risks such as technical challenges,
changing requirements, resource availability, and
external dependencies are identified and assessed.
Contingency buffers or reserves may be included in the
estimates to account for potential risks.
• Iterative and Incremental Approach: Pragmatic
estimation recognizes that software development
often involves an iterative and incremental process.
Instead of attempting to estimate the entire project
upfront, estimators focus on estimating smaller
increments or iterations. This allows for more accurate
estimation as the project progresses and more
information becomes available.
• Sensitivity Analysis: Pragmatic estimation considers
the impact of different variables on the cost estimates.
Sensitivity analysis helps identify the most influential
factors and their potential impact on the overall
project cost. This analysis provides insights into areas
where additional attention and contingency planning
may be necessary.
• Documentation and Tracking: Pragmatic
estimation emphasizes documenting the
estimation process, assumptions made, and
any constraints or limitations considered.
Regular tracking and comparison of actual
costs against estimated costs are performed
to assess the accuracy of the estimates and
identify areas for improvement.
 IMPROVING SOFTWARE
ECONOMICS
• Reducing software product size
• Improving software process
• Improving team effectiveness
• Improving automation
• Achieving required quality
• Peer inspection
 Reducing software product size
• Reducing the size of a software product can have several
benefits in terms of improving software economics. Here
are some ways in which reducing software product size can
contribute to better software economics:

• Cost Savings: A smaller software product typically requires

fewer resources, such as hardware, storage, and
bandwidth, for deployment and distribution. This can result
in cost savings in terms of infrastructure and operational
expenses. Additionally, reduced size can also lead to lower
development and maintenance costs, as fewer lines of code
are involved, resulting in less complexity and potential
issues.
• Faster Deployment and Updates: Smaller software
products can be deployed and updated more quickly,
as the distribution and installation processes are faster
and require less time and resources. This allows for
rapid deployment of new features, bug fixes, and
security updates, leading to improved customer
satisfaction and responsiveness to market demands.
• Improved Performance: Smaller software products
often have better performance characteristics, such as
faster execution, quicker startup times, and reduced
memory usage. This can enhance user experience and
increase efficiency, particularly in resource-constrained
environments or for applications that require optimal
performance.
• Enhanced Compatibility and Portability: A smaller
software product is typically easier to deploy and run
on different platforms and devices. It can be more
compatible with a wider range of operating systems,
hardware configurations, and environments. This
improves the software's reach and potential market
share, leading to better economic opportunities.
• Reduced Maintenance Effort: With a smaller
codebase, software maintenance becomes more
manageable. Bug fixing, code refactoring, and
implementing updates or enhancements are typically
less complex and time-consuming, resulting in reduced
maintenance effort and costs over the product's
lifecycle.
• Improved User Experience: Smaller software
products often have a simplified and streamlined
user interface and functionality, which can lead
to a better user experience. By focusing on
essential features and eliminating unnecessary
bloat, the software becomes more intuitive, user-
friendly, and efficient, contributing to customer
satisfaction and loyalty.
 Improving software process

• Improving the software process in Software Project

Management (SPM) involves enhancing the efficiency,
effectiveness, and quality of the software development
lifecycle. Here are some key areas to focus on when
aiming to improve the software process in SPM:
• Process Evaluation: Begin by evaluating the current
software process to identify its strengths, weaknesses,
and areas for improvement. This evaluation can
involve analyzing metrics, gathering feedback from
team members, and conducting process audits.
Understanding the existing process and its pain points
is essential for targeted improvements.
• Establish Clear Goals and Objectives: Clearly define the
goals and objectives that you want to achieve with process
improvements. These goals can include reducing
development time, improving quality, increasing customer
satisfaction, enhancing team collaboration, or streamlining
communication. Establishing clear objectives helps guide
the improvement efforts and measure progress.
• Adopt Agile or Iterative Methodologies: Consider
transitioning to agile or iterative software development
methodologies, such as Scrum or Kanban. These
methodologies promote iterative development, frequent
feedback, collaboration, and adaptability. They can help
address challenges associated with rigid waterfall
approaches, improve responsiveness to changing
requirements, and enhance team productivity.
• Communication and Collaboration: Enhance
communication and collaboration among team members,
stakeholders, and customers. Foster an environment where
open and transparent communication is encouraged. Use
collaboration tools, project management software, and
communication platforms to facilitate effective information
sharing and collaboration across distributed teams.
• Continuous Improvement: Embrace a culture of
continuous improvement within the software development
process. Encourage team members to share ideas,
suggestions, and lessons learned. Regularly review and
assess the process, identify bottlenecks or inefficiencies,
and implement changes to address them. Emphasize
learning from past experiences and applying those lessons
to future projects.
• Quality Assurance and Testing: Strengthen the quality
assurance and testing practices within the software
process. Implement robust testing strategies, including
automated testing, unit testing, integration testing,
and user acceptance testing. Integrate quality
checkpoints throughout the development lifecycle to
catch defects early and ensure that the software meets
the specified requirements.
• Risk Management: Improve risk management
practices within the software process. Identify and
assess potential risks, both technical and non-
technical, that could impact project success. Develop
mitigation strategies and contingency plans to address
identified risks. Regularly monitor and review risks
throughout the project to proactively manage
potential issues.
• Training and Skill Development: Invest in training and skill
development programs for the software development
team. Provide opportunities for continuous learning,
professional development, and acquiring new technologies
or methodologies. Ensuring that team members have the
necessary skills and knowledge enhances their
effectiveness and contributes to improved software process
outcomes.
• Metrics and Measurement: Implement metrics and
measurement systems to monitor and track the
performance of the software process. Define relevant
metrics, such as development velocity, defect rates,
customer satisfaction, and adherence to project timelines.
Regularly analyze these metrics to identify trends, areas for
improvement, and make data-driven decisions
 Improving team effectiveness
• Improving team effectiveness in Software Project
Management (SPM) is crucial for enhancing
productivity, collaboration, and the overall success of
software development projects. Here are some key
strategies to improve team effectiveness:
• Clearly Define Roles and Responsibilities: Ensure that
each team member has a clear understanding of their
roles and responsibilities within the project. Clearly
define the scope of their work, tasks, and expectations.
This clarity helps in avoiding confusion, overlapping
responsibilities, and ensures that everyone knows their
contribution towards the project's success.
• Foster Effective Communication: Establish open and
transparent communication channels within the team.
Encourage regular and frequent communication to
share updates, progress, challenges, and feedback.
Utilize collaboration tools, project management
software, and communication platforms to facilitate
seamless communication and knowledge sharing.
• Promote Collaboration and Teamwork: Encourage a
collaborative environment where team members
actively work together, share ideas, and support each
other. Foster a culture of teamwork and mutual
respect. Implement practices such as pair
programming, code reviews, and collaborative
decision-making to promote collective ownership and
shared accountability.
• Set Realistic Goals and Expectations: Ensure that project
goals and expectations are realistic and achievable. Involve
the team members in the goal-setting process to gain their
buy-in and commitment. Break down larger goals into
smaller, manageable milestones, and celebrate
achievements along the way. This helps in maintaining
motivation and focus within the team.
• Provide Adequate Resources and Support: Ensure that the
team has the necessary resources, tools, and infrastructure
to perform their work effectively. Provide training
opportunities, workshops, and access to relevant
technologies or tools to enhance their skills and
capabilities. Offer guidance and support when needed, and
remove any obstacles or bottlenecks that hinder progress.
• Encourage Continuous Learning and Skill Development:
Promote a culture of continuous learning within the
team. Encourage team members to enhance their skills,
stay updated with industry trends, and adopt new
technologies or methodologies. Support their
professional development through training programs,
conferences, workshops, or certifications.
• Empower Decision-Making: Empower team members
to make decisions and take ownership of their work.
Encourage autonomy and give individuals the authority
to make informed decisions within their areas of
expertise. This not only increases their engagement but
also fosters a sense of responsibility and accountability.
•
• Regularly Review and Evaluate Performance: Conduct
regular performance reviews and evaluations to
provide feedback and identify areas for improvement.
Recognize and acknowledge team members'
accomplishments and provide constructive feedback to
address any performance gaps. This helps in fostering
a culture of continuous improvement and personal
growth.
• Foster a Positive Work Environment: Create a positive
and supportive work environment where team
members feel valued, respected, and motivated.
Encourage a healthy work-life balance, recognize
achievements, and promote well-being initiatives. A
positive work environment enhances team morale,
productivity, and collaboration.
• Encourage Innovation and Experimentation:
Encourage team members to think creatively,
explore new ideas, and take calculated risks.
Provide opportunities for innovation,
experimentation, and exploring alternative
solutions. Celebrate and learn from both
successes and failures, fostering a culture of
continuous improvement and innovation.
 Improving automation
• Improving automation in Software Project
Management (SPM) can significantly enhance
efficiency, reduce manual effort, and streamline
various project management tasks. Here are some key
areas where automation can be implemented to
improve SPM:
• Project Planning and Tracking: Utilize project
management tools that offer automated features for
planning and tracking project activities. These tools can
automate the creation of project schedules, resource
allocation, task assignments, and progress tracking.
Automation helps in maintaining an up-to-date view of
project status, identifying bottlenecks, and ensuring
timely completion of tasks.
• Requirement Management: Implement automated
requirement management tools to capture, track, and
manage project requirements. These tools can assist in
requirements gathering, documentation, traceability, and
change management. Automation reduces the likelihood of
errors, improves collaboration among stakeholders, and
provides a centralized repository for managing
requirements.
• Test Management and Execution: Employ automated
testing frameworks and tools to streamline the testing
process. Automated testing helps in reducing manual
effort, ensuring comprehensive test coverage, and
detecting defects early in the development cycle.
Automated test execution and reporting facilitate faster
feedback loops, enabling quicker bug fixes and enhancing
the overall software quality.
• Configuration Management: Use configuration
management tools to automate the management and
version control of software configurations,
dependencies, and deployment artifacts. Automation
ensures consistency across different environments,
simplifies the process of deploying software updates,
and reduces the risk of configuration-related issues.
• Collaboration and Communication: Utilize
collaboration and communication tools that automate
team collaboration, document sharing, and
communication channels. Automation helps in
improving team coordination, knowledge sharing, and
reduces the dependency on manual communication
methods.
• Documentation and Documentation Management:
Implement automated documentation tools that
facilitate the generation, updating, and version control
of project documentation. Automation helps in
maintaining documentation consistency, improves
collaboration among team members, and saves time
and effort in manual documentation tasks.
• Task and Workflow Automation: Automate repetitive
and mundane tasks, such as email notifications, status
updates, and task reminders. Workflow automation
tools can streamline approvals, notifications, and other
routine activities, reducing manual overhead and
ensuring timely task completion.
 Achieving required quality

• Achieving the required quality in Software Project

Management (SPM) is crucial to ensure that the
delivered software meets the specified requirements
and satisfies customer expectations. Here are some
key strategies to achieve the required quality in SPM:
• Define Clear Quality Objectives: Start by clearly
defining quality objectives that align with the project
goals and customer expectations. Specify the quality
criteria, such as reliability, usability, performance,
security, and adherence to functional requirements.
Clear quality objectives provide a guiding framework
for the project team to focus on delivering the desired
level of quality.
• Establish Quality Assurance Processes: Implement robust
quality assurance processes throughout the software
development lifecycle. These processes should include
activities such as requirements validation, code reviews,
testing, and user acceptance testing. Establishing quality
gates at various stages of the project ensures that quality is
continuously assessed and validated.
• Conduct Comprehensive Testing: Testing plays a critical
role in achieving the required quality. Implement a
comprehensive testing strategy that includes various types
of testing, such as unit testing, integration testing, system
testing, and regression testing. Utilize both manual and
automated testing techniques to detect defects, validate
functionality, and ensure that the software operates as
intended.
• Implement Continuous Integration and Deployment
(CI/CD): Continuous Integration and Deployment practices
facilitate early defect detection and quick feedback loops.
By automating the build, integration, and deployment
processes, CI/CD ensures that changes are validated
continuously, reducing the risk of introducing defects. This
allows for faster identification and resolution of quality
issues.
• Enforce Code Quality Standards: Establish coding
standards and enforce them throughout the development
process. Conduct regular code reviews to identify and
address code quality issues, such as readability,
maintainability, and adherence to best practices. Utilize
static code analysis tools to automatically identify potential
coding issues and enforce coding standards.
• Involve Stakeholders in Quality Assurance: Engage
stakeholders, including end-users, in the quality
assurance process. Seek their feedback, conduct user
acceptance testing, and involve them in validation
activities. By involving stakeholders throughout the
project, you can ensure that their expectations are
met, and the software aligns with their requirements.
• Quality-Oriented Team Culture: Cultivate a team
culture that prioritizes quality and takes ownership of
delivering high-quality software. Encourage
collaboration, knowledge sharing, and open
communication within the team. Provide training and
professional development opportunities to enhance
the team's skills and knowledge related to quality
assurance practices.
 Peer inspection
• Peer inspection, also known as peer review or
peer evaluation, is a quality assurance technique
commonly used in Software Project Management
(SPM). It involves having team members review
and evaluate each other's work products to
identify defects, ensure adherence to quality
standards, and improve the overall quality of the
software being developed. Peer inspection can be
applied to various artifacts throughout the
software development lifecycle, including
requirements documents, design documents,
code, test cases, and other deliverables. Here are
some key aspects of peer inspection in SPM:
• Objective: The primary objective of peer inspection is
to identify defects and improve the quality of work
products. This includes identifying errors,
inconsistencies, violations of coding standards, design
flaws, and other potential issues that could affect the
software's functionality, reliability, or maintainability.
• Roles and Responsibilities: Assign specific roles and
responsibilities for conducting peer inspections.
Typically, team members take turns being reviewers
and authors, ensuring that everyone participates in the
process. The reviewers carefully examine the work
products and provide constructive feedback, while the
authors actively engage in incorporating the feedback
and making necessary improvements.
• Guidelines and Checklists: Establish guidelines and
checklists to ensure a consistent and systematic approach
to peer inspection. These guidelines outline the inspection
process, provide criteria for evaluating the work products,
and specify the roles and responsibilities of reviewers and
authors. Checklists serve as a reference for reviewers to
ensure that they cover all relevant aspects during the
inspection.
• Formal and Informal Inspections: Peer inspections can be
conducted in both formal and informal settings. Formal
inspections typically follow a structured process, with
defined roles, documentation, and meetings. Informal
inspections, on the other hand, are more ad-hoc and
involve less formal procedures. The choice between formal
and informal inspections depends on the project's needs,
complexity, and available resources
• Constructive Feedback: Emphasize the importance of
providing constructive feedback during peer inspections.
The feedback should be specific, objective, and focused on
improving the quality of the work product. Reviewers
should avoid personal criticism and instead focus on
identifying areas for improvement, suggesting alternative
approaches, and sharing best practices.
• Collaboration and Learning: Peer inspections promote
collaboration and learning within the team. It allows team
members to learn from each other's expertise, share
knowledge, and gain insights into different perspectives.
Through the inspection process, team members can
acquire new skills, enhance their understanding of project
requirements, and improve their own work based on the
feedback received.
• Continuous Improvement: Treat peer inspection as an
ongoing process of continuous improvement. Regularly
evaluate and refine the inspection process based on
feedback and lessons learned. Monitor the
effectiveness of the inspections and adapt the
guidelines, checklists, or procedures as needed to
optimize the quality assurance efforts.
• Documentation and Tracking: Document the findings
and outcomes of peer inspections. Keep track of
identified defects, their resolutions, and any recurring
patterns to address systemic issues. This
documentation can serve as a valuable reference for
future inspections, quality audits, and process
improvement initiatives.
 THE OLD WAY AND THE NEW

• The principles of conventional software

engineering
• Principles of modern software management
• Traditionla to an iterative process
 The principles of conventional
software engineering
• The principles of conventional software engineering
have evolved over time, transitioning from traditional
"waterfall" methodologies to more modern and agile
approaches. Here is a comparison between the old
way (conventional software engineering) and the new
approaches:
• Waterfall vs. Agile: Conventional software engineering
often followed the waterfall model, which involved
sequential phases of development, such as
requirements gathering, design, implementation,
testing, and maintenance. The new approaches, such
as Agile methodologies (e.g., Scrum, Kanban), focus on
iterative and incremental development,
• Big Design Upfront vs. Iterative Design: In conventional
software engineering, there was a tendency to perform
extensive upfront planning and design before moving into
implementation. The new approaches emphasize iterative
design and development, starting with an initial design or
prototype and refining it through multiple iterations based
on user feedback and changing requirements.
• Documentation-Heavy vs. Minimal Documentation:
Conventional software engineering placed significant
emphasis on extensive documentation, including detailed
requirements documents, design specifications, and
comprehensive test plans. The new approaches prioritize
lightweight and just-in-time documentation, focusing on
delivering working software rather than extensive
documentation.
• Fixed Scope vs. Adaptive Scope: Conventional software
engineering often followed a fixed-scope mindset, where
requirements were determined upfront and changes were
discouraged. The new approaches embrace changing
requirements and encourage adaptability. They prioritize
customer collaboration, allowing for the incorporation of
feedback and the ability to adjust the scope based on
evolving needs.
• Sequential Development vs. Cross-Functional Teams: In
conventional software engineering, development was often
carried out by specialized teams working in isolation, with
handoffs between different phases. The new approaches
promote cross-functional teams comprising members with
different skills (developers, testers, designers, etc.) working
collaboratively throughout the project, fostering better
communication and shared ownership.
• Predictive Planning vs. Adaptive Planning:
Conventional software engineering focused on
detailed, predictive planning, aiming to define and
estimate the entire project upfront. The new
approaches embrace adaptive planning, where plans
are flexible and regularly adjusted based on new
information, changing priorities, and ongoing
feedback.
• Long Development Cycles vs. Short Iterations:
Conventional software engineering often involved long
development cycles, with the entire project being
planned and executed over extended periods. The new
approaches employ short iterations, typically lasting a
few weeks, enabling faster delivery of working
software, frequent validation of assumptions, and
earlier identification of potential issues.
• Heavy Process and Documentation Reviews vs.
Continuous Feedback: Conventional software
engineering relied on formal process gates and
extensive documentation reviews at specific
milestones. The new approaches emphasize
continuous feedback and regular reviews, such as daily
stand-ups, sprint reviews, and retrospectives, to
ensure transparency, identify and address issues
promptly, and promote continuous improvement.
 Principles of modern software
management
• The principles of modern software management
reflect the evolution of software development
practices and the adoption of more agile and
collaborative approaches. Here is a comparison
between these principles in the old (conventional) way
and the new (modern) way:
• Customer Collaboration over Contract Negotiation:
–Old Way: Emphasized formal contracts and negotiations
with customers to define requirements and project scope.
–New Way: Values collaborative and ongoing customer
collaboration throughout the project to gather feedback,
validate requirements, and prioritize work based on
customer needs.
• Adaptive Planning over Detailed Upfront Planning:
• Old Way: Focused on extensive upfront planning and detailed
project plans that aimed to predict and define the entire
project scope.
• New Way: Prioritizes adaptive planning, where plans are
flexible and continuously adjusted based on feedback,
changing requirements, and evolving project needs.
• Iterative and Incremental Development over Sequential
Phases:
• Old Way: Followed a sequential development process, such as
the waterfall model, where each phase (requirements,
design, development, testing) was completed before moving
to the next.
• New Way: Embraces iterative and incremental development,
with multiple short iterations where development, testing,
and feedback loops are intertwined to deliver incremental
value and allow for continuous improvement.
• Empowered and Self-Organized Teams over
Siloed Roles:
–Old Way: Relied on specialized roles and a
hierarchical structure where tasks were
assigned to individuals based on their
specialization.
–New Way: Fosters empowered and self-
organized teams where members
collaborate, take ownership, and share
responsibilities, leveraging their diverse skills
to deliver high-quality software collectively.
• Continuous Delivery and Feedback over Batch
Releases:
–Old Way: Aimed for large and infrequent
software releases, often requiring significant
effort for integration and deployment.
–New Way: Promotes continuous delivery,
where software is developed and released in
small increments, allowing for rapid
feedback, faster validation, and continuous
improvement.
• Continuous Integration and Test Automation
over Manual Processes:
• Old Way: Relying on manual integration and
testing processes that were time-consuming and
prone to errors.
• New Way: Emphasizes continuous integration
and test automation, where code changes are
frequently integrated and tested to detect
defects early and ensure the stability and quality
of the software.
• Embracing Change over Resisting Change:
–Old Way: Tended to resist changes to
requirements, considering them as potential risks to
project success.
–New Way: Embraces change as an opportunity for
improvement and encourages flexibility and
adaptability to accommodate evolving customer
needs and market dynamics.
•
• Collaboration and Communication over
Documentation Heavy Processes:
• Old Way: Focused on extensive documentation,
which could be time-consuming and could
potentially hinder communication and
collaboration.
• New Way: Values effective communication,
collaboration, and knowledge sharing within
teams, while still maintaining necessary
documentation at an appropriate level to
facilitate understanding and future reference.
• Continuous Improvement and Learning over
Static Processes:
• Old Way: Followed a fixed process and
resisted making changes to established
practices.
• New Way: Encourages a culture of continuous
improvement, where teams regularly reflect
on their processes, seek feedback, and adopt
new practices and tools to enhance efficiency,
quality, and customer satisfaction.
 Traditionla to an iterative process

• Transitioning from traditional (conventional)

software development to an iterative process
represents a shift towards more flexible and
adaptive approaches. Here's a comparison
between the old way (traditional) and the new
(iterative) process:
• Old Way (Traditional):
• Sequential and Linear: The old way followed a
sequential and linear development approach, often
following the waterfall model. Each phase
(requirements, design, development, testing) was
completed before moving to the next, with limited
opportunities for revisiting previous stages.
• Big-Bang Delivery: Emphasized a big-bang delivery at
the end of the project, where the entire software
product was developed and released in one go.
• Fixed Scope: The scope of the project was defined
upfront and considered fixed. Changes to
requirements were generally discouraged or required
formal change control processes.
• Extensive Upfront Planning: Extensive
planning was done at the beginning of the
project, attempting to predict and define all
requirements, deliverables, and timelines in
detail.
• Limited Customer Involvement: Customer
involvement was usually limited to the
requirements gathering phase, with minimal
interactions during development and testing.
• New Way (Iterative):
• Iterative and Incremental: The new way follows an
iterative and incremental approach. Development is
broken down into smaller cycles or iterations, each
delivering a working increment of the software
product.
• Continuous Delivery: Focuses on delivering working
software in regular intervals, with each iteration
adding value and incorporating customer feedback.
• Adaptive Scope: Scope flexibility is embraced, allowing
for changes in requirements and priorities throughout
the project. Customer feedback is incorporated
iteratively, leading to a more accurate understanding
of requirements.
• Adaptive Planning: Planning is done at the beginning of
each iteration and adjusted based on feedback and
changing project needs. The focus is on adapting to
new information and adjusting plans accordingly.
• Customer Collaboration: Active customer collaboration
is encouraged throughout the development process,
with regular interactions, demos, and feedback
sessions to ensure alignment and validate the product.
• Continuous Integration and Testing: Iterations involve
continuous integration of code changes, along with
automated testing. This helps identify and address
issues early, ensuring a stable and reliable software
product.
• Continuous Improvement: Teams regularly reflect on
their progress, seek feedback, and make adjustments
for continuous improvement. Lessons learned from
each iteration inform subsequent iterations, leading to
increased efficiency and quality.
• Embracing Change: The new process embraces change
and treats it as a natural part of software
development. Changes in requirements and priorities
are expected and accommodated throughout the
project.
• Transparent Communication: Open and transparent
communication is promoted within the team and with
stakeholders. Regular communication channels, such
as daily stand-ups and demos, foster collaboration and
ensure everyone is aligned.
THE END
THANK YOU