Предпосылки создания SADT

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

• анализ - определение того, что система будет делать,
• проектирование - определение подсистем и их взаимодействие,
• реализация - разработка подсистем по отдельности, объединение - соединение подсистем в единое целое,
• тестирование - проверка работы системы,
• установка - введение системы в действие,
• функционирование - использование системы.

Эта последовательность всегда выполнялась итерационно, потому что система полностью никогда не удовлетворяла требованиям пользователей, поскольку их требования часто менялись. И, тем не менее, с этой моделью создания системы, ориентированной на управление, постоянно возникали сложности. Эксплуатационные расходы, возникавшие после сдачи системы, стали существенно превышать расходы на ее создание и продолжали расти с огромной скоростью из-за низкого качества исходно созданной системы. Некоторые считали, что рост эксплуатационных расходов обусловлен характером ошибок, допущенных в процессе создания системы. Исследования показали, что большой процент ошибок в системе возник в процессе анализа и проектирования, гораздо меньше их было допущено при реализации и тестировании, а цена (временная и денежная) обнаружения и исправления ошибок становилась выше на более поздних стадиях проекта. Например, исправление ошибки на стадии проектирования стоит в 2 раза, на стадии тестирования - в 10 раз, а на стадии эксплуатации системы - в 100 раз дороже, чем на стадии анализа. На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление - примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях. Кроме того, ошибки анализа и проектирования обнаруживались часто самими пользователями, что вызывало их недовольство.

Традиционные подходы к созданию систем приводили к возникновению многих проблем. Не было единого подхода. Привлечение пользователя к процессу разработки не контролировалось. Проверка на согласованность проводилась нерегулярно или вообще отсутствовала. Результаты одного этапа не согласовывались с результатами других. Процесс с трудом поддавался оценкам, как качественным, так и количественным. Утверждалось, что когда создатели систем пользуются методологиями типа структурного программирования и проектирования сверху вниз, они решают либо не поставленные задачи, либо плохо поставленные, либо хорошо поставленные, но неправильно понятые задачи. Кроме того, ошибки в создании систем становились все менее доступны выявлению с помощью аппаратных средств или программного обеспечения, а наиболее катастрофические ошибки допускались на ранних этапах создания системы. Часто эти ошибки были следствием неполноты функциональных спецификаций или несогласованности между спецификациями и результатами проектирования. Проектировщики знали, что сложность систем возрастает и что определены они часто весьма слабо. Рост объема и сложности систем является жизненной реалией. Эту предпосылку нужно было принять как неизбежную. Но ошибочное определение системы не является неизбежным: оно - результат неадекватности методов создания систем. Вскоре был выдвинут тезис: совершенствование методов анализа есть ключ к созданию систем, эффективных по стоимости, производительности и надежности. Для решения ключевых проблем традиционного создания систем широкого профиля требовались новые методы, специально предназначенные для использования на ранних стадиях процесса. Применение SADT проистекало из этого убеждения. Методы, подобные SADT, на начальных этапах создания системы позволяли гораздо лучше понять рассматриваемую проблему. А это сокращает затраты как на создание, так и на эксплуатацию системы, а кроме того, повышает ее надежность. SADT - это способ уменьшить количество дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшения контактов между пользователями и разработчиками и сглаживания перехода от анализа к проектированию.

Дуглас Т. Росс часть своих PLEX-теорий относящихся к методологии и языку описания систем, назвал "Методология структурного анализа и проектирования" (SADT). Исходная работа над SADT началась в 1969 г. Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, когда она была несколько пересмотрена сотрудниками SofTech, Inc. В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний. Появление SADT на рынке произошло в 1975 г. после годичного оформления в виде продукта. К 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей и охватывавшими дюжину проблемных областей, в том числе телефонные сети, аэрокосмическое производство, управление и контроль, учет материально-технических ресурсов и обработку данных. Ее широкое распространение в настоящее время в европейской, дальневосточной и американской аэрокосмической промышленности (под названием IDEF0) позволяет эти цифры существенно увеличить. Таким образом, SADT выделяется среди современных методологий описания систем благодаря своему широкому применению. Почему SADT имеет такое широкое применение? Во-первых, SADT является единственной методологией, легко отражающей такие системные характеристики, как управление, обратная связь и исполнители. Это объясняется тем, что SADT изначально возникла на базе проектирования систем более общего вида в отличие от других структурных методов, "выросших" из проектирования программного обеспечения. Во-вторых, SADT в дополнение к существовавшим в то время концепциям и стандартам для создания систем имела развитые процедуры поддержки коллективной работы и обладала преимуществом, связанным с ее применением на ранних стадиях создания системы. Кроме того, широкое использование SADT показало, что ее можно сочетать с другими структурными методами. Это достигается использованием графических SADT-описаний в качестве схем, связывающих воедино различные методы, примененные для описания определенных частей системы с различным уровнем детализации. Таким образом, неадекватные спецификации систем того времени вызвали создание графического языка SADT, а его усиленное использование преобразовало SADT в законченную методологию, способную повысить качество продуктов, создаваемых на ранних стадиях развития проекта. Итак, SADT началась как язык описания функционирования систем общего вида, а по мере применения ее процедуры описания систем были улучшены и дополнены. В первых главах этой книги обсуждаются концепции описания систем, лежащие в основе SADT, ее графический язык и процедуры описания систем. В последующих главах мы как бы заглядываем через плечо человека, использующего SADT, чтобы увидеть, как с помощью этой методологии можно описать систему, и как из этого описания получаются спецификации.