Marcações

TWEETS RECENTES

ENCONTRE-NOS NO FACEBOOK

Question and answer session with our systems engineering leaders

With the announcement of RELM in September, the growing importance of systems engineering has been a topic of discussion. We sat down with four of our Rational systems experts to answer some common questions about design, agile, modeling and architecture.

Meet the leaders

Dr. Keith Collyer is an expert in Requirements and Systems Engineering. He trained as an electronic engineer, later moving into software development. His interest in the “people” aspects led him into project management, quality assurance and processes, never losing sight of the need to develop systems that meet real needs. Much of his career has concentrated on helping organizations large and small to introduce requirements management. The key aspects of this are ensuring that the client understands the needs for and benefits from requirements management, clarifying and defining with the client the processes involved, including the necessary information and inter-relationships, and defining a DOORS® implementation to best support the client’s needs.

Bruce Powel Douglass is the Chief Evangelist for IBM Rational® with over 30 years specializing in the development of real-time and embedded systems and software. He is the author of the IBM Rational Harmony™ for Embedded RealTime Development (Harmony/ERT) process. He and Peter Hoffmann developed the original Harmony process that combined systems and software engineering with a well specified hand-off for a smooth, integrated workflow.Bruce developed the IBM Rational Rhapsody® DoDAF profile that currently ships with the product as well as a Safety Analysis Profile that allows engineers to include Fault Tree Analysis (FTA) diagrams, Fault Means and Effect Analysis (FMEA), and hazard analysis in their models. Follow Bruce on Twitter at @brucedouglass.

Greg Gorman leads both the strategy and development of Rational's product development platform, which is designed to address the needs of Systems Engineers and Embedded Software Developers based on industry best practices and leading products Rational DOORS, Rational Rhapsody, Rational Team Concert and Rational Quality Manager. Greg earned a Bachelor's of Science in Electrical Engineering (BSEE) from the University of Missouri and is an Association of International Product Marketing and Management (AIPMM) Certified Product Manager. Greg is the IBM ambassador to INCOSE, and currently is the INCOSE Associate Director for K-12 Youth Outreach. Greg is a father of 2 teenage boys and acts as Committee Chair and executive leader of Boy Scout Troop 301 in Mesa Arizona (and is an Eagle Scout himself). Greg is running for INCOSE president, view his platform here. Follow Greg on Twitter at @gregorygorman.

Barclay Brown is the Global Solution Executive for Systems Engineering for IBM Rational. A former chief engineer for IBM Global Business Services, he was the lead systems engineer for some of IBM’s largest development projects. He is the designer of the model‐driven system development course and co‐author of the book Model‐Driven Systems Engineering with Rational Tools. Mr. Brown holds a BS degree in electrical engineering with graduate degrees in psychology and business and continued graduate work in systems engineering. He is a certified Expert Systems Engineering Professional (ESEP) and an adjunct professor of systems engineering at the University of Central Florida. A member of INCOSE for 7 years, Mr. Brown has served as secretary and vice president of the largest INCOSE chapter, the Washington Metro Area chapter as well as the regional representative to the INCOSE member board and an assistant sector director for the Americas.

1. Is a system-level architecture really that important when developing a product?

Keith: Designing a product without having an architecture would be like designing a house without knowing what the rooms are going to be used for — which is the kitchen, which the bedrooms, which the bathrooms. You can start to draw the outside without knowing this, but it will still be subject to change. The architecture gives you the framework in which you work. Of course, before you create the architecture, you need to understand what the product is going to be used for and any constraints. These are the stakeholder requirements and domain definition. This is equivalent to knowing what sort of occupants the house will have, what the land it will be on is like, and so forth.

Greg: It is absolutely important! Without a systems-level architecture, there are many risks to the development team, such as missing or duplicated functionality. A big challenge is agreement on the architecture. It is critical that everyone understands the big picture and how all the parts play together so that the entire team can execute properly. Without a systems-level architecture, there can be no confidence that the system will perform the functions in a capable manner and no way to proceed in a cost- or performance-effective way. Finally, without a chosen architecture, each team chooses their own, which produces a suboptimal result.

2. What does "resilient architecture" mean, and why is it important in systems engineering?

Keith: A resilient architecture is one that can be adapted if there is a change. To use the house-building analogy, a framed house is more resilient than one already built with solid walls, because the internal structure can be modified relatively easily as needs change. What constitutes or allows resilience varies, depending on the application domain and the technology. But hints that an architecture might not be resilient include reliance on a new or untried technology or limited flexibility.

Barclay: One of the main benefits of architecture is to improve communication and understanding throughout the team. The team becomes a mirror of the architecture. Subteams mirror components, and good communication within the team is reflected in smooth communication among parts of the system. Resiliency comes from loose, flexible connections between components, because that reduces points of system failure. One element can change, fail, or misbehave without causing system-wide failure. Resilient architectures also mean flexibility in the application and use of the system. It becomes more adaptable to changing conditions and applications. A modular, resilient communications architecture, for example, can be adapted for use in a battle theater or an emergency response mission.

3. What benefit do systems engineers gain from modeling? Can they do their jobs effectively without it?

Bruce: All architects and designers model, but not all do it explicitly. All models are abstractions. That is, we elide details that are unimportant to the questions we want to ask or to the reasoning so we can focus on specific properties of a system. Modeling languages, properly applied, allow us to improve the precision and accuracy of the reasoning about important aspects of a system by focusing on its relevant characteristics.

Greg: No, an SE cannot be effective without modeling, but modeling comes in various forms. Systems engineers always create models, whether they are spreadsheets, diagrams in a tool, or equations in code. These models are used to understand and document various parts of the system and can be used to communicate that to others.

4. How much design is enough? When do you know that you have covered enough detail to move on?

Bruce: This is a bit of a fuzzy area. In general, when all of the reasoning at a particular level of abstraction is complete, then you can move on to the next level of abstraction. For example, when you consider the control and data transformations that a system visibly performs from an external viewpoint, you can move your viewpoint from requirements to design. When all of the design elements are characterized in terms of their input-output control and data transformations, you can move to the next level of abstraction (coding, for example).

Barclay: There are levels of design from system, to subsystem, component, module, and so on. Each level's design must be complete enough to work for the next level down, with no risk of the next level diverging from the intent and purpose of the system. If I'm designing a vehicle, I must detail the design enough that, say, the engine designers can freely design an engine that will fit my purposes for the vehicle. At the lowest level, enough design needs to be done so that the module can be built in one way to meet the intended purpose. Any critical item left open at any level can introduce a risk at the next level. This is where the concept of an integrated product team (IPT) came from. It allows designers of various levels and disciplines to collaborate.

5. Can people outside of the core development team truly contribute significantly to the design of a system?

Greg: Yes, they can. There are always insights and usage scenarios that the core team might or might not think about. Also, involving other disciplines early can significantly improve various aspects of the system's design, such as the ability to maintain it (bring in those who must service it) or manufacture it (consult those who will build it). Involve training, sales, and marketing also to ensure that what is being built can be properly communicated to the outside world.

Barclay: If they are stakeholders, they must contribute to the design, based on their interests. If they are experts in certain aspects of design, they can contribute in their areas or as reviewers. They key to getting benefit from outside contributors is to involve them early, before decisions are made that lock in designs. No one likes to change something after it has become the basis for other work. Get wide input early!

6. Should systems engineering be considered part of product lifecycle management (PLM)? Why or why not?

Keith: This is tricky, because the definitions of the two are very similar, at least at first glance. I produced this diagram a few years ago to help me to understand the distinction:

Greg: I think it's the other way around. PLM is a consideration and a domain that the systems engineer needs to be aware of and work closely with. The manufacture of the system and its corresponding lifecycle, from when it leaves the dock until it is retired and recycled, is a key area to capture lessons learned (about robustness or reliability, for instance). It's also helpful for learning the in-service use of the system to understand how well it met the original requirements.

7. Is agile development really possible in medical devices?

Bruce: Absolutely. I've written extensively about this, for example in Real-Time Agility (Addison-Wesley Professional, 2009). Agile principles, such as avoiding defects through practices of test-driven development and continuous integration, allow us to avoid defects early on and improve the quality, safety, and reliability of medical devices. However, much of the agile literature is focused on small co-located teams doing simple IT applications and doesn't directly apply to the development of high-reliability, safety-critical medical devices. The principles of agile development are sound and do apply to medical device development, but you have to look hard to find the specialized practices that apply to embedded, safety critical systems of systems.

Keith: Yes, but it needs to be controlled. One thing that is often forgotten about agile development is that, to get the best results, it must be carefully managed. This is also a characteristic of medical device development. For the most part, medical device standards specify outcomes, not processes. This means that more documentation might be needed than many agile developers are used to. The way of dealing with this is simply to consider the documents as work products in the same way as designs, code, tests, and so forth.