Subject - Software Engineering

Unit- B

Software Project Planning

Software project planning is the process of defining the objectives, scope, resources, timeline, and
risks involved in developing a software product. It serves as a roadmap for the development team to
follow and ensures that the project is completed efficiently, on time, and within budget.

Software project planning aims to define a clear roadmap for successful project execution. The primary
objectives ensure that the project is completed efficiently, within scope, budget, and timeline while
meeting quality standards.

Objectives of Software Project Planning

1. Define Project Scope and Goals
o Clearly outline the project's purpose, deliverables, and constraints.
o Ensure alignment with business and user requirements.
2. Estimate Resources and Budget
o Determine the human, technical, and financial resources needed.
o Allocate the budget effectively to avoid overspending.
3. Create a Realistic Schedule
o Break the project into tasks and assign deadlines.
o Identify dependencies and plan for parallel task execution.
4. Identify and Mitigate Risks
o Analyze potential risks (e.g., technical challenges, scope creep).
o Develop contingency plans to minimize negative impacts.
5. Define Roles and Responsibilities
o Assign tasks to developers, testers, designers, and project managers.
o Ensure accountability and efficient teamwork.
6. Ensure Quality Assurance
o Plan testing strategies to meet performance and security standards.
o Implement code reviews, user testing, and bug tracking.
7. Establish Communication Plans
o Maintain transparency with stakeholders through regular updates.
o Use reports, meetings, and documentation to track progress.
8. Plan for Change Management
o Establish a process to handle changes in requirements or technology.
o Ensure flexibility without compromising deadlines.
9. Optimize Resource Utilization
o Prevent resource underutilization or overload.
o Maximize efficiency in team productivity.
10. Ensure Successful Project Delivery

 Deliver software that meets functional, performance, and security expectations.

 Ensure smooth deployment and post-launch maintenance.
Decomposition Techniques
Decomposition is the process of breaking down a complex software system into smaller, manageable
parts. It helps in better understanding, designing, and implementing a software project.
Decomposition techniques are commonly used in software development, project management, and
system design to improve clarity and maintainability.

Software sizing:
Software sizing refers to estimating the size, complexity, and effort required to develop a software
system. In decomposition techniques, software sizing plays a crucial role in breaking down the system
into smaller, manageable components and estimating their development effort.

Software Sizing Techniques in Decomposition

1. Lines of Code (LOC) Sizing
o Measures the size of software based on the number of lines of code.
o Used in module-based decomposition, where each module’s size is estimated based on
the expected number of lines.
o Limitation: It does not consider complexity or functionality.
2. Function Point (FP) Sizing
o Measures the software size based on its functional requirements.
o Used in functional decomposition, where the system is broken down into individual
functionalities, and function points are assigned.
o Factors considered:
 Inputs (e.g., forms, user data entry)
 Outputs (e.g., reports, responses)
 User interactions (e.g., buttons, clicks)
 Files and external interfaces
3. Object Point Sizing
o Used in object-oriented decomposition by counting the number of objects, classes, and
their interactions.
o Takes into account:
 Number of objects
 Methods within each object
 Inheritance and relationships
4. Use Case Point (UCP) Sizing
o Based on use cases in process-based decomposition.
o Assigns weight to actors, use cases, and interactions to estimate size.
o Useful for systems designed using Unified Modelling Language (UML).
5. Work Breakdown Structure (WBS) Sizing
o Used in hierarchical decomposition, where the project is broken into tasks and
subtasks.
o Each task’s effort is estimated based on:
 Development time
 Complexity
 Dependencies
6. COCOMO (Constructive Cost Model) Sizing
o Uses mathematical models to estimate size based on:
 LOC (Basic COCOMO)
  Function Points (Intermediate COCOMO)
 Project complexity (Detailed COCOMO)
o Suitable for large-scale software decomposition.

Problem-Based Estimation in Software Engineering

Problem-based estimation is a technique used in software engineering to estimate the effort, time,
and cost required to develop a software system by breaking it down into smaller problems. Each sub-
problem is analysed individually, and its complexity, required resources, and effort are estimated
separately. The estimates for all sub-problems are then aggregated to get the total project estimate.

Steps in Problem-Based Estimation

1. Identify the Main Problem
o Define the software system’s overall objective and requirements.
2. Decompose the Problem into Smaller Sub-Problems
o Use problem-based decomposition to divide the system into manageable tasks.
3. Estimate Each Sub-Problem Separately
o Determine the effort, resources, and time required for each component.
o Consider factors like complexity, dependencies, and team expertise.
4. Combine Estimates to Get the Total Effort
o Sum the estimates of all sub-problems to calculate the overall project effort.
5. Adjust for Risk and Uncertainty
o Add buffer time for unexpected challenges.
o Consider historical data and expert judgment.

Process-Based Estimation in Software Engineering

Process-based estimation is a technique used in software engineering to estimate the effort, time, and
cost required for a project based on its development process. Instead of focusing on system
components or functionality, this approach considers the various phases of software development
(e.g., requirements analysis, design, coding, testing, deployment) and estimates effort for each phase
separately.

Key Steps in Process-Based Estimation

1. Identify the Software Development Phases
o Common phases in Software Development Life Cycle (SDLC) include:
 Requirements Analysis
 System Design
 Implementation (Coding)
 Testing
 Deployment
 Maintenance
2. Estimate Effort for Each Phase
o Use historical data or expert judgment to estimate the effort required for each phase.
o Assign percentage-based effort distribution (e.g., coding 40%, testing 30%, etc.).
3. Determine Resource Allocation
o Assign developers, testers, and designers to different phases.
 4. Calculate the Total Project Effort
o Sum up the effort required for each phase.
5. Adjust for Risk Factors
o Consider uncertainties such as scope changes, skill availability, and complexity.

COCOMO Model
The Constructive Cost Model (COCOMO) is a widely used software cost estimation model that helps predict the
effort, cost, and schedule required for a software development project. Developed by Barry Boehm in 1981,
COCOMO uses a mathematical formula based on the size of the software project, typically measured in lines of
code (LOC)1.

The key parameters that define the quality of any software product, which are also an outcome of
COCOMO, are primarily effort and schedule:
1. Effort: Amount of labour that will be required to complete a task. It is measured in person-
months units.
2. Schedule: This 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.
Types of Projects in the COCOMO Model :
In the COCOMO model, software projects are categorized into three types based on their complexity,
size, and the development environment. These types are:
1. 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.
2. 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 environments lie in
between 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
better guidance and creativity. Eg: Compilers or different Embedded Systems can be considered
Semi-Detached types.
3. Embedded: A software project requiring the highest level of complexity, creativity, and
experience requirement falls 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.

Comparison of these three types of Projects in COCOMO Model

Aspects Organic Semidetached Embedded
Project Size 2 to 50 KLOC 50-300 KLOC 300 and above KLOC
Complexity Low Medium High
Some experienced as
Mixed experience,
Highly experienced well as inexperienced
includes experts
Team Experience staff
Flexible, fewer Somewhat flexible, Highly rigorous, strict
Environment constraints moderate constraints requirements
Effort Equation E = 2.4(400)1.05 E = 3.0(400)1.12 E = 3.6(400)1.20
 New system interfacing
Simple payroll system Flight control software
Example with existing systems

The Six phases of detailed COCOMO are:

Phases of COCOMO Model

1. Planning and requirements: This initial phase involves defining the scope, objectives, and
constraints of the project. It includes developing a project plan that outlines the schedule,
resources, and milestones
2. System design: : In this phase, the high-level architecture of the software system is created. This
includes defining the system’s overall structure, including major components, their interactions,
and the data flow between them.
3. Detailed design: This phase involves creating detailed specifications for each component of the
system. It breaks down the system design into detailed descriptions of each module, including
data structures, algorithms, and interfaces.
4. Module code and test: This involves writing the actual source code for each module or
component as defined in the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.
5. Integration and test: This phase involves combining individual modules into a complete system
and ensuring that they work together as intended.
6. Cost Constructive model: The Constructive Cost Model (COCOMO) is a widely used method for
estimating the cost and effort required for software development projects.

S/w Equation in the COCOMO Model

The COCOMO (Constructive Cost Model) is an empirical model used for estimating effort, time, and
cost in software development projects. It is based on a mathematical equation derived from historical
project data.
The COCOMO software equation is: E=a×(KLOC)b×EAF

Where:

 E = Effort (measured in person-months)

 KLOC = Thousands of Lines of Code (size of the software)
 a, b = Model-specific constants (vary based on project type)
 EAF = Effort Adjustment Factor (accounts for cost drivers like team capability, tools, complexity)