Системные проекты руководство

Время на прочтение
4 мин

Количество просмотров 2.7K

Всем привет. Я часто применяю в своей работе принципы системной инженерии и хотел бы поделиться этим подходом с сообществом.

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

Формируем начальную архитектуру

Когда система, не важно какая, только начинает разрабатываться, у нас в голове или на бумаге появляются прямоугольники со стрелками. Такие прямоугольники – это и есть компоненты системы. А стрелки — это соединения между компонентами. И очень часто у нас нет времени посидеть и подумать, как все те компоненты, которые мы определили, будут друг с другом работать, а в итоге мы начинаем создавать кучу костылей, придумывая избыточные конструкции.

Важно помнить, что с точки зрения системы и ее архитектуры компонент – это достаточно абстрактная штука. Например, если в нашей системе есть микроконтроллер, то на уровне архитектуры нам важно только то, что это микроконтроллер, а не то, что это STM32, Arduino или Миландр. Более того, зачастую нам вообще непонятно что именно будет в системе, и мы обращаемся к системной инженерии для выработки требований к оборудованию, софту и т.д.

Для нашего примера со СКУД, попытаемся сформулировать ее предназначение. Это поможет нам в определении ее компонентов. Итак, задача СКУД – пропускать в помещение ограниченный круг людей. То есть это — умный замок. Следовательно, у нас появился первый компонент – некое устройство запирающее и отпирающее дверь! Назовем его DoorLock

А как мы узнаем, что человек может попасть внутрь? Мы же не хотим сажать вахтера и проверять паспорта? Давайте выдавать людям специальные карточки с RFID-метками, на которые будем записывать уникальные ID или другие данные, позволяющие точно идентифицировать человека. Тогда нам понадобится некое устройство, которое сможет читать эти метки. Прекрасно, у нас есть еще один компонент, RFIDReader

Посмотрим еще раз на то, что у нас получилось. RFIDReader читает некие данные, система СКУД что-то с ними делает, и на основании этого чего-то управляется DoorLock. Зададим следующий вопрос – а где хранить список людей с правами доступа? Лучше всего в базе данных. Следовательно, наша система должна уметь слать запросы и обрабатывать ответы от базы данных. Таким образом у нас есть еще один компонент – DBHandler. Итак, мы получили крайне абстрактное, но достаточное для начала описание системы. Мы понимаем, что она должна делать и как это устроено.

Вместо листка бумаги я использую System Composer – специальный инструмент для моделирования архитектур систем в среде Simulink – и создам 3 компонента. Выше я описал связи между эти компонентами, поэтому сразу же соединим их:

Расширяем архитектуру

Посмотрим на нашу схему. Кажется, что все хорошо, но на самом деле нет. Посмотрите на эту систему с точки зрения пользователя — пользователь подносит карту к считывателю и…? Как пользователь узнает, что ему разрешен или запрещен доступ? Необходимо как-то его еще оповещать об этом! Поэтому добавим еще один компонент — уведомление пользователя, UserNotify:

А теперь спустимся на уровень абстракции пониже. Попробуем расписать некоторые компоненты чуть подробнее. Начнем с компонента RFIDReader. В нашей системе этот компонент отвечает за чтение RFID-метки. На его выходе должны быть некие данные (UID, пользовательские данные…). Но постойте, RFID, как и NFC, – это в первую очередь железо, а не софт! Поэтому можно допустить, что у нас отдельно есть сам чип для RFID, который передает «сырые» данные в некий предобработчик. Итого, у нас есть абстрактная железка, которая умеет читать RFID-метки, и абстрактный софт, который умеет преобразовывать данные в нужный нам формат. Назовем их RFIDSensor и RFIDParser соответственно. Как это отобразить в System Composer? Можно удалить компонент RFIDReader и вместо него поставить два компонента, но так лучше не делать, так мы потеряем читаемость архитектуры. Вместо этого зайдем внутрь RFIDReader и добавим 2 новых компонента:

Отлично, теперь перейдем к оповещению пользователя. Каким образом система оповестит пользователя о том, что ему запрещен или разрешен доступ к помещению? Человек, воспринимает лучше всего звуки и что-то мигающее. Поэтому можно выдать некий звуковой сигнал, чтобы пользователь обратил внимание, и помигать светодиодом. Добавим соответствующие компоненты в UserNotify:

Мы создали архитектуру нашей системы, но в ней что-то не так. Что же? Посмотрим на имена соединений. InBus и OutBus — не совсем нормальные имена, которые бы помогали разработчику. Их надо переименовать:

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

Главный вывод из этой части такой:

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

Последним
этапом начальной стадии проектирования
ИС является создание системного проекта,
определяющего методы и средства
дальнейшего детального проектирования
и поддержки ЖЦ ИС. Работы
по разработке системного проекта ИС
регламентированы следующими нормативными
документами: ГОСТ-34.602,
РД 50-34.698-90 пункты 2.11, 2, 3.1; ГОСТ Р ИСО/МЭК
12207-99 пункты 5.1.3, 5.2.3, 5.2.4, 5.3.3, 5.3.4, 5.3.5,
5.3.6, 7.1, 7.4, приложения A
и B,
ISO
9000-3 пункты 4, 5. Перечень и порядок работ
может быть следующим:

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

2. Предварительное
   определение архитектуры ИС, ее БД,
   потребностей в вычислительных ресурсах.
   Определение первичный требований к
   интерфейсам: пользователей, аппаратных
   и программных средств, а также их
   основных функциональных компонент.
   Разработка, визуализация и анализ
   реальной модели функционирования,
   диаграмм взаимодействия компонент ИС,
   потоков данных ИС.

3. Выбор или разработка
   модели ЖЦ ИС.

4. Предварительный
   выбор комплекта стандартов и обобщенного
   набора профилей для обеспечения ЖЦ ИС.

5. Предварительный
   выбор технологии, методов и инструментария
   для проектирования и поддержки ЖЦ ИС,
   включая операционную систему, средства
   автоматизации проектирования, создания
   БД и разработки приложений.

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

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

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

9. Разработка
   технического задания и комплекта
   спецификаций требований на создание
   детального и рабочего проектов базовой
   версии ИС.

10. Разработка
    системного проекта базовой версии для
    новой или модернизированной ИС.

11. Приемка комиссией
    заказчика системного проекта и
    утверждение акта о завершении работ.

12. Подготовка и
    заключение контракта на разработку
    детального и рабочего проекта базовой
    версии ИС.

Результатом каждой
из этих работ является набор документов
следующего содержания:

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

• Титульный лист с
  утверждающими и согласующими подписями.

• Полное наименование
  системного проекта ИС.

• Назначение и цель
  разработки или модернизации ИС.

• Основание для
  выполнения и финансирования системного
  проекта.

• Организация –
  заказчик проекта.

• Головной исполнитель
  и соисполнители проекта.

• Общие сроки
  выполнения всего системного проекта.

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

• Обобщенные
  результаты и выводы предпроектного
  обледования.

• Обобщенные
  предложения по концепции разработки
  новой ИС.

• Обобщенные
  характеристики объекта информатизации.

• Общие требования
  к ИС (к функциям и основным задачам, БД,
  инфрастуктуре).

• Предварительные
  требования к эксплуатационным
  характеристикам.

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

• Требования к
  структуре, оформлению и содержанию
  эксплуатационной и технологической
  документации.

• Требования к
  составу и содержанию работ по внедрению
  ИС в эксплуатацию.

• Этапы и график
  выполнения основных работ.

• Ожидаемые результаты
  системного проекта и форма их
  представления.

• Порядок контроля
  исполнения проекта и приемки результатов
  работы.

• Предложения по
  применению и развитию системного
  проекта.

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

• Описание архитектуры
  ИС с выделением компонент ИС и связей
  между ними, с обоснованием выделения
  компонент из системы.

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

• Требования к
  интерфейсам.

• Реальную модель
  функционирования ИС с учетом ограничений
  конкретного проекта:

• функциональную
  модель;

• информационную
  модель;

• событийную модель;

• диаграммы потоков
  данных;

• диаграммы
  взаимодействия компонентов ИС;

• описание интерфейсов
  объектов ИС с окружающей средой и между
  собой.

Описание
модели жизненного цикла, технологии,
инструментария и стандартов на
проектирование ИС должно содержать
разделы:

• Постановка задачи
  и предварительная адаптированная
  модель полного жизненного цикла базовой
  версии ИС.

• Предварительный
  состав и основные положения комплекса
  стандартов и нормативных документов
  для подготовки профилей стандартов.

• Предварительное
  содержание технологии, методов и состава
  инструментальных средств для
  проектирования и поддержки ИС.

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

Планы
управления детальным и рабочим проектами
основаны на общих требованиях и
методах планирования и должны включать
следующие разделы:

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

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

• План управления
  характеристиками качества ИС.

• План управления
  обеспечением безопасности, защитой и
  другими критическими требованиями при
  создании ИС.

• План управления
  субподрядчиками, включая выбор
  субподрядчиков и решение финансовых
  затруднений.

• План управления
  рисками.

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

• План организации
  обучения персонала разработчиков и
  пользователей.

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

• наименование и
  содержание работы;

• дату начала и
  окончания работы;

• наименование
  подразделения – исполнителя работы;

• фамилию и должность
  ответственного исполнителя;

• состав и форму
  представления результатов работы.

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

Системный
проект должен содержать:

• Исходные требования
  к функциям и характеристикам ИС.

• Описание и
  графическое представление архитектуры
  ИС, ее БД и взаимодействия компонент:

• полную реальную
  модель функционирования ИС, с визуализацией
  взаимодействия компонент, потоков
  данных;

• комплект
  предварительных спецификаций на
  компоненты ИС;

• детальное описание
  интерфейсов пользователей и взаимодействия
  внешней средой.

• Модель жизненного
  цикла ИС:

• предложения по
  типу модели ЖЦ ИС;

• предложения по
  выбору технологии проектирования и
  набору инструментальных средств;

• предложения по
  выбору базового комплекта и профилей
  стандартов для обеспечения ЖЦ ИС;

• предложения по
  системе защиты и обеспечения безопасности
  функционирования ИС;

• предложения по
  организационной структуре коллектива
  специалистов для реализации ЖЦ ИС.

• Предварительные
  планы последующих этапов и работ ЖЦ
  ИС.

• Проект технического
  задания на детальное проектирование
  и весь ЖЦ ИС.

• Проект контракта
  на детальный проект и весь ЖЦ ИС.

Акт
завершения работ и утверждение системного
проекта должен содержать разделы:

• Наименование
  завершенной работы.

• Состав представителей
  организации разработчика (поставщика)
  и заказчика (покупателя), составивших
  и утвердивших акт.

• Дата завершения
  работ.

• Перечень исходных
  документов, на основании которых
  проводились работы.

• Перечень документов,
  в которых представлены результаты
  выполненных работ.

• Обобщенные
  результаты системного проектирования.

• Заключения и выводы
  о результатах и качестве завершенной
  работы.

• Предложения о
  возможности и целесообразности
  дальнейшего проектирования и всего ЖЦ
  ИС.

• Рекомендации по
  закрытию контракта (договора) и полному
  расчету за выполненные работы.

Основные
компоненты контракта (договора) на
детальное проектирование и весь ЖЦ ИС
должны содержать:

• Название и цель
  проекта.

• Ссылку на содержание
  основных положений ТЗ на проектирование
  и ЖЦ ИС.

• Полное наименование
  и реквизиты Заказчика (пользователя,
  покупателя).

• Полное наименование
  и реквизиты головного Исполнителя
  (разработчика, поставщика).

• Общие сроки
  проектирования.

• Условия, объемы и
  этапы финансирования проекта.

• Отчетные этапы
  выполнения работ и условия их оплаты.

• Ожидаемые результаты
  проекта.

• Требования к
  документированию результатов проекта.

• Условия контроля
  реализации и приемки проекта.

• Условия возможной
  корректировки ТЗ и контракта.

• Требования к
  мониторингу контракта проекта.

Рассмотрим
подробнее проблему выбора и описания
архитектуры ИС. Под выбором архитектуры
будем понимать выбор платформы (платформ)
и выбор операционной системы (операционных
систем). В системе могут работать
несколько компьютеров на разных
аппаратных платформах и под управлением
различных операционных систем.

Решения
относительно выбора аппаратной платформы,
как правило, необратимы, поскольку тесно
связаны со сметой затрат и наличием
обслуживающего персонала. Например,
решения на платформе RS/6000 и Intel с точки
зрения сметы затрат выглядят одинаково,
но персонала, способного квалифицированно
обслуживать RS/6000, нет, и руководство не
согласно оплатить обучение сотрудников,
хотя решение на основе RS/6000 обладает
более высокой масштабируемостью. Это
может послужить причиной выбора платформы
Intel. Аналогичные причины могут влиять
и на выбор операционной системы. Менять
платформу, операционную систему или
СУБД на этапе реализации сложно, а на
этапе опытной эксплуатации практически
невозможно (на это просто не хватит
времени, если не произойдет чудо). Чем
большее количество компонентов системы
уже реализовано, тем сложнее произвести
подобную замену.

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

Кроме определения
платформы следует выяснить следующее:

Будет ли это
архитектура «файл-сервер» или
«клиент-сервер».

Будет ли это
3-уровневая архитектура со следующими
слоями: сервер, ПО промежуточного слоя
(сервер приложений), клиентское ПО.

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

Будет ли база
данных однородной, то есть, будут ли все
серверы баз данных продуктами одного
и того же производителя (например, все
серверы только Oracle или все серверы
только DB2 UDB). Если база данных не будет
однородной, то какое ПО будет использовано
для обмена данными между СУБД разных
производителей (уже существующее или
разработанное специально как часть
проекта).

Будут ли для
достижения должной производительности
использоваться параллельные серверы
баз данных (например, Oracle Parallel Server, DB2
UDB и т.п.).

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

На этом
этапе системного проектирования большую
роль играют процессы планирования
дальнейших работ по проектированию ИС.
Тщательное планирование важно для
любого проекта. Это входит в обязанности
руководителя проекта и руководителя
группы проектирования (консультации с
аналитиками в этом случае будут
обязательными). Это позволяет:

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

• Определить
  контрольные даты (этапы сдачи), которые
  позволят определить, насколько успешно
  продвигается проект, какие направления
  отстают, какие недогружены, какие
  работают успешно. Это позволяет
  обнаружить отставание от сроков сдачи
  и вовремя предотвратить авралы.

• Определить зависимости
  между задачами, а также последовательность
  завершения задач.

• Прогнозировать
  загрузку персонала, наем временных
  работников, привлечение других групп
  разработчиков, привлечение консультантов
  (если это необходимо).

• Получить
  четкое представление о том, когда можно
  начать следующие этапы проектирования
  ИС.

Заказчики
всегда хотят, чтобы план выполнения
работ оставался неизменным. На практике
этого редко удается достичь в полном
объеме. Определенным компромиссом здесь
может стать неизменность установленных
сроков сдачи компонентов системы.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

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

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

Этим анализам обычно способствуют две задачи: технико -экономическое обоснование и разработка требований.

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

Позже мы рассмотрим обе эти задачи более подробно.

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

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

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

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

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

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

Системный анализ и проектирование системы являются ключевыми этапами SDLC.

Системный анализ против проектирования системы

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

1. Системный анализ предшествует проектированию системы

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

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

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

1. Планирование и предварительный анализ
2. Системный анализ
3. Системный дизайн
4. Разработка
5. Тестирование и интеграция
6. Реализация
7. Эксплуатация и обслуживание
8. Оценка

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

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

2. Сосредоточение внимания на «что» и «как»

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

Системный анализ: «что»

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

Дизайн системы: «как»

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

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

3. Выполнение разных задач

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

ТЭО

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

Эти исследования обычно включают следующие этапы:

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

Этот последний шаг в основном связан с взвешиванием трех типов осуществимости:

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

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

Разработка требований

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

• Как предлагаемая система будет работать на высоком уровне
• Какими качествами или свойствами должна обладать предлагаемая система, чтобы обеспечить ожидаемые результаты

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

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

• Запрос : первоначальный сбор требований от клиента.
• Анализ : Более подробная оценка требований клиентов
• Спецификация : создание официального документа, иногда называемого спецификацией требований.
• Валидация или верификация : обеспечение согласованности документированных требований и их соответствия потребностям клиента.
• Управление : соответствие предлагаемых системных процессов требованиям.

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

После определения осуществимости и тонкой настройки требований системные аналитики составляют SRS. Этот документ позволяет инженерам-проектировщикам систем начать работу над проектом новой или обновленной системы.

ИЗМЕНЕННЫЙ подход к проектированию системы

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

• Требования : Соберите все функциональные и нефункциональные требования, отражающие потребности бизнеса или организации клиента. Функциональные требования представляют собой основные функции, без которых система не будет работать так, как ожидает конечный пользователь, в то время как нефункциональные требования являются важными соображениями, которые не влияют на основные функции.
• Оценка : оценка аппаратных и инфраструктурных ресурсов, необходимых для реализации системы в масштабе.
• Схема хранения (необязательно): сформулируйте модель данных с диаграммами потоков данных, если это имеет отношение к рассматриваемой проблеме. Вы захотите определить структуру данных, какие таблицы использовать, типы полей в таблицах и отношения между таблицами (необязательно). Этот шаг может понадобиться, если вы ожидаете данные с высокой нормализацией, вам нужно хранить разные части данных в разных форматах или вы сталкиваетесь с проблемами производительности и эффективности хранилища.
• Высокоуровневый дизайн: выберите один из 16 строительных блоков, которые мы обсуждали ранее, для выполнения определенных функциональных требований.
• PI : создавайте интерфейсы, которые пользователи могут использовать для вызова различных служб в системе. Интерфейсы принимают форму вызовов API и обычно представляют собой перевод функциональных требований.
• Детальный проект: проанализируйте и улучшите проект высокого уровня, добавив или заменив стандартные блоки для удовлетворения нефункциональных требований, а затем обрисовав в общих чертах эти стандартные блоки. В этой схеме должно быть указано, как и почему работают компоненты, зачем они нужны и как они будут интегрированы.
• Оценка : Сравните детальный проект с требованиями. Обоснуйте компромиссы и взвесьте все за и против альтернативных проектов. Определите области для улучшения и рассмотрите решения любых упущенных проблем.
• Отличительный компонент/функция. Обсудите уникальную функцию, добавленную в ваш проект для удовлетворения требований. Это обсуждение, которое может следовать за различными этапами процесса, может быть наиболее актуальным для интервью или презентаций по проектированию системы.

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

Поскольку в среде высочайших заказчиков и не менее высочайше приближенных разработчиков системных проектов (Минкомсвязи, И-Совет, ГУ-ВШЭ, АНХ, …) наблюдаются разброд и шатания по краеугольным вопросам – что же такое «системный проект» и как его следует разрабатывать, — я решил дать здесь небольшую подборку цитат и ссылок из интернета. Правда, судя по тому, что в И-Совете и Минкомсвязи уже третий месяц не прекращаются дискуссии по поводу «системного проекта» с акцентом на терминологии и методологии, интернета у них нет (иначе они бы давно сами нашли все эти ссылки и материалы). Так что, существует риск, что и мой скромный труд останется необнаруженным. Придется, видимо, все распечатывать, конвертировать (это, если кто не в курсе, не то, что вы подумали, а вовсе даже наоборот – укладывать в конверт) и отправлять по почте (которая Почта России, а не e-mail).

 1. Учебно-методическая литература

Еще 10 лет назад в издательстве «Горячая линия – Телеком» вышла книга Г.Калянова «CASE-технологии: Консалтинг в автоматизации бизнес-процессов». Конечно, найти ее в магазинах сейчас невозможно, но в Российской Государственной Библиотеке она точно есть – это мне на «портале госуслуг» библиотечный сервис подсказал

 Чем хороша эта книжка? Ее автор УЖЕ ТОГДА знал, что такое «системный проект». Во «Введении» (доступно в интернете) читаем (выделение жирным шрифтом мое – А.Б.):

4. Разработка системного проекта

Данный этап является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.

На этом этапе определяются:

¨        архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;

¨        интерфейсы и распределение функций между человеком и системой;

¨        требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;

¨        состав людей и работ, имеющих отношение к системе;

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

Системный проект строится на основе модели «как должно быть» и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEFO или IDEF3), информационную модель, например, в соответствии со стандартом IDEF1X, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89).

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

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

¨        описать, «увидеть» и скорректировать будущую систему до того, как она будет реализована физически;

¨        уменьшить затраты на разработку и внедрение системы;

¨        оценить разработку по времени и результатам;

¨        достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);

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

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

А еще в этой книжке есть просто образец для подражания – готовый (правда, учебный) системный проект. Приложение 4 так и называется – «Системный проект паевого фонда (учебный пример)».

 2. Сайты системных интеграторов

Кому, как не СИСТЕМНЫМ интеграторам знать, что такое СИСТЕМНЫЙ ПРОЕКТ? На сайте компании-интегратора «Сайнер» (Sciner) есть страничка, посвященная системному проекту – «Цели, задачи, рамки, принципы Системного проекта»:

Цели Системного проекта:

¨        обеспечить соответствие целей Проекта создания КИСУ бизнес-целям компании;

¨        обеспечить целостность модели управления и архитектуры КИСУ;

¨        обеспечить прозрачность и управляемость комплексного Проекта создания КИСУ;

¨        обеспечить достижение главных целей и задач проекта создания КИСУ;

¨        обеспечить эффективность инвестиций в систему управления предприятием.

Задачи Системного проекта:

¨        проанализировать состояние автоматизации предприятия;

¨        определить комплексную архитектуру КИСУ, согласованную с целевой моделью управления предприятием;

¨        предложить оптимальную организацию работ;

¨        оценить проектные риски и предложить оптимальную стратегию работы с ними;

¨        провести оценку ресурсов, требуемых для реализации проекта.

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

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

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

Разработка и утверждение схемы бизнес-процессов дает возможность перехода к разработке Системного проекта. Основываясь на общей схеме бизнес-процессов предприятия, Системный проект определяет направленность и последовательность подпроектов создания КИСУ (с учетом модели управления и организационной структуры предприятия).

Еще вариант достаточно короткого определения – что есть «системный проект»:

Системный проект, как пакет материалов, документирующих требования к будущей системе и ее свойства, содержит следующие сведения:

¨   перечень функций, реализуемых системой и их распределение между элементами системы;

¨   состав людей и работ, имеющих отношение к системе;

¨   распределение функций между человеком и системой и их взаимодействие;

¨   топологию размещения элементов системы;

¨   структуру и потоки информации и документов, участвующих в системе, процедуры документооборота;

¨   предложения по оптимизации организационной структуры предприятия, в соответствии с проектируемой системой;

¨   полномочия участников системы;

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

И вообще – Google по запросу «системный проект» выдает 204 миллиона ссылок. Даже если допустить, что релевантными окажутся только 0,01% полученных ссылок – и тогда это будет более 20 тысяч страниц! Есть из чего выбирать.