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

Стадии жизненного цикла

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

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

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

2. проектирование системы;

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

4. интеграция и внедрение;

5. процесс функционирования и сопровождения.

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

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

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

Имеется много методов и технологий выявления требований. Они включают

● интервьюирование пользователей и экспертов в предметной области;

● анкетные опросы пользователей;

● наблюдение, как пользователи выполняют свои задачи;

● изучение существующих документов системы;

● изучение подобных систем ПО, чтобы выяснить состояние в предметной области;

● изучение опытных образцов рабочих моделей для определения и подтверждения требований;

● объединенные совещания разработчиков и клиентов по разработке приложения.

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

И графические представления, и текст размещаются в хранилище специального CASE-средства (computer assisted software engineering — автоматизированная программная инженерия). Данное средство облегчает изменения в моделях, если это потребуется. Оно позволяет интегрировать различные модели с перекрывающимися концепциями. CASE-средство позволяет также выполнять преобразования между моделями анализа (где это возможно) и помогает в преобразованиях моделей проектирования.

Анализ требований завершается созданием технического задания.

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

Сервисы системы (то, что система должна делать) часто делятся на функциональные требования и требования к данным.

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

Результат каждой стадии жизненного цикла должен быть утвержден и проверен. Профессиональный подход к тестированию требует внутри организации создания группы по гарантии качества ПО (SQA — software quality assurance). Коллектив этой группы состоит из профессиональных системных испытателей. Он работает достаточно независимо от разработчиков. Чтобы обеспечить целиком всю работу процесса, именно коллектив SQA-группы, а не разработчики, является ответственным за качество программного продукта (то есть SQA отвечает за все несоответствия и дефекты в ПО).

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

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

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

Дата добавления: 2014-01-05