Реферат: Краткий обзор системы

Содержание

Краткий обзор системы……………….…………..………………………..2

Стадии разработки АИС в RUP IBM……………………………………...3

Роли………………………………………………………………………...….6

Артефакты………………………………………….………………………12

Стандарт ISO/IEC 12207………………………….……………...………14

Стандарт ISO/IEC 15288………...………………………………………..17

Разработка артефакта «Прототип пользовательского интерфейса…………………………………………………...…………..…19

Заключение…………………………………………………………………..23



1. Краткий обзор системы.


Rational Unified Process. Методология и технология


IBM Rational Unified Process (RUP) — это новый подход к разработке ПС, основанный на использовании лучших практических методов, успешно зарекомендовавших себя во многих проектах разработки ПС по всему миру;

— четко определенный процесс (технологическая процедура), описывающий структуру жизненного цикла проекта, роли и ответственности отдельных исполнителей, выполняемые ими задачи и используемые в процессе разработки модели, отчеты и т.д.;

— готовый продукт, предоставляемый в виде веб-сайта, содержащего все необходимые модели и документы с описанием процесса.

Подход к разработке

RUP предлагает разработчикам не жесткие правила, регламентирующие выполнение всех действий в ходе разработки, а набор достаточно гибких методов и подходов, из которых разработчик может выбирать то, что более всего соответствует его задачам и особенностям проекта.

Основными принципами RUP являются итерационная разработка, управление процессом на основе прецедентов использования и ориентация на архитектуру.

^ IBM Rational Unified Process — это итерационный процесс. Создавать современные сложные программные системы последовательно, т.е. сначала определять все проблемы, затем принимать все проектные решения, формировать ПС и, наконец, проверять изделие, невозможно. Такой подход (называемый каскадным подходом или «водопадом») в современной информационной индустрии не оправдывает себя, поскольку его использование часто приводит к непредсказуемому увеличению проектной стоимости и сроков выпуска ПС. Эффективной альтернативой «водопаду» служит итерационный процесс разработки ПС.

При итерационном процессе каждая из фаз процесса разработки ПС состоит из итераций, целью которых является последовательное осмысление стоящих проблем, наращивание эффективности решений и снижение риска потенциальных ошибок в проекте. На выходе каждой итерации создается законченная версия работающего программного продукта.

При таком подходе можно гибко учитывать новые требования или производить тактические изменения в деловых целях, такой подход позволяет выявлять проблемы и разрешать их на самых ранних этапах разработки, что связано с меньшими затратами.

Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой.


^ IBM Rational Unified Process — процесс, управляемый на основе прецедентов. Это означает, что в качестве метода описания функциональных требований к системе, а также в качестве естественной единицы для дальнейшего планирования и оценки выполнения работ используются сценарии использования. Сценарии использования позволяют легко выявлять реальные потребности будущих пользователей системы и отслеживать полноту описания этих требований. Они гарантируют выполнения требований заказчика к ПС. Кроме того, использование завершенных сценариев в качестве единицы измерения прогресса помогает избежать неадекватной оценки степени выполнения проекта исполнителем.

IBM Rational Unified Process предполагает разработку, реализацию и тестирование архитектуры на самых ранних стадиях выполнения проекта. Такой подход позволяет устранять самые опасные риски, связанные с архитектурой, на ранних стадиях разработки. Благодаря ему удается избежать существенных переработок в последний момент, если вдруг выяснится, что выбранное решение не обеспечивает, к примеру, выполнение требований к производительности системы.


^ 2. Стадии разработки АИС в RUP IBM.


RUP создавался по методике, используемой при проектировании ПС. В частности, моделирование производилось с помощью Software Process Engineering Metamodel (SPEM) — стандарта моделирования процессов, основанного на Unified Modeling Language (UML). У процесса есть два измерения:

Динамическая структура. Горизонтальное измерение представляет собой динамическую структуру или временное измерение процесса. Оно показывает, как процесс, выраженный в форме циклов, фаз, итераций и вех, развертывается в ходе жизненного цикла проекта.

Статическая структура. Вертикальное измерение представляет собой статическую структуру процесса. Оно описывает, как элементы процесса — задачи, дисциплины, артефакты и роли — логически группируются в дисциплины или рабочие процессы (workflows).




Динамическая структура RUP состоит из четырех фаз: Inception, Elaboration, Construction и Transition. Фазы могут подразделяться на итерации. Переход с фазы на фазу возможен только после выполнения задач фазы и представляет собой контрольную точку (milestone) процесса.

Статическая структура RUP состоит из дисциплин, в которые группируются работы, задачи, артефакты и роли. Для описания осмысленной последовательности выполнения работ и задач используются рабочие процессы. Они описывают кто, что, как и когда выполняет в процессе. В RUP входят 6 основных дисциплин:

— Бизнес-моделирование (Business modeling);

— Управление требованиями (Requirements);

— Анализ и Проектирование (Analysis and Design);

— Реализация (Implementation);

— Тестирование (Test);

— Развертывание (Deployment).

И три вспомогательные:

— Управление проектом (Project management);

— Управление изменениями (Change management);

— Среда (Environment).

Моделирование бизнес-процессов применяется с тем, чтобы разобраться в структуре исследуемой предметной области, обеспечить единство понимания основных автоматизируемых процессов среди всех участников проекта и определить высокоуровневые требования, которые должны быть реализованы в ходе проекта.

Управление требованиями позволяет прийти к соглашению с заказчиками и конечными пользователями, определить, что должна уметь делать создаваемая система, предоставить более четкие инструкции участникам проекта о возможностях системы, создать базу для успешного планирования работ в проекте и оценки его статуса в любой момент жизненного цикла.

Анализ и проектирование служат для последовательного преобразования выявленных требований к системе в спецификации особого вида, которые описывают, как следует конкретно реализовать конечный продукт. Следует при этом делать различия между анализом и проектированием. Основное из них состоит в том, что спецификации анализа не зависят от конкретной платформы и технологии, для которой осуществляется создание ИС. А спецификации проектирования являются точным представлением проектируемой системы, часто позволяя автоматизировать процесс генерации на их основе программного кода.

Реализация необходима для выявления порядка организации программного кода в терминах отдельных подсистем, преобразования исходного кода в выполняемые компоненты, тестирования созданных компонентов и интеграции отдельных компонентов в подсистемы и системы.

Тестирование позволяет определять и контролировать качество создаваемых продуктов, следить за тем, насколько качественно осуществлена интеграция компонентов и подсистем, все ли требования к системе реализованы и все ли выявленные ошибки устранены до того, как система будет развернута на оборудовании конечного пользователя.

Развертывание является процессом, в ходе которого осуществляется доставка разрабатываемого продукта к конечному пользователю. В ходе данного процесса производится новый выпуск системы, распространение ПО, его установка на стороне конечного пользователя, обучение последнего навыкам эффективной работы с поставленным ПО, предоставление услуг по технической поддержке, бета-тестирование и т. п.

Конфигурационное управление и управление изменениями позволяет организовать эффективную работу с артефактами проекта, контролировать и управлять доступом к ним, вести историю изменений, обеспечить эффективное взаимодействие участников проекта, как в простых командах, так и в распределенных, находящихся на большом удалении друг от друга.

Управление проектом включает в себя непосредственное формирование условий для эффективного хода всего проекта, определение руководств и руководящих принципов для планирования, формирования команды и мониторинга проекта, выявление и управление рисками, организацию работы участников проекта, формирование бюджета, планирование фаз и итераций.

Управление средой позволяет осуществить поддержку всех участников проекта. В эту поддержку входят выбор инструментария и его приобретение, настройка и установка, конфигурирование процесса, доработка и адаптация методологии, используемой для ведения проекта, обучение.


В отличие от каскадного подхода ( «водопада»), в RUP все дисциплины выполняются практически во всех фазах жизненного цикла ПС. Однако, в зависимости от фазы, меняются текущие цели проекта и соотношение между объемами работ, соответствующих различным дисциплинам.

Так фаза Inception посвящена определению границ системы и устранению экономических рисков (в частности, именно здесь принимается решение о том, имеет ли смысл продолжать разработку). Основное внимание в ней уделяется моделированию бизнес процессов и работе с требованиями. В этой фазе, как правило, осуществляется проектирование и реализация первого прототипа системы.

Фаза Elaboration, посвящена тщательной проработке требований и выбору основных проектных решений. В этой фазе концептуальный прототип превращается в реальную систему, позволяющую протестировать и оценить выбранные архитектурные решения. В результате, к концу фазы команда готова к быстрой и качественной разработке основного объема кода системы. Наличие тщательно проработанной устойчивой архитектуры гарантирует, что в дальнейшем не придется перерабатывать большие фрагменты системы.

В фазе Construction основными задачами становится быстрая и экономичная разработка кода системы. К концу фазы система должна быть готова к передаче заказчику для бета-тестирования и/или приемо-сдаточных испытаний.

Фаза Transition жизненного цикла посвящена подготовке разработанного продукта к передаче его заказчику или к тиражированию и распространению (если это «коробочный» продукт).


3. Роли
Роль – это элемент методологии, который описывает набор связанных навыков, компетенций и ответственностей. Роли используются в контексте Задач, для определения того кто реально будет выполнять Задачи в зависимости от ответственности за те артефакты которые используются в задаче. Каждый работник как бы примеряет на себя разные шляпы, или выполняет разные Роли.

Роль обычно выполняет один работник, или группа людей работающая как команда. Член проектной команды обычно выполняет несколько ролей. Учтите что Роль это не человек и не всегда соответствует должностям, Роли описывают сколько работников требуется в проекте и ответственности этих работников. Назначение ролей производится Менеджером проекта при планировании работ.

В то время как многие роли выполняются внутри организации, люди вне организации играют важную роль Заинтересованное лицо продукта или проекта.

Проанализированы и выделены (в соответствии с ТЗ) роли. Для каждой роли определены задачи.

^ Архитектор программного средства

Анализ архитектуры

Детальное описание

Идентификация механизмов

Идентификация элементов

Объединение разработанных элементов

Описание архитектуры в динамике

Оценка жизнеспособности

Приоритеты прецедентов

Разработка архитектурной концепции

Структурирование модели реализации

^ Проектировщик баз данных

Проектирование базы данных

Проектировщик тестов

Идентификация тестов

Определение порядка выполнения тестов

Определение тестового подхода

^ Разработчик документации

Разработка артефактов инсталляции

Разработка сопроводительной

Разработчик интерфейса пользователя

Разработка интерфейса пользователя

^ Разработчик кода

Анализ динамики системы

Выполнение разработанных тестов

Разработка классов

Разработка подсистем

Разработка прецедентов

Реализация разработанных тестов

Реализация спроектированных

^ Рецензент архитектуры

Рецензирование архитектуры

Рецензент кода

Рецензирование кода

Рецензент проекта

Организация рецензирования

Рецензирование критериев оценки

Рецензирование плана итерации

Рецензирование плана создания

Рецензирование полномочий

Рецензирование проекта

Рецензирование разработки

Рецензирование требований

^ Руководитель проекта

Верификация созданного продукта

Детализация прецедентов

Допуск к производству

Инициализация итераций

Инициализация проекта

Интеграция подсистем

Интеграция системы

Обеспечение разработки

Определение структуры и штата

Оценка итераций

Планирование интеграции подсистем

Планирование интеграции системы

Планирование фаз и итераций

Развитие плана развертывания

Разработка модели предметной области

Разработка плана итераций

Расписание и назначение работ

Создание компонент развертывания

Составление списка устраненных

Управление бета-тестированием

Управление тестами приема/сдачи

Уточнение требований к программному

Формирование штата

^ Системный аналитик

Определение потребностей заказчика

Поиск акторов и прецедентов

Разработка документа-концепции

Составление общего словаря

Структурирование модели прецедентов

Тестировщик

Выполнение набора тестов

Определение результатов тестирования

Оценивание и подтверждение качества

Реализация набора тестов


Роль «Менеджер конфигурации»


Менеджер конфигурации занимается полным обеспечением инфраструктуры УК и среды для разработки продукта. Функция УК поддерживает задачу разработки продукта, с тем чтобы разработчики и Интегратор имели соответствующие рабочие пространства для выполнения и тестирования своей работы, и для того, чтобы все артефакты были доступны для включения должным образом в инсталляционный пакет. Менеджер конфигурации должен следить за тем, чтобы среда УК облегчала рецензирование продукта и задачи изменения и отслеживания дефектов. Также в обязанности Менеджера конфигурации входит написание Плана УК и формирование статистического отчета о состоянии работ на основании запросов на изменение.


На рисунке 12 представлены выполняемы ролью задачи и артефакты за которые эта роль несет ответственность.





Рисунок 12 Задачи и артефакты


Менеджер конфигурации должен знать принципы УК, и, желательно, иметь опыт работы или пройти курс обучения по использованию инструментальных средств УК. Сотрудник качественно выполняющий роль Менеджер конфигурации уделяет внимание деталям. Он должен быть напористым, для обеспечения того, чтобы разработчики не пренебрегали правилами и процедурами УК.


Несколько примеров, как назначать на данную роль:

назначение одного сотрудника на две роли Менеджер конфигурации и Интегратор подходит для маленьких и средних проектов.

назначение одного сотрудника на две роли Менеджер конфигурации и Менеджер развертывания. Данная стратегия подходит для маленьких и средних проектов, в которых дисциплина Развертывание слабо формализована.


Роль «Менеджер контроля изменений»


В обязанности Менеджера контроля изменений входит наблюдение за процессом УИ. Эту роль обычно исполняет ГКИ, состоящая из представителей всех заинтересованных сторон, включая заказчиков, разработчиков, и пользователей. В маленьких проектах, эту роль может играть один член команды, например, Менеджер проекта или Архитектор.


Менеджер контроля изменений также занимается определением процесса УЗИ, который формализован в План УК.


На рисунке 3.2 представлены выполняемы ролью задачи и артефакты за которые эта роль несет ответственность.





Рисунок 13 Задачи и артефакты


Менеджер контроля изменений должен знать принципы УК. Он должен иметь навыки по оценке стоимости и планированию влияний ЗИ. Он должен быть достаточно коммуникабелен, для того чтобы проводить обсуждения масштабных изменений и, чтобы определять кому и как следует проводить ЗИ.


Роль «Интегратор»


Протестированные компоненты Исполнители передают в интеграционное рабочее пространство, где Интегратор осуществляют их сборку. Интегратор несет ответственность за планирование интеграции, проводимое на уровнях подсистем и всей системы, каждая из которых имеет свое отдельное интеграционное рабочее пространство. Протестированные компоненты из персонального рабочего пространства разработчика передаются в интеграционные рабочие пространства подсистем, а те, в свою очередь, вливаются в интеграционное рабочее пространство системы в целом.


На рисунке представлены выполняемы ролью задачи и артефакты за которые эта роль несет ответственность.




Рисунок 14 Задачи и артефакты


От сотрудника выполняющего эту роль требуется:

знание интегрируемой системы или её части подлежащей интеграции. В частности Интегратор должен знать о зависимостях между элементами реализации и подсистемами реализации, и как эти зависимости меняются в ходе разработки;

хорошее знание инструментария интеграции.


Интегратор должен обладать хорошими координационными способностями, для работы с несколькими разработчиками.


В некоторых случаях сотруднику, исполняющему роль Интегратор, могут быть назначены и обязанности Тестировщика. Например, если проект небольшой, а также при интеграции на уровне подсистемы роли Исполнителя, Интегратора и Тестировщика вполне может выполнять один человек, обеспечивая тем самым экономию ресурсов. Однако на уровне всей системы рекомендуется, чтобы интеграция и тестирование выполнялись независимыми группами.


Роль «Участник проекта»


Участник проекта в RUP, обладая правами доступа, может регистрировать и проверять в системе УК любой связанный с продуктом артефакт поддержки. Он также может представлять на рассмотрение ЗИ и делать исправления в своих ЗИ.


На рисунке 3.4 представлены выполняемы ролью задачи и артефакты за которые эта роль несет ответственность.





Рисунок 15 Задачи и артефакты


Участник проекта может выполнять любой член проектной команды назначенный хотя бы на одну из ролей RUP.Соответственно требования к сотруднику определяться назначенной ролью, а также знанием задач выполняемых ролью Участник проекта.


Роль Участник проекта выполняется всеми членами проектной команды. Поэтому назначение данной роли происходит по умолчанию.
4. Артефакты
Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом.

Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов. Причем то, что попадает в руки конечного пользователя, будь то программный модуль или программная документация, - это один из подклассов всех артефактов проекта.

Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист разрабатывает программу, руководитель - проектный план, а аналитик - модели системы. RUP позволяет определить, когда, кому и какой артефакт необходимо создать.

Система гиперссылок построена таким образом, что можно легко переходить от работ к артефактам, создаваемым в процессе конкретной деятельности, а через них к ролям исполнителей и обратно. К артефактам можно добраться различными путями - например, через список процессов, примеры итераций, роли исполнителей, а можно просто найти нужный артефакт в дереве ссылок, что позволяет рассматривать один и тот же процесс разработки с различных точек зрения - руководителя и исполнителя, пользователя и программиста.

В ходе анализа RUP определены следующие артефакты:

Архитектура программного средства Software Architecture Document

Документ по инсталляции Instaliation Artifacts

Документ-концепция Vision

Журнал тестирования Test Log

Интерфейс Interface

Инфраструктура разработки Development Infrastructure

История изменения требований Storyboard

Компоненты развертывания Deployment Unit

Конфигурация тестовой среды Test Enviroment Configuration

Модель данных Data Model

Модель предметной области Business Case

Модель прецедентов использования Use-Case Model

Модель развертывания Deployment Model

Модель разработки Design Model

Модель реализации Implementation Model

Набор тестов Test Suide

Отчет о тестировании Test Evalution Summary

Отчет рецензента Review Record

Оценка итераций Iteration Assessment

План итераций Iteration Plan

План приема/сдачи продукта Product Acceptance Plan

План развертывания Deployment Plan

План создания программного средства Software Development Plan

План тестирования Test Plan

Порядок работ Work Order

Прецеденты Use-Case

Продукт Product

Проект подсистем Design Subsystem

Прототип пользовательского интерфейса User-Interface Prototype

Реализация подсистем Implementation Subsystem

Результат тестирования Test results

Руководство пользователя End-User Support Material

Сборка Build

Сборка прецедентов Use-Case Package

Словарь Glossary

Спецификация требований к ПО Software Requirement Specification

Список акторов Actor

Список потребностей заинтересованных лиц Stakeholder Request

Список тестов Test-Ideals List

Список требований Change Request

Список устраненных замечаний Release Notes

Стратегия тестирования Test Strategy

Требования к ПО Software Requirement


Весь процесс разработки с точки зрения RUP рассматривается в двух плоскостях. В динамике процесс выражается через циклы, фазы, итерации и вехи, а в статике - через виды деятельности, технологические процессы, артефакты и роли исполнителей.


^ 5. Стандарт ISO/IEC 12207


ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов [5].


Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.


Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML .


В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:


1. Основные процессы:

приобретение;

поставка;

разработка;

эксплуатация;

сопровождение.


2. Вспомогательные процессы:

документирование;

управление конфигурацией;

обеспечение качества;

разрешение проблем;

аудит;

аттестация;

совместная оценка;

верификация.


3. Организационные процессы:

создание инфраструктуры;

управление;

обучение;

усовершенствование.


В таблице 1.1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами.

Таблица 2.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

^ Процесс (исполнитель процесса)

Действия

Вход

Результат

Приобретение (заказчик)

инициирование

Подготовка заявочных предложений

Подготовка договора

Контроль деятельности поставщика

Приемка ИС

Решение о начале работ по внедрению ИС

Результаты обследования деятельности заказчика

Результаты анализа рынка ИС/ тендера

План поставки/ разработки

Комплексный тест ИС

Технико-экономическое обоснование внедрения ИС

Техническое задание на ИС

Договор на поставку/ разработку

Акты приемки этапов работы

Акт приемно-сдаточных испытаний

Поставка (разработчик ИС)

инициирование

Ответ на заявочные предложения

Подготовка договора

Планирование исполнения

Поставка ИС

Техническое задание на ИС

Решение руководства об участии в разработке

Результаты тендера

Техническое задание на ИС

План управления проектом

Разработанная ИС и документация

Решение об участии в разработке

Коммерческие предложения/ конкурсная заявка

Договор на поставку/ разработку

План управления проектом

Реализация/ корректировка

Акт приемно-сдаточных испытаний

Разработка (разработчик ИС)

Подготовка

Анализ требований к ИС

Проектирование архитектуры ИС

Разработка требований к ПО

Проектирование архитектуры ПО

Детальное проектирование ПО

Кодирование и тестирование ПО

Интеграция ПО и квалификационное тестирование ПО

Интеграция ИС и квалификационное тестирование ИС

Техническое задание на ИС

Техническое задание на ИС, модель ЖЦ

Техническое задание на ИС

Подсистемы ИС

Спецификации требования к компонентам ПО

Архитектура ПО

Материалы детального проектирования ПО

План интеграции ПО, тесты

Архитектура ИС, ПО, документация на ИС, тесты

Используемая модель ЖЦ, стандарты разработки

План работ

Состав подсистем, компоненты оборудования

Спецификации требования к компонентам ПО

Состав компонентов ПО, интерфейсы с БД, план интеграции ПО

Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам

Тексты модулей ПО, акты автономного тестирования

Оценка соответствия комплекса ПО требованиям ТЗ

Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ



^ 6. Стандарт ISO/IEC 15288

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

Договорные процессы:

приобретение (внутренние решения или решения внешнего поставщика);

поставка (внутренние решения или решения внешнего поставщика).

Процессы предприятия:

управление окружающей средой предприятия;

инвестиционное управление;

управление ЖЦ ИС;

управление ресурсами;

управление качеством.

Проектные процессы:

планирование проекта;

оценка проекта;

контроль проекта;

управление рисками;

управление конфигурацией;

управление информационными потоками;

принятие решений.

Технические процессы:

определение требований;

анализ требований;

разработка архитектуры;

внедрение;

интеграция;

верификация;

переход;

аттестация;

эксплуатация;

сопровождение;

утилизация.

Специальные процессы:

определение и установка взаимосвязей исходя из задач и целей.

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 1.2.

Таблица 1.2. Стадии создания систем (ISO/IEC 15288)

№ п/п

Стадия

Описание

1

Формирование концепции

Анализ потребностей, выбор концепции и проектных решений

2

Разработка

Проектирование системы

3

Реализация

Изготовление системы

4

Эксплуатация

Ввод в эксплуатацию и использование системы

5

Поддержка

Обеспечение функционирования системы

6

Снятие с эксплуатации

Прекращение использования, демонтаж, архивирование системы


^ 7. Разработка артефакта «Прототип пользовательского интерфейса»
Цель

Разработать прототип пользовательского интерфейса системы, чтобы попытаться проверить правильность конструкции пользовательского интерфейса по отношению к функциональным требованиям и требованиям по простоте работы.

Роль:  Конструктор пользовательского интерфейса 

Частота: По необходимости, обычно один раз либо за Начальную фазу, либо за фазу Развития, там, где требуется пользовательский интерфейс.

Шаги, соответствующие стандарту ISO/IEC 15288

Разработка прототипа пользовательского интерфейса

Реализация пользовательского интерфейса

Получение отклика о прототипе пользовательского интерфейса

На практике, разработка прототипа пользовательского интерфейса обычно выполняется вместе с разработкой самого пользовательского интерфейса (см. Деятельность: Разработка пользовательского интерфейса). Во время разработки пользовательского интерфейса вы должны разработать прототип вашей конструкции и ознакомить с ней других, принимая во внимание все руководства по проекту.

Начало деятельности: 

Актор

Навигационная карта

Специальные руководства по проекту

Работа с архивными документами

Дополнительные спецификации

Прецедент использования

 

Конец деятельности: 

Прототип пользовательского интерфейса

 

Менторы инструментов:   

Подробная информация: 

Концепция: прототип



Подробности технологического процесса: 

Анализ и проектирование

Анализ поведения

 

При разработке прототипа пользовательского интерфейса, принимайте во внимание структуру пользовательского интерфейса, работу с архивными документами и руководства по пользовательскому интерфейсу в специальных руководствах по проекту. Если обнаружится, что архивным документам нужны обновления в результате этой деятельности, то они выполняются Аналитиком системы (См. Деятельность: Установление требований заказчиков). Если обнаружится, что обновления нужны структуре пользовательского интерфейса, то они выполняются Конструктором пользовательского интерфейса (См. Деятельность: Разработка пользовательского интерфейса.
^ Разработка прототипа пользовательского интерфейса