Blog

January 2, 2019

Zero Defect SW Components, V-Model, Scrum, Kanban and Agile

An overview with a bit more about them

Introduction

SW development is a long and complex process. Even in the simplest components there are bugs sometimes, but once you locate those – you have half the work done.

What is interesting: can you design and develop a zero defect versions of bigger and more complex components and systems, which e.g. include state machines and algorithms and are highly involved in the internal workflow of a system in multiple ways?

Many people might say that this is not possible; others would contradict that this might be done only with a lot preconditions fulfilled.

I want to present here first the process itself, then the ways of managing SW development and back this with few experiences from my practice.

In advance I will summarize my opinion as follows: according to my experience it is definitely possible to design Zero Defects Components, and yes – only if some preconditions are fulfilled. In addition – it is not too much harder to achieve this for bigger components, if one follows certain rules. But before we go with the examples, we shall look deeper in the development process itself, as well as the approaches for its management.

What is Development? What is a Zero Defects Component?

Development is a process that consists of multiple steps, which are:

  1. Define the idea, or purpose of the component(s) and/or system.
  2. Write an exact specification of what is required. This will be as well the base of your test specification later.
  3. Start some or extensive research on possible implementations, choose the best specific approach.
  4. Implement it. Then continue with as much iterations as necessary to achieve the required behavior.
  5. Between the iterations perform tests and add tests at each sub-functionality finish phase (both based on initial requirement specification and on the requirements deriving from the chosen design approach). Start adding parts in the internal design specification as well.
  6. At the end, when you think you are ready, finalize all tests and double check that those cover completely the requirement specification, as well as all possible cross-use-case scenarios, that derive from your main cases. Finally check whether any whole system usage may require additional tests of your component (usually these are at least the integration tests).
  7. Add Worst Case Scenario tests, brute force tests, limits tests, performance and/or speed evaluation.
  8. Fix all bugs found throughout all test phases and finalize the design documentation (usually due to bugs found small changes are required both in the design and correspondingly in specifications).
  9. A final crucial point – nowadays it is quite common to have “living” requirement specifications, i.e. changes come throughout the complete development, adaptions are necessary, many times while developing you add additional requirements deriving from the process itself. A good development process is adaptable and allows those changes. So it is expected to have some phases developed in parallel, or to go back and forth between the steps and add new requirements, developed features and tests.
  10. If you perform all the steps above and :
    • no bug goes to the customer, AND
    • all bugs are fixed before SOP (Start Of Production) THEN:

You have achieved the development of a Zero Defect Component.

The list above looks a bit like the Waterfall methodology, that’s why I’ve added the final crucial point 9. If you are unfamiliar it is possible to assume that you cannot jump between phases. In reality no one can survive in the current business environment if he doesn’t adapt and allow changes. The only exception are some specific medical, military and airplane related industries, where standards are extremely strict and the development is quite conservative (thus changes, adaptions and phases interactions happen there quite slower, and the whole process is quite heavier).

******* ******* ******* ******* ******* ******* ******

Methodologies and approaches for SW Development

Just mentioning – Waterfall is the regular old initial design approach, almost not used anymore, thus I will not present it’s weaknesses. It is sufficient to say that it is not flexible and thus it was completely replaced by the approaches listed here.

V Model

 V Model is the classical generic name for the process above when we add exactly corresponding validation steps for each development phase. It is quite known to most SW developers. The upper list of steps is actually the V-Model in practice. To go a bit further let’s see several depictions of the V-Model itself, with exact definition of each of its ladders:

  1. The GeeksforGeeks website says that V-Model is “also known as Verification and Validation model”. What is interesting is that this version refers to a whole system, and not a single SWC (SW component)

    https://www.geeksforgeeks.org/software-engineering-sdlc-v-model/

  2. —– —– —– —– —–       —– —– —– —– —–       —– —– —– —– —–

  3.  The “concepts-of-testing” website presents the same process with a bit different names. In it, compared to the previous, the “Business Case” and “Requirements” is equal to the “Requirements Analysis” phase from the the GeeksForGeeks diagram.
  4. http://concepts-of-testing.blogspot.com/2010/12/development-phases-and-types-of-testing.html

    —– —– —– —– —–       —– —– —– —– —–       —– —– —– —– —–

     

  5. https://www.softwaretestingmaterial.com/v-model-in-sdlc/
  6. —– —– —– —– —–       —– —– —– —– —–       —– —– —– —– —–

  7. http://betica.com/blog/2016/05/13/the-v-model-software-development-methodology-extends-the-waterfall-process/
  8. —– —– —– —– —–       —– —– —– —– —–       —– —– —– —– —–

  9. https://oaksys.net/oak-engagement-models/oak-pv-model/

—– —– —– —– —–       —– —– —– —– —–       —– —– —– —– —–

The last one I’ve chosen contains extended steps split between developers and validation/test engineers’ roles. By this way it explicitly points out that Verification at each step is mandatory. In practice however, this is seldom done. Reason – at the moment that you introduce in a development process 16 more verification and validation steps – the development time rises exponentially because the work process gets split into too many smaller steps. In addition – doing this in a team with 200 engineers, that are working on 40 SWCs, with several team leaders, Tech Leads, an Architect and two project managers – leads to immense complications. Many times multiple components depend on each other, most of them depend at least a bit (usually more) from the system design and architecture, many are tightly related to specific business use cases. This is the reason why some companies, which apply this model, skip part of those validation steps – I have seen it multiple times, and I know for many other companies that do it as well! It is as well many times a practice to merge verification phases, require each developer to make his own checklists, and the verification to be done a bit rarely than predicted from the conservative original diagram.

In other companies the V-model is combined with Agile principles to increase the speed of development and allow more flexibility.

Now let’s see all those steps in a comparison table for the 5 examples above:

Step Nr.: Model 1
Geeks
Model 2
Concepts
Model 3
Testing
Model 4
Betica
Model 5
Oaksys
Development
Model 5
Oaksys
Validation
1 Business Case Project Initiation Review Acceptance Criteria
2 Requirements Analysis Requirements Business Requirements Requirements Requirements Analysis SRS Review and prepare STP
3 System Specification
4 System Design System Design System Requirements
5 Architecture Design High Level Design HLD High Level Design HLD Review and prepare ITP
6 Module Design Component Design Low Level Design LLD Low Level Design LLD Review and prepare UTP
7 Coding Construct Component Coding Source Code Coding Code Review and prepare stubs/Drivers
8 Unit Testing Component Testing Unit Testing Unit Testing Unit Testing
9 Functional Testing
10 Integration Testing Interface Testing Integration Testing Build Subsystems Integration Testing
11 System Testing System Testing System Testing Component Testing Build Complete System
12 Acceptance Testing Acceptance Testing Acceptance Testing Acceptance Testing System Release System Testing
13 Release Testing

You see now how people name similar phases with different names. The most interesting situation I’ve met in my professional life, is when some manager (who believes the steps have only one correct naming), expect you to know exactly his / hers terminology, and if you want explicit explanation what do they mean by each step – they look a bit puzzled. Like e.g. you are uneducated, who actually don’t know the steps, hence they feel some frustration. And as they have been for 5 to 10 years in the same company, they strongly believe that their point of view is the only one to the V-Model.

 

The conclusion is as follows – the V simply says – define all steps, define exact testing and verification phase against each step – depending on your system, targets, requirements and needs. Customize the V. I’d add – try to do it smart by analyzing and planning in advance, this will pay off later.

******* ******* ******* ******* ******* ******* ******

Scrum

One of the good detailed descriptions of Scrum I’ve found is at https://www.scrumguides.org/scrum-guide.html#team-sm. The author there states that Scrum is Lightweight, Simple to understand, but difficult to master.

In addition this is one of the greatest short videos in YouTube on Scrum: https://www.youtube.com/watch?v=9TycLR0TqFA.

The Roles

Scrum is a management approach that defines in SW development several specific roles: A Product Owner, a Scrum Master and a Team. The product owner defines the required features, the team makes the development and the scrum master manages the further required by Scrum: meetings, targets, steps, etc. In addition the Scrum Master works on helping the team to work on the defined tasks; identifies issues on the run and works on solving them; supports the team in all possible ways. In other words usually the Scrum Master is also the / a Team Leader.

The Sprints

In Scrum the development is split to regular phases that have a length of 1 to 3 weeks. Thus it was designed mostly for common type of projects, where tasks are not regularly too long. These periods are called sprints. The purpose here, compared to the regular Waterfall model, is more flexibility by splitting the whole development in smaller pieces. The other purposes include: providing incremental releases to customer more often (sending him shippable pieces of SW that are of use to him)  – if possible at the end of each sprint; adding a lot more flexibility to the whole development as early releases mean early testing on customer side, allowing corrections both in requirements and in chosen implementation approaches, as well as the proposed solutions.

What contains one Sprint

Each Sprint has targets defined as stories, expected to be written in “human language” (and not technical specifications, that may come as a result of those stories). In the beginning of a Sprint the team makes a meeting to define the stories (i.e. goals). The stories are also prioritized. Each day there is a short meeting tracking the progress. The Scrum Master always tries to identify potential issues and blocking points at it. At the end of a Sprint we have a Review meeting where apart from the achieved results, the team is always required to identify all potential points of improvement.

Combination of V-Model and Scrum

You can see now, that the V-Model and Scrum can be applied together. Targets of Scrum summed up:

  • to force good traceability of the work done
  • to force splitting the work to smaller tasks
  • to ask the team to propose and identify all potential points of improvement
  • to assign explicitly a role for a person working on any blocker issues.

So Scrum is a way of organizing our regular tasks and work.

In comparison – the V-Model states explicitly the product development phases, and describes explicitly the testing phases corresponding to each development phase. It is also flexible as it allows periodic return of the product to previous phase when improvements are required.

The conclusion – we can use the Scrum methodology to manage our V-Model tasks (and I have seen this in practice enough times).

******* ******* ******* ******* ******* ******* ******

Kanban

One great short video on it in YouTube presented from Angelo Coppola from Axosoft in 2013 (4 minutes): https://www.youtube.com/watch?v=R8dYLbJiTUE&t=95s

Idea and basics

As explained in Wikipedia: Kanban (看板) (signboard or billboard in Japanese) is a scheduling system for lean manufacturing and just-in-time manufacturing (JIT).[2] Taiichi Ohno, an industrial engineer at Toyota, developed Kanban to improve manufacturing efficiency.

The “Just In Time” manufacturing means reducing warehouse quantities, increasing speed of delivery to end customer, optimizing the required quantities of basic production materials in our input warehouse, and by this way reach a huge increase in customer satisfaction, productivity, speed, and profits. This approach is expected as well to equalize the workload on the different parts of the system, thus removing any extra wait times between phases. Kanban helps identifying bottlenecks and weak points in your production chain. Just for your information – Kanban is related a lot to the Theory of Constraints of Eliyahu Goldratt. But it is not the same.

Kanban in SW development + exmaples

Now – one would ask: how can we import manufacturing management into SW development? It’s simple – this is actually a really efficient way to monitor the planned, ongoing, stalled, waiting and finished tasks in one big “stories board”. And considering that SW development is actually producing a product, it is quite helpful. One key point – Kanban can be applied together with Scrum as it is mostly a way of graphically depicting the tasks in the world of SW Development.

Here are few examples of Kanban based management systems for software development:

  1. http://antyradar.info/scrum-board-examples/scrum-board-examples-10-kanban-board-examples-leankit-2/
  2.  

  3. https://www.agilesparks.com/blog/kanban-service-level-expectations-and-how-to-use-them-in-scrum/
  4.  

  5. https://en.wikipedia.org/wiki/Kanban_(development)

 

One important point is that in Wikipedia Kanban is noted as well as a Lean Methodolgy.

—– —– —– —– —– —– —– —– —– —– —– —– —– —– —–

The categories I would suggest in case you have a SW that allows customization of those:

Backlog – you can put here main goals

Research – this would be features that are in planning and research

Scheduled – this would be a feature ready to start to implement

In Progress – the tasks in actual implementation

In Test – here you can put features going to test phase

Blocked – features that wait for specific external factor to be continued to work on

Paused – paused by no matter what reason

Finished – our “Hooray” list

Rejected – features that were rejected due to impossibility to realize or simply because were found as actually not necessary.

—– —– —– —– —– —– —– —– —– —– —– —– —– —– —–

Pluses of the Kanban charts:

  • you can easily identify bottlenecks
  • you identify all blocking issues
  • you can easily monitor the progress of tasks according to your classifications
  • you can later easily create burn-down charts
  • you can monitor several teams at once, or the whole project

Kanban and Scrum

Both methods are often combined. In my opinion it is because Kanban gives one of the best ways to monitor and classify all current tasks with their state and to organize the tasks monitoring.

A few tools for Kanban

Free:

  1. https://kanboard.org/
  2. https://wekan.github.io/
  3. https://restya.com/board
  4. https://taskboard.matthewross.me/

Cheap:

  1. https://taiga.io/

Payed from Atlassian (that is a quite famous company): Trello is their famous Kanban board. Jira is a system helping not only with Kanban view, but also with Scrum based management and supporting the Agile principles. Jira is also a famous one.

  1. https://www.atlassian.com/software/trello
  2. https://www.atlassian.com/software/jira

******* ******* ******* ******* ******* ******* ******

Agile

Finally we reach this widely used name, which actually stands for a specific set of values and principles. Its manifesto is only 68 words! People and companies claim to sell Agile management software, but just be aware – Agile is a set of values and principles! This means – those platforms, software products or whatever – are somebody’s implementation of the simple definitions of Agile. And of course these tools might be helpful or powerful. Or not helping at all. Here is the manifesto:

***** ***** ***** ***** *****

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

***** ***** ***** ***** *****

A really great short video (11:55 min. long) can be seen here. Watch the video, it is worth.

******* ******* ******* ******* ******* ******* ******

Agile and the others (Scrum, Kanban, V-Model) all together

So – Agile is a set of Values and Principles. It simply centers on: working resulting product; customer interaction; building a team and giving the individuals responsibilities. The core essence is to provide maximum flexibility and faster customer deliveries.

Scrum centers on splitting the work on smaller digestible pieces and forcing both frequent customer delivery and periodic internal improvements. It also cares about blocked actions, is based on tasks definitions, and imposes flexibility.

Kanban is a great system to organize the writing and monitoring of all tasks within a project and to identify bottlenecks.

V-Model is a methodology that forces heavy testing against each project or SW component development phase. That’s why it is widely adopted in Automotive companies.

One can easily conclude that we can combine these in any combination that we find useful for our project.

******* ******* ******* ******* ******* ******* ******

Iterations

Why do I put this in a separate paragraph? Because we have several reasons to consider the iterations:

  1. Scrum and Agile recommend smaller pieces of work and adaptation. In other words they impose iterations.
  2. Complex components can’t be developed at once. One has to define basic functionality, develop it, and finally test it – even when partially integrated. Then you should make the necessary fixes and then continue with adding more features. Then test again. After this continue with next set of features.
  3. Complex components in complex living projects, where the system is not yet fully developed, guarantee that you will have changes and necessary adaptations later. So – if you develop at smaller iterations – you will have the ability to add new features easier.
  4. Any expectation that once we define a function it may or should never change is ridiculous.
  5. Examples for adaptability we can find all around us – in smartphones, in Windows, Mac OS X, Linux – all of them have never considered staying at the same stage for years. All that have done this have failed – sooner or later someone creates more new and better features, and the obsolete are out of the market.

Conclusion – plan in iterations. Normally most of the main characteristics will rarely change.

Testing and Design Specifications

If the requirements and definitions are expected to change – how can we consider writing a stable testing specification? The answer is simple. At the moment that we start iterating – we develop tests mostly for what we have just achieved, and not for the whole functionality.

Regarding the design specification – I have written a detailed article on why a developer should write his own documents here.

******* ******* ******* ******* ******* ******* ******

Examples

Few BAD practices I’ve seen

  1. Antelope Audio – development of updates for a HiFi DAC. First I want to point out – the device itself was great. However – the owner, founder and main manager of the company was the main developer as well. He didn’t write documentation and have developed one really complex code, as it incorporated VHDL, C, USB drivers, Audio decoding, DAC interaction and drivers. The structure of the code was not good. In addition he changed his ideas quite often, and many times without enough communication to the team. Result – one cannot understand what is done, neither can follow the current targets. The person had weak management skills, lacked planning, the whole development was chaotic. The only one successful task I could achieve in this company was making a self-extracting installer with scripts for a python based GUI SW – cause only for it I got good task definition and was given the time to do the job.
  2. The second example is for a car cluster / instrument panel. Our team was strictly of C developers. We switched completely to C++ code and QNX. None of us had enough experience with multi-threading, nor with UNIX-, POSIX- or Linux-like systems. None of us was given training. In addition the requirements were poorly written. The managers spent too much time in efforts to devise basic system architecture, but most of us didn’t have enough experience to do this. Final addition – we had extremely bad GUI framework in alpha testing phase. This of course led to big delays in initial development planning. Later we had hundreds of bugs for the GUI. We had to fight to get the originals of the customer specifications, which were quite better and actually complete (in comparison with the limited internal requirements specifications). So the development was delayed and delayed, consequently our customer got enormous delays in getting first versions of the product. The whole team was frustrated, working was unpleasant and nervous. Finally the project was put in some relatively good rails, but the price was high. I have achieved finishing my component there only after I got the customer specifications, and I was not the only one to have this experience. No matter whether you use Agile, Kanban or Scrum – in similar situations those will not help at all to any project managed like this.
  3. The last bad example is a Road scanner project in initial phase. Company B bought the project from company A. Now all of us worked for company B – the old company, the internal company B team, and a few externals. The project leader was as well external. He neither knew the product, nor understood enough from development. How the hell do you manage something, which you don’t understand? The answer is – you do it badly.
    I and my team were responsible for refactoring and unit testing. But we were not given good descriptions of our job, e.g. what was the purpose of the refactoring. The code was relatively bad, complex, based on 6 layers of C++ templates – both native and custom ones, the higher levels included complex mathematical computations. We were not given any introduction in this. And we were supposed to write tests. The corresponding people to support us were completely overloaded. Again – there is no approach, which can help to a system that lacks definitions, clear development path, clear chain of command and correct distribution of responsibilities. I and my team worked for 6 months in the project and our job was done. Later we joined the project again, but under correct management, that goes to the good examples.

 

Examples for achieved Zero Defects Components from me

  1. Multimedia solutions, 9 years ago. I was developing a series of CMOS image sensors drivers. There was a design, a good one, and according to the architecture. So at some moment, despite all the production tests incorporated heavily in the process via the dedicated test team, my direct manager (and tutor) and I decided – we need more explicit testing of the driver itself. The reason was that the driver had enough parameters, which could be measured and tested. As we had multiple projects and thus enough potential use cases – I had the task to develop the test via the debugger IDE (it provided live tracing and console output to PC). The main development of the test cost 2 weeks. The further refinements were numerous and required weeks, iterations and usage. The result was that at the end of each new sensor driver integration we could easily check all main characteristics, and further I added detailed testing for specific features. We had 6 projects  – all successfully sent to market. All on time. In addition the test was introduced after the second project. As we had repeatability, and my sensor driver team was getting better, and we had the test (together with a detailed but short manual written by me) we reduced the time for delivering a new sensor driver from almost 3 months to 3 weeks. This was from starting from scratch until declaring zero defects and closing the project. The test allowed multiple regular problems to be easily detected. It was used as well as a trimming tool for some settings. Now that I tell the story I’m excited for its usability.
  2. The second example is for a data manager that I developed for a car door controller ECU. This was a lot harder. The data manager interacted with lowest level memory drivers, had to qualify for 15 years memory retainment, contained one really complex state machine, internal small but complex data structure, and was dynamically managing 14 blocks of different types of data. So once I finished the main design, and almost completed the documentation, I went to my manager and said – now I have to write and perform tests. So I started working on special development tests, which integrated both the application and the HW. I even had to use oscilloscope to measure timings, and a small logging code to ensure correct working of the internal state machine sequences. I found few smaller bugs and one major. Only after this I could guarantee that it was practically flawless. The testing phase continued for almost 2 months! Considering that the whole development was over 6 months – this is quite OK. In addition – the whole system development continued for year and a half. So 2 months was worth for achieving a Zero Defects Component!

Example for good Agile/Scrum managed project

  1. We go back to the road scanner device. After almost half a year I and my team got back in the project. This time there was a new manager. He had introduced Agile/Scrum approach. Which means – short sprints, clear targets, monitoring of progress, blocking issues, etc. He, together with the company B, have assigned correctly roles for sub-team managers, two architects, people to do the necessary trainings for any newcomers (including the externals like us, and developers and test engineers from 2 more companies). In the previous phase I have written good HowTos and manuals for the testing framework we had to use. So before the introductory trainings from the architects and team internals – I made training for our newcomers for the testing and refactoring. Result – increased integration in the workflow, dedicated contact people on each component (as we had over 30 components to handle), clear rules on requirements reviews, etc.

    I have to point explicitly this one – it is not the Agile or Scrum that made the progress. It was the good management. And the Agile and Scrum ideas were implemented correctly, thus helping the whole team and giving to the whole development process good structure.

******* ******* ******* ******* ******* ******* ******

Roadmap for the development of zero defects components

Now that we have been through everything I will just repeat the steps I have given in the beginning. Because Zero Defects means – zero defects before SOP and no bug delivered to the final customer. The only solution is enough testing in advance, and adaptability in testing and requirements.

  1. Define the idea, or purpose of the component(s) and/or system.
  2. Write an exact specification of what is required. This will be as well the base of your test specification later.
  3. Start some or extensive research on possible implementations, choose the best specific approach.
  4. Implement it. Then continue with as much iterations as necessary to achieve the required behavior.
  5. Between the iterations perform tests and add tests at each sub-functionality finish phase (both based on initial requirement specification and on the requirements deriving from the chosen design approach). Start adding parts in the internal design specification as well.
  6. At the end, when you think you are ready, finalize all tests and double check that those cover completely the requirement specification, as well as all possible cross-use-case scenarios, that derive from your main cases. Finally check whether any whole system usage may require additional tests of your component (usually these are at least the integration tests).
  7. Add Worst Case Scenario tests, brute force tests, limits tests, performance and/or speed evaluation.
  8. Fix all bugs found throughout all test phases and finalize the design documentation (usually due to bugs found small changes are required both in the design and correspondingly in specifications).
  9. A final crucial point – nowadays it is quite common to have “living” requirement specifications, i.e. changes come throughout the complete development, adaptions are necessary, many times while developing you add additional requirements deriving from the process itself. A good development process is adaptable and allows those changes. So it is expected to have some phases developed in parallel, or to go back and forth between the steps and add new requirements, developed features and tests.
  10. If you perform all the steps above and :
    • no bug goes to the customer AND
    • all bugs are fixed before SOP (Start Of Production) THEN:

You have achieved the development of a Zero Defect Component.

 

COPYRIGHT NOTICE:

All rights on the used pictures remain in the given source pages, thus I kept their logo when such was provided on the picture. The usage of the pictures is only for the purpose of the research and comparison, thus I have explicitly posted links to keep track to the owners.

You can use parts of this article wherever you want as long as you provide also the link http://atanasrusev.com/2019/01/02/zero-defect-sw-c…kanban-and-agile/.

Project Management

Leave a Reply

Your email address will not be published. Required fields are marked *