Unit II: SOFTWARE PROJECT PLANNING AND SCHEDULING

Software Project Planning and Scheduling: Software Requirement, Software Requirements,

Specification, Requirements Validation, Software Design Principles, Software Project. Estimation:
Size Oriented, Function Oriented, Software Metrics, Software Cost Estimation

Software Requirements

The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements can
be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.

Requirement Engineering

The process to gather the software requirements from client, analyze and document them is
known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –

 Feasibility Study

 Requirement Gathering

 Software Requirement Specification

 Software Requirement Validation

Feasibility study

When the client approaches the organization for getting the desired product developed, it comes
up with rough idea about what all functions the software must perform and which all features are
expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired
system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the
software product can be practically materialized in terms of implementation, contribution of
project to organization, cost constraints and as per values and objectives of the organization. It
explores technical aspects of the project and product such as usability, maintainability,
productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should be
undertaken.

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the client and
end-users to know their ideas on what the software should provide and which features they want
the software to include.

Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from various
stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces, speed of
operation, response time of system, portability of software across various platforms,
maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from client are written in natural language. It is the responsibility of
system analyst to document the requirements in technical language so that they can be
comprehended and useful by the software development team.

SRS should come up with following features:

 User Requirements are expressed in natural language.

 Technical requirements are expressed in structured language, which is used inside the
organization.

 Design description should be written in Pseudo code.

 Format of Forms and GUI screen prints.

 Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document
are validated. User might ask for illegal, impractical solution or experts may interpret the
requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
Requirements can be checked against following conditions

 If they can be practically implemented

 If they are valid and as per functionality and domain of software

 If there are any ambiguities

 If they are complete

 If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the following diagram:

 Requirements gathering - The developers discuss with the client and end users and
know their expectations from the software.

 Organizing Requirements - The developers prioritize and arrange the requirements in

order of importance, urgency and convenience.

 Negotiation & discussion - If requirements are ambiguous or there are some conflicts in
requirements of various stakeholders, if they are, it is then negotiated and discussed with
stakeholders. Requirements may then be prioritized and reasonably compromised. The
requirements come from various stakeholders. To remove the ambiguity and conflicts,
they are discussed for clarity and correctness. Unrealistic requirements are compromised
reasonably.

 Documentation - All formal & informal, functional and non-functional requirements are
documented and made available for next phase processing.

Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake in the
software system development.

There are various ways to discover requirements

Interviews
Interviews are strong medium to collect requirements. Organization may conduct several types
of interviews such as:

 Structured (closed) interviews, where every single information to gather is decided in

advance, they follow pattern and matter of discussion firmly.

 Non-structured (open) interviews, where information to gather is not decided in advance,

more flexible and less biased.

 Oral interviews

 Written interviews

 One-to-one interviews which are held between two persons across the table.

 Group interviews which are held between groups of participants. They help to uncover
any missing requirement as numerous people are involved.

Surveys

Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.

Questionnaires

A document with pre-defined set of objective questions and respective options is handed over to
all stakeholders to answer, which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Task analysis

Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied and
requirements of proposed system are collected.

Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a great
help to analyze general and specific requirements.

Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.
Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no
software installed at client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback serves as an input
for requirement gathering.

Observation

Team of experts visit the client’s organization or workplace. They observe the actual working of
the existing installed systems. They observe the workflow at client’s end and how execution
problems are dealt. The team itself draws some conclusions which aid to form requirements
expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project.
Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

 Clear

 Correct

 Consistent

 Coherent

 Comprehensible

 Modifiable

 Verifiable

 Prioritized

 Unambiguous

 Traceable

 Credible source
Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation
phase and what kinds of requirements are expected from the software system.

Broadly software requirements should be categorized in two categories:

Functional Requirements

Requirements, which are related to functional aspect of software fall into this category.

They define functions and functionality within and from the software system.

Examples -

 Search option given to user to search from various invoices.

 User should be able to mail any report to management.

 Users can be divided into groups and groups can be given separate rights.

 Should comply business rules and administrative functions.

 Software is developed keeping downward compatibility intact.

Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall into this category. They
are implicit or expected characteristics of software, which users make assumption of.

Non-functional requirements include -

 Security

 Logging

 Storage

 Configuration

 Performance

 Cost

 Interoperability

 Flexibility

 Disaster recovery
  Accessibility

Software Design Principles

Software design principles are concerned with providing means to handle the complexity of the
design process effectively. Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors during design.

Problem Partitioning

For small problem, we can handle the entire problem at once but for the significant problem,
divide the problems and conquer the problem it means to divide the problem into smaller pieces
so that each piece can be captured separately.

For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand

2. Software becomes simple

3. Software is easy to test

4. Software is easy to modify

5. Software is easy to maintain

6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the system. They
have to cooperate and communicate to solve the problem. This communication adds complexity.

Abstraction

An abstraction is a tool that enables a designer to consider a component at an abstract level

without bothering about the internal details of the implementation. Abstraction can be used for
existing element as well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction

2. Data Abstraction

Functional Abstraction

i. A module is specified by the method it performs.

ii. The details of the algorithm to accomplish the functions are not visible to the user of the
function.

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis
for Object Oriented design approaches.

Modularity

Modularity specifies to the division of software into separate modules which are differently
named and addressed and are integrated later on in to obtain the completely functional software.
It is the only property that allows a program to be intellectually manageable. Single large
programs are difficult to understand and read due to a large number of reference variables,
control paths, global variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.

o Each module has single specified objectives.

o Modules can be separately compiled and saved in the library.

o Modules should be easier to use than to build.

 o Modules are simpler from outside than inside.

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by
allowing parallel development of various parts of a system. We discuss a different section of
modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that

perform only one kind of task and do not excessively interact with other modules. Independence
is important because it makes implementation more accessible and faster. The independent
modules are easier to maintain, test, and reduce error propagation and can be reused in other
programs as well. Thus, functional independence is a good design feature which ensures software
quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can be
characterized by the design decisions that protect from the others, i.e., In other words, modules
should be specified that data include within a module is inaccessible to other modules that do not
need for such information.

The use of information hiding as design criteria for modular system provides the most significant
benefits when modifications are required during testing's and later during software maintenance.
This is because as most data and procedures are hidden from other parts of the software,
inadvertent errors introduced during modifications are less likely to propagate to different
locations within the software.

Strategy of Design

A good system design strategy is to organize the program modules in such a method that are easy
to develop and latter too, change. Structured design methods help developers to deal with the
size and complexity of programs. Analysts generate instructions for the developers about how
code should be composed and how pieces of code should fit together to form a program.

To design a system, there are two possible approaches:

1. Top-down Approach

2. Bottom-up Approach
1. Top-down Approach: This approach starts with the identification of the main components
and then decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves
towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing system

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 types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of relations
between the modules. That is, the coupling increases as the number of calls between modules
increase or the amount of shared data is large. Thus, it can be said that a design with high coupling
will have more errors.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.
2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.

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

Types of Modules 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.

Software Project Estimation

LOC Metrics

It is one of the earliest and simpler metrics for calculating the size of the computer program. It is
generally used in calculating and comparing the productivity of programmers. These metrics are
derived by normalizing the quality and productivity measures by considering the size of the
product as a metric.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.

2. It is an older method that was developed when FORTRAN and COBOL programming were
very popular.

3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.

 4. Size-oriented metrics depend on the programming language used.

5. As productivity depends on KLOC, so assembly language code will have more

productivity.

6. LOC measure requires a level of detail which may not be practically achievable.

7. The more expressive is the programming language, the lower is the productivity.

8. LOC method of measurement does not apply to projects that deal with visual (GUI-based)
programming. As already explained, Graphical User Interfaces (GUIs) use forms basically.
LOC metric is not applicable here.

9. It requires that all organizations must use the same method for counting LOC. This is so
because some organizations use only executable statements, some useful comments, and
some do not. Thus, the standard needs to be established.

10. These metrics are not universally accepted.

Based on the LOC/KLOC count of software, many other metrics can be computed:

a. Errors/KLOC.

b. $/ KLOC.

c. Defects/KLOC.

d. Pages of documentation/KLOC.

e. Errors/PM.

f. Productivity = KLOC/PM (effort is measured in person-months).

g. $/ Page of documentation.

Advantages of LOC

1. Simple to measure

Disadvantage of LOC

1. It is defined on the code. For example, it cannot measure the size of the specification.

2. It characterizes only one specific view of size, namely length, it takes no account of
functionality or complexity

3. Bad software design may cause an excessive line of code

 4. It is language dependent

5. Users cannot easily understand it

Function Oriented

Function Point Analysis: In this method, the number and type of functions supported by the
software are utilized to find FPC(function point count). The steps in function point analysis are:

 Count the number of functions of each proposed type.

 Compute the Unadjusted Function Points(UFP).

 Find the Total Degree of Influence(TDI).

 Compute Value Adjustment Factor(VAF).

 Find the Function Point Count(FPC).

The explanation of the above points is given below:

 Count the number of functions of each proposed type: Find the number of functions
belonging to the following types:

 External Inputs: Functions related to data entering the system.

 External outputs: Functions related to data exiting the system.

 External Inquiries: They lead to data retrieval from the system but don’t change
the system.

 Internal Files: Logical files maintained within the system. Log files are not
included here.

 External interface Files: These are logical files for other applications which are
used by our system.

 Compute the Unadjusted Function Points(UFP): Categorise each of the five function
types like simple, average, or complex based on their complexity. Multiply the count of
each function type with its weighting factor and find the weighted sum. The weighting
factors for each type based on their complexity are as follows:
 Function type Simple Average Complex

External Inputs 3 4 6

External Output 4 5 7

External Inquiries 3 4 6

Internal Logical Files 7 10 15

External Interface
5 7 10
Files

 Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to find
the degree of influence of each of them. The sum of all 14 degrees of influence will give
the TDI. The range of TDI is 0 to 70. The 14 general characteristics are: Data
Communications, Distributed Data Processing, Performance, Heavily Used Configuration,
Transaction Rate, On-Line Data Entry, End-user Efficiency, Online Update, Complex
Processing Reusability, Installation Ease, Operational Ease, Multiple Sites and Facilitate
Change.
Each of the above characteristics is evaluated on a scale of 0-5.

 Compute Value Adjustment Factor(VAF): Use the following formula to calculate VAF

VAF = (TDI * 0.01) + 0.65

 Find the Function Point Count: Use the following formula to calculate FPC

FPC = UFP * VAF

Advantages:

 It can be easily used in the early stages of project planning.

 It is independent of the programming language.

 It can be used to compare different projects even if they use different

technologies(database, language, etc).
Disadvantages:

 It is not good for real-time systems and embedded systems.

 Many cost estimation models like COCOMO use LOC and hence FPC must be converted to
LOC.