Архитектура приложений
Здесь описываются стандартные интерфейсы, службы и модели приложений, необходимые для Вашего бизнеса. Они составляют основу работы групп проектов (например, библиотеки компонентов и кода, стандартизирующие документы и рекомендации по разработке). Архитектура приложений, кроме того, определяет автоматизированные службы поддержки бизнес-процессов, составляющих бизнес-архитектуру, и взаимодействия и взаимозависимости приложений, используемых в организации. Также она предлагает рекомендации по разработке перспективных приложений и переходу на новые модели программ. Вот основные вопросы, решаемые на этой стадии.
Возникают ли проблемы при интеграции систем, применяемых в настоящий момент?
Какие модели приложений Вы используете в своей организации?
Применяете ли Вы журналы работы приложений?
Какие программы уникальны для Вашего бизнеса?
Какие приложения лучше приобретать у независимых поставщиков программного обеспечения?
Что важнее для Вас: функциональная эффективность приложений или надежность?
Замедляют или нет используемые приложения обслуживание потребителей?
Бизнес-сервисы
Бизнес-сервисы — это модули логики приложения, управляющие соблюдением бизнес-правил итранзакционной целостностью выполняемых операций. Бизнес-сервисы преобразуют данные в информацию с помощью надлежащего применения бизнес-правил.
Физическая стадия
Наконец, с проектом знакомятся строители, они корректируют замыслы архитектора, уточняя доступность технологий и материалов. На этом этапе составляется план всех строительных работ, который может существенно повлиять на деятельность смежников (например, на планы поставки отдельных субподрядчиков). В модели разработки решений это физическая стадия (см. рис. 13.5), где на логическую модель накладываются реальные технологические ограничения, а также учитываются вопросы реализации и производительности. На этой стадии оцениваются реальные потребности в ресурсах, стоимость и график работ.
Эти три стадии не следует рассматривать как строго ограниченные этапы. Они не подразумевают точной точки отсчета или четких сроков. Не требуется завершить всю работу одной стадии, чтобы перейти к другой — составляющие могут накладываться друг на друга. Например, некоторые части системы могут быть реализованы, когда другие еще только проектируются. Если информация становится доступной раньше, чем предполагалось, ее следует использовать сразу же — нет смысла ждать, пока наступит оговоренный в модели момент.
Формирование представления
Формирование представления гарантирует, что разрабатываемое решение или продукт будут соответствовать как текущим, так и перспективным целям компании, а также помогает скорректировать направление развития организации. Эта стадия требует глубокого осмысления целей проекта. Формирование представления позволяет избежать, например, инвестирования в незначительные или неэффективные проекты. В результате этой стадии составляется представление о продукте, определяются его функциональные возможности и оцениваются результаты. Если новый продукт (или, в случае развертывания инфраструктуры, новая служба) вызывает интерес и получает одобрение, составляется группа разработки проекта, задача которой — выработать концепцию продукта. На этом этапе фиксируются цели и определяется четкое направление разработки. Здесь же определяются возможности конкретной версии продукта или службы и оцениваются тенденции развития продукта в следующих версиях.
Информационная архитектура
Информационная архитектура позволяет выделить информацию, необходимую для выполнения бизнес-процессов и операций компании. Это стандартные модели данных, стратегия управления ими, описание схем потребления и производства информации в организации, а также способы участия данных в рабочем процессе. Некоторая наиболее важная информация находится не только на серверах баз данных, но также и на тысячах локальных компьютеров, как это часто бывает в крупных организациях. Вот основные вопросы, решаемые на этой стадии. Каковы потребности Вашего бизнеса в информации?
Каковы промышленные требования и стандарты?
Какая информация жизненно важна для Вашего бизнеса?
Каковы основные проблемы, связанные с информацией?
Каковы Ваши функциональные требования к данным?
Каковы Ваши требования к данным бизнес-процесса и к документообороту?
Существуют ли законодательные ограничения на получение и использование информации?
Интеграция Visual SourceSafe со средствами разработки
Microsoft Visual Studio — это новая интегрированная среда разработки, объединяющая такие средства, как Visual Basic, Visual C++ и Visual FoxPro. Visual SourceSafe интегрируется с Microsoft Visual Studio, а также с Visual Basic Professional Edition и Visual Basic Enterprise Edition. Visual SourceSafe не входит в состав большинства этих продуктов (а только в Visual Basic Enterprise Edition), его надо приобретать отдельно. Visual SourceSafe можно также использовать со многими другими средами разработки, включая (но не ограничиваясь) СУБД Microsoft Visual FoxPro и Microsoft Office.
Visual SourceSafe и Visual Basic
Если Вы ведете проект Visual Basic средствами Visual SourceSafe, можете выполнять входную и выходную маркировку форм непосредственно из интегрированной среды разработки Visual Basic (рис. 13.9).
Рис. 13.9 Работа с Visual SourceSafe из интегрированной среды Visual Basic
Не выходя из Visual Basic, Вы можете:
маркировать файлы;
просматривать историю файлов;
совместно использовать файлы;
добавлять файлы;
создавать новые проекты;
получать последние версии файлов;
отменять выходную маркировку.
Кроме того, если Вы выполняете выходную маркировку .frm-файла, то связанный с ним .frx-файл будет извлечен автоматически. В файле с расширением .frm хранится текстовая информацию формы, а в файле с расширением .frx — ее двоичные данные.
Использование Visual SourceSafe
В этом упражнении Вы создадите проект и будете управлять его файлами средствами Visual SourceSafe.
> Создание проекта Visual Source Safe
В меню File Visual SourceSafe Explorer выберите пункт Create Project. Откроется диалоговое окно Create Project.
Введите имя проекта и комментарий, содержащий детальное описание причин создания проекта и предполагаемых действий с ним. Комментарии, вводимые в этом диалоговом окне, являются частью истории проекта, их можно просматривать и редактировать в других диалоговых окнах, например в History of File или History of Project.
Нажмите ОК.
> Добавление файлов в проект Visual SourceSafe
В меню File выберите пункт Add Files. Откроется диалоговое окно Add File.
Щелкните стрелку списка Drives и выберите диск, если это необходимо.
В области Folders укажите папку.
В списке File Name выберите файл.
Нажмите Add.
Visual SourceSafe откроет еще одно диалоговое окно Add File.
Установите флажок Apply Same Comment For All, чтобы использовать один и тот же комментарий для всех файлов, добавляемых в данный проект.
После того как Вы нажмете ОК, добавленные Вами файлы исчезнут из области File Name — они уже стали частью проекта.
Нажмите ОК.
Концептуальная стадия
Проектирование здания начинается с набросков архитектора, которые позволяют клиенту познакомиться с внешним видом будущего здания. Они должны включать план территории, подъемы, планы этажей, вид здания в разрезе и т. д. Это концептуальная стадия проекта (рис. 13.5). На этой стадии выявляются реальные пожелания пользователей, которые и воплощаются в набор моделей.
Логическая стадия
За набросками архитектор создает архитектурные планы, в которых отражает свое видение требований заказчика. На этой, второй, стадии архитектурного процесса совмещаются пожелания клиента с точкой зрения и знаниями архитектора. Подробные чертежи помогают подрядчикам и другим исполнителям реализовать проект. В модели разработки решений это логическая стадия (см. рис. 13.5), где определяется структура и взаимодействие отдельных элементов системы.
Логистика
Логистика помогает продумать все трудности, которые могут возникнуть при реализации какого-либо процесса. В результате развертывание и установка продукта проходит «без сучка, без задоринки», а переход рабочих групп и групп поддержки к работе с новым продуктом выполняется безболезненно.
Методики разработки и управления проектами
Глава 13. Методики разработки и управления проектами
Прежде всего
Для изучения занятий этой главы необходимы:
Microsoft Visual SourceSafe;
звуковая карта и колонки или наушники для прослушивания мультимедиа-файлов;
следующие мультимедиа-файлы с компакт-диска:
Chap13a.exe;
Chap13b.exe.
Занятие 1. Microsoft Solutions Framework
Занятие 2. Управление исходными текстами средствами Visual SourceSafe
Закрепление материала
Методы оценки
На стадии планирования определяются методы оценки расходов и доходов от инвестиций (Return of Investments, ROI) и проверки оценок. Полную стоимость вычисляют по среднеотраслевым затратам. Базовые оценки основаны на фактической стоимости приобретения, использования и списания используемых информационных технологий.
Модель «Архитектура предприятия»
Эта модель предоставляет согласованный набор рекомендаций по планированию, построению и управлению технологической инфраструктурой для четырех уровней: делового, прикладного, информационного и технологического. Оценка архитектуры с этих точек зрения позволит Вам выработать оптимальную стратегию развития предприятия.
Планировать архитектуру предприятия следует постоянно, по мере изменения требований бизнеса. Этот подход, часто называемый «планированием во время строительства» (planning while building), основан на таких принципах MSF, как планирование с учетом рисков, установка на фиксированную дату выпуска, планирование деятельности, конкретизация этапов и разбивка на небольшие группы. В отличие от планирования «сверху вниз», модель архитектуры предприятия не только управляет проектами, но и сама видоизменяется по мере разработки проектов (рис. 13.4).
Рис. 13.4 Уровни модели архитектуры предприятия
Бизнес-архитектура
Бизнес-архитектура описывает деятельность Вашего предприятия. Она определяет функции и операции, выполняемые компанией. При этом выявляются возможности для увеличения дохода, снижения расходов или усиления роли новаций при использования технологии. Архитектура бизнеса помогает выработать четкое представление о каждом проекте и требования к нему. Вот основные вопросы, решаемые на этой стадии.
К какой отрасли относится Ваше предприятие?
Какие службы и ресурсы Вам необходимы?
Каковы сильные стороны Вашего бизнеса?
Влиянию каких факторов подвержен Ваш бизнес?
Расширяется или сужается Ваш рынок?
Какой будет Ваша отрасль через пять лет?
Каков диапазон Ваших прибылей?
Позволяют ли основные бизнес-процессы удовлетворить нужды потребителей?
Могут ли инновации позитивно сказаться на обороте средств, доходах или расходах?
Модель «Группа»
Эта модель позволяет отслеживать состояние проекта, обеспечивает разделение обязанностей и распределение ответственности за выполнение составных задач проекта. Основные объекты ее внимания в сложных программных проектах — персонал, компетентность, управление, ответственность и качество. В частности, она помогает определить, как подбирать группы разработчиков для создания решений с хорошим соотношением цены и качества.
Модель «Группа» описывает взаимодействие равноправных сотрудников, для каждого из которых четко определена задача. Такой подход стимулирует личную ответственность и, в конечном счете, позволяет создать высококачественный продукт. Лидеры каждой группы отвечают за менеджмент, руководство и координацию составных частей проекта, в то время как рядовые члены группы заняты выполнением возложенных на них конкретных задач.
Важнейшая составляющая успешной работы группы — возможность неограниченного общения ее членов.
Модель состоит из шести компонентов (рис. 13.1).
Рис. 13.1 Компоненты модели «Группа»
Модель «Инфраструктура»
Она позволяет разработать инфраструктуру информационных технологий на основе моделей процесса и группы. В частности, на базе этой модели выработаны принципы управления персоналом, процессами и технологиями поддержки крупных корпоративных сетей.
Модель позволяет обеспечить построение инфраструктуры для следующих стадий модели процесса:
формирования представления;
планирования;
разработки;
стабилизации.
Проект, реализация которого занимает больше года, может потерять актуальность из-за появления новых технологий. В глобальных же проектах иногда нет смысла использовать конкретную версию какой-либо технологии. Как только одна стадия реализации близка к завершению, следующая уже должна находиться на стадии планирования. Чтобы добиться этого, группам потребителей и разработчикам проекта необходимо определить приоритеты и компромиссы по трем параметрам: графику работ, функциональным возможностям и ресурсам.
Как этого добиться? Основные компоненты, определенные в рамках модели группы, остаются в силе, также взаимосвязаны и по-прежнему взаимодействуют между собой. Но, чтобы сделать эту модель пригодной для развертывания инфраструктуры, мы расширили область ответственности некоторых компонентов модели группы и добавили три новые области логистики (рис. 13.6):
управление системой — учитывает работающие системы и технологии;
справочная служба — предоставляет оперативную поддержку пользователям;
коммуникации — поддерживает коммуникации всех видов, включая обмен данными.
Рис. 13.6 Модель инфраструктуры
В результате применения модели инфраструктуры возможен более гибкий подход к развертыванию технологий, минимизирующий риск при капиталовложениях в новую технологию и максимально увеличивающий отдачу от ее развертывания.
Модель «Приложение»
Модель приложения описывает разработку многоуровневых приложений, объединяющих пользовательские сервисы с бизнес-сервисами и сервисами данных. Эта модель позволяет выработать определения, правила и отношения, составляющие структуру приложения. Она также позволяет рассматривать его как совокупность сервисов, что обеспечивает распределенную работу приложения и возможность повторного использования его функций и компонентов.
Сервис в этом контексте представляет собой логический модуль приложения, выполняющий какую-либо операцию, функцию или преобразование объекта. Сервисы гарантируют соблюдение бизнес-правил, выполнение вычислений или изменение данных, а также ввод, сбор, просмотр и изменение информации.
Модель «Процесс»
Используя ее, Вы получите рекомендации по планированию и управлению ориентированными на результат проектами на основе анализа их трудоемкости, имеющихся ресурсов и графика работ. Эта итеративная и адаптируемая модель помогает:
определить основные этапы разработки;
создать критерии и средства оценки работы групп;
учесть критические особенности проекта на ранних стадиях планирования;
оценить факторы и приоритеты, влияющие на график работ, функциональные возможности продукта и компромиссы.
В результате повышается качество принимаемых решений, уменьшается необходимость переделки, улучшается отношение работников к делу, а значит, в конечном счете улучшается качество продукта. Кроме того, учет проблем сопровождения и производительности на стадии разработки позволяет снизить как затраты на развертывание новых решений, так и общую стоимость владения.
Модель «Процесс» состоит из четырех стадий: формирования представления, планирования, разработки и стабилизации (рис. 13.2). Каждая стадия завершается конкретным результатом.
Рис. 13.2 Четыре стадии модели «Процесс»
Модель разработки решений
Это пошаговая стратегия разработки решений для конкретных потребностей бизнеса. Она объединяет модели приложения, группы и процесса и позволяет подразделениям информационных систем сконцентрировать ресурсы там, где отдача будет максимальной.
Эта модель координирует разработку решений с потребностями бизнеса двумя способами.
Параметры решений определяются конкретикой бизнеса, что особенно важно при создании приложений документооборота.
Способность решений удовлетворять запросы бизнеса проверяется конечными пользователями. Сотрудники подразделения информационных систем помогают пользователям решать их проблемы, не изменяя инфраструктуру.
Модели приложения, группы и процесса помогают предварительно определить все технические и бизнес-требования к приложению, что позволяет эффективнее распределять ресурсы. Объединив эти модели, Вы увидите сходство процессов разработки программного обеспечения с проектированием архитектурных сооружении. Именно поэтому компания Microsoft называет экспертов по разработке программного обеспечения архитекторами.
Модели приложения, группы и процесса следует рассматривать как составляющие методологии, которая позволяет воспользоваться определенным набором методов и инструментальных средств для удовлетворения нужд конкретных потребителей. Они детально описывают процесс разработки и позволяют пересмотреть его на любой стадии. Помните, что разработка — это непрерывный процесс последовательных улучшений.
Рис. 13.5 Три стадии модели разработки решений
Модель совокупной стоимости владения
Модель совокупной стоимости владения (Total Cost of Ownership, TCO) позволяет уменьшить затраты и увеличить отдачу от вложений в информационные технологии. Вот некоторые аспекты проблемы стоимости владения, рассматриваемые в рамках этой модели.
Роль стоимости. Вы можете снизить совокупную стоимость владения до нуля, избавившись от всех компьютеров Вашей организации, однако при этом Вы потеряете и все преимущества от их использования. Эта абсурдная ситуация иллюстрирует два ключевых момента: во-первых, оптимизация стоимости владения должна учитывать эффект от применения информационных технологий; во-вторых, задача заключается не в минимизации совокупной стоимости владения, а в оптимизации затрат на информационные технологии и отдачи от них.
Какова реальная стоимость? В компьютерной индустрии существует множество моделей расчета совокупной стоимости владения, оценивающих годовые расходы на содержание одного персонального компьютера суммами от $3 200 до $13 000. Такой разброс вызван тем, что даже эксперты не могут прийти к соглашению о том, какие именно затраты должна учитывать модель совокупной стоимости владения. Достаточно полная модель компании Microsoft позволяет организациям понять реальную стоимость владения и использования каждого компонента информационных технологий.
Применение ТСО для Ваших нужд. Некоторые модели ТСО учитывают все затраты на обеспечение деятельности конечных пользователей, часто без их конкретизации. Такой подход усложняет точную оценку затрат и уменьшает эффект от применения ТСО.
Обзор картины в целом. Иногда ТСО рассматривают только как стоимость приобретения, не учитывая расходы на сети, затраты на разработку и т.д., что не позволяет получить полную оценку.
Модель ТСО — это динамический процесс уточнения стоимости, учитывающий три ключевых момента: методы оценки, вычисление стоимости и ее проверку. Этот подход полезен при выработке планов и приоритетов в проектах развития инфраструктуры.
Обучение пользователей
Обучение (например, средствами обучающих систем) позволяет повысить эффективность использования продукта, а также снижает затраты на его сопровождение.
Все члены группы ответственны за качество продукта. Таким образом, вопросы, связанные с качеством, решаются до реализации продукта, тем самым исключается стадия исправления недостатков, а значит, снижаются затраты на сопровождение и уменьшается стоимость поддержки во время миграции. Хотя модель группы разрабатывалась на основе опыта создания программного обеспечения, эти правила успешно применяются и к проектам развертывания инфраструктуры.
Оценка продукта
Эта стадия помогает выработать представления о продукте или службе, собрать и классифицировать требования потребителей, оценить бизнес-ситуацию и отследить ожидания потребителей.
Планирование
С точки зрения Microsoft, планирование — это процесс согласования требований потребителей и группы проекта, касающихся конечного продукта и направления разработки продукта. Это важный метод прогнозирования рисков, выработки приоритетов и оценки графика работ и необходимых ресурсов.
Стадия планирования завершается одобрением плана проекта, который включает функциональную спецификацию — комбинированные планы для каждого члена группы в соответствие с требованиями модели «Группа» — и график работ. Функциональная спецификация необходимо достаточно детализировать, чтобы позволить группе проекта определить потребности в ресурсах и ее обязательства.
Пользовательские сервисы
Это логические модули интерфейса приложения. Пользователем приложения может выступать человек или другое приложение, поэтому интерфейс в этом контексте бывает как графическим пользовательским, так и программным.
Просмотр изменений в файлах в VSS Explorer
В этом упражнении Вы с помощью Visual SourceSafe ознакомитесь с изменениями, внесенными в различные версии одного и того же файла. > Внесение изменении в код Visual Basic
Открыв проект NASA в Visual Basic, раскройте окно кода для события Form_Load формы frmPhotos.frm.
Пометьте выходной маркировкой файл frmPhotos.frm.
Если Вы попытаетесь отредактировать его, не пометив выходной маркировкой, Visual Basic выдаст сообщение «Can't edit module» (Редактирование модуля запрещено).
В событии Form_Load отметьте все закомментированные строки кода и нажмите кнопку Uncomment Block.
Кнопка Uncomment Block расположена на панели инструментов Edit. Если эта панель инструментов скрыта, в меню View, Toolbars установите флажок Edit.
Сохраните проект.
Пометьте файл frmPhotos.frm входной маркировкой в Visual SourceSafe.
> Просмотр изменений в Visual SourceSafe Explorer
В дереве проектов All projects Visual SourceSafe Explorer выберите проект NASA.
В окне Contents выберите frmPhotos.frm и щелкните кнопку Show History, рас положенную на панели инструментов.
В диалоговом окне History of отметьте обе версии файла и нажмите кнопку Diff.
Появится диалоговое окно, показывающее различия между двумя версиями.
Закройте Visual SourceSafe и Visual Basic, сохранив изменения.
Проверка оценки
На этой стадии полученные результаты сопоставляются с поставленными задачами, что позволяет принять или отвергнуть выбранную стратегию оптимизации ТСО. В оптимизацию включены следующие элементы модели стоимости владения:
аппаратное и программное обеспечение — обеспечение рабочих станций и серверов, маршрутизаторы и мосты (включая стоимость модернизации);
поддержка — сопровождение, устранение неисправностей, справочное бюро, администрирование и обучение;
разработка — создание кода и информационного наполнения;
управление — сетями, системами и данными;
затраты на конечных пользователей — централизованное обучение конечных пользователей, поддержка коллег и просто эксперименты с компьютером;
нерабочее время/другое — запланированные и вынужденные перерывы в работе, создание программного обеспечения и тестирование;
телекоммуникационные затраты — выделенные линии и другие расходы на средства связи.
Рис. 13.7 Составляющие элементы модели стоимости владения
Большую часть средств организации тратят не на приобретение оборудования или программного обеспечения, а на разработку и поддержку информационно-технологической инфраструктуры. Их оптимизация требует наилучшего использования технологий, квалифицированного и опытного персонала.
Например, часто компании не полностью применяют возможности системных политик, сценариев регистрации и профилей пользователя. Чтобы получить максимальную отдачу, необходимо обучить персонал. Желательно также хорошенько продумать процедуры управления активами, стандартизовать рабочую среду и обеспечить обучение пользователей.
Стратегия оптимизации стоимости владения включает оценку и повышение эффективности персонала, процессов и технологии предприятия. Процессы в рамках инфраструктуры информационных технологий (сетевые операции, управление данными и сетями, администрирование и поддержка пользователей) должны быть настолько эффективными, насколько это возможно. С другой стороны, необходимо стремиться к максимальной самодостаточности конечных пользователей — чем меньше им придется обращаться за поддержкой к персоналу информационных подразделений, тем эффективнее они будут работать.
Разработка
Разработка — это создание или реализация продукта (службы), отвечающего техническому заданию, требованиям потребителей и функциональной спецификации.
Стадия разработки завершается реализации возможностей продукта или службы и проверкой их на практике. Когда функциональная спецификация и связанный с ней план проекта одобрены, можно начинать целенаправленную разработку. Группа разработки определяет промежуточные этапы выпуска продукта, каждый из которых включает полный цикл тестирования, отладки и внесения исправлений.
На этом этапе потребители и группа разработки оценивают функциональные возможности продукта и проверяют оптимальность планов развертывания и поддержки. Разработка в целом завершается, а все нереализованные возможности документируются для включения в следующие версии.
это гибкий набор взаимосвязанных моделей,
Методология разработки решений Microsoft (Microsoft Solutions Framework, MSF) — это гибкий набор взаимосвязанных моделей, позволяющих организации подобрать ресурсы, персонал и методы, необходимые для обеспечения соответствия технологической инфраструктуры и принимаемых решений ее целям. Краткое описание каждой модели приведено в таблице.
| Модель | Описание |
| Группа | Отслеживается состояние проекта, обеспечивается разделение обязанностей и распределение ответственности за выполнение задач. Модель состоит из шести четко определенных компонентов: выработки программы, управления продуктом, разработки, тестирования, логистики и обучения пользователей |
| Процесс | Выработка рекомендаций по планированию и управлению ориентированными на результат проектами на основе анализа их трудоемкости, имеющихся ресурсов и графика работ. Основные этапы — формирование представления о продукте, планирование, разработка и стабилизация |
| Приложение | Создание многоуровневых приложений, объединяющих пользовательские сервисы с бизнес-сервисами и сервисами данных |
| Архитектура предприятия | Выработка согласованного набора рекомендаций по планированию, построению и управлению технологической инфраструктурой для четырех уровней: делового, прикладного, информационного и технологического. Оценка архитектуры с этих точек зрения позволит Вам выработать оптимальную стратегию развития предприятия |
| Разработка решений | Пошаговая стратегия разработки бизнес-ориентированных решений для конкретных потребностей бизнеса. В основе модели лежат три стадии: концептуальная, логическая и физическая |
| Инфраструктура | Устанавливает принципы управления персоналом, процессами и технологией поддержки крупных корпоративных сетей. Модель основана на компонентах, определенных в модели «Группа», однако роль логистики при развертывании инфраструктуры возрастает |
| Совокупная стоимость владения | Помогает уменьшить затраты и увеличить отдачу от вложений в информационные технологии |
Инструментальное средство управления исходными текстами
Инструментальное средство управления исходными текстами и контроля версий Microsoft Visual SourceSafe повышает эффективность разработки программного обеспечения. VSS включает простые и удобные средства проектно-ориентирован-ного контроля версий, работает с любыми типами файлов, независимо от использованных для их создания языков программирования или инструментальных средств разработки, обеспечивает повторное использование компонентов как на уровне файлов, так и на уровне проекта, а также поддерживает коллективную разработку с помощью проектно-ориентированных средств, предназначенных для повышения эффективности решения повседневных задач коллективной разработки программного обеспечения.
Visual SourceSafe позволяет выполнять входную и выходную маркировки файлов, а также сохраняет все изменения, внесенные в файл. Помимо последней версии файла, всегда доступны и все предыдущие. VSS интегрируется со всеми средствами разработки и приложениями Microsoft, включая Microsoft Visual Studio, Visual Basic, Visual C++, Visual J++, Word, Excel, Access, FoxPro и Frontpage.
Сервисы данных
Это логические модули приложения, ответственные за предоставление необходимого уровня абстракции для манипулирования информацией. Сервисы данных обеспечивают доступность и целостность постоянных и временных данных как активов компании. Они отвечают за создание, чтение, модификацию и удаление данных, избавляя бизнес-сервисы — клиенты сервисов данных — от заботы о физическом местонахождении, организации и интерфейсе данных.
Эти сервисы обычно используют при разработке многоуровневых приложений, но особенно они полезны при интеграции бизнес-систем с Интернет-техно-логиями. В частности, это позволяет:
обеспечить кросс-платформенную поддержку приложения в гетерогенной среде;
поддерживать единый пользовательский интерфейс и навигационную модель во всех бизнес-приложениях;
обеспечить поддержку присутствия в Интернете;
упростить развертывание при централизованном управлении логикой приложений на серверах Интернета.
Совместное использование файлов в Visual SourceSafe
В этом упражнении Вы попробуете воспользоваться формой Visual Basic в нескольких проектах.
Примечание Прежде чем приступать к этому упражнению, необходимо выполнить предыдущее упражнение («Использование Visual SourceSafe»).
> Создание нового проекта Visual SourceSafe
В Visual SourceSafe Explorer выберите корневой проект $/ дерева All projects.
На панели инструментов нажмите кнопку Create Project.
В поле Project диалога Create Project введите Shared Objects и нажмите ОК.
В дереве All projects выберите Shared Objects.
На панели инструментов нажмите кнопку Create Project.
В поле Project диалога Create Project введите Login и нажмите ОК.
В дереве All projects выберите Login.
На панели инструментов нажмите кнопку Add Files.
Ознакомьтесь с содержимым папки WA\Practice\Chl3\Shared\Login.
Выберите все файлы из списка и нажмите Add.
Не заполняя поле комментария, нажмите ОК.
Нажмите Yes, чтобы сделать папку WA\Practice\Chl3\Shared\Login Вашей лич ной рабочей папкой.
Нажмите Close для возврата в окно Visual SourceSafe Explorer.
> Совместное использование формы Login с другими проектами Visual SourceSafe
В дереве All projects выберите пункт Hubble.
На панели инструментов нажмите кнопку Share. Будет открыт диалог Share with $/Hubble.
В списке Projects дважды щелкните Shared Projects и выберите Login.
В списке File to share выберите frmLogin.frm и нажмите Share.
Нажмите Close для возврата в окно Visual SourceSafe Explorer.
Заметьте, что форма frmLogin.frm добавлена в список Contents проекта Hub ble. Ее значок отличается от остальных, это демонстрирует, что файл исполь зуется совместно с другими проектами Visual SourceSafe. Файл frmLogin.frm также скопирован в рабочий каталог проекта Hubble.
Повторите пункты 1—5, чтобы обеспечить совместное использование формы frmLogin с еще одним проектом — NASA.
> Добавление формы Login в проекты Hubble и NASA
В Visual Basic откройте проект Hubble.
Выберите в меню Project пункт Add Form.
Щелкните вкладку Existing и выберите frmLogin.frm, затем нажмите Open.
Если Вы получили сообщение «Project file is read-only» (Файл проекта предназ начен только для чтения), закройте окно сообщения и выполните выходную маркировку проекта в Visual SourceSafe.
Теперь Вы сможете добавить форму Login в проект. Так как файл Hubble.vbp содержит информацию о том, какие файлы составляют Ваш проект. Visual Basic не позволит добавить в проект какие-либо файлы до тех пор, пока не будет выполнена выходная маркировка файла проекта (.vbp-файла). При необходимости повторите пункт 3.
Нажмите OK в окне сообщения, информирующего, что Visual Basic не смог добавить эту форму в проект Visual SourceSafe.
Это сообщение появляется потому, что данный файл уже был добавлен в Visual SourceSafe.
В Project Explorer щелкните правой кнопкой мыши frmLogin и выберите пункт Check Out.
Повторите пункт 5, чтобы занести файл формы frmLogin в Visual SourceSafe. Когда Вы сначала выполняете выходную маркировку файла, а затем входную, Visual Basic заменяет значок этого файла в окне Project Explorer. Это происходит потому, что данная форма используется совместно с другими проектами.
Сохраните проект.
Повторите пункты 1—7 для проекта NASA.
> Входная и выходная маркировка файлов в Visual SourceSafe
Оставив проект NASA открытым, в окне Project Explorer щелкните правой кнопкой форму frmLogin.frm и выберите пункт Check Out.
Переключившись в окно Visual SourceSafe Explorer, обратите внимание, что файл помечен выходной маркировкой во всех трех добавленных нами проектах. Если в Visual SourceSafe Explorer файлы не помечены выходной маркировкой, выберите пункт Refresh File List в меню View.
Переключитесь в Visual Basic и пометьте входной маркировкой форму frmLogin.frm.
Стабилизация
На этой стадии акцент переносится с разработки решения на проверку его работоспособности в реальных условиях и тщательное полномасштабное тестирование.
Стадия стабилизации завершается выпуском продукта. Тестирование не должно прерываться даже при переработке кода продукта. На стадии стабилизации главная точка приложения усилий — поиск и исправление ошибок. По окончании ее продукт передается группам развертывания и сопровождения. Группе проекта поручают создание следующей версией либо ее сотрудников подключают к работе над другими проектам.
Технологическая архитектура
Технологическая архитектура детально описывает стандарты и рекомендации по приобретению и развертыванию рабочих станций и клиентского ПО, компонентов приложений, служб инфраструктуры, компонентов сетевого обеспечения и платформ. Приобретение — это решения по закупке и самостоятельной разработке, а развертывание — создание технологических схем, призванных содействовать развитию инфраструктуры. Вот основные вопросы, решаемые на этой стадии. Какой уровень технологического риска приемлем?
Развертываете ли Вы стандартные технологии или же приобретаете специализированные решения?
Понимаете ли Вы, как, где и какая именно технология развертывается в Вашей организации?
Отвечает ли Ваша технологическая инфраструктура целям и задачам Вашего бизнеса?
Какие основные технологические тенденции влияют на Ваши операции с информационными технологиями?
Знаете ли Вы, какой уровень подготовки персонала нужен Вам сегодня и потребуется в будущем?
Тестирование
Оно позволяет обнаружить все проблемы до выпуска продукта или службы, Тестируют, как правило, пользовательский интерфейс и API, а также обязательно проверяют совместимость нового программного обеспечения с существующими системами.
Три категории сервисов
Чтобы добиться максимальной распределенности сервисов, модель «Приложение» подразделяет их натри категории: пользовательские, бизнес-сервисы и сервисы данных (рис. 13.3).
Рис. 13.3 Три категории сервисов модели «Приложение»
Управление исходными текстами средствами Visual SourceSafe
Visual SourceSafe поддерживает файлы любых типов — как текстовые, так и двоичные. Visual SourceSafe работает с обоими форматами, но из-за структуры двоичных файлов некоторые операции, например сравнение содержимого двух двоичных файлов, невыполнимы. Способность работать с файлами любых типов делает SourceSafe легко адаптируемым средством для контроля исходных текстов, управления документами и Web-узлами и любых других операций, связанных с организацией набора файлов и управления ими.
Входная и выходная маркировка файлов
Средства разработки Microsoft и Visual SourceSafe Explorer позволяют маркировать файлы, поступающие в базу данных или извлекаемые из нее (рис. 13.8).
А теперь запустите видеоролик Chapl3b.exe с прилагаемого к книге компакт-диска. Он познакомит Вас с тем, как VSS управляет файлами, чтобы предотвратить одновременное изменение файла несколькими пользователями.
Команда Get по умолчанию извлекает файл или набор файлов из Вашей базы данных Visual SourceSafe и помещает их копии (предназначенные только для чтения) на Ваш локальный компьютер. Вы не сможете ни модифицировать их на локальном компьютере, ни занести их обратно в БД Visual SourceSafe.
Команда Check Out маркирует файл или набор файлов базы данных, тем самым обеспечивая Вас полноценными копиями, которые Вы сможете изменять и сохранять.
Рис. 13.8 Управление файлами в Visual SourceSafe
Закончив редактировать файл, маркируйте его в Visual SourceSafe командой Check In. Она скопирует измененный файл из Вашей папки в базу данных Visual SourceSafe. В результате доступ к сделанным Вами изменениям получат остальные члены коллектива. Однако Visual SourceSafe хранит все изменения, которые когда-либо вносились в файл — последняя версия доступна всегда, но при необходимости можно получить и все предыдущие. Обратная дельта-технология, используемая Visual SourceSafe, обеспечивает доступность всех версий файла при минимальном использовании дискового пространства.
Вычисление стоимости
На стадии построения оценки доходность инвестиций вычисляется путем моделирования эффекта от рекомендуемых проектов и экономии средств на основании конкретной стратегии перехода или развертывания.
Выработка программы
Программа позволяет подготовить и принять решения, необходимые для создания нужного продукта или службы за установленное время, а также учесть необходимость соответствия продукта стандартам и правилам организации в вопросах совместимости.
Microsoft Solutions Framework
Занятие 1. Microsoft Solutions Framework
(Продолжительность занятия 45 минут)
Методология разработки решений Microsoft (Microsoft Solutions Framework, MSF) — это набор взаимосвязанных моделей, позволяющих подобрать необходимые ресурсы, персонал и методы. Эти модели помогают надлежащим образом организовать все стадии — планирования, создания и управления, составляющие разработку и реализацию программного обеспечения.
Для решения задач стадии планирования предназначена модель архитектуры предприятия. Модели группы, процесса, приложения и управления рисками и модернизацией облегчают разработку приложений. Для управления MSF предлагает модели инфраструктуры, операций и совокупной стоимости владения. Это занятие посвящено моделям, составляющим Microsoft-Solutions Framework.
Изучив материал этого занятия, Вы сможете:
перечислить, какие проблемы, возникающие при разработке программного обеспечения для Вашей организации, поможет решить Microsoft Solutions Framework;
описать шесть составляющих модели группы;
идентифицировать четыре стадии модели процесса и описать основные этапы каждой из них;
дать определение сервиса и описать три категории сервисов модели приложения;
перечислить основные вопросы, решаемые на каждой из стадий модели архитектуры предприятия;
описать три составляющие модели разработки решений;
описать применение модели группы для процессов реализации инфраструктуры.
Использование MSF
MSF реализуют отдельно или в сочетании с другими инструментальными средствами и методами. Это динамическая база знаний, которая развивается на основе новой информации, поступающей от клиентов и партнеров Microsoft, и новых технологических разработок. MSF помогает организациям:
эффективно модернизировать существующие архитектуры технологий, приложений и данных с минимальными потерями;
разработать методики создания эффективных проектных групп и управлять выполнением проекта;
определить стратегии создания и реализации бизнес-решений;
управлять реализацией и работой технологических решений.
MSF также позволяет планировать, создавать и управлять распределенной технологической инфраструктурой, а также выявлять критические участки, допуски планирования и ключевые взаимозависимости, которые необходимо учитывать для успешной реализации технологических решений. MSF поможет ответить на следующие вопросы.
Как управлять вычислительными ресурсами?
Как ускорить разработку, уменьшить затраты на сопровождение и добиться многократного использования технологий?
Как учесть изменение пользовательских или бизнес-требований, не разрабатывая всю систему заново?
Модели в составе MSF
А теперь запустите видеоролик Chapl3a.exe с прилагаемого к книге компакт-диска. Он подробнее познакомит Вас со всеми моделями в составе MSF.
Каждая модель MSF играет свою роль при разработке программного обеспечения. MSF позволяет четко выделить отношения между бизнес-целями компании и технологическими решениями. Все модели MSF взаимосвязаны — например, модель группы служит для анализа задач проектирования, а модель процесса поддерживает принятие решений.
Модели MSF и их назначение перечислены в таблице.
| Модель | Описание |
| Группа | Модель группы сотрудников, работающих над проектом |
| Процесс | Помогает группе определить методы планирования и контроля проектов, учитывая трудоемкость, имеющиеся ресурсы и график работ |
| Приложение | Помогает группе разработать распределенные приложения, обеспечивающие оптимальное повторное использование компонентов. Модели группы и процесса формируют ядро методологии MSF в области разработки и управления инфраструктурой проекта |
| Архитектура предприятия | Ключ к успешному долгосрочному использованию новых технологий. Это модель принятия решений, связанных с информацией, приложениями и технологиями, необходимыми для поддержки бизнеса |
| Разработка решении | Позволяет найти компромиссный вариант, учитывающий бизнес-цели и идеальную схему разработки, предлагаемую моделью «Приложение» |
| Инфраструктура | Формирует принципы управления персоналом, процессами и технологией поддержки сетей в рамках крупного предприятия |
| Совокупная стоимость владения | Процесс оценки и управления стоимостью информационных технологий и максимизации их отдачи |
Управление исходными текстами средствами Visual SourceSafe
Занятие 2. Управление исходными текстами средствами Visual SourceSafe
(Продолжительность занятия 30 минут)
Контроль версий — важнейший аспект коллективной разработки программного обеспечения и Web-узлов, так как он препятствует случайной утрате исходного кода, обеспечивает доступ к предыдущим версиям продукта, а также поддерживает управление версиями кода. При контроле версий в файл можно внести изменения, сохранить его и, при необходимости, вернуться позднее к одной из предыдущих версий. Microsoft Visual SourceSafe — это инструментальное средство управления исходными текстами и контроля версий, позволяющее эффективно управлять разработкой программного обеспечения коллективом любого размера. Вы можете интегрировать Visual SourceSafe в любой из инструментов разработки Microsoft или воспользоваться Visual SourceSafe Explorer для управления своими файлами. На этом занятии Вы узнаете, как Visual SourceSafe управляет файлами и как он интегрируется с другими средствами разработки производства компании Microsoft.
Изучив материал этого занятия, Вы сможете:
рассказать, как можно использовать Microsoft Visual SourceSafe для управления исходными текстами проекта;
создать проект Visual SourceSafe;
просмотреть изменения в файлах средствами Visual SourceSafe Explorer;
объяснить, как Visual SourceSafe интегрируется со средствами разработки компании Microsoft.
Visual Source Safe обладает следующими характеристиками:
полностью интегрируется со многими средствами разработки компании Microsoft;
обеспечивает простой в использовании проектно-ориентированный контроль версий;
работает с файлами любых типов;
обеспечивает повторное использование компонентов как на уровне файлов, так и на уровне проекта;
поддерживает коллективную разработку с помощью проектно-ориентирован-ных средств, нацеленных на повышение эффективности решения повседневных задач, связанных с коллективной разработкой программного обеспечения.
