1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

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

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

«На днях я задал одной из проектных команд такой же воп­ рос», — ответил один из менеджеров. «Как вы думаете, что они от­ ветили?»

«Какой-нибудь высокопроизводительный компилятор C++? Ассемблер? Или мощное средство отладки для устранения мно­ жества ошибок в их коде (хи-хи-хи)?»

«Ничего подобного», - ответил менеджер, игнорируя иро­ нию. «Они ответили: электронная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живет в элект­ ронной почте. Уберите электронную почту, и проект умрет».

Эти события происходили до начала эры Internet и World Wide Web, когда сотня почтовых сообщений в день могла потрясти во­ ображение. Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 п, от­ ветом могло быть «World Wide Web»; по аналогии, «факс» в 1987 г, «ПК» в 1983 г., «онлайновый терминал» в 1976 г и «телефон на ра­ бочем столе» в 1964 г.

Очевидно, не следует ожидать, что команда «безнадежного» проекта сможет ограничиться только одним средством. Большин­ ство команд (даже в нормальных проектах) пользуется в своей повседневной работе самыми разнообразными средствами и тех­ нологиями. Правда, подчас количество средств становится черес-

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

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

С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своем распоряжении сотни различных средств, приобретавшихся в течение ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работа­ ют, те умственные усилия, которые необходимо затратить, чтобы запомнить, как ими пользоваться, а также дополнительные уси­ лия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести аналогию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаряжение им использовать. Существуют необходимые вещи (палатки, питьевая вода и т.д.); и, если маршрут не слишком сложный, можно взять с собой некоторые новомодные приспо­ собления, о которых написано в альпинистском журнале. Одна­ ко, если они собираются штурмовать Эверест, им не обойтись без помощи ослов или носильщиков из местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека.

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

подготовки своих документов, хотя, скорее всего, важен один и тот же компилятор C++. Одна из проблем, связанных с «безна­ дежными» проектами, заключается в том, что разработчики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется использовать никому не известный компилятор C++, который они переписали с университетского Web-сайта, то они считают это своим неотъемлемым правом). Но это не так: неотъемлемым правом обладает команда, и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуа­ циях, когда несовместимые средства могут привести к значитель­ ным разногласиям.

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

Менеджер проекта должен настаивать на достижении кон­ сенсуса; в самом деле, это может быть одним из критериев, ис­ пользуемых менеджером для выбора потенциальных участников команды. То же самое можно сказать относительно процессов, которые обсуждались ранее.

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

Электронная почта, ПО для групповой работы, средства Internet/Web, видеоконференции и т.д. Так же, как и в эпизоде с Microsoft, эти средства находятся в начале списка. Причина зак­ лючается в следующем: электронные средства общения и взаимо­ действия являются не только более эффективным средством коммуникации, чем записки и факсы, но они также способству­ ют координации и сотрудничеству Безразлично, какие именно средства использовать: Microsoft Outlook или Lotus Notes; важно только, чтобы вся команда работала в сети и хранила там общие проектные данные.

Средства прототипирования/быстрой разработки приложений (RAD). Почти все «безнадежные» проекты используют в той или иной степени прототипирование и пошаговую разработку; следо­ вательно, им необходимы соответствующие инструментальные средства. Сегодня не так просто отыскать популярную среду раз-

работки приложений, которая заявляла бы о себе иначе, чем сре­ да 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-+. Разумеется, мож-

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

CASE-средства для анализа и проектирования. Некоторые про­ ектные команды рассматривают CASE-средства как «костыли» для новичков, а другие считают их не менее важными, чем текс­ товые процессоры. Самая большая проблема, связанная с CASEсредствами, заключается в том, что они поддерживают (а иногда навязывают) определенную методологию, которую проектная команда не понимает и не желает использовать.

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

Но ситуация не всегда бывает черно-белой. Например, про­ ектная команда считает, что диаграммы потоков данных полез­ ны, но только как «неформальное» средство моделирования. Та­ ким образом, «гибкое» CASE-средство может рассматриваться как нужное и полезное, в то время как «жесткое» CASE-средство может быть отвергнуто.

Все это означает, что команда «безнадежного» проекта долж­ на в первую очередь нормально воспринимать те процессы и ме­ тоды, которым она собирается следовать. Кроме того, она долж­ на решить, каким из них надо подчиняться беспрекословно, а ка­ ким — следовать духу, но не букве закона. После принятия такого решения можно соответственно выбрать (или отвергнуть) сред­ ства и технологию. Таким же образом менеджер проекта может решить использовать какое-либо средство для усиления процес­ са, необходимость которого все понимают, но на практике следу­ ют ему достаточно небрежно; примеры таких процессов — конт­ роль версий и управление конфигурацией.

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

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

Ирония заключается в том, что большинство организаций в своих провалах винит технологию. Они приобретут дорогостоя­ щую библиотеку классов или поменяют свою старую технологию разработки ПО на объектно-ориентированную, исходя из пред­ положения, что объекты и повторное использование — это одно и то же. Обнаружив, что не добились сколько-нибудь ощутимых результатов, они будут винить во всем объектную технологию, библиотеку классов, поставщика и др. Между тем все процессы остались в точности такими же, какими были до внедрения новой технологии. Культура такой организации может быть выражена следующей фразой: «Только бездари пользуются чужим кодом; настоящие профаммисты, черт возьми, пишут свой!»

С точки зрения работы над «безнадежным» проектом мораль проста: если внедрение новых средств потребует серьезного из­ менения стандартных процессов команды, то это значительно увеличит риск и, возможно, будет способствовать провалу проек­ та. Необходимость обучения и освоения практического исполь­ зования новых средств создает дополнительные проблемы. Одна­ ко наиболее серьезной из них является изменение режима рабо­ ты, который целиком определяется процессом. Это трудно еде-

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

При работе над «безнадежными» проектами некоторые часто хватаются за новые средства и технологии для достижения более высокой продуктивности. При этом возникают два наиболее ве­ роятных риска — технология и обучение. Во многих случаях но­ вое средство даже не является законченным коммерческим про­ дуктом; обычно кто-нибудь из проектной команды переписывает из Интернета бета-версию. Или же данное средство невозможно интегрировать с любыми другими средствами, используемыми проектной командой; поставщик давал на этот счет неопределен­ ные обещания, однако в результате оказалось, что возможности экспорта-импорта изобилуют ошибками. Или, средство никем не поддерживается — оно разработано студентом из Ирака или (что еще хуже) создано в домашних условиях одним из разработчиков ПО, который не видит ничего странного в том, что банк разраба­ тывает свое собственное CASE-средство, а страховая компания — свою СУБД.

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

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

чется верить менеджеру проекта и разным другим руководите­ лям, поскольку они считают любое обучение потерей времени и отвлечением от работы над проектом. Более реалистичная оцен­ ка заключается в том, что на освоение средства потребуется час, день или неделя. Независимо от формы обучения (занятия в классе, чтение книги или просто «ифы» со средством), на это все равно потребуется какое-то время.

Однако в результате недельного обучения не получится опыт­ ного пользователя, в совершенстве владеющего средством. Это должно быть очевидным, однако нарушает планы высшего руко­ водства, которое склонно возмущаться: «Мы потратили кучу де­ нег на этих высокооплачиваемых преподавателей и напрасно по­ теряли столько времени в классах, чтобы эти ленивые бездельни­ ки-программисты могли научиться кодировать. Теперь мы хотим увидеть реальную отдачу от этого «замечательного» средства, за которое вы так агитировали!» Наверное, в такой наивности выс­ шего руководства нет ничего удивительного, поскольку они сами практически не сталкивались с инструментальными средствами. Однако, к сожалению, приходится наблюдать похожую реакцию со стороны многих менеджеров «безнадежных» проектов, гораздо лучше разбирающихся в технических вопросах.

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

Итак, нужно использовать любые средства, которые подходят для «безнадежного» проекта, не обращая внимания на то, какими их считает весь остальной мир: современными или устаревшими. Но не следует забывать, что новые средства в «безнадежном» про­ екте окажут воздействие и на людей, и на процессы. Как сказал 150 лет назад Генри Дэвид Торо, люди становятся орудиями в ру­ ках собственных средств.

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

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

2.Проекты, выполняющиеся в экстремальных условиях, предъявляют особые требования к используемым методам, средствам и технологиям.

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

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

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

1.Каким образом менеджер проекта может оценить вероят­ ность его успешного завершения?

2.Чем вызываются разногласия между участниками «безна­ дежных» проектов?

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

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

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

Л.Ч'^Ч.* *'^••Л•'•^г*•s^^

1.Бек К. Экстремальное программирование: Пер. с англ. — СПб.: Питер, 2002.

2.Боггс У., Боггс М. UML и Rational Rose: Пер. с англ. - М.: ЛО­ РИ, 2000.

3.Боэм Б.У. Инженерное проектирование программного обеспе­ чения : Пер. с англ. — М.: Радио и связь, 1985.

4.Брауде Э. Дж. Технология разработки профаммного обеспече­ ния: Пер. с англ. - СПб: Питер, 2004.

5.Брукс Ф. Мифический человеко-месяц или как создаются программные системы: Пер. с англ. - СПб.: Символ-Плюс, 1999.

6.Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. — 2-е изд.: Пер. с англ. — М.: Изда­ тельство Бином, СПб.: Невский диалект, 1999.

7.Буч Г. и др. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Джекобсон: Пер. с англ. — М.: ДМК, 2000.

8.Вендров A.M. CASE-технологии. Современные методы и сред­ ства проектирования информационных систем. - М.: Финансы и статистика, 1998.

9.Вендров A.M. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. посо­ бие. — М.: Финансы и статистика, 2002.

10.Вигерс К. Разработка требований к программному обеспече­ нию: Пер. с англ. — М.: Русская редакция, 2004.

11.Гамма Э. и др. Приемы объектно-ориентированного проекти­ рования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес: Пер. с англ. — СПб: Питер, 2001.

12.Гома X. UML. Проектирование систем реального времени, распределенных и параллельных приложений: Пер. с англ. — М.: ДМК, 2002.

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

14.Калашян А.Н., Каляное Г.Н. Структурные модели бизнеса: DFD-технологии. - М.: Финансы и статистика, 2003.

15.Каляное Г.Н. Консалтинг при автоматизации предприятий. — М.: СИНТЕГ, 1997. (Серия «Информатизация России на пороге XXI века»)

16.Коберн А. Быстрая разработка программного обеспечения: Пер. с англ. - М.: ЛОРИ, 2002.