Технологический процесс разработки программного обеспечения курсовая 2010 по информатике , Дипломная из Информатика

Скачай Технологический процесс разработки программного обеспечения курсовая 2010 по информатике и еще Дипломная в формате PDF Информатика только на Docsity! Курсовая работа Технологический процесс разработки программного обеспечения Киев 2008 Содержание 1. Введение 2. Понятие технологического процесса в организации 2.1 Компоненты технологического процесса организации 2.2 Компоненты технологического процесса проекта 3. Организационная структура и роли в технологических процессах 4. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения 5. Методы оценивания технологической зрелости 6. Внутренняя структура уровней зрелости 7. Иерархия оценок зрелости ТП по модели СММ Заключение обеспечение технологической готовности организации к выполнению работ по проекту). Основные элементы описанной концептуальной модели разработки ТП представлены на рис.1 и описаны ниже. Техпроцессы проектов разрабатываются путем настраивания стабильного и гибкого стандартного ТП организации на характеристики конкретного проекта. 2.1 Компоненты технологического процесса организации Основные компоненты ТП организации таковы: архитектура ТП; элементы ТП; описания жизненных циклов (ЖЦ) ПО, рекомендованных для использования в организации; руководства и критерии для настройки стандартного ТП организации; база данных (БД) ТП организации; библиотека документации, связанной с процессом разработки. Компоненты ТП открыты для использования проектами при разработке, сопровождении и реализации собственных ТП проектов. Организация может группировать компоненты ТП разными способами в зависимости от подхода к формированию стандартного ТП. Например, описание ЖЦ ПО может быть интегральной частью стандартного ТП организации. Другой пример - часть библиотеки документации, относящейся к ТП, может храниться в БД ТП организации. Архитектура ТП - это описание стандартного ТП организации, касающееся приоритетов, интерфейсов, взаимозависимостей и других взаимоотношений между элементами стандартного ТП организации и других внешних по отношению к нему процессов (например, системной инженерии, инженерии аппаратного обеспечения и др.). Элемент ТП - это составной элемент описания ТП, который охватывает четко определенное, ограниченное и связное множество задач (например, оценивание ПО, проектирование ПО и др.). Описания элементов ТП могут представлять собой: шаблоны (template), подлежащие заполнению; фрагменты, требующие укомплектования; описания, выполненные на высоком уровне абстракции и нуждающиеся в уточнении; полностью сформированные описания, которые могут быть модифицированы или использованы без изменений. Рис.1. Концептуальная модель ТП (например, планы, оценки, данные о реальной трудоемкости, документы требований и др.). Релизы (продукты ПО) (software products) представляют собой полное множество или любой из отдельных элементов множества компьютерных программ, процедур, данных и соответствующей документации, предназначенных для передачи заказчику или конечному пользователю (IEEE- STD-610). Все релизы являются в то же время рабочими продуктами, но не все рабочие продукты представляют собой релизы. План разработки ПО. Этот план в виде одного или группы документов образует мост между ТП проекта и конкретной реализацией этого ТП (с указанием исполнителей и графика выполнения задач). Только сочетание точного определения ТП и плана разработки дает возможность реально выполнить технологический процесс. 3. Организационная структура и роли в технологических процессах Роль - это совокупность обязанностей и сфер ответственности, возлагаемых на одно лицо или группу лиц. В небольших проектах или организациях допускается совмещение нескольких ролей одним лицом. В крупных проектах роли, особенно руководящие (менеджеры), должны исполняться разными лицами. 1. Менеджеры. Выполняют традиционные функции планирования, обеспечения ресурсами, организации, руководства и контроля исполнения работ, входящих в сферу их ответственности. 1.1 Главный менеджер организации (директор) (senior manager). Один из руководителей организации, отвечающий за жизнеспособность и совершенствование ТП организации и всех ТП проектов. 1.2 Менеджер проекта (руководитель проекта) (project manager). Руководит разработкой программной системы. Несет полную финансовую ответственность за выполнение проекта перед заказчиком. 1.3 Менеджер ПО проекта (project software manager). Несет полную ответственность за все действия, связанные с разработкой ПО проекта. Контролирует ресурсы программирования проекта. Отвечает непосредственно перед менеджером проекта. В крупных проектах менеджер ПО может быть одним (первым) из линейных менеджеров проекта. 2. Разработчики. Непосредственные исполнители (штат) проекта, объединенные в группы (бригады, команды). 2.1 Лидер (software task leader). Возглавляет бригаду разработчиков. Несет ответственность за технические решения. Отвечает перед менеджером ПО. 2.2 Персонал (штат) (staff). Лица, включая лидера, ответственные за выполнение определенных функций в проекте и не являющиеся менеджерами. 3. Группа системной инженерии (system engineering group). Коллектив исполнителей (менеджеры и штат), несущих ответственность за спецификацию системных требований; их распределение по программно- аппаратным компонентам; спецификацию интерфейсов между компонентами; мониторинг проектирования и реализации этих компонентов в соответствии со спецификациями. 4. Группа программной инженерии (software engineering group). Это коллектив исполнителей проекта (разработчиков и менеджеров), несущих ответственность за разработку и сопровождение ПО проекта. 5. Группы поддержки разработки. Коллективы исполнителей (менеджеры и штат), связанных с различными аспектами программной инженерии (например, оценкой качества, управлением конфигурацией и др.), но не несущих прямую ответственность за разрабатываемый продукт. 5.1. Группа процесса разработки ПО (software engineering process group). Коллектив специалистов, занимающихся определением, сопровождением и улучшением ТП организации. 5.2. Группа системного тестирования (system test group). Коллектив исполнителей (разработчики и штат), несущих ответственность за планирование и проведение независимого системного тестирования ПО с целью установления соответствия продукта ПО требованиям. Группа системного тестирования существует автономно от разработчиков проектов, что дает возможность исключить влияние принятых ими проектных и реализационных решений на состав и содержание тестов. 5.3. Группа обеспечения (гарантии) качества ПО (software quality assurance group). Коллектив исполнителей (менеджеры и штат), выполняющих планирование и реализацию действий, гарантирующих соблюдение дисциплины разработки в соответствии с шагами ТП и стандартами. С целью снижения риска, связанного с разработкой проектов ПО, группа обеспечения (гарантии) качества ПО получает независимость от конкретных проектов (в частности, от менеджеров проектов) и несет ответственность непосредственно перед главным менеджером организации. 5.4. Группа управления конфигурацией ПО (software configuration management group). Коллектив исполнителей (менеджеры и штат), несущих группы улучшения техпроцесса - руководство по определению и улучшению техпроцесса в организации. СММ - это описательная (descriptive) модель, т.к она описывает существенные (или ключевые) атрибуты, которыми должен обладать процесс программирования в организации, находящейся на определенном уровне зрелости. В то же время СММ - это нормативная (normative) модель, поскольку рекомендует применение определенных практических приемов. СММ обеспечивает достаточный уровень абстракции и не накладывает ограничений на способы реализации процесса программирования в организации, то есть, в любом контексте применения СММ должна существовать разумная интерпретация практических приемов. СММ нельзя считать предписывающей (prescriptive) моделью, поскольку она дает ответ на вопрос, какими свойствами должен обладать процесс программирования в организации, имеющей тот или иной уровень зрелости, но не говорит о том, какими средствами обеспечить улучшение процесса и достижение соответствующего уровня. Достоинства СММ: основывается на реальных процедурах; отражает передовую практику программной инженерии и опыт выполнения больших государственных заказов на разработку ПО; пригодна для совершенствования или оценки процессов разработки ПО; хорошо документирована; продолжает уточняться (для нижних уровней) и развиваться (для верхних уровней) по мере приобретения организациями-разработчиками опыта построения зрелого ТП. Концепция зрелости процесса разработки ПО основывается на интеграции концепций: технологического процесса разработки ПО (software process) широты возможностей процесса разработки ПО (software process capability) результативности процесса разработки ПО (software process performance) зрелости процесса разработки ПО (software process maturity). Широта возможностей ТП - это диапазон ожидаемых результатов, достигаемых при выполнении техпроцесса. Оценка широты возможностей процесса программирования в организации - это способ предсказания наиболее вероятных результатов (выхода), которые можно ожидать от любого проекта ПО в рамках организации. Результативность ТП характеризует реальные результаты, достигнутые благодаря следованию процессу. Результативность конкретного проекта, разрабатываемого в определенных условиях, может не отражать в полной мере широты возможностей процесса в организации, поскольку возможности проекта ограничены его средой (на них влияют, например, изменения технологии, требующие от персонала дополнительной подготовки). Уровень зрелости (maturity level) организации-разработчика - это четко определенный базис для достижения зрелости процесса разработки ПО, который указывает на степень совершенства (состоятельности) процесса. Уровень зрелости описывает характеристики, которые достигает организация. На каждом уровне сконцентрировано множество целей процесса, которые, в случае их достижения, стабилизируют соответствующий важный компонент (направление) процесса программирования. Пять уровней зрелости СММ представлены на рис.2. Стрелки на рисунке указывают вид возможностей процесса, который официально утверждается организацией на каждом уровне зрелости. Названия уровней отражают сущность изменений в основном процессе программирования: Рис.2. Пять уровней зрелости технологического процесса разработки ПО Каждый уровень образует фундамент для эффективной реализации процессов на последующих уровнях. Пропуск уровней противоестественен. Организации могут с успехом использовать (внедрять) процессы, описанные на вышележащих уровнях, находясь при этом на более низком уровне. Например, такие процессы как анализ требований, проектирование, кодирование и тестирование, не обсуждаются в СММ вплоть до третьего уровня, хотя организации проводят соответствующую работу уже на первом уровне. То же касается и обзоров, которые могут проводиться на 1 или 2 уровне, хотя описаны в СММ на 3 уровне. Однако, эти и другие процессы, не отнесенные, но применяемые на низлежащих уровнях, не могут в полной мере раскрыть свой потенциал, пока не будет создан соответствующий фундамент на нижних уровнях СММ. Таким образом, СММ идентифицирует уровни, через которые организация должна эволюционировать для утверждения культуры программной инженерии. Организации, находящиеся на 1 уровне и пытающиеся создать фиксированный (defined) процесс (уровень 3), не создав перед тем повторяемый процесс (уровень 2), обычно не достигают успеха, поскольку менеджеры проекта больше всего озабочены проблемами сроков и стоимости проекта. Это основная причина, по которой нужно сначала усовершенствовать процесс управления, а затем процессы собственно инженерии. Может показаться, что определить и реализовать процесс инженерии легче, чем процесс управления (особенно с точки зрения разработчика), но без дисциплины управления процесс инженерии неминуемо скатится к проблемам сроков и стоимости. Способность организации реализовывать процессы с высших уровней зрелости не означает, что уровни зрелости могут быть пропущены. По мере того, как организация достигает зрелости ТП, она официально устанавливает (учреждает, внедряет) (institutionalizes) этот процесс в виде базового (стандартного) путем принятия соответствующих административных решений, разработки стандартов и создания необходимых Для удобства оценивания действия в рамках каждого ключевого направления совершенствования ТП сгруппированы в следующие пять разделов: административные меры (commitment to perform) - действия организации для обеспечения хода и стабильности техпроцесса (обычно касаются формирования политики и обеспечения финансовой поддержки); необходимые предпосылки (ability to perform) - условия для обеспечения готовности ТП (необходимые ресурсы, организационные структуры и система обучения); выполняемые процедуры (activities performed) - правила и процедуры, необходимые для успешной реализации соответствующего участка ТП (разработка планов и процедур, выполнение технологических операций, проверка и корректировка ТП); измерение и анализ (measurement and analysis) - измерение показателей техпроцесса, анализ полученных результатов измерений, оценка состояния и эффективности процесса; проведение проверки (verifying implementation) - проверка соответствия выполняемых действий требованиям существующего техпроцесса (методы проверки - обзоры (осмотры) (reviews) и аудиторские проверки (ревизии) (audits) в ходе управления и обеспечения качества ПО). 5. Методы оценивания технологической зрелости СММ предлагает критерии, позволяющие оценить зрелость организаций-разработчиков. Эти критерии могут использоваться разработчиками для улучшения процессов разработки и сопровождения ПО, а также заказчиками для оценки рисков заключения договоров на разработку программных проектов с определенными исполнителями. Разработано 3 метода оценивания зрелости технологического процесса: метод SPA (от Software Process Assessment) - определение текущего состояния ТП. Используется для обследования и оценки текущего состояния процесса программирования в организации, выявления существующих проблем, определения высокоприоритетных целей улучшения процесса программирования, выработки соответствующей стратегии улучшения и получения поддержки со стороны руководства; метод SCE (от Software Capability Evaluation) - оценка способностей организации-разработчика. Используется для идентификации риска заказчика, связанного с определенным проектом или контрактом с организацией-исполнителем на разработку высококачественного ПО в соответствии с установленными сроками и бюджетом. Может использоваться при определении потенциальных организаций-исполнителей программных проектов или для управления эффективностью ТП в организациях- исполнителях, располагающих определенными ресурсами программирования; метод IP (от Interim Profile) - метод быстрой промежуточной оценки состояния ТП. Используется для получения достоверной информации о ходе выполнения плана мероприятий по улучшению ТП в промежутках времени между проведением обследований по методу SPA. Осуществляется по контрольному опроснику с минимальным привлечением дополнительной информации со стороны исполнителей проектов. Условием применения этого метода является предварительная оценка по методу SPA и официально утвержденный план мероприятий по улучшению ТП в организации. Методы SPA и SCE отличаются мотивацией, целями, структурой результирующих данных и способами интерпретации результатов. А это определяет применяемые процедуры оценивания, условия проведения обследования, динамику интервьюирования, спектр задаваемых вопросов, характер и объем собираемой информации, а также принципы подготовки специалистов для бригад оценивания. Обследование методом SPA с целью улучшения процесса в организации выполняется регулярно (с периодичностью 18-36 месяцев) в условиях открытости и сотрудничества с руководством и коллективом разработчиков. Оценивание методом SCE выполняется в условиях, приближенных к условиям проведения ревизий. Рекомендации экспертов помогают выбрать наиболее надежных исполнителей проектов. Основные шаги выполнения оценок по СММ: Шаг 1. Выбор группы экспертов, обученных основам СММ и специфике методов оценивания текущего состояния или потенциальных возможностей организации. Члены группы должны быть профессионалами в программной инженерии и менеджменте. Шаг 2. Получение от оцениваемой организации ответов на вопросы контрольного опросника (maturity questionnare). Шаг 3. Анализ ответов и идентификация тех участков ТП, которые требуют дальнейшего обследования. Шаг 4. Посещение организации. Его цель - произвести интервьюирование разработчиков и обзоры документации и сопоставить полученные результаты с результатами анализа по опроснику. Руководящими материалами в этом процессе служат описание КРА и практических приемов СММ. В своей работе группа использует методы проведения экспертизы, что дает ей возможность оценить, в какой мере КРА удовлетворяют целям процесса по каждому направлению. В случае, если обнаруживаются расхождения между ключевыми процедурами СММ и действующей практикой в организации, - группа должна документировать обоснование своих решений по каждому направлению. представлением о практических возможностях техпроцесса. Действия же, перечисляемые во всех остальных разделах, в целом образуют основу для их проведения в жизнь (внедрения). Описание каждой процедуры (practice) содержится в одном предложении текста, за которым может следовать более подробное объяснение с примерами. Описанные таким образом процедуры называют также основополагающими (ключевыми) процедурами (key practices) самого верхнего уровня, составляющими фундамент политики и практики по соответствующему ключевому направлению. Они могут содержать компоненты (процедуры нижнего уровня), детализирующие деятельность в рамках направления. Процедуры предписывают “что” должно быть сделано для достижения целей, и не касаются того, “как” это должно быть сделано. 7. Иерархия оценок зрелости ТП по модели СММ В общем случае, оцениванию подлежат (в приведенной последовательности): ключевые процедуры (если их оценка предусмотрена в плане работ по SPA или SCE); разделы (если их оценка предусмотрена в плане работ по SPA или SCE); цели ключевого направления (всегда); ключевые направления уровня (всегда); уровень зрелости (если целью оценивания является определение уровня зрелости). Цель определенного КРА считается достигнутой (оценка “удовлетворительно”), если в результате обследования ТП обнаруживается, что все ключевые процедуры по всем разделам направления ТП определены, реализованы практически и внедрены во все проекты организации. Оценка “не удовлетворительно" присваивается в том случае, если отмечены существенные недостатки в реализации и внедрении оцениваемых элементов СММ. Каждый метод оценивания может предлагать расширенную шкалу ранжирования, учитывающую частичность реализации целей КРА. Ключевое направление ТП получает оценку “удовлетворительно”, если эта же оценка присвоена всем целям, достижение которых предусмотрено по данному направлению. Если хотя бы одна из целей КРА не достигается (с оценкой “удовлетворительно”) - КРА получает оценку “не удовлетворительно". Определенный уровень зрелости считается достигнутым, если все ключевые направления ТП, с которыми связывается данный уровень зрелости в модели СММ, а также все ключевые направления низлежащих уровней получили оценку “удовлетворительно". Таким образом, обязательным условием аттестации организации- разработчика на соответствующий уровень зрелости является достижение всех целей по всем направлениям данного и всех низлежащих уровней, указанных в модели СММ, для всех проектов организации (текущих и будущих) на все время существования организации. Отечественным организациям-разработчикам, совершенствование ТП в которых будет осуществляться в направлении достижения второго уровня технологической зрелости по модели СММ, целесообразно: детально изучить цели и процедуры КРА второго уровня (разд.4 и приложение 2); получить административную и финансовую поддержку; создать соответствующие организационные структуры и другие элементы ТП, рекомендуемые СММ (разд.5); подготовить нормативно-методическую и учебную базу. Перечень необходимых (для достижения уровня 2) международных стандартов, которые могут использоваться в качестве ориентиров при выполнении работ по ключевым направлениям, представлен в табл.1; организовать процесс обучения специалистов программных проектов; составить глобальный план работ по совершенствованию ТП организации, рассчитанный на 6-8 лет; обеспечить надлежащее управление работами. Отв. исполнитель проекта: (ФИО) _____ Подпись Рабочий телефон __________________ Дата _______________ Шаг 2. Организация-заказчик рассылает претендентам на роль исполнителей форму паспорта и контрольный опросник; Шаг 3. Организация-претендент, ознакомившись с проектом паспорта заказываемого продукта, подбирает несколько (но не менее трех) завершенных или находящихся в стадии завершения проектов, разработанных в данной организации и схожих с предлагаемым к разработке; Шаг 4. Разработчик проекта заполняет паспорт разработанного (разрабатываемого) продукта по форме паспорта и отвечает на все вопросы контрольного опросника (приложение 1). Ответы на вопросы по каждому направлению проставляются посредством отметки (знак "+" при ручном заполнении формы или число “1” при машинном заполнении) в соответствующих колонках интервальной шкалы; Шаг 5. Организация-претендент отсылает заполненные паспорта и контрольные опросники организации-заказчику; Шаг 6. Эксперт организации-заказчика обрабатывает все паспорта и контрольные опросники организации-претендента и определяет уровень зрелости организации. Обработка контрольных опросников для получения оценок включает выполнение следующих действий: каждой оценке присваивается эквивалентный числовой коэффициент (табл.1) Таблица 1 Оценка Коэффи циент Почти всегда 1 Часто 0.75 Иногда 0.5 Редко 0.25 Никогда 0 обрабатывается один опросник для одного проекта: подсчитывается количество ответов по каждой оценке одного направления ТП (количество отметок “+” или “1” в столбце). Это количество ответов умножается на соответствующий коэффициент (см. табл.1) и вычисляется их сумма. Затем эта сумма делится на количество вопросов, касающихся данного направления (приложение 1) и умножается на 100% (для получения оценки достижимости целей направления в процентах). Ниже приведен пример заполнения опросного листа по направлению “Управление требованиями” и оценка уровня достижимости целей по данному направлению. Соответствующий опросный лист содержит 6 вопросов. Пример заполнения опросного листа приведен в табл.2. Вычисленная оценка КРА по ответам на вопросы по данному направлению составляет. (2*1 + 1*0.75 + 1*0.5 + 2*0) / 6 = 0.54 или в процентном отношении - 0.54*100% = 54% Процедура повторяется по всем шести направлениям, представленным в опроснике; 3) подобным образом обрабатываются ответы на вопросы по всем проектам; 4) по завершении обработки опросных листов оценки по каждому направлению для всех проектов усредняются. Усредненная оценка направления по всем проектам вычисляется как медиана частных оценок. Например, если в результате обработки вопросов по первому направлению для пяти проектов были получены такие оценки: 54 58 75 79 80 то медианой ряда будет значение 75 и это будет средняя оценка данного направления по представленным проектам. 5) полученные суммарные оценки проектов в процентах по каждому направлению заносятся в итоговый отчет по форме, представленной в табл.3. 6) для расчета уровня зрелости Lзр организации применяется формула: Lзр = 2/6 * { F 0E 5i=1 [ (КPA%i) /100] } где КРАi - полученные суммарные оценки проектов в процентах. Таблица 2 Управление требованиями П очти всегда Част о Иногд а Редк о Никог да Не испо льзу ется 1. Используются ли системные требования, делегированные ПО, в качестве основы для выполнения разработки и управления процессом разработки? + 2. Выполняется ли корректировка планов ПО, рабочих продуктов и действий при изменении системных требований, делегированных ПО? + 3. Руководствуется ли проект принятой в организации политикой в части управления системными требованиями, делегированными ПО? + 4. Прошли ли лица, которым поручено управление делегированными требованиями, обучение приемам управления требованиями? +