Письменные лекции по дисциплине «Разработка и анализ требований»
Лекция 1. Основы работы с требованиями к по
1.1. Что такое требования
Требования — requirements.
Это свойства ПО, приносящие пользу клиенту.
Это свойство ПО, позволяющее удовлетворить требования контракта, стандарта, спецификации или иной формальной документации.
Это свойства ПО, определяющие его взаимодействие со своим окружением.
Это характеристики ПО, отличающие его от аналогов.
1.2. Классификация программного обеспечения
По назначению:
— Системное ПО.
— Прикладное ПО.
— Инструментальное ПО.
— Встроенное ПО — содержимое энергонезависимой памяти любого цифрового вычислительного устройства (Ольга Петровна выделяет это как отдельный вид ПО, так как имеет свои специфические свойства).
Если брать с точки зрения рынка, то различаются подходы разработки ПО:
— Внешний клиент (продукт на заказ). Требования полностью определяет клиент, который заказывает.
— Компания-разработчик ПО (для открытого рынка). Разрабатывает компания для рынка, важен аналог конкурентов, так как если конкурент разработает лучше ПО, то компания понесет убытки.
— Компания, автоматизирующая свои производственные процессы своими же силами. Для собственных нужд, разрабатывается практически так же, как продукт на заказ.
1.3. Разработка требований в модели жизненного цикла по
Водопадная модель по Уинстону Ройсу
Эта модель обязана своим появлением У. Ройсу (1970 г.). Модель имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии; возвратов на пройденные стадии не предусматривается.
Требования к разрабатываемой ПС, определенные на стадиях формирования и анализа, строго документируются в виде ТЗ и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации (ТЗ, ЭП, ТП, РП), достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций ТЗ. Основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемой ПС – производительности, объема занимаемой памяти и др.
Преимущества каскадной модели:
— на каждой стадии формируется законченный набор проектной документации, отвечающей критериям полноты и согласованности;
— выполняемые в логической последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ПС, для которых в самом начале проекта можно полно и четко сформулировать все требования. Пока все это контролируется стандартами и различными комиссиями госприемки, схема работает хорошо.
Недостатки каскадной модели:
— выявление и устранение ошибок производится только на стадии тестирования, которое может существенно растянуться;
— реальные проекты часто требуют отклонения от стандартной последовательности шагов;
— цикл основан на точной формулировке исходных требований к ПС, реально в начале проекта требования заказчика определены лишь частично;
— результаты работ доступны заказчику только по завершении проекта.
Место требований в водопадной модели ЖЦ. Современная водопадная модель, в которой создание концепции вынесено на первое место. Сбор и анализ требований происходит только после того, как определены основные цели и задачи ПП.
Место требований в спиральной модели ЖЦ. Тут снова создание концепции на первом месте, а затем идут итерации, один этап заменяет другой. Основная идея спиральной модели заключается в том, что на этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путём создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы, в процессе анализа которых проводится конкретизация деталей проекта. В результате выбирается обоснованный вариант, который действительно удовлетворяет требованиям заказчика.
Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы за счёт частичной реализации функциональности программного продукта. Тем самым активизируется процесс уточнения и дополнения требований со стороны пользователей системы.
