>Date: Sat, 03 Feb 96 11:26:35 -0600 >From: "Brian A. Reynolds" >Subject: How Changes Are Actually Handled .>I have also heard an increase in nav database storage capacity would cost .>$100,000 per airplane(cockpit chit-chat). .I have heard a similar number. Have any of you engineering types heard .anything about costs? What follows is a satirical examination of the Design and Development Process. It's a bit long, but then I have to justify why a New Capability costs $100,000 per airplane. :) Consider this: Need to expand the data base storage capability using Newest Technology. This requires a new data bus as all memory now is based on a 32-bit word rather then the existing 16-bit word. We need to change the technology; we need to be New not Old - so we are different from those other folks making the same stuff. Slogan from Marketing: New == Good; Old == Bad. Don't use Systems Engineers. Problem is well understood so no need to question what the best solution to the problem is. To minimize time, give problem to Hardware and Software groups for a Concurrent Design Solution. Prepare Program Plan showing that this work can really be charged to another account. Hardware decides that a New Central Processor Card (Hey - we got the box open now's our chance!) is best. Need more memory as that is What The Customer Needs. Typical memory capacity has to be twice the expected need, with expansion capability of another twice expansion. (See we are tying to learn.) All this has to fit into the same size box as the old unit so it can be a retrofit. This requires the latest in high density packaging techniques (i.e. hardware folks run amok and design in all kinds of neat LITTLE stuff). Put this into an oven to see if it runs at 85C. Put it outside in the snow and see if it runs at -45C (OK - right now it's only -32C outside so go rent a cold chamber) Find out that your simulations of the neat little stuff was not really accurate. Find the timing problems and buy some more prototypes for about $2,000 each (for one Application Specific Integrated Circuit! Production prices are lower.) Repeat until problem is solved. Prepare a Software Development Plan. Can't do anything without a plan. Use lots of new abbreviations and acronyms. RTCA, ARINC, DO-160y and DO-178z. Plans are not acceptable if they are clear, concise, and readable. Plan for evaluating Plans and schedule lots of reviews. Plan on getting everyone involved in the reviews so that Mistakes Are Caught As Early As Possible. Make sure everyone has a Checklist. Checklists ensure that The Process is Followed and proves that You Did A Quality Job. Have all Members of the Team sign the checklist so everone is responsible when a Significant Problem is discoverd later in The Process. Write a Configuration Management Plan. CM Plans are GOOD. Review the plan with Software Quality Assurance - find out that they have their own Plan which they think is better. Try and find a Happy Medium and hire her as a consultant to Reconcile the Plans. Tell the FAA what you are going to do. Ask them if the Plans are OK. Try and convince them this is a Minor Change (It's Almost Like the Old One, So We Don't Need as Many Plans) rather then a Major Change (All new Plans are required and no one has ever used any of this neat little stuff before.) FAA is skeptical - but would like to go along as it means less paper flowing onto their desk so perhaps they would have a chance to have more going off their desk then is coming in. Agree to do Quallification By Similarity to show that the new stuff is really like the old stuff. Everyone is very relieved. When the design is realy, throw it over the wall to the software folks for testing. They find out that they are using the Hardware Specification Manual for the old system as Hardware was too busy Designing and Building and not Documenting. Write a few neat little macros to go in and automatically change the code so it will run on the new processor. Implement Stastical Process Control midway through this effort. Hold a few reviews. If they come out OK, release the software for Integration Testing. Let them find the remaining problems. 90% of schedule used, 75% of effort remaining. Reorganize and Write New Plans. Start Safety Analysis. Show that the Equipment is Nonessential and will have no effect on the airplane or its operation if it fails. Because time is of the essence, use lots of Hasty Generalizations. Make sure that the Pilot In the Loop As A Monitor philosophy gets maximum use. Discover that one of the engineers on the program is a Fully Certified, VFR rated Pilot on a Cesna-150. Provide all flight deck effects, cautions, and announciations to this Pilot for a professional review. Complete Integration Testing and throw the almost Fully Tested Prototype onto an airplane and fly to the airframer for more System Testing. Software Engineers go along with laptop computers, continuing the Integration Testing while traveling. (Using self contained shipping container. No liquids provided as sanitary facilities are not provided. Container is labeled 'Live Animals.') During testing at the Airframer, discover that the Wrong Problem was solved. Involve Systems Engineering to see what the Quick Solution is. Write more Plans. Define a Multiple Phase Certification Effort. Classify all problems as 'Must Fix' or 'Fix Someday.' To satisfy management, make all problems "Fix Someday." Write Reports to show that all Plans have been complied with. Reports are Good. Reports are better then Plans. Attempt to mazimize Report Generation as new unit cannot be approved until FAA engineering is totally buried under reports. One week prior to release of new unit to the airlines, give all engineering documentation to Product Support. Tell them that It's Really Important that they have a Product Support Plan in place by next week. Inform Airlines that the New Unit is not backwards compatable with the old units, so they will have to buy all new spares. Suppliers stock goes up. New Unit is also incompatable with old test equipment and if Product Support Ever Gets Done, new Provisioning Plans will be sent out. Write new Maintenance Manual. Use engineering data for production testing. Hide product test procedures from Maintence Manual writers. Airline maintenance shops finds out that the Maintenance Manual writers based their manual on the Old Design. Write word processing macros to update manual Cannot give Maintenance Manual to production test for proofing as they are in a different organization and there is no way to pay them. Work with airframer to test unit on a Real Airplane. Airframer charges developer for flight testing. Airframers stock goes up and Flight Test turns a profit. Suppliers stock goes down. More problem reports written during flight test phase. Classify them as "Fix Someday" due to schedule. Write Procedures To Work Around Problems. Reference Standard Procedure #1 (Reset Circuit Breaker) whenever possible in the firm belief that this will keep flight deck work load down. Write Service Bulletin for installation of new unit. Get internal signatures for release of document. Find out that you did not follow the "Release of Document for New Units which Replace Older Units Already In Service." Try and find Happy Medium. She is now working for the competition but she recommends her sister. Wrong Medium. Documentation release will only accept documents in Macintosh formatted disks, and all Documents were prepared instead using IBM's mainframe Document Composition Facility. Hire consultants to write a few macros to do the documentation conversion. Take Service Bulletin to Airframer. They only accept Service Bulletins using a Unix TAR formatted tape. Hire a different set of consultants to write a few macros to convert Macintosh formated disks to proper format. FAA needs to approve Service Bulleting. They require a paper copy as they have few computers, and no budget for extension cords. Find out that no one knows how to make a paper copy of the Service Bulletin. The one person who did quite, and is raising pinecones in Oregan. Hire consultant to prepare paper copy. FAA is skeptical, but approves service bulleting as we have shown that We Know What We are Doing, and this is Only Pro-Forma Anyway. Introduce new unit to fleet. Airline training realizes that the New Unit is not like the Old Unit. Updates traing sylabus overnight. Updates to procedures manuals prepared using the unproductive spare time which is usually used for sleeping. FAA is skeptical, but approves new training and procedures. Pilots reaction - "Look, all we wanted was a few more nav points added to the database!." Airframer writes problem report. Go to top of story. [One is cautioned about confusing humor with fact as this is a twisted composite of my experience with many companies and is provided only as a humorous confirmation of what the Flight Deck actually thinks goes on Brian]