Розробка програмного забезпечення Загальні відомості про стандарт SWEBOK Разработка и ис

Работа добавлена на сайт samzan.net:

PAGE 119

ОСНОВИ ПРОГРАМНОЇ ІНЖЕНЕРІЇ

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

Спеціальність: 5.05010301 «Розробка програмного забезпечення»

Загальні відомості про стандарт SWEBOK

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

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

Примерно каждые 10 лет происходит смена языков программирования и операционных сред для описания и функционирования программ. Это предполагает изменение ранее изготовленных и функционирующих программ в новые языки и операционные среды.

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

Вместе с тем, новый программный проект разрабатывается 1-2 года, а эволюционирует 6-7 лет. На его сопровождение тратиться 61% затрат против 39% на его разработку.

В связи с этим мировое компьютерное сообщество пришло к необходимости систематизации накопленных знаний и общие из них зафиксировать в виде ядер знаний (Body of Knowledge - BOK) для разных областей информатики. Для создания ядра знаний ПО был создан международный комитет при американском объединении компьютерных специалистов ACM (Association for Computing Machinery) и институте инженеров по электронике и электротехнике IEEE Computer Society. В комитет вошли специалисты мирового уровня в области информатики и разработки ПО, которые внесли свой опыт и знания, а также систематизировали накопленные разнородные знания и определили (1999г., 2001г., 2004г.) ядро профессиональных знаний SWEBOK (Software Engineering Body Knowledge) программной инженерии, как основы проектирования ПО. Ядро включает сумму знаний, распределенную по 10 специализированным областям, которые отражают отдельные процессы проектирования ЖЦ ПО и методы их поддержки.

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

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

Компьютерная наука (computer science) охватывает теорию и методы построения вычислительных и программных систем, тогда как программная инженерия рассматривает вопросы практического построения ПО.

SWEBOK содержит разделы:

1. Основы программных требований (Software Requirements)

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

2. Проектирование ПО (Software design)

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

3. Конструирование ПО (Software Construction)

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

4. Тестирование ПО (Software Testing)

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

5. Сопровождение ПО (Software maintenance)

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

6. Управление конфигурацией ПО (Software Configuration Management-SCM)

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

7. Управление инженерией ПО (Software Engineering Management)

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

8. Процесс инженерии ПО (Software Engineering Process)

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

9. Методы и средства инженерии ПО (Software Engineering Tools and Methods)

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

10. Качество ПО (Software Quality)

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

Стандарт 12207: процеси життєвого циклу програмного забезпечення

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

Каждая ПС на протяжении своего существования проходит определенную последовательность процессов (этапов), начиная от постановки задачи, до ее воплощения в готовую программу, эксплуатации и изъятия. Такая последовательность этапов называется жизненным циклом (ЖЦ) разработки ПС. На каждом этапе ЖЦ выполняется определенная совокупность процессов и/или подпроцессов, каждый из которых порождает соответствующий промежуточный продукт, используя результаты предыдущего.

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

Разновидности действий и задач, представленные в процессах ЖЦ ПС, отображены в международном стандарте ISO\IEC 12207 и связаны содержательно с областями знаний SWEBOK.

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

Стандарт не обязывает использовать определенную модель ЖЦ ПО или конкретную методологию разработки ПО и не предъявляет требования к формату и содержанию создаваемых документов. Поэтому организации-пользователю этого стандарта потребуются для своей работы дополнительные стандарты или процедуры, определяющие разные детали процесса (ISO выпускает руководства и процедуры, дополняющие стандарт 12207).

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

Все процессы в данном стандарте разделены на три категории:

основные процессы;

обеспечивающие (поддерживающие) процессы;

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

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

К основным процессам относятся:

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

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

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

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

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

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

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

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

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

Каскадна модель життєвого циклу програмного забезпечення

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

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

Охарактеризуем содержание основных этапов.

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

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

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

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

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

архитектуры ПО;
модульной структуры ПО;
алгоритмической структуры ПО;
структуры данных;
входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО.

Цели изменений:

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

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

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

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

Недостатки классического жизненного цикла:

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

Інкрементна модель життєвого циклу програмного забезпечення
Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис. 1.4). Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.

Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы.

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

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

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

Современная реализация инкрементного подхода — экстремальное программирование ХР (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

Спіральна модель життєвого циклу програмного забезпечення

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

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

Планирование — определение целей, вариантов и ограничений.
Анализ риска — анализ вариантов и распознавание/ выбор риска.
Конструирование — разработка продукта следующего уровня.

Оценивание — оценка заказчиком текущих результатов конструирования.

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

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

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

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

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

Недостатки спиральной модели:

новизна (отсутствует достаточная статистика эффективности модели);
повышенные требования к заказчику;
трудности контроля и управления временем разработки.
Важковагові та полегшені процеси розробки програмного забезпечення

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

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

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

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

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

Таким образом, в современной инфраструктуре программной инженерии существуют два семейства процессов разработки:

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

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

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

ХР-процес розробки програмного забезпечення

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

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

Базис ХР образуют перечисленные ниже двенадцать методов.

Игра планирования (Planning game) — быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продвижение (прогресс).
Частая смена версий (Small releases) — быстрый запуск в производство простой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.
Метафора (Metaphor) — вся разработка проводится на основе простой, общедоступной истории о том, как работает вся система.
Простое проектирование (Simple design) — проектирование выполняется настолько просто, насколько это возможно в данный момент.
Тестирование (Testing) — непрерывное написание тестов для модулей, которые должны выполняться безупречно; заказчики пишут тесты для демонстрации законченности функций. «Тестируй, а затем кодируй» означает, что входным критерием для написания кода является «отказавший» тестовый вариант.
Реорганизация (Refactoring) — система реструктурируется, но ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.
Парное программирование (Pair programming) — весь код пишется двумя программистами, работающими на одном компьютере.
Коллективное владение кодом (Collective ownership) — любой разработчик может улучшать любой код системы в любое время.
Непрерывная интеграция (Continuous integration) — система интегрируется и строится много раз в день, по мере завершения каждой задачи. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гарантирует, что изменения требований не приведут к регрессу функциональности.
40-часовая неделя (40-hour week) — как правило, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.
Локальный заказчик (On-site customer) — в группе все время должен находиться представитель заказчика, действительно готовый отвечать на вопросы разработчиков.
Стандарты кодирования (Coding standards) — должны выдерживаться правила, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

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

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

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

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

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

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

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

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

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

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

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

Види вимог

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

Функциональные требования задают назначение системы, а нефункциональные -условия выполнения ПО. Системные требования описывают требования к программной системе, состоящей из взаимосвязанных программных и аппаратных подсистем и разных приложений. Требования могут оцениваться количественно (например, количество запросов в сек., средний показатель ошибок не должен превышать 1.5% от объема вводимой информации и т.п.). Значительная часть требований относится к атрибутам качества: безотказность, надежность и др. Область знаний «Требования к ПО (Software Requirements)» состоит из следующих разделов:

- инженерия требований (Requirement Engineering),

- выявление требований (Requirement Elicitation),

- анализ требований (Requirement Analysis),

- спецификация требований (Requirement Specification).

- проверка требований (Requirement validation),

- управление требованиями (Requirement Menegement).

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

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

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

Качество и процесс улучшения требований - это процесс формулировки характеристик и атрибутов качества (надежность, реактивность и др.), которыми должна обладать система и ПО, методы их достижения на этапах ЖЦ и адекватности процессов работы с требованиями.

Согласно международного глоссария по терминологии [6] требования включают описание:

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

3) документированное представление условий или возможностей проектирования
системы.

Виды требований

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

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

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик».

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

Функциональные требования включают описание требований в видам и типам реализуемых функций и документируются в спецификации требований к ПО (software requirements specification, SRS), где описано и ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и его функциями. В дополнение к функциональным требованиям спецификация содержит нефункциональные требования (защита данных, адаптивность, изменчивость и др.), где описаны цели и атрибуты качества.

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

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

Аналіз вимог

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

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

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

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

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

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

- требования связаны друг с другом, а также с процессами разработки ПС и постоянно меняются.

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

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

анализировать проблему,

понимать потребности заказчика и пользователей,

определять функции системы и требования к ним,

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

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

Здесь цена ошибок и нечетких неоднозначных формулировок очень высока, поскольку время и средства могут расходоваться на ненужную заказчику систему или программу. Для внесения изменений в требования может потребоваться повторное проектирование и, соответственно, перепрограммирование всей системы или отдельных ее частей. Как утверждает статистика, процент ошибок в постановке требований и в определении задач системы превышает процент ошибок кодирования. Это является следствием субъективного характера процесса формулирования требований и отсутствия способов его формализации. К примеру, в США ежегодно расходуется до $ 82 млрд. на проекты, признанные после реализации не соответствующими требованиям заказчиков.

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

В процессе формулирования требований на систему принимают участие:

представители от заказчика из нескольких профессиональных групп;

операторы, обслуживающие систему;

разработчики системы.

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

Сбор требований. Источниками сведений о требованиях могут быть:

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

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

Таким образом, требования к системе формулируются исходя из:

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

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

Методами сбора требований являются:

интервью с носителями интересов заказчика и операторами;

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

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

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

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

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

Нефункциональные требования определяют условия и среду выполнения функций (например, защита и доступ к БД, секретность, взаимодействие компонентов функций и др.).

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

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

конфиденциальность;

отказоустойчивость;

несанкционированный доступ к системе;

безопасность и защита данных;

время ожидания ответа на обращение к системе;

свойства системы (ограничение на память, скорость реакции при обращении к системе и т. п.).

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

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

Следующий шаг анализа требований - установление их приоритетов и избежание конфликтов между ними.

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

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

Верифікація та формалізація вимог

Спецификация требований к ПО - процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 9126-94, которые будут отрабатываться на этапах ЖЦ ПО. В спецификации требований отражается структура ПО, требования к функциям, качеству и документации, а также задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структура данных.

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

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

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

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

Фиксация требований (Requirement Capturing), с одной стороны, определяется желаниями заказчика в реализации того или иного свойства. С другой стороны в процессе сбора требований может обнаружиться ошибка, которая приведет к определенным последствиям, устранение которых заберет непредвиденные ресурсы -дополнительное кодирование, перепланирование.

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

Автоматизированная верификация требований может производиться лишь после спецификации или формализации требований.

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

Об’єктно-орієнтована інженерія вимог

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

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

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

Объектно-ориентированный подход к разработке программных систем такого недостатка не имеет. В нем общее видение решения проблемы формирования требований осуществляется исходя из следующих постулатов:

мир составляют объекты, которые взаимодействуют между собой;

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

объекты могут вступать в отношения друг с другом;

значения атрибутов и отношения могут с течением времени изменяться;

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

совокупность состояний объектов определяет состояние мира объектов;

мир и его объекты могут находиться в разных состояниях и порождать некоторые события;

события могут быть причиною других событий или изменений состояний.

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

переходы из одного состояния в другое под влиянием соответствующих событий;

возбуждение определенных событий или посылка сообщений другим объектам;

операции, которые могут выполнять объекты;

возможные совокупности действий, которые задают его поведение;

- обмен сообщениями.

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

- пользователь избавлен от необходимости знать лишнее;

- то, что ему не сообщили, он не испортит (защита от намеренных или случайных неправомерных действий;

- все, о чем не знает пользователь, можно изменять.

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

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

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

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

В настоящее время предложен ряд современных методов объектно-ориентированного анализа требований, объектно-ориентированного проектирования программ, объектно-ориентированного программирования (С++, JAVA). Наибольшую ценность среди них имеет проблема согласованности между ними.

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

Концептуальное моделирование проблемы системы происходит в терминах взаимодействия объектов:

- онтология домена определяет состав объектов домена, их атрибуты и взаимоотношения, а также оказываемые услуги;

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

- модель процессов определяет действия, которые выполняют объекты.

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

Метод інженерії вимог А. Джекобсона

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

Автор назвал свой метод как базирующийся на вариантах (примерах или сценариях -use case driven) системы, которую требуется построить. В дальнейшем термин сценарий используется для обозначения варианта представления системы.

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

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

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

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

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

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

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

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

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

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

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

Экземпляр сценария существует, пока он выполняется и его можно считать экземпляром класса, в роли которого выступает описание транзакции.

Сценарий определяет протекание событий в системе и обладает состоянием и поведением. Каждое взаимодействие между актером и системой это новый сценарий или объект. Если несколько сценариев системы имеют одинаковое поведение, то их можно рассматривать как класс сценариев. Вызов сценария - это порождение экземпляра класса. Таким образом, сценарии - это транзакции с внутренним состоянием.

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

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

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

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

- сценарий изображается овалом, в середине которого указывается название иконы;

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

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

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

Для сценариев определены два типа отношений:

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

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

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

Визначення об’єктів в моделі аналізу вимог

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

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

- изменение требований неизбежно;

- объект модифицируется вследствие изменения соответствующих требований к системе;

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

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

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

- определение поведения системы;

- презентация системы (ее интерфейсов с пользователями и другими системами).

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

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

Рассматривается три типа объектов:

- объекты-сущности;

- объекты интерфейса;

- управляющие объекты.

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

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

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

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

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

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

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

- взаимодействует,

- составляется с,

- выполняет роль,

- наследует,

- расширяет,

- использует.

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

Исходя из известного метода анализа требований И. Джекобсона на стадии анализа определяются:

- онтология домена;

- модель сценариев;

- неформальное описание сценариев и актеров;

- описание интерфейсов сценариев и актеров;

- диаграммы взаимодействия объектов сценариев.

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

Трасування та атрибути вимог

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

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

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

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

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

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

Механизмы трассировки должны учитывать следующее:

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

Желательно наличие механизмов поддержки возможностей объектно-ориентированного программирования, операций над классами, а также механизмов унификации функций и отношений (1:1, 1:М,уничтожение и изменение связей, установка стандартных связей).

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

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

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

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

Перевірка та вимірювання вимог

Определение требований напрямую связано с процедурами проверки (verification) и утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято

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

Часто, в крупных организациях вместо полноценной проверки сути и содержания документов, все сводиться к так называемому "нормоконтролю" -- когда проверка документов требований заключается в проверке на соблюдение принятых стандартов внешнего оформления документа (отступы и размеры поля, подписи таблиц/рисунков и т.п.), но никак ни оценки качества требований. И совершенно неверно считать такой "нормоконтроль" полноценной проверкой требований.

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

Обзор требований (Requirements Review)

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

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

Прототипирование (Prototyping)

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

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

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

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

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

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

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

Утверждение модели (Model Validation)

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

Приемочные тесты (Acceptance Tests)

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

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

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

Основні поняття аналізу предметної області

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

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

<имя объекта > <концепт>,

где <имя объекта> - идентификатор, строка из литер и десятичных чисел;

< концепт > - некоторый денотат, определяющий объект реального мира в соответствии с интерпретацией сущности моделируемой ПрО.

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

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

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

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

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

Концепт вместе со своими атрибутами в информационной концептуальной модели представляется графически или в текстовом виде.

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

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

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

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

а) в случае связи 1:1 дополнительный атрибут может определяться для одного из объектов связи и содержать идентификатор экземпляра, который принимает участие в связи;

б) в случае связи 1:К дополнительный атрибут предоставляет объекту N экземпляров, принимающих участие в связи;

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

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

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

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

Метод аналізу предметної області

Наиболее распространенными методами объектно-ориентированного анализа ПрО, широко используемые в практике программирования являются следующие:

метод OOAS, позволяющий выделить объекты реального мира ПрО, определить сущности, свойства и отношения объектов и из них построить информационную модель, модель состояний объектов и процессов представления потоков данных (dataflow);

метод OOA позволяет провести анализ, определить требований к ПрО, специфицировать потоки данных в ПрО в виде диаграммной модели;

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

- методология OOAD позволяет построить модели ПрО с помощью ER-моделирования, понятий и их отношений с использованием структурных диаграмм, диаграмм «сущность-связь» и матрицы информационного управления;

- объектное OMT моделирование объектной, динамической, функциональной моделей и взаимодействия объектов;

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

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

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

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

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

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

- информационная модель системы или онтология домена;

- модель состояний объектов, определенных в составе информационной модели (или онтологии);

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

Інформаційна модель в даграмі С. Шлаер та С. Меллора для аналізу предметної області

Информационная модель

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

- реальные предметы мира, имеющие физическое воплощение;

- абстракции физических предметов этого мира;

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

- взаимодействия - это отношение между объектами;

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

Для классов объектов выбираются уникальные имена, устанавливаются атрибуты и устанавливаются связи между объектами.

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

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

- задание числового диапазона;

- перечисление возможных значений;

- ссылка на документ, в котором определены возможные значения;

- правила генерации значений.

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

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

- каждый экземпляр объекта обязательно имеет одно значение (значение не может быть неопределенным или отсутствующим);

- атрибут одномерен и не имеет нескольких значений одновременно;

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

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

1) проект имеет исполнителей, которые заняты в проекте;

2) руководитель управляет исполнителями, т.е. исполнитель подчинен руководителю;

3) исполнитель занимает комнату, т.е. комната занята исполнителем.

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

В методе различаются три фундаментальных вида связи между объектами:

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

- один ко многим (1:п), один экземпляр объекта некоторого класса может поддерживать отношения одновременно с несколькими экземплярами объектов другого или того же класса (пример, руководитель может иметь несколько подчиненных, но у каждого из них один шеф);

- много ко многим (m: n ), в связи могут принимать участие несколько экземпляров объектов с каждой стороны.

Метод С.Шлаер и С.Меллора предусматривает специальную графическую нотацию для фиксации связей, базирующихся на диаграммах метода Чена сущность - связь (entity-relations) [3] для представления информационной модели проблемной области, суть которого заключается в следующем.

Связи между объектами изображаются стрелками, указывающими направление связи. Возле рамки объекта, принимающей участие в связи, на линии стрелки указывается роль, которая этот объект поддерживает в данной связи. Связь 1:1 обозначается двунаправленной стрелкой, имеющей по одному "наконечнику" стрелки с каждой стороны, связь 1:n обозначается стрелкой, имеющей два "наконечника" со стороны объекта, для которого в связи могут принимать участие несколько экземпляров, и, наконец, по два "наконечника" с каждой стороны имеет стрелка, означающая связь вида n : m.

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

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

Модель станів в діаграмі С. Шлаер та С. Меллора для аналізу предметної області

Модель состояний

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

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

- состояние объекта изменяется в результате произошедших действий или стимулов;

- состояние домена, которое определяется совокупностью состояний его объектов;

- изменение состояния объекта сопровождается некоторыми процессами, которые определены для каждого состояния.

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

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

Для каждого из выделенных объектов определяются:

1) множество состояний, в которых объект может находиться;

2) множество инцидентов или событий, которые побуждают экземпляры класса изменять свое состояние;

3) правила перехода для каждого из зафиксированных состояний, как указание на новое состояние экземпляра данного класса, если произойдет некоторое событие из множества событий тогда, когда объект находится в данном состоянии;

4) действия или процессы для каждого из определенных состояний, которые выполняются при переходе в данное состояние.

Для представления этой информации в нотации диаграммы перехода состояний предусматривается следующее:

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

- состояние обозначается рамкой, содержащей номер и название состояния;

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

- начальное состояние обозначается стрелкой, направленной к соответствующей рамке и является состоянием, которое экземпляр объекта приобретает после его создания (или инициализации);

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

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

Для изменения состояния экземпляра класса объектов выполняются действия:

- обработка информации, переданной в сообщении о событии;

- изменение определенного атрибута объекта;

- вычисления;

- генерация операции для некоторого экземпляра класса;

- генерация события, сообщение о котором должно передается внешнему по отношению к данному домену объекту (например, человеку-оператору другой системе);

- передача сообщения о событии от внешних объектов;

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

Атрибутами таймера являются:

- уникальный идентификатор экземпляра таймера;

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

- метка наступающего события, при условии, что остаток времени равен нулю;

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

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

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

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

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

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

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

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

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

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

Модель процесів в діаграмі С. Шлаер та С. Меллора для аналізу предметної області

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

В качестве источников данных могут быть:

- атрибуты объектов, которые продолжают существовать после завершения работы системы;

- системные часы, как показатель времени; таймеры;

- данные событий;

- сообщения внешних объектов (людей, операторов и т. п.).

Правила построения диаграмм действий потоков данных:

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

- процесс изображается овалом, в середине которого указано содержание или название процесса;

- потоки данных изображены стрелками, на которых указываются идентификаторы данных, передаваемых от процесса к процессу; стрелка к овалу процесса указывает на входные данные процесса, направление от овала процесса - на выходные данные;

- источники данных изображены как прямоугольники или рамками с открытыми сторонами;

- данным, имеющим своими источниками архивные объекты, соответствуют потоки с названиями атрибутов объектов, которые передаются потоками (при этом название объекта может не указываться);

- потоки данных от таймера маркируются названием таймера;

- потоки данных от системных часов маркируются показателями времени (час, минута, и т. п.);

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

- процесс, породивший событие и процесс от приема сообщения о событии, относятся к одной диаграмме действий потоков данных и связывается потоком;

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

Различаются следующие типы процессов:

- аксессор, осуществляющий доступ к архивам;

- генератор событий;

- преобразователь данных (вычисления);

- проверки условий.

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

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

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

идентификатор процесса; тип процесса; название процесса;

название состояния, для которого определен процесс; название действия состояния.

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

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

Результатами метода инженерии требований С.Шлаер и С.Меллора являются три модели.

1. Информационная модель системы, состоящая из:

- диаграммы сущность - связь;

- описания объектов и их атрибутов (неформальное);

- описания связей между объектами (неформальное).

2. Модель поведения объектов системы, представленная в виде:

- диаграммы переходов в состояния диаграмм перехода состояний или таблицы перехода состояний;

- неформальное описания действий диаграммами перехода состояний;

- неформальное описания событий диаграммами перехода состояний.

3. Модель процессов состояний объектов, представленная в виде:

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

- таблицы процессов состояний;

- неформальное описание процессов.

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

Методи проектування архітектури ПЗ

Область знаний йПроектиротаки ПО (Software Dдign)» состоит из следующих разделов:

базовые концепции проектирования ПО (Software Design Basic Concepts),

ключевые вопросы проектирования ПО (Key Issue in Software Design),

структура и архитектура ПО (Software Structure and Architecture),

анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),

нотации проектирования ПО (Software Design Notations),

стратегия и методы проектирования ПО (Software Design Strategies and Methods).

К базовым концепциям проектирования ПО относятся процессы ЖЦ (стандарт ISO/IEC 12207), процесс проектирования архитектуры с использованием разных принципов (объектного, компонентного и др.) и техник: абстракции, декомпозиции, инкапсуляции и др. Автоматизируемая система декомпозируется на отдельные компоненты, выбираются необходимые артефакты (нотации, методы и др.) программной инженерии и строится архитектура ПО.

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

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

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

Паттерн - это конструктивный элемент ПО, который задает взаимодействие объектов (компонентов) проектируемой системы, определение ролей и ответственности исполнителей. Основным языком задания этого элемента является UML.

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

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

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

Структурные нотации являются графическими, они используются для представления структурных аспектов проектирования, компонентов и их взаимосвязей, элементов архитектуры и их интерфейсов. К ним относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relation Diagrams), IDL (Interface Description Language), классы и объекты, компоненты и классы (CRC Cards), Use Case Driven и др. Нотации включают языки описания архитектуры и интерфейса, диаграммы классов и объектов, диаграммы сущность-связь, компонентов, развертывания, а также структурные диаграммы и схемы.

Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Таким нотациям соответствуют диаграммы: Data Flow, Decision Tables, Activity, Colloboration, Pre-Post Conditions, Sequence, таблицы принятия решений, формальные языки спецификации, языки проектирования PDL и др.

Стратегия и методы проектирования ПО. Данный раздел знаний представляет различные стратегии и методы, которые используются при проектировании. К общим стратегиям относятся: снизу-вверх, сверху-вниз, абстракции, паттерны и др. Функционально-ориентированные (структурные) методы базируются на структурном анализе, структурных картах, Dataflow-диаграммах и др. Они ориентированы на идентификацию функций и их уточнение сверху-вниз, после чего проводится разработка диаграмм потоков данных и описание процессов. В обьектно-ориентированном проектировании ключевую роль играет наследование, полиморфизм и инкапсуляция, а также абстрактные структуры данных и отображение объектов [30] Подходы, ориентированные на структуры данных, базируются на методе Джексона (Jackson) [8] и используются для задания входных и выходных данных структурными диаграммами.

Компонентное проектирование ориентировано на использование и интеграцию компонентов (особенно компонентов повторного использования) и на их интерфейс, обеспечивающий взаимодействие компонентов; является базисом других видов программирования, в том числе сервисно-ориентированного, в котором группы компонентов обеспечивают функциональный сервис. К другим методам относятся: формальные, точные и трансформационные методы, а также UML для моделирования архитектурных решений с помощью диаграмм [31].

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

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

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

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

Структурний підхід до проектування

Разработка автоматизированных систем (АС) выполнялась и выполняется на основе положений, представленных в стандарте ГОСТ 34.601-90. Он состоит из стадий и этапов разработки АС, которые, в зависимости от особенностей автоматизируемой системы, можно объединять друг с другом или вообще не включать в процесс разработки. Основанием для разработки АС является договор между разработчиком системы и ее заказчиком.

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

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

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

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

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

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

- концептуальное проектирование, которое состоит в уточнении и согласовании деталей требований;

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

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

детальное проектирование, которое состоит в определении алгоритмов задач, построения БД и программного обеспечения системы.

При концептуальном проектировании определяются:

источники поступления данных от заказчика, который несет ответственность за их достоверность;

объекты системы и их атрибуты;

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

интерфейсы с потенциальными пользователями системы на ранних стадиях ЖЦ цикла разработки системы для оказания им помощи при формулировки целей и функций системы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В основу структурного подхода положены такие общие принципы:

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

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

В основе этих принципов лежат операции:

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

формализации, т.е строгое методологическое решение проблемы;

непротиворечивости, состоящей в обосновании и согласовании элементов системы;

структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).

При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПС:

SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы;

SSADM (Structured Systems Analysis and Design Method) - метод структурного анализа и проектирования;

IDEF0 (Integrated Definition Functions) метод создания функциональной модели, IDEF1 - информационной модели, IDEF2 - динамической модели и др.

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

Об’єктно-орієнтований підхід до проектування

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

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

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

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

1. Объектно-ориентированный анализ. Создание объектно-ориентированной модели предметной области приложения. Здесь объекты отражают реальные объекты-сущности и операции, выполняемые этими объектами.

2. Объектно-ориентированное проектирование. Разработка объектно-ориентированной модели системы ПО (системной архитектуры) с учётом требований. В этой модели определение всех объектов подчинено решению конкретной задачи.

3. Объектно-ориентированное программирование. Реализация архитектуры (модели) системы с помощью объектно-ориентированного языка программирования (С++, Java) для определения объектов и средств определения классов объектов.

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

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

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

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

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

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

Существует два типа моделей системной архитектуры:

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

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

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

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

Методи моделювання UML

Метод UML (United Modeling Language — унифицированный язык моделирования) является результатом совместной разработки специалистов программной инженерии и инженерии требований. Он широко используется ведущими разработчиками программного обеспечения как метод моделирования программных продуктов на всех стадиях жизненного цикла разработки программных систем.

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

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

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

— модель процессов определяет действия, которые выполняют объекты.

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

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

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

Некоторые стереотипы являются фиксированными в UML и имеют стандартные названия, например, «актер», «система», «подсистема», «исключительная ситуация», «интерфейс» и т.п.

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

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

Предмети в UML

В UML имеются четыре разновидности предметов:

структурные предметы;

предметы поведения;

группирующие предметы;

поясняющие предметы.

Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для написания моделей.

Структурные предметы являются существительными в UML-моделях. Они представляют статические части модели — понятийные или физические элементы. Перечислим восемь разновидностей структурных предметов.

	1. Класс — описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантику (смысл). Класс реализует один или несколько интерфейсов. Как показано на рис., графически класс отображается в виде прямоугольника, обычно включающего секции с именем, свойствами (атрибутами) и операциями.
	2. Интерфейс — набор операций, которые определяют услуги класса или компонента. Интерфейс описывает поведение элемента, видимое извне. Интерфейс может представлять полные услуги класса или компонента или часть таких услуг. Интерфейс определяет набор спецификаций операций (их сигнатуры), а не набор реализаций операций. Графически интерфейс изображается в виде кружка с именем, как показано на рис. Имя интерфейса обычно начинается с буквы «I». Интерфейс редко показывают самостоятельно. Обычно его присоединяют к классу или компоненту, который реализует интерфейс.
	3. Кооперация (сотрудничество) определяет взаимодействие и является совокупностью ролей и других элементов, которые работают вместе для обеспечения коллективного поведения более сложного, чем простая сумма всех элементов. Таким образом, кооперации имеют как структурное, так и поведенческое измерения. Конкретный класс может участвовать в нескольких кооперациях. Эти кооперации представляют реализацию паттернов (образцов), которые формируют систему. Как показано на рис. 10.3, графически кооперация изображается как пунктирный эллипс, в который вписывается ее имя.
	4. Актер — набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами Use Case). Каждая роль требует от системы определенного поведения. Как показано на рис., актер изображается как проволочный человечек с именем.
	5. Элемент Use Case (Прецедент) — описание последовательности действий (или нескольких последовательностей), выполняемых системой в интересах отдельного актера и производящих видимый для актера результат. В модели элемент Use Case применяется для структурирования предметов поведения. Элемент Use Case реализуется кооперацией. Как показано на рис., элемент Use Case изображается как эллипс, в который вписывается его имя.
	6. Активный класс — класс, чьи объекты имеют один или несколько процессов (или потоков) и поэтому могут инициировать управляющую деятельность. Активный класс похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов. Как показано на рис., активный класс изображается как утолщенный прямоугольник, обычно включающий имя, свойства (атрибуты) И операции.
	7. Компонент — физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов. В систему включаются как компоненты, являющиеся результатами процесса разработки (файлы исходного кода), так и различные разновидности используемых компонентов (СОМ-компоненты, Java Beans). Обычно компонент — это физическая упаковка различных логических элементов (классов, интерфейсов и сотрудничеств); Как показано на рис., компонент изображается как прямоугольник с вкладками, обычно включающий имя.
	8. Узел — физический элемент, который существует в период работы системы и представляет ресурс, обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Как показано на рис., узел изображается как куб с именем.

Предметы поведения — динамические части UML-моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Существуют две основные разновидности предметов поведения.

1. Взаимодействие — поведение, заключающее в себе набор сообщений, которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции. Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами). Как показано на рис., сообщение изображается в виде направленной линии с именем ее операции.

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

Эти два элемента — взаимодействия и конечные автоматы — являются базисными предметами поведения, которые могут включаться в UML-модели. Семантически эти элементы ассоциируются с различными структурными элементами (прежде всего с классами, сотрудничествами и объектами).

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

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

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

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

Відношення в UML

В UML имеются четыре разновидности отношений:

зависимость;
ассоциация;
обобщение;
реализация.

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

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

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

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

Реализация — семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их. Как показано на рис., реализация изображается как нечто среднее между обобщением и зависимостью.

Діаграми в UML

Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).

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

Диаграмма - в самом общем смысле некоторый срез системы.

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

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

Диаграммы объектов (object diagram) , на которых представляются объекты и отношения между ними. Это статические снимки экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы сточки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.

Диаграммы прецедентов (use case diagram) , на которых представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения возможностей ее использования. Это вид диаграмм особенно важен при организации и моделирования поведения системы.

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

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

Диаграммы деятельности (activity diagram) - это частный случай диаграмм состояний. На диаграмме этого типа представляются переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм относится к динамическим представлениям системы, и является наиболее полезным при моделировании ее функционирования, так как отражает передачу потока управления между объектами.

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

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

Діаграми класів в UML

Итак, вершина в диаграмме классов — класс. Обозначение класса показано на рис.

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

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

Свойства

Общий синтаксис представления свойства имеет вид

Видимость Имя [Множественность]: Тип - НачальнЗначение {Характеристики}

Рассмотрим видимость и характеристики свойств. В языке UML определены три уровня видимости:

public любой клиент класса может использовать свойство (операцию), обозначается символом +

protected любой наследник класса может использовать свойство (операцию), обозначается символом #

private свойство (операция) может использоваться только самим классом, обозначается символом -

Если видимость не указана, считают, что свойство объявлено с публичной видимостью.

Определены три характеристики свойств:

changeable Нет ограничений на модификацию значения свойства

addOnly Для свойств с множественностью, большей единицы; дополнительные значения могут быть добавлены, но после создания значение не может удаляться или изменяться

frozen После инициализации объекта значение свойства не изменяется

Если характеристика не указана, считают, что свойство объявлено с характеристикой changeable.

Организация свойств и операций

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

Множественность

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

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

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

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

Діаграми схем станів

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

Диаграмма схем состояний показывает:

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

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

Переходы между состояниями отображаются помеченными стрелками

На рис. обозначено: Событие — происшествие, вызывающее изменение состояния, Действие — набор операций, запускаемых событием.

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

Для отображения перехода в начальное состояние принято обозначение, показанное на рис. .

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

Действия в состояниях

Для указания действий, выполняемых при входе в состояние и при выходе из состояния, используются метки entry и exit соответственно.

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

Условные переходы

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

Правила пометки стрелок условных переходов иллюстрирует рис.:

Вложенные состояния

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

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

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

Діаграми діяльності

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

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

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

Фактически в данную вершину вписывается имя другой диаграммы, имеющей внутреннюю структуру.

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

Кроме того, в диаграммах деятельности используются вспомогательные вершины:

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

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

Вершина «объединением отмечает точку слияния альтернативных потоков действий.

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

Діаграми взаємодії

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

Для формирования диаграммы сотрудничества выполняются следующие действия:

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

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

Первая характеристика — линия жизни объекта.

Линия жизни объекта — это вертикальная пунктирная линия, которая обозначает период существования объекта.

Вторая характеристика — фокус управления.

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

Діаграми співробітництва

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

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

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

ИмяОбъекта : ИмяКласса

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

Имя : Тип = Значение

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

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

«global» Объект-поставщик находится в глобальной области определения

«local» Объект-поставщик находится в локальной области определения объекта-клиента

«parameter» Объект-поставщик является параметром операции объекта-клиента

«self» Один и тот же объект является и клиентом, и поставщиком

Сообщение — это спецификация передачи информации между объектами в ожидании того, что будет обеспечена требуемая деятельность. Прием сообщения рассматривается как событие.

Результатом обработки сообщения обычно является действие. В языке UML моделируются следующие разновидности действий:

Вызов В объекте запускается операция

Возврат Возврат значения в вызывающий объект

Посылка (Send) В объект посылается сигнал

Создание Создание объекта, выполняется по стандартному сообщению «create»

Уничтожение Уничтожение объекта, выполняется по стандартному сообщению «destroy»

Для записи сообщений в языке UML принят следующий синтаксис:

ВозврВеличина := ИмяСообщения (Аргументы),

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

Когда объект посылает сообщение в другой объект (делегируя некоторое действие получателю), объект-получатель, в свою очередь, может послать сообщение в третий объект, и т. д. Так формируется поток сообщений — последовательность управления. Очевидно, что сообщения в последовательности должны быть пронумерованы. Номера записываются перед именами сообщений, направления сообщений указываются стрелками (размещаются над линиями связей).

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

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

Итерация представляет повторяющуюся последовательность сообщений.

Сообщение альтернативной ветви помечается таким же номером, но с другим условием

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

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

Діаграми послідовності

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

Графически диаграмма последовательности — разновидность таблицы, которая показывает объекты, размещенные вдоль оси X, и сообщения, упорядоченные по времени вдоль оси У.

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

Первая характеристика — линия жизни объекта.

Линия жизни объекта — это вертикальная пунктирная линия, которая обозначает период существования объекта. Большинство объектов существуют на протяжении всего взаимодействия, их линии жизни тянутся от вершины до основания диаграммы. Впрочем, объекты могут создаваться в ходе взаимодействия. Их линии жизни начинаются с момента приема сообщения «create». Кроме того, объекты могут уничтожаться в ходе взаимодействия. Их линии жизни заканчиваются с момента приема сообщения «destroy».

Вторая характеристика — фокус управления.

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

Діаграми 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 может иметь несколько актеров, использующих его. Каждый элемент 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. Отношение включения является примером отношения делегации. При этом в отдельное место (включаемый элемент 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;

когда элемент Use Case взаимодействует с актерами;

какими данными обмениваются актер и система.

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

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

Діаграми об’єктів в UML

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

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

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

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

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

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

В чистых объектно-ориентированных языках программирования операции могут объявляться только как методы — элементы классов, экземплярами которых являются объекты. Гибридные языки (C++, Ada 95) позволяют писать операции как свободные подпрограммы (вне классов).

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

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

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

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

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

Виды отношений между объектами

В поле зрения разработчика ПО находятся не объекты-одиночки, а взаимодействующие объекты, ведь именно взаимодействие объектов реализует поведение системы. У Г. Буча есть отличная цитата из Галла: « Самолет — это набор элементов, каждый из которых по своей природе стремится упасть на землю, но ценой совместных непрерывных усилий преодолевает эту тенденцию». Отношения между парой объектов основываются на взаимной информации о разрешенных операциях и ожидаемом поведении. Особо интересны два вида отношений между объектами: связи и агрегация.

Связи

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

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

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

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

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

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

Видимость объектов

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

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

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

Агрегация

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

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

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

агрегация инкапсулирует части как секреты целого.

Основи конструювання

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

Область знаний «Конструирование ПО (Software Construction)» включает следующие разделы:

снижение сложности (Reduction in Complexity),

предупреждение отклонений от стиля (Anticipation of Diversity),

структуризация для проверок (Structuring for Validation),

использование внешних стандартов (Use of External Standards)

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

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

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

Визуальный стиль является наиболее универсальным стилем конструирования ПО. Он позволяет разработчикам проекта представлять в наглядном виде сложные программные конструкции. Например, графический интерфейс пользователя освобождает разработчика от подбора необходимых координат и свойств объектов интерфейса. Визуальный язык проектирования UML представляет разработчику набор удобных диаграмм для задания статической и динамической структуры ПО [31].

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

В процессе конструирования должны использоваться внешние стандарты ЯП (Ада 95, С++ и др.), языков описания данных (XML, SQL и др.), средств коммуникации (COM, CORBA и др.), интерфейсов компонентов (POSIX, IDL, APL) [33], сценариев UML [31] и др.

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

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

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

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

Тестирование в конструировании. Проводится две формы тестирования созданного кода - модульное и интеграционное. Виды тестирования описаны в специальной области знаний (см. ниже). При этом используются два стандарта (IEEE 829-1996 и IEEE 1008-1987) тестирование элементов ПО и документации. Обеспечение качества конструирования базируется не только на тестировании и отладке отдельных программ, а и на просмотрах, инспектировании, анализе и оценках результатов тестирования.

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

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

Термин конструирование программного обеспечения (software construction) описывает детальное создание рабочей программной системы посредством комбинации кодирования, верификации (проверки), модульного тестирования (unit testing), интеграционного тестирования и отладки.

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

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

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

В процессе конструирования обычно создается большая часть активов программного проекта -конфигурационных элементов (configuration items). Поэтому в реальных проектах просто невозможно рассматривать деятельность по конструированию в отрыве от области знаний "Конфигурационного управления" (Software Configuration Management).

Так как конструирование невозможно без использования соответствующего инструментария и, вероятно, данная деятельность является наиболее инструментально-насыщенной, важную роль в конструировании играет область знаний "Инструменты и методы программной инженерии" (Software Engineering Tools and Methods).

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

Из связанных дисциплин программной инженерии (Related Disciplines of Software Engineering) наиболее тесная и естественная связь данной области знаний существует с компьютерными науками (computer scince). Именно в них, обычно, рассматриваются вопросы построения и использования алгоритмов и практик кодирования. Наконец, конструирование касается и управления проектами (project management), причем, в той степени, насколько деятельность по управлению конструированием важна для достижения результатов конструирования.

Стандарты, которые напрямую применяются при конструировании, включают:

коммуникационные методы (например, стандарты форматов документов и <оформления> содержания)

языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK - Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для языка программирования Java)

платформы (например, стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows

Моделі конструювання програмного забезпечення

Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В большинстве случаев, модели конструирования определяются используемым стандартом жизненного цикла, применяемыми методологиями и практиками. Некоторые стандарты жизненного цикла, по своей природе, являются ориентированными на конструирование – например, экстремальное программирование (XP- eXtreme Programming). Некоторые рассматривают конструирование в неразрывной связи с проектированием (в части моделирования), например, RUP (Rational Unified Process).

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

Некоторые модели являются более линейными с точки зрения конструирования ПО. К ним относятся, например, водопадная (waterfall) и поэтапная (staged-delivery) модели жизненного цикла Эти модели рассматривают конструирование как деятельность, которая начинает проводиться только после завершения определенных обязательных к выполнению (prerequisite) работ, включающих детальное определение требований, подробный дизайн и детальное планирование. Более линейные подходы стараются подчеркнуть действия, предваряющие конструирование (т.е. требования и дизайн) и создать более четкое разделение между такими различными типами деятельности. В таких моделях основным содержанием конструирования может быть кодирование.

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

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

Планування конструювання

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

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

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

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

Измерения в конструировании (Construction Measurement)

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

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

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

Почему "авторизованный перевод" этой темы SWEBOK оказался столь эмоционален? Практика автора показывает, что в погоне за "красотой", разработчики слишком часто забывают о цели их работы и воспринимают деятельность по управлению проектами (не буду спорить, иногда лишь формальную, для "прикрытия" всего, что только можно ...) со стороны менеджеров и, тем более, любой аудит - как однозначную помеху "полёту мысли". Зря. Если все именно так обстоит в вашем случае - проект, с большой вероятностью, а иногда и просто, "если не случится чудо", можно считать пусть и не провальным ("фуух... не закрыли...."), то, наверняка, выйдущим за рамки тех или иных ограничений, будь то сроки, деньги, качество или, наконец, время, которое разработчик мог провести с семьей. И не сидеть ночью, дописывая функциональность или отлавливая очередную ошибку за несколько дней до передачи проекта в эксплуатацию. Все эти вопросы преследуют одну единственную цель - предсказуемость работ и результата. И измерения - важный инструмент достижения этой цели.

Область знаний "Software Engineering Process" уделяет специальное внимание вопросам измерений при создании программного обеспечения.

Проектування в конструюванні

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

Проектирование в конструировании (Construction Design)

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

Детали деятельности по проектированию на стадии конструирования в основном те же самые, что и описанные в области знаний "Проектирование программного обеспечения" (Software Design). Отличие заключается в большем внимании деталям.

Языки конструирования (Construction Languages)

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

Простейший тип языков конструирования - конфигурационный язык (configuration language), позволяющий задавать параметры выполнения программной системы.

Инструментальный язык (toolkit language) - язык конструирования из повторно-используемых элементов; обычно строится как сценарный язык (script), выполняемый в соответствующей среде.

Язык программирования (programming language) - наиболее гибкий тип языков конструирования. Содержит минимальный объем информации о конкретных областях приложения и процессе разработки, требуя больше всего (по сравнению с другими типами языков конструирования) усилий на изучение и наработку опыта для эффективного применения при решении конкретных задач.

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

лингвистическая

формальная

визуальная

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

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

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

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

Статичні методи тестування програм

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

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

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

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

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

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

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

Динамічні методи тестування програм

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

Динамическое тестирование ориентировано на проверку корректности ПС на множестве тестов, прогоняемых по ПС, в целях проверки и сбора данных на этапах ЖЦ и проведения измерения отдельных элементов тестирования для оценки характеристик качества, указанных в требованиях посредством выполнения системы на ЭВМ. Оно основывается на систематических, статистических, (вероятностных) и имитационных методах.

Дадим краткую характеристику этим методам.

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

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

Методы «черного ящика» обеспечивают:

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

анализ граничных значений;

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

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

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

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

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

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

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

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

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

Тестирование по принципу «белого ящика» ориентировано на проверку прохождения всех путей программ посредством применения путевого и имитационного тестирования

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

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

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

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

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

Функціональне тестування програм

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

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

В задачи функционального тестирования входят:

- идентификация множества функциональных требований;

идентификация внешних функций и построение последовательностей функций в соответствии с их использованием в ПС;

идентификация множества входных данных каждой функции и определение областей их изменения;

построение тестовых наборов и сценариев тестирования функций;

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

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

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

Предпосылками функционального тестирования являются:

- корректное формирование требований и ограничений к качеству ПО;

- корректное описание модели функционирования ПО в среде его эксплуатации заказчиком;

- адекватность модели ПО заданному классу.

Організація підготовки тестів

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

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

Создаются тесты, проверяющие:

полноту функций;

согласованность интерфейсов;

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

надежность выполнения системы;

защиту от сбоев аппаратуры и не выявленных ошибок и др.

Тестовые данные готовятся как для проверки отдельных программных элементов, так и для групп программ или комплексов на разных стадиях процесса разработки. На рис. 7.5 приведена классификация тестов проверки по объектам тестирования на основных стадиях разработки.

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

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

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

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

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

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

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

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

Команда тестувальників

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

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

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

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

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

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

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

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

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

Для проведения тестирования тестовые инженеры предлагают процедуры тестирования (Test Procedures), включающие валидацию объектов и верификацию тестовых сценариев в соответствии с планом графикам. Оценка тестов (Test Evaluation) заключается в оценке результатов тестирования и степени покрытия программ сценариями и статуса полученных ошибок. На рис. 7.5. приведен круг обязанностей тестового инженера.

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

Організація процесу тестування

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

- выделение объектов тестирования,

проведение классификации ошибок для рассматриваемого класса тестируемых программ,

подготовка тестов, их выполнение и поиск разного рода ошибок и дтказов в компонентах и в системе в целом;

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

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

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

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

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

Классификация ошибок. Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие

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

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

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

Отказ может быть результатом следующих причин:

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

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

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

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

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

Ошибки на этапах ЖЦ тестирования

. Приведенные типы ошибок распределяются я по этапам ЖЦ и им соответствуют такие источники их возникновения:

- непреднамеренное отклонение разработчиков от рабочих стандартов или планов реализации;

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

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

Рассмотрим этапы тестирования, определенные в соотвествии с рекомендациями стандарта КОЛЕС 12207, и приведем типы ошибок, которые обнаруживаются на каждом из них.

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

Характерными ошибками этого этапа являются:

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

некорректность спецификации взаимодействия ПО со средой функционирования или с пользователями;

несоответствие требований заказчика к отдельным и общим свойствам ПО;

некорректность описания функциональных характеристик;

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

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

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

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

определением процесса обработки информации и взаимодействия между процессами (результат некорректного определения взаимосвязей компонентов и процессов);

некорректным заданием данных и их структур при описании отдельных компонентов и ПС в целом;

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

определением условий возникновения возможных ошибок в программе;

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

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

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

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

- нарушение стандартов кодирования (плохие комментарии, нерациональное выделение модулей и компонент и др.);

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

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

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

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

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

логические и функциональные ошибки;

ошибки вычислений и времени выполнения;

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

ошибки интерфейсов;

ошибки объема данных и др.

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

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

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

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

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

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

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

На современном этапе развития средств поддержки разработки ПО (САБЕ-технологии, объектно-ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.

Связь ошибки с отказом и источники ошибок

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

идентификация изъянов в технологиях проектирования и программирования;

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

классификация отказов, изъянов и возможных ошибок, а также дефектов на каждом этапе разработки;

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

и т. д.);

проверка и защита от ошибок на всех этапах ЖЦ, а также обнаружение дефектов на каждом этапе разработки;

сопоставление дефектов и отказов в ПО для разработки системы взаимосвязей и методики локализации, сбора и анализа информации об отказах и дефектах;

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

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

Приведем следующую классификацию типов отказов:

аппаратный, при котором общесистемное ПО не работоспособно;

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

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

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

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

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

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

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

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

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

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

Модель якості програмного забезпечення

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

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

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

Модель качества ПО имеет следующие четыре уровня детализации.

Первый уровень соответствует определению характеристик (показателей) качества для ПО, каждая из них отражает отдельную точку зрения пользователя на качество. Согласно стандартов [1-4] определено шесть характеристик или шесть показателей качества в стандартной модели качества:

функциональность (functionality),
надежность (realibility),
удобство (usability),
эффективность (efficiency),
сопровождаемость (maitainnability),
переносимость (portability).

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

Третий уровень предназначен измерения качества с помощью метрик, каждая из них согласно стандарта [1] определяется как комбинация метода измерения атрибута и шкалы измерения значений атрибутов. Для оценки атрибутов качества на этапах ЖЦ (при просмотре документации, программ и результатов тестирования программ) используются метрики с заданным оценочным весом для нивелирования результатов метрического анализа совокупных атрибутов конкретного показателя и качества в целом. Атрибут качества определяется с помощью одной или нескольких методик оценки на этапах ЖЦ и на завершающем этапе разработки ПО.

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

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

Характеристики якості програмного забезпечення

\1). Функциональность - совокупность свойств, определяющих способность ПО выполнять в заданной среде перечень функций в соответствии с требованиями к обработке и общесистемным средствам.

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

функциональная полнота - свойство компонента, которое показывает степень достаточности основных функций для решения задач в соответствии с назначением ПО;

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

- интероперабельность - атрибут, который показывают на возможность взаимодействовать ПО со специальными системами и средами (ОС, сеть);

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

2). Надежность - совокупность атрибутов, которые определяют способность ПО преобразовывать исходные данные в результаты при условиях, зависящих от периода времени жизни (износ и его старение не учитывается). Снижение надежности ПО происходит из-за ошибок в требованиях, проектировании и выполнении. Отказы и ошибки в программах появляются на заданном промежутке времени [8-13].

К подхарактеристикам надежности ПО относятся:

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

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

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

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

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

К факторам, влияющим на надежность ПО, относятся:

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

угроза как проявление нарушения безопасности системы;

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

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

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

Подхарактеристиками удобства применения являются:

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

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

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

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

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

К подхарактеристикам эффективности ПО относятся:

- реактивность - атрибут, который показывает время отклика, обработки и выполнения функций;

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

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

5). Сопровождаемость

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

Сопровождаемость включает подхарактеристики:

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

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

стабильность - атрибут, указывающие на риск модификации;

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

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

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

Переносимость включает подхарактеристики:

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

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

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

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

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

Метрики оцінки якості програмного забезпечення

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

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

Метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.

Остановимся на классификации метрик ПО, правилах для проведения метрического

анализа и процесса их измерения.

Типы метрик. Существует три типа метрик:

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

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

метрики использования.

Метрики программного продукта включают:

- внешние метрики, обозначающие свойства продукта, видимые пользователю;

- внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта включают такие метрики:

надежности продукта, которые служат для определения числа дефектов;

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

сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);

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

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

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

сложности, необходимые для определения сложности продукта;

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

Внутренние метрики позволяют определить производительность продукта и они являются релевантными по отношению к внешним метрикам.

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

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

требований;

сценариев и действующих лиц;

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

параметров и операций объекта и др.

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

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

мера времени (функционирования системы, выполнения компонента и др.);

мера усилий (производительность труда, трудоемкость и др.);

меры учета (количество ошибок, число отказов, ответов системы и др.).

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

общее число объектов и число повторно используемых;

общее число операций, повторно используемых и новых операций;

число классов, наследующих специфические операции;

число классов, от которых зависит данный класс;

число пользователей класса или операций и др.

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

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

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

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

Метрики процессов включают метрики:

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

оценки стоимости работ специалистов за человека-дни либо месяцы;

ненадежности процесса - число не обнаруженных дефектов при проектировании;

- повторяемости, которые устанавливают степень использования повторных компонентов.

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

общее время разработки и отдельно время для каждой стадии;

время модификации моделей;

время выполнения работ на процессе;

число найденных ошибок при инспектировании;

стоимость проверки качества;

стоимость процесса разработки.

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

Стандартний метод оцінки значень показників якості

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

По определению стандарта 9126-2 метрика качества ПО представляет собой "модель измерения атрибута, связываемого с показателем его качества". Для пользования метриками при измерения показателей качества данный стандарт позволяет определять следующие типы мер:

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

- меры времени - периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.);

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

меры интервалов между событиями, например, время между последовательными отказами;

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

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

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

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

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

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

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

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

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

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

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

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

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

метрическая (1.1 - абсолютная, 1.2 - относительная, 1.3 - интегральная);

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

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

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

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

Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:

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

порядковая шкала служит для упорядочивания характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями;

интервальная шкала задает существенные свойства объекта (например, календарная дата);

относительная шкала задает некоторое значение относительно выбранной единицы;

абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).

Керування якістю програмного забезпечення

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

- SQA (Software Quality Assurance).

Цель процесса SQA состоит в гарантировании того, что продукты и процессы согласуются с требованиями, соответствуют планам и включает следующие виды деятельности:

внедрение стандартов и соответствующих процедур разработки ПС на этапах ЖЦ;

оценка соблюдения положений этих стандартов и процедур.

Гарантия качества состоит в следующем:

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

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

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

анализ применяемых процессов на соответствие договору и планам;

среда и методы разработки согласуются с заказом на разработку;

проверка принятых метрик продуктов, процессов и приемов их измерения в соответствии с утвержденным стандартом и процедурами измерения.

Цель процесса управления SQМ состоит в том, чтобы провести мониторинг (систематический контроль) качества для гарантии, что продукт будет удовлетворять потребителю и предполагает выполнение следующих видов деятельности:

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

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

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

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

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

проводится контроль качества (SQА, верификация и валидация) и целей, если они не достигнуты, то проводится регулирование процессов;

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

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

- гарантия (подтверждение) качества ПС, как результат определенной деятельности на каждом этапе ЖЦ с проверкой соответствия системы стандартам и процедурам, ориентированным на достижении качества;

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

Процессы достижения качества предназначены для:

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

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

в) контроль базовой версии ПС и реализованных в ней характеристик качества.

Выполнение указанных процессов включает такие действия:

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

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

контроль проведения формальных инспекций и просмотров;

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

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

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

Система качества (Quality systems - QS) [15] - это набор организационных структур, методик, мероприятий, процессов и ресурсов для осуществления управления качеством. Для обеспечения требуемого уровня качества ПО применяются два подхода. Один из них ориентирован на конечный программный продукт, а второй - на процесс создания продукта.

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

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

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

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

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

Обеспечение качества заключается в выполнении и проверки того, что объект разработки выполняет указанные требования к качеству. Цели обеспечения качества могут быть внутренние и внешние. Внутренние цели - создание уверенности у руководителя проекта, что качество обеспечивается. Внешние цели - это создание уверенности у пользователя, что требуемое качество достигнуто и результатом является качественное программное обеспечение.

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

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

Моделі оцінки надійності

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

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

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

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

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

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

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

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

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

К факторам гарантии надежности относятся:

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

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

анализ риска - изучение угрозы или риска, их частота и последствия;

целостность - способность системы сохранять устойчивость работы и не иметь риска;

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

Методи керування проектами

Согласно мировой статистики, не все реализуемые программные проекты завершаются успешно, 33% из них являются провальными по следующим причинам:

требования заказчика не выполняются ,

проект не вложился в стоимость,

проект не вложился в заданные сроки,

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

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

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

планирование проекта и составление графиков работ выполнения проекта,

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

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

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

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

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

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

этот продукт не материален, его нельзя увидеть в процессе конструирования (как это имеет место, например, при строительстве здания) и повлиять на его реализацию более оперативно;

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

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

элементной базы и языков программирования.

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

Накопленный опыт в создании технических проектов был систематизирован (в институте управления проектами в США) и разработано ядро знаний - РМВОК (Project Management Body of Knowledge [2]. В нем малыми проектами считаются проекты, содержащие 100 работ и 15 исполнителей, средними - 500 работ и 50 исполнителей и большими - 1000 работ и 100 исполнителей.

Методы управления программным проектом

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

Метод критичного шляху для керування проектом

Метод критического пути СРМ

Оснополагающим моментом создания этого метода является исследование возможности эффективного использования вычислительной машины Univac на фирме "Dupon" при планировании и создании планов-графиков больших комплексов работ по модернизации заводов этой фирмы. В результате был создан рациональный и простой метод (Уолкера - Келли) управления проектом с использованием ЭВМ, который был назван CPM (Critical Path Method ) методом критического пути.

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

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

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

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

Метод аналізу та оцінки PERT

Метод анализа и оценки PERT

Параллельно с разработкой CPM, в военно-морских силах США был создан (фирма "Буз, Аллен & Гамильтон") метод анализа и оценки программ PERT (Program Evaluation and Review Technique) для реализации проекта разработки ракетной системы "Polaris", объединяющей около 3800 подрядчиков с числом операций более 60 тыс. [6].

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

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

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

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

оптимистичной (О),

пессимистической (P),

вероятностной (B).

А далее вычисляется по формуле: (О+4В+П)/6, c указанием его на сетевом графике.

Для уменьшения провалов проектов используются и другие аналитические методы и усовершенствованные языки разработки систем. Как показывает опыт, "продвинутые" технологии решают вопросы успешного создания проекта с учетом факторов, которые уменьшают его провал [3]:

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

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

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

2). Поддержка темпа работы состоит в:

уменьшении текучести кадров;

контроле качества выполняемых работ;

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

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

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

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

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

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

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

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

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

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

работ со сроками их выполнения по методу критического пути СРМ или PERT;

достижения требуемого качества методами проверки промежуточных результатов процессов ЖЦ;

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

аттестации результатов проектирования и деятельности исполнителей проекта,

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

Составляется график работ по следующей схеме (рис.10.2):

Определение	Связь	Оценка	Распределение	Определение
этапов	между	ресурсов	персонала	графика
А	этапами	для этапа	по этапам	і

Требования График

к проекту

Рис.10.2. Шаги составления графика работ на проекте

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

На этапе планирования могут использоваться также сетевая разбивка работ (СРР) и диаграммы Ганта.

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

структуризацию работ на основные компоненты и подкомпоненты,

определить направления деятельности для достижения комплекса целей,

распределить ответственных за выполнение отдельных работ на проектеа,

получить отчетность и обобщение информации по проекту.

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

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

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

Каждая фаза описывается с помощью параметров:

начальная точка выполнения процесса,

продолжительность,

срок,

результат (конечная точка).

При построении сетевого графика работ создается граф (рис.10.4), в котором указываются:

начальная точка - событие или набор событий, которые произошли до начала выполнения данной фазы процесса, и для которой описывается набор условий начала процесса;

продолжительность - интервал времени, за которое процесс должен успешно завершить свое выполнение;

срок - дата, до которой процесс полностью или частично завершает свое выполнение; конечная точка процесса - контрольная точка, в которой заказчик проверяет качество полученных результатов процесса.

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

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

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

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

Організаційні аспекти керування в проекті

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

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

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

способностью выполнять работу;

интересом к работе;

опытом работы с подобным проектом, инструментами, языками, технологиями и ОС;

способностью к обучению;

коммуникабельностью с другими сотрудниками;

способностью разделить ответственность с другими;

профессионализмом и знанием методов управления.

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

Стиль работы. Разным людям свойственны разные стили выполнения работы и коммуникации с другими сотрудниками [3]. Отличаются сотрудники тем, что одни сначала взвешивают все детали и собирают всю информацию, а потом принимают решения по всем вопросам. Другие разбивают работу на фрагменты и принимают решение постепенно для каждого фрагмента. Некоторые сотрудники предпочитают формировать рабочее решение путем высказывания своего мнения другим сотрудниками и принимать окончательное решение сообща (стиль экстраверта), другие предпочитают и интересоваться мнением других по тому или другому вопросу, а потом самостоятельно принимать решение (интроверты). Некоторые сотрудники полагаются на свою интуиции и профессиональный опыт при принятии решения (интуитивисты), другие - руководствуются только рациональными и логическими доводами (рационалисты). В реальной рабочей среде более часто встречаются смешанные типы сотрудников.

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

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

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

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

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

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

рабочие стили членов группы;

число людей в группе;

стиль работы с заказчиками и разработчиками.

Один из популярных стилей ведения проекта впервые использовался в IBM (рис.10.5). В нем главным ответственным за проектирование системы и ведение разработки является руководитель группы программистов. Ему непосредственно подчиняются программисты, которые имеют право последнего слова при принятии решений -главные программисты. Главный программист руководит своей подгруппой программистов и непосредственно посвящен в детали проекта и разработки программы.

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

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

Альтернативная структура ведения проекта описана Вейнбергом (Weinberg) [3], так называемое обезличенное программирование, при котором все несут одинаковую ответственность за качество продукта. В проекте не концентрируются на персоналиях, критике подвергается программный продукт, а не члены группы. Такая структура подходит для маленьких групп программистов.

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

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

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

В приведенной модели, группа - это комбинация разных сотрудников, ответственная за результат своей работы. Заказчик влияет на результат или на выбор пути для достижения результата. При разработке обязанности и роли сотрудников постоянно меняются. Это удобно для проекта, в котором требуется проведение оперативных процедур и часто меняются планы. Для планов устанавливаются сроки в пределах недели или даже часов. Для организации работ большого коллектива используются карты обязанностей, схемы, отражающие сроки выполнения работ для каждой части проекта. Показателем того, насколько выполнено задание является диаграмма планируемых и реально выполненных работ. Часто эта модель обязанностей объединяется с моделью «из рук в руки» (hand-off), которая предполагает использование сценариев и образцов взаимодействия между сотрудниками, при которых результат работы одной группы передается как исходное данное для работы другой группе.

Оцінка проекту

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

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

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

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

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

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

В большинстве моделей оценка зависит от размера системы в строках кода. Модель СОСОМО Боєма собрала в себе три техники измерений по проекту. В первых моделях применялись показатели цены, учитывался персонал и свойства проекта, продукта и среды. Модель включает оценку трех стадий ведения проекта. На первой стадии строится прототип для задач повышенного риска (интерфейс пользователя, ПО, система взаимодействия, реализации и др.) и проводится оценка затрат (например, число таблиц в БД, экраны и отчетные формы др.).

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

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

Можно сформулировать основные вехи для эффективного и успешного управления программным проектом:

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

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

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

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

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

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

Методи керування ризиками

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

Управление риском включает шесть действий:

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

Первые три действия относят к этапу оценивания риска, последние три действия — к этапу контроля риска.

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

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

Источниками проектного риска являются:

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

К источникам технического риска относят:

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

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

Источники коммерческого риска включают:

создание продукта, не требующегося на рынке;
создание продукта, опережающего требования рынка (отстающего от них);
потерю финансирования.

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

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

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

Анализ риска

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

Ранжирование риска

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

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

Цель планирования — сформировать набор функций управления каждым элементом риска. Введем необходимые определения.

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

Разрешение и наблюдение риска

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

Разрешение риска состоит в плановом применении действий по уменьшению риска. Наблюдение риска гарантирует:

цикличность процесса слежения за риском;

вызов необходимых корректирующих воздействий.

Рассмотрим шаги методики «Отслеживания 10 верхних элементов риска».

Выполняется выделение и ранжирование наиболее существенных элементов риска в проекте.
Производится планирование регулярных просмотров (проверок) процесса разработки. В больших проектах (в группе больше 20 человек) просмотр должен проводиться ежемесячно, в остальных проектах — чаще.
Каждый просмотр начинается с обсуждения изменений в 10 верхних элементах риска (их количество может изменяться от 7 до 12). В обсуждении фиксируется текущий приоритет каждого из 10 верхних элементов риска, его приоритет в предыдущем просмотре, частота попадания элемента в список верхних элементов. Если элемент в списке опустился, он по-прежнему нуждается в наблюдении, но не требует управляющего воздействия. Если элемент поднялся в списке, или только появился в нем, то элемент требует повышенного внимания. Кроме того, в обзоре обсуждается прогресс в разрешении элемента риска (по сравнению с предыдущим просмотром).

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

Керування конфігурацією програмної системи

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

Элементами конфигурации являются:

- единица конфигурации - ЕК (Configuration Item ) - элемент, выделенный для целей управления и обработки на процессорах компьютера системы;

- базис конфигурации - БК (Configuration Baseline ) - набор формально рассмотренной и утвержденной основы системы из состава ЕК и документации, устанавливающей возможность дальнейшего развития системы;

- программные компоненты системы.

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

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

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

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

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

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

Согласно действующего стандарта IEEE Std.610-90 УК включает следующие основные задачи:

Идентификация конфигурации (Configuration Identification).
Контроль конфигурации (Configuration Control).
Учет статуса конфигурации (Configuration Status Accounting).
Аудит конфигурации аудит (Configuration Audit).

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

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

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

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

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

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

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

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

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

За внесением изменений проводится контроль текущей версии системы с использованием выходных кодов в репозитории, проверки исходного кода и полученной версий. Инструменты контроля имеются в фирмах Rational's ClearCase и SourceSafe of Microsoft системы Unix.

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

Проблеми організації документування

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

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

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

определить, где приблизительно находятся функции, области и границы решения проблем документирования ПС;

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

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

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

Рис. 1.1

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

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

- интервьюирование и анкетирование заказчиков и потенциальных пользователей;

совещания, посвященные анализу требований к проекту и его документам;

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

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

- создание и апробацию прототипов и версий документов.

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

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

Проблеми формування системи, функцій та характеристик програмного продукту

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

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

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

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

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

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

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

включена - функции, включенные в базовый уровень и документы ПС на данный момент времени.

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

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

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

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

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

Проблеми оцінки та керування масштабом проекту

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

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

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

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

Проблеми побудови коректної системи документів

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

В процессе установления стратегии, стандартов и руководств по документированию конкретного проекта ПС необходимо осуществить - см. рис. 1.1:

выбор модели жизненного цикла ПС и состава его документов (рис. 1.2);

определение шаблонов, содержания и степени детализации
каждого документа;

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

определение форматов и системы обозначения документов;

установление процедур реализации шаблонов документов;

распределение ресурсов для документирования: персонала; технических средств; финансов, а также на планирование документирования.

Ниже представлены основные цели, методы и принципы стандартизации работ, а также исходные шаблоны документов, обеспечивающие регламентированное создание, развитие, модернизацию и повышение качества документации на программные средства (см. главу 3). Методы и стандарты ориентированы на коллективную, групповую работу специалистов по созданию документации для сложных, многоверсионных, тиражируемых ПС, с длительным, жизненным циклом. Внимание акцентировано на методах, документах и стандартах, которые непосредственно обеспечивают эффективное, высококачественное документирование программных средств. При этом предполагается, что процессы и технология создания программ и документов опирается на совокупность современных, автоматизированных методов и инструментальных средств. В более простых случаях рекомендуемые положения, структуру и содержание документов следует адаптировать с учетом конкретных характеристик объектов, а также условий разработки и сопровождения ПС (см. п. 1.5).

Рис. 1.2

Проблеми організаційної структури колективу, який забезпечує документування

Проблемы организационной структуры коллектива, обеспечивающего документирование при создании и развитии конкретных комплексов программ и данных определяют:

- состав подразделений и должностных лиц предприятия,

обеспечивающих документирование проекта ПС, и использующих при принятии решений документы сторонних организаций;

основные функции и связи между подразделениями и отдельными должностными лицами, указанными на схеме документирования, и их подчиненность;

описание регламента работ документирующих подразделений;

перечень категорий специалистов, число штатных единиц и
их функциональные обязанности.

Стратегия разработки, совершенствования, расширения функций и сферы применения ПС требует перехода к определенному, регламентированному порядку, который позволит специалистам в этой области говорить на одном языке и сделать процессы документирования программ и баз данных экономически эффективными. Создание и сопровождение документации на ПС должны обеспечивать длительный жизненный цикл, мобильность и повторное применение программных и информационных компонентов, независимо от их первичных разработчиков. Представленный ниже порядок документирования охватывает весь жизненный цикл программных средств от формирования концепции и требований к первой версии ПС до завершения его жизненного цикла. Общая структура и комплекс шаблонов технологических и эксплуатационных документов объектов и процессов ЖЦ ПС, предназначены для использования в индустрии сложных систем управления и обработки информации. Эта структура содержит номенклатуру документов, которые должны быть использованы во время создания, применения и сопровождения программных средств, для определения, Управления и совершенствования сложных комплексов программ. Предприятие, подразделение или руководство конкретного проекта, в зависимости от стоящей перед ними задачи, могут выбрать соответствующую группу документов, процессов и процедур для реализации своей конкретной цели. Они предназначены для использования в тех случаях, когда программный продукт и его документация

является автономным объектом или встроенной и неотъемлемой частью системы. Для этого организаторы документирования и заказчики должны обеспечить специалистов, создающих ПС:

официальными отчетами и руководствами по принятой стратегии документирования конкретного проекта ПС;

стандартами и нормативными документами, определяющими все аспекты документирования программ и данных;

опубликованными в описаниях инструментальных средств, и рекомендуемыми процедурами автоматизированного документирования ПС, его процессов и документов;

вычислительными, трудовыми и временными ресурсами для реализации документирования программ и данных;

планами документирования как органической части всего жизненного цикла конкретного ПС;

контролем, управлением и консультациями для обеспечения полноценного и унифицированного документирования всех компонентов и процессов ЖЦ ПС.

Проблема узгодження та затвердження вимог замовника

Проблема согласования и утверждения требований заказчика и разработчиков на проект и документацию программного средства должны осуществляться, используя при этом принятую в соответствующем бизнесе терминологию. Выявляя требования заказчика, аналитики и менеджеры разработчика могут лучше понять задачи и осознать, какое место уготовано создаваемому ПС у заказчика. Аналитики должны отсортировать и выявить функциональные требования, цели и возможные решения в области создания и применения ПС. Конечный итог этого анализа - спецификация требований к программному средству и документам, представляющая собой соглашение между разработчиками и заказчиком о функциях, качестве, документах и ограничениях создаваемого продукта. Чтобы гарантировать, что новая система не будет автоматизировать неэффективные или устаревшие процессы, аналитики должны знать, почему существующие системы не годятся для заказчика. Иногда пользователи просят, чтобы продукт был дружественным, надежным или эффективным, однако эти термины слишком субъективны, чтобы помочь разработчикам. Поэтому аналитики должны выяснять и документировать конкретные характеристики, означающие эти пожелания.

Аналитику могут быть известны готовые программные компоненты и/или документы, которые практически полностью удовлетворят некоторые потребности заказчика. В таком случае следует скорректировать отдельные требования, чтобы разработчики могли использовать имеющиеся компоненты ПС. Если считается разумным включить в продукт готовые коммерческие компоненты, следует проявить гибкость, поскольку характеристики таких компонентов вряд ли будут точно соответствовать исходным потребностям. Для принятия правильных решений необходимы данные об эффективности и стоимости предполагаемого изменения требований.

Только заказчик можете полноценно познакомить разработчиков с концепциями и терминологией своего проекта. Они обязаны потратить время на участие в совещаниях, интервью и прочих процедурах, необходимых для выявления реальных требований проекта. На этапах разработки участникам проекта необходимо устранять все неоднозначности и неточности спецификаций требований. Зачастую в таких случаях применяют метод прототипов и итераций — когда заказчики совместно с разработчиками формулируют и уточняют требования поэтапно и постепенно. При этом аналитик задает заказчику ряд вопросов и просит выбрать различные варианты и принять решения. Это может быть согласование противоречивых запросов от разных клиентов, выбор между конфликтующими атрибутами качества и оценками точности исходной информации.

Проблеми прогнозування об’єму документації

Проблемы прогнозирования физического объема комплекса документов для конкретных проектов программного средства. Базой для таких оценок можно использовать соответствующую модель жизненного цикла ПС. Последующее изложение базируется на применении сокращенной каскадной модели жизненного цикла сложных программных средств (см. стандарт ГОСТ Р 16326), представленной на рис. 1.2, которая используется в п. 1.5 и главе 3 при структурировании групп шаблонов документов, поддерживающих выделенные этапы ЖЦ ПС. Ниже приводятся рекомендации по структуре и содержанию более шестидесяти шаблонов типовых документов, сконструированных так, что возможны их выбор и адаптация в соответствии с масштабом и характеристиками проектов ПС. Адаптация является процессом в основном исключения процедур и компонентов документов, не применимых в конкретном проекте. Добавление уникальных или специфических документов должно быть оговорено в контракте или конкретной методике. Архитектура и содержание шаблонов документов на ПС, далее не конкретизируется в деталях, как их реализовать, оформить и оценить суммарный объем комплекса документов для определенного проекта, вследствие большого числа неопределенных параметров. Эти задачи должны решаться индивидуально с использованием Руководящих документов по подготовке и оформлению конкретных эксплуатационных и технологических документов для пользователей и разработчиков определенных проектов ПС. Стороны ответственны за выбор и применение методов и инструментальных средств автоматизации разработки и оценки суммарных размеров совокупности документов, а также за выбор процедур и документов, подходящих для оценки конкретного проекта ПС или системы.

Оформление документации должно обеспечивать успешное сопровождение, внедрение и применение ПС. Нужно описывать цель и содержание технологических документов и руководств пользователей, их желаемый объем и уровень детализации. Структура шаблонов, содержание стиль формления и изложения документов при реализации конкретных проектов ПС должны учитывать характеристик ряда документов:

договоров между заинтересованными лицами проектов ПС;

описаний компонентов, процессов и продуктов комплексов программ;

руководств по разработке и применению программных средств;

планов выполнения работ и процессов разработки документов;

протоколов результатов и контроля качества процессов или продуктов;

отчетов о проделанной работе или испытаниях программных продуктов;

справочников о функциях и эксплуатации программных средств;

учебных пособий для освоения и применения программных средств пользователями.

Следует учитывать возможные ограничения, связанные с форматированием и печатью. Многие проекты комплексов программ предлагают для помощи пользователям систему интерактивных подсказок. Подобные системы имеют уникальную природу: они сочетают в себе моменты программирования (создание гиперссылок) с моментами написания технических текстов. Могут быть важны применения некоторых компонентов ПС - руководства по инсталляции, инструкции по конфигурированию. В качестве стандартного компонента иногда включается файл Read Me. Он может содержать разделы описаний продукта, что нового в очередной версии и обсуждение совместимости с более ранними версиями.

Современные коммерческие программные продукты должны иметь соответствующее внешнее оформление, которое начинается с Упаковки продукта и его объявления в инсталляционных меню, открывающихся экранах, системах подсказок, диалогах. Примерами являются отметки об авторском праве и патентовании, а также логотипы компаний, стандартизированные пиктограммы и другие графические элементы.

Формування вимог до документації

Масштаб проектов комплексов и компонентов программ явля¬ется одним из важнейших факторов, влияющим на формирование, структуры и содержание документации, поддерживающей весь жизненный цикл ПС. Оценки масштаба проекта ПС должны быть проанализированы и скорректированы для установления в договоре между заказчиками и разработчиками исходного компромиссного масштаба, допустимого для разработки первичных требований к комплексу документации. Некоторые требования могут потребовать изменения (обычно увеличения) масштаба, и соответственно ресур¬сов на этапах предварительного и детального проектирования для обеспечения возможности реализации требуемой функциональной пригодности. Таким образом, требования к функциональной пригодности, к конструктивным характеристикам ПС, к форматам и структуре документации должны быть согласованы с масшта¬бом проекта и доступными ресурсами для реализации, на ранних этапах его жизненного цикла. Для этого необходимо использовать адекватные методы и единицы измерения масштаба проектов ПС .

Формированию требований к комплексу программ должно сопутствовать создание требований, отражающих его документооборот, вследствие чего эти процессы во многом подобны. От масштаба ПС непосредственно зависят затраты ресурсов для их документирования и не всегда целесообразно создавать и использовать в реальных проектах весь комплекс шаблонов документов, отраженных в главе 3. Масштаб проекта и спецификация требований к ПС, непосредственно отражаются на составе, содержании и объеме документации, необходимой различным участникам проекта. Каждый из разработчиков в той или иной степени должен привлекаться к управлению требованиями, как к проекту, так и его документации. Разработчикам необходимо выработать профессиональные приемы для понимания и изложения в документах потребностей пользовате¬лей, управления масштабом проекта, построением системы и документации, удовлетворяющих достаточно полно эти потребности, которые включают:

- команда разработчиков ПС, получает представление о сложности и размере создаваемого продукта и составе его документации;

- менеджеры проекта, - базу для расчета содержания спецификаций, графиков, затрат и ресурсов;

- группа тестирования, - планы тестирования, варианты испытаний и процедуры проверок;

- специалисты по сопровождению и поддержке, получают представление о функциональности каждой составной части продукта;

- клиенты отдела маркетинга и специалисты по продажам, будут иметь представление о конечном программном продукте;

- составители документации, создающие шаблоны документов, руководства для пользователей и правки на основании спецификации требований к ПС получат проект пользовательского интерфейса;

- специалисты, ответственные за обучение персонала, получат спецификации требований к ПС и документацию для пользователей, а также для разработки обучающих материалов;

- персонал, занимающийся юридической стороной проекта, проверит, соответствуют ли требования к продукту существующим законам и постановлениям.

Основная цель оценки масштаба ПС - подготовить возможность принять обоснованное решение о допустимости дальнейшего продвижения проекта в область системного анализа, разработки требований, предварительного проектирования и документирования. Если оказывается, что рассчитанные первично масштаб и требуемые ресурсы не могут быть обеспечены для продолжения проекта, то возможны кардинальные решения: либо изменение некоторых выделяемых ресурсов, либо прекращение проектирования данного ПС(рис. 1.3).

Для продолжения разработки набора документов после оценки масштаба комплекса программ, необходимо выполнить цикл по¬этапного определения и формирования совокупности спецификаций требований к компонентам и документации проекта ПС.

После первичной оценки масштаба проекта ПС итерационно выполняется поэтапная разработка спецификаций требований проекта и документов ПС. Ограничения при прогнозировании требований к документам, определяются, прежде всего, имеющимися данными, которые могут быть использованы в качестве исходных ана¬логов или обобщенных характеристик.

Составлять спецификацию требований к документации ПС следует таким образом, чтобы все заинтересованные в проекте лица смогли в ней разобраться.

Разработку и утверждение спецификаций требований к функциональным характеристикам, к качеству, составу и номенклатуре документов ПС, целесообразно проводить итерационно на этапах предварительного и детального проектирования. Полная и однократная формализация требований к характеристикам и комплекту документов в начале жизненного цикла сложного ПС обычно невозможна, прежде всего, из-за разных представлений заказчика и разработчиков о деталях его назначения, функций и возможностей реализации при доступных ресурсах. Чем крупнее и сложней проект ПС и соответственно выше его стоимость, тем тщательнее следует разрабатывать требования к его характеристикам, к составу и содержанию документов, а также распределять ресурсы на их реализацию. Поэтому при средней и относительно невысокой сложности ПС во многих случаях можно удовлетвориться подготовкой требований к комплексу программ с подробностью анализа, соответствующего предварительному проектированию. Для крупномасштабных и особо сложных проектов необходим более детальный анализ факторов при разработке набора документов и требова¬ний их оптимизации по критерию качество/затраты в детальном проекте.

Для разработчиков особенно важно формализовать требования к качеству и согласовать их с заказчиком при утверждении контракта и технического задания на проект ПС. Требования к функциональным характеристикам, качеству, составу и содержанию документов, утвержденные после предварительного проектирования, могут быть закреплены в техническом задании как обязательные для детального и рабочего проектирования. Эти данные могут использоваться при последующем оценивании качества документации при их сопоставлении с требованиями в процессе квалификационных испытаний или сертификации ПС. Однако для крупномасштабных и дорогих проектов может потребоваться уточнение требований к качеству документации при детальном проектировании с позиции улучшения соотношения значений качества и затрат ресурсов, кото¬рые необходимы или допустимы для их реализации в ЖЦ ПС.

Для заказчика и пользователей может иметь значение не только определение функциональной пригодности, но и оценка потенциального спроса на рынке конкретного программного продукта, а также его конкурентоспособности с другими аналогичными по функциям ПС с учетом его качества и стоимости. Это обстоятельст¬во может определять необходимость уточнения требований к отдельным характеристикам и документам не только для их реализации разработчиками в ЖЦ ПС, но также для оценивания интеграль¬ного качества готового программного продукта поставляемого на рынок.

Для эффективного управления документацией сложного ПС при детальном проектировании целесообразно учитывать и обобщать степень полезности разнородных характеристик и документов в некоторый интегральный показатель, отражающий их совокупное влияние на его функциональную пригодность. Таким образом, при разработке требований к характеристикам документов проекта выявилась проблема анализа системной эффективности документации и обобщения их характеристик, а также оценивания совместного влияния различных документов на функциональную пригодность ПС с учетом затрат на их реализацию.

Для управления и сопоставительного оценивания выбранных Характеристик качества документов целесообразно каждому из них присваивать коэффициент или приоритет влияния на функциональную пригодность. Точность определения коэффициентов вряд ли может превышать 10%, поэтому количество градаций шкалы оценок целесообразно не больше десяти. Аналогично, по такой же трудно. Такие оценки могут проводиться на основе специальных маркетинговых исследований и опыта эксплуатации аналогичных комплексов программ или достаточно близких их прототипов. Это подтверждает целесообразность выделения для автономного анализа интегральных характеристик программного продукта и документов и их влияния на функциональную пригодность.

Работа по подготовке и определению документирования может быть затруднена, если новый проект не имеет аналогов, то есть отсутствуют предварительные наработки в данном предприятии. Для уникального, не имеющего аналогов проекта должны быть предприняты специальные мероприятия, обеспечивающие документирова¬ние и соответствующий надзор за реализацией документов. Данные мероприятия должны сопровождаться соответствующими анализами и оценками, и экспертными заключениями. Должны быть предусмотрены специальные мероприятия для управления изменениями в области управления документацией в жизненном цикле программ¬ного проекта. Все изменения, вносимые в документы и требования, должны быть тщательно оценены по их влиянию на стоимость, гра¬фики работ, риски и эффективность характеристик проекта.

Планування документування проектів

Общее руководство процессом документирования комплексов программ можно разделить на два уровня:

- адаптация состава и содержания документов к данной дело¬вой, проблемно-ориентированной области, например, авиационной, медицинской, военной, финансовой или административной;

- адаптация номенклатуры, структуры и содержания документов для каждого специфического проекта, контракта или предприятия.

В соответствии со стандартами план документирования в виде совокупности руководящих, промежуточных и отчетных документов должен разрабатываться системными аналитиками и утверждаться менеджером проекта вместе со спецификацией требований к ПС.

В спецификации формализуются требования к ре¬зультатам документирования, а в плане - методы и средства их дос-т. Тем самым характеристики ПС не только декларируются в виде требований, но и сопровождаются совокупностью рекомендуе¬мы мероприятий и документов по их обеспечению и реализации. Первичные требования к документированию при проектировании детализируются по компонентам ПС и по этапам их создания. При этом важно обеспечить баланс жесткости требований к качеству различных компонентов и документов с тем, чтобы в ПС не было доминирующих компонентов, заметно снижающих значения важ¬нейших показателей качества, или напрасных затрат ресурсов на высокое качество документов, слабо влияющих на функциональную пригодность ПС и общее качество документации проекта в целом.

При первичной оценке ресурсов, необходимых для документирования сложных проектов ПС наибольшее значение имеют три ключевых фактора:

- размер - масштаб, подлежащих разработке полностью новых программных компонентов и документов;

- размер и относительная доля готовых программных компонентов и документов, которые могут быть заимствованы из предшествовавших проектов и повторно использованы в новом проекте ПС;

- относительные затраты ресурсов на создание проекта с оцененным масштабом: труда специалистов, времени, бюджета на единицу размера (на строку текста программ) или полные затраты на разработку всего ПС и комплекса документов.

Эти факторы могут быть оценены квалифицированными экспертами на основе имеющегося у них опыта реализации предшествовавших подобных проектов, а также использования опубликованных данных

Оценивая масштаб, функции и требования к документации, за¬казчик и разработчики должны хотя бы приближенно представлять тот объем затрат и физический размер комплекса документации, ко¬торый придется создать в процессе всего жизненного цикла ПС, а также для обеспечения его эффективного применения. Известно, что на документирование крупномасштабных ПС требуется до 20 - 30% общей трудоемкости создания таких проектов, а для относительно малых проектов около 10% трудоемкости. Представляет интерес оценка ориентировочного физического объема документации (например, в стандартных страницах А4 или эквивалентных объемов файлов) для проектов комплексов программ.

Большая часть этих документов может оставаться в файлах (сотни мегабайт), однако каждый документ должен быть оформлен в соответствии со стандартами и шаблонами, и скреплен подписями разработчиков и, где нужно, заказчика. Изме¬ение этих документов должно санкционироваться, также как твердых копий. Для относительно малого ПС (50 тысяч строк) с минимальной технологической документацией может потребоваться около 5 тысяч страниц.

Приведенные оценки следует рассматривать только как ориентиры, которые в реальных проектах могут изменяться на порядок в ту или иную сторону, в зависимости от требований заказчика и характеристик проекта. Оценки объема предстоящей разработки технологической и эксплуатационной документации целесообразно проводить на этапе детального проектирования с учетом реальных характеристик ПС, что позволит избежать неприятных сюрпризов вызванных превышением затрат на реализацию документов проекта.

Менеджер проекта для оценок документации должен подгото¬вить план выполнения документирования в жизненном цикле ПС. тот план должен содержать описания соответствующих работ и задач и обозначения создаваемых программных продуктов и доку¬ментов. Он должен охватывать (но не ограничиваться) следующие задачи:

- установление графиков и сроков своевременного решения документирования;

- оценку необходимых трудозатрат на создание каждого документа и всего комплекса; определение времени, необходимого для выполнения кон¬кретных задач документирования;

- распределение задач документирования по исполнителям;

- определение обязанностей исполнителей по созданию содержания документов;

- выделение критических ситуаций, связанных с задачами или самим процессом документирования;

- установление критериев управления и обеспечение качества документов;

- обеспечение внешних условий и определение инфраструкту¬ры проекта системы для выполнения процесса документирования.

План документирования может быть частью общего плана жизненного цикла ПС или отдельным документом и должен быть доведен до всех участников проекта, в той части, которая их касает¬ся. План и поддерживающее его Руководство по документирова¬нию конкретного проекта ПС должны отражать:

- общую структуру комплекта документов;

- номенклатуру и содержание (или ссылки на шаблоны) каждого документа;

- требования к качеству, оформлению и обозначению документов;

- регламент комплектования и хранения документов;

- правила обращения, изменения и сопровождения докумен¬тов;

- графики подготовки, проверки, редактирования, согласова¬ния, утверждения и распространения документов.

Менеджер программного проекта должен отвечать за проведе¬ние оценок программных продуктов, документов и планов: на соответствие принципам, методологии и технологии управления проек¬том и документированием; в части удовлетворения их установлен¬ным требованиям договора с заказчиком. Необходимыми компонен¬тами успешной реализации программных проектов являются перио¬дические анализы и оценки хода выполнения и завершения этапов и заданий на документирование.

В каждой организации должна быть создана официальная сис¬тема для сбора, анализа, обобщения, архивирования и поиска архив¬ных данных и документов по проектам. Результатом сотрудничества заказчика и разработчика считается соглашение по требованиям к продукту и к документам.

Документ наилучшим образом представляет наше понимание требований к этому проекту и

Керування спеціалістами при документуванні

Важнейшим фактором при оценивании затрат на документирование в ЖЦ ПС являются люди - специалисты, с их уровнем профессиональной квалификации, а также с многообразием знаний, опыта, стимулов и потребностей. Специалисты в соответствии со своей квалификацией и ролью в проекте вносят в него специфические дефекты и ошибки достаточно определенных категорий, что целесообразно учитывать при прогнозировании документов проекта.

Разработка и документирование сложных ПС, особенно, на начальных и завершающих этапах, характеризуется высокой долей творческого труда. Дефекты, трудоемкость и длительность отдельных операций и частных работ существенно зависят от индивидуальных особенностей их исполнителей и характеристик конкретного проекта. Отсюда принципиальной особенностью планирования документирования комплексов программ является необходимость активного участия руководителей и заказчиков проектов в составлении планов на базе исследованных характеристик прототипов завершенных разработок ПС и их личного опыта.

Недостатки или отсутствие достоверного обоснования необходимых ресурсов для документирования проектов новых ПС, являются причинами острых конфликтов между заказчиками и разработчиками. Поэтому целесообразно активно привлекать заказчиков к управлению документированием проектов, чтобы обеспечить своевременность разработки ПС в условиях ограниченных ресурсов. Необходимы согласия заказчиков при принятии основных решений, и только они могут реально определить, как получить комплекс программ с необходимой документацией высокого качества, выполненный в срок и в пределах бюджета.

При разработке комплексов программ большими коллективами велика роль квалификации руководителей разработки, что непосредственно отражается на интегральных дефектах и документах проекта ПС. Руководство крупномасштабным проектом ПС должны осуществлять один или два лидера - менеджера с различными функциями - рис. 1.4:

Рис. 1.4

менеджер проекта - этот специалист, обеспечивающий коммуникацию между заказчиком и проектной командой, его задача определять и обеспечивать удовлетворение требований заказчика с учетом согласованных с ним доступных ресурсов, и по возможности сокращать ошибки оценивания реальной сложности ПС и документов;
менеджер-архитектор комплекса программ и документации - управляет коммуникациями и взаимоотношениями в проектном коллективе, является координатором создания компонентов, разрабатывает базовые, функциональные спецификации и управляет ими, ведет график проекта и отчитывается за его состояние, инициирует принятие критичных для хода проекта решений, которые могут содержать соответствующие типы ошибок документов планирования и системного проектирования ПС.

Уровень квалификации заказчика и корректность технического задания на разработку ПС может весьма сильно влиять на выделяемые ресурсы при создании комплекса программ. При проектировании и создании высококачественных комплексов программ, прежде всего, необходима организация и тесное взаимодействие представителей заказчика и менеджеров разработчиков проекта. Взгляды и требования заказчика, в основном, отражаются в функциональных и потребительских характеристиках и документах ПС. Устремления разработчиков направлены на возможность и способы их реализации с требуемым качеством. Эти различия исходных точек зрения на проект приводят к тому, что некоторые неформализованные представления тех и других имеют зоны неоднозначности и взаимного непонимания, отражающиеся на документах, что может приводить к конфликтам.

Разработчики должны иметь в своем составе квалифицированных, проблемно-ориентированных аналитиков и системных архитекторов, способных переводить функциональные требования заказчика в конкретные документы, спецификации и технических требования к комплексу программ и его компонентам.

Таблица 1.1

Специалисты - источники дефектов и ошибок	Типы первичных дефектов и ошибок программного средства и документации
Заказчики проекта	Дефекты организации проекта и исходных требований заказчика
Менеджер проекта	Дефекты организации проекта и исходных требований заказчика
Менеджер-архитектор комплекса программ	Ошибки планирования и системного проектирования программного средства
Проблемно-ориентированные аналитики и системные архитекторы	Системные и аналитические дефекты и ошибки проекта
Спецификаторы компонентов проекта	Алгоритмические ошибки компонентов и документов программного средства
Разработчики программных компонентов - программисты	Программные дефекты и ошибки компонентов и документов программного средства
Системные интеграторы	Системные ошибки и дефекты реализации версий программного средства и документации
Тестировщики	Программные и алгоритмические ошибки программного средства и документации
Управляющие сопровождением и конфигурацией, инструкторы интерфейсов	Ошибки проектирования и реализации версий программного средства и документации
Документаторы	Дефекты и ошибки обобщающих документов

Затраты труда при реализации и документировании крупномасштабного проекта ПС полезно распределить по двум категориям специалистов: разрабатывающим компоненты и ПС в целом и обеспечивающим технологию и качество программного продукта и документов. Организационное разделение специалистов, осуществляющих разработку ПС (первая категория), и специалистов, контролирующих и управляющих его качеством и документами в процессе разработки и всего ЖЦ (вторая категория), должно обеспечивать эффективное достижение заданных характеристик, а также независимый, достоверный контроль затрат ресурсов при разработке ПС.

Специалисты первой категории непосредственно создают компоненты и ПС в целом с заданными показателями качества и документами. В процессе разработки их функции заключаются в тщательном соблюдении принятой в предприятии технологии и в формировании всех предписанных руководствами исходных, промежуточных и отчетных документов. При этом предполагается, что выбранная технология способна обеспечить необходимые значения конструктивных показателей качества продукта, а достижение заданных функциональных характеристик гарантируется тематической квалификацией соответствующих специалистов, регулярным контролем и сокращением возможных дефектов и ошибок в процессе разработки. Система стандартизированного документирования частных работ должна обеспечить объективное отражение качества компонентов и процессов их создания на всех этапах ЖЦ ПС [5, 15, 20].

Разделение труда специалистов этой категории в крупных проектных коллективах приводит к необходимости их дифференциации по квалификации и областям деятельности, каждая из которых характеризуется определенными типами документов и возможных дефектов (см. рис. 1.4):

спецификаторы подготавливают описания функций соответствующих компонентов с уровнем детализации, достаточным для корректной разработки текстов программ программистами и их интерфейсов, которые могут содержать преимущественно алгоритмические ошибки;

разработчики программных компонентов - программисты создают компоненты, удовлетворяющие спецификациям, реализуют возможности продукта, отслеживают и исправляют про дефекты и ошибки, при разработке сложных систем это требует детального знания методов, технологии и языков программирования а также проектирования баз данных;

системные интеграторы сложных проблемно-ориентированных ПС работают над проектами, в значительной степени, от личными от программистов методами, на разных языках проектирования, используют различные средства автоматизации и имеют на выходе различные документы крупных компонентов и комплексов программ, с соответствующими системными ошибок документов проектирования;

тестировщши обеспечивают проверку функциональных спецификации, систем обеспечения производительности, пользовательских интерфейсов, разрабатывают стратегию, выполняют и документируют тестирование для каждого компонента проекта ПС, должны быть административно независимыми от программистов и спецификаторов, характеризуются соответствующими уровнями оставшихся не выявленными программных, алгоритмических и системных ошибок документов;

управляющие сопровождением и конфигурацией, инструкторы интерфейсов отвечают за снижение затрат на модификацию и сопровождение продукта, обеспечение максимальной эффективности разработчиков по взаимодействию компонентов и реализации версий ПС, принимают участие в обсуждениях пользовательского интерфейса и архитектуры продукта, что также не может быть без ошибок проектирования, планирования и документирования проекта;

документаторы процессов и объектов ЖЦ ПС обеспечивают подготовку и издание сводных обобщающих технологических и эксплуатационных документов в соответствие с требованиями стандартов и возможными дефектами документов.

Анализ и мониторинг характеристик, последствий и частости выявленных дефектов в документах конкретного комплекса программ может служить ориентиром для оценки индивидуальной квалификации и качества работы определенных специалистов.

Следствием такого анализа может быть выделение некоторых специалистов, отличающихся большим числом дефектов, для их замены и дополнительного обучения с целью сокращения числа ошибок соответствующего типа. Накопление, классификация и обобщение характеристик дефектов определенных классов документов позволяет прогнозировать изменение ошибок по этапам развития жизненного цикла ПС, а также необходимое распределения состава и квалификации специалистов.

При выборе заказчиком надежного поставщика-разработчика проекта необходима оценка тематической и технологической квалификации возможного коллектива специалистов, а также его способности реализовать проект с заданными требованиями и качеством документации. Тематическую квалификацию специалистов в области создания ПС определенного функционального назначения приближенно можно характеризовать средней продолжительностью работы в данной проблемной области основной части команды, непосредственно участвующей в разработке алгоритмов, спецификаций, программ, баз данных и документов. Важнейшую роль играет комплексная квалификация руководителей - менеджеров разработки и системных аналитиков функциональных компонентов, и в меньшей степени непосредственных разработчиков программ в конкретной прикладной области. Особенно важна не индивидуальная характеристика каждого специалиста, а, прежде всего, интегральный показатель квалификации «команды», реализующей некоторую, достаточно крупную функциональную задачу или весь проект. При низкой тематической квалификации допускаются наиболее грубые системные ошибки, требующие больших затрат при доработке программ или даже делающие проект практически не реализуемым [18, 19,25].

Специалисты второй категории - технологи, обслуживающие и сопровождающие технологический инструментарий документирования, который применяется специалистами первой категории, обеспечивают применение системы качества проекта или предприятия, контролируют и инспектируют ее использование. Основные задачи второй категории специалистов должны быть сосредоточены на контроле процессов, затратах ресурсов, результатах выполнения работ, а также на принятии организационных и технологических контрмер для достижения их необходимого качества, обеспечивающего выполнение всех требований технического задания на ПС и документацию.

Технологи должны выбирать, приобретать и осваивать наиболее эффективный инструментарий для проектов, реализуемых конкретной фирмой с учетом особенностей создаваемых ПС требуемого качества и рентабельности технологических средств. Они должны разматывать регламентированный технологический процесс и систему качества, поддерживающие весь ЖЦ ПС и обучать разработчиков ПС квалифицированному применению соответствующих инструментальных средств, документации и технологий.

Специалисты, непосредственно управляющие обеспечением качества ПС и документов, должны овладеть стандартами и методиками предприятия, поддерживающими регистрацию, контроль, документирование и воздействия на выявление дефектов на всех этапах ЖЦ комплекса программ. Они должны обеспечивать эксплуатацию системы качества проекта, выявление всех отклонений от заданных показателей качества объектов, процессов и документов, а также от предписанной технологии на промежуточных и заключительных этапах разработки.

Для сокращения и устранения дефектов документов проекта посредством адекватных контрмер необходима четкая организация коллектива специалистов и автоматизация процессов исправления дефектов, которые позволяют избегать множества вторичных ошибок, обусловленных недостаточной координацией проводимых корректировок и формирования новых версий сложных ПС и документов. Этому должна способствовать утвержденная дисциплина и иерархия принятия решений на координированные изменения компонентов и ПС в целом, должностными лицами проекта, поддержанная методами и средствами защиты от несанкционированного доступа при выполнении корректировок документов специалистами различной квалификации и права доступа к модификациям компонентов на разных уровнях проекта.

Следует установить полномочия специалистов или групп для санкционирования и выполнения изменений документов - контрмер на каждом уровне разработчиков ПС .

На основе проведенного анализа персонал разработки должен разрабатывать варианты реализации изменений и документально оформлять: сообщение о каждом дефекте или заявку на внесение изменений; результаты их анализа и варианты реализации изменений, оценку их влияния на функциональную пригодность. Следует согласовывать с заказчиком выбранные варианты изменений документов в соответствии с договором. Регистрация и учет истории этого процесса обеспечивает возможность его контроля и пошагового восстановления выполненных изменений (отката) документов для выявления вторичных дефектов, внесенных в процессе разработки очередной версии. Такие дефекты обычно обусловлены одновременным, не скоординированным внесением групп изменений документов несколькими специалистами или потерей некоторых корректировок в определенной версии ПС.

Если предполагается, что программный продукт будет иметь длительный, жизненный цикл поддержки или ожидаются значительные корректировки в ЖЦ ПС, то следует рассмотреть и учесть наиболее детальные требования к методике организации и к коллективу ответственному за совершенствование и документирование программ. В стратегии сопровождения документов следует учесть характеристики системы: количество компонентов программного средства, типы, размер, критичность и безопасность создаваемых и применяемых программных продуктов и документов.

В процессах совершенствования сложных ПС и документации участвует большое число специалистов различных направлений и квалификации, которые при необходимости могут объединяться в единый коллектив - службу сопровождения, управления конфигурацией программного продукта и документов. Менеджер проекта является высшим должностным лицом, принимающим важнейшие решения по внесению изменений и корректировке конфигурации сложных ПС и документов. Он взаимодействуют с заказчиком и пользователями, определяющими разработку или эксплуатацию ПС, для согласования изменений в системе, в контракте и в техническом задании. Заказчик системы должен оценивать и утверждать наиболее крупные изменения, заметно влияющие на условия контракта, технические требования или стоимость проекта ПС.

В процессе эксплуатации версий ПС у каждого пользователя могут появляться некоторые претензии к функционированию, которые квалифицируются им как ошибки или дефекты эталонной или собственной версии. Для общения с пользователями и накопления информации о выявляемых недостатках в широко тиражируемых сложных ПС целесообразно выделение группы специалистов высокой квалификации, овладевших всеми функциональными возможностями данного ПС. От пользователей или заказчика могут поступать также предложения по внесению изменений в версию для улучшения эксплуатационных характеристик и расширения функциональных возможностей ПС.

Документообіг в життєвому циклі

Для реализации на практике приведенных выше концепций, требований и планов документирования в проектах программных средств необходимы организационные мероприятия, гарантирующие участникам проектов определенную культуру, дисциплину разработки и применения документов. Такая организационная система должна обеспечивать специалистам разной квалификации и роли в проекте, возможность взаимодействия при решении требуемых комплексных задач, для накопления, хранения и обмена упорядоченной информацией о состоянии и изменениях компонентов проекта. Формализованная в документах такая информация должна повысить ответственность специалистов за корректность её содержания, оперативность формирования и изменения, качество процессов трансформации и реализации в жизненном цикле ПС.

Для этого в каждом крупном проекте комплекса программ должен быть организован регламентированный процесс документооборота, обеспечивающий для коллектива специалистов единую среду разработки, изменения и утверждения документов, адекватных реальному содержанию объектного кода программ и текстовых данных файлов проекта ПС.

Технической основой документооборота являются системы управления базами данных (СУБД), адекватные целям и функциям проектов, структурированные по целям, назначению и содержанию данных в выделенных подсистемах документооборота (рис. 1.6) Они должны обеспечивать возможность управления организационной и проектной деятельностью коллективов специалистов подсистем документооборота, универсальное хранилище в них необходимых данных, с инструментами наполнения, корректировки, поиска и контроля информации, соответствующей их профессиональной деятельности.

Рис 1.6

Должны быть упорядочены деловые коммуникации между специалистами разных категорий, управление динамическими процессами изменений и транспортировки документов между подсистемами документооборота для приближения их в соответствии с целями, к месту использования специалистами.

Первоначально должен быть разработан проект архитектуры системы документооборота и руководство по её применению, настроена выбранная СУБД на управление шестью взаимодействующими подсистемами документооборота, с соответствующими комплектами шаблонов документов, с учетом класса и масштаба предполагаемого проекта ПС. По мере развития жизненного цикла проекта комплекса программ, шаблоны подсистем документооборота должны поэтапно заполняться реальными данными от заказчика и разработчиков соответствующих квалификаций, и контролироваться менеджерами проекта. При этом следует управлять динамикой процессов реализации процедур документооборота, регистрировать реальное использование ресурсов специалистов, текущее время выполнения процедур процессов проекта и оформления документов в подсистемах документооборота.

В процессе реализации проекта производится наполнение отобранных шаблонов документов реальными требованиями и характеристиками результатов разработки, и архивация компонентов и отчетов выполненного проекта. При этом фиксируются корректировки и исправления дефектов и ошибок, и оформляются комплекты документов базовых версий программных продуктов поставляемых заказчику. Эти процедуры целесообразно выделять в отдельную подсистему документооборота - сопровождения, конфигурационного управления версиями и корректировками программного продукта, для чего, формировать группу специалистов, которые могут быть организационно автономными от остальных подсистем документирования и даже размещаться на другом предприятии.

Стандарти, що регламентують документування програмних проектів

Общие требования к составу и содержанию документов, поддерживающих создание ПС, представлены в ряде стандартов разного ранга, в фирменных описаниях технологий и в публикациях по управлению проектами. Состав и формы документов широко варьируется в зависимости от класса и характеристик объекта разработки, а также в зависимости от используемой технологии. Наиболее сложному случаю разработки критических ПС высокого качества, соответствует представленная широкая номенклатура документов. Такой перечень документов может быть использован как базовый для формирования из него состава документов в остальных более простых случаях.

Стандарт ISO 9294 представляет руководство по документированию ПС для менеджеров, отвечающих за создание программных продуктов. Руководство предназначено для помощи в управлении разработкой и эффективном документировании программных проектов. Стандарт содержит рекомендуемые стратегии, процедуры, ресурсы и планы, которыми должны заниматься руководители проектов в целях эффективного создания комплектов документов ПС. Общая структура стандарта представлена на рисунке 1.

Рисунок 1

Руководители проектов ПС должны осуществлять организацию работ по документированию и поддержку этих работ в планах, которыми они определяются. Для этого требуется руководство и стимулирование персонала при проведении требуемого документирования и обеспечение его ресурсами в этих работах. Специалистам необходимо обеспечить: опубликованные официальные отчеты о стратегии документирования; стандарты и руководства определяющие все аспекты процессов документирования; выделение соответствующих ресурсов на документирование; планирование документирования, осуществляемое как неотъемлемая часть процесса разработки программного средства.

Во время разработки ПС администрации необходимо оценивать ход работы, возникающие проблемы и развитие процесса документирования. Периодические стандартизированные отчеты, согласно которым проверяется ход работ по графику и представляются планы на следующий период, должны обеспечивать контроль и обзор развития проекта. Этим специалистам необходимы средства общения с друг с другом, обеспечивающие информацию, которую можно, при необходимости, воспроизводить, распространять и на которые можно ссылаться. Большинство методологий разработки ПС устанавливают официальные документы для связи между задачами о специалистами. для обеспечения качества ПС требуется документация процессов разработки и документация продукции. Сопровождающим специалистам и программистам требуется детальное описание ПС, такое, чтобы они могли локализовать и корректировать дефекты, модернизировать и изменять программы.

Стратегии документирования, подготовленные и отслеживаемые администрацией проекта, должны обеспечивать документы я ответственных лиц, принимающих решения на всех нижних уровнях. Из-за существенной роли, которую играет документация на всех этапах жизненного цикла ПС, должна быть подготовлена официально утвержденная стратегия. Каждый специалист, затронутый стратегией, должен быть информирован о ней и должен ее понимать. Официальная, описанная, разрекламированная стратегия устанавливает дисциплину, требуемую для эффективного документирования ПС.

Стратегия должна поддерживать основные элементы эффективного документирования, требования документации должны охватывать весь жизненный цикл ПС. Руководители и специалисты по изданиям должны ГОТОВИТЬ шаблоны документов, подробные планы, охватывающие документирование продукции, графики, обязанности, ресурсы, обеспечение качества и процедуры проверок. Читателями документов могут быть руководители, аналитики, специалисты по экспертным системам, сопровождающие программисты, канцелярский персонал. В зависимости от выполняемых задач им требуются различные степени детализации и различное представление материала. Специалисты по изданиям должны быть готовы соответствующим образом спроектировать различные типы шаблонов документации, предназначенные для различных читателей.

Внутри предприятия должны быть приняты стандарты а руководства для:

- модели жизненного цикла ПС;

- типов и взаимосвязей документов;

- содержания и шаблонов документов;

- качества документов;

- форматов и обозначения шаблонов документов.

Такие стандарты и руководства должны определять, как следует выполнять задачи документирования, обеспечивать критерии для оценки полноты, полезности и соответствия документации программному продукту. По возможности, должны быть использованы действующие международные и национальные стандарты. Зачастую могут требоваться управленческие решения для адаптации общих рекомендаций этих стандартов к конкретным проектам. Контракт с заказчиком должен требовать, чтобы документация удовлетворяла принятым стандартам. Он должен определять типы поставляемых документов, уровень качества каждого и процедуры их проверки и утверждения.

Руководители должны, выбрать соответствующую модель ЖЦ ПС и гарантировать, чтобы ее применяли в данном предприятии. Создание документации, связанной с конкретным этапом, может быть использовано как контрольный пункт для проверки, приемки и завершения этапа работ. Программные документы в данном стандарте предлагается представить разделенными на три категории:

- документация разработки;

- документация продукции;

- документация управления проектом.

Документация разработки (технологическая) описывает процесс разработки определяет требования, которым должно удовлетворить ПС, определяет проект, как его контролируют и обеспечивают качество. Документация разработки включает подробное техническое описание ПС (программную логику, взаимосвязи, форматы хранение данных). Она является средством связи между всеми лицами, вовлеченными в процесс разработки, описывает подробности решений принятых относительно требований к ПС, проекту, программированию и тестированию, а также обязанности группы разработки — кто, что и когда делает, учитывая роль объекта работ, документации, персонала, обеспечивающего качество, и каждого специалиста в процессе разработки. Документация образует основу сопровождения — описывает историю разработки ПС. Если документы разработки отсутствуют, неполны или устарели, руководители теряют важное средство для отслеживания и контроля проекта.

Документация продукции (эксплуатационная) обеспечивает формацию, необходимую для эксплуатации, сопровождения модернизации, преобразования и передачи программной продукции к пользователю. Она обеспечивает учебную и справочную информацию для специалистов использующих или эксплуатирующих программную продукцию; облегчает программистам не разрабатывающим ПС, его сопровождение и модернизацию; помогает продаже приемке программной продукции. Документация продукции, должна включать материалы: для пользователей, которые вводят данные, восстанавливают информацию и решают задачи с помощью ПС для операторов, которые применяют и ПС на вычислительной системе; для сопровождающих программистов, а также материалы для руководителей которые следят за использованием комплекса программ. Типовые документы продукции включают: учебные руководства; справочные руководства и руководства пользователей; руководства по сопровождению ПС; брошюры и информационные листовки, посвященные рекламе продукции.

Документация управления проектом включает графики для каждой стадии процесса разработки и отчеты об изменениях графиков; отчеты о согласованных изменениях программ; отчеты о решениях, связанных с разработкой; распределение обязанностей специалистов. Руководители должны применять стандарты, распространяющиеся на обеспечение качества, соответственно различными типами документов и различным типам проектов, и должны определять, как это качество будет достигнуто и поддержано. Понятия качества документации включает: качество содержания; структуру информации; представление проекта с иллюстрациями.

Стандартизированные форматы — шаблоны документов важны для контроля качества документов, для читаемости документов и для облегчения их сопровождения. Форматы документов могут различаться от проекта к проекту. Они зависят от таких факторов, как объем проекта, аудитория, для которой предназначены документы, количество установленных стадий и бюджет документирования. В проектируемых форматах должно быть учтено будут ли документы переводиться для международного распространения.

Стандартные обозначения документов необходимы для эффективного контроля документации. Обозначающая информация может включать в себя: заглавие документа; номер версии документа; дату выпуска и пересмотра; реквизиты автора; реквизиты утвердившего лица; обозначение защищенности (авторских прав); обозначение предприятия. должны быть установлены процедуры для применяемых стратегий:

- последовательность документирования;

- планирование;

- конфигурационное управление;

- проверки;

- утверждение;

- производство;

- хранение;

- дублирование;

- распространение и модернизация;

- продажа.

Процедуры также должны определять контрольные пункты и методы обеспечения качества.

Основными ресурсами в стандарте, для документирования выделяются: персонал; инструментальные средства; финансирование. для процесса разработки необходимы люди со знанием: программирования; сути предмета применения ПС; документирования продукции. Важно, чтобы штат был полностью обучен методам документирования, и чтобы каждая группа специалистов полностью понимала и выполняла свою роль в процессе документирования. Проектировщики ПС и программисты создают документацию разработки; специалисты в предметной области обеспечивают информацию для стадий изучения спецификаций требований, планов тестирования и обеспечения качества, планов сборки программ. Специалисты по изданию обычно подготовляют документацию по обучению пользователей, а также справочную и информационную о продукции.

Важно предусмотреть обеспечение задач документирования соответствующими техническими средствами. Они могут быть применены для повышения эффективности многих процессов документирования и использования стандартов данного предприятия распространяющихся на документирование. Полезно, чтобы стоимость документирования определяли как отдельные статьи бюджета, так как она нередко составляет значительную часть стоимости разработки ПС.

План документирования определяет, что должно быть сделан, как, когда и кто это должен делать. Для больших проектов это может быть объемный документ, который следует установленным стандартам и является предметом для официальной проверки и процедуры утверждения. План документирования должен быть доведен до всех участников разрабатывающего коллектива, кого он касается. Должны быть четко установлены обязанности всех вовлеченных в работу, связанную с документированием. График документирования должен распределять время для: планирования разработки документов; проверки плана и принципов документирования; подготовки проектов и проверки их на техническую точность, полноту и соответствие; проведение согласования; распространения. Планирование следует начинать заранее, реализацию плана необходимо проверять на всем протяжении проекта. План документирования отражает намечаемые действия и является объектом для необходимых изменений. В проекте должны быть предусмотрены регулярные проверки результативности изменений в плане.

Стандарт ISO 12182 — описывает схему классификации программных средств, охватывающую существенные характеристики и атрибуты, отражающие и определяющие ПС, их виды и классы. установленная в стандарте классификация предназначена для определения классов конкретных ПС, и связей программных задач, процессов или продуктов и их документов со стандартами программной инженерии. В настоящем стандарте установлена схема классификации, помогающая:

- уточнить области применения используемого стандарта или ПС;

- определить, выбрать стандарты и шаблоны документов, применимые к конкретному проекту ПС;

- определить классификационные характеристики новых стандартов.

Описанная в настоящем стандарте классификация может служить в качестве концептуальной схемы построения системы документации. Разработчики и заказчики должны применять собственные подходы к использованию данной классификации. Ее описание не основано на четко установленных потребностях разработчиков и пользователей, поэтому применение данной схемы в практической деятельности не является обязательным. Схема классификации состоит из 16 видов, которые объединены в следующие группы.

Внутренние виды:

- режим эксплуатации;

- масштаб ПС;

- стабильность ПС;

- функциональные возможности; функции ПС;

- требование защиты;

- требование надежности;

- требуемые рабочие характеристики;

- исходный язык.

Виды среды:

- прикладная область информационной системы;

- вычислительная система и среда;

- класс пользователя;

- требование к вычислительным ресурсам;

- критичность ПС;

- готовность программного продукта.

Виды данных:

- представление данных;

- использование программных данных.

для классификации конкретного ПС может быть достаточен один вид или выбранный набор видов с конкретными классами. В зависимости от специфики ПС может быть необходимым использование дополнительных видов. В ряде случаев применения схемы классификации для представления наиболее специфичных характеристик и документации ПС может быть использована комбинация нескольких видов с конкретными классами. Схема классификации, связанная с описанием каждого вида, представляет собой перечень классов, соответствующих данному виду. В большинстве случаев такие перечни являются типовыми или открытыми, а не исчерпывающими или полными. Пользователи схемы классификации должен и руководствоваться собственными соображениями при выборе и идентификации соответствующих классов для конкретного ПС или прикладной области. Примерами классов функции ПС являются:

- обработка деловых сообщений;

- компиляция;

- научные вычисления;

- обработка текстов;

- медицинские системы;

- системы управления объектами или процессами.

Для вида прикладная области системы, классы должны быть определены в зависимости от типа или класса внешней среды и системы, в которой они устанавливаются. Примерами классов прикладной области являются:

- наука;

- бытовые устройства;

- оборудование

- аппаратура управления объектом или процессом

- предпринимательство

- система организации сети.

Для вида режим эксплуатации классы должны быть определены в зависимости от конкретных технологий или типов обработки, принятых в системе:

- пакетная обработка данных;

- обработка данных в режиме реального времени;

- обработка данных в режиме разделения времени;

- параллельная обработка данных;

- совмещенная обработка данных.

Для вида масштаб ПС должны быть определены классы в зависимости от размера или сложности ПС. Размер может быть определен в числа строк исходной программы (SLOC), исключая комментарии, и уточнен на уровне языка (в Ассемблере, Фортране, Аде). Сложность может быть определена как функция соответствующего параметра, классов масштаба ПС:

- малый;

- средний;

- большой.

Следует учитывать, что диапазоны выше названных классов не должны быть жесткими. Напротив, классы должны быть установлены с учетом представления неопределенных или приблизительных диапазонов. В остальные 12 видов характеристик, которые в стандарте иллюстрируются примерами классов, выделены:

- представление данных;

- исходный язык;

- критичность ПС;

- класс пользователя;

- стабильность ПС;

- готовность программного продукта;

- использование программных данных;

- требуемые рабочие характеристики;

- требование защиты;

- требование надежности;

- вычислительная система и среда;

- требование к вычислительным ресурсам.

Применение стандарта иллюстрируется таблицей взаимосвязи шести характеристик качества ПС по стандарту ISO 9126 и 16-ти видов классификации комплексов программ в области действия стандарта ISO 12182.

В стандарте ISO 12207 документированию посвящен специальный раздел 6.1 в группе вспомогательных процессов. Кроме того, почти все процессы и работы основного, пятого раздела стандарта, представляющего этапы и работы жизненного цикла ПС, отражают конкретные требования к документированию соответствующих работ. Специальный раздел стандарта по документированию ПС имеет следующее содержание (с небольшими сокращениями нумерации).

Процесс документирования – это процесс для записи информации, произведенной процессами жизненного цикла. Процесс содержит набор действий, которые планируют, проектируют, разрабатывают, производят, редактируют, распределяют и сопровождают те документы, в которых нуждаются все заинтересованные лица проекта, такие как менеджеры, инженеры и пользователи системы или программного продукта.

Реализация процесса — должен быть разработан, документирован и реализован план, идентифицирующий документы, которые должны быть произведены в течение жизненного цикла программного продукта. Для каждого идентифицированного документа должно быть определено следующее: заглавие (титул) или название; цель; предназначенная аудитория; процедуры и обязательства для вводов, разработки, обзора, модификации, утверждения, производства, хранения, распределения, сопровождения и управления конфигурацией; план, режим, программа для промежуточных и конечных (заключительных) версий.

Проектирование и разработка — каждый идентифицированный документ должен быть спроектирован (разработан) согласно соответствующим документационным стандартам для формата — шаблона, описания содержания, нумерации страниц, размещения рисунков / таблиц, маркировки (отметки) права собственности/ защиты и других компонентов представления. Должны быть подтверждены источники и соответствие входных данных для документов. Подготовленные документы должны быть рассмотрены и отредактированы на предмет формата, технического содержания и стиля представления в соответствии с их стандартами. Они должны быть рассмотрены на соответствие и одобрены доверенным персоналом до выпуска.

Производство — документы должны быть произведены и поставлены заказчику согласно плану. Производство и дистрибуция документов может использовать бумагу, электронные или другие средства. Оригинальный материал (оригинал) должен быть сохранен согласно требованиям для хранения данных, защиты, содержания и дублирования. Средства управления должны быть поставлены согласно процессу управления конфигурацией (раздел 6.2 стандарта ISO 12207).

Сопровождение задач и, требующие исполнения измененного кода, представленного в документации, должны быть выполнены в соответствии с Процессами Сопровождения (см. раздел 5.5 стандарта). Для тех документов, которые находятся под конфигурационным управлением, модификации должны управляться согласно Процессу управления конфигурацией.

Стандарт ГОСТ Р 51904 регламентирует документы, которые создаются в течение всего жизненного цикла ПС. Эти документы позволяют реализовать процессы и модификацию программного средства. Заказчик должен осуществлять выбор необходимого и экономически обоснованного Состава и Содержания документов для конкретной разработки, Заказчик разрешает любые конфликты между требованиями разрабатывающего предприятия и требованиями контракта. В настоящем стандарте не ставилась задача описать все документы, которые могут быть необходимы для разработки конкретного программного средства, и предложить конкретные методы организации информации. Дополнительно к З9-и документам, определяемым в этом стандарте, могут быть подготовлены другие документы для поддержки процесса разработки и удовлетворения требований контракта. В отдельном разделе обсуждаются характеристики, форма, методы контроля конфигурации и содержание документов жизненного цикла ПС, при этом выделены:

- однозначность: информация является однозначной, если она написана в терминах, которые допускают только единственную интерпретацию, уточненную, если необходимо, соответствующими определениями;

- полнота: информация является полной, если она включает в себя необходимые требования и/или описательные материалы, определяет ответную реакцию для всего диапазона допустимых входных данных, используемые рисунки и таблицы сопровождаются необходимыми обозначениями, термины и единицы измерения определены;

- верифицируемость: информация является верифицируемой, если она может быть проверена на корректность человеком или инструментальным средством;

- согласованность: информация является согласованной, если не существует противоречий внутри нее и с внешней средой;

- модифицируемость: информация является модифицируемой, если она структурирована и имеет такой стиль, что изменения могут быть выполнены в необходимом объеме, согласованно и корректно без нарушения структуры компонента или проекта ПС;

- трассируемость: информация является трассируемой, если о каждого его компонента может быть определен корректный первоисточник.

Форма документов должна обеспечивать эффективный поиск и просмотр документов ПС в процессе обслуживания систем. Состав документов и их конкретная форма должны быть определены в Плане. Документы жизненного цикла ПС могут быть отнесены к одной из двух категорий степени контроля, в соответствии с применяемыми в стандарте методами управления конфигурацией. Введение различных категорий контроля позволяет снизить стоимость разработки в случаях, когда менее строгий контроль может быть применен без снижения допустимого качества и безопасности.

Кроме стандартов, приведенных в данном разделе, процессы документирования и рекомендуемая Структура шаблонов документов отражены, в той или иной степени, во многих стандартах.

Стандарти, що регламентують експлуатаційну документацію

Эксплуатационная документация должна обеспечивать эффективное применение программных средств в соответствии с их назначением и функциями квалифицированными специалистами-пользователями. Состав и содержание комплекта документов конкретного программного продукта, следует адаптировать разработчиками к его особенностям и свойствам на основе использования стандартов и типовых структур - шаблонов. Разработчики документов должны обеспечивать комфортное и корректное применение ПС пользователями, на основе ясного и непротиворечивого изложения в документах технологических процедур и операций для функционирования и получения требуемых результатов. На базе представленного в стандарте набора и содержания документов следует выделять из них необходимые для двух классов ПС, которые в наибольшей степени различаются особенностями эксплуатации. Первый класс характеризуется комплексами программ автоматизированного управления динамическими объектами и процессами в реальном масштабе времени. В процессе их применения допускается минимальное вмешательство и процедуры пользователей, и необходим, соответственно, небольшой объем эксплуатационных документов, выделяемых из базового. Для ПС второго класса возможно применение пользователями широкого набора процедур управления, которые должны быть регламентированы достаточно полным набором и подробным содержанием документов. Все последующее изложение ориентировано на этот класс ПС.

Пользователи таких ПС можно разделить на две крупных группы, каждая из которых должна быть обеспечена комплектной эксплуатационной документацией:

- администраторы, подготавливающие ПС к эксплуатации и обеспечивающие их функционирование и использование по прямому назначению;

- операторы пользователи, реализующие функционирование и применение программных средств в системе, обработку и анализ результатов.

Документация администрирования при эксплуатации системы должна обеспечивать поддержку первичной инсталляции, безопасного функционирования и восстановления программ и данных после сбоев. Администратор системы должен быть информирован о всех изменениях функционирования устройств системы и внешней среды, могущих привести к сбою или возникновению аварийной ситуации, и предпринимать соответствующие действия. для этого требуется полная информация о компонентах системы (компьютерах, сетевых устройствах) и внешней среды, которые имеют свои особенности в управлении с помощью специальных программных средств, поддерживающих администрирование и управление системой и ПС. К основным функциям системы администрирования относятся:

- консультация разработчиков программ и данных по особенностям применения операционной системы и системы управления базой данных (СУБд);

- планирование использования памяти и производительности вычислительной системы в рабочем режиме применения ПС;

- инсталляция и генерация инструментальных средств и рабочей версии ПС для оперативного пользователя;

- выявление и регистрация сбоев и дефектов функционирования программ и данных,

- управление, корректировка и учет внешней среды при реконфигурации конкретного ПС;

- оперативное управление, учет и распределение ресурсов системы и компонентов ПС;

- управление средствами защиты информации и санкционированный доступом пользователей, анализ попыток взлома системы защиты;

- защита и восстановление информации баз данных при дефектах и искажениях;

- сбор статистики о функционировании системы обработки информации и ПС.

Взаимодействие при управлении заданиями и ресурсами осуществляется путем обмена спецификациями заданий, которые определяют состав работ. управляющая деятельность администратора состоит в манипулировании управляемыми объектами и должна описываться, анализироваться и регламентироваться совокупностью требований и документов в четырех направлениях: информационном; функциональном; коммуникационном и организационном.

С информационной позиции административное управление прикладными программами и процессами их функционирования должно содержать документирование и описание управляемых объектов и используемых ресурсов. Для каждого управляемого объекта и ресурса необходимо определить их свойства атрибуты, а также их структуру, объем, сложность. Кроме того, должна регистрироваться и храниться информация о содержании операций управления и справках (извещениях) о результатах воздействия на них, механизм и форма передачи которых должны быть стандартизированы.

Функциональный аспект документирования административного управления ПС должен соответствовать требованиям конкретной информационной системы по реализации функций управления и обработке управляющей информации при подготовке и исполнении заданий. Комбинации функций должны удовлетворять общим требованиям на среду функционирования и обеспечивать корректную реализацию каждой функции.

Коммуникационный аспект определяет взаимодействие пользователей (управляющие объекты) и исполнителей заданий (управляемые объекты) посредством обмена управляющей информацией. Должна быть обеспечена и документирована транспортировка запросов на управляющие операции и извещений о их реализации, а также результатов контроля состояния объектов и процессов взаимодействия с внешней средой.

Организационный аспект состоит в документировании сфер административного управления и общего набора функций ПС, Подлежащих реализации в системе и внешней среде. Кроме того, должны быть созданы механизмы контроля соблюдения стандартов и аттестационного тестирования реализаций функций администрирования.

Каждый из документов административного управления должен не противоречить международным стандартам на коммуникацию, интерфейсы с пользователями и базами данных, на защиту и обеспечение безопасности информации. Определяющую роль среди них играют стандарты на услуги и протоколы управления, которые регламентируют форму спецификаций выполняемых заданий, способы перемещения документов, необходимых для их выполнения, и результатов исполнения заданий, а также данных для контроля процессов реализации заданий.

для сохранения применяемых операционных систем, прикладных программ и баз данных, а также для обеспечения возможности их переноса на иные платформы необходимо выделение и унификация интерфейсных компонентов, организующих взаимодействие пользователей с различными аппаратно-программными реализациями терминалов. Для этого необходима унификация концепции, архитектуры, функций и методов визуализации пользовательского интерфейса. Задача обеспечения мобильности пользовательского интерфейса включает стандартизацию:

- визуализации и непосредственного взаимодействия пользователей с различными типами терминалов;

- интерфейсов программных средств и баз данных, обеспечивающих визуализацию, с операционной системой;

- интерфейсов программных средств визуализации с приложениями.

Для обеспечения мобильности программных средств и данных, взаимодействие с пользователями целесообразно организовывать по принципам и моделям, заложенным в международных стандартах графических систем. Однако развитие программных средств графических систем происходит очень динамично. В результате разработка стандартов де-юре в этой области не поспевает, а реальной практикой совершенствования функциональных возможностей диалога пользователей и аппаратных графических устройств. Это приводит к появлению и массовому использованию в этой области стандартов де-факто. Их формализация на международном уровне может быть не всегда целесообразна, так как ограничено время их существования вследствие интенсивного развития функций и изменения аппаратуры диалоговых средств.

Основу современного пользовательского интерфейса с ПС составляют наборы текстовых и графических элементов и действий над ними, представляемые как меню и системы окон для манипулирования с изображениями. Основные особенности современного интерфейса с пользователями состоят в следующем:

-наличие механизмов управления окнами;

-использование готовых графических символов (икон) для отображения управляемых объектов;

-непосредственное манипулирование графическими объектами и окнами посредством «мыши»;

-объектно- и проблемно-ориентированное проектирование диалоговых систем.

Для реализации интерфейсов создаются библиотеки технологических интерактивных программ, позволяющих использовать устройства ввода команд управления и графических элементов при наличии обратной связи, отображающей на дисплее результаты манипулирования ими. Эти возможности обеспечиваются прикладными и системными программными средствами, обладающими общностью пользовательских интерфейсов структуры меню, инструментальных линеек, диалоговых окон и т.д.

Типовые формы-шаблоны, документов и процедуры работы с ними, рассматриваемые как объекты стандартизации, относятся к функциональному уровню взаимодействия пользователей с системами. Объектами стандартизации, соответствующими процедурам являются компоненты интерфейса пользователя, определяющие возможность начала соответствующей операции, ее ход и результат. Должна быть предусмотрена идентификация ошибочных действий и стандартизирована форма сообщений об ошибках. В этих документах должны быть описаны:

-соответствие между элементами интерфейсов пользователя (экранными формами) и типовыми процедурами;

-последовательность допустимых операций и переходы между экранными формами;

-формы идентификации ошибочных действий и/или ситуаций;

-формы входных и выходных документов.

Обучение представляет собой процесс обеспечения и сопровождения обучаемого персонала. Приобретение, поставка, разработка, функционирование и сопровождение программных средств, в большой степени, зависит от квалификации персонала. Поэтому в проекте ПС обязательно должно быть запланировано и осуществлено обучение персонала с целью подготовки работы персонала при приобретении, поставке, разработке или сопровождения программного средства. Процесс обучения состоит аз следующих действий, которые должны быть документированы:

- оценка требований проекта ПС с целью установления и своевременного создания условий для приобретения квалификации и опыта, требующихся операторам, техническому персоналу и администраторам;

- определение видов и уровней обучения и категорий персонала, требующих обучения;

- разработка и документирование планов и требований к обучению;

- разработка руководств для обучения, включая материалы и средства автоматизации, используемые для обеспечения обучения;

- планирование должно обеспечить регулярное обучение персонала, контроль и учет результатов обучения с оценкой достигнутой квалификации специалистов;

- должно быть гарантировано, что соответствующие категории обученного персонала готовы для выполнения запланированных действий и задач с определенным программным средством.

Возрастающий масштаб применения программных средств и их с сложности вызывает необходимость наличия полной, точной и понятой эксплуатационной документации на эти средства, доступной пользователям. Стандарты определяют способ достижения данной цели, устанавливая работы (что должно быть сделано) и исполнителя, обеспечивающие качество и унификацию документаций пользователя программных средств. Для достижения качества программной документации она должна рассматриваться как неотъемлемая часть процесса создания данного ПС. При надлежащем подходе к данной проблеме требуется достаточно сложная систематизированная работа по планированию и реализации документирования эксплуатации ПС, что регламентируется представленными стандартами.

Стандарт ISO 15910 является наиболее современным нормативным документом, регламентирующим процессы создания эксплуатационной документации для пользователей сложных программных средств. Целью стандарта является стимулирование разработчиков программных средств к методичному использованию процесса документирования. Он построен по традиционной схеме стандартов ISO и первые семь разделов являются вводными, а также определяют терминологию. Основное, функциональное содержание стандарта сосредоточено в 8-м разделе - Требования к документированию ПС.

Пользовательская документация должна проходить испытания на достоверность, которые должны быть спланированы и реализованы типовыми пользователями на базе применения эксплуатационных процедур реального программного средства. Описана координация документирования у субподрядчиков, а также конфигурационное управление изменениями и сопровождение документов. Раздел 8 посвящен требованиям к содержанию и стилю изложения типовой спецификации. Изложены требования к языку и грамматике составления документов, к оформлению содержания текста, рисунков и таблиц, к характеристикам и качеству используемой бумаги. Подробно описаны технические правила оформления твердой копии документов и правила структурирования и представления схем компонентов, окружения, иллюстраций и основного текста документов. Специальный подраздел посвящен подготовке электронных документов: общей схеме, размещению материала и комментариев, помощи подсказками, навигации по тексту, использованию клавиатуры.

Стандарт представляет разработчикам документации - пользователям метод определения и применения процесса документирования при создании конкретного программного средства. Основной работой по настоящему стандарту является создание комплексного плана разработки документации, реализация которого обеспечивает лучшее документирование программного средств. для соответствия настоящему стандарту план должен включать в себя требования (спецификацию) к стилю оформления документов. Настоящий стандарт не определяет структуру и состав требований (то есть компоновку конкретного документа или используемый шрифт), но устанавливает их диапазоны. Стандарт также определяют виды информации, представляемой заказчиком разработчику документации (документатору) для проверки и распространения документации.

Настоящий стандарт определяет реализацию процесса документирования, описанного в ISO 12207 и может быть адаптирован к условиям конкретных проектов. Стандарт не определяет компоновку конкретного документа, его содержание и другие аспекты комплектности документации, однако он устанавливает метод планирования и проведения процессов документирования.

Процесс документирования должен быть выполнен в два этапа в последовательности, представленной на рис. 3.

Рисунок 3

Поэтапные работы выполняются не одновременно. На отдельных этапах работы могут проводиться параллельно. Возможные итерации работ показаны пунктирными линиями. Минимальный состав документации определяется заказчиком (например, с использованием ISO 12207 или ISO 6592), что должно быть учтено документатором при разработке плана документирования.

Описание эксплуатационной концепции для системы управления содержит описание действий пользователя, необходимых для работы с предлагаемой системой и ПС, ее связи с существующими системами и процедурами. данное описание используют при создании соглашения между поставщиком, разработчиком, организацией, осуществляющей поддержку, и пользователями. данный документ фиксирует текущее состояние системы, ее назначение, возможности и ограничения в зависимости от режима или конкретного состояния эксплуатации (например, стандартный режим, сопровождение, обучение, снижение функций, аварийные ситуации) и включает в себя описание (см. рис. 2):

- конкретной эксплуатационной среды и ее характеристики;

- основных компонентов системы и связей между ними;

- внешних интерфейсов системы;

- возможностей и функций системы;

-таблиц и дополнительных графических представлений входов, выходов, потоков данных, а также руководств, позволяющих разобраться в текущем состоянии системы с точки зрения пользователя:

- состава персонала, его организационной структуры, технической подготовки, обязанностей, взаимодействия;

- уровней и циклов технического обслуживания;

- форм регистрации обнаруженных дефектов;

- соглашений о внесении изменений, возникающих в процессе сопровождения (их классификация и порядок внесения, включая поставку необходимого оборудования и обучение персонала);

- концепцию поставки новой или модифицированной версии, эксплуатационный сценарий;

- информацию о взаимодействии пользователей, поставщика, разработчика и организации, осуществляющей поддержку, во время эксплуатационного периода.

В обязанности документатора входит обеспечение плодотворности контактов заказчика с разработчиками программных средств, гарантирующее, как минимум, понимание сути выпускаемой продукции и соответствующих ей аудиторий. Независимо от того, является ли документатор одновременно разработчиком программного средства, заказчик должен обеспечить его копиями всех применяемых стандартов, руководствами по стилям и форматам, а также соответствующими материалами (если они не являются общедоступными). Заказчик должен обеспечивать документатору доступ:

- ко всем соответствующим спецификациям, форматам записей, компоновкам экранов и отчетов, выходным результатам работы средств автоматизации программирования и другой информации, необходимой для подготовки документации;

- к рабочей копии программного средства (при необходимости);

- к аналитикам и программистам, включая своевременное правильное решение вопросов, возникающих у персонала разработчиков документации;

- к типичным пользователям (по возможности) для анализа аудитории и тестирования на практичность.

Обязанностью разработчика является обеспечение полноты, правильности и актуальности всех Материалов, предъявляемых разработчиком на момент их поставки. Разработчик должен гарантировать, что представление документатору данных материалов не нарушает прав интеллектуальной собственности любой третьей стороны. документатор должен предпринять соответствующие шаги по сохранению материалов, представленных заказчиком, обеспечить защиту информации о требованиях заказчика и возвратить все материалы заказчику по завершении проекта документирования. В ряде случаев требуется сохранить конфиденциальность и секретность предоставляемых материалов. В договоре должны быть установлены уровни (грифы) конфиденциальности или секретности материалов, представляемых заказчиком документатору.

План документирования — готовить менеджер — документатор, в котором определены задания, выполняемые при создании конкретных документов. План должен быть официально согласован, что подтверждает полный учет всех требований заказчика. Обычно план документирования должен охватывать весь комплект документов, например, руководства пользователя, диалоговую документацию, справочные тексты и краткие справочные карты.

В плане документирования должны быть четко описаны область применения и ограничения использованию планируемых документов, а также основные решения по их анализу и проектированию. В плане также должны быть определены процессы и проверки, выполняемые при разработке документации. План документирования должен охватывать следующие вопросы:

- рабочее наименование, назначение, область применения и ограничения по использованию планируемой документации;

- спецификацию стиля документов;

- определение аудитории и квалификации пользователей;

- обоснование причин использования документов данной аудиторией и ее целевое назначение;

- содержание (план-проспект) документации, с оценкой ее постраничного объема, и соответствующие уточнения для других машинных носителей документов;

- номенклатуру поставки — число печатных копий, наличие электронных копий, форматы дисков и файлов (включая версии программных средств) и откуда они могут быть поставлены;

- установление собственника авторских прав на документы и любых других прав собственности, в договорах на документацию должны быть указаны собственники соответствующих прав;

- уровни (грифы) секретности и конфиденциальности (при необходимости);

- процедуры и проверки, могущие влиять на процесс разработки документации, включая, при необходимости, хранение, поиск, резервирование, передачу и оценку качества;

- методы и средства производства (тиражирования) и используемые версии программных средств;

- структуру коллектива разработчиков документов и, возможно, плана выбора данной структуры;

- требования к проектным ресурсам, включая информационные и прочие ресурсы, представляемые заказчиком, и срокам их представления;

- метод передачи документатору информации об изменениях программного средства в процессе его разработки;

- планы контроля изменений и сопровождения документации;

- планы проверки документации после ее создания;

- календарное планирование (графики) по контрольным точкам, включая (при необходимости):

* утверждение плана документирования;

* подготовку, проверку и корректировку проекта каждого

документа;

* тестирование на практичность;

* подготовку оригиналов шаблонов;

* распечатку, переплетение и распространение документации.

При необходимости каждый из пунктов плана должен быть описаны для каждого элемента документации. План документирования должен быть подготовлен и утвержден до начала разработки документации, чтобы гарантировать согласование всеми сторонами поставленных задач и используемых методов. После утверждения плана он должен быть доведен до всех заинтересованных сторон, включая персонал разработчиков документации, а также заказчика и субподрядчиков (например, печатников, наборщиков, переводчиков).

Определение аудитории пользователей. План документирования должен включать определение аудитории пользователей документации, уровня образования, квалификации, способностей, подготовки, опыта пользователей и другие характеристики, связанные с содержанием, структурой и использованием документации. Обычно имеется ряд различных групп пользователей, преследующих различные цели при пользовании конкретной документацией. Каждый тип пользователей, включая их характеристики и задачи, решаемые ими при помощи документации, должен быть определен отдельно. данные об определении аудитории пользователей могут быть получены из результатов изучения аудитории, проведенного заказчиком или документатором; описаний, представляемых заказчиком. По возможности персонал разработчиков документации должен организовать встречи с типовыми пользователями в их рабочей обстановке и обследовать их работу.

Контроль плана документирования. После официального согласования плана документатор должен нести ответственность за контроль и распространение данного плана. Документатором должен быть составлен список по распространению учтенных копий данного плана. В случае внесения в план изменений (согласованных с документатором и заказчиком) документатор должен гарантировать получение этих изменений всеми держателями учтенных копий. Вследствие проблем, возникающих при наличии устарелых копий плана, документатор должен запретить его несанкционированное копирование и предусмотреть процедуры аудита всех обновляемых копий плана.

Проверка выполнения плана должна проводиться заказчиком с привлечением документатора (при необходимости). Целью проверки является гарантирование полноты и правильности представленных материалов и удовлетворения ими потребностей заказчика в соответствии с условиями договора и плана документирования. Проверка должна проводиться персоналом заказчика, обладающим соответствующей квалификацией и полномочиями на изменения в документах и их утверждению.

При утверждении (согласовании) каждого проекта документации заказчик должен гарантировать правильность решения вопросов ее защиты и законности. документация для проверки должна представляться с сопроводительным письмом документатора, в котором должны быть указаны цели проверки и обязанности проверяющей стороны (эксперта). Качество документов и успешность проверок повышаются при наличии хороших контактов между заказчиком и документатором в процессе их разработки. При этом должно быть предусмотрено неформальное обсуждение возникающих вопросов и по возможности раннее представление заказчику образцов документации или предварительных материалов. Проведение проверки не освобождает документаторов от обязанностей по гарантированию максимально возможной полноты и точности документации. Непосредственно перед представлением любой публикации на утверждение, в ней должны быть обновлены все распечатки экранов для гарантирования ее актуальности. Заказчик должен хранить копии всех вносимых изменений для сравнения их с последующими проектами документов. Представляемые заказчиком комментарии должны быть в виде, позволяющем персоналу разработчиков внести предлагаемые изменения в проекты документов без дальнейших пояснений.

Для больших сложных систем и ПС, разрабатываемых одновременно с документацией, Может быть необходимо более двух редакций проектов документации и наличие гранок. В этом случае максимальное число проектов (редакций) документации должно быть оговорено между заказчиком и документатором и указано в плане. При проверке проектов документации используют редакционные разметки (знаки, цвета, разметка шрифтов и прочее). Целью редакционных разметок является выделение частей публикации, нуждающихся в уточнении. Тем самым предотвращается необходимость в повторных проверках проектов.

Проверка плана должна гарантировать, что документация, предусмотренная планом, после его выполнения будет удовлетворять целям заказчика. При утверждении плана документирования заказчик согласовывает все характеристики номенклатуры поставки, предусмотренной планом. Заказчики должны уделять особое внимание структуре, полноте и практичности документации в соответствии с планом- проспектом ее содержания. План документирования должен быть проверен и утвержден (согласован) до начала работ над первым проектом документации.

Проверка первой редакции должна содержать основную часть документации в соответствии с планом документирования, а также содержание, приложения и словарь (словник, определения). Первый проект документации должен быть проверен заказчиком (см. рис. 2). Данная проверка предназначена для контроля технической правильности и полноты документации и должна гарантировать соответствие данного проекта заданиям плана документирования. Также проверяют соответствие орфографии, пунктуации, стиля и компоновки документации требованиям плана документирования. При утверждении первого проекта заказчик согласовывает техническую правильность, структуру, понятность и полноту документации, исключая предложенные изменения. Проект должен быть проверен на соответствие выданным заданиям, указанной аудитории, содержанию и другим характеристикам, согласованным в плане документирования. Перед возвратом первого проекта с комментариями документатору заказчик должен быть уверен, что проект, включая все корректировки, соответствует плану документирования.

Проверка второй редакции проекта. Во второй проект документации должны быть включены все изменения, согласованные с заказчиком при проверке первого проекта, а комплектность поставки второго проекта по возможности должна соответствовать номенклатуре поставки, оговоренной в плане документирования. данная проверка предназначена для контроля правильности внесения в документацию всех изменений, указанных заказчиком на этапе первого проекта. Любые обнаруженные заказчиком несоответствия должны быть немедленно доведены до сведения документатора, который должен соответствующим образом модифицировать документацию и представить копии измененных разделов заказчику для дальнейшей проверки. Утверждая (согласовывая) гранки документации, заказчик подтверждает готовность конкретно документа к производству (тиражированию).

Тестирование документации на практичность следует рассматривать как дополнения к проводимым проверкам и анализам документации. Подобное тестирование при разработке должно проводиться на прототипе документации, наиболее полно моделирующем ее окончательную версию. При установлении условий данного тестирования должен быть полностью указан стандарт на характеристики практичности, по которому проводят измерение. Следует также определить соответствующие методы измерения и процесс описания результатов замеров. При необходимости в плане документирования следует определить внешнюю среду тестирования, которая должна полностью соответствовать эксплуатационной среде конечного пользователя. Тестирование на практичность может быть использовано для оценки (измерения) практичности по ISO 12119. В плане документирования должны быть полностью описаны условия тестирования, включая:

- этапы жизненного цикла разработки, на которых должно проводиться тестирование;

- цели тестирования;

- используемые показатели (например, время реакции задач);

- среду тестирования;

по ним;

число и вид привлекаемых пользователей;

процесс описания результатов тестирования и рекомендаций

- процесс обеспечения реализации рекомендаций по результатам тестирования;

- процесс доведения результатов тестирования до всего персонала разработчиков документов и заказчика;

- обязанности персонала разработчиков документации, участвующего в тестировании;

- процесс определения необходимости последующего тестирования.

При проведении тестирования документации на практичность необходимо проверить соответствие документов конкретному программ ному средству. Для повышения эффективности данного тестирования необходимо проводить как можно раньше, внося необходимые изменения, как в само программное средство, так и в его документацию. При составлении графика тестирования необходимо учитывать тестирование отдельных компонентов (частей) ПС и выполняемых ими функций. Когда тестирование запланировано до завершения разработки ПС, при его проведении должна быть использована рабочая модель или прототип данного средства. При проведении тестирования после завершения разработки ПС следует использовать выпускаемую версию данного программного средства.

В проведении тестирования документации на практичность должны участвовать представители заказчика. Данными представителями должны являться лица, имеющие тот же опыт (навыки, образование и т.д.), что и пользователи из конкретной аудитории. Цели их участия в тестировании должны быть определены заказчиком. Для участия в тестировании по возможности должны быть привлечены лица из конкретной аудитории.

Контроль изменений и сопровождение документации. В плане документирования должны быть предусмотрены следующие типы изменений документации:

- функциональные изменения данной версии — изменения функции ПС, внесенные при разработке документации и отраженные в опубликованной документации;

- функциональные изменения последующей версии — изменения функции ПС, внесенные при разработке документации и не отраженные в опубликованной документации, но подлежащие учету в последующей редакции;

- изменения ПС после публикации изменения конкретных функций программного средства после издания документации;

- изменения документа после публикации — изменения в опубликованной Документации, обусловленные изменениями ПС или обнаружением погрешностей в данной документации.

документатор должен обеспечить проектирование документации так, чтобы допустить внесение в нее изменений всех четырех типов. для этого необходимо, чтобы:

- разработчики документации получали учтенные копии изменений программного средства, подтверждающие внесение соответствующих изменений в данное средство после конкретной даты его пересмотра;

- наименование документа и номер версии или дата были указаны в верхнем или нижнем колонтитуле конкретного документа;

- в бумажном документе с замененными страницами была предусмотрена таблица действующих страниц (лист изменений) или нечто подобное, позволяющее пользователю контролировать наличие каждой страницы документа;

- дополнительно был предусмотрен метод, позволяющий пользователю контролировать соответствие конкретной копии данного документа используемой версии ПС.

В стандарте ISO 15910 представлены рекомендации по созданию и применению электронной документации, справочной и диалоговой информации. В спецификации документации могут быть указаны один или несколько из следующих типов справочной информации:

- контекстная справка — информация о текущем поле, в котором находится курсор или высвечена программа, включал ее необходимое или целевое (предметное) содержание, ее назначение и потенциальное влияние на работу программного средства;

- расширенная справка — информация о текущем экране или окне, включая ее назначение и требуемый режим использования;

- справка о клавишах — о применении клавиатуры, функциональном назначении клавиш и их наименовании (обозначении);

- справка о сообщении — о том, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;

- терминологическая справка — определения конкретных элементов, связей с конкретной тематикой и расшифровка обозначений и сокращений.

В спецификации стиля электронной документации могут быть указаны один или несколько из следующих типов диалоговой, оперативной документации:

- руководства или рекомендации пользователя - описывают процедуры по применению продукта;

- командные справки — определяют синтаксис, результаты и целевое назначение каждой команды (только для команд управления системой);

- рекомендации по сообщению определяют, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;

- административная информация — о конфигурации, защите системы, а при необходимости — о ее инсталляция, предназначенная для администратора системы.

Стандарт IЕЕЕ 1063-1987 (подтвержден в 1993 г.) отражает общие требования к пользовательской документации на программные средства широкого применения. Стандарт определяет минимальные требования к структуре и содержанию комплекта документов для пользователей программных продуктов. Стандарт ориентирован на документы, применяемые при инсталляции, эксплуатации и поставке ПС любого размера и назначения, но без изменения и сопровождения программ. Он не применим для технологической документации, используемой при проектировании, разработке, тестировании, испытаниях и сопровождении ПС, а также для оформления коммерческих пакетов прикладных программ. Использование стандарта не должно препятствовать применению более строгих и широких требований к документам, а также собственных стандартов предприятия по стилю изложения документов.

В первых двух разделах стандарта представлено назначение, ограничения для применения и определения основных терминов. В третьем разделе рекомендуется начинать планирование разработки эксплуатационной документации с определения:

- потенциальных пользователей и технологии их взаимодействия с документами;

- комплектации и ориентации каждого документа на определенную сферу применения;

- способов использования документов:

* инструктивных для обучения применению и основным операциям по эксплуатации, диагностике и инсталляции ПС;

* справочных, детально представляющих всю необходимую информацию при применении и функционировании программ.

В четвертом разделе представлены требования к составу (структуре) единого пользовательского документа. Две таблицы, отражают рекомендуемую структуру документа и варианты его модификации. В первой таблице перечислены названия подразделов, рекомендуемого типового пользовательского документа на ПС. Во второй таблице состав этих подразделов адаптирован для документирования небольших, относительно простых программ и для сложных комплексов программ с многотомной документацией.

Пятый раздел посвящен изложению требований и рекомендаций к содержанию каждого из подразделов пользовательского документа на программное средство в составе:

- титульного листа, оформляемого по правилам предприятия с учетом требований заказчика;

- ограничения на применение документа и указания на авторские права на программный продукт и пользовательский документ;

- гарантии и обязательства по контракту, а также условия отказа от них;

- структура и перечень разделов документа;

- перечень иллюстраций (рисунков, таблиц и схем) с указанием страницы текста описания, где они используются;

- предисловие:

* предполагаемый уровень квалификации и предшествующее обучение пользователей;

* аппаратная и операционная среда, которой соответствует применение данной версии ПС и документа;

* назначение документа;

* стилистические особенности описания;

* взаимодействие с другими документами;

* отчетность о дефектах.

Основное описание «тело» документа:

- учебно-методическая часть:

* теоретические основы данного комплекса программ;

* решаемые задачи и функции;

* технические и административные операции для запуска

задач;

* предостережения и предупреждения;

* метод решения каждой задачи, их взаимодействие и ограничения;

- справочно-рекомендующая часть — конкретные рекомендации и подробные инструкции по применению данного ПС:

* исходные данные, необходимые для корректного функционирования программ;

* информация дал их контроля;

* рекомендации как приостановить исполнение и провести рестарт программ;

* регистрация окончание исполнения программы;

* состав результатов;

- предупреждения о возможных ошибках и дефектах освоения и применения;

- приложения — детальные сведения о форматах исходных и результирующих данных, структуре файлов и экранов;

- библиография;

- глоссарий;

- индекс.

Шестой раздел стандарта содержит общие методические требования к представлению документа пользователя: методику освещения материала; рекомендации по составу и плотности текста каждого раздела; терминологические рекомендации, а также по отражению взаимосвязи частей материала. В седьмом разделе стандарта приведена библиография.

Стандарт ISO 9127 рекомендуется для создания пользовательской документации на коммерческие пакеты (закрытые коробки) программных средств, поставляемых на рынок. Пользовательская и рекламная документация на пакеты программ должна включать:

Общие сведения: введение; ограничения; область применения; определения; ссылки.

Пользовательская документация — инструкция по эксплуатации должна содержать описание, в котором заключена вся информация, необходимая пользователю для установки, запуска и применения ПС. Обычно эта документация представляет собой одно или несколько руководств, заключенных вместе с носителями ПС внутри упаковки, В результате пользователи не могут ознакомиться с детальным руководством до тех пор, пока пакет не куплен.

Описание целей и области применения публикуется на внешней упаковке пакета ПС. Его задачей является дать возможность будущему покупателю оценить применимость ПС к своим по потребностям.

Системный анализ

Анализ требований

Проектирование

Кодирование

Тестирование

Сопровождение

Рисунок 1.1 – Классический жизненный цикл разработки ПО

Анализ

Проектирование

Кодирование

Тестирование

1-й инкремент

оставка

1-го инкремента

Анализ

Проектирование

Кодирование

Тестирование

2-й инкремент

Поставка

2-го инкремента

Анализ

Проектирование

Кодирование

Тестирование

3-й инкремент

Поставка

3-го инкремента

Рисунок 1.4 – Инкрементная модель

Рисунок 1.6 – Спиральная модель: 1 – начальный набор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком

Рис.10.1. Граф задания сроков выполнения работ

A2jL_ 4нед.

1. Ярославский государственный педагогический университет им
2. тема дополнительных средств пассивной безопасности SRS 1 STEP1 Система дополнительных средств
3. УТВЕРЖДАЮ Генеральный директор ООДТДМ им
4. Контрольная работа по дисциплине Русский язык и культура речи Выполнил- Проверил-
5. Архитектурные памятники Казанского Кремля.html
6. Социология личности1
7. Интеграция дошкольного и семейного воспитания в процессе работы семейного клуба «Друзья природы»
8. Кредиты от коммерческого банка на жилищное строительство
9. тема стала одной из немногих сфер экономики в которой переход к рыночным отношениям произошел наиболее быст
10. Котирование активов на бирже
11. Производство чугуна и стали
12. Банковский менеджмент
13. Хабаров Ерофей Павлович
14. 081994 N 26ФЗ от 28
15. і Наслідком Першої світової війни став новий переділ світу між країнамипереможницями закріплений юридично
16. Туризм в странах Латинской Америки и Китае
17. ЗАДАНИЕ N 1 сообщить об ошибкеКейсзадания- Кейс 1 подзадача 1Кривая долгосрочных средневаловых издержек фирм
18. Курсовая работа- Робота з данними в середовищі електронних таблиць Microsoft Excel.html
19. обыденной и простой формы некое искусственное её украшение
20. реферату- Регулювання виробничого процесуРозділ- Організація виробництва Регулювання виробничого процесу.

Материалы собраны группой SamZan и находятся в свободном доступе