Учебно-методическое пособие "Управление качеством разработки программного обеспечения"


Подгонка модели жизненного цикла разработки



страница6/18
Дата18.10.2016
Размер1.92 Mb.
ТипУчебно-методическое пособие
1   2   3   4   5   6   7   8   9   ...   18

3.2.8 Подгонка модели жизненного цикла разработки.


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

Согласно модели SEI СММ, не существует каких-либо четких предписаний на сей счет: "Руководящие принципы и критерии для адаптации стандартного процесса разработки программного обеспечения данной организации к выбранным проектам получают путем разработки и последующего утверждения", а также "определенный процесс разработки программного обеспечения в рамах данного проекта является адаптированной версией стандартного процесса разработки программного обеспечения для данной организации".

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

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

Стадии процесса выбора жизненного цикла разработки программного обеспечения и его последующей подгонки можно определить следующим образом:

1. Ознакомьтесь с различными моделями.

2. Просмотрите и проанализируйте возможные виды работ: разработка, модерниза­ция, сопровождение и т.д.

3. Выберите самый подходящий жизненный цикл, используя для этого матрицы критериев: высокая степень риска, пользовательский интерфейс, высокая надеж­ность, время доставки на рынок/выпуска продукта, приоритеты пользователя, уточнение требований, ожидаемый срок эксплуатации системы, технология, раз­мер и сложность, возможный параллелизм, а также интерфейсы для существую­щих и новых систем.



  1. Проанализируйте, насколько выбранный жизненный цикл соответствует стан­дартам вашей организации, ваших заказчиков или типа проекта — ISO, IEEE и т.д.

  2. Сформулируйте набор фаз и действий, образующих каждую фазу.

  3. Определите внутренние и внешние производимые продукты.

  4. Определите шаблоны и внутреннее содержимое поставляемых продуктов.

  5. Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта.

  6. Выполните оценку эффективности схемы жизненного цикла и проведите ее мо­дернизацию там, где это необходимо.

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

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

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

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

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

Вместо того чтобы начать разработку "с нуля", в некоторых популярных, обоб­щенных моделях обеспечиваются готовые начальные схемы. Каждая модель имеет присущие ей преимущества и недостатки, определяющие ее применение для опреде­ленных типов проектов.

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

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

Однако интеграция моде­лей жизненного цикла с "каркасом" процесса — это уже другая стадия в ходе достижения более высокого уровня завершенности процесса разработки программного обеспечения. Организация должна осознать то, что разрабатываемые программы должны обладать постоянными характе­ристиками. В то же время реализация этого процесса должна быть гибкой, что обеспе­чивается с помощью настраиваемых моделей жизненного цикла разработки программного обеспечения.

4 Качество программных продуктов.


4.1 Определение качества. Стандарты качества.


Термин «Качество» не имеет общепринятого (индустриального) определения в производстве.

Если попросить группу людей высказать свое мнение по поводу того, что такое качественное программное обеспечение, можно получить следующие варианты ответов:



  • Его легко использовать.

  • Оно демонстрирует хорошую производительность.

  • В нем нет ошибок.

  • Оно не портит пользовательские данные при сбоях.

  • Его можно использовать на разных платформах.

  • Оно может работать 24 часа в сутки и 7 дней в неделю.

  • В него легко добавлять новые возможности.

  • Оно удовлетворяет потребности пользователей.

  • Оно хорошо документировано.

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

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

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

Рис. 7. Представление качества в стандарте ISO 9126


 

Основные аспекты качества программного обеспечения по ISO 9126:

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

Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания добротного программного обеспечения существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO 9126, показано на рисунке.

В области управления качеством известны три гуру Джозеф Джуран, Филипп Кросби и Эдвард Деминг. У каждого из них есть свое определение качества, но у всех у них есть общее – это отношение клиента к качеству продукта.

Джозеф Джуран в свое время (1988), ввел определение качества как пригодность к использованию (“Fitness for Use”) – качестов для заказчика.

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

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

Филип Кросби, определяет качество как соответствие требованиям (“Conformance requirements”, 1979). По Кросби, качество либо есть, либо его нет. Нет такого явления, как различные уровни качества.

Мы можем определить два вида качества:



Внешнее качество – качество для заказчика (это удобство в использовании, отсутствие ошибок, хорошая производительность и т.п.)

Внутренне качество – это качество для разработчиков программного продукта (соответствие требованиям, удобная архитектура, простота изменения и т.п.)

Общие принципы обеспечения качества процессов производства во всех отраслях экономики регулируются набором стандартов ISO 9000. Наиболее важные для разработки программного обеспечения стандарты в его составе следующие:



  • ISO 9000:2000 Quality management systems — Fundamentals and vocabulary.

Системы управления качеством — Основы и словарь. (Аналог — ГОСТ Р-2001).

  • ISO 9001:2000 Quality management systems — Requirements. Models for quality assurance in design, development, production, installation, and servicing.

Системы управления качеством — Требования. Модели для обеспечения качества при проектировании, разработке, коммерциализации, установке и обслуживании.

Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла. (Аналог — ГОСТ Р-2001).



    • Этот стандарт выделяет следующие 22 процесса:

      • Управление качеством.

      • Управление ресурсами.

      • Развитие системы управления.

      • Исследования рынка.

      • Проектирование продуктов.

      • Приобретения.

      • Производство.

      • Оказание услуг.

      • Защита продуктов.

      • Оценка потребностей заказчиков.

      • Поддержка коммуникаций с заказчиками.

      • Поддержка внутренних коммуникаций.

      • Управление документацией.

      • Ведение записей о деятельности.

      • Планирование.

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

      • Внутренние аудиты.

      • Оценки управления.

      • Мониторинг и измерения.

      • Управление несоответствиями.

      • Постоянное совершенствование.

      • Управление и развитие системы в целом.

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

      • Проектирование процесса.

      • Документирование процесса.

      • Реализация процесса.

      • Поддержка процесса.

      • Мониторинг процесса.

      • Управление процессом.

      • Усовершенствование процесса.

    • Помимо поддержки и развития системы процессов, нацеленных на удовлетворение нужд заказчиков и пользователей, ISO 9001 требует:

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

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

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

      • Постоянно контролировать соблюдение требований к качеству на практике, во всех процессах проектирования, производства, предоставления услуг и при приобретениях.

      • Предусмотреть процесс устранения дефектов, определить и контролировать качество результатов этого процесса.

Ранее использовавшиеся стандарты ISO 9002:1994 Quality systems — Model for quality assurance in production, installation and servicing и ISO 9003:1994 Quality systems — Model for quality assurance in final inspection and test в 2000 году были заменены соответствующими им частями ISO 9001.

  • ISO 9004:2000 Quality management systems — Guidelines for performance improvements.

Системы управления качеством. Руководство по улучшению деятельности. (Аналог — ГОСТ Р-2001).

  • ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software.

Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.

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

Стандарт ISO 9126 предлагает использовать для описания внутреннего и внешнего качества программного обеспечения многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества программного обеспечения. Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Для каждого атрибута определяется набор метрик, позволяющих его оценить. Множество характеристик и атрибутов качества согласно ISO 9126 показано на Рис. 6.

Рис. 6. Характеристики и атрибуты качества программного обеспечения по ISO 9126.







Ниже приведены определения этих характеристик и атрибутов по стандарту ISO 9126:2001:

  • Функциональность (functionality)

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

    • Функциональная пригодность (suitability).

Способность решать нужный набор задач.

    • Точность (accuracy).

Способность выдавать нужные результаты.

    • Способность к взаимодействию (interoperability).

Способность взаимодействовать с нужным набором других систем.

    • Соответствие стандартам и правилам (compliance).

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

    • Защищенность (security).

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

  • Надежность (reliability).

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

    • Зрелость, завершенность (maturity).

Величина, обратная частоте отказов программного обеспечения. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени.

    • Устойчивость к отказам (fault tolerance).

Способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением.

    • Способность к восстановлению (recoverability).

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

    • Соответствие стандартам надежности (reliability compliance).

Этот атрибут добавлен в 2001 году.

  • Удобство использования (usability) или практичность.

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

    • Понятность (understandability).

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

    • Удобство обучения (learnability).

Показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с программным обеспечением.

    • Удобство работы (operability).

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

    • Привлекательность (attractiveness).

Способность программного обеспечения быть привлекательным для пользователей. Этот атрибут добавлен в 2001 году.

    • Соответствие стандартам удобства использования (usability compliance).

Этот атрибут добавлен в 2001 году.

  • Производительность (efficiency) или эффективность.

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

    • Временная эффективность (time behaviour).

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

    • Эффективность использования ресурсов (resource utilisation).

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

    • Соответствие стандартам производительности (efficiency compliance).

Этот атрибут добавлен в 2001 году.

  • Удобство сопровождения (maintainability).

Удобство проведения всех видов деятельности, связанных с сопровождение программ.

    • Анализируемость (analyzability) или удобство проведения анализа.

Удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий.

    • Удобство внесения изменений (changeability).

Показатель, обратный трудозатратам на выполнение необходимых изменений.

    • Стабильность (stability).

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

    • Удобство проверки (testability).

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

    • Соответствие стандартам удобства сопровождения (maintainability compliance).

Этот атрибут добавлен в 2001 году.


  • Переносимость (portability).

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

Иногда эта характеристика называется в русскоязычной литературе мобильностью. Однако термин "мобильность" стоит зарезервировать для перевода "mobility" — способности программного обеспечения и компьютерной системы в целом сохранять работоспособность при ее физическом перемещении в пространстве.



    • Адаптируемость (adaptability).

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

    • Удобство установки (installability).

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

    • Способность к сосуществованию (coexistence).

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

    • Удобство замены (replaceability) другого ПО данным.

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

    • Соответствие стандартам переносимости (portability compliance).

Этот атрибут добавлен в 2001 году.

Перечисленные атрибуты относятся к внутреннему и внешнему качеству программного обеспечения согласно ISO 9126. Для описания качества программного обеспечения при использовании стандарт ISO 9126-4 предлагает другой, более узкий набор характеристик.



  • Эффективность (effectiveness).

Способность программного обеспечения предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте.

  • Продуктивность (productivity).

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

  • Безопасность (safety).

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

  • Удовлетворение пользователей (satisfaction).

Способность программного обеспечения приносить удовлетворение пользователям при использовании в заданном контексте.

Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута. Приведем следующие примеры таких метрик.



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

  • Корректность реализации функций — правильность их реализации по отношению к требованиям. Используется для измерения функциональной пригодности.

  • Отношение числа обнаруженных дефектов к прогнозируемому. Используется для определения зрелости.

  • Отношение числа проведенных тестов к общему их числу. Используется для определения зрелости.

  • Отношение числа доступных проектных документов к указанному в их списке. Используется для измерения удобства проведения анализа.

  • Наглядность и полнота документации. Используется для оценки понятности.

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

  • Что программное обеспечение должно делать, например:

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

    • обеспечивать контроль качества строительства и отслеживать проблемные места;

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

  • Насколько оно должно быть надежно, например:

    • работать 7 дней в неделю и 24 часа в сутки;

    • допускается неработоспособность в течение не более 3 часов в год;

    • никакие введенные пользователями данные при отказе не должны теряться.

  • Насколько им должно быть удобно пользоваться, например:

    • покупатель должен, зная название товара и имея средние навыки работы в Интернет, находить нужный ему товар за не более чем 2 минуты;

    • инженер по специальности "строительство мостов" должен в течение одного дня уметь разобраться в 80% функций системы.

  • Насколько оно должно быть эффективно, например:

    • поддерживать обслуживание до 10000 запросов в секунду;

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

    • время реакции на изменение параметров процесса производства не должно превышать 0.1 с;

    • на обработку одного запроса не должно тратиться более 1 MB оперативной памяти.

  • Насколько удобно должно быть его сопровождение, например:

    • добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;

    • добавление поддержки нового этапа процесса производства не должно стоить более $20000.

  • Насколько оно должно быть переносимо, например:

    • ПО должно работать на операционных системах Linux, Windows XP и MacOS X;

    • ПО должно работать с документами в форматах MS Word 97 и HTML;

    • ПО должно сохранять файлы отчетов в форматах MS Word 2000, MS Excel 2000, HTML, RTF и в виде обычного текста;

    • ПО должно сопрягаться с существующей системой записи данных о заказах.

Приведенные атрибуты качества определены в стандартах, но это не значит, что они вполне исчерпывают понятие качества программного обеспечения. Так, в стандарте ISO 9126 отсутствуют характеристики, связанные с мобильностью программного обеспечения (mobility), т.е. способностью программы работать при физических перемещениях машины, на которой она работает.

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


Методы контроля качества


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

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

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

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

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

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


  • Методы и техники, связанные с выяснением свойств программного обеспечения во время его работы.

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

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

К этому виду относятся проверка на моделях (model checking), а также прототипирование (макетирование), используемое для оценки качества принимаемых решений.

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

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

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

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


Каталог: shared -> files -> 201211
201211 -> 1. 1 Предмет и содержание курса 2 Вопросы стандартизации систем
201211 -> Учебное пособие 10 часть Основы общей теории управления. Функциональный и процессный подходы к управлению организацией 15
201211 -> Учебное пособие Санкт-Петербург 2012
files -> Технологические подходы к разработке по [Алексеев П. С.]
files -> Статья 48. Архитектурно-строительное проектирование
files -> Программа дисциплины вычислительная геометрия Цели изучения дисциплины
files -> Методы расчета расходов на it совокупная стоимость владения


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   18


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал