Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

Microsoft Solutions Framework (модель разработки приложений Microsoft) -- это набор концепций и рекомендуемых моделей, которые позволяют разрабатывать и внедрять информационные системы на основе технологий и инструментальных средств Microsoft. Многие концепции MSF хорошо известны. MSF является одной из интерпретаций спиральной (циклической) модели разработки приложений и базируется на практических результатах организации распределенных вычислений и применения технологий «клиент-сервер» компании Microsoft, ее партнеров и заказчиков.

Теоретическая часть

В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Майкрософт выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Майкрософт при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт и лучшем из того, что накопила на данный момент IT-индустрия. Все это представлено в виде двух взаимосвязанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).

MOF призван обеспечить организации, создающие критически важные (mission-critical) IT решения на базе продуктов и технологий Майкрософт, техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала и процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Central Computer and Telecommunications Agency -- Агентством правительства Великобритании.

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

MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей, а затем перейти к дисциплина

Основные компоненты и модели MSF

MSF содержит следующие модели:

* Team Model (Модель команды) -- описывает коллектив, в котором работа одного сотрудника зависит от другого;

* Proccess Model (Модель процесса) -- позволяет определить принципы планирования и контроля проектов;

* Application Model (Модель приложения) -- помогает создавать приложения, максимально используя готовые компоненты;

* Enterprise Architecture Model (Модель архитектуры корпорации) -- обеспечивает принятие решения по технологиям; она очень важна для эффективного использования новых технологий;

* Solution Desing Model (Модель проектирования решений) -- показывает, каким должно быть приложение с точки зрения пользователя. Эта модель связывает приложение, команду разработчиков и процесс разработки;

* Infrastructure Model (Модель управления инфраструктурой) -- определяет принципы управления пользователями в больших сетях;

* Total Cost of Ownership Model (Модель стоимости владения продуктом) -- позволяет оценивать расходы на информационные технологии.

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

* Solution Development Discipline (SDD) -- дисциплина разработки решений. Содержание этой дисциплины связано с уникальными моделями: моделью команды и моделью процесса, которые рекомендуется использовать для организации эффективных команд проектов и управления жизненным циклом проекта. SDD включает три фундаментальные модели MSF:

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

- сетевая трехслойная модель приложения -- описывает, какой должна быть структура приложения, удовлетворяющего современным требованиям;

* Designing Component Solutions (DCS) -- проектирование компонентного ПО. Эта дисциплина направлена на поддержку процесса проектирования сложных моделей распределенных вычислений;

* Enterprise Architecture Planning -- планирование архитектуры предприятия. С точки зрения Microsoft, это итеративный процесс, сосредоточенный на долгосрочном планировании, но при этом направленный на достижение результатов в максимально сжатые сроки;

* Infrastructure Deployment and Management -- управление технологической инфраструктурой. Эта дисциплина содержит подход к процессу внедрения в масштабах предприятия как новых информационных технологий, так и отдельных программных продуктов и приложений.

Процесс MSF

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

Цикл (виток спирали) разработки включает четыре фазы и завершается выпуском версии продукта. Каждая фаза представляет собой определенную последовательность действий и завершается вехой (milestone).

Первая фаза -- Анализ (Envisioning). На данном этапе формируется представление о продукте на данном витке спирали. Это гарантирует, что разрабатываемый продукт будет соответствовать как текущим, так и перспективным целям компании, а также поможет скорректировать направление развития компании. Данная стадия требует глубокого осмысления целей проекта. Формирование представления позволяет избежать, например, инвестирования в незначительные или неэффективные проекты. В результате этой стадии составляется представление о продукте, определяются его функциональные возможности и оцениваются результаты. Если новый продукт получает одобрение, то составляется группа разработки проекта, задача которой -- выработать концепцию продукта. На этом этапе фиксируются цели и определяется четкое направление разработки. Здесь же устанавливаются возможности конкретной версии продукта или службы и оцениваются тенденции развития продукта в следующих версиях. Вехой данной фазы является утверждение представления.

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

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

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

Контрольными точками процесса являются вехи (milestones). Работа команды ориентирована на достижение вех, что сопровождается появлением и фиксацией того или иного отчуждаемого материала (документа, программы, протокола и т.д.). Веха -- это время проведения инспекций (фазовых обзоров), на которых обсуждаются достигнутые результаты и принимаются решения. Перечисленные выше ключевые вехи являются внешними, то есть отчуждаемые материалы вехи согласуются с заказчиком. Очень важно, что каждая веха -- это точка синхронизации, в которой происходит взаимное согласование точек зрения исполнителей (команды проекта), заказчиков, пользователей. Следует отметить, что вехи MSF являются точками не «замораживания» проекта (когда одна группа передает результаты своей работы другой группе), а его синхронизации. Все изменения артефактов, полученных в процессе работы над проектом, строго контролируются. Они вносятся не произвольно, а только после согласования на внутренних обзорах. Таким образом обеспечивается возможность принятия решения максимально рано, а «замораживания» проекта -- максимально поздно.

Модель команды

Модель, рекомендуемая SDD, предусматривает, что для выполнения проектов необходимо организовать команду специалистов по шести направлениям (ролям):

* управление продуктом;

* управление программой;

* разработка;

* тестирование;

* обучение пользователей;

* сопровождение (логистика).

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

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

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

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

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

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

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

Распределение ответственности при фиксации отчетности

Наделяйте членов команды полномочиями

Концентрируйтесь на бизнес-приоритетах

Единое видение проекта

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

Поощряйте свободное общение

Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):

Команда соратников

Сфокусированность на нуждах заказчика

Нацеленность на конечный результат

Установка на отсутствие дефектов

Стремление к самосовершенствованию

Заинтересованные команды работают эффективно

Модель приложения

Модель приложения MSF основана на трех основных понятиях.

Многослойное (Multi-tier) приложение -- позволяет адекватным образом описать различные аспекты распределенных приложений. Модель приложения MSF выделяет три основных слоя:

* пользовательский интерфейс;

* бизнес-правила;

* управление данными.

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

* информационные службы;

* бизнес-службы;

* пользовательские службы.

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

Проектирование компонентного ПО

Процесс проектирования MSF состоит из трех стадий.

Первая стадия -- концептуальное проектирование -- это описание точки зрения пользователя на проект. На этом этапе происходит следующее:

* определение существа проблемы, подлежащей решению, установление цели разработки;

* идентификация основной деятельности: определяются границы области, которую покрывает разрабатываемое решение, причем как перспективные, так и реальные;

* классификация пользователей: группирование пользователей по категориям и описание требований и ожиданий каждой категории;

* составление сценариев «Как есть» и «Как должно быть». Сценарии являются основным выходом стадии концептуального проектирования;

* проверка, оценка и итеративное проектирование. Все стадии проектирования, во-первых, носят итеративный характер, а во-вторых, взаимно перекрываются.

Вторая стадия -- логическое проектирование -- это точка зрения группы проектировщиков на приложение. Логическое проектирование является ядром процесса разработки. Центральной задачей логического проектирования при использовании рекомендуемой MSF модели приложения является вычленение и спецификация служб. Результатом логического проектирования является логическая модель приложения, то есть на этой стадии должны быть спроектированы службы, а также специфицированы реализуемые ими функции и интерфейсы.

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

Управление рисками

Управление рисками (risk management) -- это одна из ключевых дисциплин Microsoft Solutions Framework® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF -- мы не боремся с рисками -- мы ими управляем.

рабочее приложение риск модель

Управление проектами

Проект (project) -- ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги. Управление проектами (project management) -- это область знаний, навыков, инструментария и приемов, используемых для достижения целей проектов в рамках согласованных параметров качества, бюджета, сроков и прочих ограничений.

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

Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS. Иерархическая структура работ (Work Breakdown Structure -- WBS) -- это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.

Заключение

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

Практика

Описание алгоритма решения задачи

1. Запустить СУБД access

2. Создать таблицу с названием ОС

Рис. 1. Структура данных таблицы ОС

3. Запустить табличный процессор MS Exсel.

4. Создать книгу с именем «Расчёт заработной платы».

5. Лист первый переименовать в РОСПИП.

6. Лист второй переименовать в РОСПДП.

7. На рабочем листе РОСПИП формируем таблицу «Реестр основных средств по источникам получения».

Рис. 2. Реестр основных средств по источнику получения

8. Редактируем тип данных в ячейках опираясь на таблицу ОС. Столбцам «Источник поступления» «Наименование основных средств» - задаём тип данных текстовый, столбцам «Первоначальная стоимость» «Номер акта ввода в эксплуатацию» - задаём тип данных числовой, столбцу «Дата ввода в эксплуатацию» - задаём тип данных дата.

Рис. 3. Задание типа ячейки

9. На рабочем листе РОСПДП формируем таблицу «Реестр основных средств по датам поступления».

Рис. 3. Реестр основных средств по датам поступления

10. Редактируем тип данных в ячейках опираясь на таблицу ОС. Столбцам «Источник поступления» «Наименование основных средств» - задаём тип данных текстовый, столбцам «Первоначальная стоимость» «Номер акта ввода в эксплуатацию» - задаём тип данных числовой, столбцу «Дата ввода в эксплуатацию» - задаём тип данных дата.

Рис. 4. Задание типа ячейки

11. Введём текущее значение даты между таблицей и её названием. Для этого в ячейках Е2 листа РОСПИТ и таблицы РОСПДП введём формулу =СЕГОДНЯ().

Рис. 5. Ввод значения даты

12. Переименуем лист 3 в «Основные средства».

13. На листе «Основные средства» создадим таблицу отображающую Основные средства.

Рис. 6. Основные средства

14. По данным таблицы «Основные средства» заполним таблицу «Реестр основных средств по источникам поступления». Для этого в ячейку А4 поместим формулу ='Основные средства'!B2. Заполним остальные ячейки аналогично.

Рис. 7. Заполненная таблица «Реестр основных средств по источникам поступления»

15. По данным таблицы «Основные средства» Заполним таблицу «Реестр основных средств по датам поступления» для этого будем использовать тот же приём что и с таблицей «Реестр основных средств по источникам поступления».

Рис. 8. Заполненная таблица «Реестр основных средств по датам поступления»

16. Построим гистограмму по таблице «Реестр основных средств по источникам поступления». Для этого выделим все столбцы с числовыми значениями, нажмём Вставка-диаграмма, в меню выберем Гистограмма. Зададим название осей и название диаграммы, подключим легенду.

Рис. 6. Гистограмма

Список используемой литературы:

1. https://msа.ru/Downloads//Materials/msf.htm_ -Что нового в Msf.

2. http://3dnow.com - Msf полезные приложения.

3. http://www.gings.ru/article16.htm - что такое Msf.

Размещено на Allbest.ru