Здравствуйте, уважаемые хабровчане! Думаю будет кому-то интересно вспомнить какие модели разработки, внедрения и использования программного обеспечения существовали ранее, какие модели в основном используются сейчас, зачем и что это собственно такое. В этом и будет заключаться моя небольшая тема.
Собственно, что же такое жизненный цикл программного обеспечения
- ряд событий, происходящих с системой в процессе ее создания и дальнейшего использования. Говоря другими словами, это время от начального момента создания какого либо программного продукта, до конца его разработки и внедрения. Жизненный цикл программного обеспечения можно представить в виде моделей.
Модель жизненного цикла программного обеспечения
- структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.
Эти модели можно разделить на 3 основных группы:
- Инженерный подход
- С учетом специфики задачи
- Современные технологии быстрой разработки
Модель кодирования и устранения ошибок
Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.Данная модель имеет следующий алгоритм:
- Постановка задачи
- Выполнение
- Проверка результата
- При необходимости переход к первому пункту
Каскадная модель жизненного цикла программного обеспечения (водопад)
Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.Преимущества:
- Последовательное выполнение этапов проекта в строгом фиксированном порядке
- Позволяет оценивать качество продукта на каждом этапе
- Отсутствие обратных связей между этапами
- Не соответствует реальным условиям разработки программного продукта
Каскадная модель с промежуточным контролем (водоворот)
Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку . Относится к первой группе моделей.V модель (разработка через тестирование)
Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.
Модель на основе разработки прототипа
Данная модель основывается на разработки прототипов и прототипирования продукта.Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:
- Прояснить не ясные требования (прототип UI)
- Выбрать одно из ряда концептуальных решений (реализация сцинариев)
- Проанализировать осуществимость проекта
- Горизонтальные и вертикальные
- Одноразовые и эволюционные
- бумажные и раскадровки
Вертикальные прототипы - проверка архитектурных решений.
Одноразовые прототипы - для быстрой разработки.
Эволюционные прототипы - первое приближение эволюционной системы.
Модель принадлежит второй группе.
Спиральная модель жизненного цикла программного обеспечения
Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.
Преимущества:
- Быстрое получение результата
- Повышение конкурентоспособности
- Изменяющиеся требования - не проблема
- Отсутствие регламентации стадий
Большое спасибо за внимание!
Жизненный цикл программного обеспечения
Одним из базовых понятий методологии проектирования ПО является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ним документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:
· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
· вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Модели жизненного цикла ПО
Модель жизненного цикла - структура, определяющая последовательность выполнения и взаимосвязи стадий и этапов, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ПО и специфики условий, в которых последняя создается и функционирует. Основные модели ЖЦ следующие.
1. Каскадная модель (до 70-х годов XX в) определяет последовательный переход на следующий этап после завершения предыдущего.
Для этой модели характерна автоматизация отдельных несвязанных задач, не требующая информационной интеграции и совместимости, программного, технического и организационного сопряжения.
Достоинство : хорошие показатели по срокам разработки и надежности при решении отдельных задач.
Недостаток : неприменимость к большим и сложным проектам из-за изменчивости требований к системе в течение длительного проектирования.
2. Итерационная модель (70-80-е годы XX в.) соответствует технологии проектирования «снизу - вверх». Допускает итерационные возвраты на предыдущие этапы после выполнения очередного этапа;
Модель предусматривает обобщение полученных проектных решений отдельных задач в общесистемные решения. При этом возникает потребность в пересмотре ранее сформулированных требований.
Достоинство: возможность оперативно вносить коррективы в проект.
Недостаток: при большом числе итераций растет время проектирования, возникают расхождения в проектных решениях и документации, запутывается функциональная и системная архитектура созданной ПО. Необходимость в перепроектировании старой или создании новой системы может возникнуть сразу после этапа внедрения или эксплуатации.
3. Спиральная модель (80-90-е годы XX в.) соответствует технологии проектирования «сверху - вниз». Предполагает использование программного прототипа, допускающего программное расширение. Проект системы циклически повторяет путь от детализации требований к детализации программного кода.
При проектировании архитектуры системы сначала определяется состав функциональных подсистем и решаются общесистемные вопросы (организация интегрированной базы данных, технология сбора, передачи и накопления информации). Затем формулируются отдельные задачи и разрабатывается технология их решения.
При программировании сначала разрабатываются головные программные модули, а затем - модули, исполняющие отдельные функции. Сначала обеспечивается взаимодействие модулей между собой и с базой данных, а затем - реализация алгоритмов.
Достоинства:
1. сокращение число итераций и, следовательно, число ошибок и несоответствий, которые необходимо исправлять;
2. сокращение сроков проектирования;
3. упрощение создания проектной документации.
Недостаток: высокие требования к качеству общесистемного репозитория (общей базы проектных данных).
Спиральная модель лежит в основе технологии быстрой разработки приложений или RAD-технологии (rapid application development), которая предполагает активное участие конечных пользователей будущей системы в процессе ее создания. Основные стадии информационного инжиниринга следующие:
· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области.
· Проектирование. Пользователи под руководством разработчиков принимают участие в техническом проектировании.
· Конструирование. Разработчики проектируют рабочую версию ПО с использованием языков 4-го поколения;
· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.
Жизненный цикл программы.
Жизненный цикл программного обеспечения (ПО) - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл - процесс построения и развития ПО.
Этапы жизненного цикла :
2. Проектирование
3. Реализация
4. Сборка, тестирование, испытание
5. Внедрение (выпуск)
6. Сопровождение
Различают 2 случая производства ПО: 1) ПО делается для конкретного заказчика. В этом случае нужно прикладную задачу преврашать в программистскую. Нужно понять как функционирует та среда, которую нужно автоматизировать (анализ бизнес-процессов). В результате появляется документация-спецификация требования, где указаны какие именно задачи д.б. решены и при каких условиях. Эту работу выполняет системный аналитик (аналитик бизнес-процессов).
2) ПО разрабатывается для рынка. Нужно проводить маркетинговые исследования и найти какого продукта на рынке нет. Это связано с большим риском. Цель – разработка спецификации требований.
Проектирование
Цель – определение общей структуры (архитектуры) ПО. Результат – спецификация ПО. Эту работу выполняет системный программист.
Реализация
Написание программного кода. Реализация включает и разработку, и тестирование, и документацию.
Сборка, тестирование, испытние
Сборка всего, что сделано разными программистами. Тестирование всего программного комплекса. Отладка – поиск и устранение причин ошибок. Испытание – уточнение технических характеристик. В результате – гарантия работоспособносит программы.
Внедрение (выпуск)
Внедрение – когда работают на одного заказчика. Включает постановку программы у заказчика, обучение заказчика, консультации, устранение ошибок и явных недостатков. Должно произойти отчуждение ПО – пользователь может работать с ПО без участия автора.
Выпуск – когда ПО разрабатывается на рынок. Начинается с этапа бета-тестирования. Соотв. версия – бета-версияю. Альфа-тестирование – тестирование людьми из той же организации, не участвовавших в разработке программ. Бета-тестирование – изготовление нескольких экземпляров ПО и отправка потенциальным заказчикам. Цель – еще раз проверить разработку ПО.
Если на рынок выпускается принципиально новый ПО, то возможно несколько бета-тестирований. После бета-тестирование – выпуск коммерческой версии.
Сопровождение
Устранение замеченных в ходе эксплуатации ошибок. Внесение непринципиальных усовершенствований. Накопление предложений для разработки следующей версии.
Модели жизненного цикла
1. Waterfall («водопад», каскадная модель)
2. Прототипирование
Сначала разрабатывается не сам программный продукт, а его прототип, содержащий решение главных проблем, стоящих перед разработчиками. После успешного завершения разработки прототипа по тем же принципам разрабатывается и настоящий программный продукт. Прототип позволяет лучше понимать требования к разрабатываемой программе. Используя прототип заказчик также может точнее сформулировать свои требования. Разработчик имеет возможность с помощью прототипа предъявить заказчику предварительные результаты своей работы.
3. Итерационная модель
Задача разделяется на подзадачи и определяется очередность их реализации т.о., чтобы каждая следующая подзадачи расширяла возможности ПО. Успех существенно зависит от того сколь удачно разделены задачи на подзадачи и как выбрана очередность. Преимущества: 1) возможность активного участия заказчика в разработке, он имеет возможность уточнить свои требования в ходе разработки; 2) возможность тестирования вновь разрабатываемых частей совместно с ранее разработанными, это уменьшит затраты на комплексную отладку; 3) во время разработки можно начинать внедрение по частям.
Жизненный цикл – это модель создания и использования программной системы. Он отражает различные состояния программной системы, начиная с момента возникновения необходимости в этой программной системе и принятия решения о ее создании и заканчивая полным изъятием программной системы из эксплуатации.
Международный стандарт ISOIES 12207 регламентирует структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания программного обеспечения. По этому стандарту жизненный цикл программного обеспечения базируется на трех группах процессов:
основные процессы жизненного цикла, то есть приобретение, поставка, разработка, эксплуатация и сопровождение;
вспомогательные процессы, обеспечивающие выполнение основных процессов, то есть документирование, верификация, аттестация, оценка качества и другие;
организационные процессы, то есть управление проектами, создание инфраструктуры проекта и обучение.
Разработка включает в себя все работы по созданию программного обеспечения в соответствии с заданными требованиями. Сюда включаются оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности и качества программных продуктов.
Основные этапы процесса разработки:
анализ требований заказчика;
проектирование;
реализация (программирование).
Процесс эксплуатации включает в себя работы по внедрению программного обеспечения в эксплуатацию, в том числе конфигурирование рабочих мест, обучение персонала, локализация проблем эксплуатации и устранение причин их возникновения, модификация программного обеспечения в рамках установленного регламента и подготовка предложений по модернизации системы.
Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными и результатами.
Жизненный цикл программного обеспечения носит, как правило, итерационный характер, то есть реализуются этапы, начиная с самых ранних, которые циклически повторяются в соответствии с изменением требований внешних условий и введением ограничений.
Модели жизненного цикла программного обеспечения
Существует несколько моделей жизненного цикла, которые определяют порядок исполнения этапов разработки и критерии перехода от этапа к этапу. К настоящему времени наибольшее распространение получили две модели жизненного цикла: каскадная и спиральная .
В существующих ранее однородных информационных системах каждое приложение представляло собой единое целое. Для разработки таких приложений применялась каскадная модель жизненного цикла, которую также называют классической или водопадной .
При использовании каскадной модели разработка рассматривалась как последовательность этапов, причем переход на следующий более низкий этап происходит только после того, как полностью завершены все работы на текущем этапе. Подразумевается, что в каскадной модели разработка начинается на системном уровне и происходит через анализ, проектирование, кодирование, тестирование и сопровождение.
Рисунок 1– Основные этапы разработки каскадной модели
1. Системный анализ задает роль каждого элемента в компьютерной системе и взаимодействие элементов друг с другом. Поскольку программное обеспечение рассматривается как часть большой системы, то анализ начинается с определения требований по всем системным элементам. Необходимость системного анализа явно проявляется, когда формируется интерфейс программного обеспечения с другими элементами, т.е. с аппаратурой или базами данных. На этом же этапе начинается решение задач планирования проекта. В ходе планирования проекта определяется объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к отдельному программному элементу. На этом этапе уточняются и детализируются функции каждого элемента, его характеристики и интерфейс. На этом же этапе завершается решение задачи планирования проекта.
2. Проектирование состоит в создании:
архитектуры программного обеспечения;
модульной структуры программного обеспечения;
алгоритмической структуры программного обеспечения;
структуры данных;
входного/выходного интерфейса (входных/выходных форм данных).
При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
3. Кодирование или разработка состоит в переводе результатов проектирования в код программы.
4. Тестирование – это выполнение программы на выявление дефектов в функциях, логике и форме реализации программного продукта.
5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:
исправления ошибок;
адаптации к изменениям внешней для программного обеспечения среды;
усовершенствование программного обеспечения в соответствии с требованиями заказчика.
Достоинства применения каскадной модели:
дает план и временной график по всем этапам проекта, упорядочивая, таким образом, ход разработки;
на каждом этапе формируется законченный набор проектной документации, проверенный на полноту и согласованность;
выполняемые в логической последовательности этапы работы позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадная модель хорошо себя зарекомендовала при построении информационных систем, для которых в самом начале разработки можно достаточно точно сформулировать все требования в системе, например, сложные расчетные системы, различные системы реального времени и т.д.
Недостатки каскадной модели:
реальные проекты часто требуют отклонений от стандартной последовательности шагов;
каскадная модель основана на точной формулировке исходных требований к программному обеспечению, однако реально в ряде случаев в начале проекта требования заказчика определены только частично;
результаты реализации проекта доступны заказчику только после завершения всех работ.
Из-за необходимости в процессе создания программного обеспечения постоянного возврата к предыдущим этапам и уточнения или пересмотра ранее принятых решений реальный процесс разработки программного обеспечения на основе каскадной модели может быть представлен следующей схемой (рис.2).
Рисунок 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).
Выход системы на проектную мощность в хорошем варианте - это доводка мелких ошибок и редкие серьезные ошибки.
Эксплуатация и техническая поддержка
На этом этапе последним документом для разработчиков является акт технической приемки. Документ определяет необходимый персонал и требуемое оборудование для поддержки работоспособности системы, а также условия нарушения эксплуатации продукта и ответственность сторон. Помимо этого обычно в виде отдельного документа оформляются условия технической поддержки.