Главная » UML » "Разумный" подход

0

Многие технологические проблемы решаются с использованием последовательного процесса, имеющего следующие пять стадий.

1.          Полное понимание проблемы, подлежащей решению, ее требований и ограни
чений. Все.это фиксируется в письменном виде и передается всем заинтересо
ванным сторонам для подтверждения корректности формулировки поставлен
ной задачи.

2.          Выработка решения, удовлетворяющего всем требованиям и ограничениям.
Это решение тщательно исследуется, а все заинтересованные стороны под
тверждают то, что данное решение является верным.

3.    Реализация решения с использованием лучших технологических методов.

4.    Проверка, удовлетворяет ли реализация сформулированным требованиям.

5.    Сдача проекта. Задача решена!

Так строятся небоскребы и мосты. Это — разумный подход к работе, но, к сожалению, он применим только тогда, когда область проблемы относительно хорошо изучена и инженеры могут использовать опыт сотен лет экспериментирования в области проектирования и строительства.

 

Область же программирования является сравнительно молодой. На ее исследование у специалистов по программному обеспечению было всего лишь несколько десятилетий. Разработчики программного обеспечения работали весьма напряженно, особенно в семидесятых и восьмидесятых, чтобы скопить экспериментальные результаты в области проектирования и построения программного обеспечения. В 1980 году автор поклялся, что последовательный процесс является одним-единственным разумным подходом.

Итак, если последовательный процесс является таким идеальным, то почему же проекты, в которых он используется, не являются более успешными? Причин этому множество.

•       Делаются ложные предположения.

•       Среда разработки программного обеспечения несколько отличается от других
технологических дисциплин.

•       Не удалось ввести некоторые человеческие факторы.

•       Процесс, зарекомендовавший себя в некоторых хорошо определенных обсто
ятельствах, попытались расширить на то, что он был не способен охватить.

•        

•    Технологии программного обеспечения все еще находятся в стадии исследо
вания. Отсутствует опыт сотен лет проб и ошибок, сделавший то же построе
ние моста механическим процессом. Данную причину вполне можно считать
основной.

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

Ложное предположение 1: требования неизменны

Отметим, что в описании первой стадии последовательного процесса предполагалось, что проблему изначально можно очертить во всей ее полноте. Предполагалось, что все требования можно точно и однозначно выразить в письменном виде и начать процесс, имея прочный фундамент. Стоит отметить, что несмотря на все усилия это практически невозможно. Требования будут меняться, и этот факт приходится признать. Если решаемая проблема не является тривиальной, то будут появляться новые требования. Почему это происходит? Назовем несколько причин.

•     Изменения в пользовательской среде

Пользовательские требования не поддаются фиксации во времени. Особенно это справедливо в том случае, если время разработки измеряется не неделями или месяцами, а годами. Пользователи обнаруживают новые системы и другие продукты, и им хочется, чтобы разрабатываемый продукт перенял некоторые их свойства. Кроме того, развивается их собственная рабочая среда, и пользователи становятся образованнее.

•     Изменения задачи

После реализации или в процессе реализации система сама влияет на то, какой ее видят пользователи. Испробовать некоторое свойство или увидеть его демонстрацию — это совсем не то, что прочитать о нем. Как только конечные пользователи увидят, как их замысел воплощается в системе, требования начнут меняться. Фактически пользователи точно понимают, что они хотели, не за два года до реализации системы, а через несколько недель или месяцев после сдачи проекта, когда исходная фаза обучения уже завершена. Такой эффект иногда называется "Узнаю, когда увижу" .

Пользователи не могут сказать определенно, чего они хотят, но они знают, чего они не хотят (точнее, узнают, когда увидят). Следовательно, работа по подробному описанию, сбору и фиксации требований может в конечном счете привести к сдаче системы, которая по отношению к требованиям является идеальной, но в то же время не соответствует текущему состоянию поставленной проблемы.

; Авторство высказывания "I’ll Know It When I See It" иногда приписывается американскому судье Стюарт)7 Поттеру (Stewart Potter); достоверно известным случаем использования акронима IKIWISI является семинар по архитектуре систем программного обеспечения, прочитанный Барри Боемом (Barry Boehm) в University of Southern California в 1997 году.

 

 

•     Изменения основоположных технологий

Возникает новое программное или аппаратное обеспечение, новые продукты, и может появиться желание воспользоваться ими. Если проект разрабатывается несколько лет, то аппаратная платформа, предполагаемая в начале проекта, к моменту его сдачи может уже просто не выпускаться.

•     Изменения рынка

Конкуренция может выдвигать на рынок новые продукты. Зачем разрабатывать продукт, великолепно отвечающий исходной спецификации, но являющийся безнадежно устаревшим на момент сдачи?

•     Требования нельзя сформулировать достаточно точно и подробно

Решение этой проблемы обещают формальные методы, но в промышленности начала третьего тысячелетия они не получили широкого распространения, причем особенно это относится к небольшим, узкоспециализированным отраслям. Эти методы трудно применять на практике; кроме того, они крайне недоброжелательны к пользователю. Попробуйте объяснить временную логику или цветные сети Петри аудитории, состоящей из банковских служащих и заведующих отделением, причем так, чтобы они смогли прочесть и одобрить спецификацию их новой системы.

Ложное предположение 2: до начала работы правильный проект можно получить на бумаге

На второй стадии последовательного процесса предполагается, что можно доказать, что созданный проект является верным решением поставленной задачи. Под "верным" подразумевается соответствие всем показателям качества: правильности, эффективности, реализуемости и т. д. При полном отслеживании требований, наличии методов формального вывода, автоматизированного доказательства, генерирующих технологий и моделировании проекта можно добиться удовлетворения некоторых из этих показателей. В то же время не все эти технологии свободно доступны исполнителям, большинство требует наличия формального описания проблемы. Можно скапливать тонны документации и сотни чертежей, проводить недели за рецензированием, и все это только для того, чтобы позднее в процессе обнаружить, что проект имеет существенные дефекты, приводящие к серьезным авариям.

Технология программного обеспечения еще не достигла уровня других инженерных дисциплин (а, возможно, и никогда не достигнет), поскольку "теории", лежащие в основе этой отрасли, слабы и плохо понимаемы, а эвристические методы довольно грубы. Можно сказать, что для технологии программного обеспечения было подобрано неверное название. На разных этапах своего развития она больше походила на раздел психологии, философии или область искусства, чем на технологическую дисциплину. В проектировании моста заложены относительно простые законы физики, но при проектировании программного обеспечения таких строгих эквивалентов нет. В этом отношении "слабое" программное обеспечение (в противоположность "жесткому", аппаратному) является действительно слабым.

 

По теме:

  • Комментарии