tsegelnyk: (Default)
[personal profile] tsegelnyk

При внедрении любого программного продукта существует несколько подходов к предоставлению результата Заказчику. Под результатом я понимаю программу, настроенную или скорее всего настроенную по бизнес-требованиям.

Понятно, что Интегратор ничего сам не программирует. Понятно, что он сам, как правило, не создает базу данных с 0, не создает ее структуру. Он лишь обеспечивает адаптацию купленного Заказчиком продукта к его бизнес-требованиям, настраивает его. А теперь давайте представим картинку: Заказчик заказал, Интегратор знает программу как свои пять пальцев, вдоль и поперек, он занимается ее настройкой, чтобы она работала, как описал Заказчик в бизнес-требованиях. Настраивает ее, отдает Заказчику и,… казалось бы, все должны быть довольны, ан нет. Программа не работает! Кто касался программирования или внедрения, сразу понимает, что мы пропустили один шаг – тестирование. Тестирование того, что настроил Интегратор, и насколько это соответствует тому, что заказывал Заказчик.

Существует 2 основных подхода к тестированию:

1) Все тестирование на себя берет Заказчик. Т.е. Интегратор чего-то там добавляет, создает, исправляет, а проверку делает Заказчик. Проверку на соответствие бизнес-требованиям, проверку на правильную работу бизнес-логики и т.д.

2) Все тестирование берет на себя Интегратор. Заказчик получает уже готовый продукт, который необходимо лишь правильно установить. В нем возможны небольшие огрехи, но что касается соответствия бизнес-логике или бизнес-требованиям, он будет безупречен.

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

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

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

Идеально - Интегратор сам тестирует свои настройки и изменения в системе. Как только он может показать реально работающий процесс – он передает его Заказчику. Заказчик проверяет логику, и соответствие договоренностям по документам.

This account has disabled anonymous posting.
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting

Profile

tsegelnyk: (Default)
tsegelnyk

August 2011

S M T W T F S
 1 23 456
78910111213
14151617181920
21222324252627
28293031   

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 17th, 2025 01:50 am
Powered by Dreamwidth Studios