MANAKULA VINAYAGAR INSTITUTE OF TECHNOLOGY

KALITHEERTHAL KUPPAM, PUDHUCHERY -605 107

DEPARTMENT OF CSE
SOFTWARE ENGINEERING (CS T55)

UNIT –II Software Project Management and Requirements Analysis

Software Project Management and Requirements Analysis: Responsibilities of a Software Project

Manager – Project Planning – Metrics for Project Size Estimation – Empirical Estimation Techniques
– COCOMO – Halstead‘s Software Science – Staffing Level Estimation – Scheduling – Organization
and Team structures – Staffing – Risk Management – Software Configuration Management –
Requirements Gathering and Analysis – Software Requirements specification – Formal System
Specification – Axiomatic Specification - Algebraic Specification – 4GL.
--------------------------------------------------------------------------------------------------------------------

2.1 Software project Management

The main goal of software project management is to enable a group of developers to work
effectively towards the successful completion of a project.

Software Project Management Complexities

The main factors contributing to the complexity of managing a software project, as identified by are
the following:
Invisibility
Changeability
Complexity:
Uniqueness
Exactness of the solution
Team-oriented and intellect-intensive work

2.2 Responsibilities of a Software Project Manager

Job Responsibilities for Managing Software Projects

Project manager‘s responsibilities into the following two major categories:

Project planning: Project planning involves estimating several characteristics of a project and then
planning the project activities based on these estimates made.
Project monitoring and control: The focus of project monitoring and control activities is to ensure
that the software development proceeds as per plan.

Skills Necessary for Managing Software Projects

SOFTWARE ENGINEERING 1 MIT/CSE

Three skills that are most critical to successful project management are the following:
Knowledge of project management techniques.
Decision taking capabilities.
Previous experience in managing similar projects.

Project Planning
Project planning is undertaken and completed before any development activity starts.

During project planning, the project manager performs the following activities.

Estimation: The following project attributes are estimated.

Cost: How much is it going to cost to develop the software product?

Duration: How long is it going to take to develop the product?
Effort: How much effort would be necessary to develop the product?

The effectiveness of all later planning activities such as scheduling and staffing are dependent
on the accuracy with which these three estimations have been made.

Scheduling: After all the necessary project parameters have been estimated, the schedules for
manpower and other resources are developed.
Staffing: Staff organization and staffing plans are made.
Risk management: This includes risk identification, analysis, and abatement planning.
Miscellaneous plans: This includes making several other plans such as quality assurance plan,
and configuration management plan, etc.

Size is the most fundamental parameter based on which all other estimations and project plans are
made.

SOFTWARE ENGINEERING 2 MIT/CSE

 Based on the size estimation, the effort required to complete a project and the duration over
which the development is to be carried out are estimated.
Based on the effort estimation, the cost of the project is computed.
The estimated cost forms the basis on which price negotiations with the customer is carried
out.
Other planning activities such as staffing, scheduling etc. are undertaken based on the effort
and duration estimates made.
The SPMP Document of Project Planning
Organization of the software project management plan (SPMP) document
Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraints
Project estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost, and Project Duration Estimates
3. Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation
4. Project resources
(a) People
(b) Hardware and Software
(c) Special Resources
5. Staff organization
(a) Team Structure
(b) Management Reporting
6. Risk management plan
(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures
7. Project tracking and control plan
(a) Metrics to be tracked
(b) Tracking plan
(c) Control plan
8. Miscellaneous plans
(a) Process Tailoring
(b) Quality Assurance Plan
(c) Configuration Management Plan
(d) Validation and Verification
(e) System Testing Plan
(f ) Delivery, Installation, and Maintenance Plan

SOFTWARE ENGINEERING 3 MIT/CSE

METRICS FOR PROJECT SIZE ESTIMATION

Lines of Code (LOC)

Function Point (FP) Metric

Lines of Code (LOC)

LOC is possibly the simplest among all metrics available to measure project size.
This metric measures the size of a project by counting the number of source instructions in the
developed program while counting the number of source instructions, comment lines, and
header lines are ignored
Determining the LOC count at the end of a project is very simple.
Accurate estimation of LOC count at the beginning of a project is a very difficult task.
LOC count at the starting of a project, only by using some form of systematic guess work
Systematic guessing typically involves the following.
The project manager divides the problem into modules, and each module into sub-modules and
so on, until the LOC of the leaf-level modules are small enough to be predicted.
By adding the estimates for all leaf level modules together, project managers arrive at the total
size estimation.
In spite of its conceptual simplicity, LOC metric has several shortcomings when used to
measure problem size.

Shortcomings of the LOC metric

LOC is a measure of coding activity alone.

LOC count depends on the choice of specific instructions
LOC measure correlates poorly with the quality and efficiency of the Code
LOC metric penalises use of higher-level programming languages and code reuse
LOC metric measures the lexical complexity of a program and does not address the more
important issues of logical and structural complexities
It is very difficult to accurately estimate LOC of the final program from problem specification

Function Point (FP) Metric

Function Point (FP) Metric overcomes many of the shortcomings of the LOC metric.
In the function point metric size can easily be computed from the problem specification itself,
whereas in LOC metrics the size can accurately be determined only after the product has fully
been developed.

The conceptual idea behind the function point metric is the following.

The size of a software product is directly dependent on the number of different high-level
functions or features it supports.
A software product supporting many features would certainly have large size than the product
with fewer features.

SOFTWARE ENGINEERING 4 MIT/CSE

 Each function invokes some function for input data and transforms it to output data.
For example book query feature
It consists of features like query book, issues book and return book

The size of the program depends on the number of files and interfaces.
Interface is used for data transfer with other external systems

Function point (FP) metric computation

The size of a software product (in units of function points or FPs) is computed using different
characteristics of the product identified in its requirements specification.

Step 1: Compute the unadjusted function point (UFP) using a heuristic expression.
Step 2: Refine UFP to reflect the actual complexities of the different parameters used in UFP
computation.
Step 3: Compute FP by further refining UFP to account for the specific characteristics of the project
that can influence the entire development effort.

Step 1: UFP computation

The unadjusted function points (UFP) is computed as the weighted sum of five characteristics
of a product as shown in the expression.
The weights associated with the five characteristics were determined empirically by Albrecht
through data gathered from many projects.

UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 +

(Number of files)*10 + (Number of interfaces)*10

1. Number of inputs:

SOFTWARE ENGINEERING 5 MIT/CSE

 Each data item input by the user is counted. It should be noted that data inputs are considered
different from user inquiries.
Inquiries are user commands such as print account- balance that require no data values to be
input by the user. Inquiries are counted separately.
Individual data items input by the user are not simply added up to compute the number of
inputs, but related inputs are grouped and considered as a single input.
2. Number of outputs:
The outputs considered include reports printed, screen outputs, error messages produced, etc.
While computing the number of outputs, the individual data items within a report are not considered;
but a set of related data items is counted as just a single output.
3. Number of inquiries:
An inquiry is a user command (without any data input) and only requires some actions to be
performed by the system. Thus, the total number of inquiries is essentially the number of distinct
interactive queries (without data input) which can be made by the users. Examples of such inquiries
are print account balance; print all student grades, display rank holders‘ names, etc.
4. Number of files:
The files referred to here are logical files. A logical file represents a group of logically related
data. Logical files include data structures as well as physical files.
5. Number of interfaces:
Here the interfaces denote the different mechanisms that are used to exchange information with
other systems. Examples of such interfaces are data files on tapes, disks, communication links with
other systems, etc.
Step 2: Refine parameters
` UFP computed at the end of step 1 is a gross indicator of the problem size. This UFP needs to
be refined. Some input values may be extremely complex, some very simple. The complexity of each
parameter is graded into three broad categories—simple, average, or complex.

Step 3: Refine UFP based on complexity of the overall project

Several factors that can impact the overall project size are considered to refine the UFP
computed in step 2.
Albrecht identified 14 parameters that can influence the development effort. 14 parameters is
assigned a value from 0 (not present or no influence) to 6 (strong influence).

SOFTWARE ENGINEERING 6 MIT/CSE

 The resulting numbers are summed, yielding the total degree of influence (DI).
A technical complexity factor (TCF) for the project is computed and the TCF is multiplied with
UFP to yield FP.
The TCF expresses the overall impact of the corresponding project parameters on the
development effort.
TCF is computed as (0.65+0.01*DI). As DI can vary from 0 to 84, TCF can vary from 0.65 to
1.49. Finally, FP is given as the product of UFP and TCF. That is, FP=UFP*TCF.

PROJECT ESTIMATION TECHNIQUES

Empirical estimation techniques
Heuristic techniques
Analytical estimation techniques

EMPIRICAL ESTIMATION TECHNIQUES

Expert Judgment
Delphi Cost Estimation

Expert Judgment

Expert judgement is a widely used size estimation technique. In this technique, an expert
makes an educated guess about the problem size after analysing the problem thoroughly.
Usually, the expert estimates the cost of the different components (i.e. modules or subsystems)
that would make up the system and then combines the estimates for the individual modules to
arrive at the overall estimate.
This technique suffers from several shortcomings. The outcome of the expert judgement
technique is subject to human errors and individual bias. Also, it is possible that an expert may
overlook some factors inadvertently.
Further, an expert making an estimate may not have relevant experience and knowledge of all
aspects of a project. For example, he may be conversant with the database and user interface
parts, but may not be very knowledgeable about the computer communication part.
Due to these factors, the size estimation arrived at by the judgement of a single expert may be
far from being accurate.
A more refined form of expert judgement is the estimation made by a group of experts.
Chances of errors arising out of issues such as individual oversight, lack of familiarity with a
particular aspect of a project, personal bias, and the desire to win contract through overly
optimistic estimates is minimised when the estimation is done by a group of experts. However,
the estimate made by a group of experts may still exhibit bias.
For example, on certain issues the entire group of experts may be biased due to reasons such as
those arising out of political or social considerations. Another important shortcoming of the
expert judgement technique is that the decision made by a group may be dominated by overly
assertive members.

SOFTWARE ENGINEERING 7 MIT/CSE

Delphi cost estimation

Delphi cost estimation technique tries to overcome some of the shortcomings of the expert
judgement approach.
Delphi estimation is carried out by a team comprising a group of experts and a co-ordinator.
In this approach, the co-ordinator provides each estimator with a copy of the software
requirements specification (SRS) document and a form for recording his cost estimate.
Estimators complete their individual estimates anonymously and submit them to the co-
ordinator.
In their estimates, the estimators mention any unusual characteristic of the product which has
influe nce d their estimations.
The co-ordinator prepares the summary of the responses of all the estimators, and also includes
any unusual rationale noted by any of the estimators.
The prepared summary information is distributed to the estimators. Based on this summary, the
estimators re-estimate.
This process is iterated for several rounds. However, no discussions among the estimators is
allowed during the entire estimation process.
The purpose behind this restriction is that if any discussion is allowed among the estimators,
then many estimators may easily get influenced by the rationale of an estimator who may be
more experienced or senior.
After the completion of several iterations of estimations, the co-ordinator takes the
responsibility of compiling the results and preparing the final estimate.
The Delphi estimation, though consumes more time and effort, overcomes an important
shortcoming of the expert judgement technique in that the results can not unjustly be
influenced by overly assertive and senior members.

COCOMO – Heuristic estimation technique

COCOMO – COnstructive COst estimation MOdel

This model was proposed by Boehm, 1981. He postulated that any software development
project can be classified into any one of the following three categories based on the development
complexity, they are
Organic
Semidetached
Embedded
It is not only classified by the characteristic of the product but also by the development team and
development environment.
 The three product classes correspond to application, utility and system programs
o Data processing program consider as application programs
o Complier, linker, etc., are Utility program
o Real time system and operating system etc., are system program
 utility programs are roughly three times as difficult to write as application program
 system program are roughly three times as difficult as utility program
1.organic:
It is organic If the project deals with developing a well understood application program

SOFTWARE ENGINEERING 8 MIT/CSE

 The size of the development team is reasonably small
The team members are experienced in developing similar types of projects
2.semidetached:
It is semidetached if the developing team consists of mixture of experienced and inexperienced
staff
Team member may have limited experience on related systems but may be unfamiliar with
some aspects of the system being developed
3.embedded:
It is embedded if the software being developed is strongly coupled to complex hardware

Boehm provides different sets of expressions to predict the effort and development time from
the size estimation given in KLOC (kilo Lines of Source Code).Open person-month is the effort an
individual can typically put in a month.
That effort estimation is expressed in units of person-months (PM).The person month unit
indicates the work done by one person working on the project for one month.
Effort estimation of 100PM does not imply that 100persons should work for one month, it imply that 1
person should be employed for 100 months.

The number personal working on the project usually increases and decreases as shown in person-
month curve.

Software cost estimation should be done through three stages:

Basic COCOMO Model
Intermediate COCOMO
Complete COCOMO.
Basic COCOMO Model:
The basic COCOMO model gives an approximate estimate of the project parameters.
Expression of basic COCOMO model,
Effort =a1 x (KLOC)a2 PM
Tdev=b1 x (Effort)b2 Months
Where,
KLOC is estimated size in Kilo Lines of Code.

a1,a2,b1,b2 are constants for each category of software products.

Tdev is the estimated time to develop the software,expressed in months.

SOFTWARE ENGINEERING 9 MIT/CSE

 Effort is total effort required to develop the software product in PM

Estimation of development effort

Organic: effort = 2.4(KLOC) 1.05 PM
Semidetached: effort = 3.0(KLOC)1.12 PM
Embedded: effort= 3.6(KLOC)1.20PM

Estimation of development time

Organic: Tdev= 2.5(Effort)0.38 Months
Semidetached: Tdev=2.5(Effort)0.35 Months
Embedded: Tdev=2.5(Effort)0.32 Months

Effort versus product size

In this the effort is somewhat superlinear, slope of curve <=1

The effort required to develop a product rapidly increase with product size
Development time versus size

SOFTWARE ENGINEERING 10 MIT/CSE

 The development time is sublinear function of the size of the product
The size of the product increases two times the time of to develop the product does not
double but rises moderately.
If team tries to develop the product in at time shorter than the estimated time than cost
will increase rapidly
If the team complete the project over a longer period of time than that estimated, then
there is almost no decrease in the estimated cost value.

Example
Assume that the size of an organic type software product has been estimated to be 32,000 lines
of source code. Assume that the average salary of a software developer is Rs. 15,000 per month.
Determine the effort required to develop the software product, the nominal development time, and the
cost to develop the product.

From the basic COCOMO estimation,

Formula for organic software: Effort = 2.4 × (32) 1.05 = 91PM
Nominal development time = 2.5 × (91) 0.38 = 14 months
Staff cost required to develop the product = 91 × Rs. 15, 000 = Rs.1,465,000

Intermediate COCOMO model

The basic COCOMO model assumes that effort and development time are functions of the
project alone
But the intermediate COCOMO model considered the other 15 parameters base on various
attributes of software development
They are:
1.product: it considered the complexity of the product, reliability requirements of the
products, etc.,
2.computer: it consider the execution speed, storage space required, etc.,
3.personnel: it consider the experience level of the person, programming capability, analysis
capability, etc.,
4.development environment: it consider the development facilities available to the
developers, sophistication of software development tools used for development(CASE).

Complete COCOMO model

The major shortcoming of both basic and intermediate COCOMO model is they consider the
product as a single homogeneous entity.
Most large system is made up of several subsystems. These subsystem consider different
characteristics, one may be organic one may be semidetached and some may embedded.
The complete COCOMO model considers all these subsystem as separate system and
calculates the effort and time estimation separately for each system. Final the cost of the whole
project is calculated by summing the estimated value of the subsystems.
This reduces the error in the final stage
The subcomponents of the project are,
Database part
Graphical user interface(GUI) part

SOFTWARE ENGINEERING 11 MIT/CSE

 Communication part
Datrabase part can be consider as semidetached, GUI part can be considered as organic and
communication part can be considered as embedded.

COCOMO 2
The present day software is large in size and reuse of existing software to develop new
products. This give rise in component based development. New life cycle model and
development paradigms are being deployed for web based and component base software.
Most of the product are highly interactive and elaborate graphical user interface, thus
COCOMO 2 model is introduced.
COCOMO 2 model provides three increasingly detailed cost estimation models.these can be used
to estimate project costs at different phases of the software. Project progresses through these models
can be applied at the differen stages. They are,
1.application composition: used to estimate the cost of the prototyping eg: to resolve user interface
issues.
2.early design: this support estimation of cost at the architectural design stage
3.post architecture stage: this provides cost estimation during detailed design and codeing stage.

Application composition model

The application composition model is based on counting the number of screens, reports, and
modules (components). Each of these components is considered to be an object (this has nothing to do
with the concept of objects in the object-oriented paradigm). These are used to compute the object
points of the application.
Effort is estimated in the application composition model as follows:
1. Estimate the number of screens, reports, and modules (components) from an analysis of the SRS
document.
2. Determine the complexity level of each screen and report, and rate these as either simple,
medium, or difficult. The complexity of a screen or a report is determined by the number of tables
and views it contains.
3. Use the weight values in Table 3.3 to 3.5.
The weights have been designed to correspond to the amount of effort required to implement an
instance of an object at the assigned complexity class.

SOFTWARE ENGINEERING 12 MIT/CSE

4. Add all the assigned complexity values for the object instances together to obtain the object
points.

5. Estimate percentage of reuse expected in the system. Note that reuse refers to the amount of pre-
developed software that will be used within the system. Then, evaluate New Object-Point count
(NOP) as follows,

6. Determine the productivity using Table 3.6. The productivi ty depends onthe experience of the
developers as well as the maturity of the CASE environment used.
7. Finally, the estimated effort in person-months is computed as E = NOP/PROD.

Early design model

The unadjusted function points (UFP) are counted and converted to source lines of code
(SLOP). In a typical programming environment, each UFP would correspond to about 128 lines of C,
29 lines of C++, or 320 lines of assembly code.
The cost drivers include product reliability and complexity, the extent of reuse, platform
sophistication, personnel experience, CASE support, and schedule.

The effort is calculated using the following formula:

Effort = K SLOC × πi cost driveri

Post-architecture model

The effort is calculated using the following formula, which is similar to

the original COCOMO model.
Effort = a × K SLOCb × πi cost driveri

Halstead’s software science- an analytical technique

This technique is to measure size , development effort development cost of software products.
Halstead used a few primitive program parameters to develop the expressions for over all
program length, potential minimum volume, actual volume, language level, effort and
development time.

SOFTWARE ENGINEERING 13 MIT/CSE

  h1 be the number of unique operators used in the program,
 h2 be the number of unique operands used in the program,
 N1 be the total number of operators used in the program,
 N2 be the total number of operands used in the program.

Operators and Operands for the ANSI C language

The following is a suggested list of operators for the ANSI C language:

( [ . , -> * + - ~ ! ++ -- * / % + - << >> < > <= >= != == & ^ | && || = *= /= %= += -= <<= >>= &= ^=
|= : ? { ; CASE DEFAULT IF ELSE SWITCH WHILE DO FOR GOTO CONTINUE
BREAK RETURN and a function name in a function call

Example 3.3 Consider the expression a = &b; a, b are the operands and =,
& are the operators.

Example 3.4 The function name in a function definition is not counted as an

operator.
int func ( int a, int b )
{
...
}
For the above example code, the operators are: {}, ()We do not consider func, a, and b as operands,
since these are part of the function definition.

Example 3.5 Consider the function call statement: func (a, b);. In this, func ‗ ,‘ a n d ; are considered
as operators and variables a, b are treated as operands.

Length and Vocabulary

The length of a program as defined by Halstead, quantifies total usage of all operators and
operands in the program.
Thus, length N = N1 + N2. Halstead‘s definition of the length of the program as the total
number of operators and operands roughly agrees with the intuitive notion of the program
length as the total number of tokens used in the program.
The program vocabulary is the number of unique operators and operands used in the program.
Thus, program vocabulary h = h1 + h2.

Program Volume
The length of a program (i.e., the total number of operators and operands used in the code)
depends on the choice of the operators and operands used.
In other words, for the same programming problem, the length would depend on the
programming style.
This type of dependency would produce different measures of length for essentially the same
problem when different programming languages are used.
Thus, while expressing program size, the programming language used must be taken into
consideration: V = N log2 h

SOFTWARE ENGINEERING 14 MIT/CSE

  The program volume V is the minimum number of bits needed to encode the
program.
 To represent h different identifiers uniquely, we need at least log2 h bits (where h is
the program vocabulary).
 N log2 h bits to store a program of length N.
 Therefore, the volume V represents the size of the program by approximately
compensating for the effect of the programming language used.

Potential Minimum Volume

The potential minimum volume V* is defined as the volume of the most succinct program in
which a problem can be coded.
The minimum volume is obtained when the program can be expressed using a single source
code instruction, say a function call like foo();.
The volume is bound from below due to the fact that a program would have at least two
operators and no less than the requisite number of operands.
Operands are the input and output data items.
Thus, if an algorithm operates on input and output data d1, d2, ... dn, the most succinct
program would be f(d1, d2 , ..., dn); for which, h1 = 2, h2 =n.
Therefore, V* = (2 + h2) log2 (2 + h2).
The program level L is given by L = V*/V.

Effort and Time

The effort required to develop a program can be obtained by dividing the program volume with
the level of the programming language used to develop the code.
Thus, effort E = V /L, where E is the number of mental discriminations required to implement
the program and also the effort required to read and understand the program. T
hus, the programming effort E = V2/V* (since L = V*/V) varies as the square of the volume.
Experience shows that E is well correlated to the effort needed for maintenance of an existing
program.
The programmer‘s time T = E/S, where S is the speed of mental discriminations.

Length Estimation
Even though the length of a program can be found by calculating the t o t a l number of
operators and operands in a program, Halstead suggests a way to determine the length of a
program using the number of unique operators and operands used in the program.
Using this method, the program parameters such as length, volume, cost, effort, etc., can be
determined even before the start of any programming activity.
combinatorial result that for any given alphabet of size K, there are exactly Kr different strings
of length r. Thus,

SOFTWARE ENGINEERING 15 MIT/CSE

STAFFING LEVEL ESTIMATION

Norden’s Work

SOFTWARE ENGINEERING 16 MIT/CSE

where, E is the effort required at time t. E is an indication of the number of developers (or the staffing
level) at any particular time during the duration of the project, K is the area under the curve, and td is
the time at which the curve attains its maximum value.

Putnam’s Work

where the different terms are as follows:

• K is the total effort expended (in PM) in the product development and L is the product size in KLOC.
• t d corresponds to the time of system and integration and testing. Therefore, t d can be approximately
considered as the time required developing the software.
• Ck is the state of technology constant and reflects constraints that impede the progress of the
programmer. Typical values of C k =2 for poor development C k =8 for good software development
environment Ck =11 for an excellent environment
Jensen’s Model

where, Cte is the effective technology constant, td is the time to develop the software, and K is the
effort needed to develop the software.

SCHEDULING
The scheduling problem, in essence, consists of deciding which tasks would be taken up when and by
whom.
In order to schedule the project activities, a software project manager needs to do the following:

1. Identify all the major activities that need to be carried out to complete the project.
2. Break down each activity into tasks.
3. Determine the dependency among different tasks.
4. Establish the estimates for the time durations necessary to complete the tasks.
5. Represent the information in the form of an activity network.
6. Determine task starting and ending dates from the information represented in the activity network.
7. Determine the critical path. A critical path is a chain of tasks that determines the duration of the
project.
8. Allocate resources to tasks.

SOFTWARE ENGINEERING 17 MIT/CSE

Work Breakdown Structure
Tasks are the lowest level work activities in a WBS hierarchy. They also form the basic units of work
that are allocated to the developer and scheduled

How long to decompose?

The decomposition of the activities is carried out until any of the following is satisfied:
A leaf-level subactivity (a task) requires approximately two weeks to develop.
Hidden complexities are exposed, so that the job to be done is understood and can be assigned
as a unit of work to one of the developers.
Opportunities for reuse of existing software components is identified.

Activity Networks

SOFTWARE ENGINEERING 18 MIT/CSE

Activity on Node (AoN): In this representation, each activity is represented by a rectangular (some
use circular) node and the duration of the activity is shown alongside each task in the node.
Activity on Edge (AoE): In this representation tasks are associated with the edges. The edges are also
annotated with the task duration. The nodes in the graph represent project milestones.

Example 3.9: Determine the Activity network representation for the MIS development project of
Example 3.7. Assume that the manager has determined the tasks to be represented from the work
breakdown structure of Figure 3.7, and has determined the durations and dependencies for each task as
shown in Table 3.7.

Answer: The activity network representation has been shown in Figure 3.8.

Critical Path Method (CPM)

A critical task is one with a zero slack time. A path from the start node to the finish node containing
only critical tasks is called a critical path.
Minimum time (MT): It is the minimum time required to complete the project. It is computed by
determining the maximum of all paths from start to finish.
Earliest start (ES): It is the time of a task is the maximum of all paths from the start to this task. The
ES for a task is the ES of the previous task plus the duration of the preceding task.
Latest start time (LST): It is the difference between MT and the maximum of all paths from this task
to the finish. The LST can be computed by subtracting the duration of the subsequent task from the
LST of the subsequent task.
Earliest finish time (EF): The EF for a task is the sum of the earliest start time of the task and the
duration of the task.
Latest finish (LF): LF indicates the latest time by which a task can finish without affecting the final
completion time of the project. A task completing beyond its LF would cause project delay. LF of a
task can be obtained by subtracting maximum of all paths from this task to finish from MT.
Slack time (ST): The slack time (or float time) is the total time that a task may be delayed before it
will affect the end time of the project. The slack time indicates the ‖flexibility‖ in starting and
completion of tasks. ST for a task is LS-ES and can equivalently be written as LF-EF.

Example 3.10 Use the Activity network of Figure 3.8 to determine the ES and EF for every task for
the MIS problem of Example 3.7.
Answer: The activity network with computed ES and EF values has been shown in Figure 3.9.

SOFTWARE ENGINEERING 19 MIT/CSE

The project parameters for different tasks for the MIS problem can be computed as follows:
1. Compute ES and EF for each task. Use the rule: ES is equal to the largest EF the immediate
predecessors
2. Compute LS and LF for each task. Use the rule: LF is equal to the smallest LS of the immediate
successors
3. Compute ST for each task. Use the rule: ST=LF-EF

SOFTWARE ENGINEERING 20 MIT/CSE

PERT Charts

Optimistic (O): The best possible case task completion time.

Most likely estimate (M): Most likely task completion time.
Worst case (W): The worst possible case task completion time.

Gantt Charts

A Gantt chart is a special type of bar chart where each bar represents an activity. The bars are drawn
along a time line. The length of each bar is proportional to the duration of time planned for the
corresponding activity.

SOFTWARE ENGINEERING 21 MIT/CSE

Project monitoring and control
The project manager designates certain key events such as completion of some important activity as a
milestone.

ORGANISATION AND TEAM STRUCTURES

Organisation Structure
Functional format
In the functional format, the development staff are divided based on the specific functional group to
which they belong to.
Project format
set of developers is assigned to every project at the start of the project, and remain with the project till
the completion of the project.

Functional versus project formats

The main advantages of a functional organisation are:
• Ease of staffing
• Production of good quality documents
• Job specialisation
• Efficient handling of the problems associated with manpower turnover
Matrix format
A matrix organisation is intended to provide the advantages of both functional and project structures.
In a matrix organisation, the pool of functional specialists are assigned to different projects as needed.
Thus, the deployment of the different functional specialists in different projects can be represented in a
matrix

SOFTWARE ENGINEERING 22 MIT/CSE

Team Structure
Chief programmer team
In this team organisation, a senior engineer provides the technical leadership and is designated
the chief programmer. The chief programmer partitions the task into many smaller tasks and assigns
them to the team members. He alsoverifies and integrates the products developed by different team
members.

The chief programmer team is probably the most efficient way of completing simple and small
projects since the chief programmer can quickly work out a satisfactory design and ask the
programmers to code different modules of his design solution.

Democratic team
The democratic team structure, as the name implies, does not enforce any formal team
hierarchyTypically, a manager provides theadministrative leadership. At different timesdifferent
members of the group provide technical leadership.

SOFTWARE ENGINEERING 23 MIT/CSE

Mixed control team organization

The mixed control team organisation, as the name implies, draws upon the ideas from both the
democratic organisation and the chief-programmer organisation.

STAFFING
Software project managers usually take the responsibility of choosing their team. Therefore,
they need to identify good software developers for the success of the project. A common
misconception held by managers as evidenced in their staffing, planning and scheduling practices, is
the assumption that one software engineer is as productive as another.

Who is a good software engineer?

Exposure to systematic techniques, i.e. familiarity with software engineering principles.
Good technical knowledge of the project areas (Domain knowledge)
Good programming abilities.
Good communication skills. These skills comprise of oral, written, and interpersonal skills.
High motivation.
Sound knowledge of fundamentals of computer science
Intelligence.
Ability to work in a team.
Discipline, etc.
RISK MANAGEMENT
A risk is any anticipated unfavourable event or circumstance that can occur while a project is
underway.

SOFTWARE ENGINEERING 24 MIT/CSE

Risk Identification

Project risks: Project risks concern various forms of budgetary, schedule, personnel, resource,
and customer-related problems. An important project risk is schedule slippage. Since, software
is intangible, it is very difficult to monitor and control a software project. It is very difficult to
control something which cannot be seen.

Technical risks: Technical risks concern potential design, implementation, interfacing, testing,
and maintenance problems. Technical risks also include ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence. Most
technical risks occur due the development team‘s insufficient knowledge about the product.

Business risks: This type of risks includes the risk of building an excellent product that no one
wants, losing budgetary commitments, etc.

Classification of risks in a project

Example 3.12 Let us consider a satellite based mobile communication product discussed in Case
Study 2.2 of Section 2.5. The project manager can identify several risks in this project. Let us classify
them appropriately.
What if the project cost escalates and overshoots what wasestimated?: Project risk.
What if the mobile phones that are developed become too bulky in size to conveniently carry?:
Business risk.
What if it is later found out that the level of radiation coming from the phones is harmful to human
being?: Business risk.
What if call hand-off between satellites becomes too difficult to implement?: Technical risk.

Risk Assessment
The objective of risk assessment is to rank the risks in terms of their damage causing potential. For
risk assessment, first each risk should be rated in two ways:
The likelihood of a risk becoming real (r).
The consequence of the problems associated with that risk (s).

Risk Mitigation
After all the identified risks of a project have been assessed, plans are made to contain the most
damaging and the most likely risks first. Different types of risks require different containment
procedures.
Avoid the risk: Risks can be avoided in several ways. Risks often arise due to project
constraints and can be avoided by suitably modifying the constraints. The different categories
of constraints that usually give rise to risks are:
 Process-related risk: These risks arise due to aggressive work schedule, budget, and
resource utilisation.
 Product-related risks: These risks arise due to commitment to challenging product
features (e.g. response time of one second, etc.), quality, reliability etc.
 Technology-related risks: These risks arise due to commitment to use certain technology
(e.g., satellite communication).

SOFTWARE ENGINEERING 25 MIT/CSE

 Transfer the risk: This strategy involves getting the risky components developed by a third
party, buying insurance cover, etc.
Risk reduction: This involves planning ways to contain the damage due to a risk. For
example, if there is risk that some key personnel might leave, new recruitment may be planned.
The most important risk reduction techniques for technical risks is to build a prototype that
tries out the technology that you are trying to use.

REQUIREMENTS ANALYSIS AND SPECIFICATION

The goal of the requirements analysis and specification phase is to clearly understand the
customer requirements and to systematically organize the requirements into a document called
the Software Requirements Specification (SRS) document.
The engineers who gather and analyze customer requirements and then write the requirements
specification document are known as system analysts in the software industry.
After understanding the precise user requirements, the analysts analyze the requirements to
weed out inconsistencies, anomalies and incompleteness.
They then proceed to write the software requirements specification (SRS) document. The SRS
document is the final outcome of the requirements analysis and specification phase.
Requirements analysis and specification phase mainly involves carrying out the following two
important activities:
o Requirements gathering and analysis
o Requirements specification

Requirements gathering and analysis

Requirements gathering is also popularly known as requirements elicitation.

Studying existing documentation:

The analyst usually studies all the available documents regarding the system to be developed
before visiting the customer site.
Customers usually provide statement of purpose (SoP) document to the developers.
To systematize this method of requirements gathering, the Delphi technique can be followed.

Interview:
Typically, there are many different categories of users of a software. Each category of users
typically requires a different set of features from the software.
It is important for the analyst to first identify the different categories of users and then
determine the requirements of each.

SOFTWARE ENGINEERING 26 MIT/CSE

Task analysis
The users usually have a black-box view of a software and consider the software as something
that provides a set of services (functionalities).
A service supported by a software is also called a task.

Scenario analysis
A task can have many scenarios of operation. The different scenarios of a task may take place
when the task is invoked under different situations.
For different types of scenarios of a task, the behaviour of the software can be different.

For example
Book is issued successfully to the member and the book issue slip is printed. The book is
reserved, and hence cannot be issued to the member. The maximum number of books that can be
issued to the member is already reached, and no more books can be issued to the member.

Form analysis
Form analysis is an important and effective requirements gathering activity that is undertaken
by the analyst, when the project involves automating an existing manual system.

Requirements Analysis

The main purpose of the requirements analysis activity is to analyse the gathered requirements
to remove all ambiguities, incompleteness, and inconsistencies from the gathered customer
requirements and to obtain a clear understanding of the software to be developed.

The following basic questions

Pertaining to the project should be clearly understood by the analyst before carrying out
analysis:
1. What is the problem?
2. Why is it important to solve the problem?
3. What exactly are the data input to the system and what exactly are the data output by the
system?
4. What are the possible procedures that need to be followed to solve the problem?
5. What are the likely complexities that might arise while solving the problem?
6. If there are external software or hardware with which the developed software has to
interface, then what should be the data interchange formats with the external systems?

During requirements analysis, the analyst needs to identify and resolve three main types of problems
in the requirements:

• Anomaly
• Inconsistency
• Incompleteness

SOFTWARE ENGINEERING 27 MIT/CSE

Anomaly: It is an anomaly is an ambiguity in a requirement. When a requirement is anomalous,
several interpretations of that requirement are possible. Any anomaly in any of the requirements can
lead to the development of an incorrect system, since an anomalous requirement can be interpreted in
the several ways during development.

Inconsistency: Two requirements are said to be inconsistent, if one of the requirements contradicts the
other.

Incompleteness: An incomplete set of requirements is one in which some requirements have been
overlooked. The lack of these features would be felt by the customer much later, possibly while using
the software. Often, incompleteness is caused by the inability of the customer to visualize the system
that is to be developed and to anticipate all the features that would be required. An experienced analyst
can detect most of these missing features and suggest them to the customer for his consideration and
approval for incorporation in the requirements.

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

After the analyst has gathered all the required information regarding the software to be
developed, and has removed all incompleteness, inconsistencies, and anomalies from the specification,
he starts to systematically organise the requirements in the form of an SRS document. The SRS
document usually contains all the user requirements in a structured though an informal form.

Users of SRS Document

Users, customers, and marketing personnel:
Software developers
Test engineers:
User documentation writers:
Project managers
Maintenance engineers

Why Spend Time and Resource to Develop an SRS Document?

Forms an agreement between the customers and the developers:
Reduces future reworks:
Provides a basis for estimating costs and schedules:
Provides a baseline for validation and verification
Facilitates future extensions:

Characteristics of a Good SRS Document

Concise
Implementation-independent
Traceable
Modifiable
Identification of response to undesired events
Verifiable

SOFTWARE ENGINEERING 28 MIT/CSE

Attributes of Bad SRS Documents
Over-specification
Forward references
Wishful thinking
Noise
Important Categories of Customer Requirements

An SRS document should clearly document the following aspects of software:

• Functional requirements
• Non-functional requirements
— Design and implementation constraints
— External interfaces required
— Other non-functional requirements
• Goals of implementation.

Functional requirements
The functional requirements capture the functionalities required by the users from the system.
It is useful to consider a software as offering a set of functions {fi} to the user.
These functions can be considered similar to a mathematical function f : I → O, meaning that a
function transforms an element (ii) in the input domain (I) to a value (oi) in the output (O).

Each function fi of the system can be considered as reading certain data ii, and then
transforming a set of input data (ii) to the corresponding set of output data (oi).
The functional requirements of the system, should clearly describe each functionality that the
system would support along with the corresponding input and output data set.
Considering that the functional requirements are a crucial part of the SRS document.

Non-functional requirements
The non-functional requirements are non-negotiable obligations that must be supported by the
software.

SOFTWARE ENGINEERING 29 MIT/CSE

 The non-functional requirements capture those requirements of the customer that cannot be
expressed as functions (i.e., accepting input data and producing output data).
Non-functional requirements usually address aspects concerning external interfaces, user
interfaces, maintainability, portability, usability, maximum number of concurrent users, timing,
and throughput (transactions per second, etc.).
The non-functional requirements can be critical in the sense that any failure by the developed
software to achieve some minimum defined level in these requirements can be considered as a
failure and make the software unacceptable by the customer.
Design and implementation constraints:
Design and implementation constraints are an important category of non-functional
requirements describe any items or issues that will limit the options available to the developers.
Some of the example constraints can be—corporate or regulatory policies that needs to be
honored; hardware limitations; interfaces with other applications; specific technologies, tools,
and databases to be used; specific communications protocols to be used; security
considerations; design conventions or programming standards to be followed, etc.
External interfaces required:
Examples of external interfaces are— hardware, software and communication interfaces, user
interfaces, report formats, etc.
To specify the user interfaces, each interface between the software and the users must be
described.
The description may include sample screen images, any GUI standards or style guides that are
to be help) that will appear on every screen, keyboard shortcuts, error message display
standards, and so on.
Other non-functional requirements:
This section contains a description of non- functional requirements that are neither design
constraints and nor are external interface requirements.
An important example is a performance requirement such as the number of transactions
completed per unit time.
Besides performance requirements, the other non-functional requirements to be described in
this section may include reliability issues, accuracy of results, and security issues.

Goals of implementation
The ‗goals of implementation‘ part of the SRS document offers some general suggestions
regarding the software to be developed.
These are not binding on the developers, and they may take these suggestions into account if
possible.

Functional Requirements
In order to document the functional requirements of a system, it is necessary to first learn to
identify the high-level functions of the systems by reading the informal documentation of the
gathered requirements.
The high-level functions would be split into smaller sub requirements. Each high-level function
is an instance of use of the system (use case) by the user in some way.
A high-level function is one using which the user can get some useful piece of work done

SOFTWARE ENGINEERING 30 MIT/CSE

Interactions between the user and the system in the withdraw-cash high-level functional
requirements

Each high-level requirement characterizes a way of system usage (service invocation) by some user to
perform some meaningful piece of work.

example, consider the withdraw-cash function of an automated teller machine (ATM) Since during the
course of execution of the withdraw-cash function, the user would have to input the type of account,
the amount to be withdrawn, it is very difficult to form a single high-level name that would accurately
describe both the input data. However, the input data for the sub functions can be more accurately
described.

SOFTWARE ENGINEERING 31 MIT/CSE

How to Identify the Functional Requirements?

The high-level functional requirements often need to be identified either from an informal problem
description document or from a conceptual understanding of the problem. Each high-level requirement
characterizes a way of system usage (service invocation) by some user to perform some meaningful
piece of work.

How to Document the Functional Requirements?

Once all the high-level functional requirements have been identified and the requirements problems
have been eliminated, these are documented. A function can be documented by identifying the state at
which the data is to be input to the system, its input data domain, the
output data domain, and the type of processing to be carried on the input data to obtain the output data.
R.1: Withdraw cash from ATM
Description:The withdraw cash function first determines the type of account that the user has and the
account number from which the user wishes to withdraw cash. It checks the balance to determine
whether the requested amount is available in the account. If enough balance is available, it outputs the
required cash, otherwise it generates an error message.
R.1.1: Select withdraw amount option
Input: ―Withdraw amount‖ option selected Output: User prompted to enter the account type
R.1.2: Select account type
I n p u t : User selects option from any one of the followings— savings/checking/deposit.
Output: Prompt to enter amount
R.1.3: Get required amount
Input: Amount to be withdrawn in integer values greater than 100 and less than 10,000 in multiples of
100.
Output: The requested cash and printed transaction statement.
Processing: The amount is debited from the user‘s account if sufficient balance is available, otherwise
an error message displayed.

Specification of large software:

If there are large number of functional requirements (much larger than seen). A better way to
organize the functional requirements in this case would be to split the requirements into sections of
related requirements.
For example, the functional requirements of a academic institute automation software can be
split into sections such as accounts, academics, inventory, publications, etc. When there are to o many
functional requirements, these should be properly arranged into sections. For example the following
can be sections in the trade house automation software:
• Customer management
• Account management
• Purchase management
• Vendor management
• Inventory management

SOFTWARE ENGINEERING 32 MIT/CSE

Traceability
Traceability means that it would be possible to identify (trace) the specific design component
which implements a given requirement, the code part that corresponds to a given design component,
and test cases that test a given requirement. Traceability analysis is an important concept and is
frequently used during software development.
For example, by doing a traceability analysis, we can tell whether all the requirements have
been satisfactorily addressed in all phases. It can also be used to assess the impact of a requirements
change. That is, traceability makes it easy to identify which parts of the design and code would be
affected, when certain requirement change occurs

Organisation of the SRS Document

1. Introduction
a. Purpose
b. Overview
c. Environmental characteristics
i. Hardare
ii. Peripherals
iii. people
2. Goals of implementation
3. Functional requirements
a. User class 1
i. Functional requirement 1.1
ii. Functional requirement 1.2
b. User class 2
i. Functional requirement 2.1
ii. Functional requirement 2.2
4. Non-functional requirements
a. External interfaces
b. User interfaces
c. Software interfaces
d. Communication interfaces
5. Behavioral description
a. System states
b. Events and actions

Example 4.9 (Personal library software):

Functional requirements
The software needs to support three categories of functionalities as
described below:
1. Manage own books
1.1 Register book
Description: To register a book in the personal library, the details of a
book, such as name, year of publication, date of purchase, price and
publisher are entered. This is stored in the database and a unique serial
number is generated.

SOFTWARE ENGINEERING 33 MIT/CSE

Input: Book details
Output: Unique serial number
R.1.2: Issue book
Description: A friend can be issued book only if he is registered. The various
books outstanding against him along with the date borrowed are first
displayed.
R.1.2.1: Display outstanding books
Description: First a friend’s name and the serial number of the book to be issued are
entered. Then the books outstanding against the friend should be displayed.
Input: Friend name
Output: List of outstanding books along with the date on which each was
borrowed.
R.1.2.2: Confirm issue book
If the owner confirms, then the book should be issued to him and the relevant
records should be updated.
Input: Owner confirmation for book issue. Output: Confirmation of book issue.
R.1.3: Query outstanding books
Description: Details of friends who have books outstanding against their name
is displayed.
Input: User selection
Output: The display includes the name, address and telephone numbers of
each friend against whom books are outstanding along with the titles of the
outstanding books and the date on which those were issued.
R.1.4: Query book
Description: Any user should be able to query a particular book from
anywhere using a web browser.
Input: Name of the book.
Output: Availability of the book and whether the book is issued out.
R.1.5: Return book
Description: Upon return of a book by a friend, the date of return is stored and
the book is removed from the borrowing list of the concerned friend.
Input: Name of the book.
Output: Confirmation message.

Techniques for Representing Complex Logic

There are two main techniques available to analyze and represent complex processing logic—decision
trees and decision tables.

Decision tree
A decision tree gives a graphic view of the processing logic involved in decision making and
the corresponding actions taken.
Decision tables specify which variables are to be tested, and based on this what actions are to
be taken depending upon the outcome of the decision making logic, and the order in which
decision making is performed.
The edges of a decision tree represent conditions and the leaf nodes represent the actions to be
performed depending on the outcome of testing the conditions.

SOFTWARE ENGINEERING 34 MIT/CSE

Decision table
A decision table shows the decision making logic and the corresponding actions taken in a
tabular or a matrix form.
The upper rows of the table specify the variables or conditions to be evaluated and the lower
rows specify the actions to be taken when an evaluation test is satisfied.
A column in the table is called a rule. A rule implies that if a certain condition combination is
true, then the corresponding action is executed.
The decision table for the

Decision table versus decision tree

Readability: Decision trees are easier to read and understand when the number of conditions are
small. On the other hand, a decision table causes the analyst to look at every possible combination of
conditions which he might otherwise omit.

Explicit representation of the order of decision making: In contrast to the decision trees, the order
of decision making is abstracted out in decision tables. A situation where decision tree is more useful
is when multilevel decision making is required. Decision trees can more intuitively represent
multilevel decision making hierarchically, whereas decision tables can only represent a Single decision
to select the appropriate action for execution.

Representing complex decision logic: Decision trees become very complex to understand when the
number of conditions and actions increase. It may even be to draw the tree on a single page. When
very large number of decisions is involved, the decision table representation may be preferred.

SOFTWARE ENGINEERING 35 MIT/CSE

Question Bank:

11 Mark Question:

1. Explain about the software responsibilities.

2. Write about the metrics for project size estimation .
3. Write about emprical estimation technique and analytical estimation technique.
4. Write about heuristic estimation techique or COCOMO models.
5. Explain about Halstead‘s software science- an analytical technique.
6. Explain briefly about schedulling with PERT chart and Gantt chart.
7. Explain about Organisation and Team Structures.
8. Explain about risk management.
9. Explain about Requirements Analysis and Specification.
10. Write about Software Requirements Specification (SRS) document.

Two Mark Question:

1. What is the main goal of software project management?

2. Write the Software Project Management Complexities.
3. What are the Responsibilities of a Software Project Manager?
4. What are the Skills Necessary for Managing Software Projects?
5. What are the Planning activities?
6. Define Lines of Code (LOC)
7. Write the Shortcomings of the LOC metric
8. Define Function Point (FP) Metric.
9. Write the conceptual idea behind the function point metric.
10. What are the steps in Function point (FP) metric computation?
11. Write the Formula to calculate UFP.
12. What are the different types of Project Estimation Techniques?
13. What are the two popular Empirical Estimation Techniques?
14. Define Expert Judgment.
15. Define Delphi cost estimation.
16. Define COCOMO – COnstructive COst estimation MOdel .
17. Define organic.
18. Define semidetached.
19. Define embedded.
20. What are the three stages in COCOMO model?
21. Write the formulas for estimating the effort based on the code size.
22. Write the formula for estimating the development time based on the effort
23. What are the Parameter of Intermediate COCOMO model.
24. What are the sub components of MIS ?
25. What are the three increasingly detailed cost estimation models in COCOMO model 2?
26. Write about Norden‘s Work.
27. Write about Putnam‘s Work.
28. Write about Jensen‘s Model.
29. Define scheduling.

SOFTWARE ENGINEERING 36 MIT/CSE

30. Write the tasks which project manager follows to schedule the project activities.
31. Define Work Breakdown Structure.
32. Define Activity Networks.
33. Define Critical Path Method (CPM) and Minimum time (MT).
34. Define Earliest start (ES) and Latest start time (LST).
35. Define Earliest finish time (EF), Latest finish (LF)and Slack time (ST).
36. How to compute the ES, EF, LS, LF and ST?
37. What are the cases in PERT Charts?
38. Define Gantt chart.
39. Define Functional format and Project format.
40. Functional versus project formats.
41. Define Matrix format.
42. Define Chief programmer team.
43. Define Democratic team.
44. Define Mixed control team organization.
45. Define Staffing.
46. Who is a good software engineer?
47. Define risk and types of Risk Management
48. Define Risk Assessment.
49. Define Risk Mitigation.
50. What are the ways to gather requirements?
51. What are the three main types of problems in the requirements?
52. Define Anomaly.
53. Define Inconsistency.
54. Define Incompleteness.
55. Define Software Requirements Specification (SRS).
56. Write the Users of SRS Document.
57. Why Spend Time and Resource to Develop an SRS Document?
58. Write the Characteristics of a Good SRS Document.
59. Write the Attributes of Bad SRS Documents.
60. What are the Important Categories of Customer Requirements?
61. Define Functional requirements.
62. Define Non-functional requirements.
63. Define Traceability
64. What are the Techniques for Representing Complex Logic?
65. Define Decision tree.
66. Define Decision table.
67. Decision table versus decision tree
68. What is a Formal Technique?
69. Define Syntactic domains.
70. Define Semantic domains.
71. Define Satisfaction relation.
72. Define Operational Semantics
73. What are the Merits and limitations of formal methods?
74. How to develop an axiomatic specifications?
75. What are the sections in An algebraic specification?

SOFTWARE ENGINEERING 37 MIT/CSE

76. What are the operators in An algebraic specification?
77. Properties of algebraic specifications
78. Define Software Configuration Management.
79. Define Auxiliary Functions.
80. What are the Necessity of Software Configuration Management?
81. What are the Configuration Management Activities?

SOFTWARE ENGINEERING 38 MIT/CSE