Системный анализ для маленьких
Часть 1. Краткая история
Как бы многие не думали, системные представления не являются открытием ХХ века. Слово "система" появилось в Древней Греции 2000-2500 лет назад!
значение: сочетание, организм, устройство, организация, строй, союз.
Первоначально оно (слово) было связано с формами социально-исторического бытия, позднее принцип порядка был перенесен на Вселенную. В античной философии термин "система" характеризовал упорядоченность и целостность естественных объектов, а термин "синтагма" - упорядоченность и целостность искусственных объектов.
Именно в античной философии был сформулирован важнейший системный тезис — целое (система).
Эпоха зарождения основ системного анализа была характерна рассмотрением систем физического или философского происхождения. При этом постулат (Аристотеля): «Важность целого превыше важности его составляющих» сменился позже на новый постулат (Галилея): «Целое объясняется свойствами его составляющих».
Философское определение системного анализа:
Системный анализ – это прикладная диалектика, т.е. учение о всеобщей связи и развитии.
Сам термин «системный анализ» впервые появился в 1948 году в публикациях корпорации RAND (Research and Development — «Исследования и разработки»).
С момента создания в структуре военно-воздушных сил США в 1945 году RAND была центром разработки стратегических решений ключевых задач международной безопасности. В сфере её интересов — исследования по проблемам национальной безопасности, оценка качества и стоимости перспективных вооружений, а также рисков, связанных с их разработками.
Первым масштабным аналитическим продуктом, построенным на основе системного анализа, был проект 1950 года «Strategic Bombing Systems Analysis», ставший ответом экспертов корпорации RAND на возрастающую угрозу со стороны СССР, впервые проведшего испытания ядерного оружия в 1949 году.
В 1960-е годы в корпорации RAND была разработана первая методика системного анализа PATTERN (Planning Assistance Through Technical Evaluation from Relevant Number — помощь планированию посредством относительных показателей технической оценки). Её назначением было перспективное планирование разработки дорогостоящих систем вооружения с учётом прогноза развития науки и техники.
Постепенно в корпорации сделали упор на системный анализ, теперь на первый план выдвигаются гипотезы и логика принятия решений.
Системный анализ признается в настоящее время наиболее конструктивным из направлений системных исследований.
Но это не мучительная статья об истории зарождения системного анализа, так что поехали дальше.
Часть 2. Как я начинал?
И одним из первых моих мест работы в сфере IT была компания, которая на заказ разрабатывала программное обеспечение, например, нужно было разработать программное обеспечение для электросетей: оно должно было иметь функционал, который бы считывал количество скачков электроэнергии на линиях электропередач.
Я работал там в качестве бизнес аналитика.
И хочу заметить - бизнес аналитики (в основном) не знают ЧТО "под капотом", поэтому вся логика работы, в таких случаях, уходит на усмотрение разработчикам, т.е. разработчики сами продумывают, как проектировать систему.
Но разработчики пишут код, описывать документацию в их обязанности не входит. Поэтому никакой документации (грубо говоря инструкции) на то как работает система в компании, естественно, не было.
Как следствие - в компании возникало много трудностей, когда у заказчика появлялись задачи на доработку системы (например, добавить дополнительную кнопку).
А ведь в данной ситуации разработчик может уже и не работать в компании, заболеть, уйти в отпуск – и новому/другому разработчику придётся вникать в задачу с нуля: вычитывать ЧУЖОЙ код, понимать какие взаимосвязи имеются.
Компания тратила колоссальное количество времени и денег, которые можно было бы сэкономить, будь описана документация.
Несколько раз столкнувшись с такой проблемой, я погрузился с головой в нюансы и узнал, что есть такая должность как системный аналитик, который продумывает технические решения разработки. Так начался мой путь в системном анализе..
Часть 3. О серьезном
В идеальном мире, например, на моей нынешней работе, процесс разработки происходит следующим образом:
• Задача поступает в работу бизнес-аналитика от владельца продукта в "начальной форме".
• Бизнес аналитик собирает и формирует первоначальные требования и передает их в архитектуру.
• Архитектор валидирует, проверяет корректность бизнес требований и проектирует архитектуру, а затем передает задачу в системный анализ.
• Системный аналитик пишет постановку на разработку и ставит задачу разработчикам.
• После написания кода задача уходит в тестирование.
• И наконец, после успешного тестирования - выкатывается итоговый продукт.
Итак, что же такое системный анализ?
Если коротко, системный анализ нужен Вам для того чтобы ожидание и реальность совпали.
Представьте Вы хотите построить дом, Вы нафантазировали дом который слева на картинке, но без конкретного описания ТЗ, системного анализа, выявления и написания требований заказчика получится дом который справа.
Чтобы описать систему, недостаточно только перечислить ее элементы. Еще необходимо указать как эти элементы связаны друг с другом.
На примере ниже вы видите схему ERD из 4 таблиц (члены семьи, покупки, продукты, типы продуктов), на которых в виде реляционной базы данных отображены связи. С помощью этих связей мы можем отследить покупки за определенный период времени, либо отдельного члена семьи и тд
Когда вы опишите элементы системы и укажете их взаимосвязи, тем самым Вы проведете системный анализ.
Системный аналитик — это тот человек, который продумывает технические решения, реализацию и пишет понятное техническое задание для разработчика
Поговорим о принципах системного анализа
Принцип конечной цели. При проведении системного анализа следует прежде всего определить цель исследования. Это касается как задачи исследования существующей системы, так и разработки новой системы. От формулировки цели зависят такие фундаментальные понятия как показатели качества системы и критерии их оценки, а для проектируемых систем сверх того – их функции и структура.
Принцип измеримости. Необходимы количественные оценки качества системы, в особенности применительно к надсистеме (государству, региональной экономике, рынку и др.) Такими количественными оценками занимается специальное научное направление – теория эффективности.
Принцип иерархии. Сложные системы не могут создаваться или исследоваться иначе как на основе иерархической декомпозиции. Введение иерархии подсистем упрощает разработку системы и определяет порядок ее исследования/
Принцип модульного построения. При исследовании или проектировании сложных систем необходимо выделение относительно независимых модулей с обеспечением возможности их отдельного рассмотрения или создания. Здесь необходимо определение интерфейса в терминах вход/выход.
Принцип развития означает учет изменяемости системы во времени, возможность ее адаптации к изменяющимся условиям и требованиям. В основу создаваемой системы следует закладывать возможность наращивания масштаба, расширения функций, других усовершенствований. Для определения возможной динамики системы принцип развития также требует учета предыстории системы и действующих тенденций. Одним из основных понятий здесь является жизненный цикл системы.
Принцип неопределенности – это необходимость учета неопределенностей и случайностей в системе. Можно изучать или проектировать систему, в которой существует неполнота или неопределенность информации в отношении структуры, функционирования или воздействия внешней среды. Принцип неопределенности приводит к вариантности анализа: можно отдельно оценивать «наихудшие» ситуации и проводить оценку гарантированного результата. Часто рассматривают три варианта: наилучший (оптимистический), наихудший (пессимистический) и усредненный (наиболее вероятный).
Чем конкретно занимается системный аналитик?
Ключевым моментом в реализации задачи являются два последних пункта, а точнее сбор требований. Чем лучше и точнее собраны требования, тем качественнее будет реализована задача.
Разберемся что такое требования и какие они бывают.
Требования — это описание того, что должна делать система, какие функции выполнять и какие ограничения соблюдать.
Это конкретные требования, которые ставит заказчик. Требования собирает бизнес аналитик, прорабатывает их и передает в работу системному аналитику.
Бизнес требования отвечают на вопрос: ЧТО должна делать система?
Это уже работа системного аналитика. Отвечают на вопрос: КАК должна работать система?
В функциональных требованиях описываются возможности и функции, которые должна иметь система, т.е. как все должно работать.
Одним словом - надежность. Определяют качество разрабатываемого функционала, такие как безопасность, производительность, надежность и прочее.
Здесь можно задать вопросы: Кто? Зачем? Как?, которые опишут взаимодействия конечных пользователей с продуктом.
Как же добывать эти требования? Есть ряд пунктов, который необходимо изучить:
Интервью – разговор с заинтересованными лицами по выявлению требований, получаем информацию непосредственно от пользователей и заинтересованных сторон. Этим может заниматься и системный и бизнес аналитик.
Анкетирование и опросы – можем сделать анкеты и опросники, раздать, получить обратную связь, когда у тебя есть варианты вопросов.
Работа с фокус группами – например, есть запрос от одного заказчика, который является учителем в школе, ему необходимо добавить функционал на сайт, но у нас есть еще преподаватели, значит собираем информацию со всех, возможно появятся дополнения, чтобы потом не переделывать.
Мозговой штурм – это когда мы генерируем новые идеи и решения, используется на ранних этапах проекта: работа с командой. Я, например, показываю какой-то макет и мы с командой накидываем наброски, идеи.
Наблюдение – наблюдаем за работой преподавателя, за интерфейсом, выявляем какие-то моменты для себя.
Прототипирование – делаем прототипы на собранных требованиях, показываем заказчику, обсуждаем стоит что-то дорабатывать или нет.
После всего этого идет Анализ требований – описываем всю полученную информацию, структурируем ее.
Требования формируются по шаблонам. Рассмотрим их подробнее:
User Story, или пользовательская история, помогает увидеть функции продукта глазами конечного потребителя. Основную часть User Story пишут кратко, без технических деталей и лишних подробностей. Главное — сделать фокус на целях и потребностях людей.
Шаблоны обычно записываются в формате:
Этот шаблон позволяет понять кто является пользователь, что он хочет сделать и зачем ему это нужно.
Use case или путь пользователя - это описание конкретного взаимодействия между пользователем и системой. Он помогает разработать качественный продукт, от которого пользователь получит ожидаемый результат.
Когда разрабатывают ПО, для него пишут спецификацию — большой документ, который описывает, как должна работать система или продукт. Он состоит из разных требований: от бизнеса, пользователей, требований к функциям ПО, интерфейсам, операционной системе. Use case (в переводе с англ. «вариант использования») — это часть такого документа. Он описывает, какие действия выполняет пользователь и как система должна на них реагировать. Пример простейшего use case:
Ну вот и все. Данная статья в кратце дает понять нам, что представляет из себя Системный анализ.