Université de la Manouba Module : Ingénierie des méthodes et des processus

Institut Supérieur des Arts Multimédias

M1 - DSIR

Travaux dirigés - Série N°2

 Points clés

 Les processus de développement des logiciels sont les activités impliquées dans la production d'un
système de logiciel. Modèles de processus logiciel sont des représentations abstraites de ces
processus.

 Modèles génériques de processus décrivent l'organisation des processus logiciels.

 Des exemples de ces modèles génériques comprennent le modèle en cascade, le
développement incrémental, et le développement intégration/configuration.

 L„Ingénierie des exigences est le processus d'élaboration de la spécification du logiciel.

 La Conception et la mise en œuvre des processus sont concernés par la transformation de la

spécification des exigences dans un système de logiciel exécutable.

 La Validation du logiciel est le processus de vérification que le système est conforme à sa

spécification et qu'il répond aux besoins réels des utilisateurs du système.

 L‟Évolution du logiciel a lieu lorsque vous changez les systèmes logiciels existants afin de répondre
aux nouvelles exigences. Le logiciel doit évoluer pour rester utile.

 Les processus devraient inclure des activités telles que le prototypage et la livraison incrémentale
(progressive) pour faire face aux changements.

 Les processus peuvent être structurés pour le développement et l'exécution itérative de sorte que
des changements peuvent être effectués sans perturber le système dans son ensemble.

 Les principales approches de l'amélioration des processus sont les approches agiles, axées sur la
réduction des frais généraux des processus et les approches basées sur la maturité, basées sur une
meilleure gestion des processus et l'utilisation de bonnes pratiques d'ingénierie logicielle.

Exercices
I) Quiz :
1 : Le modèle de développement des logiciels en cascade est
a. Une approche raisonnable lorsque les exigences sont bien définies.
b. Une bonne approche lorsqu'un programme de travail est requis rapidement.
c. La meilleure approche à utiliser pour les projets avec de grandes équipes de
développement.
d. Un modèle ancien qui est rarement utilisé.

1
2: Le modèle incrémentiel de développement de logiciel est
a. Une approche raisonnable lorsque les exigences sont bien définies.
b. Une bonne approche lorsqu'un produit de base est exigé rapidement.
c. La meilleure approche à utiliser pour les projets avec de grandes équipes de
développement.
d. Un modèle révolutionnaire qui n'est pas utilisé pour les produits commerciaux.
3: Modèles de processus évolutifs
a. Ils sont de nature itérative.
b. Peut facilement répondre aux changements des exigences du produit.
c. Ne produisez généralement pas de systèmes jetables.
d. Tout ce qui précède.
4: Le modèle de prototypage de développement des logiciels est
a. Une approche raisonnable lorsque les exigences sont bien définies.
b. Une approche utile lorsqu'un client ne peut pas définir clairement les exigences.
c. La meilleure approche à utiliser pour les projets avec de grandes équipes de
développement.
d. Un modèle risqué qui produit rarement un produit significatif.
5: Le modèle en spirale de développement de logiciels
a. Se termine par la livraison du produit logiciel.
b. Est plus chaotique que le modèle incrémental.
c. Comprend l'évaluation des risques du projet au cours de chaque itération.
d. Tout ce qui précède.

6: Le modèle de développement concurrent est

a. Un autre nom pour l'ingénierie concurrente.
b. Définit les événements qui déclenchent les transitions d'état de l'activité d'ingénierie.
c. Utilisé uniquement pour le développement de systèmes parallèles ou distribués.
d. Utilisé chaque fois qu'un grand nombre de demandes de modification sont anticipées.
e. a et b

7: Le modèle de développement à base de composants est

a. Seulement approprié pour la conception du matériel informatique.
b. N‟est pas capable de supporter le développement de composants réutilisables.
c. Dépendant de l‟approche orientée objet.
d. N‟est pas rentable selon les mesures logicielles quantifiables connues.

8: Le modèle des méthodes formelles de développement de logiciels utilise des méthodes

mathématiques pour
a. Définir la spécification des systèmes informatiques.
b. Développer des systèmes informatiques sans défaut.
c. Vérifiez l'exactitude des systèmes informatiques.
d. Tout ce qui précède.

2
 9: Laquelle parmi les suivantes n‟est pas une phase du modèle RUP (Rational Unified Process)?
a. Phase de création
b. Phase d'élaboration
c. Phase de construction
d. Phase de validation

10: Lequel de ces éléments n'est pas une caractéristique du Processus Logiciel Personnel? (PSP :
Personal Software Process)?
a. Met l'accent sur la mesure personnelle du produit de travail.
b. Le praticien exige une supervision minutieuse par le chef de projet.
c. Le praticien individuel est responsable de l'estimation et de la planification.
d. Le praticien a l‟habilité de contrôler la qualité des produits logiciels.

11: Quel est l'objectif du Processus Logiciel d'Equipe (TSP :Team Software Process)?
a. Accélérer l'amélioration des processus logiciels
b. Permettre une meilleure gestion de temps par des professionnels hautement qualifiés
c. Créer des équipes de logiciels auto-dirigés
d. Montrer aux gestionnaires comment réduire les coûts et maintenir la qualité
e. b et c

12: Les outils technologiques des processus permettent aux entreprises de logiciels de compresser
les plannings en ignorant les activités sans importance.
a. Vrai
b. Faux
13: Il est généralement admis que l'on ne peut pas avoir de processus logiciels faibles et créer des
produits finis de haute qualité.
a. Vrai
b. Faux

II) Questions de recherche :

1. Donner les raisons de votre réponse en fonction du type de système en cours de développement,
proposer le modèle de processus logiciel générique le plus appropriée qui pourrait être utilisé
comme une base pour la gestion de développement des systèmes suivants:
 Un système pour contrôler le freinage anti-blocage (Anti-lock Braking System) dans une
voiture.
 Un système de réalité virtuelle pour soutenir la maintenance des logiciels.
 Un système de comptabilité de l'université qui remplace un système existant.
 Un système interactif de planification de voyage qui aide les utilisateurs à planifier leurs
voyages avec le plus bas impact sur l'environnement.

3
 2. Expliquer pourquoi le développement incrémental est l'approche la plus efficace pour le
développement des systèmes logiciels de commerce. Pourquoi ce modèle est moins approprié à
l‟ingénierie des systèmes de temps réel?
3. Considérons le modèle de processus basé sur l‟intégration et la configuration montré dans
Chapitre 2. Expliquer pourquoi il est essentiel d‟avoir deux activités séparées des exigences dans
le processus.
4. Proposer pourquoi il est important de faire une distinction entre le développement
des exigences de l'utilisateur et le développement des exigences du système dans le processus de
l'ingénierie des exigences.
5. Décrire les principales activités du processus de conception de logiciels et les sorties (résultats)
de ces activités. En utilisant un diagramme, montrer les relations possibles entre les sorties de ces
activités.
6. Expliquer pourquoi le changement est inévitable dans systèmes complexes et donner des
exemples (en dehors de prototypage et la livraison incrémentielle) des activités de processus
logiciel qui aident à prédire les changements et rendre le logiciel étant développé plus résistant
aux changements.
7. Expliquer pourquoi les systèmes développés comme prototypes ne devraient, normalement, pas
être utilisés comme une production de systèmes.
8. Expliquer pourquoi le modèle en spirale de Boehm est un modèle adaptable qui peut soutenir à la
fois les activités de l‟évitement du changement et de la tolérance au changement. Dans la
pratique, ce modèle n'a pas été largement utilisé. Proposer pourquoi cela pourrait être le cas.

8. Solutions
I) Quiz :

1:a 2:b 3:d 4:b 5:c 6:e 7:c 8:d 9:d 10:b 11:e 12:b 13:a

II) Questions de recherche :

1) Les modèles de processus logiciel générique le plus appropriés pour les systèmes suivants:

a. Système de freinage antiblocage : Ceci est un système de sécurité critique (safety-critical

system) qui exige beaucoup d'analyse à l'avance avant la mise en œuvre. Il a certainement
besoin d'une approche de développement axée sur plan avec des exigences soigneusement
analysés. Un modèle en cascade est donc le processus le plus approprié à utiliser, peut-être
avec des transformations formelles entre les différentes phases de développement.
b. Système de réalité virtuelle : Ceci est un système où les besoins vont changer et il y aura des
composants d'interface utilisateur (UI or GUI) étendus. Le développement incrémental avec,
peut-être, certain prototypage de l'interface utilisateur (UI) est le modèle le plus approprié. Un
processus agile peut être utilisé.
c. Système de comptabilité de l’université : Ceci est un système dont les exigences sont très tôt
connues et qui sera utilisé en collaboration avec beaucoup d'autres systèmes tels que le
système de gestion des subventions de recherche. Par conséquent, une approche fondée sur
la réutilisation (intégration et configuration) est susceptible d'être approprié pour cela.

4
 d. Système Interactif de planification de voyage: système avec une interface utilisateur
complexe (plusieurs questions et réponses entre le système et l‟utilisateur), mais qui doit être
stable et fiable. Une approche de développement incrémental est la plus appropriée et
avec le changement dans les exigences du système, l'expérience de l'utilisateur avec le système
sera acquise.
3) Dans un processus fondé sur l‟intégration et configuration, vous avez besoin de deux activités
d'ingénierie des exigences parce qu‟il est essentiel de s'adapter aux exigences du système en
fonction des capacités systèmes/composants pour être réutilisés. Ces activités sont les suivantes:
 Une activité initiale où vous comprenez le fonctionnement du système et de définir
les besoins généraux de ce que le système doit faire. Ceux-ci devraient être exprimés
avec suffisamment de détails que vous pouvez les utiliser comme une base pour
décider si le système/composant satisfait certaines exigences et peut donc être
réutilisé.
 Une fois que les systèmes/composants sont sélectionnés, vous avez besoin de plus de
l‟ingénierie des exigences pour vérifier que les fonctionnalités du logiciel réutilisé
répondent aux besoins du système et d'identifier les modifications et les ajouts requis.
4) Il existe une différence fondamentale entre les exigences de l'utilisateur et du système, ce qui
signifie qu'ils doivent être considérés séparément.
a) Les exigences de l'utilisateur sont destinées à décrire les fonctions et les caractéristiques du
système de point de vue utilisateur et il est essentiel que les utilisateurs comprennent ces
exigences. Elles doivent être exprimées en langage naturel et peuvent ne pas être exprimées avec
beaucoup de détails, pour permettre une certaine flexibilité d'implémentation. Les personnes
impliquées dans le processus doivent pouvoir comprendre l'environnement de l'utilisateur et le
domaine d'application.

b) Les exigences du système sont beaucoup plus détaillées que les exigences de l'utilisateur et sont
destinées à être une spécification précise du système qui peut faire partie d'un contrat de système.
Ils peuvent également être utilisés dans les situations où le développement est sous-traité
(externalisé) et l'équipe de développement a besoin d'une spécification complète de ce qui devrait
être développé. Les exigences du système sont développées après l'établissement des exigences
des utilisateurs.

6) Les systèmes doivent être modifiés car ils sont installés dans un environnement. L'environnement
s'adapte à eux et cette adaptation génère naturellement des exigences système
nouvelles/différentes. En outre, l'environnement du système est dynamique et produit
constamment des nouvelles exigences à la suite de modifications apportées au métier, les
objectifs de l‟entreprise et les politiques commerciales. Le système devrait être adapté pour tenir
compte ces exigences ou il sera moins utile.
Exemples d'activités de processus qui soutiennent le changement:

a. Enregistrement de la justification des exigences de sorte que la raison pour laquelle une
exigence est incluse est connue. Cela aide les changements futurs.
b. Traçabilité des exigences qui montre les dépendances entre les exigences et entre les
exigences et la conception/code du système.

5
c. Modélisation de la conception où le modèle de conception documente la structure du
logiciel.
d. Reconstruction du code qui améliore la qualité du code et le rend plus susceptible à changer.