курсовая работа. Учебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах
 Скачать 7.57 Mb.
|
6. Модели качества процессов конструированияВ современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/ IEC 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model — СММ) Института программной инженерии при американском университете Карнеги-Меллон. 1.Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. 2.Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ. 3.Модель CMM. Базовым понятием модели СММ считается зрелость компании. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта. Напротив, в зрелой компании работают ясные процедуры управления проектами и построения программных продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте. Кроме того, в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качественную разработку программного обеспечения. Таким образом, модель СММ фиксирует критерии для оценки зрелости компании и предлагает рецепты для улучшения существующих в ней процессов. Иными словами, в ней не только сформулированы условия, необходимые для достижения минимальной организованности процесса, но и даются рекомендации по дальнейшему совершенствованию процессов. Очень важно отметить, что модель СММ ориентирована на построение системы постоянного улучшения процессов. В ней зафиксированы пять уровней зрелости и предусмотрен плавный, поэтапный подход к совершенствованию процессов — можно поэтапно получать подтверждения об улучшении процессов после каждого уровня зрелости. 1.Начальный уровень (уровень 1) означает, что процесс в компании не формализован. Он не может строго планироваться и отслеживаться, его успех носит случайный характер. Результат работы целиком и полностью зависит от личных качеств отдельных сотрудников. При увольнении таких сотрудников проект останавливается. 2.Для перехода на повторяемый уровень (уровень 2) необходимо внедрить формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов. 3.Следующий, определенный уровень (уровень 3) требует, чтобы все элементы процесса были определены, стандартизованы и задокументированы. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта компании. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей. 4.С переходом на управляемый уровень (уровень 4) в компании принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса. 5.Высший, оптимизирующий уровень (уровень 5) подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется. Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы: предотвращения дефектов; управления изменениями технологии; управления изменениями процесса. Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать данному уровню СММ. Контрольные вопросы Какие этапы классического жизненного цикла вы знаете? Охарактеризуйте содержание классического жизненного цикла. Объясните достоинства и недостатки классического жизненного цикла. В чем отличие классического жизненного цикла и макетирования? Чем отличаются друг от друга стратегии конструирования ПО? Чем отличается модель быстрой разработки приложений? В чем достоинства и недостатки модели быстрой разработки приложений? Укажите максимальное время разработки каждой главной функции RAD-модели? Укажите особенность спиральной модели конструирования. Объясните достоинства и недостатки инкрементной модели. Чем отличаются прогнозирующие процессы от адаптивных? Приведите пример прогнозирующих процессов. Приведите пример адаптивных процессов. Перечислите характеристики и методы ХР-процесса. В чем главная особенность ХР-процесса? Какова особенность тестирования в ХР-процессе? Какова максимальная численность группы ХР-разработчиков? Какой метод ХР-процесса является самым спорным? За счет чего достигается ускорение разработки в RAD-модели? Охарактеризуйте модель СММ. Охарактеризуйте уровень зрелости известной вам фирмы. Глава 3.Руководство проектом. Метрики 1. Процесс руководства проектом Руководство программным проектом – первый слой процесса конструирования ПО. Термин «слой» подчёркивает, что руководство определяет сущность процесса разработки от его начала до конца. Принцип руководства иллюстрирует рисунок 1.
 Время Рис. 1. Руководство в процессе конструирования ПО Для проведения успешного проекта нужно понять объём предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые условия(стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ. Начало проекта Перед планированием проекта следует: установить цели и проблемную область проекта; обсудить альтернативные решения; выявить технические и управленческие ограничения. Измерения, меры, метрики Измерения помогают понять как процесс разработки продукта, так и сам продукт. Измерения процесса производятся в целях его улучшения, измерения продукта – для повышения его качества. В результате измерения определяется мера – количественная характеристика какого-либо свойства объекта. Путём непосредственных измерений могут определяться только опорные свойства объекта. Все остальные свойства оцениваются в результате вычисления тех или иных функций от значений опорных характеристик. Вычислении этих функций проводятся по формулам, дающим числовые значения и называемым метриками. В IEEEStandartGlossaryofEnineeringTerms метрика определена как мера степени обладания свойством, имеющая числовое значение. В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы. Процесс оценки При планировании программного проекта надо оценить людские ресурсы (в человеко-месяцах), продолжительность (в календарных датах), стоимость . Обычно исходят из прошлого опыта. Если новый проект по размеру и функциям похож на предыдущий проект, вполне вероятно, что потребуются такие же ресурсы, время и деньги. Анализ риска На этой стадии исследуется область неопределённости, имеющаяся в наличии перед созданием программного продукта. Анализируется её влияние на проект. Нет ли скрытых от внимания трудных технических проблем? Не станут ли изменения, проявившиеся в ходе проектирования, причиной недопустимого отставания по срокам? В результате принимается решение – выполнять проект или нет. Планирование Определяется набор проектных задач. Устанавливаются связи между задачами, оценивается сложность каждой задачи. Определяются людские и другие ресурсы. Создаётся сетевой график задач, проводится его временная разметка. Трассировка и контроль Каждая задача, помеченная в плане, отслеживается руководителем проекта. При отставании в решении задачи применяются утилиты повторного планирования. С помощью утилит определяется влияние этого отставания на промежуточную веху и общее время конструирования. Под вехой понимается временная метка, к которой привязано подведение промежуточных итогов. В результате повторного планирования: могут быть перераспределены ресурсы; могут быть реорганизованы задачи; могут быть пересмотрены выходные обязательства. Планирование проектных задач Основной задачей при планировании является определения WBS – Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рисунке 2. Модули:  Рис. 2. Типовая структура распределения проектных работ Первыми выполняемыми задачами являются системный анализ и анализ требований. Они закладывают фундамент для последующих параллельных задач. Системный анализ проводится с целью: выяснения потребностей заказчика; оценки выполнимости системы; выполнения экономического и технического анализа; распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.); определения стоимости и ограничений планирования; создания системной спецификации. В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация. Анализ требований даёт возможность: определить функции и характеристики программного продукта; обозначить интерфейс продукта с другими системными элементами; определить проектные ограничения программного продукта; построить модели: процесса, данных, режимов функционирования продукта; создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования. Результаты анализа сводятся в спецификацию требований к программному продукту. Как видно из типовой структуры, задачи по проектированию и планированию тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального (процедурного) проектирования, кодирования и тестирования. После получения всех модулей ПО решается задача тестирования интеграции – объединения элементов в единое целое. Далее проводится тестирование правильности, которое обеспечивает проверку соответствия ПО требованиям заказчика. Ромбиками на рисунке 2 обозначены вехи – процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию как на один из результатов успешного решения задачи. Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи. Основной рычаг в планирующих методах – вычисление границ времени выполнения задачи. Обычно используются следующие оценки: Раннее время начала решения задачи Tinmin (при условии, что все предыдущие задачи решены в кратчайшее время). Позднее время начала решения задачи Tinmax (ещё не вызывает общую задержку проекта). Раннее время конца решения задачи Toutmin = Tinmin + Tреш Позднее время конца решения задачи Toutmax = Tinmax + Tреш Общий резерв – количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути Tк п. Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач. Рекомендуемое правило распределения затрат проекта – 40-20-40: на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ – 5%); на кодирование – 20%; на тестирование и отладку – 40%. 2. Метрики 2.1 Размерно-ориентированные метрики Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Cod). LOC-оценка – это количество строк в программном продукте. Исходные данные для расчёта этих метрик сводятся в таблицу 1. Таблица содержит данные о проектах за последние несколько лет. Например, запись ааа01 показывает: 12 100 строк программы были разработаны за 24 человеко-месяца и стоили 168 000 долларов. Кроме того, по проекту ааа01 было разработано 365 страниц документации, а в течение первого года эксплуатации было зарегистрировано 29 ошибок. Разрабатывали проект ааа01 три человека. Таблица 1. Исходные данные для расчёта LOC-метрик
На основе таблицы вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта): Производительность = Длина / Затраты [Тыс. LOC / чел.-мес.] ; Качество = Ошибки / Длина [Единиц / тыс. LOC]; Удельная стоимость = Стоимость / Длина [Тыс. $ / LOC]; Документированность = СтраницДокумента / Длина [Страниц / тыс. LOC]. Достоинства размерно-ориентированных метрик: широко распространены; просты и легко вычисляются. Недостатки размерно-ориентированных метрик: зависимы от языка программирования; требуют исходных данных, которые трудно получить на начальной стадии проекта; неприспособленны к непроцедурным языкам программирования. | ||||||||||||||||||||||||||||||||||||||||