Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Особенности современных проектов 511

методологий, как структурный анализ или объектно-ориентиро-

ванное проектирование. Ответы были примерно следующими:

«иногда», «вроде

бы

да»,

«от

случая к случаю» и

«а что

это такое?».

Когда же он поинтересовался относительно использования

CASE-средств (которые в то время все еще были довольно попу-

лярными в индустрии ПО), то из их ответов понял, в чем заклю-

чается общее мнение майкрософтовцев: эти средства годятся для

«людей с улицы», т.е. «невежественных дикарей, которые только

что вылезли из своего первобытного леса и начали обучаться

профаммированию, в отличие от настоящих профаммистов, не

нуждающихся во всяких финтифлюшках».

Будучи слегка уязвленным, он полюбопытствовал, использу-

ют ли

их проектные команды хоть какие-нибудь средства, и в от-

вет

услышал,

что каждая команда Microsoft может выбрать любые

средства, которые сочтет подходящими для своего проекта. Ухва-

тившись за такой ответ, Йордон спросил, какое средство считает

наиболее важным типичная проектная команда?

«На днях я задал одной из проектных команд такой же воп-

рос»,

—

ответил один из менеджеров. «Как

вы

думаете,

что они от-

ветили?»

«Какой-нибудь высокопроизводительный компилятор C++?

Ассемблер? Или мощное средство отладки для устранения мно-

жества ошибок в их коде (хи-хи-хи)?»

«Ничего подобного», - ответил менеджер, игнорируя иро-

нию.

«Они ответили: электронная почта. Средний разработчик

Microsoft получает сотню сообщений в день; он живет в элект-

ронной почте. Уберите электронную почту, и проект умрет».

Эти события происходили

до

начала эры Internet

и World Wide

Web,

когда сотня почтовых сообщений

день могла потрясти во-

ображение. Однако можно представить себе, что если бы такой

же вопрос о «наиболее важном средстве» был задан в 1996 п, от-

ветом могло быть «World

Wide

Web»;

по аналогии, «факс» в 1987 г,

«ПК» в

1983

г.,

«онлайновый терминал» в

1976

г и «телефон на ра-

бочем столе» в 1964

г.

Очевидно, не следует ожидать, что команда «безнадежного»

проекта сможет ограничиться только одним средством. Большин-

ство команд (даже в нормальных проектах) пользуется в своей

повседневной работе самыми разнообразными средствами и тех-

нологиями. Правда, подчас количество средств становится черес-

512 Глава?

чур большим, технологии

—

слишком новыми, а иногда нежела-

тельные средства навязываются некомпетентными менеджерами.

Ранее настоятельно рекомендовалось устанавливать приори-

теты для пользовательских требований. Такой же подход исполь-

зуется по отношению к средствам и технологии, и его разумно

применить в самом начале проекта. Наиболее очевидная причи-

на

—

экономия средств. Даже если средства хорошо работают и

все знакомы с ними, их приобретение может стоить слишком до-

рого.

Кроме того, на их получение может уйти много времени

—

процесс приобретения их в условиях обычной корпоративной

бюрократии может завершиться

уже

после окончания работы над

проектом. Для большинства «безнадежных» проектов следует

выбрать небольшое количество критически важных средств и

убедить высшее руководство (или соответствуюилую службу) в

необходимости их приобретения.

С другой стороны, предположим, что команда работает в

крупной корпорации, имеющей в своем распоряжении сотни

различных

средств,

приобретавшихся

течение ряда

лет.

Следует

ли их все использовать? Конечно,

нет!

Даже если все они работа-

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

запомнить, как ими пользоваться, а также дополнительные уси-

лия для обеспечения их совместной работы обычно сводят на нет

всю выгоду. Можно провести аналогию с командой альпинистов,

которые собираются штурмовать вершину и пытаются решить,

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

вещи (палатки, питьевая вода

т.д.);

и, если маршрут

не

слишком

сложный, можно взять с собой некоторые новомодные приспо-

собления, о которых написано в альпинистском журнале. Одна-

ко,

если они собираются штурмовать Эверест, им не обойтись без

помощи ослов или носильщиков из местных жителей, иначе они

будут не в состоянии тащить на спине по

300

фунтов снаряжения

на человека.

Команда «безнадежного» проекта должна самостоятельно,

независимо от принятых в организации стандартов, решить, ка-

кие средства являются необходимыми, а без каких можно обой-

тись.

Очень важно участникам команды прийти к единому мне-

нию относительно используемых в проекте средств, иначе насту-

пит хаос. Разумеется, это утверждение не следует понимать бук-

вально; оно не означает, что все участники команды должны обя-

зательно использовать один и тот же текстовый процессор для

Особенности современных проектов 513

подготовки своих документов, хотя, скорее всего, важен один и

тот же компилятор C++. Одна из проблем, связанных с «безна-

дежными» проектами, заключается в том, что разработчики ПО

считают допустимой полную анархию на индивидуальном уровне

(например, если им хочется использовать никому не известный

компилятор C++, который они переписали с университетского

Web-сайта, то они считают это своим неотъемлемым правом). Но

это не так: неотъемлемым правом обладает команда, и менеджер

проекта должен неуклонно проводить его в жизнь во всех ситуа-

циях, когда несовместимые средства могут привести к значитель-

ным разногласиям.

Следовательно, пока участники команды не поработают

вместе над несколькими «безнадежными» проектами, они не

придут к единому мнению относительно «минимального» набора

средств. Определив набор средств, команда выбирает те, которы-

ми следует пользоваться. При этом возникает еще одна проблема

- добиться согласия в команде и получить разрешение руковод-

ства на приобретение новых средств.

Менеджер проекта должен настаивать на достижении кон-

сенсуса; в самом деле, это может быть одним из критериев, ис-

пользуемых менеджером для выбора потенциальных участников

команды. То же самое можно сказать относительно процессов,

которые обсуждались ранее.

Вот перечень средств, которые рекомендуются для «безна-

дежных» проектов:

Электронная почта, ПО для групповой работы, средства

Internet/Web, видеоконференции и т.д. Так же, как и в эпизоде с

Microsoft, эти средства находятся в начале списка. Причина зак-

лючается в следующем: электронные средства общения и взаимо-

действия являются не только более эффективным средством

коммуникации, чем записки и факсы, но они также способству-

ют координации и сотрудничеству Безразлично, какие именно

средства использовать: Microsoft Outlook или Lotus Notes; важно

только, чтобы вся команда работала в сети и хранила там общие

проектные данные.

Средства прототипирования/быстрой разработки приложений

(RAD). Почти все «безнадежные» проекты используют в той или

иной степени прототипирование и пошаговую разработку; следо-

вательно, им необходимы соответствующие инструментальные

средства. Сегодня не так просто отыскать популярную среду раз-

514 Глава?

работки приложений, которая заявляла бы о себе иначе, чем сре-

да RAD. Большинство таких средств обладают визуальным поль-

зовательским интерфейсом, выполненным в стиле «drag and

drop», облегчающим и ускоряющим процесс разработки. Важно,

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

одного и того же поставщика. Если часть команды использует

среду разработки Java компании Sun, а другие

—

Microsoft Visual

J4-+, то это явно глупо, хотя

допустимо

точки зрения техноло-

гии.

Средства

управления

конфигурацией/управления

версиями.

Не-

которые полагают, что они должны быть на первом месте в спис-

ке.

Очевидно, использование

средств

управления конфигурацией

может принести больше пользы, если они будут интегрированы

со средствами разработки приложений. Например, SourceSafe от

Microsoft может и не быть самым лучшим средством управления

версиями ПО, однако тот факт, что оно тесно интегрировано с

Visual Basic, является весомым аргументом в его пользу. Анало-

гично, многие другие средства разработки приложений интегри-

рованы с PVCS или другими подобными средствами управления

конфигурацией.

Средства тестирования и отладки. Многие автоматически

включают эти средства в «базовый» набор средств разработки

приложений, позволяющих создавать, компилировать и выпол-

нять код.

Средства управления проектом (оценка, планирование,

PERT/GANTT

т.д.).

Обычно их считают средствами менеджера

проекта. К этой же категории следует отнести такие средства

оценки, как ESTIMACS (Computer Associates), CHECKPOINT

(Software Productivity Research) и SLIM (Quantitative Software

Management). Они, я считаю, являются важными, поскольку

позволяют

в ходе

выполнения проекта динамически пересматри-

вать планы и сроки.

Наборы повторно используемых компонентов. Если проектная

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

рассматривает ее как стратегическое оружие, позволяющее дос-

тичь высокого уровня продуктивности разработки, то набор пов-

торно используемых компонентов должен быть в списке тех

средств, которые необходимо использовать. Это может быть на-

бор компонентов

VBX

для Visual Basic, компоненты Java компа-

нии Sun или библиотека классов

STL для

С4-+. Разумеется, мож-

Особенности современных проектов 515

но использовать и компоненты, разработанные другими проект-

ными командами

организации. Выбор

их

обычно зависит от ис-

пользуемого языка программирования, и это еще одна проблема,

нуждающаяся в выработке единого подхода со стороны проект-

ной команды.

CASE-средства

для анализа и

проектирования.

Некоторые про-

ектные команды рассматривают CASE-средства как «костыли»

для новичков,

другие считают их не менее важными, чем текс-

товые процессоры. Самая большая проблема, связанная с CASE-

средствами, заключается в том, что они поддерживают (а иногда

навязывают) определенную методологию, которую проектная

команда не понимает и не желает использовать.

Упомянутая проблема CASE-средств, вероятно, представляет

собой наиболее очевидный пример трюизма: средства и процес-

сы связаны друг с другом сложным образом. Бессмысленно

браться за объектно-ориентированное CASE-средство, поддер-

живающее анализ, если разработчики никогда

не

слышали об ие-

рархии классов или диаграммах вариантов использования. Ис-

пользование такого CASE-средства будет не только бесполез-

ным, но и чрезвычайно обременительным, если проектная ко-

манда искренне полагает, что диаграммы классов представляют

собой лишенные смысла формы бюрократических документов.

Но ситуация не всегда бывает черно-белой. Например, про-

ектная команда считает, что диаграммы потоков данных полез-

ны,

но только как «неформальное» средство моделирования. Та-

ким образом, «гибкое» CASE-средство может рассматриваться

как нужное и полезное,

то время как «жесткое» CASE-средство

может быть отвергнуто.

Все это означает, что команда «безнадежного» проекта долж-

на в первую очередь нормально воспринимать те процессы и ме-

тоды, которым она собирается следовать. Кроме того, она долж-

на

решить,

каким из них надо подчиняться беспрекословно, а ка-

ким

—

следовать

духу,

но не букве закона. После принятия такого

решения можно соответственно выбрать (или отвергнуть) сред-

ства и технологию. Таким же образом менеджер проекта может

решить использовать какое-либо средство для усиления процес-

са, необходимость которого все понимают, но на практике следу-

ют ему достаточно небрежно; примеры таких процессов

—

конт-

роль версий и управление конфигурацией.

516 Глава?

Один из величайших мифов, касающихся использования

инструментальных средств в любых проектах (и особенно опас-

ных в безнадежных проектах) заключается в отношении к сред-

ству как к «серебряной пуле», которая позволит творить чудеса.

Разумеется, поиском чудес занимается в основном высшее руко-

водство. Однако даже менеджера проекта могут соблазнить рек-

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

гениальных средств можно

десять

раз

повысить производитель-

ность профаммирования, тестирования или какой-нибудь дру-

гой деятельности.

Помимо проблемы, заключающейся в новизне таких средств

и в неумении их использовать, существует более важный момент:

средство станет подобным «серебряной пуле» только в том слу-

чае,

если оно позволит или заставит разработчиков изменить

свои процессы. Едва ли кто-нибудь станет возражать против ис-

пользования усовершенствованных технологий, позволяющих

избавляться от рутинных и утомительных процессов. Труднее

внедрить новую технологию, требующую введения новых про-

цессов или модификации существующих процессов, к которым

привыкли.

Ирония заключается в том, что большинство организаций в

своих провалах винит технологию. Они приобретут дорогостоя-

щую библиотеку классов или поменяют свою старую технологию

разработки ПО на объектно-ориентированную, исходя из пред-

положения, что объекты и повторное использование

—

это одно и

то же. Обнаружив, что не добились сколько-нибудь ощутимых

результатов, они будут винить во всем объектную технологию,

библиотеку классов, поставщика и др. Между тем все процессы

остались

точности такими

же,

какими

были до

внедрения новой

технологии. Культура такой организации может быть выражена

следующей фразой: «Только бездари пользуются чужим кодом;

настоящие профаммисты, черт возьми, пишут свой!»

С точки зрения работы над «безнадежным» проектом мораль

проста: если внедрение новых средств потребует серьезного из-

менения стандартных процессов команды, то это значительно

увеличит риск

и,

возможно, будет способствовать провалу проек-

та. Необходимость обучения и освоения практического исполь-

зования новых средств создает дополнительные проблемы. Одна-

ко наиболее серьезной из них является изменение режима рабо-

ты,

который целиком определяется процессом. Это трудно еде-

Особенности современных проектов 517

лать и в нормальных условиях, когда у нас достаточно времени,

чтобы относительно безболезненно перейти к новому процессу

Для «безнадежного» проекта такой переход будет просто катаст-

рофическим.

При работе над «безнадежными» проектами некоторые часто

хватаются за новые средства и технологии для достижения более

высокой продуктивности. При этом возникают два наиболее ве-

роятных риска

—

технология и обучение. Во многих случаях но-

вое средство даже не является законченным коммерческим про-

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

из Интернета бета-версию. Или же данное средство невозможно

интегрировать с любыми другими средствами, используемыми

проектной командой; поставщик давал на этот счет неопределен-

ные обещания, однако в результате оказалось, что возможности

экспорта-импорта изобилуют

ошибками.

Или, средство никем не

поддерживается

—

оно разработано студентом из Ирака или (что

еще хуже) создано

домашних условиях одним из разработчиков

ПО,

который не видит ничего странного в том, что банк разраба-

тывает свое собственное CASE-средство,

страховая компания

—

свою СУБД.

Допустим, что средство является достаточно надежным, а его

поставщик пользуется устойчивой репутацией и поддержкой на

высоком уровне.

этом случае проблемы будут связаны с освое-

нием, поскольку

даже

если это средство прежде широко исполь-

зовалось

организации, никто не воспринимал его как «серебря-

ную

пулю»,

которая сможет чудесным образом спасти проектную

команду от гарантированной катастрофы. Иногда можно встре-

тить проектную команду, добивающуюся разрешения использо-

вать какое-либо мощное средство, с которым она

уже

имела дело

в предьщущей

работе.

Однако это редкое

явление.

большинстве

случаев никто из участников проектной команды и вообще ник-

то в организации никогда прежде не видел или не использовал

подобное средство. Если предположить, что не существует ника-

ких проблем, связанных

данным средством, тогда все, что оста-

ется

—

это обучение и практика.

Как много времени на это потребуется? Очевидно, это зави-

сит от характера и сложности средства, а также от его пользова-

тельского интерфейса, возможностей онлайновой подсказки и

др.

В лучшем случае разработчики могут самостоятельно разоб-

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

такую возможность очень хо-

518 Глава?

чется верить менеджеру проекта и разным другим руководите-

лям, поскольку они считают любое обучение потерей времени и

отвлечением от работы над проектом. Более реалистичная оцен-

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

день или неделя. Независимо от формы обучения (занятия в

классе, чтение книги или просто «ифы» со средством), на это все

равно потребуется какое-то время.

Однако

результате недельного обучения не получится опыт-

ного пользователя, в совершенстве владеющего средством. Это

должно быть очевидным, однако нарушает планы высшего руко-

водства, которое склонно возмущаться: «Мы потратили кучу де-

нег на этих высокооплачиваемых преподавателей и напрасно по-

теряли столько времени

классах, чтобы эти ленивые бездельни-

ки-программисты могли научиться кодировать. Теперь мы хотим

увидеть реальную отдачу от этого «замечательного» средства, за

которое вы так агитировали!» Наверное, в такой наивности выс-

шего руководства нет ничего удивительного, поскольку они сами

практически не сталкивались с инструментальными средствами.

Однако, к сожалению, приходится наблюдать похожую реакцию

со

стороны многих менеджеров «безнадежных» проектов, гораздо

лучше разбирающихся в технических вопросах.

Если бы внедрение новой технологии не оказывало никакого

влияния на процессы, не требуя специального обучения и прак-

тики, то можно было бы принять решение, основываясь всего

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

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

любую проблему можно решить

помощью простого финансово-

го вливания, то существует тенденция к гораздо большему ис-

пользованию совершенно новых технологий в «безнадежных»

проектах, чем в нормальных. Ирония заключается в том, что но-

вое средство может оказаться последней каплей, переполнившей

чашу терпения. Таким образом, именно на средство будет возло-

жена ответственность за неудачу проекта.

Итак, нужно использовать

любые

средства, которые подходят

для «безнадежного» проекта, не обращая внимания на

то,

какими

их считает весь остальной мир: современными или устаревшими.

Но не следует

забывать,

что новые средства

«безнадежном» про-

екте окажут воздействие и на людей, и на процессы. Как сказал

150

лет назад Генри Дэвид Торо, люди становятся орудиями в ру-

ках собственных средств.

Особенности современных проектов 519

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

Во многих проектах наиболее серьезные проблемы носят

не столько технический характер, сколько политический,

социальный, культурный и человеческий.

Проекты, выполняющиеся в экстремальных условиях,

предъявляют особые требования к используемым методам,

средствам

технологиям.

v^ Основные понятия

«Безнадежный» проект, «достаточно хорошее» ПО, принцип

«ежедневной сборки».

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

Каким образом менеджер проекта может оценить вероят-

ность его успешного завершения?

Чем вызываются разногласия между участниками «безна-

дежных» проектов?

Какие технологии и инструментальные средства являются

наиболее предпочтительными в «безнадежных» проектах?

Какие меры следует предпринимать менеджеру проекта,

чтобы снизить текучесть кадров?

ДОПОЛНИТЕЛЬНАЯ ЛИТЕРАТУРА

Л.Ч'^Ч.*

*'^••Л•'•^г*•s^^

Бек

К.

Экстремальное программирование: Пер. с англ.

—

СПб.:

Питер, 2002.

Боггс

У.,

Боггс

М.

UML и Rational Rose: Пер. с англ. - М.: ЛО-

РИ, 2000.

Боэм

Б.У.

Инженерное проектирование программного обеспе-

чения : Пер. с англ.

—

М.: Радио и связь, 1985.

Брауде

Э.

Дж.

Технология разработки профаммного обеспече-

ния: Пер. с англ. - СПб: Питер, 2004.

Брукс Ф. Мифический человеко-месяц или как создаются

программные системы: Пер. с англ. - СПб.: Символ-Плюс, 1999.

Буч

Г.

Объектно-ориентированный анализ и проектирование с

примерами приложений на C++.

—

2-е изд.: Пер. с англ.

—

М.: Изда-

тельство Бином, СПб.: Невский диалект, 1999.

Буч

Г.

др.

Язык UML. Руководство пользователя /

Г.

Буч, Дж.

Рамбо, А. Джекобсон: Пер. с англ.

—

М.: ДМК, 2000.

Вендров

A.M.

CASE-технологии. Современные методы и сред-

ства проектирования информационных систем. - М.: Финансы и

статистика, 1998.

Вендров

A.M. Практикум по проектированию программного

обеспечения экономических информационных систем: Учеб. посо-

бие.

—

М.: Финансы и статистика, 2002.

10.

Вигерс

К. Разработка требований к программному обеспече-

нию:

Пер. с англ.

—

М.: Русская редакция, 2004.

11.

Гамма

Э.

др.

Приемы объектно-ориентированного проекти-

рования. Паттерны проектирования /

Э.

Гамма,

Р.

Хелм,

Р.

Джонсон,

Дж. Влиссидес: Пер. с англ.

—

СПб: Питер, 2001.

12.

Гома

X. UML. Проектирование систем реального времени,

распределенных и параллельных приложений: Пер. с англ.

—

М.:

ДМК, 2002.

13.

Йордон

Эд.

Путь камикадзе: Пер. с англ. - М.: ЛОРИ, 2001.

14.

Калашян А.Н., Каляное Г.Н. Структурные модели бизнеса:

DFD-технологии. - М.: Финансы и статистика,

2003.

15.

Каляное

Г.Н.

Консалтинг при автоматизации предприятий.

—

М.: СИНТЕГ, 1997. (Серия «Информатизация России на пороге XXI

века»)

16.

Коберн

А. Быстрая разработка программного обеспечения:

Пер.

с англ. - М.: ЛОРИ, 2002.