UNIT-III

SOFTWARE PLANNING
 Responsibilities of Software Project Manager
A Software Project Manager (SPM) is responsible for planning, executing, monitoring, and
delivering a software project successfully. Their primary role is to ensure that the project is
completed on time, within budget, and meets quality standards while managing risks and
resources efficiently.

Key Responsibilities of a Software Project Manager

1. Project Planning & Scheduling

 Define the project scope, objectives, and deliverables.

 Develop a detailed project schedule with timelines and milestones.
 Identify tasks, dependencies, and resource requirements.
 Use project management tools like Gantt charts, PERT charts, and Agile boards.

2. Cost Estimation & Budgeting

 Estimate cost, time, and effort using models like COCOMO, Function Points, or
Expert Judgment.
 Allocate financial resources effectively to avoid cost overruns.
 Monitor expenses to ensure the project stays within budget.

3. Risk Management

 Identify potential risks and challenges in the project.

 Develop risk mitigation strategies to minimize impact.
 Continuously monitor and update risk assessments throughout the project lifecycle.

4. Resource Allocation & Team Management

 Assign the right team members to the right tasks based on their expertise.
 Ensure adequate hardware, software, and tools are available for development.
 Resolve team conflicts and ensure smooth collaboration.

5. Quality Assurance & Testing

 Define quality standards and ensure compliance.

 Implement software testing strategies (unit testing, integration testing, system
testing).
 Work closely with the QA (Quality Assurance) team to ensure defect-free software.

6. Communication & Stakeholder Management

 Act as a bridge between clients, developers, and stakeholders.

  Maintain regular communication to keep all parties updated.
 Organize meetings, presentations, and progress reports.

7. Project Monitoring & Control

 Use performance metrics to track project progress.

 Identify delays or deviations and take corrective actions.
 Monitor team productivity and efficiency.

8. Documentation & Reporting

 Maintain proper documentation of requirements, design, testing, and deployment.

 Prepare status reports for senior management and stakeholders.
 Ensure that all project-related documents are properly stored and accessible.

9. Change Management

 Handle requirement changes effectively without disrupting the project.

 Ensure that any modifications are properly documented and approved.
 Evaluate the impact of changes on cost, time, and resources.

10. Deployment & Maintenance

 Plan and oversee the deployment of the software.

 Provide post-deployment support and handle bug fixes.
 Ensure the system is scalable and maintainable for future enhancements.

 Metrics for Project Size Estimation

Project size estimation is a crucial step in software engineering that helps in predicting the
effort, cost, time, and resources required for software development. One of the most widely
used metrics for project size estimation is LOC (Lines of Code).

 LOC(LINE OF CODE)
LOC (Lines of Code) is a software metric that measures the size of a software project by counting
the number of lines in the source code. It includes all the executable lines, but it excludes comments
and blank lines.

Formula for LOC-Based Estimation

Project effort estimation based on LOC can be done using:

Effort=a×(KLOC)^b
Types of LOC Counting Methods
There are two types of LOC counting methods:

1. Physical LOC (PLOC):

o Counts the total number of lines in the program, including comments and
blank lines.
o Easy to calculate but may lead to inconsistencies due to differences in coding
styles.
2. Logical LOC (LLOC):
o Counts only the executable statements and ignores blank lines and
comments.
o More accurate in estimating actual development effort

Advantages of LOC Metric

Simple and easy to measure – Just count the lines of code.
Useful for productivity measurement – Helps compare developer performance.
Can be used across projects – Especially useful for projects using the same language.

Disadvantages of LOC Metric

Language dependency – The same program in Python will have fewer lines than in Java or
C.
Does not measure complexity – More lines don’t always mean a better or more complex
program.
Encourages inefficient coding – Developers may write longer, redundant code to meet LOC
targets.
Difficult to estimate for modern projects – With code reuse, libraries, and frameworks,
LOC is often misleading.

 Function Point Metric

The Function Point (FP) metric is a software size estimation technique that measures the
functionality provided by a software system rather than counting the lines of code (LOC). It
was introduced by Allan Albrecht at IBM in the late 1970s.

Function Points measure software based on what it does, not how it is implemented. It is
language-independent and considers the user's perspective of system functionality.
Components of Function Point Metric
Function Point Analysis (FPA) evaluates a software system based on five key components:

1. External Inputs (EI)

 User inputs that modify system data.

 Example: Forms for user registration, order entry.

2. External Outputs (EO)

 Information sent out by the system.

 Example: Reports, invoices, confirmation messages.

3. External Inquiries (EQ)

 User requests for information without updating data.

 Example: Searching for customer details, lookup requests.

4. Internal Logical Files (ILF)

 Data files maintained by the system.

 Example: Customer database, product catalog.

5. External Interface Files (EIF)

 Data files used by the system but maintained externally.

 Example: A shared database accessed by multiple applications.

Advantages of Function Point Metric

Language-independent – Can be used for Java, Python, C++, etc.
Focuses on functionality – Measures what the software does, not how it is coded.
Useful for early estimation – Can estimate effort before development starts
Better for comparing projects – More reliable for productivity analysis.

Disadvantages of Function Point Metric

Requires expertise – Function point counting needs experience.
Subjectivity – Complexity ratings may vary between estimators.
Time-consuming – More steps involved than LOC-based estimation.

 What is Project Estimation?

Project estimation in software engineering involves predicting the effort, cost, and time
required to complete a software project. One of the most widely used estimation models is the
COCOMO (Constructive Cost Model) developed by Barry Boehm in 1981.

COCOMO helps in estimating:

Effort (Person-Months)
Time (Schedule in Months)
Cost (Budget Required)
Team Size

 COCOMO (Constructive Cost Model)

The COCOMO model provides a mathematical formula for estimating software
development effort based on the project size (in KLOC – Thousands of Lines of Code).

Types of COCOMO Models

COCOMO is divided into three versions:

1. Basic COCOMO – Estimates effort based only on LOC (Lines of Code).

2. Intermediate COCOMO – Considers additional factors like team experience, tools, and
hardware.
3. Detailed COCOMO – Breaks down effort estimation across different phases of
development.

1. Basic COCOMO Model

Formula for Effort Estimation

E=a×(KLOC)^b

Where:

 E = Effort (in person-months)

 KLOC = Thousands of Lines of Code
 a, b = Constants based on project type

Formula for Development Time

T=c×(E)d^T

Where:

 T = Development Time (in months)

 E = Effort from the previous formula
 c, d = Constants based on project type
Effort Required: ~203 person-months
Development Time: ~24 months

2. Intermediate COCOMO Model

The Intermediate COCOMO model improves accuracy by considering additional factors
called Cost Drivers (Effort Adjustment Factors - EAF).

Formula for Effort in Intermediate COCOMO

E=a×(KLOC)^b×EAFE

Where:

 EAF (Effort Adjustment Factor) = Product of all cost drivers

 The remaining terms are the same as Basic COCOMO

Provides quantitative estimates – More accurate than expert judgment.

Works for different types of projects – Organic, Semi-Detached, and Embedded.
Improves decision-making – Helps in resource planning and budgeting.
Intermediate & Detailed models improve accuracy – By considering cost drivers.

Disadvantages of COCOMO Model

Depends on historical data – Needs past project data for accurate results.
Assumes Waterfall Model – Less effective for Agile or iterative development.
LOC-based estimation has limitations – Modern software uses reusable components,
reducing LOC relevance.
Detailed COCOMO is complex – Harder to implement in small organizations.

 Software Requirement Specification (SRS)

A Software Requirement Specification (SRS) is a formal document that defines the

functional and non-functional requirements of a software system. It serves as a contract
between the client and the development team, ensuring that the final product meets
business and technical needs.
Key Purpose of SRS:

 Clearly define software requirements to avoid misunderstandings.

 Act as a blueprint for development, testing, and maintenance.
 Help in cost estimation and project planning.
 Ensure all stakeholders (developers, testers, clients) are aligned.

Importance of SRS in Software Engineering

Improves Communication – Avoids misinterpretation between teams.
Serves as a Reference – Guides developers, testers, and maintainers.
Helps in Project Estimation – Defines scope, timeline, and cost.
Ensures Quality – Provides measurable goals for verification and validation.

Structure of SRS
It consists of three main sections:

1. Introduction

 Purpose – Defines why the software is being developed.

 Scope – Describes what the software will and will not do.
 Definitions, Acronyms, and Abbreviations – Explains technical terms.
 References – Lists related documents, such as business rules or compliance documents.
 Overview – Provides a brief description of the SRS structure.
2. Overall Description

 Product Perspective – How this software fits into an existing system.

 Product Functions – High-level features of the software.
 User Characteristics – Expected user skills, experience level, etc.
 Constraints – Hardware/software limitations, security constraints.
 Assumptions and Dependencies – External factors that may affect the software.

3. Specific Requirements

 Functional Requirements – Defines system behavior and interactions.

 Non-functional Requirements – Performance, security, usability, etc.
 External Interface Requirements – Interfaces with hardware, other software, and users.
 System Features – Detailed explanation of each feature.

 Key Characteristics of a Good SRS

1. Completeness

A good SRS should include all necessary requirements of the system without leaving any
critical information missing. Every feature and function that the software must perform
should be clearly documented.

Example: If an online banking system needs user authentication, the SRS should specify
login requirements, password policies, and security protocols.

Why is it important?

 Prevents misinterpretation and confusion.

 Ensures that no feature is forgotten during development.

2. Unambiguity

Each requirement should be clear, precise, and unambiguous, meaning that different
people should interpret it the same way.

Example: Instead of saying "The system should be fast", an unambiguous requirement would
be:
"The system should process user login requests within 2 seconds under normal load
conditions."

Why is it important?
  Reduces misinterpretation by developers, testers, and clients.
 Prevents costly rework due to unclear requirements.

3. Consistency

All requirements in the SRS should be logically consistent with no contradictions.

Example:

 Incorrect: One requirement states that "The system shall allow only one active user session
per account," while another states that "The user can log in from multiple devices
simultaneously."
 Correct: The requirements should be aligned to avoid contradictions.

Why is it important?

 Ensures smooth development without conflicts.

 Avoids confusion and rework.

4. Verifiability

A good SRS should be verifiable, meaning that every requirement can be tested to check
whether it is met.

Example:

 Verifiable: "The system shall generate a confirmation email within 10 seconds of order
placement."
 Not verifiable: "The system should generate emails quickly."

Why is it important?

 Allows proper testing and validation.

 Ensures that each requirement can be objectively evaluated.

5. Modifiability

A good SRS should be easy to modify when requirements change. The document should be
well-structured so that updates can be made without affecting unrelated sections.

Example: If the client decides to change the login system from a password-based login to an
OTP-based login, the SRS should be structured in a way that this change can be made
easily without rewriting the entire document.

Why is it important?

 Reduces maintenance effort.

  Supports changes due to evolving business needs.

6. Traceability

Each requirement in the SRS should be traceable back to its origin (business needs, user
feedback, or regulatory standards). This helps in ensuring that all requirements are justified
and accounted for.

Example: If a requirement states "The system shall support PCI-DSS security compliance," it
should be linked to the legal requirement or business goal that necessitates it.

Why is it important?

 Helps in impact analysis when changes are required.

 Ensures that no requirement is added without a proper reason.

7. Feasibility

The requirements should be realistic and achievable given the available technology, time,
and budget.

Example:

 Feasible: "The system shall support up to 10,000 concurrent users on a cloud-based

infrastructure."
 Not feasible: "The system shall support an unlimited number of concurrent users on a single
server."

Why is it important?

 Prevents unrealistic expectations.

 Ensures that requirements align with technical capabilities.

8. Prioritization

A good SRS should classify requirements based on importance (e.g., must-have, should-
have, optional).

Example: In an e-commerce system,

 High priority: Users must be able to add items to their cart.

 Medium priority: Users should be able to add product reviews.
 Low priority: Users may be able to customize their profile page.
Why is it important?

 Helps in phased development and release planning.

 Focuses on critical features first.

9. Correctness

The requirements should accurately describe the actual needs of users and stakeholders.

Example: If a client wants multi-currency support in an application, the SRS should

correctly specify this instead of assuming a single currency model.

Why is it important?

 Ensures the developed system meets business goals.

 Avoids costly errors during development.

10. Security Considerations

A good SRS should define security requirements to protect user data and prevent
vulnerabilities.

Example: "The system shall encrypt all user passwords using SHA-256 encryption and
enforce two-factor authentication for admin access."

Why is it important?

 Ensures data protection and regulatory compliance.

 Prevents cyber threats and unauthorized access.

11. Performance Efficiency

The SRS should specify performance requirements, such as response time, load capacity,
and system availability.

Example: "The system should respond to user queries within 2 seconds for 95% of the
requests under normal load."

Why is it important?

 Helps in system optimization.

 Ensures smooth user experience.