Файл: Основы проектирования программы. Этапы создания программного обеспечения.pdf

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

Третья проблема масштабируемости решается в объектно-ориентированном программировании с помощью создания классов, основанных на других классах. Например, мы можем создать класс «Трехмерная точка», основываясь на уже созданном классе «Точка». При этом мы автоматически получим в новом классе два поля с координатами, и нам придется добавить лишь одно – «Координата Z». Некоторые методы (например, определить, в какой координатной четверти находится точка) не потребуется менять вовсе, так как они будут зависеть лишь от «старых» координат X и Y. Однако некоторые методы (например, посчитать расстояние от начала координат) придется переделать. Однако их число будет меньше, а следовательно, сделать это будет проще.

Кроме того, если вдруг нам придется сделать изменение, которое будет для данных точек (на плоскости и в пространстве), например, «вернуть координату X, умноженную на координату Y», то мы можем реализовать ее в «базовом» классе «Точка», и в производном классе «Трехмерная точка» данный метод появится автоматически. Если же нам нужно реализовать
что-то, относящееся только к точкам в пространстве, то можно реализовать это в производном классе (в таком случае, в базовом классе данного метода не будет).

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

1.4 Проблема эмоционального выгорания

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

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

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

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

Для того, чтобы повысить моральный дух команды был разработан процесс «геймификации» (от англ. game – игра). Данный процесс состоит в том, что процесс разработки рассматривается как игра типа RPG (Role Playing Game), в которой каждый игрок должен выполнять квесты
(от англ. quest – задание) и получать за это ачивки (от англ. achievement – достижение).

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

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

Примерами подобных значков могут быть такие:

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

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

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

2. Часто используемые модели жизненного цикла программ

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

2.1 Модель водопада

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

1. Разработка;
2. Сопровождение.

Однако, так как данные фазы являются довольно крупными, они дополнительно подразделяются на ряд этапов. Например, разработка состоит из пяти этапов:

1. Определение требований – сюда включается описание общего контекста задачи, ожидаемых функций системы и ее ограничений. На данном этапе заказчик совместно с разработчиками принимает решение о том, что систему необходимо создать;
2. Спецификация системы – разработчики системы пытаются осмыслить выдвигаемые заказчиком требования и зафиксировать в виде спецификаций системы. Важно отметить, что в спецификациях описывается только внешнее поведение системы, то есть «что она будет делать», в то время как внутренняя реализация (то есть, «как система будет это делать») сюда не включается. Прежде чем приступать к работе над проектом согласно спецификации, они должны быть проверены на соответствие исходным целям, полноту, непротиворечивость и однозначность;
3. Проектирование – на данном этапе выполняется проектирование системы таким образом, чтобы она могла удовлетворять определенным на этапе 1 и 2 требованиям. Чаще всего на данном этапе выполняют последовательную декомпозицию системы до уровня очевидных процедур и функций (а также модулей или классов);
4. Реализация – на данном этапе каждый из спроектированных на предыдущем шаге модулей непосредственно кодируется на наиболее подходящем для данного приложения языке;
5. Тестирование – созданный программный продукт подвергается комплексному тестированию, чтобы удостовериться, что он соответствует спецификации и выполняет поставленные задачи.

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

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

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

2.2 Модель водопада с промежуточным контролем

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

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

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

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

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

2.3 Спиральная модель

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

1. Этап определения требований и анализа;
2. Этап проектирования;
3. Этап реализации;
4. Этап внедрения.

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

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

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

2.4 Гибкие методологии разработки

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