загрузка...
загрузка...
На головну

Технологія швидкої розробки додатків RAD

  1. CASE-технологія створення інформаційних систем
  2. CASE-технологія створення інформаційних систем.
  3. I. Завдання семіотики і передумови, необхідні для її розробки
  4. I. Технологія організованого спілкування школярів.
  5. Алгоритм розробки стратегії
  6. Базові принципи розробки інформаційних технологій
  7. Введення і форматування даних. технологія роботи

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

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

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

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

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

1. Аналізу та планування вимог;

2. Проектування;

3. Побудови;

4. Запровадження.

 
 


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

Результатом фази повинні бути: список розставлених по пріоритету функцій майбутньої ПС; попередня функціональна модель ПС; попередня інформаційна модель ПС.

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

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

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

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

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

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

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

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

На закінчення перелічимо основні принципи технології RAD:

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

O необов'язковість повного завершення робіт на кожному етапі ЖЦ;

O обов'язкове залучення користувачів на етапі розробки;

O використання прототипування, що дозволяє з'ясувати і задовольнити всі вимоги кінцевого користувача;

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

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


Контрольні запитання до розділу 3:

1. Що таке стандартизація і сертифікація програмного продукту?

2. Які існують типи стандартів?

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

4. Що таке життєвий цикл ПО?

5. Перерахуйте основні етапи життєвого циклу ПЗ. Що таке процес, дію, завдання?

6. Які типи процесів і конкретні процеси ви запам'ятали?

7. Розкажіть про основні інженерних процесах життєвого циклу ПО.

8. Що таке модель життєвого циклу ПО? Дайте визначення основних понять, пов'язані з поняттям «модель».

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

10. що ви можете сказати про особливості каскадної моделі життєвого циклу?

11. в чому відмінність узагальненої каскадної моделі від базової?

12. що ви можете сказати про особливості спіральної моделі життєвого циклу?

13. перерахуйте складові технології RAD. Для розробки яких типів ПО можна застосовувати технологію RAD?

14. опишіть основні фази життєвого циклу за технологією RAD.

15. перерахуйте основні принципи технології RAD.


СПИСОК ЛІТЕРАТУРИ

1. Аптекар М. Д., Рамазанов С. К., Фрегер Г. Е. Історія інженерної діяльності. - Київ, 2003. - 204 с. : Ил.

2. Арчибальд Р. Моделі життєвого циклу високотехнологічних проектів. http://www.pmprofy.ru/content/rus/107/1073-article.html

3. Брукс Ф. Міфічний людино-місяць або як створюються програмні системи. - СПб. : Символ-плюс, 1999. - 321 с. : Ил.

4. Буч Г. Об'єктно-орієнтоване проектування з прикладами застосування. - М .: Конкорд, 1992. - 586с. : Ил.

5. Буч Г. Об'єктно-орієнтований аналіз і об'єктно-орієнтоване проектування на С ++. - М.: Біном, - 2001. - 558 с. : Ил.

6. Вендров А. М. CASE-технології. Сучасні методи і коштів проектування інформаційних систем. - М.: Фінанси і статистика, - 1999. - 256 с. : Ил.

7. Вірт Н. Алгоритми + структури даних = програми: Пер. з англ. - М.: Мир, 1985. - 406 с .: іл.

8. Дав О., Дейкстра Е., Хоор К. Структурний програмування: Пер. з англ. - М .: Світ, 1975. - 247 с. : Ил.

9. Дзержинський Ф. Я., Калиниченко І. м. Дисципліна програмування: концепція і досвід реалізації методичних засобів програмної інженерії. - М .: ЦНДІ інформації і техніко-економічних досліджень з атомної науки і техніки, 1988. - 245 с. : Ил.

10. Жоголєв Е. А. Технології програмування. - М.: Науковий світ, 2004. - 216 с. : Ил.

11. Закон РФ № 149-ФЗ від 29.07.2006. «Про інформацію, інформаційні технології та захист інформації» // Російська газета, № 165 від 27.07.2006 р

12. Іванова Г. С. Технологія програмування: Підручник для вузів. - 2-е изд., Стереотип. - М.: Изд-во МГТУ ім. Н. е. баумана, 2003. - 320 с .: іл.

13. Калянов Г. Н. CASE: Структурний системний аналіз (автоматизація і застосування). - М.: «Лорі», 1996. - 356 с. : Ил.

14. Кораблін М. А. Програмування, орієнтоване на об'єкти: Навчальний посібник. - Самара: вид-во СГАУ, 1994. - 94 с.

15. Леоненков А. В. Самовчитель UML. - СПб: ВХВ Петербург, - 2001. - 304 с. : Ил.

16. Липа В. В. Якість програмного забезпечення. - М .: Фінанси і статистика, 1983. - 263 с. : Ил.

17. Липа В. В. Налагодження складних програм: Методи, засоби, технологія. -М. : Вища школа, 1993. - 384 с. : Ил.

18. Липа В. В., Філіппов Е. М. Мобільність програм і даних у відкритих інформаційних системах. - М.: Наукова книга, 1997. - 297 с. : Ил.

19. Майерс Г. Надійність програмного забезпечення. - М.: Мир, 1980. - 375 с. : Ил.

20. Ожегов С. І. Словник російської мови. - М.: Мир і освіта, 2006. - одна тисячі триста двадцять вісім с.

21. Технологія проектування комплексів програм АСУ / В. В. Липа, Л. А. Серебровский, П. Г. Гаганов і ін .; Під ред. Ю. В. Афанасьєва, В. В. Ліпаева. - М.: Радио и связь, 1983. - 256 с. : Ил.

22. Хювенен Е., Сеппянен Й. Світ ЛИСП: Пер. з фін. У 2 т. Т.1: Введення в мову Лісп і функціональне программірованіе.- М.: Мир, 1990. - 447 с. : Ил.

23. Хювенен Е., Сеппянен Й. Світ ЛИСП: Пер. з фін. У 2 т. Т.2: Методи і системи программірованія.- М.: Мир, 1990. - 319 с. : Ил.

24. Boehm B. «A Spiral Model of Software Development and Enhancement», IEEE Computer, Vol. 21, No. 5, pp. 61-72, 1988.

25. Courtois P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.28 (6), p.596.

26. Criteria for Evaluation of Software. ISO TC97 / SC7 # 383.

27. Dijktra E. 1979. Programming Considered as a Human Activity. Classics in Software Engineering. New York, NY: Yourdon Press.

28. http://www.pmi.ru/glossary/.

29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.

30. Microsoft Corporation. Принципи проектування і розробки програмного забезпечення. Навчальний курс MCSD: Пер. з англ. - М .: Видавничо-торговий дім «Російська редакція», 2000. -608 с. : Ил.

31. Parnas D., Clements P., Weiss D. 1983. Enhancing Reusability with Information Hiding. Proceedings of the Workshop on Reusability in Programming. Stratford, CT: ITT Programming. p.241.

32. Rechtin E. October 1992. The Art of Systems Architecting. IEEE Spectrum, vol.29 (10), p.66.

33. Royce W.W. Managing the Development of Large Software Systems. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.

34. Shaw M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE Software vol.1 (4).

35. Simon H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press. - P.218.

36. Sommerville I. Software engineering. - Addison-Wesley Publishing Company, 1992. p.87.

37. Tesler L. August 1981. The Smalltalk Environment. Byte vol.6 (8), p.142.

38. Yonezawa A., Tokoro M. 1987. Objectt-Oriented Concurrent Programming. Cambridge, MA: The MIT Press.


список термінів

 Назва терміна  визначення
 російське  англійське
 абстракція  Abstraction  Істотні характеристики об'єкта, які відрізняють його від всіх інших об'єктів і чітко визначають його концептуальні межі для спостерігача
 алгоритм  Algorithm  Заздалегідь задана послідовність чітко визначених правил або команд для отримання рішення задачі за кінцеве число кроків
 алгоритмічна декомпозиція  Algorithmic decomposition  Процес поділу системи на частини, кожна з яких відображає етап загального процесу. Застосування структурного підходу до проектування призводить до алгоритмічної декомпозиції, яка фокусується на потоці управління в системі
 верифікація  Verification  Процес визначення того, чи відповідає поточний стан розробки, досягнуте на даному етапі, вимогам цього етапу
 дані  Data  Подання фактів і ідей в формалізованому вигляді, придатному для передачі і переробки в якомусь процесі
 Життєвий цикл програми  Software Lifetime Cycle  Безперервний процес, який починається з моменту прийняття рішення про необхідність створення програми і закінчується в момент її повного вилучення з експлуатації
 ієрархія  Hierarchy  Впорядкування абстракцій, розташування їх за рівнями. У термінах ієрархії «частина / ціле» об'єкт знаходиться на більш високому рівні абстракції, ніж інші, якщо він будується на основі цих об'єктів; в термінах ієрархії «загальне / приватне» високорівневі абстракції носять більш узагальнений характер, ніж низькорівневі
 інкапсуляція  Encapsulation  Об'єднання в класі даних (властивостей) і методів (Процедур обробки), приховування окремих деталей внутрішнього устрою класів від зовнішніх по відношенню до нього об'єктів або користувачів
 інформаційне середовище  Data medium  Сукупність носіїв даних, що використовуються при будь-якій обробці даних
 Носій даних  Матеріал з певними фізичними властивостями, який може використовуватися для зберігання даних (магнітні стрічка або диск, оптичний диск, папір для друку)
 інформація  Information  Сенс, який надається даними при їхньому уявленні
 Відомості про осіб, предмети, факти, події, явища і процеси незалежно від форми їх подання
 якість програми  Software quality  Сукупність рис і характеристик програмної системи, які впливають на її здатність задовольняти задані потреби користувачів
 клас  Class  Безліч об'єктів, що володіють внутрішніми (іманентними) властивостями, які грають роль классообразующіх ознак і при будь-якому об'єкту класу
 Методологія програмування  Methodology of programming  Сукупність механізмів, що застосовуються в процесі розробки програмного забезпечення та об'єднаних одним загальним філософським підходом
 Модель  Model  Абстракція, яка служить для спрощення або подання будь-якої концепції або процесу
 Модель життєвого циклу  Life cycle model  Описується набір фаз (етапів, стадій) проекту по створенню продукту, в яких виконуються окремі процеси, розбиті на операції і завдання
 модуль  Module  Одиниця коду, що служить будівельним блоком фізичної структури системи; програмний блок, який містить оголошення, виражені відповідно до вимог мови і утворюють фізичну реалізацію частини або всіх класів і об'єктів логічного проекту системи (складається з інтерфейсної частини і реалізації)
 модульне програмування  Modular programming  Організація програми у вигляді сукупності модулів із суворим дотриманням правил їх взаємодії
 надійність  Reliability  Здатність системи програмного забезпечення виконувати покладені на неї функції при надходженні вимог на їх виконання
 спадкування  Inheritance  Можливість виведення нового класу зі старого з частковою зміною властивостей і методів
 Відношення між класами, при якому клас використовує структуру або поведінку іншого (одиночне спадкоємство) або інших (множинне успадкування) класів. Спадкування вводить ієрархію «загальне / приватне», в якій підклас успадковує від одного або декількох більш загальних суперкласів. Підкласи зазвичай доповнюють або скасовують успадковану структуру і поведінку
 Обробка даних  Data processing  Виконання систематичної послідовності дій з даними, які представляються і зберігаються на так званих носіях даних
 об'єктна модель  Object model  Сукупність основоположних принципів, що лежать в основі об'єктно-орієнтованого проектування; парадигма програмування, заснована на принципах абстрагування, інкапсуляції, модульності, ієрархічності, типізації, паралелізму та стійкості
 об'єктне програмування  Object-based programming  Метод програмування, заснований на представленні програми як сукупності об'єктів, кожен з яких є екземпляром деякого типу. Типи утворюють ієрархію, але не спадкову. У програмах типи розглядаються як статичні, а об'єкти мають більш динамічну природу, яку обмежують статичну зв'язування і мономорфизм
 Об'єктно-орієнтована декомпозиція  Object-oriented decomposition  Процес розбиття системи на частини, відповідні класам і об'єктам предметної області. Світ розглядається як сукупність об'єктів, узгоджено діючих для забезпечення необхідного поводження
 Об'єктно-орієнтоване програмування  Object-oriented programming  Методологія реалізації, при якій програма організується, як сукупність об'єктів, кожен з яких є екземпляром будь-якого класу, а класи утворюють ієрархію спадкування. При цьому класи зазвичай статичні, а об'єкти дуже динамічні, що «заохочується» динамічним зв'язуванням і поліморфізмом
 Об'єктно-орієнтоване проектування  Object-oriented design  Методологія проектування, що з'єднує процес об'єктно-орієнтованої декомпозиції і систему позначень для представлення логічної і фізичної, статичної та динамічної моделей проектованої системи. Система позначень складається з діаграм класів, об'єктів, модулів і процесів
 парадигма програмування  Paradigm  Нова модель конструювання програми та взаємодії її з даними
 поліморфізм  Polymorphism  Визначення властивостей і методів об'єкта по контексту (має на увазі відділення ідеї «що робити» від її втілення всередині ієрархії класу об'єктів «як робити»)
 Положення теорії типів, згідно з яким імена (наприклад, змінних) можуть позначати об'єкти різних (але мають загального батька) класів. Отже, будь-який об'єкт, що позначається поліморфним ім'ям, може по-своєму реагувати на якийсь загальний набір операцій
 Предметна область  Application domain  Частина реального світу, яка має суттєве значення або безпосереднє відношення до процесу функціонування програми, вона включає в себе тільки ті об'єкти і взаємозв'язки між ними, які необхідні для опису вимог і умов вирішення деякої задачі
 програма  Program  Набір операторів, який може бути представлений як єдине ціле в деякій обчислювальній системі і який використовується для управління поведінкою цієї системи.
 Програмування (в широкому сенсі)  Programming  Всі технічні операції, необхідні для створення програми, включаючи аналіз вимог і всі стадії розробки і реалізації
 Програмування (у вузькому сенсі)  Процес кодування і налагодження програми в рамках реального проекту
 Програмна інженерія  Software engineering  Систематичний підхід до розробки, експлуатації, супроводу і вилученню з обігу програмних засобів
 процес  Process  Набір взаємопов'язаних робіт, які перетворять вихідні дані у вихідні результати
 процес розробки  development process  Відповідно до стандарту передбачає дії і завдання, що виконуються розробником, і охоплює роботи зі створення ПЗ і його компонентів відповідно до створеними вимогами, включаючи оформлення проектної та експлуатаційної документації, а також підготовку матеріалів, необхідних для перевірки працездатності і відповідності якості програмних продуктів, матеріалів , необхідних для навчання персоналу, і т. д.
 сопровождаемость  Maintainability  Характеристики ПС, які дозволяють мінімізувати зусилля по внесенню змін до системи при усуненні в ній помилок і / або при її модифікації через мінливих потреб користувачів
 Середовище розробки  Framework  Набір класів, що надають деякі базові послуги в певній галузі. Таким чином, середовище розробки експортує класи і механізми, які клієнти можуть використовувати або адаптувати в своїх цілях
 стандарт  Standard  Нормативно-технічний документ, що затверджується компетентним органом, що встановлює комплекс норм, правил по відношенню до предмету стандартизації; типовий зразок, еталон, модель, що приймаються як вихідні для зіставлення з ними інших предметів
 структурне програмування  Structured programming  Методологія програмування, заснована на припущенні, що логічність і зрозумілість програм забезпечує її надійність, полегшує модифікацію і прискорює обробку
 структурний проектування  Structured design  Метод проектування, заснований на алгоритмічної декомпозиції
 технологія  Technology  Сукупність виробничих процесів у певній галузі виробництва, а також науковий опис способів виробництва, це сукупність технологічних елементів (засобів, пристроїв, методів, прийомів, документів), які використовуються для обробки вихідних матеріалів з метою отримання кінцевої продукції
 технологія програмування  Programming technology  Сукупність методів і засобів, що використовуються в процесі розробки програмних продуктів, являє собою набір технологічних інструкцій
 Уніфікована мова моделювання  Unified modeling language  Графічна мова для візуалізації, специфицирования, конструювання та документування програмних систем
 рівень абстракції  Level ofabstraction  Відносне впорядкування абстракцій по структурам класів, об'єктів, модулів або процесів
 ефективність  Efficiency  Ставлення рівня послуг, що надаються ПС користувачеві при заданих умовах, до обсягу використовуваних ресурсів (розрізняють ефективність за часом, по пам'яті, по устаткуванню)

навчальне видання

 




Л. С. Зеленко | Структурний підхід до розробки програмних систем | Об'єктний підхід до розробки програмних систем | інженерні процеси | Каскадна модель розробки ПЗ | Спіральна модель розробки ПЗ |

загрузка...
© um.co.ua - учбові матеріали та реферати