25. Этапы анализа проблем в разработке кис

Анализ проблемы – это процесс осмысления реальных проблем и потребностей пользователя; пути решений для удовлетворения этих потребностей;

Анализ области проблем должен определить из множества возможных решений решение, наиболее соответствующее анализируемой проблеме. Целью анализа проблемы является необходимость добиться лучшего понимания решаемой проблемы до начала разработки, что можно осуществить с помощью пяти этапов: 1)достижение соглашения об определении проблемы; 2)выделение основных причин - проблем, состоящих за проблемами; 3)выявление круга заинтересованных лиц и пользователей; 4)определение границы системы решения; 5)выявление ограничений, которые необходимо наложить на решение.

Этап 1. Достижение соглашения об определении проблемы.

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

Этап 2. Выделение основных причин-проблем, стоящих за проблемой.

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

Этап 3. Выявление заинтересованных лиц и пользователей.

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

Этап 4. Определение границ системы-решения

Границы системы представляет собой «рубеж» между решением и окружающим его реальным миром. Все взаимодействия с системой осуществляются посредством интерфейсов между системой и внешним миром. Таким образом, мир делится на две части:

создаваемая система; то, что взаимодействует с создаваемой системой;

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

26. Унифицированный процесс в разработке кис

Унифицированный процесс (УП), предназначенный для получения ПО, представляет собой сумму различных видов деятельности, необходимых для преобразования требований пользователей в программную систему. Требования пользователей к разрабатываемой системе -> Процесс разработки ПО -> Программная система.

УП компонентно-ориентирован, т.е. создаваемая программная система строится на основе программных компонентов, связанных хорошо определенными интерфейсами.

Для разработки чертежей программной системы используется унифицированный язык программирования (UML). UML является неотъемлемой частью УП. УП и UML разрабатывались совместно. Специфические аспекты УП: 1)управляется вариантами использования; 2)архитектурно-ориентированный; 3)итеративный и инкрементный;

УП управляется вариантами использования

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

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

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

УП является итеративным и инкрементным. Для экономии времени разработки проекта и правильного распределения работы между исполнителями предлагается разделить проект на отдельные мини-проекты.

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

требования; варианты использования;

нефункциональные требования;

варианты тестирования;

Полное представление готового продукта состоит из:

- модели вариантов использования

- модели анализа

- модели проектирования

- модели реализации

- модели развертывания

- модели тестирования

- представления архитектуры

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