Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
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 был создан для определения, визуализации, проектирования и документирования в основном программных систем.
Также используется для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
Виды диаграмм:
Структурные диаграммы:
Диаграммы поведения:
1. Начало (Inception)
2. Уточнение (Elaboration) анализ предметной области, построение исполняемой архитектуры.
ARIS (Architecture of Integrated Information Systems). Точки зрения:
Подуровни: описание требований, описание спецификации, описание внедрения.
Возможные методы описания:
Скрипт это инструмент ARIS, с помощью которого автоматизируется составление различных аналитических отчётов, нормативных документов, новых моделей. Подпрограмма, запускаемая в ARIS Toolset или непосредственно на сервере ARIS. Пишутся на спец. языке программирования (SAX Basic). ARIS Script позволяет в автоматическом режиме производить:
15. Анализ объекта автоматизации. Инструментальные средства поддержки анализа.
Инструментальные средства поддержки анализа совокупность методов анализа, проектирования, разработки и сопровождения ИС, поддержанная комплексом взаимосвязанных средств автоматизации. Это инструментарий для системных аналитиков, разработчиков и программистов, позволяет автоматизировать процесс проектирования. Цель: отделить проектирование ИС и ИТ от ее кодирования и последующих этапов разработки, а также max автоматизировать процессы разработки и ф-ния систем.
СИСТЕМНАЯ АРХИТЕКТУРА С Т.З. СТРУКТУРЫ
Репозиторий
Структура репозитория: все данные, используемые в ИС, хранятся в единой БД, и всем подсистемам ИС репозиторий предоставляет одинаковые права на доступ к данным. Репозиторий пассивный элемент, все управление перелагается на разные подсистемы. Такой подход стоит применять, если в ИС обрабатывается очень большой объем медленно изменяемых данных.
+ Все подсистемы имеют равные права доступа, единое хранение позволяет уменьшить затрачиваемые на хранение информации ресурсы. Легко можно обеспечить резервирование данных.
- Нет возможности обеспечить разный уровень доступа к информации.
Клиент-сервер
Данные и процессы распределены м/у несколькими объектами с разным статусом. Основные элементы: сервер, клиент, сеть. Один и тот же объект системы м.б. и клиентом, и сервером. У сервера существует стандартный интерфейс доступа к нему, по которому клиент может обратиться с каким-то запросом. Сервер имеет стандартный вход, получает запросы и выполняет задачи. При выполнении задач он может обращаться к другим объектам (выступает в роли клиента). Такой подход стоит применять, если необходимо распределение данных или различные уровни доступа к данным.
+ Можно создать распределенную архитектуру. Это позволяет увеличить производительность за счет распределения задач м/у отдельными физическими компонентами.
+ Возможно масштабирование системы за счет постепенного ввода различных клиентов и серверов.
- Если клиенту необходимо получать большие объемы информации, то при большом количестве таких запросов нагрузка на сеть слишком велика.
Многоуровневая система (абстрактная машина)
Выделяется три уровня: уровень представления показывает внешний вид (интерфейс доступа к каким-то функциям, выполняемым ИС); уровень бизнес-логики определяет, как функции выполняются; уровень источника данных поставщик данных для выполнения функций бизнес-логики.
+ Многоуровневая система может разрабатываться пошагово и следует за логическим развитием представления об информационной системе пользователя.
- Уровни логические. Исходный код отдельных элементов сильно связан. Изменение одного уровня влечет изменение других.
В чистом виде структурные паттерны редко применяются раздельно. Чаще всего их комбинируют.
АРХИТЕКТУРА С Т.З. УПРАВЛЕНИЯ
Управление компонентами
Взаимодействие отдельных компонент как точка-точка. Элемент архитектуры обращается непосредственно к нужному ему объекту. Каждый объект должен знать интерфейсы всех других объектов.
Интегратор, позволяющий каждому объекту системы обращаться к другому объекту через единую точку доступа. Все компоненты системы предоставляют интегратору данные о формате ввода-вывода, а интегратор обеспечивает трансляцию различных данных в нужный вид для передачи тому или иному компоненту, а также обеспечивает передачу информации о существовании объекта. При большом количестве объектов интегратор становится очень сложным.
Управление потоками данных
Вызов-возврат. Инициируется выполнение какой-то команды, это может порождать цепную реакцию вызова других команд. Порождается событие, дальше ждем отклика на событие. Применим только в последовательных системах, когда все процессы могут выполняться последовательно.
+ простой анализ потоков управления.
-ложность в обработке исключительных событий.
Диспетчер. Некий объект назначается приемником всех событий и он инициирует различные дальнейшие события и операции. Применяется при необходимости обеспечить выполнение параллельных процессов или когда необходимо выполнять последовательные процессы, но с вариативностью.
ОБЩИЕ МОМЕНТЫ ПРИ ПРОЕКТИРОВАНИИ СИСТЕМНОЙ АРХИТЕКТУРЫ
Необходимо определиться с компонентами системы, которые будут объединены в понятие системной архитектуры (клиент, СУБД, сервер приложений и т.п.).
Определить интерфейсы взаимодействия м/у компонентами, определить интерфейсы ввода-вывода отдельных компонент.
Определить программно-аппаратные и аппаратные требования.
Методика выбора архитектуры
Для описания системной архитектуры выделяют:
Общие цели и задачи объекта автоматизации.
IT инфраструктуру и связанные с ней IT-услуги (сервис).
После строятся модели возможных IT-сервисов. Они разделяются на бизнес-модели (стратегия предприятия, структура и требования бизнес-процессов), информационные модели (типы хранилищ, БД, используемые внешние информационные хранилища) и модели прикладных систем (системы, обеспечивающие нужный функционал для реализации бизнес-логики). На основании этого формируется представление об архитектуре, которое формирует некую модель.
Методы описания информационной архитектуры:
Методика описания архитектуры по модели Захмана. В основе матрица Захмана, которая с одной стороны определяет уровень детализации, с другой стороны рассматриваемые аспекты на каждом уровне детализации. Матрица состоит из:
Аспекты (столбцы матрицы):
В каждой ячейке матрицы описывается определенный взгляд на части системы. Правило использования матрицы: неважно, в каком порядке мы будем отвечать на вопросы. Нет четкой последовательности колонок. Каждый ряд формирует свой взгляд на систему в целом. Каждая клетка уникальна. Совокупность клеток одного ряда формирует полное описание системы. При этом в каждой колонке имеется простая модель объекта автоматизации.
Метод Захмана позволяет достаточно формально описать ИС с различных т.з. Позволяет сохранить независимость логических и технологических решений от детальных моментов, связанных с применением тех или иных технологий и того или иного программного решения.
Методики Гигагрупп.
Методика POSIX.
Методика ТОГА.
Паттерн (шаблон) проектирования показывает, каким образом необходимо решать ту или иную системную задачу. Паттерны используются на разном системном уровне: уровня программной архитектуры, уровня системной архитектуры. И те и другие описывают, как решать конкретную задачу, а различаются уровнем детализации.
Паттерны позволяют тратить меньше ресурсов на решение проблемы, показывают возможные сложности, плюсы и минусы данной системы. Но бездумное применение шаблонов приводит к большим затратам на доработку готового решения под частности.
Не существует абсолютно подходящего паттерна, т.к. каждая конкретная задача имеет тот или иной набор нестандартных моментов, которые нужно нестандартно решать.
СИСТЕМНАЯ АРХИТЕКТУРА С Т.З. СТРУКТУРЫ
Репозиторий
Структура репозитория: все данные, используемые в ИС, хранятся в единой БД, и всем подсистемам ИС репозиторий предоставляет одинаковые права на доступ к данным. Репозиторий пассивный элемент, все управление перелагается на разные подсистемы. Такой подход стоит применять, если в ИС обрабатывается очень большой объем медленно изменяемых данных.
+ Все подсистемы имеют равные права доступа, единое хранение позволяет уменьшить затрачиваемые на хранение информации ресурсы. Легко можно обеспечить резервирование данных.
- Нет возможности обеспечить разный уровень доступа к информации.
Клиент-сервер
Данные и процессы распределены м/у несколькими объектами с разным статусом. Основные элементы: сервер, клиент, сеть. Один и тот же объект системы м.б. и клиентом, и сервером. У сервера существует стандартный интерфейс доступа к нему, по которому клиент может обратиться с каким-то запросом. Сервер имеет стандартный вход, получает запросы и выполняет задачи. При выполнении задач он может обращаться к другим объектам (выступает в роли клиента). Такой подход стоит применять, если необходимо распределение данных или различные уровни доступа к данным.
+ Можно создать распределенную архитектуру. Это позволяет увеличить производительность за счет распределения задач м/у отдельными физическими компонентами.
+ Возможно масштабирование системы за счет постепенного ввода различных клиентов и серверов.
- Если клиенту необходимо получать большие объемы информации, то при большом количестве таких запросов нагрузка на сеть слишком велика.
Многоуровневая система (абстрактная машина)
Выделяется три уровня: уровень представления показывает внешний вид (интерфейс доступа к каким-то функциям, выполняемым ИС); уровень бизнес-логики определяет, как функции выполняются; уровень источника данных поставщик данных для выполнения функций бизнес-логики.
+ Многоуровневая система может разрабатываться пошагово и следует за логическим развитием представления об информационной системе пользователя.
- Уровни логические. Исходный код отдельных элементов сильно связан. Изменение одного уровня влечет изменение других.
В чистом виде структурные паттерны редко применяются раздельно. Чаще всего их комбинируют.
АРХИТЕКТУРА С Т.З. УПРАВЛЕНИЯ
Управление компонентами
Взаимодействие отдельных компонент как точка-точка. Элемент архитектуры обращается непосредственно к нужному ему объекту. Каждый объект должен знать интерфейсы всех других объектов.
Интегратор, позволяющий каждому объекту системы обращаться к другому объекту через единую точку доступа. Все компоненты системы предоставляют интегратору данные о формате ввода-вывода, а интегратор обеспечивает трансляцию различных данных в нужный вид для передачи тому или иному компоненту, а также обеспечивает передачу информации о существовании объекта. При большом количестве объектов интегратор становится очень сложным.
Управление потоками данных
Вызов-возврат. Инициируется выполнение какой-то команды, это может порождать цепную реакцию вызова других команд. Порождается событие, дальше ждем отклика на событие. Применим только в последовательных системах, когда все процессы могут выполняться последовательно.
+ простой анализ потоков управления.
-ложность в обработке исключительных событий.
Диспетчер. Некий объект назначается приемником всех событий и он инициирует различные дальнейшие события и операции. Применяется при необходимости обеспечить выполнение параллельных процессов или когда необходимо выполнять последовательные процессы, но с вариативностью.
19.Процессы проектирования. Проектирование информационной архитектуры
ИА организация интерактивного визуального представления больших массивов данных.
Этапы создания ИА:
1) Формирование логической структуры данных Непосредственное взаимодействие системного архитектора с заказчиком. Формальный метод описания: формирование диаграмм сущность-связь. Логические диаграммы ER модели должны однозначно пониматься как исполнителем, так и заказчиком и являются обязательным элементов ТЗ.
2) Формирование физической структуры данных. Физическая модель графическое представление реально реализованной БД. Состоит из таблиц, столбцов и связей. Зависит от платформы, выбранной для реализации, и требований к использованию данных.
Нормализация данных позволяет обеспечить целостность и непротиворечивость хранимых данных. Теории нормализации 6 нормальных форм хранения данных.
Чем более высоконормализована модель данных, тем более она сложна для получения из нее данных. Чем более модель данных приближена к действительности, тем больше в ней возможных противоречий, т.к. много информации имеет дублирующееся хранение.
Высокие уровни нормализации позволяют хранить любую инф-ию в БД один раз и в виде, в котором она интерпретируется однозначно в любой момент времени. Для обеспечения скорости работы добавляются дополнительные сущности.
Триггер исполняемая процедура, обеспечивает целостность данных. Вызывается автоматически по какому-то событию. Внутренняя процедура, ее исполнение не зависит от пользователя.
Процедура записанный в БД стандартные набор операций, которые вызываются пользователем по имени. Цель: защита целостности БД.
Представление текущий слепок реальной БД по какому-то запросу. Обычно результаты стандартных запросов хранят в виде представлений. Наличие представлений обеспечивает быстродействие и безопасность.
20. Процессы проектирования. Построение ER модели. Виды нотаций.
ER-модель модель данных, описывает концептуальные схемы предметной области. Используется при высокоуровневом (концептуальном) проектировании БД. Можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. Во время проектирования БД происходит преобразование ER-модели в конкретную схему БД.
Формальная конструкция, которая сама по себе не предписывает никаких графических средств её визуализации. Стандартная графическая нотация диаграмма сущность-связь (ER-диаграмма).
Сущность объект, который может быть идентифицирован неким способом, отличающим его от других объектов. конкретный человек, событие и т.д.
Набор сущностей множество сущностей одного типа (обладающих одинаковыми свойствами) (все люди).
Сущность множество атрибутов, которые описывают свойства всех членов данного набора сущностей.
Ключ сущности один или более атрибутов уникально определяющих данную сущность.
Связь ассоциация, установленная между несколькими сущностями.
Набор связей отношение между n сущностями, каждая из которых относится к некоторому набору сущностей.
Один - к одному. Каждому объекту первого вида соответствует не более 1 объекта второго вида, и наоборот (сотрудник руководит только 1 отделом, и у каждого отдела только 1 руководитель).
Один - ко многим. Каждому объекту первого вида может соответствовать более 1 объекта второго вида, но каждому объекту второго вида соответствует не более 1 объекта первого вида (в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в 1 отделе).
Много к одному. Каждому объекту первого вида может соответствовать не более 1 объекта второго вида, но каждому объекту второго вида соответствует более 1 объекта первого вида (с одним заказчиком может быть заключено более 1 контракта, то связь будет иметь степень n : 1)
Многие - ко многим. Каждому объекту первого вида может соответствовать более 1 объекта второго вида, и наоборот (каждый сотрудник может входить в несколько рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь имеет степень n : n).
Связь линия, связывает 2 сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде "вилки" на конце связи.
Атрибуты сущности записываются внутри прямоугольника, изображающего сущность и выражаются существительным в единственном числе.
План создания ER модели
Нотации ER-диаграмм
Сущность прямоугольник, в который вписано имя.
В одинарной рамке независимая сущность, в двойной зависимая сущность. Связь изображается в виде ромба с именем. Идентифицирующая связь ромб с двойной рамкой.
Атрибут изображается в виде овала с именем.
Атрибут-первичный_ключ двойное подчеркивание имени.
Атрибут-внешний ключ одинарное подчеркивание имени.
Независимая сущность, зависимая сущность как у Чена.
Атрибуты вписываются внутрь сущности под именем.
Связь между сущностями сплошная линия.
Множественная связь сплошная линия с разветвлением на конце.
К одному сплошная линия, на конце крест.
Модальная связь «может» - как ветвление, но с овалом на линии перед ветвлением.
Связи именуются (прямо на линиях).
Независимая сущность как у Чена. Зависимая сущность прямоугольник со скругленными краями.
Идентифицирующая связь сплошная линия.
Неидентифицирующая связь пунктирная линия.
Линия связь один-к-одному.
Линия с жирной точкой на конце один-ко-многим.
С буквой z на конце один-к-перечислимому-множеству
С цифрой один-к-N
Отношение категоризации одна сущность разделяется на подкатегории. Категоризация бывает
а) полная
б) неполная
Повторяет нотацию Мартина, но ключевые атрибуты в данном случае выделяются знаком #.
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 часто используют уникальные номера, которые могут автоматически генерироваться системой при добавлении экземпляра сущности в БД.
Pk, выбранный при создании ЛМ, м.б. неудачным для осуществления эффективного доступа к БД и должен быть изменен при проектировании физической модели.
Потенциальный ключ, не ставший Pk - альтернативный (Alternate Key). При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).
При проведении связи между 2мя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты Pk в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.
22. Процессы проектирования. Построение физической модели данных (ФМД)
Физическая модель графическое представление реально реализованной БД. Физическая БД состоит из таблиц, столбцов и связей. Физическая модель зависит от платформы, выбранной для реализации, и требований к использованию данных.
Требования к использованию данных:
Компоненты физической модели данных
Таблицы, столбцы и отношения. Сущности логической модели > таблицы в физической модели. Логические атрибуты > столбцы. Логические отношения > ограничения целостности связей.
Обратное проектирование
Когда логическая модель недоступна, возникает необходимость воссоздания модели из существующей БД. Обратное проектирование может производиться несколькими способами. Разработчик модели может исследовать структуры данных в базе данных и воссоздать таблицы в визуальной среде моделирования. Вы можете импортировать язык описания данных (DDL data definitions language) в инструмент, который поддерживает проведение обратного проектирования (например, ERwin). Развитые средства, такие как ERwin, включают функции, обеспечивающие связь через ODBC с существующей БД, для создания модели путем прямого чтения структур данных.
АИ 1С подразумевает объектную структуру. Существует набор типов данных, которые организуются в определенную структуру, которая имеет иерархию типа «дерево». Система типов позволяет обеспечить понятную для пользователя структуру объектов и четкое описание отдельных элементов ИА.
Типы данных 1С
ИА некое описание логической структуры хранимых данных (в конечном счете БД). Сама по себе БД существовать не может, к ней необходима СУБД. Функции СУБД:
Основные компоненты СУБД
+совместное использование данных;
+целостность данных;
+повышенная безопасность;
+повышение доступности данных и их готовности к работе;
+упрощение сопровождения системы за счет независимости от данных;
+возможность управления параллельной работой;
+наличие служб копирования и восстановления.
-сложность создания и сложность функционирования;
-размеры и стоимость;
-большие затраты на обеспечение производительности;
-более серьезные последствия при выходе системы из строя.
Проектирование ПО этап ЖЦ ПО, во время которого исследуется структура и взаимосвязи элементов разрабатываемой системы. Результат: проект, содержащий достаточное количество инф-ии для реализации системы.
Детальное проектирование (проектирование программной архитектуры) подразумевает трансформирование системной архитектуры в процедурное описание программ. На этапе детального проектирования происходит выбор и оценка алгоритма реализации каждого конкретного модуля. Весь набор модулей определяется в системной архитектуре.
При проектировании отдельного модуля необходимо
Задачи проектирование программной архитектуры:
Проектирование ПО этап ЖЦ ПО, во время которого исследуется структура и взаимосвязи элементов разрабатываемой системы. Результат: проект, содержащий достаточное количество информации для реализации системы.
Детальное проектирование (проектирование программной архитектуры): трансформирование системной архитектуры в процедурное описание программ. На этапе детального проектирования происходит выбор и оценка алгоритма реализации каждого конкретного модуля.
Весь набор модулей определяется в системной архитектуре.
При проектировании отдельного модуля необходимо:
СТРУКТУРНЫЕ ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ КЛАССОВ И ОБЪЕКТОВ
Адаптер. Необходимо обеспечить взаимодействие несовместимых интерфейсов или создать единый устойчивый интерфейс для разных интерфейсов. Предполагает создание промежуточного объекта, который имеет стандартный входной интерфейс и при этом внутри адаптера прописываются интерфейсы, находящихся за ним и решающих свои отдельные задачи. При введении новых объектов в систему необходимо только исправить адаптер.
Декоратор (оболочка). Подразумевается необходимость возложить доп. обязанности на отдельный объект, а не на класс в целом. Декоратор выделяется как отдельная часть компонента, которая разделяет общие операции компонента и дает возможность их по-разному использовать. Позволяет достичь гибкой работы компонента, избежать перегруженности методов классов. Декоратор и базовый компонент не идентичны полностью, отдельный декоратор не заменяет компонент в целом.
Заместитель (суррогат). Решает проблему управления доступом к объекту с целью создания громоздких объектов по требованию. Создается объект-заместитель, в обязанностях которого хранение ссылок на реальный объект, интерфейс заместителя полностью идентичен реальному объекту, при этом на заместителя возлагаются дополнительные контроля доступа к объекту.
Удаленный заместитель: кодирование запроса и его аргументов и отправку в закодированном виде реальному объекту. Виртуальный: кэширование доп. инф-ии о реальном субъекте и создавать его позже. Защищающий проверяет права доступ к объекту и корректность передаваемых данных.
Мост. Решает проблему отделения абстракции от реализации так, чтобы и то и другое м.б. изменять независимо. Клиент обращается к объекту абстракции, который выполняет ф-ии через интерфейс реализации.
Приспособленец. Решает проблему поддержки множества мелких объектов. Моделирует сущности, число которых слишком велико для представления объектом. Имеет смысл, если: приложение использует много объектов; большую часть состояния объектов можно вынести вовне. Это позволяет уменьши количество базовых классов и сэкономить ресурсы.
Фасад. Обеспечивает унифицированный интерфейс с набором разрозненных реализаций при невысокой связанности с подсистемой реализации. Это объект, обеспечивающий единую точку входа, при этом фасад закрывает реализацию компонентов подсистемы от внешних компонентов. Фасадный объект обеспечивает и защиту внутренних компонентов от изменений.
ПОВЕДЕНЧЕСКИЕ ПАТТЕРНЫ
Интерпретатор. Решает часто встречающуюся, но подверженную изменениям, задачу.
Итератор (курсор). Решает проблему доступа к составному объекту (списку), не раскрывая его внутреннюю структуру. Поддерживает обращение к внутреннему содержимому элементов списка динамически в зависимости от того, какой объект списка выбран.
Посредник. Решает проблему взаимодействия множества объектов, имеющих слабую связанность. Также обеспечивает отсутствие необходимости объекта явно ссылаться друг на друга.
Хранитель. Решает проблему фиксации поведения объекта или состояние этого объекта с целью реализации механизма отката. Хранитель позволяет зафиксировать и вынести за пределы объекта его внутреннее состояние, чтобы по этому состоянию восстановить исходный объект.
ПОРОЖДАЮЩИЕ ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ
Абстрактная фабрика (инструментарий). Создается абстрактный класс, в котором объявлен интерфейс для создания конкретных классов. Она изолирует клиентов от деталей реализации классов.
Прототип. Решает проблему зависимости системы от того, как в ней создаются, компонуют объекты. Прототип предоставляет интерфейс для клонирования самого себя.
Строитель. Отделяет конструирование сложного объекта от его представления в результате одного и того же конструирования получались различные представления. Строитель предоставляет алгоритм создания сложного объекта, а также набор частей, с которыми он работает и правила их стыковки.
Фабричный метод (виртуальный конструктор). Решает проблему создания интерфейсов для создания объектов и отделения создания подклассов от того, кто пользуется интерфейсом объекта.
27. Процессы проектирования. Проектирование инфраструктуры
Процесс создания инфраструктуры процесс установления и обеспечения (сопровождения) инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения.
Список работ:
ПОДГОТОВКА ПРОЦЕССА. Задачи:
СОЗДАНИЕ ИНФРАСТРУКТУРЫ. Задачи:
СОПРОВОЖДЕНИЕ ИНФРАСТРУКТУРЫ. Задачи:
должна сопровождаться, контролироваться и, при необходимости, изменяться так, чтобы обеспечивать удовлетворение требований к процессу, использующему процесс создания инфраструктуры. Д.б. определена как часть сопровождения инфраструктуры продолжительность нахождения инфраструктуры под управлением конфигурацией.
Процесс усовершенствования процесс установления, оценки, измерения, контроля и улучшения любого процесса ЖЦ программных средств.
Список работ:
СОЗДАНИЕ ПРОЦЕССА
ОЦЕНКА ПРОЦЕССА
УСОВЕРШЕНСТВОВАНИЕ ПРОЦЕССА
28. Процессы проектирования. Проектирование интерфейсов.
При проектировании ИС важная роль отводится понятию интерфейса.
Интерфейс: программный, пользовательский.
Пользовательский интерфейс
Уровни проектирования интерфейса:
29. Процессы верификации. Оценка качества. Понятие качества
Процесс верификации процесс определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Для оценки эффективности затрат и выполняемых работ верификация должна как можно раньше реализовываться в соответствующих процессах (поставка, разработка, эксплуатация или сопровождение). Включает анализ, проверку и испытание (тестирование).
Процесс обеспечения качества ПО д.б. выполнен в соответствии с процессом планирования ПО и документом «План обеспечения качества ПО». Выход: представлен в Протоколах обеспечения качества ПО. Процесс обеспечения качества оценивает процессы ЖЦ ПО, их выходные результаты и документы ЖЦ ПО соответствуют сертификационным требованиям.
Цель процесса обеспечения качества обеспечить уверенность в том, что:
Работы по обеспечению качества ПО
Разработчик должен регистрировать отчеты о каждой выполненной работе по обеспечению качества ПО. Эти отчеты следует сохранять в течение срока действия контракта. Проблемы, обнаруженные в программных средствах, при управлении конфигурацией должны быть обработаны.
Лица, ответственные за обеспечение качества ПО, не должны участвовать в разработке программного средства или быть ответственными за программное средство или работы по его созданию. Однако это не запрещает таким лицам принимать участие в оценках программных средств или выполненных работ. Лица, ответственные за обеспечение качества ПО в соответствии с контрактом, должны иметь возможности, обязательства, полномочия и организационную независимость для объективной оценки качества ПО, а также для инициирования и верификации действий, связанных с коррекцией.
План обеспечения качества ПО устанавливает методы, которые должны быть использованы для того, чтобы достичь цели процесса обеспечения качества ПО.
Результаты работ процесса обеспечения качества ПО должны быть зарегистрированы в протоколах обеспечения качества. Они могут включать в себя протоколы просмотров и аудитов, протоколы совещаний, регистрацию отклонений от санкционированных процессов или протоколы проверки соответствия ПО.
30. Процессы верификации. Тестирование
Верификация процесс определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Для оценки эффективности затрат и выполняемых работ верификация должна как можно раньше реализовываться в соответствующих процессах (поставка, разработка, эксплуатация или сопровождение). Процесс включает анализ, проверку и испытание (тестирование).
Цели тестирования ПО: 1) показать, что ПО удовлетворяет требованиям к нему. 2) продемонстрировать, что были устранены ошибки, которые м.б. привести к возникновению отказных ситуаций, определенных процессом оценки безопасности системы. Уровни тестирования:
Для удовлетворения целей тестирования ПО:
Методы тестирования, основанные на требованиях - основной метод тестирования любого уровня
Порядок выполнения тестирования ПО