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

* организацию изготовления бланков лицензий и определение организации - изготовителя этих бланков;

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

* проведение анализа лицензионной деятельности и совместную разработку мер по ее совершенство-ванию.

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

Лицензионные органы субъектов Российской Феде-рации:

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

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

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

В соответствии с Законом "Об участии в междуна-родном информационном обмене" и во исполнение По-становления Правительства Российской Федерации от 03.06.98 № 564 "Об утверждении Положения о лицензи-ровании деятельности по международному информационному обмену" Минсвязи России разработало и внед-рило ряд нормативно-правовых документов, в том числе:

* методические рекомендации по осуществлению лицензионной деятельности по международному информационному обмену лицензионными органа-ми субъектов Российской Федерации;

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

В соответствии с вышеуказанными Законом и по-становлением Правительства Российской Федерации мэром г. Москвы издано распоряжение "О лицензиро-вании деятельности по международному информацион-ному обмену" от 31 декабря 1998 года № 1331-РМ, в ко-тором ставятся конкретные задачи Московской лицен-зионной палате о проведении необходимых организаци-онных мероприятий по созданию (на уровне субъекта Российской Федерации) органа лицензирования деятель-ности по международному информационному обмену.

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

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

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

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

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

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

* разработку Сборника организационно-мето-дических документов по организации и проведению лицензионной деятельности по международному информационному обмену для субъектов Россий-ской Федерации;

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

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

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

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

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

Автоматизированная система по ведению Сводного реестра создаст условия для повышения производитель-ности труда специалистов по лицензированию.

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

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

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

Тема 2. РАЗРАБОТКА ПРОГРАММНЫХ СРЕДСТВ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Понятие ЖЦ ПО. Международный стандарт ISO/IEC 12207: 1995. Основные и вспомогательные процессы ЖЦ ПО. Организация процессов ЖЦ. Связь между процессами.

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

Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207: 1995 “Information Technology - Software Life Cycle Processes” (ISO - International Organization for Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике. Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

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

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

В России существуют стандарты:

ГОСТ 34601 - 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

ГОСТ 34601 - 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

ГОСТ 34601 - 92. «Информационная технология. Виды испытаний автоматизированных систем».

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

В соответствии с ISO/IEC 12207: 1995 все процессы ЖЦ ПО разделены на три группы:

Основные процессы:

· приобретение;

· поставка;

· разработка;

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

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

Вспомогательные процессы:

· документирование;

· управление конфигурацией;

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

· верификация;

· аттестация;

· совместная оценка;

· аудит;

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

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

· управление;

· усовершенствование;

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

· обучение.

Процесс приобретения состоит из действий и задач заказчика:

Действие - инициирование приобретения - включает задачи:

· определение заказчиком своих потребностей в приобретении;

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

· принятие решения относительно приобретения;

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

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

Действие - подготовка заявочных предложений. Заявочные предложения должны содержать:

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

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

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

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

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

Действие - подготовка и корректировка договора - включает задачи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· утверждение выбранного варианта модификации.

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

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

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

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

Вспомогательные процессы ЖЦ ПО

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

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

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

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

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

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

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

Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ ПО. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/IEC 12207-2: 1995 “Information Technology - Software Life Cycle Processes. Part2. Configuration Management for Software”.

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

· подготовительную работу (планирование управления конфигурацией);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· верификацию;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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