Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація




Скачати 84.64 Kb.
НазваЛекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація
Дата конвертації16.03.2013
Розмір84.64 Kb.
ТипЛекція
uchni.com.ua > Інформатика > Лекція
Лекція №20

Тема: Типова архітектура інформаційних систем, їх класифікація
План

  1. Інформаційна система (ІС).

  2. Життєвий цикл по ІС.

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

  4. Структурний підхід до проектування ІС.


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

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

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

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

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

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

  • функціонування в неоднорідному середовищі на декількох апаратних платформах;

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

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

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

Життєвий цикл по ІС


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

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

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

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

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

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

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

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

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

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

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

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


Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПО (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозв'язку процесів, дій і задач, виконуваних впродовж ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, в яких остання створюється і функціонує). Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПО, але не конкретизує в деталях, як реалізувати або виконати дії і задачі, включені в ці процеси.

До теперішнього часу найбільше поширення набули наступні дві основні моделі ЖЦ:

  • каскадна модель (70-85 г.г.);

  • спіральна модель (86-90 г.г.).

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

Позитивні сторони застосування каскадного підходу полягають в наступному :

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

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

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

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

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

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

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

Структурний підхід до проектування ІС

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


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

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

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

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

  • принцип абстрагування - полягає у виділенні істотних аспектів системи і відвернення від неістотних;

  • принцип формалізації - полягає в необхідності строгого методичного підходу до рішення проблеми;

  • принцип несуперечності - полягає в обгрунтованості і узгодженості елементів;

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

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

  • SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми;

  • DFD (Data Flow Diagrams) діаграми потоків даних;

  • ERD (Entity-Relationship Diagrams) діаграми "суть-зв'язок".


Література:

Томас Конноли, Каролин Бегг, Анна Страчан. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд. – М.: Издательский дом «Вильямс», 2000. [1], 963-980
Контрольні запитання:

  1. Яким особливостями характеризуються сучасні крупні проекти ІС?

  2. На яких групах процесів базується структура життєвого циклу ПО?

  3. Які найбільше поширення основні моделі життєвого циклу?

  4. Яки позитивні сторони застосування каскадного підходу при побудові ІС?

  5. Яки базові принципи методології структурного підходу?




Схожі:

Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconУрок № Тема
Типова архітектура персонального комп’ютера. Класифікація та призначення апаратних засобів: пристроїв введення, виведення, зберігання...
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconУрок №3. Тема
Принципи класифікації інформаційних систем. Інформаційні технології. Етапи розвитку інформаційних технологій. Сфери застосування...
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconЛекція №2 Тема: Системи бд, архітектура бд, адміністратор бд
Визначення Адміністратором даних (АД) назвемо співробітника, несучого відповідальність за дані підприємства
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconТема. Архітектура
Архітектура – мистецтво проектування та будування різних будівель, споруд та їх комплексів
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconЛекція №21 Тема: Специфіка розробки інтегрованих інформаційних систем
Методології, технології І інструментальні засоби проектування (case-засоби) складають основу проекту будь-який іс. Методологія реалізується...
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconУрок №7. Тема
Тема: Підсумковий урок з тем «Інформація. Інформаційні процеси та системи», «Апаратне забезпечення інформаційних систем»
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconРоботи по обслуговуванню інформаційних систем та систем бухгалтерського обліку

Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconУрок №22 Тема: Призначення, можливості І класифікація систем обробки...
Дидактична: доповнити та узагальнити знання учнів про призначення, основні можливості систем обробки текстів; ознайомити з середовищем...
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація iconІнформатика (усна форма)
Опишіть інформаційні системи та технології. Охарактеризуйте види інформаційних систем їх апаратне та програмне забезпечення. Назвіть...
Лекція №20 Тема: Типова архітектура інформаційних систем, їх класифікація icon2 до листа Міністерства освіти І
Опишіть інформаційні системи та технології. Охарактеризуйте види інформаційних систем їх апаратне та програмне забезпечення. Назвіть...
Додайте кнопку на своєму сайті:
Школьные материалы


База даних захищена авторським правом © 2014
звернутися до адміністрації
uchni.com.ua
Головна сторінка