ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 13450
Скачиваний: 411
Сертификация продуктов с помощью самих пользователей — это наилучший способ предоставить гарантии на ПО, поскольку при этом продукт оценивается в ситуациях, когда он применяется в условиях реального мира.
Такой подход предполагает также сбор информации о характере применения продукта. Можно измерить частоту, с которой вызываются определенные функции, и просто собирать файлы ввода, которые используются для создания профилей. Эти наборы информации будут служить в качестве основы для выпуска ограниченных гарантий на ПО.
Производитель программного обеспечения представляет конечный продукт для включения в него резидентного инструментария тестирования, в результате этого создается специальная, «инструментальная» копия. Производитель предоставляет копии SCL, которая передает инструментальную копию предварительно отобранным пользователям, работающим в разных отраслях. Эти тестировщики будут использовать продукт по согласованию с SCL. Предлагаемая Microsoft модель бета-тестирования — прекрасный пример того, как среди всех желающих отобрать только тех, кто действительно сможет предоставить самый большой объем полезной информации.
Заметим, что было бы возможно и потенциально предпочтительно для SCL самой встраивать необходимый инструментальный код, не привлекая для этого производителя. Это можно было бы сделать, если бы специалисты SCL получили доступ к определенным файлам с исходными текстами или к интерфейсам. По сути, независимая организация в первую очередь призвана сделать так, чтобы производитель как можно меньше знал о пользователях, принимающих участие в тестировании, и не мог влиять на результаты процесса сертификации.
Периодически БСЬ собирает информацию от пользователей и суммирует ее. Это позволяет БСЬ предоставить разработчику статистические данные о том, как использовался продукт и как он вел себя во время испытаний. При этом БСЬ может собирать статистику от участников тестирования таким образом, чтобы восстановить личность конкретного пользователя было бы невозможно.
БСЬ должна определить, получит ли данный продукт гарантию и что должно быть указано в этой гарантии: платформа, секторы рынка, операционные среды. Со временем, собрав дополнительные данные, 8СЬ могла бы предложить более широкую гарантию и снизить указанные в ней ограничения.
Особую сложность представляют системы, критичные к безопасности. Нельзя рассчитывать на то, что 8СЬ найдет желающих полетать на самолете, на котором установлены ^сертифицированные программы управления полетами, или использовать медицинские приборы с ^сертифицированными программами только потому, что необходимо выяснить, имеют ли.эти программы право на сертификат. По мнению авторов, ЪСЬ сначала должна сертифицировать программное обеспечение для областей, которые не являются критически важными. После того как продукт получит сертификат для работы в таких условиях, он будет пользоваться большим доверием у производителей приложений для критичных к безопасности систем в том случае, если его утилиты ранее были сертифицированы для некритических сред, которые отражают условия критичных к безопасности приложений.
Если программное обеспечение прекрасно работает в критичных к безопасности применениях и если БСЬ сумеет собрать достаточно доказательств этого, можно попробовать сертифицировать его для критически важных областей.
Достоинства модели сертификации с участием пользователей
Подобный подход обладает рядом преимуществ. Эти преимущества, однако, не могут быть реализованы до тех пор, пока точно не известно, какие данные необходимы для того, чтобы выдать ограниченную гарантию на программное обеспечение.
В конце концов, объем необходимых данных будет зависеть от того, насколько строгую и полную гарантию хотим получить.
Эти данные должны включать в себя результаты по оценке надежности, предположений о функциональности, мониторинга звонков о возникновении исключительных ситуаций, использования в работе и анализа охвата кода. Хотя возможно проведение и другого анализа, эти параметры, по-видимому, являются наиболее важными индикаторами того, достаточно ли хорошо изучена работа компонента, чтобы его можно было сертифицировать для использования в конкретных средах и секторах рынка. В дальнейшем можно вместе со специалистами по сертификации выбрать технологии резидентного тестирования, которые обеспечивают получение данных, достаточных для того, чтобы предложить страховую премию на программное обеспечение и гарантии на ПО.
Чтобы быстро добиться получения сертификата, недобросовестные разработчики могут попытаться изменить инструментарий таким образом, чтобы добавить фальшивые датчики, которые помешают проведению тестирования. И 5СЬ должна уменьшить этот риск.
2.3. Жизненный цикл программы
2.3.1. Понятие технологии разработки программы
В современном мире всеобщей компьютеризации и информатизации требования, предъявляемые к программному обеспечению (ПО) вообще и к программным продуктам (ПП), программным средствам (ПС) и программам в частности, весьма высоки. В связи с этим обеспечение удовлетворяющих пользователя потребительских качеств программы, таких как надежность, быстродействие, соответствие заявленным возможностям, полнота документации, возможности расширения, развития и т. д., без строгого соблюдения определенной технологии практически невозможно.
Рассмотрим сначала основные термины и определения. Политехнический словарь [26] оперирует словом «технология» (от грен. 1есЬпе — искусство, мастерство, умение и логия) в широком смысле как совокупностью «методов обработки, изготовления, изменения состояния, свойств, формы сырья, материала или по-
луфабрикатов, применимых в процессе производства, для получения готовой продукции»; как наукой «о способах воздействия на сырье, материалы и полуфабрикаты соответствующими орудиями производства. Разработка технологии осуществляется по отраслям производства». В Энциклопедическом словаре [25] определение примерно то же, более того, задача науки технологии заключается в выявлении «физических, химических, механических и др. закономерностей с целью определения и использования на практике наиболее эффективных и экономичных производственных процессов». В Толковом словаре [24] технология — это «совокупность производственных процессов в определенной отрасли производства, а также научное описание способов производства».
Итак, на основании анализа вышеприведенных определений под технологией программирования в широком смысле следует понимать технологию разработки программного средства, как совокупность абсолютно всех технологических процессов его создания — от момента зарождения идеи о данном ПС до составления необходимой программной документации. Каждый процесс указанной совокупности базируется на использовании неких методов и средств, например компьютерных (в этом случае будем говорить о компьютерной технологии программирования).
В литературе имеются и другие, отличные от приведенного понятия технологии программирования. Используется также близкое обсуждаемому понятие программной инженерии, определяемой как систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств. Главное различие между технологией программирования и программной инженерией в качестве учебных дисциплин заключается в способах рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки ПС (технологических процессов) и порядке их прохождения — в этих процессах используются определенные методы и инструментальные средства разработки ПС (их применение и образует технологический процесс), тогда как в программной инженерии изучаются прежде всего методы и инструментальные средства разработки ПС с точки зрения достижения определенных целей — они могут использоваться в разных технологических процессах (и в разных технологиях программирования). Вопросом о том, каким образом эти методы и средства создают технологический процесс, в этом случае никто не задается.
Не следует также путать технологию программирования с методологией программирования, несмотря на то, что в обоих случаях изучаются соответствующие методы. Дело в том, что в технологии программирования методы рассматриваются «сверху», т. е. с точки зрения организации технологических процессов, а в методологии программирования — «снизу», т. е. с точки зрения основ их построения.
Имея в виду, что надежность является неотъемлемым атрибутом ПС, технологию программирования здесь будем рассматривать как технологию разработки надежных ПС. Это значит, во-первых, обсуждение всех процессов разработки ПС (от идеи создания до «утилизации»), а во-вторых, вопросов построения программных конструкций, описания функций и принимаемых решений с точки зрения их человеческого восприятия. И наконец, в качестве продукта технологии появится надежное программное средство. Все вышеперечисленное будет существенно влиять на выбор методов и инструментальных средств при разработке ПС [20].
Кратко резюмируем сказанное. Целью программирования является выполнение систематической последовательности действий для достижения автоматической обработки данных, таким образом, технология разработки программного обеспечения или, проще, технология программирования терминологически обозначает совокупность процессов для создания программного продукта требуемой функциональности.
Результатом таких процессов является программное средство — совокупность логически связанных программ на носителях данных, снабженных программной документацией и предназначенных для людей, не участвовавших в процессе разработки.
Поскольку технологический процесс разработки программного обеспечения вообще аналогичен процессу разработки программного средства (в частности), далее будем рассматривать специфику технологии программирования именно по отношению к ПО.
2-3.2. Основа разработки программного обеспечения
В основе разработки и дальнейшего применения программного обеспечения пользователем лежит понятие жизненного цикла, который, в сущности, является моделью его создания и использования, отражающей различные состояния, начиная с момента осознания необходимости появления данного ПО и запячивая моментом его полного выхода из употребления [5].
Существует несколько моделей жизненного цикла (ЖЦ), каждая из которых определяет различную методологию создания систем, тем не менее все без исключения модели ЖЦ включают в себя пять этапов и связей между ними с детальным описанием действий, моделей и результатов каждого этапа. Приведем названия и краткое содержание каждого этапа в соответствии с ГОСТ 19.102-77.
1. Техническое задание:
-
постановка задачи;
-
выбор критериев эффективности;
-
проведение предварительных научно-исследовательских работ (НИР);
-
разработка ТЗ.
2. Эскизный проект:
-
структура входных и выходных данных;
-
уточнение методов решения;
-
общий алгоритм;
-
разработка документации эскизного проекта.
3. Технический проект:
-
уточнение структуры входных и выходных данных;
-
разработка алгоритмов;
-
формы данных;
-
семантика и синтаксис языка;
-
структура программы;
-
конфигурация технических средств;
-
план работ.
4. Рабочий проект:
-
программирование и отладка;
-
разработка документов;
-
подготовка и проведение испытаний;
-
корректировка программы и документов по итогам испытаний.
5. Внедрение:
-
передача программы и документов для сопровождения;
-
оформление акта;
-
передача в Фонд алгоритмов и программ (ФАП).
2.3.3. Модели жизненного цикла
Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ.
Первой по времени появления и самой распространенной явилась каскадная модель (рис. 2.5).
Стратегическое планирование
12
Анализ требований
Проектирование
—1£
Реализация
Тестирование и отладка
11
Эксплуатация, сопровождение
Рис. 2.5. Каскадная модель жизненного цикла ПО
Каскадная модель характеризуется следующими основными особенностями:
-
последовательным выполнением входящих в ее состав этапов;
-
окончанием каждого предыдущего этапа до начала последующего;
-
отсутствием временного перекрытия этапов (последующий этап не начнется, пока не завершится предыдущий);
-
отсутствием (или определенным ограничением) возврата к предыдущим этапам;
-
наличием результата только в конце разработки.
Выявление и устранение ошибок в каскадной модели производится только на стадии тестирования, которая может растянуться во времени или вообще никогда не завершиться.
Следующей стадией развития теории проектирования ПО стала итерационная модель ЖЦ, или так называемая поэтапная модель с промежуточным контролем (рис. 2.6). Основной ее особенностью является наличие обратных связей между этапами, вследствие этого появляется возможность проведения проверок и корректировок проектируемой ИС на каждой стадии разработки. В результате трудоемкость отладки по сравнению с каскадной моделью существенно снижается. Итерационность модели проявляется в обработке ошибок, выявленных промежуточным контролем. Если на каком-либо этапе в ходе промежуточной проверки обнаружена ошибка, допущенная на более ранней стадии разработки, необходимо повторить весь цикл работ этой стадии. При этом анализируются причины ошибки и корректируются в случае необходимости исходные данные этапа или его содержание (последовательность действий).
К сожалению, в процессе разработки системы могут измениться начальные требования, и в этом случае итерационная модель может оказаться неэффективной.
Реализация
и
тестирование
Третья
модель ЖЦ ПО — спиральная (spiral)
модель (рис. 2.7)
— поддерживает итерации поэтапной
модели, но особое внимание уделяется
начальным этапам проектирования:
анализу требований, проектированию
спецификаций, предварительному
проектированию и детальному проектированию.
Каждый виток спирали соответствует
поэтапной модели создания фрагмента
или версии ПО, уточняются цели и
требования к программному обеспечению,
оценивается качество разработанного
фрагмента или версии и планируются
работы следующей стадии разработки
(витка). Таким образом, углубляются и
конкретизируются все детали проектируемого
ПО, в результате получается продукт,
который удовлетворяет всем требованиям
заказчика.
2.3.4- Rational Objectory Process — модель жизненного цикла (методология объектно-ориентированного программирования)
Известно, что объектно-ориентированное проектирование программного обеспечения стало результатом появления объектно-ориентированного программирования (ООП), т. е. применение новой методологии, как всегда1, началось с этапа кодирования. Ранние стадии описания предметной области и разработки архитектуры системы не поддерживались, первые варианты использования объектно-ориентированной методологии в большей степени являлись чистым повторением принципов ООП. Такие вопросы, как декомпозиция предметной области, спецификация требований, интерфейс пользователя, не рассматривались, однако успехи объектно-ориентированного программирования заставили распространить новую технологию на весь жизненный цикл ПО. В результате все преимущества подхода применяются не только в процессе кодирования, но и на более ранних этапах. Таким образом, были определены основные компоненты методологии:
-
модель жизненного цикла;
-
действия;
-
нотация языка.
2.3-5. Жизненный цикл UML2 (Rational Objectory Process)
Фирма Rational Software, разработавшая язык UML, предложила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого перевода не имеет, так как rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразование аналогично слову repository (накопитель).
Перечислим основные свойства ROP-технологии.
1 В исторической последовательности развития программных средств первыми появились узкоориентированные приложения («программа, предназначенная для вычисления числа п с точностью до 200 знака»), следом — системы программирования (ранние их версии назывались системами автоматизации программирования), затем — операционные системы.
2 Unified Modeling Language — унифицированный язык моделирования.
Rational Objectory Process — итеративный процесс, в течение которого происходит последовательное уточнение результатов.
Rational Objectory Process направлен именно на создание моделей, а не на разработку каких-либо других элементов проекта (например, текстовых документов).
Действия Rational Objectory Process определяются в первую очередь блоками использования (use case) (рис. 2.8).
Время
< ►
Фазы
|
А Анализ требований |
Inception Elaboration Construction Transition |
|
|
|
|
к ш Проектирование |
^^^^^г - -■ |
|
ь о ф ^ Кодирование |
|
|
Тестирование |
1 _ ; |
|
Т |
j |
|
^ #J #2 ' #n Ln+lL + 2 #m Ln+J |
Рис. 2.8. Модель жизненного цикла UML
Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз:
-
начальная стадия (Inception);
-
разработка (Elaboration);
-
конструирование (Construction);
-
ввод в эксплуатацию (Transition).
Результатом работы каждого такого цикла является своя версия программной системы.
Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.
Начальная стадия может принимать множество разных форм. Для крупных проектов — это всестороннее изучение всех возможностей реализации на протяжении нескольких месяцев. Здесь же вырабатывается бизнес-план проекта, определяется его стоимость, примерный доход, а также ограничения ресурсов — иными словами, выполняется некоторый начальный анализ оценки проекта.
Окончанием начального этапа могут служить следующие результаты:
-
начальный проектный словарь терминов;
-
общее описание системы — основные требования к проекту, его характеристики и ограничения;
-
начальная модель вариантов использования;
-
начальный бизнес-план;
-
план проекта, отражающий стадии и итерации;
-
один или несколько прототипов.
На стадии разработки выявляются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта.
Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает:
-
модель предметной области, которая служит отправным пунктом для формирования основных абстракций предметной области;
-
технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодействие.
Стадия разработки занимает примерно пятую часть времени создания проекта, результатом которой являются:
-
оценка времени реализации каждого варианта использования;
-
идентификация всех наиболее серьезных рисков и возможности их ликвидации.
Сущность стадии конструирования заключается в определении последовательности итераций конструирования и вариантов использования, реализуемых на каждой итерации, которые являются одновременно инкрементными и повторяющимися.
При этом необходимо отметить следующее:
-
итерации являются инкрементными в соответствии с выполняемой функцией. Каждая итерация добавляет очередные конструкции к вариантам использования, реализованным во время предыдущих итераций;
-
итерации являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода переписывается с целью сделать его более гибким.
Результатом стадии конструирования является продукт, готовый к передаче пользователям и содержащий, как правило, руководство пользователей и готовый к интеграции на требуемых платформах.
Назначением стадии ввода в эксплуатацию является передача готового продукта в полное распоряжение конечных пользователей. Данная стадия включает:
-
бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;
-
параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;
-
оптимизацию производительности;
-
обучение пользователей и специалистов службы сопровождения.
2.3-6- Специфицирование и планирование
Процесс разработки начинается с создания концептуального описания будущего продукта, задающего «по-крупному» его образ, видение (этот документ так и называется «vision statement*) в контексте требований рынка. Главным действующим лицом на этом этапе является «менеджер по продукту» (product manager) — специалист-маркетолог, знающий ситуацию на рынке и запросы потенциальных пользователей. Его задача — донести до менеджеров по разработке ПО потребительские свойства будущего продукта, т. е. указать, какие цели и требования пользователей необходимо удовлетворить, какие для этого заложить функциональные возможности (product features) и в каком порядке в соответствии с существующими приоритетами следует их ранжировать.
На основании vision statement менеджеры по разработке составляют функциональную спецификацию. Здесь функциональные особенности будущего продукта прописываются все еще с точки зрения будущего пользователя, правда, с большей степенью подробности, глубины и формализованное™. Затрагиваются вопросы архитектуры проекта, определяются основные компоненты и взаимосвязи между ними. Принципиально то, что эта начальная спецификация вовсе не должна фиксировать всю функциональность будущего продукта, как и детали каждой из уже определенных функций. В течение последующих этапов работы эта спецификация подвергнется ревизии по мере того, как разработчики будут больше узнавать о самом продукте, обретающем материальное воплощение и в связи с этим способность «сообщать» о целесообразности наличия (формы) той или иной функции.
На изменение функциональности будут влиять и внешние факторы, в том числе те реальные и потенциальные рыночные продукты, которые так или иначе конкурируют с разрабатываемым ПО. Наконец, функциональность зависит и от таких прозаических факторов, как недостаток ресурсов, отставание от графика или просто изъяны в реализации, которые невозможно или некогда исправить. В этом смысле корпоративная культура компании Microsoft не предполагает каких-либо комплексов: здесь без колебаний «режут по живому», отдавая приоритет своевременности выброса продукта на рынок. Статистические данные по основным продуктам Microsoft показывают, что в среднем около 25 % содержащихся в исходной спецификации (разрекламированных, а потому ожидаемых потребителем) функциональных особенностей исчезают ко времени выпуска продукта; если же считать и то, что привнесено, то конечная функциональность будет отличаться от исходной на 30 % и более.
На основе функциональной спецификации менеджеры по разработке, постоянно консультируясь с проектировщиками, начинают на модульной основе создавать горизонтальную архитектуру продукта. Главное, что на этой стадии все основные функции ПО разбиваются на несколько групп (обычно три-четыре группы). Соответственно, формируется столько же подпроектов, работа над которыми будет вестись последовательно. Разбиение производится на основе уже имеющейся классификации функций по степени важности. Наиболее важные ('/3 от общего количества, если групп всего 3) попадают в первый подпроект; другие, менее приоритетные, реализуются в рамках второго подпроекта, и наконец, прочие, наименее значимые функции выполняются в последнем подпроекте. Каждый подпроект заканчивается выпуском промежуточной «контрольной» версии продукта (milestone release).
Определенная таким образом архитектура проекта отображается на организационную структуру: для реализации отдельных Функций в рамках одного подпроекта назначаются небольшие команды (small feature teams), которые и работают параллельно и максимально автономно. Для них определяется график работы и выделяются необходимые ресурсы, за рамки которых выходить не рекомендуется. Причем большое значение на рассматриваемом этапе придается сознательному принятию этих рамок самими разработчиками, которые имеют возможность детально проанализировать назначенную им задачу. В результате график, планируемый с точностью до дня, часто оказывается чересчур оптимистичным.
Следует обратить внимание на весьма упрощенный подход к разработке архитектуры программного продукта: по сути, само понятие архитектуры низводится до вспомогательного инструментария, подчиненного интересам организационного планирования и управления. Между тем, с точки зрения современных представлений хорошо структурированная архитектура продукта есть необходимое условие его успешной разработки и — что особенно важно! — дальнейшего развития. Именно поэтому виднейшие авторитеты в области Software Engineering, например Гради Буч [3], рассматривают архитектуру, определяющую логическую и физическую структуры программной системы, как основу надлежащих стратегических и тактических проектных решений в целях построения качественного продукта.
Известно, что многие продукты компании Microsoft, созданные на шаткой основе заведомо неполной и постоянно изменяемой спецификации, во многом ущербны. Именно в этом разгадка удивительных на первый взгляд отличий последовательных версий одного и того же продукта, не говоря уже о продуктах разных, но в то же время преемственных идеологически. Яркий тому пример — реализация механизмов DLE — OLE — ActiveX. Консервативная «несущая конструкция», каковой является архитектура ПО, гнется и ломается под грузом малоуправляемых мутаций и деформаций. В результате — масса проблем при реализации такого желательного принципа разработки, как повторное использование кода: достаточно сказать, что 50 % кода изменяется каждые 18 месяцев!
2-3-7. Процесс разработки
Каждая из параллельно работающих в рамках реализации подпроекта команд обычно состоит из менеджера по разработке (program manager), трех—восьми разработчиков и такого же количества тестировщиков. Каждая команда выполняет полный цикл разработки, включая проектирование, кодирование и про-тотипирование (вкупе с тестированием) своей задачи по реализации той функции, за которую она ответственна.
Разработчики выполняют проектирование, кодирование и отладку своего кода. Небезынтересно отметить, что обычно никакой особой проектной документации не ведется — на фирме издавна считается, что ее ведение наложило бы излишние ограничения на динамизм разработки. Функции же документации выполняет сам код; при этом он содержит очень мало комментариев, что всегда и являлось самой, пожалуй, отличительной особенностью хакеров. К примеру, комментарии в коде Excel составили лишь около 1 % его общего объема. С учетом же того, что команде предоставлена возможность, чтобы не сказать — обязанность, не рассматривать исходную спецификацию как догму, а, наоборот, оперативно откликаться на поступающие извне либо генерируемые внутри нее самой предложения по ее изменению, в конечном счете оказывается, что единственным источником для понимания реализации функции оказывается этот самый скупо откомментированный код. А отдуваться в итоге приходится местным «техническим писателям», и стоит ли удивляться количеству плохо документированных (и вовсе не документированных) возможностей, которыми традиционно славится руководство Microsoft. Стоит отметить, что при данном подходе к кодированию сложно применять такую современную технику, как «инспекция кода», позволяющую резко увеличить количество обнаруживаемых дефектов при сокращении затрат и усилий на тестирование [13].
Команды и отдельные разработчики, имея значительную свободу в процессе реализации подпроекта, должны тем не менее следовать нескольким жестким правилам, которые необходимы для синхронизации параллельно протекающей работы, что, собственно, и позволяет им функционировать как единому слаженному коллективу, способному относительно быстро и дешево справиться с масштабным проектом. Коль скоро идет работа над единым проектом, то разрабатываемый продукт всегда существует в виде доступной всем командам централизованной базы данных, содержащей «контрольную» (эталонную) версию файлов с исходным кодом (master version). Действующий в Microsoft механизм работы с единым проектом обычно называют «сборкой» (build), что подразумевает периодическое выполнение процедуры генерации новой текущей версии продукта из частично или полностью законченных разработчиками компонентов. Эта процедура позволяет, не дожидаясь конца разработки, сразу же увидеть, как реализованные (реализуемые) отдельные функции работают в контексте всего продукта, и оперативно выявлять и корректировать проблемы.
Принятая в Microsoft технология подразумевает ежедневное выполнение процесса сборки (daily build), состоящего из нескольких шагов. Прежде всего, любой разработчик имеет возможность «скачать» (check out) необходимые ему для работы файлы из общей базы. После этого он имеет полную свободу по внесению в этот код изменений, необходимых для реализации и отладки той функции, за которую он ответствен. В любой момент разработчик может выполнить свою сборку (private build) и сгенерировать таким образом персональную версию продукта (private release).
Примерно половину своего рабочего времени разработчик тратит на написание кода; другую половину использует на тестирование, отладку и прямое общение с потребителями продукта. При этом нельзя сказать, что типичный майкрософтовский разработчик использует в своей работе самые современные методы и инструменты. Так, очень многие продолжают (как это ни покажется в стенах Microsoft удивительным) использовать Unix Source Code Control System просто потому, что привыкли к этой системе. Это и отражение того факта, что корпоративный менеджмент полагает, что лучше тратить время непосредственно на разработку, чем на освоение нового инструментария. Зато немаловажно, что почти все команды физически сосредоточены в одном месте (в корпоративном кампусе в Редмонде), используют общие языки программирования (в основном это Си и С++), более того — общий «фирменный» стиль кодирования и стандартизованные средства разработки. Это помогает параллельно работающим командам в обсуждении проектных идей и решений, потому что полностью автономной работы команд над общим проектом достигнуть невозможно.
Каждый разработчик работает в паре со «своим» тестиров-щиком; задача последнего — выполнять непрерывное тестирование той самой «персональной» промежуточной версии, которую собирает разработчик. Надо сказать, что по сравнению со своими коллегами-разработчиками тестировщики используют более современные методы и средства, включая автоматически генерируемые и запускаемые тесты и технику регрессионного тестиро-вания. Конечно, не всякая фирма позволит себе такую роскошь, как придание каждому разработчику его персонального тести-ровщика, но при майкрософтовских масштабах продаж это экономически оправдано, а по сути и необходимо — это плата за качество проектирования.
По крайней мере, дважды в неделю разработчик должен встраивать (check in) разрабатываемый «персональный» код в общую базу, где находится текущая «эталонная» версия (а можно это делать и каждый день). При этом он производит компиляцию и компоновку с обязательным выполнением регрессионного теста, который позволяет проверить реакцию общей «сборки» на вновь поступивший код. В случае проявления при этом какого-либо дефекта разработчик обязан тут же его «зафиксировать» (М. Кусумано, являющийся автором получивших мировую известность книг о японских промышленных технологиях, подмечает здесь сходство с действующим в сборочном цехе корпорации «Тойота» правилом, требующим немедленной остановки конвейера любым сборщиком, если он обнаружил дефект в собираемом автомобиле).
Операцию по встраиванию своего кода в общую эталонную базу разработчики имеют право выполнять до определенного назначенного часа; затем в дело вступает специально назначенный разработчик (project build master), который ежедневно генерирует полную «сборку» продукта на основе текущей эталонной версии исходного кода всего продукта. Эта процедура следует «сценарию сборки» (build script) в виде автоматически выполняемой последовательности команд и включает шаги по полной компиляции кода и получению в конечном итоге одного или нескольких исполняемых файлов. При этом могут создаваться различные «библиотечные файлы», позволяющие конечным пользователям настроить продукт в соответствии со своей спецификой. Таким образом, ежедневно производится выпуск внутренней версии продукта (internal release), генерируемой для каждой платформы (Windows, Mac), а также для каждого значимого рынка (американский, европейские и т. п.). Вся эта технология, направленная на периодическую интеграцию функций и «стабилизацию» кода в его текущем состоянии, позволяет реализовать такой базисный принцип, как постоянное наличие во всех необходимых версиях «готового» (пусть еще далеко не полностью) продукта, который можно предъявить потребителю.
76 Глава 2. Технология разработки программных продуктов... 23.8. Выпуск продукта и механизмы обратной связи
В процессе разработки непрерывно используется несколько метрик. Хотя в соответствии с общей корпоративной философией здесь не придают такого значения количественным индикаторам, как, например, в 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 месяца — радикально переработанную (с большим количеством новых функций и измененной архитектурой). Небезынтересно отметить, что работа отвечающих на телефонные звонки и другие обращения о помощи инженеров службы поддержки финансируется за счет бюджета команд разработчиков данного продукта; поэтому последние заинтересованы в постоянной минимизации дефектов в каждой последующей версии сравнительно с предыдущей.
Контрольные вопросы
-
Расскажите об особенностях создания программного продукта.
-
Что такое жизненный цикл программного обеспечения?
-
Каковы основные свойства каскадной (итерационной) модели жизненного цикла?
-
Из каких этапов состоит модель жизненного цикла иМ1_?
-
Какова стоимость исправления ошибок в ПО на различных стадиях его разработки?
-
Что такое «управление требованиями»?
-
В чем заключается анализ проблемы?
-
Какие виды ограничений на создаваемое ПО необходимо выявить в процессе работы над требованиями?
-
Каковы существующие методы выявления требований к ПО?
Глава 3
АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Процесс проектирования программных продуктов начинается с определения требований к разрабатываемому программному обеспечению и его исходных данных. В результате анализа требований получают спецификации программного обеспечения в виде текстовых описаний, структурных схем и диаграмм. В процессе определения спецификаций строят общую модель предметной области и конкретизируют основные функции программного продукта и его поведение при взаимодействии с окружающей средой [1].
3.1. Определение требований к программным продуктам
Один из наиболее ответственных этапов создания программного продукта — этап постановки задачи. На этом этапе принимаются важные решения относительно функций создаваемого ПО, эксплуатационных ограничений, накладываемых на него. Производится выбор архитектуры, среды разработки ПО, интерфейса пользователя и др. От этого выбора будет зависеть качество и стоимость конечного программного продукта.
3.7.7. функциональные требования
Функциональные требования описывают сервисы, предоставляемые программной системой, ее поведение в определенных ситуациях, реакцию на те или иные входные данные и действия,