
- •2 Жизненный цикл программного обеспечения. Дать краткую характеристику каждого этапа.
- •3 Почему программные системы сложны. Привести пять признаков сложной системы.
- •4 Техническое задание. Перечислить и охарактеризовать разделы, входящие в техническое задание.
- •5 Унифицированный процесс разработки программного обеспечения. Основные принципы унифицированного процесса.
- •6 Жизненный цикл унифицированного процесса. Цели каждого из этапов.
- •7 Работа с кадрами. Перечислить роли разработчиков и дать характеристику каждой из них.
- •8 Использование языка uml при проектировании сложных программных систем. Какие диаграммы используются в uml для создания моделей программной системы.
- •9 Диаграмма вариантов использования, ее назначение. Рассказать о варианте использования и действующем лице. Правила построения диаграммы вариантов использования.
- •10 Что такое классификация с точки зрения объектно-ориентированного проектирования программных систем. Теории классификации.
- •11 Методы классификации.
- •12 Диаграммы взаимодействия. Основное назначение.
- •13 Диаграмма классов. Ее назначение. Что она включает. Рассказать об основных видах связей между классами.
- •14 Дать определение тестированию и отладке. Особенности и объекты тестирования. Автономное и комплексное тестирование.
- •15 Дать определение тестированию и отладке. Направления тестирования. Стратегия тестирования. Контрольный лист тестирования модуля.
- •16 Дать определение тестированию и отладке. Локализация ошибок. Классификация ошибок.
- •17 Документирование. Состав и содержание документов прилагаемых к программной системе.
- •18 Оценка качества ПрогОбесп. Методы оценки свойств ПрогОбес.
- •19 Уровни зрелости организации с точки зрения cmm.
- •20 Понятие стандарта. Что включает в себя стандарт.
- •21 Сертификация. Схемы сертификации.
- •22 Психологич факторы проектирования интерфейса пользователя.
- •23 Правила построения удобного интерфейса пользователя.
- •24 Принципы построения интерфейса пользователя.
- •25 Проектирование, ориентированное на использование.
5 Унифицированный процесс разработки программного обеспечения. Основные принципы унифицированного процесса.
Унифицированный процесс – это обобщённый каркас процесса создания ПП, который м.б. специализирован для широкого круга программных систем. Для разработки модели программной системы унифицированный процесс использует унифицированный язык моделирования.
начинайте вести наступлении на главные риски, ведите его непрерывно, иначе риски пойдут в наступления на вас.
обеспечьте выполнение требований заказчика: документируйте требования в виде понятном заказчику, и в ходе проектировании и реализации строго придерживайтесь этих требований
сконцентрируйтесь на выполняемой программе: работающий программный продукт, проходящий тесты лучше, чем всеобъемлющая документация
приспосабливайтесь к изменениям с самого начала проекта: современные приложения достаточно сложны, чтобы мы смогли получить конкретные требования в самом начале разработки. Поэтому необходимо закладывать архитектуру ПП таким образом, чтобы она была восприимчива к изменениям.
закладывайте основу исполняемой архитектуры как можно раньше. Исполняемая архитектура – ключевые варианты использования. Ключевой ВИ это та функциональность системы, без реализации которой ПП не имеет смысла. Ключ. ВИ составляют 7-10% от всех вариантов
стройте систему из компонентов. Приложения на основе компонентов создаются быстрее, более гибкие с точки зрении изменений, относительно низкая стоимость.
работайте как 1 команда
сделайте качество образом жизни, а не запоздалой идеей
6 Жизненный цикл унифицированного процесса. Цели каждого из этапов.
Унифицированный процесс циклически повторяется. Эта последовательность повторений Унифицированного процесса представляет собой жизненный цикл системы. Каждый цикл завершается поставкой выпуска продукта заказчикам.
Каждый цикл состоит из четырех фаз - анализа и планирования требований, проектирования, построения и внедрения. Каждая фаза, как будет рассмотрено ниже, далее подразделяется на итерации.
В ходе фазы анализа и планирования требований хорошая идея превращается в концепцию готового продукта и создается бизнесплан разработки этого продукта. В частности, на этой фазе должны быть получены ответы на вопросы:
Что система должна делать в первую очередь для ее основных пользователей?
Как должна выглядеть архитектура системы?
Каков план и во что обойдется разработка продукта?
На этом этапе создается пробный вариант архитектуры. Обычно он представляет собой набросок, содержащий наиболее важные подсистемы. На этой фазе выявляются и расставляются по приоритетности наиболее важные риски, детально планируется фаза проектирования и грубо оценивается весь проект.
В ходе фазы проектирования детально описываются большинство вариантов использования и разрабатывается архитектура системы.
В конце фазы проектирования менеджер проекта занимается планированием действий и подсчетом ресурсов, необходимых для завершения проекта. Ключевым вопросом в этот момент будет следующий: достаточно ли проработаны варианты использования, архитектура и план и взяты ли риски под контроль настолько, чтобы можно было давать контрактные обязательства выполнить всю работу по разработке?
В ходе фазы построения происходит создание продукта - к скелету (архитектуре) добавляются мышцы (законченные программы). На этой фазе базовый уровень архитектуры разрастается до полной развитой системы. Концепции развиваются до продукта, готового к передаче пользователям. В ходе фазы объем требуемых ресурсов вырастает. В конце этой фазы продукт включает в себя все варианты использования, которые руководство и заказчик договорились включить в текущий выпуск. Правда, они могут содержать ошибки. Большинство дефектов будут обнаружены и исправлены в ходе фазы внедрения. Ключевой вопрос окончания фазы: удовлетворяет ли продукт требованиям пользователей настолько, что некоторым заказчикам можно делать предварительную поставку?
Фаза внедрения охватывает период, в ходе которого продукт существует в виде бета-выпуска или бета-версии. Небольшое число квалифицированных пользователей, работая с бета-выпуском продукта, сообщает об обнаруженных дефектах и недостатках. После этого разработчики исправляют обнаруженные ошибки и вносят некоторые из предложенных улучшений в главный выпуск, подготавливаемый для широкого распространения. Фаза внедрения включает в себя такие действия, как производство тиража, тренинг сотрудников заказчика, организацию поддержки по горячей линии и исправление дефектов, обнаруженных после поставки.