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

Стр 1 из 6Следующая ⇒

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

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

Рис. 2.1

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.2

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

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

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

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

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

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

Рис. 2.3.

Рис. 2.4.

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

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

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

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

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

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

Рис. 2.5

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

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

2) Анализ;

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

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

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

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

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

Стратегия

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

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

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

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

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

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

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

Анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение

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

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

1) первоначальная загрузка информации;

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

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

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

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

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

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

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

3. Формирование и анализ требований

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

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

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

a) выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц),

b) анализ (проверка целостности и законченности),

c) спецификация (документирование требований),

d) проверка правильности.

По уровням требования делятся на следующие категории.

1) Бизнес-требования, которые определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).

2) Пользовательские требования, определяющие набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Они могут выражаться в виде фраз утверждений, сценариев использования (use case) или пользовательских историй ({{lang-en|user stories), сценариев взаимодействия (scenario).

3) Функциональные требования, описывающие предполагаемое поведение системы, определяя действия, которые она способна выполнять. Они представляются в виде системной спецификации (system requirement specification, SRS).

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

1) Функциональные — тр еб ования к поведению системы:

a) Бизнес-требования;

b) Пользовательские требования;

c) Функциональные требования;

2) Нефункциональные — требования к характеру поведения системы:

a) Бизнес-правила, которые определяют ограничения, вытекающие из предметной области и свойств автоматизируемого объекта (предприятия);

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

- Ограничения на программные интерфейсы, в том числе к внешним системам;

- Требования к атрибутам качества;

- Требования к применяемому оборудованию и ПО;

c) Требования к документированию;

d) Требования к дизайну и юзабилити (удобству);

e) Требования к безопасности и надёжности;

f) Требования к показателям назначения (производительность, устойчивость к сбоям и т. п.)

g) Требования к эксплуатации и персоналу;

h) Прочие требования и ограничения (внешние воздействия, мобильность, автономность и т.п.).

Источниками требований могут быть следующие объекты.

· Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения);

· Нормативное обеспечение организации (регламенты, положения, уставы, приказы);

· Текущая организация деятельности объекта автоматизации;

· Модели деятельности (диаграммы бизнес-процессов);

· Представления и ожидания потребителей и пользователей системы;

· Журналы использования существующих программно-аппаратных систем;

· Конкурирующие программные продукты.

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

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

Анализ требований включает три типа операций.

1) Сбор, при котором происходит общение с клиентами и пользователями и анализ предметной области.

2) Анализ, на котором определяют, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; выполняют решение этих проблем и выявляют взаимосвязи требований.

3) Документирование — представление требований в одной из возможных форм, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.

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

Рис. 3.1

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

Рис. 3.2

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

Спецификация требований программного обеспечения (Software Requirements Specification, SRS) является полным описанием поведения системы, которая будет создана. Она включает ряд сценариев использования, которые описывают все виды взаимодействия пользователей с программным обеспечением. Сценарии использования также называют функциональными требованиями. В дополнении к ним, спецификации программного обеспечения также содержат нефункциональные требования.

Рекомендуемые подходы к спецификации требований программного обеспечения описаны стандартом IEEE 830—1998. Этот стандарт описывает возможные структуры, желательное содержание и качество спецификации требований программного обеспечения.

12 3 4 5 6 Следующая ⇒