Система управления проектами территориально-распределенной IT-компании

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

Итеративная модель

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

Рисунок 2.2 - Диаграмма разработки по итеративной модели

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

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

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

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

Итеративная разработка обладает рядом преимуществ по сравнению с последовательной моделью.

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

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

основные проектные риски могут (и должны) быть разрешены на первых итерациях. Например, архитектурное решение, приводящее к неприемлемой производительности может быть обнаружено и исправлено уже в первой итерации [18].

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

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

Rational Unified Process (RUP) - методология разработки программного обеспечения, созданная компанией Rational Software. Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее - Rational) для управления процессами разработки. Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.

В основе RUP лежат следующие принципы [19]:

ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков;

концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов(вариантов использования));

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

компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта;

постоянное обеспечение качества на всех этапах разработки проекта (продукта);

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

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

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

В фазе «Начало» формируются видение и границы проекта, создается экономическое обоснование (business case), определяются основные требования, ограничения и ключевая функциональность продукта, создается базовая версия модели прецедентов, оцениваются риски.

При завершении начальной фазы оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта [19].

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя документирование требований (включая детальное описание для большинства прецедентов), спроектированную, реализованную и оттестированную исполняемую архитектуру, обновленное экономическое обоснование и более точные оценки сроков и стоимости, сниженные основные риски.

Рисунок 2.3 - Графическое представление процесса разработки по RUP

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя документирование требований (включая детальное описание для большинства прецедентов), спроектированную, реализованную и оттестированную исполняемую архитектуру, обновленное экономическое обоснование и более точные оценки сроков и стоимости, сниженные основные риски.

Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone) [19].

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки [19].

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

Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников. При этом попытка обойтись своими силами, скорее всего, будет обречена на неудачу - необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов [18].

Гибкие методологии

В течение 1990-х годов все больше разработчиков ПО начинали искать альтернативу традиционным, как правило, основанным на модели водопада, процессам разработки. К 2000 году существовало уже целое множество так называемых легковесных (lightweight) методологий.

В 2001 году группа создателей и экспертов по различным легковесным методологиям провела семинар, на котором были сформулированы основные принципы гибкой разработки ПО (так называемый Agile Manifesto). На том же семинаре было предложено новое название легковесных методологий - гибкая разработка (agile software development).

Общими особенностями гибких методологий являются [18]:

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

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

итеративная разработка с возможно более короткой (в разумных пределах) продолжительностью итерации, при этом в результате каждой итерации выпускается полноценная работающая версия продукта;

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

Многие руководители проектов, работающие в традиционных методологиях вроде «водопада», критикуют agile-методы.

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

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

Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto [20]:

Agile Modeling - набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения. Не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель: эффективное моделирование и документирование; но не охватывает программирование и тестирование, не включает вопросы управления проектом, развёртывания и сопровождения системы. Однако включает в себя проверку модели кодом;

Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений;

Agile Data Method - группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд;

DSDM (основан на концепции быстрой разработки приложений Rapid Application Development, RAD) представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя;

Essential Unified Process (EssUP);

Экстремальное программирование (Extreme programming, XP);

Feature driven development (FDD) - функционально-ориентированная разработка; используемое в FDD понятие функции или свойства системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие -- это дополнительное ограничение: «каждая функция должна допускать реализацию не более чем за две недели»; то есть если сценарий использования достаточно мал, его можно считать функцией; если же велик, то его надо разбить на несколько относительно независимых функций;

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

Базовые технологии и средства разработки

Программное средство реализовано с использованием языка программирования C#, поддерживающего платформу Microsoft .Net Framework 4.0, в среде разработки Microsoft Visual Studio 2010 Express. Так же использовалась технология ASP.NET и интерфейс Membership API. Приложение имеет взаимодействие с базой данных, созданной в системе управления базами данных Microsoft SQL Server 2008.

Выбор языка программирования

В последнее время С и C++ становятся наиболее используемыми языками при разработке коммерческих и бизнес-приложений. Эти языки устраивают многих разработчиков, но в действительности не обеспечивают должной продуктивности разработки. К примеру, процесс написания приложения на C++ часто занимает гораздо больше времени, чем разработка эквивалентного приложения на Visual Basic. Сейчас существуют языки, увеличивающие продуктивность разработки за счет потери в гибкости, которая так привычна и необходима программистам на C/C++. Подобные решения весьма неудобны для разработчиков и нередко предлагают значительно меньшие возможности. Эти языки также не ориентированы на взаимодействие с появляющимися сегодня системами и очень часто не соответствуют существующей практике программирования для Web. Многие разработчики хотели бы использовать современный язык, который позволял бы писать, читать и сопровождать программы с простотой Visual Basic и в то же время давал мощь и гибкость C++, обеспечивал доступ ко всем функциональным возможностям системы, взаимодействовал с существующими программами и легко работал с возникающими Web-стандартами.

Учитывая все подобные пожелания, Microsoft разработала новый язык - С#. Он имеет массу преимуществ: простота, объектная ориентированность, типовая защищенность, «сборка мусора», поддержка совместимости версий и многое другое. Данные возможности позволяют быстро и легко разрабатывать приложения.

При создании С# его авторы учитывали достижения многих других языков программирования: C++, С, Java, Visual Basic и т.д. Необходимо заметить, что поскольку С# разрабатывался «с нуля», у его авторов была возможность не переносить в него все неудачные особенности любого из предшествующих языков. Особенно это касается проблемы совместимости с предыдущими версиями. В результате получился простой, удобный и современный язык, который по мощности не уступает C++, но существенно повышает продуктивность разработок [21].

Ввиду высокой объектной ориентированности, язык С# подходит для быстрого конструирования различных компонентов - от высокоуровневой бизнес-логики до системных приложений, использующих низкоуровневый код. Также следует отметить, что С# является и Web-ориентированным - с помощью простых встроенных конструкций языка существует возможность переводить созданные компоненты в Web-сервисы, к которым можно будет обращаться из сети Интернет, используя любой язык на любой операционной системе. Дополнительные возможности и преимущества С # перед другими языками приносит использование современных Web-технологий, таких как: XML (Extensible Markup Language) и SOAP (Simple Object Access Protocol). Удобные методы для разработки Web-приложений позволяют программистам, владеющим навыками объектно-ориентированного программирования, быстро освоиться в разработке Web-сервисов.

Выбор среды разработки

Интегрированные среды разработки, среды разработки (Integrated Development Environment - IDE) - система программных средств, используемая программистами для разработки программного обеспечения [22].

Интегрированные среды разработки обычно содержат:

текстовый редактор, предназначенный для ввода и корректировки текста программы;

компилятор, с помощью которого программа переводится с языка, на котором она написана, в машинные коды;

средства отладки и запуска программ;

общие библиотеки, содержащие многократно используемые элементы программ;

справочную систему и другие элементы.

Microsoft Visual Studio - линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework и Microsoft Silverlight. Visual Studio построена на архитектуре, поддерживающей возможность использования встраиваемых дополнений - плагинов от сторонних разработчиков, что позволяет расширять возможности среды разработки [23].

Microsoft Visual Studio 2010 (кодовое имя Hawaii) - выпущена 12 апреля 2010 года вместе с .NET Framework 4.0. Visual Studio включает поддержку языков C# 4.0.

Интегрированная среда разработки Microsoft Visual Studio 2010 не является крайне необходимой для создания приложений на С#, но она значительно упрощают этот процесс. При желании, конечно, можно манипулировать файлами исходного кода на С# в базовом текстовом редакторе, вроде повсеместно известного редактора Notepad, и компилировать код в сборки с помощью компилятора командной строки. Однако данный процесс требует значительных навыков и понимания базовых принципов программирования.

Редакции Express Edition следует рассматривать как ответ фирмы Microsoft на существующие сегодня бесплатные инструменты для разработчиков. Эти редакции преднамеренно лишены некоторых возможностей (конструктора классов, модульного тестирования, шаблонов предприятия, поддержки XSLT, управления исходными кодами, поддержки 64-битных вычислений и т. д.). Однако они имеют полную поддержку языков (например, LINQ) и доступ к элементам .NET Framework (таким как WPF).

Редакции Express Edition имеют также упрощенную среду пользователя, лишенную сложности (и возможностей) профессиональных редакций. Однако при помощи этих инструментов разработчики смогут создавать приложения "клиент-сервер" (на базе форм), Web-сайты и даже Web-сервисы [24].

Выбор платформы разработки

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

.NET Framework состоит из двух частей: общеязыковой исполняющей среды (common language runtime, CLR) и библиотеки классов (Framework Class Library, FCL).

CLR предоставляет модель программирования, используемую во всех типах приложений. У CLR собственный загрузчик файлов, диспетчер памяти (сборщик мусора), система безопасности (безопасность доступа к коду), пул потоков и другое. Кроме того, CLR предоставляет объектно-ориентированную модель программирования, определяющую, как выглядят и ведут себя типы и объекты. CLR является основой кросплатформенности .NET Framework, поскольку выполнятся для конкретной операционной системы.

FCL предоставляет объектно-ориентированный API-интерфейс, используемый всеми моделями приложений. В ней содержатся определения типов, которые позволяют разработчикам выполнять ввод/вывод, планирование задач в других потоках, создавать графические образы, сравнивать строки и т. п. Естественно, что все эти определения типов соответствуют существующей CLR в модели программирования [25].

Microsoft .NET Framework позволяет разработчикам в гораздо большей степени задействовать готовые технологии, чем аналогичные платформы других разработчиков. В частности, .NET Framework предоставляет реальные возможности повторного использования кода, управления ресурсами, многоязыковой разработки, безопасности, развертывания и администрирования. Вот далеко не полный список преимуществ использования технологий Microsoft .NET Framework [25]:

единая программная модель;

отсутствие проблем с версиями;

работа на многих платформах;

интеграция языков программирования;

упрощенное повторное использование кода;

автоматическое управление памятью (сбор мусора).

Технология ASP.NET

С выходом первой версии .NET Framework около десяти лет назад в сфере проектирования программного обеспечения появилось совершенно новое направление. Вдохновленные наилучшими возможностями Java, COM и веб-технологий и обученные на ошибках и ограничениях прежних технологий, разработчики в Microsoft решили полностью обновить свою платформу для разработки. В результате этого появился ряд удивительно совершенных технологий для выполнения всего, начиная от построения приложений Windows и заканчивая выполнением запросов в базах данных, и специально ориентированный на разработку веб-сайтов инструмент под названием ASP.NET [26].

Когда платформа ASP.NET была выпущена впервые, от предыдущих продуктов Microsoft и конкурирующих платформ ее отличали семь ключевых фактов [26]:

ASP.NET интегрируется с .NET Framework. Способ, которым классы .NET Framework можно использовать в ASP.NET, ничем не отличается от того, которым они применяются в приложениях .NET любого другого типа. Хотя в .NET предлагаются ориентированные специально на Windows- и на веб-приложения классы для построения пользовательских интерфейсов, большинство возможностей .NET Framework (начиная с получения доступа к базам данных и закачивания поддержкой многопоточной обработки) допускается использовать в приложениях любого типа. Другими словами, в .NET разработчикам веб-приложений предлагаются те же самые инструменты, что и разработчикам многофункциональных клиентских приложений;

код ASP.NET компилируется, а не интерпретируется. Приложения ASP.NET в действительности проходят через два этапа компиляции. На первом этапе написанный код на С# компилируется в код на промежуточном языке MSIL (Microsoft Intermediate Language - промежуточный язык Microsoft), или просто IL. Этот первый этап компиляции может происходить как автоматически при первом запросе страницы, так и выполняться заранее (это называется предварительной компиляцией). Скомпилированный файл с кодом на IL представляет собой сборку. Второй этап компиляции происходит непосредственно перед фактическим выполнением страницы. На этом этапе код IL компилируется в код на низкоуровневом машинном языке. Называется этот этап оперативной (Just-In-Time - JIT) компиляцией и выглядит одинаково для всех приложений .NET;

в ASP.NET поддерживается множество языков программирования. Хотя при разработке приложения предпочтение, скорее всего, будет отдано какому-то одному языку, выбор языка никак не влияет на то, какие задачи с помощью приложения можно будет решать. Причина в том, что какой бы язык не использовался, код всегда будет компилироваться в IL;

ASP.NET обслуживается средой CLR;

ASP.NET является объектно-ориентированной технологией;

ASP.NET поддерживает все браузеры;

ASP.NET позволяет легко выполнять развертывание и конфигурирование.

Интерфейс Membership API

Интерфейс Membership API - это платформа, построенная на основе существующей инфраструктуры аутентификации с помощью форм, предоставляет полный набор готовых функций управления пользователями [26]:

возможность создавать и удалять пользователей - как программно, так и с помощью Web-утилиты конфигурирования ASP.NET;

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

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

Любая функциональность, перечисленная выше, работает совершенно независимо от конкретного используемого хранилища данных, и одни хранилища данных можно заменять на другие - совершенно без необходимости какой-либо модификации приложений. Класс Membership обеспечивает набором методов для программного доступа к пользователям и ролям, находящимся в хранилище. Эти методы работают с поставщиком Membership. Поставщик реализует доступ к лежащему в основе хранилищу данных. Все классы, относящиеся к Membership API, размещаются в пространстве имен System.Web.Security.

Интерфейс Membership API служит только для управления и аутентификации пользователей. Он не реализует никакой функциональности авторизации и не предоставляет функциональности управления пользовательскими ролями. Для этой цели предназначен интерфейс Roles API, который будет рассмотрен подробнее в пункте 2.4.6.

Прежде чем приступить к использованию интерфейса Membership API и элементов управления безопасностью ASP.NET, необходимо выполнить несколько шагов [26]:

сконфигурировать аутентификацию форм в файле web.config и запретить доступ анонимным пользователям;

настроить хранилище данных Membership. В базе данных нужно создать пару таблиц и хранимых процедур;

сконфигурировать в файле web.config строку подключения к базе данных и поставщика Membership;

создать пользователей в хранилище данных Membership с помощью Web-утилиты конфигурирования ASP.NET либо воспользоваться собственной страницей администрирования, которую можно реализовать в своем Web-приложении, используя функции Membership API.

Membership API, обеспечивает полноценную инфраструктуру управления пользователями приложения. Для доступа к этим базовым службам можно применять WAT (средство администрирований Web-узла), новые элементы управления безопасностью или же непосредственно Membership API. Сама платформа Membership API основана на модели поставщиков. Другими словами, можно расширять возможности лежащего в основе хранилища, заменяя поставщика и не затрагивая приложения.

Интерфейс Roles API

Платформа ASP.NET поставляется с готовой к использованию инфраструктурой для управления и применения ролей. Эта инфраструктура, будучи полностью расширяемой через механизм поставщиков, такой как у Membership API, включает встроенную функциональность для управления ролями, назначения ролей пользователям и обращения ко всей информации о ролях в коде. Если говорить более подробно, то инфраструктура ролей включает перечисленные ниже аспекты [26]:

основанный на поставщиках механизм включения разных типов хранилищ данных, связанных с ролями;

готовую к использованию реализацию поставщика для SQL Server и необходимые таблицы базы данных, основанные на данных членства;

предварительно построенный класс RolePrincipal, автоматически инициализируемый для аутентифицированных пользователей через RoleManagerModule (также входящий в инфраструктуру ролей);

полный программный доступ к ролям через класс Roles.

После конфигурирования Roles API можно создавать пользователей и роли, а затем назначать пользователей на эти роли с помощью либо WAT (средство администрирований Web-узла), либо класса Roles в коде. Интерфейс WOT представлен на рисунке 2.4:

Рисунок 2.4 - Интерфейс средства администрирования Web-узлом

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

Microsoft SQL-server 2008 R2 Express

Microsoft SQL Server 2008 Express - это мощная и надежная система управления данными, обеспечивающая множество функций, защиту данных и высокую производительность для внедренных приложений-клиентов, «легких» веб-приложений и локальных хранилищ данных. Microsoft SQL Server 2008 R2 Express - это бесплатный, обладающий развитыми функциональными возможностями выпуск SQL Server, который идеально подходит для обучения, разработки и наращивания функциональности приложений для настольных компьютеров, веб-приложений и небольших серверных приложений, а также для распространения через независимых поставщиков программных продуктов. 

Основные возможности:

поддержка хранимых процедур, триггеров, функций и представлений;

хранение всех видов бизнес-данных с собственной поддержкой XML, FILESTREAM, реляционных и пространственных данных;

повысились производительность, удобство работы, визуализация, а также степень интеграции с системой Microsoft 2007 Office в службах SQL Server Reporting Services;

сократились усилия на разработку за счет использования имеющихся знаний T-SQL, ADO.NET Entity Framework и LINQ;

тесная интеграция с Visual Studio и Visual Web Developer.

Microsoft SQL Server -- система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов -- Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка [27].

Пакет Microsoft SQL Server 2008 предоставляет массу новых возможностей. Особого внимания заслуживают такие функции, как поддержка «горячего» добавления процессора (Hot Add CPU), инструмент Resource Governor, сжатие данных, «прозрачное» шифрование данных, управление на основе политик и сбор изменений данных. Все редакции пакета SQL Server 2008 включают полезные усовершенствования, в том числе новые типы данных, поддержку механизма отладки кодов T-SQL и автоматического заполнения IntelliSense, а также улучшения в механизмах бизнес-аналитики (BI).

После выпуска Microsoft SQL Server 2008 продукт SQL Server стал не просто реляционной базой данных, скрытой за корпоративными приложениями. Целью компании Microsoft является признание SQL Server 2008 информационной платформой, способной удовлетворить любые требования пользователей к механизмам обработки информации. Благодаря встроенным службам интеграции, анализа и отчетности сервер SQL Server 2008 более чем способен соответствовать этим ожиданиям [28].

Безопасность: учетные данные (в пакете входа), передаваемые при соединении клиентского приложения с SQL Server, всегда зашифрованы. SQL Server будет использовать сертификат доверенного корневого центра сертификации, если он есть. Если доверенный сертификат не установлен, то SQL Server сформирует самозаверяющий сертификат при запуске экземпляра и будет шифровать учетные данные с его помощью.

Вывод

В данном разделе были рассмотрены основные стандарты в области управления процессом разработки программных проектов применимые к отдельным объектам управления, к субъектам управления, к системе УП и организации в целом и позволяющие оценить уровень зрелости организационной системы менеджмента. Проанализированы наиболее популярные методы (методологии) разработки программного обеспечения: каскадная или модель водопада, итеративная, гибки методологии. Каждая из них имеет свои преимущества, которые проявляются в соответствующих условиях. Для разработки дипломного проекта была выбрана итеративная модель, так как осуществлялось выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы, дополнением требований. Данная методология позволяет на более ранних стадиях выявить ошибки предыдущего этапа жизненного цикла проекта. Итеративное тестирование проводится непрерывно, на завершающем этапе каждой итерации, что позволяет наиболее точно оценить успешность проекта.

Были описаны технологии и средства разработки, использовавшиеся в процессе создания приложения. Технология ASP.NET повышает степень устойчивости к вредоносным действиям и различным видам хакерских атак сайтов, построенных на ней. Используемая платформа Microsoft .NET имеет множество встроенных технологий для интеграции информационных систем и приложений, таких как службы Web, WCF, XML и другие, при этом ASP.NET существует как ее часть. Наличие таких многочисленных решений дает возможность выбора оптимальной технологии для каждого отдельного случая. Это обеспечивает отменную производительность, масштабируемость и, самое главное, безопасность.

Для разработки на платформе ASP.NET использовалась среда MS Visual Studio 2010 года, которая признана одним из лучших средств. Данная среда упростила и ускорила создание Web-приложения за счет применения усовершенствованного конструктора Web-форм, поддержки неограниченного набора коммерческих и стандартных элементов управления.



3.Проектирование и реализация системы управления IT-проектами

3.1 Проектирование логической структуры базы данных

Для реализации поставленной задачи была создана база данных System_manager. Для её создания использовалось система управления реляционными базами данных Microsoft SQL Server.

База данных - совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования данными, независимая от прикладных программ [29]

Система управления базами данных - совокупность программ и языковых средств, предназначенных для управления данными в базе данных, ведения базы данных и обеспечения взаимодействия ее с прикладными программами [29]

При разработке приложения использовался интерфейс Membership API, поэтому для начала потребовалось настроить хранилище данных.

Настройка хранилища данных

ASP.NET поставляется с инструментом aspnet_regsql.exe, который создает таблицы автоматически. Необходимо было запустить инструмент в окне командной строки Visual Studio, поскольку оно включает всю необходимую настройку путей к каталогу .NET Framework, содержащему нужные инструменты. После запуска команды появляется интерфейс мастера установки SQL Server в ASP.NET, представленный на рисунке 3.1.

Рисунок 3.1 - Интерфейс мастера установки SQL Server в ASP.NET

Мастер создаёт и настраивает базу данных, в которой хранятся сведения для служб приложений ASP.NET (пользователи, профили, управление ролями, личные настройки и поставщики веб-событий SQL). Далее было предложено указать имя SQL сервера, базы данных, которую необходимо создать и учётные данные, используемые для подключения. После всех осуществлённых действий, была создана база данных System_manager с необходимыми для работы с Membership таблицами.

Основные таблицы, с которыми предстоит работать представлены на рисунке 3.2:

Рисунок 3.2 - Таблицы для работы с Membership

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

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

Создание основных таблиц

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

ClientData (основные данные о клиенте);

Employee (личные данные сотрудника);

ProjectsData (данные о проекте, название, сроки);

ProjectsData (таблица, связывающая клиента с проектами);

PostInEmployee (таблица, связывающая сотрудника с проектом);

Post (список должностей);

PostInEmployee (таблица, связывающая сотрудника с должностью);

Phase (данные об этапах, на которые разбивается проект);

PhaseInProject (таблица, связывающая этапы с соответствующим проектом);

Tasks (данные о задачах, на которые разбивается этап проекта);

TasksInProject (таблица, связывающая задачи с проектом);

EmployeeInTasks (таблица, связывающая задачи с сотрудником, который назначен на её выполнение);

и другие таблицы (для работы с языками, технологиями, местом работы и так далее).

Схема таблиц базы данных System_manager со всеми связями представлена на рисунке 3.3:

Рисунок 3.3 - Схема таблиц базы данных System_manager

Исходный код создания таблиц представлен в приложении А.1. «Листинг создания таблиц базы данных», а схему базы данных можно подробно рассмотреть в приложении Б. «Схема логической структуры базы данных».

Представления

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

Представление (англ. view) - виртуальная (логическая) таблица, представляющая собой поименованный запрос, который будет подставлен как подзапрос при использовании представления [30].

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

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

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



Рисунок 3.4 - Схема представления vw_Project

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

Хранимы процедуры

Хранимая процедура - объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере. Хранимые процедуры очень похожи на обыкновенные процедуры языков высокого уровня, у них могут быть входные и выходные параметры и локальные переменные, в них могут производиться числовые вычисления и операции над символьными данными, результаты которых могут присваиваться переменным и параметрам. В хранимых процедурах могут выполняться стандартные операции с базами данных (как DDL, так и DML). Кроме того, в хранимых процедурах возможны циклы и ветвления, то есть в них могут использоваться инструкции управления процессом исполнения [31].

Хранимые процедуры обычно создаются с помощью языка SQL и конкретной его реализации в выбранной СУБД. В СУБД Microsoft SQL Server это язык Transact-SQL.

Для разработанного проекта были созданы хранимые процедуры реализующие функции сохранения данных в таблицы: сохранение изменений данных о клиенте, сотруднике, проекте, этапе и так далее. Список всех хранимых процедур представлен на рисунке 3.5.

Рисунок 3.5 - Список хранимых процедур базы данных

Исходный код создания одной из хранимых процедур - SaveClient - представлен на рисунке 3.6. Код создания всех остальных хранимых процедур представлен в приложении А.3. «Листинги создания хранимых процедур».

Рисунок 3.6 - Листинг создания хранимой процедуры SaveClient

Функции

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



Рисунок 3.7 - Создание функции V_PhaseInProject

Код остальных функций представлен в приложении А.4. «Листинги создания функций».

Проектирование и разработка приложения

Роли

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

Рисунок 3.8 - Диаграмма вариантов использования

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

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

Авторизация - предоставление субъектам доступа к объектам системы [32].

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

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

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

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

Более наглядно UML диаграмма вариантов использования системы представлена в приложении В. «Диаграмма вариантов использования».

Структура приложения

Структура приложения построена так, что каждой роли принадлежат свои страницы, которые видны только пользователям, принадлежащим данной роли. Структура страниц приложения показана на рисунке 3.9.

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

Страница Default.aspx - главная страница приложения. На неё попадает любой пользователь системы. Страница login.aspx - содержит форму для входа в систему, а страница registrated.aspx - форму для регистрации. На странице Info.aspx будет храниться информация о компании. Данные страницы видны всем пользователям.

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

Папка Client содержит страницы, доступные только клиенту компании. Это форма с личными данными клиента, форма для добавления заказов, списки всех заказов, утверждённых и неутверждённых.

Рисунок 3.9 - Структура страниц приложения

В папке Employee расположены страницы, доступные только сотруднику компании. Здесь находится форма с личными данными, страница со списком всех задач сотрудника, форма для фиксации выполнения задания, списки проектов, в которых участвует сотрудник.

Так же, в этом проекте был создан подпроект Model, в котором хранятся страницы, где прописаны классы для доступа к базе данных.

Структурную схему проекта можно просмотреть в приложении Г. «Структура страниц приложения».

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

Для разграничения доступа к страницам приложения использовалась аутентификация с помощью форм.

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

Когда пользователь регистрируется, он получает так называемый билет с базовой информацией о себе. Информация сохраняется в зашифрованном cookie-наборе, который присоединяется к ответу, так что автоматически отправляется в каждом последующем запросе. Когда пользователь запрашивает страницу ASP NET, которая не доступна анонимным пользователям, исполняющая среда ASP.NET проверяет, имеется ли билет аутентификации с помощью форм. Если нет, производится автоматическая переадресация на страницу входа [26].

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

Каждый файл web. config включает раздел конфигурации <authentication>. Для атрибута mode необходимо было указать значение Forms. Фрагмент файла web.config, в котором включается раздел конфигурации <authentication>, представлен в следующем листинге:

<authentication mode="Forms"> </authentication>
Листинг для включения конфигурации аутентификации

В данном случае используются установки по умолчанию для аутентификации с помощью форм, которые жестко закодированы в исполняющей среде ASP.NET.

Конфигурация <authentication> ограничена только файлом web.config высшего уровня приложения, то ASP.NET загружает и активизирует модуль FormsAuthenticationModule, который выполнит большую часть работы.

Как было сказано в пункте 3.2.2, для каждой роли была создана отдельная папка. В каждой папке расположен свой конфигурационный файл, где прописывается правило доступа. Необходимо было добавить новое правило авторизации к элементу <authorization>. В отличие от <authentication>, элемент <authorization> не ограничен файлом web.config, находящимся в корневом каталоге веб-приложения. Его можно создавать в любом подкаталоге, что позволяет устанавливать разные настройки авторизации для разных групп страниц. Фрагменты файлов web.config для каждой роли представлены на рисунке 3.10:

Менеджер	Клиент	Администратор	Сотрудник
Рисунок 3.10 - Фрагменты файлов web.config для каждой роли

Знак звёздочка (*) - это шаблонный символ, которому соответствуют все пользователи. При включении этого правила в файл web.сonfig указывается, что все пользователи не разрешены. Чтобы указать, кому разрешён доступ, добавляется элемент <allow>. В данном случае был указан список ролей, пользователям которых разрешён доступ.

Интерфейс Membership API включает предварительно подготовленный элемент управления Login, который может применяться либо на отдельной странице входа, либо в составе любой страницы веб-приложения. На рисунке 3.11 представлен стандартный элемент Login, расположенный на странице входа Login.aspx:

Рисунок 3.11 - Элемент управления входом

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

Всякий раз, когда пользователь щелкает на кнопке Вход, элемент управления автоматически проверяет имя и пароль, используя для этого функцию Membership.ValidateUser(), а затем вызывает FormsAuthenication. RedirectFromLoginPage(), если проверка прошла успешно.

FormsAuthenication.RedirectFromLoginPage() - перенаправляет прошедшего проверку подлинности пользователя по первоначально запрошенному URL-адресу. Перед аутентификацией пользователя элементом управления инициализируется событие LoggingIn, которое вызывает функцию logIn, которая сохраняет в сессии имя вошедшего пользователя.

Элементы управления доступом

После того, как пользователь прошёл проверку подлинности элемент управления Login, рассмотренный в пункте 3.2.4, сменяется элементом управления LoginName и LoginStatus. LoginName - отображает имя вошедшего пользователя, а LoginStatus - ссылку для входа (пользователям, не прошедшим проверку подлинности) и ссылку для выхода (пользователям, прошедшим проверку подлинности). Ссылка для входа направляет пользователя на страницу входа. Ссылка для выхода меняет текущий статус пользователя на анонимный. Элемент LoginName и LoginStatus представлены на рисунке 3.12:

Рисунок 3.12 - Элементы управления LoginName и LoginStatus

Для организации смены элементов в зависимости от роли, к которой принадлежит пользователь, используется элемент управления LoginView.

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

Рисунок 3.13 - Элемент управления LoginView

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

Элемент LoginView использовался также для отображения меню. Данный элемент осуществляет смену меню в зависимости от роли вошедшего пользователя. На рисунке 3.14 показан пример меню для сотрудника и клиента:

Рисунок 3.14 - Элемент LoginView для разных видов ролей

Элемент управления CreateUserWizard собирает информацию от потенциальных пользователей. Он используется при регистрации и расположен на странице registrated.aspx. Эта информация используется для проверки подлинности пользователя и при необходимости для восстановления паролей пользователей. Применяя CreateUserWizard, не придется выполнять какую-либо специальную конфигурацию. Элемент управления CreateUserWizard представлен на рисунке 3.15:

Рисунок 3.15 - Элемент управления CreateUserWizard

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

Классы

Приложение основано на проекте SM (System Manager) и его подпроекте Model. В проекте SM содержаться все Web-страницы приложения, проект Model содержит классы для взаимодействия с базой данных. Диаграмма классов проекта Model представлена на рисунке 3.16. Более наглядно диаграмма классов представлена в приложении Д. «Диаграмма классов». Как видно из диаграммы, проект содержит класс DBUtil - класс для связи с базой данных. Все остальные классы наследуют его, чтобы получить данный функционал.

Рисунок 3.16 - Диаграмма классов

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

Потомки класса DBUtil содержат функции для получения данных о различных объектах приложения.