д.ф.м.н, доцент, Бухарский государственный университет, Республика Узбекистан, г. Бухара
РАЗЛИЧНЫЕ ПОДХОДЫ К СИСТЕМНОМУ АНАЛИЗУ И ПРОЕКТИРОВАНИЮ
АННОТАЦИЯ
В статье приведён анализ подходов к системному анализу и проектированию. Рассмотрены различные методы разработки информационных систем. Системный анализ - это процесс сбора и интерпретации фактов, выявления проблем и разложения системы на ее компоненты. Системный анализ проводится с целью изучения системы или ее частей с целью определения ее целей. Это метод решения проблем, который улучшает систему и гарантирует, что все компоненты системы работают эффективно для достижения своей цели. Проектирование системы фокусируется на том, как достичь цели системы.
ABSTRACT
The article provides an analysis of approaches to system analysis and design. Various methods of information systems development are considered. System analysis is the process of collecting and interpreting facts, identifying problems and decomposing a system into its components. System analysis is carried out in order to study the system or its parts in order to determine its goals. It is a problem solving method that improves the system and ensures that all components of the system work efficiently to achieve their goal. System design focuses on how to achieve the goal of the system.
Ключевые слова: системный анализ, методология разработки, гибкий подход, традиционные методы.
Keywords: system analysis, development methodology, flexible approach, traditional methods.
Введение
При разработке информационных систем большинство организаций используют стандарт шагов, называемый жизненным циклом разработки систем (SDLC - Software development lifecycle), в рамках общей методологии разработки систем. SDLC включает в себя такие этапы, как планирование, анализ, проектирование, внедрение и обслуживание. В основе разработки систем, анализа и проектирования лежат второй и третий этапы SDLC. Этап анализа обычно требует тщательного изучения существующей системы, которое продолжается двумя подэтапами: определение требований и анализ.
Процесс определения требований обычно включает в себя тщательное изучение существующих ручных и компьютеризированных систем, которые могут быть заменены или улучшены в рамках проекта. Процесс исследования анализа обычно включает аналитиков для изучения структурных требований в соответствии с взаимосвязями компонентов и устранения избыточности.
- В целях улучшения процессов системного анализа и проектирования были разработаны различные подходы. Традиционный водопадный подход фокусируется на разделении проекта на несколько этапов.
- Гибкий подход фокусируется на самоадаптирующихся процессах с упором на индивидуальные таланты.
- Объектно-ориентированный подход фокусируется на объединении данных и процессов в объекты и разделяет итеративный подход к разработке гибкого метода.
Все эти подходы имеют разные преимущества и недостатки, поэтому их можно использовать для соответствия и оптимизации различных типов проектов.
Анализ
Традиционный водопад SDLC. Этот структурированный подход рассматривает систему сверху вниз [4]. Это формализованный пошаговый подход к жизненному циклу разработки систем (SDLC), который состоит из фаз или действий. Действия одного этапа должны быть завершены до перехода к следующему этапу. По завершении каждого действия или фазы достигается веха, и создается документ, который должен быть одобрен заинтересованными сторонами перед переходом к следующему действию или фазе; требуется кропотливое количество документации и подписаний на каждой части цикла разработки [2]. «Центром структурированного подхода является модель процесса, которая изображает бизнес-процессы системы, а основной моделью, которая представляет процессы, является диаграмма потока данных» [3].
Гибкие методологии (Agile) Такие методологии делают акцент на людях; на личности, а не на роли, которые люди выполняют. В отличие от методологии водопадной разработки, Agile отказывается от документации, но изначально ее трудно адаптировать, добавляя в модель разработки множество новых аспектов, которые сбивают с толку людей. «Методологии Agile пытаются уловить и использовать динамику изменений, присущую разработке программного обеспечения, в самом процессе разработки, а не сопротивляться вездесущей и быстро меняющейся среде» [7].
Традиционные методы требуют полной и точной спецификации требований перед разработкой; Agile-методы предполагают, что изменения неизбежны и должны осуществляться на протяжении всего цикла разработки продукта [6]. Люди, исполняющие эти роли, более важны, чем роли, которые они исполняют. Фаулер считает, что каждый талантливый человек привносит что-то уникальное в команду разработчиков, и не согласен с применением инженерных принципов, рассматривающих людей как взаимозаменяемые единицы.
Гибкие методологии способствуют самоадаптируемым процессам разработки программного обеспечения. Ожидается, что процесс, используемый для разработки программного обеспечения, со временем будет совершенствоваться и улучшаться. Улучшения выполняются посредством процесса обзора, связанного с компиляцией итераций. Гибкие методологии подходят не для каждого проекта. Фаулер рекомендует гибкий или адаптивный процесс, если ваш проект включает в себя: непредсказуемые или динамические требования, ответственных и мотивированных разработчиков, а клиенты поймут процесс и будут вовлечены.
Объектно-ориентированный анализ и проектирование (OOAD).
Объектно-ориентированный подход рассматривает систему снизу вверх. Он объединяет данные и процессы (методы) в объекты. В информационной системе объектами могут быть клиенты, поставщики, контракты и договоры аренды. Набор диаграмм или моделей используется для представления различных представлений и функций системы и широко известен как унифицированный язык моделирования (UML). Позднее объектно-ориентированный подход становится известен как единый процесс, когда эти модели используются вместе с определенным методом разработки систем.
Унифицированный процесс - это итеративный и поэтапный подход к разработке систем [4]. Цель OOAD улучшить качество системы и производительность системного анализа и проектирования, сделав ее более удобной. Объекты сгруппированы в классы, чтобы иметь общие структурные и поведенческие характеристики. OOAD также включает использование наследования; это позволяет создавать новые классы, которые имеют общие характеристики с существующими классами. Подобно гибким методологиям, объектно-ориентированный подход к разработке систем похож на подход итеративной разработки. На этапе анализа объектно-ориентированные модели используются для заполнения пробела между проблемой и решением. По сути, цель состоит в том, чтобы преобразовать варианты использования в модель анализа для достижения связанных с ними целей.
В исследовании японского учёного Сюэ, такая модель анализа последовательно строится из шести шагов, и его исследовательская группа изучила эти шаги с помощью описания варианта использования, чтобы определить возможные участвующие объекты на основе некоторых эвристик. Чтобы перейти к этапу проектирования, объектно-ориентированный дизайн включает в себя процесс преобразования, который преобразует концепции реального мира в модель программного обеспечения, которая обеспечивает модель решения. Процесс преобразования должен осуществляться с учетом следующих вопросов проектирования. Основная проблема: касается основных, общих и повторяющихся проблем при разработке системы. Например, разлагает систему, распределяет объекты, диспетчеризирует процесс управления и составляет компоненты. Проблема качества: касается того, как улучшить нефункциональные требования. Проблема компромисса: касается того, как разрешить конфликтующие требования.
Также важно отметить, что объектно-ориентированная модель не имеет общепринятых стандартов. Таким образом, эти модели очень существенно меняются от одного развития к другому, неизбежна некоторая изменчивость в содержании и структуре моделей анализа [8].
При сравнении традиционных методов и объектно-ориентированного метода фазы этих подходов не совпадают, поскольку унифицированный подход представляет собой двумерную модель по сравнению с традиционной одномерной водопадной моделью. Для унифицированной модели процесса все этапы SDLC проверяются, чтобы разработчики удовлетворяли требованиям в каждом этапе. В каждом приращении «действия одной фазы преобладают над другими, в результате чего усилия по разработке систем перемещаются от зарождения к разработке, от разработки к построению и от построения к переходу» [3]. При сравнении гибких методов и традиционных методов, гибкие методы кажутся более подходящими для небольших проектов ИС, а традиционные методы больше подходят для крупномасштабных проектов. При близком рассмотрении объектно-ориентированного подхода выяснилось, что объектно-ориентированный анализ требует более длительного обучения, но после того, как он был изучен и освоен, объектно-ориентированные аналитики показали лучшие результаты, чем испытуемые, работающие на диаграммах потоков данных, при анализе системы [1].
Однако, сравнивая три подхода: традиционный, гибкий и объектно-ориентированный подход, нет четкого ответа, какой подход лучше, поскольку все они имеют разные преимущества и недостатки. В зависимости от потребности и готовности предприятий инвестировать в свой конкретный проект трудно сказать, какой подход принесет наилучший результат. В целом SDLC можно рассматривать как инструменты, подобные языкам программирования, базам данных, средам промежуточного программного обеспечения или любой другой технологии. Работает это или нет, зависит от вашей компании, ваших людей, ваших процессов и процедур, вашей истории и всего остального.
Выводы
Подходы SDLC, рассмотренные выше, имеют разные способы реализации и детали процесса. Традиционный подход, возможно, является наиболее простым методом системного анализа и проектирования даже для небольших проектов; гибкие методы могут быть более желательны. Однако, если целью проекта является масштабируемость проекта и повторное использование компонентов, лучшим выбором может быть объектно-ориентированный подход.
Список литературы:
- Ван, С. Два метода анализа МИС: экспериментальное сравнение// Журнал образования для бизнеса. С. 136. 1996.
- Гейб, М. Пересмотр проверенных процессов разработки// Ипотечное банковское дело, №71 (12). С.88-89. 2011.
- Мохаммад, Р. Дилемма между структурированным и объектно-ориентированным подходами к системному анализу и проектированию// Журнал компьютерных информационных систем. С. 32-42. 2006.
- Харрис, А., Ланг, М., Оутс, Б. & Seau, K. Системный анализ и проектирование: неотъемлемая часть образования в области ИС// Журнал образования информационных систем. С.241-248. 2011.
- Хоффер, Дж., Джордж, Дж., Валачич, Дж. Анализ и проектирование современных систем/ Прентис Холл: США.2006.
- Цао, Л., Рамеш, Б. Гибкая разработка программного обеспечения: специальные практики или надежные принципы //Компьютерное общество IEEE. С. 41-47. 2007.
- Эриксон, Дж. Гибкое моделирование, гибкая разработка программного обеспечения и экстремальное программирование: состояние исследований// Журнал управления базами данных. С. 88-100. 2005.
- Briand, L., Labiche , Y. Основанный на UML подход к системному тестированию// Модель системы программного обеспечения: №1, С.10-42. 2002.