Метод PJM

Метод PJM оформлен в виде коммерческого продукта и называется PJM Advantage. Цель реализованного в PJM подхода — обеспечить участников проекта технологией, в которой проекты разных типов могут быть спланированы, оценены по ресурсам, проконтролированы и нормально завершены.

Другими словами, PJM — это определенная дисциплина ведения проекта, позволяющая гарантировать, что цели проекта, четко определенные в его начале, остаются в центре внимания на протяжении всего проекта.

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

Рис. 5.5. Этапы и процессы PJM

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

Рассмотрим более подробно процессы, которые формируют полный набор решаемых в PJM задач:

• Управление проектом и предоставление отчетности (Control and Reporting) - содержит задачи, в результате решения которых определяются границы проекта и подход к разработке, происходит управление изменениями и контролируется возможный риск. Здесь же содержатся задачи, связанные с ведением планов и предоставлением отчетности по проекту.

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

• Управление ресурсами (Resource Management) - включает задачи, связанные с обеспечением каждого этапа исполнителями, а также содержит указания о необходимых для выполнения работ по проекту умениях и навыках.

• Управление качеством (Quality Management) - гарантирует, что проект отвечает требованиям пользователя в течение всего процесса разработки.

• Управление конфигурацией (Configuration Management) - содержит задачи, помогающие сохранить, организовать и проследить за всем тем, что получается в результате выполнения проекта. Цикл решения задач методом PJM состоит из отдельных этапов.

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

По аналогии с CDM в методе PJM предусмотрено широкое использование шаблонов разрабатываемых документов. Для составления календарного плана работ предлагается воспользоваться шаблонами формата MS Project 4.0 либо АВТ Project Workbench 3.0, а для получения других документов - шаблонами MS Word.

Следует запомнить:

Промышленные технологии проектирования ПО поставляются как продукты и позволяют адаптировать их к конкретным условиям применения.

Вопросы для самоконтроля

1. Каковы основные характерные особенности технологии DATARUN?

2. В чем состоят основные характерные особенности RUP?

3. Каковы основные характерные особенности Oracle Method?

4. Что общего и какие различия имеются у перечисленных технологий?

ВСПОМОГАТЕЛЬНЫЕ СРЕДСТВА ПОДДЕРЖКИ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Прочитав эту главу, вы узнаете:

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

• Каковы их основные особенности.

6.1.

УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ К СИСТЕМЕ

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

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

Итак, требование — это условие или характеристика, которым должна удовлетворять система. Существуют функциональные и нефункциональные требования.

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

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

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

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

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

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

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

Управление требованиями (requirements management) представляет собой:

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

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

Управление требованиями преследует определенные цели:

• достичь соглашения с заказчиком и пользователями о том, что система должна делать;

• улучшить понимание требований к системе со стороны разработчиков;

• очертить границы системы;

• определить базис для планирования.

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

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

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

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

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

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

В настоящее время появились специализированные системы управления требованиями (Requirements Management Systems), обеспечивающие комплексную и сложную поддержку управления требованиями. Некоторыми из доступных на сегодняшний день средств, о которых упоминалось в главе 4, являются 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.

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

Помимо CASE-средств Rational, перечисленных в главе 4, RequisitePro интегрируется со средствами управления конфигурацией PVCS Version Manager и Microsoft Source Safe, а также со средством управления проектами Microsoft Project. Интеграция RequisitePro версии 4.5 с CASE-средством Rational Rose 2000 позволяет расширять диаграммы вариантов использования нефункциональными требованиями к системе.

6.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Аналитические модели для оценки проектов, описанные в литературе. Лучшими являются работы Барри Боэма (модель СОСОМО, разработанная им в начале 80-х гг., была позднее модифицирована в модель СОСОМО-2). Другой классической работой является книга Фредерика Брукса "Мифический человеко-месяц", также переизданная в 1995 г. с учетом современной технологии и практики разработки ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.3.

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

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

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

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

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

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

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

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

Аналитические исследования International Data Corporation (IDC) свидетельствуют о быстром росте мирового рынка средств управления конфигурацией (SCM - Software Configuration Management). Если в 1995 г. мировой объем продаж средств SCM составил 239 млн дол., то в 1996 г. - 350, в 1997 г. - 477, в 1998 г. - 595 млн дол. Оценка продаж SCM в 1999 г. составляет 750 млн дол. Лидером по объему продаж является корпорация Rational Software со своим продуктом управления конфигурацией ClearCase.

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

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

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

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

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

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

Другим распространенным средством управления конфигурацией является средство PVCS фирмы Merant, включающее интегрированный набор продуктов PVCS Professional (PVCS Version Manager, PVCS Tracker и PVCS Configuration Builder) и PVCS Notify.

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

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

Доступ к архивам PVCS Version Manager возможен не только через сам Version Manager, но и из более чем 50 инструментальных средств. Сюда входят PowerBuilder, Delphi, JBuilder, ERwin, Visual C++, Visual Basic, Oracle Developer и др.

Результатом работы PVCS Version Manager является созданный средствами файловой системы ОС репозиторий, хранящий в компактной форме все рабочие версии программного продукта вместе с необходимыми комментариями и метками.

PVCS Version Manager функционирует в среде Windows 95/98/NT, Solaris, HP-UX, AIX и SCO UNIX.

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

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

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

• разработчики (Development Engineers) - имеют право производить основные операции с требованиями и замечаниями в базе данных PVCS Tracker. Если разработчики делятся на подгруппы, то для каждой подгруппы могут быть заданы отдельные списки прав доступа;

• тестировщики (Quality Engineers) — имеют право производить основные операции с требованиями и замечаниями;

• специалисты службы сопровождения (Support Engineers) — имеют право вносить любые замечания, требования и рекомендации в базу данных, но не имеют прав по распределению работ и изменению их приоритетности и сроков исполнения;

• руководители (Managers) — имеют право распределять работы между исполнителями и принимать решение об их надлежащем исполнении. Руководителям разных групп могут быть заданы различные права доступа к базе данных PVCS Tracker.

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

Требование или замечание, поступающее в PVCS Tracker, проходит четыре этапа обработки:

• регистрация — внесение замечания в базу данных;

• распределение — назначение ответственного исполнителя и сроков исполнения;

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

• приемка — приемка работ и снятие их с контроля или направление на доработку.

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

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

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

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

• успевает ли группа разработчиков справляться с поступающими замечаниями;

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

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

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

PVCS Tracker предназначен для использования в рабочих группах, объединенных в общую сеть. В этом случае центральная база или проект PVCS Tracker находится на общедоступном сервере сети, доступ к которому реализуется посредством ODBC-драйверов, входящих в состав PVCS Tracker. Главной особенностью PVCS Tracker по сравнению с обычным приложением СУБД является способность автоматически уведомлять пользователя о поступлении интересующей его или относящейся к его компетенции информации и гибкая система распределения полномочий внутри рабочей группы. При необходимости PVCS Tracker может использовать для уведомления удаленных членов группы электронную почту.

PVCS Tracker поддерживает групповую работу в локальных сетях и взаимодействует с СУБД Oracle, MS SQL Server и Sybase посредством ODBC.

PVCS Configuration Builder предназначен для сборки окончательного продукта из компонентов проекта. Он позволяет описывать процесс сборки как на стандартном языке МАКЕ, так и на собственном внутреннем языке, имеющем существенно большие возможности. PVCS Configuration Builder выполняет сборку программного продукта на основании файлов, хранящихся в репозитории PVCS Version Manager.

Обычная процедура сборки программного продукта с помощью PVCS Configuration Builder состоит из трех шагов:

• строится файл зависимостей между исходными модулями;

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

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

6.4

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

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

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

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

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

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

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

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

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

6.5

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительную информацию по данным средствам можно получить на сайте Rational Software Corporation (https://www.rational.com).

6.6

УПРАВЛЕНИЕ ПРОЕКТОМ ПО

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

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

Основные преимущества использования системы управления проектами включают:

• централизованное хранение информации по графику работ, ресурсам и стоимости;

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

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

• возможности автоматизированной генерации отчетов и графических диаграмм, разработки документации по проекту.

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

• средства визуального проектирования структуры работ проекта;

• средства планирования по методу критического пути;

• средства ресурсного планирования (описание, назначение и оптимизация загрузки ресурсов);

• возможности стоимостного анализа;

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

• средства создания отчетов и графических диаграмм;

• средства организации групповой работы.

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

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

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

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

Microsoft Project и Time Line — недорогие системы управления проектами, просты в использовании, доступны для новичков и непрофессионалов. Они содержат базовые возможности, позволяющие осуществлять достаточно гибкое планирование и управление людскими ресурсами, поддерживают несложное многопроектное планирование и контроль.

Microsoft Project 98 — один из лидеров по возможностям объединения участников проекта средствами электронной почты или Интранет. При описании ресурса для каждого исполнителя может быть указан адрес его электронной почты. Информация о работах проекта может сохраняться в формате HTML и публиковаться на внутреннем Web-cepвepe. Кроме стандартных форматов файлов Microsoft Project (MPP и МРХ) пользователь может сохранять информацию о проекте в форматах ODBC, Excel и Access. Формат MPD (Microsoft Project Database) позволяет хранить все данные о проекте в структуре, доступной как из Microsoft Project 98, так и из Access.

Что касается Time Line, то система позволяет хранить все данные, касающиеся проектов организации, в единой базе данных. Отдельный модуль импорта/экспорта позволяет обмениваться данными с другими системами (Microsoft Project, Time Line 1.0 for Windows), базами данных (dbf) и электронными таблицами. Система Time Line 6.5 поддерживает стандарты ODBC, OLE 2.0, DDE и макроязык Symantec Basic.

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

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

Open Plan поставляется в двух вариантах (Professional и Desktop), каждый из которых отвечает различным потребностям исполнителей, менеджеров и других участников проекта. Обе версии работают с одной базой данных. Совместное использование профессиональной и "облегченной" версий системы управления проектами дает возможность не только учесть потребности всех групп пользователей, но и значительно снизить стоимость решения.

Open Plan обладает прямым доступом к базам данных. Пользователь может выбрать, в каком формате хранить данные по проектам (в собственном формате Open Plan, в форматах Oracle, SQL Server, Sybase, xBase).

Open Plan обеспечивает ограничение доступа к данным проекта, предоставляя различные права на доступ к определенным данным, делая их доступными ограниченному кругу лиц и регулируя их совместное использование. Средство "Директор управления проектами", встроенное в Open Plan, позволяет упорядочить применение стандартных элементов проектов и процедур. В Open Plan предлагается 65 моделей, построенных на базе руководств PMI (Project Management Institute — Институт проектного менеджмента, США), которые можно настроить для создания документов, отвечающих требованиям стандартов ISO.

6.7

ДИНАМИЧЕСКИЕ МОДЕЛИ В АНАЛИЗЕ И ПРОЕКТИРОВАНИИ ИС

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

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

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

В настоящее время идет активное развитие интегрированных многофункциональных средств, объединяющих в себе возможности объектно-ориентированного программирования, CASE-технологий, имитационного моделирования, инженерии знаний и средств быстрой разработки приложений. Две наиболее продвинутые в этом отношении системы — SPARKS (System Performance Analysis using Realtime Knowledge-based Simulation), разработанная фирмой Coopers & Lybrand Consulting (США), и ReThink, предлагаемая фирмой Gensym (США), ведущим поставщиком инструментальных средств для разработки интеллектуальных систем управления производством. Системы SPARKS и ReThink имеют много общего как в части концепций, положенных в основу разработки, так и в части методов использования, поскольку в основе и первой, и второй лежит оболочка экспертных систем реального времени G2 фирмы Gensym — объектно-ориентированный инструментарий с встроенными возможностями моделирования динамических систем.

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

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

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

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

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

Система ReThink включает ряд базовых компонентов, на основе которых строится модель бизнес-процессов:

• блоки — выполняют операции над объектами, такие, как создание объектов, исполнение бизнес-функций, установление и разрыв ассоциаций между объектами, удаление объектов;

• ресурсы (средства труда) — предназначены для ограничения исполняемых операций на основе объема и состава наличных ресурсов;

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

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

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

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

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

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

ReThink поддерживает коллективную работу с приложениями на основе архитектуры "клиент-сервер" с помощью системы Telewindows комплекса G2. Как и сам инструментальный комплекс G2, система ReThink функционирует на большинстве рабочих станций в среде UNIX, Windows 95/98/NT.

Следует запомнить:

Наиболее распространенными на практике вспомогательными средствами поддержки ЖЦ ПО являются:

• средства управления требованиями;

• средства оценки затрат на разработку ПО;

• средства управления конфигурацией ПО;

• средства тестирования;

• средства документирования;

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

Вопросы для самоконтроля

1. В чем заключается важность управления требованиями?

2. Каковы основные функции средств управления конфигурацией ПО?

3. На какой стадии проекта должна выполняться оценка затрат на разработку ПО?

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

КРАТКИЙ СЛОВАРЬ ТЕРМИНОВ

А

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

Агрегация - отношение "часть - целое".

Ассоциация — отношение между экземплярами классов.

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

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

В

Вариант использования (use case) — последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом).

Внешня