Отчет по практике. Отчет по производственной практике Управление качеством продукции на иностранном предприятии epam systems

• Название: Отчет по производственной практике Управление качеством продукции на иностранном предприятии epam systems
• Анкор: Отчет по практике
• Дата: 04.07.2022
• Размер: 185.67 Kb.
• Имя файла: 542913.rtf
• Тип: Отчет; #623929
• страница: 2 из 2

2. Качество продукции.

.1 Система стандартов, используемых на предприятии
Сертификация производственных процессов..

Производственные процессы EPAM Systems сертифицированы в соответствии с требованиями ISO 9001:2000 (ИСО-9001:2000.) и SEI CMMI Level 4.

Стандарты ISO серии 9000 - Стандарты международной организации по стандартизации ISO являются наиболее известными и распространенными в мире . Стандарты ISO универсальны , их можно применять в качестве моделей независимо от отрасли , в которой функционирует компания . Такой подход, очевидно, имеет свои преимущества и недостатки. Основным преимуществом моделей ISO серии 9000 является их известность , распространенность , признание на мировом уровне , большое количество экспертов и аудиторов и невысокая стоимость услуг по сертификации . Универсальность же моделей ISO серии 9000 содержит в себе определенные недостатки : они являются достаточно высокоуровневыми . В модели лишь упоминаются требования, которые должны быть реализованы , но не говорится о том , как это можно сделать. Это связано с тем, что для того, чтобы рекомендовать абстрактному предприятию способы реализации и зафиксировать необходимые рекомендации по выполнению требований , необходимо конкретизировать :

• сферу деятельности организации ;

• специфику ее процессов ;

• специфику культуры предприятия ;

• структуру управления , существующую в компании (матричная , иерархическая проектная ) и другие особенности , свойственные компании .

Поэтому для построения полноценной системы качества по ISO необходимо помимо основной модели ISO 9001 (1994 или 2000 года ), которая создавался как модель, по которой необходимо проводить оценку , а не модель для внедрение системы качества использовать вспомогательные отраслевые и рекомендательные стандарты . Для организации , занимающейся разработкой программного обеспечения , таким стандартами являются : ISO 9004-1:94 (ISO 9004:2000), ISO 8402:94 (ISO 9000:2000), ISO 9000-3:91, ISO 10007:95, ISO 10013:95, ISO 12207:95.(Capability Maturity Model Integration) - международный стандарт качества, оценивающий уровень процессов разработки и сопровождения программного обеспечения. CMMI был разработан в 90-е годы Институтом разработки программного обеспечения (Software Engineering Institute, SEI) при университете Карнеги-Меллона (Carnegie Mellon University). CMMI предусматривает пять уровней зрелости компании. Для достижения каждого (кроме первого) необходимо выполнить условия по приведению всех процессов, происходящих в организации, к максимальному соответствию установленным критериям качества. Например, для сертификации на 4 уровень требуется четко определить все процессы производства и описать правила их адаптации к условиям конкретных проектов. Кроме того, управление компанией в целом и проектами в частности должно базироваться на количественном анализе данных об осуществлении процессов. Наличие сертификата CMMI 4 - подтверждение того, что в организации существуют документально оформленные и, следовательно, предсказуемые процессы разработки программного обеспечения, созданные на базе многолетнего опыта работы компании и соответствующие международным требованиям. CMMI 4 подразумевает, что процессы постоянно контролируются, оцениваются и сравниваются со стандартными показателями и лучшими практиками. Это позволяет гарантировать клиентам своевременное и эффективное выполнение проектов, а также высокое качество разрабатываемого ПО.устанавливает жесткие требования к соблюдению процессов в компании, а SEI постоянно их контролирует. Компания должна иметь стабильные процессы управления, которые позволяют четко планировать и получать прогнозируемый результат. Более того, формируются метрики и инструменты (например, EPAM Project Management Center), которые помогают максимально эффективно предотвращать и устранять возможные сбои в процессе разработки. По сравнению с широко известным стандартом ISO требования стандарта СMMI создавались специально для компаний, ведущих крупные ИТ-проекты. CMMI описывает методы управления и совершенствования процессов разработки ПО, в то время как ISO выдвигает более общие требования по управлению качеством в любой компании любой отрасли. Кроме того, СMMI более четко дифференцирует уровень управления качеством в компании в соответствии с уровнем ее зрелости. ISO же не предполагает никаких уровней зрелости компании, что во многом затрудняет определение "истинных" возможностей компании и, соответственно, путей ее дальнейшего развития.
.2 Принципы управления качеством, принятые в компании EPAM Systems
В основу деятельности компании положены восемь принципов системы менеджмента качества, охватывающие все имеющиеся в компании стадии разработки программного продукта:

• Ориентация на потребителя - компания зависит от своих заказчиков и поэтому должна понимать настоящие и будущие потребности заказчика, выполнять требования заказчика и стремиться превзойти ожидания заказчика

Применение принципа «Ориентация на потребителя» - это осуществление в компании деятельности, направленной на:

• Изучение и понимание потребностей и ожиданий заказчика

• Изучение потребностей других заинтересованных сторон (владельцев, персонала)

• Обеспечение соответствия целей и задач компании потребностям и ожиданиям заказчика

• Отражение принципа ориентации на потребителя в Политике в области качества, Руководстве по качеству, программе качества.

• Доведение этих требований до всего персонала компании

• Введение механизмов взаимодействия с заказчиком

• Организацию измерения и оценки степени удовлетворенности заказчика

• Разработку корректирующих действий для повышения удовлетворенности заказчика

• Лидерство руководителя - лидеры устанавливают единство целей и руководства в компании. Они создают и поддерживают среду, в которой персонал компании может быть полностью вовлечен в достижение целей компании

Применение принципа «Лидерство руководителя» - это осуществление в компании деятельности, направленной на:

• Определение Политики компании в области качества

• Демонстрация руководством приверженности принципам системы менеджмента качества на личном примере

• Понимание и реагирование на внешние изменения

• Рассмотрение потребностей всех заинтересованных сторон(заказчика, владельцев, персонала)

• Прогнозирование будущего компании

• Постановку перспективных целей и задач для компании

• Предоставление персоналу требуемых ресурсов, обучения и свободы действий с требуемой ответственностью и отчетностью

• Инициирование, поощрение и признание вклада персонала

• Обучение и продвижение персонала.

• Вовлечение персонала - персонал на всех уровнях составляет основу компании, и его полное вовлечение позволяет использовать его способности на пользу компании

Применение принципа «Вовлечение персонала» - это осуществление в компании деятельности, направленной на:

• Обеспечение понимания персоналом важности собственного вклада и роли в компании

• Определение ответственности каждого за результаты своей деятельности

• Привлечение персонала к активному поиску возможностей улучшения

• Привлечение персонала к оценке собственных показателей

• Привлечение персонала к активному поиску возможностей повышения своей компетентности, знаний и опыта

• Создание условий для свободного обмена знаниями и опытом

• Процессный подход - желаемый результат достигается более эффективно, когда соответствующими ресурсами и видами деятельности управляют как процессами

Применение принципа «Процессный подход» - это осуществление в компании деятельности, направленной на:

• Определение процессов, необходимых для выпуска программного продукта

• Установление последовательности и взаимодействия процессов в компании

• Установление ответственности и полномочий для управления процессами

• Определение входов и выходов процессов

• Определение и обеспечение ресурсами, необходимыми для достижения целей процессов

• Системный подход к менеджменту - определение, понимание и управление системой взаимосвязанных процессов улучшает результативность и эффективность компании

Применение принципа «Системный подход к менеджменту» - это осуществление в компании деятельности, направленной на:

• Определение и разработку системы процессов, обеспечивающих достижение заданных целей компании

• Понимание взаимозависимости между процессами в системе менеджмента качества

• Установление измеримых целей и определение того, как взаимодействуют части системы для достижения установленных целей

• Непрерывное улучшение системы посредством измерения и оценивания степени достижения установленных целей

• Постоянное улучшение - неизменной целью компании должно стать постоянное улучшение

Применение принципа «Постоянное улучшение» - это осуществление в компании деятельности, направленной на:

• Установление целей по управлению и измерению постоянного улучшения

• Оценку, признание и подтверждение улучшений

• Постоянное повышение эффективности всех процессов

• Принятие решений, основанных на фактах - эффективные решения основываются на анализе данных и информации

Применение принципа «Принятие решений, основанных на фактах» - это осуществление в компании деятельности, направленной на:

• Организацию мониторинга, измерений, сбор данных и информации

• Обеспечение уверенности в достоверности данных и информации

• Принятие решений и действий на основе результатов анализа зарегистрированных фактов

• Обеспечение доступности данных для тех, кому они требуются

• Взаимовыгодные отношения с поставщиками - компания и поставщики взаимозависимы, и их взаимовыгодные отношения увеличивают их способность создавать ценности.

Применение принципа «Взаимовыгодные отношения с поставщиками» - это осуществление в компании деятельности, направленной на:

• Идентификацию и выбор основных поставщиков
.3 Планирование качества продукции
С целью обеспечения качества программных продуктов и процессов в компании функционирует Совет по качеству.

Совет по качеству состоит из высококвалифицированных специалистов в области разработки программного обеспечения. Возглавляет Совет по качеству главный технический директор.

Члены Совета по качеству назначаются главным техническим директором.

Основные функции Совета по качеству:

• анализ выполнения Политики в области качества;

• анализ функционирования системы управления качеством;

• оценка качества программного продукта

• оценка качества процессов системы управления качеством;

• оценка результативности и эффективности корректирующих и предупреждающих действий;

• рассмотрение, анализ и разработка решений по результатам функционирования системы управления качеством;

• анализ деятельности внутренних аудиторов системы управления качеством;

• улучшение системы управления качеством.
2.4 Организация контроля качества на предприятии
Важную роль во всех проектах Epam Systems играет тестирование. Обнаружение и устранение проблем после развертывания программного обеспечения будут стоить в 100-1000 раз больше, чем обнаружение и устранение этих проблем до внедрения ПО. Поэтому очень важно уметь оценивать качество системы программного обеспечения по таким параметрам как функциональность системы, ее надёжность и производительность.

Создано независимое подразделение контроля качества, специалисты этого подразделения принимают активное участие во всех фазах разработки приложения для того, чтобы обеспечить соответствие требованиям, проконтролировать последовательность его разработки и внедрения.

Лаборатория тестирования и подразделение контроля качества EPAM отвечают за:

· планирование процесса тестирования;

· создание тестовых примеров и драйверов;

· автоматическое и ручное функциональное тестирование;

· отчетность о результатах тестов;

· анализ архитектуры системы тестирования;

· нагрузочное тестирование;

· анализ слабых мест или компонентов системы.

Понятие функциональной спецификации

Функциональная спецификация - это результат этапа проектирования, подробно описывающий требования к приложению.

Разработка функциональной спецификации очень важна, поскольку этот документ является единственным описанием проекта и используется всеми членами команды и клиентами. Именно этот документ готовит менеджер проекта, именно этот документ обсуждается клиентом и менеджером продукта, именно этот документ служит основой для руководителя разработки, архитектора базы данных и разработчиков.

Процесс создания функциональной спецификации

Определение требования к программному средству (ПС) являются исходным документом для его разработки - заданием, выражающим в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел программного продукта, характеризуют условия его использования.

Определение требований является достаточно сложной и важной частью работы по созданию функциональной спецификации, поскольку необходимо точно определить, что хочет пользователь получить от программного продукта и что, в конечном счете, следует создать.

После того как требования и пожелания заказчика к будущему программному продукту определены, осуществляется их анализ.

Может существовать большое количество способов начать и проводить анализ требований, но все они должны приводить к одному и тому же результату - составлению документа, описывающего все требования и пожелания пользователя.

Результатом анализа должно быть ясное понимание того, что требует пользователь, и что он хочет. Тонкое различие между этими двумя понятиями немаловажно. Требования пользователя ограничиваются представлением пользователя о предлагаемой им задаче. Эти требования пользователь явно обговаривает в процессе дискуссии. Пожелания же пользователя нередко остаются за кадром, не потому что пользователь не обговаривает их специально, а потому, что он подсознательно считает некоторые требования естественными и не требующими специального выделения.

Таким образом, после получения заказа на новую разработку (или на модификацию существующей) начинается анализ требований и пожеланий заказчика и заканчивается составлением документа, в деталях описывающего данную разработку. Главной целью анализа требований заказчика является нахождение того, что хочет пользователь. Если данная фаза разработки проекта была тщательно проведена, осуществляется переход на следующую фазу, где разрабатывается конечный продукт, составляемый для пользователя - функциональная спецификация.

Функциональная спецификация - это мост между начальным обзором требований и технической спецификацией, разрабатываемой позже. Начальный обзор требований выделяет то, что система должна делать, а техническая спецификация - это детализированное проектирование каждого элемента системы. Таким образом, функциональная спецификация описывает, ЧТО система будет делать, но не как это будет выполнено. Это различие важно. Функциональная спецификация также включает описание всех главных функциональных модулей и учитываемые ограничения.

Этот документ в бизнес-терминах объясняет, что должна делать система, как должна работать и выглядеть. А так же спецификация отражает самые последние и лучшие идеи и решения менеджеров, разработчиков и дизайнеров. Все в нем должно представлять интерес для пользователя, и он не должен быть перегружен техническими подробностями, структурами файлов и прочими технологическими деталями.

Ответственный за спецификацию только один человек. Может быть ответственной и группа людей, если проект очень велик, но даже в этом случае каждый из группы должен отвечать за отдельную часть документа.

Разработка тестовых сценариев

Одним из методов технического контроля качества является составление тестовых сценариев, которые содержат в себе описание тестирования граничных состояний, общий подход к оценке качества ПО и в то же время описывает специфику тестирования каждого отдельно взятого модуля.

Тестовые сценарии разрабатываются в соответствии с функциональной спецификацией.

Использование тестового сценария позволяет снизить влияние человеческого фактора на процесс тестирования: пропускается меньше ошибок, возможность тестирования дополнительных функций и требований, регрессионное тестирование, передача информации, напоминание о тестах некоторой давности, позволяют контролировать результаты и обмен опытом, тестирование можно отслеживать в целом (% сделано), позволяет не упустить ни одно требование.

Следующим этапом контроля качества является тестирование приложений.

Тестирование Web приложений

Основы тестирования Web приложений:

· реализация и дизайн

· Клиент - сервер установка

· WEB-ориентированная помощь

· конфигурация

· база данных

· безопасность

· производительность, загруженность и устойчивость к стрессам

При тестировании следует понимать цели и реализацию (технологию)

Два основных класса тестирования:

· дизайн компонентов;

· реализация компонентов;

Список проверок - максимальный набор тестовых случаев, который может быть использован при составлении тестовых сценариев.

Тестирование навигации:

Навигация должна быть проста, логична, интуитивна. Наиболее используемые функции быстро доступны, доступны посредством клавиатуры и мыши, навигация в прямом и обратном порядке.

Тестирование презентабельности:

Должен быть доступ с разрешениями 1024*768 и 600*800, не должно быть лишних скролов, текст на кнопках д/быть виден полностью, цвета линков соответствующие, без разрывов картинок, цветовой контраст не д/быть низким, без пробелов в таблицах, соответствующим образом оформлены границы, выравнивание, форматирование, правильное расположение всех кнопок, проверка анимации (ненавязчивая, корректно проигрывается).

Обработка ошибок:

сообщение должно максимально обрисовывать проблему, пользователю, предлагать возможные пути выхода из неё, не должны содержать грамматических ошибок. Лучше, если валидация происходит на обмене данных, желательно указание конкретных проблем.

Безопасность:

· шифрование

· аутентификация

· цифровые сертификаты

· брандмауэры

· авторизация

Тестирование базы данных:

· поиск

· добавление дублирующейся информации

· добавление/редактирование/удаление информации

· использование примеров

Производительность, загруженность и устойчивость к стрессам:

· доступ нескольких пользователей одновременно

· разные приложения

· все в одно время

Тестирование производительности - скорость отклика (работы) при многопользовательском режиме;

Нагрузочное тестирование - есть требование к загрузке системы - проверяется всё то же самое на определенном наборе hard-soft configuration;

Стрессовое тестирование - сочетает в себе первые 2 пункта, попытка поставить приложение в стрессовую ситуацию при эмуляции работы многих пользователей - выявить предельно допустимую нагрузку.
2.5 Центр управления проектами-PMC (Project Management Center)
PMC - Это специальный программный продукт, разработанный компанией EPAM Systems, который поддерживает процесс создания программных продуктов.

Для тестирования наиболее важен раздел Bugs, который содержит описание всех найденных ошибок.

Для обеспечения надежности очень важным является правильно документировать найденную ошибку. Тестировщик после обнаружения ошибки передает ее в виде отчета об ошибке программисту.

Отчет об ошибке имеет следующие поля:

· Summary - содержит краткое описание ошибки, возникшей в приложении, где она произошла и ее краткая суть.

· Build found - версия приложения, где была обнаружена ошибка

· Symptom - вид ошибки

· Severity - серьезность найденной ошибки

· Reproducible - воспроизводимость ошибки

· Description - подробное описание ошибки. Приводится для того, чтобы программист понял суть проблемы

· Steps to reproduce - шаги для воспроизведения

2.6 Управление продукцией не соответствующей качеству
Программный продукт (ПП) не соответствующий предъявленным к нему требованиям по качеству, как правило, не передается заказчику. По требованию заказчика допускается поставка ПП, прошедшего тестирование с отрицательными результатами. В этом случае заказчик информируется обо всех дефектах, обнаруженных в ПП.

Несоответствующий ПП выявляется на следующих этапах разработки :

•при анализе исходной информации, поступающей от заказчика

•при разработке программного продукта

•при тестировании программного продукта

•при эксплуатации программного продукта у заказчика.

Регистрация несоответствующего ПП осуществляется при наличии соответствующих требований в описаниях процессов и документированных процедурах.

ПП, не соответствующий требованиям, идентифицируется в соответствии с описанием процедуры «Управление конфигурацией и изменениями» и находится под управлением с целью предотвращения непреднамеренного использования или поставки заказчику.

Использоваться или поставляться заказчику может только ПП, успешно прошедший тестирование в процессах «Функциональное тестирование» и «Оптимизация производительности» и имеющих соответствующий статус в процедуре «Управление конфигурацией и изменениями».

Данные о несоответствиях продукции документируются:

•в отчётах по верификации и валидации ПП, в частности в отчётах по тестированию;

•в Сценариях тестирования;

•в специализированных базах данных, в частности в PMC (модуль “Bugs”).

Программный продукт не соответсвуещий требований по качеству отправляется на доработку в соответствии со спецификацией и требованиями. Исправленный ПП повторно проверяется на соответствие требованиям и спецификации в процессе тестирования.

Устранение несоответствий в продукции, выявленных после поставки заказчикам, производится при выполнении процесса «Сопровождение и поддержка» (в случае если сопровождение после поставки ПП оговорено в контракте).
.7 Совершенствование процесса функционального тестирования
Совершенствование процесса производится советом по качеству на основании результатов мониторинга процесса и предложений по улучшению. Мониторинг осуществляется на основе различных метрик.

Метрики:

· Основные метрики:

· Общее количество открытых дефектов;

· Общее количество исправленных дефектов;

· Общее количество исправленных верифицированных дефектов;

· Общее количество отклонённых дефектов;

· Общее количество отложенных дефектов;

· Общее количество повторно открытых дефектов;

· Общее количество сценариев тестирования;

· Общее количество выполненных сценариев тестирования;

· Общее количество успешно пройденных сценариев тестирования;

· Общее количество неуспешно пройденных сценариев тестирования;

· Отношение протестированных требований к общему количеству требований;

· Общее количество дефектов;

· Общее количество закрытых дефектов (включая отклонённые);

· Количество дефектов найденных каждым тестировщиком.

· Прочие метрики:

· Трудозатраты на тестирование за заданный период;

· Общие трудозатраты на тестирование.

Заключение

В своей деятельности компания являются достаточно развитой. Процессы «EPAM Systems» соответствуют международным стандартам качества. В то же время компания постоянно стремится к совершенствованию своих процессов с целью повышения качества продукции и завоевания больших долей рынка. Являясь ведущей компанией, представляющей отечественную программную индустрию на мировом рынке, обладает набором специализированного программного обеспечения, разработанного с целью повышения эффективности работы с клиентами. Разработанные системы разработаны на базе интернет-технологий и позволяют эффективно осуществлять электронный обмен данными, для соответствия системам главных клиентов.

Список литературы

1. В.Н. Гулин «Бизнес офис предприятия». - Мн.: БГЭУ 2004.

. В.И. Кузякин «Информационные системы в Экономике». - Екатеринбург, 2003.

. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980.

. А.И. Мишенин «Теория Экономических Информационных Систем». - М.: "Финансы и статистика" 2000.