Разработка информационной системы

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

Предпосылками для разработки является возможность осуще­ствить постановку задачи своими силами. Постановка задачи пере­дается программисту. На каждом предприятии должна быть ко­манда программистов, а также необходим ИТ-менеджер, который бы руководил всей разработкой; должна быть уверенность в том, что система будет сопровождаться своими силами, а не только раз­рабатываться. Доводом в пользу разработки своими силами явля­ется тиражирование своей разработки в своей отрасли. Заметим, что разработка системы требует наличия инструментов двух видов, т. е. программных средств аналитического и креативного характера.

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

Креативные инструменты – программные средства, которые служат для создания программного обеспечения ИС. Это операци­онные системы, универсальные языки программирования (Delphi, С++), пакеты прикладных программ, СУБД, системы класса Work­flow и др.

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

В отличие от разработки своими силами, разработка на заказ имеет тот плюс, что качество системы выше, время разработки от­носительно невелико и предусматривается фирменное сопровожде­ние оригинальной разработки, а минус – это высокая стоимость и недостаточная управляемость со стороны заказчика, особенно если заказчик не имеет четкой постановки задачи.

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

 

 

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

 

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

Коллектив разработчиков информационной системы должен включать в себя специалистов разного профиля: системных анали­тиков, проектировщиков-специалистов по постановке и алгоритми­зации задач, СУБД и внемашинному информационному обеспече­нию, выбору комплекса технических средств и сетевым проектным решениям, системных и прикладных программистов, специалистов по защите информации, администраторов репозитория, специали­стов по управлению проектами и др.

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

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

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

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

Матричная структура построения проектной группы соответ­ствует процессному подходу в управлении. При организации про­ектной группы может использоваться принцип единоначалия, когда на время выполнения пректа создается отдельное подразделение, в котором объединяются все участники разработки («проектная структура»).

 

 

6.3. Методы и средства организации
метаинформации проекта ИС

 

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

Организация коллективной работы проектной группы требует разработки методов обмена информацией между проектировщи­ками и регистрации результатов разработки в реальном масштабе времени.

В качестве основного метода решения такой задачи использу­ется механизм создания и эксплуатации цифрового хранилища дан­ных о проекте информационной системы. Это хранилище метаин­формации проекта информационной системы принято называть цифровым репозиторием.

Методическими принципами создания репозитория являются:

· многопользовательский режим работы, обеспечивающий со­вместную работу проектной группы;

· разделение прав доступа к проектным решениям со стороны участников разработки;

· хранение версий проектных решений

В качестве средства организации репозитория могут исполь­зоваться распространенные СУБД, например, MS SQL Server, ORACLE, а также системы контроля версий проекта (CVS и др.).

Репозиторий представляет собой ядро и центральный компо­нент CASE-средства.

На рис. 6.3 представлена взаимосвязь основных компонентов CASE-средства на основе репозитория [9].

 

 

Рис. 6.3. Взаимосвязь основных структурных компонентов CASE-средства
на основе репозитория

 

Рассмотрим взаимосвязь компонентов системы автоматизи­-рованного проектирования ИС, использующей репозиторий.

Репозиторий содержит информацию, характеризующую сле­ду­ющие стороны проекта ИС:

· диаграммы;

· связи между диаграммами;

· структуры данных;

· программные модули;

· права доступа проектировщиков ИС и т. д.

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

В репозитории предусматривается архивация и резервное копирование проектных данных.

Графический редактор диаграмм предназначен для отобра­же­ния в заданных нотациях всех диаграмм проектирования ИС. Редактор диаграмм может создавать элементы диаграмм и связи между ними.

Средства контроля и сбора статистики выполняют следующие функции:

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

· выделение на диаграмме ошибочных элементов;

· сбор статистики ошибок в процессе проектирования.

Генератор документов формирует выходные документы, со­дер­жащие диаграммы проекта, в соответствии с запросом проекти­ровщика.

Администратор занимается административными функциями проектирования, куда входят:

· назначение и изменение прав доступа к репозиторию;

· мониторинг процесса проектирования.

Браузер позволяет осуществлять просмотр проекта, в том чис­ле переключение от одной диаграммы к другой и т. д.

Генератор кодов программ на основе моделей проекта, хра­нящихся в репозитории, создает код программы.

 

 

6.4. Планирование и контроль процесса проектирования

 

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

Цена на разработку системы является договорной, т. е. ус­танавливается по согласованию между разработчиком в заказчи­ком. Этот подход касается и сроков сдачи.

Если программный продукт является тиражируемым, его цена устанавливается с учетом конъюнктуры рынка и цен на аналогич­ные программные продукты.

Для планирования и контроля процесса проектирования сис­темы обычно используются следующие документы:

· договор на создание системы, к которому прилагается техни­ческое задание, необходимое как для разработки, так и для приемки системы;

· график выполнения работ;

· акт приемки – сдачи, составляемый после приемки системы.

График выполнения работ для небольших систем имеет обычно форму таблицы, пример которой представлен в виде табл. 6.1.

Таблица 6.1

График выполнения работ

Номер этапа	Содержание работы	Дата начала и окончания этапа	Объем работ, %
	Обследование Постановка задач Адаптирование и программирование Тестирование, отладка, приемка-сдача	1.01–31.09 1.04–30.06 1.06–30.08 1.10–20.12

 

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

 

 

6.5. Сетевое планирование комплекса работ
по проектированию

 

Сетевой график позволяет отразить временную последова­тельность взаимосвязанных работ.

Существует два способа построения сетевых графиков:

· в терминах работ. Работа представляется вершиной графа, а связи между работами – дугами. Этот способ позволяет легко до­полнять пропущенные ранее связи.

· в терминах работ и событий. Этот способ предусматривает использование вершины графа для изображения события, связан­ного с окончанием работы. Работа представляется дугой, идущей к данной вершине. Следовательно, дуги данного графика можно раз­мечать числами, определяющими характеристики работ, например, их продолжительность.

Обычно используется второй способ построения сетевого гра­фика. Такая форма удобна для временного анализа хода выполне­ния работ.

Сетевой график зависит от того, насколько детально мы пред­ставим состав работ в комплексе. Если мы представим работы ук­рупненно, то граф будет выражать лишь их линейную последова­тельность. Так, в CASE-технологии выделяются следующие ра­боты:

 

Проектирование Эксплуатация

 

Анализ требований Программирование

 

В соответствии с рекомендациями, принятыми в нашей стране по проведению работ при создании систем, выделяются похожие, но более детализированные стадии.

Разработка Эскизный Разработка Сопровождение

концепции проект документации

 

 

Формирование Техническое Технический Ввод

требований задание проект в действие

 

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

Пример структурной таблицы приведен в виде табл. 6.2.

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

Сетевая модель процесса проектирования, соответствующая структурной табл. 6.2, представлена на рис. 6.4. Штриховыми линиями на модели представлены фиктивные работы (не имеющие продолжительности и служащие лишь для указания последователь­ности выполнения работ). Заглавными буквами обозначены собы­тия (вершины), показывающие завершение соответствующих работ, обозначенных строчными буквами.

Таблица 6.2

Структурная таблица

Номер события	Наименование работы	Обозначение	Опирается на работы	Время
	Обследование объекта	a 1	–	t 1
8, 9, 10	Сбор данных об отечест­венных и зарубежных сис­темах Формирование требований к функциональной части и обеспечивающим подсис­темам Разработка вариантов сис­темы и выбор оптимального Расчет экономической эф­фективности Оценка научно-техниче­ского уровня Разработка технического задания Постановка задач подсис­тем I, II, III	a 2     a 3   a 4   a 5   a 6   a 7   a 8, a 9, a 10	–     a 1 и а 2   а 3   а 4   а 4   а 5, а 6   а 7	t 2     t 3   t 4   t 5   t 6   t 7   t 8, t 9, t 10

Окончание табл. 6.2

Номер события	Наименование работы	Обозначение	Опирается на работs	Время
11, 12, 13	Программирование задач подсистем I, II, III Опытная эксплуатация и комплексное тестирование Сдача системы в постоян­ную эксплуатацию Сопровождение	a 11, a 12, a 13   a 14   a 15   a 16	а 8, а 9, а 10   а 11, а 12, а 13   а 14   а 15	t 11, t 12, t 13   t 14   t 15   t 16

 

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

		a 3
			a 4			a 7

 

a 2

a 6

a 11

a11

a 8

a8

a 16

a 15

a 14

a 12

a 9

a14 а14 а15 a16

a9 a12

a 10

a10

a 13

a13

 

Рис. 6.4. Сетевая модель процесса проектирования

6.6. Анализ сетевого графика проектирования

 

Использование компьютерных программ позволяет ответить на вопросы, связанные с решением прямых задач (задач анализа) и обратных задач (задач синтеза).

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

Критический путь определяет то минимальное время, за кото­рое может быть выполнен комплекс работ. На нем лежат последо­вательно выполняемые работы, характеризующиеся в сумме наибольшей продолжительностью.

Обратные задачи – это обычно оптимизационные задачи.

Рассмотрим прямые задачи.

Минимально возможный срок окончания i -й работы равняется

Т_i = τ _i + t_i,

где t_i – время выполнения i -й работы;

τ_i – минимально возможный срок начала i -й работы,

где (оп) – множество работ, на которое опирается данная ра­бота.

Расчет ведется от работ первого порядка, которые ни на какие работы не опираются (для ниx t = 0).

Время окончания всего комплекса работ определяется по формуле:

Рассмотрим нахождение критических работ, т. е. работ, лежащих на критическом пути: сначала находят работу, для кото­рой время окончания работы (Т_i) – максимальное. Затем находят ту j -ю работу, которая определяет момент начала этой i -й работы τ _i:

Та j -я работа, на которой достигается этот максимум, будет второй работой на критическом пути и т. д.

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

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

Этот резерв времени может быть произвольно распределен между некритическими работами.

Для анализа сетевого графика на ПК существует целый ряд готовых программных продуктов (например, пакет Тime Linе, Pro­ject Expert и др.).

 

 

6.7. Модели распределения ресурсов
между проектными работами

 

Рассмотрим распределение стоимостных (трудовых и др.) ре­сурсов в комплексе работ по проектированию информационной системы.

Задача распределения ресурсов является двухкритериальной: хочется минимизировать ресурсы и время проектирования. Из­вестно, что «время – деньги» и, следовательно, можно предполо­жить, что время выполнения i -й работы t_i зависит от величины ре­сурсов x_i, вкладываемых в эту работу так, что чем больше ресурсов, тем меньше время, и наоборот (рис. 6.5).

t_i = t_i (x_i),

где x_i – ресурсы, вкладываемые в i -ю работу.

Можно сформулировать несколько задач, отличающихся тем, что принимается за критерий, и что за ограничение.

Задача минимизации ресурсов. Задача возникает тогда, ко­гда в исходном варианте распределения ресурсов общее время вы­полнения работ Т > Т _доп, где Т _доп – допустимое время выполне­ния комплекса работ.

 

xi

 

 

Рис. 6.5. Зависимость времени выполнения работы
от выделенных ресурсов

 

Задача ставится следующим образом:

,

где I – число работ сетевого графика;

(кр) – означает, что суммирование распространяется только на критические работы.

В общем случае задача нелинейная, но если ограничиться не­большими изменениями величин t_i, при которых они линейно зави­сят от дополнительных вложений х_i, и критический путь не меня­ется, то задача решается методами линейного программирования.

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

,

где Х _доп – допустимые ресурсы, находящиеся в распоряже­нии главного специалиста проектной группы.

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

 

 

6.8. Вероятностная оценка выполнения сроков проектирования

 

Если сроки выполнения отдельных этапов проектирования из­вестны заранее достаточно точно, то задача определения общего срока проектирования ИС называется детерминированной.

Однако обычно величины t_i случайны. Отклонение этих вели­чин от заранее заданного значения может быть в обе стороны – как в большую (опоздание), так и в меньшую (опережение). Хотя на практике второе встречается гораздо реже первого.

Закон распределения случайных величии t_i далеко не всегда бывает известен. Чаще удается указать наиболее вероятное значе­ние величины , а также оценить наименьшее («оптимистическое») значение и наибольшее («пессимистическое») значение , ее математическое ожидание М [ t_i ] и среднее квадратическое отклонение s[ t_i ].

Плотность вероятности величины t_i можно изобразить сле­дующим образом (рис. 6.6).

 

 

i

ti

 

 

Рис. 6.6. Распределение вероятностей времени выполнения работы

 

Вид зависимости F (t_i) на качественном уровне определяется следующими соображениями: запаздывание по сравнению с плано­вым сроком обычно значительно больше, чем опережение.

Оценка вероятностного характера влияния отдельных значе­ний t_i на длительность выполнения комплекса работ выполняется с помощью трех способов:

· сценарного подхода;

· аналитического подхода;

· статистических компьютерных испытаний.

Сценарный подход предполагает три расчета для трех сцена­риев: оптимистического, пессимистического и наиболее вероятного случая.

Аналитический подход обычно предполагает, что случайная величина T подчинена нормальному закону распределения. Эта ве­личина является суммой достаточно большого числа случайных ве­личин. Согласно центральной предельной теореме ее закон распре­деления близок к нормальному (независимо от законов распреде­ления слагаемых).

При этом ее математическое ожидание и среднее квадратиче­ское отклонение могут быть представлены как

М [ T ] =

Используя известную функцию Лапласа Ф, можно определить вероятность выполнения комплекса работ по проектированию ИС в установленный срок Т _доп

Р (Т ≤ Т _доп) = .

Такой поход используется для относительно небольшого ко­личества работ.

Если работ много, то используется третий метод, т. е. ме­тод статистических испытаний (метод Монте-Карло). Этот метод предусматривает многократные расчеты длительности выполнения комплекса работ. Каждый расчет требует предварительного уста­новления совокупности случайных значений t_i с помощью датчика случайных чисел. На основании большого количества расчетов можно получить статистический ряд значений случайной величины Т и ее числовые характеристики.

 

 

Рис. 6.7. Направления развития информационных систем
и их проектирова­ния

Значение вероятности Р (Т ≤ Т _доп) будет приближаться к час­тоте событий в большой серии расчетов.

Перспективы развития ИС и их проектирования зависят от ряда факторов, к числу которых относятся инновации в области менеджмента, достижения в сфере информационных технологий и совершенствование методов и средств проектирования.

Основные направления развития ИС и их проектирования представлены на рис. 6.7.

 

Вопросы для самопроверки по главе 6

 

1. Назовите возможные пути создания информационной системы.

2. Какие различают методы внедрения ИС?

3. В чем состоит организация процесса проектирования информацион­ной системы?

4. В чем состоит назначение репозитория при проектировании ИС?

5. С какими структурными компонентами CASE-средства связан репози­торий?

6. В чем состоит назначение сетевого графика комплекса работ по проек­тированию информационной системы?

7. Дайте определение критического пути в сетевом графике.

8. Какова структура моделей распределения ресурсов между работами при проектировании информационных систем?

9. Назовите основные подходы к вероятностной оценке выполнения сро­ков проектирования.

ЗАКЛЮЧЕНИЕ

 

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

Функциональность информационной системы должна соответ­ствовать информационным потребностям пользователей с учетом стратегического плана развития предприятия (корпорации).

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

При выборе технологии проектирования следует отдать пред­почтение технологии типового проектирования в тех случаях, когда функциональность типовой системы на 80% и более удовлетворяет информационные потребности пользователей.

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

Информационные системы, как живой организм, постоянно развиваются и совершенствуются.

Совершенствование функциональности ИС связывается с процессным подходом в управлении, управлением бизнес-процес­сами (Business Process Management System, BPMS).

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

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

Все большее применение для поддержки принятия решений находят технологии оперативной аналитической обработки инфор­мации – OLAP-технологии (Online Analytical Processing). Для осуще­ствления такого, обычно многомерного, анализа, требуется инфор­мация, накапливаемая в больших объемах за длительный период времени, хранящаяся в разнородных базах данных, объединяемых в хранилище данных (Data Warehouse).

Применение бизнес-процессов, состоящих из бизнес-функций, привело к возникновению сервисно-ориентированной архитектуры ИС, в которой бизнес-функции обслуживаются IT-сервисами в со­ответствии с соглашением об уровне качества сервиса (Service Level Agreement, SLA). Очевидно, что эффективное использование сервисно-ориентированных ИС связано со стандартизацией как биз­нес-процессов управления, так и входящих в них бизнес-функций.

Стандартизация в управлении должна сблизить функциональ­ность типовых информационных систем с информационными по­требностями пользователей. Очевидно, что стандартизация должна охватывать не только систему управления объектом, но и процессы проектирования информационных систем. Стандарты в области ка­чества информационных систем, ведущие начало от концепции всеобщего управления качеством (Total Quality Management, TQM), должны лежать в основе менеджмента качества проектов информа­ционных систем.

Перспективным направлением в области информатизации яв­ляется IT-аутсорсинг, предполагающий передачу ряда задач обра­ботки информации для предприятия внешнему исполнителю. IT-аутсорсинг особенно целесообразен для предприятий малого и среднего бизнеса, не обладающих собственными значительными информационными ресурсами. Примерами такого вида интернет-ус­луг являются услуги провайдеров приложений (Application Service Provider, ASP) и услуги поставщиков облачных вычислений (Cloud Computing) – фирм-владельцев крупных центров обработки данных.

На основе web-технологий строятся электронные (виртуаль­ные) предприятия (корпорации), которые представляют собой пер­спективную форму объединения свободных производственных мощностей пространственно распределенных хозяйствующих субъектов.

Новым фактором на рынке программного обеспечения ин­формационных систем явилось появление свободного програм­м­ного обеспечения (Open Source), бесплатно распространяемого че­рез Интернет. Его использование требует экономического обоснова­ния с учетом издержек на сопровождение на протяжении жизнен­ного цикла программного продукта.

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

Применение экспертных систем, нечеткого моделирования, нейросетевых методов, а также голосового, сенсор­ного человеко-машинного интерфейса, сканирования информации и когнитивной графики составляет основу интеллектуализации ИС.

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

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

 

 

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

 

Нормативные правовые акты

 

1. ГОСТ 34.602–89. Техническое задание на создание автомати­зированной системы. М.: Изд-во стандартов, 2003.

2. ГОСТ 34.601–90. Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания. М.: Изд-во стандартов, 2003.

3. ГОСТ Р ИСО/МЭК 12207–99. Информационная технология. Процессы жизненного цикла программных средств. М.: Изд-во стандартов, 2003.

4. ГОСТ 34.698–90. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов. URL: http://www.standards.ru/.

5. ГОСТ 19.701–90. Единая система программной документа­ции. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения. URL: http://www.standards.ru/.

6. ГОСТ 7.32–2003. Система станд

⇐ Предыдущая6789101112131415

Поделиться:

Воспользуйтесь поиском по сайту: