Модели жизненного цикла программных средств. Требования к ПО, страница 8

1.  Ответственного за ее проверку- тестировщик который нашел и проверяет, что исправления сделанные разработчиком действительно устраняют ошибку

2.  Ответственные за ее исправление- разработчик, к которому ошибка направляется для исправления

3.  Состояние- Ошибка найдена, Ошибка исправлена, Ошибка закрыта, Ошибка повторилась

Этот список существенно дополняется в различных программных средствах контроля ошибок. Использование таких систем давно стало практикой разработки по, на равне со средствами версионного контроля и многими другими инструментами, они включают в себя: 1. БД для хранения ошибок 2. Интерфейс к этой БД для внесения новых ошибок и задание их многочисленных атрибутов в целях получения отчетов, выдачи ошибок за конкретный период или все ошибки закрепленные за разработчиком 3. Сетевой доступ- поскольку в разрабатываемых приложениях все чаще оказывается распределенными 4. Программный интерфейс- для возможности программной интеграции одних систем с другим по (конвертеры)

Диаграммные техники в работе со знаниями

Метод случай-использования

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

Задача: Клиенты регистрируются в компании, а потом по телефону в удобное время делают заказ товаров, за которые он расплачивается после доставки товара. Для этого компания организовывает локальный телефонный центр включающий многоканальную АТС, штат операторов и соответствующее по. При этом в компании уже существует ИС обработки заявок и заказываемое по должно быть интегрировано в нее.

Работа с требованиями

Диаграммы использования были предложены в конце 90х годов Якобсоном одним из главных разработчиков UML, диаграммный подход используется для извлечения и первичной формализаций требований к системе. Необходимо извлечь требования из всех возможных источников, формализовать в каком-то виде и обсудить. Этот процесс (извлечение формализации обсуждение) итеративен, более того сам способ формализации должен быть удобен для обсуждения потенциальным пользователям системы, которые абсолютно некомпетентны в IT технологиях их заключение, одобрение и согласие часто является основой итеративного извлечения требований к системе, кроме того методы для реализации этой системы должны вести к созданию моделей удобной в дальнейшей реализации т.е. способ формализации должен быть прост, понятен, и обладать достаточной строгостью, этим требованиям удовлетворяет диаграмма случаев использования являющаяся на сегодняшний день составной частью стандарта UML. Рассмотрим диаграмму случаев использования на примере

1.  Оперативная и сводная статистика 

2.  Справочная информация о клиентах

3.  Разработка запросов

4.  Просмотр текущих заявок

5.  Контроль рабочего времени оператора

 🚶

                                                                                                                                                                                 🚶

🚶

🚶                                                                                                                                           🚶

1.Инсталляция настройка обновление по

2. Настройка ремонт и замена оборудования

3. Администрирование пользователей

4. Доступ к новым заявкам

5. Система обработки заявок

Все начинается с точной идентификации пользователей будущей системы- это основа хороших требований и хорошей системы, т.к. ее основной задачей является- удовлетворять потребности будущих пользователей. В нашем случае пользователи системы являются: Оператор, менеджер и представитель тех поддержки. Система должна поддерживать внешний интерфейс с системой обработки заявок (это 4 пользователь). Еще 1 пользователем системы является Петров- Директор департамента сбыта продукции, который хочет периодически отслеживать деятельность телефонной службы приема заявок. Для него создано специальное пользовательское место с экранными формами статистики. Различные пользователи по отображенные на диаграмме называются актерами. Актеры могут обозначать: 1. Типовых пользователей- группа людей сгруппированные по исполняемым обязанностям 2. Другие системы взаимодействующие с данными (система обработки заявок уже существует) 3. Выделенные пользователи (Петров)