Do-178b Pub Talk

Pub Talk with a DO-178B Trail Guide By: Vincent P. Socci, Principal, On Target Technology Development (607) 755-4980, [email protected] Abstract – Many recent military software projects are demanding the development team to satisfy the objectives of DO-178B. Although the implementation of DO-178B guidelines is new to many organizations, consulting help is available from “DO-178B Trail Guides”. This article, in the form of a dialog between a software program leader and a DO-178B software consultant, describes the value-add opportunities, dangerous risks and best practices of using a DO-178B software consultant to support and facilitate software development to meet the objectives of DO-178B.

Pub Talk with a DO-178B Trail Guide Our company was hired as a software subcontractor to develop the control system for a complex aerospace actuator system. After an illuminating program planning meeting, Ron, the software program lead, invited me out for a drink. I am not a big drinker, but I recognize the value of relationship-building, so we headed out to Ron’s favorite pub. We bellied up to the bar and Ron ordered a pint. He looked awful. I knew his Business Leadership Team was beating on him pretty heavily, and this program was taking a visible toll on him. In the few days that I have been working with him, I’ve seen him go from a sharp-dressed, confident leader at 8:00 AM to a disheveled, insecure ball of stress at 8:00 PM. The daily grind was wearing him down. “You look a little stressed, Ron. What keeps you awake at night?” I asked. “Lots! There’s too much going on in this program,” Ron whined, “but at the same time, there’s not enough.” “How so?” “Well, this is a big program. We have electrical, mechanical, communication and control components, each with their own issues. I can’t get resources to save my life and every time I meet with the leadership team, they twist my priorities around six ways to Sunday.” Ron was now getting fired up. “I have no experience in some parts, like your DO-178B software, but if we don’t get them coordinated and moving forward now, the program manager is going to eat me for lunch.”

Page 1 of 8

“I can solve your problems in the DO-178B software development,” I offered. “We’ve run the DO-178B lifecycle successfully several times. We know the challenges – and the solutions.” “That’s what I’m hoping,” confided Ron. “Our business has never really succeeded in DO-178B development. We’ve had DO-178B certification as a stretch goal for several programs, but it has always been overcome by events. This time, DO-178B certification is a top-priority requirement, and I need your help to spool me up.”

DO-178B in a Nutshell I jumped right into my DO-178B elevator speech. “DO-178B is all about ensuring safety in your critical airborne system development. You achieve that by meeting the objectives of the software life cycle processes, capturing your development plans and performance requirements, and proving – with documented evidence – your success in satisfying those objectives.” “What makes it different from other software specifications?” Ron asked. “We often construe DO-178B as a specification that demands compliance. However, DO-178B is a guideline, not a specification. As a guideline, ‘compliance’ is an ambiguous characteristic. It is often said that our development process must meet the ‘objectives of DO-178B’. Stating it as a guideline instead of a specification does not necessarily relieve the developer of responsibility. Quite to the contrary, satisfaction of objectives is much less verifiable than compliance to specifications. Therefore, satisfaction of the DO-178B objectives is dependent on the subjective assessment of the FAA certification authority. In most cases, the development team works with a designated engineering representative (DER) that ascertains fulfillment of those objectives. Since fulfillment is based on the subjective interpretation of the DER, a consultant that has successfully satisfied DER interpretations can add tremendous value to the program planning and execution.”

The DO-178B trend in defense software development “This is all kind of new to our business,” Ron admitted. “More and more of our military software development projects are requiring us to meet the objectives of DO-178B.” “Over the last several years, many defense aerospace software organizations have entered the DO-178B development ring,” I commented. “As new entrants, they recognize that they lack the necessary expertise to efficiently launch a DO-178B-compliant development process.” “Why the big push to DO-178B?” “Military planes are flying in commercial airspace. It is recommended (if not required) that they meet the same safety standards as commercial aircraft. After all, they are sharing the same airspace. What would be the political implications of a flight incident

Page 2 of 8

involving a commercial and a military aircraft?” I replied. “If commercial aircraft are going to be exposed to an environment where military aircraft are also present, then the military aircraft should meet the high level of system and software safety considerations for commercial aircraft. Otherwise we are exposing the commercial passengers to added dangers.” “You know,” Ron snickered, “we used to relate military and commercial aircraft safety standards by comparing the flow of money. Passengers pay to fly commercial aircraft; military personnel get paid to fly theirs. That’s why there were always stronger safety and reliability standards in commercial aircraft. “So now we are making a transition to adapt our processes to be more aligned with the objectives of DO-178B,” continued Ron. “That’s why I brought your team on board to do the software development. I needed someone who knows the path and can teach us the way. Essentially, you’re our trail guide.” “Trail Guide Vince reporting for duty,” I remarked with a military salute. “That’s not uncommon. Component developers in the aerospace industry need to focus on their core competencies. Let the guys whose core competency is safety-critical controllers deal with the DO-178B guidelines. Lately, that has been a big discriminator for my business, and many system integrators have called on us for similar support. “Companies that have not developed applications to DO-178B might use small, low-risk projects to learn to deploy DO-178B processes. Other times, they use larger projects in order to lock-in management support. There are risks in both of these cases. Smaller projects do not have the budget for a large undertaking as a first-time deployment of DO178B practices. Large projects take on a heavier risk with any significant process change. DO-178B defines a life-cycle process, and mistakes made early in the program can haunt your throughout development. We’re fortunate that we are focusing on DO178B objectives right from the start.” “Look, I don’t need any more ghosts haunting my program!” exclaimed Ron. “We need to stay straight from Day 1.” “No matter what project is chosen as the launching program for DO-178B, the company is taking on a huge risk of the unknown. Enter the DO-178B consultant,” I stated with an exaggerated professional tone as I straightened my shirt collar and tie. “Leverage experience managing DO-178B compliant software development throughout the entire software life-cycle. We’ve fought the battles and won the wars. We know what works and what doesn’t. Our battle strategies and tactics are proven, and we know the trail to victory.”

The Value of a DO-178B Consultant (Opportunities) “I guess my trail guide analogy was about right,” Ron smiled. I agreed. “It’s right on target. The greatest value you can get from my team is to show you the best trail through the DO-178B jungle. Just like a trail guide, we’ll show you the route and give you advice on how to get past the obstacles. But remember this…” I

Page 3 of 8

paused to gain Ron’s focused attention, “… you have to walk the trail yourself. I cannot carry you.” “If you beat down the trail, I’m sure my software team can march through,” continued Ron. “I want you to facilitate the process. Show us how to develop the SDP, the PSAC, the SSPM, the SQAP, the SCMP, and all those other DO-178B documents. But my team knows the way we do business, so don’t push your standard processes on us.” “I’m with you, Ron. In fact, most of the technical content of these documents we need to develop are already active in your organization. We just have to capture the process, align it with the DO-178B objectives, and fill in any gaps. We should review your processes and help you lay them out in an SDP. Then we can do a gap analysis to compare any deficiencies between your process and the DO-178B certification level we want to achieve. I can help you fill in any holes and make your processes robust enough to satisfy the DO-178B objectives for the criticality level of the project.” Ron shook his head with a worried look. “So you’re going to bury me in process, aren’t you?” “Absolutely not!” I stated, trying to restore Ron’s confidence. “DO-178B development does not have to be a lot of process, and it does not have to be an overwhelming, nebulous monster. The intent of DO-178B is to develop safe software, not necessarily to generate documentation. We’ll use the documentation guidelines in DO-178B Section 11 to facilitate your safety review, development process and verification analysis. “From a development perspective, you have to say what you are going to do; do it as you say; and prove that you did. Verification is a little more effort because not only will we do normal range and robust requirements-based testing, but we will also do structural coverage testing of the code. We’ll use checklists and structured processes that will help us prevent things from falling through the cracks.” “So you’ll keep a watchful eye on us to make sure we implement a robust process and follow it precisely?” asked Ron. “Yep, that leads into another great value our team can provide – we can help you meet your independence objectives of DO-178B.” “I’ve heard about that,” Ron smirked. “That requires that the person who does the verification is different than the person who does the development, right?” “Pretty much so,” I confirmed. “The basic idea is to remove any single point failures in development. We need to eliminate the ‘Frankenstein Syndrome’ and get the ego involvement out of the developer’s creation. Innovators are horrible judges of their own work. Even if they create a monster, it is still hot-stuff to them. That’s why developers are the worst reviewers of their own work. They need to get independent input. My team can work with your team throughout development and we can verify each other’s work against the requirements. This will prevent misinterpretations from causing failures down the line.”

Page 4 of 8

“Well, I certainly am looking forward to your help facilitating our process and verifying our work,” welcomed Ron. “This software project is a big mountain ahead of us, and the fear of it has been keeping me awake at night.”\ “Sleep easy, Ron. You don’t have to move that mountain. We’ll help you climb over it.”

Keep the Fox out of the Henhouse (Risks) “You know, Vince, not everyone in our organization likes the idea of bringing in a consultant to support a DO-178B development.” Ron warned. “Some don’t take too kindly to consultants managing our own internal efforts. Now, I can tell that that you are hard-working and honest and are passionate about what you're doing. But our experience with consultants has been painful and expensive.” “That’s OK, Ron,” I said confidently. “While I worked with many organizations needing DO-178B software strategies, I have had to overcome many predetermined beliefs on consultants, most of which were not complimentary. You’re right that if the consulting effort is not managed appropriately, more harm than good may be done. You and I will coordinate the efforts well enough to avoid the threats.” “I see a lot of work ahead of us, and you and I will have to march arm in arm the whole way. But there are two schools of thought on consultants that we have to overcome,” Ron warned. “One says that consultants are just expensive manpower resources; another says that consultants should be able to come in and wave a magic wand to make the problems disappear.” I laughed. “You’re right; we’ll have to fix that mindset. First, unlike manpower resources, a DO-178B software consultant should possess the technical and business expertise to solve your software development problems, as well as the aerospace experience to fit the aerospace requirements into your process. You should get a DO178B strategist, not just a brain-on-a-stick contracting resource. The consultant may bring a bag of tricks, but in the DO-178B world, you have to bring the process, the product and the application expertise. Nonetheless, do not define the effort in terms of the consultant’s expertise; define it in terms of your needs and current readiness. We’re not going to just dump information and processes on you; we’re going to strategically guide you through the program aspects of DO-178B development, employ proven tactics to satisfy the objectives, and carry much of the burden along the way. “However, we are NOT going to force a set of canned processes on you,” I continued sternly. “We want you to use your processes to enable the development. We don’t want you to lose the processes that make your company unique; but we may need to adapt them to satisfy the objectives of DO-178B.” “Besides,” Ron cut in. “We have to maintain this after you are done, so we’d better use the processes our team is familiar with. For the same reason, I don’t want to reuse SDP’s SSPM’s, etc. from your legacy projects. Every one of our projects is unique; otherwise we would call it manufacturing. I’d like to use legacy documents as templates, but not boilerplates. Let’s review legacy content for applicability, and make sure we fill in any holes in a manner appropriate for our business.” Page 5 of 8

“We need to build your own process,” I agreed, “because in the end, you need to maintain development. It's your process, so if you don't know how it works, you will never be able to maintain your products.” “I’m glad you feel that way, Vince,” Ron commented. “At first, I was worried that you were going to insist on using processes and documentation from your previous programs – but not just because we are unfamiliar with them. I was more concerned that my proprietary information that I am investing heavily in would become more tools in your bag of tricks to show your next customer – which might be my competitor.” “Good consultants put a high value on professional integrity,” I affirmed. “If you don’t feel confident that they are looking our for your best interests, tell them ‘Sayonara’. Ethical consultants are worth their weight in gold. Unethical ones will cash it in.”

Secrets of Success (Best Practices) “Alright, while maintaining your professional integrity, what are the top-five best practices you recommend for using DO-178B consultants in the rest of our software development programs?” Ron asked. “As you know, it seems like all the new projects are requiring DO-178B, so we might as well build a strategy.” “Get the consultant involved early in the program – even during the proposal stage. Whether you are developing a simple light switch or a complex flight control system, DO-178B development activities can add significant scope and cost to your development and test – more so if you bring them on late in the game. If you don’t have the expertise to quantify that program impact, use someone who does. Early involvement will help you build a cost- and time-effective roadmap,” I began. “Even if your software team’s experience in DO-178B development is minimal, there are ways for them to ramp up quickly. First, some dedicated training is recommended to get everyone talking the same language and discussing DO-178B considerations at the same level. One way to get your development team spooled up is to have them perform independent reviews and audits. DO-178B requires independence (for some levels) and your team members will get their fingers in everything. Use the DO-178B software consultant to train your team on the objectives and facilitate the internal software reviews. “The third secret of success,” I continued, “is that the consultants should be part of the development team. It is easy for consultants to rattle off recommendations when they don’t have to execute them. Consultants that know they don’t have to participate in the actual performance will often demand overwhelming practices that are cost-prohibitive and quite extreme. You can have a streamlined process that meets the objectives of DO178B. Your execution team is best at finding that path. So put the DO-178B consultant on your execution team. Make it worth his while to find an efficient process that meets the DO-178B objectives. Plus, you’ll have continuity throughout the project. “Never ‘hand-off’ DO-178B content development to a consultant. A consultant would be a great facilitator of this development, but she cannot perform this effort in a vacuum.

Page 6 of 8

The SSPM and SDP are unique to the developing organization and to the development project. Many software consultants will gladly assume such a lucrative role that gives them full reign of your processes. This can be a cash-cow, evergreen business for them, especially if you become fully dependent on them. Don’t let that happen. It will result in a butchered software development process and long-term dependence on the consultant, since you’ll have minimal development of your own capabilities. Take advantage of the consultant’s expertise to develop you team’s in-house capabilities in your industry. “Finally,” I stated, “use independent technical reviews of your processes and products to minimize software problems. In DO-178B processes, downstream problems become extremely expensive simply because of all the rework they produce. In fact, the rework often produces more problems. It costs about $75 to produce a line of code, and about $2000 to fix it. Forty percent of software development time is spent debugging problems. Concurrent technical reviews catch the problems when the fix is least expensive. Your DO-178B consultants provide you a vehicle to support those independent reviews throughout the program.” “Wow, it really sounds like you got your arms around this software development process!” Ron exclaimed. “Hey, we’ve been around the block a few times,” I smiled. “That’s what makes us good consultants. Software consultants don’t develop capabilities by studying methods. They develop them by living them.”

Paying the Tab Ron seemed much more relaxed now. Maybe it was the beer, maybe it was the assurance that he had his DO-178B software problems under control. With a busy day ahead of us, we decided to call it a night. I flagged the hostess so I could pay the tab. Ron stopped me and insisted that he pay. “After all,” Ron smiled, “this will likely be the least expensive consulting effort you’ll do for me.” “Well a couple of drinks only get you so far, my friend. Tomorrow is another day on billable hours,” I ribbed. “Let’s make sure we tackle the job with a sense of urgency.” “Lead the way, Mr. Trail Guide, and let’s try to get out of there tomorrow at a reasonable hour,” Rob suggested. “How about a nice dinner at 6?” “More free consulting?” I probed. “No, you’re worth your weight in gold,” chuckled Ron. That was a pretty good compliment for a guy my size. “We just need to get away from distractions so we can focus on this plan. The investment in upfront DO-178B planning offers a pretty good ROI. I’d rather pay a little now than a lot later.” “Hope you look a lot better at the end of tomorrow than you did today,” I teased with a friendly pat on the shoulder. Ron laughed. “My looks improve as my problems get solved. What’s your excuse?”

Page 7 of 8

References: Freedman, Daniel and Weinberg, Gerald. Handbook of Walkthroughs, Inspections and Technical Reviews. Dorset House PublishingL New York. 1990. RTCA/DO-178B/ED-12B “Software Considerations in Airborne Systems and Equipment Certification”, RTCA/EUROCAE, December 1992. RTCA/DO-248B. Final Annual Report for Clarification of DO-178B "Software Considerations in Airborne Systems and Equipment Certification".

Additional Information:

Author Bio : Vince Socci, founding principal of On Target Technology Development, is a proven leader in technology planning and development, project management, product development, and technical venturing. He has developed products in various industries, including aerospace, automotive, information technologies, and manufacturing. As Chief Engineer, Mr. Socci has led successful software product development life-cycles to meet the objectives of DO-178B Level A. He has managed several major product development and production programs and has implemented business and technology strategies for many new ventures. He facilitates product development and project management courses for the State University of New York and the University of Phoenix. Mr. Socci holds an MBA in technology management, and MS and BS degrees in electrical engineering. Copyright – All materials are copyright of Vincent P. Socci Contact – Vincent P. Socci, Principal, On Target Technology Development, [email protected]; phone (607) 755-4980; fax: (607) 755-4981

Page 8 of 8