• О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 2

      С частью 1 можно ознакомиться, перейдя по ссылке

      Рекомендации по проектированию спецификаций требований с примерами


      То, о чем не говорят, каждый понимает по-своему

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

      Готовим читателей к знакомству со спецификациями


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

      Пример обзора документа:



      Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
      Читать дальше →
      • +12
      • 3,5k
      • 4
    • О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 1

        По мотивам моей статьи, изданной ранее…

        Вступление


        Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
        (Георгий Александров)

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

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

          С частью 1 можно ознакомиться, перейдя по ссылке
          С частью 2 можно ознакомиться, перейдя по ссылке

          Использование спецификаций требований в управлении проектом


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

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

          Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человеко\днях или человеко\часах (как Вам удобнее) по подсистемам и проекту в целом.
          Читать дальше →
        Самое читаемое