/

Модели жизненного цикла программных систем. Модели жизненного цикла информационных систем

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

Разработка ПО имеет следующие специфические особенности:

    неформальный характер требований к ПО и формализованный основной объект разработки – программы;

    творческий характер разработки;

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

    при своем использовании (эксплуатации) ПО не расходуется и не изнашивается;

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

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

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

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

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

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

    системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения;

    качество ПО должно быть высоким;

    разработка ПО должна быть осуществлена в рамках выделенного бюджета;

    системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющемся ПО;

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

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

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

Основным понятием программной инженерии является понятие жизненного цикла ПО .

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

С точки зрения статической структуры ЖЦ является совокупностью процессов ЖЦ.

Процесс ЖЦ – набор взаимосвязанных действий, преобразующих некоторые входные данные и ресурсы в выходные.

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

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

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

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

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

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

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

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

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

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

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

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

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

    каскадная (водопадная);

    эволюционная;

    основанная на формальных преобразованиях;

    итерационные (пошаговая и спиральная).

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

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

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

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

На этапе тестирования производится собственно тестирование, а также отладка и оценка качества ПО.

Ввод в действие – это развертывание ПО на целевой вычислительной системе, обучение пользователей и т.п.

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

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

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

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

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

Схема эволюционной модели ЖЦ

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

Особенности итерационных моделей :

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

    модель напоминает несколько последовательных «каскадов»;

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

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

Рис. 3.1.3.-1 Схема пошаговой итерационной модели ЖЦ.

Особенности итерационной спиральной модели :

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

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

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

Достоинства итерационных моделей:

    полный учет требований заказчика, большее его участие в проекте;

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

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

Рис. 3.1.3.-2 Схема спиральной модели ЖЦ

Проблемой современной программной инженерии являются «тяжелые» процессы. Характеристики «тяжелого» процесса :

    необходимость документировать каждое действие разработчиков;

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

    отсутствие гибкости;

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

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

    Диалог «лицом к лицу» – самый эффективный способ обмена информацией.

    Избыточная «тяжесть» технологии (дополнительные рабочие продукты, планы, диаграммы, документы) стоит дорого.

    Более многочисленные команды требуют более «тяжелых» технологий.

    Большая «тяжесть» процесса подходит для проектов с большей критичностью.

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

    Дисциплина, умение и понимание противостоят процессу, формальности и документированию.

    Потеря эффективности в некритических видах деятельности вполне допустима.

Под критичностью понимаются масштабы последствий отказа разрабатываемого ПО. Уровни критичности:

    потеря удобства;

    потеря важных данных и/или рабочего времени;

    потеря невозместимых средств, дорогостоящего оборудования;

    потеря человеческой жизни.

Основные направления развития современной программной инженерии:

    Управление требованиями

    Управление конфигурацией и изменениями

    Управление качеством ПО

    Итерационная разработка ПО

    Использование компонентной архитектуры (объектно-ориентированный подход)

    Визуальное моделирование ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки этой модели:

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

При применении каскадной модели могут иметь место следующие факторы риска:

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

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

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

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

2.2.2. Инкрементная модель ЖЦ

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

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

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

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

При применении данной модели необходимо учитывать следующие факторы риска:

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

Данную модель ЖЦ целесообразно использовать, в случаях когда:

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

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

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

В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ разделены на три группы (рис. 2.1).

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

1. Формирование требований к ПО.

2. Проектирование.

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

4.Тестирование.

5. Ввод в действие.

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

7. Снятие с эксплуатации.

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

a) каскадная и

b) спиральная (эволюционная).

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

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

На каждой стадии формируется законченный набор проектной документации;

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

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

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

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

Каскадную (эволюционную) модель можно представить в виде диаграммы, которая приведена на рисунке 2.5.

Одним из результатов применения спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений , или RAD (Rapid Application Development). Жизненный цикл ПО в соответствии с этим способом включает в себя четыре стадии:

1) анализ и планирование требований;

2) проектирование;

3) реализация;

4) внедрение.

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

1) Стратегия;

2) Анализ;

3) Проектирование;

4) Реализация;

5) Тестирование;

6) Внедрение;

7) Эксплуатация и техническая поддержка.

Стратегия

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

Итогом этапа определения стратегии становится документ, в котором четко сформулировано следующее:

Что именно причитается заказчику, если он согласится финансировать проект;

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

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

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

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

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

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

a) функции - информация о событиях и процессах, которые происходят в бизнесе;

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

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

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

На этапе проектирования формируется модель данных. Проектировщики обрабатывают данные анализа. Конечным продуктом этапа проектирования являются схема базы данных (если таковая существует в проекте) или схема хранилища данных (ER-модель) и набор спецификаций модулей системы (модель функций).

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

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

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

Рассмотрение результатов анализа и проверка их полноты;

Семинары с заказчиком;

Определение критических участков проекта и оценка его ограничений;

Определение архитектуры системы;

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

Проектирование хранилища данных: модель базы данных;

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

Определение требований к процессу тестирования;

Определение требований к безопасности системы.

Реализация

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

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

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

Этап разработки сопряжен с этапом тестирования, и оба процесса идут параллельно. Синхронизирует действия тестеров и разработчиков система bug tracking.

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

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

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

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

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок - bug tracking, которая обеспечивает следующие функции:

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

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

Отчеты об актуальных ошибках по компонентам системы;

Информация об ошибке и ее история;

Правила доступа к ошибкам тех или иных категорий;

Интерфейс ограниченного доступа к системе bug tracking для конечного пользователя.

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

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

a) автономные тесты модулей; они используются уже на этапе разработки компонентов системы и позволяют отслеживать ошибки отдельных компонентов;

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

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

d) приемосдаточный тест ; основное его назначение - сдать систему заказчику;

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

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

Отдельного компонента информационной системы;

Группы компонентов системы;

Основных модулей системы;

Операционной системы;

Жесткий сбой (отказ питания, жестких дисков).

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

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

Внедрение

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

Ввод в эксплуатацию проходит как минимум три стадии:

2) накопление информации;

3) выход на проектную мощность (то есть собственно переход к этапу эксплуатации).

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

В период накопления информации в информационной системе выявляется наибольшее количество ошибок, связанных с многопользовательским доступом. Вторая категория исправлений связана с тем, что пользователя не устраивает интерфейс. При этом циклические модели и модели с обратной связью этапов позволяют снизить затраты. Рассматриваемый этап является также наиболее серьезным тестом - тестом одобрения пользователем (customer acceptance tests).

Выход системы на проектную мощность в хорошем варианте - это доводка мелких ошибок и редкие серьезные ошибки.

Эксплуатация и техническая поддержка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Поделиться