Причины отказа программного обеспечения

Большинство программных проектов терпят неудачу полностью или частично, потому что небольшое количество проектов отвечает всем их требованиям. Этими требованиями могут быть затраты, сроки, качество или требования. Согласно многим исследованиям, уровень отказов программных проектов составляет от 50% до 80%. Это эссе является компиляцией причин сбоя проектов разработки программного обеспечения; это эссе суммирует несколько областей, которые играют жизненно важную роль в сбое программного проекта.

Итак, что на самом деле является причиной отказа программного проекта? Печальный факт заключается в том, что программные проекты терпят неудачу, потому что мы не понимаем, что хорошие технические принципы должны применяться к проектам программного обеспечения так же, как и к строительству офисных зданий. Мы пытаемся защитить себя, заявив, что разработка программного обеспечения «разная».

Одной из наиболее серьезных жалоб на отказ программного обеспечения является невозможность

с приемлемой точностью оценить затраты, ресурсы и график

для программного проекта. Традиционные методы оценки всегда производили

положительные результаты, которые вносят вклад в слишком известную стоимость зараженных и

расписание скольжения.

За последние 20 лет многие методы оценки затрат и расписания были

используется со смешанным ощущением из-за ограничений моделей оценки. Главный

часть сбоев оценок может быть вызвана недостаточным пониманием

процесс разработки программного обеспечения и влияние этого метода, используемого в проекте

план, график и сметы расходов.

Примеры сбоев

Ниже приведены некоторые из рассмотренных тематических исследований, которые будут проанализированы для извлечения

основные причины отказа программного обеспечения.

Университет Нортумбрии разработал бухгалтерское программное обеспечение для управления своим повседневным

бизнес. Проект не смог найти желаемых результатов и не смог

соответствуют срокам. Исследования показали, что основное управление проектами

процедуры не соблюдались. Это тематическое исследование упоминается в этом эссе на

при необходимости. [1]

Тайский филиал (SMTL) многонациональной компании в Гонконге (SMHK)

занимается изготовлением электронного оборудования. Они внедрили

интегрированный пакет программного обеспечения; что было неудачей при нескольких факторах. Эти

факторы были в основном связаны с управлением. Такие, как плохой подход между бизнесом

допущения процесса, вписанные в программное обеспечение и бизнес-процессы в SMTL,

плохое лидерство на разных уровнях, культурные различия, организационные

и плохое управление человеческими ресурсами.

Госпиталь Св. Иоанна — это районный больница общего профиля, которая предоставляет медицинские и

сестринские услуги, включающие как общую хирургию, так и медицину. Все эти
Услуги
поддерживаются диагностической визуализацией, лабораторией, скорой помощью, аптекой

и терапевтические услуги, которые находятся на территории. В качестве основной больницы в туристической

он имеет дело со многими посетителями в праздничный сезон, создавая большой

количество незарегистрированных поступлений за регистрацию.

Управление программным обеспечением и лидерство

Было неоднократно показано, что эффективное лидерство имеет важное значение для успешной реализации ИТ (Klenke, 1994). Лидер должен также обладать культурной чувствительностью, навыками общения, творчеством, способностью делегировать, а также способностью развивать и удерживать человеческие ресурсы (Luthans, 1994). Менеджер программного обеспечения в (SMHK) был западным, где нижние менеджеры были восточными. Так что всегда происходило культурное столкновение. Джек (менеджер) всегда пытается представить творческие мысли. И большую часть времени нижнее руководство не могло их сделать. Следовательно, все время происходило столкновение.

Сотрудники также считали, что руководство почти никогда не «слушало» их проблемы

или попытались обратиться к ним. Следовательно, многие сотрудники были готовы уйти

и сделали это, как только они нашли альтернативные возможности в других

компании.

Планирование и планирование проекта

Планирование проекта означает создание разбивки на работу, а затем распределение обязанностей разработчикам с течением времени. Планирование проекта состоит из построения различных задач, сроков и основных путей, включая диаграммы Ганта и диаграммы PERT, а также различные письменные планы для различных ситуаций.

В процессе разработки программного обеспечения вполне нормально работать с

дата завершения проекта, что приводит к сбою полного программного обеспечения. это

невозможно, что проект может быть эффективно выполнен с этапа планирования

к этапу реализации.

Распределение ролей и обязанностей должно быть четко определено, и оно

становится решающим при найме стойла извне. Высший университет

руководство не применяло основные правила управления проектами, которые

.

Правильное планирование также требуется до начала проекта. Это

включает планирование времени, планирование команд. Менеджеры проекта не знают, что

они должны планировать и планировать. Они просто говорят программисту, что делать

и программисты могут придумать правильное решение.

Разработка была перенесена в новый офис, и офис не был полностью

оснащена надлежащей инфраструктурой. Поскольку время также является большим фактором успеха

или провал проекта. Поэтому он отложил процесс разработки и

в сторону отказа проекта. Инфраструктура не была полностью запланирована и

команда менеджеров не знала, где и как будет развиваться проект

.

Совершенно секретно, что победоносный проект разработки программного обеспечения — это контроль над

качество вверх и снизить риск. План непредвиденных обстоятельств также является частью планирования. В

дело пошло не так, тогда этот план может быть применен, чтобы снизить влияние

провал проекта. То же самое было и с бухгалтерским программным обеспечением университета.

не было такого плана действий в чрезвычайных ситуациях, и они не оценили риск

участвует в разработке новой системы. Так что это вызвало больше проблем без

резервная система или план резервного копирования.

Руководство просто пытается следовать методологиям вроде SDLC или RAD, но не знает, какую методологию использовать и в какое время следует применять правильную технику.

] Оценка стоимости

. Оценка стоимости в основном связана с затратами на создание программного проекта. Но это не ограничивается только усилиями. Он также включает в себя стоимость аппаратного и программного обеспечения, обучение сотрудников и клиентов, поездки на клиента, сетевые и коммуникационные расходы. Оценка стоимости должна быть выполнена в рамках модели программного процесса.

Оценка стоимости должна быть выполнена задолго до начала проекта

развития. Неспособность бюджетирования к стоимости проекта приводит к

полная катастрофа. Как указано выше, стоимость инфраструктуры, инструменты разработки

стоимость и стоимость оборудования также должны быть оценены первыми.

То же самое произошло с развитием системы бухгалтерского учета университета. Oни

хорошо приобрел новую систему без какой-либо серьезной оценки стоимости и

источники дохода.

Ниже приведены причины неправильной оценки стоимости.

Методология неудовлетворительной оценки

Еще одной причиной может быть использование методологии несоответствующей оценки затрат. Ни одна методология не лучше других. Каждая методология имеет свои сильные и слабые стороны, которые следует учитывать. В книге доктора Барри Бемма «Software Engineering Economics» перечислены семь методологий оценки. Одна или несколько из этих методологий могут использоваться для оценки стоимости проекта

«Хорошее предложение состоит в том, что более чем одна методология оценки стоимости программного обеспечения

следует использовать для точной оценки ».

Инструменты оценки затрат

В ручной калькуляции затрат есть много недостатков. Этот метод почти устарел сейчас. В эти дни успешная оценка стоимости включает использование соответствующих коммерческих инструмент оценки стоимости программного обеспечения.

Хорошие инструменты оценки программного обеспечения не всегда гарантируют надежное программное обеспечение

оценка. Неправильный ввод размера программного обеспечения приведет к неправильной оценке.

Программное обеспечение для оценки также необходимо настроить для конкретной потребности

организации. Эти настройки требуют данных из прошлых проектов как

ввод для инструмента для оценки.

Существует ряд причин, по которым эти инструменты могут вернуть неправильную оценку.

Выбор правильного инструмента оценки

Для правильной оценки необходим правильный инструмент оценки. Инструмент не способен обрабатывать входные данные, и поэтому может возникнуть неправильная оценка и, следовательно, привести к сбою программного проекта.

Простота настройки

Как уже упоминалось выше, выбранный инструмент должен настраиваться в соответствии с потребностями организации, чтобы организация могла настроить его в соответствии с потребностями и данными прошлых проектов.

Прост в использовании и учебе

Инструмент оценки стоимости должен быть прост в использовании и учебе. Он должен включать в себя помощь и примеры, простой и прямой интерфейс пользователя. Он должен требовать меньше обучения для изучения системы, и исходные данные должны быть четко определены.

Точная оценка

Инструмент оценки должен иметь возможность анализировать все параметры и получать точную оценку стоимости.

Управление рисками

Управление рисками является важным фактором для отказа программного проекта, если он не является управляемых своевременно и эффективно. Поскольку ничто не может быть предсказано, что то, что будет происходить в будущем, поэтому мы должны предпринять необходимые шаги в настоящем, чтобы принять любую неопределенную ситуацию в будущем.

Идентификация риска

Согласно проекту Universal Risk Project существует два типа условий, которые могут быть символом риска.

]

  • Заявления IF-THEN
        

    • «Технология IF недоступна, ТОГДА мы не выполним требования»
    • «Если мы не сможем нанять достаточных квалифицированных инженеров-программистов, ТОГДА мы не сможем выполнить запланированный график разработки
  • CONDITION-CONSEQUENCE Заявления

    [19659042] Учитывая «условие», существует вероятность того, что произойдет «следствие»

  • «Учитывая, что этот конкретный тест терпит неудачу (СОСТОЯНИЕ), ПОСЛЕДСТВИЯ — это то, что запланированное расписание будет проскальзывать»

Руководители проектов имеют определить области, в которых может быть риск, и как это

может повлиять на разработку проекта. Риск может носить технический характер или

нетехнический. Руководители проектов должны знать обо всех рисках. Большинство из

Менеджеры проектов не очень хороши ни в одной из сторон. Хороший менеджер с

навыки программирования могут быть хорошими при определении технического риска, но не в

технический риск.

Анализ рисков

После определения риска необходимо сделать категории этого риска. Анализ рисков — это процесс изучения результатов и результатов проекта после анализа риска и применения метода для снижения риска. После того, как анализ риска будет завершен, необходимо провести надлежащий план анализа рисков, чтобы справиться с какой-либо неопределенной ситуацией. Первые выявленные риски классифицируются и определяют иерархию этих рисков. На данный момент риск классифицируется как положительный или отрицательный риск.

Приоритизация рисков

После анализа риска следующий шаг — это приоритеты риска. Сначала сначала сосредоточьтесь на самом серьезном риске; и les sever позже. Эти факторы риска могут время от времени работать, так что окончательный проект не будет подвержен риску. Поэтому большую часть времени команда по управлению проектами не может идентифицировать степень риска и работать с менее серьезным риском. Это часто приводит к форме кризиса.

Предотвращение рисков

. Работа с риском — это искусство. В некоторых случаях руководство принимает проекты, не определяя надлежащий риск, связанный с проектом. Таким образом, опытный менеджер возьмет проект после надлежащего анализа рисков и избежит любого риска, связанного с проектом.

Управление рисками

Управление рисками для достижения желаемых результатов и результатов осуществляется путем контроля риска на его Лучший. Это чистый интуитивный процесс и зависит от опыта команды управления проектами или риска, который уже был реализован в прошлых проектах, которые были сделаны той же организацией.

Заключение

В этом эссе представлено три основных фактора, которые может привести к сбою проекта разработки программного обеспечения. Планирование и планирование, оценка затрат и управление рисками. Все эти факторы должны рассматриваться на уровне управления, а затем передаваться нижнему управлению.

Планирование и планирование планируются на начальном этапе, хорошее планирование и планирование

прочный фундамент для программного проекта. Планирование проекта состоит из

строительство различных задач, временных рамок и основных путей, включая Ганта

диаграммы PERT и различные письменные планы для различных ситуаций. Если

эти факторы не принимаются во внимание, тогда программное обеспечение может столкнуться с проблемами

во время разработки, и конечный продукт будет неудачным.

Оценка стоимости зависит от бюджета проекта, типа клиента и

размер и усилия, которые будут включены в проект. Оценки затрат выполняются много раз

в течение жизненного цикла проекта. Это влияет на проект во многих отношениях, неправильно

оценка полного сбоя, влияет на добрую волю организации, если

расходы не покрываются, затрагиваются заинтересованные стороны и теряются ресурсы.

Управление риском является практическим подходом к уменьшению двусмысленности и

возможные потери, связанные с проектом разработки программного обеспечения. Потенциальные меры

можно рассматривать как ориентированный на возможности (положительный риск), если их последствия

являются благоприятными или с точки зрения угрозы (отрицательный риск), если их последствия

неблагоприятным.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *