Business and technical hardware-software workflows must be combined and shared to be successful, notes Jama Software, Dassault Systemes and ARM.
By John Blyler, Editorial Director
It’s no secret that hardware and software groups must work together, especially when creating complex systems in an ever shrinking time-to-market window. The challenges have always been that each domain uses different development methodologies and tools. How to you put together a combined hardware-software workflow that ensures traceable requirements and intellectual property reuse while allowing project managers to reprioritize assignments as needed? This questioned is addressed by several product delivery experts including, Michael Munsey, Director Product Management and Strategy at Dassault Systemes; Eric Nguyen, Director of Business Intelligence at Jama Software; and Jonathan Austin, Senior Software Engineer at ARM. What follows is a portion of their responses. — JB
Blyler: How do you deal with the differing workflows between hardware and software teams?
Munsey @ Dassault: To successfully manage all resources, a company must understand its business goals, organizational structure and below- and above-the-line product workflows. The “ line” denotes the focus of the activity, i.e., below-the-line is work in progress. Above-the-line is work on applications at the enterprise level. Most SoC design companies have done a good job below-the-line, i.e., technical design work. In the past, this workflow was captured in file-based structures. Today, most companies use some form of design data-management system that includes IP repositories and libraries. These have, in turn, provided the start of an IP-management infrastructure.
Nguyen @ Jama Software: Synchronization is critical in maintaining combined hardware and software workflows. For example, in Agile, the developers work with user stories. One of the challenges is sending these stories downstream while looking at the upstream epics and themes. Integration allows you to synchronize the downstream system while maintaining all the upstream relationships and interdependencies. In simpler terms, it gives the development staff both the detailed tasks that they need but also the ability to see the broader context. This synchronization is bi-directional, i.e., as the developers complete the work, their status moves back upstream.
Many software developer project managers (PM) use dashboards to see the current work status. The dashboards show the high-level themes and features that are going into a particular product release, all traceable down to detailed work assignments. The PMs are focused on ensuring that all the work is correctly prioritized to meet the product launch. They must be sure that the developers are working on the right tasks. Additionally, the PMs must be able to reprioritize and perform trade-off analysis in order to see the impact that changing priorities will have on downstream work.
Austin @ ARM: One thing that the hardware folks (I’m a ‘software guy’) really felt they could bring from the software into the hardware world was well-designed continuous integration. Something that provides good reports on a regular basis about breakage of the build, etc.
(For workflows in general) it can really help to have clear engineering specs before starting work. For example, we have a few very defined stages our hardware design processes go through (Initial Investigation, Detailed Design, etc) and recognizing the need to firmly transition through these stages, rather than just drift towards completeness is important.
Blyler: Thank you.