1.1 Анализ предметной области. Основные понятия Работа над созданием программного продукта начинается с анализа предметной области: определяют потребности пользователей в информации, которые, в свою очередь, предопределяют структуру и содержание системы и используемых в ней данных. Предметная область — совокупность объектов реального мира, информация о которых должна быть отражена в системе. Предметная область подлежит изучению в целях организации управления и, в конечном итоге, автоматизации. Предметная область характеризуется совокупностью объектов, процессов, использующих эти объекты, а также множеством пользователей, которые имеют единый взгляд на предметную область. Анализ предметной области сводится к поэтапному выявлению информационных объектов и их основных функций, взаимосвязей между объектами и информационными потоками. Информационный объект — описание некоторой сущности предметной области — объекта, процесса, явления или события, существующих или происходящих в реальном мире. Информационный объект является совокупностью логически связанной информации: между информационными объектами могут существовать разного рода связи. Изучение предметной области складывается из непосредственного наблюдения протекающих в ней процессов, изучения документов, циркулирующих в системе, а также интервьюирования участников этих процессов. Результатом анализа предметной области должны стать перечень системных требований, спецификаций, информационных потоков и их описание, а также совокупность моделей, адекватных данной области. Модель предметной области — некоторая система, адекватная этой области, имитирующая ее структуру и функционирование. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки программного продукта. Модель должна отражать все аспекты функционирования программного обеспечения и необходима на всех этапах жизненного цикла программного продукта. Особую роль модели предметной области играют на стадии формирования требований к программному обеспечению. На этом этапе создаются текстовые описания предметной области (в том числе должностные инструкции, описание документооборота, примеры первичных документов, выходных отчетов, описание работы оборудования). Более информативными и полезными при разработке программного обеспечения и баз данных являются описания предметной области, выполненные с помощью специализированных графических нотаций (материал о них содержится в следующих главах). Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого числа ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование продукта. При разработке модели предметной области определяют некоторые границы, в пределах которых можно развивать логическую модель данных, т. е. моделировать объекты, не выходящие за пределы рассматриваемой предметной области. Например, в качестве предметной области можно выбрать обслуживание газораспределительной системы, бухгалтерию предприятия, кредитный отдел банка, ремонтную мастерскую. Предметная область содержит как существенные понятия и данные, так и малозначащие или вообще незначащие. Так, если в качестве предметной области выбрать учет товаров на складе, то понятие «Накладная» является существенным. В то же время количество детей сотрудника, принимающего накладные для учета товаров, является несущественной информацией. Но для расчета заработной платы данные о наличии детей являются необходимыми. Таким образом, любая предметная область имеет свои границы рассмотрения и при проектировании программного обеспечения требуется выделить информационные объекты внутри границ предметной области и абстрагироваться от информации вне границ. К модели предметной области предъявляют следующие требования: формализация, обеспечивающая однозначное описание структуры предметной области; понятность для заказчиков и разработчиков на основе применения графических средств отображения модели; реализуемость, подразумевающая наличие средств физической реализации модели предметной области; легкость модификации (в модель по разным причинам часто приходится вводить новые объекты или модифицировать существующие; модель должна обеспечивать возможность ввода новых данных без изменения ранее определенных); обеспечение возможности оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей. Для реализации перечисленных требований требуется построение системы моделей: объектной модели, отображающей состав взаимодействующих в процессах объектов предметной области; функциональной модели, отображающей взаимосвязь функций (действий) по преобразованию объектов в процессах; технической модели, описывающей расположение и способы взаимодействия комплекса технических средств. Возможно, также потребуются и другие модели, например организационная модель или модель управления, отображающая события и бизнес-правила, которые воздействуют на выполнение процессов. Главный критерий адекватности модели предметной области заключается в функциональной полноте разрабатываемой информационной системы. Обычно модели строят на трех уровнях (рис. 1.1): 1) внешнем — определения требований; 2) концептуальном — спецификации требований; 3) физическом (внутреннем) — реализации требований. Рис. 1.1.Трехуровневое представление информационной системы На внешнем уровне определяют состав основных компонентов информационной системы и их размещение (объектов, функций, событий, организационных единиц, технических средств). На концептуальном уровне выявляют характер взаимодействия компонентов системы. Концептуальная модель является смысловой структурой рассматриваемой предметной области. Для построения такой модели требуются хорошее знание предметной области, ее семантики, понимание логических взаимосвязей между объектами, а также информационных потребностей пользователей проектируемой системы (рис. 1.2). Рис. 1.2.Схема построения концептуальной модели На физическом (внутреннем) уровне с помощью модели определяют программно-технические средства, позволяющие реализовать требования к системе. Методы обследования предметной области и сбора материалов можно подразделить на следующие группы: методы сбора информации, выполняемого проектировщиками, — включают методы проведения бесед и опросов, анализа материалов обследования, личных наблюдений; методы сбора информации специалистами предметной области — проведение документальной инвентаризации рабочего места либо использование других методов, позволяющих определить состав производимых операций, набор получаемых документов и т. д.; метод бесед и консультаций с руководителями предприятий и подразделений, групп будущих пользователей либо со специалистами по вопросам, относящимся к определению проблем; метод опроса исполнителей на рабочих местах — заранее составляется список сотрудников, с которыми требуется провести беседу, разрабатывается перечень вопросов о назначении работ и порядке их выполнения; метод анализа операций — разбиение рассматриваемого процесса или работы на составные части (задачи, операции), анализ каждой части в отдельности, выявление многократного повторения отдельных операций, определение степени зависимости друг от друга и т. д. В процессе проведения обследования все действия в обязательном порядке документируются, согласуются и утверждаются всеми заинтересованными и ответственными сторонами. Перед началом работ по проведению обследования предметной области необходимо выбрать вид обследования: локальное проведение обследования для разработки проекта отдельной задачи; системное обследование объекта для изучения всего объекта в целом. Как правило, применяют стандартные способы описания предметной области с использованием моделей DFD — диаграмм потоков данных, унифицированного языка моделирования UML и др. Наиболее полной методологией моделирования является методология IDEF. Фактически, это целое семейство методологий от IDEF0 до IDEF14. Речь об этих методологиях пойдет в следующих главах. 1.2Требования к программному обеспечению. Классификация требований Требования к программному обеспечению представляют собой совокупность условий, которым они должны удовлетворять. Изначально собираемые требования называют первичными требованиями заказчика. Первичные требования заказчика включают протоколы обсуждений, интервью с заказчиками, различные документы и отчеты, сведения о существовании аналогичных программных продуктов и другие материалы. После этого вырабатывают требования к компонентам программного обеспечения — программным и техническим средствам, базам данных и т. д. Первичные требования заказчика не должны противоречить друг другу, так же как и не должно быть «лишних» документов, не содержащих полезную информацию. На самом деле требования и пожелания могут быть не структурированы, часто противоречивы, разбросаны по всевозможным соглашениям, договорам, протоколам рабочих совещаний, черновым материалам обследований. Следовательно, есть немалый риск не учесть всех требований, если не будет приложено достаточно усилий по организации и контролю выполнения этих требований. Решение проблемы достаточно очевидно: нужно учитывать требования и контролировать их обработку, оценку и выполнение. Такую работу называют работой по управлению требованиями. Управление требованиями к программному обеспечению, как правило, включает: а) выявление, организацию и документирование требований к программному обеспечению; б) установление взаимопонимания между заказчиками и разработчиками относительно требований к программному обеспечению. Управление требованиями к программному обеспечению преследует следующие цели: достижение соглашения с заказчиком и пользователями о том, что должен делать программный продукт; улучшение понимания требований к программному обеспечению со стороны разработчиков; установление границ программного обеспечения, т. е. определение технических требований к аппаратуре компьютера, операционной среде и возможностям программного обеспечения; определение данных для планирования. Важность управления требованиями объясняется еще и тем, что в период работы над программным обеспечением требуется установить приоритеты, распределив требования по категориям: необходимо выполнить и можно выполнить. Все требования подразделяют на функциональные и нефункциональные. Функциональные требования определяют задачи и функции, которые должно выполнять программное обеспечение, независимо от ограничений, связанных с его реализацией. Другими словами, они определяют поведение программного продукта. Нефункциональные требования описывают его свойства или характеристики, а также требования к системному окружению, но не определяют поведение программного продукта. К нефункциональным требованиям к программному обеспечению относят: требования к эксплуатации (качество пользовательского интерфейса, пользовательской и технической документации, справочной системы); требования к производительности (ограничения функциональных требований, требования к эффективности использования ресурсов, например к пропускной способности или времени отклика системы); требования к реализации — описывают использование технических стандартов, определенных инструментальных средств, операционного окружения и т. д.; требования к надежности — предписывают допустимые частоту появления сбоев и их воздействие на работу программного обеспечения, а также возможности восстановления программного обеспечения после сбоев; требования к интерфейсу — определяют внешние сущности (т. е. пользователей и любые внешние устройства), с которыми может взаимодействовать система, и регламент этого взаимодействия. Этап формирования требований можно назвать этапом неформального определения архитектуры будущего программного обеспечения. Этот этап является наиболее сложным и ответственным. В процессе работы над проектом меняется представление о программном обеспечении как у заказчика, так и у исполнителя. Поэтому на ранних этапах трудно определить, какими характеристиками должно обладать создаваемое программное обеспечение. Этап формирования требований включает анализ первичных требований заказчика, структурирование требований и, возможно, конструирование прототипа. Составление требований является циклическим процессом. Если требования в итоге составлены и утверждены, то разработка переходит в следующую фазу жизненного цикла программного обеспечения — проектирование, иначе вновь проводят анализ первичных требований. В каждом цикле выявляют и устраняют семантические ошибки в описании программного обеспечения. При этом невозможно определить момент окончания процесса составления требований. Для того чтобы он закончился, на одном из шагов, руководствуясь принципом разумной достаточности, принимают решение, что составленные требования больше не имеют семантических ошибок, и однозначно описывают то, что программное обеспечение должно выполнять. Первичные требования заказчика представляют собой обобщенное описание программного обеспечения, не содержащее подробностей, а описания отдельных функций не детализированы либо отсутствуют. Анализ первичных требований должен проводиться обязательно совместно с заказчиком. При анализе первичных требований заказчика требуется выяснить, возможно ли создание требуемого программного обеспечения и насколько реальны указанные сроки, а также каких деталей в описании не хватает и что еще следует прояснить. Кроме того, необходимо определить сроки и способы получения недостающей информации, способы тестирования и условия приемки готового программного продукта. Рассмотрим, каким образом происходит структурирование требований. Сначала указывают общее назначение программного продукта, особенности аппаратных средств, на которых программное обеспечение должно быть реализовано, определяются особенности эксплуатации программного продук- та, выделяют основные компоненты программного обеспечения. Далее выполняют детализацию обобщенной структуры требований: уточняют описания взаимосвязей основных компонентов и составляют детальное описание каждого структурного элемента. Для каждого структурного элемента осуществляют детализацию его функций и составляют общее описание каждой функции всех структурных элементов. При этом анализируют все требования с точки зрения возможности их выполнения в указанные сроки. Детальная структура требований к программному продукту должна давать подробное представление о взаимосвязях структурных элементов и общее представление обо всех их функциях. Завершается структурирование требований к программному обеспечению составлением описаний отдельных функций каждого структурного элемента. Для каждой функции должны быть указаны входные данные, детально описаны производимые над входными данными действия, определены выходные данные, а также способы тестирования. Глубину детализации каждого требования определяет руководитель проекта. Она должна быть такой, чтобы описания отдельных функций содержали все необходимые сведения и давали разработчику и заказчику ясное представление о том, что же собой представляет программный продукт и что он может делать. Описание рекомендуется составлять с использованием принятой в технической литературе терминологии.
