Лабораторна робота №1 на тему Моделювання систем, Процеси керування
« Назад
Лабораторна робота № 1Тема: Моделювання систем. Процеси керуванняЦіль: Ознайомитися зі способами моделювання систем. Навчитися моделювати системи (Облік студентів, автоматизована система керування(АСК) роботи бібліотеки, АСУ роботи бухгалтерії, АСУ роботи складу, АСУ навчального плану, АСУ обліку кадрів ). Ознайомитися із процесами керування. Навчиться писати пропозиції по створенню ПЗ. (Облік студентів, автоматизована система керування, (АСУ) роботи бібліотеки, АСУ роботи бухгалтерії, АСУ роботи складу, АСУ навчального плану, АСУ обліку кадрів ).Теоретичні відомостіУ процесі формалізації вимог до системи та на етапі проектування система оглядається як сукупність компонентів і взаємозв'язків між ними. Для цього використовуються моделі системної архітектури, які в графічному виді надають всю організацію системи, тобто її компоненти й взаємозв'язки між ними. Архітектура системи звичайно представляється у вигляді блокової діаграми (блок-схеми), де блоки відповідають основним підсистемам, а існуючі зв'язки між підсистемами позначаються лініями зі стрілками, що з'єднують окремі блоки діаграми. Зв'язку можуть відповідати потокам даних, послідовності включення підсистем у роботу або які-небудь інші типи залежності. На мал. 1.1 представлена блок-схема основних компонентів системи сигналізації, що попереджає про несанкціоноване проникнення в житло. У табл. 2.1 наведений короткий опис підсистем, яким відповідають певні блоки на мал. 1.1. Мал. 1.1. Таблиця 1.1. Функціональні підсистеми системи сигналізації
На цьому рівні деталізації система розбивається на окремі підсистеми. Кожна підсистема, у свою чергу, може бути представлена як декомпозиція своїх функціональних компонентів. Це такі компоненти підсистеми, які, виходячи із призначення підсистеми, виконують яку-небудь одну функцію. На противагу цьому підсистема зазвичай виконує кілька функцій. Звичайно, декомпозицію підсистем (і самої системи) можна проводити по інших ознаках, наприклад конструктивним або технологічним. Історично склалося так, що модель системної архітектури використовується для вичленовування апаратних і програмних компонентів системи, які зазвичай розробляються паралельно. Разом з тим протиставлення "апаратні засоби— програмне забезпечення" у сучасних системах найчастіше недоречно й несуттєво. Оскільки практично всі системні компоненти мають певні обчислювальні можливості. Наприклад, машини, що зв'язують безліч комп'ютерів у єдину мережу, складаються з репитерів, мережних шлюзів і сполучних кабелів. Репитери й шлюзи мають процесори й програми, що управляють цими пристроями, і, звичайно ж, інші електронні компоненти. На рівні системної архітектури більш раціонально класифікувати підсистеми відповідно до виконуваними їх функціями, не акцентуючи спеціально увагу на тому, чи є вони апаратними або програмними компонентами. Питання про те, чи буде дана функція реалізована апаратно або програмно, часто вирішується на основі нетехнічних факторів, таких як час, необхідне для створення компонента, або виходячи з наявності на ринку промислових виробів підходящих готових пристроїв. Блок-схеми можна використовувати для подання систем будь-якого розміру, На рис. 1.2 показана архітектура значно складнішої системи керування польотами. Ця система містить кілька основних підсистем, які самі є системами великого розміру. Напрямок інформаційних потоків між підсистемами показано з'єднуючими їх лініями зі стрілками. Рис. 1.2. Архітектура системи управління політами Неможливо описати й стандартизувати всі роботи, виконувані проекту по створенню ПЗ. Ці роботи досить істотно залежать від організації, де розробка ПЗ, і від типу створюваного програмного продукту. Але в будь якому випадку більшість менеджерів відповідальні за виконання всіх або деяких з наведених нижче процесів керування.
Перша стадія програмного проекту може складатися з написання пропозицій по реалізації цього проекту. Пропозиції повинні містити опис цілей проектів і способів їх досягнення. Вони також зазвичай містять у собі оцінки фінансових і часових витрат на виконання проекту. При необхідності тут можуть обґрунтування для передачі проекту на виконання сторонньої організації або розроблювачів. Написання пропозицій - дуже відповідальна робота, тому що для багатьох організацій питання про те, чи буде проект виконуватися самою організацією або розроблятися за контрактом сторонньою компанією, є критичним. Неможливо дати яких-небудь рекомендацій з написання пропозицій, багато чого тут залежить від досвіду менеджера. Эйрон (Агоп) вважає цю роботу менеджера однієї з найважливіших серед інших виконуваних їм робіт. На етапі планування проекту визначаються процеси, етапи й отримані на кожному з них результати, які повинні привести до виконання проекту. Реалізація цього плану приведе до досягнення цілей проекту. Визначення вартості проекту прямо пов'язане з його плануванням, оскільки тут оцінюються ресурси, що вимагаються для виконання плану Контроль за ходом виконання робіт (моніторинг проекту) - це безперервний процес, що триває протягом усього строку реалізації проекту. Менеджер повинен постійно відслідковувати хід реалізації проекту й порівнювати фактичні й нові показники виконання робіт з їхньою вартістю. Хоча багато організацій мають механізми формального моніторингу робіт, досвідчений менеджер може скласти ясну картину про стадію розвитку проекту просто шляхом неформального спілкування з розроблювачем. Неформальний моніторинг часто допомагає виявити потенційні проблеми, які в явному виді можуть виявитися пізніше. Наприклад, щоденне обговорення ходу виконання робіт може виявити окремі недоробки в створюваному програмному продукті. Замість очікування звітів, у яких буде відбитий факт "пробуксовки" графіка робіт, менеджер може обговорити з фахівцями намічені програмістські проблеми й не допустити зриву графіка робіт. Протягом реалізації проекту звичайно відбувається кілька формальних контрольних перевірок ходу виконання робіт зі створення ПО. Такі перевірки повинні дати загальну картину ходу реалізації проекту в цілому й показати, наскільки вже розроблена частина ПО відповідає цілям проекту. Час виконання великих програмних проектів може займати кілька років. Протягом цього часу мети й наміри організації, що замовила програмний проект, істотно змінитися. Може виявитися, що розроблювальний програмний проект уже непотрібен або вихідні вимоги до створюваного ПО просто застаріли і їх необхідно кардинально змінювати. У такій ситуації керівництво організації-розроблювача може застосовувати рішення про припинення розробки ПО або про зміну проекту в цілому з тим, врахувати змінені цілі й наміри організації-замовника. Керівники - менеджери проектів зазвичай зобов'язані самі підбирати виконавців для своїх проектів. В ідеальному випадку професійний рівень виконавців повинен відповідати тій роботі, яку вони будуть виконувати в ході реалізації проекту. Однак у багатьох випадках менеджери повинні покладатися на команду розроблювачів, що далека від ідеальної. Така ситуація може бути викликана наступними причинами. Бюджет проекту не дозволяє залучити висококваліфікований персонал. У такому випадку за меншу плату залучаються менш кваліфіковані фахівці. Бувають ситуації, коли неможливо знайти фахівців необхідної кваліфікації як у самій організації-розроблювачі, так і поза нею. Наприклад, в організації "кращі люди" можуть бути вже зайняті в інших проектах. Організація хоче підвищити професійний рівень своїх працівників. У цьому випадку вона може залучити до участі в проекті недосвідчених або недостатньо кваліфікованих працівників, щоб вони придбали необхідний досвід і повчилися в більш досвідчених фахівців. Таким чином, майже завжди підбор фахівців для виконання проекту має певні обмеження й не є вільним. Разом з тим необхідно, щоб хоча б кілька членів групи розроблювачів мали кваліфікацію й досвід, достатні для роботи над даним проектом. У противному випадку неможливо уникнути помилок у розробці ПО. Менеджер проекту зазвичай зобов'язаний посилати звіти про хід його виконання як замовлення, так і підрядним організаціям. Це повинні бути короткі документи, засновані на інформації, що витягається з докладних звітів про проект. У цих звітах повинна бути та інформація, що дозволяє чітко оцінити ступінь готовності створюваного програмного продукту. Завдання: Написати пропозиції по створенню програмного забезпечення та намалювати архітектуру системи відповідно до власного варіанту. Варіанти:
З повагою ІЦ "KURSOVIKS"! |