Введение в профессию бизнес-аналитика. Отправная точка для приобретения опыта бесплатное чтение

Менеджер проекта (Project manager)

Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Менеджер релизов – в реалиях российских Enterprise-компаний так называются руководители команд, управляющие процессом, когда IT-продукт из проекта уже превратился в сервис, но находится на доработке согласно запросам на изменения (ЗИ).

Менеджер продукта (Product manager)

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

Эти роли различаются тем, что product manager придумывает новые функции, которые можно добавить в продукт, а project manager ставит задачу подчиненным реализовать эти новые функции и сообщает о сроках, когда они будут готовы. Product manager решает, что сделать, project manager – когда и как.

Архитектор (Architect)

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

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

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

Бизнес-архитектура (Business Architecture) описывает все бизнес-процессы, бизнес-акторы, бизнес-сущности и бизнес-правила с точки зрения бизнеса. Бизнес-архитектура не зависит от применяемых в разработке технологий.

Информационная архитектура (Information Architecture) определяет структуры данных и описывает все потоки данных, которые используются для поддержки бизнес-архитектуры. Такие операции, как идентификация, систематизация, категоризация, хранение данных, относятся к информационной архитектуре. Может представляться в виде модели данных (Data Model).

Архитектура решения (Solution Architecture) – архитектура программного обеспечения (ПО), которое реализует функции бизнес-архитектуры.

Технологическая архитектура (Technology Architecture) описывает архитектуру IT-окружения, которое используется для поддержки информационной архитектуры и архитектуры решения.

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

Архитектура ПО (Application Architecture) – составная часть системной архитектуры. Описывает организацию системы с точки зрения программных компонентов, из которых она состоит, и связи между компонентами.

Архитектура данных (Data Architecture) – составная часть системной архитектуры. Описывает структуры данных и логические связи между ними.

Каждым из видов архитектуры занимается соответствующий архитектор.

Бизнес-архитектор (Enterprise Architect) отвечает за то, чтобы бизнес-стратегия компании использовала правильную архитектуру технологических систем для достижения своих целей. EA несут огромную ответственность и, как правило, подчиняются непосредственно директору по информационным технологиям (CIO). Они должны идти в ногу с последними тенденциями в технологиях и определять, подходят ли технологии для компании. EA берет бизнес-стратегию компании и описывает архитектуру технологических систем, которая будет необходима для поддержания этой стратегии. Архитекторы уровня enterprise ориентируются на бизнес-потребности, придумывают, как решить какую-либо бизнес-задачу, разрабатывают глобальный план работы приложения и алгоритм его взаимодействия с другими. EA должен представлять, как все приложения работают вместе, иметь всю информацию. Он принимает концептуальные решения.

Архитектор решений (Solution Architect). Если EA решает, что делать, то SA – как делать.

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

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

• какую платформу или стек технологий можно использовать для создания решения;

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

• как вещи будут масштабироваться и поддерживаться.

Архитектор решений часто работает под методическим руководством бизнес-архитектора.

Technical (software) Architect – техлид в обычных реалиях. Это технический эксперт, который пытается решать проблемы, поставленные SA-архитектором. TA ставит задачи разработчикам и занимается уровнем реализации конкретной системы. На уровне конкретной информационной системы определяет стек технологий этой системы, сервисы, подходы к разработке, выбирает БД и интерфейсы для взаимодействий с другими системами.

Аналитик (Analyst)

Бизнес-аналитик (Business Analyst) описывает бизнес-процессы, как они есть (as is), и, общаясь с заказчиком и заинтересованными сторонами, составляет предложение, какими они должны быть (to be), чтобы решить задачи бизнеса (достичь целей).

Бизнес-аналитик фиксирует бизнес-требования и их решения по реализации в виде бизнес-процессов. При этом может рисовать схемы бизнес-процессов, писать use case – бизнес-сценарии, которые необходимо проверять при приемке решения. Бизнес-аналитик выбирает любой способ фиксирования результатов своей деятельности и передает эту информацию системным аналитикам каждой из систем, которые участвуют в реализации решения. Они составляют свои документы.

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

Продуктовый аналитик (Product Analyst) – мостик между бизнесом и данными. Он работает рука об руку с менеджером продукта и помогает продуктовой команде принимать верные решения.

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

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

На втором этапе аналитик вытаскивает из цифр инсайды, которые проливают свет на поведение пользователей. Благодаря этому продуктовая команда понимает, какой продукт она сделала и куда двигаться дальше.

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

Дизайнер (Designer)

User Experience (UX) – это путь клиента от точки входа до точки выхода. То, насколько клиенту удобно, например, заполнить на сайте заявку на кредит. Отвечает за функциональность.

User Interface (UI) – это вид интерфейса. Отвечает за статику.

UX-дизайнер – это проектировщик, который изучает потребности пользователей, строит логические схемы работы интерфейса, тестирует прототипы на целевой аудитории и составляет ТЗ для UI-дизайнера.

UI-дизайнер определяет цветовую палитру, располагает объекты в интерфейсе так, чтобы он был удобным и понятным. Визуализирует рабочий прототип, отрисовывает кнопки, формы и другие компоненты. На выходе мы получаем макет.

Специалист по информационной безопасности (Application security)

Анализирует приложение с точки зрения информационной безопасности: определяет требования к приложениям и проверяет реализацию на соответствие этим требованиям. Занимается поиском и анализом уязвимостей.

Разработчик (Developer)

Если говорить о веб-приложении, frontend-разработчик занимается клиентской стороной интерфейса, отвечает за вывод информации для пользователя. Backend-разработчик занят серверной разработкой – тем, чего не видит пользователь, реализацией бизнес-логики приложения. Fullstack – человек, который объединяет в себе обязанности front и back (они тесно связаны).

Пример

Вы выбираете рейс из Нью-Йорка в Гонконг. Вы находитесь в зоне frontend. Нажмите клавишу поиска, и вы переместитесь в зону backend, чтобы вам могли правильно вернуть лучший, самый короткий и дешевый рейс в мгновение ока. Как только отобразятся результаты, вы снова окажетесь в зоне frontend.

Отдельно выделены gamedev-разработчики (разработчики игр) и iOS/Android-разработчики – группы разработчиков под эти ОС.

1С/SAP-разработчики и так далее – разработчики на определенном коробочном решении. Такие решения закупаются фирмой и дорабатываются под ее нужды, здесь имеются специализированный язык и свои инструменты.

Тестировщик (QA Engineer)

Есть несколько видов тестирования. Соответственно, разные его виды выполняют разные тестировщики.

➤ По отношению к объекту тестирования.

1. Функциональное. Тестирование конкретной функциональности, которая была разработана в соответствии с требованиями.

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

3. Производительности. Стресс-тестирование, тестирование нагрузки, стабильности.

➤ По доступу к коду.

1. Тестирование черного ящика в том случае, когда мы не знаем алгоритмы.

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

3. Тестирование серого ящика – комбинация первого и второго.

➤ По степени автоматизации.

1. Ручное – тест-кейсы.

2. Автотестирование – специально написанный код для автоматизации проверки определенного кейса.

➤ По степени изолированности компонента

1. Модульное – тестирование определенных модулей системы (компонентов).

2. Интеграционное – тестирование взаимодействия модулей.

3. Тестирование системы в целом (полной системы).

Техническая поддержка (Tech Support)

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

Level 1/2/3 support – несколько уровней поддержки приложения по степени знания системы.

На этом этапе обеспечивается общая техническая поддержка, в рамках которой обрабатываются типовые обращения. Цель создания такой службы – обеспечение постоянной поддержки пользователей на определенном уровне. Значительное число входящих вопросов решается на первой линии.

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

Level 2 support – это технические специалисты с более продвинутыми навыками общего или специализированного назначения. Тут происходит систематизация, анализ и решение проблем.

Обязанности специалистов второго уровня:

• контакт с персоналом первой линии и помощь ему;

• фиксация и последующий анализ инцидента;

• решение проблемы;

• передача данных по решенной проблеме на первый уровень.

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

Level 3 support – это обычно команда разработки, которая лучше всех знает продукт и может помочь в решении проблемы.

Жизненный цикл ПО (SDLC, Software Development Life Cycle) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

SDLC – это основные этапы, через которые проходит любой программный продукт. Плюс-минус всегда имеют место следующие этапы.

1. Фаза планирования.

2. Фаза сбора требований/анализа.

3. Фаза дизайна/проектирования.

4. Фаза разработки.

5. Фаза тестирования.

6. Фаза внедрения.

7. Фаза поддержки.

ЖЦ продукта начинается с идеи. После того как мы решили создавать новый продукт, мы приступаем к фазе планирования: прорабатываем идею, пишем бизнес-план, проводим анализ конкурентов, рассчитываем предполагаемую прибыль. Далее запускается сам проект по реализации продукта, если руководство решит, что оно того стоит.

После завершения проекта получается продукт, и начинается операционная деятельность по работе с этим продуктом. И далее, если продукт требует изменений, то строится новый бизнес-план и запускается новый проект.

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

Поэтому хотелось бы отметить, что для продукта и проекта этапы ЖЦ могут отличаться. Это стоит понимать и учитывать.

Жизненный цикл проекта

Любой ЖЦ проекта включает в себя четыре фазы.

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

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

3. Выполнение работ. Это фаза создания проекта. Именно на этом этапе создается продукт. Менеджер проекта получает отчеты о ходе выполнения проекта и контролирует процесс. Далее происходит финальное одобрение продукта перед подписанием акта приема работ.

4. Финальная стадия. Основная суть этой фазы – подвести итоги после завершения проекта, подписать акт приема-передачи и передать продукт в операционную деятельность.

На графике показано, как в зависимости от стадии проекта меняются такие показатели, как:

• стоимость проекта и численность персоналом – вовлеченность ресурсов (кривая 1);

• влияние заинтересованных сторон, неопределенность проекта, возможность рисков (кривая 2);

• стоимость изменений по проекту (кривая 3).

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

Пример

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

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

Этап планирования

На этой стадии нужно максимально снизить неопределенность.

Фаза планирования – наиболее критичный этап в создании успешной системы. Во время нее вы точно решаете, что хотите сделать и какие проблемы решить. Для этого вам необходимо:

• определить проблемы, цели, задачи и ресурсы (такие, как персонал и издержки – важно заранее найти людей, которые в дальнейшем будут работать с проектом, и включить их в проектную команду; инфраструктурные ресурсы);

• рассмотреть варианты альтернативных решений на встречах с клиентами, поставщиками, консультантами и сотрудниками;

• понять, как сделать ваш продукт лучше, чем у конкурентов;

• провести анализ осуществимости (feasibility study), направленный на изучение возможности создания продукта в соответствии с заданными требованиями заказчика и выделенными ресурсами.

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

Результатом разработки концепции является Product Vision Document (если продукт разрабатывается под заказ) или Marketing Requirement Document (если продукт предназначен для открытого рынка). Эти документы содержат подробную информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять эти требования, а также ориентировочные сроки его реализации и бюджет. Различие между PVD и MRD состоит в том, что в MRD обычно более детально описаны целевые сегменты рынка и сделан детальный обзор конкурентов.

После разработки концепции продукта делается вывод о целесообразности создания продукта. Если принято положительное решение, пишется устав проекта по разработке продукта. PVD/MRD – входной документ устава проекта, описывающий содержание работ.

Входы: идея, концепция, экономическое обоснование.

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

Этап анализа требований

На этом этапе нужно четко определить и задокументировать требования к продукту и утвердить их.

Входы: реестр заинтересованных лиц, дорожная карта.

Выходы: техническое задание.

Этап проектирования

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

Входы: техническое задание.

Выходы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Этап разработки

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

Входы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Выходы: работающая версия ПО, готовая к тестам.

Этап тестирования

На этом этапе проверяется работоспособность системы.

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

Входы: тест-кейсы, версия ПО.

Выходы: отчет о тестировании, баг-репорты.

Этап внедрения и поддержки

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

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

Входы:

• консультирование пользователей;

• исправление дефектов;

• доработка в соответствии с новыми требованиями.

Выходы:

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

• пользовательская документация.

Стандарты жизненного цикла ПО

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

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

➤ Процессы соглашения

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

➤ Процессы организационного обеспечения проекта

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

Процессы организационного обеспечения проекта:

• процесс менеджмента модели жизненного цикла;

• процесс менеджмента инфраструктуры;

• процесс менеджмента портфеля проектов;

• процесс менеджмента людских ресурсов;

• процесс менеджмента качества.

➤ Процессы проекта

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

Существуют две категории процессов проекта.

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

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

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

• планирование проекта;

• управление проектом и его оценка.

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

• менеджмент решений;

• менеджмент рисков;

• менеджмент конфигурации;

• менеджмент информации;

• измерения.

➤ Технические процессы

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

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

Технические процессы:

• определение требований правообладателей;

• анализ системных требований;

• проектирование архитектуры системы;

• реализация;

• комплексирование системы;

• квалификационное тестирование системы;

• инсталляция программных средств;

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

• функционирование программных средств;

• сопровождение программных средств;

• изъятие программных средств из обращения.

➤ Процессы реализации программных средств

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

➤ Процессы поддержки программных средств

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

➤ Процессы повторного применения программных средств

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

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

• Не детализирует процессы жизненного цикла в разрезе методов и процедур.

• Не устанавливает требований к документации.

• Не предписывает четких и однозначных схем построения жизненного цикла ПО.

• Не предписывает использование конкретной модели жизненного цикла, методологии, методов, моделей или технических приемов.

Каждая организация сама несет ответственность за выбор!

Стандарт предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

1. Формирование требований к АС:

a. Обследование объекта и обоснование необходимости создания АС;

b. Формирование требований пользователя к АС;

c. Оформление отчета о выполнении работ и заявки на разработку АС.

2. Разработка концепции АС:

a. Изучение объекта;

b. Проведение необходимых научно-исследовательских работ;

c. Разработка вариантов концепции АС и выбор варианта, удовлетворяющего требованиям пользователей;

d. Оформление отчета о проделанной работе.

3. Техническое задание:

a. Разработка и утверждение технического задания на создание АС.

4. Эскизный проект:

a. Разработка предварительных проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части.

5. Технический проект:

a. Разработка проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части;

c. Разработка и оформление документации на поставку комплектующих изделий;

d. Разработка заданий на проектирование в смежных частях проекта.

6. Рабочая документация:

a. Разработка рабочей документации на АС и ее части;

b. Разработка и адаптация программ.

7. Ввод в действие:

a. Подготовка объекта автоматизации;

b. Подготовка персонала;

c. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

d. Строительно-монтажные работы;

e. Пусконаладочные работы;

f. Проведение предварительных испытаний;

g. Проведение опытной эксплуатации;

h. Проведение приемочных испытаний.

8. Тестирование АС.

9. Сопровождение АС:

a. Выполнение работ в соответствии с гарантийными обязательствами;

b. Послегарантийное обслуживание.

Эскизный, технический проекты и рабочая документация – это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

Классические модели разработки

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

1. Постановка задачи.

2. Создание программы.

3. Тестирование.

4. Анализ результатов тестирования и возможный переход к шагу 1.

Эта модель совсем не актуальна для профессиональной разработки ПО. По таким алгоритмам программисты работали 50–60 лет назад. Излишняя простота в этом случае не позволяет конкурировать с другими моделями.

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

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

1. Сбор требований. Собираются требования к продукту, который надо разработать (определяем требования заказчика).

2. Анализ требований. Требования анализируются, детализируются, уточняются, обсуждаются, документируются (формируем требования к ПО).

3. Проектирование. Проектируются и согласовываются логика работы ПО и требования к дизайну; выбираются инструменты разработки. На выходе получаем документы, подробно описывающие для программистов способ и план реализации указанных требований.

4. Разработка. Реализация.

5. Тестирование. Проверка.

6. Внедрение, поддержка. Вывод в промышленную эксплуатацию и перевод на поддержку.

Когда можно использовать каскадную модель:

• для средних и больших проектов, в которых задействованы десятки программистов и несколько разных команд проекта;

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

«Водопад» подходит для разработки проектов в медицинской и космической отраслях, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.

Любая стройка – это пример использования «Водопада» (кейс – проект – стройка – приемка). Также в качестве примера подходит автомобильный конвейер.

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

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

Расширяет стандартную модель, добавляя в нее циклы обратной связи для возврата на предыдущую стадию при изменении требований, для пересмотра отдельных вопросов или исправления ошибок.

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

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

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

Модель обладает следующими характеристиками взаимодействия этапов:

• модель состоит из последовательно расположенных этапов (точно так же, как и «Водопад»);

• каждый этап имеет обратную связь с предыдущими;

• исправление ошибок происходит на каждом из этапов сразу при выявлении проблемы – производится промежуточный контроль;

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

• результат появляется только в конце разработки, как и в модели «Водопад».

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

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

Мы получаем несколько циклов разработки – своеобразный «мультиводопад». Каждый цикл делится на модули, а каждый модуль – на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

Когда можно использовать инкрементную модель:

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

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

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

Когда можно использовать итеративную модель:

• когда важен анализ рисков и затрат;

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

• при разработке новой линейки продуктов.

На рисунке показана итерационная «разработка» Моны Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй появляются цвета, в третьей добавляются детали и насыщенность, и процесс завершается. В инкрементной же модели функционал продукта наращивается по кусочкам, и продукт составляется из частей. В отличие от итерационной модели, здесь каждый кусочек – целостный элемент.

Еще она называется Verification and Validation model – модель верификации и валидации. Это усовершенствованная каскадная модель, в которой заказчик и команда программистов одновременно составляют требования к системе и описывают, как будут тестировать ее на каждом этапе. V-модель разработки унаследовала структуру «шаг за шагом» от каскадной модели.

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

Ее начали использовать в 1988 году. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее включен анализ рисков и предусмотрена разработка проекта посредством прототипирования.

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

Главные фазы:

1. определение целей, альтернатив, ограничений;

2. анализ, определение и разрешение рисков;

3. фаза разработки и тестирования;

4. планирование новой итерации.

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

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