We have a new project. Great! A moment later we bang our heads on the table thinking where on earth do we start. Do we rush and build a prototype? Do we start planning a whole development process for the next 18 months? Each time a new project falls into our hands we sit down, with the Project Manager (PM) if such exists, and start thinking how do we tackle this project’s obstacles and what would be our system development process in this project. There is one thing we can say for certain and that is no two projects are the same and as such we have to treat each project’s development process planning separately. For those of us who have been employed in relatively big or corporate companies or in firms that have well-established R&D processes usually there are templates already available for us to use and simply follow. I will challenge this concept a few times in this post as there is a danger in following a template without looking into the details to see how fit the template is for our needs.
A fair warning: this will be one of the longest posts in my blog since it is one of those very important and interesting subjects that cannot be divided into separate posts.
Development Process Inside the Product Life Cycle
So, in broad terms, what is a system development process?
If we take the whole product life cycle from an idea on the drawing board till the product line is completely terminated and no service or backwards support for this product is officially available, the R&D process is the only initial small fraction of this life cycle. Furthermore, if we built the product with a correct fit to the market over time, the R&D process in terms of calendar time would have to be relatively short compared to the whole life time of the product. We can see in the following chart that the Design & Development to an alpha process is only a small segment of the whole cycle:
Since we are dealing with multidisciplinary systems, the product mid-life era may run for a decade or even more in a lot of business models, and so it should be. If our development process took 30 calendar months it would be a terrible waste to be only able to actively manufacture and sell it for just as many months. Take for example the cellphone industry where there is fierce competition and where the active selling life-time of a product is only a few years.
But enough about product and back to our R&D process. There are many theoretical process models for R&D project management. I will detail here only in general terms with the ones that either I have personally been involved in or those that were used by my colleagues. Note you may see different versions of these models where the stages of the development will have different titles and maybe more stages in between. The concepts of these models stay the same in all the versions. I’ve tried to simplify the models as much as possible and still keep the whole flows with the details accurate. Additional information regarding each model can be found easily on the web.
There are generally two kinds of models; sequential models and iterative models.
Sequential models are the ones in which the development planning and implementation is done such that we know in each step of the way what the next step is and where the requirements are very much decided upon at the beginning of the process.
Iterative models are development processes in which at each stage of the process we re-evaluate what the next step is and where the requirements are decided upon only for a small portion of the project.
Sequential Models in System Development Process
V-Model
The V-Model is the classic development model. The chart below details the different steps in a V-Model where in blue we have short flow descriptions in the development and design; in yellow the output of each step and in green we have the testing phase of each corresponding output.
The V-Model is structured in a way such that for every design and requirements stage on the left side of the V shape there is a corresponding integration and testing stage on the right side of the V shape.
In this model we start on the top left by either by Research and\or Proof of Concept (POC) for a certain technology or by Product\Marketing requirements. This depends on whether our product development starts bottom-up or top-down. We then go through Requirements Analysis & Design Concepts which lead to System Requirements. From there we continue to System Design and Detailed Design which accordingly lead to System Architecture and Discipline Requirements. Once we have each discipline’s requirements we can start the implementation, which is at the bottom of the V shape. Going up on the right side of the V shape corresponds to each step on the left: Unit Assembly and Unit Testing will correspond to the Discipline Requirements, System Assembly and System Testing will correspond to the System Architecture, the Internal Testing & Error Fixing and Verification will correspond to System Requirements and finally the User Testing and Validation will respond to the Product Requirements.
V-Model is the classic development process model for huge projects
The V-Model is very popular in military\air-space industries where we start our project with a set of very structured requirements and the scale of the projects tend to be wide enough that any other model would just be a total mess. In those kinds of projects this model could be carried out to the letter. Note that because of the strict requirements for system development process and V&V proof required in the medical device industry regulation bodies many projects will be chosen to be conducted in the V-Model, as least in the top level, because inherently it includes the testing stages in a controlled manner.
In industries other than these mentioned above we would choose to use the V-Model as our system development process in projects where we have high certainty that the top-level product requirements are not going to, on the one hand, change and on the other hand, where we are passed some kind of a technological feasibility before we began development and once again not to change the system requirements during the process. Personally, for products with fierce competition, I would probably choose a different development model since they tend to change their requirements more frequently.
Pros
- Very structured system development process model
- Simple to understand and follow by all team members
- Easy to build timelines and Gantts
- Dependencies between pre-implementation and post-implementation activities are known in advance and can be planned ahead
Cons
- Very sensitive to requirements change
- The actual integrated system is operational very late in the development process
Waterfall Model
The Waterfall Model is a fully sequential development model. Each activity starts only after the previous activity in the process is fully completed. See the chart below.
The Waterfall model is the most non-flexible model and as such this model is popular in short run projects like small to medium scale experiments or dedicated features in situations where the availability of resources is scarce or on the one hand very expensive and while on the other hand there are no doubts whether the initial requirements meet the stakeholders’ needs.
Pros
- Effort waste kept to a minimum including planning
- Low sensitivity to development unknowns
Cons
- Difficult to estimate timelines
- Not suitable for long projects with high complexity
- Does not inherently include fit tests for stakeholders’ requirements
Prototyping Model
In the Prototyping Model, as the name implies, the development process goes forward from prototype to prototype. Although considered as a sequential model it is in practice “semi-iterative”. See below flow chart.
The flow is quite simple; we plan, build and evaluate prototype after prototype. We would use such a model when we want to explore each and every development cycle as fast as possible at the client’s place, either for marketing exploration reasons (when we do not know what the market needs) or because of fierce competition needs (when we are required to show how great we are before the competition does, whatever it costs).
Pros
- All stakeholders are involved in each development iteration (see cons)
- All technical potential problems are discovered very early in the system development process
- If built correctly, the most important features and capabilities are being tested very early in the process
- All the requirements are being evaluated in each prototype iteration
Cons
- All stakeholders are involved in each development iteration – yes, it is also a disadvantage, as different inputs from different stakeholders might cause deviation from the main path between prototypes
- Effort waste in building and maintaining the different prototypes
- Very complex configuration management and process management
Incremental and Evolutionary Models
The Incremental and Evolutionary Models are similar to the Prototyping Model in the sense where we build our product in prototypes. The main difference however is that here we know a-priory how many protos we are going to be building in the development process. These are also “semi-iterative” models very much like the Prototyping Model.
The Incremental and Evolutionary Models are essentially the same with one very distinctive difference; in the Incremental Model we go through user requirements and system architecture processes only once while in the Evolutionary Model we go through these stages 3 times.
Incremental Model
We would choose this model when there is an urgency to release to the market ASAP a system with limited features and where the other planned features of the system may sit on the same systematic infrastructure or basic architecture or a field-upgrade is a viable option technically and budget wise. This model is very popular in SW based features systems where the hardware infrastructure does not change and all the additional products are SW only upgrades.
Pros
- Fast release to the market of initial product
- Inherently includes the separation between urgent and less urgent tasks for the market
Cons
- Architecture ends up non optimal because of operational constraints
- The project is planned long haul and if broken in the middle most of the design and planning work has to be repeated
Evolutionary Model
The reasons to choose this model are similar to the ones of the Prototyping Model with the exception that here we know for a fact that the final product is delivered after 3 cycles, so eventually we would deploy this model when we have some technical confidence in our solution.
Pros (on top of those of Prototyping)
- Less sensitive to requirement changes than the other models
Cons (on top of those of Prototyping)
- Requires 3 different full cycles of development
Iterative Models in System Development Process
It is difficult to discuss the classic iterative models like Agile and Scrum in multidisciplinary system development process since these have evolved as SW development tools. Nevertheless, since “multidisciplinary” also includes SW and since many SW teams adopted these methods, we should at least mention them generally to understand how to interact with these processes’ concepts.
Lean
Lean is a concept created at the time in Toyota production line which was aimed for manufacturing departments and service providers. Its main goal is to reduce waste of material, resources and efforts. The structure is iterative of course:
- Define the value for the client – What is needed? When it is needed? Why it is needed?
- Map the value the stream – How do we provide the value for our client? What is required from us to reach the value?
- Create flow to manage the stream – How our workflow serves the stream best by removing bottlenecks, waiting times and obstacles from the flow.
- Establish Pull – How the customer is going to use the product per demand.
- Pursue perfection – Keep searching for ways to improve the process.
This is a very efficient way to approach sustaining R&D projects over assembly and production lines. It is difficult to apply the Lean model as is for a non-sustaining R&D process for the development itself it is however a very efficient approach to improve the R&D process itself. If we take for example the process of mechanical drawing approval and upload to a documentation system, we may find that in an R&D process the flow takes N people in the approver list and M different signature flows when it could be narrowed down the N/2 and M/3. As a pure system development process model, I admit it is not one you see often outside sustain projects.
Agile Methodology
Agile models are nowadays the hot stuff in SW development with the frameworks of Scrum (see below) and Kanban. I will give only a quick summary of the models’ pillar concepts. You may find a lot (a lot) more in-depth information on the web.
The main concept of Agile is continuous development and testing\verification. The methodology is built on iterative development cycles called sprints that include relatively small packages of work to be delivered every couple of weeks up to 8 weeks, the shorter the better, at the end of each cycle a working product is delivered (this is the main reason why Agile adoption by hardware teams is problematic. It is very difficult to get a working product in small packages of work when involved in hardware development, let alone that in hardware projects sometimes the lead time of items is measured in quarters and not even in weeks).
The Agile methodology has clear working principles which can be seen here for example.
Pros
- Very flexible model
- Can tolerate frequent changes in requirements
- Fast delivery
- Easy testing methodology
- Each cycle ends up in a working tested product
- Each iteration (sprint) timeline and tasks are easy to manage and to estimate timeline
Cons
- Close to impossible to adopt in non-SW only projects
- High level architecture suffers greatly from patches syndromes
- Effective top project management and project risk management are very challenging
- Success of the overall project purely depends on the project management competency
- Requirement management and traceability problematic
Scrum Framework
Scrum is an agile framework implementation. Essentially what it adds on to the Agile concepts is the different role assignment for the team members (Scrum master, Product owner etc.) and how in practice to manage the Agile development process in the day-to-day (sprint planning, daily scrum, backlog management and so on). For additional initial reading you may refer to the Scrum Guide.
After such a long reading, to raise a big smile on everyone’s faces I couldn’t resist linking to an unforgettable scene from the epic TV series Silicon Valley S01E05 scrum scene.
The Practice – Mixed Models
As I stated before, I will again emphasize – each project requires its own system development process. Of course, if the SW team you are working with daily are already well into Scrum-Agile you’d probably wouldn’t want to change it, but if the SW packages go hand-in-hand with hardware availability then with all due respect to the SW team habits it will have to be managed differently otherwise the project is bound to have delays.
In practice in very big projects, we choose to have our development process in mixed model. Just as an example of how an open-minded project management made the best of a very complex situation, I will give an example of a beautiful development process that I was part of. Officially it was planned as a top-level V-Model:
- The research phase was purely a Prototyping Model; however, we kept this model in parallel for early customer engagement during the design and integration phases
- The hardware was managed in an Incremental Model
- The SW infrastructure and hardware support followed the Incremental Model
- All the soft features, soft defect management and integration phase SW deliveries were employed in Agile by the SW and System Engineering team
- The integration, testing and requirement management was following a strict V-Model
I wish there was a way to draw a sketch of this project’s system development process without exposing exactly what the project was…
To summarize, in this detailed post I have given examples for different development process models and when to use them, however I think the most important point I would have liked to convey would be to open your minds when planning your project’s development process, know your team’s needs, know your project’s needs and make sure your development process is serving your team and not your team is service the process.