Порядок разработки программного обеспечения. Модели разработки программного обеспечения

Этапы разработки программного обеспечения

Процесс разработки программного обеспечения можно разбить на этапы (фазы):

– разработка модели и выбор метода решения;

– разработка алгоритма решения задачи;

– кодирование алгоритма;

– компиляция программы;

– тестирование программы;

– создание документации;

– сопровождение и эксплуатация.

В результате выполнения этого этапа работы составляется документ, называемый "Задание на разработку программного обеспечения (техническое задание)". В нем указывается следующее:

– название задачи. Дается краткое определение решаемой задачи, название программного комплекса, указывается система программирования для ее реализации и требования к аппаратному обеспечению;

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

– управление режимами работы программы. Формулируются основные требования к способу взаимодействия пользователя с программой (интерфейс пользователь-компьютер).

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

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

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

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

Разработка модели и выбор метода решения . На этом этапе создается математическая или логиче­ская модель исследуемого явления реального мира. При этом нужно уметь сформулировать на языке математики конкретные задачи физики, экономики, технологии и т.д. После того как определена математическая модель задачи, надо выбрать метод ее решения. Если программируемая задача носит вычислительный характер, то приводится вывод всех используемых формул с подробными комментариями. Если же задача невычислительная, то приводится словесное описание логической модели, например, в виде плана действий.

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

В процессе разработки алгоритма могут быть использованы различные способы его описания: словесная запись, блок-схемы, псевдокод, структурограммы и т.п.

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

Кодирование алгоритма. Этап кодирования (программирования) алгоритмов заключается в переводе алгоритмов, разработанных для каждого программного модуля, в программы на конкретном языке программирования. Результатом выполнения этого этапа являются файлы с исходными текстами программ. Эти файлы по своей природе текстовые, только они содержат тексты, написанные на языке программирования (в нашем случае это тексты, написанные на языке Си).

Компиляция программы. После того как закончено кодирование (написание программы на языке программирования) и исходный текст программы введен в память компьютера, производят компилирование программы, т.е. перевод исходного текста в машинный код. Этот процесс осуществляется специальной программой – компилятором. На рисунке 1 представлена схема подготовки исполняемой программы.

Сначала программа передается препроцессору , который выполняет директивы , содержащиеся в ее тексте (например, #include - включение файла в текст программы).

Получившийся текст передается на вход компилятора (Compiler ) , который выделяет лексемы (отдельные слова), а затем на основе грамматики языка распознает выражения и операторы, построенные из этих лексем. При этом компилятор выявляет синтаксические ошибки и в случае их отсутствия строит объектный модуль.

Компоновщик, или редактор связей (Linker ) , формирует исполняемый модуль программы, подключая к объектному модулю другие объектные модули, в том числе содержащие функции библиотек, обращение к которым содержится в любой программе. При успешном завершении процесса образуется исполняемый файл программы (файл с расширением EXE).

Тестирование программы. Различается два вида тестирования: автономное и комплексное. При автономном тестированию подвергаются отдельные программные модули, из которых состоит программный комплекс. Комплексное тестирование заключается в проверке всего программного комплекса. Для тестирования подбираются такие исходные данные, для которых результат выполнения программы заранее известен.

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

Описание применения – общая характеристика программного продукта и сферы его применения, требований к базовому программному обеспечению, комплексу технических средств обработки.

Руководство пользователя – детальное описание функциональных возможностей и технологии работы с программным продуктом для конечного пользователя. Документы данного вида могут офор­мляться в печатном виде и (или) "встраиваться" в программный комплекс (в последнем случае помощь в виде подсказки вызывается самим пользо­вателем в процессе работы программного комплекса).

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

Задание на разработку программного обеспечения (техническое зада­ние);

Спецификация;

Прокомментированные исходные тексты (листинги) модулей програм­мы и управляющего модуля;

Схема разбиения программного комплекса на программные модули;

Схема потоков данных программного комплекса;

Схема взаимодействия программных модулей;

Планы и данные для тестирования программного комплекса;

Другие материалы, иллюстрирующие проект, например: блок-схемы программного комплекса и программных модулей.

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

Методология разработки софта - организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам. Выделим 12 видов:

  • Waterfall - традиционный подход.
  • RUP (Rational Unified Process) - рациональный.
  • Agile - общая методология гибкой разработки.
  • Crystal Clear - подход с уравниванием разработчиков в коллективе.
  • Spiral - спиральный метод.
  • DSDM (Dynamic Systems Development Model) - динамическая модель.
  • FDD (Feature Driven Development) - методология, рассматривающая будущие изменения.
  • JAD (Joint Application Development) - ориентированный на пользователя подход.
  • RAD (Rapid Application Development) - модель быстрой разработки.
  • Scrum - концепция работы в условиях сорванных сроков и идеологического кризиса.
  • XP (Extreme Programming) - экстремальная разработка в динамической среде.
  • LD (Lean Development) - метод, предполагающий бережное отношение ко всем участникам процесса.

Давайте попробуем разобраться, что скрывается за этими английскими названиями.

Waterfall

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

На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе - это дорогостоящие исправления.

RUP

RUP - итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:

  • Учитывает изменяющиеся требования. Как бы ни был хорош руководитель проекта, учесть всё в начале невозможно.
  • Интеграция функций происходит постепенно, то есть каждая «деталь» проходит цикл разработки, проверки и внедрения в проект. Как следствие, снижаются риски и стоимость производства.
  • Ранний выпуск продукта. ПО выходит с уменьшенной функциональностью, чтобы занять нишу на рынке и противостоять конкурентам, после чего обрастает «мясом».
  • Повторное использование. При наращивании функциональности проще выделить типовые решения, которые сократят разработку.
  • Постоянное обучение. Из-за частых итераций разработчики не имеют больших пауз между доработкой кода, поэтому профессиональный рост происходит плавно и безболезненно.
  • Постоянное улучшение продукта. Итерации позволяют оценить проект не только с точки зрения соответствия плану и ТЗ, но и найти пути увеличения эффективности и качества продукта.

Agile

Agile - метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:

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

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

Crystal Clear

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

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

Spiral

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

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

DSDM

Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс - исследовательская работа.

В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.

FDD

FDD - процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:

  • Разработка каждого крупного проекта должна иметь системность.
  • Процессы должны быть простыми и проработанными.
  • Ценность и логичность процесса должна быть ясна каждому члену команды.
  • Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.

FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.

JAD

JAD - это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.

В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.

RAD

RAD - методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий - использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:

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

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

Scrum

Scrum - гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).

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

XP

Экстремальное программирование - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

  • Игра в планирование. В начале проекта есть только приблизительный план, после каждой итерации его чёткость возрастает.
  • Высокая частота релизов. Новая версия продукта имеет незначительные изменения по сравнению с предыдущей, но время на выпуск при этом минимально.
  • Контакт с клиентом. Для удовлетворения требований конечной аудитории необходимо оперативное реагирование на замечания и пожелания.
  • Рефакторинг. Улучшение качества кода без уменьшения функциональности.
  • Стандарт выполнения кода. Или применяются общие правила, или разногласия в оформлении не подлежат обсуждению и критике.
  • Коллективная ответственность. Несмотря на то, что каждый член команды выполняет свой участок работ, за код в целом отвечает весь коллектив.

LD

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

  • Поощрении сотрудников за успешную работу.
  • Изменении текущих задач только по мере необходимости или по запросу заказчика.
  • Строгом выполнении плана: всё, что сверх - считается потерями времени и ресурсов.
  • Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

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

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

«Как получится». Разомкнутая система управления. Полное доверие техническим лидерам. Представители бизнеса практически не участвуют в проекте. Планирование, если оно и есть, то неформальное и словесное. Время и бюджет, как правило, не контролируются. Аналогия: баллистический полет без обратной связи. Можно, но недалеко и неточно.

«Водопад» или каскадная модель. Жесткое управление с обратной связью. Расчет опорной траектории (план проекта), измерение отклонений, коррекция и возврат на опорную траекторию. Лучше, но не эффективно.

«Гибкое управление». Расчет опорной траектории, измерение отклонений, расчет новой попадающей траектории и коррекция для выхода на нее. «Планы - ничто, планирование - все» (Эйзенхауэр, Дуайт Дэвид)

«Метод частых поставок». Самонаведение. Расчет опорной траектории, измерение отклонений, уточнение цели, расчет новой попадающей траектории и коррекция для выхода на нее.

Классические методы управления перестают работать в случаях, когда структура и свойства управляемого объекта нам не известны и/или изменяются со временем. Эти подходы так же не помогут, если текущие свойства объекта не позволяют ему двигаться с требуемыми характеристиками. Например, летательный аппарат не может развить требуемое ускорение или разрушается при недопустимой перегрузке. Аналогично, если рабочая группа проекта не может обеспечить требуемую эффективность и поэтому постоянно работает в режиме аврала, то это приводит не к росту производительности, а к уходу профессионалов из проекта.

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

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

Известно, что производительность разных программистов может отличаться в десятки раз. Утверждаю, что производительность одного и того же программиста может так же отличаться в десятки раз. Заставьте лучшего в мире бегуна бегать в мешке, и он покажет в 10 раз худший результат. Заставьте лучшего программиста заниматься «сизифовым трудом»: плодить документацию (которую, как правило, никто не читает) в угоду «Методологии» (именно с большой буквы М), - и его производительность снизится в 10 раз.

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

Модели (или, как еще любят говорить, методологии ) процессов разработки ПО принято классифицировать по «весу» – количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше «вес» модели.

Наиболее распространенные современные модели процесса разработки ПО представлены на рис. 2.3.

Рис. 2.3. Различные модели процесса разработки ПО

ГОСТы

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

В середине 80-х годов минувшего столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения.

Данная модель определяет пять уровней зрелости процесса разработки ПО.

1) Начальный - процесс разработки носит хаотический характер. Определены лишь немногие из процессов, и успех проектов зависит от конкретных исполнителей.

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

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

4) Управляемый - собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных.

5) Оптимизируемый - постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

Унифицированный процесс (Rational Unified Process, RUP) был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.

Microsoft Solutions Framework (MSF) - это гибкая и достаточно легковесная модель, построенная на основе итеративной разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.

Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process . Personal Software Process определяет требования к компетенциям разработчика. Согласно этой модели, каждый программист должен уметь:

· учитывать время, затраченное на работу над проектом;

· учитывать найденные дефекты;

· классифицировать типы дефектов;

· оценивать размер задачи;

· осуществлять систематический подход к описанию результатов тестирования;

· планировать программные задачи;

· распределять их по времени и составлять график работы.

· выполнять индивидуальную проверку проекта и архитектуры;

· осуществлять индивидуальную проверку кода;

· выполнять регрессионное тестирование.

Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков. Команды должны:

· установить собственные цели;

· составить свой процесс и планы;

· отслеживать работу;

· поддерживать мотивацию и максимальную производительность.

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

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

Выбор модели процесса

Тяжелые и легкие модели производственного процесса имеют свои достоинства и свои недостатки, которые представлены в табл. 2.1.

Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа «Карго» - религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа.

Таблица 2.1

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

Вес модели Плюсы Минусы
Тяжелые Процессы рассчитаны на среднюю квалификацию исполнителей. Большая специализация исполнителей. Ниже требования к стабильности команды. Отсутствуют ограничения по объему и сложности выполняемых проектов. Требуют существенной управленческой надстройки. Более длительные стадии анализа и проектирования. Более формализованные коммуникации.
Легкие Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями. Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации. Эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды. Объем и сложность выполняемых проектов ограничены.

Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения («муштру») и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи «USA». Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.

Алистер Коуберн, один из авторов «Манифеста гибкой разработки ПО» проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и «гибких» до тяжелых (СММ-5) за последние 20 лет . Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что:

· У каждого проекта должна быть своя модель процесса разработки.

· У каждой модели - свое время.

Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с «Законом 4-х П» (рис. 2.4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта «отдохни.ру». И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.

Команда, которая начинала проект, не остается неизменной, она проходит определенные стадии формирования и, как правило, количественно растет по мере развития проекта. Поэтому процесс должен постоянно адаптироваться к этим изменениям. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую эффективность.

Рис. 2.4. «Закон 4-х П». Процесс в проекте должен определяться в зависимости от проекта, продукта и персонала

    В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия

    Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения … Википедия

    - (англ. Software project management) особый вид управления проектами, в рамках которого происходит планирование, отслеживание и контроль за проектами по разработке программного обеспечения. Ключевым моментом в управлении проектом по… … Википедия

    - (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… … Википедия

    Наиболее распространённый в настоящее время способ нумерации версий Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными от исправления ошибки до полного переписывания. В бол … Википедия

    Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия

    Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия

    Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия

    Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Книги

  • , Кон Майк. В книге "Пользовательские истории: гибкая разработка программного обеспечения" Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…
  • Пользовательские истории. Гибкая разработка программного обеспечения , Майк Кон. В книге`Пользовательские истории: гибкая разработка программного обеспечения` Майка Кона, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки…

С. Архипенков

Модели (или, как еще любят говорить, методологии) процессов разработки ПО принято классифицировать по "весу" - количеству формализованных процессов (большинство процессов или только основные) и детальности их регламентации. Чем больше процессов документировано, чем более детально они описаны, тем больше "вес" модели.

Наиболее распространенные современные модели процесса разработки ПО представлены на Рисунке 3.

Рисунок 3 Различные модели процесса разработки ПО и их распределение по "весу"

ГОСТы

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

SW-CMM

В середине 80-х годов минувшего столетия Министерство обороны США крепко задумалось о том, как выбирать разработчиков ПО при реализации крупномасштабных программных проектов. По заказу военных Институт программной инженерии, входящий в состав Университета Карнеги-Меллона, разработал SW-CMM, Capability Maturity Model for Software в качестве эталонной модели организации разработки программного обеспечения.

Данная модель определяет пять уровней зрелости процесса разработки ПО.

  1. Начальный - процесс разработки носит хаотический характер. Определены лишь немногие из процессов, и успех проектов зависит от конкретных исполнителей.
  2. Повторяемый - установлены основные процессы управления проектами: отслеживание затрат, сроков и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах.
  3. Определенный - процессы разработки ПО и управления проектами описаны и внедрены в единую систему процессов компании. Во всех проектах используется стандартный для организации процесс разработки и поддержки программного обеспечения, адаптированный под конкретный проект.
  4. Управляемый - собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных.
  5. Оптимизируемый - постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

Документация с полным описанием SW-CMM занимает около 500 страниц и определяет набор из 312 требований, которым должна соответствовать организация, если она планирует аттестоваться по этому стандарту на 5-ый уровень зрелости.

RUP

Унифицированный процесс (Rational Unified Process, RUP) был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. Модель RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать конкретный специализированный процесс, ориентированный на ее потребности. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В результате такого общего построения RUP можно использовать и как основу для самого что ни на есть традиционного водопадного стиля разработки, так и в качестве гибкого процесса.

MSF

Microsoft Solutions Framework (MSF) - это гибкая и достаточно легковесная модель, построенная на основе итеративной разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нестандартные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.

PSP/TSP

Одна из последних разработок Института программной инженерии Personal Software Process / Team Software Process [ , ]. Personal Software Process определяет требования к компетенциям разработчика. Согласно этой модели каждый программист должен уметь:

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

Team Software Process делает ставку на самоуправляемые команды численностью 3-20 разработчиков. Команды должны:

  • установить собственные цели;
  • составить свой процесс и планы;
  • отслеживать работу;
  • поддерживать мотивацию и максимальную производительность.

Последовательное применение модели PSP/TSP позволяет сделать нормой в организации пятый уровень CMM.

Agile

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

Выбор модели процесса

Тяжелые и легкие модели производственного процесса имеют свои достоинства и свои недостатки (Таблица 1).

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

Вес модели Плюсы Минусы
Тяжелые Процессы рассчитаны на среднюю квалификацию исполнителей. Большая специализация исполнителей. Ниже требования к стабильности команды.

Отсутствуют ограничения по объему и сложности выполняемых проектов.

 Требуют существенной управленческой надстройки.

Более длительные стадии анализа и проектирования.

Более формализованные оммуникации.
Легкие Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурациями.

Упрощенные стадии анализа и проектирования, основной упор на разработку функциональности, совмещение ролей. Неформальные коммуникации.

 Эффективность сильно зависит от индивидуальных способностей, требуют более квалифицированной, универсальной и стабильной команды.

Объем и сложность выполняемых проектов ограничены.

Те, кто пытается следовать описанным в книгах моделям, не анализируя их применимость в конкретной ситуации, показания и противопоказания, уподобляются последователям культа "Карго" - религии самолетопоклонников. В Меланезии верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В наиболее известных культах карго из кокосовых пальм и соломы строятся точные копии взлётно-посадочных полос, аэропортов и радиовышек. Члены культа строят их, веря в то, что эти постройки привлекут транспортные самолёты (которые считаются посланниками духов), заполненные грузом (карго). Верующие регулярно проводят строевые учения ("муштру") и некое подобие военных маршей, используя ветки вместо винтовок и рисуя на теле ордена и надписи "USA". Все это для того чтобы снова с неба спустились самолеты и этих предметов стало больше.

Алистер Коуберн, один из авторов "Манифеста гибкой разработки ПО" проанализировал очень разные программные проекты, которые выполнялись по разным моделям от совершенно облегченных и "гибких" до тяжелых (СММ-5) за последние 20 лет [ , ]. Он не обнаружил корреляции между успехом или провалом проектов и моделями процесса разработки, которые применялись в проектах. Отсюда он сделал вывод о том, что эффективность разработки ПО не зависит от модели процесса, а также о том, что:

  • У каждого проекта должна быть своя модель процесса разработки.
  • У каждой модели - свое время.

Это означает, что не существует единственного правильного процесса разработки ПО, в каждом новом проекте процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала, в соответствие с "Законом 4-х П" (Рисунок 4). Совершенно разные процессы должны применяться в проектах, в которых участвуют 5 человек, и в проектах, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО, например, система управления атомной электростанцией, то процесс разработки должен сильно отличаться от разработки, например, сайта "отдохни.ру". И, наконец, по-разному следует организовывать процесс разработки в команде вчерашних студентов и в команде состоявшихся профессионалов.


Рисунок 4. "Закон 4-х П". Процесс в проекте должен определяться в зависимости от проекта, продукта и персонала

Команда, которая начинала проект, не остается неизменной, она проходит определенные стадии формирования и, как правило, количественно растет по мере развития проекта. Поэтому процесс должен постоянно адаптироваться к этим изменениям. Главный принцип: не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую эффективность.

Что надо делать для успеха программного проекта

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

Чтобы программный проект стал успешным, необходимо:

  1. Четко ставить цели.
  2. Определять способ достижения целей.
  3. Контролировать и управлять реализацией.
  4. Анализировать угрозы и противодействовать им.
  5. Создавать команду.
  1. Ставим цели

    1.1. Концепция определяет ясные недвусмысленные цели.
    1.2. Все члены команды считают концепцию реалистичной.
    1.3. У проекта имеется обоснование экономической эффективности.
    1.4. Разработан прототип пользовательского интерфейса.
    1.5. Разработана спецификация целевых функций программного продукта.
    1.6. С конечными пользователями продукта налажена двухсторонняя связь

  2. Определяем способ достижения целей

    2.1. Имеется детальный письменный план разработки продукта.
    2.2. В список задач проекта включены "второстепенные" задачи (управление конфигурациями, конвертация данных, интеграция с другими системами).
    2.3. После каждой фазы проекта обновляется расписание и бюджет.
    2.4. Архитектура и проектные решения документированы.
    2.5. Имеется план обеспечения качества, определяющий тестирование и рецензирование.
    2.6. Определен план многоэтапной поставки продукта.
    2.7. В плане учтены обучение, выходные, отпуска, больничные.
    2.8. План проекта и расписание одобрен всеми участниками команды.

  3. Контролируем и управляем реализацией

    3.1. У проекта есть куратор. Это такой топ-менеджер исполняющей компании, который лично заинтересован в успехе данного проекта.
    3.2. У проекта есть менеджер, причем только один!
    3.3. В плане проекта определены "бинарные" контрольные точки.
    3.4. Все заинтересованные стороны могут получить необходимую информацию о ходе проекта.
    3.5. Между руководством и разработчиками установлены доверительные отношения.
    3.6. Установлена процедура управления изменениями в проекте.
    3.7. Определены лица, ответственные за решение о принятии изменений в проекте.
    3.8. План, расписание и статусная информация по проекту доступна каждому участнику.
    3.9. Код системы проходит автоматическое рецензирование.
    3.10. Применяется система управления дефектами.

  4. Анализируем угрозы

    4.1. Имеется список рисков проекта. Осуществляется его регулярный анализ и обновление.
    4.2. Руководитель проекта отслеживает возникновение новых рисков.
    4.3. Для каждого подрядчика определено лицо, ответственное за работу с ним.

  5. Работаем над созданием команды

    5.1. Опыт команды достаточен для выполнения проекта.
    5.2. У команды достаточная компетенция в прикладной области.
    5.3. В проекте имеется технический лидер.
    5.4. Численность персонала достаточна.
    5.5. У команды имеется достаточная сплоченность.
    5.6. Все участники привержены проекту.

Оценка и интерпретация теста

Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

  • 0 - даже не слышали об этом;
  • 1 - слышали, но пока не применяем;
  • 2 - применяется частично;
  • 3 - применяется в полной мере.

Поправочные коэффициенты:

  • для малых проектов (до 5 человек) - 1.5;
  • для средних (от 5 до 20 человек) - 1.25.

Результат:

  • <40 - завершение проекта сомнительно.
  • 40-59 - средний результат. В ходе проекта следует ожидать серьезные проблемы.
  • 60-79 - хороший результат. Проект, скорее всего, будет успешным.
  • 80-89 - отличный результат. Вероятность успеха высока.
  • >90 - великолепный результат. 100% шансов на успех.

Этот чек-лист перечисляет, что надо делать для успеха программного проекта, но не дает ответ на вопрос как это следует делать. Именно об этом пойдет речь в остальных лекциях.