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

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

Розробка програмного продукту

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

ВУЗ:

Інші

Інститут:

Не вказано

Факультет:

Комп’ютерні науки

Кафедра:

Не вказано

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

Рік:

2008

Тип роботи:

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

Предмет:

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

Завантажити

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

Ковівчак Я. В., Пелешко Д.Д., Кінаш Ю.Є. Технологія програмування та створення програмних продуктів КОНСПЕКТ ЛЕКЦІЙ Для студентів Інституту комп’ютерних наук та інформаційних технологій бакалаврського рівня підготовки по спеціальності «Комп’ютерні науки» (шифр - 0927) Затверджено на засіданні кафедри автоматизованих систем управління. Протокол № 8-03/08 від “06” березня 2008 р. Львів-2008 Ковівчак Я. В., Пелешко Д. Д., Кінаш Ю. Є. Технологія розробки електронних видань : Конспект лекцій з дисципліни «Технологія розробки електронних видань» для студентів бакалаврського рівня підготовки зі спеціальності 0927 «Видавничо-поліграфічна справа– Львів: Національний університет «Львівська політехніка», 2008. – 122 с. Висвітлено основні підходи до побудови електронних видань. Зокрема, поняття гіпертексту та вимоги до організації гіпертекстових документів. Приведено основні властивості та структуру графічних файлів націлених на використання в Web-документах. Розглянуто способи створення та обробки текстових, графічних, анімаційних, аудіо й відеокомпонентів електронних видань. Приведено основні програмні середовища створення компонентів мультимедійних видань. Детально висвітлено підходи до класифікації сучасних електронних видань. Відповідальний за випуск Шпак З.Я., к. т. н., доц. Рецензенти Медиковський М. О., д. т. н., проф. Лотошинська Н. Д., к. т. н, доц. Зміст I. Введення в розробку програмного забезпечення Складність інформаційних систем Що називається розробкою програмного забезпечення Криза програмного забезпечення Концептуальне моделювання Короткий звіт Вправи II. Життєві цикли програмного забезпечення Модель водоспаду Модель водоспаду із зворотнім зв'язком Виконання по документації Моделювання Покрокова розробка Збірка готових елементів Спіральна модель Короткий звіт Вправи III. Етапи розробки програмного забезпечення Введення Стратегічний етап Етап визначення вимог 4.1 Функціональні вимоги 4.2 Нефункціональні вимоги 5. Аналіз 6. Етап проектування 7. Етап реалізації 8. Етап тестування 9. Етап установки 10. Етап підтримки 11. Короткий звіт Вправи IV. Початок - стратегічний етап Дії стратегічного етапу Співпраця з клієнтом Можливості і контекст проекту Стратегічні рішення Вивчення доступності Оцінка рішення Оцінка вартості Чинники успіху Ефекти стратегічного етапу Короткий звіт Вправи V. Розпізнавання вимог і документація Труднощі у формулюванні вимог Методи ототожнення вимог Методи опису вимог Види вимог Вимоги перевірки Документ вимог Чинники успіху Короткий звіт Вправи VI. Побудова моделі Вимоги для конструкції моделі Аналітична модель Дії на етапі аналізу Функціональне розкладання Методологія, що використовується при створенні аналітичної моделі Документація вимог Чинники успіху аналізу Короткий звіт Вправи VII. Етап проектування Цілі проектування Специфікація аналізу результатів Проектування інтерфейсу Структуровані чарти/діаграми Складова організації даних Оптимізація проекту Фізична струтура системи Коректність і якість проекту Нефункціональні вимоги на етапі проектування Ефекти етапу проектування Детальний документ проекту Короткий звіт Вправи VIII. Розробка інтернет-програм Специфікація інтернет-програми Методи розробки інтернет-програм Об'єктно-орієнтована гіперсрсередовищна модель розробки (OOHDM) Метод розробки веб-сторінок Мова веб-моделювання Короткий звіт Вправи IX. БдБ і БдС системи Електронний бізнес Що таке інтернет-бізнес і електронний ринок? Інтернет-магазин Модель електронного бізнесу Платежі Безпечність Моделювання систем БдБ та БдС Архітектура багаторівневих програм Сервіс-орієнтована архітектура (SOA) Короткий звіт Вправи X. Реалізація Характеристики етапу реалізації Надійність програмного забезпечення Погрішність Транзакції Середовище реалізації Чинники успіху і результати етапу реалізації Короткий звіт Вправи XI. Тестування Етап тестування Перевірка Перегляди Аудит Інспекції Види тестів Процес тестування Тестування надійності Типи тестів на знаходження помилок Програми-інструменти Статичні тести Оцінка кількості помилок Чинники успіху, успіх тестування Короткий звіт Вправи XII. Оцінка програмного забезпечення Оцінка програмного забезпечення Оцінка складності в проектах Ефекти масштабування Оцінка вартості програмного забезпечення Конструктивна вартісна модель (COCOMO) Балова функціональна оцінка Метод випадків використання Короткий звіт. Вправи XIII. Управління конфігурацією ПЗ і версіями Управління конфігурацією ПЗ Елементи конфігурації ПЗ Угода позначень Зберігання елементів конфігурації Перегляди Реліз План управління конфігурації ПЗ Короткий звіт Вправи XIV. Якість програмного забезпечення Що таке якість програмного забезпечення? TQM – управління за якістю Якість у ISO Модель якості ISO-9126 Управління якістю Стандарти якості Незрілість і зрілість виробництва План гарантії якості ПЗ (SQAP) Короткий звіт Вправи XV. Управління проектом програмного забезпечення Завдання управління проектом Особи виробників програмного забезпечення Характеристики хорошого розробника ПЗ Робота в команді Управління підприємством по виробництву ПЗ Розвиток компанії по виробництву ПЗ Документація проекту Вимірювання производительности Складання графіків проекту Завдання управління проектом Інтерфейс проекту Планування проекту Управління ризиком Вимірювання процесів і продуктів Короткий звіт Вправи Вступ Введення в розробку програмного забезпечення Непрофесійний розробник програмного забезпечення завжди у пошуках магії, якого-небудь сенсаційного методу або інструмента, що обіцяє зробити розробку програмного забезпечення тривіальною. Характерна риса професійного розробника програмного забезпечення - знати, що ніякого універсального засобу не існує. Сучасне програмне забезпечення (ПЗ) стає складним, великим і залежить від капітальних витрат. Програмне забезпечення створюється великими командами професіоналів і представляє різні сфери інтересів, часто далекі від комп'ютерної науки. Питання, які виникли в процесі розробки ПЗ: Що робити зі складністю програмного забезпечення? Як організувати командну роботу? Як розумно спілкуватися в групі професіоналів різних дисциплін? Які методи можуть бути використані належним чином, щоб приготувати якісний і не дуже дорогий продукт в зазначений термін? Прогрмісти повинні дати відповіді на всі ці питання для успішної розробки ПЗ. 1. Складність інформаційних систем Сучасні інформаційні системи складні, їх розробка вимагає багато часу і великих капіталовкладень. Нажаль, вельми часто результати є не задовільними. Аналіз показує, що зі всіх проектів програмного забезпечення, що розробляються, тільки кожний третій завершується успіхом. Малюнок 1.2. Успіхи і невдачі розробки програмного забезпечення Причини складності програмного забезпечення численні і різні. Наприклад: проблема великої кількості напрямків в інформаційних технологіях складнощі спілкування членів команд різних професій динамічні зміни в технологіях і доступних технічних інструментах зміна вимог користувачів і невпевненість в розробці вимог Малюнок 1.2.2. Причини Складності ІТ-проекту. 2. Розробка програмного забезпечення Розробка ПЗ є нелегке заняття і воно часто завершується невдачею. Тому виникають такі питання: 1.Що потрібно зробити, щоб збільшити шанс успіху проекту ПЗ? 2.Як бути впевненим, що результат роботи задовольнить користувача? 3.Як перевірити безпомилковість програмного продукту? 4.Як визначити вимоги до продукту, щоб він був зрозумілий людям без досвіду роботи з комп'ютером, але в той же час зробити вимоги достатніми для можливості моделювання і програмування? Програмотехніка намагається відповісти на ці та інші питання. Програмотехніка - це практична дисципліна, яка пов'язана зі всіма етапами великої розробки інформаційних систем. Можливості програмотехніки досить широкі. Виділимо декілька аспектів: Методи управління в розробці ПЗ Технології планування, ціни, розклад і моніторинг розробки ПЗ Аналіз і методи проектування Технології підвищення надійності програмного забезпечення Методи підготовки технічної і призначеної для користувача документації Процедури контролю якості Методи зменшення витрат на підтримку, усунення помилок, модифікації і розширення можливостей ПЗ Технології командної роботи і філософські чинники, які впливають на роботу Криза програмного забезпечення Декілька останніх років ми спостерігаємо феномен, який назвають кризою ПЗ. Під цим ми розуміємо цілий ряд труднощів під час розробки ПЗ не дивлячись на всі сучасні технології і високі ціни продукції. Основна причина кризи ПЗ - це складність продуктів комп'ютерної науки і процесу розробки. Серед невід'ємних причин кризи ПЗ: Суперечності між очікуваною відповідальністю ІС і їх ненадійністю. Це результати складності систем і не ідеальних методів їх створення. Дорога підтримка. Нечасте повторне використання вже існуючих проектів і компонентів ПЗ, їх низький рівень. Довгий і дорогий цикл розробки ПЗ, великий шанс провалу проекту. Довгий і дорогий життєвий цикл інформаційних систем і необхідність робити часті зміни. Розмаїття мов програмування. Залежність результатів проектування від швидких змін мов пристроїв, методів, довгий і ненадійний період підтримки. Залежність компаній від комп'ютерних систем і прикладних технологій обробки інформації. Проблеми з інтеграцією готових комонентів ПЗ різних команд. Проблеми з удосконаленням існуючих і робочих систем для того, щоб задовольняти нові вимоги техніки. Розробники ПЗ і менеджери намагаються здійснювати певні кроки для того, щоб мінімізувати дію вищевказаних факторів. Важливі методи для обмеження кризи ПЗ: Застосування різних методів і інструментів ,що полегшують роботу зі складними системами. Використання методів підтримки для аналізу нових проблем ,..що полегшує процес. Процедури розробки ПЗ повинні бути систематичними, спланованими і керованими. Переконання виробників і покупців, що розроблена систем високої якості вимагає професійного підходу. 4.Концептуальне моделювання Важливий шлях обмеження кризи ПЗ - це розробка концептуальної моделі. Люди,що проектують і програмують повинні концептуалізувати проблему. Базовий процес розробки завершується в людській голові і не вимагає використання якоїсь мови програмування. Зміст концептуального моделювання і концептуальної моделі полягає в обдумуванні і представленні по'язаного з розробкою ПЗ. Такі моделі відображають реальні процеси моделювання інформації, процеси обробки інформації, структуру даних і програм. Малюнок 1.5.1. Концептуальне моделювання. Життєві цикли програмного забезпечення Існують наступні моделі розробки ПЗ: класична модель водоспаду, покрокова модель, збірка по частинах, модель спіралі та ін. Розробка і експлуатація ПЗ - процес, який повинен бути систематизований. Для того ,щоб це відбулося потрібно сформулювати безлічі моделей циклу життя програмного забезпечення. Ці моделі представляють етапи життя програмного забезпечення, визначають дії, що проводяться на конкретному етапі, розписують черговість виконання цих етапів. Цикли життя програмного забезпечення дають змогу планувати роботу, ведучи послідовне планування і контролюють виконання. Модель водоспаду Модель водоспаду, відома також як каскадна модель або лінійна модель, є класичною моделлю циклу життя програми. Модель була запропонована по аналогії з методами, що використовуються в інших технічних дисциплінах, наприклад в проектуванні будівель. Конструкція моста починається з визначення основних інструментів, потрібних для його будівництва, а потім формулюється деталі для того, щоб досягти цілі. Наступний крок - спроектувати міст. За цим слідує будівництво і тестування. Останній етап полягає в підтримці будови. Малюнок 2.2.1. Каскадна модель життєвого циклу програмного забезпечення. Каскадна модель вводить наступні цикли розробки програмного забезпечення: етап визначення вимог ( формулюються цілі і деталі для майбутньої системи) етап проектування ( деталі проекту розвиваються для того, щоб забезпечити відповідні вимоги) етап реалізації/написання коду і тестування модулів ( реалізується і тестується дизайн в даному програмному середовищі) етап тестування ( відбувається об'єднання модулів і тестування всієї системи) етап підтримки ( замовник використовує продукт, а виробник його підтримує, вносить зміни і розширює функціональність). Існують іншші розбиття циклів. Ці розбиття можуть враховувати більше або менше деталей. Але найважливішим залишається - лінійність цього процесу. Під лінійністю розуміємо послідовне виконання етапів. У каскадній моделі представлені такі етапи: стратегічний етап ( здійснюється перед формальним ухваленням рішень. На цьому етапі ухвалюються деякі стратегічні рішення про майбутню роботу. Цей етап вимагає як мінімум найзагальнішого формулювання вимог). етап аналізу ( будується логічна модель системи). етап документації ( готується призначена для користувача документація. Документація виготовляється паралельно з ПЗ. Цей етап може починатися одночасно з формулюванням вимог. Вважається, що інструкція користувача є хорошою документацією для вимог. Останнні зміни в документації відбуваються установки). етап установки ( система передається користувачеві). Переваги і недоліки моделі Основна перевага каскадної моделі - керованість. Модель полегшує планування і моніторинг. Серед недоліків є наступні: Необхідність дотримуватись встановленого порядку проведення робіт. Програмісти віддають перевагу вільнішому стилю роботи. Підвищення ціни наслідків помилок, зроблених на різних етапах. Помилки, зроблені на етапі формулювання вимог, будуть виявлені лише на етапі перевірки або навіть на етапі підтримки. Вартість цих помилок може значно перевищити вартість помилок, зроблених протягом етапу реалізації. Довгий період, протягом якого немає контакту з клієнтом. Тільки стратегічний етап, формулювання вимог і етапу аналізу здійснюються за участю клієнта. Дизайн, реалізація і тестування повністю покладаються на компанію. Тому існує ризик втрати зацікавленості клієнта. 2. Модель водоспаду із зворотнім зв'язком Для того, щоб зменшити негативні наслідки каскадної моделі, які полягають у відсутності можливості виправлень помилок, зроблених на попередніх етапах, з'явилася модель із зворотнім зв'язком. Концепція полягає в тому, що можна повернутися до попередніх етапів, якщо виникає така необхідність. У семантичній формі можемо представити підхід таким чином. Малюнок 2.3.1. Модель водоспаду із зворотнім зв'язком. Документоване виконання Модель була спочатку введена армією США. Ця організація завжди вкладала великі суми у виробництво ПЗ. У сімдесятих роках минулого століття призначення грошових коштів було пов'язане із завданням на Зоряні Воєни. Було оцінено, що програмне забезпечення, потрібне для завдання, буде довжиною в мільйони рядків програмного коду. Програми були написані на мові Ada. Армія США весь час доводила, що здатна працювати на дуже складних проектах. Ця організація була причетна до процесу розвитку ПЗ і нових технологій. Деякими з результатів були стандарти DOD STD 2167 і DOD STD 2167a, які описують необхідні методи розробки ПЗ для армії. Життєвий цикл програм, описаний в документах, називається документованим виконанням. Це каскадна модель, що складається з декількох послідовних етапів. Ці документи будуть потрібні для подальшої розробки. Клієнт забезпечується документами, і лише після схвалення цих документів можлива розробка наступного етапу. Переваги і недоліки моделі Переваги моделі такі ж, як у каскадній моделі, тобто можливість планування, опрацьовування розкладу і моніторинг проекту. Новою перевагою є здатність зупинити розробку проекту в одній компанії і перенести її в іншу разом зі всім комплектом документів. Недоліки моделі такі ж, як у каскадної моделі. Ще одним недоліком є: потрібно вкладати більше інвестицій в роботу з підготовки документів (наприклад ті, що відповідають стандарту DOD STD 2167, складають більше 50% всього робочого навантаження); потрібні паузи в розробці ПЗ для перевірки документів клієнтом. Деякі організації, наприклад IEEE, пропонують свої власні стандарти для документованого виконання програмних проектів. Прототипування Всі описані вище методи розробки проектів мають суттєвий недоліки – висока вага помилок, зроблених на етапі формулювання вимог. Тому рекомендується спочатку створити модель перед розробкою систем, для якої формулювання є дуже просте, а потім її модифікувати.Що протягом розробки є дороге або зовсім неможливе (наприклад, для космічних програм). Типовим прикладом систем, які можуть прототипуватися, - інформаційні системи, які обробляють дані роботи організації за нескладними алгоритмами, тобто здійснюють зберіганням даних, їх пошук на виконання простих операцій. Такі системи виконують функції, які раніше виконувалися без комп'ютера. Проте, інформаційні системи дають змогу вводити нові функції, неможливі без комп'ютерів: дуже складні аналізи, виробнича оптимізація, підтримка ухвалення рішення і автоматизоване управління виробництвом. Точне визначення вимог до нових функцій може бути дуже важким. Прототипування – це модель, яка прагне мінімізувати ризик помилок у формулюванні вимог. Ця модель включає: загальне формулювання вимог розробку прототипу перевірку прототипу клієнтом повне формулювання вимог реалізацію повної системи з використанням каскадної моделі Головна мета розробки прототипу - краще формулювання вимог, тобто: знаходження відмінностей між побажаннями клієнта і розробника виявлення відсутніх функцій виявленняя найбільш складних операцій формулювання вимог по деталізації Переваги і недоліки моделі Перевагами розробки прототипу є: можливість дуже швидкої демонстрації робочого варіанту системи можливість тестування і часткового використання системи до її повної розродки Головний недолік - додаткове робоче навантаження на розробку прототипу. Крім того, може виникнути помилкове уявлення про низьку вартість продукту, викликане низькою ціною прототипу. Слід зазначити, що прототип – це частина майбутньої системи. Передбачається, що після перевірки прототипу клієнтом розробка повної системи розпочинається з початку. На практиці ж буває, що деякі добре зроблені частини можуть бути використані для подальшої розробки. Проте, протягом розробки прототипу ми повинні мати на увазі, що метою повинна бути його швидка розробка, а не надійність чи ефективність. Методи створення прототипу: Часткова реалізація ( тільки частина вимог виконана. Прототипуються лише найважчі вимоги). Мови високого рівня (Smalltalk, LISP, Prolog, мови подальших поколінь, мови формальної функціональної специфікації) Використання готових компонентів. Генератори інтерфейсу користувача ( реалізація прототипу часто обмежується розробкою інтерфейсу користувача). Швидке прототипування ( прототип може включати всі функції, використовувати ті ж методи, які будуть застосовані для повного створення системи. Деякі з етапів, наприклад, етап перевірки, ігноруються, що робить процес розробки коротшим. Тому різниця між прототипом і останньою версією системи полягає в надійності). Робота на папері ( це швидкий і зручний метод розробки інтерфейсу користувача, який замовники, зазвичай, високо цінують). Покрокова розробка Покрокова розробка починається з формулювання вимог і розробки базового проекту всієї системи. На наступному кроці вибираються деякі функції. Вони реалізуються каскадною моделлю і відбувається опис їх реалізації. Протестувавши реалізовану частину її відправляють замовнику. Малюнок 2.6.1. Покрокова розробка. Переваги і недоліки моделі Переваги: менші часові розриви у взаємодії із замовником можливість більш швидкого використання частин системи гнучкість при затримках в роботі якщо реалізація однієї частини затримується, це не зупиняє весь проект, це мотивує розробника працювати над іншими частинами швидше. Недолік моделі - додаткова вартість, необхідна для незалежної реалізації частин системи. Практично неможливо зробити повністю незалежний набір функцій. При цьому може виникнути необхідність реалізувати скелети модулів, тобто моделі з інтерфейсами, що узгоджені зі всім системним інтерфейсом але не реалізовують їх функції до кінця. Реалізація цих модулів вимагає додаткового робочого навантаження і збільшує вірогідність помилок. 6. Збірка готових елементів Модель збірки готових елементів акцентує увагу на можливості зменшити капітал, що витрачається на розробку шляхом максимізації схожості створеного ПЗ із вже існуючим. Вже існуючі елементи можуть використовуватися на різних стадіях розробки. Зазвичай це етап реалізації. Приклади використовуваних елементів: бібліотеки мови четвертого покоління, в яких інструкції обробляються як посилання на вбудовані бібліотеки повні програми, наприклад браузер допомоги в MS Windows Останнім часом підвищився інтерес до використання готових елементів на етапах аналізу і дизайну. CASE -Інструменти полегшують використання елементів, створених в інших проектах. Деякі компанії стверджують, що вони можуть використовувати до 90% готових продуктів. Очевидно, що можливість повторного використання залежить від схожості системних компонентів. Деякі компанії пропонують так званий інструментарій дизайну. Це вже готові методи для банків, страхових компаній і інших підприємств. Моделі реалізовуються у вигляді CASE -інструментарію. Є два методи збірки готових компонентів: придбання у зовнішніх постачальників розробка біжучого проекту з розрахунком на його багатократне використання в наступних проектах Переваги і недоліки моделі Переваги використання готових компонентів: висока надійність, - готові компоненти добре перевірені на практиці зменшення ризику ефективне використання експертів стандартні вимоги. Готові компоненти реалізовувалися відповідно до деяких стандартів, які повинні бути задоволені в поточному проекті. можливість зменшення ціни. Вартість нових компонентів зазвичай менша, ніж вартість розробки "з нуля". Недоліками моделі є: додаткова вартість створення компонентів для подальшого використання ( компоненти системи повинні бути розроблені для користування . Вартість інвестицій може не відшкодуватися в майбутньому). Залежність від одного постачальника ( постачальник може перестати розробляти бібліотеку або не модифікувати її під нові вимоги ПЗ чи нову апаратуру). Недолік інструментів, що підтримують роботу ( у разі CAD/CAM, які, як було згадано вище, служать в інших дисциплінах тієї ж мети, що і CASE, мають можливість використання бібліотек готових компонентів. Інструменти CASE підтримували в обмеженому об'ємі цей вид роботи до останнього часу. Сучасні інструменти кращі, але розробка нових все ще необхідна). 7.Модель спіралі Модель спіралі запропонував Boem в 1998. Модель містить в собі чотири первинні циклічні етапи: аналіз розробка оцінювання планування Малюнок 2.8.1 Модель спіралі. На першому етапі формулюються основні складові елементи нової системи. Вони аналізуються, з врахуванням ризику. Проблеми аналізу складових елементів обговорюються на наступному кроці стратегічного етапу проекту. Етап також може передбачати прототипування. На другому етапі створюється версія системи, грунтуючись на каскадній моделі. На етапі оцінювання версію оцінює клієнт. Якщо оцінка не задовільна, починається новий цикл. На етапі планування формулюються головні цілі виробництва. Детальніше модель спіралі можна розглянути на мал. 2.8.2. Мал.2.8.2. III. Етапи розробки програмного забезпечення Етап - це період між основними пунктами в процесі, в якому формуються добре описані завдання, презентуються готові робочі продукти і приймаються рішення про перехід на наступний етап. На малюнку нижче показані всі етапи в методі RUP. Малюнок 3.2.1. Життєві цикли ПЗ RUP. 1. Стратегічний етап Мета стратегічного етапу полягає в тому, щоб описати проект з точки зору клієнта. Всі цілі можуть здаватися іноді очевидними. Проте, спроба визначити їх зазвичай дозволяє уникати можливого непорозуміння між клієнтом і виробником. Крім того, навіть якщо цілі ясні для всіх людей, залучених до стратегічного етапу, вони не будуть очевидні для людей, які працюють на подальших стадіях і людям, які не мають прямого контакту з клієнтом. Метою проекту повинен бути докладний опис вимог на випадок, якщо виникають будь-які сумніви в подальших етапах. Наступне завдання, яке виконується на стратегічному етапі полягає в тому, щоб описати можливості проекту. Зазвичай розвинена система підтримуватиме певні аспекти діяльності клієнта. Відповідний опис можливостей необхідний для хоршої вартісної оцінки проекту. Проте, клієнт не знає можливостей проекту на даному етапі. Може бути незрозумілим, які функції будуть здійснені в ПЗ і які функції будуть здійснені користувачами, іншими системами і апаратними засобами. Визначення можливостей проекту призводить до контекстного опису, тобто до опису зовнішніх систем, з якими взаємодіяла б система. У багатьох випадках система використовується одним або декількома користувачами. Цих користувачів розглядають як зовнішню систему. Визначення мети, можливостей і контексту проекту недостатньо для вартісної оцінки виробництва і складних систем. Точна оцінка можлива тільки якщо всі етапи, такі як формулювання вимог, аналіз і проектування, були виконані. Практично фінансові ресурси доступні в стратегічному етапі, обмежені, тому рекомендується робити тільки загальну оцінку. Важливо враховувати всі можливості описаної системи. Стратегічний етап називають також етапом проектування. Він виконується перш, ніж ухвалені остаточні рішення. У випадку компанії, яка виробляє ПЗ для клієнта, це етап ведення переговорів про продукт з клієнтом. У випадку, коли компанія розробляє ПЗ для ринку, це - етап обговорення і планування продукту. Стратегічний етап також називають техніко-економічним вивченням. На цьому етапі виконуються наступні дії: обговорення проекту з представниками клієнта визначення мети проекту з точки зору клієнта визначення можливостей і контексту проекту приблизне формулювання вимог, аналіз і проект системи формулювання альтернативних рішень аналіз представлення результатів представникам клієнта і здійснення виправлень попереднє планування і вибір структури команди стандартні визначення У випадку розробки системи ПЗ для клієнта ми повинні розрізняти людину-замовника і людей, які використовуватимуть і застосовуватимуть систему. В загальному наш проект повинен відповідати вимогам замовників, так як продукт буде оцінюватися ними. Дуже часто вони не є користувачами системи. На цьому етапі існує декілька стратегічних рішень, які повинні бути прийняті: вибір моделі проекту вибір методів, що будуть використовуютися для аналізу і проектування вибір програмного середовища вибір CASE-інструментів рішення про використання наборів інструментів рішення про можливу співпрацю Як правило, існують декілька можливих рішень по системі і ці варіанти рішень підпорядковані певним обмеженням. Обмеження можуть стосуватись: максимальна допустима вартість доступні професіонали і персонал доступні інструменти обмеження в часі На стратегічному етапі виконується попереднє планування ( визначаються підзадачі і оцінюється час, необхідний для їх виконання). Тому деталі проекту ще не визначені і графік роботи є дуже загальним. На стратегічному етапі повинні бути визначені стандарти. Вони включають: використання інструментів і понять методи документування Оцінка рішення може бути заснована на таких критеріях, як вартість, затрати часу на проект, надійність, повторне використання компонентів системи, мобільності і спосіб виконання. До ключових чинників успіху на стратегічному етапі належить: Ефективність роботи ( особливо для компаній, що працюють на конкретного клієнта на ринку конкуруючих компаній, будь-які затримки можуть призвести до низьких шансів на нові замовлення). Незалежно від системи, що розробляється, компанія не може витратити значні кошти на стратегічному етапі ( таким чином, етап повинен бути організований невеликою групою людей і в короткі терміни). Нерозуміння ключових моментів клієнтом ( цей чинник робить успіх проекту неможливим). Осмислення всієї системи ( більшість невдач, викликані в результаті приділення дуже великої уваги деяким фрагментам системи, тобто відсутнє розуміння частин, які можуть бути найважчими в розробці). До основних результатів стратегічного етапу відносять: складання звіту, який охоплює визначення мети опис можливостей опис зовнішніх систем опис загальних вимог загальна модель системи запропоноване рішення по системі вартісна оцінка попереднє планування звіт про відносну оцінку рішення, що містить інформацію про всі можливі рішення і обгрунтування ухвалених рішень представлення необхідних ресурсів - штату, апаратних засобів, програмного забезпечення і т.д. стандартні визначення планування аналізу Етап визначення вимог Мета цього етапу полягає в тому, щоб описати детально вимоги клієнта. На цьому етапі ми описуємо всі вимоги, які ведуть до досягнення мети. Ми повинні мати на увазі, що клієнт може не зрозуміти їх технічної точки зору. Таким чином формулювання вимог - процес комунікації з клієнтом, в якому клієнт і розробник встановлюють ряд відповідних вимог. У компанії, що створює ПЗ для клієнта, аналітики мають прямий контакт з представниками клієнта. Постійне обговорення з представниками клієнта, які в більшості випадків є користувачами системи, призводять до формулювання всіх деталей вимог. Рекомендується, щоб одна людина з боку клієнта була відповідальна за комунікацію представників клієнта з аналітиками. Труднощі на цьому етапі виникають з наступних причин: клієнт не знає, як цілі можуть бути досягнуті ( існує багато способів досягнення цілей) великі системи використовуються багатьма користувачами. Можуть бути протиріччя в підходах до їх використання. Різні користувачі можуть володіти різною термінологію люди, що організовують замовлення і користувачі – це різні люди. Думка замовників може бути критичною на цьому етапі, але вони, можливо, не враховують деяких потреб користувачів. Вимоги клієнта можна описати на різних абстрактних рівнях: визначення вимог ( загальний опис, який проводиться після обговорення деталей з представниками клієнта) специфікація вимог. Опис, який використовує структуровану і природню мову і вводить деякі прості формальні примітки специфікація ПЗ - завершений формальний опис вимог Опис вимог повинен: бути повним і послідовним; описувати, як поводиться система, як вона організована; розглядати будь-які обмеження системи; бути легким у розвитку; брати до уваги можливі майбутні зміни; описувати виключення. Основна помилка на цьому етапі полягає в зосередженості на типових ситуаціях і нехтування виключеннями. І користувачі, і аналітики мають таку схильність. Вимоги до ПЗ можуть бути розділені на два типи: Функціональні вимоги. Вони описують функції (операції, дії), що виконуються системою; Нефункціональні вимоги. Вони описують обмеження функціональності. Вимоги повинні міститися в відповідному документі, який повинен містити в собі наступні розділи: вступ - цілі, можливості і контекст системи. Ця частина містить результати стратегічного етапу опис розвитку системи - опис можливих змін опис функціональних вимог опис атрофованих вимог модель системи словник Крім того цей документ може містити додаткову інформацію: специфікація функціональних вимог специфікація нефункціональних вимог вимоги до устаткування вимоги до баз даних індекс плани тестування 2.1. Функціональні вимоги Функціональні вимоги описують функції, що виконуються системою. Вони можуть включати в себе вимоги дозовнішніх систем. Часто для опису вимог використовується неспеціалізована мова, при цьому виникають деякі незручності: двозначність неспеціалізованої мови, робить опис важким до сприйняття і може призвести до різного його розуміння людьми гнучкість неспеціалізованої мови, яка дозволяє виражати той же самий вміст в різних формах. Це може призвести до упущення суперечливих вимог, сформульованих в різноманітних формах одних і тих самих функцій. Формальна примітка може усунути двозначність, але при цьому може виявитись важкою для сприйняття клієнтом. Таким чином, формальна примітка може тільки підсумовувати неспеціалізований опис. Зазвичай функціональні вимоги подаються у формі очікуваного результату, а не у формі алгоритму. Цей опис є декларативним, але в деяких специфічних випадках необхідним є і викладення алгоритму. Функціональні вимоги сформульовані, щоб визначити зовнішні зв'язки. Функції системи повинні бути відомі користувачам і іншим взаємодіючим системам. Під функціями системи ми не повинні розуміти тільки функції програми. Методика декомпозиції функцій передбачає, що найзагальніші функціональні вимоги формулюються і поділяються по назві функцій. Практично клієнти не завжди розуміють або цікавляться загальними функціональними можливостями системи і обговорюють специфічні функції, які потім об’єднані аналітиком системи. Таку методику називають знизу-вверх. Більшість розробників використовує обидва методи. Аналітик системи повинен розглянути спочатку загальні функції, а потім інформацію, зібрану у користувачів. Таким чином розділення і об’єднання опису застосовується в процесі формулювання вимог. 2.2. Нефункціональні вимоги Нефункціональні вимоги описують обмеження, в яких виконуються функції. Вимоги можуть бути поділені на: вимоги продукту, наприклад "можуть використовуватися тільки клавіатура і миша " вимоги процесу, наприклад "система повинна виконувати за стандартом XXA/2002" зовнішні вимоги, наприклад "система повинна працювати з базою даних, описаною в документі YYYB/2001, і ніякі зміни в базі даних недопустимі" Ці вимоги повинні бути зрозумілими, тобто повинен бути метод перевірки виконання умов. Такі вимоги як: "зручний", "надійний", "ефективний" не можуть бути перевірені, отже, вони не відповідають формулюванню. Для успішного формулювання функціональних вимог необхідно: постійна співпраця з відповідними представниками клієнта повне розуміння вимог, усвідомлення спеціальних випадків і виключень у вимогах перевірка завершеності і послідовності вимог невеликий опис нефункціональних вимог Аналіз Мета формулювання вимог полягає в тому, щоб дати відповідь, чи необхідна система і які є при цьому обмеження. Мета проектування полягає в тому, щоб визначити, як система повинна бути реалізована. Мета аналізу полягає в тому, щоб визначити, як система повинна працювати. Результат цього етапу є логічна модель, яка показує, як підійти до розробки системи. Деталі розробки системи не розглядаються. Етап аналізу також називають етапом моделювання. Логічна модель на цьому етапі покращує розуміння системних вимог. Проект розпочинається з вибору моделі в області проблеми і передбачає визначення, яка повинна бути система. Проте, обов'язки системи зазвичай - підмножина змодельованої моделі в аналізі. Чинники успіху при аналізі є: залучення професіоналів; підтримка необхідних стандартів, наприклад, в примітці; правильність і перевірка концепції; прозорість, логічність і послідовність документації; глобальне розуміння системи без деталізації особливостей. За результатами аналізу отримують: покращений документ по вимогам; словник даних; документ, що описує створену модель: діаграми класу діаграма випадків використання діаграма дій діаграми станів звіт, що описує визначення класів, ознак, відносин, методів і т.д.; графік етапу проектування; попереднє призначення людей і команд. 4. Етап проектування Цей етап передбачає детальний опису реалізації системи. Опис після необхідних змін, зроблених на наступних етапах (реалізації і тестування), буде частиною технічної документації системи. Всупереч аналізу на етапі проектування, проектувальники повинні знати, яке програмне середовище, мови програмування, бібліотеки і інші інструменти будуть застосовані на етапі реалізації. На цьому етапі виконується перетворення абстрактних понять, що використовувалися в аналізі. У ПЗ існує декілька складових; одна з них представляє частину проблем, відповідальних за виконання основних функцій і обробки необхідних даних. Вона відображає модель, розроблену після аналізу. Інші частини відповідальні за комунікацію з клієнтом, за зберігання і доступ до даних, управління пам'яттю і компоненти управління завданнями. На етапі проектування також виконується оптимізація моделі. Програмне середовище використовує різні інструменти, які обмежують раніше розроблену модель, але воно може також забезпечити допоміжні механізми, які дозволяють покращити реалізацію. Таким чином на етапі проектування створюється модель в рамках обмежень та покращує можливості програмного середовища

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

77pazan77

01.02.2013 02:02-

Коментарі

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

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

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

поділитись