Смілянський промислово-економічний коледж 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Смілянський промислово-економічний коледж



СМІЛЯНСЬКИЙ ПРОМИСЛОВО-ЕКОНОМІЧНИЙ КОЛЕДЖ

Черкаського державного технологічного університету

Відділення Технічне

Циклова комісія Математичних дисциплін, інформатики та програмування

Освітньо-

кваліфікаційний рівень Молодший спеціаліст

Напрям підготовки 6.050101 «Комп’ютерні науки»

(шифр і назва)

Спеціальність 5.05010301 « Розробка програмного забезпечення »

(шифр і назва)

 


Смілянський промислово-економічний коледж ЧДТУ

(повне найменування вищого навчального закладу)

Відділення Технічне

Циклова комісія математичних дисциплін, інформатики та програмування

Освітньо-кваліфікаційний рівень Молодший спеціаліст

Спеціальність 5.05010301 «Розробка програмного забезпечення»

ЗАТВЕРДЖУЮ

Зав. технічним відділенням

_____________Осіпов В.В.

«__» _______201_ р

З А В Д А Н Н Я

НА ДИПЛОМНИЙ ПРОЕКТ СТУДЕНТУ

 

Гребенюку Івану Адрійовичу

 

1. Тема проекту: Автоматизована інформаційна система медичного центру

керівник проекту: Зборівська Валентина Петрівна,

(прізвище, ім’я, по батькові)

затверджені наказом вищого навчального закладу від “ 20квітня 20 16 року № 44

2. Строк подання студентом проекту: 13.06.2016

3. Вихідні дані до проекту Розробка специфікації; Проектування CASE –засобами: BP-win, ER-win, Rational Rose. Реалізація RAD-технології в середовищі С++ Builder 2006. Генерація схеми БД в Batch Access.

 

4. Зміст пояснювальної записки (перелік питань, які потрібно розробити)

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

5. Перелік додаткового матеріалу (з точним зазначенням обов’язкових діаграм)

Лістингпрограми; функціональна діяльність системи(IDEF0); діаграма потоків даних проектованої системи (DFD); діаграма використання; діаграма послідовності; діаграма класів системи; кооперативна діаграма системи; логічна модель БД системи; інтерфейс АІС.

6. Консультанти розділів проекту

Розділ Прізвище, ініціали та посада консультанта Підпис, дата
завдання видав завдання прийняв
1 – 4, 6 Зборівська В. П.    
  Кондратенко М. Г.    

7. Дата видачі завдання 20.04.16 _________________________________


КАЛЕНДАРНИЙ ПЛАН

№ з/п Назва етапів дипломного проекту Строк виконання етапів проекту  
  Системний аналіз    
  Архітектура програмного забезпечення    
  Детальне проектування    
  Реалізація    
  Економічна частина    
  Охорона праці    

Студент ___________ Гребенюк І. А. _

(підпис) (прізвище та ініціали)

 

Керівник проекту (роботи) ______________ Зборівська В. П.

(підпис) (прізвище та ініціали)

 

 


ЗМІСТ

 

ВСТУП.. 10

1 СИСТЕМНИЙ АНАЛІЗ. 12

1.1 Огляд предметної області 12

1.2 Специфікація. 13

2 АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ.. 23

2.1 Огляд технології розробки. 23

2.2 Архітектура потоків даних. 26

2.3 Варіанти використання системи. 31

3 ДЕТАЛЬНЕ ПРОЕКТУВАННЯ.. 36

3.1 Проектування інтерфейсу. 36

3.1.1 Поняття інтерфейсу. 36

3.1.2 Дослідження користувача. 39

3.1.3 Формування шаблонів форм програми. 41

3.2 Проектування бази даних. 46

3.2.1 Логічна структура БД.. 46

3.2.2 Генерація схеми БД.. 48

4 РЕАЛІЗАЦІЯ.. 51

4.1 Програмування і стиль. 51

4.2 Розробка інтерфейсу програми. 53

4.3 Реалізація модулів. 62

5 ЕКОНОМІЧНА ЧАСТИНА.. 69

5.1 Загальні положення. 69

5.2 Планування розробки інформаційної системи. 70

5.3 Визначення витрат на розробку програмного продукту. 71

5.3.1 Розрахунок основної заробітної плати. 71

5.3.2 Розрахунок додаткової заробітної плати. 72

5.3.3 Відрахування на соціальне страхування і в інші фонди. 72

5.3.4 Визначення витрат на матеріали та комплектуючі 73

5.3.5 Витрати на оплату машинного часу. 74

5.3.6 Накладні витрати. 78

5.4 Визначення ціни програмного продукту. 78

5.5 Висновок економічної частини. 79

6 ОХОРОНА ПРАЦІ 80

6.1 Вступ. 80

6.2 Конструювання робочого місця оператора. 81

6.3 Реалізація ергономічної оцінки робочого місця оператора. 82

6.4 Розташування робочого місця оператора в приміщенні 84

6.5 Вимоги до робочого місця. 85

6.5.1 Вимоги до мікроклімату та змісту шкідливих хімічних речовин у повітрі помешкань експлуатації моніторів і ЕОМ.. 85

6.5.2 Вимоги до організації медичного обслуговування. 87

ВИСНОВОК.. 88

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

ДОДАТОК А.. 95

ДОДАТОК Б.. 105

ДОДАТОК В.. 115

 


АНОТАЦІЯ

Дипломного проекту

 

Тема: Автоматизована інформаційна система медичного центру

Автор: Гребенюк Іван Андрійович

 

Короткий зміст

 

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

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

Для повноцінної працездатності системи, на персональних комп’ютерах повинно бути встановлено програмний додаток Microsoft Access та операційна система Windows (XP / Vista / 7 / 8 / 8.1 / 10).

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

Розроблене програмне забезпечення повинно формувати звіти по заданим фільтрам користувача або без фільтрів(на розсуд користувача).

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

 

 

Дата ___________ Підпис автора ________


Annotation

Thesis project

 

theme: Automated Information System Medical Center

Author: Grebenyuk Ivan Andriyovich

Short content

 

In this paper creates automated information systems for the medical center. The system is designed to facilitate (automation) control keeping of information by employees and reporting on the basis of the information received.

The system is operated on PCs these employees: chief doctor, nurse and accountant Medical Center.

For full system performance, the PCs must be installed Microsoft Access software application and operating system Windows (XP / Vista / 7/8 / 8.1 / 10).

To prevent unauthorized access to the system other employees of the company, the system should include user identification window that provides a protection system.

The developed software has to generate reports on user specified filters or no filters (the user's discretion).

The introduction of AIS should allow to significantly increase the efficiency of staff by automating the control of information and formation on the basis of reports.

 

 

Date ___________ Signature author ________

 


ВСТУП

Виробництво програмного забезпечення (ПЗ) сьогодні - це найбільша галузь світової економіки, в якій зайнято більше семи мільйонів фахівців. Саме приголомшливий прогрес в області ПЗ допоміг впоратися з інформаційним бумом кінця 20 століття.

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

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

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

Головною метою створення програмного продукту для медичного діагностичного центру «Medical© control» – є спрощення(автоматизація) діяльності по веденню інформації, обрахування грошових розрахунків, створення звітів.

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

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

Дана система зможе забезпечити:

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

· Друк звітів по потрібній для користувача інформації;

· Надасть інформацію для користувача по управлінню та контролю програмного додатку «Medical© control»;

Результатом проектування є програмний додаток для медичного діагностичного центру «Medical© control», який автоматизує процес ведення та обробки інформації для користувача.


СИСТЕМНИЙ АНАЛІЗ

Огляд предметної області

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

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

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

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

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

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

В сучасному світі АІС повинна відповідати наступним вимогам:

· Інтуїтивне представлення програми(інтерфейс форм користувача);

· Своєчасне задоволення користувача інформацією;

· Надання користувачу змогу обчислювання інформації;

· Повинна містити довідку користування системою.

Головні принципи розробки і експлуатації автоматизованої системи медичного діагностичного центру є:

· Здійснення обробки інформації апаратно-програмними засобами персонального комп’ютера користувача;

· Зменшення трудомісткості обрахування та часу.

 

Специфікація

«Medical© control»

Вступ

Призначення, мета

Даний документ містить вимоги на розробку програмного продукту «Medical© control», які складаються із системних, функціональних і не функціональних вимог до даного продукту.

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

Загальний опис

Характеристики

2.2.1 Веде облік клієнтів.

2.2.2 Веде облік діагнозів клієнтів.

2.2.3 Виконує пошук.

2.1.4 Обчислює вартість за день.

2.1.5 Друкує звіти.

2.1.6 Виконує фільтрацію.

Користувачі

2.2.1 Старша медсестра.

2.2.2 Лікарі.

2.2.3 Головний лікар.

Середовище функціонування

Даний продукт працює на операційній системі Windows XP / Vista / 7 / 8 / 8.1 / 10.

Апаратна платформа(мінімальні технічні характеристики ПК, на якому система буде працювати):

· Intel® Atom™ Processor N570 (1M Cache, 1.66 GHz);

· RAM 128 Mb;

Для роботи з програмою підійде будь який принтер та монітор.

Програмна платформа(необхідні програмні засоби для функціонування системи):

· Microsoft Access 2003 / 2007 / 2010 / 2013;

Характеристики системи

Функціональні вимоги

3.1.1 Продукт повинен дозволяти вводити дані: Діагнози(Код діагнозу, термін, термін лікування), Клієнти(Код клієнта, діагноз, код лікаря, прізвище та ім’я, код паспорту, телефонний номер, місто проживання), Лікарі(Код лікаря, прізвище і ініціали, код паспорту, телефонний номер, місто проживання), Препарати(Код препарату, назва препарату, дата виготовлення, термін придатності), Квитанції(Код квитанції, код клієнта, всього до оплати, дата видачі, прізвище та ім’я клієнта, діагноз клієнта, код препарату);

3.1.2 Продукт повинен дозволяти виводити дані: Діагнози(Код діагнозу, термін, термін лікування), Клієнти(Код клієнта, діагноз, код лікаря, прізвище та ім’я, код паспорту, телефонний номер, місто проживання), Лікарі(Код лікаря, прізвище і ініціали, код паспорту, телефонний номер, місто проживання), Препарати(Код препарату, назва препарату, дата виготовлення, термін придатності), Квитанції(Код квитанції, код клієнта, всього до оплати, дата видачі, прізвище та ім’я клієнта, діагноз клієнта, код препарату);

3.1.3 Продукт повинен дозволяти видаляти дані: Діагнози(Код діагнозу, термін, термін лікування), Клієнти(Код клієнта, діагноз, код лікаря, прізвище та ім’я, код паспорту, телефонний номер, місто проживання), Лікарі(Код лікаря, прізвище і ініціали, код паспорту, телефонний номер, місто проживання), Препарати(Код препарату, назва препарату, дата виготовлення, термін придатності), Квитанції(Код квитанції, код клієнта, всього до оплати, дата видачі, прізвище та ім’я клієнта, діагноз клієнта, код препарату). По заданим полями таблиці: Діагнози(Код діагнозу, термін, термін лікування), Клієнти(Код клієнта, діагноз, код лікаря, прізвище та ім’я, код паспорту, телефонний номер, місто проживання), Лікарі(Код лікаря, прізвище і ініціали, код паспорту, телефонний номер, місто проживання), Препарати(Код препарату, назва препарату), Квитанції(Код квитанції, код клієнта, всього до оплати, прізвище та ім’я клієнта, діагноз клієнта, код препарату);

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

3.1.5 Продукт повинен дозволяти здійснювати редагування даних по полях деяких таблиць: Діагнози(Код діагнозу, термін, термін лікування), Клієнти(Код клієнта, діагноз, код лікаря, прізвище та ім’я, код паспорту, телефонний номер, місто проживання), Лікарі(Код лікаря, прізвище і ініціали, код паспорту, телефонний номер, місто проживання), Препарати(Код препарату, назва препарату, дата виготовлення, термін придатності), Квитанції(Код квитанції, код клієнта, всього до оплати, дата видачі, прізвище та ім’я клієнта, діагноз клієнта, код препарату);

3.1.6 Продукт повинен обчислювати прибуток за день на основі даних в таблиці Квитанції по полю «Всього до оплати»;

3.1.7 Продукт повинен обчислювати загальний прибуток по всім клієнтам по полю «Всього до оплати» таблиці «Квитанції»;

3.1.8 Продукт повинен дозволяти друкувати звіти усіх полів таблиць: Діагнози, Квитанції, Лікарі, Препарати, Клієнти.

Користувацькі інтерфейси

Інтерфейс системи складається з:

4.1.1 Головне меню.

4.1.2 Таблиця бази даних.

4.1.3 Вікна додавання та видалення даних.

4.1.4 Вікна пошуку даних.

4.1.5 Меню швидкого доступу.

Апаратні інтерфейси

4.2.1 Взаємодіє з принтером.

Не функціональні вимоги

Вимоги продуктивності

5.1.1 Продукт повинен обчислювати вартість за день менше ніж за секунду;

5.1.2 Програма повинна бути розроблена на мові С++;

5.1.3 Продукт повинен виконувати фільтрацію даних менше ніж за секунду;

5.1.4 Продукт не повинен займати більше 20 мегабайт оперативної пам’яті;

5.1.5 Продукт не повинен займати на магнітному носію більше 20 мегабайт.

Вимоги безпеки

5.2.1 Продукт повинен містити ідентифікацію по паролю.

Вимоги до інформації

6.1 Структура вхідних даних:

Таблиця 1.2.1 – Вхідні дані системи

Ідентифікатор Тип Діапазон значень Пояснення
Код діагнозу Текстовий(String) Код діагнозу.
Термін Текстовий(String) Назва діагнозу.
Термін лікування Текстовий(String) Термін лікування діагнозу.
Код квитанції Текстовий(String) Код квитанції.
Код клієнта Текстовий(String) Код клієнта.
Всього до оплати Числовий(double) Сума, яку клієнт після використання послуг медичного діагностичного центру повинен оплатити в грошовій одиниці – рн..
Дата видачі Дата(date) 1968 – 2100 Дата видачі клієнту квитанції.
Прізвище та ім’я клієнта Текстовий(String) Прізвище та ім’я клієнта.
Діагноз Текстовий(String) Діагноз
Код препарату Текстовий(String) Код препарату, який належить медичному діагностичному центру.
Код лікаря Текстовий(String) Код лікаря.
Прізвище та ім’я Текстовий(String) Прізвище та ініціали клієнта.
Код паспорту Текстовий(String) Код паспорту клієнта.
Телефонний номер Текстовий(String) Телефонний номер клієнта
Місто проживання Текстовий(String) Місто проживання клієнта.
Прізвище і ініціали Текстовий(String) Прізвище та ініціали лікаря.
Код паспорту Текстовий(String) Код паспорту лікаря.
Телефонний номер Текстовий(String) Телефонний номер лікаря.
Місто проживання Текстовий(String) Місто проживання лікаря.
Назва препарату Текстовий(String) Назва препарату, який належить медичному діагностичному центру.
Дата виготовлення Дата(Date) 1968 – 2100 Дата виготовлення препарату.
Термін придатності Дата(Date) 1968 – 2100 Дата, до якого препарат можна вживати.
text2 Текстовий(AnsiString) Для виконання запитів додавання та видалення інформації
text3 Текстовий(AnsiString) Для виконання запитів додавання та видалення інформації
text Текстовий(AnsiString) Для виконання запитів додавання та видалення інформації
textKey Текстовий(AnsiString) Для перевірки на повторюваність значень по кодовим полям всіх таблиць
textTermin Текстовий(AnsiString) Для перевірки на повторюваність значень по полю «Термін» таблиці «Діагнози»

6.2 Структура вихідних даних:

Таблиця 1.2.2 – Вихідні дані системи

Ідентифікатор Тип Діапазон значень Пояснення
Код діагнозу Текстовий(String) Код діагнозу.
Термін Текстовий(String) Назва діагнозу.
Термін лікування Текстовий(String) Термін лікування діагнозу.
Код квитанції Текстовий(String) Код квитанції.
Код клієнта Текстовий(String) Код клієнта.
Всього до оплати Числовий(double) Сума, яку клієнт після використання послуг медичного діагностичного центру повинен оплатити в грошовій одиниці – рн..
Дата видачі Дата(date) 1968 – 2100 Дата видачі клієнту квитанції.
Прізвище та ім’я клієнта Текстовий(String) Прізвище та ім’я клієнта.
Діагноз Текстовий(String) Діагноз
Код препарату Текстовий(String) Код препарату, який належить медичному діагностичному центру.
Код лікаря Текстовий(String) Код лікаря.
Прізвище та ім’я Текстовий(String) Прізвище та ініціали клієнта.
Код паспорту Текстовий(String) Код паспорту клієнта.
Телефонний номер Текстовий(String) Телефонний номер клієнта
Місто проживання Текстовий(String) Місто проживання клієнта.
Прізвище і ініціали Текстовий(String) Прізвище та ініціали лікаря.
Код паспорту Текстовий(String) Код паспорту лікаря.
Телефонний номер Текстовий(String) Телефонний номер лікаря.
Місто проживання Текстовий(String) Місто проживання лікаря.
Назва препарату Текстовий(String) Назва препарату, який належить медичному діагностичному центру.
Дата виготовлення Дата(Date) 1968 – 2100 Дата виготовлення препарату.
Термін придатності Дата(Date) 1968 – 2100 Дата, до якого препарат можна вживати.
date Текстовий(String) Для отримання вибраного користувачем дати, яка задана через компонент MonthCalendar, щоб виконати обрахування загальної суми за день.
*d Символьний(Char) Для конвертування в правильну позицію для бази даних дату.
first_2_day Символьний(Char) Для конвертування в правильну позицію для бази даних дату.
month Символьний(Char) Для конвертування в правильну позицію для бази даних дату.
d1 Символьний(Char) Для конвертування в правильну позицію для бази даних дату.
none Текстовий(String) Для виведення інформації про відсутній прибуток.
sum_day Текстовий(String) Для виведення користувачу суму за день.

 


 

Огляд технології розробки

RAD (від англ. rapid application development - швидка розробка додатків) - концепція створення засобів розробки програмних продуктів, яка надає особливого увагу швидкості і зручності програмування, створенню технологічного процесу, що дозволяє програмісту максимально швидко створювати комп'ютерні програми.

Основні принципи RAD:

· Інструментарій повинен бути націлений на мінімізацію часу розробки.

· Створення прототипу для уточнення вимог замовника.

· Циклічність розробки: кожна нова версія продукту грунтується на оцінці результату роботи попередньої версії замовником.

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

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

· Управління проектом повинно мінімізувати тривалість циклу розробки.

Середовища розробки, використовують принципи RAD:

· Borland Delphi.

· Borland C + + Builder.

· Microsoft Visual Studio.

· Macromedia Flash.

· Macromedia Authorware.

· Macromedia Director.

· Omnis Studio.

· Visual DataFlex.

· IntraWeb.

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

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

Найбільш суттєвими з них є:

· Висока швидкість розробки;

· Низька вартість;

· Висока якість.

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

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

Технологія RAD забезпечує:

· Прудкість просування програмного продукту на ринок;

· Інтерфейс влаштовує користувача;

· Легку адаптованість проекту до змінюваним вимогам;

· Простоту розвитку функціональності системи.

Під терміном «RAD» звичайно розуміється процес розробки ПЗ, що містить 3 елементи:

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

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

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

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

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

· Фаза аналізу і планування вимог.

· Фаза проектування.

· Фаза побудови.

· Фаза впровадження.

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

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

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

Архітектура потоків даних

BPwin - потужний інструмент моделювання, розроблений фірмою Computer Associates Technologies який використовується для аналізу, документування та реорганізації складних бізнес-процесів. Модель, створена засобами BPwin, дозволяє чітко документувати різні аспекти діяльності - дії, які необхідно зробити, способи їх здійснення, що вимагаються для цього ресурси та ін. Таким чином, формується цілісна картина діяльності підприємства - від моделей організації роботи в маленьких відділах до складних ієрархічних структур. При розробці або закупівлі програмного забезпечення моделі бізнес-процесів служать прекрасним засобом документування потреб, допомагаючи забезпечити високу ефективність інвестицій у сферу IT. В руках же системних аналітиків і розробників BPwin - ще й потужний засіб моделювання процесів при створенні корпоративних інформаційних систем.

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

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

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

BPwin дозволяє:

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

· Удосконалювати бізнес-процеси, формулюючи і визначаючи альтернативні реакції на дії ринку.

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

BPwin (тепер AllFusion Process Modeler) - програмний продукт в області реалізації засобів CASE-технологій. Дозволяє проводити опис, аналіз і моделювання бізнес-процесів. Займає одне з лідируючих місць в своєму сегменті ринку. В даний час випускається компанією Computer Associates. Поширюється на комерційній основі.

Включає три стандартні методології: IDEF0 (функціональне моделювання), DFD (моделювання потоків даних) і IDEF3 (моделювання потоків робіт). Ці методології по-своєму унікальні. Кожна з них може бути виконана окремо за допомогою BPwin, але їх сукупність укладена в модель дає аналітику повну картину предметної області клієнта.

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

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

· функції обробки інформації (роботи, процеси);

· документи (стрілки, arrow), об'єкти, співробітників або відділи, що беруть участь в обробці інформації;

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

· таблиці для збереження документів (сховища даних, data store).

У BPwin для побудови діаграм потоків даних використовується нотація Гейна - Сарсона.

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

Роботи. У DFD роботи являють собою функції системи, що перетворюють входи у виходи.

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

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

Злиття і розгалуження стрілок. У DFD стрілки можуть зливатися і розгалужуватися, що дозволяє описати декомпозицію стрілок. Кожний новий сегмент стрілки, що зливається або розгалужується може мати власне ім'я.

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

Альтерн



Поделиться:


Последнее изменение этой страницы: 2016-08-16; просмотров: 233; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.189.2.122 (0.139 с.)