Historique

1. 2006-04-11 11:10-11:30: Introduction (à partir des documents précédents) et problématique.
2. 2006-04-11 15:10-15:30: Incertitude et ajout des titres des sous-sections
3. 2006-04-11 21:16-21:57: Revue de la documentation
4. 2006-04-12 16:00-16:40: Méthodologie utilisée
5. 2006-04-13 11:40-12:20: Description de la solution, partie I
6. 2006-04-13 19:00-19:20: Description de la solution, partie II
7. 2006-04-13 20:30-21:00: Discussion et recommendations
8. 2006-04-13 23:35-23:50: Conclusion
9. 2006-04-14 18:00-18:40: Revision #1.1
10. 2006-04-14 20:00-20:50: Revision #1.2, ajout de graphique et références
11. 2006-04-15 22:00-22:50: Revision #1.3, ajout tableau, correction orthographique, acronymes
12. 2006-04-16 13:50-14:50: Revision #2
13. 2006-04-16 18:00-19:00: Formatage ODT

Introduction

SFLphone est un téléphone logiciel IP utilisant le protocole SIP. Le téléphone SFLphone est développé pour une utilisation en entreprise et pour les employés désirant utiliser la téléphonie IP de l'entreprise à la maison. Une des particularités de ce logiciel est qu'il offre une interface graphique simple et une gestion de 6 appels. Toutefois, il permet d'enregistrer une seule configuration de paramètres à la fois. Cette restriction n'est pas idéal pour un usage à la maison et au travail ou pour les personnes ayant plusieurs comptes IP. Ce téléphone est sous licence GPL et est développé avec des outils et librairies libres.

Objectifs du projet

Le projet a pour but d'intégrer des nouvelles fonctionnalités au logiciel SFLPhone. Il s'agit de rendre SFLphone multi-sessions. Le téléphone permettra alors d'utiliser plusieurs comptes et protocoles à la fois. Une approche apprise en génie logiciel sera utilisée pour concevoir une solution adéquate répondant aux besoins initiaux. Les livrables du projet sont un document d'analyse préliminaire, une discussion et des diagrammes de conceptions, un plan de travail pour les tests et la phase de codage et le code. Ces documents permettront une meilleure évaluation des besoins et des défis amenés par l'ajout de ces fonctionnalités au logiciel existant. Finalement, les fonctionnalités ajoutées découleront de la problématique présentée plus bas.

Problématique

Présentement, le logiciel SFLphone permet de se connecter sur un seul serveur SIP à la fois. Les utilisateurs voyageant avec des portables ou voulant utiliser plusieurs serveurs SIP ne peuvent donc pas enregistrer et conserver plusieurs configurations. Cette limite du logiciel peut être frustante et le logiciel n'est donc pas adapté à un usage d'affaires. De plus, le logiciel ne permet pas de communiquer nativement avec le serveur Astérix et son protocole IAX. L'architecture actuelle ne permet pas de gérer plusieurs comptes usagers. La gestion des appels a été codée avec une approche SIP exclusive et ne peut accepter d'autres protocoles pour le moment.

Les bénéfices d'une nouvelle architecture

Une nouvelle architecture multi-session permettrait dans un premier temps de conserver plusieurs configurations et d'en utiliser plusieurs à la fois. Par exemple, un utilisateur pourrait recevoir les appels provenant de plusieurs serveurs VoIP en même temps. Dans un deuxième temps, l'intégration du protocole IAX permettra de communiquer directement et plus facilement avec le serveur PBX Astérix. Ces intégrations sont importantes pour permettre une évolution plus rapide du logiciel et intégrer la vidéo-conférence à SFLphone ultérieurement, via le protocole IAX. Ces fonctionnalités permettront de distinguer le logiciel des autres logiciels concurents qui ne supportent qu'une seule configuration.

Les parties prenantes

Entrepreneur

Cyrille Béraud est le président de Savoir-Faire Linux et est le principal intéressé pour les possibilités de contrats d'installation à long terme (contrat avec des entreprises pour le support et l'intégration en entreprise).

Architecte et premier concepteur

Jérôme Oufella est le père de SFLphone, premier concepteur et premier architecte de la structure du logiciel. Son avis est important pour connaître les erreurs qui ont été commises par le passé et les raisons pour lesquels des choix d'architecture ont été faits.

Programmeurs

Laurielle Léa, Jean-Philippe Barette-LaPierre et Yan Morin ont créé le code source du logiciel, la documentation et l'architecture actuelle.

Entreprise-utilisateur

Une entreprise intéressée à SFLphone pourrait installer sur plusieurs ordinateurs le logiciel SFLphone et l'utiliser avec un serveur SIP ou IAX interne (Astérix ou un autre PBX).

Utilisateur

Il utilise le logiciel dans une entreprise ou à la maison pour communiquer dans le cadre du travail. Il effectue des appels ou des communications à longue distance via IP.

Bidouilleur/Testeur

Utilisateurs ou programmeurs qui testent la version CVS du logiciel ou les versions précédentes à la maison où dans des buts de tests avec d'autres applications, réseaux ou distributions.

Distributeur

Le distributeur fait le paquetage d'application pour des distributions Linux. On parle notamment de Debian ou Fedora.

Développeur de librairies

Il développe des librairies ou dépendances de SFLphone. Lors de problème sérieux avec une librairie, on doit le contacter directement si possible.

Les risques

Il existe plusieurs incertitudes et risques dans ce projet. Il est évident qu'il doivent être tenu en compte pour la prise de décision lors de l'analyse et de la conception.

Premièrement, IAX est un nouveau protocole et la version 2 n'est pas très diffusée sur Internet et dans les distributions Linux. Personne au sein de l'équipe ne connaît ce protocole.

Deuxièmement, le coeur de SFLphone a été fait par une développeuse il y a deux ans. L'ajout d'une fonctionnalité dans le module principal du projet amène des répercussions sur tous les composantes du logiciel: coeur, protocole, son, interface texte, interface graphique.

Troisièmement, les ressources humaines pour travailler sur SFLphone ne sont pas nécessaire pour permettre un développement continu. Le programmeur principal est occupé avec 4 autres cours cette session-ci. De plus, un développeur à cesser d'être actif au sein du projet et à quitter l'entreprise. Finalement, un nouvel employé s'est joint à Savoir-Faire Linux, mais ne connaît pas le dossier.

Quatrièmement, les plans et la maintenance de dépendances dans les distributions sont des facteurs incertains et peuvent jouer contre nous. Même si l'inclusion de librairie et dépendance à même le projet est considéré comme une mauvaise chose, l'inaction des grandes distributions nous obligent à prendre ce type d'initiative. L'inclusion de librairie est une mauvaise stratégie à long terme car les mises à jour demeurent plus difficiles et moins automatisées.

Revue de la documentation

Pour faire ce projet, trois types de documentations ont été utilisés: les ouvrages portant sur les patrons de conception, les spécification de IAX et les codes sources de logiciels intégrant IAX.

Patrons de conceptions et approches

Pour le support multi-protocole (SIP/IAX), un couplage faible est préférable entre le contrôleur et les protocoles. Ce couplage faible permettra d'ajouter d'autres protocole à l'avenir. Il faut donc crée une interface générique pour les classes compte, lien voIP et appel. Ensuite, une hiérarchie pour chaque classe sera construire en créant des classes spécifiques à chaque protocole. Par exemple, une classe SIPAccount et IAXAccount sera créée. On peut voir à l'adresse http://www.dofactory.com/Patterns/PatternAbstract.aspx le patron "Abstract Factory" qui permet de créer une hiérarchie de classes. Ce patron provient du livre de GoF et on peut aussi le retrouver dans le livre "Applying UML And Patterns, Second Edition" de Craig Larman à la page 525. Ce patron répond bien aux problèmes de hiérachisation des classes.

Héritage en série de classes.

Enfin, Pour la création des classes spécifiques à un seul protocole, le patron Factory (GoF) répond à se besoin. Il suffit donc d'utiliser une classe qui permettra de construire à l'aide d'un identifiant une classe avec un protocol SIP ou IAX. Par exemple, la classe AccountCreator a pour seul but de créer les classes SIPAccount et IAXAccount.

Le contrôleur utilise la classe AccountCreator pour crée une instance SIPAccount.

Un autre problème posé par le support multi-protocole et multi-compte est le partage des ressources. Ainsi, chaque protocole possède un fil d'exécution (thread) distinct qui écoute sur un port les évènements externes. Un autre fil d'exécution est créé pour l'intéraction avec l'usager (le contrôleur) et un dernier fil d'exécution est créé pour l'accès au son. Tous ces processus s'exécutent en même temps et manipule le son, l'états des appels et du téléphone. Une synchronisation est donc exigé pour chaque ressources partagées par de multiples fils d'exécution. Pour ce faire, l'utilisation de Mutex (Mutual Exclusion) a été utilisé. Cette approche a été vue et utilisée dans le cadre du cours de LOG550 (Conception de systèmes informatiques en temps réel). Chaques ressources partagées par plusieurs fils en même temps ont donc été protégées par un mutex. Il s'agit des classes AccountMap, CallAccountMap, CallMap.

Spécification IAX

La spécification Inter-Asterisk EXchange (IAX) Version 2 a été utilisé pour comprendre le fonctionnement d'IAX. Il s'agit d'un protocole binaire simple pour établir des communications entre deux agents IAX. Ce protocole de bas niveau n'a pas été codé dans le logiciel car la librairie IAX2 offre une interface pour les logiciels de téléphonie.

Intégration de IAX

Trois librairies ont été étudiées pour l'utilisation de IAX2.

Premièrement, la librairie IAX version 1 n'est pas adaptée pour une intrégration dans un projet en langage C++. De plus, elle n'implémente pas la dernière version du protocole. On peut donc qualifié cette librairie d'obsolète bien qu'elle soit largement diffusée dans les distributions.

Deuxièmement, la librairie IAX version 2 a été étudiée. Elle est adaptée pour les projets C++, implémente la version 2 du protocole mais n'est pas largement distribuée. Une étude plus approfondie de son intégration dans d'autres projets permet de constater qu'elle est la plus utilisée. Elle est généralement incluse dans les autres projets de téléphonie VoIP.

Troisièmement, la librairie iaxclient semblait parfaite pour l'utilisation dans le projet. Elle incluait le protocole IAX2, était distribuée et semblait implémenter toutes les fonctions nécessaires pour un téléphone IP. Toutefois, un problème majeur a freiné son adoption. Ainsi, cette librairie gère la librairie sonore et inclus de multiples codecs. La librairie sonore et les codecs entraient directement en conflit avec ceux de SFLphone. Pour l'intégrer dans le logiciel, des modifications majeures auraient dû être apportées à cette librairie et à SFLphone. Les avantages amenés par cette librairie, la gestion simple des codecs et des appels, se sont donc trouvés être des inconvénients majeurs pour son utilisation.

Finalement, suite à cette analyse, la librairie IAX, version 2 a été choisie et intégrée dans le projet de SFLphone. Cette librairie a été choisie puisque les autres librairies ne pouvaient pas être utilisés à long terme. On peut voir en annexe (Annexe B: Analyse IAX), un tableau de comparaison de ces librairies.

Méthodologie et élaboration de la solution

Approche utilisée

Une approche minimaliste a été utilisée pour analyser et développer une solution.

Ainsi, un document de spécification allégé a permis de rappeler et de clarifier les différents besoins et identifier les acteurs. Ce document a permis de poursuivre l'analyse en étudiant les librairies IAX disponibles. Se référer à l'Annexe A "Analyse et impact".

Ensuite, grâce au document de spécification et au code source du projet SFLphone, des diagrammes UML ont été conçus. Les classes qui devaient être modifiées ont été identifiées à ce stade. (Annexe A)

Par la suite, les besoins identifiés ont permis de concevoir une première ébauche d'un document de conception avec les problèmes amenés par l'ajout de ces fonctionnalités. La recherche documentaire a permis de cerner des solutions tangibles pouvant être intégrer au projet. Un nouveau diagramme de classe a donc été ajouté. Ce modèle a permi l'élaboration des tests et le développement final de la solution (code). Voir l'annexe C "Conception".

Durant l'écriture des tests et du code (les tests ont été écrits avant le code), un document rassemblant les grandes étapes pour les phases de transition entre l'ancienne architecture du projet et la nouvelle architecture a été rédigé. La période de transition s'est effectué sur 5 journée intensive. Le document a été complété durant le codage avec les tâches accomplies et les heures allouées. Ce document a permis d'avoir une vision à moyen terme de la charge de travail amené par la transition.

Finalement, deux guides pour les changements après les transitions seront écrits. Le premier guide rassemblera les scénarios et les interfaces d'utilisation des comptes usagers tandis que le deuxième guide permettra de spécifier les étapes et tests pour l'implémentation du protocole IAX.

Cette méthode de travail était utilisée lors du développement antérieur de SFLphone. Il s'agit d'une méthode qui pourrait être grandement améliorée avec l'ajout d'outil libre pour la gestion des besoins et la planification des tâches. Cet outil devrait supporter des processus allégés et reste à développer. Il est toutefois à noter que la gestion des erreurs détectées par l'usager se fait actuellement sur le site forge.novell.com.

Alternatives considérées

Le processus de développement RUP n'a pas été choisi puisqu'il a été considéré comme trop lourd et non adéquat à l'élaboration de documentation légère pour le projet SFLphone. Le développement ne pouvait pas se faire avec les outils propriétaire Rational Rose ou avec les gabarits dans un format propriétaire. Il faut rappeler qu'un des contraintes du projet est qu'il doit être développé avec des outils pouvant être utilisés par le plus de développeurs de la communauté du libre.

Le processus AGILE n'était pas familier à l'équipe de développement et n'a donc pas été retenu.

Difficultés rencontrées

Durant le projet, trois difficultés majeures ont influencé le projet.

La motivation

Le manque de motivation et une surchage de travail a nuit grandement au déroulement du projet. Après un début de session chargée, le départ d'un développeur de l'équipe de SFLphone ainsi que des travaux sur d'autres projets (w3c, facil, linux-québec) pour le développeur principal, le projet SFLphone a passé en priorité secondaire. De plus, il n'existe pas encore une grande communauté derrière SFLphone et il s'agit d'une erreur de la part des développeurs du projet. Le rythme des sorties de SFLphone devra donc être accéléré après la version 0.7 pour susciter plus d'intérêts et de volonté de s'approprier ce logiciel. Enfin, la volonté des développeurs du projet à utiliser d'autres librairies devront être freiné pour ne pas faire exploser le projet.

La distribution des librairies

Le manque flagrant de librairies pour la téléphonie IP dans les distributions bloquent l'émergence de beaucoup de projets et la création d'une communauté de développement libre active. Par exemple, près de 4 mois se sont écoulés depuis une demande pour inclure une librairie dans la distribution debian et il y a eu peu d'effort pour l'ajouter. Le processus est encore en cours et une équipe s'est formé depuis lors pour l'ajouter. Il en va de même pour les distributions comme Fedora, Redhat ou Suse qui tardent parfois à mettre à jour des librairies ou ne fragmentent pas assez les paquetages.

Parmi les librairies qui ne sont pas à jours dans les distributions, on peut parler de: ccrtp2, libexosip2, portaudio_v19, libiax2, libgsm, libortp.

Le manque de connaissances

Peu de personne étaient disponibles pour donner des explications sur des concepts comme les protocoles STUN, IAX ou SIP à l'ETS ou dans les contacts des développeurs. De ce fait, tout développement et apprentissage a été plus long et laborieux. Il faut aussi préciser que les livres ne montrent que peu d'information utile lorsqu'il s'agit de problèmes avec des implémentations de serveur. Malheureusement, la pratique ne concorde pas exactement avec les standards et les exemples sont parfois trop pauvres pour être utilisés. On peut penser par exemple au serveur SIPPhone qui intègre des réponses qui lui sont propres ou au format incertain utilisé par les documents SDP lorsque l'appel se fait sous un NAT.

Description de la solution

Les modifications apportées à la conception originale

L'architecture de SFLphone, à la version 0.3 devait permettre l'utilisation de plusieurs liens SIP. Par contre, l'implémentation ne supportait pas cette architecture et le code a donc dû être réécrit et l'architecture repensée.

L'ajout de compte usager

L'utilisateur possédait autrefois un seul compte. Les configurations étaient enregistrées dans la section "VoIPLink". La configuration était chargée au démarrage du contrôleur. L'instance du lien VoIP SIP accédait directement aux configurations du téléphone en utilisant le contrôleur, une classe singleton.

Pour permettre de gérer plusieurs configurations et compte usager, plusieurs classes ont été ajoutées. Premièrement, les classes Account, SIPAccount, et IAXAccount permettre de gérer un compte. Ces classes permettent d'initialiser les configurations particulière à chaque protocole. De plus, ces classes se chargent de communiquer avec leur lien VoIP respectif. Deuxièmement, le type AccountMap a été rajouté. Il s'agit d'un type pour une liste de comptes dans le contrôleur. L'accès aux comptes se fait en utilisant le nom du compte ou en parcourant la liste.

Ainsi, lors de l'initialisation de la configuration, chaque instance "Account" charge sa configuration. Ensuite, lorsque l'usager lance l'activation des comptes, chaque compte actif est démarré. L'activation des comptes permet de créer un lien VoIP. Le lien VoIP permet de communiquer avec le protocole et de recevoir les appels.

Du côté du protocole de communication serveur/client graphique, un champ "compte" a été ajouté à quelques méthodes comme "register" ou "unregister".

Finalement, le client graphique (QT) et le client en ligne de commande (CLI) ont été modifiés pour utiliser temporairement le premier compte SIP (identifiant SIP0). Un changement d'interface devra avoir lieu pour permettre l'utilisation de plusieurs comptes. Il s'agit d'une étape planifiée pour plus tard.

Les liens VoIP

L'interface VoIP existait déjà mais à quand même été modifiée légèrement lors du changement d'architecture. Ainsi, quelques propriétés non-utilisées ont été supprimées. De plus, les liens VoIP connaissent maintenant le nom de leur compte utilisateur. Les liens VoIP doivent connaître ce renseignement pour avertir l'usager d'un nouvel appel.

La gestion des appels

Les classes Call, SipCall et la gestion des appels dans le contrôleur (Manager) ont été complètement réécrites. La logique pour gérer les appels n'étaient pas adéquates pour un développement futur du logiciel. Certains problèmes d'états avaient été découverts dans la classe Call. Notamment, un appel pouvait ne pas être répondu, mais en mode attente (Hold). Hors, il n'était pas possible avec l'ancien modèle de la classe de représenter un tel état. De plus, la classe SipCall n'héritait pas de classe Call. Pourtant, un SipCall répond au postulat d'héritage des classes dans la programmation orienté objet, une classe SipCall est un Call. Du couplage non nécessaire dans la classe SipVoIPLink était présent pour pallier à ce problème.

La modification de l'architecture du logiciel a donc permis de réglé ce problème de couplage. Ainsi, l'interface VoIPLink gère une liste de classe "Call". À son tour, les classes SIPVoIPLink gèrent cette liste en ajoutant des SIPCall. Seul SIPVoIPLink connaît l'existance de SIPCall et peut en même temps connaître l'état présent de tous les appels (En attente, non répondu, etc.). Les instances de la classes IAXVoIPLink vont quand à elles gérer des instances IAXCall.

Étape de création d'un appel sortant (outgoing call) avec l'ancienne architecture.

Étape de création d'un appel sortant (outgoing call) avec la nouvelle architecture.

Puisque le contrôleur a besoin de connaître un peu d'information sur les appels, pour par exemple, acheminer un message de l'utilisateur au lien voIP, une liste qui associe un numéro d'appel à un numéro de comptes est gérée dans le contrôleur. Cette liste doit être en synchronisation en tout temps avec les différentes listes des liens VoIP. Cependant, la nouvelle architecture a permis d'enlever la gestion des états des appels à même le contrôleur. Cette tâche ést maintenant gérée par le lien VoIP.

La gestion des appels dans le serveur

Le protocole de communication entre le serveur de sflphone et l'interface usager indique qu'un appel doit être identifié par un numéro d'appel unique. Hors, ce numéro était du type chaîne de caractères (string) dans le protocole de communication et entier (int) à l'intérieur du contrôleur. Une table de correspondance a donc dû être créée pour régler ce problème. Avec la refonte de la gestion des appels dans le coeur du projet, cette table a été enlevée et le type "string" a été utilisé dans tout le projet. L'utilisation d'un type commun entre le serveur de communication et le coeur du projet a permis de simplifier et de rendre plus uniforme la communication entre les modules.

Les évènements spécifiques aux comptes

Comme indiqué précédement, le protocole de communication a été modifié pour permettre de s'enregistrer à un compte spécifique. Un compte contient les fonctionnalités suivantes: initialisation, enregistrement, désenregistrement et terminaison. En plus, un compte contient une méthode pour charger ses paramètres de configurations. Tous les autres évènements sont gérés par le lien VoIP, directement.

La séparation des modules

La gestion des appels à l'intérieur des liens VoIP a permis une plus grande séparation entre les modules et à diminuer les responsabilités du contrôleur. Cette séparation permet d'être plus flexible pour l'ajout de nouveau protocole et facilite une transition vers une application qui pourrait supporter la vidéo.

Les outils utilisés pour faire le projet

L'écriture des rapports et des plans de tests se sont effectués avec un navigateur Web (Firefox) et le traitement de texte OpenOffice.org.

Le logiciel Umbrello a permis l'exportation du code C++ pour créer les diagrammes UML. Il n'a pas été utilisé pour générer les nouvelles classes puisque le contenu généré n'était pas conforme aux gabarits du projet. La documentation peut être générée grâce à l'outil Doxygen.

Les éditeurs KDevelop et vim ont permis d'écrire les tests et le code du logiciel. KDevelop est un environnement graphique qui permet un débogage simple des applications C++ à l'aide d'une intégration avec l'outil gdb. Par ailleurs, vim, par sa simplicité, permet d'éditer rapidement des fichiers texte.

La librairie iaxclient et les clients de démonstration ont été utilisées pour apprendre à utiliser la librairie IAX2. La librairie iaxclient a été étudiée pour être utilisée dans le projet. Malheureusement, elle n'a pu être intégrée pour des raisons d'incompatibilité de dépendances.

Le gestionnaire de version CVS, sur un serveur de Novell, est utilisée pour le projet SFLphone depuis ses débuts.

Le serveur Asterisk, un PBX libre et à code source ouvert a permis d'effectuer des tests de connexion, d'échanges et d'appels SIP et IAX. Les paquets échangés ont pu être étudiés grâce au logiciel Ethereal.

Discussion

Les fonctionnalités non prises en compte

Plusieurs fonctionnalités n'ont pas été implémentées immédiatement dans ce projet. Ainsi, l'ajout d'une interface pour configurer plusieurs comptes sera fait dans une prochaine étape. Cette ajout a été reporté puisque les modifications apportées au coeur du logiciel n'ont pas été testées raisonnablement encore. De plus, l'interface graphique a été développé par un autre développeur et il s'agit d'une refonte majeure.

Ensuite, les tests pour exécuter plusieurs comptes en parallèle restent à faire. Ces tests n'ont pas été fait par manque de temps et parce qu'il s'agit de tests complexes à développer et à exécuter. De plus, les problèmes qu'ils peuvent trouver sont habituellement difficiles et long à fixer. Il s'agit par exemple, d'essayer de se connecter à deux comptes SIP, ou un compte SIP et un compte IAX ou encore de tenter de s'enregistrer avec deux comptes identiques.

Les prochaines étapes du projets

Les prochaines étapes du projet sont:

1. Implémentation de la boucle d'écoute de IAX;
2. Ajout des fonctionnalités de base pour la gestion d'appels dans IAX;
3. Test pour le support SIP et IAX en parallèle;
4. Test pour le support de deux comptes SIP en parallèle;
5. Développement des interfaces usagers pour la partie QT;
6. Migration des anciens comptes SIP du fichier de configuration personnel vers les nouveaux comptes SIP;
7. Suppression de la librairie libexosip2 à l'intérieur du projet;
8. Sortie de la version 0.7;
9. Ajout de la vidéo avec le protocole IAX;
10. Modification de la gestion des codecs;
11. Suppression de la librairie portaudio_v19 à l'intérieur du projet;
12. Aide aux distributeurs pour ajouter SFLphone aux distributions Debian et Fedora.

Les freins au développement

Les freins pour le développement de l'application ont été le manque de motivation et de temps pour travailler sur ce projet. La charge de travail du développeur principal était très élevée pour cette dernière session de cours. De plus, l'indisponibilité ou l'instabilité des librairies utilisées dans le projet ont rallentit l'intégration et le développement de SFLphone. Il faut noter toutefois que grâce à plusieurs journées de négociation, il y a une ouverture dans les dernières semaines pour les librairies nécessaires aux applications téléphoniques sur Linux.

Conclusions et recommandations

Conclusion

En conclusion, ce projet a rencontré beaucoup de problèmes car il comportait des risques élevés. Le développeur principal n'a pas pu mettre assez de temps sur ce projet. Plusieurs étapes ont du être reportés comme les tests ou l'implémentation complète de IAX.

Aussi, on peut constater que les outils et les librairies ne sont pas encore disponibles pour faire ce type de logiciel. En plus des moyens techniques, une volonté sans faille pour travailler sur un tel projet est requise. La patience et la communication avec les acteurs est essentiel pour réussir.

Pour ce qui a trait à la conception et des modifications d'architecture, il faut en tout temps prévoir une période de transition et ne pas vouloir refaire au complet le logiciel. La transition peut être longue, mais elle est nécessaire pour éviter un cas où il ne serait plus possible de revenir en arrière.

Finalement, les notions apprises lors de la session hiver 2006 en LOG550 (temps réel) et LOG610 (réseau), ont permis au développeur principal de comprendre plus facilement des aspects cruciaux du logiciel. Le choix de ses cours s'est donc avéré judicieux.

Recommandations

Plusieurs mesures auraient pu faciliter ce projet.

• Une disponibilité des dernières librairies pour la téléphonie IP et pour le son permettrait de développer beaucoup plus rapidement des applications. Cette disponibilité permettrait une plus grande appropriation des bibliothèques et un plus grand engouement dans le domaine. À long terme, les librairies ne pourraient que s'améliorer et devenir plus stable. De plus, la diffusion à grande échelle des librairies éviteraient aux développpeurs d'inclure inutilement du code externe et difficile à maintenir.
• Les outils utilisées pour l'importation du code C++ restent à être solidement tester, à l'aide de matrice de tests par exemple, pour permettre une utilisation sans problèmes fréquents.
• Les documents fournis par le département de Génie Logiciel devraient être accessible dans le plus grand nombre de formats et ne devrait pas être limité à un seul format propriétaire. Il s'agit d'un frein pour les personnes qui choisissent une autre plate-forme de développement.
• Un outil de gestions des exigences, qui permet d'englober les besoins, les exigences, la gestion du code, la communication entre développeurs et qui permettrait d'enregistrer les problèmes rencontrés pourraient améliorer la gestion d'un tel projet. Cet outil devrait normalement être libre pour permettre d'englober les techniques déjà existantes. Un tel outil devrait à la fois posséder un interface Web et une interface applicative dans les logiciels existants. L'interface Web permettrait d'accéder aux informations de l'extérieur, nécessaire pour un travail qui se doit être ouvert.
• Avoir une politique pour entretenir une bonne communication sur les listes de discussions. Ainsi, une certaine redevance aux utilisateurs est exigée à chaque semaine et permet un développement constant de l'application.

Références

• Beaulieu, J-M., De Kelper, B., Mécanisme de synchronisation dans UCOS-II https://intra.ele.etsmtl.ca/academique/log550/cours/chap07_SynchroUCOS_4p.pdf
• Beaulieu, J-M., De Kelper, B., Programmation concurrente et synchronistaion https://intra.ele.etsmtl.ca/academique/log550/cours/chap07_ProgConc_4p.pdf
• Data & Object Factory, Abstract Factory, http://www.dofactory.com/Patterns/PatternAbstract.aspx
• Gamma, E., Helm, R., Johnson, R., Vlissides, J. M., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley
• Johnston, B. Alan, SIP: Understanding the Session Initiation Protocol, Second Edition, Artech House, 2004.
• Larman, C., Applying UML And Patterns, Second Edition, Prentice Hall PTR, 2001, p.525.
• Savoir-Faire Linux, SFLphone, an Open Source VoIP client for Linux, http://www.sflphone.org/
• Spencer, M., Miller, F., Inter-Asterisk EXchange (IAX) Version 2, 2005, http://www.cornfed.com/iax.pdf

Acronyme