Вопросы трпо рспс 2018. Перечень вопросов к экзамену по
 Скачать 355.79 Kb.
|
|
Перечень вопросов к экзамену по дисциплинам «Технология разработки ПО» и «Разработка и стандартизация ИС и ПС» 2018 год
13 эволюция В настоящее время упомянутая демаркационная линия между процессами разработки и сопровождения постепенно стирается. Только немногие вновь созданные программные системы можно назвать полностью новыми. Поэтому имеет смысл рассматривать процесс сопровождения как непрерывное продолжение процесса разработки. Вместо двух отдельных процессов рациональнее принять эволюционный подход инженерии программного обеспечения, где программные продукты в течение своего жизненного цикла непрерывно изменяются (эволюционируют) в ответ на изменения в системных требованиях и потребностях пользователей. Схема этого эволюционного процесса программных систем показана на рис. 3.13.  18. минимизация ошибок В спецификации могут быть ошибки, которые отразятся в программном обеспечении, либо пользователи могут неверно истолковывать или неправильно эксплуатировать систему. Безотказное ПО не обязательно гарантирует отсутствие отказов в работе системы. Но, с другой стороны, минимизация ошибок программного обеспечения значительно уменьшает число отказов системы и должна выполняться при разработке критических систем. Существует ряд требований к разработке безотказного программного обеспечения. 1. Должна быть точная (предпочтительно формальная) спецификация системных требований, определяющая разрабатываемую систему. 2. Организация – разработчик ПО должна иметь высокую культуру управления качеством, поскольку качество является главным в процессе создания критических систем. В идеале предполагается, что программисты создают программы, в которых отсутствуют ошибки. 3. Методы проектирования и реализации ПО должны основываться на сокрытии и инкапсуляции информации. Объектно-ориентированные языки, такие как Java, удовлетворяют этому условию. 4. В процессе реализации программного кода должны использоваться языки программирования со строгим контролем типов данных, например Jаvа или Ada. В таких языках многие ошибки программирования будут обнаружены на этапе компилирования программ. 5. Везде, где возможно, следует избегать использования тех программных конструкций, которые потенциально могут привести к ошибкам. Такие конструкции обсуждаются в следующем разделе. 6. Должна быть определена четкая технология разработки ПО, и разработчики должны быть обучены применению этой технологии. Менеджеры, отвечающие за качество, должны проверять процесс разработки. 22. обработка исключений Во время выполнения программы могут возникать ситуации, когда состояние данных, устройств ввода-вывода или компьютерной системы в целом делает дальнейшие вычисления в соответствии с базовым алгоритмом невозможным или бессмысленными. Исключительные ситуации, возникающие при работе программы, можно разделить на два основных типа: синхронные и асинхронные, принципы реакции на которые существенно различаются. Синхронные исключения могут возникнуть только в определённых, заранее известных точках программы. Так, ошибка чтения файла или коммуникационного канала, нехватка памяти — типичные синхронные исключения, так как возникают они только в операции чтения из файла или из канала или в операции выделения памяти соответственно. Асинхронные исключения могут возникать в любой момент времени и не зависят от того, какую конкретно инструкцию программы выполняет система. Типичные примеры таких исключений: аварийный отказ питания или поступление новых данных. Обработка исключительных ситуаций самой программой заключается в том, что при возникновении исключительной ситуации, управление передаётся некоторому заранее определённому обработчику — блоку кода, процедуре, функции, которые выполняют необходимые действия. Существует два принципиально разных механизма функционирования обработчиков исключений. Обработка с возвратом подразумевает, что обработчик исключения ликвидирует возникшую проблему и приводит программу в состояние, когда она может работать дальше по основному алгоритму. В этом случае после того, как выполнится код обработчика, управление передаётся обратно в ту точку программы, где возникла исключительная ситуация (либо на команду, вызвавшую исключение, либо на следующую за ней, как в некоторых старых диалектах языка BASIC) и выполнение программы продолжается. Обработка с возвратом типична для обработчиков асинхронных исключений (которые обычно возникают по причинам, не связанным прямо с выполняемым кодом), для обработки синхронных исключений она малопригодна. Обработка без возврата заключается в том, что после выполнения кода обработчика исключения управление передаётся в некоторое, заранее заданное место программы, и с него продолжается исполнение. 23. обнаружение ошибок Большинство методов данной группы направлено по возможности на незамедлительное обнаружение сбоев. Немедленное обнаружение имеет два преимущества: можно минимизировать влияние ошибки и последующие затруднения для пользователя, которому придется извлекать информацию о ней, находить ее и исправлять. Меры по обнаружению ошибок можно разбить на две подгруппы: пассивные попытки обнаружить симптомы ошибки в процессе «обычной» работы ПО и активные попытки программной системы периодически обследовать свое состояние в поисках признаков ошибок. Пассивное обнаружение ошибок. Меры по обнаружению ошибок могут быть приняты на нескольких структурных уровнях программной системы. Здесь мы будем рассматривать уровень подсистем, или компонентов, т.е. нас будут интересовать меры по обнаружению симптомов ошибок, предпринимаемые при переходе от одного компонента к другому, а также внутри компонента. Все это, конечно, применимо также к отдельным модулям внутри компонента. Разрабатывая эти меры, мы будем опираться на следующие принципиальные моменты:
Активное обнаружение ошибок.Не все ошибки можно выявить пассивными методами, поскольку эти методы обнаруживают ошибку лишь тогда, когда ее симптомы подвергаются соответствующей проверке. Можно делать и дополнительные проверки, если спроектировать специальные программные средства для активного поиска признаков ошибок в системе. Такие средства называются средствами активного обнаружения ошибок. Средства активного обнаружения ошибок обычно объединяются в диагностический монитор — параллельный процесс, который периодически анализирует состояние системы с целью обнаружить ошибку. Большие программные системы, управляющие ресурсами, часто содержат ошибки, приводящие к потере ресурсов на длительное время. Например, управление памятью операционной системы сдает блоки памяти «в аренду» программам пользователей и другим частям операционной системы. Ошибка в этих самых «других частях» системы может иногда вести к неправильной работе блока управления памятью, занимающегося возвратом сданной ранее в аренду памяти, что вызывает медленное вырождение системы. Диагностический монитор можно реализовать как периодически выполняемую задачу (например, она планируется на каждый час) либо как задачу с низким приоритетом, которая планируется для выполнения в то время, когда система переходит в состояние ожидания. Выполняемые монитором конкретные проверки зависят от специфики системы. Так, например, монитор может обследовать основную память, чтобы обнаружить блоки памяти, не выделенные ни одной из выполняемых задач и не включенные в системный список свободной памяти. Он может проверять также необычные ситуации: например, процесс не планировался для выполнения в течение некоторого разумного интервала времени. Монитор может осуществлять поиск:
29. процесс управления при по Невозможно описать и стандартизировать все работы, выполняемые в проекте по созданию ПО. Эти работы весьма существенно зависят от организации, где выполняется разработка ПО, и от типа создаваемого программного продукта. Но всегда можно выделить следующие:
Написание предложений— очень ответственная работа, так как для многих организа ций вопрос о том, будет ли проект выполняться самой организацией или разрабатываться по контракту сторонней компанией, является критическим. Не существует каких-либо рекомендаций по написанию предложений, многое здесь зависит от опыт. На этапе планирования проекта определяются процессы, этапы и полученные на каждом из них результаты, которые должны привести к выполнению проекта. Реализа ция этого плана приведет к достижению целей проекта. Определение стоимости проек та напрямую связано с его планированием, поскольку здесь оцениваются ресурсы, тре бующиеся для выполнения плана. Контроль за ходом выполнения работ (мониторинг проекта)— это непрерывный процесс, продолжающийся в течение всего срока реализации проекта. Руководитель дол жен постоянно отслеживать ход реализации проекта и сравнивать фактические и пла новые показатели выполнения работ с их стоимостью. 30. план Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает руководителю предви деть проблемы, которые могут возникнуть на каких-либо этапах создания ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на началь ном этапе проекта, рассматривается всеми его участниками как руководящий документ, вы полнение которого должно привести к успешному завершению проекта. Этот первоначаль ный план должен максимально подробно описывать все этапы реализации проекта. Процесс планирования начинается, исходя из описания системы, с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т.д.). Эти ограничения должны определяться параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты документация, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по выполнению проекта или дается разрешение на продолжение использования ранее созданного графика. После этого проводится контроль выполнения работ и отмечаются расхождения между реальным и плановым ходом работ.
31.
 32. график Составление графика - одна из самых ответственных работ, выполняемых менедже ром проекта. Здесь менеджер оценивает длительность проекта, определяет ресурсы, не обходимые для реализации отдельных этапов работ, и представляет их (этапы) в виде со гласованной последовательности. Если данный проект подобен ранее реализованному, то график работ последнего проекта можно взять за основу для данного проекта. Но затем следует учесть, что на отдельных этапах нового проекта могут использоваться методы и подходы, отличные от использованных ранее. В процессе составления графика (рис. 2) весь массив работ, необходимых для реали зации проекта, разбивается на отдельные этапы и оценивается время, требующееся для выполнения каждого этапа. Обычно многие этапы выполняются параллельно. График ра бот должен предусматривать это и распределять производственные ресурсы между ними наиболее оптимальным образом. Нехватка ресурсов для выполнения какого-либо крити ческого этапа - частая причина задержки выполнения всего проекта.  33. Риски
 12. аттестация требованиям заказчиков. Верификация и аттестация охватывают полный жизненный цикл ПО – они начинаются на этапе анализа требований и завершаются проверкой программного кода на этапе тестирования готовой программной системы. Верификация и аттестация не одно и то же, хотя их легко перепутать. Кратко различие между ними можно определить следующим образом: • верификация отвечает на вопрос, правильно ли создана система; • аттестация отвечает на вопрос, правильно ли работает система. Согласно этим определениям, верификация проверяет соответствие ПО системной спецификации, в частности функциональным и нефункциональным требованиям. Аттестация– более общий процесс. Во время аттестации необходимо убедиться, что программный продукт соответствует ожиданиям заказчика. Аттестация проводится после верификации, для того чтобы определить, насколько система соответствует не только спецификации, но и ожиданиям заказчика. Как уже отмечалось ранее, на ранних этапах разработки ПО очень важна аттестация системных требований. В требованиях часто встречаются ошибки и упущения; в таких случаях конечный продукт, вероятно, не будет соответствовать ожиданиям заказчика. Но, конечно, аттестация требований не может выявить все проблемы в спецификации требований. Иногда недоработки и ошибки в требованиях обнаруживаются только после завершения реализации системы. В процессах верификации и аттестации используются две основные методики проверки и анализа систем. 1. Инспектирование ПО. Анализ и проверка различных представлений системы, например документации спецификации требований, архитектурных схем или исходного кода программ. Инспектирование выполняется на всех этапах процесса разработки программной системы. Параллельно с инспектированием может выполняться автоматический анализ исходного кода программ и соответствующих документов. Инспектирование и автоматический анализ – это статические методы верификации и аттестации, поскольку им не требуется исполняемая система. 2. Тестирование ПО. Запуск исполняемого кода с тестовыми данными и исследование выходных данных и рабочих характеристик программного продукта для проверки правильности работы системы. Тестирование – это динамический метод верификации и аттестации, так как применяется к исполняемой системе.  16. окружение системы и Первый этап в любом процессе проектирования состоит в выявлении взаимоотношений между проектируемым программным обеспечением и его окружением. Выявление этих взаимоотношений помогает решить, как обеспечить необходимую функциональность системы и как структурировать систему, чтобы она могла эффективно взаимодействовать со своим окружением. Модель окружения системы и модель использования системы представляют собой две дополняющие друг друга модели взаимоотношений между данной системой и ее окружением. 1. Модель окружения системы – это статическая модель, которая описывает другие системы из окружения разрабатываемого ПО. 2. Модель использования системы – динамическая модель, которая показывает взаимодействие данной системы со своим окружением. Модель окружения системы можно представить с помощью схемы связей, которая дает простую блок-схему общей архитектуры системы. С помощью пакетов языка UML ее можно представить в развернутом виде как совокупность подсистем. Такое представление показывает, что рабочее окружение системы Метеостанция находится внутри подсистемы, занимающейся сбором данных. Там же показаны другие подсистемы, которые образуют систему построения карт погоды. При моделировании взаимодействия системы с ее окружением применяется абстрактный подход, который не требует больших объемов данных для описания этих взаимодействий. Подход, предлагаемый UML, состоит в том, чтобы разработать модель вариантов использования, в которой каждый вариант представляет собой определенное взаимодействие с системой. В модели вариантов использования каждое возможное взаимодействие изображается в виде эллипса, а внешняя сущность, включенная во взаимодействие, представлена стилизованной фигуркой человека. В нашем примере внешняя сущность, хотя и представлена фигуркой человека, является системой обработки метеорологических данных. Модель вариантов использования для метеостанции показана на рис. 10.2. В этой модели метеостанция взаимодействует с внешними объектами во время запуска и завершения работы, при составлении отчетов на основе собранных данных, а также при тестировании и калибровке метеорологических приборов.  28. управление процессами Под управлением процессами понимаются процедуры ОС, обеспечивающие запуск системных и прикладных программ, их выполнение и завершение. В однозадачных ОС управление процессами решает следующие задачи:
Все эти задачи решаются сравнительно просто. В многозадачном режиме добавляются значительно более серьезные задачи:
20. 2. Локализация ошибок Локализация - это нахождение места ошибки в программе. В процессе поиска ошибки мы обычно выполняем одни и те же действия: прогоняем программу и получаем результаты; сверяем результаты с эталонными и анализируем несоответствие; выявляем наличие ошибки, выдвигаем гипотезу о ее характере и месте в программе; проверяем текст программы, исправляем ошибку, если мы нашли ее правильно. Способы обнаружения ошибки: Аналитический - имея достаточное представление о структуре программы, просматриваем ее текст вручную, без прогона. Экспериментальный - прогоняем программу, используя отладочную печать и средства трассировки, и анализируем результаты ее работы. Оба способа по-своему удобны и обычно используются совместно. 3. Принципы отладки Принципы локализации ошибок: Большинство ошибок обнаруживается вообще без запуска программы - просто внимательным просматриванием текста. Если отладка зашла в тупик и обнаружить ошибку не удается, лучше отложить программу. Когда глаз "замылен", эффективность работы упорно стремится к нулю. Чрезвычайно удобные вспомогательные средства - это отладочные механизмы среды разработки: трассировка, промежуточный контроль значений. Можно использовать даже дамп памяти, но такие радикальные действия нужны крайне редко. Экспериментирования типа "а что будет, если изменить плюс на минус" - нужно избегать всеми силами. Обычно это не дает результатов, а только больше запутывает процесс отладки, да еще и добавляет новые ошибки. Принципы исправления ошибок еще больше похожи на законы Мерфи: Там, где найдена одна ошибка, возможно, есть и другие. Вероятность, что ошибка найдена правильно, никогда не равна ста процентам. Наша задача - найти саму ошибку, а не ее симптом. Это утверждение хочется пояснить. Если программа упорно выдает результат 0,1 вместо эталонного нуля, простым округлением вопрос не решить. Если результат получается отрицательным вместо эталонного положительного, бесполезно брать его по модулю - мы получим вместо решения задачи ерунду с подгонкой. Исправляя одну ошибку, очень легко внести в программу еще парочку. "Наведенные" ошибки - настоящий бич отладки. Исправление ошибок зачастую вынуждает возвращаться на этап составления программы. Это неприятно, но порой неизбежно. |