ТОР 5 статей: Методические подходы к анализу финансового состояния предприятия Проблема периодизации русской литературы ХХ века. Краткая характеристика второй половины ХХ века Характеристика шлифовальных кругов и ее маркировка Служебные части речи. Предлог. Союз. Частицы КАТЕГОРИИ:
|
Організація розробки ІС. Канонічне проектування ІСОрганізація канонічного проектування ІС орієнтована на використання головним чином каскадної моделі життєвого циклу ІС. Стадії і етапи роботи описані в стандарті ГОСТ 34.601-90. Залежно від складності об'єкту автоматизації і набору завдань, що вимагають рішення при створенні конкретної ІС, стадії і етапи робіт можуть мати різну трудомісткість. Допускається об'єднувати послідовні етапи і навіть виключати деякі з них на будь-якій стадії проекту. Допускається також починати виконання робіт наступної стадії до закінчення попередньої. Стадії і етапи створення ІС, виконувані організаціями-учасниками, прописуються в договорах і технічних завданнях на виконання робіт: Стадія 1. Формування вимог до ІС. На початковій стадії проектування виділяють наступні етапи робіт: · обстеження об'єкту і обгрунтування необхідності створення ІС; · формування вимог користувачів до ІС; · оформлення звіту про виконану роботу і тактико- технічного завдання на розробку. Стадія 2. Розробка концепції ІС. · вивчення об'єкту автоматизації; · проведення необхідних науково-дослідних робіт; · розробка варіантів концепції ІС, що задовольняють вимогам користувачів; · оформлення звіту і затвердження концепції. Стадія 3. Технічне завдання. · розробка і затвердження технічног о завдання на створення ІС. Стадія 4. Ескізний проект. · розробка попередніх проектних рішень по системі і її частинам; · розробка ескізної документації на ІС і її частини. Стадія 5. Технічний проект. · розробка проектних рішень по системі і її частинам; · розробка документації на ІС і її частини; · розробка і оформлення документації на постачання комплектуючих виробів; · розробка завдань на проектування в суміжних частинах проекту. Стадія 6. Робоча документація. · розробка робочої документації на ІС і її частини; · розробка і адаптація програм. Стадія 7. Введення в дію. · підготовка об'єкту автоматизації; · підготовка персоналу; · комплектація ІС виробами (програмними і технічними засобами, програмно-технічними комплексами, інформаційними виробами), що поставляються; · будівельно-монтажні роботи; · пуско-налагоджувальні роботи; · проведення попередніх випробувань; · проведення дослідної експлуатації; · проведення приймальних випробувань. Стадія 8. Супровід ІС. · виконання робіт відповідно до гарантійних зобов'язань; · післягарантійне обслуговування. Oбстеження - це вивчення і діагностичний аналіз організаційної структури підприємства, його діяльності і існуючої системи обробки інформації. Матеріали, отримані в результаті обстеження, використовуються для: · обгрунтування розробки і поетапного впровадження систем; · складання технічного завдання на розробку систем; · розробки технічного і робочого проектів систем. На етапі обстеження доцільно виділити дві складові: визначення стратегії впровадження ІС і детальний аналіз діяльності організації. Основне завдання першого етапу обстеження - оцінка реального об'єму проекту, його цілей і завдань на основі виявлених функцій і інформаційних елементів об'єкту високого рівня, що автоматизується. Ці завдання можуть бути реалізовані або замовником ІС самостійно, або із залученням консалтингових організацій. Етап припускає тісну взаємодію з основними потенційними користувачами системи і бізнес-експертами. Основне завдання взаємодії - отримати повне і однозначне розуміння вимог замовника. Як правило, потрібна інформація може бути отримана в результаті інтерв'ю, бесід або семінарів з керівництвом, експертами і користувачами. Після закінчення цієї стадії обстеження з'являється можливість визначити вірогідні технічні підходи до створення системи і оцінити витрати на її реалізацію (витрати на апаратне забезпечення, закуповуване програмне забезпечення і розробку нового програмного забезпечення). Результатом етапу визначення стратегії є документ (техніко-економічне обгрунтування проекту), де чітко сформульовано, що отримає замовник, якщо погодиться фінансувати проект, коли він отримає готовий продукт (графік виконання робіт) і скільки це коштуватиме (для великих проектів має бути складений графік фінансування на різних етапах робіт). У документі бажано відбити не лише витрати, але і вигоду проекту, наприклад час окупності проекту, очікуваний економічний ефект (якщо його вдається оцінити). Орієнтовний зміст цього документу: · обмеження, риски, критичні чинники, які можуть вплинути на успішність проекту; · сукупність умов, при яких передбачається експлуатувати майбутню систему: архітектура системи, апаратні і програмні ресурси, умови функціонування, обслуговуючий персонал і користувачі системи; · терміни завершення окремих етапів, форма приймання/здачі робіт, ресурси, що притягаються, заходи по захисту інформації; · опис виконуваних системою функцій; · можливості розвитку системи; · інформаційні об'єкти системи; · інтерфейси і розподіл функцій між людиною і системою; · вимоги до програмних і інформаційних компонент ПЗ, вимоги до СУБД, що не буде реалізоване у рамках проекту. На етапі детального аналізу діяльності організації вивчаються завдання, що забезпечують реалізацію функцій управління, організаційна структура, штати і зміст робіт по управлінню підприємством, а також характер підлеглості вищестоящим органам управління. На цьому етапі мають бути виявлені: · інструктивно-методичні і директивні матеріали, на підставі яких визначаються склад підсистем і перелік завдань; · можливості застосування нових методів рішення завдань. Аналітики збирають і фіксують інформацію в двох взаємозв'язаних формах: · функції - інформація про події і процеси, які відбуваються у бізнесі; · сутності - інформація про об’єкти, що мають значення для організації і про яких щось відоме. При вивченні кожного функціонального завдання управління визначаються: · найменування завдання; · терміни і періодичність його рішення; · міра формализуемости завдання; · джерела інформації, необхідні для вирішення завдання; · показники і їх кількісні характеристики; · порядок коригування інформації; · діючі алгоритми розрахунку показників і можливі методи контролю; · діючі засоби збору, передачі і обробки інформації; · діючі засоби зв'язку; · прийнята точність рішення задачі; · трудомісткість рішення задачі; · діючі форми представлення початкових даних і результатів їх обробки у вигляді документів; · споживачі результатної інформації по завданню. Одній з найбільш трудомістких, хоча і завдань цього етапу, що добре формалізуються, являється опис документообігу організації. При обстеженні документообігу складається схема маршруту руху документів, яка повинна відбити: · кількість документів; · місце формування показників документу; · взаємозв'язок документів при їх формуванні; · маршрут і тривалість руху документу; · місце використання і зберігання цього документу; · внутрішні і зовнішні інформаційні зв'язки; · об'єм документу в знаках. За результатами обстеження встановлюється перелік завдань управління, рішення яких доцільно автоматизувати, і черговість їх розробки. На етапі обстеження слід класифікувати заплановані функції системи по мірі важливості. Один з можливих форматів представлення такої класифікації - MuSCoW [9]. Ця абревіатура розшифровується так: Must have - необхідні функції; Should have - бажані функції; Could have - можливі функції; Won't have - відсутні функції. Функції першої категорії забезпечують критичні для успішної роботи системи можливості. Реалізація функцій другої і третьої категорій обмежується часовими і фінансовими рамками: розробляється те, що необхідно, а також максимально можливе в порядку пріоритету число функцій другої і третьої категорій. Остання категорія функцій особливо важлива, оскільки необхідно чітко представляти межі проекту і набір функцій, які будуть відсутні в системі. Моделі діяльності організації створюються в двох видах: · модель "як є" - відбиває існуючі в організації бізнес-процеси; · модель "як повинно бути" ("to-be") - відбиває необхідні зміни бізнес-процесів з урахуванням впровадження ІС. На етапі аналізу необхідно залучати до роботи групи тестування для вирішення таких завдань: · отримання порівняльних характеристик передбачуваних до використання апаратних платформ, операційних систем, СУБД, іншого оточення; · розробки плану робіт по забезпеченню надійності інформаційної системи і її тестування. Залучення тестувальників на ранніх етапах розробки є доцільним для будь-яких проектів. Якщо проектне рішення виявилося невдалим і це виявлено надто пізно, то виправлення помилки проектування обходиться дуже дорого. Чим раніше групи тестування виявляють помилки в інформаційній системі, тим нижче вартість супроводу системи. Час на тестування системи і на виправлення виявлених помилок слід передбачати не лише на етапі розробки, але і на етапі проектування. Для автоматизації тестування слід використати системи відстежування помилок (bug tracking). Це дозволяє мати єдине сховище помилок, відстежувати їх повторну появу, контролювати швидкість і ефективність виправлення помилок, бачити найбільш нестабільні компоненти системи, а також підтримувати зв'язок між групою розробників і групою тестування (повідомлення про зміни по e - mail і тому подібне). Чим більше проект, тим сильніше потреба в bug tracking. Результати обстеження представляють об'єктивну основу для формування технічного завдання на інформаційну систему. Технічне завдання - це документ, що визначає цілі, вимоги і основні початкові дані, необхідні для розробки автоматизованої системи управління. При розробці технічного завдання необхідно вирішити такі завдання: · встановити спільну мету створення ІС, визначити склад підсистем і функціональних завдань; · розробити і обгрунтувати вимоги, що пред'являються до підсистем; · розробити і обгрунтувати вимоги, що пред'являються до інформаційної бази, математичного і програмного забезпечення, комплексу технічних засобів (включаючи засоби зв'язку і передачі даних); · встановити загальні вимоги до проектованої системи; · визначити перелік завдань створення системи і виконавців; · визначити етапи створення системи і терміни їх виконання; · провести попередній розрахунок витрат на створення системи і визначити рівень економічної ефективності її впровадження. Типові вимоги до складу і змісту технічного завдання приведені в таблиці 20.1.
Приклад. Розробити технічне завдання на створення програмної системи «Облік успішності студентів». Система призначена для оперативного обліку успішності студентів в сесію. Система використовується деканом, заступниками декана і співробітниками деканату. Відомості про успішність студентів повинні зберігатися впродовж усього терміну їх навчання і використовуватися при складанні довідок про прослухані курси і додатків до диплому.
Текст технічного завдання приведений нижче. 1. ВСТУП 1.1. Найменування програмної системи Повна назва системи «Облік успішності студентів». Коротка назва «Успішність». 1.2. Область застосування Системи обліку успішності студентів призначена для збору і зберігання інформації про хід здачі екзаменаційної сесії. Передбачається, що використовувати цю систему будуть співробітники деканату, декан і його заступники. Під час сесії потрібне отримання оперативної інформації про хід її здачі студентами, проте виконання такого контролю вручну вимагає багато часу. Автоматизована система обліку успішності дозволить поліпшити якість контролю здачі сесії з боку куратора і деканату і забезпечить отримання даних про динаміку роботи кожного студента, групи і курсу в цілому. Крім того, зберігання інформації про здачу сесій впродовж усього часу навчання дозволить здійснювати автоматичну генерацію довідок про прослухані курси і додатків до диплому випускника. 2. ОСНОВА ДЛЯ РОЗРОБКИ Система розробляється на основі навчального плану підготовки бакалавра з напряму підготовки 6.170101 «Безпека інформаційних і комунікаційних систем» у відповідності з завданням на курсову роботу з нормативної дисципліни «Технології програмування». 3. ПРИЗНАЧЕННЯ Розробка є атестаційною при підготовці бакалавра. Програмна система призначена для зберігання і обробки відомостей про успішність студентів навчальних груп факультету впродовж усього терміну навчання. Оброблені відомості про успішність студентів можуть бути використані для оцінки успішності кожного студента, групи, курсу і факультету в цілому. 4. ВИМОГИ ДО ПРОГРАМИ 4.1. Вимоги до функціональних характеристик 4.1.1. Система повинна забезпечувати можливість виконання наступних функцій: • ініціалізацію системи (введення списків груп, переліків дисциплін, що вивчаються, відповідно до навчальних планів і т. п.); • введення і корекцію поточної інформації про хід здачі сесії конкретними студентами; • зберігання інформації про успішність впродовж часу навчання студента; • отримання відомостей про поточний стан здачі сесії студентами. 4.1.2. Початкові дані: • списки студентів навчальних груп; • учбові плани кафедр - перелік предметів і контрольних заходів по кожному предмету; • розклади сесій; • поточні відомості про здачу сесії кожним студентом. 4.1.3. Результати: • підсумки здачі сесії конкретним студентом; • підсумки здачі сесії студентами конкретної групи; • відсоток успішності по усіх студентах групи при здачі конкретного пред-мета в цілому на даний момент; • відсотки успішності по усіх групах спеціальності на даний момент; • відсотки успішності по усіх групах курсу на даний момент; • відсотки успішності по усіх курсах і в цілому по факультету на даний момент; • список боржників групи на даний момент; • список боржників курсу на даний момент. 4.2. Вимоги до надійності 4.2.1. Передбачити контроль інформації, що вводиться. 4.2.2. Передбачити блокування некоректних дій користувача при роботе з системою. 4.2.3. Забезпечити цілісність інформації, що зберігається. 4.2.4. Час відновлення після відмови/ Час відновлення після відмови складається з часу перезапуску користувачем ОС, часу на запуск виконуваного файлу програми та часу на відновлення втрачених даних. 4.3. Вимоги до складу і параметрів технічних засобів 4.3.1. Система повинна працювати на персональних комп’ютерах. 4.3.2. Мінімальна конфігурація: • тип процесора Pentium і вище; • об'єм оперативного пристрою, що запам'ятовує, 32 Мб і більше. 4.4. Вимоги до інформаційної і програмної сумісності Система повинна працювати під управлінням сімейства операційних систем Win 32 (Windows 95, Windows 98, Windows 2000, Windows NT і т. п.). Для розробки використовується IDE Visual C++ 2008. 4.5. Умови експлуатації. Програма має зберігатися на диску у вигляді двох копій: еталонної та робочої. 5. ВИМОГИ ДО ПРОГРАМНОЇ ДОКУМЕНТАЦІЇ 5.1. Програмні модулі, що розробляються, мають бути документовані, т. е. тексти програм повинні містити усі необхідні коментарі. 5.2. Програмна система повинна включати довідкову інформацію про роботу і підказки користувачеві. 5.3. До складу супроводжуючої документації повинні входити: 5.3.1. Інструкція системного програміста. 5.3.2. Посібник користувача. 5.3.3. Графічна частина на трьох листах формату А1: 5.3.4.1. Схема структурна програмної системи. 5.3.4.2. Діаграма компонентів даних. 5.3.4.3. Форми інтерфейсу користувача. 6. ЕТАПИ РОЗРОБКИ 1. Розробка, узгодження технічного проекту – 1 тиждень. 2. Реалізація графічного інтерфейсу користувача системи – 2 тижня 3. Реалізація програмних модулів та алгоритмів системи – 2 тижня. 4. Тестування програмної системи та складання програмної документації - 2 тижня. 5. Приймання – здача з виправленням виявлених недоліків в програмі та програмній документації – 1 тиждень. 7. ПОРЯДОК КОНТРОЛЮ ТА ПРИЙМАННЯ Програма приймається комісією. Програма вважається придатною для експлуатації, якщо вона відповідає всім пунктам технічного завдання. Ескізний проект передбачає розробку попередніх проектних рішень по системі і її частинам. Виконання стадії ескізного проектування не є строго обов'язковим. Якщо основні проектні рішення визначені раніше або досить очевидні для конкретної ІС і об'єкту автоматизації, то ця стадія може бути виключена із загальної послідовності робіт. Зміст ескізного проекту задається в ТЗ на систему. Як правило, на етапі ескізного проектування визначаються: · функції ІС; · функції підсистем, їх цілі і очікуваний ефект від впровадження; · склад комплексів завдань і окремих завдань; · концепція інформаційної бази і її укрупнена структура; · функції системи управління базою даних; · склад обчислювальної системи і інших технічних засобів; · функції і параметри основних програмних засобів. За результатами виконаної роботи оформляється, узгоджується і затверджується документація в об'ємі, необхідному для опису повної сукупності прийнятих проектних рішень і достатньому для подальшого виконання робіт із створення системи. На основі технічного завдання (і ескізного проекту) розробляється технічний проект ІС. Технічний проект системи - це технічна документація, що містить загальносистемні проектні рішення, алгоритми рішення завдань, а також оцінку економічної ефективності автоматизованої системи управління і перелік заходів по підготовці об'єкту до впровадження. На цьому етапі здійснюється комплекс науково-дослідних і експериментальних робіт для вибору основних проектних рішень і розрахунок економічної ефективності системи. Склад і зміст технічного проекту приведені в таблиці 20.2.
На завершення стадії технічного проектування робиться розробка документації на постачання виробів, що серійно випускаються, для комплектування ІС, а також визначаються технічні вимоги і складаються ТЗ на розробку виробів, що не виготовляються серійно. На стадії " робоча документація " здійснюється створення програмного продукту і розробка усієї супроводжуючої документації. Документація повинна містити усі необхідні і достатні відомості для забезпечення виконання робіт по введенню ІС в дію і її експлуатації, а також для підтримки рівня експлуатаційних характеристик (якості) системи. Розроблена документація має бути відповідним чином оформлена, погоджена і затверджена. Для ІС, які є різновидом автоматизованих систем, встановлюють наступні основні види випробувань: попередні, дослідна експлуатація і приймальні. При необхідності допускається додатково проведення інших видів випробувань системи і її частин. Залежно від взаємозв'язків частин ІС і об'єкту автоматизації випробування можуть бути автономні або комплексні. Автономні випробування охоплюють частини системи. Їх проводять у міру готовності частин системи до здачі в дослідну експлуатацію. Комплексні випробування проводять для груп взаємозв'язаних частин або для системи в цілому. Для планування проведення усіх видів випробувань розробляється документ "Програма і методика випробувань". Розробник документу встановлюється в договорі або ТЗ. В якості додатка в документ можуть включатися тести або контрольні приклади. Попередні випробування проводять для визначення працездатності системи і вирішення питання про можливість її приймання в дослідну експлуатацію. Попередні випробування слід виконувати після проведення розробником відладки і тестування програмних і технічних засобів системи і представлення, що поставляються, ним відповідних документів про їх готовність до випробувань, а також після ознайомлення персоналу ІС з експлуатаційною документацією. Дослідну експлуатацію системи проводять з метою визначення фактичних значень кількісних і якісних характеристик системи і готовності персоналу до роботи в умовах її функціонування, а також визначення фактичної ефективності і коригування, при необхідності, документація. Приймальні випробування проводять для визначення відповідності системи технічному завданню, оцінки якості дослідної експлуатації і вирішення питання про можливість приймання системи в постійну експлуатацію.
Не нашли, что искали? Воспользуйтесь поиском:
|