Анализ и проектирование информационных систем: ключевые аспекты

Системное проектирование

Подытожим

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

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

Моделируя систему, определитесь с тем, кто будет потреблять документированную  информацию как на этапе разработки, так и в будущем, какие знания важно сохранить по итогам реализации на «электронной бумаге». Строить дом без плана — странно

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

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

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

Проектируйте, и в процесс вашей разработки придет порядок!

Причины появления системного аналитика

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

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

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

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

Организация проектирования ИС

Организацию проектирования ИС принято разделять на 2 типа:

  1. Каноническое проектирование отражает особенности технологии оригинального (индивидуального) процесса.
  2. Типовое проектирование, для которого характерно типовое проектное решение (ТПР), тиражируется и пригодно к многократному использованию.

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

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

  1. Предпроектная стадия. Производится предпроектный анализ и составляется техническое задание. То есть, формируются требования к ИС, разрабатывается её концепция, составляется технико-экономическое обоснование и пишется ТЗ.
  2. Проектная стадия предусматривает составление эскизного и технического проектов, разработку рабочей документации.
  3. Послепроектная стадия даёт старт мероприятиям по внедрению ИС, обучению персонала, анализу результатов испытания. Частью этой стадии становится сопровождение ИС и устранение выявленных недостатков.

Этапы, в случае необходимости, можно укрупнять или детализировать – объединять последовательные этапы, исключать «лишние», начинать выполнение очередной стадии до завершения предыдущей.

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

Декомпозиция может иметь несколько уровней, что позволяет выделить классы ТПР:

  • элементные – по отдельной задаче (элементу),
  • подсистемные – по отдельным подсистемам,
  • объектные – отраслевые типовые проектные решения, содержащие весь набор подсистем.

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

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

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

Аспекты анализа объекта с позиции системного подхода

С позиции системного подхода изучение объекта включает ряд аспектов:

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

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

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

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

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

Этапы развития системного подхода в XX в.

Выделяют следующие этапы в развитии системного подхода в XX в. (таблица 1).

Таблица 1 — Основные этапы в развитии системного подхода

Временные рамки Имена исследователей
1920-е гг. Тектология (всеобщая организационная наука) – это общая теория организации (дезорганизации), наука об универсальных типах структурного преобразования систем Л. А. Богданов
1930-1940-е гг. Общая теория систем (в качестве совокупности принципов исследования систем и спектр отдельных изоморфизмов, выявленных эмпирически, в формировании и функционировании различных по структуре системных объектов). Система является комплексом взаимодействующих элементов, совокупностью элементов, которые находятся в определенных соотношениях со средой и друг с другом Л. фон Берталанфи
1950-е гг. Проектирование автоматизированных систем управления и развитие кибернетики. Винер доказал законы информационного взаимодействия структурных элементов в процессе управления системой Н. Винер
1960-1980-е гг. Концепции общей теории систем, обеспеченные собственным математическим аппаратом, к примеру, модели многоцелевых многоуровневых систем П. Глушков, М. Месарович

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

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

Согласно общей теории систем объект изучается в качестве системы и как составляющий более крупной системы одновременно.

Что делает системный аналитик?

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

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

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

Состав и модели процедур документооборота, обеспечивающих информационное взаимодействие автоматизированных рабочих мест Компании

Анализ разработанных рациональных
функционально-информационных моделей
технологий работ Компании позволяет
систематизировать и сформировать группы
документов по типовым алгоритмам прохождения
между должностными лицами и исполнителями.

В процессе выполненного объединения потоков
входящих и исходящих документов сформированы
четыре типовые группы документов:

  • договорные документы;
  • первичные бухгалтерские
    документы;
  • документы поддержки
    бизнес-процессов;
  • отчетные документы.

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

  • договорные документы;
  • первичные бухгалтерские
    документы;
  • документы поддержки
    бизнес-процессов.

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

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

Оцените статью