Стандатризация программных средств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· договорный аспект;

· аспект управления;

· аспект эксплуатации;

· инженерный аспект;

· аспект поддержки.

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

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

Понятие модели ЖЦ ПО (каскадная, спиральная). Стадии: формирование требований к ПО; проектирование; реализация; тестирование; ввод в действие; эксплуатация и сопровождение; снятие с эксплуатации. Подход RAD. Модели качества процессов проектирования.

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

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

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

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

1. Формирование требований к ПО.

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

3. Реализация.

4. Тестирование.

5. Ввод в действие.

6. Эксплуатация и сопровождение.

7. Снятие с эксплуатации.

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

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

· определение целей разработки;

· предварительная экономическая оценка проекта;

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

· создание и обучение совместной рабочей группы.

Проведение обследования деятельности автоматизируемого объекта (организации), в рамках которого осуществляются:

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

· определение структуры организации;

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

· анализ распределения функций по подразделениям и сотрудникам;

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

· анализ существующих средств автоматизации деятельности организации.

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

· модели “AS-IS” («как есть»), отражающей существующее на момент обследования положение дел в организации и позволяющее понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

· модели “TO-BE” («как должно быть»), отражающей представление о новых технологиях работы организации.

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

Переход от модели “AS-IS” к модели “TO-BE” может выполняться двумя способами:

· совершенствованием существующих технологий на основе оценки их эффективности;

· радикальным изменением технологий и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов).

Построенные модели имеют самостоятельное практическое значение. Например, модель “AS-IS” позволяет выявить узкие места в существующих технологиях и предлагать рекомендации по решению проблем независимо от того, предполагается на данном этапе дальнейшая разработка ЭИС или нет. Кроме того, модель облегчает обучение сотрудников конкретным направлениям деятельности организации за счет использования наглядных диаграмм (известно, что «одна картинка стоит тысячи слов»).

Стадия проектирования включает этапы:

Разработка системного проекта. На этом этапе дается ответ на вопрос: «Что должна делать будущая система?», а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели “TO-BE” . Документальным результатом является техническое задание.

Разработка технического проекта. На этом этапе на основе системного проекта осуществляется собственно проектирование системы, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня.

К настоящему времени наибольшее распространение получили следующие две модели ЖЦ ПО: каскадная (1970-1985) и спиральная (1986-1990).

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

Рис.1. Каскадная модель

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

Преимущества применения каскадного способа:

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

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

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

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

Рис. 2. Итерационный процесс создания программного обеспечения

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

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

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

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

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

Для преодоления перечисленных проблем в середине 80-х годов была предложена спиральная модель ЖЦ (рис.3). Ее принципиальной особенностью является следующее: прикладное ПО создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, степень полноты и точности понимания требований к системе, а также целесообразность прекращения проекта. Спиральная модель избавляет пользователей и разработчиков от необходимости точного и полного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

1. Планирование -- определение целей, вариантов и ограничений.

2. Анализ риска -- анализ вариантов и распознавание/выбор риска.

3. Конструирование -- разработка продукта следующего уровня.

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

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

Планирование Анализ риска

Рис. 3. Спиральная модель: 1 - начальный сбор требований и планирование проекта; 2 - та же работа, но на основе рекомендаций заказчика; 3 - анализ риска на основе начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход к комплексной системе; б - начальный макет системы; 7 - следующий уровень макета; 8 - сконструированная система; 9 - оценивание заказчиком.

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

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

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

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

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

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

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

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

· включает шаг системного подхода в итерационную структуру разработки;

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

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

· новизна (отсутствует достаточная статистика эффективности модели);

· повышенные требования к заказчику;

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

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). RAD предусматривает наличие трех составляющих:

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

· короткого, но тщательного проработанного производственного графика (до 3 месяцев);

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

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

ЖЦ ПО в соответствии с подходом RAD включает 4 стадии:

1. Анализ и планирование требований предусматривает действия:

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

· выделение наиболее приоритетных функций, требующих проработки в первую очередь;

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

Кроме того, на данной стадии реализуются следующие задачи:

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

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

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

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

· более детально рассматриваются процессы системы;

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

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

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

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

· входной элемент приложения (входной документ или экранная форма);

· выходной элемент приложения (отчет, документ, экранная форма)

· запрос (пара «вопрос/ответ»);

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

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

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

Результатом данной стадии должно быть:

· общая информационная модель системы;

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

· точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранных форм, отчетов, диалогов.

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

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

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

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

· Осуществляется анализ использования данных и определяется необходимость их распределения.

· Производится физическое проектирование базы данных

· Формируются требования к аппаратным ресурсам.

· Устанавливаются способы увеличения производительности.

· Завершается разработка документации проекта.

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

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

· разрабатывается совершенно новая система;

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

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

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

Подход RAD не применим для построения сложных расчетных программ, операционных систем.

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

Итак, перечислим основные принципы подхода RAD.

· Разработка приложений итерациями.

· Необязательность полного завершения работ на каждой стадии ЖЦ ПО.

· Обязательность вовлечения пользователей в процесс разработки ЭИС.

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

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

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

· Тестирование и развитие проекта, осуществляемые одновременно с разработкой.

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

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

В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO / IЕС 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model - СММ) Института программной инженерии при американском университете Карнеги-Меллон.

Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IЕС 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IЕС 15504 взята из модели СММ.

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

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

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

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

Рис. 4. Пять уровней зрелости модели СММ

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

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

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

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

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

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

· предотвращения дефектов;

· управления изменениями технологии;

· управления изменениями процесса.

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

Лекция 12. Понятие метода и технологии проектирования ПО

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

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

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

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

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

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

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

Современная технология проектирования должна обеспечивать:

1. Соответствие стандарту ISO/IEC 12207: 1995 (поддержка всех процессов ЖЦ ПО).

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

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

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

5. Независимость получаемых проектных решений от средств реализации ЭИС (СУБД, ОС, языков и систем программирования).

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

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

1. Стандарт проектирования.

2. Стандарт оформления проектной документации.

3. Стандарт интерфейса конечного пользователя с системой.

Стандарт проектирования должен устанавливать:

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8