Категории: ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника |
Профіль інструментальних засобівПрофіль інструментальних засобів, вбудованих в інформаційну систему, повинен відбивати рішення по вибору методології і технології створення, супроводу і розвитку інформаційної системи. У цьому профілі повинні знаходитися посилання на опис вибраної методології і технології, виконане на стадії ескізного проектування системи. Склад інструментальних засобів визначається на підставі рішень і нормативних документів про організацію супроводу і розвитку інформаційної системи. При цьому мають бути враховані правила і порядок, що регламентують внесення змін до діючих систем. Функціональна область профілю інструментальних засобів, вбудованих в систему, охоплює функції централізованого управління і адміністрування, пов'язані з, : · контролем продуктивності і коректності функціонування системи в цілому; · управлінням конфігурацією прикладного програмного забезпечення, тиражуванням версій; · управлінням доступом користувачів до ресурсів системи і конфігурацією ресурсів; · перенастроюванням застосувань у зв'язку із змінами прикладних функцій інформаційної системи; · налаштуванням призначених для користувача інтерфейсів (генерацією екранних форм і звітів); · веденням баз даних системи; · відновленням працездатності системи після збоїв і аварій. Додаткові ресурси, необхідні для функціонування вбудованих інструментальних засобів, такі як мінімальний і рекомендований об'єм оперативної пам'яті, розміри необхідного дискового простору і тому подібне, мають бути врахований в розділі проекту, що відноситься до середовища інформаційної системи. Вибирання інструментальних засобів, вбудованих в систему, повинне проводитися відповідно до вимог профілю середовища. Посилання на відповідні стандарти, що входять в профіль середовища, повинні міститися і в профілі інструментальних засобів. У цьому профілі повинні також знаходитися посилання на вимоги до засобів тестування, які потрібні для процесів супроводу і розвитку системи і мають бути в неї вбудовані. До числа вбудованих в інформаційну систему засобів тестування повинні входити засоби функціонального тестування застосувань, тестування інтерфейсів, системного тестування і тестування серверів/клієнтів при максимальному навантаженні.
Лекція 15 Фази життєвого циклу у рамках методології RAD При використанні методології швидкої розробки застосувань життєвий цикл інформаційної системи складається з чотирьох фаз: · фаза аналізу і планування вимог; · фаза проектування; · фаза побудови; · фаза впровадження. Розглянемо кожну з них детальніше.
Фаза аналізу і планування вимог. На цій фазі виконуються наступні роботи: · визначаються функції, які повинна виконувати інформаційна система, що розробляється ; · визначаються найбільш пріоритетні функції, що вимагають розробки в першу чергу; · проводиться опис інформаційних потреб; Примітка Визначення вказаних вище вимог виконується спільно майбутніми користувачами системи і розробниками. · обмежується масштаб проекту; · визначаються часові рамки для кожної з наступних фаз; · на закінчення, визначається сама можливість реалізації цього проекту у встановлених рамках фінансування, на наявних апаратних і про-граммных засобах. Якщо реалізація проекту принципово можлива, то результатом фази аналізу і планування вимог буде список функцій информаци-онной системи, що розробляється, з вказівкою їх пріоритетів і попередні функціональні і інформаційні моделі системи.
Фаза проектування На фазі проектування необхідним інструментом являються CASE -средства, використовувані для швидкого отримання працюючих прототипів застосувань. Примітка Термін CASE (Computer Aided Software/System Engineering) використовується в настоя-щее час в дуже широкому сенсі. Первинне значення терміну CASE огра-ничивалось лише питаннями автоматизації розробки програмного забезпечення. Проте надалі значення цього терміну розширилося і набуло нового сенсу, що охоплює процес розробки складних інформаційних систем в цілому. Те-перь під терміном - CASE - засоби" розуміються програмні засоби, поддер-живающие процеси створення і супроводу інформаційних систем, включаючи аналіз і формулювання вимог, проектування прикладного програмного забезпечення і баз даних, генерацію коду, тестування, документування, обес-печение якості, конфігураційне управління і управління проектом, а також інші процеси. Прототипи, створені за допомогою CASE -средств, аналізуються користувач-мі, які уточнюють і доповнюють ті вимоги до системи, які не були вы-явлены на попередній фазі. Таким чином, на цій фазі також потрібна участь майбутніх користувачів в технічному проектуванні системи. Примітка Для побудови усіх моделей і прототипів мають бути використані саме ті CASE -средства, які потім застосовуватимуться при побудові системи. Ця вимога пов'язана з тим, що при передачі інформації про проект з етапу на етап може статися фактично неконтрольоване спотворення даних. Застосування еди-ной середовища зберігання інформації про проект дозволяє уникнути цієї небезпеки. Далі на цій фазі проводиться аналіз і при необхідності коригування функціональної моделі системи. Детально розглядається кожен процес системи. При необхідності для кожного елементарного процесу створюється частковий про-тотип: екран, діалог або звіт (це дозволяє усунути неясності або неоднознач-ности). Потім визначаються вимоги розмежування доступу до даних. Після детального розгляду процесів визначається кількість функциональ-ных елементів системи, що розробляється. Це дозволяє розділити информаци-онную систему на ряд підсистем, кожна з яких реалізується однією командою розробників за прийнятне для RAD -проектов час (близько півтори меся-цев). З використанням CASE -средств проект розподіляється між різними командами - ділиться функціональна модель. На цій же фазі відбувається визначення набору необхідної документації. Результатами цієї фази є; · загальна інформаційна модель системи; · функціональні моделі системи в цілому і підсистем, що реалізовуються отдель-ными командами розробників; · точно визначені за допомогою CASE -средства інтерфейси між підсистемами, що автономно розробляються; · побудовані прототипи екранів, діалогів і звітів. Примітка Однією з особливостей застосування методології RAD на цій фазі є те, що кожен створений прототип розвивається в частину майбутньої системи. Таким чином, на наступну фазу передається повніша і корисніша інформація. (При традиційному підході використовувалися засоби прототипирования, не призначені для побудови реальних застосувань, тому розроблені прототипи не могли бути використані на наступних фазах і просто "викидалися" після того, як виконували завдання усунення неясностей в проекті.)
Фаза побудови На фазі побудови виконується власне швидка розробка застосування. На цій фазі розробники проводять ітеративну побудову реальної системи на основі отриманих раніше моделей, а також вимог нефункціонального характеру. Розробка застосування ведеться з використанням візуальних засобів програмування. Формування програмного коду частково виконується за допомогою автоматичних генераторів коду, що входять до складу CASE -средств. Код генерується на основі розроблених моделей. На фазі побудови також вимагається участь користувачів системи, які оце-нивают отримувані результати і вносять корективи, якщо в процесі розробки система перестає задовольняти визначеним раніше вимогам. Тестирова-ние системи здійснюється безпосередньо в процесі розробки. Після закінчення робіт кожної окремої команди розробників проводиться поступова інтеграція цієї частини системи з іншими, формується пол-ный програмний код, виконується тестування спільної роботи даною ча-сти застосування з іншими, а потім тестування системи в цілому. Завершується фізичне проектування системи, а саме: · визначається необхідність розподілу даних; · проводиться аналіз використання даних; · проводиться фізичне проектування бази даних; · визначаються вимоги до апаратних ресурсів; · визначаються способи збільшення продуктивності; · завершується розробка документації проекту. Результатом цієї фази є готова інформаційна система, що задовольняє усім вимогам користувачів.
Фаза впровадження Фаза впровадження в основному зводиться до навчання користувачів розробленої інформаційної системи. Оскільки фаза побудови досить нетривала, планування і подготов-ка до впровадження повинні починатися заздалегідь, ще на етапі проектування системи.
Примітка Приведена схема розробки інформаційної системи не являється универсаль-ной. Цілком можливі різні відхилення від неї. Це пов'язано із залежністю схеми виконання проекту від початкових умов, при яких починається разработ-ка (наприклад, розробляється абсолютно нова система або на підприємстві вже існує деяка інформаційна система). У другому випадку існуюча система може або використовуватися як прототип нової системи, або ин-тегрироваться в нову розробку як одна з підсистем.
Обмеження методології RAD Незважаючи на усі свої достоїнства, методологія RAD проте (як, втім, і будь-яка інша методологія) не може претендувати на універсальність. Її при-менение найефективніше при виконанні порівняно невеликих систем, що розробляються для цілком певного підприємства. При розробці ж типових систем, що не є закінченим продуктом, а типових елементів інформаційної системи, що є сукупністю, велике значення мають такі показники проекту, як керованість і якість, які можуть увійти до протиріччя з простотою і швидкістю розробки. Це пов'язано з тим, що типові системи зазвичай централізований супроводжується і може бути адаптовані до різних програмно-апаратних платформ, систем управління базами даних, комунікаційних засобів, а також інтегруватися з існуючими розробками. Тому для такого роду проектів потрібний високий рівень планування і жорстка дисципліна проектування, строге наслідування заздалегідь розроблених протоколів і інтерфейсів, що знижує швидкість розробки. Методологія RAD непридатна не лише для створення типових информацион-ных систем, але і для побудови складних розрахункових програм, операційних систем або програм управління складними інженерно-технічними об'єкт-мі програм, що вимагають написання великого об'єму унікального коду. Методологія RAD не може бути використана для розробки застосувань, в ко-торых інтерфейс користувача є вторинним, тобто відсутнє нагляд-ное визначення логіки роботи системи. Прикладами таких застосувань можуть служити застосування реального часу, драйвери або служби. Абсолютно неприйнятна методологія RAD для розробки систем, від яких залежить безпека людей, - наприклад, систем управління транспортом або атомних електростанцій. Це обумовлено тим, що ітеративний підхід, що є однією з основ RAD, припускає, що перші версії системи не будуть повністю працездатні, що в даному випадку може привести до серйозних катастроф.
Лекція 16 Стандарти і методики Однією з важливих умов ефективного використання інформаційних тех-нологий є впровадження корпоративних стандартів. Корпоративними стандартами є угода про єдині правила організації технології або управління. При цьому за основу корпоративних можуть прийматися галузеве, національні і навіть міжнародні стандарти. Проте висока динаміка розвитку інформаційних технологій призводить до быс-трому застарівання існуючих стандартів і методик розробки информаци-онных систем. Так, наприклад, у зв'язку зі значним прогресом в області програмного забезпечення і засобів обчислювальної техніки спостерігається зростання розмірів і складності інформаційних систем. При цьому істотно міняються вимоги як до основних функцій і сервісних можливостей систем, так і до динаміки зміни цих функцій. У цих умовах застосування классиче-ских способів розробки і забезпечення якості інформаційних систем ставати малоефективним і не призводить до рівня якості, адекватного реальним вимогам. Корисні в цьому відношенні стандарти відкритих систем (в першу чергу стандарти на інтерфейси різних видів, включаючи лінгвістичні, і на протоколи взаємодії). Проте розробка систем в нових умовах вимагає також нових методів проектування і нової організації проектних робіт. Проектування і методична підтримка організації розробки інформаційних систем (включаючи програмне забезпечення (ПЗ), і бази даних (БД)) традици-онно підтримуються багатьма стандартами і фірмовими методиками. В той же час відомо, що вимагається адаптивне планування розробки, у тому числі в динаміці процесу її виконання. Одним із способів адаптивного проектирова-ния є розробка і застосування профілів життєвого циклу інформаційних систем і програмного забезпечення. Корпоративні стандарти утворюють цілісну систему, яка включає три види стандартів, : · стандарти на продукти і послуги; · стандарти на процеси і технології; · стандарти на форми колективної діяльності, або управлінські стандарти.
Види стандартів Існуючі на сьогодні стандарти можна декілька умовно разде-лить на декілька груп за наступними ознаками: · по предмету стандартизації. До цієї групи можна віднести функціональні стандарти (стандарти на мови програмування, інтерфейси, протоколи) і стандарти на організацію життєвого циклу створення і використання ин-формационных систем і програмного забезпечення; · по стверджуючій організації. Тут можна виділити офіційні міжнародні, офіційні національні або національні відомчі стандар-ты (наприклад, Госты, ANSI, IDEFO/i), стандарти міжнародних консорциу-мов і комітетів із стандартизації (наприклад, консорціуму OMG), стандарти "де-факто" - офіційно ніким не затверджені, але фактично діючі (наприклад, стандартом "де-факто" довгий час були мова взаємодії з реляційними базами даних SQL і мова програмування С), фірмові стандарти (наприклад, Microsoft ODBC); · по методичному джерелу. До цієї групи відносяться різного роду методичні матеріали провідних фірм-розробників програмного забезпечення, фірм-консультантів, наукових центрів, консорціумів по стандартизації. Примітка Необхідно мати на увазі, що, хоча це і не очевидно, в кожну з вказаних вище груп і підгруп входять стандарти, що істотно розрізняються по мірі обов'язковості для різних організацій; конкретності і деталізації вимог, що містяться; відкритості і гнучкості, а також адаптується до конкретних умов. Нижче ми розглянемо наступні стандарти і методики, що стосуються організації життєвого циклу інформаційних систем і програмного забезпечення : · методика Oracle CDM (Custom Development Method) no розробці прикладних інформаційних систем під замовлення; · міжнародний стандарт ISO/IEC 12207:1995- 08-01 на організацію життєвого циклу продуктів програмного забезпечення; · вітчизняний комплекс стандартів ГОСТ 34. Оскільки дані стандарти є дуже об'ємними документами, викладеними на десятках і навіть сотнях сторінок, то ми розглянемо їх лише на рівні загальної структури і основних особливостей.
Методика Oracle CDM Одним з напрямів діяльності фірми ORACLE, що вже склалися, стала розробка методологічних основ і виробництво інструментальних засобів для автоматизації процесів розробки складних прикладних систем, ориентирован-ных на інтенсивне використання баз даних. Методика Oracle CDM є розвитком давно розробленої версії Oracle CASE - Method, вживаною в CASE -средстве Oracle CASE (у нових версіях - Designer/2000). Основу CASE -технологии і інструментального середовища фірми ORACLE складають: · методологія структурного низхідного проектування, при якій розробка прикладної системи представляється у вигляді послідовності чітко певних етапів; · підтримка усіх етапів життєвого циклу прикладної системи, починаючи з найзагальніших описів предметної області до отримання і супроводу готового програмного продукту; · орієнтація на реалізацію застосувань в архітектурі клієнт-сервер з використанням усіх особливостей сучасних серверів баз даних, включаючи декларативні обмеження цілісності, процедури, що зберігаються, тригери баз дан-ных, і з підтримкою в клієнтській частині усіх сучасних стандартів і вимог до графічного інтерфейсу кінцевого користувача; · наявність централізованої бази даних, репозитария, для зберігання специфікацій проекту прикладної системи на усіх етапах її розробки. Такий репозитарий є базою даних спеціальної структури, СУБД ORACLE, що працює під управлінням; · можливість одночасної роботи з репозитарием багатьох користувачів. Такий розрахований на багато користувачів режим майже автоматично забезпечується стандартними засобами СУБД ORACLE. Централізоване зберігання проекту системи і управління одночасним доступом до нього усіх учасників розробки підтримують узгодженість дій розробників і не допускають ситуацію, коли кожен проектувальник або програміст працює зі своєю версією проекту і модифікує її незалежно від дру-гих; · автоматизація послідовного переходу від одного етапу розробки до наступного. Для цього передбачені спеціальні утиліти, за допомогою кото-рых можна по специфікаціях концептуального рівня (моделі предметної області) автоматично отримувати первинний варіант специфікації рівня проектування (опис структури бази даних і складу про-граммных модулів, щоб на його основі після усіх необхідних уточнень і доповнень автоматично генерувати готові до виконання про-граммы; · автоматизація різних стандартних дій з проектування і реалізації застосування : передбачається генерація численних звітів по вмісту репозитария, що забезпечують повне документування поточної версії системи на усіх етапах її розробки; за допомогою спеціальних про-цедур надається можливість перевірки специфікацій на повноту і несуперечність.
Загальна структура Життєвий цикл формується з певних етапів (фаз) проекту і процес-сов, кожен з яких виконується протягом декількох етапів, Методика Oracle CDM визначає наступні фази життєвого циклу информа-ционной системи : · стратегія (визначення вимог); · аналіз (формулювання детальних вимог до прикладної системи); · проектування (перетворення вимог в детальні специфікації сис-темы); · реалізація (написання і тестування застосувань); · впровадження (установка нової прикладної системи, підготовка на початок эксплуа-тации); · експлуатація (підтримка застосування і стеження за ним, планування буду-щих функціональних розширень). Перший етап пов'язаний з моделюванням і аналізом процесів, що описують дея-тельность організації, технологічні особливості роботи. Метою є по-строение моделей існуючих процесів, виявлення їх недоліків і возмож-ных джерел удосконалення. Цей етап не є обов'язковим у разі, коли існуюча технологія і організаційні структури чітко визначені, добре зрозумілі і не вимагають додаткового вивчення і реорганізації. На другому етапі розробляються детальні концептуальні моделі предметної області, що описують інформаційні потреби організації, особливості функціонування і тому подібне. Результатом є моделі двох типів : · інформаційні, відбиваючі структуру і загальні закономірності предметної області; · функціональні особливості вирішуваних завдань, що описують. На третій стадії (етапі проектування) на підставі концептуальних моделей виробляються технічні специфікації майбутньої прикладної системи - визначаються структура і склад бази даних, специфікується набір программ-ных модулів. Первинний варіант проектних специфікацій може бути отриманий автоматично за допомогою спеціальних утиліт па основі даних кон-цептуальных моделей. На етапі реалізації створюються програми, що відповідають усім вимогам проект-ных специфікацій. Примітка Використання генераторів застосувань, що входять до складу DESIGNER/2000, позво-ляет повністю автоматизувати цей етап, істотно скоротити терміни розробки системи і підвищити її якість і надійність. Методика Oracle CDM виділяє наступні процеси, що протікають на протяже-нии життєвого циклу інформаційної системи; · визначення виробничих вимог; · дослідження існуючих систем; · визначення технічної архітектури; · проектування і побудова бази даних; · проектування і реалізація модулів; · конвертація даних; · документування; · тестування; · навчання; · перехід до нової системи; · підтримка і супровід. Процеси складаються з послідовностей завдань, завдання різних процесів взаи-мосвязаны за допомогою явних посилань.
|
|
Последнее изменение этой страницы: 2016-06-09 lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда... |