Добрый день. Вопрос №1 Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте? Вопрос №2 Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже? |
Действия
Формулирование концепции проекта
Перед запуском проекта необходимо четко сформулировать его концепцию. Формулирование и донесение центральной концепции является самым важным элементом в поддержании направленности проекта. В течение жизни проекта его концепция может меняться под воздействием внешних или внутренних факторов. Если подобные изменения произошли, то важно сразу изменить проект согласно новой концепции. Концепция дает представление о будущих пользователях. Способы использования и задачи этих пользователей должны быть выявлены при помощи собирательных образов ( per-sonas ). Концепция дает понять, привязан ли проект ко времени или к реализуемому функционалу. Сама концепция и связанная с ней деятельность создают надежный фундамент, на котором будет строиться весь проект.
Написание концепции | Обобщите всю известную о проекте информацию |
---|---|
Определение собирательных образов | Определите группы пользователей |
Уточнение собирательных образов | Определите характер отличий между собирательным образом и пользователем |
Операция: Написание концепции
Концепция - это короткая и точная формулировка цели создания новой системы или улучшения существующей. Она дает команде представление о проекте и его движущих факторах, а также содержит обоснование разработки системы. В концепции должно присутствовать высокоуровневое описание пользователей системы. Концепция должна также содержать описание потребностей пользователей и способов их удовлетворения разрабатываемым приложением. Наконец, концепция определяет, привязан ли выпуск системы к срокам или к функциональным возможностям. Концепция должна быть на писана языком, понятным будущим пользователям. Написание сжатой и предметной концепции является сложной задачей
Обобщение исходных данных проекта | Напишите один-два абзаца о контексте проекта. В них должна быть описана предпосылка создания новой системы или улучшения существующей |
---|---|
Объяснение движущих факторов | Опишите основные требования или выделенный интервал времени, которые управляют выпуском продукта. Будьте кратки |
Определение пользователей | Определите тех пользователей, которые получат наибольшую пользу от системы |
Определение основных достоинств | Опишите предполагаемые достоинства новой или улучшенной системы |
Операция: Определение собирательных образов
Собирательный образ - это вымышленный персонаж, представляющий группу пользователей. Собирательные образы используются для изучения потребностей целого сегмента пользователей путем рассмотрения характеристик одного вымышленного персонажа. Для определения собирательного образа изучите сегмент пользователей, взаимодействующих с системой, соберите их опыт, умения и цели, которые они разделяют. На основе этих данных создайте вымышленный персонаж, представляющий данный сегмент. Собирательный образ является также инструментом, с помощью которого можно получить информацию о пользователях, упомянутых в концепции. Собирательные образы используются при создании сценариев и при проведении исследовательских тестирований.
Определение ролей | Среди пользователей, определенных в концепции, выберите группу пользователей, взаимодействующих с системой |
---|---|
Создание собирательного образа | Для создания собирательного образа соберите реальные данные. Используйте данные, полученные в исследованиях удобства использования и при посещениях клиентов, в работе с фокус-группами и при маркетинговых исследованиях, чтобы убедиться, что собирательный образ представляет реальных пользователей |
Операция: Уточнение собирательных образов
Собрания и обзоры часто помогают выявить новые детали о способах использования и уровне знаний. Используйте такие собрания для проверки собирательных образов. Периодически уточняйте их, чтобы они соответствовали текущей целевой аудитории системы. Если в собирательных образах происходят изменения, сообщайте об этом заказчику.
Определение отличий | Выявляйте сходства и различия в уровне знаний, способах использования, взаимодействии и задачах, имеющиеся между собирательным образом и реальным пользователем. Если нашлись такие отличия, разберитесь, является ли пользователь тем, кого описывает собирательный образ |
---|---|
Обновление и передача изменений | Добавьте новые собирательные образы и измените существующие |
Разработка требований к качеству
Требования к качеству используются для описания нефункциональных требований или ограничений на функциональные возможности системы. Требования к качеству должны быть точными и не быть субъективными. Они выявляются, им присваиваются приоритеты и - если они запланированы на текущую итерацию - документируются.
Определение требований к качеству путем "мозгового штурма" | Определите цели требований к качеству |
---|---|
Создание моментальных снимков деятельности собирательного образа | Определите характерный промежуток времени действий собирательного образа |
Определение приоритетов в списке требований к качеству | Определите важность каждого требования |
Написание требований к качеству | Задокументируйте требования к качеству |
Определение требований безопасности | Задокументируйте требования к системе безопасности |
Операция: Определение требований к качеству путем мозгового штурма
Проведите коллективное обсуждение требований к качеству, проанализируйте каждый сценарий и определите, какие взаимодействия в них должны сопровождаться требованиями к качеству. Во время обсуждения выявите аспекты системы, для которых в сценариях были пропущены необходимые требования к качеству. Список требований к качеству содержит нефункциональные требования к приложению, он же является списком ограничений функциональных возможностей системы. Бизнес-аналитик каждый раз переоценивает и корректирует список требований к качеству, когда в процессе тестирования выявляются новые требования или когда появляются изменения в проекте.
Определение необходимых уровней качества | В папке требований Проводника команды ( Team Explorer ) откройте список требований к качеству. Он связан с проектом. Если необходимо, импортируйте описатели требований к качеству, которые были созданы непосредственно в Проводнике команды |
---|---|
Определение требований к качеству | Проанализируйте сценарии на предмет соответствия желаемым стандартам качества всех моментов, связанных с взаимодействием пользователя и системы |
Операция: Создание моментальных снимков деятельности
Моментальные снимки деятельности - это необязательные средства, которые используются совместно с моделью собирательного образа. При написании сценариев моментальные снимки помогают конкретизировать некоторые детали. Моментальный снимок деятельности - это описание одного дня или короткого периода в жизни собирательного образа. При этом всегда описывается текущее состояние, без применения предлагаемой технологии, что помогает продемонстрировать, чем новая система или продукт будут полезны для пользователя. Работая с конкретными примерами деятельности, проще оценить пользу от каждого сценария и назначить им на основании этого приоритеты.
Создание прототипа рабочего дня собирательного образа | Для каждого собирательного образа выделите один или несколько периодов времени в их жизни |
---|---|
Поиск технологических возможностей | Изучите каждый день собирательного образа и выявите места, где применение продукта оказывается полезным пользователю за счет решения каких-либо его задач или расширения возможностей |
Операция: Определение приоритетов в списке требований к качеству
Приоритеты в списке требований к качеству определяются, исходя из их важности и оказываемого влияния на пользователя. Требования, которые наиболее важны , пользователю, должны реализовываться в первую очередь. Список требований к качеству, упорядоченных по приоритетам, включается в план итерации. Тот, в свою очередь, используется при планировании разработки для повышения эффективности использования ресурсов. При добавлении или удалении требований, а также при изменении потребностей пользователей следует заново определить приоритеты списка требований к качеству.
Операция: Написание требований к качеству
Требования к качеству используются для описания нефункциональных требований или ограничений на функциональные возможности системы. Требования к качеству должны быть точными и не быть субъективными. Их описание должно предоставлять достаточно информации разработчикам, чтобы те могли спроектировать и запрограммировать функциональные возможности, удовлетворяющие этим требованиям.
Документирование требования к качеству | Опишите требование к качеству в поле описания его описателя. При разработке требований к качеству используйте следующий языковой шаблон: "контекст", "воздействие", "ответ". Требование к качеству должно быть таким, чтобы его можно было протестировать. Проектирование оставьте архитекторам и разработчикам |
---|---|
Прикрепление вспомогательной информации | К требованию к качеству прикрепите связанные с ним сценарии, если таковые имеются. Если требование к качеству затрагивает все сценарии или большинство из них, просто укажите это вместо того, чтобы прикреплять их все |
Операция: Определение требований безопасности
Требования к системе безопасности определяют уровень, до которого система будет защищать себя и ресурсы. Это могут быть конфиденциальные данные, требования закона или нематериальные активы, такие как репутация компании, торговые секреты или интеллектуальная собственность. Требования к системе безопасности должны быть конкретны, а для защищаемых ресурсов должна быть возможность проверки защиты. Способ защиты описывать не нужно. Требования к системе безопасности обычно формулируются предложениями, начинающимися с глагола, например: "Предотвратить доступ неавторизованных пользователей к учетным записям клиентов". Защищаемые ресурсы должны быть четко определены.
Документирование требований к системе безопасности | Опишите требования к системе безопасности в поле описания описателя требования к качеству. Убедитесь, что требования к системе безопасности обращены на конкретные ресурсы и могут быть протестированы. Проектирование оставьте архитекторам и разработчикам |
---|---|
Прикрепление вспомогательной информации | Прикрепите ссылки на законодательные акты, если они имеются. Прикрепите все сценарии, относящиеся к задачам обеспечения безопасности. Если требование к системе безопасности затрагивает все сценарии или большинство из них, просто укажите это вместо того, чтобы прикреплять их все |