ИТ-консультант.рф - Технический проект

ИТ-консультант.рф : Холодков Антон

главная

внедрение BPM-систем

консультирование

мои статьи

обо мне & галерея проектов

контакты

Новая статья:

BPM-система в действии или как сделать много за мало

Прочитать...

Артефакты ИТ-консалтинга

Технический проект

Аналитическая записка

Концепция

Описание бизнес-процесса

Артефакт (от лат. Artefactum — искусственно сделанное) — явление, процесс, предмет, свойство предмета или процесса, появление которого в наблюдаемых условиях по естественным причинам невозможно или маловероятно. Появление артефакта, следовательно, является признаком целенаправленного вмешательства в наблюдаемый процесс, либо наличия неких неучтённых факторов.

Термин «артефакт» очень хорошо отражает то, что «производится» в процессе ИТ-консалтинга, его «выходы», «осязаемые результаты». В данном контексте «наблюдаемая система» - это бизнес Заказчика или его отдельные элементы (бизнес-процессы, информационные системы и т.п.), а артефакты – это то, что создает для Заказчика ИТ-консультант (документы, внедренные бизнес-процессы и системы, оформленные идеи и т.п.). Артефакт создается Консультантом для использования Заказчиком, поэтому в итоге должен рассматриваться как часть его бизнеса. Однако, ввиду того, что этот элемент полностью или частично создан Консультантом, он также представляется «искусственно сделанным». Артефакты ИТ-консалтинга, очевидно, создаются путем «целенаправленных усилий» со стороны Консультанта и без его участия их появление «маловероятно», иначе Заказчик не обращался бы к Консультанту. В общем, мы видим соответствие почти с каждым словом в определении «артефакта».

Большинство артефактов ИТ-консалтинга являются документами, но не только ими, поэтому использование термина «документ» для обозначения результатов работы Консультанта не совсем полно отражает суть происходящего. Например, в результате своей работы ИТ-консультант может внедрить у Заказчика хранилище бизнес-моделей и бизнес-процесс их непрерывного совершенствования, актуализации. Это не документы, но, несомненно, осязаемые результаты работы Консультанта.

Создаваемые ИТ-консультантом артефакты, как и весь процесс ИТ-консалтинга, несомненно, направлены на достижение Заказчиком бизнес-целей. В этом смысле артефакты являются промежуточными элементами между работой Консультанта и бизнес-целями Заказчика. Артефакты могут перечисляться в договоре между Заказчиком и Консультантом в качестве требуемых результатов работы последнего.

Подробнее об ИТ-консалтинге

Зачем это нужно?

Для кого это может быть интересно?

Как улучшить достижение бизнес-целей за счет использования ИТ?

Что именно делается для этого?

В каких случаях целесообразно участие консультанта?

Контакты

город Москва

e-mail: anton@kholodkov.ru

skype: a_kholodkov

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

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

Технический проект используется разработчиками при программировании спроектированного программного продукта. В его «принципиальной части» он может использоваться при обсуждении и согласовании ключевых проектных решения с Заказчиком. Также технический проект может быть очень полезен другим техническим и не очень техническим специалистам в решении самых разнообразных задач.

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

Исходя из основного требования, в технических проектах обычно решение описывается «сверху вниз» - от самого высокого уровня абстракции до деталей реализации отдельных элементов. Соответственно, в работе над различными частями технического проекта могут принимать участие разные специалисты: системный аналитик, архитектор, ведущий разработчик и т.п.

Для обозначения «Технического проекта» в различных системах и методологиях могут использоваться разные термины. Так в отечественных ГОСТах 34.201-89, 34.601-90 и РД 50-34.698.90 под «Технический проект» в описанных выше границах подпадает несколько десятков документов, создаваемых на стадиях «Эскизный проект», «Технический проект» и частично «Рабочая документация». В рамках MSF выделяются понятия концептуальный, логический и физический дизайн, по своей сути в совокупности также эквивалентные понятию «Технический проект». В предлагаемых в последнее время «шаблонах процессов разработки» (например, для Microsoft Team Foundation Server) также присутствуют самые разные сущности проектирования, которые не перечесть, однако все они будут так или иначе укладываться в понятие «Технический проект», поскольку отражают те же самые философские принципы и специфику разработки программных продуктов.