Читайте также:
|
RAD-модель
Модель быстрой разработки приложений (Rapid Application Development) появилась в 80-х годах прошлого века и является еще одним примером реализации инкрементной стратегии. Предполагает выделение в системе нескольких основных бизнес-функций и разработку каждой из них отдельной группой разработчиков с последующей интеграцией в целую систему
Характеристика:
p Основным достоинством модели является уменьшение сроков разработки
p Ее главный недостаток заключается в необходимости использования большого числа квалифицированных разработчиков, что может существенно повысить стоимость разработки
Спиральная модель
p Модель определяет четыре действия:
n планирование
n анализ рисков
n конструирование
n оценивание.
p Планирование заключается в определении целей очередной итерации процесса разработки, выборе вариантов решения и оценки ограничений
p Анализ рисков – анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов
p Конструирование – это основное действие, заключающееся в создании следующей версии ПО
p Оценивание – оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований
Достоинства модели: данная модель отображает процесс разработки ПО в наиболее реальном виде; позволяет явно учитывать риски на каждом витке эволюционного процесса и принимать различные управленческие решения вплоть до прекращения работ
Недостатки модели: повышенные требования к заказчику; трудности контроля и управления временем разработки
В настоящее время все большее распространение получают адаптивные или облегченные, «живые» (agile) процессы разработки. Они не требуют столь жесткой регламентации, допускают возможность частых и существенных изменений требований заказчиков. Адаптивные процессы делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки. Они избегают фиксации четких схем действий, чтобы обеспечить б о льшую гибкость в каждом конкретном проекте и не требуют разработки дополнительных промежуточных документов
Принципы «живой» разработки
Основные принципы «живой» разработки ПО зафиксированы в манифесте, появившемся в 2000 году:
n Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты
n Работающая программа более важна, чем исчерпывающая документация
n Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
n Отработка изменений более важна, чем следование планам.
Экстремальное программирование
Наиболее часто используемой адаптивной моделью является модель экстремального программирования (eXtreme Programming, XP-процесс). XP-процесс ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределенных или быстро меняющихся требований
XP-процесс
Основная идея XP-процесса – устранение высокой стоимости внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций. Базовыми действиями являются:
n кодирование,
n тестирование,
n выслушивание заказчика,
n проектирование
Принципы XP
Высокий динамизм разработки обеспечивается следующими принципами:
n непрерывная связь с заказчиком,
n простота выбираемых решений,
n быстрая обратная связь на основе оперативного тестирования,
n профилактика рисков
Реализация этих принципов достигается за счет использования следующих методов:
n Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система
n Простое проектирование – принимаются наиболее простые
n Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант
n Реорганизация (Refactoring) – улучшение структуры системы при сохранении ее поведения
n Парное программирование – код пишется двумя программистами на одном компьютере
n Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы
n Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований
n Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика
n Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы
Руководство проектом определяет сущность процесса разработки от его начала до конца. Оно обеспечивает: оценку объема предстоящих работ; оценку требуемых ресурсов; оценку возможных рисков; составляет или корректирует план работ; определяет первоочередные задачи; устанавливает вехи – точки контроля промежуточных результатов.
Процесс оценки
Оценка объема предстоящих работ производится в человеко-месяцах.
Исходя из нее определяют необходимые ресурсы:
n продолжительность работ (в календарных датах)
n число разработчиков
n стоимость (в тыс. рублей)
При оценках используется опыт предыдущих собственных разработок, либо опыт других разработчиков.
Для оценки различных свойств процесса создания программного продукта, а также и самого продукта, применяются количественные характеристики, называемые мерами.
Путем непосредственного измерения определяются опорные свойства. Остальные свойства оцениваются путем вычисления функций от опорных значений. Такие функции называются метриками.
Размерно-ориентированные метрики
Основаны на LOC-оценках, т.е. на количестве строк в текстах программ (Lines Of Code). К числу размерно-ориентированных метрик относятся: производительность; качество; удельная стоимость; документированность.
Производительность = Длина [тыс. LOC]/Затраты [чел-мес]
Качество = Ошибки [единиц]/Длина [тыс. LOC]
Удельная стоимость = Стоимость [тыс. рублей]/Длина [LOC]
Документированность = Страниц документа/ Длина [LOC]
Достоинства: основаны на объективных данных, просты и легко вычислимы
Недостатки: зависят от языка программирования, трудновыполнимы на начальной стадии проекта, не приспособлены к непроцедурным языкам программирования
Дата добавления: 2015-01-30; просмотров: 36 | Поможем написать вашу работу | Нарушение авторских прав |