3. Основные характерные особенности больших программных систем

Большие программные системы – это промышленные программные продукты. Для них характерно следующее:

• различные области применения;

• сложность логической организации;

• большой объём кода;

• множество пользователей;

• долгосрочное использование;

• требуется модернизация и сопровождение;

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

• разрабатываются коллективом программистов;

• требуются значительные финансовые ресурсы.

4. Определение требований к проектируемому программному обеспечению. Управление требованиями.

Эта работа выполняется совместно разработчиком и заказчиком.

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

• нужно понять, что нужно сделать.

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

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

• разные пользователи предъявляют противоречивые требования.

• представитель заказчика должен иметь полномочия принимать решения.

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

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

• предусмотреть изменения в проекте;

• заказчики и разработчики одни и те же требования понимают по-разному;

• требованиями надо управлять;

• за выработку требований должен отвечать один и тот же человек.

	Может сделать	Пропустит
ЗАКАЗЧИК	Ясно выразить важные потребности Правильно расставить приоритеты	Требования к технологии Потребности инфраструктуры
ПРОЕКТИРОВЩИК	Определить состояние дел в технологии Определить полноту требований	Сортировку интересов пользователей Тонкости прикладной области

5. Документирование процесса проектирования. Назначение документирования. Требование к документированию.

Самая трудная задача - организовать ведение документации.

Если отсутствует документация, доступная для всех, то проект обречён на неудачу.

Дональд Дуглас: "Когда вес документов достигает веса самолёта, самолёт начинает летать".

Основные принципы:

• документация создаётся на всех уровнях проектирования;

• должны использоваться методы документирования (HIPO, SADT, IA, UML).

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

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

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

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

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

6. Использование декомпозиции при проектировании больших программных систем. Декомпозиция при алгоритмическом подходе. Декомпозиция при объектно-ориентированном подходе.

Декомпозиция – это разложение на более мелкие составные части.

Алгоритмическая декомпозиция:

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

• Нисходящее проектирование - этот алгоритм предпочтителен, когда в самом начале мы не проектируем модули, а проектируем управляющий алгоритм.

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

• Комбинированное проектирование - сочетание нисходящего и восходящего.

Объектная декомпозиция: