Что такое пми испытания
Техническая документация
разработка техдокументации по ГОСТ
Как писать программу и методику испытаний по ГОСТ 19.301-79?
Создан 16.02.2010 10:45:37
Структура и оформление документа устанавливается в соответствии с ГОСТ 19.105-78. Составление информационной части (аннотации и содержания) является необязательным [из 1.1 ГОСТ 19.301-79]
Необязательным – и не надо.
Разделы документа
Документ «Программа и методика испытаний» должен содержать следующие разделы:
В зависимости от особенностей документа допускается вводить дополнительные разделы [из 1.2 ГОСТ 19.301-79]
Разработчики стандарта в очередной раз обеспечили исполнителю пространство для маневра.
Содержание разделов
Имеет смысл дополнить ПМ, разработанную по ГОСТ 19.301-79, сведениями «системотехнического» характера. Поскольку разработчики стандарта предоставили возможность дополнять ПМ, следует воспользоваться этим и открыть РД 50-34.698-90.
Такой подход оправдан. В договоре не должно, по идее, быть ни слова по существу организации и проведения испытаний. В договоре просто указывается, что испытания должны иметь место.
Объект испытаний
Перечисленные сведения заимствуются из соответствующих разделов технического задания.
Наименование
Наименование – «Текстовый редактор для работы с файлами формата rtf».
Область применения
Программа предназначена к применению в профильных подразделениях на объектах заказчика.
Обозначение программы
Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf».
Условное обозначение темы разработки (шифр темы) – «РТФ-007».
Цель испытаний
В разделе «Цель испытаний» должна быть указана цель проведения испытаний [из 2.2 ГОСТ 19.301-79]
Фактически, цель проведения испытаний – сдача работы заказчику. Формально – подтверждение соответствия функциональных и иных характеристик разработанной программы требованиям, сформулированным в техническом задании.
Общие положения
Подраздел заимствован из РД 50-34.698-90. Названия подразделов несколько изменены.
Основания для проведения испытаний
Испытания проводятся на основании Приказа Директора ФГУП «Спецтяжмонтажстройсельхозавтоматика» за № таким-то от такого-то 2004 г.
Основанием проведения испытаний является Приказ о проведении испытаний с составом приемочной комиссии. Документ разрабатывается согласно, к примеру, разд. 6 РД 50-34.698-90.
Следующий подраздел заимствуется из технического задания.
Место и продолжительность испытаний
Приемосдаточные испытания должны проводиться на объекте заказчика в сроки…
Приемосдаточные испытания программы должны проводиться согласно разработанной (не позднее такого-то срока) исполнителем и согласованной с заказчиком Программы и методики испытаний.
Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в Протоколе испытаний.
Организации, участвующие в испытаниях
Испытания проводятся комиссией, в состав которой входят представители организаций заказчика и исполнителя. Состав комиссии утверждается Приказом.
Поскольку в техническом задании нет указанного пункта, для проведения испытаний достаточно представителей заказчика и исполнителя. В случае привлечения сторонних организаций следует указать их минимальные реквизиты.
Перечень документов, предъявляемых на испытания
Состав программной документации должен влючать в себя:
Перечень заимствуется из п. «Предварительный состав программной документации» технического задания. В случае необходимости в ходе разработки перечень может быть пополнен. Стоит согласовать с заказчиком.
Объем испытаний
Подраздел заимствован из РД 50-34.698-90.
Перечень этапов испытаний
Испытания проводятся в два этапа:
Перечень проверок, проводимых на 1 этапе испытаний
Перечень проверок, проводимых на 1-м этапе испытаний, должен включать в себя:
Методика проведения проверок, входящих в перечень по 1-му этапу испытаний, изложена в документе.
Перечень проверок, проводимых на 2 этапе испытаний
Перечень проверок, проводимых на 2-м этапе испытаний, должен включать в себя:
Методика проведения проверок, входящих в перечень по 2-му этапу испытаний, изложена в документе.
Количественные и качественные характеристики, подлежащие оценке
Количественные характеристики – все, что можно взвесить, измерить или просто сосчитать. Качественные – не требующие проведения измерений.
Количественные характеристики, подлежащие оценке
В ходе проведения приемосдаточных испытаний оценке подлежат количественные характеристики, такие как:
Качественные характеристики, подлежащие оценке
В ходе проведения приемосдаточных испытаний оценке подлежат качественные (функциональные) характеристики программы. Проверке подлежит возможность выполнения программой перечисленных ниже функций:
Приведенный выше перечень – результат вставки в настоящий документ п. «Требования к составу выполняемых функций» из технического задания.
Последовательность проведения и режимы испытаний
Испытания проводятся в последовательности, указанной в п. «Перечень этапов испытаний».
Перечень работ, проводимых после завершения испытаний
В случае успешного проведения испытаний в полном объеме исполнитель совместно с заказчиком на основании Протокола испытаний утверждают Акт приемки-сдачи работ… (Акт завершения работ согласно п.1 РД 50-34.698-90).
Исполнитель передает заказчику программное изделие, программную (эксплуатационную) документацию и т.д.
В случае выявления несоответствия разработанной программы отдельным требованиям техзадания исполнитель проводит корректировку программы и программной документации по результатам испытаний в сроки, согласованные с заказчиком.
По завершении корректировки программы и программной документации исполнитель и заказчик проводят повторные испытания согласно настоящей программы и методик в объеме, требуемом для проверки проведения корректировок.
Мелкие, несущественные недоработки могут быть устранены в рабочем порядке.
Требования к программе
В разделе «Требования к программе» должны быть указаны требования, подлежащие проверке во время испытаний (3.1) и заданные в техническом задании на программу (3.2) [из 2.3 ГОСТ 19.301-79]
При проведении испытаний функциональные характеристики (возможности) программы подлежат проверке на соотвествие требованиям, изложенным в п. «Требования к составу выполняемых функций» технического задания.
Подлежат проверке требования, результат выполнения которых можно взвесить, измерить, посчитать. Выполнение многих требований бывает очевидно. Например требование «Программа должна обеспечивать свое выполнение под управлением операционной системы такой-то». Развернутый перечень требований предъявлять не обязательно, поскольку техническое задание входит в состав программных документов, предъявляемых для проведения испытаний. Но желательно.
Требования к программной документации
В разделе «Требования к программной документации» должны быть указаны состав программной документации, предъявляемой на испытания (4.1), а также специальные требования, если они заданы в техническом задании на программу (4.2) [из 2.4 ГОСТ 19.301-79]
Состав программной документации должен влючать в себя:
В подраздел следует вставить содержание п. «Предварительный состав программной документации» технического задания. Что и сделано.
Средства и порядок испытаний
В разделе «Средства и порядок испытаний» должны быть указаны технические (5.1) и программные средства, используемые во время испытаний (5.2), а также порядок проведения испытаний (5.3) [из 2.7 ГОСТ 19.301-79]
Технические средства, используемые во время испытаний
В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:
Испытания проводятся на технических средствах, перечень которых следует позаимствовать из подраздела «Требования к составу и параметрам технических средств» технического задания. Испытания проводятся с использованием программных средств, состав которых приведен в подразделе «Требования к программным средствам, используемым программой» технического задания. Должна, очевидно, иметь место и разработанная программа.
Программные средства, используемые во время испытаний
Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы. Допускается использование пакета обновления такого-то.
Для проведения испытаний предоставляется инсталляционная (установочная) версия разработанной программы.
Порядок проведения испытаний
Испытания должны проводиться поэтапно согласно п. «Перечень этапов испытаний» настоящего документа.
Условия и порядок проведения испытаний
Условия проведения испытаний
Испытания должны проводиться в нормальных климатических условиях по ГОСТ 22261-94. Условия проведения испытаний приведены ниже:
Условия начала и завершения отдельных этапов испытаний
Необходимым и достаточным условием завершения 1 этапа испытаний и начала 2 этапа испытаний является успешное завершение проверок, проводимых на 1 этапе (см. п. «Перечень проверок, проводимых на 1 этапе испытаний»).
Условием завершения 2 этапа испытаний является успешное завершение проверок, проводимых на 2 этапе испытаний.
Ограничения в условиях проведения испытаний
Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
Требования к техническому обслуживанию
Требования к техническому обслуживанию не предъявляются.
Бензином, соляркой программу заправлять не надо, масло менять не надо.
Меры, обеспечивающие безопасность и безаварийность проведения испытаний
При проведении испытаний заказчик должен обеспечить соблюдение требований безопасности, установленных ГОСТ 12.2.007.0-75, ГОСТ 12.2.007.3-75, «Правилами техники безопасности при эксплуатации электроустановок потребителей», и «Правилами технической эксплуатации электроустановок потребителей».
Поскольку (согласно подразделу «Виды испытаний» технического задания) испытания проводятся на объекте заказчика, заказчик должен обеспечить соблюдение мер безопасности.
Порядок взаимодействия организаций, участвующих в испытаниях
Исполнитель письменно извещает заказчика о готовности к проведению приемо-сдаточных испытаний не позднее чем за 14 дней до намеченного срока проведения испытаний.
Заказчик Приказом назначает срок проведения испытаний и приемочную комиссии, которая должна включать в свой состав представителей заказчика и исполнителя.
Заказчик письменно извещает сторонние организации, которые должны принять участие в приемо-сдаточных испытаниях.
Заказчик совместно с исполнителем проводят все подготовительные мероприятия для проведения испытаний на объекте заказчика, а так же проводят испытания в соответствии с настоящей программой и методиками.
Заказчик осуществляет контроль проведения испытаний, а также документирует ход проведения проверок в Протоколе проведения испытаний.
Требования к персоналу, проводящему испытания
Персонал, проводящий испытания, должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).
Методы испытаний
В разделе «Методы испытаний» должны быть приведены описания используемых методов испытаний (6.1). Методы испытаний рекомендуется по отдельным показателям располагать в последовательности, в которой эти показатели расположены в разделах «Требования к программе» и «Требования к программной документации».
В методах испытаний должны быть приведены описания проверок с указанием результатов проведения испытаний (6.2) (перечней тестовых примеров (6.2.1), контрольных распечаток тестовых примеров (6.2.2) и т.п.) [из 2.8 ГОСТ 19.301-79]Сведения о методах проведения испытаний изложены в документах Приложение А и Приложение Б.
Приложения
В приложение (7) к документу могут быть включены тестовые примеры, контрольные распечатки тестовых примеров, таблицы, графики и т.п. [из 2.9 ГОСТ 19.301-79]
Приложение А
Методы проведения проверки комплектности программной документации
Проверка комплектности программной документации на программное изделие производится визуально представителями заказчика. В ходе проверки сопоставляется состав и комплектность программной документации, представленной исполнителем, с перечнем программной документации.
Проверка считается завершенной в случае соответствия состава и комплектности программной документации, представленной исполнителем, перечню программной документации, приведенному в указанном выше пункте.
Протокол испытаний – п. 7 РД 50-34.698-90.
Методы проведения проверки комплектности и состава технических и программных средств
Проверка комплектности и состава технических и программных средств производится визуально представителем заказчика. В ходе проверки сопоставляется состав и комплектность технических и программных средств, представленных исполнителем, с перечнем технических и программных средств, приведенным в Табл Х настоящего документа.
Комплектность системного блока, входящего в состав технических средств, может производиться по бланку заказа, если системный блок опечатан производителем или продавцом. Комплектность программных средств проводится также визуально. Загрузилась операционная система, высветился логотип, версия – соответствует/не соответствует заявленной в техническом задании.
Проверка считается завершенной в случае соответствия состава и комплектности технических и программых средств, представленных исполнителем, с перечнем технических и программных средств.
Приложение Б
Руководство оператора должно содержать подробные сведения о реализации всех функций программы. Чтобы не копировать указанные сведения в настоящий документ, достаточно ограничиться ссылками на подразделы Руководства оператора.
Методы проверки выполнения функции создания нового (пустого) файла
Проверка выполнения указанной функции выполняется согласно п. «Выполнение функции создания нового (безымянного) файла» руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Формализованное изложение («указанной», «данному» и пр.) позволяет копировать все три абзаца из подраздела в подраздел, меняться будет только номер подраздела руководства оператора.
Методы проверки выполнения функции открытия (загрузки) существующего файла
Проверка выполнения указанной функции выполняется согласно п. «Выполнение функции открытия (загрузки) существующего файла» руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Проверка выполнения указанной функции выполняется согласно п. «Выполнение функции редактирования текущего файла путем ввода, замены, удаления содержимого файла с применением устройств ввода» руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Методы проверки выполнения функции редактирования текущего файла с применением буфера обмена операционной системы
Проверка выполнения указанной функции выполняется согласно п. «Выполнение функции редактирования текущего файла с применением буфера обмена операционной системы» руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Методы проверки выполнения функции сохранения файла с исходным именем
Проверка выполнения указанной функции выполняется согласно п. «Выполнение функции сохранения файла с исходным именем» руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Методы проверки выполнение функции сохранения файла с именем, отличным от исходного
Проверка выполнения указанной функции выполняется согласно п. «Выполнение функции сохранения файла с именем, отличным от исходного» руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Методы проверки выполнения функции отправки содержимого текущего файла электронной почтой с помощью внешней клиентской почтовой программы
Проверка выполнения указанной функции выполняется согласно п. такому-то руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Методы проверки выполнения функции вывода оперативных справок в строковом формате (подсказок)
Проверка выполнения указанной функции выполняется согласно п. такому-то руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Методы проверки выполнения функции интерактивной справочной системы
Проверка выполнения указанной функции выполняется согласно п. такому-то руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Методы проверки выполнение функции отображения названия программы, версии программы, копирайта и комментариев разработчика
Проверка выполнения указанной функции выполняется согласно п. такому-то руководства оператора.
Проверка считается завершенной в случае соответствия состава и последовательности действий оператора при выполнении данной функции указанному выше подразделу руководства оператора.
Вот, собственно, и вся Программа и методики испытаний.
Выводы
Программа и методика испытаний, разработанные согласно требований ГОСТ 19.301-79 – программный документ, достаточный (в целом) для проведения испытаний программных изделий.
В то же время программа и методики испытаний (компонентов, комплексов средств автоматизации, подсистем, систем) согласно п. 2.14. РД 50-34.698-90. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ – документ, который можно считать «всеобъемлющим». Автор(ы), при разработке программы и методики испытаний, рекомендует обращаться именно к указанному выше документу.
Copyright © «Техническая документация» 2008-2021. Заимствуйте наши материалы с блеском! При воспроизведении материалов портала обязательна установка активной гиперссылки на источник — страницу с этой публикацией на tdocs.su.
Корпоративный троллинг — 3, или сдача работ без лишних забот
В предыдущих статьях (первая, вторая) мы бегло и в шутливой форме прошлись по примерам противодействия, которое оказывают нам сотрудники заказчика на различных этапах проекта. Сегодня предметом рассмотрения будет сдача работ, и мы подойдем к этому этапу во всеоружии, чтобы ни один тролль не прорвался. Получилось много букв, но, надеюсь оно того стоит.
Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.
Процесс приемо-сдаточных испытаний должен быть строго формализован. Всем понятно, что в конце этого процесса должен появиться протокол и акт, на основании которого выпускается приказ о переводе системы в опытную или промышленную эксплуатацию. Акт также является формальным поводом для выставления счета на оплату очередного этапа проекта.
В этой статье я без лишних шуток (какие уж тут шутки!) и максимально последовательно (ну, для блога, конечно) опишу процесс сдачи проектных работ. Разумеется, многие вещи опытным коллегам покажутся очевидными. Пусть. Зато менее опытные коллеги или желающие примерить ответственную роль сдающего на себя найдут эту публикацию полезной и познавательной.
Направления троллинга в ходе испытаний
Программа и методика испытаний
Документ ПМИ, или программа и методика испытаний, на мой взгляд, более важен, чем даже ТЗ. От качества этого документа зависит половина, если не две третьих успеха испытаний.
Протокол испытаний
На основе тестов ПМИ вы должны подготовить протокол испытаний. Протокол будет являться документом, подтверждающим то, что ваша система выполнена в соответствии с ТЗ, о чем делается соответствующая запись в акте. Не доверяйте подготовку протокола никому другому, если не хотите иметь бледный вид перед комиссией. Обычно протокол является «копипастом» из ПМИ, так что его подготовка много времени у вас не займет.
Протокол испытаний состоит из общей части, таблицы тестов и списка замечаний.
Генеральная репетиция
Без нее нельзя. Только так вы можете отловить все шероховатости в тестах, выявить тесты, крадущие время и тесты, результаты которых сомнительны. Помните, что визуальная составляющая должна быть безупречна. Постарайтесь забить в систему данные, которые выглядят натурально и похожи на то, с чем имеет дело клиент. Проследите, чтобы имена пользователей и другие поля не содержали ненормативную лексику (любимая шутка внедренцев и программеров). Эти «шуточки» иногда действуют на комиссию как красная тряпка на быка.
Не бойтесь переписать ПМИ с нуля. Один раз мы пожалели время и перекомпоновали тесты вместо того, чтобы переписать их. В итоге мы просто успокоили сами себя, не изменив общей плачевной картины. За что и огребли.
Если вы сдаете вдвоем, гоняйте тесты вместе. Приглашайте коллег, пусть они придираются, изображая из себя комиссию. Потраченное на эти игры время в итоге позволит всем вам получить деньги от довольного заказчика.
Эффективный дуэт
Оптимальной командой для сдачи является пара из внедренца (или программиста) и бизнес-аналитика (консультанта).
Точно так же, если консультант скажет глупость, а заказчик нахмурится в ответ, программист может с лицом оскорбленной невинности продемонстрировать очередную фишку системы и тогда заказчик проникнется к нему симпатией, так как поймет, кто тут настоящий профи, а кто клоун в галстуке.
В особенно напряженные моменты можно устроить дружескую перепалку, разрядив тем самым обстановку и отведя внимание аудитории от не совсем корректной работы системы.
Не зря же западные «айтишные евангелисты» любят работать парами.
Процесс пошел!
Когда вы приступили к испытаниям, не смейте лезть в систему сразу! Постарайтесь пройти сначала всю формальную часть. Сверьте коды документации, носителей информации, откройте ТЗ, положите на стол Руководство пользователя. Пройдитесь по нефункциональным требованиям. ОС Windows — галочка. Поддерживаемые версии браузеров — раз, два, три, галочка. Язык разработки, архитектура, база данных, да мало ли что там в ТЗ понаписано! Все нужно показать в документации. Хотя бы там всего лишь одно предложение, оно обязано там быть! Не пренебрегайте этой бюрократией, тролли только этого и ждут. Вам хочется получить в протоколе, что «Исполнитель не продемонстрировал, что язык java является кроссплатформенным языком высокого уровня. Требования ТЗ 1.2.3 и 3.2.1 не выполнены»? А ведь это не придуманный маразм, это сама жизнь.
Когда вы закончили с формальной стороной дела, тоже не спешите лезть в систему! Следующая группа тестов заключается во включении монитора и демонстрации рабочего стола, иконок и запуска программы (если запуск нужно тестировать). Вход в систему с неправильным паролем, галочка, вход с правильным — опять галочка, галочка, галочка. Меню — эка невидаль! Главная форма, список чего-нибудь. Галочка.
Когда дойдет дело до нажатия кнопок в системе, комиссия уже порядком устанет и проголодается. А вы в первый день сможете проскочить, к примеру, основные справочники и базовые функции. А на другой день оставить бекапирование, администрирование и еще какую-нибудь ерунду.
Замечания
Они будут, можете не сомневаться. Нет такой системы, к которой не было бы замечаний. Ваша задача — заставить заказчика поделить все замечания на критические и не критические. Первые должны быть исправлены для успешного перевода в опытную эксплуатацию. Вторые могут быть исправлены в ходе опытной эксплуатации. Соответственно, лучше, чтобы первых вообще не было или были только те, исправить которые не представляет особого труда.
Когда заказчик делает замечание, вы фиксируете его формулировку в протоколе. Обязательно проговорите записанные слова, убедитесь, что вы друг друга поняли. Будет лучше, если в ходе испытаний будет работать диктофон. Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть, было понятно, что нужно сделать, чтобы замечание было снято. Слов «все», «ничего», «каждый», «любой», а также неизмеряемых качественных оценок «плохо», «медленно», «слишком быстро» и т.п. в замечании быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отображаться в течении 5 сек». Если «символы на схеме плохо различимы», то должно быть написано «увеличить символы на схеме до 18 пунктов». И так далее.
Конкретизация позволит минимизировать возможность необоснованного перетаскивания того или иного замечания в ранг критического. Заказчик может утверждать, что отработка запроса за 6 секунд для него неприемлема, а за 5 секунд — в самый раз. Пусть это появится в протоколе! Но что-то мне подсказывает, что не появится. Или замечание будет признано некритическим.
Все замечания, признанные критическим фиксируются в акте: «Комиссия постановила, что система соответствует ТЗ и рекомендует принять ее в опытную эксплуатацию при условиях отработки следующих замечаний. » При этом список некритических замечаний лучше непосредственно в акт не включать. Их обычно много и они могут напугать ответственного сотрудника, ставящего подпись. Если заказчик беспокоится, что вы не будете отрабатывать некритические замечания, успокойте его при помощи документа «Методика проведения опытной эксплуатации», котрый настоятельно рекомендуется подготовить. Там вы в простой и доступной форме должны описать как будет проходить опытная эксплуатация, как будут отрабатываться найденные баги и как будет заполняться журнал опытной эксплуатации, являющийся гарантом безболезненного окончания ОЭ, ввода системы в промышленную эксплуатацию и салюта с шампанским по причине окончания проекта.
Что делать, если все пропало
Когда вы понимаете, что испытания идут неудовлетворительно, система безобразно глючит, а заказчик уже исчерпал запас ругательств, не нужно сдаваться! Караван должен продолжать идти вперед, будет новый релиз, новые испытания. И даже если проект будет завален, ничего в этом страшного для вас нет. В условиях острого дефицита толковых исполнителей вы быстро найдете работу, тем более, что я бы на вашем месте не стал бы работать в компании, допускающей подобные ситуации.
Чтобы не терять время в бесплотных препирательствах, я бы рекомендовал применить тактику «бей своих, чтобы чужие боялись». Начните вместе с заказчиком ругать «этих криворуких программеров», «жадное руководство», а когда накал страстей уменьшится, предложите заказчику собрать максимум багов «этого глюкалова», чтобы показать этим нехорошим людям какие они нехорошие.
Тогда активные сотрудники заказчика во главе с троллем-киллером начнут собирать баги и радостно наполнять протокол сотнями замечаний. Фактически, за свои собственные деньги они проведут вам высокоуровневое функциональное тестирование, на которое, судя по результатам испытаний, ваши разработчики так и не сподобились.
По хорошему, описанной безобразной ситуации вообще быть не должно. Но проектный бизнес отличается иногда странными флуктуациями, когда первый прототип пытаются сдать как полноценную систему, начальство врет подчиненным и самим себе, все вокруг делают хорошую мину при плохой игре и уверяют друг друга в обязательном и непременном успехе.
Вторым советом в подобной ситуации было бы, как я уже говорил, сразу уволиться из конторы, допускающей подобные «косяки». Потому что по всем меркам настоящему профессионалу не стоит портить свою репутацию подобным образом.
Заключение
Итак, коллеги, на этом я спешу завершить трилогию о корпоративных троллях, которых не нужно бояться, а нужно уважать и даже некоторым образом любить, так как они не дают ленивым обезьянам ИТ бизнеса падать от обжорства с деревьев, держат нас в тонусе и даже привносят некоторый интерес в безумно скучные, но крайне необходимые проектные работы.
UPD от 23.06.2011. Пользователь igendo добавляет в комментариях, что неплохо бы уже на этапе заключения договора утвердить формы официальных документов проекта.
Добавлю, что очень помогает в работе, когда формы актов, протоколов и прочих формальных документов зафиксированы в контракте. Дабы не было необходимости их предварительно согласовывать, пересогласовывать и переделывать\переподписывать в середине проекта.
От себя тоже могу добавить, что в совсем уж тяжелых и масштабных проектах принято составлять устав проекта, некий документ о глубинном смысле которого можно говорить часами. Там, кроме всего прочего, можно обговорить и формы документов проекта, и процедуры контроля хода проекта, и высокоуровневые бизнес-задачи. Но это, опять же, тема для другого поста.
Пользователь ЖЖ ryzhij_papa Добавляет, что существует практика ранжирования замечаний по степени их влияния на бизнес, методика ранжирования также заносится в ПМИ.
Нужно формально описать что является замечаниями крического, высокого, среднего и низкого приоритета. Описание делается в терминах бизнеса. Если утрировать, то так: критический приоритет при потере 1000$, высокий если 100$, средний когда сотрудники в мыле, но убытков у нас нет, низкий — возможны случаи легкого умопомрачения на 5-6 году жизни с такой багой.