Quels sont les Documents dans le SDLC?

La réponse est - comme cela a été dit - elle dépend. Je suis sûr que beaucoup de gens vont répondre pour les méthodologies Agiles (qui sont beaucoup plus mobile fête) donc pour l'exhaustivité, je vais aller avec ce que vous auriez pour un assez standard cascade méthodologie:

• Un document sur le cadre de - très haut niveau décrivant ce qu'est et surtout ce n'est pas dans la portée du projet et quelles sont les hypothèses sont formulées. Le but principal de ce document est de définir les attentes de ce qui sera finalement livré - vous ne dites pas comment les choses vont travailler, mais vous êtes en essayant de répondre à des questions telles que sera-t-il un rapport? Passer des données à d'autres systèmes? Vous devez écrire votre propre fonction de gestion des utilisateurs ou de tirer à partir d'AD? Où vous ne pouvez pas obtenir de réponses définitives à ces choses, alors inclure une section hypothèses et la liste de ce que vous êtes en supposant que ce sera le cas, donc les gens peuvent vous corriger si vous vous trompez. Elle devrait également inclure des choses comme cible dates de mise en œuvre (et non comme un engagement, mais que les gens sachent ce qui est attendu et de gérer les attentes en conséquence).
• Une spécification fonctionnelle - Ce que l'application doit faire sur un niveau d'affaires. Cela peut être divisée en besoins de l'entreprise (processus métier, c'est l'automatisation et la façon dont ils travaillent) et des exigences fonctionnelles (ce que le système fonctionne et comment il le fait à l'écran de navigation, la façon dont les calculs sont effectués et ainsi de suite), mais le plus souvent ils sont combinés, sauf pour les plus gros systèmes. Il devrait également inclure des "non-fonctionnel" des exigences, telles que la performance, de charge, de sécurité et ainsi de suite.
• Une spécification technique - Les plus susceptibles d'être oublié. Une conception technique détaillée, y compris des choses telles que les modèles d'objet, le schéma des schémas et des informations sur la façon détaillée les problèmes techniques sont abordées.
• Des plans de Test et des scripts de test - la Façon dont l'application est en cours de test détaillée des cas de test, les données et les résultats attendus, couvrant tous les éléments du système.
• Guide de l'utilisateur et les Notes de publication - Comment installer, configurer et utiliser l'application.

Celui que je voudrais ajouter c'est un document d'appui - court (moins de 10 pages) cours intensif de ce que l'application fait et comment il le fait. Les développeurs vont souvent de ne pas lire des spécifications complètes (soit parce qu'ils n'ont pas le temps ou ne veulent pas) donc, ce document devrait être suffisant pour leur permettre de comprendre ce qu'il fait, comment il fonctionne, les parties de l'application qui sont les plus susceptibles d'être problématique et ainsi de suite. Il serait écrit quelques semaines après le go live par l'équipe qui a construit et mis en œuvre le système.

De cours en fonction de votre méthodologie vous pouvez vous n'avez aucun de ces documents, mais si vous êtes en cours d'exécution un projet standard dans une ancienne école de structuré, de la cascade façon, ce serait assez normal.

OriginalL'auteur Jon Hopkins

Typique d'un scénario de production, où le développement n'est pas effectuée à l'emplacement du client, généralement le modèle en cascade de SDLC est suivi et les documents relatifs à divers stades de WFM sont préparés:

1. De collecte des exigences d'Affaires - cahier des charges que les détails de l'exigence complète. Ceci est de nature fonctionnelle. Ceci est accompagné par un test de scénarios de cas fournies par les utilisateurs dont le utilisateurs mentionner le test et des cas de test qu'ils auraient à effectuer sur les fonctionnalités souhaitées. Cela sert de ligne directrice à l'équipe de développement ainsi à construire la portée de la fonctionnalité et de validations.

2. Analyse des besoins - au Cours de cette phase, le BA associée avec le projet réalisé l'analyse d'impact et l'analyse de la faisabilité. Les limites si toutes les exigences, les contraintes, les hypothèses sont documentés, partagés avec les utilisateurs métier et signé-off pour éviter toute d'autres surprises.

3. Approche de développement - au Cours de cette phase, l'équipe de développement de plomb ou de l'analyste de système d'prépare une approche doc qui définit le flux de processus, la conception de l'écran, les contrôles qui seront placés sur l'écran, les validations, les attributs, schéma de base de données, etc. C'est alors signée avec le BA. Si l'équipe de développement prévoit aucune contrainte technique qui aura un impact sur la fonctionnalité désirée, même est partagé avec l'équipe à nouveau et signés.
4. Test - Quand les utilisateurs d'effectuer des tests sur la libération, ils valident la libération, sur la base de cas et des scénarios de test fournis auparavant. Les défauts constatés sont documentées et renvoyé à l'équipe de développement. Les défauts sont d'abord validés par le BA à savoir si le défaut signalé dans la compréhension de la faille, de l'exigence fonctionnelle de déchéance ou de bogue technique. En conséquence de la résolution est fournie. Au cours de cette phase, il est pris soin que tous les cas de test sont terminées avec succès et tous les bugs sont résolus. Si un cas de test ou de bug est stationné pour la prochaine course, la base de l'impact qu'il aura sur la fonctionnalité, un appel conjoint est prise par l'équipe de développement et les utilisateurs de l'entreprise sur les risques encourus. À la fin, les Utilisateurs de l'Entreprise préparer les tests de signer un document où ils mentionnent le temps pris par chaque ressource pour les tests, les observations et les processus de suggestions d'amélioration.
5. Déploiement de Production - Ce qui inclut les instructions de déploiement pour le déploiement de l'équipe, des serveurs et des administrateurs de base de données pour mener à bien le déploiement.

Hésitez pas à donner vos suggestions.

OriginalL'auteur Nikhil Diwakar