Анализ предметной области и требования к ПО
Описание предметной области
Курсовая работа: Исследование предметной области и проблемной среды деканатов Разработка модели предметной области
Планирование итеративного проекта Технологические процессы 7 Технологический процесс управления проектом Цель Планирование итеративного проекта Понятие риска Понятие метрики Что такое метрика Исполнители и артефакты Технологический процесс Создание плана итерации 8 Технологический процесс моделирования производства Цель Зачем моделировать производство Использование методов программотехники в процессе. Основные задачи книги Благодаря этой книге вы узнаете чем является Rtionl Unified Значение программного обеспечения 17 Проблемы в процессе разработки программного. Как лучше всего организовать процесс разработки Пользуйтесь модульными архитектурами Используйте визуальное моделирование Не забывайте о проверке качества Rational Unified Process Дополнительные элементы процесса Особенности итеративного подхода Процесс, основанный на архитектуре Другие архитектурные концепции Прецеденты в процессе Планирование итеративного проекта Что такое метрика Исполнители и артефакты Создание плана итерации Зачем моделировать производство Использование методов программотехники в процессе Сценарии моделирования производства От моделей производства к моделям системы Моделирование производства программного обеспечения Сбор требований и управление ими Проектирование интерфейса, ориентированного. Технологический процесс управления требованиями Анализ против проектирования Насколько стоит продумывать проект Роль интерфейсов , Артефакты систем реального времени Тестирование в итеративном жизненном цикле Определение видения продукта и бизнес-плана Создание архитектурного прототипа Эффект реализации процесса Сильвии, Элис, Зо и Николасу. Благодаря этой книге вы. Полный вариант содержит подробнейшее руководство, необходимое для претворения в жизнь вашего проекта. Книга разбита на две части. Советы по организации процесса разработки программного обеспечения. Процесс, основанный на архитектуре. Каждому из основных технологических процессов посвящена отдельная глава. Технологический процесс управления проектом. Технологический процесс моделирования производства. Технологический процесс управления требованиями. Технологический процесс анализа и проектирования. Технологический процесс управления конфигурацией и изменениями. Технологический процесс управления средой. Большинство глав этой части содержит шесть разделов. Определения и основные понятия. В двух приложениях перечислены все исполнители роли процесса и артефакты результаты процесса , которые вводятся в главах Здесь также представлен обзор разработки систем реального времени и реагирующих систем. Кроме того, изложение материала было углублено, и теперь здесь представлены дополнительные контрольные таблицы и директивы для артефактов, видов деятельности и фаз процесса. История этого процесса излагается в главе 2. Создание книги, даже такой маленькой и скромной, как эта, потребовало значительных усилий преданных своему делу людей, которых мне бы хотелось здесь назвать. И наконец, огромное спасибо нашему редактору Дж. Филипп Крачтен Ванкувер, Канада. Преимущественно программные продукты способствовали лечению больных: На сегодняшний день программное обеспечение является неотъемлемой частью современного мира. Кроме того, растет и общественный спрос на эти системы. Ситуацию усложняет еще и то, что коммерческая отрасль требует все более эффективных и качественных продук-. IEEE Software 15 1 , January-February , pp. Итак, создавать и поддерживать программное обеспечение трудно и со временем становится еще труднее. Мы можем выделить несколько основных показателей, характеризующих "провал" проектов. Неточное понимание нужд конечных пользователей. Неспособность работы в условиях меняющихся требований. Продукт состоит из несовместимых модулей. Программное обеспечение трудно поддерживать или расширять. Позднее обнаружение существенных изъянов проекта. Плохое качество программного обеспечения. Каждый сотрудник занимается чем-то своим, причем непонятно, кто, когда, где и зачем что-либо меняет. Хотя различные проекты "проваливаются" по различным причинам, похоже, что большинство неудач происходит вследствие сочетания следующих основных причин. Неумелое управление специальными требованиями. Неопределенная и неточная связь. Необнаруженные противоречия в требованиях, проектах и реализациях. Субъективная оценка состояния проекта. Неспособность справиться с реализовавшимся риском. Patterns of Software Systems Failure and Success. International Thompson Computer Press, ; и Edward Yourdon. Managing "Mission Impossible" Projects. Upper Saddle River, NJ: Советы по организации процесса разработки Классический подход к разработке программного обеспечения включает водопадный жизненный цикл, показанный на рис. Основной проблемой описанного подхода является рост риска со временем; так что устранять ошибки предыдущих фаз становится слишком дорого. Principles of Software Engineering Management. Альтернативой водопадному подходу является поэлементный итеративный процесс, показанный на рис. A Spiral Model of Software Development and Enhancement. IEEE Computer, May , pp. Целиком определить системные требования до начала процесса разработки можно только для тривиальных систем. Активное управление требованиями включает три вида деятельности: Управление требованиями проекта предлагает множество решений, устраняющих основные причины проблем в процессе разработки программного обеспечения. Системная архитектура включает решения относительно. Выбора структурных элементов и их интерфейсов при формировании системы;. Поведения этих структурных элементов, обусловленного совместной их работой;. Формирования из структурных элементов и линий их поведения постепенно укрупняющихся подсистем;. Архитектурного стиля, направляющего структуру, состоящую из элементов и их интерфейсов, а также их совместной работы и объединения. Как показано на рис. Итеративная разработка программного обеспечения с использованием модульной архитектуры связана с непрерывным развитием архитектуры системы. Кроме того, этот подход позволяет команде непрерывно бороться с важнейшими рисками проекта. Средства визуального моделирования облегчают управление моделями, позволяя показывать или скрывать подробности по мере надобности. Впоследствии во время каждой итерации можно, при наличии надлежащих средств, синхронизировать модели с исходными кодами. Модель помогает лучше понять модулируемую систему. Проверка функциональных возможностей системы основная часть работы по тестированию включает создание тестов для всех ключевых сценариев, каждый из которых представляет некоторый аспект ожидаемого поведения системы. Проверка качества программного обеспечения предлагает множество решений, устраняющих основные причины проблем в процессе разработки программного обеспечения. При отсутствии строгого контроля процесс разработки быстро станет хаотичным. Координация итераций и версий включает установление и выпуск проверенной базовой линии в конце каждой итерации. Запросы на внесение изменений способствуют установлению более надежной связи между группами разработчиков и заинтересованными сторонами. Сбор статистических данных позволяет объективно оценить состояние проекта. Рабочие среды содержат все артефакты, согласовывающие процесс. Распространение изменений поддается оценке и контролю. Изменения можно поддерживать в устойчивых, настраиваемых системах. Такое состояние никак нельзя назвать удовлетворительным. И наоборот, развитые организации могут разрабатывать сложнейшие системы с помощью процесса, результаты каждого действия которого можно предсказать, а сам процесс повторить. Когда все эти советы будут учтены в процессе, команда разработчиков сможет применить коллективный опыт использования тысяч успешных проектов. Object Solutions- Managing the Object-Oriented Project. Разрабатывайте итеративно Управляйте требованиями. Пользуйтесь модульными архитектурами Используйте визуальное моделирование. Не забывайте о проверке качества Следите за изменениями. Целью этого процесса является производство качественного программного обеспечения, удовлетворяющего требования конечных пользователей, в рамках прогнозируемого бюджета и графика работ. Он неразрывно связан с выпускаемым корпорацией набором средств для разработки программного обеспечения. Он предоставляется оперативно, с использованием технологии Web , поэтому для разработчиков он буквально доступен с клавиатуры. Подход к процессу как к программному продукту имеет следующие преимущества. Все участники проекта могут по внутренней сети получить последнюю версию процесса. В каждом проекте или отделе может использоваться собственная версия процесса. Software Processes Are Software Too. Proceedings of the Ninth International Conference on Software Engineering, pp. Продукт состоит из следующего. Броузер в форме иерархического дерева. Подробная схема Web -узла. Все это можно увидеть на рис. В нем также имеется следующее. Шаблоны для основных артефактов процесса. Помимо этого, в руководстве имеются типовые варианты определенных классов разработки вместе с дополнительными или специализированными руководствами. Ericsson , Alcatel , MCI. Транспорт, авиационно-космическая отрасль, оборонная промышленность: Xerox , Volvo , Intel. Visa, Merrill Lynch, Schwab. Похоже, что в нашей промышленности постепенно начинают назревать перемены: В процессе можно выделить две структуры, или, если желаете, два измерения. Горизонтальная ось представляет время и показывает развитие различных аспектов жизненного цикла процесса. Первое измерение представляет динамическую сторону процесса, то есть показывает, как процесс происходит. Это выражается через циклы, фазы, итерации и вехи. Второе измерение представляет статическую сторону процесса: Эти вопросы рассматриваются в главе 3, "Статическая структура: Он позволяет учитывать меняющиеся требования. При итеративном процессе по мере развития первых итераций тщательно тестируются все компоненты процесса, развиваются инструментальные средства, готовые программные продукты, навыки сотрудников и т. В то же время рецензирование проекта при ранних итерациях позволяет архитекторам выделить фрагменты, потенциально подлежащие повторному использованию, после чего разработать и развить в следующей итерации общий код. Изъяны выявляются не в глобальной фазе заключительного тестирования, а в фазах исследования и уточнения плана. Дефицит ресурсов обнаруживается не накануне сдачи проекта, порождая при этом всеобщую панику, а тогда, когда ситуацию еще можно поправить. Необходимость переподготовки или потребность в дополнительных сотрудниках обнаруживается на ранних этапах проекта, в процессе оценочных обзоров. Может улучшаться и уточняться сам процесс разработки. Руководители проекта часто пренебрегают итеративным подходом, считая его чем-то сродни бесконечной, неуправляемой и нудной работе. Определены объективные критерии состояния процесса. Для вышедших из-под контроля проектов характерно непонимание поведения разрабатываемой системы и "дрейф" требований. Заинтересованной стороной может быть конечный пользователь, покупатель, подрядчик, разработчик, управляющий проектом или другое лицо, нуждающееся в завершении проекта или интересующееся им. Он предусматривает установление архитектурного стиля, правил проектирования и ограничений. Модульная разработка может использоваться по-разному. Они предоставляют организации основу для повторного использования, увеличивая, таким образом, общее качество и эффективность программного обеспечения. Это позволяет разработчикам покупать и объединять эти компоненты, не занимаясь самостоятельно их разработкой. Концентрация внимания на архитектуре системы программного обеспечения позволяет четко сформировать структуру. Для упорядочения компонентов и определения связующих звеньев в процессе анализа и проектирования используются понятия пакетов, подсистем, уровней и т. Тестирование вначале проходят отдельные компоненты, а затем постепенно увеличивающиеся их наборы. В данной книге представляется несколько моделей: Язык UML представляет собой стандартное средство создания чертежей системы, включающих такие абстрактные понятия, как процессы производства и функции системы, а также конкретные понятия, такие как классы, написанные на определенных языках программирования, схемы баз данных и программные компоненты с возможностью повторного использования. Он рассказывает, какие модели необходимы, почему они необходимы и как их создавать. Ответ заключается в том, что качество продукта определяется не усилиями нескольких человек; за качество несут ответственность все сотрудники организации-разработчика. При разработке программного обеспечения основные требования к качеству относятся к двум областям: Насколько был реализован желаемый процесс в том числе системы мер и критерии качества и насколько его придерживались во время производства продукта. Кроме того, на качество процесса влияет и качество артефактов таких, как планы итераций, планы тестирования, реализации прецедентов, модель проектирования и т. Управление изменениями, основанное на потребностях организации-разработчика, представляет собой упорядоченный подход к управлению изменениями в требованиях, проекте и реализации. Отметим также, что управление изменениями связано с управлением конфигурацией и мерами. Роль прецедентов в управлении многими аспектами разработки. С одного взгляда на модель обычной объектно-ориентированной системы часто трудно определить, как же эта система работает. Прецеденты не требуют объектной ориентации, хотя они и создают важные связи между системными требованиями и другими артефактами разработки, такими как проект и тесты. В число потенциально модифицируемых, дополняемых и удаляемых элементов процесса входят артефакты, виды деятельности, исполнители и технологические процессы, а также директивы и шаблоны артефактов. Инструментальные средства бесценны при учете использования ресурсов, связанного с управлением изменениями и конфигурацией, сопровождающим каждую итерацию. Рассмотрим родословную процесса RUP , показанную на рис. Эта версия также объединила управление требованиями от корпорации Requisite , Inc. Основанный на концепции использования прецедентов и объектно-ориентированном проектировании, этот процесс быстро получил признание в индустрии программных средств и был принят полностью или в качестве составной части множеством компаний по всему миру. The Unified Software Development Process. Здесь вводятся ключевые понятия: В процессе описывается, кто выполняет, что выполняет, как и когда. Первые три элемента изображены на рис. Основным понятием процесса является исполнитель. Об исполнителе можно думать как о некоторой "шляпе", которую человек может одевать во время проекта. Смысл аналогии заключается в том, что каждый человек может надеть несколько шляп. Приведем несколько примеров исполнителей. Лицо, действующее как системный аналитик, направляет и координирует процессы определения требований и моделирования прецедентов. Лицо, действующее как разработчик, определяет обязанности, операции, атрибуты одного или нескольких классов и взаимоотношения между классами. Кроме того, разработчик определяет способы их адаптации к среде реализации. Лицо, действующее как разработчик тестов, отвечает за планирование, проектирование, реализацию и оценку тестов, в том числе за создание плана и модели тестирования, реализацию методик испытаний и оценку тестового покрытия, его результатов и эффективности. Соответствие между сотрудником и исполнителем устанавливает руководитель. Это соответствие позволяет сотруднику действовать как несколько исполнителей, а также назначать на роль исполнителя нескольких сотрудников. Возможна и иная ситуация: Сотрудник, играющий роль исполнителя, должен иметь определенные навыки. Исполнители процесса обычно называются с использованием слова "исполнитель", например Исполнитель: Каждый вид деятельности соотносится с определенным исполнителем. Приведем несколько примеров видов деятельности. Поиск прецедентов и акторов. Виды деятельности обычно называются с использованием слова "вид деятельности", например Вид деятельности: Исполнитель создает или модернизирует некоторые артефакты. На основании некоторых критериев исполнитель проверяет результаты. Виды деятельности имеют исходные и результирующие артефакты. Артефакты могут быть составляющими других артефактов. Например, модель проектирования содержит множественные классы; план разработки программного обеспечения включает несколько других планов: Артефакты довольно часто требуют управления их версиями и конфигурацией. Например, можно управлять версиями всей модели проектирования или пакетом проектирования но не отдельными классами и их составляющими. Дефект, сохраненный в ClearQuest. Несмотря на то что "владеть" артефактом может только одно лицо, использовать его могут многие люди, которые, при наличии соответствующего разрешения, могут даже модернизировать этот артефакт. Артефакты называются с использованием слова "артефакт", например Артефакт: Модели и элементы моделей могут сопровождаться отчетами. Например, отчет предоставляет артефакт или множество артефактов для рецензирования. Множество управления объединяет артефакты, относящиеся к управлению проектом и сфере программного обеспечения. Требования в форме запросов заинтересованных сторон, модели прецедентов и дополнительных спецификаций. Множество проектирования содержит описание создаваемой или созданной системы в форме: Множество реализации включает следующее. Исходный код и исполняемые программы. Множество распространения содержит всю поставляемую информацию. Артефакты не являются чем-то завершенным или хотя бы зафиксированным в одной фазе итеративного процесса разработки до перехода к следующей фазе. Помимо этого, требуется описание значимых последовательностей видов деятельности, дающих некоторый полезный результат, и отображение взаимодействий между исполнителями. Существует множество способов, позволяющих. Процесс анализа и проектирования;. Девять основных технологических процессов. Тремя основными процессами поддержки являются. Процесс управления конфигурацией и требованиями;. Каждый из основных технологических процессов является достаточно объемным. Планы итераций можно считать реализациями процесса для данной итерации, определяющими виды деятельности, которые будут эффективно выполняться во время итерации, и воспроизводящими их при необходимости. Этими элементами являются следующие. Виды деятельности и этапы должны описываться точно и лаконично, поскольку они указывают, что должно быть сделано. Следовательно, они должны быть полезны и новичкам, разыскивающим руководство, и опытным сотрудникам, нуждающимся в напоминании. Они описывают правильно сформированные артефакты, акцентируя внимание на их специфических качествах, например на том, что образует хороший прецедент или хороший класс проектирования. Рабочие директивы для рецензий. Рабочие директивы для мастерской прецедентов. Контрольные точки, которые будут использоваться как часть рецензии или по которым исполнитель будет проверять завершенность действия. Приведем примеры таких директив. Давайте рассмотрим некоторые из этих шаблонов. Как и в случае директив, организации могут пожелать настроить шаблоны перед использованием, например добавить логотип компании, маркировку проекта или информацию, характерную для типа проекта. Кроме того, в книге содержится и множество других важных понятий. Технологические процессы связывают виды деятельности и исполнители для получения значимого результата. Директивы, шаблоны и инструментальные наставники дополняют описание процесса путем предоставления исполнителю подробного руководства. Это несколько неожиданно, поскольку именно такой подход к разработке программного обеспечения изначально казался самым разумным. Многие технологические проблемы решаются с использованием последовательного процесса, имеющего следующие пять стадий. Так строятся небоскребы и мосты. Область же программирования является сравнительно молодой. В году автор поклялся, что последовательный процесс является одним-единственным разумным подходом. Итак, если последовательный процесс является таким идеальным, то почему же проекты, в которых он используется, не являются более успешными? Среда разработки программного обеспечения несколько отличается от других технологических дисциплин. Не удалось ввести некоторые человеческие факторы. Данную причину вполне можно считать основной. Предполагалось, что все требования можно точно и однозначно выразить в письменном виде и начать процесс, имея прочный фундамент. Стоит отметить, что несмотря на все усилия это практически невозможно. Если решаемая проблема не является тривиальной, то будут появляться новые требования. Пользовательские требования не поддаются фиксации во времени. Особенно это справедливо в том случае, если время разработки измеряется не неделями или месяцами, а годами. Пользователи обнаруживают новые системы и другие продукты, и им хочется, чтобы разрабатываемый продукт перенял некоторые их свойства. После реализации или в процессе реализации система сама влияет на то, какой ее видят пользователи. Как только конечные пользователи увидят, как их замысел воплощается в системе, требования начнут меняться. Фактически пользователи точно понимают, что они хотели, не за два года до реализации системы, а через несколько недель или месяцев после сдачи проекта, когда исходная фаза обучения уже завершена. Такой эффект иногда называется "Узнаю, когда увижу". Пользователи не могут сказать определенно, чего они хотят, но они знают, чего они не хотят точнее, узнают, когда увидят. Возникает новое программное или аппаратное обеспечение, новые продукты, и может появиться желание воспользоваться ими. Конкуренция может выдвигать на рынок новые продукты. Зачем разрабатывать продукт, великолепно отвечающий исходной спецификации, но являющийся безнадежно устаревшим на момент сдачи? Решение этой проблемы обещают формальные методы, но в промышленности начала третьего тысячелетия они не получили широкого распространения, причем особенно это относится к небольшим, узкоспециализированным отраслям. Эти методы трудно применять на практике; кроме того, они крайне недоброжелательны к пользователю. Попробуйте объяснить временную логику или цветные сети Петри аудитории, состоящей из банковских служащих и заведующих отделением, причем так, чтобы они смогли прочесть и одобрить спецификацию их новой системы. На второй стадии последовательного процесса предполагается, что можно доказать, что созданный проект является верным решением поставленной задачи. Под "верным" подразумевается соответствие всем показателям качества: В проектировании моста заложены относительно простые законы физики, но при проектировании программного обеспечения таких строгих эквивалентов нет. В этом отношении "слабое" программное обеспечение в противоположность "жесткому", аппаратному является действительно слабым. Последовательный, или водопадный, процесс, конечно же, работает. Исходя из этих соображений, в общую картину процесса и включается анализ рисков. Разработчики программного обеспечения, которые знают, что через два-три месяца они увидят вещественные результаты своей работы, могут четко представлять действительный результат. В этом случае обратная связь по качеству осуществляется очень быстро. Рассмотрим теперь место разработчиков в следующей ситуации: Не существует ничего волнующего, ничего материального. Разработчики имеют очень мало благоприятных возможностей для улучшения собственной работы. Более того, если в тексте требований обнаруживаются непонятные моменты, то это. Неудивительно, что мотивировать эти решения сейчас будет трудновато. А если исходные исполнители уже давно не работают Над проектом, а контракт с заказчиком нельзя ни изменить, ни разорвать? Разработчики имеют только по одной попытке для произведения каждого вида деятельности, а возможности поучиться на собственных ошибках практически нет. Проект нужно создать с первой попытки, и лучше, чтобы эта попытка была удачной. Вы никогда не проектировали подобных систем? Запрограммировать результат нужно с первой попытки, и лучше бы, чтобы эта попытка была удачной. Язык программирования для вас нов? Работайте дольше и изучайте его свойства. Протестировать полученную систему нужно за один раз, и желательно, чтобы в этот раз не было сбоев. Что ж, это поймете вы. На практике последовательные процессы акцентируют внимание на производстве и фиксации документации. Это относится к нежеланию изменять требования и терять видение конечного продукта, которое, как правило, стараются фиксировать, особенно в продолжительных проектах. Довольно часто важнейшим фактором успеха проекта разработки программного обеспечения является своевременность. При линейном подходе нельзя получить существенного изменения графика работ, если в середине фазы реализации решить удалить функцию X. Таким способом можно взять некоторые требования и риски, немного спроектировать, немного реализовать, утвердить полученное, а затем взять больше требований, немного больше спроектировать, создать, утвердить и так до тех пор, пока проект не будет завершен. Такой подход и называется итеративным. Проиллюстрировать итеративный метод легко, гораздо сложнее его получить. Этот подход скорее поднимает новые вопросы, чем отвечает на старые. Эти новые вопросы звучат следующим образом. Как направить эту работу, чтобы она дала конечный продукт? Как сделать так, чтобы каждая итерация не начиналась с самого начала? Какие требования и какие риски рассматривать? Как этот подход решает основные проблемы, упоминавшиеся ранее? Некоторые из ответов приводятся и в данной книге, в этой главе и главе 7, "Технологический процесс управления проектом". Как показано Eia рис. Данные фазы ортогональны традиционным фазам, и каждая из них завершается крупной вехой. Рассмотрим четыре фазы итерационного процесса подробнее. Было бы неплохо задать видение конечного продукта и его бизнес-план, а также определить область действия проекта. Планирование необходимых действий и определение требуемых ресурсов; задание свойств и проектирование архитектуры. В это входит производство, доставка, подготовка, поддержка и эксплуатация продукта, пока пользователи не будут удовлетворены. Этот этап да и весь цикл завершается вехой выпуска продукта. На практике циклы могут незначительно перекрываться: Подробнее к этому вопросу мы вернемся в главе 7. Например, для двухлетнего проекта имеем следующее. Как это соотносится с итерациями? Если обратить внимание на поперечное сечение видов деятельности в середине каждой фазы, то можно отметить несколько важных моментов. В фазе исследования внимание уделяется пониманию общих требований и определению области действия работ по разработке. Важность видов деятельности в отдельном цикле разработки. В фазе построения внимание обращается на проектирование и реализацию. В фазе развертывания акцент делается на обеспечении в системе должного уровня качества, удовлетворяющего поставленным требованиям; исправляются ошибки, обучаются пользователи, согласовываются функции и добавляются пропущенные элементы. Производится и сдается окончательный продукт. В данном разделе подробно рассматриваются цели каждой фазы и критерии оценки, используемые в каждой основной вехе ь. В число основных целей фазы исследования входят следующие. Оценка рисков источников непредсказуемости. В фазе исследования необходимыми являются следующие виды деятельности. На выходе фазы исследования должны быть получены следующие артефакты. Документ видения, в котором описано общее видение основных требований проекта, ключевые функции и главные ограничения. План проекта, демонстрирующий фазы и итерации. Эти предположения повторно проверяются в конце фазы уточнения плана, когда область действия и план определяются более точно. Оценка ресурсов может относиться либо ко всему проекту, завершаемому стадией сдачи, либо только к ресурсам, необходимым в фазе уточнения плана. Эта оценка будет корректироваться при последующих фазах и итерациях, и с каждой такой итерацией она будет точнее. В нее входят прецеденты, создаваемые в процессе работы с начальным циклом разработки. Модель предметной области, более изощренная, чем словарь см. Описание предварительного плана разработки, необходимое для определения используемых процессов см. Один или несколько прототипов см. Фаза исследования завершается первой из основных вех: Фаза исследования оценивается согласно следующим критериям. Понятность требований, вытекающих из основных прецедентов. Глубина и широта разработанного архитектурного прототипа. Отношение действительных расходов к запланированным. Если проект не пройдет данную веху, то он может быть отменен или в значительной степени пересмотрен. Для достижения этого требуется осмотреть систему "на милю в ширину, на дюйм в глубину". В большинстве проектов эта фаза соответствует переходу от мобильной, гибкой работы с низким уровнем риска к более дорогой, рискованной и инертной работе. В фазе уточнения плана за одну или несколько итераций это зависит от области действия, размера, риска и новизны проекта создается выполнимый архитектурный прототип. Кроме того, это не исключает ни изучения выполнимости, ни проведения демонстраций перед инвесторами, заказчиками и конечными пользователями. Основными целями фазы уточнения плана являются следующие. Создание базовой линии видения. Создание базовой линии высокоточного плана фазы построения. Демонстрация того, что базовая архитектура позволяет получить желаемое видение за разумную цену и разумное время. В фазе уточнения плана необходимыми являются следующие виды деятельности. Тщательная разработка видения и установление четкого понимания наиболее критичных прецедентов, направляющих архитектурные и проектные решения. Тщательная разработка архитектуры и выбор компонентов. Интеграция и оценка выбранных архитектурных компонентов согласно основ-. Многие проекты настолько велики, что приводят к нагромождению параллельных конструкций. Это является одной из причин того, что в фазе уточнения плана делается акцент на синхронной разработке архитектуры и плана. В число основных целей фазы построения входят: В фазе построения основными являются следующие виды деятельности. Управление ресурсами, контроль ресурсов и оптимизация процесса. Полная разработка компонентов и их тестирование согласно определенным критериям оценки. Оценка версий продукта согласно критериям приемлемого видения. Он включает, как минимум, следующее: Фаза построения завершается третьей основной вехой проекта: В этот момент принимается решение, готовы ли к активной. Такая версия продукта часто называется бетагверсней. Критерии оценки фазы построения включают ответы на следующие вопросы. Устойчива ли данная версия проекта и готова ли она к распространению в пользовательской среде? Если проект не сможет пройти эту веху, то фазу развертывания, вероятно, придется отсрочить на одну версию. После предоставления продукта конечному пользователю обычно возникают вопросы, требующие разработки новых версий, устранения некоторых проблем или доработки отложенных функций. Данная фаза включает следующее. Бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователя. Параллельное функционирование с существующей системой, которую должна заменить разрабатываемая. Перекодирование эксплуатационных баз данных. Подготовка пользователей и персонала поддержки. Передача продукта командам маркетинга, распространения и продаж. Для одних проектов эта конечная точка жизненного цикла может совпадать с начальной точкой следующего цикла, вызывая "рождение" нового поколения или версии продукта. Впрочем, в этот период жизненного цикла обратная связь с пользователем должна, в первую очередь, ограничиваться вопросами настройки продукта, конфигурирования, установки и практичности. Основные цели фазы развертывания состоят в следующем. Добиться независимости от пользователя. Максимально быстро и рентабельно получить окончательную базовую линию продукта. В фазе развертывания необходимыми являются следующие виды деятельности. Проектирование с акцентом на распространение, то есть отбрасывание лишнего, коммерческое оформление продукта и производство, развертывание продаж и подготовка технического персонала. Настройка видов деятельности, в том числе коррекция ошибок и модернизация в целях повышения производительности и практичности. В зависимости от типа продукта эта фаза может быть как простой, так и крайне сложной. Фаза развертывания завершается четвертой важнейшей вехой проекта: В этот момент принимается решение, достигнуты ли поставленные цели и стоит ли начинать еще один цикл разработки. Основные критерии оценки фазы развертывания включают ответы на следующие вопросы. По сравнению с традиционным водопадным процессом, итеративный подход имеет следующие преимущества. Последствия от реализации рисков смягчаются быстрее. Выше уровень повторного использования. Команда, работающая над проектом, может обучаться в процессе. Смягчение последствий от реализации риска. Воспринимаемые риски при этом уже не будут представлять опасности, а новые непредвиденные будут выявляться. При итеративном подходе создается весьма прочная архитектура, поскольку ошибки можно корректировать в течение нескольких итераций. Можно выделить несколько групп изменений, которые поддаются прогнозированию. Итеративный процесс позволяет учитывать меняющиеся требования. Дело в том, что требованиям свойственно меняться. Изменения требований и "дрейф" требований всегда оставались основным источником затруднений, приводящих к поздней сдаче. Итеративный процесс обеспечивает управление с возможностью внесения в продукт тактических изменений, например, для конкуренции с существующими продуктами. Обучение "по ходу дела". Необходимость подготовки или дополнительной возможно, даже внешней помощи обнаруживается на ранних этапах проекта, в процессе оценочных обзоров. Сам по себе процесс также поддается улучшению и уточнению в процессе работы. Повышенная возможность повторного использования. Итеративный процесс способствует повторному использованию элементов проекта, поскольку легче определить общие части не в самом начале работы, а тогда, когда они раздельно проектируются или реализуются. Вообще, определить и разработать части, допускающие повторное использование, достаточно сложно. Такая система тестировалась несколько раз, что повысило качество тестирования. Кроме того, на момент сдачи проекта эта система проработала дольше. Каждая итерация подобна "мини-водопаду" и включает следующие виды деятельности: При его использовании можно максимально рано начать "борьбу" с рисками и смягчение последствий от их реализаций. Основное внимание в этом подходе обращается на реальные, вещественные объекты. Чтобы эти модели не были противоречивыми или чрезмерно избыточными, их следует тщательно координировать. Модели сложных систем могут быть очень большими. The Unified Modeling Language Users Guide. Предположим теперь, что решение этой задачи необходимо представить не более чем на 60 страницах. Результатом этой работы будет то, что называется описанием архитектуры системы. Как когда-то сказал мне один человек: Цель архитектуры не всегда поддается четкому формулированию. Данная концепция остается неясной, находясь где-то между проектированием высшего уровня, понятием системы и управлением требованиями. Не существует общепринятого способа представления архитектуры. Другими словами, системы не очень "упруго" реагируют на изменения. Сейчас, когда все простые системы уже построены, управление сложностью больших систем стало вопросом номер один в организациях-разработчиках программного обеспечеЕшя. Программное обеспечение стало значительной ценностью, и для управления им организациям нужны концептуальные инструментальные средства. Какие выгоды можно извлечь из нее? Как создается и утверждается архитектура, удовлетворяющая требованиям проекта? Архитектуру можно определить по-разному. В Rational Unified Process используется. Архитектура объединяет значимые решения относительно. Остановимся подробнее на нескольких моментах. Кроме того, она имеет отношение к поведению: Архитектура исследует не только внутреннюю часть системы, но еще и ее "пригодность" в двух средах: Архитектура также занимается "тонкими" вопросами, такими как стиль и эстетика. Может ли архитектура быть привлекательной? Да, для тренированного глаза может. Тем или иным образом архитектура представляет интерес для многих. Системного аналитика, использующего ее для организации и формулирования требований, а также понимания технологических ограничений и рисков. Разработчиков, использующих ее для понимания основоположных принципов и определения границ собственного проекта. Субподрядчиков, использующих ее для понимания границ их части разработки. Чтобы различные заинтересованные стороны могли сообщаться и размышлять об архитектуре, требуется понятное им архитектурное представление. Различные заинтересованные стороны беспокоят и интересуют разные аспекты архитектуры. Поэтому архитектура является не плоской, а многомерной. При строительстве здания используются различные типы чертежей, представляющие различные аспекты архитектуры. Планы электромонтажа кабельной проводки. Чертежи водопроводов, систем центрального отопления и вентиляции. Вид здания на фоне пейзажа эскизы. Со временем чертежи развиваются в стандартные формы, чтобы каждый человек, задействованный в проектировании и строительстве здания, понял, как их читать и использовать. Наоборот, они должны тщательно координироваться. Архитектура преимущественно программной системы также предусматривает различные чертежи, служащие различным целям. Отображению логической организации системы. Упорядочению функциональных возможностей системы. Отображению аспектов параллельной работы. Описанию физического размещения программного обеспечения на базовой платформе. Точку зрения, а именно: Какие элементы будут фиксироваться и представляться и какие между ними существуют взаимоотношения. Каким образом элементы данного представления связаны с элементами других представлений. Каким способом лучше всего создать представление. Эти пять измерений или представлений кратко описываются ниже. Данное представление является абстракцией модели проектирования и определяет основные пакеты, подсистемы и классы проекта. В данном представлении отображаются аспекты параллельности задач, потоков или процессов во время работы системы, а также их взаимодействия. В этом представлении также отображается схема модульного наращивания. IEEE Software, 12 6 Nov. Соотношения между моделями и представлениями. Модель проектирования Логическое представление. Модель реализации Реализационное представление. Модель распространения Представление распространения. Модель прецедентов Прецедентное представление. Создание архитектуры, ее утверждение и использование в качестве базовой линии является главной задачей фазы уточнения плана. Подробнее это рассматривается в разделе "Прототип" главы На основе этих двух ключевых артефактов создается еще три. Директивы проекта, определенные некоторыми сделанными архитектурными выборами и отражающие использование шаблонов и идиом. Структура команды, основанная на структуре реализационного представления. В определении и реализации. Внимание разработчиков сосредоточено на архитектурно значимых классах и механизмах, но не на подробностях классов. Испытатели тестируют архитектурный прототип на предмет эффективности и устойчивости. В фазе построения акцент смещается на "одевание" архитектурного скелета в "мясо и кожу". Виды деятельности этой фазы отражают текущие заботы архитектуры: Основные виды деятельности относятся к архитектурному проектированию и описаны в технологическом процессе анализа и проектирования см. Теперь, когда мы рассмотрели архитектуру, можно переходить к ее цели. Довольно долго целью архитекторов было поддержание целостности системы. Изначально слово "целостность" означает "быть единым целым". Это позволяет каждому конструктору и разработчику понимать, что же они должны делать. Архитектура также облегчает широкомасштабное повторное использование: Архитектура предоставляет основу для управления проектом. Планирование и кадровое обеспечение организовывается вдоль линий основных компонентов: Архитектура и работа, выполненная в фазе уточнения плана, обеспечивают основу для последующей разработки, в том числе проектирования директив, принципов, стилей, шаблонов и механизмов, допускающих повторное использование. Компоненты нельзя смешивать и сопоставлять, если они для этого не предназначены. Существует несколько видов компонентов. Они активны только во время выполнения на используемой платформе. Они могут использоваться другими разработчиками. Связанные наборы компонентов времени выполнения или разработанных компонентов , имеющие значительную часть коммерческих выполняемых функций и являющиеся единицами продажи, выпуска или усовершенствования. Архитектура программного обеспечения, или архитектурное представление, может содержать параметр, называемый архитектурным стилем. Этот параметр уменьшает количество возможных форм, которые может принимать архитектура, и навязывает ей некоторую степень единообразия. Этот механизм используется для предоставления "жизни" то есть линии поведения другим классам. В шаблонах документи руется сложившийся, доказанный опыт проектирования. Мы знаем, что данная структура делается из стали и бетона, а не из дерева. Также известно, что, помимо лестниц, проект включает лифты. Шаблоны и механизмы предлагают архитектору развивающийся инструментарий для решения архитектурных проблем. Важную роль в этом наборе инструментов играют шаблоны и механизмы. Model-View-Controller MVC и Object Request Broker ORB. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerland and Michae Stahl. A System of Patterns. John Wiley and Sons, В данной главе вводятся понятия прецедентов, акторов и сценариев. Для моделирования проблемы, а также определения требований и ограничений разрабатываемой системы можно применять различные подходы. В этом случае весьма вероятно неверное истолкование проблемы, и довольно часто просто затруднительно обосновать решение по отношению к поставленной проблеме. Более того, в процессе, который должен оставаться непротиворечивым, придется работать с несколькими моделями, что совсем не будет способствовать его согласованности. Именно прецеденты позволяют так выразить проблему, чтобы она была понятна значительному числу пользователей, разработчиков и заказчиков. Ivar Jacobson, Grady Booch and James Rumbaugh. Прежде чем приступить к построению модели прецедентов, нужно разобраться с двумя концепциями: Поясним ключевые термины, используемые в данных выше определениях. Действие может предполагать передачу сигналов задействованному актору или другим акторам. Действие является элементарным; это означает, что оно либо выполняется полностью, либо не выполняется вовсе. Возможно множество потоков; многие из них могут быть подобными. Чтобы модель прецедентов была понимаемой, подобные потоки объединяются в один прецедент. Таким образом, прецедент помогает очертить область действия системы. Последовательность действий должна давать что-то, имеющее значение для актора системы. Для получения чего-либо полезного не нужна реализация нескольких прецедентов. При акцентировании внимания на отдельном акторе выделяется значение, которое прецедент представляет для отдельных групп ролей пользователей системы; таким образом мы гарантируем, что система делает именно то, что требуется пользователям. Он также предотвращает рассеивание внимания и позволяет избежать создания системы, пытающейся удовлетворить потребности всех и каждого, поскольку в итоге она не сможет удовлетворить ничьи потребности. Процесс, управляемый прецедентами В описании прецедента указывается, что делает система при его выполнении. Все функциональные возможности системы определяются именно набором прецедентов, каждый из которых представляет определенный поток событий. Пример прецедентов и акторов. Все эти возможности рис. Рассмотрим пример потока событий для одного из описанных выше прецедентов. Исходную схему потока событий прецедента Снятие денег можно записать следующим образом. Система печатает квитанцию если ее заказывали. Выбранный путь зависит от следующего. Например, банковские клиенты могут в любой момент аннулировать операцию или же они могут отказаться от квитанции. В банкомате, например, может не хватить наличных или бумаги для печати квитанций; может "заесть" устройство выдачи денег или принтер. Если пользователь банкомата не отвечает по прошествии определенного времени, система может автоматически аннулировать операцию. Если пользователь несколь- -ко раз подряд вводит неверный PIN-код, то операция может быть аннулирована, а. Результатом такого объединения является класс прецедентов. Другим названием экземпляра класса прецедентов является сценарий. Рассмотрим пример с банкоматом. Для упрощения рассуждений забудем на время о множественных операциях. Значима для вас эта последовательность действий? Будете ли вы счастливы? Банкомат используется для получения денег, перевода средств и т. Прецедент можно также рассматривать как средство достижения некоторой "цели", которую система должна дать актору. Действия, составляющие прецедент, нельзя разрывать. Почему эти блоки объединяются в группу, которая называется прецедентом? Да потому, что так удобнее управлять этими функциональными блоками в течение всего. Начинать всегда следует с разработки эскиза прецедента в пошаговом формате , а лишь затем можно переходить к подробностям. Зачастую модель содержит прецеденты, которые настолько просты, что они не требуют подробного описания потока событий, поэтому достаточно будет простого пошагового эскиза. Критерий такого разделения прецедентов прост: Structuring Use Cases with Goals. Journal of Object-Oriented Programming, Sept. Но при переходе к большим системам необходимо определить принципы организации и структурирования. Также можно использовать и отношения между прецедентами, для чего придется внимательно рассмотреть поток событий. Поток событий можно рассматривать как несколько подпотоков один основной поток и один или несколько альтернативных , которые, будучи связанными, дают суммарное описание потока событий. Иными словами, данный тип поведения должен иметь только один набор объектов, а то, какой при этом выполняется прецедент, не должно иметь значения. Если более двух прецедентов содержат одинаковые последовательности действий или формируют независимую часть процесса, то эти последовательности действий стоит выделить в отдельный прецедент и использовать именно как прецедент. Это подобно разложению программы на подпрограммы. В одной и той же модели не обязательно два-три раза выражать поток событий, связанный с введением PIN -кода. Вместо этого в оба прецедента можно включить прецедент Аутентификация пользователя рис. Не стоит поддаваться соблазну и разбивать все прецеденты на множество небольших, бессмысленных прецедентов, не имеющих никакого значения для актора. Прецедент может расширять существующий прецедент. Рассмотрим, например, использование телефонного коммутатора. В этом случае обычный вызов по телефону определенного лица можно развить до работы по принципу прохождения вызова или циркулярного вызова. Расширение прецедента происходит в определенных точках, называемых точками расширения. Например, в системе управления полетами прецедент Запись схемы рейсов аэрофлота основан на тех же основных принципах и последовательностях действий, что и общий прецедент Запись схемы рейсов, но он включает некоторые уточнения, а также специфические этапы или параметры. Отметим, что злоупотребление этими тремя отношениями является одной из весьма распространенных ошибок, приводящих к созданию модели прецедентов, которую трудно понимать и эксплуатировать, а также к значительному перерасходу средств. В этом процессе прецеденты нужны для сбора информации о том, что система должна делать по мнению пользователей. В технологическом процессе реализации модель проектирования представляет собой спецификацию реализации. Другими словами, каждый прецедент реализуется для проверки системы. С прецедентами связаны и другие виды деятельности. В процессе распространения пакеты прецедентов могут применяться для планирования поэтапного распространения или определения вариантов системы. В моделировании производства может использоваться то же понятие прецедента, но уже не на уровне разрабатываемой системы, а на более высоком уровне всего предприятия. Более подробно этот вопрос будет рассмотрен в главе 8, "Технологический процесс моделирования производства". Прецеденты помогают синхронизировать содержание различных моделей. В процессе разработки прецедентом управляют как единым целым. Описанные экземпляры класса прецедентов называются сценариями. Созданием и утверждением модели проектирования. Определением контрольных задач и методик испытания модели тестирования. Результатом процесса должен быть продукт, удовлетворяющий потребностям заказчиков тех, кто оплачивает счета и конечных пользователей. Существует три основные цели процесса управления проектом. Создать контур для управления преимущественно программными проектами. Обеспечить практическое руководство по вопросам планирования, кадрового обеспечения, реализации проекта и наблюдения за проектом. Создать контур для управления риском. Например, не освещаются следующие вопросы. Управление контрактами с поставщиками и заказчиками. Данный технологический процесс акцентирует внимание лишь на определенных аспектах процесса итеративной разработки. Наблюдение за прогрессом итеративного проекта и метрики. Убедить руководство проекта в преимуществах итеративного процесса, как правило, нетрудно см. Тут же возникают новые вопросы. К целям планирования проекта относятся следующие. Автор лично видел эти графики Гантта и логические сети видов деятельности, которые полностью покрывали стены нескольких комнат и приемных. Данный подход оправдал себя в промышленности, где декомпозиция работ более ИЛИ менее стандартна и устойчива, а распределение заданий предопределено, по-. Технологический процесс управления проектом В нем указано следующее. Вехи выпуска продукта конец фазы развертывания и жизненного цикла в целом. Для описания плана обычно требуется не более одной-двух страниц. Как правило, в каждый момент времени "активны" два плана итерации. Следующий план итерации план следующей итерации , создаваемый во второй половине текущей итерации, причем к концу итерации он должен быть завершен. План итерации создается с использованием традиционных инструментальных средств и технологий планирования графиков Гантта и т. Представить план итерации можно как окно, перемещающееся по плану фаз и действующее как лупа рис. Управление риском относится уже к области неизвестных и ненадежных аспектов разработки. В настоящее время многие организации работают в режиме "отрицания риска": Seminar at Software productivity Center, Vancouver, В. Многие решения итеративного жизненного цикла управляются рисками. В повседневной жизни под риском понимается курс, содержащий неопределенную опасность, а также возможность упустить важное условие, предмет, элемент. Риски можно разделить на прямые и косвенные. Кроме того, можно ввести два важных параметра. Воздействие на проект серьезность. Эти два параметра часто объединяют в единый показатель величины риска. Ключевая идея процесса управления рисками звучит так: Итак, возможны три основные линии поведения. Такая реорганизация проекта, при которой риску подвергается кто-то другой или что-то другое заказчик, поставщик, банк или другой элемент проекта. При выборе стратегии принятия риска необходимо следующее. М Снизить вероятность риска. В основном для того, чтобы контролировать проект, а следовательно, управлять им. Измерения проводятся для определения того, насколько близко или далеко текущее состояние проекта от поставленной цели. Это "расстояние" выражается через завершенность проекта, его качество и соответствие требованиям. Измерения нужны и для того, чтобы на основе полученного опыта можно было лучше спланировать работы, определить стоимость и качество нового проекта. И наконец, измерения выполняются для оценки эффектов изменений и определения того, как со временем можно улучшить эффективность процесса см. Эти цели можно разделить на две группы. Эти цели формулируются с использованием глаголов оценить, предсказать, отследить и т. Они выражают желание лучше понять процесс разработки. Эти цели формулируются с использованием глаголов увеличить, уменьшить, улучшить, получить и т. Они связаны с наблюдением за изменениями или улучшениями, происходящими по мере развития объектов в ходе нескольких итераций или проектов. Приведем примеры целей при разработке программного обеспечения. Отследить отношение прогресса к плану. Повысить степень удовлетворенности заказчика. A Quantitative Approach to Software Management- The ami Handbook. Отметим, что процесс перевода этих общих целей в метрику проходит в несколько этапов. Определить степень удовлетворенности заказчика. Измерить степень удовлетворенности заказчика в нескольких версиях. Подтвердить повышение степени удовлетворенности. Цель улучшить производительность будет включать следующие подцели. Измерить объем произведенных работ. Вычислить производительность нескольких итераций проекта. Некоторые но не все подцели будут требовать сбора метрик. Существует два типа метрик. Каждая метрика включает одну или несколько примитивных метрик. Обратите внимание на фигуру рецензента проекта, отвечающего за оценку артефактов, связанных с планированием и оценкой проекта, выполняемой в точках рецензирования жизненного цикла проекта. Ниже Представлены ключевые артефакты технологического процесса управления проектом. Планы итераций по одному на каждую итерацию. База данных измерений проекта. Отметим, что хотя план SDP и включает несколько других планов, за разработку последних отвечают разные исполнители. План управления конфигурацией разрабатывается Исполнителем: План разработки план процесса, используемого в проекте разрабатывается Исполнителем: Технологический процесс разбивается на ряд подпроцессов, называемых элементами. Оценка области действия проекта и риска. Данный элемент технологического процесса включает такие виды деятельности: Она должна создать прочную основу для подробного планирования и помочь определить, какие новые знания получены к концу каждой итерации и какие риски устранены. Создание плана разработки программного обеспечения. Данный элемент технологического процесса включает следующие виды деятельности. Разработка плана управления риском. Разработка плана принятия продукта. Разработка плана разрешения проблем. Определение структуры проекта и обеспечение проекта кадрами. Определение процессов наблюдения и контроля. Планирование фаз и итераций. Составление плана разработки программного обеспечения. За все эти виды деятельности отвечает руководитель проекта. Затем данный элемент проекта активизируется в начале каждой итерации и, исходя из опыта предыдущих итераций и плана следующей итерации, корректирует план разработки программного обеспечения и его приложений. Отметим, что критическое рассмотрение всего, что затрагивает план разработки программного обеспечения, входит в обязанности руководителя проекта. Наблюдение и контроль над проектом. Данный элемент процесса включает такие виды деятельности: Данный элемент процесса фиксирует текущую ежедневную работу руководителя проекта и включает следующее. Данный элемент процесса включает следующие виды деятельности: Решены ли все основные проблемы предыдущей итерации. Известно ли состояние всех основных артефактов определяется при ревизии конфигурации. Окончательная оценка состояния фазы выполняется для обзора, производимого в вехе жизненного цикла проекта. Руководитель подготавливает проект к завершению. Для выполнения обзора принятия проекта готовится заключительная оценка состояния. В случае успешного принятия проекта пользователь формально получает продукт в пользование. Рассмотрим теперь некоторые важные аспекты этих видов деятельности более подробно. Чтобы начать создание плана фаз, нужно, по меньшей мере, оценить "размер горы". Например, нужно рассмотреть следующие вопросы. Насколько велика эта гора то есть общий объем работ? Когда нужно добраться до вершины даты финального выпуска? Компромисс между персоналом, графиком работ и областью действия проекта. Начать можно с типичного профиля, такого, например, как приведенный на рис. Такой профиль подходит проекту, имеющему следующие характеристики. Средний размер проекта и средний объем работ. Незначительное число рисков и новшеств. Находится в первоначальном цикле разработки. Не имеет предопределенной архитектуры. Для удобства этот же профиль представлен и в виде таблицы табл. Распределение времени и объема работ по фазам. Фазы Время работы Объем работы. Предположим теперь, что данный профиль сделан из резины. Будем вытягивать его и массировать, чтобы подогнать под имеющиеся обстоятельства, следуя при этом указанным ниже эвристическим правилам. Прежде чем принять решение по этому вопросу, рассмотрим вначале вопрос продолжительности каждой итерации. Хотя цикл редактирование, компиляция, тестирование, отладка и звучит как итерация, но это не совсем то, что мы здесь называем итерацией. В идеале, итерация длится от двух до шести недель, хотя в действительности это зависит от проекта. Пять человек могут выполнить некоторое планирование в понедельник утром, наблюдать за прогрессом и перераспределять задания во время ежедневных совместных обедов, начать построение во вторник, а завершить итерацию в пятницу вечером. Если мы попытаемся применить этот сценарий для группы из 20 человек, то это окажется затруднительным. Распределение работы, синхронизация подгрупп и интеграция будут занимать уже больше времени. В этом случае итерация может занять три-четыре недели. Кроме того, влияние оказывают и другие факторы: Кроме того, следует сознавать, что требуется итерация некоторых определенных служебных издержек на планирование, синхронизацию и анализ результатов. Длительность итерации, приемлемая для многих итеративных проектов. Впрочем, в некоторых случаях итерации все же могут быть. Они могут потребоваться для следующего. Создания прототипа, призванного убедить вас или вашего спонсора возможно, заказчика или предпринимателя, идущего на риск в ценности предлагаемой идеи. Помните, что целью фазы исследования является совсем не накопление кода. В этой фазе вы просто должны максимально быстро получить ответы на поставленные вопросы. В фазе уточнения плана нужна, как минимум, одна итерация. Возможно, потребуется продемонстрировать прототип заказчик 7 или конечным пользователям, чтобы помочь им лучше определить требования помните, узнаю, когда увижу? Кроме того, дополнительная итерация может потребоваться для исправления ошибок, допущенных при разработке архитектуры. Итак, в фазе уточнения плана требуется от одной до трех итераций. В фазе построения также нужно запланировать не менее одной итерации. Таким образом, в этой фазе нужны одна-три итерации. В фазе развертывания нужна, как минимум, одна итерация, например, для выпуска финальной версии после бета-версии. Достаточно часто результаты анализа рынка или низкое качество первоначальной версии заставляют выполнить большее число итераций. Итак, в фазе развертывания нужно провести одну-две итерации. Существует три уровня проведения полного цикла разработки [И, У, П, Р]. Это эмпирическое правило мы будем называть "шесть плюс-минус три". Ранее уже показывалось, что содержание и акценты итераций меняются при переходе от фазы к фазе. Хотя при этом меняются и критерии, которые мы будем учитывать, общий рецепт остается неизменным. Итак, в качестве основного примера мы разберем итерацию в фазе уточнения плана, а позднее отметим, как изменятся итерации для других фаз. Для начала рассмотрим итерацию, ее длительность, а также ресурсы, которые требуется распределить для ее ограничения. Помните, что рассчитывать нужно только на такой объем работы, который может быть выполнен за одну итерацию. Планировать нужно по времени, а не по объему. План итерации подробно описывает, что должно произойти за время итерации. Он распределяет виды деятельности исполнителям и назначает сотрудников на роль исполнителей. Напомним, что термин исполнитель используется нами в несколько особом смысле; см. Для создания плана итерации следует пройти четыре этапа. Итерация в фазе уточнения плана. Существует три основных фактора, определяющих цели итерации в фазе уточнения плана. Основным фактором, определяющим цели итерации, является риск. Риски следует устранять как можно раньше или, по крайней мере, нужно смягчать последствия от их. Особенно это важно в фазе уточнения плана, хотя и в фазе построения фактор риска все же остается ключевым, поскольку здесь некоторые риски все еще велики и, кроме того, выявляются еще и новые. Поскольку целью фазы уточнения плана является создание базовой линии архитектуры, следует учитывать и фактор охвата: Предположим, что у нас имеется перечень текущих рисков проекта. Для удовлетворения фактора критичности в артефакт следует выделить наиболее важные функции или предоставляемые услуги. Для удовлетворения фактора охвата к концу фазы уточнения плана в отдельный артефакт следует выделить сценарии, относящиеся к области, заведомо требующей разработки. Зачастую экономически выгодно создать продолжительный сквозной сценарий, объединяющий множественные проблемы. Например, сценарий, который является критичным и противостоит двум техническим рискам. Кроме того, в фазе уточнения плана следует помнить, что некоторые риски могут зависеть от человеческого фактора. Приведем несколько примеров целей итераций. Итерация в фазе построения. При переходе проекта в фазу построения фактор риска все еще остается основным, особенно это относится к новым и непредвиденным рискам. В то же время еще одним немаловажным фактором является завершенность прецедентов. Приведем примеры целей итераций для фазы построения. Итерация в фазе развертывания. Приведем примеры целей итераций фазы развертывания. Подробнее о работе при итерации. Какие классы должны быть переработаны? Какие подсистемы затрагиваются или создаются? Какие интерфейсы могут требовать модификации? Какие документы следует обновить? Соедините виды деятельности с их очевидными зависимостями и распределите предполагаемые работы. В зависимости от того, в какой фазе произошла данная неприятность, можно либо упростить сценарий, либо исключить или отключить некоторые функции. При итеративном процессе разработка должна основываться на плане фаз и последовательности планов итераций. Основным фактором, направляющим планирование, является риск. Ключевой технологией, используемой для контроля над проектами, является измерение. Критерии, определяющие масштаб итераций, меняются в зависимости от фазы проекта. В данной главе объясняется, зачем нужно моделировать производство перед началом разработки системы. Рассматривается несколько способов такого моделирования. Описывается, как из модели производства определить требования к программному обеспечению. Цели моделирования производства состоят в следующем. Эти приложения должны интуитивно восприниматься исполь-. Технологический процесс моделирования производства Это становится очевиднее при подготовке организаций к вступлению в мир е-бизнеса. Кстати, а что обозначает это модное словечко е-бизнес? Как и в случае прочих широко употребляемых жаргонных терминов, значение этого слова до некоторой степени зависит от того, кто его использует. Согласно определению, которое будем использовать мы, е-бизнес или электронный бизнес связан с созданием систем иногда называемых коммерческими или производственными инструментальными средствами , автоматизирующих производственные процессы. Некоторые организации, разрабатывающие программное обеспечение для е-бизнеса, основной частью своих проектов считают моделирование производства. Коммерческие инструментальные средства, создаваемые для отрасли е-бизнеса, можно разбить на следующие категории. Потребительские, приложения, позволяющие заказывать товары через Internet , например электронные книжные магазины. Коммерческие, автоматизируют цепь поставок между компаниями. Коммерческие, предоставляют для потребителей иногда пассивных информацию, например, посредством распространения информационных бюллетеней. В зависимости от сути производства и требований к нему возможны шесть сценариев его моделирования. Обычно это часть программно-технического проекта, выполняемая в фазах исследования и уточнения плана. Одно производство для нескольких систем. При создании большой системы или семейства приложений может получиться так, что одна работа, связанная с моделированием производства, будет использоваться в. Это поможет избежать слишком? В этом случае работы по! Реорганизация, как правило, выполняется в несколько этапов: В процессе моделирования производства задействованы следующие основные ис-1 полнители. A Manifesto for Business Revolution. В этом случае моде- i лирование производства часто рассматривается как отдельный проект. При разработке приложения, которое будет использоваться несколькими организация- ми например, приложение организации продаж или составления счетов , полезно бу- I дет усреднить способы ведения организациями дел. Это поможет избежать слишком I больших требований к системе. Если организация решила открыть совершенно новую сферу деятельности и создать для ее поддержки информационные системы, то в этом случае также требуется проведение I работ по моделированию производства. В этом случае работы по j моделированию производства также часто рассматриваются как отдельный проект. Разработчик производства устанавливает обязанности, действия, параметры одного или нескольких производственных исполнителей, а также их связь с категориями производства. Кроме того, в технологическом процессе участвуют следующие исполнители. Рщетент производства, представляющий рецензию на результирующие артефакты. В процессе моделирования производства создаются ключевые артефакты. Необходимая основа для определения ролей и комплектующих узлов. Кроме того, создаются следующие артефакты. Модель производственных прецедентов включает производственные акторы и производственные прецеденты. Для отображения групп и отделов организации-разработчика производственные акторы и категории производства могут объединяться в организационные блоки. На этом этапе создаются следующие основные артефакты: При этом процесс идет по маршруту моделирования производства, но пропускается действие описание текущего производства. Если моделирование производства осуществляется в целях разработки нового производства практически с нуля сценарий 5 , то необходимо представить себе новое производство и создать его модели, пропустив действие описание текущего производства. Модели производства и акторы системы. Каким образом можно определить акторы и прецеденты потенциальной системы? Начать необходимо с производственных исполнителей модели объектов производства. Затем для каждого производственного исполнителя определяются акторы потенциальной системы. А после этого для всех произведет венных прецедентов, в которых участвуют действующие производственные акторы, создаются прецеденты потенциальной системы. При создании приложений такого типа приходится сталкиваться с изменением способа ведения дел. Обязанности производственных исполнителей передаются производственным акторам. Пример такой ситуации приведен на рис. Модели производства и классы категорий в модели анализа. Следовательно, соответствующие категории системы могут участвовать в нескольких информационно-системных прецедентах. Модель объектов производства для планирования ресурсов. Давайте рассмотрим некоторые из них. Все вопросы, связанные с унаследованными функциями или свойствами. Координация и синхронизация с другими проектами. Тенденции в сфере проекта и информационных технологий. Модели производства и архитектура системы. С точки зрения архитектуры наличие моделей производства особенно полезно при построении систем двух типов. В этих случаях модели производства внесли бы вклад в прецедентное и логическое представление системы. Кроме того, появилась бы возможность определить ключе вые механизмы на уровне анализа механизмы анализа. И это не случайно. Поскольку для моделирования производства и системы используются одни и те же понятия языка UML особенно это справедливо для незначительно отличающихся стереотипов , то в обоих случаях можно применять и одинаковые инструментальные средства. Моделирование производства необходимо для понимания его структуры динамики, для обеспечения полного понимания целевой организации всеми заинтересованными сторонами, а также для получения системных требований в целях поддержки этой организации. В моделировании производства могут использоваться те же методы, что и программно-техническом моделировании. В зависимости от характера целевой организации, а также от среды проекта, могут применяться различные сценарии моделирования производства. Reengineering Your Software Engineering Process. В данной главе описываются важные концепции определения системных требований и эффективного управления ими. В ходе технологического процесса управления требованиями необходимо выполнить следующее. Разработчики должны полнее понять системные требования. Должны быть определены границы системы. Он выделил следующие необходимые параметры качества: В дальнейшем мы будем использовать аббревиатуру FURPS , которая напоминает о типах требований, требующих! Функциональные требования используются для выражения поведения системы путем задания предпосылок и возможностей, ожидаемых в качестве результата. Для передачи в руки пользователя системы с приемлемым качеством одних только функциональных требований недостаточно. Следовательно, необходимо ввести дополнительный набор требований, называемых нефункциональными. Стоит отметить, впрочем, что, несмотря на разные названия, требования обоих видов одинаково важны для конечного пользователя. Practical Software Metrics for Project Management and Process Improvement. Требования этого типа связаны с возможностью тестирования, эксплуатации и другими параметрами качества, необходимыми для обновления системы после ее выпуска. Для эффективного управления всеми требованиями необходимо иметь полное понимание нужд пользователей и других заинтересованных сторон, которым должна удовлетворять разрабатываемая система. Это понимание позволяет команде разработчиков ответить не только на вопрос что? Другими заинтересованными сторонами могут быть лица, получающие экономические выгоды от реализации системы. Но как понять эти нужды? Одним из необходимых условий является сбор в процессе всего жизненного цикла запросов заинтересованных сторон необработанных данных, используемых для вычисления нужд. Кроме того, если к этим свойствам добавить различные ат-. Ни понимания нужд заинтересованных сторон, ни понимания свойств системы не достаточно для точного сообщения разработчикам, что же должна делать система "Эй, Билл, займись программированием системы автоматического уведомления". Задание программных требований с помощью прецедентов. Последние выражают услуги, которые должны быть предоставлены заинтересованным сторонам для удовлетворения их нужд. Этот анализ фиксируется в бизнес-плане проекта. Такие подробные требования фиксируются в модели прецедентов и различных дополнительных спецификациях, включающих требования, не совсем подходящие для выделения в прецеденты. Выражение "проектирование пользовательского интерфейса" может означать одно. Визуальное формирование пользовательского интерфейса, удовлетворяющего различным требованиям практичности. В технологическом процессе управления требованиями мы будем использовать первое определение, причем основное внимание будет обращаться на интерфейс, ориентированный на пользователя. Процесс создания прототипа пользовательского интерфейса способствует созданию весьма полезного механизма обратной связи, позволяющего определить окончательные требования к системе. Разберем эту диаграмму подробнее. Последнее действие позволит максимально полно удовлетворить ожидания пользователей, не выходя за времени ые и бюджетные рамки проекта. Модель прецедентов способствует уточнению программных требований и позволяет прийти к соглашению с заказчиком относительно функциональных возможностей системы. Как все сказанное выше реализуется в терминах исполнителей, артефактов и видов деятельности? Системный аналитик в ходе проекта сотрудничает со всеми заинтересованными сторонами. На основе полученной информации он разрабатывает видение проекта. В большинстве случаев эти два исполнителя работают в тесном сотрудничестве. В процессе управления требованиями задействован также архитектор. На ранних итерациях он сотрудничает с системным аналитиком и спецификатором прецедентов в целях обеспечения целостности архитектурно значимых прецедентов. При рассмотрении требований особое внимание следует обратить на определение и масштаб проблемы, которую мы пытаемся решить с помощью системы. Значительную помощь в этом оказывает модель объектов производства, разрабатываемая в процессе моделирования производства. Запросы заинтересованных сторон нужны для получения "перечня желаний", то есть ответа на вопрос, чего ожидают от системы различные заинтересованные стороны заказчики, пользователи, покупатели или что желают в ней увидеть. Эти артефакты представляют собой еще один важный источник информации, помимо системных требований. В ходе каждого проекта должна существовать возможность получения информации от заинтересованных сторон. В этом документе должно описываться, что будет включено в систему и какие свойства было решено исключить. В результате это позволяет. Как уже неоднократно упоминалось, модель прецедентов состоит из прецедентов и акторов. Важность словаря очевидна, поскольку в нем определяется общая терминология, которая должна непротиворечиво использоваться в ходе проекта. Для этого существует архив прецедентов и прототипы пользовательских интерфейсов, разрабатываемые параллельно с выполнением других действий данного технологического процесса. Более того, если вы используете прецеденты, то приложение RequisitePro поможет вам описать их текстовые свойства. Использование этого приложения также облегчает поддержание связи с элементами модели проектирования. Поддержание атрибутов требований и возможности оперативного контроля - вот ключевые элементы эффективного управления областью действия проекта и обработки меняющихся требований в ходе жизненного цикла проекта. Целью анализа является преобразование требований системы в форму, понятную разработчику программного обеспечения. В процессе анализа и проектирования могут участвовать и другие исполнители. Разработчик оболочки для систем реального времени. Этот, исполнитель отвечает за возможность системы своевременно реагировать на события. Для обеспечения этого используются методы параллельного проектирования. Документ архитектуры программного обеспечения, в котором собраны различные архитектурные представления системы. Она состоит из множества взаимодействий элементов модели, обеспечивающих требуемое поведение системы. В общем случае в системе существует одна модель анализа. Использование единственной модели уменьшает число артефактов, требующих поддержания в согласованном состоянии. В ней опускается большинство подробностей работы системы и дается обзор функциональных возможностей системы в целом. Хотя использование такого представления системы, в котором описаны только важнейшие детали работы системы, выгодно, не следует забывать и о непротиворечивости моделей анализа и проектирования. Интерфейсы задают набор операций, выполняемых элементами модели, в том числе количество и типы параметров. Интерфейсы повышают гибкость проектов, уменьшая зависимости между частями системы, и, следовательно, позволяют легче менять эти части. Такие системы находят применение в приложениях с жесткими требованиями к безопасности. Технологический процесс анализа и проектирования Каждая оболочка содержит порты, через которые происходит сообщение с другими оболочками. Это описание происшедшего в пространстве и времени или, менее формально, появление чего-то, на что должна отреагировать система. Это асинхронное событие, которое может вызвать смену состояний конечного автомата или объекта. Эти дополнительные артефакты являются стереотипами класса и частью модели проектирования. Они поддерживают подход к разработке систем реального времени, основанный на идеях, представленных в работе Real-Time Object-Oriented Modeling. Элементами модели проектирования, относящимися к компонентам, являются подсистемы. Подсистемы также предлагают интерфейсы и зависят от интерфейсов других элементов модели. Некоторые элементы процесса зависят от фазы разработки: В последующих итерациях фазы построения акцент смещается на увеличение функциональных возможностей приложения, которое должно реализовываться на определенной, к тому времени, стабильной архитектурной платформе. Из архитектурно значимых прецедентов определить классы анализа. Дополнить реализации прецедентов взаимодействиями классов анализа. Рассматриваемый элемент технологического процесса состоит из следующих видов деятельности: Описать структуру рабочего цикла системы и архитектуры распространения. Целью этого элемента процесса является преобразование поведенческих описаний, предлагаемых прецедентами, в набор элементов, на основе которых можно создать. Его целью является следующее. Уточнить определение элементов проекта путем подробного описания того, I как эти элементы реализовывают требуемое от них поведение. Рецензировать проект по мере его развития. В компонентах проекта полностью определяются характеристики и отношения I классов, интерфейсы подсистем и их реализации классами-контейнерами, а также I реализации прецедентов в терминах взаимодействий. Проектирование компонентов реального времени. Последнее необходимо для определения параллельных потоков управления в системе то есть оболочек и протоколов между ними. Он состоит из следующих видов деятельности: Целью этого элемента является следующее. Определить постоянно хранимые классы. Спроектировать структуру базы данных, подходящую для хранения постоянно хранимых классов. Предпочтительным языком для выражения всех описанных моделей является UML , а все указания по моделированию, связанные с различными артефактами, выражаются в терминах этого языка. SoDA позволяет автоматически создавать документы и отчеты, извлекая информацию из нескольких инструментальных средств, таких как Rose или RequisitePro , и форматируя ее. Этот процесс использует прецеденты для определения набора объектов, которые последовательно превращаются в классы, подсистемы и пакеты. Представление распространения отображает эти процессы в набор узлов, на которых они выполняются. В некоторых случаях отдельная модель анализа может использоваться для обзора или обобщения системы. В главе описывается технологический процесс реализации. Здесь вводятся понятия прототипов и поэлементной интеграции. Существует четыре основные цели технологического процесса реализации. Реализовать классы и объекты через компоненты исходные файлы, двоичные коды, исполняемые файлы и др. Провести блочное тестирование разработанных компонентов. Тестирование системы и тестирование интеграции будут описаны в технологическом процессе тестирования см. В то же время следует помнить, что на практике эти технологические процессы обычно переплетаются. Технологический процесс реализации В процессе итеративной разработки программного обеспечения будут создаваться множественные конструкции. Как правило, конструкции в проектах пытаются создавать через определенные интервалы времени, максимум по одной в день, но не менее одной в неделю к концу итерации. Делается это исходя из следующих соображений. Для интеграции подсистем в целостную систему. Поэлементная интеграция означает, что коды пишутся и тестируются небольшими блоками, после чего они объединяются в рабочее целое путем постепенного добавления блоков. Ошибка может находиться в любом из новых компонентов, во взаимодействии между этими компонентами или во взаимодействии между новыми и существовавшими ранее компонентами. Использование поэлементной интеграции имеет следующие преимущества. М Компоненты тестируются полнее. Это означает, что они используются чаще, чем при единовременной интеграции множественных компонентов. Прототипы используются для снижения вероятности риска. Они могут прояснить следующие моменты. Коммерческая жизнеспособность разрабатываемого проекта. Устойчивость или производительность ключевой технологии. Обязательства по проекту или финансирование проекта для этого создается небольшой испытательный прототип. Прототип может обеспечить поддержку продукта путем демонстрации пользован телям, заказчикам и руководству чего-то конкретного и исполняемого. В то же время природа и цель прототипа должны оставаться ясными в течение всего жизненного цикла проекта. Если прототип не планировалось развивать в реальный j продукт, то не стоит, глядя на его прекрасную работоспособность, внезапно решать, что он должен быть преобразован в окончательный продукт. Прототипы можно рассматривать двояко: В первом случае прототипы можно разделить на две группы. Структурные, исследующие архитектурные или технологические вопросы. Во втором случае также имеется два типа прототипов. Эволюционные прототипы, развивающиеся в конечную систему. Довольно часто прототипы этого типа "лепятся наспех" и не соответствуют стандартам проек-ти.. Структурные прототипы, как правило, являются эволюционными; в них, вероятнее всего, используется инфраструктура конечной системы "кости" , и эти прототипы, как правило, развиваются в конечную систему. Эволюционные прототипы, как явствует из названия, эволюционируют при переходе от одной итерации к другой. Хотя изначально их качество далеко от идеального, коды этих прототипов перерабатываются по мере развития продукта. Для управляемости этой переработки прототипы стараются разрабатывать и тестировать формально,. Ключевыми артефактами процесса реализации являются следующие. Часть программного кода исходного, двоичного или исполняемого или файл, содержащий информацию например, файл запуска или ознакомительный файл. Этот документ определяет порядок реализации компонентов и подсистем и задает, какие конструкции должны быть созданы при интеграции системы.
The page you were trying to reach does not exist. Or, maybe it has moved. You can start again from home or go back to the previous page.
Скачать видео с ютуба буквы
Новейшие препараты для лечения псориаза
Как замариновать мясо для горячего копчения
10 port usb 3.0 hub
Принципы и методы научного менеджмента