1) Describe various activities during software project planning?

 The project planning is an important activity which is performed by the project managers, in
order to build a plan for creating a particular software it estimate the following entities :
o Resources required for the project under development.
o The cost of project.
o The schedule for completion of project.
 Software project planning is a crucial phase in the software development life cycle (SDLC).
 It involves defining the scope, objectives, resources, schedule, and procedures necessary to
successfully complete a software project. The key activities during software project planning
include:

1. Project Scope Definition

 Clearly define what the project is supposed to achieve.

 Identify deliverables, features, and functionalities.

 Set boundaries for what is included and excluded from the project.

2. Project Feasibility Analysis

 Assess technical, operational, and economic feasibility.

 Determine whether the project is worth undertaking.

 May include cost-benefit analysis and risk assessment.

3. Resource Planning

 Identify the team members required (developers, testers, designers, etc.).

 Plan for hardware, software, tools, and other infrastructure.

 Allocate time and budget for each resource.

4. Project Scheduling

 Break down the project into smaller tasks (Work Breakdown Structure).

 Estimate the time required for each task.

 Create a project timeline using tools like Gantt charts or PERT charts.

5. Risk Management Planning

  Identify potential project risks.

 Assess their likelihood and impact.

 Develop mitigation and contingency plans.

6. Cost Estimation and Budgeting

 Estimate the overall cost of the project, including labor, tools, and infrastructure.

 Create a detailed budget and define how the funds will be allocated.

7. Quality Assurance Planning

 Define quality standards and procedures.

 Plan for code reviews, testing phases, and validation activities.

8. Communication Planning

 Define how and when information will be shared among stakeholders.

 Plan meetings, status reports, and documentation.

9. Configuration Management Planning

 Plan for version control and change management.

 Define how software changes and updates will be tracked and managed.

10. Staffing Plan

 Define roles and responsibilities.

 Identify hiring needs or training for current staff.

 Software scope:

Software scope describes what the project is supposed to achieve, it defines what the software
will do and what it will not do.

In start of the development process it is always good and necessary to define the scope of the
project.

It includes:
  Functions and Features:
Specifies what the system will do (e.g., login, data processing, reporting).

 Data Requirements:
Defines the type of data to be input, processed, stored, and output by the system.

 Content Presented to the User:

Describes the interface elements, layout, and information made available to users (e.g.,
dashboards, menus, notifications).

 Performance Requirements:
Defines acceptable response times, throughput, and efficiency.

 Scalability:
Specifies how well the software can handle increased loads (more users, more data) in
the future.

 Constraints:
Identifies limitations such as hardware, software platforms, legal regulations, and
budget.

Software feasibility is the measure of how successfully a software project can be developed,
implemented, and maintained within given constraints (budget, time, technology, and
organizational goals).

After developing the scope of the project its feasibility must be ensured.

1. Technical Feasibility: This checks whether the required technology, tools, and expertise are
available to develop the software. It answers the question: Can we build the system with the
current technical resources?

2. Operational Feasibility: Evaluates whether the project can be integrated into the current
operations and whether it will be accepted by users and stakeholders.

3. Finance Feasibility: Evaluates if the project can be built under the defined budget

4. Schedule Feasibility: Assesses whether the project can be completed within the desired
timeframe.
3) What are the categories of software engineering resources?

In software engineering, resources refer to all the elements needed to successfully complete a
software project. These resources are crucial for planning, development, testing, and
maintenance. They are broadly classified into the following categories:

1. Human Resources :
 They include all the technical and non technical individuals.
 Usually there is a hierarchy in human resources.
 For smaller projects, human resource may be very limited but this might get
complicated with larger projects

2. Reusable Resources :

These resources can be used across multiple software project to save time, reduce costs and
improve quality.

 There are four reusable categories:

a) = OTS Components [ 3rd party components]
b) = Full Experience Components
c) = Partial Components
d) = New Components

3. Environment Resources : These include hardware and software

a) Software Resources:

These are the software programs and platforms used to build and manage the project:

 Programming tools (e.g., IDEs like Eclipse, Visual Studio)

 Project management tools (e.g., Jira, Trello)

b) Hardware Resources

These include the physical equipment required for development and deployment:

 Computers/Servers – For coding, building, and testing

 Networking equipment – For communication and collaboration

 Storage devices – For code, databases, and backups

The hardware must be capable of supporting the software and the tools used in the project.
q) What is estimation with Use cases? Explain Estimation using use case points with the help
of an example.

Use Case-Based Estimation is a technique used in software engineering to estimate the effort,
time, and cost required to develop a software system by analyzing its use cases.

Use cases represent how users interact with the system, and they help in understanding the
system's functional requirements.

Key Components:

1. Use Case Classification

o Based on complexity of the module:

 Simple (5 points), Average (10), Complex (15)

2. Actor Classification

o Based on interaction type of an individual:

 Simple (1 point), Average (2), Complex (3)

For ex: Bank App

1) Identify test cases

 user login
 view account balance
 transfer funds
 pay bills
 generate account statement

2) Categorize test cases:

 user login : simple

 view account balance: simple
 transfer funds: complex
 pay bills : avg
 generate account statement : avg

3) Assign weights for each category:

 simple : 5 points
 avg : 10 points
  complex : 15 points

4) Calculate total efforts

total points : 45 points

5) Estimate effort per point

avg effort per points = 8 hours

6) Calculate overall effort

45 * 8 = 360 hours

7) Total including overhead

360 + 50 = 410 hours

Project Decomposition in Software Engineering

Project decomposition is the process of breaking down a large software project into smaller,
manageable parts, to simplify development, estimation, and planning. It helps teams
understand the project better, assign tasks efficiently, and reduce complexity.

A project is typically divided into components like a front-end, back-end, and the modules, and
finally into individual tasks.

Breaking the project into components improves clarity, assigns clear responsibilities and
enables parallel development process and helps in better time and resource estimation.

 Types of Project Decomposition

1. Problem Decomposition (also called Functional Decomposition)

 Focuses on what the system must do.

 The project is broken down based on functional requirements or user-visible features.

 Each function is divided into sub-functions or modules.

Example:
In a Banking System, functions like:

 Account Management
  Fund Transfer

 Bill Payments can be further decomposed into sub-functions like "Add Account",
"Transfer to Savings", etc.

2. Process Decomposition

 Focuses on how the system will be built.

 The project is broken into development phases or activities based on the Software
Development Life Cycle (SDLC).

Example:
Decomposing the project into:

 Requirement Analysis

 Design

 Coding

 Testing

 Deployment

Each phase can have its own tasks and timelines.

Explain LOC (Lines of Code) in software estimation.

 Lines of code (LOC) is one of the size estimation technique that measures the size of a
software system by counting the number of lines in the source code of the program.
 It is used to estimate the effort, time, and cost of a software project.
 This is one of the simplest and easiest methods for software project estimation that predicts
time needed to complete a project by estimating the lines of code.
 What all is included in LOC?
a) Declarations
b) conditional statements
c) looping statements
d) Braces, etc.
 What is not included in LOC?
a) Comments
b) Blank lines
Advantages:

 Simple and easy to understand

 Good for small and well-understood projects

 Can be used when source code is available

Disadvantages:

 Language-dependent (same logic takes more LOC in C than in Python)

 Not suitable or large projects

 Ignores non-coding effort (e.g., design, testing, documentation)

FP Based Estimation:

Function Point (FP) is a software size estimation technique used to measure the functionality
delivered to the user.

It is independent of the programming language and focuses on what the software does, rather
than how it's built.

Function Point is a widely used estimation method that measures software size based on
functionality, not code.

Key Components of Function Point Analysis (FPA):

1. External Inputs (EI):

o Data received from the user to the system

o Example: login form, transaction input

o Weight: Simple (3), Average (4), Complex (6)

2. External Outputs (EO):

o Data sent from system to user (e.g., reports)

o Weight: Simple (4), Average (5), Complex (7)

3. External Inquiries (EQ):

 o User requests that retrieve data without updating

o Example: search or lookup

o Weight: Simple (3), Average (4), Complex (6)

4. Internal Logical Files (ILF):

o Data maintained within the system

o Example: user database

o Weight: Simple (7), Average (10), Complex (15)

5. External Interface Files (EIF):

o Data used from other systems

o Example: imported account data

o Weight: Simple (5), Average (7), Complex (10)

🔹 Steps to Calculate Function Points:

1. Assign weights to each component based on its complexity.

2. Calculate the Unadjusted Function Point (UFP) by summing all weighted values.

3. Determine the Value Adjustment Factor (VAF) using 14 general system characteristics
(like security, performance, etc.).

VAF = 0.65 + (0.01 × Sum of characteristics)

4. Calculate Final FP:

FP = UFP × VAF

Example of Function Point Estimation: Library Management System

Component Type Count Complexity Weight (per item) Total Points

External Inputs (EI) 3 Simple 3 3×3=9

External Outputs (EO) 2 Average 5 2 × 5 = 10

External Inquiries (EQ) 2 Simple 3 2×3=6

Component Type Count Complexity Weight (per item) Total Points

Internal Logical Files (ILF) 2 Average 10 2 × 10 = 20

External Interface Files (EIF) 1 Simple 5 1×5=5

Advantages:

 Technology-independent

 Useful in early project stages

Disadvantages:

 Requires experience and judgment to classify components

 Slightly time-consuming compared to LOC

Process-Based Estimation
 Process based estimation is a method used to estimate the effort cost and duration of a
particular software project by breaking down the project into a series of task or process.
 This is the most commonly used estimation technique for estimating the project based on
the processes used in the project.
 Process-Based Estimation is a technique that estimates effort, cost, and time by breaking
down the software project into its processes or development activities.
 It is based on the Software Development Life Cycle (SDLC)
 The total effort is calculated by estimating the effort required for each phase of the process,
such as:
 Requirements analysis
 System design
 Implementation
 Testing
 Deployment
 Maintenance

Example: For a e-commerce website

Phase Estimated Effort (person-days)

Requirements 10
Design 15
Coding 25
Testing 10
Deployment 5

 Total Effort = 65 person-days

 If each developer works 8 hours/day, and the team has 2 developers, the project can be completed in
approximately:

65/2 = 32.5 working days

Empirical Estimation Models

Empirical estimation models are based on observed data from past projects and use statistical
analysis or mathematical formulas to estimate the cost, effort, and schedule of a software
project.

These models rely on historical data and project characteristics to make predictions.

Constructive Cost Model (COCOMO)

COCOMO (Constructive Cost Model) is one of the most well-known empirical models, proposed
by Barry Boehm in 1981. It estimates the effort, cost, and schedule required to develop
software based on the size of the software (measured in KLOC – thousands of lines of code).

Types of COCOMO Models:

1. Basic COCOMO: Uses only size (KLOC) to estimate effort.

2. Intermediate COCOMO: Includes size and a set of 15 cost drivers.
3. Detailed COCOMO: Adds phase-wise estimation and cost drivers.

 COCOMO II is an updated version of the original COCOMO model. It helps estimate the cost,
effort, and time needed to develop modern software projects, especially large and complex
ones.

Example:

Let’s say you're building a mobile app with:

 Estimated size = 50,000 lines of code (50 KLOC)

 Scale factor E = 1.1 (moderate complexity)
 Cost driver product = 1.2 (average team/tools)

Effort = 2.94 × (50) 1.1 × 1.2 ≈ 2.94 × 68.4 × 1.2 ≈ 241.3 person-months

So, you would need 241 person-months to finish the project.

 Basic principles software project scheduling:

 Software project scheduling is a mechanism to communicate what tasks need to be get done
and which organizational resources will be allocated to completely those task in what the
time frame.

 Project scheduling provides details like start and end of the project, milestones, and task for
the project.

 Project scheduling specifies the resources like people, equipment etc. required to complete
the project and dependencies of tasks of the project on each other.

 Basic principles of software project scheduling are:

1. Compartmentalization: The project must be compartmentalized (divided) into a number of

manageable activities and tasks. To accomplish compartmentalization, both the product and
the process are decomposed.

2. Interdependency: The interdependency of each compartmentalized activity or task must be

determined. Some tasks must occur in sequence while others can occur in parallel. Some
activities cannot commence until the work product produced by another is available. Other
activities can occur independently.

3. Time allocation: Each task to be scheduled must be allocated some number of work units
(e.g., person-days of effort). In addition, each task must be assigned a start date and a
completion date that are a function of the interdependencies and whether work will be
conducted on a fulltime or part-time basis.

4. Effort validation: Every project has a defined number of staff members. As time allocation
occurs, the project manager must ensure that no more than the allocated number of people
has been scheduled at any given time.

5. Defined responsibilities: Every task that is scheduled should be assigned to a specific team
member.

6. Defined outcomes: Every task that is scheduled should have a defined outcome.

7. Defined milestones: Every task or group of tasks should be associated with a project
milestone. Program evaluation and review technique (PERT) and critical path method (CPM)
are two project scheduling Methods that can be applied to software development.