Шпаргалка по "Технологии программирования и UML"

1. Суть каскадной модели ЖЦ

 

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

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

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

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

Достоинствами такой схемы  являются:

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

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

Положительные стороны применения каскадного подхода заключаются  в следующем:

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

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

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

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

 

 

2. Основные понятия в области разработки и стандартизации ПС.

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

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

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

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

  Пользователь (программного средства) - Юридическое или фактическое лицо, применяющее программное средство или участвующее в деятельности, прямо или косвенно зависящей от функционирования данного программного средства. Примечание. Пользователь программного средства может как являться, так и не являться пользователем вычислительной системы по ГОСТ 15971.

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

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

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

 

 

3. Испытания ПС.

 

Для программ, создаваемых на уровне продукции производственно-технического

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

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

достигнутые показатели качества программного средства (ПС).

Целью испытания является экспериментальное определение  фактических

(достигнутых) характеристик  свойств испытываемого ПС и определение степени

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

от заказчика. Эти характеристики могут быть как количественными, так и

качественными.

Длительность испытания  зависит от типа, конфигурации (сложности) ПС, а также

от целей и степени  автоматизации рассматриваемого технологического процесса.

При испытании операционных систем она колеблется от одного до шести месяцев.

Сложные программные комплексы  после интеграции могут испытываться и более

длительное время.

Составлению плана проведения испытаний должен предшествовать анализ Т3 на

разработку ПС, структурных  и функциональных схем, режимов функционирования,

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

компонентов ПС, результатов  контроля их качества на ранних стадиях

разработки.

Существует несколько  различных методик проведения испытания:

1. Анализируют весь диапазон  входных данных. На основе анализа  заранее

готовят такое множество  комбинаций данных (тестовых наборов  данных), которое

охватывает наиболее характерные  подмножества входных данных. Программу

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

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

2. Анализируют множество  ситуаций, которые могут возникнуть  при

функционировании ПС. Выбирают наиболее характерные ситуации. Каждую из них

выражают через тестовый набор входных данных. Далее сущность испытания и

анализа результатов сводится к подходу 1;

3.С помощью графовой модели анализируют микроструктуру ПС. Выбирают

множество путей, которое  полностью покрывает граф-схему  ПС, и такую

последовательность тестовых наборов исходных данных, выполнение которой будет

проходить по выделенным путям. Организация испытаний аналогична подходам 1 и 2;

4.ПС испытывают в реальной  среде функционирования;

5.ПС испытывают в статистически  моделируемой среде функционирования,

адекватной реальной среде.

Ни один из этих подходов не является универсальным.

Следует выделить три стадии испытания: подготовительную; непосредственные

испытания; заключительную (подготовка отчетных материалов).

Подготовительная стадия наиболее длительная и наиболее трудоемкая. Основными

ее задачами являются:

- планирование испытаний;

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

- разработка программ  и методик испытания;

- накопление предварительных  статистических данных, характеризующих  ПС.

Целенаправленность и  четкость организации работ по накоплению статистических

данных может существенно  повысить достоверность оценки качества ПС, исключить

дублированные (повторные) проверки и уменьшить сроки испытаний  и

затрачиваемые материальные ресурсы.

Между выделенными стадиями испытания ПС имеются прямые и  обратные связи,

аналогичные связям между этапами жизненного цикла ПС. Это означает, что при

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

возвращения к стадии непосредственных испытаний (или даже к подготовительной

стадии) для уточнения  отдельных характеристик.

План проведения испытаний  должен быть ориентирован на обеспечение

всесторонней проверки ПС и максимальной (заданной) достоверности  полученных

результатов при использовании  ограниченных ресурсов, выделенных на

испытаниях.

 

 

4. Аттестация ПС.

 

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

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

 

 

5. Виды стандартизованных документов.

 

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

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

2. Инструкция – это нормативный документ, с пошаговым описанием определенного небольшого процесса, действия. 

 

6. Стандарт, регламент, технические условия. Общее и частное в этих документах.

 

Стандарт в Российской Федерации — документ, в котором в целях добровольного многократного использования устанавливаются характеристики продукции, правила осуществления и характеристики процессов проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации и утилизации, выполнения работ или оказания услуг. Стандарт также может содержать правила и методы исследований (испытаний) и измерений, правила отбора образцов, требования к терминологии, символике, упаковке, маркировке или этикеткам и правилам их нанесения.^[1] Некоторые стандарты в России могут иметь статус обязательных к применению на время перехода к системе технических регламентов.

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

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

Технические условия (ТУ) — это документ, устанавливающий технические требования, которым должны удовлетворять конкретное изделие, материал, вещество и пр. или их группа^[1]. Кроме того, в них должны быть указаны процедуры, с помощью которых можно установить, соблюдены ли данные требования.

 

7. Стандартизация ПС.

 

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