Информационные технологии и информационные системы. Реферат: Жизненный цикл информационных систем

Лабораторная работа №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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ 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 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

спиральный жизненный цикл каскадный

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

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 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. Предпроектное обследование
   • 1.1. Сбор материалов для проектирования; при этом выделяют формулирование требований, изучение объекта автоматизации, даются предварительные выводы предпроектного варианта ИС.
   • 1.2. Анализ материалов и разработка документации; обязательно даётся технико-экономическое обоснование с техническим заданием на проектирование ИС .
2. Проектирование
   • 2.1. Предварительное проектирование:
     • выбор проектных решений по аспектам разработки ИС;
     • описание реальных компонент ИС;
     • оформление и утверждение технического проекта (ТП).
   • 2.2. Детальное проектирование:
     • выбор или разработка математических методов или алгоритмов программ;
     • корректировка структур БД;
     • создание документации на доставку и установку программных продуктов;
     • выбор комплекса технических средств с документацией на её установку.
   • 2.3. Разработка техно-рабочего проекта ИС (ТРП).
   • 2.4. Разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.
3. Разработка ИС
   • получение и установка технических и программных средств;
   • тестирование и доводка программного комплекса;
   • разработка инструкций по эксплуатации программно-технических средств.
4. Ввод ИС в эксплуатацию
   • ввод технических средств;
   • ввод программных средств;
   • обучение и сертификация персонала;
   • опытная эксплуатация;
   • сдача и подписание актов приёмки-сдачи работ.
5. Эксплуатация ИС
   • повседневная эксплуатация;
   • общее сопровождение всего проекта.

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трёх группах процессов:

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

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

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

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего, процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учёта их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

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