Будь умным!


У вас вопросы?
У нас ответы:) SamZan.net

. Жизненный цикл ПО ГОСТ 519042002 В настоящем стандарте рассмотрены следующие процессы ЖЦ ПО Процесс плани

Работа добавлена на сайт samzan.net:

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Выберите тип работы:

Скидка 25% при заказе до 2.11.2024

1. Жизненный цикл ПО (ГОСТ 51904-2002)

В настоящем стандарте рассмотрены следующие процессы ЖЦ ПО:

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

Процессы разработки:

- процесс определения требований к ПО;

- процесс проектирования ПО;

- процесс кодирования ПО;

- процесс интеграции.

Интегральные процессы (обеспечивают корректную реализацию и качество выполнения процессов разработки и их выходных данных):

- процесс верификации ПО;

- процесс управления конфигурацией ПО;

- процесс обеспечения качества ПО;

- процесс сертификационного сопровождения.

Интегральные процессы выполняются одновременно с процессами разработки ПО.

2. Модели ЖЦ ИС (ГОСТ 15271-2002)

Общая модель ЖЦ системы разделяется на стадии:

a) определение потребностей;

b) исследование и описание основных концепций;

c) демонстрация и аттестация основных концепций;

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

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

f распространение и продажа;

g) эксплуатация;

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

i) снятие с эксплуатации (утилизация).

Фундаментальные модели ЖЦ ИС:

- каскадная;

- инкрементная;

- эволюционная.

М.б. использованы самостоятельно или скомбинированы в гибридную модель.

Выбор модели: процессы, работы и задачи из ГОСТ Р ИСО/МЭК 12207 связаны м/у собой и определены их взаимосвязи с предшествующими процессами, работами и задачами.

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

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

- установление потребностей пользователя;

- определение требований;

- проектирование системы;

- изготовление системы;

- испытание;

- корректировка;

- поставка или использование.

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

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

Недостатки

a) требования к объектам определены недостаточно четко;

b) система обычно слишком велика, чтобы все работы по ее созданию выполнять однократно;

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

Преимущества

a) однократное представление всех возможностей (характеристик) системы;

b) необходимость только единственной фазы перехода от старой системы к новой.

Инкрементная модель (запланированное усовершенствование продукта)

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

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

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

Недостатки

а) требования к объектам определены недостаточно четко;

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

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

d) возможные текущие изменения требований к системе;

е) привлечение ресурсов (средств или персонала) на длительный период ограничено.

Преимущества

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

b) пригодность для использования промежуточного продукта;

c) естественное разделение системы на наращиваемые компонент (инкременты);

d) возможности наращивания привлекаемого персонала и средств.

Эволюционная модель

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

Работы и задачи процесса разработки выполняют последовательно или параллельно с частичным перекрытием.

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

Недостатки

а) все возможности системы предопределены изначально;

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

Преимущества

a) изначальное определение возможностей системы;

b) пригодность для использования промежуточного продукта;

b) естественное разделение системы на наращиваемые компонент (инкременты);

d) привлечение персонала и средств по мере необходимости;

e) необходимая обратная связь с пользователем для полного понимания требований;

f) упрощение надзора за изменением технологии.

3. Методологии проектирования. Каноническое проектирование

В основе – каскадная модель ЖЦ ИС.

Процесс каскадного проектирования в ЖЦ ИС (ГОСТ 34.601-90):

Стадия 1. Формирование требований к ИС. Этапы работ:

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

Стадия 2. Разработка концепции ИС.

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

Стадия 3. Техническое задание.

  •  разработка и утверждение ТЗ на создание ИС.

Стадия 4. Эскизный проект.

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

Стадия 5. Технический проект.

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

Стадия 6. Рабочая документация.

  •  разработка рабочей документации на ИС и ее части;
  •  разработка и адаптация программ.

Стадия 7. Ввод в действие.

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

Стадия 8. Сопровождение ИС.

  •  выполнение работ в соответствии с гарантийными обязательствами;
  •  послегарантийное обслуживание.

4. Методологии проектирования. Типовое проектирование.

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

Типовое проектное решение (ТПР) – тиражируемое (пригодное к многократному использованию) проектное решение.

Класс ТПР / Реализация ТПР

Достоинства

Недостатки

Элементные ТПР

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

Библиотеки методо-ориентированных программ

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

Подсистемные ТПР

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

Пакеты прикладных программ

(ППП)

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

Объектные ТПР

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

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

5. Процессы жизненного цикла информационной системы. ГОСТ 12 207.

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

1) Процесс заказа (работа заказчика).

2) Процесс поставки (работа поставщика).

3) Процесс разработки (работа разработчика).

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

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

Вспомогательные процессы ЖЦ – целенаправленная составная часть другого процесса, обеспечивает успешную реализацию и качество выполнения программного проекта.

1) Процесс документирования (описание информации, выдаваемой в процессе ЖЦ).

2) Процесс управления конфигурацией.

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

4) Процесс верификации. 

5) Процесс аттестации. 

6) Процесс совместного анализа (оценка состояния и результатов какой-либо работы).

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

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

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

1) Процесс управления (управление проектом при реализации процессов ЖЦ).

2) Процесс создания инфраструктуры (создание основной структуры процесса ЖЦ).

3) Процесс усовершенствования.

4) Процесс обучения персонала.

6. Процессы жизненного цикла информационной системы. Процессы планирования.

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

Планирование позволяет:

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

Цели процесса планирования ПО:

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

В процессе планирования ПО должны быть выполнены следующие работы:

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

В процессе планирования ПО должны быть разработаны следующие планы:

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

Планы ПО должны указывать:

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

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

7. Процессы ЖЦ ИС. Процессы определения требований к ИС.

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

Требования к ПО д.б.: документируемые, выполнимые, тестируемые, с уровнем детализации достаточным для проектирования системы. Требования м.б. функциональными и нефункциональными.

Анализ требований включает три типа деятельности:

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

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

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

  •  разработать требования верхнего уровня;
  •  оценить производные требования верхнего уровня с т.з. безопасности системы.

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

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

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

8. Процессы ЖЦ ИС. Процессы проектирования.

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

Цели:

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

Входные данные: требования к ПО, План разработки ПО и стандарты на процесс проектирования ПО.

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

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

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

9. Процессы ЖЦ ИС. Процессы кодирования.

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

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

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

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

Требования к исходному коду должны быть следующие:

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

10. Процессы ЖЦ ИС. Процессы интеграции.

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

Цель: получение интегрированной системы.

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

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

Требования процесса интеграции:

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

11. Процессы планирования. Планирование инфраструктуры проекта

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

Цели процесса планирования ПО:

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

В процессе планирования ПО должны быть выполнены следующие работы:

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

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

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

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

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

12. Процессы планирования. Планирование ресурсов проекта.

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

При планировании вводят 2 основных типа ресурсов: возобновляемые и невозобновляемые.

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

Невозобновляемые: не могут повторно использоваться (топливо, финансовые ресурсы и т.п).

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

Затем строится профиль доступности ресурсов: показывает наличие ресурсов в каждый момент времени реализации проекта.

Затем строят ресурсные гистограммы, показывающие перегрузку/недогрузку ресурсов. Распределение ресурса по задачам – вертикальные закрашенные столбцы, расположенные под соответствующими задачами. Ширина столбца = продолжительности задач. Высота столбца = размеру суммарного объема назначения данного ресурса по параллельным задачам. Пунктирная линия = пороговое значение загрузки ресурса. Перегруженная часть ресурса выступает на гистограмме над пунктирной линией. 

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

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

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

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

13. Стратегии и методы проектирования информационных систем.

Метод «снизу-вверх»

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

Метод «сверху-вниз»

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

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

Принципы «дуализма» и многокомпонентности.

Развитие промышленных предприятий, рост количества клиентов, необходимость повышения качества обслуживания предъявляли к автоматизированным системам новые требования. Новый подход к проектированию АИС заключается в сбалансированном сочетании двух предыдущих.

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

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

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

ПОД СТРАТЕГИЕЙ ПОНИМАЕТСЯ:

- Определение организационной структуры проекта автоматизации;

- Определение основных информационных потоков;

- Проведение стратегического анализа деятельности фирмы;

- Выбор технической и программной базы ИС;

- Выбор архитектуры и стандартов ИС;

- Определение экономической эффективности ИС.

14. Анализ объекта автоматизации. Методологии анализа

SADT (Structured Analysis and Design Technique) — методология структурного анализа и проектирования, интегрирует процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых ср-в и руководство проектом со своим графическим языком. Этапы: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Процесс хорошо отлажен, т.к. при разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь обеспечивает своевременный обмен информацией.

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

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

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

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

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

4. Координация процесса рецензирования. Необходим наблюдатель за процессом рецензирования (библиотекарь).

5. Модели используются после их одобрения. Цель (диаграмма А-0) определяет, как будет использоваться модель. Т.о., как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели.

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

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

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

Виды диаграмм:

Структурные диаграммы:

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

Диаграммы поведения:

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

RUP (Rational Unified Process) – методология разработки ПО. Принципы:

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

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

1. Начало (Inception)

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

При завершении оценивается достижение вехи целей ЖЦ, которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration) – анализ предметной области, построение исполняемой архитектуры.

  •  Документирование требований (+ детальное описание для большинства прецедентов).
  •  Спроектированная, реализованная и оттестированная исполняемая архитектура.
  •  Обновленное эк. обоснование и более точные оценки сроков и стоимости.
  •  Сниженные основные риски.

Итог: достижение вехи архитектуры ЖЦ.

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

4. Внедрение (Transition) – финальная версия продукта, передача от разработчика к заказчику. Программа бета-тестирования, обучение пользователей, определение качества продукта. Если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется. Итог: веха готового продукта и завершение полного цикла разработки.

ARIS (Architecture of Integrated Information Systems). Точки зрения:

  1.  Организационная структура,
  2.  Функциональная структура,
  3.  Структура данных,
  4.  Структура процессов.

Подуровни: описание требований, описание спецификации, описание внедрения.

Возможные методы описания:

  1.  EPC (event-driven process chain) – метод описания процессов (система SAP R/3);
  2.  ERM (Entity Relationship Model) – модель сущность-связь д/описания структуры данных;
  3.  UML (Unified Modeling Language)объектно-ориентированный язык моделирования.

Скрипт — это инструмент ARIS, с помощью которого автоматизируется составление различных аналитических отчётов, нормативных документов, новых моделей. Подпрограмма, запускаемая в ARIS Toolset или непосредственно на сервере ARIS. Пишутся на спец. языке программирования (SAX Basic). ARIS Script позволяет в автоматическом режиме производить:

  1.  Формирование нормативных документов на основании моделей ARIS (паспорт процесса, регламент процесса и т. п.).
  2.  Формирование аналитических отчётов на основании моделей ARIS.
  3.  Интеграция ARIS Toolset с другими приложениями и базами данных.
  4.  Формирование базы моделей ARIS на основании готовых спецификаций.

15. Анализ объекта автоматизации. Инструментальные средства поддержки анализа.

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

Классификация инструментальных средств

  •  локальные, поддерживающие 1-2 типа моделей и методов (Design/IDEF, ProCap, S-Designor, "CASE. Аналитик");
  •  малые интегрированные средства моделирования, поддерживают несколько типов моделей и методов (ERwin, BPwin);
  •  средние интегрированные средства моделирования, поддерживающие от 4 до 10-15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);
  •  крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).

16. Процессы проектирования. Проектирование системной архитектуры

СИСТЕМНАЯ АРХИТЕКТУРА С Т.З. СТРУКТУРЫ

Репозиторий

Структура репозитория: все данные, используемые в ИС, хранятся в единой БД, и всем подсистемам ИС репозиторий предоставляет одинаковые права на доступ к данным. Репозиторий – пассивный элемент, все управление перелагается на разные подсистемы. Такой подход стоит применять, если в ИС обрабатывается очень большой объем медленно изменяемых данных.

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

- Нет возможности обеспечить разный уровень доступа к информации.

Клиент-сервер

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

+ Можно создать распределенную архитектуру. Это позволяет увеличить производительность за счет распределения задач м/у отдельными физическими компонентами.

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

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

Многоуровневая система (абстрактная машина)

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

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

- Уровни логические. Исходный код отдельных элементов сильно связан. Изменение одного уровня влечет изменение других.

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

АРХИТЕКТУРА С Т.З. УПРАВЛЕНИЯ

Управление компонентами

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

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

Управление потоками данных

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

+ простой анализ потоков управления.

-ложность в обработке исключительных событий.

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

ОБЩИЕ МОМЕНТЫ ПРИ ПРОЕКТИРОВАНИИ СИСТЕМНОЙ АРХИТЕКТУРЫ

Необходимо определиться с компонентами системы, которые будут объединены в понятие системной архитектуры (клиент, СУБД, сервер приложений и т.п.).

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

Определить программно-аппаратные и аппаратные требования.

17. Процессы проектирования. Методики описания системной архитектуры

Методика выбора архитектуры

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

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

Общие цели и задачи объекта автоматизации.

IT инфраструктуру и связанные с ней IT-услуги (сервис).

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

Методы описания информационной архитектуры:

Методика описания архитектуры по модели Захмана. В основе – матрица Захмана, которая с одной стороны определяет уровень детализации, с другой стороны – рассматриваемые аспекты на каждом уровне детализации. Матрица состоит из:

  1.  Уровня контекста (взгляд бизнес-аналитика на внешние требования и движущие факторы бизнес-процесса).
  2.  Модель бизнеса (взгляд владельца бизнеса: модели бизнес-процесса «изнутри»).
  3.  Системная модель (взгляд проектировщика ИС).
  4.  Технологическая модель (взгляд разработчика ИС).
  5.  Детальная модель. Уровень реализации (взгляд на уровне программиста).

Аспекты (столбцы матрицы):

  1.  Кто?
  2.  Почему?
  3.  Что? (данные);
  4.  Как?
  5.  Где? (физическое расположение: куда мы будем ориентироваться).

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

Метод Захмана позволяет достаточно формально описать ИС с различных т.з. Позволяет сохранить независимость логических и технологических решений от детальных моментов, связанных с применением тех или иных технологий и того или иного программного решения.

Методики Гигагрупп.

Методика POSIX.

Методика ТОГА.

18. Процессы проектирования. Архитектурные стили и шаблоны проектирования

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

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

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

СИСТЕМНАЯ АРХИТЕКТУРА С Т.З. СТРУКТУРЫ

Репозиторий

Структура репозитория: все данные, используемые в ИС, хранятся в единой БД, и всем подсистемам ИС репозиторий предоставляет одинаковые права на доступ к данным. Репозиторий – пассивный элемент, все управление перелагается на разные подсистемы. Такой подход стоит применять, если в ИС обрабатывается очень большой объем медленно изменяемых данных.

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

- Нет возможности обеспечить разный уровень доступа к информации.

Клиент-сервер

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

+ Можно создать распределенную архитектуру. Это позволяет увеличить производительность за счет распределения задач м/у отдельными физическими компонентами.

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

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

Многоуровневая система (абстрактная машина)

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

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

- Уровни логические. Исходный код отдельных элементов сильно связан. Изменение одного уровня влечет изменение других.

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

АРХИТЕКТУРА С Т.З. УПРАВЛЕНИЯ

Управление компонентами

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

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

Управление потоками данных

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

+ простой анализ потоков управления.

-ложность в обработке исключительных событий.

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

19.Процессы проектирования. Проектирование информационной архитектуры

ИА – организация интерактивного визуального представления больших массивов данных.

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

Этапы создания ИА:

1) Формирование логической структуры данных Непосредственное взаимодействие системного архитектора с заказчиком. Формальный метод описания: формирование диаграмм сущность-связь. Логические диаграммы ER модели должны однозначно пониматься как исполнителем, так и заказчиком и являются обязательным элементов ТЗ.

2) Формирование физической структуры данных. Физическая модель – графическое представление реально реализованной БД. Состоит из таблиц, столбцов и связей. Зависит от платформы, выбранной для реализации, и требований к использованию данных.

Нормализация данных позволяет обеспечить целостность и непротиворечивость хранимых данных. Теории нормализации – 6 нормальных форм хранения данных.

  1.  Первая нормальная форма.
  2.  Запрещается иметь повторяющиеся атрибуты.
  3.  Запрещаются составные атрибуты.
  4.  Обязательное определите первичного ключа сущности.
  5.  Вторая нормальная форма.
  6.  Выполнение первой нормальной формы.
  7.  все неключевые атрибуты должны зависеть от первичного ключа целиком.
  8.  Третья нормальная форма.
  9.  Выполнение первой и второй нормальных форм.
  10.  Все неключевые атрибуты должны быть независимы друг от друга и зависеть только от первичного ключа.
  11.  Нормальная форма Бойса-Кодда.
  12.  Выполнение первой, второй, третей.
  13.  У каждой сущности должен быть только один потенциальный первичный ключ.
  14.  Четвертая нормальная форма.
  15.  Подразумевает выполнение 1-4.
  16.  Необходимо устранить имеющиеся многозначные зависимости. Изменение одно из атрибутов не должно приводить к изменению других атрибутов или их модификации.
  17.  Пятая нормальная форма.
  18.  Подразумевает 1-5.
  19.  Устранены зависимости соединений сущностей.

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

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

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

Процедура – записанный в БД стандартные набор операций, которые вызываются пользователем по имени. Цель: защита целостности БД.

Представление – текущий слепок реальной БД по какому-то запросу. Обычно результаты стандартных запросов хранят в виде представлений. Наличие представлений обеспечивает быстродействие и безопасность.

20. Процессы проектирования. Построение ER модели. Виды нотаций.

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

Формальная конструкция, которая сама по себе не предписывает никаких графических средств её визуализации. Стандартная графическая нотация – диаграмма сущность-связь (ER-диаграмма).

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

Набор сущностей – множество сущностей одного типа (обладающих одинаковыми свойствами) (все люди).

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

Ключ сущности – один или более атрибутов уникально определяющих данную сущность.

Связь – ассоциация, установленная между несколькими сущностями.

Набор связей – отношение между n сущностями, каждая из которых относится к некоторому набору сущностей.

Один - к одному. Каждому объекту первого вида соответствует не более 1 объекта второго вида, и наоборот (сотрудник руководит только 1 отделом, и у каждого отдела только 1 руководитель).

Один - ко многим. Каждому объекту первого вида может соответствовать более 1 объекта второго вида, но каждому объекту второго вида соответствует не более 1 объекта первого вида (в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в 1 отделе).

Много – к одному. Каждому объекту первого вида может соответствовать не более 1 объекта второго вида, но каждому объекту второго вида соответствует более 1 объекта первого вида (с одним заказчиком может быть заключено более 1 контракта, то связь будет иметь степень n : 1)

Многие - ко многим. Каждому объекту первого вида может соответствовать более 1 объекта второго вида, и наоборот (каждый сотрудник может входить в несколько рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь имеет степень n : n).

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

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

План создания ER модели

  1.  Получение информации о возможном списке сущностей, необходимых атрибутах и взаимосвязях сущностей.
  2.  Среди описанных сущностей формируются градации на обязательные и важные, и вспомогательные. Просматривается список атрибутов сущностей с целью возможного перевода атрибутов в самостоятельную сущность.
  3.  Формируется графическое представление сущностей и отношений между ними без учета атрибутов. Основной упор делается на отношениях между сущностями (с целью выявить противоречия и циклические связи). Каждая связь подразумевает двойное описание.
  4.  После того, как логическая структура данных проверена на отсутствие логических дыр, наступает работа с атрибутами сущностей. К каждой сущности формируется набор ее атрибутов (те свойства, которые обязательны с точки зрения заказчика).
  5.  Выделение среди атрибутов возможных ключевых атрибутов. Ключ может быть составным, может вводиться дополнительный атрибут (например, цифровой идентификатор, являющийся ключом). На этом этапе возможно выделение каких-то отдельных атрибутов набора сущностей в отдельные сущности, которые будут дополнять те или иные основные сущности.
  6.  Превращение концептуальной модели данных в физическую модель данных. Модель данных вписывается в особенности конкретных СУБД.

Нотации ER-диаграмм

  1.  Нотация Чена

Сущность  прямоугольник, в который вписано имя.

В одинарной рамке – независимая сущность, в двойной – зависимая сущность. Связь изображается в виде ромба с именем. Идентифицирующая связь – ромб с двойной рамкой.

Атрибут изображается в виде овала с именем.

Атрибут-первичный_ключ – двойное подчеркивание имени.

Атрибут-внешний ключ – одинарное подчеркивание имени.

  1.  Нотация Мартина

Независимая сущность, зависимая сущность – как у Чена.

Атрибуты вписываются внутрь сущности под именем.

Связь между сущностями – сплошная линия.

Множественная связь – сплошная линия с разветвлением на конце.

К одному – сплошная линия, на конце крест.

Модальная связь «может» - как ветвление, но с овалом на линии перед ветвлением.

Связи именуются (прямо на линиях).

  1.  IDEF 1x

Независимая сущность – как у Чена. Зависимая сущность – прямоугольник со скругленными краями.

Идентифицирующая связь – сплошная линия.

Неидентифицирующая связь – пунктирная линия.

Линия – связь один-к-одному.

Линия с жирной точкой на конце – один-ко-многим.

С буквой z на конце – один-к-перечислимому-множеству

С цифрой – один-к-N

Отношение категоризации – одна сущность разделяется на подкатегории. Категоризация бывает

а) полная

б) неполная

  1.  Нотация Баркера

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

21. Процессы проектирования. Построение логической модели данных (ЛМД)

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

Разработчик использует требования к данным и результаты анализа для формирования ЛМД; приводит ЛМ к 3ей нормальной форме и проверяет ее на соответствие корпоративной модели данных, если она существует.

Уровни модели, объединяющие ЛМ: ERD (Entity Relationship Diagram – сущность-связь), the Key-Based Model (Модель, основанная на ключах) и the Fully Attributed model (Полная атрибутивная модель).

1) Диаграмма сущность-связь

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

Модель данных, основанная на ключах

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

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

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

Разработка ЛМ:

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

Компоненты ЛМД

Сущности. Объекты, данные о которых корпорация заинтересована сохранять. М.б. вещественные объекты (персона или книга), м.б. абстрактные концепции (центр затрат или производственная единица). Существительные в ед.ч. (потребитель (CUSTOMER); НЕ потребители (CUSTOMERS)).

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

Атрибуты. Данные об объектах, которые необходимо иметь корпорации. Существительные, описывают характеристики сущностей.

Атрибуты: дата рождения клиента, модель автомобиля или код ISBN книги.

Отношения. Взаимосвязи м/у объектами, о которых корпорация заинтересована хранить данные. Глаголы (глагол. фразы), описывают взаимосвязь.

«Один-ко-многим»: 1 экземпляр первой сущности взаимодействует с несколькими экземплярами другой сущности. Линия, соединяющая 2 сущности с точкой на одном конце и глаголом над линией.

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

Проверка адекватности ЛМ

Если взаимосвязи м/у сущностями были правильно установлены, то можно составить предложения, их описывающие.

2) Модель данных, основанная на ключах

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

Выбор первичного ключа

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

  •  Pk д.б. подобран т.о., чтобы по значениям включенных в него атрибутов м.б. точно идентифицировать экземпляр сущности.
  •  Никакой из атрибутов Pk не должен иметь 0 значение.
  •  Значения атрибутов Pk не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.

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

Pk, выбранный при создании ЛМ, м.б. неудачным для осуществления эффективного доступа к БД и должен быть изменен при проектировании физической модели.

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

При проведении связи между 2мя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты Pk в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.

22. Процессы проектирования. Построение физической модели данных (ФМД)

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

Требования к использованию данных:

  •  Требования к доступу и производительности
  •  Волюметрические характеристики (оценку объема данных, которые предстоит хранить): позволяют администратору представить физический объем базы данных
  •  Оценка количества пользователей, которым необходим одновременный доступ к данным
  •  Суммарные, сводные и другие вычисляемые или производные данные, которые могут рассматриваться в качестве кандидатов для хранения в долговременных структурах данных
  •  Требования к формированию отчетов и стандартных запросов, помогающих администратору БД формировать индексы
  •  Представления, которые помогут пользователю при объединения или фильтрации данных.

Компоненты физической модели данных

Таблицы, столбцы и отношения. Сущности логической модели – > таблицы в физической модели. Логические атрибуты – > столбцы. Логические отношения – > ограничения целостности связей.

Обратное проектирование

Когда логическая модель недоступна, возникает необходимость воссоздания модели из существующей БД. Обратное проектирование может производиться несколькими способами. Разработчик модели может исследовать структуры данных в базе данных и воссоздать таблицы в визуальной среде моделирования. Вы можете импортировать язык описания данных (DDL – data definitions language) в инструмент, который поддерживает проведение обратного проектирования (например, ERwin). Развитые средства, такие как ERwin, включают функции, обеспечивающие связь через ODBC с существующей БД, для создания модели путем прямого чтения структур данных.

23. Процессы проектирования. Шаблоны Информационной Архитектуры (ИА)

АИ 1С подразумевает объектную структуру. Существует набор типов данных, которые организуются в определенную структуру, которая имеет иерархию типа «дерево». Система типов позволяет обеспечить понятную для пользователя структуру объектов и четкое описание отдельных элементов ИА.

Типы данных 1С

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

ИА – некое описание логической структуры хранимых данных (в конечном счете БД). Сама по себе БД существовать не может, к ней необходима СУБД. Функции СУБД:

  •  Хранение, извлечение и обновление данных.
  •  Формирование и предоставление конечным пользователям каталога БД, в котором хранится описание всех элементов данных, которые хранятся в данной БД. В каталоге необходимо хранить имена, типы и размеры данных, имена пользователей.
  •  Поддержка транзакций – это набор действий, выполняемых отдельным пользователем. СУБД должна поддерживать выполнение (одновременное и параллельное) транзакций, обеспечивать их корректность, целостность и непротиворечивость. Управление одновременной работой обеспечивается либо блокировкой данных, либо введением четкой системы битовости (все команды выполняются с использованием фиксированных временных отрезков).
  •  Служба восстановления (способность исправлять повреждения или разрушения данных).
  •  Контроль доступа к данным.
  •  Поддержка обмена данными.
  •  Служба поддержки целостности данных. СУБД должна на программном уровне обеспечивать удобные инструменты обеспечения целостности данных.
  •  Служба поддержки независимости от данных. СУБД должна обеспечить независимость физической структуры данных от программных компонентов, которые работают с этими данными. Вспомогательные службы: уборка мусора, устранение физических потерь записи и т.п.

Основные компоненты СУБД

  •  Процессор языка DML. Позволяет прикладным программам формировать код для управления запросами.
  •  Процессор запросов. Позволяет формировать запросы в данной СУБД.
  •  Процессор авторизации. Обеспечивает контроль и определение прав доступа.
  •  Процессор команд.
  •  Диспетчер транзакций.
  •  Планировщик.
  •  Диспетчер восстановления.
  •  Диспетчер файлов.
  •  Методы доступа.
  •  Системные буферы.

+совместное использование данных;

+целостность данных;

+повышенная безопасность;

+повышение доступности данных и их готовности к работе;

+упрощение сопровождения системы за счет независимости от данных;

+возможность управления параллельной работой;

+наличие служб копирования и восстановления.

-сложность создания и сложность функционирования;

-размеры и стоимость;

-большие затраты на обеспечение производительности;

-более серьезные последствия при выходе системы из строя.

24. Процессы проектирования. Проектирование программной архитектуры

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

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

При проектировании отдельного модуля необходимо

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

Задачи проектирование программной архитектуры:

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

25. Процессы проектирования. Модели описания программной архитектуры.

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

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

Весь набор модулей определяется в системной архитектуре.

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

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

26. Процессы проектирования. Шаблоны программной архитектуры

СТРУКТУРНЫЕ ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ КЛАССОВ И ОБЪЕКТОВ

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

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

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

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

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

Приспособленец. Решает проблему поддержки множества мелких объектов. Моделирует сущности, число которых слишком велико для представления объектом. Имеет смысл, если: приложение использует много объектов; большую часть состояния объектов можно вынести вовне. Это позволяет уменьши количество базовых классов и сэкономить ресурсы.

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

ПОВЕДЕНЧЕСКИЕ ПАТТЕРНЫ

Интерпретатор. Решает часто встречающуюся, но подверженную изменениям, задачу.

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

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

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

ПОРОЖДАЮЩИЕ ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ

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

Прототип. Решает проблему зависимости системы от того, как в ней создаются, компонуют объекты. Прототип предоставляет интерфейс для клонирования самого себя.

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

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

27. Процессы проектирования. Проектирование инфраструктуры

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

Список работ:

ПОДГОТОВКА ПРОЦЕССА. Задачи:

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

СОЗДАНИЕ ИНФРАСТРУКТУРЫ. Задачи:

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

СОПРОВОЖДЕНИЕ ИНФРАСТРУКТУРЫ. Задачи:

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

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

Список работ:

СОЗДАНИЕ ПРОЦЕССА

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

ОЦЕНКА ПРОЦЕССА

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

УСОВЕРШЕНСТВОВАНИЕ ПРОЦЕССА

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

28. Процессы проектирования. Проектирование интерфейсов.

При проектировании ИС важная роль отводится понятию интерфейса.

Интерфейс: программный, пользовательский.

Пользовательский интерфейс

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

Уровни проектирования интерфейса:

  1.  Концептуальный уровень. Содержимое интерфейса max формализуется, определяется, что должен содержать интерфейс, исходя из его функциональных задач.
  •  текстовое описание.
  •  четко выделены необходимость и достаточность в любом интерфейсе
  •  на одном интерфейсе желательно выполнять одну функциональную задачу.
  1.  Макет интерфейса. Функциональные требования интерфейса совмещаются с возможными графическими объектами платформы или неким графическим образом распределяется взаимное расположение элементов интерфейса друг относительно друга.
  •  max удобный и понятный интерфейс
  •  ориентация на сферу применения данной ИС
  •  определение относительной расположенности и функциональной нагрузки элементов интерфейса, предусматривается масштабируемость и кастомизация
  •  формируется схематичная модель интерфейса
  •  необходимо учитывать аппаратные возможности тех устройств, на которых будет использоваться интерфейс.
  1.  Дизайн. 2й уровень + элементы дизайна.
  •  обратить внимание на целевую аудиторию
  •  учитывать аппаратные возможности устройств, на которых будет использоваться интерфейс
  •  учитывать физиологические особенности оператора, который будет работать на данном интерфейсе.

29. Процессы верификации. Оценка качества. Понятие качества

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

Процесс обеспечения качества ПО д.б. выполнен в соответствии с процессом планирования ПО и документом «План обеспечения качества ПО». Выход: представлен в Протоколах обеспечения качества ПО. Процесс обеспечения качества оценивает процессы ЖЦ ПО, их выходные результаты и документы ЖЦ ПО соответствуют сертификационным требованиям.

Цель процесса обеспечения качества – обеспечить уверенность в том, что:

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

Работы по обеспечению качества ПО

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

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

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

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

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

30. Процессы верификации. Тестирование

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

Цели тестирования ПО: 1) показать, что ПО удовлетворяет требованиям к нему. 2) продемонстрировать, что были устранены ошибки, которые м.б. привести к возникновению отказных ситуаций, определенных процессом оценки безопасности системы. Уровни тестирования:

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

Для удовлетворения целей тестирования ПО:

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

Методы тестирования, основанные на требованиях  - основной метод тестирования любого уровня

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

Порядок выполнения тестирования ПО

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




1. Автомобильное хозяйство и Двигатели ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС РЕМОНТА детали; КОЛЕНЧАТ
2. 10 аралык ~ Жансая Асель 1120 аралык ~ Алина Улжан Бота 2130 аралык ~ 8 общ улдары Айбек Нуркен Асик Медет
3. Учебное пособие- Робота з вікнами
4. Тема Хронический гастрит Утверждена на кафедральном заседании межкафедральной методической конфер.html
5. на тему Особенности правового статуса государственных унитарных предприятий Группа 12
6. ЭКОНОМИЧЕСКИХ И ФИНАНСОВЫХ ПРОБЛЕМ КРАСНОЯРСКОГО КРАЯ Введение Одним из важнейших направлений экономи
7. а Студент-Отчёт принят-
8. Маркетинговая среда состоит из микросреды медиасреды и макросреды
9. The second bred The Belrusins bring fme to their beloved potto in their verses songs dnces
10. в числе которых как показывает практика наиболее существенны три группы- объективное состояние экономик
11. на тему- Характеристика физических загрязнений окружающей среды
12. іба~а факторы Айналмалы капиталды облигациялар шы~ару жолымен тарту А~ ~а келесідей арты~шылы~ты береді-О
13. 14 1145 027 Менеджмент персоналу 14
14. Искусство украинского танца
15. Приобщение детей к русской культуре и декоративно-прикладное творчество
16. Орфоэпия произносительная норма и произносительный вариант источники вариантов произношения
17. Тема занятия- Учение о бытии
18. по теме Рождество и Новый год в Великобритании актуализация лексических навыков тренировка навыков чтени
19. Обозначения святости в ономастическом пространстве русского языка
20. КОЛИЧЕСТВЕННОЕ ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ ЖЕЛЕЗА В ВОДЕ