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

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

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

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. Об этом в следующем посте.

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