Добавлен: 25.10.2018
Просмотров: 4563
Скачиваний: 12
66
перехода. Первая итерация будет состоять только из анализа и планирования требований, вторая ите-
рация будет первой в серии итераций проектирования. Это составит первую версию проекта. Количе-
ство последующих итераций и состав версии 2 будут определены после того, как заказчик ознако-
мится с первой версией.
2.2. Организационная структура
Организационная структура проекта в рамках ЮГУ представлена на рис. И.1. Проект органи-
зован как команда равных с назначением ролей. Роли следующие: лидер команды, ответственный за
конфигурацию, ответственный за качество, ответственный за требования, ответственный за проекти-
рование и ответственный за реализацию. Кроме того, имеется роль ответственного за связи с отделом
маркетинга и с лабораторией технологий программирования. Все эти роли показаны на рис. И.2. В
проекте будет проводиться инспектирование всей работы, как это определено в SQAP. Каждый уча-
стник команды будет проводить инспектирование работы других участников (см. рис. И.2).
Рис. И.1. Организационная структура
Рис. И.2. Организация проекта ИСС.
2.3. Организационные рамки и взаимосвязи
[Указывают людей и организации, с которыми должна взаимодействовать команда.]
Команда проекта должна взаимодействовать со следующими людьми и организациями: отдел
разработки, отдел маркетинга, лаборатория информационных технологий, внешние эксперты и лабо-
ратория технологии программирования.
2.4. Ответственность за проект
Ответственность участников проекта показана в табл. И.1. Ответственность за документ под-
разумевает следующее:
документ должен быть создан вовремя;
лидер команды определяет, кто пишет документ;
документ поддерживается в актуальном состоянии.
Таблица И.1.
Ответственность участников проекта
Участ-
ник
Лидер
команды
Ответствен-
ный за кон-
фигурацию
Ответствен-
ный за каче-
ство
Ответствен-
ный за тре-
бования
Ответствен-
ный за проек-
тирование
Ответствен-
ный за реали-
зацию
Отвеча-
ет за
связь
Отдел
разработ-
ки
Отвеча-
ет за
доку-
мент
SPMP SCMP SQAP
SRS
SDD
Листинги
кода
3. Управляющий процесс
3.1. Цели и приоритеты
[Устанавливается относительный приоритет расписания, бюджета и возможностей приложения.
Возможности подразделяются на степень выполнения требований, уровень качества и пригодность
для повторного использования. Повторное использование должно предусматриваться требования-
ми.]
Высший приоритет имеет достижение заданного уровня качества. На втором месте по при-
оритетности стоит выполнение проекта в срок. Третий приоритет имеет выполнение максимального
количества требований. Четвертый приоритет имеет создание классов, которые можно повторно ис-
пользовать в других аналогичных проектах.
3.2. Допущения, зависимости и ограничения
[Перечисляются предположения и допущения о внешних по отношению к проекту событиях, кото-
рые могут повлиять па проект.]
Нет.
3.3 Управление рисками
[Следует определить риски как конкретные неприятности, которые могут произойти. Нельзя огра-
ничиваться общими фразами. Например, утверждение «недостаточные навыки программирования
67
на Java» само по себе не описывает суть проблемы. Иногда проект можно успешно выполнить и с
недостаточными навыками.]
Информация об идентификации и обработки рисков заносится в табл. И.2. Каждое совещание
по проекту должно включать в повестку дня пункт «мозговой штурм с целью выявления рисков».
Риск № 1 - недостаточные навыки программирования на Java, отражает тот факт, что 40 %
команды не имеют достаточного опыта программирования на Java. Принимая этот факт, следует при-
знать, что данный фактор серьезно затормозит проект, но поскольку не все в команде должны про-
граммировать, ущерб оценивается числом 6. Стоимость устранения риска высока, поскольку нужно
затратить много времени на обучение с отвлечением от работы, так что полагаем ее равной 8.
Риск № 2 …
Таблица И.2
Идентификация и обработка рисков
№
п
/
п
Название
Вероятность
возникновения
риска, 1-10 (1 -
маловероят-
ный)
Ущерб,
1-10 (1 -
наимень
ший)
Стоимость
устранения,
1-10 (1 -
низкая)
Итого-
вый
при-
оритет
План
устра-
нения
(умень
шения)
Ответст-
венный за
исправле-
ние
Дата
завер-
шения
1
недоста-
точные
навыки
програм-
мирова-
ния на
Java
9 6
8
(11-
9)*(11-
6)*8=8
0
Изуче-
ние ли-
терату-
ры:
Java 2.
Биб-
лиотека
профес
сиона-
ла. Ос-
новы
А. Мели-
хов
09.09.0
9
2 …
…
…
…
…
…
…
…
3.4. Механизмы мониторинга и контроля
Вся команда будет встречаться на совещании в начале каждой фазы (определение требований,
проектирование, реализация) каждой итерации. Должны проводиться еженедельные совещания по
проекту по вторникам с десяти утра до полудня.
3.5. План расстановки кадров
Назначение ролей указано в табл. И.3. Каждый участник команды имеет дополнительные обя-
занности по резервированию и инспектированию (см. рис. И.2).
Таблица И.3
Назначение ролей участников проекта
ФИО
Лидер
проекта
Ответст-
венный
за кон-
фигура-
цию
Ответствен-
ный за каче-
ство
Ответственный
за требования
Ответственный
за проектирова-
ние
Ответственный
за реализацию
А. Мелихов
X
X
А. Мелихов
X
А. Мелихов
X
А. Мелихов
X
А. Мелихов
X
68
Осуществля-
ет связь с
Отдел
разработ-
ки
Отдел маркетин-
га
Лаборатория
информацион-
ных технологий
и управления
4. Технический процесс
[В этом разделе описывается технология, используемая в проекте, но только в тех аспектах, кото-
рые не являются спецификацией требований.]
SRS описывает некоторые аспекты требуемого технологического процесса. Здесь рассматри-
ваются те аспекты, которые не установлены явно в SRS.
4.1. Методы, инструменты и технологии
В проекте для проектирования используется Rational Rose, а реализация ведется на языке Java.
Во всех случаях используется объектно-ориентированный подход. Для документирования использу-
ется Javadoc (подробнее см. SRS). Используемая модель процесса описана в разделе 2.1.
4.2. Документация программного обеспечения
См. SQAP, раздел 4.2.
4.3. Функции сопровождения проекта
На все время проведения проекта будет привлечен на полставки технический специалист по
поддержке инструментов.
5. Распределение работ, план-график и бюджет
5.1. Распределение работ
Распределение работ показано на рис. И.3. В нижней строке показано количество человеко-
месяцев, приходящихся на данный месяц.
Рис. И.3. Распределение работ по проекту
5.2. Зависимости
[В этом разделе показываются взаимозависимости различных работ. Данный раздел должен быть
пересмотрен после проектирования.]
5.3. Потребности в ресурсах
[Проводится оценка стоимости разработки первых трех версий продукта.]
В проекте будут заняты семь инженеров, один секретарь на полставки и один технический
специалист на полставки.
Аппаратные ресурсы составят восемь компьютеров с процессором Intel Core 2 3,0 ГГц и опе-
рационной системой Windows Vista и системой программирования Symantec Visual Cafe версии 3.0.
Каждый компьютер должен иметь не менее 2 Гбайт RAM и не менее 16 Гбайт свободного простран-
ства на жестком диске.
5.4. Выделение бюджета и ресурсов
[В этом разделе определяется, как расходуются выделенные средства. Смете предшествует оценка
стоимости. По мере продвижения проекта оценка стоимости уточняется.]
Оценка до начала анализа требований.
Данная оценка проведена тремя различными методами.
1. С использованием неформальной оценки сверху вниз на основе предыдущего опыта команды по
аналогичным проектам.
2. С использованием оценки сверху вниз на основе данных по отрасли.
3. С использованием оценки функционального размера для двух известных функций и экстраполяци-
ей результатов на весь проект.
Результаты приведены в табл. И.4 (все величины даны в тысячах строк исходного кода на языке
Java).
Таблица И.4
Предварительная оценка размера приложения до анализа требований
Метод
Минимум Максимум
Комментарий
1 7,5
170
2 4,2
300
3 11,4
46
1,9-2,3 для двух функций, умно-
женные на 6-20 по числу функ-
ций всего приложения
69
5.5. План-график
[В настоящем разделе приводится итоговая версия плана-графика. Структура плана-графика
должна соответствовать выбранной модели жизненного цикла проектируемой системы.]
План график приведен на рис. И.4. См. также SQAP (приложение Ж), где приведен план-
график мероприятий по контролю качества.
1-ая итерация
2-ая итерация
Буферный период
Рис. И.4. Диаграмма задач для проекта при условии фиксированной даты поставки
6. Дополнения
6.1. Указатель
6.2. Приложения
70
ПРИЛОЖЕНИЕ К
(справочное)
IEEE 830-1993 СПЕЦИФИКАЦИЯ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
(SOFTWARE REQUIREMENTS SPECIFICATION – SRS)
Утверждаю
Дата
02.02.09 А. Мелихов: исходный черновик
03.04.09 А. Мелихов: проверка технической точности; изменения текста
04.07.09 А. Мелихов: проверка всего документа, небольшие улучшения
06.15.09 А. Мелихов: перемещение вариантов использования в раздел 2.2
06.23.09 А. Мелихов: окончательное форматирование
06.23.09 А. Мелихов: выпуск
1. Введение
1.1. Цель
[В разделе отражается цель данного документа в целом (а не цель программы)]
Этот документ предоставляет все требования для проекта. Части 1 и 2 предназначены пре-
имущественно для заказчиков приложения, но также будут интересны инженерам-разработчикам,
разрабатывающим или поддерживающим его. Часть 3 предназначена в основном для разработчиков,
но также представляет некоторый интерес и для заказчика.
1.2. Область применения
[Аспекты программы, которые должен охватить этот документ]
Этот документ охватывает требования к версии 0.01 информационно-справочной системы
учебно-методических материалов (ИСС УММ).
1.3. Определения, термины и сокращения
С-требование – cводка требований к приложению, сформулированных в форме, понятной клиенту.
D-требование – cводка требований к приложению, сформулированных достаточно четко для исполь-
зования программистами при проектировании и реализации. По возможности D-требования должны
быть также понятны и клиенту
1.4. Ссылки
План управления конфигурациями программного обеспечения (SCMP) для ИСС, версия 1.0.
Архитектура программного обеспечения (SDD) для ИСС, версия 1.2.
План управления программным проектом (SPMP) для ИСС, версия 1.2.
План контроля качества (SQAP) для ИСС, версия 1.0.
План пользовательской документации (SUDP) для ИСС, версия 1.0.
1.5. Обзор
Обзор будет проведен в разделе 2.
2. Общее описание
[В данном разделе проектируемая система описывается с точки зрения ее назначения в целом. Это
описание необходимо сделать достаточно общим, чтобы оно несущественно изменялось в будущих
версиях. Кроме того, здесь же перечисляются общесистемные и отраслевые требования к систе-
мам заданной класса.]
Информационно-справочная система учебно-методических материалов (УММ) предназначена
для обеспечения доступа во внутренней сети организации к следующей информации об УММ, хра-
нящейся в базе данных сервера (ФИО автора, название, раздел знаний, год издания, количество стра-
ниц, аннотация), а также для организации доступа пользователей к файлам УММ, хранящимся на
сервере. Пользователь системы с помощью web-интерфейса может проводить поиск в базе данных по
полям «автор» или «название-аннотация» и копировать на свой носитель файлы найденных УММ из
серверного хранилища. Кроме того, пользователь может загружать в специальный каталог сервера
файлы УММ, отсутствующие в БД, для последующей их обработки администратором. Администра-
тор системы с помощью web-интерфейса может: (i) проводить поиск записей, заносить новые записи
в базу данных, редактировать их и удалять; (ii) размещать файлы, загруженные пользователем, в со-