Ваш бизнес - От идеи до реализации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессы ЖЦ ПО:

Основные,

Вспомогательные,

Организационные.


Основные:

1. Приобретение – действия и задачи заказчика, приобретающего ПО;

2. Поставка – действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой;

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

4. Эксплуатация – действия и задачи оператора организации, эксплуатирующей систему;

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

Вспомогательные:

1. Документирование – формализованное описание информации, созданной в течение ЖЦ ПО;

2. Управление конфигурацией– применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями;

3. Обеспечение качества– обеспечение гарантий того, что ПО и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам;

4. Верификация – определение того, что программные продукты полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями;

5. Аттестация – определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению;

6. Совместная оценка– оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами;

7. Аудит – определение соответствия требованиям, планам и условиям договора;

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

Организационные:

1. Управление – действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами;

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

3. Усовершенствование – оценка, измерение, контроль и усовершенствование процессов ЖЦ;

4. Обучение – первоначальное обучение и последующее постоянное повышение квалификации персонала.

В 2002 г. был опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение – поддержка создания компьютеризированных систем.



Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

Приобретение (внутренние решения или решения внешнего поставщика);

Поставка (внутренние решения или решения внешнего поставщика);

2. Процессы предприятия:

Управление окружающей средой предприятия;

Инвестиционное управление;

Управление ЖЦ ИС;

Управление ресурсами;

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

3. Проектные процессы:

Планирование проекта;

Оценка проекта;

Контроль проекта;

Управление рисками;

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

Управление информационными потоками;

Принятие решений.

4. Технические процессы:

Определение требований;

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

Разработка архитектуры;

Внедрение;

Интеграция;

Верификация;

Переход;

Аттестация;

Эксплуатация;

Сопровождение;

Утилизация.

5. Специальные процессы:

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


Создание основных процессов ЖЦ ПО по ИС (ISO/IEC 15288)

Процесс (исполнитель процесса) Действия Вход Результат
Приобретение (заказчик) - Инициирование - Подготовка заявочных предложений - Подготовка договора - Контроль деятельности поставщика - Приемка ИС - Решение о начале работ по внедрению ИС - Результаты обследования действий заказчика - Результаты анализа рынка ИС/ тендера - План поставки/ разработки - Комплексный тест ИС - Технико-экономическое обоснование внедрения ИС - Техническое задание на ИС - Договор на поставку/ разработку - Акты приемки этапов работы - Акт приемно-сдаточных испытаний
Поставка (разработчик ИС) - Инициирование - Ответ на заявочные предложения - Подготовка договора - Планирование исполнения - Поставка ИС - Техническое задание на ИС - Решение руководства об участии в разработке - Результаты тендера - Техническое задание на ИС - План управления проектом - Разработанная ИС и документация - Решение об участии в разработке - Коммерческие предложения/ конкурсная заявка - Договор на поставку/ разработку - План управления проектом - Реализация/ корректировка - Акт приемно-сдаточных испытаний
Разработка (разработчик ИС) - Подготовка - Анализ требований к ИС - Проектирование архитектуры ИС - Разработка требований к ПО - Проектирование архитектуры ПО - Детальное проектирование ПО - Кодирование и тестирование ПО - Интеграция ПО и квалифицированное тестирование ПО - Интеграция ИС и квалифицированное тестирование ИС - Техническое задание на ИС - Техническое задание на ИС, модель ЖЦ - Подсистемы ИС - Спецификации требования к компонентам ПО - Архитектура ПО - Материалы детального проектирования ПО - План интеграции ПО, тесты - Архитектура ИС, ПО, документация на ИС, тесты - Используемая модель ЖЦ, стандарты разработки - План работ - Состав подсистем, компоненты оборудования - Спецификации требования к компонентам ПО - Состав компонентов ПО, интерфейсы с БД, план интеграции ПО - Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам - Тексты модулей ПО, акты автономного тестирования - Оценка соответствия комплекса ПО требованиям ТЗ - Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

Стадии создания систем (ISO/IEC 15288)


СРС: Создать техническое задание для проекта «Очередь» на сайте www.mastertz.ru

Модели ЖЦ ПО:

1. каскадная,

2. спиральная,

3. итерационная.

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

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

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

Разработка требований
Формирование

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

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

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

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

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

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

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

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

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

Один из примеров реализации спиральной модели - RAD.

Основные принципы RAD:

1. Инструментарий должен быть нацелен на минимизацию времени разработки;

2. Создание прототипа для уточнения требований заказчика;

3. Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком;

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

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

6. Управление проектом должно минимизировать длительность цикла разработки.

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

Рис. 22. Итерационная модель ЖЦ ПО

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering - Software life cycle processes».

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

Процессы жизненного цикла ПО

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

  • процессы соглашения - два процесса;
  • процессы организационного обеспечения проекта - пять процессов;
  • процессы проекта - семь процессов;
  • технические процессы - одиннадцать процессов;
  • процессы реализации программных средств - семь процессов;
  • процессы поддержки программных средств - восемь процессов;
  • процессы повторного применения программных средств - три процесса.
  • Основные:
    • Приобретение (действия и задачи заказчика, приобретающего ПО)
    • Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
    • Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
    • Эксплуатация (действия и задачи оператора - организации, эксплуатирующей систему)
    • Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение - внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
  • Вспомогательные
    • Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
    • Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
    • Обеспечение качества (обеспечение гарантий того, что ИС и процессы её ЖЦ соответствуют заданным требованиям и утверждённым планам)
    • Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
    • Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
    • Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
    • Аудит (определение соответствия требованиям, планам и условиям договора)
    • Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
  • Организационные
    • Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
    • Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
    • Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
    • Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

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

  1. Инициирование приобретения
  2. Подготовка заявочных предложений
  3. Подготовка и корректировка договора
  4. Надзор за деятельностью поставщика
  5. Приёмка и завершение работ

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

  1. Формирование требований к системе
  2. Формирование списка программных продуктов
  3. Установление условий и соглашений
  4. Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

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

Модель ЖЦ ПО включает в себя:

  1. Стадии;
  2. Результаты выполнения работ на каждой стадии;
  3. Ключевые события - точки завершения работ и принятия решений.

Аннотация.

Введение.

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

Введение.

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

Введение.

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

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

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

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

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

Вывод к п. 1.1

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

Введение.

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

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

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

Вывод к п. 1.2.

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

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

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

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

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

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

Литература.


Введение

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

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


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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НАЗВАНИЕ

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

ОПИСАНИЕ

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

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

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

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

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

В соответствии со стандартом 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).

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

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

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

Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter
ПОДЕЛИТЬСЯ:
Ваш бизнес - От идеи до реализации