Курсовая + программа на тему Учет выполненных работ

РЕФЕРАТ

Отчет 41 с., 22, 4 ч., 22 табл, 3 рис., 2 источника.
Перечень ключевых слов: требования, атрибуты, RequisitePro, представление, матрицы связей требований, use case, варианты использования.
Объектом разработки являются требования к программной системе "Учет выполненных работ".
Цели исследования:
1. Рассмотрение средства RequisitePro, его возможностей.
2. Формирование требований к программной системе.
3. Формирование матриц связей требований.
В процессе работы проводилась разработка проекта в формате программы RequisitePro. Данный проект может использоваться для последующей разработки программной системы.
Программный продукт находится на стадии выработки спецификаций.
Внедрение разрабатываемого продукта возможно на строительных предприятиях среднего размера.
Представленные требования могут применяться в области разработки программного обеспечения.
Значимость работы заключается в том, что использование средств управления требовниями может существенно упростить и ускорить процесс разработки ПО.




СОДЕРЖАНИЕ
ВВЕДЕНИЕ 3
1. ОСОБЕННОСТИ (FEATURES) 5
1.1. Нефункциональные особенности 5
1.2. Функциональные особенности 6
2. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ 8
2.1. Формы приложения (FORM) 8
2.2. Поля форм приложения (FLD) 10
2.3. Запросы 31
3. ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ (USE CASES) 33
4. МАТРИЦЫ СВЯЗЕЙ ТРЕБОВАНИЙ 36
4.1. Связи между Use Cases 37
4.2. Связи между Use Cases и особенностями 38
4.3. Связи между Use Cases и формами приложения 39
ЗАКЛЮЧЕНИЕ 40
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 41


ВВЕДЕНИЕ
Организации, которые применяют высококачественные процессы разработки требований получают массу преимуществ. Одно из них - уменьшение объема переделок в течение последней стадии разработки и на протяжении всего длительного периода обслуживания продукта. Эффективность качественных требований не очевидна, и многие люди ошибочно считают, что время, которое тратится на обсуждение требований, просто отсрочивает выпуск продукта. При завершении проекта становится особо ясной ценность приемов повышения качества на ранних стадиях [1].
Целью данной работы является формирование требований к программной системе, в которой формируется журнал учета выполненных работ и акт о приемке работ.
Основными задачами являются:
1. Фомирование требований use case (вариантов использования).
2. Формирование требований к формам приложения.
3. Формирование требований к полям, расположенным на формах и в базе данных.
4. Формирование требований относительно функциональных и нефункциональных особенностей использования системы.
5. Формирование представлений (View).
6. Формирование матриц связей требований.
Для решения задачи "Формирование требований use case" мы будем использовать стандартный тип требований, определенный в RequisitePro - UC (Use Case), со стандартными атрибутами.
Для формирования требований к полям и типам данных в БД необходимо будет определить пользовательский тип требований с пользовательскими атрибутами, т.к. стандартные шаблоны RequisitePro не содержат подобных типов.
Определим атрибуты такого требования FLD (Поле).
Атрибуты данного поля следующие:
1. Статус (возможные значения: Предложено, Утвеждено, Реализовано).
2. Ответственный (текстовое значение).
3. Тип поля на форме (возможные значения: Текстовое поле, Числовое значение, Поле с маской, Выпадающий список, Список выбора, Многострочное поле). В случае, если атрибут не указан, подразумевается что поле присутствует только в базе данных.
4. Тип значения в базе данных (возможные значения: Строка, Целое число, Дата, Денежный)
5. Длина поля (числовое значение).
6. Маска ввода (строка).
7. Название поля в БД (строка). Атрибут необходим в случае, если будет использоваться база данных, не поддерживающая кириллические кодировки.
8. Обязательность поля (да/нет).
9. Уникальность поля (да/нет).
10. Автоинкремент (да/нет).
Для формирования требований к формам приложения также необходимо определить пользовательский тип требований. Мы определили тип FORM со следующими атрибутами:
1. Вид формы (в столбец, ленточная, табличная).
2. Приоритет (высокий, средний, низкий).
3. Статус (аналогично предыдущему требованию).
4. Стоимость реализации (числовое поле).
5. Сложность (средняя, высокая, низкая).
6. Стабильность (высокая, средняя, низкая).
7. Ответственный (текстовое поле)
Для определения запросов к базе данных создадим тип требования Запрос (Query). Основным его свойством является свойство Тип запроса (выборка, умножение, суммирование).
После изучения представленного документа "Журнал выполненных работ", мы выяснили, что заполнение данного документа целесообразно разделить на следующие этапы.
1. Заполнение справочника контрагентов.
2. Заполнение справочника объектов.
3. Заполнение справочника видов работ.
4. Заполнение справочника договоров подряда.
5. Заполнение справочника единичных расценок.
6. Заполнение справочника единиц измерения.
7. Формирование актов приемки выполненных работ на основе данных, введенных в справочнике, и заполнение дополнительных полей документа.
8. Формирование журнала выполненных работ на основе данных из актов приемки выполненных работ.
Данные этапы отражены в одноименных use case требованиях.
При заполнении таблицы "Акт выполненных работ" в базу данных должны вноситься только ссылки на соответствующие строки в таблицах "Контрагенты", "Объекты", "Виды работ", "Договора подряда", "Единичные расценки", "Единицы измерения". Это необходимо для того, чтобы избежать избыточности данных (данные по контрагентам и объектам могут дублироваться в различных строках таблицы, и нет необходимости вводить их каждый раз заново).
Таким образом, для хранения данных можно использовать семь таблиц в базе данных - "Контрагенты", "Объекты", "Виды работ", "Договора подряда", "Единичные расценки", "Акты выполненных работ", "Журнал выполненных работ".
Следовательно будут использоваться соответствующие формы для вода данных в эти таблицы.
Внесение данных в "Журнал выполненных работ" должно производиться на основании данных из документов "Акт выполненных работ".

1. ОСОБЕННОСТИ (FEATURES)
1.1. Нефункциональные особенности