Быстрый поиск

Учебное пособие: Інформаційні системи в економіці

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

Проект інформаційної системи - генеральний план або модель системи.

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

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

Мети проектування:

· Розгляд альтернативних конфігурацій технології.

· Керування і контроль технічною реалізацією системи.

· Визначення і деталізація технічних специфікацій системи

Види проектування

Існу два основних види проектування логічну і фізичне (див. таблицю 3.)

Таблиця 3.

Види проектування

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

Опис

Склад

Логічне

Представлення компонентів системи і їхніх зв'язків з погляду користувача, що показує, що системне рішення буде робити.

введення і висновки;

функції обробки;

ділові процедури;

моделі даних;

засобу керування.

Фізичне

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

апаратні засоби;

програмне забезпечення;

фізичні бази даних;

засобу введення-висновку інформації;

ручні процедури;

засобу керування.

Проектні альтернативи

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

Основн проектні альтернативи:

· централізовані або розподілені;

· нтерактивні або пакетні;

· частково ручні або цілком автоматизовані;

· нші.

Роль кінцевих користувачів

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

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

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

Проектн специфікації

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

Таблиця 4.

Проектні специфікації

Висновок

Носій

Зміст

Синхронізація

Уведення

Джерела

Потік

Уведення даних

Інтерфейс користувача

Простота

Ефективність

Логіка

Зворотний зв'язок

Помилки

Проект бази даних

Логічні зв'язки даних

Вимоги по обсязі і швидкодії

Файлова організація і проект

Специфікації записів

Обробка

Обчислення

Програмні модулі

Необхідні звіти

Синхронізація висновку

Ручні процедури

Які дії

Хто виконує їхній

Коли

Як

Де

Засобу керування

Засобу керування введенням (символи, обмеження, вірогідність)

Засобу керування обробкою (несуперечність, кількість записів)

Засобу керування висновком (загальні підсумки, приклади висновку)

Процедурні засоби керування (паролі, спеціальн форми)

Безпека

Засобу керування доступом

Плани на випадок катастрофи

Контрольні журнали

Документація

Документація по операціях

Документи систем

Документація користувача

Конверсія

Преутворені файли

Ініціалізація нових процедур

Вибір методу тестування

Перехід до нової системи

Навчання

Вибір методів навчання

Розробка модулів навчання

Ідентифікація засобів навчання

Організаційні зміни

Перепроектування задач

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

Проектування офісу і структури організації

Повідомлення про зв'язки

Програмування

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

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

Таблиця 1.

Учасники етапу програмування

Учасник	Функція
Кваліфікований програміст	Робота складається винятково в кодуванні програм
Програміст / аналітик	Проектування і програмування функції
Група програмування	Створення великих систем, що складаються з безліч програм з тисячами і навіть сотнями тисяч рядків коду

Тестування

Тестування - вичерпний рунтовний процес, що відповідає на запитання: чи робить системи необхідн результати при відомих умовах.

50 відсотків від усього бюджету на розробку програмного забезпечення може бути витрачене на іспити. Іспит також вимагає дуже багато часу: повинні бути ретельно підготовлені дані іспити, розглянуті результати і зроблені виправлення в системі.

Види тестування:

· тестування модулів або тестування програми – незалежне тестування кожної програми в системі.

· Тестування системи - перевірка функціонування інформаційної системи в цілому.

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

Роль користувачів у процесі тестування:

· Ідентифікація повного діапазону даних і умов обробки системи.

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

· Ідентифікація частих і менш загальних транзакций.

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

· Перевірка ручних процедур у системі.

Якість спитів значно підвищується, якщо вони проводяться на основі плану іспитів.

План спитів - список усіх готувань до серії іспитів, що будуть виконані на системі.

Конверсія

Конверсія - процес заміни старої системи нової.

Стратег конверсії представлені в таблиці 2.

Таблиця 2.

Стратегії конверсії

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

Якість конверсії значно підвищується, якщо вона проводиться на основі плану конверсії.

План конверсії - список усіх дій, необхідних для установки нової системи.

Проблеми конверсії

Створення плану конверсії.

Конверсія даних.

Навчання кінцевих користувачів використанню нової системи.

Створення детальної технічної і користувальницької документації.

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

Документація - описи роботи інформаційної системи з технічної або користувальницької точки зору.

Реалізація і супровід

Заключними етапами процесу розробки є реалізація і супровід.

Реалізація - процес оцінки системи користувачами і технічними фахівцями на відповідність первісним цілям розробки і визначення необхідних змін.

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

Розподіл часу супроводу

Налагодження або виправлення проблем реалізації - 20%.

Зміни даних, файлів, звітів, апаратних засобів або програмного забезпечення - 20%.

Створення розширень користувача, поліпшення документації і перекодування компонентів системи для підвищення ефективності обробки - 60%.

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

Види стратегій розробки інформаційних систем

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

Таблиця 1.

Стратегії розробки інформаційних систем

Підхід	Можливості	Переваги	Недоліки
Життєвий цикл систем	Послідовний покроковий формальний процес Написання специфікацій і тверджень Обмежена роль користувачів	Необхідний для великих складних систем і проектів	Повільний і дорогою Не вітає змін Величезний документообіг для керування
Макетування	Вимоги визначаються динамічно за допомогою експериментальної системи Швидкий, неформальний і ітеративний процес Користувачі постійно взаємодіють із прототипом	Швидкий і недорогий Корисний, коли вимоги точно не відомі або, коли важливий інтерфейс кінцевого користувача Сприяє участі користувача	Не підходить для великих складних систем Може замовчувати недоліки на важливих кроках аналізу, документування і тестування
Пакети прикладного програмного забезпечення	Комерційне програмне забезпечення усува необхідність для розробки програм власними силами	Скорочує роботи з проектування, програмуванню, нсталяції і супроводові Може заощадити час і гроші, коли розробляються загальні бізнеси-додатки Скорочує необхідність у внутрішніх ресурсах нформаційних систем	Може не задовольняти унікальним вимогам організації Може не виконувати багато бізнесів-функцій добре Велике настроювання може значно збільшити витрати на розробку
Розробка кінцевого користувача	Системи створюються кінцевими користувачами, що використовують інструментальні засоби програмного забезпечення четвертого покоління Швидка і неформальна Мінімальна роль фахівців інформаційних систем	Користувачі контролюють створення систем Заощаджує час і витрати на розробку Зменшує незавершені роботи додатка	Може привести до розростання неконтрольованих нформаційних систем Системи не завжди відповідають стандартам забезпечення якості
Використання зовнішніх постачальників інформаційних послуг	Системи створюються й іноді керуються зовнішнім постачальником	Може скоротити або контролювати витрати Може зробити системи, при недоліку внутрішніх ресурсів і технічному дефіциті	Менший контроль над функцією інформаційних систем Залежність від технічної спрямованост благополуччя зовнішніх постачальників

Проблеми вибору стратегії розробки інформаційної системи

Нема підходу, що може використовуватися для всіх ситуацій і типів систем. Кожний з цих підходів має переваги і недоліки, і кожний забезпечує менеджерів діапазоном виборів. У таблиці 2 представлені основні проблеми вибору стратегії розробки нформаційної системи.

Таблиця 2.

Проблеми вибору стратегії розробки інформаційної системи

Проблема	Опис
Визначення правильної стратегії розробки систем	Жодна зі стратегій не підходить. Остаточна конфігурація системи не може бути заздалегідь визначена, тому що інформаційні вимоги або відповідна технологія невизначені. Запропонована система викликає основн організаційні і технічні зміни. Рішення: організація повинна переслідувати стратегію по етапного введення, при якому проекти систем розбиті в менш блоки і розробляються "поступово" по етапах, або фірма повинна цілком відкласти проект.
Контролювання розробки інформаційних систем поза відділом інформаційних систем	Розробка кінцевого користувача: не існує підходящого способу установки стандартів засобів контролю. стандарти і засоби контролю, що мають велик обмеження, можуть не тільки викликати опір користувача, але можуть також душити інновації кінцевого користувача. занадто слабкі засоби контролю викликають серйозн проблеми цілісності даних і связности. Рішення: не завжди можливо знайти правильне сполучення стандартів і засобів контролю.
Вибір стратегія розробки систем, що вписуватися в нформаційну архітектуру фірми і стратегічний план	Розробка кінцевого користувача, пакети прикладного програмного забезпечення або використання зовнішніх інформаційних послуг: підходящі короткострокові рішення, що не враховують довгострокові інтереси організації; створення непорівнянних додатків, що не можуть легко інтегруватися в загальну інформаційну архітектуру фірми. Рішення: ретельна оцінка довгострокового впливу стратегій розробки додатків.