Quelles sont les différentes phases du cycle de développement des systèmes ?
Cycle de vie du développement des systèmes

Article
Parler
Lire
Modifier
Voir l'historique

Outils
De Wikipedia, l'encyclopédie libre
Cet article est consacré au cycle de vie du développement des systèmes. Pour le protocole de communication informatique d'IBM, voir Synchronous Data Link Control.

Modèle du cycle de vie du développement logiciel, mettant en évidence la phase de maintenance
En ingénierie des systèmes, des systèmes d'information et des logiciels, le cycle de vie de développement des systèmes (SDLC), également appelé cycle de vie de développement des applications, est un processus de planification, de création, de test et de déploiement d'un système d'information. Le concept de SDLC s'applique à une série de configurations matérielles et logicielles, car un système peut être composé uniquement de matériel, uniquement de logiciel ou d'une combinaison des deux. Ce cycle comprend généralement six étapes : l'analyse des besoins, la conception, le développement et les tests, la mise en œuvre, la documentation et l'évaluation.

Vue d'ensemble
Le cycle de vie du développement de systèmes est composé de phases de travail distinctes utilisées par les ingénieurs et les développeurs de systèmes pour fournir des systèmes d'information. Comme tout ce qui est fabriqué sur une chaîne de montage, un cycle de développement de systèmes vise à produire des systèmes de haute qualité qui répondent ou dépassent les attentes, sur la base des exigences, en livrant les systèmes dans les délais prévus et les estimations de coûts. Les systèmes informatiques sont complexes et relient souvent des composants d'origines diverses. Diverses méthodologies de SDLC ont été créées, telles que la chute d'eau, la spirale, l'agile, le prototypage rapide, l'incrémental et la synchronisation et la stabilisation.

Les méthodologies du SDLC s'inscrivent dans un spectre de flexibilité allant de l'agile à l'itératif en passant par le séquentiel. Les méthodologies agiles, telles que XP et Scrum, se concentrent sur des processus légers qui permettent des changements rapides. Les méthodologies itératives, telles que le processus unifié rationnel et la méthode de développement de systèmes dynamiques, se concentrent sur la stabilisation de la portée du projet et sur l'expansion ou l'amélioration itérative des produits. Les modèles séquentiels ou BDUF (big-design-up-front), tels que la cascade, se concentrent sur une planification complète et correcte pour guider des projets plus importants et limiter les risques afin d'obtenir des résultats réussis et prévisibles[citation nécessaire]. Le développement anamorphique est guidé par la portée du projet et par des itérations adaptatives.

Dans la gestion de projet, un projet peut inclure à la fois un cycle de vie de projet (PLC) et un SDLC, au cours desquels des activités quelque peu différentes ont lieu. Selon Taylor (2004), "le cycle de vie du projet englobe toutes les activités du projet, tandis que le cycle de vie du développement des systèmes se concentre sur la réalisation des exigences du produit".

Le SDLC n'est pas une méthodologie en soi, mais plutôt une description des phases qu'une méthodologie devrait aborder. La liste des phases n'est pas définitive, mais elle comprend généralement la planification, l'analyse, la conception, la construction, le test, la mise en œuvre et la maintenance/assistance. Dans le cadre de Scrum, par exemple, on peut dire qu'une seule histoire d'utilisateur passe par toutes les phases du cycle de développement durable au cours d'un sprint de deux semaines. Par opposition à la méthodologie en cascade, où chaque exigence commerciale[citation nécessaire] est traduite en descriptions de caractéristiques/fonctions qui sont ensuite toutes mises en œuvre sur une période de plusieurs mois ou plus[citation nécessaire].

Historique
Selon Elliott, Strachan et Radford (2004), le SDLC "a vu le jour dans les années 1960, pour développer des systèmes d'entreprise fonctionnels à grande échelle à l'époque des grands conglomérats d'entreprises. Les activités liées aux systèmes d'information tournaient autour du traitement de données lourdes et des routines de calcul".

La méthode d'analyse et de conception de systèmes structurés (SSADM) a été élaborée pour l'Office of Government Commerce du gouvernement britannique dans les années 1980. Depuis lors, selon Elliott (2004), "les approches traditionnelles du cycle de vie du développement de systèmes ont été de plus en plus remplacées par des approches et des cadres alternatifs, qui ont tenté de surmonter certaines des déficiences inhérentes au SDLC traditionnel".

Les modèles

Version en dix phases du cycle de développement des systèmes
Le SDLC fournit un ensemble de phases/étapes/activités à suivre par les concepteurs et développeurs de systèmes. Chaque phase s'appuie sur les résultats de la précédente Tous les projets n'exigent pas que les phases soient séquentielles. Pour les projets plus petits et plus simples, les phases peuvent être combinées ou se chevaucher.

Chute d'eau
Le modèle le plus ancien et le plus connu est le modèle en cascade, qui utilise une séquence linéaire d'étapes. Le modèle en cascade se décline en plusieurs variantes. L'une d'entre elles est la suivante :

Analyse préliminaire
Effectuer une analyse préliminaire, envisager des solutions alternatives, estimer les coûts et les bénéfices, et soumettre un plan préliminaire avec des recommandations.

Effectuer une analyse préliminaire : Identifier les objectifs de l'organisation et définir la nature et la portée du projet. S'assurer que le projet est en adéquation avec les objectifs.
Envisager des solutions alternatives : Les solutions alternatives peuvent provenir d'entretiens avec les employés, les clients, les fournisseurs et les consultants, ainsi que d'une analyse de la concurrence.
Analyse coûts-avantages : Analyser les coûts et les avantages du projet.
Analyse des systèmes, définition des exigences
Décomposer les objectifs du projet[clarification nécessaire] en fonctions et opérations définies. Cela implique de rassembler et d'interpréter les faits, de diagnostiquer les problèmes et de recommander des changements. Analyser les besoins d'information de l'utilisateur final et résoudre les incohérences et les lacunes.

Recueillir les faits : Obtenir les besoins de l'utilisateur final par l'examen de documents, des entretiens avec les clients, des observations et des questionnaires.
Examiner le(s) système(s) existant(s) : Identifier les avantages et les inconvénients.
Analyser le système proposé : Trouver des solutions aux problèmes et préparer les spécifications, en incorporant les propositions appropriées des utilisateurs.
Conception des systèmes
À cette étape, les fonctionnalités et les opérations souhaitées sont détaillées, y compris les présentations d'écran, les règles de gestion, les diagrammes de processus, le pseudocode et d'autres éléments livrables.

Développement
Écrire le code.

Intégration et tests
Assembler les modules dans un environnement de test. Vérifier les erreurs, les bogues et l'interopérabilité.

Acceptation, installation, déploiement
Mettre le système en production. Cela peut impliquer la formation des utilisateurs, le déploiement du matériel et le chargement des informations du système précédent.

Maintenance
Surveiller le système afin d'en évaluer l'adéquation permanente. Apporter des modifications et des corrections modestes si nécessaire.

Évaluation
Le système et le processus sont examinés. Les questions pertinentes consistent à savoir si le système nouvellement mis en œuvre répond aux exigences et atteint les objectifs du projet, si le système est utilisable, fiable/disponible, correctement dimensionné et tolérant aux pannes. Les vérifications du processus comprennent l'examen des délais et des dépenses, ainsi que l'acceptation par les utilisateurs.

Élimination
À la fin de la durée de vie du système, des plans sont élaborés pour l'arrêter et passer à son remplacement. Les informations et l'infrastructure correspondantes doivent être réutilisées, archivées, mises au rebut ou détruites, tout en protégeant la sécurité de manière appropriée.

Dans le diagramme suivant, ces étapes de la fin de vie sont divisées en dix étapes, de la définition à la création et à la modification des produits de travail informatiques :

Analyse et conception des systèmes
L'analyse et la conception des systèmes (ACS) peuvent être considérées comme une activité de méta-développement, qui sert à préparer le terrain et à délimiter le problème. L'analyse et la conception de systèmes peuvent aider à équilibrer des exigences de haut niveau concurrentes. L'ASD interagit avec l'architecture d'entreprise distribuée, l'architecture informatique d'entreprise et l'architecture d'entreprise, et s'appuie fortement sur des concepts tels que le cloisonnement, les interfaces, les personnes et les rôles, et la modélisation du déploiement/de l'exploitation pour parvenir à une description du système de haut niveau. Cette description de haut niveau est ensuite décomposée en composants et modules qui peuvent être analysés, conçus et construits séparément et intégrés pour atteindre l'objectif de l'entreprise. Le SDLC et le SAD sont les pierres angulaires de la planification du cycle de vie complet du produit et du système.

Analyse et conception orientées objet
L'analyse et la conception orientées objet (OOAD) est le processus d'analyse d'un domaine problématique afin de développer un modèle conceptuel qui peut ensuite être utilisé pour guider le développement. Au cours de la phase d'analyse, un programmeur élabore des exigences écrites et un document de vision formel par le biais d'entretiens avec les parties prenantes.

Le modèle conceptuel qui résulte de l'OOAD se compose généralement de cas d'utilisation et de diagrammes de classes et d'interactions. Il peut également inclure une maquette d'interface utilisateur.

Un artefact de sortie n'a pas besoin d'être complètement défini pour servir d'entrée à la conception orientée objet ; l'analyse et la conception peuvent se dérouler en parallèle. En pratique, les résultats d'une activité peuvent alimenter l'autre dans un processus itératif.

Quelques artefacts d'entrée typiques pour la conception orientée objet :

Modèle conceptuel : Un modèle conceptuel est le résultat d'une analyse orientée objet. Il capture les concepts du domaine du problème. Le modèle conceptuel est explicitement indépendant des détails de l'implémentation.
Cas d'utilisation : Un cas d'utilisation est une description des séquences d'événements qui, ensemble, accomplissent une tâche requise. Chaque cas d'utilisation fournit des scénarios qui indiquent comment le système doit interagir avec les acteurs (utilisateurs). Les acteurs peuvent être des utilisateurs finaux ou d'autres systèmes. Les cas d'utilisation peuvent être élaborés à l'aide de diagrammes. Ces diagrammes identifient l'acteur et les processus qu'il exécute.
Diagramme de séquence du système : Un diagramme de séquence du système (SSD) est une image qui montre, pour un cas d'utilisation particulier, les événements que les acteurs génèrent, leur ordre, y compris les événements inter-systèmes.
Document d'interface utilisateur : Document qui montre et décrit l'interface utilisateur.
Modèle de données : Un modèle de données décrit comment les éléments de données sont liés les uns aux autres. Le modèle de données est créé avant la phase de conception. Les conceptions orientées objet s'appuient directement sur le modèle de données. Les conceptions relationnelles sont plus complexes.
Cycle de vie du système
Le cycle de vie d'un système est une vision d'un système ou d'un projet de système qui aborde toutes les phases de son existence, à savoir la conception du système, la conception et le développement, la production et/ou la construction, la distribution, l'exploitation, la maintenance et le soutien, le retrait, l'élimination progressive et la mise au rebut.

L'étude conceptuelle
La phase de conception est l'étape au cours de laquelle un besoin identifié est examiné, les exigences des solutions potentielles sont définies, les solutions potentielles sont évaluées et une spécification du système est élaborée. La spécification du système représente les exigences techniques qui fourniront une orientation générale pour la conception du système. Étant donné que ce document détermine tous les développements futurs, l'étape ne peut pas être achevée tant qu'une revue de la conception n'a pas déterminé que la spécification du système répond correctement au besoin motivant.

Les étapes clés de la phase de conception sont les suivantes :

Identification du besoin
l'analyse de faisabilité
Analyse des exigences du système
Spécification du système
Examen de l'étude conceptuelle
Conception préliminaire du système
Au cours de cette étape du cycle de vie du système, les sous-systèmes qui exécutent les fonctions souhaitées du système sont conçus et spécifiés conformément à la spécification du système. Les interfaces entre les sous-systèmes sont définies, de même que les exigences globales en matière de test et d'évaluation. À l'issue de cette étape, une spécification de développement suffisante pour réaliser la conception et le développement détaillés est produite.

Les étapes clés de la phase de conception préliminaire sont les suivantes

l'analyse fonctionnelle
l'attribution des exigences
Études détaillées des compromis
Synthèse des options du système
Conception préliminaire de modèles d'ingénierie
Spécification de développement
Examen de la conception préliminaire
Par exemple, en tant qu'analyste système de la Viti Bank, tu as été chargé d'examiner le système d'information actuel. La Viti Bank est une banque à croissance rapide aux Fidji. Les clients des zones rurales éloignées éprouvent des difficultés à accéder aux services de la banque. Il leur faut des jours, voire des semaines, pour se rendre dans une localité afin d'accéder aux services bancaires. Dans le but de répondre aux besoins des clients, la banque a demandé à ses services d'examiner le système actuel et de proposer des solutions ou des recommandations sur la manière dont le système actuel peut être amélioré pour répondre à ses besoins.

Conception détaillée et développement
Cette étape comprend le développement de conceptions détaillées qui transforment le travail de conception initial en une forme achevée de spécifications. Ce travail comprend la spécification des interfaces entre le système et son environnement prévu, ainsi qu'une évaluation complète des exigences en matière de logistique, de maintenance et de soutien des systèmes. La conception détaillée et le développement sont responsables de la production des spécifications du produit, du processus et du matériel et peuvent entraîner des modifications substantielles de la spécification de développement.

Les étapes clés de la phase de conception et de développement détaillés sont les suivantes :

la conception détaillée
Synthèse détaillée
Développement de modèles d'ingénierie et de prototypes
Révision des spécifications de développement
Spécification du produit, du processus et des matériaux
Examen critique de la conception
Production et construction
Au cours de la phase de production et/ou de construction, le produit est construit ou assemblé conformément aux exigences spécifiées dans les spécifications du produit, du processus et des matériaux, et il est déployé et testé dans l'environnement opérationnel cible. Des évaluations du système sont effectuées afin de corriger les lacunes et d'adapter le système en vue d'une amélioration continue.

Les principales étapes de la construction du produit sont les suivantes

la production et/ou la construction des composants du système
les essais d'acceptation
la distribution et l'exploitation du système
les essais opérationnels et l'évaluation
Évaluation du système
Utilisation et soutien
Une fois entièrement déployé, le système est utilisé pour le rôle opérationnel prévu et maintenu dans son environnement opérationnel.

Les étapes clés de la phase d'utilisation et de soutien sont les suivantes :

Fonctionnement du système dans l'environnement de l'utilisateur
la gestion des changements
les modifications du système en vue de son amélioration
l'évaluation du système
Retrait progressif et mise au rebut
L'efficacité et l'efficience du système doivent être évaluées en permanence afin de déterminer quand le produit a atteint son cycle de vie maximal : L'existence continue d'un besoin opérationnel, l'adéquation entre les exigences opérationnelles et les performances du système, la faisabilité de l'élimination progressive du système par rapport à sa maintenance, et la disponibilité de systèmes alternatifs.

Phases

Cette section comprend une liste de références, de lectures connexes ou de liens externes, mais ses sources ne sont pas claires en raison de l'absence de citations en ligne. Merci de contribuer à l'amélioration de cette section en introduisant des citations plus précises. (janvier 2023) (Apprendre quand et comment supprimer ce modèle de message)
Enquête sur le système
Au cours de cette étape, les priorités actuelles qui seraient affectées et la manière dont elles devraient être traitées sont examinées. Une étude de faisabilité permet de déterminer si la création d'un nouveau système ou l'amélioration d'un système existant est appropriée. Elle permet d'estimer les coûts, les avantages, les besoins en ressources et les besoins spécifiques des utilisateurs.

L'étude de faisabilité doit aborder les questions opérationnelles, financières, techniques, humaines et juridiques/politiques.

L'analyse
L'objectif de l'analyse est de déterminer où se situe le problème. Cette étape consiste à décomposer le système en plusieurs parties, à analyser les objectifs du projet, à décomposer ce qui doit être créé et à faire participer les utilisateurs à la définition des exigences.

Conception
Lors de la conception des systèmes, les fonctions et les opérations sont décrites en détail, y compris les présentations d'écran, les règles de gestion, les diagrammes de processus et d'autres documents. La conception modulaire réduit la complexité et permet de décrire le système comme un ensemble de sous-systèmes.

La phase de conception prend comme point de départ les exigences déjà définies. Pour chaque exigence, un ensemble d'éléments de conception est produit.

Les documents de conception comprennent généralement des diagrammes de hiérarchie fonctionnelle, des présentations d'écran, des règles de gestion, des diagrammes de processus, du pseudo-code et un modèle de données complet avec un dictionnaire de données. Ces éléments décrivent le système de manière suffisamment détaillée pour que les développeurs et les ingénieurs puissent développer et fournir le système avec un minimum de données supplémentaires.

Les tests
Le code est testé à différents niveaux dans le cadre des essais de logiciels. Des tests unitaires, des tests de système et des tests d'acceptation par l'utilisateur sont généralement effectués. De nombreuses approches des tests ont été adoptées.

Les types de tests suivants peuvent être pertinents :

Tests de cheminement
Tests d'ensembles de données
Tests d'unités
Tests de système
Tests d'intégration
Tests boîte noire
Tests boîte blanche
Tests de régression
Tests d'automatisation
Tests d'acceptation par l'utilisateur
Tests de performance des logiciels
Formation et transition
Une fois qu'un système a été stabilisé par des tests, le SDLC veille à ce qu'une formation adéquate soit préparée et dispensée avant de transférer le système au personnel d'assistance et aux utilisateurs finaux. La formation couvre généralement la formation opérationnelle du personnel d'assistance et la formation des utilisateurs finaux.

Après la formation, les ingénieurs systèmes et les développeurs transfèrent le système dans son environnement de production.

Opérations et maintenance
La maintenance comprend les changements, les corrections et les améliorations.

L'évaluation
La dernière phase du cycle de développement durable consiste à mesurer l'efficacité du système et à évaluer les améliorations potentielles.

Cycle de vie
Gestion et contrôle

Phases du cycle de développement durable liées aux contrôles de gestion
Les objectifs des phases du SDLC sont décrits dans cette section avec les principaux produits à livrer, une description des tâches recommandées et un résumé des objectifs de contrôle connexes pour une gestion efficace. Il est essentiel que le gestionnaire de projet établisse et surveille les objectifs de contrôle pendant l'exécution des projets. Les objectifs de contrôle sont des énoncés clairs du résultat ou du but souhaité et doivent être définis et suivis tout au long du projet. Les objectifs de contrôle peuvent être regroupés en grandes catégories (domaines) et se rapportent aux phases du cycle de développement durable, comme le montre la figure.

Pour gérer et contrôler une initiative importante du cycle de développement durable, une structure de répartition du travail (SRT) permet de saisir et de programmer le travail. La structure de répartition du travail et tout le matériel programmatique doivent être conservés dans la section " description du projet " du carnet de projet[clarification nécessaire]. Le chef de projet choisit le format de structure de répartition du travail qui décrit le mieux le projet.

Le diagramme montre que la couverture s'étend sur de nombreuses phases du SDLC, mais le MCD[clarification nécessaire] associé montre les correspondances avec les phases du SDLC. Par exemple, l'analyse et la conception sont principalement réalisées dans le cadre du domaine de l'acquisition et de la mise en œuvre, et la construction et le prototypage du système sont principalement réalisés dans le cadre de la livraison et du soutien.

Organisation structurée de la répartition du travail

Structure de répartition du travail
La partie supérieure de la structure de répartition du travail donne un aperçu de la portée et du calendrier du projet. Elle doit également résumer les principales phases et étapes. La partie centrale est basée sur les phases du SDLC. Les éléments de l'OTP consistent en des jalons et des tâches à accomplir plutôt qu'en des activités à entreprendre et assorties d'une date limite. Chaque tâche a un résultat mesurable (par exemple, un document d'analyse). Une tâche de l'OTP peut s'appuyer sur une ou plusieurs activités (par exemple, le codage). Les parties du projet nécessitant le soutien de contractants doivent faire l'objet d'un cahier des charges. L'élaboration d'un cahier des charges n'a pas lieu au cours d'une phase spécifique du SDLC, mais est développée pour inclure le travail du processus SDLC qui peut être effectué par des sous-traitants.

Lignes de base
Les lignes de base[clarification nécessaire] sont établies après quatre des cinq phases du SDLC et sont essentielles à la nature itérative du modèle. Les lignes de base deviennent des jalons.

ligne de base fonctionnelle : établie après la phase de conception.
ligne de base attribuée : établie après la phase de conception préliminaire
Base de référence du produit : établie après la phase de conception détaillée et de développement.
base actualisée du produit : établie après la phase de construction de la production.
Le cycle de vie du développement des systèmes comporte sept phases. Il s'agit de l'étude du système, de l'analyse, de la conception, des essais, de la formation et de la transition, de l'exploitation et de la maintenance, et de l'évaluation.
What are the different phases in systems development life cycle?
Systems development life cycle

Article
Talk
Read
Edit
View history

Tools
From Wikipedia, the free encyclopedia
This article is about systems development life cycle. For the IBM's computer communication protocol, see Synchronous Data Link Control.

Model of the software development life cycle, highlighting the maintenance phase
In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system.[1] The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both.[2] There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Overview
A systems development life cycle is composed of distinct work phases that are used by systems engineers and systems developers to deliver information systems. Like anything that is manufactured on an assembly line, an SDLC aims to produce high-quality systems that meet or exceed expectations, based on requirements, by delivering systems within scheduled time frames and cost estimates.[3] Computer systems are complex and often link components with varying origins. Various SDLC methodologies have been created, such as waterfall, spiral, agile, rapid prototyping, incremental, and synchronize and stabilize.[4]

SDLC methodologies fit within a flexibility spectrum ranging from agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on lightweight processes that allow for rapid changes.[5] Iterative methodologies, such as Rational Unified Process and dynamic systems development method, focus on stabilizing project scope and iteratively expanding or improving products. Sequential or big-design-up-front (BDUF) models, such as waterfall, focus on complete and correct planning to guide larger projects and limit risks to successful and predictable results.[citation needed] Anamorphic development is guided by project scope and adaptive iterations.

In project management a project can include both a project life cycle (PLC) and an SDLC, during which somewhat different activities occur. According to Taylor (2004), "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".[6]

SDLC is not a methodology per se, but rather a description of the phases that a methodology should address. The list of phases is not definitive, but typically includes planning, analysis, design, build, test, implement, and maintenance/support. In the Scrum framework,[7] for example, one could say a single user story goes through all the phases of the SDLC within a two-week sprint. By contrast the waterfall methodology, where every business requirement[citation needed] is translated into feature/functional descriptions which are then all implemented typically over a period of months or longer.[citation needed]

History
According to Elliott & Strachan & Radford (2004), SDLC "originated in the 1960s, to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines".[8]

The structured systems analysis and design method (SSADM) was produced for the UK government Office of Government Commerce in the 1980s. Ever since, according to Elliott (2004), "the traditional life cycle approaches to systems development have been increasingly replaced with alternative approaches and frameworks, which attempted to overcome some of the inherent deficiencies of the traditional SDLC".[8]

Models

A ten-phase version of the systems development life cycle[9]
SDLC provides a set of phases/steps/activities for system designers and developers to follow. Each phase builds on the results of the previous one.[9][10][11][12] Not every project requires that the phases be sequential. For smaller, simpler projects, phases may be combined/overlap.[9]

Waterfall
The oldest and best known is the waterfall model, which uses a linear sequence of steps.[10] Waterfall has different varieties. One variety is as follows:[9][10][13][14]

Preliminary analysis
Conduct with a preliminary analysis, consider alternative solutions, estimate costs and benefits, and submit a preliminary plan with recommendations.

Conduct preliminary analysis: Identify the organization's objectives and define the nature and scope of the project. Ensure that the project fits with the objectives.
Consider alternative solutions: Alternatives may come from interviewing employees, clients, suppliers, and consultants, as well as competitive analysis.
Cost-benefit analysis: Analyze the costs and benefits of the project.
Systems analysis, requirements definition
Decompose project goals[clarification needed] into defined functions and operations. This involves gathering and interpreting facts, diagnosing problems, and recommending changes. Analyze end-user information needs and resolve inconsistencies and incompleteness:[15]

Collect facts: Obtain end-user requirements by document review, client interviews, observation, and questionnaires.
Scrutinize existing system(s): Identify pros and cons.
Analyze the proposed system: Find solutions to issues and prepare specifications, incorporating appropriate user proposals.
Systems design
At this step, desired features and operations are detailed, including screen layouts, business rules, process diagrams, pseudocode, and other deliverables.

Development
Write the code.

Integration and testing
Assemble the modules in a testing environment. Check for errors, bugs, and interoperability.

Acceptance, installation, deployment
Put the system into production. This may involve training users, deploying hardware, and loading information from the prior system.

Maintenance
Monitor the system to assess its ongoing fitness. Make modest changes and fixes as needed.

Evaluation
The system and the process are reviewed. Relevant questions include whether the newly implemented system meets requirements and achieves project goals, whether the system is usable, reliable/available, properly scaled and fault-tolerant. Process checks include review of timelines and expenses, as well as user acceptance.

Disposal
At end of life, plans are developed for discontinuing the system and transitioning to its replacement. Related information and infrastructure must be repurposed, archived, discarded, or destroyed, while appropriately protecting security.[16]

In the following diagram, these stages of the are divided into ten steps, from definition to creation and modification of IT work products:

Systems analysis and design
Systems analysis and design (SAD) can be considered a meta-development activity, which serves to set the stage and bound the problem. SAD can help balance competing high-level requirements. SAD interacts with distributed enterprise architecture, enterprise I.T. Architecture, and business architecture, and relies heavily on concepts such as partitioning, interfaces, personae and roles, and deployment/operational modeling to arrive at a high-level system description. This high-level description is then broken down into the components and modules which can be analyzed, designed, and constructed separately and integrated to accomplish the business goal. SDLC and SAD are cornerstones of full life cycle product and system planning.

Object-oriented analysis and design
Object-oriented analysis and design (OOAD) is the process of analyzing a problem domain to develop a conceptual model that can then be used to guide development. During the analysis phase, a programmer develops written requirements and a formal vision document via interviews with stakeholders.

The conceptual model that results from OOAD typically consists of use cases, and class and interaction diagrams. It may also include a user interface mock-up.

An output artifact does not need to be completely defined to serve as input of object-oriented design; analysis and design may occur in parallel. In practice the results of one activity can feed the other in an iterative process.

Some typical input artifacts for OOAD:

Conceptual model: A conceptual model is the result of object-oriented analysis. It captures concepts in the problem domain. The conceptual model is explicitly independent of implementation details.
Use cases: A use case is a description of sequences of events that, taken together, complete a required task. Each use case provides scenarios that convey how the system should interact with actors (users). Actors may be end users or other systems. Use cases may further elaborated using diagrams. Such diagrams identify the actor and the processes they perform.
System Sequence Diagram: A System Sequence diagrams (SSD) is a picture that shows, for a particular use case, the events that actors generate, their order, including inter-system events.
User interface document: Document that shows and describes the user interface.
Data model: A data model describes how data elements relate to each other. The data model is created before the design phase. Object-oriented designs map directly from the data model. Relational designs are more involved.
System lifecycle
The system lifecycle is a view of a system or proposed system that addresses all phases of its existence to include system conception, design and development, production and/or construction, distribution, operation, maintenance and support, retirement, phase-out, and disposal.[17]

Conceptual design
The conceptual design stage is the stage where an identified need is examined, requirements for potential solutions are defined, potential solutions are evaluated, and a system specification is developed. The system specification represents the technical requirements that will provide overall guidance for system design. Because this document determines all future development, the stage cannot be completed until a conceptual design review has determined that the system specification properly addresses the motivating need.

Key steps within the conceptual design stage include:

Need identification
Feasibility analysis
System requirements analysis
System specification
Conceptual design review
Preliminary system design
During this stage of the system lifecycle, subsystems that perform the desired system functions are designed and specified in compliance with the system specification. Interfaces between subsystems are defined, as well as overall test and evaluation requirements.[18] At the completion of this stage, a development specification is produced that is sufficient to perform detailed design and development.

Key steps within the preliminary design stage include:

Functional analysis
Requirements allocation
Detailed trade-off studies
Synthesis of system options
Preliminary design of engineering models
Development specification
Preliminary design review
For example, as the system analyst of Viti Bank, you have been tasked to examine the current information system. Viti Bank is a fast-growing bank in Fiji. Customers in remote rural areas are finding difficulty to access the bank services. It takes them days or even weeks to travel to a location to access the bank services. With the vision of meeting the customers' needs, the bank has requested your services to examine the current system and to come up with solutions or recommendations of how the current system can be provided to meet its needs.

Detail design and development
This stage includes the development of detailed designs that brings initial design work into a completed form of specifications. This work includes the specification of interfaces between the system and its intended environment, and a comprehensive evaluation of the systems logistical, maintenance and support requirements. The detail design and development is responsible for producing the product, process and material specifications and may result in substantial changes to the development specification.

Key steps within the detail design and development stage include:

Detailed design
Detailed synthesis
Development of engineering and prototype models
Revision of development specification
Product, process, and material specification
Critical design review
Production and construction
During the production and/or construction stage the product is built or assembled in accordance with the requirements specified in the product, process and material specifications, and is deployed and tested within the operational target environment. System assessments are conducted in order to correct deficiencies and adapt the system for continued improvement.

Key steps within the product construction stage include:

Production and/or construction of system components
Acceptance testing
System distribution and operation
Operational testing and evaluation
System assessment
Utilization and support
Once fully deployed, the system is used for its intended operational role and maintained within its operational environment.

Key steps within the utilization and support stage include:

System operation in the user environment
Change management
System modifications for improvement
System assessment
Phase-out and disposal
Effectiveness and efficiency of the system must be continuously evaluated to determine when the product has met its maximum effective lifecycle.[19] Considerations include: Continued existence of operational need, matching between operational requirements and system performance, feasibility of system phase-out versus maintenance, and availability of alternative systems.

Phases

This section includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help to improve this section by introducing more precise citations. (January 2023) (Learn how and when to remove this template message)
System investigation
During this step, current priorities that would be affected and how they should be handled are considered. A feasibility study determines whether creating a new or improved system is appropriate. This helps to estimate costs, benefits, resource requirements, and specific user needs.

The feasibility study should address operational, financial, technical, human factors, and legal/political concerns.

Analysis
The goal of analysis is to determine where the problem is. This step involves decomposing the system into pieces, analyzing project goals, breaking down what needs to be created, and engaging users to define requirements.

Design
In systems design, functions and operations are described in detail, including screen layouts, business rules, process diagrams, and other documentation. Modular design reduces complexity and allows the outputs to describe the system as a collection of subsystems.

The design stage takes as its input the requirements already defined. For each requirement, a set of design elements is produced.

Design documents typically include functional hierarchy diagrams, screen layouts, business rules, process diagrams, pseudo-code, and a complete data model with a data dictionary. These elements describe the system in sufficient detail that developers and engineers can develop and deliver the system with minimal additional input.

Testing
The code is tested at various levels in software testing. Unit, system, and user acceptance tests are typically performed. Many approaches to testing have been adopted.

The following types of testing may be relevant:

Path testing
Data set testing
Unit testing
System testing
Integration testing
Black-box testing
White-box testing
Regression testing
Automation testing
User acceptance testing
Software performance testing
Training and transition
Once a system has been stabilized through testing, SDLC ensures that proper training is prepared and performed before transitioning the system to support staff and end users. Training usually covers operational training for support staff as well as end-user training.

After training, systems engineers and developers transition the system to its production environment.

Operations and maintenance
Maintenance includes changes, fixes, and enhancements.

Evaluation
The final phase of the SDLC is to measure the effectiveness of the system and evaluate potential enhancements.

Life cycle
Management and control

SDLC phases related to management controls[20]
SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives while executing projects. Control objectives are clear statements of the desired result or purpose and should be defined and monitored throughout a project. Control objectives can be grouped into major categories (domains), and relate to the SDLC phases as shown in the figure.[20]

To manage and control a substantial SDLC initiative, a work breakdown structure (WBS) captures and schedules the work. The WBS and all programmatic material should be kept in the "project description" section of the project notebook.[clarification needed] The project manager chooses a WBS format that best describes the project.

The diagram shows that coverage spans numerous phases of the SDLC but the associated MCD[clarification needed] shows mappings to SDLC phases. For example, Analysis and Design is primarily performed as part of the Acquisition and Implementation Domain, and System Build and Prototype is primarily performed as part of delivery and support.[20]

Work breakdown structured organization

Work breakdown structure[20]
The upper section of the WBS provides an overview of the project scope and timeline. It should also summarize the major phases and milestones. The middle section is based on the SDLC phases. WBS elements consist of milestones and tasks to be completed rather than activities to be undertaken and have a deadline. Each task has a measurable output (e.g., analysis document). A WBS task may rely on one or more activities (e.g. coding). Parts of the project needing support from contractors should have a statement of work (SOW). The development of a SOW does not occur during a specific phase of SDLC but is developed to include the work from the SDLC process that may be conducted by contractors.[20]

Baselines
Baselines[clarification needed] are established after four of the five phases of the SDLC, and are critical to the iterative nature of the model.[21] Baselines become milestones.

functional baseline: established after the conceptual design phase.
allocated baseline: established after the preliminary design phase.
product baseline: established after the detail design and development phase.
updated product baseline: established after the production construction phase.
There are 7 phases in systems development life cycle. They are system investigation, Analysis, Design, Testing, Training and transition, Operations and maintenance and Evaluation