Л.Новиков в русской редакции нотации RUP приводит следующее определение: "Требование – это условие или возможность, которой должна соответствовать система".
В IEEE Standard Glossary of Software Engineering Terminology (1990)
данное понятие трактуется шире. Требование – это:
1) условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3) документированное представление условий или возможностей для пунктов 1 и 2.
Основным источником требований к информационной системе, безусловно, являются соображения, высказанные представителями Заказчика.
Ключевой стратегией выявления требований было и остается интервью с экспертами.Полезными приемами являются формирование программы беседы и ознакомление с ней респондента, подробное планирование беседы вплоть до записи подготовленных вопросов. Подготовленное таким образом интервью называют структурированным. В дополнение к так построенному интервью предлагается проводить неструктурированное интервью, «представляющее собой неформальную встречу, которой не свойственны заготовленные впрок вопросы или заранее поставленные цели». Цель такого интервью – пробудить респондента к креативу в области, в которой интервьюер недостаточно хорошо ориентируется.
Анкетирование – самый малозатратный для аналитика способ извлечения информации, он же – и наименее эффективный. Обычно применяется как дополнение к другим стратегиям выявления требований.
Недостатки анкетирования очевидны: респонденты часто бывают неспособны, либо слабо мотивированы в том, чтобы хорошо и информативно заполнить анкету. Велика вероятность получить неполную или вовсе ложную информацию. Преимущество – в том, что подготовка и анализ анкет требуют небольшой ресурс.
|
|
Наблюдение за работой моделируемой организационной системы – полезная стратегия получения информации.
Различают пассивное и активное наблюдение. При активном наблюдении аналитик работает, как участник команды, что позволяет улучшить понимание процессов.
Через наблюдение, а возможно, и участие аналитики получают информацию о происходящих день за днем операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал документы или разговаривал с экспертами.
Недостатком этой стратегии является то, что наблюдатель, как и всякий «измерительный прибор», вносит помехи в результаты измерений: сотрудники организации, находясь «под колпаком» могут начать вести себя принципиально по-другому, чем обычно.
Документы – хороший источник информации, потому что они чаще всего доступны и их можно «опрашивать» в удобном для себя темпе. Чтение документов - прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам.
Если опытный аналитик уже исследовал большое число систем такого же типа, что и на предприятии внедрения, он обладает фундаментальными знаниями в соответствующей предметной области, относительно определенного класса систем.
|
|
По результатам анализа документов и собственных знаний аналитик может составить описание требований и предложить его представителям Заказчика в качестве информации к размышлению, либо – основы для формирования технического задания.
Недостаток этой стратегии – опасность пропуска знаний, специфичных для объекта исследования (в случае самоопроса), либо – неформализованных знаний, эмпирических правил и процедур, широко используемых на практике, но не вошедших в документы.
Прототипирование– ключевая стратегия выявления требований в большинстве современных методологий. Программный прототип – «зеркало», в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путем прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя дает еще больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный.
В данной работе был использован метод самостоятельного составления требований и прототипирования.
Обычно выделяют три уровня требований.
1) На верхнем уровне представлены так называемые бизнес-требования (businessrequirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия;
2) Следующий уровень – уровень требований пользователей (userrequirements). Пример требования пользователя: система должна представлять диалоговые средства для ввода исчерпывающей информации о заказе, последующей фиксации информации в базе данных и маршрутизации информации о заказе к сотруднику, отвечающему за его планирование и исполнение. Требования пользователей часто бывают плохо структурированными, дублирующимися, противоречивыми. Поэтому для создания системы важен третий уровень, в котором осуществляется формализация требований;
|
|
3) Третий уровень – функциональный (functionalrequirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.
В дальнейшем будет использоваться именно третий уровень.
Функциональные требования регламентируют функционирование или поведение системы (behavioralrequirements). Функциональные требования отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Функциональные требования записываются, как правило, при посредстве предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные". Другим способом являются так называемые варианты использования (userscases) – популярный и весьма продуктивный способ представления требований.
В качестве требований к тестируемой информационной системе были взяты следующие показатели:
1) возможность просмотра отчётов о состоянии домов;
2) возможность добавления информации о домах;
3) возможность удаления информации о домах;
4) возможность изменения информации о домах.
ИНДИВИДУАЛЬНОЕ ЗАДАНИЕ
В ходе практики было произведено исследование методов и технологий проектирования, разработки и тестирования программного обеспечения. В результате было созданы модель классов и структуры базы данных и программное средство. Разработка велась с использованием технологий Java, H2DB/JDBC. В качестве способа организации модулей была использована модель Model-Service-Controller-View. Она подразумевает, что программа делится на 4 уровня.
1) Model – отображает структуру базы данных на уровне программы.
2) Service – используется для работы с данными: чтение, запись, изменение, удаление, поиск.
3) Controller – модуль, отвечающий за все операции, производимые в программе. Именно здесь реализуются все основные алгоритмы.
4) View – модуль-интерфейс, отвечающий за отображение программы пользователю в виде графического или консольного приложения.
На рисунке 2 изображена модульная структура программы. Классы BaseHall.class и BaseEntity.class являются предками для классов Room.class, Flat.class, Floor.class, Entrance.class, House.class. Вместе эти классы представляют собой Model. Класс Service.class отвечает за операции над данными и представляет собой Service. Класс Controller.class отвечает за выполнение основных операций и алгоритмов и является Controller. Класс View.class отвечает за отображение интерфейса конечному пользователю и представляет собой View. Класс Main.class служит инициализатором программы – с него начинается выполнение программы.
На рисунке 3 изображена структура базы данных для данного программного средства.
Рисунок 2 – диаграмма классов
Рисунок 3 – диаграмма «сущность-связь»
Данная программа позволяет через консоль просматривать, изменять, добавлять и удалять информацию о домах, а также выводить отчёт об итоговом состоянии домов.
На рисунках 4 и 5 изображена работа программы с точки зрения пользователя.
Рисунок 4 – главное меню
Рисунок 5 – пример отчёта
ЗАКЛЮЧЕНИЕ
В ходе производственной практики былиполучены навыки по разработке и тестированию программных средств на реальном производстве. Были описаны функциональные требования к разрабатываемому программному продукту. Основной целью программы является обработка информации: отображение, добавление, изменение и удаление данных.
Был написан прототип программы.
В процессе тестирования прототипа было реализовано 5 тест-кейсов, которые показали основные ошибки программы, на что стоит обратить внимание. По результатам тестирования был сформирован план по исправлению ошибок.