Книга: Программное обеспечение и его разработка
Особая важность требований
Особая важность требований
Тот факт, что наша работа над программами начинается с установления требований, сильно отражается на всем дальнейшем ходе работ. Если этот процесс выполнен недостаточно аккуратно, недостаточно точно, недостаточно адекватно, то от этого пострадают все остальные части процесса разработки. Последующие усилия могут быть просто героическими, но нужная система уже не будет создана.
Персонал, работающий с созданной системой, будет трактовать ошибки, искажения и неоднозначности как правильные требования, понапрасну тратя усилия не только на то, чтобы их внедрить, но и на то, чтобы затем от них избавиться. Плохие требования подобны кривым зеркалам — они все искажают.
В августе 1977 г. министерство обороны США провело изучение основных автоматизированных систем. Большинство из них были системами связи. Это были системы:
1) TRI — ТАС;
2) LDMX/NAVCOMPARS и AMMC/SRT;
3) SATIN IV;
4) WMMCCS NORAD/COC;
5) WWMCCS ADP — LANTCOM;
6) Телекоммуникационный центр Пентагона;
7) WWMCCS ADP — CCTC;
8) Автоматизированный технологический контроль;
9) CUDIX/NAVMASC.
Изучение показало:
— Во всех системах требования были неустойчивыми и подвергались пересмотру; чем больше была система, тем большие изменения вносились в них.
— В большинстве систем отсутствовал формальный механизм отслеживания и управления процессом выработки требований.
— Некоторые разработчики даже не смогли осознать необходимость обоснования требований.
— В большинстве систем не было отбоя от «списков пожеланий».
Результаты исследования в точности соответствуют моему личному опыту деятельности в коммерческой сфере, охватывающей вычислительную технику.
Опытный строитель, работая на богатого заказчика, может столкнуться с большими затруднениями. У такого заказчика может оказаться «мания» внесения постоянных изменении в проект рабочего кабинета, гостиной, веранды и вообще всех комнат дома. Строитель может быть очень опытным специалистом, знающим, умелым, изобретательным и компетентным в своей области — и все же он не сможет закончить строительство дома в отведенный для этого срок и уложиться в смету. Да и более или менее приличный дом он не построит. Любые изменения, вносимые в какой-либо проект в середине работ, по окончании этих работ обычно выглядят неуместными.
Даже тому, кто остро ощущает их необходимость и вкладывает в свою работу всю душу, с трудом удается четко сформулировать требования. Напомним еще раз:
1) формулируйте требования с максимально возможной строгостью;
2) заранее планируйте изменчивость системы.
- Характеристики программ
- Процесс разработки программного обеспечения
- Полный цикл
- Использование
- «Большой взрыв» и эволюция
- Определение требований
- Требования системного уровня
- Изменения неизбежны
- Кто формулирует требования к программному обеспечению?
- Язык документирования требований
- Особая важность требований
- Кто является действительным пользователем в любом проекте?
- Противоречивые требования разных пользователей
- Требования к товарным программам и программному обеспечению проектов
- Изменения, вносимые пользователем
- Адаптируемость способствует непрекращающимся изменениям
- Определение требований — это длительный процесс
- Спецификация требований
- Определение требований к окружающей обстановке в фазе использования
- Управление процессом выработки требований
- Новые методы определения требований
- Личный опыт
- Резюме: требования к большим системам программного обеспечения
- Проектирование
- Что такое проектирование?
- Программное обеспечение — это подсистема
- Многократное и параллельное проектирование
- Параллельная разработка
- Итерации при проектировании и выработке требований
- Проектирование программного обеспечения фазы использования
- Кто должен вести проектирование
- Конечная продукция — что же мы создаем?
- Составные части и процесс проектирования
- Структура
- Описание
- Последовательный ход процесса проектирования программной системы
- Уровни проектирования
- Проектирование верхнего уровня
- Расслоение
- Выделение макрослоев
- Временные ограничения
- Проектирование среднего уровня
- Выделение микрослоев
- Проектирование модуля
- Упрятывание информации
- Проектирование нижнего уровня
- Межуровневые механизмы и уровень тривиальности
- Вариации уровня тривиальности и межуровневых механизмов
- Структурное программирование
- Введение в структурное программирование
- Преимущества структурного программирования
- Приемлемость структурного программирования
- Хорошее проектирование
- Проектирование это…
- Итеративность
- Компромиссы
- Проектирование больших программ типа V — это многогранная деятельность
- Деталировка — это примитивное проектирование
- Устойчивые программы, или программы, дружественные пользователю
- Документирование проекта
- Спецификация — это проектирование и одновременно выработка требований
- Новые методы проектирования
- Данные и процесс
- Структурное проектирование
- Трудности нововведений
- Написание программ — программирование
- Языки
- Мощность языка и связанные с ней трудности
- Рост числа языков
- Язык и мышление
- Ограничения, накладываемые языками
- Процесс написания программы
- Кросс-транслятор
- Множество форм одной программы
- Вычислительные машины для трансляции
- Программирование в диалоговом режиме
- С чем же мы ведем диалог?
- Управление написанием программ
- Различия уровня квалификации программистов
- Главный программист
- Библиотекарь
- Компоновка программ
- Сборка большого числа модулей в одну работающую систему программного обеспечения
- Следует ли проводить компоновку перед тестированием?
- Средства обслуживания руководства
- Автоматическое использование инструментальных средств
- Выбор трансляторов и языков
- Реализация сверху вниз
- Окружение разработки программного обеспечения
- Выводы
- Верификация и тестирование
- Верификация
- Раннее выявление «пробелов»
- Инспектирование
- Пример ошибки
- Тестирование и качество
- Надежное программное обеспечение — неверный термин
- Тестирование с возвратом
- Физическая сохранность
- Тестирование — средство обучения
- Независимость тестирующих групп
- Продолжительность развития
- Выводы
- Документирование
- Самодокументирование
- Структурированное словесное описание
- Документация для других целей
- Отслеживание связей
- Избыток документации
- Исключение блок-схем
- История проекта
- «Как» — это «что». Требование — это проект — уровни детализации
- Реальная ситуация
- Особая благодарность
- 2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ
- 12.6. АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА
- Введение Важность основ
- Важность создания уникального торгового предложения (УТП) Дэн Кеннеди
- Глава 8. Анализ требований
- Работа с полем «Важность» письма («Priority»)
- Планирование требований к инфраструктуре
- 7.1.2. Важность ведения документации при создании программ
- Пять требований к модульным структурам
- Соблюдение требований, предъявляемых другими классами, с помощью протоколов
- 12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ