Recommandé à collectionner! Un processus complet de développement logiciel

Prenons l'exemple du processus de développement de produits de base

Généralement, lorsque les entreprises développent des logiciels, elles effectuent le travail de développement de projet de deux manières parallèles : base de référence et personnalisation. Quelle que soit l’entreprise, elle doit suivre un système de processus de développement de produits mature afin de produire des produits de meilleure qualité. Par conséquent, s'il existe de nombreux projets, la référence et les jalons avant la personnalisation doivent être raisonnablement organisés de manière à ce que le produit de base puisse collecter autant d'exigences générales des utilisateurs que possible, fournir un support technique pour l'avancement du projet de personnalisation et réduire le grand nombre de changements de code dans le projet de personnalisation, la nécessité d'ajouter de nouveaux modules se produit. De plus, le système de processus de développement de produits doit également évoluer en fonction des besoins réels de l'entreprise. Ne vous en tenez pas à la méthode en cascade ou à la méthode agile. Tout doit être géré d'une manière qui vous convient. Seuls vos pieds savent si les chaussures vous conviennent ou non.

Nous utilisons ici un processus de développement de produit de base comme base pour l'explication du processus. Il convient de noter que pour chaque étape décrite ci-dessous, Avant l'exécution du projet, les objectifs de chaque étape doivent être clairement définis, les plans spécifiés, la communication en temps opportun et veiller à ce que tous les membres aient une compréhension cohérente du projet.

Réunion de lancement du projet

L'objectif de la réunion de lancement du projet est de clarifier les objectifs du projet de développement de produits. Les objectifs n'existent pas isolément. Les objectifs et les plans se complètent. Les objectifs guident les plans, et l'efficacité des plans affecte la réalisation des objectifs. Par conséquent, lors de l'exécution des objectifs, réfléchissez clairement à votre propre plan d'action et à la manière d'atteindre les objectifs plus efficacement. C'est une question sur laquelle tout le monde doit être clair en détail, sinon des objectifs peu clairs ou trop élevés affecteront la performance réelle de l'objectif. résultat du projet.

La réunion de lancement du projet doit expliquer les objectifs du projet, les divisions de phases, la structure organisationnelle, les processus de gestion et d'autres questions clés, et rédiger ces contenus en PPT (de préférence avec un format fixe et un exemple de texte, afin que l'équipe ou l'entreprise peut respecter conjointement les normes ), tout le monde doit parvenir à un consensus. Pour la nomination des rôles clés, il est également nécessaire d’écouter au préalable les opinions des dirigeants concernés et des principales parties prenantes du projet.

Besoins des utilisateurs

Avant de commencer à développer un logiciel, il est nécessaire de déterminer la comparaison entre le coût et la valeur obtenue, c'est-à-dire le ROI (Return On Investment). Une fois qu'il est déterminé qu'il doit être créé, une série. Des ressources doivent être organisées pour soutenir la survie du logiciel. Il s’agit de la description la plus primitive des exigences.

Pourquoi avons-nous besoin à la fois des besoins des utilisateurs et des besoins des produits ?
Parce qu'il existe une différence entre les deux, les besoins des utilisateurs sont mis en avant par les utilisateurs et la technologie n'est généralement pas décrite, seuls les objectifs du produit sont décrits. Les exigences du produit sont des exigences de mise en œuvre technique transformées à partir des besoins des utilisateurs.Il est nécessaire de subdiviser les objectifs du produit proposés par les utilisateurs, de résumer chaque point de fonction spécifique, puis de subdiviser chaque point de fonction en divers processus opérationnels.

Les besoins des utilisateurs et les besoins en matière de produits sont sujets à des différences. En effet, même si tout le monde parle de besoins, le point de départ peut être différent, ce qui entraîne des préoccupations et des façons de penser différentes entre les deux parties. Les besoins des utilisateurs se concentrent sur la manière dont le système prend en charge les processus métier, et la demande qui le sous-tend est « d'atteindre les objectifs commerciaux ». Le personnel technique se concentre sur des solutions techniques raisonnables, et les exigences qui les sous-tendent sont la « charge de travail », la « difficulté de mise en œuvre » et les « performances du système ».

Exigences du produit

Nous devons comprendre pourquoi le chef de produit ou le proposant des exigences du projet souhaite réaliser ce projet ? Il s’agit de l’exigence commerciale la plus essentielle. Les besoins commerciaux déterminés par l’analyse de la demande découlent tous des besoins commerciaux et doivent répondre à ces besoins.

Les exigences du produit comprennent généralement des spécifications des exigences du produit et une matrice des exigences du produit. La matrice des exigences du produit répertorie généralement toutes les exigences fonctionnelles en fonction de la structure des sous-systèmes, des ensembles de fonctions et des unités d'exécution. Chaque colonne correspond aux étapes de travail de chaque fonction et à la charge de travail de chaque étape.

Une fois les exigences du produit rédigées, elles doivent être révisées. Lors de la réunion d'examen des exigences, les exigences détaillées de l'examen des produits et de la technologie sont-elles remplies ? Quels sont les scénarios normaux pour les fonctions du produit ? Est-ce que cela forme une boucle fermée ? Quels sont les scénarios inhabituels ? Est-ce réfléchi ?

Après l'examen des exigences, les responsables du développement et des tests rédigeront respectivement des solutions techniques et des cas de test.
Revue du plan technique, le responsable du développement réunit les responsables des autres systèmes pour discuter. Le plan technique doit avoir un organigramme commercial et un diagramme de séquence L'organigramme commercial sert à trier la compréhension de l'entreprise par le développement. et si cela répond aux besoins de manière cohérente. Le diagramme de séquence sert à trier les interactions système impliquées dans cette exigence. Une fois le plan technique examiné et approuvé, la charge de travail et le délai de livraison seront confirmés et répercutés sur le produit.

L'objectif de la phase de conception est principalement d'analyser et de concevoir l'architecture du système à développer, et d'établir la base de référence de l'architecture du système afin de fournir une base stable pour les travaux de mise en œuvre ultérieurs.

La phase de conception comprend le résultat de l'architecture du système. Une bonne conception de l'architecture du système peut aider les humains à trier la logique métier et à comprendre les exigences fondamentales, à concevoir des systèmes commerciaux stables et évolutifs, à évaluer les cycles de développement commercial et les coûts de développement et à éviter efficacement les risques. . Par exemple, lors de la construction d'une maison, vous devez disposer de dessins architecturaux. Ce n'est qu'avec ces dessins que vous pourrez calculer la période de construction.

La conception globale est la conception du cadre de l'ensemble du système. Elle est d'une grande importance et ne peut être omise dans des circonstances normales (la conception globale ne peut être omise que pour les projets de maintenance car le projet de base a été conçu Tous les projets de développement de produits nécessitent une conception globale). la conception d'abord. , c'est la première étape de la conception, et il n'est jamais permis de mettre la charrue avant les bœufs, et le codage d'abord puis la conception ne sont pas autorisés. C'est le deuxième plus gros problème du développement logiciel (le premier n'est pas clair). exigences et modifications arbitraires des exigences !) .

La conception globale est divisée en trois phases :

• Phase 1 : Conception initiale. Sur la base de l'examen et de l'affinement du diagramme de flux de données donné, il est converti en un diagramme de structure de module initial.

• La deuxième phase : Design raffiné. Selon le principe de « cohésion élevée et faible couplage » des modules, le diagramme de structure initial du module est affiné et la structure globale des données et l'interface de chaque module sont conçues.

• La troisième phase : Phase de révision de la conception, examen de la structure logicielle de haut niveau obtenue au cours des deux premières phases, et il peut également être nécessaire d'affiner la structure logicielle si nécessaire.

Conception des contours

Le but de la conception des contours est de décrire la conception interne de chaque module du système et de jouer un rôle de liaison entre la conception globale et la conception détaillée.

La conception des contours est conçue selon la méthode de conception structurée. L'idée de base de la méthode de conception structurée est la suivante : selon le domaine problématique, le logiciel est affiné étape par étape et décomposé en modules qui n'ont pas besoin d'être décomposés. Chaque module remplit une certaine fonction et sert un ou plusieurs modules parents. (c'est-à-dire accepte les appels), accepte également les services d'un ou plusieurs sous-modules (c'est-à-dire appelle les sous-modules). La notion de modules correspond à des sous-programmes ou fonctions dans les langages de programmation.

Au stade de la conception des grandes lignes, le logiciel est décomposé en niveaux de modules selon certains principes, chaque module se voit confier certaines tâches et les relations d'appel et les interfaces entre les modules sont déterminées.

À ce stade, le concepteur réfléchira et s'occupera généralement de la mise en œuvre interne du module, mais sans trop s'y emmêler. Concentrez-vous principalement sur la division des modules, l'attribution des tâches et la définition des relations d'appel. Les interfaces et les transferts de paramètres entre modules doivent être rendus très détaillés et clairs à ce stade, et un dictionnaire de données rigoureux doit être rédigé pour éviter toute confusion ou malentendu dans les conceptions ultérieures. La conception des grandes lignes ne se fait généralement pas en une seule fois, mais nécessite des ajustements structurels répétés. Les ajustements typiques consistent à fusionner les modules avec des fonctions en double ou à les décomposer davantage en modules pouvant être réutilisés. Au stade de la conception des grandes lignes, les modules réutilisables doivent être extraits au maximum, un système structurel raisonnable doit être établi et la charge de travail des liens ultérieurs doit être économisée.

Les parties les plus importantes du document de conception générale sont le diagramme de flux de données hiérarchique, le diagramme de structure, le dictionnaire de données et les descriptions textuelles correspondantes. Sur la base du document de conception schématique, la conception détaillée de chaque module peut être réalisée en parallèle.

Conception détaillée

L'étape de conception détaillée consiste à concevoir l'algorithme et le processus au sein de chaque module sur la base de la décomposition de l'étape de conception générale, à fournir une description spécifique des fonctions complétées par chaque module et à transformer la description fonctionnelle en un structure précise.Description du processus de transformation.

Dans cette étape de conception détaillée, chaque module peut être attribué à différentes personnes pour une conception parallèle. L'objet de travail du concepteur est un module. Sur la base des tâches locales et des interfaces externes assignées par la conception générale, le concepteur conçoit et exprime les algorithmes, les processus, les transitions d'état du module, etc.

Il convient de noter ici que s'il s'avère qu'un ajustement structurel est nécessaire (comme la décomposition des sous-modules, etc.), vous devez revenir à l'étape de conception des grandes lignes et refléter l'ajustement dans le document de conception des grandes lignes, et cela ne peut pas être résolu sur place sans dire bonjour. Les parties les plus importantes du document de conception détaillée sont l'organigramme du module, le organigramme des états, les variables locales et la description textuelle correspondante, etc. Un module correspond à un document de conception détaillée.

Le diagramme de structure du logiciel est généralement obtenu au cours de la phase de conception générale. Les méthodes de description couramment utilisées au cours de la phase de conception détaillée comprennent : un organigramme, un diagramme N-S, un diagramme PAD, un pseudo-code, etc. Le but de la conception détaillée est de décrire le flux de traitement interne, les méthodes de développement et les compétences de codage d'un module donné. De manière générale, la conception détaillée comprend

introduction du projet, description du module (décrivant spécifiquement les processus internes, les fonctions, la logique, la consommation et les problèmes non résolus de chaque module), conception d'interface (y compris les interfaces internes et externes), Conception de la structure des données (y compris la structure physique et la structure logique), Traitement spécial et autres parties. La conception détaillée d'un logiciel est en fin de compte une description écrite des méthodes de conception, de la logique et des fonctions spécifiques de chaque partie du système logiciel. De cette façon, pendant le processus de mise en œuvre, les codeurs peuvent implémenter le code strictement selon ce principe.

Écrire du code

Vous pouvez suivre les principes suivants lors de l'écriture de code :

• Effectuez d'abord le test de résistance du module de base : De nombreux programmeurs sont habitués à terminer les choses, puis attendent d'être sur le point de se connecter avant de faire des tests de performances. S'il y a un problème avec la conception précédente, ce sera le cas. un gros mal de tête. Bien sûr, des tests de performances seront également effectués lors de la mise en ligne ultérieure, mais je pense que cela reste très important au début. Bien sûr, pour bien faire cela, vous devez comprendre certaines activités. Vous devez savoir où se situe la pression commerciale et où se concentrent les demandes commerciales. Souvent, si le chef de produit ne l'explique pas, vous devez demander clairement. .

• Assurez-vous que le processus est contrôlable : La sortie intermédiaire doit être maintenue lorsque le code est exécuté. Par exemple, chaque fois que 100 000 journaux sont traités, un journal d'état est écrit pour enregistrer le nombre d'entrées de journal traitées et le courant. temps d'exécution.

• Connectez-vous plus : Souvent, je ne suis pas très satisfait du code que j'écris. Par exemple, une certaine efficacité de traitement n'est pas suffisamment optimisée, une certaine méthode de traitement n'est pas assez concise ou l'évolutivité est relativement faible. , et le code est écrit avec un retard mental. Mais je ne pourrai peut-être pas trouver la solution la plus raisonnable en peu de temps, étant donné que ce n'est pas l'objectif au début du lancement, mais je ne l'optimiserai pas délibérément. , dans ce cas, je laisse souvent une note et explique la prochaine étape de l'optimisation quelles sont les idées possibles, ou quelles sont les solutions possibles qui me viennent à l'esprit.

• Logique simple et facile à comprendre : Ne vous impliquez pas, avec le temps, personne ne pourra comprendre votre logique. Si la logique est vraiment difficile à réaliser dans une fonction, essayez de la découper.

• Ne soyez pas obsédé par les frameworks : Quel est le plus gros problème avec les frameworks ? C'est une nidification trop lourde. Pourquoi suis-je toujours ennuyé par les frameworks ? Parce que nous rencontrons souvent des scénarios de traitement qui nécessitent des milliers de requêtes par seconde, lors du réglage, nous devons rechercher les points bloqués dans la logique de traitement des données et les performances d'innombrables frameworks. Nous pouvons modifier seulement deux lignes de code, mais trouver le problème prend deux jours. Les programmeurs n'oubliez pas que vos capacités techniques ne doivent pas être limitées par le framework.

• Utilisez une technologie familière et mature : De nombreuses personnes ne comprennent tout simplement pas où se trouvent leurs obstacles et leurs problèmes, et elles ne savent pas quels sont les avantages et les inconvénients des produits technologiques associés. évaluations des données des partis, leur cerveau Une fois que vous aurez chaud, vous apprendrez de nouvelles technologies, puis vous tomberez dans un gouffre et vous ne pourrez pas en sortir. Si vous êtes une start-up, le projet peut y mourir. Avant d'utiliser une nouvelle technologie, il est recommandé de bien comprendre les caractéristiques, la portée applicable et la portée non applicable de la technologie.

Révision de code

Comme nous le savons tous, effectuer des révisions de code au sein d'une équipe peut améliorer la qualité du code, partager les connaissances du projet, clarifier les responsabilités et, en fin de compte, créer de meilleurs logiciels et de meilleures équipes.

La révision du code est extrêmement importante. De manière générale, une révision du code doit être effectuée chaque semaine. Tout d'abord, les revues de code vous aident à suivre l'avancement du projet. Nous pouvons vraiment voir comment les personnes sous nos ordres progressent et découvrir plus tôt si elles s'égarent. Parfois, les gens disent "C'est presque terminé !", et vous regardez le code et constatez qu'il n'y a rien ou juste un tas d'ordures, etc., mais il est encore loin d'être terminé. En gestion, cette situation est la plus ennuyeuse, je pense donc que la révision du code est le meilleur moyen d'éviter ce problème.

Test unitaire

Pour comprendre les tests unitaires, vous devez d'abord comprendre ce qu'est une « unité ». Ce qu'on appelle « unité » fait référence à la plus petite unité d'appel de code, qui fait en fait référence à un bloc fonctionnel (Fonction) ou à une méthode (Méthode). Les tests unitaires font donc référence au test des unités qui appellent ces codes.

Les tests unitaires sont une sorte de test en boîte blanche, qui est un test qui doit être très clair sur les détails du code de l'unité. Par conséquent, l’écriture et l’exécution des tests unitaires sont effectuées par des ingénieurs logiciels. Par rapport aux tests unitaires, il existe également des tests d'intégration. Les tests d'intégration sont essentiellement des tests en boîte noire, qui sont principalement effectués par des testeurs conformément au manuel fonctionnel du logiciel, et nécessitent la coopération d'un environnement de test spécial. Les tests d'intégration sont divisés en tests fonctionnels, tests de régression, etc.

Le code qui nécessite des tests unitaires est en fait la logique écrite par les développeurs eux-mêmes. Tester si l'environnement dont dépend la logique est normal n'est pas le but des tests unitaires

. L'introduction d'une logique dans le code d'accès à l'environnement ne fera que rendre la logique plus difficile à tester, rendant le code logique impossible à tester unitairement. Par conséquent, le code testable unitaire peut être testé unitairement. Une autre façon de juger le code testable est de voir si la méthode peut être exécutée directement à l'aide d'une fonction principale. Si tel est le cas, il s'agit d'un code testable unitaire. Une autre caractéristique du code testable est que les paramètres de l'unité de méthode peuvent être simulés librement par les développeurs sans dépendre de l'environnement externe. Tests d'intégration

Tests d'intégration, également appelés tests d'assemblage ou tests conjoints. Sur la base des tests unitaires, tous les modules sont assemblés en sous-systèmes ou systèmes selon les exigences de conception pour les tests d'intégration. La pratique montre que même si certains modules peuvent fonctionner de manière indépendante, rien ne garantit qu'ils fonctionneront correctement une fois connectés. Certains problèmes qui ne peuvent pas être reflétés localement sont susceptibles d'être exposés à l'échelle mondiale

.

Le test d'intégration est un test effectué lors du processus d'intégration des systèmes logiciels. Son objectif principal est de vérifier si les excuses entre les unités logicielles sont correctes. Selon le plan de test d'intégration, il combine des modules ou d'autres modules dans un système de plus en plus grand tout en exécutant le système pour analyser si le système composé est correct et si les différents composants s'emboîtent. Il existe deux stratégies principales pour les tests d'intégration : descendante et ascendante. Il peut également être compris comme le test conjoint de divers composants du système applicatif (unités logicielles, interfaces de modules fonctionnels, liens, etc.) lorsque l'unité de conception logicielle et les modules fonctionnels sont assemblés et intégrés dans le système pour déterminer s'ils peuvent fonctionnent ensemble. , les composants peuvent être des blocs de code, des applications autonomes, des programmes côté client ou côté serveur sur le réseau .

Tests du système

La phase de test du système comprend plan de test du système et rédaction de cas d'utilisation, tests fonctionnels, tests de performances, tests de stabilité.

Afin de vérifier si les fonctions déterminées par l'analyse des besoins sont complètes et correctement mises en œuvre, les exigences non fonctionnelles telles que l'installation, le déploiement, l'adaptabilité, la sécurité et l'interface doivent également être testées. Les tests du système relèvent également de la responsabilité des testeurs. Ils doivent être conçus une fois l'analyse des exigences terminée et mis en œuvre une fois les tests d'intégration terminés.

Les tests fonctionnels
sont généralement testés par une équipe de test indépendante en utilisant une méthode de boîte noire. Il teste principalement si le système répond aux « spécifications des exigences ». Après les étapes de test et de confirmation ci-dessus, le système est entièrement simulé pour tester l’environnement client. Les tests du système consistent à combiner les logiciels, le matériel informatique, les périphériques, les réseaux et d'autres éléments confirmés pour effectuer divers tests d'assemblage et de confirmation du système d'information. Le but est de découvrir les informations développées en les comparant aux exigences du système. Le système ne correspond pas ou contredit les besoins des utilisateurs, une solution plus complète peut être proposée.

Test de performance
Vérifiez la stabilité et l'efficacité du système et vérifiez si le système répond aux exigences de performance spécifiées. Les tests de performances sélectionnent généralement certaines fonctions typiques pour vérifier si le système est stable lorsqu'un grand nombre d'utilisateurs utilisent le système en même temps. Les tests de performances relèvent de la responsabilité du testeur. Ils peuvent être effectués une fois le test du système terminé, ou les tests de performances des modules importants peuvent être effectués en premier. Ils peuvent être exécutés tout au long du cycle de test. Le but est de découvrir les goulots d'étranglement des performances du système le plus tôt possible. que possible et résolvez-les rapidement.

Les tests de stabilité et les tests de performances doivent attendre que le système soit fondamentalement correct et stable pour être efficace. Sinon, il sera difficile de tester en douceur et il sera impossible de déterminer si une anomalie est un problème avec l'architecture du système ou. un défaut fonctionnel.

Test de stabilité (également appelé test de fiabilité)
En chargeant le système avec une certaine pression commerciale et en laissant le système fonctionner en continu pendant une période de temps (généralement 7 x 24 heures), il teste si le système peut fonctionner de manière stable.

Libération du produit

La publication du produit est la dernière étape après le test du système. Habituellement, dans le processus de développement d'un produit logiciel, il n'est pas nécessaire de produire un essai du produit et il peut être mis en ligne directement. signaler et approuver la sortie du produit (en ligne) C'est tout.

Avant la sortie du produit, il est nécessaire d'organiser une réunion d'information sur la sortie du produit pour retracer l'ensemble du processus de développement du produit depuis la création du projet afin de souligner les lacunes de l'ensemble du processus, de résumer l'expérience et de fournir des cas d'expérience pour le prochain projet. Cette réunion peut se tenir sous la forme d'une réunion formelle. Les chefs de produit, les principaux développeurs, les testeurs, les dirigeants supérieurs, etc. doivent être convoqués pour y participer. Ils doivent être parfaitement préparés et faire de leur mieux pour expliquer les effets et les avantages de la réunion. produit après sa sortie, afin d'évaluer la valeur après son lancement. Ce lien est indispensable, même dans les entreprises Internet avec une vitesse d'itération rapide, ce lien doit encore être respecté.

Révision du processus de développement

En fait, ce processus n'existe pas dans le système de processus de développement, mais je pense personnellement qu'il est très important.

Tous les résumés ne peuvent être obtenus que si vous y réfléchissez avec des questions. Ceci est une révision. Peu importe combien je le dis, si je n’ai pas vécu des expériences similaires, il sera difficile d’avoir une forte résonance. Je pense que la meilleure façon de voir clairement un problème est d’avoir joué deux rôles différents face au même problème.

Le but de résumer l'expérience et les leçons du projet est de résumer les problèmes, d'analyser les causes et d'éviter de commettre les mêmes erreurs à l'avenir, plutôt que de tenir quiconque pour responsable.

Supposons qu'il y ait un défaut dans la compréhension des exigences. S'il est découvert au cours de la phase d'exigences, la modification ne peut prendre qu'une heure. Cependant, si le défaut est découvert une fois la conception terminée, on estime qu'il le sera. prendre un jour en raison de l'augmentation du nombre de personnes et de documents impliqués. Si vous attendez que le code soit découvert, cette faille n'a été découverte qu'une fois que tout a été écrit, ce qui peut prendre dix ou huit jours. Que se passe-t-il si le défaut n'est pas découvert et est directement transmis au système de production ? Ce n’est plus une question de charge de travail, et la perte estimée est difficile à estimer. Dans la théorie de la gestion de la qualité, chaque fois qu'un défaut est découvert tardivement, le coût de la réparation sera multiplié par dix.

Écrit à la fin

Le développement agile, le développement extrême et d'autres modèles visent à résoudre le problème de l'itération rapide lorsque les exigences ne sont pas claires et que le temps est compté, non pas pour nier fondamentalement le processus de R&D. La conception doit encore être conçue, mais. le cycle de vie est effectué par segmentation, divisant le processus horizontalement en plusieurs cycles. Le développement de logiciels est une discipline avec des exigences d'ingénierie strictes. Adhérons à une attitude rigoureuse et à des méthodes de travail efficaces pour créer des produits logiciels hautement disponibles et de haute qualité.

Cet article est réimprimé, auteur original : Zhou Mingyao, adresse originale : https://mp.weixin.qq.com/s/-XDomowMhz9rX-zeCIJuaA