Тема: Классификация инструментальных средств

Тема: Классификация инструментальных средств Порядок разработки. Классификация и основные особенности современных инструментальных средств. Описание функциональности разработки. Требования к содержанию и документам. Выработка требований. Техническое задание.

Все CASE средства подразделяются на типы, категории и уровни. Классификация по типам: отражает функциональное назначение CASE средства в ЖЦ ПС и систем. Анализ и проетирование. Средства данной группы используются для создания спецификаций системы и ее проектирования. Они поддерживают широко известные методологии проектирования. К таким средствам относятся: - CASE. Аналитик (Эйтэкс), The Developer (ASYST Technologies), POSE (Computer Systems Advisers), Pro. Kit*Workbench (Mc. Donnell Douglas; - Excelerator (Index Technology), Design-Aid (Nastec), Design Machine (Optima), Micro. Step (Mela Systems), vs. Designer (Visual Software), Analist/Designer (Yourdon); - Design/IDEF (Meta Software), BPWin (Logic Works), SELECT (Select Software Tools), System Architect (Popkin Software & Systems); - Westmoimt I-CASE Yourdon (Westmount Technology B. V. & CADRE Technologies), CASE/4/0 (micro. TOOL Gmb. H).

2. Проектирование баз данных и файлов. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в Третью Нормальную Форму, автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода: ERWin (Logic Works), Chen Toolkit (Chen & Asssociates), S- Designer (SDP), Designer 2000 (Oracle), Silvernm (Computer Systems Advisers). 3. Программирование. Средства этой группы поддерживают этапы программирования и тестирования, автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу: COBOL 2/Workbench (Mikro Focus), DECASE (DEC), NETRON/CAP (Netron), APS (Sage Software). Помимо диаграммеров различного назначения и средств поддержки работы с репозиторием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и в динамике), генераторы наборов тестов, анализаторы покрытия тестами, отладчики. 4. СОПРОВОЖДЕНИЕ И РЕИНЖИНИРИНГ. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и реинжениринга: Adpac CASE Tools (Adpac), Scan/COBOL

Классификация по категориям отражает уровень интегрированности CASE средств по выполняемым функциям и включает вспомогательные программы (tools), пакеты разработчика (toolkit) и инструментальные средства (workbench). Категория tool обозначает вспомогательный пакет, решающий небольшую автономную задачу, принадлежащую проблеме более широкого масштаба. Категория toolkit представляет совокупность интегрированных программных средств, обеспечивающих помощь для одного из классов программных задач, использует репозиторий для всей технической и управляющей информации о проекте, концентрируясь при этом на поддержке, как правило, одной фазы или одного этапа разработки ПО. Категория workbench представляет собой интеграцию программных средств, которые поддерживают системный анализ, проектирование и разработку ПО; используют репозиторий, содержащий всю техническую и управляющую информацию о проекте; обеспечивают автоматическую передачу системной информации между разработчиками и этапами разработки; организуют поддержку практически полного ЖЦ (от анализа требований и проектирования ПО до получения документированной выполняемой программы).

Классификация по уровням связана с областью действия CASE средств в ЖЦ ПС, систем и организаций. Однако четкие критерии определения границ между уровнями не установлены, поэтому данная классификация имеет качественный характер. Верхние (Upper) CASE часто называют средствами компьютерного планирования. Они призваны повышать эффективность деятельности руководителей фирмы и проекта путем сокращения затрат на определение политики фирмы и на создание общего плана проекта. Этот план включает цели и стратегии их достижения, основные действия в свете целей и задач фирмы, установление стандартов на различные виды взаимосвязей и т. д. Использование верхних CASE позволяет построить модель предметной области, отражающую всю существующую специфику. Она направлена на понимание общего и частного механизмов функционирования, имеющихся возможностей, ресурсов, целей проекта в соответствии с назначением фирмы. Эти средства позволяют проводить анализ различных сценариев (в том числе наилучших и наихудших), накапливая информацию для принятия оптимальных решений.

Средние (Middle) CASE считаются средствами поддержки этапов анализа требований и проектирования спецификаций и структуры ПО. Их использование значительно сокращает цикл разработки проекта; при этом важную роль играет возможность накопления и хранения знаний, обычно имеющихся только в голове разработчика аналитика, что позволит использовать накопленные решения при создании других проектов. Нижние (Lower) CASE являются средствами разработки ПО (при этом может использоваться до 30% спецификаций, созданных средствами среднего CASE). Они содержат системные словари и графические средства, исключающие необходимость разработки физических спецификаций. Имеются системные спецификации, которые непосредственно переводятся в программные коды разрабатываемой системы (при этом автоматически генерируется до 80 90% кодов). На эти средства возложены также функции тестирования, управления конфигурацией, формирования документации. Главными преимуществами нижних CASE являются: значительное сокращение времени на разработку, облегчение модификаций, поддержка возможностей прототипирования (совместно со средними CASE).

CASE-средства BPWIN и ERWIN BPwin автоматизирует задачи, связанные с построением моделей развития, обеспечивая семантическую строгость. Это необходимо для гарантирования правильности и непротиворечивости результатов. В BPwin применяются следующие методологий: IDEF 0, DFD, IDEF 3. Применение данных методологий в ходе построения моделей бизнес процессов в виде иерархии диаграмм обеспечивает наглядность и полноту их отображения, позволяет анализировать деятельность предприятия в трех информационных разрезах. Первый информационный разрез BPwin - функциональность системы. В рамках методологии IDEF 0 (Integration Definition for Function Modeling) бизнес процесс представляется в виде набора элементов работ. Первая диаграмма в иерархии диаграмм IDEF 0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными. В контекст входит описание цели моделирования, области моделирования, т. е. описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие и точки зрения позиции, с которой будет строиться модель.

Кроме основных видов диаграмм, модель нотации IDEF 0 в BPwin может включать следующие элементы. Диаграмма дерева узлов имеет вид традиционного иерархического дерева, где верхний прямоугольник соответствует работе с контекстной диаграммы. Последующие нижние узлы представляют собой дочерние уровни декомпозиции. Диаграмм деревьев узлов в модели может быть сколько угодно много, поскольку дерево может быть построено на произвольную глубину и необязательно с корня. Диаграммы только для показа (FEO). Чаще всего FEO диаграммы строятся, чтобы показать модель с других точек зрения, а также вырезать важный кусок из сложной диаграммы, рассмотреть вариации модели или проблемной области, проанализировать их, не внося изменений в основную модель. Второй информационный разрез - потоки информации (документооборота) в системе. Диаграммы DFD дополняют то, что уже отражено в модели IDEF 0. Эти диаграммы описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией. Причем, как внутри системы между бизнес функциями, так и системы в целом с внешней информационной средой. Для усиления функциональности в данной нотации диаграмм предусмотрены специфические элементы, предназначенные для описания информационных и документопотоков, такие как внешние сущности и хранилища данных.

Третий информационный разрез последовательность выполняемых работ. В отличие от диаграмм IDEF 0 и DFD, элементы которых позволяют точно описать функциональность системы и организацию документооборота, описать с их помощью логику построения системы не удастся. Для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии IDEF 3, также называемой диаграммами workflow (рабочего процесса). В IDEF 3 включены элементы логики, что позволяет аналитику моделировать и анализировать альтернативные сценарии развития бизнес процесса. Методология моделирования IDEF 3 позволяет графически описывать и документировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.

IDEF 3 предполагает построение двух типов моделей: 1. Модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация. 2. Модель может показывать "сеть переходных состояний объекта", последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс. С помощью диаграмм IDEF 3 можно анализировать сценарии из реальной жизни, например, как осуществлять оформление документов приемке груза. Каждый такой сценарий содержит в себе описание процесса и может быть использован, чтобы наглядно показать или лучше задокументировать бизнес функции организации. В последней версии BPwin существует возможность использования модели Swim Lane, основанной на нотации IDEF 3. Это делает диаграммы данной нотации более читабельными и понятными пользователю. Диаграммы Swim Lane представляют собой диаграмму, разделенную горизонтальными полосками на ролевые области. Название данному виду диаграмм дано по аналогии дорожек для плавания.

ERwin позволяет проводить процессы прямого и обратного проектирования баз данных. Это означает, что по модели данных можно сгенерировать схему базы данных или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования. Для больших, содержащих сотни таблиц моделей данных существенной проблемой становится поиск и исправление ошибок. Решение этой проблемы вручную слишком трудоемкая задача, которая может недопустимо затянуть выполнение проекта. All. Fusion Data Model Validator (ERwin Examiner) позволяет анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. ERwin Examiner дополняет функциональность ERwin, автоматизируя трудоемкую задачу поиска и исправления ошибок. ERwin Examiner может использовать в качестве источника метаданных готовую модель ERwin, DDL скрипт или провести обратное проектирование базы данных. BPwin и ERwin позволяют генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования моделей. Отчеты могут быть экспортированы в распространенные форматы текстовый, MS Office, HTML и др.

Model. Mart хранилище моделей, к которому открыт доступ для участников проекта создания ИС. Model. Mart удовлетворяет всем требованиям, предъявляемым к средствам разработки крупных ИС, а именно: 1. Совместное моделирование. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются три режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь, не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени. Возникающие при этом конфликты разрешаются при помощи специального модуля. В дополнение к стандартным средствам организации совместной работы Model. Mart позволяет сохранять множество версий, снабженных аннотациями, с последующим сравнением предыдущих и новых версий. При необходимости возможен возврат к предыдущим версиям.

2. Создание библиотек решений. Model. Mart позволяет формировать библиотеки стандартных решений, содержащие наиболее удачные фрагменты реализованных проектов, накапливать и использовать типовые модели, объединяя их при необходимости "сборки" больших систем. На основе существующих баз данных с помощью ERwin возможно восстановление моделей (обратное проектирование), которые в процессе анализа пригодности их для новой системы могут объединяться с типовыми моделями из библиотек моделей. 3. Управление доступом. Для каждого участника проекта определяются права доступа, в соответствии с которыми они получают возможность работать только с определенными моделями. Права доступа могут быть определены как для групп, так и для отдельных участников проекта. Роль специалистов, участвующих в различных проектах, может менять ся, поэтому в Model. Mart можно определять права доступа и управлять правами доступа участников проекта к библиотекам, моделям и даже к специфическим областям модели.

4. Архитектура Model. Mart реализована на архитектуре клиент-сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server, Informix и Oracle. Клиентскими приложениями являются ERwin и BPwin. В Model. Mart реализован доступ к хранилищу моделей через API, что позволяет постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа. При разработке крупных проектов критическим становится время реализации проекта. Решением проблемы может стать автоматическая генерация кода приложения CASE средствами на основе модели предметной области. Эту задачу решает технология кодогенерации, основанная на объектно ориентированном проектировании. Существует несколько CASE средств, поддерживающих языки объектно ориентированного проектирования, в том числе ставший в последнее время стандартом UML.

Rational Rose семейство объектно ориентированных CASE средств фирмы Rationa Software Corporation (США). Эти средства предназначены для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rationa Rose использует синтез методологию объектно ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML) претендует на роль стандарта в области объектно ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (С++, Smalltalk, Power. Builder, Ada, SQL Windows). Основной вариант Rational Rose /C++ позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонентов в новых проектах.

Структура и функции. В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций. Они определяют логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозитории, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для C++, обеспечивающий реинжиниринг восстановление модели проекта по исходным текстам программ. Репозиторий представляет собой объектно ориентированную базу данных. Средства просмотра обеспечивают "навигацию" по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сборастатистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.

Средства автоматической генерации кодов программ на языке C++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом «скелет» программы может быть уточнен путем прямого программирования на языке C++. Анализатор кодов C++ реализован в виде отдельного программного модуля. Его назначение создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на C++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. В результате разработки проекта с помощью CASE средства Rational Rose формируются следующие документы: диаграммы классов; диаграммы состояний; диаграммы сценариев; диаграммы модулей; диаграммы процессов; спецификации классов, объектов, атрибутов и операций; заготовки текстов программ; модель разрабатываемой программной системы.

Последний из перечисленных документов является текстовым файлом, который содержит всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций). Тексты программ это заготовки для последующей работы программистов. Тексты программ формируются в рабочем каталоге в виде файлов типов. h (заголовки, содержащие описания классов) и . срр (заготовки программ для методов). Система включает в программные файлы собственные комментарии, которые начинаются с последовательности символов ###. Состав информации, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы. Взаимодействие с другими средствами, и организация групповой работы. Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством So. DA для документирования проектов. Интеграция Rational Rose и So. DA обеспечивается средствами So. DA.

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

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

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

При использовании стандартов создания АС на стадии "Техническое задание" в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. Схема функциональной структуры АС разрабатывается на стадии "Эскизное проектирование" и "Техническое проектирование", описание автоматизируемых функций АС производится на стадии "Техническое проектирование". При разработке АС в соответствии должны быть отслежены с связи между функциональными требованиями к системе и функциями системы, их реализующими. Функции системы в свою очередь должны быть детально описаны. В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций. Как видно из табл. 1, создание АС на стадиях 3 5, подразумевает подготовку: технического задания; предварительной схемы функциональной структуры системы (эскизное проектирование); окончательной схемы функциональной структуры (техническое проектирование); описания автоматизируемых функций системы.

Документы, модели, Наименование создаваемые на стадиях по ГОСТ, в котором № стадии по ГОСТ 34. 601 -90 стадии по ГОСТ ГОСТ 34. 602 -89, описан документ 34. 601 -90 ГОСТ 34. 201 -89 Техническое задание (ТЗ) 3 ГОСТ 34. 602 задание Эскизное Схема функциональной 4 проектирование структуры РД 50 -34. 698 -90 п. 2. 3. Техническое Схема функциональной проектирование структуры 5 Описание автоматизируемых РД 50 -34. 698 -90 п. функций 2. 5

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

Техническое задание – это основной документ, призванный консолидировать все требования к разрабатываемому программному продукту (автоматизированной системе). Его структура и содержание определяется ГОСТ 34. 602 89. Основные разделы технического задания с кратким описанием их назначения. 1. Общие положения 1. 1. Полное наименование системы и ее условное обозначение. 1. 2. Номер договора. 1. 3. Наименование разработчика и заказчика системы и их реквизиты. 1. 4. Перечень документов, на основании которых создается система. 1. 5. Плановые сроки начала и окончания работ. 1. 6. Сведения об источниках и порядке финансирования работ. 1. 7. Порядок оформления и предъявления заказчику результатов работ по созданию системы.

2. Назначение и цели создания системы 2. 1. Назначение системы: вид автоматизируемой деятельности и перечень объектов автоматизации. 2. 2. Цели создания системы: требуемые значения технических, технологических, производственно экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания системы. 3. Характеристика объекта автоматизации 3. 1. Краткие сведения об объекте автоматизации. 3. 2. Сведения об условиях эксплуатации объекта автоматизации.

4. Требования к системе 4. 1. Требования к системе в целом. 4. 1. 1. Требования к структуре и функционированию системы. 4. 1. 2. Требования к численности и квалификации персонала системы и режиму его работы. 4. 1. 3. Требования к надежности. 4. 1. 4. Требования безопасности. 4. 1. 5. Требования к эргономике и технической эстетике. 4. 1. 6. Требования к эксплуатации и техническому обслуживанию. 4. 1. 7. Требования к защите информации от несанкционированного доступа; 4. 1. 8. Требования к сохранности информации при авариях. 4. 1. 9. Требования к защите от влияния внешних воздействий. 4. 1. 10. Требования к патентной чистоте. 4. 1. 11. Любые дополнительные требования. 4. 2. Требования к функциям (задачам), выполняемым системой. (перечень функций (задач), подлежащих автоматизации; временной регламент реализации каждой функции (задачи); требования к качеству реализации каждой функции (задачи), к форме представления выходной информации, к точности и времени выполнения, к достоверности выдачи результатов; перечень и критерии отказов для каждой функции (задачи), для которых определены требования к надежности)

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

4. 3. 4. Требования к программному обеспечению системы. (перечень лицензионных программных продуктов, наличие которых необходимо для функционирования системы в нормальном режиме) 4. 3. 5. Требования к техническому обеспечению. (требования к видам технических средств, программно- технических комплексов и других комплектующих изделий, допустимых к использованию в системе; к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы) 4. 3. 6. Требования к организационному обеспечению. (требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию; к организации функционирования системы и порядку взаимодействия персонала объекта автоматизации; к защите от ошибочных действий персонала системы) 4. 3. 7. Требования к методическому обеспечению (к нормативно технической документации).

5. Состав и содержание работ по созданию (развитию) системы 5. 1. Перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24. 601, сроки их выполнения, перечень организаций исполнителей работ и т. п. 5. 2. Перечень документов, по ГОСТ 34. 201 89, предъявляемых по окончании соответствующих стадий и этапов работ. 6. Порядок контроля и приемки системы 6. 1. Виды, состав, объем и методы испытаний системы в целом и отдельный ее компонентов (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему). 6. 2. Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие Перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу программного продукта в эксплуатацию. 8. Требования к документированию Согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34. 201 89 и непосредственно требованиям заказчика. 9. Источники разработки Перечисляются документы и информационные материалы, на основании которых разрабатывается техническое задание и которые должны быть использованы при создании системы.

Технический проект – это тот документ, который должен стать результатом выполнения этапов эскизного и технического проектирования согласно ГОСТ 34. 601 90. Технический проект должен содержать более детальную проработку требований, изложенных в техническом задании, а также, описание проектных решений, которые предстоит реализовать, чтобы эти требования выполнить. Структура технического проекта строго не регламентируется. Ниже представлены основные разделы, которые в том или ином виде должны присутствовать в документе (наборе документов), отражающих результаты проектирования программного продукта.