www.jntuworld.

co
m

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
development.
3. In the mid-1990s, three important analyses were performed on the software engineering industry.
All three analyses given the same general conclusion:-
“The success rate for software projects is very low”.
They Summarized as follows:
1. Software development is still highly unpredictable. Only 10% of software projects are delivered successfully
within initial budget and scheduled time.
2. Management discipline is more differentiator in success or failure than are technology advances.
3. The level of software scrap and rework is indicative of an immature process.
Software management process framework:
WATERFALLL MODEL
1. It is the baseline process for most conventional software projects have used.
2. We can examine this model in two ways:
i. IN THEORY
ii. IN PRACTICE
IN THEORY:-
In 1970, Winston Royce presented a paper called “Managing the Development of Large Scale
Software Systems” at IEEE WESCON.
Where he made three primary points:
1. There are two essential steps common to the development 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:

- System requirements definition

www.jntuworld.co
www.jntuworld.co
m

- Software requirements definition

- Program design and testing

These steps addition to the analysis and coding steps

3. Since the testing phase is at the end of the development cycle in the waterfall model, it may be risky and invites
failure.
So we need to do either the requirements must be modified or a substantial design changes is warranted by
breaking the software in to different pieces.
-There are five improvements to the basic waterfall model that would eliminate most of the development
risks are as follows:
a) Complete program design before analysis and coding begin (program design comes first):-
- By this technique, the program designer give surety that the software will not fail because of storage, timing, and
data fluctuations.
- Begin the design process with program designer, not the analyst or programmers.
- Write an overview document that is understandable, informative, and current so that every worker on the project
can gain an elemental understanding of the system.
b) Maintain current and complete documentation (Document the design):-
-It is necessary to provide a lot of documentation on most software programs.

www.jntuworld.co
www.jntuworld.co
m

- Due to this, helps to support later modifications by a separate test team, a separate maintenance team, and
operations personnel who are not software literate.
c) Do the job twice, if possible (Do it twice):-
- If a computer program is developed for the first time, arrange matters so that the version finally delivered
to the customer for operational deployment is actually the second version insofar as critical design/operations are
concerned.
- “Do it N times” approach is the principle of modern-day iterative development.
d) Plan, control, and monitor testing:-
- The biggest user of project resources is the test phase. This is the phase of greatest risk in terms of cost and
schedule.
- In order to carryout proper testing the following things to be done:
i) Employ a team of test specialists who were not responsible for the original design.
ii) Employ visual inspections to spot the obvious errors like dropped minus signs, missing factors of
two, jumps to wrong addresses.
iii) Test every logic phase.
iv) Employ the final checkout on the target computer.
e) Involve the customer:-
- It is important to involve the customer in a formal way so that he has committed himself at earlier points before
final delivery by conducting some reviews such as,
i) Preliminary software review during preliminary program design step.
ii) Critical software review during program design.
iii) Final software acceptance review following testing.
IN PRACTICE:-
- Whatever the advices that are given by the software developers and the theory behind the waterfall model, some
software projects still practice the conventional software management approach.
Projects intended for trouble frequently exhibit the following symptoms:
i) Protracted (delayed) integration
- In the conventional model, the entire system was designed on paper, then implemented all at once,
then integrated. Only at the end of this process was it possible to perform system testing to verify that the
fundamental architecture was sound.
- Here the testing activities consume 40% or more life-cycle resources. ACTIVITY
COST
Management 5%
Requirements 5%
Design 10%
Code and unit testing 30%
Integration and test 40%
Deployment 5%
Environment 5%

www.jntuworld.co
www.jntuworld.co
m

ii) Late Risk Resolution

- A serious issues associated with the waterfall life cycle was the lack of early risk resolution. The risk
profile of a waterfall model is,

www.jntuworld.co
www.jntuworld.co
m

- It includes four distinct periods of risk exposure, where risk is defined as “the probability of missing a
cost, schedule, feature, or quality goal”.

iii) Requirements-Driven Functional Decomposition

-Traditionally, the software development process has been requirement-driven: An attempt is made to provide a
precise requirements definition and then to implement exactly those requirements.
-This approach depends on specifying requirements completely and clearly before other development activities
begin.
- It frankly treats all requirements as equally important.
- Specification of requirements is a difficult and important part of the software development process.
iv) Adversarial Stakeholder Relationships
The following sequence of events was typical for most contractual software efforts:
- The contractor prepared a draft contact-deliverable document that captured an intermediate artifact and delivered
it to the customer for approval.
- The customer was expected to provide comments (within 15 to 30 days)
- The contractor integrated these comments and submitted a final version for approval (within 15 to 30 days)

Project Stakeholders :

 Stakeholders are the people involved in or affected by project activities

 Stakeholders include
 the project sponsor and project team
 support staff
 customers
 users
 suppliers
 opponents to the project

v) Focus on Documents and Review Meetings

- The conventional process focused on various documents that attempted to describe the software product.
- Contractors produce literally tons of paper to meet milestones and demonstrate progress to stakeholders, rather
than spend their energy on tasks that would reduce risk and produce quality software.
- Most design reviews resulted in low engineering and high cost in terms of the effort and schedule involved in
their preparation and conduct.

www.jntuworld.co
www.jntuworld.co
m

www.jntuworld.co
www.jntuworld.co
m

www.jntuworld.co
www.jntuworld.co
m

www.jntuworld.co
www.jntuworld.co
m

www.jntuworld.co
www.jntuworld.co
m

CONVENTIONAL SOFTWARE MANAGEMENT PERFORMANCE

Barry Boehm’s Top 10 “Industrial Software Metrics”:

1) Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the
problem in early design phases.

2) You can compress software development schedules 25% of nominal (small), but no more.

3) For every $1 you spend on development, you will spend $2 on maintenance.

4) Software development and maintenance costs are primarily a function of the number of source lines of
code.

5) Variations among people account for the biggest difference in software productivity.

6) The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985, 85:15.

7) Only about 15% of software development effort is devoted to programming.

8) Software systems and products typically cost 3 times as much per SLOC as individual software programs.
Software-system products cost 9 times as much.

9) Walkthroughs catch 60% of the errors.

10) 80% of the contribution comes from 20% of the contributors.

- 80% of the engineering is consumed by 20% of the requirements.

- 80% of the software cost is consumed by 20% of the components.

- 80% of the errors are caused by 20% of the components.

- 80% of the software scrap and rework is caused by 20% of the errors.

- 80% of the resources are consumed by 20% of the components.

- 80% of the engineering is accomplished by 20% of the tools.

- 80% of the progress is made by 20% of the people.

www.jntuworld.co
www.jntuworld.co
m

Part-2
Evolution of Software Economics

Economics means System 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) Size: Which is measured in terms of the number of Source Lines Of Code or the number of
function points required to develop the required functionality.

2) Process: Used to produce the end product, in particular the ability of the process is to avoid non-
value-adding activities (rework, bureaucratic delays, communications overhead).

3) Personnel: The capabilities of software engineering personnel, and particularly their experience
with the computer science issues and the application domain issues of the project.

4) Environment: Which is made up of the tools and techniques available to support efficient
software development and to automate the process.

5) Quality: It includes its features, performance, reliability, and flexibility.

The relationship among these parameters and estimated cost can be calculated by using,

Effort = (Personnel) (Environment) (Quality) (SizeProcess)

- One important aspect of software economics is that the relationship between effort and size
exhibits a diseconomy of scale and is the result of the process exponent being greater than 1.0.

- Converse to most manufacturing processes, the more software you build, the more expensive it is
per unit
item.
- There are three generations of basic technology advancement in tools, components, and processes

are available.
1) Conventional: 1960 and 1970, Craftsmanship. Organizations used custom tools, custom
processes, and virtually all custom components built in primitive languages. Project performance was highly
predictable.

www.jntuworld.co
www.jntuworld.co
m

2) Transition: 1980 and 1990, software engineering. Organizations used more-repeatable processes
and off-the-shelf tools, and mostly (>70%) custom components built in higher level languages.

- Some of the components (<30%) were available as commercial products like, OS, DBMS,
Networking and GUI.

3) Modern practices: 2000 and later, software production.

- 70% component-based,

- 30% custom

Conventional Transition Modern Practices

- 1960s – 1970s - 1980s –1990s - 2000 and on

- Waterfall model - Process improvement - Iterative development

- Functional design - Encapsulation - based - Component-based

- Diseconomy of scale- Diseconomy of scale- ROI

E nv i r o n m e n t s / t o o l s :

Custom Off-the-shelf, separate Off-the-shelf, Integrated

S i ze:

100% custom 30% component-based 70% component-based

70% custom 30% custom

Pr o c e s s :

Ad hoc Repeatable Managed/measured

T y p i c a l p r o j e c t P e r f o r m a n c e :

Always: Infrequently: Usually:

Over budget On budget On budget

Over schedule On schedule On schedule

What Does Return On Investment - ROI Mean?

www.jntuworld.co
www.jntuworld.co
m

A performance measure used to evaluate the efficiency of an investment or to compare the

efficiency of a number of different investments. To calculate ROI, the benefit (return) of an investment is
divided by the cost of the investment; the result is expressed as a percentage or a ratio.

The return on investment formula:

Return on investment is a very popular metric because of its versatility and simplicity. That
is, if an investment does not have a positive ROI, or if there are other opportunities with a higher ROI, then
the investment should be not be undertaken

Project Sizes :

• Size as team strength could be :

– Trivial (Minor) Size: 1 person

– Small Size: 5 people
– Moderate Size: 25 people
– Large Size: 125 people
– Huge Size: 625 people
• The more the size, the greater are the costs of management overhead, communication, synchronizations
among various projects or modules, etc.

Reduce Software Size:

The less software we write, the better it is for project management and for product quality
- The cost of software is not just in the cost of ‘coding’ alone; it is also in
Analysis of requirements
– Design
– Review of requirements, design and code
– Test Planning and preparation
– Testing
– Bug fix
– Regression testing
– ‘Coding’ takes around 15% of development cost
- Clearly, if we reduce 15 hrs of coding, we can directly reduce 100 hrs of development effort, and also
reduce the project team size appropriately !
- Size reduction is defined in terms of human-generated source code. Most often, this might still mean that
the computer-generated executable code is at least the same or even more

www.jntuworld.co
www.jntuworld.co
m

- Software Size could be reduced by

– Software Re-use
– Use of COTS (Commercial Off-The Shelf Software)
– Programming Languages

PRAGMATIC 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.

- But the cost model vendors claim that their tools are well suitable for estimating iterative
development projects.

- In order to estimate the cost of a project the following three topics should be considered,

1) Which cost estimation model to use.

2) Whether to measure software size in SLOC or function point.

3) What constitutes a good estimate.

- There are a lot of software cost estimation models are available such as,

COCOMO, CHECKPOINT, ESTIMACS, Knowledge Plan, Price-S,

ProQMS, SEER, SLIM, SOFTCOST, and SPQR/20.

- Of which COCOMO is one of the most open and well-documented cost estimation models

- The software size can be measured by using

1) SLOC 2) Function points

- Most software experts argued that the SLOC is a poor measure of size. But it has some value in the
software Industry.

- SLOC worked well in applications that were custom built why because of easy to automate and
instrument.

- Now a days there are so many automatic source code generators are available and there are so
many advanced higher-level languages are available. So SLOC is a uncertain measure.

- The main advantage of function points is that this method is independent of the technology and is
therefore a much better primitive unit for comparisons among projects and organizations.

- The main disadvantage of function points is that the primitive definitions are abstract and
measurements are not easily derived directly from the evolving artifacts.

www.jntuworld.co
www.jntuworld.co
m

- Function points is more accurate estimator in the early phases of a project life cycle. In later
phases, SLOC becomes a more useful and precise measurement basis of various metrics perspectives.

- The most real-world use of cost models is bottom-up rather than top-down.

- The software project manager defines the target cost of the software, then manipulates the parameters and
sizing until the target cost can be justified.

www.jntuworld.co