Стратегия синтеза структуры БД на основе информационной модели

Структура даних та бази даних.

Інформаційні бази даних включають весь комплекс статистичних показників, які характеризують господарську діяльність організації в цілому і її підрозділів, а також, фактологічний матеріал про всі фактори, які впливають на стан і тенденції розвитку організації. При формуванні бази даних вирішуються питання про систему збереження і обновлення даних, а також обгрунтовується ув’язка даних, їх взаємна узгодженість, можливість проведення порівняння і співставлення оцінок даних, що зберігаються в банку даних. Це має суттєве значення при об’єднанні первинних даних в укрупнені групи (файли) із своїми реквізитами. Бази даних неперервно обновлюються з врахуванням вимог основних користувачів банку даних.

На сьогодні в абсолютній більшості організацій створені і використовуються бази даних, в яких зберігається постійно обновлювана, максимально деталізована і систематизована по різноманітних ознаках інформація про кадровий склад працівників. Це дозволяє оперативно відслідковувати укомплектованість штатів, переміщення кадрів всередині організації, набір і звільнення працівників, заходи спрямовані на підвищення їх кваліфікації.

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

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

Такие СУБД как Oracle, Informix, Sybase, т.е. серверы баз данных, позволяют задавать весь спектр ограничений целостности. Принципиально важным при этом является использование средств, позволяющих задавать ограничения, накладываемые на связи между объектами, поскольку это позволяет значительно увеличить семантическую мощность базы данных и тем самым повысить ее адекватность предметной области. Таким образом, данные в такой базе уже нельзя рассматривать как некий абстрактный объект, не имеющий связи с объектами предметной области.

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

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

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

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

32. CASE засоби в системному аналізі.

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

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

Для CASE существуют 4 типа диаграмм: диаграммы функционального проектирования (для этих целей наиболее часто употребляются DFD-диаграммы потоков данных), диаграммы моделирования данных (как правило, ERD-диаграммы "сущность-связь"), диаграммы моделирования поведения (как правило, STD-диаграммы переходов состояний) и структурные диаграммы (карты), применяющиеся на этапе проектирования и описывающие отношения между модулями и внутримодульную структуру. Создание и модификация подобных диаграмм осуществляется с помощью специальных графических редакторов (диаграммеров), являющихся сервисными средствами на этапах анализа требований и проектирования спецификаций.

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

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

33. Використання CASE-засобів для побудови інформаційних моделей

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

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

2. По FD-модели предметной области строится совокупность диаграмм потоков данных (DF-модель). Данные диаграммы, используя функции и процессы, описанные на уровне FD-модели, позволяют детализировать описание предметной области за счет введения накопителей, потоков данных и внешних сущностей. В описательном смысле это соответствует добавлению к функциональной структуре объекта предметной области данных, полученных при обследовании документооборота – сведений о поставщиках и получателях информации, структуре и реквизитном составе документов, структуре потоков данных и накопителей. Эти хранимые в репозитории описания используются для перехода к построению диаграммам «сущность-связь».

3. По результатам анализа содержания накопителей данных строятся диаграммы типа «сущность-связь». В отличие от FD- и DF-диаграмм эти диаграммы описывают структуру системы понятий, в рамках которой сотрудники функциональных служб системы управления предприятием реализуют процессы своей предметной деятельности. Этот процесс требует высокой квалификации и значительных интеллектуальных затрат, но в соответствии с концепцией применения современных CASE-технологий является необходимой стадией в структурном анализе информационных систем.

34.Етапи та зміст універсального процесу розробки

1. Начальный этап

- Запуск проэкта:

Цель:

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

- Определить действие,кот будет выполнять система

- Определениеобщей стоимости - Идентификация рисков

Действие этапа:

- Формировка области примен проэкта, кот.рассматривается в рамках критерия реализ

- Планирование альтернатив развития проэкта + бизнесс планирование

- Синтез архитектуры системы (реализацияпланового распределения системы)

Результаты этапа:

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

2. Процесс развития:

Цель:

- Создание архитектурного базиса системы

- Определение оставшихсятребований

- Функциональные требования и проектирование

- Определить архитектурную пиат-форму процесса

- Отслеживание риска и определение опасной состовляющей

a1 – P1 a2 – P2 P1>P2>…>Pn, сумма Pi=1 An – Pn

Исходя из По установим,что Pi<=Р(со звездочкой) и отсечь ненужное по задан парам

Основные действия:

- Так как задача опредлеляет архитектуру базиса,то развитие спецификации и представления об еепунктах

- Развитие архитектуры и ее действий(компонент-информационных и математических)

Результаты этапа:

- Модель системы (мы должны реализовать 80% и больше)

- Дополнительные нефункциональные требования(дизайн)

- Описание программной архитектуры(язык, алгоритм UML)

- Выяснить архитектурный макет - Пересмотренный вариант системы

- Пересмотренный вариант рисков – Pi уменьшается(if -then)

3. Этап конструирования:

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

- Минимизировать стоимость разработки путем оптимизации ее распределения ресурсов (F) С+Ru->extr

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

- Добиться получения контрольных версий

Основные действия:

- Управление ресурсами - Оптимизация и контроль процессов

- Полная программная разработка и тестирование - Оценка реализации

Результаты этапа:

Артефакты-продуктыэксплуатации

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

- Описание тенденций реализации

- Руководство пользователя

35. Наведіть основні результати та критично проаналізуйте побудову та результати досліджень моделей по нотації IDEF0 в системах штучного інтелекту

IDEF0 - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами. Так же отображаются все сигналы управления, которые на DFD (Диаграмме Потоков Данных) не отображались. Данная модель является одной из самых прогрессивных моделей и используется при организации бизнес проектов и проектов, основанных на моделировании всех процессов как административных, так и организационных

Методологія IDEF0 пропонує побудову ієрархічної системи діаграм - одиничних описів фрагментів системи. Спочатку проводиться опис системи в цілому і її взаємодії з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція - система розбивається на підсистеми й кожну підсистему описується окремо (діаграми декомпозиції). Потім кожна підсистема розбивається на більше дрібні й так далі до досягнення потрібного ступеня деталізації.

Кожна IDEF0-діаграма містить блоки й дуги. Блоки зображують функції системи, що моделюється. Дуги зв'язують блоки разом і відображають взаємодії й взаємозв'язки між ними.

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

IDEF0 вимагає, щоб у діаграмі було не менш трьох і не більше шести блоків.

Кожна сторона блоку має особливе, цілком певне призначення. Ліва сторона блоку признач для входів, верхня - для керування, права - для виходів, нижня - для механізм.

Взаємодія робіт із зовнішнім світом і між собою описується у вигляді стрілок, які зображуються одинарними лініями зі стрілками на кінцях. Стрілки являють собою якусь інформацію й іменуються іменниками.

В IDEF0 розрізняють п'ять типів стрілок. Вхід Керування Вихід Механізм Виклик

У методології IDEF0 потрібно тільки п'ять типів взаємодій між блоками для опису їхніх відносин: вхід, керування, зворотний зв'язок по входу, зворотний зв'язок по керуванню, вихід-механізм. Зв'язку по керуванню й входу є найпростішими, оскільки вони відбивають прямі впливи, які інтуїтивно зрозумілі й дуже прості.

В IDEF0 дуга рідко зображує один об'єкт. Звичайно вона символізує набір об'єктів. Тому що дуги представляють набори об'єктів, вони можуть мати множину початкових джерел і кінцевих призначень. Тому дуги можуть розгалужуватися й з'єднуватися різними способами. Вся дуга або її частина може виходити з одного або декількох блоків і закінчуватися в одному або декількох блоках.

Нотація IDEF0 (Integration Definition for Function Modeling) може бути використана для моделювання широкого класу систем. Для нових систем застосування IDEF0 має своєю метою визначення вимог і вироблення функціональних вказівок для наступної розробки системи, що відповідає поставленим вимогам і реалізує виділеним функціям. Стосовно до вже існуючих систем IDEF0 може бути використана для аналізу функцій, які виконуються системою й відображення механізмів цих функцій. Результатом застосування IDEF0 до деякої системи є модель цієї системи, що складається з ієрархічно впорядкованого набору діаграм, тексту документації й словників, зв'язаних один з одним за допомогою перехресних посилань.

36. Наведіть основні результати та критично проаналізуйте побудову та результати досліджень моделей по нотації DFD

Діаграми потоків даних (Data Flow Diagrams) представляють мережу зв'язаних між собою робіт. Їх зручно використовувати для опису документообігу й обробки інформації. Для побудови діаграм DFD в BPwin використовується нотація Гейна-Сарсона (таблиця 1).

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

Призначення процесу складається в продукуванні вихідних потоків із вхідних відповідно до дії, що задається ім'ям процесу.

Сховище даних дозволяє на певних ділянках визначати дані, які будуть зберігатися в пам'яті між процесами. Фактично сховище представляє «зрізи» потоків даних у часі. Інформація, що воно містить, може використовуватися в будь-який час після її визначення, при цьому дані можуть вибиратися в будь-якому порядку.

Сховище даних у загальному випадку є прообразом майбутньої бази даних, і опис даних, що зберігаються на ньому, повинне бути зв'язане з інформаційною моделлю (ERD). Ім'я сховища повинне ідентифікувати його вміст, воно вибирається з міркування найбільшої інформативності для проектувальника. У випадку, коли потік даних входить у сховище або виходить із нього і його структура відповідає структурі сховища, він повинен мати те ж саме ім'я, і немає необхідності відображати його на діаграмі.

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

Діаграми DFD можна використовувати як доповнення до діаграм IDEF0 для опису документообігу й обробки інформації.

Побудова діаграм DFD. Діаграми DFD можуть бути побудовані з використанням традиційного структурного аналізу, подібно тому як будуються діаграми IDEF0. Спочатку будується фізична модель, що відображає поточний стан справ. Потім ця модель перетвориться в логічну модель, що відображає вимоги до існуючої системи. Після цього будується модель, що відображає вимоги до майбутньої системи. І нарешті, будується фізична модель, на основі якої повинна бути побудована нова система.

Альтернативним підходом є підхід, популярний при створенні програмного забезпечення, який називається подійним поділом (event partitioning), у якому різні діаграми DFD будують модель системи. По-перше, логічна модель будується як сукупність робіт і документування того, що вони (ці роботи) повинні робити.

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

Нарешті, модель поводження (behavior model) показує, як система обробляє події. Ця модель складається з однієї діаграми, у якій кожний прямокутник зображує кожну подію з моделі оточення. Сховища можуть бути додані для моделювання даних, які необхідно запам'ятовувати між подіями. Потоки додаються для зв'язку з іншими елементами, і діаграма перевіряється з погляду відповідності моделі оточення.

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

37. Наведіть основні результати та критично проаналізуйте побудову та результати досліджень моделей по нотації IDEF3

Однак для опису логіки взаємодії інформаційних потоків більше підходить IDEF3, називана також workflow diagramming - методологією моделювання, що використовує графічний опис інформаційних потоків, взаємин між процесами обробки інформації й об'єктів, що є частиною цих процесів. Діаграми Workflow можуть бути використані в моделюванні бізнес-процесів для аналізу завершеності процедур обробки інформації. З їхньою допомогою можна описувати сценарії дій співробітників організації, наприклад послідовність обробки замовлення або події, які необхідно обробити за кінцевий час. Кожний сценарій супроводжується описом процесу й може бути використаний для документування кожної функції.

IDEF3 - це метод, що має своєю основною метою дати можливість аналітикам описати ситуацію, коли процеси виконуються в певній послідовності, а також описати об'єкти, що беруть участь спільно в одному процесі.

IDEF3 доповнює IDEF0 і містить все необхідне для побудови моделей які надалі можуть бути використані для імітаційного аналізу.

Кожна робота в IDEF3 описує який-небудь сценарій бізнес-процесу й може бути складовою частиною іншої роботи. Оскільки сценарій описує мету й рамки моделі, важливо, щоб роботи йменувалися віддієслівним іменником, що позначає процес дії, або фразою, що містить такий іменник.

Одиниці роботи - Unit of Work (UOW). UOW, також називані роботами (activity), є центральними компонентами моделі. В IDEF3 роботи зображуються прямокутниками із прямими кутами й мають ім'я, виражене віддієслівним іменником, що позначає процес дії, одиночним або в складі фрази й номер (ідентифікатор). Часто ім'я роботи міняється в процесі моделювання, оскільки модель може уточнюватися й редагуватися. Ідентифікатор роботи привласнюється при створенні й не міняється ніколи. Навіть якщо робота буде вилучена, її ідентифікатор не буде знову використовуватися для інших робіт. Звичайно номер роботи складається з номера батьківської роботи й порядкового номера на поточній діаграмі.

Зв'язок. Зв'язки показують взаємини робіт. Всі зв'язки в IDEF3 односпрямовані й можуть бути спрямовані куди завгодно, але звичайно діаграми IDEF3 намагаються побудувати так, щоб зв'язку були спрямовані ліворуч праворуч. В IDEF3 розрізняють три типи стрілок, що зображують зв'язки, стиль яких установлюється через меню Edit/Arrow Style:

Головна (Precedence) - суцільна лінія, що зв'язує одиниці робіт (UOW). Рисується ліворуч праворуч або зверху долілиць. Показує, що робота-джерело повинна закінчитися перш, ніж робота-ціль почнеться.

Відносини (Relational Link) - пунктирна лінія, що використовується для зображення зв'язків між одиницями робіт (UOW) а також між одиницями робіт і об'єктами посилань.

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

Головний зв'язок і потік об'єктів. Головний зв'язок показує, що робота-джерело закінчується раніше, ніж починається робота-мета. Часто результатом роботи-джерела стає об'єкт, необхідний для роботи-мети. У цьому випадку стрілку, що позначає об'єкт, зображують із подвійним наконечником. Ім'я стрілки повинне ясно ідентифікувати відображуваний об'єкт. Потік об'єктів має ту ж семантику, що й головна стрілка.

Відношення показує, що стрілка є альтернативою головній стрілці або потоку об'єктів у змісті завдання послідовності виконання робіт - робота-джерело не обов'язково повинна закінчитися, перш ніж робота-ціль почнеться. Більше того, робота-ціль може закінчитися перш, ніж закінчиться робота-джерело

Перехрестя (Junction). Закінчення однієї роботи може служити сигналом до початку декількох робіт, або ж одна робота для свого запуску може очікувати закінчення декількох робіт. Перехрестя використовуються для відображення логіки взаємодії стрілок при злитті й розгалуженні або для відображення множини подій, які можуть або повинні бути завершені перед початком наступної роботи.

Об'єкт посилання. Об'єкт посилання в IDEF3 виражає якусь ідею, концепцію або дані, які не можна зв'язати зі стрілкою, перехрестям або роботою. Об'єкт посилання зображується у вигляді прямокутника, схожого на прямокутник роботи. Об'єкти посилання повинні бути пов'язані з одиницями робіт або перехрестями пунктирними лініями.

Декомпозиція робіт. В IDEF3 декомпозиція використовується для деталізації робіт. Методологія IDEF3 дозволяє декомпозувати роботу багаторазово, тобто робота може мати множину дочірніх робіт. Це дозволяє в одній моделі описати альтернативні потоки. Можливість множинної декомпозиції висуває додаткові вимоги до нумерації робіт. Так, номер роботи складається з номера батьківської роботи, версії декомпозиції й власного номера роботи на поточній діаграмі.

38. Ідентифікація ризиків.

1. Категории рисков:

- проэктные риски - технические риски - коммерческие риски

1.1 Источники проектного риска:

- Вывод бюджета,плана - Формирование тренований кпрограммному продукту

- Выбор структуры програмного продукта - Методика взаимодействия с заказчиком

1.2 Источники технических рисков

- Разработка проэктов - Неточность спецификации

- Наличие неопределенностей + ожидаемые решения - Отсутствие технических средств

1.3 Коммерческие риски:

- Создание програмного продукта которыйне относится к R-ном.риску

- Создание программнеого продукта,опрежающего требования работодатчика

- Потери проэктирования

39. Категорії джерел ризику

1.Проектные риски(относятнся к проэктам):

Источники:

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

- формирование тренований к програмному продукту

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

2. Технические риски (аппаратурные или технические риски,оказывающие риски):

Источники:

- Трудности проектирования реализации интерфейса тестового обеспечения

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

- Наличие неопределенности + отсталые решения (неопределенные…для них риски не могут быть идентефицированы)

- Отсутствие технических средств

3.Коммерческие риски(финансирование,маркетинг,реклама)

Источники:

- Создание программного продукта,кот.непользуется спросом

- Создание программного продукта,опережающего требования рынка

- Потеря финансирования

40. Аналіз ризиків.

Анализ рисков – оценка вероятности возникновения какого-либо события

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

41.Ранжування ризиків

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

Управление: Управляющий строительной организацией (общее руководство)

Входные данные: заполненная форма «риск-регистр» и «экспертная оценка риска»

Выходные данные: заполненная форма «рейтинг рисков»

Механизм: Комитет управления рисками

Система: обзор рисков, выбор критериев ранжирования, ранжирование

42. Планування управління ризиками. Стеження за ризиками

Риск – степень удовлетворения каких-либо потребностей

Эффект=потери*ожидаемые потери риска

E=R*L

R – влияние риска, где R[0,1]

Степень потери от риска:

RE=P*L(UO)

P-степень вероятности

L(UO) – потери риска

P(UO) – вероятность временного риска

Управление рисками обычно включает:

1. Идентификация рисков –выявление по каким-то критериям,что в дан. Случае есть риски(аналитическими градиентными методами);

2. Анализ рисков – результатом а.р. является ранжирование

RE1 P1

RE2 P2, при чем P1>P2>=…Pn, где P1 – самый сложный

3. Ранжирование рисков;

4. Планирование по управлению риском (составляют некоторый план,кот. Является очевидным для развязки некот сущностей);

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

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

43. Рівні тестування. Види тестування

Уровни тестирования:

- Модульное тестирование тестирует минимальный компонент программы или модуля. Каждый модуль тестируется для проверки правильности его реализации.

- Интеграционное тестирование позволяет проверить логику взаимодействия аппаратуры и ПО; выявляет дефекты в интерфейсах и во взаимодействии между компонентами (модулями).

- Системное тестирование охватывает всю систему и позволяет проверить функциональность компонент системы на системном уровне.

- Системное интеграционное тестирование проверяет, система интегрируется в любую внешнюю систему (или системы) в соответствии с системных требований.

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

а) надежность (То = 1/»лямбда» (часы), «лямбда» - интеснивность отказа)

б) быстродействие дельта-Т;

Виды тестирования (из конспекта):

1. Приемочное тестирование – реализует требования заказчика:

а) надежность (То = 1/»лямбда» (часы), «лямбда» - интеснивность отказа)

б) быстродействие дельта-Т;

2. Установочное тестирование альфа, бета – тестирование

3. Функциональные тесты (тесты соответствий) 4. Достижение надежности

5. Регрессионное тестирование(предмет соответствия установленным нормам)

6. Тестирование производительности

7. Нагрузочное тестирование (аппаратуры определяют все поворные тесты)

7. Сравнительное тестирование(есть старая версия,работающая и есть новая,но она должна работать по старым критериям с какими-то улучшенными моментами в работе. Новая версия всегда должна быть лучше)

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

10. Конфигурационное тестирование

11. Тестирование удобства и простоты использования

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

44. Техніка тестування. Особливості використання. Переваги, недоліки

Техника тестирования:

1. техники базируются на интуиции и знаниях инженеров

- специализированные тестирования

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

2. техники базируются на спецификации вход, выход, дел. – техники задания

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

- эквивалентность разделения(выделение эквивалентных классов)

- анализ граничных значений

3. Таблица принятий решений

4. Тестирование на основе конечного автомата - Случайное тестирование

5. Техники ориентированнные на код(ориентируются на структурное тестирование)

Дата добавления: 2017-02-01