Теоретическая часть2. Техническое задание состоит из трех частей
Скачать 120.67 Kb.
|
46 2 РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ НА ВНЕДРЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 2.1 ЦЕЛЬ РАБОТЫ Цель работы – изучение теоретических основ, связанных с разработкой технического задания и получение практических на- выков по разработке технического задания. 2.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ Техническое задание (ТЗ) в дальнейшем является основным документом, по которому ведут разработку проекта. Любые из- менения ТЗ на систему должны быть согласованы и заверены. Техническое задание состоит из трех частей: – содержание задания, в котором перечисляются все ос- новные составные этапы выполнения проекта; – исходные данные; – календарный план выполнения работ. Часть 1 – Содержание задания. Данная часть ТЗ фиксирова- на, в ней перечислены основные составные этапы выполнения проекта. При разработке программной используются две основ- ные методологии: объектно-ориентированного анализа и проек- тирования (ООАП) и методология структурного проектирования. ООАП (Object-Oriented Analysis/Design) – технология разра- ботки программных систем, в основу которых положена объект- но-ориентированная методология представления предметной об- ласти в виде объектов, являющихся экземплярами соответст- вующих классов. Методология ООАП тесно связана с концепци- ей автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE) и языком модели- рования UML (Unified Modeling Language). Методология структурного проектирования применяется на первой фазе проектирования при разделении системы на подсис- темы, здесь используется принцип проектирования «сверху вниз». 47 Часть 2 – Исходные данные включает в себя следующие подразделы: – характеристики объекта автоматизации (или управле- ния); – требования к информационному обеспечению; – требования к техническому обеспечению; – требования к программному обеспечению; – общие требования к проектируемой систем; – перечень дополнительных работ (если необходимо). Характеристики объекта автоматизации. Здесь указываются общие характеристики объекта автоматизации, характерные для рассматриваемой предметной области: – полное название объекта; – условия его функционирования; – количественные и качественные показатели объекта, ко- торые являются ограничениями процесса функционирования. В качестве примера рассмотрим проект «Автоматизирован- ная система составления и разгадывания линейного кроссворда по выбранной теме». Понятие «объект автоматизации» в явном виде в ГОСТ 34.602-89 нигде не определено, но в пункте 2.4.1 указано: «В подразделе Назначение системы указывают вид автоматизируе- мой деятельности (управление, проектирование и т. п.) и пере- чень объектов автоматизации (объектов), на которых предполага- ется ее использовать». Из него следует, что под «объектами ав- томатизации» авторы понимали вовсе не процессы. Будем счи- тать, что объектом автоматизации может быть только материаль- ный (интеллектуальный) объект организация, магазин, цех, отдел, и так далее. Из названия темы следует, что в данном случае объект ав- томатизации – это линейный кроссворд, а виды автоматизируе- мой деятельности – это процессы: – составления/генерирования кроссворда; – разгадывания кроссворда; – работы со словарем понятий. Составление кроссворда отличается от генерирования: в первом случае пользователь вручную составляет кроссворд (до- бавляет понятия, удаляет понятия и т. п.), во втором (генерирова- 48 ние) кроссворд составляется системой автоматически в соответ- ствии с теми настройками, которые выполнил пользователь. Про- цесс составления во многом дублирует функции, которые будет выполнять пользователь при редактировании кроссворда, поэто- му процесс редактирования кроссворда не нужно выделять от- дельно. Для каждого процесса в ТЗ должны быть указаны количест- венные показатели-ограничения, для того, чтобы их правильно выбрать, необходимо знать начальные сведения о структуре са- мого объекта, каким образом будет проходить его построение и разгадывание. Отправной точкой является определение линейно- го кроссворда (ЛК). Итак, ЛК – это «цепочка слов, которая стро- ится методом стыкования, где последняя буква первого слова яв- ляется первой буквой второго и т. д. В чайнворде, как и в кросс- ворде, используются только имена существительные в имени- тельном падеже и единственном числе». Так как ЛК строится из слов, то необходимо указать ограничение на длину слова: мини- мальную длину слова можно определить равную 3, а максималь- ную – 15, потому что чаще всего кроссворды будут составляться на бытовые темы и сам ЛК не должен быть очень простым. Что- бы ЛК было интересно разгадывать, он не должен быть очень ко- ротким, поэтому минимальное количество слов, например, 5, а максимальное – 15. Идем дальше: «слова в чайнворде не пересе- каются, а только стыкуются друг с другом. Иногда цепочку слов изгибают для придания сетке причудливой формы. Длинная изо- гнутая цепочка может неоднократно пересекать саму себя, как слова в кроссворде, такая головоломка обычно называется кросс чайнвордом». Исходя из этого, можно задать следующее ограни- чение – на форму отображения ЛК: обычная (линейная), спираль, змейка, W-образная. «В линейных кроссвордах слова могут пере- крываться не только одной, но и двумя или тремя буквами, по- этому их длина указывается в скобках при определении к слову», эта часть описания ЛК дает еще одно ограничение: количество букв в пересечении от 1 до 3. В качестве пожелания, заказчик от- метил, что ЛК необходимо строить в двух режимах: ручном и ав- томатическом (генерация кроссворда), из этого следует еще одно ограничение – составление кроссворда осуществляется с привяз- кой к словарю понятий. Для того чтобы системы была более уни- 49 версальной (необходимо обеспечить создание тематических кроссвордов или на общие области знаний), заказчик предложил загружать в систему внешние словари понятий и обеспечить ему возможность редактировать их содержимое. При разгадывании кроссворда могут возникнуть затруднения, поэтому (в соответст- вии с пожеланиями заказчика) в системе должна быть организо- вана система подсказок, количество которых можно связать с ко- личеством слов – не менее 1 и не более 10% от количества слов. Требования к информационному обеспечению. Разработка информационного обеспечения (ИО) – наиболее важная часть проекта, она может оказать существенное влияние на весь про- цесс разработки, поэтому уже на стадии разработки ТЗ необхо- димо определить: 1. На основании каких документов разрабатывается мето- дическое и информационное обеспечение системы (нормативные и другие документы). 2. Перечень исходных данных: – какие массивы данных используются и в каких форматах; – на каких носителях эти данные будут поставляться в сис- тему. 3. Перечень выходных данных: – какие массивы данных будут являться результатом рабо- ты системы; – какие документы будут представлены пользователю и в каком виде (указывается вид носителя) и с какой периодично- стью; – какие требования по целостности данных и их защите должны быть выполнены в проектируемой системе. Особо должны быть выделены файл-серверные и клиент- серверные части информационного обеспечения, если таковые имеются. Для разработки данной системы никаких нормативных до- кументов не требуется (стандартов, инструкций и т. п.), поэтому необходимо только сослаться на информацию, где определена структура и свойства линейного кроссворда, а также требования к его построению. Также необходимо определить требования по входным и выходным данным. Большинство параметров линей- ного кроссворда будут задаваться пользователем в режиме диало- 50 га: он обязательно должен подключить словарь понятий, из кото- рого будут формироваться задания для кроссворда. В данном случае «словарь понятий» – это текстовый файл определенной структуры (каждая строка файла – это понятие и его расшифров- ка), который должен загружаться в систему из внешней памяти (с любого логического диска), с которым пользователь должен иметь возможность работать дополнительно. Обязательное усло- вие заказчика – возможность создания коллекции ЛК, поэтому в системе должна быть предусмотрена возможность сохранения наиболее интересных кроссвордов в файл. На данном этапе еще трудно определить структуру этого файла (она должна учитывать и возможность дальнейшего разгадывания кроссворда с помо- щью данной системы), поэтому можно написать, что «структура файла определяется в процессе проектирования». Обязательным условием составления любого типа кроссвордов является его це- лостность (для данного случая это отсутствие пустых клеток в середине ЛК), поэтому это обязательно должно быть записано в требованиях. Требования к техническому обеспечению. Здесь формули- руются ограничения по составу технических средств автоматиза- ции с указанием конкретных типов оборудования и ЭВМ или их составляющих, используемых в проекте, если они заранее из- вестны. Иначе в этом разделе указывается, что состав комплекса технических средств системы определяется в процессе проекти- рования системы. Требования к программному обеспечению. Приводится пе- речень используемых системных и прикладных программных средств, включая операционную систему, систему программиро- вания, систему управления базами данных (в случае необходимо- сти) и другие инструментальные средства (например, среда про- ектирования) с точным наименованием версий, если они заранее известны. Иначе указывается, что состав программного обеспе- чения определяется в процессе проектирования системы. Допол- нительно могут быть указаны требования по совместимости раз- рабатываемого программного обеспечения с существующими системами. Общие требования к проектируемой системе. В данной час- ти ТЗ отдельно выделяется подраздел «Функции, реализуемые 51 системой». В нем приводится подробный перечень функций, ко- торые должна выполнять проектируемая система (или подсисте- ма) в процессе ее эксплуатации. Отдельно должны быть выделе- ны функции ввода данных, их обработки, передачи, хранения, а также формирования отчетов с выдачей на экран или печатающие устройства, функции управления, работа со справочниками и различные сервисные (обслуживающие систему) функции. Фор- мулировка функций должна быть однозначной и конкретной, так как именно она является основой приемки проекта руководите- лем и проверки на полноту и качество реализованной системы или подсистемы. Функции, которые должна выполнять данная система, опре- деляются в первую очередь видами автоматизируемой деятельно- сти. Среди неявных функций, про которые не должны забывать разработчики, это: – визуализация процессов работы с кроссвордом; – выдача сведений о системе (справочные данные о систе- ме и о том, как с ней работать). Нужно отметить, что многие перечисленные в ТЗ функции, не раскрываются подробно, их необходимо будут детализировать при разработке функциональной спецификации. В других подразделах оговариваются специальные техниче- ские требования, предъявляемые к системе: – по быстродействию (времени реакции на выполнение наиболее важных функций); – по режиму работы (диалоговый/интерактивный, автома- тический); – по точности (в случае, если в системе производятся ма- тематические расчеты, требующие минимизации вычислитель- ных погрешностей, или используются внешние информационные источники (датчики, измерители и т. п.)); – по достоверности; – по условиям функционирования (диапазон температур, относительная влажность, давление, наличие в атмосфере пыли, вредных примесей и т. д.), – другие количественные и качественные показатели, оп- ределяющие эффективность функционирования системы. 52 Кроме того, в данном разделе указываются санитарные пра- вила и нормы и ГОСТы, требования которых необходимо учиты- вать при разработке такого класса систем, с учетом того, что сис- темы разворачиваются на средствах вычислительной техники. Часть 3 – Календарный план выполнения работ. Технология RAD требует жесткого следования плану-графику работ, поэтому в ТЗ оговариваются ключевые задания, по которым преподава- тель должен проводить обязательный контроль. Каждый из пере- численных этапов должен завершаться полностью готовой доку- ментацией, согласованной с заказчиком (руководителем). Невы- полнение в срок какого-либо из этапов может привести либо к сдвигу «контрольных точек» по оставшимся этапам, либо к не за- вершению проекта в срок. В заключение хотелось бы отметить, что процесс составле- ния ТЗ на внедрение системы: – требует от разработчиков коллективных обсуждений и принятия ответственных решений; – позволяет выявить наиболее «узкие» места проекта и оценить возможные риски; – дает возможность команде разработчиков распределить между собой все виды выполняемых работ, сосредоточив в даль- нейшем усилия на концептуальных аспектах проекта; – определить наиболее приоритетные функции, которые будут составлять каркас системы. 2.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ Данное практическое занятие предполагает выполнение следующих этапов: – изучение теоретических положений; – разработка технического задания по выбранной системе; – ответы на контрольные вопросы. 2.4 КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Из каких частей состоит техническое задание? 2. Поясните часть содержание задания. 3. Подразделы исходных данных к проекту. 53 4. Что указывается в характеристиках объекта автоматиза- ции? 5. Что необходимо определить в требованиях к информаци- онному обеспечению? 6. Что необходимо определить в требованиях к техниче- скому обеспечению? 7. Что необходимо определить в требованиях к программ- ному обеспечению? 8. Что содержат общие требования к проектируемой систе- ме? 9. Специальные технические требования, предъявляемые к системе. 10. Календарный план выполнения работ. |