Системный анализ и проектирование системы: что нужно знать каждому разработчику

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

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

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

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

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

Системный анализ — это процесс обзора технологической системы для устранения неполадок, разработки или улучшения. Такая система может быть программной реализацией, такой как система или прикладная программа. Важно рассматривать системный анализ как один из этапов более крупного процесса, жизненного цикла разработки систем (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 наиболее очевидна в его гибкости в качестве общего руководства для решения проблем проектирования систем. Однако он не предназначен для решения всех проблем проектирования, поэтому не бойтесь проявлять творческий подход и находчивость, когда дело доходит до разработки новых решений.