Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Ход работы. Порядок выполнения работы

Читайте также:
  1. D. Требования к структуре и оформлению курсовой работы.
  2. E. Порядок защиты курсовой работы.
  3. I ОРГАНИЗАЦИОННО-МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ КУРСОВОЙ РАБОТЫ
  4. I Принцип работы клавиатур
  5. I. МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ КОНТРОЛЬНОЙ РАБОТЫ
  6. I. ОБЩИЕ ПОЛОЖЕНИЯ ПО ВЫПОЛНЕНИЮ КОНТРОЛЬНОЙ РАБОТЫ
  7. I. Общие рекомендациик написанию курсовой работы
  8. I. Основные задачи и направления работы библиотеки
  9. I. ОСНОВНЫЕ ПОЛОЖЕНИЯ. РУКОВОДСТВО ПОДГОТОВКОЙ И НАПИСАНИЕМ КУРСОВОЙ РАБОТЫ
  10. I. Теоретическая часть лабораторной работы

Порядок выполнения работы

1. Изучить теоретический материал.

2. Определить обоснованно тип работ из списка команды разработчиков.

3. Описать все их функциональные обязанности для всех этапов жизненного цикла процесса создания ПО.

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

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

Ход работы

В ходе выполнений лабораторной работы был выбран вариант указанный в Таблице 1.

Таблица 1 – номер варианта и тема задания.

Вариант  
Задание Система автоматизации работы кадрового агентства.  

 

1 На фазе разработки.

Основные задачи и сферы ответственности каждого из авторов команды разработчиков во время фазы разработки (см.табл.1).

Таблица 1 – Задачи ролевых групп на фазе разработки

Функциональные обязанности Задачи
Управление продуктом Требования заказчика.
Управление проектом Управление функциональной спецификацией; мониторинг проекта; доработка планов.
Разработка Разработка программного кода и информационных связей всех типов. Документирование конфигураций.
Удовлетворение потребителя Обучение; доработка плана обучения; тестирование удобства эксплуатации; контроль графического дизайна.
Тестирование Настройка тестовой среды. Разделение приложения на функционально-законченные единицы, компоновка тестов согласно плану, функциональное тестирование; выявление проблем; доработка плана тестирования, работа с ошибками, анализ и оценка тестового покрытия.
Управление выпуском Доработка планов внедрения (включая фазу опытной эксплуатации); подготовки к внедрению коммерческой версии.

 

Результатами фазы разработки являются:

- исходный и исполнимый код приложений;

- окончательная функциональная спецификация;

- материалы поддержки решения;

- спецификации и сценарии тестов.

2 На фазе тестирования.

Основные задачи и сферы ответственности каждого из авторов команды разработчиков во время фазы верификации (см.табл.2).

Таблица 2 – Задачи ролевых групп на фазе тестирования

Функциональные обязанности Задачи
Управление продуктом Выполнение плана верификации программного продукта.
Управление проектом Мониторинг проекта; приоритезация ошибок.
Разработка Устранение ошибок; оптимизация программного кода.
Удовлетворение потребителя Доработка эксплуатационных руководств; учебные материалы.
Тестирование Проведение инсталляционного, системного, функционального тестирования, повторное тестирование; анализ сообщений об ошибках и их статусе; тестирование конфигурации, описание и анализ результатов тестирования.
Управление выпуском Развертывание и поддержка пилотного внедрения; планирование внедрения коммерческих версий продукта; обучение персонала сопровождения.

Табл.2.4.

Результатами фазы верификации являются.

- окончательный продукт;

- документация выпуска;

- материалы поддержки решения;

- результаты и инструментарий тестирования;

- исходный и исполнимый код приложений.

 

Каждому сотруднику соответствуют определённые обязанности. Перечень участников команды разработчиков:

- менеджер проекта;

- архитектор;

- инженер по вариантам использования;

- инженер по компонентам;

- системный аналитик;

- спецификатор вариантов использования;

- тестировщики(разработчики тестов, тестировщики целостности, системный тестировщик);

- кодировщики (программисты);

- специалисты по повторному использованию;

- разработчик интерфейса «пользователь- ПК».

 


3 Рассмотрим функциональные обязанности участников команды, которые присущи данному ПО (для участников команды разработчиков была создана диаграмма Гантта, по которой видно, длительность и начало разработки ПО):

3.1Менеджер проекта:

Он несет персональную ответственность за связь с заказчиком, а именно:

- осуществление идентификации проблемы и планирование выполнения проекта;

- согласование и анализ требований различного назначения;

- определение ориентировочной стоимости проекта;

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

Он осуществляет контроль разработки и выполнения календарных планов:

- распределение членов команды разработчиков, с учётом их профессиональных знаний и навыков;

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

- является связующим звеном между командой и вышестоящим руководством;

- несёт ответственность перед заказчиком.

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

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

3.2 Системный аналитик отвечает:

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

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

- за создание и использование глоссария, чтобы обеспечить согласие по общим терминам, понятиям и концепциям.

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

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

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

3.6 Инженер по компонентам:

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

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

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

- поддерживает целостность одной или более подсистем.

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

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

3.8 Разработчик тестов:

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

- планируют тесты, т.е. определяют цели соответствующих тестов и график тестирования;

- выбирают и определяют тестовые примеры и соответствующие им процедуры тестирования,

- отвечают за оценку результатов тестов интеграции и системных тестов.

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

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

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

3.11 Инженер по компонентам отвечает за тестовые компоненты, которые автоматизируют некоторые процедуры тестирования, но не все процедуры тестирования можно автоматизировать.


Рисунок 1 – Диаграмма команды разработки ПО

 




Дата добавления: 2015-01-12; просмотров: 14 | Поможем написать вашу работу | Нарушение авторских прав

<== предыдущая лекция | следующая лекция ==>
Сл.3хч.форма| Ист-ки инф-ии и порядок провед-я ан-за СЕБ-ти пр-ва пр-ции ЖИВ-ВА.

lektsii.net - Лекции.Нет - 2014-2024 год. (0.011 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав