Оценка качества требований

Posted on Saturday 30 April 2011 under , by Rustam Sydykov

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

В предыдущем посте я упоминал, что после того, как сформулированы требования к функционалу (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 может использоваться как при проверке предъявляемых требований, так и при их предъявлении. Когда вам прийдется что-то просить сделать, не забудьте сформулировать свои требования так, чтобы другой человек проверил их по этой методике и остался доволен :)

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

Требования к функциональности систем/решений

Posted on Monday 18 April 2011 under by Rustam Sydykov

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

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

  1. Требования к функциональности системы (так называемые “functional requirements” (FRs)).
    В это входит описание “что” должна делать система/решение/сервис или приложение. Например: почтовая система должна предоставлять возможность коллективной работы (календарь, общие папки), позволять обмениваться е-мейлами внутри предприятия и с другими организациями через интернет; антивирусная система для файл серверов должна проверять файлы на запись/чтение и т.д.;
  2. Требования спецификации системы (“non-functional requirements” (NFRs))
    Это описание того “как” должна работать система/решение/сервис или приложение. Иными словами – описание “качества”. Например: файловый антивирус должен быть обновлен не позднее чем через 1 час после того, как производитель антивируса обновит антивирусную базу; антивирус не должен использовать более 10% ресурсов файлового сервера в пиковое время и т.п.

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

  • Бизнес предлагает уже выбранное им решение или приложение. Вполне возможно, что выбор правильный, не тем не менее внедрение приложения или решения/сервиса должно решать определенные бизнес-задачи: “Какие задачи в бизнесе вам предстоит решать, используя это приложение? Какая выгода от этого будет?”;
  • Бизнес не может предоставить четкую задачу или описание задачи слишком расплывчато: “Какая(ие) проблема(ы) существует? Как вы думаете, как ее можно решить? Что будет, если данная проблема не будет решена?”;
  • Бизнес не может определить границы проекта: ограничиться ли одним отделом, внедрить на всем предприятии и т.п.: “Какая часть бизнеса или бизнес-процессов получит выгоду в после окончания проекта? Как часть бизнеса страдает от проблемы, которую предстоит решить? Каков бюджет, выделенный на проект?”

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

  • Производительность системы (performance)
    Если брать в пример ту же почтовую систему, то требование может звучать так: обеспечивать отклик системы не более…, среднее время доставки внутри предприятия – …, время отправления/получения е-мейла, отправленного через и-нет – … и т.п.;
  • Запас производительности/мощность сервиса/системы (capacity)
    Например: почтовая система должна предоставлять сервис для …пользователей, средний почтовый ящик не более …МБ, среднее количество писем, отправляемых в день и т.д.;
  • Масштабируемость (scalability)
    Почтовая система должна обеспечивать требуемую производительность с учетом роста количества почтовых ящиков на … в год;
  • Доступность (availability)
    Почтовая система должна предоставлять сервис 99.9% рабочего времени в год или 24х7 :)
  • Восстанавливаемость (continuity)
    В случае сбоя, система должна быть востановлена в течении … часов и с потерей не более чем …% данных пользователей;
  • Безопасность (security)
    Система должна быть защищена от несанкционируемого доступа; доступ к почтовым ящикам для авторизированных пользователей через интернет только с шифрованием трафика ключем не менее …. бит и т.д., и т.п.

Когда все эти требования собраны, надо в обязательном порядке “пропустить” их через фильтр критериев: S.M.A.R.T. Об этом в следующем посте.

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

“Модные” методики в IT

Posted on Monday 4 April 2011 under , by Rustam Sydykov

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

После определенного уровня проектов, в которых участвовал, или размеров компаний, на которые работал, невозможно не столкнуться с различными методиками, которые если не применяются, то хотя бы упоминаются типа “мы внедрили упрощенную версию методики Х или частично методику Z”. Без этого как бы стыдно говорить о больших проектах или работе IT службы на крупном предприятии. Поэтому об этих вещах надо хотя бы иметь какое-то представление. В моем случае это архитектура и внедрение IT проектов, связанных с инфраструктурой (сервера, приложения), а не программирование (а жаль ).
Итак, по порядку:

  • Методика, описывающая полный цикл создания и управления IT архитектурой масштаба предприятия – TOGAF. Это даже не медотика для создания архитектуры, а набор правил, принципов, рекомендаций для создания процесса создания архитектуры :) Так как TOGAF – достаточно высокоуровневая общая методика, с ее помощью сразу так IT архитектуру не построишь. Существуют еще специализированные методики, которые  могут применяться в той или иной отрасли. Следующим этапом для IT, например, может быть Zachman Framework.
    Если кому-то интересно, TOGAF можно скачать бесплатно с сайта http://www.togaf.org/. Я сейчас как раз где-то в середине цикла чтения. Более академического, сухого и скучного чтения я не пытался осилить со времен института, когда должен был готовится к экзаменам по теоретической физике :) Но читаю, потому что деваться некуда. Если честно – там очень много полезного, просто написано так, что спать клонит на 5-ой минуте. Я спасаюсь тем, что чтение разбил на две части по 15 минут: читаю в метро, когда еду на работу в метро с железнодорожной станции и потом обратно. В поезде предпочитаю что-нибудь повеселее :)
    Как и с другими методиками, я в жизни никогда не встречал полного следованию всему циклу разработки архитектуры. Всегда применялись упрощенные процессы. Если формально следовать всем рекомендациям, то для того, чтобы только начать разрабатывать архитектуру, надо будет написать порядка 20-ти документов :) Никто этого делать, конечно, не будет;
  • Внедрение проектов. Здесь больше поле деятельности менеджеров проектов. Но есть несколько распространенных “учений”:
    • Чаще всего говорят о PRINCE2. В этой области я вообще не силен, хотя неплохо было бы для меня пройти курс PRINCE2 Foundation. Все курсы Foundation дают общее понятие о предмете, не вдаваясь в детали. Полезно для того, чтобы иметь хоть какое-то представление и использовать одну и ту же терминологию;
    • От себя добавлю про Microsoft Solution Framework (MSF). Хотя основная цель в нем – разработка программного обеспечения, тем не менее для небольших проектов ее вполне  можно применить. Полный набор документации по этой методике можно скачать здесь.
  • Поддержка и управление IT средой:
    • Признанный лидер здесь ITIL. Позволяет по другому взглянуть на IT как набор сервисов, а не операционные системы и приложения. Опять же, имеет смысл пройти хотя бы курс ITIL Foundation, чтобы понимать, о чем будет разговор с каким-нибудь IT менеджером после сдачи проекта.
      Боюсь повториться, но не видел ни разу полного внедрения ITIL. Основной “гвоздь” ITIL – CMDB. Создание, внедрение и поддержка CMDB может оказаться неподъемной задачей для многих компаний, особенно в том случае, если ожидается мгновенная отдача от внедрения ITIL.
    • Опять же, менее академичный и более простой подход: MS Operations Framework (MOF). Читается легко, объем материала приемлемый. Даже если вы не собираетесь заниматься операционной поддержкой IT, я бы порекомендовал почитать MOF для общего развития. Я когда-то с этого начинал :)

Ну вот и все. Любые дополнения приветствуются.

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