Программная реализация системы управления работой метрологической службы
Жизненный цикл информационных систем. Обзор CALS-технологии, которая предполагает создание ЕИП предприятия, включающее в себя совокупность распределенных баз данных. Этапы создания программного обеспечения управления метрологической службой предприятия.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 08.07.2012 |
| Размер файла | 2,5 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
59
Размещено на http://www.allbest.ru/
программная реализация системы управления работой метрологической службы
Введение
В настоящее время на мировом рынке наукоемких промышленных изделий отчетливо наблюдаются три основные тенденции:
· Повышение требований к качеству продукции;
· Повышение конкуренции на рынке;
· Развитие кооперации между участниками жизненного цикла (ЖЦ) продукции (в т.ч., создание «виртуальных предприятий»).
Основной проблемой, стоящей сейчас перед отечественной промышленностью, является повышение конкурентоспособности выпускаемой продукции. Добиться этого возможно за счет:
· Повышения степени удовлетворения требований потребителя;
· Сокращения сроков выхода продукции на рынок;
· Сокращения материальных затрат на производство продукции.
Основным способом повышения конкурентоспособности изделия является повышение эффективности процессов его ЖЦ, т.е. повышение эффективности управления ресурсами, используемыми при выполнении этих процессов. В настоящее время существует большое количество методов повышения эффективности управления ресурсами разного типа: материальными, финансовыми, кадровыми или информационными.
Для успешной деятельности предприятия необходимо организовать производственный процесс таким образом, чтобы он был гибким и прозрачным. Ориентированность на потребителя (удовлетворение его потребностей) - один из главных постулатов каждого современного преуспевающего предприятия. В нынешнее время потребности заказчиков постоянно изменяются, требования к качеству продукции повышаются, расширяются рынки и т.д. Поэтому необходимо, чтобы предприятие реагировало на изменение спроса продукции, требований к ней на рынке своевременно и качественно. Это достигается за счет применения системы менеджмента качества и процессного подхода.
Также на предприятии необходима четкая организации выпуска продукции, четкое разграничение функций, обязанностей и ответственности, выделение в рамках предприятия процессов на различных уровнях производства и управления. Все это служит предпосылкой для эффективного контроля деятельности, организации информационных потоков и потоков работ внутри предприятия, наличия более точной информации о текущем состоянии и, следовательно, все это приведет к повышению качества решений, принимаемых руководителями.
Особое значение в такой ситуации имеет наличие программного обеспечения для персональных ЭВМ, как общего назначения, так и чисто прикладных программ, решающих специализированные задачи подразделения предприятия.
В данном проекте предлагается один из вариантов решения задачи конкретной программной реализации системы управления работой метрологической службы. Разрабатываемое программное средство предназначено в первую очередь для автоматизации работы специалистов метрологической службы. Использование данного программного обеспечения должно значительно упростить и ускорить их работу за счет автоматизации учетно-расчетных операций, формирования всей отчетности в процессе решения конкретных задач.
Раздел 1. Литературный обзор
1.1 Жизненный цикл информационных систем
Под жизненным циклом системы обычно понимается непрерывный процесс, который начинается с момента принятия решения о необходимости создания системы и заканчивается в момент ее полного изъятия из эксплуатации.
Современные сети разрабатываются на основе стандартов, что позволяет обеспечить, во-первых, их высокую эффективность и, во-вторых, возможность их взаимодействия между собой. Все стандарты на информационные системы (как и на любые системы вообще) можно разбить на следующие два основных класса:
· Функциональные стандарты, определяющие порядок функционирования системы в интересах достижения цели, поставленной перед нею ее создателями.
· Стандарты жизненного цикла, определяющие то, как создается, развертывается, применяется и ликвидируется система.
Модели, определяемые стандартами этих двух классов взаимосвязаны, однако решают совершенно разные задачи и характеризуются принципиально различными подходами к их построению. Таким образом, жизненный цикл информационной системы охватывает все стадии и этапы ее создания, сопровождения и развития:
· предпроектный анализ (включая формирование функциональной и информационной моделей объекта, для которого предназначена информационная система);
· проектирование системы (включая разработку технического задания, эскизного и технического проектов);
· разработку системы (в том числе программирование и тестирование прикладных программ на основании проектных спецификаций подсистем, выделенных на стадии проектирования);
· интеграцию и сборку системы, проведение ее испытаний;
· эксплуатацию системы и ее сопровождение;
· развитие системы.
1.2 CALS
Аббревиатура CALS расшифровывается как Continuous Acquisition and Life cycle Support - непрерывная информационная поддержка жизненного цикла продукта. Встречается также другой перевод, менее схожий с исходным названием, но более близкий по смыслу: обеспечение неразрывной связи между производством и прочими этапами жизненного цикла изделия. Данная технология, разработанная в 80-х годах в Министерстве обороны США, распространилась по всему миру и охватила практически все сферы мировой экономики. Она предназначена для повышения эффективности и качества бизнес-процессов, выполняемых на протяжении всего жизненного цикла продукта, за счет применения безбумажных технологий. Началом создания системы CALS-технологий явилась разработка системы стандартов описания процессов на всех этапах жизненного цикла продукции.
В международных стандартах серии ISO 9004 (управление качеством продукции) введено понятие "жизненный цикл изделия". Данное понятие включает в себя следующие этапы жизненного цикла изделия: маркетинг, поиск и изучение рынка; проектирование и/или разработка технических требований к создаваемой продукции; материально-техническое снабжение; подготовка и разработка технологических процессов; производство; контроль, проведение испытаний и обследований; упаковка и хранение; реализация и/или распределение продукции; монтаж, эксплуатация; техническая помощь в обслуживании; утилизация после завершения использования продукции.
1.3 Реинжиниринг бизнес-процессов и информационные технологии
Реинжиниринг бизнес-процессов с момента своего возникновения тесно взаимодействует с информационными технологиями, так как без реинжиниринга информационные технологии почти не приносят результатов, а без информационных технологий реинжиниринг почти невозможен. Проект реинжиниринга бизнес-процессов компании, как правило, реализуется в два этапа; на первом этапе осуществляется описание бизнес-процессов, их переосмысление и создание новых эффективных бизнес-процессов. На втором этапе к управлению новыми бизнес-процессами подключаются информационные технологии.
В последнее десятилетие самой важной технологией, связанной с реинжинирингом, стало планирование и управление ресурсами компании (ERP - Enterprise Ressource Planning) - интегрированная компьютерная система, поддерживающая не отдельные области деятельности, а целые бизнес-процессы.
Корпоративные системы планирования и управления ресурсами (ERP) - это стандартное программное обеспечение для реализации интегрированных организационно-экономических решений, как для основных, так и для вспомогательных процессов в организации.
Благодаря использованию единой базы данных, система способна интегрировать различные, но при этом тесно взаимосвязанные, функциональные области компании, например управление материальными потоками, планирование производства, бухгалтерский учет или управление персоналом. При этом конфигурация таких систем с учетом специфики конкретной организации осуществляется за счет встроенных механизмов.
ERP - системы способны учитывать потребности отдельных отраслей и специфичных для них процессов и функций. Кроме того, ERP - системы являются центральным элементом расширенных корпоративных систем для межфирменных и внешних процессов, таких как управление логистической цепочкой или управления связями с клиентами.
Бизнес-процесс -- это последовательность взаимосвязанных активностей или задач, которые приводят к созданию определенного продукта или услуги для потребителей. Часто бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов.
Существуют три вида бизнес-процессов:
Управляющие -- бизнес-процессы, которые управляют функционированием системы. Примером управляющего процесса может служить Корпоративное управление и Стратегический менеджмент.
Операционные -- бизнес-процессы, которые составляют основной бизнес компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение, Производство, Маркетинг и Продажи.
Поддерживающие -- бизнес-процессы, которые обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка, АХО.
Бизнес-процесс начинается со спроса потребителя и заканчивается его удовлетворением. Процессно-ориентированные организации стараются устранять барьеры и задержки, возникающие на стыке двух различных подразделений организации при выполнении одного бизнес-процесса.
Бизнес-процесс может быть декомпозирован на несколько подпроцессов, которые имеют собственные атрибуты, однако также направлены на достижение цели основного бизнес-процесса. Такой анализ бизнес-процессов обычно включает в себя составление карты бизнес-процесса и его подпроцессов, разнесенных между определенными уровнями активности.
Бизнес-процессы должны быть построены таким образом, чтобы создавать стоимость и ценность для потребителей и исключать любые необязательные или вовсе лишние активности. На выходе правильно построенных бизнес-процессов увеличиваются ценность для потребителя и рентабельность (меньшая себестоимость производства товара или услуги).
Бизнес-процессы могут подвергаться моделированию с помощью различных методов. Одним из способов есть составление модели бизнес-процесса «как есть» (англ. as is). После этого модель бизнес-процесса подвергается критическому анализу или обрабатывается специальным программным обеспечением. В результате строится модель бизнес-процесса «как должно быть» (англ. to be). Некоторые консультанты опускают фазу «как есть» и сразу предлагают модель «как должно быть».
PDM-система (англ. Product Data Management -- система управления данными об изделии) -- организационно-техническая система, обеспечивающая управление всей информацией об изделии. При этом в качестве изделий могут рассматриваться различные сложные технические объекты (корабли и автомобили, самолёты и ракеты, компьютерные сети и др.). PDM-системы являются неотъемлемой частью PLM-систем.
В PDM-системах обобщены такие технологии, как:
· управление инженерными данными (engineering data management -- EDM)
· управление документами
· управление информацией об изделии (product information management -- PIM)
· управление техническими данными (technical data management -- TDM)
· управление технической информацией (technical information management -- TIM)
· управление изображениями и манипулирование информацией, всесторонне определяющей конкретное изделие.
Базовые функциональные возможности PDM-систем охватывают следующие основные направления:
· управление хранением данных и документами
· управление потоками работ и процессами
· управление структурой продукта
· автоматизация генерации выборок и отчетов
· механизм авторизации
С помощью PDM-систем осуществляется отслеживание больших массивов данных и инженерно-технической информации, необходимых на этапах проектирования, производства или строительства, а также поддержка эксплуатации, сопровождения и утилизации технических изделий. Такие данные, относящиеся к одному изделию и организованные PDM-системой, называются цифровым макетом. PDM-системы интегрируют информацию любых форматов и типов, предоставляя её пользователям уже в структурированном виде (при этом структуризация привязана к особенностям современного промышленного производства). PDM-системы работают не только с текстовыми документами, но и с геометрическими моделями и данными, необходимыми для функционирования автоматических линий, станков с ЧПУ и др., причём доступ к таким данным осуществляется непосредственно из PDM-системы.
С помощью PDM-систем можно создавать отчеты о конфигурации выпускаемых систем, маршрутах прохождения изделий, частях или деталях, а также составлять списки материалов. Все эти документы при необходимости могут отображаться на экране монитора производственной или конструкторской системы из одной и той же БД. Одной из целей PDM-систем и является обеспечение возможности групповой работы над проектом, то есть, просмотра в реальном времени и совместного использования фрагментов общих информационных ресурсов предприятия.
Раздел 2. Характеристика отдела главного метролога, выделение процесса и его вербальное описание
2.1 Краткая характеристика предприятия ООО «ЛУКОЙЛ-ПНГП»
Официальной датой образования ООО «ЛУКОЙЛ-ПНГП» является 1998 год, однако фактическая история предприятия началась в 1969 году с момента пуска в эксплуатацию Пермского газоперерабатывающего завода.
26 ноября 1998 года было зарегистрировано Общество с ограниченной ответственностью «Пермнефтегазпереработка». Равные доли в уставном капитале нового предприятия принадлежали ЗАО «ЛУКОЙЛ-ПЕРМЬ» и ОАО «Пермский ГПЗ».
В 2000 году доля Пермского ГПЗ перешла к ОАО «ЛУКОЙЛ». Этот этап производственной жизни ООО «ЛУКОЙЛ-ПНГП» характеризуется тем, что была проведена значительная работа по приему в собственность объектов транспортировки попутного нефтяного и природного газа, принадлежащих ООО «ЛУКОЙЛ-Пермнефть», расположенных на юге и на севере Прикамья.
В июне 2001 года состоялся пуск в эксплуатацию нового газопровода длиной 12,6 км, построенного в рекордные сроки за счет собственных средств ООО «ЛУКОЙЛ-ПНГП». По трубопроводу один из видов продукции, отбензиненный газ, транспортируется непосредственно с завода потребителям в Перми. В результате строительства этого уникального для Пермской области газопровода продукция ООО «ЛУКОЙЛ-ПНГП» поступает на промышленные предприятия и ТЭЦ города. Поставка отбензиненного газа в областной центр обеспечила не только экономическую безопасность ряда местных производств, но и значительно удешевила себестоимость целого ряда производимых в Прикамье товаров и услуг.
В сентябре 2005 года ООО «ЛУКОЙЛ-ПНГП» завершило работу над внедрением значимого газового проекта - на основной производственной площадке введена в эксплуатацию установка утилизации кислых газов. Назначение установки - производство натрия гидросульфида технического, который применяется при обогащении и переработке руд цветных металлов, в производстве кальцинированной соды, полисульфидного каучука, красителей, пигментов, других неорганических и органических веществ, в кожевенной и текстильной промышленностях, в производстве сульфатной целлюлозы, при обезвреживании некоторых видов жидких отходов промышленных предприятий. При этом весь извлекаемый из углеводородного сырья кислый газ полностью утилизируется, что помимо экономической выгоды создает существенный экологический эффект, а именно: снижаются выбросы загрязняющих веществ в атмосферу более чем на 2,4 тыс. тонн в год.
В 2007 году на ООО «ЛУКОЙЛ-ПНГП» завершилось самое крупномасштабное строительство в истории предприятия.
30 октября в цехе приема сырья, хранения и отгрузки продукции была введена в эксплуатацию новая сливо-наливная эстакада сжиженных углеводородных газов (СУГ) и легковоспламеняющихся жидкостей (ЛВЖ).
По протяженности новая эстакада превосходит все подобные объекты в России. Длина эстакады составляет 440 метров, эстакада имеет 72 станции слива-налива продукции. По объему слива-налива сжиженных углеводородных газов и по номенклатуре наливаемой продукции - объект является одним из мощнейших в Европе. За основу определения количества фронтов налива и слива эстакады были взяты максимальные пропускные возможности путей приема и отгрузки сырья станции «Осенцы». Общая протяженность железнодорожных подъездных путей ООО «ЛУКОЙЛ-ПНГП» возросла в 2 раза и составила более 14 км.
информационная система программное обеспечение
2.1.1 Продукция, выпускаемая на ООО «ЛУКОЙЛ-ПНГП»
|
СПБТ |
ГОСТ 20448-90 |
|
|
ПБА |
ГОСТ 27578-87 |
|
|
Фракция пропановая |
ТУ 0272-023-00151638-99 |
|
|
Фракция изобутановая |
ТУ 0272-025-00151638-99 |
|
|
Фракция нормального бутана |
ТУ 0272-026-00151638-99 |
|
|
Углеводороды легкие |
ТУ 0272-05-50260226-2006 |
|
|
Фракция пентан-изопентановая |
ТУ 0272-030-00151638-99 |
|
|
Фракция гексан-гептановая, поставляемая на экспорт |
ТУ 38.1011359-91 |
|
|
Бензин газовый стабильный |
ТУ 0272-020-00148300-06 |
|
|
Бензин газовый стабильный (БГС-3) |
ТУ 0272-03-50260226-2003 |
|
|
Газ отбензиненный для промышленного и коммунально-бытового назначения |
ТУ 0272-02-50260226-2001 |
|
|
Натрий гидросульфид технический |
ТУ 2153-063-00151638-2005 |
|
|
Фракция этановая |
ТУ 0272-07-50260226-2009 |
2.2 Характеристика отдела главного метролога
Метрологическая служба создана для выполнения работ по обеспечению единства измерений, соблюдению метрологических правил и норм в ООО «ЛУКОЙЛ-ПНГП» (далее - Общество) в соответствии с требованиями законодательства Российской Федерации об обеспечении единства измерений и техническом регулировании, метрологическому надзору.
На основании процессного подхода основным бизнес-процессом отдела считается обеспечение единства измерений (рис.1). Входом данного процесса является Федеральный закон от 26 июня 2008 г. № 102-Ф3 «Об обеспечении единства измерений». Результат процесса представляет собой точность измерений на предприятии.
Рисунок 2.1 - основной бизнес-процесс ОГМетр.
2.2.1 Структура отдела главного метролога
Метрологическую службу возглавляет Главный метролог - начальник отдела главного метролога, назначаемый на должность и освобождаемый от должности приказом Генерального директора по согласованию с Главным метрологом ОАО «ЛУКОЙЛ».
Главный метролог подчиняется Первому заместителю генерального директора -Главному инженеру и несет ответственность за выполнение задач, возложенных на метрологическую службу.
Главный метролог осуществляет общее и методическое руководство работами по обеспечению единства измерений, метрологическому надзору и метрологическому обеспечению в Обществе.
В своей деятельности метрологическая служба ООО «ЛУКОЙЛ-ПНГП» руководствуется:
· законодательством Российской Федерации, в том числе Федеральным законом от 26 июня 2008 г. № 102-Ф3 «Об обеспечении единства измерений», Федеральным законом от 27 декабря 2002 г. № 184-Ф3 «О техническом регулировании» (с изменениями и дополнениями);
· стандартами, правилами по метрологии и другими нормативными документами Государственной системы обеспечения единства измерений Российской Федерации;
· документами Федерального агентства по техническому регулированию и метрологии Российской Федерации, Минэнерго России, Минпромторга России в области обеспечения единства измерений;
· стандартами, приказами, указаниями, нормативными и распорядительными актами ОАО «ЛУКОЙЛ», обязательными для исполнения газоперерабатывающими обществами Компании;
· Положением о метрологической службе ОАО «ЛУКОЙЛ»;
· Уставом Общества, решениями органов управления Общества, касающимися деятельности службы;
· приказами, другими обязательными для исполнения нормативно-правовыми актами Общества;
· стратегией развития Общества и функциональной стратегией по направлению деятельности;
· политикой ООО «ЛУКОЙЛ-ПНГП» в области промышленной безопасности, охраны труда, окружающей среды в соответствии с требованиями стандартов ISO 14001 и OHSAS 18001;
· действующим Положением об интегрированной системе управления промышленной безопасностью, охраной труда и окружающей средой в ООО «ЛУКОЙЛ - ПНГП»;
· правилами корпоративной культуры организаций Группы «ЛУКОЙЛ»;
· Кодексом деловой этики организаций Группы «ЛУКОЙЛ»;
· настоящим Положением.
На рисунке 2.2.1 представлена схема организационной структуры отдела
Рисунок 2.2. - Схема организационной структуры ОГМетр
2.2.2 Основные функции сотрудников ОГМетр
Главный метролог - начальник отдела.
Функции, выполняемые начальником отдела, включают процессы планирования и организации работ в отделе. Подробное рассмотрение этих функций не имеет практического смысла в данной ВКР, так как они не связаны с непосредственным созданием графиков поверки, калибровки и технического обслуживания.
Начальник лаборатории метрологии
· Вести учёт по оборудованию узлов учёта, а также учёт проведённого технического обслуживания и ремонтов, поверок и калибровок оборудования узлов учёта, работ по метрологическому обеспечению производства на базе «Автоматизированной системы управления метрологической службой («АСУ МС»)»;
· Обеспечить подготовку, согласование, заключение, ведение и исполнение договоров на поверку, калибровку средств измерений в соответствии с Договорным регламентом;
· Обеспечивать формирование, ведение и выполнение, бюджета на поверку, калибровку средств измерений в соответствии с Бюджетным регламентом Общества;
· Обеспечивать проведение проверок полноты и качества проведения работ подрядными организациями по поверке, калибровке средств измерений, метрологическому обеспечению производства, ремонту и обслуживанию кондиционеров;
· Обеспечивать подготовку, согласование, выполнение планов - графиков производства работ по поверке, калибровке средств измерений, метрологическому обеспечению производства на период проведения остановочного ремонта;
· Обеспечивать бесперебойную и безаварийную эксплуатацию и работу средств измерений;
· Контролировать правильную эксплуатацию средств измерений работниками Общества и подрядных организаций;
· Контролировать полноту и качество ведения учёта средств измерений в подразделениях ООО «ЛУКОЙЛ-ПНГП» ответственными за метрологическое обеспечение;
Инженер по метрологии II категории
· Вести учёт средств измерений, а также учёт проведённых поверок и калибровок средств измерений на базе «Автоматизированной системы управления метрологической службой («АСУ МС»)»;
· Готовить, обеспечивать согласование, заключение, ведение и исполнение договоров на поверку, калибровку средств измерений в соответствии с Договорным регламентом;
· Обеспечивать выполнение в установленные договором сроки, в установленных объёмах поверку, калибровку средств измерений;
· Разрабатывать, обеспечивать согласование, утверждение и выполнение графиков поверки, калибровки средств измерений;
Инженер
· Обеспечить подготовку, согласование, заключение, ведение и исполнение договоров на техническое обслуживание, текущий и капитальный ремонты КИПиА, АСУ ТП в соответствии с Договорным регламентом
· Вести учёт КИПиА, АСУ ТП, а также учёт проведённого технического обслуживания и ремонтов КИПиА, АСУ ТП на базе «Автоматизированной системы управления метрологической службой («АСУ МС»)»;
· Обеспечивать выполнение в установленные договором сроки, в установленных объёмах технического обслуживания, текущего и капитального ремонта КИПиА, АСУ ТП;
· Проверять полноту и качество проведения технического обслуживания, выполнения текущего и капитального ремонта КИПиА, АСУ ТП;
Таким образом, обеспечение точности измерения является основной функцией отдела. Остальные выполняемые работы направлены на повышение эффективности деятельности отдела.
Рассмотрение выполняемых сотрудниками ОГМетр функций позволяет сформировать общую картину метрологического обеспечения предприятия. Однако, для выявления слабых сторон и поиска возможных вариантов развития необходим тщательный анализ деятельности отдела с применением процессного и системных подходов.
2.3 Вербальное описание основной бизнес-функции ОГМетр
Для того чтобы получить полное представление об отделе главного метролога как о функционально выделенной единице в структуре предприятия, ООО «ЛУКОЙЛ-ПНГП», необходимо представить детальное описание процессов, происходящих внутри отдела.
Это можно сделать двумя способами:
· Вербальное описание бизнес-процессов (в виде структурированного текста)
· Графическое представление с использованием стандартизированных методологий (IDEF0 - диаграммы)
Основная бизнес-функция ОГМетр - обеспечение единства измерений. Результат этого процесса - точность измерений. Вербально процесс может быть представлен как структурированный текст.
Для обеспечения точности измерений необходимо следить за состоянием СИ, КИПиА и АСУ ТП. Для этого требуется составление графиков поверки, калибровки, технического обслуживания и ремонтов.
Регламентирующая документация хранится в следующем виде (см. табл.3):
Таблица 2.1 -.Способ хранения документации.
|
Наименование блока |
Наименование документа |
|
|
Блок Стандартов |
ГОСТы |
|
|
Федеральные законы |
||
|
Стандарты, правила по метрологии и другие нормативные документы Государственной системы обеспечения единства измерений Российской Федерации |
||
|
Документы Федерального агентства по техническому регулированию и метрологии Российской Федерации, Минэнерго России, Минпромторга России в области обеспечения единства измерений |
||
|
Документы по ИСУ ПБ, ОТ и ОС |
||
|
Административный блок |
Положения и должностные инструкции отдела главного метролога |
|
|
Блок рабочих документов |
Графики поверки, калибровки, технического обслуживания и ремонтов |
|
|
Акты метрологического надзора |
||
|
Свидетельства о поверке |
||
|
Методики поверки, калибровки |
||
|
Паспорта на СИ |
||
|
Приказы и распоряжения по ООО «ЛУКОЙЛ-ПНГП» |
||
|
Переписка ОГМетр (входящая, исходящая) |
||
|
Договоры |
||
|
Технологический блок |
Технологические регламенты |
|
|
Проекты |
Вербальное описание представлено в разделе технико-экономического обоснования. Оно имеет ряд очевидных недостатков перед использованием графического представления (за исключением отсутствия необходимости знать принципы построения графических диаграмм), а именно:
владельцев подзадач и инструментов их решения.
На основе информации, получаемой из текстовых источников (регламенты, стандарты, положения), строятся более информативные графические модели этих процессов. Поэтому изначально охарактеризуем процессы вербально.
Раздел 3. Идентификация основного бизнес-процесса ОГМетр моделями структурного анализа
Основным бизнес-процессом проектно-конструкторского отдела является составление графиков поверки, калибровки и технического обслуживания предприятия ООО «ЛУКОЙЛ-ПНГП». Исходными данными для его начала принимается предыдущие графики поверки, калибровки и технического обслуживания, результатом считается новые графики поверки, калибровки и технического обслуживания.
В предыдущем разделе было рассмотрено вербальное описание этого процесса, имеющее ряд недостатков в сравнении с графическим представлением. Ниже приведен анализ проектного обеспечения предприятия с использованием визуальной методологии представления моделей - BPWin.
3.1 Краткое описание методологии BPWin
BPWin - средство описания, анализа и моделирования бизнес-процессов без применения специальных инструментов. Для решения этих задач, создана программа BPWin, которая включает следующие методологии: IDEF0, DFD и IDEF3.
Таблица 3.1- Возможности и инструментальная среда BPWin
|
№ |
Возможности/ Инструментальная среда |
BPWin |
|
|
1 |
Поддерживаемый стандарт |
IDEF0, IDEF3, DFD |
|
|
2 |
Система хранения данных |
Модели хранятся в файлах |
|
|
3 |
Ограничение на размер базы данных |
Нет. Размер БД ограничивается вычислительными ресурсами |
|
|
4 |
Возможность групповой работы |
Есть. Используется Model Mart. |
|
|
5 |
Ограничение на количество объектов на диаграмме |
От 2 до 8. |
|
|
6 |
Возможность декомпозиции |
Неограниченная декомпозиция. Возможен однократный переход на другую нотацию в процессе декомпозиции. |
|
|
7 |
Формат представления моделей |
Стандартный бланк IDEF с возможностью его отключения |
|
|
8 |
Удобство работы по созданию моделей |
Простая панель управления, нет выравнивания объектов |
|
|
9 |
UDP - свойства объектов, определяемые пользователем |
Количество UDP не ограничено. Количество типов ограничено. |
|
|
10 |
Возможность анализа стоимости процессов |
Упрощенный анализ стоимости по частоте использования в процессе. Возможность экспорта в EasyABC. |
|
|
11 |
Генерация отчетов |
RPT Win с возможностью визуальной настройки отчетов. Включая расчет по формулам с использованием UDP. |
|
|
12 |
Сложность разработки нестандартных отчетов |
Просто |
При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer.
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из репозитория Model Mart, внести имя модели и выбрать методологию, в которой будет построена модель.
Как было указано выше, BPwin поддерживает три методологии - IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи.
В BPwin возможно построение смешанных моделей, т.е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
Рисунок 3.1 - Диалог создания модели
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
Методология IDEF0
В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, обмениваясь информационными и материальными потоками с помощью людских и производственных ресурсов, потребляемых каждой работой. С помощью функционального моделирования можно провести системный анализ бизнеса, сосредоточившись на регулярно решаемых задачах или функциях, на показателях их правильного выполнения, необходимых для этого ресурсах, результатах и исходных материалах.
BPWin автоматически синхронизирует изменения объектов диаграмм на всех уровнях детализации, тем самым, освобождая пользователя от ручного ведения словаря объектов модели. Так если мы исправим на верхнем уровне название объекта, то получим изменение на всех уровнях, где данный объект встречается. Также невозможным является случайное дублирование наименований работ. При появлении такой ситуации BPWin генерирует предупреждающее сообщение.
Методология DFD
Диаграммы DFD могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией как внутри системы между бизнес-функциями, так и системы в целом с внешней информационной средой.
Для усиления функциональности в данной нотации диаграмм предусмотрены специфические элементы, предназначенные для описания информационных и документопотоков, такие как внешние сущности и хранилища данных.
Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы -- движение объектов, хранение объектов, поставка и распространение объектов.
Методология IDEF3
Третий информационный разрез -- последовательность выполняемых работ. В отличие от диаграмм IDEF0 и DFD, элементы которых позволяют точно описать функциональность системы и организацию документооборота, описать с их помощью логику построения системы не удастся. Для описания логики взаимодействия информационных потоков, последовательности выполнения работ и сценариев взаимодействия модель дополняют диаграммами еще одной методологии -- IDEF3, также называемой диаграммами workflow.
В IDEF3 включены элементы логики, что позволяет аналитику моделировать и анализировать альтернативные сценарии развития бизнес-процесса. Методология моделирования IDEF3 позволяет графически описать и документировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.
IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать «сеть переходных состояний объекта», предлагая вниманию аналитика, последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.
С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни. Каждый такой сценарий содержит в себе описание процесса и может быть использован, чтобы наглядно показать или лучше документировать бизнес-функции организации.
Перечисленные информационные разрезы по-своему уникальны. Каждый из них может быть выполнен отдельно с помощью BPWin, но их совокупность, заключенная в модель, дает аналитику полную картину предметной области клиента.
3.2 Процесс создания графиков поверки, калибровки, технического обслуживания с использованием IDEF0, IDEF3 - диаграмм
Для наглядного представления процесса создания графиков поверки, калибровки, технического обслуживания, разработана модель бизнес-процесса в среде BPWin. Вид общей модели процессов представлен на рисунках. С помощью IDЕF3 диаграмм представлены основные этапы и стадии процесса создании графиков.
Рисунок 3.2. - IDEF0 диаграмма процесса создания графика поверки
На рис.2 видно, что для процесса разработки и составления графика поверки входящими документами являются предыдущие графики поверки и договор с поверочной организацией, а исходящим документом новый график поверки. Так же видно, что процесс регламентируется законом об обеспечении единства измерений, перечнем СИ, техническими характеристиками СИ, паспортами на СИ, инструкцией по эксплуатации СИ и методикой поверки СИ. Необходимые ресурсы для выполнения процесса это транспорт, интернет, специалисты и оборудование. Для того чтобы увидеть в какой последовательности выполняются процедуры разработки и составления графиков поверки этот блок декомпозируют.
Рисунок 3.3. - Основные стадии создания графика поверки в IDEF0 диаграмме
На рис.3 представлена последовательность выполнения процедур процесса. После составления графика поверки, он отправляется на согласование в поверочную организацию. Следующей стадией является доставка средств измерений в лаборатории для прохождения поверки, по результатам которой вносятся изменения в график.
Рисунок 3.4 - Декомпозиция второй стадии с помощью IDEF3 диаграммы.
Рисунок 3.5 - Декомпозиция третей стадии с помощью IDEF3 диаграммы
Рисунок.3.6 - IDEF0 диаграмма процесса создания графика калибровки
На рис.6 видно, что для процесса разработки и составления графика калибровки входящими документами являются предыдущие графики калибровки и договор с сервисной организацией, а исходящим документом новый график калибровки. Так же видно, что процесс регламентируется законом об обеспечении единства измерений, перечнем СИ, техническими характеристиками СИ, паспортами на СИ, инструкцией по эксплуатации СИ и методикой поверки СИ. Необходимые ресурсы для выполнения процесса это транспорт, интернет, специалисты и оборудование. Для того чтобы увидеть в какой последовательности выполняются процедуры разработки и составления графиков калибровки этот блок декомпозируют.
Рисунок 3.7 - Основные стадии создания графика калибровки в IDEF0 диаграмме
На рис.7 представлена последовательность выполнения процедур процесса. После составления графика калибровки, он отправляется на согласование в сервисную организацию. Следующей стадией является доставка средств измерений в лаборатории для прохождения калибровки, по результатам которой вносятся изменения в график.
Рисунок 3.8 - Декомпозиция второй стадии с помощью IDEF3 диаграммы.
Рисунок 3.9 - Декомпозиция третей стадии с помощью IDEF3 диаграммы.
Рисунок 3.10 - IDEF0 диаграмма процесса создания графика ТО
На рис.10 видно, что для процесса разработки и составления графика ТО входящими документами являются перечень имеющихся СИ, информация по новым СИ и договор с сервисной организацией, а исходящим документом новый график ТО. Так же видно, что процесс регламентируется законом об обеспечении единства измерений, техническими характеристиками СИ, паспортами на СИ, инструкцией по эксплуатации СИ. Необходимые ресурсы для выполнения процесса это интернет, специалисты и оборудование. Для того чтобы увидеть в какой последовательности выполняются процедуры разработки и составления графиков ТО этот блок декомпозируют.
Рисунок 3.11 - Основные стадии создания графика ТО в IDEF0 диаграмме
На рис.10 представлена последовательность выполнения процедур процесса. После закупки новых СИ, информация о них отправляется в ОГМетр. Следующей стадией является составление полного перечня СИ в который, затем, вносятся виды ТО по новым СИ.
Рисунок 3.12 - IDEF0 диаграмма процесса создания графика ремонтов
На рис.12 видно, что для процесса разработки и составления графика ремонтов входящим документом является сводный график ремонтов. Необходимые ресурсы для выполнения процесса это специалисты и оборудование. Для того чтобы увидеть в какой последовательности выполняются процедуры разработки и составления графиков ремонтов этот блок декомпозируют.
Рисунок 3.13 - Основные стадии создания графика ремонтов в IDEF0 диаграмме
На рис.13 представлена последовательность выполнения процедур процесса. На основе сводного графика составляется дефектная ведомость. Следующей стадией является составление графика ремонтов.
Раздел 4. Технико-экономическое обоснование необходимости внедрения интегрированной системы управления
В соответствии с заданием, объектом исследования выберем процесс составления графиков поверки, калибровки, ТО и ремонтов.
4.1 Исходное состояние
Рассмотрим существующую поддержку информационных процессов ОГМетр.
Обеспечение единства измерений является первостепенной задачей ОГМетр. В результате выполнения этой задачи СИ имеющиеся на предприятии должны соответствовать утвержденным техническим характеристикам. Одной из функций метрологической службы в процессе выполнения основной задачи является поверка, калибровка, ТО и ремонт СИ и КИП. Выполнение этих видов работ требует составление соответствующих графиков.
Графики поверки, калибровки, ТО и ремонтов составляются инженером по метрологии. В качестве исходной информации для их составления используется:
· Перечень СИ;
· Нормативная документация;
· Межповерочные, межкалибровочные интервалы;
· Периодичность ТО, ремонтов;
· Договора на выполнение работ.
· Дефектные ведомости
Порядок составления графиков на предприятии.
График поверки (калибровки) составляется в электронном виде, распечатывается в 2-х копиях в бумажном виде и подписывается начальником лаборатории метрологии. На бумажном носителе направляется на утверждение главному инженеру. Утвержденный график направляют в поверочную (сервисную) организацию, где подписывается руководителем. Один экземпляр организация возвращает в отдел главного метролога, а другой оставляет себе.
В ОГМетр графики хранятся в бумажном виде в папке под названием «Графики поверки, калибровки», ранее составленный электронный вариант разбивается по месяцам, и рассылается по установкам предприятия.
По итогам поверки выдаются в бумажном виде свидетельства о поверке или извещения о непригодности, которые хранятся в ОГМетр, в папке «Свидетельства о поверке».
По итогам калибровки в паспорте на СИ ставится клеймо о пригодности или выдается извещение о непригодности. Паспорта и извещения в бумажном виде хранятся в папках, каждая папка создается по месту фактической установки прибора, например «Паспорта СИ Цех №1 К-120».
Графики ТО, ремонтов составляются в электронном виде, распечатываются в 2-х копиях в бумажном виде и согласовываются главным метрологом. На бумажном носителе направляется на утверждение главному инженеру. Утвержденный график направляют в сервисную организацию, где подписывается руководителем. Один экземпляр организация возвращает в отдел главного метролога, а другой оставляет себе.
В ОГМетр графики ТО, ремонтов хранятся в бумажном виде в папках под названием «Графики ТО», «Графики ремонтов, дефектные ведомости».
На всех участников данного процесса имеются должностные и рабочие инструкции, которые хранятся на бумажных носителях в отделе.
Формулирование проблемы
В результате анализа информационной поддержки деятельности отдела главного метролога выявлены следующие недостатки:
1. Документация участвует в процессах отдела в основном на бумажных носителях. А в отделе все документы формируются в электронном виде. Хранится документация также в бумажном виде.
Хранение документации на бумажных носителях ведет к тому, что:
· участники процесса затрачивают длительное время на поиск документации, что может повлиять на скорость принятия решений и утомляемость участников процесса;
· документ может просматриваться только одним участником процесса;
· затрачивается время на копирование подлинников документации;
· увеличивается расход бумаги;
2. Передача документов осуществляется на бумажных носителях, что ведет к тому что:
ь Графики поверки, калибровки, ТО и ремонтов утверждаются длительное время, т.к. необходимо согласование с другими отделами, организациями, из-за этого возможна задержка поступления графиков в производство.
ь Передача паспортов на СИ, свидетельств о поверке и извещений о непригодности осуществляется на бумажном носителе, что ведет к задержке времени на использование документа;
Вследствие перечисленных недостатков исполнители и пользователи документов нерационально используют свое рабочее время.
Так как описанная ситуация, сложившаяся в отделе главного метролога, характерна и для других отделов и служб, то считаем, что на предприятии существует проблема совершенствования поддержки информационных процессов.
Таблица 4.1
|
Анализ проблем |
Как должно быть |
|
|
Процесс взаимодействия зачастую основывается на передаче адресату какого либо бумажного документа, что влечет за собой определенные последствия: затраты времени на оформление, регистрацию, передачу документа, на доведение этого документа до адресата. |
Взаимодействие подразделений, руководства, подразделений и руководства должно осуществляться посредством электронного документооборота; фиксирование результатов и их рассылка так же только в электронном виде. В результате - сокращение времени на доведение нужной информации от исполнителей до руководителей и обратно. |
|
|
Невозможно просмотреть ход работы, объективно оценить объем выполненных работ и процент занятости каждого из исполнителей, что может привести к неэффективному управлению человеческими ресурсами отдела. |
Информация для расчета должна поступать сразу же в ИИС. ИИС должна свободна совмещаться с расчетными программными средствами. Тем самым процесс передачи от одного лица к другому значительно сократится и ускорится работа по осуществлению нужного процесса. |
|
|
Постановка задачи не всегда конкретна, она выражена общими фразами и часто не понятно, что именно нужно сделать. Проблемой является и то, что бывают случаи, когда начальник отдела не понимает сути задачи, которую он ставит перед исполнителем. Из-за этого происходит неправильная оценка времени выполнения данной задачи и/или даже неправильный выбор исполнителя работ, что приводит к неэффективной работе цеха и некорректному выполнению задания. |
Анализ поставленной задачи должен происходить на уровне восприятия и понимания полученного задания. Следовательно, произойдет сведение к минимуму времени взаимодействия с начальником отдела и представителями производства-заказчика работ по поводу конкретного содержания работ. Этого можно достичь путем принятия служебных записок с производств, а так же другой документации с корректной детализированной постановкой задачи. |
Формулирование цели
Решение проблемы совершенствования поддержки информационных процессов ОГМетр возможно за счет создания ЕИП на базе ИИС.
Поэтому за цель совершенствования поддержки управления информационных процессов принимается создание ЕИП.
Внедрение ИИС обеспечит:
· создание единой информационной среды для эффективного взаимодействия сотрудников отдела;
· хранение, учет и оперативный поиск электронных подлинников документов;
· оперативное формирование отчетов;
· защита документов от несанкционированного доступа;
· назначение маршрута согласования и утверждения таких документов, как графики поверки, калибровки, ТО и ремонтов, контроль за сроками их исполнения;
· уменьшение площадей, используемых для хранения бумажных документов.
· разграничение доступа к документам;
Раздел 5. Разработка концепции построения ИИС, выбор системы
В данном разделе будет рассматриваться основные виды обеспечение, предъявляемые к ИИС, а также требования к ним. ИИС разрабатывается для отдела главного метролога ООО «ЛУКОЙЛ-ПНГП».
5.1 Виды обеспечения АС
Совокупность видов обеспечения составляет комплекс средств автоматизации некоторой деятельности. Ни один из видов обеспечения не может быть опущен.
Различают следующие виды обеспечения АС:
o лингвистическое;
o информационное;
o программное;
o техническое;
o организационное.
5.1.1 Требования к видам обеспечения
Требования к видам обеспечения разделены следующие подгруппы:
· требования к информационному и лингвистическому обеспечению системы
· требования к программному обеспечению
· требования к техническому обеспечению
· требования к организационному обеспечению
5.1.2 Информационное и лингвистическое обеспечение
5.1.2.1 Требования к информационному и лингвистическому обеспечению
Ш Уровень хранения данных в системе должен быть построен на основе современных реляционных или объектно-реляционных СУБД.
Ш Для обеспечения целостности данных должен использоваться механизм СУБД - MS SQL Server Management Studio.
Ш Средства СУБД, а также средства используемых операционных систем должны обеспечивать документирование и протоколирование обрабатываемой в системе информации.
Ш Доступ к данным должен быть предоставлен только авторизованным пользователям с учетом их служебных полномочий, а также с учетом категории запрашиваемой информации.
Ш В состав системы должна входить специализированная подсистема резервного копирования и восстановления данных.
Ш Доступ со стороны пользователей АСУП должен происходить в одностороннем порядке без возможности редактирования проектов (за исключением руководителей для утверждения или согласования документа).
Ш Все прикладное программное обеспечение системы для организации взаимодействия с пользователем должно использовать русский язык.
Ш Программный код интерфейса пользователя и модуля интеграции могут быть написаны на любом объектно-ориентированном языке программирования (например Delphi).
5.1.2.3 Информационное обеспечение
В отделе главного метролога за время работы по обеспечению единства измерений предприятия обращается огромное количество документов, как в бумажном виде, так и в персональных компьютерах пользователей. Вследствие большого объема ценной информации, очень многие документы отправляются в архив.
Таким образом, для сохранения важной информации необходимо создавать систематизированные электронные данные об этих документах - базы данных.
База данных - это совокупность сведений о реальных объектах, процессах, событиях или явлениях, относящихся к определённой теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности, как в целом, так и любой её части.
База данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определённого типа. Каждая строка таблицы содержит данные об одном объекте (например: средстве измерения), а столбцы таблицы содержат различные характеристики этих объектов - атрибуты (например: дата, вид обеспечения и т.д.). Строки таблицы называются записями, все записи имеют одинаковую структуру - они состоят из полей, в которых хранятся атрибуты объекта. Каждое поле в записи содержит одну характеристику объекта и имеет строго определённый тип данных (например, текстовая строка, число, дата). Все записи имеют одни и те же поля, только в них содержатся разные значения атрибутов.
Цель создание БД в ОГМетр:
· создать систему автоматизации метрологического учета
Определение критериев разработки:
· БД должна работать в существующей компьютерной сети
· БД должна предоставлять пользователю конкретную достоверную информацию
Основные направления разработки:
· БД должна быть разработана с учетом функций и задач, выполняемых ОГМетр
Определение масштаба и границ БД:
· БД должна охватывать все процессы, которыми занимаются сотрудники ОГМетр
Описание информационного обеспечения находится в Приложении .
5.1.2.4 Лингвистическое обеспечение
Рассмотрим самый распространенный язык, с помощью которого происходят практически все операции с БД.
SQL (англ. Structured Query Language -- язык структурированных запросов) -- универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. Вопреки существующим заблуждениям, SQL является информационно-логическим языком, а не языком программирования.
Возможности SQL не ограничиваются выборкой данных из базы. В SQL поддерживаются разнообразные возможности для взаимодействия с базой данных, в том числе:
· определение структуры данных -- определение конструкций, используемых при хранении данных;
· выборка данных -- загрузка данных из базы и их представление в формате, удобном для вывода;
· обработка данных -- вставка, обновление и удаление информации;
· контроль доступа -- возможность разрешения/запрета выборки, вставки, обновления и удаления данных на уровне отдельных пользователей;
· контроль целостности данных -- сохранение структуры данных при возникновении таких проблем, как параллельные обновления или системные сбои.
Основные преимущества MS SQL Server:
1. Широкая поддержка языка XML и стандартов Интернета.
· удобное хранение и извлечение данных в формате XML при помощи встроенных хранимых процедур.
· удобный доступ к базе данных SQL Server непосредственно через web по протоколу HTTP.
· быстродействующий встроенный полнотекстовый поиск в текстовых данных, хранящихся в БД и в документах.
2. Эффективные средства анализа данных на базе web.
· выявление взаимосвязей и закономерностей в web-данных при помощи новых средств "информационной проходки".
· связывание и анализ сложно организованных данных через web, предоставление партнерам и сотрудникам, работающим в режиме удаленного доступа, всех возможностей анализа данных.
3. Платформа для безопасного размещения приложений.
Подобные документы
Специфика Клачеевского линейного производственного управления магистральными газопроводами. Разработка информационной системы метрологической службы. Процесс создания графиков калибровки и технического обслуживания с использованием IDEF0, IDEF3–диаграмм.
дипломная работа [1,6 M], добавлен 19.05.2017Обзор программных средств для создания информационных систем. Анализ деятельности предприятия и задач, подлежащих автоматизации. Проектирование содержания и структуры веб-сайта, его программная реализация. Обеспечение безопасности при передаче данных.
дипломная работа [3,1 M], добавлен 21.01.2012Анализ видов обеспечения автоматизированных систем предприятия. Средства программирования распределенных систем обработки информации. Изучение особенностей использования технологии распределенных объектов. Эксплуатация программного обеспечения системы.
отчет по практике [486,0 K], добавлен 23.11.2014Виды архитектуры распределенных информационных систем. Сущность синхронного и асинхронного, блокирующего и неблокирующего взаимодействия в распределенных информационных системах. Основные проблемы и принципы реализации удаленного вызова процедур.
реферат [26,4 K], добавлен 22.06.2011Агентно-ориентированная программная архитектура систем обработки потоковых данных. Обеспечение гибкости и живучести программного обеспечения распределенных информационно-управляющих систем. Спецификации программных комплексов распределенной обработки.
реферат [1,1 M], добавлен 28.11.2015Жизненный цикл программного обеспечения - непрерывный процесс, который начинается с принятия решения о необходимости создания ПО и заканчивается при полном изъятия его из эксплуатации. Подход к определению жизненного цикла ПО Райли, по Леману и по Боэму.
реферат [39,1 K], добавлен 11.01.2009Обзор принципов построения информационных систем для торговли через Интернет. Технология создания электронных магазинов. План работ для web-проекта. Язык сценариев JavaScript. Моделирование предметной области. Дизайн интерфейса и программная реализация.
дипломная работа [2,5 M], добавлен 10.04.2013Структура, классификация и этапы проектирования баз данных. Системы управления базами данных, их жизненный цикл. Разработка и реализация базы данных в MS Access. Организация входных и выходных данных. Защита данных от внешних угроз. Сведение о программе.
курсовая работа [558,6 K], добавлен 21.06.2012Реляционная база данных как совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Описание программного продукта: входная и выходная информация, выбор и обоснование программного обеспечения, содержание проектных решений.
контрольная работа [2,9 M], добавлен 17.08.2013Основные международные стандарты в области информационных технологий. Международный стандарт ISO/IEC 9126. Качество и жизненный цикл. Характеристика внутренних и внешних атрибутов качества. Анализ функциональных возможностей программного обеспечения.
доклад [94,4 K], добавлен 13.06.2017
