Temporal Relations of SWLC Phases For Various Software Development Models (Click for Table)

The development times don't change much for each of the models but the O & M time could be 4 to 50 times the total time to produce the product. If the requirements, specification and design times are reduced the length of the O & M phase increases. It really costs you when you try to decrease the amount of time you spend thinking about how you should do things. O & M is the phase that generates bad public relations for the firm, raises cost and creates chaos when things go wrong and errors are more difficult to correct.

During the requirements analysis the requirements must be stated in the client's language and a product traceability matrix set up. Establish a cut off date for requirements with the customer in writing and agree that there will be no new requirements accepted without renegotiations. Requirements are static or dynamic, well known or sketchy, complete or incomplete and adjectival or quantitative. Look out for those adjectival requirements that are not well defined and are subjective. Automatic capture of requirements as a basis for the Requirements Traceability Matrix (RTM) is the first item that should be placed under development configuration management.

During the specification phase three products are produced. The client domain specification (CDS) is produced in the client's language and looks like a block diagram of the program. The software architecture (SWA) simulation is in SW language, and the performance model or SW architecture is in the software. The CDS is the vehicle for requirement to specification discussions with the client. The SWA is the vehicle for coupling the CDS to our SW designers. SWA and SWD performance models will add detailed layers as the design grows.

The design phase starts out with the CDS, the SWA, the SWA performance model and the RTM. The SWA will consist of SW subjects. A subject is a set of objects and an object is a design task. Sometimes the word "module" is used for what Paul calls a "subject", but he regards the word module as too general. The design job is to produce subjects that have high cohesion and low coupling, both internally and with other subjects. Internal changes should not change the form of the output definition. Data should be changed in a data base and should not be changed internally. Examples of subjects could be data base handlers, the input interface, error handlers, the output interface, scheduler, math functions, built in self test, report generators and so forth. We must show the client how our program satisfies the requirements associated with a subject by using the CDS enhanced with details obtained from the subject design and do this in the client language. When the client understands and agrees then have the interface team certify the subject's object to object interfaces. Pass the design of the objects to the Chief Programmer for coding, to Configuration Management for entry and expand the CDS, SWA and SWA performance module. Each object design is in Parnas Form.

(Reporter note: Do a google search on David+Parnas+Form. The presentation "Barking up the Wrong Trees" is my recommendation.)

During the coding phase inputs are the subject designs that contain designs of the objects composing the subject, including any object to object interfaces. Each subject is a document (paper or magnetic) that tells the programmer the composition of the object including inputs, outputs, data types, and any necessary details including possible changes that may be required if other objects change. Performance estimates may be provided when they are known.

The test phase is performed by an independent test team that is completely independent of the coders. The coders are instructed not to do unit testing and to turn the code over to the testers as soon as they have compiled it successfully. The test team will perform all unit testing, object set testing, subject testing and integration tests. Each test yields test set data, results, a test coverage estimate, repair history and appropriate metrics.

As in the test phase, the implementation and operating phase draws on the results of the prior phases. Operational testing should be done by the client to let him catch any differences in our understanding of the requirements. The test team should have been thorough enough to keep the possibility of rude surprises low and is available to fix any embarrassments. Perform boot up and take metrics together with the client. Let the client do the boot up and enter incorrect data commands. Generate a to be fixed list with completion time estimates. If we do it right, the whole system will run the second time we boot it.

After delivery we enter the evolution and maintenance phase. Make a clear distinction between enhancement of the software, say to accommodate a lately resolved requirement, and maintenance to fix faults in this version. We need to give the client a method to separate these two interpretations of the term maintenance that is frequently used to describe both fixes and additions of capabilities. Paul said that when he used these procedures to design a system his team learned a lot, as did the client. If the process is done correctly there should be no remaining faults in the items that were agreed on in this version of the software.

In summary, establish a rapport with the client. There can be a problem if the client's software people don't like the fact that your team has been called in to accomplish the job and you must take action to insure that this does not make it impossible for you to do your job. Establish a rigorous process to accomplish software development. Paul recommends the Carnegie Mellon Capability Maturity Model. Establish a training agenda and support activities. Apply continual risk controls, look out for problems. People find it very difficult to schedule their own progress accurately. There must be well defined metrics used in each phase. Use automated tools including automatic test generators.

Paul Willis gave an excellent talk on very short notice. It was interesting and very thought provoking and many interesting and important things were presented that are not fully recorded in this short report. We are sorry that the LA Chapter of ACM was unable to provide the program that we advertised, but Paul Willis provided a high quality presentation. Unfortunately, the software development community that we would expect to be interested in it never heard about it in advance.