Проектування ІС

n1.doc (14 стор.)
Оригінал


1   2   3   4   5   6   7   8   9   ...   14

Ц їли і етапи розробки консалтингових проектів (далі просто проектів).


Проектування ІС охоплює три основні області:

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

Основними цілями розробки проектів є:

Основні етапи розробки проектів:

1. Аналіз первинних вимог та планування робіт. Даний етап передує ініціацію робіт над проектом. Його основними завданнями є: аналіз первинних бізнес-вимог, попередня економічна оцінка проекту, побудова план-графіку виконання робіт, створення і навчання спільної робочої групи.

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

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

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

3. Побудова моделей діяльності підприємства.

На даному етапі здійснюється обробка результатів обстеження та побудова моделей діяльності підприємства таких типів:

Перехід від моделі "як є" до моделі "як має бути" здійснюється такими двома способами:

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

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

4. Розробка системного проекту. Даний етап є першою фазою розробки власне системи автоматизації (точніше фазою аналізу вимог до системи), на якій вимоги замовника уточнюються, формалізуються і документуються. Фактично на цьому етапі дається відповідь на питання: "Що повинна робити майбутня система?" На цьому етапі визначаються:

Системний проект будується на основі моделі "як має бути" і включає функціональну модель майбутньої системи відповідно до одним із загальновживаних стандартів (наприклад, IDEF0 або IDEF3), інформаційну модель (наприклад, у відповідності зі стандартом IDEF1X), а також технічне завдання на створення автоматизованої системи (наприклад, відповідно до ГОСТ 34.602-89).

5. Розробка пропозицій по автоматизації підприємства.

На підставі системного проекту здійснюється:

6. Розробка технічного проекту.

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

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

7. Розробка нової системи або налаштування існуючої системи.

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

Налаштування існуючої системи здійснюється за такими етапами:

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


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

Характеристики замовника, що впливають на оцінку ризику проекту:

Характеристики виконавця, що впливають на оцінку ризику проекту:

Загальні показники проекту, що впливають на оцінку його ризику:

Проектування інформаційних систем зазвичай розглядається в трьох аспектах:

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

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


  1. Життєвий цикл програмного забезпечення ІС і його етапи

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

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

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

Проектування інформаційних систем завжди починається з визначення мети проекту.

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

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

Зазвичай виділяють наступні етапи створення ІС:

Формування та аналіз вимог. Метою початкових етапів створення ІС, виконуваних на стадії аналізу діяльності організації, є формування вимог до ІС, коректно і точно відображають цілі та завдання організації-замовника. Фактично на цьому етапі дається відповідь на питання: "Що повинна робити майбутня система?".

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

Список вимог до розроблюваної системі повинен включати:

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

Крок 1. Моделювання бізнес-процесів, що протікають в організації і реалізують її цілі і завдання. Результат - розробка моделі організації.

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

Крок 2. Безліч моделей опису вимог до ІС перетвориться в систему моделей, що описують концептуальний проект ІС, що включає:

Крок 3. Формулювання вимог до ІС, в рамках яких:

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

Проектування

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

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

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

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

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

Кінцевими продуктами етапу проектування є:

На етапі проектування здійснюється також розробка архітектури ІС, що включає в себе вибір:

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

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

Етап проектування завершується розробкою технічного проекту ІС.

Реалізація

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

Тестування

Етап тестування зазвичай виявляється розподіленим у часі.

Крок 1 .. Після завершення розробки окремого модуля системи виконують автономний тест, який переслідує дві основні мети:

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

Крок 3. Група модулів тестується на надійність роботи, тобто проходять:

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

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

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

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

  1. Еволюція моделей життєвого циклу

Індустрія розробки автоматизованих інформаційних систем управління зародилася в 1950-х - 1960-х роках і до кінця століття набула цілком закінчені форми.

Етап 1. Основним підходом у проектуванні ІС був метод "знизу-вгору", коли система створювалася як набір додатків, найбільш важливих в даний момент для підтримки діяльності підприємства. Основною метою цих проектів було не створення тиражованих продуктів, а обслуговування поточних потреб конкретної установи. Такий підхід частково зберігається і сьогодні. В рамках "клаптикової автоматизації" досить добре забезпечується підтримка окремих функцій, але практично повністю відсутня стратегія розвитку комплексної системи автоматизації, а об'єднання функціональних підсистем перетворюється на самостійну і досить складну проблему.

Існують дві основні причини, по яких цей підхід зазнає невдачі:

  1. до вибору інструментальних засобів приступають ще до того, як будуть визначені потреби бізнесу, тобто тут вибір програмних засобів є питанням технології, а не бізнесу;

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

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

Етап 2. 1960-і-1970-і роки. Проектування "зверху-вниз". Цей етап пов'язаний з усвідомленням того факту, що існує потреба в досить стандартних програмних засобах автоматизації діяльності різних установ та підприємств.

З усього спектра проблем розробники виділили найбільш помітні: автоматизацію ведення бухгалтерського аналітичного обліку і технологічних процесів. Системи почали проектуватися "зверху-вниз", тобто у припущенні, що одна програма повинна задовольняти потреби багатьох користувачів.

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

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

Етап 3. Класичне проектування ІС бере свій початок у 70-х роках минулого сторіччя. Каскадна (Водопадна) модель. Характерна для періоду 1970-1985 рр.. Основною особливістю даної методики є послідовна організація робіт при розбитті структури ІС на заздалегідь визначений ряд підсистем: організаційне, методичне, інформаційне, програмне та апаратне забезпечення.

Каскадна модель (рис.1) передбачає послідовне виконання всіх етапів проекту в строго фіксованому порядку. Кожен етап завершується після повного виконання та документального оформлення всіх передбачених робіт.

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



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

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

Можна виділити наступні позитивні сторони застосування каскадного підходу:

Основні недоліки цього підходу:

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

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

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

Спіральна модель процесу розробки (рис. 3). Характерна для періоду після 1986 р.

і є альтернативою каскадної моделі.



Рис. 2. Поетапна модель з проміжним контролем

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

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

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

У той час як склад проектної бригади на різних етапах водоспадні моделі схильний до змін, спіральна модель орієнтована на стабільний склад бригади розробників.

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

Таким чином, можна відзначити наступні достоїнства спіральної моделі:

 накопичення та повторне використання програмних засобів, моделей і прототипів;

 орієнтація на розвиток і модифікацію ПЗ в процесі його проектування;

 аналіз ризику та витрат в процесі проектування.

У процесі вдосконалення з'явилася схема безперервної розробки ІС (рис.4). Характерною особливістю даної методики став безперервний спіральний процес розробки ІС з планованими точками передачі в експлуатацію нових версій і нових функціональних підсистем.


Розробка

Продовження розробки

Введення в дію

Продовження розробки


Введення в дію




Використання

Використання


Рис.4. Схема безперервної розробки

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



Рис. 5. Схема швидкого прототипування

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

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

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

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

Зауваження. Ітераційна розробка також допускає виключення частини коду при змінах. Але таке виключення не є навмисним.

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

Недоліками схеми безперервної розробки є жорсткість використовуваних моделей проектування і закритість створюваних ІС.

Складнощі використання швидкого прототипування полягають у тому, що:

Висновок:

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

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

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

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

Мета такої методології полягає в регламентації процесу проектування ІС та забезпеченні управління цим процесом з тим, щоб гарантувати виконання вимог як до самої ІС, так і до характеристик процесу розробки. Основними завданнями, вирішення яких має сприяти методологія проектування корпоративних ІС, є наступні:

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

Таким чином, наслідком недоліків класичних методів проектування з'явився перехід до системного проектування.

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


  1. Організація канонічного проектування ІС. Стадії та етапи

Організація канонічного проектування ІС орієнтована на використання головним чином каскадної моделі життєвого циклу ІС. Стадії та етапи роботи описані в стандарті ГОСТ 34.601-90.

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

Стадії та етапи створення ІС, що виконуються організаціями-учасниками, прописуються в договорах і технічних завданнях на виконання робіт:

Стадія 1. Формування вимог до ІС. На початковій стадії проектування виділяють наступні етапи робіт:

Стадія 2. Розробка концепції ІВ.

Стадія 3. Технічне завдання.

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

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

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

Стадія 7. Введення в дію.

Стадія 8. Супровід ІС.

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

На етапі обстеження доцільно виділити дві складові: визначення стратегії впровадження ІС і детальний аналіз діяльності організації.

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

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

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

Орієнтовний вміст цього документа:

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

Аналітики збирають і фіксують інформацію в двох взаємозв'язаних формах:

При вивченні кожної функціональної задачі управління визначаються:

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

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

На етапі обстеження слід класифікувати плановані функції системи за ступенем важливості. Один з можливих форматів представлення такої класифікації:

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

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

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

Моделі діяльності організації створюються у двох видах:

На етапі аналізу необхідно залучати до роботи групи тестування для вирішення наступних завдань:

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

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

При розробці технічного завдання необхідно вирішити наступні завдання:

Ескізний проект передбачає розробку попередніх проектних рішень по системі і її частинам.

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

Зміст ескізного проекту задається в ТЗ на систему. Як правило, на етапі ескізного проектування визначаються:

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

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

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

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

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

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

В залежності від взаємозв'язків частин ІС і об'єкта автоматизації випробування можуть бути автономні або комплексні. Автономні випробування охоплюють частини системи. Їх проводять у міру готовності частин системи до здачі в дослідну експлуатацію. Комплексні випробування проводять для груп взаємопов'язаних частин або для системи в цілому.

Для планування проведення всіх видів випробувань розробляється документ "Програма і методика випробувань". Розробник документа встановлюється в договорі або ТЗ. В якості додатку до документа можуть включатися тести або контрольні приклади.

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

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

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


  1. Коротка характеристика застосовуваних технологій проектування
Навчальний матеріал
© ukrdoc.com.ua
При копіюванні вкажіть посилання.
звернутися до адміністрації