• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Система виконання замовлення

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

4. Стратегічні рішення

На стратегічному етапі ухвалюються рішення, які важливі для всього проекту.

Найголовнішими рішеннями є:

· вибір моделі,

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

· вибір середовища розробки,

· вибір інструментів CASE,

· ухвалення рішень по використанню готових компонентів,

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

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

Найголовнішими обмеженнями є:

· максимальна сума грошей, яка може бути витрачена,

· працівники, які можуть бути задіяні,

· доступні інструменти,

· обмеження за часом.

Результатом стратегічного етапу є прийняття або неприйняття пропозиції замовника.

Стратегічний етап не є частина виробництва ПЗ, тому він не повинен реалізовуватися за рахунок замовника.

Під вивченням досяжності розробки розуміють:

· порівняння розмірів проекту, проектної команди і необхідного часу

· наявність ресурсів (бюджет, штат, менеджери),

· обмеження в часі,

· початкові умови, потрібні для реалізації,

· наявність ПЗ і інструментів,

· наявність апаратури і мережі,

· наявність технологій і ноу-хау,

· наявність експертів,

· наявність послуг, співробітників і постачальників,

· наявність офісів і транспорту.

5. Оцінка різних варіантів рішеннь

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

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

До них відносять:

· вартість,

· час реалізації,

· можливість багатократного використання,

· мобільність,

· продуктивність.

Приклад оцінювання за різними критеріями приведений в наступній таблиці:

Таблиця 4.7.1 Оцінка різних способів рішення.

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

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

Таблиця 4.7.2 Приклад оцінки, розробленій на зваженій сумі.

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

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

Приклад.

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

Приклад дерева ризику має вигляд:

Мал. 4.7.3. Приклад дерева ризику.

6. Оцінка вартості рішень

Оцінка вартості визначається для кожного з варіантів рішень.

Вартість складають наступні аспекти:

· вартість апаратури,

· вартість навчання професіоналів,

· вартість придбання інструментів,

· робоче навантаження.

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

Для оцінки робочого навантаження використовують різні методи:

Алгоритмічні методи. Вони вимагають атрибути даних у формі номерів або описів. Відповідна математична формула видає результат.

Оцінка, дана експертом. Досвідчені люди можуть легко оцінити витрати нового проекту.

Оцінка за аналогією.Цей підхід вимагає доступу до даних про виконаних раніше проектів і заснований на пошуку характеристик цих проектів.

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

Зростаюче оцінювання. Вартості розраховується по частинах, і результатом є їх сума.

Метод COCOMO(Constructive Cost Model).Метод заснований на декількох формулах, які дають змогу зробити оцінку повної вартості, якщо відома кількість рядків коду. Це є слабким місцем методу. Число рядків може бути відоме тільки коли розробка архітектури системи завершена, що зазвичай надто пізно. Поняття "рядок коду" залежить від мови програмування. COCOMO пропонує декілька рішень: просте, середньої складності і складне (детальне). Простий метод обчислює вартість, застосовуючи просту формулу для оцінки числа людей і місяців, потрібних для завершення проекту. Метод середньої складності змінює результати простого методу, враховуючи нові чинники, які залежать від складності проекту. Складний метод враховує нові чинники і вплив інших факторів на систему, але це не призводить до збільшення точності оцінок.

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

Інші методи:

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

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

Оцінкаробочогонавантаження тестування.
Оцінка робочого навантаження документації.
Оцінка використання мережі.

7. Чинники успіху

Найголовнішими чинниками успіху на стратегічному етапі є:

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

· Контакт з ключовими представниками клієнта. Невелике неприйняття методу може закінчитися невдачею.

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

8. Результати стратегічного етапу

Користувач отримує звіт, який містить в собі:

· мета проекту,

· область дії проекту,

· опис зовнішніх систем,

· формулювання основних вимог,

· модель системи,

· пропоноване рішення,

· попередній графік роботи.

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

9. Короткий звіт

Стратегічний етап - це попередня стадія проекту. Головна мета - доставити відповідні дані, потрібні для проектного стратегічного ухвалення рішення. Це дуже складне завдання, для вдалого виконання якого необхідний досвід.

V. Розпізнавання вимог і документація

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

Цей етап повинен бути виконаний кілька разів, можливо інколи із присутністю клієнта.

1. Складнощі у формулюванні вимог

Цей етап дуже важливий. Він визначає успішність проекту. Також це - дуже складне завдання.

Існує багато причин складності цього етапу:

· клієнт зазвичай не знає, як досягти мети,

· існує багато шляхів для рішення завдання,

· великі системи часто використовуються безліччю користувачів, і вони протирічать один одному,

· користувачі можуть спілкуватися, використовуючи різні словники,

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

Рівні опису вимог

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

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

Специфікація ПЗ - формальний опис вимог.

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

Якість опису вимог

Хороший опис вимог повинен задовольняти наступні вимоги:

· бути повним і послідовним,

· описувати зовнішній режим роботи,

· описувати обмеження системи,

· бути доступним для модифікування,

· брати до уваги можливі майбутні зміни,

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

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

Рекоммендациі до правильних визначеннях

Вимоги повинні бути представлені критичним порівнянням з існуючим ПЗ і прототипами. Угода повинна бути складена між розробниками і користувачами. Знання і досвід розробників повинен бути втілені у проект і зрозумілими для замовника.

Вимоги користувача повинні бути:

· зрозумілими,

· унікальними,

· такими, щбо їх можна було перевірити,

· точними,

· реалістичними,

· виконуваними.

2. Методи ідентифікації вимог

Найбільш важливі методи ідентифікації вимог:

· Зустрічі і огляди (зустрічі повинні бути підготовлені у формі списку питань від різних сторін, що відносяться до даного проекти. Вони повинні проходити серед презентабельної групи користувачів, які прагнуть схвалення проекту).

· Вивчення існуючого ПЗ (часто нове ПЗ замінює старе. Вивчення повинне визначати слабкі і сильні сторони старого ПЗ і погоджувати з ними нові вимоги, якщо система повинна бути частиною старої).

· Вивчення досяжності (повинні бути визначені реалістичні цілі і методи).

· Прототипування (проектування прототипів систем з меншим об'ємом і спрощеним інтерфейсом).

Читайте також:

1. Active-HDL як сучасна система автоматизованого проектування ВІС.
2. II. Бреттон-Вудська система (створена в 1944 р.)
3. III. Виконання бюджету
4. III. Вимоги безпеки під час виконання роботи
5. III. Вимоги безпеки під час виконання роботи
6. IV. Система зв’язків всередині центральної нервової системи
7. IV. УЗАГАЛЬНЕННЯ І СИСТЕМАТИЗАЦІЯ ВИВЧЕНОГО
8. V. Виконання вправ на застосування узагальнювальних правил.
9. V. Систематизація і узагальнення нових знань, умінь і навичок
10. VI. Система навчаючих завдань для перевірки кінцевого рівня завдань.
11. VI. Система навчаючих завдань для перевірки кінцевого рівня завдань.
12. VI. Узагальнення та систематизація знань

Переглядів: 747