КОНСТРУИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

102. Недостатки непрерывной интеграции

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

Кодирование

5) обработка ошибочных условий
и исключительных ситуаций;
6) документирование кода;
7) тонкая «настройка» кода;
8) рефакторинг.

Обзор кода

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

Язык программирования

Важную роль играют
1. Программирование не на языке, а с
использованием языка.
2. Опыт программирования на
конкретном языке.
3.
Программирование с псевдокодом
– запись в программе пошагового
алгоритма.

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

Достоинства — упорядоченный процесс
конструирования с четким планом и
графиком следования этапов.
Недостатки:
a) Требования к проекту на начальном этапе
обычно определены частично, поэтому в
дальнейшем возможны их уточнения и
изменения;
b) Этапы выполняются последовательно,
поэтому результаты разработки заказчик
получает в самом конце.

Сложность программной системы

Показатели:
1) Длина
N ≈ n1 log2 (n1) + n2 log2 (n2)
где n1 — число различных операторов модуля,
n2 — число различных операндов.
2) Объем
V = N * log2 (n1 + n2).
3) Цикломатическая сложность:
V(G) = E*N – 2,
где E – количество дуг, а
N – количество вершин в управляющем
графе программной системы.

Зачем нужно проектирование программного обеспечения

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

Проектируя ПО заранее, разработчик получает возможность:

1 Процессы и инструментальные средства конструирования

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Процесс конструирования программного обеспечения заклю-

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

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

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

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

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

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

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

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

внесение при необходимости изменений в документацию пользователя;

корректировка при необходимости требований к процедуре тестирования и определение графиков работ по комплексированию программных средств;

оценивание качества программного кода и документальное оформление результатов тестирования;

разработка и документальное оформление плана комплексирования по объединению программных компонентов и программных модулей в программный продукт;

проведение в соответствии с планом комплексирования программных компонентов и программных модулей в программный продукт, тестирование и документальное оформление результатов комплексирования и тестирования;

внесение изменений результатов комплексирования и тестирования в пользовательскую документацию по мере необходимости.

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

К инструментальным средствам конструирования ПП относятся промышленные технологии проектирования и конструирования, в том числе интегрированные среды разработки программ (IDE), методы и технологии программирования.

Промышленные технологии создания программного продукта (Microsoft Solution Framework (MSF), Rational Unified Process (RUP), DATARUN) основаны на использовании конкретных моделей разработки, содержат описания принципов, методов, применяемых процессов и операций, поддерживаются набором CASE-средств, охватывающих все этапы жизненного цикла продукта.

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

VisualStudio разработан на С++ и С#, поддерживается Windows OS, включает различного рода дополнения, такие как:

Subversion – систему контроля версий.

Komodo написана на JavaScript, XUL, Python, поддерживает десять языков программирования, среди которых присутствуют: PHP, Ruby, HTML5; рaботает нa опeрационных систeмах: OS Linux, Windоws и

· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·

Интегрированные среды разработки удобны для командной работы над

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

основным методам и технологиям разработки (написания кода) программного обеспечения относятся:

процедурное программирование (язык C);

системное программирование (Ассемблер);

структурное программирование (C);

логическое программирование (PROLOG;

функциональное программирование (LISP, Haskell, Scala, Elm);

визуальное программирование (Delphi);

объектно-ориентированное программирование (Java, C#, C++, JavaScript, ActionScript, Python, Ruby, PHP, и др.);

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

сервис-ориентированный подход к разработке ПП, основанный на использовании распределенных, слабо связанных компонентов, взаимодействующих по стандартизированным интерфейсам и протоколам;

интеллектуальные многоагентные (мультиагентные) системы управления и поддержки групповой работы.

процессе конструирования также должны использоваться внешние стандарты языков описания данных (XML, SQL и др.), средств коммуникации (COM, CORBA и др.), интерфейсов компонентов (POSIX, IDL, APL), описания сценариев UML и др.

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

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

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

троля версий: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce,

4.4.2 Практические рекомендации по организации процессов конструирования при использовании промышленной технологии

Процессы конструирования промышленной технологии Microsoft Solution Framework (MSF) ориентированы не просто на создание программного продукта, удовлетворяющего перечисленным требованиям, а на поиск решения проблем, стоящих перед заказчиком. Различие состоит в том, что перечисляемые заказчиком требования являются проявлениями некоторых более глубоких проблем и неточность, неполнота, изменение требований в процессе разработки – следствие недопонимания проблем. Поэтому в технологии MSF большое внимание уделяется анализу проблем заказчика и разработке вариантов системы для поиска решения этих проблем.

Связность модулей

Это мера зависимости его частей. Для ее
измерения используют понятие силы связности
(СС).
Типы связности:
1) Функциональная (СС = 10)
2) Информационная (СС = 9);
3) Коммуникативная (СС = 7);
4) Процедурная (СС = 5);
5) Временная (СС = 3);
6) Логическая (СС = 1);
7) По совпадению (СС = 0).

4 Тестирование в конструировании

Это процесс выполнения программы с
намерением найти ошибки.
Методологии тестирования:
a) «белого ящика» и
b) «чёрного ящика».

Инкрементная модель

объединяет достоинства каскадной и
методов макетирования.

Прототипирование

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

5 Повторное использование

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

Технология Scrum

представляет собой эмпирический подход к
разработке программного обеспечения. Основан
на повторяющихся циклах. В процессе
разработки участвуют актеры со следующими
ролями.
1. Scrum Мастер (Scrum Master) – самая важная
роль (организует работу).
2. Владелец продукта (Product Owner) –
представитель заказчика.
3. Команда (Team) самоорганизующаяся и
самоуправляемая, работает как единое целое,
без учета вклада отдельных членов.

Стандарты в конструировании

1.
2.
3.
4.
Государственные (ГОСТ) — ЕСПД;
Отраслевые (ОСТ) – стандарты
языков (СИ, Java);
Стандарты предприятий (СТП);
Стандарты проектов – соглашения
об оформлении кода и пр.
документов.

7 Интеграция

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

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

Достоинства :
a) Более точно отображает процесс
разработки ПО;
b) Позволяет учитывать риск разработки;
c) Использует моделирование для оценки
характеристик.
Недостатки :
a) Повышенные требования к заказчику;
b) Сложность контроля и управления
временем разработки.

Непрерывная интеграция (CI — Continuous Integration)

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

Виды качества

Внешнее – качество для заказчика
(это удобство в использовании,
отсутствие ошибок, хорошая
производительность и т.п.)
Внутреннее – это качество для
разработчиков программного
продукта (соответствие
требованиям, удобная архитектура,
простота изменения и т.п.)

Модульный принцип разработки ПО

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

Конструирование ПО, метафоры, предварительные требования

Время на прочтение

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

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

Читабельность

удобство чтения программного кода.
Достигается с помощью целого ряда
средств: структурирования,
использования мнемонических имен и
пр.

Технологии разработки приложений

1)
2)
3)
4)
Быстрая разработка (RAD);
Унифицированная разработка
(RUP);
Экстремальное
программирование;
Технология Scrum.

Особенности XP-программирования

Используются 12 базовых методов, которые
предполагают разработку историй
(сценариев) и включение их в очередную
итерацию. Каждая история реализуется за 2
недели.
Применяется парное программирование
(написание и отладка кода двумя
программистами).
Широко используется тестирование. Тесты
составляются до начала кодирования.

2 Планирование конструирования

Необходимо оценить:
a) людские ресурсы (в человекомесяцах);
b) продолжительность (в календарных
датах);
c) стоимость.
Определяется порядок разработки
компонентов и методов обеспечения
качества.

2 Связь конструирования с прочими стадиями жизненного цикла

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

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

процессе конструирования обычно создается большая часть активов программного проекта – конфигурационных элементов. Поэтому в реальных проектах просто невозможно рассматривать деятельность по конструированию в отрыве от области знаний «Конфигурационного управления» (Software Configuration Management).

Так как конструирование невозможно без использования соответствующего инструментария и, вероятно, данная деятельность является наиболее инструментально-насыщенной, важную роль в конструировании играет область знаний «Инструменты и методы программной инженерии» (Software Engineering Tools and Methods).

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

Из связанных дисциплин программной наиболее тесная и

естественная связь данной области знаний существует с

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

Технология конструирования программного обеспечения

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

Различают методы, средства и процедуры ТКПО. Методы обеспечивают решение следующих задач:

планирование и оценка проекта;

анализ системных и программных требований;

проектирование алгоритмов, структур данных и программных структур;

Средства (утилиты) ТКПО обеспечивают автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами (Computer Aided Software Engineering).

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

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

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

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

процессе конструирования программного изделия осуществляют:

функциональную декомпозицию решаемой задачи, на основе которой определяется архитектура системы, представляющей задачу;

внешнее проектирование программного обеспечения, выражающееся в форме его внешнего взаимодействия с пользователем;

проектирование базы данных, если это необходимо;

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

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

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

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

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

Основные принципы проектирования программного обеспечения можно представить в виде следующей схемы (рис 1):

внешний проект программного изделия (взаимодействие с пользователем)

(требования для каждого

Рис. 1. Принципы проектирования

Метрики программного обеспечения

1)
2)
3)
4)
5)
6)
7)
8)
9)
Трудоемкость и емкостная сложность
(асимптотическая оценка),
Количество строк кода (LOC — lines-of-code),
Цикломатическая сложность,
Анализ функциональных точек,
Количество ошибок на 1000 строк кода,
Степень покрытия кода тестированием,
Покрытие требований,
Количество классов и интерфейсов,
Связность.

3) Жемчужины – наращивание
функциональности как жемчуг в
раковине;
4) Строительная – по аналогии со
строительством зданий,
предпочтительная.

Ожидание изменений

Существует два вида изменений:
1) Усовершенствование кода
программы (рефакторинг);
2) Добавление новой
функциональности (реинжениринг).

Процедуры разработки ПО

объединяют методы и средства и
обеспечивают непрерывную
последовательность разработки.
Определяют:
a) Порядок применения методов и утилит;
b) Формирование отчетов;
c) Порядок контроля обеспечения качества и
координации изменений;
d) Формирование этапов выполнения работ.

1 Понятие конструирования

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

Данная область знаний связана с другими областями. Наиболее сильная связь существует с проектированием (Software Design) и тестированием (Software Testing). Причиной этого является то, что сам по себе процесс конструирования программного обеспечения затрагивает важные аспекты деятельности по проектированию и тестированию. Кроме того, конструирование отталкивается от результатов проектирования, а тестирование (в любой своей форме) предполагает работу с результатами конструирования. Достаточно сложно определить границы между проектированием, конструированием и тестированием, так как все они связаны в единый комплекс процессов жизненного цикла и, в зависимости от выбранной модели жизненного цикла и применяемых методов (методологии), такое разделение может выглядеть по-разному.

V-образная модель

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

Локальные характеристики модулей

a)
b)
Коэффициент объединения по
входу, Fan_in(i) – количество
модулей, которые прямо управляют
i–тым;
Коэффициент разветвления по
выходу, Fan_out(i) — количество
модулей, которыми прямо
управляет i–тый модуль.
В примере Fan_in(n) = 4, Fan_out(m) = 3.

Реинжиниринг

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

Характеристики иерархической сложности структуры программной системы

1)
2)
3)
4)
Количество вершин (модулей);
Количество связей между вершинами;
Высота – количество уровней
управления;
Ширина – максимальное количество
модулей, размещенных на отдельных
уровнях управления.

Управление инженерией ПО

a)
b)
c)
организационное управление
(Organizational Management),
управление процессом и проектом
(Process/Project Management),
измерения инженерии ПО (Software
Engineering Measurement).

Определение

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

Достоинства и недостатки прототипирования

Достоинства
a) уменьшение времени, стоимости и рисков;
b) вовлечение пользователя в процесс
разработки
Недостатки
a) недостаточный анализ,
b) смешение прототипа и готовой системы в
представлении пользователей,
c) большое время создания прототипа.

Макетирование

Многократное повторение итераций

Примеры техзаданий на разработку ПО

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

ТЗ на программное обеспечение Protector

Объект ТЗ: разработка и интеграция с существующей системой модульного ПО для мониторинга удаленных устройств охраны
Заказчик: ООО «ВТИМБ»

Техническое задание на платформу безопасности Protector from EDISON Software Development Centre

Вариант в pdf

Сценарии использования образовательной системы

Объект ТЗ: создание образовательной системы

Cценарии использования from EDISON Software Development Centre

ТЗ на разработку ПО SMPP-шлюз

Объект ТЗ: разработка программного обеспечения SMPP-шлюза
Заказчик: IMT

ТЗ на SMPP шлюз from EDISON Software Development Centre

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

Управление процессом

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

Семь раз отмерь, один раз отрежь

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

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

Важность выполнения предварительных условий

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

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

Самый веский аргумент в пользу выполнения предварительных условий перед началом конструирования

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

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

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

Ученые из компаний Hewlett-Packard, IBM, Hughes Aircraft, TRW и других
организаций обнаружили, что исправление ошибки к началу конструирования обходится в 10-100 раз дешевле, чем ее устранение в конце работы над проектом, во время тестирования приложения или после его выпуска (Fagan, 1976; Humphrey, Snyder, and Willis, 1991; Leffingwell 1997; Willis et al., 1998; Grady, 1999; Shull et al., 2002; Boehm and Turner, 2004).

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

Разработкой чего вы занимаетесь?
— Встроенные системы, от которых зависит жизнь людей
— Бизнес-системы
— Системы целевого назначения

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

Влияние итеративных подходов на предварительные условия

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

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

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

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

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

Более итеративный подход (при котором вопросы решаются по мере работы) можно предпочесть, если:
— требования относительно непонятны или вам кажется, что они могут оказаться нестабильными по другим причинам;
— проект приложения сложен, не совсем ясен или и то и другое;
— группа разработчиков незнакома с прикладной областью;
— проект сопряжен с высоким риском;
— долговременная предсказуемость проекта не играет особой роли;
— затраты на изменение требований, проекта приложения и кода скорее всего
будут низкими.

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

Предварительные условия, связанные с определением проблемы

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

Определение проблемы — это просто формулировка сути проблемы без каких-
либо намеков на ее возможные решения. Оно может занимать пару страниц, но
обязательно должно звучать как проблема. Фраза «наша система Gigatron не справляется с обработкой заказов» звучит как проблема и является хорошим определением. Однако фраза «мы должны оптимизировать модуль автоматизированного ввода данных, чтобы система Gigatron справлялась с обработкой заказов» —
плохое определение проблемы. Оно похоже не на проблему, а на решение.
Определение проблемы предшествует выработке детальных требований, которая
является более глубоким исследованием проблемы.

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

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

Не имея хорошего определения проблемы, можно потратить усилия на решение не той проблемы.

Предварительные условия, связанные с выработкой требований

Важность явного набора требований объясняется несколькими причинами:
— Явные требования помогают гарантировать, что функциональность системы определяется пользователем, а не программистом. Если требования сформулированы
явно, пользователь может проанализировать и утвердить их.

— Наличие явных требований помогает избегать споров.

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

Миф о стабильности требований ПО

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

Что делать при изменении требований во время конструирования программы?

Оцените качество требований при помощи контрольного списка,
приведенного в конце раздела. Если требования недостаточно хороши, прекратите работу, вернитесь назад и исправьте их.

— Убедитесь, что всем известна цена изменения требований. Думая о новой
функции, клиенты приходят в возбуждение. Кровь у них разжижается, переполняет продолговатый мозг, и они впадают в эйфорию, забывая обо всех собраниях, посвященных обсуждению требований, о церемонии подписания и всех документах. Угомонить таких одурманенных новыми функциями людей проще всего, заявив: «Ого, это действительно прекрасная идея! Но ее нет в документе требований, поэтому я должен пересмотреть график работы и смету, чтобы вы могли решить, хотите ли вы реализовать это прямо сейчас или позднее». Слова «график» и «смета» отрезвляют куда лучше, чем кофе и холодный душ, и многие требования быстро превращаются в пожелания.

— Задайте процедуру контроля изменений

— Используйте те подходы к разработке, которые адаптируются к изменениям

— Оставьте проект, если требования особенно неудачны

— Помните о бизнес-модели проекта

Примеры связанных модулей

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

Метафоры, позволяющие лучше понять разработку ПО

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

Важность метафор

Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем
понятное явление с чем-то похожим, но более понятным, вы можете догадаться,
как справиться с проблемой. Такое использование метафор называется моделированием».
История науки полна открытий, сделанных благодаря метафорам. Так, химик Кекуле однажды во сне увидел змею, схватившую себя за хвост. Проснувшись, он понял, что свойства бензола объяснила бы молекулярная структура, имеющая похожую кольцевую форму. Дальнейшие эксперименты подтвердили его гипотезу (Barbour, 1966).

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

Иногда люди упрощают суть метафор. На каждый из описанных примеров так и
тянет ответить: «Разумеется, правильная метафора более полезна. Другая метафора
была неверной!» Так-то оно так, но это слишком упрощенное представление. История науки — не серия переходов от «неверных» метафор к «верным». Это серия
переходов от «менее хороших» метафор к «лучшим».

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

Как использовать метафоры?

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

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

Далее рассмотрим популярные метафоры, характеризующие разработку ПО.

Литературная метафора

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

Подобный подход может быть практичным, если вы пишете банальное письмо своей тетушке. Однако расширение метафоры «написания» ПО вплоть до выбрасывания первого
экземпляра программы — не лучший совет в мире разработки ПО, где крупная система по стоимости уже сравнялась с 10-этажным офисным зданием или океанским лайнером.

Сельскохозяйственная метафора

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

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

Медленное приращение системы

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

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

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

Строительная метафора

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

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

Комбинирование метафор

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

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

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

Последние фазы

Построение длится от 2 до 4
итераций. При этом происходит
разработка окончательного продукта.
4) Внедрение занимает от 1 до 3
итераций. На этой стадии проводится
тестирование системы, тренинги
пользователей и развертывание
системы на рабочей площадке.
3)

Простые алгоритмы

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

Спринт

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

Метод черного ящика

Тестирование внешних интерфейсов

Унифицированная разработка (Rational Unified Process — RUP)

Один из самых известных процессов,
использующих итеративную модель
разработки. Был разработан компанией
Rational Software и стал основной
методологией компании IBM.
RUP описывает некоторый абстрактный
процесс, на основе которого организация
или проектная команда создает
специализированный процесс для
конкретной системы.

Это процесс создания модели программного
продукта. Модель может быть в виде :
1) Бумажного макета или макета на основе
компьютера (изображает или рисует
человеко-машинный диалог);
2) Работающего макета (выполняет часть
требуемых функций ПС);
3) Существующей программы
(характеристики которой затем
улучшаются).

Стандарты программирования

a)
b)
c)
общие, разрабатываемые
специальными организациями,
например, ISO, IEEE или Комитетом
по стандартизации РФ,
стандарты языка (например, java)
а также стандарты конкретной
организации-разработчика
программной системы.