Головна

Методології проектування. Типове проектування.

  1.  I.2.4. Майданні камеральноє проектування.
  2.  I.2.4. Майданні камеральноє проектування.
  3.  Автоматизація процесів проектування.
  4.  Аналіз об'єкта автоматизації. методології аналізу
  5.  Аспірантам. Поняття методу і методології. Основні методи і форми наукового пізнання.
  6.  Взаємозв'язок методології, методів і методик психологічного експериментального дослідження.
  7.  Взаємозв'язок методології, методів і методик психолого-педагогічних досліджень

Створення системи з готових типових елементів. Вимога - можливість декомпозиції проектованої ІС на безліч складових компонентів (підсистем, комплексів задач, програмних модулів і т. Д.). Д / реалізації виділених компонентів вибираються наявні на ринку типові проектні рішення, які налаштовуються на особливості конкретного підприємства.

Типове проектне рішення (ТПР) - тиражується (придатне до багаторазового використання) проектне рішення.

 Клас ТПР / Реалізація ТПР  переваги  недоліки
 елементні ТПРТіповие рішення по завданню або окремого виду забезпечення завдання (інф-ному, програмного, тех., матем., організаційного) Бібліотеки методо-орієнтованих програм  ? забезпечується застосування модульного підходу до проектування і документування ІС  ? великі витрати часу на створення пари різнорідних елементів внаслідок інформаційної, програмної та технічної несумісності ? великі витрати часу на доработкуТПР окремих елементів
 Підсистемні ТПРЕлемент типізації - окремі підсистеми, розроблені з урахуванням функціональної повноти і мінімізації зовнішніх інформаційних связейПакети прикладних програм (ППП)  ? досягається високий ступінь інтеграції елементів ІС ? дозволяють здійснювати: модульне проектування; параметріч. настройку програмних компонентів на різні об'єкти керування ? забезпечують: скорочення витрат на проектування і програмування взаємопов'язаних компонентів; гарне документування відображаються процесів обробки інф-ії  ? адаптивність ТПР недостатня з позиції безперервного інжинірингу ділових процесів ? виникають проблеми в комплексуванні різних функціональних підсистем, особливо в разі використання рішень кількох виробників програмного забезпечення
 Об'єктні ТПРТіповие галузеві проекти, включають повний набір функціональних і забезпечують підсистем ІС.  ? комплексування всіх компонентів ІС за рахунок методологічної єдності і інформаційної, програмної та технічної сумісності ? відкритість архітектури - дозволяє устанавліватьТПР на різних програмно-технічних платформах ? масштабованість - допускає конфігурацію ІС для змінного числа робочих місць ? конфігурованість - вибір необхідної підмножини компонентів  ? проблеми прив'язки типового проекту до конкретного об'єкта управління, що викликає в деяких випадках навіть необхідність зміни організаційно-економічної структури об'єкта автоматизації

5. Процеси життєвого циклу інформаційної системи. ГОСТ 12 207.

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

1) Процес замовлення (робота замовника).

2) Процес постачання (робота постачальника).

3) Процес розробки (робота розробника).

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

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

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

1) Процес документування (опис інформації, яка видається в процесі ЖЦ).

2) Процес управління конфігурацією.

3) Процес забезпечення якості (об'єктивне забезпечення того, щоб програмні продукти і процеси відповідали вимогам, встановленим для них, і реалізовувалися в рамках затверджених планів. Методи: спільні аналізи, аудиторські перевірки, верифікація та атестація).

4) Процес верифікації.

5) Процес атестації.

6) Процес спільного аналізу (оцінка стану і результатів будь-якої роботи).

7) Процес аудиту (визначення відповідності вимогам, планам і договором).

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

Організаційні процеси ЖЦзастосовуються для створення і реалізації основної структури, що охоплює взаємопов'язані процеси ЖЦ і відповідний персонал, а також для постійного вдосконалення даної структури і процесів. Як правило, типові процеси.

1) Процес управління (управління проектом при реалізації процесів ЖЦ).

2) Процес створення інфраструктури (створення основної структури процесу ЖЦ).

3) Процес удосконалення.

4) Процес навчання персоналу.

6. Процеси життєвого циклу інформаційної системи. Процеси планування.

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

Планування дозволяє:

- Ефективніше використовувати ресурси інформаційної системи;

- Закладати велику керованість і кращу інтеграцію існуючих і майбутніх систем;

- Бути впевненим у тому, що ІС буде відповідати загальному напрямку розвитку організації;

- Врахувати думку кінцевих користувачів;

- Створювати умови для правильного реагування на непередбачені ситуації.

Цілі процесу планування ПО:

- Визначити конкретні види робіт, які дозволять реалізувати системні вимоги і створити ПО необхідного рівня.

- Визначити моделі ЖЦ ПО, а також описати взаємозв'язки між процесами, послідовність їх виконання, механізми зворотного зв'язку.

- Вибрати середу підтримки ЖЦ, а також методи і інструментальні кошти, які потрібно використовувати для виконання робіт в кожному процесі ЖЦ.

- Розробити документи процесу планування ПО.

У процесі планування ПО повинні бути виконані наступні роботи:

- Розробка планів створення ПО і передача їх виконавцям;

- Визначення і вибір стандартів розробки ПО;

- Необхідно скоординувати плани розробки ПО і плани інтегральних процесів, щоб отримати узгоджені стратегії виконання різних процесів ЖЦ;

- Визначення процедури перегляду і уточнення планів по мірі розвитку проекту;

- Вибір методів і інструментальних засобів, що дозволяють запобігти і виявити помилки і забезпечують безпеку системи.

У процесі планування ПО повинні бути розроблені такі плани:

- План розробки ПЗ (використовувані моделі ЖЦ ПО і середовище розробки ПО);

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

- План кваліфікаційного тестування ПО (порядок його виконання);

- План управління конфігурацією ПЗ (кошти, за допомогою яких будуть задоволені мети процесу управління конфігурацією ПЗ);

- План забезпечення якості ПЗ (кошти, за допомогою яких будуть задоволені мети процесу забезпечення якості ПЗ);

- План установки ПО (дії по встановленню розробленого ПО на робочих місцях користувачів, підготовку і навчання персоналу та адаптацію існуючих систем);

- План передачі ПО (апаратне і ПО, а також інші ресурси, необхідні для підтримки ЖЦ переданого ПО).

Плани ПО повинні вказувати:

- Вхідні дані для процесу, включаючи зворотний зв'язок від інших процесів;

- Дії інтегральних процесів, які можуть знадобитися для обробки цих даних;

- Необхідні інструментальні засоби, методів, стандартів та процедур.

Мета планування середовища ЖЦ ПО полягає у визначенні методів, інструментальних засобів, процедур, мов програмування і апаратних засобів, які будуть використані для виконання процесів ЖЦ ПО і підготовки документів ЖЦ ПО.

7. Процеси ЖЦ ІС. Процеси визначення вимог до ІС.

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

Вимоги до ПО д. Б .: документовані, здійснимі, тестовані, з рівнем деталізації достатнім для проектування системи. Вимоги м. Б. функціональними і нефункціональними.

Аналіз вимог включає три типи діяльності:

- Збір вимог: спілкування з клієнтами і користувачами.

- Аналіз вимог: визначення, чи є зібрані вимоги неясними, неповними, неоднозначними (суперечать) і потім вирішення цих проблем.

- Документування вимог: вимоги м. Б. задокументовані в різних формах (простий опис, сценарії використання, призначені для користувача історії, або специфікації процесів).

Розробник повинен визначити і зареєструвати вимоги до ІС, методи, які потрібно використовувати, для гарантії того, що кожне вимога була виконана.

Цілі процесу визначення вимог до ПЗ:

- Розробити вимоги верхнього рівня;

- Оцінити похідні вимоги верхнього рівня з т. З. безпеки системи.

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

Процес визначення вимог до ПЗ повинен забезпечити наступне:

- Аналіз функціональних системних вимог і вимог до інтерфейсів;

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

- Визначення всіх вимог верхнього рівня, відповідних системним вимогам, які пов'язані із запобіганням ризику;

- Верифіковані, несуперечливість та відповідність вимог верхнього рівня стандартам на розробку вимог до ПЗ;

- Встановлення вимог верхнього рівня в кількісних показниках з похибками в тих випадках, коли це необхідно;

- Оцінку похідних вимог верхнього рівня з точки зору безпеки системи.



 Методології проектування. канонічне проектування |  Процеси ЖЦ ІС. Процеси проектування.

 каскадна модель |  переваги |  еволюційна модель |  Процеси ЖЦ ІС. Процеси кодування. |  Процеси ЖЦ ІС. Процеси інтеграції. |  Стратегії та методи проектування інформаційних систем. |  Аналіз об'єкта автоматизації. методології аналізу |  Координація процесу рецензування. Необхідний спостерігач за процесом рецензування (бібліотекар). |  Початок (Inception) |  Методика вибору архітектури |

© um.co.ua - учбові матеріали та реферати