Фазы унифицированного процесса и диаграммы UML

Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему, которая давала бы «значимый результат» пользователям и выполняла бы именно то, что они от системы ожидают. Поэтому процесс управляется вариантами использования (Use Case) системы, или иначе – прецедентами.

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

Рис. 54. Фазы и потоки работ RUP

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

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

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

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

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

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

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

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

Изменение бизнес-процессов, которое неизбежно должно произойти в компании-разработчике программного обеспечения при внедрении RUP и UML, может проходить также тяжело, как внедрение информационной системы на промышленном предприятии. Любое внедрение – это ломка стереотипов. Поскольку квалификация сотрудников в компании-разработчике ПО довольно высока, то и отказаться от своих взглядов таким людям труднее, чем «простым смертным», а возникающие трудности и неприятие можно сравнить с переходом от процедурного к объектно-ориентированному мышлению.