ВЫБОР НЕОБХОДИМОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применительно к ПС построение профилей стандартов актив­но применяется в международной и национальной стандартиза­ции. В России впервые основы построения и использования про­филей стандартов ЖЦ ПС заложены в базовом стандарте ГОСТ Р ИСО/МЭК 12207. Данный документ введен в действие с 1 июля 2000 г., тесно взаимоувязан с рядом стандартов, принятых ранее, и с некоторыми стандартами, разрабатываемыми в данное время на основе прямого применения стандартов ИСО.

Актуальность стандарта ГОСТ Р ИСО/МЭК 12207 для совре­менных условий настолько высока, что принятие в ISO его исход­ного, международного варианта вскоре вызвало самую положи­тельную оценку российских экспертов и ряд рекомендаций по его использованию в реальных условиях. Была высказана идея исполь­зования стандарта ИСО/МЭК 12207 на ЖЦ ПС в качестве системообразующего для создания моделей ЖЦ на системы в целом, тем более когда разработчик сталкивается с наличием различных типов нормативных документов, которые необходимо или полез­но использовать для организации ЖЦ ПС.

Соответствие проекта стандарту ГОСТ Р ИСО/МЭК 12207 оп­ределяется как реализация в рамках конкретного проекта такой модели ЖЦ ПС, которая построена на основе выбора из данного стандарта соответствующих процессов, работ и задач. Выполнение процесса или работы считается завершенным, если решены все требуемые в них задачи в соответствии с предварительно установ­ленными в договорной документации проекта (договоре или кон­тракте) критериями и требованиями.

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

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

§ процесс заказа — работы заказчика (субъекта, приобретаю­щего систему, ПС или получающего программную услугу);

§ процесс поставки — работы поставщика (субъекта, постав­ляющего систему, ПС или программную услугу заказчику);

§ процесс разработки — работы разработчика (субъекта, проектирующего и разрабатывающего ПС);

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

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

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

процесс документирования — работы по описанию информа­ции, выдаваемой в конкретном процессе ЖЦ;

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

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

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

процесс аттестации — работы соответствующего субъекта (за­казчика, поставщика или независимой стороны) по аттестации (сертификации) конечного продукта проекта;

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

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

процесс решения проблемы — анализ и устранение (решение) проблем (включая обнаруженные несоответствия), независимо от их характера и источника, обнаруженных при реализации проек­та;

• организационные процессы ЖЦ — применяются каким-либо субъектом для создания и реализации основной структуры модели ЖЦ ПС, охватывающей взаимосвязанные процессы и соответству­ющий персонал, а также для постоянного совершенствования дан­ной структуры и входящих в нее процессов. Организационные про­цессы, как правило, являются типовыми независимо от области выполнения конкретных проектов и договоров. Организационные процессы определяют следующее:

процесс управления — основные работы по управлению, вклю­чая управление проектом, при реализации процессов ЖЦ;

процесс создания инфраструктуры — основные работы по со­зданию базовой структуры какого-либо процесса ЖЦ;

процесс усовершенствования — основные работы, выполня­емые субъектом при создании, оценке, контроле и усовершен­ствовании выбранных процессов ЖЦ;

процесс обучения — работы по соответствующему обучению персонала.

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

Для приобретения ПП крупных производителей ПО, таких как корпорация Microsoft, следует обращаться к ее партнерам, через которых она действует во всем мире. Каждый пользователь ПП дол­жен иметь лицензию на него. Лицензия должна быть закуплена для каждого компьютера, на котором установлен или используется загружаемый через сеть ПП. Договор между пользователем и про­изводителем не подписывается: считается, что покупатель прини­мает условия лицензионного соглашения, если он вскрывает дис­трибутив-упаковку с дискетами или компакт-диском. Это так на­зываемая оберточная лицензия, предусмотренная законом «О пра­вовой охране программ для ЭВМ и баз данных» от 23 сентября 1992 г.

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

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

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

Часто хорошие новинки появляются у малоизвестных компа­ний, но через некоторое время лидеры обязательно применяют эти новинки в своих продуктах, так что ставка на лидера и в этих случаях оказывается правильной, поскольку небольшой инкуба­ционный период позволяет определить качество и перспектив­ность нового решения. Примером может служить новая техноло­гия IPswitching, которую компания Ipsilon применила для уско­ренной передачи IP-пакетов через магистрали ATM. Через пол­года компания Cisco разработала аналогичную технологию Tagswitching, внеся в исходную идею некоторые усовершенство­вания. Единственным недостатком ставки на лидеров является бо­лее высокая стоимость их продуктов по сравнению с компаниями второго эшелона.