ПРАКТИЧЕСКИХ РАБОТ

ПО ДИСЦИПЛИНЕ

«ТЕОРИЯ ТЕХНИЧЕСКИХ СИСТЕМ»

(для студентов специальностей

заочной формы обучения)

Макеевка – 2010


МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ

ДОНБАССКАЯ НАЦИОНАЛЬНАЯ АКАДЕМИЯ

СТРОИТЕЛЬСТВА И АРХИТЕКТУРЫ

Кафедра “Подъемно-транспортные, строительные, дорожные машины

и оборудование”

МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ВЫПОЛНЕНИЮ

ПРАКТИЧЕСКИХ РАБОТ

ПО ДИСЦИПЛИНЕ

«ТЕОРИЯ ТЕХНИЧЕСКИХ СИСТЕМ»

(для студентов специальностей

7.090214 «Подъемно-транспортные, строительные, дорожные,

мелиоративные машины и оборудование» и

7.090258 «Автомобили и автомобильное хозяйство»

заочной формы обучения)

Макеевка – 2010


УДК 681.51:519.21

Методические указания к выполнению практических работ по дисциплине «Теория технических систем» (для студентов специальностей 7.090214 «Подъемно-транспортные, строительные, дорожные, мелиоративные машины и оборудование» и 7.090258 «Автомобили и автомобильное хозяйство» заочной формы обучения) / Сост.: В.А. Пенчук, Н.А. Юрченко.- Макеевка: ДонНАСА, 2010.- 25 с.

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

Составители: проф. В.А. Пенчук

асс. Н.А. Юрченко

Рецензенты: доц. А.К. Кралин

доц. В.А. Талалай

Ответственный за выпуск проф. В.А. Пенчук


ПРАКТИЧЕСКАЯ РАБОТА

СОСТАВЛЕНИЕ ЖИЗНЕННОГО ЦИКЛА

ТЕХНИЧЕСКОЙ СИСТЕМЫ»

Цель работы: получение практических навыков в составлении жизненного цикла технической системы.

Порядок выполнения работы:

1. Изучить структуру и этапы жизненного цикла технических систем.

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

3. Разработать общую схему жизненного цикла для заданной системы.

ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

Структура жизненного цикла технической системы .

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

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

Рисунок 1.1 – Жизненный цикл технической системы:

ТЗ – техническое задание; РД – рабочая документация; TS – техническая система; акт – акт утилизации

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

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

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

При любой системе производственной деятельности в создании, реализации и эксплуатации технических систем действуют три взаимосвязанных процесса: разработки «Р »; производства «П р » и эксплуатации «Э». Процессы «Р » и «П р » могут выполняться одной специализированной формой, что позволяет повысить качество технической системы в сфере эксплуатации «Э ».

Не зависимо от функциональных и экономических связей объектов «Р » и «П р » в них должны быть следующие цеха или отделы: исследовательский, конструкторско-технологический, испытательный, производственный, материально-технического снабжения, предпродажной подготовки и другие по специфике технической системы.

Этапы жизненного цикла технической системы.

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

Таблица 1.1 – Распределение основных этапов жизненного цикла

технической системы между организациями

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

Административные противоречия – это противоречия, которые возникают в начале технической задачи, когда надо принимать решение: кем делать, кто финансирует, где делать и т.д.?

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

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

Необходимо четко различать противоречия, которые возникают на стадии разработки технического задания (ТЗ) на техническую систему и на стадиях проектирования и конструирования, изготовления и эксплуатации. Стадия разработки «ТЗ» предназначена для решения вопросов «почему», что относится к научно-техническим задачам, на остальных стадиях решаются вопросы «как делать».

Техническое творчество. Процесс создания новых технических решений называют техническим творчеством . Техническое творчество предполагает преобразование уже известных знаний, учений и опыта в новые технические системы. Техническое творчество весьма многообразно и происходит во всех областях техники, оно может быть условно разделено на такие виды деятельности: инженерно-исследовательскую, инженерно-конструкторскую и инженерно-технологическую. В первом случае устанавливаются новые закономерности процессов и технических систем, дается ответ на вопрос «почему это происходит?». Во втором – создаются новые технические системы в виде рабочей документации, моделей, макетов, а в третьем – в виде реальных технических систем.

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

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

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

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

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

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

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

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

C, %

Рисунок 1.2 – Ориентировочное распределение затрат на зарплату при создании технических систем

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

Преимущества такого подхода – сведение задач более сложного уровня к ряду задач малой сложности не вызывает сомнений и поэтому специалистами всего мира применяется ЕСКД (единая система конструкторской документации), которая устанавливает следующую иерархию технической системы типа «объект» машиностроения: детали; сборочные единицы, комплексы, комплекты. По аналогии можно расчленить техническую систему типа «процесс» на операции, процедуры, этапы и стадии.

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

Логику проектировщика технических систем и ее взаимосвязь с этапами проектирования можно представить следующей таблицей (табл. 1.2).

Таблица 1.2

Логика процесса Основное содержание Этап проектирования
Постановка Задачи Определение потребности создания изделия Расчет ожидаемого эффекта при использовании нового изделия Техническое задание
Определение области исследования Установление показателя эффективности для сравнения вариантов Количественное выражение показателя эффективности Сужение области поиска Выбор решения Анализ информации и принятие решения Формулировка задания (перечень характеристик изделия) Техническое предложение
Формирование новых идей Выработка концепции изделия Эскизный проект
Инженерный анализ, оптимизация Определение показателя эффективности Технический проект
Проверка и анализ результатов проверки Конкретизация решения – разработка технической документации Разработка методов изготовления и технической документации к ним Создание экспериментального образца Рабочая документация
Организация производства Испытания, уточнение документации и принятие решения Серийное изготовление
Оценка эффективности на этапе эксплуатации Эксплуатация изделия Эксплуатация

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

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

ВАРИАНТЫ ЗАДАНИЙ

Вариант задания студент выбирает по двум последним цифрам зачетной книжки.

№ зачетной книжки Техническая система № зачетной книжки Техническая система
Башенный кран Компьютер
Мостовой кран Ноутбук
Козловой кран Парта
Стреловой кран Стол
Автомобиль Стул
Бульдозер Кресло
Скрепер Тумба
Конвейер Шкаф
Автобетоносмеситель Комбайн
Бензовоз Дверной замок
Автобус Настольная лампа
Микроавтобус Аудиторная доска
Телевизор Тахометр
Магнитофон Часы
Холодильник Гаечный ключ
Микроволновая печь Аккумулятор
Компьютер Насос
Ноутбук Вентилятор
Парта Башенный кран
Стол Мостовой кран
Стул Козловой кран
Кресло Стреловой кран
Тумба Автомобиль
Шкаф Бульдозер
Комбайн Скрепер
Дверной замок Конвейер
Настольная лампа Автобетоносмеситель
Аудиторная доска Бензовоз
Тахометр Автобус
Часы Микроавтобус
Гаечный ключ Телевизор
Аккумулятор Магнитофон
Насос Холодильник
Вентилятор Микроволновая печь
Башенный кран Компьютер
Мостовой кран Ноутбук
Козловой кран Парта
Стреловой кран Стол
Автомобиль Стул
Бульдозер Кресло
Скрепер Тумба
Конвейер Шкаф
Автобетоносмеситель Комбайн
Бензовоз Дверной замок
Автобус Настольная лампа
Микроавтобус Аудиторная доска
Телевизор Тахометр
Магнитофон Часы
Холодильник Гаечный ключ
Микроволновая печь Аккумулятор

Контрольные вопросы:

1. Дайте определение категории «жизненный цикл» технической системы.

2. Что включает в себя структура жизненного цикла?

3. Назовите основные этапы жизненного цикла.

4. Какие типы противоречий возникают в проблемной ситуации?

5. Чем отличаются административные противоречия от технических?

6. На какие виды деятельности может условно разделено техническое творчество?

7. Что такое научно-исследовательское творчество?

8. Что такое проектирование и конструирование?

9. От каких факторов зависит качество проектной документации?

10. Назовите характерное распределение затрат на создание технической системы?


ПРАКТИЧЕСКАЯ РАБОТА

«ПОСТРОЕНИЕ РЯДОВ ТЕХНИЧЕСКИХ СИСТЕМ»

Цель работы: научиться построению рядов технических систем.

Порядок выполнения работы:

1. Дать определения понятиям: параметр, ряд, ряд предпочтительных чисел, модульный ряд, ряд золотого сечения, ряд Фибоначчи.

2. Согласно заданию определить первые десять членов рядов: Фибоначчи, модульного, мультипликационного и предпочтительного.

ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

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

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

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

Параметр – величина, характеризующая какие-либо свойства технической системы.

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

Формируя новые технические системы, необходимо исходить из того, что они должны содержать наименьшее число модулей, для обеспечения минимальных затрат на её изготовление и эксплуатацию. Для возможности сборки технической системы необходимо согласовать расположение модуль-узлов как по горизонтали (на одном уровне), так и по вертикали (на других уровнях). Все известные системы согласования параметров базируются на следующих основных принципах: пропорциональности, аддитивности, мультипликативности.

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

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

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

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

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

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

Ряды и их свойства весьма разнообразны и зависят от вида первых двух членов. Наиболее широко используются цельно числовой ряд Фибоначчи: 1; 1; 2; 3; 5; 8; 13; 21; 34; 55; 89; 144 и т.д. Как видно, значения членов ряда вначале растут медленно, а затем их рост становится стремительным. Например, двенадцатый член ряда а 12 = 377, т.е. во много раз превышает значение первого члена а 1 = 1.

Ряд золотого сечения (золотой ряд) представляет собой последовательность чисел, которая подчиняется закону

Золотое сечение - это такое пропорциональное деление отрезка (рис. 2.1) на неравные части, при котором весь отрезок так относится к большей части, как сама большая часть относится к меньшей; или другими словами, меньший отрезок так относится к большему, как больший ко всему

a: b = b: c или с: b = b: а.

Рисунок 2.1 - Схема разбиения отрезка по методу золотого сечения

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

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

где - линейный модуль; - член ряда.

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

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

Мультипликационные ряды в основном основаны на использовании закономерностей геометрических прогрессий

где - знаменатель прогрессии; - номер -го члена ряда.

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

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

В 1953 году многими странами было принято к использованию международную систему построения числовых рядов. Эти численные ряды получили название рядов предпочтительных чисел (табл. 2.1).

Ряды предпочтительных чисел (РПЧ) представляют собой десятичные ряды геометрической прогрессии вида , т.е. знаменатель ряда , где - номер ряда = 5; 10; 20; 40 и .

Таблица 2.1 - Основные ряды предпочтительных чисел

Основные ряды Номер предпочтительного числа Разность меж-ду числами и расчетными величинами, %
1,00 1,60 2,50 4,00 6,30 10,00 1,00 1,25 1,60 2,00 2,50 3,15 4,00 5,00 6,30 8,00 10,00 1,00 1,25 1,40 1,60 2,00 2,12 2,24 2,50 2,80 3,15 3,55 4,00 4,50 5,00 5,60 6,30 7,10 8,00 9,00 10,00 1,00 1,06 1,12 1,18 1,25 1,32 1,40 1,50 1,60 1,70 1,80 1,90 2,00 2,12 2,24 2,36 2,50 2,65 2,80 3,00 3,15 3,35 3,55 3,75 4,00 4,25 4,50 4,75 5,00 5,30 5,60 6,00 6,30 6,70 7,10 7,50 8,00 8,60 9,00 9,50 10,00 +0,07 -1,18 -0,71 -0,71 -1,01 -0,88 +0,25 +0,95 +1,26 +1,22 +0,87 +0,42 +0,31 +0,06 -0,48 -0,47 -0,49 -0,65 +0,49 -0,39 +0,01 +0,05 -0,22 +0,47 +0,78 +0,74 +0,39 +0,24 -0,17 -0,42 +0,73 -0,15 +0,25 +0,29 +0,01 +0,71 +1,02 +0,98 +0,63

Примечание. Расчетные величины чисел, указанные в таблице, представляют собой величины, вычисленные с точностью до 5-й значащей цифры; при этом погрешность по сравнению с теоретической величиной составляет менее 0,00005

В зависимости от согласования параметров Т-систем необходимо применять тот или иной номер ряда. Например, для назначения главного параметра – емкости ковша одноковшового экскаватора применяется ряд R5, соответственно знаменатель ряда равен и ряд по емкости ковша (м 3) представляет 0,15; 0,25; 0,4; 0,65; 1,1; 1,6; 2,5.

При назначении главного параметра самоходных стреловых кранов (грузоподъемности) также принят ряд R5 и грузоподъемность крана (т) представляет ряд 4; 6; 10; 16; 25; 40; 64; 100; 160; 250 и т.д.

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

ВАРИАНТЫ ЗАДАНИЙ

Студент выбирает вариант задания по последним двум цифрам зачетной книжки (табл. 2.2 и 2.3).

Таблица 2.2 - Варианты заданий для ряда Фибоначчи и модульного ряда

№ зачетной книжки Фибоначчи модульного № зачетной книжки Фибоначчи модульного

Таблица 2.3 - Варианты заданий для мультипликационного и

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

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.

Процессы создания автоматизированных систем ( АС ), в состав которых входит и ПО , регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

В соответствии со стандартом ISO / IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).


Рис. 5.1.

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

5.2. Основные процессы ЖЦ ПС

Процесс приобретения состоит из действий и задач заказчика, приобретающего ПС. Данный процесс охватывает следующие действия :

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

Инициирование приобретения включает следующие задачи:

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

Заявочные предложения должны содержать:

  1. требования, предъявляемые к системе;
  2. перечень программных продуктов;
  3. условия приобретения и соглашения;
  4. технические ограничения (например, по среде функционирования системы).

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

Подготовка и корректировка договора включает следующие задачи:

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

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

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

  1. инициирование поставки;
  2. подготовку ответа на заявочные предложения;
  3. подготовку договора;
  4. планирование работ по договору;
  5. выполнение и контроль договорных работ и их оценку;
  6. поставку и завершение работ.

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

  1. принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;
  2. разработку поставщиком плана управления проектом, содержащего организационную структуру проекта, разграничение ответственности, технические требования к среде разработки и ресурсам, управление субподрядчиками и др.

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

Процесс разработки включает следующие действия:

  1. подготовительную работу;
  2. анализ требований, предъявляемых к системе;
  3. проектирование архитектуры системы;
  4. анализ требований, предъявляемых к программному обеспечению;
  5. проектирование архитектуры программного обеспечения;
  6. детальное проектирование программного обеспечения;
  7. кодирование и тестирование программного обеспечения;
  8. интеграцию программного обеспечения;
  9. квалификационное тестирование программного обеспечения;
  10. интеграцию системы;
  11. квалификационное тестирование системы;
  12. установку программного обеспечения;
  13. приемку программного обеспечения.

Подготовительная работа начинается с выбора модели ЖЦ ПО , соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбирать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки , а также составить план выполнения работ .

Анализ требований, предъявляемых к системе, подразумевает определение ее функциональных возможностей, пользовательских требований , требований к надежности, безопасности, требований к внешним интерфейсам, производительности и т.д. Требования к системе оцениваются, исходя из критериев реализуемости и возможности проверки при тестировании.

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

Анализ требований к программному обеспечению предполагает определение следующих характеристик для каждого компонента ПО :

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

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

Проектирование архитектуры ПО включает следующие задачи для каждого компонента ПО :

  1. трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
  2. разработку и документирование программных интерфейсов ПО и баз данных (БД);
  3. разработку предварительной версии пользовательской документации;
  4. разработку и документирование предварительных требований к тестам и плана интеграции ПО.

Детальное проектирование ПО включает следующие задачи:

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

Кодирование и тестирование ПО включает следующие задачи:

  1. кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
  2. тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
  3. обновление документации (при необходимости);
  4. обновление плана интеграции ПО.

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

Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (

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

  1. Подготовительная работа, которая включает проведение оператором следующих задач:

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

1. Жизненный цикл ИС и его структура. 2

1.1 Стадии жизненного цикла ИС.. 3

1.2 Стандарты жизненного цикла ИС.. 4

2. Модели жизненного цикла. 6

2.1 Типы моделей жизненного цикла ИС.. 6

2.2 Достоинства и недостатки моделей жизненного цикла ИС.. 8

3. Процессы жизненного цикла ИС.............................................................. 11

3.1 Основные процессы жизненного цикла. 11

3.2 Вспомогательные процессы жизненного цикла. 13

3.3 Организационные процессы.. 14

Список использованной литературы.. 16


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

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

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

Полный жизненный цикл информационной системы включает в себя, как правило, стратегическое планирование, анализ, проектирование, реализацию, внедрение и эксплуатацию. В общем случае жизненный цикл можно в свою очередь разбить на ряд стадий. В принципе, это деление на стадии достаточно произвольно. Мы рассмотрим один из вариантов такого деления, предлагаемый корпорацией Rational Software – одной из ведущих фирм на рынке программного обеспечения средств разработки информационных систем (среди которых большой популярностью заслуженно пользуется универсальное CASE-средство Rational Rose).


1.1 Стадии жизненного цикла ИС

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

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии.

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

1) Начальная стадия

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

2) Стадия уточнения

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

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

В конце стадии уточнения проводится анализ архитектурных решений и способов устранения главных факторов риска в проекте.

3) Стадия конструирования

На стадии конструирования разрабатывается законченное изделие, готовое к передаче пользователю.

По окончании этой стадии определяется работоспособность разработанного программного обеспечения.

4) Стадия передачи в эксплуатацию

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

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

1.2 Стандарты жизненного цикла ИС

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

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

ISO/IEC 12207(International Organization of Standardization /International Electrotechnical Commission)1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последоват ельно дорабатываемых прототипов.


2. Модели жизненного цикла

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

Модель ЖЦ ИС включает в себя:

результаты выполнения работ на каждой стадии;

ключевые события - точки завершения работ и принятия решений.

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

2.1 Типы моделей жизненного цикла ИС

В настоящее время известны и используются следующие модели жизненного цикла:

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

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

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

Рис. 2.1. Каскадная модель ЖЦ ИС

Рис. 2.2. Поэтапная модель с промежуточным контролем

Рис. 2.3. Спиральная модель ЖЦ ИС

На практике наибольшее распространение получили две основные модели жизненного цикла:

каскадная модель (характерна для периода 1970-1985 гг.);

спиральная модель (характерна для периода после 1986.г.).

2.2 Достоинства и недостатки моделей жизненного цикла ИС

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

Жизненный цикл системы является старейшим методом построения информа­ционных систем, в наши дни он используется при создании сложных проектов среднего и крупного масштабов. Данный процесс включает в себя шесть этапов: 1) подготовка проекта; 2) исследование системы; 3) проектирование; 4) програм­мирование; 5) инсталляция; 6) эксплуатация и освоение системы. Эти этапы изо­бражены на рис. 10.7. Каждый этап включает в себя несколько процессов.

Данная методика предполагает четкое разделение труда между конечными пользователями и специалистами по информационным системам. Технические

Systems lifecycle (жизненный цикл системы)

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

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

Этапы жизненного цикла системы

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

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

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

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



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

Project definition (определение проекта)

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

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

Design (проектирование)

Этап, на котором разрабатываются проектные спецификации для системного

Programming (программирование)

На данном этапе проектные спецификации транслируются в программный код.

Installation (установка)

Данный этап состоит из трех процессов: тестирования, обучения персонала и конверсии; последних подготовительных стадий перед вводом системы в экс­плуатацию. Postimplementation (эксплуатация и освоение системы)

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

небольших настольных систем, которые по своей природе более индивидуализи­рованы, т. е. «настроены» на определенного пользователя.

Создание прототипа

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

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

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

На рис. 10.8 изображен процесс создания прототипа, состоящий из четырех сле­дующих этапов (шагов):

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

Шаг 2. Разработка начального прототипа. Проектировщик быстро создает ра­бочую модель, используя программное обеспечение нового поколения, мультиме­дийные программы или системы автоматизированного проектирования (см. гл. 14).

Шаг 3. Работа с прототипом. Пользователь оценивает работу системы и дает рекомендации по ее улучшению.

Prototyping (создание прототипа)

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

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

Процесс неоднократного повторения нескольких этапов в процессе создания системы.

Шаг 4. Исправление и совершенствование прототипа. Проектировщик реали­зует на практике все пожелания пользователей. После внесения изменений и ис­правления ошибок процесс возвращается к шагу 3. Шаги 3 и 4 повторяются до тех пор, пока пользователь не будет полностью удовлетворен.

Когда итерации прекращаются, модель становится «рабочим прототипом», на основе которого составляются окончательные спецификации системы. Иногда та­кой прототип просто используется как рабочая версия информационной системы.

Использование прототипа: достоинства и недостатки

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

End-user interface (пользовательский интерфейс)

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

Но быстрое создание прототипа может создать иллюзию ненужности некото­рых важных этапов разработки системы. Если завершенная модель работает нор­мально, руководство компании может решить, что такие процессы, как програм­мирование, реконструкция системы и подготовка исчерпывающей документации, не играют существенной роли в создании полностью работоспособной системы. Некоторые из систем, созданные в такие сжатые сроки, не могут оперировать большими объемами данных или же не в состоянии поддерживать много пользо­вателей одновременно. Процесс создания прототипа может также сильно замед­литься, если в нем участвуют слишком много пользователей (Hardgrove, Wilson, and Eastman, 1999).

Пакеты прикладных программ

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

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

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

Application software package (пакет прикладных программ)

Набор программ, готовых к работе, которые можно приобрести или взять в аренду.

Customization (кастомизация)

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

Выбор программного пакета

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

Разработка конечными пользователями

Некоторые типы информационных систем могут разрабатываться конечными пользователями при незначительном участии технических специалистов. Этот феномен носит название разработки конечными пользователями. Используя языки программирования четвертого поколения, графические языки и специальные утилиты для персональных компьютеров, пользователи могут манипулировать данными, создавать отчеты и даже формировать полноценные информационные системы для собственного пользования, причем им даже не всегда нужна помощь профессиональных системных аналитиков или программистов. Многие такие си-

Request for proposal (RFP) (запрос предложений)

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

End-user development (разработка конечными пользователями)

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

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

Из рабочей учебной программы:

Тема 2. Стандарты и нормативные руководства по системной и программной инженерии.

Стандарт ISO/IEC 15288 «Системная инженерия - процессы жизненного цикла систем".

ГОСТ 34: Комплекс стандартов на автоматизированные системы.

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

2.1. Стандарт ISO 15288 «Системная инженерия - процессы жизненного цикла систем".

2.2. Жизненный цикл системы.

2.3. Представления жизненного цикла системы.

2.4. Жизненный цикл информационной системы

2.5. Модели жизненного цикла

2.6. Выбор модели жизненного цикла

2.1. Стандарт iso 15288 «системная инженерия - процессы жизненного цикла систем".

Системная инженерия применяется для решения проблем, связанных с ростом сложности рукотворных систем. Стандарт ISO 15288, описывающий методы системной инженерии, предписывает иметь описание жизненного цикла системы и его практик. Такое описание требуется для успешного продвижения системы по жизненному циклу. Но стандарт не указывает на методы, с помощью которых требуется создавать подобное описание.

Задачи стандарта:

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

    Внедрить в практику организации ряд ключевых идей системной инженерии:

    • системного подхода

      жизненного цикла

      инжиниринга требований

      архитектурного дизайна

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

      проектного подхода

      культуры контрактации

Ис т ория создания

    Совместная разработка ISOиIEC, активное участиеINCOSE

    Начало работ в 1996, версии в 2002, 2005 (ГОСТ Р ИСО/МЭК 15288-2005), 2008

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

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

2.2. Жизненный цикл системы

Аббревиатура русск: ЖЦ

Аббревиатура англ: LC (Life Cycle )

Русский: «жизненный цикл» . Английское life cycle в технике ранее означало и переводилось как «срок службы», и иногда даже «срок службы до первого капитального ремонта». «Жизненный цикл» -- это относительно новый перевод. Иногда «цикл» переводят как «период», но такой перевод не устоялся (хотя он и точнее в данном случае: «период жизни» системы). Слово «цикл» не должно смущать – ничего циклического в жизненном цикле нет. Слово «цикл» имеет смысл «типичности», говоря о том, что то же самое происходит и с другими системами.

Формально: жизненный цикл – это смена состояний системы (эволюция системы) в период времени от замысла до прекращения её существования.

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

Определения.

    Определение стандарта ISO/IEC 15288:2008 (Определение: life cycle -- evolution of a system, product, service, project or other human-made entity from conception through retirement (ISO 15288, 4.11):

жизненный цикл (ЖЦ) – это эволюция системы, продукции, услуги, проекта или иного рукотворного объекта от замысла до прекращения использования.

    Определение стандарта ISO 15704 (Industrial automation systems - Requirements for enterprise-reference architectures and methodologies Системы промышленной автоматизации. Требования к архитектуре эталонных предприятий и методологии. Описывает эталонную архитектуру предприятия и средства реализации проектов в рамках полнрго жизненного цикла предприятия):

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

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

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

Таблица 2.1

Стадии создания систем (ISO/IEC 15288)

№ п./п

Стадия

Описание

Формирование концепции

Анализ потребностей, выбор концепции и проектных решений

Разработка

Проектирование системы

Реализация

Изготовление системы

Эксплуатация

Ввод в эксплуатацию и использование системы

Поддержка

Обеспечение функционирования системы

Снятие с эксплуатации

Прекращение использования, демонтаж, архивирование системы