М. Фаулер, К. Скотт - UML Основы, страница 8

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

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

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

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

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

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

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

Старайтесь разрабатывать свой проект таким образом, который позволил бы вам относительно легко вносить изменения в элементы данного проекта. Задайте себе следующие вопросы: Что случится, если какая-то часть технологии не будет работатьт ° Что произойдет, если не удастся согласовать между собой два фрагмента мезанинов ° Какова вероятность принятия ошибочных решенийу Если они всетаки будут иметь место, каким образом мы могли бы с ними справиться7 Так же как и модель предметной области, вам следует внимательно анализировать варианты использования по мере их появления, чтобы оценить, нет ли в них чего-либо такого, что может привести ваш проект к краху.

Если есть опасения, что варианты использования могут содержать вскрытого червя», продолжайте их исследовать и далее. В ходе этого процесса, как правило, приходится пользоваться рядом методов языка ТАЙМЕ для того, чтобы схематически представить идеи и документировать те решения, которые впоследствии вы постараетесь реализовать. Не пытайтесь на этой стадии разработать исчерпывающую модель; краткие наброски — это все, что необходимо, и все, что следует использовать. ° Диаграммы классов (см.

главы 4 и 6) и диаграммы взаимодействия (см. главу 5) полезно использовать для представления взаимодействия компонентов. Исследование Диаграммы пакетов (см. главу 7) на этой стадии могут дать общее представление о компонентах системы. ° Диаграммы развертывания (см. главу 10) могут дать представление о распределении составных частей системы. Риски, связанные с квалификацией персонала Я часто посещаю различные конференции и с интересом слушаю выступления разработчиков, только что завершивших какой-либо объектно-ориентированный проект.

В ответ на вопрос: «Что являлось для вас самой большой ошибкой 2 «они почти всегда включают следующую фразу: «Нам следовало больше внимания уделять обучению«. Я никогда не перестану удивляться тому, как компании приступают к выполнению сложных объектно-ориентированных проектов, имея незначительный опыт в этой области н не задумываясь о наиболее выгодных решениях. Людям жаль тратить деньги на обучение, но им влетает в копеечку продление сроков завершения проекта. Обучение является способом избежать ошибок, поскольку учителя эти ошибки уже сделали.

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

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

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

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

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