Managing the development of large software systems pdf

You have to get it before you can do it, and the types of programmers who were inclined to get it weren't in decision-making positions. Another great story that Larman told was that he tracked down some of the programmers on famous waterfall projects that had succeeded, and found out that what they had really done was write code first, secretly, and then write up the requirements and design docs based on what they had learned.

In other words they did things in the 'wrong' order but published them in the 'right' order. It does seem likely. Further, it probably came directly out of the nature of programming on expensive, shared, and often batched machines.

I still think one has to ignore most of the Royce's paper to not pick up on iteration paradigm. But, I could easily see someone in that mentality sort of glossing over it, spotting a diagram of their current flow, giving it a name, and pushing it from there.

Finally read the paper you gave me. It was really neat to see iterative development kept getting independently invented from the 60's onward. It getting into the mainstream was an inevitability due to its inherent advantages. The majority just couldn't contain it within limited groups forever.

Safety-critical design is like waterfall or spiral on steroids with specs, constraints on implementation, rigorous testing, analysis To outsiders, it seems they're using a waterfall-like refinement strategy to build these things. Insiders trying to get Agile methods in there have countered that with an unusual supporting argument: successful projects already use an iterative process combining top-down and ground-up work that results in a linked, waterfall-like chain of deliverables.

The actual work is often done differently, though, so why not allow that kind of development in the first place? With your comment, I've heard that twice. Another quick one was Mills' people not being able to run their own code in Cleanroom. Sometimes it wasn't necessary but it has many benefits. So, of course they often ran their own code during prototyping phase to get an idea of how the final submission should be done. We'll all be better off when management lets their processes reflect the realities of development.

At least it's already happening in some firms and spreading. How did I never read this paper before now!? People have been bashing waterfall for a long time. If this paper originated it, then the resulting waterfalls say more about the readers and IT culture than the visionary that recommended a very, adaptive process. A few points on the paper. The author describes the software development as a creative process. Most managers and even many CompSci researchers thought it was mechanical with potential for automation and assembly-line type guidance.

He wisely contradicts that in a way that I hope was to help us all out by putting reality in management reader's heads. I used to think one person did waterfall followed by other models eg Spiral realizing initial work usually failed and is rewritten.

Now I know it's the opposite: waterfall author knew requirements or design would require rewrites. Even made new diagrams for it. In these assignments I have experienced different degrees of successwith respect to arriving at an operational state, on-time, and wi th in costs. I have become prejudiced by my experiences and I am going to… Expand. View on ACM.

Save to Library Save. Create Alert Alert. Share This Paper. Background Citations. Methods Citations. Results Citations. Figures and Topics from this paper. Software system Nat unit Money Emoticon. Citation Type.

The following steps are required. Allocate processing, functions, design the data base, define data base processing, allocate execution time, define interfaces and processing modes with the operating system, describe input and output processing, and define preliminary operating procedures.

Each and every worker must have an elemental understanding of the system. At least one person must have a deep understand- ing of the system which comes partially from having had to write an overview document. Step 1 : Insure that a preliminary program design is complete before analysis begins. The first rule of managing software development is ruthless enforcement of documentation requirements.

Occasionally I am called upon to review the progress of other software design efforts. My first step is to investigate the state of the documentation, If the documentation is in serious default my first recommendation is simple. Replace project management. Stop all activities not related to documentation. Bring the documentation up to acceptable standards. Management of software is simply impossible w i t h o u t a very high degree of documentation.

As an example, let me offer the following estimates for comparison. In order to procure a 5 million dollar hardware device, I would expect that a 30 page specification would provide adequate detail to control the procurement.

A verbal record is too intangible to provide an adequate basis for an interface or manage- mentdecision. An acceptable written description forces the designer to take an unequivocal position and provide tangible evidence of completion. It prevents the designer from hiding behind t h e - " l ampercent finished" - syndrome month after month. Until coding begins these three nouns documentation, specification, design d e n o t e a s i n g t e t h i n g. If the documentation is bad the design is bad.

If the documentation does not yet exist there is as yet no design, only people thinking and talking about the design which is of some value, but not much. The value of documentation can be described in terms of three concrete, tangible situations that every program manager faces.

Without good documentation every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area. Without good documentation the software must be operated by those who built it. Generally these people are relatively disinterested in operations and do not do as effective a job as operations-oriented personnel.

It should be pointed out in this connection that in an operational situation, if there is some hangup the software is always blamed first. In order either to absolve the software or to fix the blame, the software documentation must speak clearly. If documentation does not exist, generally the entire existing framework of operating software must be junked, even for relatively modest changes. Figure 6 shows a documentation plan which is keyed to the steps previously shown.

Note that six documents are produced, and at the time of delivery of the final product, Documents No, 1, No. Figure 7 iltustrates how this might be carried out by means of a simulation. Note that it is simply the entire process done in miniature, t o a t i m e scale that is relatively small with respect to the overall effort. The nature of this effort can vary widely depending primarily on the overall time scale and the nature of the critical problem areas to be modeled. If the effort runs 30 months then this early development o f a p i l o t model might be scheduled for 10 months.

For this schedule, fairly formal controls, documentation procedures, etc. If, however, the overall effort were reduced to 12 months, then the pilot effort could be compressed to three months perhaps, in order to gain sufficient leverage on the mainline development. In this case a very special kind of broad competence is required on the part of the personnel involved. They must have an intuitive feel for analysis, coding, and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren't worth studying at this early point, and finally arrive at an error-free program.

In either case the point of all this, as with a simulation, is that questions of timing, storage, etc. Without this simulation the project manager is at the mercy of human judgment. With the simulation he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the area of computer program design as in the estimation of takeoff gross weight, costs to complete, or the daily double is invariably and seriously optimistic.

Step 3: A t t e m p t to do the job twice - the first result provides an early simulation of the final product.