Постоянная адаптация к изменяющимся обстоятельствам.

Удовлетворение клиента за счет ранней и бесперебойной поставки ценного ПО.

Приветствие изменения требований, даже в конце разработки.

Частая поставка рабочего ПО.

Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта.

Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием

6. Рекомендуемый метод передачи информации – это личный разговор.

7. Работающее ПО – лучший измеритель прогресса.

8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок.

Постоянное внимание на улучшение технического мастерства и удобный дизайн.

Простота- искусство не делать лишней работы.

Лучшая архитектура, требования и дизайн получатся у самоорганизуемой команды.

Постоянная адаптация к изменяющимся обстоятельствам.

Методики гибкой разработки:

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

игра в планирование, переработки кода (refactoring), короткие релизы, метафоры, простой дизайн, разработка «тестами вперед», коллективное владение кодом, парное программирование, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода.

SCRUM

Разбитие планируемого времени на жёсткие участки. Выпуск прототипов привязан к окончанию времени (спринт), не смотря на функционал. Ежедневные короткие совещания. Для проекта в целом ведется бэклог (backlog) – список задач, которые необходимо решить в ходе выполнения проекта. Бэклог не изменяется для спринта.

ежедневные собрания. Каждый член команды должен ответить на 3 вопроса:

· Что я сделал?

· Что я буду делать дальше?

· Что мне мешало работать или что повысит производительность?

Строгая специализация в ходе спринта.

+100% времени дают 600% производительность.

Метод разработки динамических систем ( Dynamic System Development Method DSDM ) .

Основан в 1994 году в Великобритании, консорциумом из 17 английских компаний. DSDM состоит из двух этапов:

· Изучение осуществимости программы и области ее применения

o Подходит ли DSDM для данного проекта

o Изучение области применения программы

o Разработка основных положений архитектуры и плана проекта

· Работа над проектом (этот этап делится на три взаимосвязанных цикла)

o Цикл функционального моделирования (отвечает за создание документации и прототипов)

o Цикл проектирования и конструирования (отвечает за приведение системы в рабочее состояние)

o Цикл реализации ( отвечает за развертывание программы)

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

Адаптивная разработка (ASD)

В ASD обычный статический жизненный цикл Plan-Design-Build (Планирование - Проектирование - Конструирование) заменен на динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие - Обучение).

Crystal Clear

Методология, позволяющая менять степень формализации процесса разработки в зависимости от критичности задач и количества участников разработки. Основные особенности: итеративная инкрементная разработка, автоматическое регрессионное тестирование, пользователи привлекаются к активному участию в проекте, состав документации определяется участниками проекта, как правило, используются средства контроля версий кода. Ориентирована на поддержание естественных привычек разработчиков. Считается, что если в организации не используется какая-то определенная методология, то достаточно квалифицированный коллектив рано или поздно сам естественным образом придёт к этой Crystal Clear.

Функционально-ориентированная разработка. Feature Driven Development (FDD)

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

Разработка по ГОСТ

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

_______________________

COnstructive COst MOdel (COCOMO – модель конструктивных затрат) – это алгоритмическая модель оценки стоимости разработки программного обеспечения, позволяющая оценить трудоемкость и время разработки программного продукта.

Название режима Размер проекта

Органичный До 50 KSLOC

Полуразделенный 50–300 KSLOC

Встроенный Более 300 KSLOC

человеко-месяц – это 19 рабочих дней в месяце (или 152 рабочих часа в месяц)

Трудоемкость E (Effort Applied) = a * Размер^b, [человеко-месяцев]

Длительность выполнения проекта D (Development Time) = 2,5 * E^k, [месяцев]

Таблица 2. Значения коэффициентов модели COCOMO в зависимости от режима использования

Название режима Значение коэффициента

a b k

Органичный 2,4 1,05 0,38

Полуразделенный 3 1,12 0,35

Встроенный 3,6 1,2 0,32

Число разработчиков P (People required) = D / E, [человек]

Произведение всех множителей трудоемкости составляет Регулирующий фактор трудоемкости effort adjustment factor (EAF):

Формула модели COCOMO для среднего уровня принимает вид

Трудоемкость (E) = a * Размер^b*EAF, [человеко-месяцев]

Длительность выполнения проекта D (Development Time) = 2,5 * E^k, [месяцев]

Число разработчиков P (People required) = D / E, [человек]

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

Модель COCOMO подходит только для ПО, разрабатываемого по каскадной модели. Кроме этого при уточнении возрастает ее сложность. Ее развитием стала модель COCOM II.

К более простым моделям относятся, например:

1. Количество строчек кода. «индусский код»

2. Объектно-ориентированные методики

3. Статистические методики

4. Методики, оценивающие связность нашего продукта

5. Методики оценки графа параллельности (если наша программа должна выполняться в несколько потоков, на разных вычислительных системах и т.д.)

6. Метрики, которые оценивают стилистику и понятность кода

Функциональная Точка – это работа, которую человек может выполнить за 1-2 дня. У программиста это будет примерно 100 строк кода на языке С/С++. У технического редактора – 6-8 страниц документации. У дизайнеров это будет какое-то количество изображений, которое они рисуют за 1-2 дня и т.д.

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

Более формальные методики, например объектно-ориентированные методики Мы берем не просто класс, а взвешенную насыщенность класса - это мера, которая несколько приближенно позволяет оценить насколько класс сложен по количеству его функции, по количеству объектов, с которыми этот класс будет взаимодействовать.

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

В общем случае оцениваются совершенно разные параметры. И оценивают не только кол-во строк кода. Например, мы должны оценивать:

· Усилия разработчика при реализации

· Длина и объем программы

· Анализ цикломатической сложности (чем выше сложность алгоритма, тем сложнее его отлаживать)

· Усилия программиста при разработке

· Количество строк на реализацию требования

· Количество комментариев на единицу кода

· Прочие количественные метрики (число функций, классов, файлов)

· Плотность дефектов на единицу кода