А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 27

Чтобы облегчить окончательноеопределение области применения ТС ПО, предметная область пилотногопроекта должна быть типичной для обычной деятельности организации.Пилотный проект должен помочь определить любую дополнительнуютехнологию, обучение или поддержку, которые необходимы для переходаот пилотного проекта к широкомасштабному использованию ТС ПО. Врамках этих ограничений пилотный проект должен иметь небольшой, нозначимый размер.Масштабируемость. Результаты, полученные в пилотном проекте,должны показать масштабируемость ТС ПО. Цель - получить четкоепредставление о масштабах проектов, для которых данная ТС ПОприменима.166Представительность. Пилотный проект не должен быть необычнымили уникальным для организации.

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

Группа специалистов, участвующих в проекте,должна обладать высоким авторитетом, при этом результаты проектабудут всерьез восприняты остальными сотрудниками организации.Готовность проектной группы. Проектная группа должна обладатьготовностью к нововведениям, технической зрелостью и приемлемымуровнем опыта и знаний в данной ТС ПО и предметной области. С другойстороны, группа должна отражать в миниатюре характеристикиорганизации в целом.В процессе оценки пилотного проекта организация должна определитьсвою позицию по следующим трем вопросам:• Целесообразно ли внедрять ТС ПО?• Какие конкретные особенности пилотного проекта привели к егоуспеху (или неудаче)?• Какие проекты или подразделения в организации могли быполучить выгоду от использования ТС ПО?Если ТС ПО удовлетворила или даже превысила ожиданияорганизации, то решение об ее внедрении может быть принято достаточнопросто и быстро.С другой стороны, может оказаться, что в рамках пилотного проектаТС ПО не оправдала тех ожиданий, которые на нее возлагались, или же впилотном проекте она использовалась удовлетворительно, однако опытпоказал, что дальнейшие вложения в ТС ПО не гарантируют успеха.Возможны четыре варианта результатов и соответствующих действий:• Пилотный проект потерпел неудачу, и его анализ показалнеадекватность ожиданий организации.

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

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

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

Такой вариантдолжен рассматриваться только в том случае, если осталиськонкретные неразрешенные вопросы относительно внедрения ТСПО в организации. Новый пилотный проект должен быть таким,чтобы ответить на эти вопросы.• Отказаться от ТС ПО. В этом случае причины отказа от конкретнойТС ПО должны быть определены в терминах потребностейорганизациииликритериев,которыеосталисьнеудовлетворенными.

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

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

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

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

д.Стандартоформленияпроектнойдокументациидолженустанавливать:• комплектность, состав и структуру документации на каждой стадиипроектирования (в соответствии со стандартом ГОСТ Р ИСО 912794 "Системы обработки информации. Документация пользователя иинформация на упаковке потребительских программных пакетов");• требования к оформлению документации (включая требования ксодержанию разделов, подразделов, пунктов, таблиц и т.д.);• правила подготовки, рассмотрения, согласования и утверждениядокументации с указанием предельных сроков для каждой стадии;• требования к настройке издательской системы, используемой вкачестве встроенного средства подготовки документации;• требования к настройке CASE-средств для обеспечения подготовкидокументации в соответствии с установленными правилами.Стандарт интерфейса пользователя должен регламентировать:• правила оформления экранов (шрифты и цветовая палитра), состави расположение окон и элементов управления;• правила использования клавиатуры и мыши;• правила оформления текстов помощи;• перечень стандартных сообщений;• правила обработки реакции пользователя.Стандарты использования ТС ПО, выработанные во время пилотногопроекта, должны использоваться в качестве отправной точки дляразработки более полного набора стандартов использования средств вданной организации.

При этом должен учитываться опыт участниковпилотного проекта.Дополнительную информацию по материалу подразд. 4.3 можнонайти в американских стандартах IEEE Std 1348-1995. IEEE RecommendedPractice for the Adoption of Computer-Aided Software Engineering (CASE)Tools и IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluationand Selection of CASE Tools (IEEE - Institute of Electrical and ElectronicsEngineers - Институт инженеров по электротехнике и электронике).Временной разрыв между их утверждением составляет четыре года(первый стандарт был утвержден в декабре 1996 г., а второй - в декабре1992 г.), однако, они достаточно тесно взаимосвязаны, поскольку первыйстандарт содержит целый ряд ссылок на второй (помимо упомянутыхстандартов, существует также упомянутый выше международный стандартISO/IEC 14102:1995(E).