что такое системный проект
Что такое системный проект
Консалтинг при автоматизации предприятий:
подходы, методы, средства
12.2. Разработка системного проекта
Создание системного проекта (по другому, модели требований к будущей системе) является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются, так как если требования нигде не зафиксированы, то их вроде-бы и не существует. Системный проект строится на основе модели “ как должно быть ” и результатов обследования предприятия в части выявления требований к будущей системе.
Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.
На этом этапе определяются :
В рамках системного проектирования должно быть осуществлено :
Системный проект должен включать :
Таким образом, системный проект содержит функциональную, информационную и, возможно, событийную модели требований к будущей системе. Виды и последовательность работ при построении этих моделей требований аналогичны соответствующим работам по построению моделей деятельности. Дополнительно системный проект включает в себя техническое задание на создание автоматизированной системы.
Необходимо отметить следующее достоинство системного проекта. Для традиционной разработки характерно осуществление начальных этапов кустарными неформализованными способами. В результате заказчики и пользователи впервые могут увидеть систему после того, как она уже в большей степени реализована. Естественно, эта система отличается от того, что они ожидали увидеть. Поэтому далее следует еще несколько итераций ее разработки или модификации, что требует дополнительных (и значительных) затрат денег и времени. Ключ к решению этой проблемы и дает системный проект, позволяющий:
С истемный проект полностью независим и отделяем от конкретных разработчиков, не требует сопровождения его создателями и может быть безболезненно передан другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации системы на основе проекта, он может быть положен «на полку» до тех пор, пока в нем не возникнет необходимость. Кроме того, его можно использовать для самостоятельной разработки или корректировки уже реализованных на его основе программных средств силами программистов отдела автоматизации предприятия.
Системное проектирование по сравнению с построением моделей деятельностей имеет важную особенность в технике структурирования модели. Особую роль здесь играют хранилища (накопители) данных : практически все процессы модели связываются не напрямую, а с использованием этих объектов (что реально соответствует чтению / записи информации из / в базу данных). При этом операции записи должны удовлетворять основному критерию проектирования : данные должны заносится в накопитель один раз в том месте, где они впервые появляются.
Основное правило введения накопителей данных заключается в следующем : если данные из некоторого накопителя используются по крайней мере двумя процессами, то этот накопитель должен присутствовать на содержащей эти процессы диаграмме. Поэтому на втором уровне модели (детализации контекстной диаграммы) должны быть введены базовые накопители, к которым осуществляют доступ основные подсистемы будущей системы. Базовым накопителям должны соответствовать основные подсхемы информационной модели. К выявлению базовых накопителей следует подходить чрезвычайно тщательно, поскольку именно с ними будут работать бизнес-процессы и бизнес-функции на всех без исключения уровнях детализации модели.
В качестве примера введения накопителей рассмотрим фрагмент модели требований к системе автоматизации упоминавшейся выше автобазы, входящей в состав горнообогатительного комбината и занимающейся перевозками породы. На рис. 12.1. приведена диаграмма потоков данных, детализирующая рассматриваемую систему на основные подсистемы:
На данном уровне введены накопители данных, используемые в нескольких подсистемах и являющиеся прообразами подсхем интегрированной базы данных автобазы:
Обмен диспетчерскими данными моделируется с использованием информационного канала Оперативные диспетчерские данные.
Все перечисленные накопители детализируются на нижних уровнях в тех процессах, где такая детализация необходима. Например, в процессе Химический анализ масел и жидкостей введен накопитель Масла и охлаждающие жидкости, являющейся частью накопителя Запасные части и материалы, и по сути моделирующий единственную таблицу из базы данных, в которой хранятся данные об имеющихся в наличии на автобазе маслах и охлаждающих жидкостях (тип, место хранения, объем, результаты спектрального анализа и т.п.).
Рис. 12. 1 . Фрагмент системного проекта
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Основы системного проектирования. Кратко. Таблица
Каждое предприятие в ходе своей деятельности решает важные задачи. Для этого применяются как ранее разработанные методы, так и новые подходы. Однако для выполнения любого задания требуется индивидуальный творческий взгляд. Процесс, начиная от поиска специфических выводов и заканчивая их применением, называют системным проектированием.
Что такое системное проектирование
Системное проектирование – это система операций, связанных с поиском оригинальных и творческих решений, с утверждением результатов, анализом продуктивности и иными видами деятельности.
В экономической теории существует несколько понятий проектирования. Зачастую, так называют полезную работу, которая связана с удовлетворением новых потребностей клиентов. Результатом проектирования является готовый план, оформленный в электронном или бумажном виде. В дальнейшем он послужит основой для выполнения поставленной задачи.
Законы, принципы и задачи проектирования
Системное проектирование выполняет такие задачи, как:
Цели системного проектирования напрямую связаны с задачами. Главным его назначением считают решение поставленных задач посредством поиска и выбора творческих методов. Системное проектирование строится на нескольких законах:
| № п.п. | Закон системного проектирования | Описание |
| 1 | Информационной проводимости | Означает, что система будет эффективна только в случае обеспечения информационной проходимости на всех этапах |
| 2 | Увеличения уровня превосходства системы | Конструкцию необходимо постоянно улучшать до тех пор, пока исследуемые параметры не будут стремиться к нулю, при условии сохранения и выполнения функций |
| 3 | Поэтапного развития | Систему проектирования рекомендуется развивать в определенной последовательности, не перескакивая через этапы |
| 4 | Соотношения функций и элементов конструкции | Если форма предмета проектирования будет соответствовать содержанию системы, конструкция считается эффективной |
| 5 | Роста потребностей и любопытства потенциальных клиентов | С увеличением предложения растет и уровень потребностей, а любопытство всегда заставляет людей попробовать что-то новое |
| 6 | Минимизации усилий | Человеческая природа заставляет людей лениться и пытаться выполнить задачу, приложив минимум усилий |
К принципам системного проектирования относят:
Важно! Предмет проектирования возникает на этапе постановки задачи.
Элементы системного проектирования
Элементы системного проектирования классифицируют по двум признакам: по стадиям и процессам. Стадийная структура конструирования характеризуется тем, что каждый его этап строго регламентирован ГОСТом и включает в себя:
Важно! Сертификация отвечает на вопрос, соответствуют ли новые товары заявленным требованиям. Ее проводят специализированные органы, включенные в список Государственным стандартом.
Методы системного проектирования
Системное проектирование осуществляется с применением одного или группы методов. Приемами называют действия работника, при помощи которых он достигает поставленной цели. Экономическая теория делит методы на группы:
Надо отметить, что использование того или иного метода начинается с его избрания, а заканчивается принятием лучшего варианта для выполнения задачи решения.
Эвристические
Эвристические методы — это приемы, основанные на творческом мышлении и оригинальном подходе. Если говорить простыми словами, эвристическими вариантами называют совершенно новый подход, не имеющий аналогий.
Надо отметить, что подобные методы в настоящее время используют практически все успешные крупные фирмы, независимо от их деятельности. К эвристическим методам относят следующие приемы:
Важно! В ходе системного проектирования могут быть использованы несколько приемов. Все зависит от сложности и специфики задачи.
Основу теории решения изобретательских задач заложил ученый Г.С. Альтшуллер, после того, как сформировал тысячи патентов. Его огромный опыт позволил создать алгоритм выполнения заданий. Данная группа приемов необходима, чтобы найти причины, которые влияют на выполнение задачи. ТРИЗ включает в себя следующие методы:
Последний метод делится на несколько подгрупп. Выбор того или иного приема напрямую зависит от вида производимой продукции.
Прием базового агрегата используют в том случае, если есть необходимость выпустить продукцию, имеющую одно или несколько идентичных свойств.
Метод агрегирования характеризуется соединением унифицированных членов. Модификация связана с видоизменением ранее установленных форм, а стандартизация, производство продукции и ее усовершенствование осуществляются путем использования нормативов.
Экспериментальные приемы
К экспериментальным приемам относят методы, которые ранее компания не применяла. Их реализация осуществляется путем измерения показателей, анализа, диагностирования, а также закрепления явлений. Группа экспериментальных приемов включает в себя следующие методы:
В первом случае аналитик планирует, проводит опыт, а затем оценивает его итоги. Второй прием предполагает реализацию исследования при помощи предметов автоматизации, например, компьютера. Мыслительный вариант – это прием, при котором весь эксперимент проходит в голове у исследователя и не является производством физических действий.
Формальные
Формальные методы – это привычные всем приемы системного планирования. Их достоинство заключается в том, что они помогают быстро и без лишних затрат составить проект, сформировать его структуру и реализовать в автоматическом режиме.
Предмет проектирования
Предметом проектирования называют конечный результат проведенной работы. То есть, вся деятельность направлена на формирование данного объекта. Как правило, на предприятии предметом проектирования может стать новый вид продукции, иная услуга или другие работы.
Важно! Прежде чем приступить к реализации проекта, важно создать модель предмета исследования. Это поможет оценить свойства объекта, а в случае необходимости, видоизменить их.
Модели делятся на три основных вида. Эвристический образец – это не физический предмет, а некий образ предмета, который аналитик рисует у себя в голове. Он мысленно оценивает свойства объекта и принимает решение о реализации проекта либо о внесении в него изменений.
Физическая модель характеризуется реальным ее существованием. Однако размеры могут существенно отличаться от предусмотренных проектом. Математический образец – это числовое или аналитическое выражение будущего объекта, которое характеризует его основные свойства и функции.
Большая Энциклопедия Нефти и Газа
Системный проект
Системный проект полностью независим и отделяем от конкретных разработчиков, не требует сопровождения его создателями и может быть безболезненно передан другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации системы на основе проекта, он может быть отложен до тех пор, пока в нем не возникнет необходимость. [1]
Системный проект строится на основе модели как должно быть и результатов обследования предприятия в части выявления требований к будущей системе. [2]
В основу системного проекта должен быть положен учет динамики развития основных и дополнительных функций автоматизированной системы на различных этапах ее существования. Такой подход позволяет отодвинуть сроки старения системы и предусмотреть возможность естественного включения в новые системы ранее существовавших систем в качестве подсистем. [4]
Таким образом, системный проект содержит функциональную, информационную и, возможно, событийную модели требований к будущей системе. Виды и последовательность работ при построении этих моделей требований аналогичны соответствующим работам по построению моделей деятельности. Дополнительно системный проект включает в себя техническое задание на создание автоматизированной системы. [5]
На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: Как ( каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям. [8]
По завершении данного этапа ( после согласования системного проекта с заказчиком) изменяется роль консультанта. Отныне он становится на сторону заказчика, одной из его основных функций на всех последующих этапах работ будет контроль на соответствие требованиям, зафиксированным в системном проекте. [10]
Кто такой системный архитектор
— Почему я здесь?
— Твоя жизнь — это сумма остатков неуравновешенного уравнения, свойственного программированию Матрицы. Ты — возможный результат аномалии, которую, несмотря на мои искренние усилия, мне не удалось устранить из того, что в противном случае было бы гармонией математической точности.
Мир развивается. Прогресс не стоит на месте. То, что когда-то казалось фантастикой, сейчас становится обыденностью. Всё стремится к технологической сингулярности, совершенству и удобству — минимум действий, максимум возможностей. Это неспроста, ведь вычислительные платформы усложняются и множатся, возникают новые инструменты для преодоления тех или иных проблем и задач. И так сложилось, что сегодня любое крупное или не очень цифровое решение является сложной структурой, которая разработана под конкретные запросы и требования заказчика. Потому, чтобы не было проблем, а проект отработан четко, нужны люди с соответствующей квалификацией. А значит, сегодня мы поговорим за профессию 21 века — системного архитектора. Работа, связанная с проектированием IT-инфраструктуры информационных систем, высоко ценится на рынке труда. Ведь условия в нашем быстро меняющемся мире таковы, что цифровые нововведения становятся все более и более распространенными, они внедряются не только на корпоративном уровне, но и банально, даже в обычном быту. Следовательно, появляется необходимость в специалистах, которые могут проанализировать все процессы использования цифровых технологий на разных уровнях и создать единую архитектуру организации.
А в чём заключается работа IT-архитектора?
Множество вещей предстоит сделать системному архитектору во время работы над проектом, но большинство из них определяются надобностью в данный момент, сложностью самого проекта и, конечно же, квалификацией самого архитектора, но даже из довольно массивного перечня задач можно выделить основные:
Олег Филимошин — архитектор Timeweb Cloud
По своей сути, выражаясь художественно, системные архитекторы — это первокрасные кардиологи-хирурги от мира IT, проводя высококлассные операции на «сердце» IT-инфраструктуры. Потому, крупный бизнес, чья инфраструктура построена на взаимодействии между технологическими элементами, не выжила бы в столь суровом мире цифровых технологий.
Какие знания будут полезны системному архитектору?
Требования к кандидатам на должность инженера проекта довольно высокие, что уже можно понять по сфере деятельности данной профессии. Есть ряд обязательных и желательных навыков, которыми должен обладать человек, претендующий на это место. Рассмотрим самые важные аспекты.
Одного знания языков программирования недостаточно, поскольку главное требование —иметь практический опыт, то есть напрямую участвовать в разработке. В вакансиях вы часто увидите такие требования:
К часто требуемым навыкам еще можно отнести качества общего характера, то есть умение отстаивать свою точку зрения, настаивать на решениях, защищать позицию и искать компромиссы между сторонами.
Каким образом можно попасть на должность системного архитектора?
Добро пожаловать в профессию
Высшее образование в нынешнее время не во всех ситуациях является определяющим требованием, но специальное техническое точно может оказаться полезным. Больше всего внимание обращают именно на практические умения и понимание работы в целом. Очень часто компании выбирают на эту должность именно тех сотрудников, которые имеют опыт работы с подобными проектами. Или вовсе повышают сотрудников, которые уже работает в данной компании, так как им проще будет руководить, опираясь на уже имеющиеся знания о проекте.
Существует ли на этой должности «карьерная лестница»?
В рамках самой работы главным инженером проекта может только возрастать объёмность и сложность проектов, а соответственно и оплата. Но сама по себе подобная работа позволяет набрать достаточно опыта в любом направлении, которое будет интересно, за счёт того, что приходится следить и организовывать совместную работу многих отделов проекта, попутно в ней участвуя. Набрав нужных знаний и получив достаточно навыков можно выбрать любое направление в IT сфере и развиваться в нём дальше.
Сколько зарабатывают системные архитекторы?
Это вопрос, который наверняка волнует любого человека, ведь сама по себе работа весьма непростая, а значит и заработная плата должна быть соизмеримой. На следующем скриншоте вы видите выдачу четырех последних загруженных вакансий на Headhunter по Москве. Если же самому заглянуть на сайт, то вряд ли вы найдёте зарплату меньше 150 тыс. р., а основная масса компаний предлагает зарплату в районе 300-400 тысяч. Немногие вакансии в IT сфере могут так же хорошо оплачиваться, как системный архитектор.
Сравнить, допустим, можно с PHP-разработчиком, чья оплата труда в среднм составляет 150-200 тыс. рублей. Как другой пример можно взять должность технического директора,
также посмотрев вакансии по Москве, чья зарплата начинается от 5 тыс. долларов, но которая относится к высшему менджменту и требует участия во всех до единого технических процессах.
Откликаются на эти вакансии не так много соискателей, в некоторых случаях можно вполне себе оказаться первым, и всё потому, что у многие разработчики не имеют достаточного опыта и навыков, чтобы к тому же быть ещё и человеком, понимающем в бизнесе. Опытных архитекторов тоже не хватает, для того, чтобы была сильная конкуренция на данную вакансию.
Вместо заключения
Системный архитектор — это один из самых важных участников IT-инфраструктуры, отвечающий за большое количество технических процессов. Без его организационной работы зачастую не представляется возможным довести проект за конца.
Для этой работы вы должны уметь работать в рамках всех других должностей. Тяжёлые проекты позволяют быстрее построить свою карьеру, но зачастую излишне напряжённая работа приводит к выгоранию.
Если устали работать руками, «нажимая кнопки» и готовы взвалить на себя ответственность за себя и того парня, то это то, что вам нужно. Это работа неплохо нагружает «технический склад ума», а также позволяет проявить творческий подход к проекту, общаясь с профессионалами и большими начальниками, а то и мир спасая от какого-нибудь техно-краха. Если всё это вам близко и подходит, дерзайте. Проявляйте инициативу, развивайте кругозор и интересуйтесь «железом» во всех его проявлениях и смыслах. Ведь за вычислительными системами — весь современный мир и будущее!
«Вместо заключения» — Задачи и понимание должности системного архитектора отличается от компании к компании. Узнать, какие задачи выполняет архитектор в Timeweb и чем это отличается от CTO и тимлида можно в новом выпуске подкаста:
О роли системного аналитика и шаблон для проектирования
Сейчас нужно написать краткое введение о том, что важно проводить аналитику для задачи на разработку: оценить влияние изменений, проработать все возможные сценарии и т.д.
Понимание сути и объема задачи должно появиться до первой строки кода. Писать сколь угодно емкое введение о важности этого этапа можно долго, но кажется, что все мы понимаем, что самые дорогие ошибки — на этапе проектирования.
Разработчику с проектированием и документированием решения задачи помогает аналитик.
Аналитики бывают двух видов:
Бизнес-аналитик — понимает заказчика, его бизнес, пользователей, творчески мыслит. Он приносит задачу в команду на уровне «Наш бизнес (или пользователи) хочет такое вот волшебство: в двух словах рассказываю, все понятно, делаем!». Бизнес-аналитик отвечает за ожидания и потребности пользователей, за вид ПО снаружи.
Системный аналитик — как правило, встречает бизнес-аналитика (если сам им не является) / заказчика / владельца продукта, получает «несколько строк на человекочитаемом» описания задачи, BPMN-диаграммы дедлайн. Он принимает задачу: оценивает изменения, анализирует влияние на подсистемы, модель данных, расписывает алгоритмы и вот это вот все.
Системный аналитик отвечает за внутренности, о которых пользователям лучше вообще не знать и не думать.
Задача системного аналитика — спроектировать решение «от и до»:
Проработать пользовательские и системные сценарии, алгоритмы, реакцию на действия пользователя, обработать все возможные «а что может пойти не так»,
Определить связи между подсистемами, влияние на них,
Декомпозировать задачу, если она большая,
Описать изменения в модели данных.
Продумать требования к UI/UX.
В процессе проектирования с командой разработки обсуждаются варианты технической реализации. Системным аналитиком создаются UML-диаграммы, ER-диаграммы, схемы обмена данными, последовательности передачи управления. В общем всё, что происходит внутри — зона ответственности системного аналитика.
Кстати, иногда пользователем системы может быть другая система.
У нас в компании есть команды, которые отвечают за развитие отдельных частей МоегоСклада.
Если в процессе разработки не будет понимания, как очередные изменения повлияют на продукт в целом, на отдельные его части, то мы будем страдать и, возможно, расти со скоростью мертвой черепахи, ловя ошибки и ломая всё на своем пути.
А хочется быть лучше, качественнее, делать процесс разработки осознанным и управляемым.
Причины появления системного аналитика
Системным анализом в команде могут заниматься разработчики самостоятельно. Основные причины, которые приводят к решению искать выделенных специалистов:
Разработчики хотят писать код, а не анализировать систему. Но все же хорошо и правильно, когда их подключают к этому процессу.
Разработчики не готовы описывать результат анализа на человеческом языке. Они готовы только запрограммировать и показать готовое решение. Такой подход не всегда оптимален, потому что решение может оказаться неудовлетворительным для поставщика требований. А с ним оно должно быть согласовано.
По итогам разработки остается только код. Разработчики не любят документировать, это не их задача.
Что делает системный аналитик?
Получив задачу в работу, системный аналитик представляет, как это вообще должно работать. Если ассоциировать систему с домом, то можно сказать, что он описывает, как построить дом или вставить кирпич в готовый так, чтобы сделать его больше и лучше. По сути аналитик, проектируя систему, делает архитектурный проект.
Чтобы построить здание, нужно понимать, для чего оно нужно: кто в нем будет жить и как им будут пользоваться, какой вид оно должно иметь, какие функции выполнять.
В идеальном случае системный аналитик оставляет в качестве результата работы документ, описывающий модель будущей системы или ее части.
Шаблон для проектирования поможет получить результат
От системного аналитика требуется описание модели ровно в том объеме, в котором его хочет получить заказчик.
Проект дома — понятие широкое, в него может быть вложено абсолютно разное наполнение: от дизайна комнат до высоты фундамента и толщины стен. Бизнес-заказчику обычно важно только то, что видит пользователь, а вот госзаказчику описание подавай по ГОСТу. Все разные.
В МоемСкладе — свой продукт. Нам важно понимать, какие возможности он реализует, какое поведение можно ожидать от системы, как обеспечена реализация в коде, как представлены объекты в модели данных.
У нас внедрен шаблон документации, который системные аналитики и другие участники команд наполняют в процессе проектирования и описания решения задачи.
Наш шаблон состоит из перечисленных далее блоков. Он помогает описывать, как встраивать новые кирпичики в «большое здание МоегоСклада».
Общее описание. Фото здания снаружи
В этом разделе мы описываем, что это за функциональность, для чего и для кого она предназначена. Кратко формулируем описание работы и какой результат нужно ожидать в идеальном случае.
Если необходимо, то обозначаются особенности работы, которые точно вызовут вопросы в процессе реализации и тестирования — все «потому что так задумано».
Влияние и связи. Не заденем ли мы при строительстве ель и баню, которые тут уже стояли?
В этом блоке в шаблоне автоматически подставляется полный список подсистем продукта и подсказки по функциональности, которая в них входит. Аналитику нужно заполнить его, чтобы проверить, что он точно всё учел, показать, с чем связана доработка.
Заполняя этот блок, системный аналитик оценивает влияние изменений на весь продукт в целом и ищет части, которые могут быть задеты.
Так, например, изменения в пользовательском UI основного приложения могут повлиять на наш публичный API и мобильные клиенты. Другим командам нужно будет своевременно сообщить о необходимости доработок.
Описание функциональности и основные сценарии. Список помещений и способы их использования
Системный аналитик прорабатывает:
Пользовательские сценарии, алгоритмы обработки данных и поведение системы.
Требования к передаче управления между подсистемами.
Влияние исходного состояния системы на результаты выполнения задач.
Результаты своей творческой деятельности он должен описать в этом разделе, согласовать с владельцем продукта и продемонстрировать команде разработки.
Описание может включать UML- и BPMN-диаграммы, блок-схемы, диаграммы состояний, текстовое описание поведения, макеты экранов. Всё, что может помочь разобраться в том, как система должна работать: все решения по алгоритмам, основным сценариям и способам обработки ошибок.
Этот блок является основным, так как описывает модель поведения системы: ее реакцию на действия пользователя и внешние события.
Доступы и ограничения или просто ролевая модель. Кто может войти в здание
В системе есть администратор и обычный пользователь, оплаченный аккаунт и бесплатный, сотрудник с доступом к отчетам и без, пользователи основного приложения и кассового. Здесь нужно описать, кто будет допущен к использованию функциональности.
Если в шаблоне проектирования внедряется этот блок, то его лучше сразу наполнять заглушками по полному набору ролей пользователей, чтобы системный аналитик не упустил ничего.
Описание UI/UX. Дизайн-проект здания
Здесь важно не просто рассказать про то, что «пользователь видит на экране форму документа» и прикрепить макет, а подробно описать:
Поля ввода, селекторы, тексты подсказок, кнопки и вообще все элементы, которые должны быть отображены на экране для каких состояний.
Описать требования к валидации данных со стороны клиентского приложения (то, что проверяется без отправки запроса в сеть): ограничения на ввод, допустимые символы, значения для селекторов, какие проверки инициируются нажатием на кнопки, можно ли выделить текст на экране и т.п.
Для кнопок и других элементов описываются требования к отправке запросов на сервер и реакция на их нажатие.
В идеале здесь стоит описать, как данные на экране связаны с БД.
Если к моменту начала разработки есть макет от дизайнера — прекрасно! Если нет, то системный аналитик должен уметь сделать макеты, поставить задачку дизайнеру, который сделает всё удобно и красиво.
Для наглядности показываю нашу заглушку.
P.S. Хранить скрины и макеты в будущей документации не всегда хорошо. Они частенько теряют актуальность
Техническая реализация. Описание фундамента и инженерки
Самое интересное происходит здесь!
Требования к технической реализации можно описывать только после того, как модель поведения системы полностью проработана и согласована со всеми заинтересованными лицами. Их аналитику помогают собирать разработчики и архитекторы. Опытные аналитики могут проектировать эту часть самостоятельно.
Нужно проанализировать и описать:
Список подсистем, которые будут реализовывать функциональность и процесс обмена данными между ними.
Изменения в модели данных.
Требования к алгоритмам обработки данных, работе с CRUD-моделью. Другие особенности реализации.
Техническая реализация — это последняя стадия проектирования перед написанием кода. Она может быть описана поверхностно, и доделывать ее нужно только после написания кода.
Блок используется для сохранения знаний об особенностях реализации и помогает быстро понять, как работает функциональность без доступа к коду.
Логирование и метрики. Как монтировать камеры видеонаблюдения и систему охраны
Мы анализируем работу нашего продукта: собираем метрики, все логируем. На этапе проектирования закладываются отдельные требования в этой части, а по итогам реализации описание дополняется для документации.
Другие блоки
В зависимости от того, какая часть МоегоСклада описывается, могут быть блоки:
Работа ПО в оффлайн-режиме — особенности поведения в отсутствии сети для касс и мобильных приложений.
Программно-аппаратные интеграции для касс.
Подытожим
Системным анализом для разработки ПО может заниматься как выделенный специалист, так и любой из участников команды.
Для описания модели системы рекомендую использовать шаблон проектирования, который после релиза превращается в документацию с описанием работы, если в процессе реализации он добросовестно актуализируется и уточняется командой.
Моделируя систему, определитесь с тем, кто будет потреблять документированную информацию как на этапе разработки, так и в будущем, какие знания важно сохранить по итогам реализации на «электронной бумаге».
Строить дом без плана — странно. Может получиться избушка на курьих ножках, куча дров в результате дуновения ветра или недостроенное нечто.
С программным обеспечением — аналогично. Если заранее не проработать требования к реализации и не описать модель, то в результате разработки может получиться набор костылей, который будет раз за разом переписываться. Его будет сложно тестировать.
Нет модели — нет ожидаемого поведения системы.
Проектируйте, и в процесс вашей разработки придет порядок!