И. Соммервилл - Инженерия программного обеспечения (1133538), страница 114
Текст из файла (страница 114)
В частности, они опрсдсляют нештатное поведение системы, а нс сс "рабочее" повсдснис. Однако. как правило. невозможно определить это поведение в виде простых ограничений, коцтролирусмых системой. Осцовнос отличие мсжду безопасностью и защнщснностью состоит в том, что проблсмы бсэопасностн обычно имсют случайный характер, в то время как атаки на защищенность системы совершаются прсднамс реп но. Даже в тсх системах, которые используются ужо много лст.
нзобрстатсльный взломщик может найти новый способ проникнуть в систему, которал до сих пор считалась эащищснной. Например. долгое время считавшийся бсзопасным алгоритм шифрования данных ИВА был взломан в 1999 году. Сущсстпуст чстырс дополняющих друг друга метода проверки эащищснности. 1, Лттпонпкиц оеновпннпл нп ггредыдуктеэг аниме. Здесь система анализируется по атно. вению к различным типам атак. известных группе аттестации. Данный тип атгс.
стацип обычно проводится совисстно с аттссгацисй, выполнясмой инсгрумсн. тальными средствами. 2. аэгомегпаннл нггапрулиггпгпльными е]мдеггмпнгс Здесь лля анализа системы используются разные инструменты защищенности, наприлгср программа проверки паролей. Данный метод дополняет аттестацию, основанную на прсдыдущслг опыте. э.
Коканда выомп. Команда ставит пород собой цсль — взломать систему разными способами, Напримср, моделируются атаки на систему. 4. Формпвлггпя вернфнкагтил. Выполняется'провсрка системы на соответствие формальной спецификации эащигяснности. Этот метод нс имеет широкого применения. Коночным пользоватслялг очень сложно проверить защнщспность системы. Поэтому в Сонорной Америке н Европс выработаны системы крнтсрисв оцспки защищенности, которые контролируются спсциэльно обучснными экспертами [131], Поставщики готового ПО люгут прсдставить на расслготрснис свои конечные продукты для оценки и сертификации гго различным критериям защищенности.
КЛЮЧЕВЫЕ ПОНЯТИЯ ° Из.за высокой стоимости последствий отказов в критичеспц системах такие методы верификации и аттестации, квк формальная спецификация и доказательства„требующие значительных рзсхо. дов, могут оказаться рентабельными для критичесех систем. ъ °,Ствтистическое тестирование применяется для оценки безотказности ПО.
При этом проводится' тестирование системы с наборами тестовых данных, соответствующими операционным профилям данного ПО. Генерация тестовых даннык может быть автомвтизироввна ° Модели возрастания безотказности моделируют изменения безотказности в процессе тестирования по мере исправления ошибок в ПО, Модели возрастания безотказности можно использовать' для оценивания моменте достижения необходимой безотказности и завершения тестирования ПО. 21. Аттестация критических систем 443 ° Доказательство безопасности яшшется"жрг$ектианйм "методомг оценийанйя йэдежности готового ,,:,,',продукта.
В ходе доказательства демонстрируется невозможность возникновения отказов в сис', ' ' теме. Обычно доказательство безопасности проще, чем доказательство соответствия программы ,' "чух Аттестацию защищенностй'маею'др(ювсти методйм анализа,"'рсйояаййов'ига"п~геул(ыдущегл ошяге, ьф~,.„с поыощью инструментальных.срщюте'илй с помощью комшщы; имитирующей атшщ'на систему. Упражнения 21.1. Проведите аттестацию по спецификации безотказности для программной системы, управляющей сетью кассовых терминалов в магазине, описанной в упражнении 17.3. Опишите все методы и средства, которые использовались в процессе аттестации.
21.2. Объясните, почему практически невозможно проверить безотказность системы, если требование безотказности определено как малое число отказов за время работы системы. 21.3. Этично ли поведение разработчика, который соглашается поставить заказчику программную систему с известными дефектами2 Этично ли его поведение, если в данной ситуации он заблаговре. менно предупредит закаэчика о наличии в системе ошибоку Разумно ли заявлять о безотказности системы в таких обстоятельствкту 21.4.
Объясните, почему обеспечение безотказности системы не гарантирует безопасность системы. 21.6. Система управления дверным замком в системе хранения радиоактивнык отходов спроектирована с учетом безопасности обслуживающего персонала, Вход а хранилище разрешен, только когда установлены защитные экраны или если уровень радиации в хранилище ниже некоторого уставов. ленного значения (г(апйег(.ечеЦ. Итак: ° если контролируемые на расстоянии защитные экраны установлены, зарегистрированный оператор может открыть дверь; ° если уровень радиоактивности меньше некоторого определенного значения, зарегистрированный оператор может открыть дверь; ° регистрация оператора определяется посредством ввода им личного входного кода. Программный код на языке 3ача, используемый для управления механизмом дверного замка, представлен в листинге 21.3. Заметим, что безопасное состояние состоит в том, чтобы не разрешить вход в хранилище, если не выполнены перечисленные выше условия.
Покажите, что код в листинге 21.3 потенциально небезопасный. Измените его так, чтобы он стал безопасным. 21.6. Используя спецификацию вычисления дозы в системе управления инъекцией инсулина (см, главу 9, рис. 9.10), по аналогии с программой из листинга 21.1 напишите на языке эата код метода согпрмте! пвмбп. Постройте неформальное доказательство безопасности этого кода. 21.7. Опишите, как вы проводите аттестацию системы защиты с помощью паролей для разработанных вами приложений. Объясните назначение и применение любого инструментального средства, которое, на ваш взгляд, может оказаться полезным. 21.В. Предположим, что вы представитель группы разработчиков программного обеспечения для химического завода, работа которого вызывает серьезное загрязнение окружающей среды.
Ваш руководитель во время интервью на телевидении заявил, что процесс аттестации программной системы всесторонний и ошибок в ней быть не может. Далее он сообщил, что проблемы возникают вследствие неправильных действий операторов, обслуживающих систему. Системные операторы не согласны с такими заявлениями и предлагают бастовать. Как вы будете действовать в сложившейся ситуации? 444 Часта М. Верификация и аттестация Листинг 21.3. Управление дверным замком епггусойе = 1ос)г.дегапггусойе(); ЕЕ(епггусойе -"= 1осв.апспогЕвейсойе) ( впте1йзсагпв = 5ПЕе1й.десзсаспв(); гайтаггопьече1 = Райдепвог. дев (); 1Е(гайтагаопЬеое1 < йапдегЬече1) агаве = ваЕе е1ве агаве = ппваЕе ЕЕ(впае1йдгагпв == 5оае1й.зпР1асе()) агаве = ваЕе ; ЕЕ(вгаге == ваЕе) ( Поог.1освей = Еа1ве ()оог.ип1осв(); е1ве ( ()оог.1ос)г(): ))оог.1освей = ггпе; ) Управление персоналом 1 ш ,'ю гэ знать основные модели организации человеческой памяти, модели решения проГшсм н мотивации, а также механизмы их применения в практической работе р>ководптслсй проектами по созданию программного обеспечения; иметь представление об основных проблемах ко.
мандиой работы (в частности, при подборе членов команды), о сплоченности команды, внугрикомаид. н ых взаимоотиошенилх и сс структуре; знать о проблемах, связанных с подбором и сохранением персонала в организации, занимаю- шейся разработкой и сопровождением программного обеспечения; иметь понятие о модели Р-СММ, которая являс гся основой для повышения производительносги сотрудников органиэации, занимающейся созданием программного обеспечения. l ."' зе~Ь ьн 'Ч - гж .ц'э ', 32~1 н , ч ш '"з в р( / Э» ''Дф 4 жте ~фет1Дфф:к~~э~,'~~ ~|~~Щяуч'"„".';.рл,'а~~"„-"~~.~;ь зьь 22.1.
Пределы мышления 22.2. Групповая работа 22.3. Подбор и сохранение персонала 22тй Модель оценки уровня развития персонала Цель этой главы — рассмотреть роль человеческого фактора в процессе разработки программного обес- печения. Изучив материал главы, вы должны: 443 Часть 71. Управление Люди, работающие в компаниях по разработке ПО, являются нх самым ценным "активом". Именно они представляют интеллектуальный капитал, и от менеджеров по разработке ПО зависит, получит ли компания наилучшие из возможных дивиденды от инвестиций в человеческие ресурсы. В успешно развивающихся компаниях и зкономических структурах это достигается в том случае, если организация уважает своих сотрудников.
Круг выполняемых ими обязанностей и уровень вознаграждения должны соответствовать их умению, которое, в свою очередь, зависит от квалификации. Таким образом, эффективный менеджмент — зто эффективное управление персоналом компании. Менеджеры — руководители проектов должны решать как технические, так и далекие от текническнк вопросы, используя при этом членов команды с оптимальной зф. фективностью. Они должны уметь мотивировать действия людей, организовывать их работу и гарантировать ее качественное исполнение.
Слабый менеджмент персонала — одна из основных составляющих провала программных проектов. В своих рассуждениях я опираюсь в основном не на принятые в наше время модные модели теории менеджмента, а на два фактора- познавательный и социальный. Процесс разработки ПО включает в себя познавательный и социальный процессы, поэтому именно эти факторы я считаю самыми важными в углублении понимания того, как создаются программы. Если у менеджеров есть понятие об этих основах, тогда они лучше управляют людьми, получал наибольшую отдачу.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
