/
Автор: Гусятников В.Н. Безруков А.И.
Теги: программные средства стандартизация продукции, процессов, мер, весов и времени стандарты технические требования нормы и правила рекомендации программирование программное обеспечение стандартизация учебное пособие компьютерные технологии
ISBN: 978-5-279-03450-5
Год: 2010
Текст
"$
УДК 004.4:006(075.8)
ББК 32.973.2-018ц.я73
Г96
РЕЦЕНЗЕНТЫ:
Кафедра математической экономики
Саратовского государственного университета
(заведующий кафедрой – С.И. Дудов,
доктор физико-математических наук, профессор);
Ю.В. Клинаев,
доктор физико-математических наук, профессор
Г96
Гусятников В.Н.
Стандартизация и разработка программных систем: учеб.
пособие / В.Н. Гусятников, А.И. Безруков. – М.: Финансы и
статистика, 2010. – 288 с.: ил.
ISBN 978-5-279-03450-5
Рассматриваются актуальные вопросы совместного использования российских и международных стандартов при разработке программного обеспечения с учетом последних изменений в отечественном законодательстве и
системе национальных и международных стандартов. Обсуждаются современные концепции и методологии организации и управления процессом
разработки, формирования комплекта программной документации и оценки качества программного продукта. Даются практические рекомендации и
примеры реализации излагаемых положений.
Для студентов специальностей и направлений «Прикладная информатика (по областям)», «Программное обеспечение вычислительной техники и
автоматизированных систем», «Математическое обеспечение и администрирование информационных систем» и др., а также для аспирантов и специалистов в области разработки программного обеспечения.
Ã
2404000000 005
119 2009
010(01) 2010
ISBN 978-5-279-03450-5
УДК 004.4:006(075.8)
ББК 32.973.2-018ц.я73
© Гусятников В.Н., Безруков А.И., 2010
© Издательство «Финансы и статистика, 2010
ÎÃËÀÂËÅÍÈÅ
Предисловие ......................................................................................... 7
à ë à â à 1. ÎÑÍÎÂÛ ÑÒÀÍÄÀÐÒÈÇÀÖÈÈ
È ÑÅÐÒÈÔÈÊÀÖÈÈ ............................................................. 9
1.1. Основные понятия стандартизации ................................ 9
1.1.1. Что такое стандарт ................................................. 9
1.1.2. Задачи стандартизации ........................................ 11
1.1.3. Виды стандартов ................................................... 13
1.1.4. Изменение целей и методов стандартизации
при развитии рыночных отношений .................. 14
1.1.5. Федеральный закон «О техническом
регулировании» ..................................................... 15
1.2. Сертификация ................................................................. 18
1.2.1. Сущность сертификации ..................................... 18
1.2.2 Требования к безопасности и качеству ............. 19
1.2.3. Обязательная и добровольная
сертификация ....................................................... 20
1.2.4. Органы по сертификации программного
обеспечения в России .......................................... 23
1.3. Метрология ...................................................................... 24
1.3.1. Обеспечение единства измерений ...................... 26
1.3.2. Измерение неколичественных
характеристик. Шкалы и метрики ...................... 31
1.4. Обеспечение единства терминологии .......................... 38
1.5. Обеспечение специализации производства
и взаимозаменяемости ................................................... 41
1.5.1. Унификация .......................................................... 42
1.5.2. Модульный принцип программирования .......... 45
1.5.3. Унификация интерфейсов ................................... 48
1.6. Использование стандартов для оценки качества
программного продукта ................................................. 54
1.6.1. Внешнее и внутреннее качество
программы ............................................................ 55
1.6.2. Характеристики качества программного
обеспечения .......................................................... 57
1.7. Органы стандартизации в области программного
обеспечения .................................................................... 63
Контрольные вопросы ............................................................ 64
!
à ë à â à 2. ÎÐÃÀÍÈÇÀÖÈß ÐÀÇÐÀÁÎÒÊÈ
ÏÐÎÃÐÀÌÌÍÛÕ ÑÈÑÒÅÌ ................................................. 66
2.1. История развития методологий разработки
сложных систем .............................................................. 66
2.2. Жизненный цикл программной системы ..................... 68
2.3. Международные и национальные стандарты
методологий разработки программных систем ............ 70
2.3.1. Процессы жизненного цикла систем.
Стандарт ГОСТ Р ИСО/МЭК 15288-2005 ......... 80
2.3.2. Процессы жизненного цикла программных
средств. Стандарт ГОСТ Р ИСО/МЭК
12207-99 ................................................................. 81
2.4. Модели жизненного цикла программных систем ....... 83
2.4.1. Каскадная (водопадная) модель ......................... 84
2.4.2. Поэтапная модель с промежуточным
контролем ............................................................. 88
2.4.3. Спиральная модель .............................................. 89
2.4.4. Инкрементная модель ......................................... 91
2.5. Документальное сопровождение этапов жизненного
цикла программной системы ......................................... 92
2.6. Фирменные (корпоративные) технологии
разработки программной системы ................................ 98
2.7. Методы «быстрой» разработки программной
системы .......................................................................... 106
2.8. Выбор и адаптация методологии разработки ............ 110
Контрольные вопросы .......................................................... 114
à ë à â à 3. ÍÀ×ÀËÜÍÛÉ ÝÒÀÏ ÐÀÇÐÀÁÎÒÊÈ.
ÏËÀÍÈÐÎÂÀÍÈÅ È ÎÖÅÍÊÀ ÏÐÎÅÊÒÀ ........................ 116
3.1. Проблема формирования системы требований
к большому программному продукту ......................... 117
3.1.1. Формирование первичных требований ............ 118
3.1.2. Анализ первичных требований ......................... 121
3.1.3. Методы углубленного анализа требований ..... 125
3.2. Согласование сложности разработки
и возможностей исполнителя ...................................... 130
3.3. Планирование реализации проекта ............................ 134
3.3.1. Прогнозирование и планирование ................... 135
3.3.2. Классификация методов планирования ........... 136
3.4. Методы систематизации опыта разработки ............... 144
3.4.1. Привычка подводить итоги ............................... 144
3.4.2. Оценка трудоемкости и времени,
необходимого на реализацию проекта ............. 145
3.4.3. Как относиться к своим ошибкам ................... 147
3.4.4. База данных самонаблюдений .......................... 148
3.4.5. Базовая линия устойчивости процесса ............ 149
"
3.5. Метрики сложности ..................................................... 150
3.5.1. Простейшие объемные метрики ....................... 151
3.5.2. Метод функциональных точек .......................... 154
3.5.3. Учет сложности требований
к программному продукту ................................. 158
Контрольные вопросы .......................................................... 160
à ë à â à 4. ÐÀÇÐÀÁÎÒÊÀ ÏÐÎÃÐÀÌÌÍÎÃÎ ÊÎÄÀ
È ÒÅÑÒÈÐÎÂÀÍÈÅ ÑËÎÆÍÛÕ ÏÐÎÃÐÀÌÌ .................. 162
4.1. Архитектура программных систем .............................. 162
4.2. Методики программирования ..................................... 165
4.2.1. Восходящее и нисходящее проектирование
программ ............................................................. 166
4.2.2. Различные подходы к программированию ...... 166
4.2.3. Правила структурного программирования ...... 168
4.2.4. Документирование кода .................................... 169
4.3. Средства разработки ..................................................... 170
4.3.1. Проблема выбора средств разработки .............. 170
4.3.2. История развития средств разработки ПС ...... 171
4.4. Тестирование и отладка программ ............................. 175
4.4.1. Основные понятия ............................................. 175
4.4.2. Виды тестирования ............................................ 179
4.4.3. Тестирование надежности ................................. 182
4.4.4. Организация процесса тестирования ............... 195
4.5. Финишные этапы разработки программных
систем ............................................................................ 204
Контрольные вопросы .......................................................... 210
à ë à â à 5. ÓÏÐÀÂËÅÍÈÅ ÏÐÎÃÐÀÌÌÍÛÌ ÏÐÎÅÊÒÎÌ ................ 213
5.1. Эволюция методов управления ................................... 214
5.1.1. Система Тейлора ................................................ 215
5.1.2. Система Шухарта ............................................... 217
5.1.3. Новая философия качества (идеи Деминга) ... 219
5.2. Современные концепции управления ........................ 222
5.2.1. Управление предприятием
в постиндустриальный период .......................... 222
5.2.2. Система управления качеством ........................ 223
5.2.3. Сертификация систем качества.
Стандарты серии ИСО 9000 .............................. 225
5.2.4. Всеобщее управление качеством ...................... 228
5.3. Управление рисками программного проекта ............. 229
5.3.1. Риски, связанные с реализацией проекта ....... 229
5.3.2. Разделение ответственности .............................. 231
5.3.3. Количественная оценка рисков ........................ 232
#
5.3.4. Определение размеров ресурсов,
необходимых для снижения рисков ................. 233
5.3.5. Типовые и специфические источники
рисков .................................................................. 236
5.3.6. Откуда брать информацию о рисках ................ 238
5.4. Управление персоналом ............................................... 239
5.4.1. Роль персонала в эффективности проекта ...... 239
5.4.2. Обеспечение условий работы ............................ 242
5.4.3. Работа в потоке .................................................. 243
5.4.4. Организация рабочего места ............................. 244
5.4.5. Формирование команды .................................... 245
5.4.6. Инвестиции в человека ..................................... 248
5.5. Управление конфигурацией ........................................ 249
5.5.1. Основные понятия ............................................. 249
5.5.2. Средства и методы управления
конфигурацией ................................................... 254
5.5.3. Электронная документация ............................... 258
5.6. Эволюционная модель зрелости фирмы .................... 259
5.6.1. Уровни СММ ...................................................... 260
5.6.2. Использование модели CMM ........................... 263
Контрольные вопросы .......................................................... 265
Приложение. Примеры заданий для практических занятий ....... 267
Краткий словарь терминов .............................................................. 277
Библиографический список ............................................................. 283
$
ÏÐÅÄÈÑËÎÂÈÅ
Одно из неоспоримых достижений российской высшей школы – высокий уровень качества подготовки программистов.
Однако в последние годы отечественные разработчики программного обеспечения не могут похвастаться большими успехами
на мировом рынке. Достаточно сказать, что при равных стартовых условиях в начале 1990-х годов, мы в 10 раз отстаем от Индии
по объему продаваемых на экспорт программных продуктов.
Важнейшей причиной таких неудач является низкий уровень
организации разработок. И это при том, что в России имеется
богатый опыт именно в организации крупномасштабных сложных технических проектов.
Проблема эффективной организации разработки программных проектов актуальна во всем мире. В последнее время появилось новое направление компьютерной науки – программная инженерия. Авторы множества публикаций, разработчики
известных программных продуктов приходят к выводу, что организация работ и управление проектом являются определяющими факторами успешности конкретного проекта и фирмы в
целом.
Вопросам программной инженерии посвящено множество
учебников отечественных и зарубежных авторов. К сожалению,
в большинстве из них недостаточно внимания уделяется вопросам применения стандартов с учетом специфики и сложившейся практики разработки программных продуктов в России.
Цель настоящего учебного пособия – раскрыть особенности
использования отечественных и зарубежных методов стандартизации при организации разработки средних и крупных программных проектов и управления ими. Эта цель определила и
структуру пособия.
Глава1 знакомит читателя с основными понятиями и методами стандартизации, российским законодательством в области
технического регулирования. В ней рассматривается проблема
оценки качества программного продукта. В главе2 обсуждаются вопросы организации разработки программных систем; описываются различные модели жизненного цикла, отечественные,
%
зарубежные и международные стандарты, регламентирующие
этапы, процессы и методы разработки проекта и управления им.
Как показывает опыт многих разработок, успешность проекта и его качество во многом определяется начальными этапами – формированием требований и планированием разработки
проекта. Глава 3 посвящена этим начальным этапам разработки:
излагаются методы формирования, систематизации и анализа
требований к программе; приводятся основные понятия, связанные с планированием разработок, дается обзор методов планирования; рассматриваются методы получения объективной
информации о трудоемкости и сложности разработки на основе
систематизации опыта прошлых разработок и объективных метрик сложности.
В главе 4 освещаются проблемы разработки и тестирования
программного продукта, выбора средств разработки, приводятся понятия архитектуры программы, стратегии нисходящего и
восходящего проектирования. Подробно описаны модели надежности программного обеспечения, цели, задачи и методы тестирования программ.
В главе 5 обсуждаются проблемы управления программным
проектом; приводится исторический экскурс эволюции представлений и методов управления; излагаются современные концепции управления; рассматриваются различные аспекты управления – рисками, персоналом и конфигурацией проекта; дается
подробное описание применения модели развития возможностей по мере зрелости фирмы (Capability Maturity Model – CMM)
для сертификации и управления развитием фирмы.
Пособие предназначено для студентов высших учебных заведений, обучающихся по специальностям и направлениям подготовки высшего профессионального образования 080801.65
«Прикладная информатика (по областям)» и 080800.62 «Прикладная информатика», 230105.65 «Программное обеспечение
вычислительной техники и автоматизированных систем»,
010503.65 «Математическое обеспечение и администрирование
информационных систем», а также для аспирантов и специалистов в области разработки программного обеспечения.
&
ÎÑÍÎÂÛ ÑÒÀÍÄÀÐÒÈÇÀÖÈÈ
È ÑÅÐÒÈÔÈÊÀÖÈÈ
1.1. Îñíîâíûå ïîíÿòèÿ ñòàíäàðòèçàöèè
1.1.1. ×òî òàêîå ñòàíäàðò
Занимаясь совместным трудом, мы постоянно сталкиваемся
с необходимостью согласовывать свои действия таким образом,
чтобы результатом работы одних могли воспользоваться все люди.
Примеры таких договоренностей известны с древних времен.
Так, в Древнем Риме была определена ширина колесницы, и
никто не имел права делать колесницы иной ширины. Это заставило римлян проектировать дома таким образом, чтобы по
дороге между ними могли разъехаться встречные колесницы, а
дороги мостить по колеям (только там, где катятся колеса).
Одним из первых упоминаний использования методов стандартизации для организации производства является пример вооружения армии США времен Гражданской войны1. Армия остро нуждалась в мушкетах, но ни один ремесленник не мог
изготовить нужное количество оружия в требуемые сроки. Раздавать заказ по многим ремесленникам командование не хотело, справедливо полагая, что собрать и испытать массу разнородного оружия будет очень трудно.
За выполнение заказа взялся один смелый бизнесмен. Он
выбрал простую, но надежную конструкцию мушкета, тщательно зарисовал все его детали, сформулировал требования к каждой их них и раздал в виде субподрядов другим ремесленникам
и фирмам. У себя он оставил только участки контроля и сборки.
В договоре о субподряде он заранее оговорил, что оплачивать
будет только те детали, которые полностью удовлетворяют
1
См.: Бурстин Д. «Американцы: национальный опыт». – М.: Прогресс, 1993. – С. 619
'
предъявленным к ним требованиям. Таким образом, заказ был
выполнен в полном объеме и в оговоренный срок, армия получила добротное и однотипное оружие, а человечество сделало
еще один шаг в направлении кооперации и повышения эффективности производства.
Основным законом, определяющим место, цели и задачи стандартизации в России является закон РФ «О техническом регулировании» [1]. В законе дано следующее определение стандарта: «стандарт – документ, в котором в целях
добровольного многократного использования устанавливаются характеристики продукции, правила осуществления и
характеристики процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, выполнения
работ или оказания услуг. Стандарт также может содержать
требования к терминологии, символике, упаковке, маркировке или этикеткам и правилам их нанесения».
Таким образом, стандарт – это специальным образом
оформленный договор между всеми участниками определенного
вида деятельности (например, производства и потребления
определенной продукции).
Стандарты позволяют зафиксировать договоренности между
участниками, обеспечить совместимость результатов, многократно использовать удачные технические решения. Применение
стандартов позволяет использовать заимствованные узлы, детали, программные модули и информационные ресурсы, помогает планировать и управлять ходом разработок.
Юридическими участниками договора, оформленного в виде
стандарта, обычно являются не физические, а юридические лица
(организации), а также государство. Если вы работаете на предприятии, на котором действует стандарт, то обязаны выполнять
требования этого стандарта.
К договору можно присоединиться (т.е. признать стандарт)
и после его заключения. Например, если вы намерены производить или продавать какую-либо продукцию (например, товары
потребления для граждан России), то должны признать стандарты, устанавливающие требования к вашей продукции на данном рынке (например, требования к безопасности, маркировке
и упаковке, к защите окружающей среды и т.д.). При этом вы
берете на себя обязательство неукоснительно выполнять признанные вами требования.
1.1.2. Çàäà÷è ñòàíäàðòèçàöèè
В законе «О техническом регулировании»1 перечислены следующие задачи стандартизации:
1. Обеспечение единства технических решений:
а) обеспечение единства измерений. Единство измерений –
состояние измерений, при котором их результаты выражены в
узаконенных единицах величин и погрешности измерений не
выходят за установленные границы с заданной вероятностью [2].
Обеспечение единства измерений гарантирует сопоставимость
результатов измерений вне зависимости от того, кем и когда
они выполнены. Для обеспечения единства измерений в России создана специальная Государственная система обеспечения
единства измерений (ГСИ). Программные продукты, обрабатывающие или использующие результаты измерений, должны подчиняться стандартам ГСИ. Основные понятия и методы обеспечения единства измерений приведены в разд.1.3;
б) единство терминологии. Термины, используемые участниками договора, должны однозначно пониматься всеми участниками. Для обеспечения единства терминологии в России создано несколько общероссийских классификаторов. При разработке
программ и информационных систем, как правило, разрабатываются терминологические справочники, позволяющие системе
и всем ее пользователям правильно воспринимать и обрабатывать информацию. Методы обеспечения единства терминологии с помощью программных продуктов приведены в разд.1.4;
в) единство обозначений и маркировки. Требования к упаковке, маркировке, этикеткам на продукции и правилам их нанесения должны обеспечивать однозначность идентификации видов
и свойств продукции. Программы, работающие с информацией
о продукции, должны учитывать требования к ее маркировке.
Сами программы, являющиеся товаром, должны иметь названия, отражающие их назначение и область применения. При
этом, название программы должно быть уникальным, обеспечивать защиту авторского права разработчика и не нарушать
авторских прав других разработчиков программного обеспече1
Федеральный закон «О техническом регулировании» от 27 декабря
2002 г. № 184-ФЗ. Вступил в силу 27 июня 2003 г. (через шесть месяцев
после опубликования).
ния. Упаковка и маркировка программы должны обеспечивать
ее сохранность и однозначную идентификацию. Описание, расположенное на упаковке, должно содержать информацию о назначении программы и основных ее характеристиках.1
2. Обеспечение совместимости:
а) конструкционная совместимость – конструкция деталей и
узлов, которые могут работать вместе (в одном изделии), должны обеспечить их совместную работу;
б) электрическая совместимость – совокупность параметров
электрических цепей и сигналов должны обеспечивать совместную работу устройств. Множество примеров конструкционной и электрической совместимости дает современный персональный компьютер. Так, разъем USB позволяет подключить к
нему множество разнообразных внешних устройств. Все технические средства, используемые вашим программным продуктом,
должны проверяться на конструкционную и электрическую совместимость;
в) информационная и программная совместимость – наиболее
важный для программистов вид совместимости. Как будет показано дальше, большинство стандартов в области программного
обеспечения призваны обеспечить информационную и программную совместимость программных продуктов.
3. Методики выполнения измерений. Измерения одних и тех
же величин нередко встречаются в различных отраслях деятельности человека. Методами измерений, оценки точности и
достоверности их результатов занимается специальная наука–
метрология. Удачные методики измерения оформляются в виде
стандартов, которые могут быть использованы всеми, кому нужно
проводить аналогичные измерения. Использование стандартных
методик измерения позволяет обеспечить единство измерений.
В программировании специфическими измерениями являются тесты, подтверждающие работоспособность программ, а
также испытания, определяющие значения характеристик программ (например, время реакции на запрос). Разработка и использование методик тестирования и испытаний, пригодных для
1
Например, если компьютерная программа распространяется на CD,
необходимо расположить на обложке CD название программы, краткую
информацию о ее назначении, сведения об изготовителе (включая адрес,
E-mail и контактные телефоны), а также знак охраны программы как объекта
интеллектуальной собственности.
нескольких программных продуктов с близкими функциями и
назначениями, также является задачей стандартизации.
4. Использование типовых технических решений. Как и измерения, удачные технические решения могут быть использованы
многократно. Это сокращает затраты на проектирование, а сами
изделия становятся более дешевыми и надежными. Разработка
универсальных программных модулей и их использование в различных программах является хорошим примером типовых технических решений.
5. Использование типовых наборов требований к качеству.
Качество продукта, в условиях насыщенного рынка, становится
основным фактором, определяющим его конкурентоспособность.
При этом методы обеспечения качества во многом являются универсальными, не зависящими от того, какой продукт мы производим. Систематизированные и оформленные в виде стандартов методы и требования к системам управления качеством
позволяют существенно повысить качество продукции.
Отметим, что практически все отечественные и международные стандарты в области разработки программного обеспечения
хорошо интегрированы с системой международных стандартов
в области управления качеством ISO 9000.
1.1.3. Âèäû ñòàíäàðòîâ
Методы управления, заключающиеся в создании и применении стандартов, называются нормативными методами управления. Разработка, производство и использование достаточно сложных объектов требует, чтобы все участники этого процесса
договорились по техническим вопросам и придерживались этих
договоренностей в своей деятельности. Договоренности, достигнутые сотрудниками одного предприятия, оформляются в виде
стандарта организации (СТО). Требования СТО после утверждения их руководителем организации становятся обязательными для всех сотрудников данного предприятия.
Для обеспечения взаимодействия предприятий также требуются стандарты. Совокупность требований, отражающих специфику одной отрасли, оформляется в виде отраслевых стандартов (ОСТов). Требования, специфичные для данного региона,
оформляются в виде региональных стандартов. Наконец, требования, касающиеся всех граждан и предприятий страны, оформляются в виде государственных стандартов (ГОСТов).
!
Для вхождения в мировую экономическую систему Россия
должна присоединиться к международным соглашениям и принять на себя ряд обязательств. Одним из механизмов присоединения страны к мировому сообществу является признание этой
страной международных стандартов. В этом случае в стране выпускается национальный стандарт, полностью идентичный международному стандарту.
1.1.4. Èçìåíåíèå öåëåé è ìåòîäîâ ñòàíäàðòèçàöèè
ïðè ðàçâèòèè ðûíî÷íûõ îòíîøåíèé
В настоящее время в России происходят весьма противоречивые процессы перехода от административных методов управления экономикой к рыночным.
При административной системе только государство могло
владеть средствами производства. Фактически все предприятия
страны являлись филиалами одной фирмы– государства. Для
обеспечения управления в такой огромной фирме требовались
специальные методы (рис. 1.1, а).
Рис. 1.1. Различия в применении нормативных методов управления при
административной (а) и рыночной (б)
системах управления экономикой страны
"
Государство создало два ведомства: Госплан и Госстандарт.
Госплан осуществлял общее планирование, определял производственные задания всем предприятиям, подбирал для них
поставщиков и определял потребителей их продукции. Госстандарт отвечал за обеспечение единства требований. Он разрабатывал и утверждал стандарты, обязательные для всех участников
экономического процесса, обеспечивал единство измерений и
терминологии.
Таким образом, в плановой экономике стандарт отражал требования единого хозяина–государства. Устанавливая стандарты
и осуществляя контроль за их выполнением, государство управляло своей огромной фирмой.
Как показал опыт, такой способ управления национальной
экономикой является весьма неэффективным. Сложность задач
централизованного управления десятками тысяч предприятий
была столь высокой, что приводила к постоянным сбоям и ошибкам планирования и управления народным хозяйством.
В рыночной экономике государство берет на себя значительно
меньше обязательств (рис. 1.1, б). Важнейшими из них являются обеспечение безопасности граждан и общества, а также законности и порядка взаимодействия всех членов общества.
Формирование требований к товару и его цене обеспечивает
рынок. Никому не нужные товары, предлагаемые по завышенным ценам или не обладающие требуемым качеством, никто не
купит. Следовательно, производители этих товаров не будут иметь
доход и будут вынуждены или уйти с рынка, или изменить свое
отношение к производству.
Таким образом, в рыночной экономике государство ограничивается контролем соблюдения интересов своих граждан, связанных с безопасностью их жизни и здоровья, а также формирует
«правовое поле» – правила и законы взаимоотношений граждан, организаций и государства.
1.1.5. Ôåäåðàëüíûé çàêîí
«Î òåõíè÷åñêîì ðåãóëèðîâàíèè»
В соответствии с Федеральным законом «О техническом регулировании», выполнение которого контролируется государством, обязательными являются только требования стандартов,
#
относящиеся к безопасности1. Это значит, что все остальные
требования могут приниматься участниками процесса производства и использования продукции добровольно. При формировании требований разработчики и заказчики вправе выбирать подходящие стандарты, соглашаться только с частью записанных в
них требований или формулировать дополнительные требования к продукции, технологии ее производства и использования.
Обязательными к исполнению эти требования становятся в случае признания стандарта фирмой или указания на него в договорной документации.
Таким образом, существующие стандарты являются систематизированными наборами требований, отражающими накопленный опыт. Использование стандартов существенно сокращает затраты на формулировку требований, а также позволяет
воспользоваться хорошо отработанными и проверенными временем методическими решениями.
До недавних пор обязательные требования к одному виду
деятельности (т.е. требования к продукции, к безопасности производства, маркировке и т.д.) были рассредоточены в нескольких нормативных документах. Разобраться с такой системой требований могли только высококвалифицированные специалисты
в области стандартизации. Кроме того, стандарты, написанные
и принятые в различное время и различными ведомствами, нередко противоречили друг другу.
Одним из условий существования демократического общества является гласность и доказуемость правильности действий
государственных органов. Для этого необходимо выполнение нескольких требований:
1) тексты законов должны быть доступны и понятны всем
гражданам, которых они касаются:
• тексты законов и всех документов, связанных с ними, должны быть опубликованы и доступны для изучения и применения;
• нормы, изложенные в законе, должны одинаково пониматься всеми гражданами, кого эти нормы касаются;
• законы не должны содержать противоречивых требований;
1
Такое положение определено законом только на переходный период
при отсутствии технического регламента на данную группу продукции/
услуг. После появления технического регламента, обязательными считаются только содержащиеся в нем требования.
$
2) законы и нормативные акты должны определять четкие
правила проверки исполнения содержащихся в них требований.
Для выполнения перечисленных требований в области технического законодательства в 2003 г. в России и был принят
Федеральный закон «О техническом регулировании», который
определяет основные понятия, устанавливает правила и требования государственного контроля технических характеристик
производства и выпускаемой продукции. Закон предусматривает постепенный пересмотр всех нормативно-технических документов, устанавливающих требования к продукции, услугам и
их производству. Вместо разрозненных нормативных документов для каждой группы продукции разработаны специальные
документы: «Технические регламенты», каждый из которых содержит исчерпывающий перечень требований к данной группе
продукции. Ни один государственный орган не в праве требовать от производителя чего-либо кроме выполнения требований, указанных в «Техническом регламенте».
Ниже приведены определения основных понятий, данные в
этом Федеральном законе.
Техническое регулирование – правовое регулирование отношений в области установления, применения и исполнения обязательных требований к продукции, процессам производства, эксплуатации, хранения, перевозки, реализации
и утилизации, а также в области установления и применения на добровольной основе требований к продукции, процессам производства, эксплуатации, хранения, перевозки,
реализации и утилизации, выполнению работ или оказанию
услуг и правовое регулирование отношений в области оценки соответствия.
Технический регламент – документ, который принят международным договором Российской Федерации, ратифицированный в порядке, установленном законодательством Российской Федерации, или федеральным законом, или указом
Президента Российской Федерации, или постановлением
Правительства Российской Федерации, устанавливает обязательные для применения и исполнения требования к объектам технического регулирования продукции, в том числе зданиям, строениям и сооружениям, процессам производства,
эксплуатации, хранения, перевозки, реализации и утилизации.
%
Безопасность продукции, процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации (далее –
безопасность) – состояние, при котором отсутствует недопустимый риск, связанный с причинением вреда жизни или
здоровью граждан, имуществу физических или юридических
лиц, государственному или муниципальному имуществу, окружающей среде, жизни или здоровью животных и растений.
Риск – вероятность причинения вреда жизни или здоровью граждан, имуществу физических или юридических лиц,
государственному или муниципальному имуществу, окружающей среде, жизни или здоровью животных и растений с
учетом тяжести этого вреда.
Декларирование соответствия – форма подтверждения соответствия продукции требованиям технических регламентов.
Сертификат соответствия – документ, удостоверяющий
соответствие объекта требованиям технических регламентов,
положениям стандартов или условиям договоров.
1.2. Ñåðòèôèêàöèÿ
Предположим, что разработана хорошая программа. Она реализует оригинальный алгоритм, позволяющий просто и быстро решать очень важные задачи. Разработчикам программа очень
нравится. Но как убедить пользователя в том, что данная программа – это именно то, что ему нужно? Вот если бы кто-то, к
чьему мнению прислушиваются пользователи, подтвердил, что
эта программа действительно хороша. Тогда бы, рекламируя свою
программу, разработчики могли бы сослаться на мнение уважаемого эксперта, что позволило бы быстрее убедить пользователей приобрести именно эту программу.
1.2.1. Ñóùíîñòü ñåðòèôèêàöèè
Дословный перевод термина «сертификация» – «я подтверждаю». Любая сертификация – это подтверждение соответствия
объекта сертификации предъявленным к нему требованиям. В
процессе сертификации можно выделить ряд элементов. Их перечень и назначение приведены ниже.
&
Ýëåìåíò
Íàçíà÷åíèå ýëåìåíòà
Îáúåêò ñåðòèôèêàöèè Îáúåêò, ñâîéñòâà êîòîðîãî ïîäòâåðæäàþòñÿ.
Çàêàç÷èê
Õîçÿèí îáúåêòà ñåðòèôèêàöèè, ãîñóäàðñòâî èëè
òðåòüå ëèöî, ïîòðåáîâàâøåå ïðîâåäåíèå ñåðòèôèêàöèè
Öåëü ñåðòèôèêàöèè
Îïðåäåëÿåòñÿ, çà÷åì ïðîâîäèòñÿ ñåðòèôèêàöèÿ;
êàê áóäóò èñïîëüçîâàíû åå ðåçóëüòàòû
Òðåáîâàíèÿ
Óñòàíàâëèâàåòñÿ ïåðå÷åíü ñâîéñòâ îáúåêòà ñåðòèôèêàöèè, íàëè÷èå êîòîðûõ ïîäòâåðæäàåòñÿ â
ïðîöåññå ñåðòèôèêàöèè. Òðåáîâàíèÿ ìîãóò áûòü
îïðåäåëåíû çàêîíîäàòåëüíî èëè ïðåäúÿâëåíû
çàêàç÷èêîì
Îðãàí ñåðòèôèêàöèè Ãîñóäàðñòâåííîå ó÷ðåæäåíèå èëè ÷àñòíàÿ ôèðìà,
ïðîâîäÿùèå ñåðòèôèêàöèþ
Ñõåìà ñåðòèôèêàöèè Óêàçûâàþòñÿ ïðàâèëà ïðîâåäåíèÿ ñåðòèôèêàöèè,
âêëþ÷àþùèå ïåðå÷åíü ïîäòâåðæäàåìûõ òðåáîâàíèé, ìåòîäèêó èõ êîíòðîëÿ è ïîäòâåðæäåíèÿ, à
òàêæå âèä è þðèäè÷åñêèé ñòàòóñ âûäàâàåìîãî
äîêóìåíòà
Ñåðòèôèêàò
Äîêóìåíò, âûäàâàåìûé îðãàíîì ñåðòèôèêàöèè,
ïîäòâåðæäàþùèé ñîîòâåòñòâèå îáúåêòà ñåðòèôèêàöèè ïðåäúÿâëåííûì ê íåìó òðåáîâàíèÿì
1.2.2.Òðåáîâàíèÿ ê áåçîïàñíîñòè è êà÷åñòâó
Как отмечалось выше, в рыночной экономике государству
вовсе не обязательно контролировать все требования к продукции, ее производству и потреблению. Закон выделяет:
• обязательные требования– контролировать выполнение которых может государственный орган или любой другой орган,
имеющий государственную аккредитацию на проведение сертификации в данной области;
• необязательные требования – выполнять которые исполнитель и заказчик добровольно обязались в рамках конкретного
договора.
Обязательные требования включают требования к безопасности производства и потребления продукции, а также требования к совместимости. Необязательные требования, в основном, –
требования к качеству продукции. В зависимости от того, выполнение каких требований подтверждается при сертификации,
сама сертификация может быть обязательной или добровольной
(необязательной). Правила проведения сертификации обязатель '
ных и необязательных требований определяются законом РФ
«О техническом регулировании».
Документальное удостоверение соответствия продукции или
иных объектов требованиям технических регламентов, положениям стандартов или условиям договора получило название подтверждение соответствия. Обязательное подтверждение соответствия осуществляется в формах:
• принятия декларации о соответствии (далее – декларирование соответствия);
• обязательной сертификации.
1.2.3. Îáÿçàòåëüíàÿ è äîáðîâîëüíàÿ ñåðòèôèêàöèÿ
Организация и проведение работ по обязательной сертификации возлагаются на Госстандарт, а в случаях, предусмотренных законодательными актами Российской Федерации в отношении отдельных видов продукции, могут быть возложены на
другие федеральные органы исполнительной власти. На рис. 1.2
приведена схема формирования требований к конкретному объекту при его обязательной сертификации. Здесь необходимо отметить, что требования, содержащиеся в стандартах и системах
стандартов, могут быть обязательными только до выхода соответствующего технического регламента. Такой порядок сохраняется в
течение семи лет1 со дня вступления в силу Федерального закона
«О техническом регулировании». Длинная вертикальная стрелка отображает процедуру формирования требований на основе
технических регламентов.
В условиях конкуренции, когда рынок перенасыщен товаром, производителю нет смысла выпускать некачественную продукцию – ее все равно никто не купит. В то же время, продукция лучшего качества будет пользоваться повышенным спросом
и принесет производителю больше дохода. Таким образом, качество продукции становится важнейшим фактором в конкурентной борьбе. Чтобы привлечь как можно больше покупателей, производитель рекламирует качество своей продукции. Он
просит, чтобы люди и фирмы, вызывающие доверие у покупателей, подтвердили это качество. Одним из самых достоверных
1
Согласно пункту 7 статьи 46 Федерального закона «О техническом
регулировании», технические регламенты должны быть приняты в течении семи лет со дня вступления в силу данного закона.
Рис. 1.2. Нормативно-правовая база, устанавливающая требования
к номенклатуре и характеристикам продукции, подлежащей
обязательной сертификации
методов подтверждения качества является добровольная сертификация.
Смысл добровольной сертификации. Торговля рисками. Представьте себе: вы начинающий бизнесмен, наладивший производство высококачественного и очень нужного товара. Вы рассчитываете добросовестно выпускать этот товар, не снижая его
качества, а постоянно улучшая, учитывая интересы покупателей. Но на рынке вас пока не знают. Как покупателю отличить
ваш товар от товаров фирм-однодневок, обманывающих своих
клиентов? Вы обращаетесь в солидную фирму, к мнению которой прислушиваются покупатели, просите протестировать ваш
товар, и если результаты тестирования удовлетворят фирму, публично подтвердить соответствие вашего товара характеристикам,
указанным в вашей рекламе. Такая процедура называется добровольная сертификация.
Конечно, после такого подтверждения покупатели будут более охотно присматриваться к вашему товару. Объем продаж, а,
следовательно, и доход возрастут. Вы расплатитесь с фирмой за
сертификацию и все равно окажетесь в прибыли.
За что вы заплатили этой фирме? Давая подтверждение качества вашего товара, фирма взяла часть вашего риска на себя.
Таким образом, сертифицирующая фирма торгует своим добрым
именем! В условиях развитого, цивилизованного рынка это очень
дорогой товар, потому что единожды солгавшему, кто же поверит? Именно поэтому солидная фирма, прежде чем выдать сертификат, тщательно проверит и вас, и вашу фирму, и ваш товар.
Схема проведения сертификации. Добровольное подтверждение соответствия осуществляется по инициативе заявителя на
условиях договора между заявителем и органом по сертификации. Добровольное подтверждение соответствия может осуществляться для установления соответствия национальным стандартам, стандартам организаций, системам добровольной
сертификации или условиям договоров.
Объектами добровольного подтверждения соответствия являются: продукция, процессы производства, эксплуатации, хранения, перевозки, реализации и утилизации, работы и услуги, а
также иные объекты, в отношении которых стандартами, системами добровольной сертификации и договорами устанавливаются требования.
При проведении сертификации Орган по сертификации выполняет следующие функции:
• осуществляет подтверждение соответствия объектов добровольного подтверждения соответствия;
• выдает сертификаты соответствия на объекты, прошедшие
добровольную сертификацию;
• предоставляет заявителям право на применение знака соответствия, если применение знака соответствия предусмотрено
соответствующей системой добровольной сертификации;
• приостанавливает или прекращает действие выданных им
сертификатов соответствия.
Система добровольной сертификации может быть создана
как юридическим лицом, так и индивидуальным предпринимателем или несколькими юридическими лицами и (или) индивидуальными предпринимателями.
1.2.4. Îðãàíû ïî ñåðòèôèêàöèè
ïðîãðàììíîãî îáåñïå÷åíèÿ â Ðîññèè
В России действует национальная система сертификации –
ГОСТ Р, образованная на базе Госстандарта России. Она получила признание в большинстве стран мира и включает, в частности, сертификацию программных продуктов. Для получения
сертификата системы ГОСТ Р нужно обратиться или в один из
аттестованных Госстандартом России органов по сертификации,
или непосредственно в Госстандарт, где порекомендуют такой
орган. Можно также обратиться в одну из аккредитованных Госстандартом испытательных лабораторий (в отличие от органа по
сертификации она не имеет права самостоятельно выдавать сертификат соответствия, но может проводить испытания, которые
затем проверяются и утверждаются органом, связанным с данной лабораторией соответствующими договорами). Каждый орган
(лаборатория) имеет свою область аккредитации, определяющую
номенклатуру программных продуктов, которые они имеют право
сертифицировать.
В качестве примера приведем описание одной такой организации – Российского научно-технического центра информации
по стандартизации, метрологии и оценке соответствия («Стандартинформ – Сертификат»). Организация аккредитована в качестве Органа по добровольной сертификации программных
средств и информационных продуктов вычислительной техники в Системе сертификации ГОСТ Р Федерального агентства по
техническому регулированию и метрологии1.
Следует отметить, что рынок сертификационных услуг в
России еще находится в стадии формирования. Наряду с крупными общероссийскими организациями, в настоящее время созданы отраслевые центры сертификации. Например, в области
образования наибольшую известность получили два центра сертификации: Московский государственный технологический
университет «Станкин» и Институт информатизации образования. Кроме них существует значительное количество более мелких центров, ориентированных на сертификацию специфиче1
Номер в Государственном реестре: РОСС RU.0001.11СП18. Выдан:
22 января 2007 г. Срок действия аттестата: до 22 января 2010 г. Адрес:
123995, К-1, ГСП-5, г. Москва, Гранатный переулок, дом 4.
!
ских видов программной продукции. При этом постоянно появляются и активно борются «за место под солнцем» новые организации, предлагающие услуги по сертификации программ.
1.3. Ìåòðîëîãèÿ
В процессе познания мира и практической деятельности человеку приходится сопоставлять характеристики объектов, с
которыми он имеет дело. Например, вы выбираете костюм. Цена
всех увиденных вами костюмов в принципе вас устраивает, но
как подобрать фасон, цвет и фактуру материи, как выбрать нужный размер? Некоторые из перечисленных характеристик легко
измерить (например, длину брюк). Другие характеристики (например, фасон) трудно поддаются количественной оценке и часто порождают споры, вызванные тем, что различные участники понимают предмет обсуждения по-разному.
При обсуждении философской проблемы, такое разнообразие взглядов уместно и даже полезно, но когда нужно скоординировать работу множества людей, мы должны договориться о
системе понятий, методах и критериях их оценки. У этой проблемы два связанных между собой аспекта:
• обеспечение единства понимания и применения (это задача стандартизации);
• обеспечение сопоставимости оценок и критериев (а это
задача метрологии).
Вот почему метрология и стандартизация, как правило, рассматриваются и изучаются вместе.
Как сопоставить различные характеристики объектов и как
обосновать принятое решение? Для этого нам придется построить модель объекта, включить в нее все важные для нас свойства
реального объекта и отбросить несущественные свойства1. Затем придется предположить, что существует множество схожих
объектов, характеристики которых можно сравнить с аналогичными характеристиками нашего объекта.
1
Для простых и хорошо известных объектов такие построения проходят на уровне интуиции. Мы просто используем давно известные модели,
не задавая вопросов о том, как они построены. Если же мы имеем дело с
новыми и достаточно сложными объектами, нам придется самим строить
их модели.
"
Что такое измерение и что такое измеряемая величина. Если
результат сопоставления может быть выражен количественно
(например, длина моего стола в 130 раз больше длины сантиметрового деления линейки), то такая характеристика называется измеряемой величиной. До недавних пор измерениями назывались только количественные сопоставления характеристик
объектов с эталонами1, выполняемые с помощью технических
средств (приборов), поэтому рассмотрим их в первую очередь.
Каким условиям должна удовлетворять количественная характеристика объекта, чтобы ее можно было считать измеряемой величиной?
Во-первых, должна присутствовать интерпретация ее связи с
интересующими нас свойствами объекта. Характеристика должна сама быть интересующим нас свойством (в этом случае мы
говорим о прямых измерениях), или по ее значению можно вычислить значение интересующего нас свойства (косвенные измерения).
Во-вторых, характеристика может быть задана в одной из
установленных единиц измерения. Это позволит сопоставлять
значения характеристики, полученные для разных объектов или
различными методами.
В-третьих, должен существовать метод измерения характеристики для интересующего нас множества объектов, обладающий следующими свойствами:
• объективностью – результаты измерения должны как можно меньше зависеть от того, кто эти измерения проводит. Величина такой зависимости не должна превышать допустимую
погрешность метода с заданной доверительной вероятностью;
• определенностью погрешности и достоверности. Для метода
должна быть известна погрешность – доверительный интервал,
в котором с указанной доверительной вероятностью находится
истинное значение характеристики. Погрешность должна быть
достаточно малой, а доверительная вероятность – близкой к
единице.
• воспроизводимостью. Если свойства объекта, связанные с
измеряемой величиной не менялись, результаты повторных ис1
Эталоном называется объект, для которого известно значение измеряемой величины с точностью, превышающей допустимую точность измерений, а также прибор или метод, позволяющий измерить данную величину с точностью, большей, чем требуется в данном измерении.
#
пытаний с указанной доверительной вероятностью не должны
отличаться друг от друга больше, чем на погрешность метода.
Совокупность измеряемой величины, ее интерпретации
и метода измерений называется метрикой.
Поиск методов измерений, оценка их достоверности, точности и воспроизводимости часто является сложной научной проблемой. Отрасль науки, посвященная проблемам измерений,
называется метрологией.
Метрология – наука об измерениях. В ее задачи входят:
поиск методов измерения интересующих нас характеристик,
обеспечение сопоставимости и достоверности результатов измерений.
1.3.1. Îáåñïå÷åíèå åäèíñòâà èçìåðåíèé
Для того чтобы обосновано принимать решения, мы должны
иметь возможность сопоставлять данные. Если метод измерения существует, то мы можно воспользоваться его результатами
независимо от того, кто и когда эти измерения произвел. В этом
случае результаты измерений называются сопоставимыми.
Для обеспечения сопоставимости результатов измерений
необходимо осуществить ряд специальных мероприятий и применить методы, некоторые из которых описаны ниже.
Сопоставимыми называются результаты измерений, с которыми можно обращаться как с числами (складывать, вычитать). При этом сумма частей должна равняться целому.
Если эти мероприятия обеспечили сопоставимость всех измерений на предприятии, в отрасли, в стране или во всем мире,
мы говорим о единстве измерений. Обеспечение единства измерений является одной из важнейших задач метрологии.
Единство измерений – состояние измерений, при котором их результаты выражены в узаконенных единицах величин и погрешности измерений не выходят за установленные
границы с заданной вероятностью [2]. Данное состояние
обеспечивает сопоставимость результатов измерений.
Система единиц измерения. Первое требование единства измерений – их результаты должны быть выражены в узаконен$
ных единицах величин. Для обеспечения этого требования в
России допускается к применению только определенный перечень единиц измерений [2]. Основу этого перечня составляют
величины Международной системы единиц (СИ), принятой Генеральной конференцией по мерам и весам, рекомендованные
Международной организацией законодательной метрологии.
Национальные наименования, обозначения и правила написания единиц величин, а также правила их применения на территории России устанавливает Правительство РФ. В случае необходимости Правительство допускает к применению внесистемные
единицы величин. Только для продукции, поставляемой на экспорт, количественные характеристики могут быть выражены в
единицах величин, установленных заказчиком.
Обеспечением единства измерений в России занимаются специальные метрологические службы.
Метрологическая служба – совокупность субъектов деятельности и видов работ, направленных на обеспечение единства измерений.
Для обеспечения единства измерения в масштабах страны в
России действует Государственная метрологическая служба, в
состав которой входят государственные научные метрологические центры и органы Государственной метрологической службы на территориях республик в составе Российской Федерации,
автономной области, автономных округов, краев, областей, городов Москва и Санкт-Петербург.
Правовой основой обеспечения единства измерений в России является закон РФ «Об обеспечении единства измерений»
[2]. Согласно этому закону (статья 4), Государственное управление деятельностью по обеспечению единства измерений в Российской Федерации осуществляет Комитет Российской Федерации по стандартизации, метрологии и сертификации (Госстандарт
России), который в 2004г. преобразован в Федеральное агентство по техническому регулированию и метрологии (Ростехрегулирование), подведомственное Министерству промышленности и энергетики Российской Федерации.
Обеспечением единства измерений на предприятии занимается
метрологическая служба предприятия. Ввиду огромной практической значимости обеспечения единства измерений такие службы созданы практически на каждом предприятии.
%
Службы осуществляют метрологический контроль и надзор
за состоянием измерений на предприятии путем:
• калибровки средств измерений;
• надзора за состоянием и применением средств измерений,
а также метрологической и нормативной документации (методик выполнения измерений, калибровки, поверки и т.д.);
• выдачи обязательных предписаний, направленных на предотвращение, прекращение или устранение нарушений метрологических правил и норм;
• проверки своевременности представления средств измерений на испытания, а также на поверку и калибровку.
Поверка средств измерений. Одним из методов обеспечения
сопоставимости измерений является поверка. Чтобы показаниям нашего прибора верили все, кто использует эти показания,
надо договориться о специальной процедуре проверки и поручить ее проведение людям, которым все верят. Действия, направленные на то, чтобы убедить всех, что показаниям прибора
можно верить, называются поверкой1.
Средство измерений – техническое устройство, предназначенное для измерений.
Поверка – совокупность операций, выполняемых органами государственной метрологической службы (другими
уполномоченными на то органами, организациями) в целях
определения и подтверждения соответствия средства измерений установленным техническим требованиям.
Назовем средство измерения, предназначенное для поверок
других средств измерений, эталоном. Чтобы характеристики точности эталона сохранялись как можно дольше, будем использовать его только для поверок. Таким образом, все средства измерений разбиваются на два класса: рабочие и эталонные.
Рабочее средство измерения – прибор (или оборудование), используемый для измерений на производстве.
Эталонное средство измерения – прибор (или оборудование), используемый только для поверки рабочих средств
измерений и эталонов.
1
Следует различать термины проверка и поверка. Например, перед тем
как использовать прибор, проверяют его работоспособность, но для того,
чтобы результатам измерений верили люди, прибор должен пройти поверку.
&
Эталоны также нуждаются в периодической поверке. Для этого
используются эталоны более высокого уровня. Для каждой основной величины существует государственный (национальный)
эталон и специальная методика поверок, позволяющая «передать»
характеристики измеряемой величины через цепочку промежуточных эталонов до рабочего средства измерения.
Государственный эталон единицы величины – эталон единицы величины, признанный решением уполномоченного
на то государственного органа в качестве исходного на территории Российской Федерации.
Требования к представлению результатов измерений в информационных системах. Результаты измерений составляют значительную часть информации, обрабатываемой компьютерными
программами. В отличие от отвлеченных чисел, результат измерений теряет смысл, если указывается только его количественное значение. Для однозначного понимания смысла результата
измерения необходимо знать:
• какое свойство, какого объекта, измеренное при каких обстоятельствах, он отражает;
• в каких единицах выражено значение;
• с какой точностью проведено измерение;
• насколько достоверен результат.
Перечисленные характеристики отражают семантику измерительной информации. Если не учитывать эту семантику при
обработке и интерпретации информации между потребителем
информации и ее поставщиком может возникнуть недопонимание, приводящее к ошибкам (табл. 1.1).
Т а б л и ц а 1.1
Типовые ошибки, возникающие при работе
с измерительной информацией
Îøèáêà
Íå òîò îáúåêò,
íå òà âåëè÷èíà
Íå òà åäèíèöà
èçìåðåíèÿ
Îïèñàíèå
Ïðåäñòàâëåíèÿ ïîòðåáèòåëÿ
èçìåðèòåëüíîé
èíôîðìàöèè îòëè÷àþòñÿ îò ïðåäñòàâëåíèé èñòî÷íèêà èíôîðìàöèè
Ïðèìå÷àíèå
Òèïè÷íàÿ îøèáêà, âûçâàííàÿ
îòñóòñòâèåì
åäèíñòâà òåðìèíîëîãèè,
ÿâëÿåòñÿ ïðè÷èíîé ãðóáåéøèõ îøèáîê èñïîëüçîâàíèÿ èíôîðìàöèè
Èñòî÷íèê èíôîðìàöèè è Ãðóáàÿ îøèáêà íà ïîïîòðåáèòåëü èìåþò â âèäó ðÿäêè èñêàæàåò çíà÷åíèÿ
ðàçíûå åäèíèöû èçìåðåíèÿ èçìåðÿåìîé âåëè÷èíû
'
Продолжение
Îøèáêà
Íåó÷òåíà
òî÷íîñòü
èçìåðåíèé
Íå òà
äîñòîâåðíîñòü
Îïèñàíèå
Ïîãðåøíîñòü
èçìåðåíèé
âîîáùå íå ó÷èòûâàåòñÿ,
èëè ïîòðåáèòåëü îøèáî÷íî
ïðåäïîëàãàåò, ÷òî òî÷íîñòü
îòëè÷àåòñÿ îò çàäàííîé
ïîñòàâùèêîì
Ïðèìå÷àíèå
Åñëè ïðè îáðàáîòêå èíôîðìàöèè
íåçíà÷àùèå
öèôðû íå îòáðàñûâàþòñÿ
(èëè îòáðàñûâàþòñÿ íåâåðíî), ñîçäàåòñÿ èëëþçèÿ
âûñîêîé òî÷íîñòè ðåçóëüòàòîâ. Îøèáêà ñêàçûâàåòñÿ ïðè èíòåðïðåòàöèè
áëèçêèõ çíà÷åíèé èçìåðÿåìîé âåëè÷èíû
 îòâåòñòâåííûõ ðàñ÷åòàõ Âîçìîæíîñòü
ïðèíÿòü
èñïîëüçóåòñÿ èíôîðìàöèÿ, îöåíî÷íûå èëè óñòàðåâäîñòîâåðíîñòü êîòîðîé âû- øèå çíà÷åíèÿ çà èñòèíçûâàåò ñîìíåíèÿ
íûå. Êàê è ïðåäûäóùàÿ
îøèáêà, îñîáåííî îïàñíà
ïðè îòâåòñòâåííûõ ðàñ÷åòàõ è âûâîäàõ
Ниже перечислены требования, предъявляемые к полноте характеристики измерительной информации, хранящейся в информационной системе.
Õàðàêòåðèñòèêà
èçìåðèòåëüíîé è íôîðìàöèè
Òðåáîâàíèå
Îáúåêò è îáñòîÿòåëüñòâà
êîíòðîëÿ
Îáúåêò, ñâîéñòâîì êîòîðîãî ÿâëÿåòñÿ èçìåðÿåìàÿ âåëè÷èíà, à òàêæå îáñòîÿòåëüñòâà
êîíòðîëÿ
(âðåìÿ,
ñîñòîÿíèå
îáúåêòà,
âëèÿþùèå ôàêòîðû è ò.ä.)
Äîñòîâåðíîñòü èçìåðåíèé
Åñëè êîíòðîëü ïðîâîäèòñÿ ñàìîñòîÿòåëüíî,
óêàçûâàåòñÿ ñòàòóñ êîíòðîëÿ. Íàïðèìåð:
«Êîíòðîëü ïðîèçâåäåí ïîâåðåííûì ñðåäñòâîì, îòâåòñòâåííûé Èâàíîâ À.Â.».
Ïðè èñïîëüçîâàíèè âíåøíåé èçìåðèòåëüíîé èíôîðìàöèè óêàçûâàåòñÿ åå èñòî÷íèê è
íàøà îöåíêà äîâåðèÿ åìó
Èçìåðÿåìàÿ âåëè÷èíà
 èíôîðìàöèîííîé ñèñòåìå äîëæåí âåñòèñü
ñïèñîê äîïóñòèìûõ èçìåðÿåìûõ âåëè÷èí.
Êðîìå íàçâàíèÿ âåëè÷èíû â ñïèñîê æåëàòåëüíî âêëþ÷àòü îïðåäåëåíèå (ïîÿñíåíèå).
Äëÿ êàæäîãî âèäà èçìåðèòåëüíîé èíôîðìàöèè äîëæíà áûòü óêàçàíà èçìåðÿåìàÿ âåëè÷èíà èç ñïèñêà
!
Продолжение
Õàðàêòåðèñòèêà
èçìåðèòåëüíîé èíôîðìàöèè
Òðåáîâàíèå
Åäèíèöà èçìåðåíèÿ
Äëÿ êàæäîãî çíà÷åíèÿ äîëæíà áûòü èçâåñòíà åäèíèöà èçìåðåíèÿ, ñâîéñòâåííàÿ äàííîé èçìåðÿåìîé âåëè÷èíå.  ðàçâèòûõ ñèñòåìàõ âåäóòñÿ ñïðàâî÷íèêè èçìåðÿåìûõ
âåëè÷èí, èõ åäèíèö èçìåðåíèÿ è àëãîðèòìîâ ïåðåñ÷åòà çíà÷åíèé èç îäíèõ åäèíèö â
äðóãèå
Òî÷íîñòü èçìåðåíèé
Òî÷íîñòü èçìåðåíèé äîëæíà áûòü âûðàæåíà
â îäíîé èç ïðèíÿòûõ ôîðì
Çíà÷åíèå èçìåðÿåìîé
âåëè÷èíû
Ôîðìàò ïðåäñòàâëåíèÿ çíà÷åíèÿ äîëæåí
ñîîòâåòñòâîâàòü òî÷íîñòè èçìåðåíèÿ. Ïðè
ïðåäñòàâëåíèè ðåçóëüòàòîâ èçìåðåíèÿ íåçíà÷àùèå öèôðû äîëæíû îòáðàñûâàòüñÿ
Вовсе не обязательно повторять перечисленные характеристики для каждого значения измеряемой величины. Например,
если вы храните информацию в табличной форме или в базе
данных, то характеристики семантики скорее всего относятся
ко всему столбцу значений. Вы можете запретить ввод сомнительной и недостоверной информации в информационную систему, тогда отпадет необходимость указывать характеристику
«достоверность».
Для пользователя важно знать значения всех характеристик
измерительной информации. И ему в принципе все равно, каким образом вы ее предоставите: в виде записи в базе данных
или комментария на экране, в контекстной справке или в программной документации.
1.3.2. Èçìåðåíèå íåêîëè÷åñòâåííûõ õàðàêòåðèñòèê.
Øêàëû è ìåòðèêè
Далеко не каждый результат сопоставления может быть выражен количественно. Например, продегустировав несколько
сортов сыра, мы можем выбрать самый вкусный, однако сказать, насколько или во сколько раз он вкуснее других сыров, мы
не сможем. Отметим, что чем сложнее объект и чем выше уровень управления, тем чаще приходится использовать неколиче!
ственные сопоставления. Например, изготовляя деталь, мы можем измерить и выразить в миллиметрах все ее размеры. Однако, при сопоставлении качества товаров (например, компьютерных программ) количественные оценки сделать очень трудно.
Еще более трудно сопоставить количественно различные направления развития программного комплекса. Как сделать неколичественные оценки максимально объективными, как оперировать такими оценками?
Хорошим примером использования неколичественных оценок является обработка результатов экспертизы. Действительно, организатору экспертизы приходится разбираться в разноголосице мнений приглашенных им экспертов, оценивать,
насколько они согласованны и можно ли принимать решение
на их основе. Наконец, он должен принять свое решение, учитывающее, по возможности, все разнообразие мнений. Чтобы
избежать грубых ошибок при проведении экспертизы и добиться приемлемой надежности оценок, необходимо использовать
специальные методики проведения экспертизы и обработки ее
результатов.
Множество объектов, предлагаемых эксперту для оценки, как
правило, не упорядочено. Основная задача эксперта – навести
какой-то порядок в этом множестве и, по возможности, оценить предпочтение каждого объекта для решаемой задачи. Каждому способу упорядочивания соответствует своя шкала.
Числовая шкала – самая мощная и привычная, позволяет
каждому объекту поставить в соответствие число, характеризующее его предпочтение для данной задачи и оперировать с оценками как с числами. Например, в соревновании по бегу победитель пробежал дистанцию за 9,98 сек., второй– за 10,01, третий–
за 10,12 сек. Мы можем сказать: на сколько секунд и во сколько
раз один спортсмен пробежал быстрее другого. Но для построения числовой шкалы требуется очень много информации об
объектах. Если заменить недостающую информацию предположениями, достоверность оценок снизится, поэтому на ранних
этапах, в условии отсутствия информации желательно пользоваться более слабыми шкалами.
Ранговая шкала упорядочивает все объекты. Объекты выстраиваются в список так, чтобы предыдущий объект был не менее предпочтителен, чем последующий. Поэтому именно эта
шкала чаще всего используется для экспертных оценок, но она
!
не позволяет определить, на сколько или во сколько раз один
объект предпочтительней другого. Например, на конкурсе красоты эксперты распределили места среди 10 девушек. Однако
утверждать, что победительница на 10% красивее второй девушки никто не берется.
Нестрогий порядок допускает одинаковый уровень предпочтения для нескольких объектов, разбиение множества на ряд
уровней (слоев, страт). Каждый уровень считается более предпочтительным, чем находящиеся ниже. Объекты из одного уровня
считаются одинаково предпочтительными. Для выбора лучшего
из них требуются дополнительные исследования. Например,
футбольные команды разбиты на высшую, первую, вторую и
т.д. лиги.
Частичный порядок позволяет определить предпочтение для
каждой пары объектов и установить, какая из них предпочтительней. Однако выбрать наилучший объект из всего множества в
этой шкале нельзя. Например, эксперты посчитали, что программный модуль A сложнее, чем модуль B, а B сложнее C. Но вполне
может оказаться, что, по мнению эксперта, С сложнее А.
Номинальная шкала – самая слабая. Множество разбивается
на группы схожих объектов. Все объекты в группе объявляются
одинаковыми с точки зрения решаемой задачи. Предпочтения
разных групп не определяются. Например, ранее разработанные
программные модули разбиты на три класса, исходя из трудоемкости их написания. Однако определить, от каких характеристик самих модулей зависит трудоемкость, не удалось.
Ниже представлены способ и соответствующая ему шкала
упорядочения множества.
Ñïîñîá
Êîëè÷åñòâåííàÿ îöåíêà
Ðàíæèðîâàíèå
Ñòðàòèôèêàöèÿ
Ïàðíûå ïðåäïî÷òåíèÿ
Êëàññèôèêàöèÿ
Øêàëà
×èñëîâàÿ
Ðàíãîâàÿ (Ñòðîãèé ïîðÿäîê)
Ðàíãîâàÿ (Íåñòðîãèé ïîðÿäîê)
×àñòè÷íûé ïîðÿäîê
Íîìèíàëüíàÿ
Обеспечение сопоставимости оценок в ранговой шкале. Повышение мощности шкалы дает дополнительные возможности
структуризации, но накладывает дополнительные условия на
результат. Классическими методами повышения объективности
ранговых оценок являются многоаспектное ранжирование и
!!
привлечение нескольких экспертов, имеющих различные мнения и опыт.
У каждого эксперта свои опыт и представления о том, что
нужно потребителю, поэтому их ранжировки будут различны.
Насколько эти ранжировки согласуются друг с другом? Как структурировать множество альтернатив в ситуации «разноголосицы»
суждений экспертов? Может ли вообще данная группа экспертов придти к согласованному решению?
Например, для сравнительной оценки функциональности
нескольких программных продуктов (ПП) используются ранговые оценки следующих характеристик1:
• пригодность (Suitability) – соответствие набора функций
ПП конкретным задачам;
• правильность (Accuracy) – правильность результатов вычислений и реакций системы;
• способность к взаимодействию (Interoperability) с другими
системами.
Результаты экспертизы показали, что ПП, занявшие высокие места в первой ранжировке, как правило, занимают места
ниже среднего в остальных ранжировках. Как сопоставить различные ранжировки и выбрать лучшую программу?
Если можно проранжировать сами признаки по степени их
значимости (например, в порядке: пригодность, способность к
взаимодействию, правильность), результирующую ранжировку
можно получить следующим образом. Сначала проранжировать
(отсортировать) программы по первой характеристике. Программы, схожие по первой характеристике, рассортировать по второй, а схожие по первой и второй – рассортировать по третьей
характеристике. Такое упорядочение, называемое лексографический порядок, позволяет построить единую ранжировку, учитывающую все исходные ранжировки. При этом предполагается, что
никакие преимущества ПП по младшим характеристикам не
компенсируют его недостатков по старшей характеристике.
Последнее предположение редко выполняется на практике.
Первое, что приходит на ум, заменить ранговые оценки числами.
Обозначим через Xij оценку i-го объекта j-м экспертом (или, в
случае многаспектного ранжирования, оценку объекта по j-й харак1
Характеристики функциональности взяты из ГОСТ Р ИСО 9126-93.
Информационная технология. Оценка программной продукции.
!"
теристике). Если мнения экспертов для нас равнозначны, общую
оценку i-го объекта вычислим как сумму его частных оценок:
Ri =
∑mj =1 X ij .
(1.1)
Для учета разной значимости экспертов (характеристик) каждому из них присвоим вес Wj. Тогда общая оценка примет вид
линейной свертки:
Ri =
∑mj =1W j X ij .
(1.2)
Чем большее число экспертов поставит высшие оценки объекту и чем значимее мнения этих экспертов, тем выше результирующая оценка.
На первый взгляд такой метод полностью соответствует здравому смыслу. Однако это не совсем так: существует строгое математическое доказательство1, что линейная свертка корректна
только тогда, когда все критерии попарно независимы по предпочтению (т.е. изменение предпочтения у одного эксперта не
повлечет изменения предпочтений у других экспертов). Кроме
того, если Xij заданы в ранговой шкале, нельзя предполагать, что
расстояния между соседними местами всегда одинаковые. И,
наконец, свертка нивелирует мнения экспертов, отдавая предпочтение средним «сереньким» объектам. Например, если два
эксперта расставили объекты a, b и c соответственно: (a, b, c) и
(c, b, a), линейная свертка отдаст предпочтение объекту b, хотя
ни один эксперт не назвал его лучшим.
Таким образом, простейшие методы применимы только в ограниченном числе случаев, когда предположения, положенные в
их основу, выполняются. Если эксперты дают числовые оценки,
удобной мерой их согласования является коэффициент корреляции. Он равен ±1, если последовательности линейно зависимы, и
близок к нулю для независимых последовательностей.
Английский математик и психолог Чарльз Эдвард Спирмен
предложил аналогичный коэффициент для ранжировок. Пусть
Ai и Bi – места i-го объекта в ранжировках экспертов А и B
соответственно.
RAB = 1 -
6
2
n
å (Ak - Bk )2 .
n(n - 1) k =1
(1.3)
1
Кини Р.Л., Райф Х. Принятие решений при многих критериях: предпочтения и замещения. – М.: Радио и связь, 1981.
!#
Выражение (1.3), получившее название коэффициент Спирмена, обладает свойствами, схожими с коэффициентом корреляции: оно равно единице, если ранжировки совпадают, и минус единице, если они противоположны. Если оно близко к нулю,
можно считать, что ранжировки независимы (не согласуются
друг с другом). Кроме того, RAB распределен асимптотически
нормально, с известными характеристиками. Следовательно, RAB
может быть использован для проверки статистических гипотез о
согласованности (взаимной зависимости) ранжировок.
Умение подсчитать меру близости между ранжировками позволит нам решить две задачи: оценить согласованность мнений
экспертов и подобрать ранжировку, наилучшим образом согласованную со всеми исходными ранжировками. Для оценки согласованности мнений подсчитаем среднее значение коэффициента Спирмена для всех пар ранжировок (Rср). Если оно
достаточно близко к единице, мнения согласованы, и их смело
можно использовать для формирования результирующего решения. Если Rср недостаточно большое (например, меньше 0,5), разногласия между мнениями столь высоки, что стоит подумать о
повторной экспертизе или использовании других методов оценки.
Наиболее корректным методом построения результирующей
ранжировки в настоящее время считается метод медианы Кемени1.
Сущность этого метода – поиск ранжировки, для которой сумма мер близости со всеми исходными ранжировками была бы
минимальной.
Являются ли рассмотренные величины R метриками? Для
ответа на этот вопрос рассмотрим представленное в табл. 1.2
сравнение свойств каждой из величин с требованиями к метрике.
Из табл. 1.2 видно, что полноценными метриками являются
только коэффициент Спирмена и медиана Кемени. В табл. 1.3
сведены методы согласования мнений экспертов.
Обеспечение сопоставимости оценок в номинальной шкале.
Основная задача при упорядочении объектов в номинальной шкале – правильно их назвать, поэтому основной метод обеспечения сопоставимости – классификация. Хорошая классификация
разбивает множество исследуемых объектов на непересекающиеся
подмножества, каждому из которых соответствует уникальная
1
Метод назван по имени автора – американского математика и экономиста, лауреата Нобелевской премии.
!$
Т а б л и ц а 1.2
Оценка соответствия характеристик близости требованиям к метрике
Òðåáîâàíèå
Îáúåêò
èçìåðåíèÿ
Èíòåðïðåòàöèÿ
Åäèíèöà
èçìåðåíèÿ
Îáúåêòèâíîñòü
ìåòîäà
Âîñïðîèçâîäèìîñòü ìåòîäà
Ëèíåéíàÿ
ñâåðòêà
Èññëåäóåìûé
îáúåêò
Îáùàÿ îöåíêà
îáúåêòà ïî ñîâîêóïíîñòè åãî
ñâîéñòâ
Íàçíà÷àåòñÿ
ïðîèçâîëüíî
Íèçêàÿ. Âåñà
ýêñïåðòîâ è çíà÷åíèÿ ñâîéñòâ
çàäàþòñÿ ïðîèçâîëüíî
Âåëè÷èíà
Êîýôôèöèåíò
Ñïèðìåíà
Ìíîæåñòâî
ðàíæèðîâîê
Ìåðà ñîãëàñîâàííîñòè
ðàíæèðîâîê
Ìåäèàíà
Êåìåíè
Ìíîæåñòâî
ðàíæèðîâîê
Ðàíæèðîâêà
ðåçóëüòàò ñîãëàñîâàíèÿ ÷àñòíûõ
ðàíæèðîâîê
Áåçðàçìåðíàÿ
Áåçðàçìåðíàÿ
âåëè÷èíà
âåëè÷èíà
Âûñîêàÿ. Ðàñ÷åò Âûñîêàÿ. Ðàçáðîñ
âåäåòñÿ ïî îäðåçóëüòàòîâ îïðåíîé è òîé æå
äåëÿåòñÿ òîëüêî
ôîðìóëå
ïîãðåøíîñòÿìè
ìåòîäîâ îïòèìèçàöèè
Òðåáóåòñÿ ñïåöè- Îäíîçíà÷íàÿ
Ïðàêòè÷åñêè
àëüíàÿ ìåòîäèêà âåëè÷èíà. Ðàñîäíîçíà÷íàÿ
îöåíêè çíà÷åíèé ÷åòû ïðîâîäÿòñÿ âåëè÷èíà
÷àñòíûõ õàðàêòå- ïî äåòåðìèíèðèñòèê íà êàæðîâàííîìó
äîì îáúåêòå
àëãîðèòìó
Т а б л и ц а 1.3
Методы согласования мнений экспертов
Ìåòîä
Êîíñåíñóñ
Ñóììà
ìåñò
Îïèñàíèå
Ýêñïåðòû
îáñóæäàþò
ðàíæèðîâêó äî òåõ ïîð,
ïîêà èì íå óäàñòñÿ óáåäèòü äðóã äðóãà è ïðèäòè ê åäèíîìó ìíåíèþ
Äëÿ êàæäîãî îáúåêòà
ñ÷èòàåòñÿ ñóììà ìåñò,
äàííûõ åìó ýêñïåðòàìè.
Îáúåêò, íàáðàâøèé ëó÷øóþ ñóììó ìåñò, îáúÿâëÿåòñÿ ëó÷øèì
Êîììåíòàðèé
Ïóòü òðóäîåìêèé è íå âñåãäà âîçìîæíûé. ×àñòî äåëî çàêàí÷èâàåòñÿ òåì, ÷òî îäèí ýêñïåðò äàâèò íà
îñòàëüíûõ, íàâÿçûâàÿ èì ñâîå
ìíåíèå
Ïðè ðàçíîðîäíîñòè ãðóïïû ýêñïåðòîâ ëåãêî ïîëó÷èòü ñèòóàöèþ,
êîãäà ëó÷øåå ìåñòî ïðèñóæäàåòñÿ
îáúåêòó-ñåðåäíÿ÷êó, ïîñòàâëåííîìó
áîëüøèíñòâîì ýêñïåðòîâ â ñåðåäèíó ñïèñêà. Êðîìå òîãî, ïðåäïîëàãàåòñÿ, ÷òî âñå ìåñòà ðàâíîóäàëåíû
äðóã îò äðóãà, ò.å. îáúåêò, çàíÿâøèé ïåðâîå ìåñòî, îòëè÷àåòñÿ îò
âòîðîãî îáúåêòà òàê æå, êàê âòîðîé
îò òðåòüåãî, è ò.ä.
!%
Продолжение
Ìåòîä
Ãîëîñîâàíèå
Ìåäèàíà
Êåìåíè
Îïèñàíèå
Îáúåêòû ðàñïîëàãàþòñÿ
â ñîîòâåòñòâèè ñ ÷èñëîì
îòäàííûõ çà íèõ ãîë îñîâ
Ñòðîèòñÿ ðàíæèðîâêà,
íàèáîëåå
áëèçêàÿ
ê
ïðåäúÿâëåííûì
Êîììåíòàðèé
Ôàêòè÷åñêè îòáðàñûâàþòñÿ ìíåíèÿ ýêñïåðòîâ, íå ñîãëàñíûõ ñ
áîëüøèíñòâîì
Ó÷èòûâàåòñÿ ìíåíèå âñåõ ýêñïåðòîâ. Äàåòñÿ îöåíêà ñîãëàñîâàííîñòè ãðóïïû ýêñïåðòîâ.
Òðåáóåòñÿ îïðåäåëåíèå ìåðû áëèçîñòè ìåæäó ðàíæèðîâêàìè è ìàòåìàòè÷åñêàÿ îáðàáîòêà ýêñïåðòíûõ îöåíîê
комбинация значений классифицирующих признаков. Используя ее, мы можем отнести оцениваемый объект к одному из типов, применив в качестве правила отнесения набор значений.
Например, множество всех программных модулей разобьем по
признакам: «язык, на котором написан модуль», «функция модуля», «используемые типовые приемы программирования». В
каждом классе окажутся относительно схожие модули, которые
можно сравнивать по затраченному времени, искусству написания кода и т.д.
Мощным средством структуризации системы объектов и характеристик является построение иерархии их отношений. Приписывая родительскому объекту все свойства, одинаковые у его
потомков, мы избавляемся от необходимости многократно описывать одни и те же свойства для различных объектов (принцип
наследования).
Так как номинальная шкала не имеет отношения «ближедальше», погрешностью можно считать неверное отнесение
объекта к какому-то другому классу (ошибка первого рода), или
неверное отнесение объекта из другого класса в данный (ошибка
второго рода). В качестве доверительной вероятности выступают вероятности этих событий.
1.4. Îáåñïå÷åíèå åäèíñòâà òåðìèíîëîãèè
Вспомним легенду о строительстве Вавилонской башни. Люди
задумали построить башню до небес и таким образом добраться
до Бога. Богу это не понравилось. Он смешал языки, люди перестали понимать друг друга, и амбициозный проект провалился.
!&
Как обеспечить однозначность понимания для всех участников совместной работы?
Единство терминологии – состояние, при котором все
участники одинаково понимают и используют все термины,
связанные с данным видом деятельности.
Простейший способ обеспечения единства терминологии –
договориться об использовании терминов. Давайте запишем все
используемые термины в специальный справочник и договоримся применять только их. Тогда если возникает необходимость использования нового термина, мы сначала сопоставим
его с терминами, уже записанными в справочнике. Если аналогов в справочнике нет (т.е. термин действительно новый), внесем его в справочник и только тогда будем использовать. Для
лучшего понимания кроме самого термина нам может понадобиться ввести в справочник его определение или пояснение, а
также отразить взаимоотношения с другими терминами.
Нормативные документы, содержащие справочники разрешенных к применению терминов, называются терминологическими стандартами. В табл. 1.4 приведены виды терминологических стандартов в зависимости от подробности описания.
Т а б л и ц а 1.4
Виды терминологических стандартов
Âèä
Ãëîññàðèé
Ñòàíäàðò «Òåðìèíû è îïðåäåëåíèÿ»
Êîäèôèêàòîð
Ñîäåðæàíèå
Ïåðå÷åíü òåðìèíîâ, óïîðÿäî÷åííûé ïî òåìàì,
àëôàâèòó, èëè â ïîðÿäêå
óïîìèíàíèÿ. Èíîãäà óêàçûâàþòñÿ ññûëêè íà ñòðàíèöû, íà êîòîðûõ ïîÿñíÿþòñÿ èëè óïîìèíàþòñÿ
òåðìèíû
Òåðìèíû, èõ îïðåäåëåíèÿ, ñîîòíîøåíèÿ ìåæäó
òåðìèíàìè, ïðàâèëà è
ïîÿñíåíèÿ ïî ïðèìåíåíèþ è èíòåðïðåòàöèè
òåðìèíîëîãèè
Ïåðå÷åíü òåðìèíîâ ñ óêàçàíèåì êîäîâ
Îáëàñòü ïðèìåíåíèÿ
Ïîèñê äàííîãî òåðìèíà â
èñòî÷íèêå
èíôîðìàöèè
(íàïðèìåð, â êíèãå)
Ñòàíäàðò,
óñòàíàâëèâàþùèé òåðìèíîëîãèþ â îïðåäåëåííîé
ïðåäìåòíîé
îáëàñòè èëè ñèñòåìå ñòàíäàðòîâ
Êîäèðîâàíèå èíôîðì àöèè
!'
Продолжение
Âèä
Êëàññèôèêàòîð
Òåçàóðóñ
Ñîäåðæàíèå
Ïåðå÷åíü íàçâàíèé ïðåäìåòîâ ñ óêàçàíèåì èõ êîäîâ, óïîðÿäî÷åííûé ïî
èåðàðõè÷åñêîìó îòíîøåíèþ
«îáùåå-÷àñòíîå».
Êðîìå ïðÿìîãî óêàçàíèÿ
êëàññà èíîãäà ïðèâîäÿòñÿ
îïèñàíèÿ êëàññîâ è ïðàâèëà îòíåñåíèÿ îáúåêòîâ
ê êëàññàì
Íàèáîëåå ïîäðîáíûé òåðìèíîëîãè÷åñêèé ñïðàâî÷íèê. Êðîìå íàçâàíèÿ òåðìèíà ïðèâîäèòñÿ åãî îïðåäåëåíèå, à òàêæå îòíîøåíèÿ ê äðóãèì òåðìèíàì
è ïîíÿòèÿì
Îáëàñòü ïðèìåíåíèÿ
Êîäèðîâàíèå è êëàññèôèêàöèÿ èíôîðìàöèè, óñòàíîâëåíèå îòíîøåíèÿ «îáùåå-÷àñòíîå»,
îáåñïå÷èâàþùåãî
àãðåãèðîâàíèå
èíôîðìàöèè è ðàñïðîñòðàíåíèå îáùèõ òðåáîâàíèé íà ÷àñòíûå ñëó÷àè
Ôîðìèðîâàíèå è ôèêñàöèÿ
ñèñòåìû ïîíÿòèé ïðåäìåòíîé îáëàñòè, îáåñïå÷åíèå
åäèíñòâà ïîíèìàíèÿ òåêñòîâ
Обеспечение единства терминологии в системе управления.
Трудно представить себе последствия путаницы терминологии в
системе управления большого предприятия. Чтобы такие сбойные ситуации не возникали, в системе управления предприятия
ведутся специальные терминологические справочники. При необходимости на предприятии выпускается специальный документ: стандарт предприятия (СТП) «Термины и определения».
Управление современным предприятием невозможно без
использования автоматизированных информационных систем,
обеспечивающих оперативность и четкость ведения документации, всестороннюю продуманность и обоснованность принимаемых решений. При разработке таких систем единство терминологии является ключевым моментом их пригодности и
эффективности.
Мощным средством обеспечения единства терминологии в
автоматизированных системах является грамотное конструирование и использование реляционных баз данных. При разработке такой базы в предметной области выделяются объекты и формируются справочники объектов. Система организуется так, что
во всей другой информации, хранящейся в базе данных, могут
упоминаться только объекты, названия которых имеются в справочниках. При попытке удалить объект из справочника система
"
проверяет, нет ли в базе данных информации, связанной с этим
объектом и запрещает удаление объекта без удаления или соответствующего изменения связанной с ним информации. Таким
образом обеспечивается целостность информации, хранящейся в
базе данных.
Обеспечение единства терминологии при разработке программного продукта. При разработке сложного программного продукта большой группой специалистов крайне важно, чтобы все они
одинаково понимали используемые термины. Для этого в комплекты средств разработки программ включаются специальные
средства формирования и ведения терминологического справочника (словаря) разрабатываемого продукта.
1.5. Îáåñïå÷åíèå ñïåöèàëèçàöèè ïðîèçâîäñòâà
è âçàèìîçàìåíÿåìîñòè
С появлением станков и машин для производства товаров
люди научились изготавливать детали с достаточно точными,
наперед заданными характеристиками. Собирать одинаковые по
конструкции изделия из однотипных деталей и узлов гораздо
проще, чем подгонять каждую деталь для каждой машины в отдельности. Появилась возможность заранее продумать особенности взаимодействия всех узлов и деталей при работе машины,
выбрать оптимальные характеристики деталей и заложить их в
чертежи и стандарты. Если детали и узлы соответствуют стандарту, можно быть уверенными, что собранная из них машина
будет работать правильно.
Изготовитель сложной машины может раздать заказы на отдельные узлы и детали субподрядчикам. Изготовители отдельных узлов, имея дело с однородной продукцией, могут специализировать свое производство1 (например, применить мощные
прессы и штампы, автоматизировать производство и контроль
1
Способ организации производства, при котором производители кооперируются при создании сложной продукции и специализируются для повышения эффективности однородной продукции, называется разделением
труда. Разделение труда играет важнейшую роль в развитии человеческой
цивилизации, начиная с разделения племен на скотоводов и земледельцев.
В настоящее время умение людей различных специальностей совместно работать является определяющим фактором успешности проекта.
"
продукции) и тем самым сократить стоимость единицы продукции с одновременным повышением ее качества.
Одинаковость характеристик деталей позволяет решить еще
одну важную задачу: облегчение ремонта сложных машин. Если
деталь или узел вышли из строя, мы можем просто заменить их
новыми с точно такими же характеристиками. После такой замены, потребуется минимальная настройка, чтобы машина работала как до аварии. Значит, детали и машины обладают свойством, которое называется взаимозаменяемость.
По своей сложности, важности взаимодействия между составляющими их частями компьютерные программы мало чем
отличаются от современных машин, поэтому методы, первоначально разработанные для машиностроения, широко применяются в программировании.
1.5.1. Óíèôèêàöèÿ
Внедрение машинного способа производства существенно
сократило затраты и позволило организовать массовый выпуск
однотипных изделий. Однако рынок требует разнообразия. Если
на нем появляется много одинакового товара, происходит насыщение и цены на такой товар падают.1 Производителям приходится постоянно выбрасывать на рынок новые товары с более
привлекательными для потребителя свойствами.
Как разрешить противоречие между удобством производства
однотипных изделий и необходимостью постоянно расширять
разнообразие предлагаемых товаров? Даже у самого нового, оригинального изделия найдутся функции, схожие с функциями
других изделий. А что, если попробовать реализовать одинаковые функции с помощью одинаковых деталей и узлов?
Для этого нам придется проанализировать функции множества изделий, выбрать одинаковые функции и разработать для
них типовые детали и узлы. При разработке типовых узлов мы
должны учесть требования всех мест их будущего применения.
1
Согласно современным экономическим исследованиям, основным
фактором прибыли на насыщенном товарами рынке является новизна товара. Рыночная цена давно производимого товара практически всегда равна его себестоимости. Прибыли выпуск такого товара не принесет.
"
Это позволит расширить объемы выпуска и получить эффект от
специализации производства. Если мы хотим получить эффект
в течение длительного срока, нам придется учитывать не только
требования существующих типов изделий, но и тенденции их
развития. Такой метод проектирования получил название унификация, а детали, узлы и модули, разработанные в результате
унификации, – унифицированные изделия.
Разработка унифицированных изделий требует значительно
больших затрат, чем компонент для отдельной машины. Нам
придется провести системный анализ требований. Из-за их разнообразия часть требований унифицированного изделия могут
оказаться излишними в некоторых конкретных применениях.
Чтобы изделие «жило» долго, нам придется тщательно продумать
технологию его производства и использовать самые современные
технические решения. Однако эффект от умелого применения
унификации, как правило, с лихвой превышает дополнительные затраты.
В большинстве современных изделий, будь то дома, машины или компьютерные программы, широко используются унифицированные детали, узлы и модули. Искусство проектирования новой продукции с максимально привлекательными для
потребителя свойствами во многом определяется умением автора широко применять унифицированные изделия.
Каждый раз, решая проблему, использовать унифицированное изделие или разработать новое, проектировщик должен оценить преимущества и недостатки каждого варианта решения. Для
наглядности выпишем характеристики каждого решения на отдельном листе бумаги. Разделим листы на четыре части (табл. 1.5
и 1.6). В верхней левой части запишем преимущества данного
решения. В правой части – его недостатки. В нижней левой
части укажем возможности, которые открывает выбор данного
решения в будущем, а справа – угрозы, связанные с таким выбором. Такой способ представления получил название SWOTанализ (по заглавным буквам английских слов: Seniority – преимущества, достоинства; Wrongs – недостатки; Opportunities –
возможности; Threats – угрозы), а соответствующие таблицы –
SWOT-таблицы.
В табл. 1.5 и 1.6 приведен пример SWOT-анализа для альтернативы: применять унифицированное или разрабатывать новое изделие.
"!
Т а б л и ц а 1.5
SWOT-таблица применения унифицированного изделия
Äîñòîèíñòâà
Îòïàäàåò íåîáõîäèìîñòü ðàçðàáîòêè íîâîãî èçäåëèÿ.
Óíèôèöèðîâàííîå èçäåëèå ïðîâåðåíî ïðàêòèêîé, â íåì óñòðàíåíî áîëüøèíñòâî íåäî÷åòîâ è
îøèáîê. Åãî íàäåæíîñòü è êà÷åñòâî, êàê ïðàâèëî, âûøå, ÷åì ó
âíîâü ðàçðàáîòàííîãî
Âîçìîæíîñòè
Ìîæíî ñîêðàòèòü âðåìÿ è ñòîèìîñòü ðàçðàáîòêè è, îäíîâðåìåííî, ïîâûñèòü åå êà÷åñòâî.
Ìîæíî ïîâûñèòü ïðèâëåêàòåëüíîñòü èçäåëèÿ çà ñ÷åò ññûëêè íà
íàäåæíîñòü èñïîëüçóåìûõ óçëîâ.
Âîçìîæíîñòü ïîñëåäóþùåé ìîäåðíèçàöèè èçäåëèÿ «ïî ÷àñòÿì»
çà ñ÷åò çàìåíû óñòàðåâøåãî óçëà
íà ñîâðåìåííûé
Íåäîñòàòêè
Ñâîéñòâà óíèôèöèðîâàííîãî èçäåëèÿ «íå ñîâñåì òå, ÷òî íóæíî».
Òðåáóåòñÿ ïåðåñìîòð âñåé êîíöåïöèè ðàçðàáàòûâàåìîãî èçäåëèÿ.
×àñòü ñâîéñòâ, çàëîæåííûõ â óíèôèöèðîâàííîå èçäåëèå íå íóæíà.
Òðåáóþòñÿ äîïîëíèòåëüíûå óñèëèÿ
äëÿ ñîïðÿæåíèÿ âíîâü ðàçðàáàòûâàåìûõ óçëîâ ñ óíèôèöèðîâàííûì
èçäåëèåì (â òîì ÷èñëå, ñâÿçàííûå
ñî ñâîéñòâàìè, êîòîðûå íå èñïîëüçóþòñÿ â íàøåì èçäåëèè)
Óãðîçû
Èäåîëîãèÿ, çàëîæåííàÿ â óíèôèöèðîâàííûå èçäåëèÿ, ñîâîêóïíîñòü
èõ ñâîéñòâ äèêòóþò èõ ïðèìåíåíèå,
êîòîðîå ìîæåò ñóùåñòâåííî îòëè÷àòüñÿ îò æåëàåìîãî. Ýòî ìîæåò
ñèëüíî èñêàçèòü ïåðâîíà÷àëüíûé
çàìûñåë ðàçðàáàòûâàåìîãî èçäåëèÿ
Т а б л и ц а 1.6
SWOT-таблица разработки нового изделия
Äîñòîèíñòâà
Íåäîñòàòêè
Âíîâü ðàçðàáîòàííîå èçäåëèå ìîæåò Ñðîêè è òðóäîåìêîñòü ðàçðàáîòêè
âûïîëíÿòü ôóíêöèè, êîòîðûå íå ñóùåñòâåííî ïîâûøàþòñÿ
ìîæåò âûïîëíèòü óíèôèö èðîâàííîå.
Íå íàäî ïîêóïàòü óíèôèöèðîâàííûå
èçäåëèÿ èëè ëèöåíçèþ íà èõ èñïîëüçîâàíèå.
Åñòü âîçìîæíîñòü ïðîäóìàòü âñþ
êîíñòðóêöèþ èçäåëèÿ «îò íà÷àëà äî
êîíöà», íå îãëÿäûâàÿñü íà ñóùåñòâóþùèå ðåàëèçàöèè.
Ó âíîâü ðàçðàáîòàííîãî èçäåëèÿ íåò
íåíóæíûõ ñâîéñòâ.
Ìîæíî äîáèòüñÿ áîëüøåé ñîãëàñîâàííîñòè âíîâü ðàçðàáîòàííîãî èçäåëèÿ ñ äðóãèìè ÷àñòÿìè ìàøèíû
""
Продолжение
Âîçìîæíîñòè
Âîçìîæíîñòü ðàçðàáîòêè ïðèíöèïèàëüíî íîâûõ òîâàðîâ, èìåþùèõ îðèãèíàëüíûå ïîòðåáèòåëüñêèå ñâîéñòâà,
êîìïîíåíòû è êîìïîíîâêó.
Ìîæíî ëó÷øå ó÷åñòü èíòåðåñû ïîòðåáèòåëÿ.
Âîçìîæíîñòü
ïðîäåìîíñòðèðîâàòü
ñâîé ïîòåíöèàë êàê ðàçðàáîò÷èêà
ïðè ðåøåíèè ñîïîñòàâèìûõ çàäà÷
Óãðîçû
Ñëîæíîñòü ðàçðàáîòêè «ñ íóëÿ».
Ðàçðàáîòêà ìîæåò ïðåâûñèòü âîçìîæíîñòè ðàçðàáîò÷èêà è íå áûòü
äîâåäåíà äî êîíöà.
Âåëèê ðèñê âûÿâëåíèÿ îøèáîê è
íåó÷òåííûõ ñèòóàöèé ïðè èñïîëüçîâàíèè èçäåëèÿ.
 ñâÿçè ñ óâåëè÷åíèåì ñòîèìîñòè
è âðåìåíè ðàçðàáîòêè ìû íå ñìîæåì âîñïîëüçîâàòüñÿ áëàãîïðèÿòíîé êîíúþíêòóðîé íà ðûíêå.
Îáúåìû ïðîäàæ óïàäóò
Сопоставляя SWOT-таблицы вариантов, разработчик выбирает
вариант, для которого достоинства и возможности выглядят привлекательней, а недостатков и угроз меньше, чем у остальных.
1.5.2. Ìîäóëüíûé ïðèíöèï ïðîãðàììèðîâàíèÿ
Рассмотрим, как решаются проблемы совместимости и унификации на примере, близком каждому программисту: обеспечения совместимости программных модулей.
Такая проблема возникает в связи с тем, что пока программист пишет короткие и достаточно простые программы, он без
труда может проследить все связи и все изменения переменных
величин. Однако время простых программ прошло: современный программный комплекс оперирует с тысячами параметров
и массивов. Размеры программного кода составляют десятки, а
иногда и сотни мегабайт1.
Рассмотрим несколько правил быстрого и эффективного создания больших программ:
1) к разработке программ привлекается не один, а целая команда программистов (кооперация);
2) программа разбивается на относительно независимые части (модули), каждая из которых должна выполнять определенную функцию (специализация);
3) обеспечивается совместимость программных модулей.
1
Например, размер кода операционной системы Windows XP составляет величину порядка 50 млн строк.
"#
Следовательно, разбиение программы на модули – типичная задача обеспечения совместимости. А если модули используются многократно, они должны разрабатываться как унифицированные изделия.
Рассмотрим последовательность реализации модульного
принципа программирования. В настоящее время используются
два подхода к декомпозиции (разбиению сложной задачи на более
простые)1. Исторически первым сложился алгоритмический подход, согласно которому решение задачи представляется как процесс преобразования информации от входных данных к искомому результату. Декомпозиция заключается в разбиении этого
процесса на ряд более простых подпроцессов, связи между которыми четко определены и легко контролируются. Более современным является объектный подход. В соответствии с ним
строится объектная модель предметной области. Каждый объект
общей модели является моделью объекта реального мира. Объекты
наделяются свойствами и методами, а общая модель – событиями.
Таким способом повышается наглядность и адекватность модели.
Решение ищется как результат взаимодействия объектов.
Обратим внимание на различия и сходства алгоритмического
и объектного подходов.
1. Разбиение на относительно простые и самостоятельные
фрагменты (модули). Этот шаг необходим при обоих подходах.
Критериями качества разбиения являются:
а) законченность выделяемых модулей. Каждый модуль должен до конца решать какую-то, пусть маленькую задачу в алгоритмическом подходе или описывать поведение какого-либо
объекта в объектном подходе;
б) посильность программирования. Размеры и сложность модуля должны быть такими, чтобы один программист в реальные
сроки справился с его написанием и отладкой;
в) минимум связей с остальными модулями. Чем меньше зависит модуль от остальной части программы, и чем меньше осталь1
В настоящее время нередко применяется и комбинированный подход – выделяются объекты (Entities), они представляют входную и выходную информацию. А затем анализируются процессы преобразования информации, в которых выделяются типовые модули (Actions), которые проектируются так, чтобы они могли производить действия над объектами
разного типа. Этим они отличаются от стандартно понимаемых методов в
объектном подходе.
"$
ные модули зависят от него, тем меньше проблем возникнет при
их совместной отладке. Вот тут и проявляются преимущества
объектного подхода. Ведь объекты изначально являются самостоятельными сущностями со своей «внутренней жизнью» и относительно небольшим набором внешних характеристик;
г) проверяемость входных данных и результатов выполнения
модуля. К правильности и полноте входных данных должны быть
сформулированы четкие требования, выполнение которых должно быть проверено на входе модуля. Ситуации получения неверных данных должны быть учтены и обработаны. Решая определенную задачу до конца, модуль должен выдавать результаты,
правильность которых также можно логически проверить. При
алгоритмическом подходе придется сформулировать требования,
определяющие, что такое правильная входная информация для
каждого подпроцесса. В объектном подходе это требования к
диапазонам значений и допустимым соотношениям внешних
свойств объекта.
2. Формирование требований к модулям. Для каждой конкретной задачи (варианта использования), выполняемой программой, при алгоритмическом подходе должна существовать цепочка
последовательно выполняемых модулей, полностью решающая
данную задачу. При объектном подходе для каждой задачи должна существовать последовательность взаимодействия объектов,
приводящая к желаемому результату. Если объекты выделены
удачно, т.е. соответствуют сущностям реального мира, то многообразие их взаимодействия хорошо отражает проблемы этого
мира. Таким образом, удачно реализованный объектный подход
позволяет получить программу, решающую большинство задач
реального мира, в том числе и не осознанных разработчиками
на момент постановки задачи на программирование. В простейшем случае цепочка может состоять из одного модуля. При алгоритмическом подходе требования к модулям формируются по
принципу «обратной волны»:
• требования к результату решения задачи являются требованиями к последнему модулю в цепочке, решающей эту задачу;
• часть требований могут обеспечить входная информация и
условия выполнения модуля, остальное формулируется как требования к предыдущим и обеспечивающим модулям;
• анализируется, какая информация и инструментарий необходимы модулю, чтобы обеспечить предъявленные требования.
"%
Данный анализ проводится последовательно по всем модулям от конца к началу. Если модуль участвует в нескольких цепочках, требования к нему анализируются на совместимость и
объединяются. Если требования к модулю не совместимы, необходимо пересмотреть модульную структуру программы.
3. Формирование совокупности требований к каждому модулю. При объектном подходе требования к модулям формируются исходя из максимальной адекватности программного объекта
объекту реального мира: чем лучше будут смоделированы объекты, тем больше задач можно правильно решить, используя конкретную объектную модель.
4. Разработка межмодульного интерфейса – правила вызова
модулей, передачи им параметров и данных. Информация, необходимая для работы большинства модулей (например, отражающая внешнее окружение моделируемого мира, состояние взаимодействия объектов и т.д.), организуется в виде общих
областей, глобальных переменных, массивов или баз данных.
5. Формирование заданий на программирование. Только после
этого шага стоит приступать к программной реализации модулей.
Процесс выделения модулей и формирования требований к
ним проходит в несколько итераций. От качества выделения
модулей зависят трудоемкость и реализуемость программного
продукта, сроки и качество его реализации.
6. Комплексная отладка. Она проводится после написания
отдельных модулей. В ходе отладки проверяется возможность
совместной работы модулей, правильность решения всех задач
программного продукта.
1.5.3. Óíèôèêàöèÿ èíòåðôåéñîâ
Применение методов стандартизации существенно ускоряет
научно-технический прогресс. Однако в самой идее стандартизации заложено противоречие. Действительно, развитие технологии, появление принципиально новых решений подразумевает
изменение (иногда кардинальное) характеристик изделий. Стандарты, устанавливая требования к этим характеристикам, фактически тормозят прогресс. Как разрешить это противоречие?
Как известно, далеко не все характеристики деталей, узлов
или модулей влияют на их взаимодействие в компьютере (программе). Для внешнего окружения узла часто не важно, как вы"&
полняются нужные функции внутри него, какие принципы действия и алгоритмы в нем используются. Главное, чтобы все
функции узла выполнялись правильно в условиях, которые обеспечивает машина.
Воспользуемся этим свойством и разделим все характеристики узлов (модулей) на характеристики, влияющие и не влияющие на их внешнее поведение. Назовем первые из них характеристиками интерфейса. При разработке стандартов будем
устанавливать требования только к характеристикам интерфейса. Таким образом, мы обеспечим взаимозаменяемость узлов и
дадим простор разработчикам для создания все более совершенных изделий1.
Использование методов стандартизации при формировании единого информационного пространства. В качестве примера использования стандартизации интерфейсов рассмотрим проблему организации единого информационного пространства – организации
доступа к информации в компьютерных сетях, состоящих из разных компьютеров, сетевого оборудования и средств связи, работающих под различными операционными системами.
Доступность необходимой информации, возможность обмена своими идеями и мнениями – важнейшее условие формирования гражданского общества.
Доступ к информационным ресурсам должен быть быстрым,
свободным и защищенным от искажений при обмене информацией. В условиях динамически развивающейся экономики и насыщенного товарами рынка наличие такого доступа становится
важнейшим конкурентным преимуществом как отдельных предприятий, так и страны в целом.
Потребность в широком, ничем не затрудненном, но в то же
время защищенном от искажений и несанкционированного использования обмене информацией, является важнейшей потребностью общества в настоящее время.
1
Если вы загляните в корпус современного компьютера, то увидите
практически пустую коробку. Это следствие бурного технического прогресса в области микроэлектроники и последовательного выполнения принципа стандартизации интерфейсов. Во времена, когда были приняты эти
стандарты, размеры и тепловые характеристики компьютерных модулей
требовали гораздо больших размеров корпуса и разъемов. Наличие стандартов на интерфейс позволяет заменять (например, обновлять) только те
комплектующие компьютера, которые вы считаете нужным.
"'
Концепция единого информационного пространства. Для удовлетворения этой потребности желательно объединить информационные ресурсы, необходимые для решения перечисленного комплекса задач, а также информационные технологии поиска, доступа
и анализа данных в единое информационное пространство.
Единое информационное пространство – совокупность информационных ресурсов, технологий их формирования и использования, средств доступа и телекоммуникаций, обеспечивающая информационное взаимодействие организаций и
граждан, а также удовлетворение их информационных потребностей.
Компонентами единого информационного пространства являются:
информационные ресурсы – информация, организационные
структуры и технологии, обеспечивающие полноту, достоверность и актуальность информации, а также организующие доступ к этой информации;
информационно-коммуникационные системы и сети – комплексы технических средств и технологий, организационные структуры и нормативная база, обеспечивающие доступ к информационным ресурсам и обмен информацией по единым принципам
и правилам.
Исторически сложилось так, что пользователи, желающие
свободно обмениваться информацией, используют различные
технические средства и программное обеспечение. В связи с этим
для создания единого информационного пространства необходимо решить сложнейшую техническую задачу – организовать
взаимодействие вычислительных и информационных систем,
использующих разнородное оборудование, разные технические
и организационные решения, работающих с разными операционными системами.
Открытые информационные системы – системы, реализующие открытые (не являющиеся тайной для пользователей) спецификации (стандарты) на интерфейсы, службы и форматы данных, достаточные для того, чтобы обеспечить:
• мобильность (возможность переноса) приложений1 на различные программно-аппаратные платформы;
1
Приложение – пользовательская программа, написанная в соответствии с установленными требованиями.
#
• интероперабельность (возможность совместной работы) нескольких приложений на локальных и удаленных платформах;
• мобильность пользователей – стиль взаимодействия с пользователями, обеспечивающий им максимально удобный переход
от системы к системе.
Последовательно рассмотрим требования к системе, необходимые для того, чтобы она имела перечисленные свойства.
Прежде всего информация передается в виде электрических
сигналов. Поэтому чтобы устройства могли работать вместе и
«понимали» друг друга, необходимо сформулировать требования к электрическим характеристикам сигналов (амплитуде,
форме, частоте, длительности фронтов и т.д.). Кроме того, нужно выбрать правила кодирования. Например, тоновый сигнал
высокой частоты соответствует единице, а низкочастотный –
нулю.
Достаточно ли перечисленных требований? Очевидно, нет.
Ведь так мы сможем только передать последовательность нулей
и единиц. Чтобы передать данные, нам нужно «расставить знаки препинания» (разделить слова) и как-то маркировать начала
и концы передаваемых данных. Затем наша система должна
выбрать канал, по которому будут переданы данные, и инициировать передачу данных.
При передаче данные могут исказиться, поэтому после передачи их нужно проверить, а при необходимости устранить
искажения. Чтобы иметь такую возможность, в данные заранее
придется включить избыточную информацию (например, контрольную сумму).
Для того чтобы передача данных прошла корректно, мы должны договориться о том, как маркировать данные, как выбирать канал и передавать информацию, как проверять корректность данных и исправлять ошибки.
Источник и потребитель данных могут находиться в одном
компьютере, а могут и в разных. Во втором случае для доставки
данных потребителю нужно выбрать маршрут. Система, связывающая компьютеры, должна уметь анализировать свою структуру, выбирать последовательность устройств, через которые
данные дойдут до потребителя. Образно говоря, передаваемые
данные нужно положить в конверт, написав на нем адрес получателя, и отнести на «почту». «Почта» определяет маршрут и
доставляет конверт получателю. Чтобы наша «почта» работала
#
правильно и надежно, необходимо договориться о правилах адресации всех возможных источников и получателей данных,
а также о правилах записи маршрута.
Наше «письмо» начало путешествовать по системе. Когда оно
придет на промежуточную станцию, нужно проверить, правильно ли оно передано, не исказились ли передаваемые данные и
является ли эта станция получателем. Если это только промежуточная станция, «письмо» отправляется на следующую станцию,
указанную в маршруте. Правила проверки и передачи данных
по сети должны быть одинаковыми вне зависимости от конфигурации устройств, составляющих открытую систему.
Итак, данные достигли адресата. Но их еще рано передавать
в пользовательское приложение. Дело в том, что для удобства
пересылки объемные данные обычно упаковывают в несколько
«конвертов». Полученные данные обретут смысл для приложения (т.е. превратятся в информацию) только тогда, когда соберется полный набор данных (например, приложение должно
получить графический объект и нужно подождать, пока будет
получено все описание объекта). Правила формирования целостных наборов данных в зависимости от смысла запрашиваемой
приложением информации должны быть заданы и одинаковы
для всех устройств открытой системы.
Чтобы приложение могло воспринять полученную информацию, данные должны быть представлены в нужном формате.
Перечень разрешенных форматов и правила преобразования
одних форматов в другие должны быть заложены в системное
программное обеспечение открытой системы.
Наконец, последний (внешний) уровень требований – правила интерпретации запросов приложения. Система должна понять, что требуется приложению, откуда нужно получить информацию и организовать всю цепочку пересылок, описанных
выше.
Таким образом, мы получили целую систему требований к
нашей открытой системе. Отметим, что требования как бы расслаиваются на уровни: на низшем уровне мы имеем дело с электрическими сигналами, выше – с данными, и только на самых
высоких уровнях – с информацией. Более высокие уровни используют низшие как функции. При этом взаимодействовать
могут только соседние уровни (более высокие уровни просто
«не видят» функции уровней ниже следующего).
#
Для более высоких уровней не важно, как реализованы низшие уровни. Главное, чтобы устройства и программы системы
были совместимы на каждом уровне в отдельности, а предыдущий уровень реализовал все функции, необходимые следующему. Такой подход позволяет разделить клубок взаимообусловленных требований на относительно независимые наборы
требований к каждому уровню.
Базовая семиуровневая эталонная модель открытой системы,
имеющая статус международного стандарта ИСО 7498-1-93, представлена в табл. 1.7. Требования на каждом уровне оформляются в виде стандартов. При этом различные технические и программные решения для одного и того же уровня могут быть
оформлены в виде нескольких стандартов. Разработчик открытой системы сам может подобрать стандарты для каждого уровня. Совокупность взаимно совместимых стандартов, устанавливающих требования к открытой системе, называется профилем
взаимодействия открытой системы.
Т а б л и ц а 1.7
Базовая семиуровневая эталонная модель открытой системы
Ìåæìàøèííîå âçàèìîäåéñòâèå
Íîìåð
Ñîäåðæàíèå
Îïðåäåëÿþòñÿ ïàðàìåòðû ñèãíàëîâ è
ìåòîäû èõ êîäèðîâàíèÿ/äåêîäèðîâàíèÿ
Êàíàëüíûé
Ãðóïïà ñèãíàëîâ îôîðìëÿåòñÿ êàê ñîîáùåíèå. Îðãàíèçóåòñÿ ïåðåäà÷à ñîîáùåíèÿ ïî êàíàëó (íàçíà÷àåòñÿ êàíàë, ïðîâåðÿþòñÿ è èñïðàâëÿþòñÿ îøèáêè ïåðåäà÷è)
Ïðîêëàäûâàåòñÿ ìàðøðóò ïåðåäà÷è äàííûõ îò ïîñòàâùèêà ê ïîëó÷àòåëþ
Óïðàâëåíèå ïåðåäà÷åé äàííûõ ïî âûáðàííîìó ìàðøðóòó. (Îñóùåñòâëÿåòñÿ
ïåðåäà÷à ïàêåòà äàííûõ, íà êàæäîé «ïðîìåæóòî÷íîé ñòàíöèè» àíàëèçèðóåòñÿ öåëîñòíîñòü è íåèñêàæåííîñòü äàííûõ, ïðè
íåîáõîäèìîñòè óñòðàíÿþòñÿ îøèáêè, âîçíèêøèå ïðè ïåðåäà÷å ïàêåòà)
1
2
3
Èñòî÷íèê
ïîëó÷àòåëü
Óðîâåíü
Ôèçè÷åñêèé
Ñåòåâîé
Òðàíñïîðòíûé
4
#!
Продолжение
Ïîëüçîâàòåëüñêèå ôóíêöèè
Íîìåð
Óðîâåíü
Ñåàíñîâûé
Ñîäåðæàíèå
Îðãàíèçàöèÿ ïåðåäà÷è âñåõ äàííûõ, íåîáõîäèìûõ äëÿ ðåàëèçàöèè ñåàíñà (ïðåâðàùåíèå äàííûõ â èíôîðìàöèþ)
Ïðåäñòàâëåíèå äàííûõ
Ïðèêëàäíîé
(ïîëüçîâàòåëüñêèé)
Ïðåîáðàçîâàíèå äàííûõ ê âèäó, íåîáõîäèìîìó äëÿ ïîëüçîâàòåëüñêîãî ïðèëîæåíèÿ
Ðåàëèçàöèÿ ïîëüçîâàòåëüñêèõ ôóíêöèé
5
6
7
Кроме стандартов требований в профиль входят основополагающие, терминологические и распорядительные стандарты,
а также стандарты на методы тестирования и испытаний. Таким
образом, профиль является целостной системой стандартов, устанавливающей требования к целому классу открытых систем,
предназначенных для решения определенного круга задач.
Правительства многих стран разрабатывают национальные
профили систем для государственных органов GOSIP (Government
Open System Interconnection Profile). В России также разработан
Государственный профиль взаимосвязи открытых систем[33].
1.6. Èñïîëüçîâàíèå ñòàíäàðòîâ äëÿ îöåíêè
êà÷åñòâà ïðîãðàììíîãî ïðîäóêòà
В условиях насыщенности рынка программных продуктов и
жесткой конкуренции на этом рынке качество становится важнейшим свойством программы. Для потребителя от качества
программы зависят сложность ее внедрения и эффективность
использования. Как показывает опыт, общие затраты на внедрение программы в два–шесть раз превышают стоимость ее
лицензии. В связи с этим при выборе программы для внедрения
в достаточно широком диапазоне цен именно качество программы, а не ее цена, является главным фактором.
#"
1.6.1. Âíåøíåå è âíóòðåííåå êà÷åñòâî ïðîãðàììû
При выборе программы потребителя, как правило, не интересует, как она устроена внутри. Для него гораздо важнее, как
эта программа поведет себя в деле. Такой взгляд на программу
получил название пользовательское качество. В терминологическом стандарте1 ИСО 8402 [12] дано следующее определение:
Качество – совокупность свойств и характеристик изделий или услуг, обеспечивающих удовлетворение установленных или предполагаемых потребностей.
На рис. 1.3 изображены комплексные характеристики качества программы, интересующие потребителя.
Рис. 1.3. Комплексные характеристики пользовательского качества
программного продукта (в скобках курсивом приведены
английские названия этих характеристик)
Организация, занимающаяся тестированием, сертификацией и продвижением ПП, должна оценить соответствие свойств
программы и предъявленных к ней требований, а также сопоставить качество различных программ-конкурентов. При этом ее,
как правило, не интересует, какими проектными решениями
достигнут результат. Она смотрит на программу как бы извне.
Такой взгляд получил название внешнее качество.
Для фирмы-разработчика качество программы вместе с эффективностью ее продвижения определяет коммерческий успех.
Высокое качество продукции фирмы определяет ее место на
1
Терминологический стандарт серии международных стандартов ИСО
9000 версии 1994 г., определяющих требования к системе управления качеством. В новой версии этой серии стандартов определения терминов
приводятся в разделе 3 стандарта ГОСТ Р ИСО 9000–2001. Подробнее
стандарты этой серии будут описаны в гл. 5.
##
рынке, формирует доброе имя (бренд), является залогом ее экономической стабильности и развития.
Для разработчика участие в проекте, завершившемся созданием качественной программы, является важным фактором профессионального и карьерного роста.
В разработке крупной современной программы, как правило,
принимают участие сотни человек различных специальностей, а
сама разработка может длиться годы. Для разработки качественной программы приходится организовывать и координировать
действия всех участников разработки, ориентировав их на выпуск высококачественного продукта. Система действий, обеспечивающих разработку качественного продукта на всех этапах,
начиная от замысла до эксплуатации готового продукта, называется системой управления качеством.
Во всех перечисленных случаях и руководству фирмы, и разработчикам, и работодателям важно уметь объективно оценивать качество программы изнутри. Такой взгляд на качество программы получил название внутреннее качество1.
В реальной жизни понятие «качество программы» является
трудным для формализации и измерения. Приведем примеры.
Особенностью программного обеспечения является то, что
наряду с инструментами решения традиционных задач, разработчик, как правило, передает пользователю свое видение проблемы, свои подходы к организации дела и т.д. Поэтому программа, признанная высококачественной одним заказчиком,
в глазах другого может оказаться низкокачественной.
При обсуждении идеи программы и разработке технического
задания одной из основных проблем является согласование фактически разных представлений внешнего, внутреннего и пользовательского качества. Искусство проектировщика во многом заключается
в том, чтобы правильно интерпретировать представления заказчика
(или потенциальных потребителей) о пользовательском качестве программы в терминах ее внешнего и внутреннего качества.
При планировании и управлении работами руководитель
должен обеспечить единое понимание требований к качеству
проекта и правильную интерпретацию этих требований применительно к работе каждого исполнителя.
1
В последней версии международного стандарта ИСО 9126 (2002),
еще не принятой в России, выделено три точки зрения на показатели качества: пользовательское качество, внешнее и внутреннее качество.
#$
Из вышеизложенного видно, как важно обеспечить единство понимания качества и измеримость его характеристик.
1.6.2. Õàðàêòåðèñòèêè êà÷åñòâà
ïðîãðàììíîãî îáåñïå÷åíèÿ
Для упорядочения использования характеристик качества
программного обеспечения разработан стандарт ГОСТ Р ИСО/
МЭК 9126-93 [12]. Стандарт придерживается определения качества, данного стандартом ИСО 9000. В стандарте определяется
шесть групп характеристик, которые с минимальным дублированием описывают различные аспекты качества программного
продукта. Эти характеристики определены так, что могут применяться к любому виду ПП. В своей совокупности группы характеристик образуют основу для дальнейшего уточнения и описания качества ПП.
Как известно, конкретные характеристики существенно зависят от особенностей разработки и применения программ, поэтому стандарт не регламентирует, а только рекомендует подхарактеристики (комплексные показатели) и показатели, а также
методы их измерения, ранжирования, оценки и использования.
Перечень рекомендуемых стандартом ГОСТ Р ИСО/МЭК 9126-93
показателей, разбитый на группы и составляющие их характеристики, с указанием русского и английского названий, приведен в табл. 1.8.
Т а б л и ц а 1.8
Группы характеристик качества программного продукта
Ãðóïïà
Ôóíêöèîíàëüíîñòü
(Functionality)
Íàäåæíîñòü
(Reliability)
Õàðàêòåðèñòèêà
Ïðèãîäíîñòü (Suitability)
Ïðàâèëüíîñòü ( Accuracy)
Ñïîñîáíîñòü ê âçàèìîäåéñòâèþ (Interoperability)
Çàùèùåííîñòü (Security)
Ñîãëàñîâàííîñòü [ñ äåéñòâóþùèìè ñòàíäàðòàìè]
(Compliance)
Ñòàáèëüíîñòü (Maturity)
Óñòîé÷èâîñòü ê îøèáêå ( Fault tolerance)
Âîññòàíàâëèâàåìîñòü (Recoverability)
Ñîãëàñîâàííîñòü [ñî ñòàíäàðòàìè íàäåæíîñòè]
(Reliability compliance)
#%
Продолжение
Ãðóïïà
Óäîáñòâî èñïîëüçîâàíèÿ (Usability)
Ýôôåêòèâíîñòü
(Efficiency)
Ñîïðîâîæäàåìîñòü
(Maintainability)
Ìîáèëüíîñòü
(Portability)
Õàðàêòåðèñòèêà
Ïîíÿòíîñòü (Understand ability)
Îáó÷àåìîñòü (Learn ability)
Ïðîñòîòà èñïîëüçîâàíèÿ (Operability)
Ïðèâëåêàòåëüíîñòü ( Attractiveness)
Ñîãëàñîâàííîñòü [ñî ñòàíäàðòàìè óäîáñòâà]
(Compliance)
Õàðàêòåð èçìåíåíèÿ âî âðåìåíè ( Time behavior)
Õàðàêòåð èçìåíåíèÿ ðåñóðñîâ ( Resource behavior)
Ñîãëàñîâàííîñòü [ñî ñòàíäàðòàìè ýôôåêòèâíîñòè]
(Compliance)
Àíàëèçèðóåìîñòü ( Analyzability)
Èçìåíÿåìîñòü (Changeabi1ity)
Óñòîé÷èâîñòü ( Stabi1ity)
Òåñòèðóåìîñòü ( Testabi1ity)
Ñîãëàñîâàííîñòü [ñî ñòàíäàðòàìè ñîïðîâîæäàåìîñòè] (Compliance)
Àäàïòèðóåìîñòü ( Adaptabi1ity)
Ïðîñòîòà âíåäðåíèÿ (Installabi1ity)
Ñîâìåñòèìîñòü ( Co-existence)
Âçàèìîçàìåíÿåìîñòü (Rep1aceabi1i1y)
Ñîãëàñîâàííîñòü [ñî ñòàíäàðòàìè ìîáèëüíîñòè]
(Compliance)
Разработчику предоставляется возможность самому отобрать
важные для программы характеристики из предлагаемого набора. Использование данного стандарта обеспечивает единство
понимания и измерения характеристик качества ПП.
Чтобы лучше понять содержание стандарта, необходимо
взглянуть на программу глазами заказчика, выбирающего программное обеспечение для внедрения. Итак, на что в первую
очередь обращают внимание покупатели, выбирая программный
продукт?
Программа должна делать то, что нужно заказчику. Делать правильно, в приемлемые сроки и с приемлемой трудоемкостью. Кроме того, программа должна уметь взаимодействовать с другими программами, которые заказчик использует
при решении своих задач, и быть защищенной от несанкционированного использования, искажения или удаления.
#&
Для оценки этого аспекта стандарт предлагает группу характеристик, названную функциональность (Functionality), – совокупность свойств программного средства, определяемую наличием и конкретными особенностями набора функций, способных
удовлетворять заданные или подразумеваемые потребности.
Заказчик должен быть уверен, что расчеты, проводимые с
помощью программы, выполняются правильно. Программа сама
отслеживает возможные сбойные ситуации, понятно и однозначно диагностирует их появление.
База данных, используемая программой, содержит верную и
актуальную информацию. Если пользователь своевременно введет в ЭВМ верные данные и правильно ими воспользуется, то
гарантированно получит правильные результаты в нужные мне
сроки.
Приведем некоторые конкретные характеристики этой группы:
пригодность (suitability) – степень соответствия набора функций ПП поставленным задачам;
правильность (accuracy) – степень правильности получаемых
результатов и соответствия реакции программы ожидаемой.
способность к взаимодействию (interoperability) – способность
программы взаимодействовать с конкретными системами.
защищенность (security) – способность предотвращать несанкционированный доступ, случайный или преднамеренный, к
программам и данным.
согласованность с действующими стандартами (compliance) –
соответствие программы требованиям законов, стандартов, положений, соглашений или рекомендаций, действующих в данной области. Значение характеристики – список документов и
требований, с которыми согласована программа. Данная характеристика имеется во всех группах.
Программа должна быть надежной. Программа должна обладать достаточной устойчивостью к нештатным ситуациям: иметь
защиту от сбоев оборудования и несанкционированного использования. Данные, используемые программой, должны быть защищены от несанкционированного или случайного просмотра,
изменения или удаления. При вводе ошибочной информации
программа должна сообщать об обнаруженных ею ошибках.
Должен быть предусмотрен «откат» выполняемых действий. За
этот аспект качества в стандарте программного средства отвечает группа характеристик надежность (reliability). Эта группа
#'
представляет собой совокупность свойств, характеризующих способность программного средства сохранять заданный уровень
пригодности в заданных условиях в течение заданного периода
времени.
Как правило, в надежности выделяют три главные составляющие:
стабильность (maturity), зависящую от количества ошибок,
оставшихся в программе, и характеризующую возможность безотказной работы;
устойчивость к ошибкам (fault tolerance), характеризующую
степень разрушительности последствий возникающих ошибок;
восстанавливаемость (recoverability), характеризующую время и усилия, необходимые для устранения последствий возникающих в программе ошибок.
Отметим, что в отличие от технических средств, программа
не подвержена износу или физическому старению1. Ограничения уровня ее пригодности являются следствием дефектов и
неучтенных ситуаций в процессе постановки и программирования. При длительной эксплуатации программы эти дефекты и
ситуации проявляются.
Купленная программа должна помогать пользователю решать
его проблемы и по возможности не создавать дополнительной головной боли. Что это значит? Разработчик должен видеть задачу
так же, как пользователь. Алгоритм и все действия, выполняемые программой, должны быть одинаково прозрачны и понятны для обеих сторон. Результаты работы программы, их форма
должны быть максимально приближены к существующим нормам и практике.
Интерфейс программы должен быть понятен пользователю,
применять лексику его (а не программиста) предметной области. Набор функций и доступ к ним должны быть удобны для
решения задач пользователя (а не для программирования!).
К программе должна быть приложена понятная пользователю инструкция. Желательно также иметь контекстную подсказку, содержательно описывающую возможности каждого шага.
Она должна содержать кроме описания операторских действий
методические рекомендации по реализации данного шага.
1
Программы подвержены моральному старению. Рано или поздно они
перестают соответствовать изменившимся требованиям.
$
Для оценки этого аспекта качества используется группа характеристик удобство использования (usability). В нее входят следующие характеристики:
понятность (understand ability)– определяет усилия пользователя по пониманию общей логической концепции программы и
ее применимости для нужд пользователя;
обучаемость (learn ability)– определяет усилия пользователя,
необходимые для его обучения использованию программы;
простота использования (operability)– определяет усилия
пользователя при эксплуатации программы;
привлекательность (attractiveness)– оценка привлекательности программы, например, ее интерфейса.
Программа должна работать эффективно, т.е. достаточно быстро, чтобы ее можно было использовать в динамически протекающих процессах, а также достаточно экономно тратить ресурсы.
За эти стороны качества отвечает группа характеристик эффективность (efficiency). В нее входят:
характер изменения во времени1 (time behavior) – время выполнения функций и обработки, пропускная способность и время
реакции программы;
характер изменения ресурсов (resource behavior) – объемы используемых ресурсов и продолжительность их использования.
Программа должна быть достаточно гибкой и приспособляемой. Никто не может заранее предсказать все изменения, которые могут произойти даже в ближайшем будущем, поэтому, чтобы
воспользоваться программой в изменившихся условиях, нужно
иметь возможность настройки программы и данных. Чем чаще
возникают изменения, тем более гибкой должна быть программа.
Если программа будет использоваться не в одном месте, настройка нужна и для адаптации программы к конкретному месту использования. Чем больше гибкость программы, тем шире
круг ее возможных покупателей. В стандарте эта группа характеристик называется сопровождаемость (maintainability). К характеристикам данной группы относятся:
анализируемость (analizability)– определяет усилия пользователя, необходимые для диагностики отказов и несоответствий
работы программы, а также для ее модернизации;
1
По мнению авторов, это пример не совсем удачного перевода терминов, что, к сожалению, часто встречается при принятии зарубежных стандартов в качестве национальных стандартов России.
$
изменяемость (changeability) – определяет усилия, необходимые для модификации, устранения отказов или для изменения
условий эксплуатации программы;
устойчивость (stability)– оценка рисков от непредвиденных
эффектов, возникающих при модификации или изменении условий эксплуатации программы;
тестируемость (testability) – оценка усилий, необходимых для
проверки модифицированного программного обеспечения.
И наконец, программа должна работать на моей технике и в
операционной среде, используемой мной. А если это невозможно,
я должен понять, почему мне придется их модернизировать и
какие преимущества мне это даст.
Характеристики, определяющие простоту внедрения программы на платформе заказчика, переноса ее на другие платформы
и т.д., объединены в группу мобильность (portability). В нее входят:
адаптируемость (adaptability) – оценивает удобство адаптации программы к различным конкретным условиям ее эксплуатации. При этом учитываются только возможности самой программы, без применения других действий или программных
средств;
простота внедрения (installability) – оценка усилий, необходимых для внедрения программного обеспечения в конкретное
окружение;
совместимость (co-existence) – возможность работы программы в данной операционной среде совместно с другими программами;
взаимозаменяемость (replaceability) – характеризует сложность
и трудоемкость применения программы вместо другого конкретного программного средства в операционной среде этого средства.
Принципиально важно, что пользователь может отказаться
от некоторых из перечисленных требований только в виде исключения, когда продавец убедит его, что предлагаемое им видение задачи, новые свойства программы и т.д. с лихвой компенсируют пользователю все затраты труда, времени и денег,
необходимые для приспособления к новой программе.
Критерий Тагути. Как видим, перечень требований к программе как к товару весьма разнообразен. Как же оценить качество конкретного программного продукта? Как сопоставить характеристики различных программ? Японский ученый Тагути
$
сформулировал следующий критерий оценки качества товара:
качество товара (продукта или услуги) тем выше, чем меньше
совокупные затраты и потери всего общества, связанные с его
разработкой, изготовлением, применением и утилизацией.
Если внимательно просмотреть перечисленные раньше требования к программе, то можно убедиться в том, что все они
удовлетворяют критерию Тагути. Критерий позволяет не только
сформулировать требования к качеству, но и:
• оценить полноту перечня требований, задав вопрос: «А все
ли виды затрат и потерь мы учли?»;
• отделить характеристики качества от других характеристик, может быть влияющих на продажу, но к качеству не имеющих прямого отношения. Например, красочность упаковки программного продукта и «раскрученность» его рекламы могут
повлиять на объемы продаж, но характеристиками качества они
не являются;
• дать общее правило измерения (сопоставления) качества
различных программ, правильно подсчитав все потери и затраты.
К сожалению, последнее свойство критерия Тагути мало чего
даст для практического применения. Учет и расчет всех затрат и
потерь в реальных условиях потребует столько времени и сил, а
главное, столько допущений и предположений, что его реализация с требуемой точностью, как правило, невозможна. Однако
для проверки правильности конкретных критериев качества критерий Тагути может быть очень полезен.
1.7. Îðãàíû ñòàíäàðòèçàöèè â îáëàñòè
ïðîãðàììíîãî îáåñïå÷åíèÿ
Стандарты разных уровней принимаются различными по
уровню и полномочиям органами стандартизации. Все специализированные организации, занимающиеся разработкой и распространением стандартов, принято делить на международные,
национальные и профессиональные.
Наиболее авторитетной и общепризнанной международной
организацией в области стандартизации является Международная организация по стандартизации (International Organization
for Standardization), которая имеет также краткое название ИСО
(ISO), образованное от греческого слова «isos» – равный. Эта
$!
организация создана в 1946 г. и в настоящее время объединяет
усилия по разработке стандартов практически всех развитых стран
мира. Тесно сотрудничает с ИСО в области разработки «информационных» стандартов еще одна международная организация–
Международная электротехническая комиссия (МЭК).
Наиболее известной национальной организацией стандартизации в области информационных технологий является американский институт национальных стандартов ANSI. (Всем
известна таблица ANSI кодировки символов). В России национальным органом стандартизации является Комитет Российской Федерации по стандартизации, метрологии и сертификации (Госстандарт России), который в 2004г. преобразован в Федеральное агентство по техническому регулированию и метрологии (Ростехрегулирование), подведомственное Министерству
промышленности и энергетики Российской Федерации.
Ранее были рассмотрены виды стандартов, разрабатываемых
внутри страны. Стандарты, принятые Госстандартом или Ростехрегулированием имеют обозначение ГОСТ Р, после которого
следует порядковый номер принятого стандарта и год утверждения. В области программного обеспечения и информационных
технологий значительную часть стандартов, принимаемых сегодня в качестве национальных на территории России, составляют международные стандарты, принятые международными
органами стандартизации. Если национальный стандарт разрабатывается на основе международного стандарта ИСО/МЭК, то
в его обозначении присутствует соответствующая запись. Например, упомянутый выше, ГОСТ Р ИСО/МЭК 9126-93.
В качестве примеров профессиональных организаций, стандарты которых широко используются во всем мире, можно указать Институт инженеров по электротехнике и электронике
IEEE, Группу управления объектами OMG, Консорциум W3C и др.
Контрольные вопросы
1. Какой закон Российской Федерации регулирует деятельность в области стандартизации?
2. Перечислите основные задачи стандартизации.
3. Являются ли все требования национальных стандартов
обязательными на территории России?
4. Что такое технический регламент и какой орган может его
принять?
$"
5. Каким требованиям должна соответствовать организация,
проводящая сертификацию продукции?
6. В каких случаях и для каких целей проводится обязательная и добровольная сертификация?
7. Какие преимущества дает производителю наличие сертификата на его продукцию?
8. Какие органы в России могут проводить сертификацию
программных средств?
9. Что такое единство измерений? Какая область знаний занимается вопросами обеспечения единства измерений?
10. Каким требованиям должна соответствовать характеристика, чтобы ее можно было считать измеряемой величиной?
11. Что такое метрика?
12. Что такое единство терминологии? Какие методы обеспечения единства терминологии применяются в системах управления и информационных системах?
13. Перечислите виды совместимости изделий. Какие из них
наиболее важны для программного обеспечения?
14. С какой целью проводится стандартизация методик выполнения измерений?
15. Что такое унификация? Как применяется этот метод в
программировании?
16. В каких шкалах (номинальной, ранговой или количественной) могут измеряться данные характеристики программного продукта:
• среда разработки;
• экспертная оценка удобства использования программы;
• производительность программы;
• простота внедрения.
17. Чему равен коэффициент Спирмена для ранжировок:
R1(1;2;3;4;5;6;7;8;9;10) и R2(10;9;8;7;6;5;4;3;2;1)?
18. Выделите из приведенного списка характеристики качества программного продукта, указанные в ГОСТ Р 9126-93:
• среда программирования;
• удобство использования программы;
• привлекательность пользовательского интерфейса;
• доля заимствованных программных объектов;
• надежность программного средства.
$#
ÎÐÃÀÍÈÇÀÖÈß ÐÀÇÐÀÁÎÒÊÈ
ÏÐÎÃÐÀÌÌÍÛÕ ÑÈÑÒÅÌ
2.1. Èñòîðèÿ ðàçâèòèÿ ìåòîäîëîãèé ðàçðàáîòêè
ñëîæíûõ ñèñòåì
Как отмечалось ранее, создание и использование сложных
систем является непростой задачей и требует особых подходов к
организации их разработки и эксплуатации. Люди научились
осуществлять большие проекты уже давно, достаточно вспомнить египетские пирамиды. В основу организации работ по их
реализации положено жесткое управление и безусловное подчинение исполнителей командам руководителя проекта.
Особенностью современных масштабных проектов является
необходимость участия в них большого количества исполнителей, выполняющих творческую, интеллектуальную работу. Необходимость таких проектов возникла в XX в. с развитием современной авиации, ракетной техники, атомной отрасли,
электроники и других областей деятельности. Оказалось, что для
реализации проектов, которые требуют выполнения больших
объемов интеллектуального труда, не годятся старые методы
организации работ.
При выполнении данных проектов возникло противоречие.
С одной стороны, необходимо получить сложное и принципиально новое изделие со строго заданными характеристиками в
заданные сроки. Для этого необходимо организовать согласованную работу большого количества людей, что требует четкости управления, доведения до каждого исполнителя конкретного
задания и безусловного выполнения заданий исполнителями.
С другой стороны, заранее не известны методы решения задач,
поставленных перед исполнителями. При этом успех всего проекта существенно зависит от решения каждого исполнителя.
Основы современных методологий разработки сложных систем были заложены в 1930-х годах в связи с необходимостью
$$
координации усилий по созданию новых систем вооружений и
авиационной техники. Наиболее ярко потребность в новых методах управления разработкой сложных систем проявилась как
в СССР, так и в США при реализации атомного и космического
проектов. Общие черты этих проектов, удельные затраты и достигнутые результаты оказались весьма схожи, несмотря на значительную разницу в государственном устройстве. Сами проекты при этом носили закрытый характер и опыт организации
работ по их осуществлению не нашел должного отражения в
соответствующих открытых стандартах и нормативных документах того времени.
Можно выделить следующие характерные особенности успешных крупных проектов середины XX в.:
1) заказчиком проектов выступала политическая элита государств, ясно и четко определяющая цель проектов и готовая
потратить на их осуществление значительные ресурсы при жестких ограничениях на сроки реализации;
2) создавался коллектив разработчиков, нацеленный на конечный результат;
3) было организовано эффективное взаимодействие между
разработчиками: сбор разработчиков в одном месте и обеспечение возможности непосредственного общения между ними (Арзамас-16, Челябинск-70, Лос-Аламос, …);
4) несмотря на наличие жестких сроков, существовала обратная связь между разработчиками и высшим руководством,
которая позволяла корректировать принятые решения и вовремя ставить новые задачи;
5) большое значение имел человеческий фактор. К разработке привлекались наиболее квалифицированные специалисты.
(В США 11 участников атомного проекта стали впоследствии
лауреатами Нобелевской премии.) В СССР лучших специалистов
собирали принудительно в «шарагах», или позднее в специальных закрытых городах со специальным обслуживанием, жильем,
высокой зарплатой и т.д., куда ехали по собственному желанию
действительно лучшие специалисты и выпускники вузов.
Развитие компьютерной техники и программных систем привело к необходимости массового внедрения передовых методологий разработки. Сложные программные комплексы (не уступающие по сложности космической технике) стали разрабатываться
повсеместно. Это потребовало создания соответствующих средств
$%
и методов разработки и стимулировало появление и бурное развитие во второй половине XX в. новой инженерной дисциплины, называемой программная инженерия (software engineering).
Развитие данной дисциплины сопровождалось выработкой соответствующих международных, национальных, отраслевых и
корпоративных стандартов, в которых фиксировались найденные удачные решения и методы.
Ниже описывается передовой опыт и методологии разработки программных систем, закрепленные в стандартах различного
уровня.
2.2. Æèçíåííûé öèêë ïðîãðàììíîé ñèñòåìû
Практически все современные программные продукты являются сложными системами. Под системой в данном случае
понимается совокупность взаимодействующих компонентов и
взаимосвязей между ними, направленная на достижение определенной цели. Существующие методы анализа, разработки и
использования сложных систем основаны на применении понятия жизненного цикла (ЖЦ) системы. Подход, основанный на
рассмотрении жизненного цикла, оказался эффективным при
анализе любых сложных объектов и реализации больших проектов, будь то строительство нового лайнера, осуществление полета на Марс или разработка программной системы. Под проектом будем понимать временное предприятие, осуществляемое
в целях создания уникального продукта или услуги.
Рассматриваются основные особенности жизненного цикла
современных программных систем и методологии их разработки.
Программной системой (ПС) будем считать комплекс связанных между собой программ (программный комплекс),
снабженный необходимой документацией, ориентированный
на сбор, хранение, поиск, обработку, передачу и отображение информации в некоторой предметной области.
В ряде стандартов и различной технической литературе используются термины программное средство, программное обеспечение, программный продукт. Все они произошли от одного
термина «software» и обозначают одно и то же понятие. Так как
всякое программное средство можно рассматривать как программную систему и всякая программная система является про$&
граммным средством, а также для того, чтобы подчеркнуть важность системного подхода при рассмотрении методологий разработки программных средств, в дальнейшем будем считать эти
термины синонимами. Попутно заметим, что термины информационная система и автоматизированная система во многих
источниках используются для обозначения более широкого понятия, в которое кроме программной системы входят технические средства и люди, обеспечивающие работу программной системы, т.е. программную систему можно рассматривать как
составную часть информационной системы.
Под жизненным циклом программной системы обычно понимается непрерывный процесс, который начинается с момента принятия решения о необходимости создания системы
и заканчивается в момент ее полного изъятия из эксплуатации.
Жизненный цикл представляет собой некоторую последовательность этапов и совокупность протекающих в течение ЖЦ
процессов. Для каждого этапа определяются: состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ
позволяет спланировать и организовать процесс коллективной
разработки, внедрения и эксплуатации информационной системы и обеспечить управление этим процессом.
Следует напомнить, что первоначально понятие жизненного
цикла рассматривалось более узко, как цикл разработки ПС. Однако понимание того, что качество программного обеспечения
во многом определяется добротностью идеи программы, глубиной понимания запросов будущих пользователей, удачностью
«раскрутки» и сопровождения программы и т.д., привело к естественной трансформации исходного понятия цикла разработки.
В маркетинге используется понятие жизненный цикл товара,
отражающее эволюцию отношения к товару во времени его жизни: от зарождения идеи до прекращения продаж. Цикл разработки является одним из этапов жизненного цикла ПС как товара.
В условиях жесткой конкуренции на рынке программного
обеспечения все более важными становятся конкурентоспособность программ, их возможность захватить и удержать как можно
больший сегмент рынка. Необходимое для этого качество программ закладывается на ранних этапах их жизненного цикла,
$'
реализуется в процессе разработки и используется при продаже
и сопровождении программ. Это привело к необходимости объединить в одном понятии жизненного цикла ПС точки зрения
маркетологов и разработчиков. Таким образом, понятие жизненного цикла включает в себя взаимосвязанные процессы разработки, продажи, внедрения, эксплуатации, сопровождения и
выведения из эксплуатации ПС.
2.3. Ìåæäóíàðîäíûå è íàöèîíàëüíûå ñòàíäàðòû
ìåòîäîëîãèé ðàçðàáîòêè ïðîãðàììíûõ ñèñòåì
В настоящее время принято несколько международных и
национальных стандартов, регламентирующих этапы и процессы ЖЦ ПС. В табл. 2.1 приведены наиболее важные из них.
Т а б л и ц а 2.1
Отечественные и международные стандарты,
регламентирующие этапы и процессы жизненного цикла ПС
Ñòàíäàðò
ÃÎÑÒ 34.601-90
[7]
ÃÎÑÒ 19.102-77
[4]
%
Íàçâàíèå
Èíôîðìàöèîííàÿ òåõíîëîãèÿ.
ÊÑÀÑ. Àâòîìàòèçèðîâàííûå
ñèñòåìû. Ñòàäèè
ñîçäàíèÿ
Êîììåíòàðèé
Äàííûé ñòàíäàðò ðàçðàáàòûâàëñÿ â
ÑÑÑÐ âî âðåìåíà ïëàíîâîé ýêîíîìèêè è ãîñóäàðñòâåííîé ñîáñòâåííîñòè íà ñðåäñòâà ïðîèçâîäñòâà, êîãäà íå áûëî ðå÷è î êîììåð÷åñêèõ ïðîãðàììíûõ ïðîäóêòàõ.
Ñòàíäàðò îòðàæàåò ñëîæèâøóþñÿ
íà òî âðåìÿ â Ðîññèè ïðàêòèêó
ðàçðàáîòêè ïðîãðàììíûõ ïðîäóêòîâ. Ó÷èòûâàåò ðîññèéñêóþ ñïåöèôèêó âçàèìîîòíîøåíèé ðàçðàáîò÷èêà è çàêàç÷èêà
Åäèíàÿ ñèñòåìà Ïåðâûé Ðîññèéñêèé ñòàíäàðò,
ïðîãðàììíîé
ðàçðàáîòàííûé â 70-å ãîäû ïðîäîêóìåíòàöèè
øëîãî âåêà. Äëèòåëüíîå ïðèìåíå(ÅÑÏÄ). Ñòàäèè íèå ýòîé ñèñòåìû ñòàíäàðòîâ
ðàçðàáîòêè
ñôîðìèðîâàëî
îïðåäåëåííûé
ñòèëü âçàèìîäåéñòâèÿ çàêàç÷èêà è
ðàçðàáîò÷èêà, îñíîâàííûé íà êàñêàäíîé ìîäåëè ÆÖ. Íåñìîòðÿ íà
òî, ÷òî ýòîò ñòàíäàðò ðàçðàáîòàí
äîñòàòî÷íî äàâíî, íåêîòîðûå åãî
ïîëîæåíèÿ îñòàþòñÿ ïîëåçíûìè
äî íàñòîÿùåãî âðåìåíè
Продолжение
Ñòàíäàðò
ÃÎÑÒ Ð
ÈÑÎ/ÌÝÊ
12207-99 [9]
ÃÎÑÒ Ð
ÈÑÎ/ÌÝÊ
15288-2005 [10]
ISO/IEC 15504
[14]
ISO/IEC
9000-3-2002 [17]
Íàçâàíèå
Èíôîðìàöèîííàÿ òåõíîëîãèÿ.
Ïðîöåññû æèçíåííîãî öèêëà
ïðîãðàììíûõ
ñðåäñòâ
Êîììåíòàðèé
Ýòîò ñòàíäàðò ÿâëÿåòñÿ ïåðåâîäîì
ìåæäóíàðîäíîãî
ñòàíäàðòà
ISO/IEC 12207:1995 «Software Life
Cycle Processes» [13], ðàçðàáîòàííîãî â íåäðàõ Ìèíèñòåðñòâà îáîðîíû ÑØÀ. Â íåì îáîáùåí îïûò
óïðàâëåíèÿ ðàçðàáîòêàìè êðóïíûõ ïðîãðàììíûõ ïðîåêòîâ ïî
çàêàçó óïîìÿíóòîãî ì èíèñòåðñòâà
Ðîññèéñêèé àíàëîã ìåæäóíàðîäÑèñòåìíàÿ èííîãî ñòàíäàðòà ISO/IEC 15288
æåíåðèÿ ïðîSystem life cycle processes [18].
öåññû æèçíåíÓñòàíàâëèâàåò
ïîñëåäîâàòåëüíîãî öèêëà ñèñíîñòü ýòàïîâ è ïåðå÷åíü ïðîöåñòåì
ñîâ ÆÖ ðàçðàáîòêè ëþáûõ êðóïíûõ ïðîåêòîâ, â òîì ÷èñëå è ÏÑ.
Ââåäåí â Ðîññèè ñ 1 ÿíâàðÿ 2007ã.
Íàèáîëåå ïðîãðåññèâíûé ñòàíäàðò, â êîòîðîì ó÷òåí ìåæäóíàðîäíûé îïûò ðàçðàáîòêè ñëîæíûõ
ñèñòåì
Information Tech- Ìåæäóíàðîäíûé ñòàíäàðò, îïðåäåëÿþùèé ïîðÿäîê îöåíêè ïðînology-Software
öåññîâ æèçíåííîãî öèêëà ÏÑ
Process Assessment
Ìåæäóíàðîäíûé
ñòàíäàðò
ïî
Ñèñòåìíàÿ è
óïðàâëåíèþ êà÷åñòâîì ðàçðàáîòêè
ïðîãðàììíàÿ
ÏÑ
èíæåíåðèÿ
ðóêîâîäñòâî ïî
ïðèìåíåíèþ
ñòàíäàðòà ISO
9001-2000 ê
ïðîãðàììíîìó
îáåñïå÷åíèþ
Стандарты ГОСТ 34.601-90 и ГОСТ 19.102-77 были разработаны в Советском Союзе в 1970-е–1980-е годы, поэтому они не
учитывают многие современные реалии. Несмотря на это, они
хорошо адаптированы к сложившейся в России системе взаимодействия разработчика и заказчика, существующей системе документооборота и имеют богатую практику применения.
Общей особенностью стандартов, перечисленных в табл. 2.1,
является то, что они разработаны государственными структурами
%
и отражают в основном их взгляд на ЖЦ ПС. Эти стандарты
рассчитаны на тесное взаимодействие заказчика и разработчика
(покупателя и поставщика) и лучше всего адаптированы к случаю, когда заказчиком ПС является крупная государственная
структура, заказывающая разработку ПС своему подразделению
или частной фирме.
ЖЦ согласно этим стандартам можно условно разбить на
обобщенные этапы, последовательность которых приведена на
рис. 2.1 (названия этапов и степень детализации процессов на
каждом этапе в разных стандартах несколько различаются, но
содержание этапов весьма схоже). Основными достоинствами
такой схемы ЖЦ является возможность формализации процессов разработки и эксплуатации ПС и представления их в виде
четко определенных и детально прописанных этапов. Это позволяет повысить надежность и предсказуемость планирования,
разработки и использования ПС и довести весь процесс разработки и эксплуатации ПС до уровня хорошо отлаженной промышленной технологии.
Рис. 2.1. Обобщенная схема этапов жизненного цикла
программной системы
Примером ПС, ЖЦ которых протекает по данной схеме,
могут служить заказные ПС, создаваемые для крупных организаций, таких как управление железной дороги, крупный банк,
министерство и т.д. В табл. 2.2 приведены цели и критерии качества для каждого из этапов ЖЦ данного типа.
%
Т а б л и ц а 2.2
Цели и критерии качества этапов жизненного цикла изделия,
разрабатываемого по заказу
Ýòàï
Ðàçðàáîòêà
êîíöåïöèè
Öåëü
Îïðåäåëåíèå öåëè ïðîãðà ììû.
Âûáîð âîçìîæíûõ íàïðàâëåíèé ðåàëèçàöèè.
Îöåíêà öåëåñîîáðàçíîñòè ðàçðàáîòêè è ðåàëèçóåìîñòè ïðîãðàììû
Êðèòåðèé êà÷åñòâà
Åäèíîå ïîíèìàíèå çàêàç÷èêîì è ðàçðàáîò÷èêîì
öåëåé è çàäà÷ ïðîãðàììû.
Ñîãëàñîâàííûå íà÷àëüíûå îöåíêè ñòîèìîñòè
çàòðàò è âðåìåíè ðàçðàáîòêè
Ïðîåêòèðîâà- Àíàëèç áèçíåñ-ïðîöåññîâ ïðåä- Ïîëíîòà è ñîãëàñîâàííîñòü
íèå. Ðàçðàáîò- ïðèÿòèÿ, äëÿ êîòîðîãî ðàçðàáà- ïîòðåáèòåëüñêèõ òðåáîâàíèé,
èõ
ñîîòâåòñòâèå
êà è àíàëèç
òûâàåòñÿ ïðîãðàììà.
òåõíè÷åñêèõ
Âûäåëåíèå ïðîöåññîâ, ïîä- êîíöåïöèè ïðîãðàììû.
òðåáîâàíèé
ëåæàùèõ àâòîìàòèçàöèè.
Ôîðìèðîâàíèå ñèñòåìû ïîëü- Òåõíè÷åñêèå òðåáîâàíèÿ
äîëæíû:
çîâàòåëüñêèõ òðåáîâàíèé.
Ôîðìèðîâàíèå ñèñòåìû òåõ- • îäíîçíà÷íî ïîíèìàò üñÿ
íè÷åñêèõ òðåáîâàíèé ê èçäåâñåìè
ó÷àñòíèêàìè
ëèþ.
ïðîåêòà;
Âûáîð ñðåäñòâ ðåàëèçàöèè.
• áûòü ðåàëèçóåìûìè;
Ïëàíèðîâàíèå ðàçðàáîòêè è • ìàêñèìàëüíî ó÷èò ûâàòü
âûïóñêà
ìíåíèÿ ïîòåíöèàëüíûõ
ïîòðåáèòåëåé
Ðàçðàáîòêà
Ðàçðàáîòêà è èçãîòîâëåíèå Ïðîäóêò äîëæåí ñîîòâåòïðîãðàììíîãî ïðîäóêòà ñ òðåáóåìûìè õà- ñòâîâàòü òåõíè÷åñêèì òðåïðîäóêòà
ðàêòåðèñòèêàìè, â òðåáóåìîì áîâàíèÿì.
îáúåìå è â òðåáóåìûå ñðîêè
Ñðîêè è ñòîèìîñòü ðàçðàáîòêè íå äîëæíû ïðåâûøàòü óñòàíîâëåííûõ â
ïëàíå
Òåñòèðîâàíèå Ïðîâåðêà ñîîòâåòñòâèÿ ðàç- Ïðîãðàììà äîëæíà ñîîòðàáîòàííîé ïðîãðàììû òåõ- âåòñòâîâàòü ïðåäúÿâëåííûì ê íåé òðåáîâàíèÿì.
íè÷åñêèì òðåáîâàíèÿì:
• òåñòèðîâàíèå;
Çàêàç÷èê äîëæåí áûòü
óáåæäåí â òîì, ÷òî ïðî• ñåðòèôèêàöèÿ.
Ðåãèñòðàöèÿ ïðîãðàììû êàê ãðàììà:
îáúåêòà èíòåëëåêòóàëüíîé ñîá- • ðàáîòàåò ïðàâèëüíî;
• çàùèùåíà êàê îáúåêò
ñòâåííîñòè
èíòåëëåêòóàëüíîé ñîáñòâåííîñòè
%!
Продолжение
Ýòàï
Âíåäðåíèå
è îáó÷åíèå
Öåëü
Ïîäãîòîâêà ïðîèçâîäñòâà è
ïåðñîíàëà ê èñïîëüçîâàíèþ
ïðîãðàììû.
Àäàïòàöèÿ ïðîãðàììû ê îñîáåííîñòÿì åå èñïîëüçîâàíèÿ
Ñîïðîâîæäåíèå
Ïîìîùü ïîëüçîâàòåëÿì, âûÿâëåíèå è ðàçðåøåíèå ïðîáëåì, ñâÿçàííûõ ñ èñïîëüçîâàíèåì ïðîãðàììû, íàêîïëåíèå îïûòà, êîòîðûé áóäåò
èñïîëüçîâàí ïðè ðåàëèçàöèè
áóäóùèõ ïðîåêòîâ
Êðèòåðèé êà÷åñòâà
Ãîòîâíîñòü ïðîèçâîäñòâà
ê ýêñïëóàòàöèè ïðîãðàììû.
Ìèíèìóì ñáîåâ è íåñîîòâåòñòâèé â ïåðèîä ýêñïëóàòàöèè
Êà÷åñòâî ïðîãðàììû îïðåäåëÿåòñÿ êîëè÷åñòâîì è
ñëîæíîñòüþ
ïðîáëåì,
ñâÿçàííûõ ñ åå èñïîëüçîâàíèåì, à òàêæå ñ ÷àñòîòîé èõ ïîÿâëåíèÿ. ×åì
ìåíüøå ýòè õàðàêòåðèñòèêè, òåì âûøå êà÷åñòâî, òåì âûøå ðåïóòàöèÿ
ðàçðàáîò÷èêîâ
Жизненный цикл ПС, создаваемых на продажу широкому
кругу потребителей, будет отличаться от приведенного выше. В
этом случае фирма сама (на свои или заемные деньги) разрабатывает программу, которая, по ее мнению, будет иметь коммерческий успех. В связи с этим становятся важными такие этапы,
как проведение маркетинговых исследований и планирование,
а также подготовка к продаже, продажа и послепродажное обслуживание ПС.
При управлении разработкой программных систем такого
типа уместнее применять понятие «жизненный цикл изделия»,
определенное в международных стандартах серии ИСО 9000
(устанавливающих требования к системам управления качеством
продукции1). На рис. 2.2 приведена схема этапов жизненного
цикла коммерческого программного продукта, разрабатываемого по инициативе фирмы-разработчика, а в табл. 2.3 представлено описание этапов жизненного цикла этого изделия, их цели
и критерии качества.
1
Международные стандарты серии ИСО 9000 содержат общие положения и систему требований, предъявляемых к системам управления качеством
предприятий. В России действуют стандарты: ГОСТ Р ИСО 9001-2001 «Системы менеджмента качества. Требования», ГОСТ Р ИСО 9000-2001 и ГОСТ Р
ИСО 9004-2001.
%"
Рис. 2.2. Этапы жизненного цикла программного продукта,
реализуемого на свободном рынке (в соответствии с международными
стандартами серии ISO 9000)
В отличие от последовательности этапов, данной в ГОСТ
15288 [10] и других стандартах, определяющих этапы жизненного цикла, в этой схеме больше внимания уделяется вопросам
маркетинга, выявления и систематизации требований рынка к
разрабатываемому программному продукту1. Примерами ПС,
жизненный цикл которых протекает по данной схеме, могут
служить программные продукты, продаваемые на свободном
рынке.
Несмотря на различие этих двух подходов при рассмотрении
ЖЦ, цели и результаты этапов жизненного цикла имеют общие
черты. В стандарте ГОСТ 15288 сделана попытка сформулировать общую модель ЖЦ, справедливую для любых типов проектов. В табл.2.4 приведены цели и результаты для шести стадий
(этапов), которые составляют ЖЦ ПС согласно ГОСТ15288.
Необходимо отметить, что стандарт ГОСТ 15288 – это первый в России стандарт, тесно увязанный со стандартами серии
ISO 9000 и детально описывающий все этапы ЖЦ ПС, представленного на рис. 2.1. При этом схема ЖЦ, приведенная на
рис. 2.2, также может быть реализована в рамках стандарта ГОСТ
15288, если заказчиком будет выступать собственный отдел маркетинга организации разработчика.
1
Приведенная схема является адаптацией требований стандарта ISO
9004 к специфическому виду продукции – информационным системам,
продаваемым на свободном рынке.
%#
Т а б л и ц а 2.3
Цели и критерии качества этапов жизненного цикла изделия,
выпускаемого на продажу
Ýòàï
Çàðîæäåíèå
èäåè
Öåëü
Êðèòåðèé êà÷åñòâà
Èäåÿ íîâîãî èçäåëèÿ, Ðåøàåò ðåàëüíûå çàäà÷è ïîòðåêîòîðîå ìîæåò ñîçäàòü áèòåëÿ.
ôèðìà
Âûãîäíî îòëè÷àåòñÿ îò ñóùåñòâóþùèõ èçäåëèé
Ìàðêåòèíãîâîå Îïðåäåëåíèå êðóãà ïî- Öåëîñòíîñòü, ñîãëàñîâàííîñòü è
ïëàíèðîâàíèå
òðåáèòåëåé, èçó÷åíèå èõ íàäåæíîñòü ðåçóëüòàòîâ èññëåâêóñîâ è ïðåäïî÷òåíèé. äîâàíèé è îöåíîê
Àíàëèç àíàëîãîâ è
êîíêóðåíòîâ.
Îöåíêà äîëè ðûíêà,
êîòîðóþ ìîæåò «çàõâàòèòü» èçäåëèå.
Ìàðêåòèíãîâûé ïëàí
Ðàçðàáîòêà
Ôîðìèðîâàíèå ÷åòêèõ Òåõíè÷åñêèå òðåáîâàíèÿ äîë æíû:
òåõíè÷åñêèõ
òåõíè÷åñêèõ òðåáîâà- • îäíîçíà÷íî ïîíèìàòüñÿ âñ åìè
ó÷àñòíèêàìè ïðîåêòà;
òðåáîâàíèé
íèé ê èçäåëèþ.
Ïëàíèðîâàíèå ðàçðà- • áûòü ðåàëèçóåìûìè;
• ìàêñèìàëüíî ó÷èòûâàòü ìíåáîòêè è âûïóñêà
íèÿ ïîòåíöèàëüíûõ ïîòðåáèòåëåé
Ðàçðàáîòêà
Ðàçðàáîòêà è èçãîòîâ- Ïðîäóêò äîëæåí ñîîòâåòñòâîïðîäóêòà
ëåíèå ïðîäóêòà ñ òðå- âàòü òåõíè÷åñêèì òðåáîâàíèÿì.
áóåìûìè
õàðàêòåðè- Ñðîêè è ñòîèìîñòü ðàçðàáîòêè
ñòèêàìè, â òðåáóåìîì íå äîëæíû ïðåâûøàòü óñòàíîâîáúåìå è â òðåáóåìûå ëåííûõ â ïëàíå
ñðîêè
Ïðåäïðîäàæíàÿ Ïðåâðàùåíèå ïðîäóêòà Òîâàð äîëæåí áûòü:
• èçâåñòåí íà ðûíêå;
ïîäãîòîâêà
â òîâàð:
• ðåãèñòðàöèÿ ïðîäóêòà • äîñòàòî÷íî íàäåæíûì, ÷ò îáû
êàê îáúåêòà èíòåëåãî ïðîäàæè íå ïîâðåäèëè ðåëåêòóàëüíîé
ñîáñòïóòàöèè ôèðìû;
• çàùèùåí îò íåñàíêöèîíèðîâåííîñòè;
• òåñòèðîâàíèå è ñåðâàííîãî èñïîëüçîâàíèÿ (ïèòèôèêàöèÿ;
ðàòñòâà)
• îïðåäåëåíèå ñïîñîáîâ ïðîäâèæåíèÿ
Ïðîäàæà
Ïðîäàæà òîâàðà ìàêñè- Ïðèîáðåòåí ìàêñèìóìîì ïîëüìàëüíîìó ÷èñëó ïîêó- çîâàòåëåé, êîòîðûì îí íóæåí.
ïàòåëåé, íóæäàþùèõñÿ Ðåïóòàöèÿ ôèðìû íà ðûíêå
â ýòîì òîâàðå
ïîâûñèëàñü
%$
Продолжение
Ýòàï
Ïîñëåïðîäàæíîå îáñëóæèâàíèå
Öåëü
Ïîìîùü ïîëüçîâàòåëÿì.
Ïîääåðæàíèå èíòåðåñà ê
òîâàðó êàê ìîæíî íà
áîëåå äëèòåëüíûé ñðîê.
Âûÿâëåíèå ïðîáëåì, ñâÿçàííûõ ñ èñïîëüçîâàíèåì
òîâàðà
Êðèòåðèé êà÷åñòâà
Ôèðìà èìååò ïðåäñòàâëåíèå î
òîì, ÷òî íóæíî ïîëüçîâàòåëþ,
â êàêîì íàïðàâëåíèè ðàçâèâàòü òîâàð.
Ðåïóòàöèÿ ôèðìû íà ðûíêå
ïîâûñèëàñü
Т а б л и ц а 2.4
Цели и результаты этапов жизненного цикла
согласно ГОСТ Р ИСО/МЭК 15288-2005
Ñòàäèè
æèçíåííîãî öèêëà
Çàìûñåë
Öåëü
Ðåçóëüòàò
Çàìûñåë íîâîé ñèñòåìû (íîâîãî áèçíåñà).
Îöåíêà ðåàëèçóåìîñòè.
Ïðåäâàðèòåëüíîå
ïëàíèðîâàíèå
1. Êîíöåïöèÿ, îïèñàíèå âîçìîæíîñòåé ñèñòåìû.
2. Îöåíêà îñóùåñòâèìîñòè è öåëåñîîáðàçíîñòè çàìûñëà.
3. Ñòðàòåãèÿ ðåàëèçàöèè (áàçîâàÿ
ëèíèÿ).
4. Ýñêèçíàÿ ìîäåëü æèçíåííîãî öè êëà.
5. Âûÿâëåíèå è îöåíêà ðèñêîâ.
6. Ôóíêöèîíàëüíûå âîçìîæíîñòè è
òðåáîâàíèÿ ê îáåñïå÷èâàþùèì ñèñòåìàì.
7. Êîíöåïöèè âûïîëíåíèÿ âñåõ ïîñëåäóþùèõ ñòàäèé.
8. Ïëàíû è êðèòåðèè ïåðåõîäà íà
ñòàäèþ ðàçðàáîòêè.
9. Îöåíêà ãîòîâíîñòè ê ðàçðàáîòêå.
10. Ðåøåíèå î ðàçðàáîòêå.
Ðàçðàáîòêà Ïðîåêò ñèñòåìû, èëè 1. Ñèñòåìàòèçèðîâàííûå òðåáîâàíèÿ:
ïðîòîòèï
ôóíêöèîíàëüíîñòü, áþäæåò, ñðîêè
ñèñòåìû, èëè
ðåàëèçàöèè.
êîíå÷íûé ïðîãðàìì- 2. Àðõèòåêòóðà ñèñòåìû.
íûé ïðîäóêò
3. Äîêóìåíòàöèÿ ïî âåðèôèêàöèè è
âàëèäàöèè.
4. Ðåçóëüòàòû âåðèôèêàöèè, âàëèäàöèè è ñåðòèôèêàöèè, ïîäòâåðæäàþùèå ðàáîòîñïîñîáíîñòü è êà÷åñòâî
ñèñòåìû.
5. Òðåáîâàíèÿ ê îáåñïå÷èâàþùèì
ñèñòåìàì è óñëîâèÿì ýêñïëóàòàöèè.
%%
Продолжение
Ñòàäèè
æèçíåííîãî öèêëà
Öåëü
Ïðîèçâîäñòâî
Âûïóñê ïðîäóêöèè,
ïðåäîñòàâëåíèå
ïðîäóêöèè ïîëüçîâàòåëÿì
Ýêñïëóàòàöèÿ
Îáåñïå÷åíèå äåêëàðèðîâàííûõ õàðàêòåðèñòèê ñèñòåìû â
ïðîöåññå åå ýêñïëóàòàöèè.
Äåìîíñòðàöèÿ âîçìîæíîñòåé ôèðìû.
Àíàëèç ðåçóëüòàòîâ
ýêñïëóàòàöèè â öåëÿõ ñîâåðøåíñòâîâàíèÿ ïðîäóêöèè
ôèðìû
%&
Ðåçóëüòàò
6. Ïðîãðàììíàÿ äîêóìåíòàöèÿ.
7. Ïðîòîòèï èëè çàêîí÷åííàÿ ñèñò åìà.
8. Îöåíêà çàòðàò íà ýòàïàõ ïðîèçâîäñòâà, èñïîëüçîâàíèÿ, ñîïðîâîæäåíèÿ
è ñïèñàíèÿ.
9. Îöåíêà ôóíêöèîíàëüíûõ âîçìîæíîñòåé è òðåáîâàíèÿ ê îáåñïå÷èâàþùèì
ñèñòåìàì, èñïîëüçóåìûì íà ïîñëåäóþùèõ ñòàäèÿõ æèçíåííîãî öèêëà.
10. Ïëàíèðîâàíèå ïðîèçâîäñòâà.
11. Âûÿâëåíèå è óïðàâëåíèå ðèñêàìè.
12. Îöåíêà ãîòîâíîñòè ê ïðîèçâîäñòâó.
13. Ðåøåíèå î ïðîèçâîäñòâå
1. Îïðåäåëåíèå íåîáõîäèìûõ ïðîèçâîäñòâåííûõ ìîùíîñòåé.
2. Ïðèîáðåòåíèå íåîáõîäèìûõ ðåñó ðñîâ.
3. Ïðîèçâîäñòâî ïðîäóêöèè.
4. Ïåðåäà÷à ïðîäóêöèè ïîòðåáèòåëÿì
(çàêàç÷èêó, â êàíàëû ðàñïðîñòðàíåíèÿ
è ò.ä.).
5. Ïëàíèðîâàíèå èñïîëüçîâàíèÿ è
ñîïðîâîæäåíèÿ ïðîäóêöèè.
6. Ïåðåñìîòð è îáíîâëåííûå êîíöåïöèè
îñóùåñòâëåíèÿ ïîñëåäóþùèõ ñòàäèé.
7. Óïðàâëåíèå òåêóùèìè ðèñêàìè.
8. Ñèñòåìàòèçàöèÿ è ó÷åò èíòåðåñîâ
ïîêóïàòåëåé.
9. Îöåíêà ãîòîâíîñòè ê ïðîäóêöèè ê
ýêñïëóàòàöèè.
10. Ðåøåíèå î ïåðåõîäå ê ýêñïëóàò àöèè
1. Îïûò ýêñïëóàòàöèè: ïåðñîíàë, îòëàæåííàÿ àäìèíèñòðàòèâíàÿ, èíôîðìàöèîííàÿ è òåõíè÷åñêàÿ ñòðóêòóðà
èñïîëüçîâàíèÿ ñèñòåìû.
2. Ñèñòåìà ìîíèòîðèíãà, îöåíêè ôàêòè÷åñêîé ïðîèçâîäèòåëüíîñòè è ç àòðàò.
3. Ñèñòåìà âûÿâëåíèÿ è àíàëèçà ïðîáëåì, ôîðìèðîâàíèå êîððåêòèðóþùèõ
äåéñòâèé è îïîâåùåíèå ïîëüçîâàòåëåé.
4. Îáðàòíàÿ ñâÿçü ñ çàêàç÷èêîì.
5. Îöåíêà öåëåñîîáðàçíîñòè ýêñïëóàòàöèè.
6. Ðåøåíèå î ñïèñàíèè (ïðåêðàùåíèè
ýêñïëóàòàöèè).
Продолжение
Ñòàäèè
æèçíåíÖåëü
íîãî öèêëà
Ñîïðîâîæ- Òåõíè÷åñêîå
äåíèå
îáñëóæèâàíèå è
ñîïðîâîæäåíèå,
îáåñïå÷èâàþùèå
íåïðåðûâíîå
ôóíêöèîíèðîâàíèå
ñèñòåìû è åå óñòîé÷èâóþ ýêñïëóàòàöèþ
Ñíÿòèå ñ
ýêñïëóàòàöèè (ñïèñàíèå)
Ðåçóëüòàò
1. Îáó÷åííûé ïåðñîíàë, îáñëóæèâàþùèé è îáåñïå÷èâàþùèé ñëóæáû ñîïðîâîæäåíèÿ.
2. Íàëàæåííûå ñâÿçè è âçàèìîäåéñòâèå ñ îðãàíèçàöèÿìè, îáåñïå÷èâàþùèìè ðåøåíèå ïðîáëåì è ïðîâåäåíèå
êîððåêòèðóþùèõ ìåðîïðèÿòèé.
3. Íàëàæåííàÿ ñèñòåìà ñíàáæåíèÿ è
îáñëóæèâàíèÿ,
îáåñïå÷èâàþùàÿ
ôóíêöèîíèðîâàíèå.
4. Ñîïðîâîæäåíèå ïðîäóêöèè è óñëóã,
âêëþ÷àþùåå èñïðàâëåíèå íåçíà÷èòåëüíûõ íåäîñòàòêîâ ïðîåêòèðîâ àíèÿ.
5. Óïðàâëåíèå òåêóùèìè ðèñêàìè.
6. Îöåíêà öåëåñîîáðàçíîñòè ïðîäîëæåíèÿ ñîïðîâîæäåíèÿ.
7. Ðåøåíèå îá îêîí÷àíèè ôóíêöèîíèðîâàíèÿ ñëóæá ñîïðîâîæäåíèÿ.
Ïðåêðàùåíèå èñ1. Îïûòíûé ïåðñîíàë, ñïîñîáíûé
ïîëüçîâàíèÿ ñèñòå- îáåñïå÷èòü âûïîëíåíèå ôóíêöèé ñïèìû.
ñàíèÿ.
Àðõèâàöèÿ èëè óòè- 2. Ñèñòåìà òðåáîâàíèé è ïðîöåäóð
ëèçàöèÿ ñèñòåìû è
ïðåêðàùåíèÿ ýêñïëóàòàöèè îäíîé
åå êîìïîíåíò.
ñèñòåìû, çàìåíû åå äðóãîé èëè ïðèÏðèâåäåíèå ïðîöåñ- âåäåíèÿ ïðîèçâîäñòâåííîãî ïðîöåññà
ñà, â êîòîðîì èñâ èñõîäíîå ñîñòîÿíèå.
ïîëüçîâàëàñü ñèñòå- 3. Óòèëèçàöèÿ ñïèñàííîé ñèñòåìû è
ìà, è îêðóæàþùåé
óíè÷òîæåíèå îòõîäîâ.
ñðåäû â èñõîäíîå
4. Ðàöèîíàëüíîå òðóäîóñòðîéñòâî ñîñîñòîÿíèå
òðóäíèêîâ.
5. Âîçâðàùåíèå
ïðîèçâîäñòâåííîãî
ïðîöåññà è îêðóæàþùåé ñðåäû ê ïåðâîíà÷àëüíîìó ñîñòîÿíèþ èëè ñîñòîÿíèþ, îãîâîðåííîìó â ñîãëàøåíèè
%'
2.3.1. Ïðîöåññû æèçíåííîãî öèêëà ñèñòåì.
Ñòàíäàðò ÃÎÑÒ Ð ÈÑÎ/ÌÝÊ 15288-2005
Перечень работ, которые необходимо выполнить в ходе жизненного цикла ПС, регламентируется в современных стандартах
с помощью понятия процесса.
Процессом называется совокупность взаимосвязанных
действий, преобразующих некоторые входные объекты или
данные в выходные.
Наиболее полный перечень процессов и составляющих их
действий приведен в ГОСТ 15288. Согласно этому стандарту все
процессы разбиты на четыре группы: процессы соглашения,
процессы предприятия, процессы проекта и технические процессы.
Процессы соглашения:
1)процесс приобретения (используется организациями для
приобретения продукции или получения услуг);
2) процесс поставки (используется организациями для поставок продукции или оказания услуг).
Процессы предприятия:
1) управления предприятием;
2) управления инвестициями;
3)управления жизненным циклом системы;
4) управления ресурсами;
5) управления качеством.
Процессы проекта:
1) планирования проекта;
2) оценки проекта;
3) контроля проекта;
4) принятия решений;
5) управления рисками;
6) управления конфигурацией;
7) управления информацией.
Технические процессы:
1) определения требований заказчика;
2) анализа требований;
3) проектирования архитектуры;
4) реализации проекта;
5) комплексирования;
&
6) верификации;
7) передачи заказчику;
8) валидации;
9) функционирования;
10) сопровождения;
11) списания.
В отношении каждого из процессов в стандарте определены
цели, результаты реализации и действия, входящие в процесс.
Всего в стандарте специфицировано 25 процессов, 123 результата реализации и 208 видов работ.
Данный стандарт явился результатом обобщения опыта разработчиков сложных технических систем в оборонно-промышленных комплексах и крупных корпорациях развитых стран (в
том числе и России) и отражает современный взгляд на ЖЦ ПС.
В нем сделана попытка найти компромисс – с одной стороны,
сделать процесс разработки ПС как можно более управляемым
и предсказуемым, а с другой стороны, сделать его достаточно
гибким и способным учитывать изменение требований к системе в процессе разработки. С этой целью стандартом предусматривается возможность использования процессов ЖЦ: однократно, многократно, рекурсивно, последовательно и параллельно.
Работы, входящие в процесс, не привязываются жестко к
конкретным этапам жизненного цикла и в зависимости от характера разработки и решаемых задач могут инициироваться на
любом этапе ЖЦ. Часть процессов и работ при адаптации данного стандарта к конкретному проекту можно исключить из ЖЦ
ПС. Стандарт согласован с требованиями стандартов серии ИСО
9000 и группы стандартов ИСО/МЭК 15504, касающихся оценки зрелости процессов проектирования.
2.3.2. Ïðîöåññû æèçíåííîãî öèêëà ïðîãðàììíûõ
ñðåäñòâ. Ñòàíäàðò ÃÎÑÒ Ð ÈÑÎ/ÌÝÊ 12207-99
Особенностью стандарта ГОСТ Р ИСО/МЭК 12207-99 (далее ГОСТ 12207), который также посвящен ЖЦ ПС, является
то, что он не содержит подробного описания этапов работ. Все
работы по созданию и сопровождению ИС в указанном стандарте рассматриваются с точки зрения процессов. Перечень процессов ЖЦ, приведенный в данном стандарте, незначительно
отличается от перечня, данного в стандарте ГОСТ 15288. Всего в
&
данном стандарте специфицировано 17 процессов, в составе
которых выделено 74 вида работ, которые, в свою очередь, разделены на 232 решаемые задачи. При этом все процессы, в отличие от стандарта ГОСТ 15288, сгруппированы в три класса.
1. Основные процессы: приобретение, поставка, разработка,
эксплуатация, сопровождение.
2. Вспомогательные процессы: документирование, управление
конфигурацией, обеспечение качества, разрешение проблем,
аудит, аттестация, совместная оценка, верификация.
3. Организационные процессы: создание инфраструктуры, управление; обучение, усовершенствование.
Основные процессы протекают под управлением главных
участников, вовлеченных в жизненный цикл ПС – заказчика и
разработчика-поставщика ПС. Вспомогательные и организационные процессы выделены как подчиненные относительно основных, так как они могут быть целенаправленными составными частями других процессов и порождаться основными
процессами. В стандарте достаточно определенно и однозначно
изложено, что должны делать, что могут делать и что рекомендуется делать основным участникам ЖЦ – заказчику, поставщику, разработчику. В то же время не указывается, какими методами должны производиться те или иные работы. Для
определения методов выполнения работ необходимо пользоваться
стандартами и руководствами более низкого уровня.
В стандарте предусмотрена возможность его адаптации к условиям конкретного программного проекта. При этом так же,
как и в стандарте ГОСТ 15288, часть работ и процессов можно
исключить из ЖЦ, используя некоторое подмножество всего
множества процессов и работ, приведенных в стандарте. Такая
возможность делает данный стандарт достаточно гибким.
Особенность стандарта состоит в том, что заказчику отводится весьма активная роль. Предполагается, что заказчик способен сам сформулировать требования к ПС, которые оформляются в виде заявочных предложений в процессе приобретения.
Разработчик подключается к анализу заявочных предложений
на этапе поставки, после заключения договора с заказчиком.
При этом явно не прописан традиционный для российских организаций этап составления технического задания. В России данный стандарт хотя и был принят в 1999 г., но не нашел широкого применения, так как являясь фактически разработкой военного
&
ведомства США, этот стандарт не учитывал сложившийся в России механизм взаимодействия сложных технических систем организаций заказчика и разработчика.
В этом стандарте менее подробно, по сравнению с ГОСТ
15288, описаны некоторые организационные процессы. В частности, явно не упомянуты процессы управления рисками, инвестициями, ресурсами. Во время принятия данного стандарта в
России не был еще введен термин валидация, поэтому в данном
стандарте вместо него использован термин аттестация.
Стандарт ГОСТ 12207 не во всем совместим с ГОСТ 15288.
Есть различия в терминологии, что затрудняет их совместное
использование. В связи с этим разработчику приходится самостоятельно составлять профиль на основе имеющихся стандартов, исходя из специфики решаемых задач, требований заказчика, тенденций на рынке программных продуктов и своих
предпочтений.
2.4. Ìîäåëè æèçíåííîãî öèêëà
ïðîãðàììíûõ ñèñòåì
Наиболее важное применение понятие ЖЦ находит при организации производственного процесса разработки ПС. Принятые международные и национальные стандарты, регламентирующие ЖЦ ПС, разработаны таким образом, чтобы охватить все
множество существующих ПС и все известные методологии программирования. Для более детального описания и регламентации процесса разработки ПС, а также определения последовательности выполнения работ служат модели ЖЦ ПС.
Модель жизненного цикла – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе
разработки, функционирования и сопровождения программного продукта.
Модели жизненного цикла информационных систем предназначены для использования прежде всего создателями, разработчиками таких систем, поэтому в существующих моделях ЖЦ
отражены в первую очередь различные схемы и методологии
создания ПС.
&!
В настоящее время известны и используются следующие
модели жизненного цикла:
• каскадная (водопадная);
• поэтапная с промежуточным контролем;
• спиральная (эволюционная);
• инкрементная.
2.4.1. Êàñêàäíàÿ (âîäîïàäíàÿ) ìîäåëü
Для организации взаимодействия всех участников сложного
проекта необходимо четко определить последовательность их
действий и причинно-следственные связи между ними. Простейшей моделью, позволяющей систематизировать действия
разработчиков, является каскадная (водопадная) модель ЖЦ, которая рассматривает жизненный цикл ПС как последовательность стадий (рис. 2.3). Каждая стадия заканчивается определенным результатом, который используется для принятия
решения и в качестве исходных данных для реализации следующей стадии [27]. Таким образом, модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное
завершение работ на предыдущем этапе.
Рис. 2.3. Каскадная модель жизненного цикла программной системы
&"
Эта модель является классической моделью разработки, которая широко использовалась при создании различных сложных технических систем. В российских стандартах данная модель детально прописана в стандарте ГОСТ 34.601-90 (далее ГОСТ
34). Необходимо отметить, что в данном стандарте, который описывает стадии создания автоматизированных систем, обобщен
опыт, накопленный в СССР в области организации разработки
сложных систем. (Известен целый ряд успешных проектов в
области ядерных и космических исследований, а также военнотехнических разработок, выполненных по каскадной схеме).
Ниже приводятся типовые стадии создания автоматизированной информационной системы согласно этому стандарту (далее термин «информационная система» заменен в целях соблюдения единства терминологии на «программную систему» (ПС)).
С т а д и я 1. Формирование требований к ПС:
• обследование объекта и обоснование необходимости создания ПС;
• формирование требований пользователей к ПС;
• оформление отчета о выполненной работе и тактико-технического задания на разработку.
С т а д и я 2. Разработка концепции ПС:
• изучение объекта автоматизации;
• проведение необходимых научно-исследовательских работ;
• разработка вариантов концепции ПС, удовлетворяющих
требованиям пользователей;
• оформление отчета и утверждение концепции.
С т а д и я 3. Техническое задание:
разработка и утверждение технического задания на создание
ПС.
С т а д и я 4. Эскизный проект:
• разработка предварительных проектных решений по системе и ее частям;
• разработка эскизной документации на ПС и ее части.
С т а д и я 5. Технический проект:
• разработка проектных решений по системе и ее частям;
• разработка документации на ПС и ее части;
• разработка и оформление документации на поставку комплектующих изделий;
• разработка заданий на проектирование в смежных частях
проекта.
&#
С т а д и я 6. Рабочая документация:
• разработка рабочей документации на ПС и ее части;
• разработка и адаптация программ.
С т а д и я 7. Ввод в действие:
• подготовка объекта автоматизации;
• подготовка персонала;
• комплектация ПС поставляемыми изделиями (программными и техническими средствами, программно-техническими
комплексами, информационными изделиями);
• строительно-монтажные работы;
• пусконаладочные работы;
• проведение предварительных испытаний;
• проведение опытной эксплуатации;
• проведение приемочных испытаний.
С т а д и я 8. Сопровождение ПС:
• выполнение работ в соответствии с гарантийными обязательствами;
• послегарантийное обслуживание.
Основным достоинством каскадной модели является явное
описание всех этапов работы и определение последовательности их реализации. Согласно этой схеме, на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности.
Выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Имеется возможность сопоставлять и
оценивать различные варианты их реализации, а также накапливать статистические данные о фактической трудоемкости и
затратах на реализацию каждого этапа.
Стадии и этапы создания ПС, выполняемые организациямиучастниками, прописываются в договорах и технических заданиях
(ТЗ) на выполнение работ. Техническое задание является ключевым документом для создания ПС и ее приемки. При этом ТЗ
разрабатывает организация-исполнитель, согласуя его с заказчиком. В дополнение к техническому заданию разрабатывается календарный план проведения работ. Согласование стоимости работ происходит, как правило, на начальных стадиях работы над
проектом и закрепляется протоколом согласования договорной
цены.
&$
Подразумевается, что коллектив разработчиков организован
по иерархическому принципу. Имеется руководитель проекта,
который знает, какие человеческие и материальные ресурсы он
может привлечь для разработки ПС.
Необходимо отметить, что в стандарте ГОСТ 34 учтен опыт
применения каскадной схемы к реальным проектам и стандарт
допускает достаточную гибкость в реализации данной схемы. В
зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ПС, стадии
и этапы работ могут иметь различную длительность и трудоемкость. В дополнение к основному ТЗ можно в процессе разработки создавать частные технические задания, что позволяет в
некоторой степени учитывать изменения требований к системе
в ходе разработки.
Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до
окончания предыдущей.
Один из недостатков стандарта ГОСТ 34 состоит в том, что в
нем слабо отражены процессы управления. Это затрудняет использование данного стандарта в инкрементных моделях ЖЦ
(см. далее) и для больших групп исполнителей, работающих над
сложными проектами и системами.
Каскадная модель не потеряла своего значения и сегодня,
так как она идеально подходит для проектов, в которых требования к разрабатываемой ПС можно сформулировать на начальных стадиях разработки (обычно это относительно небольшие и
несложные проекты). В случае применения данной модели к
более крупным и сложным проектам начинают проявляться ее
недостатки.
Основным недостатком каскадной модели разработки является то, что реальный процесс создания системы никогда полностью не укладывается в жесткую каскадную схему, постоянно
возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. Это приводит
к существенной задержке получения результата и возрастанию
уровня риска, связанного с созданием системы, не удовлетворяющей требованиям заказчика.
&%
2.4.2. Ïîýòàïíàÿ ìîäåëü
ñ ïðîìåæóòî÷íûì êîíòðîëåì
Поэтапная модель с промежуточным контролем, показанная
на рис. 2.4, является модификацией предыдущей модели. Разработка ПС в этой модели ведется итерациями с циклами обратной связи между этапами. Каждый этап завершается контролем
качества соответствующего продукта, и по результатам контроля принимается решение либо о переходе к следующему этапу,
либо о возврате (в случае обнаружения недостатков) на предыдущие этапы. Межэтапные корректировки позволяют учитывать
реально существующее взаимовлияние результатов разработки
на различных этапах; время жизни каждого из этапов фактически растягивается на весь период разработки. Возможность итераций частично снимает недостатки каскадной модели ЖЦ.
Рис. 2.4. Поэтапная модель с промежуточным контролем
Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе в любой момент времени. Согласование результатов разработки с
пользователями производится только в точках, планируемых
после завершения каждого этапа работ, что приводит к позднему обнаружению проблем. При этом общие требования к ПС
зафиксированы в виде технического задания на все время ее
создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям.
&&
2.4.3. Ñïèðàëüíàÿ ìîäåëü
С увеличением сложности разрабатываемых ПС, сроков разработки и неопределенности требований, которым должна будет удовлетворять будущая ПС, появляется необходимость разработки в несколько итераций. На рис. 2.5 приведена схема
спиральной модели жизненного цикла ПС1. На первом витке
спирали обычно разрабатывается прототип ПС.
Рис. 2.5. Спиральная модель жизненного цикла программной системы
Прототип программы – версия программы, предназначенная для демонстрации ее основных свойств.
Каждый виток раскручивающейся спирали представляет собой законченный цикл разработки ПС, приводящий к созданию очередной промежуточной версии. На каждом витке уточняются цели, требования и характеристики проекта, определяется
его качество и планируются работы следующего витка. В данной модели нет необходимости полного и точного формулиро1
В последнее время спиральную модель ЖЦ часто стали называть
эволюционной.
&'
вания требований к системе на начальной стадии, поскольку
они уточняются на каждой итерации.
История появления данной модели восходит к 1930–1950-м гг.
и к идеям Вальтера Шухарта и Эдвардса Деминга. Они предложили спиральную модель управления качеством продукции,
которая стала универсальной и применимой к различным процессам управления. Цикл в их модели включает фазы: планируй
(Plan), делай (Do), проверяй (Check), воздействуй (Act).
Фактически спиральная модель жизненного цикла ПС является примером применения классического цикла Шухарта–Деминга.
Достоинством спиральной модели является то, что до реализации доводится обоснованный окончательный вариант ПС,
который удовлетворяет действительным требованиям заказчика. Таким образом, снижаются риски, связанные с неправильным пониманием потребностей заказчика ПС. Кроме этого снижаются риски, обусловленные техническими трудностями в
реализации требований заказчика, так как предлагаемые пути
реализации требований апробируются при выпуске промежуточных версий.
Другим достоинством спиральной модели по сравнению с
каскадной является ускорение разработки ПС, обусловленное
более активным привлечением заказчика к формированию требований на основе анализа работы прототипов, а также интенсификация труда разработчиков ПС. Сам жизненный цикл ПС,
построенный по спиральной модели, позволяет создавать развивающиеся системы, обладающие большей восприимчивостью
к изменениям требований.
Главный недостаток спиральной модели – сложность планирования работ, оценки затрат, сроков и рисков выполнения
проекта. Соответственно сложным оказывается этап заключения договора с заказчиком, в котором необходимо явно прописать сроки выполнения и привлекаемые ресурсы. Не случайно
военное ведомство США разрешило использование в проектах
спиральной модели только в конце 1980-х годов.
Планирование в данной модели обычно производится на
основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Важным при этом является авторитет и репутация разработчика ПС.
'
Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения вводятся
временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже
если не вся запланированная работа закончена.
2.4.4. Èíêðåìåíòíàÿ ìîäåëü
Модификация спиральной модели – инкрементная модель
ЖЦ ПС. В стандарте ГОСТ15288 такая модель выделена в отдельный тип. В отличие от классической спиральной модели, в
инкрементной модели (рис. 2.6) сразу существует несколько
комплектов исходных требований к системе с разной степенью
полноты. Под каждый набор требований создается своя версия
системы. Причем это создание может идти не только по спирали: например, разные версии могут разрабатываться параллельно. Это позволяет сделать расстояние между витками спирали
меньше, чем в классической спиральной модели. Обычно при
использовании данной модели выделяют базовый набор требований к системе и в качестве нулевой итерации разрабатывают
базовую версию ПС.
Рис. 2.6. Инкрементная модель жизненного цикла
программной системы
'
В реальных проектах применяют, как правило, комбинацию
спиральной и инкрементной моделей. На начальных стадиях,
когда нет возможности точно сформулировать все требования к
ПС, используется спиральная модель. На завершающих стадиях
разработки, когда все требования к ПС могут быть определены,
применяют инкрементную модель.
Основная проблема в инкрементной модели разработки –
согласование изменений, вносимых в систему параллельными
процессами разработки, поэтому особое значение при использовании данной модели приобретает процесс управления конфигурацией. Этот процесс предполагает постоянный мониторинг и контроль версий программного кода, документации,
аппаратных настроек и других компонентов проекта. Управление конфигурацией, в свою очередь, служит эффективным инструментом управления изменениями в проекте, который регламентирует процесс внесения изменений в компоненты проекта
от запроса на изменение до включения его в базовую версию.
На рис. 2.6 процесс управления конфигурацией иллюстрируется
пунктирными стрелками.
Наиболее яркий пример использования инкрементной модели – параллельная разработка нескольких типов ОС Windows.
Недостатками данной модели является повышение рисков,
связанных с возможной несогласованностью различных модулей
системы в результате несогласованности действий разработчиков.
Для решения этой проблемы фирма Microsoft предлагает использовать (и сама успешно использует) ежедневную сборку всей системы, в которой суммируются и проверяются на согласованность
разработки большого количества групп, работающих параллельно над разными функциональными модулями системы.
2.5. Äîêóìåíòàëüíîå ñîïðîâîæäåíèå ýòàïîâ
æèçíåííîãî öèêëà ïðîãðàììíîé ñèñòåìû
Документация – важная составная часть программной системы. Все этапы ЖЦ ПС сопровождаются разработкой соответствующей документации, в которой отражаются достигнутые
договоренности, принятые решения и другие аспекты разработки
ПС. Документация включает в себя различные концептуальные,
проектные, рабочие, отчетные, эксплуатационные и организационно-распорядительные документы. При этом все компоненты
'
документации должны быть согласованы между собой. Например,
требования пользователей, зафиксированные в виде сценариев
использования, должны найти свое отражение в техническом
задании на выполнение разработки. Положения технического
задания должны быть отражены в проектной и рабочей документации, а также в программе и методике испытаний и эксплуатационных документах. Разработка и поддержание всех этих документов в актуальном состоянии является непростой задачей.
На рис. 2.7 приведена схема функционального взаимодействия различных видов документации на разных этапах ЖЦ ПС.
Наиболее важную роль среди всех документов играет техническое задание. Исходными документами для составления технического задания могут быть отчеты об исследовании объектов
автоматизации, пожелания пользователей (user story), пояснительные записки и т.д. Большинство остальных документов согласуются именно с техническим заданием.
Этапы проектирования и реализации программной системы
сопровождаются составлением проектной документации, в которой содержатся сведения об архитектуре разрабатываемой системы, модульном составе, спецификациях на каждый модуль,
исходный программный код самих модулей и т.д.
В свою очередь, на заключительных этапах разработки особую важность имеют такие документы, как программа и методика испытаний, описания различных видов тестов, отчеты о
результатах тестирования и другая документация по тестированию ПС.
Наконец, на этапах внедрения и сопровождения программной системы важными документами являются руководства и
инструкции для пользователей и программистов, обслуживающих программную систему, а также документация, подтверждающая авторские права, сертификаты соответствия, лицензионные соглашения и т.д.
Существуют различные стандарты на состав программной
документации и форму отдельных документов. Многие ведущие
фирмы – разработчики программного обеспечения используют
собственные стандарты на документацию. Также общепризнанными мировыми стандартами на программную документацию
являются отраслевые стандарты IEEE (Institute of Electrical and
Electronic Engineering).
'!
Рис. 2.7. Схема создания и использования
программной документации
В России действуют два стандарта на состав программной
документации– «ГОСТ 19.101-77 Виды программ и программных документов» (далее ГОСТ 19.101) [3] и «ГОСТ 34.201-89
Виды, комплектность и обозначение документов при создании
автоматизированных систем» (далее ГОСТ 34.201) [5].
Обычно ГОСТ 19.101 применяют в случае разработки отдельной программы или относительно несложной программной системы. ГОСТ 34.201 представляет более полное множество программных документов и применяется в случае разработки
'"
сложных программных систем. Оба этих стандарта являются в
достаточной степени гибкими и позволяют разработчикам по
согласованию с заказчиком объединять некоторые документы в
один документ или отказываться от ряда документов, если в них
нет необходимости.
Содержание программных документов, указанных в ГОСТ
19.101, регламентируется серией стандартов ГОСТ 19.***. Содержание документов из ГОСТ 34.201 регламентируется стандартами ГОСТ 34.602-89 [6] и РД 50-34.698-90 [11]. Рассмотрим
подробнее, какие документы предусматривают эти стандарты,
поскольку взаимодействие заказчиков и разработчиков в России чаще всего регламентируется именно этими стандартами.
Полный перечень документов, разрабатываемых на стадиях
жизненного цикла, приведен в ГОСТ 34.201-89. Разработчик совместно с заказчиком определяет перечни документов, которые
необходимо разработать на каждой стадии. После согласования
состав необходимых документов фиксируется в техническом задании. В табл. 2.5 приведен примерный перечень документов для
каждой стадии жизненного цикла.
Т а б л и ц а 2.5
Перечень документов, разрабатываемых на этапах ЖЦ
согласно стандарту ГОСТ 34.201-89
Ñòàäèÿ ñîçäàíèÿ
ÏÑ
Ðàçðàáîòêà êîíöåïöèè ÏÑ
Ïðåäúÿâëÿåìûå
äîêóìåíòû
Îò÷åò î ÍÈÐ
Ôîðìèðîâàíèå
òðåáîâàíèé ê ÏÑ
Îò÷åò îá îáñëåäîâàíèè îáúåêòà êîìïüþòåðèçàöèè
Òåõíè÷åñêîå çàäàíèå
Òåõíè÷åñêîå
çàäàíèå (ÒÇ)
Ýñêèçíûé ïðîåêò
Âåäîìîñòü ýñêèçíîãî
ïðîåêòà
Ïîÿñíèòåëüíàÿ
çàïèñêà ê ýñêèçíîìó
ïðîåêòó
Êîììåíòàðèé
Îáû÷íî ÍÈÐ âûïîëíÿåòñÿ
ïåðåä ðàçðàáîòêîé ïðèíöèïèàëüíî íîâîé ÏÑ
Áèçíåñ-ìîäåëü êîìïüþòåðèçèðîâàííîãî ïðîöåññà ñ
óêàçàíèåì ìåñòà è ðîëè ÏÑ
Òðåáîâàíèÿ ê ñîäåðæàíèþ,
ñòðóêòóðå è îôîðìëåíèþ ÒÇ
îïðåäåëåíû â ÃÎÑÒ 34.60289 [6]
Ïåðå÷åíü äîêóìåíòîâ ýñêèçíîãî ïðîåêòà
Îáîñíîâàíèå
ïðèíÿòûõ
ïðîåêòíûõ ðåøåíèé
'#
Продолжение
Ñòàäèÿ ñîçäàíèÿ
ÏÑ
Ïðåäúÿâëÿåìûå
äîêóìåíòû
Ñõåìà îðãàíèçàöèîííîé ñòðóêòóðû
Ñõåìà ôóíêöèîíàëüíîé ñòðóêòóðû
Òåõíè÷åñêèé
ïðîåêò
Ðàáî÷àÿ
äîêóìåíòàöèÿ
Âåäîìîñòü òåõíè÷åñêîãî ïðîåêòà
Ñõåìà ñòðóêòóðíàÿ
êîìïëåêñà òåõíè÷åñêèõ ñðåäñòâ
Ïîÿñíèòåëüíàÿ
çàïèñêà ê òåõíè÷åñêîìó ïðîåêòó
Âåäîìîñòü îáîðóäîâàíèÿ è ìàòåðèàëîâ
Ïðåäâàðèòåëüíàÿ
ñìåòà çàòðàò
Âåäîìîñòü ýêñïëóàòàöèîííûõ äîêóìåíòîâ
Ïàñïîðò èëè
Ôîðìóëÿð
Îáùåå îïèñàíèå
ñèñòåìû
Ïðîãðàììà è
ìåòîäèêà èñïûòàíèé
'$
Êîììåíòàðèé
Ñõåìà âçàèìîäåéñòâèÿ ó÷àñòíèêîâ êîìïüþòåðèçèðóåìîãî ïðîöåññà
Èåðàðõè÷åñêèé ïåðå÷åíü
ôóíêöèé ÏÑ ñ óêàçàíèåì
âçàèìîñâÿçåé ìåæäó ôóíêöèÿìè
Äîêóìåíòû òåõíè÷åñêîãî ïðîåêòà îòëè÷àþòñÿ áîëåå ãëóáîêîé ïðîðàáîòêîé è íàëè÷èåì
ïðîãðàììíîãî êîäà, ðåàëèçóþùåãî óêàçàííûå òðåáîâàíèÿ
Îêîí÷àòåëüíàÿ ñìåòà çàòðàò
ìîæåò ïîÿâèòüñÿ òîëüêî
ïîñëå çàâåðøåíèÿ ïðîåêòà
Òðåáîâàíèÿ ê ñîäåðæàíèþ
äîêóìåíòà ïðèâåäåíû â ÐÄ
50-34.698-90, ÃÎÑÒ 34.201
Ðàçðàáàòûâàåòñÿ
òîëüêî
îäèí äîêóìåíò èëè «Ïàñïîðò», èëè «Ôîðìóëÿð»
Äîêóìåíò íå ðàçðàáàòûâàåòñÿ, åñëè íà ñòàäèè «Òåõíè÷åñêèé ïðîåêò» ðàçðàáàòûâàåòñÿ äîêóìåíò «Ïîÿñíèòåëüíàÿ çàïèñêà ê òåõíè÷åñêîìó ïðîåêòó»
Äîêóìåíò äîëæåí ñîäåðæàòü
îïèñàíèÿ ìåòîäîâ èñïûòàíèÿ äëÿ êîíòðîëÿ âûïîëíåíèÿ âñåõ òðåáîâàíèé, çàïèñàííûõ â ÒÇ. Äîïóñêàþòñÿ
ññûëêè íà ñòàíäàðòíûå ìåòîäû èñïûòàíèé
Продолжение
Ñòàäèÿ ñîçäàíèÿ
ÏÑ
Ïðåäúÿâëÿåìûå
äîêóìåíòû
Ñïåöèôèêàöèÿ
îáîðóäîâàíèÿ
Èíñòðóêöèÿ ïî ýêñïëóàòàöèè êîìïëåêñà
òåõíè÷åñêèõ ñðåäñòâ
Ñõåìû ñîåäèíåíèÿ
è ïîäêëþ÷åíèÿ
âíåøíèõ óñòðîéñòâ
Ðóêîâîäñòâî ïîëüçîâàòåëÿ
Ðóêîâîäñòâî ñèñòåìíîãî àäìèíèñòð àòîðà
Ðåãëàìåíò øòàòíîãî
îáñëóæèâàíèÿ
Ðåãëàìåíò àâàðèéíîãî îáñëóæèâàíèÿ
Ðåãëàìåíò îïûòíîé
ýêñïëóàòàöèè
Êîììåíòàðèé
Ïåðå÷åíü òðåáîâàíèé ê îáîðóäîâàíèþ ÏÑ. Òðåáîâàíèÿ ê
ñîäåðæàíèþ äîêóìåíòîâ ïðèâåäåíû â ÃÎÑÒ 21.110
Òðåáîâàíèÿ ê ñîäåðæàíèþ
äîêóìåíòîâ ïðèâåäåíû â ÐÄ
50-34.698-90 [11]
Îïèñàíèå ìåòîäîâ ðàáîòû ñ
ÏÑ, îðèåíòèðîâàííîå íà
ïîëüçîâàòåëÿ
Äîêóìåíò, ðåãëàìåíòèðóþùèé
ïðàâà è îáÿçàííîñòè ïåðñîíàëà ÏÑ, ïðîöåäóðû îðãàíèçàöèè äîñòóïà, îáåñïå÷åíèÿ
ðàáîòîñïîñîáíîñòè è áåçîïàñíîñòè ÏÑ
Äîêóìåíò, ðåãëàìåíòèðóþùèé
óñëîâèÿ îáñëóæèâàíèÿ ÏÑ â
øòàòíîì ðåæèìå, ïðîâåäåíèå
ìîíèòîðèíãà è ðåçåðâíîãî êîïèðîâàíèÿ, îðãàíèçàöèþ àíòèâèðóñíîé çàùèòû è äðóãèõ
øòàòíûõ îïåðàöèé
Äîêóìåíò, êëàññèôèöèðóþùèé
îñíîâíûå òèïû ñáîåâ, îïèñûâàþùèé ìåòîäû âîññòàíîâëåíèÿ ðàáîòîñïîñîáíîñòè ÏÑ è
åå ïîäñèñòåì ïîñëå ñáîåâ óêàçàííûõ òèïîâ
Äîêóìåíò, îïðåäåëÿþùèé öåëè, ïðîäîëæèòåëüíîñòü è ïîðÿäîê ïðîâåäåíèÿ îïûòíîé
ýêñïëóàòàöèè. Ñîäåðæèò ïåðå÷íè õàðàêòåðèñòèê, êîíòðîëèðóåìûõ â õîäå îïûòíîé
ýêñïëóàòàöèè, ïîðÿäîê è ìåòîäû èõ êîíòðîëÿ
'%
Продолжение
Ñòàäèÿ ñîçäàíèÿ
ÏÑ
Ââîä â ïðîìûøëåííóþ ýêñïëóàòàöèþ
Ïðåäúÿâëÿåìûå
äîêóìåíòû
Èíñòðóêöèÿ ïî ôîðìèðîâàíèþ è âåäåíèþ áàçû äàííûõ
Ïðîãðàììà ââîäà ÏÑ
â ïðîìûøëåííóþ
ýêñïëóàòàöèþ
Ïðîãðàììà îáó÷åíèÿ
ïåðñîíàëà
Êîììåíòàðèé
Äîêóìåíò, îïðåäåëÿþùèé
èñòî÷íèêè ïîïîëíåíèÿ èíôîðìàöèè ÏÑ, ïðîöåäóðû
ïîëó÷åíèÿ è îáíîâëåíèÿ
íåîáõîäèìîé èíôîðìàöèè,
ìåòîäû îáåñïå÷åíèÿ öåëîñòíîñòè è àêòóàëüíîñòè
èíôîðìàöèîííîé áàçû ÏÑ
Äîêóìåíò,
óñòàíàâëèâàþùèé
ïîñëåäîâàòåëüíîñòü
ýòàïîâ ââîäà è ïåðå÷íè
ìåðîïðèÿòèé íà êàæäîì
ýòàïå
Äîêóìåíò,
êëàññèôèöèðóþùèé ïåðñîíàë, îïðåäåëÿþùèé öåëè, òðåáîâàíèÿ è
ó÷åáíûå ïëàíû äëÿ êàæäîé
êàòåãîðèè ïåðñîíàëà
Документы, предусмотренные в соответствующих международных стандартах или национальных стандартах ведущих зарубежных стран, аналогичны по своему функциональному назначению тем, что приведены выше, хотя отличаются по своим
названиям и форме. Необходимо напомнить, что следование
стандартам – дело добровольное. Выбор стандартов является
результатом договоренностей заказчика и разработчика. Как
известно, «кто платит – тот и заказывает музыку»: российские
заказчики с большей вероятностью предпочтут отечественные
стандарты, в то время как зарубежные скорее всего потребуют
от разработчика выполнения международных стандартов документооборота.
2.6. Ôèðìåííûå (êîðïîðàòèâíûå) òåõíîëîãèè
ðàçðàáîòêè ïðîãðàììíîé ñèñòåìû
Ведущие фирмы – разработчики программного обеспечения
в наибольшей степени заинтересованы в развитии современных
методов разработки ПС. Некоторые из них разработали собствен'&
ные стандарты и методологии разработки ПС и выпустили инструментальное программное обеспечение, позволяющее вести автоматизированную разработку ПС следуя их стандартам (табл. 2.6).
Т а б л и ц а 2.6
Наиболее известные «фирменные» (корпоративные)
методологии разработки ПС
Èíñòðóìåíòàëüíîå
ñðåäñòâî àâòîìàòèçèðîâàííîé ðàçðàáîòêè
Microsoft Solutions
Microsoft Visual Studio
Framework (MSF)
ðàçðàáîòêà êîìïàíèè Microsoft
Íàçâàíèå ìåòîäîëîãèè
Êîììåíòàðèé
Còàíäàðò,
îðèåíòèðîâàííûé íà ñïèðàëüíóþ è
èíêðåìåíòíóþ
ìîäåëè
ðàçðàáîòêè. Âêëþ÷èë â
ñåáÿ îïûò Microsoft ïî
ðåàëèçàöèè
ðàçëè÷íûõ
ïðîãðàììíûõ ïðîåêòîâ
Rational Unified
Rational Rose ïðîåêòèðî- Îáúåìíûé
ñòàíäàðò,
Process (RUP)
âàíèå è ìîäåëèðîâàíèå
îðèåíòèðîâàííûé
íà
ðàçðàáîòêà êîìïà- èíôîðìàöèîííûõ ñèñòåì
ñïèðàëüíóþ è èíêðåíèè Rational
è áèçíåñ-ïðîöåññîâ.
ìåíòíóþ ìîäåëè ðàçðàSoftware, âõîäÿRational SoDa àâòîìàòè- áîòêè, à òàêæå íà îáúùåé â ñîñòàâ
çàöèÿ ïðîöåññà ñîçäàíèÿ
åêòíî-îðèåíòèðîâàííîå
êîðïîðàöèè IBM äîêóìåíòàöèè.
ïðîåêòèðîâàíèå (ÎÎÏ) ñ
Rational RequisitePro
ïîìîùüþ CASE-ñðåäñòâ
óïðàâëåíèå òðåáîâàíè ÿìè. è ÿçûêà UML. ÏðåòåíäóRational ClearQuest
åò íà ðîëü ìèðîâîãî êîðóïðàâëåíèå èçìåíåíèÿìè
ïîðàòèâíîãî ñòàíäàðòà
â ïðîåêòå. Èíòå ãðèðóåòñÿ
ñ Rational RequisitePro,
Microsoft Project, Test
Manager, ClearCase.
Rational ClearCase èíñòðóìåíò óïðàâëåíèÿ ïðîåêòàìè. Ïîääåðæèâàåò âåðñèîííîñòü äîêóìåíòîâ,
ìîäåëåé è ò.ä.
Rational XDE Professional
v2002: Microsoft.NET
Edition èíòåãðèðóåòñÿ
â Microsoft Visual.NET,
ïîçâîëÿÿ ðàáîòàòü â îäíîé
ñðåäå. Äàåò âîçìîæíîñòü
êàê ãåíåðèðîâàòü êîä
ñîãëàñíî ïîñòðîåííîé
ìîäåëè, òàê è ñîçäàâàòü
øàáëîíû ïðîåêòîâ äëÿ
èñïîëüçîâàíèÿ â áóäóùåì
''
Продолжение
Íàçâàíèå
ICONIX ðàçðàáîòêà êîìïàíèè
ICONIX Software
Engineering, Inc
Oracle Method
ðàçðàáîòêà êîìïàíèè Oracle
Èíñòðóìåíòàëüíîå
ñðåäñòâî àâòîìàòèçèðîâàííîé ðàçðàáîòêè
Ïðåäëàãàåòñÿ èñïîëüçîâàíèå CASE-ñðåäñòâ ðàçðàáîòêè êîìïàíèè Rational
Software
Oracle Developer Suite
Êîììåíòàðèé
Óïðîùåííûé
âàðèàíò
ìåòîäîëîãèè RUP. Îñîáîå âíèìàíèå â ñòàíäàðòå óäåëåíî àíàëèçó òðåáîâàíèé è íà÷àëüíûì
ñòàäèÿì ïðåêòèðîâàíèÿ.
Äëÿ ìîäåëèðîâàíèÿ èñïîëüçóåòñÿ óïðîùåííîå
ïîäìíîæåñòâî
ÿçûêà
UML
Ïðåäóñìàòðèâàåò
êàñêàäíóþ è èòåðàöèîííûå
ìîäåëè ðàçðàáîòêè
В целом фирменные методологии не противоречат рассмотренным выше международным и национальным стандартам. Они
в большей степени ориентированы на повышение эффективности, скорости, удешевление разработки при высоком качестве
ПС, а также на выпуск коммерческих ПС, предназначенных для
широкой продажи. С этой целью в фирменных методологиях
упрощен, по сравнению с международными стандартами, ряд
этапов и процессов разработки. Они содержат больше конкретных и подробных описаний того, как должны проводиться те
или иные работы, имеют богатую практику успешного использования своих методов. Включенные в фирменные стандарты
процессы и работы адаптированы к реальным условиям разработки и позволяют достичь необходимой эффективности. Практически все фирменные методологии используют спиральную и
инкрементную модели ЖЦ.
Хотя между фирменными технологиями и международными
стандартами имеются существенные различия в терминологии и
в распределении работ по этапам и процессам, часто их можно
рассматривать как некоторое подмножество вышеописанных
международных стандартов.
Главной проблемой при использовании фирменных и международных стандартов в России является их согласование с существующей системой взаимоотношений разработчиков и заказчиков и адаптация к российским стандартам ведения документации.
Стандарты и модели жизненного цикла ПС корпорации Microsoft.
Рассмотрим особенности фирменных стандартов на примере
корпорации Microsoft– лидера в разработке коммерческих ПС.
Стремясь достичь максимальной отдачи от IT-проектов, корпорация Microsoft разработала две связанные и дополняющие друг
друга фирменные методологии: Microsoft Solutions Framework
(MSF) – для процессов разработки ПС и Microsoft Operations
Framework (MOF) – для процессов сопровождения и эксплуатации ПС [40]. Эти методологии базируются на опыте, полученном корпорацией Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения,
а также на опыте консультантов Microsoft, разрабатывавших
проекты на предприятиях заказчиков.
Как отмечалось выше, в основе большинства разработок корпорации Microsoft лежит спиральная и инкрементная модели
ЖЦ. Именно этим моделям следовали разработчики операционных систем семейства Windows. Причем, если на начальных
стадиях проектирования, когда коллектив исполнителей был
сравнительно немногочисленным, использовалась классическая
спиральная модель, то по мере развития проекта модель разработки приближалась к инкрементной.
Модель MSF основана на спиральной модели разработки и
состоит из пяти этапов (в терминологии MSF этапы названы
фазами):
• создания общей картины приложения (разработка концепции);
• планирования;
• разработки;
• стабилизации;
• развертывания.
Каждый этап завершается так называемой контрольной точкой, т.е. результаты каждого этапа четко определены, фиксируются и документируются. Порядок и условия перехода к следующему этапу строго оговорены. Рис. 2.8 иллюстрирует этапы и
контрольные точки модели процессов MSF.
Особенностью п е р в о г о э т а п а , на котором происходит
определение основных целей и рамок проекта и выработка концепции, является то, что уже здесь происходит оценка рисков и
составление соответствующего документа со сделанными оценками. Ни этом этапе выясняются приоритетные функциональ
Рис. 2.8. Этапы и контрольные точки модели MSF
ные возможности, которые должны попасть в текущую версию
ПС. Обычно в первые версии Microsoft рекомендует закладывать минимальную, но наиболее важную функциональность (базовые функции), чтобы заказчик как можно быстрее увидел работающее приложение.
В т о р о й э т а п – планирования – в целом соответствует
этапу анализа требований, составления технического задания и
календарного плана, а также оценки стоимости проекта в классической каскадной модели.
Т р е т и й э т а п – разработки – не отличается от этапа реализации в классической каскадной модели.
Ч е т в е р т ы й э т а п – тестирования – в данной модели
назван стабилизацией, что подчеркивает цель данного этапа –
обеспечение стабильной работы ПС. Для достижения поставленной цели необходима тесная взаимосвязь тестировщиков и
разработчиков. Задача первых – выявление как можно большего количества ошибок, задача вторых на этом этапе – исправление найденных ошибок. Для контроля процесса стабилизации
Microsoft предлагает две количественные характеристики – так
называемую точку конвергенции и точку достижения нуля. Точка
конвергенции – это момент времени, когда скорость обнаружения ошибок сравнивается со скоростью их исправления. Точка
достижения нуля – это момент времени, когда имеющийся в
наличии набор тестов не выявляет ни одной ошибки.
П я т ы й э т а п (последний) – развертывания – соответствует
этапу ввода в действие прототипов системы классической спиральной модели ЖЦ ПС.
Разрабатывая решения по методологии MSF, команда создает, тестирует и развертывает базовые функции, а затем в каждой
последующей версии расширяет функциональность. Подобный
подход называют стратегией, основанной на выпуске версий.
Рис. 2.9 иллюстрирует расширение набора функций с каждой последующей версией. Временной интервал между версиями зависит от размера и границ проекта.
Рис. 2.9. Функциональность версий
Фактически данный подход соответствует инкрементной
модели ЖЦ стандарта ГОСТ Р 15288.
!
Особое значение компания Microsoft придает роли личности
разработчика. И это справедливо, так как истории известны случаи успешных проектов, выполненных высококлассными программистами-разработчиками при самом бездарном руководстве.
Но неизвестно случаев выполнения сложных проектов неумелыми программистами-разработчиками, даже при самом замечательном руководстве.
В связи с этим, наряду с моделью процессов в технологии
MSF предусмотрена модель команд (MSF Team Model), которая
применяется для организации проектных команд. Модель команд MSF подчеркивает важность четкого определения ролей,
обязанностей и задач отдельных членов коллектива разработчиков для успеха проекта, а также предполагает повышенную ответственность каждого члена команды. По мнению разработчиков фирмы Microsoft, модель команд MSF легко адаптируется в
соответствии с потребностями и контекстом проекта, размером
команды и опытом членов команды. Модель позволяет создавать эффективные, гибкие и успешные проектные команды.
Согласно этой модели в составе команды разработчиков выделяют следующие роли.
• Менеджер продукта (product management) – отвечает за управление связями с клиентом. На этапе проектирования на эту
роль возлагается сбор клиентских требований и контроль за тем,
чтобы они соответствовали и удовлетворяли все потребности
бизнеса. Менеджер продукта также работает над планом связей
с клиентом в процессе создания и реализации проекта, в том
числе над организацией встреч с клиентом, маркетинговых акций, демонстраций и представления продукта;
• Менеджер программы (program management) – несет ответственность за разработку и поставку решения заказчику в полном соответствии с ограничениями проекта;
• Разработчик (development) – обеспечивает разработку технологического решения в соответствии со спецификациями, предоставленными менеджерами продукта и программы;
• Тестировщик (testing) – отвечает за выявление и устранение всех неполадок и проблем с качеством продукта и дает окончательное добро на выпуск и поставку решения. Тестировщик
оценивает и проверяет корректность набора функций и его соответствие общей концепции и области действия проекта;
"
• Менеджер по выпуску (release management) – отвечает за
развертывание и работу продукта. Он проверяет корректность
инфраструктуры и определяет возможность развертывания и
поддержки продукта;
• Специалист по удобству использования продукта (user
experience) – анализирует потребности и проблемы, возникающие у пользователей, и оценивает продукт на предмет соответствия таким потребностям.
В небольшом проекте отдельные члены проектной команды
часто совмещают несколько ролей. В своих рекомендациях
Microsoft предупреждает, что объединение ролей довольно рискованно, поэтому важно назначать участникам проекта совместимые роли. В табл. 2.7 приводятся совместимости ролей, согласно рекомендациям Microsoft.
Т а б л и ц а 2.7
---
+
--
-+
-
----
+
+
+
-+
Ñïåöèàëèñò
ïî óäîáñòâó
èñïîëüçîâàíèÿ
--
Ìåíåäæåð
ïî âûïóñêó
Òåñòèðîâùèê
--+
+
Ðàçðàáîò÷èê
Ìåíåäæåð ïðîäóêòà
Ìåíåäæåð ïðîãðàììû
Ðàçðàáîò÷èê
Òåñòèðîâùèê
Ìåíåäæåð ïî âûïóñêó
Ñïåöèàëèñò ïî óäîáñòâó
èñïîëüçîâàíèÿ
Ìåíåäæåð
ïðîãðàììû
Ìåíåäæåð
ïðîäóêòà
Таблица совместимости ролей согласно стандарту MSF
+
-+
-
-
Данная таблица составлена с соблюдением следующих принципов:
1) нельзя совмещать разработку с другими видами деятельности – создателей приложения не стоит отвлекать от основной
задачи. Если возложить на разработчиков дополнительные обязанности, то скорее всего график работ будет нарушен, а дату
выпуска продукта придется отодвинуть;
2) нельзя совмещать роли, интересы которых противоположны –
например, менеджер продукта и менеджер программы. Первый
#
хочет выполнить все требования заказчика, второму же надо уложиться в график и бюджет. Если совместить эти роли, возникает
опасность упустить просьбу заказчика о внесении изменений в
проект либо, напротив, принять их без должного анализа влияния на график работ.
Разработка по стандарту MSF поддерживается средой разработки Microsoft Visual Studio.
2.7. Ìåòîäû «áûñòðîé» ðàçðàáîòêè
ïðîãðàììíîé ñèñòåìû
В описанных выше стандартах зафиксированы подходы к
разработке ПС, характерные для крупных коммерческих и государственных структур. Достаточно жесткие требования к формализации и документированию процессов разработки, заложенные в эти стандарты, совершенно необходимы при разработке
крупных и ответственных проектов. Строгое следование рекомендациям стандартов, необходимость документировать каждое действие разработчиков приводит к значительному росту
затрат на разработку ПС и увеличению сроков разработки. Жесткая регламентация всех действий разработчиков снижает гибкость системы управления проектом при учете изменений, возникающих в процессе разработки. Не случайно рассмотренные
методологии принято называть тяжелыми.
В случае разработки относительно небольших проектов, требования к которым не столь жесткие, а их эксплуатация не сопряжена с серьезными рисками, такое «утяжеление» проекта
оказывается неоправданным. В связи с этим методология управления проектом должна подстраиваться под выполняемый
проект в зависимости от двух основных параметров: размеров и
критичности проекта.
Альтернативой тяжелым методологиям в области программной инженерии в последние годы стали облегченные (Light) методологии. Развитие облегченных методологий во многом связано и обусловлено появлением эффективных средств разработки,
позволяющих значительно повысить эффективность повторного использования уже существующего программного кода и упростить процесс сборки приложений из готовых блоков. Для
них характерно: ориентация на личность разработчика, постоянная готовность реагировать на изменения внешних требований,
$
постоянная связь с заказчиком, ориентация на итерационный
процесс разработки с циклом выпуска готовых версий от двух
недель до двух месяцев, меньший по сравнению с тяжелыми
методологиями объем документации. Одной из популярных облегченных методологий сегодня стала методология Agile (дословный перевод этого термина – быстрый, подвижный, живой).
Общепризнанного стандарта методологии Agile не существует.
Ниже приводятся выдержки из «Манифеста Agile» [37], декларирующего основные принципы этой методологии:
«…Мы находим лучшие подходы к разработке проекта, непосредственно участвуя в процессе разработки и помогая другим.
В процессе работы мы пришли к тому, что для нас важнее:
• люди и их взаимодействие, чем процессы и средства;
• работающее ПС, чем исчерпывающая документация;
• сотрудничество с заказчиком, чем обсуждение условий контракта;
• реагирование на изменения, чем следование плану.
Мы не ставим под сомнение важность пунктов справа, в то
же время для нас гораздо важнее записанное слева.
• Наивысшим приоритетом для нас является удовлетворенность заказчика ранними и периодическими поставками ценного для заказчика ПС.
• Мы приветствуем изменения требований даже на поздних
этапах разработки. Agile-процессы готовы к таким изменениям
ради достижения заказчиком конкурентного преимущества.
• Мы готовы выполнять частые поставки работающего ПС.
При этом продолжительность каждой итерации должна быть от
двух недель до двух месяцев, предпочтение отдается коротким
интервалам.
• Потенциальные пользователи системы, являющиеся специалистами в предметной области, и разработчики должны работать вместе каждый день на протяжении всего проекта.
• Привлекайте для работы над проектом мотивированных
людей. Создайте для них все условия, окажите поддержку во
всем, что необходимо, и доверьтесь им – они выполнят работу.
• Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром – непосредственное общение.
• Работающее ПС – главный индикатор продвижения проекта.
%
• Agile-процессы придерживаются равномерного темпа разработки. Работа спонсоров, разработчиков и пользователей должна все время идти в постоянном темпе.
• Постоянное стремление к техническому совершенству и
хороший дизайн системы повышают agility.
• Самые лучшие архитектуры, требования и дизайны систем
создаются самоорганизующимися командами.
• Периодически команда размышляет о том, как достичь большей эффективности, после чего корректирует свой подход к разработке ПС...»
Как видно из приведенной выдержки, основной упор в методе делается на создание сплоченной команды единомышленников-профессионалов и тесное сотрудничество с будущими
пользователями. Крайним проявлением облегченных методологий является методология экстремального программирования (XP).
В этой методологии процесс разработки максимально упрощен
за счет того, что многие работы по выявлению и систематизации требований выполняет сам разработчик, выпускающий программный код. Кроме того, разработчик выполняет и все виды
тестирования ПС, при этом система документации максимально упрощена.
Для небольших коллективов, где межличностные связи играют большую роль, применение быстрых методов разработки
оказывается весьма эффективным. Однако с увеличением числа
сотрудников, работу которых приходится постоянно координировать, быстрые методы повышают риски взаимного непонимания, несогласованности действий и т.д. В этом случае приходится применять более «тяжелые» методы управления проектом.
Интересно, что многие положения облегченных методологий использовались и в космических проектах Национального
авиакосмического агентства США (NASA), что отражено в таком документе, как «Сто правил проектного менеджера NASA»
[45]. Основные положения этого документа выглядят так:
• Принципы управления все те же. Изменились только инструменты. Вы находите людей, которые могут сделать работу и
убираетесь с их пути, чтобы они могли ее делать.
• Не спешите. Для работы необходимо понять последствия
действий, которые вы предпринимаете.
• Большинство проектных менеджеров стали успешными
благодаря силе и навыкам их персонала.
&
• Зерна проблем закладываются на ранних стадиях. Начальное планирование является жизненно важной частью проекта.
• Общение не дешево, но лучший способ понять проблему –
поговорить с правильными людьми. Отсутствие общения на
правильном уровне становится смертельным.
• Нельзя уследить за всем, но можно следить за персоналом.
Он должен знать, что менеджер не будет терпеть плохо выполненную работу.
• Источник многих проблем – это люди, но они никогда это
не признают. Менеджер должен знать людей, работающих над
проектом, чтобы контролировать существующие слабые места.
• Необходимо особенное внимание уделять «работоголикам».
Если они пойдут неверным путем, то могут принести много вреда
за короткое время.
• Если возникла проблема, которая требует дополнительных
людских ресурсов, нужно привлекать их постепенно, как опытный повар, который имеет недосоленное блюдо.
• Необходимо назначить группу аудиторов и систему отчетов. Система отчетов должна быть твердо установлена, тогда она
сможет выжить и будет получен максимум отдачи от нее.
• Отчеты – для тех, кто их пишет, а не для тех, кто их читает.
Отчет считается неудачей, если его писавший ничего из него не
почерпнул.
• Не использовать современные технологии, например, компьютер, является большой ошибкой. Но забывать, что компьютер только симулирует мышление, является еще большей ошибкой.
• Менеджер должен знать свое руководство – некоторые
любят хорошую шутку, другие любят хорошую шутку, если они
рассказали ее сами.
• Менеджер должен знать, кто может принимать решения по
проекту: внутри организации и за ее пределами. Нужно постараться наладить коммуникационный канал с ними на формальной или неформальной основе.
• Для решения проблем требуется время. Необходимо иметь
достаточный запас времени в календарном графике. Если его не
будет, то появится менеджер, который займет ваше место.
• Никогда не принимайте извинений. Вместо этого требуйте
планов действий для выхода из ситуации.
'
Основные концепции облегченных методологий известны и
в России со времен знаменитых «шараг», в которых в свое время
разрабатывались передовые по тем временам технические системы. К сожалению, опыт и методология подбора персонала,
принципы организации и управления работами, обеспечения их
качества и т.д., накопленные такими выдающимися менеджерами сложных технических проектов, как А.Н.Туполев, С.П.Королев, И.В.Курчатов, не нашли должного отражения в существующей системе российских стандартов. По имеющимся
сведениям, использовавшиеся ими методологии разработки представляли симбиоз строгой каскадной модели для руководства
верхнего и среднего уровня и облегченных методологий для коллективов разработчиков более низкого уровня управления.
2.8. Âûáîð è àäàïòàöèÿ ìåòîäîëîãèè ðàçðàáîòêè
На сегодняшний день подавляющее большинство проектов
ПС внедряется с нарушениями требований к качеству, сроков
или сметы. Почти треть проектов информационных систем прекращают свое существование, оставшись незавершенными. Чаще
всего причины провалов связаны с проблемами управления проектами.
Методология разработки ПС находится сейчас в периоде становления, пока она не стала строгой инженерной дисциплиной. Существуют разные взгляды и разные подходы к разработке ПС. Выпущено достаточно большое количество стандартов в
данной области, однако не всегда они согласованы между собой. Для каждого подхода есть примеры его успешного применения и есть случаи, когда применяемый подход приводил к
неудаче.
Какую методологию выбрать в конкретном случае и как ее
адаптировать к реальным условиям конкретного проекта? В рассмотренных стандартах приводится перечень процессов и работ, проводимых на различных этапах ЖЦ разной степени полноты. Содержание работ на различных этапах ЖЦ, а также методики
их проведения отражены без детализации, на методологическом и концептуальном уровнях. Под адаптацией понимается
составление, исходя из стандартного и полного перечня взаимосвязанной и согласованной совокупности процессов и работ,
необходимых для реализации конкретного проекта.
Основными факторами, влияющими на выбор методологии,
являются два: масштаб и критичность проекта.
Масштаб проекта определяется его сложностью. В настоящее время нет общепринятого, строгого определения понятия
«сложность проекта». Можно выделить следующие параметры,
влияющие на сложность программной системы:
Ïàðàìåòð ñëîæíîñòè
Êîëè÷åñòâî ôóíêöèé
è âàðèàíòîâ èõ
èñïîëüçîâàíèÿ
Êîììåíòàðèé
Êîëè÷åñòâî ôóíêöèîíàëüíûõ òðåáîâàíèé
è âàðèàíòîâ ïîâåäåíèÿ ñèñòåìû â çàâèñèìîñòè îò âíåøíåé îáñòàíîâêè íàïðÿìóþ
ñâÿçàíî ñî ñëîæíîñòüþ ðåàëèçàöèè
Ðàçìåðíîñòü çàäà÷è
Êîëè÷åñòâî îáúåêòîâ â ñèñòåìå
Ñâÿçàííîñòü îáúåêòîâ
Êîëè÷åñòâî ñâÿçåé ìåæäó îáúåêòàìè â
ñèñòåìå
Ñëîæíîñòü ìåòîäîâ
Ñëîæíîñòü âçàèìîäåéñòâèé ìåæäó îáúåêè àëãîðèòìîâ
òàìè â ñèñòåìå
Íåêîððåêòíîñòü ðåøàåìûõ
Îòñóòñòâèå íåîáõîäèìîé äëÿ ðåøåíèÿ
çàäà÷
èíôîðìàöèè
Ïðèâîäèò ê íåîáõîäèìîñòè ðàçðàáàòûâàòü
Îòñóòñòâèå ìåòîäîâ ðåøåíèÿ
íîâûå ìåòîäû ðåøåíèÿ èëè èñïîëüçîâàòü
íå ñòðîãèå è ïðèáëèæåííûå ìåòîäû
Èíòåëëåêòóàëüíûé èíòåðôåéñ Ãëóáèíà ïðîðàáîòêè çàïðîñîâ ïîëüçîâàòåëÿ è ðåàêöèè ïðîãðàììû, ñòåïåíü «èíòåëëåêòóàëüíîñòè» ïðîãðàììû
Êà÷åñòâî
Ïîêàçàòåëè êà÷åñòâà ïî ÃÎÑÒ 9126. ×åì
âûøå òðåáîâàíèÿ ê êà÷åñòâó, òåì ñëîæíåå
ðàçðàáîòêà
Àâòîíîìíîñòü/ñèñòåìíîñòü
Íåîáõîäèìîñòü âñòðàèâàíèÿ ñèñòåìû â
äðóãóþ ñèñòåìó áîëåå âûñîêîãî óðîâíÿ
ìîæåò ïðèâîäèòü ê ðîñòó ñëîæíîñòè
Äîëÿ ãîòîâûõ ðåøåíèé
×åì áîëüøå â ïðîãðàììå ìîæíî èñïîëüçîâàòü óíèôèöèðîâàííûõ èëè ãîòîâûõ
ðåøåíèé, òåì îíà ïðîùå
Еще одним фактором, влияющим на выбор методологии разработки, является степень использования готовых компонентов
при разработке ПС. В стандарте ГОСТ Р 12207 приводятся две
крайние характеристики ПС как критерий их классификации–
готовое и неготовое. Однако при разработке в зависимости от
характера проекта может использоваться различное количество
уже готовых программных компонентов (модулей). Чем больше
готовых компонентов можно использовать в проекте, тем, как
правило, более легкая методология может применяться.
Следующий фактор – критичность, он определяет уровень
риска (размер возможного ущерба), связанный с ошибками в
системе. Часто используется шкала, предложенная американским специалистом в области программной инженерии Алистэром Коуберном (Alistair Cockburn), на которой выделяют четыре
уровня критичности: потеря комфорта, потеря части денег, потеря «больших» (всех) денег, потеря жизни.
В международном стандарте ISO/IEC 14598, который регламентирует процесс оценки качества ПС, используется несколько
иная шкала критичности. Эта шкала, приведенная в табл. 2.8,
также содержит четыре уровня и критичность оценивается в четырех аспектах.
Т а б л и ц а 2.8
Шкала критичности ПС согласно ISO/IEC 14598
Óðîâåíü
Àñïåêòû îöåíêè
êðèòè÷- áåçîïàñíîñòè
ýêîíîìè÷êîíôèäåíöèíîñòè
íîñòè
àëüíîñòè
Ìíîæåñòâî
Ôèíàíñîâàÿ Çàùèòà äàííûõ
ëþäåé
êàòàñòðîôà
è ñëóæá ñòðàÀ
ïîãèáíåò
òåãè÷åñêîãî
íàçíà÷åíèÿ
Óãðîçà ÷åëî- Áîëüøèå
Çàùèòà êðèòèâå÷åñêèì
ýêîíîìè÷å- ÷åñêèõ äàííûõ
Â
æèçíÿì
ñêèå ïîòåðè è ñëóæá
Ñ
D
Óãðîçà ñîáñòâåííîñòè,
íåêîòîðûå
ëþäè ìîãóò
ïîëó÷èòü ïîâðåæäåíèÿ
Íåáîëüøàÿ
óãðîçà ñîáñòâåííîñòè,
îòñóòñòâèå
ðèñêà äëÿ
ëþäåé
Ñóùåñòâåííûå ýêîíîìè÷åñêèå
ïîòåðè
Çàùèòà îò
âîçìîæíûõ
îøèáîê
Íåçíà÷èòåëüíûå
ýêîíîìè÷åñêèå ïîòåðè
Êîíêðåòíûå
îïàñíîñòè íå
îïðåäåëåíû
ýêîëîãè÷íîñòè
Íåâîññòàíîâèìûå ðàçðóøåíèÿ
îêðóæàþùåé
ñðåäû
Âîññòàíîâèìûå
ðàçðóøåíèÿ
îêðóæàþùåé
ñðåäû
Ëîêàëüíûå
çàãðÿçíåíèÿ
Îòñóòñòâèå
îïàñíîñòè äëÿ
îêðóæàþùåé
ñðåäû
С ростом критичности программы быстро растет ее трудоемкость и стоимость. В наиболее надежных программах, напри
мер, в программах управления космическими кораблями, стоимость одной строки программного кода достигает 1000 долл.
Масштаб, соотношение параметров сложности и критичность
проекта определяют количество и квалификацию разработчиков,
привлекаемых для реализации проекта, необходимые сроки и
бюджет проекта. Эти же факторы определяют выбор методологии разработки и управления проектом. Чем выше критичность
и сложность проекта, тем более «тяжелая» методология должна
быть использована для его реализации.
Рис. 2.10 иллюстрирует критерии выбора методологии управления для конкретного программного проекта. Отметим, что
невозможность реализации наиболее сложных и амбициозных
проектов в настоящее время в большей степени объясняется не
отсутствием технических возможностей, а отсутствием адекватных методов управления такими проектами. Умение вовремя
выпускать качественные ПС высоко ценится на рынке программных продуктов. Цена (капитализация) фирмы, продемонстрировавшей такое умение, значительно выше, чем у фирм-конкурентов. Если учесть, что стоимость вычислительной техники и
другого оборудования по отношению к их характеристикам постоянно снижается, становится очевидной тенденция: стоимость
фирмы-разработчика ПС все больше определяется квалификацией ее коллектива, эффективностью бизнес-процессов и репутацией фирмы, заработанной ею в предыдущих проектах1.
Рис. 2.10. Области эффективности различных методологий
управления проектом
1
По оценкам западных аналитиков, доля перечисленных факторов в
капитализации ведущих программистских фирм достигает 80%.
!
Характерной особенностью программного обеспечения как
товара, является его относительно низкая стоимость по отношению к выгодам или потерям, связанным с его применением.
Например, в сравнении с внедрением оборудования, удачное
внедрение ПС даст значительно больший эффект на рубль инвестиций. При приобретении делового ПС заказчик в первую
очередь обращает внимание на его качество и особенности внедрения, а уж потом – на цену. В связи с этим качество программного обеспечения играет важнейшую и все повышающуюся
роль при его продвижении.
Качество программного обеспечения зависит от специалистов, участвующих в его разработке, их квалификации, умении
работать в команде, понимать потребности и учитывать мнения
потенциальных пользователей, находить наиболее эффективные
проектные решения и доводить дело до конца.
Современный программный продукт разрабатывают люди
разных профессий, каждый из них вносит свой творческий вклад
в общее дело. Каждый специалист имеет свой опыт, свое видение и свои методы решения возникающих задач. Качественное
ПС возникает только тогда, когда это разнообразие синтезируется в нечто целое, наилучшим образом удовлетворяющее поставленным задачам. Важнейшим фактором обеспечения высокого качества ПС является умение руководства фирмы
организовать и скоординировать работу различных специалистов, ориентировать их на выпуск качественной продукции.
Контрольные вопросы
1. Почему при создании сложных программных проектов
трудоемкость их разработки и риск провала проекта растут гораздо быстрее увеличения функциональности проекта?
2. Что такое жизненный цикл программного продукта, как
это понятие соотносится с понятиями «Жизненный цикл разработки программы» и «Жизненный цикл товара»?
3. Чем отличаются жизненные циклы программ, разрабатываемых по конкретному заказу, и программных продуктов, предназначенных для широкой продажи на рынке?
4. Как соотносятся этапы и процессы жизненного цикла программных систем?
"
5. Перечислите российские и международные стандарты, регламентирующие этапы и процессы жизненного цикла программных продуктов.
6. Какие группы процессов жизненного цикла устанавливают стандарты ГОСТ Р ИСО/МЭК15288-2005 и ГОСТ Р ИСО/
МЭК 12207-99?
7. В чем состоит отличие основных и вспомогательных процессов жизненного цикла программных средств согласно стандарту ГОСТ Р ИСО/МЭК 12207-99?
8. Что такое модель жизненного цикла программной системы?
9. Какие преимущества и недостатки имеет каскадная модель жизненного цикла?
10. Какие преимущества дает применение спиральной и инкрементной моделей жизненного цикла? Какие требования накладывает на разработчика использование этих моделей?
11. Какие документы создаются в процессе разработки программной системы. На каких этапах жизненного цикла следует
начинать и заканчивать разработку этих документов?
12. Перечислите наиболее известные «фирменные» методологии и инструментальные средства разработки программных
систем.
13. Какую модель жизненного цикла использует методология Microsoft Solutions Framework MSF?
14. Каким этапам жизненного цикла классической каскадной модели соответствуют этапы «стабилизация» и «развертывание», используемые в модели MSF?
15. Перечислите роли, которые играют разработчики в рамках модели MSF Team Model. Какие из этих ролей могут быть
совмещены?
16. Что такое «точка конвергенции» и «точка достижения
нуля», используемые в модели MSF? По каким признакам они
определяются и как используются?
17. Перечислите основные принципы, положенные в основу
методологии разработки Agile. Что обеспечивает выигрыш во
времени разработки при применении этой методологии?
18. Возможно ли применение быстрых методов программирования при разработке новой операционной системы уровня
Windows 7? Обоснуйте свой ответ.
#
ÍÀ×ÀËÜÍÛÉ ÝÒÀÏ ÐÀÇÐÀÁÎÒÊÈ.
ÏËÀÍÈÐÎÂÀÍÈÅ È ÎÖÅÍÊÀ ÏÐÎÅÊÒÀ
Начальные этапы разработки исключительно важны для успешности проекта по созданию программной системы. Это утверждение применимо к любым сложным системам. Зерна проблем закладываются на ранних стадиях проекта – это одна из
заповедей проектировщиков.
История разработки программных систем изобилует примерами, когда ошибки, допущенные на начальной стадии при планировании процессов разработки, анализе требований заказчика или оценке рисков, приводили к значительному увеличению
стоимости, сроков выполнения или полному провалу проекта.
Свежий тому пример– провал системы ЕГАИС (Единой государственной автоматизированной информационной системы
учета объема производства и оборота этилового спирта).
На рис. 3.1 показан график величины усилий, необходимых
для исправления ошибок, допущенных на начальном этапе разработки, в зависимости от того, на какой стадии разработки они
обнаружены.
Рис. 3.1. Соотношение усилий на исправление ошибки,
найденной на разных этапах жизненного цикла
$
Рассмотрим более подробно, какие работы выполняются на
начальных этапах жизненного цикла ПС и какие методы применяются, основываясь на представлениях о ЖЦ ПС, даваемых
в ГОСТ Р ИСО/МЭК 15288-2005 и в рамках каскадной модели,
так как состав работ и применяемые методы являются общими
для всех моделей разработки.
Наиболее важными процессами начального этапа являются:
• процессы соглашения – заключение договора между разработчиком и заказчиком;
• процессы проекта – планирование и оценка проекта;
• технические процессы – определение требований заказчика
и анализ требований.
Необходимо отметить, что все эти процессы неразрывно связаны и взаимозависимы.
Ясно, что цели проекта и объем требований заказчика должны быть тесно увязаны с имеющимися ресурсами, планируемыми сроками выполнения проекта и техническими возможностями уже при заключении договора между разработчиком и
заказчиком. При этом процесс разработки системы начинается
с этапа определения и анализа требований заказчика.
3.1. Ïðîáëåìà ôîðìèðîâàíèÿ ñèñòåìû
òðåáîâàíèé ê áîëüøîìó ïðîãðàììíîìó ïðîäóêòó
Задачи формирования, анализа и согласования требований являются наиболее ответственными, трудно формализуемыми и наиболее дорогими и трудными для исправления в случае ошибки [28].
Требование – это условие, которому должна удовлетворять ПС, или свойство, которым она должна обладать.
Глоссарий, приведенный в стандарте IEEE Standard Glossary
of Software Engineering Terminology (1990), определяет требования как:
1) условия или возможности, необходимые пользователю для
решения проблем или достижения целей;
2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт
или удовлетворять стандартам, спецификациям и другим формальным документам;
%
3) документированное представление условий или возможностей для пунктов 1 и 2.
Последовательность этапов в процессе сбора и анализа требований условно можно отобразить каскадной диаграммой, приведенной на рис. 3.2.
Рис. 3.2. Этапы формирования требований к программе
В процессе формирования и анализа требований происходит
постепенный переход от неструктурированных и несогласованных первичных требований, изложенных на языке заказчика, к
упорядоченной системе технических требований, изложенных
на языке разработчика.
Процесс формирования требований со стороны разработчика должен сопровождаться углубленным изучением предметной
области, для которой разрабатывается ПС, и активным взаимодействием разработчика со всеми сторонами, являющимися источниками первичных требований.
3.1.1. Ôîðìèðîâàíèå ïåðâè÷íûõ òðåáîâàíèé
На начальном этапе разработки важно понять, кто может
предъявлять требования, как получить доступ к их источникам
и как извлекать из этих источников информацию. В силу этого
&
процесс формирования требований начинается с определения
основных источников, порождающих требования. Такими источниками могут быть: руководство заказчика системы, пользователи системы, рынок и маркетинговый отдел разработчика,
общество, сами разработчики, организации, занимающиеся
сопровождением и ремонтом системы, регулирующие органы и
т.д. Кроме этого, источниками требований могут выступать стандарты и технические регламенты, предметная область ПС, система более высокого уровня, в которую будет встраиваться разрабатываемая система, сама информационная технология
(IT-отрасль). На рис. 3.3 схематично показан процесс сбора первичных требований с указанием типовых методов, применяемых в этом процессе разработчиками. Со стороны разработчика
основным действующим лицом в этом процессе обычно выступает системный аналитик, аналитик требований или менеджер
продукта в терминологии стандарта MSF от корпорации Microsoft.
Рис. 3.3. Наиболее важные источники и методы сбора
первичных требований
'
В существующих стандартах не оговорены формы, в которых фиксируются первичные требования. Это могут быть варианты и сценарии использования, текстовые описания, модели,
выраженные в текстовой и графической форме. Непреложным
и обязательным правилом является лишь то, что все требования
должны быть документированы.
Хорошим ориентиром при формировании первичных требований может стать набор характеристик качества, определенный и систематизированный в стандарте ISO/IEC 9126-1:2001
(см. гл. 1), который устанавливает модель характеристик качества программной продукции (в России в качестве национального стандарта ГОСТ Р ИСО/МЭК 9126-93 принята первая редакция этого международного стандарта).
Общая цель разработки формулируется обычно на уровне
руководства заказчика. Требования, формулируемые на уровне
руководства заказчика, иногда называют бизнес-требованиями.
Перечислим основные вопросы, которые должны быть заданы руководству на этом этапе и на которые желательно получить содержательные ответы:
• Какова цель проекта?
• Какие наиболее важные задачи должна решать система?
• Какие ресурсы могут быть привлечены?
• На какой платформе должна работать система?
• Сколько пользователей одновременно будет работать?
• Какие существуют ограничения, накладываемые, например,
аппаратным обеспечением?
• Насколько важна защита данных в системе?
• Какова должна быть надежность?
• Когда может потребоваться модернизация системы?
• Как быстро должны быть учтены новые требования пользователей?
Ответы на эти вопросы позволят установить так называемые
границы проекта.
Бизнес-требования, содержащие основные цели проекта, желательно оформить отдельным документом (например, в виде
протокола совещания). Все остальные требования должны согласовываться именно с этим главным набором требований. Часто
бизнес-требования содержат обоснование необходимости разработки новой ПС, описание проблемы, которую решает система, оценку и способы минимизации рисков проекта и критерии
достижения целей проекта.
После обсуждения данных вопросов с руководством необходимо собрать пожелания непосредственных пользователей системы (это совсем другие люди). Требования пользователей обычно
составляют основу так называемых функциональных требований,
т.е. требований, содержащих описание того, что конкретно должна делать система. При этом пожелания пользователей могут
не совпадать, а зачастую и противоречить требованиям руководства. Требования пользователей оформляют в виде вариантов использования, таблиц «событие–отклик» или в виде описания отдельных функций, которые должны быть реализованы
в системе.
Пример варианта использования – «Сделать заказ: билетов
на самолет, аренды автомобиля, гостиницы через Интернет».
Пример описания отдельной функции– «Система должна по
электронной почте отправлять пользователю подтверждение о
заказе».
Если требования пользователей противоречат основным целям проекта, изложенным в бизнес-требованиях, то они пересматриваются или отклоняются.
Полученный набор требований дополняется также требованиями, выявленными при изучении предметной области, требованиями, установленными действующими техническими регламентами и всеми другими требованиями, полученными из
различных источников. Наряду с функциональными требованиями на этом этапе формируются и нефункциональные требования, основу которых составляют такие характеристики качества
ПС, как надежность, практичность, эффективность, сопровождаемость и мобильность.
Главное и непреложное условие на этом этапе – ни одно
требование не должно быть потеряно. А главная сложность состоит в том, что первичные требования имеют несколько источников, не всегда очевидны, почти всегда взаимозависимы и часто противоречивы.
3.1.2. Àíàëèç ïåðâè÷íûõ òðåáîâàíèé
Для того чтобы собранный набор требований превратился в
целостную систему, необходимо провести его анализ. К сожалению, до настоящего времени не существует строго формализованных процедур такого анализа. Можно дать лишь общие ре
комендации аналитику, выполняющему эту творческую работу.
Ему необходимо:
• выявить в имеющихся описаниях элементарные требования;
• привести описания к единой терминологии, при необходимости составить глоссарий проекта;
• выявить объекты требований;
• провести классификацию требований, выявив отдельные
группы требований и построив иерархическую систему классов
требований;
• ранжировать требования по значимости;
• выявить и устранить противоречия в требованиях или достичь компромисса.
В результате этой работы должен быть сформирован общий
набор требований к ПС, который отвечает следующим критериям:
1) набор должен быть полным, т.е. ни одно требование, влияющее на успешность проекта, не должно быть потеряно или
забыто;
2) каждое требование в наборе должно быть корректным,
однозначным и четко определенным, т.е. требование должно
одинаково пониматься всеми участниками проекта и точно описывать желаемую функциональность;
3) каждое требование в наборе должно быть необходимым,
требования, не влияющие на успешность проекта, должны быть
исключены (все лишнее стоит времени и денег);
4) каждое требование в наборе должно быть реализуемым;
5) требования в наборе не должны противоречить друг другу;
6) каждое требование должно быть проверяемым, т.е. должны существовать четкие критерии, позволяющие установить,
что система действительно удовлетворяет данному требованию;
7) каждое требование должно обладать свойством прослеживаемости, или трассируемости. Данное свойство позволяет прослеживать процесс реализации требования, начиная от его формулировки до элементов программного дизайна и программного
кода. Сложность обеспечения данного свойства заключается в
том, что одно первичное требование может реализовываться на
уровне программного кода сразу несколькими программными
модулями и фрагментами программного кода. В свою очередь,
один и тот же модуль или фрагмент программного кода может
быть связан с реализацией нескольких первичных требований,
т.е. имеет место тип связи «многие ко многим». Тем не менее
все эти связи должны быть зафиксированы;
8) желательно каждому требованию или группе требований
присвоить приоритет. Это позволит установить очередность реализации различных требований и облегчит выпуск нескольких
версий системы с разной функциональностью.
Требования взаимно зависят друг от друга: повышение уровня одних требований может приводить как к повышению, так и
к снижению уровня других требований. Отдельные классы требований к ПС принято представлять в виде характеристик качества ПС. В табл. 3.1 приведены данные о взаимном влиянии
различных характеристик качества ПС, где знаки «+» и «–» означают соответственно положительное и отрицательное взаимное влияние показателей.
Т а б л и ц а 3.1
Ïðàêòè÷íîñòü
Ýôôåêòèâíîñòü
Ñîïðîâîæäàåìîñòü
Ìîáèëüíîñòü
Ôóíêöèîíàëüíîñòü
Íàäåæíîñòü
Ïðàêòè÷íîñòü
(Óäîáñòâî)
Ýôôåêòèâíîñòü
Ñîïðîâîæäàåìîñòü
Ìîáèëüíîñòü
Íàäåæíîñòü
Ôóíêöèî-íàëüíîñòü
Позитивные и негативные взаимосвязи
основных характеристик качества
+
+
+
+
+
+
+
+
+
+
Необходимо помнить, что при согласовании требований
компромисс не всегда является наилучшим решением. Например, одна группа пользователей требует назначить некоторую
«горячую» комбинацию клавиш для определенного действия, а
другая группа пользователей желает для этого же действия другую «горячую» комбинацию. Самое плохое, что может сделать
разработчик в такой ситуации, – назначить (в порядке компромисса) в половине форм приложения одну «горячую» комбинацию, а в другой половине форм – вторую «горячую» комбинацию.
!
Сформированный общий набор требований к системе включает в себя как формулировки на языке заказчика системы (иногда
их называют C-требования [24]), так и записи с использованием
терминологии разработчика (так называемые D-требования). Этот
набор составляет основу технического задания на разработку ПС,
в котором излагается, что надо сделать, без указаний как это
надо делать. В России техническое задание является обязательным приложением к договору на проведение работ, регулирующим юридические вопросы взаимоотношений разработчика и
заказчика. ТЗ фиксирует результаты договоренностей между разработчиком и заказчиком ПС о ее функциях и свойствах, а также
об особенностях ее реализации. ТЗ используется для планирования, распределения и оценки работ по разработке ПС. Многие заказчики привыкли к формам ТЗ, определенным в стандартах серии ГОСТ 19.***, или ГОСТ 34.602.
Хорошее ТЗ должно обладать следующими свойствами:
1) полнотой – ТЗ должно представлять собой наиболее полное описание требований, предъявляемых к ИС, необходимо
описание всех функций, существенных для информационной
системы;
2) стилем – в ТЗ не должны приводиться обоснования требований, доводы и аргументы (все это содержание пояснительных записок, обоснования или описания проекта).
3) однозначностью понимания – в ТЗ не должно быть неопределенностей; формулировки должны быть четкими, не допускающими двойных толкований. Требования ТЗ должны быть одинаково понимаемы всеми участниками процесса разработки
(отсутствие неоднозначности в описании функций и требований, отсутствие фраз типа «и так далее», «так же для других
пунктов» и т.п.);
4) точной терминологией – ТЗ должно быть написано сухой
терминологией, без использования «живого языка». Если используются нестандартные термины, то обязательно должна быть
расшифровка в списке терминов и определений;
5) продуманным оформлением – все пункты ТЗ должны быть
пронумерованы сквозной нумераций (каждое требование должно быть идентифицировано, а связи между требованиями указаны в явном виде). В тексте ТЗ должно быть наличие перекрестных ссылок на пункты ТЗ;
"
6) выверенной декомпозицией – по возможности должен использоваться принцип декомпозиции сложной системы на подсистемы, с выносом описания подсистем в частные ТЗ (ЧТЗ);
7) возможностью изменений и уточнений – если конкретные
значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ на ИС, в нем следует сделать запись о порядке установления и согласования этих показателей,
норм и требований следующего вида: «Окончательное требование
(значение) уточняется в процессе ... и согласовывается протоколом с ... на стадии…». При этом в текст ТЗ изменения не вносят.
Анализ требований не заканчивается составлением ТЗ. Дальнейший анализ требований должен приводить к созданию внутренних программных спецификаций, которые не только отражают, что надо сделать, но и показывают, каким образом это
надо делать, т.е. внутренние спецификации должны содержать
сведения об архитектуре и модульном составе ПС, необходимых
функциях и процедурах, структуре отдельных модулей и т.д.
Внутренние спецификации описывают требования к программным компонентам, реализующим требуемую функциональность.
3.1.3. Ìåòîäû óãëóáëåííîãî àíàëèçà òðåáîâàíèé
Создание прототипов системы. Создание прототипов является простым и эффективным средством уточнения и анализа требований пользователя, а также методом экспресс-моделирования интерфейса программы.
Прототип – это нефункциональная демонстрационная
версия продукта.
Чаще всего прототип представляет собой лишь набор снимков с экрана или web-страниц. Прототипы демонстрируют основные особенности продукта и отражают текущее состояние
проекта. С их помощью уже на начальных этапах разработки у
заказчика и пользователей складывается представление о программе. Прототипы помогают заказчику и разработчику не только
уточнить требования к продукту, но и установить приоритеты
реализации функций. В ходе выполнения проекта разработчики
могут быстро и с минимальными затратами создавать прототипы как для проверки наиболее важных функций, так и для написания больших фрагментов программного кода.
#
Многие фирменные стандарты разработки и, в частности,
методология MSF фирмы Microsoft настоятельно рекомендуют
использовать прототипы для уточнения требований, предъявляемых пользователем к удобству использования системы, ее эффективности, интероперабельности (возможности согласованно
работать с другими системами), а также для быстрого выявления проблем с пользовательским интерфейсом.
Моделирование процессов предметной области. В основе построения любой программы лежит моделирование объектов и
процессов той предметной области, для которой она предназначена. Построение модели начинается, как правило, уже на этапе анализа требований к системе. Моделирование позволяет выявить только те сущности и процессы, которые необходимы для
решения поставленной задачи. На основе построенной модели
уточняется концепция ПС, формируется ее архитектура, в дальнейшем проводится разработка, тестирование и интеграция ПС.
Создание любых сложных систем основано на их упрощении путем разбиения на более простые, взаимосвязанные между
собой подсистемы. Развитие технологий разработки программ
выявило два возможных подхода к такой декомпозиции– алгоритмический и объектный.
При алгоритмическом подходе система представляется в виде
совокупности взаимосвязанных функциональных модулей. На
вход модулей может поступать необходимая информация, которая обрабатывается каждым модулем по определенному алгоритму и передается на выход модуля, связанный с входами других модулей. Соответственно на выходе всей системы получается
информация как результат обработки входной информации по
сложному алгоритму.
При объектном подходе система представляется в виде совокупности взаимодействующих между собой объектов. В каждом
объекте инкапсулированы некоторые свойства, методы, возможности реакции на определенные события. Выходная информация системы получается как результат взаимодействия объектов
системы.
Исторически первым получил развитие алгоритмический
подход к моделированию при разработке программных систем.
Этот подход является естественным с точки зрения программирования, так как всякая программа представляет собой алгоритм, изложенный на языке, понятном машине. Однако с рос $
том сложности проектируемых программных систем оказалось,
что более продуктивным является объектный подход. В настоящее время при проектировании сложных программных систем
чаще применяется именно объектный подход.
Методы, используемые для моделирования предметной области, можно условно разбить на три класса: математические (подходящие и для алгоритмического, и для объектного подхода),
алгоритмические, или структурные, и объектные. На рис. 3.4 показаны наиболее известные из них.
Рис. 3.4. Классификация методов моделирования
предметной области
На начальных этапах развития компьютерной техники, когда решаемые задачи были относительно простыми, обычно удавалось построить математическую модель предметной области.
На основе построенной математической модели разрабатывались алгоритмы работы системы, выполнялось проектирование
ПС. В России именно математические методы моделирования
получили наибольшее развитие. Среди математических моделей выделяют три класса – детерминированные, стохастические
и игровые модели. Детерминированные модели предназначены
для описания процессов, в которых все основные факторы определены и известны. Стохастические модели применяют в том
случае, когда некоторые факторы имеют случайный характер.
%
Игровые модели полезно использовать, когда необходимо учесть
наличие в модели различных объектов со своими свойствами и
поведением.
Одним из популярных методов математического моделирования, используемых при проектировании программных систем,
является метод диаграмм переходов состояний, или STD (State
Transition Diagrams). Методология STD характеризует поведение системы во времени и является графической формой представления конечного автомата – математической абстракции,
используемой для моделирования детерминированного поведения технических объектов или объектов реального мира.
С ростом сложности и расширением спектра решаемых задач выяснилось, что для многих из них невозможно сразу построить точную математическую модель, необходимы другие, более гибкие методы моделирования.
Для моделирования с использованием алгоритмического подхода в настоящее время часто используются следующие методы:
DFD (Data Flow Diagrams) – диаграммы потоков данных, которые являются основным средством моделирования функциональных требований проектируемой системы, использующим
классические методы алгоритмической декомпозиции.
В соответствии с данной методологией модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее
ввода в систему до выдачи пользователю. Диаграммы верхних
уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ПС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего
уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут
такой уровень декомпозиции, на котором процессы становятся
элементарными и детализировать их далее невозможно.
С помощью DFD требования к системе разбиваются на функциональные компоненты (процессы) и представляются в виде
сети, связанной потоками данных. Главная цель данной методологии – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
SADT (IDEF0) – совокупность методов, правил и процедур,
предназначенных для построения функциональной модели объекта
какой-либо предметной области.
&
Методология функционального моделирования SADT, разработанная в начале 1970-х годов, также использует принципы
алгоритмической декомпозиции сложных систем. На ее основе
разработан известный стандарт IDEF0 (Icam DEFinition).
Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Методология SADT может использоваться для моделирования широкого круга систем и
определения требований и функций. Для уже существующих
систем SADT может быть применена для анализа функций,
выполняемых системой, а также для указания механизмов,
посредством которых они осуществляются. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих
ссылки друг на друга.
Методами моделирования, использующими объектный подход являются:
ERD (Entity-Relationship Diagrams) – диаграммы «сущностьсвязь». ERD – прообраз объектно-ориентированного подхода к
декомпозиции сложных систем. С помощью данной методологии система представляется как совокупность взаимосвязанных
объектов и на диаграмме можно увидеть схему связей между
объектами. Чаще всего данная методология используется при
проектировании реляционных баз данных.
UML (Unified Modeling Language) – унифицированный язык
моделирования. UML – наиболее мощное и универсальное средство для объектной декомпозиции ПС. Оно включает в себя все
возможности методологии ERD. Кроме того, UML позволяет
моделировать функциональные требования и требования пользователей с помощью различных типов диаграмм: диаграмм использования, диаграмм взаимодействия, диаграмм классов, диаграмм состояний и т.д.
Все перечисленные методологии моделирования позволяют количественно оценить сложность разрабатываемой системы уже при построении модели. В одних методологиях (DFD,
SADT) это можно сделать по количеству функций и потоков
данных, в других (ERD, UML) – по количеству объектов и
связей между ними, а также по количеству типов объектов и
типов связей.
'
3.2. Ñîãëàñîâàíèå ñëîæíîñòè ðàçðàáîòêè
è âîçìîæíîñòåé èñïîëíèòåëÿ
Одной из важнейших задач начального этапа разработки ПС
является согласование между собой трех величин: объема требований, привлекаемых ресурсов и сроков выполнения работ.
Разработчик на этом этапе должен, наряду с определением и
анализом требований заказчика, достаточно убедительно (особенно для заказчика, финансирующего разработку) оценить сложность и трудоемкость разрабатываемой ПС, необходимые ресурсы и требуемые сроки.
Например, если у нас есть один разработчик, 10000 руб. и один
месяц, то можно говорить с заказчиком о разработке прототипа
несложной ПС. Гораздо больший объем требований можно реализовать в системе, если в группе разработчиков имеется 10 специалистов, срок проекта составляет один год, а объем финансирования – несколько миллионов рублей. В этом случае можно говорить
о создании полноценного программного продукта.
Процесс согласования жесткой взаимосвязи величин часто
условно изображают в виде треугольника компромиссов (рис. 3.5).
Изменение объема требований вызывает соответствующее изменение объема ресурсов и необходимого времени. Иногда к
согласуемым величинам добавляют четвертое измерение – качество, за счет которого можно сэкономить время или ресурсы.
Однако все современные методологии разработки не рекомендуют экономить на качестве и допускают включение его в
процесс согласования только в крайних случаях, когда некоторое снижение качества разработки устраивает все стороны соглашения.
Рис. 3.5. Треугольник компромиссов
!
Достигнутое согласование по сложившейся в России практике фиксируется в трех основных документах: договоре на выполнение работ, техническом задании (ТЗ) и календарном плане. Договор заключается между заказчиком ПС и разработчиком.
В нем оговаривается объем и график финансирования, а также
общие сроки поставки ПС и различные условия взаимодействия
разработчика и заказчика. В техническом задании фиксируется
перечень требований к разрабатываемой ПС. В календарном
плане поэтапно указаны сроки выполнения работ.
В процессе ЖЦ ПС по современным представлениям возможно изменение согласованных величин. Корпорация Microsoft
в своей методологии MSF для эффективного согласования трех
основных величин на протяжении всего ЖЦ рекомендует составить матрицу приоритетов, пример которой показан на рис. 3.6.
Один из факторов (например, ресурсы) фиксируется, второй
фактор (например, сроки) имеет приоритет по важности и может меняться в определенных пределах во время согласования.
Значение третьего фактора (например, возможности) принимается исходя из заданных значений первых двух.
Рис. 3.6. Матрица приоритетов
Следует подчеркнуть, что, несмотря на совершенствование
методик разработки и применение самых современных методологий проектирования сложных технических систем, до сих пор
удовлетворительного решения задачи согласования не достигнуто. Достаточно отметить, что в 2000 г. 49% проектов не уложились в отведенные сроки и были выполнены с перерасходом
ресурсов и изменением набора требований к системе, 23 % закончились неудачно и только 28 % проектов ИС были признаны удачными. Похожая картина в области разработки новых ИС
наблюдалась и в 2005 г. Это связано со сложностью задач, решаемых на начальной стадии разработки.
!
Управление требованиями в ходе разработки. Одной из особенностей современных проектов по созданию сложных систем
является то, что требования к ним могут меняться в ходе выполнения проекта. Эти изменения бывают вызваны различными причинами – лучшим пониманием решаемых задач, возникшим в
ходе реализации проекта, изменениями внешней среды, выявленными в ходе выполнения проекта трудностями, и т.д. В связи с этим, независимо от уровня первоначальной проработки
требований к проекту, необходимо быть готовым к тому, что в
любой момент жизненного цикла могут появиться новые требования, а старые требования могут измениться или отпасть.
Яркий пример изменения требований, а также важности человеческого фактора при разработке сложных систем – воспоминания одного из разработчиков операционной системы
Windows Server2003. «Цикл разработки Windows Server2003 близился к завершению, количество ошибок стремительно снижалось, а процесс становился проще с каждым днем. И тогда руководство Microsoft (с подачи отдела маркетинга) объявило о смене
имени продукта. «Они должны были сделать это шесть месяцев
назад», – возмутились разработчики. «В тот момент мы бы все
согласились с этим решением. Но на столь позднем этапе...».
Необходимо было заменить всю графику, содержащую торговые
марки, текст и значения реестра в системе, т.е. задача состояла
в том, чтобы внести несколько тысяч изменений, и это могло
потребовать исправления нескольких тысяч новых ошибок.
«Я пошел и выбрал трех лучших разработчиков в команде.
Я сказал этим парням: – Не говорите мне, что вы сейчас делаете.
Просто сделайте это. Один из разработчиков исправил около
7000 ссылок на .NET Server»».
Все современные методологии разработки предполагают возможность изменения требований в ходе разработки, т.е. процесс управления требованиями не заканчивается с разработкой
ТЗ и внутренних спецификаций системы, а продолжается на
протяжении всего ЖЦ ПС и заключается в управлении изменениями в требованиях. При этом необходимо помнить, что всякое изменение в требованиях связано с изменением стоимости
и сроков выполнения проекта и может влиять на качество ПС.
Можно рекомендовать следующие действия (шаги) разработчика в процессе управления изменениями в требованиях
(рис. 3.7):
!
Рис. 3.7. Последовательность анализа и реализации
требований к проекту
Ш а г 1. Регистрация заявки на изменение. Регистрация времени поступления, формулировки и источника изменения требований позволит разработчику правильно спланировать свои
действия, отслеживать историю изменений, аргументировать свое
мнение при переговорах с заказчиком. Статистика изменений и
их характер несут ценную информацию для планирования будущих проектов.
Ш а г 2. Трассировка требований. Анализ влияния изменений в
требованиях на компоненты системы и другие требования. Основная цель такого анализа – сохранить целостность и непротиворечивость конструируемой системы требований. Для достижения этой цели бывает полезно определить тип требования:
(классифицировать новое требование как требование одного из
трех видов):
• дополняющее, которое отражает ранее не рассматривавшийся аспект системы;
• модифицирующее, которое изменяет одно или несколько
уже существующих требований;
!!
• отменяющее, принятие которого исключает одно или несколько ранее принятых требований.
Ш а г 3. Оценка трудоемкости, необходимой для выполнения
заявок на изменения, и оценка изменения сроков поставки.
Ш а г 4. Оценка дополнительных затрат. Анализ влияния изменений на стоимость системы
Ш а г 5. Обсуждение результатов анализа с вышестоящим руководством и заказчиком, получение подтверждения изменения от
заказчика. Вопрос о том, принять или отклонить требование,
является очень ответственным, и ответ на него должен быть обоснован анализом, проведенным на шагах 2–4
Ш а г 6. Исправление рабочих продуктов.
3.3. Ïëàíèðîâàíèå ðåàëèçàöèè ïðîåêòà
Разработка ПС, за исключением случаев, когда программа
пишется «для себя», является бизнесом. И, как во всяком бизнесе, вам необходимо знать самому и объяснить партнерам,
сколько времени потребует разработка, какие ресурсы придется
привлечь и в какую сумму все это обойдется. Именно эти данные
позволят вам принять окончательное решение о целесообразности реализации проекта, собрать команду разработчиков и спланировать их взаимодействие. Однако перечисленные данные,
кроме вашего желания, зависят от множества факторов (рис. 3.8),
значение которых будет известно только в будущем. Поэтому
вам придется строить свой план с учетом прогноза не зависящих от вас факторов.
Рис. 3.8. Факторы, учитываемые при планировании разработки проекта
!"
3.3.1. Ïðîãíîçèðîâàíèå è ïëàíèðîâàíèå
Прогнозирование – предсказание будущих событий. На
основе анализа существующего положения дел, изучения
истории развития прогнозируемого объекта и мнений экспертов выявляются тенденции и формируются предположения о развитии событий в будущем. Большинство факторов,
учитываемых в прогнозе, не зависят от нашей воли, однако
их учет позволит нам разработать хороший план.
Планирование – конструирование будущего. Мы продумываем действия, которые сами должны совершить, чтобы
достигнуть намеченной цели.
При планировании должны учитываться следующие факторы:
1. Цели, которые мы стремимся достигнуть:
• обеспечить функциональность проекта в соответствии с требованиями к полноте набора функций и к их реализации;
• выполнить нефункциональные требования;
• не нарушить сроки реализации;
• уложиться в бюджет проекта;
• разработать способы внедрения (продвижения).
2. Ресурсы, которыми мы располагаем:
• специалисты, их компетентность, опыт и мотивация;
• процессы организации, процессы управления и технологические процессы.
3. Действия, которые мы должны совершить, и события, которые должны случиться:
• последовательность действий;
• причинно-следственные связи между действиями и событиями;
• время и ресурсы, которые необходимо затратить для реализации каждого из намеченных действий.
4. Прогнозируемое состояние внешнего окружения:
• состояние рынка на момент реализации проекта;
• влияние внешнего окружения на реализацию проекта.
Как видим, прогнозирование – важная составляющая планирования. Основные цели прогнозирования – предсказать, как
изменится внешний мир к моменту, когда проект будет реализован, насколько нужен он будет к тому времени, а также как
повлияет изменение внешнего окружения (например, появление новых программных средств) на ход реализации проекта.
!#
Действия, которые надо осуществить при планировании:
1) оценить время и затраты, требуемые на реализацию проекта. Такая оценка необходима для принятия решения о целесообразности реализации проекта, его стоимости и сроках реализации;
2) организовать коллектив на достижение поставленной цели.
Каждый участник должен знать:
• что, когда и в какой последовательности он должен делать
для реализации проекта;
• с кем и при каких условиях он должен согласовывать свои
решения и действия;
• к кому обратиться в случае невозможности выполнить порученную работу и т.д.;
3) составить план управления проектом. Руководитель должен определить методы, критерии и время контроля состояния
реализации проекта; определить методы управления процессом
реализации проекта.
3.3.2. Êëàññèôèêàöèÿ ìåòîäîâ ïëàíèðîâàíèÿ
Планирование всегда проходит в условиях неопределенности, поэтому именно неопределенность и новизна планируемого
объекта, методов реализации проекта, а также непредсказуемость
внешних факторов и т.д. определяют выбор методов планирования. Из всего разнообразия сочетаний перечисленных факторов выберем три типовых варианта:
1. Новое все. Мы никогда не делали подобные проекты и
пока не знаем, какими методами будем пользоваться.
2. Новый объект. Объект разработки должен обладать принципиально новыми свойствами и удовлетворять новым требованиям. Поэтому нам не удалось подыскать аналог среди ранее
реализованных проектов.
3. Проект аналогичен ранее реализованному. Мы уже разрабатывали подобные проекты. У нас имеется сложившаяся процедура разработки подобных проектов. Специфика нового проекта нами осознана и мы, в принципе, понимаем, как ее
реализовать.
Очевидно, что третий вариант наиболее удобен для планирования. Мы просто выбираем ранее разработанный проект и
планируем разработку нового, как повторение уже известного
!$
процесса. Для оценки времени и затрат на разработку в этом
случае удобно использовать нормативные методы.
Второй вариант сложнее третьего, но гораздо проще первого. Ключевым моментом здесь является надежная, проверенная
опытом процедура разработки. Это позволяет сосредоточить
большую часть внимания на новизне проекта, его отличиях от
предшественников. При этом в план следует заложить время на
поиск, переделывание и исправление неизбежных ошибок. Для
фирм – лидеров разработки программного обеспечения второй
вариант является типичным. Удобным методом планирования
для этого варианта является метод базовой линии (Base line).
Первый вариант самый сложный и рискованный, поэтому
его нужно постараться избегать и по возможности редуцировать
до второго, а еще лучше, до третьего варианта. Если же при всех
наших стараниях избежать первого варианта не удается, в план
необходимо по максимуму закладывать время и ресурсы для
поиска, оценки и возможного отбрасывания неудачных решений. При этом в качестве аналогов скорее должны рассматриваться не проекты, похожие на наш по функциональности или
по условиям применения, а проекты столь же неопределенные
на начальном этапе, как и наш.
Как видим, искусство планирования в значительной мере
сводится к умению сократить неопределенность проекта, свести
неизвестное к известному. В этой связи интересна история развития методов планирования программных проектов. Первые
проектировщики программ по сути были исследователями. У
них не было ни опыта, ни аналогов, ни разработанных ранее
технологий, поэтому разработки планировались как научные
исследования. Львиная доля времени и ресурсов отводилась на
исследования. Чтобы оправдать огромные риски неудач, считалось, что отрицательный результат не менее полезен, чем положительный. Проекты получались очень дорогими и реализовывались долго1. С появлением прикладных программ, для которых
функциональность и условия использования более схожи, чем
для научных программ, появилась возможность применения
нормативных методов планирования.
1
Отметим, что одной из основных причин известного кризиса в программировании, разразившегося в первой половине 1960-х гг., явилось
несоответствие все возрастающей потребности в дешевых компьютерных
программах с высокой стоимостью и длительными сроками их разработки.
!%
С расширением разнообразия прикладных программ, насыщением их все большей функциональностью и постоянным развитием использовать нормативные методы планирования становится все труднее. Дело в том, что каждый новый проект
привносит новые понятия, методы и объекты, для реализации
которых нет нормативов. Приходится или сочетать трудно совместимые методы планирования исследований и нормативные
методы, или вообще отказываться от нормативных методов планирования.
Для повышения достоверности и объективности оценок трудоемкости и затрат на разработку были предложены так называемые
объективные методы. К ним относятся метрики сложности, позволяющие оценить и сопоставить сложность написанных программных модулей на основе формализованного анализа их кода; метод
функциональных точек, основанный на связи функциональности
программы и сложности ее написания, а также другие методы.
По мере накопления опыта и развития методов разработки
программного обеспечения становится все более ясно, что успех проекта, время и трудоемкость его реализации существенно
зависят от команды разработчиков, ее квалификации, опыта и
умения работать вместе, а также от совершенства методов и процессов управления, используемых фирмой-разработчиком. Чтобы не повторять прошлых ошибок, организация должна обзавестись коллективной памятью и активно использовать ее при
планировании и управлении новыми проектами.
Нормативные методы планирования. Изучая опыт разработки нескольких однотипных проектов, мы непременно заметим,
что после некоторого периода адаптации одинаковые работы в
разных проектах выполняются за схожее время и требуют схожих затрат труда. Запишем указанные характеристики в таблицу
нормативов (табл. 3.2) и будем использовать ее при оценке трудоемкости будущих проектов. Такой метод дает возможность
оценить трудоемкость разработки с достаточной точностью и
достоверностью до тех пор, пока наш новый проект похож на
проекты, использованные для формирования таблицы. На базе
таблицы нормативов разрабатывается стандарт, включающий классификацию видов работ и правила расчета их трудоемкости. Применение такого стандарта позволит существенно упростить процесс оценки сложности разработки, а ссылки на стандарт являются
обоснованием оценок. Методы, использующие нормативы для
оценки затрат, получили название нормативные методы.
!&
В качестве примера стандарта, использующего нормативный
метод, рассмотрим ОСТ 4.071.030 «Автоматизированная система управления предприятием. Создание системы. Нормативы
трудоемкости»1. В нем приводится классификация сложности
задач и программ. Для каждой группы сложности дается таблица нормативов трудоемкости (фрагмент таблицы приведен в
табл. 3.2)
Т а б л и ц а 3.2
Фрагмент таблицы нормативов трудоемкости работ
1 категории сложности
Îáñëåäîâàíèå îáúåêòà
óïðàâëåíèÿ è îôîðìëåíèå
ìàòåðèàëîâ îáñëåäîâàíèÿ
Ðàçðàáîòêà ïëàíà ìåðîïðèÿòèé ïî ïîäãîòîâêå îáúåêòà
ê âíåäðåíèþ ñèñòåìû
Ðàçðàáîòêà îñíîâíûõ
òðåáîâàíèé ê ñîçäàâàåìîé
ñèñòåìå è ñîñòàâëåíèå
òåõíè÷åñêîãî çàäàíèÿ
4911
123
5558
3364 538
ñîãëàñîâàíèå
è óòâåðæäåíèå
ïîäëèííèêà
ðàçìíîæåíèå,
ïåðåïëåò
è ïåðåäà÷à
äîêóìåíòàöèè
çàêàç÷èêó
ðóêîâîäñòâî õîäîì
ðàáîò
îôîðìëåíèå
ïîäëèííèêà
âñåãî
Íàèìåíîâàíèå ðàáîòû
ðàçðàáîòêà
è îôîðìëåíèå
îðèãèíàëà
Òðóäîåìêîñòü ðàçðàáîòêè è îôîðìëåíèå
äîêóìåíòàöèè ïî ýòàïàì, íîðìî-÷àñû
314
269
426
25
16
41
3677 588
278
294
721
41
Оценка трудоемкости начинается с классификации проекта
в целом, конкретных задач и программ, входящих в проект. В
зависимости от класса сложности работы (задачи/программы)
выбирается таблица нормативов трудоемкости. Трудоемкость
создания пакета программ складывается из трудоемкости всех
работ, входящих в проект.
1
Стандарт устанавливал нормативы трудоемкости на работы по созданию и дальнейшему развитию автоматизированной системы управления
предприятием (АСУП). В настоящее время стандарт отменен, так как многие
его нормативы устарели.
!'
Нормативные методы широко использовались на этапе экстенсивного развития информационных технологий, когда типовые программные решения применялись к новым практическим задачам. Однако с появлением все более сложных программ,
учитывающих особенности областей применения, использовать
нормативные методы становится все труднее.
Планирование на основе систематизации накопленного опыта.
Современные концепции планирования разработок базируются
прежде всего на анализе и систематизации предыдущего опыта,
оценке готовности организации и ее коллектива к разработке
данного проекта, а также на использовании стандартных процедур разработки проекта. На рис. 3.9 изображена последовательность планирования реализации программного проекта.
Рис. 3.9. Процесс планирования разработки на основе
систематизированного опыта предыдущих проектов
На основе анализа особенностей проекта, а также целей организации, ее готовности к выполнению данного проекта и т.д.
выбирается и адаптируется стандартная процедура разработки.
Она определяет последовательность шагов реализации, причинно-следственные связи между ними, а также позволяет подыскать аналоги в предыдущих и схожих разработках.
Проект в целом и отдельные этапы его разработки сопоставляются с аналогами, информация о которых накоплена в специализированной базе данных, систематизирующей опыт предыдущих
разработок. Определяются количественные характеристики трудоемкости и время выполнения каждого шага. Накопленные и
"
систематизированные статистические данные о трудоемкости и
сроках разработки позволяют не только дать количественную
оценку этих характеристик для нового проекта, но и оценить
погрешность этой оценки.
Опыт предыдущих проектов позволит также определить наиболее рискованные участки плана, определить точки контроля
и принятия решений, оценить риски, связанные с отклонением
реализации проекта от плана. Таким образом, в план проекта
мы встраиваем план управления его реализацией.
Результатом планирования является сетевой график, на котором отражены все этапы реализации, последовательность и
сроки их выполнения, а также графики загрузки ресурсов. Глубина детализации планирования определяется размерами и особенностями проекта, численностью группы проектировщиков,
а также стилем планирования, принятым в организации. Ниже
будут описаны основные этапы планирования и методы их реализации.
Адаптация стандартного процесса разработки. В табл. 3.3.
сведены факторы, которые следует учитывать при выборе и адаптации стандартного процесса для разработки конкретного проекта.
Т а б л и ц а 3.3
Факторы, влияющие на выбор и адаптацию
стандартного процесса разработки
Ôàêòîð
Îïûò è êâàëèôèêàöèÿ ðàçðàáîò÷èêîâ
è ìåíåäæåðîâ
ßñíîñòü
òðåáîâàíèé
Ãðàäàöèè çíà÷åíèé ôàêòîðà
Íèçêèé
Âûñîêèé
Áîëüøèíñòâî ðàçðàáîò- Ðàçðàáîò÷èêîâ ñ äîñòàòî÷÷èêîâ èìååò áîëåå ÷åì íûì îïûòîì ìåíüøèíñòâî
äâóõëåòíèé îïûò ðàçðàáîòêè ïðîåêòîâ ñ àíàëîãè÷íîé òåõíîëîãèåé
Âûñîêàÿ
Âñå òðåáîâàíèÿ
ñôîðìóëèðîâàíû, çàïèñàíû
â äîêóìåíòàöèè,
îäíîçíà÷íî ïîíèìàþòñÿ âñåìè
ó÷àñòíèêàìè
ïðîåêòà
Óäîâëåòâîðèòåëüíàÿ
Äëÿ èíòåðïðåòàöèè è óòî÷íåíèÿ
÷àñòè òðåáîâàíèé íåîáõîäèìû
ðàáî÷èå ñîâåùàíèÿ
Íèçêàÿ
Îæèäàåòñÿ, ÷òî
ìíîãèå òðåáîâàíèÿ áóäóò äîáàâëåíû èëè èçìåíåíû â õîäå ðåàëèçàöèè ïðîåêòà
"
Продолжение
Ôàêòîð
×èñëåííîñòü
êîìàíäû
Ãðàäàöèè çíà÷åíèé ôàêòîðà
Áîëüøàÿ
Áîëüøå
10 ÷åëîâåê
ÏðîäîëæèòåëüÄîëãàÿ
íîñòü ðàçðàáîòêè Ñâûøå ãîäà
Êðèòè÷íîñòü
ðàçðàáîòêè
Ñðåäíÿÿ
410 ÷åëîâåê
Ìàëàÿ
13 ÷åëîâåêà
Ñðåäíÿÿ
Äî ãîäà
Êîðîòêàÿ
Ìåíüøå òðåõ
ìåñÿöåâ
Êðèòè÷íàÿ
Îêàçûâàåò ñóùåñòâåííîå
âëèÿíèå íà ïîëüçîâàòåëÿ
èëè ðàçðàáîò÷èêà
Íåêðèòè÷íàÿ
На рис. 3.10 изображен стандартный процесс разработки,
принятый в известной индийской программистской фирме Infosys
[39]. Как видно из рисунка, процесс основан на каскадной модели жизненного цикла. Однако там, где есть возможность, отдельные шаги выполняются параллельно.
Входом процесса является спецификация требований – полный и систематизированный перечень внешних требований к программе. Уже его наличие позволяет планировать процессы системного тестирования пока еще не разработанной программы.
Интерпретация внешних требований в требования к архитектуре и компонентам программы происходит на этапе высокоуровневого проектирования. Перечень компонентов программы (подсистем, программных модулей, информационных ресурсов) и
требований к ним позволяет спланировать процесс сборки программы и уточнить процесс системного тестирования.
На основании спецификации высокого уровня – перечня
общих требований к компоненту мы можем проработать детальные требования и сформулировать задания на программирование этого компонента. Разработанные программные модули
подвергаются тестированию и при необходимости дорабатываются. Для проверки возможности их совместной работы проводится комплексное тестирование, а после этого – системное
тестирование, цель которого – продемонстрировать работоспособность программы и ее соответствие исходным требованиям.
Убедившись в пригодности программы, мы можем продемонстрировать ее заказчику, организовав приемочные испытания. Одновременно разрабатывается программная документация,
необходимая для промышленной эксплуатации программы.
"
"!
Рис. 3.10. Процесс разработки программной системы, принятый в INFOSYS
Последними этапами являются установка программы у заказчика и ее сопровождение (гарантийное обслуживание) в ходе промышленной эксплуатации.
Далеко не для каждого проекта требуется в точности повторять весь стандартный процесс разработки. Например, для относительно простых и некритичных проектов, функциональность
которых во многом является суммой функциональностей отдельных модулей, можно объединить этапы комплексного и системного тестирования, а приемочные испытания совместить с установкой программы у заказчика.
3.4. Ìåòîäû ñèñòåìàòèçàöèè îïûòà ðàçðàáîòêè
Как видно, реалистичность плана а, следовательно, успех
проекта и его стоимость сильно зависят от нашего умения накапливать, систематизировать и использовать опыт своих предыдущих разработок и опыт коллег. Рассмотрим основные методы систематизации опыта.
3.4.1. Ïðèâû÷êà ïîäâîäèòü èòîãè
Разработка сложного программного модуля закончена. Несмотря на жесткость и противоречивость исходных требований
разработчику удалось создать приличную программу и включить
в нее несколько программистских находок, которвми можно
гордиться.
Пока разработчик помнит все особенности созданного модуля, он может объяснить, почему выбрано именно такое решение и чем грозят альтернативы. Кажется, что это он будет помнить всегда, но пройдет несколько месяцев, воспоминания об
удачном модуле заслонят новые знания и впечатления, и когда
ему предложат разработать аналогичный модуль, он вынужден
будет начинать практически «с чистого листа».
Чтобы избежать потери знаний и опыта, полученных в ходе
работы, необходимо выработать в себе привычку подводить итоги
в конце каждого этапа и по завершении работы в целом. В
западной культуре менеджмента есть специальный термин follow
up (проверка исполнения). После завершения работы все ее участники собираются вместе и обсуждают:
""
• что удалось и не удалось сделать;
• какие достоинства и недостатки имеет выбранное решение;
• сколько времени и труда было потрачено на эту работу, на
что конкретно они были потрачены;
• какие проблемы возникали в ходе работы, как удалось их
решить;
• какой опыт получили разработчики.
Результаты обсуждения формулируются в виде итогового
документа, который используется при планировании и в управлении будущими проектами.
3.4.2. Îöåíêà òðóäîåìêîñòè è âðåìåíè,
íåîáõîäèìîãî íà ðåàëèçàöèþ ïðîåêòà
Особое внимание следует уделить фактическим затратам труда
и времени, которые ушли на разработку. Объективные сведения
об этих характеристиках помогут нам планировать будущие проекты. В табл. 3.4 приведены итоги затрат времени в человекочасах на выполнение стадий разработки конкретного проекта
фирмой Infosys [39]. Отдельно фиксировалась трудоемкость выполнения каждого вида работ и доработки – исправления всех
ошибок и замечаний, выявленных при выполнении данного вида
работ. Доля доработки – отношение трудоемкости доработки к
общей трудоемкости работы позволяет оценить качество выполнения предыдущих работ и дополнительные затраты, связанные
с повышением качества проекта.
Т а б л и ц а 3.4
Âñåãî
414
1147
32
76
446
1223
7
6
Ñðåäíåå çíà÷åíèå
ïî ãðóïïå àíàëîãîâ
Äîðàáîòêà
Ïðîåêòèðîâàíèå
Ïðîãðàììèðîâàíèå
Âûïîëíåíèå
Âèä ðàáîòû
Äîëÿ ðàáîòû
â îáùåé
òðóäîåìêîñòè, %
Äàííûé ïðîåêò
Òðóäîåìêîñòü, ÷åë.-÷
Äîëÿ äîðàáîòêè, %
Трудоемкость выполнения стадий разработки проекта
14
39
12
39
"#
Продолжение
Âûïîëíåíèå
Äîðàáîòêà
Âñåãî
Äàííûé ïðîåêò
Ñðåäíåå çíà÷åíèå
ïî ãðóïïå àíàëîãîâ
156
74
230
32
7
9
251
30
281
11
9
6
183
237
0
8
183
245
0
3
6
8
6
12
30
3
33
9
1
1
200
332
2950
0
0
223
200
332
3173
0
0
7
6
10
100
7
8
3000
Âèä ðàáîòû
Òåñòèðîâàíèå
ýëåìåíòîâ
Êîìïëåêñíîå
òåñòèðîâàíèå
Ïðèåìî÷íûå èñïûòàíèÿ è óñòàíîâêà
Óïðàâëåíèå ïðîåêòîì
Óïðàâëåíèå
êîíôèãóðàöèåé
Îáó÷åíèå ïåðñîíàëà,
ñâÿçàííîå ñ ðåàëèçàöèåé ïðîåêòà
Ïðî÷åå
Âñåãî
Äîëÿ äîðàáîòêè, %
Òðóäîåìêîñòü, ÷åë.-÷
Äîëÿ ðàáîòû
â îáùåé
òðóäîåìêîñòè, %
В последней графе приведена оценка общей трудоемкости
проекта и ее распределения по видам работ, сделанная на основе анализа предыдущих проектов, аналогичных данному. Сопоставление фактических трудоемкостей с оценкой позволяет судить об успешности и эффективности реализации проекта.
Как видно из табл. 3.4, доля собственно программирования
в объеме работ не превышает 40%, общие затраты на управление проектом – 25%, тестирование– 15%. Наибольшая дополнительная трудоемкость требуется для исправления ошибок, выявленных на этапе локального тестирования, поэтому при
планировании будущих проектов, претендующих на высокий
уровень качества, на тестирование и исправление ошибок следует выделить больше времени.
"$
3.4.3. Êàê îòíîñèòüñÿ ê ñâîèì îøèáêàì
Человеку, как известно, свойственно ошибаться. По существу процесс отладки программы – процесс поиска и устранения ошибок. А вот сознаться в своей ошибке бывает очень трудно. Профессиональный программист не должен стесняться своих
ошибок. Его задача понять их причину и постараться не совершить в следующий раз.
Как работать над ошибками? В качестве примера рассмотрим ошибку, которую нередко допускают начинающие программисты. Допустим, программист объявил глобальную переменную Х, а в одном из модулей объявили Х как локальную
переменную. Ошибка никак себя не проявит, пока не потребуется передать значение Х из одного модуля в другой. Потратив
почти час на выявление этой досадной ошибки, не поленитесь
и потратьте еще 10 мин. на работу над ошибками, результат
запишите в журнал ошибок (табл. 3.5).
Т а б л и ц а 3.5
Пример записи в журнале ошибок
Îøèáêà
Ïåðåìåííàÿ, îáúÿâëåííàÿ êàê ãëîáàëüíàÿ, à â îäíîì èç
ìîäóëåé îíà îáúÿâëåíà êàê ëîêàëüíàÿ
Ïðîÿâëåíèå
îøèáêè
Íåâåðíàÿ ïåðåäà÷à
çíà÷åíèÿ ïåðåìåííîé èç îäíîãî
ìîäóëÿ â äðóãîé
Çàòðà÷åííîå âðåìÿ, ìèí.
íà îáíàðóíà èñïðàâëåæåíèå
íèå îøèáêè
îøèáêè
50
5
Теперь, встретившись с похожей проблемой, вы гораздо быстрее найдете ее причину. Еще важнее то, что, осмыслив свою
ошибку один раз, вы реже будете ее совершать.
Фиксация ошибок дает очень полезную статистическую информацию об интенсивности их появления на различных стадиях проектирования. В табл. 3.6 приведена статистика интенсивности появления и обнаружения ошибок для конкретного проекта
[39]. В каждой ячейке таблицы указано количество ошибок, возникших на этапе, указанном в названии строки, и найденных
на этапе, указанном в названии столбца.
"%
Т а б л и ц а 3.6
Интенсивность появления и обнаружения ошибок
на различных этапах жизненного цикла разработки проекта
14
0
3
21
24
1
1
48
50
1
0
17
18
0
0
6
6
Âñåãî
Ïðèåìî÷íûå
èñïûòàíèÿ
0
Ñèñòåìíîå
òåñòèðîâàíèå
0
14
Òåñòèðîâàíèå
ýëåìåíòîâ
0
Ýêñïåðòèçà êîäà
Àíàëèç òðåáîâàíèé
Ïðîåêòèðîâàíèå
Ïðîãðàììèðîâàíèå
Âñåãî
Ýêñïåðòèçà
ïðîåêòèðîâàíèÿ
Ýòàï ïîÿâëåíèÿ
îøèáêè
Ýêñïåðòèçà
òðåáîâàíèé
Ýòàï îáíàðóæåíèÿ îøèáêè
2
18
92
112
Как видно из табл. 3.6, максимальное число ошибок возникло
на этапе программирования и обнаружено на этапе тестирования
элементов. Подобная информация может быть полезна для выявления проблем проектирования и поиска путей совершенствования процесса проектирования, существующего в организации.
3.4.4. Áàçà äàííûõ ñàìîíàáëþäåíèé
Пока у программиста накоплено мало опыта, ему не составит
труда просмотреть все предыдущие записи при планировании нового проекта. С ростом числа этих записей возникает проблема поиска нужной информации в ворохе несистематизированных данных.
Для повышения эффективности использования прошлого
опыта разработчикам ПС придется создать базу данных самонаблюдений. На рис. 3.11 изображена возможная структура такой базы, а на рис. 3.12 более подробно представлена структура
описания характеристик проекта.
Размеры программы определяются сложностью ее архитектуры и размерами модулей, входящих в программу. Трудоемкость проекта – фактические затраты труда, распределенные по
конкретным этапам графика. График работы по проекту – фактический сетевой график, по которому выполнялся проект (с
указанием отклонений от первоначального графика). Ошибки
проекта – журнал ошибок с указанием этапов, на которых они
появились и были обнаружены.
"&
Рис. 3.11. Структура базы данных самонаблюдений
Рис. 3.12. Раздел базы данных «Характеристики проекта»
3.4.5. Áàçîâàÿ ëèíèÿ óñòîé÷èâîñòè ïðîöåññà
При разработке программного продукта важно знать, насколько стабилен этот процесс разработки, чтобы в случае появления
нежелательных тенденций вмешаться в процесс и предотвратить их, пока их последствия не стали необратимыми.
Одним из самых ярких симптомов грядущей беды является отклонение от запланированных сроков и затрат на проведение этапов работ. Насколько опасны эти отклонения? Ведь, как известно,
значения характеристик определены из предыдущего опыта с некоторой погрешностью, а самим характеристикам присущ разброс.
"'
Для оценки этих погрешностей следует воспользоваться методами статистической обработки. Значения характеристик оцениваются не по одной, а по возможно большему числу реализаций схожих работ в прошлом. Разброс значений используется
для оценки погрешности1. Для каждой количественной характеристики в плане определяется доверительный интервал. Отклонение от запланированного значения считается существенным,
если оно превышает доверительный интервал.
После этого стандартный процесс можно описать более содержательно. Для каждого этапа указываются ожидаемые значения и доверительные интервалы:
• сроков и трудоемкости выполнения;
• темпов внесения и устранения ошибок;
• темпов появления изменений требований.
Такое описание называется базовой линией устойчивости процесса. Применение базовой линии позволяет сделать наглядным
анализ динамики развития процесса и применять методы статистического регулирования для управления процессом разработки программного продукта.
3.5. Ìåòðèêè ñëîæíîñòè
С накоплением опыта разработок повышается достоверность
количественных оценок, а доверительные интервалы сужаются.
Это позволяет создавать все более обоснованные планы, а нежелательные тенденции выявлять на все более ранних стадиях, когда
для их устранения требуются незначительные усилия.
Однако накопленный опыт быстро стареет. Появляются новые технологии и подходы, кардинальным образом изменяющие не только количественные характеристики процессов разработки, но их структуру и смысл. Новые задачи требуют
нетрадиционных подходов, поэтому надеяться на стабильное
улучшение планирования в будущем не стоит. Придется уже сейчас искать пути повышения точности и надежности оценок.
1
В качестве метода оценки погрешности удобно, например, использовать обратное распределение Стьюдента – зависимости доверительного
интервала случайной величины с единичной дисперсией от доверительной
вероятности и числа наблюдений. Умножив эту величину на стандартное
(среднеквадратическое) отклонение нашей выборки, получаем доверительный интервал для заданной доверительной вероятности.
#
Одним из таких путей является расширение круга аналогов.
Например, для оценки трудоемкости программных модулей можно применять не только собственные разработки. В качестве меры
сложности программы можно выбрать размер ее кода (например, количество строк кода). Тогда, сопоставив трудоемкости
разработки разными исполнителями схожих по сложности программ, можно оценить производительность каждого исполнителя и с ее учетом оценивать трудоемкость работы по более широкому кругу аналогов. Однако при этом возникает проблема
объективной оценки сложности программы. Размеры одинаковых по сложности программ, написанных на разных языках, в
разных стилях, исполнителями, имеющими разную квалификацию, могут существенно отличаться друг от друга.
Отметим, что понятие «сложность» не является строгим, поэтому ему трудно дать формальное определение. Обычно говоря
о сложности какого либо объекта или системы, мы полагаем:
сложно то, что сложно для понимания человеком. В связи с
этим существует много подходов и методов количественной оценки сложности проектов.
С точки зрения теории измерений оценка сложности – косвенное измерение. Функцию, устанавливающую значение измеряемой переменной (того или иного свойства программы), исходя из результатов прямых измерений, называют оценочной
функцией, или мерой; область ее значений – оценочным множеством; совокупность индикаторов-аргументов – метрикой измерения.
3.5.1. Ïðîñòåéøèå îáúåìíûå ìåòðèêè
Исторически первой мерой сложности программы является
число строк в программе L, включая комментарии. Отметим,
что чем длиннее программа, тем она сложнее, однако эта зависимость далеко не линейная. Действительно, строки программы
взаимообусловлены: изменение одной из них должно повлечь
изменения в других строках. Если мы будем учитывать только
парные связи, то и тогда удвоение длины кода приведет к учетверению числа связей, которые должен учитывать программист.
В общем случае зависимость сложности программы Т от ее размера L можно задать степенной функцией
#
T = LN ,
где N
– показатель, значение которого может меняться в диапазоне
от 1 до 2 в зависимости от стиля программирования, опыта
команды разработчиков, характера решаемой задачи и других факторов.
К объемным мерам также можно отнести [46]: S – число
исполняемых операторов; U – число программных модулей (подпрограмм, функций и т. д.); S / U – средний размер программного модуля.
М.Х. Холстед предложил учитывать не только размеры, но и
разнообразие объектов, использованных в программе. Обозначим: π1, π2 – соответственно количество типов операторов и
различных операндов; N1, N 2 – соответственно число всех
операторов и операндов, встречающихся в программе. Тогда
словарь программы (количество терминов, используемых в программе) будет иметь длину: π = π1 + π2, а длина программы:
N = N1 + N2. Оценочная длина программы отражает возможное
количество информации в программе с данным словарем:
N = p1 ´ log2 (p1) + p 2 ´ log2 (p 2 ) . (Это выражение напоминает один
из вариантов формулы Шеннона, использующейся для оценки
количества информации). Объем программы вычисляется как
V = N ´ log2 (p ) , а мера трудности создания программы – как
отношение объема к количеству строк E = V/L.
Меры Холстеда позволяют сопоставить сложности программ,
написанных на разных языках, оценить лаконичность кода. Однако при этом не учитываются все характеристики сложности
программы. Например, программа со сложной структурой управления и линейная программа того же объема, по Холстеду,
обладают одинаковой сложностью, что, конечно, противоречит
нашим представлениям о сложности.
Для учета структуры взаимосвязей элементов внутри программы используются топологические меры сложности [46].
Простейшей мерой такого типа является цикломатическая мера,
предложенная Мак-Кейбом.
Обозначим через G граф, отражающий структуру управления в программе. В простейшем случае вершинами такого графа
будут операторы перехода, а дугами– переходы. Например, оператор If..Then изображается вершиной с двумя дугами, соот-
#
ветствующими переходам при выполнении и невыполнении условия. Оператор Select Case изобразится вершиной с несколькими дугами, количество которых равно числу вариантов, рассматриваемых в операторе. В более сложных схемах учитываются
различные связи между операторами.
Цикломатическая мера показывает, насколько управляющий
граф программы сложней простой последовательности. Если n –
число вершин графа, m – число дуг, а p– число типов связей,
цикломатическая сложность вычисляется по формуле
l(G ) = m - n + p.
На рис. 3.13 показаны управляющие графы двух программ:
а) – простая последовательность управления, б) – программа,
содержащая ветвление и цикл.
Рис. 3.13. Управляющие графы программ:
а – простая последовательность управления;
б – программа с ветвлениями и циклом
′
В графах учитывается только один тип связи: «Передача управления», следовательно, p = 1. Вычислим цикломатическую
′ = 9 – 7 + 1 = 3.
сложность графов: λ(a) = 6 – 7 + 1 = 0; λ(a)
В более сложных мерах дополнительно учитываются: число
условных операторов (интервальная мера Майерса); общая длина кода (Хансен); структурированность программ; глубина вложенности циклов и т.д.
Перечисленные меры соответствуют нашему интуитивному
представлению о сложности программы и трудоемкости ее реализации. При наличии кода каждая из них может быть вычислена однозначно. Более того, процесс вычисления может быть автоматизирован, например путем добавления соответствующих
функций в компилятор. Однако оценка сложности и трудоемкости программы часто бывает нужна еще до того, как программа написана, поэтому в последнее время усилился интерес к
#!
методам оценки этих характеристик на ранних этапах жизненного цикла программного продукта.
3.5.2. Ìåòîä ôóíêöèîíàëüíûõ òî÷åê
Трудоемкость программных модулей можно было бы оценивать еще на этапе постановки задачи, если бы сложность программного обеспечения удалось связать с его функциональностью.
Функциональные типы. Рассмотрим в самом общем виде
факторы, влияющие на сложность программного продукта, на
примере стандартной программы, имеющей пользовательский
интерфейс и способной взаимодействовать с внешними программами1 («толстый клиент»). На рис. 3.14 представлены виды связи программы с внешним миром.
Рис. 3.14. Функциональные типы программного продукта
1
Примером такой программы может быть «толстый клиент» – клиетская часть программы, выполненной в клиент-серверной архитектуре и
наделенная внушительным набором пользовательских функций.
#"
Пользователь может:
• вводить данные с помощью интерактивного диалога или
без него;
• получать результаты в виде распечатки или электронного
документа;
• формировать запросы к программе (с использованием диалоговой системы запросов).
Внешняя программа может:
• передавать и получать данные от программы в определенном формате и в зависимости от определенных событий;
• делать стандартные запросы к программе или формировать
запросы автоматически, используя логику системы запросов.
Для того чтобы обеспечить перечисленные виды взаимодействия, программа должна включать следующие компоненты [47]:
1) внутренние логические файлы (internal logical files – ILF),
содержашие структурированную информацию, необходимую для
работы программы;
2) внешние интерфейсные файлы (external interface files – EIF),
определяющие правила взаимодействия с внешним объектом.
Например, сценарий диалога ввода данных является внешним
интерфейсным файлом интерактивной системы ввода данных;
3) процессы ввода и вывода внешних данных (external input –
EI; external outpu – EO);
4) процесс формирования и реализации внешнего запроса
(external queru – EQ).
Функциональным типом будем считать один из перечисленных компонентов программы, для которого определены цель и
способ реализации.
В качестве примера рассмотрим информационную систему,
содержащию сведения о студентах. Отдельные функциональные
типы могут порождаться: функцией ввода информации из личных карточек студентов, распечаткой этих карточек, базой данных студентов, запросом об успеваемости, выгрузкой данных для
бухгалтерской программы и т.д. Чем больше функциональных
типов поддерживает программа, тем она сложнее. Типы можно
выделить уже на этапе построения диаграмм использования., поэтому количество функциональных типов служит достаточно хорошей мерой сложности и трудоемкости программы.
Функциональные точки. Однако сами типы далеко не однозначны по сложности. Как оценить индивидуальную сложность
каждого функционального типа?
##
Для функциональных типов, являющихся информационными ресурсами (ILF и EIF), сложность зависит от количества:
• реквизитов в одной записи1 (data element types – DET);
• записей (record element types – RET);
• связей, которые нужно учесть при формировании записи типа
или изменить при изменении записи (file type referented – FTR).
В нашем примере база данных студентов имеет следующие
реквизиты: фамилию; имя; отчество; пол; возраст; дату поступления; специальность. Количество DET = 7. База содержит сведения о 10 тыс. студентов: RET=10000. При вводе, удалении или
изменении информации необходимо отследить или внести изменения в следующие реквизиты: количество студентов, поступивших на данную специальность в данном году; состав студенческой группы; результаты успеваемости студента по каждому факту
проверки (экзамены, зачеты, модули и т.д.). Количество FTR = 3.
Очевидно, что влияние перечисленных характеристик на
сложность неодинаково. Меньше всего влияет число записей.
Оно должно измениться на несколько порядков, чтобы проявилась необходимость изменения алгоритмов и методов обработки. Изменение числа реквизитов в два раза, по крайней мере,
удваивает сложность. Однако сильней всего на сложность влияет количество учитываемых связей.
Для сопоставления влияния перечисленных факторов введем условную единицу функциональности – функциональную
точку (function point – FP) [47]. Для оценки количества FP используется эвристическая таблица, входами которой являются:
функциональный тип, а также количества DET, RET и FTR.
В табл. 3.7 приведены примеры, иллюстрирующие связь количества FP и сложности программы.
Описанный выше метод позволяет уточнять оценку сложности и трудоемкости программных компонентов по мере их проектирования. Оценка количества функциональных типов дается
уже на стадии анализа требований к программе и разработке
диаграмм использования. Более точная оценка по количеству
FP дается и уточняется на стадии проектирования архитектуры
программы. Такой подход позволяет отбрасывать непомерно
сложные варианты уже на ранних стадиях жизненного цикла,
1
Здесь даны упрощенные определения характеристик функциональных типов. Точные определения и описание метода функциональных точек можно найти на сайте www.ifpug.org.
#$
Т а б л и ц а 3.7
Типичные размеры программных продуктов
Êîëè÷åñòâî
Ïðèìåðû
FP
ñòðîê
10
1000
Ïðîãðàììû-óòèëèòû,
íåáîëüøèå èçìåíåíèÿ
â ñóùåñòâóþùèå
ïðîãðàììû
100
100000 Çàêîí÷åííûé ïðîåêò
ñðåäíåé ñëîæíîñòè
1000
105
104
106
105
107
Êîìåíòàðèé
Òðåáóåò îêîëî ìåñÿöà ðàáîòû
îäíîãî ïðîãðàììèñòà,
ïðàêòè÷åñêè âñåãäà óñïåøíî
çàêàí÷èâàåòñÿ
Ïðåäåë ñëîæíîñòè äëÿ îäíîãî
ïðîãðàììèñòà. Òðåáóåò áîëåå
ïîëóãîäà ðàáîòû. Ðèñê ïðîâàëà
15%
Íåáîëüøîå êîììåðÒðåáóþòñÿ ñïåöèàëüíûå ìåòîäû
÷åñêîå êëèåíòóïðàâëåíèÿ è îáåñïå÷åíèÿ êà÷åñåðâåðíîå
ñòâà. Êîëëåêòèâ ~10 ÷åë. (ìåíåäïðèëîæåíèå èëè
æåðû, ïðîåêòèðîâùèêè, ïðîãðàìîôèñíàÿ ïðîãðàììà
ìèñòû) è ãîä ðàáîòû. Ðèñê ∼ 15%
MS Office, ïðîèçâîä- Âàæíåéøàÿ ïðîáëåìà
ñòâåííîå ïðèëîæåíèå, óïðàâëåíèå ïðîåêòîì. Òðåáóåòñÿ
êîëëåêòèâ â 100 ÷åë. è îò 1,5
áîðòîâàÿ ïðîãðàììà
ëåòàòåëüíîãî àïïàðàòà äî 5 ëåò âðåìåíè íà ðàçðàáîòêó.
Ðèñê ∼ 50%.
Ïðåäåë ñëîæíîñòè. Òðåáóåòñÿ
MS Windows XP,
êðóïíåéøèå ñèñòåìû âûñîêîîðãàíèçîâàííûé êîëëåêòèâ
â íåñêîëüêî ñîòåí ñïåöèàëèñòîâ è
â îáëàñòè îáîðîíû
58 ëåò âðåìåíè íà ðåàëèçàöèþ.
Ðèñê ïðîâàëà ∼ 65%
сопоставлять возможные альтернативы реализации программы
до написания ее кода.
Несмотря на различия рассмотренных подходов, в них просматривается общая методология построения меры:
• выбирается свойство компонента программного продукта
(желательно количественное), которое хорошо коррелирует с
трудностью и временем его реализации;
• предлагается метод измерения этого свойства (желательно
на ранних этапах жизненного цикла);
• для ранее разработанных компонентов проводится сопоставление измеренного значения данного свойства со сложностью и трудоемкостью разработки компонента, строится функциональная зависимость;
• при планировании нового проекта найденные функции
используются для оценки затрат на разработку и их доверительных интервалов.
#%
3.5.3. Ó÷åò ñëîæíîñòè òðåáîâàíèé
ê ïðîãðàììíîìó ïðîäóêòó
Кроме сложности самих программных компонентов, на трудоемкость, риски и время реализации ПП влияют требования к
реализации и функционированию ПП.
Требования к функционированию ПП:
• сложность обработки информации;
• коммуникация данных;
• наличие дистанционной обработки;
• производительность;
• неоднородность потока транзакций;
• необходимость согласования и синхронизации процесса
вычисления с внешними процессами.
Требования к инсталляции и эксплуатации ПП:
• развитость интерфейса пользователя;
• уровень интерактивности использования ПП;
• разнообразие пользователей;
• простота установки (наличие инсталляции);
• развитость средств эксплуатации ПП.
Требования к гибкости, адаптируемости и обновляемости:
• наличие средств настройки и адаптации ПП;
• интенсивность обновления;
• возможность экспорта и импорта данных;
• возможность переноса ПП на другую платформу.
Эвристический алгоритм оценки влияния перечисленных
требований описан в [26]. Для каждого из требований задается
градация сложности в количественной или ранговой шкале.
Совокупная сложность определяется методами, аналогичными методам согласования мнений экспертов (см. разд. 1.3.2. гл. 1).
Учет условий разработки. Фактическая трудоемкость, стоимость и сроки разработки, а также риски провала проекта и
ухудшения его характеристик существенно зависят от условий,
сложившихся в организации в период разработки ПП, и уровня
зрелости самой организации1. В табл. 3.8 приведены характеристики условий разработки.
1
Классификация уровней зрелости фирм и коллективов разработчиков программного обеспечения дана в стандарте CMM.
#&
Т а б л и ц а 3.8
Условия разработки ПП
Õàðàêòåðèñòèêà
Ñîäåðæàíèå
Óðîâåíü
Íàëè÷èå ñòàíäàðòíûõ
çðåëîñòè
ïðîöåññîâ ðàçðàáîòêè,
îðãàíèçàöèè
ïîëåçíûõ íàâûêîâ è îïûòà
ðàçðàáîòêè
Ñòðóêòóðà
Âîçìîæíîñòü
óïðàâëåíèÿ
ñòðàòåãè÷åñêîãî è
îïåðàòèâíîãî
ïëàíèðîâàíèÿ; óïðàâëåíèå
ðåàëèçàöèåé, èçìåíåíèåì
è ðàçâèòèåì; ñèñòåìà
óïðàâëåíèÿ êà÷åñòâîì
Óðîâåíü
Êîìïåòåíòíîñòü è îïûò
ðàçðàáîò÷èêîâ
ó÷àñòíèêîâ ïðîåêòà, èõ
ìîòèâàöèÿ íà óñïåõ
ðàçðàáîòêè
Èñïîëüçîâàíèå
ñïåöèàëüíûõ
ñðåäñòâ
ðàçðàáîòêè
Ôèíàíñèðîâàíèå è ñðîêè
ðàçðàáîòêè
Êîììåíòàðèé
Èíòåãðàëüíàÿ
õàðàêòåðèñòèêà ãîòîâíîñòè ôèðìû ê
ðàçðàáîòêå ÏÏ
Âàæíîñòü
ýôôåêòèâíîé
ñòðóêòóðû óïðàâëåíèÿ ïîâûøàåòñÿ ñ ðîñòîì ñëîæíîñòè ÏÏ, à òàêæå ïðè
óæåñòî÷åíèè îãðàíè÷åíèé
íà
ôèíàíñèðîâàíèå
è
ñðîêè ðåàëèçàöèè ïðîåêòà
Âàæíî íå òîëüêî íàëè÷èå
âûñîêîêâàëèôèöèðîâàííûõ
ñïåöèàëèñòîâ, íî è èõ
óìåíèå ðàáîòàòü â êîìàíäå,
îïûò ñîâìåñòíîé ðàçðàáîòêè àíàëîãè÷íûõ ÏÏ
Ïðè ðàçðàáîòêå ñëîæíûõ
Íàëè÷èå è îïûò
ÏÏ èñïîëüçîâàíèå ñðåäñòâ
èñïîëüçîâàíèÿ
ñïåöèàëüíûõ ïðîãðàììíûõ êîììóíèêàöèè ó÷àñòíèêîâ
ðàçðàáîòêè, âåäåíèÿ äîêóè àïïàðàòíûõ ñðåäñòâ
ìåíòàöèè, óïðàâëåíèÿ êîíôèãóðàöèåé è àâòîìàòèçàöèè òåñòèðîâàíèÿ ñòàíîâÿòñÿ îáÿçàòåëüíûìè
Îãðàíè÷åíèÿ íà îáúåìû
Óæåñòî÷åíèå ýòèõ òðåáîè ãðàôèê ôèíàíñèðîâàíèÿ âàíèé ïîâûøàåò ðèñêè
è íà ñðîêè ðåàëèçàöèè
ïðîâàëà ïðîåêòà, âåäåò ê
ïðîåêòà
ïîâûøåíèþ òðóäîåìêîñòè
è óæåñòî÷àåò òðåáîâàíèÿ ê
äðóãèì
õàðàêòåðèñòèêàì
óñëîâèé ðàçðàáîòêè
В настоящее время разработан ряд методик и программных
средств, позволяющих оценить сложность и трудоемкость разработки ПП, а также риски провала проекта, затягивания его
реализации и ухудшения пользовательских характеристик. Большинство из них основано на градации значений характеристик,
перечисленных в этом разделе, и применении эвристических
алгоритмов оценки совокупного влияния этих характеристик.
Приведем характеристики нескольких методов:
#'
1. Регрессионный анализ зависимости трудоемкости и рисков от объема и сложности ПП. Это самый ранний метод оценки. В качесте меры сложности используется ожидаемый размер
кода (измеренный в строках). Метод удобен для оценки трудоемкости ПП при наличии множества аналогов и достоверной
информации о трудоемкости их разработки. Пример: Статистическая модель COCOMO II [35,27].
2 . Метод функциональных точек. Разработан международной
организацией International Function Point Users Group и компанией Software Productivity Research. Характеристики сложности
выделяются в результате анализа архитектуры ПП и требований
к его реализации.
3.Оценка трудоемкости на основе анализа вариантов использования. Разработчик – компания Rational Software.
Контрольные вопросы
1. Почему начальный этап разработки считается наиболее
сложным?
2. Сопоставьте потери и затраты, обусловленные ошибками,
допущенными на разных этапах жизненного цикла.
3. Назовите источники требований к разрабатываемой ПС.
4. Перечислите критерии, которым должна удовлетворять
система требований к программе.
5. Назовите методы сбора первичных требований к ПС.
6. Какая группа требований к ПС называется бизнес-требованиями?
7. Что вкладывается в понятие функциональных требований
к ПС?
8. В каком документе, согласно российским стандартам,
принято формулировать систему требований к программному
продукту?
9. Что означает понятие трассируемости требований?
10. Назовите группы требований, оказывающих друг на друга положительное и отрицательное влияние.
11. Что вкладывается в понятие «управление требованиями»?
12. Какие методы используются при планировании разработки программного обеспечения? Какими из них Вы воспользуетесь, планируя работу над Вашим дипломным проектом?
$
13. Какие системы стандартов определяют форму и содержание технического задания на разработку ПС в РФ?
14. Дайте определение прототипа ПС.
15. Стоит ли обсуждать с коллегами ошибки, которые Вы
допустили в ходе разработки? Почему?
16. Какую информацию следует зафиксировать при обнаружении и исправлении программной ошибки? Предложите свою
форму журнала самонаблюдений.
17. Что такое базовая линия устойчивости проекта и как она
используется?
18. При каких обстоятельствах можно утверждать, что ход
реализации проекта опасно отклонился от базовой линии?
19. Какие аспекты сложности программного кода отражают
мера Холстеда и цикломатическая мера? Как можно использовать эти характеристики?
20. Какие преимущества дает метод функциональных точек
при планировании программного проекта?
$
ÐÀÇÐÀÁÎÒÊÀ ÏÐÎÃÐÀÌÌÍÎÃÎ ÊÎÄÀ
È ÒÅÑÒÈÐÎÂÀÍÈÅ ÑËÎÆÍÛÕ
ÏÐÎÃÐÀÌÌ
4.1. Àðõèòåêòóðà ïðîãðàììíûõ ñèñòåì
После того как техническое задание согласовано с заказчиком, договор с ним подписан, построена модель предметной
области и частично разработаны внутренние спецификации,
наступает волнующий всякого программиста момент воплощения построенной модели в программном коде. Еще на заре программирования был замечен удивительный факт: если поручить
решение одной задачи разным программистам, то и программы,
которые они напишут, будут совершенно разными. Даже при
решении относительно простых задач существует огромное количество вариантов программной реализации.
При разработке требуется получить точный ответ на ряд вопросов: какую архитектуру применить? какие модули сформировать? какие межмодульные интерфейсы употребить? какие типовые или готовые решения и в каком объеме использовать?
какие средства разработки применить? и др. Хороший разработчик должен знать несколько вариантов ответов на эти вопросы.
Еще большим разнообразием обладают решения более низкого уровня, касающиеся логической структуры программы,
используемых алгоритмов и структур данных. Чем квалифицированнее и профессиональнее разработчик, тем больше возможных путей решения задачи он видит и тем больше у него возможностей выбрать оптимальный вариант решения.
Сложные системы требуют при создании значительных затрат ресурсов и времени. Для того чтобы окупить эти затраты,
такие системы должны обладать высоким качеством и использоваться достаточно долго, их невыгодно делать одноразовыми.
Качество системы во многом определяется ее архитектурой, так
как основные характеристики качества ПС в большей мере за $
висят от архитектуры, а не от конкретной реализации программного кода.
Архитектура программной системы – это первичная организация системы, сформированная ее компонентами, отношениями между компонентами и внешней средой системы,
а также принципами, определяющими структуру и эволюцию системы1.
С построения архитектуры начинается этап высокоуровневого проектирования программной системы. Одно из главных
требований к архитектуре создаваемой системы – ее концептуальная целостность, единство подходов и конструктивных идей.
Весь предыдущий опыт создания ПС на примере многих успешных и неудачных проектов убедительно показывает, что лучше
убрать из системы отдельные необычные возможности и улучшения, но построить ее на основе единой концепции, используя единые конструктивные решения. Множество реальных ПС,
оснащенных массой полезных функций, оказались неудачными
из-за того, что для их построения использовались хотя и хорошие, но несогласованные между собой идеи и архитектурные
решения. Яркий пример такой неудачной системы, приведенный в книге Фредерика Брукса [25], – операционная система
OS/360. Для достижения концептуальной целостности задача
построения архитектуры даже самых сложных ПС поручается
весьма ограниченному числу наиболее опытных разработчиков–
архитекторов.
Типовая архитектура современных программных систем при
любых подходах предполагает модульный принцип организации,
при котором система строится из относительно независимых
программных модулей. Каждый модуль может быть одним объектом или функцией, но, как правило, в модулях хранятся целые
наборы необходимых объектов, функций и процедур. При этом
каждый модуль реализует некоторую часть функций системы
или обеспечивает работу остальных модулей. Принципы межмодульного взаимодействия позволяют обеспечивать устойчивость, полноту и развиваемость системы.
Во многих программах можно выделить совокупности модулей, называемые уровнями, отвечающие за интерфейс с пользо1
Recommended Practice for Architectural Description of Software-Intensive
Systems, ANSI/IEEE Std 1471-2000.
$!
вателем (уровень представления данных), содержащие основные
алгоритмы обработки информации (уровень прикладной логики),
предоставляющие доступ к хранимым данным (уровень данных).
В частности, такую трехуровневую схему организации программных систем рекомендует использовать корпорация Microsoft.
Взаимодействие между модулями часто строится по принципу клиент-сервер, т.е. модуль, выступающий в роли клиента,
может отправить запрос другому модулю, выступающему в роли
сервера. Запросом может быть любая информация, требующая
обработки на сервере. Кроме этого модуль-клиент может принимать ответ от сервера на свой запрос. В свою очередь, серверный модуль должен находиться в постоянном ожидании запросов от клиентских модулей, а при поступлении запроса должен
уметь его обработать и отослать обработанную информацию в
качестве ответа клиенту. Как правило, серверный модуль способен обрабатывать запросы от многих клиентов. Такая схема организации взаимодействия между модулями позволяет размещать
их на разных компьютерах в сети и подходит для создания сетевого взаимодействия между ними, т.е. создания распределенного приложения.
В современных программных системах решаемые задачи настолько усложнились, что возникает необходимость разделять
их на большее число уровней. В этом случае трехуровневая схема может трансформироваться в многоуровневую, когда один и
тот же модуль может выступать и в роли клиента, обращаясь с
запросами к другим модулям, и в роли сервера, отвечающего на
поступающие запросы. Такая схема организации программных
систем оказалась особенно эффективной при одновременном
обслуживании большого количества клиентов и обработке больших объемов информации, так как позволила распределить решение задачи на большое количество компьютеров. Кроме этого, повысилась масштабируемость и надежность программных
систем.
Серверные модули, выполняющие повторяющиеся, типовые задачи и имеющие стандартный, унифицированный
интерфейс, принято называть сервисами.
В последние годы наиболее перспективной считается архитектура ПС, построенная на использовании сервисов (service
oriented architecture – SOA). В качестве сервиса в ПС, построен $"
ной в соответствии с SOA, может выступать как целое приложение, так и отдельные его функциональные модули. Взаимодействуя по сети в определенной последовательности, сервисы позволяют реализовать тот или иной процесс предметной
области.
Наиболее популярными стандартами межмодульного взаимодействия до недавнего времени были модели объектов COM/
DCOM (разработчик – корпорация Microsoft) и модель объектов Corba (разработчик – группа компаний Object Management
Group). В этих моделях детально прописано то, как необходимо оформлять интерфейсы модулей, чтобы их можно было
использовать в других программах, поддерживающих данную
технологию. Каждая из этих технологий снабжена соответствующими инструментальными средствами, позволяющими автоматизировать создание модулей, удовлетворяющих данным стандартам.
В настоящее время в связи с развитием концепции «сервис
ориентированной архитектуры» все большую популярность приобретают стандарты межмодульного взаимодействия, основанные на более универсальных и открытых технологиях. К таким
стандартам можно отнести протокол Simple Object Access Protocol
(SOAP) – для обмена данными и язык eXtensible Markup Language
(XML) – для представления данных.
Разработка архитектуры программной системы должна сопровождаться разработкой соответствующей технической документации, на основе которой в дальнейшем будут осуществляться процессы построения системы и внутреннего тестирования. Эта
документация должна содержать обоснование принятых проектных
решений, структурные и функциональные схемы программной системы, требования к отдельным программным модулям и т.д.
4.2. Ìåòîäèêè ïðîãðàììèðîâàíèÿ
История развития программирования сравнительно короткая, ей немногим более полувека. Но за это время накоплен
определенный опыт разработки качественного программного
кода, который оформлен в виде правил, рекомендаций, методик и руководств. Ниже будут рассмотрены наиболее важные
из них.
$#
4.2.1. Âîñõîäÿùåå è íèñõîäÿùåå
ïðîåêòèðîâàíèå ïðîãðàìì
Все множество методик разработки программ можно разбить
на два класса– восходящее и нисходящее проектирование программ. Более естественной для отдельного программиста является методика восходящего программирования, так как она повторяет естественный путь от простого к сложному. (Сначала
разрабатываются относительно простые функции и процедуры,
а затем на их основе – более сложные конструкции).
Однако при разработке больших и сложных проектов, над
которыми работали целые коллективы программистов, выяснилось, что более продуктивной оказывается нисходящая методика. Согласно этой методике один, обычно самый опытный программист, разрабатывал общую структуру программы исходя из
алгоритмической или объектной декомпозиции решаемой задачи. Далее разработка отдельных модулей программы поручалась
разным программистам или группам программистов. Их работа
начиналась с разработки так называемых заглушек – программ,
которые имитируют работу реальных программных модулей,
получая на вход необходимую для работы реального модуля информацию и возвращая информацию, похожую на обработанную по формату и содержанию. По мере готовности отдельных
программных модулей такие заглушки заменяются реальными
работающими модулями.
Большинство современных программ строится по методу
нисходящего проектирования. Визуальное проектирование программ в средах быстрой разработки–это наиболее массовый
пример применения принципов нисходящего проектирования.
Всякое помещение на форму очередного элемента управления –
это появление в древовидной структуре программы очередной
ветки: отдельные точки «роста» на ней закрыты заглушками –
обработчиками событий в жизни данного элемента управления,
для которых еще не написан программный код.
4.2.2. Ðàçëè÷íûå ïîäõîäû ê ïðîãðàììèðîâàíèþ
В программировании выделяют функциональный, логический, процедурный и объектный подходы. Каждому подходу соответствует свой набор языков программирования. Согласно
$$
данным известного сайта www.tiobe.com, на страницах которого
публикуются рейтинги различных языков программирования,
суммарный рейтинг на середину 2009 г. составил: объектно-ориентированных языков – 54,2%, процедурных языков – 41,8%,
функциональных языков – 2,8% и логических языков– 1,1%,
т.е. наибольшей популярностью пользуются два подхода к разработке программ – процедурный и объектный. Эти два подхода являются естественным продолжением алгоритмического и
объектного подходов к моделированию предметной области.
Исторически первым получил развитие процедурный подход
к разработке программных систем. Данный подход основан на
применении правил структурного программирования, о которых будет написано ниже, и заключается в составлении структурированных программ с выделенными по смыслу, замкнутыми
алгоритмами-процедурами. Эти выделенные процедуры и функции могут объединяться в библиотеки и оформляться как отдельные программные модули, содержимое которых доступно
из выполняемой программы. Необходимые для выполнения программы процедуры и функции извлекаются из библиотек на этапе
сборки приложения или динамически во время выполнения.
Такой подход позволил эффективно выполнять алгоритмическую декомпозицию и создавать программы, удобные для чтения и понимания человеком, прослеживания логики их работы,
внесения в них исправлений и других изменений, а также позволил в некоторой степени решить проблему повторного применения программного кода.
Однако с ростом сложности решаемых задач и создаваемых
моделей при использовании процедурного подхода возникли
проблемы, связанные с надежностью создаваемых программных
систем и сложностью повторного применения программного
кода, разработанного на основе разных языков и платформ.
Объектный подход в программировании, основанный на
создании иерархической системы классов, изначально нацелен
на легкость многократного использования программного кода и
простоту построения сложных систем из готовых объектов. Вместо библиотек процедур при этом подходе используются библиотеки классов, которые содержат описания объектов и позволяют
создавать в программах необходимое количество используемых
объектов. Сокрытие внутренней структуры объектов от программ,
в которых они используются, и стандартизация интерфейсов
$%
объектов в виде набора доступных свойств, методов и событий
не только упрощает их использование, но и значительно повышает надежность программ, построенных на их основе. Практически все современные сложные программные системы строятся с использованием объектного подхода.
4.2.3. Ïðàâèëà ñòðóêòóðíîãî ïðîãðàììèðîâàíèÿ
Главное правило структурного программирования гласит: при
создании программного кода можно использовать только три основные алгоритмические конструкции – линейную, ветвление и цикл.
Все современные языки программирования высокого уровня хорошо приспособлены для соблюдения данного правила. Интересно, что к сегодняшнему дню выросло несколько поколений
программистов, использовавших это правило. Они с удивлением читают нашумевшие в свое время статьи Эдсгера Дейкстры (1968
г.) и Дональда Кнута (1974 г.) о вреде безусловных переходов в
программе и запрете использования оператора Goto, а также о
его возможном использовании при обработке исключительных
ситуаций. Авторам данного пособия не встречались в последние
годы программисты, страдающие от необходимости использования этого правила и делающие попытки его нарушать (за исключением случаев выхода из вложенных циклов по дополнительному условию).
Другим правилом структурного программирования является
требование открыто объявлять используемые в программе переменные и максимально возможное ограничение области видимости
переменных, функций и подпрограмм. Использование глобальных
переменных допустимо только там, где это действительно необходимо. Опыт программирования показывает, что использование глобальных переменных значительно снижает надежность
программ и порождает наиболее трудоемкие в обнаружении причин возникновения ошибки.
Еще одним обязательным правилом современного структурного программирования является включение в код программы явных обработчиков ошибок, которые защищают программы от неожиданных ситуаций.
Повсеместное и безусловное использование данных правил –
яркий пример того, что эффективность алгоритмов в сложных
программах должна приноситься в жертву их надежности, по $&
нятности и анализируемости. Попутно заметим, что то же самое
происходит сейчас с использованием переменных типа указатели в языках программирования. Например, создатели языка C#
не рекомендуют использовать переменные типа указатели и не
поддерживают эту возможность в целях повышения надежности
программ.
4.2.4. Äîêóìåíòèðîâàíèå êîäà
Всякий создаваемый программный код необходимо снабжать
содержательными комментариями – это правило знает каждый,
даже начинающий программист (правда не каждый ему следует). Оно обусловлено удивительным свойством программного
кода – через сравнительно небольшой промежуток времени (недели, максимум месяцы) даже автору программного кода бывает
очень трудно разобраться в его логике (несмотря на соблюдение
всех правил структурного программирования). Об отладке, контроле, тестировании и сопровождении такого кода говорить не
приходится. К сожалению, при обучении программированию на
эту особенность программного кода обращается мало внимания
и программисты учатся искусству документирования в ходе практической работы вечным методом проб и ошибок.
Непреложным правилом является также использование при
разработке программного кода единых правил именования переменных и модулей, а также единых стандартов в одной команде разработчиков. Неважно, используете вы венгерскую нотацию1 или
свою собственную, важно, что, работая в команде, вы строго
следуете единым правилам оформления программного кода. Это
правило должно выполняться независимо от того, работаете ли
вы в маленьком коллективе, ведущем разработку небольшого
интернет-магазина по методике экстремального программирования, или являетесь членом большого программистского коллектива, разрабатывающего автоматизированную систему управления атомной электростанцией.
1
Система специальных соглашений по конструированию имен переменных, констант и других идентификаторов в программе, предложенная
Чарлзом Шимоньи и ставшая внутренним стандартом корпорации Microsoft.
$'
4.3. Ñðåäñòâà ðàçðàáîòêè
4.3.1. Ïðîáëåìà âûáîðà ñðåäñòâ ðàçðàáîòêè
Выбор средств разработки и языков программирования –
важный этап реализации программной части. От этого выбора
может зависеть успешность всего проекта. Естественно, что для
разработки клиентских веб-приложений и систем управления
сложными объектами в реальном времени должны использоваться разные средства разработки. Если мы создаем драйвер
нового устройства или критические части операционной системы, уместнее пользоваться языками низкого уровня. Другой
крайний случай – прикладная программная система, решающая
типовые задачи предметной области. Тогда может быть выгоднее купить сразу работающее приложение или проектировать
требуемую систему с помощью фабрики приложений, используя адаптацию под требования заказчика готового тиражируемого решения.
Чем больше у разработчика программ инструментов для их
разработки и чем лучше он владеет навыками по их применению, тем больше возможностей выбрать оптимальное для данной задачи средство и тем качественнее будет получаемый продукт. При всем богатстве имеющихся средств разработки одним
из важных критериев при выборе остается правило: лучшее средство то, которым ты лучше владеешь. Это тем более справедливо потому, что любое современное средство является сегодня
весьма универсальным, рассчитанным на широкий круг решаемых задач. Каждый более или менее опытный разработчик знает, что для реализации 90% задач в ходе реализации проекта
обычно используется не более 20% возможностей применяемых
средств разработки. Хотя во многих учебниках приводятся данные по трудоемкости реализации задач на разных языках программирования в виде таблиц соответствия количества операторов, приходящихся на одну функциональную точку, нам не
удалось найти данных о том, с какой погрешностью определены
указанные значения. С другой стороны, есть исследования1, ко1
DeMarco and Lister, 1985. Tom DeMarco, and Tim Lister. «Programmer
Performance and the Effects of the Workplace.» Proceedings of the 8th
International Conference on Software Engineering. New York: Institute of
Electrical and Electronics Engineers. – 1985. – Р. 268–272.
%
торые показывают весьма слабую связь использованного языка
программирования с производительностью труда программиста. В этих исследованиях показано, что разработчики, использовавшие «старые» языки, такие, как COBOL или Fortran, выполняли задания не хуже тех, кто писал на Pascal и С.
Единственным исключением из этого наблюдения стал язык ассемблера: участники эксперимента, писавшие на ассемблере,
сильно отстали от всех остальных языковых групп.
Сами средства разработки быстро меняются и совершенствуются, поэтому хороший разработчик должен постоянно изучать
особенности новых технологий. Часто бывает и так, что пока
изучишь какие то сложные приемы и возможности новой технологии, они успевают устареть. При этом производители инструментальных программных средств, как правило, не скупятся
на рекламу и оказывают сильное давление на потребителей с
целью побудить их как можно скорее купить новые средства
разработки и приступить к их освоению. Далеко не всегда время
и усилия, потраченные на это, окупаются.
4.3.2. Èñòîðèÿ ðàçâèòèÿ ñðåäñòâ ðàçðàáîòêè ÏÑ
История развития языков программирования и средств разработки программ начинается с середины XX в. Мы будем придерживаться следующей классификации этапов их развития.
П е р в ы й э т а п (1950-е – начало 1960-х гг.). Появились
первые языки программирования высокого уровня (Fortran,
Algol). Была сформулирована фундаментальная для технологии
разработки программ концепция модульного программирования1.
Основными средствами разработки у программистов были –
лист бумаги и перфоратор. Программы компилировались и запускались в пакетном режиме, т.е. к одной (страшно дорогой)
машине выстраивалась очередь из программ (а иногда и из программистов), которые последовательно запускались на компиляцию и выполнение. Основными средствами отладки были –
визуальный контроль листинга программы и анализ сообщений
компилятора и операционной системы (сообщения о процессах
1
См.: Жоголев Е.А. Система программирования с использованием библиотеки подпрограмм // Система автоматизации программирования. – М.:
Физматгиз, 1961. – С. 15–52.
%
компиляции и выполнения выводились на бумагу с помощью
печатающего устройства). Незаменимым был справочник сообщений об ошибках компилятора и операционной системы. Цикл
кодирование–компиляция–отладка даже для относительно несложных программных модулей мог иметь продолжительность
до нескольких дней.
В т о р о й э т а п (конец 1960-х – 1970-е гг.). Разработана
целая группа языков программирования высокого уровня (среди них Pascal, C, Ada, Basic и др.). Начало серьезных исследований в области методологий программирования и программной
инженерии. Сформулированы законы структурного программирования. В практику программирования вошло нисходящее проектирование программ. В продвинутых вычислительных центрах появились многотерминальные системы, оснащенные
простейшим текстовым редактором кода (например, система
Primus для OS ЕС ЭВМ). Компиляторы «научились» обнаруживать грубые синтаксические ошибки в программах. Однако цикл
кодирование–компиляция–отладка оставался достаточно продолжительным (до нескольких часов), так как программы все
еще запускались в пакетном режиме.
Т р е т и й э т а п (1980-е гг.). Появились персональные компьютеры и интегрированные среды разработки. Например, в России наиболее популярной стала среда Turbo фирмы Borland (Turbo
Pascal в 1984г. перенесен в операционную систему MS-DOS).
Разработаны объектно-ориентированные языки программирования. Основные возможности интегрированных сред разработки того времени – удобный и многофункциональный редактор
кода, компилятор с возможностями для раздельной компиляции модулей, средства быстрой сборки и запуска приложения,
эффективный отладчик кода, оснащенный средствами пошагового выполнения, динамического отслеживания значений переменных и т.д., легко доступные библиотеки функций и процедур, развитая справочная система.
Вот что пишет известный программист Джоэл Спольски (один
из разработчиков программы Excel) о появлении среды Turbo
Pascal:
«…мы выложили 600 долларов за IВM Pascal, который поставлялся на трех дискетах. Я написал простую программу «hello,
world» и скомпилировал ее. Общее время работы: 8 минут. Hдa.
Многовато. Я написал пакетный файл для автоматизации работы
%
и сократил время до 7,5 минут. Уже лучше. Но когда я попытался писать длинные программы, типа моей потрясающей версии
«Отелло», всегда у меня выигрывавшей, основное время стало
уходить на ожидание результатов компиляции…
Turbo Pascal просто потрясал, потому что делал практически
то же, что IВM Pascal, но занимал примерно 33 килобайта вместе с текстовым редактором. Это было просто изумительно. Еще
больше поражало, что небольшую программу можно было скомпилировать быстрее чем за 1 секунду. Это как если бы никому
не известная компания стала выпускать клон Buick LeSabre, двигающийся со скоростью миллион километров в час и объезжающий земной шар на таком количестве бензина, которого муравью не хватит, чтобы нанюхаться».
Внедрение новых средств разработки в этот период произвело революцию в разработке за счет многократного ускорения
цикла кодирование–компиляция–отладка.
Ч е т в е р т ы й э т а п (1990-е гг.). Повсеместное распространение объектно-ориентированного подхода в программировании. Появление средств визуальной разработки приложений.
Средства быстрой разработки приложений (RAD) стали типовым универсальным средством разработки для создания приложений, у которых имеется интерфейсная часть, и идеальным
средством создания прототипов. Кроме этого, в них, как правило, есть средства для разработки компонентов распределенных
приложений. В дополнение ко всем уже упомянутым возможностям интегрированные среды разработки оснащены средствами визуального проектирования приложения и обширной библиотекой стандартных объектов интерфейса программы. Для сред
RAD характерна простота многократного использования объектов, легкость создания массивов объектов, широкие возможности сборки программы из крупных блоков-модулей, высокая
скорость отладки приложений.
Формируется понятие о CASE-средствах разработки
(Computer Aided Software Engineering), как о средствах, автоматизирующих все основные этапы и процессы разработки. В составе инструментальных CASE-систем кроме средств автоматизации разработки кода программы появляются средства
управления конфигурацией программных систем с возможностями идентификации всех компонентов системы. Средства разработки оснащаются общедоступным хранилищем файлов со
%!
средствами контроля изменений, системой блокировок, ограничивающей изменения при множественном доступе к компонентам разрабатываемой ПС, системой поддержки целостности
компонентов проекта, системой контроля версий продукта и т.д.
В состав таких CASE-средств стали включать также средства
моделирования предметной области, средства автоматической
генерации программного кода на основе построенной модели,
средства обратной разработки модели на основе программного
кода, средства автоматической поддержки целостности документации всего проекта. Современные CASE-средства позволяют
уже на ранних стадиях разработки тестировать согласованность
и корректность модели и постоянно синхронизировать модель
предметной области с программным кодом.
Кроме высокой стоимости программного обеспечения, к
недостаткам современных CASE-средств можно отнести сложность подготовки и обучения, сложность интеграции с другими
средствами разработки, низкое качество получаемого автоматически программного кода и необходимость его ручной доводки.
П я т ы й э т а п (2000-е гг.). Быстрое развитие средств создания Web-приложений. К настоящему моменту существует
большое разнообразие эффективных средств разработки информационных систем для Web.
Говоря об используемых сегодня языках программирования,
можно выделить среди них определенный набор, который наиболее часто применяется при разработке. Ряд из них описан в
отраслевых стандартах, однако использование того или иного
языка программирования определяется в большей степени не
наличием стандарта, а его эффективностью при решении поставленных задач. Например, язык C# становится сейчас лидером при разработке Windows-приложений, несмотря на то, что
он пока не включен в стандарты ANSI. Под эффективностью
языка программирования в данном случае понимается обобщенная характеристика, которая содержит в себе стоимость и сроки
реализации требований, предъявляемых к ПС с помощью данного языка программирования. В табл. 4.1 приведены данные
сайта www.tiobe.com, публикующего результаты анализа относительной популярности современных языков программирования. При всей условности приведенных рейтингов эти данные
представляются достаточно объективными.
%"
Т а б л и ц а 4.1
Рейтинг популярности языков программирования
ßçûê
ïðîãðàììèðîâàíèÿ
Java
C
C++
PHP
(Visual) Basic
C#
Python
Perl
JavaScript
Ruby
Èþëü 2009
1
2
3
4
5
6
7
8
9
10
Ìåñòî â ðåéòèíãå
Èþëü 2005 Èþëü 1999 Èþëü 1984
2
4
1
1
1
3
2
4
6
3
5
7
19
8
5
5
9
12
27
4.4. Òåñòèðîâàíèå è îòëàäêà ïðîãðàìì
4.4.1. Îñíîâíûå ïîíÿòèÿ
Тестирование – важнейшее понятие при разработке ПС. В
программной инженерии тестирование рассматривается в двух
аспектах – и как процесс, который сопровождает все этапы ЖЦ
ПС, и как этап разработки, который следует обычно вслед за
этапами реализации программных компонентов.
Рассматривая тестирование как процесс, можно дать следующее определение: тестирование это процесс анализа или
эксплуатации программного обеспечения в целях выявления
дефектов (ошибок).
Под дефектом или ошибкой понимается случайное, непреднамеренное искажение (погрешность) в компонентах
программной системы, проявляющееся в процессе их анализа или функционирования.
Само понятие ошибки предполагает, что нам известно правильное, эталонное состояние компонента и процессов его функционирования. Знание об эталонном состоянии всех компонентов ПС формируется на основе всей системы требований,
предъявляемых к ПС, начиная от первичных требований пользо %#
вателя и заканчивая внутренними спецификациями и требованиями к документированию. Однако хорошо известно, что сами
требования тоже могут содержать неточности и быть некорректными. Таким образом, дефекты могут быть внесены в программную систему на любом этапе его жизненного цикла. Соответственно процессы тестирования должны сопровождать все этапы
жизненного цикла и выявлять ошибки как можно раньше.
Во всех руководствах по тестированию специально подчеркивается, что тестирование ни в коей мере не может служить
для доказательства отсутствия ошибок в программах и программных системах, так как такое доказательство требует проведения тестов при всех возможных комбинациях входных данных.
Провести подобное тестирование даже для простейших программ
невозможно. Классикой стало высказывание Эдсгера Дейкстры:
«Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие».
Другой важный принцип тестирования – «Тестирование успешно, если ошибки найдены»1.
(Хорошо, что далеко не все заказчики знакомы с этими принципами, и тестирование все-таки позволяет убедить заказчика в
качестве и надежности программы).
Рассматривая тестирование как этап жизненного цикла
ПС, можно определить цель тестирования, как проверку соответствия тестируемого компонента некоторым установленным требованиям.
В данном контексте тестирование выступает проверкой условия в точке принятия решения. Если несоответствия найдены, то программный компонент возвращается на доработку и
исправление ошибки или производится дальнейший анализ серьезности найденных ошибок. В противном случае компонент
ПС передается на следующий этап ЖЦ.
С тестированием тесно связан процесс отладки ПС.
Отладкой называется целенаправленный процесс обнаружения, локализации и исправления ошибок в программных компонентах на этапе их реализации. В этом случае тестирование можно рассматривать как процесс, формирующий
исходные данные для отладки.
1
%$
Alan M. Davis 201 Principles of Software Development, 1995.
Независимо от того, рассматриваем мы тестирование как
процесс или как этап работ, одним из главных принципов при
проведении тестирования является требование документальной
фиксации условий тестирования, тестовых наборов, ожидаемых
и получаемых результатов каждого теста. Любой тест независимо от того, выявил он ошибки или нет, должен быть воспроизводимым, а его результат – доступным для анализа. Соблюдение данного принципа позволяет быстро воспроизводить и
локализовывать найденные ошибки, а также проводить анализ
статистики обнаруженных и необнаруженных дефектов.
Существует большое количество объектов, порождающих
ошибки, и огромное количество объективных и субъективных
факторов, приводящих к их возникновению. Кроме этого, различные характеристики качества программных систем требуют
различных подходов к тестированию. Соответственно имеется
значительное количество видов и методов тестирования.
Все множество методов тестирования в зависимости от характера использования информации о тестируемых компонентах можно разбить на статические и динамические методы.
Статическое тестирование – это тестирование, проводимое без запуска на выполнение программного кода.
К этому виду тестирования относятся все методы инспекции
и анализа программного кода, включая автоматический синтаксический анализ во время компиляции и парное программирование в методологии экстремального программирования. К этому же виду тестирования относятся инспекции начальных
требований, анализ непротиворечивости моделей и т.д. Наиболее интенсивно данный вид тестирования проводится на начальных этапах ЖЦ ПС. Все современные руководства для программистов настоятельно рекомендуют разработчикам не
пренебрегать этим видом тестирования во время отладки программного кода.
Динамическое тестирование – это тестирование, проводимое посредством запуска на выполнение программного
кода, с подачей на вход тестовых наборов входных данных.
В динамическом тестировании, в свою очередь, выделяют
методы «белого ящика» (или «стеклянного ящика») и методы «черного ящика».
%%
Методом «белого ящика» называется динамическое тестирование, проводимое с учетом внутренней структуры программы.
Это значит, что и формирование тестового набора данных,
и анализ результатов тестирования строятся на основе знания
логики программы. Как правило, такое тестирование применяется на этапе отладки и при тестировании отдельных, относительно несложных программных модулей.
Методом «черного ящика» называется динамическое тестирование, при котором программа представляется в виде
объекта, внутренняя структура которого неизвестна, а формирование тестовых наборов и анализ полученных результатов строятся только на основании имеющихся спецификаций и наборов требований к программе.
Иногда тестирование методом черного ящика называют тестированием с управлением по входу и выходу.
В зависимости от того, какие объекты подвергаются тестированию, выделяют модульное тестирование – тестирование отдельных программных модулей, тестирование интерфейсов – тестирование межмодульных связей и системное
тестирование – тестирование всей или части системы, собранной из модулей.
В зависимости от порядка тестирования целого и частей системы в методологиях тестирования (по аналогии с методологиями программирования) выделяют восходящее и нисходящее
тестирование.
Восходящее тестирование означает порядок, при котором
сначала тестируются отдельные компоненты системы, стоящие
на нижнем уровне иерархии в системе, затем– их взаимодействие с другими протестированными компонентами, и на следующем этапе тестируется подсистема из этих связанных компонентов. Именно такая последовательность видов тестирования
предусмотрена в стандарте ЖЦ ПС по ГОСТ 34. Модульное тестирование выполняется, как правило, вместе с разработкой самого модуля, затем проводится тестирование его взаимосвязей с
другими модулями – интерфейсное тестирование. Системное, или
комплексное (интеграционное) тестирование является заключительным этапом тестирования ПС. В ходе такого тестирования
%&
модули сначала могут объединяться попарно, затем в более крупные блоки и, наконец, из модулей составляется вся система.
Преимущество данного подхода к тестированию состоит в том,
что он позволяет быстро и точно проводить локализацию ошибок. Специфика данного подхода заключается в необходимости
создания для каждого модуля специальных тестовых оболочек,
вызывающих тестируемый модуль.
При нисходящем тестировании сначала тестируются компоненты системы, стоящие на верхнем уровне иерархии, когда
большинство модулей заменены заглушками. В процессе тестирования заглушки постепенно заменяются реальными модулями. При таком подходе для тестирования отдельных модулей не
надо разрабатывать специальные тестовые оболочки. Однако
локализовать найденные ошибки при нисходящем тестировании бывает обычно сложнее, чем при восходящем.
В реальной жизни стараются тестировать каждый модуль сразу
после его разработки, поэтому для одних частей системы может
применяться восходящая стратегия, а для других – нисходящая,
в зависимости от порядка сборки системы. Нисходящее тестирование часто применяется на начальных этапах ЖЦ ПС при
статическом тестировании требований, модели предметной области и архитектуры ПС. Восходящее тестирование начинает
интенсивно применяться на этапе реализации, когда требуется
разработка самих программных модулей.
4.4.2. Âèäû òåñòèðîâàíèÿ
В зависимости от конкретных задач, решаемых с помощью
тестирования, а также тестируемых характеристик качества ПС,
выделяют следующие виды тестирования: приемочное (квалификационное), функциональное, регрессионное, тестирование
граничных условий, тестирование на ошибочных данных, нагрузочное, стрессовое, бета-тестирование, на соответствие стандартам, стабильности и т.д. Ниже приведены описания некоторых из них.
Приемочное (квалификационное) – тестирование, на жаргоне программистов называемое smoke test (тест, который длится,
пока горит сигарета). Этот вид тестирования проводится самым
первым. Его необходимость связана с тем, что программу, содержащую большое количество грубых ошибок, не имеет смысла
%'
проводить через весь цикл тестирования. Если система виснет
при малейшей провокации, возиться с ней не стоит. Более мелкие и менее критичные ошибки будут просто не заметны на
фоне грубых ошибок. Для проведения приемочного тестирования подбирают короткие тесты, в которых проверяется выполнение основных, наиболее часто используемых функций при
типичных наборах входных данных. Как правило, такие тесты
стараются автоматизировать и часто их поручают проводить самим разработчикам программы.
Функциональное – тестирование полноты и правильности
выполнения функций ПС, предусмотренных функциональными требованиями к системе. Как правило, этот вид тестирования заключается в проверке методом «черного ящика» соответствия ПС требованиям технического задания, реализованным в
последней версии ПС. Это основной вид тестирования в процессе верификации системы.
Регрессионное – тестирование, применяемое к исправленным,
измененным в целях устранения ошибок программным компонентам. Регрессионный тест – это полный набор тестов, охватывающий всю программу и выполняющийся всякий раз, когда
разработчики сдают очередную версию данной программы. Необходимость регрессионного тестирования как отдельного вида
обусловлена удивительным свойством программных компонентов – даже при внесении незначительных изменений в готовый
компонент вероятность допустить ошибку (и не заметить ее)
значительно выше, чем в случае, когда данный компонент разрабатывается с нуля. Очень часто исправление одной ошибки в
программе приводит к появлению другой. По некоторым оценкам, если для исправления ошибки необходимо изменить в готовой программе не более 10 операторов, то вероятность того,
что программисты сделают это правильно, не превышает значения 0,5. Это примерно в пять раз превышает типичный уровень
ошибок в компонентах, передаваемых программистами на тестирование в первый раз. Таким образом, в реальном процессе
разработки приходится тестировать одну и ту же программу на
одних и тех же тестах много раз.
Тестирование граничных условий. Давно замечено, что ошибки в программах чаще проявляются тогда, когда входные данные находятся вблизи границ допустимых диапазонов или вблизи
особых точек, в которых происходит изменение алгоритма их
&
обработки. Тест же считается тем лучше, чем с большей вероятностью он обнаруживает ошибки. Выделение данного вида тестов связано именно с тем, что такие тесты являются наиболее
эффективными. Тестирование границ широко применяют в процессе отладки при использовании методов «белого ящика», когда из программного кода видно, в каких точках входных данных
происходит смена алгоритмов или какие значения являются граничными для тестируемого алгоритма. При тестировании граничных условий методом «черного ящика» необходимо сначала
провести инвентаризацию данных, выделив типы данных, с последующей классификацией всех состояний, в которых они могут находиться.
В любом случае тестирование стараются провести при трех
значениях данных: граничном, вблизи границы слева и вблизи
границы справа. Если граничные значения не известны и входные данные являются числовыми, а ожидаемые результаты трудно
вычислить точно, то применяют методы анализа тенденций, т.е.
изменяют в какую-либо сторону значения входных числовых
данных и смотрят направление изменения выходных данных.
Тестирование на ошибочных данных – при этом виде тестирования специально стараются ввести данные, выходящие за границы допустимого диапазона: отсутствие входных данных, неверные типы данных, необычные или недопустимые комбинации
данных и т.д.
Нагрузочное – тестирование различных (как правило, функциональных) характеристик ПС при пиковой нагрузке по объему входных данных, количеству пользователей, количеству запросов и т.д. Это может быть также тестирование при уменьшенном
размере доступной оперативной или дисковой памяти, при параллельном запуске нескольких экземпляров приложения, при
одновременной загрузке системы другими задачами.
Стрессовое – тестирование, с помощью которого проверяется реакция системы на различные внештатные ситуации. Такими ситуациями могут быть аппаратные сбои, вирусные атаки,
неправильные действия пользователей и т.д.
Бета-тестирование – тестирование, проводимое потенциальными пользователями системы. Применяется на заключительных стадиях этапа тестирования непосредственно перед началом эксплуатации системы. Бета-тестирование может служить
средством валидации ПС.
&
4.4.3. Òåñòèðîâàíèå íàäåæíîñòè1
Надежность – важнейшее требование к ПС, одна из основных характеристик, определяющих качество ПС. Надежность,
согласно ГОСТ 9126 (см. гл. 1), имеет три составляющих – завершенность, отказоустойчивость и восстанавливаемость.
Наиболее сложной для измерения при тестировании является такая характеристика, как завершенность, т.е. некоторая величина, которая характеризует количество ошибок, оставшихся
в программной системе. Естественно, что никакими прямыми
измерениями определить эту величину нельзя.
В последние годы получают развитие формальные методы
доказательства правильности программ и отсутствия в них ошибок. Однако пока такие методы применимы лишь к относительно простым программам.
В процессе тестирования сложных ПС мы можем измерять
количество найденных ошибок, интенсивность обнаружения
ошибок, количество исправленных ошибок, сложность ПС и
относительное количество уже обнаруженных ошибок на одну
строку программного кода. В связи с этим единственным средством для определения завершенности ПС является построение
аналитической или эмпирической модели и сопоставление построенной модели с параметрами ПС, которые могут отслеживаться в процессе разработки ПС.
Особенности моделирования отказов программного обеспечения. Проблемой надежности технических средств и изделий занимается специальная наука: теория надежности. В рамках этой
науки разработаны модели надежности технических систем, комплекс характеристик надежности и методики оценки значений
этих характеристик для конкретных систем. Отказы в технических системах могут возникать из-за ошибок проектирования,
непредусмотренных воздействий внешней среды, износа системы, «усталости» конструкций и т.д. Кроме того, отказ может
возникнуть из-за накопления многих мелких ошибок и неисправностей.
Появление отказов технической системы в теории надежности рассматривается как случайный процесс, характеристики
1
Материалы этого раздела базируются на курсе лекций И.И.Серебрякова (http://www.serebiv.ru/).
&
которого зависят от параметров и качества исследуемой системы, а также от внешних факторов. Для описания процесса отказов используются понятия: интенсивность отказов (λ) – вероятность появления отказа в единичный отрезок времени;
вероятность безотказной работы системы за определенный период времени (P(τ)) и время наработки на отказ τ0. Иногда зависимость вероятности безотказной работы от времени называют
функцией надежности.
Многие положения теории надежности применимы и к программным системам. Однако, в отличие от технических средств,
сбои программного обеспечения могут быть вызваны только
ошибками в программе. При этом если устранение причины
аппаратурного отказа не гарантирует, что такой же отказ не повторится в дальнейшем, то, устранив ошибку в программе, мы
можем быть уверены, что из-за этой ошибки отказ уже не произойдет. Другая особенность программ состоит в том, что они
не подвержены износу и старению, поэтому вероятность программного отказа зависит не от времени или объема выполненной работы, а от выхода программы на участок, содержащий
ошибку, или от появления во внешних условиях ситуации, не
предусмотренной программистом.
Еще одно отличие программных систем от технических состоит в том, что в технике для обеспечения надежности широко
применяется дублирование отдельных подсистем или узлов. Дублирование в программных системах скорее приведет к обратному результату – уменьшению надежности, так как введение в
систему лишних элементов усложняет ее. Если же ошибка содержится в каком-либо программном модуле, то эта же ошибка
будет содержаться и в дубликате этого модуля.
Классификация моделей надежности программ. На рис. 4.1.
приведена иерархическая классификация моделей надежности
программного обеспечения в зависимости от способов и целей
моделирования, характера исходной информации и получаемых
результатов. В табл. 4.1 даны описания классов моделей. Ниже
приводятся описания некоторых моделей надежности, сгруппированных по классам.
Непрерывные модели. Стремление программиста уменьшить
количество ошибок после каждого шага тестирования можно
формализовать следующим образом: λi+1 < λi, где i – порядковый номер шага тестирования. Во всех рассмотренных моделях
&!
Рис. 4.1. Классификация моделей надежности программ
Т а б л и ц а 4.1
Описание классов моделей отказов программных систем
Êëàññ
Îñíîâàíèå
Àíàëèòè÷åñêèé Îò ÷åãî
çàâèñèò
íàäåæíîñòü
Ýìïèðè÷åñêèé
Îïèñàíèå
Ïðåäïîëàãàåòñÿ íåêîòîðàÿ àíàëèòè÷åñêàÿ çàâèñèìîñòü õàðàêòåðèñòèê íàäåæíîñòè îò êà÷åñòâà ÏÑ (íàïðèìåð, îò
êîëè÷åñòâà îøèáîê). Ïàðàìåòðû ìîäåëè
îïðåäåëÿþòñÿ èç ðåçóëüòàòîâ òåñòèðîâàíèÿ
Ïðåäïîëàãàåòñÿ, ÷òî ÷åì ñëîæíåå ÏÑ,
òåì áîëüøå îøèáîê îíà ìîæåò ñîäåðæàòü
Äèíàìè÷åñêèé Ó÷èòûâàåòñÿ
Ïîÿâëåíèå îòêàçîâ ðàññìàòðèâàåòñÿ âî
èëè íåò âðåìÿ âðåìåíè
îòêàçîâ
Ñòàòè÷åñêèé
Ðàññìàòðèâàåòñÿ çàâèñèìîñòü êîëè÷åñòâà
îñòàâøèõñÿ îøèáîê îò ÷èñëà òåñòîâûõ
ïðîãîíîâ èëè çàâèñèìîñòü âåðîÿòíîñòè
îòêàçîâ îò õàðàêòåðèñòèêè âõîäíûõ äàííûõ
Íåïðåðûâíûé
Äèñêðåòíûé
&"
Õàðàêòåðèñòèêà ìîäåëè
ïî âðåìåíè
Ôèêñèðóåòñÿ âðåìÿ ïîÿâëåíèÿ îòêàçîâ
Ôèêñèðóåòñÿ ÷èñëî îòêàçîâ â êàæäîì
ïðîãîíå
предполагается, что исправление одной ошибки не приводит к
появлению других ошибок (т.е. после исправления количество
ошибок уменьшается на единицу).
1. Модель Литтлвуда–Верралла.
Принимается следующая зависимость интенсивности i-того
отказа (λi) от i:
li = le( b0 + b1i ) .
Параметры модели λ, β0 и β1 определяются из статистики
результатов тестирования. Область использования модели –
моделирование процессов отладки.
2. Модель Джелинского–Моранды.
Предполагается, что интенсивность отказа λ прямо пропорциональна количеству ошибок N, содержащихся в программе
( l = ÑN ). Если первоначально в программе было N ошибок (λ1 =
CN), и при каждом тестировании выявляется по одной ошибке, то:
λ2 = C(N – 1); … λN = C. Для остальных M > N λM = 0. Считается,
что время, необходимое на исправление найденных ошибок, значительно меньше времени тестирования, поэтому в модели оно
не учитывается.
Рассмотрим интервалы времени, между обнаружениями очередной ошибки t1; t2 ⋅ tN. В соответствии с теорией надежности, плотности вероятности продолжительности временных интервалов между
отказами можно выразить через интенсивности отказов:
fi (ti ) = λi e − λi ti = C ( N − i + 1) e−C (N −i +1)ti .
Для оценки параметров C и N используем метод максимального правдоподобия1. Составим функцию правдоподобия
k
k
i =1
i =1
−C (N −i +1)t i
→ max
L = ∏ fi (ti ) = ∏ C ( N − i + 1) e
и найдем величину N, обеспечивающую максимальное значение
этой функции из уравнения
1
Корн Г., Корн Т. Справочник по математике для научных работников и инженеров. – М.: Наука, 1978. – 832 с.
&#
k
1
N − i +1
k
= i =1
.
k
k
∑ (N − i + 1)ti
∑ ti
∑
i =1
i =1
Зная величины ti, мы можем решить это уравнение численными методами. Отметим, что с увеличением числа наблюдений
(i), точность оценки исходного числа ошибок (N) возрастает.
3. Модель особых ситуаций.
В этой модели предполагается, что в ходе работы ПС возникают особые ситуации, не предусмотренные программистом.
Отказ в этом случае может произойти, а может и не произойти.
Время между наступлениями особых ситуаций считается случайным, имеющим показательное распределение с плотностью
f (t ) = le -lt . Вероятность отказа будет уменьшаться по мере обнаружения и исправления ошибок. В простейшем варианте мо-
дели принято pi = 1 - (1 - p1 )r ×i -1 , где pi – вероятность безотказной работы ПС в i-й по счету особой ситуации, i = 1,2,..., r –
параметр модели, 0 < r < 1. Неизвестные параметры λ, р1 и r
определяются по данным о моментах отказов.
4. Модель переходных вероятностей.
Модель используется, если время на исправление ошибок
соизмеримо со временем тестирования. Предполагается, что
время на поиск и исправление очередной ошибки также имеет
показательное распределение с параметром μ, который может
изменяться в зависимости от предыдущих выявленных ошибок
(обычно каждую следующую ошибку искать труднее, поэтому μ
уменьшается после каждой исправленной ошибки). Процесс
возникновения отказов и исправления ошибок описывается графом состояний, изображенным на рис. 4.2.
Обозначим через ПSi(t) вероятность того, что ПС в момент t
будет находиться в состоянии Si , через ПVi(t) – вероятность того,
что ПС будет находиться в состоянии Vi. В любой момент времени система может находиться только в одном из состояний
(Si или Vi). Тогда эти вероятности описываются бесконечной
системой уравнений
&$
Рис. 4.2. Граф состояний модели переходных вероятностей:
Vi – состояние, когда произошел i-й по счету отказ ПС
и ищется ошибка, вызвавшая этот отказ;
Si – состояние, когда ошибка, вызвавшая i-й отказ,
обнаружена и исправлена, а следующий отказ еще не наступил
PS0 (T ) +
¥
å (PSi (t ) +PVi (t )) = 1.
i =1
Начальные условия: ПS (0) = 1 – в начальный момент систе0
ма находится в состоянии S0;
Для всех i > 0 ПSi(0) = ПVi(0) = 0 – все остальные состояния
невероятны. Значение параметров λi и μi выбираются на основе
предыдущего опыта разработчика ПС.
Один из способов анализа подобных уравнений – метод
Монте-Карло. Многократно «разыгрывая» случайные последовательности событий Si и Vi, мы получаем статистку распределения искомого события – отсутствия сбоев для каждого интересующего нас момента времени.
Дискретные модели надежности ПС. В дискретных моделях
предполагается, что сначала проводится тестирование ПС, в ходе
которого выявленные ошибки не исправляются. По результатам
тестирования ПС отправляется на доработку или передается в
эксплуатацию. Модели используются для оценки характеристик внешнего тестирования и надежности ПС, прошедшего тестирование.
5. Модель Муса.
В модели Муса предполагается экспоненциальное распределение времени наработки на отказ. Пусть Т – суммарное время
тестирования; М – число отказов, произошедших за время тестирования. Тогда среднее время наработки до отказа после тестирования определяется по формуле
&%
τ = τ 0 exp(
где τ0
С
ÑÒ
),
Ì τ0
– среднее время наработки до отказа до начала тестирования,
зависящее от числа ненайденных ошибок и степени их проявления;
– коэффициент, учитывающий уплотнение тестового времени
по сравнению с временем реальной эксплуатации. Например, если один час тестирования соответствует 12 ч работы в
реальных условиях, то С=12.
Надежность ПП в период эксплуатации определяется как вероятность безотказной работы в течение определенного времени t:
P (t ) = e
-t
t.
Рассмотрим применение модели Муса для оценки достаточности тестирования ПП. Пусть в договоре с заказчиком определена требуемая величина средней наработки на отказ τd, а рассчитанное по результатам тестирования значение τ меньше
требуемого τd. Тогда необходимо провести дополнительное тестирование в течение некоторого времени ΔТ. Если во время дополнительного тестирования отказов не произойдет, надежность
ПП можно считать соответствующей условию договора. Общее
время тестирования Т + ΔТ должно удовлетворять соотношению:
C (Ò + ΔÒ )
τ d = τ 0 exp(
.
Ì τ0
Отсюда легко получить:
ΔÒ =
τ
Ì τ0
ln( d ).
τ
Ñ
6. Модель Шумана.
В этой модели предполагается, что тестирование проводится
в несколько этапов. Каждый этап представляет собой выполнение программы на наборе тестовых данных. Выявленные в течение этапа тестирования ошибки регистрируются, но не исправляются. По завершении этапа исправляются все обнаруженные
на этом этапе ошибки, корректируются тестовые наборы и проводится новый этап тестирования.
&&
Как в модели Джелинского–Моранды, предполагается, что
при корректировке новые ошибки не вносятся, а интенсивность
обнаружения ошибок пропорциональна числу оставшихся ошибок.
Пусть всего проводятся k этапов тестирования. Обозначим
продолжительность каждого этапа через t1 ,...t k, а число ошибок, обнаруженных на каждом этапе, через m1,...mk.
Пусть n = m1 +...+ mk – общее число обнаруженных и исправленных при тестировании ошибок;
ni = m1 +...+ mi. – число ошибок, исправленных к началу
(i + 1)-го этапа тестирования (n0 = 0).
На i-м этапе тестирования вероятность безотказной работы
Pi (t ) = exp(-C (N - ni -1 )t ),
где N – первоначальное количество ошибок в ПО;
ni-1 – количество ошибок, оставшихся к началу i-го этапа;
С – коэффициент пропорциональности.
Неизвестные параметры модели N и C можно приближенно
определить из системы уравнений (см. модель Джелинского–Моранды). Ожидаемое число ошибок, оставшихся в программе после
k шагов тестирования, равно N – nk. Тогда функция надежности
после завершения тестирования выглядит следующим образом:
Pi (t ) = exp(-C (N - nk )t ).
Статические модели надежности программ. Напомним, что
статические модели отличаются от динамических прежде всего
тем, что в них явно не учитывается время появления ошибок.
7. Модель Миллса.
Характеристики надежности программы определяются количеством ошибок в программе до и после тестирования. Рассмотренные выше модели дают возможность оценить эти величины. Однако для получения достаточно достоверных оценок
требуется провести очень большое количество тестирований. Для
повышения достоверности оценки числа ошибок и оценки эффективности тестирования Миллс предложил перед началом
тестирования искусственно вносить в программу некоторое количество известных ошибок. Ошибки вносятся случайным образом и фиксируются в протоколе искусственных ошибок. Специалист, проводящий тестирование, не знает ни количества, ни
характера внесенных ошибок. Предполагается, что все ошибки
(как естественные, так и искусственно внесенные) имеют равную вероятность быть найденными в процессе тестирования.
&'
Программа тестируется в течение некоторого времени, собирается статистика обнаруженных ошибок.
Пусть в программу внесено S искусственных ошибок, после тестирования обнаружено n собственных ошибок программы и L искусственно внесенных. Тогда первоначальное число ошибок в программе N можно считать пропорциональным отношению
собственных и искусственных ошибок, найденных в программе:
n
L
Например, если в программу внесено 50 ошибок и в процессе тестирования обнаружено 25 собственных и 5 внесенных
ошибок, то по формуле Миллса делается предположение, что
первоначально в программе было 250 ошибок.
Проверим достоверность этой оценки. Допустим, мы считаем,
что в программе первоначально К ошибок. Вносим искусственно в
программу S ошибок и тестируем ее до тех пор, пока все искусственно внесенные ошибки не будут обнаружены. Пусть при этом
обнаружено n собственных ошибок программы. Если n > K, гипотезу придется отвергнуть. Для K ≥ n вероятность, что в программе
первоначально было K ошибок, можно рассчитать по соотношению
N =S
P =
S
.
S + K +1
Например, если утверждается, что в программе нет ошибок
(K = 0) и при внесении в программу 10 ошибок все они в процессе тестирования обнаружены, но при этом не выявлено ни
10
= 0,91 . Таким образом, с
11
вероятностью 0,91 можно утверждать, что в программе нет ошибок. Но если в процессе тестирования обнаружена хоть одна
собственная ошибка, то P = 0.
Если не все искусственно внесенные ошибки найдены, вероятность гипотезы вычисляется по более сложной формуле:
одной собственной ошибки, то P =
⎧0
⎪⎪ L −1
P = ⎨ CS
⎪ K +L
⎪⎩CS + K +1
M – число сочетаний из N по M.
где C N
'
n>K
n≤K
,
Например, если утверждается, что в программе нет ошибок,
а к моменту оценки надежности обнаружено 5 из 10 искусственно внесенных ошибок и не обнаружено ни одной собственной
ошибки, то вероятность того, что в программе действительно
нет ошибок, будет равна:
p=
4
C10
5
C11
» 0,45.
Для 8 найденных ошибок вероятность повысится:
p=
7
C10
8
C11
» 0,73.
Достоинством модели Миллса является простота применяемого математического аппарата и наглядность. Использование этой
модели для оценки надежности оказывает положительное психологическое воздействие на лиц, выполняющих тестирование, уже
только тем, что они знают: в программу внесены ошибки.
8. Простая интуитивная модель.
Количество найденных ошибок зависит от их первоначального числа в программе и от искусства тестера. Чтобы снизить
влияние второго фактора, давайте поручим тестирование двум
специалистам (или группам, если объемы тестирования достаточно большие). Каждая группа проводит тестирование независимо и протоколирует найденные ошибки.
Пусть первая группа обнаружила n1 ошибок, а вторая n2. При
этом n12 ошибок обнаружено как первой, так и второй группой.
Обозначим через N неизвестное количество ошибок, присутствующих в программе до начала тестирования. Эффективность тестирования каждой группы определим как вероятность
обнаружения ошибки:
n
pi = i i = 1, 2.
N
Так как группы действуют независимо друг от друга, вероятность обнаружения n12 ошибок равна произведению вероятностей:
n
n
n
ð1,2 = ð1 × ð2 = 12 = 1 × 2 .
N
N N
'
Отсюда оценка первоначального числа ошибок равна:
nn
N = 1 2.
n12
9. Модель Нельсона.
При работе программы в реальных условиях риск отказа сильно зависит от того, какие комбинации исходных данных подаются на ее вход. Организуя тестирование, мы стремимся выявить как можно больше ошибок, поэтому чаще, чем в реальной
жизни, выбираем комбинации данных из «критических» областей. При этом надежность программы, рассчитанная по результатам тестирования, окажется существенно заниженной. Для
повышения достоверности оценки надежности разделим область
комбинаций исходных данных на k непересекающихся областей
Zi , i = 1, 2,...,k. Пусть к моменту оценки надежности было выполнено Ni прогонов программы на наборах данных из области
Zi , и ni из этих прогонов закончились отказом.
Пусть pi – вероятность того, что для очередного выполнения
программы в реальных условиях будет выбран набор данных из
области Zi. Тогда надежность работы программы в реальных
условиях оценивается по формуле
k n
P = 1 - å i pi .
i =1 N i
Эмпирические модели. Эмпирические модели основаны на
анализе накопленной информации о функционировании ранее
разработанных программ. Наиболее простая эмпирическая модель связывает число ошибок в программе с ее объемом. Из
опыта известно, что к началу системного тестирования в ПС на
каждые 1000 операторов приходится примерно 10 ошибок. Уровень надежности ПС считается приемлемым для начала эксплуатации, если тому же объему операторов будет соответствовать
одна ошибка.
Параметры зависимости от сложности программы существенно зависят от процессов разработки, используемых фирмой, и
от профессионального уровня разработчиков. Фирма IBM использует эмпирическую модель, которая оценивает число ошибок в различных редакциях операционной системы:
'
N = 23M10 + 2M 1,
где M10 – число модулей, потребовавших 10 и более исправлений;
M1 – число модулей, в которых обнаружено меньше 10 ошибок.
Применяется эмпирическая формула также для оценки средней наработки ПО на отказ:
V
τ = α îï ,
N
где τ – средняя наработка ПО в часах;
Voп – объем программы в операторах;
N – число ошибок в ПО, оцененное по одной из приведенных
выше моделей;
α – коэффициент, лежащий в диапазоне от 100 до 1000.
Определение оптимальной продолжительности тестирования.
Тестирование– достаточно дорогостоящая операция. Так как ни
один тест не может дать нам полную гарантию отсутствия ошибок
в программе, разработчикам приходится самим решать, когда заканчивать тестирование. Ошибки, выявленные на этапе эксплуатации (сопровождения) программы, обходятся фирме существенно дороже, чем выявленные и исправленные на этапе тестирования.
В связи с этим определение времени окончания тестирования можно
рассматривать как задачу минимизации суммарных затрат и потерь, связанных с программой (см. критерий Тагути).
Пусть Т0 – длительность жизненного цикла ПС;
T – искомое время тестирования;
k1 – стоимость обнаружения и устранения одной
ошибки на этапе тестирования;
k2 – стоимость обнаружения и устранения ошибки
на этапе эксплуатации1;
k3 – стоимость единицы времени тестирования ПС;
N – первоначальное число ошибок в программе;
λ – интенсивность отказов программы.
При заданной интенсивности за время t произойдет n(t) отказов:
n(t ) = N (1 - exp(-lt )) .
1
В эту характеристику следует включить производственные потери у
пользователя и потери фирмы, связанные со снижением ее репутации.
'!
Полная стоимость тестирования С1 (сюда входят стоимость
обнаружения и устранения ошибок и стоимость выполнения
тестовых прогонов):
C1 = k1n(T ) + k3T .
Стоимость устранения ошибок, возникающих на этапе эксплуатации:
C2 = k2 (n(T0 ) − n(T )).
Суммарные затраты и потери: С = С1 + С2.
Найдем Т, минимизирующий С:
C = k1n(T ) + k3T + k2 ( n( T0 ) − n( T)) =
k − k1 − λT
= k1N − k2 e− λT0 + k3 (T + N 2
e
) → min .
k3
k3
Введем обозначение: S = k − k , характеризующее соотно2
1
шение затрат на тестирование и потерь от ошибок. При заданных N и T0 величина С зависит только от Т. Производная этой
функции:
λ N − λT
dC
= k3(1 −
e
).
dT
S
При l N £ S производная всегда положительная, минимум
С достигается при Т = 0 (т.е. тестировать вовсе не стоит). Если
λN > S, минимум достигается при
T =
1
λN
ln(
).
S
λ
Отметим, что в модели сделано сильное и плохо согласующееся с практикой допущение: интенсивность отказов считается постоянной как во время тестирования, так и во время эксплуатации. Такое предположение имеет смысл только при
тестировании «хвостов», когда количество оставшихся ошибок
и вероятность отказа достаточно малы.
'"
Выбор модели надежности. Описанные выше модели строятся на достаточно простых модельных предположениях, что позволяет дать объяснимые оценки интересующих нас характеристик надежности программ. Однако, строго говоря,
предположения каждой модели выполняются только для очень
узкого круга реальных ситуаций, а для получения достаточно
достоверных и точных оценок требуется провести нереально
большое количество испытаний, поэтому модели могут быть использованы только для оценки порядка характеристик, а также
для анализа тенденций и зависимостей. Отметим, что все перечисленные модели используют статистическую информацию о
тестировании, что еще раз подчеркивает важность сбора и систематизации такой информации (см. гл. 3).
4.4.4. Îðãàíèçàöèÿ ïðîöåññà òåñòèðîâàíèÿ
Уровни качества и этапы разработки. Как отмечалось выше,
целью процесса тестирования является нахождение ошибок.
Ошибки ищутся для того, чтобы их исправить и тем самым повысить качество программной системы, т. е. процесс тестирования – важный компонент ЖЦ ПС, позволяющий обеспечивать
высокий уровень качества ПС. Хорошо известно, что ни один
тест и ни одна методика тестирования не могут гарантировать
выявление всех ошибок, поэтому на практике используется многоуровневая система тестирования, в которой задействованы различные методы тестирования.
Согласно современным представлениям о качестве ПС (см.
гл. 1), выделяют три уровня характеристик качества – пользовательский, внешний и внутренний. Этим уровням качества можно сопоставить соответствующие этапы разработки ПС. Их же
можно соотнести с определенными этапами тестирования ПС.
Соответствие между этапами разработки и тестирования принято изображать в виде так называемых шарнирно-каскадных, или
V-диаграмм. На диаграмме, приведенной на рис.4.3, этапы разработки соотносятся с этапами тестирования и уровнями характеристик качества ПС, с указанием ссылок на соответствующие
стандарты.
'#
'$
Рис. 4.3. Шарнирно-каскадная диаграмма (L-диаграмма)
Эта диаграмма иллюстрирует тот факт, что показатели пользовательского качества и соответствующие им метрики формируются на этапе сбора пользовательских требований, а используются на этапе валидации системы. Они же служат основой для
формирования системы показателей и метрик внешнего качества на этапе анализа и систематизации требований, которые
используются на этапе системного тестирования и верификации. В свою очередь, показатели и метрики внешнего качества
служат основой для формирования показателей и метрик внутреннего качества, используемых в процессе проектирования
программной системы на этапах отладки и модульного тестирования.
Тестирование на начальном этапе. Современные взгляды на
организацию процесса тестирования предполагают, что данный
вид работ начинается вместе со сбором и анализом первичных
требований заказчика. На начальном этапе разработки тестируются не программы, а идеи и документы. Обычно к этой работе
привлекаются специалисты по маркетингу, руководители проекта, системные аналитики. Во многих успешных компаниях к
этой работе привлекается также инженер по качеству ПС.
Как отмечалось в гл. 3, каждое требование пользователя должно быть проверяемым. Задача инженера по качеству на начальном этапе – установить критерии достижения того или иного
требования и продумать методику проверки этих критериев.
Такая работа уже на начальном этапе позволяет выявить некорректные или невыполнимые требования. Например, нельзя считать корректным такое требование: система должна иметь удобный и интуитивно понятный интерфейс, так как его выполнение
невозможно проверить. Включение подобного требования в ТЗ
дает юридическую возможность заказчику отправлять разработанную систему на бесконечные доработки. Следует отметить,
что стоимость исправления ошибок, выявленных на этом этапе,
невелика, в то время как стоимость пропущенных на этом же
этапе ошибок – максимальна.
На следующем этапе проектирования ПС применяются методы статического тестирования. Для этого привлекаются высококвалифицированные эксперты, способные провести анализ
построенной модели предметной области, проинспектировать
основные проектные решения, разработанную архитектуру системы и т.д. Как пример такого тестирования можно рассматри '%
вать порядок, при котором происходит «защита» проекта перед
тем, как будут привлечены большие силы к его реализации.
Внутреннее тестирование. Внутренним называют тестирование, в котором тесты основаны на внутренних показателях качества. На э т а п е р е а л и з а ц и и п р о г р а м м н о г о к о д а
внутренним тестированием занимается сам разработчик в процессе отладки. Иногда к внутреннему тестированию можно отнести и модульное тестирование.
Когда тестированием и исправлением найденных ошибок
занимается сам программист, ему не нужно взаимодействовать
с другими разработчиками и нет необходимости в тщательном
описании ошибок. Исходными данными при составлении тестов на этом этапе являются внутренние спецификации и характеристики внутреннего качества по стандарту ISO 9126-3.
Основным методом тестирования на э т а п е р а з р а б о т к и
п р о г р а м м н о г о к о д а является метод «белого ящика», хотя
важное значение могут иметь и статические методы, например,
инспекция кода, написанного другим программистом. Средой
для проведения тестирования служит сама среда разработки. По
некоторым оценкам на каждые 10 строк только что написанного программистом программного кода в среднем приходится 15
ошибок. На э т а п е о т л а д к и выявляется и исправляется 99%
этих ошибок. Полагается, что нет смысла передавать на этап
тестирования программу, в которой больше 1–3 ошибок на каждые 100 строк кода. (Во многих организациях это считается просто
неприличным). Такая программа не пройдет оценочное тестирование и тут же будет отправлена на доработку.
Средствами для проведения тестирования на данном этапе
являются все имеющиеся в среде разработки средства отладки.
Как правило, эти средства позволяют управлять ходом выполнения программы, отслеживать последовательность выполнения
команд, значения всех переменных и их адреса в памяти, проверять целостность данных. Некоторые средства отладки позволяют оценивать сложность тестируемых программ, эффективность
отдельных фрагментов программного кода, определять частоту
использования тех или иных ветвей программы. Современные
средства отладки позволяют достаточно эффективно проводить
как тестирование потоков управления (структуры программы),
так и тестирование потоков данных в программе.
'&
Критерием окончания отладки на этом этапе может служить
степень покрытия тестами кода программы. Самый слабый критерий – требование того, что в тестовых примерах каждая команда программы выполнилась хотя бы по разу. Более сильные
критерии – требование прохода всех ветвей программы и проверка всех вариантов логических условий. В настоящее время
разработаны специализированные программы, позволяющие
автоматически подсчитывать общее количество путей в программном коде, подлежащих проверке, и фиксировать, какая часть из
них уже проверена.
К сожалению, тестирование во время отладки оказывается
малоэффективным средством поиска ошибок, допущенных на
начальном этапе разработки при формировании системы требований к программе. Даже самая тщательная отладка с полным
покрытием всех команд и вариантов логических условий не может выявить многих ошибок в самой постановке задачи или в
использованном алгоритме. Кроме того, отсутствие ошибок в
какой-либо ветви программы при данном наборе входных данных, использованных при отладке, не означает, что ошибка не
появится в этой же ветви программы при другом наборе входных данных.
Эффективным на этом этапе бывает тестирование граничных условий, так как разработчик, глядя на код программы, всегда
видит эти граничные условия и особые точки в наборах данных.
Внешнее тестирование. Внешним называют тестирование, для
которого тесты основаны на внешних показателях качества.
Внешнее тестирование производится после того, как разработчик отладил программу и, по его мнению, она уже не содержит
ошибок (по крайней мере, он их не видит). Следовательно, внешнее тестирование совпадает с этапами интерфейсного и системного тестирования, т.е. служит для верификации ПС. Исходными данными для составления тестов на этом этапе является
техническое задание на разработку и характеристики внешнего
качества по стандарту ISO 9126-3. Основным методом внешнего
тестирования служит метод «черного ящика». Внешним тестированием занимается отдельная группа специалистов, не зависимая от разработчиков и не участвующая в разработке программного кода. Они проверяют соответствие ПС всем
требованиям ТЗ, полноту и правильность реализации функций
системы, ее стабильность, защищенность и т.д. Так как тести ''
рование и исправление найденных на этапе внешнего тестирования ошибок производится разными группами специалистов,
особое значение имеет тщательное планирование и документальная регистрация всех проведенных тестов, а также всех обнаруженных ошибок. Если описание ошибки недостаточно четкое и понятное или ошибка невоспроизводима, программист не
сможет ее исправить. Ни одна ошибка не должна быть потеряна. Каждая найденная ошибка должна быть воспроизводима. По
каждой ошибке должен быть проведен анализ и принято решение о необходимости ее исправления (далеко не все ошибки
целесообразно и экономически выгодно исправлять). Наилучшим решением проблемы учета результатов тестирования будет
ведение базы данных найденных и исправленных ошибок, в которой фиксируются параметры тестов, условия возникновения
ошибки, ее критичность и срочность исправления, трудоемкость
локализации и исправления и т.д.
После нахождения ошибок и принятия решения об их исправлении программные компоненты возвращаются на доработку
группе разработчиков.
Пользовательское тестирование. Пользовательским называют тестирование, в котором тесты основаны на показателях
пользовательского качества. Тестирование программы пользователями является завершающим этапом оценки качества ПС и
служит основой для валидации системы.
Пользовательское тестирование программ, предназначенных
для широкой продажи, проводят обычно конечные пользователи системы в два последовательных этапа, называемых альфа- и
бета-тестирование. На этапе альфа-тестирования в качестве
конечных пользователей – тестировщиков выступают сотрудники фирмы-разработчика, не связанные непосредственно с разработкой системы. На этапе бета-тестирования к тестированию
привлекаются на добровольной основе наиболее активные
пользователи ПС (не обязательно самые профессиональные),
которым бесплатно передается версия ПС для опытной эксплуатации. В обоих случаях разработчикам необходимо на этих этапах организовать эффективный механизм сбора и систематизации сообщений о найденных ошибках.
Программы, разработанные для конкретного заказчика, проходят заключительные этапы тестирования в процессе приемосдаточных испытаний, которые проводятся комиссией заказчика.
Порядок таких испытаний оговаривается в договоре между заказчиком и разработчиком и в техническом задании на разработку. Как правило, до проведения испытаний составляется разработчиком и утверждается заказчиком программа и методика
испытаний. В этом документе должны быть отражены все характеристики качества системы, предусмотренные техническим
заданием.
Взаимодействие разных видов тестирования. Схему взаимодействия внутреннего, внешнего и пользовательского тестирования можно представить в виде классической конструкции трех
вложенных циклов с постусловиями (рис. 4.4.). Для простоты на
схеме показан идеальный случай, когда критерием выхода из
внутренних циклов является отсутствие ошибок при соответ-
Рис. 4.4. Циклы внутреннего, внешнего
и пользовательского тестирования
ствующем виде тестирования. В реальной жизни такими критериями могут быть уменьшение количества неисправленных некритичных ошибок ниже некоторого граничного значения или
достижение программой необходимого уровня надежности, который может быть оценен по одной из моделей надежности,
приведенных выше.
В процессе тестирования общее количество найденных ошибок сначала возрастает, так как скорость обнаружения ошибок
на начальных этапах тестирования, как правило, превышает возможности разработчиков по их исправлению. По мере уменьшения количества обнаруживаемых в ходе тестирования ошибок наступает момент, когда скорость обнаружения новых
ошибок сравнивается со скоростью исправления уже найденных. С этого момента количество найденных и неисправленных
ошибок в программе начинает уменьшаться (В корпорации
Microsoft называют этот момент точкой конвергенции и рекомендуют фиксировать его).
Некоторые компании-разработчики в процессе тестирования
выделяют в отдельный класс регрессионные ошибки, т.е. ошибки, которых не было в исходных версиях и которые появились в
измененных, исправленных версиях программы. В ходе тестирования относительное количество регрессионных ошибок в общем количестве увеличивается. В результате на последних фазах
процесса тестирования приходится исправлять в основном регрессионные ошибки, и именно их количество часто служит критерием завершения соответствующего цикла тестирования.
Необходимо заметить, что внесение изменений в программах может быть связано не только с необходимостью исправления найденных ошибок, но и с появлением или изменением
требований в ходе разработки. Опыт разработки показывает, что
если не принять специальных мер по ограничению количества
изменений в программах по мере приближения ПС к завершению, этап тестирования может растянуться на длительный срок
из-за неубывающего со временем потока регрессионных ошибок. В качестве такой меры некоторые фирмы четко регламентируют размер и характер изменений, вносимых в программу на
каждом этапе. Кроме того, с продвижением проекта к завершению сужается круг лиц, которые могут принимать решения относительно внесения в программу изменений и исправлений.
Такое сужение позволяет добиться постепенного уменьшения
числа регрессионных ошибок.
Интересно проследить алгоритм обработки отдельной ошибки, пользуясь для этого схемой взаимодействия различных служб
при обработке ошибок (рис. 4.5). Обнаружить и сгенерировать
сообщение об ошибке может тестер или конечный пользователь
системы.
Рис. 4.5. Схема взаимодействия различных служб при обработке
ошибок: толстые линии – движение программного продукта;
тонкие линии – сообщения об ошибках
и управляющие взаимодействия
Исправить обнаруженную ошибку может только разработчик, а решение о необходимости исправления ошибки должен
принимать руководитель проекта или специальная служба обработки ошибок. Исправленная ошибка, если ее исправление подтверждается тестированием, попадает в разряд закрытых. Все
сведения о найденных ошибках, как исправленных, так и неисправленных, должны сохраняться в базе данных, с помощью
которой можно фильтровать, упорядочивать сведения об ошибках, восстанавливать историю работы с ошибкой.
Минимальные сведения о каждой ошибке, которые должны
храниться в базе данных ошибок:
1) действия, воспроизводящие ошибку;
2) требуемое (эталонное) поведение программы;
3) наблюдаемое (ошибочное) поведение программы;
4) лицо, ответственное за исправление;
5) отметка о том, исправлена ошибка или нет.
!
4.5. Ôèíèøíûå ýòàïû ðàçðàáîòêè
ïðîãðàììíûõ ñèñòåì
На заключительных этапах разработки происходит переход
от реализации и тестирования программной системы к ее сопровождению.
Сопровождением называется процесс внесения изменений в эксплуатируемую программную систему.
Такие изменения могут проводиться в целях исправления
ошибок в системе, выявленных в процессе эксплуатации, для
улучшения характеристик качества программной системы, а также
для адаптации системы к изменившимся требованиям. Серьезные фирмы-разработчики продумывают и организуют систему
сбора сообщений от пользователей программы, а также формируют команду специалистов для сопровождения программной
системы. По разным оценкам затраты на сопровождение могут
составлять от 40 до 90% от общей стоимости жизненного цикла
ПС. Любая программа, адаптацией которой к изменяющимся
внешним условиям никто не занимается, постепенно теряет свою
ценность.
Некоторые фирмы прекращают тестирование на последнем
этапе перед выпуском, другие продолжают тестирование и в
начале выпуска коробочных версий ПС. Если на этом этапе находится серьезная ошибка, то остается возможность остановить
производство. Хотя это может дорого обойтись разработчику,
но выпуск некачественного продукта наверняка обойдется еще
дороже.
Заключительный этап разработки ПС – самое подходящее
время навести порядок в документации и написать отчет о разработке. Знания о проекте в данный момент максимальны и их
надо зафиксировать, так как потом многое может забыться. В
связи с этим в хороших фирмах требуется писать отчеты.
Документация программы – неотъемлемая составная часть
программной системы. На заключительных этапах разработки
ПС происходит формирование комплекта эксплуатационной
документации, при необходимости проводится сертификация.
На этом этапе разработки необходимо зарегистрировать авторские права на разработанные программы, защитить их от пиратского распространения, уточнить лицензионные соглашения.
"
Если вы выпускаете программу для широкой продажи или
если для вашего заказчика она обладает высокой критичностью,
весьма желательно провести ее сертификацию. Часто сертификацию можно рассматривать как дополнительное внешнее тестирование, проводимое независимой от разработчика и заказчика
третьей стороной. Как всякий товар на рынке, программная система нуждается в раскрутке, рекламе, организации продаж и т.д.
Интеллектуальная собственность. Разработка программного
обеспечения – процесс, требующий больших затрат труда, времени и других ресурсов. В то же время скачать программу и
научиться ею пользоваться легко и просто. Если при этом разработчики не получат никакой оплаты за использование их программы, разработка полезных и нужных программ будет нерентабельной.
Чтобы защитить интересы разработчика и обеспечить справедливую оплату его труда, во всем мире используется правовая
охрана интеллектуальной собственности. В настоящее время в
связи с интеграцией России в мировую экономическую систему
защита интеллектуальной собственности становится особенно
актуальной.
Интеллектуальная собственность – собирательное понятие, означающее совокупность исключительных прав на
результаты творческой деятельности и средства индивидуализации. Это понятие впервые введено в 1967 г. Конвенцией, учредившей Всемирную организацию интеллектуальной
собственности, участником которой является Россия1.
Одной из задач финишного этапа разработки программной
системы является юридическое оформление отношений по поводу интеллектуальной собственности между тремя основными участниками процесса ее разработки и использования: разработчика
(автора программы), заказчика и пользователя системы.
До недавнего времени авторское право в области программного обеспечения в нашей стране регулировалось Законами РФ
«Об авторском праве и смежных правах», «О правовой охране
программ для ЭВМ и баз данных» и дополняющими их подзаконными актами. С 1 января 2008 г. все эти законы и подзаконные акты утратили силу и основным законом, регламентирую1
Правовая информационная система «Гарант». Толковый словарь.
#
щим авторское право на программы и базы данных, является
часть четвертая Гражданского кодекса Российской Федерации.
Не вдаваясь в юридические детали, отметим следующие основные положения данного закона. Права на результаты интеллектуальной деятельности (интеллектуальные права) можно разделить на имущественные (исключительное право) и
неимущественные (авторские права) (рис. 4.6).
Рис. 4.6. Правовые отношения в области интеллектуальной собственности
В соответствии со статьей 1259 Гражданского кодекса РФ
программы для ЭВМ относятся к объектам авторских прав и
охраняются, как литературные произведения.
Авторские права – это интеллектуальные (неимущественные) права на произведение (например, программу или базу
данных). Они возникают с момента создания произведения,
всегда принадлежат гражданину или гражданам, создавшим
произведение, и не зависят от факта регистрации данного
произведения или соблюдения каких-либо иных формальностей.
Лицо, указанное в качестве автора на оригинале или экземпляре произведения, считается его автором, если не доказано
иное. Авторские права не распространяются на идеи, концепции, принципы, методы, процессы, системы, способы решения
технических, организационных или иных задач, открытия, факты и языки программирования.
Исключительное право – это право использования результата интеллектуальной деятельности по своему усмотрению,
т.е. право распоряжаться произведением как собственностью.
Это право может принадлежать автору, если он создал произведение по собственной инициативе и его создание никак не
$
связано с его служебными обязанностями. Если автор создавал
произведение, исполняя свои служебные обязанности, то исключительное право на произведение принадлежит работодателю1. Если программный продукт создается по заказу, исключительное право на такой программный продукт, как правило,
принадлежит заказчику.
Знак охраны авторского права. Оповещает о принадлежащем
правообладателю исключительном праве на произведение, помещается на каждом экземпляре произведения и состоит из следующих элементов:
• латинской буквы «C» в окружности;
• имени или наименования правообладателя;
• года первого опубликования произведения.
Регистрация программ для ЭВМ и баз данных. Создав новую
программу и оповестив потенциальных покупателей о своем
исключительном праве на нее, вы можете распоряжаться программой как своей собственностью. Однако во многих случаях
желательно иметь документ, подтверждающий ваши права, а в
случае арбитражного разбирательства иметь возможность доказать,
что именно вы являетесь разработчиком данной программы.
Для получения официального документа, подтверждающего
интеллектуальные права на программу, и поддержки государства при защите этих прав разработчик может осуществить государственную регистрацию своей программы.
Процедура регистрации (рис. 4.7) начинается с формирования заявки. Заявка на регистрацию должна содержать:
• заявление о государственной регистрации программы для
ЭВМ или базы данных с указанием правообладателя, а также
автора, если он не отказался быть упомянутым в качестве такового, и места жительства или места нахождения каждого из них;
• депонируемые материалы, идентифицирующие программу
для ЭВМ или базу данных, включая реферат;
• документ, подтверждающий уплату государственной пошлины в установленном размере или наличие оснований для осво1
Известно судебное решение, когда программный продукт, созданный работником в нерабочее время не на рабочем месте без дополнительной оплаты, был признан служебным произведением, исключительное право
на которое осталось за работодателем, так как разработка программного
продукта проводилась во время работы лица на предприятии, соответствовала его служебным обязанностям и находилась под контролем работодателя.
%
Рис. 4.7. Процедура регистрации программы для ЭВМ
бождения от уплаты государственной пошлины, либо для уменьшения ее размера, либо для отсрочки ее уплаты.
Правила оформления заявки на регистрацию устанавливает
федеральный орган исполнительной власти, осуществляющий
нормативно-правовое регулирование в сфере интеллектуальной
собственности. В соответствии с «Положением о Федеральной
службе по интеллектуальной собственности, патентам и товарным знакам»1 таким органом в России является указанная служба, сокращенно именуемая Роспатент.
На основании заявки на регистрацию Роспатент проверяет
наличие необходимых документов и материалов, их соответствие
установленным требованиям. При положительном результате
проверки программа вносится в Реестр программ для ЭВМ; зая1
Положение утверждено постановлением Правительства РФ №299 от
16 июня 2004 г. и изменено 22 апреля 2005 г.
&
вителю выдается свидетельство о государственной регистрации,
а в официальном бюллетене публикуются сведения о зарегистрированной программе.
Если комплект документов, составляющий заявку, не полон
или неправильно оформлен, Роспатент пересылает заявителю
свои замечания. Заявитель корректирует и повторно посылает
заявку в Роспатент. Изменять содержание заявки можно вплоть
до публикации сведений в официальном бюллетене.
Защита интеллектуальной собственности при использовании
программ. Использование чужих программ без разрешения также незаконно, как использование любой чужой собственности.
В табл. 4.2 приведены варианты легального использования программ и документы, подтверждающие законность использования.
Т а б л и ц а 4.2
Документы, подтверждающие право
использования программного продукта
Îñíîâàíèå
äëÿ èñïîëüçîâàíèÿ
ÏÏ
Èñêëþ÷èòåëüíîå
ïðàâî
Ïðàâî èñïîëüçîâàíèÿ ïðîãðàììû
Äîêóìåíòû
Ïðèìå÷àíèå
Íàëè÷èå çíàêà îõðàíû
àâòîðñêîãî ïðàâà íà ïóáëèêàöèè ïðîãðàììû.
Ñâèäåòåëüñòâî îá îôèöèàëüíîé ðåãèñòðàöèè
ïðîãðàììû
Ëèöåíçèîííûé äîãîâîð
Åñëè ïðàâîîáëàäàòåëü
íå ÿâëÿåòñÿ àâòîðîì,
èñêëþ÷èòåëüíîå ïðàâî
äîëæíî ïîäòâåðæäàòüñÿ ñâèäåòåëüñòâîì
Право на использование чужой программы обычно оформляется в виде лицензионного договора (соглашения). В зависимости от условий договора продавец (лицензиар) может передать
покупателю (лицензиату):
• исключительное право на программу (исключительную лицензию). При этом продавец лишается права выдавать лицензии другим покупателям;
• неисключительное право (простую лицензию). Покупателю разрешается использовать программу на условиях, записанных в договоре. Продавец оставляет за собой право продавать
лицензии другим покупателям.
Лицензионный договор может быть оформлен как:
• договор, подписанный продавцом и покупателем. Такой
способ оформления обычно используется при передаче прав на
'
индивидуальное программное обеспечение, выполненное по заказу;
• оберточный договор – типовое соглашение между продавцом массового программного продукта и покупателем, подтверждающим признание условий договора при инсталляции программы.
В лицензионном договоре указывается объект (программа),
права на который передаются, объем передаваемых прав (исключительная/простая лицензия), сроки действия лицензии, обязанности сторон, а также все условия использования программы.
Процедура заключения лицензионного договора проиллюстрирована рис. 4.8. Необходимым условием продажи лицензии
является наличие у продавца исключительного права на программный продукт. В зависимости от объема передаваемых прав
продавец передает покупателю исключительные права на программу или только разрешает ею пользоваться. Содержание реального договора значительно сложнее описанной здесь схемы,
поэтому прежде чем принять условия договора, внимательно
прочитайте сам договор и оцените, сможете ли вы выполнить
все условия и стоит ли использовать программу на предложенных условиях.
Рис. 4.8. Процедура заключения лицензионного договора
Контрольные вопросы
1. Сформулируйте цели и задачи этапа высокоуровневого
проектирования программной системы.
2. Что такое архитектура программной системы? Какие требования к ней предъявляются?
3. Опишите достоинства и недостатки восходящего и нисходящего подходов к программированию больших систем. Каким
подходом воспользуетесь Вы при реализации дипломного проекта?
4. Сформулируйте основные принципы структурного программирования.
5. Какие проблемы можно решить, следуя правилам структурного программирования?
6. Сформулируйте основные принципы процедурного и
объектно-ориентированного подхода к разработке программных
систем.
7. В области заголовка программного модуля принято записывать его название, основное назначение, имя автора, дату создания, статус и т.д. Когда и зачем может быть использована эта
информация?
8. К чему приводит отсутствие единого стиля при формировании наименований программных модулей, переменных и
объектов сложной программной системы?
9. Перечислите основные функциональные возможности современных интегрированных сред разработки.
10. Расположите в хронологическом порядке следующие события:
• появление языков программирования высокого уровня;
• появление объектно-ориентированного подхода в программировании;
• появление средств визуального проектирования и CASE
средств разработки программных приложений;
• разработка правил структурного программирования;
• появление интегрированной среды разработки TURBO.
11. Может ли результат тестирования служить доказательством отсутствия ошибок в программе?
12. Чем отличаются методы тестирования белого и черного ящиков? Когда целесообразно применять каждый из этих методов?
13. Чем вызвана необходимость введения регрессионного
тестирования?
14. В чем состоит отличие альфа- и бета-тестирования?
15. Как интерпретируются понятия: интенсивность отказов λ;
вероятность безотказной работы P(τ) и время наработки на отказ τ0 при оценке надежности программных систем?
16. Чем обуславливается экспоненциальный закон распределения времени безотказной работы программной системы? При
каких модельных предположениях это утверждение справедливо?
17. Как оценить продолжительность тестирования, необходимую для обеспечения заданного уровня надежности программной системы?
18. Чем отличаются цели и задачи внутреннего, внешнего и
пользовательского тестирования? На каких этапах жизненного
цикла целесообразно проводить каждый из перечисленных видов тестирования?
19. Как программист может использовать информацию, полученную в ходе сопровождения написанной им программы?
20. В чем состоит отличие исключительного и авторского
права на программы для ЭВМ? Кто является обладателем этих
прав?
21. Какие права дает разработчику регистрация его программы?
22. В какое учреждение должна подаваться заявка на государственную регистрацию программы для ЭВМ? Опишите процедуру регистрации.
23. Какие документы должна содержать заявка на государственную регистрацию программы для ЭВМ?
24. Какой документ подтверждает авторские права на программу?
25. Разработайте комплект документов для заявки на регистрацию программы «Налоговый калькулятор».
26. Оцените, при каких условиях выгоднее продавать исключительное право на программу, а при каких – неисключительное.
27. Какие документы подтверждают право на использование
программного продукта?
ÓÏÐÀÂËÅÍÈÅ
ÏÐÎÃÐÀÌÌÍÛÌ ÏÐÎÅÊÒÎÌ
В условиях развитого, насыщенного товарами рынка качество продукции становится мощным фактором конкуренции. При
наличии выбора среди товаров сходного назначения покупатель
охотнее приобретет товар лучшего качества. Это дает фирмам,
заботящимся о качестве, дополнительный шанс в конкурентной
борьбе. Некачественные товары вытесняются с рынка, а производители, заботясь о своей репутации, становятся заинтересованными выпускать только качественный товар. Таким образом, основной целью управления фирмой становится управление
качеством.
Разработка программного обеспечения (ПО) – творческий
процесс, в который вовлечено множество людей разных профессий. Как организовать их совместную работу, как ориентировать коллектив на создание качественного продукта? В книге
«Человеческий фактор» [30] проведено исследование судеб нескольких сотен программных проектов. Осмысливая причины
удач и неудач, авторы приходят к выводу, что для реализации
успешного и действительно качественного проекта необходимо,
чтобы все разработчики считали его своим: сами оценивали уровень и качество своей работы, используя свои «внутренние стандарты», и обязательно получали удовольствие от сделанной работы. В то же время, причиной подавляющего числа неудач
является невыполнение указанных условий.
В данной главе рассматриваются основные идеи и методы,
обеспечивающие такое управление фирмой, чтобы выпускаемый
ею программный продукт всегда отвечал требованиям к качеству, диктуемым рынком, а сотрудники фирмы гордились своей
работой.
!
5.1. Ýâîëþöèÿ ìåòîäîâ óïðàâëåíèÿ
Для лучшего понимания сложившейся к настоящему времени системы методов управления, обеспечивающих производство
качественной продукции, совершим небольшой исторический
экскурс. Рассмотрим, как менялись представления о качестве
продукции, методах управления и обеспечения качества, отношения между людьми в процессе производства и потребления
продукции.
Допромышленное ремесленное производство. Как известно, в
период до промышленной революции производство несельскохозяйственных товаров в Европе в основном осуществлялось
ремесленниками. Хозяин мастерской, как правило, самостоятельно производил и продавал свою продукцию, закупал материалы, обучал секретам мастерства своих детей и подмастерьев.
Более опытный, аккуратный и старательный ремесленник быстрее продавал свою продукцию. Продавец порою буквально
жизнью отвечал за безопасность и качество своего товара. Знания ремесленника, относительно стабильный и надежный доход ставили его на более высокую, по сравнению с крестьянином, социальную ступеньку. В связи с этим профессиональные
знания и опыт, являясь источниками дохода и престижа, передавались по наследству детям и ученикам, наравне с материальными ценностями. Таким образом, проблема управления качеством решалась самим производителем, а производство
качественного товара мотивировалось отношением общества к
ремесленнику.
Издержки промышленной революции. С развитием производительных сил в обществе возрастала потребность в несельскохозяйственных товарах. Ремесленное производство, не способное удовлетворить возрастающую потребность, вытеснялось
промышленным способом производства. Преуспевающему промышленнику уже некогда было производить продукцию, появилась необходимость найма работников и разделения труда.
При использовании наемного труда обострилась проблема
управления. Если ремесленник, сделав свой товар, сам встречался с покупателем, то до работника мнение потребителя должен был донести хозяин предприятия. Самый простой метод
сделать это – заставить исполнять работу так, как считает хо "
зяин1. Такой подход к управлению мог осуществляться только
путем насилия, в условиях бесправия рабочих2. Появление машин усугубило положение рабочих и не изменило подход к управлению.
5.1.1. Ñèñòåìà Òåéëîðà
Совершенно другая ситуация сложилась в Новом Свете во
второй половине XIX в. Активное освоение нового континента
сопровождалось развитием рынка. Ограничения на природные
ресурсы, характерные для Европы, здесь не сдерживали развития зарождающейся промышленности. Единственным дефицитным ресурсом становятся квалифицированные рабочие руки.
Жаждущие свободы переселенцы3 не очень-то были настроены
попадать в новое «промышленное рабство». Для управления
новыми предприятиями требовались совершенно иные методы.
Другой причиной, делающей невозможным применение старых методов управления, становится все возрастающая сложность изделий. Если простую «черную» работу можно заставить
делать с помощью плетки, то «тонкую», ответственную принципиально нельзя.
1
Хорошо описана такая «система управления» в замечательной сказке
В.Ф. Одоевского «Городок в табакерке»: своевольная хозяйка Пружина
толкает Дядек Молоточков, а те нещадно лупят по Мальчикам Колокольчикам. Всем тошно, но музыка играет.
2 В XVI в. в Англии началось так называемое «огораживание». Крупные землевладельцы сгоняли со своих земель крестьян и устраивали на
них пастбища для овец. Лишенные средств существования крестьяне вынуждены были переселяться в города. В городах необходимость переработки шерсти ускорила развитие мануфактур. Вчерашние крестьяне, не
обученные никакому ремеслу, подвергающиеся жесткой эксплуатации, стали
основой пролетариата.
3 В книге Дэниела Бурстина «Американцы: национальный опыт». ( М.:
Прогресс, 1993. – 619 с.) ярко описаны нравы, характерные для Америки
того времени. Группа переселенцев, объединившаяся в конвой для путешествия на Запад, на второй день пути пишет «Конституцию» и выбирает
капитана. Во время путешествия капитан имеет широкие полномочия и,
практически, единолично управляет конвоем. Однако по прибытии на место
он становится рядовым переселенцем. Таким образом, власть воспринимается не как нечто дарованное человеку Богом на всю жизнь, а как функция, полезная всем членам общества в определенных условиях.
#
Выход предложил американский инженер Фридерик Тейлор.
Он разделил процесс производства на последовательность относительно простых операций. При этом операции выделялись так,
чтобы большинство из них могли выполнить неквалифицированные рабочие, а результат выполнения удобно оценивался.
Теперь хозяин не боялся нанимать на работу неквалифицированных людей. В договоре четко определялись их обязанности и
зависимость оплаты от их выполнения работником. Организация такой системы на предприятии требовала серьезной подготовки производства, пересмотра применяемых технологий и изменения характера отношений между работодателем и наемным
рабочим. Необходимость сопряжения и синхронизации множества
технологических операций потребовала документирования применяемых процедур и введения производственных стандартов.
Фактически система «научной организации труда» Тейлора
стала следующим шагом на пути специализации производства,
что позволило резко повысить производительность труда и управляемость производственных процессов. Многие принципы
этой системы лежат в основе организации производства современных предприятий.
Достижение высокого качества продукции при организации
труда по системе Тейлора, безусловно более производительной и
эффективной, неразрывно связано с внедрением стандартов, развитием стандартизации. Действительно, чтобы организовать взаимодействие множества исполнителей, каждый из которых выполняет лишь одну небольшую операцию, необходимо написать
четкие инструкции и хорошо продумать организацию работ. Затраты на это окупаются с лихвой. Теперь можно организовать поточное производство, заранее изготавливая однотипные взаимозаменяемые детали и собирая из них готовые изделия. При
благоприятной конъюнктуре предприниматель может организовать дополнительный прием рабочих, ознакомить их с инструкцией и быстро расширить свое производство. Предприятие может передать заказ на изготовление нужных ему деталей другой
фирме и быть уверенным, что детали точно подойдут к изготавливаемым изделиям. Технологическая инструкция превращается
во внутренний закон – стандарт предприятия. Стандарт позволяет оценивать качество не только готовой продукции, но и отдельных узлов и деталей. Для этого не нужен потребитель, главное, чтобы изделие соответствовало требованиям стандарта.
$
Развитие стандартизации позволило решить множество проблем унификации, специализации и кооперации производства.
Представление о качестве товара, как о соответствии его характеристик требованиям стандарта, надолго стало господствующим.
5.1.2. Ñèñòåìà Øóõàðòà
Во всех перечисленных подходах к управлению и обеспечению
качества молчаливо предполагалось, что качество изделия зависит
в основном от старательности рабочих, его изготавливающих. Однако дальнейшее повышение сложности изделий и технологий их
производства сделали очевидным, что качество и стабильность
больше зависят от управляемости процесса производства. Стало
понятным, что главное не наказать, а найти причину.
Впервые на это обратил внимание сотрудник компании Bell
Labs Вальтер Шухарт. Он занимался разработкой и эксплуатацией линейных усилителей. Эти достаточно сложные изделия
нужно было в буквальном смысле закапывать в землю для поддержания необходимого уровня сигнала в телефонной линии.
Стоимость самого изделия была ниже, чем затраты, вызванные
его отказом и заменой, поэтому надежность изделия играла первостепенную роль.
Изучая причины отказов, Шухарт заметил, что большинство
из них связано не с тщательностью изготовления, а с устойчивостью процесса производства. Анализируя причины, приводящие к отклонениям процесса производства от заданной траектории, он разделил их на два класса:
общие причины – неуправляемые, случайные природные (внутренние, присущие процессу) факторы. Таких причин, как правило, много. Влияние каждой из них может быть небольшим,
но суммарное действие существенно. Они определяют масштаб
собственной изменчивости нормально идущего процесса;
особые причины – несоответствия выполняемых операций
технологическим инструкциям, отклонения качества сырья, сбои
в управлении и т.д.
Как правило, общие причины вызывают хаотические отклонения от заданной траектории, а особые носят более регулярный характер. Исследуя статистический характер отклонений
реального процесса, можно оценить степень его управляемости
и перспективы повышения управляемости.
%
Обобщая эти исследования, Шухарт разработал концепцию
статистического управления качеством. Согласно этой концепции, производство продукции рассматривается как процесс,
подверженный случайным и не вполне случайным колебаниям.
Статистическое управление качеством - это деятельность
по управлению процессом, при которой акцент делается на
уменьшение вариаций, случайных отклонений характеристик процесса от намеченной цели.
Стратегия управления – исключение особых причин вариаций и уменьшение общих причин.
Критерий качества процесса – статистическая устойчивость (стабильность) процесса производства.
Для оценки стабильности управляемого процесса Шухарт
предложил использовать контрольные карты – временные диаграммы изменения основных параметров этого процесса. На диаграмме, представленной на рис. 5.1, изображаются: идеальная
(теоретическая) зависимость контролируемого параметра от времени (тонкая сплошная линия), границы доверительной области (штриховые линии) и реальное изменение параметра во времени (толстая ломаная линия). Контрольная карта Шухарта
позволяет наглядно проследить тенденции отклонений параметра
Рис. 5.1. Контрольная карта Шухарта
&
от теоретической кривой и вовремя вмешаться в процесс для
устранения нежелательных тенденций1.
Другими инструментами статистического управления являются статистический инженерный анализ, диаграммы Парето и
Исикавы.
Так как основным источником несоответствий являются вариации процессов, В.Шухарт предлагает отказаться от поисков
виноватых, а сосредоточиться на выявлении причин несоответствий. Главное – найти дефект/несоответствие, это помогает
найти причину.
Еще один вывод из концепции статистического контроля –
изменение отношения к персоналу. Персонал должен быть заинтересован в своевременном выявлении несоответствий и при этом
должен быть уверен в отсутствии негативных последствий таких
решений. У каждого процесса должен быть хозяин процесса –
определенное лицо, ответственное за правильное, надежное
функционирование устойчивого процесса, число вариаций которого желательно уменьшать. Хозяин процесса должен быть
заинтересован в том, чтобы процесс был устойчив и число вариаций снижалось. Вид мотивации существенно зависит от общих
принципов менеджмента, принятых в организации (денежное
вознаграждение, моральное поощрение и т.п.). Весьма полезной для этих целей может быть функция потерь Тагути. Таким
образом, именно хозяин процесса становится заказчиком по
отношению к технологам, разработчикам и работникам ОТК.
Работы В.Шухарта являются начальной точкой переворота
наших представлений о качестве и способах его обеспечения.
5.1.3. Íîâàÿ ôèëîñîôèÿ êà÷åñòâà (èäåè Äåìèíãà)
Понимание того факта, что большинство причин несоответствий вызваны несовершенством процесса производства, позволило по-другому взглянуть на роль процесса управления в обеспечении качества. Предыдущие подходы акцентировали внимание
на технологическом процессе производства. Однако в реальной
жизни качество продукции в большей степени определяется ка1
Отметим, что базовая линия устойчивости процесса, рассмотренная
в гл. 3, фактически является разновидностью диаграммы Шухарта для процесса разработки ПП.
'
чеством сырья и отношениями с его поставщиками, моральным
климатом в коллективе и распределением ответственности руководства, наличием достоверной информации и многими другими причинами, не связанными непосредственно с технологическим процессом.
Последователь Вальтера Шухарта Уильям Эдвардс Деминг
предложил системно взглянуть на всю совокупность причин
несоответствий. Процедуру управления он представляет в виде
замкнутой последовательности четырех действий – (цикла Деминга): планирования, исполнения, проверки, корректировки
(рис. 5.2).
Рис. 5.2. Цикл Деминга
Новую философию качества Деминг сформулировал в виде
14 принципов, представляющих собой ключевые принципы –
заповеди, применимые к любым компаниям, предприятиям и
их подразделениям, заботящимся о стабильном производстве
качественной продукции. Следует отметить, что принципы Деминга применимы практически ко всем видам производственной деятельности, большим и малым учреждениям вне зависимости от их формы собственности и организационной структуры.
Четырнадцать принципов Деминга:
1. Обеспечить постоянство цели: улучшение продукции и
обслуживания.
2. Принять новую философию – познание менеджерами
своих обязанностей и принятие на себя лидерства на пути к
переменам.
3. Покончить с зависимостью от массового контроля в достижении качества; исключить необходимость в массовом
контроле, сделав качество неотъемлемым свойством продукции, «встроив» качество в продукцию.
4. Покончить с практикой закупок по самой дешевой цене;
вместо этого следует минимизировать общие затраты и стремиться к выбору определенного поставщика для каждого
продукта, необходимого в производстве.
5. Совершенствовать каждый процесс для улучшения качества, повышения производительности и уменьшения затрат.
6. Ввести в практику подготовку и переподготовку кадров.
7. Ввести такой стиль руководства, который помогает
сотрудникам лучше делать свою работу; необходимо тщательно рассмотреть систему руководства персоналом.
8. Изгнать страхи, чтобы все могли эффективно работать для предприятия.
9. Разрушить барьеры между подразделениями: исследования, проектирование, производство и реализация должны
работать вместе, чтобы предвидеть проблемы производства
и эксплуатации.
10. Отказаться от пустых лозунгов, призывов для производственного персонала, таких, как «нуль дефектов» или «новые задания по производительности». Такие призывы бессмысленны, так как подавляющее большинство проблем возникает
в системе и находится вне возможностей работников.
11. Устранить произвольно установленные задания и количественные нормы.
12. Дать возможность работникам гордиться своим трудом; упразднить почасовую оплату среди рабочих, управляющих и инженеров; упразднить определение годовых и других рейтингов.
13. Поощрять стремление к образованию и совершенствованию.
14. Необходимы приверженность делу повышения качества
и действенность высшего руководства.
Предлагаемые Демингом принципы относятся к целям разного уровня, некоторые из них противоречивы, иногда не разделяются другими специалистами (например, 10-й). Но они представляют собой очень важные цели, для достижения которых
используются различные инструменты управления, менеджмента
качества, в том числе и предлагаемые другими специалистами.
5.2. Ñîâðåìåííûå êîíöåïöèè óïðàâëåíèÿ
5.2.1. Óïðàâëåíèå ïðåäïðèÿòèåì
â ïîñòèíäóñòðèàëüíûé ïåðèîä
С развитием индустрии массового производства рынок наполняется доступной продукцией приемлемого качества. В этих
условиях в выигрыше оказываются производители, сумевшие
приспособиться к разнообразию и изменчивости запросов потребителей. Оставаясь необходимым, умение предпринимателя
организовать производство оказывается недостаточным условием успешного бизнеса. Все более важным становится умение
вовремя выпустить нужную потребителю продукцию, более
привлекательную, чем продукция конкурентов.
Общество переходит от диктата производителя, навязывания им выгодных ему достаточно жестких и стабильных условий потребления к гибкой системе реагирования на возникающие запросы потребителей. Только такой подход – «изменчивость
в условиях жесткой конкуренции» позволяет выжить предприятиям на современном этапе.
Ярким примером, иллюстрирующим происходящие перемены, является эволюция стандартов корпоративных информационных систем1 (рис. 5.3). Начало разработок подобных систем
принято связывать с появлением в конце 1960-х гг. методологии
MRP (Manufacturing Resource Planning). Основной целью системы считалось планирование производства в условиях стабильного рынка.
1
Богаров Е.П. Интегрированные корпоративные информационные
системы: Принципы построения. Лабораторный практикум на базе системы «Галактика»: учеб. пособие / Е.П. Бочаров, А.И. Колдина. – М.: Финансы и статистика, 2007. – 288 с.: ил.
Рис. 5.3. Эволюция корпоративных информационных систем
К концу 1970-х гг. стало ясно, что методы жесткого планирования мало пригодны для управления реальным предприятием в динамично изменяющихся условиях. В качестве ответа на
эти вызовы были разработаны системы MRP с замкнутым циклом, позволяющие оперативно корректировать планы, адаптируя их к изменяющимся условиям, и системы планирования развития мощностей предприятия (Capability Requirements Planning).
К середине 1980-х гг. отдельные методы планирования удалось объединить в комплексное планирование всего производства (MRP II). Однако и этого было недостаточно. Практика
управления требовала создания систем, позволяющих организовать производство продукции в объемах, необходимых конкретным потребителям и доставлять ее точно в оговоренные сроки.
Без интегрального управления всеми видами деятельности
предприятия, включая маркетинг, финансовую деятельность и развитие предприятия, эта задача не разрешима. К началу 1990-х гг.
появилась новая методология планирования ресурсов предприятия ERP (Enterprise Resource Planning).
Принцип приоритетности требований потребителя становится
основой для методологии, синхронизирующей проявляющиеся
потребности и планы их удовлетворения в одной информационной системе CSRP (Customer Synchronized Resource Plainer).
5.2.2. Ñèñòåìà óïðàâëåíèÿ êà÷åñòâîì
Важнейшим фактором, обеспечивающим гибкость и динамику реагирования фирмы на возникающие запросы потребителей, является ее система управления. В связи с этим фирмы!
лидеры постоянно занимаются сбором, анализом, обобщением
и внедрением опыта в области управления. Как показывает практика, разрозненное применение даже самых замечательных методов управления не приносит желаемых результатов. Методы и
задачи управления тесно связаны между собой и для их успешного применения необходимо внедрить специальную систему
управления качеством.
Система качества – совокупность организационной
структуры, ответственности, методик, процессов и ресурсов,
необходимых для осуществления общего руководства качеством [12].
Система управления качеством должна охватывать все аспекты, как внутренней, так и внешней деятельности фирмы (рис. 5.4),
обеспечивать ее стабильное функционирование в существующих
условиях и возможность развития.
Рис. 5.4. Аспекты деятельности фирмы, охватываемые
системой управления качеством
"
Система качества создается для достижения следующих целей:
1. Обеспечение стабильной деятельности фирмы в существующих условиях:
а) стабильное производство продукции, уровень качества
которой соответствует требованиям, указанным в документации
(например, в договоре или рекламе);
б) стабильность и управляемость собственных производственных процессов;
в) стабильность и предсказуемость партнерских связей фирмы;
г) стабильность отношений с обществом и государственными структурами.
2. Обеспечение развития фирмы:
а) постоянное повышение качества, обеспечивающее все более полное удовлетворение запросов потребителей и лидирующее положение фирмы на рынке;
б) постоянное совершенствование и профессиональный рост
персонала, обеспечивающие готовность коллектива к решению
новых, более сложных задач, а также привлекательность для
специалистов работы в фирме;
в) развитие материально-технической базы, обеспечивающее
возможность решать новые задачи, востребованные обществом;
г) развитие социальной ориентации фирмы, обеспечивающее
стабильность коллектива и привлекающее перспективных специалистов.
5.2.3. Ñåðòèôèêàöèÿ ñèñòåì êà÷åñòâà.
Ñòàíäàðòû ñåðèè ÈÑÎ 9000
Еще одной особенностью современного рынка высокотехнологичной продукции является большая доля молодых фирм.
Для внедрения новых технологий или организации выпуска принципиально новой продукции очень часто выгоднее создать новое предприятие, чем реорганизовывать сложившуюся структуру. Добросовестные фирмы-новички стремятся быстрее завоевать
доверие потенциальных покупателей, однако те справедливо
опасаются приобретать ответственную продукцию у малоизвестных фирм.
Как разрешить это противоречие, облегчить путь к известности для добросовестных фирм и как можно раньше вытеснить
с рынка недостойных? Типовой способ подтверждения качества –
#
сертификация. По аналогии с сертификацией продукции может
быть проведена сертификация самой фирмы: ее системы управления, способности выпускать продукцию заявленного качества.
Для этих целей создаются специальные фирмы1, которые проводят аудит систем качества – всестороннюю проверку систем,
действующих на предприятиях. Если результаты аудита подтверждают способность предприятия стабильно выпускать продукцию заявленного качества, предприятию выдается сертификат.
Различные фирмы могут проводить аудит по отличающимся
методикам, предъявлять различные требования к системам качества, поэтому сертификаты, выданные разными аудиторами,
неравнозначны. Чтобы обеспечить необходимое единообразие
требований к производству и управлению предприятием при
аудите, разработан ряд международных стандартов серии ISO
9000. Первая версия комплекта стандартов ISO 9000 была разработана Международной организацией по стандартизации (ISO) в
1986 г. В ее основе лежала идея управления предприятием любого типа через управление качеством. При этом подразумевалось,
что для выпуска качественной (удовлетворяющей потребителя)
продукции необходима система управления качеством, затрагивающая практически все аспекты деятельности предприятия.
В ISO 9000 сформулированы требования для каждой стадии
жизненного цикла продукта – от маркетинга до утилизации. Такой подход затрагивает большинство, если не все подразделения и
процессы предприятия. Предполагается, что выполнение данных
требований дает потребителю некую гарантию того, что у производителя налажен устойчивый выпуск качественной продукции.
Не вдаваясь в детали, перечислим основные принципы и
требования к системам управления качеством, установленные в
стандартах серии ИСО 9000:
• ориентированность на потребителя;
• лидерство;
• привлечение персонала;
• процессный подход;
• системный подход;
• непрерывное улучшение;
• основанный на фактах подход к принятию решений;
• взаимовыгодные отношения с поставщиками.
1
Наиболее авторитетные среди них — Lloyd’s Register, SGS, Bureau
Verities, TUV.
$
Структура требований к системам управления качеством в
стандарте ISO 9001:2000 такова:
1. Ответственность руководства.
2. Управление ресурсами.
3. Управление процессами.
4. Измерение, анализ, улучшение.
При анализе системы управления рассматриваются следующие аспекты:
1) ответственность руководства – наличие у предприятия
сформулированной политики в области качества;
2) система качества – организационная система, обеспечивающая управление всеми процессами предприятия в целях достижения требуемого качества;
3) анализ контракта – процессы и процедуры, обеспечивающие качество продукции на этапе заключения контракта;
4) управление проектированием – закладывающее качество
будущей продукции на этапе ее проектирования;
5) управление документацией и данными – процессы оборота документов и информации, обеспечивающие своевременное
принятие решений на основе объективных данных;
6) закупки – обеспечение качества на этапе закупок сырья и
комплектующих;
7) управление продукцией, поставляемой потребителю;
8) идентификация и прослеживаемость продукции, обеспечивающие возможность анализа несоответствий и оценки эффективности мер по устранению причин несоответствий;
9) управление процессом;
10) контроль и проведение испытаний;
11) управление контрольным, измерительным и испытательным оборудованием;
12) статус контроля и испытаний;
13) управление несоответствующей стандарту качества продукцией;
14) корректирующие и предупреждающие действия;
15) погрузоразгрузочные работы, хранение, упаковка, консервация, поставки;
16) управление протоколами качества;
17) внутренние проверки качества;
18) подготовка кадров;
19) техническое обслуживание;
20) статистические методы.
%
5.2.4. Âñåîáùåå óïðàâëåíèå êà÷åñòâîì
Всеобщее управление качеством (TQM – Total Quality Management) – общая идеология управления качеством, включающая
весь комплекс рассмотренных методов и мер. Главная идея TQM
состоит в том, что предприятие должно работать не только над
качеством продукции, но и над качеством организации в целом,
включая работу персонала. Постоянное одновременное усовершенствование этих трех составляющих – продукции, организации, персонала – позволяет достичь более быстрого и эффективного развития бизнеса.
TQM охватывает четыре сферы:
• уровень качества продукции;
• удовлетворенность персонала;
• удовлетворенность клиентов;
• финансовые результаты.
По сравнению с традиционной системой контроля качества,
в TQM акцент переносится с контроля результата на контроль
процесса.
Постоянное улучшение качества считается основной стратегией развития фирмы. Цели системы управления качеством и
управления фирмой сливаются, так как именно качество продукции определяет стратегию управления. В табл. 5.1 дано сопоставление систем TQM и ISO 9000.
Т а б л и ц а 5.1.
Различия между TQM и ISO 9000
Àñïåêòû
TQM
Êðàòêîå Ñòðàòåãèÿ äîñòèæåíèÿ êîíêóîïèñàíèå ðåíòíûõ ïðåèìóùåñòâ ïóòåì
âíåäðåíèÿ êóëüòóðû íåïðåðûâíîãî ïîâûøåíèÿ ê à÷åñòâà
Àêöåíò
Îòíîøåíèå ëþäåé ê ðàáîòå
Öåëü
Íåïðåðûâíîå ïîâûøåíèå êà÷åñòâà: äîñòèãíóòûé óðîâåíü
êà÷åñòâà íèêîãäà íå ÿâëÿåòñÿ
äîñòàòî÷íûì; âñåãäà ÷òî-òî
ìîæåò áûòü óëó÷øåíî
Êóëüòóðà Óêàçàíèÿ ïðè÷èí íèçêîãî
êà÷åñòâà ïðîäóêöèè è öåííûå
ïðåäëîæåíèÿ ïî ïîâûøåíèþ
êà÷åñòâà îæèäàþòñÿ îò ðàáîòíèêîâ âñåõ óðîâíåé
&
ISO 9000
Íàáîð ïðàâèë, ñîáëþäåíèå
êîòîðûõ ãàðàíòèðóåò ïîñòàâêó
ïîòðåáèòåëþ òîâàðà ñ çàÿâëåííûì óðîâíåì êà÷åñòâà
Ñîáëþäåíèå ñòàíäàðòîâ
Ïîëó÷åíèå ñåðòèôèêàòà
Êàæäûé ðàáîòíèê èìååò ÿñíî
èçëîæåííûå îïèñàíèÿ ðàáî÷èõ
ïðîöåäóð è ñòðîãî ñëåäóåò èì
[14]
Таким образом, в отличие от ИСО 9000–стандарта, определяющего уровень, на котором предприятие способно обеспечить объявленное качество, TQM формирует стратегию развития предприятия.
5.3. Óïðàâëåíèå ðèñêàìè
ïðîãðàììíîãî ïðîåêòà
Разработка программного проекта всегда связана с риском:
начиная проект, разработчики очень часто не знают, какими
методами будут реализованы заложенные в него идеи, какие
трудности ждут их на этом пути, сколько времени и сил займет
реализация. Стоит ли так рисковать?
Авторы известной книги «Вальсируя с медведями»1 наоборот, считают, что не стоит браться за проекты, в которых нет
рисков, так как скорее всего такие проекты уже давно кем-то
осуществлены, поэтому в них нет никакой выгоды.
Риски и выгода всегда ходят парой. Взявшись и успешно
осуществив рискованный проект, вы получаете конкурентное
преимущество и известность (брэнд) на рынке программных
продуктов. Однако связавшись с неоправданно рискованным
проектом, вы ставите на карту свою репутацию, карьеру и судьбу фирмы. Грамотный менеджер стремится управлять рисками:
заранее оценить выгоды и риски, связанные с программным
проектом, продумать стратегию и методы снижения рисков, отслеживать ход реализации проекта и выявлять потенциально
опасные тенденции на ранней стадии их развития.
5.3.1. Ðèñêè, ñâÿçàííûå ñ ðåàëèçàöèåé ïðîåêòà
При реализации проекта репутация фирмы, ее коллектив и
процессы имеют определяющее значение. В связи с этим важнейшими являются риски не материальных потерь, а риски потери репутации, управления и возникновения проблем с коллективом. В табл. 5.2 приведены основные риски, связанные с
реализацией программного проекта.
1
Демарко Том, Листер Тимоти «Вальсируя с медведями. Управление
рисками в проектах по разработке программного обеспечения». М: Компания p.m.Office, 2005. – 208 с. (сайт: http://www.pmo.ru/riskology/).
'
Т а б л и ц а 5.2
Виды рисков реализации программного проекта
Âèäû ðèñêà
Ôàêòîðû ðèñêà
Ðèñê
Òåõíè÷åñêàÿ
ïðîâàëà
ñëîæíîñòü ïîñòàâëåííîé çàäà÷è
ïðîåêòà
Íåãîòîâíîñòü
ôèðìûðàçðàáîò÷èêà
Ðèñê ïîòåðè
ðåïóòàöèè
Ðèñê
îïîçäàòü
íà ðûíîê
!
Îïèñàíèå
Ñîâðåìåííûé óðîâåíü ïðîãðàììèðîâàíèÿ íå ïîçâîëÿåò ðåøèòü ïîñòàâëåííóþ çàäà÷ó
Êâàëèôèêàöèÿ ñïåöèàëèñòîâ, óðîâåíü
óïðàâëåíèÿ, äîñòèãíóòûé ôèðìîé, èëè
åå òåõíè÷åñêàÿ áàçà íå ïîçâîëÿþò åé
ñïðàâèòüñÿ ñ ïîñòàâëåííîé çàäà÷åé
Íåðåàëüíûå ñðîêè Ñðîêè ðåàëèçàöèè ïðîåêòà è åãî
è áþäæåò ïðîåêòà ñòîèìîñòü íå ñîîòâåòñòâóþò çàòðàòàì
òðóäà è ñðåäñòâ, íåîáõîäèìûì äëÿ
ðåàëèçàöèè ïðîåêòà. Èçëèøíÿÿ èíòåíñèôèêàöèÿ òðóäà ñîçäàåò òÿæåëûé
ïñèõîëîãè÷åñêèé êëèìàò, ÷òî òîëüêî
óñóãóáëÿåò ïðîáëåìó
Ïîòåðÿ
Îòñóòñòâèå ó àäìèíèñòðàöèè íåîáõîóïðàâëåíèÿ â õîäå äèìûõ íàâûêîâ óïðàâëåíèÿ ïðîåêòîì,
ðåàëèçàöèè
íåóìåíèå ñîòðóäíèêîâ ðàáîòàòü â êîìàíäå è ò.ä. ïðèâîäèò ê òîìó, ÷òî äàæå
âûñîêîêâàëèôèöèðîâàííûå ñîòðóäíèêè, èñêðåííå æåëàþùèå âûïîëíèòü
ðàáîòó, íå ìîãóò ñêîîðäèíèðîâàòü
ñâîè äåéñòâèÿ è äîâåñòè ïðîåêò äî
êîíöà
Íèçêîå êà÷åñòâî
Íàëè÷èå îøèáîê, íåïðîäóìàííûå
ïðîåêòà
ôóíêöèîíàëüíîñòü è èíòåðôåéñ, íåóäà÷íûå ïðîåêòíûå ðåøåíèÿ, ïëîõàÿ
ïðîåêòíàÿ äîêóìåíòàöèÿ è ò.ä. âûçûâàþò ó ïîëüçîâàòåëåé ñïðàâåäëèâûå
íàðåêàíèÿ. Âíåäðåíèå è ýêñïëóàòàöèÿ
íåêà÷åñòâåííîãî ïðîåêòà ïîðîæäàåò
àíòèðåêëàìó, ÷òî ñóùåñòâåííî âðåäèò
ðåïóòàöèè ôèðìû-ðàçðàáîò÷èêà
Íàðóøåíèå
Ïðåâûøåíèå ñðîêîâ è ñòîèìîñòè ðàçðàäîãîâîðåííîñòåé
áîòêè, íåâûïîëíåíèå îáîñíîâàííûõ
òðåáîâàíèé çàêàç÷èêà ôîðìèðóþò ó ïîòåíöèàëüíûõ çàêàç÷èêîâ ìíåíèå î íåíàäåæíîñòè ôèðìû-ðàçðàáîò÷èêà
Ïðåâûøåíèå
Èç-çà çàäåðæåê ñ ðàçðàáîòêîé èëè
ñðîêîâ ðàçðàáîòêè íåâåðíîãî ïëàíèðîâàíèÿ ðàíåå âîñòðåáîâàííàÿ è äîáðîòíî âûïîëíåííàÿ
ïðîãðàììà ìîæåò îêàçàòüñÿ íåâîñòðåáîâàííîé
Продолжение
Âèäû ðèñêà
Ôàêòîðû ðèñêà
Ðèñê
Îòêàç
óïóñòèòü
îò âûãîäíîãî
âîçìîæíîñòè è ïåðñïåêòèâíîãî
êîíòðàêòà
Ïîòåðÿ
ëèäèðóþùèõ
ïîçèöèé íà ðûíêå
Îïèñàíèå
Ôèðìà óïóñêàåò äîõîä. Èç-çà íèçêèõ
çàðïëàò è ìàòåðèàëüíîãî îáåñïå÷åíèÿ
ôèðìó ïîêèäàþò ñïåöèàëèñòû (êàê
ïðàâèëî, ëó÷øèå è íàèáîëåå âîñòðåáîâàííûå)
Îòêàçûâàÿñü îò àìáèöèîçíûõ ïðîåêòîâ, ôèðìà äåìîíñòðèðóåò ñâîþ íåãîòîâíîñòü ê èõ ðåàëèçàöèè. Ýòî îòïóãèâàåò ïîòåíöèàëüíûõ çàêàç÷èêîâ, ñíèæàåò èíòåðåñ ê ñîòðóäíè÷åñòâó ñ ôèðìîé íàèáîëåå ïåðñïåêòèâíûõ ñïåöèàëèñòîâ, ïîðîæäàåò çàñòîéíûå ïðîöåññû â êîëëåêòèâå
Как видим, риски существуют у каждого решения. Наша задача трезво оценить их и спланировать наши действия так, чтобы максимально снизить существующие риски.
5.3.2. Ðàçäåëåíèå îòâåòñòâåííîñòè
Умение распределять ответственность – одна из важнейших
составляющих культуры управления. В идеальном случае отвечать за риск должен тот, кто лучше всего может повлиять на его
снижение. При этом, если распределение окажется неравномерным, рискующий вправе требовать от своих коллег компенсацию в виде дополнительных ресурсов, полномочий, авторитета
и т.д. Рассмотрим типичное распределение ответственности.
Риск разработчика (риск не успеть или не суметь разработать обещанное). Реализуемый проект или отдельные его требования могут оказаться значительно более сложными и трудоемкими, чем представлялось в момент заключения договора. Их
реализация требует значительно больше времени и средств, чем
запланировано, или вообще невозможна. Именно разработчик
раньше всех может понять, что с проектом что-то не так, и принять необходимые меры для исправления ситуации.
Риск заказчика (риск заказать не то, что нужно). Проект реализован в срок и соответствует условиям договора, но он не
может быть использован как планировалось. Например, функциональность проекта недостаточна для решения поставленной
задачи. В этом случае заказчик не в праве обвинять исполнителя
!
в провале проекта. Ответственность за данный риск заставит
заказчика внимательно продумать условия договора прежде, чем
его подписывать.
Риск исполнителя (риск не справиться с порученным делом).
Когда руководитель поручал исполнителю эту работу, тот был
уверен, что справится. Это заставляет исполнителя ответственно браться за предложенную работу, а взявшись, приложить все
усилия для ее успешного выполнения.
Риск руководителя (риск потратить имеющиеся ресурсы не
на то). Исполнители выполнили всю порученную им работу,
однако конечный результат не достигнут.
Форс-мажор (риск стечения обстоятельств). Все выполнили
свои условия, однако по не зависящим от нас условиям проект
не может быть использован, как намечено. Этот риск неизбежен, однако ни разработчик, ни заказчик не могут повлиять на
него. В этом случае им придется разделить ответственность (и
потери, в случае их возникновения) между собой.
Недопустимо сваливать ответственность за все риски на одного участника. Это плохо не только потому, что не справедливо, это
пагубно для проекта. Дело в том, что вместе с отказом от ответственности за риск, участник проекта снимает с себя мотивацию
делать все, чтобы снизить риск. А участник проекта, взваливший
на себя чужие риски, объективно не может управлять ими. В результате вероятность риска и связанные с ним потери растут.
5.3.3. Êîëè÷åñòâåííàÿ îöåíêà ðèñêîâ
Риск – понятие достаточно сложное, в настоящее время существует много подходов к его определению и методам измерений. Обычно, когда говорят о риске, имеют в виду три связанные друг с другом вещи:
1) нежелательное событие;
2) вероятность появления этого события;
3) потери, связанные с появлением этого события.
Для количественной оценки риска введено понятие ожидание риска – математическое ожидание потерь, связанных с данным риском, а в простейшем случае– понятие единичного риска – это произведение вероятности появления нежелательного
события на размеры потерь. Если имеется полная система событий (включая идеальный вариант), то ожидаемые потери от
всех рисков есть математическое ожидание потерь.
!
5.3.4. Îïðåäåëåíèå ðàçìåðîâ ðåñóðñîâ,
íåîáõîäèìûõ äëÿ ñíèæåíèÿ ðèñêîâ
Борьба с рисками может быть экономически оправданной,
если размеры затрат на предотвращение и сокращение рисков
не превысят ожидаемых потерь. Отсюда вытекает стратегия определения размера затрат на снижение рисков: сумма затрат и
ожидаемых потерь должна быть минимальной.
Проблему оценки размеров ресурсов рассмотрим на простом,
но поучительном примере борьбы с опозданиями. Допустим, что
среднее время, которое вы затрачиваете на дорогу в институт –
30 мин. Однако на время в пути влияет множество независимых
факторов: автобус, на котором вы привыкли ездить, может задержаться, а может придти пораньше, ситуация на дороге может сложиться благоприятно, а может и не очень. Так как факторов много и они независимы, а влияние каждого из них невелико, можно
предположить, что случайная величина «время в пути» распределена нормально. Путем многократных наблюдений вы установили, что среднеквадратическое отклонение этой случайной
величины σ равно 1 мин.
На рис. 5.5 представлено распределение плотности вероятности для времени, затраченного на дорогу. Вероятность опоздания – площадь под кривой левее линии 30мин. Если вы регулярно выходите за 30 мин. до звонка, то в половине случаев вы
опаздываете (соответствующая площадь на рисунке заштрихована). Определим, за сколько минут вам следует выходить из
дома, чтобы число опозданий не превышало 1%. Для нормального распределения справедливо «правило трех сигм»: вероятность нахождения значения случайной величины в интервале:
среднее значение ± 3σ не менее 99%. Таким образом, если вы
будете выходить на 3σ = 3 мин. раньше, вероятность вашего
опоздания снизится до менее чем 1% (площадь, закрашенная
черным).
Конечно, в 99% случаев вам придется ждать звонка. Но это
гораздо лучше, чем постоянно опаздывать.
Прогнозируемое время разработки программного проекта
также является случайной величиной. Однако распределение ее
вероятности чаще всего далеко от нормального. На рис.5.6 изображена типичная кривая рисков. По горизонтальной оси отложено ожидаемое время завершения проекта, а по вертикальной –
!!
Рис. 5.5. Кривая нормального распределения плотности
вероятности для времени в пути
вероятность того, что проект завершится в данный момент времени. Отметим, что для кривых, приведенных на рис. 5.6, вероятность завершения проекта менее, чем за 62 дня, практически
равна нулю, 50%-ная вероятность наступает на 76-й день, наиболее вероятный день завершения разработки – 75-й, а с вероятностью 90% проект будет закончен ранее 90-го дня с начала
разработки.
Рис. 5.6. Кривая рисков завершения проекта
!"
Более наглядной будет кумулятивная кривая, отображающая
вероятность того, что проект будет закончен не позднее указанного срока. На рис. 5.7 приведен пример такой кривой. По горизонтальной оси отложены значения коэффициента увеличения срока (отношения реальной продолжительности проекта к
плановой), а по вертикальной оси – вероятность, что превышение не будет больше указанной величины.
Приведенные на рис 5.7 кривые построены на основе анализа статистики разработки нескольких сотен проектов, близких
по размерам и сложности реализации. Точка появления практически значимой вероятности (в нашем случае 65-й день) соответствует срокам завершения проекта по идеальному плану (ни
один риск не реализован, ничего не мешает проекту завершиться в срок). Конкретный вид кривых зависит также от уровня
фирмы-разработчика, эффективности применяемых процессов
разработки и системы управления качеством.
Рис. 5.7. Риск увеличения сроков из-за ошибок
планирования
!#
5.3.5. Òèïîâûå è ñïåöèôè÷åñêèå èñòî÷íèêè ðèñêîâ
Основной причиной затягивания сроков и превышения бюджета проекта, как правило, являются ошибки планирования. Как
видно из рис. 5.7, в половине случаев фактический срок реализации проекта превышает планируемый до 30% (К(50%)=1,3).
Перечень основных типовых причин рисков затягивания и удорожания программных проектов приведен в табл. 5.3.
Т а б л и ц а 5.3
Основные типовые причины рисков программных проектов1
Ïðè÷èíà
Îøèáêè
ïëàíèðîâàíèÿ
Îïèñàíèå
Ê(50%) Ê(99%)
Íåâåðíàÿ îöåíêà ïåðå÷íÿ ðà1,3
1,82
áîò, èõ òðóäîåìêîñòè è âðåìåíè, íåîáõîäèìîãî äëÿ ðåàëèçàöèè ïðîåêòà
Áîëüøîå êîëè÷åñò-  õîäå ðåàëèçàöèè ïðîåêòà âíî1,07
1,2
âî èçìåíåíèé
ñèòñÿ ñëèøêîì áîëüøîå êîëè÷åñòâî èçìåíåíèé
1,04
1,1
Òåêó÷åñòü êàäðîâ
Íîâûì ñîòðóäíèêàì òðåáóåòñÿ
âðåìÿ äëÿ àäàïòàöèè, ïðåæäå
÷åì îíè âêëþ÷àòñÿ â ðàáîòó ñ
ïîëíîé îòäà÷åé
Âçàèìíîå
Ðàçðàáîò÷èê è çàêàç÷èê, ðóêî- Îò 7 äî 12% ïðîíåïîíèìàíèå
âîäèòåëü è èñïîëíèòåëè, ðàç- åêòîâ òåðïÿò êðàõ
íûå èñïîëíèòåëè ïî-ðàçíîìó ïî ýòîé ïðè÷èíå
ïîíèìàþò òðåáîâàíèÿ ê ïðîãðàììå
ÏðîèçâîäèÑîòðóäíèêè ðàáîòàþò ñ ðàçíîé
1
1,1
òåëüíîñòü
ñêîðîñòüþ è îòäà÷åé. Ïðè
èñïîëíèòåëåé
óäà÷íîì ñòå÷åíèè îáñòîÿòåëüñòâ
ýòî ìîæåò ïðèâåñòè ê ñîêðàùåíèþ çàòðàò è âðåìåíè, ïðè íåóäà÷íîì ê óâåëè÷åíèþ
1
1,1
Ñîòðóäíèêè ðàáîòàþò ñ ðàçíîé
Ïðîèçâîäèòåëüñêîðîñòüþ è îòäà÷åé. Ïðè
íîñòü èñïîëóäà÷íîì ñòå÷åíèè îáñòîÿòåëüñòâ
íèòåëåé
ýòî ìîæåò ïðèâåñòè ê ñîêðàùåíèþ çàòðàò è âðåìåíè, ïðè íåóäà÷íîì ê óâåëè÷åíèþ
1
В таблице использованы материалы из книги «Вальсируя с медведями», авторы которых собрали базу данных из нескольких сотен историй
реализации программных проектов американскими фирмами.
!$
В последних столбцах таблицы указаны коэффициенты увеличения срока проекта: К(50%) – для 50%-ной вероятности и
К(99%) – для максимального превышения. Особое место занимает причина «Взаимное непонимание»: если участники проекта не сумеют договориться и однозначно понимать требования,
проект скорее всего потерпит крах.
Используя кривые риска для каждой из причин, можно построить результирующую кривую риска. Зная эту кривую, можно оценить риски и количественно определить ресурсы, необходимые для разумного сокращения их ожиданий.
В отличие от типовых причин, специфические причины рисков характеризуются большим разнообразием и взаимосвязями. Для их количественной оценки удобно применить методы
сценарного моделирования. Использование сценариев позволяет
превратить ворох цепляющихся друг за друга причин в логические цепочки взаимно обусловленных событий, каждая из которых реализуется с определенной вероятностью.
Рассмотрим этот метод на конкретном примере. Допустим,
длительность проекта – один год. При его разработке мы хотели
использовать перспективный программный инструментарий,
который обещают выпустить на рынок через полгода. Использование этого инструментария может существенно сократить
трудоемкость проекта и повысить его привлекательность. Однако выпуск инструментария может задержаться. Стоит ли ориентироваться на его использование или все делать самим?
Сформируем три сценария возможного развития событий и
оценим их вероятности:
1. Оптимистический. Ожидаемый инструментарий действительно появится через полгода и хорошее качество позволит успешно использовать его в нашем проекте (вероятность реализации – 20%).
2. Умеренно оптимистический. Инструментарий появится, но
потребуются его доработка и адаптация (вероятность реализации – 40%).
3. Пессимистический. Инструментарий вовремя не появится
(вероятность реализации – 40%).
Мы можем придерживаться двух стратегий: самостоятельно
разрабатывать проект, не надеясь на появление нового инструментария (это стоит 100 тыс. руб.) или дождаться появления
инструментария и адаптировать его к проекту (30 тыс. руб.).
!%
Составим матрицу потерь (табл. 5.4). В ячейках матрицы
запишем сумму затрат и потерь, соответствующих стратегии-строке и сценарию-столбцу. Например, при самостоятельной разработке при любом сценарии мы должны затратить 100 тыс. руб.,
но при этом не понесем потери. При использовании инструментария мы потратим 30 тыс. руб. при оптимистическом сценарии, несколько больше (60 тыс. руб.) при умеренном, и понесем большие потери (200 тыс. руб.) из-за провала проекта в случае
реализации пессимистического сценария.
Т а б л и ц а 5.4
Матрица потерь, тыс. руб.
Ñöåíàðèé
Îïòèìèñòè÷åñêèé
Óìåðåííûé
Ïåññèìèñòè÷åñêèé
20%
40%
40%
Ñàìîñòîÿòåëüíàÿ
ðàçðàáîòêà ïðîåêòà
100
100
100
100
Àäàïòàöèÿ èíñòðóìåíòàðèÿ
30
60
200
110
Ñòðàòåãèÿ
Ïîòåðè
ñòðàòåãèè
Совокупность наших сценариев образует полную систему
событий: они альтернативны и один из них обязательно реализуется. В связи с этим потери по каждой стратегии вычислим
как математическое ожидание потерь. Из табл. 5.4 видно, что
потери второй стратегии больше, чем первой, и в данных условиях разумнее не дожидаться появления инструментария.
5.3.6. Îòêóäà áðàòü èíôîðìàöèþ î ðèñêàõ
Как отмечается в литературе об управлении, самые опасные
риски, это те, о которых мы забыли или вообще не знали, поэтому первое, что необходимо сделать, приступая к управлению
рисками, выписать все возможные риски проекта.
Серьезным поставщиком рисков являются нерешенные проблемы. Даже если в предыдущем проекте нам удалось как-то
обойти их, проблема грозит нагнать нас в следующих проектах,
и так до тех пор, пока не будет найдено ее решение. В связи с
этим проблемы следует анализировать и решать сразу после их
!&
осознания, не дожидаясь, пока они проявятся в самый неподходящий момент.
Чем больше мы знаем о рисках, тем эффективнее можем
ими управлять. Источники таких знаний – наш и чужой опыт.
У каждого из этих источников есть свои достоинства и недостатки. Чужого опыта много, на его основе можно делать достоверные статистические выводы, но при этом не учитываются
особенности конкретной команды, фирмы и тематики, поэтому
необходимо постоянно собирать и систематизировать собственный опыт управления разработками.
5.4. Óïðàâëåíèå ïåðñîíàëîì
5.4.1. Ðîëü ïåðñîíàëà â ýôôåêòèâíîñòè ïðîåêòà
Хорошая команда разработчиков может создать выдающийся проект, несмотря на объективные трудности, ошибки администрации, неудачную конъюнктуру и т.д. Однако в мировой
практике не известны случаи, когда команда, составленная из
посредственных разработчиков, создавала действительно хороший проект.
В середине 1980-х годов в США и Австралии проводились эксперименты, целью которых было выявить факторы, влияющие на
производительность, и оценить различия в производительности
разработчиков программного обеспечения [23]. В эксперименте
участвовали несколько сотен программистских фирм, каждую из
которых представляли 2–3 разработчика. Всем участникам эксперимента выдавались задания, которые они выполняли на своих
рабочих местах, используя привычные языки программирования,
инструментарий и технические средства. Задания подбирались схожими по сложности и трудоемкости. Результаты и время выполнения заданий фиксировались экспериментаторами.
В ходе эксперимента выяснилось, что многие факторы, которые мы интуитивно включаем в список существенно влияющих на производительность, на самом деле влияют очень слабо.
Рассмотрим эти факторы.
1. Язык программирования. Эксперимент показал, что лучшим
языком для решения поставленной задачи является язык, кото!'
рый лучше знает разработчик, исключение составляет язык Ассемблер, требующий существенно больших затрат усилий по
сравнению с языками высокого уровня.
2. Стаж разработчиков. Если стаж более двух лет, то он практически не влияет на производительность. Другое дело – опыт:
сумма знаний, умений и навыков, приобретенных в прошлых
разработках. Но опыт зависит не столько от того, как долго человек работал, сколько от того, как он работал.
3. Качество выполнения заданий (количество недочетов). У
большинства разработчиков, быстро справившихся с заданием,
качество работы было выше, чем у отстающих. Это свидетельствует о том, что при правильной организации работы, качество
не приводит к ее удорожанию, а если работа организована неправильно, даже дополнительные затраты не смогут повысить
ее качество.
4. Уровень заработной платы. Это неожиданно, но производительность разработчика слабо коррелирует с уровнем его зарплаты. Лучшая половина разработчиков получала зарплату всего
на 10% выше, чем худшая, имея вдвое большую производительность.
Основными факторами, влияющими на производительность
работы фирмы, оказались: уровень зрелости фирмы, персональная производительность разработчиков и условия их работы. На
основании полученных данных была построена кривая распределения персональной производительности разработчиков (рис. 5.8).
На горизонтальной оси откладывалось время, потраченное на
выполнение задания, а по вертикали – количество разработчиков, выполнивших задание за указанное время.
Аналогичные кривые получались по результатам нескольких
лет наблюдений, проводимых разными экспериментаторами.
Лучшие разработчики имели производительность в 2,5 раз выше
средней и почти в 10 раз выше, чем аутсайдеры. При этом, если
разделить разработчиков на две группы: с производительностью
выше средней и ниже средней, то средняя производительность
первой группы в два раза превышает среднюю производительность второй группы.
Эксперимент выявил еще одну интересную закономерность:
высокую корреляцию производительности разработчиков одной
фирмы. Например, если у одного представителя фирмы дело не
"
Рис. 5.8. Вариации производительности разработчиков
программного обеспечения
ладилось, то с большой вероятностью и у другого представителя
той же фирмы дела также шли плохо. Кривая распределения
производительности по фирмам оказалась схожей с кривой индивидуальной производительности, изображенной на рис. 5.8.
Складывалось впечатление, что одни фирмы сумели собрать у
себя классных специалистов, а другие могли привлечь только
аутсайдеров.
Фирмы-лидеры, собравшие лучших разработчиков, приобретают огромное конкурентное преимущество, так как их издержки могут быть значительно ниже, чем у остальных фирм. А
фирмы-аутсайдеры попадают в порочный круг: из-за низкого
профессионального уровня и текучки персонала руководство
считает нецелесообразным вкладываться в кадры. Это приводит к еще большей текучке, при этом в первую очередь фирму
покидают наиболее перспективные сотрудники, которым легче
найти другую работу.
Если фирма действительно хочет стать лидером, она должна
разорвать этот круг, постоянно заботиться о формировании команды профессионалов, стремиться выпускать продукты, лучшие в своей области.
"
5.4.2. Îáåñïå÷åíèå óñëîâèé ðàáîòû
Для того чтобы человек хорошо работал, ему необходимо
создать нормальные условия работы. Особенно это важно для
людей творческого интеллектуального труда. В литературе по
психологии часто рассматривается пирамида потребностей человека, предложенная Маслоу (рис. 5.9).
Рис. 5.9. Пирамида Маслоу
Самая нижняя потребность, отраженная в пирамиде, – потребность в безопасности. Если человек не чувствует себя в безопасности, он вряд ли сможет продуктивно думать о чем либо
другом1. Удовлетворив потребность в безопасности, человек
может думать о физиологических потребностях своего организма:
пище, чистом воздухе и т.д. Справившись с потребностями своего
1
Сразу по окончанию Вьетнамской войны Российская Академия Наук
(РАН) решила помочь Вьетнаму в развитии национальной науки. Но все
усилия нашей стороны не давали желаемого результата. Тогда в Ханой была
направлена делегация РАН, чтобы разобраться на месте. Прибыв в Ханой,
они увидели город, сильно пострадавший от американских бомбардировок,
а вокруг города на полкилометра вырублены джунгли. «Зачем вы вырубили
такие красивые джунгли?», – спросили члены делегации. «Чтобы тигры не
ели детей. Во время войны в джунглях развелось много тигров, они беспрепятственно заходят на улицы города и нападают на детей». Было ясно, что в
таких условиях науку не возродить, и было принято решение пригласить
талантливую вьетнамскую молодежь учиться в Советский Союз.
"
существования, человек задумывается о своем месте в обществе,
ему нужно, чтобы его уважали, а с его мнением считались. От
«забитого» сотрудника вряд ли можно ожидать красивых и эффективных проектных решений. И только справившись со всеми нижними проблемами, человек может в полной мере проявить свой творческий потенциал, а заодно и удовлетворить свои
высшие потребности.
Отметим, что человек – существо очень сложное, умеющее
адаптироваться и преодолевать внешние условия. Например,
явным исключением из пирамиды Маслоу является самоотверженная работа в «шарагах», геройское поведение некоторых советских военнопленных, когда в нечеловеческих условиях люди
сохранили силу духа, находясь на высшей ступени пирамиды.
Однако это исключение только подтверждает правило, подчеркивая величие подвига таких людей.
Разработка программного обеспечения требует от человека
активности на высшей ступени пирамиды потребностей. Работодатель, желающий получить максимальную отдачу от сотрудников, должен помочь им удовлетворить все нижние потребности пирамиды с минимальными затратами драгоценных усилий
и времени сотрудников.
5.4.3. Ðàáîòà â ïîòîêå
Если у вас есть опыт программирования и вам это дело нравится, то наверняка вы знакомы с состоянием полной погруженности в работу: взявшись за работу в 9 ч. утра, мы с удивлением узнаем, что уже 12 ч. и пора делать перерыв. Именно в
таком состоянии работа идет потоком, поэтому создание и охрана этого состояния от внешних помех особенно важны для
повышения производительности и качества труда. Исследования показали, что даже небольшое отвлечение (например, вопрос коллеги) выхватывает человека из потока и, для того чтобы
вернуться назад, ему потребуется минимум 15 мин.
Наиболее опасными врагами потока являются шум, телефонные звонки и отвлечение от работы. Например, если вас отвлекают каждые 15 мин., то у вас просто не остается времени на
работу. Даже если вы считаете, что привыкли к шуму и не замечаете его, шум вам мешает. Санитарные исследования показали, что наличие постороннего шума снижает производительность
"!
умственной работы на 20– 80%. При этом снижение производительности не зависит от уровня звука: бормочущий радиоприемник так же вреден, как говорящий в полный голос.
Существует мнение, что приятная музыка может замаскировать шумы и способствовать работе. Для проверки этой гипотезы американские исследователи сформировали две группы разработчиков, в одной из которых собрали людей, считающих,
что музыка им мешает, а в другой – любящих работать под музыку. Половину каждой группы посадили в комнату, где играла
музыка, а половину– в тихую комнату. Каждому участнику эксперимента дали задание «с подвохом». Исходные данные требовалось 10 раз преобразовать и только потом использовать. При
внимательном изучении задания можно было понять, что длинная цепочка фактически является тождественным преобразованием и данные можно использовать сразу. Большая часть испытуемых из тех, кто сидел в тихой комнате, увидела подвох, а из
комнаты с музыкой, практически никто. Дело в том, что сосредоточенная творческая работа требует участия всего мозга и любое отвлечение снижает эффективность его работы.
5.4.4. Îðãàíèçàöèÿ ðàáî÷åãî ìåñòà
Нередко руководителю приходится слышать жалобы от сотрудников о том, что здесь им «не работается». И далеко не
всегда это каприз. Причиной могут быть слишком шумная или
тесная комната, неудобная мебель или неудачное ее расположение, вредная привычка коллег отвлекаться на пустую болтовню
и т.д.
Приведем несколько практических советов по организации
рабочего места.
1. Не собирайте людей в слишком большую и многолюдную
комнату. Чем больше людей в комнате, тем выше уровень шума.
Исследования американских менеджеров показали, что экономия на рабочих площадях фактически является растратой денег
из-за резкого снижения производительности труда сотрудников.
В России нормы площади и объема помещения определены в
специальном документе «Строительные Нормы и Правила»
(СНиП).
2. Не сажайте людей лицом к стенке. Во время работы глаза
программиста испытывают большую нагрузку. Чтобы снять на""
пряжение глаз, человек инстинктивно периодически отрывает
взгляд от монитора и смотрит вдаль. Если перед ним стена, находящаяся менее чем в 2,5 м, глаза не смогут адаптироваться «на
бесконечность» и отдохнуть.
3. Разрешите сотрудникам самим оборудовать и оформлять
свое рабочее место. У каждого человека с его рабочим местом
связано множество эмоций и воспоминаний, приятных и не
очень. Чтобы рабочее место было действительно его, оно должно
отражать индивидуальность сотрудника, быть привычным и удобным для него.
4. Позаботьтесь о корпоративной культуре. Люди, работающие вместе, достаточно быстро синхронизируют фазы своей деятельности. Они вместе «уходят в поток», вместе обсуждают ход
работы, вместе отдыхают. Это свойство должно стать основой
для формирования корпоративной культуры общения. Утренние, самые ценные часы должны отводиться для работы в потоке. Производственные совещания должны назначаться на время, удобное для большинства участников, приглашать на них
стоит только тех, кто действительно нужен для обсуждения.
Любителям поболтать должно быть неуютно, если они займутся
этим во время, отведенное для работы.
5.4.5. Ôîðìèðîâàíèå êîìàíäû
Команда – группа людей, преследующих одну цель, в которой авторитет каждого участника зависит от его вклада в
достижение общей цели.
Психологи, участвующие в подготовке первого отряда советских космонавтов, заметили интересную закономерность. После тяжелой тренировки будущие космонавты стремились быстрее принять душ. Зайдя в кабинку, каждый стремился быстрее
открыть горячую воду, а из крана текла холодная. Когда холодная вода стекала, всем сразу хотелось прикрыть горячую воду и
открыть холодную. Так как вода во все кабинки подавалась по
общим трубам, система входила в резонанс и во всех кабинках
то шпарил кипяток, то текла ледяная вода. Однако этот процесс
быстро устанавливался, если в группу входили определенные
люди. Психологи проследили за их поведением. Выяснилось,
что в отличие от остальных, они не спешили резко открывать и
"#
закрывать краны, а действовали так, чтобы вся система как можно
быстрее стабилизировалась. Именно эти люди обладали даром
лидерства.
Лидер – человек, который в данный момент лучше других понимает ситуацию и действует в интересах всей команды, иногда вопреки своим сиюминутным интересам.
Наличие лидеров в группе разработчиков существенно повышает шансы формирования эффективной команды. При этом
в хорошей команде никто не становится лидером навсегда, лидерство переходит от одного человека к другому в зависимости
от области специализации. Чтобы завоевать лидерство, каждый
участник команды должен продемонстрировать действительно
эффективные решения и преданность общему делу.
Факторы, способствующие формированию команды. Разработка программного обеспечения является специфическим видом
работ, успех и эффективность которых напрямую зависит от
чувства удовлетворения работой у большинства участников. В
связи с особой важностью проблемы формирования малых производственных коллективов в мире проводятся многочисленные
исследования в области психологии таких групп, но до сих пор
мы не знаем ни достаточных условий формирования эффективной команды, ни методики ее формирования. Однако некоторые рекомендации можно привести.
• Дайте людям возможность гордиться своей работой.
• Доверяйте своим сотрудникам как профессионалам. Если
сотрудник не внушает доверия, лучше расстаться с ним сразу,
чем перепроверять каждый его шаг.
• Позвольте сотрудникам самим определять уровень внутреннего качества их работы, оставив за собой формулировки и
контроль требований к внешнему качеству (опыт показывает,
что сам разработчик склонен устанавливать для себя максимально
высокий уровень).
• Распоряжения руководителя должны касаться только стратегических вопросов разработки. Если ему пришла в голову идея
конкретной реализации, он может предложить ее на рассмотрение команде наряду с другими идеями. И нет ничего страшного,
если команда отвергнет эту идею, ведь коллективный интеллект
хорошей команды мощнее интеллекта одного человека.
"$
• Устраивайте презентации и промежуточные финиши, которые позволяют сотрудникам чаще демонстрировать свои успехи коллегам, а заодно и обсуждать возникшие проблемы. У
всех членов команды должна сформироваться привычка добиваться успеха.
• Информируйте своих сотрудников о ходе реализации проекта, положении дел в фирме, на рынке и у конкурентов, привлекайте их к обсуждению стратегических проблем.
• Защищайте команду от внешних воздействий, не относящихся к проекту. Удел руководителя – расчищать административные завалы на пути своей команды.
• Избегайте одновременной работы над несколькими проектами. По-настоящему человек может принадлежать только одной
команде, а у команды должна быть одна, четко поставленная цель.
Факторы, препятствующие формированию команды. Несмотря на очевидную эффективность командной работы, немногие
руководители искренне желают иметь у себя настоящую команду.
Дело в том, что с точки зрения администрирования, команда –
очень неудобный объект. Авторитета команды хватает, чтобы
сказать «нет» нереальным срокам или невыполнимым требованиям. Команда не потерпит мелочного вмешательства и излишней регламентации ее работы. А если отношения между командой и администрацией испорчены окончательно, команда может
подать коллективное заявление об уходе и переметнуться к конкуренту, уводя с собой самых квалифицированных сотрудников. В связи с этим некоторые руководители интуитивно стремятся ограничить своеволие команды. Рассмотрим некоторые
из этих проявлений.
1. Излишняя регламентация работы. Как было показано выше,
разработка программного проекта требует особой культуры труда: следования принятым процессам разработки и стандартам,
ведения журналов самонаблюдений, регистрации и анализа ошибок и т.д. Если команда понимает смысл и необходимость этих
действий, она внедрит их в свою практику. Однако если те же
действия будут навязываться сверху, команда скорее всего отторгнет их или постарается довести до абсурда.
2. Географическое разделение. Членам команды нужно постоянное общение. Если затруднить возможность общения, эффективность работы команды снижается, а ее целостность ставится
под угрозу.
"%
3. «Племянники». Чем успешнее фирма, тем сильнее желание у «сильных мира сего» устроить туда своего родственника
или близкого знакомого. Само по себе появление нового сотрудника, явление нормальное, вне зависимости от того, кто его
рекомендовал. Однако у администрации возникает соблазн воспользоваться ситуацией. При этом новый сотрудник получает
незаслуженные привилегии, остальные участники команды начинают понимать, что успех зависит не от их компетенции,
а от «связей». Явная несправедливость разъедает дух команды,
и она распадается.
5.4.6. Èíâåñòèöèè â ÷åëîâåêà
В бухгалтерском учете принято различать два вида затрат:
издержки и инвестиции. Оплачивая счета за электричество, покупая бумагу, картриджи и другие расходные материалы, сотрудники фирмы понимают, что к концу проекта у них не будет
ни этих материалов, ни денег. Такие затраты называются издержками. Другое дело, приобретение компьютера или строительство нового здания: оно будет служить сотрудникам и после того,
как проект закончится. Затраты на подобные цели называются
инвестициями.
С ростом сложности и новизны продукции человеческий
фактор приобретает все большее значение. Чтобы повысить квалификацию своих сотрудников, фирма готова терпеть неудобства и затраты, связанные с их учебой, а иногда готова оплачивать учебу своих сотрудников. На эти жертвы руководство фирмы
идет отнюдь не из абстрактной любви к ближнему. Сотрудник,
получивший новые знания, скорее всего будет работать эффективнее, что сторицей оправдает затраты фирмы на его обучение.
Кроме того, сама возможность учиться и перспектива профессионального роста будет привлекать в фирму наиболее перспективных людей. В современном высокотехнологическом производстве грамотный человек становится специфическим средством
производства, а деньги, вложенные в его развитие,– инвестициями в человека.
Формы инвестиций в человека весьма разнообразны. Кроме
поощрения учебы, это могут быть:
• поддержка профессионального общения: семинаров, конференций и профессиональных конкурсов. Общаясь друг с дру"&
гом, специалисты обмениваются опытом, обсуждают общие проблемы, определяют свой профессиональный статус. Особенно
выгодно общение профессионалов для фирм-лидеров, так как
повышает их статус и позволяет подобрать для себя наиболее
перспективных сотрудников;
• улучшение условий труда и быта своих сотрудников. Избавившись от постоянных бытовых проблем (где поесть, как добраться до работы и т.д.) сотрудники смогут отдать больше сил
на решение профессиональных задач. При этом фирме зачастую
проще централизованно решить бытовые проблемы, чем каждому сотруднику заниматься ими самостоятельно.
Как и любые инвестиции, вложение в человека требует системного подхода и продуманности. Например, тратя деньги на
обучение, но не предоставляя своим сотрудникам приемлемой
оплаты и условий труда, фирма быстро становится «кузницей
кадров» для конкурентов.
Политика инвестиций в человека, проводимая фирмой, является хорошим индикатором состояния фирмы и истинных
целей ее руководства. Например, если фирма вкладывает мало
денег в свой коллектив, скорее всего она не заинтересована в
своем развитии. Обширные, но бессистемные вложения свидетельствуют или о непрофессиональности управления, или о том,
что истинные цели администрации далеки от создания сильной
и эффективной команды.
5.5. Óïðàâëåíèå êîíôèãóðàöèåé
5.5.1. Îñíîâíûå ïîíÿòèÿ
В русском языке термин «конфигурация» имеет много значений. В разных контекстах он может быть близок к терминам
«форма», «структура» или «архитектура». Как правило, он означает определенное взаимное расположение различных элементов, или компонентов.
В программной инженерии термин конфигурация означает совокупность всех компонентов проекта, таких, как документы, сопровождающие проект, исходные тексты программ,
структурные схемы, программные модули, планы и графики
работ, базы данных, библиотеки, файлы помощи, методики
и результаты тестирования, другие компоненты проекта.
"'
Состав элементов конфигурации (configuration items – CI)
существенно зависит от размеров проекта, стиля управления,
принятого в организации, и комплекта стандартов, которыми
руководствуются проектанты. В табл. 5.5 приведен примерный
перечень элементов конфигурации.
Т а б л и ц а 5.5
Элементы конфигурации программного проекта
Ýëåìåíò
Òåõíè÷åñêèå òðåáîâàíèÿ ê ïðîåêòó
Àðõèòåêòóðà
ïðîåêòà
Ïëàíû
Ñïåöèôèêàöèè
Âåðñèè ïðîãðàììíûõ ìîäóëåé
Îïèñàíèÿ âåðñèé
ìîäóëåé
Ìåòîäèêè
òåñòèðîâàíèÿ
Ðåçóëüòàòû
òåñòèðîâàíèÿ
Ìåòîäèêè
èíñïåêòèðîâàíèÿ
Ïëàíû
èíñïåêòèðîâàíèÿ
Ðåçóëüòàòû
èíñïåêòèðîâàíèÿ
Èíôîðìàöèîííûå
ðåñóðñû
Ãðàôè÷åñêèå
ìóëüòèìåäèéíûå
ðåñóðñû
Õàðàêòåðèñòèêà
Òðåáîâàíèÿ ê ïðîåêòó â öåëîì ìîãóò áûòü îôîðìëåíû â âèäå òåõíè÷åñêîãî çàäàíèÿ, äîãîâîðà è ò.ä.
Ìîäóëüíàÿ ñòðóêòóðà, ëîãèêà äàííûõ, ñõåìà ñòàòè÷åñêèõ è äèíàìè÷åñêèõ ñâÿçåé
Ïëàíû ðåàëèçàöèè ïðîåêòà è åãî ñîñòàâëÿþùèõ
Òðåáîâàíèÿ ê îòäåëüíûì ïðîãðàììíûì ìîäóëÿì.
Óêàçûâàåòñÿ: íàçíà÷åíèå, ñâîéñòâà è ìåòîäû, ñïîñîáû âûçîâà, ïåðåäàâàåìûå ïàðàìåòðû. Òðåáîâàíèÿ
ê ðåçóëüòàòó
Èñõîäíûé êîä âåðñèé, ñ óêàçàíèåì ñòåïåíè ãîòîâíîñòè ê êîìïèëÿöèè è ñáîðêå â ïðîãðàììíûé êî ìïëåêñ
Îïèñàíèå âíóòðåííåé ñòðóêòóðû, ïåðåìåííûõ è
àëãîðèòìîâ. Øàáëîíû, òèïîâûå ðåøåíèÿ, ïðèìåðû
èñïîëüçîâàíèÿ
Ìåòîäû òåñòèðîâàíèÿ è èñïûòàíèé, êîíòðîëüíûå
ïðèìåðû è ìàññèâû, òåñòèðóþùèå ïðîãðàììû
Ïðîòîêîëû òåñòèðîâàíèÿ è èñïûòàíèé, ðåçóëüòàòû
èõ àíàëèçà è îáîáùåíèÿ, âûâîäû
Öåëè è ìåñòî èíñïåêòèðîâàíèÿ, çàäà÷è, ìåòîäû è
ðîëè èíñïåêòîðîâ, òðåáîâàíèÿ ê ðåçóëüòàòó
Óêàçûâàåòñÿ îáúåêò èíñïåêòèðîâàíèÿ, ñîñòàâ, ðîëè
è ôóíêöèè èíñïåêòîðîâ
Âûÿâëåííûå îøèáêè è ïðîáëåìû, îáîáùåíèÿ è
ïðåäëîæåíèÿ
Óñëîâíî ïîñòîÿííàÿ èíôîðìàöèÿ, âêëþ÷àåìàÿ â
ïðîåêò, çàèìñòâîâàííàÿ èíôîðìàöèÿ è ò.ä.
Ðèñóíêè, çâóêè, âèäåî è ò.ä., âêëþ÷àåìûå â ïðîåêò,
çàèìñòâîâàííûå è ñîáñòâåííîãî èçãîòîâëåíèÿ. Äëÿ
çàèìñòâîâàííûõ ðåñóðñîâ óêàçûâàþòñÿ îñíîâàíèÿ
èõ èñïîëüçîâàíèÿ
Æóðíàë èçìåíåíèé Äîêóìåíò, ðåãèñòðèðóþùèé èçìåíåíèÿ, âíîñèìûå â
êîíôèãóðàöèþ
Ôàéëû ïîìîùè
Ôàéëû êîíòåêñòíîé ïîäñêàçêè, äåìîíñòðàöèîííûå
è ó÷åáíûå ïðèìåðû è ò.ä.
#
Продолжение
Ýëåìåíò
Ýêñïëóàòàöèîííàÿ
äîêóìåíòàöèÿ
Âåðñèÿ ïðîãðàììíîãî ïðîäóêòà
Èñïîëüçóåìîå
ïðîãðàììíîå
îáåñïå÷åíèå
Äîêóìåíòû
ðåãèñòðàöèè
Äîêóìåíòû
ñåðòèôèêàöèè
Õàðàêòåðèñòèêà
Èíñòðóêöèè ïî èíñòàëëÿöèè, ðóêîâîäñòâà ïîëüçîâàòåëÿ
Ñêîìïèëèðîâàííàÿ âåðñèÿ ïðîãðàììíîãî ïðîäóêòà,
ãîòîâàÿ ê êîìïëåêñíîìó èñïûòàíèþ èëè âíåäð åíèþ
Çàèìñòâîâàííûå ïðîãðàììû, ÿâëÿþùèåñÿ îáúåêòîì
èíòåëëåêòóàëüíîé ñîáñòâåííîñòè. Óêàçûâàþòñÿ îñíîâàíèÿ èõ èñïîëüçîâàíèÿ (íàïðèìåð, íîìåð ëèöåíçèè)
Êîìïëåêò äîêóìåíòîâ, íåîáõîäèìûõ äëÿ ðåãèñòðàöèè ïðîäóêòà êàê îáúåêòà èíòåëëåêòóàëüíîé ñîáñòâåííîñòè, ñâèäåòåëüñòâî î ðåãèñòðàöèè ïðîãðàììíîãî ïðîäóêòà
Êîìïëåêò äîêóìåíòîâ äëÿ ñåðòèôèêàöèè è ïîëó÷åííûå ñåðòèôèêàòû
Совокупность элементов с указанием взаимосвязей между
ними также является элементом конфигурации. Например, версия программного продукта – это совокупность версий модулей
и ресурсов, связанных между собой в соответствии с архитектурой проекта.
Все элементы конфигурации взаимосвязаны, влияют друг на
друга и естественно должны всегда быть согласованы между собой.
Управление конфигурацией – это поддержание всех элементов конфигурации в согласованном состоянии при внесении изменений в систему.
В любом проекте программная система в своем жизненном
цикле проходит через многие состояния, соответственно на протяжении жизненного цикла происходят изменения во всех элементах конфигурации.
До недавнего времени, пока в разработке использовалась в
основном каскадная модель, управление конфигурацией сводилось
к обеспечению статической согласованности всех компонентов
проекта. Требования к системе формировались на начальном
этапе, а затем жестко закреплялись. Все этапы разработки системы выполнялись строго последовательно, т.е. каждый разрабатываемый элемент конфигурации должен согласовываться с
уже созданными на предыдущих этапах. Каждый этап начинался только после завершения предыдущего этапа, результаты которого служили исходными данными для выполнения следую#
щего этапа. Компоненты проекта, разработанные на предыдущих этапах, не изменялись. При этом достаточно жестким было
требование согласованности всех документов, сопровождающих
ПС на протяжении всего жизненного цикла. Например, первичные требования, установленные во время изучения объекта
автоматизации, должны быть зафиксированы в виде отдельных
пунктов ТЗ. В свою очередь все пункты ТЗ должны найти отражение в проектной документации разрабатываемой системы, в планах
тестирования, в программе и методике испытаний. На заключительных этапах разработки эти же требования должны присутствовать в руководстве пользователя и описании программы.
Проблема согласования компонентов проекта внутри отдельного этапа не стояла так остро и решалась в ходе предварительного планирования работ, а также за счет следования определенным стандартам и прямого взаимодействия разработчиков
между собой в ходе выполнения работ на этапе.
Ситуация коренным образом изменилась и роль управления
конфигурацией резко возросла с внедрением в практику разработки ПС спиральных и, особенно, инкрементных моделей ЖЦ,
а также в связи со стремлением к параллельной разработке
программных систем. Оказалось, что очень сложно сохранять
целостность и согласованность всех компонентов проекта в том
случае, когда изменяются требования к уже готовой программной системе, или когда над одним и тем же компонентом параллельно работает большое количество исполнителей, а также,
если один и тот же компонент существует в нескольких рабочих
версиях. (Значимость данной проблемы хорошо иллюстрируется тем, что сегодня даже в такие универсальные программные
продукты, как Word и Excel, включаются средства управления
конфигурацией).
Особую важность управления конфигурацией можно проследить в следующих сценариях.
1. На заключительных этапах разработки разные группы разработчиков работают над разными функциональными модулями программной системы одновременно. Каждый программист
берет последние версии модулей, разработанных коллегами. При
этом появляется риск, что текущие изменения, внесенные в модуль другой группой разработчиков, не будут учтены.
2. В процессе внешнего тестирования в программной системе одновременно выявлено несколько ошибок. Исправление
#
каждой из них поручено отдельному разработчику. Все разработчики одновременно приступают к работе с одним и тем же
файлом с последней версией изменяемого программного модуля. Выполнив работу, каждый из разработчиков сохраняет исправленный файл на прежнем месте.
3. Программная система существует в нескольких рабочих
версиях, отличающихся функциональностью или интерфейсом
(используется инкрементная модель ЖЦ ПС). В процессе исправления ошибок, обнаруженных внешним тестированием,
разработчик локализовал и исправил их в одной из рабочих версий. Однако та же ошибка присутствует и в других рабочих версиях ПС.
4. Когда программная система почти готова, например, на
этапе бета-тестирования, обнаружено новое требование к системе, которое руководитель проекта решил в ней реализовать.
Для реализации данного требования необходимо включить его в
первичные требования, внести изменения в спецификацию программной системы, проектную и рабочую документацию, существующие модели системы, программный код, планы тестирования и т.д. Или, наоборот, оказалось необходимым отменить
уже сделанные изменения в готовой системе.
Если не применять специальных мер по согласованию действий всех разработчиков в подобных ситуациях, может оказаться,
что изменения, вносимые в систему одним разработчиком, уничтожают работу другого разработчика, а ошибки, исправленные в
одной версии программы, будут появляться в других версиях.
Таким образом, процесс управления конфигурацией необходим: он устанавливает такой порядок внесения изменений в
систему, когда все изменения согласованы между собой, все изменения регистрируются, у каждого изменения есть владелец
(автор), все изменения вносятся в последнюю версию программы и не уничтожают друг друга, все сделанные изменения и
различные версии ПС сохраняются в архиве. При этом система
управления конфигурацией должна позволять вносить изменения в систему даже при одновременной работе исполнителей
над одним компонентом.
Очевидно, что чем сложнее проект, тем сложнее управлять
его конфигурацией. По некоторым оценкам, управление конфигурацией сегодня – это основной ограничительный фактор
доступной сложности проектов.
#!
5.5.2. Ñðåäñòâà è ìåòîäû
óïðàâëåíèÿ êîíôèãóðàöèåé
Средства управления конфигурацией можно разделить на организационные и технические.
Организационные средства:
1. Определение конфигурационных элементов (объектов конфигурации) и классификация видов изменений.
2. Следование стандартам. Например, стандартные соглашения на именование файлов и четкая структура каталогов для их
хранения.
3. Контроль версий программных модулей.
4. Планирование работ по управлению конфигурацией.
5. Распределение обязанностей, ответственности, прав на
внесение изменений.
6. Установление процедур согласования вносимых изменений
и приоритета изменений. Например, исправление ошибок всегда
имеет приоритет перед другими изменениями в программах.
7. Регулярная сборка всей системы, например, ежедневная
(как в Microsoft).
Технические средства:
1. Разработка базы данных вносимых изменений.
2. Использование CASE-средств в разработке (репозитарии
объектов, общий доступ к компонентам и т.д.).
3. Использование специализированных технических средств
управления конфигурацией. К средствам такого типа в первую
очередь относятся средства управления версиями, в стандартный набор функций которых входит возможность создания разных версий одного документа с сохранением истории создания
и изменения всех версий, контроль авторства каждого изменения с возможностью разграничения и управления правами доступа разных пользователей, возможность сохранения пояснений
для каждого изменения. Наиболее известные программные продукты для управления версиями: CVS, Subversion, Microsoft Visual
SourceSafe, Rational ClearCase, Mercurial, Darcs.
4. Средства автоматизации сборки системы.
Мощным методом согласования усилий разработчиков и
получения продукта заданного качества является ведение документации. Разработчики договариваются об общих и взаимных
требованиях к разрабатываемым модулям и фиксируют догово#"
ренности в документации. В ходе разработки они придерживаются договоренностей, а если это невозможно, собираются вновь
и пересматривают ранние договоренности. При этом изменение
требований происходит с ведома всех заинтересованных участников, что гарантирует их согласованные действия. Для реализации этого метода документация проекта должна быть организована в систему и обладать следующими свойствами:
полнотой – в документации должны быть учтены все требования и договоренности к программному продукту и процессу
его разработки;
согласованностью – требования и договоренности должны
быть взаимно согласованы и не противоречить друг другу. Все
участники проекта должны принять требования, записанные в
документации1;
целостностью – изменения документации в ходе реализации
проекта не должны нарушать два предыдущих требования;
доступностью – документация со всеми изменениями, внесенными в нее на данный момент, должна быть доступна для
чтения каждому разработчику, который в ней нуждается.
Для обеспечения перечисленных выше требований используется система управления документацией.
В табл. 5.6 приведены перечни документов, составляющих
проектную документацию в соответствии с российскими стандартами Единой системы программной документации (ЕСПД)
и международными стандартами IEEE.
В ходе проектирования код программного продукта и проектная документация разрастаются по двум направлениям:
• «в п е р е д » (появляются новые программные модули, информационные и методические ресурсы, а также результаты тестирования, новые договоренности и т.д.);
• «в ш и р ь » (новые версии имеющихся модулей и ресурсов,
вспомогательные ресурсы, например, программы-заглушки при
восходящем проектировании, утилиты и т.д.).
Например, если программный модуль передается для изменения одному участнику, для остальных участников изменение
1
Было бы замечательно, если бы все договоренности достигались консенсусом. Однако в реальном проекте некоторые договоренности придется принимать волевым решением. Тем не менее все принятые решения
должны выполняться всеми участниками проекта.
##
Т а б л и ц а 5.6
Российские и международные стандарты,
устанавливающие требования к программной документации
Äîêóìåíòû
è ïðîöåññû
Íàçíà÷åíèå ÏÎ,
òðåáîâàíèÿ ê ÏÎ
Ðîññèéñêèå
ñòàíäàðòû
Òåõíè÷åñêîå çàäàíèå
ÃÎÑÒ 19.201-78
ÃÎÑÒ 34.602-84
Ïðîåêòíàÿ
äîêóìåíòàöèÿ
Îïèñàíèå ïðîãðàììû
ÃÎÑÒ 19.402-78
Ïîÿñíèòåëüíàÿ
çàïèñêà
ÃÎÑÒ 19.404-79
Óïðàâëåíèå
ïðîåêòîì
Óïðàâëåíèå
êîíôèãóðàöèåé
Êîä ïðîãðàììû
Âåðèôèêàöèÿ,
âàëèäàöèÿ,
òåñòèðîâàíèå
Òåêñò ïðîãðàììû
ÃÎÑÒ 19.401-78
Ïðîãðàììà
è ìåòîäèêà
èñïûòàíèé
ÃÎÑÒ 19.301-79
Êîíòðîëü êà÷åñòâà
Èñïîëüçîâàíèå
Îïèñàíèå
ïðèìåíåíèÿ
ÃÎÑÒ 19.502-78
Ñòàíäàðòû IEEE
Ñïåöèôèêàöèÿ òðåáîâàíèé ê
ïðîãðàììíîìó îáåñïå÷åíèþ:
SRS (Software Requirements
Specification)
Ïðîåêòíàÿ
äîêóìåíòàöèÿ
ïðîãðàììíîãî îáåñïå÷åíèÿ:
SDD (Software Design Document)
Ïëàí óïðàâëåíèÿ ïðîãðàììíûì ïðîåêòîì: SPMP (Software Project Management Plan)
Ïëàí óïðàâëåíèÿ êîíôèãóðàöèåé ïðîãðàììíîãî îáåñïå÷åíèÿ: SCMP (Software Configuration Management Plan)
Êîä
Ïëàí ýêñïåðòèçû ïðîãðàììíîãî
îáåñïå÷åíèÿ :
SVVP
(Software Verification and Validation Plan)
Äîêóìåíòàöèÿ ïî òåñòèðîâàíèþ ïðîãðàììíîãî îáåñïå÷åíèÿ: STD (Software Test
Documentation)
Ïëàí
êîíòðîëÿ
êà÷åñòâà
ïðîãðàììíîãî îáåñïå÷åíèÿ:
SQAP (Software Quality Assurance Plan)
Ðóêîâîäñòâî ïîëüçîâàòåëÿ
этого модуля должно быть заблокировано1. Чтобы вернуть измененный модуль в конфигурацию, участник должен оповес1
На практике часто один и тот же модуль одновременно меняют несколько человек. А потом идет процесс объединения сделанных изменений – code merge (существует много программ, помогающих это делать).
#$
тить об изменениях всех, кто этим модулем пользуется, а при
необходимости согласовать изменения с другими участниками.
Это позволяет избежать потери изменений, внесенных в предыдущую версию, повышает согласованность и ответственность
действий разработчиков.
Для возможности отката в предыдущее состояние старые версии не удаляются, а помечаются как неактуальные. Все изменения регистрируются в специальном журнале. Указывается дата
(время) и автор изменений. При необходимости добавляется комментарий. В случае появления несоответствия журнал позволяет выявить его причины и разработать меры по их устранению.
Так как все элементы конфигурации CI являются элементами системы, они должны быть снабжены характеристиками,
позволяющими однозначно идентифицировать их и определить
место каждого CI в системе. Средства идентификации и формат
характеристик зависят от стандартов, методов и программных
средств, применяемых в организации. Например, идентификация программного модуля может осуществляться за счет написания специальной «шапки» комментариев, в которой указываются: уникальное название модуля, номер версии, дата и время
создания, старший модуль или подсистема, которой принадлежит данный модуль и автор1. Для лучшего понимания работы
модуля в комментарии могут быть добавлены описание назначения модуля, его свойств и смысл переменных.
Другой стиль описания: в модуле оставляется только идентифицирующие характеристики, а все остальное переносится в
специальный документ «Описание варианта программного модуля». Таким образом, пара CI: «описание…» и «код…» рассматривается как единый элемент конфигурации.
Чтобы иметь возможность оценить состояние разработки и
по ошибке не включить в сборку неготовый элемент, каждый CI
должен иметь характеристику, отражающую степень его завершенности. Например, для программного модуля эта характеристика может принимать значения: «в стадии разработки»; «готов
к локальному тестированию»; «прошел локальное тестирование»;
«готов для сборки» (т.е. автор считает, что его модуль можно
включать в сборку более крупного модуля или новой версии
программного продукта).
1
В современных средствах разработки, например в системе Microsoft.
NET, каждый программный модуль предваряется так называемым манифестом, где содержится указанная выше информация.
#%
При формировании новой версии программного продукта
должны учитываться версии его модулей. Новая версия считается актуальной только после прохождения ею всех запланированных процедур верификации, тестирования и согласования.
До этого момента актуальной считается предыдущая версия.
Далеко не все CI попадут в окончательную версию программного продукта. Часть из них будет признана устаревшей после
разработки новых версий; часть, имеющая вспомогательные
функции (например, утилиты, программы-«заглушки», тестирующие программы и т.д.), могут использоваться только во время
разработки. Однако не стоит торопиться удалять все эти элементы после завершения проекта. Многие из них могут пригодиться при разработке новых версий этого проекта или новых
проектов. Это так называемое имущество проекта.
Чтобы обеспечить правильность управления конфигурацией, выполнение всех перечисленных выше требований и процедур, еще до начала реализации проекта (т.е. до появления его
конфигурации) следует разработать документ: «План управления конфигурацией» (Software Configuration Management Plan
(SCMP)) и включить в него все требования и процедуры, технические средства поддержки управления конфигурацией (депозитарии, средства управления версиями, средства автоматизации сборки программных комплексов).
5.5.3. Ýëåêòðîííàÿ äîêóìåíòàöèÿ
В современных технологиях проектирования происходит
постепенное сращивание программного кода и программной
документации. Необходимость в любой момент разработки иметь
полную и непротиворечивую конфигурацию делает требования
к управлению конфигурацией схожими со стандартными требованиями к современным информационным системам. Например, чтобы снизить трудоемкость согласования требований и
риск чего-нибудь забыть в этом кропотливом процессе, желательно вносить изменения только один раз и обеспечивать возможность системе управления автоматически учитывать эти изменения во всех CI, которых они касаются.
Если вся документация ведется в электронном виде, для решения этой проблемы можно использовать гиперссылки. Например, назначение модуля, смысл переменной или свойство ресур#&
са описывается только один раз, а во всех документах, где эти
объекты упоминаются, ставят гиперссылки на исходный документ.
Еще более мощным средством обеспечения целостности требований является расширяемый язык разметки XML. Язык позволяет создавать и описывать собственную систему тегов, отражающих объекты и свойства предметной области. При этом может
учитываться иерархия и вложенность понятий. Разметив с помощью таких тегов проектную документацию (т.е. создав XML-документ), можно автоматизировать многие операции, обеспечивающие целостность документации и согласованность требований.
5.6. Ýâîëþöèîííàÿ ìîäåëü çðåëîñòè ôèðìû
Практика работы фирм, занимающихся разработкой программного обеспечения, изобилует случаями, когда внедрение
новых, хорошо продуманных методов управления приносит не
пользу, а вред. Аналогичные проблемы возникают и у покупателей (заказчиков программного обеспечения).
Дело в том, что фирма должна дорасти (созреть) до применения современных методов. Уровень зрелости фирмы определяется множеством плохо формализуемых факторов. К ним относятся: компетентность руководства и его желание создать
действительно эффективное предприятие, сложившаяся система
отношений и практика взаимодействия сотрудников между собой, опыт сотрудников, их мотивация, культура общения и т.д.
Анализируя причины побед и неудач множества программных проектов, практичные американцы разработали эволюционную модель зрелости, учитывающую уровень зрелости фирмыразработчика и позволяющую оценить полезность внедрения
новых процессов управления. Модель, получившая название
«модель развития возможностей по мере зрелости фирмы»
(Capability Maturity Model (CMM)), стала использоваться для
решения задачи организации работ по развитию ПО с начала
90-х годов XX в. в США, а затем и во всем мире1.
1
Разработку CMM курирует институт программной инженерии США
(SEI). К работе привлечены специалисты промышленности, правительственных органов и разработчики ПО. К настоящему времени разработано несколько моделей: SW-CMM (Software СММ) – использование СММ при разработке программного обеспечения; SA-CMM (Software Acquisition СММ) –
использование СММ при приобретении программного обеспечения; CMMI –
интегрированная модель зрелости.
#'
В основу модели положены представления об эволюционном
характере развития системы управления программисткой фирмы. В модели выделяются пять уровней зрелости. Предприятие
должно дорасти (дозреть) до внедрения эффективных методов
управления. Внедрение все более сложных и точных методов возможно по мере созревания предприятия. Для каждого уровня
указываются критерии его достижения, методы управления, адекватные этому уровню, и цели, которые предприятие должно достичь, чтобы перейти на следующий уровень зрелости.
Использование модели CMM позволяет поставить разработку ПО на промышленную основу, повысить производственную
культуру, гарантировать качественную работу и исполнение проектов точно в срок. Фактически СММ задает генеральную линию развития предприятия, стремящегося достичь лидирующих
позиций на рынке программного обеспечения. Классификация, включенная в модель, позволяет потенциальным заказчикам оценить возможности фирмы-исполнителя и тем самым
снизить риск провала проекта.
5.6.1. Óðîâíè ÑÌÌ
На рис. 5.10 представлено соотношение уровней зрелости
программистской организации. Каждый верхний уровень характеризуется повышением полноты, точности и достоверности
оценок, используемых при планировании и управлении. Методы
и цели различных уровней эволюционно связаны. Например, внедряемые на первом уровне учет и контроль используются на
более высоких уровнях для планирования, управления и оптимизации процессов разработки. Ниже приведены описания каждого
уровня, выделены ключевые проблемы и цели, которые предприятие должно поставить для перехода на высший уровень.
1. Начальный уровень (Хаос) – «самоорганизующийся хаос».
Каждый новый проект начинается с «белого листа», так как регулярные процессы разработки пока отсутствуют. Успешность
и качество проекта напрямую зависят от способностей и опыта
отдельных сотрудников. Стоимость разработки проекта высока,
результат непредсказуем (вслед за удачной разработкой может
произойти провал аналогичного по сложности проекта). Основные цели развития – организация первичного учета и контроля
производственной деятельности, воспитание самодисциплины
исполнителей.
$
Рис. 5.10. Этапы зрелости предприятия
2. Контроль (Обеспечение повторяемости). Предприятию удалось наладить учет и контроль производственной деятельности.
На базе объективной информации о реальных сроках и затратах
на разработку осуществляется планирование и, как следствие,
балансировка основных целей. При выходе на второй уровень
деятельность предприятия становится прозрачной, возможно
повторение ранее достигнутых успехов, результат становится
предсказуемым. Качество проекта все еще зависит от способностей отдельных личностей. Основное внимание на данном уровне
уделяется совершенствованию и систематизации процессов управления.
3. Начало оптимизации (Определенность). Управляющие и
прикладные действия по разработке ПО документированы, стандартизованы и объединены в общий для всех проектов процесс
разработки. Использование стандартных процессов позволяет
достаточно точно оценить и спланировать затраты времени и
ресурсов на создание проекта. У предприятия появляется возможность гарантировать время, стоимость и качество своей продукции. Управление проектом становится эффективным, что дает
возможность предотвратить большинство нежелательных ситуаций еще до их появления. Проводится интегрированное управление рисками. Основное внимание уделяется прикладным
процессам и организационной поддержке. Предприятие заботится о росте квалификации своих кадров, для снижения рисков, связанных с уходом отдельных разработчиков, создается
«инкубатор лидеров». За счет оптимизации (упрощения) бизнес-процессов предприятие снижает свои издержки и риски.
$
4. Управляемость (Количественные модели). Собраны подробные данные о процессах разработки программных проектов
и компонентах продукции. Все процессы и компоненты продукции количественно оцениваются и контролируются. Использование достаточно надежных количественных моделей позволяет предприятию рассматривать множество альтернативных
вариантов развития и адаптировать свои бизнес-процессы к изменяющимся условиям внешней рыночной среды. Основное внимание на данном уровне уделяется качеству продукции и процессов работы.
5. Высокая оптимизация (Непрерывное совершенствование).
За счет непрерывного улучшения своих бизнес-процессов
(Business Processes Improvement–BPI) предприятие обеспечивает себе положение лидера на рынке программной продукции.
Постоянный анализ рынка, тесное взаимодействие с существующими и потенциальными пользователями дают возможность
предприятию предсказывать и формировать будущий спрос на
свою продукцию.
Например, рассмотрим эволюцию взаимодействия заказчика и разработчика при формировании требований к программному проекту в зависимости от зрелости организации. Ниже приведены качественная шкала оценок этого взаимодействия (в
столбце справа дана количественная оценка зрелости – 5-й уровень) и аналогичная шкала оценок по другой характеристике –
качеству планирования на различных уровнях зрелости.
0.
1.
2.
3.
4.
5.
$
Êà÷åñòâåííàÿ õàðàêòåðèñòèêà óðîâíÿ çðåëîñòè
Òðåáîâàíèÿ çàêàç÷èêà ôîðìóëèðóþòñÿ è ïðèíèìàþòñÿ â
óñòíîé ôîðìå è çàòåì íèãäå íå ôèêñèðóþòñÿ
Òðåáîâàíèÿ çàêàç÷èêà ôèêñèðóþòñÿ â ðàçðîçíåííûõ äîêóìåíòàõ; âçàèìíîå âëèÿíèå òðåáîâàíèé è èõ èñïîëíåíèå íå
ïðîñëåæèâàþòñÿ
Âåäåòñÿ äèñïåò÷åðèçàöèÿ çàÿâîê çàêàç÷èêà, ñòàäèé èõ èñïîëíåíèÿ, óðîâåíü óäîâëåòâîðåííîñòè çàêàç÷èêà
Òåñíàÿ êîîðäèíàöèÿ ðàáîòû ñ çàêàç÷èêîì, çàêàç÷èê âîâëåêàåòñÿ â ïðîöåññ ðàçðàáîòêè ïðîåêòà
Íàêàïëèâàþòñÿ ôîðìàëèçîâàííûå çíàíèÿ (ìåòðèêè) ïî
óäîâëåòâîðåííîñòè çàêàç÷èêà (äëÿ ïëàíèðîâàíèÿ ïðèîðèòåòîâ)
Âíåäðÿåòñÿ ñèñòåìà óïðàâëåíèÿ çàÿâêàìè, ïîçâîëÿþùàÿ
çàêàç÷èêó êîíôèãóðèðîâàòü çàÿâêè íà ÏÎ ñ ó÷åòîì áóäóùèõ
ïîòðåáíîñòåé.
%
0
20
40
60
80
100
Êà÷åñòâî ïëàíèðîâàíèÿ íà ðàçëè÷íûõ óðîâíÿõ çðåëîñòè
Ïëàíèðîâàíèÿ íåò, åñòü àâðàëüíîå ðåàãèðîâàíèå íà âíåøíèå ñîáûòèÿ
 íàëè÷èè ïåðâûé óðîâåíü ïëàíèðîâàíèÿ (íà áàçå áþäæåòèðîâàíèÿ)
Íàðÿäó ñ ïåðâûì óðîâíåì ââîäèòñÿ òðåòèé óðîâåíü ïëàíèðîâàíèÿ, âòîðîé óðîâåíü ïëàíèðîâàíèÿ ôîðìàëüíûé
 ïëàíèðîâàíèè ðàáîò ó÷àñòâóþò âñå
0.
1.
2.
3.
%
0
20
40
100
5.6.2. Èñïîëüçîâàíèå ìîäåëè CMM
Модель CMM содержит классификацию уровней зрелости и
адекватные методы для каждого уровня, определяет цели, задачи и критерии достижения каждого уровня. В связи с этим документы CMM служат хорошей нормативной базой развития
фирм, специализирующихся на разработке и использовании программного обеспечения.
Существует сильная корреляция между уровнями зрелости
разработчика и его техническими решениями: качеством и надежностью программного обеспечения, полнотой и адекватностью его функциональности, удобством использования и т.д. Из
этого можно сделать один практический вывод: зрелость продавца должна соответствовать зрелости покупателя. Действительно, если фирма-покупатель сама находится на низком уровне
СММ, она может позволить себе приобрести ПО у низкоуровневого производителя. При этом возможные ошибки технических решений скажутся не так сильно. С повышением собственного уровня зрелости риск покупателя приобрести «не то»
становится неоправданно высоким.
Для оценки уровня зрелости фирмы в соответствии с моделью CMM был разработан стандарт ISO 15504. По аналогии с
ИСО 9000 данный стандарт может использоваться для сертификации систем управления качеством фирм-разработчиков. В настоящее время практика подобной сертификации широко распространена преимущественно на американском рынке
программного обеспечения1.
1
Сайт: QUALITY Менеджмент качества и ISO 9000 (quality.eup.ru).
$!
В отличие от универсальных требований ИСО 9000, сертификация на основе CMM ориентирована на специфику индустрии программного обеспечения. Начиная с третьего уровня зрелости, требования CMM становятся более жесткими, чем
требования ИСО, поэтому, выбирая схему сертификации, руководство фирмы должно ясно представлять, с какой целью проводится сертификация. Если цель – подтвердить готовность
фирмы выпускать продукцию объявленного уровня качества (что
требуется для выхода фирмы на международный рынок), то предпочтительней сертификация на соответствие ИСО 9000. Если
же целью является подтверждение лидерства фирмы на своем
сегменте рынка ПО (что очень желательно для существования
на высоко конкурентном американском рынке ПО), следует сертифицироваться на соответствие высшим уровням CMM1.
Возможность применения различных схем сертификации
является ярким, но далеко не единственным примером множественности способов применения стандартов. На рис. 5.11 приведены основные группы стандартов, используемых при разработке и сертификации программного продукта.
Рис. 5.11. Стандарты, используемые при разработке и сертификации
программного продукта
1
Липаев В.В, Модели зрелости программной инженерии CMMI –
Содержание и применение. Информационный бюллетень Jet Info №6 (157)/
2006.
$"
Например, систему характеристик качества программы принято выбирать на основе ГОСТ Р ИСО 9126 (см. гл. 1), однако
можно применять и альтернативные стандарты ИСО. Модели
жизненного цикла (см. гл. 2) регламентируются стандартами ISO
12207 и ISO 15288. Требования к программной документации
определяются отечественными системами стандартов ГОСТ 19
(ЕСПД) и ГОСТ 34. (КСАС) или соответствующими стандартами ИСО. Специальные вопросы стандартизации, связанные с
безопасностью и надежностью программных средств, интерфейсами открытых систем и т.д., регламентируются соответствующими системами стандартов.
Контрольные вопросы
1. Перечислите этапы формирования представлений о качестве и методах управления качеством. Какие идеи, принципы и
методы управления качеством появлялись на каждом этапе?
2. Требования к чему содержатся в стандартах серии ИСО
9000?
3. Укажите различия между концепциями качества, на которых базируются стандарты серии ИСО 9000 и TQM.
4. Что такое риск? Охарактеризуйте риски, с которыми связана реализация программного проекта.
5. Что такое разделение ответственности? Какими принципами следует руководствоваться при распределении ответственности между партнерами?
6. Какие факторы следует учитывать при количественной
оценке риска превышения сроков и стоимости проекта?
7. Как оцениваются дополнительные временные ресурсы,
необходимые для снижения рисков до приемлемого уровня?
8. Перечислите потребности человека, указанные в пирамиде Маслоу. На каком уровне пирамиды находятся потребности,
влияющие на качество интеллектуального труда?
9. Многие программисты считают, что посторонние шумы и
музыка не влияют на их работоспособность. Так ли это?
10. Перечислите основные санитарно-гигиенические требования, предъявляемые к рабочему месту программиста.
11. Что такое команда разработчиков? Какими свойствами
должен обладать лидер команды?
$#
12. Перечислите факторы, способствующие и препятствующие формированию команды.
13. Что такое конфигурация программного проекта? Перечислите основные элементы конфигурации.
14. Чем вызвана необходимость управления конфигурацией
в ходе реализации программного проекта? Какие методы и программные инструменты используются для этого?
15. Опишите уровни зрелости предприятий согласно модели
СММ. Как знание уровня зрелости может помочь при покупке
готового программного проекта или выборе разработчика программного проекта?
16. В чем схожесть и в чем отличия сертификации предприятия на соответствие требованиям стандартов ИСО 9000 и требованиям СММ? Чем отличаются цели этих сертификаций?
17. Перечислите группы стандартов, используемые при разработке и сертификации программных продуктов. Укажите цели
и задачи, для решения которых используется каждая группа.
18. Можно ли применять стандарты из различных систем
для одного программного проекта?
19. В чем заключается руководство программным проектом?
Перечислите основные задачи, которые должен решать руководитель проекта.
20. Какими проблемами занимается новая наука – программная инженерия?
$$
ÏÐÈËÎÆÅÍÈÅ
Ïðèìåðû çàäàíèé äëÿ ïðàêòè÷åñêèõ çàíÿòèé
Задание 1
Проанализируйте приведенные ниже требования заказчика и
сформулируйте систему требований к программе «Налоговый калькулятор».
Требования
заказчика к программе
«Налоговый калькулятор»
1. Программа предназначена для расчета величины налога на
доходы физических лиц (НДФЛ) за 1 месяц. Программа должна
работать в операционной системе Windows XP, как автономный
модуль, не требующий инсталляции и установки дополнительных
библиотек.
2. Входной информацией для программы являются следующие
величины:
• доход физического лица за 1 месяц (Д), с которого надо удержать подоходный налог;
• доход физического лица, уже полученный им с начала года до
месяца, для которого производится расчет (ДСУММ);
• количество детей до 18 лет, имеющихся на иждивении у физического лица (ДЕТИ);
• сведения о том, является ли семья физического лица полной.
3. Алгоритм расчета налога следующий:
Если доход, полученный с начала года, не превышает сумму
в 40000 руб., то величина налога составляет 13% от величины дохода за месяц, уменьшенного на величину налоговых вычетов
(ВЫЧ):
НАЛОГ = 0,13 ⋅ (Д – ВЫЧ).
Налоговые вычеты равны:
• для физического лица, не имеющего детей младше 18 лет, –
600 руб.
$%
• для физического лица, имеющего детей младше 18 лет, в случае, если семья является полной, – 600 руб. плюс 600 руб. на каждого имеющегося ребенка:
ВЫЧ = 600 + 600 ⋅ ДЕТИ [руб.]
• для физического лица, имеющего детей младше 18 лет, в случае, если семья является неполной, – 600 руб. плюс 1200 руб. на
каждого имеющегося ребенка:
ВЫЧ = 600 + 1200 ⋅ ДЕТИ [руб.].
Если сумма вычетов превышает месячный доход, то налог равен нулю.
Если доход, полученный с начала года, превышает 40000 руб.,
то налоговые вычеты не предоставляются и величина налога составляет 13% от величины дохода за месяц:
НАЛОГ = 0,13 ⋅ Д.
4. Входные данные должны вводиться в программу с помощью
стандартных элементов управления со стандартными возможностями редактирования вводимой информации. Элементы управления
должны иметь защиту от неправильного ввода данных, не позволяя
вводить не числовые величины в текстовые поля. Разделителем десятичной части должна быть точка.
5. Поле для ввода дохода физического лица за 1 месяц должно
позволять вводить максимальную сумму до 999999999 руб. 99 коп.
6. Выходными данными программы являются две величины –
рассчитанная сумма подоходного налога в рублях и сумма чистого
дохода за месяц в рублях, которая равна разнице дохода за месяц и
подоходного налога.
7. Каждая из выходных величин должна быть представлена в
двух форматах – в виде числа и в виде суммы прописью. При выводе суммы прописью все числительные и обозначения денежных
единиц должны быть в нужных падежах.
Задание 2
Выберите модель жизненного цикла и адаптируйте стандартный процесс разработки для программы «Налоговый калькулятор».
На их основе разработайте календарный график реализации программы.
$&
В качестве типовых этапов реализации можно использовать этапы: «Разработка технического задания», «Программная реализация»,
«Тестирование», «Регистрация программы» и «Защита проекта».
Для оценки трудоемкости этапа «Программная реализация» используйте ваш опыт и метод функциональных точек. Оценку этапов, не связанных с программированием, дайте на основании средней доли этих этапов в общей трудоемкости разработки.
При построении календарного графика можно использовать
любую доступную программу-планировщик.
Скорректируйте план, исключив случаи сверхурочной работы.
Добейтесь максимально возможной равномерности загрузки исполнителей.
Определите сроки реализации проекта и общую трудоемкость
проекта.
Сформируйте отчеты: «Общие сведения о проекте», «Календарный план» и «График загрузки исполнителей».
Задание 3
Составьте техническое задание на разработку программы «Налоговый калькулятор». Техническое задание должно соответствовать требованиям ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».
Ниже приведены основные требования ГОСТ 19.201. к техническому заданию и комментарии по применению этих требований
(выделены курсивом).
1. Общие положения
1.1. Техническое задание оформляют в соответствии с ГОСТ
19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.
1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
1.3. Техническое задание должно содержать следующие разделы:
• введение;
• основания для разработки;
• назначение разработки;
• требования к программе или программному изделию;
• требования к программной документации;
• технико-экономические показатели;
• стадии и этапы разработки;
$'
• порядок контроля и приемки;
• в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного
изделия допускается уточнять содержание разделов, вводить новые
разделы или объединять отдельные из них.
2. Содержание разделов
2.1. В разделе «Введение» указывают наименование, краткую
характеристику области применения программы или программного
изделия и объекта, в котором используют программу или программное изделие.
Область применения – вид деятельности, в котором планируется применять программу. Например, налоговый калькулятор предназначен для организации консультаций граждан налоговыми органами. Назначение введения – дать читателю представление о
документе, достаточное, чтобы он понял, стоит ли читать документ дальше.
2.2. В разделе «Основания для разработки» должны быть указаны:
• документ (документы), на основании которого ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.
В нашем случае основание разработки – учебный план и задание
преподавателя.
2.3. В разделе «Назначение разработки» должно быть указано
функциональное и эксплуатационное назначение программы или
программного изделия.
Функциональное назначение программы – функции, для выполнения которых она используется. Например, налоговый калькулятор предназначен для расчета налога.
Эксплуатационное назначение – процесс, в котором планируется
использовать программы. Например, налоговый калькулятор предназначен для организации консультации граждан по вопросам налогового
законодательства.
2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
• требования к функциональным характеристикам;
• требования к надежности;
%
• условия эксплуатации;
• требования к составу и параметрам технических средств;
• требования к информационной и программной совместимости;
• требования к маркировке и упаковке;
• требования к транспортированию и хранению;
• специальные требования.
2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых
функций, организации входных и выходных данных, временным
характеристикам и т.п.
2.4.2. В подразделе «Требования к надежности» должны быть
указаны требования к обеспечению надежного функционирования
(обеспечения устойчивого функционирования, контроль входной
и выходной информации, время восстановления после отказа и т.п.).
При формировании требований к надежности следует уточнить
понятие «надежность» применительно к данному случаю. Например,
надежность налогового калькулятора – соответствие результатов
расчета действующему законодательству.
2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха,
относительная влажность и т.п. для выбранных типов носителей
данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и
квалификация персонала.
В нашем случае, условия эксплуатации – типовые условия офиса.
Вид обслуживания – должность и квалификация сотрудника, обслуживающего программу.
2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств
с указанием их основных технических характеристик.
Каждое требование технического задания должно проверяться,
поэтому не следует формулировать неоправданно широкие требования. Например, требование «Программа должна работать на любом
компьютере» никогда не может быть выполнено. Более правильно
указывать требования к составу и параметрам технических средств,
на которых планируется эксплуатация программы.
2.4.5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения,
исходным кодам, языкам программирования и программным средствам, используемым программой.
%
При необходимости должна обеспечиваться защита информации и программ.
Если ваша программа взаимодействует с другими программами и
устройствами, то она, во-первых, не должна мешать их работе, а
во-вторых, правильно работать совместно с указанными программами и устройствами. Нередко для расширения области применения программы вместо конкретных программ и устройств указываются стандарты на интерфейсы, обеспечивающие совместимость со всеми
устройствами, поддерживающими данные стандарты.
2.4.6. В подразделе «Требования к маркировке и упаковке» в
общем случае указывают требования к маркировке программного
изделия, варианты и способы упаковки.
В соответствии с Законом РФ «О защите прав потребителя» на
упаковке программы должны помещаться: название программы, реквизиты изготовителя и вся информация о программе, необходимая
покупателю. Кроме того, на упаковке принято размещать краткую
инструкцию по установке и использованию программы.
2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия
транспортирования, места хранения, условия хранения, условия
складирования, сроки хранения в различных условиях.
В нашем случае требования к транспортировке и хранению можно опустить.
2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.
При определении перечня программных документов удобно придерживаться какой-либо системы стандартов. Например, в стандарте
ЕСПД ГОСТ 19.101-77 приведен следующий перечень документов.
Âèä ïðîãðàììíîãî
äîêóìåíòà
Ñïåöèôèêàöèÿ
Âåäîìîñòü äåðæàòåëåé
ïîäëèííèêîâ
Òåêñò ïðîãðàììû
Îïèñàíèå ïðîãðàììû
Ïðîãðàììà è ìåòîäèêà
èñïûòàíèé
%
Ñîäåðæàíèå ïðîãðàììíîãî äîêóìåíòà
Ñîñòàâ ïðîãðàììû è äîêóìåíòàöèè íà íåå
Ïåðå÷åíü ïðåäïðèÿòèé, íà êîòîðûõ õðàíÿò
ïîäëèííèêè ïðîãðàììíûõ äîêóìåíòîâ
Çàïèñü ïðîãðàììû ñ íåîáõîäèìûìè êîììåíòàðèÿìè
Ñâåäåíèÿ î ëîãè÷åñêîé ñòðóêòóðå è ôóíêöèîíèðîâàíèè ïðîãðàììû
Òðåáîâàíèÿ, ïîäëåæàùèå ïðîâåðêå ïðè èñïûòàíèè ïðîãðàììû, à òàêæå ïîðÿäîê è ìåòîäû
èõ êîíòðîëÿ
Продолжение
Âèä ïðîãðàììíîãî
äîêóìåíòà
Òåõíè÷åñêîå çàäàíèå
Ïîÿñíèòåëüíàÿ çàïèñêà
Ýêñïëóàòàöèîííûå
äîêóìåíòû
Ñîäåðæàíèå ïðîãðàììíîãî äîêóìåíòà
Íàçíà÷åíèå è îáëàñòü ïðèìåíåíèÿ ïðîãðàììû, òåõíè÷åñêèå, òåõíèêî-ýêîíîìè÷åñêèå è
ñïåöèàëüíûå òðåáîâàíèÿ, ïðåäúÿâëÿåìûå ê
ïðîãðàììå, íåîáõîäèìûå ñòàäèè è ñðîêè ðàçðàáîòêè, âèäû èñïûòàíèé
Ñõåìà àëãîðèòìà, îáùåå îïèñàíèå àëãîðèòìà
è (èëè) ôóíêöèîíèðîâàíèÿ ïðîãðàììû, à
òàêæå îáîñíîâàíèå ïðèíÿòûõ òåõíè÷åñêèõ è
òåõíèêî-ýêîíîìè÷åñêèõ ðåøåíèé
Ñâåäåíèÿ äëÿ îáåñïå÷åíèÿ ôóíêöèîíèðîâàíèÿ è ýêñïëóàòàöèè ïðîãðàììû
В зависимости от сложности и содержания задачи часть документов может не разрабатываться. Например, если испытание программы не требует специальной методики, документ «Программа и
методика испытаний» можно не разрабатывать, а требования к испытаниям внести в раздел «Порядок контроля и приемки» технического задания.
2.5. В разделе «Технико-экономические показатели» должны
быть указаны: ориентировочная экономическая эффективность,
предполагаемая годовая потребность, экономические преимущества
разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
Для формирования оценки экономической эффективности ответьте
на следующие вопросы:
• Для чего предназначена наша программа, какие задачи она решает?
• Что, какое предприятие является объектом внедрения?
• Какие проблемы предприятия призвана решать наша программа?
• Готово ли предприятие к внедрению программы, какие мероприятия следует провести для обеспечения эффективности использования программы?
• Какие положительные изменения в работе предприятия ожидаются в связи с внедрением программы?
Приведите характеристики программ-аналогов (отечественных и
зарубежных), решающих схожие задачи. В чем преимущества вашей
программы?
2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (пере-
%!
чень программных документов, которые должны быть разработаны, согласованы и утверждены), а также сроки разработки.
Данный раздел удобно оформить в виде таблицы:
¹
Ýòàï ðàáîòû
ï/ï
Ñðîêè èñïîëíåíèÿ
íà÷àëî
çàâåðøåíèå
Îòâåòñòâåííûé
èñïîëíèòåëü
2.7. В разделе «Порядок контроля и приемки» должны быть
указаны виды испытаний и общие требования к приемке работы.
Типовая процедура контроля и приемки выглядит так: создается
комиссия из представителей заказчика и разработчика, которая на
основании результатов испытаний принимает решение о готовности
программы. Если в разделе «Требования к программной документации»
указана разработка «Программы и методики испытаний», в данном
разделе достаточно указать “Испытания проводятся в соответствии
с требованиями «Программы и методики испытаний»”.
2.8. В приложениях к техническому заданию при необходимости приводят:
• перечень научно-исследовательских и других работ, обосновывающих разработку;
• схемы алгоритмов, таблицы, описания, обоснования, расчеты
и другие документы, которые могут быть использованы при разработке;
• другие источники разработки.
Задание 4
Разработайте программу «Налоговый калькулятор». Программа
считается разработанной, если существует исполняемый модуль,
соответствующий требованиям разработанного Технического задания. Во время разработки фиксируйте фактические затраты времени на выполнение всех этапов календарного плана, а также изменения календарного графика. Ведите журнал ошибок.
В ходе разработки программы необходимо будет решить три
задачи: организовать корректный ввод входных данных, реализовать алгоритм расчета величины налога и обеспечить корректный
вывод рассчитанных значений налога и чистого дохода. Если поставить условие не пользоваться готовыми компонентами для организации ввода только числовой информации, то первая задача связана
с программированием фильтров для входных полей и наложением
ограничений на их длину. Вторая задача состоит в программировании бизнес-логики расчета подоходного налога в соответствии с
требованиями технического задания. Наиболее сложная часть дан-
%"
ной программы будет связана с выводом суммы налога и дохода
прописью. Эту задачу можно отнести к разряду классических программистских задач, в Интернете можно найти множество примеров ее реализации.
В разработанную программу внесите несколько искусственных
ошибок. Например, можно внести ошибки в реализацию первой задачи – ввод данных, расширив граничные значения фильтров ввода
и разрешив вводить во входные поля некоторые нечисловые символы, или запретив ввод какой-либо цифры в одно из входных полей.
При реализации второй задачи – программировании бизнес логики программы, можно изменить, например, процент подоходного налога или граничные значения дохода, при которых происходит смена формулы расчета подоходного налога, и т.д.
Большинство алгоритмов, реализующих третью задачу – вывод
суммы прописью, предоставляют удобную возможность ввести в
программу ошибки, которые будут проявляться, например, неправильными падежами или неправильными значениями числительных в определенных числовых диапазонах.
Характер введенных в программу искусственных ошибок сохраняйте в секрете до окончания выполнения тестирования в задании 5.
Задание 5
Организуйте тестирование программы. Разработайте программу и методику испытаний программы на соответствие требованиям
Технического задания. Обменяйтесь исполняемыми модулями с
введенными в них искусственными ошибками с коллегой и проведите тестирование чужой программы. По результатам испытаний
составьте протокол тестирования. По методу Миллса оцените число оставшихся в программе ошибок. При необходимости программа передается автору для доработки.
Проведите работу над ошибками. Для этого составьте таблицу
интенсивности появления и обнаружения ошибок по этапам (см.
табл. 3.6.). Объясните результаты. Что, по вашему мнению, следует
изменить в организации работы, чтобы повысить ее эффективность?
Задание 6
Подготовьте комплект документов для регистрации программы
«Налоговый калькулятор» как объекта интеллектуальной собственности. Требования к комплекту документов и бланки документов
можно получить на сайте http://www1.fips.ru/wps/wcm/connect/
content_ru/ru/copyright/soft/article_forms .
%#
Задание 7
После завершения разработки подведите итоги. Выясните:
• что удалось и что не удалось сделать в данном проекте;
• какой опыт вы получили в ходе его реализации;
• какие трудности встречались при разработке;
• на что было потрачено время, что вызвало самые большие
затраты;
• насколько реалистичен был сетевой график, чем вызваны серьезные отклонения от начального графика.
Результаты анализа оформите в виде итогового документа, который
поможет вам при планировании и реализации будущих проектов.
%$
ÊÐÀÒÊÈÉ ÑËÎÂÀÐÜ ÒÅÐÌÈÍÎÂ
Авторские права – это интеллектуальные (неимущественные) права на произведение (например, программу или базу данных).
Они возникают с момента создания произведения, всегда принадлежат гражданину или гражданам, создавшим произведение,
и не зависят от факта регистрации данного произведения или
соблюдения каких-либо иных формальностей.
Архитектура программной системы – это первичная организация
системы, сформированная ее компонентами, отношениями между
компонентами и внешней средой системы, а также принципами, определяющими структуру и эволюцию системы.
Аудит системы качества – всесторонняя проверка системы качества, действующей на предприятии. Обычно выполняется фирмой-аудитором.
Безопасность – состояние, при котором отсутствует недопустимый
риск, связанный с причинением вреда жизни или здоровью граждан, имуществу физических или юридических лиц, государственному или муниципальному имуществу, окружающей среде, жизни
или здоровью животных или растений.
Всеобщее управление качеством – (Total Quality Management – TOM) –
общая идеология управления качеством, включающая: организационную структуру, необходимые технические средства, а также
комплекс методов и мероприятий, необходимых для обеспечения планируемого качества производства.
Единство измерений – состояние, при котором результаты измерений выражены в узаконенных единицах величин и погрешности измерений не выходят за установленные границы с заданной вероятностью.
Единство обозначений и маркировки – требования к упаковке, маркировке, этикеткам на продукции и правилам их нанесения,
обеспечивающие однозначность идентификации видов и свойств
продукции.
Единство терминологии – состояние, при котором все участники
одинаково понимают и используют все термины, связанные с
данным видом деятельности.
%%
Жизненный цикл (ЖЦ) программной системы – непрерывный процесс, который начинается с момента принятия решения о необходимости создания системы и заканчивается в момент ее
полного изъятия из эксплуатации.
Интеллектуальная собственность – собирательное понятие, означающее совокупность исключительных прав на результаты
творческой деятельности и средства индивидуализации.
Информационные ресурсы – информация, организационные структуры и технологии, обеспечивающие полноту, достоверность
и актуальность информации, а также организующие доступ
к этой информации.
Исключительное право – это право использования результата интеллектуальной деятельности по своему усмотрению, т.е. право
распоряжаться произведением как собственностью.
Качество – совокупность свойств и характеристик изделий или
услуг, обеспечивающих удовлетворение установленных или
предполагаемых потребностей.
Клиент – программный модуль, способный сделать запрос серверу
и принять ответ на сделанный запрос.
Команда – группа людей, преследующих одну цель, в которой
авторитет каждого участника зависит от его вклада в достижение общей цели.
Контрольные карты Шухарта – временные диаграммы фактического и требуемого изменения основных параметров контролируемого процесса. Для оценки величины отклонения параметра от требуемого значения на карту наносятся доверительные области.
Конфигурация программного проекта – совокупность всех компонентов проекта, таких, как: документы, сопровождающие проект, исходные тексты программ, структурные схемы, программные модули, планы и графики работ, базы данных, библиотеки, файлы помощи, методики и результаты тестирования, другие компоненты проекта. См. управление конфигурацией.
Лидер – человек, который в данный момент лучше других понимает ситуацию и действует в интересах всей команды, иногда
вопреки своим сиюминутным интересам.
Матрица потерь – матрица, столбцы которой соответствуют сценариям проявления внешних факторов, а строки – принимаемым решениям. Матричные элементы – оценка ожидаемых
потерь/выгоды при реализации данного сценария и выборе
данного решения.
%&
Метод сценарного моделирования – метод, в соответствии с которым продумываются несколько возможных сценариев поведения моделируемого объекта. Для каждого сценария оценивается вероятность его реализации и основные параметры
объекта.
Метрика – совокупность измеряемой величины, способа ее интерпретации и метода измерений.
Метрология – наука об измерениях. В ее задачи входят: поиск методов измерения, обеспечение сопоставимости и достоверности результатов измерений.
Модель жизненного цикла – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки,
функционирования и сопровождения программного продукта.
Модульный принцип программирования – разделение большой программы на несколько относительно простых программных модулей, каждый из которых выполняет определенную функцию.
Несоответствие – отклонение характеристик продукции или процесса ее производства от заданной нормы.
Общие причины несоответствия – множество случайных неуправляемых причин несоответствий. Вклад каждой из них может
быть невелик, но суммарное действие существенно. Они определяют масштаб собственной изменчивости нормально идущего процесса.
Ожидание риска – математическое ожидание потерь, связанных
с риском. В простейшем случае – произведение размера потерь и вероятности риска. См. риск.
Особые причины несоответствия – несоответствия выполняемых
операций технологическим инструкциям, отклонения качества сырья, сбои в управлении и т.д.
Открытые информационные системы – системы, реализующие открытые (не являющиеся тайной для пользователей) спецификации (стандарты) на интерфейсы, службы и форматы данных.
Ошибка – случайное, непреднамеренное искажение, погрешность
в компонентах программной системы, проявляющееся в процессе их анализа или функционирования.
Планирование – конструирование будущего. Мы продумываем действия, которые сами должны совершить, чтобы достигнуть
намеченной цели.
Поверка – совокупность операций, выполняемых в целях определения и подтверждения соответствия средства измерений установленным техническим требованиям.
%'
Прогнозирование – предсказание будущих событий. На основе анализа существующего положения дел, изучения истории развития прогнозируемого объекта и мнений экспертов выявляются тенденции и формируются предположения о развитии
событий в будущем. Большинство факторов, учитываемых
в прогнозе, не зависят от нашей воли, однако их учет позволит нам разработать хороший план.
Программная система (ПС) – программный комплекс, снабженный необходимой документацией, ориентированной на сбор,
хранение, поиск, обработку, передачу и отображение информации в некоторой предметной области.
Проект – временное предприятие, осуществляемое в целях создания уникального продукта или услуги.
Процесс – совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные.
Риск – нежелательное событие, появление которого может привести к потерям. Выделяются три компонента риска: событие,
его вероятность и потери, связанные с этим событием.
См. ожидание риска.
Сервер – программный модуль, находящийся в ожидании запросов
клиентов, способный принять запрос от клиента, обработать
его и отправить результат обработки.
Сервис – сервер, выполняющий типовые задачи обработки информации и имеющий стандартный, унифицированный интерфейс.
Сертификация – подтверждение соответствия объекта сертификации предъявленным к нему требованиям. Как правило, сертификация проводится специализированными организациями
(органами по сертификации).
Система – совокупность взаимодействующих компонентов и взаимосвязей между ними, направленная на достижение определенной цели.
Система Тейлора – система научной организации труда, в соответствии с которой процесс производства разделяется на последовательность относительно простых операций, для каждой
из которых определяется: цель и требования к результату,
требуемые ресурсы и нормативы затрат, характеристики качества и методы их контроля.
Система управления качеством – совокупность организационной
структуры, ответственности, методик, процессов и ресурсов.
необходимых для осуществления общего руководства качеством.
&
Совместимость изделий – способность изделий работать вместе (например, в одном механизме).
Сопровождение – процесс внесения изменений в эксплуатируемую
программную систему.
Средство измерений – техническое устройство, предназначенное для
измерений.
Стандарт – документ, в котором устанавливаются требования к
характеристикам продукции, правилам осуществления и характеристикам процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, выполнения
работ или оказания услуг. Стандарт также может содержать
требования к терминологии, символике, упаковке, маркировке
или этикеткам и правилам их нанесения.
Статистическое управление качеством – управление процессом, при
котором акцент делается на уменьшение вариаций, случайных отклонений характеристик процесса от намеченной цели.
Тестирование – 1) процесс анализа или эксплуатации программного
обеспечения в целях выявления дефектов (ошибок); 2) этап
жизненного цикла ПС, на котором выполняется проверка соответствия тестируемого компонента некоторым установленным требованиям. В данном контексте тестирование выступает проверкой условия в точке принятия решения. Если
несоответствия найдены, то программный компонент возвращается на доработку и исправление ошибки, или производится дальнейший анализ серьезности найденных ошибок.
В противном случае компонент ПС передается на следующий этап ЖЦ.
Технический регламент – правовой документ, устанавливающий
обязательные для применения и исполнения требования к
объектам технического регулирования (продукции, процессам производства, эксплуатации,
хранения, перевозки, реализации и утилизации).
Техническое регулирование – правовое регулирование отношений
в области технических требований и оценки соответствия им.
Требование – это условие, которому должна удовлетворять ПС, или
свойство, которым она должна обладать.
Унификация – метод стандартизации, согласно которому детали
и узлы разрабатываются не для одного, а сразу для нескольких мест применения.
Управление конфигурацией – поддержание всех элементов конфигурации в согласованном состоянии при внесении изменений в систему. См.конфигурация программного проекта.
&
Функциональная точка – условная единица функциональности программной системы.
Хозяин процесса – участник процесса, отвечающий за его правильное функционирование. Хозяин процесса должен быть мотивирован к тому, чтобы процесс был устойчив и вариации снижались. При возникновении проблем, которые сам хозяин
не может решить, он обращается к другим участникам процесса.
Цикл Деминга – типовая последовательность действий управляющего процессом: планируй, действуй, контролируй, корректируй.
Электронная документация – проектная документация в электронном виде, поддерживающая систему гиперссылок, позволяющая автоматизировать отслеживание изменений конфигурации в ходе реализации проекта.
Эволюционная модель зрелости – (Capability Maturity Model – CMM) –
модель процессов разработки.
&
ÁÈÁËÈÎÃÐÀÔÈ×ÅÑÊÈÉ ÑÏÈÑÎÊ
Нормативные акты
1. Федеральный закон «О техническом регулировании» от
27.12.2002 г. N 184-ФЗ.– Собрание законодательства РФ, 30.12.2002,
N 52 (ч. 1), ст. 5140.
2.Федеральный закон «Об обеспечении единства измерений»
от 27.04.1993 г. N 4871-I.– Ведомости Съезда народных депутатов
Российской Федерации и Верховного Совета Российской Федерации от 10 июня 1993 г., N 23 ст. 811.
Стандарты
3.ГОСТ 19.101-77 Единая система программной документации
(ЕСПД). Виды программ и программных документов.
4.ГОСТ 19.102-77 Единая система программной документации
(ЕСПД). Стадии разработки.
5.ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем.
6.ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы (КСАС). Техническое задание на создание автоматизированной системы.
7.ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы (КСАС). Автоматизированные системы. Стадии создания.
8.ГОСТ Р ИСО/МЭК 9126-93 Информационная технология.
Оценка программной продукции. Характеристики качества и руководства по их применению.
9.ГОСТ Р ИСО/МЭК 12207-99 Информационная Технология.
Процессы жизненного цикла программных средств.
10. ГОСТ Р ИСО/МЭК 15288-2005 Системная инженерия –
Процессы жизненного цикла систем.
11.РД 50-34.698.90. Методические указания. Информационная
технология. Автоматизированные системы. Требования к содержанию документов.
12. ИСО 8402-94 Управление качеством и обеспечение качества – Словарь.
&!
13.ISO/IEC 12207:1995 Information Technology – Software life
cycle processes, 1995 Amendments 2002, 2004.
14.ISO/IEC 15504:1-9:1998 Information Technology – Software
Process Assessment.
1 5 . ISO/IEC 9126-1 : 2000 – Software engineering – Product quality –
Part 1: Quality model (IS)
1 6 . ISO/IEC 14598 (1 to 6) : 1999-2001 – Information technology –
Software product evaluation
17.ISO/IEC 9000-3-2002. Information Technology -Software Process
Assessment (Системная и программная инженерия– Руководство
по применению стандарта ISO 9001-2000 к программному обеспечению).
18.ISO/IEC 15288:2002 Systems engineering – System life cycle
processes
1 9 . ISO/IEC 9126-2 : 2003 - Software engineering – Product quality –
Part 2: External metrics (TR)
2 0 . ISO/IEC 9126-3 : 2003 - Software engineering - Product quality –
Part 3: Internal metrics (TR)
2 1 . ISO/IEC 9126-4 : 2004 - Software engineering – Product quality –
Part 4: Quality in use metrics (TR)
Литература на тему
22.Благодатских В.А. Стандартизация разработки программных
средств: учеб. пособие/ В.А Благодатских., В.А Волнин., К.Ф. Поскакалов; под ред. О.С. Разумова.– М.: Финансы и статистика,
2006. – 288 с.
23.Боэм, Б.У. Инженерное проектирование программного обеспечения / Б.У. Боэм; под ред. А.А. Красилова; пер. с англ. – М.:
Радио и связь, 1985. – 510с.
24.Брауде Э. Технология разработки программного обеспечения / Э. Брауде – СПб.: Питер, 2004. – 655 с.
25.Брукс Ф.П. Мифический человеко-месяц или как создаются программные системы / Ф.П. Брукс. – СПб: Символ плюс, 2000. –
304 с.
26.Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: учеб. пособие / А.М. Вендров. – М: Финансы и статистика, 2004. – 192 с.
27.Вендров А.М. Проектирование программного обеспечения
экономических информационных систем: учебник / А.М. Вендров;
2-е изд., перераб. и доп. – М: Финансы и статистика, 2005. – 544 с.
&"
28.Вигерс Карл. Разработка требований к программному обеспечению / Пер. с англ.– М.: Издательско-торговый дом «Русская
Редакция», 2004. – 576с.
2 9 . Дейкстра Э. Заметки по структурному программированию //
У. Дал, Э. Дейкстра, К.Хоор. Структурное программирование. –
М.: Мир, 1975. – С. 7–97.
30.Демарко Т. Человеческий фактор: успешные проекты и команды / Т. Демарко, Т. Листер; 2-е изд.; пер. с англ. – СПб: Символ-Плюс, 2005. – 256 с.
31.Калбертсон Роберт. Быстрое тестирование / Роберт Калбертсон; пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 384с.
32.Канер Сэм. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. / Сэм
Канер, Джек Фолк, Енг Кек Нгуен; пер. с англ.– Киев: Изд-во
«ДиаСофт», 2001. – 544 с.
3 3 . Козлов В.А. Открытые информационные системы / В.А. Козлов. – М: Финансы и статистика, 1999–224 с.
34.Котляров В.П. Основы тестирования программного обеспечения: учеб. пособие/ В.П. Котляров, Т.В. Коликова – М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006. – 285 с.
35.Липаев В.В. Программная инженерия. Методологические
основы [Текст] : учебник / В.В. Липаев; Гос. Ун-т – Высшая школа
экономики. – М: ТЕИС, 2006. – 608 с.
36.Макгрегор Джон. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие / Джон Макгрегор, Девид Сайкс; пер. с англ.– Киев: ООО «ТИД «ДС», 2002. –
432 с.
37.Мартин, Роберт С. Быстрая разработка программ : принципы, примеры, практика/ Роберт С. Мартин; пер. с англ. – М.:
Издательский дом «Вильямс», 2004. – 752с.
38.Орлов С.А. Технологии разработки программного обеспечения: учебник / С.А. Орлов – Спб.: Питер, 2002. – 464с.
39.Панкаж Джалота. Управление программным проектом на
практике / Джалота Панкаж; пер. с англ.– М.: Лори, 2005. – 223 с.
40.Принципы проектирования и разработки программного обеспечения: Учебный курс MCSD. Пер. с англ.; 2-е изд., испр. – М:
Издательско-торговый дом «Русская Редакция», 2002. – 736 с.
41.Роббинс Дж. Отладка приложений / Дж. Роббинс. – СПб.:
БХВ-Петербург, 2001. – 512 с.
&#
4 2 . Соммервилл И. Инженерия программного обеспечения /
И. Соммервилл; 6-е изд.; пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 624 с.
43.Спольски Дж. Джоэл о программировании и разнообразных
и иногда родственных вопросах, которые должны быть интересны
разработчикам программного обеспечения, проектировщикам и
менеджерам, а также тем, кому посчастливилось или не повезло в
каком-то качестве работать с ними / Дж. Спольски; пер. с англ. –
СПб.: Символ Плюс, 2006. – 352 с.
44.Тамре Л. Введение в тестирование программного обеспечения / Л.Тамре; пер. с англ. – М.: Издательский дом «Вильямс»,
2003. – 368с.
Интернет-ресурсы
45.NASA. One hundred rules for NASA project managers:
http://www.altisinc.com/resources/rules/100_rules.php
46.Меры сложности программного обеспечения:
http://www.met-rix.narod.ru/page1.htm
47. Метод функциональных точек
www.ifpug.org
&$
Учебное издание
Гусятников Виктор Николаевич
Безруков Алексей Иосифович
СТАНДАРТИЗАЦИЯ И РАЗРАБОТКА
ПРОГРАММНЫХ СИСТЕМ
Заведующая редакцией Л.А. Табакова
Редактор Е.А. Рыжова
Младщий редактор О.О. Салтыкова
Художественный редактор Г.Г. Семенова
Технический редактор Т.С Маринина
Корректор Н.Б. Вторушина
Компьютерная верстка И.В. Витте
ИБ № 5347
Подписано в печать 03.02.2010. Формат 60х901/16
Гарнитура «Таймс». Печать офсетная
Усл. п.л. 18,0. Уч.-изд. л. 16,69
Тираж 1500 экз. Заказ
«С» 005
Издательство «Финансы и статистика»
101000, Москва, ул. Покровка, 7
Телефон (495) 625-35-02. Факс (495) 625-09-57
E-mail: mail@finstat.ru http://www.finstat.ru
&%
&&