markdown:
# «Институт системного программирования Российской академии наук В.В. Липаев ТЕСТИРОВАНИЕ КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ ...»
• уровень поддержки, оказываемой производителями крупных продуктов, варьируется в широких пределах, поскольку эти системы распространяются свободно, поддержка производителей особенно важна в тех случаях, когда у разработчиков возникают проблемы, на пример, при тестировании, связанные с получением доступа к исход ному коду и к подробной документации системы;
• несмотря на то, что производитель берет на себя обязательст ва по поддержке своих программных комплексов, изменение ситуа ции на рынке и экономических условий могут привести к тому, что ему станет трудно продолжать выполнение взятых обязательств по их сопровождению.
В.В. Липаев. Тестирование компонентов и комплексов программ Применение стандартов интерфейсов Открытых систем при производстве компонентов для повторного использования в программных комплексах Основными целями создания и применения концепции, мето дов и стандартов Открытых систем является повышение общей экономической эффективности производства и функционирования систем, а также логической и технической совместимости их компо нентов для обеспечения повторного использования готовых про грамм и данных. Для достижения этих целей развиваются и приме няются различные проблемно-ориентированные технологии и комп лексы средств автоматизации производства комплексов программ, базирующиеся на повторном использовании апробированных про граммных компонентов, комплексов и данных, их эффективном переносе на различные аппаратные и операционные платформы и согласованном взаимодействии в распределенных системах.
Задача сводится к максимально возможному повторному использованию разработанных и апробированных программных и информационных компонентов при расширении масштаба комплек сов программ, изменении вычислительных аппаратных платформ, их операционных систем и процессов взаимодействия. Концепция и система стандартов Открытых систем должны обеспечивать возмож ность относительно простого и эффективного по трудоемкости пере носа апробированных программных продуктов и информации баз данных на различные типы аппаратных платформ за счет стандар тизации процессов и интерфейсов взаимодействия программ с опера ционными системами ЭВМ. Основной задачей является транспорти ровка и перенос функций и процедур обработки информации, а также содержания баз данных между различными платформами, осуществ ляющими их обработку. Подобные обмены функциями, процедурами и данными имеют неоперативный характер и могут осуществляться при проектировании вне реального масштаба времени. Проблемы состоят преимущественно в обеспечении сохранности апробирован ного функционального ядра текстов программ и информации баз данных при их переносе на иные аппаратные и операционные платформы для снижения трудоемкости и длительности произ водства сложных программных продуктов.
Лекция 1.4. Требования к повторному использованию готовых компон. Концепция Открытых систем это совокупность международ ных стандартов, которая специфицирует интерфейсы, услуги и под держивающие форматы для достижения взаимодействия и переноси мости программных продуктов, данных и персонала, достаточные для того, чтобы обеспечивать:
• возможность переноса (мобильность) компонентов, комп лексов программ и данных, разработанных должным образом, с минимальными изменениями на широкий набор аппаратных и опера ционных платформ;
• совместную работу (интероперабельность) компонентов с другими компонентами, программными комплексами и системами на локальных и удаленных платформах;
• взаимодействие с пользователями в стиле, облегчающем пос ледним переход от системы к системе (мобильность пользовате лей).
Открытые системы делают доступным пользователям широкий круг программных продуктов и их компонентов, позволяют пред приятиям сэкономить средства на документации и переподготовке специалистов, а кроме того делают их независимыми от конкретного поставщика программного и аппаратного продукта. Построение открытых систем из унифицированных по взаимодействию компо нентов и комплексов программ стимулирует конкуренцию среди поставщиков как по соотношению цена/производительность, так и по функциональным возможностям. Профессионалы в области Открыт ых систем акцентируют усилия на поиске и создании гибкой, способ ной к наращиванию программной и информационной среды, которые базируются на трех направлениях стандартизации:
• стандартизация аппаратных и операционных платформ;
• стандартизация методов и технологий обеспечения жизнен ного цикла программных компонентов и комплексов;
• стандартизация интерфейсов программных компонентов и комплексов между собой, с операционной и внешней средой.
Идеология Открытых систем существенно отражается на ряде направлений развития современных программных продуктов. Она базируется на строгом соблюдении совокупности протоколов и стандартов де-юре и де-факто. Программные и аппаратные компо ненты должны отвечать двум важнейшим требованиям: переноси мости и возможности согласованной, совместной работы с другими, В.В. Липаев. Тестирование компонентов и комплексов программ возможно удаленными, компонентами. Это позволяет обеспечивать совместимость различных программных компонентов, комплексов, систем и средств передачи данных.
Технология Открытых систем для повторного использования компонентов и переноса комплексов программ на иные платформы наиболее сильно отражается на сокращении затрат ресурсов при создании крупных «коммерческих» административных систем обра ботки информации. При этом возможно снижение трудоемкости в 10 15 раз, длительности разработки в 5 8 раз и числа необходи мых специалистов почти вдвое относительно значений при полной разработке без применения современной технологии переноса и ПИК.
Эффективность переноса программных продуктов систем реального времени значительно ниже, чем в предыдущем случае, вследствие высокой доли затрат на перепрограммирование некоторых компонен тов и интерфейсов, а также на постановку и освоение технологии на новой платформе. Для этого класса комплексов программ при пере носе трудоемкость может уменьшаться в 4 5 раз, длительность в 2 3 раза, а необходимое число специалистов почти в два раза отно сительно полной разработки «с нуля» без применения ПИК.
Рядом зарубежных организаций и промышленных фирм под ру ководством IEEE с 1990 года ведется активная разработка и модер низация последовательных версий стандартов интерфейсов Откры тых систем POSIX (Portable operating system interfaces). В результате подготовлена группа международных стандартов из четырех крупных частей ISO 9945:1-4:2003 (IEEE 1003.1 – 2003). Цель документов – стандартизация обеспечения переносимости программных ком понентов на уровне исходных текстов. В них определены основные интерфейсы операционных систем и окружения, интерфейсы команд ного интерпретатора, а также программы общих утилит. Три отдель ных крупных тома включают: базовые определения;
системные ин терфейсы;
команды управления и сервисные программы (утилиты).
Кроме того, имеется большой четвертый том общего обоснования выбранных решений системы POSIX. Важными свойствами разрабо танных программных интерфейсов являются целостность, модуль ность их построения и параметризуемость.
Стандарты открытых систем – POSIX регламентируют со вокупность базовых, системных сервисов для обеспечения унифици рованных интерфейсов прикладных программ, специфицированных Лекция 1.4. Требования к повторному использованию готовых компон. для языка Си, командного языка и совокупности служебных про грамм. Основная цель – сделать программы переносимыми на уров не различных исходных языков. У каждого интерфейса компонентов программ существует вызывающая и вызываемая сторона, стандарты POSIX ориентированы преимущественно на формализацию вызы вающей стороны. Мобильность приложений должна обеспечиваться благодаря применению большого числа стандартизированных сис темных интерфейсных сервисов и возможности динамического выяс нения характеристик целевой платформы и подстройки под них ин терфейсов компонентов и комплексов программ.
Кроме стандартов POSIX, разработано и применяется множест во групп стандартов де-юре и де-факто для унификации архитектур и интерфейсов программных комплексов информационных систем раз личных классов. Разработку определенных стандартов стимулируют обычно коллективы высококвалифицированных в определенной при кладной сфере специалистов, которые привлекают другие организа ции. Одобрение и выпуск стандартов де-юре считается критерием высокого качества регламентируемых процессов.
*** При проектировании и производстве сложных программных продуктов целесообразно анализировать и выбирать подходящие ин терфейсы группы Открытых стандартов. Их необходимо приобретать, строго соблюдать и контролировать при применении, что является некоторым ограничением производственных процессов и требует оп ределенных затрат. Однако при этом одновременно повышаются экономические характеристики производства программных про дуктов и их компонентов, эффективность переноса на различные платформы, а главное - качество технологии и результатов производ ства.
Таким образом, для обеспечения эффективного управления раз работкой программ и обеспечения их тестируемости необходимо стандартизировать и соблюдать ряд требований архитектурно го построения и интерфейсов комплексов и компонентов про грамм. Эти требования могут иметь особенности для проектов в раз личных проблемно-ориентированных областях. Однако их стандарти зация обеспечивает значительный эффект в снижении трудоемкости и длительности последующей разработки и тестирования программных В.В. Липаев. Тестирование компонентов и комплексов программ продуктов и их версий. Частичная потеря гибкости архитектуры, не которое возрастание ресурсов, необходимых для их реализации, обычно полностью компенсируются повышением управляемости и технико-экономических показателей процесса разработки, тестирова ния, а также качества программных продуктов.
Лекция 1.5. Требования к допустимым рискам и к документированию… Лекция 1. ТРЕБОВАНИЯ К ДОПУСТИМЫМ РИСКАМ И К ДОКУМЕНТИРОВАНИЮ ТРЕБОВАНИЙ К КОМПЛЕКСАМ ПРОГРАММ Риски при формировании требований к характеристикам компонентов и программных комплексов Рассматриваемые риски могут быть обусловлены нарушениями технологий или ограничениями при использовании ресурсов – бюд жета, планов, коллектива специалистов, инструментальных средств, выделенных на разработку компонентов и комплекса программ. Ре зультирующий ущерб в совокупности зависит от величины и вероят ности проявления каждого негативного воздействия. Этот ущерб – риск характеризуется разнообразными метриками, зависящими от объектов анализа, и в некоторых случаях может измеряться прямыми материальными, информационными, функциональными потерями безопасности применяемых программ или систем. Одним из косвен ных методов определения величины риска может быть оценка сово купных затрат, необходимых для ликвидации негативных последст вий в программах, системе или внешней среде, проявившихся в ре зультате конкретного рискового события.
Процессы анализа и сокращения рисков должны сопутствовать основным этапам разработки и обеспечения качества компонентов и программных комплексов. Эти процессы могут быть отражены эта пами работ и процедур, которые рекомендуется выполнять при под держке производства компонентов и комплексов программ, и могут служить основой для разработки соответствующих планов работ при управлении и сокращении рисков (рис. 1.7):
• анализ рисков следует начинать с подготовки детальных ис ходных требований и характеристик комплекса программ, системы и внешней среды, для которых должны отсутствовать риски функцио нирования и применения;
В.В. Липаев. Тестирование компонентов и комплексов программ • для управления рисками и их сокращения в проектах ком плексов программ рекомендуется выделять три основных класса рис ков: функциональной пригодности, конструктивных характеристик качества и нарушения ограничений ресурсов при реализации процес сов производства программ;
• в каждом классе целесообразно анализировать несколько ка тегорий наиболее важных рисков, которые упорядочивать по степени опасности, угрозам для проекта, обусловленным ограничениями ре сурсов, дефектами и/или недостаточным качеством производства программ;
• контрмеры для сокращения рисков рекомендуется анализиро вать и применять последовательно, начиная с ликвидации наиболее опасных исходных причин – угроз, затем проводить анализ и умень шение уязвимости компонентов и комплекса в целом, а при недоста точности этих контрмер воздействовать непосредственно на умень шение итогового ущерба – риска в жизненном цикле комплекса про грамм и системы;
• процессы устранения рисков должны завершаться процеду рами мониторинга, сопровождения и конфигурационного управления изменениями версий компонентов и комплексов программ высокого качества с минимальными допустимыми рисками.
Управления рисками предполагает ясное понимание внутрен них и внешних причин и реальных источников угроз, влияющих на качество компонентов и комплекса программ, которые могут привести к большому ущербу. В результате анализа следует соз давать план отслеживания изменения рисков в жизненном цикле комплекса программ, который должен регулярно рассмат риваться и корректироваться. Главной целью управления рисками является обнаружение, идентификация и контроль за редко встречаю щимися ситуациями и факторами, которые приводят к негативным – рисковым результатам. Это должно отражаться на применении рег ламентированных процессов, в которых факторы и угрозы рис ков систематически идентифицируются, оцениваются и коррек тируются.
Одной из самых распространенных причин и опасных источни ков рисков, являются ошибки при оценке масштаба – размера про граммного комплекса.
Лекция 1.5. Требования к допустимым рискам и к документированию… Требования к допустимым рискам и документам требований к комплексам программ должны включать:
- риски при формировании требований к характеристикам компонентов и сложных программных комплексов:
• риски оценки масштабов комплексов программ;
• формирование допустимых рисков требований к характери стикам компонентов и программных комплексов;
• выделение, идентификацию, анализ угроз и рисков про граммного комплекса;
• оценивание опасности угроз и рисков и выбор контрмер для их сокращения;
• сокращение или ликвидацию опасных рисков комплекса программ;
• контроль, регистрацию, мониторинг и утверждение допус тимого интегрального риска комплекса программ;
- требования к допустимым рискам применения сложных программных комплексов;
- стандарты требований по управлению рисками в жизненном цикле программных комплексов;
- соглашение между заказчиком и разработчиками о докумен тировании требований, содержания и применения программно го комплекса;
- техническое задание на проект и исходные требования к про граммному комплексу:
• организация документирования требований к компонентам и программным комплексам;
• детальные требования к функциям и характеристикам кон кретного программного комплекса.
• документирование требований к программным компонен там и комплексам:
• документирование требований технического задания на проект программного комплекса;
- примеры документирования требований к функциям и харак теристикам программного комплекса:
• документ общих системных требований к программному комплексу;
• документ детальных требований к конкретному программ ному комплексу.
Рис 1. В.В. Липаев. Тестирование компонентов и комплексов программ Эти ошибки, чаще всего, бывают случайными – непредумыш ленными, вследствие недостаточной компетентности заказчика или разработчика-поставщика. Однако в некоторых случаях в превыше нии значения согласованного масштаба заказанного продукта могут быть заинтересованы разработчики для получения больших ресурсов от заказчика, а уменьшенную оценку масштаба могут стремиться представить заказчики для сокращения выделяемых затрат на разра ботку программного продукта. Величина оцененного и согласованно го между заказчиком и разработчиком масштаба комплекса программ непосредственно отражается на:
• бюджете и трудоемкости разработки и обеспечения всего жизненного цикла программного комплекса;
• затратах времени, сроках создания и всего жизненного цикла реализации и применения комплекса программ;
• потребности в численности и квалификации специалистов для реализации проекта и создания программного продукта в соот ветствии с требованиями заказчика.
Эти три ключевых характеристик обычно тесно связаны и могут изменяться в процессах разработки проекта заказчиком или разработ чиком в сторону увеличения или уменьшения в соответствии с их ин тересами, целями и возможностями. Для снижения возможного ущерба – рисков применяются оценки, контроль и мониторинг рисков, а также различные контрмеры. Уменьшение рисков долж но производиться путем максимально возможного приближения про екта к требованиям заказчика и к выделенным ресурсам или путем снижения этих требований и увеличения заказчиком ресурсов на комплекс программ. В крупных проектах систем, использующих комплексы программ, риски могут быть обусловлены дефектами функциональных характеристик программ, а также недостатками систем и внешней среды, в которой они используются.
Риски могут проявляться в процессах проектирования и произ водства при изменении и развитии комплексов программ и при при менении готового программного продукта по прямому назначению.
Это приводит к необходимости анализа рисков функционирования в условиях, различающихся:
• источниками и причинами угроз и опасного проявления рис ков;
Лекция 1.5. Требования к допустимым рискам и к документированию… • классами, категориями, уязвимостью комплекса программ и системы, вероятностью проявления и величиной последствий рисков;
• возможными и реализуемыми контрмерами для предотвра щения и сокращения рисков и их эффективностью.
Неопределенность оценок масштаба комплексов программ яв ляется одним из важнейших факторов, влияющим на риски всего жизненного цикла проекта. Точность оценки размера нового ком плекса программ значительно повышается после формулирования на чальных требований и спецификаций заказчиков, проведения анализа требований после завершения разработки предварительного проекта.
На этапе концепции проекта ошибки оценки размера уменьшаются приблизительно до 40%. Это вполне объяснимо, поскольку еще не уточнены структура и многие детали проекта. Эти вопросы могут быть разрешены во время разработки структуры и спецификаций требований к комплексу программ, и тогда можно оценить его размер с точностью до 15 – 20%.
Как только структура комплекса будет разбита с учетом выде ления самых нижних, доступных уровней компонентов может быть создан более точный показатель размера комплекса программ. После завершения разработки и подтверждения проектных спецификаций при детальном проектировании комплекса программ может быть определена структура внутренних данных и функции программных компонентов. На этом этапе оценка размера комплекса может со ставить около 10%. Уточнения размеров комплекса и компонентов, могут быть решены к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса око ло 5 – 10%, связанная с тем, насколько хорошо программисты по нимают спецификации, в соответствии с которыми они должны ко дировать программы.
Если при оценке масштаба проекта его величина в договоре оп ределена недостаточной – заниженной, то основной ущерб – рис ки достаются разработчикам. Они вынуждены принимать жесткие меры для выполнения плановых сроков, выделенного бюджета работ при относительно малом числе специалистов, что угрожает рисками срыва сроков и нарушения стоимости проекта. Недооценка размера комплекса программ и ресурсов для его реализации может резко уве личивать число дефектов в программах. Кроме того, ограниченные ресурсы для реализации в полном объеме функциональной пригод В.В. Липаев. Тестирование компонентов и комплексов программ ности, могут отражаться на ее качестве и удобстве применения, а также на конструктивных характеристиках: на безопасности, надеж ности, качестве взаимодействия с внешней средой и с пользователя ми, качестве документации и других эксплуатационных факторах.
Для продолжения разработки проекта после оценки рисков масштаба комплекса программ необходимо выполнить цикл поэтап ного определения и формирования совокупности спецификаций тре бований к проекту комплекса программ. Первым этапом является создание концепции проекта и комплекса первичных требований к иерархическому набору функций, на которые могут быть разбиты предполагаемые фактические компоненты комплекса. В дальнейшем декомпозиция может детализироваться, формируя упрощенный или более точный уровень абстракции и взаимодействия компонентов.
Для устранения или снижения рисков до допустимых пределов может быть необходимо изменение требований к функциональной пригодности, к конструктивным характеристикам и доступным ре сурсам.
Обычно заказчики и разработчики первоначально устанавлива ют требования к каждой характеристике компонента или комплекса программ без учета относительных затрат на их достижение, а также без детального анализа их совместного влияния на полную функцио нальную пригодность и риски у потребителей. Это может приводить к значительным перекосам и несбалансированным значениям тре бований к отдельным, взаимосвязанным характеристикам, на ко торые не рационально используются ограниченные ресурсы, или к не адекватно низким их значениям. В проектах это может угрожать зна чительным повышением стоимости и рисков и/или снижением кон курентоспособности создаваемого программного продукта из-за не достаточного уровня отдельных показателей качества.
Атрибуты качества компонентов и комплексов программ имеют различные меры и шкалы, вследствие чего они в большинстве своем непосредственно не сопоставимы между собой. Они предваритель но выбираются и согласовываются с заказчиком при последователь ном, почти независимом анализе каждого атрибута качества, для ис пользования в контракте и технических заданиях. Для обобщенного оценивания качества необходим учет относительного влияния каждой конструктивной характеристики на функциональную пригодность.
При этом не всегда учитываются ресурсы для их реализации в кон Лекция 1.5. Требования к допустимым рискам и к документированию… кретном комплексе. Это часто приводит к выдвижению ряда не ра циональных требований, которые значительно отличаются либо по степени влияния на функциональную пригодность, либо по величине ресурсов, необходимых для их реализации. Для целенаправленного эффективного управления рисками при проектировании целесообраз но иметь механизм объединения разнородных характеристик в неко торый интегральный показатель, отражающий их совокупное влияние на функциональную пригодность. Таким образом, при разработке требований к характеристикам проекта выявилась проблема анализа системной эффективности компонентов и комплекса и обобщения его характеристик, а также оценивания совместного влияния конструк тивных характеристик на функциональную пригодность с учетом за трат на их реализацию.
Эти данные могут использоваться, прежде всего, как ориенти ры для селекции и исключения из требований конструктивных харак теристик качества с особенно низкими обобщенными приоритетами рисков, в наименьшей степени влияющих на функциональную при годность и не оправдывающих больших затрат на реализацию. Ана лиз оставшихся характеристик качества и рисков может проводиться для выделения завышенных требований, а также, возможно, для сни жения их значений и приближения влияния к средним значениям.
Кроме того, сравнительный анализ обобщенных приоритетов на ос нове отношения влияния на качество и затраты позволяет выделять атрибуты качества, отличающиеся большими затратами – рисками, не оправданными их степенью воздействия на функциональную пригод ность. Подобные процедуры могут завершать разработку требований к свойствам, характеристикам качества и допустимым рискам при де тальном проектировании сложных комплексов программ.
Выше анализировалось преимущественно изменение функцио нальной пригодности и снижение риска при совершенствовании конструктивных характеристик программ. Однако для заказчика и пользователей доминирующее значение могут иметь номенклатура и особенности реализации некоторых основных функций комплекса программ, которые, как правило, требуют наибольших затрат и опре деляют основной эффект или возможные риски от применения ком плекса программ, а также потенциальный уровень спроса на рынке.
На основе анализа и оценивания характеристик масштаба, набора В.В. Липаев. Тестирование компонентов и комплексов программ требований, возможных затрат ресурсов и значений рисков следует определять:
• целесообразно ли продолжать работы над конкретным про ектом или следует его прекратить вследствие больших рисков, недос таточных ресурсов специалистов, времени или трудоемкости (бюд жета) разработки;
• при наличии достаточных ресурсов следует ли провести мар кетинговые исследования для определения рентабельности полного выполнения проекта и создания программного продукта для поставки на рынок;
• достаточно ли полно и корректно формализованы концепция и требования к проекту, на основе которых проводились оценки за трат и рисков, или их следует откорректировать и выполнить повтор ный анализ с уточненными исходными данными.
Требования к допустимым рискам применения сложных программных комплексов Требования к сокращению рисков, связанных с результатами разработки и применения программного комплекса, должны реали зоваться формализованным процессом, позволяющим выделять, сис тематически идентифицировать, оценивать и смягчать факто ры, угрозы и величину последствий возможных рисков. Для этого при управлении проектом следует: идентифицировать угрозы и рис ки, имеющие как внешние, так и внутренние причины;
проводить их количественную оценку;
разработку откликов и контрмер для сокра щения рисков и контроль реализации откликов (см. рис. 1.7).
Обеспечение минимальных допустимых рисков требований функциональной пригодности имеет доминирующее значение и изменения других классов рисков обычно должны быть, в первую очередь, подчинены сокращению рисков функционирования системы и комплекса программ. Поэтому анализ рисков и возможных угроз целесообразно проводить систематизированно, начиная с установле ния требований к допустимым рискам функциональной пригодности.
Ущерб вследствие ошибок функциональных требований к проекту программного комплекса может проявляться двумя видами рисков:
недостатками достигнутых характеристик комплекса и рисков от на рушения ограниченности доступных и используемых ресурсов в его жизненном цикле.
Лекция 1.5. Требования к допустимым рискам и к документированию… В жизненном цикле важнейшим риском является ущерб при не выполнении комплексом программ, назначения и функций главной характеристики качества функциональной пригодности, формали зованной в требованиях заказчика. В зависимости от назначения, функций, критичности требований к системе и программному ком плексу может требоваться либо полная ликвидация определенных или всех видов рисков, либо сокращение некоторых из них до допус тимых пределов, либо игнорирование некоторых и сохранение на достигнутом уровне ущерба вследствие нарушения требований заказ чика к программному комплексу.
Для выполнения требуемых функций комплекса программ необ ходима адекватная исходная информация от объектов внешней среды, содержание которой должно полностью обеспечивать реали зацию декларированных функций. Полнота формализации номенкла туры, структуры и качества входной информации для выполнения требуемых функций является одной из важных составляющих при определении функциональной пригодности и сокращении рисков применения комплекса программ в соответствующей внешней среде.
Степень покрытия всей выходной информацией: целей, назначения и функций программного комплекса для пользователей, следует рас сматривать как основное требование к допустимым рискам функ циональной пригодности. Прослеживание и оценивание адекватно сти и полноты состава выходной информации снизу вверх к назначе нию комплекса программ должны завершать выбор базовых характе ристик функциональной пригодности, независимо от сферы примене ния системы.
При начальном формировании требований к функциональной пригодности комплекса программ практически невозможно досто верно предусмотреть сбалансированное выделение каждого вида ресурса для полной реализации каждой требуемой характеристики сложного программного комплекса. Кроме того, требования заказчи ка к функциям всегда субъективны и не стабильны, что также отра жается на изменении рисков при разработке и модификациях ком плексов программ. При этом некоторые характеристики в реальном проекте могут приобретать значения более высокие, чем действи тельно требуются, на что нерационально расходуются ресурсы, а дру гие – не удовлетворять требованиям контракта и технического зада ния. Для разрешения этого противоречия основное значение имеет В.В. Липаев. Тестирование компонентов и комплексов программ деятельность менеджера рисков, который должен быть способен прогнозировать, проводить поэтапный анализ, контроль, оценивание и мониторинг возможных и реальных отклонений от требуемых ха рактеристик программного комплекса и используемых ресурсов, управление контрмерами и последовательное изменение их для сокращения интегрального риска всей системы.
Требования к оценке и сокращению рисков вследствие недос таточных характеристик качества комплексов программ должны сопровождать весь их жизненный цикл. Для этого необходимо кон тролировать области возможного возникновения рисков, оценивать вероятности их проявления, виды и степень влияния угроз, которые следует минимизировать как можно раньше по мере их возникнове ния и обнаружения в процессах жизненного цикла комплекса про грамм. Основной эффект по снижению рисков вследствие недоста точных характеристик должен достигаться на начальных этапах раз работки, когда возможно предотвращение или сокращение многих из них с минимальными затратами времени и других ресурсов. Для это го в технологическом процессе производства необходимо исполь зовать методы, которые включают:
• определение ценности (приоритета) и выделение каждой требуемой характеристики для реализации необходимой функцио нальной пригодности программного комплекса и системы;
• определение приоритетов характеристик качества, компонен тов и этапов производства, которые имеют потенциальные техниче ские, стоимостные или плановые риски;
• оценивание вероятности каждого вида угроз характеристик качества, потенциальной величины и вероятности их возможного не гативного воздействия на каждую характеристику функциональной пригодности системы и программного комплекса;
• оценивание уязвимости и последствий дефектов каждой ха рактеристики и затрат ресурсов для восстановления требуемой функ циональной пригодности системы и программного комплекса при проявлении рисков;
• систематизацию, документирование и оценивание эффектив ности доступных методов, средств и ресурсов контрмер для сокра щения рисков функциональной пригодности и выделенных характе ристик комплекса программ;
Лекция 1.5. Требования к допустимым рискам и к документированию… • планирование и разработку решений по контрмерам для обеспечения допустимого уровня интегрального риска функциональ ной пригодности и характеристик системы, в том числе, возможно, за счет изменения требований к программному комплексу, системе и/или доступных ресурсов;
• оценку вероятности сокращения рисков характеристик до допустимых пределов, при реализации процессов разработки и всего жизненного цикла программного комплекса с учетом доступных ре сурсов.
Улучшение каждой характеристики требует затрат ресурсов, которые в той или иной степени должны отражаться на основной ха рактеристике комплекса программ – на функциональной пригодно сти. Эти характеристики имеют значение для проекта постольку, по скольку они обеспечивают требуемое качество реализации основного назначения и функций программного комплекса. При выборе кон кретных допустимых характеристик следует учитывать возможные затраты ресурсов на их достижение и на результирующее повышение функциональной пригодности, желательно, в сопоставимых экономи ческих единицах, в тех же мерах и масштабах. Такое, даже приблизи тельное, качественное сравнение эффекта и затрат позволяет избегать многих не рентабельных завышений требований к отдельным ха рактеристикам, которые не достаточно отражаются на адекватном улучшении функций программного комплекса. Поэтому для каждого проекта необходимо ранжировать характеристики (приоритеты) и выделять, прежде всего, те, которые могут в наибольшей степени улучшить функциональную пригодность и снижать риски для кон кретных целей системы.
Решение этих задач должно быть направлено на обеспечение высокой функциональной пригодности программного комплекса пу тем сбалансированного улучшения остальных характеристик в условиях ограниченных ресурсов. Для этого в процессе системного анализа при подготовке технического задания и требований специфи каций, значения и риски характеристик, должны выбираться с учетом опасности их влияния на функциональную пригодность. Излишне высокие требования к отдельным характеристикам, требующие для реализации больших дополнительных трудовых и вычислительных ресурсов, целесообразно снижать, если они слабо влияют на основ ные, функциональные характеристики программного продукта.
В.В. Липаев. Тестирование компонентов и комплексов программ Для управления требованиями и рисками с целью минимизации и выделения наиболее опасных из них необходимо сопоставлять ве роятности (частости) и последствия проявления как рисков функцио нальных характеристик комплекса программ, так и рисков доступных ресурсов. Для каждого проекта эти виды рисков могут различно вли ять на интегральный ущерб – риск комплекса программ, отражаю щийся на общем риске системы. Применяемые методы оценивания и анализа величин и вероятности рисков должны позволять определять приоритеты видов рисков с целью выделения соответствующей доли ресурсов на контрмеры для сбалансированного сокращения негатив ных последствий различных видов рисков.
Прямые риски, обусловленные ошибками и дефектами заданных требований экономических характеристик, могут вызвать ущерб за казчику при завышении стоимости проекта относительно реально необходимой или ущерб разработчикам, если стоимость оценена не достаточной для его успешной реализации. Эти риски могут уменьшаться при последовательном уточнении размера комплекса программ на этапах формирования требований, предварительного и детального проектирования, однако они не полностью учитывают ре альное влияние ограничений ресурсов на процессы и риски производ ства конечного программного продукта. Поэтому риски нарушения ограничений доступных ресурсов проекта целесообразно оценивать по их последующему отражению на степень возможной реализации требований заказчика в конечном программном продукте. По мере уточнения размера – масштаба и развития проекта комплекса про грамм эти риски обычно уменьшаются, однако их влияние может ос таваться существенным в процессе всего жизненного цикла.
Требования по управлению рисками в жизненном цикле про граммных комплексов регламентированы международным стандар том ISO 16085. Он включает особенности обеспечения, мониторинга качества и функциональной безопасности сложных комплексов про грамм на базе анализа и сокращения рисков процессов, регламенти рованных стандартом ISO 12207. В стандарте ISO 15504 содержится раздел, определяющий регламентирование и планирование процессов выявления и устранения совокупности различных рисков на протя жении всего жизненного цикла. Поэтапное, иерархическое снижение интегрального риска проекта программного комплекса при использо вании выбранной стратегии может требовать ее корректировки в за Лекция 1.5. Требования к допустимым рискам и к документированию… висимости от достигаемого эффекта и требуемых затрат на сокраще ние определенных рисков, необходимых для повышения качества, надежности и функциональной безопасности. Для решения этих задач стандартами рекомендуются последовательные процедуры:
• выявление и идентификация относящихся к комплексу про грамм рисков как в исходном состоянии и требованиях к проекту, так и на последовательных этапах его выполнения: по характеристикам качества, графикам производства, трудоемкости, ресурсам и техниче ским рискам;
• анализ вероятности проявления, причин, взаимозависимости видов и последствий рисков, чтобы сбалансировать и распределить их приоритеты, на основании которых будут отводиться ресурсы на различные контрмеры для снижения этих рисков;
• определение целесообразной стратегии и области управления каждым видом риска или их наборами в проекте в соответствии с по литикой на предприятии, а также со степенью влияния, вероятностью и типами рисков, которые должны выявляться и которыми следует управлять;
• для каждого вида риска (или набора рисков) определение метрики, отражающей изменения в состоянии рисков в зависимости от деятельности по их сокращению, которые должны характеризовать изменения в вероятности проявления, последствиях и временных диапазонах проявления рисков;
• реализация разработанной стратегии управления рисками, ат тестация результатов и оценка успешности стратегии в контрольных точках жизненного цикла проекта.
Документирование требований к программным компонентам и комплексам Общие требования к документации сложных комплексов программ и компонентов определены в стандарте ISO 9126 в разделе практич ность. Требования к практичности комплекса, функциям, характе ристикам и документам, включают их понятность и простоту исполь зования, зависят от его назначения и функций. Они могут формализо ваться заказчиками набором свойств, необходимых для обеспечения удобной и комфортной эксплуатации программного комплекса доста точно квалифицированными пользователями. Для обеспечения пол ноценного изучения процессов применения комплекса специалистами В.В. Липаев. Тестирование компонентов и комплексов программ необходима эксплуатационная и технологическая документация, требования к которой должны устанавливаться заказчиком и входить в состав основных требований к программному комплексу. Ее объ ем существенно зависит от назначения и функций продукта и может быть задан на основе анализа прецедентов подобных успешных про ектов. Для некоторых программных комплексов, подлежащих широ кому тиражированию, могут быть желательны адекватные по содер жанию электронные учебники, требования к объему и функциям ко торых также целесообразно оценивать по прецедентам. Следует учи тывать, что малый объем эксплуатационной документации может снизить качество и полноту использования функций сложного ком плекса программ, а очень большой объем – также может ухудшить эксплуатацию из-за трудности выделения из множества второстепен ных деталей и освоения наиболее существенных свойств и особенно стей применения комплекса.
Общее руководство по документированию проекта и требований к программному комплексу должно быть в составе соглашения меж ду заказчиком и разработчиками (см. рис. 1.7). В базовом докумен те о функциях, образе и границах документов комплекса программ должны содержаться требования заказчика, а дополнительные поже лания пользователей могут иногда представляться в виде вариантов использования комплекса. Подробные функциональные и нефункцио нальные требования должны быть зафиксированы в спецификации требований к программному комплексу. Однако если не собрать все требования вместе в виде структурированного и конкретного доку мента и не ознакомить с ним всех заинтересованных в проекте лиц, то у них не будет уверенности, что они согласны со всеми положениями спецификации требований и смогут их выполнить.
Документация исходных требований значительно влияет на достигаемое качество сложных комплексов программ, трудоемкость и длительность их создания. Организация документирования должна определять стратегию, стандарты, процедуры, распределение ресур сов, планы создания, изменения и применения документов требований на программы и данные систем. Для этого в общем случае должны быть выделены руководители и коллективы специалистов, кото рые должны планировать, утверждать, выпускать, распростра нять и сопровождать комплекты достоверных документов на программный комплекс. Они должны стимулировать разработчиков Лекция 1.5. Требования к допустимым рискам и к документированию… компонентов, программных комплексов и их корректировок, осущест влять непрерывное, регламентированное документирование процессов и результатов своей деятельности, а также контролировать полноту и качество документов. Структура документации и формы отдельных документов, используемых для совершенствования требований к про граммам, должны позволять:
• точно документально описывать и идентифицировать требо вания к каждой оформленной версии программных модулей, компо нентов и комплексов в целом в любое время на всем протяжении их жизненного цикла;
• надежно учитывать и регистрировать все анализируемые, под готавливаемые и проведенные корректировки требований в версиях модулей, компонентов и комплекса;
• снабжать руководителей проекта обобщенной и детальной информацией для принятия решений на изменения требований к про граммам, а также для контроля выполнения принятых решений;
• обеспечивать заказчиков и пользователей объективными све дениями о наиболее существенных корректировках требований и о но вых версиях компонентов и программного комплекса.
В документах целесообразно использовать иерархическую сис тему идентификации требований к версиям программного ком плекса, его модулям, компонентам и описаниям данных. Присвоение идентификаторов для составляющих проекта, вплоть до утвержденных требований к версиям программных модулей, компонентов и комплек сов, целесообразно осуществлять централизованно группой конфигу рационного управления. Некоторый произвол в идентификации ком понентов может допускаться только в процессе подготовки корректи ровок программ и данных до комплексирования их в версию про граммного комплекса, предъявляемую на испытания.
Техническое задание на проект и исходные требования к про граммному продукту целесообразно формировать на основе общих положений программной инженерии и должны содержать поэтапно уточняющиеся, детализирующиеся и дополняющиеся при детальном и рабочем проектировании разделы:
• титульный лист с утверждающими и согласующими подпи сями заказчика и разработчиков;
• полное наименование проекта программного комплекса;
В.В. Липаев. Тестирование компонентов и комплексов программ • назначение, цель разработки или модернизации программно го комплекса;
• основание для выполнения и финансирования проекта;
• организация заказчик проекта;
• предприятие головной исполнитель и соисполнители проек та;
• общие сроки выполнения всего проекта программного ком плекса;
• общие технические требования, перечень стандартов и базо вых нормативных документов для выполнения проекта;
• общие требования к программному комплексу;
требования к функциям и основным характеристикам качества;
• требования к внешней среде применения комплекса;
• специальные требования к аппаратной и операционной плат формам для реализации программного комплекса;
• требования к структуре, оформлению и содержанию эксплуа тационной и технологической документации;
• этапы и график выполнения основных работ проекта;
• ожидаемые результаты проекта и форма их представления;
• порядок контроля исполнения проекта и приемки результатов работы.
При разработке требований к программным комплексам, кроме основных целей, назначения и функций, важно учитывать и форму лировать содержание полного множества характеристик, каждая из которых может влиять на успех применения программного комплек са. Для уменьшения вероятности случайного пропуска важного тре бования заказчикам и пользователям целесообразно иметь типовые шаблоны документов, содержащих структурированные наборы тре бований, которые можно целеустремленно сокращать и/или адапти ровать, обеспечивая целостность всей совокупности требований для конкретных комплексов программ.
Выходные проектные данные для применения программного комплекса должны быть документально оформлены и выражены в требованиях заказчика так, чтобы их можно было проверить и под твердить соответствие входным проектным требованиям. Эти данные должны содержать критерии приемки программного продукта за казчиком или ссылки на них, а также идентифицировать те характе ристики, которые являются критическими для его надежного и безо Лекция 1.5. Требования к допустимым рискам и к документированию… пасного функционирования и применения. При работе над любым проектом необходимо достигать согласованности решений по каждо му набору и значениям требований до начала их реализации разра ботчиками.
Для разработчиков особенно важно формализовать требова ния в документах и согласовать их с заказчиком при утверждении контракта и технического задания на проект. Требования к ха рактеристикам, утвержденные после предварительного проектирова ния, могут быть закреплены в техническом задании как обязатель ные для детального и/или рабочего проектирования. Эти данные должны использоваться при последующем оценивании функций и характеристик качества и их сопоставлении с требованиями в процес сах тестирования, квалификационных испытаний или сертификации программного комплекса. Однако для сложных и дорогих проектов может потребоваться уточнение документов требований при де тальном проектировании с позиции улучшения соотношения значе ний качества и затрат ресурсов, которые необходимы или допустимы для их реализации.
На основе спецификации требований должны составляться и до кументироваться планы разработки проекта, а также тестирования системы, комплекса программ и эксплуатационной документа ции. Она должна содержать описание и сценарии поведения системы при различных условиях. Детали дизайна, сборки, тестирования или управления проектом, документированные в спецификации, не долж ны противоречить ограничениям разработки. Будучи конечным хра нилищем требований к программному продукту, спецификация тре бований должна быть ясной и понятной, чтобы у разработчиков и за казчиков не оставалось ни малейших возможностей для разночтения.
Состав стандартизированных характеристик программных комплек сов должны быть отдельным, обязательным разделом в общей спе цификации требований, итерационно формируемыми на этапах жиз ненного цикла и контролируемыми при испытаниях программного комплекса.
Чтобы было легко отслеживать и модифицировать содержание документов, каждое функциональное требование должно быть пред ставлено уникально и неизменно. Это позволит ссылаться на опреде ленные требования в запросе на изменения, в хронологии изменений, в перекрестных ссылках или матрице для прослеживания реализации В.В. Липаев. Тестирование компонентов и комплексов программ требований. При этом также упрощается многократное использова ние требований к модулям и компонентам в нескольких проектах.
Для эффективного управления и модификации требований с учетом сценариев и процедур их тестирования, должна использоваться тех нология и инструментарий управления конфигурацией комплексов программ.
Документирование требований к функциям и характеристикам комплексов программ В составе требований, ориентированных на сложные проекты, особенно важно полно и детально регламентировать необходимые характеристики комплексов программ. Использование при адаптации в качестве исходного, максимального набора процедур разработки и состава требований, позволяет предотвращать пропуск некоторых из них, существенных для развития конкретного проекта. Результаты комплексной разработки требований следует документировать и учитывать, при подготовке и утверждении заказчиком технических заданий и спецификаций требований на программный комплекс. Та кая технология систематизированной, итерационной разработки тре бований к комплексу программ позволяет избежать случайных про пусков, пробелов и неопределенностей в составе и содержании ут верждаемых заказчиком документов в технических заданиях и спе цификациях.
Стандартизированные в ISO 9126 характеристики качества ком плексов программ различаются по степени влияния на системную эффективность их применения по прямому назначению. Высшие при оритеты, естественно, должны присваиваться свойствам и атрибутам функциональной пригодности для достижения стратегических це лей использования программного комплекса. Все остальные стандар тизированные характеристики, в той или иной степени, должны спо собствовать обеспечению тактических целей выбранных конструк тивных требований. Разработка требований к свойствам и характери стик качества, естественно, должна начинаться с определения и до кументирования группы показателей, непосредственно отражающих функциональную пригодность. Компоненты требований функцио нальной пригодности очень разнообразны и их целесообразно рас пределять на две части: унифицируемую по структуре и содержанию для различных по назначению комплексов программ, и уникальную – Лекция 1.5. Требования к допустимым рискам и к документированию… непосредственно связанную со специфическими функциями и целями применения программного комплекса.
Для функциональных возможностей (стандарт ISO 9126) сле дует регистрировать приоритеты реализации соответствующих тре бований, а также указывать документы, где детализированы особен ности этих свойств для конкретного проекта.
Для освоения и применения широкого состава функций, свойств и атрибутов характеристик при разработке требований и документов к программному комплексу необходимы квалифицированные спе циалисты и значительный объем работ. Полностью это может быть рентабельно при создании достаточно крупных проектов. В этих слу чаях обсуждение и согласование между заказчиком и разработчи ком всего состава документов требований к функциям, свойствам и рациональным значениям ансамбля характеристик качества, позволя ет избегать как нецелесообразное завышение требований и использо вания ресурсов, так и не оправданное снижение требований к отдель ным характеристикам. Это может негативно отражаться на функцио нальной пригодности программного комплекса и технико-экономи ческих характеристиках всего проекта. При этом важно учитывать ограниченность ресурсов при выборе свойств и значений характери стик и необходимость компромиссов между ними вследствие мно гочисленных связей и взаимовлияний.
Документацию, формализующую требования к сложному программному комплексу, целесообразно делить на две части. Пер вый документ системные требования, предназначен для опреде ления роли, назначения и функций программного комплекса в соста В.В. Липаев. Тестирование компонентов и комплексов программ ве системы для определенной внешней среды. Он используется, пре жде всего, заказчиком и менеджером главным конструктором при организации жизненного цикла сложного комплекса программ. Этот документ подлежит тщательному согласованию между заказчиком и разработчиками и утверждению заказчиком при любых изменениях требований. Второй документ определяет более детальные требова ния к реализации комплекса программ разработчиками. Формализа ция и реализация этих требований иногда частично может проходить без обязательного согласования с заказчиком, но документ должен служить основой для деятельности всего коллектива разработчиков.
Требования в этих двух документах могут несколько повторяться, но это может быть удобно, так как их основные пользователи сущест венно различаются квалификацией и ответственностью за успех про екта. Ниже приводятся примеры шаблонов двух документов, ориен тированных на разработку сложных программных продуктов высоко го качества реального времени.
Документ общих системных требований к программному комплексу должен содержать следующие сведения:
• требования к назначению и архитектуре системы, содержа щие идентификацию и функции основных компонентов системы, их назначение, статус разработки, аппаратные и программные ресурсы;
• требования проекта системы к функциям программного ком плекса, как к целому в общей архитектуре системы;
• цели, назначение программного комплекса, потребности за казчика и потенциальных пользователей к его функциям и характери стикам в заданной системной среде применения;
• распределение системных требований по основным функцио нальным компонентам программного комплекса с учетом требова ний, которые обеспечивают заданные характеристики системы;
• требования к совместному целостному функционированию компонентов, описание и характеристики их динамических связей при применении комплекса программ;
• требования к унификации интерфейсов и базы данных ком понентов комплекса программ;
• требования трассируемости функций компонентов программ ного комплекса к требованиям проекта системы;
• спецификацию требований к функциям, качеству, надежности и безопасности программного комплекса;
Лекция 1.5. Требования к допустимым рискам и к документированию… • производные требования к компонентам программного ком плекса и требования к интерфейсам между системными компонента ми, элементами конфигурации комплекса программ и аппаратуры;
• требования к применению базовых стандартов и к формиро ванию профиля стандартов для проекта программного комплекса.
Документ детальных требований к конкретному программ ному комплексу для обеспечения его разработки, сопровождения и модификации должен содержать:
- общие требования к программному комплексу:
• перечень объектов внешней среды применения программного комплекса (технологических объектов управления, подразделе ний предприятия и т.п.), при управлении которыми должен ре шаться требуемый комплекс функциональных задач;
• требования к операционной среде функционирования программного комплекса;
• требования к составу и качеству реализации функций и харак теристик программного комплекса;
• распределение функций между персоналом, программными и техническими средствами при различных ситуациях решения требуемого комплекса функциональных задач;
• требования к периодичности и допустимой продолжительности решения функциональных фрагментов комплекса задач в реаль ном времени;
• требования к надежности и безопасности функционирования системы и программного комплекса;
• требования к производительности системы и программного комплекса с заданным качеством;
• требования к возможности адаптации функций комплекса про грамм к различной внешней среде и условиям применения;
• требования к оформлению результатов и документов програм мирования и текстов программных модулей и компонентов;
- требования к входной информации комплекса программ должны содержать:
• источники информации и их идентификаторы;
• перечень и описание входных сообщений (идентификаторы, формы представления, регламент, сроки и частота поступления данных);
• перечень и описание структурных единиц информации вход В.В. Липаев. Тестирование компонентов и комплексов программ ных сообщений или ссылки на документы, содержащие эти дан ные;
- требования к выходной информации комплекса программ должны содержать:
• назначение и потребители выходной информации;
• перечень и описание содержания выходных сообщений;
• регламент и периодичность выдачи результирующей информа ции;
• допустимое время задержки отклика на результаты решения определенных задач;
• степень покрытия тестами компонентов и комплекса программ и допустимый уровень проявления дефектов и ошибок при их функционировании;
- требования к необходимым ресурсам на разработку, ввод в дейст вие и обеспечение функционирования при применении программного комплекса;
- требования, гарантирующие качество применения программного комплекса, обеспечение надежности и безопасности системы и внеш ней среды;
- обоснование выбора оптимального варианта требований к содер жанию и приоритетам реализации совокупности функций программ ного комплекса;
- требования к структуре, составу компонентов и интерфейсам с внешней средой и пользователями;
- требования к эффективности реализации выбранного варианта тре бований к программному комплексу по использованию доступных вычислительных ресурсов;
- требования к плану и срокам реализации требований к программ ному комплексу;
- требования к составу и содержанию эксплуатационной и техноло гической документации на программный комплекс, достаточной для его применения, сопровождения и модификации;
- требования к методам и программе испытаний, приемки системы и программного комплекса заказчиком;
- требования к средствам обучения и уровню квалификации специа листов пользователей программного продукта.
Лекция 1.6. Эталоны типов тестов и изменения требований… Лекция 1. ЭТАЛОНЫ ТИПОВ ТЕСТОВ И ИЗМЕНЕНИЯ ТРЕБОВАНИЙ К КОМПЛЕКСАМ ПРОГРАММ Формализация эталонов типов тестов программного комплекса и компонентов Объектами тестирования далее рассматриваются сложные комплексы программ для систем обработки информации и управле ния, разрабатываемые организованными коллективами (командами) квалифицированных специалистами разных категорий. Эталоны для тестирования включают процессы и объекты, которые определяют свойства, характеристики и качество компонентов и комплексов про грамм. Реализация тестирования может производиться разными ме тодами и независимыми специалистами – программистами, инте граторами и тестировщиками, что позволяет использовать результаты их деятельности для сравнения одних и тех же описаний программ, представленных на языках программирования и на языках описания эталонов – тестов.
Первичное описание и реализация программных компонентов, а также мышление их разработчиков (программистов) осуществля ется на основе требований, функций, характеристик структуры и ис полнения программ. Оно существенно отличается от представле ний и методов описаний тех же функций комплекса программ тестировщиками – создателями сценариев, процессов и типов эта лонов тестирования. Они акцентируют свою деятельность на кон кретных процедурах проверки функционирования, возможных ре зультатах и взаимодействии компонентов комплекса программ. Это позволяет выявлять дефекты и повышать качество путем сопоставле ния двух методов и результатов описания одних и тех же функций и характеристик программ за счет того, что мала вероятность одинако вых ошибок в сценариях и реализациях тестов и в описаниях требо ваний к функциям и характеристикам программ.
В.В. Липаев. Тестирование компонентов и комплексов программ Совокупности требований и описаний типов тестов могут при меняться как эталоны и вторая адекватная форма описаний функций и характеристик комплексов и компонентов программ.
Для обеспечения высокого качества программных комплексов и ком понентов стратегию создания тестов различных типов целесообразно строить, основываясь на требованиях к функциям и характери стикам комплексов программ (см. рис. 1.2). При разработке слож ных комплексов программ необходимо иметь пригодные для приме нения тестирования эталоны требования и/или сценарии исполь зования функций программных компонентов и комплекса. Такая вторая форма описаний содержания программ должна служить для сквозной верификации спецификаций требований к тестам сверху вниз, а также сами подвергаться верификации на корректность соот ветствия исходным требованиям к компонентам программ разного уровня.
Для обеспечения эффективности затрат ресурсов на тестирова ние компонентов и комплексов оно должно быть интегрировано как можно раньше с основными процессами проектирования, разработки и сопровождения в жизненном цикле программных комплексов. По существу, требования к программному компоненту и тесты для про верки их адекватности и полноты отражают один и тот же объ ект, но в разной форме. Поэтому сложность представительного опи сания тестов соизмерима со сложностью описания полной совокуп ности требований к функциям и характеристикам соответствующего программного компонента. Вследствие этого трудоемкость и другие ресурсы для разработки адекватных тестов должны соответство вать ресурсам и трудоемкости при создании и реализации коррект ных требований, определяющих полностью программный компонент.
Однако на практике обычно это не учитывается, и выделяемые на тестирование ресурсы оказываются значительно меньше и недоста точными для полноценного тестирования требований к компонентам программ, что определяет их не полное соответствие требованиям и недостаточное качество.
Для обеспечения высокого качества программного комплекса и компонента параллельно с верификацией требований и разработкой корректировок следует разрабатывать и верифицировать специфика ции и сценарии тестов, отражающие методы и конкретные проце дуры проверки реализации этих требований. Тестовые спецификации Лекция 1.6. Эталоны типов тестов и изменения требований… могут использоваться для проверки согласованности, внутренней не противоречивости и полноты реализации требований без исполнения программ. Для каждого требования к функциям программного ком плекса (компонента), его архитектуре должна быть разработана спе цификация требований к тестам, обеспечивающая проверку коррект ности, адекватности и возможности в последующем реализовать тес тирование на соответствие этому эталону. Такая взаимная проверка корректировок функций комплексов (компонентов), отраженных в требованиях и в спецификациях тестов, обеспечивает повышение их качества, сокращение дефектов, ошибок, неоднозначностей и проти воречий – рис. 1.8.
Тестовый эталон как продукт помогает организовать и скоор динировать усилия сотрудников, разрабатывающих и тестирующих программный комплекс. Однако многие тестовые эталоны не ограни чиваются этой исключительно важной задачей. Формат, структура и уровень детализации подобных эталонов типов тестов определяются не только соображениями эффективности тестирования, но и нормами, определяемыми спецификацией. Если разрабатывается программный продукт для военных систем, то обязательно должны поставляться тес товые эталоны заказчику и соответствующие их спецификации. То же самое касается и программных комплексов для медицины. Каждый из эталонов служит для поиска ошибок. Однако важно понимать, что даже если время, затраченное на его разработку, могло бы быть с большей производительностью использовано для анализа и тестирова ния программы, все равно придется выдержать стандарты и написать тестовый план и эталоны, полностью соответствующие требованиям заказчика или регулирующей организации на комплекс программ.
Тестовый эталон как инструмент содержится в требованиях официальных стандартов для планов тестирования, таких как ANSI/ IEEE 829. Это целый комплекс требований к спецификации тестовых эталонов, спецификации для самих тестов, журналам тестирования, разнообразным идентификаторам, к спецификации для тестовой про цедуры, спецификациям ввода/вывода, а также специальные проце дурные требования, зависимости между тестами, календарный план, описание распределения работ между персоналом, критерии приоста новки и возобновления тестирования.
В.В. Липаев. Тестирование компонентов и комплексов программ Эталоны типов тестов и изменения требований к комплексам программ должны включать:
формализацию эталонов типов тестов программного комплекса и компонентов:
• программные «оракулы» – неформальные знания и пред ставлений тестировщиков на основе опыта;
• модели потоков управления и потоков данных в модулях, компонентах и комплексе программ;
• реальные объекты внешней среды и системы, являющиеся источниками и потребителями информации;
• сценарии и наборы тестов от имитаторов на основе атте стованных моделей внешней среды;
• программные модели динамических объектов внешней среды, источники и потребители информации комплекса программ;
- формализацию документов как эталонов тестов комплексов про грамм:
• эксплуатационная документация как эталоны тестов;
• технологическая документация как эталоны тестов;
• совершенствование, контроль адекватности и качества эталонных тестовых документов при управлении проектом;
• контроль, обеспечение и гарантированное сохранение до кументации;
- управление изменениями требований к комплексам про грамм:
• квалификацию видов и причин изменения требований к комплексам программ;
• оценки стоимости изменения комплексов программ;
• планирование и утверждение изменений требований к комплексам программ;
- организацию изменений и сопровождения требований к ком плексам программ:
• стратегию сопровождения изменений требований к ком плексам программ;
• подготовку и специфицирование изменений требований к комплексам программ;
• определение ресурсов и состава специалистов для реали зации изменений требований к комплексам программ.
Рис. 1. Лекция 1.6. Эталоны типов тестов и изменения требований… Спецификации тестов должны обеспечивать дополнительный контроль корректности спецификаций требований к функциям и ве рификацию взаимодействия компонентов на соответствующем уров не описания комплекса программ. Разработка спецификаций тестов (эталонов) на основе спецификаций требований, создает базу для об наружения, какие требования не тестировались или принципиально не могут быть проверены тестированием. Таким образом, верифика ция спецификаций требований тестов к функциям и характери стикам программных компонентов могут использоваться с двумя це лями:
• для разработки и проверки программ и интерфейсов взаимо действия программных компонентов разных уровней в комплексе программ;
• для создания требований к скоординированному комплексу тестов для проверки совокупности компонентов, обеспечивающих взаимную проверку реализации спецификаций требований комплек сом программ.
Тестирование всегда предполагает компромисс между огра ниченными ресурсами и заданными сроками, с одной стороны, и практически неограниченными требованиями к качеству результатов тестирования и программных компонентов, с другой. Оценка стои мости и затрат, а также другие измерения процессов, связанных с оценкой ресурсов, необходимых для тестирования, как и оценка эко номической эффективности тестирования на разных этапах и уровнях, основывается на практиках менеджмента проектов и ис пользуется для оценки и улучшения процесса тестирования. Разные эталоны, концепции и модели тестирования требуют разных затрат по времени и необходимым ресурсам. Учет соответствия между стоимостью или затратами, необходимыми для того или иного метода и эффективности эталонов тестирования является обязательной ча стью современного управления проектами программных комплексов.
В зависимости от размера, сложности и назначения комплекса программ для тестирования могут применяться различные типы эта лонов, обеспечивающих обнаружение и устранение дефектов и оши бок (см. рис. 1.2):
- целостный комплекс требований к функциям, характеристикам, архитектуре и качеству тестов, адекватно отражающих и покрываю В.В. Липаев. Тестирование компонентов и комплексов программ щих полный набор требований заказчика или программного менед жера проекта к программным компонентам и комплексу;
- исходные объекты и процессы, которым должны соответствовать типы тестов, используемых для выявления дефектов и ошибок:
• программные «оракулы» – неформальные знания и представле ний тестировщиков на основе опыта создания предшествовавших аналогичных компонентов и комплексов программ в реализован ных проектах или специальных имитационных программах и пра вила их формирования;
• модели потоков управления и потоков данных, отражающие процессы последовательной обработки информации в компонен тах и комплексе программ;
• реальные объекты внешней среды и системы, являющиеся ис точниками и потребителями информации при применении ком плекса программ;
• сценарии, процедуры и данные от имитаторов динамических тестов на основе аттестованных моделей внешней среды;
• программные модели функционирования динамических объ ектов внешней среды, отражающие источники и потребителей ин формации комплекса программ;
• комплекты документации, отражающей все свойства, функ ции, характеристики и качество компонентов и комплекса про грамм, охваченный глубоким, детальным архивированием и кон фигурационным управлением исходных, промежуточных и от четных документов:
• эксплуатационная документация для пользователей, обеспе чивающая квалифицированное применение комплекса программ по назначению;
• технологическая документация, отражающая архитектуру, со держание компонентов и свойства комплекса, обеспечивающая возможность их модификации и развития.
Представление тестов программных компонентов и комплексов на базе достоверных и полных к ним требований, предполагает ис пользование трудоемких процессов формирования таких исходных эталонов. Это может быть необходимо при разработке программных компонентов для сложных комплексов программ с требованиями обеспечения и гарантирования высокого качества, надежности и безопасности функционирования критических систем. В более про Лекция 1.6. Эталоны типов тестов и изменения требований… стых проектах широко применяется более экономичный, полуфор мальный метод формирования тестов и выполнения тестирования на основе применения понятия тестовый «оракул».
Тестовый «оракул» – тип эталонов тестов для предсказания и оценки корректности поведения модуля или программного компонента, предназначенный для тестирования в определенных условиях. Предпола гается, что тестировщик благодаря личному опыту и квалификации знает, или имеет конкурирующую, действующую или предшествующую вер сию программы, которая может имитировать основные варианты кор ректного поведения новой программы, предназначенной для тестиро вания. Тестировщику доверяется принятие решения о том, является ли сообщение об ошибке при исполнении программы достоверным и ее необходимо корректировать. Большинство методов исследовательско го тестирования программных компонентов опирается в определенной степени на подходы, в которых в качестве «оракула» выступает тести ровщик, хотя опыт такого тестирования включает в себя также приме нение в качестве «оракулов» результатов функционирования предшест вующих аналогичных или «пилотных» моделей.
Когда документируется система тестов, то обычно пытаются точ но описывать предстоящее тестирование. Даже точный «оракул» не всегда может рассказать все, что желательно знать о поведении тес тируемой программы. Это относится к тестовым сценариям, начиная с исследовательских предположений и кончая написанными с помощью детальных сценариев последовательностей действий в тестах (скрип тов). Тестовые сценарии, зафиксированные в скриптах, определяют действия, данные и ожидаемые результаты с некоторой неопределен ностью. Неопределенность «оракула» – это, безусловно, нежелатель ное свойство при определении соответствия требованиям или рисков качества. В отличие от них, однозначные эталоны (требования) тес тирования поддерживают воспроизводимые тесты, что важно для регрессионного тестирования, они позволяют сделать интерпретацию результатов тестирования менее зависимыми от человека, выпол няющего тесты. Их можно контролировать, а другие специалисты могут изучить средства тестирования и понять, что и как было под вергнуто тестированию.
Следующие факторы, которые способствуют повышению каче ства, увеличению объемов документации и сложности тестов, целесо образно учитывать при тестировании по методу «оракулов»:
В.В. Липаев. Тестирование компонентов и комплексов программ • мозг человека способен обрабатывать одновременно только конечное число элементов информации, поэтому порядок, время и данные должны быть четко организованы при тестировании, требуют исчерпывающего документирования, чтобы убедиться, что нужные события в системе происходят в нужное время;
• тестовые сценарии и процедуры, которые находятся в голове только у одного человека, порождают организационный риск и риск управления для всей группы тестирования комплекса программ;
• потребность в регрессионном тестировании и последователь ной воспроизводимости тестов;
• потребность в формализации и стандартизации процесса тес тирования и документации на программные компоненты и комплек сы;
• уровень риска – системы с повышенными требованиями к безопасности и с особым целевым назначением должны работать очень точно при каждом использовании программ;
• жесткие временные рамки для выполнения тестов компонентов в комплексах реального времени;
• необходимость руководить неопытными тестировщиками и делиться знаниями – недостаточно квалифицированные специали сты при участии в тестировании системы, могут внести свою нега тивную лепту в процесс тестирования сложных критических систем.
Тестовое покрытие это отображение пространства варьиро вания тестов на некоторую совокупность эталонов к функциям и ха рактеристикам программ, предназначенных для тестирования. По крытие можно отражать с помощью матрицы, где по одной оси представлены тестовые эталонные сценарии, а по другой требуе мые функции, характеристики, безопасность или риски комплекса или компонентов программ. При этом можно отслеживать степень покрытия эталона тестами, поддерживаемыми конфигурацией и сце нариями использования программного компонента или комплекса.
Подобные модели могут фиксировать потоки управления и/или по токи данных компонента, последовательность состояний, в кото рых может находиться программный компонент или комплекс и по следовательность их обработки.
Можно проводить оценку степени покрытия требований относи тельно этих моделей, проверяя, что каждому узлу и каждой связи в графе соответствует тестовый сценарий. Оценка покрытия требует Лекция 1.6. Эталоны типов тестов и изменения требований… учета, в какой степени тесты нацелены на пространство требуемых функций и характеристик программного компонента или комплекса.
Точность определения степени покрытия ограничена, но выделение сильных и слабых связей между тестами и пространством требований к функциям и характеристикам компонента позволяет акцентировать анализ на безопасности, допустимых рисках или некоторых характе ристиках, особенно важных для конкретного проекта.
Однако точные сценарии и типы тестов на базе эталонных требо ваний имеют обратную сторону. Описание точного тестового сценария обычно очень многословное и сложное. Чем точнее и полнее доку ментированы требования и сценарии тестирования, тем точнее должно быть предвидение о качестве исполнения программного ком понента. Точность способствует повторному использованию тестов при регрессионном тестировании и предполагает также возможность сопровождения и модернизации тестов. Чем более точно подготовле ны сценарии тестирования и эталоны, тем больше усилий требуется для их изменения, когда в тестируемую программу вносятся корректи ровки.
Данные натурных экспериментов с объектами внешней среды в качестве требований и тестов могут подготавливаться заранее вне сеансов динамического тестирования программного комплекса, на пример, при отладке аппаратной части системы обработки информа ции. Эти данные отражают характеристики и динамику функциони рования объектов, которые трудно или опасно подключать для непо средственного взаимодействия с недостаточно проверенными про граммами. Кроме того, такие данные могут использоваться для атте стации адекватности имитаторов некоторых объектов внешней среды.
Они могут быть полезны в тех случаях, когда создание определенных условий динамического функционирования объектов внешней среды очень дорого или опасно и может быть выполнено только в исключи тельных случаях.
В отличие от натурного эксперимента моделирование внешней среды и динамических тестов на ЭВМ имеет большие возможности контроля, как исходных данных, так и всех промежуточных и выход ных результатов функционирования тестируемого программного комплекса или компонента. В реальных системах ряд компонентов иногда оказывается недоступным для контроля их состояния, так как либо невозможно поместить измерители контролируемых сигналов в В.В. Липаев. Тестирование компонентов и комплексов программ реальные подсистемы, подлежащие тестированию, либо это сопряже но с изменением характеристик самого анализируемого объекта.
Преимуществом моделирования внешней среды на ЭВМ является также повторяемость результатов функционирования и возможность исследования большого количества вариантов и сценариев тестиро вания. В отличие от этого натурные эксперименты зачастую невоз можно остановить на некоторой промежуточной фазе или повторить с абсолютно теми же исходными данными.
Программная имитация динамических тестов внешней сре ды на ЭВМ в реальном времени позволяет:
• проводить длительное непрерывное генерирование имитируе мых эталонных тестов для определения характеристик функциониро вания комплекса программ в широком диапазоне изменения условий и параметров, что зачастую невозможно при использовании реальных объектов;
• расширять диапазоны характеристик имитируемых объектов за пределы реально существующих или доступных источников дан ных, а также генерировать динамические потоки информации, отра жающие перспективные характеристики создаваемых информацион ных систем и объектов внешней среды;
• создавать тестовые эталоны, соответствующие критическим или опасным ситуациям функционирования объектов внешней среды, которые невозможно или рискованно реализовать при натурных экс периментах;
• обеспечивать высокую повторяемость имитируемых тестов при заданных условиях их генерации и возможность прекращения или приостановки имитации на любых фазах моделирования внешней среды.

Content-Type: text/html; charset=WINDOWS-1251


markdown:
Nh√¢n d·ªãp khai tr∆∞∆°ng c·ª≠a h√†ng ƒëang c√≥ nhi·ªÅu ch∆∞∆°ng tr√¨nh khuy·∫øn m√£i h·∫•p d·∫´n. Dunkin' Donuts ƒë∆∞·ª£c th√†nh l·∫≠p nƒÉm 1950 t·∫°i Quincy, Massachusetts v·ªõi m·ªôt nh√† h√†ng chuy√™n ph·ª•c v·ª• c√† ph√™ ch·∫•t l∆∞·ª£ng cao v√† b√°nh donut tuy·ªát h·∫£o.
ƒê·∫øn nay, Dunkin' Donuts ƒë√£ c√≥ m·∫∑t t·∫°i 32 qu·ªëc gia v·ªõi kho·∫£ng 10.800 nh√† h√†ng ·ªü kh·∫Øp n∆°i tr√™n th·∫ø gi·ªõi v√† n·∫±m trong top 10 th∆∞∆°ng hi·ªáu fastfood-th·ª©c ƒÉn nhanh ƒë∆∞·ª£c y√™u th√≠ch nh·∫•t t·∫°i M·ªπ. M·ªói nƒÉm, Dunkin' Donuts b√°n ra h∆°n 1,7 t·ª∑ c·ªëc c√† ph√™ v√† ƒë∆∞·ª£c vinh d·ª± l·ªçt v√†o top 10 th∆∞∆°ng hi·ªáu ƒë·ªì ƒÉn v√† th·ª©c u·ªëng ƒë∆∞·ª£c y√™u th√≠ch nh·∫•t t·∫°i th·ªã tr∆∞·ªùng M·ªπ.
Th·ª±c ƒë∆°n phong ph√∫ v√† ƒëa d·∫°ng
T·∫°i Vi·ªát Nam, sau th·ªùi gian nghi√™n c·ª©u kh·∫©u v·ªã c·ªßa th·ª±c kh√°ch b·∫£n ƒë·ªãa, Dunkin' Donuts tin r·∫±ng, t·ª´ ngh·ªá thu·∫≠t pha ch·∫ø c√† ph√™ ƒë·∫∑c bi·ªát c·ªßa "nh√†" Dunkin' Donuts c√πng nh·ªØng chi·∫øc b√°nh t∆∞∆°i ngon ƒë∆∞·ª£c ra l√≤ v·ªõi c√¥ng th·ª©c ƒë·∫∑c tr∆∞ng, h·ª©a h·∫πn s·∫Ω mang ƒë·∫øn s·ª± h√†i l√≤ng tuy·ªát ƒë·ªëi khi cung c·∫•p nh·ªØng s·∫£n ph·∫©m c√≥ ch·∫•t l∆∞·ª£ng h√†ng ƒë·∫ßu th·∫ø gi·ªõi cho c√°c th·ª±c kh√°ch Vi·ªát s√†nh ƒëi·ªáu.
Sau th√†nh c√¥ng v·ªõi c·ª≠a h√†ng ƒë·∫ßu ti√™n khai tr∆∞∆°ng t·∫°i 59 Nguy·ªÖn ƒê·ª©c C·∫£nh, Ph∆∞·ªùng T√¢n Phong, Qu·∫≠n 7 (Tp.HCM), Dunkin's Donuts Ra m·∫Øt c·ª≠a h√†ng th·ª© 2 t·∫°i 195 ‚Äì 197 Phan X√≠ch Long, Ph∆∞·ªùng 2, Qu·∫≠n Ph√∫ Nhu·∫≠n nh·∫±m ƒë√°p ·ª©ng nhu c·∫ßu kh√°ch h√†ng.
Coolatta¬Æ v√† Frozen Dunkaccino¬Æ.
Dunkin' Donuts v√† C√¥ng ty VFBS c≈©ng ƒë√£ l√†m vi·ªác ch·∫∑t ch·∫Ω v·ªõi nhau ƒë·ªÉ ra m·∫Øt th·ª±c ƒë∆°n phong ph√∫, ƒëa d·∫°ng v√† ph√π h·ª£p v·ªõi kh·∫©u v·ªã c·ªßa ng∆∞·ªùi Vi·ªát Nam, bao g·ªìm c√† ph√™ ch·∫•t l∆∞·ª£ng cao nh·∫•t, nhi·ªÅu lo·∫°i b√°nh donut cho m√πa l·ªÖ h·ªôi, b√°nh Donut Sandwich ƒë·ªôc ƒë√°o v·ª´a m·∫∑n v·ª´a ng·ªçt ch·ªâ c√≥ duy nh·∫•t t·∫°i Dunkin' Donuts v√† c√°c th·ª©c u·ªëng ƒë·ªôc ƒë√°o kh√°c nh∆∞ Coolatta¬Æ v√† Frozen Dunkaccino¬Æ.
Ngo√†i ra, c·ª≠a h√†ng c√≤n ra m·∫Øt c√°c s·∫£n ph·∫©m th√¢n thu·ªôc v·ªõi th·ªã tr∆∞·ªùng c√† ph√™ "truy·ªÅn th·ªëng" Vi·ªát Nam nh∆∞ c√† ph√™ ƒë√°, c√† ph√™ s·ªØa ƒë√°, ƒë·∫∑c bi·ªát Suadaccino, c√† ph√™ s·ªØa ƒë√° xay ƒë∆∞·ª£c thi·∫øt k·∫ø ri√™ng cho th·ªã tr∆∞·ªùng Vi·ªát Nam.
C·ª≠a h√†ng th·ª© 2 b·∫Øt ƒë·∫ßu ƒëi v√†o ho·∫°t ƒë·ªông
ƒê·ªÉ ch√†o m·ª´ng s·ª± ki·ªán ra m·∫Øt c·ª≠a h√†ng Dunkin' Donuts khai tr∆∞∆°ng, kh√°ch h√†ng c√≥ th·ªÉ mua 6 b√°nh donuts, t·∫∑ng 6 b√°nh donuts v·ªõi gi√° 90,000 VND, ngo√†i ra khi mua c√°c m·ªôt lo·∫°i n∆∞·ªõc u·ªëng b·∫•t k·ª≥, kh√°ch h√†ng s·∫Ω ƒë∆∞·ª£c th∆∞·ªüng th·ª©c 1 b√°nh donut b·∫•t k·ª≥ ch∆∞∆°ng tr√¨nh ch√≠nh th·ª©c b·∫Øt ƒë·∫ßu t·ª´ ng√†y 27/12/2013 ƒë·∫øn h·∫øt 07/01/2014.
Theo Tri·ªáu Minh (Theo B√°o ƒê·∫•t Vi·ªát)

WARC-Type: response

Content-Type: application/http; msgtype=response

WARC-Identified-Payload-Type: text/html

Connection: close

Pragma: no-cache

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Set-Cookie: f43ef07555d0dd7ad70bd7202342ca87=061pnlk7mgrgd9hn2r3mhllqj1; path=/; domain=www.marketingchienluoc.com; HttpOnly

Vary: Accept-Encoding,User-Agent

Content-Type: text/html; charset=utf-8


markdown:
Đã từng hai lần đề nghị mua lại cổ phần chi phối của Sabeco với mức giá hàng tỷ USD và đều bị từ chối, nhưng lần này hãng bia lớn nhất Thái Lan, ThaiBev, đang có một cơ hội lớn để trở thành ông chủ mới của Sabeco.
Hiện tại Sabeco đang chiếm tới hơn 41% thị phần
Chỉ ít ngày sau khi Hiệp hội Các nhà đầu tư tài chính Việt Nam (VAFI) gửi kiến nghị lên Bộ Công thương, đề nghị niêm yết Tổng Công ty Bia – Rượu – Nước giải khát Sài Gòn (Sabeco) lên sàn chứng khoán, Bộ Công Thương và Sabeco đã trình Chính phủ phương án bán cổ phần. Cụ thể, Nhà nước sẽ tiếp tục bán đấu giá công khai 53% cổ phần tại Sabeco cho nhà đầu tư nhân.
# Tiềm năng của Sabeco
Cần phải nhắc lại rằng dù đã được cổ phần hóa cách đây 8 năm, nhưng tỷ lệ vốn Nhà nước nắm giữ tại Sabeco vẫn rất lớn, 90%. Với tỷ lệ đó, Sabeco vẫn hoàn toàn nằm dưới sự chi phối của Nhà nước. Nếu như toàn bộ số vốn được rút theo kế hoạch, tỷ lệ nắm giữ cổ phần của Nhà nước tại Sabeco sẽ hạ xuống 36%, từ mức 90% hiện nay.
Hiện tại vẫn chưa biết đến khi nào Chính phủ sẽ thông qua đề xuất trên, nhưng chắc chắn rằng thông tin này đang thu hút rất nhiều sự quan tâm của các nhà đầu tư, cả trong và ngoài nước. Bằng chứng là trong những năm qua, dù kế hoạch tiếp tục thoái vốn của Sabeco chưa được Chính phủ chấp thuận, đã có rất nhiều nhà đầu tư đánh tiếng muốn mua cổ phần của Sabeco. Trong đó có một số tên tuổi nổi tiếng trong ngành công nghiệp bia như Ashahi, Heineken, SAB Miller và ThaiBev.
Có thể nói rằng trong ngành công nghiệp sản xuất bia ở Việt Nam, Sabeco chính là DN hấp dẫn nhất mà bất cứ nhà đầu tư nào cũng muốn nắm cổ phần trong đó. Đó là bởi vì hiện tại Sabeco đang chiếm tới 46% thị phần. Một điều quan trọng nữa là tiềm năng tăng trưởng của Sabeco và sự mở rộng về quy mô thị trường vẫn còn rất lớn. Theo báo cáo của Hiệp hội Bia-Rượu-Nước giải khát, Việt Nam hiện đứng thứ 5 về tiêu thụ bia tại Châu Á.
ThaiBev đang đứng trước cơ hội lớn hơn nếu Chính phủ chính thức phê duyệt bán 53% cổ phần Sabeco trong một lần đấu giá công khai.
# Cơ hội của ThaiBev
Trong số các nhà đầu tư đã từng đánh tiếng muốn đầu tư vào Sabeco, ThaiBev đang nổi lên là một trong những ứng viên tiềm năng nhất. ThaiBev hiện là một trong những hãng bia lớn nhất Thái Lan, thuộc sở hữu của tỷ phú Charoen Sirivadhanabhakdi – người cũng là chủ sở hữu tập đoàn TCC Holdings đã thâu tóm thành công Metro Cash – Carry Việt Nam hồi cuối năm ngoái.
Nói ThaiBev là một trong những nhà đầu tư tiềm năng nhất là vì tập đoàn này không hề giấu giếm mong muốn nắm giữ cổ phần chi phối tại Sabeco trong suốt hai năm qua. Năm 2014, ThaiBev đã từng đưa ra đề nghị mua lại 53% cổ phần của Sabeco với số tiền lên tới 2 tỷ USD nhưng không thành công. Tới đầu năm 2015, hãng bia này tiếp tục đưa ra một giao dịch mới trị giá 1 tỷ USD cho 40% cổ phần của Sabeco và tiếp tục bị từ chối.
Tuy nhiên, lần này ThaiBev đang đứng trước cơ hội lớn hơn nếu Chính phủ chính thức phê duyệt bán 53% cổ phần Sabeco trong một lần đấu giá công khai.
Và một điều dễ nhận thấy sau hai lần ra giá đòi mua cổ phần chi phối của Sabeco, ThaiBev dường như đã sẵn sàng trả giá rất cao để thâu tóm hãng bia nội này, để chính thức đặt chân vào thị trường Việt Nam theo một cách không thể nhanh hơn.
Mở rộng sự hiện diện ra thị trường nước ngoài đã là một chiến lược được ThaiBev thực hiện từ lâu. Tập đoàn này từng lên kế hoạch một nửa doanh thu sẽ đến từ thị trường bên ngoài Thái Lan vào năm 2020, tăng so với hiện tại là 30%. Phần lớn doanh thu đó sẽ đến từ khu vực ASEAN, sau khi Cộng đồng kinh tế chung ASEAN được thành lập từ ngày 31/12/2016, tạo ra một thị trường thống nhất với 600 triệu dân.
Trong một lần trả lời phỏng vấn hãng tin Nikkei hồi tháng Một vừa qua, ông Thapana Sirivadhanabkakdi chia sẻ rằng Việt Nam là thị trường mà ThaiBev mong muốn mở rộng nhất trong khu vực ASEAN.
“Thị trường này đã được thiết lập tốt, có quy mô lớn với hơn 90 triệu dân và có một hệ thống cơ sở hạ tầng vững chắc,” ông Thapana nói. “Tất cả mọi người đang tham gia tìm kiếm cơ hội ở đây,” ông nhấn mạnh.
Trong quá khứ, ThaiBev cũng đã mở rộng sự hiện diện của mình trên thị trường bằng chiến lược mua bán và sát nhập (M&A). Năm 2003, tỷ phú Charoen Sirivadhanabhakdi, bố của ông Thapana, đã sát nhập tất cả các thương hiệu đồ uống có cồn của ông để tạo ra một tập đoàn lớn là ThaiBev bây giờ. Năm 2008, ThaiBev đã thâu tóm Oishi, tiếp theo đó là Serm Suk. Cả hai thương hiệu này đều của Thái Lan. Hiện ThaiBev cùng với TCC Assets cũng đã nắm hoàn toàn F&N bằng cách mua lại cổ phần của Lippo Group của Indonesia. Vào thời điểm hiện tại, ThaiBev cũng đang sở hữu 11% cổ phần của Vinamilk thông qua F&N.
Với kinh nghiệm M&A như trên, cùng với mong muốn đã được thể hiện trước đó, rất có thể ThaiBev sẽ là người chiến thắng trong cuộc đua làm chủ Sabeco sắp tới.
Ngọc Linh
Theo Enternews

Set-Cookie: f43ef07555d0dd7ad70bd7202342ca87=g1bbhs0a0uahfv7q33ef97uu10; path=/; domain=www.marketingchienluoc.com; HttpOnly


markdown:
Ai cũng có một ước mơ khởi nghiệp kinh doanh nhưng rất nhiều bài học phải trả giá ở phía trước dành cho một startup. Nếu bạn đang nghĩ về việc bắt đầu ý tưởng kinh doanh của mình, hãy chắc chắn rằng bạn tránh xa những sai lầm sau, nếu không việc kinh doanh của bạn có thể sẽ thất bại.
Vân Anh
Theo nhuongquyenvietnam.com

Set-Cookie: f43ef07555d0dd7ad70bd7202342ca87=3edj80aipjb112a8fpjqmvdmo6; path=/; domain=www.marketingchienluoc.com; HttpOnly


markdown:
Trang chủ
Nhà đất
Kho xưởng cho thuê
Nhà xưởng
Huyện Thanh Oai
Thông tin của bạn sẽ được gửi trực tiếp cho Ocean Bank, sau đó sẽ có nhân viên hỗ trợ bạn trong vòng 2 giờ làm việc.
Xin cho biết họ tên quý vị
Xin cho biết số điện thoại của quý vị
Xin cho biết địa chỉ của quý vị
18
5
2
1
Về MuaBanNhaDat | Nhận bản tin | FAQ | Điều khoản thỏa thuận | Bản quyền | Quy chế Sàn GDTMĐT | Tuyên bố từ chối bảo đảm | Liên hệ | Tuyển dụng | Bảng giá dịch vụ | Sitemap
MuaBanNhaDat © 2007 - 2016. Ghi rõ nguồn "MuaBanNhaDat.vn" khi phát hành lại thông tin từ website này.
CÔNG TY TNHH DỊCH VỤ QUẢNG CÁO VÀ TRUYỀN THÔNG CHÂU Á
Số giấy phép kinh doanh: 0308967985, Nơi cấp: Sở Kế hoạch và Đầu tư Tp. Hồ Chí Minh.
Ngày cấp: 10/6/2009
Địa chỉ: Lầu 3 Tòa nhà Copac, Số 12, Tôn Đản, Phường 13, Quận 4, TP.HCM
Follow us on Facebook Linkedin Google+
Technology powered by - Copyright ©2016 by Ringier Vietnam

Server: nginx

Cache-Control: private

X-Frame-Options: SAMEORIGIN

X-Cache-Status: STALE


markdown:
# Internet Download Manager 6.28.build 3 Full ( Update Version ) - Phần mềm Hỗ trợ Tăng tốc Download
**Internet Download Manager 6.28build03 Full**- **Phần mềm Hỗ trợ Tăng tốc download cần thiết nhất.** __Giới thiệu:__ **Internet Download Manager**( IDM) là một công cụ hỗ trợ **tăng tốc**và **quản lý tải xuống**các tập tin được tải từ mạng xuống, chỉ có mặt trên hệ điều hành Microsoft Windows.
Bản dùng thử của chương trình cho phép dùng trong
**30**ngày.
Ở bài trước đã giới thiệu:
Hiện nay IDM đã ra bản 6.28build3 để update làm như sau:
Cách 1: Download IDM từ trang chủ và cài đặt, link ở bài viết trước phía trên
Cách 2: Cập nhật trực tiếp trong IDM: Vào Help > Update new version.
Trường hợp nếu mấtt Active bạn làm theo 1 trong 3 cách : cách 1 và cách 2 bài trước đã hướng dẫn chi tiết
[tại đây](https://nccsupport.blogspot.com/2017/03/internet-download-manager-62801-full.html)
Cách 3 là sử dụng tool trial reset - dùng thử và mãi mãi.
*(Link download cuối bài viết)*
Các bạn làm theo hình như bên dươi.
Giải nén chuột phải run as administrator
pass: nccsupport.blogspot.com
**Chúc các bạn thành công !** __Từ khóa:__Internet download manager full, idm new version, idm mới nhất, idm full crack, internet download manager, Update version
## Post a Comment

WARC-Identified-Payload-Type: application/xhtml+xml

Server: GSE

X-Content-Type-Options: nosniff

X-Robots-Tag: all,noodp

Cache-Control: private, max-age=0

X-XSS-Protection: 1; mode=block

Content-Type: text/html; charset=UTF-8


markdown:
# Tạo Form Hỗ trợ trực tuyến Facebook cho website
Chào các bạn, hôm nay mình sẽ giới thiệu một kiểu Chat mới, dựa trên nền tảng Facebook. Ở phiên bản này thì bất cứ khách truy cập nào đã đăng nhập Facebook đều có thể gửi tin nhắn đến Fanpage của bạn mà không cần phải like Fanpage.
Ok, các bạn dùng đoạn code sau nhé:

Và đoạn code này:

Thay link đánh dấu màu xanh thành link Fanpage facebook của bạn là được
Hỗ trợ trực tuyến

Hỗ trợ trực tuyến

Các bạn có thể đặt đoạn code 1 ở trong phần Header của website, còn đoạn code 2 thì cho vào trước thẻ  là được.
Hi vọng tính năng này có ích đối với bạn.
**Xem thêm :** *Updating ...*
## Post a Comment


markdown:
Dưới đây là 8 scandal gây ầm ĩ nhất trong năm qua của các cuộc thi hoa hậu trên thế giới:
**1. Jenna Talackova - thí sinh chuyển giới đầu tiên dự thi hoa hậu**
Jenna Talackova thu hút sự chú ý của truyền thông tại cuộc thi Hoa hậu Canada khi cô bị phát hiện là một thí sinh chuyển giới. Đây là một thông lệ chưa từng có trong các cuộc thi nhan sắc chính thống chính vì thế Jenna Talackova đã suýt bị đuổi khỏi cuộc thi nếu như không có sự lên tiếng ủng hộ của khán giả. Và cũng chính từ sự kiện này, Tổ chức hoa hậu hoàn vũ thế giới đã cho phép thí sinh chuyển giới dự thi các cuộc thi nhan sắc quốc tế như Hoa hậu thế giới, Hoa hậu hoàn vũ. Đây có thể xem là một bước tiến cởi mở của các cuộc thi sắc đẹp.
**2. Thí sinh tố cáo Miss USA gian lận**
Sau khi bị loại khỏi cuộc thi Miss USA 2012, Hoa hậu bang Pennsylvania, Sheena Monnin đã tố cáo cuộc thi dàn xếp kết quả. Trước động thái này của Sheena Monnin, người sáng lập tổ chức Miss Universe là Donal Trump đã vô cùng tức giận và tuyên bố sẽ kiện Sheena nếu như cô không xin lỗi. Tiếp theo đó, trên trang Facebook cá nhân, Sheena Monnin tuyên bố từ bỏ vương miện Pennsylvania vì cho rằng, cuộc thi Miss USA mà cô tham gia với tư cách đại diện cho bang Pennsylvania là "gian lận, vi phạm đạo đức, mâu thuẫn và có nhiều hành vi không trung thực".
**3. 2012 - một năm thắng lớn của các nước chủ nhà**
Đây là một trong những lùm xùm được bàn tán nhiều nhất trong năm qua. Chuyện người đẹp đăng quang trên chính đất nước mình sẽ chẳng có gì đáng nói nếu như các thí sinh đó có phần không xứng đáng với danh hiệu được giao. Có thể kể đến trường hợp người đẹp Vu Văn Hà kém tiếng Anh đăng quang Hoa hậu thế giới được tổ chức tại Trung Quốc, thí sinh Ikumi Yoshimatsu sở hữu nhan sắc bậc trung lên ngôi Hoa hậu quốc tế, tổ chức tại Nhật Bản, và mới đây nhất là Olivia Culpo đăng quang Hoa hậu hoàn vũ tại Mỹ chỉ với chiều cao 1m67. Với những lựa chọn này nhiều người đã tỏ ra nghi ngờ với tính chân thực của các cuộc thi nhan sắc.
**4. Natalia Pereverzeva - nữ hoàng của các scandal**
Natalia Pereverzeva tham dự cuộc thi Hoa hậu trái đất được tổ chức vào tháng 11 năm nay. Tuy nhiên thay vì nghĩ đến hình ảnh của một người đẹp Nga sở hữu gương mặt hút hồn thì người ta lại nhớ nhiều hơn đến những scandal mà cô gây ra tại cuộc thi này. Đầu tiên là loạt những hình ảnh nóng của cô trên tạp chí Playboy bị độc giả gửi đến ban tổ chức. Tiếp theo đó là phần trình diễn không thành công của cô trong đêm chung kết khi bị ngã nhào trên sân khấu. Và scandal cuối cùng và cũng ầm ĩ nhất là khi cô có những lời lẽ chê bai chính quốc gia của mình.
**5. Thí sinh Mr Worl bị băt gặp yêu đồng tính**
Cuộc thi Mr World diễn ra vào hồi đầu tháng 11 và scandal duy nhất liên quan đến việc 2 thí sinh bị bắt gặp yêu đồng giới trong một căn phòng kín. Hai nhân vật trong scandal chính là thí sinh của Venezuela (Jesus Sambrano) và Bỉ (Gianni Sennesael).
**6. HH Nam Sudan miệt thị dân đồng tính**
Cuộc thi Hoa hậu trái đất năm nay có khá nhiều scandal. Ngoài scandal ảnh nóng của HH Nga thì HH Nam Sudan khiến dư luận phẫn nộ, đặc biệt là dân đồng tính khi có những phát biểu miệt thị dân đồng tính trong khi cuộc thi đang được tổ chức tại Thái Lan, nơi vốn được biết đến là thế giới của người đồng tính và chuyển giới. Lời dẫn cô viết trên trang cá tính của mình như sau: 'Châu Á là một thế giới của đồng tính nam và đồng tính nữ... Thật tồi tệ'.
**7. Một năm nhiều phế truất**
Việc truất ngôi của một hoa hậu không còn lạ gì trong các cuộc thi nhan sắc. Tuy nhiên, chưa có năm nào việc phế truất lại tái diễn nhiều như năm này. Những sự vụ ầm ĩ nhất có thể khoa hậu Serbia đã bị tước ngôi hậu khi bị phát hiện đã từng kết hôn và chụp ảnh nóng, Hoa hậu Hoàn vũ New Zealand, Avianca Boh, buộc phải trả lại vương miện khi cô vẫn mang quốc tịch Nam Phi, HH Bulgaria bị truất ngôi vì gian lận trong phiếu bình chọn, HH Fiji bị tước vương miện vì chưa đủ tuổi còn 2 hoa hậu Dominica và CH Ai-len bị truất ngôi vì quá tuổi.
**8. HH Ấn Độ, Shilpa Singh lên ngôi bất ngờ**
Năm nay, Miss Ấn Độ cũng dính vào vụ lùm xùm phế truất khi Hoa hậu Urvashi Rautela bị phát hiện dự thi ở lứa tuổi vị thành niên. Và với scandal này Á hậu 1, Shilpa Singh bất ngờ lên ngôi Hoa hậu Ấn Độ 2012. Sự phế truất này gây ra nhiều phản đối gay gắt từ cộng đồng mạng khi Urvashi đã được xem như một ứng viên vô cùng sáng giá cho top đầu trong cuộc thi HHHV 2012. Cô được nhiều người ví như một thánh nữ trong khi đó Á hậu 1 Shilpa lại sở hữu nhan sắc bậc trung.
**Mai Nguyên** * (theo Eva)*

WARC-Truncated: length

X-Cache: MISS

Cache-Control: max-age=0, must-revalidate, no-transform, no-cache, no-store


markdown:
Đây là thông tin được tổng giám đốc Tổng công ty Điện lực Dầu khí (PV Power) Vũ Huy Quang cho biết tại họp báo kế hoạch sản xuất kinh doanh 2013, ngày 5/2.
Cũng theo lãnh đạo PV Power, trong năm 2012, Tổng công ty sẽ bị lỗ nếu như hạch toán đủ cả khoản lãi vay phải trả phát sinh từ khoản dư nợ tiền điện mà Tập đoàn Điện lực Việt Nam (EVN) vẫn chưa thanh toán.
*Theo hợp đồng được ký giữa EVN và Petro Vietnam, đến thời điểm này, khoản lãi chậm trả của EVN với Petro Vietnam đã lên tới gần 3.000 tỷ đồng.*
Tuy nhiên, để đảm bảo nhiệm vụ phát điện được giao, PV Power phải vay vốn lưu động là 10.250 tỷ đồng của Tổng công ty Tài chính Cổ phần Dầu khí (PVFC) để thanh toán chi phí nhiên liệu cho PV Gas, PV oil, trong đó lãi vay phải trả cho PVFC trong năm 2012 là gần 1.400 tỷ.
Vì vậy, mặc dù lợi nhuận sau thuế năm 2012 của PV Power là 716 tỷ đồng nhưng trên thực tế, nếu hạch toán đủ cả khoản lãi vay phải trả này, PV Power bị lỗ hơn 1.000 tỷ đồng.
Ông Quang cũng cho biết, theo hợp đồng được ký giữa EVN và Petro Vietnam, đến thời điểm này, khoản lãi chậm trả của EVN với Petro Vietnam đã lên tới gần 3.000 tỷ đồng.
Năm 2013, PV Power dự kiến sản xuất trên 14 tỷ kWh điện, hoàn thành công tác xây dựng nhà máy thủy điện Hủa Na vào quý 1/2013, phát điện tổ máy số 1 thủy điện Đăkring vào quý 4/2013, phát điện tổ máy số 1 Nhiệt điện Vũng Áng 1 vào tháng 9/2013.
Theo
*VNE*