Создание технологии разработки экономического программного обеспечения на базе 1С Предприятие 8

Федеральное государственное бюджетное образовательное учреждение высшего образования
«Балтийский государственный технический университет «ВОЕНМЕХ» им. Д.Ф. Устинова»
(БГТУ «ВОЕНМЕХ» им. Д.Ф. Устинова)


ДОПУСКАЕТСЯ К ЗАЩИТЕ:

Заведующий кафедрой
И9
Матвеев С.А.


Фамилия ИО

подпись
«         

»


20         г.



МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ
Романовой Юлии Алексеевны
Фамилия, имя, отчество обучающегося
На тему
Исследование технологий разработки программного обеспечения


Направление подготовки
09.04.04

Программная инженерия

код 

полное наименование направления

Магистерская программа
Процессы и методы разработки программного

наименование магистерской программы
обеспечения





Руководитель магистерской диссертации

Обучающийся
	к.т.н., доцент



Романова Ю.А.
Ученая степень, ученое звание

подпись

Фамилия И.О.


Каминский В.Н.

«

»

2018

г.
подпись

Фамилия И.О.




«

»

20
18
г.

Консультанты

Руководитель магистерской программы




к.т.н., доцент

подпись

Фамилия И.О.
Ученая степень, ученое звание






Гущин В.Н.

подпись

Фамилия И.О.
подпись

Фамилия И.О.




«

»

20
18
г.

подпись

Фамилия И.О.


САНКТ-ПЕТЕРБУРГ
2018 г.
РЕФЕРАТ
Пояснительная записка 91 с., 25 рис., 6 табл., 28 источников.
УПРАВЛЕНИЕ ПРОЕКТАМИ, ГИБКИЕ ТЕХНОЛОГИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ПРОЕКТИРОВАНИЕ, МЕТОДЫ УПРАВЛЕНИЯ ПРОЕКТАМИ ПО РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Магистерская диссертация нацелена на исследование технологий разработки программного обеспечения.
В ходе работы была сформулирована постановка задачи, произведен анализ предметной области, проанализированы современные гибкие технологии программного обеспечения, сформирована технология разработки программного обеспечения, реализован проект по разработке и внедрению подсистемы в «1С: ERP Управление предприятием» с помощью предложенной технологии разработки.


Содержание
РЕФЕРАТ	2
ВВЕДЕНИЕ	5
1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	8
1.1	История развития теории управления разработки программного обеспечения	8
1.2	Модели жизненного цикла программного обеспечения	12
1.2.1 Каскадная модель жизненного цикла ПО	13
1.2.2 Итеративная модель жизненного цикла ПО	14
1.3    Гибкие технологии разработки программного обеспечения	15
1.3.1 Технология разработки «Scrum»	17
1.3.2 Технология разработки «RUP»	20
1.3.3 Технология разработки «Экстремальное программирование»	24
1.3.4 Технология разработки «Бережливое производство программного обеспечения» (Lean software development)	29
2 СОЗДАНИЕ ГИБКОЙ ТЕХНОЛОГИИ РАЗРАБОТКИ ЭКОНОМИЧЕСКОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	31
2.1 Модель жизненного цикла	31
2.1.1 Создание списка историй	31
2.1.2 Планирование спринта	32
2.1.3 Проектирование	38
2.1.4 Поиск реализованных функций	40
2.1.5 Программирование	40
2.1.6 Тестирование	40
2.1.7 Демонстрация-внедрение	44
2.2 Методы управления представленной технологии	44
2.2.1 Доска задач	44
2.2.2 Покер-планирование	45
2.2.3 Ежедневное собрание	48
2.2.4 Управление рисками в процессах разработки программного обеспечения	48
2.3 Методы разработки программного обеспечения технологии	51
2.3.1 Периодическое парное программирование	51
2.3.2 Рефакторинг	52
2.3.3 Совместный анализ кода	52
3 ПРИМЕНЕНИЕ РАЗРАБОТАННОЙ ТЕХНОЛОГИИ В ОРГАНИЗАЦИИ «УЛЬТРАЮНИОН»	54
3.1 Описание проекта	56
3.2 Управление проектом с помощью разработанной технологии	56
3.2.1 Создание списка историй	57
3.2.2 Планирование спринта №1	63
3.2.3 Покер-планирование	64
3.2.4 Поиск реализованных функций	67
3.2.5 Программирование	68
3.2.6 Рефакторинг	74
3.2.7 Совместный анализ кода	76
3.2.8Тестирование	77
4 ЭКСПЕРИМЕНТАЛЬНАЯ ПРОВЕРКА ЭФФЕКТИВНОСТИ ПРИМЕНЕНИЯ ПРЕДЛОЖЕННОЙ ТЕХНОЛОГИИ	81
ЗАКЛЮЧЕНИЕ	86
СПИСОК ЛИТЕРАТУРЫ	88
ПРИЛОЖЕНИЕ А	91



ВВЕДЕНИЕ
     Управление проектами разработки программного обеспечения на настоящий момент стало обширным полем как научной, так и практической деятельности. Это объясняется тем, что, цитируя Гласса [1], “разработка программ является концептуально сложным занятием”. Брукс добавляет [2], что трудность создания программных систем возникает благодаря их “несократимой сущности”, неотъемлемыми свойствами которой являются обусловленная размерами продукта сложность и обусловленная многочисленными связями между участниками проекта согласованность и изменяемость.
     Однако, за последнее время появилось много новых технологий управления программными проектами, которые несмотря на невозможность революционного прорыва в дисциплине управления программными проектами, позволяют повысить эффективность управления. 
     Целью исследования является создание технологии разработки экономического программного обеспечения на базе «1С: Предприятие 8», внедрение технологии на предприятии и управление проектом разработки программного обеспечения с помощью неё.
     Для достижения указанной цели в диссертации поставлены следующие задачи:
     * разработка модели жизненного цикла проектов для экономического программного обеспечения;
     * создание гибкой технологии разработки экономического программного обеспечения;
     * управление проектом в организации «УльтраЮнион»» с помощью разработанной технологии;
     * анализ результатов. 
     Объектом исследования являются проекты в сфере разработки программного обеспечения. 
     Предметом исследования являются технологии разработки программного обеспечения.
     Практическая значимость и апробация работы. Разработанная технология может использоваться компаниями-производителями экономического программного обеспечения для управления проектами.
     Разработанная технология была внедрена в организации «УльтраЮнион», с помощью неё был успешно завершен проект по разработке экономического программного обеспечения.
     Публикации.
     1. Романова Ю.А. Основные риски разработки программного обеспечения. // Международный журнал гуманитарных и естественных наук. – том 5, 2016 г, – с. 243.
     2. Романова Ю.А. История развития управления проектами разработки программного обеспечения. // Технологии, инновации и предпринимательство: сборник научных трудов по материалам I Международной научно-практической междисциплинарной конференции, 31 мая 2017 г. Санкт-Петербург: НОО «Профессиональная наука», 2017. 331 с.
     3. Романова Ю.А. Гибкие технологии разработки программного обеспечения. Scrum. // Техника, технологии, ресурсы и производство: приоритетные направления развития и практические разработки: сборник научных трудов по материалам I Международной научно-практической конференции, 20 августа 2017 г. Екатеринбург: НОО «Профессиональная наука», 2017. 222 с.
     Объем и структура диссертации. 
     Диссертация состоит из введения, трех глав, заключения и библиографического списка. Общий объем работы составляет 91 страницу, включая 6 таблиц и 25 рисунков. 
     Во введении определяется предмет исследования и обосновывается актуальность исследования, сформулированы цели и задачи исследования.
     В первой главе «Теоретические основы управления разработкой программного обеспечения» приведен анализ эволюции и современного состояния теории управления разработкой программного обеспечения.
     Во второй главе «Создание гибкой технологии разработки экономического программного обеспечения» описывается модель жизненного цикла технологии, методы управления процессами разработки и методы разработки программного обеспечения.
     В третьей главе «Применение разработанной технологии в организации «УльтраЮнион»» описываются процессы и результаты разработки программного обеспечения.
     В заключении сформированы основные выводы.

     1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
     1.1 История развития теории управления разработки программного обеспечения 
     Как идея руководство проектами имеет долгую предысторию. Если задуматься обо всем, что было создано за всю историю цивилизованного мира, наберется несколько тысячелетий опыта реализации проектов, из которого можно извлечь уроки. Можно провести пунктирную линию от современных разработчиков программного обеспечения через века к строителям египетских пирамид или к архитекторам римских акведуков. Соответственно своим эпохам руководители проектов выполняли сходные роли по применению технологий для решения характерных для своего времени проблем. 
     Вся история инженерных проектов свидетельствует о том, что многие из них обладают четко обозначенными общими чертами. У них есть технические требования, проектные решения и ограничения. Они зависят от средств общения, принятия решений и сочетания творческого и логического мышления. Зачастую в проектах фигурирует рабочий график, бюджет и заказчик. Наиболее важной и основной задачей проектов является объединение усилий разных людей в единое, согласованное целое, приносящее пользу другим людям или заказчикам. Из чего бы ни был построен проект, из кода HTML, C++ или стали и бетона, существует незыблемый, основной набор понятий, разделяемый большинством проектов.
     Чтобы понять историю управления проектами, необходимо определить её ключевые категории: проект и управление проектами. До недавнего времени в нашей стране и за рубежом под проектом понимался комплект чертежей, в которых отражалась объемно-планировочные, конструктивные, организационные, технологические и другие решения в различных областях промышленности и производства. Известны названия:
     * технический проект;
     * рабочий проект;
     * проект производства работ.
     Всё перечисленное мы будем называть проектно-сметной документацией. Попытаемся разобраться, что такое проект в современном понимании, используя термины, принятые в зарубежной и российской литературе.
     В стандартах Института управления проектами США (PBBoK, PMI) под проектом понимается временное усилие (действие), предпринятое для создания уникального продукта или услуги[3].
     В «Основы профессиональных знаний. Национальные требования к компетентности (НТК) специалистов» СОВНЕТ проект трактуется как целенаправленное ограниченное во времени мероприятие, направленное на создание уникального продукта или услуги. 
     И. И. Мазур, В. Д. Шапиро, Н. Г. Ольдерогге дают следующее определение: проект - это целенаправленное, заранее проработанное и запланированное создание или модернизация физических объектов, технологических процессов, технической и организационной документации для них, материальных, финансовых, трудовых и иных ресурсов, а также управленческих решений и мероприятий по их выполнению.
     Как видно из определений, в настоящее время отсутствует единый подход к понятию «проект» как в отечественной, так и в зарубежной литературе. Под проектом могут пониматься любые виды идей и действий, которые характеризуются конкретной целью; временем начала и окончания работ; финансовыми ограничениями и потреблением различного вида ресурсов.
     Под проектом понимается некоторое действие (мероприятие), в то же самое время проект является и продуктом, который можно купить или продать. В этих подходах отражается дуалистическая природа понятия «проект», которую необходимо принимать во внимание при изучении данной дисциплины.
     Проанализировав основные составляющие проектов, можно сформулировать наиболее всеобъемлющее определение проекта. В данной диссертации будем придерживаться следующего термина.
     Проект - это идея и действия по ее реализации с целью создания продукта, услуги или другого полезного результата [11].
     Проекту так же свойственна зависимость между четырьмя показателями, которые представлены на рисунке 1: бюджет (заданные в плане оценочные затраты на проект), длительность (период времени, необходимый для выполнения проекта), область охвата (цели и задачи проекта) и качество. 

Рисунок 1 – Треугольник проекта
	Зависимость между показателями проявляется в виде следующих взаимных ограничений:
      1. Качество работы ограничивается бюджетом, длительностью и целями проекта (областью охвата).
     2. Руководитель проекта может оперировать ограничениями.
     3. Изменения в одном ограничении требуют изменений в других.
     Например, проект может быть завершен быстрее за счет увеличения объема бюджета. Аналогичным образом, увеличение объема может потребовать эквивалентного увеличения бюджета и длительности. Сокращение бюджета без корректировки графика приведет к снижению качества. 
     Согласно PMBoK [3], управление проектами - это процесс применения знаний, навыков, методов, средств и технологий к проектной деятельности с целью воплощения замыслов участников проекта.
     Технология — совокупность методов и инструментов для достижения желаемого результата [4].
     Гибкая технология разработки — совокупность методов и инструментов для разработки программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри рабочих групп.
     В 1953 году инженер компании Toyota Тайичи Оно создал технологию управления проектами Kanban [5].
     В 1968 г. Уинстон Ройс в статье [6] описал две основные модели жизненного цикла разработки программного обеспечения: каскадную и итеративную модели.
     В 1975 г. Фредерик Брукс в своей работе «Мифический человеко-месяц» описал основные проблемы проектов разработки ПО и предложил их решения, он обратил внимание на существенные отличия в производительности отдельных разработчиков и предложил эффективную модель команды проекта.
     В 1986 году Хиротака Такэути и Икудзиро Нонака в статье «The New Product Development Game» в журнале «Гарвардский Деловой Обзор» описали технологию SCRUM. [14]
     В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений «Microsoft Solutions Framework».
     В 1995 году Филипп Крачтен разработал «Рациональный унифицированный процесс» (RUP, Rational Unified Process) [7]. 
     В 1996 г. Кент Бек предложил технологию «экстремального программирования» (XP, eXtreme Programming) [13].
     В 1989 г. Технология PRINCE (PRojects IN Controlled Environments, проект в контролируемой среде) была разработана в Великобритании Central Computer and Telecommunications Agency (CCTA) по заказу UK Office of Government Commerce как стандарт ведения ИТ-проектов. Со временем границы использования этого стандарта расширились, и сегодня не ограничиваются только сферой ИТ. Методология PRINCE является расширением концепции управления проектами. В 1996 г. вышел стандарт PRINCE2, который стал стандартом де-факто в управлении проектами в Великобритании.
     В феврале 2001 в штате Юта США был выпущен «Манифест гибкой технологии разработки программного обеспечения» [8]. 
     В 2009 г. была популяризована технология «DevOps» (акроним от англ. development и operations) на серии встреч «DevOps Days», которые начали проходить в Бельгии. С тех пор «DevOps-дни» прошли в Индии, США, Бразилии, Австралии, Германии и Швеции.  [25]
     В 2013 г. PMI совместно с IEEE Computer Society выпустили Расширение Software Extension to the PMBOK Guide [9]. Расширение даёт сбалансированный взгляд на методы, инструменты и подходы к управлению проектами разработки программного обеспечения, описывает сложные жизненные циклы проектов, адаптируя их под сегодняшние реалии.
     Таким образом, история управления проектами разработки программного обеспечения развивается, потому что разработчики ПО сталкиваются с необходимостью эффективного подхода и быстрого результата, с меньшими затратами и с более высоким качеством.
     1.2 Модели жизненного цикла программного обеспечения
     Модели жизненного цикла ПО являются центральной частью технологий разработки программного обеспечения. Впервые понятие «модель жизненного цикла» ввел в широкий обиход Уинстон Ройс в 1970 г. В статье «Управление большими компьютерными системами» [6] он описал каскадную и итеративную модели жизненного цикла ПО, которые являются каркасом большинства проектов, выявил недостатки каскадной модели и определил, как она может быть трансформирована в итеративную модель.
     Каждый проект разработки программного обеспечения проходит путь с момента своего создания через ряд промежуточных этапов и до его завершения, когда информационная технология полностью создана или внедрена. Другими словами, можно сказать, что у проекта есть фазы, которые называются общим термином - жизненный цикл. Свод знаний по управлению проектами (PMBoK) [3] дает следующее определение понятию жизненный цикл проекта:
     «Жизненный цикл проекта – это набор, как правило, последовательных и иногда перекрывающихся фаз проекта, названия и количество которых определяются потребностями в управлении и контроле организации или организаций, вовлеченных в проект, характером самого проекта и его прикладной областью».
     Жизненный цикл помогает координировать усилия участников проекта, так как он учитывает некоторую специфику. К примеру, руководитель проекта должен понимать, какое влияние оказывают входы и выходы одного этапа жизненного цикла на остальные. Жизненный цикл проекта имеет прямую связь с его финансированием, так как, только спланировав фазы его реализации, можно прогнозировать стоимость и издержки. 
     1.2.1 Каскадная модель жизненного цикла ПО
     Каждая стадия каскадной модели заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Каскадная модель представлена на рисунке 2. Ключевым моментом каскадной модели является ее последовательный характер, что означает, что каждая фаза не может начаться, если не завершена предыдущая.

Рисунок 2 – Каскадная модель жизненного цикла ПО
     Данная модель требует четкого планирования в самом начале проекта, и это всегда сопровождается написанием больших технических заданий, а результат работающей программы можно наблюдать только в конце.
     Проблема заключается в том, что на деле ни один проект по разработке программного обеспечения нереально спроектировать таким образом, чтобы заранее предугадать все требования пользователей. Помимо всего прочего, если что-то было упущено в работе проекта на его начальных стадиях, исправить это, находясь на завершающих этапах разработки программного обеспечения, очень сложно и требует дополнительных затрат.
     1.2.2 Итеративная модель жизненного цикла ПО
     Итеративная модель представляет собой процесс частичной реализации всей системы и медленного наращивания функциональных возможностей. Пример итеративной модели изображен на рисунке 3.

Рисунок 3 – Итеративная модель жизненного цикла ПО
     Функциональность всей системы может быть глобально оценена уже в начале проекта (на первых итерациях), а необходимые второстепенные изменения могут быть сделаны в течение следующих итераций. Более того, итерации могут служить средством обратной связи для измерения качества выполнения проекта и продуктивности работы команды участников.
     Таким образом, необходимо понимать, что там, где целесообразно применять каскадную модель жизненного цикла программного обеспечения не стоит использовать итеративную. Например, для предприятий государственного сектора, где по требованиям нормативной базы ведомства (Министерства) требуется полное документирование проекта и автоматизированной системы (техническое задание в соответствии с ГОСТ-ами 34 серии, технический проект, расширенная пользовательская документация и др.) – необходимо применять каскадную модель жизненного цикла программного обеспечения.
     1.3    Гибкие технологии разработки программного обеспечения
     Манифест гибкой разработки программного обеспечения (Agile Manifesto) [8] — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения, разработанный в феврале 2001 года на встрече 17 независимых практиков нескольких технологий программирования, именующих себя «Agile Alliance». Примечательно, что Agile Manifesto не содержит практических советов. На рисунке 4 представлена краткая история технологий разработки ПО.

Рисунок 4 – Краткая история технологий разработки ПО
     Основные идеи манифеста гибких технологий:
     * люди и взаимодействие важнее процессов и инструментов;
     * работающий продукт важнее исчерпывающей документации;
     * сотрудничество с заказчиком важнее согласования условий контракта;
     * готовность к изменениям важнее следования первоначальному плану.
     Принципы, которые разъясняет манифест:
     * удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
     * приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
     * частая поставка рабочего программного обеспечения (каждый месяц или неделю);
     * тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
     * проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
     * рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
     * работающее программное обеспечение — лучший измеритель прогресса;
     * спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
     * постоянное внимание улучшению технического мастерства и удобному дизайну;
     * простота — искусство не делать лишней работы;
     * лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
     * постоянная адаптация к изменяющимся обстоятельствам. 
     Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.[23]
     1.3.1  Технология разработки «Scrum» 
     Scrum — технология гибкой разработки ПО. Технология делает акцент на качественном контроле процесса разработки.
     Подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game [26]. Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты.
     Рассмотрим основные понятия Scrum.
     Спринт — итерация, в результате которой создается релиз программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру, согласно Scrum-стандарту компании Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а заказчик уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок.
     Журнал продукта — это список требований к функциональности программного обеспечения, упорядоченный по их степени важности.
     Журнал пожеланий спринта — содержит функциональность, выбранную заказчиком из журнала пожеланий проекта.
     Журнал продукта создается заказчиком после анализа потребностей бизнеса в виде списка требований к программному обеспечению. Иными словами, заказчиком описываются главные желаемые задачи разрабатываемой или внедряемой программы. После этого каждому требованию приписывается степень важности для заказчика, то есть приоритет, причем наиболее приоритетные задачи должны находиться выше по списку в журнале продукта, чем наименее приоритетные. В течение всего проекта заказчик имеет право добавлять в журнал продукта новые требования или модифицировать старые. Именно такая возможность позволяет данному подходу быть «гибким к изменениям». В реальной жизни у заказчика может постоянно меняться список требований к программному обеспечению, соответственно, заказчик может вести их непосредственный учет и служить «соединяющим» звеном между компанией, интересы которой заказчик представляет, и Scrum-командой (разработчиками). Выбранные на определенный спринт требования из журнала продукта заносятся в журнал спринта. 
     В отличие от журнала продукта, который может быть изменен или пополнен заказчиком в любой момент времени проекта, журнал спринта на время конкретной итерации является фиксированным и утвержденным командой. Задачи из журнала спринта могут быть исключены только в форс-мажорных ситуациях, когда их выполнение больше не будет нацелено на успех всего проекта. Как было сказано ранее, технология Scrum вовсе не исключает документацию полностью, ее просто намного меньше, чем в традиционном подходе водопадной разработки. На практике все решается заказчиком и Scrum-командой: если обе стороны приходят к соглашению оформить процесс реализации какой-то задачи из журнала продукта, то разработчиками создается соответствующий небольшой документ. Данный документ не будет являться подобием технического задания, на него не будут ссылаться при обсуждении контрактных условий, он необходим для более конкретного понимания функционирования каких-либо частей программы. 
     Основные роли в Scrum:
     * Scrum-мастер — проводит совещания, следит за соблюдением всех принципов Scrum, разрешает противоречия и защищает команду от отвлекающих факторов;
     * заказчик — представляет интересы конечных пользователей и других заинтересованных в продукте сторон;
     * команда разработки — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. Д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. 
     Собрания.
1. Планирование спринта.
     Происходит в начале новой итерации Спринта. Из журнала продукта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда. На основе выбранных задач создается журнал пожеланий спринта. Каждая задача оценивается в идеальных человеко-часах. Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи.
     Продолжительность совещания ограничена сверху 4—8 часами в зависимости от продолжительности итерации, опыта команды и т. п. и делится на 2 части:
     * первая часть совещания: заказчик и команда выбирают задачи из бэклога продукта;
     * вторая часть совещания: только команда обсуждает технические детали реализации, наполняет бэклог спринта.
2. Ежедневное совещание. 
     На ежедневном совещании каждый участник команды стоя рассказывает о достигнутых результатах за прошлый день, обещает, что будет достигнуто сегодня и делится проблемами, из-за которых ему не удается добиться результата. По окончании совещания каждый член команды осведомлен, кто и чем будет заниматься сегодня, и как разрешить возникшие трудности. Если в рамках совещания какой-либо вопрос не разрешен, то он решается в рабочем порядке при участии руководителя, чтобы не отнимать у всей команды время.
     Такая схема переговоров помогает держать тонус в коллективе: каждый участник стремится каждый день достигать какого-то результата, в противном случае ему нечего будет рассказать на очередном ежедневном совещании. Также эти собрания помогают вовремя выявить риски, угрожающие успешному завершению спринта и нивелировать их.
3. Обзор итогов спринта.
     Проводится в конце спринта. Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам. Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт). Нельзя демонстрировать незавершенную функциональность.
4. Ретроспективное совещание.
     Проводится в конце спринта.  Члены команды высказывают своё мнение о прошедшем спринте.
     Отвечают на два основных вопроса:
     * что было сделано хорошо в прошедшем спринте;
     * что надо улучшить в следующем.
     Таким образом, команда разработчиков выполняет улучшение процесса разработки (решает вопросы и фиксирует удачные решения).
     1.3.2 Технология разработки «RUP»
     Rational Unified Process (RUP) [28] – итеративная технология разработки программного обеспечения, созданная в Rational Software Corporation (подразделение IBM с 2003 года). Её цель - обеспечить производство высококачественного программного обеспечения, которое удовлетворяет потребности конечных пользователей, в рамках прогнозируемого графика и бюджета.
     В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML).
     Итерационная разработка программного обеспечения в RUP предполагает разделение проекта на несколько мелких проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены.
     RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта — анализу и моделированию. Таким образом, эта методология направлена на снижение коммерческих рисков посредством обнаружения ошибок на ранних стадиях разработки. Технические риски оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми.
     RUP подразделяет процесс на четыре основные фазы во времени: Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание). К сожалению, в русском языке нет установившейся терминологии, поэтому в дальнейшем мы будем использовать английские термины. На рисунке 5 представлено широко распространенное изображение фаз RUP. Целями каждой из данных фаз являются:
     * начало — понимание, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;
     * уточнение плана — понимание, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;
     * конструирование — создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);
     * переход — создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.
      

Рисунок 5 - Фазы RUP
     Методология RUP основана на девяти основных потоках, являющихся элементами итерации жизненного цикла ПО:
     * деловое моделирование — предполагает анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей;
     * требования — формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases (пользовательских историй) — формальное отображение требований пользователя в UML. Результатом являются документы уровня менеджмента;
     * анализ и моделирование — предполагает перевод собранных требований в формализованную программную модель. Результатом является описание системы на фазе реализации (технический проект) — это документы уровня разработчиков системы. Язык формализации — Unified Modelling Language (UML). В процессе итеративной разработки эволюционировать будет продукт именно этого потока — модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов. Здесь имеется в виду тот факт, что результатом разработки является не модель, а исполняемый код, поэтому заказчик обычно не очень любит платить за моделирование, так как модели не являются продуктом, который ему нужен);
     * выполнение — предполагает собственно написание кода. Элементы кода в RUP уже созданы на этапе анализа и дизайна, так как средство реализации UML — Rational Rose — позволяет создавать элементы кода на нескольких языках программирования;
     * испытание — предполагает тестирование продукта на данной итерации. Стоит специально отметить, что regression testing (возвратное тестирование, тестирование «неухудшения» продукта) в данном случае должно содержать все актуальные тесты от предыдущей итерации и приемосдаточные тесты от предыдущей transition-фазы;
     * развертывание — предполагает установку продукта на полигоне заказчика, подготовку персонала, запуск системы плюс приемо-сдаточные испытания, подготовка стандартов упаковки и распространения продукта, передача материалов отделу продаж (действия опциональны в зависимости от специфики продукта).
     Особенностью реализации RUP являются временные акценты, а именно — на каких итерациях будут доминировать те или иные потоки, а также наличие универсального языка и набора утилит, позволяющего описывать процесс разработки.
     1.3.3 Технология разработки «Экстремальное программирование»
     Экстремальное программирование (XP) [17] – это технология разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований.
     Основные принципы экстремального программирования.
     1. Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования. Описание пользовательских историй короткое – 1-2 абзаца, тогда как варианты использования обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. Пользовательские истории пишутся самими пользователями, которые в экстремальном программировании являются частью команды, в отличие от вариантов использования, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в технологии экстремального программирования стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного.......................