Файл: Основы проектирования программ. Этапы создания программ (Общие положения теории проектирования)ного обеспечения.pdf

Первый этап системного анализа^[37] (организационного окружения) связан с тем, что нельзя создать работоспособную информационную систему, если исследователи ничего не знают о особенностях функционирования организации, функции которой должна обслуживать автоматизированная система (АС) и элементом которой она является. Нужно понимать тип и особенности деятельности, управленческую структуру, методы управления, персонал, связи подразделений, динамику информационного обмена между рабочими группами и отдельными работниками (сроки, формы отчетов и документов, количество экземпляров и т.п.).

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

Важно выяснить:

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

Такой перечень целей следует иметь как памятку в личном дневнике исследователя системы.

Рис. 1. Этапы проведения системного анализа информационных систем^[40]

Второй этап системного анализа самый сложный шаг в массу метаинформации^[41], т.е. "данных о данных^[42]". Важными ориентирами в организации метаинформации являются объекты (совокупности, диаграммы, документы, аналитические записки и тексты, экономические показатели), также процессы создания объектов, их передачи, хранения и обработки.

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

Третий этап системного анализа - определение того, что должно быть в новой АС. Это методологический этап синтеза требований к новой системе^[43], которые вытекают из двух первых шагов анализа, также из специальных знаний и средств системных аналитиков. Специалисты по системному анализу знают, одной из коварных ловушек в их работе это возможность спутать анализ существующей системы с тем, что должно быть. Поэтому второй и третий этапы системного анализа четко разделены. Об этом важно помнить, чтобы не ошибиться в оценках основы, на которой новая система строиться. В системотехнической методологии анализ существующего отделяется от анализа черт будущего, чтобы не воспринять желаемое за действительное.

Четвертый этап системного анализа (документирование требований к новой системе) должен обобщить имеющиеся аналитические материалы и создать документированное отображение функциональных требований к новой АС. Документ "Требования к системе^[44]", или "Функциональные требования^[45]", является основой дальнейшей работы специалистов информационного отдела для создания детального проекта новой системы, для создания спецификаций всех ее инструкций, элементов, программ.

Этап системного анализа отвечает на вопрос, что должна иметь информационная система для удовлетворения требований пользователей, а этап системного проектирования отвечает на вопрос, как конкретно осуществить АС.

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

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

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

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

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

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

Итак, на данном этапе эволюционного развития ситуация в области проектирования АС выглядит следующим образом^[47]:

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

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

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

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

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

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

1) Постановка недостижимой цели;

2) Стремление разработчика и постановщика задачи упростить задачу;

3) Неумение разработчика выделить из формулировки постановщика отдельно описание проблемы и постановку задачи;

4) Не выявленные ограничения.

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

Можно сформулировать последовательность рекомендаций^[49] (контрольных вопросов):

Рекомендация №1. Не доверяйте имеющимся формулировкам задачи

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

Рекомендация №2. Уточните требования к конечному результату:

1) Какие функции и с какими показателями качества должен выполнять функции объект?

2) Какой эффект будет получен в случае успешного решения задачи?

3) Каковы допустимые затраты, как они связаны с показателями качества?

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

Рекомендация №3.^[50] Уточните условия, в которых предполагается реализация найденного решения:

1) Подробно исследуйте ограничения и убедитесь, что они действительно имеют место;

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

Рекомендация №4. Изучите задачу, используя следующую информацию:

1) Как решаются задачи, близкие к рассматриваемой?

2) Как решаются задачи, обратные рассматриваемой? (Следует обратить особое внимание на области применения, для которых подобные задачи наиболее актуальны.)

Рекомендация №5. Мысленно измените условия задачи и исследуйте ее решение в новых условиях: изменяйте от нуля до бесконечности сложность объекта, затраты, время процесса, условия среды.

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

Рекомендация №7. Сформулируйте идеальный конечный результат, в процессе решения стремитесь получить его.

Анализ требований^[51] сосредоточен на интерфейсе системы человек - программа - машина и информационных потоках между ними. Здесь решается, что делает человек, а что и как делает машина. В ходе анализа решается вопрос о целесообразности применения ЭВМ^[52].

В процессе анализа рассматриваются^[53]:

1) Работа без и с ЭВМ с разной степенью автоматизации;

2) Варианты использования существующих программ как без так и с модификациями;

3) Варианты с программами специально созданными;

4) Время обработки информации;

5) Стоимость обработки информации;

6) Вероятность ошибок, последствия их и качество обработки информации.

Анализ требований способствует достижению наилучшего удовлетворения потребности и лучшему пониманию системы.

В ходе проведения системного анализа^[54] анализируются надсистема, система и подсистема в виде составных частей проектируемой системы.

При проектировании необходимо учитывать следующие эффекты.

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

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

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

"Хорошие цели всегда являются компромиссом между желанием наилучшим образом удовлетворить потребности и ограничениями, накладываемыми реализацией и средствами^[55]".

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

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

Формулировка и формализация целей. Интересна интерпретация целей через потребности и ограничения по ресурсам. Можно выделить три варианта формулировки целей^[56]:

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