• Введение

Интернет приложения - очень актуальная сфера, по нескольким причинам:

1. Интернет появился всего 20 лет назад, сфера интернет приложений целиком сформировалась за последние 15 лет и относительно молода.

2. Долгосрочное планирование к данной сфере не применимо: 20 лет назад не было интернета, 14 лет назад не было поисковых систем, 10 лет назад не было социальных сетей, 5 лет назад никто ничего не знал про платформы для приложений в социальных сетях.

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

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

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

2. Разработка - крупная часть работы интернет приложения. В зависимости от размера и особенностей проекта, на разработку уходит 30-80% общего времени работы команды. Процесс разработки интернет приложения является непрерывным (в отличии от процесса разработки в любых других IT сферах, когда создается "коробочное решение" которое не меняется после выпуска, а новая версия выходит отдельно как новый продукт). Сразу после выпуска первой версии приложения продолжают создаваться исправления и дополнения к текущей версии, "наращивание" продукта происходит в режиме реального времени! Таким образом, процесс разработки является центральным - он никогда не прекращается, и от него зависят все остальные процессы, происходящие в проекте.

3. Личная заинтересованность автора. Автор работает над собственным интернет стартапом

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

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

1. Исследовать материал по теме тактического и оперативного планирования, в том числе планирования разработки веб приложений;

2. раскрыть сущность тактического и оперативного планирования интернет приложения;

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

Предметом исследования является процесс разработки интернет приложения. Объект исследования - оперативное и тактическое планирование.

Работа сфокусирована исключительно на планировании процесса разработки и не затрагивает другие важные этапы планирования интернет приложения, такие как:

· Сбыт

· Маркетинговая деятельность

· Кадры

· Финансовая деятельность

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

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

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

I. Теоретические аспекты планирования

· Определение миссии, целей и задач организации

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

· Выработка различных вариантов стратегии;

· Оценка и выбор одной из альтернативных стратегий;

· Разработка окончательного стратегического плана;

· Осуществление среднесрочного тактического планирования, подготовка среднесрочных планов и программ, на основе стратегического плана;

· Разработка оперативного плана на основе стратегического и тактического планов;

· Организация выполнения планов - доведение планов до конкретных исполнителей, в виде заданий, сроков, качественных и количественных показателей;

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

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

Рисунок 1 http://www.fakultet.net/downloads-file-217.html Схемы по стратегическому менеджменту. Маленков Ю.А.

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

Планирование начинается с выбора целей. Основная, наиболее общая цель предприятия, четко выражающая основную причину его существования, называется миссией. Цели разрабатываются для осуществления этой миссии. Миссия - это, главным образом, направление, видение компанией своего предназначения в рамках общества. Как правило, миссия организации определяется на этапе становления организации и редко меняется. Миссия может содержать элементы видения, философии, концепции, образа и намерений организации, описание товаров и услуг предлагаемых организацией, характеристики технологии используемых или предлагаемых организацией, определение основных потребителей и пользователей. Например, миссия известной компании Google состоит в “организации мировой информации, обеспечении ее доступности и пользы для всех” http://www.google.com/intl/ru/corporate/.

Миссия играет большое значение для организации, так как она:

· Является критерием для оценки необходимости всех действий, осуществляемых в компании, платформой для всех плановых решений организации и дальнейшего определения её целей и задач;

· Является базой для определения и обеспечения непротиворечивости целей организации;

· Представляет в явном виде то, для чего существует компания;

· Помогает согласовать усилия всех лиц связанных с организацией (собственников, руководство, персонал, клиентов и др.);

· Способствует созданию корпоративного духа;

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

Цели организации определяются после получения формулировки миссии. Миссия, с одной стороны, дает возможность установить, какие цели необходимо поставить, с другой стороны отсекает часть возможных целей, несоответствующих миссии. Цель - это конкретное состояние отдельных характеристик организации, достижение которых является для нее желательным и на достижение которых направлена ее деятельность Виханский О.С., Наумов А.И. Менеджмент. М: Гардарика, 1998.. В зависимости от специфики отрасли, особенностей среды, характера и содержания миссии каждой организации, устанавливаются собственные цели.

Целями организации могут быть:

· Рыночные цели

o Число пользователей

o Число клиентов, число платных аккаунтов

o Доля рынка

· Производственные цели

o Обеспечить определенный темп разработки

o Создать API

· Организационные цели

o Принять на работу менеджера по управлению IT проектами

o Внедрить систему управления проектами

· Финансовые цели

o Валовая и чистая прибыль

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

· Конкретными (Specific);

· Измеримыми (Measuarable);

· Достижимыми (Archivable);

· Согласованными (Relevant);

o С миссией компании;

o Между собой;

o С теми, кому предстоит их выполнять;

· Определенными во времени (Timebounded);

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

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

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

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

· продуктовая программа;

· планы (задачи и мероприятия) по функциональным сферам деятельности;

· проекты или целевые программы.

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

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

Тактический план выполняет функции координации и контроля.

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

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

Основными задачами тактического планирования являются:

· формирование оптимальной или обеспечивающей достижение требуемого уровня финансового результата продуктовой программы;

· разработка комплекса соответствующих функциональных и проектных мероприятий.

Составление, координация и утверждение тактических планов в подразделениях осуществляется в ходе многоступенчатого, итеративного процесса планирования с учетом взаимовлияния всех подразделений и уровней управления предприятия Ильин А.И., Синица Л.М. Планирование на предприятии: Учеб. пособие. В 2 ч. Ч. 2. Тактическое планирование. - Мн.: ООО «Новое знание», 2000. - 416 с..

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

Зачастую, прошлый опыт может помочь в принятии будущих решений. Напоминание о том, что случилось в прошлом, поможет предупредить ошибку, кроме того, не нужно заново повторять анализ, который дал удовлетворительное решение; Таким образом, когда определённая ситуация, требующая принятия решения, имеет тенденцию часто повторяться, эффективным будет решение повторно применять испытанный временем способ действий, и выработать стандартизированные указания. Формально выраженные стандартизированные указания такого рода называются “процедурой”. Обычно процедуры описывают последовательность действий, которые необходимо предпринять в конкретной ситуации. В сущности, процедура является запрограммированным решением, которое исключает необходимость “изобретать заново”. Индивид, действующий согласно процедуре, имеет малую свободу действий.

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

Очевидно, чтобы планы были реализованы, кто-то, должен фактически выполнить каждую из задач, вытекающих из целей организации. Поэтому, после того как тактический план завершен, необходимо конкретизировать его до реальных действий членов организации. В этом суть оперативного планирования - согласование всех элементов производственного процесса, во времени и пространстве с необходимой степенью его детализации. Афитов Э.А. Планирование на предприятии: Учеб. Пособие. - Мн.: Выш. шк., 2001. - 285 с. Оперативное планирование конкретизирует и детализирует производственную программу в течение декады, недели или суток, выполняет координирующую функцию, обеспечивая слаженную работу всех подразделений предприятия. Основной задачей оперативного планирования является обеспечение на предприятии слаженного и ритмичного хода всех производственных процессов, для наибольшего удовлетворения потребностей рынка, эффективного использования имеющихся ресурсов и максимизации прибыли.

II. Особенности сферы интернет приложений и проблемы разработки

2.1 Основные проблемы разработки интернет приложений

o обработка ошибок

· Уязвимости (возможность получить доступ к личным данным пользователей, либо исполнить вредоносный код на сервере)

· Невозможность реализации архитектуры

· Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.

· Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

· Недостаточная производительность получаемой системы, нехватка ресурсов

· Повторное использование кода

· Повторное создание уже существующих инструментов в процессе работы ("изобретение велосипеда")

· Неоправданно высокие издержки внесения изменений в приложение, например, если для внедрения новой функции требуется изменение и/или тестирование всех компонентов системы.

· Низкое качество, наличие ошибок в коде, неработоспособность системы

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

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

· Невозможность реализации архитектуры

· Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.

· Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

· Недостаточная производительность получаемой системы, нехватка ресурсов

· Повторное использование кода

· Повторное создание уже существующих инструментов в процессе работы ("изобретение велосипеда")

· Неоправданно высокие издержки внесения изменений в приложение.

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

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

“Популярная поговорка `семь раз отмерь, один раз отрежь' очень актуальна на этапе конструирования ПО, затраты на который иногда составляют аж 65% от общего бюджета проекта. В неудачных программных проектах конструирование иногда приходится выполнять дважды, трижды и даже больше”. С. Макконнелл Совершенный код. Мастер-класс // Электронное издание. - 2010. с.46

Важность планирования в разработке трудно переоценить - согласно анализу относительной дороговизны исправления дефектов в зависимости от этапов их внесения и обнаружения, приведенному в книге "Совершенный код", в среднем, дефект архитектуры, исправление которого на этапе проектирования архитектуры стоило бы 1000$, во время тестирования ПО выльется как минимум в 15 000$

Рисунок 2 С. Макконнелл Совершенный код. Мастер-класс // Электронное издание. - 2010. с.47

В дальнейших главах детально рассмотрены аспекты тактического и оперативного планирования в разработке интернет приложения.

3.1.1 Требования

Важность определения предварительных условий

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

Конструирование - последний этап работы, поэтому ко времени начала конструирования успех проекта уже частично предопределен.

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

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

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

Влияние итеративных подходов на предварительные условия

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

Адекватное внимание к выполнению предварительных условий позволяет снизить затраты независимо от типа используемого подхода.

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

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

Предварительные условия, связанные с определением проблемы

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

Предварительные условия, связанные с выработкой требований

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

Важность явного набора требований обусловлена несколькими причинами.

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

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

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

Адекватное определение требований - одно из важнейших условий успеха проекта.

Стабильность требований

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

3.1.2 Архитектура

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

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

Хорошая архитектура облегчает конструирование. Плохая архитектура делает его почти невозможным.

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

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

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

Архитектура должна определять основные компоненты программы. В зависимости от размера программы её компонентами могут быть отдельные классы или подсистемы, состоящие из нескольких классов. Каждый компонент является классом или набором классов/методов, которые в совокупности реализуют высокоуровневые функции программы, такие как взаимодействие с пользователем, отображение Web-странцы, интерпретация команд, инкапсуляция бизнес-правил и доступ к данным. За каждую функцию приложения, указанную в требованиях, должен отвечать хотя бы один компонент. Если функцию реализуют несколько компонентов, они должны сотрудничать, а не конфликтовать.

В архитектуре должна быть четко определена ответственность каждого компонента. Компонент должен иметь одну область ответственности и "знать" как можно меньше об областях ответственности других компонентов.

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

Список типичных разделов архитектуры:

· Основные классы

· Организация данных

· Бизнес правила (и бизнес процессы)

· Пользовательский интерфейс

· Управление ресурсами

· Безопасность

· Взаимодействие с другими системами

· Интернационализация/локализация

· Обработка ошибок

· Возможность реализации архитектуры

· Готовые компоненты

· Повторное использование кода

· Стратегия внесения изменений

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

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

В архитектуре должны быть обоснованы важнейшие принятые решения.

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

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

Первому уровню проектирования соответствует вся система.

Второму уровню соответствует разделение системы на подсистемы и пакеты.

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

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

Третьему уровню соответствует разделение подсистем на классы

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

Четвертый уровень - разделение классов на методы

Полное определение методов класса часто позволяет лучше понять его интерфейс, что может подтолкнуть к соответствующему изменению интерфейса, т. е. к возвращению на уровень 3.

Пятый уровень - проектирование методов

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

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

3.2.2 Планирование в процессе конструирования приложения

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

· Кодирование программного решения конкретной заданной задачи

· Тестирование созданного блока (может назначаться “тестировщикам”)

· Интеграция блока в систему

· Тестирования системы с новым блоком (может назначаться “тестировщикам”)