Введение

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

Ниже описаны основные принципы эффективного процесса программного обеспечения.

1. Представление:  Разработка представления

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

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

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

• Каковы ключевые термины? (Глоссарий)
• Какую проблему мы пытаемся решить? (Постановка проблемы)
• Каковы заинтересованные лица? Кто является пользователем? Каковы их потребности?
• Каковы функции продукта?
• Каковы функциональные требования? (Варианты)
• Каковы нефункциональные требования?
• Каковы ограничения проектирования?

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

2. План:  Управление в соответствии с планом

"Продукт хорош настолько, насколько хорош его план" ( FIS96 ).

Зарождение нового проекта; оценка области действия и рисков; мониторинг и контроль проекта; планирование и оценка каждой итерации и этапа - это "сущность" дисциплины Управление проектом.

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

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

Формат артефактов планирования не так важен, как деятельности планирования, и входящее в них обдумывание. Не имеет значения, как будут выглядеть планы - или какие инструменты применяются для их создания.  Как сказал Dwight D. Eisenhower, "План есть ничто; планирование есть все."

3. Риски:  Вопросы снижения рисков и последствий

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

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

4. Бизнес-прецедент:  Изучение бизнес-прецедента

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

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

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

5. Архитектура:  Проектирование архитектуры компонентов

В Rational Unified Process (RUP) архитектура системы программы (в данной точке) представляет собой организацию или структуру важных компонентов системы, взаимодействующих посредством интерфейсов, где компоненты состоят из последовательно уменьшающихся компонентов и интерфейсов.  Каковы основные части?  Как они совмещаются?  Имеется ли структура, на которую можно добавить оставшуюся часть программы?

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

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

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

6. Прототип:  Последовательная компоновка и тестирование продукта

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

Дополняющие операции компоновки и тестирования компонентов системы являются "сущностью" дисциплин Реализация  иТестирование и  принципа итеративной демонстрации стоимости.

7. Оценка:  Регулярная оценка результатов

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

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

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

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

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

8. Запросы на изменения:  Управление и контроль изменений

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

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

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

9. Поддержка пользователей:  Развертывание пригодного для работы продукта

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

10. Процесс:  Адаптация процесса, подходящего для данного продукта

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

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

Дополнительная информация по адаптации RUP для данного проекта и организации приведена в разделе: Концепции: Адаптация RUP.

Заключение

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

• Нет представления? Вы можете потерять представление о том, куда вы движетесь, и можете легко сбиться на окольные пути.
• Нет процесса? Без стандартного процесса коллектив может не осознавать, кто, что и когда должен выполнять.
• Нет плана? Вы не сможете отслеживать ход работы.
• Нет списка рисков? Вы можете сфокусироваться на неверных вопросах и потратить на ненужные разработки 5 месяцев.
• Нет бизнес-прецедента? Вы рискуете потерять время и средства на проекте. Он может быть отменен или обанкротится.
• Нет архитектуры? Вы не сможете управлять связью, синхронизацией и возникающими вопросами доступа к данным; могут возникнуть проблемы, связанные с масштабируемостью и производительностью.
• Нет продукта (прототипа)? Как можно раньше представьте продукт заказчику. Простое ведение документации не гарантирует успех продукта - и возрастает риск перерасхода и/или полного исчерпания бюджета и планирования.
• Нет оценки? Не прячьте голову в песок. Важно смотреть правде в глаза. Насколько вы в действительности близки к конечному сроку? К целям в отношении качества и бюджета? Все ли вопросы прослеживались адекватно?
• Нет запросов на изменения? Как вы отслеживаете запросы заинтересованных лиц? Как вы расставляете приоритеты? И как предохраняете лица с низким приоритетом от неудач?
• нет поддержки пользователей? Что произойдет, если у пользователя возникнет вопрос, или он не сможет выяснить, как пользоваться продуктом? Насколько легко получить справку?

Эти "сущности" также обеспечивают введение в каждую из Групп дисциплин: Дисциплины RUP RUP, и поддерживают его Основные принципы.