Глупые мысли об IT

Привет, народ!

В предыдущем посте я упоминал, что после того, как сформулированы требования к функционалу (Functional Requirements (FRs)) и его качественным характеристикам (Non-Functional Requirements (NFRs)), необходимо оценить, насколько качественными являются собранные или сформулированные данные. Иметь некачественные FRs/NFRs это так же плохо, как и вообще не иметь их. Рекомендуется произвести первоначальную оценку качества и полноты FRs/NFRs. Ничего нового я не расскажу тем, кто уже ознакомился с TOGAF. В любом случае, случае, я постараюсь рассказать от себя о первоначальной оценке с помощью критериев S.M.A.R.T (Specific, Measurable, Actionable, Realistic и Time bound).
В принципе, методика SMART может применяться не только в IT. Если подумать, то это просто подход с точки зрения здравого смысла. Если есть какие-то требования, надо проверить, что они:

• Конкретные (Specific)
  Если задача или требование сформулировано очень расплывчато – “сделайте мне красиво”, то можно сказать, что ничего у вас нет. Надо избегать неясных формулировок;
• Измеряемые или допускающих количественную оценку (Measurable)
  Это как-был уточнение первого требования, чтобы сделать его более конкретным, вводя количественные характеристики. Например, я столкнулся при работе над одним проектом с требованием, чтобы уменьшить время входа в систему (логина) на компьютерах под управлением Windows XP. Требование конкретное, но абсолютно невозможно понять, в чем проблема и насколько надо улучшить время входа: то ли сейчас время составляет один час, и бизнес будет счастлив уменьшить его до 45 минут, то ли время входа составляет 10 секунд и бизнес хочет добиться входа за меньше чем за секунду. Опять же, непонятно, надо ли достигнуть этого для всех пользователей, или только для тех, у кого сейчас время входа больше часа, сколько пользователей имеет такую проблему т.д. Для того, чтобы сделать требование имеющим хоть какой-нибудь смысл, оно должно было бы быть сформулировано подобным образом: уменьшить время входа, используя как цель время входа в систему эталонного пользователя с соотвествующим профилем (ссылка на максимальные, минимальные и среднее время для таких пользователей).
  Точно так же и в реальной жизни можно придумать как использовать подобный критерий. Например, можно решить купить машину. Конкретно? Конкретно. Но вот какую!? Если пойти купить какую-нибудь малолитражку для семьи из 7-ми человек, то это будет самый глупый поступок. Для улучшения первого критерия надо будет упомянуть еще хотя бы максимальное количество человек, которое будет перевозиться в такой машине; бюджет, желаемых расход, вид топлива плюс обязательные (кондиционер, к примеру) и желаемые опции (автоматическая коробка передач и т.п.). Купленная машина, руководствуясь такими критериями, скорее всего будет удовлетворять поставленным целям.
  Я думаю, каждый в жизни когда-нибудь сталкивался с подобными ситуациями: уменьшить время отклика приложения (насколько!?); улучшить “дружественность” приложения к пользователю (это как!? как это измерить!?) и т.д;
• Ясно описывающие проблему/цель (“Actionable”)
  Данный критерий позволяет убедиться, что есть понимание цели или проблемы и это позволит составить предварительный список того, что надо сделать. Иными словами, должно быть понятно, что надо будет сделать. Например, требование “увеличить производительность труда сотрудников” вряд ли можно назвать ясным. Оно должно быть переформулировано в что-то типа: “Увеличить производительность труда сотрудников путем оптимизации программного обеспечения, используемого сотрудникпми для выполнения непосредственных обязанностей. Производительность может быть достугнута перепланировкой интерфейса приложений с целью уменьшения <времени ввода данных, заполнения форм и т.п.> и повышения производительности серверных компонент приложений: <уменьшения времени отклика/уменьшения времени для получения отчетов и т.д.>;
• Требования должны быть реализуемые/достижимые (Reasonable)
  Здесь нужно подходить с позиции здравого смысла: являются ли выдвигаемые требования реалистичными или достижимыми? Если, согласно требованию, нужно построить космический корабль и приземлиться на Солнце, то при нынешнем уровне технологий такое требование не является реализуемым. Так же, как и например, требование сокращения времени загрузки компьютера до 1 сек. с момента нажатия кнопки включения :);
• Указывающие время выполнения (Time bound)
  В данном случае для выполнения данного критерия надо убедиться, что указаны временные рамки для выполнения заданых требований. Вполне возможно, что все будет сформулировано четко, ясно и недвусмысленно, но вот сроки на выполнения будут не указаны вообще (в таком случае скорее всего ожидается “мгновенное” выполнение задачи, что может быть невозможно) , или предоставляются совершенно нереалистичные сроки. К примеру: построить ракету для полета на Луну <требования и описания> и закончить постройку завтра :)

В реальной жизни при стандартных операциях или задачах многие критерии подразумеваются по умолчанию. Просьба сходить в магазин за молоком скорее всего подразумевает, что надо отправиться туда “как только так сразу”, купить то молоко и в том количестве, которое покупалось все время. Самое главное, точно знать, что все вовлеченные лица пользуются одними и теми же значениями по умолчанию.
И еще: SMART может использоваться как при проверке предъявляемых требований, так и при их предъявлении. Когда вам прийдется что-то просить сделать, не забудьте сформулировать свои требования так, чтобы другой человек проверил их по этой методике и остался доволен :)

Засим раскланиваюсь,
Рустам.