Управление стилем границы диапазона и объектами Border

Свойство Border объекта Range возвращает семейство Borders, элементы которого не инкапсулируют данные об одной из граничных или диагональных линий данного диапазона. допустимыми значениями индекса семейства Borders могут быть следующие константы xlBordersIndex: lxDiagonalDown, xlEdgeLeft, xlEdgeRight, xlEdgeTop и т.д. Каждая из этих границ представляет объект Border.

 

Листинг 18. Управление стилем границы диапазона и объектами Border

Public Sub DemoBorders()

'Дома работает

Dim rgn As Range

Set rng = Range("A2:C2")

With rng.Borders(xlEdgeTop)

.LineStyle = xlContinuouse

.Weight = xlThick

.Color = RGB(255, 0, 0)

End With

With rng.Borders(xlEdgeBottom)

.LineStyle = xlDash

.Weight = xlMedium

.Color = RGB(0, 255, 0)

End With

End Sub

 

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

 

Пример использования объекта Shape

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

 

Листинг 19. Последовательный вывод автофигур

Public Sub StarShow()

'дома работает

Dim w As Integer, h As Integer, i As Integer

Dim toppos As Integer, leftpos As Integer

Dim v As Long

Dim star As Shape

w = 50: h = 50

Randomize

For i = 1 To 10

toppos = Rnd() * (ActiveWindow.UsableHeight - h)

leftpos = Rnd() * (ActiveWindow.UsableWidth - w)

Select Case (i Mod 6)

Case 0

v = msoShape4pointStar

Case 1

v = msoShape5pointStar

Case 2

v = msoShape16pointStar

Case 3

v = msoShape32pointStar

Case 5

v = msoShapeDiamond

End Select

Set star = ActiveSheet.Shapes.AddShape(v, leftpos, toppos, w, h)

star.Fill.ForeColor.SchemeColor = Int(Rnd() * 56)

Application.Wait Now + TimeValue("00:00:01")

DoEvents

Next

Application.Wait Now + TimeValue("00:00:01")

For Each star In Worksheets(1).Shapes

If Left(star.Name, 9) = "AutoShape" Then

star.Delete

DoEvents

Application.Wait Now + TimeValue("00:00:01")

End If

Next

End Sub

Подбор параметра и решение уравнения с одной не известной.

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

x^3-3*x-5=0

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

Точность, с которой находиться корень и предельно допустимое число используемых для нахождения корня, устанавливается свойство MaxChange и MaxIterations объекта Application. Напримкр определение корня с точностью до 0,0001 максимум за 1000 итерации устанавливает инструкцией:

With Aplication

. MaxIterations = 1000

. MaxChange = 0.0001

End With

Метод GoalSeek возвращает значение True, если решение найдено и значение False в противном случае. Например следующий код (листинг 20) ищет корень уравнения x^3-3*x-5 при начальном приближении 1

 

Листинг 20. Решение уравнения

Sub DemoGoalSeek()

Range("A1").Name = "x"

Range("A1").Value = 1

Range("B1").Formula = "=x^3-3*x-5"

If Range("B1").GoalSeek(Goal:=0, ChangingCell:=Range("x")) Then

MsgBox "Корень: " & Range("A1").Value

Else

MsgBox "корень не найден"

End If

End Sub

 

Разработка и эксплуатация автоматизированных ИС

 

Основные понятия технологии проектирования информационных систем (ИС)

 

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

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

 

Классификация ИС

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

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

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

 

Рис. 1. Классификация информационных систем.

 

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

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

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

В зависимости от характера обработки данных ИС делятся на ин­формационно-поисковые и информационно-решающие.

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

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

Результирующая информация управляющих ИС непосредственно

трансформируется в принимаемые человеком решения. Для этих систем характерны задачи расчетного характера и обработка больших объемов данных. (Например, ИС планирования производства или заказов, бухгалтерского учета.)

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

В зависимости от сферы применения различают следующие классы ИС.

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

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

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

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

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

 

Таблица 3. Функциональное назначение модулей корпоративной ИС

 

Существует классификация ИС в зависимости от уровня управления, на котором система используется.

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

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

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

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

* сравнение текущих показателей с прошлыми;

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

* обеспечение доступа к архивной информации и т.д.

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

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

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

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

Индустрия разработки автоматизированных информационных сис­тем управления зародилась в 1950-х т 1960-х годах и к концу века приоб­рела вполне законченные формы.

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

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

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

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

     

Жизненный цикл ИС

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

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

 

Модель ЖЦ

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

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

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

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

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

 

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

 

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

В основе спиральной модели жизненною цикла лежит применение прототипной технологии или RAD-технологии (Rapid Application Development - технологии быстрой разработки приложений). Согласно этой технологии ИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естествен­но, что при прототипной технологии сокращается число итераций и возникает меньше ошибок и несоответствий, которые необходимо исправлять на последующих итерациях, при этом проектирование ИС осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной ИС все большее значение придается ведению общесистемного репозитария (хранилища) и использованию CASE - технологий.

Жизненный цикл при использовании RAD-технологии предполагает активное участие конечных пользователей будущей системы на всех этапах разработки и включает четыре основные стадии информационного инжиниринга:

• анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области;

• проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;

• конструирование. Специалисты-разработчики проектируют рабочую версию ИС с использованием языков четвертого поколения;

• внедрение. Специалисты-разработчики обучают пользователей работе в среде новой ИС.

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

Спиральная модель чаще изменяется при разработке ИС силами собственного отдела ИТ предприятия.

 

Стандарты ЖЦ ИС

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

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

Значительный вклад в теорию проектирования и разработки инфор­мационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информа­ционных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организа­ционной структуры. Важнейшие шаги процесса BSP, их последователь­ность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

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

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

• ISO/IEC 12207:1995 – стандарт на процессы и организацию жизненного цикла. Распространяются на все виды заказного ПО. Стандарт не содержит описания фаз, стадий этапов.

• Custom Development Method (методика Оrас1е) по разработке при­кладных информационных систем - технологический материал, де­тализированный до уровня заготовок проектных документов, рас­считанных на использование в проектах с применением Оrас1е. Применяется СDМ для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработ­ки» (Fast Track) или «облегченного подхода», рекомендуемых в слу­чае малых проектов.

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

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

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

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных облас­тей: системной инженерии, программирования, управления качеством. Человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компью­теризированных систем.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ сле­дует включать следующие группы процессов:

1. Договорные процессы:

* приобретение (внутренние решения или решения внешнего поставщика);

* поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

* управление окружающей средой предприятия;

* инвестиционное управление;

* управление ЖЦ ИС;

* управление ресурсами;

* управление качеством.

3. Проектные процессы:

* планирование проекта;

* оценка проекта;

* контроль проекта;

* управление рисками;

* управление конфигурацией; 

* управление информационными потоками;

* принятие решений.

4. Технические процессы:

* определение требований;

* анализ требований;

* разработка архитектуры;

* внедрение;

* интеграция;

* верификация;

* переход;

* аттестации;

* эксплуатации;

* сопровождение;

* утилизация.

5. Специальные процессы:

* определение и установка взаимосвязей исходя из задач и целей.

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличается от аналогичных в других стандартах. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 4.

 

Таблица 4. Стадии создания систем(ISO / IEC 15288)

 

 

Предыдущая123456789101112131415Следующая

Поделиться:

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