21295

Мета та завдання дисципліни

Лекция

Информатика, кибернетика и программирование

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

Украинкский

2013-08-02

88.5 KB

1 чел.

Лекція 1. Мета та завдання дисципліни

Введення в предметну область

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

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

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

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

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

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

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

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

  Перераховані фактори сприяли появі програмно-технологічних засобів спеціального класу - CASE-засобів, що реалізують CASE-технологію моделювання та проектування ІС. Термін CASE (Computer Aided Software Engineering [КОМП'ЮТЕР ЕЙДІД СОФТВЕА Інженіринг] - програмна інженерія з комп'ютерною підтримкою) використовується в даний час у дуже широкому сенсі. Первинне значення терміна CASE, обмежене питаннями автоматизації розробки тільки лише програмного забезпечення (ПО), в даний час набуло нового змісту, що охоплює процес розробки складних ІС у цілому. Тепер під терміном CASE-засоби розуміються програмні засоби, що підтримують процеси створення і супроводу ІС, включаючи аналіз і формулювання вимог, моделювання прикладного ПЗ (додатків) і баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. CASE-засоби разом із системним ПЗ і технічними засобами утворюють повну середовище розробки ІС.

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

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

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

  Успішне впровадження CASE-засобів повинно забезпечити такі вигоди як:

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

Поняття моделі та моделювання

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

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

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

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

  Проблема моделювання складається з трьох завдань:

  •  побудова моделі;
  •  дослідження моделі;
  •  використання моделі.

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

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

  Як правило модель включає в себе: об'єкт О, суб'єкт (не обов'язковий) А, завдання Z, ресурси B, середу моделювання С.

  Модель можна уявити формально у вигляді: М = < O, Z, A, B, C >.

  Основні властивості будь-якої моделі:

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

  У загальному випадку весь процес побудови моделі зводиться до наступних кроків:

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

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

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

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

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

Особливості та проблеми проектування складних інформаційних систем

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

  До теперішнього часу створення таких систем нерідко виконувалося на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ПЗ. За даними Інституту програмна інженерія (США) до 2000 року близько 80% всього експлуатованого програмного забезпечення розроблялося взагалі без використання будь-яких дисципліни проектування, методом «code and fix» [КОД ЕНД ФІКС] (кодування і виправлення помилок).

  Проблеми розробки складних програмних комплексів випливають з його властивостей. Ще в 1975 р. Фредерік Брукс (найвідоміший американський вчений у галузі теорії обчислювальних систем), проаналізувавши свій унікальний на ті часи досвід керівництва найбільшим проектом розробки операційної системи OS/360 для компанії IBM, визначив перелік невід'ємних властивостей ПЗ: складність, узгодженість, змінність і незрима.

  Що ж стосується сучасних великомасштабних проектів ПЗ, то вони характеризуються, як правило, наступними особливостями:

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

  Наприкінці 60-х років минулого століття в США було відмічено явище під назвою «software crisis» [СОФВЕА КРИЗА] (криза програмного забезпечення). Це виражалося в тому, що великі проекти стали виконуватися з відставанням від графіка або з перевищенням кошторису витрат, розроблений продукт не володів необхідними функціональними можливостями, продуктивність його була низька, якість одержуваного програмного забезпечення не влаштовувало споживачів.

  Аналітичні дослідження та огляди, що виконуються протягом ряду останніх років провідними зарубіжними аналітиками, показували не дуже обнадійливі результати. Так, наприклад, результати досліджень, виконаних у 2007 році компанією Standish Group, яка проаналізувала роботу 364 американських корпорацій та підсумки виконання понад 23 тисяч проектів, пов'язаних з розробкою ПЗ, виглядали наступним чином:

  •  тільки 16,2% завершилися в термін, не перевищили запланований бюджет і реалізували всі необхідні функції і можливості;
  •  52,7% проектів завершилися з запізненням, витрати перевищили запланований бюджет, необхідні функції не були реалізовані у повному обсязі;
  •  31,1% проектів були анульовані до завершення;
  •  для двох останніх категорій проектів бюджет середнього проекту виявився перевищеним на 89%, а термін виконання - на 122%.

  У 2008 році процентне співвідношення трьох перерахованих категорій проектів лише трохи змінилося в кращу сторону (26%, 46% і 28% відповідно).

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

  У числі основних причин можливих невдач, на думку аналітиків, фігурують:

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

  Об'єктивна потреба контролювати процес розробки складних інформаційних систем, прогнозувати і гарантувати вартість розробки, терміни і якість результатів привела в кінці 60-х років минулого століття до необхідності переходу від кустарних до індустріальних способів створення ПЗ і появі сукупності інженерних методів і засобів створення ПЗ, об'єднаних спільним назвою «програмна інженерія» (software engineering).

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

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

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

82341. Понимание невербальной эмоциональной экспрессии младшими подростками 389.5 KB
  Работая в этих областях отечественные психологи-практики столкнулись с фундаментальной ошибкой сформировавшейся в результате полного игнорирования тех идей психологии невербального общения которые имели отношения к вечной проблеме взаимосвязи души и тела экспрессии и психологических особенностей человека.
82342. Разработка программы построения таблицы истинности логической функции 155 KB
  Истинность логических выражений помогает определить таблица истинности логических функций. С помощью таблиц истинности можно устанавливать эквивалентность выражений и справедливость равенств законов алгебры логики.
82343. ТЕОРЕТИЧНІ ОСНОВИ ФОРМУВАННЯ ФІНАНСОВОЇ СТРАТЕГІЇ РОЗВИТКУ ПІДПРИЄМСТВА 4.07 MB
  З метою подальшого розгляду процесу формування фінансової стратегії підприємства доцільно уточнити поняття фінансового розвитку підприємства стратегії та фінансової стратегії підприємства. В загальному під розвитком розуміють надбання нової якості яка зміцнює життєздатність підприємства в умовах змін середовища.
82344. Проект реконструкции участка диагностики автосервиса с целью увеличения количества обслуживаемых клиентов 1.31 MB
  Цель дипломного проекта заключается в реконструкции участка диагностики связанной с совершенствованием технологического процесса внедрением нового оборудования улучшением условий труда с целью увеличения количества обслуживаемых клиентов...
82345. Технология приготовления скомплектованного обеда из трех блюд 2.6 MB
  Неотъемлемой частью культуры каждого народа является кухня. Недаром этнографы начинают исследование жизни любого народа с изучения его кухни, ибо в ней в концентрированном виде отражается история, быт и нравы народа. Русская кухня в этом смысле не исключение, она так же является частью нашей культуры, нашей истории.
82346. Манипулятивный потенциал бренда в рекламной коммуникации (на примере деятельности LTD IKEA) 470 KB
  Актуальность темы данного дипломного проекта заключается в том, что для успешного развития бизнеса необходимо понимать изменение в массовой психологии восприятия, а так же уметь использовать этот фактор. В современном обществе, перенасыщенном информацией, становится все сложнее донести сообщение до потенциального...
82347. Специфика психолого-педагогической диагностики детей 5-7 лет с нарушениями зрения в условиях ПМПК 370.5 KB
  В этом возрасте к ребенку уже предъявляется система внешне нормированных требований, как к социальному индивиду. В данном случае речь идет о социально-психологическом аспекте адаптации, которая служит, с одной стороны, довольно точным индикатором различных дефицитов и отклонений в развитии...
82348. Совершенствование кадровой политики ООО «Колинз Ритейл» 1.26 MB
  Для сферы управления персоналом характерно наличие специфического понятийного аппарата отличительных характеристик и показателей деятельности специальных процедур и методов – аттестации эксперимента и других; методов изучения и направления анализа содержания труда различных категорий персонала.
82349. Содержание и психологическая характеристика представлений гагаузских первоклассников о России 574.18 KB
  Представления накладывают отпечаток на весь процесс психического развития. Так немецкий психолог Вильям Штерн определял представления детей 6–лет как конгломерат впечатлений в котором смешиваются объективные и аффективные моменты опыта ребёнка указывал что образ возникающий при взаимодействии ребёнка...