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

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

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

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

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

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

Тронет улыбку загаром
Метеосводка на пейджер
По чекам агентства задаром
Кури сигареты, пей джин

Три с половиной недели
В сауне офиса сижу
Жертвой фьючерсных сделок
На европейских биржах

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

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

В данном случае под любовью я понимаю сознательный выбор. То, что это выбор, а не принуждение, и то, что он сознательный, а не бессознательный – ключевые факторы. Когда вы любите какое-то блюдо, вы выберете именно его из огромного ресторанного меню. Вы подождете, сколько потребуется, пока его готовят. Вы заплатите за него столько, сколько попросят. И вы не откажетесь от него в пользу другого блюда, которое может выглядеть более соблазнительно.

Это и есть любовь :)

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

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

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

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

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

Терпение – ваша самая сильная черта
Представьте себе, что вы общаетесь с детьми. В определенном возрасте дети задают много вопросов, в том числе о том, что для вас очевидно. Порой из-за этого вы не знаете, как им объяснить ту или иную вещь. Грамотный аналитик будет вести себя примерно так же. Делается этого не потому, что аналитик сам не может ответить на эти вопросы, а потому, что крайне важно получить именно ваш взгляд на проблему, понять, что для вас имеет значение. Для другого заказчика будет иметь значение что-то другое, для разработчика – третье, и так далее. Чем более полное представление будет у аналитика, тем лучше конечный продукт будет соответствовать вашим потребностям (порой даже тем, о которых вы не догадывались :)). То есть – нужно готовиться к тому, чтобы отвечать на разные вопросы, иногда банальные, иногда не один раз. И обратно – если аналитик почти не задает вопросов, тут определенно что-то не так.

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

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

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

Если оно зелененькое или шевелится – значит, живое. Помните такой факт из общей биологии? Мы с вами, как создания, имеющие биологическую природу, дышим, едим, растем до определенного возраста, размножаемся и двигаемся. Но когда речь заходит проекте, в котором участвуют те же самые люди, мы смиряемся с тем, что ему нужно есть (наши силы и время), позволяем ему расти (ибо от этого прямым образом зависит наш доход), время от времени проверяем, дышит ли (есть ведь проекты, которые, по меткому выражению одного коллеги, «рождаются мертвенькими»), но часто сопротивляемся его движению, а тем более – размножению. Ведь это означает увеличение объема работы, нередко с сомнительными перспективами дополнительного дохода.

Во время подготовки своего семинара по взаимодействию аналитика с заказчиком я выделила изменение требований как одну из проблем. В действительности «проблема» в данном случае – это лишь привычное для ушей описание ситуации, которая с точки зрения жизни и развития проблемой вовсе не является, а как раз наоборот. Да, я хочу предложить очередную банальную истину из серии превращения трудностей в преимущества. А как же иначе? Если бы у нас были преимущества в готовом виде, никто бы не читал этот журнал, ну и так далее – каждый сам нарисует цепочку причинно-следственных связей.

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

Теперь я расскажу, как гнуть монеты :)

Первое и главное: воспринимайте изменения как нечто, необходимое для роста и развития, и старайтесь находить их положительные следствия. Это очень важный момент, который определяет всю дальнейшую работу. Если вы даже не выиграете в доходах и потеряете во времени, то получите опыт – а он, как известно, бесполезным не бывает (в отличие от выводов из него). В следующем проекте этот опыт позволит вам сэкономить то время, которое вы потеряли в предыдущем. Через десять проектов суммарный опыт обязательно ощутимо повысит ваш доход (не сам собой, конечно, а при наличии вашего на то желания и выполнения необходимых телодвижений).

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

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

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

Успехов вам! :)

Эту историю мне рассказал ученик одной из С-Петербургских школ айкидо, в правдивости которого у меня нет оснований сомневаться.

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

А кто принесет – будем думать, что с вами делать, резюмировал он и засмеялся.

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

Недавно в сообществе аналитиков бурно обсуждали вопрос (из теста) на множественное наследование. В поисках примеров я обратилась к своей любимой области – и нашла! Предлагаю вот такую модель:

Некоторые пояснения.

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

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

3. Фолк – это синоним народной музыки. Спорным моментом я считаю выделение Народной музыки в отдельный класс. На самом высоком уровне абстракции всю музыку можно разделить на две части – духовную и светскую. Народная музыка скорее относится к светской (“скорее” – необходимая оговорка, поскольку во все времена невозможно было разделить в народном творчестве “духовные” и “популярные” мотивы, в отличие от музыки, создаваемой специально для развлечений, прямым наследником которой является современная поп-музыка). Но все-таки я решила использовать такую модель, как на рисунке – для наглядности.

В модели есть принципиальная ошибка. Какая?

Хорошим примером плохого анализа требований (или вообще его отсутствия) является каталог консалтинговых и тренинговых компаний на сайте “Консалтинг и тренинги Санкт-Петербурга”.

Мои претензии:
1. Невозможность выбора более трех категорий “Направление” (почему именно трех? почему не пяти, не десяти? – любой уважающий себя аналитик поинтересовался бы)
2. Невозможность выводить не 15 результатов на страницу (то же самое – почему именно 15? а не 100 или не 5, или не 10)
3. Отсутствие модерации каталога (ручной или автоматической). Результат – много “мертвых ссылок”. С телефонами компаний, думаю, то же самое.

Вот и представьте – перелопатить вручную почти 800 адресов (а для моей задачи нужно либо просмотреть ВСЕ живые сайты, либо выбрать много направлений, что недоступно).

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

Никогда так не делайте :)

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

Шесть лет назад я жила в городе с населением около двухсот тысяч человек и участвовала в его музыкальной жизни, посещая концерты интересных мне групп и общаясь с местными музыкантами. Результатом такого необременительного участия явилось то, что я задумалась – а почему собственно в городе, где существует какая-никакая рок-музыка, представители которой периодически выступают в разных городах нашей великой и могучей, в том числе соседнем С-Петербурге, до сих пор нет своего собственного музыкального Интернет-ресурса? Обращая взоры опять же к достойному соседу, можно было найти таких сайтов пару десятков – свой ресурс был почти у каждого крупного клуба. В Новосибирске тоже был свой рок-сайт. И в Нижнем Новгороде был. И в Архангельске был. Даже в Удмуртии и то существовал вполне живой ресурс, посвященный рок-музыке. А у нас – не было.

А раз нет – почему бы его не сделать?…
Впрочем, неправда – у нас был сайт единственного в городе клуба, где выступали не только местные, но и приезжие команды, причем разного уровня и окраски – бывали там и «Торба на круче», и «Аукцыон», и «Кирпичи», и какие-то финны, шведы, белорусы, в общем, администрация активно занималась своей основной деятельностью.
Сайт этого клуба состоял из расписания концертов и гостевой книги.

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

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

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

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

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

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

Собственно, в этом месте можно опускать занавес. Напоследок скажу, что в активной фазе ресурс просуществовал два года – один цикл жизни Интернет-сообщества, – и был мною закрыт на отметке около 5-6 тысяч уникальных посетителей в месяц с индексом цитирования 375 по данным Яндекса. На него до сих пор ссылаются несколько десятков других сайтов, хотя домен уже два года, как свободен. Если бы не мой переезд и не подхваченная одним из музыкантов инициатива (которая выразилась в создании собственного сайта аналогичной тематики), вполне возможно, я бы еще какое-то время этим занималась.

Домашнее задание: почему в описываемой ситуации подобный проект стал возможен?

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

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

Я по-прежнему не боюсь сделать худший блюзовый альбом всех времен. Потому что надо рисковать. Я узнал это очень давно от моего отца. Он сказал – если будешь слушать других, ты никогда не создашь ничего особенного.
Маршалл Чесс, продюсер, управляющий компании “Rolling Stones”

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

Итак, все началось с того, что в определенный момент я увидела, как кривая моего профессионального роста выродилась в горизонтальную прямую. Уверенность в том, что можешь решить любую задачу в своей области – один из верных признаков прекращения роста. Технологии перестают иметь значение. Любая технология осваивается за конечный период времени, поддающийся оценке. Ты понимаешь, что это инструменты, и знаешь, где они лежат – ты можешь пойти и взять любой из них, когда потребуется. Достаточно понимать систему, принцип, внутреннюю логику процесса. Можно справедливо вопросить – а на чем, собственно, основана твоя уверенность?… Ответ: на том, что за предыдущие несколько лет я решила много разных задач.

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

Дальше собранную информацию нужно структурировать и создать какую-то модель. Хотя бы описание. Оказавшись перед этой задачей, я в полной мере прочувствовала, что объектный подход это не “друг за другом”, а “все время из середины” или “с разных сторон”. Зафиксировав ключевые моменты (проблемы и решения, как они мне виделись), я стала развивать каждый из них до такого состояния, когда все они оказались связанными друг с другом. Разумеется, постоянно шел обмен мнениями с людьми, которые обладают определенным опытом в сферах, где мне его не хватает. Но основным критерием все же было мое вИдение.

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

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

Через три месяца после начала описания концепции у меня появилась тестовая площадка, скажем так – прототип. Технически реализовано процентов 80, но оставшиеся наиболее критичны. С точки зрения сроков все идет по плану, несмотря на задержку из-за выпадения некоторых ключевых игроков – ее компенсировала простота выбранного технического решения.

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

Как это делается.

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

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

1. Первый шаг после получения запроса – определение источников, из которых нужно собрать информацию, имеющую отношение к рассматриваемому вопросу. Основных источников три – законодательство, проектные документы (включая ТЗ и пользовательскую документацию) и деловая переписка. Чем лучше структурирована информация, тем быстрее поиск. Кое-что нужно просто прочитать от начала до конца.
2. Собрав всю информацию, начинаем сравнивать фрагменты из разных источников. Цель – согласовать их между собой и выявить противоречия. Каждое противоречие нужно разрешить до того, как принимать окончательное решение. Для этого мы можем обращаться с вопросами к заказчику изменений и экспертам. Люди, которые являются экспертами в чем-либо, есть в каждой организации, даже если табличка с этим званием не украшает их рабочий стол.
3. Когда все противоречия разрешены, нужно проследить влияние запрашиваемых изменений на то, что уже существует. Это могут быть имеющиеся алгоритмы, данные и бизнес-процессы. Если изменения могут стать причиной исключительных ситуаций или новых комбинаций условий, то на каждый вариант нужно определить реакцию.

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

Вот примерно так, на практике, это делается в местных условиях.

К.Ларман. Применение UML 2.0 и шаблонов проектирования
Только начала читать эту книгу. Чувствуется хороший букварь для начинающих – если те книги, которые перечислены ниже, с нуля воспринимать тяжеловато, то эта подойдет и для студентов. Очень грамотно объясняется, что такое объектно-ориентированный анализ (больше нигде в литературе такого грамотного объяснения не встречала). Рекомендую!

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

Спрашивают периодически – что почитать. Перечислю то, что сама честно прочитала, и свои впечатления.

К.Вигерс. Разработка требований к программному обеспечению.
Исчерпывающий букварь для аналитиков. Начинающим не все будет понятно, поэтому лучше всего возвращаться к ней по мере набора опыта. Многие вещи можно применять на практике даже в местных условиях. А если вы убедите свое руководство внедрять RUP или хотя бы управление требованиями, то книга будет просто бесценной.

Г.Буч, Дж.Рамбо, А.Джекобсон. Язык UML. Руководство пользователя.
По этой книге я начинала учить UML. Сейчас есть уже второе издание, но лично мне оно показалось менее удобным – бОльшая его часть организована как справочник по языку. Однако тем, кто собирается использовать UML на практике, начинать лучше с него (а не с перепевок Леоненкова и т.п. – сами знаете, как источники искажаются :)).

Дж.Рамбо, М.Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка.
Еще один фундаментальный труд. Подойдет и для начала, и для продолжения. Аналитикам особенно полезен тем, что там описываются вещи, которые в практико-ориентированных книгах найти невозможно – например, как разрабатывается концепция системы. Именно не только конкретные методы, а как надо научить работать свои мозги, чтобы находить оптимальные решения. Очень-очень рекомендую.

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

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

На учебе я заметила такую вещь.
Дают описание задачи на полторы странички.

Разработчики по нему рисуют 10 вариантов использования. У меня получается 2-3.
Если объединить эти 10 в функциональные группы, то как раз те же 2-3 и получатся. Разные уровни абстракции.

Для разработчика такая детализация приемлема. Для аналитика – нет.

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

Дальше эту схему нужно обрабатывать напильником. Например, задать следующие вопросы:
1. В чем заключается задача?
2. Отражает ли схема все возможные сценарии и все возможные роли для поставленной задачи?
3. Почему сценарии и роли сгруппированы именно таким образом?
4. Что такое “Просмотр исходящей и входящей информации”, почему это выделено в отдельный сценарий, и почему этим занимается только Делопроизводитель подразделения?
5. Преподаватель и Студент, кроме получения справочной информации, не занимаются больше ничем?
и т.д. Вопросов можно настрогать много.

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

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

В прошлый раз thomas предложил задание для построения диаграмм UML.

У меня получился вот такой набор:

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

Моя точка зрения. Поскольку удалось выделить в описании только один процесс, то именно его я и отразила в диаграмме деятельности. Детали проверок нас в данном случае не интересуют, главное алгоритм. В принципе его почти без изменений можно перенести в код (заполнив упомянутые проверки нужными данными). Но здесь такая задача даже не ставилась.
После того, как я почитала описание в журнале у thomas’а, мне удалось нарисовать диаграммы классов и кооперации. С последней все ясно – наше предприятие в ней будет играть роль Исполнителя (можно назвать как угодно), которое имееет отношения с Поставщиками, с одной стороны, и с Клиентами, с другой. От одних оно получает материалы, а другим поставляет услуги (работу). То и другое оплачивается и сопровождается некоторыми документами.

Что касается диаграммы классов, тут возможны разные варианты. Важно помнить о том, что чем выше уровень абстракции, тем более широкий класс задач можно описать такой диаграммой – и в то же время наш частный случай должен найти в ней отражение. Исходя из этого, я определила две роли – Поставщик и Клиент. По большому счету нас интересует только эта роль, т.к. конкретный участник (предприятие, в том числе наше) выступает всегда в одной из них. Второй момент – наследование классов Материал и Работа от общего класса Продукт. Идея такая: есть Поставщик, есть Клиент, они связаны тем, что один что-то получает от другого – это что-то в данном случае и называется Продукт. Т.к. процессы поставки материалов и выполнения работы в контексте этой задачи почти не отличаются, то мне показалось возможным их объединить таким образом. Но, повторю, тут все индивидуально.

Документ всегда сопровождает Продукт – таким образом удалось избежать дублирования связи, которое возникло бы в том случае, если бы у нас не было родительского класса. Вместо этого пришлось бы указывать связи Документа с Материалом и с Работой.

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

Как я пишу техническое задание? Беру исходный материал и отрезаю все лишнее.

Требования, как правило, принимают в течение своей жизни следующие состояния:
1. понятны клиенту;
2. понятны мне;
3. понятны разработчику.

ТЗ появляется между вторым и третьим.
То, что происходит между первым и вторым, называется анализ.

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

Как я обрабатываю информацию.

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

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

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

Когда все лишнее отпилили, можно заняться дизайном. Я строю ТЗ следующим образом: сначала очень сжатое описание всех функций, а потом по разделу на каждую группу родственных функций, где они описываются детально. Важно найти базовый принцип, на основании которого устанавливается родство.
Скажем, если некая система печатает отчеты в файлы MS Excel, получает данные из системы 1С и отправляет смс-сообщения, то все три функции будут являться частными случаями обмена с внешними системами. Объединяет их как минимум необходимость шлюза и согласованности форматов между обменивающимися системами.
Аналогично все требования к отображаемым меню и экранным формам объединяются в раздел, где описываются требования к дизайну.

К вопросу о том, чем мы тут занимаемся.

Если взять ВУЗовский учебник по технологии разработки программных средств, написанный русским автором (Орлова, например), то в одной из его глав найдем описания циклов разработки ПО. Когда я писала свой диплом, то честно передирала оттуда куски теоретической части. Поэтому в мозгу отпечаталось:
1. Системный анализ
2. Анализ требований
3. Проектирование
4. Кодирование
5. Тестирование
6. Внедрение
7. Сопровождение

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

Что касается последнего, то прерывание такого рода само по себе способно привести меня в ярость, а когда оно происходит по 20 раз на дню, то провоцирует припадки бешенства с неконтролируемыми повреждениями объектов материального мира. И тем не менее, все это требуется в моей профессии.

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