Конспект - Лаборатория ITLab
реклама
Обзор стандартов проектирования и разработки ПО Технология программирования Конспект лекций «Обзор стандартов проектирования и разработки ПО» Лекция 1: Введение В современной рыночной экономике основным конкурентным преимуществом любого предприятия становится качество. Это слово - "качество" - стало своего рода общим местом в программных речах руководителей всех рангов. Возможно, именно поэтому мы редко задумываемся над тем, что такое, собственно говоря, качество, как его обеспечить и как убедить потребителей в высоком качестве производимой продукции. Итак, что такое качество? В советские времена качественным товаром можно было считать товар, соответствующий установленным стандартам. Однако стандарты несовершенны, быстро устаревают и составляются людьми, у каждого из которых имеется собственная точка зрения. Такое понимание качества не годится в условиях рынка. В современной экономике общим мерилом являются нужды и требования потребителей. Если товар удовлетворяет их - он является качественным. Таким образом качество - есть способность товара или услуги наилучшим образом удовлетворять потребности людей. Для эффективного управления качеством принципиальное значение имеет концентрация на процессах. Как процесс можно рассматривать практически любую организационную деятельность. В ходе процесса некий "вход" (сырье, материал, полуфабрикат, информация и т.д.) преобразуется в некий "выход" (продукт) с конечной целью удовлетворить потребности клиента. Качество конечной продукции или услуг зависит от качества каждого отдельного процесса и их взаимоувязанности. Концентрация на процессах позволяет обеспечить прозрачность и управляемость производственной деятельности предприятия и работ по обслуживанию клиентов. Еще один важный элемент динамичной стратегии (или системы) качества непрерывные улучшения. Деятельность по улучшению качества направлена на обеспечение максимального соответствия производимых продукции и услуг потребностям клиентов, а также на устранение выявленных недостатков в существующих процессах. Качество продукции и услуг зависит от качества управления, принятия решений. Решения, влияющие на качество должны приниматься на основе фактов и проверенных данных. Описанный подход к обеспечению качества является универсальным и может быть использован практически каждым предприятием, в любой отрасли для обеспечения стабильного высокого качества продукции и услуг. Этот универсальный подход был законодательно закреплен серией международных стандартов ISO 9000. Зачем нужны стандарты систем качества? У каждого руководителя и у каждого покупателя (заказчика) продукции имеются две альтернативы поведения в отношении контроля работы поставщика (исполнителя): Учебно-исследовательская лаборатория «Информационные технологии» 1 Обзор стандартов проектирования и разработки ПО 1. Контролировать ход выполнения работы с целью предотвращения некачественного результата, затрачивая при этом значительные средства на контрольные мероприятия. 2. Полностью доверить выполнение работы исполнителю, экономя средства, затрачиваемые на контроль, но неся риск убытков, связанных с получением некачественного результата. Один из главных идеологов управления качеством Эдвард Деминг описывает ряд закономерностей, позволяющих наглядно показать значение стандартизации систем качества: "Правило недоверия": рациональный покупатель (заказчик) выберет альтернативу 1 при R>C/L "Правило доверия": рациональный покупатель (заказчик) выберет альтернативу 2 при R<C/L Где: R - вероятность некачественного результата C - затраты на контроль для предотвращения некачественного результата L - ущерб от возникновения некачественного результата. Естественно, экономически более выгодной является вторая альтернатива поведения, предполагающая доверие между партнерами. Для ее применения очевидно необходимо, чтобы вероятность получения некачественного результата от поставщика была как можно более низкой. Проблема только в том, чтобы объективно оценить значение R, то есть определить насколько можно доверять партнеру, поставщику или сотруднику и не контролировать его работу. Краткая история стандартов ISO 9000 Семейство стандартов ISO 9000 ведет свою историю с 1987 года, когда Международная Организация по Стандартизации (International Organization for Standardization или ISO) утвердила первую версию универсальных стандартов сертификации систем качества: ISO 9000 /87. За основу при разработке стандартов ISO 9000 были приняты стандарты, использовавшиеся министерством обороны США для оценки систем обеспечения качества поставщиков оборонной продукции. Методологической базой стандартов стал подход Управления комплексным качеством (Total Quality Management). Костяк семейства стандартов составили три альтернативные модели сертификации: ISO 9001 - Модель обеспечения качества при проектировании, производстве, монтаже и обслуживании ISO 9002 - Модель обеспечения качества при производстве, монтаже и обслуживании ISO 9003 - Модель обеспечения качества при окончательном контроле и испытаниях В 1994 году была выпущена обновленная версия стандартов, в целом повторявшая структуру версии 1987 года (ISO 9000 /94). И наконец с 1 января 2001 года в действие вступает версия ISO 9000 /2000. Новая версия уже не включает в себя альтернативных моделей обеспечения качества, подлежащих сертификации. С 2001 года сертифицировать по ISO 9000 можно будет лишь полномасштабную систему качества. Учебно-исследовательская лаборатория «Информационные технологии» 2 Обзор стандартов проектирования и разработки ПО Философия стандартов семейства ISO 9000 Философия ISO 9000 основывается на экономически эффективном применении "правила доверия", позволяющем рациональнее использовать ресурсы как каждого предприятия в отдельности, так и экономики в целом. Можно считать, что стандарты систем качества ISO 9000 были внедрены именно для того, чтобы дать предприятиям большую уверенность в поставщиках, дать им возможность точнее оценить значение R и повысить это значение. Важно четко разделять два понятия - управление качеством и сертификация систем качества. Управление качеством - одна из функций управления предприятием, которая позволяет реально обеспечивать высокий уровень качества продукции и услуг за счет внимательного и разумного управления производством и обслуживанием. Система управления качеством организована в соответствии со спецификой и задачами конкретного предприятия. Стандарты ISO 9000 предлагают методику построения такой системы, которая может быть официально сертифицирована. Сертификация системы качества сама по себе не может обеспечить повышение качества. Она всего лишь показывает другим субъектам рынка, что система качества предприятия организована в соответствии с определенными требованиями и эффективно функционирует, обеспечивая стабильное и высокое качество продукции и услуг предприятия. Сертификацию проводят специализированные сертификационные бюро (или регистры). Эти регистры аккредитованы при соответствующих государственных и международных органах стандартизации, что позволяет обеспечить доверие к выдаваемым ими сертификатам. Стандарты ISO 9000 признаны во многих странах. Существуют переведенные на национальные языки и адаптированные версии стандартов, такие как, ГОСТ Р ИСО9000. В то же время сертификация по ISO 9000 не является обязательным требованием к производителям. Даже в промышленно развитых странах сертификация по ISO 9000 обязательна (по закону) только для поставщиков в военной и аэрокосмической отраслях, а также в некоторых отраслях, производящих продукцию, от качества которой зависят жизни людей. Однако, наличие сертификата ISO 9000, тем не менее зачастую является ключевым фактором успеха на многих рынках или даже выхода на них. Оно свидетельствует о принадлежности компании к цивилизованному деловому миру. Кроме того, системы качества многих компаний требуют наличия сертифицированных систем качества у их поставщиков. Универсальность семейства стандартов ISO заключается в том, что они не предлагают абсолютных измеримых критериев качества для каждого отдельного вида продукции и услуг (например, требуемых технических характеристик продукции). Это было бы и невозможно - ведь качество - есть способность продукции или услуг удовлетворять потребности людей, а потребности - бесконечно разнообразны. Стандарты семейства ISO 9000 задают лишь методологию функционирования системы качества, которая в свою очередь должна обеспечивать высокое качество продукции и услуг, производимых предприятие, иными словами - обеспечивать высокую степень удовлетворенности потребителей. Нужно ли сертифицироваться по ISO 9000? Учебно-исследовательская лаборатория «Информационные технологии» 3 Обзор стандартов проектирования и разработки ПО Ясно, что управлять качеством должны все, кто хочет сохранить конкурентоспособность на рынке. Вряд ли кто-то станет отрицать важность повышения качества для успеха на рынке. Другое дело - дорогостоящая процедура сертификации. Сертификация по стандартам ISO 9000 предполагает соответствие системы качества предприятия ряду как содержательных, так и формальных требований. Процесс приведения системы качества в соответствие этим требованиям может быть весьма трудоемким и, как правило, занимает много времени. Поэтому, прежде чем принять решение о подготовке системы качества к сертификации по ISO 9000, руководство предприятия должно тщательно взвесить все "за" и "против", а также ясно определить зачем компании нужен сертификат на систему качества. Даже за рубежом наличие сертификата ISO 9000 (или аналогичных сертификатов) является обязательным лишь в отдельных отраслях, преимущественно, связанных с продукцией, от качества которой зависит жизнь и здоровье людей (военные и аэрокосмические отрасли, автомобилестроение и др.). Иногда наличие сертификации является требованиям системы качества самого заказчика. В остальных случаях сертификат ISO 9000 не является обязательным, однако может обеспечить преимущество при выборе поставщика. Если дело касается российских предприятий, то речь о сертификации по ISO 9000 должна вестись в том случае, если компания работает на зарубежных рынках или намерена выходить на них, или же если клиенты компании требуют наличия у нее сертифицированной системы качества. Учебно-исследовательская лаборатория «Информационные технологии» 4 Обзор стандартов проектирования и разработки ПО Лекция 2: Управление проектами по разработке программного обеспечения В последние 3 года на западе стали модными термины «легковесный процесс», «адаптивный процесс», «единый рациональный процесс» и «экстремальное программирование». Что это такое? И почему иногда эффект от внедрения ISO9000 оказывается негативным? Какой процесс предпочесть и какими критериями руководствоваться при выборе процесса? Существующие методологии В мире существует довольно много типовых процессов производства программного обеспечения. ISO9001, ISO12207, ISO15504, CMM (Capability Maturity Model), MSF (Microsoft Solution Framework), RUP (Rational Unified Process), SCRUM, XP (eXtremal Programming), Crystal Clear, ASD (Adaptive Software Development), Lean Development – все это разновидности процессов производства программного обеспечения, семейства процессов и методологии. Под методологией понимается набор методов, практик, метрик и правил, используемых в процессе производства ПО. Согласно Алистеру Кобурну, методология нужна для того, чтобы: Облегчить процедуру введения новых людей в курс процесса производства Обеспечить взаимозаменяемость людей Распределить ответственность Произвести впечатление на спонсора/заказчика Демонстрировать видимый прозрачный процесс Создать учебную базу для своих сотрудников Методологии можно условно разбить на 3 категории – тяжелые, легкие и средние. Упрощенно, каждая из которых, предназначена для работы в условиях, соответственно, больших, малых и средних проектов. Первая категория методологий появилась на свет раньше всех и является неотъемлемой частью моделей качества программного обеспечения. Тяжелые методологии отличаются тем, что охватывают все аспекты деятельности компании, производящей программное обеспечение – от управления требованиями и планирования процесса до регламентирования взаимоотношений с субподрядчиками и описания требований к вспомогательным процессам. Все методологии данной категории нетерпимы к изменениям и рассматривают людей как обычный ресурс. Примеры: CMM, ISO9000, SPICE. Вторая категория методологий появилась на свет в качестве некоторой совокупности методов и практик, применявшихся небольшими командами разработчиков в успешных проектах. Здесь огромное значение уделяется взаимоотношениями между людьми внутри команды, учитываются вопросы терпимости и другие психологические аспекты. Все процессы данной категории предусматривают итерационный жизненный цикл разработки ПО. Если попытаться сформулировать основной смысл легких методологий, то получится следующее: «Обеспечение максимальной скорости и качества разработки ПО при минимуме ограничений и условностей». В частности, во всех легких методологиях предусмотрен лишь необходимый минимум документов, т.к. отдается должное принципу «Документация – это не есть понимание». Существенным отличием данных методологий от методологий первого типа является отношение к планированию. Лучше всего суть этого отличия выразил Джим Хайсмит: «В традиционном планировании отклонения от Учебно-исследовательская лаборатория «Информационные технологии» 5 Обзор стандартов проектирования и разработки ПО плана являются ошибками, которые должны быть устранены. Однако, в адаптивном процессе, отклонения ведут нас к правильному решению». Примеры: SCRUM, XP (eXtremal Programming), Crystal Clear. В третью категорию методологий попадают так называемые «универсальные» процессы. Самым ярким и известным представителем данной категории является RUP. Основной характеристикой подобных процессов является масштабируемость – т.е. процесс может быть настроен как на работу в малой команде над небольшим проектом, так и в большой команде над большим и серьезным проектом. Учебно-исследовательская лаборатория «Информационные технологии» 6 Обзор стандартов проектирования и разработки ПО Лекция 3: XP (eXtremal Programming) Краткое описание Новое модное направление в технологии программирования. Довольно часто стало встречаться в объявлениях о приеме на работу, как условие приема. Экстремальное программирование применяется для создания программ коллективом от двух до десяти человек при заранее заданных сроках сдачи проекта. Правила экстремального программирования Планирование Пишутся User Stories. Собственно план создается в результате планирования Релиза. Выпускать частые небольшие релизы. Измеряется скорость проекта. Проект делится на итерации. Каждая итерация начинается с собрания по планированию. Люди постоянно меняются задачами. Каждый день начинается с утреннего собрания стоя. XP правила корректируются если что-то не так. Дизайн Простота. Обязательно выбрать метафору системы. Использовать CRC карточки для дизайна. Писать пробные решения для уменьшения риска. Не добавлять никаких функций раньше времени. Рефакторить безжалостно. Кодирование Заказчик всегда рядом. Весь код должен соответствовать принятому стандарту. Весь код должен быть создан парным программированием. Частая интеграция кода. Коллективное владение кодом. Оставлять оптимизацию на потом. Тестирование Любой код должен иметь Unit Test. ВСЕ Unit тесты должны проходить перед отдачей. Если найдена ошибка, то тесты корректируются или создаются. Функциональные тесты периодически выполняются и их результаты публикуются. Комментарии: Учебно-исследовательская лаборатория «Информационные технологии» 7 Обзор стандартов проектирования и разработки ПО User Story - это описание того как система должна работать. Каждая User Story написана на карточке и представляет какой-то кусок функциональности системы, имеющий логический смысл с точки зрения Заказчика. Форма - один-два абзаца текста понятного пользователю (не сильно технического). Планирование Релиза определяет набор правил, которые позволяют всем принимать свои решения. Эти правила определяют метод выработки удовлетворяющего всех плана работ. Сущность собрания по планированию релиза для команды разработчиков в том, чтобы оценить каждую User Story в идеальных неделях. Идеальная неделя - это сколько, повашему, займет времени выполнение задачи, если ничто больше вас не будет отвлекать. Ни зависимостей, ни дополнительных задач, но включая тесты. Заказчик затем решает, какие задачи наиболее важны или имеют более высокий приоритет. Скорость Проекта (или просто скорость) это мера того, как быстро выполняется работа в вашем проекте. Простота. Простой дизайн всегда легче реализовать, чем сложный. Поэтому всегда делайте простейшее решение, которое может работать. Если находите что-нибудь сложное - замените это чем-нибудь простым. Всегда оказывается быстрее и дешевле заменить сложный код простым до того как начнешь разбираться в сложном коде. Метафора системы. Всегда выбирайте System Metaphor - простую и понятную концепцию чтобы члены команды называли все вещи одинаковыми именами. Для понимания системы и исключения дублирующего кода чрезвычайно важно как вы называете обьекты. Если вы можете предположить как называется какой-либо обьект в системе (если вы знаете что он делает) и он правда так называется - вы сохраните уйму времени и сил. Создайте систему имен для своих обьектов так, чтобы каждый член команды мог пользоваться ею без специальных знаний о системе. CRC карточки. Используйте Class, Responsibilities, Collaboration (CRC - Класс, Обязанности, Взаимодействие) карточки для дизайна системы командой. Использование карточек позволяет легче приучиться мыслить обьектами а не функциями и процедурами. Также карточки позволяют большему количеству людей участвовать в процессе дизайна (в идеале - всей команде), а чем больше людей делает дизайн, тем больше интересных идей будет привнесено. Пробное решение. Создавайте пробные решения для ответа на сложные технические вопросы, для обоснования тех или иных технологических решений. При принятии любого технологического решения существует риск и пробные решения призваны уменьшить его. Безжалостно рефракторить! Безжалостно пересматривайте любой код для того, чтобы сохранять дизайн простым по мере разработки. Сохраняйте код ясным и понятным чтобы его было легко понять, модифицировать и расширять. Удостоверьтесь что все написано один и только один раз. В конечном итоге, это занимает меньше времени чем доводить до ума запутанную систему. Заказчик. Одно из требований XP - заказчик всегда доступен. Он должен не просто помогать команде разработчиков, а быть ее членом. Все фазы XP проекта требуют коммуникации с заказчиком, лучше всего лицом к лицу - на месте. Лучше всего, просто назначить одного или нескольких заказчиков в команду разработчиков. Учебно-исследовательская лаборатория «Информационные технологии» 8 Обзор стандартов проектирования и разработки ПО Соглашение о кодировании. Все должны подчиняться общим стандартам кодирования форматирование кода, именование классов, переменных, констант, стиль комментариев. Таким образом, мы будем уверены, что внося изменения в чужой код (что необходимо для агрессивного и экстремального продвижения вперед) мы не превратим его в Вавилонское Столпотворение. Парное программирование. Весь код для продукционной системы (а это значит за исключением пробных решений) пишется парами. Два разработчика сидят рядом. Один набирает, другой смотрит. Время от времени они меняются. Не разрешается работать в одиночку. Если по какой-то причине второй из пары пропустил что-то (болел, отходил и т.п.) он обязан просмотреть все изменения сделанные первым. Звучит необычно, но XP утверждает что после небольшого периода адаптации большинство людей прекрасно работают в парах. Им даже нравится, поскольку работа делается заметно быстрее. Действует принцип "Одна голова хорошо, а две лучше". Пары обычно находят более оптимальные решения. Кроме того существенно увеличивается качество кода, снижается число ошибок и ускоряется обмен знаниями между разработчиками. Коллективное владение кодом. Коллективное владение кодом стимулирует разработчиков подавать идеи для всех частей проекта, а не только для своих модулей. Любой разработчик может изменять любой код для расширения функциональности. Оставляйте оптимизацию на потом! Никогда не оптимизируйте ничего до окончания кодирования. Никогда не пытайтесь угадать где будут узкие места по производительности. Измеряйте! Сделайте, чтобы это работало, затем чтобы работало правильно, затем чтобы работало быстро. Unit Test-ы. Unit тесты играют ключевую роль в XP. Они позволяют быстро менять код, не боясь наделать новых ошибок. Unit тест пишется для каждого класса, тест должен проверять все аспекты работы класса - тестировать все что может не работать. Хитростью здесь является то, что тест для класса должен быть написан раньше самого класса. Это значит, что как только вы выпустите первый работающий результат, он будет поддерживаться системой тестирования. Для проведения тестов пишется специальная система тестирования со своим интерфейсом. Unit тест для класса хранится в общем репозитории вместе с кодом класса. Никакой код не может быть выпущен без Unit теста. Перед отдачей кода разработчик должен удостовериться что все тесты проходят без ошибок. Никто не может отдать код, если все не прошли 100%. Другими словами поскольку до ваших изменений все тесты проходили, то если вы имеете ошибки, то это результат ваших изменений. Вам и исправлять. Иногда бывает неправильным или неполным код теста. В таком случае надо исправлять его. Огромным искушением является сэкономить на Unit тестах когда мало времени. Но этим Вы только обманываете себя. Чем сложнее написать тест, тем больше времени он потом сэкономит. Это доказано практикой. Функциональные тесты. Пишутся на основе User Story. Они рассматривают систему как черный ящик. Заказчик ответственен за проверку корректности функциональных тестов. Эти тесты используются для проверки работоспособности системы перед выпуском ее в производство. Функциональные тесты автоматизируются так, чтобы имелась возможность их часто запускать. Результат сообщается команде, и команда отвечает за планирование исправлений функциональных тестов. Учебно-исследовательская лаборатория «Информационные технологии» 9 Обзор стандартов проектирования и разработки ПО Лекция 4: CMM Краткое описание Capability Maturity Model – система качества, разработанная SEI (Software Engineering Institute) Цель СММ: гарантирование реализации проекта разработки ПО в заданный срок с заданным бюджетом и высоким качеством. CMM - не технология, не стандарт, для нее нет никаких формальных описаний, и SEI не рекомендует использовать ориентированные на CMM CASE-системы. Более того, при создании CMM не проводилось никаких аналогий и не делалось никаких заимствований из других методик проектирования ПО. В ней нет жестких предписаний, она не привязана к конкретным информационным технологиям, не подсказывает, как улучшить работу компании, и не объясняет, как работать с персоналом. Нет готовых руководств и по применению CMM - SEI советует каждой компании самой написать руководство для своего бизнеса на основе CMM. CMM предназначена для организации эффективного управления разработкой ПО. Она определяет ключевые действия, которые указывают, что надо сделать для достижения требуемого качества ПО (но не указывают, как). CMM позволяет точно оценить процесс разработки ПО и на этой основе сравнить производительность различных компаний. В CMM включен набор критериев для определения зрелости процессов разработки ПО. Эти критерии используются крупными заказчиками для оценки риска при заключении контрактов на разработку ПО. Пять уровней CMM Первый уровень. ПРПО фирмы никак не организованы, и реальные попытки их улучшения не предпринимаются. Практически 99% отечественных программистских компаний соответствуют этому уровню. Успех проектов зависит только от индивидуальных способностей сотрудников, и обычно ни сроки, ни бюджет не укладываются в заданные границы. Сам проект представляет собой "черный ящик", когда известно только, что есть "на входе" (число программистов и их примерная производительность) и что должно быть на "выходе" (продукт в соответствии с техническим заданием). Второй уровень. Компания на основе анализа успешных проектов начинает повторно использовать подходящие ПРПО. Положительная практика документируется, организуется учеба сотрудников и определяются пути улучшения ПРПО для их применения в смежных проектах. Создаются внутрифирменные стандарты ПРПО, внедряются процессы планирования и контроля за работой. Налаживается обратная связь с заказчиками. Определяются примерные ресурсы на используемые ПРПО (например: для процесса тестирования модуля из 10 тыс. строк требуется один программист, месяц времени и 1000 долл.). Однако успех проектов по-прежнему зависит от ведущих специалистов, а ПРПО разработаны только для конкретных областей (бухгалтерское или математическое ПО и т. п.). Но фирме уже удается укладываться в заданные сроки и бюджет (с определенной вероятностью отклонения). Проект разбивается на небольшие части и становится более понятным менеджерам и разработчикам. Обычно на этом уровне компания создает информационные и функциональные модели, что нередко считается чуть ли не пределом совершенства и критерием высочайшего профессионализма. Увы, этот уровень не дотягивает даже до среднемирового. Дело в том, что такие модели не объясняют, каким образом будут Учебно-исследовательская лаборатория «Информационные технологии» 10 Обзор стандартов проектирования и разработки ПО реализовываться конкретные программные блоки. Поэтому на этапе программирования все проблемы решаются по мере их возникновения. Третий уровень. Это уже уровень мирового класса. Компания детально стандартизует используемые ПРПО (пока для решения достаточно общих задач) с учетом их дальнейшего развития. Все процессы интегрированы в жестко регламентированный общефирменный процесс разработки ПО. При этом большинство ПРПО удается успешно адаптировать для работы над проектами из разных областей. Каждый раз по завершении проекта ПРПО улучшаются, причины улучшений документируются, и новые проекты реализуются на основе более зрелых процессов. Широко внедряются всевозможные учебные программы. Роль отдельных личностей перестает влиять на результат. Этот уровень характеризуется тем, что в фирме должна быть создана специальная группа софт-инжиниринга (software engineering process group). Теперь и менеджеры, и программисты понимают, как будут реализовываться программные блоки системы, потому что их внутренняя структура формализуется в соответствии с требованиями CMM. Каждый сотрудник - от кодировщика до руководителя - точно знает, что он должен сделать. При возникновении у заказчика новых требований удается оценить риск изменения проекта. В сравнении со вторым уровнем проекты реализуются быстрее и с меньшими затратами. Снижается вероятность отклонения от срока и уменьшается величина этого отклонения. Фирма подготовлена к любым непредвиденным проблемам и способна их решить. Заказчик в любой момент может получить детальную информацию о текущем состоянии проекта. Четвертый уровень. Все ПРПО компании могут быть использованы для работы над программными проектами разной тематики. Процессы оценены по множеству критериев, максимально документированы и легко управляемы. Фактически они превращены в рабочие инструменты. На первый план выходит эффективное управление ПРПО, благодаря чему повышается качество продуктов и продолжают снижаться требования к ресурсам. Для областей, в которых компания уже работала, удается точно уложиться в сроки и бюджет, для новых областей детально оговаривается небольшая зона риска. ПО разрабатывается с заданным качеством. Возникающие проблемы оказывают минимальное воздействие на проект. Фирма создает базу данных по используемым ПРПО и постоянно ее анализирует. От подобного формализованного опыта существенно зависит снижение сроков и затрат на проект. Менеджеры не только в деталях понимают структуру проекта, но и сами начинают управлять ПРПО. Пятый уровень. На этом уровне компания осуществляет непрерывную и неограниченную оптимизацию своих ПРПО. Для каждого процесса определены сильные и слабые стороны и наиболее подходящие области применения. При работе над проектом менеджеры постоянно улучшают используемые процессы, причем степень улучшения поддается количественной оценке. В ПРПО вносятся новые идеи и технологии, анализируются и исправляются ошибки. Менеджеры не просто понимают процессы, но и осознают возможные пути повышения их эффективности. Учебно-исследовательская лаборатория «Информационные технологии» 11 Обзор стандартов проектирования и разработки ПО Лекция 5: Rational Unified Process Краткое описание На сегодняшний день это одна из самых известных методологий. Разработана она компанией Rational Software для поддержки своих продуктов, которых насчитывается более десятка (среди самых знаменитых Rational Rose и Requisite Pro). RUP создан тремя небезызвестными личностями - это Гради Буч, Ивар Якобсон, и Джеймс Рамбо. Итеративность RUP, как и любой современный продвинутый процесс, является итеративным. Это значит, что создание продукта происходит за несколько итераций. В конце каждой итерации получается работающая версия продукта, но с неполным функционалом. В последующих итерациях функционал дорабатывается и в конце последней итерации получается полностью готовый продукт. Идею итеративного процесса можно показать следующим образом: Каждый виток спирали является итерацией. Таким образом, система постепенно обрастает функционалом. Надо сказать, что в RUP прямо не сказано о корректной итеративности процесса. Так что RUP можно успешно использовать и для водопадного процесса, где все стадии следуют строго друг за другом и готовый продукт выходит в самом конце. Поэтому при настройке RUP надо обязательно обратить внимание на итеративность и внедрить ее корректно. Структура RUP Процесс имеет четыре фазы: 1. Исследование (Inception) 2. Уточнение плана (Elaboration) 3. Построение (Construction) 4. Развертывание (Transition) На каждой из фаз основное внимание уделяется разным процессам. На фазе исследования идет сбор и анализ требований, на фазе уточнения плана - анализ требований и проектирование системы, на фазе построения - разработка и кодирование, на фазе развертывания - тестирование и распространение. Методология RUP основана на 9-ти основных потоках: 1. Бизнес-анализ (анализ потребностей) 2. Сбор требований и управление требованиями (перевод требований в функциональные спецификации) 3. Анализ и моделирование (перевод требований в программную модель) 4. Кодирование 5. Тестирование (проверка того, что программа соответствует требованиям) 6. Управление конфигурацией и изменениями (отслеживание изменений в разных версиях Учебно-исследовательская лаборатория «Информационные технологии» 12 Обзор стандартов проектирования и разработки ПО продукта) 7. Управление проектом 8. Создание и поддержка среды разработки 9. Развертывание (все что нужно для продажи или передачи продукта). Все эти девять потоков и четыре фазы изображают в виде затасканной картинки, которую аккуратно вставляют в любую статью о RUP, но объяснение дают не часто. Повторять ее вновь нет особого смысла, лучше все объяснить словами. Любой проект в RUP проходит четыре фазы. Через эти фазы проходят и все девять потоков. Каждая фаза в свою очередь разбивается на итерации. Все визуальное моделирование осуществляется с помощью CASE-средств. Основой для него служит язык UML (Unified Modeling Language), что не удивительно, потому что UML разрабатывался авторами RUP. Сама RUP основывается на шести лучших практиках (best practices): Итеративная разработка Управление требованиями Использование модульных архитектур Визуальное моделирование Проверка качества Отслеживание изменений Они не являются непосредственной частью RUP, но их рекомендуется соблюдать при настройке процесса. Итеративная разработка позволяет на ранней стадии получить работающую версию продукта и выявить критичные недостатки, кроме того, в итоге продукт получается более качественным, потому что база тестируется столько раз, сколько итераций проходит продукт. Управление требованиями - один из важнейших процессов при разработке более-менее серьезных продуктов. Благодаря ему продукт более точно соответствует ожиданиям заказчика. В теории модульная архитектура позволяет повторно использовать код и система получается более гибкой. На практике это практически невозможно реализовать. Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Модели помогают понять, как на самом работает система, что она делает и как она это делает. Кроме того, модели являются средствами коммуникаций между разработчиками, но для этого они должны быть понятны каждому. Вот для этого в RUP используется UML, который позволяет разработчикам говорить на одном языке. Инструментальная поддержка обеспечивается Rational Rose. Отслеживание изменений позволяет оперативно реагировать на изменение требований заказчика, либо на изменяющиеся условия внешней среды. RUP имеет процессы, которые позволяют эффективно отслеживать изменения. Инструментальная поддержка обеспечивается Rational ClearCase и Rational ClearQuest. Учебно-исследовательская лаборатория «Информационные технологии» 13 Обзор стандартов проектирования и разработки ПО Настройка RUP RUP является адаптируемым процессом, то есть его можно настраивать под нужды конкретной команды и под конкретный проект. Более того, это делать совершенно необходимо, поскольку в противном случае эффективность использования RUP будет стремиться к нулю. В RUP 2000, например, насчитывается более 30 ролей и более 50 артефактов. Естественно, что если команда состоит из 5 человек, то просто нет смысла вводить все эти роли и создавать все артефакты. Вообще чем меньше команда, тем легче должен быть процесс. То есть надо создавать минимум артефактов и вводить минимум ролей. Так вот RUP позволяет настроить процесс. Из общего описания RUP можно взять только те процессы, роли и артефакты, которые действительно нужны команде для разработки качественного продукта в срок и в пределах бюджета. Например, возьмем управление требованиями. В общем описании RUP присутствуют следующие артефакты: план управления требованиями, модель сценариев пользователей, спецификация требований системы, видение, репозиторий требований. Для маленького проекта вполне достаточно спецификации требований и набора отдельных сценариев. Но для крупного проекта совершенно необходим репозиторий, потому что без него отслеживание и изменение требований превратиться в головную боль системного аналитика. Учебно-исследовательская лаборатория «Информационные технологии» 14
