About quality for software

Many definitions of the quality exist. The software industry is an industry. The definition of the industrial quality is:

A quality product corresponds to the requirement press out by the customer. It isn’t the best product, it’s the product asked by the customer and the users.

The essential idea is the quality is not Excellency. A requirement of the customer can be the life term of the product.

When we make software, we have two main methods: the V Cycle and the Agile Methods.

A project which is realized with the V Cycle method use 6 ordered steps to complete the project:

· The needs analyze

· The specifications

· The realization

· The tests

· The delivery

The quality is controlled at the end of the process and concerns the entire project. Often with the delay on the project, few tests are done. These tests concern the needs describe in the beginning of the project. For the projects which need more than 3 months of work, they consider a need which is partially changed. The project quality depends on the perfect success of all the step.

For the Agile Methods, the situation is different. One of principles is to adapt the software to the consumer need during the project. Consequently, the requirements in the beginning of the project can be different of those for the delivery. In this way, the project can’t be a quality project.

The practice of the actual quality is to manage and to complete the definition of the quality with the change of the need during the project. A manufacturer built a production line for a car, use it, and adapt it during about 10 years. During this time, the norm, the law and the public taste change. It is therefore necessary to adapt original requirements to these new requirements. Yet, the cars verify the constraint of the industrial quality. In the industry, the quality is organized in step and must be verified for each component and their assembly and for the final assembly.

This approach allows seeing that the Agile Methods verify the industrial quality much better than the V Cycle. One of the foundations is the Test Driven Development. Each software element is tested and the tests are executed for each change. The tests concern the objects, the stories, the features and the software performance. In other hand, at the end of each sprint, the delivery is a quality software even if it is a partial software. For the Agile Methods, the idea of beta tester doesn’t exist. An informed user or a super user replaces it. This user is a person who knows well the job and also preferably the IT. He can use the partial delivery and can give judicious advice about the change to do. His function isn’t to discover the bugs of the software but to show the improvement which is going to allow realizing the product the most adapted to the needs of the customer and the users.

De la qualité logicielle.

Il existe de nombreuse définition de la qualité. L’édition logicielle est une industrie. La définition de la qualité industrielle est la suivante :

Un produit de qualité correspond aux exigences exprimées du client. Ce n’est pas le meilleur produit, c’est le produit demandé par le client.

Il est important de comprendre que la qualité n’est pas l’excellence. Une exigence du client peut être la durée de vie du produit.

Pour la réalisation des logicielles, nous disposons de deux méthodes de travail principalement ; le cycle en V et les méthodes agiles.

Le principe du cycle en V est de réaliser en logiciel en 6 étapes successives qui traitent la totalité du projet :

• L’analyse des besoins.
• Les spécifications.
• La conception.
• La réalisation.
• Les tests.
• La livraison.

La vérification de la qualité du logiciel a lieu à la fin du processus et concerne la totalité du projet. Ces tests sont souvent réduits suite au retard pris par le projet. Ils correspondent aussi à l’expression des besoins du début du projet. Pour tous projets de plus de trois mois, ils traitent d’un besoin qui a au moins partiellement changé. La qualité d’un logiciel dépend de la parfaite réussite de toutes les étapes du projet.

Pour les méthodes agiles, La situation est différente. L’un des principes est d’adapter le logiciel au besoin du client pendant toute la durée du projet. En conséquence, les exigences définies au début du projet ne correspondent pas forcément aux exigences de la livraison. Ce qui a priori interdit au projet d’être un logiciel de qualité.

La pratique de la qualité actuelle a mené à compléter la définition de la qualité pour tenir compte des changements des besoins au cours du temps. Un constructeur construit une chaîne de fabrication pour une voiture, l’utilise et l’adapte pendant environ 10 ans. Durant cette période, les normes et le goût du public évoluent. Il faut donc adapter les exigences originales à ces nouvelles contraintes. Pourtant, les voitures vérifient les contraintes de la qualité industrielle. Dans l’industrie, la qualité est organisée par couche et doit être vérifiée pour chacun des composants et de leur montage du moteur au montage final.

L’application de cette approche permet de considérer que les méthodes agiles vérifient bien plus la qualité industrielle que le cycle en V. L’un des fondements est le développement dirigé par les tests. Chaque élément du logiciel est testé et les tests sont exécutés à chaque modification. Les tests concernent les objets, les fonctions du logiciel et les performances du logiciel. D’autre part, les étapes de la réalisation livrent un logiciel de qualité même s’il est incomplet. Pour les méthodes agiles, le concept de beta testeur n’existe pas. Il est remplacé par celui d’utilisateur averti ou de super-utilisateur. Cet utilisateur est une personne qui connaît bien le métier et aussi de préférence l’informatique, il est capable d’utiliser les livraisons partielles et de donner un avis pertinent sur les adaptations à faire. Il n’a pas pour fonction de découvrir les anomalies du logiciel mais de montrer les améliorations qui permettront de réaliser le produit le plus adapté aux besoins du client et des utilisateurs.

Agility and quality

What’s Quality? This word has many meaning. For my purpose, quality is the industrial quality. In this way, the definition is “A quality product is delivery like is design by us selves or with the customer”. A producer who satisfies quality requirements doesn’t produce the best product.

When I work on a project with the Methods Agile, I realize a quality project. When I explain this idea in an interview in a company specialize in Agility, the director answer me that agility can’t offer quality.

If you consider the agile project as a whole, the project isn’t a quality project. Because you can modify the list of functionality when the customer needs to exchange a functionality less important by another more important at this time.

But if you watch the project with all this functionality, each functionality is realize with quality. And when you deliver all the functionality, you deliver the software. And the quality of the software depends only on the quality of each functionality.

Each sprint contains full functionalities and can be delivered. For quality, a sprint is an industrial batch which verifies the constraints of quality.

The quality is more important than in the Predictive Methods because the customer receives exactly what he needs. If he needs some functionality less important which the customer decides to abandon, the supplier can realize them in a second time.

For a customer, the most important thing is that the end user has the best productivity. The end user needs simple, complete and useful functionality. The view of the user is different of the view of programmer or analyst. He can’t see the complexity or simplicity of a function like the programmer and he see the software like a list of functionality not like a system.

The Agiles Metthods and the Uncertainly Principle

I discovered Agile Methods while working for Docubase which put them in place at the end of 2007. I found them to be a realistic approach to IT project

I didn’t take formal computer training but learned to program through maintaining an application in C that I didn’t ever understand completely. I also used the “Kernigan and Ritchie” book.

Later I took training about Object Programming. During this course, I understood why Procedural Programming hasn’t been a solution for the long-term software creation and how but it is preferable to use Procedural Programming for smallest disposable programs.

After this course, I realized software which was conceived by project managers. I progressed to conceiving some programs by following the managers’ examples and studying from books.

Then, I took a traditional course about computer analysis. In 2004, the course only proposed the Predictive Methods Which leave an unsolved problem: how to manage the fluctuating needs of customers.

The discovery of Agile Methods allowed me to understand that this problem is inherent not to the customers themselves but to the Predictive Methods.

The Predictive Methods assert that all computer projects can be analyzed globally. A project comes to fruition in five steps.

· The needs analysis

· The writing of specifications

· The realization of project

· The tests

· The delivery

It’s called Predictive because it states that we may predict the entire usage situation for a computer project.

The agile methods suggest a totally different approach. They offer to construct a project in short steps which, apart from the last step, are finished by partial delivery.

The strength of these methods is to involve the customer and the user from the beginning of the project. They quickly have a usable partial product. Special users can quickly test the software and inform the team about any changes in order to obtain the project approval.

Since I known the Agile Methods, I have found them to be natural as much as pragmatic.

Later, while I read the magazine “La recherche”, an article about quantum physics allowed me to understand why Agile Methods is preferable. It spoke in particularly about the Uncertainty Principle.

One the expressions of this principle is:

The state of a system depends on the observer. The main representation of this is the Schrödinger’s Cat experiment. See this article in Wikipédia http://fr.wikipedia.org/wiki/Chat_de_Schr%C3%B6dinger

The Uncertainty Principle is certainly far from computer science. Yet it has an expression in computer science.

The customer needs constantly change as the customer develops what they want to achieve.

If this idea is true, the Predictive Methods can not be applied because the studied need is always different to the real need of the customer.

In fact in each step, it studies a need that the customer doesn’t have anymore. This is the most simple explanation as to why computer projects realized with this method need to change as soon as they deliver.

The Agile Methods give a solution to this idea. Indeed, they consider the change as part of the project and offer an organisation and tools to accept and manage it.

My experience and that of the project manager who I work with, shows me that this idea is true. This idea doesn’t contest the computer ability to solve complex problem. It simply works with the adaptability of humans.

This process is based on the idea that a person or a group of people adapt themselves systematically to the world around them. It simply uses the adaptability of humans.

When a customer decides to computerize a function in his company, he starts to study this function. From this moment, this function is going to change. First, some small bad functioning always exists. Next, the computer as a tool imposes some constraints which are going to change the way of working. These elements can be managed with predictive methods. But the changes in the mentality of customers and the users aren’t seen during the study. They come up when the software is delivered.

To be able to deliver a high-performance and a well accepted tool, it needs to know these changes as soon as possible and the only possibilities is to deliver as fastest as possible an operational software even partially.

La formation à la qualité

Je suis en ce moment au chômage et j’ai décidé de suivre une formation sur la qualité logicielle.

J’ai trouvé des formations de quelque jours sur différent sujets comme CMMI, ITIL, la qualité. Mais je n’ai pas trouvé de formation sur les usines d’intégration continue Open source ou commerciale, ni de formation globale.

Une formation globale comprend à la fois une formation à une ou plusieurs usines d’intégration continue, aux méthodes CMMI et ITIL, à la conception des tests, et à la gestion des tests. Ces formations semblent indispensable au vu des résultat des projets informatiques actuels et pour la mise en place des méthodes agiles.

Il est temps que les entreprises françaises puissent disposer d’informaticiens formés correctement. Lors de mes participation aux événement agiles, j’ai le plaisir de voir que des personnes qui travaillent pour de grandes entreprises, animent des sessions. C’est une preuve de la prise de conscience de l’échec des anciennes méthodes qui prônent la compréhension complète d’un projet de moyenne ou grande taille.

J’espère encore trouvé une formation globale. 

J’ai découvert les méthodes agiles chez Docubase qui les a mise en place à la fin de l’année 2008.
Ce fut une révélation. Je découvrais une approche réaliste des projets informatiques.

Je ne suis pas informaticien de formation. J’ai appris la programmation par la maintenance d’une application en C (programmation procédurale) que je n’ai jamais comprise en entier et grâce au livre de Kernighan et Ritchie.

J’ai ensuite suivi une formation sur la programmation objet. Ce fut ma première révélation. Lors de cette formation, j’ai compris pourquoi la programmation procédurale n’est pas une solution à la création de logiciel mais sert uniquement à programmer de petit utilitaire jetable. Je parlerais ailleurs de la réalisation de logiciel.

Après cette formation, j’ai réalisé des programmes conçus par des chefs de projet. J’ai progressivement pris en charge la conception de modules en suivant leurs exemples et étudiant dans des livres.

J’ai suivi une formation classique d’analyse. L’enseignement en 2004 présentait encore les méthodes prédictives. Il me restait un problème non résolu : Comment gérer les besoins fluctuants des clients.

La découverte des méthodes agiles m’a permis de comprendre que ce problème est inhérent non pas clients mais à l’approche prédictive.

La méthode prédictive affirme que tout projet informatique peut être analysé dans sa totalité. Un projet se réalise en 5 étapes successives :
• L’analyse du besoin.
• La rédaction des spécifications.
• La réalisation du projet.
• Les tests.
• La livraison.
Elle est dite prédictive car elle affirme qu’il est possible de prédire toutes les situations d’utilisation du projet informatique.

Les méthodes agiles proposent une approche totalement différente. Elle propose de construire le projet en étapes courtes qui finissent toutes par une livraison partielle sauf la dernière.

La force de ces méthodes est d’impliquer le client et les utilisateurs dès le départ du projet. Il dispose aussi très rapidement d’un produit utilisable même s’il est incomplet.Les utilisateurs peuvent tester l'application très rapidement. Ils peuvent donc très rapidement informer l’équipe de réalisation des adaptations nécessaires à l’approbation du projet.
Depuis que j’ai découvert les méthodes agiles, je pense qu’elles sont naturelles autant que pragmatique. Mais je n’arrivais pas à expliquer ce sentiment.

Puis en lisant le journal « la recherche », un article sur la physique quantique m’a permis de comprendre. Cet article parlait en particulier du principe d’incertitude.
L’un des énoncés de ce principe est :
L’état d’un système dépend de l’observateur. La principale illustration de cet énoncé est l'expérience du chat de Schrödinger. Voir cet article sur Wipikédia http://fr.wikipedia.org/wiki/Chat_de_Schr%C3%B6dinger
Nous sommes bien loin de l’informatique. Pourtant ce principe universel a une formulation en informatique.

Le besoin d’un client change dès que ce besoin commence à être exprimé et étudier.

Si cette hypothèse est vraie, la méthode prédictive ne peut plus être appliquée car le besoin qui est étudié n’est jamais le besoin réel du client.
En effet, à chaque étape la méthode predictive étudie un besoin que le client n’attend plus. C’est l’explication la plus simple au fait que les projets informatiques qui sont livrés avec cette approche sont soumis systématiquement à des modifications dès leur livraison.

Les méthodes agiles fournissent une solution à cette hypothèse. En effet, elle considère le changement comme faisant partie du projet et met en place des outils pour l’accepter et le gérer.

Mon expérience et celle des chefs de projet avec qui j’ai travaillé me montre que cette hypothèse est réelle. Cette hypothèse ne remet pas en cause la capacité de l’informatique à résoudre des problèmes complexes. Elle considère simplement la capacité d’adaptation de l’homme.

Le processus qui fonde cette hypothèse est qu’un individu ou un groupe d’individus s’adapte systématiquement aux changements du monde qui l’entoure.
Lorsque un client décide d’informatiser une fonction de l’entreprise, il commence par étudier cette fonction. À partir de cet instant, cette fonction va se transformer. D’abord, il existe toujours de petit dysfonctionnement. Ensuite, l’informatique en tant qu’outil impose des contraintes qui vont modifier la façon de travailler. Ces éléments peuvent être gérés par les méthodes prédictives. Mais le changement dans les mentalités des utilisateurs et des clients n’est pas perceptible pendant l’étude, mais n’apparaisse qu’à la prise en main de l’outil informatique livré.

Pour pouvoir livrer l’outil le plus performant et le mieux accepté, il faut faire s’exprimer le plus rapidement possible ces changements et le seul moyen est de mettre à disposition le plus rapidement possible l’outil mais incomplet.