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

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

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

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

Некоторые методологии разработки, которые можно отнести к семейству «гибких» приведены далее.

2.4.1 Разработка, основанная на тестах

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

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

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

В процессе разработки, основанной на тестах, разработчики проходят через следующие стадии:

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

В данной методологии, как и во всех остальных, есть свои достоинства и недостатки. Перечислим преимущества данной методологии:

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

Перечислим недостатки данной методологии:

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

2.4.2 Разработка, основанная на функциях

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

Процесс работы в рамках FDD состоит из пяти этапов:

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

2.4.3 Экстремальное программирование

Экстремальное программирование (Extreme Programming, или, сокращенно, XP) – это одна из гибких методологий разработки программного обеспечения, которая исходит из той идеи, что при разработке необходимо применять самые последние разработанные способы и методы улучшения качества кода и сокращения сроков. Данный метод является «экстремальным» в том смысле, что он находится на «переднем крае» разработки, впитывая в себя все то новое, что разрабатывается в данной области.

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

1. Это гибкая методология разработки, но также «экстремальная», доведенная до предела. Если в гибкой методологии предполагается готовность продукта раз в 2-3 недели, то здесь это возводится в абсолют, и считается, что продукт должен быть готов после каждого коммита разработчика. То есть, если разработчик внес какие-то изменения в основное дерево, то это должно быть что-то законченное, что может быть сразу запущено. Для проверки этого на сервере разработки ставятся программы, запускающие после каждого коммита автоматические тесты, и осуществляющие сборку проекта с сигнализацией ошибок;
2. Используется разработка через тестирование, то есть, тесты пишутся до кода, и запускаются при каждом коммите;
3. Принцип «Заказчик всегда рядом» - так как при каждом коммите у нас работающая система, то в нее можно пустить заказчика, который может в реальном времени в ней работать (конечно, не с реальными данными), и видеть, как система растет и улучшается;
4. Парное программирование – принцип, когда программируют одновременно два человека за одним компьютером. Один из них пишет код, а второй просматривает глазами, и обращает внимание на ошибки и неточности при необходимости. Через некоторое время они меняются ролями. Это приводит к повышению качества кодирования, а также к тому, что разработчики могут научить друг друга новым техникам и приемам;
5. Существует стандарт кодирования, в котором четко описано, как необходимо кодировать программу вплоть до мельчайших деталей. Например, написано, что «переменные должны описываться в CamelCase – на английском языке, без пробелов между словами, и каждое слово с большой буквы, например DoSomething или DebtPercent». Данное правило проверяется системой тестов при каждом коммите и жестко контролируется;
6. Коллективное владение кодом – каждый разработчик несет ответственность за весь код, в том числе и тот, который писал не он. То есть, при необходимости он может поправить ошибку в любом месте программы, или дописать необходимый функционал. Нет жесткого закрепления конкретных разработчиков за конкретными функциями. Парное программирование способствует этому – каждый разработчик видит не только свой код, но и чужой, что позволяет ему понимать, как работает система в целом.

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

Заключение

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

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

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

Список использованных источников

Бумажные источники

1. Аллен Э. Типичные ошибки проектирования. – «Питер», 2003. – 224 с.
2. Бобровский С. Технологии Пентагона на службе российских программистов. Программная инженерия. – «Питер», 2003. – 222 с.
3. Кент Б. Экстремальное программирование. – «Питер», 2002. – 260 с.
4. Лайза К, Джанет Г. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд. – М.: «Вильямс», 2010. – 464 с.
5. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. – М.: «Вильямс», 2002. – 448 с.
6. Нейгард М. Release it! Проектирование и дизайн ПО для тех, кому не все равно. – «Питер», 2016. – 320 с.
7. Ральф Д., Ричард Х., Джон В., Эрих Г. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – «Питер», 2016 – 366 с.
8. Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика. – М.: «Вильямс», 2004. – 752 с.
9. Субраманиам В., Хант Э. Этюды на тему быстрой разработки программного обеспечения. – М.: Лори, 2009. – 208 с.
10. Фаулер М. Архитектура корпоративных программных приложений. –
    М.: «Вильямс», 2007 – 544 с.