66890

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

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-09-01

143 KB

7 чел.

PAGE  1

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

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

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

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

  •  определение потребностей;
  •  исследование и описание основных концепций;
  •  проектирование и разработка;
  •  испытания системы;
  •  создание и производство;
  •  распространение и продажа;
  •  эксплуатация;
  •  сопровождение и мониторинг;
  •  снятие с эксплуатации (утилизация).

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

      Первый класс составляют относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3 –5) специалистов, которые:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     1.2. Роль системотехники в программной инженерии

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

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

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

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

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

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

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

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

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

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

1.3.  Системные основы современных технологий                                  программной инженерии

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

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

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

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

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

Значительные достижения в развитии и применении современных методов и технологии обеспечения крупномасштабных проектов ПС сосредоточены в методологии СММ (Capability Maturity Modelсистема и модель для оценки зрелости) комплекса технологических процессов жизненного цикла ПС, а также в её последующем развитии в CMMI:2003 (см. лекцию 3).  Она основана на формализации и использовании пяти уровней зрелости технологий поддержки ЖЦ ПС, которые также определяют потенциально возможное качество создаваемых на предприятии комплексов программ. Чем выше уровень зрелости, тем выше статус предприятия среди поставщиков, доверие к его продукции, его конкурентоспособность, а также возможное качество программных продуктов. Тем самым при выборе значений характеристик качества ПС  можно в соответствующей степени доверять поставщику и предприятию разработчика, что они смогут полностью реализовать требования заказчика. Эти уровни зрелости характеризуются степенью формализации, адекватностью измерения и документирования процессов и продуктов в ЖЦ ПС, полнотой применения стандартов и инструментальных средств автоматизации работ, наличием и глубиной реализации функций системой качества технологических процессов и их результатов.

Методология обеспечения качества ПС в программной инженерии поддержана рядом методических документов и инструментальных средств, а также формализована комплексом международных стандартов (см. Приложение 1).  Внедрение комплекса требует больших усилий и затрат, что ограничило его массовое использование для относительно простых и средней сложности проектов. Концептуальные и организационные основы административного управления жизненным циклом и качеством ПС в системе СММ, а также CMMI:2003, определены в восьми базовых принципах, которые декларированы в стандартах ISO 9000:2000  и ISO 15504:1-9.

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

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

         Принцип 3 Вовлечение персонала. “Люди составляют сущность предприятия на всех уровнях, и их полноценное участие в деятельности способствует применению их способностей на благо целей предприятия”.

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

Принцип 5  Системный подход к административному управлению. “Выявление и понимание задач и административное управление системой взаимосвязанных процессов для заданной стратегической цели, повышает эффективность и результативность предприятия”.

Принцип 6  Постоянное усовершенствование. “Непрерывное усовершенствование процессов и повышение качества продукции должно быть постоянной стратегической целью предприятия и его специалистов”.

         Принцип  7  Подход к принятию решений основанный на фактах.  “Эффективные решения должны базироваться на анализе только реальных данных и достоверной информации”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основой сертификации должны быть детальные и эффективные Программы и методики испытаний комплексов программ на соответствие требованиям заказчиков, специально разработанные тестовые задачи и генераторы для их формирования, а также высокая квалификация и авторитет испытателей. Применение на предприятиях-разработчиках программных продуктов, сертифицированных систем качества и профилей международных стандартов на базе требований ISO 9001:2000 и/или CMMI:2003, гарантирует высокое, устойчивое управление качеством процессов и продуктов их жизненного цикла, а также позволяет во многих случаях облегчать сертификацию конечного программного продукта. Поэтому заказчики сложных программных проектов должны выбирать подрядчиков-исполнителей, имеющих сертификаты, удостоверяющие применение ими систем гарантирования качества на основе адаптированных профилей международных стандартов.

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

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


 

А также другие работы, которые могут Вас заинтересовать

62711. There’s a good film on at 4.30 55.53 KB
  Почитайте вместе, потренируйте, обращаясь к детям “Hi, Fox!” (тот, у кого лиса – должен отреагировать) и, убедившись, что реплики достаточно усвоены, вызывайте к доске рассказывать диалог, попросив изменять время на своё.
62712. Musikkunst 25.48 KB
  Es gibt in der Welt eine Sprache, die jeder versteht, unabhängig von seiner Nationalität und Bildung. Das ist Musik. Sie macht unser Leben schön und interessant. Die Musik ruft unsere gute Gefühle hervor.
62713. Окружающий мир 85.91 KB
  Цели урока: Сформировать новые понятия: исторические источники и их виды археологические раскопки история отечество. Развивать интерес к познанию прошлого своих предков умение видеть в настоящем опыт предыдущих поколений...
62714. Ценность рода и семьи 20.09 KB
  Цель урока: Формировать уважительное отношение к семье семейным ценностям; Задачи: Развивать речь мышление память умение работать с текстом творческие способности; Формировать уважительное отношение к семье семейным ценностям; Познакомить учащихся с понятиями семья род традиция...
62717. Народні традиції, родинні свята і здоров’я. «Як влаштувати веселе свято?» 253.63 KB
  Мета: навчити дітей розуміти значення народних традицій для здоровя; формувати прагнення дбати про власне здоровя; розвивати мислення память; виховувати повагу до народних традицій. Діти скажіть мені коли ви смієтесь найчастіше...