Comments 22
А что именно предлагается?
Отказаться от документации по продукту, который был разработан под одну уникальную задачу?
Или таки улучшить каким-то образом качество выходной документации?
Документация — моя профессия, я не могу себя ее лишать. Речь идёт не просто об улучшении, а об изменении порядка качества. В целом, об изменении отношения к документации.
Много работая в данной сфере, я попытался сформулировать текущую ситуацию. Чтобы вылечить человека, надо чтобы он понял, что он болен. Чтобы захотел изменить ситуацию. Чтобы заказчик захотел получить не объем макулатуры а то, что ему поможет при работе с системой.
А можете, пожалуйста, примеров привести?
Вы не понимаете зачем нужна документация ПМИ? Или не можете автоматизировать создание паспорта системы?
Тут встает вопрос этики. Но, работая в этой сфере (госы) более 20 лет, могу сказать, что случаи, когда документацию по системе можно оценить хотя бы на три балла (из пяти) крайне редки. Если Вы скажете, что Ваш опыт говорит об обратном, я буду счастлив и скажу, что хочу в Советский Союз.
ПМИ — это как раз пример документа, который очень часто делают для галочки — своеобразный чек-лист, который надо сначала убедить заказчика принять, а потом убедить расписаться в каждом квадратике. Потому что любая сложная информационная система содержит разноаспектные требования. Задача разработать методику, которая позволит их действительно проверить и потом не допустить регресса информационной системы при эксплуатации и развитии — уж точно не простая.
Что такое автоматизировать создание паспорта — не совсем понял.
ПМИ все же не гарант отсутствия регрессий, это неверное толкование. ПМИ должна, и вроде у нее получается, гарантировать работоспособность сдаваемой заказчику версии ИС согласно требований заказчика. Или как предлагается это делать иначе?
Не совсем понимаю. Скажем, в моменте система работает. А через неделю (или, скажем, через час), когда в нее внесут правки пусть функции отваливаются? Или испытания — это способ убедиться, что мы, наконец, поняли, что хочет Заказчик? Т.е. после ввода системы в постоянную эксплуатацию ПМИ архивируем для Счётной палаты?
О каких правках идёт речь? Изменения функционала — суть изменения ТЗ и должны разрабатываться, сдаваться и приниматься потребителем явно.
А если система валится от пользовательского ввода — это не проблема процесса ведения документации, это другая проблема.
Мне кажется, устойчивость к регрессам — важный аспект системы. И желательно, чтобы он проверялся и при создании, и при доработке информационной системы.
Скажем, нужно добавить проверку для формочки. Вполне логично, если ПМИ будет содержать проверку на наличие регрессионного теста, и вполне логично проверить, чтобы тест срабатывал успешно. В более сложных случаях нужно что-то еще придумывать. Хотя употребленное Вами слово "работоспособность" вполне хорошее, я бы его заменил на "качество".
Нет, увы. Устойчивость к регрессам — не фича в общем смысле. Вы можете создать или заказать ИС, устойчивую к регрессам и такую устойчивость можно даже, наверняка, математически доказать.
В общем же смысле, ИС любого прикладного назначения, включающая в себя АРМ и живого человека в роли оператора, за АРМ сидящего, не может быть "сама по себе" устойчива к регрессу, да ей и не надо. Потому что заказывая доработку "валидация формы" Вы вносите изменение в существующее ТЗ на систему. Предполагается, что исполнитель снимет с Вас требования, отразит в ТЗ и обновит сообразным образом ПМИ и прочую документацию по ИС. И по итогу разработки это будет уже новая версия ИС, которую, опять таки, надо принять в соответствии с ПМИ.
Если же вы приняли ИС и пакет сопроводительной документации, ввели ее в эксплуатацию, а затем попросили инженера Васю "быстренько воткнуть вот сюда проверку введенного значения", реализация которой привела к таймаутам на интерфейсах АРМ из-за дурацких и тяжелых запросов к БД — это не проблема "забюрократизированности" подхода или "тяжести" документации. Это другая проблема.
В рамках испытаний проверяются не только функциональные фичи. Поэтому и ПМИ должна содержать методику проверки не только фич. Наличие документации является фичей? Соответствие требованиям ИБ является фичей? Лицензионная чистота является фичей? Инфраструктура развертывания является фичей?
В примере с Васей Вы предлагается ввести обязательное требование, чтобы все фичи реализовывались долго? Если так, их тоже надо проверять в рамках испытаний. Например, в ПМИ можно ввести пункта: С момента появления требования до его реализации должно пройти не менее 20 рабочих дней. Проверить очень легко. Если сделали быстрее, испытание не считается пройденным.
Мне кажется, Вы возводите один конкретный документ — ПМИ в данном случае — в абслют. Да, в рамках ПМИ принимаются не только фичи, но и комплектность системы (в т.ч. документации), а так же могут проверяться такие вещи как квалификация операторов и выполнение развертывания согласно проекту. Но не надо тащить в ПМИ процесс, для этого есть другие хорошие документы и регламенты.
И про "долго" речи тоже не шло. Если выполнение процесса, предусматривающего помимо поставки кода поставку бумаги — долго, это не проблема бумаги. Это другая проблема.
ГОСТ 34, вокруг которого весь сыр-бор чрезвычайно зануден, дотошен и громоздок для любого, кто попытается применить его ради применения стандарта. Причем степень его занудности зачастую ниже, чем, например, степень занудности общеотраслевых стандартов типа ITIL. Все же, применять стандарты к себе и у себя нужно для удовлетворения своим внутренним требованиям в первую очередь, а не ради удовлетворения стандарта. Иначе можно и лоб расшибить. Но это все равно не проблема стандарта. :)
Я действительно выделяю ПМИ среди прочих документов. И изучение любой новой системы начинаю с ПМИ. Это важнейший инструмент обеспечения качества продукта. Не формальный, творческий. В него надо включать не всё подряд, а именно то, что важно. Но!!! всё, что важно, в него нужно включить)) Да еще необходимо включить так, чтобы заказчик понял всё, что написано. Включим лишнее — получим бюрократию. Не включим важное — можем получить некачественный продукт. Сделаем документ непонятным — получим никому не нужную формальную процедуру испытаний.
И, честно говоря. Ни разу в жизни у меня не получилось ПМИ, которым был бы доволен:)
2. Если кто-то неверно оформил, то он и виноват :-)
3. Нет такого.
4. Зависит от конкретного случая. В сложных случаях без разраба не разобраться. Документация содержит, то что нужно заказчику. Документация для себя не ведется(исходник и есть документация :-)).
Для очередного Angry Birds стартапа этот документ — «макулатура», для гос структуры он стоил пройгрыш в выборах.
теме оформления результатов создания ИТ-продуктов для органов государственной власти и крупных корпораций
Вот скажите, а что вы там ловите и на что надеетесь?) Даже эта фраза уже звучит настолько зашкварно, что сразу понятно, что никакого проф развития, адекватных вызовов или интересной работы в этой сфере не будет.
Тут скорее вопрос не к тем, кто это все требует, а к Вам, автор. Зачем пошли в такую сферу, если монотонная размеренная и бесполезная работа Вам не по душе? Возможно, кто-то другой, был бы счастлив. Я сам офигеваю, но общался с людьми, которым в кайф делать монотонную бюрократическую работу, находить свой ритм, и чуть ли не медитировать при этом
Так я ж, говорит, о другой мечтал… А исполнилась вот такая.
Если серьезно, то вопрос терапевт/хирург будет существовать всегда. Думаю, в данном случае ситуация улучшаема терапевтически. Решать ее необходимо одновременно на разных уровнях: организационном, нормативном, технологическом и даже рекламном. Мне ближе технологический писал об этом здесь. Сейчас работаю над конвертером asciidoc -> odt. Это, думаю, сильно упростит ситуацию. Есть вот такой замечательный абсолютно работающий проект. Ловить, в общем, есть что. Но надо работать
К СПДС отношение гораздо лучше, чем к программной документации. Она лучше формализована (здание в отличие от программы можно потрогать). Проблема именно с программной документацией (не важно, ГОСТ 19, ГОСТ 34) заключается в том, чтобы она сохраняла актуальность на всём этапе жизненного цикла программного продукта. Очень многие заказчики этого не понимают, а разработчики в этом просто не заинтересованы.
Бюрократизация IT