Binary Cipher
Chapter – 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 also its flexibility:
– The almost anythingcharacteristic 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 reached the same general conclusion: The success rate for software projects is very low.
The analyses can be 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 of a discriminator 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:
THE WATERFALL 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 and Coding
2. In order to manage and control all of the intellectual freedom associated with software development one should follow the following steps:
– System requirements definition
– Software requirements definition
– Program design and testing
These steps are 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 designers 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.
– 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 the 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 and late design breakage
– 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%
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,
– 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:
If 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.
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.
Previous Questions:
1. List and explain ten reasons of why conventional software management does not perform satisfactory?[may 2007]
2. What are the draw backs of Waterfall model?[nov 2008]
3. Describe waterfall model ?Give an application which can be developed using waterfall model?[oct 2011]
4. What is meant by late risk resolution?
A comprehensive transaction screen provides all the load data and lets you manage and view it whenever you want. field service management software