III B.

Sc Sem-5 Software Engineering

UNIT-I
INTRODUCTION:
 Software Engineering Process paradigms
 Project management Process and Project Metrics
 Software estimation
 Empirical estimation models
 Planning
 Risk analysis
 Software project scheduling

1 Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

1. Explain the Software Engineering Process paradigms?

Software:
 Software is more than just a program code. A program is an executable code, which
serves some computational purpose. Software is considered to be collection of executable
programming code, associated libraries and documentations. Software, when made for a specific
requirement is called software product.
 The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of engineering to software.
Software Paradigms:

Programming paradigm is a subset of Software design paradigm which is further a subset of

Software development paradigm.
1. Software Development Paradigm: It includes various researches and requirement gathering
which helps the software product to build.
 Requirement gathering
 Software design
 Programming
2. Software Design Paradigm: This paradigm is a part of Software Development and includes
 Design
 Maintenance
 Programming
3. Programming Paradigm: This paradigm is related closely to programming aspect of
software development. This includes
 Coding
 Testing
 Integration
2 Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

Characteristics of good software:

Operational:
This tells us how well the software works in operations. It can be measured on:
 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety
Transitional:
This aspect is important when the software is moved from one platform to another:
 Portability
 Interoperability
 Reusability
 Adaptability
Maintenance:
This aspect briefs about how well the software has the capabilities to maintain itself in the ever-
changing environment:
 Modularity
 Maintainability
 Flexibility
 Scalability
SOFTWARE ENGINEERING PROCESS MODELS
1. THE WATERFALL MODEL
3
Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

1. Requirements analysis and definition: The system’s services, constraints, and goals
are established by consultation with system users. They are then defined in detail and serve as a
system specification.
2. System and software design: The systems design process allocates the requirements
to either hardware or software systems by establishing an overall system architecture. Software
design involves identifying and describing the fundamental software system abstractions and
their relationships.
3. Implementation and unit testing: The software design is realized as a set of programs or
program units. Unit testing involves verifying that each unit meets its specification.
4. Integration and system testing: The individual program units or programs are integrated and
tested as a complete system to ensure that the software requirements have been met. After
testing, the software system is delivered to the customer.
5. Operation and maintenance :The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier stages of the life
cycle, improving the implementation of system units and enhancing the system’s services as new
requirements are discovered.
Disadvantages:
Real projects rarely follow the sequential flow since they are always iterative
The model requires requirements to be explicitly spelled out in the beginning, which is
often difficult
A working model is not available until late in the project time span
2. THE INCREMENTAL PROCESS MODEL
Linear sequential model is not suited for projects which are iterative in nature
Incremental model suits such projects
Used when initial requirements are reasonably well-defined and compelling need to
provide limited functionality to users quickly and then refine and expand on that
functionality in later releases
It combines elements of waterfall model in an iterative fashion.
The incremental model applies linear sequences in a staggered ashion as
calendar time progresses.Each linear sequence provides deliverable increments of software.For
ex word processing sotware developed sing incremental paradigm might deliver basic file
management,editing,and document production functions in 1 st increment ;more sophisticated
editing and document production capabilities in 2 nd increment;spelling and grammar checking in
4 Page

3rd increment; etc

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

1st increment constitutes Core product

Basic requirements are addressed
Core product undergoes detailed evaluation by the customer
plan is developed for the next increment Plan addresses the modification of core
product to better meet the needs of customer
Process is repeated until the complete product is produced
The incremental process model unlike prototyping and other evolutionary approaches,is iterative
in nature.But unlike prototyping,the incremental model focuses on delivery of an operational
product with each increment. This model is particularly useul when staffing is unavailable for a
complete implementation by business deadline that has been established for the project.
3. RAD MODEL (Rapid Application Development)
ADVANTAGES
An incremental software process model
Having a short development cycle
High-speed adoption of the waterfall model using a component based construction
approach
Creates a fully functional system within a very short span time of 60 to 90 days
Multiple software teams work in parallel on different functions
Modeling encompasses three major phases: Business modeling, Data modeling and
process modeling
5

Construction uses reusable components, automatic code generation and testing

Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

The RAD Model

Team # n
Modeling
Business modeling
Data modeling
Process modeling

Construction
Component reuse
Team # 2 automatic code
generation
Communication Modeling testing

Business modeling
Data modeling
Process modeling

Construction
Planning Team # 1 Component reuse
automatic code
generation
testing
Modeling
Business modeling Deployment
Data modeling integration
Process modeling delivery
feedback

Construction
Component reuse
automatic code
generation
testing

12

DIS-ADVANTAGES
Problems in RAD
Requires a number of RAD teams
Requires commitment from both developer and customer for rapid-fire completion of
activities otherwise it fails
If system cannot be modularized properly project will fail.
Not suited when technical risks are high
4. PROTOTYPING
Mock up or model( throw away version) of a software product
Used when customer defines a set of objective but does not identify input,output,
or processing requirements
Developer is not sure of:
• efficiency of an algorithm
• adaptability of an operating system
• human/machine interaction
Begins with requirement gathering
Identify whatever requirements are known
Outline areas where further definition is mandatory
A quick design occur
6

Quick design leads to the construction of prototype

Page

Prototype is evaluated by the customer

Requirements are refined
Department of Computer Science, TJPS College, Guntur
Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

Prototype is turned to satisfy the needs of customer,while at the same time enabling
developer to better understand hat needs to be done.
Ideally prototype serves as a mechanism for identifying software requirements.

Disadvantages:
In a rush to get it working, overall software quality or long term maintainability
are generally overlooked
The developer often makes implementation compromises in order to get a prototype
working quickly.An inappropriate OS or PL may be used simply because it is available
and known;an inefficient algorithm may be implemented simply to demonstrate
capability.After a time,developer may become comfortable with these choices and forget
all the reasons why they were inappropriate.
5. Spiral model
This is a model proposed by boehm it is an evolutionary model which combines the best
feature of the classical life cycle and the iterative nature of prototype model
Include new element : Risk element
Starts in middle and continually visits the basic tasks of communication,
planning,modeling,construction and deployment
Using spiral model,software is developed in a series of evoltionary releases.During early
iterations,the release might be a model or prototype.During later iterations increasinly
more complete versions of engineered system are produced
Realistic approach to the development of large scale system and software
Unlike other process models that end when software is delivered,the spiral model can be
adapted to apply through out the life of computer software.Therefore the first circuit
around the spiral represent a “concept development project” which starts at the core of
the spiral and contines for multiple iterations until concept development is complete.If
7 Page

the concept is to be developed into an actual product,process proceeds outward on the

spiral and a “new product development project “commences.The new product will evolve

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

through a number of iterations around the spiral.Later,a circuit around spiral might be
used to represent a “product enhancement project”.The spiral remains operative until the
software is retired.
It is difficult to convince customers that the evolutionary approach is controllable.

20

-------------------------------------------xxxxxxxxxxxxxxxxxxxxxx---------------------------------------
2. Explain the project management process and project metrics?
Process metrics are collected across all projects and over long periods of time. Their aim is to
provide set of process indicators that lead to long term software process improvement
Project Metrics enable a software project manager to
1. Assess status of an ongoing project
2. Track potential risks
3. Uncover problem areas before they go critical
4. Adjust workflow
5. Evaluate project teams ability to control quality
8
Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

Software Measurement
Software measurement can be categorized as
Direct Measurement
Direct measure of software process include cost and effort
Direct measure of product includes lines of code, Execution speed, memory size, defects
per reporting time.
Indirect Measurement
Indirect measure examines the quality of software product itself(e.g. :-functionality,
complexity, efficiency, reliability and maintainability)
Reasons for measurement
To gain baseline for comparison with future assessment
To determine status with respect to plan
To predict the size, cost and duration estimate
To improve the product quality and process improvement
The metrics in software Measurement are
1. Size oriented metrics
2. Function oriented metrics
3. Object oriented metrics
4. Web based application metric
1. Size oriented metrics:
It totally concerned with the measurement of software.
A software company maintains a simple record for calculating the size of the software.
9

It includes
Page

errors per KLOC (thousand lines of code)

defects per KLOC
Department of Computer Science, TJPS College, Guntur
Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

$ per LOC
pages of documentation per KLOC
errors per person-month
Errors per review hour
LOC per person-month
$ per page of documentation
2. Function Oriented Metrics:
Measures the functionality derived by the application
The most widely used function oriented metric is Function point
Function point is independent of programming language
Typical Function-oriented metrics
Errors per FP (thousand lines of code), defects per FP, $ per FP, pages of documentation per FP,
FP per person-month
3. Object-Oriented Metrics:
Relevant for object oriented programming
Based on the following
Number of scenario scripts (use-cases)
Number of key classes Key classes are highly independent components that are defined early in
object-oriented analysis
Number of support classes required to implement the system but are not immediately related
to the problem domain
Average number of support classes per key class (analysis class)
Number of subsystems an aggregation of classes that support a function that is visible to the
end-user of a system
4. Web Engineering Project Metrics :
Measures that can be collected are
Number of static Web pages the end-user has no control over the content displayed on
the page
Number of dynamic Web pages end-user actions result in customized content
displayed on the page
Number of internal page links (internal page links are pointers that provide a hyperlink
to some other Web page within the WebApp
10

Number of persistent data objects As the number of persistent data objects grows the
Page

complexity of webapps also grows

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

Number of external systems interfaced As the requirement for interfacing grows,

system complexity and development effort also increases
Number of static content objects They encompass graphical,audio,video information
incorporated into the webapp
Number of dynamic content objects Generated based on end-user actions
Number of executable functions An executable function provides some computational
service to end-user. As number of functions grows construction effort increasesWe can
define a metric that reflects degree of end-user customization for webapp to effort
expended on web-project
Nsp=number of static pages
Ndp=number of dynamic pages
Customization index C=Ndp/(Ndp+Nsp)
---------------------XXXXXXXXXXXX-------------------------------------------------------------
3. Explain the software estimation?
Software project estimation can be transformed from a black art to a series of
systematic steps that provide estimates with acceptable risk. To achieve reliable cost and effort
estimates, a number of options arise:
1. Delay estimation until late in the project (obviously, we can achieve 100 percent accurate
estimates after the project is complete!).
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost and effort estimates.
4. Use one or more empirical models for software cost and effort estimation.
The first option Cost estimates must be provided up-front. However, you should
recognize that the longer you wait, the more you know, and the more you know, the less
likely you are to make serious errors in your estimates.
The second option can work reasonably well, if the current project is quite similar to past
efforts and other project influences (e.g., the customer, business conditions, the software
engineering environment, deadlines) are roughly equivalent. Unfortunately, past
experience has not always been a good indicator of future results.
The remaining options are viable approaches to software project estimation. Each used as a
cross-check for the other. Decomposition techniques take a divide-and-conquer it has been
released to the end user.
11

Software project estimation by decomposing a project into major functions and

Page

related software engineering activities, cost and effort estimation can be performed in a stepwise
fashion. Empirical estimation models can be used to complement decomposition techniques and

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

offer a potentially valuable estimation approach in their own. A model is based on experience
(historical data) and takes the form
d = f (vi)
where d is one of a number of estimated values (e.g., effort, cost, project duration)
and vi are selected independent parameters (e.g., estimated LOC or FP).
Automated estimation tools implement one or more decomposition techniques or
empirical models and provide an attractive option for estimating.
In such systems, the characteristics of the development organization (e.g., experience,
environment) and the software to be developed are described.
Cost and effort estimates are derived from these data.
Each of the viable software cost estimation options is only as good as the historical data
used to seed the estimate. If no historical data exist, costing rests on a very shaky
foundation.
--------------------------------xxxxxxxxxxxxxxxxxxxxxxx-------------------------------------------
4. Explain the software empirical estimation models?
The empirical data that support most estimation models are derived from a
limited sample of projects. For this reason, no estimation model is appropriate for all classes of
software and in all development environments. Therefore, you should use the results obtained
from such models judiciously.
An estimation model should be calibrated to reflect local conditions.
The model should be tested by applying data collected from completed projects, plugging the
data into the model, and then comparing actual to predicted results. If agreement is poor, the
model must be tuned and retested before it can be used.
1. The Structure of Estimation Models :
A typical estimation model is derived using regression analysis on data collected from
past software projects. The overall structure of such models takes the form [Mat94]
E = A+B* (ev)C
where A, B, and C are empirically derived constants, E is effort in person-months, and
ev is the estimation variable (either LOC or FP). the majority of estimation models have some
form of project adjustment component that enables E to be adjusted by other project
characteristics Among the many LOC-oriented estimation models proposed in the literature are
E =5.2 *(KLOC)0.91 Walston-Felix model
12

E =5.5 + 0.73* (KLOC)1.16 Bailey-Basili model

Page

E =3.2 *(KLOC)1.05 Boehm simple model

E =5.288* (KLOC)1.047 Doty model for KLOC>9

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

FP-oriented models have also been proposed. These include

E = -91.4+0.355 FP Albrecht and Gaffney model
E = -37+0.96 FP Kemerer model
E = -12.88+0.405 FP Small project regression model
2. The COCOMO II Model :
“Software engineering economics,” Barry Boehm introduced a hierarchy of software
estimation models bearing the name COCOMO, for COnstructive COst MOdel.
• Application composition model:It is 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.
• Early design stage model : It is used once requirements have been stabilized and basic
software architecture has been established.
• Post-architecture-stage model: It is 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.

Object type Complexity weight

Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL component 10

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, and (3) components.
The object point count is adjusted:
NOP = (object points) *[(100 -%reuse)/100]
Where NOP is defined as new object points.
general software reuse is to be applied, the percent of reuse (%reuse).
“Productivity rate” must be derived and presents the productivity rate
PROD =NOP/person-months
for different levels of developer experience and development environment maturity. Once the
13

productivity rate has been determined, an estimate of project effort is computed using
Page

Estimated effort =NOP/PROD

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

Very Very
Developer's experience/capability Low Nominal High
low high

Very Very
Environment maturity/capability Low Nominal High
low high

PROD 4 7 13 25 50

3. The Software Equation:

The Software equation is a dynamic multivariable model that assumes a specific distribution of
effort over the life of a software development project.
E= [(KLOC * B0.333)/p3] * (1/t4)
E effort in person-months or person-years
t project duration in months or years
B “special skills factor”
P “productivity parameter
You should note that the software equation has two independent parameters:
(1) An estimate of size (in LOC) and
(2) An indication of project duration in calendar months or years.
---------------------------------------XXXXXXXXXXXXXXXXXXXXX---------------------------
5. Explain the Software Project Planning?
The software project management process begins with a set activity that are collectively
called project planning. The first of these activities is estimation. Whenever estimates are made,
we look into the future and accept some degree of uncertainty.
Project Planning Objectives
The Objective of software project is to provide a framework that enables the manager to
make reasonable estimates of resources, cost, and schedule. These estimates are made within a
limited time frame at the beginning of a software project and should be updated regularly as the
project progresses. In addition, estimates should attempt to define “best case” and “worst case”
scenarios so that projects outcomes can be bounded.
The planning objective is achieved through a process of information discovery that leads
to reasonable estimates.
---------------------------XXXXXXXXXXXXXX-----------------------------------------------
14 Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

6. Explain the Risk Analysis?

Risk is an undesired event or circumstance that occur while a project is underway
 It is necessary for the project manager to anticipate and identify different risks that
 a project may be susceptible to.
Risk Management aims at reducing the impact of all kinds of risk that may affect a project
by identifying, analyzing and managing them
1. Reactive vs Proactive Risk Strategies
Reactive Risks: project team reacts to risks when they occur.
Proactive Risks :Potential risks are identified, their probability and impact are assessed, and
they are ranked by importance.The software team establishes a plan for managing risk.
2. Software Risks
Risk always involves two characteristics
Uncertainty the risk may or may not happen;
Loss if the risk becomes a reality, unwanted consequences or losses will occur.
When risks are analyzed, it is important to quantify the level of uncertainty and the degree
of loss associated with each risk
The type of risks that we likely encounter as software is built?
 Project risk: Threaten the project plan and affect schedule and resultant cost
 Technical risk: Threaten the quality and timeliness of software to be produced
 Business risk: Threaten the viability of software to be built
 Known risk: These risks can be recovered from careful evaluation
 Predictable risk: Risks are identified by past project experience
 Unpredictable risk: Risks that occur and may be difficult to identify
3. Risk Identification
Risk identification 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.
Two distinct types of risks for each category of risks specified above
 Generic risks are a potential threat to every software project.
 Product-specific risks can be identified only by those with a clear understanding of the
technology, the people, and the environment that is specific to the project at hand.
One method for identifying risks is to create a risk item checklist.
15

The checklist can be used for risk identification

Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

 Product size risks associated with the overall size of the software to be built or modified.
 Business impact risks associated with constraints imposed by management or the
marketplace.
 Customer characteristics risks associated with the sophistication of the customer and
the developer's ability to communicate with the customer in a timely manner.
 Process definition risks associated with the degree to which the software process has
been defined
 Development environment risks associated with the availability and quality of the tools
to be used to build the product.
 Technology to be built risks associated with the complexity of the system to be built and
the "newness" of the technology that is packaged by the system.
 Staff size and experience risks associated with the overall technical and project
experience of the software engineers who will do the work.
Risk Components and Drivers
The risk components are defined in the following manner.
 Performance risk—the degree of uncertainty that the product will meet its requirements
and be fit for its intended use.
 Cost risk—the degree of uncertainty that the project budget will be maintained.
 Support risk—the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance.
 Schedule risk—the degree of uncertainty that the project schedule will be maintained
and that the product will be delivered on time.
4. Risk Projection
It estimates the impact of risk on the project and the product
Risk projection, also called risk estimation, attempts to rate each risk in two ways
 The likelihood or probability that the risk is real
 The consequences of the problems associated with the risk, should it occur.
The project planner, along with other managers and technical staff, performs Three risk
projection activities
 establish a scale that reflects the perceived likelihood of a risk
 delineate the consequences of the risk
 estimate the impact of the risk on the project and the product, note the overall accuracy
16

of the risk projection so that there will be no misunderstandings

Page

Developing a Risk Table

A risk table provides a project manager with a simple technique for risk projection

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

Impact values
Catastrophic-1 Critical-2 Marginal-3 Negligible-4

A project team begins by listing all risks. This can be accomplished with the help of the risk item
checklists Each risk is categorized in the second column. The probability of occurrence of each
risk is entered in the next column of the table. The probability value for each risk can be
estimated by team members individually. Next, the impact of each risk is assessed.
Once the first four columns of the risk table have been completed, the table is sorted by
probability and by impact. High-probability, high-impact risks percolate to the top of the table,
and low-probability risks drop to the bottom. This accomplishes first-order risk prioritization.

17 Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and
Management Plan or alternatively, a collection of risk information sheets developed for all risks
that lie above the cutoff.
Assessing Risk Impact
The overall risk exposure, RE, is determined using the following relationship
RE = P x C
Where
P is the probability of occurrence for a risk, and
C is the cost to the project should the risk occur
For example, assume that the software team defines a project risk in the following manner:
Risk identification. Only 70 percent of the software components scheduled for reuse will, in
fact, be integrated into the application.
Risk probability. 80% (likely).
Risk impact. 60 reusable software components were planned. If only 70 percent can be used, 18
components would have to be developed from scratch (in addition to other custom software that
has been scheduled for development). Since the average component is 100 LOC and local data
indicate that the software engineering cost for each LOC is $14.00,
the overall cost (impact) to develop the components would be 18 x 100 x 14 = $25,200.
Risk exposure. RE = 0.80 x 25,200 ~=$20,200.
5. Risk Refinement
One way to do this is to represent the risk in condition-transition-consequence (CTC).
Using the CTC format for the reuse risk we can write:
This general condition can be refined in the following manner:
Subcondition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards.
Subcondition 2. The design standard for component interfaces has not been solidified and may
not conform to certain existing reusable components.
Subcondition 3. Certain reusable components have been implemented in a language that is not
supported on the target environment.
6. Risk Mitigation Monitoring and Management
Its goal is to assist project team in developing a strategy for dealing with risk
If a software team adopts a proactive approach to risk, avoidance is always the best strategy.
18

This is achieved by developing a plan for risk mitigation. For example, assume that high staff
Page

turnover is noted as a project risk, r1. Based on past history and management intuition, the

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

likelihood, l1, of high turnover is estimated to be 0.70 percent, and the impact, x1, is projected at
level 2.
To mitigate this risk, project management must develop a strategy for reducing turnover.
Among the possible steps to be taken are
 Meet with current staff to determine causes for turnover
 Mitigate those causes that are under your control before the project starts.
 Once the project commences, assume turnover will occur and develop techniques
to ensure continuity when people leave.
 Organize project teams so that information about each development activity is
widely dispersed.
 Define work product standards and establish mechanisms to be sure that all
models and documents are developed in a timely manner.
 Conduct peer reviews of all work
 Assign a backup staff member for every critical technologist.
As the project proceeds, risk monitoring activities commence
In the case of high staff turnover, the following factors can be monitored:
 General attitude of team members based on project pressures.
 The degree to which the team has jelled.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
In addition to monitoring these factors, the project manager should monitor the effectiveness of
risk mitigation steps. For example, a risk mitigation step noted here called
Risk management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality. Continuing the example, the project is well underway and a
number of people announce that they will be leaving. If the mitigation strategy has been
followed, backup is available, information is documented, and knowledge has been dispersed
across the team.
In addition, the project manager may temporarily refocus resources to those functions that are
fully staffed, enabling newcomers who must be added to the team to “get up to speed.” Those
individuals who are leaving are asked to stop all work and spend their last weeks in “knowledge
transfer mode.”
19

It is important to note that RMMM steps incur additional project cost. For example, spending the
Page

time to "backup" every critical technologist costs money.

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

7. RMMM PLAN
1)Risk Avoidance(mitigation) Proactive planning for risk avoidance. This is achieved by
developing a plan for risk mitigation.
2)Risk Monitoring what factors can we track that will enable us to determine if the risk is
becoming more or less likely?
 Assessing whether predicted risk occur or not
 Ensuring risk aversion steps are being properly applied
 Collection of information for future risk analysis
 Determine which risks caused which problems
--------------------------------------xxxxxxxxxxxxxxxxxxx------------------------------------------
7. Explain the Project Scheduling?
1. Basic Principles
Compartmentalization The project must be compartmentalized into a number of manageable
activities and tasks. To accomplish compartmentalization, both the product and the process are
refined.
Interdependency The interdependency of each compartmentalized activity or task must be
determined. Some tasks must occur in sequence, while others can occur in parallel. Some
activities cannot commence until the work product produced by another is available. Other
activities can occur independently.
Time allocation Each task to be scheduled must be allocated some number of work units (e.g.,
person-days of effort). In addition, each task must be assigned a start date and a completion date
that are a function of the interdependencies and whether work will be conducted on a full-time or
part-time basis.
Effort validation Every project has a defined number of people on the software team. As time
allocation occurs, you must ensure that no more than the allocated number of people has been
scheduled at any given time. For example, consider a project that has three assigned software
engineers (e.g., three person-days are available per day of assigned effort4). On a given day,
seven concurrent tasks must be accomplished. Each task requires 0.50 person-days of effort.
More effort has been allocated than there are people to do the work.
Defined responsibilities Every task that is scheduled should be assigned to a specific team
member.
Defined outcomes Every task that is scheduled should have a defined outcome.
20

Defined milestones Every task or group of tasks should be associated with a project milestone.
Page

A milestone is accomplished when one or more work products has been reviewed for quality and
has been approved.

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance
III B.Sc Sem-5 Software Engineering

2. The Relationship between People and Effort

In small software development project a single person can analyze requirements, perform design,
generate code, and conduct tests. As the size of a project increases, more people must become
involved.
The relation- Effort
ship between cost 4 4
effort and Ea = m (td /t a )
delivery time Ea = effort in person-months
Impossible
region td = nominal delivery time for schedule
to = optimal development time (in terms of cost)

Ed ta = actual delivery time desired

E
o

td to Development time
Tmin = 0.75T d

“If we fall behind schedule, we can always add more programmers and catch up later in the
project”. The Putnam-Norden-Rayleigh (PNR) Curve5 provides an indication of the relationship
between effort applied and delivery time for a software project.
3. Effort Distribution
A recommended distribution of effort across the software process is often referred to as the
40–20–40 rule. Forty percent of all effort is allocated to frontend analysis and design. A similar
percentage is applied to back-end testing. You can correctly infer that coding (20 percent of
effort) is deemphasized. A range of 20 to 25 percent of effort is normally applied to software
design. If software is human rated (i.e., software failure can result in lossof life), even higher
percentages are typical.

Important Questions
1. Explain the Software Engineering Process paradigms?(2017)
2. Explain the project management process and project metrics?
3. Explain the software estimation?(2017)
4. Explain the software empirical estimation models?
5. Explain the Software Project Planning?
6. Explain the Risk Analysis?
7. Explain the Project Scheduling?
21 Page

Department of Computer Science, TJPS College, Guntur

Prepared By K.Nageswara Rao..8 Year Teachning Experiance