Жизненный цикл программного продукта

Технологический раздел

Технология разработки программного продукта

Основные понятия и определения программного продукта

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

Программные продукты могут создаваться как:

- индивидуальная разработка под заказ;

- разработка для массового распространения среди пользователей.

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

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

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

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

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

Сопровождение программного продукта — поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок.

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

Основными характеристиками программ являются:

- алгоритмическая сложность (логика алгоритмов обработки информации);

- состав и глубина проработки реализованных функций обработки;

- полнота и системность функций обработки;

объем файлов программ;

- требования к операционной системе и техническим средствам обработки со стороны

- программного средства;

- объем дисковой памяти;

- размер оперативной памяти для запуска программ;

- тип процессора;

- версия операционной системы;

- наличие вычислительной сети и др.

Программные продукты имеют многообразие показателей качества:

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

Мобильный (многоплатформный) программный продукт может быть установлен на различных моделях компьютеров и операционных систем, без ограничений на его эксплуатацию в условиях вычислительной сети. Функции обработки такого программного продукта пригодны для массового использования без каких- либо изменений.

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

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

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

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

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

Коммуникативность программных продуктов основана на максимально возможной их интеграции с другими программами, обеспечении обмена данными в общих форматах представления (экспорт/импорт баз данных, внедрение или связывание объектов обработки и др.).

Большое значение имеет проводимый фирмой маркетинг, который включает:

- формирование политики цен для завоевания рынка;

- широкую рекламную кампанию программного продукта;

- создание торговой сети для реализации программного продукта (так называемые дилерские и дистрибьютерные центры);

- обеспечение сопровождения и гарантийного обслуживания пользователей программного продукта, создание горячей линии (оперативный ответ на возникающие в процессе эксплуатации программных продуктов вопросы);

- обучение пользователей программного продукта.

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

Жизненный цикл программного продукта

Жизненным циклом ПП называют период от момента появления идей создания некоторого ПО до момента завершения его поддержки фирмой разработчиков или фирмой выполнявших сопровождение.

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

Модель жизненного цикла ПО включает в себя:

- Стадии;

- Результаты выполнения работ на каждой стадии;

- Ключевые события — точки завершения работ и принятия решений.

 

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях.

Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.

Модели жизненного цикла ПО:

Водопадная (каскадная, последовательная) модель

Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом (Рисунок 3.1). Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

- Этапы проекта в соответствии с каскадной моделью:

- Формирование требований;

- Проектирование;

- Реализация;

- Тестирование;

- Внедрение;

- Эксплуатация и сопровождение.

 

 

Преимущества:

- Полная и согласованная документация на каждом этапе;

- Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы.

Неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную

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

Рисунок 3.1 - Каскадная модель жизненного цикла

 

 

Поэтапная модель с промежуточным контролем (рисунок 3.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

 

Рисунок 3.2 - Поэтапная модель с промежуточным контролем

 

Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта.

 

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

Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности.

Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте».

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

 

Спиральная модель

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом (Рисунок 3.3). Она основана на классическом цикле Деминга PDCA (plan-do-check-act).

При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

- риск превышения сроков и стоимости проекта;

- необходимость выполнения ещё одной итерации;

- степень полноты и точности понимания требований к системе;

- целесообразность прекращения проекта.

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

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

- Дефицит специалистов;

- Нереалистичные сроки и бюджет;

- Реализация несоответствующей функциональности;

- Разработка неправильного пользовательского интерфейса;

- Ненужная оптимизация и оттачивание деталей;

- Непрекращающийся поток изменений;

- Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию;

- Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами;

 

- Недостаточная производительность получаемой системы;

- Разрыв в квалификации специалистов разных областей. [9]

 

Рисунок 3.3 - Спиральная модель жизненного цикла