Les 11 principales étapes du cycle de vie du développement du système

Cet article met en lumière les onze étapes du cycle de vie du développement du système. Les étapes sont les suivantes: 1. Sélection de la zone et définition du problème (Enquête préliminaire) 2. Collecte de données / d'informations 3. Création d'alternatives 4. Étude de faisabilité 5. Plan directeur de développement 6. Évaluation et sélection de l'équipement 7. Conception et développement du système 8. Système Tests 9. Mise en œuvre du système 10. Revue et suivi du système.

Cycle de vie du développement du système Étape 1. Sélection de la zone et définition du problème (Enquête préliminaire):

Il s’agit de la première phase et consiste en une brève étude de la zone concernée. Le projet passera à la phase suivante du projet, en retardant le développement pour une période donnée ou en recommandant qu’aucune autre mesure ne soit prise.

Parfois, il est divisé en une enquête préliminaire (étude initiale) suivie d'une étude de faisabilité plus détaillée.

La phase est initiée par la direction, qui en perçoit le besoin en raison de changements ou de champs attendus dans l’environnement commercial, de l’initiation ou de la défaillance de systèmes existants, ou de la connaissance des avancées technologiques relatives au domaine particulier concerné par les systèmes développés par la concurrence.

Cycle de vie du développement du système Étape 2. Collecte de données:

La collecte de données fait référence à la collecte d'informations pertinentes pour le projet de systèmes. Pour obtenir des informations, l'analyste peut lire des livres ou des rapports, parcourir des enregistrements, collecter des formulaires pour une analyse ultérieure ou interroger des personnes. L'interview est une compétence importante pour l'analyste qui peut interroger des gestionnaires, des travailleurs, parfois même des clients.

Certaines des informations les plus importantes proviennent souvent des employés subalternes (les travailleurs).

Sources d'information:

Les informations proviennent de deux sources principales. Les sources sont les suivantes:

1. De l'environnement de l'organisation.

2. Personnel ou documents écrits au sein de l'organisation.

Les principales sources externes sont:

1. Documents gouvernementaux

2. vendeurs

3. Journaux et revues professionnelles.

Les principales sources internes sont:

1. Personnel

2. Rapports financiers

3. Documentation système des manuels

4. Rapports et documents de transaction

5. Personnel professionnel (avocat, auditeur, etc.).

6. Le personnel utilisateur.

Les fournisseurs de matériel constituent la source d'informations sur le système et le logiciel. Il existe des milliers de progiciels sur le marché pour sauvegarder la zone à problèmes et ces logiciels sont utilisés après les modifications raisonnables. Les informations de ces packages sont déjà vendues par les fournisseurs de matériel.

Les documents gouvernementaux, les journaux techniques et les revues professionnelles constituent la deuxième source d’information externe. Ils fournissent des informations hebdomadaires sur le nouveau matériel, les installations matérielles, les développements logiciels, etc.

Les sources d'information internes sont limitées au personnel utilisateur ou à l'utilisateur. Le personnel des utilisateurs constitue une source très étendue d'informations. Ce sont les employés clés qui travaillent dans le domaine des utilisateurs depuis des années et qui connaissent bien les activités et applications actuelles. Nous collectons ensuite les informations à partir des documents historiques et sensibles.

Dans certains cas, c'est la seule source disponible pour l'analyste. Au fur et à mesure que les informations sont collectées, l'analyste documente les aspects importants afin de pouvoir y faire référence ultérieurement. À cette fin, il peut utiliser des formulaires, des graphiques ou des tableaux.

Les principales méthodes d'obtention de faits incluent:

(a) Observer des activités pouvant être réalisées de différentes manières, notamment par des méthodes visuelles et photographiques.

(b) Utilisation de questionnaires ou par inspection et examen.

c) Entretien avec le personnel.

Étape de cycle de vie du développement du système # 3. Création d'alternatives:

Une fois que l'analyste a une idée claire des problèmes, il commence à créer des solutions possibles. Dans la pratique, ces solutions commencent généralement à se former pendant la recherche initiale (collecte de données). Une fois la recherche terminée, l’analyste choisit les alternatives les plus prometteuses et les développe.

Pour créer des solutions de remplacement valables, l’analyste doit avoir une vaste expérience du travail, doit être familiarisé avec les nombreux types d’équipement pouvant être appliqués au problème et doit être familiarisé avec les différents types de procédures pouvant être utilisés.

À partir de ce contexte, il peut développer une alternative similaire à celle utilisée par une autre société ou un autre groupe, ou créer une solution spéciale ou unique au problème de son entreprise.

Il est important de réaliser que les solutions à ce stade ne sont pas développées en détail. Les procédures développées ici ne sont pas spécifiques. Bien qu'un flux logique général soit créé pour chaque alternative, des étapes spécifiques seront déterminées lors de la phase de conception du système.

À moins que le problème ne soit assez limité, les analystes devraient essayer de développer plus d’une alternative. Cela leur donnera la liberté d'explorer des solutions imaginatives plutôt que de ne parler que de solutions rapides et évidentes. Cela donnera également à la direction une perspective plus large sur la gamme de solutions disponibles.

Étape de cycle de vie du développement du système # 4. Étude de faisabilité:

Une fois que les solutions de remplacement sont découvertes ou conçues, l’analyste effectue l’étude de faisabilité.

La réalisation de l'étude de faisabilité comprend les étapes suivantes:

(a) Formuler une déclaration sur les objectifs des problèmes.

(b) Analyse du système existant comprenant la collecte de données, la présentation de données, l'établissement de la liste des fichiers et des enregistrements nécessaires, les besoins en communication, la préparation d'organigrammes et l'estimation des coûts.

c) Analyse des solutions de remplacement répondant aux mêmes exigences pour chaque solution proposée.

(d) Détermination des principaux besoins en matière de production.

e) Étudier les effets sur les activités de l'entreprise.

f) Effet financier.

g) Résumé des pertes incorporelles et des avantages qui découleraient de l’adoption du système.

(h) Une recommandation de procéder.

La collecte de données effectuée au cours de l'enquête préliminaire examine la faisabilité du système, la probabilité que le système soit bénéfique pour l'organisation.

Les quatre tests de faisabilité sont:

1. Test opérationnel

2. Test économique

3. Test technique

4. Test politique

1. Test opérationnel:

Les projets proposés ne sont bien sûr avantageux que s’ils peuvent être transformés en systèmes d’information répondant aux besoins opérationnels de l’organisation. En termes simples, ce test de faisabilité demande si le système fonctionnera une fois développé et installé. Existe-t-il des obstacles majeurs à la mise en œuvre? Les questions suivantes aident à tester la faisabilité opérationnelle d'un projet.

Les méthodes commerciales actuelles sont-elles acceptables pour les utilisateurs? S'ils ne le sont pas, les utilisateurs peuvent souhaiter un changement qui entraînera un système plus opérationnel et plus utile. La direction apporte-t-elle un soutien suffisant au projet? Des utilisateurs? Si le système actuel est bien aimé et utilisé dans la mesure où les personnes ne verront pas la raison d'un changement, il peut y avoir une résistance.

Le système proposé causera-t-il des dommages? Les questions suivantes sont liées à ce problème:

(a) La perte de contrôle entraînera-t-elle une zone?

(b) Les clients seront-ils affectés de manière indésirable?

(c) Cela affichera-t-il la performance dans n'importe quel domaine?

(d) Le système produira-t-il des résultats plus médiocres dans quelque domaine que ce soit?

e) L'accessibilité à l'information sera-t-elle perdue?

4. Les utilisateurs ont-ils été impliqués dans la planification et le développement du projet? Une implication précoce réduit les chances de résistance au système et aux changements en général, et augmente les chances de réussite des projets.

La faisabilité opérationnelle est une mesure de la capacité des personnes à travailler avec le système. Par exemple, un système peut nécessiter que les responsables écrivent des programmes BASIC, COBOL ou FORTRAN pour accéder aux données. Cependant, un gestionnaire reçoit probablement la plus grande aide d'un système lorsqu'il peut se concentrer sur les problèmes à résoudre plutôt que sur la manière dont les programmes doivent être conçus pour les résoudre.

2. Test économique:

En consiste à estimer les avantages et les coûts. Ces avantages et coûts peuvent être tangibles ou intangibles.

Un système qui peut être développé techniquement et qui sera utilisé s’il est installé doit toujours être un bon investissement. Autrement dit, les avantages financiers doivent être égaux ou supérieurs aux coûts financiers.

Les questions économiques et financières soulevées par les analystes lors de l'enquête préliminaire visent à obtenir des estimations concernant:

1. Le coût du matériel et des logiciels pour la classe d'applications considérée.

2. Le coût si rien ne change (le système n'est pas développé).

3. Le coût d'une enquête complète sur les systèmes.

4. Les avantages sous forme de réduction des coûts ou de réduction des erreurs coûteuses.

Les estimations des coûts et des avantages de chaque projet permettent de déterminer les projets les plus dignes d’attention. Chaque estimation peut être analysée pour déterminer avec quelle rapidité les coûts sont recouvrés par les avantages, pour calculer à la fois les montants absolus et les intérêts ajustés en fonction des intérêts, et pour établir le rapport avantages / coûts.

Tous ces facteurs sont pris en compte lors de l'élaboration d'un sens global de la faisabilité économique du projet.

Pour être réalisable, une proposition de projet doit réussir tous ces tests. Sinon, ce n'est pas un projet réalisable. Par exemple, un système de gestion du personnel financièrement réalisable et attrayant du point de vue opérationnel n’est pas réalisable si la technologie nécessaire n’existe pas ou si un système médical pouvant être développé à un coût raisonnable, mais que les infirmières éviteront d’utiliser, ne peut pas être jugé réalisable du point de vue opérationnel.

Cycle de vie du développement du système Étape n ° 5. Plan de développement principal:

C'est une sorte de résumé de l'effort de développement du système. Dans une organisation dynamique, les applications de traitement informatique pouvant être traitées en même temps offrent davantage d'opportunités, ce qui nécessite un processus d'allocation. Ainsi, un plan directeur de développement est requis. C'est un calendrier de diverses applications à informatiser.

Un tel plan comprend quatre étapes:

1. L’analyste élabore les objectifs des efforts de développement des systèmes proposés.

2. Les capacités actuelles de l'organisation sont évaluées par l'analyste. Cette évaluation couvrira le matériel existant, les applications logicielles et les dépenses personnelles, l’utilisation des installations.

3. L'analyste examine les développements technologiques possibles dans le matériel informatique.

4. Enfin, l'analyste établit le plan spécifique, qui comprend un calendrier du matériel et des logiciels, un calendrier de développement des applications de maintenance et de conversion du logiciel, un plan des ressources en personnel et un plan des ressources financières.

Le plan directeur de développement est essentiellement un calendrier de diverses applications à informatiser, c’est-à-dire qu’il comprend les dates de début et de fin des activités d’analyse, de conception, de mise en œuvre et de maintenance des systèmes. Ce calendrier doit être pris en charge par le personnel, le matériel et les calendriers financiers.

Étape de cycle de vie du développement du système 6. Évaluation et sélection de l'équipement:

À ce stade, le service système peut contacter les fournisseurs d’équipements pour obtenir des informations et des prix concernant des machines spécifiques. Lorsque la proposition d'un système implique d'importants achats d'équipement, cette phase de développement du système peut être un projet majeur en soi.

Si les machines peuvent être achetées, louées ou louées à un prix qui reste dans les limites indiquées dans la proposition des systèmes, le projet continue tel que proposé, sinon l'analyste pourrait être contraint de revenir aux phases de faisabilité et de proposition des systèmes avec l'inattendu. données de coût.

Un bon analyste vérifiera toutefois les prix et les capacités de plusieurs fournisseurs lors de l’analyse de faisabilité afin de s’assurer que les prévisions de coûts sont raisonnables. Il tiendra compte non seulement du coût au moment de l’étude, mais aussi du prix le plus probable.

Cycle de vie du développement du système Étape # 7. Conception et développement du système:

La conception d'un système d'information produit les détails qui indiquent comment un système répondra aux exigences identifiées lors de l'analyse des systèmes. Souvent, les spécialistes, les systèmes, qualifient cette étape de conception logique, par opposition au développement d'un logiciel de programme appelé conception physique.

Dès que la proposition de système est acceptée par l'utilisateur, la préparation de la spécification du système peut commencer. Cette phase prend les exigences convenues et le travail qui a conduit à la production de la proposition et développe le système avec le niveau de détail nécessaire pour préparer la voie à la programmation.

À ce stade, l’analyste se préoccupe du détail des entrées et des sorties, du traitement requis et de la manière dont le système fonctionnera au quotidien.

En fonction du niveau de complexité du système, de la quantité et de la qualité du travail effectué aux premières étapes, cette phase peut nécessiter plusieurs mois de travail acharné.

Il concerne la conception informatique du système - le détail des transactions en entrée, le détail des rapports imprimés, des écrans et autres sorties, la structure du fichier ou de la base de données, le contenu des enregistrements, le traitement requis et l'efficacité le système du point de vue du traitement informatique.

Les analystes de système commencent par identifier les rapports et les autres sorties que le système produira. Ensuite, les données spécifiques à chaque objet sont identifiées, y compris son emplacement exact sur le papier, l’écran d’affichage ou un autre support. Habituellement, les concepteurs esquissent le formulaire ou l’affichage comme ils s’attendent à ce qu’il apparaisse à la fin du système.

La conception du système décrit également les données à saisir, à calculer ou à stocker. Les éléments de données individuels et les procédures de calcul sont écrits en détail. Les concepteurs sélectionnent les structures de fichiers et les périphériques de stockage, tels que les disques magnétiques, les bandes magnétiques ou même les fichiers papier. Les procédures écrites indiquent comment traiter les données et produire la sortie.

Les documents contenant les spécifications de conception utilisent différentes méthodes pour représenter la conception: graphiques, tableaux et symboles spéciaux. Les informations de conception détaillées sont transmises à l'équipe de programmation afin que le développement du logiciel puisse commencer.

Les concepteurs sont responsables de fournir aux programmeurs des spécifications complètes et clairement définies qui indiquent ce que le logiciel doit faire. Lorsque la programmation commence, les concepteurs sont disponibles pour répondre aux questions, clarifier les zones floues et gérer les problèmes auxquels les programmeurs sont confrontés lors de l'utilisation des spécifications de conception.

Une spécification système typique contiendra:

1. Une description des commandes qui fonctionnent dans le système. Cela inclut le contrôle de l'entrée et du traitement, les restrictions d'accès (par exemple, les mots de passe) et le contrôle de la sortie (par exemple, la numérotation des contrôles).

2. Un calendrier détaillé de développement et de mise en œuvre. Cette section doit répertorier toutes les tâches à effectuer, y compris les programmes individuels, en montrant l’interrelation entre chaque tâche et les données de début et d’achèvement prévues pour chaque tâche.

3. Un plan de sauvegarde: il devrait décrire les procédures à suivre pour effectuer des sauvegardes de sécurité des fichiers afin d'assurer la résilience du système (par exemple, le duplexage) et pour exécuter le système sur un autre site en cas de non disponibilité de l'ordinateur.

4. Une introduction couvrant la pertinence du document et son évolution par rapport aux phases précédentes.

5. Des descriptions détaillées des sorties et des fichiers d'entrée, par exemple: modèles de documents (entrée), modèles d'écran, modèles de rapports, modèles de fichiers / enregistrements, modèles de bases de données.

6. Une description du système. Il s’agit généralement d’une présentation sous forme narrative accompagnée d’organigrammes, de procédures, de diagrammes de flux de données ou de modèles de données.

7. Traitement requis. Cela peut en fait être traité en spécifiant généralement ce que chaque programme du système est censé faire et en sauvegardant avec les spécifications de programme individuelles publiées séparément. Les dispositions relatives aux tests peuvent également être décrites dans cette section.

8. Considérations relatives à la mise en œuvre: dispositions pour la conversion de fichiers existants, la vérification des exécutions en parallèle, la production de procédures utilisateur et la production de procédures informatiques.

C’est à ce stade que la première estimation fiable de l’effort de programmation nécessaire peut être produite. Jusqu'à présent, les estimations sont dans une large mesure des conjectures éclairées et ce qui sort à la fin de cet exercice peut être assez effrayant par rapport aux estimations précédemment disponibles.

C’est une raison valable pour s’assurer que la haute direction continue d’avoir un rôle d’approbation à la fin de cette étape.

Les estimations produites ont maintenant une base solide et s’ils sont sensiblement en contradiction avec les estimations initiales, il n’est pas encore trop tard pour examiner la viabilité du développement.

Le choix se situe maintenant entre.

1. Abandonner le système

2. Continuer comme prévu

3. Mise en veille du système pendant un certain temps

4. Modifier les aspirations du système.

Toutes ces options sont disponibles pour un développement interne, bien qu’il soit généralement estimé qu’au moment où ce stade est atteint, l’engagement est irréversible. Lorsqu'un fournisseur externe est impliqué, l'option peut être limitée par la nature du contrat entre les parties.

Un contrat à prix variable devrait fournir une formule de retrait dans de telles circonstances. Un arrangement à prix fixe protège les clients des prix à la hausse, mais une erreur d’estimation importante peut amener le fournisseur à couper le fil.

Cycle de vie du développement du système Étape n ° 8. Test du système:

Les tests de système ont pour objectif de s'assurer que tous les programmes fonctionnent comme prévu, que les programmes sont liés les uns aux autres pour répondre aux exigences spécifiées et que le système informatique, les procédures de bureau et les procédures connexes fonctionnent ensemble.

La phase initiale des tests du système incombe à l’analyste, qui détermine les conditions à tester, génère les données de test, produit un calendrier des résultats attendus, exécute les tests et compare les résultats produits par ordinateur aux résultats attendus.

L'analyste peut également être impliqué dans les tests de procédures. Lorsque l'analyste est convaincu que le système fonctionne correctement, il le transmet aux utilisateurs pour qu'il le teste. L'importance des tests du système par l'utilisateur doit être soulignée. En fin de compte, c'est l'utilisateur qui doit vérifier le système et donner le feu vert.

Lors des tests, le système est utilisé à titre expérimental pour garantir que le logiciel ne tombe pas en panne, c’est-à-dire qu’il fonctionnera conformément à ses spécifications et à la manière dont les utilisateurs s’attendent à ce qu’il fonctionne. Des données de test spéciales sont entrées pour le traitement (plan de test) et les résultats sont examinés pour localiser les résultats inattendus. Un nombre limité d'utilisateurs peut également être autorisé à utiliser le système. Les analystes peuvent ainsi savoir s'ils tentent de l'utiliser de manière inattendue.

Il est préférable de trouver ces surprises avant que l'organisation implémente le système et en dépende. Dans de nombreuses organisations, les tests sont effectués par des personnes autres que celles qui écrivent les programmes d'origine. Des personnes qui ne savent pas comment certaines parties ont été conçues ou programmées garantissent des tests plus complets et impartiaux et des logiciels plus fiables.

Cycle de vie du développement du système Étape n ° 9. Mise en œuvre du système:

Lorsque le système est testé, il commence à passer à la phase de mise en œuvre. Idéalement, le système devrait être terminé et entièrement testé avant la mise en œuvre, mais cela se produit rarement à moins qu'un package ne soit installé. Normalement, lorsque cela se produit, les parties du système nécessaires à la configuration des fichiers sont complétées en premier et ce processus est lancé.

Il peut également être nécessaire de disposer de programmes de conversion permettant d'utiliser les données d'un autre système lors de la configuration des fichiers. Une fois ces données configurées, elles doivent être tenues à jour et, par conséquent, le nouveau système est utilisé pour la première fois. Cela peut être suivi par une période de fonctionnement en parallèle, puis une décision est prise pour abandonner l'ancien système.

Dès que la première phase d'implémentation - la configuration des fichiers commence - démarre, toute la documentation du système devrait être disponible, à savoir. manuels de procédures du manuel d'utilisation, instructions d'utilisation de l'ordinateur et procédures de sécurité.

Le système passe ensuite du personnel de développement au personnel d’exploitation de l’ordinateur et, une fois celui-ci mis en service, des procédures strictes doivent être appliquées, qui régissent les programmeurs, l’accès aux programmes et aux fichiers. Des procédures doivent être établies pour contrôler toutes les demandes de modification du système et du programme, de la demande de l'utilisateur à la mise en œuvre par le programmeur.

La mise en œuvre implique de placer le système matériel et logiciel terminé et testé dans l'environnement de travail réel des utilisateurs. Lorsque le personnel système vérifie et met en service le nouveau matériel, forme le personnel utilisateur, installe la nouvelle application et crée tous les fichiers de données nécessaires à son utilisation, nous disons qu'il est implémenté.

Il existe à la fois des activités techniques et des activités axées sur les personnes. Des exemples d'activités techniques incluent la conversion de fichiers de données, le remplacement d'anciens programmes par de nouveaux et la planification d'opérations informatiques. Des exemples d'activités axées sur les personnes comprennent l'orientation, la formation et le soutien.

Cycle de vie du développement du système, étape n ° 10. Examen et suivi du système:

La dernière phase du processus de développement ou de mise en œuvre est la révision du système ou «post-audit», comme on l'appelle parfois. Ceci est généralement effectué par un groupe composé d'un représentant du service utilisateur, de l'audit interne et du traitement des données. Son objectif fondamental est de voir si le système a atteint les objectifs qui lui étaient assignés.

Cela comprendra une comparaison des coûts et avantages réels par rapport aux estimations initiales, un examen des performances générales du système, un examen des demandes de modification et un examen de la documentation, des procédures de contrôle et de sécurité et des dispositifs de sauvegarde.

L'étape de révision examine comment le processus du système a été mis au point.

Les deux questions principales suivantes sont posées:

1. Les systèmes eux-mêmes sont-ils appropriés?

2. Le système a-t-il été développé correctement?

Pour décider, si le système lui-même est approprié, l'utilisateur doit être consulté pour savoir si le système fournit les informations dont il a besoin, sous la forme appropriée. Pour déterminer si le système a été développé correctement, les réviseurs peuvent vérifier dans quelle mesure le système fonctionne correctement, combien de temps le programmeur et l'analyste ont consacré à son développement et si le développement du système a été achevé dans les délais.

Fait intéressant, cela pourrait marquer le début d’un autre projet. Les carences du système entraînent un autre cycle de vie, les examinateurs se demandant: «Les changements en valent-ils la peine? À quoi devraient-ils ressembler? Comment devraient-ils être fabriqués, programmés et mis en œuvre? Ont-ils été fait correctement? "