АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
Дополнительно указываются смежные дисциплины, которые связаны с инженерией ПО. SWEBOK выделяет девять дисциплин: Компьютерная инженерия; Информатика (computer science); Обобщенный менеджмент; Математика; Управление проектами; Управление качеством; Системная инженерия. 5.2. Жизненный цикл программных средств SWEBOK описывает только области знаний и не описывает процессов разработки. ГОСТ Р ИСО/МЭК 12207-2010 «Процессы жизненного цикла программных средств» определяет процесс как совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы. Процессы требуют цели и наблюдаемые результаты. Каждый процесс имеет как минимум один вид деятельности. Деятельность определяется как совокупность согласованных задач. Задача – требование («должно»), рекомендация («следует») или разрешенное («может») действие, предназначенное для содействия достижению одного или более выходов процесса. Задача является наиболее детализированным условием реализации процесса. В целом ГОСТ 12207-2010 рассматривает разработку и поставку программного обеспечения как проектную процессную деятельность. ГОСТ Процессы жизненного цикла разделяет два вида разработки программного обеспечения. Разработка независимых, полноценных информационных систем (автономных программных продуктов) и разработка программного обеспечения, которое является частью другой, более крупной системы (программных средств). Оба вида разработки отличаются по составу процессов. Разработка полноценных информационных систем включает 4 группы процессов (рис. 5.1).  Рис.5.1 Процессы разработки информационных систем Процессы соглашения приводят к тому, что стороны понимают и договариваются о результатах и условиях проекта. Процессы организационного обеспечения проекта включают в себя общие проектные процессы, такие как процесс менеджмента жизненного цикла, процесс менеджмента портфеля проектов, процесс менеджмента людских ресурсов, процесс менеджмента качества и процесс менеджмента инфраструктуры. Процессы проекта обеспечивают непосредственную проектную деятельность и включают такие процессы как планирование, управление и оценки проекта, управление рисков и другие. Технические процессы включают в себя процессы по разработке и производству ПО: анализ, проектирование, разработка и т.п. Именно они являются основными для технических ролей (архитекторы, аналитики, разработчики), участвующих в разработке ПО. Разработка подсистем (программных средств, в терминологии ГОСТ 12207-2010) включает процессы реализации программных средств, процессы поддержки программных средств и процессы повторного применения программных средств (рис. 5.2).  Рис. 5.2. Процессы разработки программных средств Процесс реализации включает все деятельности, связанные с анализом требований, проектированием архитектуры, конструированием, разработкой и тестированием ПО. Процессы поддержки программных средств включают в себя процессы, характерные именно для разработки многокомпонентного ПО (в данном контексте программное средство рассматривается как компонента). Основная цель данной группы процессов – использование компонента ПО в целевой системе, для которой он был разработан. Для обеспечения этого необходимы такие процессы, как документирование, валидация и верификация, обеспечение качества. Группа процессов повторного применения программных средств позволяет сформировать используемый пул компонентов, который задействуется при разработке систем различных предметных областей. В группу входят процессы проектирования доменов и процессы управления повторным применением активов и ПО. 5.3. Бизнес-модель компании и подходы к операционной деятельности Существенное влияние на процесс разработки ПО оказывает бизнес-модель компании и принятый в ней подход к операционной деятельности. В операционное деятельности выделяют координаты формализованности процесса и горизонта планирования (рис. 5.3). Минимальная формализованность процесса заключается в постановке цели, ограничений (например, время и деньги) и предоставлении исполнителю решать задачу полностью самостоятельно. Минимальная формализованность процессов хорошо подходит для творческих и научных коллективов, а также для топ-менеджеров компании.  Рис. 5.3 Координаты горизонт планирования - формализованность процессов При максимальной формализованности процесса исполнители задач получают четкие инструкции по всем производственным процессам. Инструкции формируются максимально подробно и оставляют минимум возможности самостоятельного принятия решения. Достоинствами такого подхода являются: абсолютная прозрачность бизнес-процессов компании, контролируемость и легкая замена исполнителей. Подход широко применяется при организации работ для должностей, не требующих высокого уровня квалификации (сотрудники розничных магазинов, точек быстрого питания, клининговых компаний и т.д.). Для оценки качества процессов в компании-разработчика информационных систем, широко используется модель CMMI (модель зрелости интеграции) [70], на основе которой осуществляется сертификация компании по 5 уровням: «Начальный» – процесс непредсказуем, сильно зависит от конкретных разработчиков. В целом результат может быть предсказан, но предсказаний по сроку и качеству нет. «Управляемый» - процессы определены на уровне проектов, процессы появляются в ответ на события. Проект может быть выполнен в срок, но без гарантий качества. Зависимость от процесса поднимается до уровня управления проектами. «Определенный» - процессы определены на уровне организации, при поставке можно доверять оценку по сроку и качеству, но не бюджету. Организация слабо зависит от исполнителей. «Измеряемый» - процессы не только определены, но и измеряются и контролируются. Высокая вероятность выпустить качественный продукт в срок и в рамках установленного бюджета. «Оптимизируемый» - фокус на совершенствовании процессов При этом хорошо формализованный процесс не обязательно переходит в полностью процедурный подход управления персоналом, но накладывает дополнительные ограничения и обязанности на исполнителей. Горизонт планирования определяет, на какой интервал времени компания формирует план по достижению заданных бизнес-целей. При минимальном планирование горизонт может составлять от двух-трех недель, тогда как длительное – несколько лет. Короткий горизонт планирования предоставляет компании гибкость в принятии решений и хорошо подходит для молодых компаний, особенно на этапе формирования бизнес-модели (стартапы). Долгосрочное планирование позволяет эффективнее планировать использование ресурсов компании (в том числе персонал), запускать дорогие проекты с окупаемостью в несколько лет и показывает, что компания стабильно развивается и имеет проработанную бизнес-стратегию. Планирование на год и больше необходимо для крупных и особенно публичных компаний (акции которой размещены на бирже). Существует две бизнес-модели компании разработчика программного обеспечения: разработка продукта (продуктовая модель) и оказание услуг по разработке и внедрению для конкретного заказчика (проектная/сервисная модель). При продуктовой разработке компания выпускает единую (коробочную) версию своего продукта, которая в одинаковом виде доступна всем заказчикам. Заказчиком продукта является менеджер продукта, который формирует требования на основе своего видения и понимания рынка. В чисто продуктовых компаниях требования конечных пользователей либо не учитываются, либо реализуются в рамках всего продукта и становятся доступны всем клиентам. Примерами компаний, работающих по продуктовой модели являются Facebook, Google, Microsoft, Oracle, 2GIS, Acronis и другие. Сервисная модель компании подразумевает разработку решений под заказ и его интеграцию в IT-ландшафт заказчика. Примерами таких компанию являются крупные интеграторы (ЛАНИТ, Техносерв, Крок и другие), так и небольшие WEB-студии, реализующие маленькие (бюджетом в десятки тысяч рублей) проекты. Заказчиком продукта является клиент компании и, как правило, все требования к разрабатываемой информационной системе фиксируют в виде подписанного технического задания. Отдельно в договоре указывают, кто разработанное решение не может быть поставлено другим заказчикам. Как правило, для продуктовых компаний характерно быстрое реагирования на рыночные условия и изменение разрабатываемого продукта. Поэтому горизонт планирования достаточно небольшой – от нескольких недель до нескольких месяцев. На начальных этап развития у компании часто нет ресурсов на поддержку сложных процессов. Главная цель – максимально быстрая проверка продуктовых гипотез (т.е. насколько разрабатываемый продукт интересен рынку и может окупиться). Существует постоянное понимание, что любое техническое решение может быть пересмотрено и траты на поддержку процессов не окупятся. Компании по сервисной модели работают с проектами, договоренности по которым зафиксированы с заказчиками. Это уже накладывает определенные требования к формализации процессов. Выстроенные процессы являются конкурентным преимуществом на рынке интеграторов, т.к. делают процесс более предсказуемым и прозрачным для заказчика. Наличие нескольких контрактов с конкретными сроками сдачи заставляет иметь горизонт планирования более длительный, чем свойственен продуктовым компаниям, не привязанным к длительности контрактов. На рис. 5.4 представлены бизнес-модели компании в связи с планированием и горизонтом планироваия  Рис. 5.4 Бизнес-модели компании в связи с планированием и горизонтом планироваия Расположение моделей разработки относительно координат горизонта планирования и формализации процессовпоказывает, что они находятся в разных квадрантах. 5.4. Роли участников процесса разработки и их функциональные обязанности Задачи в рамках различных процессов разработки программного обеспечения решают различные сотрудники компании, которые обладают разными компетенциями и навыками. Каждый сотрудник в компании занимает какую-либо должность в рамках организационной структуры компании и имеет должностную инструкцию, в которой определяются его задачи, права и обязанности. Набор обязанностей и выполняемой работы называется бизнес-роль (или просто роль) – ответственность за выполнение определенных задач [72, 73]. Роли могут иметь не только отдельные сотрудники, но и группы сотрудников – поэтому вводится обобщенное понятие бизнес-актор – сущность организационной структуры, которая выполняет определенные действия в границе назначенных на нее ролей. На рис. 5.5 с помощью языка Archimate [74] показан пример, когда одну роль (Куратор молодых специалистов) исполняют две организационные единицы – Руководитель группы разработки и Инженер-программист 3-ей категории. На роль Куратора назначена ответственность Обучение молодых специалистов, которая реализуется в процессе Проверка кода.  Рис. 5.5 Пример отображения роли, процесса и актора Министерство труда и социальной защиты Российской Федерации публикует профессиональные стандарты (ПС). Согласно Трудовому кодексу Российской Федерации (статья 195.1) профессиональный стандарт - характеристика квалификации, необходимой работнику для осуществления определенного вида профессиональной деятельности. Разработка новых профессиональных стандартов в области информационных технологий ведется под эгидой АПКИТ (Ассоциация предприятий компьютерных и информационных технологий). Помимо характеристик, ПС содержит список трудовых функций и соответственно описывает обобщенные бизнес-роли, участвующие в разработке информационных систем. Список ролей приведен в табл. 5.2. Как правило, в каждой роли выделяют несколько уровней зрелости специалиста (в профессиональных стандартах это выражено в виде уровней квалификации): Инженер (специалист) I категории/junior – начинающий специалист. Требует наставничества, контроля и детальной постановки задач. Инженер (специалист) II категории/middle – специалист среднего уровня. Может самостоятельно решать поставленные задачи низкого уровня. Инженер (специалист) III категории/senior – специалист высокого уровня. Может декомпозировать задачи, работает полностью самостоятельно. Осуществляет наставничество над начинающими специалистами, но в тоже время не осуществляет организационную работу. Ведущий (специалист) инженер/lead – специалист высокого уровня, управляющий специалистами в своей области (аналитик – над аналитиками, разработчик – над разработчиками и т.д.). Таблица 5. 2. Список ролей
5.5. Обобщенная модель процесса разработки ПО В разработке ПО можно выделить несколько базовых процессов, которые явно или неявно присутствуют при любой промышленной разработке ПО (рис. 5.6). Предпроектная подготовка – процесс получения предварительной информации о продукте или проекте. В продуктовой компании роль заказчика выполняет Менеджер продукта. Анализируя рынок, общаясь с потенциальными покупателями он формирует портрет потенциального пользователя, его ожидания от продукта. В случае запуска проекта в роли заказчика выступает представитель возможного покупателя, с которым согласуется видение проекта, проясняются цели его внедрения и способы их достижения (бизнес-требования). Руководитель проекта оказывает организационную и проектную поддержку, согласуя возможные работы с планами по другим проектам и подбирая исполнителей, составляя договоры и т.п. Задача Архитектора ПО заключается в консультации со стороны технической реализуемости. Он помогает дать примерную стоимость проекта и необходимые для его реализации ресурсы (как с точки зрения исполнителей, так и с точки зрения технологий). На этом этапе также возможно составление высокоуровневого архитектурного описание проекта. Результатом процесса является заказчик или представление о потенциальном заказчике (в случае продуктовой разработки), подготовлен черновой вариант бизнес-требований и первичная оценка по бюджету и сроку работ.  Рис. 5.6 Обобщенная модель разработки ПО Анализ требований – процесс преобразования бизнес-требований в функциональные требования (рис. 5.7). Основная работа производится в рамках роли Аналитика. Аналитик преобразует бизнес-требования в требования, предъявляемые к разрабатываемой информационной системе. Для этого он использует свою экспертизу в предметной области и находится в максимально возможном контакте с Заказчиком для прояснения всех спорных или непонятных вопросов.  Рис. 5.7. Анализ требований Архитектор ПО анализирует техническую реализуемость разрабатываемых требований, формирует этапы отправки и оценивает их стоимость. На этом этапе должно быть зафиксировано высокоуровневое архитектурное описание, включающее в себя список основных компонентов, связей между ними и список используемого готового ПО (операционные системы, системы управления базами данных и т.п.). Руководитель проекта осуществляет организационную деятельность, помогая, например, организовывать встречи между участниками команды и контролируя выполнение задач. Также он формирует окончательный календарный план графика работ по проекту, его стоимость и бюджет. Составляется высокоуровневый план график, который показывает заказчику даты поставки решений бизнес-задач. Несмотря на то, что фактически каждая роль поставляет по результатам процесса свой набор артефактов (документов), они постоянно взаимодействуют, уточняя и дополняя артефакты друг друга. В процессе проектирования основную роль играет Архитектор ПО (рис. 5.8). Его задача – на основе согласованных требований подготовить детальную архитектуру и технический проект. При этом все непонятные моменты в требованиях прорабатываются вместе с аналитиком. Детальная архитектура описывает компоненты системы, технологии разработки и взаимосвязи. Также может быть включена диаграмма развертывания на серверах заказчиков, которая особенна важна для систем с повышенными требованиями информационной безопасности (например, в банковской и финансовой сфере). Проектное решение строится исходя из разработанной архитектуры и включает в себя технологии, используемые для разработки компонент, схемы хранения данных и дополнительные аспекты, которые необходимо учитывать при разработке. Для сложных или ключевых компонентов может быть разработан верхне-уровневый объектно-ориентированный дизайн. Архитектор определяет пакеты работ (набор задач, в результате которого достигается реализация бизнес-требований) и взаимосвязи между ними. Руководитель проекта на основе этой информации и количестве доступных ресурсов создает подробный план хода проекта с контрольными точками. Данной информации достаточно для запуска контролируемого и прозрачного процесса разработки.  Рис. 5 8. Этап проектирования В процессе разработки главную работу выполняют программисты и специалисты по качеству (тестировщики). Данный процесс можно разбить на два этапа: непосредственно написание кода и тестирование. Во время написания кода программисты реализуют функционал системы, описанный в техническом задании, в том объеме, который определен на релиз (возможно – промежуточный релиз) в рамках пакета работ. Одновременно с ними специалисты по тестированию на основе требований готовят сценарии тестирования. После окончания работ по подготовке релиза, включающего в себя весь функционал (т.н. кандидат в релизы, release candidate) начинается второй этап – тестирования и отладки. Специалисты по качеству осуществляют прогон тестовых сценарий на предоставленном разработчиками релизе. Все найденные ошибки фиксируются и отдаются в разработку, после исправления которых готовится очередной релиз, который проверяется с фиксацией ошибок и цикл выпуска релиза повторяется. Таких промежуточных релизов может быть много, а частота их появления – от нескольких в рабочий день до одного-двух в неделю. Как правило, промежуточные кандидаты в релизы тестируются не полностью – проверяются только сценарии с обнаруженными ошибками. Поэтому после исправления всех ошибок проводится еще одно тестирования, которое включает в себя полный набор сценариев как на новый, так и уже выпущенный функционал (регрессионное тестирование). В определенный момент группа обеспечения качества признает релиз готовым к отправке заказчику. После окончания разработки начинается процесс поставки решения заказчику (рис. 5.9). В самом простом случае продуктовой разработки, данный этап заключается в разворачивании (или выкладки) ПО на сервера промышленной эксплуатации. При разработке проекта разворачивание остается важной процедурой, но не основной. После того как разработчики по в виде отдела качества признали очередную версию достаточно качественной для передачи заказчику, заказчик в виде его представителя начинает осуществлять самостоятельную проверку соответствия между реализованным и описанным в техническом задании функционала. При необходимости технический писатель разрабатывает руководство пользователя и руководство администратора. Как правило, руководство администратора включает описание шагов, которые нужно сделать для развертывания приложения и сценарии поддержки промышленной эксплуатации системы. В ходе отправки у заказчика могут возникать различные пожелания по доработке или изменениям в системе. Для их реализации запускаются процесс анализа требований и разработки. В этот же процесс может входить опытно-промышленная эксплуатация, во время которой система запускается на серверах заказчика и работает с реальными информационными системами заказчика. При этом круг пользователей ограничен представителями заказчика, участвующими в процессе приема ПО. В результате процесса между компанией разработчиком и заказчиком подписывается акт приёма-передачи, разработчик получает оплату, а клиент – готовое к промышленной эксплуатации ПО.  Рис. 5.9. Этап поставки Поддержка – часто наиболее длительный по времени процесс. Начинается после передачи информационной системы в промышленную эксплуатацию и заканчивается прекращением использования системы. На данном процессе осуществляется исправление найденных ошибок и внесение нового функционала. Исправление ошибок осуществляется в обычном режиме и, в зависимости от критичности, поставка исправлений может осуществляться как максимально оперативно, так и в виде куммулятивного пакета обновлений. Доработка новых функциональных возможностей запускает цикл разработки, аналогичный такому в процессе поставки решения. Обязанности сторон по поддержке, как правило, зафиксированы в SLA (Service Level Agreement, Соглашение об уровне сервиса) [75]. Помимо ответственности сторон, в Соглашении прописывают виды ошибок и сроки их исправления, процедуры обновления и действия при инцидентах (инцидент – найденная в процессе эксплуатации серьезная ошибка). При поддержке сложных продуктов, особенно, с которыми взаимодействуют клиенты заказчика (например, юридические лица при работе с интернет-банком для юридических лиц) часто выстраивается схема двух или трех уровневой техподдержки (рис. 5.10). Основная цель выделения многоуровневой технической поддержки – минимизация привлечения дорогостоящих технических специалистов к обработке обращений пользователей. На первой линии работают операторы, которые способны решать большинство стандартных вопросов пользователей. Как правило, такие вопросы связаны с непониманием интерфейсов пользователя или с конкретной ситуацией. Часто у операторов есть возможность получить дополнительную информацию о ситуации (например, технической код ответа внешней информационной системы) через специальные информационные системы и тем самым помочь пользователю. Если оператор первой линии не может самостоятельно решить проблему, он передает обращение на вторую линию. На ней работают технически грамотные специалисты, которые хорошо знают поддерживаемую систему, ее компоненты и взаимодействие между ними. Не маловажно, что они могут иметь доступ к хранилищу данных (СУБД), техническим журналам и другой низкоуровневой информации. Часто сотрудники второй линии могут решить проблему самостоятельно за счет применения низкоуровневых приложений или изменений данных в хранилище. В случае, если они не могут закрыть обращение, их задача – собрать максимальное количество информации для передачи разработчикам системы.  Рис. 5.10. Уровни технической поддержки Данные процессы и роли являются базовыми – они могут не быть явно обозначенными, но будут присутствовать. Если проект разрабатывается минимальным количество исполнителей, на разных этапах производства они будут играть разные роли. Например, если в команде только один технический специалист, он будет самостоятельно проектировать (роль архитектора), разрабатывать (роль программиста), тестировать и поставлять приложение. Список ролей и их ответственностей приведены на рис. 5.11.  Рис. 5.11 Роли их ответственности 5.6. Методологии разработки ПО Детальное описание процессов разработки, включающее роли и необходимые артефакты, приводится в методологиях разработки – совокупности методов, применяемых на различных стадиях жизненного цикла программного обеспечения и имеющих общий подход. Использование методологии позволяет добиться управляемости процесса разработки ПО. Каскадный подход. В статье “Managing The Development of Large Software Systems” [76] Ройс описал водопадную(каскадную) модель разработки ПО. Несмотря на то, что он явно написал о несостоятельности модели и предложил пути ее улучшения до итеративной модели, описание водопадной модели берется из этой статьи. Ключевой особенностью каскадной разработки является последовательное выполнение всех фаз (подпроцессов) процесса. Переход к следующей фазе возможен только после окончательной и полностью проработанной предыдущей, при этом изменение результатов предыдущей работы не допускается. Данный подход приводит к двум серьезным проблемам: очень высокая стоимости ошибки, допущенной на ранних стадиях процесса; неявно подразумевается неизменность исходных бизнес-требований заказчика. Опасность первой проблемы также заключается в сложности проверки результатов работы первых итераций. Таким образом, получается противоречие – нет методик, позволяющих минимизировать количество ошибок и при этом стоимость ошибки значительно возрастает с каждой фазой. При каскадной модели время, прошедшее после общения с заказчиком и выяснения бизнес-требований до передачи решения заказчику может составлять более года. Практически невозможно представить ситуацию, что за год бизнес-процессы и бизнес-цели у компании заказчика не поменяются. Таким образом, заказчик получит систему, которая как минимум, не будет устраивать его частично, а как максимум – полностью не удовлетворит текущим бизнес-требованиям. Эти недостатки привели к тому, что в чистом виде каскадную модель нельзя рекомендовать к использованию на длительных проектах. RationalUnifiedProcess. К концу 80-х стала ясна несостоятельность водопадной модели разработки, что привело к разработке методологии RUP в 1998г (Rational Unified Proccess, Унифицированный процесс компании Rational). RUP предлагает следующие лучшие практики процесс разработки [77, 78]: Процесс управляется вариантами использования. Использование компонентной архитектуры. Итеративная и инкрементная разработка. Визуализация моделей ПО. Управление изменениями ПО. «Управляемый вариантами» использования означает, что процесс разработки проходит серии рабочих процессов, порожденных вариантами использования. Вариант использования – это часть функциональности системы, необходимая для получения пользователем значимого для него, ощутимого и измеримого результата. Описание системы с помощью вариантов использования позволяет ответить не только на вопрос «что система предположительно делает?», но и на вопрос «что система предположительно делает для каждого пользователя?». Это побуждает разработчиков системы думать в понятиях результата, значимого для пользователя. Архитектура вырастает из тех требований к результату, которые описаны в вариантах использования. При этом она также зависит от других факторов, таких как выбор платформы, наличие готовых решений, IT-ландшафта заказчика и влияет на возможности самой системы. Таким образом, архитектура и требования плотно связаны между собой проблемой «курицы и яйца» и фактически разрабатываются параллельно. Для того, чтобы была возможность зафиксировать архитектуру в достаточном для проработки виде и оставить в ней гибкость, RUP рекомендует использовать компонентный архитектурный подход – создание и развертывание систем, собираемых из компонентов, а также разработка и поиск этих компонентов. Компонента - не тривиальный модуль (подсистема), которая выполняет четкую функцию, доступ к которой предоставляется через зафиксированный программный интерфейс. В первую очередь прорабатываются компоненты и взаимосвязи между ними, без их детальной проработки компонент. На основе этой минимальной архитектуры осуществляется проработка следующих вариантов использования, под которые дорабатывается архитектурное представление и процесс повторяется. В отличие от водопадной модели, итеративная модель подразумевает разработку ИС и поставку ее заказчику в несколько вех, называемых итерациями. Каждая итерация – это мини-проект, по результатам которого приложение получает приращение бизнес-функциональности в виде реализованных сценариев использования. Для большей эффективности при каждой итерации выбираются наиболее актуальные бизнес-сценарии, а сама реализация осуществляется в рамках проработанной архитектуры. Визуализация моделей позволяет подчеркнуть важное в структуре и поведении разрабатываемого ПО. Визуальное представление позволяет оценить решение с разных точек зрения и согласовать между собой различные аспекты разрабатываемой системы. Также наличие проработанных диаграмм значительно повышает качество документации и позволяет новым членам команды быстрее вникать в проект. Следует отметить, что RUP и UML разрабатывались совместно и UML рассматривался как часть методологии RUP. В отличии от водопадной модели, RUP подчеркивает возможность изменений в требованиях и считает хорошей практикой рассматривать принятие любого изменения. Помимо лучших практик, RUP предлагает описание структуры процесса с статической и динамической точек зрения [79]. В статической модели RUP описаны четыре элемента: сотрудники (workers), деятельности (activities), артефакты (artifacts) и рабочие процессы (workflows) [78]. Сотрудник – позиция, которая может быть поручена члену команды, требующая ответственности и способностей. Например – выполнение какой-либо деятельности или разработка артефакта. Деятельность – существенная единица работы, которая выполняется сотрудником в ходе потока работы. Каждая деятельность четко определяет ответственность сотрудника, дает четко определенный результат (выход деятельности), который базируется на исходных данных (вход деятельности). Вход и выход представлены в виде артефактов – любые виды информации, создаваемой, изменяемой или используемой сотрудниками при создании системы. Связанные деятельности группируются в рабочие процессы. Динамическая модель в обобщенном виде описывает последовательность фаз, которые нужно сделать для разработки проекта. RUP предлагает четыре фазы, последовательно идущие друг за другом: анализ и планирование требований, проектирование, построение, внедрение. По завершению каждой фазы фиксируется промежуточная точка разработки (milestone), по результатам которой можно принять решение о закрытии, продолжении проекта или внесении в него существенных изменений. В рамках фазы работа ведется итерациями, т.е. каждая фаза состоит из нескольких итераций. В рамках каждой итерации последовательно выполняется несколько рабочих процессов. Шесть из них составляются ключевыми, а четыре - вспомогательными. Основные процессы включают в себя: сбор требований, анализ, проектирование, реализацию, тестирование, поставку. Поддержку ключевым процессам оказывают: управление конфигурациями и изменениями, управление проектами и процессы окружения. В зависимости от фазы и итерации, объем работ каждой деятельности отличается (Рис. 5.12). Scrum. RUP накладывает требования на организацию процесса разработки, которые позволяют эффективно организовать работу крупных проектов, разрабатываемых на заказ. В то же время эти требования могут быть лишними для небольших команд и компаний, занимающихся продуктовой разработкой. Для решения этого противоречия предлагается использовать «гибкие» процессы разработки – Scrum, Kanban, Lean и др [80]. Наибольшую популярность сейчас завоевал Scrum, поэтому далее будет рассмотрен он.  Рис. 5.12 Итерации и фазы RUP Экстремальное программирование. Большое влияние на развитие гибких процессов оказали практики экстремального программирования (XP, Extreme Programming), в которых центральная роль в разработке отводится разработчикам, а главным артефактом является удовлетворяющая требованиям заказчика программа. Концепция XP строится на 4 исходных предпосылках [81] : люди и их взаимодействие важнее, чем процессы и среда; работающее ПО важнее, чем исчерпывающая документация; сотрудничество с заказчиком важнее, чем обсуждение условий контракта и соблюдение технического задания; реагирование на изменение важнее, чем следование плану. Технически, экстремальное программирование привнесло такие практики как постоянное улучшение кода путем его рефакторинга (т.е. изменения кода без изменения его функциональности), разработка модульных тестов, парное программирование, непрерывные сборки и поставки и др. Тем не менее экстремальное программирование не является методологией разработки в чистом виде, правильней рассматривать его как набор хороших практик разработки. Немаловажным является требование участия в разработке только опытных разработчиков с высокой мотивацией на производство продукта. Scrum. Процессные методологии разработки, такие как RUP, подразумевает механистическую модель управления, когда сотрудники рассматриваются как часть большой машины по производству продуктов. Современный менеджмент активно пользуется системным мышлением в управлении, при котором ключевая роль в работе отдается непосредственно исполнителю, которому дается достаточно прав и обязанностей для самостоятельного принятия решений в рамках поставленной цели. В разработке ПО данный подход представлен в виде методологии Scrum. В отличии от RUP, в котором вводится много ролей, Scrum оперирует всего тремя ролями: Владелец продукта (Product Owner), Scrum-мастер (Scrum Master) и член команды [80]. Команда работает итерациями, в конце каждой из которых предоставляет готовый к поставке продукт. Задача Владельца продукта – составление и поддержка в актуальном состоянии списка задач, которые команда должна взять в следующие итерации. При этом Владелец продукта ставит бизнес-задачи, которые дают бизнес-прирост функционала команды. Scrum-мастер хоть и рассматривается как отдельная роль, но он является членом команды (т.е. человек одновременно выполняет две роли). Его задача – контролировать, что команда придерживается принципов scrum’а и взятых на себя обязательств по улучшению процесса. В команде нет четко выделенных исполнителей ролей, каждый член команды может выполнять разные роли. Например, один член команды может совмещать роли Аналитика и Тестировщика, а другой – Программиста и Тестировщика. Такие команды называется кроссфункциональными. Очень важным является аспект доверия между всеми участниками процесса – заказчик должен доверять исполнителю, а Владелец продукта – команде. В отличии от проектных видов деятельности, Scrum не оперирует временем в астрономических единицах (часы, дни, недели и т.д.). В нем используются абстрактные единицы объема работ – story и task points (стори и таск поинты, SP и TP). Владелец продукта за несколько итераций вычисляет объем story point, который команда может выполнить в полном составе. Жизненный цикл состоит из следующих видов деятельности: Проработка задач. Встреча, на которой владелец продукта вместе с командой обсуждает суть задач и их примерную оценку в story point. По результатам грумминга у команды должно быть четкое понимание, что именно нужно сделать истории. Планирование итерации. Перед планированием владелец продукта выбирает из backlog наиболее приоритетные задачи, которые команда должна взять в очередную итерацию. Само планирование проходит как встреча, на которой команда еще раз, более тщательно, оценивает задачи и фиксирует, какие именно задачи она обязуется сделать в конце итерации. Тщательность оценки достигается за счет разбивки историй Владельца продукта на технические задачи, которые в свою очередь могут быть разбиты на подзадачи. Каждая подзадача оценивается с помощью task point. Спринт. Основной вид деятельности, длится от одной до трех недель. Во время спринта команда занимается разработкой. Важным элементом являются утренние короткие встречи (их длительность не должна превышать 15 минут), на которых члены команды делятся результатами за предыдущий день и планами на новый. Как правило, такие встречи проходят у доски, на которой вывешены задачи. Доска разбита на несколько вертикальных дорожек: не взята в работу, взята в работу, выполнена (конкретный набор дорожек выбирает сама команда). Изначально все задачи находятся на дорожке «не взята в работу». После завершения работы над задачей, она перемещается в дорожку «выполнена». Для наглядного отображения прогресса работы спринта, после каждой утренней встречи обновляется диаграмма burndown, на которой отмечается количество реально выполненных и количество оставшихся taskpoint у команды. Демонстрация результатов спринта. Встреча, на которой команда показывает свои успехи за прошедший спринт. При этом на демонстрацию приглашаются все заинтересованные стороны и в первую очередь – заказчик разработки. Обязательным является присутствие всех членов команды, которые должны видеть реакцию приглашенных на результаты своей работы. Ретроспектива. Последняя деятельность в итерации. На ретроспективе команда обсуждает как прошел спринт и планирует, как можно улучшить процесс в дальнейшем. Как правило, демонстрация результатов спринта и ретроспектива проходят в один день, а не следующий день осуществляется планирование и запуск новой итерации. В иерархических моделях управления, оценки по трудозатратам дают начальники и они спускаются исполнителям как данность. В scrum же, напротив, оценки стоимости разработки задач осуществляются непосредственно исполнителями. При этом обоснованно считается, что быстрее указанного командой срока задача выполнена быть не может. Несмотря на то, что в основе RUP и Scrum лежит итеративная разработка, эти методологии предназначены для разных видов разработки. В табл. 5.3 приведены ключевые особенности методологий и различия между ними ([82]). Таблица 5.3. Ключевые особенности методологий и различия между ними
Контрольные вопрсы Свяжите обобщенную модель процесса разработки ПО с процессами из ГОСТ Р ИСО/МЭК 12207-2010 «Процессы жизненного цикла программных средств» Вы являетесь Архитектором небольшой WEB-студии, ориентирующейся на мелких розничных клиентов с небольшим бюджетом на проект. Какую схему процесса вы будете внедрять «свобода принятий решений» - «процедуры» и «гибкость» -«планирования»? Вы являетесь Архитектором компании, которая работает на банковский сектор и ориентируется на клиентов из топ-30. Какую схему процесса вы будете внедрять по координатам «свобода принятий решений» - «процедуры» и «гибкость»-«планирования»? Поместите методологии разработки в координаты «свобода принятий решений» - «процедуры» и «гибкость»-«планирования». Компания полностью внедрила ГОСТ Р ИСО/МЭК 12207-2010. Поместите ее на шкалу «свобода принятий решений» - «процедуры» Сравните Эталонную модель процесса с моделью процессов предлагаемых в RUP. Расположите методологии в координаты «свобода принятий решений» - «процедуры» и «гибкость»-«планирования». Вы возглавляете проект по разработке внутреннего продукта «Управление отношениями с клиентами». Какую методологию вы предложите использовать? |