«большую»

Вид материала

Лекция

Содержание Рисунок 1. Стандарты, описывающие структуры жизненного цикла ПО. Рисунок 2. Последовательность разработки согласно «общепринятой» водопадной модели. Унифицированный процесс Rational Фаза начала проекта (Inception) Фаза проработки (Elaboration) Фаза построения (Construction) Фаза передачи (Transition) Экстремальное программирование Рисунок 4. Схема процесса XP.

Подобный материал:

• «Путевка в большую жизнь», 8.12kb.
• Аллы Викторовны Албеговой, главы департамента экологии и природопользования Кировской, 148.67kb.
• Экономика Республики Казахстан испытывает большую нужду в кадрах практически всех специальностей,, 101.64kb.
• Мы, учащиеся 8 в класса, готовились заранее к новогоднему празднику. Принесли ёлку, 16.17kb.
• Эрик В. Гуннемарк, 1826.8kb.
• Реферат по «Культурологии» на тему: Буддизм, 271.04kb.
• Правиле крестьянского выхода в юрьев день, 50.94kb.
• Фольклорно-этнографическая группа, 43.2kb.
• Макарова Татьяна Викторовна Форма экспертного материала доклад, 135.72kb.
• Тема урока: Закономерности модификационной изменчивости, 30.88kb.

Технологии программирования. Компонентный подход

В. В. Кулямин

Лекция 2. Жизненный цикл ПО. Процессы разработки ПО.

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

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

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

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

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

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

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

Международными организациями, такими как IEEE (читается «ай-трипл-и», Institute of Electrical and Electronic Engineers, Институт инженеров по электротехнике и электронике), ISO (International Standards Organization, Международная организация по стандартизации), EIA (Electronic Industry Association, Ассоциация электронной промышленности), IEC (International Electrotechnical Commission, Международная коммиссия по электротехнике) а также некоторыми национальными исследовательскими институтами (ANSI, American National Standards Institute, Американский национальный институт стандартов; SEI, Software Engineering Institute, Институт программной инженерии), разработан набор стандартов, регламентирующих различные аспекты жизненного цикла ПО и вовлеченных в него процессов. Список и общее содержание этих стандартов таковы.

• Группа стандартов ISO
  
  • ISO/IEC 12207 Standard for Information Technology — Software Life Cycle Processes (есть российский аналог ГОСТ Р-1999)
    Определяет структуру процессов жизненного цикла ПО, которые, согласно ему, включают
    
    • Основные процессы:
      Приобретение ПО, Передача ПО (в использование), Разработка ПО, Эксплуатация ПО, Поддержка ПО
      
    • Поддерживающие процессы:
      Документирование, Управление конфигурациями, Обеспечения качества, Верификация, Валидация, Совместные экспертизы, Аудит, Разрешение проблем
      
    • Организационные процессы:
      Управление проектом, Управление инфраструктурой, Усовершенствование процессов, Обучение
      
  • ISO/IEC 15288 Standard for Systemы Engineering — System Life Cycle Processes
    Отличается от предыдущего нацеленностью на рассмотрение систем в целом, т.е. программно-аппаратных систем.
    В данный момент продолжается работа по интеграции этих двух стандартов.
    
  • ISO/IEC 15504 (SPICE) Standard for Information Technology — Software Process Assessment
    Определяет правила оценки процессов жизненного цикла ПО и их возможностей, опирается на модель CMMI (см. ниже) и ориентирован на оценку возможности улучшения процессов
    
• Группа стандартов IEEE
  
  • IEEE Std 1074-1997 IEEE Standard for Developing Software Life Cycle Processes
    Описывает структуру процессов разработки и сопровождения, а также связанных с ними, определяет основные виды деятельностей, выполняемых в рамках этих процессов и документы, требущиеся на входе и возникающие на выходе этих деятельностей.
    
  • IEEE/EIA Std 12207-1997 IEEE/EIA Standard: Industry Implementation of International Standard ISO/IEC 12207:1995 Guide for Information Technology — Software Life Cycle Processes
    Аналог ISO/IEC 12207, сменил ранее использовавшиеся
    J-Std-016-1995 EIA/IEEE Interim Standard for Information Technology--Software Life Cycle Processes--Software Development Acquirer-Supplier Agreement
    и стандарт министерства обороны США
    MIL-STD-498
    
• Группа стандартов, связанная с моделью зрелости возможностей CMM (Capability Maturity Model)
  
  • Собственно, модель CMM описывает различные степени зрелости процессов в организациях, определяя 5 уровней организаций
    
    • Уровень 1, начальный.
      Организации, разрабатывающие ПО, но не имеющие осознанного процесса разработки, не производящие планирования и оценок, находятся на этом уровне
      
    • Уровень 2, повторяемый.
      В таких организациях ведется учет затрат ресурсов и отслеживается ход проектов, установлены правила управления проектами, основанные на имеющемся опыте
      
    • Уровень 3, определенный.
      В таких организациях имеется принятый, полностью документированный процесс разработки ПО, включающий как управленческие, так и технические подпроцессы.
      
    • Уровень 4, управляемый.
      В этих организациях, помимо установленного и описанного процесса, используются показатели качества продуктов и процессов, позволяющие достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством
      
    • Уровень 5, совершенствующийся.
      В таких организациях , помимо процессов и методов их оценки, установлены процедуры поиска и оценки новых методов и техник разработки, обучения персонала работе с ними и их включения в общий процесс организации в случае повышения ими эффективности производства
      
  • CMMI
    Результат интеграции моделей CMM для продуктов и процессов
    mu.edu/cmmi/models/
    

В целом эти стандарты связаны следующим образом (стрелки указывают направления исторического развития).



Рисунок 1. Стандарты, описывающие структуры жизненного цикла ПО.

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

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

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

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

К последовательным моделям — в них предполагается, что работы разных видов выполняются в некоторой предписанной последовательности, т.е. что можно отождествить определенную фазу существования ПО с некоторой основной деятельностью, которая выполняется на этой фазе — относят так называемую водопадную (waterfall) модель, которая, как считается, была впервые четко сформулирована в работе [1] и впоследствии была принята как стандарт министерства обороны США в семидесятых-восьмидесятых годах XX века. Предлагаемая в этой статье последовательность шагов разработки выглядит так, как показано на рис. 1.



Рисунок 2. Последовательность разработки согласно «общепринятой» водопадной модели.

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

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

Расмотрим два основных примера итеративных процессов — это унифицированный процесс Rational (Rational Unified Process, RUP) и экстремальное программирование.

Унифицированный процесс Rational

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

1. Фаза начала проекта (Inception)
   Основная цель этой фазы — достичь компромисса между всеми заинтересоваными лицами относительно задач проекта.
   На этой фазе определяются основные цели проекта, руководитель проекта и бюджет проекта, основные средства его выполнения — технологии, инструменты, ключевой персонал, а также происходит, возможно, апробация выбранных технологий с целью подтверждения возможности достичь целей с их помощью, составляются предварительные планы проекта.
   
2. Фаза проработки (Elaboration)
   Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы.
   
3. Фаза построения (Construction)
   Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.
   
4. Фаза передачи (Transition)
   Цель этой фазы — сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.
   

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

• Моделирование предметной области (бизнес-моделирование, Business Modeling)
  Цели этой деятельности — понять бизнес-контекст, в котором должна будет работать система (и убедиться, что все заитересованные лица понимают его одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система.
  в результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющий бизнес-операции и бизнес-процессы).
  
• Определение требований (Requirements)
  Цели — понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем.
  Требования принято фиксировать в виде модели вариантов использования (use cases).
  
• Анализ и проектирование (Analysis and Design)
  Цели — выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования.
  В результате проектирования должна появиться проектная модель, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов, и диаграммы развертывания.
  
• Реализация (Implementation)
  Цели — определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое
  
• Тестирование (Test)
  Цели — найти и описать дефекты системы (проявления ее недостаточного качества), оценить ее качество в целом, оценить выполнение гипотез, лежащих в основе проектирования, оценить степень соответствия истемв требованиям
  
• Развертывание (Deployment)
  Цели — развернуть систему в ее рабочем окружении и оценить ее работоспособность
  
• Управление конфигурациями и изменениями (Configuration and Change Management)
  Цели — определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений
  
• Управление проектом (Project Management)
  Цели — планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта
  
• Управление средой проекта (Environment)
  Цели — подстройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте
  

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



Рисунок 3. Распределение работ в проекте по RUP.

Основные техники, используемые в RUP таковы

• Выработка концепции проекта (project vision) в самом его начале для четкой постановки задач
  
• Управление по плану
  
• Снижение рисков и отслеживание их последствий, работа по преодалению рисков должна начинаться как можно раньше
  
• Тщательное экономическое обоснование всех действий, делается только то, что нужно заказчику
  
• Выявление требований и их фиксация в виде вариантов использования (use cases).
  
• Формирование базовой архитектуры как можно раньше.
  Вообще, архитектура системы является хребтом всего проекта в RUP. На основе архитектуры организуются большинство деятельностей. Архитектура фиксируется в виде нескольких моделей, используемых и обновляемых по ходу всего проекта.
  И архитектурные модели, и модели вариантов использования оформляются на графическом унифицированном языке моделирования (unified modeling language, UML).
  
• Использование компонентной архитектуры
  
• Прототипирование, инкрементная разработка и тестирование
  
• Регулярные оценки текущего состояния
  
• Управление изменениями, постоянная отработка изменений извне проекта
  
• Создание продукта, работоспособного в реальном окружении
  
• Нацеленность на качество
  
• Адаптация процесса под нужды проекта
  

Экстремальное программирование

Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх». Этот подход является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, Метод разработки динамичных систем), Feature-Driven Development (Разработка, управляемая характеристиками результата) и пр.

Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки [3].

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

Тем не менее, XP имеет свою схему процесса разработки (хотя широко используемое понимание «процесса разработки» противоречит «живости» разработки).

Р
исунок 4. Схема процесса XP.

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

• Живое планирование (planning game)
  Его задача как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в превую очередь, бизнес-приоритетов заказчика и, во-вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.
  
• Частая смена версий (small releases)
  Самая первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.
  
• Метафора (metaphor) системы
  Метафора в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.
  
• Простые проектные решения (simple design)
  В каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Не надо добавлять функции «заранее» — только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.
  
• Разработка на основе тестирования (test-driven development)
  Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.
  
• Постоянная переработка (refactoring)
  Программисты постоянно перерабатывают систему для устранения излишней сложности, увеличения понятности кода, повышения его гибкости, но не изменяя его поведения, что проверяется прогоном тестов. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат.
  
• Программирование парами (pair programming)
  Весь код пишется двумя программистами на одном компьютере. Объединение в пары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытается наилучшим способом решить текущую задачу. Второй программист обдумывает последствия, новые тесты, менее прямые, но более гибкие возможности решения.
  
• Коллективное владение кодом (collective ownership)
  В любой момент любой член команды может изменить любую часть кода, но он же несет ответственность за эти изменения.
  
• Постоянная интеграция (continuous integration)
  Система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции.
  
• 40-часовая рабочая неделя
  Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.
  
• Включение заказчика в команду (on-site customer)
  В составе команды разработчиков постоянно находится представитель заказчика, который доступен в течении всего рабочего дня и способен отвечать на все вопросы о системе.
  
• Использование кода как средства коммуникации
  Код рассматривается как важнейшее средство общения внутри команды. Ясность кода — один из основных приоритетов. Следование стандартам кодирования, обеспечивающим такую ясность, обязательно. Такие стандарты, помимо ясности кода, должны обеспечивать минимальность выражений (запрет на дублирование кода и информации) и должны быть приняты всеми членами команды.
  
• Открытое рабочее пространство (open workspace)
  Команда размещается в одном, достаточно просторном помещении, для упрощения коммуникации и возможности проведения коллективных обсуждений при планировании и принятии важных технических решений.
  
• Изменение правил по необходимости (just rules)
  Каждый член команды должен принять перечисленные правила, но при возникновении необходимости команда может поменять их ,если все ее члены пришли к согласию по поводу этого изменения.
  

Как видно, XP рассчитано на использование в рамках небольших команд (не более 10 программистов) , что подчеркивается и авторами этой методики, больший размер команды разрушает легкость коммуникации.

Литература

1. W. W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, pp. 1–9, August 1970.
   Переиздана: Proceedings of the 9^th International Software Engineering Conference, Computer Society Press, pp. 328–338, 1987.
   
2. Kroll, The Spirit of the RUP. ссылка скрыта
   
3. ссылка скрыта
   
4. И. Соммервилл. Инженерия программного обеспечения. Вильямс, 2002.
   
5. У. Ройс. Управление проектами по созданию программного обеспечения. М., Лори, 2002.
   
6. А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программного обеспечения. Питер, 2002.
   
7. Э. Дж. Брауде. Технология разработки программного обеспечения. Питер, 2004.
   
8. К. Бек. Эктремальное программировнаие. Питер, 2002.
   
9. I. Jacobson, M. Christenson, P. Jonsson, G. Overgaard. Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley, 1994.