- •1 ) Виды обеспечения вс. Понятия программы, программной системы (комплекса), программного продукта (средства, изделия), программного обеспечения.
- •2 ) Причины сложности разработки по.
- •3 ) Процессы жизненного цикла программного продукта по стандарту iso/iec 12207 (гост р исо/мэк 12207).
- •4 ) Основные процессы разработки программного продукта.
- •Анализ;
- •Проектирование;
- •Программирование (кодирование, реализация);
- •Тестирование;
- •Документирование.
- •5 ) Основные модели и методологии разработки по.
- •6 ) Задачи и проблемы планирования разработки.
- •7 ) Понятие конфигурации и управления конфигурацией, задачи управления конфигурацией.
- •8 ) Модель зрелости возможностей cmm.
- •9 ) Задачи анализа требований. Основные виды работ при анализе.
- •Исходная постановка задачи
- •Сбор и исследование информации
- •Выбор приоритетных критериев качества
- •Определение входных, хранимых и выходных данных
- •Формализация требований
- •10 ) Варианты использования: определение, роль в жизненном цикле.
- •11 ) Цель и объекты проектирования. Архитектурное и детальное
- •12 ) Виды декомпозиции системы. Основные структурные методы проектирования (по направлению декомпозиции).
- •13 ) Понятие модуля. Критерии качества проектирования модулей и классов.
- •14 ) Проектирование интерфейса пользователя (определение, классификации)
- •15 ) Проектирование интерфейса пользователя (определение, требования).
- •16 ) Повышение информативности программ: цели, основные методы.
- •Основные методы сводятся к четырем группам:
- •17 ) Безопасное программирование. Различают два подхода к программированию:
- •Основные принципы:
- •18)Цели тестирования и отладки. Объекты и особенности процесса тестирования.
- •Объектами тестирования являются:
- •Три принципа тестирования:
- •Основные проблемы организации тестирования программы:
- •19. Виды тестирования
- •20. Критерии качества тестирования
- •21. Метод ручной инспекции кода; метод эквивалентов и граничных условий.
- •22. Тесты и тестовые процедуры (определения, принципы создания)
- •23. Классификация ошибок с точки зрения процесса разработки
- •24. Основные программные и эксплуатационные документы
- •25. Общее и детальное планирование испытаний
- •26. Методы оценки свойств программного продукта
- •27. Основные факторы качества программного продукта (по гост р исо/мэк 912693)
6 ) Задачи и проблемы планирования разработки.
Задачи планирования:
Определение списка работ (WBS – Work Breakdown Structure)
Определение списка исполнителей
Проецирование исполнителей и работы на шкалу времени
Инструментарий: MS Project, Spyder Project, Primavera Project Planner.
Проблемы:
Известно, что оптимальный вариант плана приходится искать в «железном треугольнике», или «треугольнике компромиссов»:
ресурсы (люди и деньги);
качество (возможности, требования);
время.
Это означает, что если по объективным причинам жёстко задан (неизменяем) какой-то один из этих параметров, то можно пытаться варьировать одним из двух оставшихся. Последний же неизбежно будет функцией двух первых. Если нужно максимальное качество за минимальные деньги, то потребуется много времени. Если нужно максимальное качество за минимальное время, то потребуется много ресурсов. И если хочется создать продукт за минимальное время минимальными ресурсами, то качество будет минимальным.
7 ) Понятие конфигурации и управления конфигурацией, задачи управления конфигурацией.
Конфигурация – это совокупность всех сведений о проекте в виде файлов и документов.
Управление конфигурацией позволяет:
определить что надо хранить (выполнить конфигурационную идентификацию);
организовать хранение всей истории изменений;
организовать согласованность внесения изменений (контроль конфигурации);
организовать хранение моментальных снимков (версий) конфигурации, то есть согласованных состояний проекта в некоторые важные моменты времени(2 variants: Lock – Modify – UnLock (в случае Check In – снимается блокировка и копия записывается в «мастер копий», после чего становится доступной для всех), Copy – Modify – Merge (хранит историю изменений + версию сравнений изменений в случае временного или постоянного отката)).
Начальный этап управления конфигурацией заключается в двух мероприятиях:
выбор и внедрение системы управления версиями (version control system: borland star team, Microsoft TFS, SVN);
разработка организационного обеспечения (регламента управления конфигурацией).
Назначение ответственных лиц (распределение обязанностей)
Очевидно, эти действия должны быть выполнены ещё до начала любых работ по проекту, так как любые работы по проекту требуют упорядоченного хранения каких-либо электронных материалов. Дальнейшее управление конфигурацией со стороны менеджеров является в основном административным:
управление составом конфигурации (набором хранимых файлов);
управление правами доступа к системе управления версиями;
разрешение проблем;
резервное копирование (backup).
8 ) Модель зрелости возможностей cmm.
CMM (Capability Maturity Model) — модель зрелости возможностей, созданная в 1987 г. организацией Software Engineering Institute (SEI) при университете Карнеги-Меллон, США.
Ключевым понятием стандарта CMM является зрелость организации.
1. Начальный уровень (Initial level). На этот уровень не сертифицируются, он описан как отправная точка. К данному уровню относится любая компания, которой удалось получить заказ на разработку программного продукта. В организации царит анархия при разработке, нет четких процессов управления и четких инженерных процессов. Могут существовать стандарты и инструкции, но им никто не следует. Успех одного проекта не гарантирует успешность следующего. Для компаний данного уровня свойственны неравномерность процесса разработки — наличие затиший и авралов в работе. Организация полностью зависит от конкретных разработчиков, которые «тянут» на себе всю работу, а их уход неминуемо означает крах проекта.
2. Повторяемый уровень (Repeatable level). К этому уровню можно отнести компании, в которых внедрено управление проектами, по крайней мере, на приемлемом уровне. Управление проектами само по себе ещё тесно не связано (не интегрировано) с методологией разработки, но налажено планирование, контроль исполнения, управление конфигурацией. Организация стабильно использует опыт предыдущих проектов, поддерживает производственную дисциплину. Однако полная зависимость от конкретных личностей сохраняется, а организация имеет сильную тенденцию «сползания» к начальному уровню.
3. Определённый уровень (Defined level). Процессы управления интегрированы с инженерными процессами (методологий разработки) в единый стандартный документированный программный процесс, причем общий для всех проектов организации. Ведется постоянное обучение сотрудников. Начиная с этого уровня, организация перестает полностью зависеть от личностных качеств конкретных разработчиков и не имеет тенденции скатываться на нижестоящие уровни (нет деградации процесса в стрессовых ситуациях).
4. Управляемый уровень (Managed level). Кроме «примитивных» показателей качества (хорошо/плохо, быстро/медленно и т. п.) устанавливаются количественные показатели качества, которые собираются с помощью специального измерительного инструментария и оперативно анализируются менеджерами. Информация обо всех проектах собирается в базе данных. Достигается полное управление проектами и предсказуемость программного процесса и качества программ.
5. Оптимизирующий уровень (Optimizing level). Организация постоянно и целенаправленно занимается улучшением существующих процессов, и делает это полностью контролируемым образом, поскольку количественные показатели качества позволяют вести оценку эффективности ввода новых технологий. Организация нацелена на предупреждение дефектов (defect prevention).
В 2000 г. SEI предложил сменить CMM новой, улучшенной моделью — CMMI (Capability Maturity Model Integration). CMMI фактически является обобщением CMM, поскольку рассматривает не только процессы разработки, как CMM, но и другие процессы ЖЦ (приобретение, сопровождение и т. д.).