СОПРОВОЖДЕНИЕ И ОБСЛУЖИВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНЫХ СИСТЕМ. Методические указания по выполнению практических и лабораторных работ по пм. 04
 Скачать 1.92 Mb.
|
|
Процесс управления разработкой программного обеспечения Невозможно описать и стандартизировать все работы, выполняемые в проекте по созда- нию ПО. Эти работы весьма существенно зависят от организации, где выполняется разработка ПО, и от типа создаваемого программного продукта. Но всегда можно выделить следующие: 58 Написание предложений по созданию ПО. Планирование и составление графика работ по созданию ПО. Оценивание стоимости проекта. Подбор персонала. Контроль за ходом выполнения работ. Написание отчетов и представлений. Первая стадия программного проекта может состоять из написания предложений по ре- ализации этого проекта. Предложения должны содержать описание целей проектов и способов их достижения. Они также обычно включают в себя оценки финансовых и временных затрат на выполнение проекта. При необходимости здесь могут приводиться обоснования для передачи проекта на выполнение сторонней организации или команде разработчиков. Написание предложений — очень ответственная работа, так как для многих организаций вопрос о том, будет ли проект выполняться самой организацией или разрабатываться по кон- тракту сторонней компанией, является критическим. Не существует каких-либо рекомендаций по написанию предложений, многое здесь зависит от опыт. На этапе планирования проекта определяются процессы, этапы и полученные на каждом из них результаты, которые должны привести к выполнению проекта. Реализация этого плана приведет к достижению целей проекта. Определение стоимости проекта напрямую связано с его планированием, поскольку здесь оцениваются ресурсы, требующиеся для выполнения плана. Контроль за ходом выполнения работ (мониторинг проекта) — это непрерывный про- цесс, продолжающийся в течение всего срока реализации проекта. Руководитель должен посто- янно отслеживать ход реализации проекта и сравнивать фактические и плановые показатели выполнения работ с их стоимостью. Хотя многие организации имеют механизмы формального мониторинга работ, опытный руководитель может составить ясную картину о стадии развитии проекта просто путем неформального общения с разработчиками. Неформальный мониторинг часто помогает обнаружить потенциальные проблемы, ко- торые в явном виде могут обнаружиться позднее. Например, ежедневное обсуждение хода вы- полнения работ может выявить отдельные недоработки в создаваемом программном продукте. Вместо ожидания отчетов, в которых будет отражен факт "пробуксовки" графика работ, можно обсудить со специалистами намечающиеся программистские проблемы и не допустить срыва графика работ. В течение реализации проекта обычно происходит несколько формальных контрольных проверок хода выполнения работ по созданию ПО. Такие проверки должны дать общую кар- тину хода реализации проекта в целом и показать, насколько уже разработанная часть ПО со- ответствует целям проекта. Время выполнения больших программных проектов может занимать несколько лет. В течение этого времени цели и намерения организации, заказавшей программный проект, могут существенно измениться. Может оказаться, что разрабатываемый программный продукт стал уже ненужным либо исходные требования к создаваемому ПО просто устарели и их необхо- димо кардинально менять. В такой ситуации руководство организации-разработчика может принять решение о прекращении разработки ПО или об изменении проекта в целом с тем, чтобы учесть изменившиеся цели и намерения организации-заказчика. Руководители проектов обычно обязаны сами подбирать исполнителей для своих проек- тов. В идеальном случае профессиональный уровень исполнителей должен соответствовать той работе, которую они будут выполнять в ходе реализации проекта. Однако во многих случаях руководители должны полагаться на команду разработчиков, которая далека от идеальной. Та- кая ситуация может быть вызвана следующими причинами: 1. Бюджет проекта не позволяет привлечь высококвалифицированный персонал. В таком случае за меньшую плату привлекаются менее квалифицированные специалисты. 59 2. Бывают ситуации, когда невозможно найти специалистов необходимой квалификации как в самой организации-разработчике, так и вне ее. Например, в организации "лучшие люди" могут быть уже заняты в других проектах. 3. Организация хочет повысить профессиональный уровень своих работников. В этом слу- чае она может привлечь к участию в проекте неопытных или недостаточно квалифици- рованных работников, чтобы они приобрели необходимый опыт и поучились у более опытных специалистов. Таким образом, почти всегда подбор специалистов для выполнения проекта имеет опре- деленные ограничения и не является свободным. Вместе с тем необходимо, чтобы хотя бы не- сколько членов группы разработчиков имели квалификацию и опыт, достаточные для работы над данным проектом. В противном случае невозможно избежать ошибок в разработке ПО. Руководитель проекта обычно обязан посылать отчеты о ходе его выполнения как заказ- чику, так и подрядным организациям. Это должны быть краткие документы, основанные на информации, извлекаемой из подробных' отчетов о проекте. В этих отчетах должна быть та информация, которая позволяет четко оценить степень готовности создаваемого программного продукта. В рамках курса «Технология разработки программного обеспечения» выделены следу- ющие роли в группе по разработке ПО: Руководитель – общее руководство проектом, написание документации, общение с за- казчиком ПО Системный аналитик – разработка требований (составление технического задания, про- екта программного обеспечения) Тестер – составление плана тестирования и аттестации готового ПО (продукта), состав- ление сценария тестирования, базовый пример, проведение мероприятий по плану те- стирования Разработчик – моделирование компонент программного обеспечения, кодирование Планирование проекта разработки программного обеспечения Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предви- деть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий документ, выполне- ние которого должно привести к успешному завершению проекта. Этот первоначальный план должен максимально подробно описывать все этапы реализации проекта. Процесс планирования начинается, исходя из описания системы, с определения проект- ных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием про- ектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документа- ция, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разраба- тывается график работ по выполнению проекта или дается разрешение на продолжение исполь- зования ранее созданного графика. После этого проводится контроль выполнения работ и от- мечаются расхождения между реальным и плановым ходом работ. Далее, по мере поступления новой информации о ходе выполнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к изменению графика работ. Если в результате этих изменений нарушаются сроки завершения проекта, должны быть пересмотрены (и согласованы с заказчиком ПО) проектные ограничения. Конечно, большинство руководителей проектов не думают, что реализация их проектов прой- дет гладко, без всяких проблем. Желательно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять "пессимистические" гра- фики работ, чем "оптимистические". Но, конечно, невозможно построить план, учитывающий 60 все, в том числе случайные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания про- граммного продукта. План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделе- ние работ на этапы и временной график выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все виды планов, описанных выше. В других случаях план проекта описывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатыва- ются отдельно от плана проекта. Детализация планов проектов очень разнится в зависимости от типа разрабатываемого программного продукта и организации-разработчика. Но в любом случае большинство планов содержат следующие разделы. 1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, вре- менных и т.д.), которые важны для управления проектом. 2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды. 3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение. 4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программного обеспечения, необходимого для разработки про- граммного продукта. Если аппаратные средства требуется закупать, приводится их сто- имость совместно с графиком закупки и поставки. 5. Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные про- цессы, определяются этапы выполнения проекта, приводится описание результатов ("выходов") каждого этапа и контрольные отметки. 6. График работ. В этом графике отображаются зависимости между отдельными процес- сами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам. 7. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые руководителем отчеты о ходе выполнения работ, сроки их предостав- ления, а также механизмы мониторинга всего проекта. План должен регулярно пересматриваться в процессе реализации проекта. Одни части плана, например, график работ, изменяются часто, другие более стабильны. Для внесения из- менений в план требуется специальная организация документопотока, позволяющая отслежи- вать эти изменения. Ход работы 1. Составить подробное описание информационной системы. 2. На основании описания системы провести анализ осуществимости. В ходе анализа отве- тить на вопросы: Что произойдет с организацией, если система не будет введена в эксплуатацию? Какие текущие проблемы существуют в организации и как новая система поможет их решить? Каким образом система будет способствовать целям бизнеса? Требует ли разработка системы технологии, которая до этого не использовалась в орга- низации? Результатом анализа должно явиться заключение о возможности реализации проекта. 4. Распределить роли в группе (руководитель проекта-разработчик, системный аналитик- разработчик, тестер-разработчик). 5. Заполнить разделы плана: Введение Организация выполнения проекта Анализ рисков 61 Разделы должны содержать рекомендации относительно разработки системы, базовые предложения по объёму требуемого бюджета, числу разработчиков, времени и требуемому про- граммному обеспечению. Практическая работа № 4.14. Анализ рисков Цель работы: анализ рисков информационной системы\ Теоретический материал 1 Идентификация рисков 1.1 Риск утери информации о клиентах риск информационный потеря безубыточность Так как внедрено программное обеспечение, в котором хранится вся информация о кли- ентах и данных компании, имеется риск потери этих данных, несанкционированный доступ к ним, вследствие чего возможна кража конфиденциальной информации о клиентах, а так же блокировка абонементов, что понесет существенные убытки компании. Данный риск относится к информационным рискам. В результате воздействия этого со- бытия на обрабатываемую, хранящуюся или передаваемую информацию может произойти ее искажение, подделка, утечка, хищение, потеря, т.е. собственнику, владельцу информационных ресурсов может быть нанесен ущерб. 1.2 Риск отказа работы ПО на длительное время Так же имеет место быть риск отказа работы ПО, что несет за собой временное отсут- ствие доступа ко всем данным, в том числе и бухгалтерским. В результате этого бухгалтер не сможет совершать никаких операций. Например, для бухгалтера будет недоступна подача дан- ных в налоговую инспекцию, что повлечет за собой начисления штрафных санкции для орга- низации, а так же может привести к лишению лицензии фитнес-клуба. Так же, в результате воздействия этого риска, бухгалтер не сможет начислить сотрудни- кам заработную плату. Нестабильные выплаты заработной платы портят репутацию компании и ведут к уволь- нению сотрудников. Данный риск относится к производственным рискам, связанным с убытками от оста- новки производства или коммерческой деятельности либо предоставления услуг в сфере ин- форматизации вследствие воздействия различных факторов, прежде всего, связанных с утратой или повреждением информации. 2 Оценка рисков Оценка рисков производится по качественному и количественному методам. Обычно считается, что риск тем больше, чем больше вероятность происшествия и тя- жесть последствий, т.е. наблюдается зависимость от двух факторов: вероятности происшествия и тяжести возможных последствий. 2.1 Риск утери информации о клиентах Сначала необходимо определить значения шкал. Значения субъективной шкалы вероят- ностей происшествия равно C – вероятность события – около 0,5. Значения субъективной шкалы серьезности последствий равно Mo (Moderate – умерен- ный, средний) – происшествие с умеренными результатами: ликвидация последствий не свя- зана с крупными затратами, воздействие на информационную технологию небольшое и не за- трагивает критически важных задач. По матрице результатов оценивания рисков строится гра- фик. Ход работы Задание 1. Общая стоимость компании составляет 2 000 000 руб. Риск утери данных мо- жет нанести ущерб с фактором воздействия 50%. Вероятность происшествия – раз в 5 лет, т.е. 0,5. Расчет цены потерь (Q) производится по формуле 1. 62 Q = K * С, (1) К – Общая стоимость компании С – фактор воздействия риска Q = 2 000 000 * 0,5 = 1 000 000 рублей. Величина риска (R) в данной ситуации зависит от двух факторов и считается по формуле R = P * Q (2) Р – Вероятность наступления риска R = 0,5 * 1 000 000 = 500 000 рублей, т.е. существует риск потери такой суммы ежегодно. Задание 2. Риск потери информации в результате отказа работы ПО на длительное время Значения субъективной шкалы вероятностей происшествия равно B – событие случается редко. Значения субъективной шкалы серьезности последствий равно C (Critical – критический) – происшествие приводит к невозможности решения критически важных задач. По матрице результатов оценивания рисков строится график Общая стоимость компании составляет 2 000 000 руб. Риск утери данных может нанести ущерб с фактором воздействия 95%. Вероятность происшествия – раз в 10 лет, т.е. 0,1. Расчет цены потерь производится по формуле 1. Q = 2 000 000 * 0,95 = 1 900 000 рублей. Величина риска в данной ситуации зависит от двух факторов и считается по формуле 2. R = 0,1 * 1 900 000 = 190 000 рублей, т.е. существует риск потери такой суммы ежегодно. Рекомендации по минимизации рисков Планирование рисков подразумевает их уменьшение за счет принятия некоторых мер, например, грамотное управление паролями снижает риск несанкционированного доступа (НСД). Для минимизации риска отказа ПО, необходима постоянная его техническая поддержка, которая производится компанией на аутсорсинге. Если не удается уклониться от риска или эффективно его уменьшить, можно принять некоторые меры страховки, например, заключить договор с поставщиками ПО о сопровожде- нии и компенсации ущерба, вызванного нештатными ситуациями. Практическая работа № 4.15. Выявление первичных и вторичных ошибок Цель работы: способы выявление первичных и вторичных ошибок. Теоретический материал Неоднократно экспериментально установлено, что в любом сложном комплексе про- грамм в процессе эксплуатации обнаруживаются ошибки[Липаев_3], даже если проведено са- мое тщательное тестирование. Важной особенностью тестирования программ является невоз- можность получения полностью определенной абсолютно корректной программы, которую можно было бы использовать в качестве эталона без ошибок для сравнения с ней создаваемой программы. Поэтому при тестировании первоначально обнаруживаются вторичные ошибки, которые являются отклонениями некоторых результатов функционирования программ от пред- полагаемых эталонных значений. Тестирование для локализации ошибки позволяет установить причину вторичной ошибки и выявить первичную ошибку, подлежащую исправлению. Первичные ошибки в программах в различной степени искажают результаты, которые первоначально обнаруживаются как вторичные ошибки, в процессе тестирования. Каждая пер- вичная ошибка k-го типа отражается как вторичная ошибка j-го результата с некоторым коэф- фициентом пропорциональности Dkj. Если в некоторый момент тестирования имеющиеся пер- вичные ошибки характеризуются вероятностями проявления Qk, то они будут приводить к ин- тегральным вторичным ошибкам с интенсивностью (весом), рассчитываемой как 63 где m— полное число возможных типов ошибок в программах; q— полное число контролируемых результатов, в которых могут проявляться вторичные ошибки. Однако прямыми измерениями невозможно установить коэффициент влияния первич- ных ошибок на вторичные Dk j, а также вероятность первичных ошибок Qk. Поэтому исследо- ваны, в основном, обобщенные характеристики вторичных ошибок и некоторые общие законо- мерности проявления первичных ошибок в процессе тестирования программ. В результате анализа и обобщения экспериментальных данных предложено несколько математических моделей, описывающих основные закономерности изменения суммарного числа вторичных ошибок в программах. Эти модели предназначены для оценки: возможного изменения надежности функционирования в процессе отладки, испытаний и эксплуатации; числа ошибок, оставшихся не выявленными в тестируемых программах; времени, требующе- гося для обнаружения следующей ошибки в функционирующей или тестируемой программе; времени, необходимого для выявления всех ошибок с заданной вероятностью. Точное определение полного числа не выявленных ошибок в ПО прямыми методами из- мерения невозможно, поскольку в противном случае их можно было бы все зафиксировать и устранить. Однако имеются косвенные пути для приближенной статистической оценки их пол- ного числа или вероятности ошибки в каждой команде программы. Такие оценки базируются на построении математических моделей в предположении жесткой корреляции между общим числом ошибок и их проявлениями в некотором ПО после его отладки в течение времени t, т.е. между следующими параметрами: суммарным числом первичных ошибок в ПО (n0) или вероятностью ошибки в каждой команде программы (p0): числом вторичных ошибок, выявляемых в единицу времени в процессе тестирования и отладки при постоянных усилиях на ее проведение (dn/dt); интенсивностью искажений результатов в единицу времени (l) на выходе программы (вследствие невыявленных первичных ошибок) при функционировании системы в типовых условиях. В результате может быть построена экспоненциальная математическая модель распре- деления ошибок в программах и установлена связь между интенсивностью обнаружения вто- ричных ошибок при тестировании dn/dt, интенсивностью l проявления ошибок при нормальном функционировании ПО и числом выявленных первичных ошибок n. При этом учитываются все виды ошибок независимо от источников их происхождения (технологические, программные, алгоритмические, системные). При постоянных усилиях на тестирование интенсивность обнаружения искажений и вы- числительного процесса, программ или данных вследствие еще невыявленных ошибок пропор- циональна числу n0оставшихся первичных ошибок в ПО. Тогда dn/dt= К'l = Кn0=K(N0 – n), где N0— число ошибок в ПО в начале отладки, а коэффициенты К и К' учитывают: мас- штаб времени, используемого для описания процесса обнаружения ошибок, быстродействие ЭВМ, распределение тестовых значений на входе проверяемого комплекса программ и другие параметры. Значение коэффициента К' можно, в принципе, определить как изменение темпа проявления ошибок при переходе от функционирования программ на специальных тестах к функционированию на нормальных типовых исходных данных. Так как предполагается, что в начале отладки при t= 0 отсутствуют обнаруженные ошибки, то n = N0 [1 – exp(-Кt)]. Число оставшихся первичных ошибок в ПО n0 = N0 exp(-Кt), пропорционально интен- сивности обнаружения dn/dt с точностью до коэффициента К. Длительность функционирования программ (наработка) между проявлением ошибок, которые рассматриваются как обнаруживаемые искажения программ, данных или вычисли- тельного процесса, равна величине, обратной интенсивности обнаружения ошибок 64 Если известны все моменты обнаружения ошибок tiи каждый раз в эти моменты обнару- живается и достоверно устраняется одна первичная ошибка, то, используя метод максималь- ного правдоподобия, можно получить уравнение для определения значения начального числа первичных ошибок N0 а также выражение для расчета коэффициента пропорциональности В результате можно рассчитать число оставшихся в программе первичных ошибок и среднюю наработку Т до обнаружения следующей ошибки. С помощью преобразований можно получить затраты времени на тестирование, которые позволяют устранить dn ошибок и соот- ветственно повысить наработку между очередными обнаружениями ошибок от значения Т1 до Т2 Необходимо подчеркнуть статистический характер приведенных соотношений. Нерав- номерность выбора маршрутов исполнения программы при нормальной эксплуатации, разное влияние конкретных типов ошибок в программах на проявление их при функционировании, а также сравнительно небольшие значения n и dn, особенно на заключительных этапах отладки приводят к тому, что затраты времени на тестирование могут быть весьма значительными. |