
- •I. Введення в розробку програмного забезпечення
- •1. Складність інформаційних систем
- •2. Розробка програмного забезпечення
- •4.Концептуальне моделювання
- •2. Модель водоспаду із зворотнім зв'язком
- •7.Модель спіралі
- •III. Етапи розробки програмного забезпечення
- •1. Стратегічний етап
- •2.2. Нефункціональні вимоги
- •4. Етап проектування
- •5. Етап реалізації
- •6. Етап тестування
- •7. Етап установки
- •8. Етап підтримки
- •IV. Стратегічний етап
- •1. Дії на стратегічному етапі
- •2. Співпраця з клієнтом
- •3. Область дії і контекст проекту
- •4. Стратегічні рішення
- •5. Оцінка різних варіантів рішеннь
- •6. Оцінка вартості рішень
- •7. Чинники успіху
- •8. Результати стратегічного етапу
- •9. Короткий звіт
- •V. Розпізнавання вимог і документація
- •1. Складнощі у формулюванні вимог
- •2. Методи ідентифікації вимог
- •3. Методи опису вимог
- •4. Типи вимог
- •5. Перевірка вимог
- •6. Документ з вимогами
- •7. Чинники успіху
- •8. Короткий звіт
- •VI. Розробка моделі
- •1. Потреба в розробці моделі
- •2. Аналітична модель
- •3. Дії на етапі аналізу
- •4. Функціональна декомпозиція
- •5. Методологія, що використовується в створенні аналітичної моделі
- •6. Документація вимог
- •7. Аналіз чинників успіху
- •8. Короткий звіт
- •VII. Етап проектування
- •1. Цілі проектування
- •Малюнок 7.2.1. Етап проектування.
- •2. Специфікація результатів аналізу
- •3. Дизайн інтерфейсу
- •4. Структуровані схеми/діаграми
- •5. Складова організації даних
- •6. Оптимізація проекту
- •7. Фізична структура системи
- •8. Правильність і якість проекту
- •9. Нефункціональні вимоги на етапі проектування
- •10. Результати етапу проектування
- •11. Детальний документ проекту
- •2. Стандарти, правила і порядок здійснення дій проекту:
- •12. Короткий звіт
- •VIII. Розробка інтернет-програм
- •1. Специфікація інтернет-програми
- •2. Методи розробки інтернет-програм
- •3. Об'єктно-орієнтована гіперсередовищна модель розробки (oohdm)
- •4. Метод розробки веб-сторінок (wsdm)
- •5. Мова веб-моделювання (WebMl)
- •6. Короткий звіт
- •IX. Бдб і бдс системи
- •1. Електронний бізнес
- •2. Інтернет-бізнес і електронний ринок.
- •3. Інтернет-магазин
- •4. Модель електронного бізнесу
- •1.Модель брокера
- •2.Модель, яка задовольняє індивідуальним потребам
- •3.Модель контактів
- •5. Платежі
- •6. Безпека
- •8. Моделювання систем бдб і бдс
- •9. Багатошарова архітектура програм
- •9. Cервіс-орієнтована архітектура (соа)
- •10. Короткий звіт
- •X. Реалізація
- •1. Характеристики етапу реалізації
- •2. Надійність програмного забезпечення
- •3. Похибка
- •4. Транзакції
- •5. Середовище реалізації
- •6. Чинники успіху і результати етапу реалізації
- •7. Короткий звіт
- •XI. Тестування
- •1. Етап тестування
- •2. Перевірка
- •Малюнок 11.3.1. Модель V-тестування.
- •3. Перегляди
- •4. Аудит
- •5. Інспекції
- •6. Види тестів
- •7. Процес тестування
- •8. Тестування надійності
- •9. Типи тестів на знаходження помилок
- •10. Програми-інструменти
- •11. Статичні тести
- •12. Підрахунок кількості помилок
- •13. Чинники успіху, успіх тестування
- •14. Короткий звіт
- •XII. Оцінка програмного забезпечення
- •1. Простановка розмірів проекту
- •2. Оцінка складності в проектах
- •3. Ефекти масштабування
- •4. Оцінка вартості програмного забезпечення
- •5. Конструктивна вартісна модель (cocomo)
- •6. Балова функціональна оцінка
- •7. Метод випадкового використання
- •8. Короткий звіт
- •XIII. Управління конфігурацією пз і версіями
- •1. Управління конфігурацією пз
- •2. Елементи конфігурації пз
- •3. Угода позначень
- •4. Зберігання елементів конфігурації
- •5. Перегляди
- •7. План управління конфігурації пз
- •I Вступ
- •II Управління
- •III Визначення конфігурації
- •IV Управління конфігурацією
- •V Реєстрація статусу конфігурації
- •4. Модель якості iso-9126
- •5. Управління якістю
- •6. Стандарти якості
- •7. Незрілість і зрілість виробництва
- •8. План гарантії якості пз (sqap)
- •9. Короткий звіт
- •XV. Управління проектом програмного забезпечення
- •1. Завдання управління проектом
- •2. Працівники виробництва програмного забезпечення
- •3. Характеристика хорошого розробника програмного забезпечення
- •4. Робота в команді
- •5. Управління підприємством по виробництву програмного забезпечення
- •6. Розвиток компанії по розробці програмного забезпечення
- •7. Документація проекту
- •8. Визначення продуктивності
- •9. Складання графіків проекту
- •10. Завдання управління проектом
- •11. Інтерфейс проекту
- •12. Планування проекту
- •13. Управління ризиком
- •14. Вимірювання процесів і продуктів
- •15. Короткий звіт
7. Чинники успіху
Ключові чинники успіху етапу формулювання вимог:
Надання лієнту зразків для усунення неясності,
повна ідентифікація вимог, виявлення специфічних і виняткових вимог. ,
завершеність і перевірка змісту,
формулювання нефункціональних вимог в певній формі.
8. Короткий звіт
Етап формулювання вимог дуже важливий в процесі розробки ПЗ. Помилки на цьому етапі складно виправити, що робить цей етап дорогим. Помилковий або неузгоджений опис вимоги може викликати невдачу або стати причиною не прийняття продукту.
Тому краще сформулювати вимоги ясно, скласти документ, що задовольняє обидві сторони.
VI. Розробка моделі
1. Потреба в розробці моделі
Модель - це представлення концепції якоїсь реальності. Розум людини завжди займався розробкою моделей, будь то математичні моделі, фізичні, моделі машин, будинків і т.д.
Яка мета розробки моделі?
Відповідь не проста, оскільки існує безліч цілей, для яких створюються моделі навколишнього світу. Одна з них - поліпшити розуміння системи перед тим, як її побудувати. Модель дозволяє експериментувати: вносити зміни, додавати і видаляти частини і елементи. Вносити зміни до моделі набагато простіше, ніж в систему. Наслідки неправильних рішень зменшуються і їх простіше виявити перед тим, як вони завдадуть шкоди самій системі.
Розробники інформаційних систем використовують моделі.
Зазвичай створюють наступні моделі:
модель вимог - описується, наприклад, випадками використання,
аналітична модель - статика і динаміка системи описуються мовою UML; деталями реалізації нехтують,
модель дизайну - описується мовою UML більш деталізовано. Наприклад, присутні фізичні діаграми.
Головна мета проектування такої моделі - надати повний, послідовний і зрозумілий опис системи з точки зору функцій, але не деталей реалізації. Модель використовується для кращого розуміння системи, виправлення помилок, додавання елементів,яких не вистачає і є основою моделі дизайну.
2. Аналітична модель
Аналітична модель - модель, яка будується на етапі аналізу. Мета етапу - розпізнавання всіх чинників або умов в наочній області, в проектному оточенні, в існуючих і запланованих комп'ютерних системах, які можуть вплинути на ухвалення рішень, якості системи і реалізацію вимог. Результат - логічна модель системи, яка описує метод реалізації вимог але не зачіпає нічого, що стосується реалізації.
Наступний етап - етап дизайну. Він відповідає на питання, як система повинна реалізовуватися і описує цю реалізацію.
Границі аналітичної моделі
Зазвичай аналітична модель ширша, ніж спочатку вимагається.
Ось декілька причин проектування більшої моделі:
Імпортування в модель елементів із зовнішніх систем робить систему більш загальною і всеосяжною,
Протягом розробки ми можемо все ще не знати, які готові елементи будуть включені у фінальну версію продукту, а які будуть написані уручну,
Бюджет може не дозволити повного проектування системи "з нуля", і визначення способів розробки буде проведено під час аналізу.
Мета розробки аналітичної моделі
Хороша аналітична модель повинна мати наступні характеристики:
вона повинна бути спрощеним описом системи,
функції повинні бути представлені ієрархічно,
логічна модель повинна слідувати певним правилам,
модель повинна будуватися за допомогою добре відомих методів і інструментів,
модель використовується для ухвалення рішень в подальшому дизайні.
Модель ПЗ повинна бути спрощеним описом, який представляє найважливіші особливості ПЗ на високому абстрактному рівні.
Логічна модель:
показує, що повинна робити система,
показує ієрархію системи,
уникає термінології реалізації,
дозволяє ухвалювати рішення "від причини до наслідків" і назад.
Записи, що робляться на етапі аналізу
У аналітичному спорудженні моделі найчастіше роблять такі записи:
звичайна мова,
графічні записи,
специфікація - структурований текстовий і числовий опис.
Графічні записи дуже важливі в спорудженні аналітичної моделі. Розробка ПЗ використовує і інші способи запису, наприклад, методи з електроніки і механіки. Психологічний аналіз показує важливість використання графічного запису.
Функції запису:
інструмент аналітика і дизайнера,
зв'язок з користувачем,
зв'язок з іншими членами команди,
основа для реалізації ПЗ,
опис технічної документації.
Запис повинен бути простий, зрозумілий, конкретний, легкий для розуміння, дозволяючи моделювати складні зв'язки.