Systems relying on embedded software typically demand high reliability. Consider the common embedded software domains of avionics, automotive, and medical devices, where mistakes can cost lives.
As a result, embedded software development processes must provide the checks and balances necessary to ensure high reliability software that satisfies regulatory requirements, such as RTCA DO-178B or FDA 21 CFR part 820. But, development processes cannot hinder innovation, or a company will lose its competitive edge.
How does one balance the need for rigorous process and the need for unbridled creativity? The Eclipse Process Framework (EPF) delivers a process framework that supports such a compromise.
What is EPF?
EPF is an open source project within the Eclipse Foundation that aims to provide an extensible framework, which includes exemplary processes and a tool for process engineering.
“EPF provides an efficient mechanism to communicate processes within the organization and with external stakeholders.”
The tool, EPF Composer, provides an environment for defining, tailoring, managing, and communicating development processes. Process authors can define who does what, when, and how. They can provide guidance, templates, and other supporting material and publish the information as a website on a corporate intranet.
By separating the method content, which defines the roles, work products, tasks, and associated guidance from the process, which defines the phases, iterations, activities, and tasks in the context of a work breakdown structure, one can reuse content across projects, phases, and iterations, tailoring the life cycle to meet the specific needs of the project team. This approach effectively supports top-down process definition (phases, iterations, and activities), bottom-up process definition (roles, work products, and tasks), or a combination of the two. Figure 1 shows the EPF Composer user interface (authoring perspective) that process authors would use in developing process descriptions.
The tailored configuration can then be published to HTML for dissemination and exported to Microsoft Project to create a project plan. Planned integrations with configuration and change management tools will enable a controlled, auditable evolution of the process content itself. The rest of the development team does not need to know the details of how the process was created; they can simply view the end product. Figure 2 shows a sample page from the published website that development team members would use to obtain guidance in applying the process.
The exemplary processes, OpenUP (based upon the Unified Process) and Agile component (based upon Agile methods), are designed to be minimal, complete, and additive. They are minimal in the sense that only fundamental content is included; complete in that they can be manifested as an entire process for the development of software on any platform for any domain; and additive in that they can be used as the foundation on which process extensions can be easily added to meet the needs of a specific situation.
Needs of embedded software development
EPF is as applicable to a small software development team working on an embedded device as it is for a large aerospace and defense contractor building a system of systems.
All teams need to define roles, responsibilities, work products, and work flows to function cohesively as a team. All teams need to capture corporate knowledge and train new hires. The only difference is the scale of the project (size of team, scope of work) and level of detail (descriptive versus prescriptive) that must be captured and communicated.
Smaller teams generally require, and want, less process overhead since communications and coordination are easier in a small team environment, and they simply do not have the resources for any additional overhead.
However, the larger the team and the higher the cost of failure, the more important it is to have a well-defined process with suitable checks and balances to ensure the efficient and effective development of high-quality products that meet stakeholder and regulatory requirements.
The ability of the framework to accommodate both extremes, using a standard tool and language, enables the process engineer to dial in the appropriate amount of control while balancing the need to remain agile and creative. For example, mechanisms called variability within EPF Composer permit one to select existing content for reuse, tailor existing content, replace existing content with new content, or remove existing method content from a configuration in order to strike the balance required for any particular situation.
Benefits of EPF
The availability of an open source framework for process engineering and implementation provides a number of significant benefits to organizations. The following discussion provides a limited sample of some of these benefits.
Capture and communicate corporate knowledge
Organizations cannot depend upon the knowledge and heroics of individuals for their success. The ability to quickly and easily capture and communicate corporate knowledge reduces the risk of losing key personnel and provides an effective means of training new team members.
Integrate best practices from multiple sources
By providing a common framework, it is easier to integrate best practices from multiple sources. As the EPF ecosystem evolves, we expect to see many out-of-the-box process variants that address different domains. Potential sources of these out-of-the-box processes include:
An Eclipse open source community that will evolve and improve upon the exemplary processes
Tool vendors that wish to provide process support for their tools
Academia and research organizations interested in bringing state-of-the-art processes into the mainstream
Standards bodies looking for efficient process delivery mechanisms (ISO 15288, 12207, and others)
Partners, suppliers, and customers with whom we must collaborate
EPF provides an efficient mechanism to communicate processes within the organization and with external stakeholders. Many contracts require a description of internal processes as part of any bid. Standards and regulatory bodies, such as ISO, RTCA, and FDA, require documentation of the process for certification (such as the ISO 9000 series). Noncompliance can have drastic consequences. Similar requirements for documenting the development process are applicable in the IT domain as well, Sarbanes-Oxley regulations, for example.
Connect the dots: People, process, and technology
Organizations depend upon three key resources for success: People, process, and technology. Process definition should precede process automation since investments in technology and tools are wasted if people do not know when and how to use them. The EPF ability to integrate tool guidance and extended help simplifies the integration of these three resources.
Process improvement initiatives such as CMMI are simplified. The current process can be documented, baselined, and analyzed to identify gaps and areas for improvement. Subsequent process improvement initiatives are simplified via configuration and change management of the process artifacts.
As mentioned earlier, organizations are often required to state what they do and do what they state in order to satisfy regulatory or certification requirements. The EPF provides the ability to capture, communicate, and evolve this information as a model. Compared to the traditional paper-based process descriptions that typically become obsolete and get ignored, information in the EPF is easily referenced and updated.
Improving development processes
The EPF project represents a collaboration of industry and academic thought leaders dedicated to providing an open source framework that supports process engineering and implementation.
The framework provides a standard language and tool for developing processes of any kind, be they lightweight software development processes for small teams working on internal IT projects, detailed prescriptive processes for large distributed teams working on a global C4ISR system of systems, or organizations wishing to optimize business processes.
In addition to the exemplary processes that will form part of the initial and subsequent EPF releases, a number of other domain-specific processes likely will become available from various sources outside of the Eclipse Foundation, creating even more value for those looking to improve their development process.
Visit the EPF website at www.eclipse.org/epf to learn more and get involved.
A final thought: Although the Eclipse platform is the technology behind the EPF, the EPF is not limited to developing processes for Eclipse-based software development. The EPF is applicable to any process, including business processes, technical support processes, as well as systems and software development processes.
Chris Sibbald, PhD, is the senior systems engineer with Telelogic. He has more than 10 years of systems engineering experience, including a former position as payload systems engineer for the Canadian Space Agency’s RADARSAT spacecraft. Chris was also president of Objective SST, an engineering consultancy in Ottawa that provides software and systems development process mentoring and consulting. Chris holds a PhD in Electrical Engineering from the University of Ottawa, and can be reached at chris.sibbald@telelogic.com.
Kurt Sand is a senior manager at Telelogic, where he defines, develops, and promotes software development and governance and compliance solutions for Global 1000 companies. Kurt has more than 15 years of experience in the IT industry as a software developer, project manager, and business unit manager. Kurt holds BS and MS degrees in Computer Engineering from Lehigh University and Syracuse University, respectively, and has conducted postgraduate studies in Engineering Management at George Washington University. He can be reached at kurt.sand@telelogic.com.
