Шпаргалка по "Информатике"

1 Классификация  ПО.

ПО делится  на:   

1) Системное которое включает в себя операционную систему, оболочку  и сервисные программы. В свою очередь ОС и оболочка являют собой операционную среду, а сервисные программы являются утилитами.

2)Инструментальное ПО – это языки программирования (языки программирования высокого уровня, операционные языки, программные языки, машинные языки).

3)Пакеты прикладных программ - сюда входят всё программное обеспечение относящееся к разделу «прикладное» (MS Word, Exel, Paint, Access и другие).

2Жизненый цикл По. Процессы  и модели  ЖЦ

Под жизненным  циклом ПС понимают весь период его  разработки и эксплуатации (использования), начиная от момента возникновения  замысла ПС и кончая прекращением всех  видов  его  использования .                                                                    Процессы жизненного цикла ПО                                               Основные:                                                                              Приобретение (действия и задачи заказчика, приобретающего ПО)Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.                                                  Вспомогательные                                                           Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению) Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)Аудит (определение соответствия требованиям, планам и условиям договора)Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)                                                      Организационные                                                                  Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

модели  ЖЦ ПО

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

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

Достоинства классического  жизненного цикла: дает план и временной  график по всем этапам проекта, упорядочивает ход конструирования. Недостатки классического жизненного цикла:

1)  реальные проекты  часто требуют отклонения от  стандартной последовательности шагов; 2)  цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично); 3)  результаты проекта доступны заказчику только в конце работы.

2. Инкрементная  модель Инкрементная модель является классическим примером инкрементной стратегии конструирования.

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.

3. Спиральная  модель Спиральная модель — классический пример применения эволюционной стратегии конструирования.

Спиральная модель (автор  Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий в этих парадигмах. Как показано на рис. 1.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали. 1.   Планирование — определение целей, вариантов и ограничений. 2.   Анализ риска — анализ вариантов и распознавание/выбор риска. 3.   Конструирование — разработка продукта следующего уровня. 4.   Оценивание — оценка заказчиком текущих результатов конструирования.Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали. Достоинства спиральной модели:

1)  наиболее реально  (в виде эволюции) отображает разработку  программного обеспечения; 2)  позволяет  явно учитывать риск на каждом  витке эволюции разработки; 3)  включает шаг системного подхода в итерационную структуру разработки; 4)  использует моделирование для уменьшения риска и совершенствования программного изделия. Недостатки спиральной модели: 1)  новизна (отсутствует достаточная статистика эффективности модели); 2)  повышенные требования к заказчику; 3)  трудности контроля и управления временем разработки.

14 модели статическая  и диномическая

Статические и динамические модели

По признаку учета  зависимости объекта моделирования  от времени различают статические и динамические характеристики систем, отражаемые в соответствующих моделях.

Статические модели (модели статики) отражают функцию системы - конкретное состояние реальной или  проектируемой системы (своего рода его «мгновенную фотографию»)

Примеры. Закон Ома, описание показателей эффективности организацией в некоторый момент времени.

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

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

Отличие статических  и динамических моделей заключено  в учете времени: в статике  его как бы не существует, а в  динамике это основной элемент.

3 Методы и  модели разработки ПО: каскадная  спиральная макетирование

Каскадная модель

Данная модель также носит название «водопад». Классическими представителями реализации данной методологии являются стандарты ISO и CMM.

Модель предполагает следующие свойства взаимодействия этапов:

• модель состоит  из последовательно расположенных этапов;

• каждый этап полностью  заканчивается до того, как начнется следующий;

• этапы не перекрываются  во времени: следующий этап не начинается до тех пор, пока не завершится предыдущий;

• возврат к предыдущим этапам не предусмотрен либо всячески ограничен;

• исправление ошибок происходит лишь на стадии тестирования;

• результат появляется только в конце разработки.

Критерием появления результата является отсутствие ошибок и точное соответствие продукта первоначальной спецификации.

Основным недостатком  каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.             Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Макетирование

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

•               Основная цель макетирования — снять неопределенности в требованиях заказчика.

•               Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.

•               Модель может принимать одну из трех форм:

•               1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);

•               2) работающий макет (выполняет некоторую часть требуемых функций);

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

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

Достоинство макетирования: обеспечивает определение полных требований к ПО.

Недостатки  макетирования:

заказчик может принять  макет за продукт;

разработчик может принять  макет за продукт.

4 Стратегии конструирования ПО

Существуют 3 стратегии  конструирования ПО:

однократный проход (водопадная стратегия) - линейная последовательность этапов конструирования;

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

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

5 Быстрая разработка  приложений RAD

RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.

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

Принципы RAD технологии направлены на обеспечение трех основных ее преимуществ – высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.  Инструментарий должен быть нацелен на минимизацию времени разработки.                                                                    Создание прототипа для уточнения требований заказчика. Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком. Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию. Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.      Управление проектом должно минимизировать длительность цикла разработки.                                                                                         Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн.

18способы  тестирования классов ооп

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

Методы тестирования структурных программ достаточно давно  и хорошо проработаны ( тем не менее  даже для структурных программ тестирование не является полностью закрытой темой ). Объектно-ориентированные программы неизбежно добавляют специфические проблемы к технологии тестирования. Эти проблемы определяются двумя основными аспектами :

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

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

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

    Основные свойства  объектов ( инкапсуляция, наследование, полиморфизм ) добавляют новые  аспекты тестирования.

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

 Наследование ставит вопросы  о повторении тестирования наследуемых  операций. Допустим операция А  принадлежит базовому классу, и она протестирована. Операция В принадлежит производному классу и вызывает операцию А. Должна ли операция А тестироваться повторно?

 Полиморфизм приводит к неоднозначности  с вызовом операций, которая может  быть разрешена только на этапе выполнения. Следовательно заранее построить и спланировать набор тестов становится просто невозможным.

 Объектно-ориентированная технология  привносит свои особенности в  процесс тестирования систем. Формулируется  несколько вопросов, которые необходимо  разрешить для успешного проведения тестирования:

Какая часть унаследованных свойств  должна заново тестироваться.

Когда и как можно проверять  информациию о состоянии класса.

Как можно проверить поведение  системы, зависящее от состояния, когда  отсутствует единый механизм управление состояниями в программе.

Как следует тестировать интеграцию классов и какие стратегии  тестирования применять.

Решение подобных вопросов выполняется  путем разработки новых подходов и модернизации старых, специально для тестирования объектно-ориентированных систем.

6 модель разработки  ПО компонентно Орентированные , экстремальное программирование

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

Программные компоненты, созданные в реализованных программных  проектах, хранятся в библиотеке. В  новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиотеке. Если они найдены, то компоненты извлекаются из библиотеки и используются повторно. В противном случае создаются новые компоненты, они применяются в проекте и включаются в библиотеку.

Достоинства компонентно-ориентированной модели:

уменьшает на 30% время разработки программного продукта;

уменьшает стоимость  программной разработки до 70%;увеличивает  в полтора раза производительность разработки.                                                       Экстремальное программирование

Наиболее часто  используемой адаптивной моделью является модель экстремального программирования (eXtreme Programming, XP-процесс) 
XP-процесс ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределенных или быстро меняющихся требованийXP-процесс (экстремальное программирование)Основная идея XP-процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций. 
Базовыми действиями xp являются:=                               кодирование, тестирование,выслушивание заказчика,проектирование                                              Принципы XP                                                                          Высокий динамизм разработки обеспечивается следующими принципами:=непрерывная связь с заказчиком,простота выбираемых решений,быстрая обратная связь на основе оперативного тестирования,профилактика рисков              Практики XP разработки                                                         Реализация этих принципов достигается за счет использования следующих методов:=                      Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система               Простое проектирование – принимаются наиболее простые из возможных проектные решения                                       Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант                     Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения                                                      Парное программирование – код пишется двумя программистами на одном компьютере                         Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы                          Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований                                                                            Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика                            Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы                                                                                                                                 

7 методы и  технологии конструирования ПО

Определение технологии конструирования программного обеспечения

Технология конструирования  программного обеспечения (ТКПО) —  система инженерных принципов для  создания экономичного ПО, которое  надежно и эффективно работает в  реальных компьютерах 

Различают методы, средства и процедуры ТКПО.

Методы обеспечивают решение следующих задач:

- планирование и оценка  проекта;

- анализ системных  и программных требований;

-проектирование алгоритмов, структур данных и программных  структур;

- кодирование;

- тестирование;

- сопровождение.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов.

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

Процедуры определяют:

- порядок применения  методов и средств;

- формирование отчетов   по соответствующим требованиям;

- контроль, который помогает  обеспечивать качество и координировать  изменения;

Процесс конструирования  программного обеспечения состоит  из последовательности шагов, использующих методы, утилиты и процедуры. Эти последовательности шагов часто называют парадигмами ТКПО.

13 ООП

Ключевые черты ООП  хорошо известны:

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

Наследование предполагает создание нового класса на основе старого (родителя) с заимствованием его  атрибутов и методов.

Третья черта, известная  как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программы, основанных на них.

Инкапсуляция, наследование и полиморфизм — фундаментальные  свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах). Различные ОО языки используют совершенно разные подходы. Мы можем различать ОО языки, сравнивая механизм контроля типов, способность поддерживать различные программные модели и то, какие объектные модели они поддерживают.

8модели качества процессов конструирования ПО

Базовым понятием модели СММ считается зрелость компании

Очень важно отметить, что модель СММ ориентирована на построение системы постоянного улучшения процессов. В ней зафиксированы пять уровней зрелости (рис. 1.9) и предусмотрен плавный, поэтапный подход к совершенствованию процессов — можно поэтапно получать подтверждения об улучшении процессов после каждого уровня зрелости.

Начальный уровень (уровень 1) означает, что процесс в компании не формализован. Он не может строго планироваться и отслеживаться, его успех носит случайный  характер. Результат работы целиком  и полностью зависит от личных качеств отдельных сотрудников. При увольнении таких сотрудников проект останавливается.

Для перехода на повторяемый  уровень (уровень 2) необходимо внедрить формальные процедуры для выполнения основных элементов процесса конструирования. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов.

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

С переходом на управляемый  уровень (уровень 4) в компании принимаются  количественные показатели качества как  программных продуктов, так и  процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса.

Высший, оптимизирующий уровень (уровень 5) подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется.

Каждый уровень СММ  характеризуется областью ключевых процессов (ОКП), причем считается, что  каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:

q предотвращения дефектов;

q управления изменениями  технологии;

q управления изменениями  процесса.

Если все цели ОКП  достигнуты, компании присваивается  сертификат данного уровня зрелости. Если хотя бы одна цель не достигнута, то компания не может соответствовать  данному уровню СММ.

17 системное  тестирование

Системное тестирование

Объект тестирования – система в целом.

Цель тестирования –  проверка правильности объединения  и взаимодействия всех элементов  компьютерной системы, реализации всех системных функций.

Способ тестирования – принцип «черного ящика».

Системное тестирование включает в себя:

Тестирование восстановления (время восстановления, отказоустойчивость, правильность повторной инициализации, восстановление данных и др.)

Тестирование безопасности (проверка функционирования защитных механизмов системы в случае проникновения).

Стрессовое тестирование (тестовые варианты направлены на оценку стабильности работы ПС при «ненормальных» нагрузках: по частоте, объему, размеру  данных). Частный случай – тестирование чувствительности.

Тестирование производительности (проверяется скорость работы ПО в  компьютерной системе).

19испытание сопровождения и эксплуатации программных продуктов

испытания программных  средств

Данная работа состоит  из следующих задач применительно  к каждому программному объекту архитектуры (или объекту программной конфигурации, если он определен):

1 Разработчик должен  проводить квалификационные испытания  (тестирование) на соответствие квалификационным  требованиям к программному объекту.  При проведении испытаний должно быть обеспечено, чтобы реализация каждого установленного требования к программному объекту была проверена на соответствие. Результаты квалификационных испытаний должны быть документально оформлены.

2 Разработчик, при  необходимости, должен уточнить документацию пользователя.

3 Разработчик должен  оценить проект, запрограммированный  программный объект, проведенные  испытания, результаты испытаний  и документацию пользователя  по следующим критериям (при  этом результаты оценок должны  быть документально оформлены):

a) тестовое покрытие  требований к программному объекту;

b) соответствие ожидаемым  результатам;

c) возможность сборки  и тестирования системы (при  их проведении);

d) возможность эксплуатации  и сопровождения.

4 Разработчик должен  обеспечить проведение аудиторской проверки(ок) в соответствии с подразделом. Результаты аудиторских проверок должны быть документально оформлены. Если при реализации конкретного проекта разрабатывались или собирались как технические, так и программные средства, то проведение аудиторских проверок может быть отложено до квалификационных испытаний системы.

.5 После успешного  завершения аудиторских проверок, если они проводились, разработчик  должен:

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

b) определить состояние  конфигурации (базовую линию) проекта  и программ данного программного объекта.

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

Оператор управляет  процессом эксплуатации на проектном  уровне в соответствии с процессом  управления, который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры; адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации и управляет процессом эксплуатации на организационном уровне в соответствии с процессами усовершенствования и обучения

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

2) эксплуатационные испытания;

3) эксплуатация системы;

4) поддержка пользователя.

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

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

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

Список работ. Данный процесс состоит из следующих  работ:

1) подготовка процесса;

2) анализ проблем и  изменений;

3) внесение изменений;

4) проверка и приемка  при сопровождении;

5) перенос;

6) снятие с эксплуатации.

9 руководство программным проектом

Руководство программным  проектом

Начало проекта

Перед планированием  проекта следует:

· установить цели и проблемную область проекта;

· обсудить альтернативные решения;

· выявить технические  и управленческие ограничения.

Измерения, меры и метрики

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

Процесс оценки

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

Анализ риска

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

Планирование

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

Трассировка и контроль

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

10функциональное  моделирование SADT

Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для  построения функциональной модели объекта какой-либо предметной области. Основана на:

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

строгость и  точность. Выполнение правил SADT требует достаточной строгости и точности,

Правила SADT включают:

ограничение количества блоков на каждом уровне (правило 3-6 блоков);

связность диаграмм (номера блоков);

отсутствие повторяющихся имен;

синтаксические правила  для графики (блоков и дуг);

разделение входов и  управлений (правило определения  роли данных).

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

11 объектно-ориентированный  подход  к разработке по

Объектно-ориентированный  подход основан на систематическом  использовании моделей для языково-независимой разработки программной системы,

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

объектно-ориентированный подход помогает справиться с такими сложными проблемами, как

уменьшение сложности  программного обеспечения;

повышение надежности программного обеспечения;

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

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

Объектно-ориентированная  разработка программного обеспечения  связана с применением объектно-ориентированных  моделей при разработке программных систем и их компонентов. объектно-ориентированная разработка включает:

объектно-ориентированные  методологии (технологии) разработки программных  систем;

инструментальные  средства, поддерживающие эти технологии.

Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным.

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

12.Модульное  программирование

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

Создание модулей и  использование их объектов в программах является одним из приемов экономичного программирования, что обуславливается  следующими обстоятельствами:

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

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

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

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

15 методика тестирования  программных систем структурное и функциональное

Тестирование «черного ящика» (функциональное тестирование) позволяет получить комбинации входных данных, обеспечивающих полную проверку всех функциональных требований к программе

Тестирование «черного ящика» обеспечивает поиск следующих  категорий ошибок:

1) некорректных или  отсутствующих функций;

2) ошибок интерфейса;

3) ошибок во внешних  структурах данных или в доступе к внешней базе данных;

4) ошибок характеристик  (необходимая емкость памяти и  т. д.);

5) ошибок инициализации  и завершения.

В отличие от тестирования «белого ящика», которое выполняется  на ранней стадии процесса тестирования, тестирование «черного ящика» применяют на поздних стадиях тестирования.

Техника «черного ящика» ориентирована на решение следующих  задач:

- сокращение необходимого  количества тестовых вариантов 

- выявление классов  ошибок, а не отдельных ошибок.

Тестирование «белого ящика»

Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется  корректность построения всех элементов  программы и правильность их взаимодействия друг с другом.

Особенности тестирования «белого ящика»

Обычно тестирование «белого ящика» основано на анализе управляющей структуры программы. Программа считается полностью проверенной, если проведено исчерпывающее тестирование .

В этом случае формируются тестовые варианты, в которых:

- гарантируется проверка всех  независимых маршрутов программы;

- проходятся ветви True, False для  всех логических решений;

- выполняются все циклы (в  пределах их границ и диапазонов);

- анализируется правильность внутренних  структур данных.