Module 5

Software Management - Planning for software development

1
 Course Outcomes

After successful completion of the

course, the student will be able to:
1. Demonstrate understanding of
the process of Software
Development
2. Determine the Suitability of Uni Hour
Title
processes for varying software t s
application development 1 Introduction to Software Engineering 9
3. Differentiate Development 2 Software development phases and processes 9
phases through the life cycle of
software 3 Requirements, design and solution 9
4. Reflect on design choices and
development standards Implementation and Ensuring Quality of software
4 9
and Metrics
5. Check and verify software
quality from requirements to
release of software and across Software Management - Planning for software
5 9
versions. development
 Unit 5- Software Management - Planning For Software
Development
• Estimation of time, resources, the cost for software development:
• COCOMO,
• Function point,
• Putnam resource allocation models
• Planning activities and re-planning,
• Risk analysis
• Release mechanisms,
• Configuration management,
• Licensing methods and maintenance
• Software life cycle management –
• Planning,
• Tracking,
• Communication,
• Negotiation,
• Delivery,
• Quality aspects.
3
 Key Software Development Practices
• Definition: Planning involves defining project scope, objectives, tasks, schedules, and
resources.
• Importance: Ensures project success, avoids cost overruns, and manages risks
effectively.
• Key Challenges:
• Unclear requirements
• Changing technology
• Resource constraints
• Risk management complexities
• Key Elements of Planning:
• Estimation
• Risk Analysis
• Scheduling
• Maintenance Planning
4
Estimation of Time, Resources, and Cost for Software Development

• Software development estimation is crucial for planning, budgeting, and

resource allocation.
• Proper estimation helps in minimizing project risks, avoiding cost overruns,
and ensuring timely delivery.
• The estimation process involves:
• Time Estimation – Predicting the total duration of the project.
• Resource Estimation – Determining manpower, tools, and infrastructure
needed.
• Cost Estimation – Calculating the total project expenditure based on
resources and time.

5
 Estimation of Time
• Time estimation determines how long a project will take to complete, typically
measured in months or weeks.
• It is influenced by:
• Project size (Lines of Code (LOC) or Function Points (FP)).
• Complexity (Simple vs. Enterprise-level software).
• Development methodology (Agile, Waterfall, etc.).
• Methods for Time Estimation
• COCOMO (Constructive Cost Model) Approach
• Uses the effort estimation (Person-Months) to calculate time
• Function Point Analysis (FPA) Time Estimation
• Based on software functionality, independent of programming language.
• Expert Judgment & Historical Data
• Estimates based on previous similar projects and expert experience.
• Often used in Agile development for sprint planning.
6
 Estimation of Resources

• Resource estimation identifies the human, hardware, and software

requirements for project execution.
• Types of Resources in Software Projects
• Human Resources (Manpower)
• Developers, testers, project managers, and business analysts.
• Technical Resources
• Hardware: Servers, network infrastructure, cloud computing.
• Software: Development tools, testing frameworks, project management
tools.
• Infrastructure & Support Resources
• Office space, licenses, training programs, and documentation tools.
7
 Estimation of Cost

• Cost estimation calculates the total budget required to complete the

project. It includes:
• Personnel Costs – Salaries, training, and hiring expenses.
• Development Costs – Software, hardware, cloud, and infrastructure costs.
• Testing Costs – Tools for automation, manual testing, and debugging.
• Maintenance Costs – Post-deployment bug fixes, updates, and customer
support.
• Methods for Cost Estimation
• COCOMO Cost Estimation
• Function Point-Based Cost Estimation
• Putnam Resource Allocation Model.

8
 COCOMO (Constructive Cost Model)

• The COCOMO (Constructive Cost Model) is a software cost estimation model

developed by Barry Boehm in 1981.
• It is used to estimate effort, time, and cost for software development based on
project size (Lines of Code (LOC)).
• COCOMO helps in:
• Estimating effort (Person-Months) required to develop a software project.
• Predicting development time (Months) based on project complexity.
• Determining project cost by calculating effort and resource needs.
• Planning team size and resource allocation effectively.
• Types of COCOMO Models
• COCOMO has three models, each increasing in complexity.

9
 Types of COCOMO Models

COCOMO Model Description Usage

Estimates effort & time using only
Suitable for early-stage
Basic COCOMO KLOC (Lines of Code in
estimations.
Thousands).
Considers cost drivers like team More realistic for medium
Intermediate COCOMO
experience, complexity, and tools. to large projects.
Breaks effort into project phases
Used for large-scale
Detailed COCOMO (Design, Coding, Testing) for better
enterprise projects.
accuracy.

10
 Basic COCOMO Model
• The Basic COCOMO Model estimates effort and time based on only KLOC and project type.
• Basic COCOMO Project Categories

Project Type Description Constants (a, b, c, d)

Organic Small, simple projects with well-defined requirements a = 2.4, b = 1.05, c = 2.5, d = 0.38
Semi-Detached Medium-sized, moderately complex projects a = 3.0, b = 1.12, c = 2.5, d = 0.35

Embedded Large, complex, real-time systems with strict requirements a = 3.6, b = 1.20, c = 2.5, d = 0.32

Basic COCOMO Equations

• For the project type-based constants a, b, c, d.

• Effort Estimation (Person-Months) Equation:

• E=a×(KLOC)b
• Time Estimation (Months):
• T=c×(E)d
• Team Size Calculation:
• Team Size=E/T​

11
 Example: Basic COCOMO Calculation
• Project Type: Semi-Detached
• Estimated Size: 100 KLOC
• Step 1: Calculate Effort (E)
• E=3.0×(100)1.12 =3.0×132.2= 396.6 Person-Months
• Step 2: Calculate Time (T)
• T=2.5×(396.6)0.35=2.5×8.88=22.2 Months
• Step 3: Calculate Team Size
• Team Size=396.6/22.2​≈18 developers
• Answers:
• Effort: 396.6 Person-Months
• Time: 22.2 Months
• Team Size: ~18 developers

12
 Intermediate COCOMO Model

• The Intermediate COCOMO Model improves accuracy by considering 15 cost drivers that
affect software effort.
• Each cost driver is assigned a multiplicative factor (Effort Adjustment Factor - EAF)
between 0.7 (Very Low) and 1.66 (Very High).
Category Example Factors
Product Attributes Complexity, Reliability Requirements
Hardware Attributes Execution Time, Storage Constraints
Personnel Attributes Analyst Capability, Team Experience
Project Attributes Use of Tools, Development Schedule

• Effort Calculation in Intermediate COCOMO:

• E=a×(KLOC)b×EAF
13
 Intermediate COCOMO Calculation

• Project Type: Semi-Detached

• Size: 100 KLOC
• EAF = 1.2 (High complexity, tight schedule)
• Effort Calculation
• E=3.0×(100)1.12×1.2 = =396.6×1.2=475.9 Person-Months

14
 Detailed COCOMO Model

• The Detailed COCOMO Model is the most comprehensive and accurate

version of the COCOMO (Constructive Cost Model).
• It extends the Intermediate COCOMO Model by estimating effort and cost for
each phase of the software development life cycle (SDLC).
• Key Features of the Detailed COCOMO Model
• Phase-wise Estimation: Effort is distributed across different development
phases (Requirement Analysis, Design, Coding, Testing, etc.).
• Effort Multipliers for Each Phase: Uses cost drivers (Effort Adjustment
Factors, EAF) specific to each phase.
• More Precise than Basic & Intermediate COCOMO: Considers risk,
complexity, and team capability per phase.

15
Instead of estimating effort only once, it breaks it down phase-wise.

The effort for each phase is calculated as a percentage of the total effort.

16
 Example
• A Semi-Detached software project is estimated to have 100 KLOC. The effort adjustment factor
(EAF) due to project complexity, team experience, and tools used is 1.15. Calculate
• Total Effort (Person-Months)
• Distribute Effort Across Development Phases
• Calculate Development Time (Months)
• Estimate Team Size
• Solution:
1. Calculate Total Effort (Person-Months)
• For a Semi-Detached project, the constants are: a = 3.0, b = 1.12
• E=3.0×(100)1.12×1.15 = 456.1 Person-Months
2. Distribute Effort Across Development Phases
3. Calculate Development Time (Months)
• For Semi-Detached projects, the constants are: c = 2.5, d = 0.35
• T=2.5×(456.1)0.35 = 22.4 Months
4. Team Size== E/T = ​22.4456.1​≈20 developers
17
Effort (Person-Months)

18
Effort comparison

19
 Function Point Analysis (FPA)
• Function Point Analysis (FPA)
• FPA is a software estimation technique used to measure the functionality
provided by a system independent of programming language.
• Function Point Analysis (FPA) was developed by Allan Albrecht (IBM, 1979)
• It estimates software size, effort, and cost based on the number and complexity of
functional components such as inputs, outputs, inquiries, files, and interfaces.
• Why Use Function Point Analysis?
• Works across different programming languages (unlike LOC-based
estimation).
• More accurate for business applications that rely on inputs, outputs, and
reports.
• Useful in early project stages, before coding begins.
• Helps estimate project effort, cost, and timeline effectively.

20
• When to Use FPA?

• FPA is useful for:

• Early-stage project estimation
• Comparing software developed in different programming languages
• Agile, Waterfall, and Hybrid development models
• Estimating maintenance & enhancements

• Not suitable for:

• Hardware or infrastructure projects
• Small-scale projects with unclear requirements.

21
 Key Components of FPA
• Function Points are based on five functional components:
• Each component has a complexity level: Low, Average, High

Component Definition Example

External Inputs (EI) User inputs data Login form, product upload
External Outputs (EO) System provides output Invoice generation, order
confirmation
External Inquiries (EQ) User requests Search bar, order tracking
information
Internal Logical Files Internal data storage Customer database, product
(ILF) catalog.
External Interface Files Interfaces with other Payment API, shipping service
•(EIF)
Value Adjustment Factors (VAF) in Function
systems Point Analysis (FPA)
• Used to adjust the Unadjusted Function Points (UFP) based on project
complexity and environmental factors.

22
 Steps in Function Point Analysis
1. Identify five functional components of the system:
• External Inputs (EI) → Data entered into the system.
• External Outputs (EO) → Processed information displayed or exported.
• External Inquiries (EQ) → User requests for data retrieval.
• Internal Logical Files (ILF) → Data stored within the system.
• External Interface Files (EIF) → Shared data with other systems.
2. Assign weight factors based on complexity (Low, Average, High).
3. Calculate the Unadjusted Function Point (UFP) using:
• UFP=∑(Count × Weight_Factor)
4. Find Complexity Adjustment Factor (CAF) =
• CAF=0.65+(0.01×∑Fi)
• ΣFi = Sum of Influence Factors (Total influence score of the system).
• 0 = No influence, 5 = Strong influence
5. Multiply the Complexity Adjustment Factor (CAF) to get Final Function Points (FP):
• FP=UFP×CAF
6. Effort and Cost Estimation
23
Example

24
 Solution
1. Calculate Unadjusted Function Points (UFP): 1. Effort is 2.5 person-hours per FP
• UFP=∑(Number of Components × Complexity Weight)
2. Total Effort = FP * 2.5 = 612*2.5
• External Inputs (I): 30 × 4 = 120
• External Outputs (O): 60 × 5 = 300
• External Inquiries (E): 23 × 4 = 92
• Files (F): 8 × 10 = 80
• External Interfaces (N): 2 × 7 = 14
• 𝑈𝐹𝑃=120+300+92+80+14=606
2. Compute Complexity Adjustment Factor (CAF)
• CAF=0.65+(0.01×∑(Complexity Adjustment Factor))
• Total 14 factors
• 4 factors are not applicable (ignored) = 4*0=0
• 4 factors have a value of 3 = 4*3 = 12
• Remaining factors have a value of 4 = 6*4 = 24
• ∑(Complexity Adjustment Factor)) = 0+12+24 = 36
• VAF=0.65+(0.01×36)=0.65+0.36=1.01
3. Compute Function Points (FP)
FP=UFP×VAF = 606×1.01=612.06
4. The computed function point metric is 612 (rounded).

25
 Example of Function Point Calculation
• A banking system project has the following functional components, compute the Function Points (FP).
Estimate the effort, Time and Team size.
• Assume Effort per FP =2.5 Person-Hour.
• Unadjusted Function Point (UFP) Calculation :
• UFP = 40+56+18+50+40=204.
• Assuming CAF = 1.00 (moderate complexity),
• The final Function Points (FP) = 204.
• Effort=AFP×Effort per FP = 205×2.5
• Team Size for 6-Month Deadline =
• Team Size=Total Effort (Person-Months)​/ Project Duration (Months) =

26
 Advantages and Limitations of FP Method

• Advantages of Function Points

• Language-independent—same for Java, Python, C++, etc.
• Focuses on functionality, not code length—better for business applications.
• More accurate for effort estimation—used in Agile and COCOMO-II
models.
• Limitations of Function Points
• Requires expert judgment—assigning weight factors can be subjective.
• Complex calculation compared to LOC.

27
 Example
• A university management system is being developed, and the software team wants
to estimate the effort, development time, and team size using Function Point
Analysis (FPA). The system has the following functional components as in Table
1. Given, the Value Adjustment Factor (VAF) = 1.12, Effort per Function Point =
2.5 person-hours, Team Productivity = 12 FP per Person-Month, and Project
Deadline = 6 months.
• Estimate the
• Unadjusted Function Points (UFP).
• Adjusted Function Points (AFP).
• Estimate the total effort required, and
• Team size required to complete the project within 6 months.

28
 Function Point Calculation Steps

Estimation Factor Computed Value

Unadjusted Function Points (UFP) 252
Adjusted Function Points (AFP) 282
Total Effort (Person-Hours) 705
Total Effort (Person-Months) 23.5

Required Team Size (for 6-month deadline) 4 Developers

29
 Putnam Resource Allocation Model

• The Putnam Model, also known as the Software Lifecycle Management (SLIM)
Model, is a mathematical model for software effort estimation.
• It was developed by Lawrence H. Putnam in 1978 and is based on empirical
observations of software projects.
• To estimate effort, time, and team size required for software development
• Software development effort follows a Rayleigh Curve,
• The effort gradually increases, peaks in the middle, then decreases toward
completion.

30
RAYLEIGH CURVE

31
 Key Principles of the Putnam Model
Effort-Time Tradeoff:
• Reducing project time significantly increases effort exponentially.
• Increasing project time reduces manpower requirements.
• Software Development Follows a Rayleigh Curve:
• Effort starts low, peaks in the middle, and gradually decreases as the project is completed.
• Initial Phase: Planning and requirement analysis require low effort.
• Middle Phase: Coding and integration require maximum effort.
• Final Phase: Testing and maintenance require less effort.
• Productivity Factor (K) Determines Efficiency:
• The K-factor represents team productivity based on historical data.
• Higher K → More efficient team → Less effort required.
• Putnam’s Effort Estimation Formula: E= (K×S)3​/ T4
• E = Effort (Person-Years)
• K = Productivity Factor (varies based on technology, team skills, etc.)
• S = Estimated System Size (Lines of Code, LOC)
• T = Development Time (Years)

32
 Phases of the Putnam Model

Phase Description Effort Allocation

Planning & Requirement Define scope, requirements, and feasibility
15-20%
Analysis study.
Architecture, UI/UX design, and database
System & Software Design 20-25%
modeling.
Writing code, developing modules, and 35-40% (Peak
Coding & Implementation
integration. Effort)
Debugging, validation, and release
Testing & Deployment 20-25%
preparation.
Maintenance & Support Post-deployment fixes and feature updates. 10-15%

33
 Example Using the Putnam Model

• A software development company is building a large-scale banking application. The project is

estimated to require 150,000 Lines of Code (LOC) (150 KLOC). Given the development time (T) = 3
years and a Productivity Factor (K) of 2.5, estimate:
• Effort (Person-Years)
• Development Time (Years)
• Team Size (Number of Developers)
• Solution:
• Calculate the Effort (Person-Years) Using Putnam’s Formula: 650*10 14 Person-Years
• Estimate the Required Team Size: 217 Developers
• Experiment with Different Development Times(2 YEARS):
• E=3.29×10 15 Person-Years
• Hence, reducing project duration from 3 years to 2 years significantly increases the effort required.

34
Comparison of Models

35
 Planning activities and re-planning

• Planning is a critical phase in software project

management that
• ensures the successful execution of a project.
• It involves
• Defining the project's scope,
• Objectives,
• Timelines,
• Resources, and
• Risks.
• Due to the dynamic nature of software projects, re-
planning is often necessary to adapt to changes in
• Requirements,
• Risks, or
• Resource availability.
36
KEY PHASES IN PROJECT PLANNING

37
 Gantt chart?

• A Gantt chart is a horizontal bar chart used in project management to

visually represent a project over time.
• Gantt charts typically show you the timeline and status—as well as who’s
responsible—for each task in the project.
• Gantt charts are used to schedule, track, and communicate deliverables,
deadlines, dependencies, and resource assignments.
• Understanding the Gantt chart work:
• In a Gantt chart, all project activities run vertically down the y-axis of the
chart, with a timeline running horizontally across the x-axis.
• Each task listed down the left is represented by a horizontal bar on the right
side of the chart.

38
• These taskbars span from start date to end date to show the overall
duration of a task.
• As work gets done, each taskbar fills up to indicate the amount of progress
completed.
• If one task relies on another one to start or finish, a line will be drawn
between the two taskbars to mark a dependency.
• Since project milestones have a 0-day duration, they’re typically
represented by a yellow or gold diamond on the Gantt chart.
• Resource assignments are typically listed down the left beside the task name,
but may also appear within or next to taskbars on the right side of a Gantt
chart.

39
 Advantages Gantt Charts
• Advantages Gantt Charts
• Visualize your entire project
• See how tasks are connected
• Keep everyone on the same page and on time
• Know who’s busy and who isn’t?
• When should you use a Gantt chart for your project?
• Your project has a hard deadline.
• Tasks need to be done in a specific order.
• You have to coordinate multiple people or teams to execute the work.
• A boss, client, or team member wants to see a visual timeline of the project
from beginning to end.
• Team members juggle multiple projects at a time, and you need to manage
their workloads.
• You have a good idea of roughly how long each task should or can take.
40
Example for Gantt Chart

41
 Re-planning
• Why Re-planning is Necessary
• Changing Requirements: Stakeholders may request new features or changes to existing
ones.
• Unforeseen Risks: New risks may emerge during the project.
• Resource Constraints: Team members may leave, or budget may be reduced.
• Technological Changes: New tools or technologies may become available.
• Adaptive Planning Approaches
• Agile Planning:
• Iterative and incremental planning.
• Frequent re-evaluation of plans based on feedback.
• Example: In Scrum, the team re-plans during each sprint planning meeting.
• Rolling Wave Planning:
• Detailed planning for the near term and high-level planning for the long term.
• Example: Plan the next 2-3 months in detail and the rest of the project at a high level.

42
 Steps in Re-planning
1.Assess Current Status:
• Review the project's progress against the original plan.
• Identify deviations and their causes.
• Example: A project is behind schedule due to unexpected technical
challenges.
1.Identify Changes:
• Determine what has changed (e.g., requirements, risks, resources).
• Example: A stakeholder requests a new feature that was not in the original
scope.
1.Update Plans:
• Adjust the timeline, resource allocation, and budget.
• Example: Extend the project deadline by 2 months and allocate additional
developers.
1.Communicate Changes:
• Inform stakeholders about the changes and their impact.
• Example: Hold a meeting to explain the new timeline and resource
allocation.
1.Monitor and Control:
• Track progress against the updated plan.
• Make further adjustments as needed.
• Example: Use a dashboard to monitor task completion and resource
utilization.
 Best Practices for Planning and Re-planning

1. Involve Stakeholders:
• Engage stakeholders in the planning process to ensure their needs are
met.
2. Use Tools:
• Leverage project management tools like Jira, Trello, or Microsoft Project.
3. Document Plans:
• Maintain detailed documentation of plans and changes.
4. Monitor Progress:
• Regularly track progress and make adjustments as needed.
5. Communicate Effectively:
• Keep all stakeholders informed about the project's status and changes.

44
 Risk Analysis
• Risk: An uncertain event or condition that, if it occurs, has a positive or negative
effect on a project's objectives.
• Risk Analysis: The process of identifying, assessing, and prioritizing risks to
minimize their impact on the project.
• Importance of Risk Analysis
• Proactive Management: Helps in identifying potential issues before they
occur.
• Resource Allocation: Ensures that resources are allocated to mitigate high-
priority risks.
• Decision Making: Provides a basis for making informed decisions.
• Stakeholder Confidence: Increases stakeholder confidence by demonstrating
that risks are being managed.

45
 Types of Risk Analysis
• Qualitative Risk Analysis and Quantitative Risk Analysis.

1. Qualitative Risk Analysis

• Purpose: Identify and prioritize risks based on their impact and likelihood.
• Tools: Risk matrices, risk registers.
• Steps:
• Identify Risks: Brainstorm potential risks with the team.
• Assess Impact and Likelihood: Rate each risk on a scale (e.g., low,
medium, high).
• Prioritize Risks: Focus on high-impact, high-likelihood risks.
• Example: A risk matrix categorizing risks as high, medium, or low.

46
2. Quantitative Risk Analysis
• Purpose: Numerically analyze the impact of risks on project objectives.
• Tools: Monte Carlo simulations, decision trees, sensitivity analysis.
• Steps:
• Collect Data: Gather data on risk probabilities and impacts.
• Model Risks: Use statistical methods to model risks.
• Analyze Results: Determine the likelihood of meeting project objectives.
• Example: A Monte Carlo simulation predicting a 20% chance of project delay.

47
 Risk Analysis Techniques
• Risk Identification
• Objective: Identify all potential risks that could affect the project.
• Techniques: Brainstorming, checklists, SWOT analysis, interviews.
• Output: A list of identified risks.
• Risk Assessment
• Objective: Evaluate the likelihood and impact of each risk.
• Techniques: Risk matrix, probability and impact assessment, Monte Carlo simulation.
• Output: Prioritized list of risks.
• Risk Mitigation Planning
• Objective: Develop strategies to manage high-priority risks.
• Techniques: Avoidance, mitigation, transfer, acceptance.
• Output: Risk mitigation plan.
• Risk Monitoring and Control
• Objective: Track identified risks and monitor residual risks.
• Techniques: Regular risk reviews, risk audits, status meetings.
• Output: Updated risk register and mitigation plans.
48
 Best Practices for Risk Analysis
• Involve the Team:
• Engage the project team in risk identification and assessment.
• Use Multiple Techniques:
• Combine qualitative and quantitative methods for a comprehensive analysis.
• Document Risks:
• Maintain a risk register to document all identified risks and their mitigation
plans.
• Regular Reviews:
• Conduct regular risk reviews to update the risk register and mitigation plans.
• Communicate:
• Keep stakeholders informed about risks and their management.

49
• Risk prioritization is the process used by Compliance professionals to
analyze risks and determine the order in which they are mitigated. It is
a process for defining which risks are the highest priority to the
business and need remediated first.

• Resources available to risk managers are limited, and risk

prioritization allows organizations to break down risk into manageable
pieces sorted by certain criteria the business decides to follow.

50
• Risk attitude is the state of mind an organization or individual has
toward risk uncertainty.
• There are often three types of risk attitude: risk-averse, risk-
seeking, and risk-neutral.
• Each of these attitudes affects how stringent the remediation process
will be. Risk attitude helps inform the organization on which risks
should be prioritized based on the company’s disposition toward risk
(and risk appetite).
• Risk sensitivity is a quantitative risk assessment tool that helps
determine how changes in risk affect the overall risk posture, and thus,
the mitigation strategy. You will often encounter tornado charts when
analyzing sensitivity.

51
 Risk priority numbers?
• Used in quantitative approaches to risk prioritization, risk priority
numbers help determine which risks are a priority based on their
financial impact. Rather than trusting a gut feeling or guessing like in
qualitative analysis, quantitative risk analysis is fact based.
• Threat: a potentially harmful incident
• Vulnerability: a weakness that can allow the Threat to do harm.
• Impact: how bad is it?

52
Risk Table

53
 Tools for Risk Analysis
• Risk Register:
• A document that lists all identified risks, their assessment, and mitigation
plans.
• Risk Matrix:
• A grid that maps the likelihood and impact of risks.
• Monte Carlo Simulation Software:
• Tools like @Risk or Crystal Ball for quantitative risk analysis.
• Project Management Software:
• Tools like Jira, Trello, or Microsoft Project for tracking risks.

54
 Release Mechanisms
• Release Mechanism is a structured process for deploying software updates,
patches, or new versions to users.
• Ensures that software is delivered reliably, efficiently, and with minimal risk
to users.
• Importance of Release Mechanisms
• Quality Assurance: Ensures that only thoroughly tested and approved
software is released.
• User Satisfaction: Minimizes disruptions and provides users with new
features and bug fixes.
• Risk Management: Reduces the risk of introducing critical issues into
production environments.
• Compliance: Ensures that releases meet regulatory and organizational
standards.

55
 Types of Release Strategies
1.Alpha Release:
1. Purpose: Internal testing by developers.
2. Characteristics: Unstable, not feature-complete.
3. Example: A pre-release version for internal bug testing.
2.Beta Release:
1. Purpose: External testing by a select group of users.
2. Characteristics: More stable, feature-complete but may have minor bugs.
3. Example: A beta version released to early adopters for feedback.
3.Incremental Release:
1. Purpose: Release features in stages.
2. Characteristics: Gradual rollout, reduces risk of major issues.
3. Example: Releasing a new feature set every two weeks.

56
 Types of Release Strategies
4. Continuous Deployment:
• Purpose: Automate the deployment of code changes to production.
• Characteristics: Frequent, small updates, relies on automated testing.
• Example: Deploying code changes multiple times a day (e.g., Google Chrome).

5. Rolling Release:
• Purpose: Continuously update software without versioning.
• Characteristics: Users always have the latest version.
• Example: Linux distributions like Arch Linux.

6. Big Bang Release:

• Purpose: Release all features at once.
• Characteristics: High risk, requires extensive testing.
• Example: Launching a new product version with all new features.
57
 Release Process
1.Planning:
• Define the scope, objectives, and timeline of the release.
• Identify stakeholders and their requirements.
• Example: Creating a release plan for a new feature set.
2.Development:
• Implement and test new features or bug fixes.
• Example: Developers coding and unit testing new functionality.
3. Testing:
• Conduct thorough testing, including unit, integration, and system
testing.
• Example: Running automated tests and manual QA checks.
4.Staging:
• Deploy the release to a staging environment that mimics production.
• Example: Testing the release in a staging environment to identify
issues.
5.Deployment:
• Release the software to production. 58
 Tools for Release Management
• Tools for Release Management

• Version Control Systems: Manage code changes and collaborate with team members.
• Tools: Git, SVN, Mercurial.
• Example: Using Git to track changes and manage branches for a release.
• Continuous Integration/Continuous Deployment (CI/CD) Tools: Automate the build, test,
and deployment processes.
• Tools: Jenkins, GitLab CI, CircleCI.
• Example: Setting up a Jenkins pipeline to automate deployments.
• Configuration Management Tools: Manage and automate infrastructure and application
configurations.
• Tools: Ansible, Puppet, Chef.
• Example: Using Ansible to automate server configurations for a release.
• Monitoring and Logging Tools: Track the performance and health of the release.
• Tools: New Relic, Datadog, Splunk.
• Example: Using Datadog to monitor application performance post-release.
59
 Best Practices for Release Mechanisms

1.Automate Where Possible:

• Use CI/CD tools to automate testing and deployment.
• Example: Automating unit tests and deployment pipelines.

2.Maintain a Staging Environment:

• Test releases in an environment that mimics production.
• Example: Using a staging server to test releases before deployment.

3.Use Feature Flags:

• Enable or disable features without deploying new code.
• Example: Using feature flags to roll out a new feature gradually.

60
 Best Practices for Release Mechanisms
4. Monitor Post-Release:
• Track performance and user feedback after the release.
• Example: Using monitoring tools to identify and fix issues quickly.

5. Communicate with Stakeholders:

• Keep stakeholders informed about the release process and status.
• Example: Sending release notes and updates to stakeholders.

6. Rollback Plan:
• Have a plan to revert to a previous version if issues arise.
• Example: Maintaining a backup of the previous release for quick rollback

61
 Common Challenges and Solutions

• Challenge: Release Failures

• Solution: Implement thorough testing and staging processes.
• Example: Using automated testing and a staging environment to catch issues
early.

• Challenge: User Disruptions

• Solution: Use feature flags and incremental releases.
• Example: Rolling out a new feature to a small group of users first.

• Challenge: Coordination Among Teams

• Solution: Use collaboration tools and clear communication.
• Example: Using Slack and Jira to coordinate release activities.

62
 Configuration Management
• Configuration Management (CM): A process for managing and controlling
changes to software artifacts, including code, documentation, and configurations.
• Purpose: Ensure that the software product remains consistent, reliable, and
traceable throughout its lifecycle.
• Importance of Conversion Control: Tracks changes to software artifacts,
enabling rollback and comparison.
• Consistency: Ensures that all team members work with the same versions of
artifacts.
• Traceability: Provides a history of changes, making it easier to identify and
fix issues.
• Collaboration: Facilitates teamwork by managing concurrent changes.
• Compliance: Helps figuration Management

63
 Key Components of Configuration Management
• Configuration Items (CIs)
• Any component that needs to be managed as part of the software project (e.g., source code,
documentation, binaries, configurations).
• Examples: Source files, build scripts, test cases, requirements documents.

• Version Control
• Purpose: Track changes to CIs over time.
• Tools: Git, SVN, Mercurial.
• Example: Using Git to manage source code versions.

• Baseline
• A set of CIs that have been formally reviewed and agreed upon, serving as a reference point
for further development.
• Example: A baseline for a software release includes all code, documentation, and
configurations approved for that release.

64
 Key Components of Configuration Management

• Change Control
• Purpose: Manage and control changes to CIs.
• Process: Request, review, approve, implement, and verify changes.
• Example: Using a change control board to review and approve change requests.

• Configuration Audits
• Purpose: Verify that the product meets its requirements and that all changes have been
properly implemented.
• Types:
• Functional Configuration Audit (FCA): Verifies that the product meets its functional
requirements.
• Physical Configuration Audit (PCA): Verifies that the product's physical attributes
match its design documentation.

65
Configuration Management Process

66
 Configuration Management Process
1. Identification: Identify and define all CIs.
• Activities:
• Define the scope of CIs.
• Assign unique identifiers to CIs.
• Document relationships between CIs.
• Example: Identifying source code files, build scripts, and documentation as CIs.
2. Control: Manage changes to CIs.
• Activities:
• Establish a change control process.
• Use version control tools to track changes.
• Implement access controls to prevent unauthorized changes.
• Example: Using Git to track changes and a change control board to approve modifications.
3. Status Accounting: Record and report the status of CIs and changes.
• Activities:
• Maintain a configuration status report.
• Track the status of change requests.
• Provide reports to stakeholders.
• Example: Generating a report showing the status of all open change requests.

67
 Configuration Management Process

4. Verification and Audit: Ensure that CIs meet their requirements and that changes have been
properly implemented.
• Activities:
• Conduct functional and physical configuration audits.
• Verify that all changes have been documented and approved.
• Example: Performing an audit to ensure that the latest release meets its requirements.

5. Monitoring:
• Track the release's performance and user feedback.
• Example: Using monitoring tools like New Relic or Datadog to identify issues.

6. Post-Release Activities:
• Address any issues that arise after the release.
• Example: Providing hotfixes for critical bugs.

68
 Tools for Configuration Management
• Version Control Systems
• Purpose: Track changes to CIs.
• Tools: Git, SVN, Mercurial.
• Example: Using Git to manage source code versions.
• Configuration Management Databases (CMDBs)
• Purpose: Store and manage information about CIs.
• Tools: ServiceNow, BMC Remedy, Microsoft System Center.
• Example: Using ServiceNow to track hardware and software configurations.
• Build and Deployment Tools
• Purpose: Automate the build and deployment of software.
• Tools: Jenkins, Ansible, Puppet, Chef.
• Example: Using Jenkins to automate the build and deployment process.
• Change Management Tools
• Purpose: Manage and track change requests.
• Tools: Jira, Trello, Asana.
• Example: Using Jira to track and approve change requests.

69
 Best Practices for Configuration Management
1. Define and Document CIs:
• Clearly define and document all CIs and their relationships.
• Example: Maintaining a CI inventory with unique identifiers.
2. Implement Version Control:
• Use version control tools to track changes to CIs.
• Example: Using Git to manage source code versions.
3. Establish a Change Control Process:
• Implement a formal process for requesting, reviewing, and approving changes.
• Example: Using a change control board to review and approve changes.
4. Conduct Regular Audits:
• Perform regular configuration audits to ensure compliance with requirements.
• Example: Conducting a functional configuration audit before a release.
5. Automate Where Possible:
• Use automation tools for build, deployment, and configuration management.
• Example: Using Ansible to automate server configurations.
6. Maintain Documentation:
• Keep detailed documentation of all CIs, changes, and audits.
• Example: Maintaining a configuration status report.
70
 Common Challenges and Solutions

1. Challenge: Managing Concurrent Changes

• Solution: Use version control systems and branching strategies.
• Example: Using Git branches to manage concurrent development.

2. Challenge: Ensuring Consistency

• Solution: Implement automated build and deployment tools.
• Example: Using Jenkins to ensure consistent builds.

3. Challenge: Compliance with Regulations

• Solution: Conduct regular configuration audits.
• Example: Performing a functional configuration audit before each release.

71
 Licensing Methods
• Software License: A legal agreement that grants users the right to use, modify, or
distribute software under specific terms and conditions.
• Purpose: Protect intellectual property, define usage rights, and ensure compliance
with legal and regulatory requirements.
• Importance of Licensing
• Intellectual Property Protection: Prevents unauthorized use or distribution
of software.
• Revenue Generation: Enables monetization of software through sales or
subscriptions.
• Collaboration: Facilitates open-source development by defining contribution
and usage terms.
• Compliance: Ensures adherence to legal and regulatory standards.

72
 Types of Software Licenses
1. Proprietary Licenses
• Definition: Restrictive licenses that limit usage, modification, and distribution.
• Characteristics:
• Source code is not shared.
• Users must purchase or subscribe to use the software.
• Redistribution is prohibited or restricted.
• Examples:
• Microsoft Windows: Requires a license key for activation.
• Adobe Photoshop: Sold as a subscription-based service.

2. Open-Source Licenses
• Definition: Permissive licenses that allow users to view, modify, and distribute source code.
• Characteristics:
• Source code is freely available.
• Users can modify and redistribute the software.
• Often require attribution or sharing of derivative works.
• Examples:
• MIT License: Allows almost unrestricted use, modification, and distribution.
• GNU General Public License (GPL): Requires derivative works to be open-source.
73
 Types of Software Licenses
3. Freeware
• Definition: Software that is free to use but may have restrictions on modification or distribution.
• Characteristics:
• No cost to the user.
• Source code may or may not be available.
• Redistribution is often restricted.
• Examples:
• Google Chrome: Free to use but proprietary.
• WinRAR: Freeware with a paid upgrade option.
4. Shareware
• Definition: Software that is distributed for free on a trial basis, with payment required for continued use.
• Characteristics:
• Limited functionality or time-bound usage.
• Users must purchase a license for full access.
• Examples:
• WinZip: Trial version with a paid upgrade.
• Adobe Acrobat Reader: Free version with paid features.
74
 Types of Software Licenses
5. SaaS (Software as a Service) Licenses
• Definition: Subscription-based licenses for cloud-hosted software.
• Characteristics:
• Users pay a recurring fee for access.
• Software is hosted and maintained by the provider.
• No need for local installation or updates.
• Examples:
• Salesforce: Cloud-based CRM with subscription licensing.
• Microsoft 365: Subscription-based office productivity suite.
6. Custom Licenses
• Definition: Tailored licenses designed for specific use cases or organizations.
• Characteristics:
• Terms are negotiated between the licensor and licensee.
• Often used for enterprise software or specialized applications.
• Examples:
• Enterprise Software: Custom licenses for large organizations.
• Government Contracts: Special licensing for public sector use.

75
 Key Concepts in Software Licensing

• Permissive Licenses: Allow almost unrestricted use, modification, and distribution, with minimal
requirements (e.g., attribution).
• Examples: MIT License, Apache License.
• Copyleft Licenses: Require derivative works to be open-source and distributed under the same license.
• Examples: GNU GPL, AGPL.
• Dual Licensing: Offering software under two different licenses (e.g., open-source and proprietary).
• Purpose: Provide flexibility for different use cases.
• Example: MySQL is available under the GPL or a proprietary license.
• End-User License Agreement (EULA): A legal contract between the software provider and the end-user.
• Purpose: Define the terms of use, restrictions, and liabilities.
• Example: The EULA for Microsoft Windows outlines usage rights and restrictions.
• Software Patents
• Definition: Legal protection for software inventions.
• Purpose: Prevent others from using, making, or selling the patented technology.
• Example: Amazon's "1-Click" patent for online purchasing .

76
 Real-World Examples of Licensing Methods
• Open-Source Licensing
• Linux Kernel: Licensed under the GNU GPL, allowing free use, modification, and
distribution.
• React.js: Licensed under the MIT License, enabling widespread use in commercial projects.

• Proprietary Licensing
• Microsoft Office: Requires a paid license for use, with restrictions on redistribution.
• Oracle Database: Proprietary software with complex licensing terms for enterprise use.

• SaaS Licensing
• Slack: Subscription-based licensing for team collaboration tools.
• Zoom: Cloud-based video conferencing with tiered subscription plans.

77
 Best Practices for Software Licensing

1. Choose the Right License:

• Select a license that aligns with your goals (e.g., open-source, proprietary).
• Example: Use the MIT License for permissive open-source projects.
2. Understand License Terms:
• Ensure compliance with license requirements (e.g., attribution, copyleft).
• Example: Comply with GPL terms when using open-source libraries.
3. Document Licensing:
• Maintain clear documentation of licenses for all software components.
• Example: Use a NOTICE file to list licenses for dependencies.
4. Monitor Compliance:
• Regularly audit software usage to ensure compliance with licensing terms.
• Example: Use tools like FOSSA or Black Duck for license compliance.
5. Negotiate Custom Licenses:
• For enterprise or specialized use cases, negotiate custom licensing terms.
• Example: Custom licensing for government or healthcare software.
78
 Challenges in Software Licensing
• License Compatibility
• Challenge: Combining software with incompatible licenses.
• Solution: Carefully review license terms before integration.
• Example: Avoid combining GPL-licensed code with proprietary software.
• Compliance Risks
• Challenge: Ensuring compliance with complex licensing terms.
• Solution: Use automated tools and legal expertise.
• Example: Regularly audit software for compliance with open-source licenses.
• Revenue Leakage
• Challenge: Unauthorized use or distribution of proprietary software.
• Solution: Implement license enforcement mechanisms.
• Example: Using license keys or activation codes.

79
 Software Maintenance and Life Cycle Management

• Software maintenance and life cycle management are critical components of software engineering
• They ensure the longevity, reliability, and quality of software products.
• Software Maintenance
• The Software Maintenance is a process of modifying and updating software after delivery to
• Correct faults,
• Improve performance, or
• Adapt to a changed environment.
• It ensures that the software remains functional, efficient, and relevant over time.
• Importance of Software Maintenance
• Bug Fixes: Correct errors and defects discovered after release.
• Performance Improvement: Optimize software for better efficiency.
• Adaptation: Modify software to work in new environments or with new hardware.
• Enhancements: Add new features or improve existing ones based on user feedback.

80
 Types of Software Maintenance

• Corrective Maintenance
• Purpose: Fix defects and bugs identified after the software is released.
• Example: Patching a security vulnerability in a web application.
• Adaptive Maintenance
• Purpose: Modify the software to work in a new environment or with new hardware.
• Example: Updating software to be compatible with a new operating system.
• Perfective Maintenance
• Purpose: Improve performance, usability, or functionality based on user feedback.
• Example: Optimizing database queries to reduce response times.
• Preventive Maintenance
• Purpose: Update the software to prevent future issues.
• Example: Refactoring code to improve maintainability and reduce technical debt.

81
 Software Life Cycle Management

• Software Life Cycle Management (SLCM):

• The process of managing the entire lifecycle of software, from initial planning to retirement.
• Purpose:
• Ensure that software is developed, deployed, and maintained efficiently and effectively.
• Key Activities in SLCM
• Planning
• Tracking
• Communication
• Negotiation
• Delivery
• Quality Aspects

82
 Key Activities in SLCM
1. Planning
• Objective:
• Define the scope, objectives, and resources for the software project.
• Activities:
• Develop a project plan.
• Identify stakeholders and their requirements.
• Estimate effort, cost, and schedule.
• Example: Creating a project charter and timeline for a new software product.
2. Tracking
• Objective: Monitor progress against the project plan.
• Activities:
• Use tools like Gantt charts or project management software.
• Track milestones and deliverables.
• Example: Using Jira to track task completion and project progress.
3. Communication
• Objective: Ensure effective communication among stakeholders.
• Activities:
• Hold regular meetings and status updates.
• Use collaboration tools like Slack or Microsoft Teams.
• Example: Conducting weekly team meetings and sending monthly stakeholder reports. 83
 Key Activities in SLCM
4. Negotiation
• Objective: Resolve conflicts and reach agreements on project aspects.
• Activities:
• Negotiate scope, timelines, and resources.
• Use techniques like win-win negotiation.
• Example: Negotiating a project deadline extension with stakeholders.
5. Delivery
• Objective: Ensure successful deployment of the software.
• Activities:
• Plan and execute the release process.
• Conduct post-release monitoring and support.
• Example: Using Jenkins to automate the deployment of a new software release.
6. Quality Aspects
• Objective: Ensure that the software meets quality standards.
• Activities:
• Conduct code reviews and testing.
• Use quality metrics like defect density and code coverage.
• Example: Implementing automated testing and continuous integration to maintain code quality.
84
 Maintenance Best Practices
1. Regular Updates:
• Schedule regular maintenance windows for updates and patches.
• Example: Monthly maintenance windows for security updates.

2. User Feedback:
• Collect and analyze user feedback to identify areas for improvement.
• Example: Using surveys and feedback forms to gather user input.

3. Documentation:
• Maintain detailed documentation of changes and updates.
• Example: Keeping a changelog for each software release.

4. Automated Testing:
• Use automated testing to quickly identify and fix issues.
• Example: Implementing unit tests and integration tests.

85
 Life Cycle Management Best Practices
1. Comprehensive Planning:
• Develop a detailed project plan with clear objectives and timelines.
• Example: Creating a Gantt chart for project milestones.
2. Effective Communication:
• Ensure regular and clear communication among all stakeholders.
• Example: Using Slack for team communication and Confluence for documentation.
3. Risk Management:
• Identify and mitigate risks throughout the project lifecycle.
• Example: Conducting regular risk assessments and maintaining a risk register.
4. Quality Assurance:
• Implement rigorous testing and quality control processes.
• Example: Using continuous integration tools like Jenkins to automate testing.
5. Continuous Improvement:
• Regularly review and improve processes based on lessons learned.
• Example: Conducting post-mortem meetings after each project phase.

86
 Tools for Maintenance and Life Cycle Management

• Maintenance Tools
• Version Control: Git, SVN.
• Bug Tracking: Jira, Bugzilla.
• Automated Testing: Selenium, Jenkins.

• Life Cycle Management Tools

• Project Management: Jira, Trello, Microsoft Project.
• Communication: Slack, Microsoft Teams.
• Documentation: Confluence, SharePoint.

87
 Case Studies
• Maintenance Tools
• Version Control: Git, SVN.
• Bug Tracking: Jira, Bugzilla.
• Automated Testing: Selenium, Jenkins.
• Life Cycle Management Tools
• Project Management: Jira, Trello, Microsoft Project.
• Communication: Slack, Microsoft Teams.
• Documentation: Confluence, SharePoint.
• Maintenance in Open-Source Projects
• Challenge: Managing contributions and updates from a global community.
• Solution: Use version control and automated testing to manage changes.
• Outcome: Successful maintenance of projects like Linux and Apache.
• Life Cycle Management in Agile Environments
• Challenge: Adapting to changing requirements in an Agile environment.
• Solution: Implement iterative planning and continuous integration.
• Outcome: Faster delivery of features and improved stakeholder satisfaction.

88
 Challenges and Solutions

• Challenge: Managing Technical Debt

• Solution: Regularly refactor code and prioritize preventive maintenance.
• Example: Allocating time in each sprint for refactoring.
• Challenge: Ensuring Quality
• Solution: Implement rigorous testing and quality control processes.
• Example: Using automated testing and continuous integration.
• Challenge: Stakeholder Communication
• Solution: Use collaboration tools and hold regular meetings.
• Example: Using Slack for team communication and Confluence for
documentation.

89