ВНЕШНИЕ СПЕЦИФИКАЦИИ ПРОЕКТА [c.114]
Какими должны быть ответственные исполнители внешних спецификаций Они не должны быть программистами, так как процесс внешнего проектирования не имеет ничего общего с составлением программ. Этот процесс больше связан с пониманием окружающей среды пользователей, их проблем и нужд, психологии связи человек — машина. Особенно важно то, что эта тенденция внешнего проекта возрастает с применением новых средств вычислений, касающихся большого круга конечных пользователей, не имеющих знаний в области вычислительного дела. [c.115]
Программисты обычно не имеют достаточной подготовки и опыта по этому виду проектирования. Они должны быть опытными в использовании языков программирования, методов организации вычислительных процессов, теории и практики компиляции, тестирования и отладки. В связи с этим было бы разумно использовать программистов в качестве проектировщиков модулей, предназначенных для средств отладки, компиляции и обнаружения ошибок, но вряд ли целесообразно поручать им разработку внешних спецификаций операционной системы, где они выступают не более чем пользователи. [c.116]
Вследствие этих трудностей и постоянного роста их значения в разработке ПО внешние спецификации проекта можно поручать для разработки такому специалисту, который должен понимать перечисленные выше области деятельности и должен быть знаком со всеми этапами проектирования и испытания ПО, чтобы понять и оценить влияние внешнего проекта на все этапы создания ПО. В качестве таких специалистов могут использоваться инженеры-экономисты по организации обработки информации, инженеры-системотехники, психологи, специалисты по исследованию операций и т. д. [c.116]
Описание внешних спецификаций. Хорошо сделанная внешняя спецификация — большой документ. Эффективным методом создания такого большого документа является принятие его иерархической организации. [c.118]
Замечания по программированию. Внешняя спецификация должна описывать продукт ПО с точки зрения пользователя и избегать ограничений внутреннего проекта. Но время от времени необходимо сообщать идеи о внутреннем проекте функции. Эта практика должна быть сведена к минимуму, но, где необходимо, этот раздел используется для сообщения информации. [c.120]
Для любой сложной функции пользователя задача об установлении соотношений между выводами и системными преобразователями и вводами способом причины и следствия — не тривиальная работа. В целом внешние спецификации описывают каждый возможный ввод в систему (как действительный, так и недействительный) и реакцию системы на каждый из входов. Внешние спецификации должны точно и полно описывать внешние интерфейсы, несмотря на то, что они практически не содержат сведений о внутреннем устройстве модулей. [c.120]
Проверка внешних спецификаций. Рассмотренные до сих пор вопросы касались интерфейса пользователь — программное обеспечение . Дальнейшие действия по проектированию должны быть сосредоточены на внешней структуре ПО. По этой причине и вследствие трудностей, предварительно обсуждавшихся при выработке качественной внешней спецификации, проверка полноты и точности внешней спецификации является крайне важной. [c.120]
Известен ряд методов проверки внешних спецификаций. Обычно эти методы не исключают друг друга и рекомендуются для последовательного использования. [c.120]
Групповой контроль специалистами. Первоначальная внешняя спецификация оценивается специалистами, ответственными за цели, архитектуру системы и подробный внешний проект. Спецификации должны сверяться с целями путем рассмотрения каждой из них и последующего определения адекватности отражения цели, в спецификациях. Подробную внешнюю спецификацию должны оценивать специалисты, отвечающие за разработку первоначального внешнего проекта, проектирование [c.120]
Прокрутка спецификаций. Эффективным методом по оценке подробной внешней спецификации являются генерации тестовых случаев и последующее использование подробной внешней спецификации для имитации поведения системы. Этот процесс оценки документов проектировщика путем выполнения ее с тестовыми случаями называется прокруткой. [c.121]
Второе правило— заморозить выход каждого процесса проектирования. Замораживание не подразумевает, что изменения не могут более производиться. Просто предполагается, что изменения должны проходить через процесс официального утверждения. Требования и цели должны быть заморожены после их утверждения. Внешние спецификации необходимо заморозить после того, как они пройдут стадию верификации. [c.122]
Этот процесс необходим только при проектировании систем, но не при проектировании отдельных программ, т. е. если внешние спецификации описывают систему ПО то следующим шагом построения является разработка архитектуры, за которым следует процесс построения структуры программы. Если внешние спецификации описывают программу, то разработка архитектуры не производится. [c.126]
Внешнее проектирование модулей. Начальным шагом в проектировании модуля является определение его внешних характеристик. Эта информация содержится во внешней спецификации модуля, которая включает все данные, необходимые для модулей, вызывающих данный модуль. В особенности необходимо отметить, что внешняя спецификация модуля не должна содержать указаний о внутреннем представлении данных или о логике модуля. Кроме того, недопустимо, чтобы спецификация содержала какие-либо ссылки на вызывающие модули или на контексты, в которых данный модуль используется. Допустим следующий набор информации внешней спецификации [c.141]
Внешние действия. Описание некоторых действий, принятых как внешние по отношению к программе или системе, где этот модуль вызывается. Примерами внешних действий являются печать сообщений, чтение команды, чтение вспомогательного файла (файла сообщений), выдача сообщений об ошибке. Внешние действия модуля могут включать в себя некоторые внешние действия подчиненных модулей. Например, если модуль А вызывает модуль В, а В печатает сообщение, то описания внешних действий появятся во внешних спецификациях как модуля А, так и модуля В. [c.142]
Необходимо отличать внешнюю спецификацию модуля от другой документации, такой, как описание логики модуля, так как логика модуля может изменяться без воздействия вызывающих модулей, а изменение внешних спецификаций модуля обычно приводит к изменениям в вызывающих модулях. Внешняя спецификация модуля может принимать ряд физических форм в зависимости от включения шести перечисленных выше категорий. [c.142]
Ш а г 2. Проектирование внешних спецификаций модуля. Этот процесс рассмотрен в предыдущем разделе. [c.143]
Ш а г 3. Проверка внешних спецификаций модуля. Желательно, чтобы спецификация для каждого модуля была бы проверена путем сравнения ее с информацией интерфейса, разработанного при проектировании структуры программы. Спецификация данного модуля должна быть просмотрена программистами всех модулей, вызывающих данный модуль. [c.143]
РАЗРАБОТКА ВНЕШНИХ СПЕЦИФИКАЦИЙ [c.156]
В настоящее время существует множество алгоритмов генерации тестовых последовательностей, базирующихся либо на анализе внешних спецификаций программы, либо на анализе логики программы. Это два полярных подхода, и вполне возможна некоторая их комбинация, позволяющая применительно к конкретной ситуации получить лучшие результаты. [c.165]
Исследователь, формирующий тестовые последовательности на основе анализа внешних спецификаций программы, создает свой тест, рассматривая программу как некоторый черный ящик , т. е. его не интересует собственно программа. При этом подходе считается, что если программа работает так, как предусмотрено спецификациями, то она подтверждается. Основной целью та- [c.165]
Другой подход предполагает получение тестовых последовательностей на основе анализа логики программы. Здесь задача заключается в разработке таких тестовых последовательностей, при реализации которых каждая команда программы выполняется по меньшей мере один раз. Основной целью данного метода является проверка логики выполнения всех ветвей программы. При этом тестовая последовательность генерируется без учета внешних спецификаций. [c.166]
Тестирование модуля. Целью тестирования модуля является обнаружение различий между логической схемой модуля и его интерфейсом и их внешними спецификациями. Тестирование модуля начинается после его отладки. [c.172]
Целью внешнего функционального тестирования является обнаружение противоречий между программой и ее внешними спецификациями. Предварительным условием, определяющим качественней исход функционального тестирования, являются полнота, точность и непротиворечивость внешних спецификаций. Если это условие не будет выполнено, то функциональный тест может быть реализован, но программа останется ошибочной. [c.176]
При проектировании функционального теста внешнюю спецификацию рекомендуется разделить на частные внешние функции а затем тщательно проверить каждую из. них. Для этих целей могут использоваться подходы, рассмотренные для случая тестирования единичного модуля. Они могут быть распространены на все входные условия и режимы, а также на все границы входных и выходных потоков данных. Эти способы обеспечивают также проверку программы на предмет ее поведения на функциональных границах и при появлении недействительных (ошибочных) или неожиданных данных на входе. . [c.176]
Целью системного тестирования является выявление противоречий между разработанной системой и первоначальными целями ее создания. Компонентами системного тестирования являются разработанная система ПО, конечные цели и вся документация, прилагаемая к системе. Внешние спецификации, составляющие основу функционального тестирования, при системном тестировании не играют никакой роли. [c.178]
Вероятность сбоя 18 Верификация программ 154 Внешние действия 141 Внешние спецификации 114, 115 [c.268]
Хорошее изделие может быть создано только на основании хорошего проекта, а для этого требуется хорошая документация, которая понятна разработчикам и удобна для использования в процессе проектирования. В том случае, когда проектные решения должны быть поняты большим числом людей, которые должны общаться между собой в ходе проектирования универсального программного обеспечения, качество проекта полностью определяется качеством положенной в его основу документации. Поэтому, чтобы успешно производить программные изделия, необходимо иметь полную документацию, охватывающую все аспекты их разработки. Вслед за принятием на вооружение соглашения о требованиях нужно позаботиться о том, чтобы спецификации изделия отражали потребности всех связанных с его созданием функциональных групп разработки, испытаний, выпуска документации и др. Обеспечить такое соответствие нетрудно, внедрив в практику проектирования программных изделий после соглашения о требованиях внешние спецификации, описываемые здесь достаточно подробно. [c.19]
Некоторые из вопросов, поднимаемых в фазовых обзорах, относятся к сфере текущей интерпретации предварительных соглашений. Всякое несоответствие должно устраняться по ходу его обнаружения, будь то результат проверки или обновления более ранних документов. Следует помнить, что соглашение о требованиях всегда должно правильно отражать реальную ситуацию, а внешняя спецификация должна быть в любой момент времени законченным документом, который правильно описывает, что представляет собой программное изделие. Правильное конфигурационное управление требует также, чтобы каждая существующая в данный момент времени версия программного изделия имела свою собственную внешнюю спецификацию или четко изложенное описание в рамках внешней спецификации. Управление созданием программного изделия — своего рода игра, основанная на осуществлении контроля и сведении балансов группа планирования постоянно следит за расхождением между реальным положением дел, связанных с проектированием программного изделия, планами и спецификациями. Механизм рассмотрения и утверждения должен обеспечивать возможность выявления расхождений и последующего их устранения. Технические советы, объединенные комиссии и фазовые обзоры как раз и являются таким механизмом. [c.85]
Концепция бригады главного программиста хорошо вписывается в методологию, излагаемую в данной книге. Библиотека поддержки разработки является хорошей иллюстрацией методов конфигурационного управления на уровне проекта. Структурное программирование удовлетворяет многим требованиям методологии проектирования, которые упоминаются в этой книге. Нисходящее проектирование, называемое также программированием сверху вниз, является фактически постепенной детализацией описаний функциональной структуры на уровнях более простых функций до тех пор, пока, наконец, не будет достигнут уровень собственно операторов языка программирования [14]. В ходе этого процесса фактически осуществляется декомпозиция проекта, описанная в предыдущей главе. Как заметил Бейкер [39], один из недостатков работы бригад главного программиста заключается в отсутствии подробных описаний функциональной структуры, которые отражали бы все внешние аспекты системы, не затрагивая внутренней структуры проекта. Ясно, что речь здесь идет о внешних спецификациях, рассмотренных в гл. 2. Бригада главного программиста, в составе которой предусмотрена должность руководителя проек- [c.91]
Руководитель проекта формирует многие из документов, описанных в этой книге, такие, как соглашения о требованиях, сводки трудозатрат, внешние спецификации, сетевые графики и уведомления о календарных сроках. Он анализирует и утверждает те из документов, которые создаются без его участия, например распределение бюджета, внутренние спецификации, описание конфигурации системы, планы выпуска документации, планы испытаний и поддержки. Он также проводит анализ отчетов о ходе проектирования, делает представления на сотрудников и часто осуществляет непосредственное управление проектом. [c.98]
Первое правило в управлении изменениями заключается в поддержании всей документации в неустаревшем состоянии в течение всего цикла проектирования. Общей ошибкой является разработка качественного набора целей и внешних спецификаций и отсутствие возможности их модернизации при изменениях. Это плохая практика, так как цели и спецификации теперь более не отражают точно продукт, ведя к возникновению проблем взаимодействия и использования целей и спецификаций в процессах тестирования. [c.122]
При первом подходе предполагается, что проверку построения архитектуры системы выполняют разоаботчики внешних спецификаций и разработчики структуры поог-рамм (каждой компоненты). Разработчики внешних спецификаций проверяют полноту удовлетворения и аккуратность выполнения внешних спецификаций системы. Разработчики компонентов системы проверяют возможности построения предполагаемого компонента и доступность требований архитектуры системы. В связи с тем, что процесс построения архитектуры системы может выполняться параллельно с процессом внешнего проектирования, важно своевременно согласовать выходы и входы этих процессов. [c.129]
Очередным процессом создания ПО является процесс разработки структуры программы, включающий определение всех модулей, иерархической структуры модулей и интерфейса между ними. Если результатом разработки должна быть отдельная программа, то в качестве входной информации для данного процесса должны выступать детализированные внешние спецификации. Если же результатом разработки должна стать система ПО, то в качестве входной информации должны быть детализиро- [c.129]
Для проверки правильности проведения работ по проектированию системы могут быть применены различные способы Одним из них может быть проверка проект ной документации автором архитектуры системы (авто ром внешних спецификаций) и проектировщиком после дующего процесса (разработчиком модулей) с целью обеспечения работоспособности, понятности, соответствия используемому языку программирования, а также совмес тимости с общей системой, частью которой является проект. [c.138]
Тестирование модуля включает проведение определен ного объема работ проектирование набора тестовых -комбинаций на основе анализа внешних Спецификаций и программы модуля написание программы тестирования-и ее проверку и выполнение- программы тестирования Расемотр>ш содержание этих работ. " [c.173]
Проектирование программы тестирования — процесс творческий, требующий аналитичёскЬгб мышления Одна-. ко существует определённый наборГ.простцх правил, которые позволяют получить разумное множество, проверочных тестов. Эти правила базируются на рассмотрении программы модуля как черного ящика и использовании , внешних спецификаций модуля для построения тестов далее на базе изучения программы, модуля строятся-дополнительные тесты. Эти действия выполняются за четыре шага, i [c.173]
Шаг 1. Используя внешние спецификации модуля< -необходимо получить проверочные тесты для каждого условия и варианта данных, границ-всех зэданных<>интер- -валоВ На входе и выходе и для неверных условий.- к-,, [c.173]
Одно из важных свойств любого изделия заключается в том, что оно имеет конкретные внешние спецификации. Обычно вместе с изделием поставляется документация, детально описывающая выполняемые им функции и содержащая указания, как следует лрименять изделие, чтобы описанные функции выполнялись. [c.22]