Файл: "Разработка информационной системы менеджера по продажам салона сотовой связи".docx
Добавлен: 25.10.2023
Просмотров: 267
Скачиваний: 9
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Сервисные средства для эксплуатации АРМ включают: ведение классификаторов, генератор отчетных форм, администратора баз данных сетевого доступа, инструментарий для устранения последствий аварий, для приема и передачи данных по каналам связи, для копирования и сохранности информации, мониторинга, а также часы, таймер, калькулятор.
Информационная система, осуществляющая процесс поддержки принятия решения менеджерами, должна обеспечить реализацию целей их деятельности. Одной из наиболее распространенных форм реализации является система взаимосвязанных и взаимодействующих АРМ, в том числе руководителя и исполнителя. Руководителю нужна обобщенная, достоверная и полная информация, позволяющая принимать правильные решения, а также средства анализа и планирования различных сфер деятельности хозяйственного субъекта. К этим средствам относятся методы: экономико-математические, моделирования, анализа различных сфер деятельности, статистические, прогнозирования, а также обеспечивающие технологии – табличные, графические и текстовые процессоры, электронная почта, СУБД.
Специалисту-исполнителю необходим удобный инструментарий для обеспечения профессиональной деятельности в конкретной области, что определяется применяемыми в данной сфере предметными технологиями и разделением обязанностей между управленческими работниками. АРМ данного уровня характеризуется жестким включением в программный продукт функциональных и обеспечивающих технологий, что позволяет использовать специалиста невысокой квалификации, поскольку его действия носят декларативный, а не процедурный характер и глубоких знаний предметной технологии от него не требуется, так как они заложены в АРМ разработчиками программного обеспечения.
1.3. Выбор средств разработки проекта. Решение задач проекта
1.3.1. Требования
Развитие технологии разработки программного обеспечения, методов моделирования, появление CASE-технологий не решило проблему определения и формализации требований к информационным системам, но способствовало возникновению нескольких основных подходов. Необходимость определения требований к информационной системе возникает в следующих случаях: в момент выбора новой информационной системы, при подготовке тендерной документации, при заключении договора на разработку или настройку выбранной информационной системы, при уточнении (детализации) потребностей бизнеса в процессе разработки или настройки системы, а также при необходимости внесения изменений в систему в ходе эксплуатации. В каждом случае перед специалистами предприятия и организации встает задача выбора уровня детализации требований, методов описания, включая формализованное описание с использованием графического моделирования. Выделяют следующие типы требований: бизнес требования, пользовательские требования, функциональные требования, нефункциональные требования. Стоит подробнее рассказать о функциональных требованиях.
Функциональные требования к информационной системе являются только частью общих требований, которые содержаться в техническом задании. Раздел требований к информационной системе технического задания может содержать следующие подразделы:
– требования к функциональным характеристикам
– требования к надежности
– настраиваемость
– условия эксплуатации
– требования к информационной и программной совместимости
– требования к документации
Требования к функциональным характеристикам
В этом разделе должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных. При выборе между объектными и структурными методами следует использовать принцип концептуальной общности, который предполагает следование единой философии на всех этапах ЖЦ. Если предполагается использовать структурное программирование, то и на этапе анализа следует использовать структурный подход, а в случае использования объектно-ориентированных языков разработки – объектный анализ и объектное проектирование. При необходимости структурный и объектный подходы могут использоваться одновременно.
Требования к надежности
В разделе должны быть определены требования к обеспечению надежного функционирования: контроль входной и выходной информации, время и механизмы восстановления после программных и аппаратных отказов. В этом разделе описывается организация системы безопасности, включая подсистемы контроля доступа, шифрования и т. п.
Настраиваемость
Определяются требования к адаптационным возможностям ПО, то есть указывается, какие изменения в методах управления и бизнес-процессах должны быть предусмотрены.
Условия эксплуатации
В этом разделе описывается необходимое обслуживание, которое требуется для работы системы, например, создание резервных копий, реиндексерование баз и т. п., а так же требования к квалификации персонала (пользователей и обслуживающего персонала).
Требования к составу и параметрам технических средств
Указывается необходимый состав технических средств с указанием их основных технических характеристик. Могут указываться требования к помещениям, в которых будет находиться оборудование. В этом разделе указываются требования к переносимости системы.
Требования к информационной и программной совместимости
Требования к информационным структурам на входе и выходе, методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
Требования к программной документации
В этом разделе указывается предварительный состав программной документации, и при необходимости, специальные требования к ней [5].
Еще раз необходимо подчеркнуть, что состав разделов технического задания определяется особенностями проекта, например, в случае внедрения существующей информационной требования к надежности, информационной и программной совместимости, документации и т.п. имеют номинальное значение, поскольку эти характеристики уже заложены в систему и указываются лишь как часть обязательств в рамках контракта, не влияя на фактический объем работ. В случае разработки заказной системы эти требования необходимо учесть при проектировании, они определять состав работ и структуру проекта.
Динамика изменения требований зависит от выбранной модели жизненного цикла, в каскадной модели требования определяются один раз в начале проекта, а в итерационной – уточняются в ходе выполнения проекта. Во втором случае должна быть предусмотрена процедура управления требованиями. Одним из возможных подходов является представление совокупности требований в виде набора атомарных требований – утверждений, между которыми выявляются отношения зависимости. Например, продукт Rational RequsitePro позволяет вести базу данных требований, определять их атрибуты, а так же отношения (трассируемость, иерархические связи). При использовании каскадной модели все требования содержаться в техническом задании, затем они преобразуются в архитектурное решение в техническом проекте, в этом случае процедура управления требованиями упрощается, ведь предполагается, что требования не будут меняться в ходе проекта.
Каковы типичные ошибки при определении требований к информационной системе:
-
неполнота требований (структура). Определяются только часть требований, например функциональные требования, при этом не указываются требования к надежности, производительности, программной совместимости и т.д.. Кроме того, ошибки или неполнота описания бизнес-логики. Описывается только основной поток процесса, а многочисленные альтернативные потоки не исследуются. При этом количество и сложность альтернативных потоков значительно превосходит количество и сложность основных потоков. Пример: фрагмента основного потока процесса: прибыл заказанный товар на склад, количество и номенклатура совпадают с заказанным, товар отправлен покупателю. Для этого потока существует несколько альтернативных потоков: прибыл заказанный товар, но количество отличается от заказанного (варианты, в большую, меньшую сторону), отличается номенклатура товара (отклонения по размеру, цвету, сортности). Проводится согласование с покупателем. Покупатель согласен (не согласен) получить товар в ином количестве (ассортименте). Пример можно продолжить, но наша задача лишь показать сложность и количество альтернативных потоков. Выявление альтернативных потоков важно и по той причине, что мониторинг отклонения процесса от основного потока, сбор статистики, является важной функций управления. -
Избыточность требований встречается так же часто, как и неполнота, как правило, они соседствуют в одном документе. Основные признаки избыточности: описываемые требования реализуются автоматически благодаря используемой технологии разработки или выбранной архитектуре, требования не влияют на архитектуру информационной системы, ее бизнес-логику (например, требования к содержанию данных, вместо требований к структуре и объему информации), требования повторяются многократно в различных частях документа (дублирование). Основная опасность избыточности требований в отвлечении внимания, создании иллюзии полноты выявленных требований.
1.3.2. Средства разработки
Технология создания информационных систем предъявляет особые требования к методикам реализации и программным инструментальным средствам, а именно: