II часть План Классификация ИС Основные

II часть

План • Классификация ИС. Основные стадии создания АИС. • Содержание работ на этапах создания ИС. • Средства автоматизации проектирования ИС (CASE – технологии) • Разработка информационных систем на основе шаблонов проектирования • Средства быстрой разработки приложений(IDE). Компиляторы, отладчики, редакторы кода. • Современные технологи тестирования • Средства проектирования и разработки БД • Средства и технологии разработки приложений для интернета

• Информационная система (ИС) в целом автоматизированная система, предназначенная для организации, хранения, пополнения, поддержки и представления пользователям информации в соответствии с их запросами.

Классификация по архитектуре По степени распределённости: • настольные (desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере; • распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС разделяют на: • файл-серверные ИС (ИС с архитектурой «файл сервер» ). В файл серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях. • клиент-серверные ИС (ИС с архитектурой «клиент сервер» ). В клиент серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

Клиент серверные ИС разделяют на: • В двухзвенных (англ. two-tier) ИС всего два типа «звеньев» : сервер баз данных, на котором находятся БД и СУБД, и рабочие станции, на которых находятся клиентские приложения. Клиентские приложения обращаются к СУБД напрямую. • В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья» : серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения многозвенности — современные веб приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб браузере, имеется как минимум одно промежуточное звено — веб сервер с соответствующим серверным программным обеспечением.

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

Классификация по охвату задач (масштабности) • Персональная ИС предназначена для решения некоторого круга задач одного человека. • Групповая ИС ориентирована на коллективное использование информации членами рабочей группы или подразделения. • Корпоративная ИС в идеале охватывает все информационные процессы целого предприятия, достигая их полной согласованности, безызбыточности и прозрачности. Такие системы иногда называют системами комплексной автоматизации предприятия.

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

Классификация по сфере применения • Поскольку ИС создаются для удовлетворения информационных потребностей в рамках конкретной предметной области, то каждой предметной области (сфере применения) соответствует свой тип ИС.

• Экономическая информационная система — информационная система, предназначенная для выполнения функций управления на предприятии. • Медицинская информационная система — информационная система, предназначенная для использования в лечебном или лечебно профилактическом учреждении. • Географическая информационная система — информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно координированных данных (пространственных данных).

Средства автоматизации проектирования АИС

• Максимально упростить и формализовать процессы формирования требований и проектирования системы позволяют современные CASE средства. • В 70 х и 80 х гг. ХХ в. при разработке информационных систем достаточно широко стала применяться структурная методология анализа, предоставляющая в распоряжение разработчиков строгие формализованные методы описания системы и принимаемых технических решений. • Она основана на применении наглядной графической техники (схем и диаграмм), предназначенной для описания различного рода моделей. • Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических (проектных) решений

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

• Основная цель использования CASE-технологий заключается в максимальной автоматизации стадий анализа и проектирования систем с целью построения формальных и непротиворечивых моделей системы. • Другая, не менее важная, цель использования CASEтехнологий – вынесение части деятельности (чем больше, тем лучше) из стадии кодирования в стадию проектирования. • Большинство современных CASE средств поддерживает методологии структурного и/или объектноориентированного анализа и проектирования информационных систем. Выбор того или иного подхода (парадигмы) подразумевает следование ему и на стадии кодирования (согласно принципу концептуальной общности). • Их отличие друг от друга заключается в выборе способа декомпозиции системы (задачи). Если за основу принимается функциональная (алгоритмическая) декомпозиция, то речь идет о структурном подходе, если объектная – об объектно-ориентированном.

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

• Единая база данных проекта. Основа CASE технологии — использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может совместно использоваться разработчиками в соответствии с их правами доступа. Содержимое репозитория включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонентов. Репозиторий может хранить объекты различных типов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных, логику обработки, модели данных, их организации и обработки, исходные коды, элементы данных и т. п

• Интеграция средств. На основе репозитория осуществляются интеграция СASE средств и разделение системной информации между разработчиками. При этом возможности репозитория обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представления фаз ЖЦ, передачу данных и средств между различными платформами;

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

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

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

• Верификация проекта. CASE технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом; • Автоматическая генерация программного кода. Генерация программного кода осуществляется на основе репозитория и позволяет автоматически построить до 85 90% текстов на языках высокого уровня.

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

• Все современные CASE средства могут быть классифицированы в основном по типам и категориям. • Классификация по типам отражает функциональную ориентацию CASE средств на те или иные процессы ЖЦ. • Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.

. Помимо этого, CASE средства можно классифицировать по следующим признакам: • применяемым методологиям и моделям систем и БД; • степени интегрированности с СУБД; • доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE средств и включает следующие основные типы: • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works)); • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO IV (Mc. Donnell Douglas), CASE. Аналитик (Макро. Проджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных; • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S Designor (SDP) и Data. Base Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE средств Vantage Team Builder, Designer/2000, Silverrun и PRO IV;

• средства разработки приложений. К ним относятся средства 4 GL (Uniface (Compuware), JAM (JYACC), Power. Builder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др. ) и генераторы кодов, входящие в состав Vantage Team Builder, PRO IV и частично в Silverrun; • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO IV, Silverrun, Designer/2000, ERwin и S Designor. В области анализа программных кодов наибольшее распространение получают объектно ориентированные CASE средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают • средства планирования и управления проектом (SE Companion, Microsoft Project и др. ); • средства конфигурационного управления (PVCS (Intersolv)); • средства тестирования (Quality Works (Segue Software)); • средства документирования (So. DA (Rational Software)).

• · обратное проектирование (реинжиниринг). В этом случае порядок использования CASE средства обратный – от текста программы или базы данных на диске к логической модели. Помимо построения, CASE средства позволяют быстро интегрировать полученные таким образом модели в проект, а также с меньшими потерями переходить от одной физической реализации к другой (например, в случае ухода «старых» разработчиков, плохо документирующих программное обеспечение, или появления новых, более перспективных языков программирования и СУБД); • · синхронизация моделей системы с ее физической реализацией. В случае изменения модели системы могут быть автоматически внесены необходимые изменения в физическую реализацию или наоборот; • · автоматическое обеспечение качества и тестирование моделей на наличие ошибок (например, ошибок нормализации БД), полноту и непротиворечивость; • · автоматическая генерация документации. Вся документация по проекту генерируется автоматически на базе репозитария (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитарии.

СРЕДСТВА БЫСТРОЙ РАЗРАБОТКИ ПРИЛОЖЕНИЙ

• Быстрая разработка приложений (RAD — Rapid Application Development) основывается на визуализации процесса создания программного кода. Технология RAD предоставляет программистам средства, ускоряющие разработку программ, их модификацию и отладку. • Для максимального упрощения работы используются графические инструментальные средства, основанные на компонентной архитектуре. Каждый компонент является объектом, объединяющим в себе данные, методы и свойства для работы с ними. • При этом компоненты являются объектами, объединяющими данные и методы, а также свойства. Свойства, с одной стороны, позволяют работать с данными так же, как с членами классов, а с другой стороны, скрывают за операциями чтения/записи вызовы методов, переводя операции над объектами на более высокий уровень абстракции.

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

• Интегрированная среда разработки является средством, с помощью которого выполняются проектирование, отладка, тестирование и дальнейшее распространение прикладных программ. • Для повышения эффективности данного процесса каждое из средств (конструкторы, отладчики и т. д. ) должно быть реализовано на очень высоком уровне. • Существует множество средств визуального программирования, основанных на различных алгоритмических языках. Лидерами в разработке таких средств являются фирмы Microsoft и Micro Focus, Inprise (бывшая Borland). Каждая из них предоставляет несколько сред визуального программирования: • Microsoft Visual Studio • Inprise C++Builder, Delphi и JBuilder.

Компиляторы

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

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

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

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

Основные стадии создания АИС • • • Обследование предприятия Обработка полученной информации Формирование ТЗ на систему Составление концептуального проекта Реализация системы

Современные технологии тестирования

• Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения. • С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. • Как одна из основных фаз процесса разработки программного продукта (Дизайн приложения Разработка кода Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. • Известна оценка распределения трудоемкости между фазами создания программного продукта: 40% 20% 40%.

• Статическое тестирование выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы (ошибки формального задания) с помощью специальных инструментов контроля кода – Code. Checker. • Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования – Testbed или Testbench.

Классы критериев тестирования Структурные критерии используют информацию о структуре программы (критерии так называемого "белого ящика"), что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Структурные критерии базируются на основных элементах графа управления – операторах, ветвях и путях. • Условие критерия тестирования команд (критерий С 0) набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. • Условие критерия тестирования ветвей (критерий С 1) набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. • Условие критерия тестирования путей (критерий С 2) набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз.

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

• Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы. Применяется при тестировании сложных программных комплексов когда набор детерминированных тестов (X, Y) имеет громадную сложность. • Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте Карло. • Метод мутационного тестирования состоит в том, что в разрабатываемую программу P вносят мутации (мелкие ошибки), т. е. искусственно создают программы мутанты P 1, P 2. . . Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X, Y). • Если на наборе (X, Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы мутанты ошибки, то набор тестов (X, Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной. Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X, Y) и продолжать тестирование.

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

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

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

Этапы тестирования Каждая фаза тестирования включает в себя следующие этапы: 1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т. п. 2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы. 3. Разработка тестов (тестового кода для тестируемой системы) 4. Выполнение тестов: реализация тестовых циклов. 5. Анализ результатов.

• Тестовый цикл – это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build. • Тестовый план это документ, или набор документов, содержащий тестовые ресурсы, перечень функций и подсистем, подлежащих тестированию, тестовую стратегию, расписание тестовых циклов, фиксацию тестовой конфигурации(состава и конкретных параметров аппаратуры и программного окружения), определение списка тестовых метрик, которые на тестовом цикле необходимо собрать и проанализировать (например, метрик, оценивающих степень покрытия тестами набора требований). • Тесты разрабатывают на основе спецификаций как вручную, так и с помощью автоматизирующих средств. Помимо собственно кода, в понятие «тест» включается его общее описание и подробное описание шагов, выполняемых в данном тесте. • Для оценки качества тестов используют различные метрики, связанные с количеством найденных дефектов, покрытием кода, функциональных требований, множества сценариев. • Вся информация об обнаруженных в процессе тестирования дефектах (тип, условия обнаружения, причина, условия исправления, время, затраченное на исправление) заносятся в базу дефектов. • Информация о тестовом плане, тестах и дефектах используется в конце каждого цикла тестирования для генерации тестового отчёта и корректировании системы тестов для следующей итерации.

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

Типы тестирования по способу выбора входных значений: • Функциональное тестирование, при котором проверяется: – Покрытие функциональных требований. – Покрытие сценариев использования. • Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта. • Тестирование граничных значений. • Тестирование производительности. • Тестирование на соответствие стандартам. • Тестирование совместимости с другими программно аппаратными комплексами. • Тестирование работы с окружением. • Тестирование работы на конкретной платформе

Test Driven Development • Разработка через тестирование (Test Driven Development – TDD) процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

TDD определяет следующий порядок этапов программирования: • Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется. • Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал. • Рефакторинг – удалите из написанного вами кода любое дублирование. • Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.