- •1. Характеристики и признаки больших программных продуктов и систем
- •2. Жизненный цикл программного обеспечения (класс крупных продуктов, систем)
- •Модели жизненного цикла по Каскадная модель
- •Спиральная модель
- •Итерационная модель
- •Стандарт жизненного цикла по гост 34.601-90
- •3. Проблемы и риски программных проектов. Средства борьбы со сложностью
- •Задачи управления рисками
- •4. Анализ требований к программному обеспечению, особенности проектирования крупных пс
- •5. Планирование разработки и распределение работ, организация коллективной разработки пс
- •6. Спецификации. Моделирования. Верификация методом проверки понятности
- •7. Факторы надежности разработки в языках программирования, в частности Ада
- •8. Компонентно-ориентированное проектирование и программирование. Пример - модули компиляции и внутренняя структура Ада программ
- •9. Согласованность средств проблемной ориентации в проектных решениях и при разработке на языке программирования
- •10. Гибкость программных конструкций на примере языка Ада
- •11. Забезпечення динамічності структур даних на прикладі мови Ада
- •Процессы жц верификация и валидация программ
- •Функциональное тестирование
- •12. Проектування обробки виключень на прикладі мови Ада. Исключения
- •Упрощение управляющей структуры
- •Возбуждение и обработка исключений
- •Іі. Засоби контролю та управління якістю
- •Управління якістю у розробці великих пс: система видів якості. Вариант №1
- •Глобальное управление качеством (tqm, Total Quality Management)
- •Принципы управления, принципы tqm
- •Процессная модель управления качеством
- •Внутрішня та зовнішня якості пз: характеристики та підхарактеристики
- •Система методів перевірки функціональної вірності програм
- •7.1. Процессы жц верификация и валидация программ
- •Система мір внутрішньої та зовнішнього якості пз, опис мір (метрик)
- •21(9) Підхарактеристика якості продукції «узгодженість функціональності»
- •23(11) Контроль якості в управлінні розробкою пс
10. Гибкость программных конструкций на примере языка Ада
Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.
Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.
Ада обладает достаточным набором предопределенных встроенных типов, а также предоставляет богатые возможности для описания новых типов данных и их подтипов (subtype). Кроме того, в языке представлены средства, которые позволяют гибко управлять внутренним представлением вновь создаваемых типов данных.
