Качество начинается с определения требований

Дугласс Т. Росс

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

Жизненный цикл системы. Как надо измерять качество программного обеспечения? С чем его можно сравнивать? Как, в самом деле, это качество можно „обеспечить“ в той же мере, в какой „управление качеством“ и „обеспечение качества“ являются стандартными чертами каждого развитого процесса? Все это — новая категория вопросов и проблем, стоящих перед программным обеспечением. Только теперь, когда методологии проектирования и производства программного обеспечения становятся систематизированными, на эти вопросы можно искать ответ.

Рис. 1 (взятый из [5]) показывает, что идеальная системная технология может выступать как безупречный посредник, позволяющий строить идеальную систему, которая дает совершенное решение, удовлетворяющее данному множеству требований.

Рис. 2 (из того же источника) показывает, что наша реальная системная технология имеет несовершенства, не позволяющие осуществить безупречное распознавание и перевод требований к системе в совершенные решения. Эти несовершенства (см. рис. 2) влияют на создание нашей (неидеальной, несовершенной) системы, допуская нежелательный „шум“ на входе и потерю некоторых важных факторов. Эти несовершенства влияют также на передачу решения, вызывая потерю некоторых его возможностей и искажение результатов, приводящее к нежелательным эффектам. Таковы реальные жизненные факты, определяющие с абсолютной неизбежностью качество программного обеспечения, даже если само понятие этого качества относительно.

Рис. 3 является развитием одной иллюстрации из [6] и показывает базисную структуру жизненного цикла системы. В указанной статье нам важны в первую очередь ПОЧЕМУ, ЧТО и КАК создания систем. А именно, при распознавании проблемы выясняется, ПОЧЕМУ необходимо решение, спецификация системы средствами функциональной архитектуры говорит, ЧТО должна делать система, а проектирование, ведущее к системной архитектуре, определяет, КАК должно быть достигнуто решение. Как показывает рис. 3, за этим следует фактическое построение и использование системы; полученные результаты могут быть затем проинтерпретированы, а их значения подвергнуты оценке. Любые несоответствия ведут даже к распознаванию новой видоизмененной проблемы, что вызывает выполнение следующего цикла.

Статья была, опубликована, в Трудах рабочей конференции Международной федерации по обработке информации. 1978, том 2, Новосибирск. С. 132-139.

Рис. 1. Построение идеальной системы

Рис. 2. Построение реальной системы

Каждое из рассматриваемых действий (распознавание, анализ, проектирование, использование, интерпретация) и объектов (проблема, функциональная архитектура, системная архитектура и значения) обнаруживает при исполнении или представлении свои, внутренне им присущие несовершенства. Последние вызывают отклонение от идеала, представленного на рис. 1 и 2. Некоторые из них могут не иметь последствий, а другие — оказаться серьезными. Жизненный цикл на рис. 3 применим к любым системам, как большим, так и малым. Насколько важными оказываются несовершенства в неидеальной системной технологии, используемой для реализации проблемы, — это зависит от самой проблемы.

Рис. 3. Жизненный цикл системы

Нужны порядок и стабильность. Для того чтобы вообще можно было разумным образом иметь дело с вопросами качества, надо, чтобы каждая сторона жизненного цикла системы базировалась на некоторой упорядоченной, контролируемой и дисциплинированной методологии. Это не означает, что все программное обеспечение надо производить с помощью одних и тех же средств и методов, так как это требование явно было бы чрезмерным. В случае запуска на Луну или управления такой системой реального времени, которая может поставить под угрозу человеческие жизни, строгость и тщательность будут гораздо более основательными и дорогостоящими, чем в случае одноразового, не влекущего последствий лабораторного эксперимента. Но все же в любом случае вопрос о качестве возникает. Этот вопрос нельзя даже поставить, не говоря о том, чтобы ответить на него, если используемый метод построения не является всегда упорядоченным, контролируемым и дисциплинированным. Имеется широкий спектр приближений к идеальной системной технологии, но даже самые упрощенные, прямолинейные методологии должны быть полными и непротиворечивыми. Каждая версия должна (в каком-то разумном смысле) быть вырожденной по отношению к совершенному, наиболее развитому состоянию методологии и получаться огрублением последнего в расчете на более простую обстановку.

Определение требований — исходная точка для качества Жизненный цикл системы начинается с определения требований, связанных с вопросами: ПОЧЕМУ, ЧТО и КАК. В [6] сказано: „Определение требований должно иметь дело с тремя вещами:

• (1)    Контекстный анализ; он выясняет, почему надо создавать систему, и почему те или другие технические, операционные и экономические критерии служат для системы граничными условиями.

• (2)    Функциональная спецификация; она описывает, что должна делать система в терминах выполняемых системой функций. Будучи частью задания системы, она должна только поставлять граничные условия с тем, чтобы решения по ним принимались впоследствии — при проектировании системы.

• (3)    Проектировочные ограничения; это совокупность условий, определяющих, как должна быть построена и реализована искомая система. При этом не обязательно специфицируется содержимое системы, а лишь определяются, граничные условия, с помощью которых можно впоследствии выбрать или создать это содержимое. “

Каждый из этих трех аспектов надо в ходе Определения требований полностью документировать. В любом случае, наши ПОЧЕМУ, ЧТО и КАК твердо устанавливают граничные условия, которым должны будут удовлетворять дальнейшие этапы работы с системой. Поскольку мы уже установили, что можно использовать целый спектр полных и непротиворечивых методологий, то, как мы полагаем, основной тезис этого выступления ясен и приемлем. Этот тезис состоит в следующем:

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

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

Управление качеством и обеспечение качества. Важно понять, что качество связано не с самим тестированием, а с оценкой его результатов. Таким образом, исходя из представленной здесь точки зрения, разработка и исполнение тестов (или задание и проверка некоторых утверждений) рассматриваются как составная часть процесса построения системы. Обеспечение качества состоит в формальном накоплении соответствующих тестов и оценке их результатов. Усиление же такого надзора и перестройка процессов (или же отбрасывание, переделка или снижение уровня результатов в зависимости от исхода тестов) есть управление качеством.

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

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

Качество программного обеспечения, однако, не то же самое, что качество аппаратуры или каких-то материальных вещей, так как в нем нечему износиться или сломаться. Поэтому вопросы качества программного обеспечения зависят почти полностью от применимости вопросов и утверждений разного рода, сводящихся в конечном счете к некоторому общему базису — адекватности символических или числовых представлений соответствующих физических реальностей. В этом смысле вопросы качества программного обеспечения гораздо более тонки и трудны, чем в случае материальных вещей, хотя здесь и нечему износиться или сломаться.

Заключение. Обеспечить качество программных систем можно только последовательным обратным просмотром (в направлении, противоположном указанному на рис. 1) на каждой стадии порождающего процесса. Каждый шаг должен быть упорядоченным, он должен быть оправдан и подтвержден спецификацией качества, наложенной исходными определениями требований. Библиография указывает на работы, описывающие такой упорядоченный подход к качественному программированию, основанный на системе SADT (Structured Analysis and Design Techniques), разработанной в фирме Софтек. Чертами системы, важными для обеспечения качества, являются строгая взаимосвязь каждой стадии и процесса и включение в каждом случае контролируемых циклов подтверждения. Любой метод, обладающий подобной же строгостью, может также дать качественное программное обеспечение. Но так как качество программного обеспечения почти целиком зависит от методологии программирования и построения систем, отсутствие такой строгости и дисциплины будет приводить к созданию программного обеспечения сомнительного качества.