Pub Talk with a DO-178B Trail Guide

By: Vincent P. Socci, Principal, On Target Technology Development

(607) 755-4980, vsocci@ontargettechnology.com
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 DO-
178B 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 DO-
178B 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 DO-
178B 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 DO-
178B. 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,
vsocci@ontargettechnology.com; phone (607) 755-4980; fax: (607) 755-4981

Page 8 of 8