Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

Dual Vee Model



План:


Введення

Dual Vee Model грунтується на V-моделі, щоб показати складнощі, пов'язані з проектуванням і розробкою систем. В системотехніці вона визначає єдиний порядок розробки продукту або проекту. Модель зображує одночасний розвиток архітектури системи як однієї V-моделі з кожним об'єктом цієї архітектури як іншу V модель, яка перетинає архітектуру V моделі. Це явно показує взаємодії і послідовності в розробці складних систем і систем систем.


1. Передумова

1.1. Модель водоспаду

Немодифікованих модель водоспаду.

Модель Водоспаду розбиває процес розробки на розробку фаз. Назва означає, що проектні рішення випливають з вимог, реалізація випливає з проекту і т.д. У великому проекті багато різних людей працюють тільки над певними частинами проекту. Так проектувальник може запитати: "Що я намагаюся спроектувати?" і відповідь може бути: "Ви намагаєтеся спроектувати щось, що буде задовольняти вимогам до продукту." Розробник може запитати: "Що я намагаюся розробити?" і відповідь може бути: "Ви намагаєтеся розробити те, що було спроектовано." і т.п.


1.2. V-Model

V-Model процесу розробки ІС. [1]

V-модель організує фази розробки виходячи з рівня складності, де найбільш складний пункт буде вгорі, а найпростіший - внизу (також відомий як Самий нижній пункт конфігурації). Це ставить вимоги в початок поряд з функціонуванням продукту в кінці і проектування поряд з перевіркою. Це має сенс, оскільки коли розробник поставляє продукт клієнту, клієнт може запитати: "Чому я повинен прийняти цей продукт?" і розробник повинен відповісти: "Тому що він відповідає вашим (клієнтським) вимогам". Вимоги пов'язані з функціонуванням. При виконанні тестування продукту, інженер-тестіровшік може запитати: "Які тести я повинен провести?" і проектувальник повинен відповість: "Ви повинні провести тести, щоб показати продукт, який був побудований у відповідності з проектом." Перевірка пов'язана з проектом. V-модель може бути розширена в декількох напрямках для задоволення системних вимог. Це може включати в себе сім INCOSE шарів складності системи (наприклад система, елемент, подссістема, зборка, подсборка, компонент і частина). Це може включати в себе розбивку, визначення, інтеграцію та перевірку. Також це може включати участь користувачів / зацікавлених сторін, управління ризиками та вирішення проблем.


1.3. Dual Vee Model

Подвійна V модель грунтується на V моделі для управління системою систем. Архітектура V керує системою і набором гілок V моделі виходять з V архітектури для управління підсистемами. Наприклад, GPS включає в себе сукупність супутників, наземну мережу управління та мільйони користувачів по всьому світу. Кожен супутник, наземний центр управління та GPS приймач являють собою складну систему, яка може перебувати під управлінням окремого об'єкта V моделі. Розробка супутника може вплинути на проектування, виробництво або вартість приймачів. Подібно розробка приймача може вплинути на проект, виробництво і вартість супутників. Так що все повинно бути інтегровано в систему систем, яка розробляється в рамках більш великої Vee Архітектури.


2. Vee Архітектура

При розробці складних систем, системний інженер повинен управляти підсумкової конфігурацією системи від початку і до кінця. Підсумкова конфігурація може включати проектну документацію, керівництва по експлуатації, сам продукт і повинна відповідати на питання Що, Чому? і Хто? по архітектурі системи. На кожній фазі розробки будуть зміни в системі, які призведуть до зміни підсумкової конфігурації. Ядро Vee є разівающаюся модель від початкових вимог до готової системі. Vee Архітектура відповідає на питання що, чому і хто (який рівень системи) відповідає за архітектуру системи. Низхідні з V ядра дослідження підсилюють процес отримання знань для підтвердження підсумкових архітектурних рішень зроблених в ядрі V. Висхідні з ядра взаємодії з клієнтами та користувачами підсилюють поетапне підтвердження підтримуючи залученість зацікавлених осіб в кінцевому продукті. Необхідно звернути увагу на те, що у всіх V моделях представлення часу і завершеності продукту рухається зліва направо. Так само як ми не можемо переміщатися назад у часі, також ми не можемо рухатися справа наліво в V моделях. Послідовне наближення - це основне в розробці системи і всі кроки робляться вертикально від ядра, вгору до користувачів і клієнтам (що є поетапне підтвердження) і вниз до управління ризиками і новими можливостями. Ліва гілка Vee ядра зосереджена навколо того, яка концепція краще і яка архітектура краще для цієї концепції. Наприклад, комерційні продукти зазвичай стикаються з дилемою: батареї повинні бути стандартними, унікальними, які замінюються чи ні спадні з V ядра дослідження і аналізи можуть прискорити визначення найбільш бажаного методу, який міг би бути пізніше зафіксований на V ядрі якщо все заінтересрванние особи згодні. Подібні дослідження можуть довести життєздатність та технічні можливості варіанта концепції. Права гілка V ядра спадних досліджень управляється на рівні дослідження інтеграційних аномалій для визначення причин і усунення їх. Висхідні взаємодії із зацікавленими особами визначають, чи згодні вони з такою інтеграцією і виконаної перевіркою. На кожному представленому рівні існує прямий зв'язок між діями з лівого і правого боку V моделі. Це зроблено умисно. Наприклад, метод інтеграції, перевірки і затвердження які будуть використовуватися в правій частині повинні бути визначені в лівій частині також як концепції визначені на кожному з рівнів. Це мінімізує ймовірність того, що концепції задумані таким чином, що їх неможливість здійснити.


3. Структура V моделі

Структура V моделі показує її розробку і реалізацію, процес який описує як кожен об'єкт буде отриманий (розроблений, придбаний, повторно використаний і т.д.) Модель Vee існує для кожного об'єкта архітектури починаючи з рівня системи вниз до рівня найдрібніших конфігураційних елементів (LCI) , такі як елементи комп'ютерного забезпечення або мікросхеми. Всі дії усередині об'єкту Vee знаходяться на тому ж самому рівні архітектура (Система, Підсистема, LCI). Ліва гілка Vee представляє визначення моделі, її розвиток від чорнових вимог клієнта, через визначення концепції і до опису рішення і повністю побудованого зразка. Права гілка Vee представляє послідовність складання об'єкта і її гарантована продуктивність отримана за допомогою перевірок і тверджень об'єкта. У кожній розробці, існує залежність між діями на лівій і правій гілки Об'єкту Vee. Це зроблено спеціально. Метод перевірки, які будуть використовуватися в правій гілки Vee повинні бути визначені одночасно з розробкою вимог на лівій гілки, в іншому випадку можуть бути створені вимоги, які не можуть буть перевірені. Наприклад, "бути дружнім до користувача" є підходящим вимогою, але його перевірити не можливо. Замість цього, вимога, яка стверджує що на екрані комп'ютера може бути "не більше п'яти рядків тексту, набраними 14 шрифтом тексту" визначає один користувальницький критерій вимоги "бути дружнім до користувача" у вимірних величинах. План перевірок повинні бути погоджений і зафіксований щоб гарантувати, що вимоги до перевірок та їх методи відомі і заплановані на етапі прийняття рішення по розробці, званого Перевірка Попереднього Проекту (Preliminary Design Review (PDR)). Чорнові процедури перевірок засновані на вимогах до перевірок, плані перевірок, і запропонованому проекті об'єкта повинні бути відомі на етапі прийняття рішення по створенню і програмування, зазвичай званому Остаточна Оцінка Розробки (Critical Design Review (CDR)). Це знижує ймовірність того, що перевірка, у тому вигляді якому вона визначена не може, бути виконана. Вертикальне розмір Vee Об'єкту це зафіксована розробка на обраному рівні архітектури і ядро ​​Vee Об'єкту предтавляющее підсумкову послідовність розробки об'єкта. Також включені (за аналогією з Vee Архітектурою) дії, пов'язані з управлінням можливостями і ризиками, здійснювані в низхідному від ядра об'єкта напрямку до рівня необхідного для оцінки і вирішення проблеми. Наприклад, лабораторні випробування комп'ютерного чіпа або програмного забезпечення можуть бути необхідні для підтвердження технічної придатності. На відміну від широко поширеної думки про Моделі Водоспаду, не існує заборони на виконання пробної розробки та її аналізу в будь-якій точці проектного циклу для дослідження або докази продуктивності або придатності. На відміну від Спіральної Моделі, в Vee моделі дослідження можливостей і ризиків можуть бути виконані послідовно або в паралель з основною розробкою, а не проводитися постфактум або до процесу розробки рішення. Апаратні та програмні вимоги розуміння моделей або технічної придатності моделей вітаються на початку проектного циклу для реалізації таких можливостей, як нові технології, і для зниження ризику. Наприклад, для оцінки концепції ручного коректування тексту в порівнянні з повністю автоматичним коректуванням, технічна придатність обох концепцій може бути змодельована і вибір може бути зроблений на основі порівняння часу і вартості рішень. Згода клієнта може також забезпечити необходіное в проектному циклі твердження більш пріоритетний метод. У правій гілки, спадні від основного процесу запити застосовуються для виконання збору і перевірки відхилень. Це може мати на увазі відбуваються від проекту помилки, дефекти при пайку або помилка оператора тощо. Висхідні від основного процесу користувальницькі взаємодії - отриманні користувальницького або клієнтського підтвердження або відмову від досягнутих результатів. Зверніть увагу а те, що в об'єкті Vee ці взаємодії вказують на індивідуальні рішення в моделе, а не на інтегровану архітектуру, виконану на Vee архітектурі. На будь-якому рівні представленої моделі клієнт моделі в той же час є керуючим декількох більш високих рівнів моделі. Наприклад, людина керуючий підсистемою електроживлення є клієнтом на рівні зарядних батарей і він виконує приймання цих самих батарей.


4. Подвійна Vee: перехрещуються архітектура і Моделі Vee

Щоб виявити те, що необхідно користувачу в системі, то що задовольняє ці користувальницькі потреби потрібно потрібно найбільш цінне рішення для кожного об'єкта архітектури. Це можна продемонструвати наочно розташувавши Vee об'єкти перпендикулярно до архітектури Vee. Для кожного об'єкта архітектури Vee існує відповідний об'єкт Vee який визначає розвиток і виконання об'єкта.

4.1. Розподіл точок прийняття рішення

Архітектурні об'єкти розробляються і інтегруються в архітектуру системи в заздалегідь певній послідовності у відповідності з кращими прикладами системної інженерії. Для спрощення картини тільки один об'єкт Vee показаний пересекающим архітектуру Vee на кожному рівні. Зверніть увагу, що послідовність розробки вказана зверху вниз, починаючи з системного рівня і триваюча послідовно зі схемою до нижнього рівня конфігурації складових частин (LCI). Ця послідовність гарантує, що існують відповідні вимоги, які зберігаються від початку до кінця і які можна легко відстежити. Коли зразок для розробки та програмування, що включає чорнову процедуру перевірки, готовий бути зафіксованим, послідовність прийняття рішення по розробці виконується знизу вгору, щоб довести придатність розробки або програмного коду. Точка прийняття рішення також підтверджує що якщо окочательное рішення буде побудовано у відповідності з розробленим зразком, необхідна продуктивність буде досягнута. Ця послідовність гарантує що якщо проекти об'єкта задовольняють вимогам прийнятим на етапі прийняття рішення по розробці, об'єкти будуть інтегровані в наступний більш високий рівень об'єкта, будуть реалізовані як очікувалося і будуть відповідати користувальницьким вимогам.


Примітки

  1. Clarus Concept of Operations. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
Перегляд цього шаблону Розробка програмного забезпечення
Відомі
діячі
Процес
Концепції
Напрямки
Моделі
розробки
Інші моделі

CMM CMMI Даних Function model IDEF Інформаційна Metamodeling Object model View model UML

Інше

Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Dual EC DRBG
V-Model
New Model Army
Ford Model T
Capability Maturity Model
Windows Driver Model
Document Object Model
Model Driven Architecture
Component Object Model
© Усі права захищені
написати до нас