Учебное_пособие_ТИПиС и Глоссарий. Учебное пособие для студентов очной и заочной форм обучения представляет собой подборку материала по курсу Теория информационных систем и процессов
 Скачать 5.1 Mb.
|
3.2.2. Процесс объектно-ориентированного моделирования/проектирования: начальная фаза; исследование; построение; внедрение; дополнительные средстваВ данном пункте представлено описание стандартного процесса объектно-ориентированной разработки информационного (программного) обеспечения бизнеса – Рационального Унифицированного Процесса – РУП (Rational Unified Process). Для его составления использованы работы. Основным направляющим фактором разработки ПО является его системная архитектура. Архитектура программной системы представляет собой совокупность существенных решений, охватывающих ее структурные и поведенческие аспекты, использование (функциональность), производительность, гибкость, возможность повторного использования компонент, полноту, ограничения и компромиссы, а также эстетические вопросы. Выбор архитектуры должен учитывать аспекты рассмотрения создаваемого программного продукта представленные на рисунке 3.44 и в таблице 3.2, из которых точка зрения вариантов использования (прецедентов) является основной.  Рис. 3.44. - Аспекты представления системной архитектуры. Основанный на архитектуре и управляемый прецедентами процесс разработки ПО является итеративным и инкрементным. Таким образом, он, во-первых, подразумевает создание версий программной системы и, во-вторых – развитие системной архитектуры при выпуске новых версий. Этот пошаговый процесс, предполагает постепенное проникновение в суть проблемы с помощью последовательных уточнений, в котором ПО разрабатывается и реализуется по частям, путем получения все более емкого решения. Таблица 3.2. Аспекты представления системной архитектуры.
Данный эффект достигается вследствие того, что РУП состоит из фаз, в которых достигаются конкретные хорошо определенные цели и принимается решение о переходе к следующей фазе: начало, исследование, построение, внедрение. При этомкаждая фаза состоит из итераций, содержащих рабочие процессы, соответствующие этапам жизненного цикла ПО. В каждой фазе и на каждой итерации основные усилия сосредотачиваются на различных аспектах процесса разработки. В таблице 3.3 показан общий вид этого процесса. Рабочие процессы выполняются в каждой фазе и на каждом шаге итерации. При этом в разных фазах основной упор делается на разных работах. Внутри каждого рабочего процесса сосредоточены связанные между собой артефакты (artifact) – документы, программы и т.д. и деятельности (activity) – анализ, выполнение, а также способы и рекомендации по решению различных задач. Таблица 3.3. Фазы и рабочие процессы РУП.
Одно прохождение четырех фаз процесса называется циклом разработки. Если после этого работа над проектом не заканчивается, то полученный продукт продолжает развиваться и снова проходит цикл из четырех фаз, каждая из которых состоит из рабочих процессов, представленных в таблице 3.4. Таблица 3.4. Цикл разработки.
Начальная фаза проекта (Inception) В начальной фазе пишется экономическое обоснование и определяются границы и бизнес-цели проекта. В результате итеративно выполняемых рабочих процессов на данной фазе вырабатываются критерии успешности, оцениваются риски, определяются необходимые ресурсы и составляются планы, нередко создается исполняемый прототип, демонстрирующий реалистичность концепции. Начальная фаза должна занимать несколько дней работы, в течение которых следует решить, стоит ли проводить более глубокие исследования, которые могут продолжаться несколько месяцев. Именно в этой фазе спонсор проекта принимает на себя определенные обязательства и дает согласие не более чем на серьезное рассмотрение проекта. Важнейшие цели: Определить функциональные возможности создаваемого ПО и его эксплуатационные свойства, а также критерии, по которым будет определяться его готовность. Определить наиболее трудоемкие и критичные варианты использования ПО и их сценарии. Проработать архитектуру ПО для таких сценариев. Оценить стоимость и сроки выполнения проекта. Дать обобщенную оценку потенциальных рисков. Определить инфраструктуру (рабочую среду) проекта. Важнейшие действия: Анализ бизнес-процессов, для которых разрабатывается ПО. Описание контекста и наиболее важных требований к ПО. Оценка альтернатив по управлению рисками, по укомплектованности персоналом и другим ресурсам, по планированию процесса разработки. Оценка соотношения стоимости и доходности ПО. Выбор инструментов. Создание основного документа «Vision» (см. ниже в конце данного пункта). Исследование (Elaboration) С этой фазы начинается собственно проектирование. На этой фазе необходимо проанализировать предметную область, сформулировать большую часть требований к разрабатываемой системе, определить ее структуру и принять архитектурные решения, а также устранить наиболее опасные риски. Для подтверждения правильности принятых решений и целесообразности построения системы создается прототип, демонстрирующий выбранные принципы в действии и реализующий некоторые наиболее важные прецеденты. В этой фазе следует дать ответы на следующие вопросы: Что вы на самом деле собираетесь создать? Как вы собираетесь это сделать? Какую технологию вы собираетесь использовать? Решая эти вопросы необходимо учитывать проблемы, которые могут быть присущи данному проекту. По мнению, например М. Фаулера, существуют четыре категорий проблем, которые он называет «рисками проекта»: Риски, связанные с требованиями. Самая большая опасность заключается в том, что построенная система не будет удовлетворять требованиям пользователей. Во время фазы исследования необходимо как следует разобраться с требованиями и их относительными приоритетами. Технологические риски. Необходимо разобраться имеется ли достаточный опыт для применения требуемой или выбранной технологии проектирования. Насколько хорошо эта технология работает? Можно ли с помощью данной технологии действительно реализовать те функции, которых требуют пользователи. Риски, связанные с квалификацией персонала. Имеются ли сотрудники с необходимым опытом и квалификацией? Политические риски. Существуют ли силы, которые могут оказаться на вашем пути и серьезно повлиять на проект? Одной из важнейших средств уточнения требований пользователей (устранения рисков, связанных с требованиями) является построение диаграммы вариантов использования (прецедентов), которая является «движущей силой» всего процесса разработки. Вариант использования отражает типичное взаимодействие пользователя с системой для достижения некоторых целей и является основой для общения и взаимопонимания между спонсорами (заказчиками) и разработчиками при планировании проекта. Необходимо определить все возможные варианты использования разрабатываемой системы. Для этого в фазе исследования планируется встреча с пользователем (заказчиком) с целью определения таких вариантов. Варианты использования не рекомендуется чересчур детализировать, вполне достаточно текстового описания размером от одного до трех абзацев. Текст должен быть достаточно содержательным и для пользователей, чтобы они поняли основную идею, и для разработчиков, чтобы они хорошо представляли, что скрывается за этим описанием. Другой важнейшей задачей является разработка концептуальной модели предметной области (модели анализа). Концептуальная модель предметной области закладывает основы для моделирования объектов, которые будут позднее использоваться в процессе разработки объектной модели системы. Модель предметной области это любая модель, описывающая ту часть реального мира, для которой создается компьютерная система, независимо от стадии, на которой находится процесс разработки. Модель предметной области строится, как правило, до определения любого варианта использования; ее назначение – исследование лексики предметной области в терминах, имеющих значение и смысл для экспертов (заказчиков). Модели предметной области и варианты использования охватывают функциональные требования к системе. Команда, занимающаяся моделированием предметной области, должна представлять собой небольшую группу (от двух до четырех человек), в состав которой входят разработчики и эксперты предметной области. Минимально жизнеспособная команда – это один разработчик и один эксперт. Эксперт предметной области (и, желательно, разработчик тоже) должен пройти обучение использованию соответствующих диаграмм UML для концептуального моделирования. Моделирование предметной области является весьма важным дополнением вариантов использования. Для выявления и описания вариантов использования модель предметной области следует показывать эксперту и определять по его реакции правильность сложившегося представления о бизнес-процессах. Для построения моделей предметной области наиболее важными являются следующие два инструмента UML: Диаграммы классов. Построенные с концептуальной точки зрения они очень хорошо подходят для выражения понятий предметной области. С помощью этих диаграмм можно выразить те понятия, которые эксперты предметной области используют в своей деятельности, и определить способы, с помощью которых эксперты связывают отдельно взятые понятия в стройную систему. Диаграммы деятельности. Они дополняют диаграммы классов за счет описания потоков работ, т.е. пошаговых процессов выполнения работ отдельными людьми. Ключевым аспектом диаграмм деятельности является то, что они стимулируют поиск параллельных процессов, важный с точки зрения исключения избыточных последовательностей в бизнес-процессах. Не рекомендуется слишком заботиться о строгости и пытаться зафиксировать каждую деталь. При этом может быть построено множество несвязанных диаграмм. Тем не менее, такой процесс достаточно быстро приводит к пониманию проблемы. Благодаря этому пониманию можно легко идентифицировать варианты использования для различных пользователей. После этого с помощью одного или двух экспертов следует объединить различные диаграммы в единую согласованную модель предметной области, которая будет удовлетворять всем требованиям, зафиксированным в более ранних разрозненных моделях. Эта модель может затем использоваться в качестве отправной точки для построения классов и более тщательного проектирования классов в фазе построения. Если эта модель велика, то, используя пакеты (packages), ее можно разделить на составные части. Моделирование предметной области существенно продвигается по мере определения вариантов использования. Как только появляются очередные варианты использования, команда разработчиков должна оценить, насколько сильно они влияют на модель предметной области. Если сильно, то их нужно исследовать повнимательнее, если нет – отложить на некоторое время. Команда должна интенсивно работать в течение всей фазы исследования, пока не завершит модель. В течение этого времени менеджер проекта должен следить, чтобы команда, с одной стороны, не завязла в трясине мелких деталей, а с другой стороны, не витала в облаках, а стояла ногами на земле. Когда они разберутся в сути того, что делают, погружение в мелкие детали станет самой большой опасностью. В этой ситуации, чтобы сконцентрировать их внимание в нужном направлении, рекомендуется установить сжатый срок завершения работы. Чтобы лучше понять требования к системе, рекомендуется построить прототип любых более или менее сложных вариантов использования. Прототипирование – это хороший способ для достижения наилучшего понимания динамики функционирования системы. Для выделения частей системы, которые нуждаются в прототипировании, используют модель предметной области. После того как построены модели предметной области и вариантов использования, разрабатывается модель проектирования, которая, с одной стороны, представляет информацию о системе, отражающуюся в объектах предметной области, и, с другой стороны, поведение системы, отражающееся в вариантах использования. Модель проектирования добавляет классы, выполняющие некоторую реальную работу в системе и образующие повторно используемую архитектурную основу для ее последующих расширений. В больших проектах можно построить промежуточную модель анализа для исследования влияния внешних требований на принятие проектных решений. РУП не требует, чтобы фазы исследования или построения системы выполнялись «подобно водопаду». На самом деле важно правильно определить основные классы предметной области и варианты использования, затем построить повторно используемую архитектуру системы, обеспечивающую последующие расширения. Новые варианты использования могут постепенно добавляться и включаться в модель проектирования как часть итеративного процесса разработки. Не следует пытаться строить всю систему «одним махом». Самые большие технологические риски возникают при сборке разнородных компонент в единый проект, а не в каждом из компонентов в отдельности. Поэтому самый хороший способ справиться с технологическими рисками – это строить прототипы с помощью той технологии, которая будет применяться в фазе построения системы. Можно достаточно хорошо разбираться в C++ и в реляционных базах данных, однако применение одновременно того и другого может оказаться не таким уж простым делом. Именно поэтому рекомендуется на ранней стадии процесса создания системы совместно испытать все средства, которые будут использоваться в дальнейшем. На этой стадии рекомендуется также отработать все архитектурные решения. При этом обычно имеются в виду состав основных компонент и способ их построения. Это особенно важно, если создается распределенная система. Особенное внимание необходимо уделить тем решениям, которые будет трудно изменить впоследствии. Проектирование необходимо выполнять таким образом, который позволил бы относительно легко вносить изменения в проект. Необходимо дать ответы на следующие вопросы: Что случится, если какие-то технологические элементы не будут работать? Что, если не удастся соединить между собой два фрагмента мозаики? Какова вероятность возникновения незапланированных трудностей? Если они все-таки возникнут, каким образом мы могли бы с ними справиться? Как и модель предметной области, необходимо внимательно анализировать варианты использования по мере их появления, чтобы оценить, нет ли в них чего-либо, что может привести в негодность разрабатываемый проект. Простейшим способом, позволяющим устранить риски, связанные с квалификацией персонала, является обучение. Тем не менее, самой распространенной ошибкой при выполнении объектно-ориентированной разработки по мнению, М. Фаулера, является недостаточное внимание, уделяемое обучению. Обучение – это способ избежать ошибок, поскольку учителя их уже сделали. Ошибки отнимают время, а время стоит денег. Таким образом, не обучившись, вы понесете те же расходы, только проектирование при этом продлится дольше, чем нужно. При этом необходимо иметь в виду, что небольшой формальный курс обучения может быть полезным, но это всего лишь начало. Он даст общее представление о том, что необходимо знать, но не может дать квалификации, необходимой для выполнения серьезных проектов. Если планируется пройти небольшой курс обучения, рекомендуется уделить серьезное внимание выбору преподавателя. Рекомендуется потратить больше денег на преподавателя, который способен доходчиво донести свои знания до слушателей и, таким образом, обеспечить хорошее понимание процесса. Кроме того, курсы следует проводить именно по тем проблемам, которыми вы в настоящее время занимаетесь. Если вы не примените свои знания на практике сразу после окончания курса, то скоро все забудете. Для приобретения практических навыков применения объектно-ориентированного подхода рекомендуется воспользоваться помощью опытного наставника, под руководством которого команда будете работать над проектом в течение достаточного периода времени. Такой наставник покажет, как делаются те или иные вещи, будет наблюдать за тем, что делается, и давать по ходу дела полезные советы и рекомендации. Наставник вникает в специфику проекта и знает, какие навыки и когда лучше использовать. На ранних стадиях проекта он является одним из участников команды разработчиков, помогая принимать правильные решения. Со временем команда приобретает необходимый опыт, и наставник станет скорее наблюдать, чем делать что-либо. Рекомендуется найти такого наставника, который не только сам обладает знаниями, но и может передать их другим. Выбор хорошего наставника может оказаться самым важным фактором успеха проекта; не рекомендуется экономить на качестве. Если нет возможности привлечь постоянного наставника, рекомендуется устраивать разбор проекта хотя бы через каждую пару месяцев или около этого. При этом для анализа различных аспектов проекта следует на несколько дней приглашать опытного наставника. В течение этого времени он может проанализировать любые части проекта, заслуживающие повышенного внимания, выдвинуть дополнительные идеи и наметить какие-либо полезные методы, которыми команда не владеет. Хотя от постоянного наставника гораздо больше пользы, такой способ тоже может сыграть важную роль в успехе проекта. Разумеется, можно также повысить свою квалификацию путем чтения нужной литературы. Рекомендуется, по крайней мере, каждый месяц читать серьезную техническую литературу. Еще лучше заниматься ее изучением совместно с другими разработчиками. Рекомендуется найти пару других людей, желающих прочесть ту же самую книгу и договорится с ними читать по несколько глав в неделю и в течение часа или двух обсуждать прочитанное. Если поступить таким образом, то можно лучше понять книгу, чем при чтении ее в одиночку. Менеджерам рекомендуется поощрять сотрудников к такому подходу. Необходимо обеспечить помещение и время для такого группового чтения и обсуждения; выделить средства на приобретение технической литературы. В среде разработчиков такая групповая работа над книгами считается весьма полезной. Одним из самых важных результатов фазы исследования является базовая архитектура разрабатываемой системы. Эта архитектура включает: перечень вариантов использования, определяющих требования к системе; модель предметной области, которая отражает понимание бизнеса разработчиком и служит отправным пунктом для формирования основных классов предметной области; технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодействие. Эта архитектура является основой всей разработки, она служит своего рода проектом для последующих фаз. В дальнейшем неизбежны незначительные изменения в деталях архитектуры, однако серьезные изменения маловероятны. Кроме того, результатом данной фазы является план, определяющий последовательность итераций построения системы и варианты использования, реализуемые на каждой итерации. Для каждого варианта использования должна быть определена своя итерация и назначена дата начала каждой итерации. На данном этапе более детальное планирование не рекомендуется. Для решения задачи планирования рекомендуется выполняются следующие начальные шаги: Пользователи должны указать уровень приоритетности для каждого варианта использования. Три уровня: «Эта функция абсолютно необходима для любой реальной системы»; «Какое-то небольшое время я смогу прожить без этой функции»; «Эта функция важна, но пока я могу обойтись и без нее». Разработчики должны принимать во внимание «архитектурный» риск, связанный с каждым вариантом использования, который заключается в следующем: если реализацию данного варианта использования отложить на слишком долгое время, то вся выполненная до этого работа может потребовать значительной переделки. Три категории оценки: а) высокая степень риска, б) возможно, но маловероятно и в) маленький риск. Разработчики должны оценить степень своей уверенности относительно объема работы, требуемого для реализации каждого варианта использования. Это называется риском планирования. Три уровня: «Я абсолютно уверен в том, сколько времени потребуется на реализацию»; «Я могу оценить время только с точностью до человеко-месяца»; «У меня нет никаких соображений по этому поводу». После выполнения этих шагов рекомендуется с точностью до человеко-месяца оценить время, требуемое для реализации каждого варианта использования. Данная оценка исходит из предположения, что придется выполнить анализ, проектирование, кодирование, автономное тестирование, интеграцию и документирование. Предполагается также, что разработчики будут полностью, без каких-либо отвлечений, заняты в данном проекте. Оценку должны выполнять разработчики, а не менеджеры. При этом, разумеется, нужно быть уверенным, что разработчик, оценивающий данный вариант использования, разбирается в этом наилучшим образом. После выполнения таких оценок рекомендуется выделить те варианты использования, которые обладают высоким риском планирования. Если с этими вариантами связана большая часть проектного времени или высокая степень «архитектурного» риска, то необходимо выполнить дальнейшее исследование. Следующий шаг заключается в определении длительности итерации. Рекомендуется, чтобы длина итерации была фиксированной на протяжении всего проекта, тогда можно будет получать результаты с заданной регулярностью. Итерация должна быть достаточно длительной для того, чтобы успеть реализовать некоторое количество вариантов использования. В частности, при применении C++ – от шести до восьми недель. Теперь рекомендуется рассмотреть трудоемкость каждой итерации. Например, эффективность работы разработчиков составляет в среднем 50%, т.е. на реализацию вариантов использования они расходуют половину своего рабочего времени. Следует умножить длительность итерации на количество разработчиков и на 0,5. В результате получится трудоемкость каждой итерации. Например, если имеется восемь разработчиков и продолжительность итерации составляет три недели, то на каждую итерацию потребуется 12 человеко-недель (8х3х0,5). Далее рекомендуется просуммировать время на реализацию всех вариантов использования, разделить на трудоемкость одной итерации и добавить единицу. В результате получится начальная оценка количества итераций, которое потребуется для вашего проекта. Следующий шаг заключается в распределении вариантов использования по итерациям. Варианты использования, обладающие высоким приоритетом, «архитектурным» риском и/или риском планирования, следует реализовывать в первую очередь. Рекомендуется разделить слишком большие варианты использования на несколько менее крупных и, возможно, пересмотреть некоторые начальные оценки вариантов использования в соответствии с порядком их реализации. На внедрение (тонкую настройку и компоновку конечного продукта) рекомендуется отвести от 10% до 35% времени построения. (Если нет опыта выполнения этих операций в данной среде, то времени отводится еще больше.) Затем рекомендуется добавить фактор случайности – от 10% до 20% времени построения, в зависимости от степени риска. Воздействие этого фактора обычно ощущается в конце фазы внедрения. Для разработчиков выход конечного продукта планируется без учета этой случайности, однако внешний план для пользователей должен ее учитывать. После выполнения всех перечисленных рекомендаций будет создан план, в котором для каждой итерации указаны реализуемые варианты использования. Этот план отражает согласованное мнение разработчиков и пользователей, его вполне можно назвать согласованным планом. Такой план не является чем-то застывшим – разумеется, вполне возможно, что по ходу проекта он будет изменяться. Однако поскольку этот план согласованный, постольку изменения в него должны вноситься совместно разработчиками и пользователями. Итак, как можно видеть из предыдущего обсуждения, варианты использования служат основой для планирования проекта, и именно поэтому в UML им уделяется такое серьезное внимание. Основными признаками завершения фазы уточнения являются два события: Разработчики в состоянии оценить с достаточно высокой точностью, сколько времени потребуется на реализацию каждого варианта использования. Идентифицированы все наиболее серьезные риски, и самые важные из них осознаны настолько, что известно, как с ними справиться. Важнейшие цели: Гарантировать устойчивость (стабильность) требований, архитектуры и планов. Смягчить риски. Создать прототип. Обосновать соответствие архитектуры требованиям и трудоемкость (стоимость, сроки) разработки. Обеспечить инфраструктуру (рабочую среду) проекта. Важнейшие действия: Определение и согласование архитектуры ПО и планов на фазу построения. Доработка документа «Vision» (см. в конце данного пункта). Создание инфраструктуры (рабочей среды) проекта. Отбор готовых компонентов для повторного использования. Построение (Construction) На стадии построения разработка системы выполняется путем серии итераций. Каждая итерация является своего рода мини-проектом. На каждой итерации для конкретных вариантов использования выполняются анализ, проектирование, кодирование, тестирование и интеграция. Итерация завершается демонстрацией результатов пользователям и выполнением системных тестов с целью контроля корректности реализации вариантов использования. Причиной такого построения процесса разработки является необходимость снижение степени риска. Причиной появления риска является откладывание решения сложных проблем на самый конец проекта. При итеративной разработке на каждой итерации выполняется весь процесс, что позволяет оперативно справляться со всеми возникающими проблемами. Главная идея итеративной разработки – поставить весь процесс разработки на регулярную основу с тем, чтобы команда разработчиков смогла получить конечный продукт. Однако есть некоторые вещи, которые не следует выполнять слишком рано, например оптимизация. Оптимизация снижает прозрачность и расширяемость системы, однако повышает ее производительность. В этой ситуации необходимо принять компромиссное решение – в конце концов, система должна быть достаточно производительной, чтобы удовлетворять пользовательским требованиям. Слишком ранняя оптимизация затруднит последующую разработку, поэтому ее следует выполнять в последнюю очередь. Рекомендуется очень серьезно относиться к тестированию. Объем написанного разработчиком кода тестов должен быть по меньшей мере равен объему кода самого программного продукта. Тестирование должно быть непрерывным процессом. Не рекомендуется писать программный код до тех пор, пока не известно, как его тестировать. Как только написан код, сразу же пишите для него тесты. Пока все тесты не отработают, нельзя утверждать, что написание кода завершено [81]. Однажды написанный тестовый код должен использоваться постоянно. Тестовый код должен быть организован таким образом, чтобы можно было запускать каждый тест с помощью простой командной строки или нажатия кнопки на графическом экране. Результатом выполнения теста должно быть «ОК» или список ошибок. Кроме того, все тесты должны проверять свои собственные результаты. Ничто не приводит к столь неоправданной трате времени, как получение на выходе теста числового значения, с интерпретацией которого нужно разбираться отдельно. Рекомендуется разделить все тесты на автономные и системные. Автономные тесты рекомендуется писать самим разработчикам. Они должны быть организованы в пакеты и тестировать интерфейсы всех классов. Системные тесты рекомендуется разрабатывать отдельной небольшой командой, которая занимается исключительно тестированием. Такая команда должна рассматривать всю систему как черный ящик и находить особое удовольствие в поиске ошибок. Итерации на стадии конструирования являются одновременно инкрементными (наращиваемыми) и повторяющимися. Итерации являются инкрементными в соответствии с той функцией, которую они выполняют. Каждая итерация добавляет очередные конструкции к вариантам использования, реализованным во время предыдущих итераций. Они являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода заново переписывается с целью сделать его более гибким. В этом процессе очень часто используется метод реорганизации (см. далее). Рекомендуется внимательно наблюдать за тем, какой объем кода оказывается ненужным после каждой итерации. Если каждый раз выбрасывается менее 10% предыдущего кода, то это должно вызывать подозрение. Процесс интеграции должен быть непрерывным. В конце каждой итерации должна выполняться полная интеграция. Тем не менее, интеграция может и должна выполняться еще чаще. Разработчику рекомендуется интегрировать приложения после выполнения любой сколько-нибудь значительной части работы. Во время каждой интеграции должен выполняться полный набор автономных тестов, чтобы обеспечить таким образом полное регрессионное тестирование. В рамках каждой итерации рекомендуется заниматься более детальным планированием. Самой важной частью любого плана являются меры, которые нужно предпринимать, если что-то происходит не так, как было запланировано. Главная особенность итеративной разработки заключается в том, что она жестко ограничена временными рамками, и сдвигать сроки недопустимо. Исключением может быть перенос реализации каких-либо вариантов использования на более позднюю итерацию по соглашению с заказчиком. Смысл таких ограничений – поддерживать строгую дисциплину разработки и не допускать переноса сроков. Если, например, слишком много вариантов использования перенесено на более поздний срок, то пора корректировать план, пересмотрев при этом оценку трудоемкости реализации вариантов использования. На этой стадии разработчики должны иметь более глубокое представление о такой оценке. На стадии построения полезными являются все методы UML. Концептуальная диаграмма классов полезна для приблизительного описания некоторых понятий варианта использования и определения того, как эти понятия согласуются с уже разработанным ПО, а также более детального отображения классов. Если вариант использования содержит значительные элементы потоков работ, то рекомендуется обратиться к их представлению на диаграмме деятельности. Преимущество этих методов на данной стадии заключается в том, что они могут быть использованы в сотрудничестве с экспертом предметной области. Анализ становится осмысленным только при непосредственном участии эксперта предметной области. Диаграммы взаимодействия полезны для представления взаимодействия классов, в котором выражается реализация варианта использования. Если поведение класса в течение его жизненного цикла достаточно сложно описать, рекомендуется использовать диаграмму состояния. Рекомендуется ограничить документацию теми случаями, когда она действительно помогает. Если обнаруживается, что от документации нет никакого толку, это верный признак, что что-то идет не так. Документация в нормальном случае должна содержать три основных элемента: одну или две страницы с описанием нескольких классов, присутствующих на диаграмме классов; несколько диаграмм взаимодействия, показывающих, как классы взаимодействуют между собой; небольшое текстовое описание, связывающее диаграммы воедино. Важнейшие цели: Завершить анализ, проектирование, кодирование и тестирование всех вариантов использования (функциональных возможностей). Создать готовый к использованию продукт. Добиться надлежащего качества и полезности версий. Оценить готовность к развертыванию. Уменьшить затраты на разработку, оптимизируя продукт и используемые ресурсы. Важнейшие действия: Управление ресурсами. Контроль качества и оптимизация. Разработка компонент, автономное тестирование. Интеграция и системное тестирование. Определение готовности ПО с учетом критериев его приемки. Внедрение (Transition) На стадии внедрения продукт не дополняется никакой новой функциональностью (кроме, разве что, самой минимальной и абсолютно необходимой). Здесь только исправляют ошибки, настраивают систему и передают ее пользователю. Хорошим примером для фазы внедрения может служить период времени между выпуском бета-версии и появлением окончательной версии продукта. Важнейшие цели: Отрекламировать и сбыть продукт. Завершить бета-тестирование. Согласовать разработанный продукт с унаследованным ПО. Адаптировать базы данных и знаний. Обучить пользователей. Повысить работоспособность. Поддержать пользователей. Важнейшие действия: Выполнение плана развертывания. Тестирование поставляемого продукта. Настройка поставляемого продукта. Сопровождение продукта у пользователя. Обеспечение обратной связи с пользователем. Обеспечение доступности продукта для пользователей. Дополнительные средства Реорганизация. При дополнении программы новыми функциями можно либо перепроектировать эту программу, чтобы внести изменения наилучшим образом, либо просто поправить уже существующий код. Как правило, дописывается новый код поверх существующего, не обращая при этом особого внимания на прежнюю программу, хотя теоретически программу лучше перепроектировать. Перепроектирование, в свою очередь, выливается в большую дополнительную работу, поскольку переписывание существующей программы порождает новые ошибки и проблемы. Однако, если не перепроектировать программу, дополнения могут оказаться более сложными, чем могли бы быть в противном случае. Со временем за такую «сверхсложность» придется платить все более высокую цену. Вследствие этого, как правило, приходится идти на компромисс: перепроектирование влечет за собой серьезные трудности в краткосрочном плане, зато приносит выгоду в перспективе. Находясь под прессом жестких плановых сроков, большинство разработчиков предпочитает отодвигать эти трудности на будущее. Термин «реорганизация» используется для описания методов, которые позволяют уменьшить краткосрочные трудности, связанные с перепроектированием. Реорганизация не изменяет функциональность программы; однако при этом изменяется ее внутреннюю структуру для того, чтобы сделать ее более понятной и модифицируемой. Реорганизационные изменения обычно довольно невелики: переименование метода, перемещение атрибута из одного класса в другой, консолидация двух подобных методов в суперкласс. Каждое отдельное изменение очень мало, однако даже пара часов, потраченных на внесение таких небольших изменений, могут существенно улучшить программу. Реорганизацию можно облегчить, если следовать следующим принципам: Не следует одновременно заниматься реорганизацией программы и расширением ее функциональности. Необходимо проводить четкую границу между этими действиями. В процессе работы можно переключаться от одного действия к другому – например, в течение получаса заниматься реорганизацией, затем потратить час на добавление новой функции и полчаса на реорганизацию только что добавленного кода. Перед началом реорганизации убедитесь, что у вас имеются хорошие тесты. Запускайте их как можно чаще. Таким образом, вы быстро узнаете, не нарушили ли чего-нибудь ваши изменения. Вносите изменения минимальными и тщательно обдуманными шагами. Переместите атрибут из одного класса в другой. Объедините два подобных метода в один суперкласс. Реорганизация часто включает выполнение множества небольших локальных изменений, которые, в конечном счете, выливаются в крупномасштабное изменение. Если каждый шаг будет небольшим и будет завершаться обязательным тестированием, то вы сможете избежать в будущем длительной отладки. Реорганизацию следует выполнять в следующих случаях: Вы расширяете функциональность своей программы и обнаружили, что с существующим кодом возникают некоторые проблемы. Тогда процесс расширения следует приостановить до тех пор, пока не будет реорганизован старый код. Код становится трудным для понимания. В этом случае реорганизация служит хорошим способом облегчить понимание кода и сохранить это понимание на будущее. Потребность в реорганизации возникает, когда приходится иметь дело с кодом, написанным каким-либо другим разработчиком. Если вы занимаетесь такой реорганизацией, то делайте это вместе с автором кода. Не так просто написать код, который другие могли бы легко понимать. Наилучший способ реорганизации – это работать бок о бок с тем, кто разбирается в данном коде. Образцы. Образцы – примеры моделей, представляющих результаты процесса объектно-ориентированной разработки. Образцы предназначены для описания наиболее общих решений и накапливаются, обычно, у тех разработчиков, которые умеют находить в своих проектах повторяющиеся решения. Эти разработчики описывают каждое решение таким образом, чтобы другие люди могли воспринять этот образец и понять, как его применить. Примером образца может служить объект-посредник (proxy), заменяющий реальный (удаленный) объект (обладающий тем же самым интерфейсом) и отвечающий за передачу ему любых сообщений. Это избавляет объекты локального процесса от проблем поиска других объектов в сети или выполнения вызовов удаленных процедур. Посредник – это проектный образец, поскольку он определяет метод проектирования. Образцы могут использоваться и в других областях. Например, можно использовать образец сценария, который является образцом анализа, поскольку он определяет фрагмент модели предметной области. Образцы анализа имеют важное значение, поскольку их хорошо использовать в самом начале работы с новой предметной областью. «У образцов анализа есть одна интересная особенность – они могут пригодиться в самый неожиданный момент. Когда я начал работать над проектом корпоративной системы финансового анализа, мне здорово помогли образцы, накопленные мною ранее в проекте из области здравоохранения». Образец – это нечто гораздо большее, чем просто модель. Образец должен также включать обоснование, почему он именно такой, какой есть. Часто говорят, что образец представляет собой решение проблемы. Образец должен придать проблеме необходимую ясность, объяснить, почему он является решением данной проблемы, а также в каких ситуациях он работает или не работает. Образцы очень важны, поскольку они являются следующим шагом после понимания основ языка или метода моделирования. Образцы предлагают набор готовых решений, а также показывают, что представляет собой хорошая модель и как ее построить. Они обучают на примерах. Образцы следует использовать постоянно. Чем бы вы ни занимались – анализом, проектированием, кодированием или управлением проектами – всегда стоит заняться поиском любых доступных образцов, которые могли бы вам помочь. Содержание документа «Vision». Введение. Цели документа. Область действия документа. Список определений и сокращений. Перечень ссылок. Краткий обзор документа. Позиции (основные характеристики) проекта. Возможности (деловые), получаемые в результате выполнения проекта. Постановка задачи (описание проблемы). Описание назначения (позиций, характеристик) проектируемого ПО. Описание заинтересованных лиц и потребителей. Рынок. Список и описание заинтересованных лиц. Список и описание пользователей. Условия работы пользователей. Характеристика заинтересованных лиц. Stakeholder Name. Характеристика пользователей. User Name. Основные потребности (проблемы) заинтересованных лиц и пользователей. Альтернативы и конкурирующие продукты. Основные конкуренты. Прочие конкуренты. Общее описание проектируемого ПО. Перспективы использования. Перечень возможностей. Предположения и допущения. Калькуляция. Лицензирование и ввод в эксплуатацию. Свойства (особенности) разрабатываемого ПО. Основные свойства (особенности). Прочие свойства. Ограничивающие условия. Диапазон качества. Приоритеты. Другие требования к разрабатываемому ПО. Применяемые стандарты. Системные требования. Требования к функционированию (эксплуатационные показатели). Требования (экологические) к рабочей среде. Требования к документации. User Manual (Руководство пользователя). Online Help (Интерактивная справка). Installation Guides, Configuration, and Read Me File (Руководство по установке и конфигурированию). Маркировка и упаковка. Appendix 1 – Особые свойства / атрибуты особенностей: A.1. Статус. A.2. Польза (выгода). A.3. Объем работ. A.4. Риск. A.5. Устойчивость. A.6. Целевой выпуск (целевая версия). A.7. Назначение. A.8. Причина (основание). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
естирование
азвертывание
