Сопровождение всегда признавалось одним из основных этапов жизненного цикла программного обеспечения. Уже к середине 70-х годов было признано, что сопровождение – это этап, занимающий более 50% затрат на разработку и внедрение программного средства (ПС).

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

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

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

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

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

Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении. Интересно, что данный стандарт также касается вопросов подготовки к сопровождению до передачи системы в эксплуатацию, однако, структурно это сделано на уровне соответствующего информационного приложения, включенного в стандарт.

В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает сопровождение как процесс модификации программного продукта в части его кода и документации для решения возникающих проблем при эксплуатации или реализации потребностей в улучшениях тех или иных характеристик продукта. Задача состоит в модификации продукта при условии сохранения его целостности.

Международный стандарт ISO/IEC 14764 (Standard for Software Engineering – Software Maintenance) определяет сопровождение программного обеспечения в тех же терминах, что и стандарт 12207, придавая особое значение работам по подготовке к деятельности по сопровождению до передачи системы в реальную эксплуатацию, например, вопросам планирования регламентов и операций по сопровождению.

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

Ряд источников, в частности, стандарт IEEE 1216, определяют три категории работ по сопровождению: корректировка, адаптация и совершенствование. Такая классификация была обновлена в стандарте ISO/IEC 14764 введением четвертой составляющей.

Таким образом, сегодня говорят о четырех категориях сопровождения:

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

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

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

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

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

Возможность сопровождения или сопровождаемость программной системы определяется, например, глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology, обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований. Стандарт ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality Model, 2001 г.) рассматривает возможность сопровождения как одну из характеристик качества.

Сопровождаемость должна быть определена до разработки программного средства, т.е подготовлено соответствующее соглашение между заказчиком и поставщиком как часть работы «подготовка» из процесса заказа по (ISO/IEC , #M12291 1200009075 ГОСТ Р ИСО/МЭК) 12207#S . Разработчик формирует план сопровождения, в котором должны быть отражены конкретные методы обеспечения сопровождаемости ПС, соответствующие ресурсы и алгоритм выполнения работ.

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

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

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

На стоимость работ по сопровождению оказывает влияние множество различных факторов. ISO/IEC 14764 определяет, что «существует два наиболее популярных метода оценки стоимости сопровождения: – параметрическая модель и использование опыта». Чаще всего, оба этих подхода комбинируются для повышения точности оценки.

Существуют различные методы внутренней оценки продуктивности персонала сопровождения для сравнения работы различных групп сопровождения. Организация, ведущая сопровождение, должна определить метрики, по которым будут оцениваться соответствующие работы. Стандарты IEEE 1219 и ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality Model, 2001 г.) предлагают специализированные метрики, ориентированные именно на вопросы сопровождения и соответствующие программы.

Работы по сопровождению должны быть строго регламентированы и описаны, содержать детальные входы и выходы процессов. Эти процессы рассматриваются в стандартах IEEE 1219 и ISO / IEC 14764.

Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи ПС в эксплуатацию и касается таких вопросов, как планирование деятельности по сопровождению.

Стандарт ISO/IEC 14764 уточняет положения стандарта жизненного цикла 12207, связанные с процессом сопровождения. Работы по сопровождению, описанные в этом стандарте, аналогичны работам в IEEE 1219, за исключением того, что сгруппированы несколько иначе.

Рассмотрим подробнее выдержки из стандарта ГОСТ Р ИСО/МЭК 14764-2002, содержащего полный аутентичный текст международного стандарта ISO/IEC 14764.

В соответствии с ГОСТ Р ИСО/МЭК 14764-2002, описывающем процесс сопровождения программных средств, подробности процесса сопровождения ПС должны быть документально оформлены, чтобы персонал сопровождения действовал в рамках единого процесса. Система показателей (метрик) качества должна содействовать реализации процесса сопровождения и способствовать усовершенствованию (модернизации) данного ПС.

Сопроводитель должен (5.5.2.1 ГОСТ Р ИСО/МЭК 12207) проанализировать отчет (сообщение) о проблеме или предложение о модификации по их влиянию на организационные вопросы, существующую систему и интерфейсные связи с другими системами.

На основе проведенного анализа сопроводитель должен (5.5.2.3 ГОСТ Р ИСО/МЭК 12207) разработать варианты реализации изменения. До внесения изменений в систему сопроводитель должен (см. 5.5.2.5 ГОСТ Р ИСО/МЭК 12207) получить согласование выбранного варианта изменения в соответствии с договором и подтверждение того, что внесенное изменение удовлетворяет требованиям, установленным в договоре (см. 5.5.4.2 ГОСТ Р ИСО/МЭК 12207). Сопроводитель должен (5.5.2.4 ГОСТ Р ИСО/МЭК 12207) документально оформить: отчет о проблеме или предложение о модификации, результаты их анализа и варианты реализации изменений.

Для соответствующего контроля переноса системы должен быть (5.5.5.2 ГОСТ Р ИСО/МЭК 12207) разработан, документально оформлен и выполнен план переноса объекта. К планируемым работам должны быть привлечены пользователи.

Для деятельности по сопровождению существует ряд уникальных работ и практик, которые необходимо учитывать при организации сопровождения. SWEBOK (Software Engineering Body of Knowledge) приводит следующие примеры такого рода уникальных характеристик.

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

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

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

Анализ влияния: анализ возможных последствий изменений, вносимых в существующую систему.

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

Контракты и обязательства: к ним относятся классическое соглашение об уровне предоставляемого сервиса – Service Level Agreement (SLA), а также другие договорные аспекты, на основании которых, группа/служба/организация по сопровождению выполняет соответствующие работы.

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

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

Таблица 1. Стандарты в области сопровождения информационных систем

Стандарт	Название	Описание	На выходе
12207 IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК	Процессы жизненного цикла программных средств	Настоящий стандарт устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии.	1) Выдержки из отчётов пользователей о выявленных дефектах и предложенных корректировках (п. 5.5.2.1 ГОСТ Р ИСО/МЭК 12207 ) 2) Предложения по корректировке (п. 5.5.2.3 #M12291 1200009075 ГОСТ Р ИСО/МЭК 12207#S ) 3) Извещение пользователям о выпуске новой версии АС (п. 5.5.2.5 #M12291 1200009075 ГОСТ Р ИСО/МЭК 12207#S ) 4) План переноса объекта (п. 5.5.5.2 #M12291 1200009075 ГОСТ Р ИСО/МЭК 12207 )
14764 ISO/IEC ГОСТ Р ИСО МЭК	Сопровождение программных средств (Standard for Software Engineering – Software Maintenance)	Настоящий стандарт детализирует процесс сопровождения, установленный в 12207 (ISO/IEC , #M12291 1200009075 ГОСТ Р ИСО/МЭК)
9126 ISO/IEC ГОСТ Р ИСО/МЭК	Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению	Сопроводители должны иметь программу обеспечения качества программного средства, охватывающую шесть характеристик качества , установленных в #M12291 1200009076 ГОСТ Р ИСО/МЭК 9126#S . При сопровождении программного средства должен быть реализован соответствующий процесс для определения, описания, выбора, применения и совершенствования методик оценки (измерения) характеристик данного средства	Характеристики качества: 1) Функциональные возможности 2) Надежность 3) Практичность 4) Эффективность 5) Сопровождаемость 6) Мобильность
ГОСТ 34.603-92	Виды испытаний автоматизированных систем	Стандарт устанавливает виды испытаний АС и общие требования к их проведению. Испытания АС проводят на стадии «Ввода в действие» по ГОСТ 34.601 с целью проверки соответствия создаваемой АС требованиям технического задания (ТЗ)	Для планирования проведения всех видов испытании разрабатывают документ «Программа и методика испытания». В программе автономных испытании указывают: 1) перечень (функции, подлежащих испытаниям; 2) описание взаимосвязей объекта испытании с другими частями ПС; 3) условия, порядок и методы проведения испытании и обработки результатов; 4) критерии приемки частей по результатам испытании. Во время опытной эксплуатация ПС ведут рабочий журнал , в который заносят сведения о продолжительности функционирования АС, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке технических средств.
IEEE 1219-1998	Стандарт IEEE на сопровождение программного обеспечения (Standard for Software Maintenance)	Этот стандарт описывает итеративный процесс менеджмента и осуществления деятельности по сопровождению программного обеспечения. Использование данного стандарта не ограничено размером, сложностью, критичностью или применением программного продукта.

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

Рассмотрим применение стандартов по сопровождению информационных систем на конкретном примере. Качественное функционирование системы предполагает постоянную адаптацию к изменяющимся бизнес-процессам организации, а также быстрое реагирование на сбои и устранение неполадок. В связи с этим руководством ЗАО «Фирма «СофтИнКом» было принято решение о необходимости заключения договора с разработчиками корпоративной информационной системы (КИС) «Восточный экспресс» на обновление исопровождение системы.

Сопровождение КИС «Восточный экспресс» включает в себя сопровождение нескольких типов (по ГОСТу Р ИСО МЭК 14764-2002). А именно корректирующее сопровождение, которое связано с изменениями, вызванными необходимостью устранения (исправления) фактических ошибок в программном продукте. Корректирующее сопровождение проводят в случае несоответствия программного продукта установленным требованиям. А также адаптивное и полное сопровождение, модернизирующее программный продукт.

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

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

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

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

В таблице 2 приведены основные этапы сопровождения и выход в параграфе сопроводительной документации.

Таблица 2. Этапы процесса сопровождения информационной системы

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

В соответствии с 5.5.2.1 ГОСТ Р ИСО/МЭК 12207 сопроводитель должен проанализировать сообщения пользователей о проблеме. Для автоматизации регистрации и учета обращений пользователей КИС «Восточный экспресс» используется система регистрации инцидентов MantisBT. На основе данных, зарегистрированных в системе MantisBT формируется документ «Отчет о дефектах, выявленных пользователями», содержащий следующие поля: номер инцидента, дата создания, категория, суть инцидента, предлагаемое решение.

На основе проведенного анализа сопроводитель должен (5.5.2.3 ГОСТ Р ИСО/МЭК 12207) разработать варианты реализации изменений. Для этого разрабатывается документ «Журнал подготовленных и утвержденных корректировок новой базовой версии КИС», содержащий следующие данные: категория, недочет выявленный сопровождающей организацией, недочет выявленный пользователями КИС, корректировка.

Далее сопроводитель должен (5.5.4.2 ГОСТ Р ИСО/МЭК 12207) получить подтверждение того, что внесенное изменение удовлетворяет требованиям, установленным в договоре. Для этих целей формируется документ «Извещение пользователям о выпуске новой версии КИС» и ожидается подтверждение согласия об установке нового релиза.

Для соответствующего контроля переноса системы должен быть

ГОСТ 34.603-92 Виды испытаний автоматизированных систем

IEEE 1219-1998 Стандарт IEEE на сопровождение программного обеспечения

Сопровождение программного обеспечения (Software Maintenance по SWEBOK) // ‒ Режим доступа:

Журнал «Сетевой» №2.2001Статья «Жизненный цикл информационных систем» // ‒ Режим доступа: http://www.setevoi.ru/cgi-bin/text.pl/magazines/2001/2/44

Методология и технология разработки информационных систем. Профили открытых информационных систем // ‒ Режим доступа: http://gendocs.ru/v7394/лекции_по_теории_информационных_процессов_и_систем?page=9

Количество просмотров публикации: Please wait

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Стандарты IEEE

Введение

Отдельные типы сетей в настоящее время стандартизованы Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE -- Institute of Electrical and Electronics Engineers). Соответствующие стандарты определяют структуру сетей на физическом и канальном уровне модели OSI. Эти уровни в определенном смысле перекрываются друг с другом, поэтому стандарты описывают как физическую среду передачи данных, так и методы передачи пакетов. Другими словами, вы сможете узнать, как будет вести себя сеть, удовлетворяющая этим стандартам, и как эта сеть должна быть сконструирована для выполнения требуемых задач. Далее приводится обзор некоторых стандартов IEEE, ссылки на которые вы, вероятно, встре-тите, когда будете иметь дело с организацией сетей.

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

1. Стандарт 802.2

Стандарт 802.2 определяет правила передачи данных на канальном уровне для сетевых топологий, определенных в стандартах 802.3 - 802.5. Они применимы как к сетям Token Ring, так и к Ethernet, и описывают взаимодействие между сетевыми протоколами, например, TCP/IP, и сетями различных типов. Стандарт 802. 2 предусматривает функционирование сетей в режиме без соединения (для протоколов, которые не требуют установ-ления явного соединения) или в режиме, ориентированном на соединение, (т. е. предназначенном для протоколов, требующих явного установления соединения).

В стандарте IEEE канальный уровень разделяется на два подуровня: подуровень связи логических каналов (LLC -- Logical Link Connection), назы-ваемый также уровнем соединения канала передачи данных (DLC -- Data Link Connection), и на подуровень управления доступом к среде передачи (MAC - Media Access Control). На LLC-уровне обеспечивается управление интерфейсом между всеми сетевыми топологиями и их протоколами передачи данных (сетевого уровня). Для выполнения этой задачи средства LLC-уровня опираются на средства уровня MAC, предоставляющего определенные сведения об адресации информации. Используемый же метод адресации информации определяется типом сети.

2. Стандарт Ethernet (802.3 n )

Сеть Ethernet впервые была сконструирована в 70-х гг. доктором Робер-том Меткалфом (Robert Metcalfe) как часть проекта "офиса будущего". В то время это была сеть со скоростью работы 3 Мбит/с. В 1980 г. сеть Ethernet была стандартизована консорциумом фирм DEC-Intel-Xerox (DIX) как сеть со скоростью 10 Мбит/с, а в 1985 г.

Она была стандартизована 802-м коми-тетом IEEE. С тех пор новая технология Ethernet наследует признаки базовой структуры исходной схемы Ethernet, предусматривающей логическую шинную топологию и метод множественного доступа с контролем несущей и обна-ружением конфликтов (CSMA/CD - Carrier Sensing Multiple Access with Collision Detection).

В различных типах Ethernet используются различные физические топологии (например, звездообразная или шинная) и различные типы кабелей (например, UTP, коаксиальный, оптоволоконный).

Все сети Ethernet типа 10Base2, 10Base5, 10BaseT или 10BaseF являются "вари-ациями на тему" стандарта 802.3.

3. Основы Ethernet

Информация, "путешествует" по сети Ethernet в виде пакетов, каждый из которых состоит из шести частей.

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

Адрес назначения. Содержит аппаратный адрес ("зашитый" в плату Ethernet) рабочей станции или станций, которые принимают эту инфор-мацию.

Адрес источника. Позволяет принимающей рабочей станции распознать Рабочую станцию, пославшую информацию.

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

Фактические данные. Это может быть любая информация объемом от 46 до 1500 байтов.

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

На рис. 1 показаны части кадра Ethernet в соответствии со стандар-том 802.3

Рис 1 . Структура кадра сети Ethernet в соответствии со стандартом 802.3

Имеется несколько различных типов Ethernet, каждый со своим собст-венным номером и именем, под которым они наиболее известны. Эти типы описаны в табл. 1.

Таблица 1. Некоторые типы сетей Ethernet и их описание

Номер стандарта IEEE	Общеупотребительное название	Физическая топология и среда передачи данных	Пропускная способность
		Шинная, тонкий коаксиальный кабель
		Шинная, толстый коаксиальный кабель для магистрали, тонкий - для отводов
	100BaseT или Fast Ethernet	Звёздообразная, неэкранированная витая пара	100 Мбит/с (версия на 10 Мбит/с задана в 802.3)
	Gigabit Ethernet	Звездообразная, оптоволоконный кабель для магистрали, коаксиальный кабель для отводов к концентраторам	1000 Мбит/с

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

Независимо от типа сети, наиболее примечательной особенностью стандарта 802. Зn является метод множественного доступа с контролем несущей частоты и обнаружением конфликтов (CSMA/CD -- Carrier Sensing Multiple Access with Collision Detection).

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

Краткий ответ таков: невозможно. Однако этот ответ не такая уж большая неприятность: Ethernet рассчитана на возникновение конфликтов время от времени. Чтобы разобраться в CSMA/CD давайте разобьем это название на части. Слово "Carrier" (несущая) означает: все узлы перед попыткой передачи данных "слушают" сеть чтобы определить ее состояние (свободна или занята).

Слова "Multiple access" (множественный доступ) означают: все узлы сети имеют доступ к одному и тому же кабелю, т. е. выполняется широковеща-тельная передача сигнала по всей LAN. Наконец, слова "Collision detection" означают: любой узел может определить, что другой узел начал передачу в то время, когда первый узел еще передает данные. Короче, CSMA/CD предоставляет средства, позволяющие уменьшить вероятность конфликтов между пакетами путем использования каждым PC широковещательной пред-варительной передачи сигнала, называемого сигналом контроля несущей (carrier-sensing signal) перед передачей данных с целью определения, не ведет ли широковещательную передачу какая-либо другая рабочая станция.

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

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

Если же выполняется какое-либо из этих условий, то конфликт, скорее всего, произойдет, несмотря на использование метода CSMA/CD. Он не гарантирует передачу данных только одной рабочей станцией. Он обеспечивает лишь "молчание" всех станций перед тем, как одна из них начнет передачу. Если две рабочие станции случайно начнут пе-редачу одновременно, то средства CSMA/CD не смогут устранить конфликт.

Если же два пакета "перекрываются", то CSMA/CD позволит избежать повторения конфликта. Сразу после возникновения конфликта каждая рабочая станция выбирает случайное число между 1 и 2 перед повторением попытки передачи.

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

Тогда они выберут число между 1 и 4 и сделают вторую попытку. Процесс идет до тех пор, пока рабочие станции успешно не завершат передачу своих данных или пока не выполнят 16 безуспешных попыток. Если они не смогут устранить конфликт за шестнадцать попыток, обе рабочие станции сделают паузу и предоставят шанс другим станциям выполнить передачу данных.

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

Номер попытки	Диапазон чисел

В сети Gigabit Ethernet обеспечивается как полудуплексная передача данных для разделяемых областей сети (тех областей, в которых узлы "борются" за использование полосы пропускания сети), так и дуплексная, применяемая для неразделяемых областей, построенных по принципу "коммутатор к коммутатору".

Разделяемые области, в которых для устра-нения конфликтов пакетов используется метод CSMA/CD, взаимодействуют несколько иначе, чем разделяемые области, содержащие более медленные сети Ethernet. Это обусловлено повышенными скоростями линии связи.

Поскольку скорость сети высока, в применяемые способы синхронизации должны быть внесены изменения, иначе узлы не смогут "услышать" друг друга перед началом своей передачи. Поэтому в сетях Gigabit Ethernet для устройств, работающих в полудуплексном режиме (узлы сети), минимальный квант времени, предоставляемый каждому пакету, увеличивается от 64 до 512 байтов, т. е. каждому узлу предоставляется окно, достаточное для пе-редачи 512 байтов вместо 64.

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

Однако такое измене-ние метода синхронизации не способствует совместимости с медленными сетями Ethernet, в частности, потому, что в дуплексных областях сети Gigabit Ethernet используется такой же 64-битовый квант времени, что и в медленных разновидностях сетей, определенных стандартом 802.3n.

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

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

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

4. Стандарт Token Bus (802.4)

Пытаясь разработать стандарт сети, менее склонной к конфликтам, чем не предусмотрено стандартом 802. 3, подкомитет IEEE 802. 4 разработал такое сочетание шинной и кольцевой топологий, которое обеспечивает передачу информации через кольцо, но использует для этого физическую шинную топологию. Стандарт 802. 4 разработан как результат учета того,

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

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

Метод разрешения конфликтов не является единственным. Чем стан-дарт 802. 4 отличается от стандарта 802. 3? Во-первых, несколько отличается среда передачи данных: в сети Token Bus используется либо коаксиальный кабель с волновым сопротивлением 70 Ом (в отличие от кабеля с волновым сопротивлением 50 Ом в сетях 10Base2), либо оптоволоконный кабель. Во-вторых, как вы можете заметить на рис. 2, кадр сети Ethernet стандарта 802. 4 отличается от кадра стандарта 802. 3. Он содержит преамбулу, начальный разделитель кадра, управление кадром, адрес назначения, исходный адрес, данные, контрольную последовательность кадра, конечный разделитель кадра.

Рис 2. Структура кадра сети Ethernet в соответствии со стандартом 802.4Хотя комбинация средств маркер/шина позволяет устранить конфликты, стандарт 802. 4 имеет ряд недостатков, сдерживающих его широкое распро-странение.

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

5. Стандарт Token Ring (802.5)

Стандарт 802. 5 разработал комитет IEEE 802. 4 в союзе с фирмой IBM. Этот стандарт специально предназначен для сетей Token Ring, использую-щих маркерные методы пересылки информации от одной рабочей станции к другой.

Как и в случае со стандартом 802. 4, рабочие станции в сети Token Ring, построенные в соответствии со стандартом, используют маркер для определения того, какая рабочая станция должна передавать информацию и данный момент времени. Если она ничего не должна передавать, то передаёт следующей рабочей станции свободный маркер, и этот процесс продолжается до тех пор, пока маркер не достигнет рабочей станции, которой требуется передать данные.

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

Если данные предназначены этой рабочей станции, она сохраняет копию данных и посылает оригинал далее. Если данные не предназначены этой станции, она просто пересылает их следующей станции в сети. Когда посылающая рабочая станция получает обратно копию исход-ного пакета данных, она определяет, пора ли остановить передачу и послать свободный маркер (передать эстафету) следующей рабочей станции. Этот процесс проиллюстрирован на рис. 3,4,5.

Рис. 3 Шаг 1

Стандарт 802. 5 содержит несколько рекомендаций. С помощью интел-лектуальных концентраторов система Token Ring может восстанавливать соединение сети при неисправностях, вызванных аппаратными сбоями -- это прекрасная возможность, отсутствующая в стандарте Token Bus.

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

Рис. 4 Шаг 2

Сеть, определенная в соответствии со стандартом 802. 5, может обеспе-чивать связь на большее расстояние, чем сети, построенные в соответствии со стандартами 802. 3 и 802. 4, поскольку в ней пакет путешествует от одной станции до другой и при этом ретранслируется и, следовательно, расстояние между отдельными узлами сети может равняться предельно возможному (для данного типа кабеля).

Рис. 5 Шаг 3

Платы Token Ring присоединяются к устройствам MAU (Multistation Access Unit -- устройство многостанционного доступа) с помощью D-разъема, установленного внутри устройства. К устройству MAU можно подсоединить восемь PC. Кроме того, одни MAU могут быть соединены с другими MAU. В сети Token Ring отсутствуют терминаторы, так как один конец кабеля подключается к плате, а другой -- к устройству MAU.

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

Хотя сеть Token Ring имеет логическую кольцевую топологию, в ней используется физическая звездообразная топология. Вместо концентраторов в Token Ring применяются устройства MAU (Multistation Access Unit -- уст-ройство многостанционного доступа). Не спутайте эти устройства MAU с блоками доступа к среде передачи данных (также сокращенно называемых MAU - Medium Attachment Unit), которые являются приемо-передающими соединениями с AUI-портом адаптеров Ethernet.

Подобные документы

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

курсовая работа , добавлен 30.07.2015


История появления сотовой связи, ее принцип действия и функции. Принцип работы Wi-Fi - торговой марки Wi-Fi Alliance для беспроводных сетей на базе стандарта IEEE 802.11. Функциональная схема сети сотовой подвижной связи. Преимущества и недостатки сети.

реферат , добавлен 15.05.2015


Архитектура, компоненты сети и стандарты. Сравнение стандартов беспроводной передачи данных. Типы и разновидности соединений. Безопасность Wi-Fi сетей, адаптер Wi-Fi ASUS WL-138g V2. Интернет-центр ZyXEL P-330W. Плата маршрутизатора Hi-Speed 54G.

реферат , добавлен 18.02.2013


Анализ стандарта беспроводной передачи данных. Обеспечение безопасности связи, основные характеристики уязвимости в стандарте IEEE 802.16. Варианты построения локальных вычислительных сетей. Виды реализаций и взаимодействия технологий WiMAX и Wi-Fi.

курсовая работа , добавлен 13.12.2011


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

презентация , добавлен 28.01.2015


Знакомство с современными цифровыми телекоммуникационными системами. Принципы работы беспроводных сетей абонентского радиодоступа. Особенности управления доступом IEEE 802.11. Анализ электромагнитной совместимости группировки беспроводных локальных сетей.

дипломная работа , добавлен 15.06.2011


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

дипломная работа , добавлен 09.07.2015


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

курсовая работа , добавлен 06.01.2013


Протокол беспроводной передачи данных, помогающий соединить n-ное количество компьютеров в сеть. История создания первого Wi-Fi. Стандарты беспроводных сетей, их характеристики, преимущества, недостатки. Использование Wi-Fi в промышленности и быту.

реферат , добавлен 29.04.2011


Общие сведения о Bluetooth’е, что это такое. Типы соединения, передача данных, структура пакета. Особенности работы Bluetooth, описание его протоколов, уровня безопасности. Конфигурация профиля, описание основных конкурентов. Спецификации Bluetooth.

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

Согласно стандарту IEEE-90 под конфигурацией ПО понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в ПО . Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в стандарте ISO / IEC 15288 " Information Technology . Software Life Cycle Process. Configuration Management for Software ".

Процесс управления конфигурацией включает следующие действия:

1. подготовительную работу, заключающуюся в планировании управления конфигурацией;
2. идентификацию конфигурации, устанавливающую правила, с помощью которых однозначно идентифицируются компоненты ПО и их версии. При этом каждому компоненту однозначно соответствует комплект документации;
3. контроль конфигурации – действие, предназначенное для систематической оценки предлагаемых модификаций ПО и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение;
4. учет состояния конфигурации, представляющий собой регистрацию состояния компонентов ПО. Обеспечивает подготовку отчетов о реализованных и отвергнутых модификациях версий компонентов ПО. Совокупность отчетов дает однозначное отражение текущего состояния системы и ее компонентов, а также обеспечивает ведение истории модификаций;
5. оценку конфигурации, заключающуюся в определении функциональной полноты компонентов ПО, а также соответствия их физического состояния текущему техническому описанию;
6. управление выпуском и поставку, охватывающие изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятом в организации.

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

Процесс обеспечения качества включает следующие действия:

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

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

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

1. непротиворечивость требований, предъявляемых к системе, и степень учета потребностей пользователей;
2. возможность поставщика выполнить заданные требования;
3. соответствие выбранных процессов ЖЦ ПО условиям договора;
4. адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;
5. соответствие проектных спецификаций ПО заданным требованиям;
6. корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;
7. соответствие кода проектным спецификациям и требованиям;
8. тестируемость и корректность кода, его соответствие принятым стандартам кодирования;
9. корректность интеграции компонентов ПО в систему;
10. адекватность, полнота и непротиворечивость документации.

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

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

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

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

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

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

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

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

5.4. Организационные процессы ЖЦ ПО

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

Структура ЖЦ ПО в соответствии со стандартом ISO/IEC 12207 базируется на трех группах процессов (рис. 1):

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

· организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Рис. 1. Процессы жизненного цикла программного обеспечения.

Процесс приобретения (acquisition process). Он состоит из действий

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

1) инициирование приобретения;

2) подготовку заявочных предложений;

3) подготовку и корректировку договора;

4) надзор за деятельностью поставщика;

5) приемку и завершение работ.

Процесс поставки (supply process). Он охватывает действия и задачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой. Данный процесс включает следующие действия:

1) инициирование поставки;

2) подготовку ответа на заявочные предложения;

3) подготовку договора;

4) планирование;

5) выполнение и контроль;

6) проверку и оценку;

7) поставку и завершение работ.

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

Процесс разработки включает следующие действия:

1) анализ требований к системе;

2) проектирование архитектуры системы;

3) анализ требований к ПО;

4) проектирование архитектуры ПО;

5) детальное проектирование ПО;

6) кодирование и тестирование ПО;

7) интеграцию ПО;

8) квалификационное тестирование ПО;

9) интеграцию системы;

10) квалификационное тестирование системы;

11) установку ПО;

12) приемку ПО.

Процесс эксплуатации (operation process). Он охватывает действия и задачи оператора - организации, эксплуатирующей систему. Данный процесс включает следующие действия:

1) эксплуатационное тестирование;

2) эксплуатацию системы;

3) поддержку пользователей.

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

требованиям. Изменения, вносимые в существующее ПО, не должны нарушать

его целостность. Процесс сопровождения включает перенос ПО в другую среду (миграцию) и заканчивается снятием ПО с эксплуатации.

Процесс сопровождения охватывает следующие действия:

1) анализ проблем и запросов на модификацию ПО;

2) модификацию ПО;

3) проверку и приемку;

4) перенос ПО в другую среду;

5) снятие ПО с эксплуатации.

В группу вспомогательных процессов включены:

Документирование;

Управление конфигурацией; обеспечение качества;

Верификация; аттестация;

Совместная оценка;

Разрешение проблем.

Процесс документирования (documentation process). Он предусматривает формализованное описание информации, созданной в течение ЖЦ ПО. Процесс документирования включает следующие действия:

1) проектирование и разработку;

2) выпуск документации;

3) сопровождение документации.

Процесс управления конфигурацией (configuration management process). Он предполагает применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО. Согласно стандарту IEEE-90 под конфигурацией ПО понимается совокупность его функциональных и физических ха-

рактеристик, установленных в технической документации и реализованных в ПО.

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/I EC CD 12207-2: 1995 "Information Technology - Software Life Cycle Processes. Part 2.

Configuration Management for Software". Процесс управления конфигурацией включает следующие действия:

1) идентификацию конфигурации;

2) контроль конфигурации;

3) учет состояния конфигурации;

4) оценку конфигурации;

5) управление выпуском и поставку.

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

1) обеспечение качества продукта;

2) обеспечение качества процесса;

3) обеспечение прочих показателей качества системы.

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

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

Процесс совместной оценки (joint review process). Он предназначен для оценки состояния работ по проекту и ПО, создаваемого при выполнении данных работ (действий). Он сосредоточен в основном на контроле планирования и управления ресурсами, персоналом, аппаратурой и инструментальными средствами проекта.

Процесс аудита (audit process). Он представляет собой определение соответствия требованиям, планам и условиям договора.

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

В группу организационных процессов ЖЦ ПО входят:

Управление;

Создание инфраструктуры;

Усовершенствование;

Выпуск новых версий;

Обучение.

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

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

Процесс усовершенствования (improvement process). Он предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО. Усовершенствование процессов ЖЦ ПО направлено на повышение производительности труда всех участвующих в них специалистов за счет совершенствования используемой технологии, методов управления, выбора инструментальных средств и обучения

персонала.

Процесс обучения (training process). Он охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.

Цели и задачи методологии проектирования ПО . Основные области проектирования ПО . Этапы создания ПО .

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

Программные средства (Software product) - набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных.

Программный продукт (Software product) - любой набор компьютерных программ, процедур и связанных с ними документации и данных, получаемых в результате разработки ПП и предназначенных для поставки пользователю [ИСО/МЭК 12207]. Примечание. Продукты включают промежуточные продукты и продукты, предназначенные для пользователей типа разработчиков и персонала сопровождения.

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

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

Программирование - это один из видов деятельности, входящих в цикл разработки программного обеспечения.

Этапы создания ПО

1. Понять природу и сферу применения предлагаемого продукта.

2. Выбрать процесс разработки и создать план.

3. Собрать требования.

4. Спроектировать и собрать продукт.

5. Выполнить тестирование продукта.

6. Выпустить продукт и обеспечить его сопровождение.

Под жизненным циклом программы будем понимать совокупность этапов:

Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)

Проектирование структуры программы

Кодирование (набор программного кода согласно проектной документации)

Тестирование и отладка

Внедрение программы

Сопровождение программы

Утилизация

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Основные процессы ЖЦ ПО.

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

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

Основные процессы ЖЦ :

Заказ (приобретение);

Действие - инициирование приобретения

Действие – подготовка заявочных предложений

Действие - подготовка и корректировка договора

Действие - надзор за деятельностью поставщика

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

Поставка;

Инициирование поставки

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

Разработка;

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

Подготовительная работа

Анализ требований к системе

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

Анализ требований к ПО

Проектирование архитектуры ПО

Кодирование и тестирование ПО

Интеграция ПО

Квалификационное тестирование ПО

Интеграция системы

Установка ПО

Приемка ПО

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

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

планирование действий и работ, выполняемых в процессе эксплуатации, и установку эксплуатационных стандартов;

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

Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она передается в эксплуатацию.

Эксплуатация системы

Поддержка пользователей

Процесс сопровождения предусматривает действия и задачи, выполняемые службой сопровождения. В соответствии со стандартом IEEE-90 под сопровождением понимается внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.

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

планирование действий и работ, выполняемых в процессе сопровождения;

определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

Анализ проблем и запросов на модификацию ПО

Модификация ПО

Проверка и приемка

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

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Вспомогательные процессы ЖЦ ПО.

См. пункт 2

Вспомогательные процессы ЖЦ :

Документирование ; формализованное описание информации, созданной в течение ЖЦ ПО.

Процесс документирования включает действия:

подготовительную работу;

проектирование и разработку;

выпуск документации;

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

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

подготовительную работу

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

контроль конфигурации предназначен для систематической оценки предполагаемых модификаций ПО и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение

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

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

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

Обеспечение качества;

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

Процесс обеспечения качества включает действия:

подготовительная работа

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

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

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

подготовительную работу;

верификацию;

В процесс верификации проверяются следующие условия:

непротиворечивость требований к системе и степень учета потребностей пользователей;

возможности поставщика выполнять заданные требования;

соответствие выбранных процессов ЖЦ ПО условиям договора;

адекватность стандартов, процедур и среды разработки процесса ЖЦ ПО;

соответствие проектных спецификаций ПО заданным требованиям;

корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики;

соответствие кода проектным спецификациям и требованиям;

тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

корректность интеграции компонентов ПО в систему;

адекватность, полнота и непротиворечивость документации.

Аттестация ;

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

Совместная оценка (Совместный анализ); для оценки состояния работ по проекту и ПО.

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

Процесс совместной оценки включает действия:

подготовительную работу;

оценку (анализ) управления проектом;

техническую оценку.

Аудит ;

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

Разрешение (Решение) проблем .

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

Понятие жизненного цикла (ЖЦ) программного обеспечения. Определение ЖЦ международным стандартом ISO/IEC 12207:1995. Организационные процессы ЖЦ ПО. Взаимосвязь между процессами ЖЦ ПО.

См пункт2

Организационные процессы ЖЦ :

Управление;

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

Процесс управления включает следующие действия:

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

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

составление графиков выполнения работ;

оценку затрат;

выделение требуемых ресурсов;

распределение ответственности;

оценку рисков, связанных с конкретными задачами;

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

выполнение и контроль;

проверка и оценка;

завершение.

Создание инфраструктуры;

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

Усовершенствование;

предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

Обучение.

охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.

Взаимосвязь между процессами ЖЦ ПО

Процессы ЖЦ ПО, регламентированные стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (рис.1). Такими аспектами являются:

договорный аспект;

аспект управления;

аспект эксплуатации;

инженерный аспект;

аспект поддержки.

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

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

Понятие модели и стадии ЖЦ ПО. Характеристика стадий создания ПО .

1) Международный стандарт ISO / IEC 12207: 1995 так определяет модель ЖЦ:

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

2) ГОСТ Р ИСО/ МЭК 12207-99 так определяет модель ЖЦ:

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

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

В состав ЖЦ ПО обычно включают следующие стации:

Формирование требований к ПО.

Проектирование.

Реализация.

Тестирование.

Ввод в действие.

Эксплуатация и сопровождение.

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

Понятие модели жизненного цикла программного обеспечения. Водопадная (каскадная) модель жизненного цикла программного обеспечения.

См пункт 5

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

Преимущества применения каскадного способа :

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

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

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

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

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

Понятие модели жизненного цикла программного обеспечения. Модель быстрой разработки приложений. См. п. 5

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

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

короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

Выделяют следующие этапы процесса RAD-разработки :

Бизнес-моделирование . Моделируются информационные потоки между бизнес-функциями.

Моделирование данных . Информационный поток отображается в набор объектов данных.

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

Генерация приложения . Используются языки программирования 4-го поколения, готовые компоненты, для конструирования утилиты автоматизации.

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

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

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

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

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

Не применима в условиях высоких технических рисков, т.е. при использовании новой технологии.

Понятие модели жизненного цикла программного обеспечения. V-образная модель жизненного цикла программного обеспечения.

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

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

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

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

Рис. . V-модель жизненного цикла

Ниже дано краткое описание каждой фазы V-образной модели, начиная от планирования проекта и требований вплоть до приемочных испытаний:

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

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

архитектура или проектирование на высшем уровне – определяет, каким образом функции ПО должны применяться при реализации проекта;

детализированная разработка проекта – определяет и документально обосновывает алгоритмы для каждого компонента, который был определен на фазе построения архитектуры. Эти алгоритмы в последствии будут преобразованы в код;

разработка программного кода – выполняется преобразование алгоритмов, определенных на этапе детализированного проектирования, в готовое программного обеспечения;

модульное тестирование – выполняется проверка каждого закодированного модуля на наличие ошибок;

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

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

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

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

преимуществ:

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

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

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

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

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

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

недостатки :

с ее помощью непросто справиться с параллельными событиями;

в ней не учтены итерации между фазами;

в модели не предусмотрено внесение требования динамических изменений на разных этапах ЖЦ;

тестирование требований в ЖЦ происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта;

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

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

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

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

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

Понятие модели жизненного цикла программного обеспечения. Спиральная модель Боэма жизненного цикла программного обеспечения.

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

Как показано на рис. 3, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

Планирование - определение целей, вариантов и ограничений.

Анализ риска - анализ вариантов и распознавание/выбор риска.

Конструирование - разработка продукта следующего уровня.

Оценивание - оценка заказчиком текущих результатов конструирования.

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