[БЕЗ_ЗВУКА] С потребностями, иначе: нужды, needs, иногда говорят ещё даже «требования», но обязательно прибавляют при этом стейкхолдеров, иногда говорят требования внешних стейкхолдеров, нужды стейкхолдеров, мы будем говорить, или потребности, и собственно требованиями, или requirements, но требования требования и есть, используются две разных совершенно операции по их проверке. И они даже называются по-другому. Проверка, или verification, — это всегда требование. Мы, просто говоря, проверяем, для этого делаем испытание, работает ли целевая система, как задумано, то есть выполняет ли она своё назначение. Функция — это поведение, назначенное этой системе. Мы смотрим, вот есть система, вот она как-то работает, выполняет или не выполняет свою функцию. Смотрите, это проверка. Шёпотом скажу: за это денег не дают. Если ваша система работает, это ещё ничего не означает. Если вы проверяете, работает ли использующая система в тот момент, когда вы в её состав воткнули вашу целевую систему, запустили всё вместе, и у вас выполняет свои требования, в данном случае — потребности, на контуре использующей системы, и довольны при этом все стейкхолдеры, вот эта процедура, когда вы проверяете эту работу, она называется приёмка, или validation. Смотрите, сами объекты разные. Если вы испытываете вашу систему, испытываете утверждение, которое относится к вашей системе, вы проверяете, требованиям удовлетворяет или не удовлетворяет, это одно, это проверка. Если вы испытываете другую совершенно систему, использующую, то это приёмка. Вспомним, как мы сделали вместо свадебного лимузина катафалк. Проверка — это если мы катафалк проверили, работает ли он в стартстопном режиме, проверили, как он покрашен, проверили всё, что мы о нём думаем, мы же как-то разрабатывали его, вот он стоит уже живой, надо его испытать, работает ли он. Это проверка. Далее, мы берём использующую систему, если помните, там была свадьба, и засовываем этот катафалк в систему свадьбы, включаем свадьбу. Смотрите, не катафалк, он автоматом включится, если вы включаете всю использующую систему. Работает свадьба, и мы видим, что радости и счастья нет, есть печаль, люди смотрят на этот катафалк, печалятся. В этот момент мы понимаем, что не прошла приёмка. Дальше есть типовые ситуации с этим связанные, например, ситуация с военными. Военные не говорят, какая использующая система, они делают приёмку сами и выдают команде, которая разрабатывает целевую систему, указание, что прошла приёмка или не прошла приёмка. Каждый раз при этом команда что-то меняет, иногда по просьбе военных, иногда не по просьбе военных, но получается всегда плохо. Почему? Как мне объясняла одна из команд, военные всегда платят втрое, поэтому мы не можем отказаться от заказа, это крайне выгодные заказы. А в чём тогда проблема? Ну менять приходится пять раз. То есть мы два раза систему переделываем фактически за свои. А отказаться не можем, потому что в первый раз кажется, что это втрое. Вот эта диаграмма, которая показывает что проверка и приёмка — это вообще разные деятельности, разные процедуры, она показывает, что счастья в этом случае не будет. Вы должны подписывать любые соглашения о неразглашении, вы должны подписывать любые секретности, но вы должны понимать, где будет использована ваша система, иначе у вас счастья не будет, вы не пройдёте приёмку, и вам постоянно придётся всё переделывать. Другая ситуация — это когда у вас есть программисты, которые не интересуются, что будет с их программой, когда она будет работать у клиента. Клиент же, его не интересует программа как таковая, потому что у клиента в этот момент потребность, чтобы программа с его сотрудниками работала и они вместе приносили какую-то непоправимую пользу всему предприятию в целом. Проверять клиент будет, как программа работает с его людьми по той пользе, которая наносится этим людям. Если вы выполнили требования, когда писали программу, или не выполнили, всегда у клиента будет способ объяснить вам, почему вы не получите своих денег. Третье: проверка лёгкая, вы запускаете систему, она работает, у неё нет тяжёлого операционного окружения, которое было бы в использующей системе, это легко обеспечить. Но клиент просто не пускает вас часто выполнить приёмку у себя путём запуска этой системы, и вам приходится делать сложные-сложные, очень дорогие испытательные стенды. В некоторых программно-технических проектах бывало, что на приёмку и проверку приходится 85 % стоимости всего проекта. Я уже говорил, что для атомной станции задвижка, та же самая задвижка, будет стоить сильно дороже, чем в нефтяном комплексе, потому что её в десять раз больше проверят. А потом её ещё будут принимать на каких-то стендах, обеспечивая то, что вся атомная станция, куда вставили эту задвижку, будет работать надёжно, бесперебойно, и главное, безопасно. То есть вы должны понимать, что проверка и приёмка — разные процессы. Проверка — это самое простое, делается инженерами. Приёмка — делается совместно инженерами и внешними представителями стейкхолдера, внешними стейкхолдерами, стоит это крайне дорого, но деньги вы получите только за приёмку. Если вы не различаете контуры использующей системы уровня системного использующей системы и целевой системы, вы никогда с этим не разберётесь, будете регулярно промахиваться мимо приёмосдаточных испытаний. Смотрите, не проверочных испытаний, а приёмка-сдаточных испытаний.