D.

SAMEERA 2010
UNIT-II
Improving Software Economics
- It is not that much easy to improve the software economics but also difficult to measure and
validate.
- There are many aspects are there in order to improve the software economics they are, Sie,
!rocess, !ersonnel, Environment and "uality.
- These parameters #aspects$ are not independent they are dependent. %or e&ample, tools enable
sie reduction and process improvements, sie-reduction approaches lead to process changes,
and process improvements drive tool re"uirements.
- 'UI technology is a good e&ample of tools enabling a new and different process. 'UI builder
tools permitted engineering teams to construct an e&ecutable user interface faster and less cost.
- Two decades ago, teams developing a user interface would spend e&tensive time analying
factors, screen layout, and screen dynamics. (ll this would done on paper. )here as by using
'UI, the paper descriptions are not necessary.
- (long with these five basic parameters another important factor that has influenced software
technology improvements across the board is the ever-increasing advances in hardware
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
performance.
REDUCING SOFTWARE PRODUCT SIZE:
- *y choosing the type of the language
- *y using +b,ect-+riented methods and visual modeling
- *y reusing the e&isting components and building reusable components -
- *y using commercial components,we can reduce the product sie of a software.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
.ere U!%s #Universal %unction !oints$ are useful estimators for language-independent in the
early life cycle phases. The basic units of function points are/
- E&ternal user inputs
- E&ternal outputs
- Internal logical data groups
- E&ternal data Interfaces
- E&ternal in"uiries
OBJECT ORIENTED METHODS AND VISUAL MODELING:
- There has been a widespread movements in the 0112s toward +b,ect-+riented
technology.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
- Some studies concluded that +b,ect-+riented programming languages appear to benefit
both software productivity and software "uality. +ne of such +b,ect-+riented method is U34-
Unified 3odeling 4anguage.
Booch described the folloi!" three re#so!s for the s$ccess of the %ro&ects th#t #re $si!"
Ob&ect'Orie!ted co!ce%ts:
0$ An OO-model of the problem and its solution encourages a common vocabulary
between the end user of a system and its developers, thus creating a shared understanding of the
problem being solved.
5$ The use of continuous integration creates opportunities to recognize risk early and
make incremental corrections without weaken the entire development effort.
3 An OO-architecture provides a clear separation among different elements of a system,
crating firewalls that prevent a change in one part of the system from the entire architecture.
(e #lso s$""ested fi)e ch#r#cteristics of # s$ccessf$l OO'Pro&ect*
0$ ( cruel focus on the development of a system that provides a well understood
collection of essential minimal characteristics.
5$ The e&istence of a culture that is centered on results, encourages communication, and
yet is not afraid to fail.
6$ The effective use of ++-modeling.
7$ The e&istence of a strong architectural vision.
8$ The application of a well-managed iterative and incremental development life cycle.
REUSE:
+rganiations that translates reusable components into commercial products has the
following characteristics/
- They have an economic motivation for continued support.
- They ta9e ownership of improving product "uality, adding new features and
transitioning to new technologies.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
- They have a sufficiently broad customer base to be profitable.
COMMERCIAL COMPONENTS
I+PRO,ING SOFTWARE PROCESSES:
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
There are three distinct process perspectives/
-. +et# %rocess:
- It is an +rganiation:s policies, procedures, and practices for pursuing a software-
intensive line of business.
- The focus of this process is of organiational economics, long-term strategies, and
a software ;+I.
/. +#cro %rocess:
- ( pro,ect:s policies, and practices for producing a complete software product
within certain cost, schedule, and "uality constraints.
- The focus of the macroprocess is on creating an sufficient instance of the
metaprocess for a specific set of constraints.
0. +icro %rocess:
- ( pro,ects team:s policies, procedures, and practices for achieving an artifact of a
software process.
- The focus of the microprocess is on achieving an intermediate product baseline
with sufficient functionality as economically and rapidly as practical.
The ob,ective of process improvement is to ma&imie the allocation of resources to
productive activities and minimie the impact of overhead activities on resources such as
personnel, computers, and schedule.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
I+PRO,ING TEA+ EFFECTI,ENESS:
- <+<+3+ model suggests that the combined effects of personnel s9ill and e&perience can
have an impact on productivity as much as a factor of four over the uns9illed personnel.
- *alance and coverage are two of the most important features of e&cellent teams.
)henever a team is in out of balance then it is vulnerable.
- It is the responsibility of the pro,ect manager to 9eep trac9 of his teams. Since teamwor9
is much more important than the sum of the individuals.
*oehm = staffing principles/
0$ The %ri!ci%le of to% t#le!t: Use better and fewer people.
5$ The %ri!ci%le of &ob 1#tchi!": %it the tas9s to the s9ills and motivation of the people
available.
6$ The %ri!ci%le of c#reer %ro"ressio!: (n organiation does best in the long run by
helping its people to self-actualie.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
7$ The %ri!ci%le of te#1 b#l#!ce: Select people who will complement and synchronie
with one another.
8. The %ri!ci%le of %h#se'o$t: >eeping a misfit on the team doesn:t benefit anyone.
I! "e!er#l* st#ffi!" is #chie)ed b2 these co11o! 1ethods:
If people are already available with re"uired s9ill set, ,ust ta9e them
If people are already available but do not have the re"uired s9ills, re-train them
If people are not available, recruit trained people
If you are not able to recruit s9illed people, recruit and train people
St#ffi!" of 3e2 %erso!!el is )er2 i1%ort#!t:
- !ro,ect 3anager
- Software (rchitect
I1%ort#!t Pro&ect +#!#"er S3ills:
(iri!" s3ills4 %ew decisions are as important as hiring decisions. !lacing the right person
in the right ,ob seems obvious but is surprisingly hard to achieve.
C$sto1er'i!terf#ce s3ill4 (voiding adversarial relationships among sta9e-holders is a
prere"uisite for success.
Decisio!'1#3i!" s3ill4 The ,illion boo9s written about management have failed to
provide a clear definition of this attribute. )e all 9now a good leader when we run into
one, and decision-ma9ing s9ill seems obvious despite its intangible definition.
Te#1'b$ildi!" s3ill4 Teamwor9 re"uires that a manager establish trust, motivate
progress, e&ploit eccentric prima donnas, transition average people into top performers,
eliminate misfits, and consolidate diverse opinions into a team direction.
Selli!" s3ill4 Successful pro,ect managers must sell all sta9eholders #including
themselves$ on decisions and priorities, sell candidates on ,ob positions, sell changes to
the status "uo in the face of resistance, and sell achievements against ob,ectives. In
practice, selling re"uires continuous negotiation, compromise, and empathy.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
I1%ort#!t Soft#re Architect S3ills:
Technical S9ills/ the most important s9ills for an architect. These must include
s9ills in both, the problem domain and the solution domain
!eople 3anagement S9ills/ must ensure that all people understand and
implement the architecture in e&actly the way he has conceptualied it. This
calls for a lot of people management s9ills and patience.
;ole 3odel/ must be a role model for the software engineers = they would
emulate all good #and also all bad ?$ things that the architect does
I+PRO,ING AUTO+ATION T(ROUG( SOFTWARE
EN,IRON+ENTS
The following are the some of the configuration management environments
which provide the foundation for executing and implementing the process:
!lanning tools, @uality assurance and analysis tools, Test tools, and User
interfaces provide crucial automation support for evolving the software engineering
artifacts.
Round-trip enineerin: is a term used to describe the 9ey capability of
environments that support iterative development.
!or"#rd enineerin: is the automation of one engineering artifact from
another, more abstract representation. E&/ compilers and lin9ers
Re$er%e enineerin: is the generation of modification of more abstract
representation from an e&isting artifact. E&/ creating visual design model from
a source code.
AC(IE,ING RE5UIRED 5UA6IT7:
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
>ey elements that improve overall software "uality include the
following/
- %ocusing on powerful re"uirements and critical use case early in the life
cycle
- %ocusing on re"uirements completeness and traceability late in the life cycle
- %ocusing throughout the life cycle on a balance between re"uirements
evolution, design evolution, and plan evolution
- Using metrics and indicators to measure the progress and "uality of an
architecture as it evolves from high-level prototype into a fully biddable
product
- !roviding integrated life-cycle environments that support early and
continuous configuration control, change management, rigorous design
methods, document automation, and regression test automation
- Using visual modeling and higher level languages that support architectural
control, abstraction, reliable programming, reuse, and self-documentation
- Early and continuous close loo9 into performance issues through
demonstration-based evaluations
I! order to e)#l$#te the %erfor1#!ce the folloi!" se8$e!ce of e)e!ts #re !ecess#r2*
0$ !ro,ect inception 5$ Initial design review
5$ 3id-life-cycle design review 7$ Integration and test
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010

www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
PEER INSPECTIONS: A PRAG+ATIC ,IEW:
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
T(E O6D WA7 AND T(E NEW
- +ver the past two decades software development is a re-engineering process.
Now it is replaced by advanced software engineering technologies.
- This transition is was motivated by the unsatisfactory demand for the software
and reduced cost.
T(E PRINCIP6ES OF CON,ENTIONA6 SOFTWARE ENGINEERING
*ased on many years of software development e&perience, the software
industry proposed so many principles #nearly 520 by = Aavis:s$. +f which
Aavis:s top 62 principles are/
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
0$ +#3e 8$#lit2 9-: @uality must be "uantified and mechanisms put into place
to motivate its achievement.
5$ (i"h'8$#lit2 soft#re is %ossible: In order to improve the "uality of the
product we need to involving the customer, select the prototyping, simplifying
design, conducting inspections, and hiring the best people.
6$ Gi)e %rod$cts to c$sto1ers e#rl2: No matter how hard you try to learn user:s
needs during the re"uirements phase, the most effective way to determine real
needs is to give users a product and let them play with it.
7$ Deter1i!e the %roble1 before riti!" the re8$ire1e!ts: )henever a
problem is raised most engineers provide a solution. *efore we try to solve a
problem, be sure to e&plore all the alternatives and don:t be blinded by the
understandable solution.
8$ E)#l$#te desi"! #lter!#ti)es: (fter the re"uirements are greed upon, we must
e&amine a variety of architectures and algorithms and choose the one which is not
used earlier.
B$ Use #! #%%ro%ri#te %rocess 1odel: %or every pro,ect, there are so many
prototypes #process models$. So select the best one that is e&actly suitable to our
pro,ect.
C$ Use differe!t l#!"$#"es for differe!t %h#ses: +ur industry:s main aim is to
provide simple solutions to comple& problems. In order to accomplish this goal
choose different languages for different modulesDphases if re"uired.
E$ +i!i1i:e i!tellect$#l dist#!ce: )e have to design the structure of a software
is as close as possible to the real-world structure.
1$ P$t tech!i8$es before tools: (n un disciplined software engineer with a tool
becomes a dangerous, undisciplined software engineer.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
02$ Get it ri"ht before 2o$ 1#3e it f#ster: It is very easy to ma9e a wor9ing
program run faster than it is to ma9e a fast program wor9. Aon:t worry about
optimiation during initial coding.
00$ I!s%ect the code: E&amine the detailed design and code is a much better way
to find the errors than testing.
05$ Good 1#!#"e1e!t is more important than good technology
06$ Peo%le #re the 3e2 to s$ccess: .ighly s9illed people with appropriate
e&perience, talent, and training are 9ey. The right people with insufficient tools,
languages, and process will succeed.
07$ Follo ith c#re: Everybody is doing something but does not ma9e it right
for you. It may be right, but you must carefully assess its applicability to your
environment.
08$ T#3e res%o!sibilit2: )hen a bridge collapses we as9 Fwhat did the engineer
do wrongGH. Similarly if the software fails, we as9 the same. So the fact is in
every engineering discipline, the best methods can be used to produce poor results
and the most out of date methods to produce stylish design.
-;. U!derst#!d the c$sto1er<s %riorities. It is possible the customer would
tolerate 12I of the functionality delivered late if they could have 02I of it on
time.

-=. The 1ore the2 see* the 1ore the2 !eed. The more functionality #or
performance$ you provide a user, the more functionality #or performance$ the
user wants.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
->. Pl#! to thro o!e ##2 .+ne of the most important critical success factors
is whether or not a product is entirely new. Such brand-new applications,
architectures, interfaces, or algorithms rarely wor9 the first time.
-?. Desi"! for ch#!"e. The architectures, components, and specification
techni"ues you use must accommodate change.
/@. Desi"! itho$t doc$1e!t#tio! is !ot desi"!. I have often heard software
engineers say, FI have finished the design. (ll that is left is the documentation.H
21. Use tools* b$t be re#listic. Software tools ma9e their users more efficient.
22. A)oid tric3s. 3any programmers love to create programs with tric9s-
constructs that perform a function correctly, but in an obscure way. Show the
world how smart you are by avoiding tric9y code.
23. E!c#%s$l#te. Information-hiding is a simple, proven concept that results in
software that is easier to test and much easier to maintain.
24. Use co$%li!" #!d cohesio!. <oupling and cohesion are the best ways to
measure software:s inherent maintainability and adaptability.
25. Use the +cC#be co1%leAit2 1e#s$re. (lthough there are many metrics
available to report the inherent comple&ity of software, none is as intuitive and
easy to use as Tom 3c<abe:s.
26. Do!<t test 2o$r o! soft#re. Software developers should never be the
primary testers of their own software.
27. A!#l2:e c#$ses for errors. It is far more cost-effective to reduce the effect of
an error by preventing it than it is to find and fi& it. +ne way to do this is to
analye the causes of errors as they are detected.
2. Re#li:e th#t soft#re<s e!tro%2 i!cre#ses. (ny software system that
undergoes continuous change will grow in comple&ity and become more and
more disorganied.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
2!. Peo%le #!d ti1e #re !ot i!terch#!"e#ble. 3easuring a pro,ect solely by
person-months ma9es little sense.
0@. EA%ert eAcelle!ce. Jour employees will do much better if you have high
e&pectations for them.
T(E PRINCIP6ES OF +ODERN SOFTWARE +ANAGE+ENT
0$ *ase the process on an architecture-first approach/ #<entral design element$
- Aesign and integration first, then production and test
5$ Establish an iterative life-cycle process/ #The ris9 management element$
- ;is9 control through ever-increasing function, performance, "uality.
)ith today:s sophisticated systems, it is not possible to define the entire
problem, design the entire solution, build the software, then test the end product in se"uence.
Instead, and iterative process that refines the problem understanding, an effective solution,
and an effective plan over several iterations encourages balanced treatment of all sta9eholder
ob,ectives.
3a,or ris9s must be addressed early to increase predictability and avoid e&pensive
downstream scrap and rewor9.
6$ Transition design methods to emphasie component-based development/ #The
technology element$
3oving from 4+< mentally to component-based mentally is necessary to
reduce the amount of human-generated source code and custom development.( component is
a cohesive set of pree&isting lines of code, either in source or e&ecutable format, with a
defined interface and behavior.
7$ Establish a change management environment/ #The control element$
- 3etrics, trends, process instrumentation
The dynamics of iterative development, include concurrent wor9flows by different
teams wor9ing on shared artifacts, necessitates ob,ectively controlled baseline.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
8$ Enhance change freedom through tools that support round-trip engineering/ #The
automation element$
- <omplementary tools, integrated environment
;ound-trip engineering is the environment support necessary to automate and
synchronie engineering information in different formats. <hange freedom is necessary in an
iterative process.
B$ <apture design artifacts in rigorous, model-based notation/
- ( model-based approach supports the evolution of semantically rich graphical and
te&tual design notations.
- Kisual modeling with rigorous notations and formal machine- process able language
provides more ob,ective measures than the traditional approach of human review and
inspection of ad hoc design representations in paper doc.
C$ Instrument the process for ob,ective "uality control and progress assessment/
- 4ife-cycle assessment of the progress and "uality of all intermediate product must be
integrated into the process.
- The best assessment mechanisms are well-defined measures derived directly from the
evolving engineering artifacts and integrated into all activities and teams.
E$ Use a demonstration-based approach to assess intermediate artifacts/
Transitioning from whether the artifact is an early prototype, a baseline architecture,
or a beta capability into an e&ecutable demonstration of relevant provides more tangible
understanding of the design tradeoffs, early integration and earlier elimination of architectural
defects.
1$ !lan intermediate releases in groups of usage scenarios with evolving levels
of detail/
02$ Establish a configurable process that economically scalable/
No single process is suitable for all software developments. The process must
ensure that there is economy of scale and ;+I.
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
www.jntuworld.com
www.jntuworld.com
D.SAMEERA 2010
www.jntuworld.com
www.jntuworld.com