Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Структурный анализ системы




Формулировка целей создаваемой ИС

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

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

1) аналитику сложно получить исчерпывающую информацию для оценки требований к системе с точки зрения заказчика;

2) заказчик, в свою очередь, не имеет достаточной информации о проблеме обработки данных, чтобы судить, что является выполнимым, а что – нет;

3) аналитик сталкивается с чрезмерным количеством подробных сведений о предметной области и о новой системе;

4) спецификация системы из-за объема и технических терминов непонятна для заказчика;

5) в случае понятности спецификации для заказчика, она будет недостаточной для разработчиков, создающих систему.

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

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

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

Выделение двух базовых принципов инженерии информационных систем не означает, что остальные принципы являются второстепенными. Отметим самые основные принципы:

1) принцип концептуальной общности - заключается в следовании единой философии на всех этапах жизненного цикла;

2) принцип полноты - заключается в контроле на присутствие лишних элементов;

3) принцип непротиворечивости заключается в обоснованности и согласованности элементов системы;

4) принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечение от несущественных аспектов с целью представления проблемы в более простом, общем виде;

5) Принцип упрятывания - заключается в сокрытии несущественной на конкретном этапе информации: каждая часть «знает» только необходимую ей информацию;

6) принцип логической независимости заключается в концентрации внимания на логическом описании системы, обеспечении независимости от ее физической реализации;

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

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

На данном этапе эволюционного развития ситуация в области проектирования программ ИС выглядит следующим образом:

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

2) имеется перечень потребностей, которые необходимо удовлетворить;

3) имеется ряд программных средств, которые в совокупности могут удовлетворить все имеющиеся потребности, но они никак не связаны между собой.

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

Первый этап проектирования: Формулировка целей

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

Как правило, все ошибки в формировании и последующих этапах имеют следующие причины:

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) ограничить;

3) добиться экстремума.

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

УРОВНИ ОПИСАНИЯ ЦЕЛЕЙ. В процессе проектирования цели могут быть описаны на уровне (выражены на языке) субъекта, внешнего и внутреннего описания объекта. Субъект при этом характеризуется своими потребностями, объект при внешнем описании - показателями качества, а при внутреннем, структурированном - через параметры и переменные состояния. Поэтому нередко говорят о задании целей в пространстве потребностей, показателей качества и состояния; для описания целей на каждом уровне используются соответствующие понятия и величины.

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

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

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

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

Этап формулировки целей может привести к различным ситуациям.

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

Ситуация 2. Диаметрально противоположный вариант - новые цели. В этом случае мы имеем дело с задачей, у которой имеется в наличии явно видимая цель и отсутствуют средства для ее непосредственного достижения.

 




Поделиться с друзьями:


Дата добавления: 2014-01-06; Просмотров: 578; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.01 сек.