книги / Надежность программного обеспечения систем обработки данных
..pdfвременные ограничения B I .H M (MIHIIIWI
Наиболеесущестаеяяым 'фактором* заслуживающим отдельное» рассмотрения, является 'укрюменне надежно* стъю « Процессе разработки.
Накопленный опыт оргамоацни работ' по созданию ПО указывает на иаобаодямоетк1уделения этой йробиМие' самого пристального внимания, так-как'решение аопросов структурной организации групп проектирования и программирования, распределение ответственности по этапам разработки, подбор я расстановка кадров в зна чительной мере влияют на достижение заданного уровня Надежности ПО.
Достижение заданного<уровян надежности зависит не посредственно от того» кто н Как руководит разработкой ПО. Программисты чувствуют, что наиболее серьезные ошибки ПО Вызываются обычно административными проблемами, а не просчетами конструкции, внедрения или тестирования программ. К таким административный решениям относятся, например, давление на ускорение начала кодирования до завершения конструирований из-за сжатых сроков на разработку, недостаточные Тре бования к подготовке Программистов, несоответствие возможностей программиста порученной работе.
Считается, что среди переменных, связанных С обес печением управления разработкой, наиболее важной яв ляется минимизаций количества занятых В работе людей'. Попытки решить проблему обеспечения качественной1 разработки за счет привлечения большего количества исполнителей еще не приносили положительных резуль татов в разработке ПО. В дополнение к положительному влиянию на стоимость и сроки минимальное число разра ботчиков оказывает положительный эффект я на надеж ность выходного продукта благодаря уменьшению числа звеньев в разработке и, следовательно, количества ошибок трансляции.
Второй проблемой управления разработкой является получение ответа на вопрос: должна ли одна и та же группа специалистов выполнять весь проект от начала до конца? Основываясь на предыдущей проблеме, можно ответить на поставленный вопрос утвердительно. Однако есть различные причины, по которым нецелесообразно поручать ответственность за все фазы конструирования одному коллективу. Поручая ответственность за две по следовательные стадии конструирования различным ис полнителям, имеем возможность получить лучшую доку-
4»
иентацию * двоиауюпроверку конструкцин.так как ре зультаты каждой. предыдущей стадии ■разработки прове ряются>м AKiMftVtouufS стадии с явной замнтеоесованиостыо.
С другой стороны, узкая специализация в пределах одной стадии разработки позволяет получать результаты аа болея профессиональном уровне, т. е. мало вероятно, чтобы один спецн&лнст всовершенстве владел такими различными знаниями, КаКсиСтеМиая архитектура, яро* граммнаи структура, конструирование алгоритмов, коди рование на конкретном языке и г. д.
Следующей существенной проблемой управления раз
работкой является организация контроля. Процесс контро ля является частью Проекта, требующей наиболее ответ ственного планирований и ВИИмаиия со стороны руково дителя. Одно из основный требований к контролю — структурное отделение его исполнителей от разработ
чиков проекта по примеру отделов технического контро ля на предприятиях. Организация Контроля может бази роваться на достаточно хорошо разработанных системах стимулирования качества работы. Так, из зарубежных источников известно, что программисты премируются за отсутствие ошибок в их продукции, специалисты по конт ролю должны вознаграждаться за нахождение ошибок.
В практике руководства разработкой отмечается раз деление выполнения функций между сотрудниками груп пы программирования. Так, высококвалифицированные конструкторские работы начальной стадии проектирова ния поручаются наиболее Опытным разработчикам. Сле
дующие по шкале |
значимости — работы по кодирова |
нию — поручаются |
среднему По Опыту программирова |
ния персоналу; Работы по техническому обслуживанию поручатся молодым и неопытным программистам. Ор ганизация с подобной системой должна достигать Опре деленного соответствия между руководителем и подчи ненными н обеспечивать равные возможности продви жения дли всех сотрудников.
Важное значение в усилиях по достижению надежно го ПО должно быть отведено вопросам формирования групп программирования^ Группы программирования ока зываются в ряде случаев наиболее полезной формой организации специалистов по Следующим причинам:
улучшается связь между специалистами одного про филя, что не может не способствовать обмену опытом и более быстрому >становлению молодых программистов;
42
внутри группы люгут; сушествоИвть.и еовершенетвог ваться гручяовые стандзртыкзчёства разработки и процедурысаыокОнтроля, чт;о способствует повышенню надежности разрабатываемого продукта;
развивается дух коллективизма и обшей ответствен ности за порученное дело;. :
'значительно проще.решается вопрос пёрераспр^велег ния функций и случае, когда один разработчик или часть разработчиков, покидают' груоду.
Взарубежной практике .рассматриваются три вариан та комплектования групп программистов: группа во главе
сглавным программистом, группа специалистов и де мократическая rpyqna.
Вгруппе с главнцм программистом последний руко
водит ее работой. Он .назначается из числа наиболее опытных и знающих программистов и выполняет все кон структорские задачи, разрабатывает программы для наи более важ.ных модулей,, проводит интеграцию и тести рование. Он также выступает в качестве: первоначаль ного связующего звена с организацией пользователя и другими группами, участвующими в проекте. Это позво* ляет сократить число связей , при разработке проекта и в значительной мере уменьшить количество;ошибок связи.
Главному программисту помогает его заместитель, обладающий достаточно хорошей подготовкой и выпол няющий исследование конструкторских альтернатив, пла нирование. Он Также принимает участие в конструиро вании, кодировании и тестировании^ Еще одним постоян ным членом группы может быть библиотекарь программ
Остальной состав группы в известной мере случаен, и зависит от особенностей задач, решаемых группой. Например, системный аналитик может-быть в составе группы на стадии внешнего проектирования при разработке спецификаций. В зависимости от объема работ на' стадии кодирования в группу могут включать двух и более программистов. .
Практика показывает, что группа главного програм миста способна решать возлагаемые на нее задачи. Одна ко данной структурной организации свойственны н неко торые недостатки. Часто утверждают, что группы глав ного программиста хороши для главных программистов, но ие престижны для других специалистов, так как программисты перемещаются из группы в группу, вслед ствие чего у них притупляется чувство ответственности за выполняемую работу. Для обеспечения работоспособ
на
ности с т р у к т у р а 9р ^ н н ? ^ 1(и ^а^ нр. цтобыгладный программист пользовался Ьр^окнм авторитетом $ группу. Если выбор был н^удачныц. то это может породить опре деленные трудности в работе,
Второй вариант структурной организации — группа специалистов, основным отличием которой от группы главного программиста является то» что специалисты остаются в группе в течение всего проекта н каждый из нйх имеет конкретное Задание с учетом его способностей. Работой этой группы также руководит главный програм мист, выполняющий написание кодов и документации по продукции группы. Связь с другими группами, разра батывающими проект, осуществляет помощник главного программиста. В состав группы может входить также администратор, выполняющий работу по контролю бюд жета, обеспечению условий для работы группы (помеще ния, инвентарь, снабжение, машинное время, учет, от четность) й набору персонала.
В состав группы включается редактор документации, осуществляющий редактирование и наблюдение за ее дальнейшим прохождением, С(6да же входит и библиоте карь программ. Дополнительный член группы отвечает за конструирование и развитие (получение) любого необ ходимого программного или проверочного оборудования. Специалист по контролю, аходящий в состав группы, отвечает за производство и ведение всех необходимых т^сТов. Последний член группы — специалист по языку, обеспечивающий исследование средств программирования и алгоритмов.
Третий тип группы, рассматриваемый а зарубежной практике,— это демократическая группа. В такой группе нет официально назначенного руководителя. Отдельные члены группы выступают в качестве неофициального ру ководителя на конкретном этапе разработки, иа кото ром данный специалист является более квалифициро ванным. После завершения проекта группа не распада ется и как единое целое включается в новый проект. Считается, что такое использование способствует поддер жанию высокого профессионального уровня и устойчи вых рабочих отношений в группе.
С возникновением групп программирования признано, что программирование является коллективной» а не инди видуальной деятельностью. Практика показывает, что ни одна из представленных ранее форм объединения не яв ляется лучшей для всех внешних условий функциониро-
44
вання. В резу^гатё b ЪдноЙ'Й той Ж« организации могут исполъэбватак' все варианты групп. ( ,
ПолёзйуЬ'фоль в работе группу программирование , выполняет библиотекарь программ, этот социалист яв ляется связующим звеном между программистом й ЭВМ, Он выполняет осибвиуй) канцелярскую работуt по ррое£- с ту* ввод данных, редактирование программ ,if проверку, сохранение программных распечаток, носителей исходны^ и объектных кодов/На' riero возлагаются также задачи ведения документации, хронологического архива всей де ятельности и корреспонденции проекта.
С целью обеспечения надежности ПО библиотекарь проводит централизованный контроль текущих версий программ и документаций
Если иСпользуётск система работы с программной биб лиотекой, то библиотекарь является единственным пользе* вателем данной системы, сокращая этим самым количество программных средств, которые должны быть освреиы про граммистом На библйотёкаря возлагается также работа по регистрации корреспонденции, составлении? докумен тов, Печати и подготовке графических документе по проекту 1 1 ' t '
Несмотря на Наличие Определенных преимуществ, ра боты библиотекаря в группе, это решение порождает ^ определенные недостатки г
программист теряет сЬязь со своей црогоодм0**' так, как контакт с ЭВМ передай бйоЛнфтекарк?, Действитель но, очень важно, чтобы Программист с*м имел определен ный опыт работы с разработанной программой. Это.доет программисту возможность Лучше приять влияние приня тых им решений на пользователей пфргрдм^ы;
не доказано, что Освобождение программиста от кан целярской работы принесет Только пользу с точкй зр«иия1, надежности Программирование интеллектуальная работа, и будет полезнее, если программист переключится на выполнение работы другого типа, продолжая подсо знательно думать о своей программе,
на отдельных этапах разработки библиотекарь зава лен работой и является узким звеном группы. На других же этапах объем работы библиотекаря достаточно огра ничен.
Перечисленные выше недостатки могут быть преодо лены за счет планирования и организации работ в группе, а библиотекарь программ будет в значительной мере способствовать созданию надежных программ
45'
2.3 ЭКСПЛУАТАЦИОННЫЕ ФАКТОРЫ
В группу |
|
.jgfitifpptiti; iA^i^iifb'nRx' |
ДбсТн)kferiйе Ык'МkhortkУровня |
надёжности, JBключаются |
|
едедующнефаиторы; |
„ |
- |
... полМотаи качество документации. Эксплуатационная документация на программные средства цм|ёеТ боДьшое значение м я рргэиизадйи^чественнЬгр Сопровождения и эксплуатацийснстемы ПО. и полного использования возможностей ЭВМ;
степень адаптации документации. Документация долж на выть разработана .применительно г к использованию различным контингентбм' прСгр£Ймистов и пользователей. Так, для ЕС ЭВМ разработёнб рукб1юдствд системного программиста — документ, содержащий сведения, необ-
для, проверки ц обеспечения .функционирова ния; руководство программиста — до^мент, содержащий введения, нёрбЗюдимые для полного использования воз можностей программы; руководство оператора — доку мент, включающий сведения, необходимые для обеспе чения процедуры общения человека с ЭВМ и т. д.;
‘npCctofa изучения и использования системы ПО на
основе дочументдции и путец* контрольных пропусков на ЭВМ. Реализация этого фактора исключает возмож нее, ошибкиэк<шлуатации; '
качество обучения пользователей, ответственных за ёнсплуатацщо ПО, фшибки .пользователей, совершаемые
в‘, Э к с п л у а т а ц и и |
программ» йэ-за, недостаточных |
усилий "по1о б у 4 ф к |
! а к > .источацрцвр|д нецадеж- |
ЙрСтиПР; '' |
. ; |
cteheHb вмфянщНф стандартов на эксплуатацию НО.
.{&выцш1нёйй§' ста^арт^в, нд эксплуатацию ПО может прррдйть Сшибки ; поЛьЛорателей, «что послужит источЩбМ. ;вдн.адён(.иости‘ , ........
щи(ищенНрсту цнфррмацщ ф уерамм, Система защи те/ .информаций программ дол^на исключать любые по пытки изменить содержимое .защищаемого объекта., по влиять ца получаемые результаты и.выводимую инфор мацию.
Факторы данной группы определяют надежность; ПО с качеСтвеннОй стороны и не могут практически быта из
меренными количественно. |
факторов, определяющих |
|
Приведенный |
перечень |
|
надежность |
не претендует „на полноту, может -быть |
|
дополнен в зависимости |
от потребностей анализа. |
|
1. |
JPaH^p3^^Ki»p4J9$mpft tpynntf’jBp маш м«п|. ....... •-< i> |
||||
2' СфоЬй*л1фУ11пге'рйШюдрмйсП' i |
••♦’••< " " '" ^ |
првытен^я квалц- |
|||
3. |
фи^Ш г-трсонала. - |
■'■' ■ |
|
||
Кцовы тенденции |
в развитии |
нзыпок - врвграмийровантг? |
|||
4. |
Сформулируете взанмосвязц «жду |
надежностью м Применяемым |
|||
|
языком программирования. |
|
, : *. ; „ |
. v* а .jp, |
|
5.Дайте характеристику группе технологических факторов.
6.В чем состоят Проблема управления разработкой ПО?
7Дайте характеристику' эксплуатационным факторам.
...г л а д а Э, .
ПРИЧИНЫ р ш л ы э к В ПРОГРАММНОМ ОЙЕРПБЧ^НИИ
• Для получения надёжных Я ^ а и н 1 необходимы твердые знания о типа* встречающихся ошибок. Ка&дый, кто когда-либо пытался н&пкедть и отладить' программу, которая не иьшла иэ-за ошибок йлй дала неправильный результаты; знает, ч¥0Гкг0 Обычное явление. Программист вырабатывает свой с¥вл£ защитыот ошибок, свою лич ную теорию о том, что ЙДёт' неправильно и каковы 1$&Й* вы. Как результат ЭТОЙ'ДЯОрйй; стиДь программирования в следующей разработке йзмёйяётСя, программист йзбё: тает уловок, которыеД' прошлом' оказались безусПешными, иногда даже с ущербом для Цкфективйой работа Программы. ■" “
Крайне желательно; чтобы процесс познания и qiraиовления программиста йереШел ив Области «проб й оши бок» к целенаправленному Обучению приемам и методам работы. Это особенно важно в связи с тем, что все бблЁшие контингенты людей вовлекаются Д области приме нения ЭВМ. Естественным подходом к решению ДгоЙ проблемы является обобщение накопленного ЬПыТанй базе идентификации встречаюишхсй ошибок, группировки их по различным признакам, последующего изучения природы групп ошибок, причин Их появления, среДств и приемов защиты, а также средств и приемов их локали зации и устранения применительно к различным этапам разработки ПО.
Несмотря' на то что большинство программистов интуитивно представляют себе характеристики возмож ных ошибок, встречающихся в их программах, необходи мо добиться количественного и качественного понима ния причин ненадежности с целью их эффективного поис ка и устранения.
At
> |
JU H C T W W H О РИ БО К . |
|
flPOrtyMMffQrp РВеСДЕЧШздф, |
Для последующего изучения' вопросов надежности ПО рассмотрим упрощенную схему процесса разработки программного обеспечения t акцентом на этапы, порож ЛвюЩйё йенайе'жность (рис 3.1 i
Рнс d I Укрупненная модель процесса разработмш ПО
Технологический процесс производства ПО можно простейшим образом описать как совокупность этапов, начинающуюся с постановки задачи и заканчивающуюся получением набора подробных инструкций, управляющих действиями ЭВМ при обработке информации Из этого упрощенного подхода следует, что программирование представляет собой решение задачи, а программное обес печение — некоторый специальный набор информации, описывающий алгоритм решения данной задачи Тогда процесс производства ПО можно представить как простой
Iе
набор процессор трансляций fTpH4t^ трансляция начина ется с момента преобразований постановки задачи до по ручения сначала различных .промежуточных результатов и закдиурвается детальном набором машинных и«струя
ций» что и представлено яц рчрунк*;-, Рассмотрим детали процесеа трансляции ицформодци
из некоторого документа А в документ формы В. Эти дей ствия могут быть выполнены за четыре следующих шага Ш а г 1. Читая исходный документ А, человек запоми н^ет прочитанное. Одним из основных eeoftCTB человечес к0го мозга является то. что он воспринимает любую входную информацию, сопоставляет ее с имеющимися у него знаниями и опытом Это же свойство лежит в основе способности человека «уметь читать между строк», пред сказывать концовку фильма и т д К сожалению, именно ЭТИ способности ЯВЛЯЮТСЯ I причиной ошибок, которые возникают в результате неправильного чтения документа А и принятия ошибочного решения при трансляции В исходном документе могут быт^ ошибки, Я их исправле ние может быть произведено только после согласование с поставщиком, документа, Э4о простое утверждениеобыч* но не выполняется, конфликтная ситуация устраняет) с^ «по своему усмотрению», что чаще приводит к ошиб
кам.
Ш а г 2. Информация хранится в памяти человека Для надежного хранения информации необхрднмо прннт мать ее рмЫсл. Этоаку препятствуют такие причины, ка|| сложность информации, отсутствие соответствующей под готовки и опыта работы. 1 >
, Ш а г 3.-выполнение трансляцийИспользуя хранимую информации а также информацию, рпнСывакрщур после-) довательность трансляции, человек выполняет трансля-j цию и фиксирует результаты. Основной причиной появле ния ошибок на этом шаге является то. Что забывается частично входная информация А или тонкости процесса трансляции.
Ш а г 4. Фиксация результатов в документе В. Эти действия выполняются рукописно или с помощью таких средств, как терминал, магнитофон и т. д Если необхо димо переработать и зафиксировать на бумаге большой объем информации, то возникает раздражение разницей в скорости мышления и скорости записи выводов. Здесь вступает в силу стремление записывать кратко с аппеляцией на «очевидность» некоторых далеко не очевидных утверждений. Все это позволяет утверждать, что чело-
49
вед, читая тзкойдокумднт ч принимаянвего основе решеди^непрщ|эцольно.будет^
При такой подходе к разработке ПО основной причин рой его ненадежности являются ошибки, возникающие в процессе тра«слядин информации на различных стадиях технологического процесса. Программные ошибки возни кают тогда, когда-одно состояние описания задачи транс* Даруется в очередное, более детальное состояние непол но или некорректно.
Прежде чем обсуждать модель, отметим, что ее целью не является выделение всех этапов, а иллюстрируются основные виды трансляции, имеющие место в процессе разработки ПО. Так, например» тестирование полностью исключено из модели, этап разработки представлен толь ко двумя шагами, тогда как на практике их значительно брльще. Для лучшего понимания проблемы надежности необходимо рассмотреть основные типы трансляций, представленные на рис. 3.1.
Формулировка требований. Процесс. разработки ПО начинается с описания проблемы, которую необходимо решить (точка 1). Это описание далее транслируется в требования пользователя. В идеальном случае пользова тель сам выполняет описание проблемы и формулирует требования к систем*. Наиболее часто требования к сис теме пишет разработчик после консультации с пользова телем. В любом случае при формировании требований к системе вероятность возникновения ошибки на началь ном этапе разработки достаточно велика. Например, пользователь в силу специфики выполняемой работы Может быть не в состоянии адекватно выразить свои тре бования, требования пользователя могут быть непра вильно лоцяты, не полно представлены, противоречивы.
Очевидно, что допускаемые на этом уровне недора ботки и явные ошибки могут в последствии послужить причиной появления в ПО серьезных ошибок.
Описание щелей. Далее совокупность требований к системе транслируется (точка 2) в описание целей, кото рые должны быть реализованы создаваемым програм мным обеспечением. Этот шаг трансляции обеспечивает выполнение небольшого объема работ по определению и взвешиванию значительной части издержек последующе го проектирования. Программные ошибки могут появить ся из-за неправильного толкования требований; исклю чения ряда моментов, которые должны быть обязательно учтены; неправильного толкования отдельных оговорок я
ВО