КаБа

Мы знаем, что есть вот такая шикарная диаграмма: В моих словах нет иронии, она действительно очень хороша с точки зрения структурирования видов требований, которыми оперирует аналитик, и определения их взаимосвязи. Более того, эта картинка является прекрасным примером того, что продуманная мысль неминуемо может найти свое лаконичное отображение на бумаге. Однако приходится сталкиваться с коллегами, которые принимают эту диаграмму за некоторую модель разработки требований и пытаются найти ей прямое применение в проектной деятельности, что иногда приводит к печальным последствиям. Почему? Попытаюсь объяснить. Знать эту диаграмму мало. Дело в том, что требования представляют собой текстовую / графическую модель проектируемой информационной системы (ИС). Помня, какие виды требований бывают, но не помня, что такое информационная система, довольно проблематично сформулировать все требования, которые необходимы для того, чтобы их совокупность стала моделью проектируемой ИС. Т.е....

Раньше, когда доходило дело до разговора об управлении качеством, я всегда терялся. Для меня качество системы и количество найденных баг (или баг, дошедших до прода) были абсолютными синонимами. Но теперь, когда с управлением качеством я столкнулся самым непосредственным образом и при этом вспомнил, что качество системы определяется не только качеством кода, а еще и полнотой ее обеспеченности и качеством видов обеспечения , у меня получилась некоторая модель того, как в треугольнике цена – сроки – качество управлять ценой и сроками путем манипуляций с качеством системы.

Я тут какое-то время назад попытался высказать свое отношение к качеству заказных информационных систем , но в силу ряда причин хочется эту тему немного развить. В двух словах качество ИС – это степень ее соответствия целям Заказчика, а соответственно – его ожиданиям и потребностям. Эти ожидания и потребности удовлетворяются не только функциональными возможностями продукта и совсем не его техническим качеством. В этом проявляется инвариантность качества: тот факт, что продукт совершенно идеально прошел тестирование и ни одной баги не вернулось с прода совсем не говорит о том, что продукт качественный. Легко может получиться так, что методология использования продукта не учитывает специфику процессов Бизнеса, в связи с чем использование продукта попросту не удобно. И Бизнес совершенно справедливо будет говорить о низком качестве ИС. Ему, Бизнесу, совершенно по барабану, сколько багов осталось в финальном билде, добравшемся до прода. Ему важно, чтобы продукт помогал достичь те цели, ко...