La plupart des projets de logiciel échoue ou des échecs partiels, car un petit nombre de projets répondent à toutes leurs exigences. Ces exigences peuvent être les coûts, délais, qualité, ou des objectifs exigences. Selon plusieurs études, le taux d'échec des projets logiciels est comprise entre 50% - 80%. Cet essai est une compilation des causes d'échec des projets de développement de logiciels; cet essai résume plusieurs domaines qui jouent un rôle essentiel dans l'échec des projets logiciels.
Alors, quelle est réellement la cause de l'échec des projets logiciels? La triste réalité est que les projets logiciels échoue parce que nous ne reconnaissons pas que les principes de l'art doit être appliquée aux projets de logiciels tout comme ils sont à la construction des immeubles de bureaux. Nous essayons de nous défendre en disant que la construction de logiciel est «différent».
L'une des plaintes les plus graves contre l'échec est l'incapacité de logiciels
d'estimer avec une précision acceptable le coût, les ressources nécessaires et le calendrier
pour un projet de logiciel. Méthodes d'évaluation classiques ont toujours produit
résultats positifs qui contribuent à la trop connue coût infestés et
Horaire de patinage.
Au cours des 20 dernières années, le coût de nombreuses techniques d'estimation et le calendrier ont été
utilisé avec la sensation mitigés en raison des restrictions des modèles d'évaluation. Une importante
une partie d'échec estimations de la peut être dû à un manque de compréhension de la
processus de développement logiciel et l'effet de cette méthode utilisée dans le projet
plan, le calendrier et les coûts estimatifs.
Erreur d'études de cas
Voici quelques-uns de ces études de cas qui seront analysés pour aller chercher
les principales raisons de l'échec du système logiciel.
Northumbria University a développé un logiciel de comptabilité pour gérer son jour le jour
entreprise. Le projet n'a pas pu aboutir au résultat espéré et a omis de
respecter les délais. Te enquêtes ont montré que la gestion de base du projet
procédures n'étaient pas respectées. Cette étude de cas est référencée dans cet essai à
différents points si nécessaire. [1]
Thai filiale (SMTL) d'un basé à Hong Kong multinationale (SMHK)
oeuvrant dans la fabrication de matériel électronique. Ils ont mis en œuvre un
progiciel intégré, ce qui a été un échec à l'plusieurs facteurs. Ces
facteurs étaient surtout de gestion connexes. Comme une mauvaise adéquation entre l'entreprise
hypothèses processus inscrit dans le logiciel et les processus d'affaires dans SMTL,
piètre leadership à différents niveaux, les différences culturelles, organisationnelles
environnement, et la mauvaise gestion des ressources humaines.
Hôpital St John's est un District General Hospital fournit médicaux et
services de soins infirmiers, qui comprend à la fois la chirurgie générale et medicine.All ces
services sont soutenus par l'imagerie diagnostique, de laboratoire, d'ambulance, pharmacie
et les services de thérapie, qui sont tous sur le site. Comme le grand hôpital dans une structure touristique
, la zone elle traite avec beaucoup de visiteurs pendant la saison des vacances, générant un grand
montant de la non-réservées admissions travail.
Software Management & Leadership
Il a été démontré à maintes reprises, que le leadership efficace est essentiel pour réussir l'application des TI (Klenke, 1994). Un leader doit aussi avoir une sensibilité culturelle, la communication, créativité, capacité à déléguer, et la capacité à développer et retenir les ressources humaines (Luthans, 1994). Le gestionnaire de logiciels au (SMHK) est un western, où les gestionnaires ont été inférieures de l'Est. Il ya donc eu un choc culturel se passe toujours. Jack (Manager) cherchent toujours à introduire des idées créatives. Et la plupart du temps, la gestion moindres ne pouvait pas les faire. Il y avait donc un conflit en cours tout le temps.
Les employés ont également estimé que la gestion presque jamais "écouté" à leurs préoccupations
ou tenté d'y remédier. En conséquence, de nombreux employés étaient impatients de quitter
l'entreprise, et l'ont fait dès qu'ils trouvent des possibilités de rechange dans d'autres
entreprises.
Project Planning & Scheduling
Projet de planification des moyens pour créer de répartition du travail, puis répartir les responsabilités à tous les développeurs dans le temps. La planification de projet comprend la construction de diverses tâches, des échéanciers et des pistes essentielles, y compris des diagrammes de Gantt et diagrammes de PERT et les différents programmes écrits pour différentes situations.
Il est tout à fait normal dans le processus de développement de logiciels pour travailler en arrière de la
la fin du projet qui aboutit à un échec complet des logiciels du projet. C'est
impossible qu'un projet peut être réalisé efficacement à partir du stade de la planification
à l'étape de mise en œuvre.
Répartition des rôles et des responsabilités doit être clairement défini et il
devient crucial tout en engageant le décrochage de l'extérieur. Université supérieur
direction a échoué à appliquer les règles de base en gestion de projet qui a jeté à la
échec du projet.
Une bonne planification est également requise avant le début du projet. Il
comprend la programmation en temps, des équipes de planification. Les gestionnaires de projet ne savent pas ce
qu'ils doivent planifier et du calendrier. Ils viennent de dire que le programmeur ce qu'il faut faire
et que les programmeurs peuvent trouver une solution appropriée.
Le développement a été déplacé vers un nouveau bureau et le bureau n'a pas été entièrement
doté d'une infrastructure adéquate. Comme le temps est aussi un facteur important dans la réussite
ou l'échec d'un projet. Ainsi, il a retardé le processus de développement et a contribué
vers l'échec du projet. Infrastructures n'a pas été entièrement programmée et
équipe de direction ne savait pas où et comment le développement du projet sera
commencé.
Le secret d'un projet lauréat de développement de logiciels est de contrôler la
la qualité et réduire le risque. Plan d'urgence est aussi la partie de la planification. Dans
cas les choses allaient mal tourner, ce plan peut être suivie pour réduire l'effet de la
échec du projet. Même a été le cas avec les logiciels comptables université. Le
équipe de direction n'a pas eu un tel plan d'urgence n'a pas non plus ils évaluent le risque
impliqués dans le développement du nouveau système. C'est donc causé plus d'ennuis sans
le système de sauvegarde ou d'un plan de sauvegarde.
La gestion essayez juste de suivre les méthodologies comme SDLC ou RAD, mais vous ne savez pas quelle méthodologie à utiliser et à quel moment devrait appliquer la bonne technique.
Cost Estimation
Estimation des coûts est principalement impliqué le coût de l'effort pour réaliser le projet de logiciel. Mais il n'est pas limité à l'effort uniquement. Elle comprend aussi le matériel et le coût des logiciels, la formation des employés et des clients circulant vers le client, les réseaux et les coûts de communication. L'estimation des coûts devrait être réalisé dans le cadre du modèle de processus logiciels.
Estimation des coûts doit être fait bien avant le début du projet
développement. Échec de la budgétisation du coût des résultats des projets en
complète des catastrophes. Comme indiqué au-dessus du coût des infrastructures, des outils de développement
coût et du coût du matériel doit également être estimée en premier.
La même chose s'est passé au développement du système universitaire de comptabilité. Ils
acheté le nouveau système bien avec toute estimation sérieuse des coûts et
les sources de revenus.
Voici les raisons pour lesquelles l'estimation des coûts mal est fait.
Inappropriées et méthodologie d'estimation
Une autre raison serait l'utilisation d'une méthodologie inadaptée d'estimation des coûts. Pas une seule méthodologie est mieux que d'autres. Chaque méthode a ses propres points forts et faibles qui devraient être pris en considération. Dr. Barry Boehm's Book Software Engineering Economics listes sept méthodes d'estimation. Un ou plusieurs de ces méthodologies peuvent être utilisées pour estimer le coût d'un projet
"Good suggestion est que plus d'une méthodologie d'estimation des coûts logiciels
devraient être utilisées pour l'estimation exacte ".
Coût des outils d'estimation
Il ya beaucoup d'inconvénients dans l'estimation des coûts manuel. Cette technique est presque obsolète maintenant. Ces jours-estimation des coûts de succès comprend l'utilisation du coût approprié de logiciels commerciaux estimation outil.
Les bons logiciels outils d'estimation ne garantissent pas toujours un logiciel fiable
estimations. Mauvaise entrée de la taille du logiciel se traduira dans l'estimation erronée.
Logiciel d'estimation doit également être personnalisés pour répondre aux besoins spécifiques de
organisation. Ces personnalisations exiger les données des projets passés comme
d'entrée pour l'outil à estimer.
Il ya nombre de raisons, ces outils peuvent retourner à l'estimation erronée.
Choisir l'outil d'estimation droit
Choix d'un outil d'estimation droit est nécessaire pour l'estimation de droite. L'outil n'est pas capable de gérer l'entrée et il peut ainsi arriver à l'estimation erronée et, partant, entraîner le projet de logiciel à l'échec.
Facilité de personnalisation
Comme mentionné ci-dessus, sélectionnez l'outil doit être personnalisable en fonction de l'organisation a besoin, de sorte que l'organisation peut personnaliser en fonction des besoins et des données du projet passé.
Facile à utiliser et à apprendre
L'outil d'estimation des coûts devrait être facile à utiliser et à apprendre. Elle doit inclure l'aide et des exemples, simples et droites interface utilisateur de l'avant. Il faut exiger moins de formation pour apprendre le système et les intrants doivent être bien définis.
Accurate Estimation
L'outil d'estimation doit avoir la capacité d'analyser tous les paramètres et est venue l'estimation précise des coûts.
Gestion des risques
La gestion du risque est un facteur important vers l'échec du projet de logiciel si elle n'est pas gérée en temps opportun et efficacement. Comme rien ne peut prédire que ce qui se passera à l'avenir, nous devons donc prendre les mesures nécessaires dans le présent pour prendre n'importe quelle situation incertaine dans l'avenir. La gestion des risques signifie qu'ils doivent traiter avec un souci avant qu'il ne devienne une crise.
Identification des risques
Selon le risque Universal Project, il existe deux types de conditions qui peuvent être un symbole de «risque».
- If-then
- «Si la technologie n'est pas disponible, alors nous ne pourrons pas répondre à l'exigence"
- "Si nous ne pouvons pas recruter en nombre suffisant d'ingénieurs logiciels qualifiés, on ne peut pas respecter le calendrier de développement planifié
- CONDITION-conséquence Déclarations
- Compte tenu de la «condition», il existe une probabilité que la «conséquence» aura lieu
- "Etant donné que ce test spécifique échoue (la condition), la conséquence est que le calendrier prévu glissera"
Les gestionnaires de projet doivent identifier les zones où le risque peut être et comment il
peut affecter le développement du projet. Le risque peut être de nature technique ou
non techniques. Les gestionnaires de projet doivent être conscients des risques. La plupart des
les gestionnaires de projets ne sont pas bonnes dans l'un des côtés. Un bon gestionnaire avec
compétences en programmation peut être bon dans l'identification des risques techniques, mais pas de la non
technique de ce risque.
Analyse des risques
Après le risque est identifié, il est nécessaire de faire des catégories de ce risque. L'analyse des risques est le processus d'examen des résultats et livrables du projet, après l'analyse des risques et l'application de la technique pour réduire le risque. Après une analyse des risques est terminée, le plan adéquat d'analyse de risque doit être fait pour faire face à toute situation d'incertitude. D'abord identifié les risques sont classés par catégorie et de faire la hiérarchie de ces risques. À ce stade, le risque est classé comme les risques positifs ou négatifs.
Risk Prioritization
Après que le risque est analysé, l'étape suivante consiste à les priorités du risque. À se concentrer d'abord sur les plus sever premier risque, et les couper plus tard. Ces facteurs de risque a travaillé de temps à autre afin que le projet final à venir est sans risque. Ainsi, la plupart de l'équipe de gestion du temps ne parvient pas à identifier le risque de rompre et de travailler sur les moins sever risque. Il en résulte souvent la forme d'une crise.
La réduction des risques
Le traitement du risque est un art. Quelques fois la direction prend les projets à identifier les risques aura été dûment impliqués dans le projet. Ainsi, un gestionnaire expérimenté prendra le projet après analyse adéquate des risques et d'éviter tout risque impliqués dans le projet.
Contrôle des risques
Gestion des risques liés à la réalisation des résultats escomptés et les réalisations attendues se fait à travers la maîtrise du risque à son meilleur. Il s'agit d'un processus intuitif pur et dépend de l'expérience de l'équipe de gestion de projet, ou le risque déjà réussi dans des projets antérieurs qui ont été effectuées par la même organisation.
Conclusion
Cet essai a présenté trois facteurs de base qui peut provoquer le projet de développement logiciel à l'échec. Planning & Ordonnancement, estimation des coûts et gestion des risques. Tous ces facteurs doivent être considérés au niveau de la direction, puis transféré à la gestion inférieurs.
Planning & Scheduling vient d'abord, une bonne planification et d'ordonnancement rend la
fondation solide pour le projet de logiciel. La planification de projet se compose de
la construction de diverses tâches, des échéanciers et des pistes essentielles, y compris de Gantt
graphiques et diagrammes de PERT et les différents programmes écrits pour différentes situations. Si
ces facteurs ne sont pas pris en faisait alors partie du logiciel mai rencontrez des problèmes
lors de l'élaboration et le produit final sera un échec.
Estimation des coûts dépend du budget du projet, type de client et le
taille et l'effort d'être mis dans le projet. Estimations de coûts sont fait à plusieurs reprises
au cours du cycle de vie d'un projet. Elle affecte le projet à bien des égards, faux
estimation échec complet, une incidence sur la bonne volonté de l'Organisation si le
coûts ne sont pas couverts, les parties prenantes sont concernées et le gaspillage des ressources.
La gestion du risque est une approche pratique pour réduire l'ambiguïté et
éventuelles pertes liées à un projet de développement de logiciels. Mesures potentielles
peut être considérée comme une opportunité axé (risque positif) si leurs conséquences
sont favorables, ou comme menace ciblée (risque négatif) si leurs conséquences sont
défavorable.
