Главные вкладки

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

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

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

Известно, что 30 – 40% проектов по разработке ПС не доходят до завершения. Около 70% всех проектов реализуют поставленные задачи не полностью. Средний проект завершается с опозданием на 220%. В 10% проектов результат не соответствует требованиям. В 12% заказчик недостаточно привлекался к работе, чтобы обеспечить требуемые характеристики продукта. В 22% проектов не все вносимые изменения принимались во внимание.

Поэтому в последние десятилетия во всем мире ведущими специалистами в области теории и практики программного обеспечения (ПО) активно выполняются работы по усовершенствованию подходов к разработке ПС.

ОСНОВНЫЕ ПОНЯТИЯ ПРОГРАММНОЙ ИНЖЕНЕРИИ

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

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

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

Через четверть века, международный терминологический стандарт ISO/IEC 2382/1-93, дал более развернутую формулировку определения:

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

Буквальный перевод термина software engineering звучит не совсем понятно, поэтому долгое время в русскоязычном переводе использовался термин технология разработки программного обеспечения.

Программная инженерия – сравнительно молодая дисциплина, ее возраст чуть больше сорока лет. В 70-80 годы в ней доминировал классический, процедурный подход, в 1990-2000 годы - бъектно-ориентированный подход к разработке ПО.

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

Программа (program, routine) - упорядоченная последовательность команд (инструкций) компьютера для решения задачи.

Программное обеспечение (sowtware) - совокупность программ обработки данных и необходимых для их эксплуатации документов. В свою очередь, программное обеспечение является очень широким понятием, которое охватывает:

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

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

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

Задача (problem, task) - проблема, подлежащая решению.

Приложение (application) - программная реализация на компьютере решения задачи.

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

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

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

Программирование (programming) - теоретическая и практическая деятельность, связанная с созданием программ.

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

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

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

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

Программный проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Временный характер проекта подчеркивает, что у любого проекта есть определенное начало и завершение. Характеристика «временный» не относится к создаваемому в ходе проекта продукту, услуге или результату. Большинство проектов предпринимается для достижения устойчивого, длительного результата – время жизни конечного программного продукта существенно превышает время жизни программного проекта. В состав проекта входят как люди (разработчики), так и необходимые материальные ресурсы.

ОФИЦИАЛЬНАЯ КЛАССИФИКАЦИЯ ПРОЦЕССОВ ПРОГРАММНОЙ ИНЖЕНЕРИИ

Классификацию процессов программной инженерии задают международный стандарт ISO/IEC 12207-95 “Information Technology – Software Life Cycle Processes” и его российский аналог ГОСТ Р ИСО/МЭК 12207-99.

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

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

Работы, которые могут выполняться в ЖЦ ПО, распределены по пяти основным, восьми вспомогательным и четырем организационным процессам.

Основные процессы ЖЦ.

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

Процесс заказа (acquisition process). Определяет работы заказчика, т.е. организации, которая приобретает ПО.
Процесс поставки (supply process). Определяет работы поставщика, то есть организации, которая поставляет ПО заказчику.
Процесс разработки (development process). Определяет работы разработчика, то есть организации, которая создает программный продукт.
Процесс эксплуатации (operation process). Определяет работы оператора, то есть организации, эксплуатирующей вычислительную систему.
Процесс сопровождения (maintenance process). Определяет работы сопровождающей организации, которая предоставляет услуги по сопровождению программного продукта, состоящие в контролируемом изменении программного продукта с целью сохранения его исходного состояния и функциональных возможностей. Данный процесс охватывает перенос ПО в другую операционную среду и снятие ПО с эксплуатации.

Вспомогательные процессы жизненного цикла.

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

Процесс документирования (documentation process). Определяет работы по описанию информации, формируемой в процессе ЖЦ.
Процесс управления конфигурацией (confirmation management process). Определяет работы по управлению конфигурацией, что позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.
Процесс обеспечения качества (quality assurance process). Определяет работы по объективному обеспечению того, чтобы программный продукт соответствовал установленным требованиям и создавался в рамках утвержденных планов.
Процесс верификации (verification process). Определяет работы (заказчика, поставщика или независимой стороны) по верификации (проверке реализации конкретных требований) программных продуктов по мере реализации программного проекта.
Процесс аттестации (validation process). Определяет работы (заказчика, поставщика или независимой стороны) по аттестации (проверке полноты реализации всех требований) программных продуктов программного проекта.
Процесс совместной проверки (joint review process). Определяет работы по оценке состояния и результатов какой-либо работы. Данный процесс может использоваться двумя любыми сторонами, когда одна из сторон (проверяющая) проверяет другую сторону (проверяемую) на совместном совещании.
Процесс аудита (audit process). Определяет работы по выявлению соответствия требованиям, планам и договору. Данный процесс может использоваться двумя сторонами, когда одна из сторон (проверяющая) контролирует программные продукты или работы другой стороны (проверяемой). Аудит иначе называют ревизией, проводимой независимым лицом для выявления реального положения дел.
Процесс решения проблемы (problem resolution process). Определяет процесс анализа и устранения проблем (включая несоответствия), независимо от их характера и источника, которые были обнаружены во время осуществления разработки, эксплуатации, сопровождения или других процессов.

Организационные процессы жизненного цикла.

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

Процесс управления (management process). Определяет основные работы по управлению, включая управление проектом при реализации процессов ЖЦ.
Процесс создания инфраструктуры (infrastructure process). Определяет работы по выбору и поддержке средств и действий, обеспечивающих жизненный цикл.
Процесс усовершенствования (improvement process). Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов ЖЦ.
Процесс обучения (training process). Определяет работы по соответствующему обучению персонала.

Литература:

Процессы жизненного цикла программных средств: ГОСТ Р ИСО/МЭК 12207-99 от 23.12.1999. №675-ст., переиздание 2003г.
Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.23-27]
Бахтизин В.В. Технология разработки программного обеспечения: учеб. пособие / В.В.Бахтизин, Л.А.Глухова. – Минск: БГУИР, 2010. – 267 с. [с.10-17]

Интернет – ресурсы:

Бесплатная библиотека стандартов и нормативов. Режим доступа: www.docload.ru/Basesdoc/38/38418/index.htm#i235217

ИСТОРИЯ РАЗВИТИЯ ИСРП

ИСТОРИЯ РАЗВИТИЯ ИСРП

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

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

В этих областях выделим соответственно три класса программных продуктов:

системное программное обеспечение;
пакеты прикладных программ;
инструментарий технологии программирования.

Очевидно, что в рамках нашей дисциплины нас интересует третье направление.

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

В рамках этого направления сформировались следующие группы программных продуктов:

- средства для создания приложений, включающие:

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

- СASE-технология (Computer-Aided System Engineering), представляющая методы анализа, проектирования и создания программных систем и предназначенная дли автоматизации процессов разработки и реализации информационных систем.

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

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

Язык программирования - формализованный язык для описания алгоритма решения задачи на компьютере.

Системы программирования (programming system) включают:

- компилятор;

- интегрированную среду разработчика программ;

- отладчик;

- средства оптимизации кода программ;

- набор библиотек (возможно с исходными текстами программ);

- редактор связей;

- сервисные средства (утилиты) для работы с библиотеками, текстовыми и двоичными файлами;

- справочные системы;

- документатор исходного кода программы;

- систему поддержки и управления проектом программного комплекса.

Средства поддержки проектов - новый класс программного обеспечения, предназначен для:

- отслеживания изменений, выполненных разработчиками программ;

- поддержки версий программы с автоматической разноской изменений;

- получения статистики о ходе работ проекта.

Инструментальная среда пользователя представлена специальными средствами, встроенными в пакеты прикладных программ, такими, как:

- библиотека функций, процедур, объектов и методов обработки;

- макрокоманды;

- клавишные макросы;

- языковые макросы;

- программные модули-вставки;

- конструкторы экранных форм и отчетов;

- генераторы приложений;

- языки запросов высокого уровня;

- языки манипулирования данными;

- конструкторы меню и многое другое.

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

CASE-технология создания информационных систем.

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

В истории развития ИСРП обычно выделяют шесть периодов. Периоды различаются применяемой техникой и методами разработки ПС. В эти периоды, в качестве инструментов разработки, используют следующие ПС:

Период 1. Ассемблеры, анализаторы.

Период 2. Компиляторы, интерпретаторы, трассировщики.

Период 3. Символические отладчики, пакеты программ.

Период 4. Системы анализа и управления исходными текстами.

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

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

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

Сравним усредненные оценки трудозатрат по основным этапам разработки ПС при различных подходах к процессу разработки. Номерам строк будут соответствовать: 1 – традиционная разработка с использованием классических технологий; 2 – разработка с использованием современных структурных методологий проектирования; 3 – разработка с использование CASE – средств.

№ подхода	Анализ, %	Проектирование, %	Кодирование, %	Тестирование, %
1	20	15	20	45
2	30	30	15	25
3	40	40	5	15

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

Литература:

Бахтизин В.В. Технология разработки программного обеспечения: учеб. пособие / В.В.Бахтизин, Л.А.Глухова. – Минск: БГУИР, 2010. – 267 с. [с.242 - 244]

БАЗОВЫЕ ПРИНЦИПЫ ПОСТРОЕНИЯ CASE – СРЕДСТВ

БАЗОВЫЕ ПРИНЦИПЫ ПОСТРОЕНИЯ CASE - СРЕДСТВ

Большинство CASE – средств основано на парадигме метод – нотация – средство.

Парадигма – это система изменяющихся форм некоторого понятия.

Метод – это систематическая процедура или техника генерации описания компонент ПС.

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

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

К CASE – средствам может быть отнесено любое программное средство, обеспечивающее автоматическую помощь при разработке ПС, их сопровождении или управлении проектом, базирующееся на следующих основополагающих принципах:

Графическая ориентация. В CASE – средствах используется мощная графика для описания и документирования систем и для улучшения интерфейса с пользователем.
Интеграция. CASE – средство обеспечивает легкость передачи данных между своими компонентами и другими средствами, входящими в состав линейки CASE – средств. Это позволяет поддерживать совокупность процессов ЖЦ.
Локализация всей проектной информации в репозитории. Исполнителям проекта доступны соответствующие разделы репозитория в соответствии с их уровнем доступа. Это обеспечивает поддержку принципа коллективной работы.

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

Человеческий фактор, его учет позволяет привести процессы ЖЦ к легкой, удобной и экономичной форме.
Использование базовых программных средств, применяющихся в других приложениях (СУБД, компиляторов различных языков программирования, отладчиков и др.).
Автоматизированная или автоматическая кодогенерация. При автоматизированной кодогенерации выполняется частичная генерация кодов программного средства, остальные участки программируются в ручную. При автоматической кодогенерации выполняется полная генерация кодов. Возможны различные виды генерации (проектной документации, баз данных, кодов, автоматическая сборка модулей)
Ограничение сложности. Такое ограничение позволяет поддерживать сложность компонентов разрабатываемого программного средства или системы на уровне, доступном для понимания, использования и модификации.
Доступность для различных категорий пользователей, в том числе заказчиков, специалистов в предметной области, системных аналитиков, проектировщиков, программистов, тестировщиков, инженеров по качеству, менеджеров проекта. CASE – средства содержат инструменты различного функционального назначения, поддерживающие различные этапы основных, вспомогательных и организационных процессов ЖЦ.
Рентабельность, обеспечивает быструю окупаемость денежных средств, вложенных в CASE – средства, за счет сокращения сроков и стоимости проектов.
Сопровождаемость. CASE – средства обладают способностью адаптации к изменяющимся требованиям и целям проекта.

ОСНОВНЫЕ ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ CASE - СРЕДСТВ

В состав CASE – средств входят четыре основных компонента.

Средства централизованного хранения всей информации о проекте (репозиторий). Предназначены для хранения информации о разрабатываемом программном средстве в течении всего ЖЦ.
Средства ввода. Служат для ввода данных в репозиторий, организации взаимодействия участников проекта с CASE – средством. Должны поддерживать различные методологии анализа, проектирования, тестирования, контроля. Предназначены для использования в течении ЖЦ различными категориями участников проекта.
Средства анализа и разработки. Предназначены для анализа различных видов графических и текстовых описаний и их преобразования в процессе разработки.
Средства вывода. Служат для кодогенерации, создания различного вида документов, управления проектом.

Все компоненты CASE – средств в совокупности обладают следующими функциональными возможностями:

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

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

В CASE - средствах, как правило, реализуются следующие типы контроля.

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

Основными функциями репозитория являются хранение, обновление, анализ, визуализация всей информации по проекту и организация доступа к ней. Репозиторий хранит более 100 типов объектов.

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

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

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

Основой поддержки процесса разработки являются следующие свойства современных CASE – средств.

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

КЛАССИФИКАЦИЯ CASE - СРЕДСТВ

Все CASE - средства подразделяют на типы, категории и уровни.

Классификация по типам отражает функциональное назначение CASE – средств в ЖЦ ПС.

Анализ и проектирование. Средства этого типа используются для поддержки начальных этапов процесса разработки: анализа предметной области, разработки требований к системе, проектирования системной архитектуры, технического проектирования программной архитектуры, технического проектирования программных средств. Средства данного типа поддерживают известные методологии анализа и проектирования. На выходе генерируются спецификации системы, ее компонентов и интерфейсов, архитектура системы, архитектура программного средства, технический проект, включая алгоритмы и структуры данных. Примерами являются: AllFusion Process Modeler (BPwin), CASE.Аналититк, Design/IDEF, Telelogic DOORS, Telelogic Modeler, Telelogic TAU, Telelogic Rhapsody, Telelogic Statemate.
Проектирование баз данных и файлов. Средства этого типа обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в третью нормальную форму, автоматическую генерацию схем баз данных и описаний форматов файлов на уровне программного кода. Примерами являются: AllFusion Process Modeler (BPwin), CA Erwin Data Model Validator, S-Designor, Silverrun, Designer2000, Telelogic TAU, Telelogic Rhapsody.
Программирование и тестирование. Средства этого типа поддерживают программирование и тестирование. Данные средства автоматически выполняют кодогенерацию на основе спецификаций или моделей. Содержат графические редакторы, средства поддержки работы с репозиторием, генераторы и анализаторы кодов, генераторы тестов, анализаторы покрытия тестами, отладчики. Примерами являются: TAU/Developer, TUA/Tester, Logiscope Audit, Logiscope RuleChecker, Logiscope TestChecker, Logiscope Reviewer, Rhapsody Developer.
Сопровождение и реинженерия. Общей целью средсвт этого типа является поддержка корректировки, изменений, преобразований, реинженерия существующей системы, поддержка документации по проекту. К данным средствам относятся средства документирования, анализаторы программ, средства управления изменениями и конфигурацией ПС и систем, средства реструктурирования и реинженении, средства обеспечения мобильности. Примерами являются: Telelogic DocExpress, Telelogic Synegry, Telelogic Change, AllFusion Change Management Suite.
Окружение. К средствам данного типа относятся средства поддержки интеграции CASE – средств и данных. Примерами являются: Telelogic Rhapsody Gateway, Telelogic Rhapsody Interface Pack, AllFusion Data Profiler, AllFusion Model Manager, AllFusion Model Navigator.
Управление проектом. К средствам данного типа относятся средства поддержки процесса управления ЖЦ. Их функциями являются планирование, контроль, руководство, организация взаимодействия. Примерами являются: Telelogic Focal Point, Telelogic dashboard, AllFusion Process Management Suite, Advisor.

Классификация по категориям отражает уровень интегрированности CASE – средств по выполняемым функциям.

Категория Tool. Tool – рабочий инструмент. Включает средства самого низкого уровня интегрированности. В данную категорию входят инструментальные средства, решающие небольшую автономную задачу при разработке ПС. Обычно средства данной категории являются компонентами CASE – средств белее высокого уровня интегрированности.
Категория ToolKit. ToolKit – набор инструментов, пакет разработчика. Включает средства среднего уровня интегрированности. Средства данной категории используют репозиторий для всей информации о проекте и ориентированы обычно на поддержку одного этапа или одной работы процесса разработки или на поддержку одного из вспомогательных или организационных процессов. Средства данной категории представляют собой интегрированную совокупность инструментальных средств, имеющих как правило общую функциональную ориентацию.
Категория Workbench. Workbench – рабочее место. Средства данной категории обладают самой высокой степенью интеграции. Они представляют собой интегрированную совокупность инструментальных средств, поддерживающих практически весь процесс разработки и ряд вспомогательных и организационных процессов.

Классификация по уровням связана с областью действия CASE – средств.

Верхние CASE – средства. Средства данного уровня называют средствами компьютерного планирования. Их основной целью является помощь руководителям организации, предприятия и конкретных проектов в определении политики организации и создании планов проектов. CASE – средства данного уровня позволяют строить модель предметной области, проводить анализ различных сценариев (существующего, наихудших, наилучших), накапливать информацию для принятия оптимальных решений. Таким образом, применительно к ЖЦ ПС данные средства поддерживают процесс заказа и первую работу процесса разработки (подготовка процесса разработки). Графические средства данного уровня используются как формализованный язык общения между заказчиком и разработчиком требований. Примерами являются: Telelogic System Architect, Telelogic Focal Point, Telelogic Dashboard, AllFusion Modeling Suite.
Средние CASE – средства. Средства данного уровня поддерживают начальные этапы процесса разработки. Обычно данные средства обладают возможностью накопления и хранения информации по проекту. Это позволяет использовать накопленные данные как в текущем, так и в других проектах. Часто эти средства поддерживают прототипирование и автоматическое документирование.
Нижние CASE – средства. Средства данного уровня поддерживают вторую половину работ процесса разработки. Содержат графические средства, исключающие необходимость разработки спецификаций для программных модулей. Спецификации представляются моделями и непосредственно преобразуются в программные коды. Автоматически генерируется до 90% кода. Как правило, они поддерживают прототипирование, тестирование, управление конфигурацией, генерацию документации, облегчают модификацию и сопровождение ПС.

Литература:

Бахтизин В.В. Технология разработки программного обеспечения: учеб. пособие / В.В.Бахтизин, Л.А.Глухова. – Минск: БГУИР, 2010. – 267 с. [с.24 - 254]

КЛАССИЧЕСКИЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

БАЗИС ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Различают методы, средства и процессы программной инженерии. Методы обеспечивают решение широкого спектра технических задач. Средства обеспечивают автоматизированную или автоматическую поддержку методов. А процессы являются «клеем», который соединяет методы и средства так, что они обеспечивают непрерывную технологическую цепочку разработки. Процессы определяют:

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

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

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

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

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

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

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

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

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

Конструирование. Эта деятельность объединяет два действия: генерацию программного кода ПО и тестирование, которое требуется для обнаружения ошибок в коде.

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

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

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

Отслеживание (трассировка) и контроль программного проекта – позволяют команде проекта оценивать степень выполнения плана проекта и предоставляют необходимую информацию для модификации расписания.

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

Обеспечение качества ПО – определяет и проводит действия, требуемые для поддержания качества ПО.

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

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

Управление конфигурацией ПО – управляет воздействием изменений на ход разработки в течении всего программного процесса.

Управление повторной используемостью – определяет критерии для повторного использования рабочего продукта (включая программные компоненты) и задает механизмы для получения повторно используемых компонентов.

Подготовка и производство рабочего продукта – включает действия, требуемые для создания рабочих продуктов (таких как модели, документы, логии, формы и листинги).

В рамках различных проектов одни и те же процессы могут различаться по следующим направлениям:

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

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

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

МОДЕЛЬ КЛАССИЧЕСКИЙ ЖИЗНЕННЫЙ ЦИКЛ (КАСКАДНАЯ МОДЕЛЬ)

Старейшей моделью процесса разработки ПО является классический жизненный цикл, автор модели – Уинстон Ройс, 1970.

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

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

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

Планирование. На этом этапе решаются задачи планирования программного проекта. В ходе планирования проекта определяются объем будущих работ и их риск, необходимые трудозатраты, формируются рабочие задачи и расписание (план – график работы).

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

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

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

Архитектуры ПО
Структурной и поведенческой организации частей архитектуры ПО
Входного и выходного интерфейса частей архитектуры (входных и выходных форм данных).

Конструирование – этот этап включает в себя действия кодирования и тестирования.

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

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

Развертывание – последний этап классического жизненного цикла, нацелен на два действия: поставку разработанного продукта заказчику и сопровождение процесса эксплуатации этого продукта.

Согласно статистическим данным, 65% сопровождения связано с усовершенствованием ПО, 18% отводится на адаптацию и 17% связано с исправлением ошибок. Из этого можно сделать вывод, что исправление ошибок не является самой распространенной работой сопровождения. Большая часть сопровождения ориентирована на модернизацию ПО. Поэтому сопровождение само по себе является естественным продолжение разработки системы со своими этапами подготовки, планирования, моделирования и конструирования.

Сопровождение показано на схеме стрелками обратных связей.

Как и любая инженерная схема, модель классического ЖЦ имеет достоинства и недостатки.

Достоинства:

Дает план и временной график по всем этапам проекта, упорядочивает ход разработки.

Недостатки:

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

МАКЕТИРОВАНИЕ И СТРАТЕГИИ РАЗРАБОТКИ ПО

Для дальнейшего знакомства с моделями ЖЦ рассмотрим технологии, внесение которых позволило появиться новым подходам к разработке ПО.

Макетирование (прототипирование) – это процесс создания модели требуемого программного продукта.

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

Создаваемая в макетировании модель может принимать одну из трех форм:

Бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог)
Работающий макет (выполняет некоторую часть требуемых функций)
Существующая программа (характеристики которой затем должны быть улучшены)

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

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

Достоинства:

Обеспечивает определение полных требований к ПО.

Недостатки:

Заказчик может принять макет за продукт
Разработчик может принять макет за продукт

Существуют три стратегии разработки ПО:

Водопадная стратегия – линейная последовательность этапов разработки;

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

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

ИНКРЕМЕНТНАЯ МОДЕЛЬ

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

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент (версию) ПО.

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

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

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

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

СПИРАЛЬНАЯ МОДЕЛЬ

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

Спиральная модель определяет четыре действия, представленные четырьмя квадрантами спирали.

Подготовка – сбор требований и ограничений

Планирование – формирование плана проекта и анализ риска

Моделирование и конструирование – подготовка моделей и реализация продукта следующего уровня

Развертывание – оценка заказчиком текущей версии продукта

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

С каждой итерацией по спирали строится все более полные версии ПО.

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

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

Достоинства:

Более реально отображает разработку программного обеспечения;
Позволяет явно учитывать риск на каждом витке эволюции разработки;
Включает возможность оценки системы в итерационную структуру разработки;
Использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки:

Повышенные требования к заказчику;
Трудности контроля и управления временем разработки.

КОМПОНЕНТНО ОРИЕНТИРОВАННАЯ МОДЕЛЬ

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

Рис. 5 Компонентно-ориентированная модель ЖЦ

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

Достоинства:

Уменьшается на 30% время разработки программного модуля;
Уменьшается стоимость программной разработки до 70%;
Увеличивается в 1,5 раза производительность разработки.

Литература:

Процессы жизненного цикла программных средств: ГОСТ Р ИСО/МЭК 12207-99 от 23.12.1999. №675-ст., переиздание 2003г.
Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.25-39]
Бахтизин В.В. Технология разработки программного обеспечения: учеб. пособие / В.В.Бахтизин, Л.А.Глухова. – Минск: БГУИР, 2010. – 267 с. [с.18-29, 43-60]

Интернет – ресурсы:

Бесплатная библиотека стандартов и нормативов. Режим доступа: www.docload.ru/Basesdoc/38/38418/index.htm#i235217

СОВРЕМЕННЫЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

ТЯЖЕЛОВЕСНЫЕ И ОБЛЕГЧЕННЫЕ ПРОЦЕССЫ

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

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

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

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

У каждой группы процессов свои достоинства, недостатки и область применения:

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

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

XP - ПРОЦЕСС

Экстремальное программирование – облегченный (гибкий) процесс или методология, главный автор которого – Кент Бек (1999). ХР – процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР – группу образуют 10 сотрудников, которые размещаются в одном помещении.

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

ХР рекомендует: первая реализация должна иметь длительность 2-6 месяцев, продолжительность остальных реализаций около двух месяцев, каждая итерация длится приблизительно две недели.

Основная идея ХР – устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов и реляционных баз данных. Поэтому ХР – процесс должен быть высоко динамичным процессом. ХР – группа имеет дело с изменением требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Базовых действий в ХР – цикле четыре: планирование, проектирование, кодирование и тестирование. Динамизм обеспечивается за счет пяти характеристик: непрерывной связи с заказчиком (и в пределах группы), простоте (всегда выбирается минимальное решение), быстрой обратной связи (с помощью модульного и функционального тестирования), смелости в проведении профилактики возможных проблем, уважению членов команды друг к другу и к своей работе. Кент Бек называет их ценностями ХР – методологии.

Большинство идей поддерживаемых ХР – процессом, не новы и применяются в других процессах. Но в ХР эти принципы достигают «экстремальных значений».

Практика здравого смысла	ХР экстремум	ХР реализация
Проверки кода	Код проверяется все время	Парное программирование
тестирование	Тестирование выполняется все время, даже с помощью заказчика	Тесты модулей, тесты приемки
Проектирование	Проектирование является частью ежедневной деятельности каждого разработчика	Рефакторинг
Простота	Для системы выбирается простейшие проектное решение, поддерживающее ее текущую функциональность	Самая простая вещь которая могла бы работать
Архитектура	Каждый постоянно работает над уточнением архитектуры	Метафора
Тестирование интеграции	Интегрируются и тестируются несколько раз в день	Непрерывная интеграция
Короткие итерации	Итерации являются предельно короткими, продолжаются секунды, минуты, часы	Игра планирования

Базис первой версии ХР (с 1999-го года) формировали двенадцать методик, во второй версии (с 2004-го года) их количество возросло до двадцати четырех. Наиболее характерными среди них являются следующие.

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

Частая смена версий – быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.

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

Простое проектирование – проектирование выполняется на столько просто, насколько это возможно в данный момент.

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

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

Парное программирование – весь код пишется двумя программистами, работающими на одном компьютере.

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

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

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

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

Глобальное видение полномасштабного продукта обеспечивает «метафора» - экстремально упрощенный вариант архитектуры. ХР подчеркивает желательность проектирования при минимизации проектной документации. Точнее говоря, ХР предлагает непрерывное перепроектирование (с помощью рефакторинга), при котором нет нужды в детализированной документации по проектированию, а для инженеров сопровождения единственным надежным источником информации является программный код. Обычно после написания кода документация по проектным решениям выбрасывается. Документация по проектированию сохраняется только в том случае, когда заказчик временно теряет способность придумывать новые истории. Использование рефакторинга приводит к реализации простейшего решения, удовлетворяющего текущую потребность. Изменения в требованиях заставляют отказываться от всех «общих решений».

Парное программирование – одна из наиболее спорных методик в ХР, она влияет на ресурсы, что важно для менеджеров, решающих, будет ли проект использовать ХР. Может показаться, что парное программирование удваивает ресурсы, но исследования доказали: парное программирование приводит к повышению качества и уменьшению времени цикла. Для согласованной группы затраты увеличиваются на 15%, а время цикла сокращается на 40-50%.

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

Основным средством управления ХР является количественный показатель, например «скорость проекта» - количество историй заданного размера, которые могут быть реализованы в итерации.

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

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.39 - 44]

ОРГАНИЗАЦИЯ РАБОТЫ В КОЛЛЕКТИВЕ РАЗРАБОТЧИКОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ПОДБОР ЧЛЕНОВ КОМАНДЫ

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

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

При подборе кандидатов обычно учитываются следующие аспекты:

Опыт работы во многих аппаратно-программных средах;
Знание языков программирования;
Образование и опыт работы по специальности;
Коммуникабельность;
Способность адаптироваться;
Жизненная позиция;
Личностные качества.

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

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

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

Личностные качества оценить труднее всего. Здесь и психологический портрет, и темперамент, и инициативность, и целеустремленность, и многое другое. Именно эти качества определяют совместимость кандидата с коллективом.

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

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

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

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

ВЗАИМОДЕЙСТВИЕ В КОМАНДЕ

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

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

размер / структура команды. С ростом числа участников количество связей по взаимодействию растет квадратично. Например, между тремя участника есть три связи, четыре участника имеют шесть связей, пять человек – десять связей, то есть n человек имеют (n-1)+(n-2)+ … +1=n(n-1)/2 связей (каждый с каждым). Следовательно 50 человек должны участвовать в 1225 взаимодействиях. Для больших команд альтернативой является их разделение на группы. Каждая группа отвечает за определенную часть проекта и работает над ней. Обычно численность группы не превышает 8 человек. Для взаимодействия с другими группами в каждой группе выделяется один сотрудник. Такая структура сохраняет преимущества небольших команд, но позволяет большому коллективу создавать большие программные продукты.
Иерархия команды. Сотрудникам в команде с горизонтальной организацией (все сотрудники равны) легче общаться между собой. В командах с многоуровневой организацией и иерархией отношений взаимодействие происходит между уровнями в иерархической последовательности, что может приводить к запаздыванию разработки и проблемам недопонимания.
Рабочее окружение. Организация рабочего места оказывает существенное влияние на возможности общения. Психологи доказали, что человек всегда предпочитает работать в отдельном помещении, которое он может оформить по своему вкусу и в котором может сосредоточится. В открытом помещении сотруднику сконцентрировать труднее, следствием чего становиться снижение рабочей активности и падение производительности труда.

СОСТАВ ГРУППЫ

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

Типовыми ролями в группе являются:

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

Так же группа разработчиков пользуется услугами вспомогательного технического персонала и программной библиотекой.

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.63 - 67]

ВИДЫ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ВИДЫ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

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

Правильное требование: Система должна предоставить клиенту возможность просмотра счета, снятия денег, добавления денег.

Не требование: Информация о банковском счете должна храниться в виде таблиц MySQL.

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

Требование заказчика: ПО должно обеспечить средства для ввода и сохранения разнообразных данных абонента – пользователя.

Требования разработчика:

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

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

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

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

Требования разработчика оформляется в виде спецификации анализа. Этот документ служит основой для заключения контракта.

Часто обе спецификации интегрируются в единый документ следующей структуры.

Рис. 6 Интеграция требований заказчика и разработчика в единую спецификацию требований

Различают два вида требований: Функциональные и нефункциональные.

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

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

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

Нефункциональное требование: Цикл регулирования скорости летательного аппарата должен укладываться в 64 мс.

Формы записи требований могут быть самыми разными. Однако требования должны быть:

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

Нефункциональные требования предлагается (И. Соммервилл) разделять на три группы:

Требования к программной системе – описывают свойства и характеристики системы. Сюда относят требования к скорости работы, производительности, емкости необходимой памяти, надежности, переносимости и удобству эксплуатации;

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

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

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.104 -108]

ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ОСНОВЫ ПРОЦЕССА ФОРМИРОВАНИЯ ТРЕБОВАНИЙ

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

Процесс формирования требований проводится пошагово:

Шаг 1. Определение проблемы (предметной области)

Шаг 2. Определение представителей заказчика.

Шаг 3. Проведение опроса представителей заказчика.

Шаг 4. Документирование результатов опроса.

Шаг 5. Проверка требований.

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

Таблица 1

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

Элемент	Описание
Проблема	[Описание проблемы]
Воздействует на	[Указание лиц, на которых оказывает влияние данная проблема]
Результатом чего является	[Описание воздействия данной проблемы на заинтересованных лиц и бизнес-деятельность]
Выигрыш от	[Указание предлагаемого решения]
Может состоять в следующем	[Список основных предоставляемых решением пре- имуществ]

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

Рассмотрим пример. Компания занимающаяся торговлей по каталогу, производит и рассылает на дом множество недорогих товаров различных наименований. Решив заняться проблемой недостаточной прибыльности, компания практически сразу обратила внимание на ущерб от несоответствия, который представляет собой стоимость всего, что идет не так, как надо, и приводит к бесполезным затратам. Этот ущерб включает в себя переделки, остатки, неудовлетворенность клиента, текучесть кадров и другие негативные факторы. Проанализировав ущерб от несоответствия, компания заподозрила, что наибольший вклад в него вносят «остатки».

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

Рис. 7 Диаграмма в форме рыбного скелета для отображения корневых причин

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

Элемент	Описание
Проблема	Выполнение неправильных заказов на покупку
Воздействует на	выполняющий заказы персонал, клиентов, производство, продажи и обслуживание клиентов
Результатом чего является	Увеличение остатков, повышение производственных затрат, неудовлетворенность клиентов, уменьшение прибыли
Выигрыш от	Новой системы, направленной на решение данной проблемы
Может состоять в следующем	Повышение точности заказов на покупку в точке ввода, совершенствование учета данных о покупках, в конечном счете – увеличение прибыли

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

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

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

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

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

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

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

Кто является пользователями системы?

Кто является заказчиком (экономическим покупателем) системы?

На кого еще окажут влияние результаты работы системы?

Кто будет оценивать и принимать систему, когда она будет представлена и развернута?

Существуют ли другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть?

Кто будет заниматься сопровождением новой системы?

Не забыли ли мы кого-нибудь?

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

Таблица 2

Пользователи и лица, заинтересованные в новой системе

Пользователи

Другие заинтересованные лица

Служащие, занимающиеся вводом заказов

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

Контроль производства

Служащий, выписывающий счета

Администратор информационной системы и команда разработчиков

Главный финансист

Управляющий производством

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

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

Процесс проведения интервью состоит из следующих этапов:

Разработка вопросов.

Выбор опрашиваемых пользователей.

Планирование контактов.

Проведение интервью.

Завершение встречи и определение последующих действий.

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

Часть I. Определение профиля заказчика или пользователя

Имя

Компания

Отрасль

Должность

(Вышеприведенная информация, как правило, может быть внесена заранее.)

Каковы ваши основные обязанности?

Что вы в основном производите?

Для кого?

Как измеряется успех вашей деятельности?

Какие проблемы влияют на успешность вашей деятельности?

Какие тенденции, если такие существуют, делают вашу работу проще или сложнее?

Часть II. Оценка проблемы

Для каких проблем (прикладного типа) вы ощущаете нехватку хороших решений?

Назовите их. (Замечание. Не забывайте спрашивать: «А еще?».)

Для каждой проблемы выясняйте следующее.

Почему существует эта проблема?

Как она решается в настоящее время?

Как заказчик (пользователь) хотел бы ее решать?

Часть III. Понимание пользовательской среды

Кто такие пользователи?

Какое у них образование?

Каковы их навыки в компьютерной области?

Имеют ли пользователи опыт работы с данным типом приложений?

Какая платформа используется?

Каковы ваши планы относительно будущих платформ?

Используются ли дополнительные приложения, которые имеют отношение к данному приложению? Если да, то пусть о них немного расскажут.

Каковы ожидания заказчика относительно практичности продукта?

Сколько времени необходимо для обучения?

В каком виде должна быть представлена справочная информация для пользователя (в интерактивном или в виде печатной копии)?

Часть IV. Резюме

(перечисляются основные пункты, чтобы проверить, все ли правильно вы поняли)

Итак, вы сказали мне (перечислите описанные заказчиком проблемы своими словами)

Адекватно ли этот список представляет проблемы, которые имеются при существующем решении?

Какие еще проблемы (если такие существуют) вы испытываете?

Часть V. Предположения, аналитика относительно проблемы заказчика

(проверенные или непроверенные предположения)

(те проблемы, которые не были упомянуты)

Какие проблемы, если они есть, связаны с (перечислите все потребности или дополнительные проблемы, которые, по-вашему, может испытывать заказчик или пользователь)

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

Является ли она реальной?

Каковы ее причины?

Как она решается в настоящее время?

Как бы заказчик (пользователь) хотел ее решать?

Насколько важно для заказчика (пользователя) решение этой проблемы в сравнении с другими, упомянутыми им?

Часть VI. Оценка предлагаемого вами решения

(если это уместно)

(Охарактеризуйте основные возможности предлагаемого вами решения. А потом задайте пользователю следующие вопросы.)

Что, если вы сможете?

Как вы расцениваете важность этого?

Часть VII. Оценка возможности

Кто в организации нуждается в данном приложении?

Сколько пользователей указанных типов будет использовать его?

Насколько значимо для вас успешное решение?

Часть VIII. Оценка необходимого уровня надежности и производительности, а также потребности в сопровождении

Каковы ваши ожидания относительно надежности?

Какой, по-вашему, должна быть производительность?

Будете ли вы заниматься поддержкой продукта или этим будут заниматься другие?

Испытываете ли вы потребности в поддержке?

Что вы думаете о доступе для сопровождения и обслуживания?

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

Какие требования относительно установки и конфигурации?

Существуют ли специальные требования по лицензированию?

Как будет распределено программное обеспечение?

Есть ли требования на маркировку и упаковку?

Часть IX. Другие требования

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

Нет ли других требований, о которых нам следовало бы знать?

Часть X. Окончание

Существуют ли другие вопросы, которые мне следовало бы вам задать?

Если мне еще понадобится задать вам несколько вопросов, могу ли я вам позвонить?

Будете ли вы принимать участие в обсуждении требований?

Часть XI. Заключение аналитика

После интервью, пока его данные еще свежи в вашей памяти, зафиксируйте три потребности или проблемы с наивысшими приоритетами, выявленные вами в беседе с данным заказчиком (пользователем)

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

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

Проверка требований выполняется заказчиком и разработчиком совместно, она удостоверяет:

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

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

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

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.108 -110]
Технологии разработки программного обеспечения. Версия 1.0 [Электронный ресурс]: электрон. учеб. пособие / Ю. Ю. Якунин. – Электрон. дан. (3 Мб). – Красноярск: ИПК СФУ, 2008. [с. 63-68, 104-107] Режим доступа

КЛАССИЧЕСКИЕ МЕТОДЫ АНАЛИЗА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

АНАЛИЗ ТРЕБОВАНИЙ

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

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

Рассмотрим типичные шаги анализа требований.

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

По режиму. Некоторые системы меняют поведение в зависимости от режима работы. Например: обучение, нормальный режим, аварийный режим и т.п.
По категориям пользователей. Некоторые системы обеспечивают различные наборы функций для разных категорий пользователей. Например: не зарегистрированный пользователь сайта, зарегистрированный пользователь сайта, администратор сайта.
По объектам. Объекты – это программные сущности системы, которые могут иметь физические аналоги во внешней среде. Каждый объект несет в себе набор данных и функции. Функции объектов также называют услугами, методами и операциями. Например: в системе контроля за пациентом объектами являются – пациент, датчики, медсестра, врач, лекарства.
По свойствам. Свойство – сервис, предоставляемый внешней среде, определяется с помощью пар «входное действие - реакция». Реакция может быть рассредоточена по по различным частям программной среды. Например: в телефонной системе свойства – локальный вызов, переадресация вызова и т.п.
По стимулам. Некоторые системы легко организуются при описании их функций на языке стимулов. Например: функции автоматической системы посадки самолета организованы в разделы по энергетическим потерям, сдвигу ветра, изменению направления качения, избыточной вертикальной скорости ит.д.
По откликам. Некоторые системы организуются по средством описания всех функций, поддерживающих генерацию различных откликов. Например: функции системы учета персонала могут быть организованы в разделы по всем функциям для составления чека по оплате, всем функциям для составления списка служащих и т.д.
По иерархии функций. То есто путем разделения на множество высокоуровневых функций и последующего разбиения их на подфункции. Например: требования для ПО по работе с домашним бюджетом можно разделить на функции проверки, функции сбережения и функции инвестирования. Функции проверки в дальнейшем могут быть разделены на функции чековой книжки, баланса счета, составления отчетов и т.п.

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

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

Шаг 2. Преобразование первичных требований в детальные требования. Обычно одно требование заказчика преобразуется в несколько детальных требований, хотя возможно и отображение «один – в - один».

При работе с детальными требованиями необходимо придерживаться ряда рекомендаций.

Первичная оценка. Возможны варианты:

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

Обеспечение прослеживаемости требования. Анализ возможности прослеживания при проектировании и конструировании.

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

Анализ однозначности толкования требования.

Назначение приоритета требования. Выбираются варианты: существенное, желательное, необязательное.

Проверка полноты требования. Следует убедиться в наличии всех «обеспечивающих» требований.

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

Требования заносятся в спецификацию анализа (спецификацию требований).

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

Содержательно в состав аттестации входят:

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

В ходе аттестации применяют следующие методы:

Совместные проверки требований. Требования анализируются рецензентами, избираемыми из числа заинтересованных лиц и внешних экспертов. Цель – найти неточности и ошибки. Обнаруженные противоречия, ошибки и упущения в требованиях документируются и передаются заказчику и разработчикам системы;
Макетирование. Макет создается экспертами и обсуждается заказчиком и разработчиками.
Генерация тестов. Создание тестов для требований очень часто выявляет проблемы в описании требований. Проблемы при создании тестов означают, что требования трудно выполнить и поэтому их нужно пересмотреть.
Автоматизированная проверка непротиворечивости. Если требования представлены как формализованные модели, для проверки непротиворечивости моделей можно применить программные CASE – утилиты.

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

ХАРАКТЕРИСТИКИ ДЕТАЛЬНОГО ТРЕБОВАНИЯ

Рассмотрим желательные характеристики детальных требований более подробно.

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

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

Таблица 3

Матрица прослеживания требований

Требование	Модуль 1	Модуль 2	Модуль 3
М_1415	Show_Data()	AverageMark()	GetInfo()
М_1416	ShowGroup()	Show_Semester()	Show_Data()

В данном примере требования находятся в отношении «многие – ко - многим», работать с ними сложно, так как изменения одного могут затрагивать другое. Избежать этого можно создавая требования с соотношением к функциям «один – ко - одному».

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

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

Рис. 8 Прослеживание и тестирование функциональных детальных требований.

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

Тестируемость. Должна существовать возможность протестировать реализацию требования.

Проиллюстрируем тестируемость примером.

Нетестируемое требование: Центральный процессор космического самолета должен быть идеален.

Тестируемое требование: Центральный процессор космического самолета должен иметь следующие параметры: среднее быстродействие на задачах управления полетом не менее 2 млн. оп/с, вероятность безотказной работы не менее 0,9999, рабочий диапазон температур от -80 до +140 (гр С), общая доза радиации 1000 крад.

Приоритетность. Часто бывает трудно реализовать все запланированные требоваия в срок и не выходя за рамки бюджета. В этом случае уменьшают количество реализованных требований. Одна из процедур отсеивания базируется на расстановке приоритета детальных требований. Мы уже выделяли три категории требований: существенные, желательные и необязательные. Разумеется сокращение проводиться за счет необязательных и иногда желательных требований. Сокращение также использует правило Парето – 20% требований реализуют 80% желательной функциональности.

Полнота. Полнота набора требований оценивается экспертами предметной области. Их оценка может приводить к добавлению недостающих требований.

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

КЛАССИЧЕСКИЕ МЕТОДЫ АНАЛИЗА ТРЕБОВАНИЙ

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

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

Диаграмма переходов состояний (STD – State Transition Diagrams), характеризует поведение системы во времени;
Функциональная диаграмма (SADT – Structured Analisis and Design Technique)
Диаграмма потоков данных (DFD – Data Flow Diagrams), описывает взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;
Диаграмма «сущность – связь» (ERD – Entity Relationship Diagrams), описывает базы данных разрабатываемой системы.

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

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

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

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

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

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

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

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

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

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

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.110 -120]
Рудаков А.В. Технология разработки программных продуктов. Практикум: учеб.пособие для студ.учреждений сред.проф.образования / А.В.Рудаков, Г.Н.Федорова. – 4-е изд., стер. – М.: Издательский центр «Академия»; 2014. – 192 с. [с.18-48]

ПРИНЦИПЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРЕДСТАВЛЕНИЯ ПРОГРАММНЫХ СИСТЕМ

ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРЕДСТАВЛЕНИЯ ПРОГРАММНЫХ СИСТЕМ

Вопросы:

Какие схемы декомпозиции существуют?
Что лежит в основе алгоритмической декомпозиции?
На чем основано объектно-ориентированное представление ПС?
Чем отличается инкапсуляция от абстракции?
Для чего нужны модули в ООП?
Перечислить инструменты иерархической организации.
Виды операций клиента над объектом.
Чем отличается активный объект от пассивного?
Что происходит в результате соединения связи?
Перечислить части интерфейса класса.
Ассоциация классов, пример.

Рассмотрение любой сложной системы требует применения техники декомпозиции ее на составляющие элементы. Известны две схемы декомпозиции: алгоритмическая и объектно-ориентированная декомпозиция. В основе алгоритмической декомпозиции лежит разбиение по действиям – алгоритмам. Эта схема применяется в процедурных программных системах. Объектно-ориентированная декомпозиция обеспечивает разбиение по автономным лицам – объектам реального (или виртуального) мира. Эти лица (объекты) более «крупные» элементы, каждый из них несет и описания действий, и описания данных.

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

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

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

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

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

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

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

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

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

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

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

Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются:

Структура из классов
Структура из объектов

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

Вторая разновидность иерархической организации – структура объектов – базируется на отношении агрегации. Агрегация не является понятием, уникальным для объектно-ориентированных систем. В сочетании с наследованием агрегация:

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

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

Объект – это конкретное представление абстракции. Объект обладает индивидуальностью, состоянием и поведением. Структура и поведение подобных объектов определены в их общем классе. Термины «экземпляр класса» и «объект» взаимозаменяемы.

Индивидуальность – это характеристика объекта, которая отличает его от всех других объектов.

Состояние объекта характеризуется перечнем всех атрибутов объекта и текущими значениями каждого из атрибутов.

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

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

Модификатор – изменяет состояние объекта
Селектор – дает доступ к состоянию, но не изменяет его
Итератор – дает доступ к содержанию объекта по частям, в строго определенном порядке
Конструктор – создает объект и инициализирует его состояние
Деструктор – разрушает объект и освобождает занимаемую им память.

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

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

С точки зрения активности объекты могут быть активными или пассивными. Активный объект имеет собственный канал (поток) управления, пассивный -нет. Активный объект автономен, он может проявлять свое поведение без воздействия со стороны других объектов. Пассивный объект, наоборот, может изменять свое состояние только под воздействием других объектов.

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

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

Объект – клиент вызывает операции объекта – поставщика
Один объект перемещает данные к другому объекту

Как участник связи объект может играть одну из трех ролей:

Контролер – объект, который может воздействовать на другие объекты, но никогда не подвержен воздействию других объектов;
Сервер – объект, который никогда не воздействует на другие объекты, но только используется другими объектами;
Агент – объект, который может как воздействовать на другие объекты, так и использоваться ими.

Рассмотрим два объекта А и В, между которыми есть связь. Для того чтобы объект А мог послать сообщение в объект В, надо чтобы В был виден А.

Различают четыре формы видимости между объектами:

Объект- поставщик (сервер) глобален для клиента.
Объект – поставщик (сервер) является параметром операции клиента.
Объект – поставщик (сервер) является частью объекта клиента.
Объект – поставщик (сервер) является локально объявленным объектом в операции клиента.

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

Связи обозначают равноправные (клиент - серверные) отношения между объектами.

Агрегация – обозначает отношения объектов в иерархии «целое/часть». Агрегация обеспечивает возможность перемещения от целого (агрегата) к его частям (атрибутам).

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

При выборе отношения между объектами учитывают, что:

Связи обеспечивают низкое сцепление между объектами;
Агрегация инкапсулирует части как секреты целого;

С понятием объекта тесно связано понятие класс. Класс – описание множества объектов, которые разделяют одинаковые атрибуты, операции, отношения и семантику. Любой объект – просто экземпляр класса.

Для класса различают внутреннее представление - реализацию и внешнее представление – интерфейс.

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

Интерфейс класса может быть разделен на 4 части:

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

Другом класса называют класс, который имеет доступ ко всем частям этого класса.

Реализация класса описывает секретов поведения класса. Она включает реализации всех операций, определенных в интерфейсе класса.

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

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

Для их реализации большинство языков программирования поддерживают следующие отношения:

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

Рассмотрим несколько примеров поясняющих особенности отношений классов.

Ассоциации классов.

Обозначает семантическое соединение классов.

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

Рис. 9 Ассоциация

Очевидно, что ассоциация предполагает двусторонние отношения:

Для данного экземпляра Книги выделяется экземпляр Библиотеки, обеспечивающий его хранение;
Для данного экземпляра Библиотеки выделяются все хранимые Книги.

Множественность отношения в ассоциации называют мощностью ассоциации, она бывает трех типов:

Один – к – одному;
Один – ко – многим;
Многие – ко – многим.

Наследование классов.

Это отношение, при котором один класс разделяет структуру и поведение, определенные в другом или во многих других классах.

Пример. Иерархическая структура классов системы для записи параметров полета.

Рис. 10 Иерархия простого наследования

Агрегация классов.

Пример. Класс КонтроллерУгла, функция которого выполнять развороты в соответствии с графиком разворотов. Класс КонтроллерУгла является агрегатом, а экземпляр класса РегуляторУгла – одна из его частей.

Рис. 11 Отношение агрегации по величине

Еще примеры агрегации.

Рис. 12 Агрегации классов

Зависимость классов.

Графически зависимость представляется как пунктирная стрелка, направленная на тот класс, от которого зависят.

Рис. 13 Отношение зависимости

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.187 -211]

БАЗИС ЯЗЫКА ВИЗУАЛЬНОГО МОДЕЛИРОВАНИЯ

Для создания моделей анализа и проектирования объектно-ориентированных программных систем используются языки визуального моделирования. Появившись сравнительно недавно, в период с 1989 по 1997 год, эти языки уже имеют представительную историю развития.

В настоящее время различают три поколения языков визуального моделирования. Если в первом поколении было порядка 10то во втором уже порядка 50. Среди наиболее популярных языков 2 поколения следует выделить язык Буча, язык Рамбо, язык Якобсона, язык Ковда – Йордана, язык Шлеера – Меллора и т.д. Каждый язык вводил свои выразительные средства, ориентировался на собственный синтаксис и семантику, иными словами – претендовал на роль единственного языка. В результате разработчики (пользователи этих языков) перестали понимать друг друга. Возникла острая необходимость унификации языков.

Идея унификации привела к появлению языков визуального моделирования 3-го поколения. В качестве стандартного языка был выбран Unified Modeling Language (UML), создававшийся в 1994-1997 годах (основные разработчики – Г.Буч, ДЖ.Рамбо, А.Якобсон). Заботы о развитии UML взял на себя международный консорциум OMG. В 2005 году версия UML 1.4.2 была принята в качестве международного стандарта ISO/IEC 19501:2005. В мае 2010 года появилась версия UML 2.3.

UML – стандартный язык для написания моделей анализа, проектирования и реализации объектно-ориентированных программных систем. UML может использоваться для визуализации, спецификации, разработки и документирования результатов программных проектов. UML – это не визуальный язык программирования, но его модели прямо транслируются в текст на языках программирования и даже в таблицы для реляционной БД.

Основным инструментом представления модели в UML являются диаграммы. Диаграмма UML – это нагруженный связный граф. Вершины графа нагружаются элементами модели, а дуги - отношениями между элементами.

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

Диаграммы UML разделяются на две группы: структурные диаграммы и диаграммы поведения.

Структурные диаграммы отражают статическую структуру элементов в программной системе. Они могут показать структуру нескольких уровней:

Архитектурный уровень

Диаграмма пакетов
Диаграмма компонентов

Уровень детального проектирования

Диаграмма классов
Диаграмма объектов
Диаграмма композитной структуры

Уровень физического размещения

Диаграмма развертывания

Диаграммы поведения описывают динамику системы на следующих этапах разработки:

Формирование требований

Диаграмма последовательности действий
Диаграмма деятельности

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

Диаграмма последовательности
Диаграмма коммуникации
Диаграмма обзора взаимодействий
Диаграмма синхронизации

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

Диаграмма конечного автомата

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

Ограничения;
Теговые величины;
Стереотипы.

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

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

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

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.211 - 215]

ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ФОРМИРОВАНИЕ ТРЕБОВАНИЙ С ПОМОЩЬЮ ДИАГРАММЫ USE CASE

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

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

Вершинами в диаграмме Use Case являются акторы и элементы Use Case. Приведем их обозначения.

Рис. 14 Обозначения актора и элемента Use Case

Акторы представляют внешний мир, нуждающийся в работе системы.

Элементы Use Case представляют действия, выполняемые системой в интересах акторов.

Актор – это роль объекта вне системы, который прямо взаимодействует с ее частью – конкретным элементом Use Case. Различают акторов и пользователей. Пользователь – это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими акторами. Справедливо и обратное – актором могут быть разные пользователи.

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

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

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

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

Элемент Use Case – это описание последовательности действий, которые выполняются системой и производят для отдельного актора видимый результат.

Один актор может использовать несколько элементов Use Case и наоборот. Каждый элемент Use Case задает определенный путь использования системы. Набор всех элементов Use Case определяет полные функциональные возможности системы.

Запускается элемент Use Case актором, поэтому удобно выявлять элементы Use Case с помощью акторов. Рассматривая каждого актора, решают, какие элементы Use Case он может выполнять.

Чаще всего полные описания элементов Use Case формируются за несколько итераций. На каждом шаге в описание вводятся дополнительные детали.

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

Рис. 15 Отношение ассоциации

Между акторами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями экземпляров элементов Use Case, что и экземпляр родителя.

Рис. 16 Отношение обобщения между акторами

Между элементами Use Case определено отношение обобщения и две разновидности отношения зависимости: включения и расширения.

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

Рис. 17 Отношение обобщения между элементами

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

Рис. 18 Отношение включения между элементами

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

Рис. 19 Отношение расширения между элементами

Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее представление системы от ее внутреннего представления.

Поведение элемента Use Case описывается потоком событий. Начальное описание выполняется в текстовой форме, прозрачной для пользователя системы. В потоке событий выделяют:

Основной поток и альтернативные потоки поведения;
Как и когда стартует и заканчивается элемент Use Case;
Когда элемент Use Case взаимодействует с актерами;
Какими данными обмениваются актор и система.

Для уточнения и формализации потоков событий используют диаграммы последовательности. Обычно одна диаграмма последовательности определяет главный поток в элементе Use Case а другие диаграммы – потоки исключений.

В общем случае один элемент Use Case описывает набор последовательностей в котором каждая последовательность представляет возможный поток событий. Каждая последовательность называется сценарием. Сценарий – конкретная последовательность действий, которая иллюстрирует поведение. Сценарии являются для элемента Use Case почти тем же, чем являются экземпляры для класса.

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

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

Количество шагов для выполнения элемента Use Case;
Количество и сложность акторов;
Техническая сложность программного проекта;
Уровень квалификации команды разработчиков.

Вес элемента Use Case пропорционален общему количеству действий, содержащихся во всех его сценариях, а вес актора – сложности его описания. По весу все элементы Use Case делятся на три категории: простой, средний, сложный.

Категория элемента Use Case	описание	вес
Простой	Простой пользовательский интерфейс. Взаимодействует только с одной сущностью БД. В сценарии предусмотрено до трех шагов. Реализуется менее чем пятью классами.	5
Средний	Средний по сложности пользовательский интерфейс. Взаимодействует с двумя и более сущностями БД. В сценариях предусмотрено 4-7 шагов. Реализуется 5-10 классами.	10
Сложный	Сложный пользовательский интерфейс. Взаимодействует с тремя и более сущностями БД. В сценариях предусмотрено более семи шагов. Реализуется более чем десятью классами.	15

Акторы принадлежат к одному из трех типов.

Тип актора	Описание	Вес
Простой	Актор представляет внешнюю систему с точно определенным программным интерфейсом	1
Средний	Актор представляет внешнюю систему, которая взаимодействует по протоколу, подобному TCP/IP	2
Сложный	Актор представляет личность, пользующуюся графическим интерфейсом.	3

Фактор технической сложности проекта определяется с учетом 13 показателей технической сложности. Каждому показателю команда разработчиков назначает значение в диапазоне от 0 до 5. При выборе значения исходят из влияния показателя на сложность конкретного проекта: нуль означает, что влияния нет, 3 – показатель оказывает среднее влияние, 5 – показатель оказывает сильное влияние. Обычно, если влияние неизвестно, выбирают среднее значение – 3.

Показатель технической сложности	Описание	вес
Т1	Распределенная система	2
Т2	Высокая производительность	1
Т3	Эффективность работы конечных пользователей	1
Т4	Сложная обработка данных	1
Т5	Повторное использование кода	1
Т6	Простота установки	0,5
Т7	Простота использования	0,5
Т8	Переносимость	2
Т9	Простота внесения изменений	1
Т10	Параллелизм	1
Т11	Специальные требования к безопасности	1
Т12	Непосредственный доступ к системе со стороны третьих лиц	1
Т13	Специальные требования к обучению пользователей	1

Фактор квалификации разработчиков определяется с учетом 8 показателей квалификации. Каждому показателю команда разработчиков назначает значение в диапазоне от 0 до 5. При выборе значения исходят из влияния показателя на успех конкретного проекта.

Показатель квалификации	Описание	Вес
Е1	Знакомство с UML	1..3
Е2	Работники с частичной занятостью	1
Е3	Квалификация аналитика	0,5
Е4	Опыт работы с прикладной областью	0,5
Е5	Опыт использования объектно-ориентированного подхода	1
Е6	Мотивация	1
Е7	Сложность языка программирования	1
Е8	Стабильность требований	2

Литература:

Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения: Учебник для вузов. /4-е изд. Стандарт третьего поколения. – СПб.: Питер, 2012. – 608 с. [с.218 - 239]

Мне нравится

Навигация

Главные вкладки

Лекции_ТРПОметодическая разработка

Скачать:

Предварительный просмотр:

Лекции_ТРПО
методическая разработка