Метод анализа и оценки PERT

Параллельно с разработкой CPM, в военно-морских силах США был создан (фирма "Буз, Аллен & Гамильтон")  метод анализа и оценки программ PERT (Program Evaluation and Review Technique) для реализации проекта разработки ракетной системы "Polaris", объединяющей около 3800 подрядчиков с числом операций более  60 тыс. [6].  

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

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

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

В этом методе возможное время выполнения операций оценивается с помощью трех оценок:

– оптимистичной (О),

– пессимистической (P),

– вероятностной  (B).

А далее вычисляется по формуле:   (О+4В+П)/6, c   указанием его  на сетевом графике.

Для уменьшения провалов проектов используются  и другие  аналитические методы  и усовершенствованные языки разработки систем.  Как показывает опыт, "продвинутые" технологии решают вопросы успешного создания проекта с учетом факторов, которые уменьшают его провал [3]:

1. Проект начинать с правильного шага.

2. Поддержка темпа работы.

3. Обеспечение прогресса   и  правильных решений.

4. Посмертный анализ  завершенного  проекта.

 

1). Проект начинать с правильного шага. К правильному шагу относится  формирование команды  разработчиков из хороших специалистов, в  том  числе  не более 20%  звезд,   наиболее приспособленных для хорошей работы  над  проектом (много  звезд - создание конфликтов). В команду входят надежные разработчики  с  совместимыми  характерами  и рабочими привычками. Звезды  решают  сложные   вопросы,   разрабатывают   более    ответственные алгоритмы и  проводят  техническое  обучение  остальных членов команды. Для уточнения всех  особенностей проекта разработчики  садятся  за стол переговоров с  заказчиком и составляют взаимно приемлемый документ.

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

2).  Поддержка темпа работы состоит в:

–        уменьшении   текучести кадров;



–        контроле качества выполняемых работ; 

–        управлении процессом разработки, а не людьми.

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

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

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

 

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

 

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

Метод анализа и построения моделей СШлаер и СМеллора

   

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

– информационная  модель  системы или онтология домена;

– модель состояний объектов,  определенных  в  составе информационной модели (или онтологии);

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

Ниже рассматриваются эти модели.

    

Метод функционального моделирования SADT

Метод функционального моделирования SADT. На основе метода SADT, предложенного Д. Россом, разработана методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

Основные элементы этого метода основываются на следующих концепциях:

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

– строгость и точность. Правила SADT строги и имеют ограничения на  количество блоков на каждом уровне декомпозиции (от 3 до 6 блоков) и связность диаграмм через номера блоков;

– уникальность меток и наименований;

– разделение входов и управлений ( определение роли данных).

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

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

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.
Диаграммы – главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), осуществляющий операцию, представляется дугой, входящей в блок снизу (рис.5.1).

Рис. 5.1. Структура  модели

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

 

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

 

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

– определение функций;

– моделирование взаимосвязей событий и сущностей;

– логическое  проектирование данных;

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

– логическое проектирование БД;

– физическое  проектирования.

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

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



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

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

– спецификацию функций и схемы реализации компонентов функций,

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

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

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

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

 

Метод инженерии требований А Джекобсона

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

Автор назвал  свой метод как базирующийся на вариантах (примерах или сценариях –use case driven) системы, которую требуется построить. В дальнейшем термин сценарий используется для обозначения  варианта представления  системы.

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

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

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

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

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

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

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

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

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

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

Лицо в роли (экземпляр актера) запускает операции в системе, соотнесенные с поведением последовательности транзакций системы и  называется сценарием.


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

Экземпляр сценария существует, пока он выполняется и его можно считать экземпляром класса,  в  роли  которого  выступает описание транзакции.

Сценарий определяет протекание событий в  системе  и обладает состоянием и поведением. Каждое взаимодействие между актером и системой это новый сценарий или объект. Если несколько сценариев системы имеют одинаковое поведение, то их можно рассматривать как класс сценариев. Вызов сценария – это порождение экземпляра класса. Таким образом, сценарии – это транзакции с внутренним состоянием.

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

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

Для задания модели сценариев используется  специальная графическая нотация, со следующими основными правилами:

– актер обозначается иконой человека, под которой указывается  название;

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

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

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



 



                                   Рис.3.2. Пример диаграммы сценариев для клиента банка

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

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

Для сценариев определены два типа отношений:

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

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

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

 

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



                                  Рис.3.3. Примеры расширения сценариев

На рис. 3.4. показано, что сценарий "сортировать" связан отношением "использует" с несколькими сценариями.





                              Рис.3.4. Пример отношения "использует "

Таким образом, продуктом первой стадии инженерии требований (сбора требований) является  модель требований, которая состоит с трех частей:

1) онтология домена;

2) модель сценариев, называемая диаграммой сценариев;

3) описание интерфейсов сценариев.

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

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

– аннотация (краткое содержание в неформальном представлении);

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

– определение всех аспектов взаимодействия системы с актерами (возможные действия актера и их возможные последствия), а также запрещенных действий актера;

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

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

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

– реакции на предвиденные нестандартные ситуации;

– условия завершения сценария;

– постусловия, которые определяют конечное состояние сценария при его завершении.

 

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

– механизмы запуска сценария (позиции меню);

– механизмы ввода данных;

– поведение при возникновении чрезвычайных ситуаций.

 

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

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

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

Метод критического пути СРМ

Оснополагающим моментом создания этого метода является исследование возможности  эффективного использования вычислительной машины Univac на фирме “Dupon” при  планировании и создании  планов-графиков больших комплексов работ по модернизации заводов этой фирмы. В результате был создан рациональный и простой метод (Уолкера – Келли) управления  проектом с использованием ЭВМ, который был назван CPM (Critical Path Method )   методом критического пути.

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

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

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

                                                                            

         

                                           А                   1нед.               F

                                                                                             

                                        3нед.                                   3 нед.     

             начало                                       2 нед.                                 конец

             работ                                                                                    работ

                                       A2    

                                        4 нед.               2 нед.

 

                 Рис.10.1. Граф задания сроков выполнения работ

                                                                     

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

Представление в таком виде работ называется

сетевая диаграммой

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

Метод моделирования UML

Метод UML (United Modeling Language – унифицированный язык моделирования) является результатом совместной разработки специалистов программной инженерии и инженерии требований [6, 7]. Он широко используется ведущими разработчиками программного обеспечения как метод моделирования программных продуктов  на всех стадиях жизненного цикла разработки программных систем.

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

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

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

– модель процессов определяет действия, которые выполняют объекты.

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

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

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

Некоторые стереотипы являются фиксированными в UML и имеют стандартные названия, например,  <<актер>>, <<система>>, <<подсистема>>, <<исключительная ситуация>>, <<интерфейс>> и т.п.

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

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

 

Диаграмма классов  (Class diagram) отображает онтологию домена и по содержанию  эквивалентна информационной модели метода С.Шлаера и С.Меллора. Она определяет состав классов объектов и их взаимоотношения.

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

Атрибутами могут быть типы значений в UML:

– рublic (общий), что означает операцию класса, вызванную из любой части программы любым объектом системы,

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

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

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

Классы могут находиться в следующих отношениях или связях.

Ассоциация –  взаимная зависимость между объектами разных классов, каждый из которых является  равноправным ее членом. Она  может обозначать количество экземпляров объектов каждого класса, которые принимают участие в связи (0 –  если ни одного, 1 – если один, * – если много).

Зависимость между классами, при которой  класс–клиент может использовать определенную операцию другого класса; классы могут быть связаны отношением трассирования, если один класс трансформируется во второй в результате определенного процесса ЖЦ.



Экземпляризация – зависимость между параметризированным абстрактным классом–шаблоном (template) и реальным   классом,  который  инициирует  параметры  шаблона (например, контейнерные классы языка  С++).

 

Диаграмма сценариев.       Содержание и нотация этой диаграммы полностью совпадает с той, которая  описана  в методе Э.Джекобсона (см.п.3.).

 

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

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

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

– активность, показывающей  потоки управления при взаимодействии объектов;

– состояний, указывающих на динамику изменения объектов.

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

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

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

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



Диаграмма состояний базируется на использовании расширенной модели конечного автомата  и определяет:

– условия переходов и действия при переходе;

– действия при входе в состояние, его  активности и  при выходе из состояния;

– вложенные и параллельно действующие состояния.

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

Диаграмма реализации состоит из  диаграммы компонента и диаграммы размещения.

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

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

 

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

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

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

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


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

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

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

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

 

Методология компонентной разработки систем

Эта методология  включает в себя две основные фазы процесса разработки.

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

–        формализованное определение спецификаций интерфейсов, поведения и функциональности компонента;

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

–        обеспечение принципа повторности.

Интеграция (композиция) компонентов в более сложные программные образования:

–        разработка требований (Requirements) к программной системе;

–        анализ поведения (Behavioral Analysis) программной системы;

–        спецификация интерфейсов и взаимодействия компонентов (Interface and Interaction Specification);

–        интеграция разработанных компонентов и компонентов повторного использования (Application Assembly and Component Reuse) в единую среду;

–        тестирование компонентов и среды;

–        развертывание (System Deployment) программной системы у пользователя;

–        поддержка и сопровождение программной системы (System Support and Maintenance).

МЕТОДЫ АНАЛИЗА И ПОСТРОЕНИЯ МОДЕЛЕЙ ПрО

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

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

Далее рассматривается два направления проектирования архитектуры системы, основанные на применении:

1)  объектно-ориентированных методов (например, OOAS, OOA, OMT и др.);

2) стандартных и общесистемных методов  (Гост  ГОСТ 34.601-90, ER-моделирование и др.).  

Методы доказательства правильности программ

Эти  методы появились  в 80–е годы и  разделяются  на два класса:

1. Точные методы доказательства правильности программ.

2.  Методы  доказательства  частичной правильности программ.         

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

Методы доказательства программ

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

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

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

К методам проверки правильности программ относятся:

1)  методы доказательство правильности программ;

2)  верификация и аттестация программ.

Методы и средства инженерии ПО (Software Engineering Tools and Methods)

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

Область знаний «Методы и средства инженерии ПО (Software Engineering Tools and Methods)» состоит из разделов:

– инструменты (Software Tools),

– методы (Software Methods).

 

Инструменты ПО подразделяются на инструменты:

– работы с требованиями,

– проектирования ПО (редакторы схем и диаграмм),

– конструирования ПО (редакторы текстов, компиляторы, отладчики),

– тестирования (генераторы тестов, среды исполнения тестов),

– автоматизации процесса инженерии ПО,

– контроля качества,

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

– управления инженерией ПО (планирование проектов, управление рисками).

 

Методы инженерии ПО включают эвристические (неформальные) методы – структурные, объектно-ориентированные, ориентированные на  данные  и на прикладную область, а также формальные методы проектирования и прототипирования.

 

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

Методы интеграции (композиции) компонентов

Термин интеграция олицетворяет собой действия по обеспечению способа взаимодействия разных  компонент (аппаратных и программных) и  представления данных в рамках одной системы или среды. К интеграционным операциям можно отнести: сборку, комплексирование, композицию,  взаимодействие и др. Некоторые из этих операций (например, комплексирование) означают объединение компонент по в единое целое ( в комплекс, систему, агрегат и др.). Такой подход к решению проблемы интеграции  соответствовал периоду бурного развития и существования больших машин (mainframes),  которые позволяли объединять программные компоненты  в монолитные системы и комплексы больших размеров (до 100–200тыс. команд). Одновременно с этим интеграция коснулась и данных (файлы, БД,  интегрированные БД и др.).

 

Однако с приходом на смену больших машин разных видов малых  компьютеров, объединяемых  в локальные и глобальные сети проблема интеграции приобрела другой смысл. Понятие монолитной системы  заменилось интегрированной, распределенной  системой или средой, включающей все необходимые средства  для обеспечения  единообразного взаимодействия с ними разных пользователей. Появились и в настоящее время функционируют крупные международные распределенные системы (RPC Sun, OSF DCE, COM, SOM, CORBA и др.), которые предоставляют  средства интеграции программных компонент в каркасы и  конфигурации, основанные на стандартной  модели  взаимодействия компонент  в открытых системах (Open Systems Interconnection – OSI) [1].

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

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

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

 – вертикальная модель для взаимодействия компонентов между уровнями.

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

Распределенные системы общего назначения построены согласно   модели OSI и предоставляют прикладным приложениям готовый набор ([20]): сервисных операций (управление и хранение объектов,  обслуживание очередей и запросов к БД, др.);  общих  средств обслуживания приложений (администрирование, управление интерфейсами, др.);  средств описания и поддержки взаимодействий объектов приложений, инструментариев (автоматизация приложений и БД, генераторы интерфейсов взаимодействия и др.);  типовых функциональных  компонентов  для предметных областей: медицины, финансов, страхования и др.

К распределенным  системам, обеспечивающим взаимодействие компонентов относятся:

– ОNС  SUN,  OSF DSE [2], основанные на механизме  вызова удаленных процедур;

–  DCOM [3] c возможностью связи распределенных объектов и документов;

 ОМА (Object Managment Architecture)  [4] с широким набором  средств взаимодействия объектов c помощью брокера  с помощью брокера объектных запросов;

– система JAVA [5] , основанная на методе вызова RMI и  др.

 

К основным механизмам взаимодействия  компонентов  и объектов сетевой среды на уровне внешних языков относятся:

– RPC–язык (Remote Procedure Call)  вызова удаленных процедур;

–  язык описания интерфейсов (Interface Definition Languge – IDL),



– механизм посылки запросов RMI в ЯП Java [5–7].

 

RPC–механизм  включает языки высокого и низкого уровня для описания интерфейса взаимодействующих удаленных компонентов. На языке высокого уровня в интерфейсе компонента описывается  оператор RPC

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

Данный механизм обеспечивает взаимосвязь одного процесса   с удаленно расположенным от него другим процессом (например,  сервером) на другой машине   с помощью протоколов UDP и TCP/IP. Связывающим звеном между вызываемым и вызывающим процессом является  интерфейс объекта (stub) или посредник клиента при его взаимодействии с сервером   сети. Вызывающий объект  клиенте обращается к  stub–клиента для посылки  сообщения stub–сервера в целях выполнения удаленной процедуры.

Механизм посылки запроса в системе CORBA включает оператор вызова удаленного метода/функции объекта, системные средства его поддержки с помощью протоколов IIOP,  GIOP, которые выполняет  брокер ORB. Оператор запроса и его параметры формально описываются на IDL – языке  и  размещаются в интерфейсе объекта  (stub–клиента) для  обращения к серверу через интерфейс  stub / skeleton в целях выполнения указанного в сообщении  удаленного метода.

Интерфейсы (stub и skeleton) отображаются  в ЯП  объектов с помощью IDL–генератора. Функции посылки запроса выполняет брокер ORB системы CORBA, которая содержит:

– язык IDL  и генератор трансформации описания интерфейса в соответствующий ЯП;

– общий объектный сервис  (Common Object  Services) для управления событиями,  транзакциями,  интерфейсами,  запросами и др.;

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



Брокер ORB является главной парадигмой  взаимодействия компонентов в разных приложениях и   средах.  Он реализован многими фирмами и содержится в системах: COM,  SOM, Nextstep и др. Этим  обеспечена совместимость  программных компонентов друг с другом, сделанных для  разных сред, а также  взаимодействие между самими брокерами в объединенных сетях.

Вызов удаленного метода RMI   реализован в системе JAVA и предназначен для  проектирование приложений  со стандартным вызовом удаленных  компонентов. По своим функциям этот метод  аналогичен функциям брокера ORB,  обеспечивает передачу сообщений, их синхронизацию  и освобождение памяти  после выполнения компонентов. Виртуальная машина (virtual machine) работает с byte–кодами компонентов на других ЯП и  интерпретирует  коды  той машины, для  которой  компонент был скомпилирован. Иными словами, разработан новый подход к проектированию связей и управлений объектами в  распределенных  системах, которые описываются в  языках  JAVA и С++.

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

МЕТОДЫ ОПРЕДЕЛЕНИЯ ТРЕБОВАНИЙ В ПРОГРАММНОЙ ИНЖЕНЕРИИ

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

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

Тема 3. Методы определения  требований в программной инженерии.  Приведены методы и  инженерия требований к  системе. Рассмотрен процесс сбора, накопления и спецификации требований. Дана классификация требований и характеристика функциональных и нефункциональных требований.

Тема 4. Методы анализа и построения моделей  ПрО. Приведены методы анализа предметной области и  построения моделей. Рассмотрены объектно–ориентированные  и стандартизованные, традиционные  методы проектирования архитектуры системы.

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

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

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

Тема 8. Методы интеграции, преобразования и   изменения компонентов и данных. Рассмотрены основы интеграции и  преобразования программ и данных, а также  методы изменения (реинженерия, реверсная  инженерия и рефакторинга)  компонентов и систем. 

Тема 9. Модели качества и надежности в программной инженерии. Посвящена представлению моделей качества ПС, метрикам и методам достижения и  измерения  качества ПС. Рассмотрен основной показатель качества – надежность,  дано описание математических моделей надежности и способов их применения на практике.

Тема 10. Методы управления проектом, риском и конфигурацией. Проведен анализ и дано описание инженерии программирования,  принципов и методов планирования и управления программным проектом, рисками и формированием версий ПС.

Тема 11. Средства и инструменты программной инженерии.  Дан обзор современных  средств программирования и  характеристика широко используемых  CASE-средств (Project Management, Rational Rose, MSF,  RUP, CORBA, DCOM и др.), при  объектно–ориентированном проектировании  ПС.

Приложение 1.  Набор основных терминов, используемых в программной инженерии.

Приложение 2.  Характеристика стандартов разработки автоматизированных систем.

Приложение 3.  Жизненный цикл компонентной разработки ПС.

Приложение 4.  Кодекс этики в программной инженерии.

Приложение 5.  Стандарты в программной инженерии.

Методы преобразования программ и данных

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

 

Преобразования типов данных  проводится по  трем направлениям.

 

Первое направление связано с разными форматами представления данных в программах,  которые расположены в разных средах или на разных платформах. Процедура преобразования данных из одного формата в другой получило название маршаллинга (marshalling) данных и включает линеризацию сложных структур данных с учетом порядка расположения байтов и стратегии их  выравнивания  до  границ на каждой платформе. Например, в системе CORBA для этих целей используется  стандарт общего  формата представления данных  – CDR (Common Representation Data) [4].

 

Второе  направление связано с наличием отличий в описании  типов данных разных ЯП и  необходимостью эквивалентного  их преобразования c помощью таких механизмов: удаленный вызов процедур RPC [1, 2] и RMI  [4],  языка описания интерфейсов Stub в   IDL  и стандарта, определяющего независимые от языков типы данных» (ISO/IEC 11404–96) [8].

 

Третье направление связано с заменой одной БД на другую, имеющие отличие в моделях данных (иерархические, сетевые, реляционные) и  функционируют в разных средах СУБД [9, 10].

В основе  рассмотрения этих трех направлений лежат методы и подходы решения проблемы преобразования данных, а также результаты исследований и разработок, освещенные в работах  [1–14].

            

Методы проектирования архитектуры ПО

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

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

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

 

МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ

В последние годы наибольшее развитие и использование получил объектно–ориентированный, компонентный, сервисно–ориентированный подходы. Для их поддержки Были разработаны  и инструментальные  средства  (Rational Rose, Rational Software, RUP, Demral , OОram и др.). Инструменты  рассматриваются в теме 10.

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

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

Методы просмотра структуры программы

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

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

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

 

Метод простого структурного анализа. Он ориентирован на   анализ структуры  программы  и потоков данных и базируется на использовании теория графов для представления структуры программы в виде  графа,  каждая вершина которого – это    оператор,  а дуга – передача  управления между операторами. Согласно графу  определяется достижимость вершин программы и   выход  потоков управления для ее  завершения и  обнаружение логических ошибок [5,12].

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

 

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

 

Метод проверки непротиворечивости.

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

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

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

Рассмотрим эти  виды  задач.

1). Символическое выполнение программа Р (Х, Y) на некоторых наборах данных    D = (d1, d2, ..., dn ),  D Ì Х,   Х – множество входных данных программы Р.

Пронумеруем операторы программы Р. Состояние выполнения программы – это тройка         



               < N, pc, Z

>,

где   N – номер  текущего оператора программы Р,    pc

(part condition) – условие выбора пути в  программе (вначале это true), что  является   логическим выражением  над D;         Z

– множество пар { < zi, ei >| zi Π X  Ç Y, в которых zi – переменная  программы, а  ei – ее значение;  Y – множество  промежуточных и выходных данных.

        

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

 

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

В операторе  присваивания Z = e ( x,  y),   x  Î X, y Î Y, в выражение  e ( x,  y)  производится  подстановка  символьных значений  переменных x и y, в результате чего  получается выражение  e (D), которое становится значением  переменной z (z Î Х ÈУ).  Вхождение в полученное  выражение  e (D) переменных из   Y  означает,  что их значения, а также  значение z не определены.

По оператору перехода  управление  передается  оператору, помеченному  соответствующей меткой.  В условном  операторе  « если a (x, y)  то  В1 иначе В2 » вычисляется выражение  a (x, y). Если оно определено и равно a¢ (D), то формируются  логические формулы:

                рс  ® a’ (D )                                                                                                         ( 1)

                рс  ® Ø a’ (D)                                                                                                      ( 2)

Если рс – ложно (false), то только  одна из последних формул  может быть выполнимой, тогда :

– если выполнима формула (1) , то управление передается  на В1;

– если выполнима  формула   (2),  то управление  передается  на В2;



– если (1), (2) не выполнимы  (то есть из   рс  не следует  ни  a’ (D), ни Øa’ (D)), тогда  по крайней мере  один набор данных, который  удовлетворяет рс  и cоответствует части  «то» условного оператора, а также  есть набор данных, соответствующий иначе    этого условного оператора.

 

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

                     рс1 = рс Ù  a’ (D )

                     рс2 = рс Ù  Ø a’ (D )

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

– для заданного пути формируется рс согласно  семантики операторов,  для условного оператора семантику трактуем как  преобразование рс вида (1) или (2);

–  решаем обе системы уравнений (1) и (2).

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

2). Определение пути  при заданных ограничениях на входные данные  проводится  таким шагами:

– полагаем рс = b ( D),  где   b ( D) – входная спецификация, когда ее нет,  то   рс = true;

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

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

–  для всех промежуточных d (х,у) с выходной спецификацией g (х,у)

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

                 рс ® d (х,у)    и     рс ® g (х,у),

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

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


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

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

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

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

Методы систематического программирования

К  методам систематического программирования отнесены  следующие методы:

– структурный,

– объектно–ориентированный,

– моделирование в UML,

– компонентный,

– аспектно–ориентированный,

– генерирующий,

– агентный  и др.

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

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

Методы теоретического программирования

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

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

К настоящему времени разработаны теоретические методы с участием украинских ученых для теоретического представления ключевых проблем программирования – алгебраическое программирование  (Летичевский А.А. и др.) [31–34]; 

Экспликативное  программирование (Редько В.Н.) определяет теорию дескриптивных и декларативных программных формализмов для адекватного задания моделей структур данных, программ и средств их  конструирования. Создана  программология – наука о  программах, которая объединяет идеи логики, конструктивной  математики и информатики и на  единой концептуальной основе предоставляет общий формальный аппарат  конструирования программ [35–39].  

Алгебра алгоритмики (Цейтлин Г.Е.) обеспечивает построение алгоритмов в виде схем, задаваемых графами, элементами которых являются конструкции, производные от структурных конструкций.  К операциям алгебры относится суперпозиция, свертка, развертка, а также операции над множествами [40–42].           

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

 

Методы тестирования программ

Тестирование – это способ семантической отладки (проверки) программы, заключающийся  в обработке  последовательности различных контрольных наборов тестов, для которых известен результат. Тестирование основывается на выполнении программы и получении результатов выполнения  тестов  [1–7, 21, 22]. 

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

Исторически первой разновидностью тестирования была отладка.

 Отладка

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

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

Методы управление рисками

Причиной возникновения рисков являются неопределенности, существующие в каждом проекте. Риски могут быть “известные”, которые определены, оценены и  которые можно планировать. Риски “неизвестные”, которые не идентифицированы и не могут быть спрогнозированы [9–12].

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

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

Американский Институт управления проектами (PMI) разрабатал стандарты в области управления проектами и в последнее время  переработал разделы, регламентирующие процедуры управления рисками. В новой версии PMBOK шесть процедур управления рисками:

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

2.                  Идентификация рисков – определение рисков, способных повлиять на проект, и документирование их характеристик.

3.                  Качественная оценка рисков – качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.

4.                  Количественная оценка – количественный анализ вероятности возникновения и влияния последствий рисков на проект.

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

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

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

Методы управления проектами

Согласно мировой статистики, не все реализуемые программные проекты завершаются успешно, 33% из них являются провальными по следующим причинам:

–        требования заказчика не выполняются ,

–        проект не вложился в стоимость,

–        проект не вложился в заданные сроки,

–        этапы работ оказались нескординированными друг с другом,

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

 Основные положения  управления проектом, задачи  и методы которого отрабатывались на технических проектах (например, первый проект  разработки лайнера  для перевозки пассажиров из Европы в Америку), привели к тому, что  Генри Гант впервые предложил диаграммную схему учета времени выполнения проекта. На сегодня  эти задачи  сформулированы  следующим образом:

–        планирование проекта и составление графиков работ выполнения проекта,

–        управление  проектными работами и командой исполнителей,

–        управление  рисками,

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

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

Основными составляющими любого проекта являются следующие: ресурсы  (людские, финансовые  и технические)  время и стоимость

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

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

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

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

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

–        элементной базы и языков программирования.

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

Накопленный опыт в создании технических проектов был систематизирован (в институте управления проектами  в США) и  разработано   ядро знаний – РMBOK (Project Management Body of Knowledge  [2]. В нем малыми проектами считаются проекты, содержащие  100 работ и 15 исполнителей, средними – 500 работ и 50 исполнителей и большими  – 1000 работ и 100 исполнителей.

В ядре РМВОК определены основные аспекты разработки проектов:

–        методы управления, планирования и контроля работ;

–        эффективная  организация проектной группы (команды);

–        инструментарий менеджера проекта (например, система Project Management  фирмы Microsoft ).

МЕТОДЫ УПРАВЛЕНИЯ ПРОЕКТОМ, РИСКОМ И КОНФИГУРАЦИЕЙ

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

Материал данной темы  состоит из трех разделов:

1. Методы управления программным проектом.

2. Методы обнаружения и устранения рисков в проекте.

3.Управление конфигурацией системы.

 

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

Сложилось несколько методов, эффективно применяемых в практике реализации программных проектов. Рассмотрим их.

 

МЕТОДЫ ВЕРИФИКАЦИИ И ТЕСТИРОВАНИЯ ПРОГРАММ И СИСТЕМ

         

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

Теоретические средства определяют процесс программирования  и тестирования программного продукта. Это  методы верификации и доказательства правильности составленной спецификации программ, метрики  (Холстеда, цикломатичная сложность Маккейба и др.) измерения отдельных характеристик, и выступают они в роли формализованных элементов теории определения   правильности и гарантии свойств конечного ПО. Например, концепция «чистая комната» базируется на некоторых формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования, то это проверка спецификации нотаций программ, используемых при описании тестов и покрытия соответствующих критериев программ [1–7].

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

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

1. Формальное доказательство

корректности программ осуществляется с помощью теоретических методов, основанные на задании формальных  систем правил и утверждений, используемых при доказательстве правильности операторов программы и результатов их выполнения в режиме интерпретации [5, 8–11]. К средствам формальной проверки правильности относятся верификация и валидация ПС, которые  вошли в состав регламентированных процессов ЖЦ стандарта ISO/IEC 12207.    

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

3. Организационные аспекты  проверки правильности.

Далее  излагаются  последовательно эти  направления.

Методы верификации объектно–ориентированных программ

 

Верификация  таких программ имеет свою специфику и ее можно рассматривать исходя из композиционного метода, применяя к ним известные методы доказательства  правильности композиционных программ [14, 16, 17].

Выделим несколько этапов для верификации исходного проектирования объектных моделей и программ:

1. Верификация базовых (простых) объектов сводится к верификации структуры, где атрибуты объектов являются данными структуры, а внутренние операции объекта — функциями над этими данными.

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

– базовые объекты считаются проверенными, если  их операции (функции) приняты за теоремы;

– доказательство  объектов сводится  к этим теоремам;

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

3. Верификация интерфейсов объектов сводится к доказательству:

 – правильности данного интерфейса;

–   достаточности параметров интерфейса.

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

– удаление лишних атрибутов объектов и их интерфейсов в ОМ, внесение необходимых изменений и повторное доказательство правильности объекта;

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

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

                   

       

Методы внесения изменений в компоненты и в ПС

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

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

Типичными причинами внесения изменений являются:

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

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

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

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

 

К видам сопровождения относятся:

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

–        адаптация продукта к измененным условиям (аппаратуре нового типа) использования системы после ее передачи в эксплуатацию;

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

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

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

В общем,  процесс  изменения ПС проводятся путем:

– анализа исходного кода для  внесения в него изменений;

– настройки  компонентов и  системы на новые  платформы;

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

– изменения функций  системы или добавления новых; 

– расширения возможностей (сервиса, мобильности и др.) компонентов;

– преобразования структуры  системы или  отдельных ее компонентов.

Сущность всех видов изменений  в  один компонент и совокупности компонентов  ПС  направлена   на  придание старой ПС  нового  назначения и определения условий применения.

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

Процесс обновления компонента включает в себя [14–20]:

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

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

–  реверсная инженерия, цель которой – перестройки  или полная переделки компонентов, а иногда и перепрограммирование системы в новый ЯП.

Метрики качества программного обеспечения

В настоящее время  в программной инженерии еще не сформировалась окончательно система метрик. Действуют разные подходы и методы определения их  набора и методов измерения [6–8, 14, 15].

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

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

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

Остановимся на классификации метрик ПО, правилах для проведения  метрического анализа  и процесса их измерения.

Типы метрик.  Существует три типа метрик:

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

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

– метрики использования.

Метрики программного продукта включают:

– внешние метрики, обозначающие   свойства  продукта, видимые пользователю;

– внутренние метрики, обозначающие  свойства, видимые  только команде разработчиков.

         

 Внешние  метрики  продукта включают такие метрики:

–  надежности   продукта, которые  служат для определения   числа дефектов;

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

– сопровождения, с помощью которых   измеряются   ресурсы   продукта (скорость, память, среда);

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

– общее число операций, повторно используемых и новых операций;

– число классов, наследующих специфические операции;

– число классов,  от  которых зависит данный класс;

– число пользователей класса или операций и др.

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

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

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

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

Метрики процессов включают метрики:

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

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

– ненадежности  процесса – число не обнаруженных дефектов при проектировании;

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

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

– общее время разработки и отдельно время для каждой стадии;

– время модификации моделей;

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

– число найденных ошибок при инспектировании;

– стоимость проверки качества;

– стоимость процесса разработки. 

 

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

 

Модель анализа требований Определение объектов

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

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

–   изменение требований неизбежно;

– объект модифицируется  вследствие изменения соответствующих требований к системе;

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

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

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

– определение поведения системы;

– презентация системы (ее интерфейсов с  пользователями и другими системами).

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

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

Рассматривается три типа объектов:

– объекты-сущности;

– объекты интерфейса;

–   управляющие объекты.

 

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

 Модель формального доказательства конкретности программы

Сущность формального доказательства заключается в преобразовании кода программы к  логической структуре [3, 6]  Составляется  описание  утверждений, которые задают вход–выход программ с помощью логических операторов, а также  комбинациями  логических переменных (true/false), логическими операциями (конъюнкция, дизъюнкция и др.)  и кванторами всеобщности и существования  (табл.7.1.).

                                                                                                                           Таблица 7.1       

                                  Логические операции                                            

       –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

            Название                         Примеры                        Значение

       ––––––––––––––––––––––––––––– ––––––––––––––––––––––––––––––––––––––––––

Конъюнкция                         x & y                           x  и  y

Дизъюнкция                          x * y                            x  или y 

Отрицание                             Øx                               не    x

Импликация                           x  ® y                        если

х то у

Эквивалентность                   х = у                           х

равнозначно у

Квантор всеобщности          " х Р(х)                      для всех  х, условие истинно

Квантор существования       $ х Р(х)                      существует х, для которого  

                                                                                         Р(х) истина

                        

     

1.  Для примера метода доказательства  предлагается к рассмотрению задача сортировки  одномерного массива  целых чисел Т длины N (Т [1:N]) для получения   из него эквивалентного массива Т’

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

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

Аbeg:  (Т [1:N] – массив целых )  & ( Т' [1:N] массив целых ).       

Выходное  утверждение Аend запишем  как конъюнкции таких условий:

(а)       (Т– массив целых ) & (Т' – массив целых )

(б)      ( " i если  i £ N то   $ j (T'( i ) £ T' ( j )))

(в)      ( " i если   i < N

то (T' ( i ) £ T' ( i+1) ),

то есть Аend – это  (Т – массив целых ) & (Т'

– массив целых ) &   " i если  i £ N то  $ j (T'( i ) £ T' ( j ))  &   " i если  i < N то (T' ( i ) £  T' ( i+1) ).

 

Для расположения элементов массива Т в порядке возрастания их величин в массиве Т’ в используется алгоритм пузырьковой сортировки, суть которого заключается  в предварительном копировании массив Т  в массив Т', а затем проводится сортировка элементов согласно условия их возрастания.    Алгоритм сортировки представлен на блок–схеме (рис.7.1).

Операторы алгоритма размещены в прямоугольниках. Условия, с помощью которых происходит выбор альтернативных путей в алгоритме, представлен в параллелограммах.  Кружками отмечены точки с начальным Abeg  конечным условиями Aend  и состояниями алгоритма: кружок с нулем обозначает начальное состояние, кружок с одной звездочкой – состояние после обмена местами двух соседних элементов в массиве Т', кружок с двумя звездочками обозначает состояние после обмена местами всех пар за один проход  массива Т'.

 Кроме уже известных переменных Т, T' и N, в алгоритме использованы еще два переменные: i – типа целая и М – булева, значением которой являются  логические константы true и false.

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

Так  оператор присваивания означает, что  для всех i  (i £ N  & i>0 ) выполняется  (T' [i] : = T [i]).  Результат выполнения алгоритма  в точке с нулем может быть выражен утверждением:



 

(T[1: N] – массив целых)   &  (T '[1: N] – массив целых)

 & ("i  если  i £ N  (T [ i] = T [ i] )).

Доказательство очевидно, поскольку за семантикой оператора присваивания, обеспечивающая поэлементную  пересылку чисел из Т в T’ , сами элементы при этом не изменяются и порядок их в Т і T'  одинаковый. Получили, что условие  (б) исходного утверждения выполнено. Первая строка доказанного утверждения совпадает с условием (а) исходного утверждения Аend  и остается справедливой до  конца работы алгоритма. В точке  алгоритма с одной звездочкой выполняется  оператор

(i < N) (T'( i)) > T' (i + 1) ® (T' ( i)  и   T' (i + 1)    для  изменения  местами элементов. 

В результате работы оператора будет справедливым такое утверждение:

$ i  если i < N  то  (T'(i) < T'(i +1),  которое  является   частью  условия   (в)  утверждения Аend

(для одной конкретной пары  смежных элементов массива T').

Очевидно, что семантика оператора обмена местами не нарушает условия (б) выходного утверждения Аend.

 

                                                                  

                                 Abeg                                           T = T’                                        0                         

                                                                                  M =true



                                                                                                 i = 0



                                                                                                  M=true                                 Aend                                        

                               

                                                                                         Ø M = true

                                                        ні    

                                                                                      i = i + 1



                                                                

                                                                                                   i < N

                                                               

                      **

                                                                 ні                       T’(i)>T’(i+1)  

                                                               



                                                                                    Изменить

                                                                               T( и) на  T(и+1)

                                               

                                                                                                                                          *                                                                                               



                                                                                        M = true



                     Рис.7.1.   Схема сортировки   элементов массива Т'

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

 В этой точке также справедливое утверждение:

$ i , если   i < N  то T' ( i) < T' ( i + 1).

Часть алгоритма, обозначенная точкой с двумя звездочками выполняется до тех пор, пока не будет упорядочен весь массив, то есть не будет выполняться условие (в) утверждения Аеnd для всех элементов массива T':

"i,  если   i < N  то T' (i) <  T' (i+ 1).



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

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

Другими словами, если первое утверждение – А1  и первая точка преобразования  – А2 , то  первой теоремой есть:  А1   ® А2..

Если А3 есть такой точкой преобразования, то  второй теоремой будет: А2 ® А3.

Таким образом, формулируется  общая теорема:

 Аі  ® Аj,где  Аі  и  Аj    – смежные точки преобразования.

          

Последняя теорема формулируется так, что  условие «истинное» в последней точке и отвечает истинности выходного утверждения:     Аk  ®  Аend.

Соответственно, можно возвратиться потом  к точке преобразования Аend    и к

предшествующей точке преобразования.  Доказали, что      Аk  ® Аend , а значит и  Аj ® Аj +1  и так далее, пока не получим, что   А1   ® А0

. 

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

 

4. Чтобы доказать, что программа корректная, необходимо последовательно расположить все части, которые начинаются с А1 и заканчиваются Аend. Последовательность этих частей определяет, что истинность входного условия обеспечивает  истинность выходного условия.       

 

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

Модель качества ПО

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

Качество ПО   характеризуется  тремя главными аспектами:   качество программного продукта, качество процессов ЖЦ и качество сопровождения или внедрения (рис. 9.1).

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

                                                                                                                           

        Качество процесса                 Качество продукта           Качество сопровождения

    

              Процессы                            Программный                         Эффект от

                ЖЦ                                             продукт                             внедрения

                                                                                                                  ПО

     

                                             Рис. 9.1  Основные аспекты качества ПО

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

Модель качества ПО имеет следующие четыре уровня детализации.

Первый уровень  соответствует определению характеристик (показателей) качества для ПО, каждая из них отражает отдельную  точку  зрения  пользователя  на  качество. Согласно стандартов [1–4] определено шесть характеристик  или шесть  показателей качества в стандартной   модели качества:

1.      функциональность (functionality),

2.      надежность (realibility),

3.      удобство (usability),

4.       эффективность (efficiency),

5.       сопровождаемость (maitainnability),

6.      переносимость (portability).

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

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

 

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

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

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



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

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

К атрибутам функциональности относятся:

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

– правильность (точность) – атрибут,  который  показывают степень достижения правильных результатов;

– интероперабельность – атрибут, который показывают  на возможность           взаимодействовать  ПО со специальными системами и средами (ОС, сеть);

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

2). Надежность – совокупность   атрибутов, которые  определяют способность ПО преобразовывать  исходные данные в результаты при  условиях, зависящих  от периода  времени жизни (износ  и  его старение не  учитывается).  Снижение надежности ПО происходит  из–за ошибок в требованиях, проектировании и выполнении. Отказы и ошибки в    программах появляются на    заданном   промежутке   времени [8-13].

К подхарактеристикам надежности ПО относятся:

– безотказность – атрибут, который  определяет функционирование системы без   отказов (программы или оборудования);

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

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

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



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

                                  Показатели  – характеристики                              Атрибуты

                                     

                                                                                                                Полнота функций

      

                                                                                                                   Точность



                                         Функциональность                                        Интероперабельность



                                                                                                                   Защищенность

                                                                                            

                                                                                                                  Согласованность

                                                                                                                  



                                                                                                                      Безотказность



                                               Надежность                                               Отказоустойчивость



                                                                                                                 Восстанавливаемость



                                                                                                                    Согласованность    

                                                                                              

                                                                                                                    Понимаемость



                                                                                                                                                          

                                                                                                                    Обучаемость

                                             Удобство                                                       

                                            применения                                                  Привлекательность

          Модель

         качества                                                                         

                                                                                                                 Согласованность

         програм-

           много                                                                                              Анализуруемость

         обеспече-

            ния                                                                                                  Изменяемость                                   



                                          Сопровождаемость                                         Стабильность

                                      

                                                                                                                   Тестируемость

   

                                                                                                                  

                                                                                                                   Согласованность

                                                                                                                 Реактивность                        



                                         Рациональность                                           Эффективность  ресурсов                                      

                                                                                                                  



                                                                                                                 Согласованность

                                                                                                                  

                                                                                                                                                                                                                                               

                                                                                                                 Адаптируемость  

                                                                                                                                                                                                                                 

                                         Переносимость                                              Простота установки

                                      

                                                                                                                   Сосуществование

   

                                                                                                                  Заменяемость

                                                                                                                    

                                                                                               Согласованность

                            Рис. 9.2. Модель характеристик качества

К факторам, влияющим на   надежность ПО, относятся:

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

– угроза как  проявление нарушения безопасности системы;

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

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



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

Подхарактеристиками  удобства применения являются:

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

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

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

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

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

К подхарактеристикам эффективности ПО относятся:

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

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

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

5). Сопровождаемость

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



Cопровождаемость включает подхарактеристики:

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

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

– стабильность – атрибут,  указывающие   на   риск   модификации;        

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

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

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

Переносимость включает  подхарактеристики:

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

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

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

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

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

Модель процессов

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

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

В качестве источников данных могут быть:

– атрибуты объектов,  которые  продолжают   существовать   после завершения работы системы;

– системные часы, как показатель  времени;

таймеры;

– данные событий;

– сообщения   внешних   объектов   (людей, операторов и т.п.).

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

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

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

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

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

–        данным,  имеющим своими источниками архивные объекты, соответствуют потоки с названиями атрибутов объектов, которые передаются потоками (при этом название объекта может не указываться);

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

–        потоки данных от системных часов маркируются  показателями  времени  (час, минута,  и т.п.);

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

–        процесс,   породивший   событие  и  процесс от  приема сообщения о событии, относятся к одной  диаграмме действий потоков данных и  связывается потоком;

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

Различаются следующие типы процессов:

–        аксессор, осуществляющий  доступ к архивам;

–        генератор событий;

–        преобразователь данных (вычисления);

–        проверки условий.

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



            Рис. 4.3. Пример  диаграммы действий потоков данных

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



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

–        идентификатор процесса;

–        тип процесса;

–        название процесса;

–        название состояния, для которого определен процесс;

–        название действия состояния.

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

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

Результатами метода инженерии требований С.Шлаер и  С.Меллора   являются три  модели.

1. Информационная модель системы, состоящая из:

– диаграммы сущность – связь;

– описания объектов и их атрибутов (неформальное);

– описания связей между объектами (неформальное).

2. Модель поведения объектов системы, представленная  в виде:

– диаграммы переходов в состояния  диаграмм перехода состояний или таблицы перехода состояний;

–  неформальное описания действий диаграммами перехода состояний;

–  неформальное описания событий диаграммами перехода состояний.

3. Модель процессов состояний объектов, представленная в  виде:

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

– таблицы процессов состояний;

– неформальное описание процессов.

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

 

Модель состояний

 

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

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

– состояние объекта изменяется в результате  произошедших действий или стимулов;

– состояние домена, которое определяется совокупностью состояний его объектов;

– изменение состояния объекта сопровождается некоторыми процессами, которые определены для каждого состояния.

Для фиксации  динамических  аспектов  требований   как отражения поведения объектов в рассматриваемом  методе предложены  две альтернативные нотации: графическая, которая   называется диаграммой  переходов  состояний (ДПС) и табличная, которая  называется  таблицей переходов состояний (ТПС).

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

Для каждого из выделенных  объектов определяются:

1) множество состояний, в которых объект может находиться;

2) множество инцидентов или событий, которые побуждают экземпляры класса изменять свое состояние;

3) правила перехода для каждого из зафиксированных состояний, как указание на новое состояние экземпляра данного класса, если произойдет некоторое событие из множества событий тогда, когда объект находится в данном состоянии;

4) действия или процессы для каждого из определенных состояний, которые  выполняются  при   переходе   в   данное состояние.

Для представления  этой информации в нотации диаграммы перехода состояний предусматривается следующее:

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

– состояние  обозначается  рамкой, содержащей номер и название состояния;

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

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

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

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

Для изменения состояния экземпляра класса объектов выполняются действия:

–        обработка  информации,  переданной  в  сообщении  о событии;

–        изменение определенного атрибута  объекта;

–        вычисления;

–        генерация операции для некоторого экземпляра класса;

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

–        передача сообщения о событии от внешних объектов;

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

Атрибутами таймера являются:

–        уникальный идентификатор экземпляра таймера;

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

–        метка наступающего события, при условии, что  остаток времени  равен нулю;



–        идентификатор экземпляра объекта, для которого устанавливается  таймер.                   

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

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

 

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

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

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

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



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

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



                         Рис. 4.2. Схема взаимодействия моделей поведения объектов         

МОДЕЛИ КАЧЕСТВА И НАДЕЖНОСТИ В ПРОГРАММНОЙ ИНЖЕНЕРИИ

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

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

Качество ПО было предметом стандартизации, создан стандарт ГОСТ 2844–94, в котором дано определение качества ПО,  как совокупность свойств (показателей качества) ПО, которые  обеспечивают его способность  удовлетворять потребности заказчика, в соответствии с   назначением. Этот стандарт регламентирует базовую модель качества и его показатели, главным среди них является надежность. Стандарт ISO/IEC 12207 определил не только основные процессы ЖЦ разработки ПС, но и организационные и дополнительные процессы, которые регламентирую инженерию, планирование и управление качеством ПС.

На этапах ЖЦ проводится анализ   качества ПО, ориентированные на:

– достижение  качества ПО  в соответствии с  требованиями и критериями;

– верификацию и аттестацию (валидацию) промежуточных результатов ПО на этапах ЖЦ и измерение  степени достижения отдельных его показателей;

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

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

 

Модели надежности Марковского и Пуассоновского типов

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

(n), т.е. вероятностью на n– шаге перейти из состояния i  в состояние j. Процесс называется  однородным, если он не зависит от n. 

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

К этой группе моделей относятся: Джелинського–Моранды [23],  Шика–Вулвертона [24],  Шантикумера [24] и др.

Ниже рассматриваются  некоторые модели   надежности, которые обеспечивают рост надежности ПО (называются моделями роста надежности [17]), находят широкое применение на этапе тестирования и описывают процесс обнаружения отказов при следующих основных предположениях:

– все ошибки в ПС не зависят друг от друга с точки зрения локализации отказов;

– интенсивность отказов пропорциональна текущему числу ошибок в ПС  (убывает при тестировании программного обеспечения);

– вероятность локализации отказов остается постоянной;

– локализованные ошибки  устраняются  до  того, как тестирование будет продолжено;

– при устранении ошибок новые ошибки не вносятся.

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

         m –  число обнаруженных отказов ПО за время тестирования;

        Хi

– интервалы времени между отказами i–1 и i, при i =1,..., m;

         Si  – моменты времени отказов (длительность тестирования до i– отказа),  Si

=   Xk при i = 1,..., m;

         T – продолжительность тестирования программного обеспечения (время, для которого определяется надежность);

        N – оценка числа ошибок в ПО в начале тестирования;

        M – оценка числа прогнозированных ошибок;

        MТ – оценка среднего времени до следующего отказа;

        E (Tp)

– оценка среднего времени до завершения тестирования;

        Var (Tp)

– оценка дисперсии;

        R ( t) – функция надежности ПО;

        Zi ( t) – функция риска в момент времени t между i–1  и i отказами;

        с – коэффициент пропорциональности;

        b – частота обнаружения ошибок.

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

 

Модель Джелински–Моранды. В этой модели используются исходные данные, приведенные выше, а также:

        m  – число обнаруженных отказов за время  тестирования,

        Xi  – интервалы времени между отказами,

        Т  –  продолжительность тестирования.

Функция  риска  Zi

(t)  в момент времени t  расположена между  i–1 и i  имеет вид:

        Zi (t)  = c (N – n i–1) , 

где  i = 1 ,.., m;       Ti–1 < t < Ti  .

Эта функция  считается ступенчатой кусочно–постоянной функцией с постоянным коэффициентом пропорциональности  и величиной ступени – с.      

Оценка параметров  c и N производится с помощью   системы уравнений:

                       m                                       m

                      S  1 / (N – ni–1) – S  c  Xi   = 0

                      i =1                               i =1

                                                            m

                   n/c –  NT –  S  Xi  ni–1 =  0

                                                     i =1                                                                                                                                                                                     

                                                                                                                                                                              m



При этом суммарное время тестирования  вычисляется так:    Т   =  S  Хi

                                                                                                                            i =1

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

включают:

– число оставшихся ошибок Mт

= N–m;

– среднее время до текущего отказа  MТт = 1/( N–m) c;

– среднее время до завершения тестирования и его дисперсия    

                                                       N–n                          

                       E (Tp) =  S  (1/ ic) ,        

                                     i =1                          

                                                                 N–n

                        Var (Tp) =   S  1/( ic) 2 

                                           i

=1                               

 При этом функция надежности  вычисляется по формуле:

                       Rт ( t) = exp (– (N– m) ct),

при  t>0 и числе ошибок, найденных и исправленных на каждом интервале тестирования,  равным единице.

 

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

         m  – число обнаруженных отказов за время  тестирования,

         Xi  – интервалы времени между отказами,

         Т  –  продолжительность тестирования.

         Функции риска Zi (t) в момент времени между  i–1 и i–m   отказами  определяются следующим образом:

          Zi ( t) = c (N – n i –1),  где    i = 1 ,..., m;   Ti–1 < t < Ti  ,

                                 m

                  Т =  S  Хi  .

                                      i =1

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

Оценка c и N  вычисляется  из системы уравнений:



                           m                                m

                           S 1/(N – ni–1) – S    Xi 2 /2 = 0

                           i =1                           i =1

                                      m

                          n/c  –  S  (N – ni–1 ) Xi 2 / 2  = 0

                                                      i =1                                                                                                                                                                                      

К выходным показателям надежности относительно продолжительности T относятся:

 –  число оставшихся ошибок Mт = N–m;

– среднее время до следующего отказа  MTт = (p / (2 ( N–m) c) ) 1/2 ;

– среднее время до завершения тестирования и его дисперсия

                                       N–m

                         E (Tp) = S   (p / (2 i c)) 1/2  ,

                                                         i=1

                                         N–m

                       Var (Tp) =  S   ( (2– p  /2) /  i c );

                                          i=1

Функция надежности вычисляется по формуле:

                        R Т

( t) = exp (–(N–m) ct2 /2) , t ³ 0.

Модель Пуассоновского типа базируется на выявлении отказов и моделируется неоднородным процессом, который задает  {M(t), t³0} – неоднородный пуассоновский процесс с функцией интенсивности l(t), что соответствует  общему количеству отказов ПС за время его использования t.                         

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

Исходные данные этой  модели:



          m  – число обнаруженных отказов за время  тестирования,

          Xi  – интервалы времени между отказами,

          Т  –  продолжительность тестирования.

Функция  среднего  числа отказов,  обнаруженных к моменту t имеет вид:

           m ( t) = N (1 – e –bt ) ,

где  b – интенсивность обнаружения отказов и показатель роста надежности q ( t) = b.

Функция интенсивности  l ( t)  в зависимости от  времени работы до отказа  равна

          l ( t) = Nb –bt ,     t ³ 0.

Оценка b и N  получаются из решения уравнений:

            m/N –1 + exp (–bT) = 0

                                   m

            m/b – S ti – Nm exp (–bT) =0

                         i=1

Выходные  показатели надежности относительно времени T  определяют:

1)  среднее число ошибок, которые  были обнаружены  в интервале [ 0, T]

               E (NT

) = N exp (–bT) ,

2)  функцию надежности  

            RT ( t) = exp (–N (e –bt  – e –bt (t+т) )) ,     t ³ 0.

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

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

– вероятность безотказной работы;

– среднее время до следующего отказа;

– число необнаруженных отказов (ошибок);

– среднее время для дополнительного тестирования программы.

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

           P = 1 – Neх /N ,

где      Neх – число ошибочных экспериментов,   N   – число  проведенных экспериментов для  проверки работы ПС.

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

Модели оценки надежности

Из всех областей программной инженерии  надежность ПС является  самой исследованной  областью. Ей предшествовала  разработка теории надежности технических средств, оказавшая влияние на развитие надежности ПС. Вопросами надежности ПС занимались разработчики ПС, пытаясь разными системными средствами обеспечить надежность, удовлетворяющую заказчика, а также  теоретики, которые, изучая природу функционирования ПС,  создали  математические модели надежности, учитывающие разные аспекты работы ПС (возникновение ошибок, сбоев, отказов и др.)  и оценить реальную надежность. В результате  надежность ПС  сформировалась  как самостоятельная теоретическая и прикладная наука [9–13, 17-25].

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

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

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

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

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

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

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

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

К факторам гарантии надежности относятся:

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

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

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

– целостность – способность системы сохранять  устойчивость  работы и не иметь риска;

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

МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ДЛЯ РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ

За десятилетия опыта построения программных систем был наработан ряд типичных схем последовательности выполнения работ при проектировании и разработки ПС. Такие схемы получили название моделей ЖЦ.

 

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

Исторически в эту схему работ включают:

– разработку требований или технического задания,

– разработку системы  или технического проекта,

– программирование или рабочее проектирование,

– пробную эксплуатацию,

– сопровождение и улучшение,

– снятие с эксплуатации.

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

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

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

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

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

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

 

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

Важную роль при формировании модели ЖЦ имеют организационные аспекты:

– планирование последовательности работ и сроков их исполнения,

– подбор и подготовка ресурсов (людских, программных и технических) для  выполнения работ,

– оценка возможностей реализации  проекта в заданные сроки и стоимость и др.

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

 

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

 

Мониторинг и контроль

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

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

Цель мониторинга и контроля состоит в  выяснении таких ситуаций:

–         реакция  на риски внедрена в соответствии с планом и необходимы изменения,

–        изменение рисков  по сравнению с предыдущими значениями,

–        определение влияния рисков и  принятие необходимых мер,

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

                                                                                           Проверка  списка

                                                                                           декомпозиция

                                                                                           анализ

                                                                                          функцияуправления анализом

                                                     Идентификация

                                                                                              динамика системы  

                           Оценка             анализ                               модели выполнения

                           риском                                                        модели стоимости

                                                      Приоритеты                     анализ среды

                                                                                               анализ решений

                                                                                               качество риска

Управление                                                                          воздействия на риск              

риском                                                                                 уменьшение риска

                                                

                                                                                                информация о купле

                                                      Снижение                         измерение риска

                                                                                                перемещение 

                                                                                                уровня снижения

                            контроль         Планирование                     

                            риском                                                        планирование элементов

                                                                                                планирование интеграции

                                                       Реакция                                 

                                                                                                 миграция риска      

                                                                                                 мониторинг риска      

                                                                                                 переоценка риска

                        Рис.10.7. Шаги по  управлению риском

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


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

Управление рисками основывается на рассмотрении  двух основных типа риска:  общий  риск для всех типов проектов и  специфический тип риска.

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

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

Систему управления риском можно   представить в виде отношения:

     Ущерб до минимизации - ущерб после минимизации

  

Цена минимизации риска.

Минимизацию риска можно получить прототипированием. Боэм [2] идентифицировал 10 наиболее часто возникающих причин риска в проекте:

1. Сокращение штата или набор неквалифицированных сотрудников.

2. Нереалистические в проекте планы и бюджеты.

3. Разработка функционально неправильных программных элементов.

4. Разработка неудачного пользовательского интерфейса.

5. Неудачная постановка требований.

6. Постоянное изменение требований.

7. Недостатки во внутренней организации работ.

8. Недостатки взаимосвязи с заказчиком.

9. Неумение работать в реальном времени.

10. Ограниченные компьютерные ресурсы.

      

Объектно-ориентированная инженерия требований

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

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

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

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

Объектно-ориентированный подход к разработке программных систем такого  недостатка не имеет. В нем общее видение решения проблемы формирования требований осуществляется исходя из  следующих  постулатов:

– мир составляют объекты, которые взаимодействуют между собой;

– каждому объекту присущ определенный состав свойств или атрибутов, который определяется  своим  именем  и  значениями;

– объекты могут вступать в отношения друг с другом;

–  значения атрибутов и отношения могут с течением времени изменяться;

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

–  совокупность состояний объектов определяет состояние мира объектов;

–  мир и его объекты могут находиться в разных состояниях и порождать некоторые события;

–  события  могут  быть  причиною  других  событий  или изменений состояний.

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

–        переходы из одного  состояния в другое под влиянием соответствующих событий;   

–        возбуждение определенных событий или посылка сообщений  другим объектам;

–  операции, которые  могут выполнять объекты;

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

–        обмен сообщениями.

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

– пользователь избавлен от необходимости знать лишнее;

–  то, что ему не сообщили, он не испортит (защита от намеренных или случайных неправомерных действий;

– все, о чем не знает пользователь, можно изменять.

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

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



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

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

В настоящее время предложен ряд современных методов объектно-ориентированного анализа требований, объектно-ориентированного проектирования программ, объектно-ориентированного программирования (С++, JAVA). Наибольшую ценность среди них имеет проблема  согласованности между ними.

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

Концептуальное моделирование проблемы системы происходит в терминах взаимодействия объектов:

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

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

– модель процессов определяет действия, которые выполняют объекты.

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

Объектно–ориентированные методы анализа и построения моделей ПрО

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

– метод OOAS, позволяющий выделить  объекты реального мира ПрО, определить  сущности, свойства и отношения объектов и из них построить  информационную модель, модель состояний объектов и процессов представления потоков данных (dataflow) [1];

– метод OOA позволяет  провести  анализ, определить требований к ПрО,    специфицировать  потоки данных в ПрО в виде диаграммной модели  [2];

– метод SD структурного проектирования структуры системы,  данных и   программы преобразования входных  данных в выходные с помощью структурных карт Джексона [3-5];

– методология OOAD позволяет построить  модели ПрО с помощью ER-моделирования,  понятий и их отношений с использованием структурных диаграмм,  диаграмм «сущность-связь»  и матрицы информационного управления [6, 7];

– объектное OMT моделирование объектной, динамической,  функциональной моделей и взаимодействия объектов  [8, 9];

– метод Г.Буча, включающий классы, суперклассы и операции наследования, полиморфизма и упрятывания информации об объектах, дополненный  вариантами использования Джекобсона для задания  сценариев работы системы и задач ПрО  и диаграммными средствами Румбаха,  в результате имеем UML-метод  для анализа ПрО и представления архитектуры системы с помощью набора  диаграмм  взаимодействующих объектов  [10, 11];

 

– метод построения объектной эталонной модели в CORBA и предоставления набора сервисных системных  компонентов  общего пользования для  обеспечения функционирования объектных компонентов  распределенных приложений  [12, 13];

– метод генерации частей систем из готовых компонентов (generative programming), объединивший в себе возможности  ООП,  компонентного и аспектного проектирования и развитый средствами многоразового использования отдельных членов семейства программ ПрО,  функциональные и нефункциональные требования представляются в   модели характеристик и  др. [12].     

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

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

                           

Объектно–ориентированный метод проектирования

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

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

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

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

1. Объектно–ориентированный анализ. Создание объектно–ориентированной модели предметной области приложения. Здесь объекты отражают реальные объекты–сущности и операции, выполняемые этими объектами.

2. Объектно–ориентированное проектирование. Разработка объектно–ориентированной модели системы ПО (системной архитектуры) с учётом требований. В этой модели определение всех объектов подчинено решению конкретной задачи.

3. Объектно–ориентированное программирование. Реализация архитектуры (модели) системы с помощью объектно–ориентированного языка программирования (С++, Java) для определения объектов и средств определения классов объектов.

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

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

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

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

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

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

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

Существует два типа   моделей системной архитектуры:

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

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

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

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

 

Общая характеристика формальных методов доказательства

 

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

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

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

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

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

 

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

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

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

 

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

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

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

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



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

В общем метод математической индукции разрешает доказать истинность некоторого предположения Р(n), в зависимости от  параметра n,  для всех n ³ n0, и тем самым   доказать случай Р (n0). Истинность Р(n) для любого значения n, доказывает  Р(n+1) и тем самым доказательство истинности Р(n) для всех n ³ n0.  

Этот путь  доказательства используется  для  утверждения А относительно  программы, которая при своем выполнении достигает определенной точки. Проходя через эту точку n раз, можно получить справедливость утверждения А(n), если докажем:

1) что справедливо А(1)  при первом проходе через заданную точку,

2) если справедливо А(n) (при n–проходах через заданную точку), то справедливо и А (n+1) при прохождении через  заданную точку  n+1 раз.

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

 

Общесистемный подход к проектированию архитектуры системы

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

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

                                    Рис.4.4. Поуровневая  архитектура системы

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

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

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

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

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

На уровне архитектурного проектирования система рассматривается как композиция компонент третьего уровня, имеющая  доступ  до компонентов первого и второго уровней.

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

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

Распределенная схема обеспечивает  взаимодействие компонентов  системы,   расположенных на разных компьютерах через стандартные интерфейсы и механизмы вызова, выполняемые  промежуточными средами (COM/DCOM, CORBA, OLE, Java и др.):  RPC (Remote Procedure Calls), RMI (Remote Method  Invocation),  tuple spaces, aplets и др.

В трехуровневой архитектурной схеме типа клиент/сервер сервер или брокеры объектных запросов (ORB) предоставляют общесистемный сервис и различные ресурсы, а также управляют распределенными объектами (компонентами). Архитектура такой системы  может быть  многоуровневой, если объекты предоставляют услуги и сами пользуются услугами других объектов, расположенных на разных уровнях этой  схемы. Данная архитектурная схема отображает объектный стиль проектирования  ПО, стиль моделирования проблемы  с помощью UML и унифицированного процесса RUP [13, 14].

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

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


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

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

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

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

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

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


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

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

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

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

Основными рекомендациями для декомпозиции сложной системы на компоненты или модули являются:

–  четкое определение цели и возможность  проверки их  выполнимости;

–  обязательное определение  входные и выходные данных;

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

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


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

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

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

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

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

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

К способам объединения объектов в подсистему можно отнести:

– . сборка  объектов в подсистему, которые ничем не связаны между собой;

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

–        объединение по времени, т.е. сборка объектов в подсистему, которые активизируются в общий промежуток времени;

–  коммуникативное объединение, т.е.  собираются объекты, которые имеют общий источник данных;

– процедурное объединение, т.е. в подсистему собираются объекты, которые последовательно передают друг другу  управление;

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



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

 

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

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

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

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

 

Обучение специальности – программная инженерия

Инженерная деятельность в программировании близка по своей сущности  к определению  инженерной деятельности (например, приборостроение), определенной в   толковом словаре:

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

2) деятельность по созданию машин для предоставления полезных услуг.

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

В отличие от другой  науки, целью которой есть получение знаний, в инженерии знание  является   способом получения некоторой пользы. Ф.Брукс [7] считает, что  «ученый строит, чтобы научиться, инженер учится, чтобы строить».

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

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

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

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

Приведенные отличия требуют значительных усилий и доработок для превращения  программной инженерии в специальность. Мировая компьютерная общественность признала целесообразность и своевременность таких усилий. Подтверждением этого является совместное создание ядра SWEBOK,  разных программ обучения (Cirricula -2001-2005) [23, 24],  институтов и комитета международного профессионального объединения в области информатики.  Их главной целью является проведение работ по  преобразованию программной инженерии в специальность, которая имела бы зафиксированные  признаки для ее распознания и официального признания в мировом сообществе специалистов [25-28].

Практика специализации профессиональной деятельности, которая сложилась в цивилизованном мире,  позволяет считать профессию "зрелой", если для нее существуют:

– система начального обучения  специальности;

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

– квалификация  персонала организована в рамках профессии;

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

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

– этический кодекс специалистов;

– профессиональное  объединение.

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



Отметим, что указанные профессиональные организации в 1999г. приняли  этический  кодекс специалистов  по программной инженерии [13], разработали руководства для обучения программной инженерии, а также создали программу обучения Computing Curricula (СС) 2001 [24]. Кроме того, в США работает комитет по сертификации учебных заведений (Computing Accreditation Commission of the Accreditation Board for Engineering and Technology [29].

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

– компьютерные науки;

– управление проектом;

– электротехническая инженерия;

– математика;

– телекоммуникации и сети;

–  менеджмент;

–  когнитивные науки;

– другие инженерные дисциплины.

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

 

Оценивание проекта

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

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

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

Когда такой возможности нет, эксперты проводят  пессимистическую (x), оптимистическую,        и реальную. Разные методы приближенного  оценивания  по отношению  к реалистическим рассмотрены в [3]. Эксперт проводит опрос всех членов рабочей группы, и в дальнейшем проводит коррекцию каждой оценки, выводя на их основе наиболее правдоподобную.

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

 

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

Например, стоимость проекта определяется по формуле: E =   (a+bSc) m (X), где S - оценка размера системы, а, в, с – эмпирические константы, Х – вектор факторов стоимости размерностью n, m – регулирующий множитель, основанный на  затратных факторах. В [3] предлагается модель в виде  соотношения, полученного экспериментальным путем: E = 5.25S0.91.

Эта модель  применялась при  оценке проекта, в котором  программные системы  имели размер от 4000 до 467000 строк кода, написанных на 28 различных языках программирования высокого уровня для 66 компьютеров и на которые затрачено от 12 до 11758 человека-месяцев.

В [4] предлагается техника моделирования, использующихся в уравнении затрат  организации-разработчика:

E = 5.5+0.73S1.16.

В большинстве моделей оценка зависит от размера системы в строках кода. Модель  COCOMO Боєма [ ] собрала в себе три техники измерений  по  проекту. В первых  моделях применялись   показатели цены, учитывался персонал и свойства  проекта, продукта и среды. Модель включает оценку трех стадий ведения проекта. На первой стадии строится прототип для задач повышенного риска (интерфейс пользователя, ПО, система взаимодействия, реализации и др.)  и проводится оценка затрат (например, число таблиц в БД,  экраны и отчетные формы др.).

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

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

Базовой моделью оценки служит следующее уравнение: E=bSc m(X), где первичная оценка b Sc корректируется с помощью вектора стоимости m (X). Эта модель развивается с учетом  анализа объектов (число  старых и новых объектов). Параметр с в уравнении  изменяется от 0 до 1.0 для первой  стадии и от 1.01 до 1.26 для остальных.



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

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

2. Формирование временного плана выполнения  работ в точках проекта.

3. Определение структуру рабочей группы, периода,  видов работ   и  ресурсов.

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

5. Использование стандартов, процедур,  техник и инструментов ведения проекта.

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

7. Разработка плана управления данными и источниками информации.

8. Разработка плана тестирования, измерения и оценивания результатов работ.

9. Составления плана обучения пользователей системы.

10. Определения плана безопасности (конфиденциальность,  пароли  и др.)

11. Составление плана управления рисками.

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

13. Описание алгоритмов, инструментов, техники просмотра или инспекции кода,   языков ведения проекта, языков кодирования и тестирования.

Описание интерфейса объектов-компонентов в распределенной среде

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

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

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

В  функции интерфейсного модуля  клиента входят:

– подготовка внешних данных  клиента (параметров),

– набор вызовов  этих  процедур или обращение к сервису сервера, 

– обработка  разных ошибок,  возврат  данных  от сервера к клиенту.

Общие функции интерфейсного модуля сервера содержат:

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

– возврат результатов процедуры клиенту,  уничтожения  удаленной  процедуры и др.

Структура интерфейсного модуля не зависит от  ЯП взаимодействующих объектов и в целом одинакова для всех. Это связано со  стандартизированной его  структурой   и общим  языком спецификации интерфейса, синтаксис которого  представлен ниже  в форме  Бекуса–Наура:    

         <интерфейс объекта> ::= Object <имя_Объекта> :{<множество исходных интерфейсов>}; {<множество входных интерфейсов>} end

<множество входных интерфейсов> ::= <множество интерфейсов>

<множество выходных интерфейсов> ::= <множество интерфейсов>

<множество интерфейсов> ::= _ | <интерфейс>; <множество интерфейсов>;

<интерфейс> :: = Interface <имя_интерфейса>: {<множество функций>}      end
<множество функций> :: = _ | <функция>; <множество функций>;
<функция>:::= function  <имя_функции>: <множество параметров> еnd
<множество параметров> ::= <параметр> | <параметр>, <множество параметров>
<параметр> ::= <тип> (<вид параметра>)
<вид параметра> :: = in | out | inout
Тип описывается средствами  языков программирования (C++, Pascal и т.п.) и обеспечивает взаимодействие между процессами, а  в качестве <вида параметра> могут быть:
 in — входной параметр,
out — выходной параметр,
inout — совместный параметр.
Интерфейсные объекты  в распределенной среде являются посредниками между клиентом и сервером (stub для клиента и skeleton для сервера). Их описания  отображаются в те языки программирования, в  которых  описаны соответствующие им объекты или компоненты.
Описание интерфейса в IDL-языке начинается с ключевого слова interface, за которым следует: идентификатор интерфейсного посредника, описание типов параметров и операций вызова  объектов.
     Общая структура  описания  интерфейса имеет вид
interface A { ... }
interface B { ... }
interface C: B,A { ... }.
Параметрами  операций (op_dcl) в задании  интерфейсов могут быть такими:
– тип данных (type_dcl);
– константа (const_dcl);
– исключительная ситуация (except_dcl),возникающая в процессе выполнения  метода объекта;
– атрибуты параметров (attr_dcl).
Описание типов данных начинается ключевым словом  typedef,  за которым следует базовый или конструируемый тип и его идентификатор. В качестве константы может быть некоторое значение типа данного или выражение, составленное из констант. Типы  данных и констант могут быть:  integer, boolean, string, float, char и др.
Описание операций op_dcl включает в себя:
– наименование операции интерфейса;
– список параметров (от нуля и более);


– типы аргументов и результатов, если они имеются (иначе -  void);
– управляющий параметр и задание исключительной ситуации и др.
Атрибуты параметров могут начинаться служебными словами:
      in – при отсылке параметра от клиента к серверу;
out – при отправке параметров-результатов от сервера к клиенту;
inout – при передаче параметров в оба направления (от клиента к серверу и обратно).
Описание интерфейса может наследоваться другим объектом, тогда оно становится базовым. Пример описания  базового интерфейса приведен ниже:
 const long l=2
 interface A {
 void f (in float s [l]);  }
 interface B {
 const long l=3   }
 interface C: B, A { }.
Интерфейс С использует интерфейс В и А. Это означает, что интерфейс С наследует описание их типов данных, которые по отношению  к С становятся глобальными. Но при этом  синтаксис и семантика остаются неизменными. Из приведенного примера видно, что операция f в интерфейсе С наследуется из А.
Механизм наследования интерфейса подразумевает, что все имена сохраняются без их переопределения. Особенно это касается описания операций, которые должны иметь уникальные обозначения. Имена операций могут использоваться во время выполнения интерфейса с помощью skeleton при его динамическом вызове.
Общая структура описания модуля в языке IDL с интерфейсом  приведена ниже:
            Regust Operations
            module CORBA {
            interface Reguest {
            Status add-arg (
            in Identifier name,
            in Flags arg_flags
               );
            Status invoke (
            in Flags invoke_flags // invocation flags
               );
            Status send(
            Status get_respouse (
             out Flags response_flags // response flags
                     );
                  };
              };
Предложенный язык описания интерфейса объектов содержит средства общие с языком  описания интефейсов IDL.

Определение понятий и видов требований

Одна из проблем индустрии программного обеспечения — это отсутствие общепринятых определений терминов, которыми пользуются для описания: требований пользователя, требований к ПО, функциональных требований,  системных требований,  технологических требований, требований к продукту и бизнес-требований. В разных источниках  понятия требований определяются, исходя из разных условий и взглядов на то, что по ним создается. Назовем ряд  определений в проблематике требований [2,3].

Требования — это «нечто такое, что приводит к выбору дизайна системы".

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

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

Согласно международного глоссария по терминологии [6]  требования  включают описание:

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

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

3) документированное представление условий или возможностей проектирования системы.

Определение стратегии идентификации

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

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

– именование  составных элементов  частей и всей конфигурации  системы;

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

 – ведение версии системы  (или ее частей)  и документирование;

 – выбор элементов базиса  конфигурации и  его формальное  обозначение.

 

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

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

– конфигурации продукта и ее версий;

– контролируемых единиц конфигурации и их версий;

– всех составляющих конфигурационного базиса и их редакций.

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

Организация подготовки тестов

                                  

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

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

 

Создаются  тесты, проверяющие:

– полноту функций;

– согласованность интерфейсов;  

– корректность выполнения функций и правильность функционирования системы в заданных условиях;

– надежность выполнения системы;

– защиту  от сбоев аппаратуры и не выявленных ошибок и др.

Тестовые данные готовятся как  для проверки  отдельных  программных элементов, так и для групп  программ или комплексов на разных стадиях процесса разработки. На рис. 7.5 приведена классификация тестов проверки по  объектам тестирования на основных стадиях  разработки.

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

         Тестирование        Тестирование           Тестирование            Тестирование

         спецификаций          программ                  комплекса               при испытаниях

          Тесты проверки:                Тесты проверки:                Тесты проверки:                    Тесты проверки:

           – полноты и согласо–         – структуры програм–       –– структуры комплек–         – соответствия  тре–

              ванности функций;             мы;                                      са;                                         бованиям;

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

           интерфейсов                    образования данных;            нент;                                     рабочей версии;

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

                                                          мых функций                      памяти;                                  на оборудовании;

                                                                            – длительности испо–          – удобства интерфей–

                                                                                нения;                                 са пользователя;

                                                                             – полноты решения             – удобства модифика–

                                                                               задач комплекса            ции и сопровождения

                                      Рис.7.5   Классификация тестов проверки

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

 

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



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

Первый шаг этого процесса – интеграция элементов, которая  основывается на интеграционных тестах, создаваемых по спецификациям проекта. Рассмотрим  этот шаг более подробно  на примере схемы (рис. 7.4)  интеграции отдельных элементов.

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

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

Согласно приведенной  схеме,   вначале   тестируются  компоненты А, В, D     независимо друг от друга и каждая с отдельным тестом. После  их проверки  выполняется   следующий  шаг – проверка интерфейсов для последующей их интеграции, суть которой заключается в анализе выполнения  операторов  вызова                                А   à   E,    B à C,   D à G, на нижних уровнях  графа: компоненты – Е, С, G. При этом предполагается, что указанные вызываемые  компоненты так же должны быть  отлажены отдельно. Аналогично  проверяются все обращения  к компоненте F, являющейся связывающим звеном  с вышележащими элементами.



                              Тести –                          Тести–                            Тести–

                            рование                         рование                           рование

                                   А                                   В                                       D



                                  Тести–                          Тести–                          Тести–



                                рование                       рование                       рование

                                    А, Е                             В,  С                            D,  G



                                                                              F

                                                                  Тестирование

                                                            интеграции элементов

                                                                 A, B, C, D, E, G      

                             Рис.7.4.  Интеграционное тестирование  компонент

                         

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

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

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

Организация процесса тестирования

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

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

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

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

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

 

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

      

4. Документирование результатов тестирования в соответствии  с действующим стандартом ANSI/IEEE 829,  включает описание:

– задач,  назначение и  содержание ПС, а также описание  функций соответственно   требованиям заказчика;

– технологии разработки системы;

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

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

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

 

Организационные аспекты процесса тестирования

Под организацией проведения тестирования понимается::

– выделение объектов тестирования,

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

– подготовка тестов, их выполнение  и поиск разного рода ошибок и дтказов в компонентах и в системе в целом;

– служба проведения и управление процессом тестирования.

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

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

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

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

Классификация  ошибок. Международный стандарт ANSI/IEEE–729–83 разделяет все ошибки в разработке программ на следующие

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

Дефект

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

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

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

– ошибочная спецификация или пропущенное требование, т.е.  спецификация точно не отражает того, что предполагал пользователь;

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

– проект программы может содержать ошибки (например, база данных спроектирована  без защиты от несанкционированного доступа  пользователя, а требуется защита);

 – программа может быть неправильной, т.е. она  выполняет несвойственный алгоритм  или он сделан не полностью.

 

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

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

– непреднамеренное отклонение разработчиков от рабочих стандартов или планов реализации;

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



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

Рассмотрим  этапы тестирования, определенные в соотвествии с рекомендациями стандарта  ISO/IEC 12207,  и приведем типы ошибок, которые обнаруживаются на каждом из них. 

 

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

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

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

– некорректность спецификации  взаимодействия ПО со  средой функционирования или с пользователями;

– несоответствие требований заказчика к отдельным и общим свойствам ПО;

– некорректность описания функциональных характеристик;

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

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

–  определением интерфейса пользователя со средой;

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

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

– некорректным  заданием данных и их структур при описании отдельных компонентов и ПС в целом;

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

–  определением  условий возникновения возможных ошибок в программе;



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

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

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

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

–  нарушение стандартов кодирования (плохие комментарии, нерациональное выделение  модулей и компонент и др.);

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

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

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

 

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

Все ошибки, которые возникают в программах, принято  подразделять на  следующие классы  [12, 23]:

– логические  и  функциональные ошибки;

– ошибки вычислений и времени выполнения;

– ошибки ввода–вывода и манипулирования данными;

– ошибки интерфейсов;

– ошибки объема данных  и др.



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

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

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

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

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

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

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



На современном этапе развития средств поддержки разработки ПО (CASE–технологии, объектно–ориентированные методы и средства  проектирования моделей и программ)   проводится такое проектирование, при котором ПО  защищается от  наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.

                              

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

– идентификация изъянов в технологиях  проектирования и программирования;

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

– классификация отказов,  изъянов и возможных ошибок, а также дефектов  на  каждом  этапе разработки;

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

–  проверка   и  защита от ошибок на всех этапах ЖЦ, а также  обнаружение дефектов на каждом этапе разработки;

– сопоставление дефектов и отказов в ПО  для  разработки системы   взаимосвязей и методики локализации, сбора и анализа информации об  отказах и дефектах;

– разработка подходов к документированию процессов  и испытания ПО.

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

Приведем   следующую классификацию типов отказов:

– аппаратный, при котором общесистемное ПО не работоспособно;

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

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



– программный при наличии ошибок в компонентах и др.

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

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

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

                                                                   

                       Анализ                                               некорректное, пропущенное или неясное  требование

                     требований

                                                                                   некорректный или непонятная  трансляция

                                                                                



                    Проектирование                                   некорректная или неясная спецификация проекта                    

                       системы

                                                                                                         

                                                                                    некорректная или неясная спецификация проекта

                   Проектирование

                     программ                                             ошибочная интерпретация проекта системы





                                                                                    некорректная документация                                                                            

                      Выполнение                                        ошибочная интерпретация проекта системы

                         программ                                    

                                                                                   некорректный сиснтаксис или семантика

                                                                                   неполные тесты процедур (или с дефектами)

                       Интеграционное

                        тестирование                                     новые ошибки в проверенных элементах



                      Системное

                     тестирование

                                                                                    некорректные тесты процедур или компонент



                                                                                      некорректная   пользовательская документация

                    Сопровождение                                       слабо отражен человеческий фактор

                                                                                      новые ошибки в старых правильных объектах

                                                                                      измененные требования

 

                         Рис. 7.2. Виды ошибок на этапах ЖЦ

   

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

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


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

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

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

 

Фирма IВМ

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

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

         Ортогональная классификация дефектов IBM                             Таблица 7.1

 

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

<


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

 

Фирма Hewlett–Packard использовала классификацию Буча, установив процентное соотношение ошибок, обнаруживаемых  в ПО на разных стадиях разработки  (рис. 7.3) [14].                                                                        в  управлении данными

                                       в коде

                                                        11%    6%   

                                                                                          в документации   

            в вычислениях                                        19%

                                              18%

                                                                                               

                                                                                    5%       в требованиях

                                                                                   4%       

                     в логике                   32 %              5%         в  аппаратуре

                                                                                      в интеграции

                                                                                       

                 Рис.7.3  Процентное соотношение ошибок при разработке ПО

Организационные аспекты управления в проекте

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

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

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

–        способностью выполнять работу;

–        интересом к работе;

–        опытом работы с подобным проектом, инструментами, языками,  технологиями и ОС;

–        способностью к обучению;

–        коммуникабельностью с другими сотрудниками;

–        способностью разделить ответственность с другими;

–        профессионализмом и знанием методов управления.

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

 

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

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

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

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


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

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

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

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

–        рабочие стили членов группы;

–        число людей в группе;

–        стиль работы с заказчиками и разработчиками.

Один из популярных стилей ведения проекта впервые использовался в IBM   (рис.10.5). В нем главным ответственным за проектирование системы и ведение разработки является  руководитель группы программистов. Ему непосредственно подчиняются программисты, которые имеют право последнего слова при принятии решений – главные программисты. Главный программист руководит своей подгруппой программистов и непосредственно посвящен в детали проекта и разработки программы.

               



                                                                   Главный

                                                               программист



                                                                Ассистент

                                                                 главного

                                                              программиста  



        Программисты         Библиотекарь              Администратор       Группа  тестовиков

       Подчиненный

       программист

 

      Рис.10.5.  Структура  организации группы главного  программиста

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

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

Альтернативная структура ведения проекта описана Вейнбергом (Weinberg) [3], так называемое обезличенное программирование, при котором все несут одинаковую ответственность за качество продукта. В проекте не концентрируются на персоналиях, критике подвергается программный продукт, а не члены группы. Такая структура подходит для маленьких групп программистов.

Ответственность за моделирование работ в проекте. В [3] в рамках военного ведомства разработана общая структура команды для  создания интегрированного продукта (Integrated Product Development Team). Модель ответственности команды приведена на рис.10.6.





                                         ТРЕБУЕМЫЕ   РЕЗУЛЬТАТЫ

                                              

                                               Ответственность за

                                          -    планирование               

                                          -     выполнение плана

                                          -     конечный результат

                       Команда                                                         Заказчик 

                                       

                                       Воздействие на проект:

                                    -   инспекция элементов /сборка

                                    -   содействие

                                    -   руководство  

                                    -   пополнение

        Рис. 10.6  Модель ответственности лиц  в интегрированном проекте

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

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

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

Основные этапы преобразования данных в БД

         Учитывая приведенные проблемы, рассмотрим пути их решения.  Отметим,  что промышленная эксплуатация систем, работающих с БД,  может продолжаться достаточно долго. При этом  изменяются  прикладные программы,  работающие  с БД,  повторно  преобразуются  данные, если в систему введена новая БД, а  часть ранее определенных  данных уже перенесены в новую  БД.. Это влечет за собой  доработку прикладных программ доступа к данным, чтобы приспособить их  к  измененной структуре новой БД или  к старой БД.  Для переноса данных из старой БД в новую разрабатываются скрипты с  приведенной логической структурой БД или DBF–файлы, которые вначале размещаются в транзитной БД, а затем с учетом особенностей новой основной БД  переносятся в нею.  Может оказаться, что  процесс приведения структур транзитной  БД к новой окажется нецелесообразным и разработку новой БД проводить "с нуля". При этом заполненные справочники и классификаторы потребуется   дополнить появившимися новыми данными.

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

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

 

 Этапы преобразования данных.    Процесс преобразования данных  состоит из трех главных частей:

1.  Перенос данных между СУБД (перенос данных из старой БД в транзитные файлы и затем занесение данных из этих файлов в транзитную БД;

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

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

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

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

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

Основные понятия анализа ПрО

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

 

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

<имя объекта > <концепт>,

где    <имя объекта> –  идентификатор, строка из литер и десятичных чисел;

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

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

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

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

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

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

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

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

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

Различаются статические (постоянные) связи, которые не изменяются или изменяются  редко,  и динамические связи, которые имеют определенные состояния и изменяться на протяжении  сеанса функционирования системы.

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



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

б) в случае связи 1:N дополнительный атрибут предоставляет объекту N экземпляров,  принимающих  участие в связи;

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

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

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

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

 

 

Основные понятия в проблематике надежности ПС

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

Базовые понятия, которые используются в моделях надежности ПС, являются следующие [9–13]. 

Отказ

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

Дефект

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

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

Интенсивность отказов ­ это частота появления отказов или дефектов в ПС при ее  тестировании или эксплуатации.

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

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

Основы программных требований (Software Requirements)

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

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

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

Область знаний «Требования к ПО (Software Requirements)» состоит из следующих разделов:

– инженерия требований (Requirement Engineering),

– выявление требований (Requirement Elicitation),

–  анализ требований  (Requirement Analysis),

– спецификация требований (Requirement Specification).

– проверка требований  (Requirement validation),

– управление требованиями (Requirement Menegement).

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

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

Управление требованиями к ПО заключается  в  планировании и контроле  выполнения  требований и проектных ресурсов в процессе  разработки компонентов на этапах ЖЦ.

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

 

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

 

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



 

Спецификация требований к ПО –

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

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

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

 

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

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

 

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

 

Парадигма преобразования данных

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

Средствам представления данных и их форматов  являются:

 – стандарты кодировки данных  (XDR – eXternal Data Representation, CDR, NDR – Data Representation) и их трансформации;

–  ЯП программных компонентов и механизмы обращения друг к другу;

– языки описания интерфейсов компонентов – RPC, IDL и RMI для обеспечения передачи данных между разными компонентами.                 

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

Механизмами передачи данных   являются:

–  протоколы  передачи данных (TCP/IP, UDP, GIOP и др.) [11];

–  классы функций преобразования отличающихся типов и структур данных ЯП и генерации соответствующих новых типов данных  [12, 13];

– системные процедуры по обеспечению маршаллинга  данных между разными объектами  распределенной среды неоднородных компьютеров [7, 12] .     

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

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ

 

            АCM – Association   for Computing  Machinery

API  –  Application Progpam Interface

ER   –   Entity – Relationship

            IEC – International Electrotechnical Commission

            ISO –  International  System Organization

            IDL  – Interface Definition Language

ISO – International Standard Organization

ОМ  – объектная  модель

ООП– объектно-ориентированный  подход

ОМА ­–Object Management Architecture

ООМ – объектно-ориентированная  методология

CОД – система обработки данных

ОС – операционная  система

ORB – Object Request Broker

ПС – программная система

            СММ – Capability Maturity Model

   СОМ – Component Object  Model

СORBA – Common  Object Request Broker  Architecture

COP – Component-Oriented Programming

CBSE – Component-Based Software Engineering

СРР  – структура разбивки работ в проекте

CPM  – Critical Path Method (метод критического пути)

PERT   – Program Evaluation and Review Technique (анализ за методом PERT)

PMBOK – Project Management Body of Knowledge (ядро знаний в области

                     управления проектами)

SQA  – Software Quality Assurance  (гарантирование качества)

V&V –  Verification and Validation (верификация и валидация)

ПИК – повторного использования  компонент

            ПИ  – программная  инженерия

            ПО – программное обеспечение

РП – распределенное приложение

ЖЦ – жизненный цикл

SWEBOK – SoftWare Engineering of  Body Knowledge

RMI –  Remote Method Invocation

---

---