An OEM manufacturing and selling complex embedded systems also use a more or less elaborate R&D process to arrive at the finished design of the product. Ways-of-working refer to the both this overall process used by the organisation as a whole and to the methods and practices that teams and individual developers use within this process.
One of the most common ways to describe the overall R&D process is through a V-model or a waterfall model, with requirements elicitation, design, implementation, testing and maintenance occurring as successive activities.
A more iterative R&D process would follow a spiral model where the successive activities would be iterated, ``spiralling in'' towards the final product via a number of prototypes before delivery.
Agile processes are pushing the concept of fast iterations even further, aiming at having working software after each cycle, which typically last 2-6 weeks. There exist a number of specific agile processes, with XP and Scrum being the two most common. XP prescribes a set of practices even for the individual developers such as pair programming and continuous unit testing. Scrum focuses on the process for the team, e.g. how to prioritise and track what is being implemented.
One of the present challenges is how to scale agile from single teams to large organisations, Spotify being one example. The challenge is how to enable an entire R&D organisation to work with very short iterations when multiple teams work on the same product or systems where some customer features are realised by multiple sub-systems working together.
The most common approach to develop complex embedded systems is with an integration-centric approach, as defined by Bosch & Bosch-Sijstsema: Early in the development cycle requirements are allocated to components. The development teams implement the requirements allocated to their component. After the finalisation of the components the integration phase starts where all components are integrated to form the complete systems and system level testing takes place, where most integration problems are found and resolved.
A common way to manage a development project for MPES is to follow a stage-gate process, where the gates are driven by decisions and investment in the manufacturing of the product, i.e. driven by the hardware.
The gate progression of the development process often correspond to finalisation of software artefacts, e.g. user requirements, system requirements, software architecture, component requirements, and software implementation, i.e. a waterfall process even if the artefacts are updated as the project progresses.
No comments:
Post a Comment