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

Проект Постанови Уряду Російської Федерації"Про створення, розвиток та введення в експлуатацію, експлуатацію автоматизованої інформаційної системи проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади" та внесення змін до деяких актів Уряду Російської Федерації" (підготовлений Мінкомзв'язком Росії 15.02.2018)

Досьє на проект

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

З метою реалізації Положення про організацію проектної діяльності в Уряді Російської Федерації, затвердженому постановою Уряду Російської Федерації від 15 жовтня 2016р. N1050, Уряд Російської Федерації ухвалює:

1. Затвердити додані:

Положення про автоматизовану інформаційну систему проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади";

План заходів ("дорожню карту") щодо створення, розвитку та введення в експлуатацію, експлуатації автоматизованої інформаційної системи проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади" на 2018-2020 роки (далі - План заходів);

Зміни, що вносяться до деяких актів Уряду Російської Федерації.

2. Визначити:

Міністерство зв'язку та масових комунікацій Російської Федерації - державним замовником та оператором автоматизованої інформаційної системи проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади" (далі відповідно - АІСПД);

Федеральний проектний офіс - уповноваженим органом ведення АІСПД.

3. Федеральному проектному офісу, федеральним органам виконавчої влади, забезпечити:

а) реалізацію Плану заходів;

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

в) використання АІСПД у проектній діяльності.

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

5. Міністерству зв'язку та масових комунікацій Російської Федерації щокварталу, до 15-го числа місяця наступного за звітним кварталом, представляти в Уряд Російської Федерації доповідь про хід реалізації Плану заходів.

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

7. Передбачити виділення у 2018 році бюджетних асигнувань із резервного фонду Уряду Російської Федерації на фінансування заходів щодо створення АІСПД.

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

Затверджено
постановою Уряду
Російської Федерації

Положення
про автоматизовану інформаційну систему проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади"

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

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

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

в) інформаційна взаємодія постачальників інформації та користувачів інформації, що міститься в АІСПД;

г) оперативний та об'єктивний моніторинг реалізації проектів (програм);

д) взаємодія з громадянами з питань реалізації проектів (програм) та проектних ініціатив;

е) ведення електронних форм звітності;

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

2. Виконання завдань, зазначених у пункті 1 цього Положення, здійснюється за допомогою таких функцій АІСПД:

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

б) управління проектами (програмами), портфелем проектів (програм) в органах влади різного рівня за єдиною методологією, у тому числі:

облік та ведення (супровід) проектних пропозицій;

ініціювання проектів (програм), ранжування та формування портфеля проектів (програм);

підготовку проекту (програми);

реалізацію проекту (програми) та управління змінами проекту (програми);

завершення проекту (програми);

моніторинг реалізації проектів (програм);

аналіз, оцінку та інші контрольні заходи реалізації проектів (програм);

в) отримання відомостей про хід реалізації проектів (програм) із різних зовнішніх джерел;

г) використання електронної звітностіз проектної діяльності;

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

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

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

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

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

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

3. Учасниками інформаційної взаємодії є:

а) оператор АІСПД;

б) постачальники інформації в АІСПД;

в) користувачі інформації, що міститься в АІСПД.

4. Постачальниками інформації в АІСПД є:

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

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

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

6. Уповноважений орган з ведення АІСПД виконує такі функції:

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

б) здійснює моніторинг запровадження та функціонування АІСПД;

в) затверджує за погодженням з оператором АІСПД вимоги до програмного забезпечення АІСПД;

г) визначає за погодженням з оператором АІСПД напрями розвитку АІСПД;

д) здійснює методологічну підтримку функціонування та розвитку АІСПД.

7. Оператор АІСПД забезпечує:

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

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

в) прийом, зберігання, надання даних АІСПД;

г) цілісність та доступність даних АІСПД для учасників інформаційної взаємодії;

д) захист інформації та даних, створюваних та оброблюваних у рамках функціонування АІСПД;

е) розмежування прав доступу до учасників інформаційної взаємодії;

ж) підключення та (або) надання доступу до АІСПД;

з) обов'язковість обліку та реєстрації всіх дій та ідентифікації всіх учасників;

і) технологічна та інша взаємодія АІСПД із зовнішніми інформаційними системами;

к) методичну підтримку з питань технічного використання та інформаційного наповнення АІСПД;

л) завантаження та актуалізацію класифікаторів, довідників та іншої нормативно-довідкової інформації, що використовується в АІСПД, у федеральну Державну інформаційну систему "Єдина система нормативно-довідкової інформації".

8. Постачальники інформації в АІСПД забезпечують:

а) надання відомостей до АІСПД у встановленому порядку;

б) актуальність та достовірність відомостей, що надаються в АІСПД;

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

г) надання Уповноваженому органу з ведення АІСПД пропозицій щодо розвитку АІСПД.

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

10. Програмно-технічні засоби АІСПД повинні відповідати таким вимогам:

а) розташовуються біля Російської Федерації;

б) забезпечують розміщення інформації державною мовою Російської Федерації;

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

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

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

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

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

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

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

11. В АІСПД забезпечується єдність використовуваної нормативно-довідкової інформації.

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

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

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

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

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

17. У порядку та випадках, встановлених законодавством Російської Федерації, надання відомостей про проекти (програми) в електронній формі з використанням АІСПД здійснюється із застосуванням посиленого кваліфікованого електронного підпису.

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

Затверджений
постановою Уряду
Російської Федерації
від "__" _______ 2018 р. N _______

План
заходів ("дорожня карта") щодо створення, розвитку та введення в експлуатацію, експлуатацію автоматизованої інформаційної системи проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади" на 2018-2020 роки

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

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

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

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

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

ІІ. Загальна характеристика та основні результати

Чинником підвищення ефективності державного управлінняє перехід до проектного управління з використанням єдиної методології та автоматизації процесів проектного управління.

Результатами реалізації "дорожньої карти" є:

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

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

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

ІІІ. План заходів

	найменування заходу	Термін виконання	Вид документа	Відповідальні виконавці
1.	Розробка порядку надання інформації в АІСПД та здійснення інформаційної взаємодії з АІСПД	31.12.2018 р.	проект нормативного правового акта	Мінкомзв'язок Росії, Федеральний проектний офіс
2.	1 етап. Проектування, розробка та впровадження пілотного зразка, що включає основні модулі для управління пріоритетними та відомчими проектами, міграція даних із прототипу АІСПД	31.12.2018 р.
3.	2 етап. Введення в експлуатацію інформаційної системи та подальша експлуатація	31.12.2019 р.	наказ Мінкомзв'язку Росії, доповідь Уряд Російської Федерації	Мінкомзв'язок Росії, Федеральний проектний офіс, Учасники інформаційної взаємодії
4.	3 етап. технічний супровід, розвиток інформаційної системи	31.12.2020 р.	доповідь Уряд Російської Федерації	Мінкомзв'язок Росії, Федеральний проектний офіс, Учасники інформаційної взаємодії
5.	Федеральні органи виконавчої влади розпочали ведення проектів та програм в інформаційній системі	31.12.2018 р.	доповідь Уряд Російської Федерації
6.	Органи виконавчої влади суб'єктів Російської Федерації розпочали ведення проектів та програм в інформаційній системі	31.03.2019 р.	доповідь Уряд Російської Федерації	Мінкомзв'язок Росії, Федеральний проектний офіс, Учасники інформаційної взаємодії
7.	Органи місцевого самоврядування розпочали ведення проектів та програм в інформаційній системі	31.12.2019 р.	доповідь Уряд Російської Федерації	Мінкомзв'язок Росії, Федеральний проектний офіс, Учасники інформаційної взаємодії

Затверджено
постановою Уряду
Російської Федерації
від "__" _______ 2018 р. N _______

Зміни,
які вносяться до деяких актів Уряду Російської Федерації

1. Підпункт "а" пункту 2 Положення про інфраструктуру, що забезпечує інформаційно-технологічну взаємодію інформаційних систем, що використовуються для надання державних та муніципальних послуг та виконання державних та муніципальних функцій в електронній формі, затвердженого постановою Уряду Російської Федерації 8 червня 2011 р. N 451 " Про інфраструктуру, що забезпечує інформаційно-технологічну взаємодію інформаційних систем, що використовуються для надання державних та муніципальних послуг та виконання державних та муніципальних функцій в електронній формі "(Збори законодавства Російської Федерації, 2011, N 24, ст. 3503; N 44, ст. 6274;" № 49, статті 7284, 2012, № 39, статті 5269, № 53, статті 7938, 2013, № 27, статті 3612, № 41, статті 5188; 7218, 2014, N 30, ст.4318; N 48, ст.6876; N 50, ст.7113; 2016, N 34, ст.5247; 2017, N 41, ст. ) доповнити абзацом такого змісту:

"автоматизована інформаційна система проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади"."

2. У підпункті "б" пункту 4 Положення про державну автоматизовану інформаційну систему "Управління", затвердженому постановою Уряду Російської Федерації від 25 грудня 2009 р. N 1088 "Про державну автоматизовану інформаційну систему "Управління" (Збори законодавства України, 2010, N 1, статті 101, 2011, № 38, статті 5380, 2013, № 1, статті 65, № 48, статті 6259; 49, ст.6972) слова "і виконання пріоритетних національних проектіввиключити.

3. У позиції, що стосується основного заходу 4.2 додатка N 4 до державної програми Російської Федерації "Інформаційне товариство (2011 - 2020 роки)", затвердженої постановою Уряду Російської Федерації від 15 квітня 2014 р. N 313 "Про затвердження державної програми Російської Федерації" Інформаційне суспільство (2011 - 2020 роки) "Збори законодавства Російської Федерації, 2014, N 18, ст. 2159; 2015, N 9, ст. 1341; N 26, ст. 3896; 2016, N 44, ст. 6139; № 9, статті 1366; № 11, статті 1573; № 15, статті 2214; № 34, статті 5289; № 45, статті 6661; № 47, статті 7007; 2018, № 4, статті 623 ), у графі "Основні напрямки реалізації":

а) після абзацу тридцять другого "розвиток федеральної державної інформаційної системи "Федеральний ситуаційний центр електронного уряду";" додати абзац такого змісту:

"створення та розвиток автоматизованої інформаційної системи проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів державної влади";"

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

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

Огляд документа

Запропоновано Положення про АІС проектної діяльності "Хмарне рішення щодо автоматизації проектної діяльності органів держвлади".

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

Наведено План заходів ("дорожня карта") щодо створення, розвитку та введення в експлуатацію, експлуатації АІС на 2018-2020 роки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технологія	Ступінь автоматизації	Ступінь типізації	Ступінь адаптивності
проектування	проектування	проектування	проектування
Канонічне		Оригінальне	Реконструкція
Індустріальне авто-	Комп'ютерне		Реструктуризація
матизоване
(САБЕ-технології)
Індустріальне типо-		Типове складальне	Параметризація та ре-
			структуризація

2.5.1. Канонічне проектування ІС

Канонічне проектування інформаційних систем орієнтоване використання головним чином каскадної моделі життєвого циклу інформаційної системи. Стадії та етапи роботи такого проектування описані у стандарті ГОСТ 34.601-90.

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

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

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

• обстеження об'єкта та обґрунтування необхідності створення;
• формування вимог користувачів до ІС;
• оформлення звіту про виконану роботу та тактико-технічного завдання на розробку.

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

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

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

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

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

• розробка попередніх проектних рішень за системою та її частинами;
• розробка ескізної документації на ІВ та її частини.

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

• розробка проектних рішень за системою та її частинами;
• розробка документації на ІВ та її частини;
• розробка та оформлення документації на постачання комплектуючих виробів;
• розробка завдань на проектування у суміжних частинах проекту.

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

• розробка робочої документації на ІС та се частини;
• розробка та адаптація програм.

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

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

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

• виконання робіт відповідно до гарантійних зобов'язань;
• післягарантійне обслуговування.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Моделі діяльності організації створюються у двох видах: I) модель "як є" ("as-is") - відображає існуючі в організації бізнес-процеси; 2) модель «як має бути» («to-be») – відображає необхідні зміни бізнес-процесів з урахуванням застосування ІС.

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

• отримання порівняльних характеристикпередбачуваних для використання апаратних платформ, операційних систем, СУБД тощо;
• розробки плану робіт із забезпечення надійності інформаційної системи та її тестування.

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

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

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

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

Під час розробки технічного завдання необхідно вирішити такі задачи:

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

Типові вимоги до складу та змісту технічного завдання ГОСТ 34.602-89 наведено у табл. 2.5.

Таблиця 2.5.Склад та утримання технічного завдання ГОСТ 34.602-89

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

Продовження табл. 2.5

	вимоги до персоналу (чисельність користувачів, кваліфікація, режим роботи, порядок підготовки); показники призначення (ступінь пристосовуваності системи до змін процесів управління та значень параметрів); вимоги до надійності, безпеки, ергономіки, транспортабельності, експлуатації, технічного обслуговуваннята ремонту, захисту та збереження інформації, захисту від зовнішніх впливів, до патентної чистоти, зі стандартизації та уніфікації Вимоги до функцій (за підсистемами): перелік підлягають автоматизації завдань; тимчасовий регламент реалізації кожної функції; вимоги до якості реалізації кожної функції, до форми подання вихідної інформації, характеристик точності, достовірності видачі результатів; перелік та критерії відмов Вимоги до видів забезпечення: математичному (склад та сферу застосування математичних моделей і методів, типових та розроблюваних алгоритмів); інформаційному (склад, структура та організація даних, обмін даними між компонентами системи, інформаційна сумісність із суміжними системами, використовувані класифікатори, СУБД, контроль даних та ведення інформаційних масивів, процедури надання юридичної сили вихідним документам); лінгвістичному (мови програмування, мови взаємодії користувачів із системою, системи кодування, мови введення-виводу); програмному (незалежність програмних засобів від платформи, якість програмних засобів та способи його контролю, використання фондів алгоритмів та програм); технічному; метрологічному; організаційному (структура та функції експлуатуючих підрозділів, захист від помилкових дій персоналу); методичного (склад нормативно-технічної документації)
	Перелік стадій та етапів робіт. Терміни виконання. Склад організацій – виконавців робіт. Вид та порядок експертизи технічної документації. Програма надійності. Програма метрологічного забезпечення

Закінчення табл. 2.5

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

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

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

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

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

Розробка складається з наступних фаз:

• попередня розробка структури вхідних та вихідних даних;
• уточнення методів розв'язання задачі;
• розробка загального опису алгоритму розв'язання задачі;
• розробка техніко-економічного обґрунтування;
• розробка пояснювальної записки.

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

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

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

• 1. Уточнене технічне завдання на проектування та розробку АНС.
• 2. Специфікація кваліфікаційних вимогна АІС.
• 3. Комплект специфікацій вимог на функціональні програмні компоненти та опис даних.
• 4. Специфікація вимог на внутрішні інтерфейси компонент та інтерфейси із зовнішнім середовищем.
• 5. Опис системи управління базою даних, структури та розподілу програмних та інформаційних об'єктів у базі даних.
• 6. Проект керівництва із захисту інформації та забезпечення надійності функціонування АІС.
• 7. Попередній варіант керівництва адміністратора АІС.
• 8. Попередній варіант посібника користувача АІС.
• 9. Уточнений план реалізації проекту.
• 10. Уточнений план управління забезпеченням якості АІС.
• 11. Пояснювальна записка попереднього проекту АІС.
• 12. Уточнений контракт (договір) із замовником на детальне проектування АІС.

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

• 1. Попередній опис функціонування АІС.
• 2. Схема потоків даних між функціональними компонентами АІС.
• 3. Уточнена схема архітектури АІС, взаємодії програмних та інформаційних компонентів, організації обчислювального процесу та розподілу ресурсів.
• 4. Опис показників якості компонентів та вимог до них за етапами розробки АІС.
• 5. Звіт про техніко-економічні показники, графік реалізації проекту, розподіл ресурсів і бюджету.
• 6. Таблиця розподілу фахівців за компонентами та за етапами робіт.
• 7. Атестати розробників на право використання технології та засобів автоматизації розробки АІС.
• 8. Опис вимог до складу та форм результуючих документів за етапами робіт.
• 9. План налагодження програмних компонент, забезпечення методами та засобами автоматизації тестування.
• 10. Попереднє керівництво для детального проектування, програмування та налагодження компонентів АІС.
• 11. Попередній план продажу та впровадження.
• 12. Опис попередньої структури бази даних.

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

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

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

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

Таблиця 2.6.Склад та зміст технічного проекту

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

Закінчення табл. 2.6

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

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

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

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

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

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

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

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

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

2.5.2. Загальна характеристика CASE-засобів

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

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

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

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

Основні завдання CASE-засобів - відокремити початкові етапи (аналіз та проектування) від наступних та не обтяжувати розробників деталями середовища розробки та функціонування системи.

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

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

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

В основі більшості САБЕ-засобів лежать чотири головні поняття: "методологія", "метод", "нотація", "засіб".

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

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

Існує багато різних способів класифікації САБЕ-засобів. Розглянемо деякі з них.

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

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

• засоби проектування баз даних. Забезпечують логічне моделювання даних, генерацію структур БД;
• засоби управління конфігурацією програмного забезпечення. Підтримують програмування, тестування, автоматичну генерацію програмного забезпечення зі специфікацій;
• засоби документування;
• засоби тестування;
• засоби управління проектом. Підтримують планування, контроль, взаємодію;
• засоби реверсного інжинірингу. Призначені для перенесення існуючої системи у нове середовище.
• 2. Класифікація за підтримуваними методологіями проектування:
  • функціонально-орієнтовані (структурно-орієнтовані);
  • об'єктно-орієнтовані;
  • комплексно-орієнтовані (набір методологій проектування).
• 3. Класифікація за підтримуваними графічними нотаціями побудови діаграм:
  • з фіксованою нотацією;
  • з окремими нотаціями;
  • з найпоширенішими нотаціями.
• 4. Класифікація за рівнем інтегрованості:
  • допоміжні програми (Tools), що самостійно вирішують автономне завдання;
  • пакети розробки (Toolkit), що становлять сукупність коштів, які забезпечують допомогу однієї з класів програмних завдань;
  • набори інтегрованих засобів, пов'язаних загальною базою проектних даних – репозиторієм, що автоматизують усі роботи або їх частину на різних етапах створення АІС (Workbench).
• 5. Класифікація за режимом колективної розробкипроекту:
  • без підтримки колективної розробки;
  • зорієнтовані розробку проекту як реального времени;
  • орієнтовані режим об'єднання підпроектів.
• 6. Класифікація за рівнями дії:
  • верхні (Upper) або комп'ютерне планування. Використання верхніх CASE-засобів дозволяє побудувати модель, що відображає існуючу специфіку. Вона спрямована на розуміння загального та приватного механізмів функціонування, наявних можливостей, ресурсів, цілей проекту відповідно до призначення фірми. Ці засоби дозволяють проводити аналіз різних сценаріїв, накопичуючи інформацію для ухвалення оптимальних рішень;
  • середні (Middle). Вважаються засобами підтримки етапів аналізу вимог та проектування специфікацій та структури АІС. Основний результат використання середнього CASE-засобу полягає у значному полегшенні проектування систем. Такий засіб перетворює проектування на ітеративний процес роботи з вимогами до АІС. Крім того, середні CASE засоби забезпечують можливості швидкого документування вимог;
  • нижні (Lower). Підтримують системи розробки програмного забезпечення АІС, містять системні словники та графічні засоби, що виключають необхідність розробки фізичних специфікацій - є системні специфікації, які безпосередньо переводяться в програмні коди системи (при цьому автоматично генерується до 80% кодів). Головні переваги: ​​значне зменшення часу на розробку, полегшення модифікацій, підтримка можливостей з прототипами.

Сьогодні ринок програмного забезпечення наповнений різноманітними CASE-засобами практично будь-якого з перерахованих типів.

2.5.3. Типове проектування ІС

p align="justify"> Методи типового проектування інформаційної системи досить докладно розглянуті в літературі.

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

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

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

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

У табл. 2.7 наведено особливості різних класів типових проектних рішень.

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

Параметрично-орієнтоване проектування. Включає такі етапи:

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

Нижче наведено групи, на які діляться критерії оцінки ППП:

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

Таблиця 2.7.Переваги та недоліки ТПР

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

• зобов'язання постачальника щодо впровадження та супроводу пакета;
• оцінка якості пакета та досвід його використання;
• перспективи розвитку пакета

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

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

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

Спеціальна база метаданих – репозиторій – містить модель об'єкта автоматизації, на основі якої здійснюється конфігурування програмного забезпечення. Модель об'єкта автоматизації будується за допомогою спеціального програмного інструментарію (наприклад, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler).

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

Репозиторій містить базову (посилальну) модель ІС, типові (референтні) моделі певних класів ІВ, моделі конкретних АІС підприємств.

• Див: Гагаріна Л. Г., Кисельов Д. В., Федотова Є. Л.Розробка та експлуатація автоматизованих інформаційних систем: навчань, посібник / за ред. Л. Г. Гагаріної. М: ІД «ФОРУМ»: ІНФРА-М, 2007.

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

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

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

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

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

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

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

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

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

ВСТУП

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

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

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

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

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

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

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

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

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

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

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

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

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

ѕ Поетапне використання і т.п.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Необхідність узгодження проекту ТЗ з органами державного нагляду та іншими заінтересованими організаціями визначають спільно замовник системи та розробник проекту ТЗ на ІВ,

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

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://ua.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-засобів у проектуванні інформаційної моделі. Логічна модель проектованої бази даних.

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

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

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

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

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

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

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

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

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

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

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

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

Таблиця 2

1. Формування вимог до АС	1.1. Обстеження об'єкта та обґрунтування необхідності створення АС 1.2. Формування вимог користувача до АС 1.3. Оформлення звіту про виконану роботу та заявки на розробку АС
2. Розробка концепції АС	2.1. Вивчення об'єкту 2.2. Проведення необхідних науково-дослідних робіт 2.3. Розробка варіантів концепції АС та вибір варіанта концепції АС, що задовольняє користувача 2.4. Оформлення звіту про виконану роботу
3. Технічне завдання	3.1. Розробка та затвердження технічного завдання на створення АС
4. Ескізний проект	4.1. Розробка попередніх проектних рішень за системою та її частинами; 4.2. Розробка документації на АС та її частини
6. Робоча документація	6.1. Розробка робочої документації на систему та її частини 6.2. Розробка або адаптація програм
7. Введення в дію	7.1. Підготовка об'єкта автоматизації до введення АС у дію 7.2. Підготовка персоналу 7.3. Комплектація АС виробами, що поставляються (програмними та технічними засобами, програмно-технічними комплексами, інформаційними виробами) 7.4. Будівельно-монтажні роботи 7.5. Пуско-налагоджувальні роботи 7.6. Проведення попередніх випробувань 7.7. Проведення дослідної експлуатації 7.8. Проведення приймальних випробувань
8. Супровід АС	8.1. Виконання робіт відповідно до гарантійних зобов'язань 8.2. Післягарантійне обслуговування

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Політика конфіденційності персональних даних та умови обробки персональних даних

Ця Політика конфіденційності персональних даних діє щодо всіх персональних даних, які Компанія «ТЕКОРА» може отримати від Вас під час використання Вами сайтів компанії.

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

Надаючи Компанії «ТЕКОРА» інформацію, необхідну для ініціювання подальшої взаємодії, Ви погоджуєтесь на її використання відповідно до цієї Політики.

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

Компанія «ТЕКОРА» означає:

ЗАТ "ТЕКОРА", Юридична адреса: 119285 м. Москва, вул. Мосфільмівська, д.22, стор.1.

Поштова адреса: 117997, ДСП-7, м. Москва, вул. Профспілкова, д.65, оф.369.

Під обробкою персональних даних розуміються дії, передбачені законодавством Російської Федерації, зокрема Федеральним законом від 27.07.2006 N 152-ФЗ "Про персональні дані".

Надаючи свої персональні дані Ви погоджуєтесь на їх обробку, включаючи збір, запис, систематизацію, накопичення, зберігання, уточнення (оновлення, зміна), вилучення, використання, передачу, знеособлення, видалення, знищення Компанією «ТЕКОРА» з метою обробки Ваших замовлень та запитів , для здійснення діяльності щодо просування товарів, робіт, послуг або об'єктів інтелектуальної власності на ринку шляхом здійснення прямих контактів з Вами за допомогою засобів зв'язку, оцінки та аналізу сайту, аналізу купівельних особливостей та надання персональних рекомендацій; інформування Вас про акції, знижки та спеціальні пропозиції за допомогою електронних розсилок, а також з метою зв'язку з Вами (за електронній поштіта/або телефону).

Надаючи Компанії «ТЕКОРА» свої персональні дані, Ви можете бути впевнені, що вони не надаватимуться третім сторонам, за винятком випадків, коли це потрібно на користь ділових відносин між Вами та Компанією «ТЕКОРА». У деяких випадках Компанія «ТЕКОРА» зобов'язана передавати Ваші персональні дані третім особам згідно з вимогами законодавства. Наприклад, це може бути у випадку, коли існують підстави підозрювати у скоєнні злочину або неправомірному використанні веб-сайту компанії «ТЕКОРА».

Ви можете будь-якої миті відмовитися від отримання повідомлень електронною поштою, однак це не зачіпає передачу повідомлень електронною поштою, які потрібні з метою реалізації ділових відносин між Вами та компанією «ТЕКОРА».

Вказані веб-сайти містять декілька посилань на компанії, з якими Компанія «ТЕКОРА» підтримує ділові відносини. Компанія «ТЕКОРА» не несе відповідальності за відповідність вимогам захисту персональних даних щодо використання веб-сайтів партнерів Компанії «ТЕКОРА». Для отримання інформації про захист даних при відвідуванні цих сайтів, будь ласка, ознайомтесь із політиками конфіденційності на веб-сайтах відповідних компаній.

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

Цією згодою Ви підтверджуєте, що є суб'єктом наданих персональних даних, а також підтверджуєте достовірність даних.