Жизненный цикл и этапы разработки по. Жизненный цикл программного обеспечения

Аннотация.

Введение.

1. Жизненный цикл ПО

Введение.

Шаги процесса программирования по Райли

Введение.

1.1.1. Постановка задачи.

1.1.2. Проектирование решения.

1.1.3. Кодирование алгоритма.

1.1.4. Сопровождение программы.

1.1.5. Программная документация.

Вывод к п. 1.1

1.2. Определение ЖЦПО по Леману.

Введение.

1.2.1 Определение системы.

1.2.2. Реализация.

1.2.3. Обслуживание.

Вывод к п. 1.2.

1.3. Фазы и работы ЖЦПО по Боэму

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

1.3.2. Экономическое обоснование каскадной модели.

1.3.3. Усовершенствование каскадной модели.

1.3.4. Определение фаз жизненного цикла.

1.3.5. Основные работы над проектом.

Литература.

Введение

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

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

1 Жизненный цикл ПО

ВВЕДЕНИЕ

ЖЦПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

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

Наиболее известной и полной, пожалуй, является структура ЖЦПО по Боэму, включающая восемь фаз. Она и будет представлена в дальнейшем наиболее подробно.

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

И, для разнообразия, – приведем шаги процесса программирования, представленные Д.Райли в книге «Использование языка Модула-2». Это представление, по-моему, является весьма простым и привычным, с него и начнём.

1.1 Шаги процесса программирования по Райли

Процесс программирования включает четыре шага (рис. 1):

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

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

кодирование программы, т. е. перевод спроектированного решения в программу, которая может быть выполнена на машине;

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

Рис. 1.Четыре шага программирования.

Программирование начинается с того момента, когда пользователь , т.е. тот, кто нуждается в программе для решения задачи, излагает проблему системному аналитику. Пользователь и системный аналитик совместно определяют постановку задачи. Последняя затем передается алгоритмисту , который отвечает за проектирование решения. Решение (или алгоритм) представляет последовательность операций, выполнение которых приводит к решению задачи. Поскольку алгоритм часто не приспособлен к выполнению на машине, его следует перевести в машинную программу. Эта операция выполняется кодировщиком. За последующие изменения в программе несет ответственность сопровождающийпрограммист. И системный аналитик, и алгоритмист, и кодировщик, и сопровождающий программист – все они являются программистами.

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

1.1.1 Постановка задачи

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

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

Характеристики Хорошей Постановки Задачи:

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

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

Ясность , т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи – это единственный контракт между ними.

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

Стандартная форма постановки задачи.

Рассмотрим следующую постановку задачи: «Ввести три числа и вывести числа в порядке».

Такая постановка не удовлетворяет приведенным выше требованиям: она не является ни точной, ни полной, ни понятной. Действительно, должны ли числа вводиться по одному на строке или все числа на одной строке? Означает ли выражение «в порядке» упорядочение от большего к меньшему, от меньшего к большему или тот же порядок, в каком они были введены.

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

наименование задачи (схематическое определение);

общее описание (краткое изложение задачи);

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

пример (хороший пример может передать сущность задачи, а также проиллюстрировать различные случаи).

Пример. Постановка задачи в стандартной форме.

НАЗВАНИЕ

Сортировка трех целых чисел.

ОПИСАНИЕ

Ввод и вывод трех целых чисел, отсортированных от меньшего числа к большему.

Вводятся три целых числа по одному числу на строке. При этом целым числом является одна или несколько последовательных десятичных цифр, которым может предшествовать знак плюс «+» или знак минус «–».

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

1) Если введено менее трех чисел, программа ждет дополнительного ввода.

Стандарты жизненного цикла ПО

• ГОСТ 34.601-90
• ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)

Стандарт ГОСТ 34 .601-90

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

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

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

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

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

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

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

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

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

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

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

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

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек :

1. Concept of Operations (COO) - концепция (использования) системы;
2. Life Cycle Objectives (LCO) - цели и содержание жизненного цикла;
3. Life Cycle Architecture (LCA) - архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
4. Initial Operational Capability (IOC) - первая версия создаваемого продукта, пригодная для опытной эксплуатации;
5. Final Operational Capability (FOC) –- готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Методологии разработки ПО

• Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
• Экстремальное программирование (англ. Extreme Programming, XP ). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.
• ЕСПД - комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

Литература

• Братищенко В.В. Проектирование информационных систем. - Иркутск: Изд-во БГУЭП, 2004. - 84 с.
• Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М .: Финансы и статистика, 2000.
• Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. - М .: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
• Мишенин А.И. Теория экономических информационных систем. - М .: Финансы и статистика, 2000. - 240 с.

Примечания

Wikimedia Foundation . 2010 .

Смотреть что такое "Жизненный цикл программного обеспечения" в других словарях:

Период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: 1 возникновение и исследование идеи; 2 анализ требований и проектирование; 3 программирование; 4 тестирование и отладка; 5 ввод программы в действие; 6… … Финансовый словарь

жизненный цикл программного обеспечения - … Справочник технического переводчика

жизненный цикл программного обеспечения - 3.7 жизненный цикл программного обеспечения; жизненный цикл ПО (software lifecycle): Последовательность следующих друг за другом процессов создания и использования программного обеспечения программируемой связанной с безопасностью здания или… …

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

Цикл программного обеспечения жизненный - Жизненный цикл программного обеспечения (software lifecycle): период времени, включающий в себя стадии: разработки требований к программному обеспечению, разработки программного обеспечения, кодирования, тестирования, интеграции, установки, а… … Официальная терминология

жизненный цикл - 4.16 жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Источник … Словарь-справочник терминов нормативно-технической документации

Это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из… … Википедия

Жизненный цикл информационной системы это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в… … Википедия, О. В. Казарин. В книге рассмотрены теоретические и прикладные аспекты проблемы зашиты программного обеспечения от различного рода злоумышленных действий. Особое внимание уделено моделям и методам создания…

ПО – комплекс программ, предназначенный для решения задачи. Жизненный цикл ПО – отрезок времени от момента возникновения необходимости в создании ПО до момента снятия его с эксплуатации. Стадии жизненного цикла ПО, которые могут протекать как последовательно, так и пераллельно, так и квазипараллельно:

1. разработка;

2. эксплуатация;

3. сопровождение.

На фазе сопровождения, как правило, выполняются следующие виды работ:

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

При проведении разработки чётко выделяют следующие этапы:

1. определение требований к ПО, которое предусматривает сбор необходимой информации.
2. внешнее проектирование (информация, содержащаяся в техническом задании, подвергается анализу и строгой формализации; основное назначение этого этапа – дать разработчику наиболее полное и точное представление о том, что должно в конечном итоге получиться). Не является обязательным.
3. внутреннее проектирование (уточняются те сведения, полученные на предыдущих этапах, и вырабатываются структуры данных, используемые в ПО, определяется модульная структура ПО, правила взаимодействия модулей в процессе передачи управления или обмена информацией и т.д.).
4. программирование (кодирование).
5. тестирование и отладка. Тестирование – процесс выявления факта наличия ошибок в программе. Отладка – тестирование + диагностика и локализация ошибок + устранение ошибок.
6. испытание ПО. Испытание – особый вид тестирования, цель которого выявление несоответствий между полученным ПО и требованиями технического задания.

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

§ каскадная модель

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

31. Техническое задание (ГОСТ 19.201 – 78). Его основные разделы и их содержание.

В соответствии с этим стандартом в техническое задание включаются следующие разделы:

2. введение;

3. основание для разработки;

4. назначение разработки;

5. требования к программному изделию;

6. требования к документации;

7. технико-экономические показатели;

8. стадии и этапы разработки;

9. порядок контроля и приёмки

10. приложение.

Введение:

§ наименование;

§ краткая характеристика в области применения ПО.

Основное назначение этого раздела – продемонстрировать актуальность данной разработки и какое место эта разработка занимает в ряду подобных.

Основание для разработки:

§ наименование документа, на основании которого ведётся разработка;

§ организация, утвердившая данный документ;

§ наименование или условное обозначение темы разработки.

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

Назначение разработки:

§ описание функционального и эксплуатационного назначения данной системы с указанием категории её пользователей.

Требования к программе или к программному изделию.

Этот раздел должен включать следующие подразделы:

1. требования к функциональным характеристикам;

2. требования к надёжности;

3. условия эксплуатации;

4. требования к составу и параметрам технических средств;

5. требования к информационной и программной совместимости;

6. требования к маркировке и упаковке;

7. требования к транспортированию и хранению.

8. специальные требования.

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

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

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

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

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

В разделе требования к маркировке и упаковке указываются способы маркировки и упаковки ПО.

В разделе требования к транспортированию и хранению указываются условия транспортирования, места хранения, условия складирования и сроки хранения в различных условиях.

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

Требования к программной документации.

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

Технико-экономические показатели.

Стадии и этапы разработки.

В нём указывают стадии и этапы разработки выполняемых работ с указанием сроков и исполнителей.

Порядок контроля и приёмки.

В нём указывают порядок проведения испытаний и общие требования по проведению приёмки.

Приложение: перечень НИР, обоснования, расчёты, и другие документы, которые следует использовать для разработки.

В зависимости от особенностей разрабатываемого ПО разрешается уточнять описанные разделы, вводить новые или объединять существующие.

32. Структурное проектирование ПО: метод структурного анализа, проектирование модульной структуры.

Метод структурного анализа базируется на ряде общих принципов, перечисленных ниже.

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

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

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

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

5. Принцип полноты заключается в контроле на присутствие лишних элементов.

6. Принцип непротиворечивости заключается в обоснованности и согласованности элементов.

7. Принцип логической независимости заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического исполнения.

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

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

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

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

* функции, которые система должна выполнять;

* отношения между данными;

* зависящее от времени поведение системы (аспекты реального времени).

Для этого применяются:

* DFD (Data Flow Diagrams) – диаграммы потоков данных совместно со словарями данных и спецификациями процессов;

* ERD (Entity–Relationship Diagrams) – диаграммы сущность–связь;

* STD (State Transition Diagrams) – диаграммы переходов–состояний.

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

Структура каждого хранилища описывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания, зависящего от времени поведения системы, которые описываются с помощью STD. Эти связи показаны на рисунке.

Взаимосвязь средств структурного анализа

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

К преимуществам разработки ПО с использованием модулей можно отнести следующее:

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

Для проектирования и документирования модульной структуры применяются структурные карты Константайна (Constantine), которые являются моделью отношений между программными модулями.

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

Элементы структурных карт.

Базовым элементом структурной карты является модуль. Можно выделить различные типы модулей:

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

2. Подсистема – совокупность ранее определенных модулей. Может повторно использоваться любое число раз на любых диаграммах.

3. Библиотека отличается от подсистемы тем, что определена вне контекста системы.

4. Область данных используется для указания модулей, содержащих области глобальных (распределенных) переменных.

Типы модулей на структурных картах.

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

Для моделирования условных и циклических вызовов применяются условные и итерационные узлы.

Изображения условного и итерационного вызовов.

Типовые модульные структуры. В зависимости от задач, решаемых разработчиком, и от выбранного метода проектирования модульное ПО может иметь одну из следующих основных структур: монолитно - модульную; последовательно - модульную; модульно - иерархическую; модульно - хаотическую.

а - монолитная; б - последо­вательная; в - иерархическая; г – хаотическая.

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

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

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

Модульно - хаотические структуры. Такие программы сложны для проверки и сопровождения. Эта структура допустима только в системах реального времени с жесткими объемно-временными характеристиками, когда с помощью программ с другой структурой невозможно их достичь.

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

• должна быть унифицирована структура ПО и правила оформления описания каждого программного модуля;
• каждый модуль характеризуется функциональной законченностью, автономностью и независимостью в оформлении от модулей, которые ею используют и которые он вызывает;
• применяются стандартные правила организации связей модуля по управлению и информации (данным) с другими модулями;
• ПО разрабатываются в виде совокупности небольших по количеству операторов (до 100) программных модулей, связанных иерархическим обра­зом;
• должен отсутствовать эффект после действия очередного исполнения программы на последующие исполнения;
• регламентировано использование локальных переменных и регистров ЭВМ.

В общем случае программная система помимо собственно программ содержит еще и аппаратное обеспечение, а также обычно рассматривается в окружении других программно-аппаратных систем.

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

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

Этапы жизненного цикла ПО

Жизненный цикл программного обеспечения - период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: -1- возникновение и исследование идеи; -2- анализ требований и проектирование; -3- программирование; -4- тестирование и отладка; -5- ввод программы в действие; -6- эксплуатация и сопровождение; -7- завершение эксплуатации.

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

Примеры описания жизненного цикла

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

В отечественных нормативных документах (например, ГОСТ ЕСПД) принято следующее разграничение на этапы, которое приводится с указанием аналогий из списка, данного в начале раздела:

разработка технического задания (этапы 1 и 2);

технический проект (третий этап до 3.2.1 включительно);

рабочий проект (3.2.2, 4.2.1 и, частично, 4.2, 4.3);

экспериментальное внедрение (4.2 и 4.3);

сдача в промышленную эксплуатацию (этап 5);

промышленная эксплуатация (этап 6).

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

Рис. 1.1 Пример жизненного цикла программных систем

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

Анализ целевых требований (2.1). Определяются, без учета средств реализации, общие характеристики системы, которым она должна удовлетворять. Устанавливается, что и как должна делать система.

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

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

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

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

Кодирование и тестирование программного обеспечения (4.1.1 и 4.1.2). Создание, тестирование отдельных модулей, документирование и приемка программных компонентов, которые составляют программную систему.

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

Интеграция системы (4.3). Тестирование работоспособности и функциональной законченности частей общей системы в целом.

Приемка и поставка системы (5). Производится приемка системы заказчиком, и поставка ему системы.

Эксплуатация и сопровождение системы (6). Выпуск последующих вариантов или версий системы, необходимость в которых возникает из-за устранений дефектов, отработки измененных требований и т.д.

Завершение проекта (7). Формирование посториорной модели проектных действий с анализом достоинств, недостатков и т.д., и использование их в качестве основания для улучшения процесса разработки.

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

этап планирования, который определяет и координирует действия по разработке программной системы (этап 1);

этап разработки, на котором создается программная система:

постановку задачи (этап 2),

проектирование (3),

кодирование (4.1.1),

получение исполняемого кода (4.1.1, 4.3);

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

Рис. 1.2 Вариант упрощенного жизненного цикла программной системы.

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

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

На рис. 1.3. показана последовательность этапов разработки программного обеспечения для отдельных компонентов единой программной системы с различными жизненными циклами.

Рис. 1.3 Последовательность этапов разработки компонент программного обеспечения

Для компонента W из множества системных требований к единому продукту формируется подмножество требований, относящихся к данному компоненту, используются эти требования при формировании проекта программного компонента, реализовывают этот проект в исходном коде и тогда интегрирует компонент с аппаратурой. Компонент X показывает использование ранее разработанного программного обеспечения. Компонент Y показывает использование простой отдельной функции, которая может быть закодирована прямо на основе требований к программному обеспечению. Компонент Z показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к программному обеспечению и уменьшение технических рисков и рисков разработки при создании конечного продукта. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в окружение, типичное для конкретного использования системы при разработке. Результатом преобразований является уточненные данные, которые используются для создания конечного программного продукта.

Практически все этапы жизненного цикла объединяются с верификацией.

Разработка ПО невозможна без понимания так называемого жизненного цикла программ. Рядовому юзеру это, может быть, и не нужно знать, но основные стандарты желательно усвоить (далее будет сказано, зачем это нужно).

Жизненный цикл что это такое в формальном понимании?

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

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

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

Начальные требования

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

Разработка ПО состоит из всех вышеупомянутых стадий и не может обойтись хотя бы без одной из них. Но для контроля для таких процессов установлены специальные стандарты.

Стандарты процессов жизненного цикла программного обеспечения

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

• ГОСТ 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

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

Виды ПО и апдейты

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

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

Пример на основе программы FL Studio

Изначально виртуальная студия-секвенсор FL Studio имела название Fruity Loops. Жизненный цикл ПО в его первичной модификации истек, но приложение несколько трансформировалось и приобрело нынешний вид.

Если говорить об этапах жизненного цикла, сначала на стадии постановки задачи задавалось несколько обязательных условий:

• создание барабанного модуля по типу ритм-машин вроде Yamaha RX, но с применением one-shot-сэмплов или секвенций в формате WAV, записанных в студиях вживую;
• интеграция в операционные системы Windows;
• возможность экспорта проекта в форматах WAV, MP3 и OGG;
• совместимость проектов с дополнительным приложением Fruity Tracks.

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

В связи с этим, на стадии тестирования и отладки разработчикам пришлось пойти по пути немецкой корпорации Steinberg и применить в требованиях к основному звуковому драйверу поддержку режима Full Duplex. Качество саунда стало выше и позволило изменять темп, высоту тона и накладывать дополнительные FX-эффекты в режиме реального времени.

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

Этим не ограничилось. На стадии управления проектом была введена поддержка подключения плагинов формата VST (сначала второй, а потом и третьей версии), в свое время разработанного компанией Steinberg. Грубо говоря, любой виртуальный синтезатор, поддерживающий VST-host мог подключаться к программе.

Неудивительно, что вскоре любой композитор мог использовать аналоги «железных» моделей, например, полные комплекты звуков некогда популярного Korg M1. Дальше - больше. Применение модулей вроде Addictive Drums или универсального плагина Kontakt позволило воспроизводить живые звуки реальных инструментов, записанных со всеми оттенками артикуляции в профессиональных студиях.

При этом разработчики постарались добиться и максимального качества, создав поддержку для драйверов ASIO4ALL, которые оказались на голову выше режима Full Duplex. Соответственно, повысился и битрейт. На сегодняшний день качество экспортируемого звукового файла может составлять 320 кбит/с при частоте дискретизации 192 кГц. А это профессиональный звук.

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

Перспективы развития

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

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

Даже в случае с ОС Windows такие тенденции можно заметить невооруженным взглядом. Вряд ли сегодня найдется хоть один юзер, использующий системы вроде модификаций 3.1, 95, 98 или Millennium. Их жизненный цикл закончился после выхода версии XP. Но вот серверные версии на основе технологий NT все еще актуальны. Даже Windows 2000 на сегодняшний день является не только весьма актуальной, но и по некоторым параметрам установки или безопасности даже превосходящей самые новые разработки. То же самое касается системы NT 4.0, а также специализированной модификации Windows Server 2012.

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

Но если говорить о том, что развитие ПО любого типа (управляющего или прикладного) не стоит на месте, можно только Ведь сегодня дело касается не только компьютерных систем, а и мобильных устройств, в которых применяемые технологии зачастую опережают компьютерный сектор. Появление процессорных чипов на основе восьми ядер - чем не самый лучший пример? А ведь еще далеко не каждый ноутбук может похвастаться наличием такого «железа».

Некоторые дополнительные вопросы

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

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

Но в компьютерных технологиях сегодня отдается предпочтение развитию автоматизированных систем управления (АСУ), которые применяются на производстве. Даже операционные системы, в сравнении со специализированными программами, проигрывают.

Те же среды на основе Visual Basic остаются намного более популярными, нежели Windows-системы. А о прикладном ПО под UNIX-системы речь не идет вообще. Что говорить, если практически все коммуникационные сети тех же Соединенных Штатов работают исключительно на них. Кстати, системы вроде Linux и Android тоже изначально создавались именно на этой платформе. Поэтому, скорее всего, у UNIX перспектив намного больше, чем у остальных продуктов вместе взятых.

Вместо итога

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

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

К тому же, иногда жизненные циклы могут зависеть от актуальности средств разработки. Если, допустим, какой-то язык программирования устаревает, никто же не будет писать программы на его основе, и уж тем более - внедрять их в автоматизированные системы управления на производстве. Тут уже на первый план выходят даже не программисты, а маркетологи, которые должны своевременно реагировать на изменения компьютерного рынка. И таких специалистов в мире найдется не так уж и много. Высококвалифицированные кадры, способные держать руку на пульсе рынка, становятся наиболее востребованными. И именно они зачастую являются так называемыми «серыми кардиналами», от которых зависит успех или проигрыш определенного программного продукта в сфере IT.

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

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

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

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