2015-06-24
470
Особенности написания некоторых разделов ТЗ
Раздел «Общие сведения» должен включать сведения о заказчике и возможном исполнителе работ, о способе определения исполнителя, бюджете, из которого финансируется создание СЭД, и примерных сроках и этапах проведения работ по созданию СЭД.
Например, в этом разделе может быть указано, что исполнитель определяется путем заключения государственного контракта.
Раздел «Назначение и цели создания (развития) системы» должен содержать описание основной цели создания системы и результатов, которые заказчик предполагает получить от внедрения системы. Эти результаты должны быть экономически измеримы или могут быть указаны способы их измерения.
Например, целью внедрения СЭД может быть сокращение сроков согласования договоров до 1 рабочего дня по всем филиалам компании.
Раздел «Характеристика объектов автоматизации» содержит описание процессов в организации, требующих автоматизации, и является итогом отчета об информационном обследовании, который составляется при обследовании процессов организации.
|
|
|
Раздел «Требования к системе» является основным разделом ТЗ. Этому разделу следует уделить особое внимание, т. к. именно он регламентирует и закрепляет множество технических особенностей будущей системы.
В данном разделе должны быть описаны следующие требования:
1. Требования к системе в целом, включая требования к архитектуре системы, составу рабочих мест, требования к персоналу системы, требования к надежности, требования к эргономике, требования к обеспечению режима секретности (если конфиденциальные документы обрабатываются в системе), требования к защите информации от несанкционированного доступа, требования к масштабированию системы и другие.
2. Требования к функциям (задачам), выполняемым системой, должны содержать описание функционала подсистем (модулей) СЭД.
3. Требования к взаимодействию подсистем (модулей) СЭД должны описывать механизмы взаимодействия подсистем (модулей).
4. Требования к взаимосвязи со смежными системами организации должны описывать, какие системы являются смежными и как они могут быть связаны с СЭД.
Например, система кадрового учета может предоставлять списки пользователей для СЭД. 5. Требования к режиму функционирования СЭД должны содержать описание режима функционирования (например, 24 часа 7 дней в неделю) и порядок проведения профилактических работ по переустановке системы или по ее обновлению.
Например, обновление системы должно проводиться без остановки функционирования системы.
6. Требования к видам обеспечения должны содержать: лингвистическое обеспечение системы, требования к входным и выходным формам СЭД, требования к базам данных, требования к организационному обеспечению, требования к информационному, программному и техническому обеспечению системы.
|
|
|
7. Требования к администрированию системы с описанием ролей и обязанностей администраторов системы.
Раздел «Состав и содержание работ по созданию системы» целесообразно делать в виде таблицы с указанием наименования этапов работ по созданию СЭД, примерных сроков начала и окончания этапов, а также результатов окончания этих этапов.
Раздел «Порядок контроля и приемки системы» должен определять, какие виды испытаний необходимо провести для приемки системы, включая перечень документации, требуемой для проведения этих испытаний.
Например, для ввода системы в действие могут быть проведены ведомственные испытания согласно разработанной и утвержденной заказчиком программе и методике испытаний.
Раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» описывает перечень мероприятий по обучению пользователей СЭД, по разработке пособий и методических материалов, требования к проведению конвертации данных или вводу первоначальных данных в СЭД, требования к созданию инфраструктуры для функционирования СЭД.
Раздел «Требования к документированию» описывает общие правила составления рабочей документации к системе и может ссылаться на корпоративные стандарты или ГОСТы.
Раздел «Источники разработки» является заключительным и перечисляет документы, которые послужили основой для разработки системы и принятия тех или иных технических решений.
При этом в тексте ТЗ должны быть проставлены ссылки на все источники разработки. Указание того или иного источника должно быть обоснованным и подтверждаться в тексте ТЗ.
Надеемся, что после прочтения данной статьи вы подробнее познакомились с нормативной базой ТЗ, его составом и содержанием и теперь готовы к работе с этим документом.
15.Основные принципы CASE - технологий
1. Принцип всесторонней компьютерной поддержки проектирования. САSЕ -технология — это разновидность САПР в области создания информационных систем.
2. Принцип модельного подхода — это может быть методология функционально ориентированного подхода или методология объектно - ориентированного подхода.
3. Иерархическое представление модели предметной области. Существуют плоские модели, предусматривающие представление всей модели в виде единого листа. Но когда встречаются сложные системы, то возникают определенные трудности. Преодолеть эти трудности позволяют иерархические модели, в которых предусмотрена иерархическая последовательность детализации (декомпозиции)описания системы. Эти модели соответствуют принципу проектирования «сверху вниз», от общего к частному.
4. Наглядность представления модели, т. е. наличие визуальных средств проектирования. Это связано с тем, что процесс построения модели информационной системы так и не удается формализовать до конца и в этом процессе должен принимать участие человек. Графические средства обозначения и правила, предназначенные для описания структуры системы, этапов обработки информации представляют собой нотации САSЕ -технологии. Нотации включают графы, диаграммы, таблицы, формальные и естественные языки. Их использование является существенной особенностью САSЕ -технологии. Поэтому САSЕ -технология предусматривает четырехуровневую парадигму проектирования, в которой важное место отводится нотациям: Методология – Метод - Нотации-Средства.
5. Декомпозиция не только модели предметной области, но и самого процесса проектирования на стадии и этапы. Обычно выделяют следующие стадии проектирования: анализ, собственно проектирование, программирование (реализация), внедрение. САSЕ -технология может быть распространена на все стадии жизненного цикла информационной системы.
|
|
|
6. Перенесение трудоемкости разработки в большей степени на анализ и проектирование. Известно, что ошибки на последующих стадиях труднее исправить, причем трудности возрастают на порядок. Поэтому САSЕ -технологии проектирования предусматривают особенно тщательную проработку стадии анализа и проектирования.
7. Отделение, независимость стадий проектирования от средств реализации, от программирования. Соблюдение этого принципа позволяет переносить проектные решения с одной программно-технической платформы на другую, т. е. осуществлять миграцию ИС.
8. Возможность как прямого, так и обратного проектирования (формирование моделей и спецификаций на основе анализа программных кодов и схем баз данных).
9. Использование репозитория — хранилища проектных данных,представляющего собой центральный компонент САSЕ -средства.
16.Эволюция CASE – средств
Современные CASE-средства являются естественным продолжением
эволюции всей отрасли средств разработки ПО. В [1] выделено шесть
периодов, качественно отличающихся применяемой техникой и
методами разработки ПО, которые характеризуется использованием в
качестве инструментальных следующих средств:
- ассемблеры, дампы памяти, анализаторы;
- компиляторы, интерпретаторы,трассировщики;
- символические отладчики, пакеты программ;
- системы анализа и управления исходными текстами;
- CASE-средства анализа требований, проектирования
спецификаций и структуры, редактирования интерфейсов (первая
генерация CASE-I);
- CASE-средства генерации исходных текстов и реализации
интегрированного окружения поддержки полного ЖЦ разработки ПО -
(вторая генерация CASE-II).
CASE - I является первой технологией, адресованной
непосредственно системным аналитикам и проектировщикам, к
включающей средства для поддержки графических моделей,
|
|
|
проектирования спецификаций, экранных редакторов и словарей
данных. Ее развитие включает создание методологий структурного
построения и проектирования ПО, разработку средств моделирования
данных, использование языков четвертого поколения для
проектирования баз данных (БД), создание средств проектирования
спецификаций ПО. Она не предназначена для поддержки полного ЖЦ и
концентрирует внимание на функциональных спецификациях и
начальных шагах проекта - системном анализе, определении
требований, системном проектировании, логическом проектировании
БД.
CASE - II отличается значительно более развитыми
возможностями, улучшенными характеристиками и исчерпывающим
подходом к полному ЖЦ. В ней в первую очередь используются
средства поддержки автоматической кодогенерации и передачи данных
в сетях,а также усовершенствованная графика. CASE-II может
включать свыше 100 функциональных компонент, поддерживающих все
этапы ЖЦ, при этом пользователям предоставляется возможность
выбора необходимых средств и их интеграции в нужном составе.
Планируемые к 1996 году расширения CASE-технологий призваны
обеспечить улучшение следующих показателей и характеристик:
легкость использования; разнообразие и гибкость графики; развитие
сетевых возможностей; совершенствование управления проектом;
оперативность адаптации методологий к локальным требованиям;
измерение разнообразных метрик ПО; автоматическая кодогенерация;
применение экспертных систем для повторного использования;
развитие реверсной инженерии, основанной на "обратном"
программировании.
17.Концептуальные основы CASE – технологий
Большинство CASE-средств основано на парадигме метод/
нотация/ средство. В таком контексте метод - это систематическая
процедура или техника генерации описаний компонент ПО
(проектирование потоков и структур данных,
объектно-ориентированное проектирование). Нотация предназначена
для описания структуры системы, элементов данных, этапов
обработки и включают графы, диаграммы, таблицы, блок-схемы,
формальные и естественные языки. Средства - инструментарий для
поддержки и усиления методов. Эти инструменты поддерживают работу
пользователей при создании и редактировании графического проекта
в интерактивном режиме, способствуют организации проекта в виде
иерархии уровней абстракции, выполняют проверки соответствия
компонентов.
Интегрированный CASE-пакет содержит четыре основные
компоненты:
1) Основой CASE-пакета является средства централизованного
хранения всей информации о проектируемом ПО в течении всего ЖЦ,
Соответствующая БД должна иметь возможность поддерживать большую
систему описаний и характеристик и предусматривать надежные меры
по защите от ошибок и потерь информации.
2) Средства ввода предназначены для ввода данных в
централизованную БД, а также для организации взаимодействия с
CASE-пакетом. Эти средства должны поддерживать различные
методологии и использоваться на всем ЖЦ разными категориями
разработчиков - аналитиками, проектировщиками, инженерами,
администраторами и т.д.
3) Средства анализа, проектирования и разработки
предназначены для планирования и анализа различных описаний, а
также их преобразования в процессе разработки.
4) Средства вывода служат для документирования, управления
проектом и кодовой генерации.
В основе концептуального построения CASE-пакетов лежат
следующие основные положения:
- человеческий фактор, определяющий разработку ПО как
легкий, удобный и экономичный процесс;
- широкое использование базовых программных средств
получивших массовое распространение в других приложениях (БД и
СУБД, компиляторы с различных языков программирования, отладчики,
документаторы, издательские системы, оболочки экспертных систем и
базы знаний, языки четвертого поколения и др);
- автоматизированная или автоматическая кодогенерация,
выполняющая несколько видов генерации кодов: преобразования для
получения документации, формирования БД, ввода/модификации
данных, получения выполняемых машинных кодов из спецификаций ПО,
автоматической сборки модулей из словарей и моделей данных и
повторно используемых программ, автоматической конверсии ранее
используемых файлов в форматы новых требований;
- интеграция, обеспечивающая управление всем процессом
проектирования и разработки ПО непосредственно через процесс
планирования проекта;
- ограничение сложности, позволяющее получать компоненты,
поддающиеся управлению,обозримые и доступные для понимания, а
также обладающие простой и ясной структурой;
- доступность для разных категорий пользователей;
- рентабельность;
- сопровождаемость, обеспечивающая способность адаптации при
изменении требований и целей проекта;
- графическая ориентация - программы являются схематическими
проектами и форматами, которые много проще в использовании, чем
многостраничные описания.
18.Классификация CASE – средств
CASE-средства представляют собой новый тип графически
ориентированных инструментов для микрокомпьютеров, восходящих к
системе поддержки ЖЦ ПО. В [3] к ним относят любое программное
средство, обеспечивающее автоматическую помощь при разработке ПО,
его сопровождении или деятельности по управлению проектом,
проявляющие следующие дополнительные черты:
- мощная графика для описания и документирования систем ПО,
а также для улучшения интерфейса с пользователем;
- интегрированность, обеспечивающая легкость передачи данных
между средствами;
- использование компьютерного хранилища для всей информации
о проекте, которая может разделяться между разработчиками и
исполнителями как основа для автоматической разработки ПО и
повторного использования элементов проекта в будущих системах.
Все CASE-средства делятся на типы, категории и уровни.
Классификация по типам отражает функциональную ориентацию
CASE-средств в технологическом процессе [3].
1) АНАЛИЗ И ПРОЕКТИРОВАНИЕ. Средства этой группы
используются для создания спецификаций системы и ее
проектирования; они поддерживают широко известные методологии
проектирования (см. главу 2). К таким средствам относятся: The
Developer (ASYST Techologies), Design Generator (Computer
Science), POSE (Computer Systems Advisers) ProKit*Workbench
(McDonnell Douglas), Exelerator (Index Technology), Design Aig
(Nastec), Design Machine (Optima), MicroStep (Meta Systems),
vsDesigner (Visual Software), Analist/Designer (Jourdon).
2) ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ И ФАЙЛОВ. Средства обеспечивают
логическое моделирование данных, преобразование данных, генерацию
схем БД н описание форматов файлов: IDEF/Leverage (D. Appleton),
Chen Toolkit (Chen & Associates), IDMS/Architect (Cullinet
Software), 4Front (Deloitte), CASE*Designer (Oracle).
3) ПРОГРАММИРОВАНИЕ. Средства поддерживают шаги
программирования и тестирования, а также автоматическую
кодогенерацию из спецификаций, получая полностью
документированную выполняемую программу: COBOL2/Workbench (Micro
Focus), DECASE (DEC), NETRON/CAP (Netron), APS (Sage Software).
4) СОПРОВОЖДЕНИЕ И РЕИНЖЕНЕРИЯ. К таким средствам относятся
документаторы, анализаторы программ, средства реструктурирования
и обратной реиженерии: Adpac CASE Tools (Adpac), Scan/COBOL,
SuperStructure (Computer Data Systems), Inspector/Recorder
(Language Technology).
5) ОКРУЖЕНИЕ. Средства поддержки платформ для интеграции,
создания и придания товарного вида CASE-средствам: Multi/Cam (AGS
Management Systems), Sylva Foundry (Cadware).
6) УПРАВЛЕНИЕ ПРОЕКТОМ. Средства, поддерживающие
планирование, контроль, руководство, взаимодействие, т.е.
функции, необходимые в процессе разработки и сопровождения
проектов: Project WorkBench (Apllied Business Technology).
Классификация по категориям [3] определяет уровень
интегрированности по выполняемым функциям и включает
вспомогательные программы (tools), пакеты разработчика (toolkit)
и инструментальные средства (workbench). Категория tools
обозначает вспомогательный пакет, решающий небольшую автономную
задачу, принадлежащую проблеме более широкого масштаба. Категория
toolkkit представляет совокупность интегрированных программных
средств, обеспечивающих помощь для одного из классов программных
задач; использует общее хранилище для всей технической и
управляющей информации о проекте, концентрируясь при этом на
поддержке, как правило, одной фазы или одного этапа разработки
ПО. Категория workbench представляют собой интеграцию программных
средств, которые поддерживают автоматизированную помощь в
системном анализе, проектировании и разработке ПО; используют
общее хранилище, содержащее всю техническую и управляющую
информацию о проекте; автоматически передают системную информацию
по шагам разработки; организуют поддержку от проектирования ПО до
получения документированной выполняемой программы. Workbench по
сравнению с toolkit обладает более высокой степенью интеграции
выполняемых функций, большей самостоятельностью и автономностью
использования, а также наличием тесной связи с системными и
техническими средствами аппаратно-вычислительной среды, на
которой workbench функционирует. По существу workbench может
рассматриваться как автоматизированная рабочая станция,
используемая как инструментарий для автоматизации всех или
отдельных совокупностей работ по созданию ПО.
Классификация по уровням [4] связана с областью действия
CASE в пределах жизненного цикла ПО. Однако четкие критерии
определения границ между уровнями не установлены, поэтому данная
классификация имеет, вообще говоря, качественный характер.
Верхние (Upper) CASE часто называют компьютерным
планированием. Они призваны повышать эффективность деятельности
руководителей фирмы и проекта путем сокращения затрат на
определение политики фирмы и на создание общего плана проекта.
Этот план включает цели и стратегии их достижения, основные
действия в свете целей и задач фирмы, установление стандартов на
различные виды взаимосвязей и т.д. Использование верхних CASE
позволяет построить модель предметной области, отражающую всю
существующую специфику. Она направлена на понимание общего и
частного механизмов функционирования, имеющихся возможностей,
ресурсов, целей проекта в соответствии с назначением фирмы. Эти
средства позволяют проводить анализ различных сценариев (в том
числе наилучших и наихудших), накапливая информацию для принятия
оптимальных решений.
Средние (Middle) CASE считаются средствами поддержки этапов
анализа требований и проектирования спецификаций и структуры ПО.
Их использование существенно сокращает цикл разработки проекта;
при этом важную роль играет возможность накопления и хранения
знаний, обычно имеющихся только в голове разработчика-аналитика,
что позволит использовать накопленные решения при создании других
проектов. Основная выгода от использования среднего CASE состоит
в значительном облегчении проектирования систем, проектирование
превращается в итеративный процесс, включающий действия [1]:
- пользователь обсуждает с аналитиком требования к
информации;
- аналитик документирует эти требования, используя диаграммы
и словари входных данных;
- пользователь проверяет эти диаграммы и словари, при
необходимости модифицируя их;
- аналитик отвечает на эти модификации, изменяя -
соответствующие спецификации.
Кроме того, средние CASE обеспечивают возможности быстрого
документирования требований и прототипирования.
Нижние (Lower) CASE поддерживают системы разработки ПО (при
этом может использоваться до 30% спецификаций, созданных
средствами среднего CASE). Они содержат системные словари и
графические средства, исключающие необходимость разработки
физических спецификаций - имеются системные спецификации, которые
непосредственно переводятся в программные коды разрабатываемой
системы (при этом автоматически генерируется до 80% кодов). На
этот уровень средств возложены также функции тестирования,
управление конфигурацией, формирование документации. Главные
преимуществами нижних CASE являются: значительное уменьшение
времени на разработку облегчение модификаций, поддержка
возможностей прототипирования (совместно со средними CASE).
19.Структуризация как метод создания ЭИС
Структуру ИС составляет совокупность отдельных ее частей, называемых подсистемами.
Подсистема – это часть системы, выделенная по какому-либо признаку.
Общую структуру ИС можно рассматривать как совокупность подсистем независимо от сферы применения. В этом случае говорят о структурном признаке классификации, а подсистемы называют обеспечивающими.
Структура ИС как совокупность обеспечивающих подсистем.
|
Информационное обеспечение
Назначение подсистемы информационного обеспечения состоит в своевременном формировании и выдаче достоверной информации для принятия управленческих решений.
Информационное обеспечение – это совокупность единой системы классификации и кодирование информации, унифицированных систем документации, схем информационных потоков, циркулирующих в организации, а также методология построения баз данных.
Унифицированные системы документации создаются на государственном, республиканском, отраслевом и региональном уровнях. Главная цель – это обеспечение сопоставимости показателей различных сфер общественного производства.
Схемы информационных потоков отражают маршруты движения информации и ее объемы, места возникновения первичной информации и использования результатной информации. За счет анализа структуры подобных схем можно выработать меры по совершенствованию всей системы управления.
Построение схем информационных потоков, позволяющих выявить объемы информации и провести ее детальный анализ, обеспечивает:
- исключение дублирующей и неиспользуемой информации;
- классификацию и рациональное представление информации.
Методология построения баз данных базируется на теоретических основах их проектирования. Она состоит из двух последовательно реализуемых этапов:
1 этап – обследование всех функциональных подразделений фирмы с целью:
- понять специфику и структуру ее деятельности;
- построить схему информационных потоков;
- проанализировать существующую систему документооборота;
- определить информационные объекты и соответствующий состав реквизитов, описывающих их свойства и назначение.
2 этап – построение концептуальной информационно-логической модели данных для обследованной на первом этапе сферы деятельности. В этой модели должны быть установлены и оптимизированы все связи между объектами и их реквизитами. Информационно – логическая модель является фундаментом, на котором будет создана база данных.
Для создания информационного обеспечения необходимо:
§ ясное понимание целей, задач, функций всей системы управления организацией;
§ выявление движения информации от момента возникновения и до ее использования на различных уровнях управления, представленной для анализа в виде схем информационных потоков;
§ совершенствование системы документооборота;
§ наличие и использование системы классификации и кодирования;
§ создание массивов информации на машинных носителях, что требует наличия современного технического обеспечения.
Техническое обеспечение.
Техническое обеспечение – комплекс технических средств, предназначенных для работы ИС, а также соответствующая документация на эти средства и технологические процессы.
Комплекс технических средств составляют:
- компьютеры любых моделей;
- устройство сбора, накопления, обработки, передачи и вывода информации;
- устройства передачи данных и линий связи;
- оргтехника и устройства автоматического съема информации;
- эксплуатационные материалы и др.
Документацией оформляются предварительный выбор технических средств, организация их эксплуатации, технологический процесс обработки данных, технологическое оснащение.
Документацию можно условно разделить на три группы:
- общесистемную, включающую государственные и отраслевые стандарты по техническому обеспечению;
- специализированную, содержащую комплекс методик по всем этапам разработки технического обеспечения;
- нормативно – справочную, используемую при выполнении расчетов по техническому обеспечению.
К настоящему времени сложились две основные формы организации технического обеспечения: централизованная и частично или полностью децентрализованная.
Централизованное техническое обеспечение базируется на использовании в информационной системе больших ЭВМ и вычислительных центров.
Децентрализация технических средств предполагает реализацию функциональных подсистем на персональных компьютерах непосредственно на рабочих местах.
Перспективным подходом считается частично децентрализованный подход – организация технического обеспечения на базе распределительных сетей, состоящих из персональных компьютеров и большой ЭВМ для хранения баз данных, общих для любых функциональных подсистем.
Математическое и программное обеспечение.
Математическое и программное обеспечение – это совокупность математических методов, моделей, алгоритмов и программ для реализации целей и задач ИС, а также нормального функционирования комплекса технических средств.
К средствам математического обеспечения относятся:
- средства моделирования процессов управления;
- типовые задачи управления;
- методы математического программирования, математической статистики, теории массового обслуживания и др.
В состав программного обеспечения входят общественные и специальные программные продукты, а также техническая документация.
К о бщественному программному обеспечению относятся комплексы программ, ориентированных на пользователей и предназначенных для решения типовых задач обработки информации. Они служат для расширения функциональных возможностей компьютеров, контроля и управления процессом обработки данных.
Специальное программное обеспечение представляет собой совокупность программ, разработанных при создании конкретной информационной системы. В его состав входят пакеты прикладных программ (ППП), реализующие разработанные модели разной степени адекватности, отражающие функционирование реального объекта.
Техническая документация на разработку программных средств должна содержать описание задач, задание на алгоритмизацию, экономико-математическую модель задачи, контрольные примеры.
Организационное обеспечение.
20.Нисходящее и восходящее методы создания ЭИС
Нисходящее проектирование
Одним из естественных подходов к проектированию программ
является подход сверху вню. Существуя под разными названиями,
такими, как <систематическое программирование>, <иерархическж
проектирование программ> и <взрывное проектирование>, большинство
различных вариаций нисходящего проектирования преследует одну и
ту же цель: определить основные функции, которые должны быть
обеспечены, а затем перейти к определению дополнительных функций,
которые вытекают из этих основных. Хотя осмвной принцип весьма
прост, необходимо, как это будет показано ниже, иысть в виду
многие особенности его приложения.
21.Модульный подход в создании ЭИС. Определение модульности
получил название функционально-модульного или структурного. Он основан на принципе алгоритмической декомпозиции с выделением функциональных элементов и установлением строгого порядка выполняемых действий, т.е. в основе лежит иерархический подход с выделением вначале функциональных действий, затем независимых компонентов с дальнейшей их детализацией.
В соответствии с этим принципом осуществляется разделение функций ИС на модули по функциональной принадлежности, и каждый модуль реализует один из этапов общего процесса. Такой функционально-модульный подход к проектированию ИС, получивший название «модель водопада», предусматривает строго последовательный порядок действий. Главный недостаток такого подхода заключается в движении информации в одном направлении (аналог - по течению реки). Если при проектировании или эксплуатации возникает проблема, то она решается только на данной стадии проекта, не затрагивая предыдущих стадий. Недостаточная обратная связь приводит к ограниченным исправлениям, что в свою очередь приводит к деформированным реализациям. Ориентация на функционально-модульный подход увеличивает вероятность потери контроля над решением возникающих проблем
22.Объектно-ориентированый подход в создании ЭИС
