
- •Оглавление
- •Введение.
- •Организация процесса конструирования. Жизненный цикл программных средств.
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования по
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •Модели качества процессов конструирования
- •Планирование программного проекта. Оценка трудоемкости и стоимости программного проекта. Конкурентоспособность.
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе 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. Методы оценки эффективности по на этапе эксплуатации
- •Список литературы.
Модель cmm-sei
В 1986 г. институт SEI (подразделение университета Карнеги— Меллона) с помощью корпорации Mitre начал разработку основ модели эффективного процесса изготовления программ. Характеризуя такой процесс, авторы модели употребляют понятие «зрелость», которое означает не только эффективность, но и устойчивость, надежность процесса.
Первоначальная версия модели, которая получила название «СММ», была выпущена в конце 1987 г. После этого модель несколько раз перерабатывалась, и в настоящее время готовится очередная ее версия.
В соответствии с этой моделью организация может находиться на одном из пяти уровней зрелости (рис. 4.1).
Для первого, или начального, уровня характерен спонтанный и иногда хаотический процесс разработки программ. Процедуры разработки не определены, и успех зависит от индивидуальных усилий работников.
Второй уровень, названный повторяемым, характеризуется тем, что на нем используются основные процессы управления, позволяющие отслеживать как функциональные характеристики разрабатываемого ПП, так и график работ, а также их стоимость.
Организация способна повторить успешную разработку нового проекта с аналогичными возможностями.
Третий уровень называется определенным. Организации, находящиеся на этом уровне, документируют, стандартизуют и интегрируют в общий процесс управления все управленческие и инженерные задачи разработки ПП, тем самым вырабаты- !1ля стандартный процесс организации. Все проекты в организации используют утвержденные методы разработки и поддержки программ, адаптированные к конкретному проекту.
Четвертый уровень называется управляемым. У организаций п ого уровня имеются способы детального измерения качества процесса и разрабатываемого ПП. Количественные характеристики процесса разработки и разрабатываемых ПП хорошо изучены и управляемы, процесс предсказуем.
Пятый, высший уровень зрелости организации называется оптимизированным. На нем осуществляется непрерывное улучшение процесса разработки, основанное на количественных характеристиках выполненных и выполняемых проектов и на внедрении новых идей и технологий.
Повышение зрелости идет от первого к пятому уровню. Подавим ющее большинство организаций, занимающихся разработкой 11П, начинают с первого уровня (многие на нем и остаются). Не- фелая организация не может предсказать ни срока завершения разработки, ни качества конечного продукта. Успех зависит от опытности непосредственного руководителя и квалификации и таланта разработчиков. Процесс управления, если и создается, то тлько в ходе выполнения проекта, ему не следуют, особенно во время часто случающихся кризисов и авралов.
Не стоит думать, что такая организация не способна успешно разработать ПП, хотя, скорее всего, график разработки не будет выполняться и система будет стоить больше, чем планировалось сначала. Повторение успеха возможно только в том случае, если в разработке принимают участие те же самые сотрудники.
Для достижения второго и более высоких уровней организации должны разработать свой процесс, основанный и включающий в себя определенные рекомендуемые ключевые процессы. Ключевые процессы на оптимизированном уровне: управление изменениями процесса; использование современных новейших технологий; предотвращение ошибок.
Ключевые процессы на управляемом уровне: управление качеством процесса; измерение и анализ процесса.
Ключевые процессы на определенном уровне: рецензирование и обсуждение с коллегами результатов работы;
координация и взаимодействие между проектами; повышение квалификации сотрудников; определение организационных процессов; сосредоточение особого внимания на организационных процессах;
индустриальный подход к проектированию и разработке ПП; интегрированное управление всеми проектами, базирующееся на стандартном процессе организации.
Ключевые процессы на повторяемом уровне: управление конфигурацией (версиями) ПП; обеспечение качества ПП; управление работой субподрядчиков; контроль за выполнением программного проекта; планирование программного проекта; управление требованиями к ПП.
На начальном уровне ключевых процессов нет.
Любой ключевой процесс подразумевает выполнение организацией некоторого набора ключевых действий, связанных с этим процессом, что, в свою очередь, позволяет организации достичь определенных целей, реализуемых данным ключевым процессом. Ключевые действия не только дают возможность реализовать данный ключевой процесс, но и являются своего рода инструкцией к его реализации. Выполнение или невыполнение различных ключевых действий является своеобразным ключевым показателем, по которому можно судить об уровне зрелости организации. Для определения этого уровня в модели СММ предусмотрен целый перечень вопросов, которые могут быть заданы сотрудникам организации. Анализ ответов на эти вопросы позволяет сделать вывод о достигнутом уровне зрелости. Пример структуры СММ для ключевого процесса «Планирование программного проекта» второго уровня зрелости организации приведен на рис. 4.2.
Рис.
4.2. Пример структуры СММ
Модель СММ специально обходит вопрос о подборе персонала. Она рассматривает разработку ПП как чисто производственный процесс. Организационная структура и процессы управления и должны помогать наиболее эффективно проявляться способности разработчиков.
Сами процессы в различных организациях могут быть различны, как и используемые методы и технологии. Общим требованиями ко всем процессам является создание основы для системы управления разработкой ПП.