Conventional Software Management

● The best thing about software is its flexibility. It can be used to programmed any thing.

● The worst thing about software is also its flexibility. The anything characteristic has made it difficult to
plan, monitor, and control software development.

● The analysis in software development states that, the success rate of software project is very low. The
following are three main reasons for low success rate.

a) Software development is highly unpredictable. Only 10% software projects are delivered successfully
within budget and time.

b) Management discipline is more discriminator in success or failure than technology advances.

c) The level of software scrap and rework is indicative of an immature process.

The Waterfall Model – In Practice

○ Protracted integration and late design breakage

○ Late risk resolution

○ Requirements-driven functional decomposition

○ Adversarial stakeholder relationships

○ Focus on documents and review meetings

● Barry Boehm top 10 list are as follows:

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

○ You can compress software development schedules 25% of nominal, but no more.

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

○ Software development and maintenance costs are primarily a function of the number of source
lines of code

○ Variations among people account for the biggest differences in software productivity

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

○ Only about 15% of software development effort is devoted to programming

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

● Walkthroughs catch 60% of the errors.

● 80% of the contribution comes from 20% of the contributors.

Evolution of software economics

● Economic results of conventional software projects reflect an industry dominated by custom development,
ad hoc processes and diseconomies of scale.

● Today’s cost models are based primarily on empirical project databases with very few modern iterative
development success stories.

● Good software cost estimates are difficult to attain. Decision makers must deal with highly imprecise
estimates.

● A modern process framework attacks the primary sources of the inherent diseconomy of scale in the
conventional software process.

● Five basic parameters of software cost models are as follows:

○ Size – end product, typically quantified in terms of the number of source instructions or the
number of function points required to develop the required functionality

○ Process – used to produce end product, the ability of the process to avoid non-value-adding
activities

○ Personnel – capabilities of software engineering personnel and particularly their experience with
the computer science issues and the applications domain issues of the project.
 ○ Environment – is made up of the tools and techniques available to support efficient software
development and to automate the process.

○ Quality – the required quality of the product, including its features, performance, reliability and
adaptability.

Software Economics

● Figure shows three generations of basic technology advancement in tools, components, and processes.

● The required levels of quality and personnel are assumed to be constant

● The ordinate of the graph refers to software unit costs realized by an organization.

● The three generations of software development are defined as follows:

○ Conventional

○ Transition

○ Modern practice

● Conventional - 1960s and 1970s craftsmanship

○ Organizations used custom tools, custom processes and virtually all custom components built in
primitive languages

○ Project performance was highly predictable in that cost, schedule and quality objectives were
almost under achieved

● Transition – 1980s and 1990s software engineering

○ Organizations used more-repeated processes and off-the-shelf tools.

○ Commercial products (os, dbms, n/w and graphics) are available

○ Some organizations began achieving economies of scale, with the growth in applications
complexity

● Modern practices – 2000 and later software production

○ 30% of the components are custom built

○ With the advances in the software technology and integrated production environments, these
component based systems can be produced very rapidly

Pragmatic Software Cost Estimation

● One critical problem in software cost estimation is a lack of well-documented case studies of projects that
used an iterative development approach.

● The data from actual projects are highly suspect in terms of consistency and comparability because the
software industry has in consistently defined metrics or atomic units of measure.

● Three points to decide on software cost are as follows:

○ Which cost estimation model to use?

○ Whether to measure software size in source lines of code or function points

○ What constitutes a good estimate?

○ It is conceived and supported by the project manager, architecture team, development team and
test team accountable for performing the work.

○ It is accepted by all stakeholders as ambitious but realize

○ It is based on a well defined software cost model with a credible basis

○ It is based on a database of relevant project experience that includes similar processes, similar
technologies, similar environments, similar quality requirements and similar people.

○ It is defined in enough detail so that its key risk areas are understood and the probability of
success is objectively assessed.

Improving Software Economics

● Improvements is the economics of software development have been not only difficult to achieve but also
difficult to measure and substantiate.

● The key to substantial improvement is a balanced attack across several interrelated dimensions.

● Five basic parameters of the software cost model are:

○ Reducing the size or complexity of what need to be developed

○ Improving the development process

○ Using more-skilled personnel and better teams

○ Using better environments

○ Trading off or backing off on quality thresholds

● GUI builder tools permitted engineering teams to construct an executable UI faster and at less cost.

● The new process was geared toward taking the UI through a few realistic versions, incorporating user
feedback and achieving a stable understanding of requirements and the design issues.

● Improvements in hardware performance also has influenced the software technology

Reducing software product size

● The way to improve affordability and return on investment (ROI) is to produce a product that achieves the
design goals with the minimum amount of human generated source material.

● CBD is introduced as the general term for reducing the source language size necessary to achieve a
software solution.

● Usage of newer programming languages contributed in reducing software product size

● UFP is used to indicate the relative program sizes required to implement a given functionality.

● The difference between large and small projects has a greater than linear impact on the life-cycle cost.

● O O Methods and Visual Modelling

● Five characteristics of a successful as described by booch are:

● A ruthless focus on the development of a system that provides a well understood collection of
essential minimal characteristics.

● The existence of a culture that is centered on results, encourages communication, and yet is not
afraid to fail

● The effectiveness use of object-oriented modelling

● The existence of a strong architectural vision

● Reuse

● Commercial Components

Improving Team Effectiveness

● Teamwork is much more important than the sum of the individuals.

● With software teams, a project manager needs to configure a balance of solid talent with highly skilled
people in the leverage positions

● Team management include the following:

○ A well-managed project can succeed with a nominal engineering team.

○ A mismanaged project will almost never succeed, even with an expert team of engineers

○ A well-architecture system can be built by a nominal team of software builders.

● To improve staff of software project, Boehm has offered the following staffing principles:

○ The principle of top talent: use better and fewer people

○ The principle of job matching: fit the tasks to the skills and motivation of the people available

○ The principle of career progression: an organization does best in the long run by helping its people
to self-actualize

○ The principle of team balance: select people who will complement and harmonize with one
another

○ The principle of phaseout: keeping a misfit on the team doesn’t benefit anyone

● Software development is a team sport

● Managers must nurture a culture of team work and results rather than individual accomplishment.

● Team balance and job matching are the primary objectives.

● Software project managers need many leadership qualities in order to enhance team effectiveness

● Following are the crucial attributes of a successful software project managers:

○ Hiring skills

○ Customer interface skills

○ Decision making skills

○ Team-building skills

Selling skills

Improving Automation through software environments

Achieving required quality

● Key practices that improve overall software quality:

○ Focusing on driving requirements and critical use cases early in the life cycle, focusing on
requirements completeness and traceability late in the life cycle, and focusing throughout the life
cycle on a balance between requirements evolution, design evolution, and plan evolution

○ Using metrics and indicators to measure the progress and quality of an architecture as it evolves
from a high-level prototype into a fully compliant product

○ Providing 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 language that support architectural control, abstraction,
reliable programming, reuse, and self-documentation

○ Early and continuous insight into performance issues through demonstration-based evaluations

● The typical chronology of events in performance assessment is as follows:

○ Project inception:
 ○ Initial design review

○ Mid-life-cycle design review

○ Integration and test

● This sequence occurred because early performance insight was based on naïve engineering judgement of
innumerable criteria.

● Early performance issue are typical.

● They tend to expose architectural flaws or weaknesses in commercial components.

Peer Inspections: A pragmatic view

Peer inspections are frequently overhyped as the key aspect of a quality system. Peer reviews are valuable as
secondary mechanisms, but they are rarely significant contributors to quality compared with following primary
quality mechanisms and indicators

The principles of conventional software engineering

Top 30 principles of David about conventional software engineering are as follows:

1. Make quality #1:

2. High-quality software is possible:

3. Give products to customer early:

4. Determine the problem before writing the requirements:

5. Evaluate design alternatives:

6. Use an appropriate process model:

7. Use different languages for different phases:

8. Minimize intellectual distance:

9. Put techniques before tools:

10. Get it right before you make it faster:

11. Inspect code:

12. Good management is more important than good technology:

13. People are the key to success:

14. Follow with care:

15. Take responsibility:

16. Understand the customer’s priorities:

17. The more they see, the more they need:

18. Plan to throw one away:

19. Design for change:

20. Design without documentation is not design:

22. Avoid tricks:

23. Encapsulate:

24. Use coupling and cohesion:

25. Use the McCabe complexity measure:

26. Don’t test your own software:

27. Analyze causes for errors:

28. Realize the software’s entropy increases:

29. People and time are not interchangeable:

30. Expect excellence:

The principles of modern software management

1. Base the process on an architecture-first approach:

2. Establish an iterative life-cycle process that confronts risk early:

3. Transition design methods to emphasize component based development:

4. Establish a change management environment:

5. Enhance change freedom through tools that support round-trip engineering:

6. Capture design artifacts in rigorous, model-based notation:

7. Instrument the process for objective quality control and progress assessment:

8. Use a demonstrate-based approach to assess intermediate artifacts:

9. Plan intermediate releases in groups of usage scenarios with evolving levels of detail:

10. Establish a configurable process that is economically scalable: