Votre guide complet pour tout ce qui concerne le développement de logiciels

Publié: 2020-08-13

Dans quelle mesure un atelier de production d'usine et un bureau de développeurs de logiciels sont-ils similaires ?

Imaginez une salle pleine de programmeurs tapant du code dans leurs ordinateurs. Et si vous traitiez leur sortie comme des widgets assemblés sur une chaîne de montage d'usine ? Est-ce que les choses qui maximisent la production fonctionneront ici aussi ? Ou le processus de développement ressemble-t-il davantage à d'autres disciplines d'ingénierie ?

Les chefs de projet tentent de résoudre ce problème depuis le début du développement logiciel. De ces questions, la définition du cycle de vie du développement logiciel a émergé.

Qu'est-ce que le développement logiciel ?

C'est le processus de création d'un logiciel à partir de rien. Bien que l'écriture de code soit l'activité principale, c'est bien plus que cela.

Le processus de développement comprend l'idéation et la conception avant d'écrire un code. La planification est facile à négliger. Cela ne ressemble pas à du développement comme le fait l'écriture de code. Pourtant, répondre d'abord aux questions cruciales renforce le produit fini. Le projet vaut-il même la peine d'être poursuivi ? Si oui, quelle est la meilleure façon de s'y prendre? Quelles fonctionnalités sont nécessaires et quelles fonctionnalités sont agréables à avoir ? Les réponses donnent au projet une meilleure chance de réussir.

Bien que les étapes soient constantes, leur application varie. La raison pour laquelle le développement de logiciels est une nouvelle discipline. Les disciplines d'ingénierie sont matures avec des centaines d'années d'histoire. Le développement de logiciels ne remonte qu'à la fin des années 1940. C'est encore une nouvelle discipline. La méthode agile n'a que 20 ans. Pourtant, c'est l'une des choses les plus influentes qui se soit produite dans la théorie de la création de logiciels. Quoi qu'il en soit, les six phases du cycle de vie du développement logiciel sont communes à tous les systèmes.

6 étapes du cycle de vie du développement logiciel (SDLC)

Une équipe de développement peut utiliser le cycle de vie du développement logiciel sur l'ensemble d'un projet ou sur une fonctionnalité. L'évolution de l'utilisation du SDLC a consisté à réduire les risques en raccourcissant la durée de chaque étape. Dans un instant, nous examinerons davantage les différentes méthodologies. Examinons d'abord les étapes elles-mêmes.

De plus, il convient de noter que vous verrez des variantes en termes de nombre d'étapes ou de leurs noms. Parfois, les étapes sont fusionnées, comme le développement et les tests. D'autres fois, vous verrez une étape divisée en deux, comme la planification devenant planification et analyse. Dans notre cas, nous nous en tiendrons à ces six car ils définissent clairement les phases.

1. Planification

La phase de planification est l'étape la plus importante. Les parties prenantes doivent tout considérer, y compris la faisabilité du projet lui-même. C'est normal de tuer tout le projet ici. Une organisation saine habilitera les parties prenantes à le faire si nécessaire. Les programmeurs seront moins impliqués au cours de cette phase dans un environnement d'entreprise. Les propriétaires de produits, les analystes commerciaux et les autres parties prenantes expriment leurs besoins à cette étape.

2. Conception

3. Développement

L'étape de conception comprend également la conception de l'expérience utilisateur (UX). Si l'application comporte des composants destinés à l'utilisateur, la conception UX est indispensable. Cela inclut la recherche d'utilisateurs en regardant de vraies personnes interagir avec des maquettes de produits. La raison pour laquelle cela se produit dans la phase de conception au lieu de la phase de développement est le timing. Les sessions utilisateur prennent du temps. Souvent, des discussions plus fréquentes avec les parties prenantes de l'entreprise se produisent également à partir des données recueillies.

4. Tests

Ensuite, l'équipe de développement teste le code. Le rédacteur et le testeur de code doivent être des personnes différentes. Encore mieux, un testeur d'assurance qualité non développeur. Les développeurs ont tendance à ne penser qu'à des scénarios de chemin heureux. Les professionnels des tests d'assurance qualité dédiés ont tendance à mieux réfléchir à la manière dont ils peuvent casser le logiciel. Ils sont plus susceptibles de trouver des bogues avant le déploiement de cette façon. Le résultat est un logiciel plus stable à la sortie.

Tests automatisés ou manuels

Les tests unitaires et les tests d'intégration sont souvent automatisés. Souvent, une plate-forme DevOps exécute ces tests sur un nouveau code avant de le fusionner dans la branche principale.

Les tests manuels sont loin d'être obsolètes. Les tests automatisés font la même chose encore et encore. Pourtant, une personne effectuant des tests manuels peut trouver des bogues par accident pendant les tests. C'est la variabilité des tests manuels qui fait sa force.

Tests unitaires

Un test unitaire ne vérifie qu'une méthode, rien de plus. La fonction testée est la frontière. Le développeur écrit les tests unitaires et certains frameworks SDLC les imposent. La programmation extrême en a besoin. Il prescrit également le développement piloté par les tests. C'est la pratique d'écrire les tests unitaires en premier. Ensuite, écrivez le code de programme réel.

Tests d'intégration

Les tests d'intégration vérifient les sections ou les fonctionnalités de la base de code. Ils sont généralement automatisés et exécutés par la plateforme DevOps. Ce qu'ils vérifient couvre plus d'une seule méthode. Un exemple consiste à vérifier qu'un appel d'API a conservé un nouvel enregistrement dans une base de données. Comparez cela avec un test unitaire vérifiant également la méthode API. Le test unitaire ne pourra que vérifier qu'un appel à la base de données doit avoir lieu. Le test d'intégration peut prouver que les données ont traversé l'application comme prévu.

Test du système

La dernière forme de test est le test complet du système. Pour récapituler, les tests unitaires ne vérifient qu'une fonction. Les tests d'intégration vérifient une fonctionnalité. Mais les tests système traitent l'ensemble de l'application comme une seule unité. Le test de fumée est une forme légère de test du système. Dans celui-ci, le testeur interagit avec le système comme le ferait un utilisateur naturel et s'assure qu'il se comporte comme prévu. Contrairement aux tests complets du système de bout en bout, qui sont plus rigoureux. Un test complet du système vérifie toutes les parties d'un système comme une seule entité. En outre, une suite de tests d'intégration peut servir de test complet du système.

5. Déploiement

La phase de déploiement pousse le code testé en production. L'automatisation du déploiement le rend plus fiable. De plus, la pratique des déploiements de production augmente également les chances d'un déploiement en douceur. L'équipe de développement s'entraîne avec un environnement de test appelé environnement de staging. Il doit être identique à celui de production. Plus les deux environnements se ressemblent, plus le déploiement de la pratique a de la valeur.

6. Entretien

Jusqu'à présent, tout dans le SDLC ne représentera qu'environ un quart du coût total de possession. Le coût de développement initial d'un logiciel représente 25 % de ce que l'entreprise dépensera. La phase de maintenance coûtera à l'entreprise environ 75 % du coût total de possession. La défense contre la flambée des coûts de maintenance consiste à accorder plus d'attention aux phases précédentes. Cela signifie une meilleure conception technique, un développement et des tests plus approfondis. L'alternative est la dette technique. Comme la dette réelle, elle devient plus chère avec le temps.

5 principales méthodologies de développement logiciel

Bien que les étapes de SDLC ne changent pas, leur mise en œuvre et leur ordre d'exécution varient. Examinons les méthodes les plus populaires utilisées par les organisations pour le processus de développement de logiciels.

1. Agile

Ce qui rend Agile unique, c'est l'accent mis sur les personnes. Les méthodologies Agiles ont recentré l'attention de l'industrie. Auparavant, l'accent était mis sur le produit, le logiciel. Agile a contesté cela et s'est concentré sur les individus effectuant le processus. De plus, avant le Manifeste Agile, Extreme Programming (XP) et Scrum n'avaient aucun lien. Pourtant, par la suite, leurs praticiens se sont unis sous la bannière Agile.

Agile n'est pas un framework en soi. C'est un cadre pour les cadres. À la base, il s'agit de se concentrer sur les personnes et les itérations rapides. C'est exactement ce que son nom l'indique, agile. Bien fait, il y a de la flexibilité dans l'obtention du résultat. Les processus ne se font jamais au détriment des personnes, qui en tirent plutôt de la valeur.

Un autre locataire clé d'Agile est une approche itérative. L'idée est de faire des blocs de travail dans des tranches de temps plus courtes. De cette façon, l'entreprise peut s'adapter plus rapidement aux changements du marché. La capacité à changer rapidement la direction du développement est ce qui le rend agile. Dans le même temps, l'équipe de développement peut apprendre de ce qu'elle a fait à chaque itération et s'améliorer. Les équipes agiles le font lors de réunions rétrospectives après chaque itération.

2. Programmation extrême

La programmation extrême (souvent abrégée XP) a fait ses débuts au début des années 1990. Martin Fowler était l'un des premiers signataires du Manifeste Agile. Il pense qu'Agile a obtenu sa popularité grâce au framework XP. De plus, il maintient que c'est la meilleure façon de commencer à développer des logiciels Agile.

XP tire son nom de son approche. Il faut de bonnes pratiques logicielles courantes et les exige. C'est ce qui le rend "extrême". XP nécessite des choses comme les tests unitaires, la programmation en binôme, la publication plus souvent.

Ce qui fait de XP une méthode unique, c'est :

Cycles d'itération courts (1 à 2 semaines étant courantes)
Ouverture au remplacement des éléments de travail dans l'itération actuelle (ce que Scrum ne permet pas)
Accent mis sur les tests automatisés et la programmation en binôme

3. Maigre

Lean n'était pas Agile techniquement, mais il a une sensation similaire dans la pratique. Maintenant, c'est accepté comme faisant partie d'Agile par la plupart. Son objectif est différent de l'Agile traditionnel. Selon le manifeste Agile, "Les individus et les interactions sur les processus et les outils". Lean se concentre davantage sur le logiciel que sur les fabricants.

Ses racines sont les principes de fabrication Lean de Toyota. Voici les sept parties qui le définissent. Si vous êtes familier avec la fabrication Lean, cela semblera similaire. Elles sont:

Éliminer les déchets
Amplifier l'apprentissage
Décidez le plus tard possible
Livrez aussi vite que possible
Responsabiliser l'équipe
Construire l'intégrité dans
Optimiser l'ensemble

4. Mêlée

Scrum est la méthode Agile la plus populaire. Selon le 14e rapport State of Agile, 58 % des éditeurs de logiciels utilisent Scrum. Si vous incluez les hybrides Scum, le pourcentage grimpe à 84 %. Ce qui soulève la question, pourquoi est-il le plus populaire ?

La réponse est que Scrum consiste à faire plus de travail en moins de temps. Cela plaît aux entreprises. Chaque itération dans Scrum est un "sprint". Le nom renforce l'idée de vitesse. Habituellement, un sprint dure 2 à 3 semaines. Une fois qu'une équipe Scrum a planifié un sprint, personne ne doit le modifier. Les nouveaux travaux doivent attendre le début du sprint suivant. Cela demande de la discipline de la part des parties prenantes de l'entreprise. En pratique, cette règle Scrum est souvent violée. C'est pourquoi les équipes déclarent souvent faire un Scrum hybride.

Une autre caractéristique de Scrum est le Scrum Master. Il s'agit d'un membre de l'équipe nommé pour être en charge de maintenir le sprint sur la cible. Souvent, le Scrum Master est un développeur de l'équipe de développement.

La variante la plus courante de Scrum est ScrumBan, qui est un mélange de Scrum et de Kanban. Kanban a ses racines dans le processus de fabrication Toyota japonais comme Lean. C'est un système de travail juste à temps.

Chaque élément de travail est comme une itération qui lui est propre. Un développeur ne travaille que sur une chose à la fois. La règle est un élément "en cours" par développeur. Cette limite stricte de travaux en cours met en lumière tout goulot d'étranglement. Les développeurs suivent les éléments de travail en cours via un tableau Kanban. En remarque, c'est de là que vient le nom. En japonais, Kanban signifie « enseigne ».

5. Cascade

La méthode en cascade est la plus ancienne de toutes les pratiques de développement logiciel. Il est antérieur à Agile de plusieurs décennies au moins. Cette méthode est également plus ancienne que son nom.

C'est la manière naturelle dont les entreprises ont toujours travaillé. C'est un processus linéaire, et vous commencez au début. Tout d'abord, les parties prenantes compilent les exigences. Ils ne font pas ça pour une fonctionnalité ou deux. Non, les parties prenantes de l'entreprise étudient l'ensemble du projet en une seule fois. Après, le travail commence. Les développeurs font tout le travail sans aucune itération jusqu'à la fin.

La méthode de la cascade est la plus facile à comprendre conceptuellement. Les gens font une chose à la fois. Cela dit, c'est le plus risqué pour le succès de l'entreprise. Si quelque chose est hors cible, les parties prenantes ne peuvent pas le corriger avant la fin du projet. La raison en est qu'il ne sera même pas remarqué avant l'achèvement du projet.

3 principaux sous-types de logiciels

Le logiciel fini est l'un des trois types. Ces types sont les logiciels système, de programmation et d'application. Pour illustrer, voici une analogie avec la pâtisserie. Un mélangeur ou une spatule est le logiciel de programmation. Il vous permet de faire plus de gâteaux ou plus d'applications logicielles dans cette analogie. Lors de l'assemblage d'un gâteau, la couche inférieure est le logiciel système. C'est la fondation. Sans cela, vous ne pouvez pas avoir un gâteau en couches. La couche supérieure serait alors le logiciel d'application. C'est ce qui est visible pour la plupart des observateurs occasionnels.

Logiciel système

Le système d'exploitation d'un ordinateur est un logiciel système. C'est crucial pour son utilité. Imaginez un ordinateur sans système d'exploitation. Vous ne pourrez interagir avec lui que via le langage machine. C'est du binaire pur - juste des uns et des zéros. Il vous serait impossible de travailler avec à n'importe quel niveau d'échelle. Le logiciel système ouvre l'utilité d'un ordinateur.

Windows, macOS et Linux sont les exemples les plus populaires de logiciels système. Les pilotes de périphérique sont également des logiciels système. Ils étendent les fonctionnalités de base d'un système d'exploitation. Les appareils intelligents sans système d'exploitation utilisent un micrologiciel pour activer leur fonctionnalité. C'est aussi un logiciel système.

Logiciel de programmation

Le logiciel de programmation est un sous-ensemble du logiciel d'application. Tout programme utilisé par un développeur pour créer de nouveaux programmes serait classé. Ils vont des simples éditeurs de texte aux environnements de développement intégrés (IDE) complexes. La plupart des développeurs préfèrent les outils logiciels de programmation plus complexes. Des programmes comme Visual Studio de Microsoft aident à accélérer le développement.

Logiciel d'application

Le logiciel d'application est le type le plus courant. C'est le logiciel qui vous permet de faire des choses avec un ordinateur. Cela rend les ordinateurs utiles. Des exemples populaires sont des programmes comme Microsoft Word et Excel.

Les logiciels cloud entrent également dans cette catégorie. Google Docs, Dropbox et même Instagram sont des logiciels d'application. Si jamais vous ne savez pas si quelque chose est un logiciel d'application ou non, voici un test simple. Le programme a-t-il besoin d'autre chose pour fonctionner ? Windows ou Android ne le font pas. Ce sont des logiciels système. PowerPoint, ou même un jeu comme Call of Duty, a besoin d'autres choses en cours d'exécution pour fonctionner, ce qui signifie qu'il s'agit d'un logiciel d'application. Sans pilotes de périphériques et système d'exploitation, ils ne peuvent pas s'exécuter.

Conclusion

Les méthodes de développement de logiciels sont encore en cours de maturation. Pourtant, quelle que soit la méthode utilisée, les étapes restent les mêmes. Les équipes agiles peuvent les parcourir plus rapidement, et les praticiens de Waterfall passent lentement de l'un à l'autre. Pourtant, pour créer un meilleur logiciel, vous devez renforcer le processus à chaque étape. Ils se construisent les uns sur les autres. Le cycle de vie du développement logiciel n'est pas une chose sans l'une de ses étapes. Les parties font le tout.

Pensez à ce qui se passerait si vous laissiez une étape de côté. Sans planifier ce que vous faites? Sans conception, le processus de développement sera aléatoire. Laisser de côté l'étape de développement est impossible. Un manque de tests garantit que le produit ne fonctionnera pas comme prévu. S'il n'y a pas de déploiement, personne n'aura accès au produit. Une application non maintenue tombe en désuétude. Chaque étape est cruciale pour le succès d'un produit logiciel.