Файл: 1 разработка сценария внедрения.pdf

44
После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуата- цию.
Осуществляется установка, конфигурирование и настройка сетевых и телекоммуникационных средств, производится перенос данных из прежних локальных систем и формирование интер- фейсов с унаследованными и внешними системами. При этом все создаваемые модели, планы, рабочие программные продукты, до- куменация помещаются в сквозной репозиторий проекта внедре- ния (рисунок 1.17). Важной частью этого репозитория является система документации, формируемая в рамках проекта (рису- нок 1.18).
Отрабатываются системные вопросы безопасности работы системы в многопользовательском режиме. Создаются приложе- ния, шаблоны, отчеты, клиентские формы доступа, распределя- ются полномочия пользователей. Проводится «прогонка» всех систем в «боевом режиме» с участием всех заинтересованных сторон.
После окончания фазы реализации проект внедрения счита- ется законченным. Информационная система передается в экс- плуатацию.
1.3 ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТЫ
Данное практическое занятие предполагает выполнение следующих этапов:
– изучить методические указания;
– ответить на контрольные вопросы.
1.4 КОНТРОЛЬНЫЕ ВОПРОСЫ

45 5. Какие модели и каким образом используются при про- ектировании информационных систем?
6. Какие программные средства используются для моде- лирования процессов при разработке информационных систем?

7. На основании, каких данных и информации разрабаты- ваются модели состояния AS IS и AS TO BE?
8. Кто в компании занимается вопросами разработки, вне- дрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?
9. Назовите основные этапы проектирования информаци- онных технологий.
10. Перечислите этапы жизненного цикла информационной системы.

11. На каком этапе разработки и внедрения ИС производит- ся обучение персонала компании?
12. Перечислите основные фазы внедрения ИС.

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. Подразделы исходных данных к проекту.