Технология и инструментальные

СРЕДСТВА «БЕЗНАДЕЖНЫХ» ПРОЕКТОВ

 

Летом 1992 г. Эдварду Йордону довелось обедать с группой менеджеров среднего уровня Microsoft. Во время беседы он спро­сил, является ли для них обычным делом использование таких методологий, как структурный анализ или объектно-ориентиро­ванное проектирование. Ответы были примерно следующими: «иногда», «вроде бы да», «от случая к случаю» и «а что это такое?». Когда же он поинтересовался относительно использования 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 J++, то это явно глупо, хотя и допустимо с точки зрения техноло­гии.

Средства управления конфигурацией/управления версиями. Не­которые полагают, что они должны быть на первом месте в спис­ке. Очевидно, использование средств управления конфигурацией может принести больше пользы, если они будут интегрированы со средствами разработки приложений. Например, SourceSafe от Microsoft может и не быть самым лучшим средством управления версиями ПО, однако тот факт, что оно тесно интегрировано с Visual Basic, является весомым аргументом в его пользу. Анало­гично, многие другие средства разработки приложений интегри­рованы с PVCS или другими подобными средствами управления конфигурацией.

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

Средства управления проектом (оценка, планирование, PERT/GANTT и т.д.). Обычно их считают средствами менеджера проекта. К этой же категории следует отнести такие средства оценки, как ESTIMACS (Computer Associates), CHECKPOINT (Software Productivity Research) и SLIM (Quantitative Software Management). Они, я считаю, являются важными, поскольку позволяют в ходе выполнения проекта динамически пересматри­вать планы и сроки.

Наборы повторно используемых компонентов. Если проектная команда знакома с концепцией повторного использования ПО и рассматривает ее как стратегическое оружие, позволяющее дос­тичь высокого уровня продуктивности разработки, тЬ набор пов­торно используемых компонентов должен быть в списке тех средств, которые необходимо использовать. Это может быть на­бор компонентов VBX для Visual Basic, компоненты Java компа­нии Sun или библиотека классов 8ТЪдля C++. Разумеется, можно использовать и компоненты, разработанные другими проект­ными командами в организации. Выбор их обычно зависит от ис­пользуемого языка программирования, и это еще одна проблема, нуждающаяся в выработке единого подхода со стороны проект­ной команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

 

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

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

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

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

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

 

 

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

 

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.

17. Кватрани Т. Визуальное моделирование с помощью Rational Rose 2002 и UML: Пер. с англ. - М.: Вильяме, 2003.

18. Коберн А. Современные методы описания функциональных требований к системам: Пер. с англ. — М.: ЛОРИ, 2002.

19. Конноли Т., Бегг К. Базы данных: проектирование, реализация и сопровождение. Теория и практика. — Зте изд.: Пер. с англ. — М.: Вильяме, 2003.

20. Крачтен Ф. Введение в Rational Unified Process: Пер. с англ. -М.: Вильяме, 2002.

21. Ларман К. Применение UML и шаблонов проектирования. — 2-е изд.: Пер. с англ. — М.: Вильяме, 2002.

22. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход: Пер. с англ. — М.: Вильяме, 2002.

23. Липаев В.В. Документирование и управление конфигурацией программных средств. Методы и стандарты. — М.: СИНТЕГ, 1998.

24. Липаев В.В. Системное проектирование сложных програм­мных средств для информационных систем. — 2-е изд. — М.: СИН­ТЕГ, 2002.

25. Маклаков СВ. BPwin и ERwin. CASE-средства разработки ин­формационных систем. — М.: Диалог-МИФИ, 1999.

26. Маклаков СВ. Моделирование бизнес процессов с BPwin 4.O. - М.: Диалог-МИФИ, 2002.

27. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. - М.: МетаТехнология, 1993.

28. Мацяшек Л. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML: Пер. с англ. — М.: Вильяме, 2002.

29. Мюллер Р. Базы данных и UML. Проектирование: Пер. с англ. - М.: ЛОРИ, 2002.

30. Нейбург Э. Дж., Максимчук Р.А. Проектирование баз данных с помощью UML: Пер. с англ. — М.: Вильяме, 2002.

31. Одинцов И. Профессиональное программирование. Систем­ный подход. — СПб.: БХВ-Петербург, 2002.

32. Орлов С.А. Технологии разработки программного обеспече­ния. - СПб.: Питер, 2002.

33. Оценка и аттестация зрелости процессов создания и сопро­вождения программных средств и информационных систем (ISO/IEC TR 15504-СММ): Пер. с англ. А.С. Агапова и др. - М.: Книга и бизнес, 2001.

34. Палмер С.Р., Фелсинг Дж.М. Практическое руководство по функционально-ориентированной разработке ПО: Пер. с англ. — М.: Вильяме, 2002.

35. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD. - 2-е изд.: Пер. с англ. - М.: Русская редакция, 2002.

36. Рамбо Дж. и др. UML. Специальный справочник / Дж. Рамбо, Г. Буч, А. Якобсон: Пер. с англ. — СПб: Питер, 2002.

37. Розенберг Д., Скотт К. Применение объектно-ориентирован­ного моделирования с использованием UML и анализ прецедентов: Пер. с англ. - М.: ДМК, 2002.

38. Ройс У. Управление проектами по созданию программного обеспечения: Пер. с англ. — М.: ЛОРИ, 2002.

39. Соммервилл И. Инженерия программного обеспечения. — 6-е изд.: Пер. с англ. - М.: Вильяме, 2002.

40. Фатрелл Р. и др. Управление программными проектами: дос­тижение оптимального качества при минимуме затрат / Р. Фатрелл, Д. Шафер, Л. Шафер: Пер. с англ. - М.: Вильяме, 2003.

41. Фаулер М., Скотт К. UML в кратком изложении. Примене­ние стандартного языка объектного моделирования: Пер. с англ. -М.: Мир, 1999.

42. Черемных С.В. и др. Структурный анализ систем: IDEF-техно-логии / С.В.Черемных, И.О. Семенов, B.C. Ручкин. - М.: Финансы и статистика, 2001.

43. Черемных СВ. и др. Моделирование и анализ систем. IDEF-технологии: практикум/С.В.Черемных, И.О. Семенов, B.C. Ручкин. - М.: Финансы и статистика, 2002.

44. Элиенс А. Принципы объектно-ориентированной разработки программ. - 2-е изд.: Пер. с англ. - М.: Вильяме, 2002.

45. Якобсон А. и др. Унифицированный процесс разработки прог­раммного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо: Пер. с англ. - СПб.: Питер, 2002.

 

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

А

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

Агрегация (форма ассоциации) - связь между целым (составным) объектом и его частями (компонентными объектами).

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

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

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

Бизнес-модель — формализованное описание процессов, связан­ных с ресурсами и отражающих существующую или предполагаемую деятельность предприятия.

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

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

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

Действующее лицо (actor) — роль, которую пользователь играет по отношению к системе.

Ж-3

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

Зрелость процессов (software process maturity) - степень управляе­мости, контролируемости и эффективности процессов создания ПО.

И

Иерархия - ранжированная или упорядоченная система абстрак­ций, расположение их по уровням.

Индивидуальность - набор свойств объекта, отличающих его от всех других объектов.

Инкапсуляция — физическая локализация свойств и поведения в рамках единственной абстракции (рассматриваемой как «черный ящик»), скрывающая их реализацию за общедоступным интерфей­сом.

Инструментальное средство (CASE-средство) - программное средство, поддерживающее процессы жизненного цикла ПО, опре­деленные в стандарте ISO/IEC 12207:1995.

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

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

К

Качество ПО — совокупность свойств, которые характеризуют способность ПО удовлетворять заданным требованиям.

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

Класс принадлежности — характеристика обязательности участия экземпляра сущности в связи.

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

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

М

Моделирование - процесс создания формализованного описа­ния системы в виде совокупности моделей.

Модель ПО - формализованное описание системы ПО на опре­деленном уровне абстракции.

Модель ЖЦ ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяже­нии ЖЦ.

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

Мощность связи — максимальное число экземпляров сущности, которое может быть связано с одним экземпляром данной сущности.

Н

Накопитель данных — абстрактное устройство для хранения ин­формации.

Наследование — построение новых классов на основе существу­ющих с возможностью добавления или переопределения свойств (атрибутов) и поведения (операций).

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

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

О

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

Объект — осязаемая сущность (tangible entity) - предмет или яв­ление, имеющие четко определяемое поведение.

Объектная декомпозиция - описание структуры системы в тер­минах объектов и связей между ними, а поведения системы — в тер­минах обмена сообщениями между объектами.

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

П

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

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

Поток данных - информация, передаваемая через некоторое со­единение от источника к приемнику.

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

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

Проект — временное предприятие, осуществляемое с целью соз­дания уникального продукта или услуги.

Проект ПО — совокупность спецификаций программного обеспе­чения (включающих модели и проектную документацию), обеспечи­вающих создание ПО в конкретной программно-технической среде.

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

Прототип — действующий программный компонент, реализую­щий отдельные функции и внешние интерфейсы разрабатываемого ПО.

Процесс (ЖЦ ПО) — совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные.

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

Процесс (на диаграмме потоков данных) — преобразование вход­ных потоков данных в выходные в соответствии с определенным ал­горитмом.

Р

Рабочий продукт — информационная или материальная сущ­ность, которая создается, модифицируется или используется в неко­торой технологической операции (модель, документ, код, тест и т.п.). Рабочий продукт определяет область ответственности роли и являет­ся объектом управления конфигурацией.

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

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

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

Руководство - практическое руководство по выполнению одной операции или совокупности технологических операций. Руковод­ства включают методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов.

С

Связь - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области (в модели «сущ­ность-связь»).

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

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

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

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

Степень связи — количество сущностей, участвующих в связи.

Стереотип (UML) — новый тип элемента модели, который опре­деляется на основе уже существующего элемента. Стереотипы рас­ширяют нотацию модели, могут применяться к любым элементам модели и представляются в виде текстовой метки или пиктограммы.

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

Т

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

Технологический процесс — совокупность взаимосвязанных тех­нологических операций.

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

Трассировка требований — установка и отслеживание связей тре­бований с другими требованиями или проектными решениями

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

У

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

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

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

Ф-Я

Функциональная декомпозиция — описание структуры системы в терминах иерархии ее функций и передачи информации между от­дельными функциональными элементами.

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

Язык моделирования — совокупность элементов модели — фунда­ментальных концепций моделирования и их семантики; нотации (системы обозначений) — визуального представления элементов мо­делирования; руководства по использованию — правил применения элементов в рамках построения тех или иных типов моделей ПО.