Книга: Программное обеспечение и его разработка
Кто является действительным пользователем в любом проекте?
Кто является действительным пользователем в любом проекте?
Очень часто разработка систем ведется научно-исследовательскими отделами какой-нибудь организации. В их задачу входит и выяснение того, что необходимо потенциальным пользователям.
Когда в начале 1970-х гг. мы успешно завершили первую рабочую версию новой системы управления воздушными перевозками, мы испытали чувство огромного удовлетворения. Группа определения требований FAA подписала свидетельство о завершении работ. Это была настоящая волокита.
Система была отправлена в Джексонвилл, шт. Флорида, для испытаний в рабочих условиях в ночную смену в Центре управления авиаперевозками. Однако диспетчеры из Джексонвилла отказались пользоваться ею — они заявили, что она «ненадежна».
«Ненадежность» диспетчерской авиаслужбы требует особого внимания. Нам удалось решить проблему исключением из состава системы значительной доли функций, которые ранее были туда включены. Следующий вариант программы, поставленный в Джексонвилле, содержал гораздо меньше системных возможностей. И диспетчерам он понравился. А потом постепенно, очень медленно мы стали добавлять функции, уже запрограммированные и оттестированные нами ранее.
Это служит подтверждением истории, которую я слышал в Хьюстоне. Если вам предложат пуд мороженого, трудно ожидать, что вы сможете проглотить его за один прием. Это не получится.
Такая методика обходится значительно дороже! Последовательное введение функций в действие занимает больше времени. Но у нас нет выбора.
Это другая причина, по которой необходимо отдавать предпочтение эволюционному подходу к разработке систем. Пользователи не могут переварить сразу все функциональные возможности, даже если разработчики и в состоянии их предоставить.
Полученный урок пошел нам впрок. Для дальнейшей работы FAA прикрепило профессиональных диспетчеров к группе определения требований. Несколько лет эти поистине бесценные специалисты делили свое время между основной работой и работами по проекту. Таким образом нам удалось добиться, что группа определения требований работала именно над тем, что было действительно необходимо реальным пользователям.
Чем более крупную систему создают разработчики, тем больше она подвержена опасности стать излишне сложной в использовании. Может получиться и так, что система будет решать давно решенную проблему.
Я принимал личное участие в создании двух крупных систем, на разработку которых были потрачены миллионы долларов и пользователь которых выбрасывал половину предложенных ему функций после того, как они были полностью разработаны. Операторы не могли с ними работать.
- Характеристики программ
- Процесс разработки программного обеспечения
- Полный цикл
- Использование
- «Большой взрыв» и эволюция
- Определение требований
- Требования системного уровня
- Изменения неизбежны
- Кто формулирует требования к программному обеспечению?
- Язык документирования требований
- Особая важность требований
- Кто является действительным пользователем в любом проекте?
- Противоречивые требования разных пользователей
- Требования к товарным программам и программному обеспечению проектов
- Изменения, вносимые пользователем
- Адаптируемость способствует непрекращающимся изменениям
- Определение требований — это длительный процесс
- Спецификация требований
- Определение требований к окружающей обстановке в фазе использования
- Управление процессом выработки требований
- Новые методы определения требований
- Личный опыт
- Резюме: требования к большим системам программного обеспечения
- Проектирование
- Что такое проектирование?
- Программное обеспечение — это подсистема
- Многократное и параллельное проектирование
- Параллельная разработка
- Итерации при проектировании и выработке требований
- Проектирование программного обеспечения фазы использования
- Кто должен вести проектирование
- Конечная продукция — что же мы создаем?
- Составные части и процесс проектирования
- Структура
- Описание
- Последовательный ход процесса проектирования программной системы
- Уровни проектирования
- Проектирование верхнего уровня
- Расслоение
- Выделение макрослоев
- Временные ограничения
- Проектирование среднего уровня
- Выделение микрослоев
- Проектирование модуля
- Упрятывание информации
- Проектирование нижнего уровня
- Межуровневые механизмы и уровень тривиальности
- Вариации уровня тривиальности и межуровневых механизмов
- Структурное программирование
- Введение в структурное программирование
- Преимущества структурного программирования
- Приемлемость структурного программирования
- Хорошее проектирование
- Проектирование это…
- Итеративность
- Компромиссы
- Проектирование больших программ типа V — это многогранная деятельность
- Деталировка — это примитивное проектирование
- Устойчивые программы, или программы, дружественные пользователю
- Документирование проекта
- Спецификация — это проектирование и одновременно выработка требований
- Новые методы проектирования
- Данные и процесс
- Структурное проектирование
- Трудности нововведений
- Написание программ — программирование
- Языки
- Мощность языка и связанные с ней трудности
- Рост числа языков
- Язык и мышление
- Ограничения, накладываемые языками
- Процесс написания программы
- Кросс-транслятор
- Множество форм одной программы
- Вычислительные машины для трансляции
- Программирование в диалоговом режиме
- С чем же мы ведем диалог?
- Управление написанием программ
- Различия уровня квалификации программистов
- Главный программист
- Библиотекарь
- Компоновка программ
- Сборка большого числа модулей в одну работающую систему программного обеспечения
- Следует ли проводить компоновку перед тестированием?
- Средства обслуживания руководства
- Автоматическое использование инструментальных средств
- Выбор трансляторов и языков
- Реализация сверху вниз
- Окружение разработки программного обеспечения
- Выводы
- Верификация и тестирование
- Верификация
- Раннее выявление «пробелов»
- Инспектирование
- Пример ошибки
- Тестирование и качество
- Надежное программное обеспечение — неверный термин
- Тестирование с возвратом
- Физическая сохранность
- Тестирование — средство обучения
- Независимость тестирующих групп
- Продолжительность развития
- Выводы
- Документирование
- Самодокументирование
- Структурированное словесное описание
- Документация для других целей
- Отслеживание связей
- Избыток документации
- Исключение блок-схем
- История проекта
- «Как» — это «что». Требование — это проект — уровни детализации
- Реальная ситуация
- Покупатель на крючке. Руководство по созданию продуктов, формирующих привычки
- Кто такой тест-менеджер
- Факторы выгоды
- Иерархия объектов в InterBase
- Что делать, если при установке принтера появляется сообщение Невозможно завершение операции. Подсистема печати недоступн...
- Кто сказал: «Яндекс»?
- При копировании с жесткого диска на «флэшку» иногда появляется сообщение о дополнительной присоединенной информации, кот...
- Жизненные циклы продуктов
- Имена объектов длиной 68 символов
- 2.5. Разработка технического задания на проведение детального анализа рынка при работе над инновационным проектом. Основ...
- Модули констукторов заданий
- Факторы помощи