Otvety
.docx1.Идеологические принципы построения и использования эффективной ИС.Пр-сс создания ИС состоит в последовательном постоянном внедрении в работу аппарата управления более совершенных, прогрессивных, научно обоснованных методов управления и ЭВМ с целью повышения эфф-ти ее произв.деятельности. Смысл пр-сса проектирования сводится к выбору лучшего варианта системы из множества возможных вариантов в соотв с принятой ф-цией цели. Пр-сс разработки сложных эконом.систем по своей природе является итеративным. На каждом уровне (этапе) разработки системы производится выработка множества вариантов с опр.глубиной детализации и соответствующий выбор допустимых наилучших вариантов. На след.этапе отобранные варианты системы прорабатываются более детально и среди них снова производится отбор. Пр-сс проектирования продолжается до тех пор, пока не будет отобран один вариант, проработанный с достаточной глубиной и удовлетворяющий требованиям, предъявляемым к системе. Разработка тех.задания завершает предпроектную стадию создания ИС. Тех.задание устанавливает: назначение и цели создания ИС; совокупность технических требований, включая требования к эволюции системы; На этапе технического проектирования создается собственно проект ИС, при этом формулируются и обосновываются все тех.решения по ее созданию. В пр-ссе раб.проектирования создается комплекс раб.документации, обеспечивающий практическое функционирование ИС. Пр-сс разработки и внедрения делится на очереди, а внутри очередей – на этапы или, наоборот, сначала на этапы, а внутри этапов – на очереди. В соотв с выделенными очередями производится раздельная разработка соответствующих проектов. Определение числа и содержания очередей и этапов разработки ИС, а также связей между очередями и этапами производится индивидуально для каждой конкр.системы. Одновременно с разработкой раб.проекта проводятся подготов.мероприятия по созд нормативно-справочной базы и обучению сотрудников аппарата управления.
2.Современные стандарты и модели диагностики функционирования ИС – СОСОМО.В конце 70-х годов Барри Боэмом была разработана модель оценивания объемов работ при разработке ИС, и получила название конструктивная модель стоимости (COCOMO). На сегодняшний день данная модель оценки трудоёмкости разработки ПО является наиболее известной среди множества подобных моделей. Она основана на анализе ряда проектов, реализованных по заказу Министерства обороны США. В общих чертах она с одной стороны определяет соответствие между размером системы в тысячах условных строк кода и «классом» проекта, а с другой трудоемкость разработки системы. -Базовый уровень рассчитывает трудоемкость и стоимость разработки как ф-цию от размера проги. Размер выражается в оценочных тысячах строк кода (KLOC ).COCOMO применим к трем классам проектов разработки ПО: Органический- маленькие команды с хорошим опытом работы и не жесткими требованиями к разработке. Полуразделенный вид- средние по размеру команды со смешанным опытом разработки и со смеш.требованиями (жесткими и нет). Встроенный вид- разрабатываются с учетом множества жестких ограничений (по аппаратному, операционному, ПО и т.д.) Вот базовые уравнения COCOMO: Трудоемкость= ab(KLOC)^bb [человеко-месяцев], Срок разработки или длительность= cb(Трудоемкость)^db [месяцев], Число разработчиков= Трудоемкость/Срок разработки [человек] . Базовый уровень COCOMO хорош для быстрой оценки стоимости разработки. Однако он не принимает во внимание различия в аппаратных ограничениях, кач-ве и опыте персонала, а также использованию совр.техник и ср-в разработки и др.факторов.-Средний уровень рассчитывает трудоемкость разработки как ф-цию от размера проги и множества «факторов стоимости», включающих субъективные оценки хар-тик продукта, проекта, персонала и аппаратного обеспечения. Это расширение включает в себя множество из 4ёх факторов, каждый из которых имеет несколько дочерних характеристик. Формула модели COCOMO для ср.уровня принимает вид: E=ai(KLoC)^(bi)*РФТ где E– трудоемкость разработки ПО в человеко-месяцах, KLoC – оценочный размер программы в тысячах строках исх.кода, и РФТ – регулирующий фактор, рассчитанный ранее. Расчет времени разработки для ср.уровня COCOMO совпадает с расчетом для баз.уровня. -Детальный уровень включает все хар-ки ср.уровня с оценкой влияния данных хар-к на каждый этап пр-сса разработки ПО. У модели есть ряд недостатков, одним из которых является ее основанность на размере самого кода программного комплекса.
3. Современные стандарты и модели диагностики функционирования ИС –ISO. ISO 9000 — серия междун.стандартов, описывающих требования к системе менеджмента кач-ва орг-ций и предприятий.Серия стандартов ISO 9000 разработана Тех.комитетом ТК 176 Междунар.Орг-ции по Стандартизации (ISO, InternationalOrganizationforStandardization). В основе стандартов лежат идеи и положения теории всеобщего менеджмента кач-ва (TQM) .3 модели обеспечения кач-ва, входящие в состав стандартов серии ISO 9000, отражают различные виды (сочетания) производств.этапов предприятия, которые могут быть сертифицированы. Они позволяют сделать обоснованный выбор заказчику и поставщику продукции, а также корректно зафиксировать взаимные обяз-ва в договоре на разработку, поставку или испытание пр-ции. Первая модель – стандарт ISO 9001 "Система кач-ва. Модель обеспечения кач-ва на стадиях разработки (проектирования, пр-ва, монтажа и обслуживания)". Он используется тогда, когда изготовитель (поставщик) должен обеспечить соответствие продукции установленным требованиям на всех стадиях жизненного цикла пр-ции – от проектирования до обслуживания. Область организац.применения – договор (контракт) на поставку, включающий проведение опытно-конструкторских работ. Требования к пр-ции выражаются в основном с позиций эксплуатац.хар-к. 1я модель кач-ва содержит наиболее полный набор требований при строгом соблюдении всех эл-тов управления кач-вом. 2я модель – стандарт ISO 9002 "Система кач-ва. Модель обеспечения кач-ва на стадиях пр-ва и монтажа". Стандарт применяется в условиях, когда требования к пр-ции устанавливаются с т.зр. уже разраб.проекта. В этих случаях необходимо подтвердить возможности изготовителя в части пр-ва и монтажа продукции.3я модель – стандарт ISO 9003 "Система кач-ва. Модель обеспечения кач-ва на стадии контроля и испытания готовой пр-ции". Эта модель устанавливает возможности и обязанности изготовителя в части контроля и испытания поставляемой пр-ции.
4. Современные стандарты и модели диагностики функционирования ИС –CMM. CapabilityMaturityModel- модель зрелости пр-ссов создания ПО: эволюционная модель развития способности компании разрабатывать ПО. Ключевым понятием стандарта является зрелость орг-ции. Незрелой считается орг-ция, в которой пр-сс разработки ПО зависит только от конкретных исполнителей и менеджеров, и решения зачастую просто импровизируются "на ходу"- то что на совр.языке называется творч.подходом, или искусством CMM определяет пять уровней зрелости орг-ций. В рез-те аттестации компании присваивается определение.уровень, который в дальнейшем может повышаться или понижаться. Каждый след.уровень вкл в себя все ключ.хар-ки предыдущих. Нач.уровень описан в стандарте в кач-ве основы для сравнения со след.уровнями. На предприятии нач.уровня орг-ции не существует стабильных условий для созданий качеств.ПО. Повторяемый уровень. Для его внедрения на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое ПО и существует спец.группа обеспечения кач-ва.Определенный уровень. Он характеризуется тем, что стандартный пр-сс создания и сопровождения ПО задокументирован. Подразумевается, что в пр-ссе стандартизации происходит переход на наиболее эффект.практики и технологии. Управляемый уровень в орг-ции устанавливаются количеств.показатели кач-ва- как на прогр.продукты, так и на пр-сс в целом. Оптимизирующий уровень характеризуется тем, что мероприятия по улучшению применяются не только к существующим пр-ссам, но и для оценки эфф-ти ввода новых технологий. Осн.задачей всей орг-ции на этом уровне является постоянное улучшение существующих пр-ссов.
5. Современные стандарты и модели диагностики функционирования ИС –ITIL.ITIL- библиотека, описывающая лучшие из применяемых на практике способов орг-ции работы подразделений или компаний, занимающихся предоставлением услуг в области ИТ.Преим-ва библиотеки ITIL для заказчиков/пользователей: предоставление ИТ-услуг становится более ориентированным на заказчика, соглашения о кач-ве услуг способствуют улучшению взаимоотношений; услуги описываются лучше, на языке заказчика и с требуемой детализацией; Преим-ва библиотеки ITIL для ИТ-орг-ций: становится четко понятна стр-ра ИТ-департамента, его орг-ция становится более рациональной и более ориентированной на корпор.цели; рук-во орг-цией становится более целенаправленным, облегчается Управление Изменениями; Возм.проблемы при работе с ITIL: переход на принципы ITIL может занять продолжительное время, потребовать знач.усилий и изменений в корпор.культуре. Чересчур амбициозные планы при переходе на ITIL могут привести к разочарованию, и поставленные цели не будут достигнуты; улучшения не достигаются при недостатке понимания, что должны обеспечивать пр-ссы (в чем их цель), что является критериями оценки эфф-ти пр-ссов и как осуществлять их контроль; улучшения в предоставлении услуг и снижении стоимости недостаточно видны;
6. Модели уровней зрелости предприятия. Сервисный подход к управлению ИТ-службой требует определение.зрелости как для самой ИТ-службы, так и для бизнес-заказчиков. Уровень зрелости бизнес-пр-ссов предприятия можно оценить на основе модели зрелости пр-сса разработки ПО СММ. Базовым понятием модели CMM/СММI считается зрелость компании. Незрелой-компания, где пр-сс конструирования ПО и принимаемые реш зависят только от таланта конкр.разработчиков. Рез-том является выс.риск превышения бюджета или срыва сроков окончания проекта. В зрелой компании работают ясные процедуры управления проектами и построения прогр.продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопл.опыте. В компании имеются и действуют корпор.стандарты на пр-ссы взаимодействия с заказчиком, пр-ссы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качеств.разработку ПО. В модели CMM/СММI пять уровней зрелости предприятий: начальный; повторяемый; определенный; управляемый; оптимизирующий. Кажд.уровень СММ характеризуется областью ключевых пр-ссов (ОКП), причем считается, что каждый послед.уровень вкл в себя все хар-ки предыдущих уровней. По аналогии с понятием "уровень зрелости предприятия" используется понятие "уровень зрелости ИТ-инфраструктуры". Компания Gartner предлагает для оценки зрелости ИТ-службы использовать пять уровней: хаотичный; реактивный; проактивный; сервис; польза. В методологии компании Microsoft по оптимизации ИТ-инфраструктуры выделяют уровни зрелости ИТ-инфраструктуры предприятий. Модель зрелости ИТ-инфраструктуры, разработанная Microsoft, вкл 4 уровня: базовый; стандартизированный; рационализированный; динамический. Предприятия с динамическим уровнем зрелости ИТ-инфраструктуры имеют возможность внедрять новые ИТ-технологии, необходимые для поступательного развития бизнеса, выигрыш от которых значительно перевешивает доп.расходы.
7. Стандарты оценки производительности ИС - тесты TPC. В 1988г. был создан Совет по оценке производительности обработки транзакций (TPC), который представляет собой бесприбыльную орг-цию. Любая компания или орг-ция может стать членом TPC после уплаты соответств.взноса. На сегодня членами TPC являются практически все крупнейшие производители аппаратных платформ и ПО для автоматизации комм.деятельности. К наст.времени TPC создал 3 тест.пакета для обеспечения объект.сравнения разл.систем обработки транзакций и планирует создать нов.оценочные тесты. В комп.индустрии термин транзакция может означать почти любой вид взаимодействия или обмена инфой. Однако в мире бизнеса "транзакция" имеет вполне опр.смысл: комм.обмен товарами, услугами или деньгами. В наст.время практически все бизнес-транзакции выполняются с помощью компов, осн.задачей которой является точное определение тест.пакетов для оценки систем обработки транзакций и БД, а также для распространения объективных, проверяемых данных в промышленности. TPC публикует спецификации тест.пакетов, которые регулируют вопросы, связанные с работой тестов. Эти спецификации гарантируют, что покупатели имеют объективные значения данных для сравнения производительности различных вычислительных систем. Хотя реализация спецификаций оценочных тестов оставлена на усмотрение индивид.спонсоров тестов, сами спонсоры, объявляя результаты TPC, должны представить TPC детальные отчеты, документирующие соответствие всем спецификациям. Эти отчеты, в частности, вкл конфигурацию системы, методику калькуляции цены, диаграммы значений производительности и документацию, показывающую, что тест соответствует требованиям атомарности, согласованности, изолированности и долговечности (ACID), которые гарантируют, что все транзакции из оценочного теста обрабатываются должным путём.
8. Стандарты оценки производительности ИС - тесты SPEC. Осн.целью этой орг-ции является разработка и поддержка стандартизованного набора специально подобранных тест.прог для оценки производительности новейших поколений высокопроизводительных компов. Членом SPEC может стать любая орг-ция, уплатившая вступительный взнос. Глав.видами деят-ти SPEC является разработка и публикация наборов тестов, предназначенных для измерения производительности компов. Перед публикацией объектные коды этих наборов вместе с исх.текстами и инструментальными ср-вами интенсивно проверяются на предмет возможности импортирования на разные платформы. Они доступны для шир.круга пользователей за плату, покрывающую расходы на разработку и административные издержки. Спец.лиценз.соглашение регулирует вопросы выполнения тестирования и публикации рез-тов в соотв с документацией на каждый тест.набор. SPEC публикует ежекварт.отчет о новостях SPEC и рез-тах тестирования: "TheSPECNewsletter", что обеспечивает централиз.источник инфы для рез-тов тестирования на тестах SPEC. Осн.рез-том работы SPEC являются наборы тестов. Эти наборы разрабатываются SPEC с использованием кодов, поступающих из разных источников. SPEC работает над импортированием этих кодов на разные платформы, а также создает инструментальные ср-ва для формирования из кодов, выбранных в кач-ве тестов, осмысленных раб.нагрузок. Поэтому тесты SPEC отличаются от свободно распространяемых прог. Хотя они могут существовать под похожими или теми же самыми именами, время их выполнения в общем случае будет отличаться. В наст.время имеется 2 баз.набора тестов SPEC, ориентированных на интенс.расчеты и измеряющих производительность процессора, системы памяти, а также эфф-сть генерации кода компилятором. Эти тесты ориентированы на ОС UNIX, но они также импортированы и на др.платформы. % времени, расходуемого на работу ОС и ф-ции ввода/вывода, в общем случае ничтожно мал.
9. Стандарты оценки кач-ва ИС. Кач-во ИС связано с дефектами, заложенными на этапе проектирования и проявляющимися в пр-ссе эксплуатации. Св-ва ИС могут проявляться лишь во взаимодействии с внешн.средой, включающей тех.ср-ва, персонал, информ и прог.окружение. Оценка кач-ва ИС является крайне сложной з-чей из-за многообразия интересов пользователей. Поэтому невозможно предложить одну универсальную меру кач-ва и приходится использовать ряд хар-к, охватывающих весь спектр предъявляемых требований. Наиболее близки к з-чам оценки кач-ва ИС модели кач-ва ПО, являющегося одним из важных составных частей ИС. В наст.время используется несколько абстрактных моделей кач-ва ПО, основанных на определениях хар-ки кач-ва, показателя кач-ва, критерия и метрики. Каждому показателю кач-ва ставится в соотв группа критериев. Для указ.показателей приведем возм.критерии. Один и тот же критерий может характеризовать несколько показателей: практичность- работоспособность,; целостность- регулирование доступа, контроль доступа; эфф-сть- эфф-сть использования памяти, эфф-сть функционирования; корректность- трассируемость, завершенность, согласованность;надежность- точность, устойчивость к ошибкам, согласованность, простота; удобство обслуживания- согласованность, простота, краткость, информативность, модульность; оцениваемость- простота, наличие измерительных ср-в, информативность, модульность. С помощью метрик можно дать количественную или кач.оценку кач-ва ИС. 1ый тип- метрики, которые используют интерв.шкалу, характеризуемую относ.величинами реально измеряемых физ.показателей. 2ой тип- метрики, которым соответствует порядковая шкала, позволяющая ранжировать хар-ки путем сравнения с опорн.значениями. 3ий тип- метрики, которым соответствуют номинальная, или категорированная шкала, определяющая наличие рассматриваемого случайная величина-ва или признака у рассматриваемого объекта без учета градаций по этому признаку. Например, интерфейс может быть "простым для понимания", "умеренно простым", "сложным для понимания".
10.Стандарты по управлению ИТ-услугами. Стандарты управления и безопасности ИТ были созданы на основе анализа и обобщения лучших методов, опробованных как большими группами профессионалов так и множеством различных орг-ций. Явл-ся рез-том «народного творчества». С появлением потребностей в междун.стандартах в разл.областях, в том числе и области кач-ва были созданы Междунар.Электро-тех.комиссия (IEC) и Междунар.орг-ция по стандартизации (ISO). Кроме признанных междунар.стандартов существует много нац.стандартов управления и безопасности ИТ; большинство стран имеет собств.орг-ции, издающие стандарты для разных случаев. Это связано с тем, что описываемая лучшая практика доступна или применима лишь в местном масштабе. Поскольку стандарт явл-ся рез-том обсуждения индивидуумов различие идей, культуры, п-ки и нац.особенностей вели и будут всегда вести к быстрому росту числа локальн.стандартов. Выгоды от использования стандартов управления и безопасности ИТ становятся очевидными тогда, когда орг-ция решает отдать часть своих ф-ций на аутсорсинг. Применение откр.стандартов в кач-ве основы при заключении соглашений об уровне обслуживания ведет к уменьшению разногласий и снижению сопутствующих затрат и рисков. Осн.цели аудита ИС: управление ИС (CobiT, BS 15000, ITIL); управление проектами (PRINCE 2); управление безопасностью (ISO, CobiT); управление кач-вом (ISO, EFQM); программирование (Tick IT); цель аудита (IT Governance, CobiT, COSO); управление рисками; планирование неприрывности бизнеса; аудит ИС (CobiT, ISO). Применение стандартов в неадекватных ситуациях может стать причиной инициации дорогостоящих проектов, не обеспечивающих достижение поставленных целей. Успешные стандарты всегда оставляют простор для их интерпретации, но время от времени эта интерпретация может привести к проблемам.
11.Функции международной орг-ции ISACA. Ассоциация Аудита и Контроля ИС (ISACA) была основана в 1969г. для фин.аудиторов в контроле ИТ. Она явл-ся ведущей мир.орг-цией с представительствами более чем в 100 странах мира, охватывает все уровни ИТ: орг-ции, управления, практического применения. Основная цель ассоциации – исследование, разработка, публикация и продвижение стандартизированного набора документов по управлению ИТ для ежедневного использования руководителями ИТ-департаментов, администрацией и аудиторами ИС. ISACA определяет одним из приоритетных направлений квалифицированное обучение специалистов в области аудита, безопасности и управления ИТ. Ассоциация проводит сертификацию специалистов в области аудита (CISA), информации (CISM), управления ИТ (CGEIT).
Сертификация CISA явл-ся стандартом дефактом в мире аудита ИТ и для любого аудитора ИТ в мире данный сертификат явл-ся ценным статусом.
Особенностью CISM явл-ся концентрация на эфф-ти инф.безопасности под которой прежде всего имеется ввиду ее эфф-ть с т. зр. бизнеса и его эконом.показателей. Прога CISM учит как компании заработать деньги с помощью информ.безопасности и как это показать владельцам и инвесторам. Сертификация CGEIT явл-ся самой молодой и рассматривает вопросы IT Governance, что переводится на русский как управление, стратегическое управление или регулирование.
12.Стандарты аудита эффективности ИС. Аудит ИС и технологий- сист.пр-сс получения объективных качеств и количеств.оценок о тек.состоянии информ.безопасности компании в соотв с определение.критериями и показателями безопасности. Ключ.этапами проведения аудита ИС явл-ся: определение границ проведения аудита; сбор информации; анализ инфы; выработка рекомендаций; составление аудиторского отчета и заключения; контроль выполнения ключ.рекомендаций. Осн.стандартом ЭИС явл-ся стандарт CobiT, разработанный Междунар.ассоциацией аудита и контроля ИС (ISACA) в 1996г.. Осн.цель- формализованное определение лучших практик в области пр-ссов ИТ управления для обеспечения согласованного подхода к оценке кач-ва ИТ-пр-ссов. ИТ-ресурсы в CobiT описаны 5-ю составляющими: данные; приложения; технологии; оборудование; люди. CobiT вкл 4 домена: 1. Планирование и орг-ция 2. Проектирование и внедрение 3. Эксплуатация и сопровождение 4. Монтаж
13. Корпоративные стандарты. Корпор.стандарты- модель поведения компании. С помощью перечня правил орг-ция достигает эффективного и слаженного взаимодействия м/у своими служащими. Единые корпор.стандарты позволяют компании работать четко и структурированно. Корпор.стандарт должен выполняться каждым сотрудником с целью:1)Исключения тип.воспроизводственных ошибок 2) Увеличения и надежности КПД бизнес-пр-ссов 3) Превращения удачных ситуаций в тиражируемую технологию.
14. Понятие ресурсов ИС. ИС могут базироваться на разл.ресурсах: 1)Аппаратные платформы- ПК, мэйнфрэймы и др. вычисл.системы 2)Коммуникац.оборудование- обеспечение взаимодействия компонентов распр.систем (обмен данными м/у компом сети, а также удаленный доступ пользователей к ресурсам системы) 3)Системное ПО 4) Прикладное ПО: типовое (специальное; ориентир на опр.классы з-ч); специализированное (для конкретных ИС или класса систем, имеющих узкое направление). 5)Лингв.ресурсы: представление инф.ресурсов в системе; описание их св-в и св-в окр.среды, позволяющее системе адекватно интерпретировать поддерживание инф.ресурсов. 6)Инф.ресурсы системы составляющие глав.компонент модели предм.области, которую система поддерживает. Они явл-ся как «сырьем» так и «конечным продуктом» работы ИС. Сущ 2 категории инф.ресурсов: Р-сы непосредственно пользующиеся конечным пользователем систем; метаданные (метаресурсы)- описывают св-ва р-сов 1ой категории и позволяют системе корректно оперировать ими, т.е. данные о данных.
15. Жизненный цикл функционирования ИС.Жизненный цикл ИС (ЖЦИС) – период их создания и использования, охватывает различные состояния, начиная с момента возникновения необходимого в такой системе и заканчивая моментом ее полного выхода из употребления у пользователей. ЖЦИС: 1 этап – анализ первичных требований и планирование работ. Данный этап связан с предварительной инициацией работ над проектом. Его основными задачами яв-ся: анализ первичных бизнес требований; предварительная экономическая оценка проекта; построение плана графика выполнения работ; создание и обучение совместной рабочей группы.
2 этап - Проведение обследования деятельности предприятия
В рамках данного этапа осуществляется:
-• предварительное выявление требовании, предъявляемых к будущей системе;
-• определение оргштатной и топологической структур предприятия;
-• определение перечня целевых задач (функций) предприятия;
-• анализ распределения функций по подразделениям и сотрудникам;
-• определение перечня применяемых на предприятии средств автоматизации.
Длительность обследования составляет 1-2 недели. По окончании обследования строится и согласуется с заказчиком предварительный вариант функциональной модели предприятия, включающей идентификацию внешних объектов и информационных взаимодействии с ними, а также детализацию до уровня основных деятельностей предприятия и информационных связей между этими деятельностями.
3 этап - Построение моделей деятельности предприятия
На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:- модели "как есть" и - модели "как должно быть", интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия.
4 этап - Разработка системного проекта
Данный этап является первой фазой разработки собственно системы автоматизации, на которой требования заказчика уточняются, формализуются и документируются. Самый ответственный этап. На этом этапе определяются:
-• архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;
-• интерфейсы и распределение функций между человеком и системой;
-• требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;
-• состав людей и работ, имеющих отношение к системе;
-• ограничения в пр-ссе разработки
5 этап - Разработка предложений по автоматизации предприятия. Осуществляется на основе системного проекта.
6 этап - Разработка технического проекта. На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы.
7 этап - Разработка и тестирование. Цель тестирования – выявить наличие ошибок или убедительно продемонстрировать их отсутствие. Отладка – это набор процедур и действий, начинающихся с выявления самого факта наличия ошибки и заканчивающихся установлением точного места, характера этой ошибки и способов ее устранения.
8 этап – Внедрение
9 этап – Эксплуатация и сопровождение
16. Стратегические модели ИС предприятия, трансформирующиеся вместе с предприятием, целям которого она служит. Изменения ИТ-платформы подчиняются требованиям др.масштаба и, часто, др.природы по сравнению с изменениями в прикл.прогах. Поэтому вопросы планирования серверов или сетевой инфрастр-ры, имеющей "резерв на будущее", более понятны менеджерам разных профилей. Легко согласиться с тем, что нужен резерв для поддержки новых 20ти раб.мест, которые появятся в ближайшие полгода, легко понять, что совсем др.резерв нужен для развития ИС при подключении нов.филиалов предприятия или при изменении п-ки физ.размещения изделий на складах торгующих подразделений. Поскольку hardware- более "твердая" вещь, чем проги, связь тех.ИТ-вопросов с вопросами стратегии предприятия явл-ся более очевидной. Но конечно же эти связи есть и у всех ост.компонентов системы. ИС- это не только проги, данные и коммуникации, но и люди (заказчики, пользователи, аналитики и "реализаторы"), организац.стр-ры, планы-графики работы, а также цели и стимулы предприятия и отдельных людей. И все эти "вещи" должны быть понятным и непротиворечивым образом соединены в одну систему. Все возрастающая сложность и многоаспектность предприятия определяют растущую сложность согласования его частей и аспектов работы. Главная идея такого согласования: его надо начинать с самых глав.хар-к предприятия, рассматривая самые глав.содержательные аспекты. И проводить его не "мысленно" и не "на словах", а на явно изложенных описаниях предприятия, позволяющих видеть все существенные взаимосвязи, а значит- на его моделях. Предыдущие 2 утверждения приводят к пониманию того, что привычные нотации формальных моделей (структурных, объектных) слишком рано ведут к более низк.уровню моделирования, чем необходимый в начале. Один из лидеров интеграции бизнес- и ИТ-подходов Дж. Захмана . В 1987 году появилась его статья название которой можно перевести так: "Общая схема арх-ры ИС". В ней была предложена простая, но концептуально мощная схема, показывающая разл.уровни представления арх0-ы ИС, разл.виды ее "обеспечения", а также их осн.взаимосвязи.