SEMESTER - V

Course Code:DSE-503: Computer Science Paper - XI

Course Title: Software Engineering

Unit – II : Software Project Planning

Let’s Start
Software Project Planning
֍ Software Project Planning
Size Estimation, Cost Estimation
֍ Models -
❑ COCOMO Model
❑ Putnam Resource Allocation Model
֍ Risk Identification and Projection: RMMM

֍ Project scheduling and Tracking

֍ Software Design Process, Design Principles

֍ Design Concepts:
Effective Modular Design, Design Heuristics, Design Documentation (SRS)
֍ Design Methods:
Data Design, Architectural Design, Interface Design, Procedural Design.
Software Project Planning

After feasibility study phase if a project is found to be feasible then the project manager begins project planning.

A Software Project is the complete methodology of programming advancement from requirement gathering to
testing and support, completed by the execution procedures, in a specified period to achieve intended software
product.

Need of Software Project Management

Software development is a sort of all new streams in world business, and there's next to no involvement in
structure programming items. Most programming items are customized to accommodate customer's necessities.

The most significant is that the underlying technology changes and advances so generally and rapidly that
experience of one element may not be connected to the other one.

All such business and ecological imperatives bring risk in software development; hence, it is fundamental to
manage software projects efficiently.
Software Project Manager
Software manager is responsible for planning and scheduling project development. They manage the work to
ensure that it is completed to the required standard.
They monitor the progress to check that the event is on time and within budget. The project planning must
incorporate the major issues like size & cost estimation scheduling, project monitoring, personnel selection
evaluation & risk management.
Project manager completes this activity before development work starts.
There are various activities involved in project planning as listed below:
1. Project estimation
When a project is finalized then several estimations need to be made.
A proper cost estimation is required that would be required for project.
Time estimation is needed that would propose the time in which the project would be in deliverable position.
Effort estimation is needed to finalize the resource available and required for the project.

2. Project Schedules
Schedules for manpower and several other resources has to be prepared that would be needed as the project
progress.
3. Project staffing
Staff needs to be organized and planned. Analysis has to be done to find out if the existing staff is sufficient for
the project or new recruitment is required.

4. Project risks and management

Possible risks to the project needs to identified and its solution needs to found to let project progress smoothly.

5. Project miscellaneous management

Quality of the product, configuration management plan, etc are some miscellaneous task that needs to be
planned accordingly.
Software project management

Software project management in software engineering is an important factor driving the project from product
conception till completion.

A software project, however, big or small employs project manager.

The important duty for a software project management is:
• To write project proposal,
• Prepare project cost estimation, schedule and staffing
• Help and keep the group of software developers motivated
• Building up teams morale
• Steer project towards successful completion

An effective software project management requires proper project planning, project monitoring and project
control.
Software Cost Estimation
For any new software project, it is necessary to know how much it will cost to develop and how much
development time will it take. These estimates are needed before development is initiated, but how is this done?
Several estimation procedures have been developed and are having the following attributes in common.
• Project scope must be established in advanced.
• Software metrics are used as a support from which evaluation is made.
• The project is broken into small PCs which are estimated individually.
• To achieve true cost & schedule estimate, several option arise.
• Delay estimation
• Used symbol decomposition techniques to generate project cost and schedule estimates.
• Acquire one or more automated estimation tools.
Uses of Cost Estimation
During the planning stage, one needs to choose how many engineers are required for the project and to develop a
schedule.
In monitoring the project's progress, one needs to access whether the project is progressing according to the
procedure and takes corrective action, if necessary.
Project Size Estimation
It’s important to understand that project size estimation is the most fundamental parameter. If this is estimated
accurately then all other parameters like effort, duration, cost, etc can be determined easily.
At present two techniques that are used to estimate project size are: Lines of code (LOC) and Function point
1. Lines of code
Lines of code or LOC is the most popular and used metrics to estimate size.
LOC determination is simple as well. LOC measures the project size in terms of number of lines of statements or
instructions written in the source code.
In LOC count, comments and headers are ignored.

Estimating LOC by analysing the problem specification is difficult. Estimation of accurate LOC is only possible
once the complete code has been developed. As project planning needs to be done before the development work
begins so this metrics is of little use for project managers.

LOC is the numerical measurement of problem size. This metrics will vary to a large extent from programmer to
programmer. An experienced professional may write same logic in less number of lines than a novice
programmer.
2. Function point metrics
Function point metrics overcomes many of the shortcomings of LOC.
Function point metrics proposes that size of the software project is directly dependent on various
functionalities it supports. More the features supported the more would be the size.

This technique helps determine size of the project directly from the problem specification so is really
helpful to project managers during project planning while determining size.
COCOMO Model

Barry William Boehm proposed COCOMO Model (COnstructive COst Estimation MOdel) in 1981.
COCOMO Model is one of the most generally used software estimation models in the world.
COCOMO predicts the efforts and schedule of a software product based on the size of the software.
The necessary steps in this model are:
1. Get an initial estimate of the development effort from evaluation of thousands of delivered lines of source code
(KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e., multiply the
values in step1 and step2.
The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single
variable models, using KDLOC as the measure of the size.
To determine the initial effort Ei in person-months the equation used is of the type is shown below
Ei=a * (KDLOC)b
The value of the constant/coeficient a and b are depends on the project type.

In COCOMO, projects are categorized into three types: Organic, Semidetached and Embedded
1.Organic Mode / Category:
A development project can be treated of the organic type, if the project deals with developing a well-
understood application program, the size of the development team is reasonably small, and the team
members are experienced in developing similar methods of projects.
For Examples: business systems, simple inventory management systems, and data processing systems.

2. Semidetached Mode / Category:

A development project can be treated with semidetached type if the development consists of a mixture of
experienced and inexperienced staff. Team members may have finite experience in related systems but may
be unfamiliar with some aspects of the order being developed.
For Example developing a new operating system (OS), a Database Management System (DBMS), and
complex inventory management system.

3. Embedded Mode / Category:

A development project is treated to be of an embedded type, if the software being developed is strongly
coupled to complex hardware, or if the stringent regulations on the operational method exist.
For Example: ATM, Air Traffic control.
For three product categories, Boehm provides a different set of expression to predict effort (in a unit of person
month) and development time from the size of estimation in KLOC (Kilo Line of code) efforts estimation takes into
account the productivity loss due to holidays, weekly off, coffee breaks, etc.
According to Boehm, software cost estimation should be done through three stages:
1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters.
The following expressions give the basic COCOMO estimation model:
Effort = a * (KLOC) b PM [person month] Average Staff Size (SS) or Person required = Effort / Tdev persons
Tdev = c * (efforts) d Months Productivity = KLOC / Effort KLOC / PM
Where
KLOC is the estimated size of the software product indicate in Kilo[thousands] Lines of Code,
a, b, c, d are constants/ coefficients for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
 The constant / coefficient values a, b, c and d for the Basic Model for the different categories/mode of system:

Software Projects A B C D

Organic Mode 2.4 1.05 2.5 0.38

Semi Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Estimation of development effort Estimation of development time

For the three classes of software products, the For the three classes of software products, the
formulas for estimating the effort based on the code formulas for estimating the development time based
size are shown below: on the effort are given below:
Organic: Effort = A * (KLOC) B PM Organic: Tdev = C * (Effort) D Months
B
Semi-detached: Effort = A * (KLOC) PM Semi-detached: Tdev = C * (Effort) D Months
B
Embedded: Effort = A * (KLOC) PM Embedded: Tdev = C * (Effort) D Month
 Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each of
the three model i.e., organic, semi-detached & embedded.
Solution:
The basic COCOMO equation takes the form:
Effort = a *(KLOC) b PM Tdev = c *(efforts)d Months
Estimated Size of project = 400 KLOC

Software Projects A B C D

Organic Mode 2.4 1.05 2.5 0.38

Semi Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

(i)Organic Mode (ii)Semidetached Mode (iii) Embedded Mode

E = 2.4 * (400) 1.05 E = 3.0 * (400) 1.12 E = 3.6 * (400) 1.20
= 2.4 * 539.71 = 1295.31 PM = 3.0 * 820.93 = 2462.79 PM = 3.6 * 1325.78 = 4772.81 PM
Tdev = 2.5 * (1295.31) 0.38 Tdev = 2.5 * (2462.79) 0.35 Tdev = 2.5 * (4772.8)0.32
= 2.5 * 15.23 = 38.07 PM = 2.5 * 15.38 = 38.45 PM = 2.5 * 15.03 = 37.59 PM
Example2: Suppose a project was estimated to be 525 KLOC. Calculate the effort and development time for each of
the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 525 KLOC

(i)Organic Mode
E = 2.4 * (525) 1.05 = 1723.36 PM
D = 2.5 * (1723.36) 0.38 = 42.43 PM

(ii)Semidetached Mode
E = 3.0 * (525) 1.12 = 3339.63 PM
D = 2.5 * (3339.63) 0.35 = 42.77 PM

(iii) Embedded Mode

E = 3.6 * (525) 1.20 = 6614.44 PM
D = 2.5 * (6614.44) 0.32 = 41.73 PM
Example3: A project size of 200 KLOC is to be developed. Software development team has average experience on
similar type of projects. The project schedule is not very tight. Calculate the Effort, development time, average staff size,
and productivity of the project.
Solution:
The semidetached mode is the most appropriate mode, keeping in view the size, schedule and experience of
development time.
Hence E = 3.0(200) 1.12 = 3.0 * 377.70 = 1133.12 PM
Tdev = 2.5(1133.12) 0.35 = 2.5 * 11.72 = 29.30 PM

Average Staff Size [SS] = E / Tdev persons

= 1133.12 / 29.3
= 38.67 persons
Productivity = KLOC / E

= 200 / 1133.12

= 0.1765 KLOC / PM
Example4: A project size of 320 KLOC is to be developed. Software development team has average experience on
similar type of projects. The project schedule is not very tight. Calculate the Effort, development time, average staff
size, and productivity of the project.
Solution:
The semidetached mode is the most appropriate mode, keeping in view the size, schedule and experience of
development time.
Hence E = 3.0 * (320) 1.12 = 3.0 * 639.39 = 1918.17 PM
Tdev = 2.5 * (1918.17) 0.35 = 2.5 * 14.09 = 35.23 PM

Average Staff Size [SS] = E / Tdev persons

= 1918.17 / 35.23
= 54.44 persons
Productivity = KLOC / E

= 320 / 1918.17

= 0.1668 KLOC / PM
2. Intermediate Model:
The basic COCOMO model considers that the effort is only a function of the number of lines of code and some
constants calculated according to the various software systems.
The intermediate COCOMO model recognizes these facts and refines the initial estimates obtained through the basic
COCOMO model by using a set of 15 cost drivers based on various attributes of software engineering.
Classification of Cost Drivers and their attributes:
Product attributes - Hardware attributes -

o Required software reliability extent o Run-time performance constraints

o Size of the application database o Memory constraints
o The complexity of the product o The volatility of the virtual machine environment
o Required turnabout time
Personnel attributes -
o Analyst capability Project attributes -
o Software engineering capability o Use of software tools
o Applications experience o Application of software engineering methods
o Virtual machine experience o Required development schedule
o Programming language experience
3. Detailed COCOMO Model:
Detailed COCOMO incorporates all qualities of the standard version with an assessment of the cost driver’s effect
on each method of the software engineering process.
The detailed model uses various effort multipliers for each cost driver property. In detailed COCOMO, the whole
software is differentiated into multiple modules, and then we apply COCOMO in various modules to estimate
effort and then sum the effort.
The Six phases of detailed COCOMO are:
• Planning and requirements
• System structure
• Complete structure
• Module code and test
• Integration and test
• Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost drivers are given according to every
phase of the software lifecycle.
The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that the
development time is a sub linear function of the size of the product, i.e. when the size of the product increases by
two times, the time to develop the product does not double but rises moderately. This can be explained by the fact that for
larger products, a larger number of activities which can be carried out concurrently can be identified.

The parallel activities can be carried out simultaneously by

the engineers. This reduces the time to complete the project.
Further, from fig, it can be observed that the development time
is roughly the same for all three categories of products.
For example, a 60 KLOC program can be developed in
approximately 18 months, regardless of whether it is of
organic, semidetached, or embedded type.
From the effort estimation, the project cost can be obtained by
multiplying the required effort by the manpower cost per
month. But, implicit in this project cost computation is the
assumption that the entire project cost is incurred on account
of the manpower cost alone.
In addition to manpower cost, a project would incur costs
due to hardware and software required for the project and
the company overheads for administration, office space, etc.
Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for different
software sizes. Fig shows a plot of estimated effort versus product size.

From fig, we can observe that the effort is somewhat superliner in the size of the software product. Thus, the effort
required to develop a product increases very rapidly with project size.
Putnam Resource Allocation Model
The Lawrence Putnam model describes the time and effort requires finishing a software project of a specified size.
Putnam makes a use of a so-called The Norden/Rayleigh Curve to estimate project effort, schedule & defect rate as
shown in fig:

Putnam noticed that software staffing profiles followed the

well known Rayleigh distribution. Putnam used his observation
about productivity levels to derive the software equation:

L = Ck K 1/3 td4/3
The various terms of this expression are as follows:

K is the total effort expended (in PM) in product development,

and L is the product estimate in KLOC .
td correlate to the time of system and integration testing.
Therefore, td can be relatively considered as the time
required for developing the product.

Ck Is the state of technology constant and reflects

requirements that impede the development of the program.
Typical values of
• Ck = 2 for poor development environment
• Ck= 8 for good software development environment
• Ck = 11 for an excellent environment
(in addition to following software engineering principles, automated tools and techniques are used).
The exact value of Ck for a specific task can be computed from the historical data of the organization developing it.
Putnam proposed that optimal staff develop on a project should follow the Rayleigh curve. Only a small number of
engineers are required at the beginning of a plan to carry out planning and specification tasks. As the project
progresses and more detailed work are necessary, the number of engineers reaches a peak. After implementation and
unit testing, the number of project staff falls.
Effect of a Schedule change on Cost
Putnam derived the following expression:

L = Ck K 1/3 td4/3
• K is the total effort expended (in PM) in the product development
• L is the product size in KLOC
• td corresponds to the time of system and integration testing
• Ck Is the state of technology constant and reflects constraints that impede the progress of the program
Now by using the above expression, it is obtained that,

K = L3 / Ck3td4 OR K = C / td4
For the same product size, C =L3 / Ck3 is a constant.

(As project development effort is equally proportional to project development cost)

From the above expression, it can be easily observed that when the schedule of a project is compressed, the required
development effort as well as project development cost increases in proportion to the fourth power of the degree of
compression. It means that a relatively small compression in delivery schedule can result in a substantial penalty of
human effort as well as development cost.
For example, if the estimated development time is 1 year, then to develop the product in 6 months, the total effort
required to develop the product (and hence the project cost) increases 16 times.
"Risk" refers to a situation that could result in a loss the project's progress but has not yet occurred. Risk
management is the process of identifying risks and developing plans to mitigate their influence on the project. The
primary goal of risk management is to avert disasters or significant losses.
The Risk Mitigation, Monitoring, and Management (RMMM) plan is a document that outlines all risk analysis
activities. This document is sometimes included in the overall project plan by the project manager. Although a
precise RMMM strategy is not always established, each risk can be described using a risk information sheet.
Risk Management
A software project can be associated with a wide range of threats. It is necessary to classify risks into distinct classes
in order to be able to systematically identify the critical risks that may harm a software project. After that, the
project manager can determine whether risks from each category are crucial to the project.
These potential concerns could impact the project's cost, timeline, or technical success, as well as the performance of
our software product and project team morale. Risk management is the process of identifying, addressing, and
resolving problems before they harm the project.
The risks can be broadly categorised into three categories, as illustrated below:
• Project risks are those that have an impact on the project's schedule or resources.
• Product risks affect the quality or performance of the product being developed.
• Business risks are risks to the corporation developing or licensing the software.
This is not a unique classification. When an experienced programmer leaves a project, it poses a project risk since the
system's delivery may be delayed. The product may be at risk because the replacement may not be as experienced,
resulting in slip-ups and lost revenue.
Risk management is critical because of the inherent risks that most software projects confront. The figure below
depicts the risk management process.

Risk Identification Risk Analysis Risk Planning Risk Monitoring

List of Potential Risk Avoidance and

Prioritized Risk List Risk Assessment
Risks Contingency Plan

Like all other aspects of project planning, the risk management process is an iterative process that lasts throughout
the project. The outcomes of the risk management process should be documented in a risk management plan.

A risk management plan should include a discussion of the project's hazards, an analysis of those risks, and actions to
mitigate those risks. It may also include some risk management outcomes.
Risk Management Activities
Risk management is assessing the unfavorable events that could occur, their chance of occurring, and the losses that
would result if they did. While considering this, solutions can be designed to lessen the possibility of the content
being a risk or having an impact. As a result, risk management is centered on risk assessment and control.
Risk Assessment
Risk assessment aims to categorize risks according to their chance to cause loss. First, each risk should be rated
via the two methods:
The probability of risk coming true (denoted by r).

The interpretation of the issues relates to that risk (denoted by s).

The priority of each risk can be evaluated using these two methods:
p=r*s
where, p represents the priority with which the risk must be controlled
r represents the probability of the risk becoming true
s is the severity of the loss produced by the risk becoming true.

After all identified risks have been established, the most likely and destructive risks can be addressed first, and
more comprehensive risk reduction strategies for these risks can be devised.
a.) Risk Identification
The project organizer must identify the project's risk as early as feasible to minimize the risk's impact via
appropriate risk management planning.
A project can be favorable to a wide range of risks. To detect a significant risk that could have an impact on a project.
It is essential to categorize the risks into various risk classes.
Several types of risks can impact a software product; a few of them are defined below:

• Technology Risks: Risks arising from the software or hardware technologies utilized to construct the system.
• People Risks: Risks associated with an individual of the development team.
• Organizational Risks: Risks arise due to the organization in which the software is being produced.

• Tools Risks: Risks arising from the software tools and other support software used to build the system.

• Requirement Risks: Risks associated with changes in client requirements and the process of managing those changes.

• Estimation Risks: Risks arising from management estimates of the resources necessary to create the system.
 b.) Risk Analysis
During the risk analysis process, you must analyse each identified risk and form opinions about its likelihood and
severity. There is no easy method to accomplish this. You must rely on your perception and experience with past
initiatives and the issues throughout them.
It is impossible to make an exact numerical estimate of the risk's probability and severity. Instead, you should
distribute the risk to one of the following groups:
• The risk could be classified as extremely low (0-10%), low (10-25%), moderate (25-50%), high (50-75%), or
very high (+75%) in probability.
• The risk's impact might be classified as catastrophic (threatening the plan's survival), severe (causing vital
delays), bearable (delays are within allowable contingencies), or trivial.
Risk Control
It's the process of managing risks in order to accomplish desired results. After all, a plan's identified risks must be
determined; the project must be designed to include the most dangerous and probable risks. Different risks
necessitate different ways of containment. Most risks necessitate the project manager's inventiveness in dealing
with them.
a.) Risk Planning
The risk planning technique considers all of the significant risks that have been identified and develop strategies
to mitigate them.
You must consider the behaviour you might use to minimize the disruption to the plan if the issue stated in the
risk arises for each of the risks. You should also consider the data you'll need to accumulate while observing the
procedure so that problems can be predicted.
Again, there is no simple procedure to follow for contingency planning. It is based on the project manager's
expertise.
b.) Risk Monitoring
Risk monitoring ensures that your assumptions about the product, process, and business risks remain unchanged.

Risk Mitigation, Monitoring and Management (RMMM) Plan

In most cases, a risk management approach can be found in the software project plan. This can be broken down
into three sections: risk mitigation, monitoring, and management (RMMM).
All work is done as part of the risk analysis in this strategy. The project manager typically uses this RMMM plan as
part of the overall project plan.
Some development teams use a Risk Information Sheet (RIS) to document risk. For faster information handling,
such as creation, priority sorting, searching, and other analyses, this RIS is controlled by a database system.
Risk mitigation and monitoring will begin after the RMMM is documented and the project is launched.
Risk Mitigation: Risk Mitigation is a technique for avoiding risks (Risk Avoidance).
The following are steps to take to reduce the risks:
• Identifying the risk.
• Getting rid of the causes that lead to the production of risk.
• Controlling the relevant documents regularly.
• Conducting timely reviews to accelerate the process.
Risk Monitoring Risk monitoring is an activity used to track a project's progress.
The following are the critical goals of the task.
• To see if the risks that were anticipated actually happen.
• To verify that the risk aversion steps defined for risk are adequately implemented.
• To gather information for future risk assessments.
• To determine which risks generate which problems throughout the project.
Risk Management and Planning
Risk management and planning are based on the assumption that the mitigation effort failed and the risk has become a
reality. When a risk becomes a reality and produces serious problems, the project manager is in charge of this
responsibility.
It is easier to manage risks if the project manager successfully implements project mitigation to eliminate risks. This
demonstrates how a manager will respond to each risk. The risk register is the key objective of the risk management
plan. This risk register identifies and prioritizes potential dangers to a software project.
Project Scheduling:
Project Scheduling in a project refers to roadmap of all activities to be done with specified order and within time slot
allotted to each activity. Project managers tend to define various tasks, and project milestones and they arrange them
keeping various factors in mind.

Project schedule simply means a mechanism that is used to communicate and know about that tasks are needed and
has to be done or performed and which organizational resources will be given or allocated to these tasks and in what
time duration or time frame work is needed to be performed.
Effective project scheduling leads to success of project, reduced cost, and increased customer satisfaction.
Scheduling in project management means to list out activities, deliverables, and milestones within a project that are
delivered.
For scheduling a project, it is necessary to -
• Break down the project tasks into smaller, manageable form
• Find out various tasks and correlate them
• Estimate time frame required for each task
• Divide time into work-units
• Assign adequate number of work-units for each task
• Calculate total time required for the project from start to finish
Software Project Scheduling Principles
• Compartmentalization - The product and process must be break down into a manageable number of activities
and tasks
• Interdependency - tasks that can be completed in parallel must be separated from those that must
completed serially

• Time allocation - every task has start and completion dates that take the task interdependencies into
account

• Effort validation - project manager must ensure that on any given day there are enough staff members
assigned to completed the tasks within the time estimated in the project plan

• Defined Responsibilities - every scheduled task needs to be assigned to a specific team member

• Defined outcomes - every task in the schedule needs to have a defined outcome (usually a work product or
deliverable)

• Defined milestones - a milestone is accomplished when one or more work products from an engineering task
have passed quality review
 Assign People to Create Activity
Identifies Identify Possible Estimate
conduct Network and Bar
Activities Dependencies Resource
Activities Charts

Project Scheduling Process

The manager needs to estimate time and resources of project while scheduling project. All activities in project must be
arranged in a coherent sequence that means activities should be arranged in a logical and well-organized manner for
easy to understand.
Initial estimates of project can be made optimistically which means estimates can be made when all favourable things
will happen and no threats or problems take place.
The total work is separated or divided into various small activities or tasks during project schedule. Then, Project
manager will decide time required for each activity or task to get completed.
Even some activities are conducted and performed in parallel for efficient performance. The project manager should
be aware of fact that each stage of project is not problem-free.
Problems arise during Project Development Stage :
• People may leave or remain absent during particular stage of development.
• Hardware may get failed while performing.
• Software resource that is required may not be available at present, etc.
The project schedule is represented as set of chart in which work-breakdown structure and dependencies within
various activities are represented. To accomplish and complete project within a given schedule, required resources
must be available when they are needed. Therefore, resource estimation should be done before starting development.
Resources required for Development of Project :
Human effort Specialized hardware Software technology
Sufficient disk space on server Travel allowance required by project staff, etc.
Project Effort Distribution Generally accepted guidelines are:
The 40-20-40 rule: • 02-03 % planning
• 40% front-end analysis and design • 10-25 % requirements analysis
• 20% coding • 20-25 % design
• 40% back-end testing • 15-20 % coding
• 30-40 % testing and debugging
Advantages of Project Scheduling :
There are several advantages provided by project schedule in our project management:
• It simply ensures that everyone remains on same page as far as tasks get completed, dependencies, and deadlines.
• It helps in identifying issues early and concerns such as lack or unavailability of resources.
• It also helps to identify relationships and to monitor process.
• It provides effective budget management and risk mitigation.
Project Scheduling Techniques
1. Project Evaluation and Review Technique (PERT)
Project Evaluation and Review Technique (PERT) is a procedure through which activities of a project are represented
in its appropriate sequence and timing. It is a scheduling technique used to schedule, organize and integrate tasks
within a project.
PERT is basically a mechanism for management planning and control which provides blueprint for a particular
project. All of the primary elements or events of a project have been finally identified by the PERT.
In this technique, a PERT Chart is made which represent a schedule for all the specified tasks in the project. The
reporting levels of the tasks or events in the PERT Charts is somewhat same as defined in the Work Breakdown
Structure (WBS).
Characteristics of PERT:
• It serves as a base for obtaining the important facts for implementing the decision-making.
• It forms the basis for all the planning activities.
• PERT helps management in deciding the best possible resource utilization method.
• PERT take advantage by using time network analysis technique.
• PERT presents the structure for reporting information.
• It helps the management in identifying the essential elements for the completion of the project within time.
Advantages of PERT:
• Estimation of completion time of project is given by the PERT.
• It supports the identification of the activities with slack time.
• The start and dates of the activities of a specific project is determined.
• It helps project manager in identifying the critical path activities.
• PERT makes well organized diagram for the representation of large amount of data.

Disadvantages of PERT:

• The complexity of PERT is more which leads to the problem in implementation.

• The estimation of activity time are subjective in PERT which is a major disadvantage.
• Maintenance of PERT is also expensive and complex.
Gantt Chart
2. Critical Path Method (CPM) is a method used in project planning, generally for project scheduling for the on-time
completion of the project. It actually helps in the determination of the earliest time by which the whole project can be
completed.
Critical Path Method (CPM) is a network analysis approach. It find out which sequence of activities has the least
measure of scheduling flexible by which it predict the duration of the project. It is based on the estimation of the
standard time needed for execution of a activity. CPM manages the both time and cost of the project.
There are two main concepts in this method namely critical task and critical path. .
• Critical task is the task/activity which can’t be delayed otherwise the completion of the whole project will be
delayed. It must be completed on-time before starting the other dependent tasks.
• Critical path is a sequence of critical tasks/activities and is the largest path in the project network. It gives us
the minimum time which is required to complete the whole project. The activities in the critical path are known
as critical activities and if these activities are delayed then the completion of the whole project is also delayed
Major steps of the Critical Path Method:
• Identifying the activities
• Construct the project network
• Perform time estimation using forward and backward pass
• Identify the critical path
Task Predecessor’s Duration
A - 3
B A 5 A B D F 3 5 6 4 18
C A 4
D B 6 A B E F 3 5 7 4 19
E B, C 7
F D, E 4 A C D F 3 4 7 4 18

5
3 B D 6
Duration : 19 Days
A 4
F
4
C
E
7
Advantages of Critical Path Method (CPM):
• It figures out the activities which can run parallel to each other.
• CPM is effective in new project management.
• It helps the project manager in identifying the most critical elements of the project.
• It gives a practical and disciplined base which helps in determining how to reach the objectives.
• CPM provides demonstration of dependencies which helps in the scheduling of individual activities.
• It helps in optimization by determining the project duration.
• An explicit and clear approach of communicating project plans, schedules, time and cost performance is developed.

Disadvantages of Critical Path Method (CPM):

• The scheduling of personnel is not handled by the CPM.
• In CPM, it is difficult to estimate the completion time of an activity.
• The critical path is not always clear in CPM.
• For bigger projects, CPM networks can be complicated too.
• It also does not handle the scheduling of the resource allocation.
• In CPM, critical path needs to be calculated precisely.
What is Project Tracking?
Project Tracking is a method of project management for following the progress of activities involved in projects.
Potential issues can be spotted and solved by team members and leaders.

Tracking projects from the beginning, dealing with problems quickly, and proactively making decisions is what
successful project managers do.

Managing all tasks and activities involved, handling multiple files involved, and most importantly, the people who make
up the team make this incredibly challenging.
Project tracking begins early in the project with planning and goes on until the completion of a project. Monitoring
project progress to identify potential problems in a timely manner and take corrective action.
Measuring project performance regularly to identify variances from the project management plan to make sure
projects are on track.
Simple project management software is designed with everything in one place in real-time to keep projects visible
across teams and stakeholders efficiently.
Why use Project Management Tracking?
There are multiple benefits and many reasons to engage with project tracking, from increased chances of project
success to creating a united team. Keeping up to date on the progress of the project and awareness of project status, it is
easy to spot any potential issues that could prevent project success.
Complete transparency is essential for accurate decision-making. Project tracking keeps all team members and
stakeholders in touch with deadlines and goals, enabling the project lead to manage with confidence.
Crucially, project tracking aims to help project managers adjust deliverables such as budgets and timelines based on
what you learn throughout a project.
There are four key benefits that effective project tracking should deliver.
1. Real Time Information
Firstly, stay up to date and get the most accurate information available. Everyone involved in the project needs to see the
status and progress of the project in an instant. This is crucial for senior management to make decisions at the top level
of the project along with team leaders on behalf of the team.
Using cloud-based simple project management software, reporting to senior management should be painless.
By tracking projects, teams can be aligned, along with project objectives and activities. Stay in touch and watch goals
become reality.
2. Problem Identifiers
With project tracking, there is no place for problems or issues to hide. Any up-and-coming issues are recognizable in an
instant. This allows leaders to act and take back control of the situation.
Team members can offer assistance and keep each other motivated to get jobs done. Problem-solving maintains the
structure of the project and allows resources to spend time on the things that matter. Once the issues are gone, the
project is back on track and success is on the limit.
3. Team Motivation
Collaboration is a key factor of every project. If every member has clarity on their role, they can work toward the group
objectives. As projects progress and the task list reduces with every day, team motivation to carry on and complete the
project make stronger.
By working together and creating an empowered team, project tracking keeps everyone in the loop and on the same page.
4. Easy and Accurate Reporting
Reporting is often a painful task that project managers are required to do. Senior management want an overall view of
each of the projects in an instant.
Using one system in order to manage and track projects makes reporting quick and simple. Time is valuable so having
all information in one place with more detail available if needed, perfect for reporting to senior executives.
Challenges in tracking the progress of a project
Project managers can face a range of different challenges as they get to track project progress and create reports:
• Lack of communication.
Without timely and effective communication in project management, it can be hard to get an accurate picture of
how a project is progressing.
• Unclear goals or criteria.
If you don’t know what creates success in your project, it’s hard to measure how close you are to being finished.
• Scope creep.
If the scope of a project changes mid-way through, that can affect a wide range of budgets, timelines, resource
requirements, and more.
▪ Insufficient risk management.
If you haven’t fully accounted for a project risk, that can present a number of unexpected issues.
Software Design
Software design is a mechanism to transform user requirements into some suitable form, which helps the
programmer in software coding and implementation.
It deals with representing the client's requirement, as described in SRS (Software Requirement Specification)
document, into a form, i.e., easily implementable using programming language. Hence the aim of this phase is to
transform the SRS document into the design document.

The following items are designed and documented during the design phase:
• Different modules required.
• Interface among different modules.
• Data structure among the different modules.
• Control relationships among modules.
• Algorithms required to implement among the individual modules.

Software Design Definition:

• Software design is the process of investing and selecting programs that meet the objective for a software system.

• Software design is the process of envisioning and defining software solutions to one or more sets of problems.
Objectives of Software Design
Following are the purposes of Software design:
• Correctness : Software design should be correct as per requirement.
• Completeness : The design should have all components like data structures, modules, and external interfaces, etc.
• Efficiency : Resources should be used efficiently by the program.
• Flexibility : Able to modify on changing needs.
• Consistency : There should not be any inconsistency in the design.
• Maintainability: The design should be so simple so that it can be easily maintainable by other designers.
principles of good Software Design
Many principles are employed to organize, coordinate, classify, and set up software design’s structural components.
Software Designs become some of the most convenient designs when the following principles are applied. They
help to generate remarkable User Experiences and customer loyalty.
The principles of a good software design are:
• Modularity
Dividing a large software project into smaller portions/modules is known as modularity. It is the key to scalable and
maintainable software design. The project is divided into various components and work on one component is done
at once. It becomes easy to test each component due to modularity. It also makes integrating new features more
accessible.
• Coupling
Coupling refers to the extent of interdependence between software modules and how closely two modules are
connected. Low coupling is a feature of good design. With low coupling, changes can be made in each module
individually, without changing the other modules.
• Abstraction
The process of identifying the essential behaviour by separating it from its implementation and removing irrelevant
details is known as Abstraction. The inability to separate essential behaviour from its implementation will lead to
unnecessary coupling.
• Anticipation of Change
The demands of software keep on changing, resulting in continuous changes in requirements as well. Building a
good software design consists of its ability to accommodate and adjust to change comfortably.
• Simplicity
The aim of good software design is simplicity. Each task has its own module, which can be utilized and modified
independently. It makes the code easy to use and minimizes the number of setbacks.
• Sufficiency and Completeness
A good software design ensures the sufficiency and completeness of the software concerning the established
requirements. It makes sure that the software has been adequately and wholly built.
Design Process
Software design is an iterative process through which requirements are translated into a “blueprint” for constructing
the software. Initially, the blueprint depicts a holistic view of software i.e., the design is represented at a high level of
abstraction – a level that can be directly traced to the specific system objectives. As design iterations occur, subsequent
refinement leads to design representations at much lower levels of abstraction.
McGlaughlin suggests 3 characteristics that serve as a guide for evaluation of a good design:
1. The design must implement all of the explicit requirements contained in the analysis model and it must
accommodate all of the implicit requirements desired by the customer.
2. The design must be readable, understandable guide for those who generate code and for those who test and
support the software.
3. The design should provide a complete picture of the software, addressing all data, functional and behavioural
domains.
Each of these characteristics is actually a goal of the design process.
Quality Guidelines that lead to a good design
1. A design should displays an architecture that
a) Has been created using recognizable architectural styles or patterns;
b) Is composed of components that shows good design characteristics, and
c) Can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.
2. A design should be modular; that is, the software should be logically divided into elements or subsystems.
3. A design should contain different representations of data, architecture, interfaces, and components.
4. A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from
recognizable data patterns.
5. A design should lead to the components that shows independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between components and with the
external environment.
7. A design should be derived using a repeatable method that is driven by information obtained during software
requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.
Design Principles
Software design is both a process and a model.
• The ‘design process’ is a sequence of steps that enable the designer to describe all aspects of the software to be built.
• The ‘design model’ is however, an equivalent of an architect’s plan for a house.

It begins by representing the totality of the thing to be built (e.g. a 3D house) and slowly filtering it into more details.
Similarly, the design model that is created for software provides a variety of different views of the computer software.
Davis – Design Principles

• A good designer should consider alternative approaches, judging each based on the requirements of the problem,
and the resources available to do the job.

• The design should be traceable to the analysis model. It is necessary to have a means for tracking how requirements
have been satisfied by the design model.

• The designer should not reinvent the wheel, i.e., Use the set of design patterns, already encountered so that new
patterns are not reinvented. Time is short and resources are limited. Design time should be invested in
representing truly new ideas and integrating those patterns that already exist.
• The design should be structured to accommodate change.

• Design is not coding, coding is not design.

• The design should shows uniformity and integration. A design is uniform if it appears that one person developed
the entire thing. Rules of style and format should be defined for a design team before design work begins. A design
is integrated if care is taken in defining interfaces between design components.
Design Concepts

There are 9 design concepts that we must study:

❖ Abstraction
❖ Architecture
❖ Patterns

❖ Modularity
❖ Information hiding

❖ Functional independence
❖ Refinement
❖ Refactoring

❖ Design classes
Abstraction: A solution is stated in large terms using the language of the problem environment at the highest level
abstraction.
• The lower level of abstraction provides a more detail description of the solution.
• A sequence of instruction that contain a specific and limited function refers in a procedural abstraction.
• A collection of data that describes a data object is a data abstraction.
Architecture: The complete structure of the software is known as software architecture.
• Structure provides conceptual integrity for a system in a number of ways.
• The architecture is the structure of program modules where they interact with each other in a specialized way.
• The components use the structure of data.
• The aim of the software design is to obtain an architectural framework of a system.
• The more detailed design activities are conducted from the framework.
Patterns: A design pattern describes a design structure and that structure solves a particular design problem in a
specified content.
Modularity: A software is separately divided into name and addressable components. Sometime they are called as
modules which integrate to satisfy the problem requirements. Modularity is the single attribute of a software that
permits a program to be managed easily.
Information hiding: Modules must be specified and designed so that the information like algorithm and data
presented in a module is not accessible for other modules not requiring that information.
Functional independence: The functional independence is the concept of separation and related to the concept of
modularity, abstraction and information hiding.
The functional independence is accessed using two criteria i.e. Cohesion and coupling.
• Cohesion: Cohesion is an extension of the information hiding concept.
A cohesive module performs a single task and it requires a small interaction with the other components in other
parts of the program.
• Coupling: Coupling is an indication of interconnection between modules in a structure of software.

Refinement: Refinement is a top-down design approach.

• It is a process of elaboration.
• A program is established for refining levels of procedural details.
• A hierarchy is established by decomposing a statement of function in a stepwise manner till the
programming language statement are reached.

Refactoring: It is a reorganization technique which simplifies the design of components without changing its function
behaviour. Refactoring is the process of changing the software system in a way that it does not change the external
behaviour of the code still improves its internal structure.

Design classes: The model of software is defined as a set of design classes. Every class describes the elements of
problem domain and that focus on features of the problem which are user visible.
Design Model
The design principles and concepts establish a foundation for the creation of the design model that encompasses
representation of data, architecture, interface and components. Like the analysis model before it, each of these design
representations is tied to the others, and all can be traced back to software requirements.
The Following are some design models
1. Data Design – It transforms the information domain model created during analysis into the data structures that will
be required to implement the software. The data objects (or entities) and the relationships defined in ER diagram and
the detailed data content shown in the Data Dictionary provide the basis for the data design activity. Detailed data
design occurs as each software component is designed.
2. Architectural Design – It defines the relationship between major structural elements of the software, the “design
patterns” that can be used to achieve the requirements that have been defined for the system. This design
representation forms the framework of a computer based system. It can be derived from the system specification, the
analysis model and the interaction of subsystems defined within the analysis model.
3. Interface Design – It describes how the software communicates within itself, with systems that interoperate with
it and with humans who use it. An interface implies a flow of information and a specific type of behaviour. Therefore,
data and control flow diagrams provide much of the information required for interface design.
4. Component Level Design – It transforms structural elements of the software architecture into a procedural
description of software components. Information obtained from ER-Diagrams, Data Flow diagrams serves as the basis
for component design.
Software Requirements Specification (SRS)
A software requirements specification (SRS) is a detailed description of a software system to be developed with its
functional and non-functional requirements. The SRS is developed based the agreement between customer and
contractors. It may include the use cases of how user is going to interact with software system.

The software requirement specification document consistent of all necessary requirements required for project
development. To develop the software system we should have clear understanding of Software system. To achieve this
we need to continuous communication with customers to gather all requirements.

A good SRS defines the how Software System will interact with all internal modules, hardware, communication with
other programs and human user interactions with wide range of real life scenarios. Using the Software requirements
specification (SRS) document on QA lead, managers creates test plan.

It is very important that testers must be cleared with every detail specified in this document in order to avoid faults in
test cases and its expected results.
It is highly recommended to review or test Software Requirement Specification documents before start writing test
cases and making any plan for testing.
Let’s see how to test SRS and the important point to keep in mind while testing it.
1. Correctness of Software Requirement Specification should be checked. Since the whole testing phase is
dependent on SRS, it is very important to check its correctness. There are some standards with which we can compare
and verify.
2. Ambiguity should be avoided. Sometimes in SRS, some words have more than one meaning and this might
confused testers making it difficult to get the exact reference. It is advisable to check for such ambiguous words and
make the meaning clear for better understanding.
3. Requirements should be complete. When tester writes test cases, what exactly is required from the application, is
the first thing which needs to be clear. For e.g. if application needs to send the specific data of some specific size then it
should be clearly mentioned in SRS that how much data and what is the size limit to send.
4. Consistent requirements. The SRS should be consistent within itself and consistent to its reference documents. If
you call an input “Start and Stop” in one place, don’t call it “Start/Stop” in another. This sets the standard and should
be followed throughout the testing phase.
5. Verification of expected result: Software Requirement Specification should not have statements like “Work as
expected”, it should be clearly stated that what is expected since different testers would have different thinking aspects
and may draw different results from this statement.
6. Testing environment: some applications need specific conditions to test and also a particular environment for
accurate result. SRS should have clear documentation on what type of environment is needed to set up.
7. Pre-conditions defined clearly: one of the most important part of test cases is pre-conditions. If they are not met
properly then actual result will always be different expected result. Verify that in SRS, all the pre-conditions are
mentioned clearly.

8. Requirements ID: these are the base of test case template. Based on requirement Ids, test case ids are written. Also,
requirements ids make it easy to categorize modules so just by looking at them, tester will know which module to refer.
SRS must have them such as id defines a particular module.

9. Security and Performance criteria: security is priority when a software is tested especially when it is built in such
a way that it contains some crucial information when leaked can cause harm to business. Tester should check that all
the security related requirements are properly defined and are clear to him.
Also, when we talk about performance of a software, it plays a very important role in business so all the requirements
related to performance must be clear to the tester and he must also know when and how much stress or load testing
should be done to test the performance.

10. Assumption should be avoided: sometimes when requirement is not cleared to tester, he tends to make some
assumptions related to it, which is not a right way to do testing as assumptions could go wrong and hence, test results
may vary. It is better to avoid assumptions and ask clients about all the “missing requirements” to have a better
understanding of expected results.
11. Deletion of irrelevant requirements: there are more than one team who work on SRS so it might be possible that
some irrelevant requirements are included in SRS. Based on the understanding of the software, tester can find out
which are these requirements and remove them to avoid confusions and reduce work load.
Advantages of SRS

• It provides client a satisfaction as this is the first response to the client.

• It defines functional and non-functional requirement.
• It eliminates any confusion or misunderstanding on initial stage.
• It reduces development effort.
• It reduces the chances of requirement creep.
• It makes testing easier.
• It defines project scope.
• It provides the basis for plan charter, work load, dependencies, etc.
Thank You