Software 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. To plan a successful
software project, we must understand:

o Scope of work to be completed

o Risk analysis
o The resources mandatory
o The project to be accomplished
o Record of being followed

Software Project planning starts before technical work start. The various steps of planning
activities are:
The size is the crucial parameter for the estimation of other activities. Resources requirement are
required based on cost and development time. Project schedule may prove to be very useful for
controlling and monitoring the progress of the project. This is dependent on resources &
development time.

size estimation is a crucial aspect of software engineering, as it helps in

planning and allocating resources for the project. Here are some of the
popular project size estimation techniques used in software engineering:
Expert Judgment: In this technique, a group of experts in the relevant field
estimates the project size based on their experience and expertise. This
technique is often used when there is limited information available about the
project.
Analogous Estimation: This technique involves estimating the project size
based on the similarities between the current project and previously completed
projects. This technique is useful when historical data is available for similar
projects.
Bottom-up Estimation: In this technique, the project is divided into smaller
modules or tasks, and each task is estimated separately. The estimates are
then aggregated to arrive at the overall project estimate.

Three-point Estimation: This technique involves estimating the project size

using three values: optimistic, pessimistic, and most likely. These values are
then used to calculate the expected project size using a formula such as the
PERT formula.
Function Points: This technique involves estimating the project size based on
the functionality provided by the software. Function points consider factors such
as inputs, outputs, inquiries, and files to arrive at the project size estimate.
Use Case Points: This technique involves estimating the project size based on
the number of use cases that the software must support. Use case points
consider factors such as the complexity of each use case, the number of actors
involved, and the number of use cases.
Each of these techniques has its strengths and weaknesses, and the choice
of technique depends on various factors such as the project’s complexity,
available data, and the expertise of the team.
Estimation of the size of the software is an essential part of Software Project
Management. It helps the project manager to further predict the effort and time
which will be needed to build the project. Various measures are used in project
size estimation. Some of these are:
 Lines of Code
 Number of entities in ER diagram
 Total number of processes in detailed data flow diagram
 Function points
1. Lines of Code (LOC): As the name suggests, LOC counts the total number
of lines of source code in a project. The units of LOC are:
 KLOC- Thousand lines of code
 NLOC- Non-comment lines of code
 KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same
kind. The experts use it to predict the required size of various components of
software and then add them to get the total size.
It’s tough to estimate LOC by analyzing the problem definition. Only after the
whole code has been developed can accurate LOC be estimated. This statistic
is of little utility to project managers because project planning must be
completed before development activity can begin.
Two separate source files having a similar number of lines may not require the
same effort. A file with complicated logic would take longer to create than one
with simple logic. Proper estimation may not be attainable based on LOC.
The length of time it takes to solve an issue is measured in LOC. This statistic
will differ greatly from one programmer to the next. A seasoned programmer
can write the same logic in fewer lines than a newbie coder.
Advantages:
 Universally accepted and is used in many models like COCOMO.
 Estimation is closer to the developer’s perspective.
 Both people throughout the world utilize and accept it.
 At project completion, LOC is easily quantified.
 It has a specific connection to the result.
 Simple to use.
Disadvantages:
 Different programming languages contain a different number of lines.
 No proper industry standard exists for this technique.
 It is difficult to estimate the size using this technique in the early stages of
the project.
 When platforms and languages are different, LOC cannot be used to
normalize.
2. Number of entities in ER diagram: ER model provides a static view of the
project. It describes the entities and their relationships. The number of entities
in ER model can be used to measure the estimation of the size of the project.
The number of entities depends on the size of the project. This is because more
entities needed more classes/structures thus leading to more coding.
Advantages:
 Size estimation can be done during the initial stages of planning.
 The number of entities is independent of the programming technologies
used.
Disadvantages:
 No fixed standards exist. Some entities contribute more to project size than
others.
 Just like FPA, it is less used in the cost estimation model. Hence, it must be
converted to LOC.
3. Total number of processes in detailed data flow diagram: Data Flow
Diagram(DFD) represents the functional view of software. The model depicts
the main processes/functions involved in software and the flow of data between
them. Utilization of the number of functions in DFD to predict software size.
Already existing processes of similar type are studied and used to estimate the
size of the process. Sum of the estimated size of each process gives the final
estimated size.
Advantages:
 It is independent of the programming language.
 Each major process can be decomposed into smaller processes. This will
increase the accuracy of the estimation
Disadvantages:
 Studying similar kinds of processes to estimate size takes additional time
and effort.
 All software projects are not required for the construction of DFD.
 Functional Point (FP) Analysis
Function Point Analysis was initially developed by Allan J. Albrecht in 1979 at
IBM and it has been further modified by the International Function Point Users
Group (IFPUG). The initial definition is given by Allan J. Albrecht.
Functional Point Analysis gives a dimensionless number defined in function
points which we have found to be an effective relative measure of function value
delivered to our customer.
Objectives of Functional Point Analysis
 The objective of FPA is to measure the functionality that the user requests
and receives.
 The objective of FPA is to measure software development and maintenance
independently of the technology used for implementation.
 It should be simple enough to minimize the overhead of the measurement
process.
 It should be a consistent measure among various projects and
organizations.
Types of Functional Point Analysis
There are basically two types of Functional Point Analysis, that are listed below.
 Transactional Functional Type
 Data Functional Type
Transactional Functional Type
 External Input (EI): EI processes data or control information that comes
from outside the application’s boundary. The EI is an elementary process.
 External Output (EO): EO is an elementary process that generates data or
control information sent outside the application’s boundary.
 External Inquiries (EQ): EQ is an elementary process made up of an input-
output combination that results in data retrieval.
Data Functional Type
 Internal Logical File (ILF): A user-identifiable group of logically related data
or control information maintained within the boundary of the application.
 External Interface File (EIF): A group of users recognizable logically related
data allusion to the software but maintained within the boundary of another
software.
Benefits of Functional Point Analysis
 FPA is a tool to determine the size of a purchased application package by
counting all the functions included in the package.
 It is a tool to help users discover the benefit of an application package to
their organization by counting functions that specifically match their
requirements.
 It is a tool to measure the units of a software product to support quality and
productivity analysis.
 It is a vehicle to estimate the cost and resources required for software
development and maintenance.
 It is a normalization factor for software comparison.
Characteristics of Functional Point Analysis
We calculate the functional point with the help of the number of functions and
types of functions used in applications. These are classified into five types.
Measurement Parameters Examples

Number of External Inputs (EI) Input screen and tables

Number of External Output (EO) Output screens and reports

Number of external inquiries (EQ) Prompts and interrupts

Measurement Parameters Examples

Number of internal files (ILF) Databases and directories

Number of external interfaces (EIF) Shared databases and shared routines

Functional Point helps in describing system complexity and also shows project
timelines. It is majorly used for business systems like information systems.
Weights of 5 Functional Point Attributes
Measurement Parameter Low Average High

Number of external inputs (EI) 3 4 6

Number of external outputs (EO) 4 5 7

Number of external inquiries (EQ) 3 4 6

Number of internal files (ILF) 7 10 15

Number of External Interfaces (EIF) 5 7 10

Functional Complexities help us in finding the corresponding weights, which

results in finding the Unadjusted Functional point (UFp) of the Subsystem.
Below mentioned is the way how to compute FP.

Weighing Factor

Measurement Parameter Count Simple Average Complex

Number of external inputs (EI) 32 * 3 4 6 = 128

 Weighing Factor

Measurement Parameter Count Simple Average Complex

Number of external outputs (EO) 60 * 4 5 7 = 300

Number of external inquiries (EQ) 24 * 3 4 6 = 96

Number of internal files (ILF) 8 * 7 10 15 = 80

Number of external interfaces

2 * 5 7 10 = 40
(EIF)

Algorithms used Count total → 618

From the above tables, Functional Point is calculated with the following formula
FP = Count-Total * [0.65 + 0.01 * ⅀(fi)]
= Count * CAF
Here, the count-total is taken from the chart.
CAF = [0.65 + 0.01 * ⅀(fi)]
 (fi) = sum of all 14 questions and it also shows the complexity factor – CAF.
 CAF varies from 0.65 to 1.35 and ⅀(fi) ranges from 0 to 70.
 When ⅀(fi) = 0, CAF = 0.65 and when ⅀(fi) = 70, CAF = 0.65 + (0.01*70) =
0.65 + 0.7 = 1.35

Cost Estimation Models in Software

Engineering
Cost estimation simply means a technique that is used to find out the cost
estimates. The cost estimate is the financial spend that is done on the efforts to
develop and test software in Software Engineering. Cost estimation models are
some mathematical algorithms or parametric equations that are used to
estimate the cost of a product or a project.
Various techniques or models are available for cost estimation, also known as
Cost Estimation Models as shown below :
Empirical Estimation Technique –
Empirical estimation is a technique or model in which empirically derived
formulas are used for predicting the data that are a required and essential part
of the software project planning step. These techniques are usually based on
the data that is collected previously from a project and also based on some
guesses, prior experience with the development of similar types of projects, and
assumptions. It uses the size of the software to estimate the effort.
In this technique, an educated guess of project parameters is made. Hence,
these models are based on common sense. However, as there are many
activities involved in empirical estimation techniques, this technique is
formalized. For example Delphi technique and Expert Judgement technique.
1. Heuristic Technique –
Heuristic word is derived from a Greek word that means “to discover”. The
heuristic technique is a technique or model that is used for solving problems,
learning, or discovery in the practical methods which are used for achieving
immediate goals. These techniques are flexible and simple for taking quick
decisions through shortcuts and good enough calculations, most probably
when working with complex data. But the decisions that are made using this
technique are necessary to be optimal.
In this technique, the relationship among different project parameters is
expressed using mathematical equations. The popular heuristic technique is
given by Constructive Cost Model (COCOMO). This technique is also used
to increase or speed up the analysis and investment decisions.
2. Analytical Estimation Technique –
Analytical estimation is a type of technique that is used to measure work. In
this technique, firstly the task is divided or broken down into its basic
component operations or elements for analyzing. Second, if the standard
 time is available from some other source, then these sources are applied to
each element or component of work.
Third, if there is no such time available, then the work is estimated based on
the experience of the work. In this technique, results are derived by making
certain basic assumptions about the project. Hence, the analytical estimation
technique has some scientific basis. Halstead’s software science is based on
an analytical estimation model.

COCOMO Model
Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO 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 a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

1.Organic: 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. Examples of this type of projects are simple business systems,
simple inventory management systems, and data processing systems.

Semidetached: 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. Example of Semidetached system includes
developing a new operating system (OS), a Database Management System (DBMS),
and complex inventory management system.

3. Embedded: 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, Bohem 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=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months

Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1,a2,b1,b2 are constants 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).
Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based
on the code size are shown below:

Organic: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: Effort = 3.0(KLOC) 1.12 PM

Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development
time based on the effort are given below:

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months

Embedded: Tdev = 2.5(Effort) 0.32 Months

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.
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.

It is important to note that the effort and the duration estimations obtained using the
COCOMO model are called a nominal effort estimate and nominal duration estimate. The
term nominal implies that if anyone tries to complete the project in a time shorter than
the estimated duration, then the cost will increase drastically. But, if anyone completes
the project over a longer period of time than the estimated, then there is almost no
decrease in the estimated cost value.

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=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC

(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

E = 3.6 * (400)1.20 = 4772.81 PM

D = 2.5 * (4772.8)0.32 = 38 PM

Example2: 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=1133.12PM
D=2.5(1133.12)0.35=29.3PM

Hardware attributes –

o Run-time performance constraints

o Memory constraints
 o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -

o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
o Required development schedule

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:

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:

(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.

What is Risk?
"Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a problem
that could cause some loss or threaten the progress of the project, but which has not
happened yet.

These potential issues might harm cost, schedule or technical success of the project and
the quality of our software device, or project team morale.

Risk Management is the system of identifying addressing and eliminating these problems
before they can damage the project.

We need to differentiate risks, as potential issues, from the current problems of the
project.

Different methods are required to address these two kinds of issues.

For example, staff storage, because we have not been able to select people with the right
technical skills is a current problem, but the threat of our technical persons being hired
away by the competition is a risk.

Risk Management
A software project can be concerned with a large variety of risks. In order to be adept to
systematically identify the significant risks which might affect a software project, it is
essential to classify risks into different classes. The project manager can then check which
risks from each class are relevant to the project.

There are three main classifications of risks which can affect a software project:
 1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel,
resource, and customer-related problems. A vital project risk is schedule slippage. Since
the software is intangible, it is very tough to monitor and control a software project. It is
very tough to control something which cannot be identified. For any manufacturing
program, such as the manufacturing of cars, the plan executive can recognize the product
taking shape.

2. Technical risks: Technical risks concern potential method, implementation, interfacing,

testing, and maintenance issue. It also consists of an ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence.
Most technical risks appear due to the development team's insufficient knowledge about
the project.

3. Business risks: This type of risks contain risks of building an excellent product that no
one need, losing budgetary or personnel commitments, etc.

Other risk categories

1. 1. Known risks: Those risks that can be uncovered after careful assessment of the
project program, the business and technical environment in which the plan is being
developed, and more reliable data sources (e.g., unrealistic delivery date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough
to identify in advance.

Principle of Risk Management

1. Global Perspective: In this, we review the bigger system description, design, and
implementation. We look at the chance and the impact the risk is going to have.
2. Take a forward-looking view: Consider the threat which may appear in the future
and create future plans for directing the next events.
 3. Open Communication: This is to allow the free flow of communications between
the client and the team members so that they have certainty about the risks.
4. Integrated management: In this method risk management is made an integral
part of project management.
5. Continuous process: In this phase, the risks are tracked continuously throughout
the risk management paradigm.

Risk Assessment
The objective of risk assessment is to division the risks in the condition of their loss,
causing potential. For risk assessment, first, every risk should be rated in two methods:

o The possibility of a risk coming true (denoted as r).

o The consequence of the issues relates to that risk (denoted as s).
Based on these two methods, the priority of each risk can be estimated:

p=r*s

Where p is the priority with which the risk must be controlled, r is the probability of the
risk becoming true, and s is the severity of loss caused due to the risk becoming true. If
all identified risks are set up, then the most likely and damaging risks can be controlled
first, and more comprehensive risk abatement methods can be designed for these risks.

1. Risk Identification: The project organizer needs to anticipate the risk in the project as
early as possible so that the impact of risk can be reduced by making effective risk
management planning.

A project can be of use by a large variety of risk. To identify the significant risk, this might
affect a project. It is necessary to categories into the different risk of classes.

There are different types of risks which can affect a software project:

1. Technology risks: Risks that assume from the software or hardware technologies
that are used to develop the system.
2. People risks: Risks that are connected with the person in the development team.
3. Organizational risks: Risks that assume from the organizational environment
where the software is being developed.
4. Tools risks: Risks that assume from the software tools and other support software
used to create the system.
5. Requirement risks: Risks that assume from the changes to the customer
requirement and the process of managing the requirements change.
6. Estimation risks: Risks that assume from the management estimates of the
resources required to build the system

2. Risk Analysis: During the risk analysis process, you have to consider every identified
risk and make a perception of the probability and seriousness of that risk.

There is no simple way to do this. You have to rely on your perception and experience of
previous projects and the problems that arise in them.

It is not possible to make an exact, the numerical estimate of the probability and
seriousness of each risk. Instead, you should authorize the risk to one of several bands:
 1. The probability of the risk might be determined as very low (0-10%), low (10-25%),
moderate (25-50%), high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of
the plan), serious (would cause significant delays), tolerable (delays are within
allowed contingency), or insignificant.

Risk Control
It is the process of managing risks to achieve desired outcomes. After all, the identified
risks of a plan are determined; the project must be made to include the most harmful and
the most likely risks. Different risks need different containment methods. In fact, most
risks need ingenuity on the part of the project manager in tackling the risk.

There are three main methods to plan for risk management:

1. Avoid the risk: This may take several ways such as discussing with the client to
change the requirements to decrease the scope of the work, giving incentives to
the engineers to avoid the risk of human resources turnover, etc.
2. Transfer the risk: This method involves getting the risky element developed by a
third party, buying insurance cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk. For
instance, if there is a risk that some key personnel might leave, new recruitment
can be planned.

Risk Leverage: To choose between the various methods of handling risk, the project plan
must consider the amount of controlling the risk and the corresponding reduction of risk.
For this, the risk leverage of the various risks can be estimated.

Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.

Risk leverage = (risk exposure before reduction - risk exposure after reduction) /
(cost of reduction)

1. Risk planning: The risk planning method considers each of the key risks that have been
identified and develop ways to maintain these risks.

For each of the risks, you have to think of the behavior that you may take to minimize the
disruption to the plan if the issue identified in the risk occurs.
You also should think about data that you might need to collect while monitoring the
plan so that issues can be anticipated.

Again, there is no easy process that can be followed for contingency planning. It rely on
the judgment and experience of the project manager.

3. Risk Monitoring: Risk monitoring is the method king that your assumption about
the product, process, and business risks has not changed.

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.

The software design phase is the first step in SDLC (Software Design Life Cycle), which
moves the concentration from the problem domain to the solution domain. In software
design, we consider the system to be a set of components or modules with clearly defined
behaviors & boundaries.
Objectives of Software Design
Following are the purposes of Software design:

1. Correctness:Software design should be correct as per requirement.

2. Completeness:The design should have all components like data structures,
modules, and external interfaces, etc.
 3. Efficiency:Resources should be used efficiently by the program.
4. Flexibility:Able to modify on changing needs.
5. Consistency:There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily
maintainable by other designers.

Coupling and Cohesion

Module Coupling
In software engineering, the coupling is the degree of interdependence between software
modules. Two modules that are tightly coupled are strongly dependent on each other.
However, two modules that are loosely coupled are not dependent on each
other. Uncoupled modules have no interdependence at all within them.

The various typ

es of coupling techniques are shown in fig:

3. Stamp Coupling: Two modules are stamp coupled if they communicate using
composite data items such as structure, objects, etc. When the module passes non-global
data structure or entire structure to another module, they are said to be stamp coupled.
For example, passing structure variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one
module is used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally
imposed data format, communication protocols, or device interface. This is related to
communication to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information
through some global data items.

Content Coupling: Content Coupling exists among two modules if they share code, e.g.,
a branch from one module into another module.

Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a
module belong together. Thus, cohesion measures the strength of relationships between
pieces of functionality within a given module. For example, in highly cohesive systems,
functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high

cohesion" or "low cohesion."
1. Functional Cohesion: Functional Cohesion is said to exist if the different elements
of a module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the
element of a module form the components of the sequence, where the output
from one component of the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational
cohesion, if all tasks of the module refer to or update the same data structure, e.g.,
the set of functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of
purpose of the module are all parts of a procedure in which particular sequence
of steps has to be carried out for achieving a goal, e.g., the algorithm for decoding
a message.
5. Temporal Cohesion: When a module includes functions that are associated by
the fact that all the methods must be executed in the same time, the module is
said to exhibit temporal cohesion.
 6. Logical Cohesion: A module is said to be logically cohesive if all the elements of
the module perform a similar operation. For example Error handling, data input
and data output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it
performs a set of tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.

Coupling shows the relationships between Cohesion shows the relationship within the module.
modules.

Coupling shows the Cohesion shows the module's relative functional strength.
relative independence between the modules.

While creating, you should aim for low While creating you should aim for high cohesion, i.e., a cohesiv
coupling, i.e., dependency among modules component/ module focuses on a single function (i.e., single
should be less. mindedness) with little interaction with other modules of th
system.

In coupling, modules are linked to the other In cohesion, the module focuses on a single thing.
modules.

Function Oriented Design

Function Oriented design is a method to software design where the model is decomposed
into a set of interacting units or modules where each unit or module has a clearly defined
function. Thus, the system is designed from a functional viewpoint.

Design Notations
Design Notations are primarily meant to be used during the process of design and are
used to represent design or design decisions. For a function-oriented design, the design
can be represented graphically or mathematically by the following:
Data Flow Diagram
Data-flow design is concerned with designing a series of functional transformations that
convert system inputs into the required outputs. The design is described as data-flow
diagrams. These diagrams show how data flows through a system and how the output is
derived from the input through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are
generally understandable without specialized training, notably if control information is
excluded. They show end-to-end processing. That is the flow of processing from when
data enters the system to where it leaves the system can be traced.

Data-flow design is an integral part of several design methods, and most CASE tools
support data-flow diagram creation. Different ways may use different icons to represent
data-flow diagram entities, but their meanings are similar.

The notation which is used is based on the following symbols:

The report generator produces a report which describes all of the named entities in a
data-flow diagram. The user inputs the name of the design represented by the diagram.
The report generator then finds all the names used in the data-flow diagram. It looks up
a data dictionary and retrieves information about each name. This is then collated into a
report which is output by the system.

Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a system. The data
items listed contain all data flows and the contents of all data stores looking on the DFDs
in the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all composite
data elements in terms of their component data items. For example, a data dictionary
entry may contain that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of
the following reasons:

o A Data dictionary provides a standard language for all relevant information for use
by engineers working in a project. A consistent vocabulary for data items is
essential since, in large projects, different engineers of the project tend to use
different terms to refer to the same data, which unnecessarily causes confusion.
o The data dictionary provides the analyst with a means to determine the definition
of various data structures in terms of their component elements.

Structured Charts
It partitions a system into block boxes. A Black box system that functionality is known to
the user without the knowledge of internal design.
Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules
o The relation between processing modules
o Interaction between modules
o Information passed between modules

The following notations are used in structured chart:

Pseudo-code
Pseudo-code notations can be used in both the preliminary and detailed design phases.
Using pseudo-code, the designer describes system characteristics using short, concise,
English Language phases that are structured by keywords such as If-Then-Else, While-Do,
and End.

Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects (i.e.,
entities). The state is distributed among the objects, and each object handles its state
data. For example, in a Library Automation Software, each library representative may be a
separate object with its data and functions to operate on these data. The tasks defined
for one purpose cannot refer or change data of other objects. Objects have their internal
data which represent their state. Similar objects create a class. In other words, each object
is a member of some class. Classes may inherit features from the superclass.

The different terms related to object design are:

1. Objects: All entities involved in the solution design are known as objects. For
example, person, banks, company, and users are considered as objects. Every entity
has some attributes associated with it and has some methods to perform on the
attributes.
2. Classes: A class is a generalized description of an object. An object is an instance
of a class. A class defines all the attributes, which an object can have and methods,
which represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the
integrity of the target object, the name of the requested operation, and any other
action needed to perform the function. Messages are often implemented as
procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The
data and operations are linked to a single unit. Encapsulation not only bundles
essential information of an object together but also restricts access to the data and
methods from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where
the lower or sub-classes can import, implement, and re-use allowed variables and
 functions from their immediate superclasses.This property of OOD is called an
inheritance. This makes it easier to define a specific class and to create generalized
classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned the same name. This is known
as polymorphism, which allows a single interface is performing functions for
different types. Depending upon how the service is invoked, the respective portion
of the code gets executed.