- •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. Короткий звіт
4. Робота в команді
Атрибути роботи в команді
Психологічні чинники дуже важливі для ефективності команди. Розрізняють наступні орієнтації працівників:
Проблемно-орієнтованість: талановиті, незалежні, визначні, агресивні, конкурентноздатні люди.
Само-орієнтованість: проблемні, догматичні, агресивні, конкурентноздатні, ревниві люди.
Орієнтованість на взаємодію: неагресивні, без потреби автономної роботи і успіхів, які люблять допомагати, доброзичливі.
Люди 1-го типу ефективні, якщо вони працюють незалежно. Команда людей цього типу може бути неефективною. Кращий ефект буде досягнутий командою з людей 3-го типу. Типи 1 і 2 можуть бути ефективні в добре мотивованій команді. 3-й тип потрібний для взаємодії з клієнтом.
Відданість команди
Термін "відданість команди" означає сильну відданість команді і меті. Дуже сильна відданість може бути не практична, оскільки це перешкоджає заміні лідера, яка іноді необхідна.
Одноманітнем мислення команди може іноді бути і руйнівним для реалізації проекту. Без самокритики, без нових ідей, задовольняючись лише своєю внутрішньою ідеєю і тенденціями може спричинити зменшення якості ПЗ.
Метод боротьби з таким командним мисленням - організувати засідання критики, де заборонено висловлювати самопохвалу, а дозволені лише зауваження незадоволеності. Інший спосіб - найняти критиків - людей з особливим талантом знаходити дефекти і/або нерозв'язані проблеми. Зазвичай таких людей не люблять.
Ергономіка
Ергономіка - важливий чинник. На жаль, часто цього не визнають. Замість будівництва великого офісу можна спорудити 2 менших і робота команди буде ефективнішою. Великі кімнати потрібно використовувати для конференцій і неформальних зустрічей.
Роботу потрібно виконувати на достатньо новій апаратурі, оскільки робота на старій може відштовхнути працедавців.
Психологічний комфорт, хороша атмосфера, ніяких конфліктів, ніякої невизначеності у відповідальності, справедлива оцінка роботи і справедливе робоче планування - все це може поліпшити роботу команди.
5. Управління підприємством по виробництву програмного забезпечення
Малюнок 15.6.1. зображає структуру управління підприємством по виробництву ПЗ.
Мал. 15.6.1 Управління підприємством по виробництву ПЗ.
У команді по розробці проекту повинні бути присутні наступні працівники:
Менеджер проекту,
Аналітик - людина, що контактує безпосередньо з клієнтом,
Розробник - людина, відповідальна за реалізацію проекту. Цій посаді можуть бути доручені більш спеціалізовані функції,
Дизайнер інтерфейсу користувача,
Проектувальник баз даних,
Програміст,
Тестувальник,
Людина, відповідальна за підтримку,
Експерт методології,
Технічний експерт.
Деякі посади можуть комбінуватися. Типовий приклад - об'єднаня навичок аналітика і проектувальника або проектувальника і програміста.
Структура команди
У мережевій структурі команда співпрацює на щоденній основі. Стандарти якості гарантуються взаємним контролем роботи. Написання програм може виконуватися в командній роботі. Будь-який член команди, який йде з неї, може бути легко замінений. Мережа не повинна мати більше 8 чоловік.
Мал. 15.6.2. Мережева структура командної роботи.
Зоряна структура корисна, якщо група має багато недосвідчених працівників. Супервізор контролює і координує роботу. До зоряної структури можуть увійти більше працівників, ніж до мережевої. Проблеми можуть з'явитися, якщо супервізор залишить команду.
Мал. 15.6.3. Зоряна структура командної роботи.
Гарантія якості не повинна спийматись як тестування. Гарантія якості визначається процедурами, технікою і інструментами, вживаними для того, щоб відповідати стандартам. Якщо стандарти не визначені, гарантія якості є мінімальною.
Критерії якості:
Відповідність вимогам користувача
Ефективність
Ремонтопридатність
Ергономіка
Якість ПЗ визначається всіма діями, зробленими на всіх етапах. Критерії якості і пріоритети повинні бути визначені. Критерії повинні документуватися в ПГЯПЗ. Якість програмного забезпечення залежить від якості виробничого процесу. Це визначено в стандартах ISO 900x.