Лекции_1_2
.docxОтветь на следующие КОНТРОЛЬНЫЕ ВОПРОСЫ:
1. Каково назначение требований?
2. В чем отличие разных уровней требований?
3. Для чего предназначены бизнес-требования?
4. Что собой представляет уровень пользовательских требований?
5. Что собой представляет уровень функциональных требований?
6. Какие подходы к составлению системы требований вы знаете?
7. Каким образом должны быть связаны между собой разные уровни требований?
8. Какие подходы к тестированию требований вы знаете?
9. Какие критерии качества требований вы использовали?
10. Какой критерий отвечает за то, что требование должно содержать всю необходимую
информацию для его реализации?
11. Какой критерий качества определяет необходимость связи между разными
уровнями требований?
12. Какой критерий качества требований нарушается, если бизнес-требование не
раскрыто в нижележащих уровнях требований? Допустимо ли это?
13. Какой критерий качества отвечает проверку возможности реализации требования
при заданных ограничениях?
14. Что такое метод прототипирования интерфейса
🤔 Назначение требований - определить и описать функциональность, характеристики и ограничения системы, которую нужно создать или изменить.
📊 Разные уровни требований различаются своей детализацией и аудиторией. На верхнем уровне - бизнес-требования, затем пользовательские требования, и на самом низком уровне - технические требования.
💼 Бизнес-требования определяют цели и потребности организации, которая внедряет систему. Они помогают понять, как система будет приносить пользу бизнесу.
👥 Пользовательские требования определяют, что ожидает пользователь от системы, ее интерфейса и функциональности. Они фокусируются на потребностях и ожиданиях конечных пользователей.
⚙️ Функциональные требования определяют, как система должна взаимодействовать с пользователем и выполнять определенные функции или задачи.
🛠️ К некоторым подходам к составлению системы требований могут относиться: водопадная модель, спиральная модель, гибкие методологии разработки (например, Scrum).
🔗 Разные уровни требований должны быть связаны между собой, чтобы обеспечить соответствие и согласованность. Более низкие уровни требований должны быть производными от высокоуровневых требований.
✅ Подходы к тестированию требований могут включать тестирование соответствия, сценарии использования, контрольные листы и проверку полноты требований.
📏 К критериям качества требований могут относиться: полнота, однозначность, применимость, измеримость, согласованность, модифицируемость и отслеживаемость.
📝 Критерий "полноты" отвечает за то, что требование должно содержать всю необходимую информацию для его реализации без дополнительных догадок или предположений.
🧩 Критерий "согласованности" определяет необходимость связи между разными уровнями требований, чтобы они взаимодействовали и поддерживали друг друга без противоречий.
❌ Если бизнес-требование не раскрыто в нижележащих уровнях требований, то это может нарушать критерий "полноты" требований. Нежелательно такое опущение, так как это может привести к несогласованности и неполноценной реализации системы.
🔒 Критерий "возможности реализации" проверяет, может ли требование быть реализовано с учетом ограничений, таких как технические ограничения или ограничения бюджета.
🖥️ Метод прототипирования интерфейса - это процесс создания прототипа пользовательского интерфейса системы, который позволяет протестировать и визуализировать функциональность и взаимодействие с пользователем.
ЛЕКЦИЯ 1
Тестирование – проверка соответствия реального поведения программы ожидаемому
В более широком смысле – техника контроля качества, содержащая планирование работ, проектирование + выполнение + анализ результатов тестов
Качество ПО – способность ПО удовлетворять установленные и предполагаемые потребности
Контроль качества – нахождение ошибок с целью их исправления и поддержания качества
Верификация – оценка свойства результатов удовлетворять условиям, разработанным в начале этапа
Валидация – оценка свойства ПО соответствовать ожиданиям и потребностям пользователя
Обеспечение качества (КуА) – процесс обеспечения качества продукта в будущем, ориентированный на процесс разработки
Управление качеством (Ку Манаг) – деятельность по выполнению требований к качеству ПО: определение владельцев процессов, требования к процессам, измерение процессов.
Программная инженерия (Софт инж) – изучает подходы к разработке ПО, правила и опыт в разработки
Жизненный цикл ПО – процесс, начинающийся с решения о создании и заканчивающийся изъятием из эксплуатации
Модель жизненного цикла – описание фаз/стадий проекта по созданию ПО
Проект – уникальная деятельность, имеющая начало и конец во времени, нацеленность на результат, определённый требования и ресурсы
Требование – задокументированная потребность того, что делать продукт
Внешнее качество – качество для заказчика
Внутреннее качество – качество (кода) для разработчиков
Качество при использовании – качество для пользователя
Стандарты:
ISO 9000:2015 Quality management systems — Fundamentals and vocabulary. Системы управления качеством — Основы и словарь.
SO 9001:2015 Quality management systems — Requirements. Models for quality assurance in design, development, production, installation, and servicing. Системы управления качеством — Требования.
ISO/IEC 90003:2014 Software engineering — Guidelines for the application of ISO 9001:2008 to computer software. Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.
• ISO 8402:1994 - Quality management and quality assurance. Управление качеством и элементы системы качества
ISO/IEC 25010:2011 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models) - Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов.
ЛЕКЦИЯ 2
ISO/IEC 12207 - Information Technology - Software Life Cycle Processes - Процессы жизненного цикла программных средств. Стандарт содержит определения основных понятий программной инженерии - программного продукта и жизненного цикла программного продукта, его структуры и процессов.
SEI CMM - Capability Maturity Model (for Software) - модель зрелости процессов разработки программного обеспечения. Стандарт отвечает на вопрос: «Какими признаками должна обладать профессиональная организация по разработке ПО?».
Уровни зрелости процесса:
ISO/IEC 15504 - Software Process Assessment - Оценка и аттестация зрелости процессов создания и сопровождения ПО. Является развитием и уточнением ISO 12207 и SEI CMM. Содержит расширенное по отношению ISO 12207 количество процессов жизненного цикла и 6 уровней зрелости процессов. •
PMBOK - Project Management Body of Knowledge Свод знаний по управлению проектами. Содержит описания состава знаний по следующим 9 разделам (областям знаний) управления проектами
SWEBOK - Software Engineering Body of Knowledge Свод знаний по программной инженерии - содержит описания состава знаний по 10 разделам (областям знаний) программной инженерии.
Модели жизненного цикла программного обеспечения:
Первый инкремент приводит к получению базового продукта, реализующего базовые требования
План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность
Спиральная модель: 1 — начальный сбор требований и планирование проекта; 2 — та же работа, но на основе рекомендаций заказчика; 3 — анализ риска на основе начальных требований; 4 — анализ риска на основе реакции заказчика; 5 — переход к комплексной системе; 6 — начальный макет системы; 7 — следующий уровень макета; 8 — сконструированная система; 9 — оценивание заказчиком.
Agile методологии:
Существует более 15 agile методологий. Самые распространенные:
Первая методология - XP - Экстремальное программирование (eXtreme Programming).
Ориентирован на группы малого и среднего размера, работающие в быстро меняющихся или неопределённых условиях. Большинство принципов, поддерживаемых в ХР (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т. д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе.
Методы XP-процесса:
1. Игра планирования (Planning game) — быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс).
2. Частая смена версий (Small releases) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.
3. Метафора (Metaphor) — вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.
4. Простое проектирование (Simple design) — проектирование выполняется настолько просто, насколько это возможно в данный момент.
5. Тестирование (Testing) — непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что входным критерием для написания кода является «отказавший» тестовый вариант.
6. Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.
7. Парное программирование (Pair programming) — весь код пишется двумя программистами, работающими на одном компьютере.
8. Коллективное владение кодом (Collective ownership) — любой разработчик может улучшать любой код системы в любое время.
9. Непрерывная интеграция (Continuous integration) — система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.
10. 40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.
11. Локальный заказчик (On-site customer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.
12. Стандарты кодирования (Coding standards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.
Вторая методология – Scrum
Основные понятия Scrum:
• Журнал продукта (Product Backlog) список требований или характеристик проекта, упорядоченных по приоритету и имеющих важное значение для заказчика. Журнал в любое время может быть расширен. Владелец продукта оценивает журнал продукта и по необходимости меняет приоритеты.
• Спринты (Sprint) — состоят из единиц работы, которые нужно выполнить для реализации порции требований, взятой из журнала продукта, причем за предопределенный квант времени (обычно за 15—30 дней). Эта порция требований носит название журнала спринта (Sprint Backlog) . Изменения в пунктах журнала спринта во время спринта запрещены.
• Scrum meetings — короткие встречи (обычно 15 минут) членов команды. Проводятся ежедневно.
• Демонстрационные версии — предоставляют заказчику расширенные варианты функциональной организации системы, тем самым демонстрируя реализацию новых функций.
Scrum-команда состоит из так членов как:
• Владелец продукта указывает команде разработчиков правильную цель и заботится о том, чтобы его команда двигалась к поставленной цели и не отклонялась от нее. Именно владелец продукта уполномочен не только поставить перед командой цель, но и сформировать для команды определенное представление о будущем продукте. Владелец продукта формулирует содержание журнала продукта.
• Scrum-мacтep. В его подчинении находится сам процесс разработки, но нет властных полномочий в отношении членов команды. призван помогать команде в использовании Scrum. Эта помощь напоминает действия спортивного тренера, который помогает спортсменам соблюдать режим и поддерживать форму.
• Команда разработчиков состоит из сотрудников, выполняющих всю работу по созданию работающей версии продукта (инкремента) в конце каждого спринта. Команды разработчиков сами организуют свою работу и сами управляют этой работой. • Размер команды разработчиков должен, с одной стороны, обеспечивать простоту в координации и управлении, а с другой - давать возможность выполнения значительного объема работы. Как правило, этим противоречивым требованиям удовлетворяет коллектив из 5—9 человек.