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

 

Лекция 3.

 

Тема лекции: «Модели жизненного цикла программного обеспечения».

1. Стандарты в описании жизненного цикла программных средств.

2. Модели жизненного цикла.

3. Проблемы и задачи проектирования программного обеспечения.

 

1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММЫ.

1.1. Понятие технологии разработки программы.

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

Рассмотрим сначала основные термины и определения.

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

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

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

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

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

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

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

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

1.2. Стандарты описания жизненного цикла программных средств.

 

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

 

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

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

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

 

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

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

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

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

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

 

Одно из центральных мест здесь занимает национальный стандарт РФ ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»  (Утв. приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2010 г. N 631-ст). Дата введения - 1 марта 2012 г. (взамен ГОСТ Р ИСО/МЭК 12207-99).

 

 

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

 

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

 

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

 

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

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

 

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

 

Настоящий стандарт устанавливает следующие ОТНОШЕНИЯ МЕЖДУ СИСТЕМАМИ И ПРОГРАММНЫМИ СРЕДСТВАМИ.

 

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

 

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

 

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

 

Настоящий стандарт устанавливает следующие КРИТЕРИИ ДЛЯ ПРОЦЕССОВ.

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

- цель - описывает конечные цели выполнения процесса;

 

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

 

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

 

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

 

 

Настоящий стандарт устанавливает следующие ОБЩИЕ ХАРАКТЕРИСТИКИ ПРОЦЕССОВ (подраздел 5.1.10 Общие характеристики процессов).

 

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

 

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

 

Настоящий стандарт устанавливает принцип:  ДЕКОМПОЗИЦИЯ ПРОЦЕССОВ (подраздел 5.1.11 Декомпозиция процессов).

 

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

 

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

 

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

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

 

В подразделе «5.1.12 Модели и стадии жизненного цикла» даны следующие характеристики моделей и стадий жизненного цикла.

 

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

 

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

 

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

 

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

 

В подразделе «5.2.1 Категории процессов жизненного цикла» указаны семь групп процессов.

 

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

 

a) процессы соглашения - два процесса (см. 5.2.2.1.1 и 6.1);

 

b) процессы организационного обеспечения проекта - пять процессов (см. 5.2.2.1.2 и 6.2);

 

c) процессы проекта - семь процессов (см. 5.2.2.1.3 и 6.3);

 

d) технические процессы - одиннадцать процессов (см. 5.2.2.1.4 и 6.4);

 

 

e) процессы реализации программных средств - семь процессов (см. 5.2.2.2.1 и 7.1);

 

f) процессы поддержки программных средств - восемь процессов (см. 5.2.2.2.2 и 7.2);

 

g) процессы повторного применения программных средств - три процесса (см. 5.2.2.2.3 и 7.3).

 

 

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

 

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

 

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

 

РАЗДЕЛ 7 СОДЕРЖИТ СПЕЦИАЛЬНЫЕ ПРОЦЕССЫ ПРОГРАММНЫХ СРЕДСТВ ДЛЯ ИСПОЛЬЗОВАНИЯ В РЕАЛИЗАЦИИ ПРОГРАММНОГО ПРОДУКТА ИЛИ УСЛУГИ, КОТОРЫЕ ЯВЛЯЮТСЯ НЕКОТОРЫМ ЭЛЕМЕНТОМ БОЛЕЕ КРУПНОЙ СИСТЕМЫ.

 

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

 

1)   основные;

1)

2)   вспомогательные;

 

3)   организационные.

3)

 

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

 

ВСПОМОГАТЕЛЬНЫЕ. Это процессы, предназначенные для поддержки основных процессов. Сами по себе эти процессы организации не нужны - только в связи с основными процессами, которые они обслуживают. Несколько процессов из этой группы связано с управлением качеством.

 

ОРГАНИЗАЦИОННЫЕ. Это общекорпоративные процессы, такие как «Обучение» или «Управление». Эти процессы существуют в организации независимо от того, как организовано производство и как устроены вспомогательные процессы.

 

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

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

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

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

 

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

 

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

 

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

 

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

 

Чрезвычайно важный раздел стандарта - Приложение А «Процесс адаптации». Процессом адаптации называется «процесс применения положений настоящего стандарта к условиям реализации конкретного программного проекта». Описан этот процесс в том же стиле, что и остальные процессы. Адаптация - обязательная деятельность в ходе применения стандарта на практике. Наличие процесса адаптации подразумевает, что ГОСТ Р ИСО/МЭК 12207 сначала внедряется в организации в целом, а затем для каждого проекта из него «выкраивается» подмножество необходимых процессов. О том, как организовать внедрение стандарта в организации, ГОСТ Р ИСО/МЭК 12207 умалчивает.

 

ПРОЦЕССЫ ПРОЕКТА.

 

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

 

Существуют две категории процессов проекта.

 

ПРОЦЕССЫ МЕНЕДЖМЕНТА ПРОЕКТА используются для планирования, выполнения, оценки и управления продвижением проекта.

 

ПРОЦЕССЫ ПОДДЕРЖКИ ПРОЕКТА обеспечивают выполнение специализированных целей менеджмента. Обе категории процессов проекта описаны ниже.

 

 

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

 

a) процесс планирования проекта;

 

b) процесс управления и оценки проекта.

 

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

 

a) процесс менеджмента решений;

 

b) процесс менеджмента рисков;

 

c) процесс менеджмента конфигурации;

 

d) процесс менеджмента информации;

 

e) процесс измерений.

 

ТЕХНИЧЕСКИЕ ПРОЦЕССЫ определяют деятельность, которая дает возможность реализовывать организационные и проектные функции для оптимизации пользы и снижения рисков, являющихся следствием технических решений и действий. Эта деятельность обеспечивает возможность продуктам и услугам обладать такими свойствами, как своевременность и доступность, результативность затрат, а также функциональность, безотказность, ремонтопригодность, продуктивность, приспособленность к применению, и другими качественными характеристиками, требуемыми приобретающими и поддерживающими организациями. Она также предоставляет возможность продуктам и услугам соответствовать ожиданиям или требованиям гражданского законодательства, включая факторы здоровья, безопасности, защищенности и факторы, относящиеся к окружающей среде.

 

Технические процессы состоят из следующих процессов:

 

a)      определение требований правообладателей;

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

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

d)     процесс реализации (разработанный в разделе 7 настоящего стандарта как процесса реализации программных средств);

e)      процесс комплексирования системы;

f)       процесс квалификационного тестирования системы;

g)      процесс инсталляции программных средств;

h)      процесс поддержки приемки программных средств;

i)        процесс функционирования программных средств;

j)       процесс сопровождения программных средств;

k)     процесс изъятия из обращения программных средств .

 

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

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

 

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

 

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

 

а) процесс анализа требований к программным средствам;

 

b) процесс проектирования архитектуры программных средств;

 

c) процесс детального проектирования программных средств;

 

d) процесс конструирования программных средств;

 

e) процесс комплексирования программных средств;

 

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

 

ПРОЦЕССЫ ПОДДЕРЖКИ ПРОГРАММНЫХ СРЕДСТВ предусматривают специально сфокусированную совокупность действий, направленных на выполнение специализированного программного процесса. Любой поддерживающий процесс помогает процессу реализации программных средств как единое целое с обособленной целью, внося вклад в успех и качество программного проекта. Существует восемь таких процессов:

 

a) процесс менеджмента документации программных средств;

 

b) процесс менеджмента конфигурации программных средств;

 

с) процесс обеспечения гарантии качества программных средств;

 

d) процесс верификации программных средств;

 

e) процесс валидации программных средств;

 

f) процесс ревизии программных средств;

 

g) процесс аудита программных средств;

 

h) процесс решения проблем в программных средствах.

 

Группа ПРОЦЕССОВ ПОВТОРНОГО ПРИМЕНЕНИЯ ПРОГРАММНЫХ СРЕДСТВ состоит из трех процессов, которые поддерживают возможности организации использовать повторно составные части программных средств за границами проекта. Эти процессы уникальны, поскольку, в соответствии с их природой, они используются вне границ какого-либо конкретного проекта.

 

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

 

a) процесс проектирования доменов;

 

b) процесс менеджмента повторного применения активов;

 

c) процесс менеджмента повторного применения программ.

 

 

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

 

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

1.3. Основа разработки программного обеспечения.

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

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

1. Техническое задание (ТЗ):

постановка задачи;

выбор критериев эффективности;

проведение предварительных научно-исследовательских работ (НИР);

разработка ТЗ.

2. Эскизный проект:

структура входных и выходных данных;

уточнение методов решения;

общий алгоритм;

разработка документации эскизного проекта.

3. Технический проект:

уточнение структуры входных и выходных данных;

разработка алгоритмов;

формы данных;

семантика и синтаксис языка;

структура программы;

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

план работ.

4. Рабочий проект:

программирование и отладка;

разработка документов;

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

корректировка программы и документов по итогам

испытаний.

5. Внедрение:

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

оформление акта;

передача в Фонд алгоритмов и программ (ФАП).

 

2. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА.

2.1. Основные модели жизненного цикла ПО.

 

Исторически в ходе развития теории проектирования  программного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ.

Первой по времени появления и самой распространенной явилась каскадная модель (рисунок 1).

 

 

Рисунок 1. Каскадная модель жизненного цикла ПО.

Каскадная модель характеризуется следующими основными особенностями:

- последовательным выполнением входящих в ее состав  этапов;

- окончанием каждого предыдущего этапа до начала  последующего;

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

- отсутствием (или определенным ограничением) возврата к предыдущим этапам;

-  наличием результата только в конце разработки.

 

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

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

 

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

 

Рисунок 2. Итерационная модель жизненного цикла ПО.

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

 

Третья модель ЖЦ ПО – спиральная (spiral) модель (рисунок 3) – поддерживает итерации поэтапной модели, но  особое внимание уделяется начальным этапам проектирования:  анализу требований, проектированию спецификаций,  предварительному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания  фрагмента или версии ПО, уточняются цели и требования к  программному обеспечению, оценивается качество разработанного фрагмента или версии и планируются работы следующей стадии разработки (витка). Таким образом, углубляются и  конкретизируются все детали проектируемого ПО. И в результате получается продукт, который удовлетворяет всем требованиям заказчика.

 

Рисунок 3. Спиральная модель жизненного цикла ПО.

 

Rational Objectory Process (ROP) – модель жизненного цикла (методология объектно-ориентированного программирования)

 

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

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

- модель жизненного цикла;

- действия;

- нотация языка.

Жизненный цикл UML (Rational Objectory Process)

Фирма Rational Software, разработавшая язык UML,  предложила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого  перевода не имеет, так как rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразование аналогично слову repository (накопитель).

Перечислим основные свойства ROP-технологии.

1)   Rational Objectory Process — итеративный процесс, в течение которого происходит последовательное уточнение результатов.

 

2)   Rational Objectory Process направлен,  именно,  на создание  моделей, а не на разработку каких-либо других элементов проекта (например, текстовых документов).

2)

3)   Действия Rational Objectory Process определяются в первую очередь блоками использования (use case) (рисунок 4).

 

4)   Rational Objectory Process разбит на циклы, каждый из  которых, в свою очередь, состоит из четырех фаз:

4)

- начальная стадия (Inception);

- разработка (Elaboration);

- конструирование (Construction);

- ввод в эксплуатацию (Transition).

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

 

Каждая стадия завершается в четко определенной  контрольной точке (milestone). В этот момент времени должны  достигаться важные результаты и приниматься критически важные  решения о дальнейшей разработке.

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

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

Рисунок 4. Модель ROP.

 

Окончанием начального этапа могут служить следующие  результаты:

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

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

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

- начальный бизнес-план;

- план проекта, отражающий стадии и итерации;

- один или несколько прототипов.

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

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

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

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

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

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

- идентификация всех наиболее серьезных рисков и  возможности их ликвидации.

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

При этом необходимо отметить следующее:

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

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

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

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

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

- параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

- оптимизацию производительности;

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

 

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

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

Слова «жизненный цикл системы» или «жизненный цикл программного средства» часто появляются в статьях и звучат в разговорах разработчиков, по крайней мере руководителей проектов и подразделений. Всем понятно, что относятся они к тому, что и в какой последовательности должно делаться при создании и эксплуатации систем. Но прежде чем две организации или два специалиста договорятся о том, что конкретно входит или не входит в ЖЦ, проходит значительное время. А позже вполне может обнаружиться, что эти двое (две «стороны») все-таки по-разному понимают, какие работы будут входить в ЖЦ, а какие — нет, какие проверки будут планироваться, когда и т. д. Естественно, общие принципы организации работ описаны давно, но что делать сторонам в конкретном проекте – это каждый раз приходится решать заново.

3. ПРОБЛЕМЫ И ЗАДАЧИ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

 

3.1. Основные понятия и положения технологии разработки программных средств.

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

1) проблемы рационального структурного построения ПС, включающие:

– оптимизацию структуры ПС по критерию максимального использования ресурсов ЭВМ;

– контроль вычислительного процесса и обеспечение надёжности ПС;

– обеспечение простой корректировки ПС и др.;

2) проблемы технологии разработки ПС, включающие:

– разработку моделей алгоритмов и др. компонентов ИС;

– автоматизацию программирования на основе унификации типовых компонент программ;

– обеспечение отладки и испытаний программ;

– автоматизацию изготовления документации и др.;

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

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

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

– стандартизацию методов и требований к обеспечению и измерению качества ПС;

– стандартизацию языков программирования.

3.2. Этапы жизненного цикла программных средств.

По длительности ЖЦ ПС можно разделить на 2 класса (см.: [5]):

а) с малым, б) большим временем жизни.

 

ПС с малым временем ЖЦ (до 3 лет) и объёмом 1 – 10 тысяч команд разрабатываются обычно в НИИ и вузах одним специалистом.

ПС с большим временем ЖЦ (10 – 20 лет, из которых 70 – 90 % приходится на эксплуатацию и сопровождение), с объёмом 10 – 1000 тысяч команд разрабатываются большими коллективами специалистов и создаются на основе промышленного регламентированного проектирования. ЖЦ таких программ включает в себя этапы: системный анализ, проектирование, эксплуатацию, сопровождение. Наиболее специфическим, трудноформализуемым и тесно связанным с функциональным назначением является этап системного анализа, на котором формируются назначение и основные показатели качества ПС.

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

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

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

3.3. Виды поддержки и стадии этапа проектирования.

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

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

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

Процесс разработки ПС делится на стадии: техническое проектирование и рабочее проектирование.

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

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

Все виды работ и задач, выполняемых на этих этапах, сгруппированы для оценки трудоёмкости разработки ПС в 5 групп:

 

1)   анализ разработки,

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

3)   программирование,

4)   тестирование,

5)   внедрение.

 

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

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

Статический анализ (СА) – это процесс анализа исходного текста программы без её выполнения на ЭВМ [5]. СА программ проводится:

 

 – для проверки модульной структуры программного средства, а также логической структуры отдельных модулей и сравнения этих структур с приведенными в программной документации;

 

– подготовки исходных данных для проведения динамического анализа ПС и разработки плана тестирования ПС;

– оценки конструктивных характеристик программы, степени простоты модификации и сопровождения программы;

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

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

– экспертизы идентичности программ при установлении авторства и разрешении правовых споров;

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

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

СТАТИЧЕСКИЙ АНАЛИЗ ПРОГРАММНОГО СРЕДСТВА ПРЕДУСМАТРИВАЕТ ПОЛУЧЕНИЕ СЛЕДУЮЩИХ ХАРАКТЕРИСТИК (ГРАФИЧЕСКИХ И МЕТРИЧЕСКИХ):

 

- модульная структура ПС;

 

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

 

- характеристика текста программы.

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

 

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

Характеристики текста программ включают в себя: статистические данные о комментированности программы и текстовые метрики Холстеда.

Граф вызовов – это ориентированный граф, в котором вершины – модули ПС, а рёбра ориентированы от вызывающего модуля к вызываемому.

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

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

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

Путь тестирования – это маршрут в графе управления программного модуля, начальная вершина которого является входной вершиной графа, а конечная вершина − выходной вершиной графа.

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

Кроме этого СА предусматривает определение ряда количественных характеристик, таких как иерархическая и структурная сложность, тестируемость и др.

Иерархическая сложность: I = N / L, где N – количество вершин в графе вызовов модулей; L – количество уровней.

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

Структурная сложность: S = D / N, где D – количество ребер в графе вызовов модулей; N – количество вершин.

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

 

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

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

 

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

[1] Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. Учебное пособие/ Под ред. О.С. Разумова. М.: Финансы и статистика, 2005. – 288 с., ил.

 

[2] Брауде Э. Технология разработки программного обеспечения. СПб.: Питер, 2004. – 655 с.: ил.

[3] Вигерс К. Разработка требований к программному обеспечению. М.: ИТД «Русская Редакция», 2004. – 576.: ил. 

 

[4] Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения. Учебное пособие/ Под ред. Л.Г. Гагариной. – М.: ИД «Форум»: ИНФРА-М, 2008. – 400 с.: ил. – (Высшее образование).

 

[5] Котов С.Л., Палюх Б.В., Федченко С.Л. Разработка, стандартизация и сертификация программных средств и информационных технологий и систем. Учебное пособие. Тверь.: ТГТУ, 2006. – 104 с.