Бизнес-процесс - Сайт группы Ис-9
advertisement
Бизнес-процесс Процесс - это любая операционная или административная система, которая преобразует ресурсы в желательные результаты. В деловой литературе существует много определений процесса и бизнеспроцесса, которые не противоречат, а скорее дополняют друг друга. В наиболее простом случае процесс – это поток работы, переходящий от одного человека к другому, а для более сложных процессов – это поток работы, переходящий от одной организационной единицы к другой. Процессом является завершенная, с точки зрения содержания, временной и логической очередности, последовательность операций, то есть элементарных действий, необходимых для обработки экономически значимого объекта. Международные стандарты качества семейства ISO 9000 дают определение процесса как деятельности, использующей ресурсы и управляемой с целью преобразования входов в выходы. При этом выход одного процесса часто образует вход следующего, а сами процессы многочисленны и взаимосвязаны. В более позднем определении от имени системы всеобщего управления качеством – TQM процесс представлен как организованная деятельность, предназначенная генерировать предварительно установленный определенному пользователю выход, обеспечив при этом необходимый вход процесса. Понятие бизнес-процесса как особого процесса, который служит осуществлению основных целей предприятия (бизнес-целей) и описывает центральную сферу его деятельности, представил в своих работах Нордсик – один из первых авторов идеи переориентации структуры предприятия на процессы. Бизнес-процесс – это один, несколько или множество вложенных процессов (внутренних шагов деятельности), которые заканчивается созданием продукта, необходимого клиенту. Таким образом, выходом или результатом выполнения бизнес-процесса всегда являются информация, услуги или товары, востребованные клиентом. При этом бизнес-процесс может иметь несколько выходов. Термин, который предложил М. Хаммер – автор концепции реинжениринга бизнес-процессов, звучит следующим образом: бизнес-процесс это организованный комплекс взаимосвязанных действий, которые в совокупности дают ценный для клиента результат. Здесь предполагается что процесс – это комплекс действий, а не одно действие. В свою очередь все действия, включаемые в процесс, не случайны и не произвольны, а взаимосвязаны и организованы и только в совокупности могут дать требуемый эффект. С точки зрения осуществления деятельности компании бизнес-процесс (макропроцесс) – это связанный комплекс работ, реализуемый по заданным требованиям и обеспечивающий достижение нужного конечного результата (планирование, проектирование, снабжение, производство, торговля). Определение процесса будет более полным, если его дополнить рядом уточняющих понятий: • вход процесса – ресурс (комплектация и поставки), • выход процесса – результат (информация, услуги или товары), • границы процесса – начальные и конечные точки фиксации процесса, • граница входа процесса – предшествует первому шагу процесса, • граница выхода процесса – располагается за последним шагом процесса, • первичный вход процесса – основной ресурс, • вторичный вход процесса – поддерживающий ресурс, • первичный выход процесса – основной результат процесса, • вторичный выход процесса – побочный результат процесса. Реинжениринг бизнес-процессов, в отличие от известных в последние десятилетия многочисленных методов постепенного совершенствования работы компаний, означает, по сути, решительную, стремительную и глубокую «прорывную» перестройку основ внутрифирменной организации и управления. Фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов с целью достижения существенного (в десятки и сотни раз) улучшения ключевых показателей результативности компании — вот содержание и смысл реинжениринга. Впечатляющие результаты, достигнутые на этом пути рядом компаний, породили даже своеобразную моду на реинжениринг как на панацею от всех управленческих бед, каковой он, естественно, не является. Коренная перестройка — в этом, прежде всего, суть реинжениринга бизнес-процессов. Слово «перестройка» здесь как нельзя лучше ассоциируется с той перестройкой, которую пережил в 1985 — 1991 годах Советский Союз. Правда, супердержава не выдержала такой «встряски» и неожиданно для себя и всего мира развалилась. 10-летний опыт практического реинжениринга в развитых странах свидетельствует о том, что примерно 50-70% компаний, проводивших реинжениринг своих бизнеспроцессов, если и не «развалились», то не добились тех существенных результатов, ради которых и стоило подвергать себя столь сильному «стрессу». Однако остальные 30-50% компаний, имевших мужество «перейти Рубикон», отделявший уютную и надежную гавань их бизнеса от штормов и ураганов океана жесткой конкурентной борьбы, показали всему миру, что «игра стоит свеч», добившись скачкообразного увеличения показателей эффективности функционирования бизнеса. В ближайшей перспективе все фирмы, независимо от их желания и степени осознания необходимости глубоких внутренних перемен, обусловленных объективными неотвратимыми динамичными изменениями внешней деловой среды, «обречены», во избежание исчезновения, на реинжениринг своих бизнеспроцессов. Реинжениринг бизнес-процессов принципиально отличается от сменяющих друг друга последние 30-40 лет модных веяний в менеджменте, таких, например, как управление по целям, диверсификация, бенчмаркинг, тотальное управление качеством, предполагающее постоянное «приростное», пошаговое совершенствование и др. Реинжениринг бизнес-процессов не предполагает осуществления постоянных, но незначительных изменений, ведущих к небольшому «приростному» (на единицы и даже десятки процентов) улучшению показателей функционирования компании. В результате успешно проведенного реинжениринга — быстрого осуществления глубоких и всесторонних коренных изменений системы управления — компания достигает существенного, «прорывного» роста эффективности (в десятки и сотни раз). Поэтому реинжениринг можно поставить в один ряд с таким фундаментальным открытием в области организации и управления производством как сформулированный еще в 1776 году Адамом Смитом в его книге «Богатство народов» принцип разделения труда, позволивший на основе глубокой специализации и разделения процесса производства на множество элементарных операций достичь стократного и более роста производительности труда. Специфика реинжениринга состоит в том, что существующая более 250 лет узкая специализация и обусловленная ею многократная передача ответственности как в производстве, так и, особенно, в управлении, отжили свой век и реинтегрируются ныне в сквозные бизнес-процессы, ответственность за которые от начала и до конца берут на себя сплоченные командным духом группы единомышленников, способные выполнять широкий спектр работ. Причем, работа в команде предполагает не столько всеобщий и постоянный «одобрямс» и умиление по поводу любых действий ее членов, сколько творческие дискуссии и столкновение мнений с целью выработки наилучших нестандартных решений. Как говорил знаменитый шотландский философ и экономист Дэвид Юм (1711 — 1776): «Истина возникает в результате разногласий между друзьями». Упоминаниями о реинжениринге бизнес-процессов изобилуют многие как популярные, так и академические издания. Согласно внесшим решающий вклад в разработку теории и практики современного реинжениринга американским специалистам М. Хаммеру (разработчик концепции реинжениринга, профессор школы бизнеса Гарвардского университета, который был назван журналом Business Week одним из немногих наиболее выдающихся «гуру» менеджмента 1990-тых и Дж. Чампи (ведущий эксперт по внедрению идей реинжениринга, возглавляющий консалтинговую фирму СSC Index) реинжениринг означает “создание компании заново” (так сказать “с нуля”) и определяется как “фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности: затраты, качество, уровень обслуживания и оперативность”. Выделенные (жирным шрифтом) в этом определении четыре слова, по мнению М. Хаммера и Дж. Чампи, — ключевые. Причем наиболее важным среди этих четырех является слово «бизнес-процессы». Бизнес-процесс — это совокупность различных видов деятельности, в рамках которой «на входе» используется один или более видов ресурсов и в результате этой деятельности «на выходе» создается продукт, представляющий ценность для потребителя. Бизнес-процесс можно изобразить как ряд логически взаимосвязанных заданий, нацеленных на достижение результата. При этом бизнес-процесс характеризуется двумя важными особенностями: - Он имеет своих рыночных или внутрифирменных «платежеспособных» заказчиков (получателей); - Он пересекает организационные границы, то есть он обычно протекает поверх барьеров, существующих между подразделениями компании, а также между разными компаниями, связанными между собой отношениями “поставщик-потребитель”, или даже проникает сквозь эти барьеры. Бизнеспроцесс чаще всего не зависит от формальной организационной структуры компании. Реинжениринг предполагает перенос акцентов внутрифирменного менеджмента с пооперационной специализации на межфункциональные бизнес-процессы, такие, например, как разработка нового продукта или услуги, выполнение заказов клиентов, послепродажный сервис и т.п. В организациях, действующих на традиционных принципах глубокой специализации, обычно отсутствует лицо, на которое возлагается полная ответственность за тот или иной бизнес-процесс в целом. Ответственность за бизнес-процесс в таких организациях, как правило, разделена по вкладу в его реализацию того или иного функционального подразделения, например, маркетингового, финансового или производственного. Присущее реинженирингу бизнес-процессов потенциальное превосходство над традиционным способом ведения дел может реализоваться, если привязать организационную структуру компании и всю ее деятельность к сквозным бизнес-процессам. Наблюдающийся в последние 10-15 лет “бурный поток” публикаций, посвященных реинженирингу бизнес-процессов, породил широко ныне распространенную размытость в использовании этого термина, что обусловило наклеивание ярлыка “реинжениринг” на самые различные программы организационных изменений в компаниях. Эту ситуацию известные специалисты в области менеджмента и информационных систем Т. Дэвенпорт и Д. Стоддард комментируют следующим образом: “…неправильное понимание сути реинжениринга бизнес-процессов широко распространено, так что его часто приравнивают к регулярно возникающим в последнее десятилетие модным «лекарствам от всех болезней» менеджмента. В результате, многие менеджеры «занимаются реинженирингом» по той причине, что это модно и об этом виде деятельности много и одобрительно упоминают средства массовой информации (без действительного понимания того, что он представляет собой на самом деле). Более того, многие менеджеры стали полагаться на широко распространенные и опасные заблуждения о способности реинжениринга «легко и просто» обеспечить их проектам успех в конкурентной борьбе. В то же время, некоторые руководители научились искусно представлять свою работу как реинжениринг, чтобы добиваться как получения ресурсов, так и одобрения высшего руководства компании». Есть два основных подхода к реинженирингу. Первый — это “совершенствование бизнеспроцессов”, а второй — “перепроектироваение и реинжениринг бизнес-процессов”. Термины “реинжениринг” и “перепроектирование” используются как взаимозаменяемые. По мнению К. КоулсонТомаса, совершенствование бизнес-процессов может привести к заметному улучшению, однако всего лишь “приростному” по отношению к существующему уровню ведения бизнеса. Такое совершенствование происходит за счет отказа от малоценных дополнительных видов деятельности, передвижения границ между подразделениями и делегирования полномочий с целью повышения производительности и экономии требуемых ресурсов. В противоположность просто совершенствованию, реинжениринг предполагает осуществление радикальных, коренных изменений. Это может означать перепроектирование или перестройку как отдельных бизнес-процессов, так и всей организации в целом, а также взаимоотношений с поставщиками и потребителями. Подобная реструктуризация осуществляется после глубокого и тщательного обследования, вскрывающего как недостатки, так и скрытые неиспользованные возможности персонала, процессов, информации и технологии, а также после осмысления новых способов их эффективного взаимодействия. В результате тщательного и всестороннего анализа часто можно обнаружить обширные области совершенствования бизнес-процессов посредством их упрощения. Так, скорость и качество протекания определенного бизнес-процесса можно увеличить, если параллельно выполнять те виды деятельности, которые ранее выполнялись последовательно, либо обобщить и систематизировать наиболее важную информацию (собираемую в критических точках протекания бизнес-процесса). Усилия по проведению улучшений в жизнь должны быть достаточно мощными и сконцентрированными. Д. Миллер считает, что упрощение может касаться всего бизнес-процесса или его отдельных фрагментов. Другие подходы к совершенствованию бизнес-процесса, выходящие за рамки только лишь упрощений, требуют более глубокого и радикального вмешательства в структуру выполнения всех работ и организации бизнес-процесса. Чтобы обеспечить деятельность большинства организаций, обычно достаточно всего от 3 до 10 основных бизнес-процессов. Но определить их невозможно без соответствующего анализа и так называемого инсайта (интуиции). Бизнес-процессы редко можно описать в терминах традиционных управленческих структур, а тем более отыскать среди традиционных видов деятельности. Обычно выделяют три вида типичных бизнес-процессов: выработка стратегии, разработка нового товара, выполнение заказов. Масштаб программы реинжениринга зависит от того, сколько основных бизнеспроцессов будет ею охвачено. Результаты исследования конкретных хозяйственных ситуаций, возникающих в процессе реальных попыток перепроектирования и реинжениринга бизнес-процессов, свидетельствуют как о достигнутых в ряде случаев существенных успехах, так и о неудачах и разочарованиях. Перепроектирование и реинжениринг бизнес-процессов может позволить организации создать возможности для более тесного взаимодействия между поставщиками и заказчиками. Так, например, в результате успешно проведенного в течение немногим более одного года реинжениринга своего бизнес-процесса типа “выполнение заказов” компания Bell Atlantic Corporation достигла сокращения времени реализации этого бизнес-процесса (выполнение заказов на подключение корпоративных клиентов к каналам связи, обеспечивающим высокоскоростную передачу данных и видеокоммуникации) с 30 дней до 3 и смогла, таким образом, не только сохранить существующую клиентуру, но и привлечь многих новых заказчиков, то есть значительно расширить масштабы своего бизнеса. Трансформация компании предполагает решительный отказ от традиционно сложившихся порядков, определение, переосмысление, переоценку и проведение изменений ключевых бизнеспроцессов и структуры организации. Трансформация предполагает фундаментальное изменение сущности и характера выполняемых работ. Поддержка такого фундаментального изменения требует, по мнению П. МакХью, Дж. Мерли и У. Уиллера, применения комплексного (системного) подхода к человеческим ресурсам, обучению и развитию персонала, изменению структуры управления и ключевых бизнес-процессов, что в случае удачной реализации может привести к возникновению синергетического эффекта (превышение положительного результата совместного действия составляющих некоторого процесса или явления над суммой результатов изолированного действия каждой из них). Быстро изменяющееся окружение может свести на нет усилия по постепенному (step by step) совершенствованию бизнес-процессов, ведущему всего лишь к незначительным улучшениям. К тому же такое совершенствование может оказаться чересчур медленным и запоздалым. Поэтому один из решающих факторов успеха реинжениринга — стремительность его претворения в жизнь. Поскольку реинжениринг предполагает коренную ломку устоявшихся управленческих функций и характера выполняемых менеджерами работ, инициировать и возглавить этот процесс должно высшее руководство компании, а ее лидер должен стать “фанатиком” реинжениринга. А фанатик, по определению выдающегося британского политического и государственного деятеля Уинстона Черчилля (1874 — 1965), — «это человек, который не может менять свое мнение и не хочет менять тему обсуждения». Не менее важным фактором успеха (или провала) реинжениринга следует считать настроенность персонала на решительную и быструю перестройку не только и не столько организационной структуры корпорации, но и (самое главное и, пожалуй, самое трудное) — на коренное изменение самого характера работы каждого сотрудника и его рабочего окружения (готовность и умение выполнять расширенный круг работ, нести ответственность не только за свои собственные действия, но и за результаты командной работы). Формирование команд, осуществляющих реинжениринг бизнес-процессов требует значительных инвестиций, необходимых для проведения первоначального анализа бизнес-процессов, их перепроектирования и последующего внедрения в практику функционирования организации. Согласно Дж. Моргану, реинжениринг подразумевает “превращение организаций в машины”. Хотя в некотором смысле такая метафора и подразумевает зависимость корпорации от внутренних и внешних акционеров, требующих такого изменения ее планов, которое обеспечивало бы успех в бизнесе, на самом деле она образно выражает подчиненность чувств и дел, забот и тревог, стремлений и амбиций сотрудников стратегическим целям корпорации даже тогда, когда они наиболее уязвимы и ранимы и, как это ни парадоксально, в то же время наиболее сильны и дееспособны. Лидерство проявляет свою мощь и действенность только лишь благодаря способности мотивировать сотрудников к изменению своего индивидуального и коллективного поведения в желательном для успеха направлении. Если менеджер фактически обладает небольшой властью, то зачастую и его подчиненные недостаточно инициативны. Сила власти лидера проявляется и подтверждается самостоятельными и инициативными действиями подчиненных. Явная девальвация индивидуального вклада каждого сотрудника в общее дело несовместима с успешным реинженирингом бизнес-процессов и радикальными организационными изменениями. Реинжениринг бизнес-процессов требует от руководства формирования и распространения разделяемого всеми сотрудниками единого понимания предпочтительного будущего организации и своего вклада в его достижение, создания окружающей среды и инфраструктуры, которые бы активно способствовали обучению персонала и его профессиональному росту, и предоставляли сотрудникам возможность руководствоваться в процессе принятия решений не установленными раз и навсегда незыблемыми нормами (часто — в результате психологической обработки), а творческим воображением, фантазией, изобретательностью и находчивостью. Привлечение всеобщего внимания к идеям и практике реинжениринга (так, например, только в США, где к середине 90-тых реинжениринг применяли более двух третей крупнейших компаний, представляющих самый широкий спектр разнообразных отраслей национальной экономики, в одном лишь 1994 году на консультантов по реинженирингу было израсходовано более $7 млрд.) объясняется, не в последнюю очередь, вхождением мировой экономики в эпоху повсеместного применения информационных технологий (ИТ) на основе массовой компьютеризации и широкого использования Internet. Однако упования на всесилие информационных технологий оказываются безосновательными в тех случаях, когда под реинженирингом понимают всего лишь компьютеризацию традиционно сложившихся бизнес-процессов. Здесь можно провести историческую аналогию с отечественным опытом внедрения автоматизированных систем управления производством в 60-х — 70-х годах, когда академик Глушков был вынужден призывать «не пытаться автоматизировать существующий хаос», а сначала, до подключения всей мощи информационных технологий, рационализировать все процессы управления на предприятии. Нечто подобное повторилось на новом витке исторической спирали развития, когда в работах (начала 90-тых), отражавших реальную практику реинжениринга, просматривается тенденция трактовать сплошную компьютеризацию как некое «чудо» организационной перестройки компаний, хотя еще в 1990 году М. Хаммер предостерегал об опасности переоценки роли информационных технологий, ведущей к попыткам автоматизации существующих несовершенных видов управленческих работ, которая может свестись к полной имитации компьютером “врожденных” недостатков, присущих “ручным” способам реализации неэффективных бизнес-процессов. М. Хаммер характеризует такую ситуацию как “воплощение устаревших бизнес-процессов в кремнии и программном обеспечении”. Поэтому внедрению информационных технологий должна предшествовать коренная перестройка внутрифирменного управления, а на смену пониманию компьютерной службы предприятия, как одной из его функциональных структур, должно придти встраивание информационных технологий во все обновленные бизнес-процессы. Несомненная полезность реинжениринга объясняется не только объективной корректностью его составных элементов и его надежностью как целого, его принципиальной новизной и практической ценностью, но и присущим реинженирингу способом анализа проблем, а также тем, что принимаемые на основе реинжениринга решения порождают общественный резонанс касательно связанных с ним событий. Изменение среды деловой активности, окружающей компанию, предопределяет необходимость реинжениринга концепции стратегического планирования. Г. Ансофф и Г. Минцберг первыми осознали возникшую проблему и необходимость активного поиска путей ее решения. Стратегия компании должна удовлетворять быстро изменяющимся условиям ее внешнего окружения. Вызывающе дерзкая концепция реинжениринга претендует на то, чтобы предложить осаждаемым разнообразными проблемами менеджерам процедуру принятия эффективных решений. Цели автоматизации предприятия Предприятие - это единый организм, и улучшение чего-либо одного может привести к малейшему сдвигу в сторону успеха в лучшем случае, либо к снижению общих показателей в худшем. Руководителям, а в особенности руководителям финансовых отделов, необходимо принимать комплексные решения, касающиеся всего предприятия. А загруженность решением оперативных задач еще более усложняет процесс управления. Для упрощения управления, прежде всего финансового, необходимо иметь эффективную систему управления предприятием, включающую систему менеджмента качества, и информационную систему их поддержки. Что может дать внедрение информационной системы? снижение общих затрат предприятия в цепи поставок (при закупках), повышение скорости товарооборота, сокращение излишков товарных запасов до минимума, увеличение и усложнение ассортимента продукции, улучшение качества продукции, выполнение заказов в срок и повышение общего качества обслуживания заказчиков, Основными целями автоматизации деятельности предприятия являются: Сбор, обработка, хранение и представление данных о деятельности организации и внешней среде в виде, удобном для финансового и любого другого анализа и использования при принятии управленческих решений. Автоматизация выполнения бизнес операций (технологических операций), составляющих целевую деятельность предприятия. Автоматизация процессов, обеспечивающих выполнение основной деятельности. Цели и задачи ИС Основная цель – автоматизация процессов. Задачи: Планирование производственной деятельности. Составление производственных планов различного уровня, - от стратегических до оперативных, - и проверка возможности их исполнения в соответствии с состоянием производственных мощностей и людских ресурсов. Степень детализации планов различного уровня различна - от набора продукции для решения задач стратегического планирования до конкретных материалов или производственных операций для оперативного управления производством; Управление закупками, запасами, продажами. Это автоматизация процессов планирования и учета для задач снабжения (материально-технического обеспечения) производства, сбыта готовой продукции и управления складскими запасами; Управление финансами. Как правило, это ведение бухгалтерии, расчеты с дебиторами и кредиторами, учет основных средств, управление наличными средствами и планирование финансовой деятельности; Управление персоналом. В подсистеме управления персоналом реализованы все основные потребности работы с кадрами: найм и увольнение персонала, учет сведений о сотрудниках, планирование их карьерного роста, расчет заработной платы и учет рабочего времени. Рассмотрение персонала, как отдельного вида ресурса позволяет связать воедино кадровый потенциал предприятия и производственные планы, что также возможно при использовании информационной системы; Управление затратами. Сюда относится учет всех затрат предприятия и калькуляция себестоимости готовой продукции или услуг; Управление проектами/программами. Современная деятельность предприятия все больше рассматривается через призму реализации производственных проектов или программ, для которых может осуществляться отдельное планирование и учет; Проектирование продукции и технологических процессов. Информация о составе продукции, технологических маршрутах ее изготовления, разработка продукции в соответствии с требованиями клиентов, а также оценка затрат, которые понесет предприятие при выпуске такой продукции. Как можно было заметить, информационные системы способны на многое. Но для получения эффективности при крупном капиталовложении при приобретении системы, следует правильно выбрать, какая именно система нужна. ТИПЫ ОРГАНИЗАЦИОННЫХ СТРУКТУР Концепцию традиционных, или так называемых иерархических, организационных структур, сформулировал Макс Вебер. Согласно этой концепции структуры бывают линейными и функциональными. В линейной структуре разделение системы управления на составляющие части осуществляется по производственному признаку с учетом степени концентрации производства, технологических особенностей, широты номенклатуры продукции и других признаков. Линейная структура четко функционирует при решении задач с выполнением повторяющихся операций, но трудно приспосабливается к новым целям и задачам. Линейная структура управления широко используется мелкими и средними фирмами, осуществляющими несложное производство при отсутствии широких кооперационных связей между предприятиями (табл. 5.6). Таблица 5.6 Линейная оргструктура Область предприятия, применения функциональной реализующие узкоспециализированные сложные предприятия; и структуры – это длительные однопродуктовые инновационные научно-исследовательские и предприятия; проекты; средние проектно-конструкторские организации; крупные специализированные предприятия (табл. 5.7). Таблица 5.7 Функциональная оргструктура Современная оргструктура – это линейно-функциональная структура, которая обеспечивает разделение управленческого труда. При этом линейные звенья управления призваны командовать, а функциональные – консультировать, помогать в разработке конкретных вопросов и подготовке соответствующих решений, программ, планов. Руководители функциональных служб осуществляют влияние на производственные подразделения формально, не имея, как правило, права самостоятельно отдавать им распоряжения (табл. 5.8). Линейно-функциональная оргструктура обеспечила качественно новое разделение труда в управлении, но при решении проблемных задач становится малоэффективной. Совершенствование линейно-функциональной оргструктуры привело к появлениюдивизиональной оргструктуры управления, когда отдельные подразделения, обладающие определенной самостоятельностью, вступают в договорные отношения друг с другом на основе самофинансирования. Принятие стратегических решений остается за высшим руководством. Таблица 5.8 Линейно-функциональная оргструктура Потребность в применении дивизиональной структуры возникла в связи с резким увеличением размеров предприятий, диверсификацией их деятельности, усложнением технологических процессов. Ключевыми фигурами в управлении организациями с данной структурой становятся не руководители функциональных подразделений, а менеджеры, возглавляющие производственные подразделения. Структуризация организации по отделениям производится, как правило, по одному из критериев: по выпускаемой продукции, ориентации на потребителя, обслуживаемым регионам. Руководители вторичных функциональных служб отчитываются перед управляющим производственного подразделения. Помощники руководителя производственного отделения контролируют деятельность функциональных служб, координируя их деятельность по горизонтали (табл. 5.9). Таблица 5.9 Дивизиональная оргструктура Область применения – это многопрофильные предприятия; предприятия с расположением в различных регионах; предприятия, осуществляющие сложные инновационные проекты. При поиске эффективной структуры управления в центре внимания всегда находились вопросы правильного соотношения централизации и децентрализации в управлении. На практике не встречается полностью централизованных или децентрализованных структур. В организациях с сильно децентрализованными структурами важнейшие решения часто принимаются только служащими, занимающими достаточно высокие должности (не ниже руководителя отдела). Такая форма децентрализации в крупных фирмах называется федеральной децентрализацией. Для определения степени централизации организации по сравнению с другими используют следующие характеристики: количество решений, принимаемых на нижестоящих уровнях управления: чем больше число решений, которые принимают нижестоящие руководители, тем меньше степень централизации; важность решений, принимаемых на нижестоящих уровнях; последствия решений, принимаемых на нижестоящих уровнях. Если руководители среднего звена могут принимать решения, затрагивающие более чем одну функцию, то организация слабо централизована; контроль за работой подчиненных. В слабо централизованной организации высшее руководство редко проверяет повседневные решения подчиненных руководителей. Оценка действий делается на основании суммарных достигнутых результатов. Решение вопроса централизации и децентрализации в управлении привело к появлению структур органического типа. Такие структуры характеризуются индивидуальной ответственностью каждого работника за общий результат. Главное свойство таких структур, известных в практике управления как гибкие и адаптивные, – присущая им способность сравнительно легко менять свою форму, приспосабливаться к новым условиям, органически вписываться в систему управления (табл. 5.10). Структуры органического типа ориентируются на ускоренную реализацию сложных программ и проектов в рамках крупных предприятий и объединений, целых отраслей и регионов. Как правило, органические структуры управления формируются на временной основе, т.е. на период реализации проекта, программы, решения проблемы или достижения поставленных целей. Таблица 5.10 Сравнительная характеристика иерархического и органического типов управления Разновидностями структур органического типа являются программно-целевые организационные структуры. Такие структуры формируются при разработке организацией проектов, под которыми понимаются любые процессы целенаправленных изменений в системе, например модернизация производства, освоение новых изделий или технологий, строительство объектов и т.д. В условиях управления многофункциональными программами, требующими увеличения числа проектных и функциональных руководителей, становится необходимым создание специального штабакоординатора на среднем уровне. Его задачи: обеспечение руководителей проектов необходимой информацией, анализ организационно-технических решений, фиксация сроков выполнения программ и т.д. Такая структура называетсяматрично-штабной. Она отражает все виды руководства: линейное, функциональное, дивизиональное, обеспечивая координацию деятельности между ними. Одной из последних разработок, развивающих идею гибких оргструктур, является их построение в форме перевернутой пирамиды, в которой на верхний уровень иерархии выведены специалисты-профессионалы, в то время как руководитель организации находится в нижней части схемы (рис. 5.3). Рис. 5.3. Гибкая оргструктура Такие оргсруктуры могут использоваться там, где профессионалы имеют опыт и знания, дающие им возможность действовать независимо и квалифицированно, удовлетворять запросы клиентов, например в организациях здравоохранения и образования, где сконцентрировано большое число специалистов, работающих самостоятельно при поддержке вспомогательного или обслуживающего персонала. В рыночных условиях появляются новые формы интеграции предприятий диверсифицированного типа (табл. 5.11). Принцип создания таких структур: концентрация ресурсов, мощностей, производств разного профиля для выпуска продукции массового спроса, возможность маневрирования средствами, сокращения затрат производства, создание предпосылок внедрения научно-технических новшеств. Критерии оценки качества информационных систем Качество информационной системы – это совокупность свойств системы, обусловливающих возможность ее использования для удовлетворения определенных, в соответствии с ее назначением, потребностей. Количественные характеристики этих свойств определяются показателями. Основными показателями качества информационных систем являются надежность, достоверность, безопасность. Надежность системы – свойство системы сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения. Надежность информационных систем не самоцель, а средство обеспечения своевременной и достоверной информации на ее выходе. Поэтому показатель достоверности функционирования имеет для информационных систем главенствующее значение, тем более что показатель своевременности информации в общем случае охватывается показателем достоверности. Достоверность функционирования информационной системы – свойство системы, обусловливающее безошибочность производимых ею преобразований информации. Достоверность функционирования информационной системы полностью определяется и измеряется достоверностью ее результатной информации. Безопасность информационной системы – свойство системы, заключающееся в способности обеспечить конфиденциальность и целостность информации, то есть защиту информации от несанкционированного доступа с целью ее раскрытия, изменения или разрушения. Эффективность системы – это свойство системы выполнять поставленную цель в заданных условиях использования и с определенным качеством. Показатели эффективности характеризуют степень приспособленности системы к выполнению поставленных перед нею задач и являются обобщающими показателями оптимальности функционирования ИС, зависящими от локальных показателей, каковыми являются надежность, достоверность, безопасность. Экономическая эффективность системы – кардинальный обобщающий показатель, характеризующий целесообразность произведенных на создание и функционирование системы затрат. Состав и формирование требований к проектируемой информационной системе Обоснованное и тщательное формирование требований к информационной системе – необходимое условие успешного выполнения работ по созданию системы. Начало формирования требований связано уже с первой (предпроектной) стадией создания системы, когда проводится обоснование целесообразности разработки. Чем полнее, обоснованнее будут сформулированы требования на начальном этапе (на стадии ТЗ), тем успешнее (быстрее, дешевле) может оказаться процесс создания системы. Требования к автоматизированной системе делят на три группы. 1. Требования к системе в целом Включают в себя 1.1. Требования к структурным характеристикам и режимам функционирования системы: – состав основных функций (состав функциональных подсистем); – объектная структура системы (число уровней иерархии, основные объектные подсистемы на каждом уровне); – требования к средствам и способам обмена информацией между объектными подсистемами в случае их территориальной разобщенности; – требования к интегрируемости (совместимости) со смежными системами или уже реализованными элементами создаваемой системы, с которыми должна быть обеспечена возможность взаимодействия; – требования к режимам функционирования системы (пакетный, интерактивный и т. д.). 1.2. Требования к показателям назначения, т. е. к важнейшим характеристикам системы, определяющим степень соответствия системы ее основному назначению. Например, для систем продажи и резервирования железнодорожных билетов показатели назначения – это пропускная способность (среднее время приобретения билета), число подключаемых терминалов кассира, обслуживаемые регионы; для информационно-справочной системы вокзала – это среднее время реакции, число терминалов пользователей, показатели достоверности выдаваемой информации (показатели степени соответствия данных, хранящихся в системе, истинной ситуации). 1.3. Требования к надежности: – перечень отказов (указание на то, что понимается под отказом) системы или ее частей, по которым следует предъявлять требования по надежности; – состав и количественные значения (нормы) показателей надежности по типам отказов для системы или ее элементов; – требования к методам оценки и контроля надежности на разных этапах создания системы (жизненного цикла системы); 1.4. Требования к качеству данных: – показатели достоверности данных (вводимых, хранящихся, выдаваемых системой) и их количественные значения; ситуации (события), при которых должна быть обеспечена сохранность данных; – возможные способы несанкционированного доступа к данным, от которых система должны быть защищена; 1.5. Требования по стандартизации и унификации: используемые стандарты при создании системы документооборота, используемые классификаторы, требования по применению типовых программных и технических средств при создании системы; 1.6. Требования к развитию системы: возможности модификации, включения новых функций, открытости (возможности взаимодействия с другими системами), масштабируемости (увеличения числа пользователей, числа подключаемых терминалов и пр.) 2. Требования к функциям (задачам), выполняемым системой; включают в себя: – перечни задач по каждой функциональной подсистеме (комплексу информационных технологий) с их распределением по уровням системы; – требования к качеству реализации каждой функции (задачи, комплекса задач); – формы представления входной и выходной информации; – временной регламент (требования к временным характеристикам); требования к качеству результатов (достоверности выдаваемой информации, точности расчетов и т. д.). 3. Требования к видам обеспечения (информационному, техническому, программному и т. д.). Состав требований к видам обеспечения зависит от типа и назначения системы. Требования к информационному обеспечению могут включать в себя требования к качеству данных, составу и способу организации данных, их совместимости со смежными системами, использованию классификаторов и унифицированных документов, методам контроля, хранения, обновления и восстановления данных. В состав требований к программному обеспечению могут входить требования к качеству программных средств, к интерфейсам, используемым языкам программирования, операционной системе и т. д. В состав требований к техническому обеспечению могут входить требования к функциональным, конструктивным, эксплуатационным характеристикам отдельных видов аппаратных средств, например, к быстродействию средств передачи данных, производительности средств вычислений, объемам запоминающих устройств, надежности отдельных устройств или комплексов и т. д. Структура ИС Структуру информационных систем составляет совокупность отдельных ее частей, называемых подсистемами. Функциональные подсистемы реализуют и поддерживают модели, методы и алгоритмы получения управляющей информации. Состав функциональных подсистем весьма разнообразен и зависит от предметной области использования информационной системы, специфики хозяйственной деятельности объекта, управления. В состав обеспечивающих подсистем обычно входят: 1. информационное обеспечение — методы и средства построения информационной базы системы, включающее системы классификации и кодирования информации, унифицированные системы документов, схемы информационных потоков, принципы и методы создания баз данных; 2. техническое обеспечение — комплекс технических средств, задействованных в технологическом процессе преобразования информации в системе. В первую очередь это вычислительные машины, периферийное оборудование, аппаратура и каналы передачи данных; 3. программное обеспечение включает в себя совокупность программ регулярного применения, необходимых для решения функциональных задач, и программ, позволяющих наиболее эффективно использовать вычислительную технику, обеспечивая пользователям наибольшие удобства в работе; 4. математическое обеспечение — совокупность математических методов, моделей и алгоритмов обработки информации, используемых в системе; 5. лингвистическое обеспечение — совокупность языковых средств, используемых в системе с целью повышения качества ее разработки и облегчения общения человека с машиной. Организационные подсистемы по существу относятся также к обеспечивающим подсистемам, но направлены в первую очередь на обеспечение эффективной работы персонала, и поэтому они могут быть выделены отдельно. К ним относятся: 1. кадровое обеспечение — состав специалистов, участвующих в создании и работе системы, штатное расписание и функциональные .обязанности; 2. эргономическое обеспечение — совокупность методов и средств, используемых при разработке и функционировании информационной системы, создающих оптимальные условия для деятельности персонала, для быстрейшего освоения системы; 3. правовое обеспечение — совокупность правовых норм, регламентирующих создание и функционирование информационной системы, порядок получения, преобразования и использования информации; 4. организационное обеспечение — комплекс решений, регламентирующих процессы создания и функционирования как системы в целом, так и ее персонала. Понятие жизненного цикла (ЖЦ) является одним из ключевых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации [4]. Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02 [5]. Согласно стандарту структура жизненного цикла основывается на трех группах процессов: · основные процессы (заказ, поставка, разработка, эксплуатация, сопровождение); · вспомогательные процессы (обеспечивают выполнение основных процессов): o документирование – работы по разработке, выпуску, редактированию, распространению и сопровождению документов, в которых нуждаются все заинтересованные лица; o управление конфигурацией (конфигурационное управление) включает работы: определение и установление состояния программных объектов в системе; управление изменениями и выпуском объектов; обеспечение полноты, совместимости и правильности объектов; управление хранением, обращением и поставкой объектов; - обеспечение качества – работы по обеспечению соответствия создаваемой системы и реализуемых процессов жизненного цикла установленным требованиям и утвержденным планам; - верификация – работы соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия создаваемых промежуточных результатов установленным требованиям по мере реализации проекта. Различают верификацию договора, процесса, требований, проекта, системы, сборки системы и документации; - аттестация – работы соответствующего субъекта по проверке полного соответствия требований и конечного продукта функциональному назначению системы; - совместный анализ – работы по оценке состояния или результатов какой-либо работы (системы); - аудит – работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора; - разрешение проблем – работы по анализу и устранению проблем, обнаруженных при реализации проекта; · организационные: - управление проектами – работы по планированию и управлению процессами, включая контроль, проверку и оценку выполненных работ с формированием отчетности; - создание инфраструктуры проекта – работы по установлению и обеспечению инфраструктуры, необходимой для любого другого процесса. Инфраструктура может содержать технические и программные средства, инструментальные средства, методики, стандарты и условия для разработки, эксплуатации или сопровождения системы; - усовершенствование – работы по оценке, контролю и улучшению процессов жизненного цикла; - обучение – работы по планированию и проведению обучения персонала, включая разработку учебных материалов. При этом под персоналом понимаются не только конечные пользователи, которые будут эксплуатировать систему, но и разработчики системы. Например, разработчики должны быть обучены технологиям и средствам программирования, принятым в организации, и даже обучены правильно внедрять и обучать конечных пользователей работе с системой. Как бы это ни парадоксально звучало, но обучать правильной методике и приемам обучения тоже необходимо. Стадии жизненного цикла информационной системы Классический ЖЦ Системный анализ ИСО / МЭК 12207 Заказ ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00 Стадия Формирование требований к ИС Техникоэкономическое обоснование1 Разработка концепции ИС (для (ТЭО) комплексных многоуровневых и интегрированных систем) Анализ требований Техническое задание (ТЗ) Разработка Проектирование Основные этапы (работы) 1. Обследование объекта и обоснование необходимости создания ИС. 2. Формирование требований Заказчика к ИС. 3. Оформление договора между Разработчиком и Заказчиком. 1. Поиск путей удовлетворения требований Заказчика на уровне концепции создаваемой системы (структура, функции, программно-техническая платформа, режимы). 2. Рассмотрение альтернативных вариантов концепции системы, их анализ и выбор лучшей концепции. Разработка, согласование и утверждение ТЗ на создание ИС. Эскизный проект Разработка предварительных проектных решений2 по (для комплексных многоуровневых и интегрированных системе и ее частям. систем) 1. Разработка частей проекта для испытаний в реальных, но ограниченных условиях Пилот-проект функционирования с целью проверки предварительно (макетирование3, прототипирование) принятых решений. (при необходимости) 2. Проведение испытаний на головном объекте или стенде и анализ результатов испытаний. 1. Разработка проектных решений по системе и ее частям. 2. Разработка документации на ИС и ее части. 3. Разработка документации на поставку изделий для Технический проект комплектования ИС и/или технических заданий на их разработку. 4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации (строительство, монтаж, наладка и др.). Кодирование (реализация) Рабочая документация Тестирование Интеграция и тестирование Ввод в действие на головном объекте (ввод в эксплуатацию, внедрение) Разработка и эксплуатация Внедрение и сопровождение Тиражирование (при внедрении на нескольких объектах) Сопровождение и эксплуатация Сопровождение (авторский надзор) 1. Разработка рабочей документации на систему и ее части. 2. Разработка программных и технических средств и/или адаптация приобретаемых. 3. Тестирование средств. 1. Загрузка БД типовыми исходными данными и тестами. 2. Интеграция программ и тестирование в имитированной среде. 3. Интеграция программных средств с аппаратными в реальной операционной и внешней среде. 4. Тестирование в реальной среде. 5. Разработка комплекта документации для пользователей. 1. Подготовка объекта автоматизации к вводу ИС в действие. 2. Подготовка персонала. 3. Комплектация ИС поставляемыми изделиями. 4. Проведение предварительных испытаний4 и 5 передача ИС для опытной эксплуатации . 5. Проведение опытной эксплуатации. 6. Проведение приемочных испытаний6 по сдаче ИС в постоянную эксплуатацию. 1. Передача эталона загрузочных модулей ПО и эксплуатационной документации в группу сопровождения или ОФАП7 ОАО «РЖД». 2. Тиражирование документации. 3. Обучение и консультации пользователей. 4. Поставка ПО и документации на объекты внедрения. 1. Выполнение работ в соответствии с гарантийными обязательствами8. 2. Оказание научно-технических услуг в 9 послегарантийный период . 3. Разработка методики оформления отчетов об ошибках и предложениях на изменение версий. 4. Учет состояния конфигураций ИС. Модели жизненного цикла информационной системы: каскадная модель - предлагает переход на следующие этапы после полного осуществления работ по предыдущему этапу. Модель демонстрирует классический подход в любых прикладных областях; Основные достоинства каскадной модели: 1. На каждом этапе формируется законченный набор проектной документации, отвечающая критериям полноты и согласованности. На заключительном этапе разрабатывается пользовательская документация, соответствующая стандартам (т.е. все виды обеспечения ИС: организация методов, информационное, программное, аппаратное). 2. Выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты. Применение каскадной модели для проектирования ИС предпочтительно для тех ИС, в самом начале разработки которых можно достаточно точно и полно сформулировать все требования, оставляя тем не менее разработчикам свободу выбора реализации, наилучшей с технической точки зрения. К таким ИС относятся сложные расчетные системы, системы реального времени. Недостатки каскадной системы: 1. 2. Существенная задержка получения результатов. Ошибки и недоработки выясняются, как правило, на следующем этапе, поэтому для их исправления нужно возвращаться на предыдущий этап. 3. Сложность распараллеливания работ по проекту. Необходимо постоянно согласовывать различные части проекта при параллельном выполнении несколькими проектировщиками. При последовательной разработке крайне сложно внести изменения в проект после завершения этапа и передачи проекта на следующую стадию. 4. Информационная перенасыщенность каждого из этапов. Эта проблема возникает из-за сильной зависимости между различными группами разработчиков. В процессе выполнения проекта могут также изменяться состав разработчиков и чем сложнее проект, тем больше времени потребуется, чтобы ввести нового разработчика в курс дела. 5. Сложность управления проектом – вызвана тем, что группы, работающие над разными этапами, зависимы друг от друга, поэтому часто требуется административное вмешательство для согласования сроков выполнения работ. Высокий уровень риска и ненадежность инвестиций. Проекты, разрабатываемые по каскадной 6. схеме имеют повышенный уровень риска. итерационная модель - поэтапная модель с промежуточным контролем и циклами обратной связи. Преимущество данной модели - поэтапные корректировки, которые обеспечивают меньшую трудоемкость по сравнению с каскадной. Однако время жизни каждого из этапов рассчитывается на весь период разработки; спиральная модель - данная модель делает упор на начальные этапы анализа и проектирования. Эта модель представляет собой итерационный процесс разработки, где каждая итерация (цикл), представляет собой законченный цикл разработки, приводящий к выпуску версии изделия (версии проекта ИС), который совершенствуется от итерации к итерации, чтобы стать значимой информационной системой. При этом каждый виток спирали соответствует поэтапной модели создания информационной системы. Т.о. углубляется и последовательно конкретизируется обоснованный вариант ИС, который и доводится впоследствии до реализации. Преимущества спиральной модели: 1. Итерационная разработка существенно упрощает внесение изменений в проект. 2. При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. 3. Уменьшение уровня рисков. Данное преимущество является следствием предыдущего, т. к. риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. 4. Итерационная разработка обеспечивает большую гибкость в управлении проектом. Можно сократить сроки разработки за счет уменьшения функциональности системы или использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок. Это актуально в условиях конкурентной борьбы, когда надо противостоять продвижению изделия конкурентов ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ СИСТЕМ Сравнительный анализ стандартов информационной безопасности. Опыт эксплуатации существующих компьютерных систем обработки информации показывает, что проблема обеспечения безопасности еще далека от своего решения, а предлагаемые производителями различных систем средства защиты сильно различаются как по решаемым задачам и используемым методам, так и по достигнутым результатам. Это определяет актуальность проблемы построения защищенных систем обработки информации, решение которой следует начать с анализа причин сложившейся ситуации. Проблема защиты машинной информации на современном уровне развития информатизации общества столь важна и многогранна, что заслуживает более подробного рассмотрения, чем другие аспекты автоматизации профессиональной деятельности. Для того чтобы объединить усилия всех специалистов в направлении конструктивной работы над созданием защищенных систем, необходимо определить, что является целью исследований, что мы хотим получить в результате и чего в состоянии достичь. Для ответа на эти вопросы и согласования всех точек зрения на проблему создания защищенных систем разработаны и продолжают разрабатываться стандарты информационной безопасности. Это документы, регламентирующие основные понятия и концепции информационной безопасности на государственном или межгосударственном уровне, определяющие понятие «защищенная система» посредством стандартизации требований и критериев безопасности, образующих шкалу оценки степени защищенности вычислительных систем (ВС). В соответствии с этими документами защищенная система обработки информации представляет собой систему, отвечающую тому или иному стандарту информационной безопасности. Этот факт позволяет сопоставлять степени защищенности различных систем относительно установленного стандарта. Основные понятия и определения. Политика безопасности — совокупность норм и правил, обеспечивающих эффективную защиту системы обработки информации от заданного множества угроз. Модель безопасности — формальное представление политики безопасности. Дискреционное, или произвольное, управление доступом — управление доступом, основанное на совокупности правил предоставления доступа, определенных на множестве атрибутов безопасности субъектов и объектов, например, в зависимости от грифа секретности информации и уровня допуска пользователя. Ядро безопасности — совокупность аппаратных, программных и специальных компонентов ВС, реализующих функции защиты и обеспечения безопасности. Идентификация — процесс распознавания сущностей путем присвоения им уникальных меток (идентификаторов). Аутентификация — проверка подлинности идентификаторов сущностей с помощью различных (преимущественно криптографических) методов. Адекватность — показатель реально обеспечиваемого уровня безопасности, отражающий степень эффективности и надежности реализованных средств защиты и их соответствия поставленным задачам (в большинстве случаев это задача реализации политики безопасности). Таксономия — наука о систематизации и классификации слож-ноорганизованных объектов и явлений, имеющих иерархическое строение. Таксономия основана на декомпозиции явлений и поэтапном уточнении свойств объектов (иерархия строится сверху вниз). Прямое взаимодействие — принцип организации информационного взаимодействия (как правило, между пользователем и системой), гарантирующий, что передаваемая информация не подвергается перехвату или искажению. Защищенная система обработки информации для определенных условий эксплуатации обеспечивает безопасность (доступность, конфиденциальность и целостность) обрабатываемой информации и поддерживает свою работоспособность в условиях воздействия на нее заданного множества угроз. Под защищенной системой обработки информации предлагается понимать систему, которая соответствует требованиям и критериям стандартов информационной безопасности. Отсюда вытекают следующие задачи, которые необходимо и достаточно решить, для того чтобы создать защищенную систему обработки информации, а именно: . в ходе автоматизации процесса обработки конфиденциальной информации реализовать все аспекты этого процесса, связанные с обеспечением безопасности обрабатываемой информации; . обеспечить противодействие угрозам безопасности, действующим в среде эксплуатации защищенной системы; · реализовать необходимые требования соответствующих стандартов информационной безопасности. Принципы разработки многопользовательских ИС Как следует из концепции CALS-технологий, разрабатываемые на предприятиях информационные системы и базы данных должны быть многопользовательскими. Принципы разработки многопользовательских баз данных заключаются в соблюдении двух обязательных условий: системный подход и стандартизация. Системный подход к разработке информационной системы означает, что такая система рассматривается как «большая система», состоящая из некоторого множества взаимосвязанных и взаимодействующих между собой элементов. При проектировании информационных систем необходимо: • учитывать интересы всех потенциальных пользователей систем; • использовать модульный принцип разработки и внедрения. Принцип учета интересов всех потенциальных пользователей системы определяет следующий порядок разработки БД. 1. Установить, каким специалистам и в каких подразделениях предприятия необходима информация о конкретном информационном объекте. 2. Установить признаки описания объектов различными пользователями. 3. Установить общий состав признаков объектов одного класса. Такой подход к проектированию увеличивает сроки разработки БД, но обеспечивает значительное снижение затрат на разработку всей системы в целом. Для пояснения данного принципа приведем реальный пример разработки БД на одном из предприятий, где появление программ создания баз данных было по достоинству оценено сотрудниками, и они стали разрабатывать необходимые для себя базы данных. Так как одной из задач, стоящих перед технологами цехов, являлся выбор инструмента для механической обработки деталей, они разработали свою цеховую БД по режущему инструменту (затратив на это и время и средства). В то же время в конструкторском отделе завода специалисты, занимающиеся проектированием режущего инструмента, также создали свою БД. Однако когда руководство приняло решение создать общезаводскую информационную систему по режущему инструменту, оказалось, что одни и те же признаки режущего инструмента разные специалисты описывали разными способами. В результате разработанные базы данных пришлось полностью переделывать, что потребовало как дополнительного времени, так и дополнительных затрат. Средства, затраченные на разработку несогласованных между специалистами баз данных, были потеряны для предприятия. Модульный принцип разработки и внедрения БД означает, что любая система должна разрабатываться в виде отдельных взаимосвязанных модулей (подсистем), которые могут внедряться в производство отдельно, т. е. до окончательной разработки всей системы. Стандартизация разработки информационных систем, учитывая их многопользовательский характер, включает в себя следующие аспекты: информационный, программный и аппаратный. Стандартизация информационного обеспечения обусловлена принципами компьютерной обработки информации, при которой объекты баз данных должны однозначно распознаваться компьютером. Стандартизация программного обеспечения многопользовательских, удаленных друг от необходима, так как при разработке друга систем данные одной системы должны обрабатываться программным обеспечением другой системы. Архитектура экспертной системы Экспертная система (ЭС) - это компьютерная программа, которая моделирует рассуждения человека-эксперта в некоторой определенной области и использует для этого базу знаний, содержащую факты и правила об этой области, специальную процедуру логического вывода. Разработка систем, основанных на знаниях, является составной частью исследований по ИИ, и имеет целью создание компьютерных методов решения проблем, обычно требующих привлечения экспертовспециалистов. Взаимодействие эксперта, пользователя и структурных частей системы можно представить в виде следующей базовой структуры. Рис.1. Базовая структура экспертной системы Рассмотрим архитектуру экспертной системы. База знаний. Основу ЭС составляет база знаний (БЗ), хранящая множество фактов и набор правил, полученных от экспертов, из специальной литературы. БЗ отличается от базы данных тем, что в базе данных единицы информации представляют собой не связанные друг с другом сведения, формулы, теоремы, аксиомы. В БЗ те же элементы уже связаны как между собой, так и с понятиями внешнего мира. Информация в БЗ - это все необходимое для понимания, формирования и решения проблемы. Она содержит два основных элемента: факты (данные) из предметной области и специальные эвристики или правила, которые управляют использованием фактов при решении проблемы. Знания могут быть представлены несколькими способами: логической моделью, продукциями, фреймами и семантическими сетями. Машина логического вывода (МЛВ). Главным в ЭС является машина логического вывода, осуществляющая поиск в базе знаний для получения решения. Она манипулирует информацией из БЗ, определяя в каком порядке следует выявлять взаимосвязи и делать выводы. МЛВ используются для моделирования рассуждений, обработки вопросов и подготовки ответов. Интерфейс пользователя. ЭС содержат языковой процессор для общения между пользователем и компьютером. Это общение может быть организовано с помощью естественного языка, сопровождаться графикой или многооконным меню. Интерфейс пользователя должен обеспечивать два режима работы: режим приобретения знаний и режим решения задач. В режиме приобретения знаний эксперт общается с ЭС при посредничестве инженера знаний. В режиме решения задач ЭС для пользователя является или просто носителем информации (справочником), или позволяет получать результат и объясняет способ его получения. Эксперты поставляют знания в экспертную систему и оценивают правильность получаемых результатов. Инженер по знаниям - специалист по искусственному интеллекту, выступающий в роли промежуточного буфера между экспертом и базой знаний. Помогает эксперту выявить и структурировать знания. Синонимы: когнитолог, инженер-интерпретатор, аналитик. Программисты разрабатывают программное обеспечение экспертной системы и осуществляют его сопряжение со средой, в которой оно будет использоваться Пользователь - специалист предметной области, для которого предназначена система, обычно его квалификация недостаточно высока, и поэтому он нуждается в помощи и поддержке своей деятельности со стороны экспертной системы. Многочисленные экспертные системы решают в настоящее время задачи в таких областях, как медицина, образование, бизнес, дизайн и научные исследования. Базовые функции экспертных систем 1. Приобретение знаний "Приобретение знаний - это передача потенциального опыта решения проблемы от некоторого источника знаний и преобразование его в вид, который позволяет использовать эти знания в программе". 2. Представление знаний Представление знаний — еще одна функция экспертной системы. Теория представления знаний — это отдельная область исследований, тесно связанная с философией формализма и когнитивной психологией. Предмет исследования в этой области — методы ассоциативного хранения информации, подобные тем, которые существуют в мозгу человека. При этом основное внимание, естественно, уделяется логической, а не биологической стороне процесса, опуская подробности физических преобразований. 3. Управление процессом поиска решения При проектировании экспертной системы серьезное внимание должно быть уделено и тому, как осуществляется доступ к знаниям и как они используются при поиске решения. Знание о том, какие знания нужны в той или иной конкретной ситуации, и умение ими распорядиться — важная часть процесса функционирования экспертной системы. Такие знания получили наименование метазнаний — т.е. знаний о знаниях. Решение нетривиальных проблем требует и определенного уровня планирования и управления при выборе, какой вопрос нужно задать, какой тест выполнить, и т.д. 4. Разъяснение принятого решения Вопрос о том, как помочь пользователю понять структуру и функции некоторого сложного компонента программы, связан со сравнительно новой областью взаимодействия человека и машины, которая появилась на пересечении таких областей, как искусственный интеллект, промышленная технология, физиология и эргономика. На сегодня вклад в эту область исследователей, занимающихся экспертными системами, состоит в разработке методов представления информации о поведении программы в процессе формирования цепочки логических заключений при поиске решения. Отличительные особенности ЭС 1. Экспертиза может проводиться только в одной конкретной области. 2. Создание новой БЗ для ЭС должно обеспечивать выполнение требований машины логического вывода. 3. ЭС объясняет ход решения задачи (цепочку рассуждений) понятным пользователю способом (можно спросить как и почему получилось такое решение и получить понятный ответ). 4. Выходные результаты являются качественными (например, совет), а не количественными (цифровыми). 5. Системы строятся по модульному принципу, что позволяет наращивать их базы знаний. Классификация экспертных систем Для классификации ЭС можно использовать различные критерии. 1. По назначению ЭС можно условно разделить на консультационные (информационные), исследовательские и управляющие. Консультационные ЭС предназначены для получения квалифицированных ответов; исследовательские - для помощи пользователю квалифицированно решать научные задачи; управляющие - для автоматизации управления процессами в реальном масштабе времени. 2. По сложности и объему базы знаний - неглубокие и глубокие. Неглубокие (простые) ЭС имеют относительно малые БЗ. Доказательства их заключений обычно коротки, большинство выводов являются прямыми следствиями информации, хранимой в базе знаний. Такие ЭС в основном предназначены для решения относительно простых задач типа ответов на запросы по требуемой информации. Глубокие ЭС делают свои выводы обязательно из моделей происходящих процессов, хранящихся в базах знаний. Сама модель процесса представляет собой набор правил, предназначенных для объяснения большого количества эмпирических данных. В глубоких ЭС доказательства выводов значительно длиннее, основываются на знаниях, выведенных из моделей. 3. По области применения ЭС делятся следующие классы. 1) Диагностика. Например, медицинская диагностика, когда системы используются для установления заболеваний; техническая диагностика, когда определяют неисправности в механических и электрических устройствах. 2) Прогнозирование. Прогнозирующие системы предсказывают возможные результаты или события на основе данных о текущем состоянии объекта (погода, урожайность, поток пассажиров). 3) Планирование и проектирование. Такие системы предназначены для достижения конкретных целей при решении задач с большим числом переменных (консультации по приобретению товаров, проектирование космических станций, и так далее). 4) Интерпретация. Интерпретирующие системы обладают способностью получать определенные заключения на основе результатов наблюдения (например, местоположение и тип судов в океане по данным акустических систем слежения). 5) Контроль и управление (например, регулирование финансовой деятельности предприятия и оказание помощи при выработке решений в критических ситуациях, управление воздушным движением, атомными электростанциями). 6) Обучение. Экспертно-обучающие системы реализуют следующие педагогические функции: учение, обучение, контроль и диагностику знаний, тренировку. 4. По связям с реальным миром. 1) Статические ЭС разрабатываются в предметных областях, в которых БЗ и интерпретируемые данные не меняются во времени. Они стабильны. Например, диагностика неисправностей в автомобиле. 2) Квазидинамические ЭС интерпретируют ситуацию, которая меняется с некоторым фиксированным интервалом времени. Например, микробиологические ЭС, в которых снимаются лабораторные изменения с технологического процесса один раз в 4 -5 часов и анализируется динамика полученных показателей по отношению к предыдущему измерению. 3) Динамические ЭС работают в сопряжении с датчиками объектов в режиме реального времени с непрерывной интерпретацие поступающих в систему данных. Например, управление гибкими производственными комплексами, мониторинг в реанимационных палатах. Можно выделить четыре основных класса ЭС: классифицирующие, доопределяющие, трансформирующие и мультиагентные. 1) Классифицирующие ЭС решают задачи распознавания ситуаций. Основным методом формирования решений в таких системах является дедуктивный логический вывод. 2) Доопределяющие ЭС используются для решения задач с не полностью определенными данными и знаниями. В таких ЭС возникают задачи интерпретации нечетких знаний и выбора альтернативных направлений поиска в пространстве возможных решений. В качестве методов обработки неопределенных знаний могут использоваться байесовский вероятностный подход, коэффициенты уверенности, нечеткая логика. 3) Трансформирующие ЭС относятся к синтезирующим динамическим экспертным системам, в которых предполагается повторяющееся преобразование знаний в процессе решения задач. В ЭС данного класса используются различные способы обработки знаний: · генерация и проверка гипотез; · логика предположений и умолчаний (когда по неполным данным формируются представления об объектах определенного класса, которые впоследствии адаптируются к конкретным условиям изменяющихся ситуаций); · использование метазнаний (более общих закономерностей) для устранения неопределенностей в ситуациях. 4) Мулътиагентные системы — это динамические ЭС, основанные на интеграции нескольких разнородных источников знаний. Эти источники обмениваются между собой получаемыми результатами в ходе решения задач. Системы данного класса имеют следующие возможности: · реализация альтернативных рассуждений на основе использования различных источников знаний и механизма устранения противоречий; · распределенное решение проблем, декомпозируемых на параллельно решаемые подзадачи с самостоятельными источниками знаний; · применение различных стратегий вывода заключений в зависимости от типа решаемой проблемы; · обработка больших массивов информации из баз данных; · использование математических моделей и внешних процедур для имитации развития ситуаций. 2) Синтезирующие. В системах решение синтезируется из отдельных фрагментов знаний. Этапы разработки экспертных систем В коллектив разработчиков ЭС входят как минимум четыре человека: эксперт; инженер по знаниям; программист; пользователь. Возглавляет коллектив инженер по знаниям, это ключевая фигура при разработке систем, основанных на знаниях. Экспертная система может полностью взять на себя функции, выполнение которых обычно требует опыта человека эксперта или играть роль ассистента для человека принимающего решение. Процесс разработки ЭС можно разделить на следующие этапы: 1. Выбор проблемы. 2. Разработка прототипа ЭС. 3. Доработка до промышленной ЭС. 4. Оценка ЭС. 5. Стыковка ЭС. 6. Поддержка ЭС. 1.Выбор подходящей проблемы. На этом этапе: ·определяется проблемная область; ·подбираются специалисты-эксперты; ·подбирается коллектив разработчиков; ·определяется предварительный подход к решению проблемы; ·готовится подробный план разработки. 2. Разработка прототипа ЭС. Прототипная система является сокращенной версией ЭС, спроектированной для проверки правильности представления фактов, связей и стратегий рассуждения эксперта. Объем прототипа – несколько десятков правил, фреймов или примеров. Разработка прототипа ЭС делится на шесть стадий: идентификация проблемы, извлечение знаний, концептуализация (структурирование) знаний, формализация, реализация прототипа, тестирование. 2.1. Идентификация проблемы – знакомство и обучение членов коллектива разработчиков, а также создание неформальной формулировки проблемы. На этом этапе уточняется задача, планируется ход разработки прототипа ЭС, определяются: ·ресурсы (время, люди и т.д.); ·источники знаний (книги, дополнительные эксперты); ·имеющиеся аналогичные ЭС; ·классы решаемых задач и т.д. 2.2. Извлечение знаний – получение инженером по знаниям наиболее полного из возможных представлений о предметной области и способах принятия решения в ней. Для извлечения знаний инженер использует различные методы: анализ текстов, диалоги, лекции, дискуссии, интервью, наблюдение и др. 2.3. Концептуализация (или структурирование) знаний – разработка неформального описания знаний о предметной области в виде графа, таблицы, диаграммы или текста, которое отражает основные концепции и взаимосвязи между понятиями предметной области. На этом этапе определяются: терминология, список основных понятий и их атрибутов, отношения между понятиями, структура входной и выходной информации, стратегия принятия решений и т.д. 2.4. Формализация знаний – это разработка базы знаний на языке представления знаний. На этом этапе используются: логические методы, продукционные модели, семантические модели, фреймы, объектноориентированные языки. 2.5. Реализация прототипа – разработка программного комплекса, демонстрирующего жизнеспособность подхода в целом. На этом этапе создается прототип ЭС (включающий базу знаний, остальные программные модули) при помощи: языков программирования (традиционных, специализированных), инструментальных средств разработки ЭС, «пустых» оболочек ЭС. 2.6. Тестирование – процесс выявления ошибок в подходе и реализации прототипа. Прототип проверяется на: удобство и адекватность интерфейса ввода/вывода, качество проверочных примеров, полнота и непротиворечивость правил в базе знаний. 3. Развитие прототипа до промышленной ЭС. Основная работа на этом этапе заключается в расширении базы знаний (добавление правил, фреймов, узлов семантической сети или других элементов знаний). После установления основной структуры знаний ЭС инженер по знаниям приступает к разработке и адаптации интерфейсов, с помощью которых система будет общаться с пользователем и экспертом. Система должна предоставлять пользователю возможность уточнять непонятные моменты, приостанавливать работу и т.д. 4. Оценка системы необходима для того, чтобы проверить точность работы программы и ее полезность. Оценка проводится по следующим критериям: критерии пользователя (понятность работы системы, удобство интерфейсов и т.д.); критерии приглашенных экспертов (оценка советов-решений, предлагаемые системой, оценка подсистемы объяснений и т.д.); критерии коллектива разработчиков (эффективность реализации, производительность, непротиворечивость базы знаний, количество тупиковых ситуаций и т.д.). 5. На этапе стыковки системы осуществляется соединение ЭС с другими программными средствами в среде, в которой она будет работать, и обучение людей, которых она будет обслуживать. Для подтверждения полезности системы важно предоставить каждому из пользователей возможность поставить перед ЭС реальные задачи и проследить, как она их выполняет. Стыковка включает обеспечение связи ЭС с существующими базами данных и другими системами на предприятии. 6. Поддержка системы. Готовые системы для повышения ее быстродействия и увеличения переносимости можно перекодировать на другой язык (например, С), но при этом уменьшится ее гибкость. Это можно производить с системами, которые разработаны для проблемных областей, где знания не изменяются. Если же проблемная область, для которой создана система, изменяется, то ее необходимо поддерживать в той инструментальной среде, где она создавалась. Базы данных: данные, модель данных, база данных, система управления базами данных, информационная система. Модели данных. Реляционная модель данных. При наличии большого объема перерабатываемой с помощью компьютера информации возникают задачи обеспечения наилучшего хранения данных (без дублирования) и манипулирования данными (поиска, сортировки, добавления, изменения, обработки). Следовательно, нужно наилучшим образом организовать данные и обеспечить наилучшее управление данными. Данные – информация, представленная в определенной форме, пригодной для последующей обработки, хранения и передачи. Предметная область – часть реального мира, подлежащая изучению с целью организации управления и последующей автоматизации. ПО определена, если известны существующие в ней объекты, их свойства и отношения. Модель данных – представление о предметной области в виде данных и связей между ними. То есть, модель данных – это совокупность взаимосвязанных структур данных и операций над этими структурами. Понятие “Модель данных” включает три компонента: 1) организацию данных (количество и типы объектов модели данных, ограничения на структуру данных); 2) множество допустимых операций над данными: операции выборки (поиск), операции модификации (включить, удалить, изменить данные); 3) средства обеспечения логической целостности и достоверности данных (ограничения на значения данных и связи), с помощью которых достигается непротиворечивость хранимой информации. Выбор модели данных зависит от объема информации, сложности решаемых задач и имеющегося технического и программного обеспечения. База данных – совокупность данных конкретной предметной области. Они организованы по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования, и не зависят от программ обработки. Система управления базами данных – набор программных средств (программная система или пакет), обеспечивающих создание и обслуживание баз данных и выполнение операций над данными БД (доступ к ним и обработку). СУБД поддерживает один из типов моделей данных – сетевую, иерархическую или реляционную. Реляционная модель ориентирована на табличное представление данных, т.е. организацию данных в виде двумерных таблиц. В теории множеств таблице соответствует термин отношение (relation), который дал название модели. Реляционная база данных – база данных, логически организованная как набор отношений (прямоугольных таблиц) конкретной предметной области. Таблица соответствует объекту ПО; строка (кортеж) – запись об одном экземпляре объекта. Размещение в одной строке таблицы определенных элементов данных означает установление между ними связи или отношения (relation). Значения в столбце (поле) таблицы определяют характеристику или свойство объекта (атрибут отношения). Таблица имеет фиксированное число столбцов, их порядок фиксирован; число строк – произвольное, их порядок безразличен. Таблица обладает следующими свойствами: столбцам (полям) присвоены уникальные имена; элементы каждого столбца имеют одинаковую природу, т.е. столбцы однородные; в таблице нет одинаковых строк (записей), т.е. любые две строки отличаются хотя бы одним элементом (полем записи); строки и столбцы могут обрабатываться в любой последовательности. Реляционная БД обычно включает несколько таблиц. Связи между таблицами осуществляется с использованием ключей. Ключ – атрибут (поле) или совокупность атрибутов, значения которых однозначно определяют запись в таблице. Преимущества хранения данных в РБД : каждый элемент данных хранится только в одной таблице (экономия места); внесение изменений упрощается, уменьшается риск ошибки (например, в написании фамилий); наличие связей между таблицами ускоряет обработку взаимосвязанной информации; ошибочные записи (с некорректными ссылками) должны автоматически исключаться. Техническим возможностям персональных компьютеров в настоящее время лучше всего соответствуют реляционные СУБД. Информационная система представляет собой коммуникационную систему по сбору, передаче и обработке информации о заданной предметной области, снабжающую всех своих пользователей необходимой информацией. Информационную систему определяют как систему информационных, математических, программных, языковых, организационных и технических средств, предназначенных для централизованного накопления и коллективного многоаспектного использования данных для получения необходимой информации. Основными компонентами ИС являются : собственно база данных, содержащая необходимую информацию и описание структуры хранимых данных; система управления базой данных, выполняющая типовые процедуры управления данными; прикладная программа (приложение пользователя), реализующая требуемый алгоритм ведения диалога пользователя с информационной системой для обслуживания БД и решения всего комплекса задач обработки данных. Обеспечение надежности работы ИС. Транзакции. OLTP-системы. Надежность- свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, ремонтов, хранения и транспортирования (ГОСТ 27.002-83). Транзакция - группа последовательных операций, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена целиком либо успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще и тогда она не должна произвести никакого эффекта. Иными словами транза?кция это операция перевода БД из одного непротиворечивого состояния в другое непротиворечивое состояние. Свойства транзакции:- Atomicity (атомарность): определяет, что транзакция является наименьшим, неделимым блоком алгоритма изменения данных. Другими словами, любые части (подоперации) транзакции либо выполняются все, либо не выполняется ни одной такой части. Поскольку на самом деле невозможно одновременно и атомарно выполнить последовательность команд внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех до сих пор произведённых действий должны быть отменены и система возвращается в исходное состояние.- Consistency (непротиворечивость): по окончанию транзакция оставляет данные в непротиворечивом состоянии.- Isolation (изоляция): во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии. Например, если транзакция изменяет сразу несколько полей в базе данных, то другой запрос, выполненный во время выполнения транзакции, не должен вернуть одни из этих полей с новыми значениями, а другие с исходными.- Durability (долговечность): независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, останутся сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он должен быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя. В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций. OLTP (Online Transaction Processing) — обработка транзакций в реальном времени. OLTP система – ИС, ориентированная на обработку небольших по размерам и сложности транзакций, идущих большим потоком. OLTP-системы предназначены для ввода, структурированного хранения и обработки информации (операций, документов) в режиме реального времени. OLTP-приложениями охватывается широкий спектр задач во многих отраслях — банковские и биржевые операции, в промышленности — регистрация прохождения детали на конвейере, фиксация в статистике посещений очередного посетителя веб-сайта, автоматизация бухгалтерского, складского учёта и учёта документов и т. п. Приложения OLTP, как правило, автоматизируют структурированные, повторяющиеся задачи обработки данных, такие как ввод заказов и банковские транзакции. OLTP-системы проектируются, настраиваются и оптимизируются для выполнения максимального количества небольших транзакций за короткие промежутки времени. Как правило, большой гибкости здесь не требуется, и чаще всего используется фиксированный набор надёжных и безопасных методов ввода, модификации, удаления данных и выпуска оперативной отчётности. Основным показателем эффективности является количество транзакций, выполняемых за секунду. Другой важной характеристикой OLTP-системы является время ответа на запрос. Для удовлетворения таких требовий на уровне архитектуры данных прибегают к сильной нормализации. Обычно аналитические возможности OLTP-систем сильно ограничены (либо вообще отсутствуют), так как выполнение сложных аналитических запросов противорецит концепции быстрой работы в реальном времени. Для OLTP систем крайне важной характеристикой является надежность работы и сохранение данных при воздействии различных внешних неблагоприятных факторов. Организация труда разработчиков АИС Очевидно, что основным вопросом организации труда при разработке АИС является организация труда разработчиков АИС. Важным элементом методологии программирования является принцип бригадной организации работ. Практическая реализация больших и средних программных проектов требует умения и опыта многих, входящих в бригаду, программистов. Выде-ляют три основные роли разработчиков: 1. архитектор проекта; 2. ответственные за подсистемы; 3. прикладные программисты. Архитектор проекта отвечает за эволюцию и сопровождение архитектуры системы. Он не обязательно должен быть главным разработчиком, но обязан квалифицированно принимать стратегические решения, как правило, базируясь на имеющемся опыте построения подобных систем. Руководитель (администратор, менеджер) проекта несёт ответственность за эффективное использование ресурсов и достижение результатов и не может нести прямую ответственность, например, за использование предоставляемых проектом услуг. Но он может осуществлять в течение определённого периода мониторинг связанных с этим рисков и допущений. Архитекторы, хотя и должны уметь программировать, в первую очередь обязаны разбираться в принципах организации разработки АИС, а также весьма желательно чтобы они владели принципами менеджмента. Ответственные за подсистемы отвечают за проектирование конкретных модулей и подсистем. В сотрудничестве с архитектором проекта каждый из ответственных разрабатывает, обосновывает и согласовывает с другими разработчиками интерфейс своей подсистемы, а затем возглавляет её реализацию, тестирование и выпуск обновлений в течение развития системы. Они должны знать принятую систему обозначений и организацию процесса разработки АИС. Обычно они программируют лучше, чем архитекторы проекта, но не располагают столь обширным опытом. Ответственные за подсистемы составляют от трети до половины численности команды разработчиков. Прикладные программисты – это младшие по рангу участники проекта. В основном они занимаются реализацией и последующим тестированием выполненных ими элементов подсистем и модулей. Они могут участвовать и в проектировании некоторых подсистем. Прикладные программисты должны быть хорошими программистами. Количественно они составляют не менее половины команды. В больших проектах дополнительно в состав бригады могут входить и другие специалисты: менеджер проекта и интеграции, аналитик, инженер по повторному использованию, контролёр качества, ответственный за документацию, инструментальщик и др. Менеджер проекта отвечает за управление материалами проекта, заданиями, ресурсами и графиком работ. Аналитик отвечает за развитие и интерпретацию требований конечных пользователей. Он должен быть экспертом в предметной области, и его не следует изолировать от команды разработчиков. Инженер по повторному использованию управляет хранилищем материалов проекта; активно ищет общее и добивается его использования; находит, разрабатывает или приспосабливает компоненты для общего использования. Контролёр качества анализирует результаты процесса разработки; задаёт общее направление тестирования. Менеджер интеграции отвечает за сборку подсистем в единое приложение и следит за конфигурированием подсистем. Ответственный за документацию готовит для конечного пользователя документацию по выпускаемому продукту и его архитектуре. Инструментальщик отвечает за создание и адаптацию инструментов программирования, которые облегчают создание программ. Системный администратор управляет физическими компьютерными ресурсами в проекте. Не каждый проект требует использования всех названных ролей. В не-больших проектах обязанности могут совмещаться. При этом в очень больших проектах каждой из ролей может заниматься отдельная организация. Вопрос, который может возникнуть, как в самом начале проекта, так и на любой его фазе – осуществлять все работы своими силами или привлекать внешних консультантов? Привлечение консультантов (речь идёт о специалистах с соответствующей квалификацией и опытом работы) может увеличить первоначальные финансовые затраты на проект по выбору, но при этом значительно сокращается время на проведение работ и повышается качество их выполнения, а значит снижается риск их повторного выполнения, риск ошибок при принятии решений. Качество разработки АИС напрямую зависит как от производительности, так и от квалификации разработчиков. Проблемы повышения качества программирования активно обсуждаются с конца 1960-х г. Оно включает ряд компонент, среди которых, например, одной из важных является снижение затрат на сопровождение АИС. Существенный экономический эффект, высокое качество, сокращение сроков разработки АИС достигается применением интегрированного программно-математического обеспечения. Оно значительно упрощает процессы связывания и встраивания электронных документов, их передачи как внутри предприятия, так и другим информационным системам. Интегрированные программные системы максимально упрощают и эксплуатацию АИС, так как все задачи решаются с применением единообразного пользовательского интерфейса. Значительно ускорить составление программ и облегчить их отладку можно, используя ранее составленные библиотеки стандартных, типовых модулей, а также средства автоматического проектирования программных продуктов. В этом случае CASE-средства служат также мощным инструмен-том решения исследовательских и проектных задач, связанных с начальными этапами разработки. К таким задачам относят: анализ предметной области, разработку проектных спецификаций, выпуск проектной документации, пла-нирование и контроль разработок, моделирование деловых приложений, опе-ративного и стратегического планирования, управления ресурсами и т. п.
