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

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

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

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

• Каскадная модель ( рис. 2.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
• ( рис. 2.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
• Спиральная модель ( рис. 2.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов ( макетирования ).

Рис. 2.1.

На практике наибольшее распространение получили две основные модели жизненного цикла :

• каскадная модель (характерна для периода 1970-1985 гг.);
• спиральная модель (характерна для периода после 1986.г.).

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

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

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

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

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

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

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

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

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

• ГОСТ 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): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Источник … Словарь-справочник терминов нормативно-технической документации

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

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

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

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

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

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

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

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

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

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

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

1. Каскадная модель (до 70-х годов XX в) определяет последовательный переход на следующий этап после завершения предыдущего.

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

Достоинство : хорошие показатели по срокам разработки и надежности при решении отдельных задач.

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

2. Итерационная модель (70-80-е годы XX в.) соответствует технологии проектирования «снизу - вверх». Допускает итерационные возвраты на предыдущие этапы после выполнения очередного этапа;

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

Достоинство: возможность оперативно вносить коррективы в проект.

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

3. Спиральная модель (80-90-е годы XX в.) соответствует технологии проектирования «сверху - вниз». Предполагает использование программного прототипа, допускающего программное расширение. Проект системы циклически повторяет путь от детализации требований к детализации программного кода.

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

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

Достоинства:

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

2. сокращение сроков проектирования;

3. упрощение создания проектной документации.

Недостаток: высокие требования к качеству общесистемного репозитория (общей базы проектных данных).

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

· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области.

· Проектирование. Пользователи под руководством разработчиков принимают участие в техническом проектировании.

· Конструирование. Разработчики проектируют рабочую версию ПО с использованием языков 4-го поколения;

· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник нашей мудрости - наш опыт, источник нашего опыта - наша глупость.

Саша Гитри, французский актер, режиссер

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

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

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

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

1.1. Общее описание жизненного цикла

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

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

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

На данный момент можно выделить следующие часто упоминаемые и используемые модели жизненного цикла:

• каскадная модель;
• процессная или поэтапная модель с промежуточным контролем;
• итерационная модель.

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

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

Рис. 1.1.

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

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

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