Основи методології проектування ІС 2

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Основи методології проектування ІС

1. Життєвий цикл з ІВ

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

Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO / IEC 12207 [8] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electro-technical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.

Структура ЖЦ ПЗ за стандартом ISO / IEC 12207 базується на трьох групах процесів:

основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);

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

організаційний процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).

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

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

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

Управління конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, передусім процеси розробки і супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди чи версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури та забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати і контролювати внесення змін в ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені в проекті стандарту ISO / IEC 12207-2 [8].

Кожен процес характеризується певними завданнями і методами їх вирішення, вихідними даними, отриманими на попередньому етапі, і результатами. Результатами аналізу, зокрема, є функціональні моделі, інформаційні моделі та відповідні їм діаграми. ЖЦ ПО носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, вироблених на більш ранніх етапах.

2. Моделі життєвого циклу ПЗ

Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO / IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.

Під моделлю ЖЦ розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій і завдань протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС та специфіки умов, в яких система створюється і функціонує. До теперішнього часу найбільшого поширення набули наступні дві основні моделі ЖЦ: каскадна модель (1970 - 1985 рр..) Й спіральна модель (1986 - 1990 рр..).

У спочатку існували однорідних ІС програми представляли собою єдине ціле. Для розробки такого типу додатки застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершено роботу на поточному (рис. 1.1)

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

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

на кожному етапі формується закінчений набір проектної документації, який відповідає критеріям повноти та узгодженості;

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

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


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

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

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

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

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

3. Методології та технології проектування ІС

3.1 Загальні вимоги до методології та технології

Методології, технології та інструментальні засоби проектування (CASE - засоби) складають основу проекту будь-ІВ. Методологія реалізується через конкретні технології та підтримує її стандарти, методики та інструментальні засоби, які забезпечують виконання процесів ЖЦ.

Технологія проектування визначається як сукупність трьох складових:

покрокової процедури, яка визначає послідовність технологічних операцій проектування (рис. 1.4);

критеріїв та правил, що використовуються для оцінки результатів виконання технологічних операцій;

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

Рис. 1.4. Схема технологічної операції проектування

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

Технологія проектування, розробки і супроводу ІС повинна задовольняти наступним загальним вимогам:

підтримка повного ЖЦ ПЗ;

гарантоване досягнення цілей розробки ІС з заданою кількістю і з встановлений час;

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

можливість ведення робіт з проектування окремих підсистем невеликими групами (3-7 осіб). Це обумовлено принципами керованості колективу і підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;

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

можливість управління конфігурацією проекту, ведення версій проекту і його складових, можливість автоматичного випуску проектної документації та синхронізації її версій з версіями проекту;

незалежність виконуваних проектних рішень від засобів реалізації ІС (систем управління базами даних (СКБД), операційних систем, мов і систем програмування).

підтримка комплексів узгоджених CASE - засобів, що забезпечують автоматизацію процесів, які виконуються на всіх стадіях ЖЦ. Загальний підхід до оцінки і вибору CASE - засобів описаний в розд. 4, приклади комплексів CASE - засобів - у підрозділ. 5.7.

Реальне застосування будь-якої технології проектування, розробки і супроводу ІС в конкретній організації і конкретному проекті неможливо без вироблення ряду стандартів (правил, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів належать такі:

стандарт проектування;

стандарт оформлення проектної документації;

стандарт інтерфейсу користувача;

Перераховані стандарти встановлюють певні вимоги.

Стандарт проектування:

набір необхідних моделей (діаграм) на кожній стадії проектування і ступінь їх деталізації;

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

вимоги до конфігурації робочих місць розробників, включаючи налаштування операційної системи, настройки CASE - засобів, загальні налаштування проекту і т.д.;

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

Стандарт оформлення проектної документації:

комплектність склад і структура документації на кожній стадії проектування;

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

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

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

вимоги до налаштування CASE - засобів для забезпечення підготовки документації відповідно до встановлених правил.

Стандарт інтерфейсу користувача:

правила оформлення екранів (шрифти і колірна палітра), склад і розташування вікон і елементів управління;

правила використання клавіатури і миші;

правила оформлення текстів допомоги;

перелік стандартних повідомлень;

правила обробки реакції користувача.

3.2 Методологія RAD

Один з підходів до розробки ПЗ в рамках спіральної моделі ЖЦ - отримала широке поширення методологія швидкої розробки програми RAD (Rapid Application Development), вона включає в себе три складові:

невелику команду програмістів (від 2 до 10 осіб);

короткий, ретельно пророблений виробничий графік (від 2 до 6 міс.);

повторюваний цикл, при якому розробники в міру того, як додаток починає набувати форму, запитує та реалізують в продукті вимоги, отримані через взаємодію з замовником.

Команда розробників повинна являти собою групу професіоналів, що мають досвід в аналізі, проектуванні, генерації коду і тестуванні ПЗ з використанням CASE - засобів, здатних добре взаємодіяти з кінцевими користувачами і трансформувати їх пропозиції в робочі прототипи.

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз: аналізу і планування вимог, проектування, побудови; впровадження.

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

На фазі проектування частина користувачів бере участь у технічному проектуванні системи під керівництвом фахівців-розробників. CASE - засоби використовуються для швидкого отримання працюють прототипу. Користувачі, безпосередньо взаємодіють з ними, уточнюють і доповнюють вимоги до системи, які не були виявлені на попередній фазі. Більш докладно розглядаються процеси системи. Аналізується і при необхідності коректується функціональна модель. Кожен процес розглядається детально. Якщо потрібно, для кожного елементарного процесу створюється частковий прототип: екран, діалог, звіт, що усуває несправності мул неоднозначності. Встановлюються вимоги розмежування доступу до даних. На цьому самому етапі відбувається визначення необхідної документації.

Після детального визначення складу процесів визначається кількість функціональних елементів системи, що розробляється і приймається рішення про поділ ІС на підсистеми, піддаються реалізації однією командою розробників на прийнятне для RAD - проектів час (60 - 90 днів). З використанням CASE - засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

загальна інформаційна модель системи;

функціональні моделі системи в цілому і підсистем, що реалізуються окремими командами розробників;

точно визначені за допомогою CASE - засобів інтерфейси між автономно розробляються підсистемами;

побудовані прототипи екранів, звітів, діалогів.

Усі моделі та прототипи повинні бути отримані із застосуванням тих CASE - засобів, які будуть використовуватися в подальшому при побудові системи. Дане вимога викликана тим, що в традиційному підході при передачі інформації про проект з етапу на етап може відбутися фактично неконтрольоване спотворення даних. Застосування єдиної середовища зберігання інформації про проект дозволяє цього уникнути.

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

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

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

визначається необхідність розподілу даних;

здійснюється аналіз використання даних;

виробляється фізичне проектування бази даних;

визначаються вимоги до апаратних ресурсів;

визначаються способи збільшення продуктивності;

завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всіх узгоджених вимогам.

На фазі впровадження проводиться навчання користувачів, організаційні зміни і паралельно з впровадженням нової системи здійснюється робота з існуючою системою (до повного впровадження нової). Так як фаза побудови досить нетривало, планування та підготовка до впровадження повинні починатися заздалегідь, як правило, на етапі проектування системи. Наведена схема розробки ІС не є абсолютною. Можливі різні варіанти, які залежать, наприклад, від початкових умов, в яких ведеться розробка: розробляється зовсім нова система: вже було проведено обстеження підприємства і існує модель його діяльності; на підприємстві вже існує деяка ІС, яка може бути використана в якості початкового прототипу або повинна бути інтегрована з розробляється.

Слід, однак, відзначити, що методологія RAD, як і будь-яка інша, не може претендувати на універсальність, вона хороша в першу чергу для відносно невеликих проектів, що розробляються для конкретного замовника. Якщо ж розробляється типова система, яка не є закінченим продуктом, а являє собою комплекс типових компонентів, централізовано супроводжуваних, адаптуються до програмно-технічним платформ, СУБД, засобів телекомунікації, організаційно-економічним особливостям об'єктів впровадження та інтегруються з існуючими розробками, на перший план виступають такі показники проекту, як керованість і якість, які можуть увійти в суперечність з простотою і швидкістю розробки. Для таких проектів необхідні високий рівень планування і жорстка дисципліна проектування, суворе дотримання заздалегідь розробленим протоколів та інтерфейсів, що знижує швидкість розробки.

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

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

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

менше 1000 функціональних елементів - одна людина;

1000 - 4000 функціональних елементів - одна команда розробників;

більше 4000 функціональних елементів - 4000 функціональних елементів на одну команду розробників;

Отже, перелічимо основні принципи методології RAD:

розробка додатків итерациями;

необов'язковість повного завершення робіт на кожній з етапів життєвого циклу;

обов'язковість залучення користувачів до процесу розробки ІС;

необов'язковість застосування CASE - засобів, що забезпечують цілісність проекту;

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

необхідність використання генераторів коду;

використання прототипування, що дозволяє повніше з'ясувати і задовольнити потреби з розробкою;

ведення розробки нечисленної добре керованою командою професіоналів;

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

20


Додати в блог або на сайт

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

Програмування, комп'ютери, інформатика і кібернетика | Реферат
57.9кб. | скачати


Схожі роботи:
Основи методології проектування ІС
Проектування бази даних Вивчення методології
Розробка моделі Станції переливання крові з використанням методології проектування IDEF0 DFD
Основи методології та методики комплексного економічного аналізу
Відмінність методології Д. Рікардо від методології А. Сміта
Природно-наукове пізнання структура і динаміка Основи методології природничо-наукового пізнання
Ергономічні основи проектування
Основи проектування і конструювання
Основи архітектурно-будівельного проектування
© Усі права захищені
написати до нас