Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

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

ПРЕДИСЛОВИЕ

Неуклонное повышение качества выпускаемых программных продуктов -

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

разработчики ПС для зарубежного заказчика (уровень требований которого всегда был

высок), но и организации, работающие для украинского заказчика или

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

объясняется обострением конкуренции разработчиков, а, кроме того, - повышением

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

качеству.

В последнее время происходит консолидация усилий передовых фирм-

разработчиков ПС по созданию национальной системы обеспечения качества. Об этом

свидетельствуют сообщения на сайтах Украинской Ассоциации Производителей

программного обеспечения (УАППО)

и Ассоциации «Информационные технологии

Украины»

, объединяющих такие известные компании, как «Миратех», «Софтлайн»,

«Мирасофт», «Профикс», «Укрсофт», «Софтсерв» и др. Нужно надеяться, что слияние

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

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

стандартам и способные конкурировать на международном рынке программной

продукции.

За рубежом существует множество фирм, осуществляющих регулярные обзоры

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

разных странах мира, например, NASSCOM (National Association of software and

service companies)

, Standish Group International, Inc.

, IBM's Consulting Group

. По

результатам этих исследований можно судить о том, произошли ли существенные

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

Для сравнения, обратимся к результатам исследований, проведенных Standish

Group в 1994 и в 2003 годах.

В 1994 году обзор 8380 программных проектов, разрабатываемых в

государственном и частном секторах США, показал, что

• 31% всех программных проектов были закрыты до их полного завершения;

• 53% успешно завершенных проектов в среднем на 18% превысили

начальную стоимость;

• из этих 53% проектов только 42% обеспечили в программных продуктах все

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

• только 9% проектов были завершены в срок и уложились в

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

Обзор 13522 проектов в 2003 году показал, что в 34% проектов состояние

разработок улучшилось на 16% по сравнению в 1994 годом. Однако 51% проектов все

еще сталкивались с проблемами. Из них:

Адрес УАППО в Интернет: http://www.uaswd.org.ua

Адрес «ИТ-Украины» в Интернет: http://www.itukraine.org.ua

Адрес NASSCOM в Интернет: http://www.nasscom.org

Адрес Standish Group в Интернет: http://www.standishgroup.com

Адрес в Интернет: http://www.ibm.com/annualreport/2004/ или http://www-1.ibm.com

Gibbs W. Software's Chronic Crisis // Scientific America, September 1994. - P. 86 - 95

• 15% проектов были закрыты до полного завершения;

• 46% успешно завершенных проектов превысили начальную стоимость в

среднем на 10-15%;

• из 85% завершенных проектов изначально требуемые свойства и функции

были обеспечены в программных продуктах только на 52%.

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

программной продукции все еще остается проблемой.

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

Украине, однако нет оснований считать, что состояние дел с отечественными

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

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

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

систем. Хотя за последние годы Госстандартом Украины

принято более 10 новых

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

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

методических рекомендаций по каждому стандарту, но и единого концептуального

взгляда на проблему качества ПС и пути ее решения. Не определена сама парадигма

качества ПС.

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

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

треугольника «продолжительность – стоимость – цели проекта», в течение последних

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

ПС, менеджеры проектов, а также заказчики и потребители, приобретающие

программные продукты невысокого качества.

Тайна нестабильности проектов, недолговечности и низкого качества

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

коренятся в неспособности эффективно управлять разработкой ПС. Даже самые

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

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

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

так как нет объективного базиса для его достижения и оценивания.

Изменить ситуацию можно только в результате концентрации усилий на

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

инженерии и инженерии качества ПС.

Нужно заметить, что подходы к усовершенствованию процессов создания ПС

разрабатывались в Украине еще в 80-е годы прошлого столетия. Направление

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

технического прогресса стран-членов СЭВ до 2000 года. В ней программная

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

назначения и была сформулирована проблема «Развитие технологии разработки и

промышленного производства программных средств вычислительной техники».

Правильнее было бы дать украинское наименование организации –

«Держспоживстандарт України»

В рамках этой программы в СКТБ ПО Института кибернетики АН УССР им.

В.М.Глушкова

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

программных изделий (ТПР ПИ), - этапа, предшествующего непосредственной

разработке ПС, и предназначенного для построения базового процесса программной

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

проекта. Отделом технологии программирования под руководством Е.М. Лаврищевой

были разработаны серии документов ТПР (стандартов предприятия)

, в которых

регламентировались процессы ТПР и собственно разработки ПС в СКТБ ПО и

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

документов – карт технологических линий и процессов, технологических маршрутов,

форм и т.д. С развалом СССР эти работы были приостановлены, их результаты

остались не востребованы, а «процессный подход» забыт.

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

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

современной парадигмы качества ПС. Его отражение можно найти, например, во

множестве международных стандартов ISO, а также гармонизованных с ними

стандартов стран СНГ, включая Украину. Методологические основы применения

процессо-ориентированного подхода в разработке ПС в Украине развиваются в

Институте программных систем НАН Украины (ИПС НАНУ) в рамках выполняемых

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

Авторы книги (сотрудники ИПС НАНУ) предлагают читателю материал,

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

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

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

знаний на практике.

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

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

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

инженерии качества. В нем, в частности, нашли отражение идеи известнейших

специалистов в области качества ПС – Н. Фентона, У. Хамфри, М.Полка, В.В. Липаева

и многих-многих других, опубликованные в открытой печати и Интернет.

Основная цель написания этой книги – показать место инженерии качества ПС

среди множества (более сорока) процессов программной инженерии, представленных

в базовом международном стандарте ISO/IEC 12207 «Процессы жизненного цикла

программных средств». Поскольку этот стандарт определяет только то, ЧТО (какие

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

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

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

специализирующимися в области программной инженерии – SEI (США), Microsoft,

ISO, IEEE, NIST и другими. Наиболее известные методы (например, метод измерений

в 1992 году на базе СКТБ ПО создан Институт программных систем (ИПС) НАН

Украины.

Е.М.Лаврищева. Основы технологической подготовки разработки прикладных

программ систем обработки данных // Препринт / АН УССР, Ин-т кибернетики им.

В.М.Глушкова; 87-5. – Киев, 1987. – 30с.

GQM или метод инспекции) излагаются достаточно подробно, «по шагам», и

сопровождаются множеством форм (шаблонов) и метрик, применяемых при

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

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

Перед Вами второе переработанное и дополненное издание книги «Основы

инженерии качества программных систем». Можно утверждать, что интерес к

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

программных систем существенно возрос со времени ее первого издания (в 2002 году).

Книга состоит из 12 глав.

В первой главе «Парадигма качества в программной инженерии» определено

множество взаимосвязанных понятий в области инженерии качества ПС: процессы

ЖЦ, модели ЖЦ, проект, измерение, риск, качество и другие. Акцент сделан на

процессо-ориентированном подходе к разработке ПС. Указаны процессы, которые

должны институциализироваться в организации и интегрироваться в проекты ПС для

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

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

Сформулированы основные положения концепции инженерии качества ПС. В

приложении 1 к главе дан краткий обзор моделей ЖЦ ПС.

Во второй главе «Инженерия качества. Ядро профессиональных знаний»

представлены основные элементы ядра профессиональных знаний в областях

программной инженерии (SWEBOK) и управления проектами (PMBOK) и на их

основе синтезировано множество элементов, составляющих, по мнению авторов, ядро

знаний в области инженерии качества ПС.

Третья глава «Модели и метрики качества» посвящена метрикам – основе

измерений продуктов, процессов и ресурсов в проекте. В ней приведена

классификация мер и метрик качества. Дан краткий обзор существующих моделей

качества, включая графические. Представлена парадигма «встраивания» качества в

программные продукты QFD (Quality Function Deployment). В помощь менеджерам

проектов в приложении к главе (приложение 2) приведены примеры метрик для

некоторых характеристик качества ПС.

В четвертой главе «Измерения в программной инженерии» рассмотрен

основополагающий процесс для инженерии качества - процесс измерения. Описаны

его цели, задачи и объекты, а также место в архитектуре процессов ЖЦ. В центре

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

методологии «цель – вопрос – мера» GQM (Goal - Question - Metric).

Пятая глава «Контроль и гарантия качества» посвящена процессам и методам

обеспечения качества. В ней разграничены понятия обеспечения гарантии качества

(SQA, Software Quality Assurance) и управления качеством (Quality Management),

определено место одноименных процессов в архитектуре процессов ЖЦ. Введено

понятие профиля процесса, связывающего воедино определение процесса, план его

выполнения, метрики, а также требования (стандарты) для процесса и его рабочих

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

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

профиля. Очерчен примерный круг знаний, которыми (по мнению авторов) должны

обладать инженеры по качеству (или SQA-менеджеры). Рассмотрены методы и

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

(добычи данных) и байесовских сетей). В помощь менеджерам в приложении 3

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

инженерии качества и дана краткая характеристика проектов ISO/IEC по этому

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

качества в продуктах ведущих поставщиков – Oracle (Oracle Designer’2000), Microsoft

(Microsoft Visual Studio 2005), Rational (Rational Suite), Borland (Borland Suite)

В шестой главе «Процессы и методы проверки» рассмотрен другой очень

важный аспект обеспечения качества – его проверка на стадиях ЖЦ. Процедуры

проверки качества сосредоточены в процессах верификации, валидации, совместного

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

из этих процессов. Подробно описаны задачи верификации и валидации рабочих

продуктов ПС на стадиях ЖЦ. Дана классификация и краткий обзор методов,

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

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

обзоры, сквозной контроль, аудиторская проверка). Подробно рассмотрен метод

инспекции – наиболее формализованный и широко применяемый метод проверки

рабочих продуктов ПС, а в приложении 5 приведены примеры вопросов для ее

проведения.

Седьмая глава «Тестирование программных систем» посвящена тестированию.

В ней предложен подход к тестированию с учетом риска отказов программного

продукта и риска срыва проекта. Тестирование рассматривается как интегрированный

процесс, действующий на всех стадиях ЖЦ ПС. В нем собраны воедино все действия

группы тестирования, «размытые» по другим процессам ЖЦ, начиная с процесса

выявления требований и кончая процессом инсталляции ПС. Такой подход не только

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

правильного определения трудоемкости тестирования. В главе представлен также

обзор методов тестирования.

Восьмая, девятая и десятая главы охватывают вопросы оценивания размера,

стоимости и риска разработки ПС. Хотя они, казалось бы, не имеют

непосредственного отношения к обеспечению качества, однако тесно связаны с

управлением проектом ПС. Проект должен обеспечивать разработку ПС

определенного размера (здесь размер выступает мерилом функциональности ПС),

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

риском для того же размера, качества, сроков и финансирования.

Восьмая глава «Методы оценки размера программной системы» посвящена

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

методология анализа показателей функциональности FPA (Function Points Analysis),

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

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

используя которые можно оценить (прогнозировать) размер ПС не подсчитывая число

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

разработки), а с самого начала – анализируя предметную область, функциональные

требования и интервьюируя пользователей будущей ПС. Размер определяется в

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

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

тестирования.

В девятой главе «Оценка затрат на разработку программных систем»

представлены модели и методы расчета трудоемкости и затрат на разработку ПС.

Кратко описаны методы Дельфи, SLIM, ANGEL, а также одна из самых известных

моделей - трехуровневая модель COCOMO II и ее расширения. В основе расчетных

формул модели – размер ПС, а параметрами настройки служат факторы,

учитывающие особенности самого процесса разработки.

В десятой главе «Управление риском проектов» рассмотрены основные понятия

и концепции парадигмы управления риском проектов, предложенной SEI (Software

Engineering Institute) - одним из ведущих институтов США в области программной

инженерии. В приложении к главе (приложение 6) содержится вопросник,

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

оценки риска отечественных проектов.

Одиннадцатая глава «Методологии повышения качества в современной

парадигме» посвящена современным подходам к управлению качеством ПС

(статистический контроль качества, всеобщее управление качеством TQM, лестницы

восхождения к качеству, MSF, RUP, а также Agile-подходы XP, SCRUM, DSDM и др.).

Дана их краткая характеристика и сравнительный анализ.

В двенадцатой главе «Подходы к оценке качества программных систем»

рассмотрены вопросы оценки качества. Здесь с понятием качество связываются не

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

организации-разработчика ПС, и мощность процессов ЖЦ. В главе кратко описана

широко известная модель зрелости - CMM (Capability Maturity Model), основные

процедуры оценивания мощности процессов ЖЦ, регламентируемые стандартом

ISO/IEC 15504, а также методы оценки качества продуктов и сертификации

программных продуктов и систем качества.

Книга предназначена для руководителей организаций-разработчиков

программных систем, менеджеров проектов и инженеров по качеству. Она может

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

содержит множество ссылок на литературные источники (более 200 ссылок) и адреса

сайтов в Интернете, где можно получить более детальную информацию по

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

курсов и аспирантами по специальности 01.05.03 – Математическое и программное

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

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

области инженерии качества.

Авторы будут благодарны читателям за любые отклики на книгу. Просим

направлять их по адресу Института программных систем

03187, Украина, г. Киев, просп. Академика В.М. Глушкова, 40; ИПС НАНУ

телефон (044) 526 55 07; факс 526 62 63;

e-mail: iss@isofts.kiev.ua (адрес ИПС НАН Украины)

Глава 1. ПАРАДИГМА КАЧЕСТВА В ПРОГРАММНОЙ

ИНЖЕНЕРИИ

1.1. Основные понятия в области качества

1.1.1. Инфраструктура разработки

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

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

ключаемых договоров на разработку программных систем (ПС).

Программная система - группа интегрированных программных средств,

поддерживающих определенный деловой процесс потребителя (или его часть) и

использующих общие хранилища данных. Пример ПС - группа программных при-

ложений, составляющих автоматизированное рабочее место (АРМ) специалиста в

определенной предметной области.

Термин программное обеспечение (ПО) используется применительно к сово-

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

эксплуатации в составе системы (системы автоматизации, информационные систе-

мы и др.). Примеры программных средств: шрифт, драйвер, программное приложе-

ние. Мы говорим «программное обеспечение системы», если хотим подчеркнуть

его принадлежность к системе (включающей также техническое, организационное

и другие виды обеспечения системы).

Основа качественной разработки программных систем – рациональная ин-

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

Желание компаний получить наивысшую отдачу от инвестиций в создание

ПС побуждает их постоянно возвращаться к вопросу о текущей практике разработ-

ки. Разработка ПС как вид бизнеса прошла за последние 30 лет тернистый путь от

«закрученных» кодов на Коболе, Фортране и ПЛ/1, создаваемых исключительно в

отделах Вычислительно-информационных центров, до приложений, проектируе-

мых, моделируемых и разрабатываемых профессионалами в области информаци-

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

лями.

К сожалению, разработчики ПС нечасто завершают программные проекты

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

продуктах требования спецификаций заказчика. Последствия поставки плохо раз-

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

териальные и финансовые потери, но и падение престижа. Эти проблемы, в свою

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

разработчика программных продуктов.

И практикующие специалисты в области программных систем, и пользовате-

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

который:

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

зователей или

• недостаточно надежен, гибок, эффективен и плохо сопровождается или

• является дорогим и слишком долго разрабатываемым.

Глава 1

Причины плохого состояния практики разработки ПС заключаются в том,

что организация-разработчик страдает синдромом «сапожник без сапог» из-за от-

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

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

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

того, из-за неадекватной инфраструктуры, сообществу их потенциальных пользова-

телей не отводится ведущая роль в определении методологий эксплуатации ПС,

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

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

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

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

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

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

чая списанием. Многие организации-разработчики продолжают использовать тот

же ограниченный и не интегрированный набор инструментальных средств и мето-

дологий для построения ПС, что и десятилетие тому назад. Эта практика продолжа-

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

ных информационных технологиях и повышение их требований к разрабатывае-

мым по договорам программным продуктам. Руководство организаций-

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

вает с созданием эффективной инфраструктуры, способной обеспечить специали-

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

работку высококачественных ПС.

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

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

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

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

программных продуктов.

В данном изложении проект – это ограниченная временными рамками дея-

тельность, цель которой состоит в создании уникального программного продукта;

процесс программной инженерии – это множество логически связанных видов

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

дуктов (прикладных программных систем).

Совместное использование ресурсов инфраструктуры позволяет организации

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

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

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

на рисунке 1.1.

Нет однозначного ответа на вопрос, какова наиболее рациональная инфра-

структура разработки (ИР) программных систем. Варианты ее построения зависят

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

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

между различными специалистами в проекте, и уровни их ответственности). В таб-

лице 1.1 описано множество компонентов инфраструктуры, представленных на ри-

сунке 1.1, а в таблице 1.2 – объяснены роли специалистов в организационных

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

18 Глава 1

средственное отношение к обеспечению качества разработки. В небольших проек-

тах или организациях допускается совмещение нескольких ролей одним лицом.

Техника и коммуникации

Общесистемное ПО и

инструменты

Информационные

ресурсы и стандарты

разработки ПО

Инфраструктура

программной

инженерии

Обучение методам и

технологиям

Обмен положительным и

отрицательным опытом

Накопление и

распространение

положительного опыта

Стандарты межпроектного

взаимодействия

Базовый процесс программной инженерии

Уровень проекта разработки системы

Технико-технологический

аспект

Кадровый аспект

Группа

инженерии

процесса

(технол.

служба)

Независимая

группа обес-

печения

гарантии

качества

Независимая

группа

верификации

и валидаци

Уровень организации

Межпроектная

программная поддержка

Группа

технико-

технологи-

ческой

поддержки

Программисты

Руководитель

проекта системы

Менеджер

проекта

локальной

компью-

терной

сети (ЛКС)

Менеджеры

проекта ПО

Проектировщики

Группа

качества

проекта

Група вери-

фикации и

валидации

проекта

Группа управления

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

Группа проекта ЛКС

Систем-

ные ана-

литики

Группа

защиты

инфор-

мации

Группа

поддерж-

ки Заказ-

чика

Группа

сопровож-

дения

Рис. 1.1. Инфраструктура разработки программных систем

Инфраструктура образует фундамент для осуществления процесса программ-

ной инженерии в организации.

Глава 1

Таблица 1.1. Компоненты инфраструктуры разработки ПС

Технико-технологи-

ческий аспект ИР

Описание возможностей

Техника и коммуни-

кации

• Компьютеры пользователей, файловые серверы

• Локальные компьютерные сети (ЛКС)

• Глобальная компьютерная сеть (ГКС)

• Электронная почта (e-mail)

• Техника для тестирования (тестеры)

• Офисная техника (сканеры, принтеры, проекторы и т.п.)

• Другие составляющие комплекса технических средств (КТС)

Общесистемное ПО

(ОПО) и инструменты

•Клиент/Серверные технологии

• Операционные системы

• Офисные системы (включая ридеры/райтеры)

• Системы документооборота

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

тели и т.п.)

• Средства защиты информации (антивирусные средства)

• CASE-инструменты, системы программирования (4GL)

• СУБД

• Графические инструменты

Информационные

ресурсы и стандарты

разработки

• Методологии разработки (в частности, поддержанные CASE-

средствами)

• Инструменты управления проектами, конфигурациями

• Системы поддержки использования ресурсов Интернет (вы-

грузка/загрузка информации)

• Нормативные документы, касающиеся технических, про-

граммных, коммуникационных средств, данных и защиты ин-

формации

• Нормативные документы (стандарты) оформления материалов

• Методические материалы, шаблоны и заготовки документов

Межпроектная про-

граммная поддержка

• Разработанные программы (модули), признанные пригодными

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

ные под контроль конфигурации

Кадровый аспект Описание возможностей

Обучение методам и

технологиям

• Возможности организации по обучению специалистов мето-

дам и приемам разработки ПО

• Возможности изучения (освоения) специалистами технико-

технологических компонентов инфраструктуры (включая

CASE-инструменты)

Обмен положитель-

ным и отрицательным

опытом

• Культура «открытого» восприятия/передачи приобретенного

опыта, знаний, характерных ошибок. Содействие распростра-

нению положительного опыта. Не укрывательство собствен-

ных ошибок и не перекладывание ответственности за них.

Желание обучаться/обучать