SOFTWARE ENGINEERING

UNIT I
Introduction:
SOFTWARE ENGINEERING:
The systematic collection of decades of programming experience together with
the innovations made by researcher towards developing the high quality software in
a cost efective manners.
Issues:
Past experience
Designing system
Pragmatic approach
uantitative principles
Past experience:
!oftware engineering ma"es heavy use of past experience. It is
systematically arranged and theoretically basis for then are provided wherever
possible.
Designing system:
Designing a system# several con$ict goals might have to be optimi%ed. In
such situations no unique solution may exit and several native solutions may be
proposed. !electing on appropriate solution out of several candidate solutions
various trade of are made based on issues such as#
&ost
'aintainability
(sability
To arrive at the )nal solutions# several iterations and bac"trac"ing may have to be
performed.
Pragmatic approach:
* pragmatic approach to cost efectiveness is adopted and economic
concerns are addressed.
uantitative principles:
+ngineering disciplines are based on well understand and quantitative
principles.
Software engineering Vs Science:
!oftware engineering !cience
Past experience:
!ystematically arranged
and theoretically basis for
them are provided
whenever possible.
Designing system:
!everal con$ict goals
might have to be
optimi%ed.
Pragmatic approach:
&ost efectiveness is
adopted and economic
concerns are addressed.
uantitative principles:
It is well understand
and quantitative principles.
,nly exact solutions
are accepted by the
science.
,nly unique solutions
are possible.
!cience does not
concern itself with practical
issues such as cost#
maintainability and
usability.
!ub-ective -udgment
which are based on
qualitative.
THE SW ENGINEERING !IS"I#$INE ITS EVO$UTION AN! I%#A"T:
+volution of an art into and engineering discipline
!olution to the s.w crisis
+volution of an art into and engineering:
The exploratory programming style is a very informal style of program
development approach.
There are no set rules or recommendations that one has to adhere to every
programmer himself evolves his own s.w development techniques guided by#
Intuition
+xperience
/hims
0ancies
The exploratory style is also the one that is normally adopted by all students and
novice programmers who do not have any exposure to s.w engineering principles.
+soteric "nowledge:
To analy%e the evolution of s.w development style over last )fty years easily
notice that is has evolved form an esoteric art form to a craft form and then slowly
emerged as a engineering discipline.
+ach days of programming there were
1 2ood programmers
1 3ad programmers
The good programmers "now certain principles that they seldom shared with
the bad programmers. *ll good principles along with research innovations have
systematically been organi%ed into a body of "nowledge that forms the discipline of
!+.
&ritics point out that many of the methodologies and guidelines provided by
the !+ discipline scienti)c basic# sub-ective and inadequate. There is no denying the
fact that adopting s.w engineering techniques facilitates development of high
quality s.w in a cost efective and timely manner.
* solution to the s.w crisis:
!oftware crisis
!ymptoms
&auses and solution

!oftware crisis:
The expenses that organi%ations all around the world are incurring of s.w
purchases as compared to these on h.w purchases have been showing a worrying
trend over the years.
!ymptoms:
The s.w products turning out to be more expensive than h.w but they also
present a host of other problems to the customer i.e.
1 Di4cult to alter
1 Debug
1 +nhance
1 (se resources non optimally
1 0ail to meet user requirements
1 0requency crash
1 Delivered late
&auses:
1 5apidly increasing problem si%es
1 6ac" of adequate training in s.w engineering techniques
1 Increasing s"ill shortage
1 6ow productivity improvement
RE%E!&SO$UTION:
Program 7.s products
Types of s.w development pro-ects
1 s.w product development pro-ects
1 outsourced pro-ects
!.w pro-ects being underta"en by Indian companies
#rogra' Vs (roducts:
Program:
Programs are developed by individuals for their personal use. Its small in si%e
and have limited functionality. The author of a program is usually the sole user of
the program and himself maintains the program.
+x# the program developed by a student as part of his class assignments are
programs and not s.w products.
Products.!oftware products:
!.w products have multiple users and have good user i.f proper user manuals
and good documentation support. !.w product has a large no of users it is
systematically designed carefully implemented and thoroughly tested.
!.w products consists of
1 Program code
1 Documentation
5equirement speci)cation document
Design document
Test document
(sers manuals
!.w engineers:
/ho develop s.w product s.w engineering usually wor" together in a team to
develop a s.w product# it is necessary for them to adopt some systematic
development methodology. ,therwise they would )nd it very di4cult to i.f and
understand each other8s wor" and produce a coherent set of documents.
Programmer:
/ho write programs.
T)(es of sw de*e+o('ent (ro,ects:
9. !.w product development pro-ects
:. ,utsourced pro-ects
9. !.w product development pro-ects:
*n s.w product can either be a generic or a custom developed product.
2eneric product:
2eneric products are used by a large and diverse range of customers.
+x#
1 ,perating system ;'icrosoft windows<
1 D3'! ;,racle<
1 3an"ing s.w products ;0inancial<
* company developing a generic product determines.
1 /hat may be useful to a large cross section of users
1 The product speci)cation on its own
&ustomi%ed s.w product:
It is developed according to the speci)cation drawn up by one or at most a
few customers. &ompany developed customi%ed s.w by tailoring some of their
existing products.
+x# when an academic institution wishes to have a s.w that would automate
its important activity such as student registration# grading# fee collection# etc#.
:. ,utsourced pro-ects:
* company developing a s.w product to outsource some part of its wor" as a
pro-ect to another company. *n outsourced pro-ect is a small part of some product
development all outsourced pro-ects are usually small in si%e and are normally
completed within a yen.

!.w products being underta"en by Indian companies:
Indian s.w industries have excelled in executing outsourced s.w pro-ects and
have made a name for them all over the world.
E%ERGEN"E OF SW ENGINEERING:
+arly computer programming
=igh level language programming
&ontrol $ow based design
Data structure oriented design
Data $ow oriented design
,b-ect oriented design
,ther developments
Ear+) co'(uter (rogra''ing:
In early days the computer programs were developed in machine language
and assembly languages. The programmer does not have idea about writing the
program but he wrote programs by hearing the programs. This is "nown as build
and )x or exploratory programs
Hig- +e*e+ +anguage (rogra''ing:
+arly >?8s semiconductor transistors replaced the vacuum tube based circuit
in a computer it become possible to solve larger and more complex problems.
=igh level languages#
1 0,5T5*@
1 *62,6
1 &,3,6
1 P*!&*6
1 3*!I&
*dvantages:
To reduced the efort required to develop s.w products and helped
programmers to write larger programs.
"ontro+ .ow /ased design:
The programs control $ow structure indicates the sequence in which
programs statements are executed. To develop programs having good control $ow
structures using tools such as#
*lgorithm:1 !tep by step program
0lowchart:1 Pictorial representation
Types of program#
9. !tructured program
:. (nstructured program
9. !tructured program:
It uses only sequence selection and iteration types of constructs and is
modular program.
'odular program:1 programs are divided into modules or functions.
+x#
If ;privilegedAcustomer<BB;customerAsavingsAbalanceCwithdrawalArequest<
D
*ctivateAdispenser ;withrawlArequest<E
F
+lse
Print ;error<E
+ndAtransaction;<E
0lowchart:
Disadvantages of unstructured program:
It uses many 2,T, statements leads to confusion.
:. (nstructured program:
If IcustomerAsavingAbalanceCwithdrawalArequest<
D
9??: issueAmoneyGT5(+E
2oto 99?E
F
+lseif ;privilegedAcustomerGGT5(+<
2oto 9??E
2oto 9:?E
+lse
2oto 9H?E
99?: activateAcashAdispenser ;withdrawalArequest<E
2oto 9H?E
9:?: print ;error<
9H?: endAtransaction;<E
!ata structure oriented design:
Data structure oriented techniques )rst a program data structures are
designed. This is the introduction of integrated circuits. I&8s are used to solve more
complex problems and develop larger and more complicated s.w products.
The program designing is derived from the data structure. It8s designed using
the notations for sequence# selection and iteration.
+x# I!P methodology ;9JKL< M Iac"son structured programming
!ata .ow oriented design:
It recommends that the ma-or data items handled by a system must )rst be
identi)ed and then processing required on these data items to produce the desired
o.p should be determined.
It introduced 76!I circuits and to develop a error less program using D0D.
+x# *utomated car assembly plant
+ngine Door
!tore store
*ssembled
&hassis partly car &*5
/ith
+ngine assemble
car
&hassis wheel
!tore store
O/,ect oriented design:
,,D is an intuitively appealing approach where the natural ob-ects relevant
to a program are identi)ed and then relationship among the ob-ect such as
composition reference and inheritance.
+ach ob-ect acts as data hiding entity.
3ene)ts#
1 !implicity
1 5euse
1 6ower development time
1 6ower development cost
1 5obust code
1 +asier to maintenance
"-ange in sw de*e+o('ent:
9. *n important diference is that exploratory s.w development style is based on
error correction while s.w engineering based on error prevention. The
exploratory style errors are detected only during the )nal product testing.
:. The exploratory style coding was considered synonymous with s.w
development.
H. * lot of attention is paid to user requirement speci)cation to develop a clear
and correct speci)cation of the problem before any development activity
starts.
N. Diferent design phases
1 &oherent design models
1 &omplete design models
L. Periodic reviews are being carried out during all stages of the development
process such as phase containment of errors ;detection and corrections<.
>. !.w testing has become very systematic and standard testing techniques are
available.
K. 7isibility of the product through various development activities.
O. Pro-ects are being thoroughly planned.
It includes#
1 Types of estimation
1 5esource scheduling
1 Development of pro-ect trac"ing plans
*utomation tools such as#
1 &on)guration management
1 &ost estimation
1 !cheduling
0it

engi
ne
0it
door
s
0it
whe
el
Pain
t P
test
Visi/i+it):0 Production of good quality consistent and peer review
documents at the end of every s.w development activity.
SW !EVE$O#%ENT $IFE "&"$E %O!E$S 1S!$"2:
Introduction:
* life cycle model prescribes the diferent activities that need to be carried
out to develop a s.w product and the sequencing of these activities.
Issues:
Product conception
3usiness process
'anufacturing process
!.w process
Product conception:
+very s.w product starts with a request for the product by the customer.
3usiness process:
+very so business organi%ation carries out its business through some
sequence of well de)ned steps.
'anufacturing process:
'anufacturing industries carries out its manufacture through some sequence
of stQeps.
!.w process:
The s.w life cycle can be considered as the business process for s.w
development# so s.w life cycle is also "now as a s.w process.
Stages of +ife c)c+e 'ode+:
5equirement analysis P speci)cation
Design
&oding
Testing
'aintenance
Diference b.w process and methodology:
Process:
* process covers all the activities starting from product inception through and
retirement.
'ethodology:
It covers only a single or a t best a few individual activities involved in the
development.
+x# testing and design
&omputer system engineering:
The s.w being developed would run on some general propose h.w platform
such as des"top computer in several situation it may be necessary to develop
special h.w on which the s.w run.
+x# robot# factory automation system# &ell phone

0easibility
study
5equireme
nt analysis
P
speci)cati
on
0ig. &omputer system engineering
!ystem engineering is the stage in which decision is made regarding the arts
of the problems that are to be implemented in h.w and the ones that would
be implemented in s.w.
Portioning the functions between h.s and s.w several trade of such as#
1 0lexibility
1 &ost
1 !peed
!ystem engineering testing the s.w during development becomes di4cult the
h.w on which the s.w would run and tested would still be under development.
=.w and s.w development are completer these are integrated and tested.
"$ASSI"A$ WATERFA$$S %O!E$:
Theoretical way of developing the s.w
0easibility study
5equirements analysis
*nd speci)cation
Designing
&oding and
(nit testing
Integration and
!ystem testing
'aintenance
0ig. efort distribution among diferent phases
Feasi/i+it) stud):
=./ M !./
partitioning
=./
developmen
t
!./
developmen
t
Integration
P Testing 'aintenan
ce
To determine# whether it would be )nancially and technically feasibility to
develop the product. 0easibility study activity involves analysiOs the problem
collection of all relevant information relating to the product such as#
Diferent data item which would be i.p to the system
Processing required to be carried out on these data
,.p data required to be produced by the system
&onstraints:
9. *n abstract problem de)nition:1
,nly implement requirements of the customer are captured and the details of
the requirements are ignored.
:. 0ormulation of the diferent strategies for solving the problem:1
*ll the diferent ways in which the problem can be solved are identi)ed.
H. +valuation of the diferent solution strategies:
The diferent solution strategies are analy%ed the analysis requires ma"ing
approximate estimates of the resources required# cost of development#
development time required of each of the alternate solution.
Re3uire'ent ana+)sis and s(eci4cations:
*im:
To understand the exact requirements of the customer and to document them
properly
*ctivities:
9. 5equirement gathering and analysis
:. 5equirement speci)cation
9. 5equirement gathering and analysis:
5equirement gathering:
To collect all the relevant information# gathering the product to be
development from the customer with a view to clearly understand the customer
requirements.
5equirement analysis:
To weed out the completeness and inconsistencies from these requirements
:. 5equirement speci)cation:
5equirement gathering and analysis activity are organi%ed into a s.w
requirement speci)cation document ;!5!<.
"ontent of SRS docu'ent:
9. 0unctional requirements:
It describes functions to be supported system each function can be
characteri%ed by i.p data# processing required on i.p data# and the o.p.
:. @on functional requirements:
To identi)es the performance requirements !5! document written by end
user terminology. !5! document serves as a contract b.w the development team P
customer.
!esign:
To transform the requirements speci)ed in the !5! document into a structure
that is suitable for implementation in program language.
9. Traditional
:. ,b-ect oriented
9. Traditional approach:
It is based on the data $ow oriented approach.
*ctivities of design phase:
9. !tructured analysis:1 where the detailed structure of the problem is
examined
:. !tructured design:1 result of structure analysis are transformed into a s.w
design.
*ctivities of structured design:
9. *rchitectural.high level design:1 it involves decomposing the system into
modules# and representing the i.f and the innovation relationship among
the modules.
:. Detailed design.low level design:1 internals of the individuals modules are
designed in greater detail. +xample Data structure and *lgorithm.
:. ,b-ect oriented approach:
7arious ob-ect that occur in the problem domain and the solution domain are
)rst identi)ed and the diferent relationship that exist among these ob-ects are
identi)ed.
3ene)ts of ,,D#
1 6ower development time Pefort
1 3etter maintainability of the product
"oding 5 Unit testing:
&oding.implementation:
+ach component of the design is implemented as a program module. The end
product of theis phase is set of program modules that have been individually tested.
!tandard addresses of coding#
1 6aying out the program code
1 Template for laying out the function and modules header
1 &ommenting guidelines
1 7ariable and function naming conventions
1 'aximum no of source lines permitted each module
(nit testing:
To Test each module in isolation from other modules then debugging and
documenting. (nit test need to i.f may not be ready.
Integration 5 s)ste' testing:
The diferent modules are integrated in a planned manner. *fter all the
modules have been successfully integrated and tested system testing is carried out.
!ystem testing:
To ensure that the developed system conforms to its requirements laid out
iJn the !5! document.
Types of system testing activities#
9.R testing:1 it performed by the development team
:. S testing:1 performed by a friendly set of customers
H. *cceptance testing:1 performed by customer himself after the
produce delivery to determine whether to accept the delivered product or to
re-ect.
!ystem test plan:1 identi)es all testing related activities that must be
performed and speci)es the scheduler of testing and allocates resources.
Test report:1 summari%e the outcome of all the testing that were carried out.
%aintenance:
9. &orrective maintenance:
&orrect the errors that were not discovered during the product development
phase.
:. Perfective maintenance:
Improving the implementation of the system and enhancing the functionality
of the system according to the customer requirements.
H. *daptive maintenance:
5equired for porting the s.w to wor" on new computer platform or with a new
,!
ITERATIVE WATERFA$$ %O!E$
0easibility study
5equirements analysis
*nd speci)cation
Designing
&oding and
(nit testing
Integration and
!ystem testing
'aintenance
0ig. Iterative waterfalls model
The feedbac" path allow for correction of the errors committed during a
phase as and when these are detected.
+x# testing a design error is identi)ed then the feedbac" path allows the
design to be rewor"ed and the changes to be re$ected in the design document.
@o feedbac" path to the feasibility stage. 0easibility study error cannot be
corrected.
Phase containment of errors:
To detecting errors are close to their points of introduction as possible.
!hortcoming of the iterative waterfall model:
9. The waterfall model cannot satisfactory handle the diferent types of ris"s
that a real life s.w pro-ect may sufer from
:. To achieve better e4ciency and higher productivity most real life pro-ects )nd
it di4cult to follow the rigid phase sequence prescribed by the waterfall
model.
5igid phase sequence:
* phase start only after the previous phase is complete in all respects.
3loc"ing states:
,nce the developer completes his wor"# he idle waiting for the phase to get
over.

,verlapping phase:
*n engineer wor"s fast and completes the design of the parts assigned to him
early he should not idle# waiting for the others to complete their designs. Instead#
he should proceed to start the activities for the next phase.
,verlap a diferent phases can also due to correction of errors# when
bac"trac"ing to a previous phase may be necessary.
#ROTOT&#ING %O!E$:
The prototyping model requires that before carrying out the development of
the actual s.w a wor"ing prototype of the system should be built.
* prototype can be to illustrate the i.p data formats messages# reports and
the interactive dialogues to the customer this is better understanding of the
customer needs.
The prototype model is useful in developing the 2raphical (ser Interface
;2(I< part of a system.
The prototyping model can be useful where the exact technical solutions to
be adopted are unclear to the development team.
Prototype
development
Iterative
development
Prototyping starts with an initial requirements gathering phase.
5equiremen
t gathering
uic"
design
3uild prototype
5e)ne reqs.
Incorporating
customer
suggestions
&ustomer
evaluation of
prototype
Implement
s
Text
'aintai
n
Design



3

&


* quic" design is carried out and a prototype is built.
The development prototype is submitted to the customer for his evaluation.
3ased on the customer continues till the customer approve the prototype.
,nce the customer approves the prototype# the actual system is developed
using the iterative waterfall approach.
* wor"ing prototype the !5! document is required to develop for carrying out
traceability analysis# veri)cation# and test case design.
EVO$UTIONAR& %O!E$:
The evolutionary model is a very natural model to use in ob-ect oriented s.w
development pro-ects.
+volutionary process model sometimes referred to as design a little# build a
little# test a little deploy a little mode.
,nce the requirements have been speci)ed# the design# build# test# and
deployment activities are interleaved.
6ife cycle activities:
The evolutionary lie cycle model# the s.w requirement is )rst bro"en down
into several modules that can be incrementally constructed and delivered.
0ig. +volutionary model for s.w development
* *

3

*
5ough requirements P
!peci)cation
'aintenance
Identify the core and
other parts to be
developed incrementally
Develop the core part
using an iterative
waterfall model
&ollect customer
feedbac" and modify
requirements
Develop the next
identi)ed features using
an iterative waterfall
model
The development team )rst develops the core modules of the system. The
core modules are those that do not need services form the other modules.
@on1core modules need services form the core modules.
*dvantages:
The user gets a chance to experiment with a partially developed s.w much
before the complete version of the system is released.
+volutionary model helps to accurately elicit user requirement during the
delivery of diferent versions of the s.w.
The core modules get tested thoroughly# thereby reducing chances of errors
in the core modules of the )nal products.
Disadvantages:
It is di4cult to divide the problem into several versions that would be
acceptable t the customer and which can be incrementally implemented and
delivered.
,b-ect oriented development pro-ect:
The system can easily be partitioned into stand alone units in terms of the
ob-ects. ,b-ects are self contained units that can be developed independently.
S#IRA$ %O!E$:
This model appears li"e a spiral with many loops. The exact no of loops of
the spiral is not )xed and can vary from pro-ect to pro-ect. +ach loop of the spiral is
called a phase of the s.w process.
5is" handling in spiral model:
The ris" involved in accessing data from a remote D3 can be that the data
access rate might be too slow. The ris" can be resolved by building a prototype of
the data access subsystem and experimenting with exact access rate.
The spiral model provides direct support for coping up with ris"s by providing
the scope to build a prototype at every phase of s.w developments.
#-ases of t-e s(ira+ 'ode+
9. Determine ob-ectives Pidentify alt solution
:. Identify P resolve ris"s
H. Develop next level of the product
N. 5eviewing the results
9. Determine ob-ectives P identify solution:
The products are identi)ed based on the severity of the ris" and identi)ed
features form the ob-ective of the phase.
The ob-ectives are investigated# elaborated# and analy%ed. *lternate solutions
possible for the phase under considerations are proposed.
:. Identity P resolve ris":
The solutions are evaluated by developing an appropriate prototype.
H. Develop next level of the product:
It consists of develop?ing P verifying the next level of the product.
N. 5eviewing the results:
5eviewing the results of the stages traversed with the customer and planning
the next iteration around the spiral.
#ros and "ons of t-e s(ira+ 'ode+:
Disadvantages:
The spiral model that restrict its use to certain pro-ects only.
It is a ris" driven P in more complicated them other models
It is not suitable for outsourced pro-ect.
*dvantages:
Ti is much more powerful than the prototyping model.
The ris"s in the pro-ects should be "nown as the start of the pro-ect and all.
*ll ris"s are resolved before the product development starts.
!piral model as a 'eta model:
!piral model uses a waterfall model# iteration waterfall model prototyping
model and evolutionary model so it is called 'eta model.
"O%#ARISON OF !IFFERENT "&"$E %O!E$:
&lassical life cycle model:
It cannot be used in practical development pro-ects therefore this model
supports no mechanism to correct the errors that are committed during any of the
phase.
Iterative waterfall model:
It is only suitable only for well understand problem and is not suitable for very
large pro-ects and for pro-ects that sufer from many types of ris"s.
Prototyping model:
It is suitable for pro-ects for which either the user requirement or the
underlying technical aspects are not well understood.
+volutionary model:
It is suitable for large problems which can be decomposed into a set of
modules for incrementally development P delivery. It is used for ,,D pro-ects.
!piral model:
It includes all types life cycle model.
!electing an appropriate life cycle model for a pro-ectE
9. &haracteristics of the s.w to be developed
:. &haracteristics of the s.w development team
H. &haracteristics of the customer.
SOFTWARE #RO6E"T %ANAGE%ENT:
!.w pro-ect management is to enable a group of s.w developers to wor"
e4ciently towards successful completion of the pro-ects.
Res(onsi/i+ities of a sw (ro,ect 'anager:
9. Iob responsibilities of a s.w pro-ect manager
:. !"ills necessary for s.w pro-ect management
9. Iob responsibilities of a s.w pro-ect manager:
!.w pro-ect managers ta"e the overall responsibilities of steering a pro-ect to
success. The -ob responsibility of a pro-ect manager ranges from invisible activities
li"e building up team morale to highly invisible customer presentation.
5esponsibilities of manager#
Proposal writing
&ost estimation
!cheduling sta4ng
!.w process tailoring
Pro-ect monitoring and control
!.w con)guration management
5is" management
Interfacing with clients
'anagerial pro-ect writing
Presentations
*ctivities of pro-ect manager:
9. Pro-ect planning
:. Pro-ect monitoring and control activities
:. !"ills necessary for s.w pro-ect manager:
Theoretical "nowledge
uality -udgment P decision ma"ing
&ost estimation
5is" management
&on)guration management
Trac"ing P controlling the progress
&ustomer interaction
'anagerial presentations
Team building
#RO6E"T #$ANNING:
Pro-ect planning is underta"en and completed even before any development
activity starts.
*ctivities:
9. +stimation:
&ost:1 how much is it going to cost to develop the s.wT
Duration:1 how long is it going to ta"e to develop the productT
+fort:1 how much efort would be required to develop the productT
:. !cheduling:
*fter the estimations are made the schedules for manpower and other
resources have be developed.
H. !ta4ng:
!taf organi%ation and sta4ng plan P have to be made.
N. 5is" management:
5is" identi)cation analysis and abatement planning have to be done.
L. 'iscellaneous plans:
uality assurance plan# con)guration management plan.
6arge pro-ects# it8s di4cult to ma"e accurate plans due to scope of the
pro-ect# pro-ect staf may change during the span of the pro-ect is overcome the
sliding window planning.
+fort
estimation
&ost
estimation
!i%e
estimation
Duration
estimation
Pro-ect
sta4ng
!chedulin
g
S+iding window (+anning:
Planning a pro-ect over a no of stages protects manager8s form ma"ing big
commitments too early. This techniques staggered planning is "nown as sliding
window planning.
It starting with an initial plan# the pro-ect is planned more accurately in
successive development stages. *t start of a pro-ect# pro-ect manager has
incomplete "nowledge about the details of the pro-ect.
The information base gradually improves as the pro-ect progress through
diferent phase. *fter the completion of every phase# the pro-ect manager can plan
each subsequent phase more accurately and with increasing levels of con)dence.
S#%# docu'ent:
,nce the pro-ect planning is complete# pro-ect manager8s document their
plan is a !.w Pro-ect 'anagement Plan ;!P'P<.
9. Introduction:
,b-ectives
'a-or functions
Performance issues
'anagement P technical constrains
:. Pro-ect estimates:
=istorical data used
+stimation techniques used
+fort# resource# cost P pro-ect duration estimates
H. !chedule:
/or" brea"down structure
Tas" n.w representation
2antt chart representation
P+5T chart representation
N. Pro-ect resources:
People
=.w and s.w
!pecial resources
L. !taf organi%ation:
Team structure
'anagement reporting
>. 5is" management plan:
5is" analysis
5is" identi)cation
5is" estimation
5is" abatement procedures
K. Pro-ect trac"ing and control plan
O. 'iscellaneous plans:
Process tailoring
uality assurance plan
&on)guration management plan
7alidation P veri)cation
!ystem testing plan
Delivery installation and maintenance plan
%ETRI"S FOR #RO6E"T SI7E ESTI%ATION:
The pro-ect si%e is a measure of the problem complexity in terms of the efort
and time required to develop the product.
'etrics#
9. 6ine ,f &ode ;6,&<
:. 0unction Point ;0P<
$ine Of "ode:
6ibrary
automation s.w
6,& measures the si%e of a pro-ect by counting the no of source instructions
in the developed program. &ounting the no of source instructions lines used for
commenting the code and the header lines are ignored.
The 6,& counts at the end of the pro-ect in simple. The 6,& count at the
beginning of the pro-ect is very di4cult.
'easures of problem si%e have several shortcomings:
9. 6,& gives numerical values of problem si%e that can vary with individual
coding style.
:. 6,& is measure of the coding activity alone total efort needed to specify#
design# code# test etc and not coding efort.
H. &orrelates poorly with the quality and e4ciency of the code larger code si%e
does not necessarily better quality or e4ciency.
N. The team managers use 6,& count developers# they would be discouraging
code reuse by developers.
L. 6,& metric measures the lexical complexity of a program and does not
address the more implement but subtle issues of logical or structural
complexities.
>. It di4cult to accurately estimate 6,& in the )nal product from the problem
speci)cations.
Functions #oint %etric:
The function point metric is that it can be used to easily estimate the si%e of a
s.w product directly from the problem speci)cation.
The si%e of a s.w product is directly dependent on the no of diferent functions
it supports.
+ach function when invo"ed reads some i.p data and transforms it to the
corresponding o.p data.
Input data output data

Interface:1 interface refers to the diferent
mechanisms that need to be supported for data transfer
with other external systems.
!teps:
0P is completed in three steps.
9. To compute the (nad-usted 0unction Point ;(0P<
:. The (0P is re)ned to re$ect the diferences in the complexities of the
diference parameters of the expression for (0P computations.
H. 0P is computed by further re)ning (0P to account for the speci)c
characteristics of the pro-ect that can in$uence the development efort.
(0PG ;@o of i.p< U N V ;no of o.p< U L V ;no of inquiries< U N V ;no of )les< U
9? V ;no of i.f< U 9?
#RO6E"T ESTI%ATION TE"HNI8UES:
Pro-ect estimation is a basic planning activity. Pro-ect parameter that are
included.
1 Pro-ect si%e
1 +fort required to develop the s.w
1 Pro-ect duration P cost
uery
boo"
Issue
boo"
5eturn
boo"
T)(es of esti'ation tec-ni3ues:
+stimation techniques do have certain scienti)c basis.
9. +mpirical estimation techniques
:. =euristic techniques
H. *nalytical estimation techniques
9. +mpirical estimation techniques:
It based on ma"ing an educated guess of the pro-ect parameters the prior
experience with development of similar product is helpful. It is based on common
sense over the yearsE diferent activities involved in estimation have been
formali%ed to certain extent.
:. =euristic techniques:
It assumes that the relationship among the diferent pro-ect parameters can
be modeled using suitable mathematical expressions.
&lasses#
!ingle variable model
'ulti variable model
!ingle variable model:
To provide a means to estimate the desired characteristics of a plan# using
some previously estimated basic characteristic of the s.w product i.e. si%e.
'ulti variable model:
'ulti variable model models are expected to give more accurate estimates
compared to the single variable models.
H. *nalytical estimation techniques:
It derives the required results starting with certain basic assumption
regarding the pro-ect.
E%#IRI"A$ ESTI%ATION TE"HNI8UES:
9. +xport -udgment technique
:. Delphi estimation technique
+xport -udgment technique:
*n export ma"es an educated guest of the problem si%e after analy%ing the
problem thoroughly.
The export estimations the cost of the diferent components that would ma"e
up the system and then combines the estimation for the individual modules to
arrive at the overall estimate.
+xpert -udgment is the estimation made by a group of experts.
+stimation by a group of experts minimi%es factors such as individual over
right# lac" of familiarity with a particular aspect of pro-ect# personal bias and the
desire to win contract through overly optimistic estimates.
Delphi cost estimation:
It is carried out by a team comparison of a group of experts and coordinates.
The coordinator provides each estimator with a copy of the !5! document
and a form for recording his cost estimate.
The coordinator prepares the summary of the response of all the estimators#
and also includes any unusual rationale noted by any of the estimator.
The prepared summary information is distributed to the estimators based on
this summary the estimators re estimate. *fter the completion of several iterations
of estimation# the coordinator ta"es the responsibility of compiling the result and
preparing the )nal estimate.
"O"O%O A -euristic esti'ation tec-ni3ues:
+stimated parameter G
&9 U e
d9
&,&,', stands &onstructive &ost +stimation 'odel. It was proposed by
3oehm 9JO9.
9. ,rganic
:. !emidetached
H. +mbedded
9. ,rganic:
The pro-ect dents with developing a well understood application program the
si%e of the development team is reasonably small# and the team members are
experience in developing similar byte of pro-ect.
:. !emidetached:
The development pro-ect can be transferred to be semidetached type. The
development team consists of a mixture of experienced and inexperienced staf.
H. +mbedded:
Development pro-ect in considered to be of embedded type. If the s.w being
developed in strongly completed to complex n.w.
9asic "O"O%O 'ode+:
It gives an approximate estimate of the pro-ect parameters.
+stimation of#
+fort G a9 U ;W6,&<
a:

P'
T dev G b9 U ;+fort<
b:

'onths
+fort development:
+stimation of development time:
,rganic GC +fortG
:.N;W6,&<
9.?L
P'
!emidetached GC +fort G
H.?;W6,&<
9.9:
P'
+mbedded GC +fort G
H.>;W6,&<
9.:?
P'
,rganic GC Tdev G
:.L;+fort<
.HO
'onths
!emidetached GC Tdev G :.L;+fort<
.HL
'onths
+mbedded GC Tdev G
:.L;+fort<
.H:
'onths
Inter'ediate "O"O%O:
The intermediate &,&,', model recogni%e fact and re)nes the initial
estimate obtained using the basic &,&,', expressions by using a set of 9L cost
drivers based on various attributes of s.w developments.
*ttributes of cost drivers:
9. Product
:. &omputer
H. Personnel
N. Development environment
9. Product:
The inherent complexity of the product# reliability requirement of the product
:. &omputer:
+xecution speed required# storage space required.
H. Personnel:
+xperience level of personnel8s# programming capabilities# and analysis
capabilities
N. Development environment:
It captures the development facilities available to the developers.
"o'(+ete "O"O%O:
It considers the diferences in characteristics of the subsystems and
estimates the efort and development time as the sum of the estimates for the
individual subsystem. It reduces the margin of errors in the )nd estimates sub
components of D'I! ;Distributed 'anagement Information !ystem<.
D3 part M semidetached
2(I part M organic s.w
&ommunication part
"O"O%O::
It provides three increasingly detailed cost estimation models. These can be
used to estimate pro-ect cost of diferent phases of the s.w.
!tages#
*PP composition M to estimate cost for prototype
+arly design M to estimate cost at the each design
Post architecture stage M detail design P coding stage
9. *pplication composition model:
It is based on counting the no of screens reports and H26 modules. +ach
considered as a ob-ects.
!tep:
9. +stimate the o. of screens reports and H26 components from an analysis
of the !5! document.
:. Determine complexity of each screen and report and rate these as simple#
medium# or di4cult ;therefore due to table P views conditions<.
H. (se the weight values.
@o of views Tables X N Tables X O Tables CG O
X H !imple !imple 'edium
H to K !imple 'edium Di4cult
C O 'edium Di4cult Di4cult
N. Determine the no of ob-ect points.
L. +stimate percentage of reuse expected in the system then evaluates @ew
,b-ect Point count ;@,P<.
>. Determine productivity rate P5,D G @,P.person1month. It depends on the
experience of the developers as well as the maturity of the &*!+ envy
used.
K. Person month is computed as + G @,P.P5,D.
:. +arly design model:
The unad-usted function points are counted and converted to some 6ine ,f
&ode. (0P corresponds#
1 9:O lines of &
1 :J lines of &VV
1 H:? lines of assembly code

It difers from the original &,&,', model in the choice of the set of cost
drivers and the range of values of the exponents. &ost driver include product
reliability and complexity# the extent of reuse# platform di4culty# personnel
experience# &*!+ support# and schedule.
+fort G aU W6,&
b
U II
:
cost
driver
:
ANA$&TI"A$ TE"HNI8UES Ha+stead;s sw science:
To measure si%e# development efort# and development cost of s.w products.
=alstead used a few primitive program parameters to develop the
expressions for overall program length# potential minimum volume# actual volume#
language level# and efort and development time.
O(erators and o(erands:
,perators:
,perator is a symbol that instructions to computer to perform certain
operations.
; Y . # 1C U V 1 Z [ VV 11 . \ PG XG CG ]GE T D F E &*!+# D+0*(6T# I0#
+6!+# !/IT&=. /=I6+# D,# 0,5# 2,T,# &,@TI@(+# 35+*W# 5+T(5@# function call.
,perands:
,perands are those variables and constants which are being used with
operators in expressions.
6ength and vocabulary:
The length of the program as de)ned a quality total usage of all operators
and operands in the program.
Program vocabulary:
The no of unique operators and operands are used in the program.
1 n9 G no of unique operators
1 n: G total no of operands
Potential minimum volume:
Potential minimum volume 7U is de)ned as the volume of the most succinct
program which a problem can be coded. The mini volume is obtained when the
program can be expressed using a single some code instatement i.e. function call
fun ;<E
*lgorithm operates i.p and o.p data.
+fort G W!6,& UII
:
costdriver
:
n G n9 V
n:
0 ;d9# d:#^ dn<E n9G:En:Gn
7 U G ;:Vn:< log
:
;:Vn:<
E<ort and Ti'e:
The efort 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.
+1 no of mental discriminations required to implement#

/ell correlated to the efort needed for maintenance of an existing program

! M !peed of mental discriminations# empirically developed from
psychological reasoning and its recommended value for programming.
$engt- esti'ating:
* program can be found by calculating the total no of operators and operands
in a program before the start.
Program parameters length# volume# cost# efort and etc.#
@.n XG n
n
@ XG n
nV9
:
@
G nn9
n9
n:
n:
Ta"e log on both sides#
@ G log
:
n V log
:
;n9
n9
n:
n:
<
/e get#
@ G log
:
;n9
n9
n:
n:
<
@ G log
:
n9
n9
V log
:
n:
n:
G n9 log
:
n9 V n: log
:
n:
+xample#
@9 G 9:# n: G 99
+stimate length G ;9: U log9: V 99 U log99<
G ;9: U H.LO V 99 U H.NL<
G ;NH V HO<
G O9
7olume G length U log ;:H<
G O9 U N.L:
G H>>
Sta=ng +e*e+ esti'ation:
,nce the efort required to develop a s.w has been determined# it is
necessary to determine the sta4ng requirement for the pro-ect.
9. Putnam8s wor" M the )rst to study the problem of what should be a proper
sta4ng pattern for s.w pro-ects
:. @order8s wor" M who had early investigated the sta4ng pattern of general
research and development type of pro-ects.
@orden8s wor":
@orden8s found that the sta4ng pattern can be approximated by the 5ayleigh
distribution curve.
+ G W . td
:
U t U 1t
:
.
+fort + G
7.6
Programming +fort + G
7
:
. 7
N
Programmer Time T G
+. !
e
:t
d
:
tG the efort required at time
+ G no of developers
W G area under the curve
t
d
G the time which the curve attains its maximum value
+fort
Per unit
Time
td
Time
Putnam8s wor":
The problem of sta4ng of s.w pro-ect and found that w.w development has
characteristics very similar to any other 5 P D pro-ects studies by @ordan and that
the#
6 G
&
W
W
9.H
t
d
N.H
W G total efort expended in the product development
6 G is the product si%e in W6,&
td G time required to develop the s.w
&W G constant
+fect of schedule change on cost:
The same product si%e# & G 6
H
. &W
H
is a constant
Iensen8s model:
Iensen8s model is similar to Putnam model. It attempts to soften the efect of
schedule compression on efort to ma"e it applicable to smaller and medium si%ed
pro-ects.
&
te
G constant
t
d
G is the time to develop the s.w
W G efort needed to develop the s.w
/hen the pro-ect duration is compressed# Iensen models the increase
in efort requirement to be proportional to the square of the degree of
compression.
S"HE!U$ING:
It decide which tas"s would be ta"en up when#
!teps to follow the scheduling activity:
6 G &
tetd
W
9.:
or W9 . W: G t
d:
:
. t
d9
:

W G 6
H
. ;&
W
H
t
d
N
< or W
G & . t
d
N
W9 . W: G t
d:
N
. t
d9
N
9. Identify all the tas"
:. 3rea"down large tas" into small activities
H. Determine the dependency among diferent activity
N. +stablish the time duration
L. *llocate resources
>. Plan starting and ending dates
K. Determine the critical path
9. Identify all tas":
The manager to efectively identify the implement# tas"s of the pro-ect.
:. /or" M brea" down structure:
The large tas"s are bro"en down into a logical set.
*ctivity n.w and critical path method:
/!3 representation of a pro-ect in transformed into an activity n.w by
representing activities identi)ed in /!3 along with their inter dependencies.
'anager can estimate the time durations for the diferent tas"s in several ways.
+ach engineer himself estimate the time for an activity he can be assigned to
this approach can help to accurately estimate the tas" durations without creating
undue schedule pressures.
&ritical Path 'ethod ;&P'<:
The 'ini Time ;'T< to complete the pro-ect is the max of all paths from start
to )nish.
The +arliest Time of a tas" is the max for all paths from the start.
The latest start time is the diference b.w 'T and the max of all paths to
)nish.
!lac" Time ;!T<:
!T is the total time that a tas" may be delayed before it will afect the end of
the time of pro-ect !T indicates the $exibility in starting and completion of tas".
&ritical Path:
* path from the start node to the )nish node containing only critical tas" is
called a critical paths. *ny path whose duration equals 'T is a critical path.
2antt chart:
It is developed by =enry 2entt. To allocates resource activities. It includes
staf h.w and s.w.
It is a special type of bar chart where each bar represents an activity.
+arliest 0inish Time ;+0< G +! V duration of tas"
6atest 0inish Time ;60< G 'ax of all paths M Tas"
to )nish 'T
'T! application
5equirement
speci)cation
Test Desig
n
&ode Document
D3
part
2(I
part
D3 part
2(I
part
The shaded part of the bar shows the length of time each tas" is estimated to
ta"e. The white bar shows the slac" time.
#ERT c-art 1#ro,ect E*a+uation and Re*iew Tec-ni3ues2:
It represents statistical variation in the pro-ect estimates assuming a normal
distribution. It consists of n.w of boxes and arrows. The boxes represent activities
and the arrow represent tas" dependencies thic"er arrow represents the critical
path.
Pro-ect 'onitoring and &ontrol:
The pro-ect manager has to monitor the pro-ect continuously to ensure that it
s processing s per the plan. The pro-ect manager designates certain "ey events
such as completion of some implementing activity as milestone.
,nce milestone is reached# the pro-ect manager can assume that some
measurable progress has been made. If any delay in reaching a milestone is
predicted# then corrective actions might have to be ta"en. 'ilestone can be the
completion P review of the !5! document# completion of coding unit testing# etc.#
,rgani%ation and team structures:
+very development organi%ation handles several pro-ects at any time s.w
organi%ations assigns diferent team of developers to handle diferent s.w pro-ects.
,rgani%ation structure:
9. 0unctional format
:. Pro-ect format
9. Pro-ect organi%ation:
The * set of developers are assigned to the pro-ect at the start of the pro-ect
and they remain with the pro-ect till the completion f the pro-ect.
:. 0unctional organi%ation:
!peci)cati
on
/rite user
manual
Design
2(I part
&ode 2(I
part
Integrate
P test
&ode D3
part
Design D3
part
0inish
Diferent team of programmer can perform diferent phases of a pro-ect. +x#
one team might do the requirement speci)cation another do design etc.#
0unction format requires considerable communication among the diferent
teams. &ommunication among the team members may appear as an avoidable
overhead.
*dvantage:
1 +asy of sta4ng
1 Production of good quality document
1 Iob speciali%ations
1 +4cient handling of the problems
Disadvantage:
The manager can ta"e the almost constant no of developers for the entire
duration of his pro-ect.
Tea' structure:
9. &hief programmer
:. Democratic team
H. 'ixed team organi%ations
9. &hief programmer:
* senior engineer provides the technical leadership and is designated as a
chief programmer.
&hief programmer partitions the tas" into small activities and assigns them to
the team members. The team members wor" under the constant supervision of the
chief programmer.
Pro-ect manager
5eporting
!.w engineers
:. Democratic teamE
It leads to high morale and -ob satisfaction. It suitable for pro-ects requiring
less than )ve or six developers and for research oriented pro-ects. Democratic team
organi%ation encourages egoless programming as programmer can share and
review one another8s wor".
Disadvantage:
Team member may waste a lot time arguing about trivial points due to the
lac" of authority in the team to resolve the debates.
%i>ed contro+ tea' organi?ation:
It includes both the democratic organi%ation and the chief programmer
organi%ation# to handle large and complex programs.
Pro-ect manager
5eporting
!eminar engineers
!.w
engineer
Sta=ng:
!.w pro-ect manager usually ta"e the responsibility of choosing their team.
They need to identify good s.w developers for the success of the pro-ect.
/ho is a good s.w engineerT
*ttributes:
9. +xposure to systematic techniques.
:. 2ood technical "nowledge of the pro-ect areas ;domain "nowledge<.
H. 2ood programming abilities.
N. 2ood communication s"ill.
1 ,ral
1 /ritten
1 Inter personal
L. =igh motivation.
>. !ound "nowledge of fundamentals of computer science.
K. Intelligence.
O. *bility to wor" in a team.
RIS@ %ANAGE%ENT:
It is any anticipated unfavorable event or circumstance can occur whole
pro-ect.
5is" identi)cation
5is" assessment
5is" containment
RisA identi4cation:
Pro-ect can be afected by a large variety of ris"s. !ystematically identify the
implement ris"s which might afect a pro-ect.
&ategories of ris"#
1 Pro-ect ris"s
1 Technical ris"s
1 3usiness ris"s
Pro-ect ris":
3udgetary# schedule# personnel# resource P customer related problems
Pro-ect ris" is schedule slippage. That is s.w is intangible it is di4cult to
monitor and control a s.w pro-ect.
Technical ris"s:
It concern potential design# implementation# interfacing# testing and
maintenance problems.
Technical ris"s includes#
1 *mbiguous speci)cation
1 Incomplete speci)cation
1 &hanging speci)cation
1 Technical uncertainly
1 Technical obsolescence
3usiness ris"s:
It includes ris"s of building an excellent product that no one wants# losing
budgetary or personnel commitments.
RisA assess'ent:
To ran"ing the ris"s in terms of their damage causing potential
5is" should be rated in two ways:
9. The li"elihood of a ris" coming true _.
:. The consequence of the problems associated with that ris" ;s<.
Priority ris" p G r U
s
p G Priority with which ris" must be handled
r G Probability of the ris"
s G !everity of damage
RisA contain'ent:
!trategies:
*void the ris"
Transfer the ris"
5is" reduction
*void the ris":
Discussing with the customer to change the requirements to reduce the
scope of the wor"
2iving incentives to the developers to avoid the ris" of manpower turnover
Transfer the ris":
To getting the ris"y component developed by a third party# buying insurance
cover.
5is" reduction:
The pro-ect manager must consider the cost of handling the ris" and the
corresponding reduction of ris".
Sw
con4guration 'anage'ent:
!.w con)guration management deals with efectively trac"ing and controlling
the con)guration of an s.w product during its life cycle.
Necessit) of sw con4guration 'anage'ent:
i. Inconsistency problem when the ob-ects are replicated
ii. Problems associated with concurrent access
iii. Providing a stable development environment
iv. !ystem accessing and maintaining status information
v. =andling variants
&on)guration management activities:
9. &on)guration identi)cation
:. &on)guration control
9.&on)guration identi)cation:
&ontrolled M those which are already put under con)guration control
Pre controlled M ob-ects are not yet under con)guration control but eventually
be under con)guration control
(ncontrolled M ob-ects will not sub-ect to con)guration control
&ontrolled ob-ects include:

5equest speci)cation document
Design documents
Tools used to build the system
!ource code for each module
Test case
Problem reports
5is" leverage G 5is" exposure before reduction M 5is" exposure
after reduction
&ost of reduction
:. &on)guration control:
It allows only authori%ed changes to the controlled ob-ects to occur and
prevents unauthori%ed changes.
@eed for changes:
i. &hange in well motivated
ii. Developer has considered and documented the efects of the change
iii. &hange interact well with the changes made by other developers
iv. &hange control board ;&&3< have validated the change
!ource &ode &ontrol !ystem ;!&&!< and 5&!:
!&!! and 5&! both are available on most (@I` systems. It can be used to for
controlling and managing diferent versions of text )les.
!&&! and 5&! do not handle binary )le
It minimi%e the amount of occupied dis" space
Deltas:
The changes needed to transform each base lined )le to the next version are
stored and are as called deltas.

!&&! and 5&! include:
The ability to incorporate restrictions on the set of individuals who can create
new versions
&hec"ing components in and out.
0000000000 B 0000000000