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

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

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

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

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

Жизненный цикл программного обеспечения - период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: -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 показывает использование прототипной стратегии. Обычно, целями прототипирования является лучшее понимание требований к программному обеспечению и уменьшение технических рисков и рисков разработки при создании конечного продукта. Исходные требования используются как базис для получения прототипа. Этот прототип преобразуется в окружение, типичное для конкретного использования системы при разработке. Результатом преобразований является уточненные данные, которые используются для создания конечного программного продукта.

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

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

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла программного обеспечения (ЖЦ ПО).

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

ЖЦ баз данных пока стандартами не регламентирован – существующие стандарты относятся только к ЖЦ программных средств.

Стандарты ЖЦ ПС могут использоваться как директивные, руководящие или рекомендательные документы.

Наиболее полно ЖЦ, технология разработки и обеспечения качества ПС отражены в стандартах ISO (International Standards Organisation – Международная организация по стандартизации). Стандарт ISO 12207:1995 – «Процессы жизненного цикла программных средств» - наиболее полно отражает архитектуру, работы, организацию и управление ЖЦ ПС.

Используемые реально в фирмах модели ЖЦ ПС в последнее время изменяются относительно приведенных в стандартах в связи с внедрением и развитием объектно-ориентированного анализа и методов быстрой разработки ПП, CASE-систем и языков четвертого поколения. В новых моделях сокращаются работы по непосредственному созданию программных компонентов и детализируются работы по системному анализу и проектированию ПС и БД.

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

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

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

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

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

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO /IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO /IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

Разработка ПО включает в себя , как правило:

· анализ;

· проектирование;

· реализацию (программирование).

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

На эту фазу прихо­дятся, как правило, 50% стоимости ПИ и 32% трудозатрат.

Эксплуатация начинается тогда, когда изделие пере­дается пользователю, находится в действии и используется.

Включает в себя:

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

Обеспечение эксплуатационной документацией;

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

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

Фазу сопровождения также называют фазой продолжаю­щейся разработки.

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

Практиками признано, что эта часть жизнен­ного цикла (ЖЦ) должна приниматься во внимание с момента начала разработки с целью совершенствования ПИ в соответ­ствии с потребностями пользователя.

Процесс сопровождения , продолжатся собственно параллельно эксплуатации ПИ.

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

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

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

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

Каждый процесс характеризуется:

определенными задачами и методами их решения,

исходными данными, полученными на предыдущем этапе,

результатами.

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

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. (Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи , включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

· каскадная модель (70-85 г.г.);

· спиральная модель (86-90 г.г.).

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

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

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

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

Рис. 1. Каскадная схема разработки ПО

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

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

· Неадекватное управление рисками : риски связанные с проектом, выявляются на поздних стадиях выполнения проекта.

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

Рис. 2 Реальный процесс разработки ПО по каскадной схеме

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

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

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

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

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

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

Рис. 3. Спиральная модель ЖЦ

При создании ПО может быть использована «Модель переиспользования и реверсивной инженерии».

В ней основной вес проектных решений падает на проектирование. Целью данной модели является повторное использование (переиспользование) в текущих проектах хорошо проверенных на практике «старых» проектных решений, зафиксированных в библиотеках уже законченных проектов. В процессе анализа и предварительного проектирования намечаются планы работ, в которые включены, в том числе задачи проверки альтернативных проектных решений. Затем запускаются работы по созданию запланированных прототипов по каскадной схеме. В результате выбирается одно из альтернативных решений, разрабатываемых в параллельных витках для остаточного цикла разработки продукта. Возможен выбор смешанного варианта на основе объединения результатов нескольких витков.

В случае неудачи реализованной версии возможен откат по проекту (Reengineering).

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

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

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

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

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

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

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

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

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

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

• ГОСТ 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-го кадра, когда информация закладывается в сознание юзера независимо от него самого).

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

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

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

Жизненный цикл программного обеспечения включает в себя шесть этапов:

– анализ требований;

– определение спецификаций;

– проектирование;

– кодирование;

– тестирование;

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

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

– Что должна делать программа?

– В чем состоят реальные проблемы, разрешению которых она должна способствовать?

– Что представляют собой входные данные?

– Какими должны быть выходные данные?

– Какими ресурсами располагает проектировщик?

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

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

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

Тестирование . На этом этапе производится всесторонняя проверка программ.

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

Тестирование . Существуют три аспекта проверки программы на:

– правильность;

– эффективность реализации;

– вычислительную сложность.

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

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

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

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

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

Третий способ проверки эффективности реализации основан на способности некоторых компиляторов строить коды для вычисления логических выражений так, что вычисления прекращаются, если результат становится очевидным. Например, в выражении A or В or С, если А имеет значение «истина», то переменные В и С уже не проверяются. Таким образом, можно сэкономить время, разместив переменные А, В, С так, чтобы первой стояла переменная, которая вероятнее всего будет истинной, а последней та, которая реже всего принимает истинное значение.

Четвертый прием – исключение циклов.

Пятый прием – развертывание циклов.

Это далеко не полный перечень способов оптимизации. Здесь приведены лишь самые очевидные из них. Следует, кроме того, заметить, что не всегда стоит увлекаться погоней за быстродействием, так как при этом чаще всего ухудшается удобочитаемость программ. В том случае, когда выигрыш получается «мизерный», вряд ли стоит предпочитать его ясности и читабельности программы.

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

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) программных модулей, связанных иерархическим обра­зом;
• должен отсутствовать эффект после действия очередного исполнения программы на последующие исполнения;
• регламентировано использование локальных переменных и регистров ЭВМ.

Главная » Кредиты » Жизненный цикл процесса разработки. Жизненный цикл программных систем