Материал: ответы_экзамен

1. Модели жизненного цикла программных систем.

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

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

• каскадная модель;

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

•  спиральная модель .

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

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

2. Методы усовершенствования процесса разработки ПО (CMM, ISO 9000, ISO 20000).

CMM (Capability Maturity Model) описывает модель зрелости процессов разработки программного обеспечения на предприятиях. В рамках этой модели для каждой компании может быть сопоставлен некоторый уровень (один из пяти возможных), свидетельствующих о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались, прежде всего, в целях упорядочивания процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО проектам, в то время как технические аспекты разработки освещены меньше.

В версии SW-CMM v.1.1 (Capability Maturity Model for Software) имеется 316 Key Practices. Key Practices - это то, что должно быть внедрено на предприятии и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области - Key Practices Areas (KPA) - это уже совокупности взаимосвязанных процессов, которые при совместном выполнении и приводят к достижению определенного набора целей.

CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее приемлемой для разработчиков программных систем, - количество Key Practices достигает уже 417.

Увеличение Key Practices связано с самой целью разработки CMMI - модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей CMM.

ISO 9001. Наиболее популярным, и особенно,  в Европе, является ISO 9001.

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

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

Многие организации -разработчики ПО успешно используют именно эту широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии вышла в 2000 году и уже содержит в себе такие понятия, как процессный подход, анализ и измерения,  совершенствование процессов, заимствованные из модели СММ и ранее отсутствовавшие в предыдущих версиях ISO 9000. Правда, следует заметить, что стандарты этой серии универсальны - они не ориентированы на какую либо конкретную отрасль, не учитывает специфики IT-сферы и, в этом смысле, конечно по степени конкретизации, заметно уступают СММ. Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия и, тем самым, затрудняет определение "истинных" возможностей той или иной организации и, соответственно, - путей их дальнейшего развития.

ISO 20000 – первый международный стандарт по управлению качеством ИТ-услуг, он состоит из двух частей: «Information technology – Service management. Part 1: Specification» и «Information technology – Service management. Part 2: Code of Practice».

ISO 20000-1:2005 «Information technology – Service management. Part 1: Specification» содержит полное и подробное описание требований к системе управления ИТ-сервисами, а также ответственность за их в организациях. Первая часть состоит из 10 разделов, которые содержат 13 процессов в пяти ключевых группах:

• Процессы предоставления сервисов (Service delivery process). В группу входит управление уровнем сервисов, управление непрерывностью и доступностью, управление мощностями, отчетность по предоставлению сервисов, управление информационной безопасностью, бюджетирование и учет затрат.

• Процессы управления взаимодействием (Relationship processes). Эта область включает в себя управление взаимодействием с бизнесом, управление поставщиками.

• Процессы разрешения (Resolution processes). Разработчики стандарта фокусируются на инцидентах, которые удалось предотвратить или успешно разрешить, – управление проблемами, управление инцидентами.

• Процессы контроля (Control processes). В данном разделе рассматриваются процессы управления изменениями и конфигурациями.

• Процессы управления релизами (Release process). Речь идет о выработке новых и коррекции уже имеющихся решений.

ISO 20000-2:2005 «Information technology – Service management. Part 2: Code of Practice» – это практическая часть, в которой содержатся рекомендации по процессам и требованиям, описанным в первой части. Состоит из 10 разделов и предназначена для аудиторов и компаний, намеренных пройти сертификацию.

Оценка ИТ-сервисов согласно требованиям ISO 20000-1:2005 дает возможность увидеть объем нереализованности управления, что позволяет запланировать его выполнение по рекомендациям ISO 20000-2:2005, библиотеки ITIL® или любой другой методологии. Использование данных методологий не является обязательным, но в значительной мере упрощает процесс перехода к сервисной модели и делает его более понятным.

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

3. Унифицированный процесс. Основные принципы УП.(Денис)

Унифицированный процесс (Unified Process, UP) – это методология моделирования программных систем.  

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

К отличительным особенностям унифицированного процесса можно также отнести следующие

принципы:

1. Оценка рисков и ключевых моментов проекта на ранних итерациях.

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

3. Построение общей базовой архитектуры на ранних итерациях.

4. Постоянный контроль качества, раннее и качественное тестирование в реальных условиях.

5. Применение прецедентов.

6. Визуализация программной модели с помощью uml.

7. Итеративность и инкрементальность.

Однако на практике унифицированный процесс является скорее адаптивным и гибким, что обеспечивается следующим образом:

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

2. В силу итеративного характера унифицированного процесса анализ требований и проектирования не завершается к моменту начала реализации. Требование и модель проектирования адаптивно настраиваются в течении нескольких итераций на основе обратной связи.

3. Применение языка UML вместе с приемами гибкого моделирования.

4. Детальное планирование выполняется итеративно от итерации к итерации.

4.Фазы, рабочие процессы, модели уп.

Фазы унифицированного процесса.

В рамках унифицированного процесса работа над проектом включает 4 фазы:

1. Начало (inception) Определение начального видения проекта, прецедентов, определение сложности задачи.

2. Развитие (elaboration). Формирование более полного видения проекта, итеративная реализация базовой архитектуры. Создание наиболее критичных компонентов. Идентификация основных требований. Получение более реалистичных оценок.

3. Построение (construction). Итеративная реализация оставшихся менее критичных и простых компонентов, подготовка к развертыванию.

4. Внедрение (transition) – конец итерации, где получены важные решения и оценки. Release – стабильно работающая часть ПО. Инкремент – разница между релизом и двух последующих итераций. Finale production release – система готова для коммерческого использования.

Наиболее важные с точки зрения RUP артефакты проекта — это модели, описывающие различные аспекты будущей системы. Большинство моделей представляют собой наборы диаграмм UML. Основные используемые виды моделей следующие:

• Модель вариантов использования (Use-CaseModel).

Эта модель определяет требования к ПО — то, что система должна делать — в виде набора вариантов использования.

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

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

• Модель анализа (AnalysisModel).

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

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

Модель реализации (ImplementationModel). Под моделью реализации в рамках RUP и UML понимают набор компонентов результирующей системы и связей между ними. Под компонентом здесь имеется в виду компонент сборки — минимальный по размерам кусок кода системы, который может участвовать или не участвовать в определенной ее конфигурации, единица сборки и конфигурационного управления. Связи между компонентами представляют собой зависимости между ними. Если компонент зависит от другого компонента, он не может быть поставлен отдельно от него. Часто компоненты представляют собой отдельные файлы с исходным кодом.

3. Модель развертывания (DeploymentModel)

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

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

Моделирование предметной области (бизнес-моделирование, BusinessModeling)

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

RUP – одна из спиральных методологий разработки программного обеспечения. Методология поддерживается и развивается компанией Rational Software. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная и инкрементная разработка программного обеспечения в RUP предполагает разделение проекта на несколько проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации.

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

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

По оси времени жизненный цикл делится на четыре основные фазы.

1. Начало (Inception) – формирование концепции проекта, понимание того, что мы создаем, представление о продукте (vision), разработка бизнес-плана (business case), подготовка прототипа программы или частичного решения. Это фаза сбора информации и анализа требований, определение образа проекта в целом. Цель – получить поддержку и финансирование. В конечной итерации результат этого этапа – техническое задание.

2. Проектирование, разработка (Elaboration) – уточнение плана, понимание того, как мы это создаем, проектирование, планирование необходимых действий и ресурсов, детализация особенностей. Завершается этап исполняемой архитектурой, когда все архитектурные решения приняты и риски учтены. Исполняемая архитектура представляет собой работающее программное обеспечение, которое демонстрирует реализацию основных архитектурных решений. В конечной итерации это – технический проект.

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

4. Внедрение, развертывание (Transition). Создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю (тиражирование, доставка и обучение).

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

По этой оси располагаются ключевые дисциплины жизненного цикла RUP, которые часто на русском языке называют процессами, хотя это не совсем верно с точки зрения данной методологии, поддерживаемые инструментальными средствами IBM (и/или третьих фирм).

1. Бизнес-анализ и моделирование (Business modeling) обеспечивает реализацию принципов моделирования с целью изучения бизнеса организации и накопления знаний о нем, оптимизации бизнес-процессов и принятия решения об их частичной или полной автоматизации.

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

3. Анализ и проектирование (Analysis and design) охватывает процедуры преобразования требований в промежуточные описания (модели), представляющие, как эти требования должны быть реализованы.