- •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. Аудит
Аудит - незалежний перегляд і оцінка ПЗ. Він перевіряє, чи відповідає ПЗ вимогам специфікаціям, рекомендаціям, стандартам, процедурам, умовам контрактів і ліцензіям.
Об'єктивність аудиту вимагає незалежних експертів-професіоналів.
Аудіювання повинне проводитися аудитною групою або персонами з ліцензіями.
Правила визначає стандарт ANSMEEE Std 1028-1988 IEEE - стандарт для переглядів і аудиту.
Аудит проекту розробки ПЗ
Мета аудиту - отримати цілі і інформацію про проекту.
Слід оцінювати ресурси, компетенцію і методи, які важливі для досягнення проміжних і повного успіхів.Ця інформація важлива для ухвалення стратегічних рішень.
Суб'єкти і перспективи аудиту
Суб'єктами аудиту можуть бути процеси або продукти проекту (можуть і обидва).
Мета аудиту процесу - перевірити, чи правильно виконується робота, її відповідність принципам і стандартам.
Мета аудиту продукту (проміжного або кінцевого) - перевірити, чи відповідає він вимогам і очікуванням.
Команда аудиту може застосовувати різні способи перевірки. Технічні аспекти можуть перевірятися для оцінки технічних рішень і як вони застосовані. Аспекти менеджменту можуть бути проаудийовані для того, щоб перевірити, чи достатні процедури менеджменту.
5. Інспекції
Інспекція - формальна техніка оцінки персоною або групою персон на наявність помилок у коді, вимогах і проектах, на їх відповідність стандартам і пошук інших проблем в процесі розробки ПЗ [IEEE Std. 729-1983].
Інспекція повинна бути добре спланована і організована. Всі помилки і проблеми повинні бути записані. Супервізори не повинні брати участь в інспекції. Її результати надаються супервізорам у формі звітів, без особистої інформації про інспекторів.Після чого проводиться нарада.
Мета наради - зробити виводи про те, які проблеми повинні бути ліквідовані і які дії зроблені для уникнення проблем в майбутньому.
Малюнок 11.6.1. Процес інспекції.
На малюнку 11.6.1 представлені наступні етапи інспекції:
Ініціація - виклик інспекції і її голови
Планування - лідер викликає членів, формує управляючі таблиці і план, визначає ретельність контролю
Ініціююча нарада - формулювання правил, завдань, очікувань, створення документів інспекції
Інівідуальний контроль - члени інспекції перевіряють документи, використовуючи критерії контролю (для того, щоб знайти максимальну кількість помилок)
Контрольна нарада (мозкова буря) - збір думок кожного інспектора, які можуть бути "невідповідністю" (потенційною помилкою), "питанням про намір", "пропозицією про удосконалення процесу", пошук інших невідповідностей, залучення до процесу інспекції
Удосконалення продукту: редактор (зазвичай - автор) проводить перевірку усіх рішеннь і проголошує невідповідності. Реальні невідповідності можуть відрізнятися від записаних. Їх сприймають як помилки, або документ редагується для уникнення неправильної інтерпретації.
Доопрацювання: лідер перевіряє, чи всі невідповідності виправлені; він перевіряє завершеність, а не правильність.
Рішення по завершеності: лідер дає оцінку того, чи готовий продукт (чи знаходиться кількість помилок в допустимих межах).
Розробка документів
Мета "мозкової бурі" - визначити причину вагомих помилок (не більше десяти помилок) і запропонувати процедури для їх уникнення в майбутньому.
Дослідження показують, що інспекції - найефективніший спосіб (від 50% до 80%; в середньому - 60%; для тестування середній показник - 30%, максимум - 50%). Сам метод і його умови застосовуються рідко і лише до "елітних" систем.
Продуктивність в результаті інспекції збільшується на 30% - 100%, час на розробку проекту зменшується на 10% - 30%, вартість тестування зменшується в 5 - 10 разів (менше помилок, менше регресивних помилок), підтримка - в 10 разів більша. Було відмічено, що інспекції мотивують команди: робота виконується вчасно, а її комфорт збільшується.
Продукт буде оцінений з більшою компетентністю (ми можемо вихвалятися, а не соромитися). Відбудеться навчання шляхом знаходження помилок, а витрати стануть меншими, оскільки не потрібно буде маскувати низьку якість продукту.
Інспекції не є частими, оскільки вони вимагають компетентних персон, які правильно працюють. Не потрібно ніяких особливих інструментів. Витрати і наслідки інспекції нелегко оцінити. Ефект може бути зменшений, якщо інспектора будуть недосвідчені. Також інспекція може призвести до самозахисту розробки проекту.