Viewing page 59 of 172

This transcription has been completed. Contact us with corrections.

c. Discussion of the Milestone History Data

To effectively analyze the relative success of the reconfiguration process, delivery of products must be put in the context of the schedule being worked to at the time of delivery. This procedure is particularly necessary given the continual schedule slips induced by launch date slips. The performance of individual workstations within the reconfiguration process, as well as the overall reconfiguration process, can be measured using the technique of normalization, which adjusts data for the schedule being worked to at the time of product delivery.

d. Individual Workstation Performance

Several representative workstations will be discussed. It should be noted that the data used for this report are the combined best inputs from the individual workstations and the Mission Requirements Management System (MRMS) data base. The reconstructed data have some limitations, in that the process of recording the data for the purpose of providing historical perspective was just being introduced. Nevertheless, it is felt that information has been made as reliable and correct as possible.

(1) Crew Activity Planning

The delivery of the basic version of the Crew Activity Plan relative to the actual launch date from STS-5 through STS 51-L was on time or early. The early deliveries can largely be attributed to launch date slips. Similarly, the final version of the Crew Activity Plan was generally delivered on or before the actual due date, and revisions were made as close to launch as required.

(2) Flight Design

The delivery of the end product of the cycle 1 (first iteration two total) flight design process was generally close to the date required for flights through STS 51-L.

(3) Flight Software

The initial release of the Orbiter flight software compared to the template objective of delivery at L-140 days is somewhat later than desired. Research into the causes show that most slips were due to inputs to the flight software workstation that were not on time, or to programmatically induces delays that were recognized and agreed to at the time. Flights 61-C and 51-L are good examples of the latter, as those delays were induced by a program decision to incorporate nose-wheel steering software changes into the first delivery of software for those two flights, and to accept a delay as a result. Historical analysis has shown that the flight software deliveries are a good barometer of the performance of the workstations upstream of it, so it

-95-