1. Рес-сы спец-тов для обеспечения жц сложных пс.

Важнейшим ресурсом при создании ПС являются люди – спец-ты, с их уровнем профес-ной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Быстрый рост сложности и повышение ответственности за качество комплексов программ привели к появлению новых требований к спец-там ПИ, обеспечивающим все этапы ЖЦ ПС. Теперь недостаточно навыков процедурного программирования небольших компон-в, а необходимы глубокие знания системотехники, технологии проектир-я, методов обеспечения и контроля кач-ва сложных комплексов программ в определенной области применения. Эти спец-ты должны владеть новой интеллектуальной профессией, обеспечивающей высокое качество ЖЦ ПС, а также контроль, испытания и удостоверение реального достигнутого кач-ва на каждом этапе разработки и совершенствования программ.

При проектировании и создании высококачественных комплексов программ, прежде всего, необходима организация и тесное взаимодействие представителей заказчика и разработчиков проекта.

Для реализации сложных проектов ПС наиболее часто применяются 2 схемы орг-ии коллективов спец-тов:

• формир-е для выполнения каждого проекта жесткой орг-ной стр-ры целостного коллектива с полным составом необходимых спец-тов под единым, централиз-ным руководством лидера проекта;

• выделение руководителя и небольшой группы интеграторов, по заданиям кот выполняются частные работы узкими спец-ми по компонентам, не входящими организационно в единый коллектив для реализации каждого конкретного крупного проекта.

Практически в каждом успешном проекте должен быть или был лидер. Лидером продукта может быть: менеджер продукта, менеджер проектир-я, руководитель проекта.

Руководство крупным проектом ПС должны осуществлять 1 или 2 менеджера:

• менеджер проекта  этот спец-т, обеспечивающий коммуникацию между заказчиком и проектной командой;

• менеджер-архитектор комплекса программ  управляет коммуникациями и взаимоотношениями в проектной команде, является координатором создания компон-в, разрабатывает базовые, функциональные спецификации и управляет ими, ведет график проекта и отчитывается за его состояние, инициирует принятие критичных для хода проекта решений.

Спец-ты первой категориинепосредственно создают компоненты и ПС в целом с заданными показателями кач-ва.

Разделение труда спец-тов этой категории в крупных проектных коллективах приводит к необходимости их дифференциации по квалификации и областям деятельности:

• спецификаторы подготавливают описания фун-ий соответ-щих компон-в с уровнем детализации, достаточным для корректной разработки текстов программ программистами и их интерфейсов;

• разработчики програм-х компон-в  программисты создают компоненты, удовлетворяющие спецификациям, реализуют возможности продукта, отслеживают и исправляют ошибки, при разработке сложных систем это требует детального знания высокоуровневых языков программирования, визуального программирования, сетевых технологий и проектир-я баз данных;

• системные интеграторы сложных проблемно-ориентированных ПС работают над проектами в значительной степени отличными от программистов методами, на разных языках проектир-я, используют различные средства автоматизации и имеют на выходе различные результаты крупных компон-в и комплексов программ;

• тестировщики обеспечивают проверку функц-х спецификации, систем обеспечения произв-ти, пользовательских интерфейсов, разрабатывают стратегию, планы и выполняют тестир-е для каждой из фаз и компонента проекта, должны быть административно независимыми от программистов и спецификаторов;

• управляющие сопровождением и конфигурацией, инструкторы интерфейсов отвечают за снижение з-т на модификацию и сопровождение продукта, обеспечение максимальной эф-ти работы разработчиков по взаимодействию компон-в и реализации версий ПС, принимают участие в обсуждениях пользовательского интерфейса и архитектуры продукта;

• документаторы процессов и объектов ЖЦ ПС обеспечивают подготовку и издание сводных технологических и эксплуатационных документов в соответствие с требованиями стандартов.

Спец-ты второй категории  технологи, обслуживающие и сопровождающие технологический инструментарий, который применяется спец-ми первой категории, обеспечивают применение системы кач-ва проекта или предприятия, контролируют и инспектируют ее использование. Осн задачи второй категории спец-тов должны быть сосредоточены на контроле процессов и результатов выполнения работ и на принятии организационных и технологических мер для достижения их необходимого кач-ва, обеспечивающего выполнение всех требований технического задания на ПС.

Технологи должны выбирать, приобретать и осваивать наиболее эф-ный инструментарий для проектов, реализуемых конкретной фирмой с учетом особенностей создаваемых ПС требуемого кач-ва и рентабельности технологических средств. Они должны разрабатывать регламентированный технологический процесс и систему кач-ва, поддерживающие весь ЖЦ ПС и обучать разработчиков ПС квалифицированному применению соответ-щих инструментальных средств и технологий.

Спец-ты, управляющие обеспечением кач-ва ПС, должны овладеть стандартами и методиками фирмы, поддерживающими регистрацию, контроль, документирование и воздействия на показатели кач-ва на всех этапах ЖЦ программ. Они должны обеспечивать эксплуатацию системы кач-ва проекта, выявление всех отклонений от заданных показателей кач-ва объектов и процессов, а также от предписанной технологии на промежуточных и заключительных этапах разработки. Эти же спец-ты должны анализировать возможные последствия выявленных отклонений от требований технического задания или спецификации на ПС. В результате должны приниматься меры либо по устранению отклонений, либо по корректировке требований, если устранение отклонений требует чрезвычайно больших рес-в.

Инспекторы-испытатели по проверке систем кач-ва предприятия и кач-ва ППдолжны пройти обучение, дающее им знания и квалификацию, необходимые для проведения испытаний, оценки их результатов и эф-ти применения систем кач-ва.

2. Принципы верификации и тестир-я программ.

Верификация  это процесс для опр-я, выполняют ли ПС и их компоненты требования, наложенные на них в последовательных этапах ЖЦ ПС. Анализ, просмотры и тестир-е от требований являются важнейшей частью верификации и установления корректности программ. Основная цель верификации ПС состоит в том, чтобы обнаружить, зарегистрировать и устранить дефекты и ошибки, кот внесены во время последовательной разработки или модификации программ. Для эф-ти з-т рес-в при ее реализации, верификация должна быть интегрирована как можно раньше с процессами проектир-я, разработки и сопровождения. Обычно она проводится сверху вниз, начиная от общих требований, заданных в техническом задании и/или спецификации на всю информационную систему до детальных требований на программные модули и их взаимодействие.

Тестир-е ПС от требований имеет две взаимодополняющие цели. Первая цель  показать, что ПС удовлетворяет заданным требованиям к нему. Вторая цель  показать с высокой степенью доверия, что устранены дефекты и ошибки, кот могли бы привести к возникновению недопустимых отказовых ситуаций, влияющих на корректность и надежность системы.

Только совместное и систематическое применение различных методов тестир-я позволяет достигать высокое качество функц-ния сложных комплексов программ.

В процессе разработки программ спец-ты должны стремиться охватить тестир-ем функционирование ПС во всей доступной области изменения исходных данных и режимов применения. При этом номенклату­ра и диапазоны варьирования тестов ограничены либо допустимой длительностью подготовки и исполнения тестов, либо вычислительными ресурсами, доступными для использ-я с целью контроля и тестир-я в режиме нормальной эксплуатации. Это отражается на выборе методов тестир-я и последовательности анализа компон-в ПС, объеме применяемых тестов и на глубине тестир-я. На выбор эфф-х методов тестир-я и последовательность их применения в наибольшей степени влияют осн хар-ки тестируемых объектов:

• класс комплекса программ, определяющийся глубиной связи его функц-ния с реальным временем и случайными воздействиями из внешней среды, а также требования к качеству обработки инф-ии и надежности функц-ния;

• сложность или масштаб комплекса программ и его функц-х компон-в, являющихся конечными результатами разработки;

• преобладающие элементы в программах: осуществляющие вычисления сложных выражений и преобразования измеряемых величин или обрабатывающие логические и символьные данные для подготовки и отображения решений.

Тестир-е для обнаружения ошибок имеет целью выявление отклонений результатов функц-ния реальной программы от заданных требований и эталонных значений.

Тестир-я для диагностики и локализации ошибок предназначено для того, чтобы точно установить исходное место искажения программ или данных, являющегося причиной и источником отклонения результатов от эталонов при тестир-ии для обнаружения ошибок.

Методы и стратегии тестир-я програм-х компон-в используются для обработки текстов программ в различной форме и для представления инф-ии о результатах тестир-я в виде удобном для анализа спец-ми. Форма представления и исполнения программы для тестир-я зависит от этапов разработки, уровня языков прог­раммирования, наличия соответ-щих средств автоматизации и других факторов.

Тестир-е потоков управления (стр-ры программы) должно быть начальным этапом, так как при некорректной структуре возможны наиболее грубые искажения выход­ных результатов и даже отсутствие некот из них. Оно состоит в проверке корректности последовательностей передач управления и формирования маршрутов исполнения программы при обработке тестов. Для тестир-я стр-ры прог­рамм в большинстве случаев требуются относительно меньшие з-ты по сравнению с тестир-ем на потоках данных.

Тестир-е потоков данных можно разделить на два этапа. Первый этап тестир-я состоит в анализе обработки данных, оп­ределяющих значения предикатов в операторах выработки логических решений. Эти решения влияют на маршруты обработки инф-ии, что сближает в этой части метод тестир-я потоков данных с тестир-ем стр-ры программы. Второй этап тестир-я обработки данных состоит в проверке вычислений по аналитическим формулам или численных значений результатов в зависимости от числовых или логических значений исходных данных. В качестве эталонов используются результаты ручных или автоматизированных расчетов по тем же или близким по содержанию формулам.

Для обеспечения высокого кач-ва ПП параллельно с верификацией требований и программированием корректировок, целесообразно разрабатывать и верифицировать спецификации и сценарии тестов, отражающие методы и конкретные процедуры проверки реализации изменений этих требований. Тестовые спецификации могут использоваться для проверки согласованности, внутренней непротиворечивости и полноты реализации требований без исполнения программ. Для каждого требования к комплексу программ, его архитектуре, функциональным компонентам и модулям должна быть разработана спецификация тестов, обеспечивающая проверку корректности, адекватности и возможности в последующем реализовать тестир-е компонента на соответствие этому требованию. Такая взаимная проверка фун-ий компон-в, отраженных в требованиях и в спецификациях тестов, обеспечивает повышение их кач-ва, сокращение дефектов, ошибок, неоднозначностей и противоречий.

При тестир-ии программ зачастую оказывается, что не каждое требование в спецификации описано достаточно полно и корректно, чтобы оно могло быть проверено тестами. При разработке тестов на основе таких спецификаций вследствие их возможной неопределенности, может обнаруживаться, что не для каждого требования к программе или данным может быть подготовлен тест. С другой стороны не для каждого теста может оказаться в спецификации адекватное требование на ф-ции ПС. Спецификации тестов должны обеспечивать дополнительный контроль корректности спецификаций требований и верификацию взаимодействия компон-в на соответствующем уровне описания ПС. Независимая разработка спецификаций тестов на основе спецификаций требований, создает базу для обнаружения, какие требования не тестировались или принципиально не могут быть проверены тестир-ем. Таким образом, верификация спецификаций требований на программные компоненты и ПС могут использоваться с двумя целями:

• для разработки, программирования и проверки текстов программ и интерфейсов взаимодействия програм-х компон-в разных уровней в комплексе программ;

• для создания скоординированного комплекса тестов для совокупности компон-в, обеспечивающих взаимную проверку реализации спецификаций требований на комплекс программ и компоненты.

Билет 21

1. Структурное проектирование сложных ПС

При разработке стр-ры ПС в процессе системного проектир-я, прежде всего, необходимо сформулировать критерии её формирования. Важнейшими критериями могут быть: модифицируемость, отлаживаемость и удобство управления разработкой ПС, обеспечение возможности контролируемого изменения конфигурации, состава и фун-ий компон-в с сохранением целостности структурного построения базовых версий ПС. В зависимости от особенностей проблемной области, критериями при выборе архитектуры ПС могут также применяться: эффективное использование памяти или произв-ти реализующей ЭВМ, трудоемкость или длительность разработки, надежность, безопасность и защищенность. В соответствии с целями и задачами проектир-я на стадии системного анализа и формирования стр-ры ПС необходимо ранжировать и выделить доминирующие критерии.

Осн принципы и правила структур-ния ПС и БД можно объединить в группы, кот отражают:

• стандартизированную структуру целостного построения ПС и/или БД опр класса;

• унифиц-ные правила структурного построения функц-х програм-х компон-в и модулей;

• стандартизированную структуру базы данных, обрабатываемых программами;

• униф-ные правила структурного построения инф-ных модулей, заполняющих бд;

• униф-ные правила орг-ии и структурного построения межмодульных интерфейсов програм-х компон-в;

• униф-ные правила внешнего интерфейса и взаимодействия компон-в ПС и БД с внешней средой, с операционной системой и другими типовыми средствами орг-ии вычислительного процесса, защиты и контроля системы.

Методология структурного анализа и предварительного структурного проектир-я ПС начинается с общего обзора фун-ий системы. Далее ф-ции должны детализироваться сверху вниз в виде иерархической стр-ры таким образом, чтобы процедуры сбора, хранения и переработки инф-ии, рассматриваемые сначала как нечто единое целое, расчленялись на отдельные элементы данных, компон-в и действия, совершаемые над этими данными. Структурный анализ, исходя из функционального описания системы в целом, позволяет разделить её на функциональные части, выделить функциональные описания отдельных частей, исследовать в них информационные потоки и формализовать стр-ры данных.

Разделение общей задачи системы и ПС на компоненты  это использование принципа здравого смысла, который должен быть применен в системной разработке крупного ПС для преодоления св-венной ему сложности.

Спецификация требований к предварительной архитектуре комплекса программ формируется в процессе детализации и уточнения спецификации требований к хар-ам ПС в результате проверки последних на непротиворечивость и полноту.

Структурное проектирование ПС основано на модульном принципе. Многоуровневое, иерархическое построение сложных програм-х комплексов позволяет ограничивать и локализовать на каждом из уровней соответствующие ему компоненты. Нижнему иерархическому уровню представления программ соответствуют программные и информационные модули (модули данных). Эти компоненты объединяются в группы программ опр функционального назначения с автономной целевой задачей. Несколько групп функц-х программ образует комплекс программ. В особо сложных случаях возможно создание ПС из нескольких взаимодействующих комплексов.

2. Оценивание надежности и безопасности функц-ния сложных ПС.

Оценивание надежности ПС включает измерение количественных субхар-к и их атрибутов: завершенности, устойчивости к дефектам, восстанавливаемости и доступности-готовности. При этом предполагается, что в контракте, техническом задании или спецификации требований зафиксированы, и утверждены заказчиком определенные значения этих атрибутов и их приоритеты. Измерения проводятся при функционировании готового ПП для сопоставления с заданными требованиями и для оценивания степени соответствия этим спецификациями требований.

Надежность ПС можно оценивать косвенно в процессе разработки по прогнозируемой плотности обнаружения скрытых дефектов и ошибок, а также по плотности выявляемых и устраняемых ошибок выходных результатов при тестир-ии рабочего функц-ния комплекса программ. Распределение реальных длительностей и эф-ти восстановления при ограниченных ресурсах для функц-ния программ, может рассматриваться как дополнительная составляющая при оценивании надежности.

Для прямых, количественных измерений атрибутов надежности необходимы инструментальные средства, встроенные в операционную систему или в соответствующие компоненты ПС. Эти средства должны в динамике реального функц-ния ПС автоматически селектировать и регистрировать аномальные ситуации, дефекты и искажения вычислительного процесса программ и данных, выявляемые аппаратным, программно-алгоритмическим контролем или пользователями. Накопление и систематизация проявлений дефектов при исполнении программ позволяет оценивать осн показатели надежности, помогает определять причины сбоев и отказов и подготавливать данные для улучшения надежности ПС. Регулярная регистрация и обобщение таких данных способствует устранению ситуаций, негативно влияющих на функциональную пригодность и др важные хар-ки ПС.

Прямые экспериментальные методы оценивания интегральных хар-к надежности ПС, в ряде случаев весьма трудно реализовать при нормальных усло­виях функц-ния крупномасштабных комплексов программ, из-за больших значений времени наработки на отказ (сотни и тысячи часов), кот необходимо достигать при разработке и фиксировать при испытаниях. Слож­ность выявления и регистрации редких отказов, а также высокая стоимость экспериментов при длительном многосуточном функциони­ровании крупномасштабных ПС приводят к тому, что на испытаниях получаются малые выборки зарегистрированных отказов и низка достоверность оценки показателей надежности. Кроме того, при таких экспериментах трудно гарантировать полную представительность выборки исходных данных, так как проверки определяются конкретными условиями применения данного ПС на испытаниях.

Форсированные испытания для оценивания надежности ПС значительно отличаются от традиционных методов испытаний аппара­туры. Основными факторами, влияющими на надежность ПС, являются исходные данные и их взаимодействие с дефектами и ошибками прог­рамм или сбоями в аппаратуре ЭВМ. Поэтому форсирование испытаний надежности осуществляется повышением интенсивности искажений ис­ходных данных и расширением варьирования их значений, а также специальным увеличением интенсивности потоков инф-ии и загрузки программ на ЭВМ выше нормальной.

Билет 22

1. Роль системотехники в программной инженерии.

Системотехника  как технология создания систем охватывает все аспекты создания и модернизации сложных вычислительных комплексов. Сюда можно отнести технологию разработки аппаратных средств, внутренних вычислительных процессов и связей всей системы, а также технологию создания ПС. Инженеры системотехники на основе спецификации требований системы определяют её архитектуру и затем, собрав воедино её отдельные части, создают законченную систему.

Стоимость аппаратных средств постепенно снижается, тогда, как стоимость программных продуктов стремительно возрастает. Возникла необходимость в новых технологиях и методах управления комплексными проектами разработки больших программных систем. Такие методы составили программную инженерию.

Программная инженерия  как часть системотехники охватывает все аспекты жизненного цикла ПС от начальной стадии разработки системных требований до завершения использования программного продукта.

2. Примеры оценок сложности тестирования программ.

Для пла­нирования тестирования необходимо выявить зависимости этих ха­рактеристик от числа операторов в программе, ее структуры и кри­териев выделения маршрутов. Эту задачу можно решать эксперимен­тально, путем подсчета соответствующих характеристик в реальных программных модулях, используемых в различных классах ПС.

Для полной про­верки модуля по первому критерию достаточно четырех маршрутов. По этому критерию гарантируется проверка всех передач управления между операторами программы и каждого оператора не менее одного раза.

Второй критерий выбора маршрутов при оценке сложности тестирования обеспечивает в исход­ном графе программы однократную проверку каждого линейно незави­симого ациклического маршрута и каждого линейно независимого цикла в совокупности образующих базовые маршруты.

Третий критерий заключает­ся в анализе хотя бы один раз каждого из реальных ациклических маршрутов исходного графа программы и каждого цикла, достижимого из всех этих маршрутов.

При разработке ПМ целесообразно учитывать рациональное ограничение размеров модулей на уровне трехсот строк текста, что соответствует приблизительно тридцати альтернативам в ациклических программах.

Для получения практических оценок достигаемой корректности программы при покрытии тестами ее структуры, необходимо оценить диапазон реальной вероятности ошибки допускаемой квалифицированным программистом первично в каждой дуге графа программы.

Если фиксировать маршруты, по которым уже выполнено тестирование, то можно автоматически исключать их из информирования и выдавать на регистрацию тестировщикам только группу маршрутов, подлежащих первоочередной проверке. Эти же данные могут использоваться для автоматического расчета полноты проведенной проверки и для оценивания достигнутой структурной корректности программы по каждому из критериев выбора маршрутов.

Билет 23