Отладчик

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

Языковед

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

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

Особое внимание следует обратить на различие между группой из двух программистов (гаражным дуэтом) и группой Хирург - Второй Хирург (операционной группой).

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

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 6. Каналы попарного общения в операционной бригаде из 10 человек

Максимально возможное количество попарных контактов при такой организации 10 человек равно 13, тогда как при обычной организации - 45 (таб.1). Кроме того, при совместной работе нескольких операционных бригад будут организованы контакты только между Хирургами, что на порядки сократит количество каналов попарного общения и увеличит производительность в больших проектах.

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

· Выделение независимых задач (разработка компонентов);

· Существенное (на порядки) сокращение взаимосвязей между задачами и разработчиками.

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

1.2 Основные концептуальные подходы к методологии разработки и внедрения программного обеспечения

Модель Быстрого прототипирования

В результате многократного практического применения каскадной модели с присущими ей недостатками и под влиянием очерков Фредерика Брукса и других прогрессивных ученых, вызвавших бурные обсуждения проблем разработки и внедрения программного обеспечения, в начале 80-х годов прошлого столетия зародилась модель быстрого прототипирования.

Доктор Брукс в своем очерке "Планируйте на выброс" писал:

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

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

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

В своей более поздней работе "Серебряной пули нет - сущность и акциденция в программной инженерии" доктор Брукс отметил положительные моменты в применении методов быстрого прототипирования:

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

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

Он также отметил, что:

"…На данный момент времени одной из самых обещающих среди технологических попыток, сосредоточенных на сущности, а не на трудностях решения проблемы программирования, является разработка методов и средств для ускоренного прототипирования систем как составляющей итеративной спецификации требований…"

Уоттс Хэмфри (Watts Humphrey), который известен как вдохновитель создания методологии SEI CMM поддерживает Брукса в его подходе к важности требований и их определения:

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

Согласно Джону Коннэлу (John Connel) и Линде Шафер (Linda Shafer), эволюционным ускоренным прототипированием является "…легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства системы, благодаря которой пользователи данного продукта получают физическое представление о ключевых частях системы до ее непосредственной реализации; это - легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы…"

Бернард Боар (Bernard Boar) определил прототип как "…метод, предназначенный для определения требований, при котором потребности пользователя извлекаются, представляются и разрабатываются посредством построения рабочей модели конечной системы - быстро и в требуемом контексте…"

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

Прототипирование - это процесс построения рабочей модели системы. Прототип - это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.

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

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

Преимущества модели быстрого прототипирования:

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

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

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

· в процесс разработки можно внести новые и неожиданные требования пользователей, что порой необходимо, так как реальность может отличаться от концептуальной модели реальности;

· модель представляет собой формальную спецификацию, воплощенную в рабочую модель;

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

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

· возможность возникновения разногласий при общении пользователей с разработчиками минимизирована;

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

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

· благодаря меньшему объему доработок уменьшаются затраты на разработку и внедрение программного обеспечения;

· обеспечивается управление рисками;

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

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

Недостатки модели быстрого прототипирования:

· модель может быть отклонена из-за создавшегося среди консерваторов мнения о ней, как о методе "разработки на скорую руку";

· если цели прототипирования не согласованы заранее, процесс может стать неуправляемым или бесконечным;

· с учетом создания рабочего прототипа, качеству всего создаваемого программного обеспечения или его долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания;

· иногда в результате использования модели получают систему с низкими рабочими характеристиками, особенно если в процессе ее разработки пропускается этап подгонки модели;

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

· несовпадение представлений пользователей и разработчиков об использовании прототипа может привести к созданию неадекватного пользовательского интерфейса;

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

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

· прототипирование вызывает зависимость и может продолжаться слишком долго. Неопытные разработчики могут попасть в так называемый цикл "кодирование - устранение ошибок" (рис.7), что приводит к дорогостоящим незапланированным итерациям прототипирования;

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

· на клиентов могут неблагоприятно повлиять сведения об отличии между прототипом и полностью разработанной системой, готовой к внедрению;

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

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

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

· требования не известны заранее;

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

· следует уточнить требования;

· существует потребность в разработке пользовательских интерфейсов;

· необходимы демонстрации промежуточных результатов разработки и внедрения;

· выполняется новая, не имеющая аналогов разработка;

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

· алгоритмы или системные интерфейсы усложнены;

· требуется продемонстрировать техническую осуществимость, когда технический риск высок;

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

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

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

Инкрементная модель

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

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

Известный американский ученый, автор спиральной модели, Барри Боэм (Barry Boehm) описывает инкрементный метод как процесс объединения элементов последовательной каскадной модели и прототипирования и является сторонником разработки и внедрения программного обеспечения по принципу наращивания функциональных возможностей продукта. Согласно его словам, подобное усовершенствование каскадной модели одинаково эффективно при использовании как для чрезвычайно больших, так и для небольших проектов.

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

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

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

Преимущества инкрементной модели:

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

· в результате выполнения каждого инкремента получается функциональный продукт;

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

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

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

· в процессе разработки можно ограничить количество персонала таким образом, чтобы над разработкой и внедрением каждого инкремента последовательно работала одна и та же команда и все задействованные в процессе разработчики не прекращали работу над проектом (график распределения сотрудников может выравниваться посредством распределения по времени объема работы над проектом);

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

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

· в конце каждого инкремента существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика;

· снижается риск неудач при изменениях требований;

· потребности клиента лучше поддаются управлению, поскольку время разработки каждого инкремента относительно невелико;

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

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

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

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

Недостатки инкрементной модели:

· в модели не предусмотрены итерации внутри каждого инкремента;

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

· поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах;

· формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом;

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

· клиент должен осознавать, что общие затраты на выполнение проекта не будут снижены.

Менеджер проекта может быть уверен в целесообразности применения модели, если:

· большинство требований можно сформулировать заранее, но их появление ожидается через определенный период времени;

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

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

· однопроходная разработка системы связана с большой степенью риска;

· результативные данные получаются через регулярные интервалы времени.

Спиральная модель

В спиральной модели, впервые представленной доктором Барри Боемом (Barry Boehm) и опубликованной в журнале IEEE Computer в 1988 году, учтены недостатки каскадной модели.

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

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

Графически модель представляет собой раскручивающуюся спираль, условно разделенную на четыре квадранта (рис.9):

Рисунок 9. Спиральная модель

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

· Анализ и проверка альтернатив, идентификация и разрешение рисков. Выполняется оценка альтернативных вариантов, относящихся к целям и ограничениям. Выполняется определение и разрешение рисков, управление рисками, в том числе принятие решения о прекращении/продолжении работ над проектом.

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

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

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