Материал: DO178 Учебное пособие_в183
Как следствие организация получает преимущество в производительности через улучшенные способности организации, подгонку улучшенных деятельностей на всех уровнях к стратегическому направлению организации и гибкость для быстрого реагирования на возможности.
7. Фактологический подход к принятию решений. Результативные решения основываются на анализе данных и информации. Типичными деятельностями являются:
обеспечение точности и надежности данных и информации;
предоставление доступа к данным тем, кому это надо;
анализ данных и информации правильными методами;
принятие решений и выполнение действий на основе анализа фактов с учетом опыта и интуиции.
Полезными следствиями применения этого принципа являются принятие решений на основе информации, возросшая способность демонстрировать результативность прежних решений через обращение к записям фактов и возросшая способность обсуждать, оспаривать и менять мнения и решения.
8. Взаимовыгодные отношения с поставщиками. Организация и ее поставщики зависят друг от друга, их взаимовыгодные отношения улучшают способности их обоих к созданию ценности. Типичными деятельностями в этом направлении являются:
установление отношений, сводящих вместе краткосрочные выгоды и долгосрочные рассмотрения;
разделение экспертизы и ресурсов с партнерами;
выявление и выбор ключевых поставщиков;
ясное и открытое взаимодействие;
обмен информацией и планами на будущее;
совместные деятельности по разработкам и улучшениям;
предложение, поощрение и признание улучшений и достижений у поставщиков.
Как результат в организации растет способность создавать ценность для обеих сторон, проявляется гибкость и быстрота совместных ответов на меняющийся рынок и потребности и ожидания заказчика и происходит реальная оптимизация затрат и ресурсов.
Модели iso 9000 на базе процессов
Общая структура стандартов качества семейства ISO 9000 строится на базе понятия процесса. Различают базовые, вспомогательные, внешние, внутренние и другие типы производственных процессов, так или иначе влияющих на качество создаваемого продукта или оказываемой услуги. Общая схема процессов в модели ISO 9000 приведена на Рис. 38.
Рис. 38. Модели ISO 9001 и 9004 на базе процессов
Окружение, в котором работает организация, ее среду составляют различные «заинтересованные лица», из которых в модели отмечены заказчики данной организации. Все заинтересованные лица, в том числе и заказчики, имеют свои потребности и ожидания в отношении того уровня качества, с каким данная организация должна их удовлетворить, создавая свой продукт или оказывая определенные услуги. Результатом деятельности организации является та или иная степень удовлетворенности заинтересованных сторон, включая, прежде всего, заказчиков, которая и является целью для постоянного улучшения системы управления качеством, ведущего к устойчивому успеху организации. Основой для такого развития событий служат принципы управления качеством, заложенные в серии стандартов ISO 9000. На Рис. 38 отмечены те разделы стандартов ISO 9004 и 9001, которые напрямую касаются этих аспектов управления качеством. Таким образом, ключевыми элементами в стандарте ISO 9004 являются:
управление устойчивым успехом организации – Managing for the sustained success of an organization;
стратегия и политика – Strategy and policy;
управление ресурсами – Resource management;
управление процессами – Process management;
мониторинг, анализ измерений и обзоры – Monitoring, measurement analysis and review;
улучшение, инновации и научение – Improvement, innovation, and learning,
а в стандарте ISO 9001:
ответственность руководства – Management responsibility;
управление ресурсами – Resource management;
создание продукта – Product realization;
анализ измерений и совершенствование – Measurement analysis and improvement.
Самооценивание по ключевым элементам iso 9000
Система стандартов качества ISO 9000 предлагает 5-уровевую модель соответствия организации этим стандартам. В модели сформулирован ряд вопросов, и по объективным ответам на них определяется уровень соответствия данной организации стандартам качества. Вопросы сгруппированы по указанным выше 6 ключевым элементам управления качеством, положенным в основу этой системы стандартов, и приведены в Табл. 19.
Табл. 19. Вопросы для самооценивания по ключевым элементам ISO 9000
Ключевой элемент и вопрос |
Уровень 1 |
Уровень 2 |
Уровень 3 |
Уровень 4 |
Уровень 5 |
Управление – Managing:
На чем фо-кусируется управле-ние? |
На продук-тах, акционе-рах и некото-рых заказчи-ках с ad hoc ответами на изменения, проблемы и возможности |
На заказчиках и требованиях с некоторой структурной реакцией на проблемы и возможности |
На людях и некото-рых других заинте-ресованных сторо-нах. Определены и реализованы процессы реагирования на проблемы и возможности |
На балансе потребностей выявленных заинтересован-ных сторон и на непрерывном улучшении процесса организации |
На балансе потребностей выявляемых заинтересованных сторон. Главная цель – наилучшее в данном классе производство. |
Управление – Managing:
Какой подход к лидерству? |
Реактивный, на базе спускаемых сверху указаниях |
Рекативный, на базе решений руководства на разных уровнях |
Проактивный с передачей полномочий на принятие решений |
Проактивный с высоким вовлече-нием сотрудни-ков организации в принятие решений |
Проактивный и нацеленный на обучение с привлечени-ем людей на всех уровнях |
Стратегия и политика – Strategy & policy:
Как решают, что важно? |
На базе неофициаль-ных данных с рынка и других источников |
На базе потребнос-тей и ожиданий заказчика |
На базе стратегии и привязки к потребностям и ожиданиям заинтересованных сторон |
На базе внедрения стра-тегии в операционные потребности и процессы |
На базе гибкости, подвижности и устойчивого производства |
Ресурсы – Resources:
Что нужно для получе-ния резуль-татов? |
Управление ресурсами в режиме ad hoc |
Результативное управление ресурсами |
Результативное и рациональное управление ресурсами |
Результативное и рациональное использование ресурсов с учетом их индивидуаль-ной наличности |
Управление ресурсами и их использование планируются, рацио-нально и результативно внедряются и удовлет-воряют заинтересован-ные стороны |
Процессы – Processes:
Как органи-зуются де-ятельности? |
Несистемный подход, в наличие только некоторые базовые процессы и инструкции |
Деятельности организуются по функциям с действующей базовой системой измерений |
Деятельности организуются в системе управления качеством на базе процессов, которая результативна и рациональна и допускает гибкость |
Есть результатив-ная и рациональ-ная система управления ка-чеством с хоро-шим межпроцес-сным взаимодей-ствием, поддер-живающая под-вижность и улуч-шение. Процессы нацелены на по-требности заинте-ресованных лиц |
Есть система управле-ния качеством, поддер-живающая инновации и калибровку, нацеленная на потребности и ожи-дания выявленных и возникающих заинте-ресованных сторон |
Монито-ринг и изме-рения – Mo-nitoring and measure-ment:
Как добива-ются резуль-татов? |
Случайным образом. Поправоч-ные действия в режиме ad hoc |
Некоторые предсказан-ные результаты получа-ются. Поправоч-ные и превентив-ные дейст-вия ведутся системно |
Предсказанные результаты получаются, особенно для заинтересованных сторон. Есть согласованные мониторинг, измерения и улучшения |
Есть согласованные, положительные, предсказуемые результаты с устойчивой тенденцией. Улучшения и инновации идут системно |
Получаемые результаты выше среднего по сектору для организации и поддерживаются в долгосрочном плане. Во всей организации внедрены инноваци-онность и улучшаемость |
Монито-ринг и изме-рения – Mo-nitoring and measure-ment
Как ведется наблюдение за резуль-татами? |
Имеются финансовые/ коммерчес-кие индика-торы и инди-каторы производи-тельности |
Отслеживаются удовлет-воренность заказчика, ключевые процессы реализации и производи-тельность поставщиков |
Отслеживаются удовлетворенность штата организации и заинтересован-ных сторон |
Ключевые индии-каторы произво-дительности согласованы со стратегией организации и используются для наблюдения |
Ключевые индикаторы производительности наблюдаются в реальном времени во всех процессах и производительность результативно и рацио-нально доводится до соответствующих заин-тересованных сторон |
Улучшение, инновации – Improve-ment, innovation & learning:
Как опреде-ляются при-оритеты для улучшений? |
На основе ошибок, жалоб или финансовых критериев |
На основе данных об удовлетво-рении заказчика или поправочных и превентив-ный действий |
На основе потребностей и ожиданий некоторых заинтересованных сторон, а также поставщиков и штата организации |
На основе тенденций и данных от других заинтересован-ных сторон, а также анализа изменений в социальной, окружающей и экономической среде |
На основе данных от возникающих заинтересованных сторон |
Улучшение, инновации – Improve-ment, innovation & learning:
Как происходит обучение? |
Случайно, на индивиду-альном уровне |
Есть системати-ческое научение, исходя из успехов и неудач организации |
В организации реализован систематический и разделяемый процесс обучения |
В организации есть культура обучения и сообщения знаний, нацеленная на непрерывное улучшение |
Процессы организации по обучению разделяются с соответствующими заинтересованными сторонами, поддерживают твор-чество и инновации |
Удобной графической формой представления результатов самооценивания является лепестковая диаграмма, пример которой приведен на Рис. 39.
Вдоль осей, соответствующих ключевым элементам модели ISO 9000, отложены значения уровней соответствия от 0 до 5 с промежуточным шагом 0,5, и одновременно отображаются заданные цели и текущие значения по всем этим показателям.
Рис. 39. Пример результата самооценивания на соответствие стандартам ISO 9000
На диаграмме сразу видно, что в данной организации надо, прежде всего, улучшать ключевой элемент №8 – Мониторинг, анализ измерений и обзоры.
Задания для самопроверки
Проведите самооценивание известной Вам организации-разработчика ПО по ключевым элементам стандарта ISO 9004.
Проанализируйте его результаты и предложите обоснованные рекомендации по улучшению процессов производства ПО в данной организации.
6.Формальные методы в разработке по
Формальные методы в разработке программного обеспечения призваны, с одной стороны, повысить степень его автоматизации, а с другой – гарантировать высокий уровень качества создаваемого программного продукта, который достигается, прежде всего, за счет уменьшения доли «человеческого фактора» в разработке. В идеале создание ПО должно сводиться к заданию его спецификации, из которых автоматизированным образом получается корректный программный код, реализующих данную спецификацию оптимальным образом.
Первым шагом к формализации является создание формальной модели будущего программного продукта, обладающей определенными свойствами, исходя из начальных требований к нему. Как правило, требуется создать не одну модель, а семейство согласованных между собой моделей, описывающих будущий продукт с разной степенью абстракции (levels of abstraction), по мере уточнения требований к продукту и разных точек зрения (points of view) на него. Существенными требованиями к этому семейству моделей является, с одной стороны, их внутренняя непротиворечивость и полнота, а с другой стороны, – представление в форме, доступной для содержательной обработки на ЭВМ и в то же время совершенно понятной разработчику и в достаточной степени заказчику.
Инструменты формализации и верификации
Существует ряд инструментальных средств для представления формализованных моделей программных продуктов, таких как языки моделирования MSC[27], SDL, UML[34], UCM[28], CPN, ASM, c помощью которых можно описать поведение достаточно сложных систем наглядным и, главное, формализованным способом. Некоторые из них позволяют не только исследовать различные свойства таких моделей с помощью других специализированных инструментальных средств, но сгенерировать код на языке программирования (например, С), реализующий данную модель.
Написание моделей является трудной задачей, однако модель, про которую можно доказать, что она непротиворечива и полна, несет огромную ценность, поскольку никакая проверка свойств модели тестированием не может гарантировать ее правильное поведение во всех возможных случаях. Рассмотрим для примера простую классическую задачу о безопасном железнодорожном переезде (Рис. 40).
Рис. 40. Задача о железнодорожном переезде
Имеется железнодорожный переезд, оборудованный датчиками движения поездов и автоматическими шлагбаумами для автотранспорта. Датчики регистрируют вход поезда в критический интервал и выход из него, а шлагбаумы закрывают или открывают движение через переезд для автотранспорта. Задача – обеспечить состояние обоих шлагбаумов «переезд закрыт» всякий раз, когда в критическом интервале находится хотя бы один поезд. Предполагается также, что в критическом интервале не могут находиться одновременно два поезда на одном и том же пути.
Написание соответствующей программы, получающей сигналы от датчиков и управляющей шлагбаумами, уже нетривиально, поскольку тривиальное решение – шлагбаумы всегда закрыты – явно не годится. В реальной ситуации приходится предусматривать ситуации, когда, например, поезд, войдя в критический интервал, затем начал двигаться в обратную сторону, или когда, например, перестали поступать сигналы от датчиков; таких «нестандартных» случаев может оказаться достаточно много и ни один из них не может быть пропущен в реализации программы управления реальным железнодорожным переездом.
Если в данной задаче всего 4-5 требований, то насколько сложнее становится задача формализации, когда исходных требований тысячи и десятки тысяч! На практике для доказательства свойств таких моделей применяются автоматизированные методы дедуктивного вывода (deductive reasoning), методы проверки на модели (model checking) и их различные комбинации с применением эвристических подходов. Общего решения не существует, ввиду очевидной алгоритмической неразрешимости задачи о поиске такого доказательства.
Известно достаточно много инструментальных систем для формализации и исследования подобных моделей, например:
ACL2 – Computational Logic, США
ASCE – Adelard, Соединенное королевство
Atelier B – STERIA Méditerranée, Франция
B-Toolkit – B-Core, Соединенное королевство
BLAST – University of Passau, Германия [21]
CADENCE – CADENCE, США
CADP – VASY, Франция
CBMC – Carnegie-Mellon University, США [24]
CPN Tools – University of Aarhus, Дания [38]
Coq Proof Assistant –INRIA, Франция [31]
Escher – Escher Technologies Ltd., Соединенное королевство
FDR – Formal Systems, Соединенное королевство
Isabelle – University of Cambridge, Соединенное королевство [32]
Kronos – Verimag, Франция
NuSMV – ITC-IRST, Italy [25]
PARAGON-VERSA (ACSR) – University of Pennsylvania, США
ProofPower – ICL, Соединенное королевство
Prover – Prover Technology, Швеция
PVS/DC – SRI International, США
RAISE tools – Terma, Дания
Simplify – HP Labs, США [37]
SPIN – Bells Labs, США [22]
SRDSV – Институт систем информатики им.А.П.Ершова СО РАН, Россия
StateClock – York University, США
SteP – Stanford University, США
Tempura PVS/IT – Newcastle, Соединенное королевство
TRIO – Uni.Namur, Бельгия
UPPAAL – Uppsala, Sweden; Alborg, Дания
Valiosys – Valiosys, Франция
Vampire – University of Manchester, Соединенное королевство [33]
VERISOFT – Bell Labs, США [26]
Zola – Imperial Software Technology, Соединенное королевство
Z3 – Microsoft Research, США [36]
Многие из них, будучи изначально разработаны в академической среде как результат НИР, стали затем программным продуктом, который поддерживается компанией, осуществляющей его дальнейшее развитие и сопровождение уже как коммерческого продукта. В то же время в различных компаниях, разрабатывающих промышленное программное обеспечение, имеются собственные инструментальные средства, как правило, являющиеся их торговыми секретами, в той или иной мере обеспечивающие выполнение задач верификации создаваемого ПО.
Формализация исходных требований проводится вручную, и ее главная проблема – обеспечить адекватность получаемой формальной модели исходным требованиям. Как только формальная модель получена, ее уже можно исследовать и анализировать, применяя различный инструментарий, но все выводы будут относиться не к исходным требованиям, а только к этой модели. Поэтому проблема адекватности – основная для принятия решения о том или ином методе формализации.
Формализация требований полезна даже при отсутствии инструмента для дальнейшей верификации полученной модели, поскольку при передаче требования средствами уже другого языка вскрываются неточности и прямые ошибки, которые иначе остались бы незамеченными до фазы кодирования и, возможно, еще дальше. Существует оценка, что только на этапе ручной формализации находят примерно 30% ошибок в исходных требованиях, что, в соответствии с кривой Боэма (Рис. 2) существенно снижает лишние затраты на создание данного программного продукта.
На сегодняшний день единственным разумным решением этой проблемы является разделение ответственности за адекватную формализацию между разработчиком ПО, эту формализацию осуществляющим, и заказчиком, предлагающим исходные требования для формализации. Язык представления формальной модели должен быть lingua franca (общим языком) этих двух категорий лиц – участников программного проекта. Разумеется, разработчик, осуществляющий формализацию, может не знать всех тонкостей и особенностей той предметной области, для которой разрабатывается ПО; поэтому его интерпретация исходных терминов на языке формализации может быть не той, какую имеет в виду заказчик. Отсюда следует, что язык формализации должен быть понятен заказчику, по крайней мере, в такой степени, что он может принять обоснованное мнение о правильном или неправильном отображении его требований в этом языке формализации.