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

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

9. Сравнение технологий разработки ПО.

Технология конструирования программного обеспечения (ТКПО) — система ин­женерных принципов для создания экономичного ПО, которое надежно и эффек­тивно работает в реальных компьютерах].

Различают

методы, средства процедуры ТКПО.

Методы обеспечивают решение следующих задач:

·  планирование и оценка проекта;

·  анализ системных и программных требований;

·  проектирование алгоритмов, структур данных и программных структур;

·  кодирование;

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

·  сопровождение.

·   

Как сравнивать

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

Но что реально даст такое сравнение? Как можно сравнивать по этим показателям современные методологии, которые, вообще говоря, не регламентируют строго ни то, ни другое, ни третье: И как измерять степень различия? В методологию А входит на три артефакта и на две задачи больше, чем в методологию B? И что? Какой вывод можно из этого сделать? Так что же является теми ключевыми характеристиками, которые позволили бы сказать, что методологии А и В близки между собой, а методология С, напротив, отличается от А очень сильно? 

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

Что представляют собой предложенные для сравнения характеристики? Начнем с итеративной разработки ее отличия от каскадной ("водопада"). 

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

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

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

Уровень формализма

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

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

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

Microsoft Solutions Framework является схемой для принятия решений по планированию и реализации новых технологий в организациях. MSF включает обучение, информацию, рекомендации и инструменты для идентификации и структуризации информационных потоков бизнес-процессов и всей информационной инфраструктуры новых технологий.

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

В момент подготовки данного учебного курса последней версией MSF была 3.1, при этом существовали документы, относящиеся к версии 4.0 beta.

MSF состоит из двух моделей:

·  модель проектной группы;

·  модель процессов, и трех дисциплин:

·  управление проектами;

·  управление рисками;

·  управление подготовкой.

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

Управление программой

·  Разработка

·  Тестирование

·  Управление выпуском

·  Удовлетворение потребителя

·  Управление продуктом

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

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

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

Microsoft выпустила среду разработки, в полной мере поддерживающей основные идеи MSF - Microsoft Visual Studio 2005 Team Edition. Это первый программный комплекс, представляющий собой не среду разработки для индивидуальных членов коллектива, а комплексное средство поддержки коллективной работы.

Rational Unified Process

Rational Unified Process - это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом - RUP гарантирует, что все члены группы используют общий язык моделирования и процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.