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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


Курсовик План управления программным проектом (SPMP) для Интеллектуальной системы комплектации ПВМ

Информация:

Тип работы: Курсовик. Добавлен: 3.4.2013. Сдан: 2012. Страниц: 36. Уникальность по antiplagiat.ru: < 30%

Описание (план):


План управления программным проектом (SPMP) для Интеллектуальной системы комплектации ПВМ
Утверждаю
Дата
05.09.11 Лысачев С.Г: Создание первой версии
02.10.11 Лысачев С.Г: Рецензирование и различные предложения по улучшению 16.11.11 Лысачев С.Г: Детализирован план-график, добавлены ссылки на валидацию и верификацию
29.11.11 Лысачев С.Г: Проверка для выпуска
1. Введение
1.1. Обзор проекта
Данный проект организован для разработки автоматизированного рабочего места работника регистратуры поликлиники в дальнейшем именуемое как АРМ «Регистратура». АРМ будет разработана в несколько этапов, поскольку заказчик намерен специфицировать систему поэтапно с учетом результатов предыдущего этапа. Первые версии создаются в целях обучения, чтобы разработчики могли попрактиковаться в технологии разработки. Последующие версии, как ожидается, будут либо свободно распространяемыми, либо коммерческими программами.
1.2. Результирующие артефакты проекта
Следующие материалы должны быть поставлены в указанные сроки.
Версия 1 (прототип) с документацией - вторая неделя второго месяца.
Версия 2 с документацией - четвертая неделя второго месяца.
Документация включает в себя SPMP, SRS, SDD (с использованием стандартов IEEE).
1.3. Развитие SPMP
Данный документ поддерживается лидером проекта. Лидер проекта должен поместить данный документ под управление конфигурациями и обязан поддерживать документ в актуальном состоянии, еженедельно внося необходимые изменения. Данный SPMP в основном следует стандарту IEEE 1058.1-1987.
1.4. Ссылочные материалы
Все необходимые стандарты IEEE опубликованы в сборнике стандартов IEEE, редакция 1997 года.
Данный документ должен быть согласован с корпоративным документом «Генеральный план достижения уровня 5 С ММ».
Основное руководство: Software Engineering: an Objected-Oriented Perspective. E. Braude, Wiley, 2000.
1.5. Аббревиатуры
CI - Configuration Item. Элемент конфигурации.
АРМ - Автоматизированное рабочее место.
CMM - Capability Maturity Model. Модель зрелости возможностей.
IEEE - Institute of Electrical and Electronics Engineers. Институт инженеров по электротехнике и радиоэлектронике.
QA - Quality Assurance. Контроль качества.
SEI - Software Engineering Institute. Институт технологий разработки программного обеспечения.
SPMP - Software Project Management Plan. План управления программным проектом (данный документ).
SRS - Software Requirements Specification. Спецификация требований к программному обеспечению.
SDD - Software Design Document. Проектная документация программного обеспечения.
2. Организация проекта
2.1. Модель процесса
Первые две версии этого проекта будут выполнены с использованием спирального процесса разработки, по одной итерации на версию. Итерации проводятся в соответствии с USDP. Согласно USDP, итерации классифицируются на начальные итерации, итерации проектирования, конструирования и перехода. Первая итерация будет состоять только из анализа и планирования требований, вторая итерация будет первой в серии итераций проектирования. Это составит версию 1 интеллектуальной системы комплектации пвм. Количество последующих итераций и состав версии 2 будут определены после того, как заказчик ознакомится с версией 1.

2.2. Организационная структура
Организация проекта АРМ «регистратура» в рамках корпорации IS Industries Consolidated представлена на рис. 1.1. Проект организован как команда равных с назначением ролей. Роли следующие: лидер команды, ответственный за конфигурацию, ответственный за качество, ответственный за требования, ответственный за проектирование и ответственный за реализацию. Кроме того, имеется роль ответственного за связи с отделом маркетинга и с лабораторией технологии программирования. Все эти роли показаны на рис. 1.2. Каждый участник команды будет проводить инспектирование работы других участников (см. рис. 1.2). Инспектирование будет происходить либо групповое, либо, если не будет хватать времени, индивидуальное автором и тем, кто его замещает.


Рисунок 1.1 - «Организационная структура корпорации IS Industries Consolidated».


Рисунок 1.2 - «Организационная проекта комплектации ПВМ».
2.3. Организационные рамки и взаимосвязи
Команда проекта должна взаимодействовать со следующими людьми и организациями: отдел разработки, отдел маркетинга, лаборатория интеллектуальных систем, внешние эксперты и лаборатория технологии программирования.
2.4. Ответственность за проект
Ответственность участников проекта показана в табл. 1.1. Ответственность за документ подразумевает следующее:
? документ должен быть создан вовремя;
? лидер команды определяет, кто пишет документ;
? документ поддерживается в актуальном состоянии.

Таблица 1.1. Ответственность участников проекта Комплектация ПВМ

Участник Лидер команды Ответственный за требования Ответственный за проектирование
Отвечает за связь Отдел разработки Отдел маркетинга Лаборатория технологии программирования
Отвечает за документ SPMP SRS SDD

3. Управляющий процесс
3.1. Цели и приоритеты
Высший приоритет имеет достижение заданного уровня качества. На втором месте по приоритетности стоит выполнение проекта в срок. Третий приоритет имеет выполнение максимального количества требований. Четвертый приоритет имеет создание классов, которые можно повторно использовать в других интеллектуальных системах.
3.2. Допущения, зависимости и ограничения
Нет.
3.3 Управление рисками
Форма для идентификации и обработки рисков показана в табл. 1.2. Каждое совещание по проекту должно включать в повестку дня пункт «мозговой штурм с целью выявления рисков». Риск № 1 «Работа с технологией клиент-сервер» связан с возможностями технологии клиент-сервер на языке Delphi. Предположим, что никто в команде не пробовал работать с технологией клиент-сервер. Мы не знаем, легко ли это сделать, трудно или вообще невозможно.
Риск № 2, «нехватка нужных компонентов на Delphi», отражает тот факт, что при разработке базы данных могут понадобиться нестандартные компоненты. Например при выводе информации нам необходимо будет в выводить в сетку(грид) информацию не в одну стоку ячейки, а организовать многострочнось, или же при необходимо отобразить определенные дни на календаре в процеесе выполнения программы жирным. Стандартные компоненты такие как MonthCalendar или StringGrid не могут реализовать данные требования. Мы не знаем, сможем ли мы реализовать на Delphi те возможности, которые имеет в виду заказчик, а если сможем, то сколько это потребует времени. Это обстоятельство может серьезно повредить проекту.
3.4. Механизмы мониторинга и контроля
Вся команда будет встречаться на совещании в начале каждой фазы (определение требований, проектирование, реализация) каждой итерации. Должны проводиться еженедельные совещания по проекту по вторникам с десяти утра до полудня. Следует принять все меры к тому, чтобы на этих совещаниях рассматривались сразу все общие для команды дела. Участники команды должны зарезервировать время по пятницам с 9 до 11 для проведения дополнительных совещаний, если понадобится. Лидер команды должен предупредить участников о проведении дополнительного совещания не позднее 16:30 в четверг.

3.5. План расстановки кадров
Назначение ролей указано в табл. 1.2. Каждый участник команды имеет дополнительные обязанности по резервированию и инспектированию (см. рис. 1.12).

Таблица 1.2. Расстановка участников проекта Комплектации ПВМ

Имя Лидер команды Ответственный за требования Ответственный за проектирование
Лысачев Сергей *
Лысачев Сергей *
Лысачев Сергей *
4. Технический процесс
SRS описывает некоторые аспекты требуемого технологического процесса. Здесь рассматриваются те аспекты, которые не установлены явно в SRS.
4.1. Методы, инструменты и технологии
В проекте АРМ «Регистратура» для проектирования используется Rational Rose, а реализация ведется на языке Delphi. Во всех случаях используется объектно-ориентированный подход. Для документирования используется Microsoft Office настолько широко, насколько это возможно (подробнее см. SRS). Используемая модель процесса описана в разделе 2.1.
4.2. Документация программного обеспечения
См. SQAP, раздел 4.2.

5. Распределение работ, план-график и бюджет
5.1. Распределение работ
Распределение работ показано на рис. 2.3. В нижней строке показано количество человеко-месяцев, приходящихся на данный месяц.


Рис. 1.3. Распределение работ для проекта АРМ «Регистратура».

5.2. Зависимости
Вторая итерация зависит от результатов первой. Инженер Лысачёв занят в проекте, и с вероятностью 50 % он будет недоступен в первый месяц проекта.
5.3. Потребности в ресурсах
В проекте Лысачев Сергей будет выполнять функции инженера, секретаря и один технического специалиста. Аппаратные ресурсы составят один компьютер Pentium 3000 МГц с операционной системой Windows Xp и системой программирования Borland Delphi 7. Компьютер должен иметь не менее 512 Мбайт RAM и не менее 6 Гбайт пространства на жестком диске.
5.4. Выделение бюджета и ресурсов
Оценка до начала анализа требований.
Данная оценка проведена тремя различными методами.
1. С использованием неформальной оценки сверху вниз на основе предыдущего опыта команды по аналогичным проектам.
2. С использованием оценки сверху вниз на основе данных по отрасли.
3. С использованием оценки функционального размера для двух известныхфункций и экстраполяцией результатов на весь проект.........




Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть похожие работы


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