Дипломная работа: Автоматизация учета рабочего времени сотрудников в ТОО "Профессиональные охранные системы"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
67
информации. Таким образом, необходимо, чтобы команда проекта понимает кли-
ента и его бизнеса. В противном случае это невозможно правильно реализовать
потребности клиентов. Процесс разработки программного обеспечения должен
сосредоточиться на требованиях на протяжении всего проекта. Выявление и до-
кументирование требований в начале не является достаточным. Кроме того, про-
цесс разработки программного обеспечения должен гарантировать, что не только
клиент, но и конечные пользователи участвуют в процессе формирования требо-
ваний. Успех проекта сильно зависит от этих двух групп: первая покупка про-
дукта, а второй его использования. Процесс разработки программного обеспече-
ния должен определить процедуры для подготовки конечных пользователей ис-
пользовать конечный продукт.
Архитектура привод – в современных разработках программного обеспече-
ния, архитектура системы оказывает значительное влияние на общем качестве
продукта. Одной из причин этого является интеграция в существующие системы
и окружающей среды, как большая часть сегодняшнего развития программного
обеспечения. Повторное использование приобретает все большее значение в связи
с увеличением времени и давления затрат.
Фокус на команды – команда должна рассматриваться как совокупность
равноправных лиц, которые вместе несут ответственность за качество и успеш-
ность проекта. Когда ответственность за неудачи может быть отнесена к одному
человеку, успех проекта не гарантирован больше. Сосредоточение на совместную
работу и повышает мотивацию участников проекта, так как все это рассматрива-
ется как столь же важной частью проекта. Это в конечном итоге приводит к высо-
кой идентификации членов команды с продуктом. Очевидно, что мотивированные
члены команды способствуют высокому качеству, поскольку они работают более
концентрированными и добросовестными. Процесс разработки программного
обеспечения должна включать четко определенную структуру команды, в том
числе эффективной постановки задач и четких руководящих принципов комму-
никации. MSF «команда сверстников» присваивает значение равного по каждому
члену команды и роли: полная команда имеет шесть целей для достижения и мо-
жет рассматриваться как мощные реализации принципа команды фокуса. В боль-
шинстве проектов некоторые цели имеют более высокое значение, чем другие.
68
Менеджеры решают самостоятельно или возложить ответственность за неспособ-
ность членов своей команды. MSF «команда коллег» концепция позволяет избе-
жать этих проблем и позволяет проект, чтобы получить прибыль от всех возмож-
ностей коллективной работы.
Парное программирование – парное программирование тесно связано с ак-
центом на команды, но был выбран в качестве другого критерия оценки, по-
скольку он был недооценен за свой вклад в высокое качество в прошлом. XP де-
монстрирует, как два разработчики могут дополнять друг друга, а не ингибирова-
ния друг друга. Один разработчик реализует текущий метод, а другой работает
над вопросами интеграции. Такой подход экономит время и минимизирует коли-
чество ошибок. Лучшие решения, более вероятно, так как два человека, скорее
всего, имеют разные точки зрения той же проблемы и, следовательно, дополняют
друг друга в ее решении.
Портняжное с ограничениями – процесс разработки программного обеспе-
чения должен быть определен и формализован в пути относительно его примене-
ния к широкому набору проектов. Процесс, который концентрируется на неболь-
шой или специализированный наборе проектов гарантирует высокое качество в
конкретной среде. Основной целью процесса является применение многих проек-
тов внутри компании, не снижая его прочности. Процесс должен быть адаптиро-
ван к различным проектам на основе ее основных элементов. Для того, чтобы
охватить всю сложность типовых проектов заданного набора основных элементов
должно быть сохранено. Большое количество основных элементов, не обяза-
тельно улучшить качество конечного продукта. Поэтому процесс разработки про-
граммного обеспечения должны опираться на основные элементы. Основываясь
на этих основных элементах, процесс должен определить методы для пошива про-
цесса к типу проекта и размера проекта.
Конфигурация и управление изменениями – хорошо функционирующая
конфигурация и управление изменениями (КЗУ) является важной частью обеспе-
чения качества программного обеспечения. Существование или не существование
КЗУ оказывает наибольшее влияние при обслуживании программного обеспече-
ния и развития, все же основы для КЗУ (надлежащей документации, кода архивов
источника и т.д.) должны быть установлены в процессе разработки.
69
Управление рисками – корректное понимание риска и форма управления
смягчением вместе эффективное управление рисками и является ключевым фак-
тором в достижении высокого качества продукции. Управление рисками позво-
ляет смягчить риск раннего и возможность действовать вместо реагировать на
проблемы и риски. MSF представляет свою собственную модель управления рис-
ками. Она, следовательно, делает акцент на дисциплине как важное значение для
поддержания проекта на трассе улучшая общее качество доставки. Управление
рисков как собственная дисциплина является критерием для любого процесса раз-
работки программного обеспечения с акцентом на улучшении качества программ-
ного продукта. Управление рисками в рамках ежедневных встреч и других дисци-
плин предполагает, что идентификация и управление рисками становится менее
важным, поскольку проектная группа занята другими проблемами. Проект стано-
вится восприимчивым к факторам риска. В таблице 2.1 приведены критерии для
выбора стандарта.
Таблица 2.1
Критерии для выбора стандарта
Критерий
MSF
RUP
XP
Разработка программного обеспечения Итерационной
+
+
+
Качество как цель
+
-
-
Непрерывно проверка качества
+
+
+
Требования заказчика
+
+
+
Архитектура привод
+
+
+
Фокус на команды
+
+
+
Парное программирование
+
-
-
Портняжное с ограничениями
+
+
-
Конфигурация и управление изменениями
+
-
-
Управление рисками
+
-
-
Microsoft Solutions Framework является наиболее сбалансированной техно-
логией, ориентированной на проектные группы малых и средних размеров. MSF
70
не накладывает никаких ограничений на используемый инструментарий и содер-
жит рекомендации весьма общего характера. Однако, эти рекомендации могут
быть использованы для построения конкретного процесса, соответствующего по-
требностям коллектива разработчиков.
Наш проект является небольшим, включает в себя 2 человека и этапы раз-
работки и тестирования проводятся в среде разработки C#. Кроме того, основным
преимуществом MSF является итерационная модель одновременно с уточняю-
щими вехами (аналог каскадной модели). Таким образом, реализация MSF попы-
талась объединить каскадную и итерационную модель разработки и внедрения
ПО.
По описанным выше преимуществам, мною был выбран стандарт MSF как
наиболее гибкий и удобный для реализации моего проекта.
Одним из преимуществ этого стандарта является возможность управлять
одновременно и проектом разработкой приложения и внедрением инфраструк-
туры.
Этапы
Предвидение фаза процесс MSF начинается с фазы выработки концепции.
Предвидение может быть определена как создание широкого описания целей и
ограничений проекта. На этом этапе команда определена и то, что команда должна
выполнить для клиента. Цель фазы выработки концепции заключается в создании
общей концепции проекта среди всех ключевых заинтересованных сторон про-
екта.
Методология разработки во время фазы выработки концепции команда
управления программой определяет задачи и ожидаемые результаты, которые
учитывают потребности и цели проекта. Эта фаза завершается видением / Scope
одобрил веху. Этот этап означает, что клиент и команда договариваются о цели и
направлении проекта.
Фаза планирования на этапе планирования, команда определяет, что для
разработки и планов, как создать решение. Команда готовит функциональную
спецификацию, создает дизайн решения, и готовит планы работы, сметы расходов
и графики для различных результатов.
71
Этап планирования включает анализ требований. Эти требования могут
быть классифицированы как бизнес-требование, требования пользователей, экс-
плуатационные требования и требования к системе. Эти требования используются
для разработки решения и его особенности и проверить правильность конструк-
ции.
После сбора и анализа требований, команда создает дизайн решения. Ко-
манда создает профили пользователей, которые определяют различные пользова-
телей решения и их роли и обязанности. Затем команда создает ряд сценариев ис-
пользования. Сценарий использования определяет деятельность, выполняемую
определенным типом пользователя. Таким образом, команда должна создать сце-
нарии использования для всех профилей пользователей. После создания сцена-
риев использования, команда создает случаи использования для сценариев ис-
пользования. Прецедент определяет последовательность шагов, которые пользо-
ватель будет выполнять в сценарии использования.
Разработка фазы во время фазы разработки, команда проекта создает реше-
ние. Этот процесс включает в себя создание кода, который реализует решения и
документирование кода. В дополнение к разработке кода, команда также разви-
вает инфраструктуру для решения.
Процесс разработки команда выполняет следующие основные задачи на
этапе разработки:
Начиная цикл разработки. Проверка того, что все задачи, выявленные в
ходе выработки концепции и планирование этапов были завершены, так что ко-
манда может приступить к разработке решения.
Создание приложения прототипа. Проверка концепций проекта решения
в среде, которая напоминает среду, в которой решение будет в конечном счете
развернутая. Эта среда является как можно более близкой к производственной
среде. Эта задача будет завершена до начала разработки.
Разработка компонентов решения. Разработка основных компонентов
раствора, и расширение этих компонентов к конкретным потребностям решения.
Построение решения. Серия ежедневно или частые сборки, которые до-
стигают высшей точки с основным внутренним строит, что означают точки, когда
команда разработчиков поставляет ключевые особенности решения.
Источник: https://baza.diplomsite.ru/previewfile/2420