Вопросы и ответы по дисциплине 5224 «Разработка и стандартизация программных средств и информационных технологий»

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

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

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

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

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

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

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

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

2. Жизненный цикл.

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

При создании заказного ПО выделяют пять основных стадий ЖЦ:

анализ и формализация требований заказчика;

проектирование;

реализация;

тестирование;

внедрение и эксплуатация.

Теперь об обещанных типах ЖЦ. В литературе описано множество типов жизненных циклов. Среди всего этого разнообразия можно выделить два основных.

Последовательный тип

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

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

имеется достаточно большой опыт реализации подобного рода систем;

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

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

Эволюционный тип

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

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

сложность в управлении и контроле выполнения проекта;

сложность оценки затрат на разработку;

риск бесконечного улучшения системы.

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

Выбор типа жизненного цикла

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

наличия четких и подробных требований к ПО;

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

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

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

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

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

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

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

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

организации программной системы;

выбора структурных элементов, составляющих систему и их интерфейсов;

поведения этих элементов, специфицированного в кооперациях с другими элементами;

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

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

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

4. Структурные сущности.

Структурные сущности - это существительные, применяемые в моделях UML. К ним относятся классы (Classes), интерфейсы (Interfaces), кооперации (Collaborations), прецеденты (Use cases), активные классы (Active classes), компоненты (Components) и узлы (Nodes).

5. Архитектурные виды.

Архитектурные виды

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

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

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

Моделирование архитектурных видов осуществляется следующим образом:

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

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

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

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

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

6. Определение процесса

Понятие процесса является базовым, но системные и прикладные программисты определяют его по-разному. Архитектура любой ЭВМ многопроцессорная, т.к. процессор – это устройство в составе ЭВМ, способное самостоятельно выполнять некоторые действия по хранимой в памяти информации, кроме МП существуют контроллеры ББУ и т.д. Процесс—некоторая деятельность, связанная с исполнением программы на МП.

7. Характеристики процесса

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

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

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

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

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

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

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