Qraizer
Advanced Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Цитата: так что, заведомо известно чтО должен делать этот код раз известно
Цитата:расхождение между реальным поведением кода и поведением по требованиям |
Нет. Наличие расхождения ничего не говорит о том, что правильно. Это решаем не мы, а авторы архитектуры системы.
Формально. Заказчик оговаривает ТЗ с системными интеграторами, и те после его утверждения выпускают системные требования. Они отличаются от ТЗ всякоразными деталями, неинтересными заказчику, но существенными с точки зрения различных факторов. Например, конечной стоимостью системы. Они обычно описывают только лишь обязательные возможности и характеристики проектируемой системы и должны быть понятны потенциальному потребителю изделия (не обязательно только заказчику), чтобы он мог, просто их почитав, понять, подходит/не подходит.
Затем эти требования отдаются на растерзание инженерному составу, и тот выпускает требования верхнего уровня, которые описывают архитектуру системы в терминах узлов, компонентов, их взаимодействия итп. Т.е. это уже скелет будущей системы, где каждый компонент и узел и их взаимодействие описываются не менее детально, чем системные требования описывают изделие в целом. Эти требования обязаны полно и недвусмысленно описывать теперь уже не просто характеристки, а поведение системы при любых обстоятельствах в рамках условий эксплуатации. Они должны быть понятны любому человеку, владеющему языком изложения, например, английским, и предметной областью применения системы, например, инженеру по радиоэлектронным коммуникациям, если речь идёт о радиоточке в кабине пилота.
Далее эти требования направляются персоналу следующего уровня, и те выполняют детальную проработку архитекутуры, фактически делая из скелета готовое изделие. Так получаются требования нижнего уровня, детально описывающие все нюансы дизайна системы. Логика, описываемая в них, не обязаны быть понятной кому бы то ни было, т.к. тут это не требуется. Требуется - по-прежнему полное и непротиворечивое описание поведения, но язык предметной области не обязан быть понятен кому-либо, кроме специалистов-технологов. Вот им наконец-то требования попадают на реализацию.
Применительно к программным продуктам. Условно, конечно. ТЗ заказчика: "тут окошко, я там мышкой тыц, оно возьми и вот как-нибудь вот так вот сделайся". Системный уровень требований: "должно быть окно, кликабельное, с такой-то реакцией на этот клик; окно должно вмещаться в десктоп с разрешением не менее такого-то; два и более окна недопустимы, попытки создания новых их экземпляров при уже имеющемся долны передавать фокус в имеющееся" итд. Верхний уровень: "У окна должен быть стандартный заголовок и стандартное системное меню. В системном меню должны быть два дополнительных пункта ... Стандартный пункт "Развернуть" должен быть запрещён ... Меню окна должно содержать ... Клиентская область ... Пункт меню такой-то должен ... " итд итп. Нижний уровень требований: "Должна быть вызвана RegisterClass() с параметрами ... Должна быть вызвана CreateWindow() с параметрами ... если возвращаемое значение ... иначе ... ... если uMsg равен WM_LBUTTONUP ... если параметр wParam ... ... ..." итдитпидрetc. Специалист-технолог - это программист, а то и просто кодер. И он пишет код по требованиям дизайна на него.
Несоответствие в поведении - это проблема. Но как правильно, знает в лучшем случае специалист в предметной области. А зачастую и только интегратор. Так что принимать решение о правильности не может даже программист. Он не обязан понимать, что он программирует. Хотя если понимает, то это безусловно хорошо, ибо он может взять на себя некую часть работы по ревью и верификации ещё на стадии создания кода, а то и ишуки закрывать в кратчайшие сроки.
Цитата:| а вот если я дополню свою программу вычисления периметра вот такими четырьмя условиями: |
Такие требования бессмысленны. Учитывая тип данных "плавающая точка" и подавно. Поведение кода определено только для трёх точных значений с плавающей точкой и не определено для остальных значений. Формула расчёта тестируется 2-мя степами. Плюс два степа на тестирование граничных значений.
Что касается ввода/вывода, то оно, будучи выполняемо отдельными функциями, в требованиях обычно так и оформляется, мол, вызвать такую-то функцию с такими-то параметрами. Каждая из них должна иметь свои требования, и у каждой из них будет свой тест, так что тут нет необходимости их тестировать, достаточно проверить факт вызова и корректность параметров. Учитывая, что в этом фрагменте кода все параметры константны, для тестирования этого фрагмента требований требуется не более 1-го степа. Он вполне может быть совмещён с одним из предыдущих степов, тестирующих формулу.
Цитата:Ну да, очепятался. Конечно, размер окна будет разный при разных разрешениях. Ну и что?
----------
Одни с годами умнеют, другие становятся старше. |
|
Всего записей: 613 | Зарегистр. 08-08-2006 | Отправлено: 01:54 12-08-2011 | Исправлено: Qraizer, 01:58 12-08-2011 |
|
В случае с верификаторами приоткрывается новый смысл притчи.
.