На які дві моделі спирається методологія DATARUN.

Методологія DATARUN спирається на дві моделі або на два уявлення:

· модель організації;

· модель ІС.

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

Які цілі переслідує підхід DATARUN .

Підхід DATARUN переслідує дві цілі:

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

· спроектувати ІС на підставі моделі даних.

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

Послідовність кроків проектування системи .

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

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

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

Інструментальний засіб SE Companion .

30. Основні принципи "живої" розробки ПЗ .

Екстремальне програмування (Extreme Programming, XP) виникло як еволюційний метод розробки ПЗ "від низу до верху". Цей підхід є прикладом так званого методу "живої" розробки (Agile Development Method). До групи "живих" методів входять, крім екстремального програмування, методи SCRUM, DSDM (Dynamic Systems Development Method, метод розробки динамічних систем), Feature-Driven Development (розробка, керована функціями системи) і ін.

Основні принципи "живої" розробки ПЗ:

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

· Працююча програма важливіша, ніж вичерпна документація.

· Співпраця із замовником важливіша, ніж обговорення деталей контракту.

· Відробіток змін важливіший, ніж проходження планам.

Схема потоку робіт в XP

Переваги та недоліки XP

33. Основні принципи "живої" розробки ПЗ .

Схема потоку робіт в XP

Переваги та недоліки XP.

36. Основні правила Екстремального Програмування: планування

Правила Екстремального Програмування

Основні правила Екстремального Програмування:

Планування

· Пишуться User Stories

.

· Власне план створюється в результаті Планування Релізу.

· Випускати часті невеликі Релізи.

· Вимірюється Швидкість проекту.

· Проект ділиться на Ітерації.

· Кожна ітерація починається зі зборів по плануванню.

· Люди постійно міняються завданнями.

· Щодня починається з ранкових Зборів стоячи.

· XP правила коректуються якщо щось не так.