Аіс проектне управління. АІС «Проектне управління. Основні поняття проектування АІС

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

Цикл розробки (проектування) програмного забезпечення (software project lifecycle) - сукупність стадій і етапів розробки програмного забезпечення починаючи від системного аналізу і розробки вихідних вимог до її установки (інсталяції) на ЕОМ.

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

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

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

Деталізована розробка проекту АІС передбачає наявність повного комплекту організаційної, конструкторської, технологічної та експлуатаційної документації.

Проектування будь-якого об'єкта здійснюється з:

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

Після вибору методу проектування АІС необхідно спланувати комплекс робіт по створенню системи відповідно до типових етапами її розробки. Проект розглядається і затверджується Замовником. Проектування АІС передбачає виконання певних стадій і етапів.

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

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

для автоматизації різних видівдіяльності (управління, проектування, дослідження і т.п.), включаючи їх поєднання, використовують положення ГОСТ 34.601-90. Він передбачає наступні стадії і етапи проектування (таблиця 1).

Таблиця 2

У стандарті вказується також, що:

• · Стадії і етапи, що виконуються організаціями, учасниками робіт зі створення АС, встановлюються в договорах і Технічному завданні на основі цього стандарту.
• · Допускається виключати стадію "Ескізний проект" і окремі етапи робіт на всіх стадіях, об'єднувати "Технічний проект" і "Робоча документація" в одну стадію "Техно-робочий проект". Залежно від специфіки створюваних АС і умов їх створення допускається виконувати окремі етапи робіт до завершення попередніх стадій, паралельне в часі виконання етапів робіт, включення нових етапів робіт.

Технічний проект (preliminary design) містить принципові електричні схеми і конструкторську документацію об'єкта розробки і складові його частини, перелік обраних готових засобів програмного і технічного забезпечення(В тому числі типів ЕОМ, операційної системи, прикладних програм і т.д.), алгоритми рішення задач для розробки нових засобів програмного забезпечення).

Робочий проект (detailed design) - заключний етап проектування, в загальному випадку передбачає уточнення і деталізацію результатів попередніх етапів, створення і випробування дослідного зразка об'єкта автоматизації, розробку і відпрацювання програмних продуктів, технологічної та експлуатаційної документації.

У сучасній практиці проектування автоматизованих інформаційних систем (наприклад, АІПС, АСНТИ, АСУ та ін.) Він може бути початковим етапом їх впровадження в роботу організації або служби Замовника проекту, або головний в ряді інших автоматизуються організацій, служб і т.д.

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

Державний стандарт ГОСТ 19.102-77 встановлює наступні стадії розробки програмної документації:

• 1. Технічне завдання;
• 2. Ескізний проект;
• 3. Технічний проект;
• 4. Робочий проект;
• 5. Впровадження.

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

В рамках виконання першої стадії "Формування вимог до АС" здійснюється обстеження об'єкта та обгрунтування необхідності створення АІС з урахуванням вимог користувача до проектованої АІС. Ці процедури першого етапу проектування входять до складу передпроектного дослідження. Сюди ж можуть входити процедури другій стадії проектування - "Розробка концепції АС".

В процесі передпроектного дослідження здійснюється розробка техніко-економічного обґрунтування доцільності створення АІС; вироблення загальних вимог на розробку АІС.

В процесі передпроектного дослідження для виконання необхідних проектних робіт виявляють:

• · матеріальні ресурси,
• · фінансові ресурси,
• · Людські ресурси,
• · Тимчасові ресурси.

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

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

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

До основних засобах автоматизованого проектуванняможна віднести:

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

Системи автоматизованого проектування (САПР), які передбачають використання ЕОМ на всіх етапах створення АІС.

Загальні вимоги, що пред'являються до засобів проектування:

Повне охоплення всього процесу створення АІС;

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

Універсальність, тобто можливість застосування одних і тих же засобів для різних об'єктів;

Доступність в освоєнні і простоту (простота) в реалізації;

Можливість організації процесу проектування в режимі інтерактивної взаємодії розробника системи, проектувальника та ЕОМ,

Адаптованість і економічна ефективність.

серед методів проектуваннявиділяють:

Оригінальна проектування;

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

Автоматизоване проектування.

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

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

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

1. розробка типових проектних рішень, реалізованих в пакетах прикладних програм (ППП) для вирішення економічних завдань з подальшою прив'язкою ППП до конкретних умов впровадження та функціонування;

2. Розробка автоматизованих систем проектування.

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

Типове проектування- індустріальний метод створення АІС, що використовує ТПР і ППП. Цей метод характеризується наявністю перевірених, типових організаційно-економічних, технічних, інформаційних, математичних і програмних засобів автоматизації управління. Застосування даного методу дозволяє знизити трудомісткість, знизити вартість і скоротити терміни проектування, підвищити якість проектування. Процес типового проектування полягає у виборі і прив'язці забезпечують підсистем відповідно до вимог конкретної АІС. Типова частина АІС являє собою комплекс інформаційного, програмного і технічного забезпечення. Типовий характер інформаційного забезпечення досягається шляхом суворого дотримання єдності структури інформаційної бази, складу масивів, форм вхідних і вихідних документів. Типовий характер програмного забезпечення досягається використанням ППП, і типовий характер технічного забезпечення досягається застосуванням ЕОМ одного або спільних типів.

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

2. При використанні модульного методуТПР створюються за модульним принципом, коли кожне проектне рішення розчленовується на окремі складові частини-модулі, які реалізують певну частину ТПР. Це дозволяє створити проект нової автоматизованої системи шляхом поєднання окремих типових модулів.

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

Важлива вимога, що пред'являється до ППП, - сумісність, тому що при проектуванні АІС доцільно використовувати відразу кілька пакетів. Проектування систем із застосуванням ППП фактично зводиться до прив'язки обраних за певними параметрами пакетів до конкретних умов об'єкта автоматизації. позитивними якостямитакого підходу до проектування можна назвати: менш трудомісткий процес, скорочення часу проектування в порівнянні з оригінальним проектуванням, реалізація прогресивних методів обробки даних, спрощення документування проекту (тому що використовується документація пакетів), підвищення надійності проектованих АІС.

4. Крім того, виділяють метод групового проектування. Його суть полягає в попередньому підборі групи об'єктів, однотипних за характеристиками. Серед них вибирається базовий об'єкт, для якого і розробляється проект, причому можуть використовуватися різні методи і способи проектування. Головним при цьому є забезпечення високої адаптивності проекту. Основна сфера застосування цього методу - непромислові об'єкти (наприклад, склади).

Найбільш ефективно автоматизації піддаються наступні види діяльності:

1. бухгалтерський облік, включаючи управлінський і фінансовий. Найбільше число ППП створено для бухгалтерського обліку. Серед них «1C: бухгалтерія», «Турбо-Бухгалтер», «Інфо-Бухгалтер», «Парус», «ABACUS», «Бембі +» та ін .;

2. довідкове та інформаційне обслуговування економічної діяльності. Представлено наступними ППП: «ГАРАНТ» (податки, бухоблік, аудит, підприємництво, банківська справа, валютне регулювання, митний контроль); «КОНСУЛБТАНТ +» (податки, бухоблік, аудит, підприємництво, банківська справа, валютне регулювання, митний контроль).

3. економічна і фінансова діяльність. Представлена ​​наступними ППП:

a) «Економічний аналіз і прогноз діяльності фірми, організації» (фірма «ІНЕК»), який реалізує функції: економічний аналіздіяльності фірми, підприємства; складання бізнес-планів; техніко-економічне обґрунтування повернення кредитів; аналіз і відбір варіантів діяльності; прогноз балансу, потоків грошових коштів і готової продукції.

b) на багато користувачів мережевий комплекс повної автоматизації корпорації «Галактика» (АТ «Новий атлант»), який включає планування, оперативне управління, облік і контроль, аналіз, крім того, дозволяє в рамках СППР забезпечувати вирішення завдань бізнес-планування з використанням ППП Project- Expert.

4. організація праці керівника;

5. автоматизація документообігу;

6. навчання.

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

Автоматизовані системи проектування -другий, швидко розвивається шлях ведення проектувальних робіт.

Серед автоматизованих методів проектування особливе місце займають методи модельного проектування. Створення і використання САПР забезпечує досить високий рівень функціональної надійності, комплексний охоплення всіх технологічних процесів, зниження трудомісткості проектних робіт з максимальним урахуванням інтересів об'єкта автоматизації. Однак цей метод досить дорогий і вимагає висококваліфікованих розробників. Ключова вимога, що пред'являється до САПР, - можливість побудови і підтримки в системі проектування в адекватному стані деякої глобальної економічної інформаційної моделі об'єкта автоматизації. Модель - це відображення інформаційних компонентів об'єкта автоматизації і відносин між ними, заданий в явному вигляді. Основна мета побудови моделі - створення відповідного цій моделі проекту АІС, що враховує і активно використовує всі характеристики об'єкта. Така модель повинна містити в формалізованому вигляді опис сукупностей інформаційних компонентів і відносини між ними, включаючи інформаційні зв'язки і алгоритмічне взаємодія. За допомогою модельного методу проектування застосовується системний підхід, Що обумовлює використання ЕОМ не тільки на всіх стадіях створення системи, але і в процесі аналізу результатів її промислової експлуатації. Розвиток і застосування САПР зумовило перехід до створення індивідуальних проектів, Але на значно вищому рівні, в порівнянні з оригінальним методом проектування.

В області автоматизації проектування ІС та ІТ за останнє десятиліття сформувався новий напрям - CASE технологія автоматизованої розробки ПЗ(CASE - Computer-Aided Software / System Engineering). Зростаюча складність інформаційних систем, що підвищуються до них вимоги привели до необхідності індустріалізації технологій їх створення.

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

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

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

Автоматизація програмування заснована на автоматичній генерація програмних кодів, які містять описи даних, основну логіку їх обробки, схеми баз даних, файли опису інтерфейсів і ін. Надалі коди уточнюються і допрацьовуються, проте в ряді випадків автоматизація досягає 90%. Крім того, CASE-технологія генерує необхідну документацію по проекту, готову до використання.

При використанні CASE-технології забезпечується підтримка єдиної бази проекту, тобто вся інформація про розроблюваної АИС автоматично поміщається в єдину базу даних проекту. Цим підтримується узгодженість, несуперечність, повнота і мінімальна надмірність проектних даних.

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

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

CASE володіють наступними основними перевагами:

Покращують якість створюваних ІС (ІТ) за рахунок коштів автоматичного контролю (перш за все, контролю проекту);

Дозволяють за короткий час створювати прототип майбутньої ІС (ІТ), що дозволяє швидко, на ранніх етапах оцінити очікуваний результат;

Прискорюють процес проектування і розробки системи;

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

Підтримують розвиток і супровід вже функціонуючої ІС.

До теперішнього моменту утворилася потужна CASE-індустрія, яка об'єднала сотні фірм і компаній різної орієнтації. Серед них виділяються:

Компанії-розробники засобів аналізу і проектування ІС та ІТ

Фірми-розробники спеціальних засобів з орієнтацією на вузькі предметні області або на окремі етапи життєвого циклу ІС;

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

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

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

Nbsp; Моделі життєвого циклу АІС

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

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

Модель ЖЦ АІС включає:

Результати виконання робіт на кожній стадії;

Ключові події або точки завершення робіт і прийняття рішень.

Відповідно до відомими моделями ЖЦ ПО визначають моделі ЖЦ АІС - каскадну, итерационную, спіральну.

I. Каскадна модельописує класичний підхід до розробки систем в будь-яких предметних областях; широко використовувалася в 1970-80-х рр.

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

виділяють п'ятьстійких етапів розробки, практично не залежать від предметної області (рис. 1.1).

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

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

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

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

Останній етап - здача готового проекту, І головне тут - переконати замовника в тому, що всі його вимоги виконані в повній мірі.

Рис.1.1 Каскадна модель ЖЦ АІС

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

Переваги каскадної моделі:

1) на кожному етапі формується закінчений набір проект ної документації, який відповідає критеріям повноти і узгодженості. На заключних етапах розробляється призначена для користувача документація, що охоплює всі передбачені стандартами види забезпечення АІС (організаційне, інформаційне, програмне, технічне і т. Д.);

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

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

Недоліки каскадної моделі:

Істотна затримка в отриманні результатів;

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

Складність паралельного ведення робіт за проектом;

Надмірна інформаційна перенасиченість кожного з етапів;

Складність управління проектом;

Високий рівень ризику і ненадійність інвестицій.

Затримка в отриманні результатівпроявляється в тому, що послідовний підхід до розробки узгодження результатів із зацікавленими сторонами проводиться тільки ті завершення чергового етапу робіт. В результаті може виявитися, що розробляється АІС не відповідає вимогам, і такі невідповідності можуть виникати на будь-якому етапі розробки; крім того, помилки можуть ненавмисно вноситися і проектувальниками-аналітиками, і програмістами, так як вони не зобов'язані добре розбиратися в тих предметних областях, для яких розробляється АІС.

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

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

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

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

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

У разі ж виявлення помилок в роботі необхідне повернення до попередніх етапів; поточна робота тих, хто помилився, переривається. Наслідком цього зазвичай є зрив термінів виконання як виправляється, так і нового проектів.

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

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

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

II. ітераційна модельполягає в серії коротких циклів (кроків) з планування, реалізації, вивчення, дії.

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

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

недолікиитерационной моделі:

· Час життя кожного етапу розтягується на весь період ництва;

· Внаслідок великого числа ітерацій виникають неузгодженості виконання проектних рішень і документації;

· Заплутаність архітектури;

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

III. спіральна модель, На відміну від каскадної, але аналогічно попередньої передбачає ітераційний процес розробки АІС. При цьому зростає значення початкових етапів, таких як аналіз і проектування, на яких перевіряється і обгрунтовується реалізація технічних рішень шляхом створення прототипів.

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

Мал. 1.2. Спіральна модель ЖЦ АІС

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

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

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

перевагиитерационного підходу:

Ітераційна розробка істотно спрощує внесення змін до проекту при зміні вимог замовника;

При використанні спіральної моделі окремі елементи АІС інтегруються в єдине ціле поступово. Оскільки інтеграція починається з меншої кількості елементів, то виникає набагато менше проблем при її проведенні;

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

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

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

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

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

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

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

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

Технологія проектування АІС- це сукупність методів і засобів проектування АІС, а також методів і засобів організації проектування (управління процесом створення і модернізації проекту АІС).

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

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

Предметом обраній технології проектування повинно служити відображення взаємопов'язаних процесів проектування на всіх стадіях життєвого циклу АІС.

Основні вимоги, що пред'являються до обраній технології проектування, такі:

· Створений за допомогою цієї технології проект повинен відповідати вимогам замовника;

· Технологія повинна максимально відображати всі етапи життєвого циклу проекту;

· Технологія повинна забезпечувати мінімальні трудові і вартісні витрати на проектування і супровід проекту;

· Технологія повинна сприяти зростанню продуктивності праці проектувальників;

· Технологія повинна забезпечувати надійність процесу проектування і експлуатації проекту;

· Технологія повинна сприяти простому ведення проектної документації.

Технологія проектування АІС реалізує певну методологію проектування. У свою чергу, методологія проектування передбачає наявність певної концепції, принципів проектування і реалізується набором методів і засобів.

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

За ступенем автоматизації розрізняють:

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

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

За ступенем використання типових проектних рішень розрізняють:

оригінальне (індивідуальне)проектування, коли проектні рішення розробляються «з нуля» відповідно до вимог до АІС;

типове проектування, Що припускає конфігурацію АІС з готових типових проектних рішень (програмних модулів).

Оригінальна проектуванняАІС передбачає максимальне врахування особливостей автоматизованого об'єкта.

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

За ступенем адаптивності проектних рішень різняться такі методи:

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

параметризация- проектні рішення налаштовуються відповідно до заданих і змінюваними параметрами;

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

Поєднання різних ознак класифікації методів проектування обумовлює характер використовуваної технології проектування АІС. Виділяються два основні класи технології проектування: канонічнаі індустріальна. Індустріальна технологія проектування в свою розбивається на два підкласу: автоматизоване(Використання САSЕ-технологій) і типове(Параметрически-орієнтоване або модельно-орієнтоване) проектування.

Таблиця 1.1.Характеристики класів технологій проектування

Канонічне проектування АІСорієнтоване на використання головним чином каскадної моделі життєвого циклу АІС.

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

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

Стадія 1.Формування вимог до АІС:

· Обстеження об'єкта та обгрунтування необхідності створення АІС;

· Формування вимог користувачів до АІС;

· Оформлення звіту про виконану роботу і тактико-технічного завдання на розробку.

Стадія 2.Розробка концепції АІС:

· Вивчення об'єкта автоматизації;

· Проведення необхідних науково-дослідних робіт;

· Розробка варіантів концепції АІС, які відповідають вимогам користувачів;

· Оформлення звіту і затвердження концепції.

Стадія 3.Технічне завдання:

Розробка і затвердження технічного завдання на створення АІС.

Стадія 4.Ескізний проект:

· Розробка попередніх проектних рішень по системі і її частинам;

· Розробка ескізної документації на АІС і її частини.

Стадія 5.Технічний проект:

· Розробка проектних рішень по системі і її частинам;

· Розробка документації на АІС і її частини;

· Розробка і оформлення документації на поставку комплектуючих виробів;

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

Стадія 6.Робоча документація:

· Розробка робочої документації на АІС і її частини;

· Розробка і адаптація програм.

Стадія 7.Введення в дію:

· Підготовка об'єкта автоматизації; підготовка персоналу;

· Комплектація АІС поставляються виробами (програмними і технічними засобами, програмно-технічними комплексами, інформаційними виробами);

· будівельно-монтажні роботи; пуско-налагоджувальні роботи;

· Проведення попередніх випробувань;

· Проведення дослідної експлуатації;

· Проведення приймальних випробувань.

Стадія 8.Супровід АІС:

· Виконання робіт відповідно до гарантійних зобов'язань;

· Післягарантійне обслуговування.

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

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

Обгрунтування розробки та поетапного впровадження систем;

Складання технічного завдання на розробку систем;

Розробки технічного і робочого проектів систем.

На етапі обстеження доцільно виділити дві складові: визначення стратегії впровадження АІС і детальний аналіз діяльності організації.

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

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

Результатом етапу визначення стратегії є документ (техніко-економічне обґрунтування - ТЕО - проекту), де чітко сформульовано, що отримає замовник, якщо погодиться фінансувати проект, коли він отримає готовий продукт (графік виконання робіт) та скільки це буде коштувати (для великих проектів - це графік фінансування на різних етапах робіт). У документі бажано відобразити не тільки витрати, але і вигоду проекту, наприклад час окупності проекту, очікуваний економічний ефект(Якщо його вдається оцінити).

Обмеження, ризики, критичні фактори, які можуть вплинути на успішність проекту;

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

Терміни завершення окремих етапів, форма приймання / здачі робіт, які залучаються ресурси, заходи щодо захисту інформації;

Опис виконуваних системою функцій;

Можливості розвитку і модернізації системи;

Інтерфейси і розподіл функцій між людиною і системою;

вимоги до ПО і системам управління базами даних (СКБД).

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

Аналітики збирають і фіксують інформацію в двох взаємопов'язаних формах:

Функції - інформація про події та процеси, які відбуваються в автоматизируемой організації;

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

При вивченні кожної функціональної завдання управління визначаються:

Найменування завдання; терміни і періодичність її рішення;

Ступінь формализуемости завдання;

Джерела інформації, необхідні для вирішення завдання;

Показники та їх кількісні характеристики;

Порядок коригування інформації;

Діючі алгоритми розрахунку показників і можливі методи контролю;

Діючі кошти збору, передачі та обробки інформації;

Діючі засоби зв'язку;

Прийнята точність рішення задачі;

Трудомісткість рішення задачі;

Діючі форми представлення вихідних даних і результатів їх обробки у вигляді документів;

Споживачі результатної інформації по завданню.

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

Кількість документів;

Місце формування показників документів;

Взаємозв'язок документів при їх формуванні;

Маршрут і тривалість руху документа;

Місце використання та зберігання даного документа;

Внутрішні і зовнішні інформаційні зв'язки;

Обсяг документа в знаках.

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

На етапі обстеження слід класифікувати плановані функції системи за ступенем важливості. Один з можливих форматів представлення такої класифікації - MuSCoW. Ця абревіатура розшифровується так: Must have - необхідні функції; Should have - бажані функції; Could have - I можливі функції; Won "t have - відсутні функції.

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

Моделі діяльності організації створюються в двох видах 1:

Модель «як є» ( «as is») - відображає існуючі в op- I ганизации бізнес-процеси;

Модель «як повинно бути» ( «to be») - відображає необхід] мі зміни бізнес-процесів з урахуванням впровадження АІС. j

Уже на етапі аналізу необхідно залучати до роботи групи тестування для вирішення наступних завдань:

Отримання порівняльних характеристик передбачуваних до 1 використанню апаратних платформ, операційних систем, СУБД і т. П .;

Розробки плану робіт по забезпеченню надійності АІС і її тестування.

Залучення тестувальників на ранніх етапах розробки є доцільним для будь-яких проектів. Чим пізніше виявлені помилки в проектних рішеннях, тим дорожче обходиться їх виправлення; найгірший варіант - їх виявлення на етапі впровадження. Таким чином, чим раніше групи тестування почнуть виявляти помилки в АІС, тим нижче вартість роботи над системою. Час на тестування системи і на виправлення виявлених помилок повинно бути передбачено не тільки на етапі розробки, але і на етапі проектування.

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

Результати обстеження представляють об'єктивну основу для формування технічного завдання на АІС.

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

При розробці технічного завдання (ТЗ) необхідно вирішити такі завдання:

· Встановити спільну мету створення АІС;

· Встановити загальні вимоги до проектованої системі;

· Розробити і обґрунтувати вимоги, що пред'являються до інформаційного, математичного, програмного, технічного та технологічного забезпечення;

· Визначити склад підсистем і функціональних завдань;

· Розробити і обґрунтувати вимоги, що пред'являються до підсистем;

· Визначити етапи створення системи і терміни їх виконання;

· Провести попередній розрахунок витрат на створення системи і визначити рівень економічної ефективностівпровадження;

· Визначити склад виконавців.

Типові вимоги до складу та змісту технічного завдання наведені в табл. 1.6.

Тавбліца 1.6. Склад і зміст технічного завдання (ГОСТ 34.602-89)

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

Функції АІС;

Функції підсистем, їх цілі та очікуваний ефект від впровадження;

Склад комплексів задач і окремих завдань;

Концепція інформаційної бази і її укрупненная структура;

Функції системи управління базою даних;

Склад обчислювальної системи і інших технічних засобів;

Функції та параметри основних програмних засобів.

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

Відповідно до ГОСТ 19.102-77 стадія ескізного проектування містить два етапи: розробку ескізного проекту; затвердження ескізного проекту.

Перший етап розробки складається з:

Попередньою розробки структури вхідних та вихідних даних;

Уточнення методів рішення задачі;

Розробки загального опису алгоритму розв'язання задачі;

Розробки техніко-економічного обґрунтування;

Розробки пояснювальної записки.

При цьому допускається об'єднання та виключення деяких робіт.

Нижче наведено набір документів, який повинен і може бути підготовлений після закінчення ескцзного проектування.

Обов'язкові документи:

1) уточнене технічне завдання на проектування і раз-
работку АІС;

2) специфікація кваліфікаційних вимог на АІС;

3) комплект специфікацій вимог на функціональні компоненти програмного забезпечення і опису даних;

4) специфікація вимог на внутрішні інтерфейси компонент і інтерфейси з зовнішнім середовищем;

5) опис системи управління базою даних, структури і розподілу програмних і інформаційних об'єктів в базі даних;

6) проект керівництва щодо захисту інформації та забезпечення надійності функціонування АІС;

7) попередній варіант керівництва адміністратора АІС;

8) попередній варіант керівництва користувача АІС;

9) уточнений план реалізації проекту;

10) уточнений план управління забезпеченням якості АІС;

11) пояснювальна записка попереднього проекту АІС;

12) уточнений контракт (договір) з замовником на деталь
ве проектування АІС.

Документи, що оформляються за погодженням із замовником:

1) попередній опис функціонування АІС;

2) схема потоків даних між функціональними компонентами АІС;

3) уточнена схема архітектури АІС, взаємодії програмних і інформаційних компонент, організації обчислювального процесу і розподілу ресурсів;

4) опис показників якості компонент і вимог до них по етапах розробки АІС;

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

6) таблиця розподілу фахівців з компонентів і за етапами робіт;

7) атестати розробників на право використання технології і засобів автоматизації розробки АІС;

8) опис вимог до складу та форм підсумкових документів по етапах робіт;

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

10) попереднє керівництво для детального проектіро-
вання, програмування і налагодження компонент АІС;

11) попередній план продажу та впровадження;

12) опис попередньої структури бази даних.

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

Таблиця 1.7. Зміст технічного проекту

На стадії «Робоча документація» здійснюється створення програмного продукту і розробка всієї супровідної документації. Документація повинна містити всі необхідні і достатні відомості для забезпечення виконання робіт по введенню АІС в дію і її експлуатації, а також для підтримки рівня експлуатаційних характеристик (якості) системи. Розроблена документація повинна бути відповідним чином оформлена, узгоджена і затверджена.

На стадії «Введення в дію» для АІС встановлюють такі основні види випробувань: попередні випробування, дослідна експлуатація та приймальні випробування. При необхідності допускається додатково проведення інших видів випробувань системи та її частин.

Залежно від взаємозв'язків компонентів АІС і об'єкта автоматизації випробування можуть бути автономні і комплексні. В автономних випробуваннях беруть участь компоненти системи. Їх проводять у міру готовності частин системи до здачі в дослідну експлуатацію. Комплексні випробування проводять для груп взаємопов'язаних компонентів (підсистем) або для системи в цілому.

Для планування проведення всіх видів випробувань розробляється документ «Програма і методика випробувань». Розробник документа встановлюється в договорі або ТЗ. Як додаток до документа можуть включатися тести або контрольні приклади.

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

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

Дослідники нараховують 169 типів помилок, зведених в 19 великих класів:

1) логічні;

2) помилки маніпулювання даними;

3) помилки введення-виведення;

4) помилки в обчисленнях;

Мал. 1.10.Відносні витрати на виявлення і виправлення однієї помилки

5) помилки в призначених для користувача інтерфейсів;

6) помилки в операційній системі та допоміжних програмах;

7) помилки компоновки;

8) помилки в міжпрограмних інтерфейсах;

9) помилки в інтерфейсах «Програма - системне ПО»;

10) помилки при поводженні з зовнішніми пристроями;

11) помилки сполучення з базою даних (БД);

12) помилки ініціалізації БД;

13) помилки змін за запитом ззовні;

14) помилки, пов'язані з глобальними змінними;

15) повторювані помилки;

16) помилки в документації;

17) порушення технічних вимог;

18) непізнані помилки;

19) помилки оператора.

Не всі помилки виходять від розробника. За даними різних дослідників, від 6 до 19% помилок породжуються помилками в документації.

Співвідношення розробки і випробувань на різних етапах проектування АІС наведено на рис. 1.11.

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

Мал. 1.11.Співвідношення розробки і випробувань по етапах проектування АІС

Методика налагодження враховує симптоми можливих помилок:

Невірна обробка (неправильну відповідь, результат) - до 30%;

Невірна передача управління - 16%;

Несумісність програм з використовуваними даними - 15%;

Несумісність програм по пересилаються даними - до 9%.

При розробці налагоджувальних завдань вирішуються наступні завдання:

Складання тестів;

Вибір точок, зон і маршрутів контролю;

Визначення переліку контрольованих величин і порядку фіксації їх значень;

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

Оцінка достовірності та трудомісткості налагодження.

Налагоджують програму повинна хоча б один раз пропрацювати по кожній гілці алгоритму і при цьому привласнити змінним ряд значень, захоплюючи межі діапазону, кілька значень всередині нього, нульові значення і особливі точки (якщо є). Для спеціалізованих систем розробляють спеціальні мови налагодження. Вони можуть містити відносно невелике число команд (20-30) з додатковими настроювальними параметрами для вирішення наступних завдань:

Управління висновком;

Моделювання процесу виконання налагоджують програму;

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

Перевірки умов досягнення певних станів в процесі виконання програми;

Встановлення тестових значень вихідних даних;

Здійснення умовних переходів в тестуванні в залежності від результатів виконання інших макрокоманд або різних тестів;

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

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

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

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

Про особливості та статистикою помилок;

Про специфіку вихідних даних і послідовності зміни змінних в програмі і їх взаємний вплив;

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

3. У кожен момент часу визначайте розташування тільки однієї помилки.

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

5. Уважно вивчайте отримані вихідні дані і порівнюйте їх з очікуваними, заздалегідь розрахованими результатами.

6. Звертайте увагу на дані, ретельно аналізуйте роботу програми при використанні граничних значень і при неправильному введенні; контролюйте типи даних, діапазони, розміри полів і точність.

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

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

9. Документуйте всі виявлені і виправлені помилки, їх відмінності, місце розташування і тип. Ця інформація буде корисна для попередження майбутніх помилок.

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

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

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

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

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

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

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

Розміщено на http://www.allbest.ru/

Міністерство освіти і науки Російської Федерації

Федеральне державне бюджетне освітня установавищої професійної освіти

Санкт-Петербурзький державний університет технології та дизайну

Курсова робота

З дисципліни: «Архітектура інформаційних систем»

На тему: «Проектування автоматизованих інформаційних систем»

ВСТУП

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

Ось тільки деякі з переваг, які дає використання обчислювальної техніки при роботі організації:

ѕ Можливість оперативного контролю за достовірністю інформації;

ѕ Зменшення числа можливих помилок при генеруванні похідних даних;

ѕ Можливість швидкого доступу до будь-яких даних;

ѕ Можливість швидкого формування звітів;

ѕ Економія трудовитрат і витрат часу на обробку інформації.

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

Головна особливість індустрії систем автоматизації різних підприємств і установ, що характеризуються широкою номенклатурою вхідних даних з різними маршрутами обробки цих даних, полягає в концентрації складності на початкових етапах аналізу вимог і проектування специфікацій системи при відносно невисокої складності та трудомісткості наступних етапів. Фактично тут і відбувається розуміння того, що буде робити майбутня система, і яким чином вона буде працювати, щоб задовольнити пред'явлені до неї вимоги. А саме нечіткість і неповнота системних вимог, невирішені питання і помилки, допущені на етапах аналізу і проектування, породжують на наступних етапах важкі, часто нерозв'язні проблеми і, в кінцевому рахунку, приводять до неуспіху всієї роботи в цілому. Просте тиражування навіть дуже гарної системи управління підприємством ніколи не влаштує замовника повністю, оскільки не може врахувати його специфіки. Більш того, в даному випадку виникає проблема вибору саме тієї системи, яка найбільш підходить для конкретного підприємства. А ця проблема ускладнюється ще й тим, що ключові слова, що характеризують різні інформаційні системи, практично одні і ті ж:

ѕ Єдина інформаційне середовище підприємства;

ѕ Режим реального часу;

ѕ Незалежність від законодавства;

ѕ Інтеграція з іншими додатками (в тому числі з уже працюючими на підприємстві системами);

ѕ Поетапне впровадження і т.п.

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

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

Для досягнення мети необхідно вирішити такі завдання:

§ Сформулювати визначення основних понять і термінів;

§ Розглянути цілі і завдання проектування;

§ Ознайомитись з основними етапами проектування;

§ Виділити фази розвитку автоматизованих інформаційних систем;

§ Розглянути склад і структуру технічного завдання та технічного проекту.

1. ВИЗНАЧЕННЯ ПОНЯТЬ АВТОМАТИЗОВАНА ІНФОРМАЦІЙНА СИСТЕМА (АІС), ІНФОРМАЦІЙНА СИСТЕМА (ІС), ПРОЕКТ І ПРОЕКТУВАННЯ

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

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

Корінь слова проектування підкреслює зв'язок між процесом, у яких таку назву, і головними результатами даного процесу, такими є:

a) проекція - то, що виходить при аналізі складних явищ з метою отримання спрощених уявлень, і

b) проект - то, що виходить при синтезі складних уявлень з набору більш простих образів.

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

У проектуванні інформаційних систем об'єктами проектування виступають інформаційні системи і це цілком природно для інформатики (оскільки ІС вважаються її головними об'єктами).

Як відомо, інформаційні системи здатні відображати в собі найрізноманітніші явища світобудови, і, отже, все явища теж виявляються потенційними об'єктами проектування.

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

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

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

Інформаційна система (ІС) - взаємопов'язана сукупність засобів, методів і персоналу, використовуваних для зберігання, обробки та видачі інформації в інтересах досягнення поставленої мети.

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

Додавання до поняття «система» терміна «автоматизована» відображає способи створення і функціонування такої системи.

Автоматизована система(Відповідно до Держстандарту) - це система, що складається з взаємопов'язаної сукупності підрозділів організації та комплексу засобів автоматизації діяльності, що реалізує автоматизовані функції по окремих видахдіяльності.

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

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

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

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

Можна виділити наступні основні відмітні ознаки проекту як об'єкта управління:

· Обмеженість кінцевої мети;

· Обмеженість тривалості;

· Обмеженість бюджету;

· Обмеженість необхідних ресурсів;

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

· Комплексність;

· Правове та організаційне забезпечення.

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

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

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

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

Технологія проектування АІС - це сукупність методології та засобів проектування АІС, а також методів і засобів його організації (управління процесом створення і модернізації проекту АІС).

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

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

Предметом будь-якої обраній технології проектування повинно служити відображення взаємопов'язаних процесів проектування на всіх стадіях життєвого циклу АІС. До основних вимог, що пред'являються до обраній технології проектування, відносяться наступні:

· Створений проект повинен відповідати вимогам замовника;

· Максимальне відображення всіх етапів життєвого циклу проекту;

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

· Технологія повинна бути основою зв'язку між проектуванням і супроводом проекту;

· Зростання продуктивності праці проектувальника;

· Надійність процесу проектування і експлуатації проекту;

· Просте ведення проектної документації.

Основу технології проектування АІС становить методологія, яка визначає сутність, основні відмінні технологічні особливості.

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

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

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

2. МЕТА ТА ЗАВДАННЯ ПРОЕКТУВАННЯ

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

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

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

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

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

· Необхідну функціональність системи і ступінь адаптації до постійно змінюваних умов її функціонування;

· Необхідну пропускну здатність системи;

· Необхідний час реакції системи на запит;

· Безвідмовну роботу системи в необхідному режимі, іншими словами - готовність і доступність системи для обробки запитів користувачів;

· Простоту експлуатації і підтримки системи;

· Необхідну безпеку.

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

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

· Проектування об'єктів даних, які будуть реалізовані в базі даних;

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

· Облік конкретної середовища або технології, а саме: топології мережі, конфігурації апаратних засобів, використовуваної архітектури (файл-сервер або клієнт-сервер), паралельної обробки, розподіленої обробки даних і т.п.

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

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

3. ЕТАПИ ПРОЕКТУВАННЯ

Процес створення АІС поділяється на ряд етапів (стадій), обмежених деякими тимчасовими рамками і закінчуються випуском конкретного продукту.

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

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

Можна виділити наступні фази розвитку автоматизованих інформаційних систем:

3.1 Формування концепції. концептуальна фаза

Сюди входять:

· Формування ідеї;

· Формування ключової команди проекту;

· Вивчення мотивацій і вимог замовника та інших учасників;

· Збір вихідних даних і аналіз існуючого стану;

· Визначення основних вимог і обмежень, необхідних матеріальних, фінансових і трудових ресурсів;

· Порівняльну оцінку альтернатив;

· Подання пропозицій, їх експертизу та затвердження.

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

3.2 Підготовка технічної пропозиції

§ розробка основного змісту базової структури проекту;

§ розробка і затвердження технічного завдання;

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

§ складання кошторису і бюджету проекту;

§ розробка календарних планіві укрупнених графіків робіт;

§ підписання контракту з замовником;

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

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

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

§ виконання базових проектних робіт;

§ розробка приватних технічних завдань;

§ виконання концептуального проектування;

§ складання технічних специфікацій та інструкцій;

§ подання проектної розробки, експертиза та затвердження.

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

3.4 Розробка

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

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

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

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

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

3.5 Введення системи в експлуатацію

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

Основні види робіт:

§ комплексні випробування;

§ підготовка кадрів для експлуатації створюваної системи;

§ підготовка робочої документації, здача системи замовнику і введення її в експлуатацію;

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

§ оцінка результатів проекту та підготовка підсумкових документів.

4. СКЛАД І СТРУКТУРА ТЕХНІЧНОГО ЗАВДАННЯ І ТЕХНІЧНОГО ПРОЕКТУ

1. Загальні положення

1.1. Технічне завдання (ТЗ) є основним документом, що визначає вимоги та порядок створення (розвитку або модернізації - далі створення) інформаційної системи, відповідно до якого проводиться розробка ІС і її приймання при введенні в дію.

1.2. ТЗ розробляють на систему в цілому, призначену для роботи самостійно або в складі іншої системи.

1.3. Вимоги до ІС в обсязі, встановленому цим стандартом, можуть бути включені в завдання на проектування новостворюваного об'єкта інформатизації. В цьому випадку ТЗ ні розробляють.

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

1.5. У ТЗ включають тільки ті вимоги, які доповнюють вимоги до систем даного виду і визначаються специфікою конкретного об'єкта, для якого створюється система.

1.6. Зміни до ТЗ оформляють доповненням або підписаним замовником і розробником протоколом. Доповнення або вказаний протокол є невід'ємною частиною ТЗ на ІС. На титульному аркуші ТЗ повинна бути запис «Діє з ...».

2. Склад і зміст

2.1. ТЗ складається з таких розділів, які можуть бути розділені на підрозділи:

1) загальні відомості;

2) призначення та мета створення (розвитку) системи;

3) характеристика об'єктів;

4) вимоги до системи;

5) склад і зміст робіт зі створення системи;

6) порядок контролю та приймання системи;

7) вимоги до складу та змісту робіт з підготовки об'єкта розробки до введення системи в дію;

8) вимоги до документування;

9) джерела розробки.

У ТЗ можуть включатися додатки.

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

У ТЗ на частини системи не включають розділи, що дублюють зміст розділів ТЗ в цілому.

2.3. У розділі «Загальні відомості» вказують:

1) повне найменування системи та її умовне позначення;

2) шифр теми або шифр (номер) договору;

3) найменування компаній розробника і замовника (користувача) системи та їх реквізити;

4) перелік документів, на підставі яких створюється система, ким і коли затверджені ці документи;

5) планові терміни початку і закінчення роботи зі створення системи;

6) відомості про джерела і порядок фінансування робіт;

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

2.4. Розділ «Призначення і цілі створення (розвитку) системи» складається з підрозділів:

1) призначення системи;

2) цілі створення системи.

2.4.1. У підрозділі «Призначення системи» вказують вид діяльності системи (управління, проектування і т. П.) І перелік об'єктів інформатизації (об'єктів), на яких передбачається її використовувати.

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

2.5. У розділі «Характеристики об'єкта інформатизації» наводять:

1) короткі відомості про об'єкт інформатизації або посилання на документи, що містять таку інформацію;

2) відомості про умови експлуатації об'єкта автоматизації.

2.6. Розділ «Вимоги до системи» складається з наступних підрозділів:

1) вимоги до системи в цілому;

2) вимоги до функцій (завдань), що виконуються системою;

3) вимоги до видів забезпечення.

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

2.6.1. У підрозділі «Вимоги до системи в цілому» вказують:

вимоги до структури та функціонування системи;

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

показники призначення;

вимоги до надійності;

вимоги безпеки;

вимоги до ергономіки та технічної естетики;

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

вимоги до захисту інформації від несанкціонованого доступу;

вимоги щодо збереження інформації при аваріях;

вимоги до захисту від впливу зовнішніх впливів;

вимоги до патентної чистоти;

вимоги по стандартизації і уніфікації;

Додаткові вимоги.

2.6.1.1. У вимогах до структури та функціонування системи призводять:

1) перелік підсистем, їх призначення та основні характеристики, вимоги до числа рівнів ієрархії і ступеня централізації системи;

2) вимоги до способів і засобів зв'язку для інформаційного обміну між компонентами системи;

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

4) вимоги до режимів функціонування системи;

5) вимоги щодо діагностування системи;

6) перспективи розвитку, модернізації системи.

2.6.1.2. У вимогах до чисельності та кваліфікації персоналу на ІС призводять:

§ вимоги до чисельності персоналу (користувачів) ІС;

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

§ необхідний режим роботи персоналу ІС.

2.6.1.3. У вимогах до показників призначення ІС призводять значення параметрів, що характеризують ступінь відповідності системи її призначенню.

2.6.1.4. У вимоги до надійності включають:

1) склад і кількісні значення показників надійності для системи в цілому або її підсистем;

2) перелік аварійних ситуацій, за якими повинні бути регламентовані вимоги до надійності, і значення відповідних показників;

3) вимоги до надійності технічних засобів і програмного забезпечення;

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

2.6.1.5. У вимоги з безпеки включають вимоги по забезпеченню безпеки при поставці, налагодженню, експлуатації і обслуговуванні системи.

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

2.6.1.7. У вимоги до захисту інформації від несанкціонованого доступу включають вимоги, встановлені діючу пенсійну систему галузі та інформаційному середовищі замовника.

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

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

2.6.1.10. У додаткові вимоги включають спеціальні вимоги на розсуд розробника або замовника системи.

2.6.2. У підрозділі «Вимога до функцій (завдань)», що виконується системою, призводять:

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

§ при створенні системи в дві або більше черзі - перелік функціональних підсистем, окремих функцій або завдань, що вводяться в дію в 1-й і подальших чергах;

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

§ вимоги до якості реалізації кожної функції (завдання або комплексу завдань), до форми подання вихідної інформації, характеристики необхідної точності і часу виконання, вимоги одночасності виконання групи функцій, достовірності видачі результатів;

§ перелік і критерії відмов для кожної функції, по якій задаються вимоги по надійності.

2.6.3. У підрозділі «Вимоги до видів забезпечення» в залежності від виду системи призводять вимоги до математичного, інформаційного, лінгвістичного, програмного, технічного, метрологічного, організаційного, методичного та інші видами забезпечення системи.

2.6.3.2. Для інформаційного забезпечення системи приводять вимоги:

1) до складу, структури і способів організації даних в системі;

2) до інформаційного обміну між компонентами системи;

3) до інформаційної сумісності із суміжними системами;

4) щодо застосування систем управління базами даних;

5) до структури процесу збору, обробки, передачі даних в системі і представлення даних;

6) до захисту даних;

7) до контролю, зберігання, оновлення та відновлення даних;

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

2.6.3.4. Для програмного забезпечення системи приводять перелік покупних програмних засобів, а також вимоги:

1) до залежності програмних засобів від операційної середовища;

2) до якості програмних засобів, а також до способів його забезпечення і контролю;

2.6.3.5. Для технічного забезпечення системи приводять вимоги:

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

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

2.6.3.6. У вимогах до метрологічного забезпечення призводять:

1) попередній перелік вимірювальних каналів;

2) вимоги до точності вимірювань параметрів і (або) до метрологічних характеристик вимірювальних каналів;

3) вимоги до метрологічної сумісності технічних засобів системи;

4) перелік керівників і обчислювальних каналів системи, для яких необхідно оцінювати точності характеристики;

5) вимоги до метрологічного забезпечення технічних і програмних засобів, що входять до складу вимірювальних каналів системи, засобів, вбудованого контролю, метрологічної придатності вимірювальних каналів і засобів вимірювань, що використовуються при налагодженні та випробуваннях системи;

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

2.6.3.7. Для організаційного забезпечення призводять вимоги:

1) до структури і функцій підрозділів, що беруть участь у функціонуванні системи або забезпечують експлуатацію;

2) до організації функціонування системи і порядку взаємодії персоналу ІС і персоналу об'єкта інформатизації;

3) до захисту від помилкових дій персоналу системи.

2.7. Розділ «Склад і зміст робіт зі створення (розвитку) системи» повинен містити перелік стадій і етапів робіт зі створення системи, терміни їх виконання, перелік організацій - виконавців робіт, посилання на документи, що підтверджують згоду цих організацій на участь в створенні системи, або запис, що визначає відповідального (замовник або розробник) за проведення цих робіт.

В даному розділі також призводять:

1) перелік документів пред'являються після закінчення відповідних стадій і етапів робіт;

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

3) програму робіт, спрямованих на забезпечення необхідного рівня надійності системи (при необхідності);

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

2.8. У розділі «Порядок контролю і приймання системи» вказують:

1) види, склад, обсяг і методи випробувань системи та її складових частин;

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

2.9. У розділі «Вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи в дію» необхідно привести перелік основних заходів і їх виконавців, які слід виконати при підготовці проекту до введення ІС в дію.

До переліку основних заходів включають:

1) приведення надходить в систему інформації (відповідно до вимог до інформаційного та лінгвістичного забезпечення);

2) створення умов функціонування проекту, при яких гарантується відповідність створюваної системи вимогам, які містяться в ТЗ;

3) створення необхідних для функціонування системи підрозділів і служб;

4) терміни і порядок комплектування штатів і навчання персоналу.

2.10. У розділі «Вимоги до документування» наводять:

1) узгоджений розробником і Замовником системи перелік які підлягають розробці комплектів і видів документів;

2) перелік документів, що випускаються на машинних носіях;

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

2.11. У розділі «Джерела розробки» повинні бути перераховані документи та інформаційні матеріали, на підставі яких розроблялося ТЗ і які повинні бути використані при створенні системи.

3.Правила оформлення.

3.1. Розділи і підрозділи ТЗ повинні бути розміщені в порядку, встановленому в розд. 2 цього стандарту.

3.2. Номери аркушів (сторінок) проставляють, починаючи з першого листа, наступного за титульним листом, у верхній частині листа (над текстом, посередині) після позначення коду ТЗ на ІС.

3.3. На титульному аркуші поміщають підписи замовника, розробника і узгоджувальних компаній, які скріплюють печаткою. При необхідності титульний лист оформляють на декількох сторінках. Підписи розробників ТЗ і посадових осіб, що беруть участь в узгодженні і розгляді проекту ТЗ на ІС, поміщають на останньому аркуші.

Форма титульного аркуша ТЗ наведена в додатку 2. Форма останнього листа ТЗ наведено в додатку 3.

3.4. Титульний аркуш доповнення до ТЗ оформляють аналогічно титульного аркушу технічного завдання. Замість найменування «Технічне завдання» пишуть «Доповнення № ... до ТЗ на AC ...».

3.5. На наступних аркушах доповнення до ТЗ поміщають підставу для зміни, зміст зміни і посилання на документи, відповідно до яких вносяться ці зміни.

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

Порядок розроблення, погодження та затвердження ТЗ на ІС.

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

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

2. Необхідність узгодження проекту ТЗ з органами державного нагляду та іншими зацікавленими організаціями визначають спільно замовник системи і розробник проекту ТЗ на ІС,

Роботу з узгодження проекту ТЗ на ИC здійснюють спільно розробник ТЗ і замовник системи, кожен в організаціях свого міністерства (відомства).

3. Термін узгодження проекту ТЗ в кожній організації не повинен перевищувати 15 днів з дня його отримання. Рекомендується розсилати на узгодження екземпляри проекту ТЗ (копій) одночасно в усі організації (підрозділу).

4. Зауваження щодо проекту ТЗ повинні бути представлені з технічним обґрунтуванням. Рішення по зауважень повинні бути прийняті розробником проекту ТЗ і замовником системи до затвердження ТЗ на ІС.

5. Якщо при узгодженні проекту ТЗ виникли розбіжності між розробником і замовником (або іншими зацікавленими організаціями), то складається протокол розбіжностей (форма довільна) і конкретне рішення приймається в установленому порядку.

6. Узгодження проекту ТЗ дозволяється оформляти окремим документом (листом). В цьому випадку під грифом «Погоджено» роблять посилання на цей документ.

7. Затвердження ТЗ здійснюють керівники компаній розробника і замовника системи.

8. Копії, затвердженого ТЗ в 10-денний термін після затвердження надсилаються розробником ТЗ учасникам створення системи.

9. Узгодження та затвердження доповнень до ТЗ проводять в порядку, встановленому для ТЗ на ІС.

10. Зміни до ТЗ не допускається стверджувати після представлення системи або її черги на приймально-здавальні випробування.

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

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

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

Фактично технічний проект містить комплекс економіко-математичних і алгоритмічних моделей.

Повний комплект технічного проекту на систему включає в себе 10 документів:

1. Пояснювальна записка.

2. Функціональна й організаційна структура системи.

3. Постановка завдань і алгоритм рішення.

4. Організація інформаційної бази.

5. Альбом форм документів.

6. Система математичного забезпечення.

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

8. Розрахунок економічної ефективності системи.

9. Заходи з підготовки об'єкта до впровадження системи.

10. Відомість документів.

З наведеного переліку документ 3 "Постановка завдань і алгоритм вирішення" виконується для кожної окремої задачі, що включається в ЕІС, інші документи - загальні для всієї системи. Крім того, документи 1, 2, 5, 8 і 9 можуть розроблятися для окремих підсистем.

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

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

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

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

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

§ економіко-математична модель задачі (структурна і розгорнута форма подання);

§ вхідні оперативна інформація (характеристика показників, їхню соціальну значимість і діапазон зміни, форми подання);

§ нормативно-довідкова інформація (НДІ) - зміст і форми подання;

§ інформація, що зберігається для зв'язку з іншими завданнями;

§ інформація, що накопичується для наступних варіантів розв'язання задачі;

§ інформація щодо внесення змін (система внесення змін і перелік інформації, яка піддається змінам);

§ алгоритм вирішення задачі (послідовність етапів розрахунку, схема, розрахункові формули);

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

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

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

Інформаційна частина технічного проекту об'єднує документи 4 і 5. У документі "Організація інформаційної бази" відображаються: джерела надходження інформації та способи її передачі для вирішення першочергового комплексу функціональних завдань; сукупність показників, що використовуються в системі; склад документів, терміни і періодичність їх надходження; основні проектні рішення по організації фонду НДІ; склад НДІ, включаючи перелік реквізитів, їх визначення, значность, діапазон зміни і перелік документів НДІ; перелік масивів НДІ, їх обсяг, порядок і частота коригування інформації; пропозиції щодо уніфікації документації, контрольний приклад по внесенню змін до НДІ; структурна форма НДІ з описом зв'язку між елементами; вимоги до технології створення і ведення фонду; методи зберігання, пошуку, внесення змін і контролю, визначення обсягів і потоків інформації НДІ.

"Альбом форм документів" містить форми НДІ.

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

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

ВИСНОВОК

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

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

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

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

Список використаних джерел

1. Керівництво з вивчення дисципліни «Автоматизовані інформаційні системи» [Електронний ресурс]. - Москва, 2006. - Режим доступу:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Загл. з екрану.

2. Вікіпедія, вільна енциклопедія [Електронний ресурс] / Стаття «Інформаційна система» - Режим доступу: http://ru.wikipedia.org/wiki/Информационная система.

3. Комп'ютер прес: Інтернет-журнал. - Електрон. дан. - [Б. м, 2001]. - Режим доступу: http://compress.ru/article.aspx?id=12282.

4. Вендров А.М., «Проектування програмного забезпечення економічних інформаційних систем» / А.М. Вендров. - М .: «Фінанси і статистика», 2000. - 364 с.

5. «Технічне завдання на створення автоматизованої системи» / - М .: ГОСТ 34.602-89, 1990..

6. Грекул В.І. «Проектування інформаційних систем» / В.І. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - М .: Інтернет-університет інформаційних технологій, 2008.

Розміщено на Allbest.ru

подібні документи

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

дипломна робота, доданий 22.11.2015


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

звіт по практиці, доданий 16.04.2017


Життєвий цикл автоматизованих інформаційних систем. Основи методології проектування автоматизованих систем на основі CASE-технологій. Фаза аналізу і планування, побудови і впровадження автоматизованої системи. Каскадна і спіральна модель.

курсова робота, доданий 20.11.2010


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

дипломна робота, доданий 23.06.2015


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

презентація, доданий 14.10.2013


Поняття інформаційної системи. Етапи розвитку інформаційних систем. Процеси в інформаційній системі. Інформаційна система з відшукання ринкових ніш, по зниженню витрат виробництва. Структура інформаційної системи. Технічне забезпечення.

реферат, доданий 17.11.2011


Організація, архітектура і структура інформаційної системи. Показники ефективності її роботи. Цілі і завдання аналізу АСУ. Компоненти автоматизованих систем. Опис предметної області, вхідних і вихідних даних. Побудова діаграми прецедентів.

курсова робота, доданий 11.04.2014


Створення та організація автоматизованих інформаційних систем (АІС). Основні компоненти та технологічні процеси АІС. Стадії і етапи створення АІС з позиції керівництва організації. Розробка комплексів проектних рішень автоматизованої системи.

реферат, доданий 18.10.2012


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

презентація, доданий 14.10.2013


Аналіз предметної області, етапи проектування автоматизованих інформаційних систем. Інструментальні системи розробки програмного забезпечення. Роль CASE-засобів в проектуванні інформаційної моделі. Логічна модель проектованої бази даних.

1 грудня 2015 року відбулася відкрита захист створеної на замовлення Мінпромторгу Росії Автоматизованої інформаційної системи проектного управління (АІС ПУ). На захисті, що проходила під головуванням першого заступника міністра промисловості і торгівлі Російської Федерації Гліба Нікітіна, були присутні керівники департаментів міністерства, представники Міністерства економічного розвитку і Міністерства оборони Російської Федерації.

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

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

Система створена російським системним інтегратором компанією «Інлайн-Технолоджіс» із залученням вітчизняного розробника програмного забезпечення компанії «ЛМ-Софт». АІС ПУ розроблена на базі російської платформи 1С з використанням вільного програмного забезпечення та програмного забезпечення власної розробки.

За результатами вивчення функціональних можливостей системи позитивні відгуки були отримані як з боку керівництва і співробітників Мінпромторгу, так і з боку Міністерства економічного розвитку, відповідального за впровадження механізмів проектного управління в органах державної влади. Крім того, позитивні відгуки про можливості АІС ПУ були дані з боку промислових підприємств, які представили свої пілотні проекти в рамках розробки системи. Зокрема, позитивні відгуки про дослідної експлуатації АІС ПУ дали представники ФГУП «Криловський державний науковий центр», ВАТ «Науково-виробнича корпорація« Уралвагонзавод », Федерального казенного підприємства« Науково-дослідний інститут «Геодезія». Слід також зазначити, що живий інтерес до системи і зацікавленість в спільній співпраці в питаннях впровадження проектного управління проявили представники АТ «Гарнізон», що знаходиться у віданні Міністерства оборони, а також представники деяких банків з державною участю.

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

«Головною метою впровадження АІС ПУ є підвищення якості контролю та керованості, полегшення взаємодії між органами влади та виконавцями масштабних проектів. При розробці системи враховувалися, в першу чергу, галузеві стандарти, постанови і розпорядження Уряду, укази Президента і накази міністра промисловості і торгівлі, а також кращі вітчизняні та зарубіжні практики. Для АІС ПУ було спроектовано понад 600 компонентів, завантажено понад 20 000 довідників, словників і класифікаторів. В рамках подальших робіт з розвитку АІС ПУ планується інтеграція системи в якості однієї з підсистем створюваної в даний час Мінпромторгу Росії Державної інформаційної системи промисловості », - розповів Сергій Валуєв.

Впровадження методів проектного управління визначено одним з основних інструментів модернізації державного управління та закріплено в новій редакції «Основних напрямків діяльності Уряду Російської Федерації на період до 2018 року», яка була підписана головою уряду Дмитром Медведєвим.