2.2. Формирование системы требований.

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

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

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

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

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

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

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

2.3. Планирование функций.

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

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

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

1. Поиск потенциального заказчика.

2. Выявление запросов заказчика и сопоставление их с возможностями системы.

3. Изготовление заказного программного продукта.

4. Поставка программного продукта.

5. Послепродажное сопровождение и гарантийное обслуживание.

6. Финансовые расчеты с заказчиком и внешними системами.

К этому следует добавить те функции, которые составляют основу функциональной надстройки /3/ и обеспечивают поддержание жизнеспособности самой системы.

Например, этими функциями могут быть:

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

2. Набор и обучение персонала.

3. Аренда (покупка) помещений, оборудование систем энергоснабжения, транспортные операции, охрана и многое другое.

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

2.4. Изготовление и эксплуатация.

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