ППС (9) - Лекция №3 - Проектирование больших систем - Проектирование

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

Чтобы показать проблемы данного этапа, приведём данные по 10 проектам 1977 года в США:

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

С тех пор и до наших дней эти данные не потеряли актуальности.

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

Об этом говорилось на предыдущей лекции.

Документирование

Чего следует придерживаться при создании документации:

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

Управление требованиями

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

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

	Может сделать	Пропустит
Заказчик	ясно выразить важные потребности правильно расставить приоритеты	требования к технологии потребности инфраструктуры
Проектировщик	определить состояние дел в технологии определить полноту требований	сортировку интересов пользователей тонкости прикладной области

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

Проектирование - это искусство:

• в большей степени связано с искусством;
• программа наследует все проблемы реальной системы;
• при проектировании даётся обоснование как ПО, так и ТС;
• проектирование - это итерационный процесс;
• проектированием может заниматься не каждый.