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

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

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

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

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

Макеевка – 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 - Варианты заданий для мультипликационного и

УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ФИНАНСОВАЯ АКАДЕМИЯ

ПРИ ПРАВИТЕЛЬСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ»

Кафедра «Информационные технологии»

РЕФЕРАТ

Тема: «Роль экономиста в создании и эксплуатации

Выполнила:

студентка группы У5-3

Научный руководитель:

профессор кафедры «Информационные технологии»

д. э.н., профессор

Москва 2007

Введение.. 3

1. Стадии и этапы разработки информационных систем... 4

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

1.2. CASE-технологии проектирования ИС.. 8

1.3. Модели жизненного цикла, применяемые в CASE-технологиях. 8

1.4. Принципы создания и функционирования экономических информационных систем 12

1.5. Требования стандартов по разработке информационных систем.. 12

2. Роль экономиста на различных фазах жизненного цикла информационной системы бухгалтерского учета.. 16

2.1. Предпроектная стадия жизненного цикла. 16

2.2. Проектирование и разработка информационной системы.. 19

2.3. Внедрение информационной системы.. 19

Заключение.. 20

Литература.. 20

Введение

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

Важное место среди профессионально-ориентированных ИС играют информационные системы бухгалтерского учета (ИС БУ). Примером такой системы, занимающей лидирующее положение в России и ряде зарубежных стран, является программный продукт «1С: Бухгалтерия 8.0», входящей в систему программ «1С: Предприятие 8.0».

Система «1С: Бухгалтерия 8.0» предназначена для автоматизации бухгалтерского и налогового учета, включая подготовку обязательной (регламентированной) отчетности, в организациях, осуществляющих любые виды коммерческой деятельности: оптовую и розничную торговлю, оказание услуг, производство и т. д. Бухгалтерский и налоговый учет ведется в соответствии с действующим законодательством Российской Федерации .

Структурно система «1С: Бухгалтерия 8.0» включает технологическую платформу «1С: Предприятие 8.0» и конфигурацию «Бухгалтерия предприятия». Конфигурация, являясь прикладным решением, определяет правила ведения учета; она должна быть настроена на структуру, профиль и особенности конкретного предприятия. И в этом, прежде всего, роль экономиста в создании и внедрении ИС БУ, хотя, безусловно, проектирование и разработка ИС БУ, осуществляемая фирмой 1С, не может быть реализована без тесного взаимодействия IT-специалистов с профессиональными экономистами, менеджерами, бухгалтерами, аудиторами, экспертами различных управленческих уровней, прежде всего высших и средних.

На этапе эксплуатации ИС БУ главная роль переходит к профессионалам экономического профиля – именно они, в первую очередь представители низшего звена, используют ИС БУ для решения прикладных финансово-экономических задач.

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

1. Стадии и этапы разработки информационных систем

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

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

Жизненный цикл ИС достаточно продолжителен. Создание ИС, как сложных систем, предназначенных для длительной регулярной эксплуатации во многих организациях, характеризуется жестким, строго регламентированным промышленным подходом. К ИС предъявляются особые требования по их эффективности, надежности, помехоустойчивости функционирования, выбору модели хранения данных. Часто ставится задача получения результатов за четко определенное время, не превышающее заданное. Значительное внимание уделяется отладке и тестированию – как отдельных компонент, так и всей ИС в целом. Вводятся элементы дублирования с использованием методов многовариантного программирования, когда одна и та же задача одновременно решается по нескольким алгоритмам и результат определяется при совпадении выходных значений каждого из них. С целью локализации ошибок и нераспространения их влияния устанавливаются программные блоки защиты и восстановления от сбоев и ошибок, вызванных поступлением на обработку недопустимых либо искаженных исходных данных, неисправностью аппаратуры или возможностью реализации в комплексе некорректного интерфейса между какими-то его многочисленными компонентами.

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

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

Рис. 1.1. Схема жизненного цикла ИС по

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

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

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

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

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

Схема жизненного цикла ИС (программного изделия как большого комплекса программ вместе с программной документацией), предложенная, опиралась на принятые в нашей стране, начиная с 1977 года, Государственные стандарты Единой системы программной документации (ГОСТ ЕСПД). Она послужила развитием каскадной модели жизненного цикла , используемой на западе в 70-е – 85-е годы прошлого века при разработке сложных ИС (рис. 1.2). Суть каскадной модели: вся разработка разбивается на несколько этапов. Переход на следующий этап происходит только после полного завершения работ на предыдущем этапе.

Каскадный подход имеет ряд положительных сторон:

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

Рис. 1.2. Схема каскадного подхода к построению ИС

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

Устраняя недостатки каскадной модели, в 80-е годы прошлого века на западе была предложена «водопадная » модель (waterfall model) разработки ИС, отражающая реальные процессы (рис. 1.3).

В 86-е – 90-е годы прошлого века получила развитие спиральная модель жизненного цикла ИС (рис. 1.4), в которой основной упор сделан на начальные этапы – анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов.

Рис. 1.3. «Водопадная» модель разработки ИС

Рис. 1.4. Спиральная модель жизненного цикла ИС

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

Вторым названием спиральной модели является «продолжающееся проектирование». Позднее, когда в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы, она получила название «быстрого прототипирования» (rapid prototyping approach или fast-track).

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

1.2. CASE-технологии проектирования ИС

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

Под термином CASE (Computer Aided Software Engineering) понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных , генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

CASE-средства вместе с системным программным обеспечением и техническими средствами образуют полную среду разработки ИС.

1.3. Модели жизненного цикла, применяемые в CASE-технологиях

Применение CASE-технологий опирается на понятия жизненного цикла программного обеспечения ИС. Используются ранее описанные схемы, несколько модифицированные применительно к новым реалиям. Так, например, каскадная модель, усовершенствованная Марри Кантором (2002 г.), предполагает необходимость (рис. 1.5):

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

· планирование работ, связанных с каждым действием;

· применения операций отслеживания хода выполнения действий с контрольными этапами.

Опираясь на результаты разработки крупных IT-проектов и проблемы, которые при этом возникали, М. Кантор поддерживает вывод, сделанный Фредериком Бруксом в книге «Мифический человеко-месяц» (1995 г.) – «в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться», так как требования к таким системам «характеризуются высокой динамикой корректировки и уточнения, невозможностью четкого и однозначного определения до начала работ по реализации».

Рис. 1.5. Каскадная модель жизненного цикла по М. Кантору

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

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

1. Жизненный цикл разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем.

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

3. Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента.

4. Жизненный цикл организации/бизнеса – охватывает всю деятельность организации в целом.

Рис. 1.6. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла

Рис.1.7. Содержание четырех категорий жизненного цикла по С. Амблеру

Барри Боэм (1988 г.) связал спиральную модель с рисками , влияющими на организацию жизненного цикла. Он выделил 10 наиболее распространенных (по приоритетам) рисков:

1) дефицит специалистов;

2) нереалистичные сроки и бюджет;

3) реализация несоответствующей функциональности;

4) разработка неправильного пользовательского интерфейса;

5) «золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей;

6) непрекращающийся поток изменений;

7) нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию;

8) недостатки в работах, выполняемых внешними по отношению к проекту ресурсами;

9) недостаточная производительность получаемой системы;

10) «разрыв» в квалификации специалистов разных областей знаний.

Большая часть рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

Модель жизненного цикла Б. Боэма представлена на рис. 1.8.

Рис. 1.8. Оригинальная спиральная модель жизненного цикла разработки ИС по Б. Боэму

1.4. Принципы создания и функционирования экономических информационных систем

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

Выделяют несколько принципов создания и функционирования ЭИС.

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

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

3. Принцип совместимости. ЭИС строится как открытая система, ориентированная на максимальное использование стандартов программного, технического и иного обеспечения.

4. Принцип непосредственного участия. В процессе обследования и создания ЭИС принимают непосредственное участие работники предприятия (фирмы).

5. Принцип безопасности. Обеспечивается безопасность всех информационных процессов, сохранность и целостность коммерческой информации, циркулируемой в ЭИС.

6. Принцип эффективности. Достижение рационального соотношения между затратами на создание ЭИС и результатами, полученными в процессе ее эксплуатации.

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

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

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

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

1) Модульность:

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

2) Ответственность:

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

Приобретение (5.1). Процесс (в ГОСТ его называют «Заказ») определяет работы и задачи заказчика, приобретающего программное обеспечение или услуги, связанные с ПО, на основе контрактных отношений. Процесс приобретения состоит из следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой перевод названий работ оригинального стандарта):

инициирование (подготовка); подготовка запроса на предложение (подготовка заявки на подряд); подготовка и корректировка договора; мониторинг поставщика (надзор за поставщиком); приемка и завершение (приемка и закрытие договора).

Поставка (5.2). Процесс определяет работы и задачи поставщика:

инициирование (подготовка); подготовка предложения (подготовка ответа); разработка контракта (подготовка договора); планирование; выполнение и контроль; проверка и оценка; поставка и завершение (поставка и закрытие договора).

Разработка (5.3). Процесс определяет работы и задачи разработчика:

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

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

Эксплуатация (5.4). Процесс определяет работы и задачи оператора службы поддержки:

определение процесса (подготовка процесса); операционное тестирование (эксплуатационные испытания); эксплуатация системы; поддержка пользователя.

Сопровождение (5.5). Процесс определяет работы и задачи, проводимые специалистами службы сопровождения:

определение процесса (подготовка процесса); анализ проблем и изменений; внесение изменений; проверка и приемка при сопровождении; миграция (перенос); вывод программной системы из эксплуатации (снятие с эксплуатации).

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

Таким образом, в настоящее время регламентирован процесс разработки ИС: определены фазы жизненного цикла, стадии и этапы разработки ИС, предусмотрена совместная деятельность IT-специалистов – разработчиков ИС и профессионалов-экономистов.

2. Роль экономиста на различных фазах жизненного цикла информационной системы бухгалтерского учета

2.1. Предпроектная стадия жизненного цикла

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

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

Предпроектная стадия предшествует работам по созданию ИС.

Рис. 2.1. Роль и место специалистов-экономистов на стадиях жизненного цикла ИС

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

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

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

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

2.2. Проектирование и разработка информационной системы

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

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

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

Высшая оценка на стадии проектирования иразработки ИС у экономистов среднего звена – (+++), далее идут экономисты низшего звена – (++), затем высшего – (+).

Оценка консультантов-экспертов незначительна – (+- –).

2.3. Внедрение информационной системы

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

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

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

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

Заключение

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

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

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

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

Литература

1. Экономическая информатика: Учебник / Под ред. . -2-е изд. –М.: Финансы и статистика, 2004. – 592 с.

2. Воройский. Энциклопедический систематизированный словарь-справочник. (Введение в современные информационные и телекоммуникационные технологии в терминах и фактах). - М.: 2007.

3. Липаев программного обеспечения. –М.: Финансы и статистика, 19 с.

4. Лобанова Т. Жизненный цикл информационных систем – выберем стандарты, выстроим методологию. – В журн. Оборудование, сентябрь, 2005. с.

5. Орлик С. Введение в программную инженерию и управление жизненным циклом ПО. –М.: 2005. sorlik.

6. Харитонов лекций. –М.: 2006 – 2007.

7. Чистов к дисциплине «Информационные системы в экономике». –М.: 2006.

ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electro technical Commission - Международная комиссия по

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

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 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

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

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

Краткие теоретические сведения.

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

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

Жизненный цикл ИС –это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.

Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):

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

· ISO/IEC 12207:1995. Международный стандарт, описывающий процессы жизненного цикла программного обеспечения. Содержит описание более, чем 220 базовых работ, выполнение которых может потребоваться в процессе создания ИС. Все процессы ЖЦ ПО подразделяются на три большие группы:

o Основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);

o Вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, разрешение проблем, аудит, аттестация, совместная оценка, верификация);

o Организационные процессы (создание инфраструктуры, управление, обучение, усовершенствование).

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

o ISO/IEC TR 15271:1998 – руководство по применению ISO/IEC 12207;

o ISO/IEC TR 16326:1999 – руководство по управлению проектами при использовании ISO/IEC 12207.

· ISO/IEC 15288:2002. Международный стандарт, описывающий возможные процессы жизненного цикла систем, созданных человеком. Был создан с учетом опыта проектирования автоматизированных информационных систем, а также с привлечением специалистов различных областей: системной инженерии, программирования, администрирования, управления качеством, безопасностью и т.д. Предполагается, что стандарт содержит полное множество процессов, которые могут протекать в ходе жизненного цикла системы. Таким образом, задача разработчика ИС заключается в формировании необходимого ему множества – среды процессов. В обзоре стандарта отмечается, что в нем не содержится описания методов и процедур, необходимых для обеспечения выполнения целей, задач и результатов указанных процессов. В 2003 году выпущено руководство по применению стандарта (ISO/IEC TR 19760:2003). В настоящее время продолжается работа над подготовкой новой редакции стандарта серии 15288.

· Rational Unified Process (RUP) – концепция итеративной (спиральной) разработки программного обеспечения, предложенная фирмой Rational Software (ныне – подразделение IBM). Жизненный цикл ИС представляет собой четыре фазы: начало (inception), исследование (elaboration), конструирование (construction) и внедрение (transition). Каждая фаза может содержать в себе несколько итераций. Кроме того, завершение всех четырех фаз не всегда означает завершение работы над проектом – его развитие может продолжится новым циклом. В рамках итераций производится создание взаимосогласованных моделей, которые описываются на специально разработанном языке UML (Unified Modeling Language).

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

· Extreme Programming (XP). Экстремальное программирование – это самая новая среди рассматриваемых методологий (первые идеи были сформированы в середине 1990-ых). Основные принципы: командная работа, эффективное взаимодействие между заказчиком и исполнителем в течение всего времени разработки ИС, использование последовательно дорабатываемых прототипов, достижение максимальной гибкости разработки (адаптация к изменяющимся требованиям заказчика).

Модели ЖЦ ИС.

Под моделью ЖЦ ИС понимается структура определяющая последовательность выполнения и взаимосвязи процессов действий и задач на протяжении жизненного цикла.

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

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

В соответствии с известными моделями ЖЦ программного обеспечения определяют модели ЖЦ ИС -каскадную, итерационную, спиральную.

I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.

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

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

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

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

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

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

Последний этап - сдача готового проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27

Таблица 2.1

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

1. Определение стандарта 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):

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

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

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

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

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

Комментарий: жизненный цикл – всегда жизненный цикл конкретной системы. Не бывает «жизненного цикла» кроме как в текстах стандартов, в жизни всегда «жизненный цикл X», где X – название целевой системы. Процессы жизненного цикла – это те процессы, которые акторы выполняют над/с системой, и которые меняют состояние системы, заставляя ее эволюционировать в ходе её жизненного цикла. «Управление жизненным циклом» -- общепринятое название подхода к описанию процессов жизненного цикла (а часто и название самой группы процессов жизненного цикла, описанных с использованием такого подхода).

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

Прежде всего, нужно различить жизненный цикл (иногда, ограничиваясь только инженерией, но не полным ЖЦ говорят также delivery process, изредка для софта -- software process) и другие "процессные представления" -- трансакции DEMO, логические "бизнес-процессы" (практики), workflows, проектные представления (подробнее -- http://ailev.livejournal.com/904643.html). Хотя есть множество подходов, при которых все эти разные аспекты описаний организации и методов ее работы смешиваются.

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

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

· «Нарезанная колбаска»

· V-диаграмма

Нарезанная колбаска".

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

Рисунок 2.1. Традиционное представление жизненного цикла

Вокруг традиционной «колбаски» могут указываться еще две дополнительных: как ЖЦ видят менеджеры (лица, управляющие проектом), и как ЖЦ видят инженеры(лица, реализующие проект) (рис.2.2)

Рисунок 2.2. Пример представления жизненного цикла

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

Рис.2.3. Разнообразие жизненных циклов