2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ
2.4. АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ (СИСТЕМНЫЙ АНАЛИЗ) И ФОРМУЛИРОВКА ЦЕЛЕЙ
Задача оптимизации разработки программ состоит в достижении целей при минимально возможной затрате ресурсов.
Системный анализ в отличие от предварительного системного исследования — это углубленное изучение информационных потребностей пользователей, которое будет положено в основу детального проектирования новой автоматизированной системы (АС).
Конечный продукт этого этапа — набор выполняемых функций, или функциональные требования, т. е. документированная постановка системных требований к новой АС. Когда речь идет о создании большой системы, этот документ представляет собой отчет о системном анализе, который осуществляется по этапам, показанным на рис. 2.1.
Первый этап системного анализа (анализ организационного окружения) связан с тем, что невозможно создать работоспособную информационную систему, если исследователи ничего не знают об особенностях функционирования организации, функции которой должна обслуживать автоматизированная система (АС) и элементом которой она является. Следует понимать особенности и тип деятельности, управленческую структуру, методы управления, связи подразделений, персонал, динамику информационного обмена между отдельными работниками и рабочими группами (формы документов и отчетов, сроки, количество экземпляров и т. п.).
Второй этап системного анализа (анализ существующих систем) обусловлен тем, что в организациях уже могут существовать какие-то АС с определенными ресурсами (информационными, программными, техническими, а также персоналом). Даже тогда, когда проводится полное обновление технической и программной баз, существующее информационное обеспечение отражает ядро главных потребностей, которые не только нельзя игнорировать в новой системе, а наоборот, стартуя от него, следует развить и расширить.
Следует тщательно изучать, какие задачи решают "старые" системы, какое оборудование и программное обеспечение они имеют, какой персонал работает в информационном отделе; существуют ли базы данных, какова их структура и какими методами формируются отчеты о результатах — все это — важнейшие вопросы.
Важно выяснить: применяется ли кодирование информации и какие уровни кодов при этом используются (местные, государственные, международные); существующий регламент обработки данных, кого и почему он не устраивает, бывают ли практические задержки данных и отчетов, причины задержки; есть ли документация на старую систему. Такой перечень целей следует иметь как памятку в личном дневнике исследователя системы.
Рис. 2.1. Этапы проведения системного анализа информационных систем
Второй этап системного анализа — это сложнейший и ответственный шаг в массу метаинформации, т. е. "данных о данных". Главными ориентирами в организации метаинформации являются объекты (документы, диаграммы, аналитические тексты и записки, экономические показатели, совокупности), а также процессы создания объектов, процессы их передачи, обработки, хранения.
Для выполнения третьего этапа системного анализа (анализ требований системы) исследователь должен иметь определенные знания типовых методов решения основных управленческих задач (учетных, аналитических, плановых, оперативных). Все перечисленное является составной частью специальных знаний системного аналитика. Поэтому системный аналитик должен проследить все ветви комплекса требований в беседах с конечными пользователями, а затем сделать аналитические системные выводы. Эти требования есть и поддерживаются существующей информационной системой, а это должно стать функциональным требованием к новой улучшенной системе.
Третий этап системного анализа — определение того, что должно быть в новой АС. Это методологический этап синтеза требований к новой системе, которые вытекают из первых двух шагов анализа, а также из специальных знаний и средств системных аналитиков. Специалисты по системному анализу знают, что одной из коварных ловушек в их работе является возможность спутать анализ существующей системы с тем, что должно быть. Поэтому второй и третий этапы системного анализа четко разделены. Об этом важно помнить для того, чтобы не ошибиться в оценках основы, на которой строится новая система. В системотехнической методологии анализ существующего отделяется от анализа черт будущего, чтобы не воспринять желаемое за действительное.
Четвертый, итоговый этап системного анализа (документирование требований к новой системе) должен обобщить имеющиеся аналитические материалы и создать документированное отображение функциональных требований к новой АС. Документ "Требования к системе", или "Функциональные требования", является основой дальнейшей работы специалистов информационного отдела для создания детального проекта новой системы, т. е. для создания спецификаций всех ее элементов, программ, инструкций.
Таким образом, этап системного анализа отвечает на вопрос, что должна иметь информационная система для удовлетворения требований пользователей, а этап системного проектирования отвечает на вопрос, как конкретно осуществить такую АС.
Во многих аспектах системный анализ является наиболее трудной частью процесса создания системы. Проблемы, с которыми сталкивается системный аналитик, взаимосвязаны, что является одной из главных причин сложности их решения:
1) аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;
2) заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что — нет;
3) аналитик сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;
4) спецификация системы из-за объема и технических терминов непонятна для заказчика;
5) в случае понятности спецификации для заказчика, она будет недостаточной для разработчиков, создающих систему.
Итак, на данном этапе эволюционного развития ситуация в области проектирования АС выглядит следующим образом:
• имеется субъект — потенциальный заказчик, испытывающий дискомфорт, для преодоления которого необходимо решить ряд проблем, и поэтому этот субъект является источником деятельности;
• имеется перечень потребностей, которые необходимо удовлетворить;
• известны прототипы программных средств с механизмами, которые в совокупности могли бы удовлетворить имеющиеся потребности, но эти механизмы не связаны в единое целое так, чтобы удовлетворить все имеющиеся потребности.
Теперь необходимо сформулировать цели и определить ограничения на реализацию программного продукта.
Формулировка целей — первый и важнейший этап процесса проектирования. Именно на этом этапе закладываются основы успеха в решении всей задачи. Ошибки в выборе и формулировке цели не могут быть скомпенсированы на последующих этапах. Причина проста — все, что проделывается на последующих этапах разработки, идет от поставленных целей. Следовательно, такие ошибки никакими методами на последующих этапах невозможно скомпенсировать.
Как правило, все ошибки начальных этапов, выявленные на последующих этапах, имеют следующие причины:
1) постановка недостижимой цели;
2) стремление разработчика и постановщика задачи упростить задачу;
3) неумение разработчика выделить из формулировки постановщика отдельно описание проблемы и постановку задачи;
4) не выявленные ограничения.
Ситуации, когда возможна конкуренция целей, должны обязательно выявляться; необходимо согласовать цели так, чтобы наилучшим образом в рамках возможностей, определяемых ограничениями, достигались цели каждого из возможных субъектов (заказчиков). Хорошие цели всегда являются компромиссом между желанием наилучшим образом удовлетворить потребности и ограничениями, накладываемыми реализацией и средствами.
Можно сформулировать последовательность рекомендаций (контрольных вопросов):
Рекомендация 1. Не доверяйте имеющимся формулировкам задачи; решение начинайте с нуля, с выделения субъекта, выявления причин его дискомфорта и потребностей. Дело в том, что зачастую формулировка, предлагаемая заказчиком, неудачна или вовсе неприемлема, так как описывает на самом деле неудовлетворенную потребность, выдавая ее за задачу.
Рекомендация 2. Уточните требования к конечному результату:
1) какие функции и с какими показателями качества должен выполнять функции объект?
2) какой эффект будет получен в случае успешного решения задачи?
3) каковы допустимые затраты, как они связаны с показателями качества?
Может оказаться, что затраты существенно превысят эффект, поэтому либо следует отказаться от решения, либо искать более приемлемое.
Рекомендация 3. Уточните условия, в которых предполагается реализация найденного решения:
1) тщательно исследуйте связанные с этим ограничения и убедитесь, что все они действительно имеют место;
2) выявите особенности реализации, в частности, допустимую степень сложности, предполагаемые масштабы применения.
Рекомендация 4. Изучите задачу, используя следующую информацию:
1) как решаются задачи, близкие к рассматриваемой?
2) как решаются задачи, обратные рассматриваемой? (Особое внимание следует обратить при этом на области применения, для которых подобные задачи наиболее актуальны.)
Рекомендация 5. Мысленно измените условия задачи и исследуйте ее решение в новых условиях: изменяйте от нуля до бесконечности сложность объекта, время процесса, затраты, условия среды.
Рекомендация 6. Тщательно отработайте формулировку задачи, желательно с использованием наиболее общих понятий и терминов.
Рекомендация 7. Сформулируйте идеальный конечный результат и в процессе решения стремитесь получить его.
Анализ требований сосредоточен на интерфейсе системы человек — программа — машина и информационных потоках между ними. Здесь решается, что делает человек, а что делает машина и как она это делает. В ходе анализа решается вопрос о целесообразности применения ЭВМ.
В процессе анализа рассматриваются:
1) работа без ЭВМ и с ЭВМ с разной степенью автоматизации;
2) варианты использования существующих программ как без модификаций, так и с их модификациями;
3) варианты со специально созданными программами;
4) время обработки информации;
5) стоимость обработки информации;
6) вероятность ошибок, их последствия и качество обработки информации.
Анализ требований способствует лучшему пониманию системы и достижению наилучшего удовлетворения потребности.
В ходе проведения системного анализа анализируются надсистема, система и подсистема в виде составных частей проектируемой системы.
При проектировании необходимо учитывать следующие эффекты.
Эффект подмены целей. Процесс деятельности по достижению цели, как правило, связан с преодолением неких барьеров, зачастую непредвиденных трудностей. Пытаясь преодолеть их, человек вынужден менять первоначальный план действий, приспосабливая его к конкретным условиям. Естественным для человека является и стремление упростить свою задачу, действовать привычными, хорошо знакомыми способами и средствами. Это может привести чаще всего на заключительных этапах реализации или в процессе эксплуатации к подмене исходной цели. В результате достигнут совсем иной результат, нежели предполагалось вначале.
Поэтому четкая формулировка задачи, ее отслеживание на всех этапах — необходимое условие успешной деятельности.
Цели и средства. Следующий аспект, который не всегда оценивается должным образом, — учет ограничений, накладываемых условиями реализации, в частности свойствами реализующей системы и ограничениями ресурсов. Казалось бы, обеспечение наибольшей эффективности объекта проектирования с позиций надсистемы — главная задача, но парадокс в том, что нельзя формулировать цели, не имея представления о том, как, с помощью каких средств, какой системы они могут быть достигнуты. Далеко не всякая цель достижима, и объясняется это либо невозможностью или незнанием, как реализовать систему, обеспечивающую достижение цели, либо имеются ограничения, которые могут сорвать ее достижение, и т. д.
Повторим ранее высказанную мысль: "хорошие цели всегда являются компромиссом между желанием наилучшим образом удовлетворить потребности и ограничениями, накладываемыми реализацией и средствами". Практика показывает, что цели лучше всего формулируются людьми, знающими возможности их достижения (либо группой специалистов, владеющих различными аспектами проблемы).
Согласование целей. На практике при проектировании целей нередко приходится сталкиваться с ситуацией, когда функционирование одного объекта должно удовлетворить потребности ряда субъектов (надсистем). В этом случае по отношению к каждой надсистеме могут быть сформулированы свои цели, которые зачастую оказываются противоречивыми: более полное удовлетворение потребностей одного из субъектов может быть обеспечено только за счет другого. Если на этапе проектирования цели не согласованы, то, как правило, плохо удовлетворяются потребности как одной, так и другой надсистемы. Поэтому ситуации возможности конкуренции целей должны обязательно выявляться: необходимо согласовать цели так, чтобы наилучшим образом, в рамках возможностей, определяемых ограничениями, достигались цели каждой из надсистем.
Формулировка и формализация целей. Интересной представляется интерпретация целей через потребности и ограничения по ресурсам. При этом можно выделить три варианта формулировки целей.
1. Ограничения отсутствуют. Достижение каждой из сформулированных целей в какой-то мере удовлетворяет потребность, как правило, не снимая ее полностью. Поэтому говорят об остаточной потребности: чем меньше остаточная потребность после достижения цели, тем выше оценивается и сама цель. Следовательно, наилучшей будет та цель, после достижения которой остаточная потребность окажется минимальной.
2. Приведенная выше формулировка привлекательна, но мало реальна. Достижение всякой цели требует наличия ресурсов, причем величина их (ресурсов) существенно зависит от формулировки цели. Поэтому более приемлемой представляется формулировка, когда требуется наилучшим образом удовлетворить потребность при заданных ограничениях на ресурсы.
3. Возможна ситуация, когда могут быть определены ограничения по степени удовлетворения потребностей и требуется при этом минимизировать расход ресурсов. Тогда цель формулируется следующим образом: необходимо обеспечить заданный уровень удовлетворения потребности при минимальном расходе ресурсов. Учет ресурсов и других ограничений является обязательным в большинстве задач проектирования, а значит, на этапе формулировки целей обязателен анализ, позволяющий сопоставить степень достижения целей и расходуемые ресурсы.
Независимо от формулировки цель как результат деятельности может быть задана формально через показатели качества, характеризующие степень ее достижения. Требования к показателям качества могут быть заданы в трех видах: приравнять; ограничить; добиться экстремума.
В общую формулировку целей могут входить составляющие, задаваемые различными способами.
Уровни описания целей. В процессе проектирования цели могут быть описаны на уровне (выражены на языке) субъекта, внешнего и внутреннего описания объекта. Субъект при этом характеризуется своими потребностями, объект при внешнем описании — показателями качества, а при внутреннем, структурированном — через параметры и переменные состояния. Поэтому нередко говорят о задании целей в пространстве потребностей, показателей качества и состояния. Для описания целей на каждом уровне используются соответствующие понятия и величины.
С учетом вышесказанного, общая методика проектирования целей выглядит следующим образом. Строится описание надсистемы и определяются показатели, характеризующие эффективность ее функционирования. Затем определяются функции, которые должны выполняться проектируемым объектом, и конкретные требования к ним через показатели качества надсистемы — тем самым определяются цели в пространстве потребностей. При дальнейшей конкретизации объекта до уровня его показателей качества исследуется влияние последних на показатели надсистемы. Это позволяет выразить цели через показатели качества объекта — задать их в пространстве показателей качества. Дальнейшая конкретизация объекта позволяет определить связи между показателями качества и значениями параметров и переменных состояния, а также выразить цели через требования к ним — описать их в пространстве состояний.
Несмотря на прозрачность методики, на практике при проектировании целей приходится сталкиваться с серьезными трудностями, связанными в основном со сложностью описания надсистемы и взаимосвязи ее показателей с показателями объекта, а также оценки взаимосвязи между значениями показателей и требуемыми для достижения целей ресурсами.
Этап формулировки целей может привести к различным ситуациям.
Ситуация 1. Выход на хорошо знакомые цели, известные разработчику. В этом случае потребуется лишь поиск и корректировка известных решений, т. е. в результате анализа потребностей пользователя проектировщик приходит к выводу, что удовлетворить эти потребности может уже существующий программный продукт с небольшими изменениями.
Ситуация 2. Диаметрально противоположный вариант — новые цели. В этом случае мы имеем дело с задачей, у которой имеется в наличии явно видимая цель и отсутствуют средства для ее непосредственного достижения.