Опубликован: 27.06.2009 | Доступ: свободный | Студентов: 1737 / 45 | Оценка: 4.12 / 3.62 | Длительность: 13:51:00
Специальности: Программист
Лекция 9:

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

Функциональные, нефункциональные требования и характеристики продукта

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

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

Функциональные требования записываются, как правило, при посредстве предписывающих правил: "система должна позволять пользователю формировать приходные и расходные накладные"

Анализ требований - один из основных рабочих потоков (workflow) программной инженерии, таких как: проектирование интерфейса пользователя или программирование.

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

Хорошо проработанные требования позволяют:

  • выработать общее понимание между Заказчиком и Разработчиком
  • определить рамки проекта
  • более точно определить финансовые и временные характеристики проекта
  • обезопасить Заказчика от риска получить продукт, в котором он не сможет работать
  • обезопасить Разработчика от риска попасть в ситуацию "неконтролируемого размытия границ", которое может привести к непредвиденным затратам ресурсов сверх начальных ожиданий

Один из ключевых вопросов, позволяющих оценить результативность процесса - что является выходом (результатом) процесса. Результатом рабочего потока "анализ требований" является набор артефактов. Это могут быть текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.

Проект разрабатывался по методологии MSF(Microsoft Solutions Framework for Agile Development). В MSF для обозначения роли участников команды софтверного проекта используется понятие ролевых кластеров. MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением. Шесть ролевых кластеров модели проектной группы - это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. MSF организован на базе комбинации каскадной и спиральной моделей.

Этап реализации проекта

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

Программист, приступая к работе, сначала подключается к Team Foundation Server. После подключения ему становится доступен для редактирования проект, первоначально созданный менеджером проекта. При помощи Team Explorer – клиентской части Visual Studio Team Suite, программист может просмотреть все необходимые для выполнения задания.


Рис. 15.1.

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


Рис. 15.2.

Чтобы приступить непосредственно к реализации проекта, необходимо открыть файлы для редактирования, выбрав из контекстного меню файла пункт Check out for Edit. При открытии файлов, они копируются на локальную машину для внесения изменений.


Рис. 15.3.

Редактировать файл можно в 3 режимах:

  • Монопольно
  • Все пользователи могут редактировать файлы
  • Все пользователи могут открывать файл для редактирования, но не могут сохранять изменения

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

В этом случае, программист может связаться с архитектором либо создав новое задание и отчет об ошибке.


Рис. 15.4.