ППС (9) - Лекция №2 - Проектирование больших систем - Определение требований: различия между версиями
Перейти к навигации
Перейти к поиску
ILobster (обсуждение | вклад) (Новая страница: «== Стадии проектирования программных систем == На формирование требований может уходить д...») |
ILobster (обсуждение | вклад) |
||
Строка 5: | Строка 5: | ||
Теоретический процесс разработки: | Теоретический процесс разработки: | ||
[[Файл:9sPPSl2pic1.png]] | [[Файл:9sPPSl2pic1.png|link=Файл:9sPPSl2pic1.svg]] | ||
Реальный процесс разработки: | Реальный процесс разработки: | ||
[[Файл:9sPPSl2pic2.png]] | [[Файл:9sPPSl2pic2.png|link=Файл:9sPPSl2pic2.svg]] | ||
Потому что постоянно приходится возвращаться на предыдущие этапы и вносить изменения. | Потому что постоянно приходится возвращаться на предыдущие этапы и вносить изменения. |
Версия от 09:27, 12 сентября 2012
Стадии проектирования программных систем
На формирование требований может уходить до 60% всего времени разработки.
Теоретический процесс разработки:
Реальный процесс разработки:
Потому что постоянно приходится возвращаться на предыдущие этапы и вносить изменения.
Основные принципы проектирования больших программных систем
- этап проектирования не прекращается никогда, потому что постоянно требуется вносить изменения.
- уточнение требований продолжается в течение всего времени проектирования.
- программная система наследует проблемы реальной системы.
Определение требований
Эта работа выполняется совместно разработчиком и заказчиком.
Постановка задачи
- нужно понять, что нужно сделать.
- требования формулируются совместно с заказчиком и проектировщиком с максимально возможной строгостью.
- нельзя ориентироваться на требования одного, но влиятельного лица. Потому что в этом случае система обрекается на недолговечность. Должен быть найден и вовлечён в дело действительный пользователь, а не его заменитель.
- разные пользователи предъявляют противоречивые требования.
- представитель заказчика должен иметь полномочия принимать решения.