
- •Оглавление
- •Введение.
- •Организация процесса конструирования. Жизненный цикл программных средств.
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования по
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •Модели качества процессов конструирования
- •Планирование программного проекта. Оценка трудоемкости и стоимости программного проекта. Конкурентоспособность.
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе loc- и fp-метрик
- •Конструктивная модель стоимости
- •Модель композиции приложения
- •Модель раннего этапа проектирования
- •Модель этапа постархитектуры
- •Предварительная оценка программного проекта
- •Анализ чувствительности программного проекта
- •Сценарий понижения зарплаты
- •Сценарий наращивания памяти
- •Сценарий использования нового микропроцессора
- •Сценарий уменьшения средств на завершение проекта
- •Организация разработки программного проекта.
- •Кризис программирования и способ выхода из него
- •Модель cmm-sei
- •Управление качеством разработки программного продукта с помощью системы стандартов iso 9001
- •Примерная структура процесса и организации, занимающейся разработкой программных продуктов
- •Внедрение программного проекта.
- •Что такое проект внедрения.
- •Определение стратегических целей проекта и тактического плана внедрения
- •Обучение специалистов группы внедрения.
- •Моделирование бизнеса.
- •Обучение конечных пользователей работе с системой.
- •Опытно-промышленная эксплуатация
- •Ввод системы в промышленную эксплуатацию.
- •Ключевые факторы успеха.
- •Эволюция программного обеспечения.
- •5.1. Наследуемые системы
- •Количество сбоев аппа- Характеризуются ли аппаратные средства высоким уровнем ратных средств и по сбоев в работе? Является ли по поддержки причиной аварийных перезагрузок системы?
- •5.2. Модернизация программного обеспечения
- •Прогнозирование сопровождения
- •5.3. Реинжениринг программного обеспечения
- •Преобразование исходного кода программ
- •Анализ систем
- •Создание программных модулей
- •Создание абстракций данных
- •Изменение данных
- •5.4. Управление конфигурациями
- •Планирование управления конфигурацией
- •Определение конфигурационных объектов
- •База данных конфигураций
- •Управление изменениями
- •Управление версиями и выпусками
- •Идентификация версий
- •Управление выходными версиями
- •Сборка системы
- •Case-средства для управления конфигурацией
- •Средства поддержки управления изменениями
- •Средства поддержки управления версиями
- •Средства сборки систем
- •Экономическая эффективность эксплуатации программного проекта.
- •6.1. Особенности экономики производства крупных программных продуктов
- •6.2. Проблемы анализа экономики производства программных продуктов
- •6.3. Проблемы организации экономически эффективного производства программных продуктов
- •6.4. Оценка стоимости разработки программного обеспечения
- •6.4.1. Линейный метод
- •6.4.2. Метод функциональных точек
- •6.4.3. Оценка с использованием эмпирических данных
- •6.5. Методы оценки эффективности по на этапе эксплуатации
- •Список литературы.
Организация разработки программного проекта.
Кризис программирования и способ выхода из него
Программы не появляются сами по себе, даже основываясь на самых лучших методологиях и образцах. Программа — это результат деятельности людей, и от того, как организован труд этих людей, в огромной степени зависит качество разрабатываемого ПП.
В начале 1970-х годов в США был отмечен кризис программирования (software crisis). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный ПП не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.
Аналитические исследования и обзоры, выполнявшиеся в последние годы ведущими зарубежными аналитиками, дают не слишком обнадеживающие результаты. Например, в 1995 г. компания Standish Group проанализировала работу 364 американских корпораций, а также итоги выполнения более 23 тыс. проектов, связанных с разработкой ПП, и сделала следующие выводы:
только 16,2 % проектов завершились в срок, не превысили запланированный бюджет и обеспечили реализацию всех требуемых функций и возможностей;
52,7 % проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
31,1 % проектов были аннулированы до завершения.
Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет в среднем оказался превышен на 89 %, а срок выполнения — на 122 %.
В 1998 г. процентное соотношение проектов лишь немного изменилось в лучшую сторону (26, 46 и 28 % соответственно).
В числе причин возможных неудач фигурируют:
нечеткая и неполная формулировка требований к ПП;
недостаточное вовлечение пользователей в работу над проектом;
отсутствие необходимых ресурсов;
неудовлетворительное планирование;
частое изменение требований и спецификаций;
новизна используемой технологии для организации;
отсутствие грамотного управления проектом;
недостаточная поддержка со стороны высшего руководства.
В последнее время ведущие зарубежные аналитики отмечают как одну из причин многих неудач тот факт, что большое число проектов выполняется в экстремальных условиях. В англоязычной литературе с легкой руки Эдварда Иордана, одного из ведущих мировых специалистов в области программной инженерии, утвердилось выражение «death march» — буквально «смертельный марш». Под ним понимается такой проект, параметры которого отклоняются от нормальных значений, по крайней мере, на 50 %. По отношению к проектам создания ПП это означает наличие, как минимум, одного из следующих ограничений:
план проекта сжат более чем на половину по сравнению с нормальным расчетным планом, т.е. работа, требующая в нормальных условиях 12 мес, должна быть выполнена за 6 мес или менее. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной;
число разработчиков уменьшено более чем на половину по сравнению с действительно необходимым для проекта данного масштаба, как правило, по причине сокращения штатов компании в результате кризиса, реорганизации и т.д.;
бюджет и связанные с ним ресурсы урезаны наполовину (результат сокращения компании и других противозатратных мер или конкурентной борьбы за выгодный контракт), что влечет за собой уменьшение числа нанимаемых разработчиков или привлечение малооплачиваемых неопытных молодых работников;
требования к функциям, производительности и другим техническим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях.
Потребность контролировать процесс разработки ПП, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 1970-х годов к необходимости перехода от кустарных к индустриальным способам создания ПП и появлению совокупности инженерных методов и средств создания ПП, объединенных общим названием «программная инженерия» (software engineering). Впервые этот термин прозвучал в качестве названия темы конференции, проводившейся под эгидой НАТО в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция по программной инженерии. Тогда же появилось первое издание, посвященное программной инженерии, — «IEEE. Transactions on Software Engineering» («IEEE. Труды по программной инженерии»).
В процессе становления и развития программной инженерии можно выделить два этапа:
1970-е и 1980-е годы — систематизация и стандартизация процессов создания ПП (на основе структурного подхода);
1990-е годы — начало перехода к сборочному, индустриальному способу создания ПП (на основе объектно-ориентированного подхода).
В основе программной инженерии лежит одна фундаментальная идея: проектирование ПП является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПП позволяют повысить его качество, обеспечивают управляемость процесса проектирования ПП и увеличивают срок его жизни.
При любых изменениях в процессе разработки ПП необходимо иметь критерии, позволяющие оценить эффект от проведенных изменений. Другими словами, необходимы методы, позволяющие измерять качество и эффективность работы организации. Под организацией понимается совокупность всех групп разработчиков проектов (каждый проект направлен на создание своего ПП) и администрации, связанных одним процессом.
В настоящее время существуют две общепринятые методики оценки состояния процесса разработки программного обеспечения: международный стандарт ISO 9001 и модель CMM-SEI — Capability Maturity Model (модель оценки зрелости технологических процессов в организации), разработанная в Software Engineering Institute (Институт программной инженерии).