Описание модели предметной области средствами системы 1с это

Обновлено: 04.07.2024

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

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

К моделям предметных областей предъявляются следующие требования:

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

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

Структурный аспект предполагает построение:

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

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

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

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

Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.

Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

  • время решения задач;
  • стоимостные затраты на обработку данных;
  • надежность процессов;
  • косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.

Для расчета показателей эффективности, как правило, используются статические методы функционально- стоимостного анализа ( ABC ) и динамические методы имитационного моделирования .

В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне ( определении требований ), на концептуальном уровне ( спецификации требований ) и внутреннем уровне ( реализации требований ). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций , событий, организационных единиц , технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований , логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации.

Объектная структура

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

На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.).

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

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 25.02.2016
Размер файла 3,6 M

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Курсовая работа

Разработка предметно-ориентированной конфигурации «Управленческий учет в ИТ-компании» на платформе «1С: Предприятие 8.3»

Введение

прикладной алгоритм учет

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

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

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

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

Целью выполнения курсовой работы является разработка конфигурации, которая позволит автоматизировать процесс управления в ИТ организации, реализовать основные задачи, минимизировать количество ошибок сотрудников, тем самым повысив качество обслуживания клиентов.

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

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

1. Функциональный анализ предметной области

1.1 Теоретические основы проектирования прикладных решений на платформе «1С: Предприятие 8.3»

Термин «1С: Предприятие» обозначает систему ПО, в которую входят и платформа, и наборы прикладных решений (разного масштаба и разной отраслевой специфики), а также различных методик. Поэтому как про средство разработки правильно говорить именно про платформу «1С: Предприятие». Как и для многих современных платформ, для «1С: Предприятия» трудно провести определенную границу между собственно инструментом разработки и «исполняющей системой», поскольку они образуют единое целое. Фактически платформа и есть средство разработки, но работает она как на этапе создания программ, так и при их выполнении [2].

Платформа «1С: Предприятие» содержит такие инструменты для выполнения поставленных задач, как визуальное описание структур данных, написание программного кода, визуальное описание запросов, визуальное описание интерфейса, описание отчетов, отладка программного кода, профилирование. В ее составе: развитая справочная система, механизм ролевой настройки прав, инструменты создания дистрибутивов, удаленного обновления приложений, сравнения и объединения приложений, ведения журналов и диагностики работы приложения, создания Web-приложений и приложений для КПК, а также поддержка коллективной разработки, версионирования и пр.

Разработка в «1С: Предприятии» строится на основе общей модели работы приложения, предлагаемой платформой «в обязательном порядке», т.е. основные и наиболее сложные архитектурно-технологические решения (такие, как механизм трехуровневой архитектуры, вопросы взаимодействия компонентов, аутентификация пользователей и т.д.) предлагаются разработчикам в готовом виде.

Проанализируем особенности платформы «1С: Предприятие» с точки зрения критериев выбора средства разработки. Прежде всего, ее использование стоит рассматривать для решения тех задач, для которых оно предназначено, - автоматизации управления и учета. Конечно, есть и весьма успешные случаи нестандартного применения системы для других областей, но не будем на них отвлекаться. Далее, важный критерий выбора между «1С: Предприятием» и универсальными средствами разработки - по нашему мнению, оценка затрат на разработку и сопровождение системы. При этом затраты вполне можно оценить количественно. Скорость разработки в «1С: Предприятии» обычно выше в 2-10 раз и стоимость соответственно в разы ниже.

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

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

1.2 Управленческая характеристика предметной области конфигурирования

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

Простота и удобство работы сделают данную конфигурацию незаменимым помощником в любой IT-структуре.

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

Основные возможности:

· Заказы поставщикам, контроль их оплаты и поставки;

· Соглашение на предоставление сервиса;

· Возможность формирования аналитических отчетов;

· Формирование счетов на оплату;

· Количественный и суммовой учет номенклатуры по материально-ответственным лицам;

· Возможность вести учет сразу по нескольким организациям;

· Проведение обслуживания, как собственными силами, так и силами сторонних организаций;

· Оплата и контроль услуг сторонним организациям за ремонт и обслуживание;

· Обслуживание на рабочем месте, где произошла проблема и отражение этого факта в программе;

· База клиентов, поставщиков.

1.3 Проектирование комплекса функциональных подсистем конфигурации

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

Рис. 1. Подсистемы

Первая подсистема называется «SLA» (Рис. 2).

Здесь мы можем просмотреть базу предоставляемых сервисов. Принимаем заказы на определенный сервис и здесь же выписываем счета на оплату. В этой подсистеме доступны все аналитические отчеты.

Вторая подсистема называется «Заказы поставщикам» (Рис. 3).

Рис. 3. Поставщики

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

Третья подсистема называется «Сотрудники» (Рис. 4).

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

Четвертая подсистема называется «Техническая поддержка» (Рис. 5).

Рис. 5. Поддержка

Самая объемная подсистема. В ней отражаются сведения о сервисах, клиентах, об их покупках, а также остатков материалов в организации. Доступны все аналитические отчеты.

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

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

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

Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, - образует объектное ядро предметной области , которое имеет онтологический статус. Нельзя получить в ИС ответ на вопрос о том, что ей неизвестно. Термин объект является первичным, неопределяемым понятием. Синонимами термина " объект " являются "реалия, сущность, вещь". Однако термин сущность понимается нами несколько уже, как компонент модели предметной области , т.е. как уже выделенный на концептуальном уровне объект для базы данных . Таким образом, выделяемые в предметной области объекты превращаются аналитиками (а не проектировщиками базы данных ) в сущности. Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации набора его свойств. Сущность является результатом абстрагирования реального объекта, т.е. в нашем контексте имеет гносеологический статус. Хотя далее в контексте сущность нередко отождествляется с объектом.

На рис. 2.1 представлен один из подходов к классификации объектов предметной области .


Рис. 2.1. Классификации объектов предметной области

Примерами сущностей (с точки зрения ИС) или объектов (с точки зрения внешнего мира) являются отдельный студент, группа студентов, аудитория, время занятий, слова, числа, символы. Обычно считается, что быть объектом - это значит быть дискретным и различимым. Примеры "не-объектов" - это мир, время, смысл, хотя и такие категории могут сохраняться в базе данных.

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

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

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

Пример. Рассмотрим высказывание: Студент Иванов А.А, родился в 1982 году. Оно выражает следующие свойства объекта "Иванов А.А.":

  • в явном виде - год рождения;
  • в неявном - принадлежность к студентам.

Первое свойство устанавливает связь между объектами "Иванов А.А." и "Год рождения", а второе - между объектами "Иванов А.А." и "Множество студентов". Формализация этого высказывания представляется как результат присваивания значений переменным, входящим в предикаты:

ЯВЛЯЕТСЯ СТУДЕНТОМ (Иванов А.А.)

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

На рис. 2.2 представлен один из подходов к классификации ситуаций в рамках предметной области .


Рис. 2.2. Классификация ситуаций предметной области

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

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

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

Введем определение предметной области .

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

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

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

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

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

4.2. Анализ предметной области (анализ осуществимости, бизнес - моделирование)

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

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

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

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

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

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.

Анализ осуществимости

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

  1. Отвечает ли система бизнес-целям организации-заказчика и организации-разработчика?
  2. Можно ли реализовать систему, используя известные технологии и не выходя за пределы заданной стоимости и заданного времени?
  3. Можно ли объединить систему с другими уже эксплуатируемыми системами?

Для ответа на первый (и главный) вопрос нужно опросить заинтересованных лиц, например, менеджеров подразделений, в которых будет использоваться система, для выяснения того,

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

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

Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.

Вопросы, которые ему стоит задать, это:

  1. Почему вообще пошла речь о создании системы?
  2. В чём Вы видите её назначение?
  3. Какие бизнес-возможности она должна реализовать?
  4. Какие проблемы должна решить?

В качестве "Стандарта" на вопросы такого рода смотрите шаблон документа " Stakeholder Request", например, из RUP . Бизнес-требования может выразить Заказчик или Эксперты предметной области . Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта - в качестве шаблона см. Vision из RUP .

Бизнес-моделирование надо проводить на основе информации от, а лучше совместно с экспертами предметной области . Вопросы по сути сводятся к "Что, почему, когда, как и кем происходит в предметной области и как оно взаимосвязано?":

  1. Каковы основные понятия предметной области, их определения и взаимосвязи? Результат можно оформить в виде глоссария и/или концептуально-семантической модели предметной области.
  2. На основании каких правил - международных, федеральных, муниципальных, районных и т.д. законов, указов, стандартов, спецификаций, регламентов и т.д. - происходит то, что происходит в предметной области? Результат оформляете в виде структурированного списка или прикрепляете к элементам концептуальной модели.
  3. Что реально (какие процессы, события, факты) происходит и в какой последовательности, взаимосвязи? Результат оформляете в виде сценариев описания бизнес-процессов (что достаточно универсально) или диаграмм SADT ( IDEF0 , IDEF3, DFD ) / ARIS (eEPC и т.д.) / UML (Business Use-case Diagram (BUC) + Activity Diagram + Sequence Diagram ). Это один из сложнейших этапов.
  4. Какими свойствами обладает каждое из выделенных понятий - структурными и поведенческими? Результат описывается в виде таблиц с атрибутами Концептуальных сущностей или Детальной концептуальной моделью - ER - IDEF1X / UML Class Diagram ( BOM ).

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

  1. На какую систему будет похожа создаваемая?
  2. С какими системами и как давно вы работаете?
  3. Какое у вас образование?
  4. Каковы ваши ожидания от системы - что и как она должна делать, какие задачи помогать решать, как должна выглядеть?
  5. Какие шаги необходимо предпринять для решения каждой задачи?
  6. В каком случае вы будете считать, что система "Хороша"?

Результаты анкетирования/интервьюирования обычно представляют в виде пользовательских историй ( User Story , Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS , Activity/State UML Diagram . Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике.

Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:

  1. Будет ли система единичной или тиражируемой?
  2. В каких странах она будет работать?
  3. Насколько важна информация, хранящаяся, обрабатываемая и передающаяся системой?
  4. Каков возможный ущерб от потери той или иной информации?
  5. Сколько пользователей будет работать с системой сегодня, завтра, через год?

Переработанный результат оформляется в виде Системных требований ( Software Requirement Specification , стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP ).

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

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

Оптимальный подбор предоставляемых средств определяет все остальное

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

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

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

4.3. Формирование и документирование требований к проекту

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

  1. требования проекта и целевое назначение завершенного продукта;
  2. философия проекта;
  3. архитектура приложения;
  4. текущее состояние работ в данном направлении;
  5. план, в соответствии с которым продукт будет переводиться из его текущего состояния в состояние успешного завершения.

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

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

Читайте также: