Dept of Computer Science and Engineering

CML

Module 2 Topics

1. Management: Functions
2. Project planning - Software productivity -Productivity metrics
3. Cost estimation - COCOMO & COCOMO II
4. Project control - Work breakdown structures, Gantt charts, PERT charts - Dealing with
deviations
5. Team organization - centralized, de-centralized, mixed - An assessment of organizations
6. Risk management
7. Configuration Management
8. Introduction to project management and planning CASE tools.
1. Management: Functions
1.1 Management Functions
i.

Software engineering projects involve many software engineers.

ii.

Management is needed to coordinate the activities and resources involved in projects.

iii.

The main job of Management is to enable a group of people to work towards a common goal.

iv.

Management Functions can be broadly divided into these interrelated activities, the goal of which is to
achieve effective group work :1. Planning
2. Organizing
3. Staffing
4. Directing
5. Controlling

1. Planning
Planning involves determining the flow of information, people and products within the organization.
A Manager must decide what objectives are to be achieved , what resources are required to achieve the
objectives, how and when the resources are to be acquired , and how the objective are to be achieved.
2. Organizing
Organizing involves the establishment of clear lines of authority and responsibility for groups of activities
that achieve achieve the goals of the enterprise.
Organizing is necessary at the level of small group.
Choice of organizational structure affects the efficiency of enterprise.
3. Staffing
Staffing deals with hiring personnel for the positions that are identified by the organizational structure.
Staffing involves defining the requirements for personnel; recruiting and compensating , developing and
promoting employees.

4. Directing
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:1
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Goal of directing is to guide the subordinates to undersatand and identify with the organizational structure and
goals of the enterprise.
Directing involves leading subordinates.
5. Controlling
Controlling consists of measuring and correcting activities to ensure that goals are achieved.

Controlling requires the measurement of performance against plans and taking corrective action when
deviations occur.

2. Project planning
Software project planning encompasses five major activities:1. Estimation
2. Scheduling
3. risk analysis
4. quality management planning
5. change management planning
Estimation determines how much money, effort, resources, and time it will take to build a specific system
or product
The software team first estimates
o The work to be done
o The resources required
o The time that will elapse from start to finish
Then they establish a project schedule that
o Defines tasks and milestones
o Identifies who is responsible for conducting each task
o Specifies the inter-task dependencies
Task Set for Project Planning:1. Establish project scope
2. Determine feasibility
3. Analyze risks
4. Define required resources
a. Determine human resources required
b. Define reusable software resources
c. Identify environmental resources
5. Estimate cost and effort
a. Decompose the problem
b. Develop two or more estimates using different approaches
c. Reconcile the estimates
6. Develop a project schedule
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:2
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

a. Establish a meaningful task set

b. Define a task network
c. Use scheduling tools to develop a timeline chart
d. Define schedule tracking mechanisms
1. Establish project scope
The first activity in software project planning is the determination of software scope. Function and
performance allocated to software during system engineering should be assessed to establish a project
scope that is unambiguous and understandable at the management and technical levels. A statement of
software scope must be bounded. Software scope describes the data and control to be processed,
function, performance, constraints, interfaces, and reliability. Functions described in the statement of
scope are evaluated and in some cases refined to provide more detail prior to the beginning of
estimation.
2. Define required resources
The second software planning task is estimation of the resources required to accomplish the software
development effort. Figure 5.2 illustrates development resources as a pyramid. Three major categories
of software engineering resources
1. Human Resources
2. Development environment
3. Reusable software components

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:3
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

1. Human Resources
The planner begins by evaluating scope and selecting the skills required to complete development. Both
organizational

position

(e.g.,

manager,

senior

software

engineer)

and

specialty

(e.g.,

telecommunications, database, client/server) are specified. For relatively small projects (one personyear or less), a single individual may perform all software engineering tasks, consulting with specialists
as required.
2. Reusable Software Resources
Component-based software engineering (CBSE) emphasizes reusabilitythat is, the creation and reuse
of software building blocks. Such building blocks, often called components, must be cataloged for easy
reference, standardized for easy application, and validated for easy integration. Bennatan suggests four
software resource categories that should be considered as planning proceeds:
Off-the-shelf components-Existing software that can be acquired from a third party or that has been
developed internally for a past project. COTS (commercial off-the-shelf) components are purchased
from a third party, are ready for use on the current project, and have been fully validated.
Full-experience components-Existing specifications, designs, code, or test data developed for past
projects that are similar to the software to be built for the current project. Members of the current
software team have had full experience in the application area represented by these components.
Therefore, modifications required for full-experience components will be relatively low-risk.
Partial-experience components- Existing specifications, designs, code, or test data developed for past
projects that are related to the software to be built for the current project but will require substantial
modification. Members of the current software team have only limited experience in the application
area represented by these components. Therefore, modifications required for partial-experience
components have a fair degree of risk.
New components-Software components that must be built by the software team specifically for the
needs of the current project.
3. Environmental Resources
The environment that supports the software project, often called the software engineering environment
(SEE), incorporates hardware and software. Hardware provides a platform that supports the tools
(software) required to produce the work products that are an outcome of good software engineering
practice.
3. Estimation of Project Cost and Effort
The accuracy of a software project estimate is predicated on
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:4
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

o The degree to which the planner has properly estimated the size (e.g., KLOC) of the product to be built
o The ability to translate the size estimate into human effort, calendar time, and money
o The degree to which the project plan reflects the abilities of the software team
o The stability of both the product requirements and the environment that supports the software
engineering effort
Project Estimation Approaches are:a) Decomposition techniques
o These take a "divide and conquer" approach
o Cost and effort estimation are performed in a stepwise fashion by breaking down a project into major
functions and related software engineering activities.
b) Empirical estimation models
o Offer a potentially valuable estimation approach if the historical data used to seed the estimate is
good
4. Develop a project schedule
Software project scheduling is an activity that distributes estimated effort across the planned project
duration by allocating the effort to specific software engineering tasks. It is important to note, however, that the
schedule evolves over time. During early stages of project planning, a macroscopic schedule is developed. This
type of schedule identifies all major software engineering activities and the product functions to which they are
applied. As the project gets under way, each entry on the macroscopic schedule is refined into a detailed
schedule. Here, specific software tasks (required to accomplish an activity) are identified and scheduled.
principles guide software project scheduling:
I.

Compartmentalization-The project must be compartmentalized into a number of manageable activities

and tasks.

II.

Interdependency-The interdependency of each compartmentalized activity or task must be determined.

Some tasks must occur in sequence while others can occur in parallel.

III.

Time allocation-Each task to be scheduled must be allocated some number of work units.

IV.

Effort validation-Every project has a defined number of staff members. As time allocation occurs, the
project manager must ensure that no more than the allocated number of people have been scheduled at any
given time.

V.

Defined responsibilities-Every task that is scheduled should be assigned to a specific team member.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:5
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

VI.
VII.

CML

Defined outcomes-Every task that is scheduled should have a defined outcome.

Defined milestones-Every task or group of tasks should be associated with a project milestone. A
milestone is accomplished when one or more work products has been reviewed for quality and has been
approved.
----------------------------------------------------------------------------------------------------------------------------2.1 Software productivity
Software Productivity can be measured in different ways. Software engineers spent up to half
their time spent in meetings, administrative matters and communication with team members. But
its important that productivity of the people and processes involved in software production is
measured.
2.1.1 Productivity metrics
An ideal productivity metric measure not lines of code, but the amount of value or functionality
produced per unit time. The problem that we have is no good way of quantifying the concept of
functionality. Because of the difficulty of the quantifying functionality , the search for a
productive metric has for the most part concentrated on the most tangible product of software
engineering; the actual code produced by the engineer. Uses of software product metrics are: Help software engineers to better understand the attributes of models and assess the quality of the
software
Help software engineers to gain insight into the design and construction of the software
Focus on specific attributes of software engineering work products resulting from analysis, design,
coding, and testing
Provide a systematic way to assess quality based on a set of clearly defined rules
Provide an on-the-spot rather than after-the-fact insight into the software development
Measurement Principles
Following are the measurement principles are:Formulation- The derivation (i.e., identification) of software measures and metrics appropriate
for the representation of the software that is being considered
Collection- The mechanism used to accumulate data required to derive the formulated metrics
Analysis-The computation of metrics and the application of mathematical tools

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:6
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Interpretation-The evaluation of metrics in an effort to gain insight into the quality of the
representation
Feedback-Recommendations derived from the interpretation of product metrics and passed on to
the software development team.
Attributes of Effective Software Metrics
Attributes of Effective Software Metrics are:Simple and computable- It should be relatively easy to learn how to derive the metric, and its
computation should not demand inordinate effort or time
Empirically and intuitively persuasive- The metric should satisfy the engineers intuitive
notions about the product attribute under consideration
Consistent and objective- The metric should always yield results that are unambiguous.
Consistent in the use of units and dimensions- The mathematical computation of the metric
should use measures that do not lead to bizarre combinations of units.
Programming language independent- Metrics should be based on the analysis model, the
design model, or the structure of the program itself.
An effective mechanism for high-quality feedback- The metric should lead to a higher-quality
end product.
DIFFERENT KINDS OF PRODUCTIVITY METRICS ARE:1. Metrics for Requirements Model (Analysis Model)
Metrics for Requirements Model are:(i) Function Point-based metrics
1) Use the function point as a normalizing factor or as a measure of the size of the specification.
2) First proposed by Albrecht in 1979
3) Can be used effectively as a means for measuring the functionality delivered by a system
4) Derived using an empirical relationship based on
i. Countable (direct) measures of the softwares information domain.
ii. Assessments of the softwares complexity
5) Information domain values are defined in the following manner:
i. number of external inputs (EIs)
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:7
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

ii. number of external outputs (EOs)

iii. number of external inquiries (EQs)
iv. number of internal logical files (ILFs)
v. number of external interface files (EIFs)
vi. number of external inputs (EIs)
vii. number of external outputs (EOs)
6) Function Point Computation
i. Identify/collect the information domain values
ii. Complete the table shown below to get the count total.
a. Associate a weighting factor (i.e., complexity value) with each count based on criteria established
by the software development organization
b. Evaluate and sum up the value adjustment factors (VAF)
c. Fi refers to 14 value adjustment factors, with each ranging in value from 0 (not important) to 5
(absolutely essential).
d. Compute

the

number

of

function

points

(FP)

FP = count total * [0.65 + 0.01 * sum(Fi)]

Figure:-Computing Function Points

Fi are Value Adjustment Factors

based on responses to the following questions. Each of the

questions is answered using a scale from 0 to 5:1)

Does the system require reliable backup and recovery?

2)

Are specialized data communications required to transfer information to or from the

application?

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:8
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

3)

Are there distributed processing functions?

4)

Is performance critical?

5)

Will the system run in an existing, heavily utilized operational environment?

6)

Does the system require on-line data entry?

7)

Does the on-line data entry require the input transaction to be built over multiple screens or
operations?

8)

Are the internal logical files updated on-line?

9)

Are the inputs, outputs, files, or inquiries complex?

10)

Is the internal processing complex?

11)

Is the code designed to be reusable?

12)

Are conversion and installation included in the design?

13)

Is the system designed for multiple installations in different organizations?

14)

Is the application designed to facilitate change and for ease of use by the user?
Example
SafeHome security Software
The SafeHome security function enables the homeowner to configure the security system when it
is installed, monitors all sensors connected to the security system, and interacts with the
homeowner through the Internet, a PC, or a control panel. During installation, the SafeHome PC
is used to program and configure the system. Each sensor is assigned a number and type, a
master password is programmed for arming and disarming the system, and telephone number(s)
are input for dialing when a sensor event occurs.When a sensor event is recognized, the software
invokes an audible alarm attached to the system. After a delay time that is specified by the
homeowner during system configuration activities, the software dials a telephone number of a
monitoring service, provides information about the location, reporting the nature of the event that
has been detected. The telephone number will be redialed every 20 seconds until a telephone
connection is obtained. The homeowner receives security information via a control panel, the
PC, or a browser, collectively called an interface. The interface displays prompting messages and
system status information on the control panel, the PC, or the browser window.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:9
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Figure:- Data flow diagram evaluated to determine the key measures required for computation of
the function point metric
number of user inputs - password, panic button, and activate/deactivate
number of user outputs - messages and sensor status
number of user inquiries - zone inquiry and sensor inquiry
number of files - system configuration file
number of external interfaces - test sensor, zone setting, activate/deactivate, and alarm alert

FP = count total * [0.65 + 0.01 * sum(Fi)]

FP = 50 * [0.65 + (0.01 * 46)]
FP = 55.5 (rounded up to 56)
where count total is the sum of all FP entries and Fi (i = 1 to 14) are "complexity adjustment
values." For the purposes of this example, we assume that S (Fi) is 46 (a moderately complex
product).
Project team can estimate the overall implemented size of the SafeHome user interaction
function.
Assume:

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:10
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Past data indicates that one FP translates into 60 lines of code (an object-oriented language
is to be used)
12 FPs are produced for each person-month of effort.
Assume:
Past projects have found an average of three errors per function point during analysis
design reviews.
Four errors per function point during unit and integration testing.
These data can help software engineers assess the completeness of their review and testing
activities.
(ii)

Specification metrics
b. used as an indication of quality by measuring number of requirements by type.
c. A list of characteristics that can be used to assess the quality of the analysis model and the
corresponding requirements specification:

specificity (lack of ambiguity), completeness, correctness, understandability, verifiability,

internal and external consistency, achievability, concision, traceability, modifiability, precision,
and reusability. we assume that there are nr requirements in a specification, such that
nr = nf + nnf
where nf is the number of functional requirements and nnf is the number of nonfunctional .

d. we assume that there are nr requirements in a specification, such that

nr = nf + nnf
where nf is the number of functional requirements and nnf is the number of nonfunctional .
e. SPECIFICITY (lack of ambiguity) of requirements, a metric that is based on the consistency of
the reviewers interpretation of each requirement:
Q1 = nui/nr
where nui is the number of requirements for which all reviewers had identical interpretations. The
closer the value of Q to 1, the lower is the ambiguity of the specification.
f. COMPLETENESS of functional requirements can be determined by computing the ratio
Q2 = nu/[ni X ns ]

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:11
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

where nu is the number of unique function requirements, ni is the number of inputs (stimuli)
defined or implied by the specification, and ns is the number of states specified. The Q2 ratio
measures the percentage of necessary functions that have been specified for a system.
g. we must consider the degree to which requirements have been validated:
Q3 = nc/[nc + nnv ]
where nc is the number of requirements that have been validated as correct and nnv is the
number of requirements that have not yet been validated.
2. Metrics for design Model

Architectural Design Metrics- Architectural design metrics focus on characteristics of the

program architecture with an emphasis on the architectural structure and the effectiveness of
modules.

Fan out: the number of modules immediately subordinate to the module i, that is, the
number of modules directly invoked by module i

Structural complexity
S(i) = f2out(i), where fout(i) is the fan out of module i

Data complexity
D(i) = v(i)/[fout(i) + 1], where v(i) is the number of input and output variables that
are passed to and from module i

System complexity
C(i) = S(i) + D(i)

As each of these complexity values increases, the overall architectural complexity of the
system also increases. This leads to greater likelihood that the integration and testing effort will
also increase .

Shape complexity- size = n + a, where n is the number of nodes and a is the number of arcs.
Allows different program software architectures to be compared in a straightforward manner

Connectivity density (i.e., the arc-to-node ratio) , r = a/n . It may provide a simple
indication of the coupling in the software architecture. size = 17 + 18 = 35
depth = the longest path from the root (top) node to a leaf node. For the architecture shown in
Figure 19.5, depth = 4. width = maximum number of nodes at any one level of the architecture.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:12
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

3.

CML

Metrics for Testing

Testing metrics fall into two broad categories: (1) metrics that attempt to predict the likely
number of tests
required at various testing levels and (2) metrics that focus on test coverage for a given
component. For example, the number of tests associated with the human/computer interface can
be estimated by (1) examining the number of transitions (TR) contained in the state transition
representation of the HCI and evaluating the tests required to exercise each transition; (2)
examining the number of data objects (OB) that move across the interface, and (3) the number of
data elements that are input or output.
4.

Metrics for Maintenance

Metrics designed explicitly for maintenance activities have been proposed. IEEE suggests a
software maturity index (SMI) that provides an indication of the stability of a software product
(based on changes that occur for each release of the product). The following information is
determined:
MT = the number of modules in the current release
Fc = the number of modules in the current release that have been changed
Fa = the number of modules in the current release that have been added
Fd = the number of modules from the preceding release that were deleted in the current release
The software maturity index is computed in the following manner:
SMI = [MT -(Fa + Fc + Fd)]/MT
-------------------------------------------------------------------------------------------------------------------------

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:13
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Cost estimation - COCOMO & COCOMO II

Cost Estimation is a part of the planning stage of engineering activity.

Software cost estimation has two uses in software project management:o For developing a schedule for the project.
o To monitor projects progress according to schedule.
Two widely used Cost estimation models are:1.1 COCOMO (Constructive Cost Model)
1.2 COCOMO II (Constructive Cost Model II)
1.1 COCOMO (Constructive Cost Model)
i. The COstructive COst Model (COCOMO) is the most widely used software estimation model in the
world.
ii. The COCOMO model predicts the effort and duration of a project based on inputs relating to the size of
the resulting systems and a number of "cost drives" that affect productivity.
iii. COCOMO model was developed by Boehm.
iv. Its a top-down multi-variable model. The model calculates the effort in terms of person-months.
v. The steps are:
Step 1
Obtain an initial estimate of the development effort from the estimate of thousands of delivered lines of
source code (KDLOC).
Step 2
Determine a set of 15 multiplying factors from different attributes of the project.
Step 3
Adjust the effort estimate by multiplying the initial estimate with all the multiplying factors.
Step 1
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 size.
To determine the initial effort Ei in person-months, the equation used is of the type
Ei = a * (KDLOC) b
The value of the constants a and b depend on the project type.
In COCOMO, projects are categorized into three types organic, semidetached, and embedded.
Organic projects are in an area in which the organization has considerable experience and
requirements are less stringent. Such systems are usually developed by a small team. Examples of
this type of project are simple business systems, simple inventory management systems, and data
processing systems. Projects of the embedded type are ambitious and novel; the organization has

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:14
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

little experience and stringent requirements for such aspects as interfacing and reliability. These
systems have tight constraints from the environment (software, hardware, and people). Examples
are embedded avionics systems and real-time command systems. The semidetached systems fall
between these two types. Examples of semidetached systems include developing a new operating
system (OS), a database management system (DBMS), and a complex inventory management
system. The constants a and b for different systems are given in Table 3.1.

Table 3.1:- a and b values for three different systems

Step 2
There are 15 different attributes, called cost driver attributes that determine the multiplying factors.
These factors depend on product, computer, personnel, and technology attributes (called project attributes).
Examples of the attributes are, required software reliability (RELY), product complexity (CPLX), analyst
capability (ACAP), application experience (AEXP), use of modern tools (TOOL), and required
development schedule (SCHD).
Each cost driver has a rating scale, and for each rating, a multiplying factor is provided. For example, for
the product attribute RELY, the rating scale is very low, low, nominal, high, and very high (and in some
cases, extra high). The multiplying factors for these ratings are .75, .88, 1.00, 1.15, and 1.40, respectively.
So, if the reliability requirement for the project is judged to be low then the multiplying factor is .75, while
if it is judged to be very high the factor is 1.40.
The attributes and their multiplying factors for different ratings are shown in Table 3.2.
The multiplying factors for all 15 cost drivers are multiplied to get the effort adjustment factor (EAF).

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:15
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Table 3.2 Effort multipliers for different cost drivers.

Step 3
The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF:
E = EAF * Ei
Example
Suppose, a system for office automation must be designed. From the requirements, it was clear that there
would be four major modules in the system: data entry, data update, query, and report generator. It is also clear
from the requirements that project will fall in the organic category. The sizes for the different modules and the
overall system were estimated to be as follows:

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:16
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

From the requirements, the ratings of the different cost driver attributes were assessed. These ratings, along
with their multiplying factors, are:

All other factors had a nominal rating. From these, the effort adjustment factor (EAF) is
EAF=1.15 * 1.06 * 1.13 * 1.17 =1.61.
The initial effort estimate for the project is obtained from the relevant equations. We have:Ei = 3.2*31.05 = 10.14 PM.( Ei = a * (KDLOC) b, since project is organic in nature a=3.2 and b=1.05)
Using the EAF, the adjusted effort estimate is
E =1.61 * 10.14 = 16.3 PM (E=EAF * Ei)
COCOMO II (Constructive Cost Model II)
COCOMO II is actually a hierarchy of estimation models that address the following areas:
i.

Application composition model. Used during the early stages of software engineering, when
prototyping of user interfaces, consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are paramount.

ii.

Early design stage model. Used once requirements have been stabilized and basic software
architecture has been established.

iii.

Post-architecture-stage model. Used during the construction of the software.

Like all estimation models for software, the COCOMO II models require sizing information.
Three different sizing options are available as part of the model hierarchy: object points, function points, and
lines of source code.
Like function points , the object point is an indirect software measure that is computed using counts of the
number of
(1) screens (at the user interface)
(2) reports
(3) components likely to be required to build the application.
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:17
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Each object instance (e.g., a screen or report) is classified into one of three complexity levels (i.e., simple,
medium, or difficult) using criteria suggested by Boehm. In essence, complexity is a function of the number
and source of the client and server data tables that are required to generate the screen or report and the
number of views or sections presented as part of the screen or report.
Once complexity is determined, the number of screens, reports, and components are weighted according to
Table 5.1. The object point count is then determined by multiplying the original number of object instances
by the weighting factor in Table 5.1 and summing to obtain a total object point count.

When component-based development or general software reuse is to be applied, the percent of reuse (%reuse)
is estimated and the object point count is adjusted:
NOP = (object points) x [(100 - %reuse)/100]
where NOP is defined as new object points.
To derive an estimate of effort based on the computed NOP value, a productivity rate must be derived.
Table 5.2 presents the productivity rate, PROD = NOP/person-month.

For different levels of developer experience and development environment maturity.Once the productivity
rate has been determined, an estimate of project effort can be derived as
estimated effort = NOP/PROD

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:18
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

-----------------------------------------------------------------------------------------------------------------------------Project control - Work breakdown structures, Gantt charts, PERT charts - Dealing with deviations
5.1 Project Control
The purpose of controlling a project is to monitor the progress of the activities against the plans.
Another aspect of control is to detect, deviations from the plan are occuring so that corrective action
may be taken.
5.2 Work breakdown structures (TASK NETWORK)
WBS is used as a basis for a number of processes in particular to produce the subsidiary plans of the
Project Management Plan.
The WBS is a deliverable-oriented hierarchy of decomposed project components that organises and
defines the total scope of the project.
The WBS is a representation of the detailed project scope statement that specifies the work to be
accomplished by the project.
The elements comprising the WBS assist the stakeholders in viewing the end product of the project.
The work at the lowest-level WBS component is estimated, scheduled, and tracked.
Work Breakdown Structures are also known as Task Network. The task network is a useful mechanism
for depicting intertask dependencies and determining the critical path.
Individual tasks and subtasks have interdependencies based on their sequence.
A task network, also called an activity network, is a graphic representation of the task flow for a project.
It is sometimes used as the mechanism through which task sequence and dependencies are input to an
automated project scheduling tool. In its simplest form (used when creating a macroscopic schedule),
the task network depicts major software engineering tasks.
Figure 7.3 shows a schematic task network for a concept development project. Figure 7. 4 shows an
Example task Network. Figure 7.5 shows an Example Task Network with Critical Path Marked. It
depicts task length, sequence, concurrency, and dependency. Points out inter-task dependencies to help
the manager ensure continuous progress toward project completion.
The details of critical path are:
A single path leading from start to finish in a task network.
It contains the sequence of tasks that must be completed on schedule if the project as a whole is to be
completed on schedule.
It also determines the minimum duration of the project.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:19
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Figure 7.4 Example Task Network

Figure 7.5 Example Task Network with Critical Path Marked

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:20
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

5.3 Gantt Chart

A Gantt chart also known as time-line chart is a type of bar chart, developed by Henry Gantt that illustrates a
project schedule. Gantt chart features are: A timeline chart can be developed for the entire project. Separate charts can be developed for
each project function or for each individual working on the project.
Figure(i) illustrates the format of a timeline chart. It depicts a part of a software project schedule
that emphasizes the concept scoping task for a new word-processing (WP) software product.
All project tasks are listed in the left-hand column, horizontal bars indicate the duration of
each task and diamonds indicate milestones.
When multiple bars occur at the same time on the calendar, task concurrency is implied.
Once the information necessary for the generation of a timeline chart has been input, the
majority of software project scheduling tools produce project tablesa tabular listing of all
project tasks, their planned and actual start- and end-dates, and a variety of related information.

Figure(i) An example of Timeline chart

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:21
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

5.4 PERT charts

Program evaluation and review technique (PERT) and critical path method (CPM) are two project
scheduling methods that can be applied to software development.
PERT chart is a network of boxes(or circles) and arrows.
Each box represents an activity. Arrows are used to show the dependencies of activities on one another.
The activity at the head of an arrow cannot start until the activity at the tail; of the arrow is finished.
Some boxes can be designated as Milestones. A milestone is an activity whose completion signals an
importatnt accomplishment in the life of the project.
Figure 5.3 shows a PERT chart for the compiler project.
The Figure asumes that the project will start on January1.Taking holidays into account , we see that the
design work will start on January 3. Since the design activity is estimated to take 45 days, any activity
that follows the design may start on March7 at the earliest. The dependecy arrows help us compute
these earliest start dates on the basis of our estimates of the duration of each activity.
Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the
project work breakdown structure (WBS), are defined for the product as a whole or for individual
functions.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:22
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

March 7
build
scanner
Jan 1
start

Jan 3
design

March 7
build
parser

Nov 14
integration
and testing

March 7
build code
generator

finish
Mar 17+

March 7
write
manual
Figure 5.3 PERT chart for the compiler project.
Salient features of PERT chart are:i.

It forces and helps managet to plan.

ii.

It shows the interrelationship among the tasks in the project and identifies the critical path of the
project.

iii.

It exposes all possible parallelism in the activities and thus helps in allocating resources.

iv.

It allows scheduling and simulation of alternative schedules.

v.

It enables the manger to monitor and contril the project.

PERT provide quantitative tools that allow the software planner to:(1)determine the critical paththe chain of tasks that determines the duration of the project.
(2)establish most likely time estimates for individual tasks by applying statistical models.
(3)calculate boundary times that define a time "window" for a particular task.
Boundary time calculations can be very useful in software project scheduling. Slippage in the design of one
function, for example, can retard further development of other functions. Riggs describes important
boundary times that may be discerned from a PERT or CPM network:

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:23
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

(1) the earliest time that a task can begin when all preceding tasks are completed in the shortest
possible time.
(2) the latest time for task initiation before the minimum project completion time is delayed.
(3) the earliest finishthe sum of the earliest start and the task duration.
(4) the latest finishthe latest start time added to task duration.
(5) the total floatthe amount of surplus time or leeway allowed in scheduling tasks so that the
network critical path is maintained on schedule. Boundary time calculations lead to a
determination of critical path and provide the manager with a quantitative method for evaluating
progress as tasks are completed.
Both PERT and CPM have been implemented in a wide variety of automated tools that are available for
the personal computer. Such tools are easy to use and make the scheduling methods described
previously available to every software project manager.
5.5 Dealing with deviations
Dealing with deviation deals with deviation from the project plan.
The manager should consult the chart at frequent intervals during the project to evaluate its status.
No matter how the deviations from the schedule are detected, the manager must decide how to handle them.
In activities where production is limited by raw human labor, it is usual to try to get back on schedule by
adding people or increasing overtime for existing people.
The manager has to examine the requirements and remove the ones that are not absolutely necessary.
Cutting out unecessary requirements is called requirements scrubbing.
-------------------------------------------------------------------------------------------------------------------------------Team organization - centralized, de-centralized, mixed - An assessment of organizations
Team organization structure is used to structure the communication patterns among members of a team.
Traditional team organization is hierarchical with a manager supervising a group or groups of groups.
Other organizations have been tried in software engineering with some success.
Kinds of Team Organization are:1. Controlled Centralized(CC) or Chief-programmer team
2. Democratic decentralized (DD)
3. Controlled decentralized (CD) or Mixed Control Team Organization
1. Controlled Centralized(CC) or Chief-programmer team
i.

In Controlled Centralized there is a Chief Programmer(CF) who is the Team Leader.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:24
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

ii.

Top-level problem solving and internal team coordination are managed by a team leader.

iii.

Team Leader is responsible for:a. Top-level problem solving.

b. For administration
c. Internal team coordination.
d. Plans, coordinates and reviews all technical activities of team.
e. Analysis and development activities.

iv.

Communication between the leader and team members is vertical.

v.

Chief Programmer is supported by more people such as:a. Telecommunication Expert

b. Database Engineer
c. Technical writer
d. Clerical Personne
e. Software Librarian

Chief programmer

Librarian

Programmers

Specialists

Figure:- Structure of Chief Programmers Team

vi. Software Librarian functions are:
1. Maintains and control all elements of software configuration.
2. Helps tp collect and format software productivity data.
3. Assist team in research,evaluation and document preparation.
4. Librarian acts as controller, coordinator and evaluation of software.
vii. Advantages of Controlled Centralized(CC) or Chief-programmer team are:a) Completes task faster.
b)Suitable for handling simple problems.
viii. Disadvantages of Controlled Centralized(CC) or Chief-programmer team are:a) Single point of failure may occur because too much responsibility and authority to Chief Programmer.
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:25
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

2. Democratic decentralized (DD) team

i.

This software engineering team has no permanent leader. Rather, "task coordinators are appointed for
short durations and then replaced by others who may coordinate different tasks."

ii. Decisions on problems and approach are made by group consensus.

iii. Communication among team members is horizontal.
iv. Members review each others work and are responsible as a group for what every member produces.
v. This team doesnt have any team hierarchy.At different time, different members of group provide
technical leadership.
vi. Advantages of Democratic decentralized (DD) team are:a) Appropriate for less understood problems since group of engineers can invent better solutions than
single individuals as in a Chief programmers team.
vii. Disadvantages of Democratic decentralized (DD) team are:a) It can be applied to low modularity projects only because a high volume of communication is needed.

(a )

(b )

Figure 2(a) Management Structure of Democratic decentralized team and 2(b) communication pattern in DD team

3. Controlled decentralized (CD) or Mixed-Control Team Organization

i.

This software engineering team has a defined leader who coordinates specific tasks and secondary
leaders that have responsibility for subtasks.

ii.

Attempts to combine the benefits of centralized and decentralized control

iii.

Differentiates engineers into senior and junior.

iv.

Senior engineer leads a group of juniors and reports to a project manager

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:26
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

v.

Control vested in the project manager and senior programmers

vi.

Communication decentralized among each set of individuals, peers, and their immediate supervisors

vii.

Problem solving remains a group activity, but implementation of solutions is partitioned among
subgroups by the team leader.

viii.

Communication among subgroups and individuals is horizontal. Vertical communication along the
control hierarchy also occurs.
Proj ect mana ger

Se nio r en gi nee rs

Ju ni or e ngi ne ers

(a )

(b )

Figure 3(a) Management structure of Mixed control team (b) communication pattern in Mixed control team
1.1

An assessment of organizations
We must content with the following general considerations:1. No team organization is appropriate for all tasks.
2. Decentralized control is best when communication is necessary to achieve a good solution
3. Centralized control best when development speed is key and problem is well understood.
4. An appropriate organization limits the amount of communication to what is necessary to achieve the
goalsno more and no less.
5. An appropriate organization may have to take acount goals other than speed of development.

-------------------------------------------------------------------------------------------------------------------------------Risk management
A risk is a potential problem it might happen and it might not. Conceptual definition of risk: Risk concerns future happenings

Risk involves change in mind, opinion, actions, places, etc.

Risk involves choice and the uncertainty that choice entails

Two characteristics of risk

Uncertainty the risk may or may not happen, that is, there are no 100% risks (those,
instead, are called constraints)

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:27
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Loss the risk becomes a reality and unwanted consequences or losses occur

Reactive risk strategies

"Don't worry, I'll think of something"

The majority of software teams and managers rely on this approach

Nothing is done about risks until something goes wrong

The team then flies into action in an attempt to correct the problem rapidly (fire fighting)

Crisis management is the choice of management techniques

Proactive risk strategies

Steps for risk management are followed (see next slide)

Primary objective is to avoid risk and to have a contingency plan in place to handle
unavoidable risks in a controlled and effective manner.

Steps for Risk Management

1. Identify possible risks; recognize what can go wrong
2. Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that
it will do if it does occur
3. Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and catastrophic
4. Develop a contingency plan to manage those risks having high probability and high impact.Risk
Mitigation, Monitoring, and Management.
1. Risk identification
It is a systematic attempt to specify threats to the project plan. By identifying known and
predictable risks, the project manager takes a first step toward avoiding them when possible and
controlling them when necessary.
Generic risks
Risks that are a potential threat to every software project
Product-specific risks
Risks that can be identified only by those a with a clear understanding of the technology, the
people, and the environment that is specific to the software that is to be built
This requires examination of the project plan and the statement of scope
"What special characteristics of this product may threaten our project plan?"
Risk Item Checklist
It is used as one way to identify risks. Focuses on known and predictable risks in specific
subcategories . Can be organized in several ways
A list of characteristics relevant to each risk subcategory
Questionnaire that leads to an estimate on the impact of each risk
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:28
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

A list containing a set of risk component and drivers and their probability of occurrence.
Categories of risk or Components of risk:

Performance Risk
The degree of uncertainty that the product will meet its requirement and be fit for its
intended use.

Cost Risk(CU)
The degree of uncertainty that the project budget will be maintained.

Support Risk
The degree of uncertainty that whether the project is easy to correct, adapt and enchance.

Schedule Risk
The degree of uncertainty that the project schedule will be maintained and that the product
will be delivered on time.

Product Size Risk(PS)

Risk associated with overall size of the software to be built or modified.

Business Impact Risk(BU)

Risks associated with constraints imposed by management.

Technology to built risk(TE)

Risks associated with complexity of system to be built.

Development environment Risk(DE)

Risks associated with the availability and quality of the tools to be used to build the
product.

Staff and Experience Risk(ST)

Risks associated with the overall technical and project experience of the software engineers
who will do the work.

2. Risk Projection (Estimation)

Risk projection (or estimation) attempts to rate each risk in two ways
a. The probability that the risk is real
b. The consequence of the problems associated with the risk, should it occur
The project planner, managers, and technical staff perform four risk projection steps . The intent of
these steps is to consider risks in a manner that leads to prioritization. Be prioritizing risks, the software
team can allocate limited resources where they will have the most impact. Risk Projection/Estimation
Steps:1. Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low, 10-high)

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:29
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

2. Delineate the consequences of the risk

3. Estimate the impact of the risk on the project and product
4. Note the overall accuracy of the risk projection so that there will be no misunderstandings
5. A risk table provides a project manager with a simple technique for risk projection
Contents of a Risk Table

Risk

Category

Size estimate

Probability

Impact (1-4)

PS

60%

PS

30%

BU

40%

ST

30%

DE

80%

RMMM

may be
significantly low
Larger number of
users than
planned
End users resist
system
Staff
inexperienced
Lack of training
on tools

It consists of five columns

a. Risks All kinds of risks are listed in this column.
b. Category Each risk is categorized in the second column.(eg-PS- project size risk, BUbusiness risk).
c. Probability The probability of occurrence of each risk is entered in this column.
d. Impact Each risk is assessed and impact value is given as follows:1-Catastrophic
2-Critical
3-Marginal
4- Negligible

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:30
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Once the first four columns are completed, the table is sorted by probability and by
impact. High probability, high-impact risks are now the top entries in the table and lowprobability risks drop to the bottom. A cutoffline is drawn horizontally which implies
that risks above the line will be given further attention.
e. RMMM All risks that lie above cutoff line should be managed. The column labeled
RMMM contains a pointer to a Risk Mitigation, Monitoring, and Management Plan.
RMMM are risk information sheets developed for risks that lie above cutoff line. Entries
in RMMM sheets are:Risk Information Sheet
RISK ID

DATE

PROBABILTY

IMPACT

DESCRITION OF RISK
REFINEMENT/ CONTEXT
MITIGATION/MONITORING
MANAGEMENT/CONTIGENECY PLAN
CURRENT STATUS

Developing a Risk Table

List all risks in the first column (by way of the help of the risk item checklists)

Mark the category of each risk

Estimate the probability of each risk occurring

Assess the impact of each risk based on an averaging of the four risk components to determine
an overall impact value

Sort the rows by probability and impact in descending order

Draw a horizontal cutoff line in the table that indicates the risks that will be given further
attention.

3. Assessing Risk Impact

Three factors affect the consequences that are likely if a risk does occur
a. Its nature This indicates the problems that are likely if the risk occurs

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:31
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

b. Its scope This combines the severity of the risk (how serious was it) with its overall distribution
(how much was affected)
c. Its timing This considers when and for how long the impact will be felt
The overall risk exposure formula is RE = P x C
a. P = the probability of occurrence for a risk
b. C = the cost to the project should the risk actually occur
Example
a. P = 80% probability that 18 of 60 software components will have to be developed
b. C = Total cost of developing 18 components is $25,000
c. RE = .80 x $25,000 = $20,000
4. Risk Mitigation, Monitoring, and Management
An effective strategy for dealing with risk must consider three issues
a. Risk mitigation (i.e., avoidance)
b. Risk monitoring
c. Risk management and contingency planning
Risk mitigation (avoidance) is the primary strategy and is achieved through a plan
d. Example: Risk of high staff turnover

During risk monitoring, the project manager monitors factors that may provide an indication of whether
a risk is becoming more or less likely

Risk management and contingency planning assume that mitigation efforts have failed and that the risk
has become a reality.
-----------------------------------------------------------------------------------------------------------------------

Configuration Management
Software configuration management (SCM) is an umbrella activity that is applied throughout the software
process. Because change can occur at any time, SCM activities are developed to (1) identify change, (2)
control change, (3) ensure that change is being properly implemented, and (4) report changes. Elements of a
Configuration Management System are:1. Configuration elements
a. A set of tools coupled with a file management (e.g., database) system that enables access
to and management of each software configuration item.
2. Process elements

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:32
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

a. A collection of procedures and tasks that define an effective approach to change

management for all participants
3. Construction elements
a. A set of tools that automate the construction of software by ensuring that the proper set of valid
components (i.e., the correct version) is assembled
4. Human elements
a. A set of tools and process features used by a software team to implement effective SCM
SCM has five tasks:
1. Identification Of Objects in the Software Configuration
2. Change Control
3. Version Control
4. Configuration Auditing
5. Status Reporting Task

Figure:- Elements of a Configuration Management System are:1. Identification of objects in the Software Configuration
To control and manage software configuration items, each must be separately named and then organized
using an object-oriented approach. Two types of objects can be identified basic objects and aggregate
objects.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:33
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

2. Change Control
3. Change control is a procedural activity that ensures quality and consistency as changes are made to a
configuration object. A change request is submitted to a configuration control authority, which is
usually a change control board (CCB)
a. The request is evaluated for technical merit, potential side effects, overall impact on
other configuration objects and system functions, and projected cost in terms of money,
time, and resources.
An engineering change order (ECO) is issued for each approved change request
a. Describes the change to be made, the constraints to follow, and the criteria for review
and audit.
4. Version Control Task
Version control is a set of procedures and tools for managing the creation and use of multiple
occurrences of objects in the SCM repository. Required version control capabilities
a. An SCM repository that stores all relevant configuration objects
b. A version management capability that stores all versions of a configuration object (or
enables any version to be constructed using differences from past versions)
c. A make facility that enables the software engineer to collect all relevant configuration
objects and construct a specific version of the software
d. Issues tracking (bug tracking) capability that enables the team to record and track the
status of all outstanding issues associated with each configuration object.
5. Configuration Auditing
Configuration auditing is an SQA activity that helps to ensure that quality is maintained as changes are
made. It complements the formal technical review and is conducted by the SQA group. A configuration
audit ensures that

The correct CSCIs (by version) have been incorporated into a specific build

That all documentation is up-to-date and consistent with the version that has been built

6. Status Reporting Task

Configuration status reporting (CSR) is also called status accounting. Provides information about each
change to those personnel in an organization with a need to know. Sources of entries for configuration
status reporting

Each time a CSCI is assigned new or updated information

Each time a change is approved by the CCB and an ECO is issued

Each time a configuration audit is conducted

The configuration status report

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:34
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Placed in an on-line database or on a website for software developers and maintainers to

read

Given to management and practitioners to keep them appraised of important changes to

the project CSCI.

-----------------------------------------------------------------------------------------------------------------------------------Introduction to project management and planning CASE tools

Introduction to project management
The Management Spectrum
Effective software project management focuses on the four Ps: people, product, process, and project.
1. The People
The people factor is so important that the Software Engineering Institute has developed a people
management capability maturity model (PM-CMM). People comprises of following components:1. Stakeholders
2. Team Leaders
3. Software Team
4. Agile Teams
1.1 Stakeholders
The software process is populated by stakeholders who can be categorized into one of five constituencies:
a) Senior managers define business issues that often have significant influence on the project.
b) Project (technical) managers plan, motivate, organize, and control the practitioners who do
the work
c) Practitioners deliver the technical skills that are necessary to engineer a product or
application.
d) Customers specify the requirements for the software to be engineered and other stakeholders
who have a peripheral interest in the outcome.
e) End users interact with the software once it is released for production use.
1.2 Team Leaders
Project management is a people-intensive activity, and for this reason, competent practitioners often make poor
team leaders. MOI (Motivation, Organization, Ideas)model of leadership suggests following things:
a) Motivation-The ability to encourage (by push or pull) technical people to produce to their
best ability.
b) Organization-The ability to mold existing processes (or invent new ones) that will enable the
initial concept to be translated into a final product.
c) Ideas or innovation-The ability to encourage people to create and feel creative even when they
must work within bounds established for a particular software product or application.
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:35
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

An effective project manager emphasizes four key traits:

a) Problem solving:-An effective software project manager can diagnose the technical and
organizational issues that are most relevant, systematically structure a solution or properly motivate
other practitioners to develop the solution, apply lessons learned from past projects to new
situations, and remain flexible enough to change direction if initial attempts at problem solution are
fruitless.
b) Managerial identity. A good project manager must take charge of the project.
c) Achievement. To optimize the productivity of a project team, a manager must reward initiative and
accomplishment and demonstrate through his own actions that controlled risk taking will not be
punished.
d) Influence and team building. An effective project manager must be able to read people; she
must be able to understand verbal and nonverbal signals and react to the needs of the people sending
these signals. The manager must remain under control in high-stress situations.
1.3. Software Team
There are almost as many human organizational structures for software development as there are organizations
that develop software. Four organizational paradigms for software development teams are:a) Closed paradigm traditional hierarchy of authority; works well when producing software similar
to past efforts; members are less likely to be innovative.
b) Random paradigm depends on individual initiative of team members; works well for projects
requiring innovation or technological breakthrough; members may struggle when orderly
performance is required.
c) Open paradigm hybrid of the closed and random paradigm; works well for solving complex
problems; requires collaboration, communication, and consensus among members.
d) Synchronous paradigm organizes team members based on the natural pieces of the problem;
members have little communication outside of their subgroups.
Five factors that cause team toxity (i.e., a toxic team environment)
i. A frenzied work atmosphere
ii. High frustration that causes friction among team members
iii. A fragmented or poorly coordinated software process
iv. An unclear definition of roles on the software team
v. Continuous and repeated exposure to failure
How to avoid these problems?
i. Give the team access to all information required to do the job
ii. Do not modify major goals and objectives, once they are defined, unless absolutely necessary
iii. Give the team as much responsibility for decision making as possible
__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:36
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

iv. Let the team recommend its own process model

v. Let the team establish its own mechanisms for accountability (i.e., reviews)
vi. Establish team-based techniques for feedback and problem solving
1.4 Agile Teams
Agile Teams are highly motivated, small teams which adopts many of the characteristics of successful software
project teams. Many agile process models are there which give agile teams significant autonomy.

2. The Product
We must examine the product and the problem it is intended to solve at the very beginning of the project. The
topics discussed under product are:2.1 Software Scope
2.2 Problem Decomposition

2.1 Software Scope

The scope of the software development must be established and bounded. Scope is defined by answering the
following questions:1. Context How does the software to be built fit into a larger system, product, or business context, and
what constraints are imposed as a result of the context?
2. Information objectives What customer-visible data objects are produced as output from the software?
What data objects are required for input?
3. Function and performance What functions does the software perform to transform input data into
output? Are there any special performance characteristics to be addressed?
Problem Decomposition
Problem decomposition also referred to as partitioning or problem elaboration. It sits at the core of software
requirements analysis. Two major areas of problem decomposition
i. The functionality that must be delivered
ii. The process that will be used to deliver it

3. The Process
The generic phases that characterize the software processdefinition, development and supportare
applicable to all software.
3.1 Melding the Product and the Process
Project planning begins with the melding of the product and the process. Each function to be engineered by
the software team must pass through the set of framework activities that have been defined for a software
organization. Assume that the organization has adopted the following set of framework activities:__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:37
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Customer communicationtasks required to establish effective requirements

elicitation between developer and customer.
Planningtasks required to define resources, timelines, and other project related information.
Risk analysistasks required to assess both technical and management risks.
Engineeringtasks required to build one or more representations of then application.
Construction and releasetasks required to construct, test, install, and provide user support (e.g.,
documentation and training).
Customer evaluationtasks required to obtain customer feedback based on evaluation of the software
representations created during the engineering activity and implemented during the construction activity.
The team members who work on a product function will apply each of the framework activities to it. In
essence, a matrix similar to the one shown in Figure 3.2 is created. Each major product function (the figure
notes functions for the word-processing software discussed earlier) is listed in the left-hand column.
Framework activities are listed in the top row. Software engineering work tasks (for each framework
activity) would be entered in the following row. The job of the project manager (and other team members) is
to estimate resource requirements for each matrix cell, start and end dates for the tasks associated with each
cell, and work products to be produced as a consequence of each task.

1.2 Process Decomposition

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:38
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

Once the process model has been chosen, the common process framework (CPF) is adapted to it. In every
case, the CPFcustomer communication, planning, risk analysis, engineering, construction and release,
customer evaluationcan be fitted to the paradigm. Process decomposition commences when the project
manager asks, How do we accomplish this CPF activity? For example, a small, relatively simple
project might require the following work tasks for the customer communication activity:
1. Develop list of clarification issues.
2. Meet with customer to address clarification issues.
3. Jointly develop a statement of scope.
4. Review the statement of scope with all concerned.
5. Modify the statement of scope as required.

4. The Project
In order to manage a successful software project, we must understand what can go wrong and how to do it right.
Ten signs that indicate that an information systems project is in jeopardy:
1. Software people dont understand their customers needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs change [or are ill-defined].
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost [or was never properly obtained].
9. The project team lacks people with appropriate skills.
10. Managers [and practitioners] avoid best practices and lessons learned.
How does a manager act to avoid the problems just noted? A five-part commonsense approach to software
projects:
1. Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that
is to be solved and then setting realistic objects and expectations for everyone who will be involved in the
project. It is reinforced by building the right team and giving the team the autonomy, authority, and
technology needed to do the job.
2. Maintain momentum. Many projects get off to a good start and then slowly disintegrate. To maintain
momentum, the project manager must provide incentives to keep turnover of personnel to an absolute
minimum, the team should emphasize quality in every task it performs, and senior management
should do everything possible to stay out of the teams way.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:39
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

3. Track progress. For a software project, progress is tracked as work products (e.g., specifications, source
code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality
assurance activity. In addition, software process and project measures can be collected and used to assess
progress against averages developed for the software development organization.
4. Make smart decisions. In essence, the decisions of the project manager and the software team should be to
keep it simple. Whenever possible, decide to use commercial off-the-shelf software or existing software
components, decide to avoid custom interfaces when standard approaches are available, decide to identify and
then avoid obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks.
5. Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each
project. Evaluate the planned and actual schedules, collect and analyze software project metrics, get feedback
from team members and customers, and record findings in written form.
THE W5HH PRINCIPLE

WWWWWHH principle, after a series of questions that lead to a definition of key project characteristics and
the resultant project plan:
1. Why is the system being developed? The answer to this question enables all parties to assess the validity
of business reasons for the software work. Stated in another way, does the business purpose justify the
expenditure of people, time, and money?
2. What will be done, by when? The answers to these questions help the team to establish a project schedule
by identifying key project tasks and the milestones that are required by the customer.
3. Who is responsible for a function? Earlier in this chapter, we noted that the role and responsibility of each
member of the software team must be defined. The answer to this question helps accomplish this.
4. Where are they organizationally located? Not all roles and responsibilities reside within the software team
itself. The customer, users, and other stakeholders also have responsibilities.
5. How will the job be done technically and managerially? Once product scope is established, a management
and technical strategy for the project must be defined.
6. How much of each resource is needed? The answer to this question is derived by developing estimates
based on answers to earlier questions.
-------------------------------------------------------------------------------------------------------------------------------9.2 Planning CASE tools

(a) WHAT IS CASE?

Computer-aided software engineering (CASE) tools assist software engineering managers and practitioners in every activity
associated with the software process.
They automate project management activities, manage all work products produced throughout the process, and assist
engineers in their analysis, design, coding and test work.
CASE tools can be integrated within a sophisticated environment.
The workshop for software engineering has been called an integrated project support environment and the tools that fill the
workshop are collectively called computer-aided software engineering.
CASE provides the software engineer with the ability to automate manual activities and to improve engineering insight. Like
computer-aided engineering and design tools that are used by engineers in other disciplines, CASE tools help to ensure that
quality is designed in before the product is built.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:40
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

(b) BUILDING BLOCKS FOR CASE

Computer aided software engineering can be as simple as a single tool that supports a specific software engineering activity
or as complex as a complete "environment" that encompasses tools, a database, people, hardware, a network, operating
systems, standards, and myriad other components.
The building blocks for CASE are illustrated in Figure 10.1. Each building block forms a foundation for the next, with tools
sitting at the top of the heap.
Successful environments for software engineering are built on an environment architecture that encompasses appropriate
hardware and systems software. In addition, the environment architecture must consider the human work patterns that are
applied during the software engineering process.

Figure 10.1:-The building blocks for CASE

The environment architecture composed of the hardware platform and operating system support lays the ground work
for CASE.
A set of portability services provides a bridge between CASE tools and their integration framework and the environment
architecture. Portability services allow CASE tools and their integration framework to migrate across different hardware
platforms and operating systems without significant adaptive maintenance.
The integration framework is a collection of specialized programs that enables individual CASE tools to communicate with
one another, to create a project database, and to exhibit the same look and feel to the end-user (the software engineer).
The relative levels of CASE integration are shown in Figure 10.2.
1 At the low end of the integration spectrum is the individual (point solution) tool. When individual tools provide
facilities for data exchange (most do), the integration level is improved slightly. Such tools produce output in a
standard format that should be compatible with other tools that can read the format. In some cases, the builders of
complementary CASE tools work together to form a bridge between the tools (e.g., an analysis and design tool that
is coupled with a code generator). Using this approach, the synergy between the tools can produce end products that
would be difficult to create using either tool separately.
2 Single-source integration occurs when a single CASE tools vendor integrates a number of different tools and sells
them as a package. Although this approach is quite effective, the closed architecture of most single-source
environments precludes easy addition of tools from other vendors.

Figure 10.2:- Integration levels

3

At the high end of the integration spectrum is the integrated project support environment (IPSE). Standards for each of
the building blocks described previously have been created. CASE tool vendors use IPSE standards to build tools that will be
compatible with the IPSE and therefore compatible with one another.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:41
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

(c) A TAXONOMY OF CASE TOOLS

CASE tools can be classified by function, by their role as instruments for managers or technical people, by their use in the
various steps of the software engineering process, by the environment architecture (hardware and software) that supports them, or
even by their origin or cost . The taxonomy presented here uses function as a primary criterion.
1 Business process engineering tools
Business process engineering tools provide a "meta-model" from which specific information systems are derived.
Business information is modeled as it moves between various organizational entities within a company.
The primary objective for tools in this category is to represent business data objects, their relationships, and how
these data objects flow between different business areas within a company.
2 Process modeling and management tools
Process modeling tools (also called process technology tools) are used to represent the key elements of a process so
that it can be better understood.
These tools can also provide links to process descriptions that help those involved in the process to understand the
work tasks that are required to perform it.
Process management tools provide links to other tools that provide support to defined process activities.
3 Project planning tools
Tools in this category focus on two primary areas: software project effort and cost estimation and project
scheduling.
Estimation tools compute estimated effort, project duration, and recommended number of people for a project.
Project scheduling tools enable the manager to define all project tasks, create a task network, represent task
interdependencies, and model the amount of parallelism possible for the project.
4 Risk analysis tools
Risk analysis tools enable a project manager to build a risk table by providing detailed guidance in the identification
and analysis of risks.
5 Project management tools
The project schedule and project plan must be tracked and monitored on a continuing basis. In addition, a manager
should use tools to collect metrics that will ultimately provide an indication of software product quality.
Tools in the category are often extensions to project planning tools.
6 Requirements tracing tools
When large systems are developed, things "fall into the cracks." That is, the delivered system does not fully meet
customer specified requirements.
The objective of requirements tracing tools is to provide a systematic approach to the isolation of requirements,
beginning with the customer request for proposal or specification.
7 Metrics and management tools
Metrics or measurement tools focus on process and product characteristics. Management-oriented tools capture
project specific metrics (e.g., LOC/person-month, defects per function point) that provide an overall indication of
productivity or quality.
Technically oriented tools determine technical metrics that provide greater insight into the quality of design or code.
8 Documentation tools
Document production and desktop publishing tools support nearly every aspect of software engineering and
represent a substantial "leverage" opportunity for all software developers.
Documentation tools provide an important opportunity to improve productivity.
9 System software tools
CASE is a workstation technology.
Therefore, the CASE environment must accommodate high-quality network system software, object management
services, distributed component support, electronic mail, bulletin boards, and other communication capabilities.
10 Quality assurance tools
The majority of CASE tools that claim to focus on quality assurance are actually metrics tools that audit source
code to determine compliance with language standards. Other tools extract technical metrics in an effort to project
the quality of the software that is being built.
11 Database management tools
Database management software serves as a foundation for the establishment of a CASE database (repository) that
we have called the project database.
Database management tools for CASE are evolving from relational database management systems to object
oriented database management systems.
12 Software configuration management tools
Software configuration management lies at the kernel of every CASE environment.
Tools can assist in all five major SCM (Software Configuration Management) tasksidentification, version control,
change control, auditing, and status accounting.
13 Analysis and design tools
Analysis and design tools enable a software engineer to create models of the system to be built.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:42
Prepared By: Merin Mary Philip

Dept of Computer Science and Engineering

CML

14

15

16

17

18

19

20

21

22

23

24

The models contain a representation of data, function, and behavior (at the analysis level) and characterizations of
data, architectural, component-level, and interface design.
PRO/SIM tools
PRO/SIM (prototyping and simulation) tools provide the software engineer with the ability to predict the behavior
of a real-time system prior to the time that it is built.
In addition, these tools enable the software engineer to develop mock-ups of the real-time system, allowing the
customer to gain insight into the function, operation and response prior to actual implementation.
Interface design and development tools
Interface design and development tools are actually a tool kit of software components (classes) such as menus,
buttons, window structures, icons, scrolling mechanisms, device drivers, and so forth.
Prototyping tools
A variety of different prototyping tools can be used.
Screen painters enable a software engineer to define screen layout rapidly for interactive applications.
A variety of fourth generation tools have prototyping features.
Programming tools
The programming tools category encompasses the compilers, editors, and debuggers that are available to support
most conventional programming languages.
Web development tools
The activities associated with Web engineering are supported by a variety of tools for WebApp development.
These include tools that assist in the generation of text, graphics, forms, scripts, applets, and other elements of a
Web page.
Integration and testing tools
In their directory of software testing tools, Software Quality Engineering defines the following testing tools categories:a) Data acquisitiontools that acquire data to be used during testing.
b) Static measurementtools that analyze source code without executing test cases.
c) Dynamic measurementtools that analyze source code during execution.
d) Simulationtools that simulate function of hardware or other externals.
e) Test managementtools that assist in the planning, development, and control of testing.
f) Cross-functional toolstools that cross the bounds of the preceding categories.
Static analysis tools
Static testing tools assist the software engineer in deriving test cases.
Three different types of static testing tools are used in the industry: code based testing tools, specialized testing languages,
and requirements-based testing tools.
a) Code-based testing tools accept source code (or PDL) as input and perform a number of analyses that
result in the generation of test cases.
b) Specialized testing languages (e.g., ATLAS) enable a software engineer to write detailed test
specifications that describe each test case and the logistics for its execution.
c) Requirements-based testing tools isolate specific user requirements and suggest test cases (or classes of
tests) that will exercise the requirements.
Dynamic analysis tools
Dynamic testing tools interact with an executing program, checking path coverage, testing assertions about the value of
specific variables, and otherwise instrumenting the execution flow of the program. Dynamic tools can be either intrusive or
nonintrusive.
Test management tools
Test management tools are used to control and coordinate software testing for each of the major testing steps.
Tools in this category manage and coordinate regression testing, perform comparisons that ascertain differences
between actual and expected output, and conduct batch testing of programs with interactive human/computer
interfaces.
Client/server testing tools
The c/s environment demands specialized testing tools that exercise the graphical user interface and the network
communications requirements for client and server.
Reengineering tools
The reengineering tools category can be subdivided into the following functions:
o Reverse engineering to specification tools take source code as input and generate graphical structured
analysis and design models, where-used lists, and other design information.
o Code restructuring and analysis tools analyze program syntax, generate a control flow graph, and
automatically generate a structured program.
o On-line system reengineering tools are used to modify on-line database systems.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING
Page No:43
Prepared By: Merin Mary Philip