Перспективы производственной архитектуры
Данная модель является структурной, включает четыре перспективы: бизнес, приложение, информацию и технологию (рис.11.2).
Области
применения
 |
 |
Технология
Рис.11.2. Перспективы производственной архитектуры
Рассматриваемая модель состоит из четырех перспектив: бизнеса, приложения, информации и технологии, которые связаны между собой разными зависимостями и взаимодействиями. Основной задачей этой модели является приспособление производственной архитектуры к бизнес–целям организации путем итерационного, поэтапного выпуска серии последовательных версий, ориентированных на указанные приоритеты, выполнение отдельных проектов для постепенного решения задач и последовательной корректировки производственной архитектуры.
Бизнес–перспектива включает стратегии и планы перехода к лучшему состоянию предприятия, а именно глобальные цели и задачи организации; виды продуктов и услуг организации; бизнес–процессы реализации основных функций организации и связи между ними.
Прикладная перспектива (приложение) включает услуги и сервисы, информацию и функции, которые требуются для связи пользователей, в том числе описание сервисов поддержки процессов в бизнес–перспективе; описание взаимодействий и зависимостей корпоративных приложений; совершенствование существующих и развитие новых приложений бизнес–перспективы.
Информационная перспектива основывается на возможностях организации автоматизировать бизнес–задачи с помощью персональных компьютеров, серверов и др. оборудования; ОС, общесистемных средств и сетевых компонентов; принтеров и другого периферийного оборудования; данных, которые хранятся в БД и документов, таблиц, созданных в процессе работы организации.
Технологическая перспектива включает технологию работы с аппаратным и программным обеспечением для регламентации действий разработчиков по созданию производственной архитектуры в рамках имеющейся среды разработки. Эта перспектива направлена на логическое описание инфраструктуры и системных компонентов, которые необходимы для поддержки прикладной и информационной перспектив (топологии, среды разработки, средств защиты), а также на определение перечня технологических стандартов и сервисов для выполнения задач организации.
Модель проектной группы определяет роли, обязанности каждого участника проекта и распределение между ними ответственности. Эта модель служит для формирования эффективной команды и приведения в соответствие содержания проекта с размером группы и квалификацией участников. Члены проектной группы анализируют планы (разработки, тестирования, эксплуатации, мер безопасности и обучения), выявляют взаимосвязи между ними, создают сводный календарный план, в котором предусматриваются версии проекта и проверку их на функциональность на имеющихся ресурсах. Члены группы выполняют определенную роль по оценки состава проектных решений, рисков и ресурсов и корректировки приоритетов.
Модель процесса разработки ПО определяет организационную структуру процесса и руководство им в течение всего времени жизни проекта. Отличительные особенности модели – поэтапность, итеративность и гибкость. Модель определяет фазы, этапы, виды деятельности и результаты процесса разработки приложения и их связь с моделью проектной группы. Использование этой модели обеспечивает контроль за ходом разработки проекта, минимизацию рисков, повышение качества и сокращение сроков выполнения проекта.
На этапе разработки создаются: код приложения, скрипты установки и конфигурации, окончательная функциональная спецификация, спецификации и сценарии тестирования. Все эти работы выполняют члены проектной группы. Они создают инфраструктуру и документ на конфигурацию.
Инфраструктура предприятия предназначена для выполнения требований клиентов к структуре выпуска продукции, а также проведения анализа рынков для продажи продуктов и т.п.
Задачи инфраструктуры состоят в следующем:
– привлечение клиентов к созданию приложения;
– связь с корпоративной сетью;
– сохранение данных на разных компьютерах, которые расположены на разных территориях предприятия;
– выдача информации о продукте через компьютерную сеть и т.п.
Соответственно этим задачам проводится:
– согласование информационных технологий с целями бизнеса;
– обоснование изменений и соответствующих затрат для планирования будущих инвестиций;
– усовершенствование внутренних и внешних связей между подразделениями для повышения эффективности работы с заказчиками, поставщиками и партнерами и т.п..
Модель управления рисками предназначена для управления рисками проекта. Она определяет порядок и условия реализации упреждающих решений и мер для постоянного выявления наиболее существенных моментов риска и реализации стратегии их устранения. Использование этой модели и ее основных принципов помогает команде сосредоточиться на наиболее важных моментах разработки ПО. Модель управления рисками является основой выявления, планирования и мониторинга рисков.
Выявление состоит в анализе и формулировке имеющихся рисков, причиной которых могут быть неучтенные особенности проекта и среды, в которой будет разрабатываться проект. Выявленные риски классифицируются и составляется база знаний о рисках на уровне предприятия.
Формулировка рисков включает рассмотрение условий возникновение рисков и последствий, которые они вызывают. Устанавливаются причинно–следственные связи рисков, проводится приоритезация рисков, составление плана мониторинга рисков и документа с описанием возможных рисков в проекте, в котором определены меры вероятности возникновения риска, схема оценки типа «почти невозможно», «маловероятно», «возможно» и денежные компенсации за предотвращение рисков.
В плане графике предусматривается мониторинг рисков – своевременное исполнение превентивных мер для снятия появляющихся угроз риска.
Модель процесса проектирования определяет цели и задачи процесса разработки производственной архитектуры с параллельным и итерационным выполнением отдельных работ. Процесс включает три основные фазы разработки – концептуальное, логическое и физическое проектирование. Переход от концептуального проекта к физическому способствует превращению созданного набора сценариев в совокупность компонентов и сервисов, образующих приложение и реализующих требования заказчика и пользователей.
Процесс проектирования – это систематический способ от абстрактных концепций к конкретным техническим решениям. На этапе выработки концепции формируется набор сценариев использования (usage scenarios), в каждом из которых моделируется выполнение операции определенным пользователем системы. Сценарии разбиваются на последовательность действий – примеров использования (use cases), которые необходимо выполнить пользователю для выполнения операции. Существует три уровня процесса проектирования концептуальный, логический и физический. Процесс проектирования заканчивается описанием функциональных спецификаций.
Модель приложения определяет трехуровневую структуру и сценарный метод проектирования и разработки приложения. Применение этой модели обеспечивает наглядность разработки, параллельное выполнение работ на процессах и различные удобства при эксплуатации и развертывании компонентов приложения на компьютерах и в различных серверах.
Таким образом, методология MSF обеспечивает проектирование приложения для предприятия с помощью приведенных принципов, моделей и методов решения задач этого предприятия.
ПИК сохраняется в архиве JAVA
Таким образом, JAVA поддерживает стандартные механизмы для работы с компонентами как со строительными блоками со следующими особенностями:
– большинство свойств, событий и методов в ПС являются управляемыми;
– реинженерия компонента основывается на параметрах времени разработки;
– параметры отладки конфигурации сохраняются и используются в заданное время;
– beans компоненты регистрируют принятые сообщения о событиях или сами генерируют события;
– ПИК сохраняется в архиве JAVA с помощью шаблона JAR Contents самостоятельно либо в виде группы;
– каждый компонент может описываться в разных языках.
Для всех классов компонентов в Forte for JAVA компании Sun Microsoft Systems, Inc., предлагаются шаблоны интеграции в программную разработку [7].
Планирование
Планирование представляет собой процесс распределения и назначения ресурсов (материальных и людских) с учетом стоимости и времени выполнения проекта. Планирования являются необходимой предпосылкой выполнения любой, даже самой простой задачи. Неадекватное планирование может привести к срыву проекта или к получению в среде проекта неадекватных результатов.
Планирование и перепланирование представляет собой наиболее емкостную во времени часть управления проектом, в особенности на ранних стадиях проекта. В прошлом, проекты в области программных систем не имели планов и оценок их следования и выполнения. Современные методики предлагают средства для исправления этой ситуации, предоставляя в распоряжение менеджеров инструменты и методы, которые разрешают работать в направлении достижения реальных и достижимых оценок работ и планов.
Планирование в том или ином виде выполняется в течение всего срока реализации проекта. В начале ЖЦ проекта обычно разрабатывается неофициальный первоначальный план - грубое представление о том, что потребуется выполнить в случае реализации проекта. Решение о выборе проекта в значительной мере базируется на оценках этого первоначального плана. Формальное и детальное планирование проекта начинается после принятия решения о его реализации.
Планирование заключается в составлении следующих планов:
– работ со сроками их выполнения по методу критического пути СРМ или PERT;
– достижения требуемого качества методами проверки промежуточных результатов процессов ЖЦ;
– управление рисками,
– аттестации результатов проектирования и деятельности исполнителей проекта,
– управление конфигурацией и др.
Составляется график работ по следующей схеме (рис.10.2):
Определение Связь Оценка Распределение Определение
этапами для этапа по этапам
 |
|||
 |
|||
к проекту
Рис.10.2. Шаги составления графика работ на проекте
При планировании по методу PERT событие или дата в плане является некоторой вехой осуществления отдельных работ проекта. Веха используется для отображения (отметки) состояния завершения тех или иных работ. В контексте проекта менеджеры используют вехи для того, чтобы обозначить важные промежуточные результаты, которые должны быть достигнуты в процессе реализации проекта. Последовательность вех, определенных менеджером, часто называется планом по вехам или по событиям. Определение плана достижения соответствующих вех образуют календарный план на основе вех.
На этапе планирования могут использоваться также сетевая разбивка работ (СРР) и диаграммы Ганта [7].
СРР представляет собой иерархическая структура последовательной декомпозиции задач проекта на подзадачи. На нижнем уровне располагаются работы, которые являются детализированным элементами деятельности, они отображаются в сетевой модели СРР, как в иерархической структуре и помогают провести:
– структуризацию работ на основные компоненты и подкомпоненты,
– определить направления деятельности для достижения комплекса целей,
– распределить ответственных за выполнение отдельных работ на проектеа,
– получить отчетность и обобщение информации по проекту.
План содержит описание цикла разработки ПС по фазам, состояниям проекта и представлением каждой из них в терминах отдельных задач или деятельностей. В плане отражаются связи между процессами и определяется интервал времени для выполнения каждой деятельности, а также время ее начала и завершения.
В план работ включается также описание разных видов демонстраций заказчику: функций, подсистем, надежности, защиты и др. К документам плана относятся: комплект руководства пользователя для выполнения заданного набора операций, коммуникации системы с другими подсистемами и др.
Диаграмма Ганта - горизонтальная линейная диаграмма, на которой задачи проекта представляются сроками в виде отрезков времени и имеют даты начала и окончания, возможно с задержками и другими временными параметрами.
План в виде графа СРР имеет фазы, шаги и деятельности, а также начало и конечную деятельность на процессе (рис.10.3).
шаг 2 деятельность 1.2
. .
. .
 |
шаг 2 деятельность 3.2
. .
. . .
.
шаг2
Рис 10.3. Пошаговый граф плана проекта
Каждая фаза описывается с помощью параметров:
– начальная точка выполнения процесса,
– продолжительность,
– срок,
– результат (конечная точка).
При построении сетевого графика работ создается граф (рис.10.4), в котором указываются:
начальная точка – событие или набор событий, которые произошли до начала выполнения данной фазы процесса, и для которой описывается набор условий начала процесса;
продолжительность – интервал времени, за которое процесс должен успешно завершить свое выполнение;
срок – дата, до которой процесс полностью или частично завершает свое выполнение;
конечная точка процесса – контрольная точка, в которой заказчик проверяет качество полученных результатов процесса.
Дуге, выходящей из начальной вершины и входящей в заключительную вершину, соответствует временная пометка 0. С помощью этих меток задается время выполнения процесса.
В графе могут присутствовать циклические пути. По графу проводят анализ критических путей, т.е. определяют данные о продолжительности каждого процесса. План проекта проводится в терминах этапов: планирование, проектирование, кодирование, тестирование и сопровождение. Для первых двух методов планирование затрагивает: определение спецификаций, бюджета и расписания, а также развития плана проекта в целом.
В графе могут присутствовать циклические пути. По графу проводят анализ критических путей, т.е. определяют данные о продолжительности каждого процесса. План проекта проводится в терминах этапов: планирование, проектирование, кодирование, тестирование и сопровождение. Для первых двух методов планирование затрагивает: определение спецификаций, бюджета и расписания, а также развития плана проекта в целом.
9
 |
|||
 |
|||
2.2 3.1
|
Рис.10.4. Граф работ и сроков (на дугах) для проекта
В настоящее время значительная часть современных средств проектирования нацелена на визуализацию структуры проекта и процессов деятельности, которые на иконке могут быть выделены цветом или иконкой, это позволяет увидеть, какие виды деятельности должны выполняться параллельно, и какие находятся на критическом пути (наприер в системе Project Management).
Планирование реагирования на риски
Планирование реагирования на риски – это разработка методов и технологий снижения отрицательного воздействия рисков на проект. Берет на себя ответственность за эффективность защиты проекта от воздействия на него рисков. Планирование включает в себя идентификацию и распределение каждого риска по категориям. Эффективность разработки реагирования определяется последствиями воздействия риска на проект (положительным или отрицательным).
Стратегия планирования реагирования должна соответствовать типам рисков, рентабельности ресурсов и временным параметрам. Риски обсуждаются во время встреч, должны быть адекватны задачам на каждой стадии проекта и согласованы со всеми членами группы по управлению проектом. Может быть несколько вариантов стратегий реагирования на риски.
Планирование УК
Зависит от типа проекта, организационных мероприятий, ограничений и общих рекомендаций по руководству конфигурацией. К видам планирования УК системы относятся: идентификация, определение статуса и аудита конфигурации, управление изменениями конфигурации.
При планировании составляются планы, выбираются инструменты, анализируются требования проекта, интерфейсы компонентов и т.п. К средствам обеспечения планирования относятся:
– система управления кодами компонент, их переводом и объединением в конфигурацию системы;
– базовые библиотеки и ресурсы;
– специальные группы контроля системы и ее конфигурации;
– СУБД для ведения проекта и хранения изменений в систему.
К основным задачам планирования конфигурации относятся:
– фиксация разных заданий на изменения и выбор инструментария для их выполнения;
– определение человеко-часов и инструментальных ресурсов, стандартов, затрат на внесение изменений и др.;
– установление связей с заказчиком для проведения контроля системы и конфигурации, а также проведение оценки системы;
– определение последовательности работ УК.
Результаты планирования отмечаются в плане УК проекта, а также в документе внесения изменений в версию, конфигурацию или в систему.
Планирование управления рисками
Планирование управления рисками – это процесс принятия решений по применению и планированию управления рисками для конкретного проекта. Этот процесс может включать в себя решения по организации, кадровому обеспечению процедур управления рисками проекта, выбор предпочтительной методологии, источников данных для идентификации риска, временной интервал для анализа ситуации. Важно спланировать управление рисками, адекватное как уровню и типу риска, так и важности проекта для организации.
Идентификация рисков выполняется для определения рисков, которые способны повлиять на проект. Идентификация рисков не будет эффективной, если она не будет проводиться регулярно на протяжении реализации проекта. К этой идентификации должны привлекаться менеджеры проекта, заказчики, пользователи и независимые специалисты. Эта процедура выполняется как итерационный процесс. Вначале идентификация рисков может быть выполнена частью менеджеров проекта или группой аналитиков рисков. Далее ей может заниматься основная группа исполнителей из менеджеров проекта. Для формирования объективной оценки в завершающей стадии могут участвовать независимые специалисты.
Качественная оценка рисков – это процесс представления качественного анализа идентификации рисков и определения рисков, требующих быстрого реагирования. Такая оценка рисков определяет степень важности риска и выбирает способ реагирования. Доступность сопровождающей информации помогает легче расставить приоритеты для разных категорий рисков. Качественная оценка рисков включает в себя оценку условий возникновения рисков и определения их воздействия на проект с помощью стандартных методов и средств. Применение этих средств помогает частично избежать неопределенности, которые часто встречаются в проекте. В течение ЖЦ проекта должна происходить постоянная переоценка рисков.
Подходы к обучению программной инженерии
В рамках работ по становлению программной инженерии опубликовано ряд учебников и монографий, отображающие разные ее аспекты, и сформировалось несколько подходов к обучению и подготовки соответствующих специалистов [5–13]:
1) введение в программы обучения отдельных элементов программной инженерии;
2) создание самостоятельной специальности «программная инженерия» и обучение ей студентов всех курсов;
3) сертифицированное обучение программной инженерии как профессии на курсах подготовки или переподготовки ИТ–специалистов.
Подход 1. Обучение этой дисциплине фактически уже проводиться на факультетах информатики в виде отдельных курсов, отражающих аспекты программной инженерии: модульное, объектно-ориентированное, компонентное программирование, управление данными, тестирование ПО и др. Дипломированные специалисты, прошедшие изучение некоторых из этих аспектов, не пользуются большим спросом на рынке труда, так как не имеют знаний и опыта в организации планирования и управления деятельностью разработчиков ПО, а также знаний по вопросам распределения ресурсов (людских, аппаратных, программных), оценки трудозатрат, повышения качества и др. важных моментов ведения крупных промышленных проектов. Они могут использоваться как программисты, либо повышать знания до уровня менеджера проекта или инженера в области программной инженерии на курсах повышения квалификации.
Подход 2. Наибольшее развитие в международной практике получил подход, ориентированный на создание самостоятельной специальности «программная инженерия» на факультетах информатики. Данный подход поднимает престиж учебного заведения, требует дополнительных вложений на его оборудование и привлечение соответствующего преподавательского состава. Учебный план факультета информатики предусматривает программы по информатике и программной инженерии. Согласно [24] эти учебные программы относятся как 50:50. При этом треть предметов факультета связаны с программной инженерией, а две трети – с информатикой.
Эти темы включены в программу обучения CС– 2001 как не обязательные темы, хотя проблемы интерфейса и компонентного подхода сейчас являются перспективными направлениями дальнейшего развития современного программирования и производства ПО.
Подход 3. Обучение сформировавшихся специалистов программной инженерии на специальных курсах повышения квалификации (с отрывом и без отрыва от производства) представляет значительный интерес для действующих компаний, специализирующихся в разработке ПО и крупных программных проектов. Для усовершенствования квалификации персонала фирм объявляются или заказываются отдельные темы программной инженерии или целый курс. Самыми широко распространенными сертифицированными курсами являются: программная инженерия, управление требованиями, повторное использование, управление программными проектами, моделирование в UML и Case Rational Rose и др.
Рассмотренные подходы к преподаванию программной инженерии используются в США, Канаде, Великобритании и других европейских странах. Остановимся на анализе состояния дел по ее преподаванию на факультетах информатики в странах СНГ. До настоящего времени во многих Вузах ведется обучение ЯП ( С++, Паскаль, Бейзик Lava и др.), теории алгоритмов, ОС, СУБД, информационным технологиям и системам и др. Обсуждение предмета программной инженерии как специальности проведено, например, в российской прессе [26-28, 34]. Общее мнение состоит в том, что системное преподавание этой дисциплины в основном отсутствует, в университетах ощущается недостаток профессорско-преподавательского состава и соответствующих учебно-методических пособий.
В частности, в [27] отмечается, что сложившаяся советская система образования в университетах бывшего СССР «постепенно все больше и больше отдаляется от требований современного мира»; программирование представляет фундаментальную науку и прикладную инженерную дисциплину, основанную на применение теоретических знаний в жестких ограничениях реального мира.
Тем более, что в информатике отсутствует такие понятия, как ресурсы, трудозатраты, менеджмент, измерения и оценки продуктов, которые в программной инженерии играют ключевую роль. В связи с этим возникает естественная потребность в разносторонних и полноценных программах обучения профессиональных специалистов в области программной инженерии, основу которых может составлять СС-2001 [22 ].
Основу подготовки специалистов по программной инженерии составляют специальные программы обучения и учебники, с помощью которых студенты смогут усвоить суть данной инженерной дисциплины, получать навыки и овладеть методами создания и управления программными проектами с учетом требований индустрии, современных сред и заказчиков.
На основе огромного опыта программирования разных программных систем, преподавания спецкурса по этой дисциплине в Киевском Национальном университете им. Тараса Шевченко и учитывая международный опыт по созданию ядра знаний SWEBOK, разработан и опубликован учебник серии «высшее образование XXI столетия» [8], который рекомендован в качестве учебного пособия для обучения студентов в Вузах. Однако этот учебник вышел небольшим тиражом, его использует авторы при проведении курсов в Национальном университете имени Тараса Шевченко, в Киевском отделении МФТИ, в Национальном авиационном институте.
Software engineering) в систематизированном виде
Цель данного учебника – представить методы и средства программной инженерии ( Software engineering) в систематизированном виде для их применения на процессах проектирования, тестирования и оценки качества программных систем.
Современные университетские курсы по информатике предусматривают обучение основам программирования, объектно-ориентированному подходу, UML–моделированию, параллельному программирования и др. Больше уделяется внимание современным языкам программирования (С++, JAVA) для современных компьютеров. В результате студенты получают подготовку по этим методам и средствам и недостаточные знания по инженерии проектирования и управления проектами, качеству, конфигурации и соответствующим стандартам.
В некоторых университетах проводятся лекционные курсы по теория алгоритмов, автоматов, математической логике, дискретной математике и другим формальным дисциплинам. Эти курсы основываются на математических дисциплинах (логика, алгебра, комбинаторика) и способствуют развитию математического мышления при проведении анализе предметной области, осмыслении постановок задач и разработке программ для получения на компьютере математического результата.
Производство и использование компьютерных программ в настоящее время является массовой деятельностью, разработкой программ занимаются почти семь миллионов человек, а их используют в своей профессиональной деятельности по специальности десятки миллионов. В связи с постоянно возрастающими объемами программных разработок требуется готовить кадровый потенциал, способный решать проблемы создания новых программных продуктов на инженерной основе, используя накопленный запас знаний в области программирования и управления системами.
Сложившуюся структуру и содержание подготовки специалистов надо расширить методами управления, планирования и регулирования работ, адаптируя их к условиям коллективной разработки программных систем с гарантированным качеством. Предпосылками этого является становление новой специальности, получившей название программной инженерии или инженерии программного обеспечения (Software Engineering), впитавшей в себя накопленный запас знаний в практике и теории программирования за последние десятилетия, а также обогатившейся инженерной дисциплиной выполнения процессов ЖЦ программного обеспечения.
В связи с этим предметом обучения современных студентов, будущих разработчиков программного обеспечения, менеджеров программных проектов, тестировщиков, верификаторов, контролеров качества и др. должны стать не только теоретические и прикладные методы проектирования, а и инженерные методы управления коллективом, планирования и оценивания качества выполняемых работ и укладывания в заданные сроки и стоимость проекта.
Данный учебник посвящен систематическому описанию накопленных знаний в области программирования, отражает аспекты теории и практики программирования. Для применения в лекционных курсах окажется полезным представленное в учебнике изложение современных методов программирования и обеспечения правильности программ, а также инженерии программирования (планирование, управление и оценка продуктов и процессов), сформировавшейся под влиянием развития программной инженерии – SE (Software Engineering) и стандартизации процессов программирования. В нем также представлены современные средства и инструменты поддержки процессов создания проектов (Project Management, Rational Rose, MSF, RUP, CORBA, DCOM и др.).
Авторы надеются, что учебник поднимет уровень знаний разработчиков ПО, поможет им овладеть не только представленными знаниями в области теории и практики программирования, но инженерным программированием, включая методы планирования, управления и оценивания результатов своей деятельности.
Материал учебника апробирован при чтении лекций в Киевском национальном университете имени Тараса Шевченко (1985-1997 гг.) и в МФТИ (2000-2006 гг.), а также на международных конференциях и семинарах.
Авторы
Преобразование данных БД и замена БД
При переносе данных с одной БД на другую возникают проблемы, связанные с различием логических структур данных, справочников и классификаторов, используемых СУБД, а также изменениями, внесенными в БД [9,10]. Эти проблемы объясняются поясняются следующим:
1. Многомодельность представления данных в различных БД (иерархические, сетевые, реляционные модели) и СУБД;
2. Различия в логических структурах данных, в справочниках и классификаторах, в системах кодирования информации;
3. Поддержка различных языков для представления текстовой информации;
4. Разные типы СУБД и постоянное развитие их БД в процессе эксплуатации.
Проблема 1
решается путем перехода к реляционной модели данных и СУБД, поскольку они обладают более мощным математическим аппаратом, опирающимся на теорию множеств и математическую логику. Реляционная модель данных состоит из структурной, манипуляционной и целостной частей. В них соответственно фиксируется структура данных, описание программ в SQL–языке и требования к целостности. Целостность не поддерживается в иерархических или сетевых моделей, поэтому при переходе к реляционным БД целостности данных нарушается.
Проблемы 2 вызваны тем, что логическая структура данных представляет собой концептуальную схему БД, в которой описаны основные объекты БД и связи между ними. Поэтому при изменении предметной области, переход на новую СУБД предполагает проектирование новой структуры БД, проведение сопоставления на соответствие данных в старой и новой БД, а также изменения справочной информация и классификаторов.
Проблема 3
определяется разноязычными текстовыми представлениями информации в БД. В старых БД используется, как правило, один язык, а в новых может быть несколько, поэтому необходимо организовать хранение данных с простым доступ к текстовым данным и установлении соответствия текстовых данных, записанных на разных языках.
Проблему 4
можно сформулировать как метод хранения и обработки разных данных, вызванных спецификой СУБД иерархического, сетевого и реляционного типов. Наличие явной несовместимости типов и структур моделей данных, различные языки манипулирования данными приводят к тому, что нельзя сгенерировать на языке старой СУБД скрипты по переносу данных с последующим запусков этих скриптов в среде другой СУБД. Каждая СУБД обеспечивает внесение изменений в БД, которые в некоторой степени меняют и концептуальную модель данных, если в нее вносятся новые объекты. Внесенные изменения должны отображаться в справочниках и классификаторах, которые обеспечивают перенос данных из старой БД с учетом внесенных текущих изменений.
Процесс инженерии ПО (Software Engineering Process)
Процесс инженерии ПО включает концепции, инфраструктуру, методы определения и измерения этапов ЖЦ, поиск ошибок и внесение изменений, а также анализ и оценку качества продукта.
Область знаний «Процесс инженерии ПО (Software Engineering Process)» состоит из следующих разделов:
– концепции процесса инженерии ПО (Software Engineering Process Concepts),
– инфраструктура процесса (Process Infrastructure),
– определение процесса (Process Definition),
– оценка процесс (Process Assessments),
– количественный анализ процесса (Qualitative Process Analysis),
– выполнение и изменение процесса.(Process Implementation and Change).
Данная область знаний связана со всеми элементами управления процессами ЖЦ ПО, изменения которых проводятся в связи с их совершенствованием. Цель управления в применении лучших процессов, соответствующих реальной практике выполнения конкретного проекта.
Инфраструктура процесса базируется на основных положениях стандартов IEEE/IEC 12207 и 15504, а также на видах ресурсов (групп разработчиков, технических средств, программных продуктов и др.) и процессе инженерии ПО (групповом или по типу экспериментальной фабрики (Experience Factory– EF), базирующейся на моделях проекта и продукта, моделях качества и риска. Инфраструктура включает уровни управления, отношения в коллективе, инженерные методы организации и интеграции программного продукта. Основной задачей EF является совершенствование ПО после получения опыта и уроков его разработки.
Определение процесса основывается на: типах процессов и моделей (водопадная, спиральная, итерационная и др.); моделях ЖЦ процессов и средств, стандартах ЖЦ ПО ISO/IEC 12207 и 15504, IEEE std 1074-91 и 1219-92; а также методах и нотациях задания процессов и автоматизированных средствах их поддержки. Основной целью процесса является повышение качества получаемого продукта, улучшение различных аспектов программной инженерии, автоматизация процессов и др.
К нотациям определения процессов диаграммы потоков данных, диаграммы переходов и состояний.
Ряд нотаций используются в рамках RUP. Есть специальные нотации для графического представления бизнес-процессов (Business Process Management Notation). Автоматизация заключается в использовании тех или иных диаграмм и нотаций (RUP, MSF, IBM, Rational Rose и др.).
Оценка процесса проводится с использованием соответствующих моделей и методов оценки. Например, оценка потенциальной способности специалиста для выполнения соответствующей работы. SWEBOK обращает внимание на необходимость проведения оценки возможности организации проводить разработку ПС на основе модели оценки зрелости (СММ [22]) и процессов, согласно которым проводится разработка ПО.
Оценки относятся также и к техническим работам программной инженерии, к управлению персоналом и качеству ПО. Для этого проводится наблюдение за выполнением процесса, сбор информации, моделирование, классификация полученных дефектов, а также статический контроль и оценка процесса.
Качественный анализ процесса состоит в идентификации и поиске слабых мест в процессе создания ПО до начала его функционирования. Рассматривается две техники анализа: обзор данных и сравнение данного процесса с основными положениями стандарта ISO/IEC–12207; сбор данных о качестве процессов; анализ главных причин отказов в функционировании ПО, откат назад от точки возникновения отклонения до точки нормальной работы ПО для выяснения причин изменения процесса.
Выполнение и изменение процесса. Существует ряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе детальных измерений процесса. Оценка совершенствования процессов проводится для установления количественных характеристик процессов и продуктов. После процесса развертывания ПО, выполняются вычисления, после чего проводится инспекция результатов выполнения, анализ и принятие решений, в частности возникновение необходимости изменения процесса, организационной структуры проекта и некоторых инструментов управления измерениями.Результаты процесса могут касаться оценки качества продукта, продуктивности, трудозатрат на процессе и др.
Таким образом, рассмотрение моделей ЖЦ и их особенностей, анализа процесса изменения ПО и подходов к его моделированию, методов контроля, сбора данных о дефектах и моделях оценки процессов ПО позволят разработчикам овладеть рассмотренными задачами данной области знаний SWEBOK.
Проектирование ПО (Software design)
Проектирование ПО – процесс определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного результата.
Область знаний «Проектирование ПО (Software Design)» состоит из следующих разделов:
– базовые концепции проектирования ПО (Software Design Basic Concepts),
– ключевые вопросы проектирования ПО (Key Issue in Software Design),
– структура и архитектура ПО (Software Structure and Architecture),
– анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),
– нотации проектирования ПО (Software Design Notations),
– стратегия и методы проектирования ПО (Software Design Strategies and Methods).
К базовым концепциям проектирования ПО относятся процессы ЖЦ (стандарт ISO/IEC 12207), процесс проектирования архитектуры с использованием разных принципов (объектного, компонентного и др.) и техник: абстракции, декомпозиции, инкапсуляции и др. Автоматизируемая система декомпозируется на отдельные компоненты, выбираются необходимые артефакты (нотации, методы и др.) программной инженерии и строится архитектура ПО.
К ключевым вопросам проектирования ПО относятся: декомпозиция на функциональные компоненты для независимого и параллельного их выполнения, принципы распределения компонентов в среде выполнения и их взаимодействие между собой, механизмы обеспечения качества и живучести системы и др.
При проектировании структуры ПО
используется архитектурный стиль проектирования, основанный на определении основных элементов структуры – подсистем, компонентов и связей между ними.
Архитектура проекта – высокоуровневое представление структуры, задаваемое с помощью паттернов, компонентов и их идентификация. Описание архитектуры содержит описание логики отдельных компонентов системы, достаточное для проведения работ по кодированию, и связей между ними. Существуют и другие виды структур, основанные на проектировании образцов, шаблонов, семействе программ и их каркасов.
Паттерн – это конструктивный элемент ПО, который задает взаимодействие объектов (компонентов) проектируемой системы, определение ролей и ответственности исполнителей. Основным языком задания этого элемента является UML.
Паттерн может быть: структурным, в котором определяются типовые композиции структур из объектов и классов диаграммами классов, объектов, связей и др.; поведенческим, определяющим схемы взаимодействия классов объектов и их поведение диаграммами активностей, взаимодействия, потоков управления и др.; креативным, отображающим типовые схемы распределения ролей экземпляров объектов диаграммами взаимодействия, кооперации и др.
Разработка требований – это формирование
– определение бизнесов–процессов;
– формирование прецедентов;
– спецификация требований к бизнесам–процессам, условий и особенностей их выполнения.
Определение бизнесов–процессов. Это наименее формализованный процесс на этапе разработки требований. Начальное описание делается заказчиком ПС с использованием обычного языка представления понятий относительно бизнесов–процессов и ПрО. На практике существуют несколько итераций в формировании этого описания, чтобы заказчик и разработчик пришли к соглашению и поняли друг друга.
Метод декомпозиции предусматривает постепенную и планомерную детализацию функционального, пользовательского и технологического аспектов и т.п. Детализация проводится несколькими итерациями и может закончиться на следующем этапе процесса.
Формирование прецедентов. Прецедент описывает последовательность событий в профессиональной деятельности пользователя, где применяется ПС. Прецеденты описывают варианты использования системы. Совокупность всех прецедентов определяет общую картину применения ПС для решения задач определенной ПрО. Поскольку они формируются различными категориями пользователей, могут существовать определенные противоречия в их описаниях. Для их предотвращения при анализе таких прецедентов, им даются определенные приоритеты, согласно которых они ранжируются и структурируются. Важным моментом в формировании прецедентов – согласование с описанием бизнесов–процессов.
Спецификация требований к бизнесам–процессам.
Спецификация требований не являются конечными, они выполняться на стадии анализа поведения ПС. Далее проводится переход от общих системных требований к требованиям относительно отдельных компонентов. Детализация системных требований к уровню компонентов является основой их спецификации.
Рефакторинг компонентов
Рефакторинг получил развитие в объектно–ориентированном программировании [2] в связи с применением шаблонов проектирования, методов улучшения кода и структуры объектно–ориентированных программ. Были разработаны целые библиотеки типичных трансформаций искомых объектов (классов), которые улучшают те или другие характеристики. Он вошел в компонентное программирование и базируется на типичной структуре, модели компонента и ориентирован на изменении не только компонентов, а и их интерфейсов.
Метод рефакторинга компонента – это целевой способ получения нового компонента на базе существующего, включает операции модификации (изменение, замещение, расширение) компонентов и интерфейсов, состоящие в преобразовании состава компонентов ПС или в изменения отдельного компонента системы для придания ему новых функциональных и структурных характеристик, которые наиболее полно удовлетворяют требования компонентной конфигурации.. Фактически такие изменения компонентов соответствуют процессу проектирования компонентных ПС.
Рефакторинг – это совокупность моделей, методов, процессов, применяемых к определенным классам объектов и компонентов для получения новых или изменения существующих объектов– компонентов с целью повышения качественных характеристик. ПС или добавление новых возможностей к существующей компонентной системе.
Процессы рефакторинга могут быть разными, их главная цель – получение новых компонентов, однозначно идентифицированных, и включающих в себя следующие операции над компонентами и интерфейсами по организации проведения изменений:
– добавление новой реализации для существующего и нового интерфейса;
– замена существующей реализации новой с эквивалентной функциональностью;
– добавление нового интерфейса (при условии наличия соответствующей реализации);
– расширение существующего интерфейса;
– расширение интерфейса для новых системных сервисов в компонентной среде.
Каждая операция рефакторинга является базовой, атомарной функцией преобразования, которая сохраняет целостность компонента. Под целостностью компонента
понимается совокупность правил, ограничений и зависимостей между составными элементами компонента, которые разрешают рассматривать компонент как единую и цельную структуру со своими свойствами и характеристиками
После выполнения операции рефакторинга измененные компоненты должны быть идентичными исходным и сохранять функции. В случае коренного изменения группы компонентов системы в связи с введением новых функций, система приобретает новую функциональность.
Операции над компонентами должны удовлетворять следующим условиям:
– объект, полученный в результате рефакторинга является компонентом с соответствующими свойствами, характеристиками и типичной структурой;
– операция не изменяют функциональность, то есть новый компонент может примениться в раннее построенных компонентных системах;
– перестройки или переделки компонентов, а иногда и перепрограммирования в случае реверсной инженерии [4, 5].
Реинженерия программных систем
Реинженерия (reengineering) – это повторная реализация программы (системы) в целях повышения удобства ее эксплуатации, сопровождения или изменения ее функций. Она включает такие процессы как повторное документирование системы, реорганизация и реструктуризация, перевод системы на один из более современных ЯП, модификация и модернизация структуры и системы данных. При этом архитектура системы может оставаться неизменной.
Метод реинженерии – целевое средство получения нового компонента благодаря последовательности операций внесения изменений, модернизации или модификации, а также перепрограммирования или адаптации компонентов.
Реинженерия компонентов – это совокупность моделей, методов и процессов изменения структуры и возможностей компонентов с целью получения компонента с новыми возможностями.
Новые компоненты необходимо идентифицировать по определенным действующим правилам именования компонентов и методов их применения в системах из компонентов. Решение проблемы идентификации связано с необходимостью создания компонентных конфигураций и каркасов системы из компонентов.
С технической точки зрения реинженерия – это решение проблемы эволюции системы. Если предположить, что архитектура системы не изменяется, то преобразовать централизованную систему в распределенную, компоненты которой размещаются в операционной среде на разных компьютерах, является довольно сложным процессом. (Например, изменить язык программирования старой системы (Fortran, Сobol и др.) на современные объектно–ориентированные языки Java или C++.
Однако с коммерческой точки зрения реинженерию принимают часто за единственный способ сохранения наследуемых систем в эксплуатации. Подходы к эволюции системы, при которых изменяется все, являются дорогостоящими либо рискованными.
Так как ПС много, то полная замена или радикальная реструктуризация их в большинстве затруднена. Методами реинженерии проще совершенствовать структуру, документацию или отдельные компоненты системы.
Сопровождение старых систем действительно стоит дорого, однако реинженерия может продлить время их существования.
По сравнению с более радикальными подходами к совершенствованию систем реинженерия имеет следующие преимущества.
1. Снижение рисков. При повторной разработке ПО существует риск получения неудовлетворительного результата, который определяется внесением ошибок в системные спецификации, снижением надежности или изменением функционирования некоторых программ. Снизить возникающие риски можно за счет удаления ошибок и улучшения качества работы измененных программ.
2. Снижение затрат. Себестоимость реинженерии значительно ниже, чем разработка нового ПО. Согласно данным различных коммерческих структур она в четыре раза дешевле, чем повторная разработка системы.
Реинженерия применяется при изменении деловых процессов, снижении количества излишних видов деятельности в них и повышением эффективности отдельных деловых процессов. Это можно сделать путем внедрения новых программ или модификации существующих программ, выполняющихся на процессе. Если бизнес–процесс зависит наследуемых систем, используемых в процессе, то это надо учитывать при планировании каких–либо изменений.
Основное различие между реинженерией и новой разработкой системы состоит в том, что написание системной спецификации начинается не с «нуля», а с учета возможностей старой наследуемой системы при разработке спецификации новой системы. К основным этапам этого процесса относятся:
- перевод исходного кода путем конвертирования программы в старом языке программирования на современную версию этого языка либо на другой язык программирования;
– анализ программ для документирования структуры и функциональных ее возможностей;
модификация структуры программ для ее упрощения, понятности и наращивания новых свойств;
– разбиение на модули для группирования и устранения избыточности, что приводит к изменению структуры системы;
– изменение системных данных, с которыми работает программа для согласования с проведенным изменениями в программе.
Преобразование исходного кода программ – наиболее простой способ реинженерии программ. Оно может быть выполнено автоматически (автоматизировано). Причинами перевода на другой язык могут быть:
1. Обновление платформы аппаратных средств, на которой может не выполняться компилятор исходного языка программ.
2. Недостаток квалифицированного персонала для программ, написанных в специфических ЯП, вышедших из употребления.
3. Изменение структуры организации программы в связи с переходом на общий стандартный ЯП для снижения затрат на сопровождение программных систем.
К операциям реинженерии относятся:
– именование компонентов и их идентификацию;
– расширение функций существующей реализации компонента;
– перевод языка компонента на новый современный язык программирования;
– реструктуризация структуры компонента;
– модификация описания компонента и его данных.
Репозитарий компонентов
ПИК и производные от них объекты размещаются в разных хранилищах (библиотеках, репозитариях ПС, в репозитариях Интернет) и используются многократно при построении ПС [30–31]. Например, каждый репозитарий (например, библиотека GreenStone) ориентирован на одну или несколько предметных областей.
В общем случае репозитарий представляет собой систему средств для хранения, пополнения наработанных ПИК, включает в себя инфраструктуру разработки ПС из компонентов, организацию доступа к содержащимся в нем ПИК для последующего их использования в новых проектах ПС.
С функциональной точки зрения репозитарий работает по принципу информационно-поисковой системы, объектами хранения которой являются разные типы документов, тексты и др. Им ставится в соответствие информация, содержащая формализованные спецификации экземпляров коллекции документов, которые отображают понятия ПрО, ключевые слова, правила доступа и др.
В отличие от них компоненты ПИК записываются в репозитарий с поисковым образом, создаваемый путем аннотирования ПИК на основе описания информационной части ПИК. В соответствии терминологии UML, лица, которые обеспечивают функционирование репозитария, называются актерами, а сами работы с ПИК – сценариями.
Репозитарий компонентов ПС упрощает и сокращает сроки разработки ПС за счет:
– отображения в них базовых функций и понятий ПС;
– скрытия представления данных, операций обновления и получения доступа к этим данным;
– обработки исключительных ситуаций, возникающих в процессе выполнения и др.
При представлении поискового образа ПИК используются также информационные модели, которые обеспечивают систему хранения, поиска и сопоставления ПИК, принадлежащих репозитарию, который виртуально разделен на разделы, соответствующие представленном в нем ПрО, перечень которых составляет классификатор первого уровня. Классификаторами следующих уровней могут служить отдельные понятия, определенные для ПрО.
Каждому понятию соответствует информационная модель, в состав которой входят паспортные данные (имя и адрес разработчика, способ приобретения, цена, и т.п.), сведения о среде реализации (ОС, ЯП, СУБД и т.п.), описание аппаратных ресурсах, имени ПрО, к которому относится ПИК в системе классификации и категорий ПИК, а также описание нефункциональных требований к создаваемой системе (безопасность, конфиденциальность, показатели качества системы и прочее).
Для отображения ПИК в репозитарии проводится их классификация и каталогизация, аннотирование и размещение.
Классификация компонентов обеспечивает унификацию представления информации о компонентах для последующего их поиска и отбора из среды репозитария. Она проводится с учетом следующих их групп:
– компонент типа модуль, класс и т.п.;
– компоненты, которые имеют интерфейс (входные и выходные параметры, пред-, пост- условия функционирования), функциональность и реализацию на ЯП, из которых создается ПИК со спецификацией шаблона развертывания;
– готовые к употреблению ПИК;
– сложные ПИК типа каркасы и паттерны, которые обеспечивают взаимодействие простых ПИК.
Каталогизация направлена на физическое размещение кодов ПИК в репозитарии для извлечения их при необходимости встраивания новый программный проект ПС. Для выбранных компонентов осуществляется их настройка на условия среды функционирования.
Инженерия ПИК и других компонентов (КОМ1, …, КОМk ) в разработку новых ПС осуществляется примерно по технологии, представленной на рис.6.1. Если компоненты написаны на разных ЯП, создаются интефейсные модули (Int1,…, Intk), в которых подготавливаются и преобразуются типы передаваемых данных.
Генерация интерфейсов пары КОМ на ЯП Int
1
8. Интеграция разных видов компонентов Int2
j
Рис 6.1 Технология инженерии компонентов в разработке ПС
Реверсная инжеиерия
Методы реверсной инженерии разработаны в среде объектно–ориентированного программирования [1]. Они базируется на выполнении базовых операций визуализации (visual) и измерения метрик (metric) программных систем в рамках модели, которая предлагает следующие цели:
– обеспечение высокого качества системы и переосвидетельствование ее размера, сложности и структуры;
– поиск иерархии классов и атритутов программных объектов с целью наследования их в ядре системы;
– идентификация классов объектов с определением размера и /или сложности всех классов системы;
– поиск патернов, их идентификация, а также фиксация их места и роли в структуре системы.
Этот подход ориентирован на индустриальные системы в миллион срок кода с использованием метрических оценок характеристик системы. Он разрешает генерацию тестов для проверки кодов, а также проведение метрического анализа системы для получения фактических значений внутренних и внешних характеристик системы.
В результате анализа системы строится модель, которая содержит список классов и патернов системы, которые могут модифицироваться и перепроектироваться, а также с помощью которых можно организовать процесс эволюции системы. Если некоторый класс плохо спроектирован (например, много методов и имеются пустые коды) или система не выполняет нужную работу, то проводится сбор информации для модели системы.
В данном подходе действия по визуализации системы освещаются на двухмерном экране в виде иерархического дерева. В нем узлы отображают объекты и их свойства, а отношение между ними задаются контурами команд фрагментов программ. При этом применяется таблица метрик, в которой находятся сведения о метриках классов объектов (число классов, методов, атрибутов, подклассов и строк кода), метрик методов объектов (количество параметров, вызовов, сообщений и т.п.), метрик атрибутов объектов (время доступа, количество доступов в классе и подклассе и т.п.).
В процессе визуализации ведется сбор метрических данных о системе.
Если реально определены все данные в разных фактических метриках программной системы, выполняются оценка качества и разработка плана перестройки устаревшей системы на новую с получением тех же возможностей или новых дополнительных.
Вывод. Преобразование исходного кода с целью внесения разного рода изменений (реинженерии, рефакторинга, реверсной инженерии) является эффективным, если основные изменения выполняются автоматически с помощью специально созданных систем, либо с помощью программ конвертирования кода с одного языка на другой с учетом наличия разных типов данных в этих ЯП, либо с помощью системы сопоставления с образцом, представленным в виде списка команд для описания перевода с одного языкового представления на другое, которое реализуется сравнением и сопоставлением с такими же образцами в новом языке.
Автоматизированный перевод не возможен, если структурные компоненты исходного кода не имеют соответствия в новом языке. Это бывает в том случае, когда исходный язык содержит встроенные условные команды компиляции, которые не поддерживаются в новом языке. В этом случае совершенствование создаваемой системы выполняется вручную со значительными затратами человеческих и финансовых ресурсов.
Сервлет – это небольшая программа
Сервлет – это небольшая программа, которая выполняется на серверной стороне WEB, расширяет функциональные возможности WEB сервера, облегчает доступ к ресурсам и разрешает процессу читать данные из HTTP, запрашивать WEB–сервер и записывать данные из сервера в http, как ответ. Они выполняются в границах адресного пространства WEB–сервера. Сервлеты – альтернатива CGI (Common Gateway Interface), которые базируются на взаимодействии процесса запроса клиента с WEB–сервером. CGI программы разрабатываются на разных ЯП и являются необходимыми при создании отдельного процесса обработки каждого запроса клиента. Сервлеты не требуют больших ресурсов памяти и процессора, описываются на языке JAVA независимо от платформы, размещаются в разных средах и используют библиотеку классов JAVA для получения параметров инициализации, активизации и регистрации событий, а также для доступа к информации и формирования ответа клиенту.
Создание сервлетов в языке Java осуществляется с помощью инструментария Servlet Development Kit (JSDK) с применением следующих шаблонов создания и интеграции:
– WebModule – элемент WEB ресурса, который может разворачиваться в прикладной программе для поддержки функционирования сервлета, использует спецификации сервлетов и серверных страниц. Может содержать в себе файлы с Java классами, которые поддерживают сервлети, beans компоненты с тем же назначением, страницы сервера, статические HTML документы и аплеты;
– WebModuleGroup – шаблон для создания группы взаимодействующих WebModule на WEB сервере и поддержки создания сервлетов.
– Servlet;
– HTML File.
Методы спецификации компонентов. Спецификация – это описание компонента и способа вызова компонентов из другой среды, или из электронной библиотеки, или репозитария. Спецификация включает интерфейс, контракт и нефункциональные свойства.
Интерфейс компонента может быть определен как спецификация точек доступа к компоненту. Клиент получает сервис, который предоставляет компонент, через эти точки доступа.
Так как интерфейс не дает реализацию его операций, а предоставляет их описание имеется возможность изменять реализацию без изменения интерфейса, а также добавлять новые интерфейсы (и реализацию).
Семантика интерфейса может быть представлена с помощью контрактов, в которых определяются глобальные ограничения, которые поддерживает компонент т.е инвариант. Контракт может определять ограничения операций, которые должны быть выполнены клиентом перед вызовом операции (пред–условия), и условия, которые предлагает установить после завершения операции (пост–условия). Вместе пред–условия, инвариант и пост–условия составляют спецификацию поведения компонента.
Каждый интерфейс состоит из набора операций (сервисов, которые он предлагает или требует). С каждой операцией связанный набор пред–условия и пост–условия, зависящие от состояния, которое получает компонент. Контракты и интерфейс связаны между собою, но наполняются по–разному. Интерфейс отражает функциональные свойства и состоит из набора операций для спецификации сервисов, а контракт отражает семантику и описание поведения компонента, зависящее от взаимодействия с другими компонентами.
Нефункциональные свойства задают общие черты поведения компонента, которые не могут быть выражены через стандартные интерфейсы. Примерами нефункциональных свойств являются надежность, живучесть, доступность и др. Все эти свойства можно предоставлять как специальные расширения интерфейса, которые обеспечивают сервисы описания компонента, динамической конфигурации, динамического взаимодействия с другими компонентами или средой.
Шаблон развертывания
Шаблон развертывания представляет собою скрытую часть и необязательную часть абстракции компонента, который может быть повторно использован в одном или многих средах и для этого он имеет несколько шаблонов отладки. К спецификации компонента могут добавляются новые шаблоны его интеграции или изменяются старые шаблоны. В некоторых классах ПИК параметры интегрирования в новое среды включаются в интерфейс компонента, что ограничивает способность компонента адаптироваться к новым средам и тем самым сужается круг задач, в которых он может повторно использоваться.
Для селекции и подключения нового компонента избранного типа используется механизм NFTW в JAVA. Набор параметров для интегрирования нового компонента в определенном пакете варьируется в зависимости от типа компонента.
Приведем дальше краткое описание функциональности и обзор шаблонов развертывания для отдельных типов компонентов в JAVA.
Проекты как средство композиции компонентов. Создание нового проекта состоит в конфигурации системы с помощью компонентов JAVA и обеспечении их взаимодействия следующими шагами:
– скомпилировать разные файлы с разными JAVA компонентами одной командой;
установить основной компонент (класс) в проекте, который задает шаблон кооперации других компонентов в проекте;
– установить уникальную конфигурацию для каждого отдельного проекта,
– поддержать соответствующую файловую систему,
– установить уникальные типы компилирования, выполнения и отладки;
– подключить к работе иерархию окон.
Система CORBA и средства описания объектов и компонентов
Архитектура CORBA (Common Object Request Broker Architecture) предоставляет распределенный обмен данных с помощью специальных объектов–брокеров ORB (Object Request Broker), применяется для обработки запросов. Эта технология позволяет прикладной программе запрашивать сервисы другой программы, вызывая методы ее удаленных объектов. Для реализации взаимодействия объекта–брокера и программы (клиента и сервиса) используется язык интерфейса IDL (Interface Definition Language). JAVA включает ORB и компилятор idltojava, который генерирует код по IDL спецификациям [8 –10].
Работа в системе CORBA сводится к генерации JAVA файлов на основе IDL файла интерфейса для стороны сервера или для стороны клиента или для обеих. Со стороны клиента требуется специфическая IOR форма (Interoperable Object Reference), которая поддерживает именование сервера. CORBA использует браузер для просмотра имен сервисов, генерации кода и вставки его в файл класса клиента. Со стороны сервера дополняется код, который связывает экземпляры сервентов с именами сервисов. Браузер может сгенерировать этот код и вставить его в файл класса сервера. IDL файл компилируется и полученная программа запускается для выполнения.
В системе CORBA имеются следующие шаблоны интеграции
компонентов:
– Client class для вызова метода, который будет выполнен сервером.
– Stub class для конвертации метода, инициирующего работу клиента в Wire формате, используемом при связывании в сети на стороне клиента;
– ORB class управляет методами передачи данных и вызовами методов между процессами;
– Implementation class содержит деловую логику сервера, экземпляр этого класса сервент регистрируется в ORB и может использоваться клиентом для запуска другого процесса;
– Server class создает сервент и ссылку IOR, доступную ему, которую он записывает в стандартный выходной файл;
– Skeleton class конвертирует инициирующий метод с Wire форматом с помощью ORB брокера в формат, который может прочитать экземпляр сервента.
Для реализации ПИК типа CORBA компоненты используют как шаблон, так и мастер создания CORBA компонентов. Система CORBA предлагает шаблоны для создания и реинженерии компонентов.
Шаблон поддержки работы адаптера POA (Portable Object Adapter) является корнем каждой иерархии серверов и доступен разным ORB. Адаптер порождает следующие типы объектов: пустой сервер (Empty), основной класс сервер (ServerMain), класс клиент (ClientMain) и простой Simple (сервер с минимальными инициированными элементами).
При использовании мастера инициализации CORBA компонентов пользователь должен использовать три параметра (value, title, type), каждый из которых задается переменной строкового типа, значения которого понимает мастер. Например:
<server– binding name = ‘Proprietary Binder’ template–tag = ‘SERVER_BINDING’>
<wizard requires–value = ‘/* FFJ_COBRA_TODO_SERVER_NAME*/’
title = ‘Server name:’ type = ‘string’/>
Словарь терминов программной инженерии
Абстракция – способность отделять существенное от второстепенного, видеть идею, которая определяет реализацию.
Абстрактная архитектура – декомпозированная структура задач домена на подсистемы или иерархию подсистем, на каждом уровне которой фиксируются выделенные параметры и ограничения, определяющие варианты состава выделенных подсистем.
Агрегация – объединение ряда понятий в новое понятие (отношение типа "часть–целое"), общие признаки которого могут быть суммой признаков компонентов или существенно новыми признаками
Актеры – действующие лица, для которых создается система.
Анализ требований – отображения функций системы и ее ограничений в модели предметной области.
Артефакт – любой продукт деятельности специалистов по разработке ПО.
Архитектура программной системы – определение системы в терминах вычислительных подсистем и интерфейсов между ними, отображающая правила декомпозиции проблемы..
Ассоциация – наиболее общее и существенное отношение, которое утверждает наличие связи между понятиями без уточнения их содержания и размеров.
Белого ящика метод – исследование внутренний структуры программы в целях выявления ошибок путем исчерпывающего тестирования всех путей и потоков передач управления.
Валидация – проверка соответствия разработки программной системы требованиям заказчика.
Верификация – проверка правильности реализации системы заданным требованиям на каждом этапе жизненного цикла.
Взаимодействие объектов – связь между объектами через посылку сообщений друг другу.
Водопадная (каскадная) модель – схема работ, в которой каждая из работ выполняется один раз и в том порядке, который указан в модели жизненного цикла.
Гарантия качества программного обеспечения – действия на каждом этапе жизненного цикла по проверке и подтверждении достигаемого качества соответственно стандартам и процедурам.
Дефект – это ошибочное событие в результате неверного описания спецификаций требований, исходных или проектных спецификаций, документации и т.п.
Диаграмма – графическое представление моделирования системы с помощью классов, сценариев, состояний и т.п.
Динамическое
тестирование – выполнение программ для обнаружения ошибок, установления их причины и устранения.
Домен предметной области – спектр задач проблемной области, которые допускают похожие приемы их решения.
Жизненный цикл системы (ЖЦ) – непрерывный процесс, который начинается с момента принятия решения о необходимости ее создания и заканчивается в момент ее полного изъятия из эксплуатации.
Задача системы
– описание способа (технологии) достижения цели, содержащее указание на цель с конкретными числовыми (в том числе временными) характеристиками.
Имитационное моделирование – моделирование поведения системы в различных аспектах и в разных внешних и внутренних условиях с анализом динамических характеристик и анализом распределения ресурсов
Инженерия – применение научных результатов и дисциплины управления программированием задач в целях получения пользы от свойств продуктов, способов взаимосвязи и выполнения.
Инженерия качества – процесс управления предоставлением продуктам программного обеспечения свойств качества (надежность, сопровождаемость и т.п.).
Инженерия требований – сбор, анализ, оформление условий и ограничений на разработку системы в виде спецификации, согласованной как заказчиком, так и исполнителем.
Интенсивность отказов – это частота появления отказов или дефектов в программной системе при ее тестировании или эксплуатации.
Инспекция кода – формальная проверка описания, используемых типов и структур данных в проекте системы на их соответствие требованиям.
Информационная модель повторно используемых компонентов (ПИК) – модель, с помощью которой отображается информационный (поисковый) образ ПИК в каталоге.
Информационная система – система, которая проводит сбор, обработку, сохранение и производство информации с использованием автоматических процессоров и людей.
Информационное обеспечение – набор средств для предоставления информации пользователям о содержании и условиях ее применения.
Интерфейсные объекты – связка (стыковка) программ, представленная в виде описания передаваемых через сообщения параметров для выполнения.
Интерфейсные объекты – связка (стыковка) программ, представленная в виде описания передаваемых через сообщения параметров для выполнения.
Инцидент – абстрактное событие, влияющее на изменение состояния объекта.
Каркас (фрейм) – разновидность абстрактной архитектуры для определения выделенных в структуре компонентов.
Качество программного обеспечения – совокупность свойств, которое определяют пригодность программного обеспечения удовлетворить заказчика в соответствии его требований к разработке.
Компонент – тип, класс, проектное решение, документация или иной продукт программной инженерии приспособленный для практического использования.
Компонентная разработка – конструирование программного обеспечения путем композиции готовых компонентов, сохраняемых в каталогах.
Конкретизация – добавление существенных признаков, благодаря чему содержание понятия расширяется, а объем понятия сужается.
Конечные пользователи системы – профессиональные лица, для потребностей которых заказывается компьютерная система.
Конфигурация – вариант (версия) изготовленной программной системы из отдельных экземпляров компонентов и подсистем.
Концептуальное моделирование – процесс построения модели проблемы, ориентированной на ее понимание человеком.
Критерий – количественная или качественная характеристика состояния системы, позволяющая оценить степень достижения цели и сформулировать решающие правила выбора средств (способов, технологий) достижения цели.
Критерий эффективности – критерий, позволяющий оценить степень достижения цели с учетом произведенных затрат различных ресурсов.
Менеджмент – профессиональное управление коллективами работников (персоналом).
Метрика – количественная мера и шкалы измерения характеристик программы.
Модель жизненного цикла – типичная схема последовательности работ на процессах разработки программного продукта.
Модель процессов – определенная последовательность действий, сопровождающая изменение состояния программного объектов.
Модель состояний – отображения динамики изменения состояния объекта класса, которое изменяют его поведение.
Модель качества – четырехуровневая структура, которая отображает характеристики, атрибуты, метрики и оценочные элементы программного обеспечения.
Надежность программной системы – это способность системы сохранять свои свойства (безотказность, устойчивость и др.) в процессе преобразования исходных данных в результаты в течение определенного промежутка времени при определенных условиях эксплуатации.
Нефункциональные требования – требования, которое характеризуют организационные, исполнительские, операционные аспекты работы программной системы в среде реализации.
Наследование – конкретизация в подклассе отдельных свойств для использования другими объектами суперкласса.
Отладка – проверка программы на наличие в ней ошибок и их устранение без внесения новых.
Отказ – переход программы из работающего состояния в неработающее в связи с ошибками или дефектами в ней.
Обобщение – сужения истинных признаков понятия для расширения свойств охваченных этим понятием объектов.
Ошибка – недостатки в операторах программы или в технологическом процессе ее разработки, которые приводят к неправильной интерпретации исходной информации и к неверному решению.
Объекты управления (по Джекобсону) – это функции преобразования объектов интерфейса в объекты сущности, часто отображают алгоритмы обработки данных в системе.
Объект–сущности (по Джекобсону) – долго живучие объекты, которые отвечают реальным предметам мира и сохраняют свое состояние после выполнения сценария.
Объектно–ориентированная модель – структура из совокупности объектов, которые взаимодействуют между собою, обладают свойствами и поведением.
Онтология – совокупность элементарных понятий, терминологии и парадигмы их интерпретации в среде проблемы, которую требуется разработать.
Оценочный элемент метрики
– количественная или качественная мера для оценка соответствующего показателя с учетом его веса в системе оценки качества.
Оценивание качества – действия, направленные на определение степени удовлетворения программного обеспечения требованиям, соответствующим его предназначению.
Пакет – программная структура с общим механизмом организации элементов (объектов, классов) в группы, начиная от системы (стереотип "система") и к ее подсистемам различного уровня детализации.
Переносимость системы – возможность изменять сервис системы (ОС, связи, , сетевые коммуникации, данные СУБД и т.п.) путем настройки модулей на новые условия среды или платформы.
План тестирования – описание стратегии, ресурсов и график тестирования отдельных компонентов и системы в целом.
Поведение домена – переход элементов домена из состояния к состоянию во времени.
Повторное использование – использование в качестве готовой порции любых формализованных знаний, полученных при реализации программных систем.
Повторно используемый компонент (ПИК) – фрагмент знаний о минувшем опыте программирования системы, представленный так, чтобы его можно использовать не только его разработчиками, но и пользователями после соответствующей адаптации к новой среде.
Прикладная система – продукт программной инженерии, предназначенный для выполнения конкретных задач конечного пользователя.
Прецедент (класс) определяет набор экземпляров прецедента, где каждый экземпляр – это последовательность действий, выполняемых системой, которая выдает наблюдаемый результат, ценный для конкретного субъекта.
Прецедент (экземпляр) – последовательность действий, выполняемых системой, которая выдает результат, ценный для конкретного субъекта.
Принципы – базовые концепции, лежащие в основе всей области программирования.
Приложение – область применения, в которых принципы и практика находят свое наилучшее выражение.
Программная инженерия – система методов, средств и дисциплины планирования, разработки, эксплуатации и сопровождения программного обеспечения, способного к массовому воспроизводству.
Процесс приобретения – действия, которые инициируют определенный цикл анализа для определения покупателем программной системы или сервиса.
Процесс разработки – действия разработчика по инженерии требований, проектированию, кодирование и тестированию программного продукта
Процесс сдачи – действия по передаче разработанного продукта покупателю.
Процесс эксплуатации – действия по обслуживанию системы пользователем.
Процесс сопровождения – действия по управлению модификациями и поддержкой системы в актуальном состоянии при выполнении функций системы или изъятие системы из употребления.
Проектирование – преобразования требований в последовательность проектных решений и их в архитектуру из программных компонентов.
Проектирование концептуальное – уточнение понимания и согласование деталей требований к системе.
Проектирование архитектурное – определение структурных особенностей строящейся системы.
Проектирование техническое – отображение требований среды функционирования и разработки системы путем определения всех конструктивных элементов и их композиций.
Проектирование детальное – определение подробностей реализации функций для заданной среды и связей между соответствующими компонентами системы.
Реализация программной системы – преобразования проектных решений в работающую систему (синонимы: кодирование, конструирование) .
Родовые знания – знания относительно всех задач семейства домена, которые представляются в виде, пригодном для обеспечения решения любой задачи, относящейся к данному семейству.
Сертификация программного продукта – процесс для установления соответствия программной продукции (процесса или услуг) конкретному стандарту или техническим условиям со специальным знаком или свидетельством.
Семейство прикладных систем – множество прикладных систем с общими функциональными свойствами и управлением.
Связь (Relationship) – поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.
Спецификация – описание алгоритма, правил, ограничений действий объектов с учетом стандартов, критериев качества и др.
Спиральная модель ЖЦ – модель процессов в жизненном цикле разработки системы, позволяющей возвращаться к любому предыдущему процессу с целью переработки элементов сделанного продукта.
Событие – явление, которое провоцирует смену определенного состояния и переход к другому состоянию в системе.
Состояние (домена, системы, объекту и тому подобных) – фиксация определенных свойств на определенный момент или интервал времени.
Статическое тестирование – анализ и рассмотрение спецификаций компонентов на правильность представления без их выполнения на компьютере.
Стереотип – указатель категории элемента моделирования UML.
Сопровождение – работы по внесению изменений в программную систему после того, как она передана пользователю для эксплуатации.
Структура системы – множество элементов и отношений между ними.
Субъект (экземпляр) – кто–то или что–то, вне системы, что взаимодействует с системой.
Сущность (Entity) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению.
Сценарий
– конкретная последовательность действий, которая иллюстрирует поведение и выполнение экземпляра прецедента.
Тест – некоторая программа, предназначенная для проверки правильности ее работы и выявления в ней ошибочных ситуаций.
Тестовые данные – данные, которые готовятся на основе документов программы или спецификаций для проверки работы программной системы.
Тестирование – способ семантической отладки (проверки) программы, который состоит в выполнении последовательности различных контрольных наборов тестов и сверка с известным результатом.
Требование – соглашение или договор между заказчиком и исполнителем системы относительно ее работы.
Унаследованная система – существующая действующая система, созданная за любыми и методами и технологиями для поддержки некоторых процессов бизнеса.
Управление качеством – комплекс способов и системной деятельности по планированию, управлению и оценке качества программного обеспечения.
Упрятывание информации – принятие решения о том, что следует сообщить всем о программе, а что оставить при себе – не показывать.
Фасад – механизм доступа к тем свойствам системы компонентов, которые необходимы при реинженерии с точка зрения пользователя системы.
Функция – содержание действий, выполнение которых возлагается на элемент системы при заданных требованиях, условиях и ограничениях.
Функциональные требования – требования, которые определяют цели и функции системы и принципы их выполнения на компьютере.
Функциональная полнота – атрибут, показывающий степень достаточности основных функций для решения специальных задач соответственно назначению программного обеспечения.
Функциональная структура – структура, элементами которой являются функции, реализуемые подразделениями предприятия, а отношениями – связи, обеспечивающие передачу предметов труда.
Характеристики качества – функциональность (functionality), надежность (realibility), удобство (usability), эффективность (efficiency), сопровождаемость (maitainnability), переносимость (portability) и тому подобное.
Черного ящика метод – тестирование реализованных функций путем проверки соответствия реального поведения функций с ожидаемым поведением исходя из спецификаций требований.
Экземпляризация – зависимость между параметризованным абстрактным классом–шаблоном (template) и реальным классом через определение параметров шаблона.
Эксплуатация – действия по выполнению готовой программной системы.
UML (Unified Modeling Language) – диаграммный способ (язык) для спецификации, визуализации, конструирования и документирования продуктов на процессах ЖЦ.
Сопоставление модели ЖЦ стандарта ISO/IEC и областей –процессов SWEBOK
Каждая область знаний SWEBOK по существу соответствует отдельным процессам, которые определены в стандарте 12207. В связи с этим проведен сравнительный анализ модели областей (процессов) SWEBOK и модели процессов ЖЦ этого стандарта с целью сопоставления задач процессов стандарта и основных задач областей знаний SWEBOK. В этих целях рассмотрим сначала соответственно их процессы.
Сопровождение ПО (Software maintenance)
Сопровождение ПО – совокупность действий по обеспечению работы ПО, а также по внесению изменений в случае обнаружения ошибок в процессе эксплуатации, по адаптации ПО к новой среде функционирования, а также по повышению производительности или других характеристик ПО. В связи с решением проблем 2000года сопровождение стало рассматриваться как более важный процесс, который должен строго обеспечиваться и обновляться участниками разработчиков. Новая версия системы должна решать те же задачи, иметь план переноса информации БД и учет стоимости сопровождения. Сопровождение (согласно стандартов ISO/IEC 12207 и ISO/IEC 14764) считается модификацией программного продукта в процессе эксплуатации при условии сохранения целостности продукта.
Область знаний «Сопровождение ПО (Software maintenance)» состоит из следующих описаний разделов:
– основные концепции (Basic Concepts),
– процесс сопровождения (Process Maintenance),
– ключевые вопросы сопровождения ПО (key Issue in Software Maintenance) ,
– техники сопровождения (Techniques for Maintenance).
Сопровождение рассматривается с точки зрения удовлетворения требований в данном ПО, корректности его выполнения, процессов обучения и оперативного учета процесса сопровождения.
Основные концепции включают базовые определения и терминологию, подходы к эволюции и сопровождению ПО, а также к оценке стоимости сопровождения и др.
К основным определениям относится ЖЦ ПО (стандарт ISO/IEC 12207) и документация. Эта область трактуется, как процесс выполнения, анализа необходимости модификации, оценки стоимости работ по изменению функций. Рассматриваются проблемы, связанные с увеличением сложности продукта при большом количестве изменений и преодоления этого.
Процесс сопровождения включает: модели процесса сопровождения и планирование деятельности людей, которые проводят запуск ПО, проверку правильности его выполнения и внесения в него изменений. Процесс сопровождения согласно стандарту ISO/IEC 14764 проводиться путем:
– корректировки, т.е. изменения продукта при реализации обнаруженных ошибок и нереализованных задач;
– адаптации, т.е. настройки продукта к изменившимся условиям эксплуатации или новой среды выполнения данного ПО;
– улучшения, т.е. изменения продукта для повышения производительности или уровня сопровождения;
– проверки ПО для поиска и исправления скрытых ошибок, обнаруженных при эксплуатации системы.
Ключевые вопросы сопровождения ПО. Основными из этих вопросов являются управленческие, измерительные и стоимостные. Сущность управленческих вопросов состоит в контроле ПО в процессе модификации, совершенствовании функций и недопущении снижения производительности системы. Оценка стоимости затрат на сопровождение зависит от типа ПО, квалификации персонала, платформы и др. Знание этих факторов позволяет не только их сохранить, но и уменьшить. Вопросы измерения относятся к оценке характеристик системы после ее модификации, например, после тестирования оценка качества полученного ПО.
Эволюция ПО. Известный специалист в области ПО Леман (1970г.) предложил рассматривать сопровождение как эволюционную разработку программных систем, поскольку сданная в эксплуатацию система не всегда является полностью завершенной, ее надо изменять в течение срока эксплуатации. В результате программная система становиться более сложной и плохо управляемой, возникает проблема уменьшения ее сложности. К техникам эволюции ПО относятся реинженерия, реверсная инженерия и рефакторинг.
Реинженерия – это улучшение возможностей, функций в устаревшем ПО путем его реорганизации и реструктуризации, перепрограммирования или настройка на другую платформу или среду с обеспечением удобства его сопровождения
Реверсная инженерия состоит в восстановлении спецификации (графов вызовов, потоков данных и др.) по полученному коду системы (особенно, когда в нее внесено много изменений) для наблюдения за ней на более высоком уровне. Восстанавливается идентификация программных компонентов и связей между ними для обеспечения перестройки системы к новой форме.
Рефакторинг ориентирован на улучшение структурных характеристик и качественных показателей объектно-ориентированных программ без изменения их поведения. Этот процесс реализуется путем изменения отдельных операций над текстами, интерфейсами, средой программирования и выполнения ПО, а также настройки или внесения изменений в инструментальные средства поддержки ПО. Если сохраняется форма существующей системы при изменении, то рефакторинг – один из вариантов обратной инженерии.
Таким образом: рассмотренные проблемы сопровождения позволяют специалистам узнать весь круг вопросов сопровождения, эволюции и унаследования старых программных систем.
Спецификация ПИК
В качестве ПИК могут быть объекты, созданные в рамках объектно–ориентированного программирования с наследованием их реализации, а также компоненты в компонентном программировании, для них наследуется не реализация, а интерфейсы. При этом компонент обладает такими свойствами:
– связывания компонентов на последних этапах разработки ПС,
– инкапсуляции (компонент, как “черный ящик ” без вмешательств в код),
– наследования интерфейсов,
– повторное использование кода.
Для компонентов повторного использования сложилось несколько разных определений.
Определение 1. Компонент ПИК – это некоторая функция с определенными атрибутами, обеспечивающая функциональность, взаимодействие со средой и поведение.
Определения 2. Готовый к повторному использованию компонент представляет собой совокупность методов определенной сигнатуры и типов данных, которые передаются и возвращаются после выполнения метода.
Определение 3. ПИК – это самостоятельный программный элемент, который удовлетворяет определенным функциональным требованиям, требованиям архитектуры, структуры и организации взаимодействия в заданной среде, имеет спецификацию, помогающую пользователю объединять его с другими компонентами в интегрированную ПС.
Нас более всего интересует последнее определение компонента, модель спецификации которого имеет вид:
ПИК = ( T, I, F, R, S),
где T – тип компоненты, I – множество интерфейсов компонента; F – функциональность компонента; R – реализация (скрытая часть) – программный код;
S – сервис для взаимодействия со средой или шаблон развертывания.
Каждый из элементов спецификации компонента представляет собою видимую или скрытую от пользователя часть его абстракции.
В зависимости от сложности ПИК их можно разделить на следующие группы:
– простые компоненты (функция, модуль, класс и пр.);
– объекты–компоненты, имеющие интерфейс, функциональность и реализацию на любом ЯП, а также возможность дополнять спецификации шаблоном развертывания и интеграции;
– готовые к использованию ПИК (например, beans компоненты в Java, AWT компоненты, классы и др.);
– сложные ПИК типа каркасов, паттернов с элементами группирования из нескольких простых ПИК и взаимодействия между ними при решении одной общей задачи ПС.
Большое количество готовых компонентов требует от разработчиков и пользователей задания их категории, т.е. метаинформации о том, какие классы совместимы с заведомо определенными семантическими ограничениями описания ПИК, и состоят из:
– интерфейсов, которые реализуют компоненты,
– механизмов повторного использования,
– среды развертывания компонента
– сервиса, поддерживаемого компонентом,
– ролей, которые выполняют компоненты в ПС,
– формализованные языки описания ПИК.
Современная технология применения ПИК базируются на таких особенностях:
– отображение, как способность ПС анализировать самого себя и описывать свои возможности динамично во время выполнения, а не во время компиляции, что обеспечивает управление большинством свойств, событий и методов компонента;
– анализа компонента для определения его возможностей.
– отсутствие средств поддержки реинженерии программного компонента и необходимости задания параметров его разработки;
– способности компонента к рефакторингу т.е. к трансформации компонента с сохранением функциональности, но с возможным изменением структуры и исходного кода для повторного использования.
– сохранение параметров конфигурации (шаблонов отладки) в постоянной памяти для использования в нужное время;
– регистрация сообщений о событиях, полученных от других объектов либо через ссылки (например, beans компоненты и инструментарий архива в технологии JAVA), а также группирование компонентов в JAR файле для дальнейшего повторного использования;
– использование компонента в разных языковых средах;
– адаптация ПИК к разным контекстам их использования и выделение свойств, которые мешают повторному использованию и модификации для применения в конкретных целях.
Компоненты в отличие от объектов могут изменяться и пополняться новыми функциями и интерфейсами. Они конструируются в виде некоторой программной абстракции, состоящей из трех частей: информационной, внешней и внутренней.
Информационная часть содержит описание: назначение, даты изготовления, условия применения (ОС, платформа и т.п.), возможностей ПИК, среды окружения и др.
Внешняя часть – это интерфейс, который определяет взаимодействие компонента с внешней средой и с платформой, на которой он будет выполняться и включает следующие общие характеристики:
– интероперабельность – способность взаимодействовать с компонентами других сред;
– переносимость – способность компонента выполняться на разных платформах компьютеров;
– интеграционость – объединение компонентов на основе интерфейсов в более сложные ПС;
– нефункциональность – требование на обеспечение безопасности, надежности и защиты компонентов и данных.
Внутренняя часть компонента – это программный фрагмент кода, системная или абстрактная структура, представленные в виде проекта компонента, спецификации и выходного кода.
Данная часть компонента состоит из полей (рис.6.1):
– интерфейса (interfaces),
– реализации (implementation),
– схемы развертки (deployment).
|
Структурные части компонента |
||
 ¨ Один или несколько; ¨ Уникальность именования в пределах системы; ¨ Клиентский или серверный (входной или выходной); ¨ Определенная сигнатура; ¨ Описание методов взаимодействия |
Реализация ¨ Одна или несколько; ¨ Ориентация на конкретную платформу и операционное окружение ¨ Выбор конкретной реализации; ¨ Поддержка интерфейсов компонента |
Схема развертывания ¨ Типовость процедуры развертывания; ¨ Управляемость; ¨ Настраиваемость на операционную среду; ¨ Модифицируемость |
Рис.6.1. Структурные части компонента
Интерфейс компонента содержит обращения к другим компонентам через описание параметров средствами языков IDL или APL. В нем указываются типы данных и операции передачи параметров для взаимодействия компонентов друг с другом. Каждый компонент может реализовать совокупность интерфейсов. Интерфейс компонента – это видимая часть спецификации компонента, которая является неизменной и обязательной в описании компонента. Например, система Inspector Components предназначена для изменения необходимых параметров интерфейса компонента без вмешательства в его код.
Параметры интерфейса могут определяться типом ПИК и включать в себя инварианту спецификации с указанием: типа и названия компонента, входных и выходных параметров, методов компонента и др. В языке JAVA, например, можно определять такие типы компонентов: проекты, формы (AWT компоненты), beans компоненты, COBRA компоненты, RMI компоненты, стандартные классы-оболочки, БД, JSP компоненты, сервелети, XML документы, DTD документы и т.п.
Реализация – это код, который будет использоваться при обращении к операциям, определенным в интерфейсах компонента. Компонент может иметь несколько реализаций, например, в зависимости от операционной среды или от модели данных и соответствующей системы управления базами данных, которая необходима для функционирования компонента.
Развертка - это физический файл или архив, готовый к выполнению, который передается пользователю и содержит все необходимые инструкции для создания, настройки и функционирования компонента.
Компонент описывается в ЯП, не зависит от операционной среды (например, от среды виртуальной машины JAVA) и от реальной платформы (например, от платформ в системе CORBA), где он будет функционировать.
Расширением понятия компонента есть паттерн – абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственность.Паттерн является повторяемой частью программного компонента, как схемы или взаимосвязи контекста описания решения проблемы.
Спиральная модель
Исходя из возможности внесения изменений как в процесс, так и в создаваемый промежуточный продукт была создана спиральная модель.
.
Реализация
Рис.2.3. Спиральная модель ЖЦ разработки программных систем
Это допущение ориентировано на удовлетворение потребности изменений сразу, как только будет установлено, что созданные артефакты или элементы документации (описание требований, проекта, комментариев различного вида и т.п.), не соответствуют действительному состоянию разработки после внесения некоторых изменений
Данная модель ЖЦ допускает анализ продута на витке разработки, его проверку, оценку его правильности и принятия решения двигаться на следующий виток или опуститься на нижний для доработки.
Отличие этой модели от каскадной модели состоит в возможности спиральной модели обеспечивать многоразовое возвращение к процессу формулирования требований и к повторной разработке с любого процесса выполнения работ.
На изображенной спиральной модели (рис.2.3), каждый виток спирали соответствует одной из версий разработки системы. При необходимости внесения изменений в систему на каждом процессе витка для получения версии системы, обязательно вносятся изменения в предварительно зафиксированные требования, после чего происходит возврат на предыдущий виток спирали для продолжения реализации новой версии системы с учетом изменений.
Средства и методы разработки архитектуры MSF
Micposoft Solutions Framеwork (MSF) – комплекс средств и методов процесса разработки проекта из скоординированного набора элементов (программно–технических средств, документации, обучения и сопровождения) для удовлетворения производственной архитектуры [15].
Базисом управления проектом построения производственной архитектуры предприятия является база знаний РМBOK, содержащая следующие области знаний:
– управление объемом работ в проекте,
– управление временем,
–управление стоимость,
– управление качеством,
– управление персоналом,
– управление коммуникациями,
– управление закупками и контрактами,
– управление рисками.
В рамках общего процесса управления проекта используется модель архитектуры предприятия, обеспечивающая планирование корпоративного развития предприятия с учетом четырех основных аспектов: бизнес, приложение, информация, технология.
Под реализацией производственной архитектурой понимается скоординированный технологический план создания и развития информационной системы (ИС) из главных ее элементов, соответствующих приоритету архитектуры и получению максимального эффекта при минимуме затрат с соблюдением баланса между целями и требованиями ИС, главными проектными решениями и человеческими и финансовыми ресурсами организации. Архитектор должен доказать, что затраты времени на разработку плана производственной архитектуры сэкономит время на создание всего проекта, при условии, что планирование, разработка и сопровождение могут осуществляться параллельно.
Так как любая организация имеет сложившуюся производственную архитектуру, то при ее оценке и применяется архитектурно–ориентированный метод для планирования, создания и сопровождения проекта на базе архитектуры более высокого уровня. После определения существующего уровня архитектуры организации можно приступить к планированию более совершенной архитектуры и определить направления работ для достижения цели.
Поэтому жизненно важно выполнять рационализацию производственных процессов, усовершенствовать структуру организации и внедрять новые технологии.
Средства стандарта ISO/IEC для преобразования данных
Цель этого стандарта состоит в том, чтобы обеспечить не только описание типов данных в языке LI (Language Independent), их генерацию, но и преобразование типов данных ЯП в LI–язык и наоборот. Стандарт предлагает специальные правила и характеристические операций генерации примитивных типов данных и их объединений LI–языка в более простые структуры данных ЯП, а также при определении параметров интерфейса, задаваемых в языках IDL, RPC и API.
Независимые от ЯП типы данных LI–языка разделены на примитивные, агрегатные, сгенерированные типы данных (рис.1), семейство типов данных и генератор типов данных.
Рис.8.1. Независимые от ЯП типы данных стандарта ISO/IEC 11404–1996
Типы данных в стандарте должны описываться в LI–языке, который в отличие от средств описания типов данных в ЯП является более общим языком, содержащим все существующие типы в ЯП и типы данных, ориентированные на генерацию других типов данных. Средствами LI описываются параметры вызова, как элементы интерфейса, необходимые при обращении к стандартным сервисам и готовым программным компонентам.
Стандарт имеет раздел объявления типов данных (рис.8.2), переименования существующих; объявление новых генераторов, значений и результатов. Каждый тип данных объявляется по шаблону, включающему описание и спецификатор типа данных, значение в пространстве значений, синтаксическое описание и операции над типами данных.
LI–язык предлагает следующие виды преобразования данных:
– внешнее преобразование из внутренних типов данных ЯП в LI–типы данных;
– внутреннее преобразование из LI–типы данных, в тип данных ЯП;
– обратное внутреннее преобразование.
Рис.8.2. Объявление типов данных в стандарте ISO/IEC 11404–1996
Суть внешнего преобразования типов данных и генераторов типов данных состоит в следующем:
а) для каждого примитивного типа для сгенерированного внешнего типа данных преобразование связывается с одним LI–типом данных;
в) для каждого внутреннего типа данных преобразование определяет связь между допустимым значением внутреннего типа данных и эквивалентным значением соответствующего LI–типа данных;
с) для каждого значения LI–типа данных, участвующего в преобразовании, определяется существование значения любого внутреннего типа данных, преобразуемого в LI–тип данных со взятием этого значения.
Внешнее преобразование документирует аномалии при идентификации внутренних типов и дает гарантию того, что интерфейс между программными компонентами адекватно задается сервисным средством и игнорирует среду ЯП.
Внутреннее преобразование связывает примитивный тип данных или сгенерированный в LI–тип данных с конкретным внутренним типом данных ЯП. Представители отдельного семейства LI–типа данных могут преобразовываться в различные внутренние типы данных ЯП. Данное преобразование обладает следующими свойствами:
а) для каждого LI–типа данных (примитивного или сгенерированного) преобразование определяет наличие этого типа данных в ЯП;
в) для каждого LI–типа данных преобразование определяет отношение между допустимым значением этого типа и эквивалентным значением соответствующего внутреннего типа ЯП;
с) для каждого значения внутреннего типа данных преобразование определяет является ли это значение образом (после преобразования) какого–то значения LI–типа данных и способ преобразования.
Обратное внутреннее преобразование для LI–типа данных состоит в преобразовании значений внутреннего типа данных в соответствующее значение LI–типа при наличии соответствия и отсутствия двусмысленности. Это преобразование для ЯП является коллекцией обратных внутренних преобразований LI–типа данных.
В стандарте приведен набор приложений. В приложении А приведен перечень действующих стандартов (около 40), определяющих наборы символов. Для обеспечения совместимости используемых и реализуемых типов данных в приложении В содержатся рекомендации по идентификации типов данных и описанию аннотаций для атрибутов, параметров и др.В приложении С даны рекомендации по соответствующим внутренним типы данных, которые должны преобразовываться LI–типы данных. В приложении D показано, что синтаксис LI–языка является подмножеством стандарта IDM (Interface Definition Notation), предназначеного для описания интерфейса в LI–языке, Приведен вариант внутреннего преобразования LI–типов данных в типы данных ЯП Паскаль (ISO/IEC 7185–90). В нем рассмотрены примеры преобразования примитивных типов данных LI–языка (логический, перечислимый, символьный, целый рациональный и др.) в типы данных языка Паскаль.
Предложенные в стандарте рекомендации, средства описания типов данных и методы их преобразования является универсальными и в настоящий момент не имеют общей программной поддержки.
Средства унифицированного процесса RUP
RUP (Rational Unified Process) – это процесс моделирования и построения ПС из объектов с применением языка UML. Он включает теоретический и прикладной аспекты представления и толкования создаваемых моделей для проектируемой предметной области [12, 13].
Теоретический аспект процесса моделирования моделей ПС поддерживается методами и понятиями формальных теорий. Формализация моделей в RUP обеспечивается средствами UML и дает возможность строго описывать требования и преобразовывать их к готовому продукту.
Основу процесса моделирования составляют прецеденты – варианты использования для определения требований к системе. Главный элемент проектирования – модель вариантов использования, на основе которой разрабатываются модели анализа, проектирования и реализации системы. Каждая модель анализируется на соответствие модели вариантов использования, в которую входят входные данные для поиска и спецификации классов и подсистем, для подбора и спецификации тестов, а также при планировании итераций разработки и интеграции ПС. В процессе моделирования создаются следующие модели:
– вариантов использования, отражающих взаимодействие между пользователями и ПС;
анализа, обеспечивающего спецификации требований к системе и описание вариантов использования как кооперации между концептуальными классификаторами;
– проектирования, ориентированного на создание статической структуры и интерфейсов системы, реализацию вариантов использования в виде набора коопераций между подсистемами, классами и интерфейсами;
– реализации, включающей компоненты системы в исходном виде на ЯП;
– тестирования;
– размещения компонентов и выполнение в операционной среде компьютеров.
Эти модели представляются разными видами диаграмм, например, в модели вариантов использования диаграммы use–case, в моделях анализа – диаграммы классов, коопераций и состояний. Данные модели – взаимосвязанные, семантически пересекаются и определяют систему как единое целое.
Например, вариант использования в соответствующей модели может иметь отношение зависимости к кооперации в модели проектирования, задающей реализацию. Модели, определенные на каждой итерации процесса RUP, уточняются или расширяют модели предыдущих итераций процесса
Типы моделей и их связи показаны на рис.11.1, каждая из моделей задается соответствующими диаграммами. Например, модель анализа состоит из диаграмм классов, состояний и кооперации.
Артефакты одной модели связаны между собой и должны быть совместимы друг с другом. Отношения между моделями являются не полностью формальными, поскольку части моделей специфицированы на языке метамодели, а другие описаны только неформально, на естественном языке. Спецификации диаграмм UML является также полуформальними.
 |
 |
|||||
 |
|||||
 |
|||||
проектирования
Модель
Модель
Рис.11. 1. Связь моделей в системе RUP
Основу модели анализа составляет диаграмма варианта использования, которая включает в себя диаграммы классов, взаимодействия, задающие возможные сценарии вариантов использования в терминах взаимодействия объектов на этапе анализа.
Варианты использования специфицируют тип отношений между действующим лицом (актером), пользователем и системой. На высоком уровне абстракции они представляются упорядоченной последовательностью действий или альтернатив.
Вариант использования в UML – это разновидность классификатора, операциями которого являются сообщения, получаемые экземплярами конкретного варианта использования. Методы задают реализацию операций в терминах последовательностей действий, выполняемых экземплярами варианта использования. Пример.
Пусть uc – вариант использования (uс – use case), операция которого выполняется над учетной записью и имеет следующее определение:
uc.operations = <op1>
op1.name = запрос и обновление учетной записи
op1.method.body = {< проверка идентификации пользователя, наличия сервиса,
запроса о долгах, обновление учетной записи >,
< проверка идентификации пользователя, отклонение учетной записи >,
< проверка идентификации пользователя, наличия сервиса, отклонение учетной записи >,
< проверка идентификации пользователя, проверка наличия сервиса, запроса о долгах,
запроса на оплату, обновление учетной записи >}
Тело метода – процедура, специфицирующая реализацию операций в виде последовательности действий op.method.body или op.action Sequence. Между именами действий варианта использования и именами действий в кооперации устанавливается отображение, что обеспечивает гибкость в процессе разработки и модификацию имен действий. Между кооперацией и вариантом использования uc создается отношение реализации.
Вариант использования реализуется кооперацией, если роли классификаторов в ней взаимодействуют для обеспечения поведения.
Если кооперация имеет более сложное поведение, чем специфицированное вариантом использования, то этот вариант использования – частичная спецификация поведения кооперации. Варианты использования специфицируют действия, видимые за пределами системы, но не специфицируют внутренних действий (создание и удаление экземпляров классификаторов, взаимодействие между экземплярами классификаторов и т.д.).
Определение расширения включает как условие расширения, так и ссылку на точку расширения в целевом варианте использования, которая является позицией внутри варианта использования. Как только экземпляр варианта использования достигает точки расширения, на которую ссылается это отношение, проверяется его условие. Если условие выполняется, последовательность, удовлетворяющая условиям в экземпляре варианта использования, расширяется таким образом, чтобы включить в себя последовательность расширяемого варианта использования.
С практической точки зрения RUP представляется упорядоченным набором шагов и этапов ЖЦ, которые выполняются итеративно. Этот процесс является управляемым, как в смысле задания требований, так и реализации функциональных возможностей ПрО с заданным уровнем качества и гарантированными затратами согласно графика работ. Оценка качества всех шагов и действий участников процесса базируется на определенных критериях.
Шаги при выполнении RUP управляются прецедентами, т.е. технологическим маршрутом от делового моделирования и требований до испытаний. Экземпляр прецедента – это последовательность действий, выполняемых системой с наблюдаемым результатом для конкретного субъекта. Функциональные возможности системы определяются набором прецедентов, каждый из которых представляет некоторый поток событий. Описание прецедента определяет то, что произойдет в системе, когда прецедент будет выполнен. Каждый прецедент ориентирован на задачу, которую он должен выполнить. Набор прецедентов устанавливает все возможные пути (маршруты) выполнения системы.
Прецеденты играют роль в каждом из пяти основных работ процесса: формирование требований, анализ, проектирование, реализация и испытание.
RUP содержит пять основных этапов, выполняемых на всех фазах процесса разработки ПС. Завершение этих этапов называется итерацией, при которой заканчивается выпуском промежуточного продукта. На каждой итерации цикл повторяется, начиная со сбора и уточнения требований.
Этап формирования требования. На этом этапе проводится сбор функциональных, технических и прикладных требований к проекту. На основе требований заказчика и пользователей система описывается так, чтобы достичь понимания между ними и проектной группой. Информация собирается с учетом особенностей существующих систем и документов, подготовленных заказчиком, и включает:
– модель ПрО;
– модель схем использования с описанием функциональных и общих требований в форме результатов опрашивания, наборов диаграмм и детального описания каждой схемы;
– дизайн и прототип интерфейса пользователя для каждого актера;
– список требований, которые не относятся к конкретным схемам использования.
Этап анализа.
Сформулированные требования уточняются и отображаются в модели сценариев использования. Кроме того, создается аналитическая модель системы, которая включает формализмы для анализа внутренней структуры системы, определения классов и превращения этой модели в проектные концепции и схемы их реализация.
Этап проектирования служит для уточнения классов и описания их относительно четырех уровней: пользовательского интерфейса, бизнесов–решений, уровня доступа и уровня данных. Создаваемая проектная модель системы состоит из структуры подсистем, их распределения между уровнями, интерфейсов классов и объектов, связей классов с узлами развертывания (модель развертывания).
На этапе реализации выполняется построение прототипа из компонентов; создания тестов по схемам использования; тестирование и интеграция компонентов; проверка архитектуры; переход к следующей итерации.При каждой итерации тестовая модель уточняется путем исключения неактуальных тестов, создания схемы регрессионного тестирования и добавления тестов для собираемых компонентов. Каждый тест создается с помощью вариантов использования и реализует конкретный метод проверки функций системы на входных данных.
RUP – методология оформлена и размещена в Web базе знаний поисковой системы. В ней регламентированы этапы разработки ПО, документы и инструментальные средства для обеспечения каждого этапа ЖЦ.
Стандарт разработки документации на АС – ГОСТ
Стандарт 34.201–89 («Информационная технология. Виды, комплектность и типы документов при создании АС») определяет набор разных видов документов и их комплектность для разрабатываемой АС. К документам относятся: отчеты об обследовании предметной области, результаты научно–исследовательской работы, техническое задание, эскизный проект, технический проект и рабочий проект.
Отчеты об обследовании и научно–исследовательской работе, а также эскизный проект АС создаются в произвольной форме, их структура и содержание согласуются с заказчиком и разработчиком системы. Содержание и структура технического задания, технического и рабочего проектов определяют соответствующие государственные стандарты, например, ГОСТ 34.601–90.
Техническое задание для АС – это основной документ, который определяет требования и порядок его создания или модернизации и может содержать такие разделы:
1. Общие сведения. ,
2. Назначение и цель создания системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
5. Состав и содержание работ по созданию системы.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие.
8. Требования к документации.
9. Источники разработки.
В техническое задание разрешается вносить некоторые новые разделы или их объединять и детализировать отдельно.
1. Общие сведения. Раздел знакомит со структурой организации заказчика и разработчика, определяет источники финансирования разработки, сроки начала и окончания работ, порядок оформления результатов проектных работ.
2. Назначение и цель создания системы. Раздел содержит описание целей создаваемой АС, ее назначение и возможности ее автоматизации с применением средств вычислительной техники. Дается обоснование необходимости создания АС и решения о выделении необходимого финансирования.
3. Характеристика объекта автоматизации.
Алгоритм решения подается в виде схемы в соответствии с требованиями ГОСТ 19.701–90, дополненное текстом в соответствии с ГОСТ 24.301–80 « Система технической документации на АСУ. Общие требования к выполнению текстовых документов».
Информационное обеспечение содержит описание: характеристик, организации сбора и передачи информации на обработку, системы классификации и кодирования; структуры документов и информационных массивов.
Организационное обеспечение содержит схему технологического процесса автоматизированного сбора, обработки информации, передачи данных с перечнем соответствующей документации.
Программное обеспечения включает его характеристику, схема взаимодействия программ и схемы самих программ.
В состав документов рабочего проекта входят такие документы:
– описание программ решения задачи;
– инструкции по технологическому процессу или руководству пользователя;
– классификаторы технико–экономической информации.
9. Источники разработки. В разделе перечисляются документы и информационные материалы, которые использовались во время разработки ТЗ, а также те, которые потребуются во время создания информационной подсистемы.
Стандартизованная модель системы
Типичный ЖЦ разработки системы начинается с формулировки идеи или потребности, проходит все процессы разработки, производства, эксплуатации и сопровождения системы. ЖЦ в практике программирования обычно делиться на этапы, процессы. Каждый процесс характеризуется видами деятельности и задачами, которые выполняются на нем. Переход от одного процесса к другому должен быть санкционирован (определены входные и выходные данные).
Модель общего стандартизованного ЖЦ, как правило, включает в себя следующие процессы:
– определение требований;
– разработка (проектирование);
– верификация, валидация, тестирование;
– изготовление;
– эксплуатация;
– сопровождение.
Данной модели соответствует все виды деятельности, которые начинаются с разработки идеи проблемы или концепции программного продукта и кончая его изготовлением. Стандарт ISO/IEC 12207 объединяет эти виды деятельности в основные, организационные и вспомогательные процессы, которые и составляют ЖЦ ПО.
Процессы ЖЦ приобретения, поставки и разработки используются для анализа и определения системных требований, решений верхнего уровня проектирования системы, и предварительного определения требований к компонентам системы, включая ПО. Процесс разработки может быть использован для анализа, демонстрации, валидации, тестирования, прототипирования требований и проектных решений.
На этом этапе проектирования разрабатывается техническое, программное, организационное обеспечение системы, а также проектируются, разрабатываются, интегрируются, тестируются и оцениваются компоненты системы. Результатом этого процесса является система, которая соответствует нужному продукту.
Исходный стандарт разработан так, чтобы его можно было применить полностью или частично. Процессы, действия и задачи основных процессов отбираются, адаптируются и применяются для разработки или модификации ПО. Процесс проектирования может включать одну или более итераций процесса разработки. Результатом являются основные требования к ПО, проект и его реализация.
Если разрабатываемое ПО является частью системы, то могут понадобиться все действия процесса разработки, а если – автономное ПО, то все действия на уровне системы могут не понадобиться.
Во время процесса производство – изготовление спроектированная и разработанная система изготавливается для заказчика или для покупателей. Целью процесса является производство и установка работающей системы у заказчика для сопровождения. Для ПО данный процесс заключается в копировании изготовленного ПО и документации на соответствующие носители для различных пользователей. К видам деятельности на процессе относится – управление реализацией и конфигурацией. Другие вспомогательные процессы и действия могут применяться при необходимости.
Изготовленная система передается заказчику или продается покупателям. Период развертывания системы начинается с поставки первой работающей ее версии заказчику. Продажа системы начинается с первой версии системы, которая поставляется всем покупателям и заканчивается изъятием с рынка. Другие процессы (приобретения, поставки и разработки) могут использоваться при инсталляции и проверки разработанной или модифицированной системы.
Процесс эксплуатации включает использование системы пользователями и покупателями и заканчивается, когда система больше не удовлетворят пользователей и она удаляется из эксплуатации.
Во время сопровождения система модифицируется, вследствие обнаруженных ошибок и недостатков в ее разработке либо по требованиям пользователя, которому желает ее адаптировать к новой среде или усовершенствовать отдельные функции системы. Данный процесс включает обеспечение логической, технической и программной документации пользователю.
Процесс удаление системы означает снятие ее с обслуживания, удаление ее архивов и носителей кодов системы.
Стандартный метод оценки значений показателей качества
Оценка качества ПО согласно четырех уровневой модели качества начинается с нижнего уровня иерархии, т.е. с самого элементарного свойства оцениваемого атрибута показателя качества согласно установленных мер. На этапе проектирования устанавливают значения оценочных элементов для каждого атрибута показателя анализируемого ПО, включенного в требования.
По определению стандарта ISO/IES 9126–2 метрика качества ПО представляет собой “модель измерения атрибута, связываемого с показателем его качества”. Для пользования метриками при измерения показателей качества данный стандарт позволяет определять следующие типы мер:
– меры размера в разных единицах измерения (количество функций, размер программы, объем ресурсов и др.);
– меры времени – периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.);
– меры усилий – продуктивное время, затраченное на реализацию проекта (производительность труда отдельных участников проекта, коллективная трудоемкость и др.);
– меры интервалов между событиями, например, время между последовательными отказами;
– счетные меры – счетчики для определения количества обнаруженных ошибок, структурной сложности программы, числа несовместимых элементов, числа изменений (например, число обнаруженных отказов и др.).
Метрики качества используются при оценки степени тестируемости после проведения испытаний ПО на множестве тестов (безотказная работа, выполнимость функций, удобство применения интерфейсов пользователей, БД и т.п.).
Наработка на отказ, как атрибут надежности определяет среднее время между появлением угроз, нарушающих безопасность, и обеспечивает трудно измеримую оценку ущерба, которая наносится соответствующими угрозами.
Очень часто оценка программы проводится по числу строк. При сопоставлении двух программ, реализующих одну прикладную задачу предпочтение отдается короткой программе, так как её создает более квалифицированный персонал и в ней меньше скрытых ошибок и легче модифицировать. По стоимости она дороже, хотя времени на отладку и модификацию уходит больше.
Т.е. длину программы можно использовать в качестве вспомогательного свойства при сравнении программ с учетом одинаковой квалификации разработчиков, единого стиля разработки и общей среды.
Если в требованиях к ПО было указано получить несколько показателей, то просчитанный после сбора данных при выполнении показатель умножается на соответствующий весовой коэффициент, а затем суммируются все показатели для получения комплексной оценки уровня качества ПО.
На основе измерения количественных характеристик и проведения экспертизы качественных показателей с применением весовых коэффициентов, нивелирующих разные показатели, вычисляется итоговая оценка качества продукта путем суммирования результатов по отдельным показателям и сравнения их с эталонными показателями ПО (стоимость, время, ресурсы и др.).
Т.е. при проведении оценки отдельного показателя с помощью оценочных элементов просчитывается весомый коэффициент k – метрика, j – показатель, i – атрибут. Например, в качестве j – показателя возьмем переносимость. Этот показатель будет вычисляться по пяти атрибутам (i = 1, ..., 5), причем каждый из них будет умножаться на соответствующий коэффициент ki.
Все метрики j – атрибута суммируются и образуют i – показатель качества. Когда все атрибуты оценены по каждому из показателей качества, производится суммарная оценка отдельного показателя, а потом и интегральная оценка качества с учетом весовых коэффициентов всех показателей ПО.
В конечном итоге результат оценки качества является критерием эффективности и целесообразности применения методов проектирования, инструментальных средств и методик оценивания результатов создания программного продукта на стадиях ЖЦ.
Для изложения оценки значений показателей качества используется стандарт [4] в котором представлены следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов).
Измерительный метод базируется на использовании измерительных и специальных программных средств для получения информации о характеристиках ПО, например, определение объема, числа строк кода, операторов, количества ветвей в программе, число точек входа (выхода), реактивность и др.
Регистрационный метод используется при подсчете времени, числа сбоев или отказов, начала и конца работы ПО в процессе его выполнения.
Расчетный метод базируется на статистических данных, собранных при проведении испытаний, эксплуатации и сопровождении ПО. Расчетными методами оцениваются показатели надежности, точности, устойчивости, реактивности и др.
Экспертный метод осуществляется группой экспертов – специалистов, компетентных в решении данной задачи или типа ПО. Их оценка базируются на опыте и интуиции, а не на непосредственных результатах расчетов или экспериментов. Этот метод проводится путем просмотра программ, кодов, сопроводительных документов и способствует качественной оценки созданного продукта. Для этого устанавливаются контролируемые признаки, коррелируемые с одним или несколькими показателями качества и включаемые в опросные карты экспертов. Метод применяется при оценке таких показателей как, анализируемость, документируемость, структурированность ПО и др.
Для оценки значений показателей качества в зависимости от особенностей используемых ими свойств, назначения, способов их определения используются шкалы:
– метрическая (1.1 – абсолютная, 1.2 – относительная, 1.3 – интегральная);
– порядковая (ранговая), позволяющая ранжировать характеристики путем сравнения с опорными;
– классификационная, характеризующая только наличие или отсутствие рассматриваемого свойства у оцениваемого программного обеспечения.
Показатели, вычисляемые с помощью метрических шкал, называются количественными, а с помощью порядковых и классификационных – качественными.
Атрибуты программной системы, характеризующие ее качество, измеряются с использованием метрик качества.Метрика определяет меру атрибута, т.е. переменную, которой присваивается значение в результате измерения. Для правильного использования результатов измерений каждая мера идентифицируется шкалой измерений.
Стандарт ISO/IES 9126–2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:
– номинальная шкала отражает категории свойств оцениваемого объекта без их упорядочения;
– порядковая шкала служит для упорядочивания характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями;
– интервальная шкала задает существенные свойства объекта (например, календарная дата);
– относительная шкала задает некоторое значение относительно выбранной единицы;
– абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).
Стандартный подход к проектированию системы
Разработка автоматизированных систем (АС) выполнялась и выполняется на основе положений, представленных в стандарте ГОСТ 34.601-90 (см. Приложение 2). Он состоит из стадий и этапов разработки АС, которые, в зависимости от особенностей автоматизируемой системы, можно объединять друг с другом или вообще не включать в процесс разработки. Основанием для разработки АС является договор между разработчиком системы и ее заказчиком.
Этапами стандарта, ориентированным на разработку архитектуры АС, являются: формирование требований к АС, разработка концепции АС и проектирование технического проекта, в котором на основе сформулированных требований и концепций их реализации задаются конкретные задачи системы и пути их решения.
Эти этапы заканчивается созданием и утверждением отчета о научно-исследовательской работе, в которой дается оценка необходимых для реализации АС ресурсов, вариантов разработки АС и порядка проведения оценки качества системы.
На этапе разработки эскизного проекта используются проектные решения ко всей системе или ее части и определяется перечень задач системы, концепция информационной базы, функции и параметры основных программных компонентов системы, а также основные алгоритмы обработки информации.
Этап разработки технического проекта предусматривает разработку проектных решений относительно системы и ее частей, разработку документации на АС и комплектацию АС, а также определение технических требований на систему и проектирование задач для смежных частей проекта.
Проектные решения определяют организационную структуру, функции персонала АС, структуру технических средств, языка программирования, СУБД, общие характеристики ПО, систему классификации и кодирования, а также варианты ведения информационной базы системы.
Таким образом, данный стандарт обеспечивает:
– концептуальное проектирование, которое состоит в уточнении и согласовании деталей требований;
– архитектурное проектирование, которое состоит в определении главных структурных особенностей создаваемой системы;
Количество выдаваемых знаков в текстах определяется лаконизмом избранного языка общения (английский наиболее лаконичней). Длина текстовых сообщений и окон ввода текстов должна определяться как параметр настройки будущей системы.
Правила навигации должны учитывать традиции чтения слева - направо или наоборот.
Таким образом, общей рекомендацией концепций проектирования является построение полностью всех экранных форм системы и "проигрывание" с пользователем для выбора разных вариантов, отвечающих его вкусам. Такой выбор часто входит в в противоречие с заданными характеристиками интерфейса (например, удобство доступа и обеспечение конфиденциальности, быстродействие и сложность обработки и др.).
Для построения интерфейсов существует широкий выбор методов и средств. Большинство из них базируется на фиксации определенных классов объектов интерфейса (выбор из меню, заполнение экранных форм и др.) и средствах монтирования их в программную систему в виде интегрированных блоков или автономных подсистем интерфейса с пользователем.
При техническом проектировании системы на основе модели представления требований и понятий объектно–ориентированного подхода проводится уточнение состава и содержания функций, присущих им операций (методов), а также схем взаимодействия объектов.
Содержание операций, которые способны выполнять объекты, может быть раскрыто с помощью диаграмм потоков данных (см. тема 3.).
Взаимодействие объектов организовывается путем обмена сообщений, в ответ на которые они выполняют соответствующие операции и изменяют свое состояние, или посылают сообщения другим объектам.
Для уточнения поведения объектов можно использовать ряд диаграмм, отображающих различные аспекты взаимодействия объектов. Такие диаграммы входят в состав метода UML.
Все уточнения, которые делаются относительно данных, интерфейсов и поведения объектов в сценарии, могут привести к необходимости пересмотра моделей анализа требований и даже состава объектов. Изменения надо начинать с продуктов этапа инженерии требований, а именно модели анализа требований и др.
Трудозатраты на поиск мест локации необходимых изменений в упомянутых моделях уменьшается при применении метода трассирования требований.
Определяются нефункциональные требования, задающие определенные ограничения структурой организации системы или среды использования. К отдельным разновидностям нефункциональных требований относятся требования секретности, безопасности, отказоустойчивости, корпоративной работы над общими ресурсами и др.
При построении моделей требований для автоматизированных систем учитывается их роль и место в прикладных приложениях системы. Для них разработано немало национальных, корпоративных и ведомственных стандартов, которые фиксируют правила обеспечения защиты данных, безопасности системы и др.
Результатом формирования нефункциональных требований может быть расширение модели требований дополнительными сведениями или соответствующими объектами, выполняющими требования взаимодействия, безопасности, защиты данных и др.
Стандарты программной инженерии
Существует определенное количество организаций, профилирующими направлениями деятельности которых есть разработка и сопровождение стандартов. В зависимости от области применения стандарт может иметь статус международного, ведомственного или стандарта предприятия. Главным органом установления международных стандартов является международная организация по стандартизации (The International Standards Organization или сокращенно ISO), которая работает в сотрудничестве с международной электротехнической комиссией (The International Electrotechnical Commission или сокращенно IEC). Все утвержденные ими совместно стандарты имеют идентификатор, который состоит из префикса ISO/IEC, серийного номера стандарта и даты выпуска, например: ISO/IEC 12207: 1995 – 08–11.
Каждый стандарт ISO/IEC имеет также название, которое при ссылках указывается после идентификатор. ISO/IEC имеет десятки технических профильных комитетов, в частности технический комитет "Информационные технологии", одним из технических подкомитетов которого является подкомитет по программной инженерии. Существуют также международные объединения по отдельным проблемным областям, которые выпускают стандарты для соответствующих приложений. Каждое цивилизованное государство имеет свои национальные органы стандартизации.
Большинство национальных комитетов по стандартизации признает стандарты ISO/IEC и входит в ее состав, и проводят для стандартов ISO/IEC процедуру гармонизации, т.е. их приспособление к национальным условиям и особенностям применения ( как например, национальные алфавиты, метрические системы, валютные знаки и т.п.).
Главным источником стандартов является профессиональные объединения, в частности для программной инженерии – IEEE Computer Society. На данное время существует свыше 300 стандартов IEEE для программной инженерии, значительная часть которых принимается во внимание широким кругом разработчиков программных систем.
Практически большинство стандартов программной инженерии исторически появляются как стандарты IEEE, а со временем, после испытания опытом использования, вносятся как кандидаты в стандарты ISO/IEC.
Процедура утверждения стандартов ISO довольно сложная. Имеется несколько стадий прохождения кандидата в стандарт, для любой из них предусмотрена рассылка предложений на экспертизу всем национальным комитетам, сбор замечаний, их обработка и голосование для создания новой версии.
Эта процедура для некоторых стандартов может длиться годами относительно официальных стандартов или стандартов де–юре. Бюрократизированная процедура приводит к тому, что технически доведенные до кондиции стандарты могут за время утратить свою значимость для индустрии программного обеспечения и соответствие действующему уровню технологии.
Тем временем индустрия создает так называемые "стандарты де–факто", которые фактически находят массовое использование независимо от того, утверждены они компетентными плановыми органами или нет, так как они являются наиболее актуальными в индустрии программных систем.
Термином "стандарт де–факто" обозначаются спецификации на проект стандарта (или внутренний стандарт), которые публикуются некоторым консорциумом (группой учреждений, которые официально работают для общей цели стандартизации) или фирмой, получившие общее одобрение от других разработчиков, и этот проект стал восприниматься как необходимое современное направление технологии.
Например, проектные решения консорциума Object Management Group (OMG) по управлению транзакциями стали стандартом де–факто и утверждены комитетом ISO, модель UML фирмы Rational Rose определена как стандарт моделирования артефактов программной инженерии, язык JAVA – претендент на стандарт, который активно используется на рынке, и др.
Стандарты де–факто, благодаря своему соответствию актуальным потребностям рынка, распространяются и внедряются довольно быстро, потому что их отработка и апробация проходит внутри групп, которые их создают, а публикация этих стандартов обозначает, как "зрелые" решения.
Учитывая вышесказанное, влиятельные международные организации и, в первую очередь ISO, которые являются разработчиками стандартов де–юре, признали, что они не являются монопольными и компетентными источниками всех стандартов и поэтому ввели процесс преобразования стандартов де–факто на стандарты де–юре, которые в этом случае получили название общедоступной спецификации (Public–Available Specifications – сокращенно PAS).
Объекты стандартизации. Согласно эталонной модели программной инженерии, в ней определены такие главные элементы :
– процессы разработки ПО;
– продукты разработки;
– ресурсы, которые используют процессы для создания программного продукта.
Важным элементом моделирования проблем предметной области является клиент (заказчик), который заказывает программную систему. Требования заказчика определяют состав и качество указанных элементов. Объектами стандартизации любого стандарта в программной инженерии являются аспекты указанных выше элементов или их соединений.
Больше всего стандартов существует для разных видов процессов. Так в стандарте ISO/SEC 12207 базовых процессов – 42, а всего процессов в нем более 200. Надо сказать при этом, что усовершенствование процессов, как правило, ведет к усовершенствованию создаваемых продуктов и эффективному использованию ресурсов.
Определен детальный перечень процессов и действий, которые составляют процессы, для всех этапов жизненного цикла разработки и большинства аспектов рассмотрения указанных этапов. Наибольшего успеха и широкого использования приобрел стандарт [2] для процессов жизненного цикла программного обеспечения. Этот стандарт стал определенным каркасом для рассмотрения всех проблем программной инженерии.
Первым измерением классификации является отношение стандарта к продукту, процессу, ресурсу или взаимодействию с заказчиком. В [3] предложено второе измерение классификации стандартов по уровням обобщения регламентаций, которые подаются в стандарте.
Отдельные группы разработчиков стандарта в программной инженерии создают:
– терминологию,
– общие рекомендации,
– принципы действий,
– стандартизированные элементы,
– рекомендации для прикладных применений,
– рекомендации относительно инструментов и методов разработки (например, классификация аномалий выполнения),
– планы управления качеством,
– планы валидации и верификации.
В соответствии с предложенной классификацией ниже приведены наиболее значимые и существующие стандарты программной инженерии.
ISO/IEC 12207:1996 Information Technology – Software life–cycle processes;
12207/FPDAM 1.2 – Software Engineering – Life Cycle Processes // ISO/IEC JTC1/SC7 N2413, Software & System Engineering Secretariat, Canada. – 2001. – 62p.
DTR 15271 Information Technology – Guide for ISO/IEC 12207 (Software Life Cycle Processes);
IEEE/IEA Std. 12207.1:1997 Software Life Cycle processes – Life Cycle data;
ISO/IEC JTC1/SC7 N2172a (Draft ISO/IEC TR 16326:1999). Software Engineering – Guide for the Application of ISO/IEC 12207 to Project Management;
ISO/IEC TR 15504 Information Technology – Software Process Assessment Part 1 – Part 9;
IEEE Std. 1058:1998 IEEE Standard for Software Project Management Plans
IEEE Std. 1044:1993 IEEE Standard Classification for Software Anomalies
IEEE Std. 1044–1:1995 IEEE Guide to Classification for Software Anomalies
ISO/IEC 15026:1998 Information Technology – System and Software Integrity Levels;
ISO/IEC JTC1/SC7 N2207:1999 IEC 60300: Dependability management – Part 3–13: Application Guide – Project risk management;
ISO/IEC JTC1/SC7 N2198:1999 2nd Working Draft On Risk Management Terminology и др.
Статические методы тестирования
Cтатические методы используются при проведении инспекций и рассмотрении спецификаций компонентов без их выполнения.
Техника статического анализа заключается в методическом просмотре (или обзоре) и анализе структуры программ, а также в доказательстве правильности. Статический анализ направлен на анализ документов, разрабатываемых на всех этапах ЖЦ и заключается в инспекции исходного кода и сквозного контроля программы.
Инспектирование ПО – это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программ) на процессах ЖЦ. Просмотры и инспекции результатов проектирования и соответствия их требованиям заказчика обеспечивают более высокое качество создаваемых ПС.
При инспекция программ рассматриваются документы рабочего проектирования на этапах ЖЦ совместно независимыми экспертами и участниками разработки ПС.. На начальном этапе проектирования инспектирование предполагает проверку полноты, целостности, однозначности, непротиворечивости и совместимости документов с исходными требованиями к программной системе. На этапе реализации системы под инспекцией понимается анализ текстов программ на соблюдение требований стандартов и принятых руководящих документов технологии программирования.
Эффективность такой проверки заключается в том, что привлекаемые эксперты пытаются взглянуть на проблему "со стороны" и подвергают ее всестороннему критическому анализу.
Эти приемы позволяют на более ранних этапах проектирования обнаружить ошибки или дефекты путем многократного просмотра исходных кодов. Символьное тестирование применяться для проверки отдельных участков программы на входных значения – символах.
Кроме того, разрабатывается множество новых способов автоматизации символьного выполнения программ. Например, автоматизированное средство статического контроля для языково–ориентированной разработки, ряд инструментов автоматизации доказательства корректности. С целью проверки спецификаций параллельных вычислений систем используется автоматизированный аппарат сетей Петри.
Структурный подход
Сущность структурного подхода разработки ПС заключается в декомпозиции (разбиении) системы на автоматизируемые функции, которые в свою очередь делятся на подфункции, на задачи и так далее. Процесс декомпозиции продолжается вплоть до определения конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны.
В основу структурного подхода положены такие общие принципы:
– разбивка системы на множество независимых задач, легких для понимания и решения;
– иерархическое упорядочивание, т.е. организация составных частей проблемы в древовидные структуры с добавлением новых деталей на каждом уровне.
В основе этих принципов лежат операции:
– абстрагирования, т.е. выделения существенных аспектов системы и отвлечения от несущественных;
– формализации, т.е строгое методологическое решение проблемы;
– непротиворечивости, состоящей в обосновании и согласовании элементов системы;
– структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).
При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПС:
SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы [1];
SSADM (Structured Systems Analysis and Design Method) – метод структурного анализа и проектирования [2];
IDEF0 (Integrated Definition Functions) метод создания функциональной модели, IDEF1 – информационной модели, IDEF2 – динамической модели и др. [3].
На стадии проектирования эти модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Суть этого учета
Суть этого учета состоит в регистрации и предоставлении информации для эффективного КУ. Предметом учета является информация о текущем статусе идентифицированных объектов конфигурационного управления, предложенных изменениях, а также о выявленных дефектах и отклонениях от утвержденного конфигурационного базиса.
Отчетность по статусу конфигурации является ключевым фактором принятия управленческих решений по проекту информационной системы или ПО. Более того, оперативно регистрируемые и регулярно обновляемые данные учета статуса конфигурации являются исходным материалом для формирования количественных оценок или метрик производительности и качества работ на проекте. Применение этих метрик позволяет принимать не только правильные, но и эффективные управленческие решения по созданию программного проекта.
В системе учета статуса конфигурации накапливаются сводные отчеты о количестве обнаруженных и исправленных дефектов, поступивших и реализованных запросов на изменения, динамике внесения изменений в конфигурацию продукта во времени и др. Данной отчетностью практически пользуются все участники проекта: заказчики, аналитики, разработчики, тестировщики, внедренцы, служба качества и руководство проекта. На их основе проводится количественная оценка производительности и качества работ по проекту.
Техническое проектирование
Техническое проектирование состоит в отображении архитектуры системы в среду функционирования и определении всех конструкций композиций компонентов архитектуры.
На этом этапе происходит привязка проекта к техническим особенностям платформы реализации: СУБД, ОС, коммуникации, скорость реагирования системы на внешние условия т.п.
Объекты модели анализа требований согласовываются с учетом перечисленных выше особенностей, формализуются все стимулы, которые посылают или получают объект, и все операции, которые являются ответом на указанные стимулы.
Любой аспект привязки может потребовать построения вспомогательных интерфейсных или управляющих объектов и корректировки существующих. Более того, может оказаться возможность использования готовых подсистем, устройство которых отличается от подсистем, которые были до сих пор определены на основании анализа требований. В этом случае вносятся соответствующие корректировки в модель анализа требований и в архитектуру системы.
Следующим шагом проектирования может быть учет определенных свойств, которые определяют возможность системы функционировать в другой среде, и обладать качеством, сформулированным заказчиком.
Переносимость системы. Под этим термином понимают возможность изменять определенные используемые сервисные системы (ОС, системы коммуникаций в сетях, СУБД, и т.п.) путем локальной настройки соответствующих модулей. Обычно речь идет о переносимости относительно конкретного типа сервисных систем, например, переносимость относительно СУБД, переносимость относительно системы файлов и т.п.
Для реализации таких свойств определяются объекты, которые взаимодействуют с сервисными системами, относительно которых декларируется переносимость. Любой определенный таким образом объект заменяется на объект, который взаимодействует не непосредственно с сервисной системой, а с некоторым абстрактным объектом-посредником, который осуществляет трансформацию абстрактного интерфейса в интерфейс конкретной сервисной системы. Объект-посредник при этом имеет свойство настраиваться на конкретную сервисную систему.
Техника символьного выполнения
Техника логического доказательства игнорирует структуру и синтаксис ЯП, в которых тестовые программы выполняются. В случае, когда техника доказывает, что спроектированные компоненты являются правильными, они необязательно выполняются. Одна из таких техник – символьное выполнение – включает моделирование выполнения кода, используя символы вместо переменных данных. Тестовая программа рассматривается как имеющая детерминированное входное состояние при вводе данных и условий. Благодаря этому каждая строка кода выполняется, а данная техника проверяет, изменилось ли состояние. Каждое измененное состояние сохраняется, и выполняемая программа рассматривается как серия изменений состояний. Последнее состояние каждой части будет выходным состоянием и программа будет правильной.
Символьная проверка приводится на примере нескольких строк фрагмента программы:
а = b + с ;
if (a > d) task x ( ) ; // выполнить задание х
else task y ( ); // выполнить задание у
В нем проверяется условие a>d на истинность или нет. Поскольку выполнение условного кода включает значения переменных а и d, то рассматривается два случая, определенные на двух отдельных эквивалентных классах, когда условие верно и получен соответствующий результат. И второй случай, когда условие не выполняется.
Описание доказательства может оказаться длиннее написанного фрагмента программы и нет уверенности, что это описание не содержит ошибок. Данная стратегия имеет преимущество перед логическим доказательством теорем, поскольку полагается на трассирование изменяющихся условий операторов программв. Главными элементами доказательства корректности программы являются фрагмент программы, входные и выходные значения переменных, а также процесс слежение за тем, как этот фрагмент программа будет выполняться.
Тестирование ПО (Software Testing)
Тестирование ПО – это процесс проверки работы программы в динамике, основанный на выполнении конечного набора тестовых данных и сравнения полученных результатов с запланированными вначале.
Область знаний «Тестирование ПО (Software Testing)» включает следующие разделы:
– основные концепции и определение тестирования (Testing Basic Concepts and definitions),
– уровни тестирования (Test Levels),
– техники тестирования (Test Techniques),
– метрики тестирования (Test Related Measures),
– управление процессом тестирования (Managing the Test Process).
Основная концепция тестирования базируется на терминологии, теории и инструментах подготовки и проведения процесса тестирования ПО, а также оценке данных статистического анализа процесса тестирования. При тестировании выявляются недостатки: отказы (faults) и дефекты (defects), как причины нарушения работы системы, сбои (failures), как нежелательные ситуации, ошибки (errors), как последствия сбоев и др. Базовым понятием тестирования является тест, который выполняется в заданных условиях и на наборах данных. Тестирование считается успешным, если найден дефект или ошибка, и они устраняются. Степень тестируемости зависит от задания критериев покрытия системы тестами и вероятности появления сбоев. Данные базовые понятия зависят от уровня, видов и техник тестирования ПО.
Уровни тестирования это:
– тестирование отдельных элементов, которое заключается в проверке отдельных, изолированных и независимых частей ПО;
– интеграционное тестирование, которое ориентировано на проверку связей и способов взаимодействия (интерфейсов) компонентов друг с другом, включая компоненты, расположенные на разных архитектурных платформах распределенной среды;
– тестирование системы предназначено для проверки правильности функционирования системы в целом, с обнаружением отказов и дефектов в системе и их устранение. При этом контролируется выполнение сформулированных нефункциональных требований (безопасность, надежность и др.) в системе, правильность задания и выполнения внешних интерфейсов системы со средой окружения и др.
К видам тестирования относятся:
– функциональное тестирование, которое заключается в проверке соответствия выполнения специфицированных функций;
– регрессионное тестирование – тестирование системы или ее компонентов после внесения в них изменений;
– тестирование эффективности – проверка производительности, пропускной способности, максимального объема данных и системных ограничений в соответствии со спецификациями требований;
– нагрузочное (стресс) тестирование – проверка поведения системы при максимально допустимой нагрузке или при превышении;
– альфа и бета-тестирование – внутреннее и внешнее тестирование системы. Альфа – без плана, бета с планом тестирования;
– тестирование конфигурации – проверка структуры и идентификации системы на различных наборах, а также проверку работы системы в различных конфигурациях.
К видам тестирования относятся также подходы и методы проверки поведения системы на этапе испытания ПО и приемки в соответствии с требованиями и заданными параметрами относительно состава ПО, количества и типа компьютеров, среды и ОС.
Техники тестирования бывают таких видов:
– «белый (стеклянный) ящик», основанный на задании информации о структуре ПО или системе;
– «черный ящик», основанный на задании тестовых наборов данных для проверки правильности работы компонентов и системы в целом без знания их структуры;
– основанные на спецификациях, анализе граничных значений, таблицах принятия решений, критериев потоков данных, статистики отказов и др.;
– основанные на использовании блок–схем, по которым строятся программы и наборы тестов для покрытия всех условий выполнения частей системы и системы в целом;
– на основе обнаруженных дефектов, условий использования, природы и особенностей приложения и др.
Управление тестированием это:
– планирование процесса тестирования (составление планов, тестов, наборов данных) и измерение показателей качества ПО;
– проведение тестирования reuse-компонентов и паттернов, как основных объектов сборки ПО;
– генерация необходимых тестовых сценариев, соответствующих среде выполнения ПО;
– верификация правильности реализации системы и валидация реализованных требований к ПО;
– сбор данных об отказах, ошибках и др. непредвиденных ситуациях при выполнении программного продукта;
– подготовка отчетов по результатам тестирования и оценка характеристик системы.
Стандарт ISO/IEC, ГОСТ 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, а рассматривает тестирование, как необъемлемую часть ЖЦ.
Измерение результатов тестирования. Измерение, как часть планирования и разработки тестов, базируется на размере программ, их структуре и количестве обнаруженных дефектов. Метрики тестирования обеспечивают измерение процесса планирования, проектирования и тестирования; а также результатов тестирования на основе таксономии отказов и дефектов, покрытия границ тестирования, проверки потоков данных и др. Документация на тестирование включает, согласно стандарту IEEE 829-98, описание тестовых документов, их связи между собой и с процессом тестирования. Без документации по процессу тестирования, невозможно провести сертификацию продукта и оценку модели СММ1 [22]. После завершения тестирования рассматриваются вопросы стоимости и рисков, связанных с появлением сбоев и недостаточно надежной работой системы. Стоимость тестирования является одним из ограничений, на основе которого принимается решение о прекращении или продолжении тестирования.
Таким образом, данная область знаний SWEBOK представляет разработчику методы проверки правильности ПО: верификация, валидация, тестирование. Определяются типы, уровни и техники тестирования ПО, методы планирования процесса и тестовых наборов данных для прогонки ПО в режиме испытания конкретного модуля или системы в целом, а также методы измерения результатов тестирования.
Типы компонентных структур
Компонентная модель –
отражает многочисленные проектные решения по композиции компонентов, определяет типы паттернов компонентов и допустимые между ними взаимодействия, а также снижает время развертывания программной системы в среде функционирования.
Каркас – представляет собой высокоуровневую абстракцию проекта программной системы, в которой отделены функции компонентов от задач управления ими. То есть, бизнес–логика – это функции компонентов, а каркас задает правильное и надежное управление ими. Каркас объединяет множество взаимодействующих между собою объектов в некоторую интегрированную среду для решения заданной конечной цели. В зависимости от специализации каркас называют “белым или черным ящиком”.
Каркас типа “белый ящик” включает абстрактные классы для представления цели объекта и его интерфейс. При реализации эти классы наследуются в конкретные классы с указанием соответствующих методов реализации. Использование такого типа каркаса более характерно для OOП.
Для каркаса типа «черный ящик» в его видимую часть выносятся точки, разрешающие изменять входы и выходы.
Композиция компонентов включает четыре возможных класса:
– композиция компонент–компонент обеспечивает непосредственное взаимодействие компонентов через интерфейс на уровне приложения;
– композиция каркас–компонент обеспечивает взаимодействие каркаса с компонентами, при котором каркас управляет ресурсами компонентов и их интерфейсами на системном уровне;
– композиция компонент–каркас обеспечивает взаимодействие компонента с каркасом по типу «черного ящика», в видимой части которого находится спецификация для развертывания и выполнения определенной сервисной функции на сервисном уровне;
– омпозиция каркас–каркас обеспечивает взаимодействие каркасов, каждый из которых может разворачиваться в гетерогенной среде и разрешать компонентам, входящим в каркас, взаимодействовать через их интерфейс на сетевом уровне.
Компоненты и их композиции, как правило, запоминаются в репозитарии компонентов, а их интерфейсы к репозитарии интерфейсов.
Повторное использование в компонентном программирование в общем случае представляет собой любые порции формализованных знаний, добытые во время реализации программных систем и используемых в новых разработках [13–15].
Повторно используемые компоненты (ПИК} – элементы знаний о минувшем опыте разработки систем, которые могут использовать не только их разработчиками, но и путём адаптации к новым условиям. ПИК упрощает и сокращает сроки разработки новых программных систем. Высокий уровень стандартизации и распространение электронных коммуникаций (сети Интернет) обеспечивает довольно простое получение и широкое использование готовых компонентов в разных проектах за счет:
– отражения фундаментальных понятий приложения;
– скрытия способа представления и предоставления операций обновления и получения доступа;
– обработки исключительных операций в приложении.
При создании компонентов, предназначенных для повторного использования, общий интерфейс должен содержать операции, которые обеспечивают разные способы использования компонентов. Возможность повторного использования приводит к усложнению компонента, а значит к уменьшению понятности. Поэтому требуется некоторый компромисс между ними.
Как и любые элементы промышленного производства, компоненты должны отвечать определенным требованиям, иметь характерные свойства, структуру, механизмы использования и др. В UML все компоненты делятся на три типа:
1) для развертывания в компьютерной среде;
2) как рабочие продукты (файлы текстов с программами и данными, элементы с описаниями архитектуры и правилами генерации конечного кода и др.);
3) для среды выполнения (временные программные объекты, файлы, таблицы базы данных и др.).
Главным преимуществом создания программных систем из компонентов является уменьшение затрат на разработку за счет:
– выбора готовых компонентов с подобными функциями, пригодными для практического применения;
– настраивания готовых компонентов на новые условия, которые связаны с меньшими усилиями, чем разработка новых компонентов.
Поиск готовых компонентов основывается на их классификации и каталогизации. Метод классификации предназначен для представления информации о компонентах с целью быстрого поиска и отбора. Метод каталогизации обеспечивает физическое размещение компонентов в репозитариях для непосредственного доступа к ним в процессе интеграции.
Интероперабельность компонентов. Сложились ряд подходов для решения этой проблемы, наиболее часто они связаны с анализом кода для внесения изменений при переносе его в другую среду. Механизмы обеспечения интероперабельности имеют разные концепции и реализации, т.е. приведение представления одного компонента к форме, понятной второму либо к некоторому промежуточному состоянию.
Стандартный механизм интероперабельности для связи между Java и C/C++ компонентами использует Java Native Interface (JNI) при реализации обращения из Java–классов к функциям и библиотекам на других ЯП. Механизм реализации включает: анализ Java–классов для поиска прототипов обращений к функциям на C/C++; генерацию заглавных файлов для использования их при компиляции C/C++ программ. Java–класс “знает”, что в нем помещается обращение не к Java–методу. Схема связи Java ® C/C++ [16].
Другой вариант реализации этой задачи предлагает технология Bridge2Java фирмы IBM alpha Works. В ней обеспечивается обращение из Java–классов к COM–компонентам [5]. Для COM–компонента генерируется оболочка, которая включает прокси–класс для преобразования данных с помощью стандартной библиотеки типов и вызов COM–функций. Данная схема не требует изменений в исходном Java–классе, а COM–компоненты могут быть написаны на разных ЯП.
Механизм интероперабельности предлагает и платформа .Net [17] с помощью промежуточного языка Common Language Runtime (CLR), в который транслируются коды, написанные в ЯП (C#, Visual Basic, C++, Jscript) и интегрируются эти компоненты.При этом используется библиотека стандартных классов независимо от языка реализации и доступа к готовым компонентам без ориентации на эту платформу (например, к COM–компонентам). С этой целью используются стандартные средства генерации оболочки для COM–компонента в представление .Net–компонента, а также для приведенных выше ЯП.
Особенности ОС и архитектур компьютеров учитывает среда CORBA, в которой реализована иерархия механизмов интероперабельности – от самого верхнего уровня (поддержка разных ЯП) к самому нижнему (с учетом архитектуры).
Типы компонентов и средства их интеграции в JAVA
Интерфейс является видимой частью спецификации компонента, предназначенной для интеграции компонента в среду для повторного использования. Для описания интерфейса компонента применяется Inspector Components, позволяющий изменять необходимые параметры интерфейса компонента с помощью визуальной таблицы, отображающей все параметры. Интерфейс в Inspector Components задается в виде пары – имя параметра и значение параметра, которые могут изменяться автоматически без вмешательства в код компонента.
Для разных типов компонентов Inspector Components содержит неизменную часть представленных параметров, которая может быть включена в инвариант спецификации, к которому относятся параметры: тип компонента, имя компонента, входные, выходные данные, типы атрибутов и параметров методов компонента.
Для описания и инициализации разных типов компонентов и интеграции их в новый проект используются специализированные шаблоны. Тип компонента имеет функциональность и поддерживается стандартным набором методов JAVA, которые обеспечивают инициализацию, запуск, функционирование и уничтожение компонента.
Инструментарий NFTW (New From Teplate Wizard) обеспечивает поиск, селекцию и подключение компонентов к выбранному пакету или проекту. Верхний уровень иерархии задает основные шаблоны для построения новых компонентов и интеграции их в проекты. Этот уровень определяется с помощью основных типов компонентов в языке программирования JAVA, к которым относятся: проекты, формы (AWT компоненты), beans компоненты, COBRA компоненты, RMI компоненты, стандартные классы–оболочки, базы данных, JSP компоненты, сервлети, XML документы, DTD документы, файлы разных типов и их групп [3-5]. Рассмотрим основные типы компонентов
Трассирование требований
Одной из главных проблем сбора требований является проблема изменения требований. Требования появляются в процессе общения между группой заказчиков и аналитиками системы в виде интервью, обсуждений, которые не приносят желаемого результата. Это объясняется тем, что составляющих элементов требований последовательно изменяются, благодаря чему их содержание и форма постепенно становятся более точными и полными, т.е. соответствуют действительности [6].
Инструменты трассировки поддерживают развитие и обработку требований с сохранением их описания и внутренних связей между ними. Трассировка помогает проверять особенности системы на спецификациях требований, выявлять источники разнообразных ошибок и управлять изменениями требований. Если требования разрабатывались в объектной ориентации, то объектами трассировки являются классы и суперклассы и поддерживаемые отношения между ними.
Некоторые методы трассировки базируются на формальных спецификациях отношений (фреймы, соглашения сотрудничества и др.), другие ограничиваются описаниями действий, ситуаций, контекста и возможных решений.
Трассировку можно описать исходя из следующего:
1) требования изменяются во время функционирования системы;
2) возникновение требований и их расположение зависит от деталей практической ситуации и контекста их возникновения (требования можно изменить, изменяя эти детали);
3) трассировка требований должна поддерживаться и изменятся на протяжении всего ЖЦ программного продукта (т.к. изменяются сами требования, необходимо проводить изменение и промежуточных результатов, полученных при анализе, спецификации, кодировке и т.д.);
4) для удобства трассировки использовать иерархическую структуру связей между требованиями, основу которой составляет информация об атрибутах требований.
Чтобы принять решение о возможных модификациях, необходимо иметь достаточно информации о частях и связях между ними. Более того, различные аспекты требований могут быть по-разному представлены и изменены их контексты путем персонального вмешательства аналитиков или заказчика.
Механизмы трассировки должны учитывать следующее:
1) вместо простых связей вводить более сложные отношения (например, транзитивное отношение для выделения цепочек связей) или вводить специфические отношения;
2) использовать сложные и гибкие пути трассировки;
3) поддержать базы данных объектов трассировки и отношений между ними.
Желательно наличие механизмов поддержки возможностей объектно-ориентированного программирования, операций над классами, а также механизмов унификации функций и отношений (1:1, 1:N, N:M), уничтожение и изменение связей, установка стандартных связей.
Трассировка может быть выборочной для определенных объектов, беспорядочной проверкой объектов, связанных с другими объектами, а также с возможными переходами от одного объекта к другим. Она проводится с использованием механизмов поддержания контекста и отношений, соответствующих данной ситуации (например, трассировка с регулярными выражениями, когда контекст может быть изменен только при модификации соответствующего регулярного выражения).
Человеческий фактор. Любой процесс постановки требований напрямую связан с умением людей контактировать друг с другом, кооперироваться или эффективно распределять разноплановые производственные функции между собой. Необходимо уметь достигнуть соглашения в спорных вопросах, касающихся дизайна или технических решений. Организационные функции не должны выходить за рамки понимания проблемы. Важно чтобы лица, работающие над проектом на разных уровнях, имели возможность эффективно общаться друг с другом.
Технологии проекта должны обращать внимание на динамику людских отношений в коллективе. Они должны способствовать эффективному достижению согласия и управления разногласиями, давать возможность снижать сложность отношений в группе сотрудников, работающих над проектом, особенно в повседневной работе при создании высококачественного продукта.
Наиболее привычной и результативной моделью отношений между заказчиком и проектировщиком является модель типа «учитель – ученик».На практике заказчик наблюдает за работой проектировщика системы. Когда заказчик его не беспокоит, проектировщик обращает внимание на примеры и сам отвечает себе на возникающие вопросы. В порядке исключения, заказчик может остановить свою работу, обдумать поставленный вопрос для пояснения и удовлетворения проектировщика.
Это даже помогает разработчику разобраться в деталях своей работы и избавляет его от описания излишних абстракций. Проектировщик должен сформировать свои независимые идеи относительно проектировки будущей системы и постоянно консультироваться с заказчиком, что избежать ошибок на самых ранних этапах проектирования системы Использование данной модели на практике возможно только при хороших взаимоотношениях между заказчиком и исполнителем проекта.
Унифицированные файлы для передачи данных между разными БД
Проблема преобразования и переноса данных между различными СУБД решается в основном двумя методами, основанными соответственно на использовании:
1) специального драйвера (две СУБД соединяются друг с другом и напрямую передают данные, используя интерфейс);
2) транзитных файлов, в которые копируются данные из старой БД и переносятся в новую БД.
Процесс преобразования и переноса данных из разных БД в новую БД приведен на рис.8.3.
При первом методе две СУБД соединены напрямую и передают данные, используя определенный интерфейс или драйвер. Иными словами,. они используют специальные программы взаимодействия двух СУБД, при которых вторая СУБД понимает результаты выполнения запросов на языке манипулирования данными первой СУБД, и наоборот. Данные на выходе первой СУБД являются данными на входе второй СУБД в языке манипулирования данными второй СУБД, такие данные могут быть внесены в транзитную БД.
Метод сложный в реализации и требует поставки с СУБД программ переноса данных из других СУБД, которые привязаны к старой и новой СУБД. Поэтому второй метод переноса данных между различными СУБД является более предпочтительным..
Второй метод заключается в том, что из старой БД данные переносятся в транзитные файлы, SGL–скрипты, DBF–файлы с заранее заданными форматами данных, которые пересылаются через сеть в новую транзитную БД.
Данные из транзитных файлов с помощью специальных утилит или средств новой СУБД затем переносятся в транзитную БД для дальнейшей обработки. Если вторая СУБД реляционного типа, то данные в транзитных файлах должны быть представлены к табличному виду. Если первая СУБД не реляционна, то данные должны быть приведены к табличному виду и первой нормальной форме.
Дальнейшая нормализация данных и приведение их к структуре новой БД осуществляется в транзитной БД. Существуют пять нормальных форм задания структур данных, чаще всего используется 3–я или 4–я нормальная форма.
Каждая высокая форма нормализации содержит в качестве подмножества более низкую форму первой нормальной формы, содержащей скалярные значения.
Рис. 8.3. Процесс преобразования и формирования новой БД из старых БД
Иными словами, отношение находятся в первой нормальной форме, если они хранятся в табличном виде (все ячейки в строке таблицы расположены в строго определенной последовательности) и каждая ячейка таблицы содержит только атомарные значения (каждый элемент не является множеством).
Отношение находится в третьей нормальной форме тогда и только тогда, когда каждый кортеж состоит из значения первичного ключа, которое идентифицирует некоторую сущность, и набора пустых значений или значений независимых атрибутов, описывающих эту сущность. Т.е. отношение находится в третьей нормальной форме, когда неключевые атрибуты являются взаимно независимыми и зависят от первичного ключа. Неключевой атрибут – это атрибут, который не задействован первичным ключом рассматриваемого отношения.
Два или несколько атрибутов являются взаимно независимыми, если ни один из них не зависит функционально от какой–либо комбинации остальных атрибутов. Подобная независимость подразумевает, что каждый атрибут может быть обновлен независимо от остальных.
Процесс нормализации отношений позволяет избавиться от проблем, которые могут возникнуть при обновлении, внесении или удалении данных, а также при обеспечении целостности данных.
Структуры старых баз данных, не всегда приводятся к третьей нормальной форме, поэтому требуется, чтобы данные, находящиеся в транзитных файлах, существовали хотя бы в первой нормальной форме и относились к реляционной модели.
В качестве унифицированного формата транзитных файлов используется формат DBF–файлов, поскольку многие СУБД, такие как DB2, FохРго и некоторые другие хранят данные в таких файлах, тем самым не требуется начальный перенос данных из старой СУБД в транзитные файлы.Большинство СУБД, формат хранения данных которых отличается от формата DBF–файлов, снабжены утилитами или драйверами, которые позволяют перенести данные в такой формат.
Управление инженерией ПО (Software Engineering Management)
Управление инженерией ПО (менеджмент) – руководство работами команды разработчиков ПО в процессе выполнения плана проекта, определение критериев и оценка процессов и продуктов проекта с использованием общих методов управления, планирования и контроля работ.
Как любое управление, менеджмент ПО предполагает планирование, координацию, измерение, контроль и отчет по процессу управления проектом; представляет собой системную, дисциплинированную и измеряемую разработку ПО. Координацию людских, финансовых и технических ресурсов при реализации задач проекта выполняет менеджер проекта, аналогично тому, как это делается в технических проектах. В его обязанности входит соблюдение запланированных бюджетных и временных характеристик и ограничений, стандартов и сформулированных требований. Общие вопросы управления проектом содержится в ядре знаний РMBOK [19] в разделе Management Process Activities, а также в стандарте ISO/IEC 12207 – Software life cycle processes [14], где управление проектом рассматривается как дополнительный и организайионный процесс ЖЦ,
Область знаний «Управление инженерией ПО (Software Engineering Management)» состоит из следующих разделов:
– организационное управление (Organizational Management),
– управление процессом и проектом (Process/Project Management),
– измерение инженерии ПО (Software Engineering Measurement).
Организационное управление – это планирование и составление графика работ, оценка стоимости работ, подбор и управление персоналом, контроль за выполнением работ согласно принятых стандартов и планов. Главными проблемами организационного управления проектом являются: управление персоналом (обучение, мотивация и др.), коммуникации между сотрудниками и средой (сценарии, встречи, презентации и др.), а также риски (минимизация риска, техники определения риска, выбор решений по их предотвращению и др.). Для управления проектом создается такая структура коллектива, специалисты которой могут выполнить проект, они распределяются по работам и все вместе реализуют задачи проекта под руководством менеджеру проекта.
Задачам проекта сопоставляется оборудование, средства и исполнители. Проводится распределение обязанностей специалистов и их выполнение с учетом заданной стоимости и срока разработки проекта.
Процесс управления проектом включает: составление плана проекта, построение графиков работ (сетевых или временных диаграмм) исходя из имеющихся ресурсов, а также распределение персонала по работам с учетом сроков и стоимости их выполнения и др.; анализ финансовой, технической, операционной и социальной политики организации для выбора правильной стратегии выполнения плана; контроль процесса управления планами и продуктами на процессах.
Управление продуктом заключается в уточнении требований и проверки (валидацию) их на соответствие, в просмотре и ревизии требований на соответствие заданным спецификациям качества, а также в проверке (верификации) правильности реализованных функций в отдельных продуктах проекта. Процесс управления проектом базируется на заданных сроках выполнения работ, их начала и окончания. Результаты планирования отображаются в сетевых диаграммах (PERT – Program Evaluation and Review Technique, CРM – Сritical Path Method и др.), предназначенных для отображения полного комплекса работ, времени их выполнения и зависимостей между разными работами.
Сетевая диаграмма PERT является графом, в вершинах которого располагаются работы, а дуги задают взаимные связи между этими работами. Такой граф является наиболее распространенным представлением сети для управления разными видами работ на сегодняшний день. Другой тип сетевой диаграммы является событийным, когда в ее вершинах указываются события, а работы задаются линиями между двумя узлами–событиями. Ожидаемое время выполнения работы для сетевых диаграмм оценивается с помощью среднего весового значения трех оценок: оптимистической, пессимистической и ожидаемой – вероятностной. Эти оценки берутся из заданного времени на разработку и заключений экспертов, оценивающих отдельные работы и в комплексе.
Есть и другие методы оценок.
После составления плана решается вопрос управления и контроля проекта согласно плану, выбранного процесса и сущности проекта. Корректно составленный план обеспечивает выполнение требований и целей проекта. Процесс контроля более всего направлен на внесение изменений в проект, оценку риска и оценка принимающих решений.
Управление рисками является важной проблемой выполнения проекта и представляет собой процесс определения рисков и разработки мероприятий по уменьшению их влияния на ход выполнения проекта.
Риск – вероятность проявления неблагоприятных обстоятельств, которые могут повлиять негативно на реализацию качества проекта и на управление разработкой (например, увольнение сотрудника и отсутствие замены для продолжения работ и др.). Для управления риском проводится идентификация и анализ риска, оценка критических рисков и планирование непредвиденных ситуаций, касающихся рисков. Предотвращение риска заключается в выполнении действий, которые снимают риск (например, увеличение времени разработки и др.), уменьшают вероятность появления нового риска при реорганизации проекта, БД или транзакций, а также при выполнении ПО.
Измерение в инженерии ПО проводится для определения отдельных характеристик объектов инженерии (продуктов, процессов и т.п.) и их измерение. Проводится комплекс работ, связанных с выбором метрик для оценки качества процессов и продуктов, а также обстоятельств и зависимостей, влияющих на их измерение. К ним относятся: совершенствование процессов управления проектом; оценки временных затрат и стоимости ПО, их регулирование; определение категорий рисков и отслеживание факторов для регулярного расчета вероятностей их возникновения; проверка заданных в требованиях показателей качества отдельных продуктов проекта и проекта в целом [15].
Проведение разного рода измерений является важным принципом любой инженерной деятельности, а в программном проекте оно положительно влияет на результат выполнения и создания ПО, необходимого заказчику и потребителям.Без измерений в инженерии ПО процесс управления становится неэффективным и превращается в самоцель.
Таким образом, рассмотрение основных принципов формирования команды разработчиков, методов планирования работ и оценки процессов создания ПО и самого продукта позволяет менеджеру коллектива разработчиков проекта сосредоточится на планировании работ, оценках трудозатрат, распределения ресурсов и управления изменениями и рисками.
Управление качеством ПС
Под управлением качества понимается совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС. Управление качеством – SQM (Software Quality Management) базируется на применении стандартных положений по гарантии качества – SQA (Software Quality Assurance) [4, 15].
Цель процесса SQA состоит в гарантировании того, что продукты и процессы согласуются с требованиями, соответствуют планам и включает следующие виды деятельности:
– внедрение стандартов и соответствующих процедур разработки ПС на этапах ЖЦ;
– оценка соблюдения положений этих стандартов и процедур.
Гарантия качества состоит в следующем:
– проверка непротиворечивости и выполнимости планов;
– согласование промежуточных рабочих продуктов с плановыми показателями;
– проверка изготовленных продуктов заданным требованиям;
– анализ применяемых процессов на соответствие договору и планам;
– среда и методы разработки согласуются с заказом на разработку;
– проверка принятых метрик продуктов, процессов и приемов их измерения в соответствии с утвержденным стандартом и процедурами измерения.
Цель процесса управления SQM состоит в том, чтобы провести мониторинг (систематический контроль) качества для гарантии, что продукт будет удовлетворять потребителю и предполагает выполнение следующих видов деятельности:
– определение количественных свойств качества, основанных на выявленных и предусмотренных потребностях пользователей;
– управление реализацией поставленных целей для достижения качества.
SQM основывается на гарантии того, что:
– цели достижения требуемого качества установлены для всех рабочих продуктов в контрольных точках продукта;
– определена стратегия достижения качества, метрики, критерии, приемы, требования к процессу измерения и др.;
– определены и выполняются действия, связанные с предоставлением продуктам свойств качества;
– проводится контроль качества (SQA, верификация и валидация) и целей, если они не достигнуты, то проводится регулирование процессов;
– выполняются процессы измерения и оценивании конечного продукта на достижение требуемого качества.
Основные стандартные положения [1–4, 15] по созданию качественного продукта и оценки уровня достигнутого выделяют два процесса обеспечения качества на этапах ЖЦ ПС:
– гарантия (подтверждение) качества ПС, как результат определенной деятельности на каждом этапе ЖЦ с проверкой соответствия системы стандартам и процедурам, ориентированным на достижении качества;
– инженерия качества, как процесс предоставления продуктам ПО свойств функциональности, надежности, сопровождения и других характеристик качества.
Процессы достижения качества предназначены для:
а) управления, разработки и обеспечения гарантий в соответствии с указанными стандартами и процедурами;
б) управления конфигурацией (идентификация, учет состояния и действий по аутентификации), риском и проектом в соответствии со стандартами и процедурами;
в) контроль базовой версии ПС и реализованных в ней характеристик качества.
Выполнение указанных процессов включает такие действия:
– оценка стандартов и процедур, которые выполняются при разработке программ;
– ревизия управления, разработки и обеспечение гарантии качества ПО, а также проектной документации (отчеты, графики разработки, сообщения и др.);
– контроль проведения формальных инспекций и просмотров;
– анализ и контроль проведения приемочного тестирования (испытания) ПС.
Для организации, которая занимается разработкой ПС в том числе из компонентов, инженерия качества ПС должна поддерживаться системой качества, управлением качеством (планирование, учет и контроль).
Инженерия качества включает набор методов и мероприятий, с помощью которых программные продукты проверяются на выполнение требований к качеству и снабжаются характеристиками, предусмотренными в требованиях на ПО.
Система качества (Quality systems – QS) [15] - это набор организационных структур, методик, мероприятий, процессов и ресурсов для осуществления управления качеством. Для обеспечения требуемого уровня качества ПО применяются два подхода.
Один из них ориентирован на конечный программный продукт, а второй - на процесс создания продукта.
При подходе, ориентированном на продукт, оценка качества проводится после испытания ПС. Этот подход базируется на предположении, что чем больше обнаружено и устранено ошибок в продукте при испытаниях, тем выше его качество.
При втором подходе предусматриваются и принимаются меры по предотвращению, оперативному выявлению и устранению ошибок, начиная с начальных этапов ЖЦ в соответствии с планом и процедурами обеспечения качества разрабатываемой ПС. Этот подход представлен в серии стандартов ISO 9000 и 9000-1,2,3. Цель стандарта 9000–3 состоит в выдаче рекомендаций организациям-разработчикам создать систему качества по схеме, приведенной на рис.9.3.
Система контроль Руководитель работа Ответственный
Общая политика
Ответственность
и полномочия
Средства контроля
План достижения
качества ПС
Рис.9.3. Требования стандарта к организации системы качества
Важное место в инженерии качества отводится процессу измерения характеристик процессов ЖЦ, его ресурсов и создаваемых на них рабочих продуктов. Этот процесс реализуются группой качества, верификации и тестирования. В функции этой группы входит: планирование, оперативное управление и обеспечение качества.
Планирование качества представляет собою деятельность, направленную на определение целей и требований к качеству.
Оно охватывает идентификацию, установление целей, требований к качеству, классификацию и оценку качества. Составляется календарный план–график для проведения анализа состояния разработки и последовательного измерения спланированных показателей и критериев на этапах ЖЦ.
Оперативное управление включает методы и виды деятельности оперативного характера для текущего управления процессом проектирования, устранения причин неудовлетворительного функционирования ПС.
Обеспечение качества заключается в выполнении и проверки того, что объект разработки выполняет указанные требования к качеству. Цели обеспечения качества могут быть внутренние и внешние. Внутренние цели - создание уверенности у руководителя проекта, что качество обеспечивается. Внешние цели - это создание уверенности у пользователя, что требуемое качество достигнуто и результатом является качественное программное обеспечение.
Как показывает опыт, ряд фирм, выпускающие программную продукцию, имеют системы качества, что обеспечивает им производить конкурентоспособную продукцию. Система качества включает мониторинг спроса выпускаемого нового вида продукции, контроль всех звеньев производства ПС, включая подбор и поставку готовых компонентов системы.
При отсутствии соответствующих служб качества разработчики ПО должны применять собственные нормативные и методические документы, регламентирующим процесс управления качеством ПО для всех категорий разработчиков и пользователей программной продукции.
Управление конфигурацией
Управление конфигурацией (УК) – дисциплина, обеспечивающая идентификацию элементов конфигурации системы при ее создании для проведения систематического контроля, учета и аудита внесенных изменений, а также поддержки целостности и работоспособности системы.
Согласно действующего стандарта IEEE Std.610-90 УК включает следующие основные задачи:
1. Идентификация конфигурации (Configuration Identification).
2. Контроль конфигурации (Configuration Control).
3. Учет статуса конфигурации (Configuration Status Accounting).
4. Аудит конфигурации аудит (Configuration Audit).
УК для больших систем создается с помощью методов и средств, обеспечивающих идентификацию элементов этой системы, контроль вносимых изменений и возможность определения фактического состояния системы при разработке и эксплуатации в любой момент времени. УК базируется на точной и достоверной информации о состоянии системы и планах проведения изменений.
С формальной точки зрения УК состоит в дисциплинированном применении технического, административного управления и методов наблюдения за определенными и документированными функциональными и физическими характеристиками отдельных пунктов конфигурации и элементов системы, а также методов управления изменениями, подготовки отчетов по выполненным изменениям и процедурам их проверки на соответствие поставленным требованиям.
Работы по УК, как правило, выполняет специальная служба, которая определяет возможные ограничения на функционирование системы в заданных условиях операционной среды, планирование внесения изменений, проверку разных частей системы, сбор данных и учет внесенных изменений в систему и конфигурацию. К деятельности этой службы относится также управление проектом, контроль качества и целостности конфигурации системы и ее сопровождение.
Структура службы зависит от сложности системы, этапов развития проекта и от специалистов организации-разработчика системы и заказчика.
От хорошей организации работы службы зависит эффективность УК. Взаимосвязь видов деятельности по УК представлена рис.10.8.
и контроль проектом и системы функциональной
изменений качеством группой целостности
версии сопровождения системы
Управление
и
планирование
Контроль
процессом управления Статус Обработка Проверка
группой отчетности версий (аудит)
УК разработчиков
Идентификация конфигурации системы
Рис.10.8. Виды деятельности УК
Результатом УК является отчет о проведенных изменениях версии системы и документации, а также документ о передаче измененной версии пользователю.
Для достижения целей УК должно планироваться и выполняться с учетом возникающих ограничений ОС и оборудования у заказчика. Процессом планирования занимаются менеджеры службы управления проектом. Предложения на изменение компонентов системы подаются в эту службу, для проведения анализа и определения целесообразности внесения изменений в версию системы и ее конфигурацию, оценку стоимости этих работ, разработку предложений в виде утвержденного перечня изменений для их реализации.
Процесс изменений включает в себя определение типов изменений, организацию их проведения и формирование концепции допуска отклонений и отказов по отношению к требованиям проекта системы. Результатом внесения изменений является новая версия системы, документация по проведению на ней испытаний и пользовательская документация на систему.
Заказчик оценивает предложения на внесение изменений и дает разрешение на проведение наиболее важных изменений, влияющих на ее технические характеристики или стоимость. Анализ и контроль проведения изменений конфигурации системы проводит специальная группа службы управления. Она выполняет систематический учёт и контроль внесения изменений на всех этапах ЖЦ.
План изменений в конфигурацию системы утверждается формальными процедурами, расчетами оценок влияния изменений на стоимость, принятие решений об изменениях или отказ от них. Запросы на внесение изменений выполняются в соответствии с процедурами разработки системы на этапах ЖЦ или на этапе сопровождения системы. Поскольку требуемые изменения могут проводиться одновременно с разработкой, предусматривается трассирование изменений при построении новых версий. Каждое проведенное изменение подвергаются детальному аудиту.
За внесением изменений проводится контроль текущей версии системы с использованием выходных кодов в репозитории, проверки исходного кода и полученной версий. Инструменты контроля имеются в фирмах Rational’s ClearCase и SourceSafe of Microsoft системы Unix.
После завершения изменений и испытания системы проводится тиражирование системы и документации для передачи системы и ее конфигурации заказчику.
В конфигурацию системы входят сведения об аппаратных и программных элементах системы. При этом на систему могут задаваться ограничения с учетом контактов с заказчиком, аудиторами, информации из разных источников (спецификации требований, описаний, отчетов и др.), а также состава инструментальных средств и рекомендаций государственных или межведомственных стандартов.
Управление конфигурацией ПО (Software Configuration Management–SCM)
Управление конфигурацией – дисциплина идентификации компонентов системы, определения функциональных и физических характеристик аппаратного и программного обеспечения для проведения контроля внесения изменений и трассирования конфигурации на протяжении ЖЦ. Это управление соответствует одному из вспомогательных процессов ЖЦ (ISO/IEC 12207), выполняется техническим и административным руководством проекта и заключается в контроле указанных характеристик конфигурации системы и их изменении; составления отчета о внесенных изменениях в конфигурацию и статус их реализации; проверки соответствия внесенных изменений заданным требованиям.
Конфигурация системы – состав функций, программных и физических характеристик программ или их комбинаций, аппаратного обеспечения, обозначенные в технической документации системы и реализованные в продукте.
Конфигурация ПО включает набор функциональных и физических характеристик ПО, заданных в технической документации и достигнутых в готовом продукте. Т.е это сочетание разных элементов продукта вместе с заданными процедурами сборки и отвечающие определенному назначению. Элемент конфигурации – график разработки, проектная документация, исходный и исполняемый код, библиотека компонентов, инструкции по установке системы и др.
Область знаний «Управление конфигурацией ПО» состоит из следующих разделов:
– управление процессом конфигурацией (Management of SMC Process),
– идентификация конфигурации ПО (Software Configuration Identification),
– контроль конфигурации ПО (Software Configuration Control),
– учет статуса конфигурации ПО (Software Configuration Status Accounting),
– аудит конфигурации ПО (Software Configuration Auditing),
– управление релизами (версиями) ПО и доставкой (Software Release Management and Delivery).
Управление процессом конфигурации. Это деятельность по контролю эволюции и целостности продукта при идентификации, контроле изменений и обеспечении отчетности информации, касающейся конфигурации.
Включает:
– систематическое отслеживание вносимых изменений в отдельные составные части конфигурации и проведение аудита изменений и автоматизированного контроля за внесением изменений в конфигурацию системы или ПО;
– поддержка целостности конфигурации, ее аудит и обеспечение внесения изменений в один объект конфигурации, а также в связанный с ним другой объект;
– ревизия конфигурации на предмет проверки разработки необходимых программных или аппаратных элементов и согласованности версии конфигурации с требованиями;
– трассировка изменений в конфигурацию на этапах сопровождения и эксплуатации ПО.
Идентификация конфигурации ПО проводится путем выбора элемента конфигурации ПО и документирования его функциональных и физических характеристик, а также оформления технической документация на элементы конфигурации ПО.
Контроль конфигурации ПО состоит в проведении работ по координации, утверждению или отбрасыванию реализованных изменений в элементы конфигурации после формальной ее идентификации, а также оценке результатов.
Учет статуса конфигурации ПО проводится в виде комплекса мероприятий для определения уровня изменений в конфигурацию, аудита конфигурации в виде комплекса мероприятий по проверке правильности внесения изменений в конфигурацию ПО. Информация и количественные показатели накапливается в соответствующей БД и используются при управлении конфигурацией, составлении отчетности, оценке качества и выполнении других процессов ЖЦ.
Аудит конфигурации – это деятельность, которая выполняется для оценки продукта и процессов на соответствие стандартам, инструкциям, планам и процедурам. Аудит определяет степень удовлетворения элемента конфигурации заданным функциональным и физическим характеристикам системы. Различают функциональный и физический аудит конфигурации, который завершается фиксацией базовой линии продукта.
Управление релизами (версиями) ПО это: отслеживание имеющейся версии элемента конфигурации; сборка компонентов; создание новых версий системы на основе существующей путем внесения изменений в конфигурацию; согласование версии продукта с требованиями и проведенными изменениями на этапах ЖЦ; обеспечение оперативного доступа к информации относительно элементов конфигурации и системы, к которым они относятся.Управление выпуском охватывает идентификацию, упаковку и передачу элементов продукта и документации заказчику. При этом используются следующие основные понятия.
Базис (baseline) – формально обозначенный набор элементов ПО, зафиксированный на этапах ЖЦ ПО.
Библиотека ПО – контролируемая коллекция объектов ПО и документации, предназначенные для облегчения процесса разработки, использования и сопровождения ПО.
Сборка ПО – объединение корректных элементов ПО и конфигурационных данных в единую исполняемую программу.
Таким образом, описание данной области показывает, что процесс управления конфигурации является важным процессом идентификации элементов, формирования версии системы и их управления.
Управление конфигурацией программной системы
Под конфигурацией системы понимается конкретный состав (версия) системы, включающий технические, программные и программно-технические средства, объединенные между собой специальными процедурами сборки, для достижения конкретных целей обработки данных [9-12].
Элементами конфигурации являются:
– единица конфигурации – ЕК (Configuration Item ) – элемент, выделенный для целей управления и обработки на процессорах компьютера системы;
– базис конфигурации – БК (Configuration Baseline ) – набор формально рассмотренной и утвержденной основы системы из состава ЕК и документации, устанавливающей возможность дальнейшего развития системы;
– программные компоненты системы.
Конфигурация состоит из одной и более ЕК, базис конфигурации определяет входящие в конфигурацию ЕК, к которым относятся технические решения, перечень главных ЕК и специализированные процедуры их объединения в единое целое для функционирования и выполнения компонентов в заданной последовательности. Чем больше в системе компонентов, тем больше вероятность того, что отдельные из них могут изменяться в связи с обнаруженными ошибками, уточнениями или дополнениями, как новых функций, так и оборудования.
Идентификация конфигурации – это именование всех элементов системы с учетом , которое базируется структуризации и построение схемы классификации и кодирования этих элементов, а также на методах представления и ведения версий конфигурации с использованием входящих элементов.
К элементам управления конфигурацией также относятся физические и функциональные характеристики, схема и версия конфигурации. Целью УК является обеспечение целостности системы путем наблюдения за производимыми изменениями за структурой и элементами конфигурации.
Под целостностью конфигурации понимается способность системы воспроизводить и выполнять заданные функции после физических и функциональных изменений отдельных элементов и повторного их объединения в новую версию системы.
Управление версиями
Версия системы включает элементы конфигурации и версию системы для передачи получателю [6, 7]. Управление версиями состоит в выполнении действий:
– интеграции или композиции корректной и окончательной версии системы из элементов конфигурации, которые реализованы на этапах ЖЦ. Функционирование кода системы зависит от аппаратных средств и инструментов, с помощью которых строилась система;
– выбора инструментария построения версии, оценки возможностей среды и средств автоматизации процесса построения отдельных версий с корректной конфигурацией программного обеспечения и данных;
– управления вариантами версий из совокупности готовых идентифицированных элементов системы, удовлетворяющие заданным требованиям заказчика на систему.
При формировании версий системы учитываются ограничения на разработку системы во время этапов ЖЦ, которые, как правило, порождают ряд отклонений от требований на разработку элементов конфигурации системы. Например, принимается решение об изменении конфигурации способом, который не совпадает с предложенным и согласованным с заказчиком. Когда новая версия системы получена, заказчику передаются версия, конфигурация, документация и инструменты управления версиями для самостоятельного внесения изменений в эти элементы в процессе сопровождения системы.
Ярким примером формирования 21 версии на ОС 360 (1965-1980гг.) является фирма IBM. В ОС постоянно и поэтапно добавлялись новые функциональные возможности и вносились изменения в предыдущую версию при ее эксплуатации [13]. Над развитием дополнительных возможностей данной ОС и внесением изменений в предыдущую версию постоянно работал коллектив фирмы. Трудоемкость разработки очередной версии ОС считалась пропорциональной интервалу времени между регистрациями очередных версий и принималась за единицу измерения сложности создания новой версии [7].
В качестве меры трудоемкости сопровождения и создания очередной версии использовалось число модулей (ограниченных размеров со стандартизованным описанием), подвергающихся изменениям и дополнениям.
Кроме того, оценивалась интенсивность работ по созданию версии, которая измерялась числом измененных модулей в единицу времени. После 12 лет постоянных изменений в ОС, 21 версия работала более стабильно, в нее почти не вносились изменения, так как претензий со стороны пользователей в основном не поступало.
Метрический анализ процесса развития ОС 360 позволил установить, что объем среднего прироста системы на каждую версию соответствовал примерно 200 модулям. При этом общий объем увеличился от 1 тыс. модулей в первых версиях до 5 тыс. модулей в последних версиях. Когда уровень прироста сложности был большим, для устранения ошибок или дополнительных корректировок иногда создавались промежуточные версии с меньшим числом изменений.
В результате появилось понятие «критической массы» или критической сложности модифицируемой системы. Если при модернизации и выпуске очередной версии системы объем доработок превышает «критический», то возрастает вероятность ухудшения характеристик системы или необходимость введения промежуточной версии с внесением некоторых изменений. «Критический» объем доработок ОС–360 около 200 модулей оставался постоянным, несмотря на рост квалификации коллектива, совершенствование технических и программных средств и др. В первых версиях объем доработок составлял 20% модулей, а в последних версиях снизился до 5%.
Верификация и аттестация программ
Верификация и аттестация (валидация) – это методы, которые обеспечивают соответственно проверку и анализ правильности выполнения заданных функций и соответствия ПО требованиям заказчика, а также заданным спецификациям ПО [12–17]. Эти методы обозначены в стандарте ISO/IEC 12207 [18] как самостоятельные процессы ЖЦ и используются, начиная от этапа анализа требований и кончая проверкой правильности функционирования программного кода на заключительном этапе – тестировании.
Верификация – это проверка того, правильно ли система работает в соответствии с ее спецификацией и заданными требованиями заказчика, Этот процесс ЖЦ стандарта ISO/IEC 12207 позволяет сделать заключение о корректности сделанной системы.
Валидация
является методом проверки соответствия спроектированного ПО требованиям и потребностям заказчика и предполагает выполнение на этапах ЖЦ разного рода действий для получения корректных программ и систем:
– планирование процедур проверки и контроля проектных решений с помощью методик и просмотра хода разработки;
– повышения уровня автоматизации проектирования программ с использованием –CASE–систем [19];
– проверка правильности функционирования программ с помощью методик тестирования на наборах целевых тестов;
– структурирование системы на модули, их спецификации, реализация и использование их как повторных компонентов (reuse) [10, 20];
– адаптация продукта к условиям использования;
– управления проектом.
Валидация опирается на просмотры и инспекции промежуточных результатов на каждом этапе ЖЦ с целью анализа на соответствие их требованиям и тем самым позволяет подтвердить, что ПО имеет корректную реализацию начальных требований и условий к системе
Таким образом, основными особенностями методов верификации и валидации является проверка полноты, непротиворечивости и однозначности спецификаций требований к созданному ПО.
Верификация и валидация предполагают планирование этих процессов в целях распределения ресурсов и сосредоточения проверки на наиболее критичных элементах проекта, а именно:
– компонентов системы;
– интерфейса компонентов системы (программные, технические и информационные) и взаимодействий объектов (протоколов и сообщений) для функционирования в современных распределенных средах;
– средств доступа к БД и файлам, которые обеспечивают защиту от несанкционированного доступа к ним разных пользователей;
– документация на ПО;
– тестов и тестовых процедур;
– специальных средств защиты информации в системе.
По окончании проектирования приведенных элементов соответственно проводится:
– проверка правильности перевода отдельных компонентов в выходной код, а также описаний их интерфейсов, трассировки этих компонентов в соответствии с требованиями заказчика к функциям системы;
– анализ способов доступа к файлам или БД соответственно требований, принципов передачи данных и процедур манипулирования данными;
– проверка средств защиты на удовлетворение требованиям заказчика и правильности реализации.
По завершению процессов верификации и валидации создается комплект материалов отображающий правильность формирования требований, спецификация элементов системы, результатов проведения инспекций и тестирования программ.
Верификация и формализация требований
Сбор требований является начальным и неотъемлемым этапом процесса разработки ПС. Он заключается в определении набора функций, которые необходимо реализовать в продукте. Процесс сбора требований реализуется частично в общении с заказчиком, частично посредством мозговых штурмов разработчиков. Результатом является формирование набора требований к системе, именуемой в отечественной практике техническим заданием.
Фиксация требований (Requirement Capturing), с одной стороны, определяется желаниями заказчика в реализации того или иного свойства. С другой стороны в процессе сбора требований может обнаружиться ошибка, которая приведет к определенным последствиям, устранение которых заберет непредвиденные ресурсы – дополнительное кодирование, перепланирование.
Ошибка может быть тем серьезней, чем позже она будет обнаружена, особенно если это связано с множеством спецификаций. Поэтому одной из составляющей этапа фиксации требований, наряду со сбором является верификация требований, а именно проверка их на непротиворечивость и полноту.
Автоматизированная верификация требований может производиться лишь после спецификации или формализации требований.
Спецификация требований к ПО –
процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 12119-94, которые будут учитываться при создании программного продукта на этапах ЖЦ ПО. В спецификации требований отражается структура ПО, требования к функциям, показателям качеству, которых необходимо достигнуть, и к документации. В спецификации задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные требования, нефункциональные требования и требования к взаимодействию с другими компонентами (БД, СУБД, протоколы сети и др.).
Формализация
включает в себя определение компонентов системы и их состояний; правил взаимодействия компонентов и определения условий в формальном виде, которые должны выполняться при изменении состояний компонентов.
Для формального описания поведения системы используются языки инженерных спецификаций, например, UML. В качестве формальной модели для описания требований используются базовые протоколы, которые позволяют использовать дедуктивные средства верификации в сочетании с моделированием поведения систем путем трассирования.
Валидация (аттестация) требований - это проверка требований, изложенных в спецификации для того, чтобы убедиться, что они определяют данную систему и отслеживание источников требований. Заказчик и разработчик ПО проводят экспертизу сформированного варианта требований с тем, чтобы разработчик мог далее проводить разработку ПО. Одним из методов аттестации является прототипирование, т.е. быстрая отработка отдельных требований на конкретном инструменте и исследование масштабов изменения требований, измерение объема функциональности и стоимости, а также создание моделей оценки зрелости требований.
Верификация требований – это процесс проверки правильности спецификаций требований на их соответствие, непротиворечивость, полноту и выполнимость, а также на соответствие стандартам. В результате проверки требований делается согласованный выходной документ, устанавливающий полноту и корректность требований к ПО, а также возможность продолжить проектирование ПО.
Виды требований
Требования к продукту охватывают требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры).Термин пользователи относится ко всем заинтересованным лицам в создании системы.
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Каждая система имеет свои нефункциональные требования.
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик».
Системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы или вся система. Из требований для всей системы главными являются функциональные требования к ПО.
Функциональные требования включают описание требований в видам и типам реализуемых функций и документируются в спецификации требований к ПО (software requirements specification, SRS), где описано и ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и его функциями. В дополнение к функциональным требованиям спецификация содержит нефункциональные требования (защита данных, адаптивность, изменчивость и др.), где описаны цели и атрибуты качества.
Атрибуты качества (quality attributes) представляют собой дополнительное описание функций программного продукта, выраженных через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков бизнес–системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей и отдел маркетинга. Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Они не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения на выполнение конкретных вариантов использования или на функции системы, подчиняющимся соответствующим правилам. Бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.
ВСТУПЛЕНИЕ
Термину «программная инженерия» (Software engineering) уже более 30 лет. К моменту его появления компьютерные программы проникли во все cферы человеческой деятельности, а их разработка стала массовым занятием. Практически нет ни одной х сферы человеческой деятельности (медицина, экономика, коммерция, промышленность и т.д.), где бы не применялись компьютерные программы.
Примерно каждые 10 лет происходит смена языков программирования и ОС. Это приводит к необходимости изменять ранее изготовленные и функционирующие программы применительно к новым языкам и ОС. Например, преобразованием Фортран и Кобол программ в современные языки (С, JAVA и др.) занимаются огромные коллективы программистов из третьих стран и СНГ.
Эффективность разработчиков в зависимости от квалификации колеблется в отношении 20:200, отсюда требуется повышать уровень их знаний. На сегодня ядро стабильных знаний по программной инженерии составляет 75% от тех знаний, что используются в практической программисткой деятельности.
Эти условия поставили перед теоретиками и умудренными опытом программистами разработку новых инженерных методов создания и управления процессами проектирования, а перед прикладниками создание стандартов, регламентируюших эти процессы.
Знания разработчиков ПО отличаются большим разнообразием, являются не согласованными и разнородными, ориентированными на разные предметные области, поэтому мировая компьютерная общественность пришла к необходимости систематизировать знания в области программной инженерии, создав ядро знаний SWEBOK (Software Engineering Body Knowledge).
Программная инженрия (Software Engineering) является отраслью компьютерной науки, изучает вопросы построения программ для компьютеров, отражает закономерности развития в ней знаний, обобщает накопленный опыт программирования в виде комплексов общих знаний и правил регламентации инженерной деятельности разработчиков ПО.
Как инженерная дисциплина охватывает все аспекты создания ПО, начиная от разработки требований до создания, сопровождения и снятия с эксплуатации ПО, а также оценку трудозатрат, производительности и качества.
Инженерия изменений программных продуктов выполняется методами реинжинерии, реверсной инженерии (перепрограммирование) и рефакторинга программных компонентов и интерфейсов. Применение готовых продуктов (модулей, программ, систем и т.п.) в новых разработках привело к их инженерии, при которой компоненты становятся коммерческим продуктом, приносят прибыль разработчикам и сокращают затраты при создании новых систем за счет их накопления в репозитариях или электронных библиотеках.
Программостроение больших программных проектов становится инженерным по своей сути. В нем, кроме программистов, участвуют:
– менеджеры, которые планируют и управляют проектом, отслеживают сроки и затраты;
– инженеры службы хранения готовых компонентов;
– технологи, которые определяют инженерные методы и стандарты, регламентирующие и регулирующие процесс построения программных проектов;
– тестировщики, которые проверяют правильность выполнения процессов, сбор данных при тестировании и оценку качества компонентов и системы в целом.
Инструменты поддержки разработки ПО совершили гигантский скачок в своем развитии и теперь обычной практикой стало создание ПС с использованием современных визуальных и диаграммных средств UML.
Таким образом, возникновение программной инженерии определено следующими факторами:
– появление разнообразных сложных методов анализа и моделирования ПО;
– большое количество ошибок в ПО;
– необходимость в эффективной организации работы коллективов разработчиков ПО;
– повторное использование готовых программных компонентов и высокотехнологических средств разработки и управления ПО;
– реинженерия и рефакторинга отдельных компонентов систем, их адаптация к постоянно изменяющимся условиям и средам функционирования.
Материал данного учебного курса по программной инженерии разработан с учетом методов и средств ядра знаний SWEBOK. Он предназначен студентам, изучающим компьютерное дело, менеджерам коллективов программных проектов, желающих повысить уровень своей квалификации по планированию и управлению, а также профессионалам различных предметных областей.
Данный учебник состоит из тем по методам и средствам программной инженерии, которые необходимы для овладения профессией по инженерному созданию компьютерных систем. В конце каждой темы приводятся и контрольные вопросы и задания, а также используемая литература.
Тема 1. Введение в программную инженерию и процессы жизненного цикла. Дано определение программной инженерии, ее место в инженерной деятельности специалистов при создании компьютерных систем и общее описание десяти областей знаний профессионального ядра знаний SWEBOK.
Тема 2. Модели жизненного цикла для разработки программных систем. Описываются основные модели ЖЦ, которые используются в практике проектирования программных систем. Дана характеристика фундаментальных моделей ЖЦ (водопадной, спиральной, инкрементной, эволюционной) и стандартной модели.
В последние годы быстро развиваются
В последние годы быстро развиваются такие направления программной инженерии, как построение ПС из ПИК; инженерные методы проектирования, которые характеризуются проверкой достижения показателей качества компонентов на этапах ЖЦ и оценкой затраченных ресурсов и стоимости. Главное место среди этих методов занимает компонентный подход к построению ПС, так как принцип использования готовых компонентов является основой этого подхода и стратегическим направлением повышения производительности разработчиков и обеспечения качества ПС.
Компонентный подход расширяет существующие методы программирования ПС этим принципом, а также проверкой правильности ПИК для надежного приспособления к новым условиям ПС, формализацией и приведением в порядок процесса разработки из них ПС соответственно требованиям заказчика. В результате получается значительное упрощение процесс разработки самих компонентов и ПС из них и соответственно уменьшение сроков и затрат на разработку ПС.
Исследования и разработки в области инженерии программирования, основанного на использовании готовых ранее разработанных ПИК привели к тому, что сформировалось и используются два инженерных направления применения разных видов готовых ПИК при создании новых ПС [4]:
1) инженерия построения новых одиночных ПС уникального типа из ПИК. Это направление получило название прикладная инженерия (application engineering), которой соответствует процесс производства конкретных ПС как совокупности компонентов, подсистем и ПИК одного класса, созданных раньше как самостоятельные программные продукты или как элементы процесса инженерии некоторой предметной области;
2) инженерия построения готовых частей систем в конкретной ПрО. Это направление получило название инженерия проблемной области (domain engineering), которой соответствует процесс классификации и фиксации ПИК многоразового пользования в рамках конкретной ПрО в виде готовых частей системы, самой системы или семейства систем.
Данный процесс поддерживается системными инструментами обеспечения сбора, поиска, адаптации ПИК к новым условиям создаваемой системы семейства. Этим обеспечивается повторное использование не только элементов ПИК, а и инструментов поиска.
Обе разновидности инженерии базируются на объектно-ориентированных (ОО) методах анализа ПрО, методах проектирования классов объектов и образцов многоразового использования, которые создаются в разных системах и фиксируются как готовые решения для применения в других областях. Инженерность приложения и предметной области заключается в использовании в процессе проектирования методов поиска и оценки применимости ПИК, стоимости их приобретения и планирования работ по изготовлению из ПИК новых систем в заданные сроки. Инженерия ПИК предполагает проведение классификации и каталогизации готовых компонентов в специальных хранилищах для организации поиска, выбора с требуемыми функциями и характеристиками для последующего использования в новых проектах.
Анализ современных систем поддержки инженерии приложения (ОМТ, RUP, OOA/D и др.) показывает, что они ориентированы на разработку одиночных ПС и имеют такие недостатки:
1) отсутствует различие между разработкой и областью разработки для повторного использования и разработкой с повторным использованием. Областью разработки для повторного использования являются некоторые совокупности компонентов и подсистем. Процесс разработки с повторным использованием основывается на инструментальных средствах поиска и выбора готовых компонентов, которые создавались в процессе разработки одиночной системы для повторного использования;
2) повторное использование не базируется на модели ПрО, а ПИК создаются с ориентацией на создание отдельных одиночных программ;
3) отсутствует моделирование изменяемости компонентов в рамках одного приложения или нескольких приложений, которая может быть обеспечена использованием диаграмм классов UML с представлением изменяемых параметров и операций наследования, агрегации или параметризации.
Данные недостатки устраняются в рамках инженерии ПрО, для домена которой создается характеристическая модель, которая учитывает изменчивость параметров и разных характеристик для группы программных подсистем. Инженерия ПрО использует методы инженерии приложения по использованию ПИК и включает процессы корректировки и моделирования характеристик ПрО и их изменяемости; использует другие модели (Use Case, модели взаимодействия, переходов и т.п.) и механизмы повторного использования ПИК (хранение, поиск, оценивание, объединение).
Инженерия приложений фактически предназначена для создания целевых одиночных ПС из соответствующего набора ПИК, а инженерия предметной области ставит задачу создания множества программных систем для ПрО (домена) и совокупностей ПрО с выделением в этой ПрО отдельных функций или группы функций для проектирования подсистем, обладающих общими свойствами и характеристиками для многоразового использования в других доменах этой совокупности ПрО.
ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ И ЖИЗНЕННЫЙ ЦИКЛ ПО
Разработка и использование компьютерных программ в настоящее время стало массовой деятельностью. Более семи миллионов человек занимаются их разработкой, а сотни миллионов активно используют их в своей профессиональной деятельности [1]. Практически нет ни одной сферы деятельности (экономика, медицина, бизнес, коммерция, промышленность и т.д.), где бы программное обеспечение (ПО) не использовалось для автоматизации и улучшения этой деятельности. Спрос на ПО постоянно увеличивается, его сложность растет, а ошибки в ПО остаются.
Знания разработчиков ПО отличаются большим разнообразием, и, как правило, они являются не полными, не согласованными и разнородными, ориентированными на реализацию разных предметных областей, начиная от ОС и кончая современными прикладными бизнес-системами. И самое главное, что знания в процессе инженерной деятельности постепенно уточняются, видоизменяются и пополняются, за которыми не поспевают программисты.
Примерно каждые 10 лет происходит смена языков программирования и операционных сред для описания и функционирования программ. Это предполагает изменение ранее изготовленных и функционирующих программ в новые языки и операционные среды. На это тратятся огромные людские и финансовые ресурсы. Так, при изменении формата даты (2000 год) в программах и микросхемах на десятках млн. компьютеров участвовало более 2 млн. программистов, а затраты составили сотни млн. долларов. Переделка (реинженерия) ранее созданных прикладных Фортран программ в новые языки (С, Java и др.) и условия функционирования требует больших капиталовложений и привлечения программистов из третьих стран и СНГ.
В связи с появлением огромного количества новых видов и типов персональных компьютеров, а также Фреймворков с усовершенствованными ОС и средствами интероперабельности в программистском мире возникли большие сложности, связанные с адаптацией и переводом ранее действующих готовых прикладных систем и программ. Наиболее важные и необходимые из них преобразуются, тиражируются и поступают на рынок, как продукт для продажи (сидиромы, кассеты и т.п.).
Процесс формирования знаний в информатике и Computer Science послужил толчком для формирования самого претенциозного проекта 90-х годов в истории развития вычислительной техники – японский проект ЭВМ 5 поколения, который должен был сделать переворот в области проектирования и программирования ПО [2]. В этом проекте предполагалось, что в суперкомпьютеры будут заложены огромные интеллектуальные знания в виде экспертных систем, баз знаний, систем вывода новых знаний и т.п. Общение с такими суперкомпьютерами будет осуществляться голосом, образами, речью, а из постановок задач будут выводиться готовые решения без написания соответствующих программ. Этот проект не был реализован, так как знания специалистов–разработчиков таких компьютеров не были достаточно полными и совершенными и, кроме того, уровень интеллектуализации знаний на то время не был достаточно глубоко разработанным, чтобы идеи японского проекта воплотить в реальную аппаратуру и встроить в нее высоко интеллектуальные системы автоматизации постановок задач.
Проектирование и создание новых компьютерных систем, в том числе из готовых компонентов (Reusing) и систем, теоретически и практически осуществляется с учетом современных возможностей платформ и распределенных сред, в которых компоненты распределяются по разным узлам сети и взаимодействуют между собой через сетевые протоколы. Появились новые методы и подходы к разработке ПО: структурный, объектно-ориентированный, компонентный, аспектный, визуальный – UML, агентно-ориентированный, сервисный и др. [3-13].
Разработано огромное количество разнообразных инструментальных средств поддержки процесса проектирования ПО и методов оценки качества, производительности, стоимости и т.п. Процесс разработки ПО и методы оценки продукта, процессов ЖЦ стандартизованы (ISO/IEC 12207 [14], 15504 [15], ISO 9126[16-18] и др.). Все это способствует повышению уровня проектирования, тестирования, прогнозирования надежности и оценки качества ПО.
Вместе с тем, новый программный проект разрабатывается 1-2 года, а эволюционирует 6-7лет. На его сопровождение тратиться 61% затрат против 39% на его разработку. Эффективность разработчиков в зависимости от квалификации колеблется в отношении 20:200, отсюда требуется повышать уровень знаний разработчиков ПО. На сегодня ядро стабильных знаний по программной инженерии составляет 75% от тех знаний, что используются в практической программисткой деятельности.
В связи с этим мировое компьютерное сообщество пришло к необходимости систематизации накопленных знаний и общие из них зафиксировать в виде ядер знаний (Body of Knowledge – BOK) для разных областей информатики [19]. Для создания ядра знаний ПО был создан международный комитет при американском объединении компьютерных специалистов ACM (Association for Computing Machinery) и институте инженеров по электронике и электротехнике IEEE Computer Society. В комитет вошли специалисты мирового уровня в области информатики и разработки ПО, которые внесли свой опыт и знания, а также систематизировали накопленные разнородные знания и определили (1999г., 2001г., 2004г.) ядро профессиональных знаний SWEBOK (Software Engineering Body Knowledge) программной инженерии [20], как основы проектирования ПО. Ядро включает сумму знаний, распределенную по 10 специализированным областям, которые отражают отдельные процессы проектирования ЖЦ ПО и методы их поддержки.
Программная инженерия (Software Engineering) является отраслью Computer science, изучает вопросы построения компьютерных программ, отражает закономерности ее развития, обобщает опыт программирования в виде комплекса общих знаний и правил регламентации инженерной деятельности разработчиков ПО. В этом определении важно рассмотреть два основных аспекта.
1. Инженерная дисциплина, по которой инженеры применяя теоретические идеи, методы и средства для разработки ПО, проводят создание ПО, согласно стандартов, регламентирующих процессы проектирования и разработки.
2. Аспекты создания ПО. Программная инженерия рассматривает такие аспекты ПО как управление проектом ПО и разработка средств, методов и теорий, необходимых для создания качественных программных систем. Эта инженерная дисциплина предоставляет всю необходимую информацию и стандарты для выбора наиболее подходящего метода проектирования практических задач. Не исключается и творческий неформальный подход к созданию ПО.
Как инженерная дисциплина, она охватывает все аспекты создания ПО, начиная от формирования требований до создания, сопровождения и снятия с эксплуатации ПО, а также включает инженерные методы оценки трудозатрат, стоимости, производительности и качества. Т.е. речь идет именно об инженерной деятельности в программировании, поскольку ее сущность близка к определению инженерной деятельности в толковом словаре [2]:
1) инженерия есть применение научных результатов, что позволяет получать пользу от свойств материалов и источников энергии;
2) как деятельность по созданию машин для предоставления полезных услуг.
В программной инженерии, инженеры – это специалисты, выполняющие практические работы по реализации программ с применением теории, методов и средств компьютерной науки. Компьютерная наука (computer science) охватывает теорию и методы построения вычислительных и программных систем, тогда как программная инженерия рассматривает вопросы практического построения ПО. Знание компьютерной науки необходимо специалистам в области программного обеспечения так же, как знание физики – инженерам-электронщикам. Если для решения конкретных задач программирования не существует подходящих методов или теории, инженеры применяют свои знания, накопленные ими в процессе конкретных разработок ПО, а также используя опыт работы на соответствующих инструментальных программных средствах. Кроме того, инженеры должны работать в условиях заключенных контрактов и выполнять задачи с учетом этих условий.
В отличие от науки, целью которой есть получение знаний, для инженерии знание – это способ получения некоторой пользы. Как говорил известный специалист в области программой техники Ф.Брукс], «ученый строит, чтобы научиться, инженер учится, чтобы строить».
Таким образом, разработка программных систем можно считать инженерной деятельностью, имеющей значительные отличия от традиционной инженерии, в которой:
– ветви инженерии имеют высокую степень специализации, а у программной инженерии специализация заметна только в довольно узких применениях (например, операционные системы, трансляторы);
– объекты хорошо определены и манипуляции с ними происходят в узком контексте типичных проектных решений и деталей, которые отвечают типовым требованиям заказчиков и касаются отдельных деталей, а не общих вопросов, тогда как у программной инженерии подобная типизация отсутствует;
– отдельные готовые решения классифицированы и каталогизированы, а в программной инженерии каждая новая разработка - это новая проблема, в которой довольно тяжело рассмотреть аналогию с ранее разработанными системами.
Указанные отличия требуют проведения организационных и технических работ для превращения ее в специальность. В настоящее время мировая компьютерная общественность объединились в профессиональные комитеты и проводят такие работы: разработка ядра знаний SWEBOK, этического кодекса программиста [13], учебных курсов подготовки соответствующих специалистов, обучение специальности, сертификация специалистов в области программной инженерии и др.
Следующим шагом деятельности этих организаций и комитетов является создание общей компьютерной программы обучения – Curricula 2001 [8]. В ней содержатся рекомендации по структуре и преподаванию 15 учебных курсов по информатике (дискретные системы, программирование, теория сложности, ОС и др.) в том числе и по программной инженерии, как дисциплины, изучающей теорию, знания и практику эффективного построения ПО на всех этапах ЖЦ, которым соответствуют области знаний в SWEBOK.
В разработке больших программных проектов, кроме программистов, принимают участие:
– менеджеры, которые планируют и руководят проектом, отслеживают сроки и затраты;
– инженеры службы хранения готовых компонентов в библиотеках и репозитариях;
– технологи, которые определяют инженерные методы и стандарты, регламентирующие и регулирующие процесс реализации проекта;
– тестировщики (контролеры), которые проверяют правильность выполнения процесса проектирования и продуктов процессов, на основе собранных данных проводят измерения разных характеристик качества, включая оценку надежности ПО.
Таким образом, возникновение программной инженерии как дисциплины разработки ПО определено следующими важными факторами:
– накопленным значительным объемом интеллектуальных знаний в области создания ПО;
– появлением новых разнообразных методов анализа, моделирования и проектирования ПО;
– необходимостью совершенствования методов обнаружения ошибок в ПО;
– потребностями эффективной организации коллективов разработчиков ПО и оценки их деятельности;
– использованием готовых программных компонентов, высоко технологических средств и инструментов разработки ПО;
– реинженерией компонентов и систем для их адаптации к новым изменяющимся условиям сред и сетей.
Программная инженерия, как инженерная дисциплина, делает главный акцент на повышение качества и производительности ПО за счет применения новых и усовершенствованных: методов проектирования ПО; готовых компонентов и методов их генерации; методов эволюции ПО; методов верификации и тестирования ПО; инструментальных средств поддержки; методов управления проектами, методов оценки качества, производительности, стоимости и т.п.; стандартизации процессов разработки ПО (ISO/IEC 12207, ISO/IEC 15504, ISO 9126 и др.), регламентирующих этапы ЖЦ; подходов к оценке продуктов и процессов.
В данном разделе темы лекций дается систематическое изложение следующих взаимосвязанных аспектов в инженерии проектировании ПО:
– теоретический и интеллектуальный базис (методы, принципы, средства и методологии и др.) проектирования, представленный в ядре SWEBOK, способствующий созданию высококачественных программных продуктов и удовлетворяющих заданным заказчиком функциональных и нефункциональных требований;
– связь теоретических аспектов программирования с готовыми стандартами в области программной инженерии, которые регламентируют деятельность специалистов-разработчиков ПО и организационные мероприятия по выполнению процессов верификации, валидации, тестирования, метрического анализа и оценки промежуточных и конечного результатов этой деятельности;
– концепции обучения разработчиков ПО методам и средствам программной инженерии, стандартным процессам ЖЦ с целью научить их методологии проектирования ПО, использующей знания в области программной инженерии и положений современных стандартов, регламентирующих процессы разработки, планирования, управления программным проектом, качеством, рисками и ресурсами проекта.
Введение в жизненный цикл ПО стандарта
Программная инженерия, как инженерная дисциплина охватывает все аспекты создания ПО от начальной стадии разработки системных требований, создания ПО и его использования. Эталонная модель программной инженерии включает три взаимосвязанных фактора: процессы, программные продукты, ресурсы (человеческие, технические и финансовые).
Каждая ПС на протяжении своего существования проходит определенную последовательность процессов (этапов), начиная от постановки задачи, до ее воплощения в готовую программу, эксплуатации и изъятия. Такая последовательность этапов называется жизненным циклом (ЖЦ) разработки ПС. На каждом этапе ЖЦ выполняется определенная совокупность процессов и/или подпроцессов, каждый из которых порождает соответствующий промежуточный продукт, используя результаты предыдущего.
Все продукты процессов программной инженерии представляют собой некоторые описания, а именно тексты требований к разработке, согласование договоренностей с заказчиком, архитектура, структура данных, тексты программ, документация, инструкции по эксплуатации и т.п.
Главными ресурсами разработки ПС в программной инженерии являются сроки, время и стоимость. Правильное использование этих ресурсов на процессах ЖЦ определяет эффективность этой разработки.
Разновидности действий и задач, представленные в процессах ЖЦ ПС, отображены в международном стандарте ISO\IEC 12207 (таблица 1) и связаны содержательно с областями знаний SWEBOK.
Данный стандарт устанавливает архитектуру верхнего уровня ЖЦ ПО, начиная от разработки концепции до утилизации системы. Архитектура представляет собой множество процессов, взаимосвязей между ними и определяет действия и задачи, т.е, он определяет, что надо делать, а не как надо выполнять действия или задачи процессов.
Стандарт не обязывает использовать определенную модель ЖЦ ПО или конкретную методологию разработки ПО и не предъявляет требования к формату и содержанию создаваемых документов.
Поэтому организации– пользователю этого стандарта потребуются для своей работы дополнительные стандарты или процедуры, определяющие разные детали процесса (ISO выпускает руководства и процедуры, дополняющие стандарт 12207).
Основная идея данного стандарта состоит в том, что разработка и сопровождение ПО должно осуществляться так, как этого требует инженерная дисциплина. Следуя этой идее, разрабатывается каркас (framework), имеющий четкие связи с окружением системной инженерии - ПО, техническим обеспечением, исполнителями и деловой практикой.
Все процессы в данном стандарте разделены на три категории:
– основные процессы;
– обеспечивающие (поддерживающие) процессы;
– организационные процессы.
Для каждого из процессов определены виды деятельности (действия - activity) и задачи и определяется совокупность результатов (выходов) видов деятельности и задач, а также некоторые специфические требования. Стандарт дает перечень работ для основных обеспечивающих и организационных процессов.
Процессы ЖЦ в стандарте ISO/IEC 12207 Таблица 1
|
№ п/п |
Наименование процессов (подпроцессов) |
|||||||||
|
Категория “Основные процессы” |
||||||||||
|
1.1 |
Заказ (договор) |
|||||||||
|
1.1.1 |
Подготовка заказа, выбор поставщика |
|||||||||
|
1.1.3 |
Мониторинг деятельности поставщика, прием потребителем |
|||||||||
|
1.2 |
Поставка (приобретение) |
|||||||||
|
1.3 |
Разработка |
|||||||||
|
1.3.1 |
Выявление требований |
|||||||||
|
1.3.2 |
Анализ требований к системе |
|||||||||
|
1.3.3 |
Проектирование архитектуры системы |
|||||||||
|
1.3.4 |
Анализ требований к ПО системы |
|||||||||
|
1.3.5 |
Проектирование ПО |
|||||||||
|
1.3.6 |
Конструирование (кодирование) ПО |
|||||||||
|
1.3.7 |
Интеграция ПО |
|||||||||
|
1.3.8 |
Тестирование ПО |
|||||||||
|
1.3.9 |
Системная интеграция |
|||||||||
|
1.3.10 |
Системное тестирование |
|||||||||
|
1.3.11 |
Инсталляция ПО |
|||||||||
|
1.4 |
Эксплуатация |
|||||||||
|
1.4.1 |
Функциональное использование |
|||||||||
|
1.4.2 |
Поддержка потребителя |
|||||||||
|
1.5 |
Сопровождение |
|||||||||
|
Категория “Процессы поддержки” |
||||||||||
|
2.1 |
Документирование |
|||||||||
|
2.2 |
Управление конфигурацией |
|||||||||
|
2.3 |
Обеспечение гарантии качества |
|||||||||
|
2.4 |
Верификация |
|||||||||
|
2.5 |
Валидация |
|||||||||
|
2.6 |
Общий просмотр |
|||||||||
|
2.7 |
Аудит |
|||||||||
|
2.8 |
Решение проблем |
|||||||||
|
2.9 |
Обеспечение применимости продукта |
|||||||||
|
2.10 |
Оценивание продукта |
|||||||||
|
Категория “Организационные процессы” |
||||||||||
|
3.1 |
Категория |
|||||||||
|
3.1.1 |
Управление на уровне организации |
|||||||||
|
3.1.2 |
Управление проектом |
|||||||||
|
3.1.3 |
Управление качеством |
|||||||||
|
3.1.4 |
Управление риском |
|||||||||
|
3.1.5 |
Организационное обеспечение |
|||||||||
|
3.1.6 |
Измерение |
|||||||||
|
3.1.7 |
Управления знаниями |
|||||||||
|
3.2 |
Усовершенствование |
|||||||||
|
3.2.1 |
Внедрение процессов |
|||||||||
|
3.2.2 |
Оценивание процессов |
|||||||||
|
3.2.3 |
Усовершенствование процессов |
|||||||||
К основным процессам относятся:
–
процесс приобретения инициирует ЖЦ ПО и определяет действия организации-покупателя (или заказчика), которая приобретает автоматизированную систему, программный продукт или сервис. Этот процесс включает следующие виды деятельности: инициация; подготовка запроса, контракта и его актуализация; мониторинг поставщиков; приемка и завершение;
– процесс поставки определяет действия предприятия - поставщика, которое снабжает покупателя системой, программным продуктом или сервисом. Данный процесс включает в себя следующие виды деятельности: инициация; подготовка предложений (ответа на запрос); контракт; планирование; выполнение и контроль; анализ и оценка; поставка и завершение. Процесс поставки начинается тогда, когда устанавливаются договорные отношения на поставку ПО между заказчиком и поставщиком. В зависимости от условий договора процесс поставки может включать процесс разработки ПО, процесс эксплуатации для обеспечения служб эксплуатации ПО или процесс сопровождения для исправления и улучшения ПО;
– процесс разработки определяет действия предприятия - разработчика, которое разрабатывает программный продукт. Этот процесс включает в себя: внедрение процесса (implementation); анализ требований к системе; проектирование архитектуры системы; анализ требований к ПО; проектирование архитектуры ПО; детальное проектирование ПО; кодирование и тестирование ПО; интеграция ПО; интеграция системы; квалификационное тестирование; установка ПО; обеспечение приемки ПО;
– процесс эксплуатации определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (ПО) в процессе ее эксплуатации пользователями (консультирование пользователей, изучение их потребностей с точки зрения удовлетворения их системой и т.д.). Этот процесс направлен на: внедрение процесса; функциональное тестирование; эксплуатацию системы; обеспечение пользователя документацией по проведению эксплуатации ПО;
– процесс сопровождения определяет действия организации, выполняющей сопровождение программного продукта (управление модификациями, поддержку текущего состояния и функциональной пригодности, инсталляцию и удаление программного продукта на вычислительной системе пользователя).
Данный процесс ориентирован на: внедрение процесса; анализ проблем и модификация; реализация модификаций; анализ сопровождения; миграция (перемещение) ПО; удаление ПО.
К обеспечивающим процессам создания ПС относятся: документирование, управление версиями, верификация и валидация, просмотры, аудиты, оценивание продукта и др. Процессы управления версиями соответствуют управлению конфигурацией системы, которая также, как и продукты процессы, должны проверяться на правильность реализации целей проекта и соответствия требованиям заказчика. Задачи проверки рекомендуется выполнять специальные контролеры, обладающие знаниями методов и процессов.
К организационным процессам относятся процессы управления проектом (менеджмент разработки), качеством, риском и др. Эти процессы организационно поддерживаются специальными службами: контроля процессов, измерения продуктов, проверки качества, соблюдения стандартных положений и др. Предполагает проведение обучения персонала, определение набора задач и ответственности каждого участника в реализации задач на процессах ЖЦ и др.
Процессы, определенные в этом стандарте, образуют полное множество. Пользователь стандарта может выбрать соответствующее подмножество для достижения своей конкретной цели. Процессы, действия и задачи приведены в стандарте в наиболее общей естественной последовательности. В зависимости от целей конкретного проекта процессы, действия и задачи выбираются, упорядочиваются и применяются итерационно или рекурсивно. Разработчик должен определить или выбрать модель ЖЦ ПО в зависимости от сложности, стоимости и ресурсов программного проекта.
Задачи областей
SWEBOK
стандарта
Идентификация элементов.
Контроль конфигурации.
Учет статуса.
Аудит.
Управления версиями.
Определение конфигурации.
Контроль конфигурации.
Учет состояния конфигурации.
Оценка конфигурации.
Управление реализацией и поставкой.
Управления процессами и проектом.
Планирование проектом.
Инженерия измерения ПО.
Управление риском.
Планирование.
Выполнение и контроль.
Анализ управления проектом:
– технический анализ;
– аудит (ревизия).
Определение и планирование качеством. Верификация и валидация.
Измерение в анализе качества ПО.
Обеспечение производства.
Обеспечение качества.
Процесс верификации.
Процесс валидации.
Анализ и оценивание качества.
Инструменты инженерии.
– определение процесса;
– оценка процесса;
– улучшение процесса.
Анализ проекта.
Выполнения изменений.
Оценки стоимости и затрат.
Создание инфраструктуры.
Сопровождение инфраструктуры.
Завершение.
Жизненный цикл компонентной разработки ПС
Существует много различных методологий компонентной разработки ПС, которые отличаются методами интеграции, способами описания компонентов, языками определения интерфейсов, способами построения интегрированной среды и др. К основным этапам компонентной разработки ПС относятся:
1) разработка требований (Requirements) к ПС согласно с компонентной методологией;
2) анализ поведения (Behavioral Analysis) для ПС для определения сервисных аспектов программы и соответствующие процессы обработки данных;
3) спецификация интерфейсов и взаимодействия компонентов (Interface and Interaction Specification);
4) интеграция компонентов в единую среду для ПС на основе новых компонентов и компонентов повторного применения (Application Assembly and Component Reuse);
5) развертывание (System Deployment) ПС у пользователя;
6) поддержка и сопровождение (System Support and Maintenance) ПС.
Под интегрированной средой понимается результат завершения работы на этапе интеграции, т.е. макета ПС, которая будет функционировать у пользователя. Программная система – это результат работы после этапа развертывания, характеризуется привязкой к компьютерной и сетевой среде пользователя. Кроме этого, компоненты системы могут приобретаться пользователем в отдельности и выполняться самостоятельно.
