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

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

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

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

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

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

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

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

Основные артефакты программирования:

1. Архитектурное описание — описание построения архитектуры программы и интеграции.

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

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

4. Исполняемые файлы — это результат компиляции исходного кода, который содержат исполняемый код и который может быть запущен на персональном компьютере. Они могут быть в формате *exe–файлов (для Windows), *app–файлов (для MacOS) или других форматов, в зависимости от предназначенной операционной системы.

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

6. Документация. Различные артефакты, представленные в виде документации, в которых описывается функциональность программы, её использование, Application Programming Interface (API), инструкция администратора, инструкция пользователя и другую информацию, которая помогает разработчикам и пользователям понять, как правильно использовать программу.

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

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

В план аналитики могут входить следующие задачи:

• Изучение материалов;

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

• Определить бизнес–требования;

• Определить классы пользователей;

• Определить представителей пользователей;

• Определите лица, ответственные за принятие решений по требованиям;

• Спланировать выявление требований (подготовка (определение границ, подготовка вопросов), выявление требований, действия после выявления требований);

• Определить пользовательские требования;

• Определить приоритеты пользовательских требований;

• Сформулировать пользовательские требования (описать цели и задачи, которые пользователи должны иметь возможность выполнить с помощью ПО. Что пользователь должен иметь возможность делать с системой — варианты использования, пользовательские истории);

• Вывести функциональные требования (каким должно быть поведение системы в том или ином случае. Что разработчики должны сделать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес–требовании — ТЗ);

• Смоделировать требования (моделирование необходимо, чтобы обеспечить более высокий уровень понимания, чем это дает ТЗ);

• Определить атрибуты качества;

• Разработать прототипы;

• Разработать или расширить архитектуру;

• Распределить требования по компонентам;

• Разработать тесты на основе требований;

• Разработать план коммуникации аналитиков с командой.

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

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

В концепцию и границы проекта могут входить следующие разделы:

• Основные термины и определения документа

• Входные данные (описание Заказчика — общие сведения, цели и задачи)

• О проекте — описание, обоснование, цели и задачи проекта, допущения, ограничения, риски проекта, требования к проектной документации

• Концепция продукта — цели и задачи, планы по развитию, пользователи продукта (описание пользователей, цели и задачи их, основные пользовательские сценарии)

• Границы проекта (что входит, а что не входит)

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

• Верхнеуровневая архитектура продукта

• Версия продукта

• Требования к документации

• Критерии оценки результатов проекта

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

3. Реестр требований. Документ, в котором собраны все требования. Табличка со столбцами: описание требования, автор, дата выявления, документ выявления, статус требования, спецификация, дата реализации, дата приемки и т.п.

При этом источниками требований могут быть: пользователи, заказчики, фокус–группы, команда, стандарты.

Данный документ является основой для матрицы трассировки требований.

4. Матрица трассировки требований — инструмент для управления требованиями, матрица связей требований. Требования связаны между собой и могут претерпевать изменения.

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

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

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

Техническое задание может содержать следующие разделы:

1.) Введение

1.1.) Назначение (номер выпуска продукта, название, к какой части системы относится и т.д.).

1.2.) Соглашения, принятые в документе (стандарты и типографические соглашения).

1.3.) Граница проекта (краткое описание ПО и его назначения, связь с корпоративными целями).

1.4.) Ссылки (другие ресурсы, стандарты и так далее).

2.) Общее описание

2.1.) Общий взгляд на продукт (контекст и происхождение продукта, это новая система или замена старой, соотношение с другими системами – модели экокарта или контекстная диаграмма IDEF0).

2.2.) Классы и характеристики пользователей (описание классов и характеристик пользователей).

2.3.) Операционная среда (рабочая среда, в которой будет работать система; другие ПО, с которыми будет взаимодействовать система)

2.4.) Ограничения дизайна и реализации (опционально: например, язык программирования).

2.5.) Предположения и зависимости (например, нужно установить Net Framework 4.5 или выше).

3.) Функции системы

3.1.) Функция системы Х.

3.1.1.) Описание Х (краткое описание функции, ее приоритет).

3.1.2.) Функциональные требования (по пунктам, все функциональные требования, связанные с данной функцией; реакция продукта на ожидаемые ошибки; функциональным требованиям можно сопоставить атрибуты, например, основание, источник, состояние).

4.) Требования к данным

4.1.) Логическая модель данных (визуальное представление объектов и наборов данных, которые обрабатывает система, а также отношения между этими данными; используется ERD и UML).

4.2.) Словарь данных (определяет структуру данных, их тип, длину, формат и т.д.).

4.3.) Отчеты (если система будет генерировать отчеты, то тут их характеристики; логическое описание и желательно пример).

4.4.) Получение, целостность, хранение и утилизация данных (если важно, описать, как система получает и обрабатывает данные; требования к целостности данных; как система должна поступать с локальными копиями, промежуточными архивами и т.д.).

5.) Требования к внешним интерфейсам

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

5.2.) Интерфейсы ПО (связи системы с другими компонентами ПО, в т.ч. базы данных, другие приложения, библиотеки и т.д.; описание сообщении между, данных, обмен которыми происходит; службы, нужные для внешних компонентов ПО; меры и ограничения безопасности).

5.3.) Интерфейсы оборудования (характеристики каждого интерфейса между компонентами ПО и оборудования системы, если такие есть; типы поддерживаемых устройств, элементы управления ПО; входные и выходные данные, а также их форматы).

5.4.) Коммуникационные интерфейсы (электронная почта, браузер, сетевые протоколы; форматы сообщении; ограничения этих интерфейсов, например, допустимые вложения в почте).

6.) Атрибуты качества

6.1.) Удобство использования (спец. возможности, требования к удобству использования и т.д.).

6.2.) Производительность (конкретные требования к производительности).

6.3.) Безопасность (защита данных, ограничения доступа и т.д.; как правило, здесь все связано с бизнес–правилами).

6.4.) Техника безопасности (возможные потери и ущерб, соответствие сертификатам безопасности).

6.5.) Другие (возможность установки, доступность и т.д.).

7.) Требования к интернационализации и локализации (язык, законы, точки–запятые и прочее).

8.) Остальные требования

Приложение А: Словарь терминов.

Приложение Б: Модель анализа.

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

4. Модель данных: Графическое представление структуры данных и их взаимосвязей. Модель данных может быть представлена в виде диаграммы базы данных или схемы данных, которая позволяет лучше понять, как данные связаны между собой и как они могут быть использованы для анализа.

5. Отчеты и презентации: Документы или презентации, которые содержат результаты анализа и его интерпретацию. Отчеты и презентации помогают представить результаты анализа заказчикам или заинтересованным сторонам и обеспечивают понимание полученных данных и выводов.

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

Артефакты проекта и требования к программному обеспечению (ПО) тесно связаны друг с другом. Артефакты проекта являются результатом работы по разработке и управлению проектом, включая сбор, анализ и документирование требований к ПО. Вот несколько способов, как связаны артефакты проекта и требования к ПО:

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

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

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

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

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

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