5.5. Планирование работы цехов. Возможность сверстать планы работы в разрезе цехов, суток, смен, оборудования. 5.6. Назначение исполнителей. Возможность для каждой из цеховых работ назначать исполнителей. 5.7. Контроль исполнения и оперативная корректировка планов Возможность контроля исполнения работ над заказами и цеховых планов. Возможность оперативной корректировки планов при возникновении критических ситуаций. 6. Ограничения. Внедрение системы не должно занимать более 3 месяцев. В ядре системы должна быть заложена промышленная СУБД реляционного типа. Все обращения к информации должны осуществлляться через драйвер ODBC. 7. Показатели качества. 7.1. Применимость. 7.1.1. Время, необходимое для обучения обычных пользователей (три рабочих дня (24ч); для обучения продвинутых пользователей - 1 рабочий день). 7.1.2. Время отклика для типичных задач - не более 5с, для сложных задач - не более 20с. 7.2. Надёжность. 7.2.1. Доступность (время, затрачиваемое на обслуживание системы не должно превышать 3% от общего времени работы). 7.2.2. Среднее время безотказной работы - 10 рабочих дней. 7.2.3. Максимальная норма ошибок или дефектов - одна ошибка на 10 000 строк кода. 8. Другие требования к продукту. 8.1. Применяемые стандарты. Система должна соответствовать всем стандартам интерфейса пользователя Microsoft. 8.2. Системные требования. Процессор: не менее 2 ГГц (4 ядра); оперативная память: не менее 4 Гб; жёсткий диск: 2-4 диска (резервные); сетевой адаптер: 100 Мб/с; операционная система: Microsoft Windows Server 2003; СУБД: SQL Server. 8.3. Эксплуатационные требования. Система должна быть способна поддерживать как минимум 15 одновременно работающих пользователей, связанных с общей базой данных, и иметь возможность увеличить их количество на случай увеличения штата сотрудников предприятия (см. пункт 3.2). 9. Требования к документации. 9.1. Руководство пользователя. В системе должны быть представлены руководства пользователей (по типам пользователей). Они должны содержать расшифровку всех используемых терминов, описание основных вариантов использования, включая альтернативные сценарии, а также подробный обзор интерфейса программы. 9.2. Интерактивная справка. Интерактивная справка необходима для разрешения возникших во время работы вопросов. В справке должна быть реализована возможность поиска информации по ключевым словам, а также вариант представления информации по отдельным позициям меню программы. Справка должна содержать максимально полную и подробную информацию о работе системы. 9.3. Руководство по установке и конфигурированию. Файл ReadMe. Система должна иметь руководство по установке в файле README.txt, который должен прилагаться к системе. Файл ReadMe должен содержать подробную инструкцию по установке данной системы, чтобы в случае необходимости пользователь смог произвести установку самостоятельно, без помощи администратора. 10. Маркировка и пакетирование. Система будет распространяться на компакт-диске, на котором будет находиться сама система, а также интерактивная справка, руководство по установке и руководство пользователей. Инсталяционная программа должна включать общее лицензионное соглашение и информацию об авторских правах. Словарь терминов (глоссарий) В простейшем варианте словарь терминов (глоссарий) представляет собой список важных понятий и их определение. Часто наблюдается ситуация, когда технический или другой термин используется заинтересованными лицами в нескольких возможных значениях. Такие противоречия следует устранить для облегчения общения и формулировки требований. В рамках унифицированного процесса словарь терминов также играет роль словаря данных, то есть документа, содержащего информацию о данных. На начальной стадии проекта словарь терминов включает только основные термины и их описание, а на стадии развития желательно превратить его в словарь данных. В этом случае к атрибутам терминов следует отнести: список синонимов, описание термина, формат термина (тип, длина, единица измерения), взаимосвязи с другими элементами, диапазон значений, правила проверки корректности. В словарь терминов заносятся не только простейшие понятия, такие как "цена товара", но и более сложные элементы, например, "продажа", которые, в свою очередь, могут включать в себя другие элементы, такие как "дата", "место", "дата авторизации платежа" и т. д. Документ Delta Vision Документ-концепция требует сопровждения. По мере работы над программным продуктом появляются новые функции, новый взгляд на старые функции и т. д. Не рекомендуется каждый раз создавать новую версию документа концепции и переписывать в неё всё то, что есть в старой версии. Предлагается ввести документ изменений, в котором основное внимание уделено тому, что новое включается в данную версию и чем она отличается от предыдущей. Управление масштабом Проблема масштаба проекта Приступая к разработке приложения, необходимо произвести оценку ресурсов, выделенного времени и поставленных целей. При разработке ПО эти факторы задают масштаб проекта, который определяется следующими переменными: 1) набором функций программного продукта; 2) ресурсами, которыми располагает проект; 3) временем, выделенным на реализацию. р+--------------------------+ е| | с| | у| Масштаб | р| | с| | ы+--------------------------+ Время Срок сдачи Площадь прямоугольника предоставляет достижимый масштаб проекта. Ресурсы в основном состоят из труда разработчиков, тестологов, составителей руководств, сотрудников отдела управления качеством и т. д. Добавление ресурсов в отстающий по времени проект часто приносит отрицательный результат. Объясняется это тем, что обученные ранее сотрудники отвлекаются на консультации для новых работников. Время иногда имеет мягкое ограничение, однако существуют проекты, где оно задано очень строго. Если время и ресурсы определены, то управление масштабом связано только с функциями. Задание масштаба проекта Рекомендуется задать базовый уровень требований. Базовый уровень - это разбитое на элементы множество функций и требований, которые намечено реализовать в данной версии приложения. Он должен быть по крайней мере приемлем для заказчика и иметь приемлемую вероятность успеха с т. з. команды разработчиков. Первым шагом в определении базового уровня является перечисление функций, которые были определены для приложения. Разрабатывается некоторый программный продукт. Допустим, были выделены следующие функции: +---------+-----------------------------------------+-----------+------------+-------+ |№ функции|Функция |Приоритет |Трудоёмкость|Риск | +---------+-----------------------------------------+-----------+------------+-------+ |Ф1 |Поддержка внешней реляционной БД |Критический|средняя |низкий | |Ф2 |Многопользовательская безопасность |Важный |высокая |высокий| |Ф3 |Возможность клонирования проекта |Важный |высокая |средний| |Ф4 |Порт для новой версии операц. системы |Критический|высокая |средний| |Ф5 |Новый "Мастер" проекта |Важный |низкая |низкий | |Ф6 |Импортирование внешних данных по типам |Критический|низкая |высокий| |Ф7 |Реализация средств предупреждения |Полезный |низкая |высокий| |Ф8 |Интеграция с системой управления версиями|Полезный |низкая |низкий | +---------+-----------------------------------------++----------+------------+-------+ 1) Установка приоритетов Первичное определение приоритетов должно производиться заказчиками и пользователями. Технические моменты учитываются позже. Рекомендуется использовать шкалу "критический", "важный", "полезный". Оценка трудозатрат Анализ трудоёмкости Для анализа трудоёмкости используются в основном два метода: 1) метод анализа трудоёмкости проекта (задачи) на основе трудоёмкости известного образца; для применения этого метода в качестве значения трудоёмкости основной работы выбирают данные, характеризующие трудоёмкость изделия-аналога, относительно которого вводят коэффициент сложности новой разработки или его части. сложность программы-аналога или её части принимается за единицу, затем определяют коэффициент квалификации работника (программиста) nv(сл.), который отражает степень его подготовленности к выполнению порученной ему работы; коэффициент квалификации исполнителя nv(кв.) рекомендуется определять в зависимости от его стажа работы: до 2-х лет: 0.8, от 2 до 3 лет: 1, от 3 до 5 лет - 1.1-1.2, от 5 до 7 лет - 1.3-1.4, более 7 лет - 1.5-1.7; q^(new)vi=(q^(old)vj*nv(сл.))/nv(кв.); 2) анализ трудоёмкости на основе экспертных оценок: суть метода заключается в том, что опрашивается несколько экспертов с целью определения длительности работы (этапа работы проекта). Полученные результаты заносятся в таблицу перечня работ: +------+-------------------------+ | | Экспертная оценка | |Работа+------+------+----+------+ tv1=(SIGMA)^kv(i=1)tvi/k | | 1 | 2 |....| k | +------+------+------+----+------+ |rv1 |tv(11)|tv(12)|....|tv(1n)| |rv2 | | | | | tv1=(3tv(min)+2tv(max))/5 | . | | | | | | . | | | | | | . | | | | | | . | | | | | |rvn | | | | | +------+------+------+----+------+ Добавление элементов риска Далее необходимо оценить риск, связанный с каждой функцией. Под риском понимают вероятность того, что разработка функций может оказать негативное воздействие на график и бюджет. Здесь обычно используют классификацию "низкий", "средний", "высокий". Сокращение масштаба Если функция критическая и имеет высокий риск, то нужна эффективная стратегия уменьшения риска. Если функция с высоким риском только полезна, следует рассмотреть вариант её удаления. Если функция важная, но имеет высокий риск, то её можно удалить или разрабатывать в случае, если останется время. Если команда чувствует, что масштаб продукта превышает 100%, следует сокращать список функций. Если масштаб достигает 200%, то следует в базовый уровень включать только критические функции. +--+-----------------------------------+---------+ | | |Приоритет|Трудоёмкость +--+-----------------------------------+---------+ |Ф1|Поддержка вложений PEP |критич. | |Ф4|Порт для новой версии ОС |критич. | |Ф6|Импортирование внешних ... |критич. | |Ф3|Возможность клонирования проекта |важный | +--+-----------------------------------+---------+ | Базовый уровень (отсутс. Важность) | +--+-----------------------------------+---------+ |Ф2|Многопользоват. безопас. |Важный |низкая |Ф5|Новый мастер проекта |Важный |низкая |Ф7|Реализация средств предупреждения |Полезная |низкая |Ф8|Интеграция с подсист. управ. верс. |Полезная |высокая Умение общаться с заказчиком Сокращение масштаба проекта до размеров, сопоставимых с имеющимся временем и ресурсами, может привести к враждебным отношениям между командой проекта и его заказчиками. Для того, чтобы избежать подобной ситуации, следует активно привлекать заказчиков к управлению их требованиями и масштабом проекта. Нужно дать понять заказчику, что сокращение функций позволит создать качественный продукт вовремя. Руководящий принцип при управлении масштабом - меньше обещать и больше делать. Лидер продукта В каждом успешном проекте должен быть лидер. Лидер ставит концепцию продукта во главу угла и постоянно о ней думает. Лидером может быть: менеджер продукта, менеджер информационных технологий, менеджер проектирования, руководитель проекта. В любом случае он должен заниматься следующим: 1) руководить процессом выявления требований; 2) рассматривать конфликтующие пожелания, поступающие от различных участников; 3) находить компомиссы, необходимые для определения набора функций, предоставляющего наибольшую ценность для максимального числа участников; 4) владеть концепцией продукта; 5) защищать интересы продута; 6) вести переговоры с руководством, пользователями и разработчиками; 7) противодействовать "просачиванию" функций; 8) поддерживать здоровое равновесие между тем, что хочет заказчик, и тем, что может сделать команда разработчиков за время, отведенное на реализацию проекта; 9) вызывать в роли представителя, официального канала общения между заказчиком и командой разработчиков; 10) управлять ожиданииями клиентов, дирекции, отдела маркетинга и проектирования; 11) сообщать о реализуемых функциях всем заинтересованным лицам; 12) осуществлять проверку спецификаций ПО, чтобы удостовериться, что они соответствуют функциям концепций; 13) осуществлять управление изменением приоритетов: добавление и удаление функций.