Software Engineering (PCCO6010T)

Credits : 03
Examination Scheme
Term Test : 15 Marks
Teacher Assessment : 20 Marks
End Sem Exam : 65 Marks
Total Marks : 100 Marks

Prerequisite:
1. Concepts of Object Oriented Programming & Methodology.
2. Knowledge of developing applications with front end & back end connectivity.
• Course Objectives: To provide the knowledge of Standard Software Engineering discipline.
 Unit-IV
08 Hrs.

Project Scheduling and Control: Management Spectrum, 3Ps,

Process and Project Metrics: Metrics in the Process and Project Domains, Software Measurement, Metrics for
Software Quality

Software Project Estimation: LOC, FP, Empirical Estimation Models COCOMO I COCOMO II, Specialized
Estimation Techniques.

Software Project Scheduling: Work Breakdown Structure, Network Diagram, Gantt Chart.
 THE MANAGEMENT SPECTRUM
Effective software project management focuses on the four P’s: people, product,
process, and project.

• People – The success of a software project largely depends on the skills,

collaboration, and productivity of the team. This includes developers, testers,
project managers, stakeholders, and customers. Good leadership, clear roles, and
effective communication are essential.

• Product – Understanding the requirements, scope, and objectives of the

software being developed is crucial. This includes defining functional and non-
functional requirements, user needs, and constraints to ensure the product
meets expectations.
 THE MANAGEMENT SPECTRUM
• Process – The methodology or framework used for development, such as Agile,
Scrum, Waterfall, or DevOps, determines the efficiency of execution. A well-
defined process ensures consistency, quality, and timely delivery.

• software process provides the framework from which a comprehensive plan for
software development can be established. A small number of framework
activities are applicable to all software projects, regardless of their size or
complexity.

• Product – The planning, scheduling, resource allocation, risk management, and

cost control aspects are vital for the project's success. It involves tracking
progress, managing risks, and ensuring that deliverables meet the set timeline
and budget.
 PEOPLE
The Software Team
• Mantei suggests three generic team organizations:
 Democratic decentralized (DD)
• This software engineering team has no permanent leader. Rather, "task
coordinators are appointed for short durations and then replaced by others who
may coordinate different tasks."
• Decisions on problems and approach are made by group agreement.
Communication among team members is horizontal.
 Controlled decentralized (CD)
• This software engineering team has a defined leader who coordinates specific
tasks and secondary leaders that have responsibility for subtasks.
• Problem solving remains a group activity, but implementation of solutions is
partitioned among subgroups by the team leader.
• Communication among subgroups and individuals is horizontal. Vertical
communication along the control hierarchy also occurs.
 Controlled Centralized (CC)
• Top-level problem solving and internal team coordination are managed by a team
leader.
• Communication between the leader and team members is vertical.
-
-Mantei describes seven project factors that should be considered when planning
the structure of software engineering teams:
• The difficulty of the problem to be solved.
• The size of the resultant program(s) in lines of code or function points
• The time that the team will stay together (team lifetime).
• The degree to which the problem can be modularized.
• The required quality and reliability of the system to be built.
• The rigidity of the delivery date.
• The degree of sociability (communication) required for the project.
 The Stakeholders
-The software process is populated by stakeholders who can be categorized into
one of five constituencies:
1. Senior managers
- who define the business issues that often have a significant influence on the
project.
2. Project (technical) managers
- who must plan, motivate, organize, and control the practitioners who do software
work.
3. Practitioners
- who deliver the technical skills that are necessary to engineer a product or
application.
4. Customers
-who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.
5. End users
- who interact with the software once it is released for production use.
 Team Leaders
- MOI model of leadership:
1. Motivation
- The ability to encourage (by “push or pull”) technical people to produce to their
best ability.
2. Organization.
- The ability to mold existing processes (or invent new ones) that will enable the
initial concept to be translated into a final product.
3. Ideas or innovation.
- The ability to encourage people to create and feel creative even when they must
work within bounds established for a particular software product or application.
• Another view of the characteristics that define an effective project manager
emphasizes four key traits:
• Problem solving.
- An effective software project manager can diagnose the technical and
organizational issues that are most relevant, systematically structure a solution or
properly motivate other practitioners to develop the solution, apply lessons
learned from past projects to new situations, and
-remain flexible enough to change direction if initial attempts at problem
solution are fruitless.
• Managerial identity.
- A good project manager must take charge of the project. She must have
the confidence to assume control when necessary and the assurance to
allow good technical people to follow their instincts.
• Achievement.
-A competent manager must reward initiative and accomplishment to
optimize the productivity of a project team. She must demonstrate
through her own actions that controlled risk taking will not be
punished.
• Influence and team building.
- An effective project manager must be ableto “read” people; she must
be able to understand verbal and nonverbal signals and react to the
needs of the people sending these signals. The managermust remain
under control in high-stress situations.
 Process and Project Metrics
• Measurement is a management tool. If conducted properly, it provides a project manager with insight. And as
a result, it assists the project manager and the software team in making decisions that will lead to a successful
project.
METRICS IN THE PROCESS AND PROJECT DOMAINS
Process metrics are collected across all projects and over long periods of time. Their intent is to provide a set of process
indicators that lead to long-term software process improvement.
Project metrics enable a software project manager to
(1) assess the status of an ongoing project,
(2) track potential risks,
(3) uncover problem areas before they go “critical,”
(4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control quality of software work products.
Process Metrics and Software Process Improvement
- The only rational way to improve any process is to measure specific attributes of the process, develop a set of meaningful
metrics based on these attributes, and then use the metrics to provide indicators that will lead to a strategy for improvement
Software Measurement
• What is Measurement
– Comparison & calculations according to a well defined set of rules
– Definition:-The process by which numbers or symbols are assigned to attributes of
entities in the real world in a way as to describe them according to clearly defined
rules
• Entity
– An object (i.e. person or room) or an event (i.e. journey or the testing phase of software) in
the real world
• Attribute
– Feature or property of an entity (i.e. area or color of a room; elapsed time of testing phase)

• Attributes often defined by using numbers or symbols:

• Height: inches, feet, centimeters
• Price: dollars, pounds sterling, Euros
• Clothing: small, medium, large
• These numbers & symbols are abstractions used to reflect our perception of the
real world
Software Measurement
• Quantification in software engineering generally refers to the process of measuring or
assigning numerical values to various software attributes, such as performance,
complexity, reliability, and maintainability.
• It involves defining metrics and models to assess different aspects of software systems
objectively.
• Two Kinds of Quantification:
1. Measurement
 Direct quantification
2. Calculation
 Indirect quantification-we take measurements & combine them into
quantification item that reflect attribute.
Objectives of Software Measurement

 Clearly defined metric objectives:

• Ensures a well defined metric based on customer goals
• Eliminates misunderstandings
• Communicates need
• Provides requirements statement
 Measurement for understanding ,control & improvement
 What is happening during development?
 Make process & product more visible
 control & improve process & product
• SOFTWARE MEASUREMENT
• Direct measures of the software process include cost and effort applied. Direct measures of the product include lines of
code (LOC) produced, execution speed, memory size, and defects reported over some set period of time.
• Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many
other abilities.
• The cost and effort required to build software, the number of lines of code produced, and other direct measures are
relatively easy to collect, as long as specific conventions for measurement are established in advance. However, the
quality and functionality of software or its efficiency or maintainability are more difficult to assess and can be measured
only indirectly.
• SOFTWARE MEASUREMENT
Direct & indirect measurement:-
 Direct measurement of an attribute of entity involve no other attribute /entity
Ex:- 1. length of physical object is Direct measurement
2. density is indirect in term of mass & volume
density = mass/ volume
 Direct measurement in s/w engg:-
1. LOC
2. Duration of testing process
3. No. of defect discovered
4. Time a programmer spend on project
 Indirect measurement
1. Programmer productivity= LOC produced / person month of effort
2. Defect efficiency= no. of defect detected / total no of defect
• SOFTWARE MEASUREMENT
• Metrics for Software Quality
Modeling s/w quality
Quality is composite of many characteristics

Notion of quality is captured in a model that denotes composite characteristics & their relationship

Early models:-
Mc Call & Boehm describes quality using decomposition approach

In models, focus is given on final product & identify key attribute of quality from user’s perspective

Key attribute called as quality factors- high level external attributes like reliability, usability &
maintainability Include internal attribute –testability & efficiency
Quality factor are decomposed into lower-level attribute called quality-criteria
Ex:- reliability is composed of consistency ,accuracy, fault-tolerance etc
• Metrics for Software Quality
• Metrics for Software Quality
Boehm’s quality model
• Metrics for Software Quality
McCall’s Quality Model
Software Project Estimation
• Size-Oriented Metrics
Size-oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced.
A set of simple size-oriented metrics can be developed for each project:
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• $ per KLOC
• Pages of documentation per KLOC
In addition, other interesting metrics can be computed:
• Errors per person-month
• KLOC per person-month
• $ per page of documentation
Software Project Estimation
• Size-Oriented Metrics
Software Project Estimation
• Function Point Metrics
Function-oriented software metrics use a measure of the functionality delivered by the
application as a normalization value.
The most widely used function-oriented metric is the function point (FP).
Function Point (FP) is a widely used technique for measuring the size of software based on
its functionality, independent of programming language or technology. It helps estimate
project effort, cost, and complexity.
Computation of the function point is based on characteristics of the software’s information
domain and complexity. The function point, like the LOC measure, is controversial.
• Function Point Calculation
• FP=UFP×VAF
Where UFP is Unadjusted Function Points & VAF is Value Adjustment Factor
Software Project Estimation
• Function Point Calculation
1. Identify Function Types
Software Project Estimation
• Function Point Calculation
2. Assign Complexity Weights
Software Project Estimation
• Function Point Calculation
Software Project Estimation
• Function Point Calculation
Cost Estimation Model
• COCOMO (Constructive Cost Model) is a software cost estimation model
developed by Barry W. Boehm in 1981.

• It is used to estimate effort, cost, and time required to develop a software

project based on project size and complexity.

COCOMO Models: COCOMO is divided into three models based on the level of
detail and accuracy required:
1. Basic COCOMO Model – Less information in available
2. Intermediate COCOMO Model – Requirements are specified
3. Detailed COCOMO Model – Design is complete
Cost Estimation Model
Basic COCOMO Model
A simple estimation model that calculates effort based on the size of the software in Kilo
Lines of Code (KLOC).

Effort Equation:

where:
•E = Effort in Person-Months (PM)
•a, b = Constants based on project type
•KLOC = Estimated size of the project in thousands of lines of code
Cost Estimation Model
Project Categories:
• Organic: Data processing, d/b, transactions and data retrieval(e.g., Banking, accounting payroll
systems).

• Semi-Detached: Medium complexity, some new technology (e.g., database management systems).
It is in between organic and semi detached.

• Embedded: High complexity, strict constraints (e.g., real-time control systems-missile guidance
system or water temperature sensing system).
Cost Estimation Model
Intermediate COCOMO Model
This model extends the basic model by incorporating cost drivers (factors affecting effort) like
product complexity, experience level, and tools used.

Effort Equation:

where:
• EAF (Effort Adjustment Factor) is derived from 15 cost drivers affecting software
development (e.g., reliability, memory constraints, team capability).
Cost Estimation Model
Detailed COCOMO Model
The most advanced version, which divides the project into different phases (e.g., design,
coding, testing) and applies cost drivers to each phase for more accurate estimation.

Effort Equation (It provides phase-wise effort breakdown:):

where:
• where each E_i is calculated separately based on cost drivers for that phase.
Project Scheduling
• Software project scheduling means planning and distributing work over time by assigning
tasks to the right people.

• During early stages of project planning, a macroscopic schedule is developed.

• This type of schedule identifies all major process framework activities and the product
functions to which they are applied.

• As the project gets under way, each entry on the macroscopic schedule is refined into a
detailed schedule.

• Here, specific software actions and tasks (required to accomplish an activity) are identified
and scheduled.
Basic Principles
• Compartmentalization - Break the project into smaller, manageable tasks. Both the final product and the
development process are divided into clear parts to handle them more efficiently.

• Interdependency - Identify how tasks are related. Some tasks depend on the completion of others (must be
done in sequence), while some can happen at the same time (parallel tasks), and others are independent.

• Time Allocation - Assign time to each task. Set realistic start and end dates based on dependencies and
whether the team works full-time or part-time.

• Effort Validation - Make sure the workload matches the available resources. Avoid overloading the team by
checking that the number of assigned tasks doesn't exceed the team’s capacity.

• Defined Responsibilities - Assign each task to a specific team member to ensure accountability and clarity in
execution.

• Defined Outcomes - Set a clear expected result for each task, usually a work product (e.g., a document, code
module, or design).

• Defined Milestones - Link tasks to milestones—key points in the project where specific outputs are reviewed
and approved, marking progress.
Defining a Task Set for the Software Project
• A task set is a collection of software engineering work tasks, milestones, work products,
and quality assurance filters that must be accomplished to complete a particular project,

• The task set must provide enough discipline to achieve high software quality. But, at the
same time, it must not burden the project team with unnecessary work.

• In order to develop a project schedule, a task set must be distributed on the project time
line.

• The task set will vary depending upon the project type and the degree of rigor with which
the software team decides to do its work.
Defining a Task Network
• Individual tasks and subtasks have interdependencies based on their sequence.

• When more than one person is involved in a software engineering project, it is likely that
development activities and tasks will be performed in parallel.

• A task network, also called an activity network, is a graphic representation of the task flow
for a project.

• It is sometimes used as the mechanism through which task sequence and dependencies are
input to an automated project scheduling tool.

• In its simplest form, the task network depicts major software engineering actions. Figure
shows a schematic task network for a concept development project.
Defining a Task Network
• The task network shown in Figure is macroscopic. In a detailed task network, each action
shown in the figure would be expanded. For example, Task 1.1 would be expanded to show
all tasks detailed in the refinement of Actions 1.1 shown in next slide.
Refinement of Software Engineering Actions
Scheduling
• Scheduling of a software project does not differ greatly from scheduling of any multitask
engineering effort. Therefore, generalized project scheduling tools and techniques can be
applied with little modification for software projects.

• PERT and the CPM are two project scheduling methods that can be applied to software
development.

• Both techniques are driven by information already developed in earlier project planning
activities.

• Interdependencies among tasks may be defined using a task network. Tasks, sometimes
called the project work breakdown structure (WBS), are defined for the product as a whole
or for individual functions.
Scheduling
• Both PERT and CPM provide quantitative tools that allow you to

(1) Determine the critical path—the chain of tasks that determines the duration of the
project.

(2) Establish “most likely” time estimates for individual tasks by applying statistical models.

(3) Calculate “boundary times” that define a time “window” for a particular task.
Time-Line (Gantt) Chart
• A time-line chart can be developed for the entire project. Alternatively, separate charts can
be developed for each project function or for each individual working on the project.

• Figure illustrates the format of a time-line chart. It depicts a part of a software project
schedule that emphasizes the concept scoping task for a word-processing (WP) software
product.

• All project tasks are listed in the left hand column.

• The horizontal bars indicate the duration of each task. When multiple bars occur at the
same time on the calendar, task concurrency is implied.

• The diamonds indicate milestones.

Time-Line (Gantt) Chart
Project Table
Once the information necessary for the generation of a time-line chart has been input, the majority of software
project scheduling tools produce project tables—a tabular listing of all project tasks, their planned and actual start
and end dates, and a variety of related information. Used in conjunction with the time-line chart, project tables
enable you to track progress.
Project Management Information System (PMIS)
PMIS
• A PMIS is a set of tools and techniques used to gather, integrate, and disseminate outputs of project
management processes.
• Helps in planning, executing, and closing project activities.
• Includes both software and manual systems.
Importance of PMIS
• Centralizes project data and documentation
• Enhances team collaboration and communication
• Supports decision-making with real-time information
• Improves project tracking, scheduling, and reporting
Project Management Information System (PMIS)
Components of MIS
• Software Tools (e.g., MS Project, Primavera, Asana)
• Databases for storing project info
• Dashboards and Reports
• Communication Platforms
• Scheduling & Time Management Modules
Project Management Information System (PMIS)
Features and Functions of PMIS
• Project planning and scheduling
• Budgeting and cost management
• Resource allocation and tracking
• Risk management
• Document control
• Communication and collaboration tools
• Performance reporting
Project Management Information System (PMIS)
Benefits of using PMIS
• Increased project visibility and control
• Real-time monitoring of progress
• Better resource management
• Streamlined communication
• Higher productivity and reduced risks
• On-time and within-budget project delivery
Project Management Information System (PMIS)
Examples of PMIS Tools
• Microsoft Project
• Primavera P6
• Asana / Trello / Jira
• Monday.com
• Smartsheet / Wrike
Project Management Information System (PMIS)
Challenges in PMIS Implementation
• High initial setup cost
• Resistance to change from team members
• Integration issues with other systems
• Data security and access control concerns
• Need for proper training and support