Общие принципы и подходы к разработке по. Гибкие технологии разработки по Принципы и значение гибкой разработки

Детские товары 27.06.2020

Детские товары

Модели разработки ПО Водопадная Каскадная модель Спиральная Экстремальное программирование UI Prototyping Инкрементальная W-Model Testing Унифицированный процесс разработки программного обеспечения (USDP) Методология MSF

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

Экстремальное программирование Анализ исходных требований Проектирование Интеграция Реализация Тестирование Новые требования Анализ/Утвержде ние/модификация плана разработки Выпуск продукта

UI Prototyping Выпуск продукта Разработка ПО с учетом изменений Уточнение требований и спецификации Изменение прототипа и доработка некоторой функциональности Базовая функциональность Прототип интерфейса Предварительная спецификация

Инкрементальная разработка Итерация 1 Итерация 2 …. Анализ требований Проектирование Реализация Компонентное тестирование Интеграция Тестирование единого целого Итерация N

Унифицированный процесс разработки программного обеспечения (USDP) Ø Модель вариантов использования, описывает случаи, в которых приложение будет использоваться. Ø Аналитическая модель описывает базовые классы для приложения. Ø Модель проектирования описывает связи и отношения между классами и выделенными объектами Ø Модель развертывания описывает распределение программного обеспечения по компьютерам. Ø Модель реализации описывает внутреннюю организацию программного кода. Ø Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования

Унифицированный процесс разработки программного обеспечения (USDP) Сбор требований Итер 1…. Итер N Проектирование Итер 1…. Итер N Реализация Итер 1…. Итер N Конструирование Итер 1…. Итер N Тестирование Итер 1…. Итер N

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Ø Ø Ø Ø Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Отказоустойчивость – совокупность свойств системы, повышающая ее надежность путем обнаружения ошибок, восстановления и локализации плохих последствий для системы. При разработке любой реальной системы для обеспечения отказоустойчивости необходимо предусматривать всевозможные ситуации, которые могут привести к сбою системы и разработать механизмы обработки сбоев. Надежность – способность системы противостоять различным отказам и сбоям. Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние. Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя. Чем меньше отказов и сбоев за какой-то определенный интервал времени, тем система считается надежнее.

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Кривая надежности N t 1 t Чем дальше, тем тяжелее будет найти ошибку. Чем сложнее система, тем больше вероятность отказов и сбоев.

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Ø Возможности реализации разрабатываемой архитектуры. Ø Избыточная функциональность. Ø Принятие решение о приобретении готовых компонент ПО. Ø Стратегия изменений.

Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры: Ø Ясно ли описана общая организация программы; Ø Ø Ø включает ли спецификация обзор архитектуры и ее обоснование. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Приведено ли описание самых важных классов и их обоснование. Приведено ли описание организации БД. Определены ли все бизнес правила. Описано ли их влияние на систему.

Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры: ØОписана ли стратегия проектирования пользовательского интерфейса. ØСделан ли пользовательский интерфейс модульным, чтобы его изменения не влияли на оставшуюся часть системы. ØПриведено ли описание стратегии ввода-вывода данных. ØПроведен ли анализ производительности системы, которая будет реализовываться с использованием данной архитектуры. ØПроведен ли анализ надежности проектируемой системы. ØПроведен ли анализ вопросов масштабируемости и расширяемости системы.

Рефакторинг ПО Рефакторинг предполагает адаптацию программного обеспечения к новому аппаратному обеспечению и к новым ОС, новым средствам разработки, новым требованиям, а также архитектуре и функциональности ПО. Это изменение внутренней структуры ПО без изменения его внешнего поведения, призванное обеспечить модификацию ПО. Разумные причины проведения рефакторинга: Код повторяется; реализация метода слишком велика; слишком большая вложенность циклов, или же сам цикл очень большой; класс имеет плохую связность (свойства и методы класса должны описывать только 1 объект); интерфейс класса не формирует согласованную абстракцию; метод принимает слишком много параметров. Необходимо стараться, чтобы количество параметров было разумно минимальным; отдельные части класса изменяются независимо от других частей класса;

Рефакторинг ПО при изменении программы требуется параллельное изменение нескольких классов. При возникновении такой ситуации необходимо провести реорганизацию классов с целью минимизации в будущем мест возможных изменений; приходиться параллельно изменять несколько иерархий наследования; приходиться изменять несколько блоков case. Необходимо провести модификацию программы таким образом, чтобы сделать реализацию блока case, а вызывать ее в нужном количестве раз в программе; родственные элементы данных, используемые вместе, не организованы в классы. Если вы неоднократно используете один и тот же набор элементов данных, то целесообразно рассмотреть объединение этих данных и выполняемые над ними операции поместить в отдельный класс;

Рефакторинг ПО метод использует больше элементов другого класса, чем собственного. Это означает, что метод нужно переместить в другой класс и вызывать его из старого; элементарный тип данных перегружен. Для описания сущности реального мира лучше использовать какойлибо класс, чем перегружать какой-либо существующий тип данных; класс имеет слишком ограниченную функциональность. Лучше от этого класса избавиться, перенеся его функциональность в другой класс; по цепи методов передаются «бродячие» данные. Данные, передаваемые в метод только для того, чтобы он их передал другому методу, называются «бродячими» . При возникновении таких ситуаций постарайтесь изменить архитектуру классов и методов, чтобы от них избавиться.

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

Рефакторинг ПО подкласс использует только малую долю методов своих предков. Такая ситуация возникает тогда, когда новый класс создается только лишь для наследования нескольких методов из базового класса, а не для того, чтобы описать какую-либо новую сущность. Для того, чтобы этого избежать, необходимо преобразовать базовый класс, таким образом, чтобы он давал доступ новому классу только к необходимым ему методам; код содержит глобальные переменные. Глобальными должны быть только те переменные, которые в действительности используются всей программной. Все остальные переменные должны быть либо локальными, либо должны стать свойствами каких-либо объектов; программа содержит код, который может когда-нибудь понадобиться. При разработке системы целесообразно предусмотреть места, куда в будущем может быть добавлен исходный код.

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

Этапы жизненного цикла ПО

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.

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

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты - оперативно всё исправлять.

Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.

А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.

Основные модели разработки ПО

Code and fix - модель кодирования и устранения ошибок;
Waterfall Model - каскадная модель, или «водопад»;
V-model - V-образная модель, разработка через тестирование;
Incremental Model - инкрементная модель;
Iterative Model - итеративная (или итерационная) модель;
Spiral Model - спиральная модель;
Chaos model - модель хаоса;
Prototype Model - прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью.
Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели - документацию.
Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать.

«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.

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

V-образная модель (разработка через тестирование)

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

Преимущества V-образной модели

Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.

Incremental Model (инкрементная модель)

Это модель разработки по частям (increment в переводе с англ. - приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции - страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок - и по итогам обратной связи решает, продолжать ли разработку.
Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание.
Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда.

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

Iterative Model (итеративная модель)

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Преимущества итеративной модели

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

Недостатки итеративной модели

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

Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями , либо для задач с инновационным подходом, когда заказчик не уверен в результате.

Spiral Model (спиральная модель)

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

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».

Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта - уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

Преимущества спиральной модели

Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

Есть риск застрять на начальном этапе - бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile - не модель и не методология, а скорее подход к разработке.

Что такое Agile?

Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:

экстремальное программирование (Extreme Programming, XP);
бережливую разработку программного обеспечения (Lean);
фреймворк для управления проектами Scrum;
разработку, управляемую функциональностью (Feature-driven development, FDD);
разработку через тестирование (Test-driven development, TDD);
методологию «чистой комнаты» (Cleanroom Software Engineering);
итеративно-инкрементальный метод разработки (OpenUP);
методологию разработки Microsoft Solutions Framework (MSF);
метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке - методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк - это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.

Kanban

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

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

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

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

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

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов. Базовыми принципами являются:

принцип "разделяй и властвуй" (см. подраздел 2.1.1);

принцип иерархического упорядочения - принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

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

принцип абстрагирования - выделение существенных аспектов системы и отвлечение от несущественных;

принцип непротиворечивости - обоснованность и согласованность элементов системы;

принцип структурирования данных - данные должны быть структурированы и иерархически организованы.

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

DFD (Data Flow Diagrams) - диаграммы потоков данных;

SADT(Structured Analysis and Design Technique - метод структурного анализа и проектирования,) - модели и соответствующие функциональные диаграммы;

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь".

Диаграммы потоков данных и диаграммы "сущность-связь" - наиболее часто используемые в CASE-средствах виды моделей.

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели "AS-IS" и модели "ТО-ВЕ", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимом от средств реализации базы данных (СУБД).

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

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

Предметной областью для большинства примеров диаграмм, приведенных в данной главе, является налоговая система РФ, наиболее полное описание которой содержится в Налоговом кодексе РФ. Информационные технологии, применяемые в налоговой системе РФ, имеют определенные особенности.

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

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

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Возможности реализации разрабатываемой архитектуры. Возможности реализации разрабатываемой архитектуры. Избыточная функциональность. Избыточная функциональность. Принятие решение о приобретении готовых компонент ПО. Принятие решение о приобретении готовых компонент ПО. Стратегия изменений. Стратегия изменений.

Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование. Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Приведено ли описание самых важных классов и их обоснование. Приведено ли описание самых важных классов и их обоснование. Приведено ли описание организации БД. Приведено ли описание организации БД. Определены ли все бизнес правила. Определены ли все бизнес правила. Описано ли их влияние на систему. Описано ли их влияние на систему. Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры:

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

Рефакторинг ПО Код повторяется; реализация метода слишком велика; слишком большая вложенность циклов, или же сам цикл очень большой; класс имеет плохую связность (свойства и методы класса должны описывать только 1 объект); интерфейс класса не формирует согласованную абстракцию; метод принимает слишком много параметров. Необходимо стараться, чтобы количество параметров было разумно минимальным; отдельные части класса изменяются независимо от других частей класса; Рефакторинг предполагает адаптацию программного обеспечения к новому аппаратному обеспечению и к новым ОС, новым средствам разработки, новым требованиям, а также архитектуре и функциональности ПО. Это изменение внутренней структуры ПО без изменения его внешнего поведения, призванное обеспечить модификацию ПО. Разумные причины проведения рефакторинга:

Рефакторинг ПО метод использует больше элементов другого класса, чем собственного. Это означает, что метод нужно переместить в другой класс и вызывать его из старого; элементарный тип данных перегружен. Для описания сущности реального мира лучше использовать какой- либо класс, чем перегружать какой-либо существующий тип данных; класс имеет слишком ограниченную функциональность. Лучше от этого класса избавиться, перенеся его функциональность в другой класс; по цепи методов передаются «бродячие» данные. Данные, передаваемые в метод только для того, чтобы он их передал другому методу, называются «бродячими». При возникновении таких ситуаций постарайтесь изменить архитектуру классов и методов, чтобы от них избавиться.

1.Кодирование

На этапе разработки ПП выполняются следующие основные действия: кодирование; тестирование; разработка справочной системы ПП; создание документации пользователя; создание версии и инсталляции ПП,

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

При кодировании необходимо следовать стандарту на выбранный язык, например, для языка С - это ANSI С, а для C++ - ISO/IEC 14882 «Standartforthe C++ ProgrammingLanguage».

Кроме общепринятого стандарта на язык программирования в компании могут использоваться разработаны и свои дополнительные требования к правилам написания программ. В основном они касаются правил оформления текста программы.

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

На этапе кодирования программист пишет программы и сам их тестирует. Такое тестирование называется модульным. Все вопросы, связанные с тестированием ПП, рассмотрены в гл. 10, здесь же описана технология тестирования, которая применяется на этапе разработки ПП. Эта технология называется тестированием «стеклянного ящика» (glassbox); иногда ее еще называют тестированием «белого ящика» (whitebox) в противоположность классическому понятию «черного ящика» (blackbox).

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

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

1. Направленность тестирования. Программист может тестировать программу по частям, разрабатывать специальные тестовые подпрограммы, которые вызывают тестируемый модуль и передают ему интересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как «стеклянный ящик».

2.Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными, и может подобрать условия, в которых они будут протестированы. Ниже описано, как отслеживать степень охвата программного кода проведенными тестами.

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

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

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

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

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

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

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

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

Объектом тестирования может быть не только полный путь программы (последовательность команд, которые она выполняет от старта до завершения), но и его отдельные участки. Протестировать все возможные пути выполнения программы абсолютно нереально. Поэтому специалисты по тестированию выделяют из всех возможных путей те группы, которые нужно протестировать обязательно. Для отбора они пользуются специальными критериями, называемыми критериями охвата {coveragecriteria), которые определяют вполне реальное (пусть даже и достаточно большое) число тестов. Данные критерии иногда называют логическими критериями охвата, или критериями полноты.

3. Разработка справочной системы программного продукта. Создание документации пользователя

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

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

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

У хорошо документированного ПП имеются следующие преимущества.

1. Легкость использования. Если ПП хорошо документирован, то его гораздо легче применять. Пользователи его быстрее изучают, делают меньше ошибок, а в результате быстрее и эффективнее выполняют свою работу.

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

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

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