Учебное пособие Чебоксары 2013
Скачать 2.76 Mb.
|
Глвав II. Разработка программного обеспечения Жизненный цикл программного обеспечения Понятие технологии разработки программного обеспечения В современном мире всеобщей компьютеризации и информатизации требования, предъявляемые к программному обеспечению вообще и к программным продуктам (ПП), программным средствам (ПС) и программам в частности, весьма высоки, что очевидно. В связи с этим обеспечение удовлетворяющих пользователя потребительских качеств программы, таких как надежность, быстродействие, соответствие заявленным возможностям, полнота документации, возможность расширения, развития и т.д., без строгого соблюдения определенной технологии практически невозможно. Рассмотрим сначала основные термины и определения. Политехнический словарь рассматривает словом «технология» (от греч. techne – искусство, мастерство, умение, и логия) в широком смысле как совокупность «методов обработки, изготовления, изменения состояния, свойств, формы сырья, материала или полуфабрикатов, применимых в процессе производства, для получения готовой продукции»; как науку «о способах воздействия на сырье, материалы и полуфабрикаты соответствующими орудиями производства. Разработка технологии осуществляется по отраслям производства». В Энциклопедическом словаре определение примерно то же, более того, задача технологии заключается в выявлении «физических, химических, механических и других закономерностей с целью определения и использования на практике наиболее эффективных и экономичных производственных процессов». В «Толковом словаре» технология – это «совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства». Таким образом, на основании анализа вышеприведенных определений под технологией программирования в широком смысле следует понимать технологию разработки программного средства как совокупность абсолютно всех технологических процессов его создания – от момента зарождения идеи о данном ПС до составления необходимой программной документации. Каждый процесс указанной совокупности базируется на использовании неких методов и средств, например компьютерных (в этом случае следует говорить о компьютерной технологии программирования). В литературе имеются и другие, отличные от приведенного, понятия технологии программирования. Используется также близкое к обсуждаемому понятие программной инженерии, определяемой как систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств. Главное различие между технологией программирования и программной инженерией в качестве учебных дисциплин заключается в способах рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки ПС (технологических процессов) и порядке их прохождения – в этих процессах используются определенные методы и инструментальные средства разработки ПС (их применение и образует технологический процесс), тогда как в программной инженерии изучаются прежде всего методы и инструментальные средства разработки ПС с точки зрения достижения определенных целей: они могут использоваться в разных технологических процессах (и в разных технологиях программирования). Вопросом о том, каким образом эти методы и средства создают технологический процесс, в этом случае никто не задается. Не следует также путать технологию программирования с методологией программирования, несмотря на то что в обоих случаях изучаются соответствующие методы. Дело в том, что в технологии программирования методы рассматриваются «сверху», т.е. с точки зрения организации технологических процессов, а в методологии программирования – «снизу», т.е. с точки зрения основ их построения. Имея в виду, что надежность является неотъемлемым атрибутом ПС, технологию программирования здесь целесообразно рассматривать как технологию разработки надежных ПС. Это означает обсуждение, во-первых, всех процессов разработки ПС (от идеи создания до «утилизации»), а во-вторых, вопросов построения программных конструкций, описания функций и принимаемых решений с точки зрения их человеческого восприятия. И, наконец, в качестве продукта технологии появится надежное программное средство. Все вышеперечисленное будет существенно влиять на выбор методов и инструментальных средств при разработке ПС [2]. Целью программирования является выполнение систематической последовательности действий для достижения автоматической обработки данных. Таким образом, технология разработки программного обеспечения, или технология программирования, терминологически обозначает совокупность процессов для создания программного продукта требуемой функциональности. Результатом таких процессов является программное средство – совокупность логически связанных программ на носителях данных, снабженных программной документацией и предназначенных для людей, не участвовавших в процессе разработки. Поскольку технологический процесс разработки программного обеспечения аналогичен процессу разработки программного средства, далее будем рассматривать специфику технологии программирования именно по отношению к ПО. Основы разработки программного обеспечения В основе разработки и дальнейшего применения программного обеспечения пользователем лежит понятие жизненного цикла, который, в сущности, является моделью его создания и использования, отражающей различные состояния, начиная с момента осознания необходимости появления данного ПО и заканчивая моментом его полного выхода из употребления [5]. Существует несколько моделей жизненного цикла (ЖЦ), каждая из которых определяет различную методологию создания систем, тем не менее все без исключения модели ЖЦ включают пять этапов и связей между ними с детальным описанием действий, моделей и результатов каждого этапа. Приведем названия и краткое содержание каждого этапа в соответствии с ГОСТ 19.102-77. 1. Техническое задание:
2. Эскизный проект:
3. Технический проект:
4. Рабочий проект:
5. Внедрение:
Модели жизненного цикла Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ. Первой по времени появления и самой распространенной явилась каскадная модель (рис. 2.1).  Рис. 2.1. Каскадная модель жизненного цикла Каскадная модель характеризуется следующими основными особенностями:
Выявление и устранение ошибок в каскадной модели производится только на стадии тестирования, которая может растянуться во времени или вообще никогда не завершиться. Следующей стадией развития теории проектирования ПО стала итерационная модель ЖЦ, или так называемая поэтапная модель с промежуточным контролем (рис. 2.2).  Рис. 2.2. Итерационная модель жизненного цикла Основной ее особенностью является наличие обратных связей между этапами, вследствие чего появляется возможность проведения проверок и корректировок проектируемой ИС на каждой стадии разработки. В результате трудоемкость отладки по сравнению с каскадной моделью существенно снижается. Итерационность модели проявляется в обработке ошибок, выявленных промежуточным контролем. Если на каком-либо этапе в ходе промежуточной проверки обнаружена ошибка, допущенная на более ранней стадии разработки, необходимо повторить весь цикл работ этой стадии. При этом анализируются причины ошибки и корректируются в случае необходимости исходные данные этапа или его содержание (последовательность действий). К сожалению, в процессе разработки системы могут измениться начальные требования, и в этом случае итерационная модель может оказаться неэффективной. Третья модель ЖЦ ПО – спиральная (spiral) модель (рис. 2.3) поддерживает итерации поэтапной модели, но особое внимание здесь уделяется начальным этапам проектирования: анализу требований, проектированию спецификаций, предварительному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии ПО, уточняются цели и требования к программному обеспечению, оценивается качество разработанного фрагмента или версии и планируются работы следующей стадии разработки (витка). Таким образом, углубляются и конкретизируются все детали проектируемого ПО, в результате получается продукт, который удовлетворяет всем требованиям заказчика.  Рис. 2.3. Спиральная модель жизненного цикла Rational Objeciory Process -– модель жизненного цикла (методология объектно-ориентированного программирования) Объектно-ориентированное проектирование программного обеспечения стало результатом появления объектно-ориентированного программирования (ООП), т.е. применение новой методологии началось с этапа кодирования. Ранние стадии описания предметной области и разработки архитектуры системы не поддерживались, первые варианты использования объектно-ориентированной методологии в большой степени являлись повторением принципов ООП. Такие вопросы, как декомпозиция предметной области, спецификация требований, интерфейс пользователя, не рассматривались, однако успехи объектно-ориентированного программирования заставили распространить новую технологию на весь жизненный цикл ПО. В результате все преимущества подхода применяются не только в процессе кодирования, но и на более ранних этапах. Таким образом, были определены основные компоненты методологии:
Жизненный цикл UML (Rational Objectory Process). Фирма Rational Software, разработавшая язык UML, предложила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого перевода не имеет, так как, во-первых, rational в данном случае употребляется и в значении «рациональный», и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразование аналогично слову repository (накопитель). Основные свойства ROP-технологии.
Результатом работы каждого цикла является своя версия программной системы. Каждая стадия завершается в четко определенной точке (milestone). В этот момент должны быть достигнуты важные результаты и приняты критически важные решения о дальнейшей разработке. Начальная стадия может принимать множество разных форм. Для крупных проектов – это всестороннее изучение всех возможностей реализации на протяжении нескольких месяцев. Здесь же вырабатывается бизнес-план проекта, определяется его стоимость, примерный доход, а также ограничения ресурсов – иными словами, выполняется некоторый начальный анализ оценки проекта.  Рис. 2.4. Модель жизненного цикла UML Окончанием начального этапа могут служить следующие результаты:
На стадии разработки выявляются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта. Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает:
Стадия разработки занимает примерно пятую часть времени создания проекта. Ее результатом являются:
Сущность стадии конструирования заключается в определении последовательности итераций конструирования и вариантов использования, реализуемых на каждой итерации, которые являются одновременно инкрементными и повторяющимися. При этом необходимо отметить следующее:
Результатом стадии конструирования является продукт, готовый к передаче пользователям, содержащий, как правило, руководство пользователей и готовый к интеграции на требуемых платформах. Назначением стадии ввода в эксплуатацию является передача готового продукта в полное распоряжение конечных пользователей. Данная стадия включает:
Технология программирования в компании Microsoft В качестве примера жизненного цикла ПО рассмотрим технологию разработки программного обеспечения компанией Microsoft [17, 18, 19]. Основной структурной единицей в процессе проектирования служила небольшая команда (состоящая иногда из одного человека), причем (и это принципиально!) в ней царил столь присущий корпоративной культуре компании либеральный дух, что состав команды жестко не фиксировался: разработчики, все как один обладающие высокой квалификацией и относящиеся к работе в высшей степени творчески, пользовались большой свободой и стремились обрести максимальную автономность. Вследствие этого при таком подходе необходимо было избежать хаоса, т.е. спланировать работу так, чтобы каждый разработчик, имея свой «кусок» в общем проекте, мог представить результат в четко определенный срок, за что и нес ответственность. Описанный классический «хакерский» стиль работы несовместим с «каскадным» (или «водопадным» – waterfall) подходом к организации жизненного цикла программного продукта, который предполагает развертывание проекта от четко сформулированной и утвержденной спецификации через последовательное выполнение фаз разработки, каждая из которых начинается после полного завершения предыдущей, до окончательной сборки готовых компонентов в единое целое и интегрального тестирования по окончании работы. Такой подход, весьма прогрессивный в 70-80-е гг., в настоящее время считается отнюдь не лучшим из-за своего негибкого, в чем-то даже догматического характера, приводящего к бюрократизации управления, с большим запозданием реагирующего на сигналы рынка. Тем не менее он остается наиболее распространенным. Далеко не всеми менеджерами бюрократизация рассматривается на практике как негативный фактор, так как при этом облегчается управление и размывается ответственность, во многом трансформируемая с личностного на «бумажный» уровень. К тому же при надлежащей реализации вполне возможно выдерживать заданные критерии качества. В настоящее время компания Microsoft следует методологии разработки, опирающейся на спиральную модель жизненного цикла, хотя и весьма видоизмененную по сравнению с классическим описанием [14]. Впрочем, в этом нет ничего удивительного, так как корпоративная технология формировалась эмпирически, а не путем практического использования теоретических источников. Можно выделить три ключевых понятия, в совокупности определяющих специфику подхода. Итеративность (iterativeness), позволяющая многократно проходить одни и те же фазы жизненного цикла каждый раз на новом уровне разработки; при этом фазы разработки могут перекрываться. Пошаговость изменений (incremental changes) – постепенное добавление функциональных возможностей (features) в разрабатываемый продукт в противоположность единовременной реализации полной спецификации. Как следствие, появляется возможность иметь «промежуточную» версию (и не одну!) продукта, которую можно тестировать и даже предоставлять «внешним» пользователям, что позволяет замкнуть постоянно действующую обратную связь с рынком. Параллельность разработки (concurrent development), выполняемой множеством одновременно работающих команд. При этом, главная проблема здесь – синхронизация этих, в значительной степени автономных, действий многочисленных структурных единиц всего большого коллектива, работающего над сложным проектом. Синхронизация действий означает, в сущности, синхронизацию внесения разными командами изменений в общий проект; при этом необходимо периодически фиксировать текущее состояние всей разработки. Таким образом, принятый в компании Microsoft процесс разработки можно разделить на три фазы:
Специфицирование и планирование Процесс разработки начинается с создания концептуального описания будущего продукта, задающего «по-крупному» его образ, видение (этот документ так и называется «vision statement») в контексте требований рынка. Главным действующим лицом на этом этапе является «менеджер по продукту» (product manager) – специалист-маркетолог, знающий ситуацию на рынке и запросы потенциальных пользователей. Его задача – донести до менеджеров по разработке ПО потребительские свойства будущего продукта, т.е. указать, какие цели и требования пользователей необходимо удовлетворить, какие для этого заложить функциональные возможности (product features) и в каком порядке в соответствии с существующими приоритетами следует их ранжировать. На основании vision statement менеджеры по разработке составляют функциональную спецификацию. Здесь функциональные особенности будущего продукта прописываются все еще с точки зрения будущего пользователя, однако с большей степенью подробности, глубины и формализованное. Затрагиваются вопросы архитектуры проекта, определяются основные компоненты и взаимосвязи между ними. Принципиально то, что эта начальная спецификация вовсе не должна фиксировать всю функциональность будущего продукта, как и детали каждой из уже определенных функций. В течение последующих этапов работы эта спецификация подвергнется ревизии по мере того, как разработчики будут больше узнавать о самом продукте, обретающем материальное воплощение и в связи с этим способность «сообщать» о целесообразности наличия (формы) той или иной функции. На изменение функциональности будут влиять и внешние факторы, в том числе реальные и потенциальные рыночные продукты, которые так или иначе конкурируют с разрабатываемым ПО. Наконец, функциональность зависит и от таких прозаических факторов, как недостаток ресурсов, отставание от графика или просто изъяны в реализации, которые невозможно или некогда исправить. В этом смысле корпоративная культура компании Microsoft не предполагает каких-либо комплексов: здесь без колебаний «режут по живому», отдавая приоритет своевременности выброса продукта на рынок. Статистические данные по основным продуктам Microsoft показывают, что в среднем около 25% содержащихся в исходной спецификации (разрекламированных, а потому ожидаемых потребителем) функциональных особенностей исчезают ко времени выпуска продукта; если же считать и то, что привнесено, то конечная функциональность будет отличаться от исходной на 30% и более. На основе функциональной спецификации менеджеры по разработке, постоянно консультируясь с проектировщиками, начинают (на модульной основе) создавать горизонтальную архитектуру продукта. На этой стадии все основные функции ПО разбиваются на несколько групп (обычно три-четыре группы). Соответственно, формируется столько же подпроектов, работа над которыми будет вестись последовательно. Разбиение производится на основе уже имеющейся классификацим функций по степени важности. Наиболее важные (1/3 от общего количества, если групп всего 3) попадают в первый подпроект другие, менее приоритетные, реализуются в рамках второго подпроекта, и, наконец, прочие, наименее значимые функции выполняются в последнем подпроекте. Каждый подпроект заканчивается выпуском промежуточной «контрольной» версии продукта (milestone release). Определенная таким образом архитектура проекта отображается на организационной структуре: для реализации отдельных функций в рамках одного подпроекта назначаются небольшие команды (small feature teams), которые работают параллельно максимально автономно. Для них определяется график работы, выделяются необходимые ресурсы, за рамки которых выходить не рекомендуется. Причем большое значение на рассматриваемом этапе придается сознательному принятию этих рамок самими разработчиками, которые имеют возможность детально проанализировать назначенную им задачу. В результате график, планируемый с точностью до дня, часто оказывается чересчур оптимистичным. Следует обратить внимание на весьма упрощенный подход к разработке архитектуры программного продукта: по сути, само понятие архитектуры низводится до вспомогательного инструментария, подчиненного интересам организационного планирования и управления. Между тем, с точки зрения современных представлений, хорошо структурированная архитектура продукта есть необходимое условие его успешной разработки и дальнейшего развития. Именно поэтому виднейшие авторитеты в области Software Engineering, например Грейди Буч [2], рассматривают архитектуру, определяющую логическую и физическую структуры программной системы, как основу надлежащих стратегических и тактических проектных решений в целях построения качественного продукта. Многие продукты компании Microsoft, созданные на шаткой основе заведомо неполной и постоянно изменяемой спецификации, во многом ущербны. Именно в этом разгадка удивительных, на первый взгляд, отличий последовательных версий одного и того же продукта, не говоря уже о продуктах разных, но в то же время преемственных идеологически. Яркий тому пример – реализация механизмов DLE - OLE - ActiveX. Консервативная «несущая конструкция», каковой является архитектура ПО, гнется и ломается под грузом малоуправляемых мутаций и деформаций. В результате – масса проблем при реализации такого желательного принципа разработки, как повторное использование кода: достаточно сказать, что 50% кода изменяется каждые 18 месяцев. Процесс разработки Каждая из параллельно работающих в рамках реализации подпроекта команд обычно состоит из менеджера по разработке (program manager), трех-восьми разработчиков и такого же количества тестировщиков. Каждая команда выполняет полный цикл разработки, включая проектирование, кодирование и прототипирование (вкупе с тестированием) своей задачи по реализации той функции, за которую она ответственна. Разработчики выполняют проектирование, кодирование и отладку своего кода. Необходимо отметить, что обычно никакой особой проектной документации не ведется – на фирме издавна считается, что ее ведение наложило бы излишние ограничения на динамизм разработки. Функции документации выполняет сам код; при этом он содержит очень мало комментариев, что всегда являлось самой, пожалуй, отличительной особенностью хакеров. Например, комментарии в коде Excel составили лишь около 1% его общего объема. С учетом того, что команде предоставлена возможность не рассматривать исходную спецификацию как догму, а, наоборот, оперативно откликаться на поступающие извне либо генерируемые внутри нее самой предложения по ее изменению, в конечном счете оказывается, что единственным источником для понимания реализации функции оказывается этот самый скупо откомментированный код. Следует отметить, что при данном подходе к кодированию сложно применять такую современную технику, как «инспекция кода», позволяющую резко увеличить количество обнаруживаемых дефектов при сокращении затрат и усилий на тестирование [13]. Команды и отдельные разработчики, имея значительную свободу в процессе реализации подпроекта, должны тем не менее следовать нескольким жестким правилам, которые необходимы для синхронизации параллельно протекающей работы, что, собственно, и позволяет им функционировать как единому слаженному коллективу, способному относительно быстро и дешево справиться с масштабным проектом. Так как работа идет над единым проектом, разрабатываемый продукт всегда существует в виде доступной всем командам централизованной базы данных, содержащей «контрольную» (эталонную) версию файлов с исходным кодом (master version). Действующий в Microsoft механизм работы с единым проектом обычно называют «сборкой» (build), что подразумевает периодическое выполнение процедуры генерации новой текущей версии продукта из частично или полностью законченных разработчиками компонентов. Эта процедура позволяет, не дожидаясь конца разработки, сразу же увидеть, как реализованные (реализуемые) отдельные функции работают в контексте всего продукта, и оперативно выявлять и корректировать проблемы. Принятая в Microsoft технология подразумевает ежедневное выполнение процесса сборки (daily build), состоящего из нескольких шагов. Прежде всего, любой разработчик имеет возможность «скачать» (check out) необходимые ему для работы файлы из общей базы. После этого он имеет полную свободу по внесению в этот код изменений, необходимых для реализации и отладки той функции, за которую он ответственен. В любой момент разработчик может выполнить свою сборку (private build) и сгенерировать таким образом персональную версию продукта (private release). Примерно половину своего рабочего времени разработчик тратит на написание кода; другую половину использует на тестирование, отладку и прямое общение с потребителями продукта. При этом нельзя сказать, что типичный майкрософтовский разработчик использует в своей работе самые современные методы и инструменты. Так, очень многие продолжают (как это не покажется в стенах Microsoft удивительным) использовать Unix Source Code Control System – просто потому, что привыкли к этой системе. Это является также свидетельством того, что корпоративный менеджмент полагает, что лучше тратить время непосредственно на разработку, чем на освоение нового инструментария. Однако необходимо отметить, что почти все команды физически сосредоточены в. одном месте (в корпоративном кампусе в Редмонде), используют общие языки программирования (в основном это Си и C++), более того – общий «фирменный» стиль кодирования и стандартизованные средства разработки. Это помогает параллельно работающим командам в обсуждении проектных идей и решений, потому что полностью автономной работы команд над общим проектом достигнуть невозможно. Каждый разработчик трудится в паре со «своим» тестировщиком; задача последнего – выполнять непрерывное тестирование той самой «персональной» промежуточной версии, которую собирает разработчик. Следует отметить, что по сравнению со своими коллегами-разработчиками, тестировщики используют более современные методы и средства, включая автоматически генерируемые и запускаемые тесты и технику регрессионного тестирования. Конечно, не всякая фирма может позволить персонального тестировщика, но при майкрософтовских масштабах продаж это экономически оправдано, а по сути, и необходимо –это плата за качество проектирования. По крайней мере, дважды в неделю разработчик должен встраивать (check in) разрабатываемый «персональный» код в общую базу, где находится текущая «эталонная» версия (а можно это делать и каждый день). При этом он производит компиляцию и компоновку с обязательным выполнением регрессионного теста, который позволяет проверить реакцию общей «сборки» на вновь поступивший код. В случае проявления при этом какого-либо дефекта разработчик обязан тут же его «зафиксировать» (М. Кусумано, являющийся автором получивших мировую известность книг о японских промышленных технологиях, отмечает здесь сходство с действующим в сборочном цехе корпорации «Тойота» правилом, требующим немедленной остановки конвейера любым сборщиком, если он обнаружил дефект в собираемом автомобиле). Операцию по встраиванию своего кода в общую эталонную базу разработчики имеют право выполнять до определенного назначенного часа; затем в дело вступает специально назначенный разработчик (project build master), который ежедневно генерирует полную «сборку» продукта на основе текущей эталонной версии исходного кода всего продукта. Эта процедура следует «сценарию сборки» (build script) в виде автоматически выполняемой последовательности команд и включает шаги по полной компиляции кода и получению в конечном счете одного или нескольких исполняемых файлов. При этом могут создаваться различные «библиотечные файлы», позволяющие конечным пользователям настроить продукт в соответствии со своей спецификой. Таким образом, ежедневно производится выпуск внутренней версии продукта (internal release), генерируемой для каждой платформы (Windows, Macintosh), а также для каждого значимого рынка (американский, европейский и т.п.). Вся эта технология, направленная на периодическую интеграцию функций и «стабилизацию» кода в его текущем состоянии, позволяет реализовать такой базисный принцип, как постоянное наличие во всех необходимых версиях «готового» (пусть еще далеко не полностью) продукта, который можно предъявить потребителю. Выпуск продукта и механизмы обратной связи В процессе разработки непрерывно используется несколько метрик, хотя в соответствии с общей корпоративной философией здесь не придают такого значения количественным индикаторам, как, например, в Motorola или HP, чья корпоративная культура предусматривает значительно более «выстроенные» процессы разработки. Тем не менее менеджеры каждый день отслеживают прогресс «ежедневных сборок» продукта именно на основе метрик, показывающих, сколько новых «багов» выявлено, сколько, наоборот, исправлено и, наконец, сколько всего остается «активных» дефектов. В конце каждого подпроекта – после истечения срока параллельной работы команд над реализацией назначенных им функций – предусмотрен специальный период «буферное время» (buffer time), во время которого решаются всякие не предусмотренные планом, но неизбежно возникающие проблемы, особенно вызванные оперативно вносимыми изменениями в спецификации и взаимозависимостью функций, над которыми работали разные команды. Этот период используется и как тривиальное продление периода разработки подпроекта, потому что выходы за пределы временного графика наблюдаются почти всегда. Для проектов из разряда приложений буферное время занимает 20-30% всей продолжительности подпроекта, а для системных программ – 50%. Только после этого выпускается очередная «контрольная» версия (milestone release), с которой активно работают пользователи. Важнейшим механизмом, обеспечивающим обратную связь с потенциальными потребителями продукта на протяжении всего процесса разработки, включая период работы над первым подпроектом, является институт лабораторий пользователя (Usability Lab). Первая такая лаборатория была открыта в 1989 г. и имела четыре тестовых комплекта, каждый из которых включал две разделенные полупрозрачным зеркалом комнаты: тестовую (test room), где пользователь имеет возможность «поиграть» с продуктом, и наблюдательскую (observation room), где располагается сотрудник, в чьи функции входит отслеживание всех деталей работы пользователя. Через три года была введена в действие еще одна лаборатория с пятью тестовыми комплектами; в 1995 г. добавили лабораторию, получившую название Microsoft Home, и не случайно: чтобы заставить пользователей чувствовать себя в буквальном смысле «как дома», здесь сымитирована домашняя обстановка, включая кухню, столовую и детскую. Наконец, в 1996 г. появилась лаборатория с пятью тестовыми комплектами, включающая специальное эргономичное оборудование. В этих лабораториях работают более ста сотрудников (usability engineers), не только имеющих компьютерное образование, но и обладающих знаниями в специальных областях психологии и эргономики. Кроме того, непосредственно разработчикам, особенно отвечающим за интерфейсную часть, вменено в обязанность периодически присутствовать на тестовых экспериментах. Что касается контингента испытателей, то их стремятся подбирать так, чтобы они представляли все категории потенциальных пользователей – для этого накоплена и постоянно пополняется обширная база данных. Главное, что измеряется и выражается в специальных метриках, – это легкость освоения продукта и удобство работы с ним. Следует отметить две метрики: первая показывает процент пользователей, которым удалось без обращения к руководству выполнить некое осмысленное действие; вторая метрика выражает процент корректных шагов на пути к выполнению задачи, сделанных с первой попытки. Опытным путем установлено, что для большинства продуктов на ранней стадии разработки вторая метрика (correct first-try rate) получается в районе 60%; цель же, которой в конечном счете стараются добиться, – это 90%. Эксперименты проводятся не только в корпоративных лабораториях, но и «на выезде» в офисах, школах и университетах, по месту жительства возможных потребителей. Кроме того, в последней фазе разработки – фазе стабилизации – прошедшие всестороннее внутреннее тестирование «beta» версии отправляются для опытной эксплуатации к партнерам корпорации, принадлежащим к категориям OEM и ISV; здесь задействованы и многочисленные добровольцы-индивидуалы. После этого компания приступает к подготовке выпуска финальной версии продукта («golden master» discs), а также необходимой документации. Даже после выпуска «финальной» версии работа над продуктом не прекращается. Уже установилась традиция в среднем через 12 месяцев выпускать исправленную и дополненную версию, а через 24 месяца – радикально переработанную (с большим количеством новых функций и измененной архитектурой). Необходимо отметить, что работа отвечающих на телефонные звонки и другие обращения о помощи инженеров службы поддержки финансируется за счет бюджета команд разработчиков данного продукта; поэтому последние заинтересованы в постоянной минимизации дефектов в каждой последующей версии сравнительно с предыдущей. Принципы работы с требованиями к программному обеспечению Проблематика проектирования Согласно статистическим исследованиям группы Стендиша (Standish Group) в США ежегодно тратится более 250 млрд долларов на разработку приложений информационных технологий в рамках примерно 175 000 проектов. Причем 31% проектов будет прекращен до завершения. Затраты на 52,7% проектов составят 189% от первоначальной оценки. В таком случае американские компании и правительственные учреждения потратят 81 млрд долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят дополнительно 59 млрд долларов за программные проекты, которые хотя и завершатся, но значительно превысят первоначально отведенное на них время. Первым шагом на пути решения любой проблемы является осознание основных причин ее возникновения. В отчете группы Стендиша указаны три наиболее часто встречающихся ключевых фактора, создающих проблемы при проектировании программного обеспечения:
В остальном данные сильно расходятся. Конечно, проект может потерпеть неудачу из-за нереалистично составленного графика или неправильно распределенного времени (4% проектов), нерационального подбора персонала и выделения ресурсов (6%), несоответствия технологических навыков (7%), а также по другим причинам. Тем не менее если считать, что приведенные цифры представляют реальное положение дел в отрасли, то, по крайней мере, неудачи трети проектов объясняются причинами, непосредственно связанными со сбором и документированием требований, а также с управлением ими. Несмотря на то что большинство проектов действительно превышают отведенные время и бюджет, оказалось, что около 9% проектов крупных компаний были завершены вовремя и в пределах бюджета; аналогичного успеха удалось достигнуть в 16% проектов мелких компаний. Возникает очевидный вопрос: каковы главные «факторы успеха» в этих проектах? Согласно проведенному исследованию тремя наиболее важными факторами были следующие:
Двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались:
Оценка стоимости ошибок Некоторое время назад ряд компаний провел исследование оценки стоимости ошибок, возникающих на разных этапах создания программ. Каждая фирма действовала независимо, тем не менее результаты получены примерно одинаковые: если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость обнаружения и устранения ошибки на стадии сопровождения – в 20 раз больше (рис. 2.5). Откуда берется такая высокая стоимость ошибки? Ко времени обнаружения ошибки в требованиях группа разработчиков уже могла потратить время и усилия на создание проекта по этим ошибочным требованиям. В результате проект, вероятно, придется отбросить или пересмотреть [1]. Истинная природа ошибки может быть замаскирована; при проведении тестирования и проверок на данной стадии все думают, что имеют дело с ошибками проектирования, и значительное время и усилия могут быть потрачены впустую.  Рис. 2.5. Оценка стоимости ошибок на разных этапах создания программных продуктов В зависимости от того, где и когда при работе над проектом разработки программного приложения был обнаружен дефект, цена его может разниться в 50-100 раз. Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) ниже перечисленные действия.
Управление требованиями Требования задают возможности, которые должна предоставлять система, так что соответствие или несоответствие некоторому множеству требований часто определяет успех или неудачу проекта. Поэтому необходимо узнать, что собой представляют требования, записать их, упорядочить и отслеживать их изменения. Определение управления требованиями выглядит следующим образом [4]. Управление требованиями – это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе. Учитывая, что системе будут предъявлены сотни, если не тысячи, требований, то очень важно организовать их. Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обеспечить документирование требований, которые следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений. Кроме того, очень важными факторами являются размер проекта и его сложность. Управление требованиями наиболее важно в больших проектах, в которых участвует множество людей и число требований к проекту велико. Например, если требований 1000, то придется столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсами для выполнения всех этих требований. Последовательность работы с требованиями Анализ проблемы У пользователя есть технические или бизнес-задачи, для решения которых нужны программисты. Задача последних состоит в том, чтобы понять проблемы пользователей в их собственной проблемной плоскости и на их языке и построить системы, удовлетворяющие их требованиям. Для понимания проблемы пользователей существует ряд профессиональных приемов, о которых пойдет речь ниже [3]. Программисты должны понять потребности пользователей и других заинтересованных лиц, на которых повлияет создание программы. Следующим шагом является переход в область решения - непосредственно к программированию. Однако для начала будет полезно сформулировать знания о предметной области. На данном этапе составляется список функций, которые должна реализовывать система. Для того чтобы провести анализ, следует определить, что же собственно представляет собой проблема. Проблема – это разница между желаемым и воспринимаемым. Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы. Как всегда, начинать следует с определения цели. Цель анализа состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки. Для этого необходимо осуществить следующие пять этапов:
Этап 1. Достижение соглашения об определении проблемы. Первый шаг состоит в достижении соглашения об определении проблемы, которую необходимо решить. Один из простейших способов заключается в том, чтобы просто записать проблему и выяснить, все ли согласны с такой постановкой. В рамках этого процесса зачастую полезно рассмотреть преимущества предлагаемого решения, причем их следует описывать на языке клиентов/пользователей. Это обеспечивает дополнительную содержательную основу для понимания реальной проблемы. Рассматривая эти преимущества с точки зрения клиента, программисты также достигают лучшего понимания их взгляда на проблему в целом. Этап 2. Выявление основных причин – проблем, стоящих за проблемой. На данном этапе важно понять корневые причины, лежащие в основе проблемы и ее проявления. Например, электронный магазин решил бороться с проблемой недостаточной прибыльности. Для этого был проведен анализ причин плохих продаж. Выявлено, что следующие причины ведут к слишком большим остаткам продукции на складе:
Однако нужно ли устранять все эти причины? Зачастую нет. Некоторые корневые причины просто не стоят того, чтоб их устранять. Нужно определить влияние каждой корневой причины и устранять только те, которые наиболее серьезно влияют на саму проблему. В примере, допустим, наибольшее влияние оказывает корневая причина «Неправильные заказы на покупку». Этап 3. Выявление заинтересованных лиц и пользователей. В этом процессе могут помочь ответы на следующие вопросы:
 Рис. 2.6. Границы системы Этап 4. Определение границ системы. Мир делится на две части (рис. 2.6):
Очень важно правильно определить факторы. Для этого следует ответить на приводимые ниже вопросы.
Этап 5. Выявление ограничений, налагаемых на решение. Ограничения уменьшают степень свободы, которой располагают разработчики при реализации решения. Каждое ограничение может существенно сузить возможность создания предполагаемого решения. Следовательно, в процессе планирования необходимо тщательно изучить все ограничения. Преграды на пути выявления требований Синдром «да, но...». Одну из самых неприятных проблем, с которыми сталкиваются разработчики, можно назвать синдромом «да, но...» [3]. Это первичная наблюдаемая реакция пользователя на каждый разработанный фрагмент программного обеспечения. Причина синдрома «да, но...» кроется глубоко в природе проектирования программного обеспечения как интеллектуального неосязаемого процесса. Проблема усугубляется тем, что команда разработчиков крайне редко предоставляет что-либо пользователям для обсуждения до окончания разработки (создания программного кода). Реакция пользователей является следствием человеческой природы. Подобную реакцию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему или что-либо подобное; они не понимают, что программисты подразумевают, когда описывают ее. И вот теперь она перед ними - впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали. Как это ни грустно, но нужно принять факт существования синдрома «да, но...» в качестве объективной реальности и сделать некоторые выводы, которые помогут членам команды смягчить влияние этого синдрома в будущих проектах. Синдром «да, но...» является следствием человеческой природы и неотъемлемой частью разработки любого приложения. Разработчики могут существенно уменьшить воздействие этого синдрома путем применения методов, которые выявят эти «но» как можно раньше. Выявив их на более ранних этапах, можно направить большую часть усилий на разработку программ, которые уже прошли тест «да, но...». Синдром «пользователь и разработчик» является следствием расхождения взглядов пользователей и разработчиков. Они, как правило, принадлежат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели. Предлагаются следующие рекомендации по смягчению данной ситуации. Функции. Использование функций – удобный способ описания возможностей без лишних подробностей. Такой подход имеет недостаток. Если команда при обсуждении не поймет, какая потребность стоит за функцией, это может привести к неприятным последствиям. Тем не менее это высокий уровень абстракции, удобный для описания возможностей системы. Рекомендуемое количество функций, которое дает полное представление о разрабатываемой системе, – 25-99, однако желательно, чтобы их число не превышало 50. После того как все функции перечислены, можно приступить к принятию решения вида «отложить до следующей версии», «реализовать немедленно», «полностью отвергнуть» или «исследовать дополнительно». Этот процесс корректировки масштаба лучше проводить на уровне функций, а не на уровне требований, иначе можно увязнуть в деталях. Для того чтобы лучше работать с этой информацией, введем понятие атрибутов функций – элементов данных, которые обеспечат дополнительную информацию о каждой функции. Методы выявления требований:
Интервьюирование и анкетирование. Интервью помогает понять проблему, не оказывая влияние на ответы пользователя. Ниже приведены примеры контекстно-свободных вопросов:
После этого интервьюер перечисляет основные пункты, чтобы проверить, все ли было правильно понято: «Итак, вы сказали мне...» (перечисляются описанные заказчиком проблемы своими словами), «Какие еще проблемы вы испытываете?» Правила подготовки интервью.
Совещания. Хорошо проведенное совещание по вопросам требований имеет множество преимуществ:
Все материалы к совещанию должны быть предоставлены участникам заранее. Мозговой штурм. Все основные участники собираются в одной комнате, им раздаются материалы для заметок не менее – 25 листов формата от 712 до 1217. Правила проведения мозгового штурма.
Каждый записывает идеи на листок; позже они оглашаются. Критиковать их нельзя, дискутировать тоже не стоит, чтобы никого не обидеть. Идею надо попробовать развить или скомбинировать с какой-либо другой; если ничего не получится, то ее просто изымут из рассмотрения. Идеи обязательно записывают на бумагу по следующим причинам:
Раскадровка. Цель раскадровки – в раннем выявлении реакции типа «да, но...». Существуют три типа раскадровок.
Применение прецедентов. Рисуются схемы с факторами; в овале пишется вид выполняемого ими действия. Обыгрывание ролей. Этот способ позволяет разработчику прочувствовать проблемы пользователя. Разработчик на время становится на место клиента; причем можно заранее написать сценарий для программистов, по которому они попытаются выполнить действия пользователей. Также очень эффективным способом является составление сценариев на основе CRC-карточек, которые описывают объект, его поведение и взаимодействие с другими объектами системы. Участники делят карточки между собой и используют их для ролевой игры, выполняя действия согласно предписаниям. Это эффективный способ для выявления проблем проектирования системы. Прототипы требований. Прототип требований к ПО – это частичная реализация системы, созданная для того, чтобы помочь разработчикам, пользователям и клиентам точнее определить требования к системе. Этот метод также помогает решить проблему «да, но...» [3]. Таким образом, на базе знаний по составлению требований к ПО и при их корректном постоянном применении разработчик лучше поймет проблемы клиента и, как следствие, создаст качественный программный продукт, отвечающий потребностям пользователей, снизит риск краха проекта из-за функционального несоответствия приложения. Контрольные вопросы
|
Похожие:
 | Б 90 Основы риторики и коммуникации. Нормативный и коммуникативный аспекты современной риторики [Текст] : учебное пособие / М. Б.... | | Деловой английский язык. Часть I. Business English. Part I : учебное пособие / Ю. А. Вишневецкая, Л. М. Калянова. — Тюмень : Тюмгнгу,... |
 | «Владимирский государственный университет имени Александра Григорьевича и Николая Григорьевича Столетовых» | | Юрьева О. А. Бухгалтерский учет на предприятиях сферы услуг. Учебное пособие. Дгту: Ростов-на-Дону. 2008 |
| Учебное пособие для бакалавров направления подготовки 230700. 62 «Прикладная информатика в области экономики» | | Учебное пособие пм 04 Выполнение работ по профессии Младшая медицинская сестра по уходу за больными |
| Учебное пособие предназначено для студентов III v курсов специальности «Технология художественной обработки материалов» | | Хрестоматия по культурологии: учебное пособие / Под ред. Е. Я. Букиной. Новосибирск: Изд-во нгту, 2008 |
| Адамов Н. А., Амучиева Г. А. Бухгалтерский учет в строительстве: Учебное пособие / гуу. – М., 2004. – с. 128 | | Учебное пособие предназначено для студентов имтп, а также может быть использовано при самостоятельном освоении современного программного... |