AFuzion Archives

Tag Archive for: AFuzion

In this blog, we recap the “Managing Mission Critical Requirements in an Agile Environment” webinar.

Over the last two decades, Agile has been demonstrated to be a powerful approach to software and systems development. It has taken on a number of representations but there are features that most representations share – namely “flexibility” when dealing with requirements.

The common theme is for the user community (or the representative of the user community) to state in very broad terms what user functionality would be beneficial and then leave the details (and often the priorities) to the software “whiz”.

This is seen by many as antithetical to mission or safety-critical systems. Systems where the operational characteristics must be well understood to prevent loss of life or mission failure when the product performs differently than expected. In a similar manner, the system must be reliable since it is essential for mission success or human safety.

In this webinar, attendees will learn more about how:

Agile can deliver cost and schedule benefits when developing mission or safety-critical software
Exploiting Agile requires adapting approaches often assumed for Agile – especially when it comes to requirements management
When appropriately applied, Agile can give you a product that is more reliable/dependable than classical methods

Below is an abbreviated transcript and a recording of our webinar.

Managing Mission Critical Requirements in an Agile Environment

Cary Bryczek: Welcome to our virtual user group’s keynote. Today, I’m joined by Mr. Kenneth Hebert, he’s the Chief Technical Director at AFuzion, Inc. Mr. Kenneth Hebert is a 40-year veteran of safety-critical software engineering, including over 35 years as a system safety software project and process leader manager with a Ph.D., MS, BS in Computer Science, extensive experience in the safety systems and architectural design of real-time safety-critical defense and other military and private sector applications, also a registered Agile Scrum master and CMMI software process expert. He has extensive experience in systems software development methodologies ranging from Waterfall to Agile and experience with developing and deploying processes that integrate concepts embodied in DOD, NASA, ISO, AS, and FAA standards, as well as development frameworks, such as CMMI and Lean Six Sigma. He is Lean Six Sigma certified, a certified Scrum Master, and SCAMPI lead appraiser trained. I am delighted for Mr. Hebert to come and deliver our keynote. Welcome and thank you, Kenneth. Please take it away.

Related: Jama Connect® Solution for IBM® DOORS®

Kenneth Hebert: Good morning. It’s certainly a pleasure to be here. What we’re going to talk about this morning is a little bit about Agile and requirements, and hopefully, we have a few thoughts that you can take with you and use as you go forward as a part of this conference. So this is the agenda I’d like to cover. We’d like to talk a little bit about what Agile is for those of you that might not have been familiar with that term or that approach to development a little bit about whether or not it’s different and in what ways is different. And then bringing that back into the fold of requirements and requirements management and how things fit together in that realm.

So again, hopefully, these thoughts will give you a few things to chew on and you can go forward and use them as a part of this conference and everything. So in any event, what is Agile? Well, Agile means a lot of things to a lot of different people. Actually, Agile was coined back in the early 2000s. It began with something called the Agile Manifesto and basically it was a document put together by a series of thought leaders in the software community. And at a time when, if you think about what was going on in the early 2000, and late ’90s, we had a number of standards coming out that were driving to what they perceived to be a heavyweight process.

Related: Better Product Development: Five Tips to Achieve Live Traceability™

Kenneth Hebert: Standards that called for delineation of what had to be done, exactly how it was going to be done. The CMMI was being introduced. Mill standard 498 had been installed and was being used 12207 was being worked on. NASA was putting together its standards for how it expected software to be done in development with respect to space systems. So all of them had seen several common themes, and those were those involved in essentially heavily evaluating and systematically approaching the software development process and as a part of that requirement, requirements management.

So this was in some ways a revolt or at least looking at where the pendulum was, and a claim by these leaders that let’s not lose sight of what we’re doing. Let’s realize that our objective here is to solve a problem and let’s get back to what’s really important. So what you’ve seen over the last two decades, is that Agile has become a significant influence in the development community, the software, and systems development communities. What you’ve seen is it’s been applied in a number of different contexts. It actually can be, because it really isn’t a development methodology as much as it is a set of guiding principles. And so we want to talk a little bit about what those were so that we can kind of have a common discussion as we look at what those areas, those principles, what you’ll see are some common themes in all these areas.

And that is it’s built around the notion that you have that a team is used to build a product. That team has a shared purpose. It’s typically a multidisciplinary team. It has all the skills and knowledge needed to get the job done successfully. It’s a cooperating group. They work together in order to achieve the objective and they blend their skills. They don’t operate as a group of individuals. They operate as a team. Much like if you think of a football team where everyone is operating together in order to achieve a touchdown and to advance the ball down the field. No individual may be the perfect running back or the perfect lineman or the perfect quarterback, but as a group, they overcome each other’s deficiencies in order to achieve a common goal. And that’s really what you want to see in an Agile environment.

To watch the full webinar, visit: Managing Mission Critical Requirements in an Agile Environment

Tailor Plans and Templates in Jama Connect®: The Value of Having Process and Tools in a Single Place

There are dozens of regulations, best practice frameworks, and corporate governance standards that all describe the value of documenting the processes used to design and develop systems upfront before development begins and suggest that evidence be collected to demonstrate that the documented processes were followed. The end goal is to effectuate process improvement and develop behaviors that decrease risks in service, product, and software development. To the engineers in the trenches doing the work, it can be daunting to keep up with following the right process, especially in aviation. Observations I have after working in the industry for over 25 years is that:

Engineers have difficulty translating what is in the process document to how to perform their work every day.
Engineers do not have the time to go searching for the latest process documents.
Engineers are not certain the content in process documents are enough or correct to satisfy critical audits.
Engineers wish that the process of documentation and evidence demonstration was captured automatically in the tools they use day to day.
Engineering managers wish that more time could be given for training in state-of-the art engineering techniques rather than process training.

Related: ARP4761A Introduction for Engineers and Managers

EASA and the FAA point towards industry standards which all call for a plethora of documentation that needs to be created to support the objectives. DO-178C (Airborne software), DO-254 (Airborne firmware/hardware), and ARP4754A (Aircraft/Systems) also require reviews, audits, and proof thereof. Some of the best “proof” is detailed and complete checklists covering the primary lifecycle activities and their generated artifacts.

Jama Connect® can provide engineers with a single place to author and read documentation without having to leave the requirements tool in which they are working and look in a file share. The process guidance need not be static but should also assist engineers to follow the process while performing their work. The Jama Connect workflow engine and process documentation can be tailored together to take advantage of streamlining the work that engineers do and assist in the automation of evidence collection and reporting.

The built-in Review Center in Jama Connect can also assist with review of process documentation in each stage of involvement (SOI) in addition to review of requirements, verifications, and risks. By taking an iterative and collaborative approach to reviewing lifecycle data in real-time, Review Center improves stakeholder alignment, reduces lengthy review cycles, and eases the path to compliance. Traditional review processes often stifle collaboration resulting in misalignment, long review cycles, versioning issues, and an abundance of unnecessary meetings. Having a centralized place to manage and collaborate on reviews eases keeping track of the findings and observations, making reviews more efficient and scalable.

Related: Afuzion Plans and Checklists for DO-178C, DO-254, and ARP4754A

AFuzion’s Aviation Compliance Templates and Checklists are now integrated within Jama Connect™. This proprietary content is used by 17,000 engineers worldwide in 25 countries for most certification agencies including FAA, EASA, NASA, ESA, TC, CAAC, CASA, DASA, STM, INTA, RNZAF, MOD, US ARMY, US Air Force and many more. AFuzion has spent 200 person-years of expert aviation engineering time to develop these full templates; this means you begin effective aviation development/certification work immediately instead of expending 10-16 person months developing inferior plans/standards/checklists on your own.

Using DO-178C and DO-254 templates for Plans, Standards, and Checklists ensures that you have an appropriate framework for successfully developing and certifying your system. These templates and checklists can also help in getting organizations to the goal of higher SEI CMM/CMMI ratings (preferably Level 3 – 4+). Usage of AFuzion’s process templates and checklists are intended to maximize the probability of project success and quality by:

• Reducing costs by using pre-built material from the most well-known industry experts instead of spending 2-3 person years typically necessary to develop these internally
• Eliminating tools silos by keeping your Process documents in line with your requirements data
• Enabling better communication of process requirements to your engineering teams

Safety does not rely upon magic numbers but rather real answers. Likewise, safety is never an accident, but true safety should prevent accidents. The numbers “4754” and “4761” are not magic but are associated with safety. Safety and the numbers have evolved – the new answers for safety are found in 4754A and 4761A; specifically, SAE’s ARP4754A and ARP4761A.

ARP4761A Guidelines

ARP4761A is rather more than a guideline for aircraft safety. ARP4761A (formally issued in 2018) is officially titled “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment.”

In fact, ARP4761 is almost a tutorial on generalized safety and how to apply various theoretical analysis to assess ongoing development activities toward aircraft safety. Clearly, ARP4761A is tightly coupled with ARP4754A and lays the foundation for the most fundamental aspect of aircraft regulations: safety. Clearly, viewing the avionics development ecosystem, ARP4761A’s prominent place in the upper left conveys its importance:

The Safety Assessment Process

The safety assessment process is a vital aspect of aviation safety, and for avionics, ARP4761 provides the foundation.

Literally every aspect of aviation undergoes safety assessment to better understand potential risks, quantify them, and then prevent, detect, or mitigate them. Experienced aviation persons are truthful when stating the safety assessment process is perhaps the most important element of avionics development.

For avionics, the role of the safety assessment is to ensure the safety of the aircraft, its crew, and the occupants. Essentially, aircraft safety is optimized by performing careful analysis, architectural optimization, criticality level determination, component selection, architectural improvement, monitoring, and maintenance. Therefore, only by having a thorough safety assessment process can we ensure we have an architecture with additional safety-related requirements which address safety aspects.

The title of ARP4761 accurately justifies its importance within this fundamental process: “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems & Equipment.”

To learn more about this important airborne systems safety standard, please download our full whitepaper here.