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

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

Введение моделей:
“Управление проектами-это дисциплина организации и управления ресурсами (например. Людьми) таким образом. Чтобы проект был завершен в рамках определенных ограничений по объему, качеству. Времени и затратам. Проект-это временное и разовое усилие. Предпринятое для создания уникального продукта или услуги. Которое приносит полезные изменения или добавленную стоимость.”

Цель управления программными проектами состоит в том. Чтобы понимать. Планировать. Измерять и контролировать проект таким образом. Чтобы он был выполнен в срок и в рамках бюджета.

Это включает в себя сбор требований. Управление рисками. Мониторинг и контроль прогресса. А также следование процессу разработки программного обеспечения.

Управление проектами программного обеспечения требует подготовленных и опытных инженеров-программистов. Чтобы повысить вероятность успеха проекта. Поскольку разработка программного обеспечения для крупных проектов чрезвычайно сложна. А следование строгим инженерным принципам поможет снизить риски. Связанные с проектом.

Управление программными проектами чрезвычайно важно по следующим причинам:

  • Разработка программного обеспечения крайне непредсказуема: [по состоянию на 2007 год] только около 10% проектов выполняются в рамках первоначального бюджета и по графику.

  • Управление оказывает большее влияние на успех или неудачу проекта. Чем технический прогресс.
  • Слишком часто бывает слишком много лома и переделок. Весь процесс очень незрелый. Не хватает повторного использования.

Согласно 10-му изданию ежегодного отчета о ХАОСЕ от Standish Group. Только 34% проектов завершены успешно. Хотя это на самом деле представляет собой огромное улучшение, очевидно. Еще есть место для большего! Почему все стало лучше?

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

Когда проект терпит неудачу. Не только продукт не поставляется. Но и все деньги. Вложенные в продукт. Также теряются. Без надлежащего управления программным обеспечением даже завершенные проекты будут доставлены с опозданием и сверх бюджета. Взгляните на некоторые из них

Пример:
В отчете о ХАОСЕ за 2004 год. Озаглавленном В отчете за 2004 год было установлено. Что общие расходы на проекты составили 255 миллиардов долларов

, а в 1994 году группа Стэндиша подсчитала. Что американские ИТ-проекты потратили впустую 140 миллиардов долларов. Из которых 80 миллиардов были потрачены на неудачные проекты из общего объема расходов на проекты в 250 миллиардов долларов.

Если риска неудачи и потери денег недостаточно. Чтобы убедить вас в важности правильного управления программным обеспечением, подумайте. Что какое-то программное обеспечение также поставит под угрозу жизнь людей. Читайте Ужасные истории программного обеспечения или Худшие ошибки в истории программного обеспечения. Чтобы увидеть некоторые примеры…

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

Так почему же программное обеспечение все равно терпит неудачу? Вот список из спектра IEEE:

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

  • Плохое управление проектами
  • Политика заинтересованных сторон
  • Коммерческое давление

Неудачи программных проектов имеют много общего с авиакатастрофами. Точно так же. Как пилоты никогда не собираются терпеть крушение. Разработчики программного обеспечения не стремятся потерпеть неудачу. Когда коммерческий самолет терпит крушение. Следователи обращают внимание на многие факторы. Такие как погода. Данные технического обслуживания. Расположение и подготовка пилота. А также культурные факторы внутри авиакомпании. Точно так же нам нужно взглянуть на бизнес-среду. Технический менеджмент. Управление проектами и организационную культуру. Чтобы добраться до корней программных сбоев.

ДЕЙСТВИЯ ПИЛОТА НЕПОСРЕДСТВЕННО ПЕРЕД крушением самолета всегда вызывают большой интерес у следователей. Это потому. Что пилот является конечным лицом. Принимающим решения. Ответственным за безопасную эксплуатацию корабля. Точно так же руководители проектов играют решающую роль в проектах программного обеспечения и могут быть основным источником ошибок. Которые приводят к сбою.

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

Решения по управлению проектами часто бывают сложными именно потому. Что они предполагают компромиссы. Основанные на нечетких или неполных знаниях. Оценка того. Сколько будет стоить ИТ-проект и сколько времени он займет. — это не только наука. Но и искусство. Чем крупнее или новее проект. Тем менее точны оценки. В отрасли ходит шутка. Что оценки ИТ-проектов в лучшем случае находятся в пределах 25% от их истинной стоимости в 75% случаев.

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

Еще одна проблема. Отличающая программную инженерию от других инженерных областей. Заключается в том. Что программное обеспечение не является конкретным. Существует распространенное заблуждение. Что программное обеспечение можно легко изменить. Чтобы сделать что угодно. Независимо от того. На какой стадии находится проект в данный момент. Если строительство здания или моста почти завершено. Люди понимают. Что уже слишком поздно вносить существенные изменения в архитектуру или дизайн. Однако с программным обеспечением у клиентов. Как правило. Складывается впечатление. Что внесение изменений всегда легко. Даже если конечный результат может быть эквивалентен сносу почти законченного здания!

Распространенное заблуждение состоит в том. Что разработка программного обеспечения означает написание кода, что. Безусловно, не так. Написание кода само по себе составляет лишь около 40% разработки программного обеспечения. Есть много других важных шагов. Таких как требования. Конфигурация. Развертывание и обслуживание.

Основная цель управления проектами программного обеспечения-попытаться снизить риски. Связанные с проектом. Таким образом. Чтобы проект мог быть завершен в соответствии с бюджетом и в срок со всеми функциями. Желаемыми клиентами..

Управление проектами помогает нам достичь следующих целей:

  • Оцените бюджет. Необходимый для завершения проекта до его начала. И следите за его ходом. Чтобы в любой момент времени мы знали. Сколько стоит проект и сколько еще он будет стоить.
  • Оцените время. Необходимое для завершения проекта до его начала. И следите за ходом выполнения. Чтобы в любой момент времени мы знали. Сколько времени осталось до завершения.
  • Оцените, какие функции могут быть разработаны в заданные временные и стоимостные рамки.
  • Отслеживает ход выполнения проекта. И поэтому мы знаем. Какие функции были завершены. А какие будут завершены до конца проекта.
  • Поставляемое программное обеспечение должно обеспечивать все функции. Указанные в требованиях (feature complete). Таким образом. Управление проектами помогает руководителям проектов заново согласовать функции и требования.
  • Пользователи программного обеспечения относятся к числу худших клиентов в инженерном деле. Без особых жалоб считается само собой разумеющимся. Что программное обеспечение имеет ошибки. Время от времени выходит из строя. Иногда не работает и слишком сложно устанавливается и используется. Качество должно быть заданной частью объема; завершенные функции должны быть высокого качества.
  • Поскольку управление проектами так важно. Мы должны уметь ранжировать организации с точки зрения их программных возможностей и зрелости. Для достижения этой цели мы используем Модель Capability and Maturity Model (CMM).
  • CMM ранжирует процесс разработки программного обеспечения фирмы используя 5 уровней зрелости

Материал для инженерных исследований

Модель водопада:
Модель водопада — это популярная версия модели жизненного цикла разработки систем для разработки программного обеспечения. Часто рассматриваемая как классический подход к жизненному циклу разработки систем. Модель водопада описывает метод разработки. Который является линейным и последовательным. Развитие водопада имеет четкие цели для каждой фазы развития. Представьте себе водопад на вершине крутой горы. Как только вода переливается через край утеса и начинает свой путь вниз по склону горы. Она уже не может повернуть назад. То же самое происходит и с развитием водопада. Как только фаза развития завершена. Развитие переходит к следующей фазе. И пути назад уже нет.

Инженерный Учебный Материал

Преимущества модели водопада:

  • Эта модель проста и удобна для понимания и использования.
  • Им легко управлять благодаря жесткости модели – каждый этап имеет конкретные результаты и процесс обзора.
  • В этой модели этапы обрабатываются и завершаются по одному. Фазы не перекрываются.
  • Модель водопада хорошо работает для небольших проектов. Где требования очень хорошо понятны.

Недостатки модели водопада:

  • Как только приложение находится на стадии тестирования. Очень трудно вернуться назад и изменить что-то. Что не было хорошо продумано на стадии концепции.
  • Ни одно работающее программное обеспечение не производится до конца жизненного цикла.
  • Высокий уровень риска и неопределенности.
  • Не очень хорошая модель для сложных и объектно-ориентированных проектов.
  • Плохая модель для длительных и текущих проектов.
  • Не подходит для проектов. Где требования находятся под умеренным или высоким риском изменения.

Когда использовать модель водопада:

  • Эта модель используется только тогда. Когда требования очень хорошо известны. Понятны и фиксированы.
  • Определение продукта является стабильным.
  • Технология понятна.
  • Двусмысленных требований нет
  • Достаточные ресурсы с необходимым опытом доступны бесплатно
  • Проект короткий.

В разработке продукта участвует очень мало действий по вводу клиента. После того. Как продукт будет готов. Только он может быть демонтирован конечным пользователям. Как только продукт разрабатывается и если происходит какой-либо сбой. То стоимость устранения таких проблем очень высока. Потому что нам нужно обновлять везде. Начиная с документа и заканчивая логикой.

:
Вставьте предварительную фазу разработки программы между фазой формирования требований к программному обеспечению и фазой анализа. С помощью этого метода разработчик программы гарантирует. Что программное обеспечение не выйдет из строя из-за хранения. Синхронизации и потока данных (непрерывное изменение). По мере продолжения анализа на следующей фазе разработчик программы должен накладывать на аналитика ограничения по хранению. Времени и эксплуатации таким образом. Чтобы он чувствовал последствия. Если общие ресурсы. Подлежащие применению. Недостаточны или если эмбриональный(на ранней стадии разработки) операционный проект неверен. Он будет признан на этой ранней стадии. И итерация с требованиями и предварительным дизайном может быть переделана до начала окончательного проектирования. Кодирования и тестирования. Как реализуется эта процедура разработки программы? Для этого необходимо выполнить следующие действия:

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

Проектируйте. Определяйте и распределяйте режимы обработки данных даже с риском ошибиться. Выделите функции обработки. Спроектируйте базу данных. Выделите время выполнения. Определите интерфейсы и режимы обработки с операционной системой. Опишите обработку ввода и вывода и определите предварительные операционные процедуры.

Напишите обзорный документ. Который будет понятен. Информативен и актуален. Чтобы каждый сотрудник проекта мог получить элементарное представление о системе.

Документируйте дизайн
Объем документации. Необходимой для большинства программ. Довольно велик. И, конечно. Намного больше. Чем большинство программистов. Аналитиков или разработчиков программ готовы сделать. Если предоставить их самим себе. Зачем нам столько документации? (1) Каждый дизайнер должен общаться с дизайнерами. Менеджерами и, возможно. С заказчиками. (2) На ранних стадиях документация-это проект. (3) Реальная денежная стоимость документации заключается в поддержке последующих модификаций отдельной тестовой группой. Отдельной командой технического обслуживания и операционным персоналом. Не владеющим программным обеспечением.

Сделай это дважды
Если компьютерная программа разрабатывается впервые. Организуйте все так. Чтобы версия. Наконец доставленная заказчику для оперативного развертывания. Была фактически второй версией в том. Что касается критического проектирования/операций. Обратите внимание. Что это просто весь процесс. Выполненный в миниатюре. В масштабе времени. Который относительно мал по отношению к общему усилию. В первой версии команда должна обладать особой широкой компетенцией. Где она может быстро почувствовать проблемные места в дизайне. Смоделировать их. Смоделировать альтернативы. Забыть простые аспекты дизайна. Которые не стоит изучать на этом раннем этапе. И, наконец. Прийти к безошибочной программе.

Планирование. Контроль и мониторинг тестирования
Без сомнения. Самый большой пользователь ресурсов проекта-рабочая сила. Компьютерное время и/или управленческое суждение-это фаза тестирования. Это фаза наибольшего риска с точки зрения затрат и графика. Это происходит в последний момент расписания. Когда альтернативные варианты резервного копирования наименее доступны. Если вообще доступны. Все предыдущие три рекомендации были направлены на выявление и решение проблем перед вступлением в фазу тестирования. Тем не менее. Даже после выполнения этих вещей. Все еще есть тестовая фаза. И есть еще важные вещи. Которые нужно сделать. В том числе:

  1. Наймите команду специалистов по тестированию. Которые не отвечали за оригинальный дизайн;
  2. Используйте визуальные проверки. Чтобы обнаружить очевидные ошибки. Такие как упавшие знаки минуса. Пропущенные коэффициенты двух. Прыжки по неправильным адресам (не используйте компьютер для обнаружения такого рода вещей. Это слишком дорого);
  3. Проверьте каждый логический путь;
  4. Используйте окончательную проверку на целевом компьютере.

По какой-то причине то. Что будет делать проект программного обеспечения. Подлежит широкому толкованию. Даже после предварительного согласования. Важно привлечь клиента формальным образом. Чтобы он взял на себя обязательства на более ранних этапах до окончательной поставки. После определения требований есть три момента. В которых понимание. Суждение и приверженность клиента могут поддержать усилия по разработке. К ним относятся

приемки программного обеспечения

Инженерный Учебный Материал

Обычная производительность управления программным обеспечением.
Традиционные методы управления программным обеспечением обоснованы в теории. Но практика все еще привязана к архаичным технологиям и методам. Традиционная экономика программного обеспечения обеспечивает эталон производительности для традиционных принципов управления программным обеспечением. Самое лучшее в программном обеспечении-это его гибкость: его можно запрограммировать практически на все. Самое худшее в программном обеспечении-это его гибкость: характеристика

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

  1. Разработка программного обеспечения по-прежнему крайне непредсказуема. Только около 10% проектов программного обеспечения успешно реализуются в рамках первоначального бюджета и графика.
  2. Дисциплина управления в большей степени определяет успех или неудачу. Чем технический прогресс.
  3. Уровень лома и переделки программного обеспечения свидетельствует о незрелости процесса.

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

  1. Поиск и устранение проблемы программного обеспечения после поставки обходится в 100 раз дороже. Чем поиск и устранение проблемы на ранних этапах проектирования
  2. Вы можете сжать графики разработки программного обеспечения на 25% от номинального. Но не более.
  3. За каждый 1 доллар. Потраченный на разработку. Вы потратите 2 доллара на техническое обслуживание
  4. Затраты на разработку и обслуживание программного обеспечения в первую очередь зависят от количества исходных строк кода
  5. Различия между людьми объясняют самые большие различия в производительности программного обеспечения
  6. Общее соотношение затрат на программное обеспечение и аппаратное обеспечение продолжает расти. В 1955 году было 15:85, в 1985-85:15.
  7. Только около 15% усилий по разработке программного обеспечения посвящено программированию.
  8. Программные системы и продукты обычно стоят в 3 раза дороже. Чем отдельные программы. Программно-системные продукты (т. е. система систем) стоят в 9 раз дороже.
  9. Пошаговые руководства улавливают 60% ошибок, 80% вклада исходит от 20% участников.

Принципы традиционной программной инженерии
Существует множество описаний инженерного программного обеспечения После многолетнего опыта разработки программного обеспечения индустрия программного обеспечения извлекла много уроков и сформулировала много принципов. В этом разделе описывается один взгляд на современные принципы разработки программного обеспечения в качестве ориентира для введения основных тем. Обсуждаемых в оставшейся части книги. Эталоном, который я выбрал. Является краткая статья под названием Несмотря на свое название. Статья описывает 30 лучших принципов. И это такое же хорошее резюме. Как и любая общепринятая мудрость в индустрии программного обеспечения. Хотя я поддерживаю большую часть этой мудрости, я считаю. Что некоторые из них устарели. Далее курсивом выделены 30 основных принципов Дэвиса. По каждому принципу я комментирую. Поддержит или изменит его точка зрения. Изложенная далее в этой книге. 1. Сделайте

качество #1. Качество должно быть количественно измерено и должны быть созданы механизмы. Чтобы мотивировать его достижение.
определение качества. Соизмеримого с текущим проектом, важно. Но это нелегко сделать в самом начале проекта. Следовательно. Современная структура процесса стремится понять компромиссы между характеристиками, качеством. Стоимостью и графиком как можно раньше в жизненном цикле. До тех пор. Пока это понимание не будет достигнуто. Невозможно определить или управлять достижением качества.
2. Возможно высококачественное программное обеспечение. Методы, которые были продемонстрированы для повышения качества. Включают привлечение клиента. Прототипирование. Упрощение дизайна. Проведение проверок и наем лучших людей.
а Этот принцип в основном избыточен по сравнению с другими.
3. Дайте продукты клиентам рано. Независимо от того. Как сильно вы пытаетесь узнать потребности пользователей на этапе требований. Самый эффективный способ определить реальные потребности-дать пользователям продукт и позволить им играть с ним.
Это ключевой принцип современной технологической структуры. И должно существовать несколько механизмов вовлечения клиента на протяжении всего жизненного цикла. В зависимости от предметной области эти механизмы могут включать демонстрационные прототипы. Демонстрационные вехи и альфа-/бета-релизы.
4. Определите проблему перед написанием требований. Столкнувшись с тем. Что они считают проблемой. Большинство инженеров спешат предложить решение. Прежде чем пытаться решить проблему. Обязательно изучите все альтернативы и не будьте ослеплены очевидным решением.
а Этот принцип является четким указанием на проблемы. Связанные с обычным процессом спецификации требований. Параметры задачи становятся более осязаемыми по мере развития решения. Современная структура процесса развивает проблему и решение вместе. Пока проблема не будет достаточно хорошо понята. Чтобы взять на себя обязательство по полному производству.
4. Оцените варианты проектирования. После согласования требований необходимо изучить различные архитектуры и алгоритмы. Вы, конечно. Не хотите использовать

Материал для инженерных исследований
1. Эволюция экономики программного

обеспечения 2.1 ЭКОНОМИКА программного
обеспечения Большинство моделей затрат на программное обеспечение можно абстрагировать в функцию пяти основных параметров: размер . Процесс, персонал. Окружающая среда и требуемое качество.

  1. Размер конечного продукта (в человеческих компонентах). Который обычно количественно определяется в терминах количества исходных инструкций или количества функциональных точек. Необходимых для разработки требуемой функциональности.
  2. Процесс, используемый для производства конечного продукта. В частности способность процесса избегать деятельности. Не добавляющей ценности (переделки. Бюрократические задержки. Накладные расходы на связь)
  3. Возможности персонала по разработке программногообеспечения и . В частности. Их опыт работы с вопросами информатики и прикладными областями проекта
  4. Среда, которая состоит из инструментов и методов. Доступных для поддержки эффективной разработки программного обеспечения и автоматизации процесса
  5. Требуемое качество продукта. Включая его характеристики. Производительность. Надежность и адаптивность

Отношения между этими параметрами и расчетными затратами могут быть записаны следующим образом:
Усилие = (Персонал) (Окружающая среда)( Качество)( Размер процесса)
Одним из важных аспектов экономики программного обеспечения (представленных в современных моделях затрат на программное обеспечение) является то. Что взаимосвязь между усилиями и размером демонстрирует дисэкономию масштаба. Дисэкономия масштаба разработки программного обеспечения является результатом того. Что показатель процесса больше 1,0. В отличие от большинства производственных процессов. Чем больше программного обеспечения вы создаете. Тем дороже оно стоит на единицу продукции.

На рис. 2-1 показаны три поколения основных технологических достижений в области инструментов. Компонентов и процессов. Необходимые уровни качества и персонала считаются постоянными. Ордината графика относится к затратам на единицу программного обеспечения (выберите свой любимый: на SLOC. На точку функции. На компонент). Реализуемым организацией.

Три поколения разработки программного обеспечения определяются следующим образом:

  1. Обычные: 1960-е и 1970-е годы. Мастерство. Организации использовали пользовательские инструменты. Пользовательские процессы и практически все пользовательские компоненты. Построенные на примитивных языках. Эффективность проекта была в высшей степени предсказуемой в том смысле. Что цели по затратам. Графику и качеству почти всегда оказывались недостижимыми.
  2. Переходный период: 1980-е и 1990-е годы. Разработка программного обеспечения. Некоторые из компонентов (
  3. Современная практика: 2000 и более поздние годы. Производство программного обеспечения. Философия этой книги основана на использовании управляемых и измеряемых процессов. Интегрированных сред автоматизации и в основном (70%) готовых компонентов. Возможно, всего лишь 30% компонентов должны быть изготовлены на заказ

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

Материал для инженерных исследований

Организации достигают лучшей экономии от масштаба в последовательные технологические эры-с очень большими проектами (системами систем). Долгоживущими продуктами и направлениями бизнеса. Включающими несколько аналогичных проектов. На рис. 2-2 представлен обзор того. Как профиль рентабельности инвестиций (ROI) может быть достигнут в последующих усилиях на протяжении жизненного цикла различных областей.

Материал для инженерных исследований


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

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

  1. Какую модель оценки затрат использовать
  2. Измерять ли размер программного обеспечения в исходных строках кода или точках функций
  3. Что составляет хорошую оценку

Существует несколько популярных моделей оценки затрат (таких как COCOMO. CHECKPOINT, ESTIMACS. KnowledgePlan. Price-S, ProQMS. SEER, SLIM. SOFTCOST и SPQR/20). CO COMO также является одной из наиболее открытых и хорошо документированных моделей оценки затрат. Общая точность традиционных моделей затрат (таких как COCOMO) была описана как

Большинство реальных моделей затрат используются снизу вверх (обоснование целевой стоимости). А не сверху вниз (оценка Рис. 2-3 иллюстрирует преобладающую практику: руководитель проекта программного обеспечения определяет целевую стоимость программного обеспечения. А затем манипулирует параметрами и размерами до тех пор. Пока целевая стоимость не будет оправдана. Обоснование целевой стоимости может заключаться в том. Чтобы выиграть предложение. Привлечь финансирование клиентов. Получить внутреннее корпоративное финансирование или достичь какой-то другой цели.

Процесс, описанный на рис. 2-3, не так уж плох. На самом деле. Необходимо объективно проанализировать стоимостные риски и понять чувствительность и компромиссы. Это заставляет руководителя проекта программного обеспечения изучить риски. Связанные с достижением целевых затрат. И обсудить эту информацию с другими заинтересованными сторонами.

:

  • Он задуман и поддерживается руководителем проекта. Командой архитекторов. Командой разработчиков и командой тестирования. Ответственной за выполнение работы.
  • Она принимается всеми заинтересованными сторонами как амбициозная. Но реализуемая.
  • Он основан на четко определенной модели затрат на программное обеспечение с надежной основой.
  • Он основан на базе данных соответствующего опыта проекта. Который включает в себя аналогичные процессы. Аналогичные технологии. Аналогичные среды. Аналогичные требования к качеству и аналогичные люди.
  • Он определен достаточно подробно. Чтобы понять его ключевые области риска и объективно оценить вероятность успеха.

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

Инженерный Учебный Материал