IT-Project Management

IT-PM: Персональный блог об управлении IT-проектами

Posts Tagged ‘документы

Крэг Ларман. Применение UML и шаблонов проектирования

leave a comment »

Обложка книгиФундаментальный труд, охватывающий сразу несколько аспектов разработки ПО. Я читал эту книгу довольно давно, перечитывал некоторые части много раз. Сразу оговорюсь, я читал 2-ое издание, но сейчас в продаже уже 3-е.

Первое, что я вынес для себя из этой книги — это представление о том, как должен выглядеть итеративный процесс разработки. В книге описывается UP. Причем описываются различные аспекты и виды работ: начиная от формирования первоначального видения проекта и описания use-case`ов, и заканчивая тестированием продукта.

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

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

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

Безусловно, есть и пара минусов: не очень хорошо переведены некоторые термины, книгой неудобно пользоваться как справочником. 

Written by Артур К.

Апрель 7, 2008 at 8:29

Требования — это главное и основное. Часть 2: Документирование

leave a comment »

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

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

Чтобы не записывать все требования сплошным списком, нужно выделить группы требований. Здесь каждый решает сам, какая таксономия будет удобнее. Можно взять одну из уже существующих систем классификации, можно придумать свою, «заточенную» под конкретные нужды и цели. Лично я, предпочитаю широко известную модель FURPS+. Пару слов об этой модели.

Модель FURPS+ достаточно универсальна, и вместе с тем достаточно удобна. Путаница с распределением требований по группам возникает редко. Выделяются следующие группы требований:

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

Также полезно снабдить требования некоторыми атрибутами. Например:

  • Уникальный идентификатор, состоящий из первой буквы названия класса требований (Ф — функциональные, Н — надежность) и целого числа. Нумерация списков в Word может сместиться в случае перемещения требования или добавлении нового, а такой идентификатор (записанный простым текстом) никуда не денется. При ссылке на требование из другого документа достаточно указать этот идентификатор.
  • Актуальность («Действительно», «Снято», «Под вопросом») — часть требований в процессе разработки снимается, но не следует сразу удалять их. Возможно, кто-то ссылался на них из других документов.
  • Источник требования — документ, либо лицо, выдвинувшее данное требование. Если требование сформулирован плохо, или непонятно откуда взялось, можно будет уточнить, обратившись к источнику.
  • Дата введения требования.
  • Проектирование — когда и кем требование было учтено при проектировании, и в каком проектном документе можно найти решение, подтверждающее, что требование учтено.
  • Реализация — когда и кем требование было реализовано, и в каком модуле/файле/документе можно найти реализацию этого требования.
  • Тестирование — когда и кем была проверена и подтверждена корректность реализации требования. Также может быть указан использовавшийся при проверке Test-Case.

Written by Артур К.

Февраль 25, 2008 at 16:33

Опубликовано в Опыт управления

Tagged with ,