Development Process

The need and demands for development processes have increased with the complexity of the embedded systems. Functional requirements of systems comprised by software have increased extensively, due to the advancement of various technologies used in devices. This trend has led the development of embedded software to also expand in scale in order to meet the ever-growing functional needs.

In earlier days, the developers of embedded software did not have to be that conscious about development process to build the software required to be embedded in the final product, since their scope of development was relatively limited. Due to the recent expansion in scale of software development, numerous problems attributable to embedded software or embedded systems have come to surface. As a result, more and more attention is given to improve the development process to address these emerging problems.

The demand for development processes often depend on the specific use case for the given device. As an obvious example is development of devices for medical, defence, space, automotive and safety related deployment. In general safety requirements are often imposed when casualties (human, nature or economic) are present in case of functional failure. For many industries specific standards are present while general functional safety in general terms is covered by the international standard IEC61508.

Other references of international standards for software engineering is (ISO/IEC12207 Software life cycle processes), (ISO/IEC15288 Processes and life cycle stages) and (ISO 9000 Quality management systems).

Over the years, several approaches for product development have been developed. Below, some of the often used development models/processes are briefly described.

Waterfall development model

The waterfall model defines the traditional standard development phases, where developers follow these phases in order.

1. Requirements specification (Requirements analysis)
2. Software design
3. Implementation and Integration
4. Testing and Validation
5. Deployment and Installation
6. Maintenance

One phase is finished before the next is started, and as such the workflow is in accordance with the V-Model.

Spiral development model

The spiral model, also known as the spiral lifecycle model, is a Systems Development LifeCycle (SDLC) model used in information technology. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favoured for large, expensive, and complicated projects.

In the Spiral model, software development takes place in series of developed releases. In initial stage iterations, the release or model might be a paper model or a prototype. In the later stages a more complete version of software is actually produced.

Agile development

Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to refine and deliver a software system. Different methods is used, here some often used agile methods are listed:

Extreme Programming (XP)

The phases are carried out in extremely small steps. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than months or years of each complete step as in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by programmers working in pairs, a technique known as "pair programming"), which is complete when all tests passes, and the programmers can't think of any more tests that are needed. Design and architecture emerge from refactoring after coding. The same people who do the coding do design. The incomplete but functional system is deployed or demonstrated for (a subset of) the users. At this point, the practitioners start again on writing tests for the next most important part of the system.

Dynamic System development method (DSDM)

This method is an agile project delivery framework, primarily used as a software development method. There are 9 principles which are essential to any DSDM implementation:

1. Active user involvement – Imperative.
2. Teams must be empowered to make decisions.
3. Focus on frequent delivery.
4. Criterion for accepted deliverable (Fitness for Business).
5. Iterative and incremental development – Mandatory.
6. All changes during development must be reversible.
7. Requirements are base lined at high level.
8. Testing is integrated throughout the life cycle.
9. Collaborative and co-operative approach.

Scrum

Scrum is a way for teams to work together to develop a product. Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed. Scrum is a simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.

The fundamental process is simple and its core is governed by 3 primary roles:

1. Product Owners determine what needs to be built in the next 30 days or less.
2. Development Teams build what is needed in 30 days (or less), and then demonstrate what they have built. Based on this demonstration, the Product Owner determines what to build next.
3. Scrum Masters ensure this process happens as smoothly as possible, and continually help improve the process, the team and the product being created.

Model-driven software development (MDSD)

It is a style of software development that considers itself as an alternative to the traditional style of programming. The approach centres itself on building models of a software system. These models are typically made manifest through diagrammatic design notations - the UML is one option. The idea is to use these diagrams, to specify the system to a modeling tool and then you generate code in a conventional programming language.

For MDSD the model is definitely more abstract than the code generated from it. Thus it is generally impossible to keep the model consistent automatically after a manual change of the generated code. For this reason, manual changes to generated code should be avoided. A precise definition that states which parts are generated and which are implemented manually is necessary if a mixed approach is chosen.