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

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.

Процессы создания автоматизированных систем ( АС ), в состав которых входит и ПО , регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

В соответствии со стандартом ISO / IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).

Рис. 5.1.

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

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

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

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

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

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

Заявочные предложения должны содержать:

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

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

Подготовка и корректировка договора включает следующие задачи:

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

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

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

1. инициирование поставки;
2. подготовку ответа на заявочные предложения;
3. подготовку договора;
4. планирование работ по договору;
5. выполнение и контроль договорных работ и их оценку;
6. поставку и завершение работ.

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

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

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

Процесс разработки включает следующие действия:

1. подготовительную работу;
2. анализ требований, предъявляемых к системе;
3. проектирование архитектуры системы;
4. анализ требований, предъявляемых к программному обеспечению;
5. проектирование архитектуры программного обеспечения;
6. детальное проектирование программного обеспечения;
7. кодирование и тестирование программного обеспечения;
8. интеграцию программного обеспечения;
9. квалификационное тестирование программного обеспечения;
10. интеграцию системы;
11. квалификационное тестирование системы;
12. установку программного обеспечения;
13. приемку программного обеспечения.

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

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

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

Анализ требований к программному обеспечению предполагает определение следующих характеристик для каждого компонента ПО :

1. функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
2. внешних интерфейсов;
3. спецификаций надежности и безопасности;
4. эргономических требований;
5. требований к используемым данным;
6. требований к установке и приемке;
7. требований к пользовательской документации;
8. требований к эксплуатации и сопровождению.

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

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

1. трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
2. разработку и документирование программных интерфейсов ПО и баз данных (БД);
3. разработку предварительной версии пользовательской документации;
4. разработку и документирование предварительных требований к тестам и плана интеграции ПО.

Детальное проектирование ПО включает следующие задачи:

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

Кодирование и тестирование ПО включает следующие задачи:

1. кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
2. тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
3. обновление документации (при необходимости);
4. обновление плана интеграции ПО.

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

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

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

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

   1. планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов;
   2. определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
2. Эксплуатационное тестирование, осуществляемое для каждой очередной редакции программного продукта, после чего эта редакция передается в эксплуатацию.
3. Собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.
4. анализ проблем и запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);
5. модификацию ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
6. проверку и приемку (в части целостности модифицируемой системы);
7. перенос ПО в другую среду (конвертирование программ и данных, параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода времени);
8. снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документации подлежат архивированию в соответствии с договором.

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

4.1 Построение стандарта

4.1.1 Процессы жизненного цикла

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

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

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

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

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

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

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

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

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

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

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

2. Процесс управления конфигурацией (подраздел 6.2). Определяет работы по управлению конфигурацией.

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

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

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

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

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

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

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

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

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

2. Процесс создания инфраструктуры (подраздел 7.2). Определяет основные работы по созданию основной структуры процесса жизненного цикла.

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

4. Процесс обучения (подраздел 7.4). Определяет работы по соответствующему обучению персонала.

4.1.2 Процесс адаптации

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

4.1.3 Взаимосвязи между процессами и организациями

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

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

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

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

Этапы жизненного цикла ПО

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

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

Примеры описания жизненного цикла

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

В отечественных нормативных документах (например, ГОСТ ЕСПД) принято следующее разграничение на этапы, которое приводится с указанием аналогий из списка, данного в начале раздела:

разработка технического задания (этапы 1 и 2);

технический проект (третий этап до 3.2.1 включительно);

рабочий проект (3.2.2, 4.2.1 и, частично, 4.2, 4.3);

экспериментальное внедрение (4.2 и 4.3);

сдача в промышленную эксплуатацию (этап 5);

промышленная эксплуатация (этап 6).

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

Рис. 1.1 Пример жизненного цикла программных систем

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

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

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

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

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

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

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

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

Интеграция системы (4.3). Тестирование работоспособности и функциональной законченности частей общей системы в целом.

Приемка и поставка системы (5). Производится приемка системы заказчиком, и поставка ему системы.

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

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

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

этап планирования, который определяет и координирует действия по разработке программной системы (этап 1);

этап разработки, на котором создается программная система:

постановку задачи (этап 2),

проектирование (3),

кодирование (4.1.1),

получение исполняемого кода (4.1.1, 4.3);

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

Рис. 1.2 Вариант упрощенного жизненного цикла программной системы.

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

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

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

Рис. 1.3 Последовательность этапов разработки компонент программного обеспечения

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

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

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

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

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

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

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

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

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

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

17. Организационные процессы ЖЦ ПО. Взаимосвязь между процессами ЖЦ ПО.

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

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

Процесс усовершенствования – предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО.

Процесс обучения – охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала.

Взаимосвязь между процессами ЖЦ ПО:

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

· договорной аспект – заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобретения и поставки;

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

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

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

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

18. Функциональные и нефункциональные требования. Управление требованиями.

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

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

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

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

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

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

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

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

19. Формализация, детализация и документирование требований:

Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI 830-1993 предполагает следующую структуру спецификации :

1.Введение

1.1. Цели документа

1.2. Назначение программного продукта

1.3. Определения, акронимы и аббревиатуры

1.4. Список литературы и других источников

1.5. Обзор спецификации

2. Общее описание

2.1. Описание программного продукта

2.2. Функции программного продукта

2.3. Пользовательские характеристики

2.4. Общие ограничения

2.5. Обоснования, предположения и допущения

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

4. Приложения

5. Указатели

Таблица 4. Структура спецификации требований

20. Принципы проектирования интерфейса пользователя.

1. Принципы проектирования интерфейса пользователя:

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

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

Таблица 1. Принципы проектирования интерфейсов пользователя

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

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

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

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

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

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

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

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

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

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

21. Стратегия разработки интерфейса человек-компьютер.

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

Все виды взаимодействия можно отнести к одному из пяти основных стилей взаимодействия:

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

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

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

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

5. Естественный язык. Пользователь вводит команду на естественном языке. Чтобы удалить файл, пользователь может ввести команду "удалить файл с именем XXX".

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

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

Таблица 2. Преимущества и недостатки стилей взаимодействия пользователя с системой

22. Составные части интерфейса: ввод-вывод, диалог, сообщения, проверка входных данных, подсказки. Разработка оконной системы.

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

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

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

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

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

На рис. 2 изображен итерационный процесс проектирования пользовательского интерфейса.

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

23. Функциональная (алгоритмическая) декомпозиция системы.

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

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

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

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

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

24. Структурный подход к разработке ПО.

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

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

25. Принципы структурного подхода разработки ПО.

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

• принцип «разделяй и властвуй»;
• принцип иерархического упорядочения – принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Существуют еще принципы:

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

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

• DFD (Data Flow Diagrams) – диаграммы потоков данных;
• SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) – модели и соответствующие функциональные диаграммы.
• ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь ».

Диаграммы потоков данных и диаграммы «сущность-связь » - наиболее часто используемые в CASE –средствах виды моделей.

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

На стадии формирования требований к ПОSADT –модели и DFD используются для построения модели «AS-IS » и модели «TO-BE », отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT –моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).

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

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

26. Восходящее проектирование ПО.

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

• восходящий;
• нисходящий.

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

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

Подход имеет следующие недостатки:

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

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

27. Нисходящее проектирование ПО

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

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

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

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

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

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

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

Нисходящий подход обеспечивает:

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

28. Метод функционального моделирования SADT.

Метод SADT поддерживается Министерством обороны США, которое было иници-атором разработки стандарта IDEF0 (Icam DEFinition).

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

29. Принципы построения модели IDEF0.

Основные элементы этого метода основываются на следующих концепциях:

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

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

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

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

Состав функциональной системы:

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны справой стороны. Механизм (человек или ав-томатизированная система), который осуществляет операцию, представляются дугой, входящей в блок снизу (рис.1):

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

30. Иерархия функциональных диаграмм.

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

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

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

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

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

31. Моделирование бизнес-процессов.

32. Основные принципы и технологии построения распределенных информационных систем.

Основные этапы проектирования базы данных:

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

· концептуальное проектирование;

· логическое проектирование;

· физическое проектирование;

· использование БД (заполнение БД информацией и формирование запросов и отчетов).

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

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

Процесс физического проектирования БД предполагает выполнение в среде выбранной СУБД следующих работ:

· описание логической структуры каждой таблицы;

· описание связей между таблицами, входящими в одну БД;

· первоначальное заполнение справочников БД необходимой нормативно-справочной информацией.

Что такое база данных

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

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

Все СУБД делятся на две группы: локальные и сетевые.

Локальные - это СУБД, работающие на одном компьютере. К ним относятся dBase, FoxPro, Microsoft Access и т. д.

Сетевые - это СУБД, позволяющие нескольким компьютерам использовать одну и ту же БД с помощью технологии клиент-сервер. Примерами сетевых СУБД являются InterBase, Oracle, Microsoft SQL Server и т. д.

Взаимосвязи данных:

· один к одному - каждая запись одного объекта БД будет указывать на единственную запись другого объекта;

· один ко многим - одной записи объекта БД будет соответствовать несколько записей других объектов;

· много к одному - равносилен рассмотренному выше виду «один ко многим» и отличается от него только направлением;

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

33. Модели представления данных: реляционная, древовидная, сетевая.

Тема 3. Жизненный цикл ПО 28

Жизненный цикл ПО

В соответствии со стандартом все процессы ЖЦ ПО разделены на три группы:

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

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

Четыре организационных процесса (управление, создание инф­раструктуры, усовершенствование, обучение).

ОСНОВНЫЕ ПРОЦЕССЫ ЖЦ ПО

Процесс приобретения.

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

инициирование приобретения;

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

подготовку и корректировку договора;

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

приемку и завершение работ.

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

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

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

принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;

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

подготовку и утверждение плана приобретения, включающего тре­бования к системе, тип договора, ответственность сторон и т. д. Заявочные предложения должны содержать:

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

перечень программных продуктов;

условия и соглашения;

технические ограничения (например, среда функционирования системы).

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

Подготовка и корректировка договора включают следующие задачи:

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

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

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

внесение изменений (при необходимости) в договор в процессе его выполнения.

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

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

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

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

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

подготовку ответа на заявочные предложения;

подготовку договора;

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

выполнение и контроль;

проверку и оценку;

поставку и завершение работ.

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

Планирование включает следующие задачи:

принятие решения поставщиком относительно выполнения ра­бот своими силами или с привлечением субподрядчика;

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

Процесс разработки.

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

Процесс разработки включает следующие действия:

подготовительную работу;

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

проектирование архитектуры системы;

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

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

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

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

интеграцию ПО;

квалификационное тестирование ПО;

интеграцию системы;

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

установку ПО;

приемку ПО.

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

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

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

Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО:

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

внешних интерфейсов;

спецификаций надежности и безопасности;

эргономических требований;

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

требований к установке и приемке;

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

требований к эксплуатации и сопровождению.

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

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

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

разработку и документирование программных интерфейсов ПО и баз данных;

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

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

Архитектура компонентов ПО должна соответствовать требова­ниям, предъявляемым к ним, а также принятым проектным стан­дартам и методам.

Детальное проектирование ПО включает следующие задачи:

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

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

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

разработку и документирование требований к тестам и плана те­стирования компонентов ПО;

Кодирование и тестирование ПО охватывают следующие задачи:

разработку (кодирование) и документирование каждого компо­нента ПО и базы данных, а также совокупности тестовых проце­дур и данных для их тестирования;

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

обновление (при необходимости) пользовательской документа­ции;

обновление плана интеграции ПО.

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

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

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

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

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

Процесс эксплуатации.

Он охватывает действия и задачи оператора - организации, эксплуатирующей систему. Дан­ный процесс включает следующие действия:

1) подготовительную работу;

2) эксплуатационное тестирование;

3) эксплуатацию системы;

4) поддержку пользователей.

Подготовительная работа включает проведение оператором сле­дующих задач:

планирование действий и работ, выполняемых в процессе эксп­луатации, и установку эксплуатационных стандартов;

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

Эксплуатационное тестирование осуществляется для каждой оче­редной редакции программного продукта, после чего она передается в эксплуатацию.

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

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

Процесс сопровождения.

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

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

Процесс сопровождения охватывает следующие действия:

подготовительную работу;

анализ проблем и запросов на модификацию ПО;

модификацию ПО;

проверку и приемку;

перенос ПО в другую среду;

снятие ПО с эксплуатации.

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

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

определение процедур локализации и разрешения проблем, воз­никающих в процессе сопровождения.

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

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

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

утверждение выбранного варианта модификации. Модификация ПО предусматривает определение компонентов ПО,

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

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

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

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

ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ ЖЦ ПО

Процесс документирования.

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

Процесс документирования включает следующие действия:

подготовительную работу;

проектирование и разработку;

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

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

Процесс управления конфигурацией.

Он предполагает применение административных и техни­ческих процедур на всем протяжении ЖЦ ПО для определения со­стояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО

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

Процесс управления конфигурацией включает следующие дей­ствия:

подготовительную работу;

идентификацию конфигурации;

контроль конфигурации;

учет состояния конфигурации;

оценку конфигурации;

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

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

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

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

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

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

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

Процесс обеспечения качества.

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

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

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

подготовительную работу;

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

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

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

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

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

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

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

Процесс верификации.

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

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

Процесс верификации включает следующие действия:

1) подготовительную работу;

2) верификацию.

В процессе верификации проверяются следующие условия:

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

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

соответствие выбранных процессов ЖЦ ПО условиям договора;

адекватность стандартов, процедур и среды разработки процес­сам ЖЦ ПО;

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

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

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

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

корректность интеграции компонентов ПО в систему;

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

Процесс аттестации.

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

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

Процесс аттестации включает следующие действия:

подготовительную работу;

аттестацию.

Процесс совместной оценки.

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

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

Процесс совместной оценки включает следующие действия:

подготовительную работу;

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

техническую оценку.

Процесс аудита.

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

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

Процесс аудита включает следующие действия:

подготовительную работу;

Процесс разрешения проблем.

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

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

1) подготовительную работу;

2) разрешение проблем.

ОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ ЖЦ ПО

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

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

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

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

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

выполнение и контроль;

проверку и оценку;

завершение.

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

Планирование подразумевает выполнение, как минимум, следую­щих задач:

составление графиков выполнения, работ;

оценку затрат;

выделение требуемых ресурсов;

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

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

создание инфраструктуры управления.

Процесс создания инфраструктуры.

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

Процесс создания инфраструктуры включает следующие действия:

подготовительную работу;

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

сопровождение инфраструктуры.

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

Он предусмат­ривает оценку, измерение, контроль и усовершенствование процес­сов ЖЦ ПО. Данный процесс включает следующие действия:

создание процесса;

оценку процесса;

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

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

Процесс обучения.