Gabarit du rapport final

Le but de ce document est de vous faire faire un recul en tant qu’ingénieur logiciel et d’évaluer et communiquer ce que vous aviez réussi et appris. Il sert d’analyse des résultats de votre projet. Vous devriez non seulement expliquer la situation actuelle de votre projet, mais également la façon dont vous avez arrivé à ce point et ce que vous avez appris. Votre client devrait également ajouter au contenu de ce document et le réviser pour aider à définir les réussites du projet et partager ce qu’ils ont appris. Ce rapport agira comme la référence historique de ce que vous aviez accompli dans votre projet.

Résumé du projet et les leçons que vous aviez apprises

Réitérez, BRIÈVEMENT, les buts et les besoins originaux du projet. Expliquez comment ils ont évolué ou changé durant le projet. Résumez les défis techniques et les choix qui ont été faits durant le projet. Énumérez les leçons principales que vous avez apprises. Qu’est-ce que vous ferez différemment? Identifiez les réussites et les succès du projet du point de vue technique et du point de vue clients et utilisateurs. Incluez un ou deux diagrammes d’architecture pour illustrer les détails du déploiement du système et ses différentes composantes ou paquets. Faites des recommandations pour améliorer le système dans des versions futures.

Rapport d’évaluation d’impacte

Ce rapport sert à démontrer que vous avez considéré l’impacte de votre système au-delà des définitions restreintes de besoins que vous avez établies avec votre client, tel un ingénieur licencié professionnel le ferait (ing). En tant que gradués d’un programme de génie logiciel certifié, vous serez éligibles à appliquer pour la désignation ing (voir http://www.peo.on.ca pour de plus amples renseignements). Votre rapport devrait évaluer les éléments suivants:

Questions de nature légales – Existe-il des lois ou de la législation applicables qui seront pertinents à l’utilisation ou à la construction de votre système? Comment est-ce que vous les avez adressés?

Normes – Quelles normes techniques sont pertinentes à votre logiciel? Comment est-ce que vous avez assuré que votre système soit conforme à ces normes? Il pourrait s’agir de normes gouvernementaux, de normes d’industrie, ou simplement de conventions qui sont suivies dans le marché pour votre système. Assurez-vous d’identifier clairement le type de norme duquel vous parlez et l’autorité pertinente pour cette norme.

Questions de responsabilité – Quelle responsabilité potentielle auriez-vous ou auraient les clients ou utilisateurs du système si celui-ci est mal-utilisé ou possède des défauts?

Questions de nature sociale – Quel est le potentiel que ce système soit bénéfique ou nuisible à la société en général? Qu’avez-vous fait pour adresser son utilisation potentiellement nuisible?

Communauté d’utilisateurs – Quel impact aura ce système sur la communauté d’utilisateurs visée? Avez-vous pris des démarches pour protéger les intérêts de cette communauté?

Impact financier – Avez-vous évalué la totalité des coûts financiers du déploiement et du support du système pour vous, pour le client, pour les utilisateurs, et pour la société en général?

Rapport d’assurance qualité

Faites une liste détaillée des essais que vous avez performés durant votre essai de fonctionnement final ainsi que les résultats de ces essais. Pour chaque essai, identifiez les besoins, les cas d’utilisation ou les caractéristiques qu’il est sensé couvrir. Résumez les résultats de l’essai, et, si possible, faites un corrélation avec les besoins et les objectifs du projet. Ce résumé devrait inclure le statut actuel de la réparation des bogues. Combien de bogues avez-vous détecté au cours de votre projet? Combien en reste-t-il à réparer? Remettez au moins un rapport d’assurance qualité additionnel d’une ancienne étape pour illustrer le progrès que vous avez fait récemment. Idéalement, je verrais une série de rapports d’assurance qualité illustrant que vous aviez performé des essais de fonctionnement réguliers durant l’étape de mise en œuvre du projet.

Documentation du système

Votre système devrait être entièrement fonctionnel et déployé à ses utilisateurs. Vous devriez créer une démonstration qui souligne toutes les caractéristiques clés du système ET qui démontre pourquoi ces caractéristiques sont utiles. Prenez des copies d’écran d’une démonstration en temps réel et insérez-les dans un document avec du texte qui explique ce que la copie d’écran illustre. La documentation devrait être assez détaillée pour qu’un utilisateur puisse l’utiliser pour faire la démonstration lui-même. Si vous fournissez de la documentation à votre client, veuillez identifier chaque pièce de documentation (ex : guides d’utilisateurs, documentation de construction, documents de conception, etc.) et son objectif. Veuillez inclure une copie de vos documents avec votre rapport final (mais ce n’est pas requis).

Contribution des membres

Résumez la contribution que chaque membre a fait au projet, vous référant idéalement à des parties à remettre ou à des étapes spécifiques. Si vous croyez qu’un ou plusieurs membres de l’équipe méritent d’être particulièrement reconnus pour une contribution ou une réussite importante, identifiez ces membres et décrivez la contribution ou la réussite. Veuillez noter que vous devriez discuter de tels arrangements avec moi en avance, et je dois les approuver. Préférablement, ceci devrait être fait au plus tard quand vous remettez votre rapport de conception.