(QNO: 4)

COUPLING and COHESION

COUPLING
It is an indication of the strength of interconnections between program units.
Highly coupled have program units dependent on each other. Loosely coupled are made up of units that are independent or almost
independent.
Modules are independent if they can function completely without the presence of the other. Obviously, can't have modules completely
independent of each other. Must interact so that can produce desired outputs. The more connections between modules, the more
dependent they are in the sense that more info about one modules is required to understand the other module.
Three factors: number of interfaces, complexity of interfaces, type of info flow along interfaces.
Want to minimize number of interfaces between modules, minimize the complexity of each interface, and control the type of info flow. An
interface of a module is used to pass information to and from other modules.
In general, modules tightly coupled if they use shared variables or if they exchange control info.
Loose coupling if info held within a unit and interface with other units via parameter lists. Tight coupling if shared global data.
If need only one field of a record, don't pass entire record. Keep interface as simple and small as possible.
Two types of info flow: data or control.

Passing or receiving back control info means that the action of the module will depend on this control info, which makes it
difficult to understand the module.

Interfaces with only data communication result in lowest degree of coupling, followed by interfaces that only transfer control
data. Highest if data is hybrid.
COHESION
Measure of how well module fits together.
A component should implement a single logical function or single logical entity. All the parts should contribute to the implementation.
Many levels of cohesion:
1. Coincidental cohesion: the parts of a component are not related but simply bundled into a single component.
harder to understand and not reusable.
2. Logical association: similar functions such as input, error handling, etc. put together. Functions fall in same logical class. May
pass a flag to determine which ones executed.
interface difficult to understand. Code for more than one function may be intertwined, leading to severe maintenance problems.
Difficult to reuse
3. Temporal cohesion: all of statements activated at a single time, such as start up or shut down, are brought together. Initialization,
clean up.
Functions weakly related to one another, but more strongly related to functions in other modules so may need to change lots of
modules when do maintenance.
4. Procedural cohesion: a single control sequence, e.g., a loop or sequence of decision statements. Often cuts across functional
lines. May contain only part of a complete function or parts of several functions.
Functions still weakly connected, and again unlikely to be reusable in another product.
5. Communicational cohesion: operate on same input data or produce same output data. May be performing more than one
function. Generally acceptable if alternate structures with higher cohesion cannot be easily identified.
still problems with reusability.

Design Heuristics for Effective Modularity

Once program structure is development effective modularity can be achieved by applying the design concepts illustrated in the previous
section. The program structure can be manipulated according to the following set of heuristics.
1. Obtain the first iteration of the program structure as to reduce coupling and increase cohesion:After developing the program
structure, modules may be exploded or improve module in dependence. An exploded module results in partitioning the logic into separate
program. An imploded module result in the creation of two or more modules.
2. Try to minimize structures with high fan out strive for fan in as depth increases: Try
avoid the pan caked structure in which all the modules are under the control of a single
module as shown in fig 5.23,

to

To avoid such type of pan caked structures a more reasonable distribution of control is required as shown in fig 5.24,
Fig 5.24, shown a number of layers of control
3. Keep the scope of effect of a module within the scope of control of that module: The
scope of a particular module is defined as all modules that are affected by a decision made in
this module. The scope of control of is all the a modules that are subordinate of module.
4. Obtain the module interfaces to reduce complexity and redundancy and improve consistency:Interface designing should be
like so that information can be easily passed and consistent with the function of a module .
5. Define module whose function is predictable but avoid modules that are overly restrictive: A module is predictable when it will
be produced irrespective of the internal functionality. And there should be mush restricted modules that should be avoided.
6. Strive for controlled entry modules by avoiding connections pathological :Software is easier to understand and therefore easier to
maintain when module interfaces are constrained and controlled. Pathological connection refers to branches or references into the
middle of a module.

(Q NO 2 OR)

(A) PROJECT SCHEDULING: The project schedule is the tool that communicates what work needs to be performed, which
resources of the organization will perform the work and the timeframes in which that work needs to be performed. The
project schedule should reflect all of the work associated with delivering the project on time. Without a full and complete
schedule, the project manager will be unable to communicate the complete effort, in terms of cost and resources,
necessary to deliver the project.
Online project management software allows project managers to track project schedules, resources, budgets and project
related assets in real time. The project schedule can be viewed and updated by team members associated with the
project, keeping everyone well informed on the overall project status.
Scheduling is carried out in advance of the project commencing and involves:

identifying the tasks that need to be carried out;

estimating how long they will take;

allocating resources (mainly personnel);

scheduling when the tasks will occur.

(B) COCOMO MODEL: The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed
by Barry W. Boehm. The model uses a basic regression formula with parameters that are derived from historical project data and current
as well as future project characteristics.
It was first published in Boehm's 1981 book Software Engineering Economics[1] as a model for estimating effort, cost, and schedule for
software projects. It drew on a study of 63 projects at TRW Aerospace where Boehm was Director of Software Research and Technology.
The study examined projects ranging in size from 2,000 to 100,000 lines of code, and programming languages ranging
from assembly to PL/I. These projects were based on the waterfall model of software development which was the prevalent software
development process in 1981.
References to this model typically call it COCOMO 81. In 1995 COCOMO II was developed and finally published in 2000 in the
book Software Cost Estimation with COCOMO II.[2] COCOMO II is the successor of COCOMO 81 and is better suited for estimating
modern software development projects. It provides more support for modern software development processes and an updated project
database. The need for the new model came as software development technology moved from mainframe and overnight batch processing
to desktop development, code reusability, and the use of off-the-shelf software components.

(C) Software configuration management (SCM) is a software engineering discipline consisting of standard processes and
techniques often used by organizations to manage the changes introduced to its software products. SCM helps in identifying individual
elements and configurations, tracking changes, and version selection, control, and baselining.
SCM is also known as software control management. SCM aims to control changes introduced to large complex software systems through
reliable version selection and version control.
SCM defines a mechanism to deal with different technical difficulties of a project plan. In a software organization, effective implementation
of software configuration management can improve productivity by increased coordination among the programmers in a team. SCM helps
to eliminate the confusion often caused by miscommunication among team members. The SCM system controls the basic components
such as software objects, program code, test data, test output, design documents, and user manuals.

(D) PROJECT MONITORING PLAN: A project monitoring plan is merely a document that can be used to guide the
execution of a project. Even a good plan is useless unless it is properly executed. And execution cannot be properly driven by the plan
unless it is monitored carefully and the actual performance is tracked against the plan.
Monitoring requires measurements to be made to assess the situation of a project. If measurements are to be taken during project
execution, we must plan carefully regarding what to measure, when to measure, and how to measure. Hence, measurement planning is a
key element in project planning. In addition, how the measurement data will be analyzed and reported must also be planned in advance to
avoid the situation of collecting data but not knowing what to do with it. Without careful planning for data collection and its analysis, neither
is likely to happen. In this section we discuss the issues of measurements and project tracking.

(Q No 3 OR)

cohesive module & Types of Cohesion

In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is
a measure of how strongly related each piece of functionality expressed by the source code of a software module is.
Cohesion is an ordinal type of measurement and is usually described as high cohesion or low cohesion. Modules with
high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software
includingrobustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable
traits such as being difficult to maintain, test, reuse, and even understand.

Coincidental cohesion:
A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other very loosely, if at all.
In this case, the module contains a random collection of functions. It is likely that the functions have been put in the
module out of pure coincidence without any thought or design. For example, in a transaction processing system (TPS),
the get-input, print-error, and summarize-members functions are grouped into one module. The grouping does not have
any relevance to the structure of the problem.
Logical cohesion:
A module is said to be logically cohesive, if all elements of the module perform similar operations, e.g. error handling,
data input, data output, etc. An example of logical cohesion is the case where a set of print functions generating
different output reports are arranged into a single module.
Temporal cohesion:
When a module contains functions that are related by the fact that all the functions must be executed in the same time
span, the module is said to exhibit temporal cohesion. The set of functions responsible for initialization, start-up,
shutdown of some process, etc. exhibit temporal cohesion.
Procedural cohesion:
A module is said to possess procedural cohesion, if the set of functions of the module are all part of a procedure
(algorithm) in which certain sequence of steps have to be carried out for achieving an objective, e.g. the algorithm for
decoding a message.
Communicational cohesion:
A module is said to have communicational cohesion, if all functions of the module refer to or update the same data
structure, e.g. the set of functions defined on an array or a stack.
Sequential cohesion:
A module is said to possess sequential cohesion, if the elements of a module form the parts of sequence, where the
output from one element of the sequence is input to the next. For example, in a TPS, the get-input, validate-input, sortinput functions are grouped into one module.
Functional cohesion:
Functional cohesion is said to exist, if different elements of a module cooperate to achieve a single function. For
example, a module containing all the functions required to manage employees pay-roll exhibits functional cohesion.
Suppose a module exhibits functional cohesion and we are asked to describe what the module does, then we would be
able to describe it using a single sentence.