Файл: ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ПРОЕКТА..pdf

Содержание:

Введение

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

Создание программного обеспечения – это сложный и длительный процесс, поэтому для его упрощения были продуманы процедуры, унифицирующие этот процесс. Такие процедуры были оформлены в виде стандартов. Первоначально, в России создание ПО регламентировалось стандартами ГОСТ ЕСПД, которые применялись для относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели, сроки их действия закончились и использование нецелесообразно. Процессы создания автоматизированных систем (АС), в состав которых входит и программное обеспечение, регламентированы стандартами ГОСТ 34.601-90, ГОСТ 34.602-89 и ГОСТ 34.603-92. Однако процессы создания ПО для современных распределенных ЭИС, функционирующих в неоднородной среде, в этих стандартах отражены недостаточно, а отдельные их положения явно устарели. В результате для каждого серьезного проекта ЭИС приходится создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПО, поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

Цель работы: характеристика понятия и этапов жизненного цикла, общее знакомство с моделями жизненного цикла программных систем.

На основе цели поставлены следующие задачи:

• характеристика понятия и этапов жизненного цикла;
• описание моделей жизненного цикла;
• моделирование процесса управления жизненным циклом.

1. Понятие и стадии жизненного цикла

Проектирование ИС – трудоёмкий, длительный и динамический процесс. Технологии проектирования, применяемые в настоящее время, предполагают поэтапную разработку системы [3]. Процесс, включающий в себя все этапы, через которые проходит ИС с момента её создания до прекращения её использования, называется жизненным циклом.

Стадии жизненного цикла (далее ЖЦ) описаны в Государственном стандарте РФ ГОСТ Р ИСО/МЭК "Информационная технология. Процессы жизненного цикла программных средств" под номером 12207-99, принятый и введенный в действие постановлением Госстандарта России от 23 декабря 1999 г. № 675-ст. Настоящий стандарт содержит полный аутентичный текст международного стандарта ISO/IEC 12007:95 «Информационная технология. Процессы жизненного цикла программных средств», который действует с незначительными поправками в настоящее время и регламентирует процессы жизненного цикла программных средств и информационных технологий. Все процессы ЖЦ в соответствии с этим стандартом делятся на три группы: основные процессы, вспомогательные и организационные (рисунок 1.1). Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами [2]. Стандарт не определяет конкретной модели жизненного цикла или метода разработки программного средства. Пользователи, применяющие настоящий стандарт, должны сами выбирать модель ЖЦ применительно к своему программному проекту и распределять процессы, работы и задачи, выбранные из настоящего стандарта, на данной модели [6].

Рисунок 1.1. Структура стандарта

ГОСТ 34.60190 определяет следующие стадии и этапы создания АИС [7]:

1. Формирование требований к АИС:

• обследование организации и обоснование необходимости разработки ИС;
• требования конечных пользователей к системе;
• оформление отчёта о проделанной работе (тактико-техническое задание).

2. Разработка концепции АИС:

• изучение объекта автоматизации;
• проведение исследовательских научных работ, необходимых для работы;
• разработка вариантов АИС, выбор окончательного варианта, который будет удовлетворять всем требованиям пользователя;
• оформление отчёта о проделанной работе.

3. Разработка технического задания (далее ТЗ). ТЗ – это документ, в котором сформулированы основные цели разработки, требование к программному продукту, определены сроки и этапы разработки, и регламентирован процесс приёмно-сдаточных испытаний.

4. Эскизный проект (макет):

• планирование предварительных проектных решений по будущей системе, по отдельным её частям;
• разработка документаций как на АИС.

5. Технический проект:

• принятие решений по создаваемой системе;
• разработка документаций на систему;
• разработка и оформление документации на поставку изделий на комплектование АИС;
• оформление технических требований на разработку изделий для комплектования АИС;
• задания на проектирование в смежных модулях ИС.

6. Рабочая документация:

• создание рабочей документации;
• разработка программ и её адаптация.

7. Ввод в действие:

• подготовка предприятия-заказчика к началу установки ИС;
• обучение персонала;
• комплектование АИС техническими и программными средствами;
• строительно-монтажные работы;
• пуско-наладочные действия;
• предварительные испытания ИС;
• опытная эксплуатация установленной и проверенной системы;
• приёмочные испытания.

8. Сопровождение АИС:

• выполнение обязательств по гарантийному обслуживанию;
• послегарантийное обслуживание.

Модель жизненного цикла отражает различные состояния системы в процессе всего жизненного цикла ИС. Модель ЖЦ – это такая структура, которая содержит все процессы, действия и задачи по разработке программного продукта, по его сопровождению и функционированию в течении всей жизни созданной системы, вплоть до её исчезновения [2].

В настоящее время известны несколько моделей жизненного цикла, но все они сводятся к выполнению следующих стадий:

1. Планирование и анализ требований.
2. Проектирование (техническое и логическое.).
3. Реализация (рабочее проектирование, физическое проектирование, программирование. Разработка и настройка программ, наполнение баз данных, создание инструкций).
4. Внедрение (Тестирование, опытная эксплуатация. Обучение персонала).
5. Эксплуатация (Сопровождение и модернизация. Исправление ошибок и недоработок. Повторение стадий 2-5 при необходимости). [3]

2. Модели жизненного цикла

2.1. Каскадная модель

Каскадная модель ЖЦ – одна из самых первых моделей, которая применялась не только для описания жизненного цикла ИС, но и для описания ЖЦ любого программного продукта. Она носит второе название – водопадная. Эта модель предусматривает линейный процесс функционирования ИС (рисунок 2.1), однако на любом из этапов может возникнуть ситуация, когда разрабатываемая, внедряемая или уже эксплуатируемая система не удовлетворяет каким-либо начальным требованиям и нужно возвращаться на один из предыдущих этапов для её доработки.

Рисунок 2.1. Каскадная модель ЖЦ ИС

Эта модель предусматривает линейный процесс функционирования ИС, т.е. пока не будет завершён один этап, на другой будет перейти невозможно. Каждый этап заканчивается получением некоторых результатов, которые служат исходными данными для следующего этапа. Каждый этап завершается выпуском полного комплекта документации. Этот вид модели используется для сложных систем с большим числом задач вычислительного характера. Недостатками данной модели можно назвать высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователя. Существует возможность запаздывания с получением результатов. [1]

2.2. V-образная модель

V-образная модель (рисунок 2.2) основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага:

• анализ (планирование и требования);
• проектирование;
• разработка (кодирование);
• обзор (тестирование).

Рисунок 2.2. V-образная модель ЖЦ ИС

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

• детальное проектирование – определяется алгоритм работы каждого компонента;
• кодирование – преобразование алгоритма в готовое программное обеспечение (далее ПО);
• модульное тестирование – проверка каждого компонента или модуля;
• интеграционное тестирование – интеграция программного продукта (далее ПП) и его тестирование;
• системное тестирование – проверка функционирования ПП после помещения его в аппаратную среду [5].

Данный вид модели ЖЦ используют для разработки ИС, где главным требованием является надёжность. Несмотря на ряд преимуществ, главное из которых качественное планирование всех действий, у модели есть и недостатки: не учитываются итерации между фазами, нельзя вносить изменения на разных этапах ЖЦ.

2.3. Модель прототипирования

Модель прототипирования позволяет создать прототип ПП до или в течении этапа составления требований к ПП. (рис. 4) Потенциальные пользователи работают с этим прототипом, определяя его сильнее и слабые стороны, о результатах сообщают разработчикам ПП. Жизненный цикл разработки ПП так же как и у других моделей ЖЦ, начинается с разработки плана проекта. В результате получается документ, содержащий частичную спецификацию требований к ПП. В результате прототипирования разработчик демонстрирует пользователям готовый прототип, а пользователи оценивают его функционирование. Определяются проблемы, которые устраняются пользователями и разработчиками. Процесс продолжается до тех пор, пока пользователи не будут удовлетворены степенью соответствия ПП требованиям, затем прототип демонстрирует пользователям с целью получения предложений по его усовершенствованию, пока рабочая модель не окажется удовлетворительной. После этого получают от пользователя официальное одобрение прототипа, после чего происходит преобразование прототипа в готовый ПП [8].

У модели прототипирования достаточно большое количество достоинств по сравнению с недостатками. Преимуществами модели являются:

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

Недостатки в модели прототипирования:

• решение сложных задач может отодвигаться на будущее;
• заказчик может предпочесть получить прототип;
• разработка может затянуться;
• перед началом работы неизвестно, сколько итераций придётся выполнить.

Данную модель при разработке АИС следует выбрать, если на рынке нет аналогов системы или если требования к ПП заранее не известны

Рисунок 2.3. Модель прототипирования

2.4. RAD-модель

RAD-модель – это модель быстрой разработки приложений. (рис. 5) Решающую роль в такой модели играет конечный пользователь. В тесном взаимодействии с разработчиками он участвует в формировании требований и апробации их на работающих прототипах в RAD модели большую часть отводят планированию и проектированию. [8]

Рисунок 2.4. RAD-модель

Модель проходит четыре фазы:

1. Составление требований и планирование (метод совместного планирования требований: структурный анализ и осуждение задач).
2. Описание пользователя: проектирование ПП, выполняемого при участии заказчика.
3. Создание – детальное проектирование, кодирование, тестирование ПП, поставка его заказчику.
4. Сопровождение – приёмочные испытания, установка ПП, обучение пользователя.

RAD-модель при разработке ИС выбирают, если все требования к будущей системе определены. Но для её использования требуются высококвалифицированные кадры. Если заказчики не могут постоянно участвовать, разработка по этой модели будет невозможна. Так же существует риск, что работа над ПП никогда не будет завершена.

Несмотря на эти недостатки у RAD-модели имеются и преимущества:

• сокращение время цикла разработки за счёт современных инструментальных средств;
• привлечение к работе заказчика;
• повторно используются компоненты уже существующих программ.

2.5. Многопроходная модель

Многопроходная модель – это несколько итераций процесса построения прототипа ПП с добавлением на каждой следующей итерации новых функциональных возможностей или повышением эффективности ПП. (рисунок 2.5).