49258 (Технологический процесс разработки программного обеспечения)

2016-07-30СтудИзба

Описание файла

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

Онлайн просмотр документа "49258"

Текст из документа "49258"

Курсовая работа

Технологический процесс разработки программного обеспечения

Киев 2008

Содержание

1. Введение

2. Понятие технологического процесса в организации

2.1 Компоненты технологического процесса организации

2.2 Компоненты технологического процесса проекта

3. Организационная структура и роли в технологических процессах

4. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения

5. Методы оценивания технологической зрелости

6. Внутренняя структура уровней зрелости

7. Иерархия оценок зрелости ТП по модели СММ

Заключение


1. Введение

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

Для построения такой инфраструктуры организации-разработчики должны иметь:

а) средства оценивания их способности успешно выполнять технологический процесс (ТП) разработки ПО;

б) руководства по улучшению возможностей своего ТП.

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


2. Понятие технологического процесса в организации

Технологический процесс разработки ПО (ТП) (software process) - это множество направлений деятельности, методов, практических приемов и процедур, используемых для разработки и сопровождения ПО и связанных с ним продуктов (например, планов проекта, проектных документов, кода, тестов и руководств пользователя).

Рассматривают:

технологический процесс организации (ТПО);

технологический процесс программного проекта (ТПП).

Описание стандартного (базового) ТП организации (standard software process) служит основой для определения ТП проектов. Это описание указывает на элементы стандартного процесса, которые должны включаться в ТП программных проектов, а также взаимосвязи между элементами ТП. Оно обеспечивает согласованность выполнения работ в организации, стабильность процессов и фундамент для их улучшения.

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

С каждым ТП связываются:

требования к процессу, которые указывают, “что” собой представляет процесс (что он будет делать);

архитектура процесса, которая описывает, “как” процесс будет определен (каковы будут элементы процесса и как они будут взаимосвязаны);

описание (проект) техпроцесса в рамках организации или программного проекта (создание элементов процесса и установление интерфейсов);

проверка и утверждение (validation) определения процесса (путем измерения его характеристик);

внедрение процесса в среду разработки ПО, для которой он был разработан (завершение технологической подготовки разработки ПО и обеспечение технологической готовности организации к выполнению работ по проекту).

Основные элементы описанной концептуальной модели разработки ТП представлены на рис.1 и описаны ниже.

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

2.1 Компоненты технологического процесса организации

Основные компоненты ТП организации таковы:

архитектура ТП;

элементы ТП;

описания жизненных циклов (ЖЦ) ПО, рекомендованных для использования в организации;

руководства и критерии для настройки стандартного ТП организации;

база данных (БД) ТП организации;

библиотека документации, связанной с процессом разработки.

Компоненты ТП открыты для использования проектами при разработке, сопровождении и реализации собственных ТП проектов. Организация может группировать компоненты ТП разными способами в зависимости от подхода к формированию стандартного ТП. Например, описание ЖЦ ПО может быть интегральной частью стандартного ТП организации. Другой пример - часть библиотеки документации, относящейся к ТП, может храниться в БД ТП организации.

Архитектура ТП - это описание стандартного ТП организации, касающееся приоритетов, интерфейсов, взаимозависимостей и других взаимоотношений между элементами стандартного ТП организации и других внешних по отношению к нему процессов (например, системной инженерии, инженерии аппаратного обеспечения и др.).

Элемент ТП - это составной элемент описания ТП, который охватывает четко определенное, ограниченное и связное множество задач (например, оценивание ПО, проектирование ПО и др.). Описания элементов ТП могут представлять собой:

шаблоны (template), подлежащие заполнению;

фрагменты, требующие укомплектования;

описания, выполненные на высоком уровне абстракции и нуждающиеся в уточнении;

полностью сформированные описания, которые могут быть модифицированы или использованы без изменений.

Рис.1. Концептуальная модель ТП

Описание жизненных циклов ПО, рекомендованных к использованию - это набор описаний адаптированных к нуждам организации моделей ЖЦ ПО. По согласованию с заказчиком или пользователем конкретного проекта одна из этих моделей должна быть использована в сочетании со стандартным ТП при построении ТП проекта.

Руководства и критерии настройки ТП организации призваны помочь руководителям проектов ПО выбрать ЖЦ ПО для использования и адаптировать стандартный ТП организации и выбранный ЖЦ ПО к характеристикам конкретного проекта. Эти руководства и критерии обеспечивают общий базис для планирования, реализации, измерения, анализа и совершенствования процессов разработки ПО проектов.

База данных технологического процесса организации - это БД, предназначенная для сбора и предоставления информации о технологических процессах и полученных в ходе их выполнения рабочих продуктах (релизах), в частности, тех, которые имеют непосредственное отношение к стандартному ТП организации. Эта БД содержит или ссылается как на данные реальных измерений, так и на информацию, необходимую для понимания этих данных и оценивания их обоснованности и применимости (например, оценки размера ПО, трудоемкости и стоимости его разработки, реальные данные о размере, трудоемкости и стоимости ПО, данные о производительности, полноте охвата и эффективности обзоров, о числе и серьезность дефектов, обнаруженных в коде, и др.).

Библиотека документации ТП создается для хранения документов процесса, которые могут быть полезными для других действующих или будущих проектов, особенно имеющих отношение к стандартному ТП организации (это могут быть ТП проектов, стандарты, процедуры, планы разработки ПО, планы измерений ПО и материалы по процессу обучения). Использование фонда библиотеки должно помочь снизить затраты труда на развертывание нового проекта, демонстрируя примеры успешно выполненных проектов, которые могут быть взяты за образец.

2.2 Компоненты технологического процесса проекта

Описание ТП проекта - это используемое проектом операционное определение ТП, изложенное в терминах стандартов ПО, процедур, инструментов и методов. Оно разрабатывается путем настраивания стандартного процесса организации на отражение определенных характеристик проекта. ТП проекта создает базу для планирования, выполнения и улучшения деятельности менеджеров и исполнителей проекта. Проект может иметь более одного ТП (например, для прикладного ПО и ПО тестирования). В то же время, один и тот же ТП может использоваться двумя и более проектами.

Стадии (stages) отражают распределение усилий на разработку ПО. Они имеют регулируемый размер и представляют собой измеримое множество связанных между собой задач, выполняемых проектом. Обычно стадия - это фрагмент ЖЦ ПО, как правило, заканчивающийся формальным обзором, предшествующим началу следующей стадии.

Задача (технологическая операция) (task) - это четко определенная единица работы в техпроцессе, завершение которой представляет собой для руководства проектом видимую контрольную точку для оценки состояния проекта. С задачей связывается критерий готовности (предусловие выполнения) и критерий завершения (постусловие выполнения). Каждая задача предполагает какую-либо деятельность (или действие) (activity), но не каждая деятельность до такой степени четко определена, чтобы рассматриваться в качестве задачи.

Рабочие продукты ПО (software work products) - это результаты деятельности или решения задач в ходе определения, сопровождения или использования ТП, включая описания, планы, процедуры, компьютерные программы и связанную с ними документацию, которые предназначаются (или не предназначаются) к поставке заказчику или пользователю. Рабочие продукты образуют вход для следующего шага процесса или архивную информацию по проекту ПО для использования будущими проектами (например, планы, оценки, данные о реальной трудоемкости, документы требований и др.).

Релизы (продукты ПО) (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). Коллектив исполнителей (менеджеры и штат), несущих ответственность за планирование, координацию и реализацию формальных действий по управлению конфигурацией проекта ПО.

5.5. Группа обучения (training group). Коллектив исполнителей (менеджеры и штат), несущих ответственность за координацию и систематизацию деятельности по обучению в организации (подготовка учебных материалов, проведение обучения).


4. Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения

Концепцию зрелости техпроцесса организации-разработчика ПО предложил институт SEI (Software Engineering Institute).

Свежие статьи
Популярно сейчас
Почему делать на заказ в разы дороже, чем купить готовую учебную работу на СтудИзбе? Наши учебные работы продаются каждый год, тогда как большинство заказов выполняются с нуля. Найдите подходящий учебный материал на СтудИзбе!
Ответы на популярные вопросы
Да! Наши авторы собирают и выкладывают те работы, которые сдаются в Вашем учебном заведении ежегодно и уже проверены преподавателями.
Да! У нас любой человек может выложить любую учебную работу и зарабатывать на её продажах! Но каждый учебный материал публикуется только после тщательной проверки администрацией.
Вернём деньги! А если быть более точными, то автору даётся немного времени на исправление, а если не исправит или выйдет время, то вернём деньги в полном объёме!
Нет! Мы не выполняем работы на заказ, однако Вы можете попросить что-то выложить в наших социальных сетях.
Добавляйте материалы
и зарабатывайте!
Продажи идут автоматически
4125
Авторов
на СтудИзбе
667
Средний доход
с одного платного файла
Обучение Подробнее