Учебное пособие ПИС

-наличие взаимно согласованного источника информации для объединения требований Заказчика и способов реализации системы Разработчиком;

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

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

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

1) определение источника финансирования работ по подготовке технического задания;

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

3) изучение предметной области Заказчика; 4) детальное изучение объекта Заказчика – процессов, персонала,

составление модели; 5) составление списка проблем и требований к системе;

6) выполнение обследования для определения наличия и уровня существующих решений для автоматизации объектов данной предметной области;

7) согласование с Заказчиком списка проблем и требований;

8) подготовка окончательных вариантов концепций реализации системы с ориентировочной оценкой стоимости реализации концепции. (желательно использование демонстрационных материалов, прототипов и ссылок на источники информации);

9) выбор Заказчиком концепции реализации системы;

10) выбор Разработчиком средств реализации системы;

11) формулирование требований к разрабатываемой системе и методов и механизмов решения проблем в соответствии с возможностями средств реализации системы;

12) согласование и утверждение сформулированных требований с ответственными за содержание ТЗ от Заказчика и Разработчика;

13) оформление ТЗ в форме документа;

14) согласование текста ТЗ со всеми потенциальными пользователями и участниками разработки.

15) несение изменений в ТЗ по результатам согласований;

16) подписание ТЗ руководителями Заказчика и Разработчика;

31

17) согласование ТЗ в контролирующих организациях (при необходимости).

Вприведенном списке работ очевидно повторение ряда работ, которые проводились ранее на этапе предпроектного обследования. Данные работы проводятся повторно c целью получить максимально полную и достоверную информацию.

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

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

С точки зрения информатики наиболее важными представляются следующие общие качественные свойства информации: [5,6]

- объективность; - достоверность; - полнота; - точность;

- актуальность; - полезность; - ценность;

- современность; - понятность; - доступность;

- краткость и др.

Объективность информации: Объективный – существующий вне

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

32

объективные сведения путем анализа и сопоставления нескольких субъективных.

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

-преднамеренное искажение (дезинформация) или непреднамеренное искажение субъективного свойства;

-искажение в результате воздействия помех («испорченный телефон») и недостаточно точных средств ее фиксации.

Полнота информации: информацию можно назвать полной, если

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

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

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

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

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

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

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

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

33

документ) с указанием источников и способов получения этой информации.

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

Основными разделами технического задания согласно ГОСТ 34.602-

89[4] являются:

1)общие сведения;

2)назначение и цели создания (развития) системы;

3)характеристика объектов автоматизации;

4)требования к системе;

5)состав и содержание работ по созданию системы;

6)порядок контроля и приемки системы;

7)требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8)требования к документированию;

9)источники разработки.

Раздел “Требования к системе” состоит из следующих подразделов:

-требования к системе в целом;

-требования к функциям (задачам), выполняемым системой;

-требования к видам обеспечения.

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы

В подразделе “Требования к системе в целом” указывают:

-требования к структуре и функционированию системы;

-требования к численности и квалификации персонала системы и режиму его работы;

-показатели назначения;

-требования к надежности;

-требования безопасности;

-требования к эргономике и технической эстетике;

-требования к транспортабельности для подвижных АС; требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

34

-требования к защите информации от несанкционированного

доступа;

-требования по сохранности информации при авариях;

-требования к защите от влияния внешних воздействий;

-требования к патентной чистоте;

-требования по стандартизации и унификации;

-дополнительные требования.

Вподразделе “Требование к функциям (задачам)”, выполняемым системой, приводят:

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

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

действие в 1-й и последующих очередях; - временной регламент реализации каждой функции, задачи (или

комплекса задач); - требования к качеству реализации каждой функции (задачи или

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

- перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

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

Полное содержание структуры ТЗ и видов требований изложено в оригинальном тексте ГОСТ 34.602-89 [4], который приведен в Приложении №2.

Момент после согласования и подписания технического задания можно считать отправной точкой для начала работ собственно по проектированию ИС. Именно ТЗ содержит в полном объеме исходные данные для проектирования.

ТЗ является завершенной работой и должно быть оплачено Разработчику или включено в состав расходов по проектированию.

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

35

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

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

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

2.6Использование структурных и функциональных схем

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

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

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

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

Структурные схемы делятся на одноуровневые, многоуровневые и иерархические.

36

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

Пример одноуровневой структурной схемы показан на рисунке 2.1.

Локальная сеть

Монитор

Клавиатура

Оператор ПК

Рисунок 2.1 – Структурная схема рабочего места оператора ПК

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

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

Для указания связей между элементами структуры или взаимного влияния блоки соединяют линиями. Линии могут иметь на концах

37

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

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

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

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

Генеральный директор

Рисунок 2.2 – Структура подчинения сотрудников фирмы

38

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

3 Организация процесса проектирования

3.1 Подготовка технологии проектирования

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

-стоимость создания информационной системы согласно ТЗ;

-сроки запуска в эксплуатацию;

-гарантийные обязательства;

-стоимость работ по сопровождению созданной системы;

-географическая удаленность офиса Разработчика;

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

-количество сотрудников в штате Разработчика;

-количество «знаков признания качества» работы Разработчика (свидетельств, сертификатов, грамот, благодарственных писем и др).

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

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

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

технология проектирования.

39

Технология проектирования определяется как совокупность трех составляющих [7]:

-пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

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

Каждая технологическая операция определяется набором основных характеристик:

-наименование;

-содержание;

-необходимые исходные данные;

-результаты;

-виды и источники вспомогательной информации (методики, стандарты, нормативы и т.д.)

-необходимые исполнители и технические средства;

-трудоемкость выполнения операции по исполнителям;

-ресурсоемкость операции по техническим средствам;

-эталонная себестоимость.

При графическом отображении технологии проектирования рекомендуется придерживаться правил устанавливаемых методикой SADT [7]. На рисунке 3.1. Показано правило графического отображения технологической операции.

Методические материалы, нормативы, стандарты, критерии оценки результатов

Исполнители, программные и технические средства

Рисунок 3.1 – Представление технологической операции проектирования

40