WWW.REFERATCENTRAL.ORG.UA - Я ТУТ НАВЧАЮСЬ

... відкритий, безкоштовний архів рефератів, курсових, дипломних робіт

ГоловнаПедагогіка, Сценарії виховних заходів → Менеджмент проекту інформаційної системи підтримки нормативно-правового забезпечення органів державного управління - Реферат

Менеджмент проекту інформаційної системи підтримки нормативно-правового забезпечення органів державного управління - Реферат

1.1.2. Покоління технології МП. У табл.1 представлені три покоління головних досягнень технологій МП щодо інструментарію, компонентів, процесів. Необхідний рівень якості та персонал приймаються постійними.

Таблиця 1

Три покоління головних досягнень технологій: інструментарій, компоненти, процеси

Загальна характеристика

  • 60-і – 70-і рр.

  • Водоспадна модель.

  • Функціональне проектування.

  • Плата за масштаб

  • 80-і – 90-і рр.

  • Удосконалення процесу.

  • Підхід, побудований наінкапсуляції.

  • Плата за масштаб

  • Починаючи з 2000 р.

  • Ітераційна розробка.

  • Компонентно-орієнтований підхід.

  • Повернення інвестицій

Середовище, розмір та технології процесів

Середовище/інструментарій

Кустарне

Розмір:

100% на замовлення

Процесс:

Вузькоспеціалізований

Середовище/інструментарій

Готові, локальні

Розмір:

30% на базі готових компонентів

70% на замовлення

Процесс:

Відтворюваний

Середовище/інструментарій

Інтегроване середовище автоматизації

Розмір:

70% на базі готових компонентів

30% на замовлення

Процесс:

Керований/вимірюваний

Типова ефективність проекту

Передбачувано погана

Завжди:

Перевищення бюджету.

Перевищення термінів

Непередбачувана

Рідко:

У межах бюджету.

За графіком

Передбачувана

Звичайно

У межах бюджету.

За графіком

Три покоління процесів розробки ПЗ визначимо таким чином:

  1. Традиційний: 60– 70-ті рр., кустарне виробництво. Організації використовують кустарний інструментарій, кустарні процеси і практично усі компоненти для замовника пишуться на примітивних мовах. Результат виконання проекту було легко передбачити в тому сенсі, що він практично ніколи не вкладався в наперед визначену вартість, терміни та якість.

  2. Перехідний: 80 – 90-ті рр., програмна інженерія. Організації використовують відтворювані процеси та готові інструменти, а більшість створюваних компонентів (>70%) пишуться на мовах високого рівня. Деякі компоненти (<30%) стають доступними в якості комерційного продукту, включно з операційними системами, системами керування базами даними, мережевим ПЗ та графічним інтерфейсом користувача. Протягом 80-х рр. деякі організації починають досягати економі і при великих масштабах, але із збільшенням складності застосувань (особливо при переході на розподілені системи) існуючі мови, методи та технології виявилися недостатніми для того, щоб підтримувати необхідний рівень промислового проектування.

  3. Сучасна практика: починаючи з 2000 р., виробництво ПЗ. Передові організації широко застосовують керовані та вимірювані процеси, інтегровані середовища автоматизації і більшу частину (70%) готових компонентів. Можливо, всього 30% компонентів належить створювати на замовлення. Використовуючи переваги технології створення ПЗ та інтегрованих середовищ, можна дуже швидко розробляти системи, побудовані на компонентах.

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

1.2. Практична оцінка вартості ПЗ. Однією з важливих проблем при оцінці ПЗ є відсутність добре документованих практичних приладів проектів, де використовувалася ітераційна розробка. Серед розробників та постачальників моделей та засобів для оцінки вартості ПЗ ідуть суперечки щодо:

  • яку модель вартості ПЗ належить використовувати;

  • вимірювання обсягу ПЗ належить виконувати в рядках вихідного коду або у функціональних точках;

  • що може вважатися хорошою оцінкою.

В індустрії ПЗ між собою конкурують біля 50 постачальників засобів, даних та послуг для оцінки вартості ПЗ. Відомі загальнодоступні моделі та засоби для оцінки вартості ПЗ (COCOMO, CHEKPOINT, ESTIMACS, KnowledgePlan, Price-S, ProQMS, SEER, SLIM, SOFTCOST та SPQR/20), а також величезна кількість моделей, які застосовуються в конкретних організаціях.

У питання вимірювання обсягу ПЗ домінують дві точки зору: рядки вихідного коду (SLOC) [3] або функціональні точки.

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

Застосування функціональних точок має багато послідовників, які вказують на складності, пов'язані з використанням SLOC для об'єктно-орієнтованих програм. Міжнародний консорціум по використанню функціо-нальних точок (the International Function Point User's Group), утворений в 1984 р., є домінуючою асоціацією по питаннях вимірювання ПЗ. Найголовнішою перевагою застосування функціональних точок є те, що цей метод не залежить від конкретної технології, таким чином, надає елементарні одиниці вимірювання для порівняння різних проектів та організацій. Головний його недолік полягає в тому, що визначення абстрактні, а спосіб проведення вимірювань не випливає безпосередньо з положень, які входять до нього. При порівняні різних проектів або різних організацій належить використовувати функціональні точки. Вони є більш точним способом вимірювання на ранніх стадіях ЖЦ проекту. На пізніх же стадіях кориснішою і точнішою основою для різних вимірювань стає SLOC.

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

  • Створюється і підтримується менеджером проекту, командою з розробки архітектури, командою розробників і командою тестувальників, тобто усіма, хто відповідає за виконання робіт.

  • Сприймається усіма виконавцями як амбіціозна, але така, що може бути виконана.

  • Базується на докладно описаній моделі вартості ПЗ, що має основу, яка заслуговує довіру.

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

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

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

Далі розглянемо, як представлені в цьому розділі теоретичні положення та підходи МП щодо економічних аспектів розробки ПЗ були використані в керуванні проектуванням ІС "ЗНЗ".

2. Менеджмент проекту ІС "ЗНЗ"

2.1. Методи дослідження. Комплекс досліджень по технології проектування ІС "ЗНЗ"проводився із застосуванням об'єктно-орієнтованого підходу до їхнього системного аналізу. Процес керування проектуванням ІС досліджувався з використанням методів проектного менеджменту, зокрема методів "критичного шляху" (CPM– Critical Path Method), схеми організації робіт PERT (Program Evaluation and Review Technique) та методів проектування на основі спіральної моделі. При визначенні формальної моделі керування проектом застосовувався апарат теорії графів. Методика дослідження предметної області систем управлінської діяльності (СУД) розроблена з використанням теорії масового обслуговування. Проектування ІС "ЗНЗ"з використанням підходів, моделей та методів, отриманих в результаті проведених досліджень, базувалося на архітектурно-технологічних рішеннях із застосуванням трирівневої архітектури: "клієнт –сервер застосувань – сервер БД" ( СКБД Oracle) та розподілених застосувань, побудованих за принципами компонентного підходу. Наукова новизна одержаних результатів полягає у наступному:

  • визначені нові принципи моделювання й оптимізації задач керування ТП проектування ІС, починаючи з аналізу потреб до створення відповідного програмного продукту;

  • розроблені формальні моделі керування проектуванням системи, ТП якої містить множину процесів переробок різних сукупностей робіт проекту з оцінкою їх виконання відповідно до плану.

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

2.2. Принципи керування проектуванням ІС "ЗНЗ". ІС "ЗНЗ" належить до складних об'єктів, які містять велику кількість даних та документів, зв'язність інформаційних компонентів, а також залучення до процесів проектування різних спеціалістів для врахування специфіки та особливостей керування цими процесами. Керування проектуванням таких ІС виконується з використанням принципів та методів математичного програмування, стохастичних мережевих моделей та моделей, побудованих на статистичних даних, які підтримують загальні методи вирішення задач цього класу [4]. Однак для розробки таких ІС ці принципи та моделі не є достатніми.

Loading...

 
 

Цікаве