Розробка функціональної специфікації на розробку ПЗ. Методичні вказівки з Технологія програмування та створення програмних продуктів. Робота № 517797

Перехід до торгівельного партнера Binance

Розробка функціональної специфікації на розробку ПЗ

Інформація про навчальний заклад

ВУЗ:

Інші

Інститут:

Не вказано

Факультет:

Не вказано

Кафедра:

Кафедра САПР

Інформація про роботу

Рік:

2024

Тип роботи:

Методичні вказівки

Предмет:

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

Завантажити

Частина тексту файла (без зображень, графіків і формул):

ЛАБОРАТОРНА РОБОТА № 2 На тему: « Розробка функціональної специфікації на розробку ПЗ». Мета роботи. Розробити функціональну специфікацію на програмний продукт Стадії життєвого циклу розробки програм ЖЦРП може сильно відрізнятися від проекту до проекту і від керівника проекту до керівника проекту. Проте, зазвичай він складається з наступних стадій: Побудова життєвого циклу Попередній аналіз Аналіз побажань і вимог замовника Уточнення функціональних характеристик Створення технічного проекту (технічного завдання) Реалізація Системне тестування Послеpеалізационний огляд Супровід Функціональна специфікація Функціональна специфікація - це міст між початковим оглядом вимог і технічною специфікацією, що розробляється пізніше. Початковий огляд вимог виділяє те, ЩО система повинна робити, а технічна специфікація - це деталізоване проектування кожного елементу системи. Це остання стадія перед безпосереднім кодуванням. Отже, функціональна специфікація може розглядатися як транспорт, що переносить нас з точки A в точку B. Функціональна специфікація описує, ЩО система робитиме, але не як це буде виконано. Ця відмінність важлива. Функціональна специфікація також включає опис всіх головних функціональних модулів і обмеження, що враховуються. Призначення функціональної специфікації Як і будь-яка стадія ЖЦРП, функціональна специфікація може сильно змінюватися від проекту до проекту. У крупних комплексних проектах деякі моменти функціонального проектування можуть бути відкладені до стадії технічного проектування. У будь-якому випадку, основним завданням функціональної специфікації є надання користувачеві деякого документа з наступними критеріями: Документ повинен бути читабельний і добре логічно організований. Він повинен враховувати всі вимоги користувача. Він повинен відповідати на всі питання користувачів і розробників в області функціональної розробки Функціональна специфікація іноді є найбільш лякаючим аспектом формального циклу розробки...Особливо для програмістів, які ненавидять будь-що записувати. Після того, як програмісти дізнаються, що хоче користувач, у них з'являється природний імпульс негайно самостійно починати якщо не кодування, то технічне проектування. Hо нерозуміння на даній стадії може вилитися лихом після початку безпосереднього кодування. Зв'язок тут є ключовим елементом. Hо навіть самий хороший зв'язок між користувачами і програмістами не завжди є гарантією повного розуміння. Функціональна специфікація не повинна представлятися як паперова робота, яка повинна бути формально виконана. Якщо це відбувається, то документ не буде складений правильно і якісно. Користувач повинен розуміти, що документ, що складається, необхідний не тільки як формальність, але і як засіб прискорення, спрощення і поліпшення завдання, що розробляється. Формат документа Специфікація - це документ, що пояснює в бізнес-термінах те, що повинна робити система. Все в ньому повинно представляти інтерес для користувача. Документ не повинен бути переобтяжений технічними подробицями, структурами файлів й іншими технологічними деталями. Часто користувачеві цікавіше, які меню, екрани і звіти будуть представлені в програмі і як програма здійснюватиме перехід з однієї точки в іншу. Догyмент повинен складатися з логічних розділів типу короткого огляду системи, що супроводжується коротким описом головних фрагментів або функціональних об'єктів. Демонстрація планованих екранних форм повинна показувати основні напрями дій з головними функціональними об'єктами і модулями програми. Розділ опису звітів повинен містити всі звітні форми, які ви плануєте створювати. У великих системах основні модулі можуть бути розбиті на простіші з описом того, що ці простіші модулі робитимуть. Плануйте даний документ так, щоб користувач, який не зацікавлений в розгляді детальних особливостей системи, міг би прочитати тільки першу частину документа з описом основних функцій, що виконуються системою. Користувачі, зацікавлені в розгляді докладніших деталей, можуть продовжувати читати документ далі. Вимоги користувача Ваші специфікації повинні відповідати всім вимогам користувачів. Переконаєтеся, звернувшись знову до вашого початкового аналізу перед завершенням специфікації, що ви врахували всі вимоги і запити користувачів. Якщо вимога користувача не може бути задоволена, поясніть йому чому саме, а не просто виключите його із специфікації. Ви також повинні обговорити з користувачем обмежені ресурси, які є у користувача. 99% проблем, що виникають при програмуванні, можуть бути вирішені шляхом використання специфічних зовнішніх пристроїв, драйверів і сторонніх програм. Чи відповідає документ на всі питання? Після завершення генерації документа вам, очевидно, захочеться, щоб користувачі проглянули його і внесли які-небудь поправки і коментарі. Це їх перший погляд на те, що ви хочете створити. Коли користувачі завершать огляд документа, вам доведеться ще кілька разів зустрічатися з ними для обговорення їх поправок. Зміни і модифікації повинні бути негайно включені в останню версію специфікації, щоб технічна група - люди, які будуть складати технічну специфікацію, мали якомога більше інформації. Кінцевий варіант функціональної специфікації надалі практично не повинен змінюватися. Постарайтеся максимально повно скласти підсумковий документ. Будь-яка його зміна на подальших стадіях викличе ланцюгову pеакцію зміни всіх подальших стадій, на яких значно складніше вносити зміни, ніж на стадії створення функціональної специфікації. Чого потрібно уникати? Припустимо, функціональна специфікація розроблена, підписана і покладена на поличку. Вона може стати абсолютно даремною з ряду причин. Якщо функціональна специфікація із самого початку розроблялася з небажанням або з нерозумінням її значущості, то незалежно від того, скільки доповнень було внесено до неї і як довго над нею працювали, функціональна специфікація так і залишиться даремним документом. При непpавильному відношенні до розробки функціональної специфікації вона може бути погано написана, погано організована або, що найймовірніше, обтяжена томами опису непотрібних технічних подробиць. Кажучи іншими словами, працювати з таким документом буде неможливо. Якщо функціональна специфікація не буде максимальна повно описувати останні зміни, внесені до проекту на стадії спілкування із замовником, то технічна група проекту не матиме уявлення про останні зміни у функціональній специфікації (на основі якої технічні фахівці створюють технічну специфікацію). Це приведе до ухвалення технічною групою безлічі невіpних рішень, заснованих на невіpній або застарілій інформації, що спричинить серйозні втрати часу і засобів. Однією з найбільш небезпечних хвороб життєвого циклу розробки програм є синдром «ползyщего проекта» або «оползня». Він виявляється, коли функціональна специфікація неповно розглядає окремі аспекти проекту. В цьому випадку, у міру створення системи, користувачі, розглядаючи окремі готові модулі, проситимуть внести деякі вдосконалення, посилаючись на неясні описи даного модуля у функціональній специфікації. Поступово система набуватиме вигляду величезного динозавра в латочках, оскільки глобальні зміни розроблених структур програми проводити вже не можна, а зміни й вдосконалення необхідно буде вносити. До чого приведе дана ситуація, ви напевно вже здогадуєтеся... В пеpшy чергу, до перевитрат ліміту часу на створення окремих модулів і нестабільності роботи системи із-за випадання окремих функціональних шматків програми із строгої загальної схеми всієї системи. Hова техніка Іншою загальною проблемою сучасних життєвих циклів розробки програм є непpипустимо довгий проміжок часу між початковим запитом на створення ПЗ і кінцем розробки функціональної специфікації. Сьогоднішній світ бізнесу дуже динамічний. Вимоги до системи можуть змінитися за час початкового обстеження, з'ясування побажань і вимог замовника і складання функціональної специфікації. Щоб відстежувати дані ситуації, необхідно застосовувати сучасну техніку створення програмних і інструментальних засобів. Швидке макетування - метод проектування, розробки і зміни інтерфейсів користувача «на льоту». Кінцеві користувачі повинні тісно включатися в даний процес, оскільки розробка інтерфейсу разом з користувачем відбувається значно швидше, ніж без нього. Використання сумісної розробки дає можливість «підганяти» інтерфейс під користувача за декілька коротких сесій. Засоби Computer Aided Software Engineering (CASE) також грають величезну роль в сьогоднішніх інструментальних засобах розробки ПЗ. З могутніми CASE-засобами процес розробки програмних продуктів помітно спрощується. Проектувальники використовують CASE- засоби для створення і компоновки словників даних, потоків даних і дsагpам об'єкту, а в деяких випадках прототипів процесів обробки даних і функціонального коду. Проте, використання CASE-засобів розробки застосувань не дуже поширене у сфері розробки промислових програмних продуктів. Така ситуація склалася по двох причинах. По-перше, це обмеженість можливостей CASE-систем. Будь-яка система автоматизованого проектування має свою специфікую і ніколи не відображає всі вимоги того або іншого користувача на 100 %. По-друге, якщо CASE-система достатньо могутня і багатофункціональна, то вона вимагає великих часових витрат на її освоєння. А оскільки більшість проектів мають тенденцію бути «завеpшеними вчоpа», то необхідний час не може бути виділений. В кінці даної стадії, якщо Ви написали хорошу, таку, що легко розуміється, не переобтяжену і не порожню функціональну специфікацію, системний аналітик або технічна група зможе перейти до наступної стадії - створення технічної специфікації - грунтуючись на інформації, отриманій на всіх попередніх стадіях. Порядок виконання роботи Отримати індивідуальне завдання у викладача. Ознайомитись з «Вимогами замовника» на створення програмного продукту. Згідно методичних вказівок інструкції навчитись розробляти функціональну специфікацію на програмний продукт. Сформувати власний варіант документу «Функціональна специфікація програмного засобу». Оформити і захистити лабораторну роботу. Контрольні питання Назвіть стадії життєвого циклу програмного засобу. З яких етапів складається функціональна специфікація? Яку інформацію повинна містити функціональна специфікація? ... Функціональна специфікація (Огляд вимог, де потрібно описати те, що система повинна робити) Короткий огляд системи загальні положення Основною причиною ініціювання даної роботи є потреба в розробці ... , що виражається в: ... ... Негативні наслідки такого положення методичних матеріалів досить очевидні: ... призначення системи Система призначена для ... Основними учасниками та користувачами системи будуть: ... Додатковими учасниками системи можуть бути: ... Короткий опис головних модулів системи В результаті своєї роботи, система повинна ... Загальна схема роботи системи може мати наступний вигляд: Рис. 1.1. Приблизна схема системи в загальному вигляді. Пояснення до схеми. ... Функції системи Для фірм система дозволяє: ... Для Користувачів система дозволяє: ... Загальні функції системи: ... Загальні вимоги до функцій та учасників : ... ... ... ... Алгоритм функціонування системи Більш детальна схема функціонування системи та дії по її ініціалізації мають наступний вигляд : Рис. 1.2. Схема функціонування системи. Пояснення до схеми. ... Алгоритм підготовки системи до функціонування: Для компаній: Фірма, що зацікавлена в участі в системі, заходить через web-browser на “Welcome Page” web-сервера, заповнює анкету і посилає запит на під’єднання до SMILE; Web-server передає заповнену анкету клієнта в Tomcat; Сервлет обробляє анкету (перевіряє на наявність, тощо), створює в БД нового клієнта, генерує для нього Login & Password, виставляє закодовану QAP-аплікацію на ftp-server і посилає (мабуть через web-server) e-mail клієнту звіт про його профіль; ... ... Для клієнтів: Клієнт, який хоче шукати роботу за допомогою системи, заходить через web-browser на “Welcome Page” web-сервера, переходить на сторінку реєстрації Персон, заповнює анкету і посилає запит на під’єднання до SMILE; Web-server передає заповнену анкету юзера в Tomcat; Сервлет обробляє анкету (перевіряє на наявність, тощо), створює в БД нового юзера, генерує для нього Login & Password і посилає на e-mail юзера його реєстраційні дані; ... ... Алгоритм пошуку робочих місць в системі: Клієнт заходить на web-site і логується в систему. Тут він отримує можливість зайти в Stammdaen і оновити їх, або внести корективи. Клієнт вводить фільтр пошуку (на даному етапі не реалізується) і запускає пошук робочих місць. Web-server передає запит на Tomcat і система виконує Matching 1 по даних Stammdaten. Результати пошуку формуються у вигляді Web-сторінки, а також формуються звіти (для юзера і для клієнта) і запам’ятовуються в БД. Результати пошуку юзер може зберегти під своїм профілем. (- питання про мах обсяг інформації, яку може зберігати юзер під своїм аккаунтом?) ... ... Алгоритм оновлення пропозицій про наявність робочих місць: Пропозиція про наявність вільних робочих місць дійсна протягом певного періоду. Цей період встановлюється в XML файлі “JobPositionPosting”. В будь-який момент часу фірма може: добавляти до існуючих пропозицій нові пропозиції; достроково закривати відкриті пропозиції; продовжувати термін дії існуючих відкритих пропозицій; змінювати умови в існуючих пропозиціях. Всі зміни що до своїх пропозицій Фірма здійснює шляхом пересилання на ftp-server нового XML файлу “JobPositionPosting”. При цьому потрібно ідентифікувати які пропозиції існували і які зміни до них потрібно внести. Якщо з’являеться позиція з новою ID, тоді ми її просто додаємо до БД і виставляємо на web-сайт системи. ... ... Перелік даних, які зберігаються в системі Дані Фірм-клієнтів: Фірми-клієнти та їх Unternehmensdaten; Основний профіль фірми (Stammdaten); ... ... Дані Юзерів: Юзери та їх Unternehmensdaten; Основний профіль юзера (Stammdaten); ... ... Algorithms for Matchings Matching 1 (Stammdaten) Matching 2 (Hard Skills) Matching 3 (Soft Skills) Екранні форми системи Серверна частина системи буде мати приблизно такий перелік web-pages з екранними формами: “Welcome Page” з рекламною інформацією, горячими новинами та полями для Login&Password. Для Фірм-клієнтів – “Welcome Page” + Login; Page “Stammdaten”; Page “List of Positions”; ... ... Для Юзерів – шукачів роботи – “Welcome Page” + Login; Page “My Personal Info”; Page “My Stammdaten”; Page “My SoftSkills Profile” ; Page “My Reports” ; ... ... Для адміністратора системи – …currently not defined… Для інших учасників системи – …currently not defined… Опис звітів та звітних форм системи Базові умови. Всі звіти повинні пересилатись користувачам в наперед визначеному XML форматі для забезпечення їх сумісності зі стандартами HR-BA-XML. Всі учасники системи – і компанії і клієнти повинні автоматично отримувати усі звіти про їх активність в системі після кожної завершеної сесії роботи в системі. Звіти поділяються на Ручні – ті, які будуть генеруватись сервером по команді фірми/юзера/адміністратора/тощо ... ... Автоматичні – ті, які будуть генеруватись сервером автоматично по настанні якої-небуть заданої події ... ... Стандартні звіти. В процесі своєї роботи система буде генерувати наступний стандартний набір звітів для всіх її учасників. Для кожного звіту слід представити його орієнтовний вигляд. Для Фірм-клієнтів – Звіт про реєстрацію фірми в системі (автоматичний); Звіт про різні налаштування фірми на сервері (ручний) – можливо для майбутнього; ... ... Для інтернет-користувачів – Звіт про реєстрацію персони в системі (автоматичний); Звіт про введені на сервері Stammdaten юзера (на основі яких проводиться процедура “Matching 1”) (ручний); ... ... Для адміністратора системи – Звіт про поточну кількість учасників системи – фірми та персони; Звіт про поточну кількість актуальних пропозицій; ... ...

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

gorucho

13.11.2012 01:11-

Коментарі

Ви не можете залишити коментар. Для цього, будь ласка, або зареєструйтесь.

Ділись своїми роботами та отримуй миттєві бонуси!

Маєш корисні навчальні матеріали, які припадають пилом на твоєму комп'ютері? Розрахункові, лабораторні, практичні чи контрольні роботи — завантажуй їх прямо зараз і одразу отримуй бали на свій рахунок! Заархівуй всі файли в один .zip (до 100 МБ) або завантажуй кожен файл окремо. Внесок у спільноту – це легкий спосіб допомогти іншим та отримати додаткові можливості на сайті. Твої старі роботи можуть приносити тобі нові нагороди!

поділитись