VI Международная студенческая научная конференция Студенческий научный форум - 2014

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

Для адекватного анализа проблем визуализации данных в процессе разработки ПС рассмотрим наиболее известные и активно используемые в настоящее время процессы. Одной из таких моделей можно по праву считать водопадную (или каскадную) модель, предложенную в 1970 году Уинстоном Ройсом, американским ученым, директором технического цента Lockheed Software, расположенном в штате Техас. Основная мысль модели довольно проста: весь процесс разделен на определенные, четко ограниченные по смыслу и деятельности, фазы, которые выполняются в строгой последовательности. Главным положительным моментом использования каскадной модели можно считать уменьшение количества долгоживущих ошибок.

Другой довольно известной моделью считается модель разработки– Rational Unified Process (RUP),созданная в 1990 х годах. Основным отличием данной модели является обязательное формирование прецедентов использования ПС для описания требований к разрабатываемой ПС. Каждый прецедент (вариант) использования – это описание сценария взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. И наиболее эффективным способом документирования таких сценариев является графическая визуализация прецедентов и связей между ними с помощью различных case-средств.

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

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

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

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

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

Рассмотренные модели процессов разработки ПС можно отнести к классическим, в то время как в течение 1990-х годов становилось все больше разработчиков ПО, которые пытались найти альтернативу традиционным моделям. К 2000 году было предложено целое множество так называемых легковесных процессов. И в 2001 году группой создателей и экспертов по различным легковесным процессам был проведен семинар, на котором было определено новое понятие для легковесных процессов – гибкая разработка, а так же сформулированы основные принципы гибкой разработки программного обеспечения, так называемый Agile Manifesto.

В чем же основное отличие гибкой разработки от традиционных методологий процессов разработки ПС? Для ответа на этот вопрос можно обозначить следующие особенности гибких методологий:

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

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

• графическая визуализация требований к ПС со стороны разработчиков;

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

В качестве примера гибкого процесса разработки ПС можно привести достаточно широко распространенное в наше время, так называемое, экстремальное программирование –XP – разработанное в 1996 году Кентом Беком.

Методология XP была предложена в ходе попытки спасти провальный проект по разработке системы расчета зарплаты для компании Крайслер. Но в 2000 году проект был закрыт, однако новая методология к тому времени уже получила известность и во всю распространялась среди разработчиков ПО. XP наследует все общие принципы гибких методологий, достигая их при помощи 12 инженерных практик. Ниже представлены 5 самых интересных из специфических технологий и практик методологии XP:

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

• архитектура системы должны быть максимально упрощена;

• разработка происходит через тестирование;

• архитектура системы должна постоянно изменяться- перерабатываться и улучшаться;

• время работы команды не должно быть больше 40 часов в неделю.

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

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

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

Библиографический список

1. Абрамова, О.Ф. CASE-технологии: изучать или исключить? / Абрамова О.Ф. //Alma mater (Вестник высшей школы). - 2012. - № 9. - C. 109-110.

2. Абрамова, О.Ф. CASE-технологии: нужны ли они высшей школе? [Электронный ресурс] / Абрамова О.Ф. // 11-я научно-практическая конференция профессорско-преподавательского состава ВПИ (филиал) ВолгГТУ (г. Волжский, 27-28 янв. 2012 г.) : сб. матер. конф. / ВПИ (филиал) ВолгГТУ. - Волгоград, 2012. - 1 электрон. опт. диск (CD-ROM). - C. 323-325.

3. Абрамова, О.Ф. Введение в программную инженерию: методические указания к лабораторной работе на тему "Основные сведения о UML и BOUML. Диаграммы вариантов использования" Сборник «Методические указания». Выпуск 2. / О.Ф. Абрамова, Д.Н. Лясин. - Волгоград: ВолгГТУ, 2013. - номер гос. регистрации 0321301999

4. Электронный ресурс http://library.mephi.ru/

5. Электронный ресурс http://www.RSDN.ru/

6. Электронный ресурс http://www.pcweek.ru/

7. Электронный ресурс ooad.asf.ru/standarts/Library/ModernProcesses/list05.aspx

8. Электронный ресурс http://en.wikipedia.org/wiki/Winston_W._Royce