Эскорт-услуги в Москве от Queens Palace


Архив

Вы сейчас просматриваете архивы рубрики «Технологии разработки программных продуктов».

Мар

30

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

Автор: admin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методология обеспечения качества ПС в программной инженерии поддержана рядом методических документов и инструментальных средств, а также формализована комплексом международных стандартов (см. Приложение 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, гарантирует высокое, устойчивое управление качеством процессов и продуктов их жизненного цикла, а также позволяет во многих случаях облегчать сертификацию конечного программного продукта. Поэтому заказчики сложных программных проектов должны выбирать подрядчиков-исполнителей, имеющих сертификаты, удостоверяющие применение ими систем гарантирования качества на основе адаптированных профилей международных стандартов.

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

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

Мар

30

Технологии коллективной разработки

Автор: admin

1. Авторская разработка

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

Этот принцип  был достаточно  широко  распространен  в  70 80-е  годы ХХ века. Сейчас он применяется редко. Примерами авторских разработок являются операционная система Диспак (В. Ф. Тюрин), текстовый редактор Лексикон (Е. М. Веселов), трансляторы с языков Algol – 68 (П. Наур) и Pascal (H. Вирт).

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

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

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

Об интеллектуальных работниках

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

Авторская работка может выигрывать по производительности в 30 и более раз у коллективной разработки, что достигается за счет:

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

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

Объем программного продукта, выполненного методом авторской разработки, в 5 20 раз меньше по сравнению с индустриальными аналогами.

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

О применении авторской разработки

В наибольшей степени авторская разработка в наши дни применяется при создании условно-бесплатных программных продуктов (shareware).

2. Коллективная разработка

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

Технические командные роли

Иерархическая модель

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

Матричная модель (равноправные соисполнители)

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

Примерный состав такой бригады разработчиков, а именно:

-        инженеры-разработчики  (специалисты по инженерии программирова­ния и программисты);

-        технические писатели;

-        инженеры тестирования;

-        инженеры качества;

-        специалисты по сопровождению продукта;

-        специалисты по продажам продукта.

Тип работы определяет содержание и природу выполняемой работы. Приведем список типов работ и областей специализации на основе классификации Сью Конгер (Sue Conger).

Разработка приложений (Application Development):

•     программист (Programmer);

•     специалист по инженерии программирования (Software Design Engi­neer);

•     специалист по инженерии знаний (Knowledge Engineer).

Разработка документации (Documentation):

•     технический писатель (Technical Writer). Тестирование продукта (Testing):

•     инженер тестирования (Tester);

•     инженер по разработке тестов (Test Design Engineer). Продажи (Sales):

•     консультант по продукту (Product Support);

•     специалист по маркетингу (Product Marketing).

Управление разработкой (Management):

•      менеджер проекта (Project Manager);

•     менеджер информационных систем (IT Manager).

Разработка аппаратуры (Hardware Design):

•     разработчик аппаратуры (Hardware Design Engineer).

Работа с приложениями (Application Support):

•     специалист по приложениям (Application Specialist);

•     администратор данных (Data Administrator);

•     администратор базы данных (Database Administrator).

Техническая поддержка (Technical Specialists):

•     системный администратор (System Administrator);

•     сетевой администратор (Network Administrator);

•     администратор коммуникаций (Communications Administrator).

Системное интегрирование (System Integration):

•     системный интегратор (System Integrator).

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

Бригада главного программиста

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

Основные члены бригады выполняют следующие функции.

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

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

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

Редактор. Фактически, это технический писатель. Его задача — критиче­ски переработать черновики документации, созданные главным про­граммистом, снабдить их ссылками и библиографией и обеспечить пуб­ликацию или помещение в Интернете.

Языковед. Эксперт в тонкостях языков программирования. Может найти эффективные способы использования языка для решения сложных за­дач. Обычно работает с несколькими бригадами.

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

Отладчик. Разработчик тестов и организатор тестирования программно­го продукта.

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

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

Программирование в парах

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

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

-        Второй партнер решает стратегические задачи:

•     будет ли работать используемый подход в целом;

•     какими могут быть дополнительные тестовые случаи;

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

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

Ядерная модель

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

Психологические командные роли

Кроме технических командных ролей следует разбираться и в психологических ролях. С одной стороны, важно понимать характеристики конкретно людей. Это может очень пригодиться, когда надо иметь дело с определенным человеком, и именно для него придумывать способы мотивации, характеристики  должны  определяться  профессиональным  психологом, правило, на основе интерпретации тестов. Одним из традиционных тестов является Миннесотский стандартный многофакторный метод исследования личности — СМИЛ (Minnesota Multiphasic Personality Inventory — MMPI). По результатам тестирования можно прогнозировать и диагностировать или иные возможные проблемы или хотя бы области проблем. С другой стороны, важны характеристики людей в отношениях с внешним миром. Такая типология может быть полезной, когда надо решить, кто с какой работой лучше справится. Далее мы рассмотрим два примера командных характеристик.

Ключевые проектные роли

Томсет (Rob Thomsett) предложил восемь ключевых ролей проекте.

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

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

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

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

Исполнитель. Работник, собственно занимающийся написанием кода. Как правило, он не обладает широтой кругозора.

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

Дипломат. Поддерживает силу духа в участниках проекта. Оказывает им помощь в трудных положениях. Пытается улучшить взаимоотношения в команде.

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

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

Соционические роли

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

Методика основана на выделении концентрированно выраженных и легко узнаваемых типов личности. Основы методики созданы швейцарским психологом Карлом Густавом Юнгом (Carl G. Jung), а развита и усовершенствована    она    была    в    работах    литовской   исследовательницы    Ayшры Аугустинавичуте.

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

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

-        Логика: деловая (экстраверт), отношений (интроверт).

-        Этика: эмоций (экстраверт), отношений (интроверт).

-        Сенсорика: волевая (экстраверт), ощущений (интроверт).

-        Интуиция: возможностей (экстраверт), времени (интроверт).

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

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

-        Интуитивно-логический   экстраверт —   впередсмотрящий,   импульсивный стратег, склонный к синтезу (характерный представитель типа Александр Суворов).

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

-        Интуитивно-логический интроверт — критик, стратег, генератор новых алгоритмов, знаток динамических структур (характерный представитель типа — Оноре де Бальзак).

-        Логико-интуитивный экстраверт — активный инициатор, изобретатель и рационализатор (характерный представитель типа — Джек Лондон).

Типы совместной деятельности

Коллективная разработка предполагает большое количество различных действий, причем степень совместной деятельности может существенно изменяться от одного действия к другому. Можно выделить четыре типа совместной деятельности [Robillard, Robillard 2000].

Мандатная деятельность, обычно представленная формальными собра­ниями, проводимыми на регулярной основе. Обычно собрания плани­руются заранее, а присутствие на них обязательно. Статистика показы­вает, что программисты проводят около 4% своего рабочего времени на собраниях.

Созываемая деятельность, которая имеет место в случае намерения двух или более программистов собраться вместе для решения некоторого технического вопроса. Такие собрания обычно не планируются заранее, и в них участвуют только действительно заинтересованные в решении проблемы программисты. На эту деятельность уходит около 14% рабоче­го времени.

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

Индивидуальная деятельность, когда программист работает над задачей, которая не выполняется в то же самое время никаким другим програм­мистом, и поэтому маловероятно его взаимодействие по этому предмету с любыми другими программистами группы. Эта деятельность занимает также около 41% рабочего времени.

Общинная модель разработки

Идеология общинной (базарной) модели разработки сформулирована в программной статье Эрика Раймонда (Eric Raymond) Собор и Базар. Общинная модель характеризуется тремя основными факторами.

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

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

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

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

-        Каждая хорошая программа начинается с энтузиазма разработчика.

-        Хорошие программисты знают, что можно написать, а великие — можно переписать.

-        При правильном отношении интересная проблема найдет вас сама.

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

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

-        Иногда использовать идеи пользователей лучше, чем свои.

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

Отступление об оффшорном программировании

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

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

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

-        Полная разработка — выполнение проекта по полной разработке и внедрению системы.

Довольно широкое распространение оффшорного программирования в настоящее  время  обусловлено  состоянием  мирового  рынка заказного  программного обеспечения. По очень приблизительным данным разработкой программного обеспечения в мире занято от 7 до 20 миллионов человек.

В России — от 5 до 10 тысяч. В мире существует огромный неудовлетворенный спрос на услуги профессионального программирования (например, в США дефицит профессиональных программистов составил в 2003 году около 1,5 миллионов). Следовательно, для некоторых компаний передача части работ исполнителям в другой стране обусловлена естественной необходимостью.

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

-        Оплата профессионалов ниже, чем в стране-заказчике.

-        Присутствуют высокие стандарты образования и доступны технические эксперты.

-        Доступны передовые технологии, повышение технической квалифика­ции.

Легко видеть, основные страны, удовлетворяющие данным условиям, — Россия, Индия, Китай. Среди лидеров оффшорного программирования уже находятся Уругвай и Израиль.

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

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

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

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

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

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

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

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

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

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

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

Мар

30

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

Автор: admin

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

Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.

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

MSF состоит из двух моделей:

  • модель проектной группы;
  • модель процессов,

и трех дисциплин:

  • управление проектами;
  • управление рисками;
  • управление подготовкой.

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

  • Управление программой
  • Разработка
  • Тестирование
  • Управление выпуском
  • Удовлетворение потребителя
  • Управление продуктом

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

Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF Microsoft Visual Studio 2005 Team Edition. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы.

В состав Visual Studio Team Edition входит специальная редакция для тестировщиков Team Edition for Software Testers. Материалы семинарских занятий по данному курсу ориентированы на эту среду разработки, в то время как лекционные материалы ориентированы на изложение общих принципов и методик тестирования.

Rational Unified Process это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

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

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

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

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

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

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

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

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

XP ориентирована на:

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

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

Основными практиками XP являются:

  • Планирование процесса
  • Частые релизы
  • Метафора системы
  • Простая архитектура
  • Тестирование
  • Рефакторинг
  • Парное программирование
  • Коллективное владение кодом
  • Частая интеграция
  • 40-часовая рабочая неделя
  • Стандарты кодирования
  • Тесное взаимодействие с заказчиком

Сравнение технологий MSF, RUP и XP

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

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

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

Мар

30

CASE-технологии.

Автор: admin

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

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

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

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

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

Но рано или поздно должны были появиться специализированные программно-технологические средства для разработки проектов, в частности, основанных на информатизации. Ими стали средства, реализующие CASE-технологию создания и сопровождения информационных систем. Термин CASE (Computer-Aided Software Engineering) сегодня понимается достаточно широко.

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

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

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

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

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

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

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

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

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

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

  • мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
  • интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки информационной системы;
  • использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ПО) содержит следующие компоненты:
  • репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
  • графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели информационной системы;
  • средства разработки приложений, включая языки 4GL и генераторы кодов;
  • средства конфигурационного управления;
  • средства документирования;
  • средства тестирования;
  • средства управления проектом;
  • средства реинжиниринга.

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла информационных систем (toolkit) и полностью интегрированные средства, поддерживающие весь жизненный цикл информационных систем и связанные общим репозиторием. Помимо этого CASE-средства можно классифицировать по применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает:

  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
  • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE).Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
  • средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично в Silverrun;
  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

  • средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
  • средства конфигурационного управления (PVCS (Intersolv));
  • средства тестирования (Quality Works (Segue Software));
  • средства документирования (SoDA (Rational Software)).

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

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

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

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

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

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

• достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;
• внедрение CASE-средств может представлять длительный процесс и не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого руководство организации-пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения;
• отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, что используются в данной организации, может привести к дополнительным трудностям;
• CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми разнообразными средствами, так и проблемами передачи данных и управления от одного средства к другому;
• некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязывает их применение;
• негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Но все же грамотное, продуманное и обоснованное использование CASE-технологии способно принести следующие выгоды:

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

Мар

30

Тестирование программ

Автор: admin

1. Пошаговое и монолитное тестирование.

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

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

Рассмотрим пример:

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

Модуль драйвер, который содержит фиксированные тестовые данные, вызывает тестируемый модуль и отображает выходные результаты.

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

Выводы:

-      Монолитное тестирование требует больших затрат труда.

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

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

-     Монолитный способ применяется чтобы ускорить сроки сдачи программы.

-     При монолитном  - меньше расход машинного времени.

Категории тестов системных испытаний.

1.     Тестирование удобства использования. Сравниваются цели с содержанием пользовательской документации.

2.      Тестирование на предельных объемах.

3.      Тестирование на предельных нагрузках. Означает поступление пикового объема данных в течение короткого интервала времени.

4.     Тестирование удобства эксплуатации:

-        Справка

-       Значимость входных сообщений программы

-       Понятна ли диагностика ошибок

-      Единообразие стиля пользовательских интерфейсов

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

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

5.      Тестирование защиты (от несанкционированного доступа).

6.      Тестирование производительности.

7.      Тестирование требований к памяти.

8.      Тестирование конфигураций оборудования.

9.      Тестирование удобства установки (настройки, инсталляции).

10.  Тестирование надежности.

11.  Тестирование восстановления.

12.  Тестирование удобства обслуживания.

13. Тестирование документации.

14. Тестирование процедур.

15. Выполнение проверки системы непрограммистами.

2. Принципы тестирования.

  1. Тестирование - это процесс выполнения программ с целью обнаружения ошибок.
  2. Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.
  3. Удачным считается тест, который обнаруживает еще не выявленную ошибку.
  4. Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора.
  5. Следует избегать тестирования программы ее автором.
  6. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать также тщательно как для правильных и предусмотренных.
  7. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она того, чего не должна делать.
  8. Тестирование это процесс творческий.

Методы ручного тестирования:

1.      Инспекции исходного текста.

2.    Сквозные просмотры.

3.     Проверка за столом.

Автоматические средства тестирования:

1.    Профилировщик.

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

3.      Компаратор.

4.     Тестовый драйвер.

5.      Пакет подпрограмм, вставляемых в рабочую программу.

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

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

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

Самопроверкой называется проверка результатов тестирования самой тестируемой программой.

3. Средства защиты программ.

Средства защиты программ можно рассматривать в двух направлениях:

1.      Защитное программирование.

2.      Меры предупреждения компьютерных преступлений.

Меры предупреждения компьютерных преступлений можно разделить на 3 группы:

  1. Технические:

-        защита от несанкционированного доступа к системе

-       резервирование особо важных компьютерных подсистем

  1. Организационные:

-        охрана вычислительного центра

-        тщательный подбор персонала

-       выбор места расположения центра

  1. Правовые:

-        разработка норм, устанавливающих ответственность за компьютерные преступления

-       защита авторских прав программиста

-        совершенствование уголовного и гражданского законодательства

Информационная безопасность должна обеспечивать:

1.      Конфиденциальность информации.

2.      Целостность данных.

3.      Доступность для всех авторизованных пользователей.

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

Компьютерные преступления можно условно разделить на группы:

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

2.     Преступления, связанные с вмешательством в работу компьютера:

-        несанкционированный доступ

-        ввод в ПО логических бомб

-        разработка и распространение компьютерных вирусов

-        хищение компьютерной информации

-        подделка компьютерной информации

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

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

Компьютерные вирусы можно разделить на:

1.      Вульгарный. Вирус, написанный единым блоком.

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

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

Мар

30

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

Автор: admin

Все программы по характеру использования и категориям пользователей можно разделить на два класса — утилитарные программы и программные продукты (изделия).

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

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

  • Freeware — бесплатные программы, свободно распространяемые, поддерживаются самим пользователем, который правомочен вносить в них необходимые изменения;
  • Shareware — некоммерческие (условно-бесплатные) программы, которые могут использоваться, как правило, бесплатно. При условии регулярного использования подобных продуктов осуществляется взнос определенной суммы. Ряд производителей использует OEM-программы (Original Equipment Manufacturer), т.е. встроенные программы, устанавливаемые на компьютеры или поставляемые вместе с вычислительной техникой.
  • Trial – программное обеспечение, которое является полнофункциональным в течении определенного времени или количества запусков. Основывается на принципе Try & Buy – попробуй и потом заплати.

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

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

Программные продукты могут создаваться как:

  • индивидуальная разработка под заказ;
  • разработка для массового распространения среди пользователей.

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

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

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

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

Сопровождение программного продукта — поддержка работоспособности программного продукта, переход на его новые версии, внесение изменений, исправление обнаруженных ошибок и т.п.

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

Основными характеристиками программ являются:

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

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

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

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

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

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

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

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

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

В условиях существования рынка программных продуктов важными характеристика­ми являются:

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

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

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

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

Жизненный цикл программного продукта

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

1.                       маркетинг рынка программных средств, спецификация требований к программному продукту;

2.                       проектирование структуры программного продукта;

3.                      программирование (создание программного кода), тестирование, автономная и комплексная отладка программ;

4.                       документирование программного продукта, подготовка эксплуатационной и технологической документации;

5.                       выход на рынок программных средств, распространение программного продукта;

6.                       эксплуатация программного продукта пользователями;

7.                       сопровождение программного продукта;

8.                       снятие программного продукта с продажи, отказ от сопровождения.

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

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

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

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

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

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

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

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

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

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

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

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность жизненного цикла измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства программные продукты.

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

Мар

30

ЭВМ – исполнитель алгоритмов.

Автор: admin

Всякий алгоритм (программа) составляется для конкретного исполнителя в рамках его системы команд. Исполнителем программ для ЭВМ является ЭВМ. Или точнее, комплекс ЭВМ + система программирования (СП). Программист составляет программу на том языке, на который ориентирована СП. Иногда такой комплекс называется виртуальной машиной. Например, компьютер с СП на Бэйсике называют Бэйсик – машиной, с СП на Паскале – Паскаль – машиной и т.п.


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

Независимо от того, на каком языке программирования будет написана программа, алгоритм решения любой задачи на ЭВМ может быть составлен из команд:

  • присваивания;
  • ввода;
  • вывода;
  • обращения к вспомогательному алгоритму;
  • цикла;
  • ветвления.