Планування проекту

13.12.2012

06.12.2012

29.11.2012

Бази даних

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

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

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

Таблиця, запис, поле є основними складовими реляційних баз даних.

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

Записом є рядок таблиці бази даних

Полем є стовпець таблиці бази даних.

Ключове поле встановлене для однозначного запису. В ньому записи не повторюються.

Пріорітезація – це спосіб вирішення конфліктів між вимогами за обмежені ресурси.

Вирішення: прибрати вимоги з меншим пріоритетом. Кожну вимогу можна вважати важливою/не важливою і терміновою/не терміновою.

	Важливі	Не важливі
Термінові	Високий пріоритет	Можна відкинути
Не термінові	Середній пріорітет	Низький пріоритет

Табл. Пріоритезації Конвоя

- QFM

- TQM

Методи визначення пріоритетів на основі цінності, вартості, ризиків:

Валові коеф.
Характер.	Користь	Відносн. збиток	Цінність	Відн. цінність	Вартість	%	Ризик	%	Пріоритет
Роздрук списку
Запит
Створ. звіту

25=9*2+7*1

Всього

Пріорітет

Затвердження вимог

Кодування

Користувацькі вимоги

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

Проектування архітектури

Дизайн проектування ф-цій

Приймання тестування

Системне тестування

Інтеграція тестування(перевірка цілісності)

Модульне тестування

Планування модульного тестування  

Затвердження вимог дозволяє переконатися, що:

¾ Очікування можливості і характеристики проекту

¾ Вимоги точно відображають системні вимоги бізнес-правил

¾ Вимоги повні і якісні

¾ Вимоги узгоджені між собою

¾ Вимоги створюють якісну основу для подальшої імплементації продукту

Рев’ю(інспектування)

Формальне Неформальне

-walk throw(наскрізний контроль) -Desktop checking

-fagan inspection(формальне інспектування) -колективна перевірка

Учасники формального інспектування:

¾ автор, колеги автора;

¾ автор попереднього продукту або специфікації для елемента, який необхідно перевіряти;

¾ люди, які будуть виконувати роботу: розробники, тестувальники;

¾ люди, які відповідають за роботу продуктів, що взаємодіють з тим, що перевіряється.

Макс 6 чоловік

Ролі експертів:

¾ автор;

¾ аналітик;

¾ координатор(модератор) – планує експертизу, узгоджує особливості, розподіляє матеріал, управляє нарадою, інформування про результати;

¾ читач (reader);

¾ writer, scriber (секретар).

Вхідні критерії:

¾ документ відповідає шаблону;

¾ виконана перевірка граматики;

¾ підготовлені всі супровідні документи або посилання;

¾ невирішені питання ТВД;

¾ координатор не виявляє більше 3-ьох істотних дефектів протягом 10 хвилин.

Етапи формального тестування:

Початковий продукт

e [3201]" strokecolor="#c0504d [3205]" strokeweight="2pt">

Планування

Оглядова зустріч

Інспекційна нарада

Підготовка

Переробка

Заключний етап

Заключний продукт

Планування – автор і координатор, дата експертизи, об’єм пакету. Оптимально розглядати 2-4 сторінки на год.

Оглядова зустріч – автор описує матеріал.

Підготовка(експертиза) – 75% дефектів

Інспекційна нарада – не довше 2 год.

Вихідні критерії

1) Вирішено всі питання

2) Всі зміни внесені в документ чи інші відповідні продукти були внесені коректно.

3) Всі проблеми, помічені ТВД – вирішені, при цьому фіксувались дата,автор.

4) Документ був звірений з допомогою системного управління конфігурацією

5) Контрольний список дефектів.

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

1) Чи є варіант використання автономною і окремою задачею

2) Чи чітко сформулювала мета для конкретного варіанту використання.

3) Чи зрозуміло, хто отримує переваги від цього варіанту використання.

4) Чи сформульований варіанту використання на базовому рівні

5) Чи всі альтернативні напрямки варіанту використання задокументовані

6) Чи задокументовані відомі умови виключення

7) Чи належним чином варіанту використання структурує вхідні і вихідні мови

8) Чи реалізований і піддається перевірці кожен визначений напрямок варіанту використання

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

1) Організація і завершеність

ü Чи написані всі вимоги на одному і тому ж рівні деталізації

ü Чи конкретні всі внутрішні перехресні посилання

ü Чи забезпечують вимоги адекватну основу для проектування

ü Чи вказаний пріоритет реалізації кожної вимоги

ü Чи включені всі відомі потреби клієнта(системи)

ü Чи визначені всі зовнішні інтерфейси обладнання програмних продуктів і їх взаємодії

ü Чи задокументована очікувана поведінка системи для імовірних подій

2) Конкретність

ü Чи конфліктують певні вимоги між собою, або повторність їх

ü Чи написана кожна вимога зрозумілою точною і недвозначною мовою

ü Чи не виходять вимоги за границю проекту

ü Чи можна реалізувати всі вимоги,не виходячи за рамки обмежень

ü Чи можна перевірити кожну вимогу з допомогою тестування,огляду аналізів

ü Чи немає граматичних помилок

ü Чи всі повідомлення про помилки унікальні і зрозумілі

3) Атрибути якості

ü Чи всі завдання пов’язані з продуктивністю сформульовані належним чином

ü Чи всі задачі явно заду коментовані і оцінені з врахуванням прийнятих компромісів

ü Чи всі завдання, що стосуються безпеки сформульовані належним чином

4) Послідковуваність вимог

ü Чи кожна умова ідентифікована унікально і коректно

ü Чи послід кована кожна функціональна вимога до більш високого рівня

5) Особливі проблеми

ü Чи всі вимоги можна віднести власне до вимог,а не реалізації

ü Чи ідентифіковані всі функції, шо залежать від часу,чи визначені їх критерії

ü Чи були розглянуті належним чином потреби, пов’язані з інтернаціоналізацією

Проблеми:

1) Великий об’єм документації

*виділити обсяг підвищеного ризику та мало пріоритетності

2) Велика команда експертів

*переконатись, що кожен учасник знає свою область роботи

Взаємозв’язок вимог з іншими етапами проекту

Основна версія вимог

Планування проекту

Проектування і кодування

Тестування

1) Використання вимог для оцінки масштабу проекту

2) Оновлення планів при зміні вимог

3) Врахування пріоритетів вимог, при плануванні ітерації

Проектування і кодування

1) Врахування атрибутів якості при проектуванню архітектури

2) Розподіл вимог за компонентами

3) Відслідковування вимог до дизайну і коду

Дата добавления: 2015-05-24