Конспект (краткий конспект, всё переписывать не надо!!!!!!). Тетради принести в понедельник 20. 09 в 306 кабинет для проверки!!!!!
 Скачать 164.29 Kb.
|
|
ЗАДАНИЕ: НАПИСАТЬ КОНСПЕКТ (КРАТКИЙ КОНСПЕКТ, ВСЁ ПЕРЕПИСЫВАТЬ НЕ НАДО!!!!!!). ТЕТРАДИ ПРИНЕСТИ В ПОНЕДЕЛЬНИК 20.09 в 306 кабинет ДЛЯ ПРОВЕРКИ!!!!! ВСПОМОГАТЕЛЬНЫЕ И ОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ИС Процесс документирования (documentation process)предусматриваетформализованное описание информации, созданной в течение ЖЦ ПО. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких, как руководство, технические специалисты и
Процесс управления конфигурацией (configuration managementprocess) предполагает применение административных и техническихпроцедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО. Согласно стандарту ШЕЕ—90 под конфигурацией ПО понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПО. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
Подготовительная работа заключается в планировании управленияконфигурацией. Идентификация конфигурации устанавливает правила,с,помощью которыхможно однозначно идентифицировать и различать компоненты ПО и их версии. Кроме того, каждому компоненту и его версиям соответствует однозначно обозначаемый комплект документации. В результате создается база для одноз-начного выбора и манипулирования версиями компонентов ПО, использующая ограниченную и упорядоченную систему символов, идентифицирующих различные версии ПО. Контроль за конфигурацией предназначен для систематической оценкипредполагаемых модификаций ПО и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение. Он обеспечивает контроль за состоянием и развитием компонентов ПО и их версий, а также адекватность реально изменяющихся компонентов и их комплектной документации. Учет состояния конфигурации представляет собой регистрацию состояниякомпонентов ПО, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПО. Совокупность отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификаций. Оценка конфигурации заключается в оценке функциональной полнотыкомпонентов ПО, а также соответствия их физического состояния текущему техническому описанию. Управление выпуском и поставка охватывают изготовление эталонных копийпрограмм и документации, их хранение и поставку пользователям в соответствии с порядком, принятым в организации. Процесс обеспечения качества (quality assurance process) обес-печивает соответствующие гарантии того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам. Под качеством ПО понимается совокупность свойств, которые характеризуют способность ПО удовлетворять заданным требованиям. Для получения достоверных оценок создаваемого ПО процесс обеспечения его качества должен происходить независимо от субъектов, непосредственно связанных с разработкой ПО. При этом могут использоваться результаты других вспомогательных процессов, таких, как верификация, аттестация, совместная оценка, аудит и разрешение проблем. Процесс обеспечения качества включает следующие действия: 1) подготовительную 3) обеспечение прочих работу; показателей качества системы. обеспечение качества продукта; Подготовительная работа заключается в координации с другимивспомогательными процессами и планировании самого процесса обеспечения качества с учетом используемых стандартов, методов, процедур и средств. Обеспечение качества продукта подразумевает гарантирование полногосоответствия программных продуктов и их документации требованиям заказчика, предусмотренным в договоре. Обеспечение качества процесса предполагает гарантирование соответствияпроцессов ЖЦ ПО, методов разработки, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам. Обеспечение прочих показателей качества системы осуществляется всоответствии с условиями договора и стандартом качества ISO 9001. Процесс верификации (verification process) состоит в определениитого, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями (верификация в узком смысле означает формальное доказательство правильности ПО). Для повышения эффективности верификация должна как можно раньше интегрироваться с использующими ее процессами (такими, как поставка, разработка, эксплуатация или сопровождение). Данный процесс может включать анализ, оценку и тестирование. Верификация может проводиться с различными степенями независимости. Степень независимости может варьироваться от выполнения верификации самим исполнителем или другим специалистом данной организации до ее выполнения специалистом другой организации с различными вариациями. Если процесс верификации осуществляется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой верификации. Процесс верификации включает следующие действия: 1)подготовительную работу; 2) верификацию. В процессе верификации проверяются следующие условия: непротиворечивость требованийкорректность описания в проектных к системе и степень учета потребностей пользователей; возможности поставщика выполнить заданные требования; соответствие выбранных процессов ЖЦ ПО условиям договора; адекватность стандартов, процедур и среды разработки про- цессам ЖЦ ПО; соответствие проектных спецификаций ПО заданным тре- бованиям; спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.; соответствие кода проектным спецификациям и требованиям; тестируемость и корректность кода,его соответствие принятым стандартам кодирования; корректность интеграции компонентов ПО в систему; адекватность,полнота и непротиворечивость документации. Процесс аттестации (validation process) предусматриваетопределение полноты соответствия заданных требований и созданной системы или программного продукта их конкретному функциональному назначению. Под аттестацией обычно понимается подтверждение и оценка достоверности проведенного тестирования ПО. Аттестация должна гарантировать полное соответствие ПО спецификациям, требованиям и документации, а также возможность его безопасного и надежного применения пользователем. Аттестацию рекомендуется выполнять путем тес-тирования во всех возможных ситуациях и использовать при этом независимых специалистов. Аттестация может проводиться на начальных стадиях ЖЦ ПО или как часть работы по приемке ПО. Аттестация, так же как и верификация, может осуществляться с различными степенями независимости. Если процесс аттестации выполняется организацией, не зависящей от поставщика, разработчика, оператора или службы сопровождения, то он называется процессом независимой аттестации. Процесс аттестации включает следующие действия: подготовительную работу; аттестацию. Процесс совместной оценки (joint review process)предназначен дляоценки состояния работ по проекту и ПО, создаваемому при выполнении данных работ (действий). Он сосредоточен в основном на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта. Оценка применяется как на уровне управления проектом, так и на уровне технической реализации проекта и проводится в течение всего срока действия договора. Данный процесс может выполняться двумя любыми сторонами, участвующими в договоре, при этом одна сторона проверяет другую. Процесс совместной оценки включает следующие действия: подготовительную работу; оценку управления проектом; техническую оценку. Процесс аудита (audit process)представляет собой определениесоответствия требованиям, планам и условиям договора. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую. Аудит —это ревизия(проверка),проводимая компетентным органом(лицом) в целях обеспечения независимой оценки степени соответствия ПО или процессов установленным требованиям. Аудит служит для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Аудиторы (ревизоры) не должны иметь прямой зависимости от разработчиков ПО. Они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования. Процесс аудита включает следующие действия: подготовительную работу; аудит. Процесс разрешения проблем (problem resolution process)предус-матривает анализ и решение проблем (включая обнаруженные несоответствия), независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов. Каждая обнаруженная проблема должна быть идентифицирована, описана, проанализирована и разрешена. Процесс разрешения проблем включает следующие действия: подготовительную работу; разрешение проблем. Организационные процессы: управление проектами –работы по планированию и управлениюпроцессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности; создание инфраструктуры проекта –работы по установлению иобеспечению инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения системы; усовершенствование –работы по оценке,контролю и улучшениюпроцессов жизненного цикла; обучение –работы по планированию и проведению обученияперсонала, включая разработку учебных материалов. При этом под персоналом понимаются не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы. Например, разработчики должны быть обучены технологиям и средствам программирования, принятым в организации, и даже обучены правильно внедрять и обучать конечных пользователей работе с системой. Как бы это ни парадоксально звучало, но обучать правильной методике и приемам обучения тоже необходимо. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ИС Информационная система – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели. Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения. ЖЦ ПО ИС – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO – International Organization of Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Структура ЖЦ ПО ИС по стандарту ISO/IEC 12207 базируется на трех группах процессов:
Моделью жизненного цикла ИС называют некоторую структуру, определяющую последовательность процессов, действий и задач, которые реализуются на протяжении ее жизненного цикла, а также взаимосвязи между этими процессами, действиями и задачами. Сегодня в практике создания ИС применяются следующие модели жизненного цикла: 1) каскадная модель,иногда также называемая моделью «водопад» (waterfall); спиральная модель. Каскадная модель разработки ИС каскадной модели предусматривается последовательная организацияработ с разбиением их на этапы и переходом с одного этапа на следующий лишь по окончании работ на предыдущем этапе. 23 Каждый этап сопровождается выпуском полного комплекта документации, достаточной для продолжения разработки ИС даже другой командой проектировщиков. этой модели (рис. 1) следующие этапы разработки: анализ требований заказчика; проектирование и разработка ИС; тестирование и опытная эксплуатация ИС; сдача готового программного продукта.  а) Анализ Проектирование б) Анализ Разработка Проектирование Тестировани Разработка Сдача Тестировани Сдача Рис. 1. Каскадная модель разработки ИС: а – теоретическая; б – практическая На первом этапе анализируется проблема, которую необходимо решить, четко формулируются все требования заказчика. Результат, получаемый на данном этапе, – техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами. На втором этапе разрабатываются проектные решения, которые должны удовлетворять всем требованиям, сформулированным в ТЗ на ИС. Результат этапа – комплект проектной документации, содержащей все необходимые данные для реализации проекта. Третий этап –реализация проекта ИС,разработка ПО любым из возможныхспособов в соответствии с проектными решениями, полученными на предыдущем этапе. Результат выполнения этапа – готовый к практическому применению программный продукт. На четвертом этапе проводятся тестирование и проверка полученного программного обеспечения на предмет его соответствия требованиям технического задания. Опытная эксплуатация ПО позволяет выявить его скрытые недостатки, проявляющиеся в слабом учете специфики условий работы будущей ИС. На пятом этапе осуществляются сдача готового проекта заказчику и подтверждение того, что все требования технического задания соблюдены полностью. Особенности каскадной модели жизненного цикла ИС
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||