Рисунок 1.6 - Диаграмма DFD «Отпуск товара»

Рассмотрим следующую диаграмму потоков данных «Оформление товара» (смотри рисунок 1.7). Здесь показано процесс выполнения работ и движение документов при «отпуске товара».

Рисунок 1.7 - Диаграмма DFD «Оформление товара»

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

Организационная структура предприятия, занимающегося продажей махровых изделий, рассмотрена на примере компании ОАО “Донецкая Мануфактура М” магазина Cleonelly:

В направлении разработки систем контроля и учета материалов могут успешно решать проблемы:

1. Это контроль за поставляемыми и хранящимися на складе товарами.

2. Информацию о поставщиках и потребителях

3. Также содержится информация информация и операции по товару

4. Содержится журнал отчета отпущенного товара

5. Содержится справочник товаров

6. Автоматизация складских функций (приход, расход, списание, резервирование товара)

7. Регистрация и хранение счетов на приобретаемый и продаваемый товар и за услуги, а также выписка счетов по предоплате, с отсрочкой платежа и с доставкой товара

8. Создание накладных и учет выданного товара

9. Проведение инвентаризации складов с созданием сличительной ведомости, акта недостачи и излишек

10. Создание комплектов товаров

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

При проектировании информационной системы (ИС) «АРМ Оптового Магазина», было необходимо собрать требования, которые помогли бы создать интерфейс таким образом, что конечному пользователю (работнику магазина) было удобно работать с разработанной ИС.

Разработка требований - это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований.

Для реализации процесса автоматизация учета и контроля материалов необходимо, чтобы информационная система могла выполнять следующие функциональные требования:

ѕ документирование результатов.

ѕ сохранить данные в базе;

ѕ рассчитать количество материала на складе;

ѕ Информационная система должна быть реализована как программа на базе интегрированной среды Visual Fox Pro.

Работа программы осуществляется в операционной системе Windows 2000/NT/XP.

Различают четыре основных этапа процесса разработки требований (рисунок 1.8):

- анализ технической осуществимости создания системы;

- формирование и анализ требований;

- специфицирование требований и создание соответствующей документации;

- аттестация требований.

Сбор требований является важным этапом проектирования ПО, поскольку именно здесь все требования заказчика должны быть правильно, и корректно сформулированы.

Определение корректных требований -- это, наверное, самый ответственный этап программного проекта. Очень важно, чтобы формат проекта соответствовал требованиям к ПО, собранным командой разработчиков, в противном случае эти требования не смогут быть поддержаны и представлены в программном продукте. Спецификация требований к ПО - Software Requirements Specification(SRS) имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний. Аттестация -- это оценка качества работы менеджеров проекта. Она определяет степень соответствия программного продукта установленным требованиям. Спецификация SRS выступает в роли некоего механизма фиксирования системных требований, которые используются в качестве критериев при аттестации .

На основании SRS достигается согласие между заказчиками и производителями программного продукта. В спецификации SRS полностью описаны функции, которые должен выполнять разрабатываемый программный продукт. Это позволяет потенциальным пользователям определить степень соответствия продукта их потребностям, а также пути модификации продукта для того, чтобы он был максимально полезен в решении их задач.

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

При тщательном изучении требований, представленных в спецификации SRS, можно обнаружить недосмотры, недоразумения и противоречия еще на ранних этапах цикла разработки, когда проблемы устранять гораздо легче, чем на более поздних этапах.

Спецификация SRS становится основой для оценки стоимости и составления графика работ. Описание продукта -- это реальный базис для оценки стоимости проекта. В среде, где существует понятие формального предложения, SRS используют для утверждения оценки предложения или цены.

С помощью правильно составленных спецификаций SRS на уровне организации могут разрабатывать намного более продуктивные планы аттестаций и проверок. Являясь частью договора на разработку, SRS обеспечивает точку отсчета для оценки соответствия техническим условиям.

Благодаря спецификации SRS облегчается передача программного продукта новым пользователям, а также его установка на других компьютерах. Таким образом, заказчикам становится проще переносить программный продукт в другие подразделения организации, а разработчикам -- передавать другим заказчикам.

Спецификация SRS служит основой для модернизации. В этом документе рассматривается сам продукт, а не процесс разработки проекта, поэтому на ее основании можно производить расширение завершенного продукта.

После того как процесс определения и спецификации требований завершён, необходимо осуществить аттестацию требований.

Спецификация требований к программному проекту должна быть представлена в приложении А.

Аттестация должна продемонстрировать, что требования действительно определяют ту систему, которую хочет иметь заказчик. Проверка требований важна, так как ошибка в спецификации требований могут привести к переделке системы и большим затратам, если будут обнаружены во время процесса разработки системы или после введения её в эксплуатацию.

Во время процесса аттестации требований должны быть выполнены различные типы проверок документации требований:

Проверка правильности требований.

Проверка на непротиворечивость.

Проверка на полноту.

Проверка на выполнимость.

Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности:

Обзор требований.

Прототипирование.

Генерация тестовых сценариев.

Автоматизированный анализ непротиворечивости.

Наиболее наглядным для заказчика системы является прототипирование.

Перед началом создания прототипов можно создать диаграмму потоков пользовательского интерфейса. Такая диаграмма используется для изучения взаимосвязей между основными элементами пользовательского интерфейса.

Следующим шагом аттестации требований является непосредственное создание прототипов.

Прототип ПО - это частичная или возможная реализация предлагаемого нового продукта. Прототипы позволяют решать три основные задачи: прояснение и завершение процесса формулировки требований, исследование альтернативных решений и создание конечного продукта.

Прототип основного меню данного модуля представлен на рисунке 1.9.

Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. Пи этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.

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

принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;

принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными, среди которых являются следующие:

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы. [35]

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

Архитектура информационной системы организации представляет собой модель того, как информационная технология будет поддерживать основные цели и стратегию развития автоматизируемого объекта. Она позволяет критически мыслить и ясно выразить представление того, как интегрированные наборы информационных систем должны быть структурированы для реализации этих целей. Архитектура информационной системы описывает, как информационные системы, приложения и люди работают в пределах всей организации в единообразной объединенной манере.

Таким образом, архитектура информационной системы включает в себя общепринятый набор компонентов, которые обеспечивают «строительные блоки» информационной системы. Эти «строительные блоки» и их характеристики определены на соответствующем уровне деталировки для соответствия потребностям, производимым планировочным решениям.

При проектировании современных информационных систем организаций их архитектура должна разрабатываться с учетом многих заинтересованных сторон, она должна быть понятной пользователям, дать возможность разработчикам сделать план и графики системы, позволять определять ключевые интерфейсы, функции и технологии, а также позволять оценить график и бюджет исполнения проекта. При этом от архитекторов современных информационных систем требуется ответственность за создание удовлетворительной и осуществимой концепции системы на самом раннем этапе ее разработки, поддержки цельности этой концепции на протяжении разработки и определения пригодности результирующей системы для использования клиентом. С другой стороны, разработка архитектуры информационной системы - это процесс описания архитектур информационных систем в достаточной деталировке, чтобы сделать их более полезными для разработки информационных систем.

Страницы: 1, 2, 3, 4, 5