Управление ресурсами в ЖЦ ПС. Дефекты, ошибки и риски в ЖЦ ПС Лекция 5
Основные ресурсы для обеспечения ЖЦ сложных ПС Доступные ресурсы обеспечения жизненного цикла ПС – реальные финансовые, временные, кадровые и аппаратурные ограничения затрат, в условиях которых происходит создание и совершенствование комплексов программ Основная задача при проектировании ПС – экономический анализ и определение необходимых ресурсов для создания и обеспечения всего ЖЦ ПС в соответствии с требованиями контракта и технического задания. Наиболее общим видом ресурсов, используемых в жизненном цикле ПС, являются допустимые финансово-экономические затраты или эквивалентные им величины трудоемкости соответствующих работ Затраты в жизненном цикле ПС определяются не только этапами разработки, но и этапами эксплуатации и сопровождения. 2
Затраты 3
Ресурсы Важнейший ресурс – специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Время или допустимая длительность разработки определенных компонентов и версий ПС является невосполнимым ограниченным ресурсом реальных проектов. Доступные разработчикам ПС вычислительные ресурсы объектных и технологических ЭВМ являются одним из важнейших факторов, определяющим достижимое качество сложных ПС. Обобщенными ресурсами ЖЦ проекта ПС являются доступные стоимость или совокупные трудовые, временные и материальные затраты, необходимые для приобретения, создания, модификации и эксплуатации компонентов и всего комплекса программ. При экономическом анализе ресурсов проектов ПС возможны два сценария: • создание и весь жизненный цикл комплекса программ и/или базы данных ориентируется разработчиком на массовое тиражирование и распространение на рынке, для заранее не известных покупателей пользователей в различных сферах применения, при этом отсутствует приоритетный внешний потребитель заказчик, который определяет и диктует основные требования, а также финансирует проект; • разработка проекта ПС и/или БД предполагается поставщиком разработчиком для конкретного потребителя заказчика, задающего требования, который его финансирует, с определенным, необходимым ему тиражом и известной, ограниченной областью применения результатов разработки. 4
5
Технико экономические показатели Принципиальным путем улучшения ТЭП при разработке сложных ПС – исключение творчества на тех этапах, где возможны типовые, стандартные решения и апробированные заготовки, не требующие при их применении высококвалифицированного творческого труда. Основой такого подхода является применение унифицированной технологии, готовых испытанных компонентов и стандартизированной архитектуры определенных классов ПС. Использование готовых апробированных модулей почти исключает творческий труд по их программированию, автономной отладке и документированию. «Вряд ли можно ожидать в ближайшие годы повышения производительности труда на порядок при создании полностью новых, сложных программных продуктов. Еще более консервативна длительность таких разработок. » 6
Реализация сложных проектов ПС Схемы организации коллективов специалистов: 1) формирование для выполнения каждого проекта жесткой организационной структуры целостного коллектива с полным составом необходимых специалистов под единым, централизованным руководством лидера проекта (фирма реализует небольшое число особенно крупных проектов заказов и имеет возможность для каждого из них скомплектовать полноценную, организационно замкнутую, “команду”); 2) выделение руководителя (главного конструктора) и небольшой группы интеграторов, по заданиям которых выполняются частные работы узкими специалистами по компонентам, не входящими организационно в единый коллектив для реализации каждого конкретного крупного проекта (фирма реализует большое число относительно небольших проектов, близких по содержанию и функциональному назначению компонентов). 7
Лидер проекта Лидером продукта может быть: менеджер продукта, менеджер проектирования, руководитель проекта. Лидер должен: • руководить процессом выявления и формирования требований заказчика; • рассматривать конфликтующие пожелания, поступающие от различных участников проекта и находить компромиссы, необходимые для определения набора функций, представляющих наибольшую ценность для максимального числа участников; • вести переговоры с заказчиком, руководством, пользователями и разработчиками и поддерживать равновесие между тем, чего хочет заказчик, и тем, что может предоставить команда разработчиков за ресурсы и время, отведенные заказчиком для реализации проекта; • осуществлять проверку спецификаций программного средства, чтобы удостовериться, что они соответствуют реальной концепции, представленной детальными функциями; • осуществлять управление изменением приоритетов задач, а также добавлением и исключением функций. Чтобы добиться успеха в большом проекте, необходима четкая координация действий “команды”. 8
Специалисты 1) разработчики компонент и ПС в целом: • спецификаторы; • разработчики программных компонентов программисты; • системные интеграторы; • тестировщики; • управляющие сопровождением и конфигурацией, инструкторы интерфейсов; • документаторы процессов и объектов ЖЦ ПС 2) обеспечивающие технологию и качество программного продукта: • технологи; • специалисты, управляющие обеспечением качества ПС; • инспекторы-испытатели по проверке систем качества; Особенно важна не индивидуальная характеристика каждого специалиста, а, прежде всего, интегральный показатель квалификации “команды” При низкой тематической квалификации допускаются наиболее грубые системные ошибки, требующие больших затрат при доработке программ или даже делающие проект практически не реализуемым. 9
Характеристики и влияние коллективизма разработчиков ПС на трудоемкость 10
Общение в «команде» Совещания предоставляют заинтересованным специалистам из различных команд и организаций возможность работать вместе над достижением общей цели крупного проекта. Специалист, ведущий встречи играет ключевую роль в успехе совещания и должен: • установить правила проведения встречи и добиваться их выполнения; • управлять течением дискуссии и удерживать команду на главной цели совещания; • способствовать процессу принятия решения и достижения консенсуса, но избегать участия в содержательной части дискуссии; • удостовериться, что все заинтересованные лица участвуют и их пожелания учтены; • контролировать поведение участников, которое может привести к расколу или мешает продуктивной работе. Следует активно привлекать заказчиков к совещаниям, управлению их требованиями и масштабом проекта, чтобы обеспечить как качество, так и своевременность разработки ПС. Для защиты, как проекта, так и бизнес целей заказчика может понадобиться вести переговоры об объеме работ для команды 11
Ресурсы для обеспечения функциональной пригодности Для рационального распределения этих ресурсов необходимо знать как отражается изменение затрат на улучшении каждой характеристики качества ПС. Обеспечение функциональной пригодности является основной целью при использовании финансовых, трудовых, вычислительных и других ресурсов в жизненном цикле ПС. Обычно трудно четко выделить и количественно оценить все виды затраты, используемые только на функциональную пригодность. Для анализа затрат ресурсов в жизненном цикле ПС при проектировании, их целесообразно разделить на две части: • затраты на создание программных компонентов, обеспечивающих базовые свойства функциональной пригодности комплекса программ для его применения по прямому назначению пользователями, в соответствии с требованиями контракта и технического задания; • основные составляющие дополнительных затрат, обеспечивающие требуемые конструктивные характеристики качества для улучшения функциональной пригодности ПС в соответствии с целями и сферой его применения. Необходимо также учитывать совокупность затрат ресурсов на технологию, инструментарий автоматизации разработки и систему качества, обеспечивающие жизненный цикл ПС. Для учета классов крупномасштабных ПС с позиции затрат на их разработку проведено ранжирование экспериментальных данных и выделены классы (см. ISO 12182). Основные составляющие дополнительных затрат, целесообразно структурировать в соответствии с их номенклатурой в стандарте ISO 9126 12
Крупные затраты 30% от полных затрат на разработку сложных ПС, могут приходиться на верификацию и тестирование программных компонентов, что должно обеспечивать корректность и надежность ПС в целом. Затраты на квалификационное тестирование и испытания ПС в целом обычно могут быть достаточно четко выделены из остальных ресурсов, так как в этих процессах непосредственно участвуют заказчик и пользователи Затраты на обеспечение безопасности и надежности функционирования ПС определяются требуемым уровнем защищенности и сложностью (размером) программ для ее реализации Затраты на создание достаточно полного комплекта документации практически пропорциональны размеру комплекса программ. Затраты на обеспечение и реализацию требований к характеристикам: защищенности, сопровождаемости, мобильности и практичности (последние в части документирования) ПС. При анализе затрат на обеспечение требуемых функций крупномасштабных ПС доминирующим фактором, влияющим на их величину, является сложность функциональной части комплекса программ и базы данных. 13
Ресурсы на реализацию конструктивных характеристик качества ПС Приводимые экспертные оценки относятся к разработке полностью нового, крупного ПС, без использования готовых программных компонентов. Анализ затрат на обеспечение корректности зависит от полноты прослеживания реализации требований к ПС сверху вниз, в требованиях к компонентам вплоть до объектного кода программ и от степени их покрытия тестами (могут составлять до 20% 30% от затрат на обеспечение первичной, функциональной пригодности). Затраты на взаимодействие программных средств и их компонентов с внутренней и внешней средой определяются сложностью (объемом) программ и затратами (затраты на визуализацию информации, телекоммуникацию ) производительности ЭВМ, реализующими эти функции (могут составлять до 10 – 20% затрат на обеспечение основных функций ПС). Особенности затрат на реализацию остальных требований к конструктивным характеристикам качества отмечаются при представлении соответствующих характеристик и сводятся к: • • • дополнительные затраты на обеспечение высокой надежности ПС могут достигать 2 – 3 кратного увеличения затрат относительно функциональной пригодности при требованиях наработки на отказ в десятки тысяч часов, а для минимального обеспечения автоматического рестарта в ординарных системах составляют порядка 10 – 20%; для повышения эффективности использования ресурсов ЭВМ затраты могут быть относительно невелики (несколько процентов) и их трудно выделить из затрат на решение основных, функциональных задач; затраты на обеспечение практичности зависят в основном от сложности применения ПС, от качества и количества эксплуатационной документации и электронных учебников и могут составлять до 20% затрат на решение основных, функциональных задач. 14
Ресурсы на реализацию конструктивных характеристик качества ПС Мобильность и затраты конкретных ресурсов для переноса программ и данных на иные аппаратные и операционные платформы при проектировании могут быть учтены, только очень приблизительно. Любой перенос связан с затратами. Субхарактеристики включают адаптируемость, простоту установки и замещаемость программ. Их целесообразно оценивать количественно: совокупными затратами, стоимостью, трудоемкостью и длительностью на реализацию процедур переноса программ и данных. Оценки мобильности зависят от внутренних субхарактеристик ПС, от организации, технологии и документирования реализации жизненного цикла и процессов переноса комплексов программ и их компонентов. Требования мобильности компонентов ПС приводят к необходимости их проектирования как автономных комплектующих изделий. В пределе при построении нового ПС на 80 90% из готовых компонентов суммарные затраты могут сокращаться в 3 5 раз. 15
Ресурсы на имитацию внешней среды для обеспечения тестирования и испытаний ПС Ресурсы на генерацию тестов соизмеримы с затратами на создание основных функций комплексов программ, что определяется принципиальным соответствием сложности необходимых наборов тестов и тестового покрытия программ, и сложности функций, реализуемых испытываемым ПС. Возникает проблема какой метод и когда выгодней по затратам на генерацию тестов и по обеспечению необходимой степени покрытия тестами испытываемых ПС. Анализ эффективности программной имитации внешней среды целесообразно разделить на две части: 1) оценка факторов, определяющих эффективность средств имитации тестов, 2) оценка экономического выигрыша при моделировании внешней среды на ЭВМ по сравнению с натурными экспериментами в реальных системах. Экономическую эффективность программной имитации внешней среды на ЭВМ целесообразно оценивать при одинаковых объемах тестовых данных для испытаний и определения качества ПС. Показателем экономической эффективности имитации может служить соотношение затрат ресурсов на проведение натурных экспериментов и затрат на программную имитацию той же совокупности тестовых и эталонных данных. 16
Дефекты, ошибки и риски в ЖЦ ПС Статистика ошибок и дефектов в комплексах программ и их характеристики в конкретных типах проектов ПС, могут служить ориентирами для разработчиков при распределении ресурсов в жизненном цикле ПС и предохранять их от излишнего оптимизма при оценке достигнутого качества программных продуктов. Возможно выделить предсказуемые модификации, расширения и совершенствования ПС и изменения, обусловленные выявлением случайных, непредсказуемых дефектов и ошибок. К понятию риски относятся негативные события и их величины, отражающие потери, убытки или ущерб от процессов или продуктов, вызванные дефектами проектировании требований, недостатками обоснования проектов ПС, а также при последующих этапах разработки, реализации и всего жизненного цикла комплексов программ. Понятие ошибки в программе – в общем случае под ошибкой подразумевается неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба – риска при функционировании и применении программы. При отладке и тестировании обычно сначала обнаруживаются вторичные ошибки и риски т. е. последствия и результаты проявления некоторых внутренних дефектов или некорректностей программ. Эти внутренние дефекты следует квалифицировать как первичные ошибки или причины обнаруженных аномалий результатов. 17
Дефекты, ошибки и риски в ЖЦ ПС Последующая локализация и корректировка таких первичных ошибок должна приводить к устранению ошибок, первоначально обнаруживаемых в результатах функционирован ия программ. 18
Виды ошибок Интенсивность проявления и обнаружения вторичных ошибок наиболее велика на этапе активного тестирования и автономной отладки программных компонентов. Затем она снижается приблизительно экспоненциально Небольшими ошибками называют такие, на которые средний пользователь не обратит внимания применении ПС, вследствие отсутствия их проявления, и последствия которых обычно так и не обнаруживаются. Умеренными ошибками называют те, которые влияют на конечного пользователя, но имеются слабые последствия или обходные пути, позволяющие сохранить достаточную функциональность ПС. Критические ошибки останавливают выпуск версии программного продук та. Это могут быть ошибки с высоким влиянием, которые вызывают сбой в системе или потерю данных, отражаются на надежности и безопасности применения ПС. Совокупность ошибок, дефектов и последствий модификаций проектов крупномасштабных комплексов программ можно упорядочить и условно представить в виде перевернутой пирамиды в зависимости от потенциальной опасности и возможной величины корректировок их последствий 19
20
Ошибки реализации 21
22
Предотвращение ошибок Первичные ошибки в программах проектов можно анализировать с разной степенью детализации и в зависимости от различных факторов. Практический опыт показал, что наиболее существенными факторами, влияющими на характеристики обнаруживаемых ошибок являются: • методология, технология и уровень автоматизации системного и структурного проектирования ПС, а также непосредственного программирования компонентов; • длительность с начала процесса тестирования и текущий этап разработки или сопровождения и модификации комплекса программ; • класс ПС, масштаб (размер) и типы компонентов, в которых обнаруживаются ошибки; • методы, виды и уровень автоматизации верификации и тестирования, их адекватность характеристикам компонентов и потенциально возможным в программах ошибкам; • виды и достоверность эталонов тестов, которые используются для обнаружения ошибок. 23
Первичные ошибки в ПС в порядке уменьшения их влияния на сложность обнаружения и масштабы корректировок можно разделить на следующие группы: • ошибки, обусловленные сложностью компонентов и ПС в целом и наиболее сильно влияющие на размеры модификаций; • ошибки вследствие большого масштаба – размера комплекса программ, а также высоких требований к его качеству; • ошибки планирования и корректности требований модификаций часто могут быть наиболее критичным для общего успеха ЖЦ ПС и системы; • ошибки проектирования, разработки структуры и функций ПС в более полные и точные технические описания сценариев того, как комплекс программ и система будут функционировать; • системные ошибки, обусловленные отклонением функционирования ПС в реальной системе, и характеристик внешних объектов от предполагавшихся при проектировании; • алгоритмические ошибки, связанные с неполным формированием необходимых условий решения и некорректной постановкой целей функциональных задач; • ошибки реализации спецификаций изменений – программные дефекты, возможно, ошибки нарушения требований или структуры компонентов ПС; • программные ошибки, вследствие неправильной записи текстов программ на языке программирования и ошибок трансляции текстов изменений программ в объектный код; • ошибки в документации, которые наиболее легко обнаруживаются и в наименьшей степени влияют на функционирование и применение версий ПС; • технологические ошибки подготовки физических носителей и документации, а также ввода программ в память ЭВМ и вывода результатов на средства отображения. 24
Показатели сложности ошибок 1) сложность ошибок при создании корректировок компонентов и комплекса программ статическая сложность, когда реализуются его требуемые функции, вносятся основные дефекты и ошибки: • величина – размер модифицируемой программы, выраженная числом строк текста, функциональных точек или коли чеством программных модулей в комплексе; • количество обрабатываемых переменных или размер и структура памяти, используемой для размещения базы данных корректировок; • трудоемкость разработки изменений комплекса программ; • длительность разработки и реализации корректировок; • число специалистов, участвующих в ЖЦ комплекса программ. 2) сложность проявления ошибок функционирования программ и получения результатов динамическая сложность, когда проявляются дефекты и ошибки, отражающиеся на функциональном назначении, рисках и качестве применения версии ПС: • сложность ошибок изменяемых программных компонентов и модулей; • сложность ошибок корректировок структуры комплекса; • сложность ошибок изменения структуры данных. 25
Иные ошибки • • Ошибки корректности формирования и планирования выполнения требований к ПС являются наиболее трудными для обнаружения и наиболее сложными для исправления. Ошибки проектирования и разработки структуры ПС определяются процессами перевода неопределенных и общих положений, сделанных на стадии спецификаций требований, в более точные технические описания сценариев того, как измененные ПС и система должны работать. Три категории: пропуски, конфликты и ошибки перевода. Системные ошибки в ПС определяются, прежде всего, неполной информацией о реальных процессах, происходящих в источниках и потребителях информации. Алгоритмические ошибки программ (ошибки, обусловленные некорректной постановкой требований к функциональным задачам, ошибки, обусловленные не полным учетом всех условий решения задач, ошибки интерфейса модулей и функциональных групп программ, просчеты в использовании доступных ресурсов вычислительной системы в системах реального времени) Ошибки реализации спецификаций компонентов – это программные дефекты, возможно, ошибки требований, структуры или программные ошибки компонентов. Программные ошибки модифицированных компонентов по количеству и типам в первую очередь определяются степенью автоматизации программирования и глубиной статического контроля текстов программ. Ошибки в документации модификаций состоят в том, что система делает что то одним образом, а документация отражает сценарий, что она должна работать иначе. Технологические ошибки документации и фиксирования программ в памяти ЭВМ составляют иногда до 10% от общего числа ошибок обнаруживаемых при тестировании. Большинство технологических ошибок выявляется автоматически статическими методами. 26
Риски в жизненном цикле сложных ПС Причинами возникновения и проявления рисков могут быть: злоумышленные, активные воздействия заинтересованных лиц или случайные негативные проявления дефектов внешней среды, системы или пользователей. Управления рисками предполагает ясное понимание внутренних и внешних причин и реальных источников угроз, влияющих на качество проекта ПС, которые могут привести к его провалу или большому ущербу. 27
28
Скачать презентацию Управление ресурсами в ЖЦ ПС Дефекты ошибки и
ПИ_Лекция 5 Управление ресурсами в ЖЦ ПС.pptx