D.SAMEERA,Asst.

Prof 2010
UNIT - 1
Conventional Software Management
1. The best thing about software is its flexibility:
- It can be programmed to do almost anything.
2. The worst thing about software is its flexibility:
- The almost anything characteristic has made it difficult to plan monitor and control software
de!elopment.
". In the mid-1##$s three important analyses were performed on the software engineering industry.
All three analyses given the same general conclusion:-
The success rate for software pro%ects is !ery low.
They &ummari'ed as follows:
1. &oftware de!elopment is still highly unpredictable. (nly 1$) of software pro%ects are deli!ered successfully
within initial budget and scheduled time.
2. *anagement discipline is more differentiator in success or failure than are technology ad!ances.
". The le!el of software scrap and rewor+ is indicati!e of an immature process.
Software management process framework:
WATERFALLL MODEL
1. It is the baseline process for most con!entional software pro%ects ha!e used.
2. ,e can examine this model in two ways:
i. I- T./(01
ii. I- 2034TI4/
IN TEOR!"-
In 1#5$ ,inston 0oyce presented a paper called *anaging the 6e!elopment of 7arge &cale
&oftware &ystems at I/// ,/&4(-.
,here he made three primary points:
1.There are two essential steps common to the de!elopment of computer programs:
- analysis
- coding
2. In order to mange and control all of the intellectual freedom associated with software development one should follow
the following steps:
- S#$tem re%&irement$ 'efinition
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
- Software re%&irement$ 'efinition
- (rogram 'e$ign an' te$ting
T)e$e $te*$ a''ition to t)e anal#$i$ an' +o'ing $te*$
". &ince the testing phase is at the end of the de!elopment cycle in the waterfall model it may be ris+y and in!ites
failure.
&o we need to do either the re8uirements must be modified or a substantial design changes is warranted by
brea+ing the software in to different pieces.
-T)ere are five im*rovement$ to t)e ,a$i+ waterfall mo'el t)at wo&l' eliminate mo$t of t)e 'evelo*ment
ri$-$ are a$ follow$"
a) Complete program design before analysis and coding begin (program design comes first):-
- 9y this techni8ue the program designer gi!e surety that the software will not fail because of storage timing and
data fluctuations.
- 9egin the design process with program designer not the analyst or programmers.
- ,rite an o!er!iew document that is understandable informati!e and current so that e!ery wor+er on the pro%ect
can gain an elemental understanding of the system.
b) Maintain current and complete documentation (Document the design):-
-It is necessary to pro!ide a lot of documentation on most software programs.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
- 6ue to this helps to support later modifications by a separate test team a separate maintenance team and
operations personnel who are not software literate.
+. Do the job twice if possible (Do it twice):-
- If a computer program is de!eloped for the first time arrange matters so that the !ersion finally deli!ered
to the customer for operational deployment is actually the second !ersion insofar as critical design:operations are
concerned.
- 6o it - times approach is the principle of modern-day iterati!e de!elopment.
d) !lan control and monitor testing:-
- The biggest user of pro%ect resources is the test phase. This is the phase of greatest ris+ in terms of cost and
schedule.
- In order to carryout proper testing the following things to be done:
i; /mploy a team of test specialists who were not responsible for the original design.
ii; /mploy !isual inspections to spot the ob!ious errors li+e dropped minus signs missing factors of
two %umps to wrong addresses.
iii; Test e!ery logic phase.
i!; /mploy the final chec+out on the target computer.
e) "nvolve the customer:-
- It is important to in!ol!e the customer in a formal way so that he has committed himself at earlier points before
final deli!ery by conducting some re!iews such as,
i; 2reliminary software re!iew during preliminary program design step.
ii; 4ritical software re!iew during program design.
iii; <inal software acceptance re!iew following testing.
IN (RACTICE"-
- ,hate!er the ad!ices that are gi!en by the software de!elopers and the theory behind the waterfall model some
software pro%ects still practice the con!entional software management approach.
2ro%ects intended for trouble fre8uently exhibit the following symptoms:
i; 2rotracted =delayed; integration
- In the con!entional model the entire system was designed on paper then implemented all at once
then integrated. (nly at the end of this process was it possible to perform system testing to !erify that the
fundamental architecture was sound.
- .ere the testing acti!ities consume >$) or more life-cycle resources. 34TI?IT1
4(&T
*anagement @)
0e8uirements @)
6esign 1$)
4ode and unit testing "$)
Integration and test >$)
6eployment @)
/n!ironment @)
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
ii. Late Ri$- Re$ol&tion
- A $erio&$ i$$&e$ a$$o+iate' wit) t)e waterfall life +#+le wa$ t)e la+- of earl# ri$- re$ol&tion/ T)e ri$-
*rofile of a waterfall mo'el i$0
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
- It in+l&'e$ fo&r 'i$tin+t *erio'$ of ri$- e1*o$&re0 w)ere ri$- i$ 'efine' a$ 2t)e *ro,a,ilit# of mi$$ing a
+o$t0 $+)e'&le0 feat&re0 or %&alit# goal3/
iii. Re%&irement$-Driven F&n+tional De+om*o$ition
-Traditionally the software de!elopment process has been re8uirement-dri!en: 3n attempt is made to pro!ide a
precise re8uirements definition and then to implement exactly those re8uirements.
-This approach depends on specifying re8uirements completely and clearly before other de!elopment acti!ities
begin.
- It fran+ly treats all re8uirements as e8ually important.
- &pecification of re8uirements is a difficult and important part of the software de!elopment process.
iv. A'ver$arial Sta-e)ol'er Relation$)i*$
The following se8uence of e!ents was typical for most contractual software efforts:
- The contractor prepared a draft contact-deli!erable document that captured an intermediate artifact and deli!ered
it to the customer for appro!al.
- The customer was expected to pro!ide comments =within 1@ to "$ days;
- The contractor integrated these comments and submitted a final !ersion for appro!al =within 1@ to "$ days;
(ro4e+t Sta-e)ol'er$ "
&ta+eholders are the people in!ol!ed in or affected by pro%ect acti!ities
&ta+eholders include
the pro%ect sponsor and pro%ect team
support staff
customers
users
suppliers
opponents to the pro%ect
v. Fo+&$ on Do+&ment$ an' Review Meeting$
- The con!entional process focused on !arious documents that attempted to describe the software product.
- 4ontractors produce literally tons of paper to meet milestones and demonstrate progress to sta+eholders rather
than spend their energy on tas+s that would reduce ris+ and produce 8uality software.
- *ost design re!iews resulted in low engineering and high cost in terms of the effort and schedule in!ol!ed in
their preparation and conduct.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010

CON5ENTIONAL SOFTWARE MANA6EMENT (ERFORMANCE
9arry 9oehmAs Top 1$ Industrial &oftware *etrics:
1; <inding and fixing a software problem after deli!ery costs 1$$ times more than finding and fixing the
problem in early design phases.
2; 1ou can compress software de!elopment schedules 2@) of nominal =small; but no more.
"; <or e!ery B1 you spend on de!elopment you will spend B2 on maintenance.
>; &oftware de!elopment and maintenance costs are primarily a function of the number of source lines of
code.
@; ?ariations among people account for the biggest difference in software producti!ity.
C; The o!erall ratio of software to hardware costs is still growing. In 1#@@ it was 1@:D@E in 1#D@ D@:1@.
5; (nly about 1@) of software de!elopment effort is de!oted to programming.
D; &oftware systems and products typically cost " times as much per &7(4 as indi!idual software programs.
&oftware-system products cost # times as much.
#; ,al+throughs catch C$) of the errors.
1$; D$) of the contribution comes from 2$) of the contributors.
- D$) of the engineering is consumed by 2$) of the re8uirements.
- D$) of the software cost is consumed by 2$) of the components.
- D$) of the errors are caused by 2$) of the components.
- D$) of the software scrap and rewor+ is caused by 2$) of the errors.
- D$) of the resources are consumed by 2$) of the components.
- D$) of the engineering is accomplished by 2$) of the tools.
- D$) of the progress is made by 2$) of the people.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
(art-7
Evol&tion of Software E+onomi+$
/conomics means &ystem of interrelationship of money industry and employment.
SOFTWAR ECONOMICS"-
The cost of the software can be estimated by considering the following things as parameters to a
function.
1;&i'e: ,hich is measured in terms of the number of &ource 7ines (f 4ode or the number of
function points re8uired to de!elop the re8uired functionality.
2;2rocess: Fsed to produce the end product in particular the ability of the process is to a!oid non-
!alue-adding acti!ities =rewor+ bureaucratic delays communications o!erhead;.
";2ersonnel: The capabilities of software engineering personnel and particularly their experience
with the computer science issues and the application domain issues of the pro%ect.
>;/n!ironment: ,hich is made up of the tools and techni8ues a!ailable to support efficient
software de!elopment and to automate the process.
@;Guality: It includes its features performance reliability and flexibility.
The relationship among these parameters and estimated cost can be calculated by using
/ffort H =2ersonnel; =/n!ironment; =Guality; =&i'e
2rocess
;
- (ne important aspect of software economics is that the relationship between effort and si'e
exhibits a diseconomy of scale and is the result of the process exponent being greater than 1.$.
- 4on!erse to most manufacturing processes the more software you build the more expensi!e it is
per unit item.
- There are three generations of basic technology ad!ancement in tools components and processes
are a!ailable.
1; Conventional" 1#C$ and 1#5$ 4raftsmanship. (rgani'ations used custom tools custom
processes and !irtually all custom components built in primiti!e languages. 2ro%ect performance was highly
predictable.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
2; Tran$ition" 1#D$ and 1##$ software engineering. (rgani'ations used more-repeatable processes
and off-the-shelf tools and mostly =I5$); custom components built in higher le!el languages.
- &ome of the components =J"$); were a!ailable as commercial products li+e (& 69*&
-etwor+ing and KFI.
"; Mo'ern *ra+ti+e$" 2$$$ and later software production.
- 5$) component-based
- "$) custom
Conventional Tran$ition Mo'ern (ra+ti+e$
- 1#C$s L 1#5$s - 1#D$s L1##$s - 2$$$ and on
- ,aterfall model - 2rocess impro!ement - Iterati!e de!elopment
- <unctional design - /ncapsulation - based - 4omponent-based
- 6iseconomy of scale- 6iseconomy of scale- 0(I
E n v i r o n m e n t $ 8 t o o l $ "
4ustom (ff-the-shelf separate (ff-the-shelf Integrated
S i 9 e "
1$$) custom "$) component-based 5$) component-based
5$) custom "$) custom
( r o + e $ $ "
3d hoc 0epeatable *anaged:measured
T # * i + a l * r o 4 e + t ( e r f o r m a n + e "
3lways: Infre8uently: Fsually:
(!er budget (n budget (n budget
(!er schedule (n schedule (n schedule
W)at Doe$ #eturn $n "nvestment - #$" Mean:
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
3 performance measure used to e!aluate the efficiency of an in!estment or to compare the
efficiency of a number of different in!estments. To calculate 0(I the benefit =return; of an in!estment is
di!ided by the cost of the in!estmentE the result is expressed as a percentage or a ratio.
The return on in!estment formula:

0eturn on in!estment is a !ery popular metric because of its !ersatility and simplicity. That
is if an in!estment does not ha!e a positi!e 0(I or if there are other opportunities with a higher 0(I then
the in!estment should be not be underta+en
(ro4e+t Si9e$ "
&i'e as team strength could be :
Tri!ial =*inor; &i'e: 1 person
&mall &i'e: @ people
*oderate &i'e: 2@ people
7arge &i'e: 12@ people
.uge &i'e: C2@ people
The more the si'e the greater are the costs of management o!erhead communication synchroni'ations
among !arious pro%ects or modules etc.
Re'&+e Software Si9e"
The less software we write the better it is for pro%ect management and for product 8uality
- The cost of software is not %ust in the cost of McodingA aloneE it is also in
3nalysis of re8uirements
6esign
0e!iew of re8uirements design and code
Test 2lanning and preparation
Testing
9ug fix
0egression testing
M4odingA ta+es around 1@) of de!elopment cost
- 4learly if we reduce 1@ hrs of coding we can directly reduce 1$$ hrs of de!elopment effort and also
reduce the pro%ect team si'e appropriately N
- &i'e reduction is defined in terms of human-generated source code. *ost often this might still mean that
the computer-generated executable code is at least the same or e!en more
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
- &oftware &i'e could be reduced by
&oftware 0e-use
Fse of 4(T& =4ommercial (ff-The &helf &oftware;
2rogramming 7anguages
(RA6MATIC SOFTWARE ESTIMATION"
- If there is no proper well-documented case studies then it is difficult to estimate the cost of the
software. It is one of the critical problem in software cost estimation.
- 9ut the cost model !endors claim that their tools are well suitable for estimating iterati!e
de!elopment pro%ects.
- In order to estimate the cost of a pro%ect the following three topics should be considered
1; ,hich cost estimation model to use.
2; ,hether to measure software si'e in &7(4 or function point.
"; ,hat constitutes a good estimate.
- There are a lot of software cost estimation models are a!ailable such as
4(4(*( 4./4O2(I-T /&TI*34& Onowledge 2lan 2rice-&
2roG*& &//0 &7I* &(<T4(&T and &2G0:2$.
- (f which 4(4(*( is one of the most open and well-documented cost estimation models
- The software si'e can be measured by using
1; &7(4 2; <unction points
- *ost software experts argued that the &7(4 is a poor measure of si'e. 9ut it has some !alue in the
software Industry.
- &7(4 wor+ed well in applications that were custom built why because of easy to automate and
instrument.
- -ow a days there are so many automatic source code generators are a!ailable and there are so
many ad!anced higher-le!el languages are a!ailable. &o &7(4 is a uncertain measure.
- The main ad!antage of function points is that this method is independent of the technology and is
therefore a much better primiti!e unit for comparisons among pro%ects and organi'ations.
- The main disad!antage of function points is that the primiti!e definitions are abstract and
measurements are not easily deri!ed directly from the e!ol!ing artifacts.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA,Asst.Prof 2010
- <unction points is more accurate estimator in the early phases of a pro%ect life cycle. In later
phases &7(4 becomes a more useful and precise measurement basis of !arious metrics perspecti!es.
- The most real-world use of cost models is bottom-up rather than top-down.
- The software pro%ect manager defines the target cost of the software then manipulates the parameters and
si'ing until the target cost can be %ustified.
www.jntuworld.com
www.jntuworld.com