Программа по формированию навыков безопасного поведения на дорогах и улицах «Добрая дорога детства» 2
Скачать 1.39 Mb.
|
Аудит проекта. В нем используются следующие методы и средства:
На выходе процесса «Мониторинг и контроль» получаются следующие объекты:
82 14. Сопровождение прикладных программ Комитет IEEE определяет термин «сопровождение программного обеспечения» как «процесс модификации программной системы или ее компонент, проводимый после поставки системы заказчику с целью устранения отказов, улучшения производительности или других параметров системы, или адаптации к изменившемуся программному окружению». Сопровождение программного обеспечения представляет процесс, юзволяющий уже существующим программным продуктам выполнять ;вои функции, с продолжением продаж, установок и использования заказ-шками, таким образом, принося прибыль организации-разработчику. В )бщем смысле, под сопровождением понимают все работы, проводимые 'же после выпуска первоначального продукта. Тем не менее, в обиходе ермин сопровождение применяется не столько к эволюции продукта, колько для описания следующих работ:
Рассмотрим сопровождение программного обеспечения на примере ведущей технологии - Rational Unified Process (RUP). Методология RUP хорошо справляется со всеми упомянутыми задачами. Действительно, эволюция или сопровождение системы полностью неотличимы от процесса создания первоначальной системы. Причем настолько, что стандарт IEEE по сопровождению выглядит как руководство для разработчика, учитывая идентификацию модификаций, анализ, проектирование, реализацию, регрессивное и системное тестирование, тестирование по приемке продукта и его поставку заказчику! 14.1 Циклы разработки ПО В методологии RUP определяется цикл разработки программного обеспечения, который всегда состоит из четырех фаз: 1. Фаза обследования: определение концепции будущей программной системы и экономическое обоснование проекта, определение функциональных границ проекта. 83
В этих фазах важно не то, что вы в них делали, или как долго они проводились, а важно то, чего вам удалось добиться. Фаза оценивается по своим контрольным точкам, причем каждая из основных контрольных точек имеет явно определенные критерии завершения, выраженные в терминах артефактов, которые должны быть созданы или улучшены, а также в количественных показателях. В пределах каждой фазы, разработка программного обеспечения идет итерационно, путем повторения сходных наборов работ и последовательного улучшения создаваемой системы вплоть до момента, когда продукт может быть поставлен заказчику. Эти фазы являются обязательными, но в некоторых случаях проводимые в них работы можно сократить до минимума. Вот один из ключевых принципов RUP: «Не делайте ничего, не имея перед собой цели». Давайте, например, предположим, что вы только что вышли из фазы обследования, и поняли, что имеются все предпосылки для выхода из фазы проработки проекта:
следовало провести для фазы проработки проекта. Обратите внимание, что в этой точке важно все тщательно обдумать - только тогда у вас появится уверенность, что вы действительно находитесь на нужном моменте, а не пытаетесь поспешно начать другую фазу проекта. 84 На рисунке 6 изображен типичный профиль ресурсов для цикла начальной разработки.
lime Рис. 6. Версия 1.0: цикл начальной разработки 14.2 Циклы развития Допустим, что система уже существует, и дальнейшая работа проходит в соответствии с циклом начальной разработки по методологии RUP. Рассмотрим, что произойдет дальше в цикле развития. Этот цикл будет иметь ту же самую последовательность фаз: обследование, проработка проекта, построение системы, передача в эксплуатацию, и закончится выпуском новой версии продукта. Тем не менее, так как система уже существует, отношение усилий, требуемых для проведения фаз, и реально проводимых на каждой фазе работ, будет другим по сравнению с циклом начальной разработки. В цикле начальной разработки требуется провести немало исследований и проявить определенную изобретательность, и артефакты зачастую создаются «с нуля», что происходит главным образом в итерациях фаз обследования и проработки. В противоположность этому, в цикле развития мы работаем, главным образом, над усовершенствованием уже существующих артефактов. Является ли это чем-нибудь новым? Конечно, нет. Это в точности то же самое, что мы уже делали в завершающих итерациях фазы построения системы и во время всей фазы передачи системы в эксплуатацию цикла начальной разработки. Рассмотрим несколько вариантов развития системы. Версия 2.0: Простое расширение функциональности 85 Давайте предположим, что мы выпустили первоначальный продукт: версия 1.0. Цикл развития для перехода к версии 2.0 может выглядеть так, как показано на рисунке 7.  time v 1.0 • ? 2.0 • Рис. 7. Добавление цикла развития для простого расширения функциональности Перед тем, как приступить к выполнению проекта, мы создали экономическое обоснование для перехода к версии 2.0. В этой версии нужно обеспечить следующие возможности.
Если ни одна из этих задач не влияет на архитектуру приложения, и отсутствует риск ослабления функциональных возможностей, тогда фаза проработки проекта сокращается до одного-двух дней работы. Построение системы (до бета-версии) и передача в эксплуатацию происходят итерационно в соответствии с циклом начальной разработки, с тем же самым персоналом и тем же распределением ролей. Все артефакты обновляются в соответствии с развитием. Цикл процесса разработки изображен на рисунке 86 initial cycle Evolution cycle ___ __ j __ j.». Рис. 8. Добавление цикла развития с минимальной фазой проработки проекта Версия 3.0: Существенное расширение функциональности Далеко не все циклы развития могут быть настолько просты. Давайте предположим, что, основываясь на успехе версии 2.0 (однопользовательской, однопроцессорной версии), требования к версии 3.0 будут включать распределенную систему, поддерживающую несколько пользователей. Затем нам нужно провести ответственную фазу проработки проекта для усовершенствования и утверждения архитектуры системы, так как эволюция представляет собой достаточно рискованный шаг. Теперь цикл будет больше походить на оригинальный профиль цикла начальной разработки (см. рисунок 6), с нетривиальными работами обследования и проработки процесса. 14.3 Циклы сопровождения Теперь рассмотрим наиболее типичные случаи улучшающего и адаптивного сопровождения. Версия «исправление ошибок»: улучшающее сопровождение Допустим, что нам нужна новая версия системы, в которой исправлены некоторые уже изрядно надоевшие проблемы, обнаруженные пользователями. Цикл развития будет включать:
87
Вот ключевые факторы для успеха - все проделываемые нами работы уже присутствовали в RUP. Альтернатива: Расширение фазы передачи в эксплуатацию с помощью большего числа итераций. Если улучшающее сопровождение влечет за собой лишь минимальное число изменений, в этом случае вы можете рассматривать его просто как дополнительную итерацию в вашей фазе передачи в эксплуатацию (см. рисунок 9). Если мы рассматриваем это как экстремальное обстоятельство, то в таком случае мы имеем образец инкрементной поставки: после того, как проделана интенсивная первоначальная работа, наступает следующий этап - система начинает постепенно поставляться заказчику, с добавлением дополнительной функциональности на каждом шаге. Initial cycle Additional transition iterations
lime i.o * & тг Vi.l ¥1.2 Рис. 9. Добавление небольших итераций улучшающего сопровождения в фазу передачи системы в эксплуатацию 88 Пример: Задачи для простого улучшающего сопровождения Ниже представлен список задач, выполнение которых может потребоваться при простой итерации улучшающего сопровождения: Задача: разработка плана итерации. Цели определяются выбором выполняемых запросов на изменение. Задача: планирование тестирования. Идентификация определенного теста для проверки исправления и полного набора регрессивных тестов, которые нужно провести перед выпуском окончательной версии. Задача: распределение работ. Задача: создание рабочего пространства. Задача: создание интеграционного рабочего пространства. Задача: исправление ошибок. Это повторяется для каждого дефекта. Задача: выполнение тестов. Задача: интеграция системы. Задача: выполнение системных тестов. Это включает все тесты, которые нужно выполнить для проверки новой версии выпускаемого продукта. Задача: создание базовой версии. Задача: создание описания новой версии. Задача: модификация запроса на изменение. Задача: проведение подготовки акта о приемке работ по итерации. Задача: выпуск продукта. Версия для совместимости: адаптивное сопровождение Зачастую нам требуется новая версия продукта, из-за того, что обновилась одна из частей общей системы. Это могут быть изменения компонента системы, например такого, как база данных, или некоторых элементов системного окружения, скажем, операционной системы, платформы или коммуникационного интерфейса. Для сохранения совместимости продукта нам иногда следует перестроить и, практически всегда, повторно протестировать программную систему, содержащую новые элементы. В простом случае, потребуется изменить лишь несколько артефактов, а основное время займет повторная генерация системы и ее тестирование. Если интерфейс системы изменился, тогда потребуется провести некоторое проектирование и кое-где поменять программный код. Все работы, которые | ||||||||||||||||||
