робота по проектирыванию системы. Лаба1. Проектування пз за допомогою каскадної моделі
 Скачать 262.5 Kb.
|
|
15-номер дисципліни Лабораторна робота №1 Тема: Проектування ПЗ за допомогою каскадної моделі Мета роботи: Навчитись проектувати гіпотетичне програмне забезпечення, спираючись на принципи, що закладені в каскадній моделі. Завдання. 1 частина: 1. Ознайомтесь з основними принципами каскадної моделі. 2 частина: 1. Спроектувати гіпотетичне програмне забезпечення згідно етапів каскадної моделі. Кожний етап повинен бути супроводжений документацією. За індивідуальним завданням. Порядок виконання роботи 1 частина Інформація про каскадну модель життєвого циклу програмного забезпечення. Теорія. Каскадна модель життєвого циклу (модель водоспаду, англ. waterfall model) була запропонована у 1970 р. У. Ройсом. Принципова особливість каскадної моделі - перехід на наступну стадію здійснюється тільки після повного завершення роботи на поточній стадії, повернення на пройдені стадії не передбачається. Кожна стадія закінчується одержанням результатів, що є вхідними даними для наступної стадії, та випуском повного комплекту документації. Переваги: на кожній стадії формується закінчений набір проектної документації, яка відповідає критеріям повноти й узгодженості; виконання робіт у логічній послідовності дає змогу планувати терміни завершення всіх робіт і відповідні витрати. Недоліки: реальний процес створення ПЗ ніколи цілком не укладався в жорстку схему результати чергової стадії викликають зміни у проектних рішеннях, що прийняті на попередніх стадіях Схема моделі.  Короткий опис фаз.
2 частина Пояснення каскадної моделі на прикладі інформаційної системи – Електромонтажне підприємство. Дослідження концепції Фірма, що займається продажою своїх послуг та будівельних матеріалів. Завданням є відстежування фінансової сторони роботи компанії. Основна частина діяльності пов'язана з роботою з постачальниками. Фірма має певний набір постачальників, по кожному з яких відомі назва, адреса і телефон. У цих постачальників купуються матеріали. Кожна послуга і товар разом з назвою характеризується артикулом і ціною (вважаємо ціну постійною). Деякі з постачальників можуть поставляти однакові матеріали (один і той же артикул). Кожен факт купівлі матеріалів у постачальника фіксується у базі даних, причому обов'язковими для запам'ятовування є дата купівлі і кількість придбаних матеріалів. Системний розподіл Так як для обраної системи не потрібне ніяке додаткове апаратне забезпечення, цей пункт може бути пропущений. Серед вимог до комп’ютера, на якому буде запускатися проект необхідний буде звичайний офісний ПК та мережа інтернет. Визначення вимог Бізнес вимоги: Купівля матеріалів Купівля послуг Відстеження фінансових показників. Функціональні вимоги: Можливість купити матеріал у постачальника Перегляд назви, адреси та телефону постачальника Перегляд матеріалів та цін Перегляд дати купівлі матеріалу та його кількість Нефункціональні вимоги: Система має бути легкою у використанні Можливість пошуку матеріалів та активних послуг за назвою, постачальником та артикулом Конфіденційність даних зареєстрованих користувачів Портативність Розробка проекту Функції системи: Реєстрація користувача Пошук матеріалів(за назвою, за постачальником, за артикулом); Сортування(за кількістю, за ціною); Купівля матеріалів; Збереження даних до БД; Оновлення даних у БД. Сутності системи: Постачальники(Код постачальника, Назва, Адреса, Телефон). Матеріали (Код матеріалу, Назва, Артикул, Ціна, Примітка ). Постачання(Код постачальника, Код матеріалу, Кількість, Дата). Також на даному етапі розробляється ескіз інтерфейсу, який потім передається дизайнерам. Реалізація Всі раніше визначені функції розподіляються між розробниками: Ескіз передається дизайнерам Сутності передаються розробникам баз даних Функції передають розробникам Частіше всього функції діляться між декількома розробниками. Так у моєму прикладі один розробник може відповідати за реалізацію всіх методів пошуку та сортування, другий за роботу з даними, третій за реєстрацію та авторизацію. Процес установки Після реалізації всієї структури ПЗ проект передається замовнику для його установки та тестування. Замовнику необхідно перевірити проект під таким навантаженням, яке він очікує отримати. В даному випадку це буде додаток, який передається до фірми, де кваліфіковані спеціалісти його встановлять та налаштують базу даних, після чого ним можна буде користуватися. Експлуатація та підтримка Тепер ситуація змінилася. З'ясувалося, що ціна матеріалу та послуги може мінятися від постачання до постачання. Постачальники заздалегідь повідомляють вас про дату зміни ціни і про її нове значення. Треба зберігати не лише поточне значення ціни, але і усю історію зміни цін. Супровід Оскільки в прикладі правки є значними, проект перейде до наступного етапу, а саме виведення з експлуатації, та розпочнеться новий життєвий цикл. Після початку нового життєвого циклу необхідно пройтися знову по всім фазам розробки: Контрольні запитання Що таке модель конструювання? Моделі конструювання визначають комплекс операцій, які включають послідовність, результати (наприклад, вихідний код та відповідні unit-тести) та інші аспекти, пов’язані з загальним життєвим циклом розробки програмного забезпечення. Коли вперше виникла концепція каскадної моделі? Каскадна модель життєвого циклу була запропонована у 1970 р. У. Ройсом. Назвіть основні переваги каскадної моделі? на кожній стадії формується закінчений набір проектної документації, яка відповідає критеріям повноти й узгодженості; виконання робіт у логічній послідовності дає змогу планувати терміни завершення всіх робіт і відповідні витрати. Назвіть основні недоліки каскадної моделі? реальний процес створення ПЗ ніколи цілком не укладався в жорстку схему результати чергової стадії викликають зміни у проектних рішеннях, що прийняті на попередніх стадіях Висновок: під час виконання лабораторної роботи було визначено що таке каскадна модель, її етапи та опис етапів. Згідно індивідуального завдання було спроектоване гіпотетичне програмне забезпечення.  |