Вспомогательные средства поддержки жизненного цикла ПО

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

Наиболее распространенные структурные и объектно-ориенти­рованные методы создания ПО направлены на моделирование требо­ваний с помощью различного рода диаграмм. Но в данном случае речь идет именно об управлении требованиями. Эти два понятия — моделирование и управление — не являются противоречивыми или не­совместимыми.

В реальных проектах пользовательские требования зачастую дол­жным образом не документируются. В свое оправдание разработчи­ки говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не зна­ют, что им нужно. Таким образом, обычно полагаются на методы и средства прототипирования, с помощью которых можно наглядно про­демонстрировать всю важную проектную работу, а также выявить ре­альные требования к системе. Это порождает главную проблему: не­возможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования "необходимо выполнить", какие "следует выполнить" и какие "можно выполнить"? Структурные и объектно-ориентирован­ные методы не дают ответа на этот вопрос, поскольку они служат в первую очередь для понимания и объяснения требо­ваний, а не для управления ими в динамике (можно, ко­нечно, определять приоритеты, раскрашивая кружочки на диаграм­мах потоков данных, но они изначально предназначены вовсе не для этого).

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

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

В настоящее время появились специализированные системы управления требованиями (Requirements Management Systems), обес­печивающие комплексную и сложную поддержку управления требованиями. Некоторыми из доступных на сегодняшний день средств являются Requisite Pro (Rational Software) и DOORS (Quality Systems and Software Inc.).

Средства управления требованиями обладают различными воз­можностями в зависимости от подхода разработчика. Стандартными можно считать две из них:

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

• отслеживание зависимостей между требованиями.

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

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

Еще одна важная задача, которую позволяет решить хране­ние данных о взаимозависимости требований, — это управление изменениями требований. Зная, какие требования строились на основе измененных, можно корректно отработать внесение из­менений. Каждое требование может быть описано любым удобным набо­ром атрибутов. Обычно помимо источника возникновения указыва­ется обязательность и приоритет, статус. Компоновать требования в разделы можно по любым удобным критериям.

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

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

По существу, для описания требований уже имеется одно зна­комое всем средство. Оно называется "текстовый процессор". В самом деле, начальная версия такого документа обычно исходит от пользователей, например, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу возник­шей потребности в новом замечательном продукте со свойствами X, Y и Z, который мог бы соперничать с продуктом конкурента. На этой ранней стадии пользователи рассматривают текстовый процессор как свое средство, а записку службы маркетинга - как свой документ. В результате они проявляют гораздо большую го­товность участвовать в последующих дискуссиях по поводу при­оритетности требований, если при этом продолжают использовать­ся аналогичные средства и документы. Таким образом, наблюда­ется тенденция, ведущая к документоцентричному управлению требованиями, когда средства, используемые специалистами по информационным технологиям (например, RequisitePro или DOORS), тесно интегрируются с текстовыми процессорами и до­кументами, в которых пользователи хорошо разбираются.

В заключение остановимся на некоторых возможностях и харак­теристиках системы RequisitePro:

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

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

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

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

- ввод требований осуществляется с помощью Microsoft Word, с которым интегрировано RequisitePro. Кроме того, возможен импорт существующих требований, документированных средствами Microsoft Word. Средство Import Wizard позволяет собирать требования из раз­ных источников: текстовых файлов, электронных таблиц и баз дан­ных. Сами требования могут храниться в текстовых документах и базах данных MS Access, MS SQL Server или Oracle.

- имеются возможности документирования требований за счет использования стандартных или создаваемых текстовых шаблонов. В частности, предусмотрены шаблоны для выпуска документации в соответствии со стандартами IEЕЕ, ISO, SEI СММ и RUPж

- RequisitePro интегрируется со сред­ством управления проектами Microsoft Project. Интеграция RequisitePro версии 4.5 с CASE-средством Rational Rose 2000 позво­ляет расширять диаграммы вариантов использования нефункцио­нальными требованиями к системе.

ОЦЕНКА ЗАТРАТ НА РАЗРАБОТКУ ПО

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

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

Оценка затрат на разработку ПО предполагает выполнение сле­дующих четырех шагов:

• оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOG - Lines Of Code), а в настоящее время является количество функциональных точек (FPs — Function Points);

• оценка трудоемкости в человеко-месяцах или человеко-часах;

• оценка продолжительности проекта в календарных месяцах;

• оценка стоимости проекта.

Оценка размера проекта базируется на знании требований к си­стеме. Для такой оценки существуют два основных способа:

1. По аналогии. Если в прошлом приходилось иметь дело с по­добным проектом и его оценки известны, то можно, отталкиваясь от них, приблизительно оценить свой проект.

2. Путем подсчета размера по определенным алгоритмам на ос­новании исходных данных — требований к системе.

Оценка трудоемкости проекта выводится на основании его раз­мера. Для такой оценки также существуют два основных способа:

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

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

• по крайней мере один из предыдущих проектов (а лучше, если несколько) имеет аналогичный характер и размер;

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

2. Если предыдущий подход по разным причинам оказывается неприменимым, следует использовать один из известных алгоритми­ческих методов оценки (например, модель СОСОМО (Constructive COst MOdel — конструктивная стоимостная модель) Барри Боэма).

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

Согласно Эдварду Йордану, все доступные средства оценки клас­сифицируются следующим образом:

• Средства оценки, являющиеся коммерческими продуктами, такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (Software Productivity Research (SPR)). Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельно­сти, действует принцип "что заложишь, то и получишь")- В луч­шем случае с помощью таких продуктов можно получить оценку с точностью ±10%. Даже если точность будет ±50%, это все рав­но лучше, чем брать данные "с потолка".

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

• Аналитические модели для оценки проектов.

• Различные руководства и отчеты организаций, подобных Software Engineering Institute (SEI), которые могут помочь при выполне­нии оценки проектов.

• Такие распространенные методы, как прототипирование, также могут использоваться для оценки критичности тех или иных про­ектных ограничений для всей разрабатываемой системы в целом. Этот подход позволяет привнести немного здравого смысла в про­ектную команду и в окружающих ее менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написа­ла 1 млн строк кода за 12 мес., то следовало бы в течение первого месяца разработать небольшой прототип будущей системы, кото­рый, по крайней мере, позволит грубо оценить производительность проектной команды, а также реализуемость проекта в целом.

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

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

Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной организацией IFPUG (International Function Point User Group). Существуют специальные про­граммные средства, автоматизирующие проведение оценок по методу функциональных точек и позволяющие оценить, насколько быстро и с какими затратами в действительности удастся реализовать проект. Од­ним из таких средств является KnowledgePLAN — продукт фирмы SPR.

KnowledgePLAN имеет следующие возможности:

• формирование близкого к реальному плана работ по проекту;

• определение трудоемкости и стоимости планируемых проектов;

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

• проведение анализа "what — if ("что, если") для поиска лучших решений;

• проведение сравнительного анализа качества и производитель­ности разработки разнотипных проектов или однотипных про­ектов, при выполнении которых использовались различные тех­нологии;

• накопление статистической многомерной информации о проек­те и его участниках;

• классификация проектов для принятия решения о структуре уп­равления проектом;

• анализ плановой и реальной оценки сложности и величины раз­работанного ПО и трудоемкости выполнения проекта.

СРЕДСТВА УПРАВЛЕНИЯ КОНФИГУРАЦИЕЙ ПО

Управление конфигурацией ПО является одним из наиболее важ­ных вспомогательных процессов жизненного цикла ПО. Цель управления конфигурацией — обеспечить управляемость и контролируемость процессов разработки и сопровождения ПО. Для этого необходима точная и достоверная информация о состоянии ПО и его компонентов в каждый момент времени, а также обо всех пред­полагаемых и выполненных изменениях. Предполагаемые измене­ния разделяются на следующие группы:

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

• изменения, которые целесообразно внести в очередную вер­сию с учетом затрат на их реализацию и улучшения эффектив­ности ПО;

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

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

Все проанализированные изменения регистрируются. Для при­нятых к внедрению изменений разрабатывается план доработок про­грамм и определяется ответственный за каждую корректировку про­граммы.

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

Лидером по объему продаж является корпорация Rational Software со своим продуктом управления конфигурацией ClearCase.

Rational ClearCase - средство, предназначенное для управления конфигурацией ПО сложных информационных систем. ClearCase позволяет хранить в репозитории полные хронологии версий каждо­го объекта, созданного или измененного в процессе разработки си­стемы. К ним относятся: исходный программный код, библиотеки, исполняемые программы, документация, web-страницы и каталоги.

Rational ClearCase работает с такими инструментальными сред­ствами разработки приложений, как Visual Basic, Visual C++, Visual Java++, PowerBuilder и Oracle Developer.

Семейство продуктов ClearCase включает в себя следующие про­дукты:

• собственно ClearCase — средство.управления версиями и конфи­гурацией создаваемой системы;

• ClearCase MultiSite - средство поддержки географически удален­ных групп разработчиков;

• ClearQuest - средство контроля изменений в модулях и подсис­темах проекта.

СРЕДСТВА ДОКУМЕНТИРОВАНИЯ

Для создания документов в процессе разработки ПО исполь­зуются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документиро­вания встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно исполь­зуется SoDA (Software Document Automation - автоматизирован­ное документирование ПО).

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

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

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

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

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

Среда функционирования SoDA - ОС UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packani HP 9000.

СРЕДСТВА ТЕСТИРОВАНИЯ

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

Одно из наиболее развитых средств автоматизированного тести­рования приложений архитектуры "клиент-сервер" Rational TeamTest обеспечивает следующие возможности:

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

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

• поддержка различных средств разработки приложений и языков программирования, в том числе Microsoft Visual Basic и Visual C++, Java, Oracle Developer, PowerBuilder;

• поддержка командной работы над проектом за счет контролиру­емого доступа ко всем аспектам тестов, отслеживания ошибок, внесения изменений через Интернет, оповещения по электрон­ной почте.

Основой Rational TeamTest является средство функционально­го тестирования Rational Robot. Скрипты, создаваемые в Rational Robot, обеспечивают поиск ошибок в приложении, оставаясь вир­туально независимыми от внесенных изменений и среды функци­онирования приложения. Без дополнительных изменений скрип­ты могут использоваться в среде Windows 95, Windows 98 и Windows 2000. Объектное тестирование обеспечивает быстрое создание скриптов, которые в дальнейшем можно легко изменить, создать заново и воспроизвести.

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

TeamTest также включает в себя средство Rational ClearQuest/TT Edition для управления запросами на изменения, позволяя команде разработчиков регистрировать ошибки по мере их возникновения, устанавливать статус исправления, внедрять изменения в приложе­ние и отсылать сообщение об успешном внедрении изменений об­ратно команде разработчиков и менеджеров. ClearQuest/TT Edition полностью совместимо с ClearQuest.

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

Дата добавления: 2014-01-13