Архитектура прогаммного обеспечения РОЛИ В ПРОЦЕССЕ

Архитектура прогаммного обеспечения

РОЛИ В ПРОЦЕССЕ РАЗРАБОТКИ ПО 2

Project manager PM (Менеджер проекта ) Основная задача - управление проектом в целом: ● планирование выполнения задач; ● расстановка приоритетов; ● определение требуемых ресурсов и их распределение внутри команды; ● набор сотрудников; ● разбивка продукта на компоненты и раздача их исполнителям; 3

Менеджер проекта (project manager, или PM) Основная задача - управление проектом в целом: ● взаимодействие с заказчиками и внесение корректив; ● планировать затраты времени и отпущенных на разработку средств (agreed schedule and budget); ● анализировать возможные риски (identifying and mitigating risk); ● отслеживать состояние проекта (monitoring and reporting status); ● удерживать команду в рабочем состоянии, разрешать внутренние конфликты и проблемы 4

business-process analyst (Аналитик бизнес-процессов) 1. отвечает за определение архитектуры проекта с точки зрения бизнеса заказчика; 2. определяет бизнес-прецеденты (use-cases) и потоки работ (workflow) в организации, для которой создается информационная система, и действующих в них лиц (actors); 3. документ о видении бизнеса с точки зрения внедрения создаваемого решения, бизнес- архитектура, набор бизнес-правил и модель, действующие в компании будущего пользователя; 4. аналитик должен знать область деятельности заказчика и выступает от имени заказчика; 5

Software architect (Архитектор ПО) 1. устанавливает требования как к системе в целом, так и к каждому ее отдельному компоненту, определяет дизайн решения, способы достижения цели, прикидывает развертывание готового продукта 2. уметь оценить риски, связанные с выбранными технологиями, и подготовить альтернативные варианты на случай, если вдруг что-то пойдет не так и в процессе разработки будут обнаружены серьезные препятствия; 6

Software architect (Архитектор ПО) 3. хорошо знает возможности различных технологий, их преимущества и недостатки, стыкуемость друг с другом; 4. спецификации отдельных компонентов, где определены функции создаваемого модуля , входной и выходной интерфейсы, требования к используемым технологиям, требования к документированию и минимальному тестированию, а также критерии оценки готовности компонента к приемке 7

Developer (Разработчик) 1. получает четкое задание в виде готовой спецификации (в идеальном случае) и делает по нему то, что умеет лучше всего; 2. помимо создания компонентов ПО, в обязанности, входит еще и его первичное тестирование; 3. исправление найденных ошибок. 8

Тестировщик (tester) 1. задача состоит в том, чтобы заказчик получил качественный продукт незаурядные способности по обнаружению узких мест в системе, знание подводных камней различных технологий; 2. разработка плана тестирования (test plan), наборов тестов (test suite) и тестовых случаев (test cases); 3. запуск тестовых скриптов с различными наборами тестовых данных; 4. детальное протоколирование результатов прогона тестов; 5. обнаружение и документирование ошибок (find and report bugs), и пути их воспроизведения 9

Пять уровней зрелости технологического процесса разработки ПО 10

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

Статистика Факторы повлекшие провал проекта: 1. Неполнота требований (13, 1%) 2. Неучастие пользователя в разработке требований (12, 4%) 3. Нереалистические ожидания (9, 9%) 4. Изменение требований и спецификаций (8, 7%) 5. Отпала потребность в системе (7, 5%) 12

Стоимость устранения дефекта Чем раньше найти и исправить ошибку, тем дешевле это обойдется. 13

Для чего и для кого нужны требования? Необходимость определения требований перед началом процесса разработки следует из того, что: Заказчику (Customer) требования необходимы, чтобы предоставить формальное описание продукта, который он хочет получить Команде разработчиков (Development Team) требования необходимы для понимания с самого начала того, что они должны построить (а не переделывать продукт много раз во время разработки) Тестировщикам (Testers) требования необходимы для того, чтобы начать процесс разработки тестов как можно раньше 14

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

Product Requirement (требования) – описание условий или возможностей, которым должна удовлетворять система или ее компоненты для решения пользователями, с ее помощью, поставленных задач или достижения необходимых целей. Требования определяют то, ЧТО (WHAT) должна выполнять система, но НЕ ТО, КАК (HOW) она должна это выполнять. Требования должны быть понятными и четко определять, что система должна (и чего не должна) быть способна выполнять, либо предоставлять описание некоторых условий функционирования, которые необходимо обеспечить с тем, чтобы система могла выполнять свои задачи. 16

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

Requirement Definition Document (документ определения требований) – этот документ представляет собой полный список требований заказчика, которые были рассмотрены и утверждены к разработке Руководителем проекта (PM) и руководителем разработчиков (Development Lead). Он также составляется на естественном языке, понятном заказчику и коллективу разработчиков. Requirement Definition Document представляет собой соглашение между заказчиком и организацией, выполняющей разработку, о том, что должно создаваться. Этот документ легко понять, но ему не хватает точности и технических деталей, необходимых для проектирования и разработки программного продукта. Обычно его пишет System Analyst. 18

Software Requirements Specification (SRS) (спецификация требований) или Software Functional Specification (функциональная спецификация) – данный документ содержит ту же информацию, что и предыдущий, но он предназначен для Архитекторов системы (System Architects), Разработчиков (Developers) и Тестировщиков (Testers), поэтому в нем используются термины и обозначения, принятые в разработке ПО. Здесь содержатся ВСЕ требования к разрабатываемой системе или ее части. 19

Software Requirements Specification (SRS) Эти требования группируются по соответствующим типам и могут включать в себя составные требования. Этот документ как бы является ответом разработчиков - «Что система способна будет делать» , на запрос заказчика - «Вот, что мы хотим, чтобы система делала» . Данный документ является основным при проектировании и реализации системы. 20

IEEE Standard 830: The IEEE Guide to Software Requirements Specification 1. Введение (Introduction) 1. 1 Назначение (Purpose) 1. 2 Область применения (Scope) 1. 3 Обзор (Overview) 2. Общее описание (General Description) 2. 1 Перспектива продукта (Product perspective) 2. 2 Функция продукта (Product function) 2. 3 Характеристика пользователя (User Characteristics) 2. 4 Ограничения общего характера (General Constraints) 2. 5 Допущения и зависимости (Assumption and Dependencies) 3. Особые требования (Specific Requirements) 3. 1 Функциональные требования (Functional Requirements) 3. 2 Требования внешнего интерфейса (External Interface Requirements) 3. 3 Требования к производительности (Performance Requirements) 3. 4 Проектные ограничения (Design Constraints) 3. 5 Атрибуты (Attributes) 3. 6 Другие требования (Other Requirements) Ссылки (References) Приложение 1. Сокращения (Appendix 1 —Acronyms) Приложение 2. Терминология (Appendix 1— Definition of Terms) 21

Приоритеты требований На пример имеем три уровня приоритетов: P 1 (наиболее важные требования) – внедрение является абсолютно необходимым в данной версии продукта. Обычно это основные функции программного продукта. P 2 (очень желательные требования) – внедрение является очень желательным, но не необходимым в данной версии продукта. Их реализация может быть отложена дотпатча/обновления/следующей версии. P 3 (все остальные требования). 22

Типы требований (TYPES OF PRODUCT REQUIREMENTS) Функциональные (Functional Requirements) – описывают услуги и функции (CAPABILITIES), которые должна быть способна выполнять система для решения поставленных пользователями задач: ● Functional (Feature) – функциональные особенности ● GUI – графический пользовательский интерфейс ● Usability - удобство и простота использования, практичность ● Data – данные ● Security – безопасность ● Performance – производительность ● Interface – интерфейсы 23

Не функциональные (Non-Functional Requirements) – описывают условия (CONDITIONS), допущения, ограничения, накладываемые на работу системы, и стандарты, которым она должна соответствовать: ● Configuration – конфигурация, состав оборудования ● Reliability – надежность ● Documentation – документация ● Implementation – реализация ● Supportability – сопровождение и устранение неисправностей ● Physical – физическая среда 24

Функциональные требования (Functional Requirements) Functional (Feature) – эти требования определяют, какие функции и сервисы должен обеспечивать (выполнять) программный продукт на системном или пользовательском уровне. Так же может быть указано, чего не должен делать данный продукт. GUI (Graphical User Interface) – эти требования определяют присутствие (presence), размещение (layout), отображение (внешний вид) ( appearance), функциональность (functionality) и поведение графических элементов (GUI). Графические стандарты операционной системы (Operation System, OS) часто считаются частью этих требований. 25

Функциональные требования (Functional Requirements) Usability – определяют требования, связанные с человеческим фактором, такие как эргономичность (ergonomic), понятность (clearness), простота (simplicity) и целостность (consistency) пользовательского интерфейса (UI), удобство использования приложения. Data – эти требования описывают входные и выходныеиданные системы, какой при этом используется формат (data format), какие данные нужно сохранять, с какой точностью должны выполняться вычисления 26

Функциональные требования (Functional Requirements) Performance – эти требования определяют параметры производительности системы. Описываются требования к расширяемости, масштабируемости (scalability); синхронизации ( synchronization); любые временные параметры, связанные с функционированием приложения (сколько транзакций должна выполнять система в единицу времени); любые ограничения на количество одновременных действий в системе (сколько пользователей одновременно должна обслуживать система); любые ограничения, связанные с одновременным доступом и использованием компьютерных ресурсов. 27

Функциональные требования (Functional Requirements) Interface – эти требования описывают взаимодействие данной системы с другими системами или окружением (environments): входы, получаемые из внешних систем, и выходы, направленные во внешние системы; форматы передаваемых данных, каналы и носители информации. 28

Функциональные требования (Functional Requirements) Security – эти требования описывают правила и права доступа к системе и ее данным, правила аутентификации ( authentication) и авторизации (authorization) в системе, как осуществляется управление безопасностью и на каких уровнях. Здесь же может быть описано требования к резервированию и восстановлению информации (data backup and restore). 29