Очередной веб лог…

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

Введение

Ну что ж, вот я и добрался до напиания вводного материала, уже связанного с проектом непосредственно. Первая часть правда получилась скучновата, из-за необходимости объяснить чем именно мы будем заниматься и почему именно так, но надеюсь что это никого не отпугнет, учитывая, что нас тут собралось двести пятдесят человек Для начала стоит разъяснить чем же собственно отличается UP (унифицированый процесс) от остальных процессов разработки. Думаю что большинство из нас (разработчиков) сталкивался с несколькими принципиально разными подходаим к разработки ПО: безпринципное, каскадное или же гибкое (agile/xp).

Основные виды процессов разработки

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

Каскадное — следующая ступень развития процесса разработки. Разработчики, у которых за плечами более двух-трех коммандных проектов, стараются разрабатывать именно на основе этого принципа, который подразумевает три стадии: постановка задачи (написания ТЗ), проектирование (на этой стадии требования пытаются заморозить и более не вносить изменений в ТЗ) и собственно реализация. Основная проблема же возникает из-за того, что врядли существует хоть один более-менее серьездный проект, требования в бизнес-логике (далее — БЛ) которого оставались неизменными от начала разработки и до момента развертывания. Да, обычно около 60-80%% БЛ меняется в процессе разработки из-за многих факторов.

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

UP (Унифицированный процесс) - это все лучшее из традиций гибкой и каскадной разработки. В нем есть и время на проектирование и время на отработку изменяющихся требований к системе. Это достигается за счет разбиения всего процесса на итерации (UP — итеративный процесс), которые в свою очередь состоят из нескольких этапов: анализа, проектирования, разработки и тестирования (обратной связи). Основной плюс данного подхода в том, что у нас есть достаточное время на проектирование системы, а так же то, что в конце каждой итерации мы получаем качетвенный feedback по реализованным задачам, и на основании этого фидбэка, в последующей итерации, вносим изменения в проект и реализацию, что позволяет постепенно прийти к решению, которе уже не будет нуждаться в доработках (во всяком случае ближайшее время)

Начальная фаза. Ее задачи

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

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

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

• выбрать необходимо не более 5-10%% от общего кол-ва прецедентов
• выбранные прецеденты должны быть основополагающими среди оставшихся (тоесть корневыми, либо такими, с которыми связано наиболее высокие риски)

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

Собственно сегодняшняя цель

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

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

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

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

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

Отдельным требованием является максимальная приближенность к «обычному» пользователю и не стать «бухгалтерами для бухгалтеров писанной»© (спасибо kellas за формулировку )»

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

• регистрация пользователя

• авторизация пользователя
• завершение сеанса
• создание/редактирование счета (кредитного, наличного, банковского)
• создание/редактирование операции (expense, income)
• создание/редактирование чека (трата, пополнение, перевод)
• переход в оффлайновый режим использования
• возврат в онлайн режим (с синхронизацией)
• получение разичных финансовых отчетов
• создание ежемесячных платежей
• предоставление различных прав по доступу/редактированию бюджета другим пользователям системы
• импорт данных в систему из других форматов (таких как QIF, csv и пр.)

А еще мне пришлось зарегистрировать домен. Оригинальностью я блестать не собирался, поэтому выбрал обычное для такой системы сокращение: HomeMoney. Учитывая что проект полностью Сетевой (net) и изначально располагается в Украине (ua), то окончательный вариант принял следующий вид: http://hmoney.net.ua, а сам проект получил немного стилизованое название hMoney

Последним на сегодня осталось выбрать прецеденты, которые необходимо реализовать в последующей итерации. Так как основа проекта — ведение учета финансов, а рискам более всего подвержены следующие задачи: «создание/редактирование счета (кредитного, наличного, банковского) », «создание/редактирование операции (expense, income) », «создание/редактирование чека (трата, пополнение, перевод) », то первые два из них и выберем.

В следующей серии

• знакомство с BOUML — программой построения диаграмм
• проектирование выбранных прецедентов на основании паттернов
• выбор фундамента разработки и непосредственное решение поставленных задач

Постскриптум

Прошу строго не судить — это моя первая статья такого объема, так что пожелания о стиле написания, подборке материалов и акцентирование внимания, прошу оставлять в комментариях — постараюсь прислушаться

Tags: hMoney, UP, начальная фаза, процесс, разработка

Также рекомендую к прочтению:

• UP. Первая итерация Инструменты разработки
• UP. Итерация вторая
• kyivstar снова жжот

This entry was posted on Пятница, Октябрь 17th, 2008 at 22:21 and is filed under Проект hMoney по шагам. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.