Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

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

UML — это широко распространенная графическая нотация для изображения 
объектно-ориентированных проектов.

Для облегчения процесса разработки программного обеспечения используется 
множество автоматизированных инструментальных средств. Некоторые из них 
представляют собой коллекцию классов с различными взаимосвязями. Примерами 
таких коллекций могут служить Rational Rose от Rational Corporation и Together от Object International. Эти инструменты облегчают построение объектных моделей, а также их соединение с соответствующим исходным кодом и диаграммами последовательности.

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

♦ [необходимо] Облегчение изображения объектных моделей и диаграмм 
последовательности.

♦ Быстрое создание классов.

♦ Легкое редактирование классов.

♦ Изменение масштаба изображения внутри частей модели.

♦ [желательно] Возможность  быстрого перехода от объектной модели к исходному коду.

♦ [необходимо] Должен стоить не более $Х для одного пользователя.

♦ [не обязательно] Возможность  обратного проектирования (то есть создания объектной модели из исходного кода).

Метрики для выбора архитектуры

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

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

«15. Графико-теоретическая  сложность архитектуры. Простейшей (статической) версией этой метрики  является выражение:

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

«25. Сложность потока данных или информации. Этот показатель измеряет 
поток информации в крупномасштабных объектах, сложность потоков в процедурах и модулях, а также сложность соединений между модулями.

 

11. Унифицированный процесс разработки  ПО (USDP).

Унифицированный процесс разработки программного обеспечения (USDP — Unified Software Development Process) впервые был предложен в книге Якобсона, Буча и Рамбо, изданной в 1999 году. Этот процесс является детищем более ранних методологий, разработанных этими тремя авторами: «Объектная методология» Якобсона, «Методология Буча» и «Техника объектного моделирования» Рамбо.

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

1. Начальные итерации — предварительные (подготовительные) взаимодействия с акционерами:

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

2. Итерации проектирования: их завершение желательно и просто необходимо; выбор базовой архитектуры.

3. Итерации конструирования: приводят к изначальной оперативной способности.

4. Итерации перехода: выпуск готового продукта.

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

С учетом приведенной выше классификации итераций, USDP может быть представлен матрицей (рис. 1.11 и рис. 1.12). Как и большинство процессов объектно-ориентированного анализа и проектирования, фазы водопадного процесса, представленные Якобсоном, также включают в себя фазу анализа. На рис. 1.11 показано, где эта фаза совпадает с классическими фазами водопадного процесса. Анализ состоит из той части процесса анализа требований, в которой выбираются и соотносятся между собой базовые классы приложения. Кроме того, в USDP отсутствует своя фаза интеграции, обычно представленная в классическом водопадном процессе. Это произошло в связи с убежденностью Буча в том, что объектно-ориентированные приложения могут и должны использовать непрерывную интеграцию. Другими словами, сразу после добавления новых частей исходное приложение интегрируется. Таким образом, отпадает необходимость в специальной фазе интеграции.

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

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

12. Проектирование ПО. Компонентное моделирование информационных систем.

 

13. Метрология и качество ПО. Метрики.

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

♦ удовлетворяет ясно сформулированным требованиям;

♦ проверяет входные данные и предсказуемо реагирует на некорректные 
входные данные;

♦ тщательно проинспектирован не только самим автором кода, но и другими 
разработчиками;

♦ прошел исчерпывающее многостороннее тестирование;

♦ тщательно документирован;

♦ имеет надежную оценку степени дефектности (процента ошибок).

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

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

♦ расширяемым (готовым к возможным изменениям для расширения функциональности);

♦ развиваемым (легко адаптируемым к изменению требований);

♦ переносимым (пригодным к использованию на нескольких платформах);

♦ общим (применимым к нескольким различным ситуациям).

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

Метрики

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

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

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

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

♦ объем выполненной работы, измеренный в физических единицах (например, число строк кода);

♦ время, затраченное на выполнение работы;

♦ степень дефектности (число дефектов на 1000 строк кода, число дефектов 
на страницу документации и т. д.).

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

Предварительные или желаемые значения метрик заранее прогнозируются, 
а затем сравниваются с полученными результатами. Например, наша организация ожидает 0,2 дефекта на страницу описания требований (в среднем - один на пять страниц, как известно по прошлым проектам). Нашей целью для данного проекта может являться 0,15 дефекта на страницу. Реальная же степень дефектности может составлять 0,17. Это говорит о том, что наши методы лучше использованных в прошлом, однако недостаточно хороши для достижения поставленной цели.

 

14. Модульное программирование. Реализация  программного кода.

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

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

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

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

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

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

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

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