Содержание

Концепция: Инструкции Agile и RUP

Связанные элементы
  • Инженер
  • Настройка процесса разработки для проекта

Разделы

  • Введение
  • Обзор
  • Инструкции XP
    • Инструкции XP в RUP
    • Инструкции XP, которые плохо масштабируются
    • Инструкции XP, требующие осторожности
  • Преобразование артефактов для небольшого проекта
  • Группы действий
  • Роли
    • XP и роли RUP в небольшом проекте
  • Использование инструкций XP в RUP
  • Справочник процесса Agile

Официальные документы:

  • Сравнение RUP и XP
  • Официальный документ: Использование RUP для небольших проектов: Расширение над программированием eXtreme
  • Официальный документ: Рекомендации по RUP/XP: Программирование пары
  • Официальный документ: Рекомендации по RUP/XP: Рефакторинг и план первого тестирования

Rational Unified Process (RUP) — это структура процесса обработки, которую компания Rational Software развивала на протяжении многих лет, используемая во всех типах проектов разработки программного обеспечения — от маленьких до больших. Все большее число процессов «agile», таких как eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) и Crystal Clear Methodology, получают сегодня признание как эффективные методы построения малых систем. (На сайте www.agilealliance.org можно найти подробную информацию о Agile Alliance.)

Следующие разделы призваны помочь коллективам разработчиков оценить некоторые инструкции «agile», описанные в одном из этих методов, чтобы понять, как они могут быть использованы в процессе разработки более сложного программного обеспечения, определенного в RUP (более подробная информация о RUP находится в разделе Введение в RUP).

Сообщество agile синтезировало некоторое количество «наилучших инструкций», наиболее подходящих для малых, компактных коллективов разработчиков. Хотя RUP предназначено для коллективов разработчиков любого размера, эффективно оно может применяться только в малых проектах. Вообще, RUP и процессы сообщества Agile имеют сходный подход к вопросу о том, какие ключевые инструкции должны выполняться для разработки качественного программного обеспечения.

Примерами таких инструкций являются применение повторяющейся разработки и ориентация на пользователей.

Следующие разделы описывают применение некоторых «наилучших инструкций», выработанных сообществом Agile для проектов на основе RUP, и преимущества их использования. В этом случае, внимание сосредоточено на инструкциях, основанных на методологии eXtreme Programming (XP). (Более подробная информация о XP находится на web-сайте: http://www.extremeprogramming.org.)

XP включает в себя четыре основных «вида действий» (кодирование, тестирование, прослушивание и проектирование), которые на самом деле более близко связаны с RUP дисциплины. Эти виды действий XP выполняются с помощью набора инструкций, требующих дополнительных действий, соответствующих некоторым другим дисциплинам в RUP. В соответствии с Объяснение принципов экстремального программирования инструкции XP включают в себя:

  • Игра планирования: Быстро определить рамки следующего выпуска, комбинируя бизнес-приоритеты и технические предположения.
    Как только реальность обгонит план, изменить план.
  • Быстрые выпуски: Быстро произведите простую систему, затем выпускайте новые версии с очень коротким циклом.
  • Метафора: Руководит всей разработкой с помощью простого короткого изложения способа работы всей системы.
  • Простой проект: Система должна быть спроектирована максимально просто в любой момент времени. Избыточная сложность устраняется по мере обнаружения.
  • Тестирование: Программисты постоянно пишут тесты для модулей, которые должны безупречно выполняться перед продолжением разработки. Пользователи пишут тесты, которые демонстрируют работоспособность определенных функций.
  • Рефакторинг: Программисты реструктурируют систему без изменения ее поведения для удаления повторений, улучшения связи, упрощения и повышения гибкости.
  • Программирование в парах: Весь рабочий исходный код пишется двумя программистами в одной системе.
  • Коллективное владение кодом
    : Каждый может внести изменение в исходный код в любом месте системы в любой момент времени.
  • Непрерывная интеграция: Интегрировать и компоновать систему много раз в день при завершении каждой задачи.
  • 40-часовая неделя: Как правило, не работать больше 40 часов в неделю. Никогда не работать сверхурочно две недели подряд.
  • Заказчик в группе: Включить действительного заказчика в коллектив разработки, чтобы он был доступен в любое время для ответов на вопросы.
  • Стандарты кодирования: Программисты пишут весь исходный код в соответствии с правилами, акцентированными на связности кода.

Например, действия, выполняемые в результате применения инструкции «игра планирования», будут главным образом соответствовать дисциплине управления проектом RUP. Но некоторые разделы RUP, такие как развертывание выпуска программного обеспечения, находятся вне области применения XP. Определение требований почти полностью находится вне области применения XP, потому что это находится в компетенции заказчика. Также, поскольку XP предназначено для более простых проектов, оно может легко решать задачи, которые детально охвачены RUP, и изменять дисциплины управления и среды.

Инструкции XP в RUP

В дисциплинах, в которых пересекаются XP и RUP, следующие инструкции, описанные в XP, могут быть применены RUP (а иногда уже применяются):

  • Игра планирования: Для очень маленьких проектов при планировании могут быть применены правила XP, позволяющие достичь многих целей, показанных в дисциплине RUP Управление проектом. Это особенно полезно в случаях плохо формализуемых проектов, когда не требуется создавать формальные промежуточные артефакты управления проектом.
  • Рефакторинг и тестирование: Эти техники могут быть успешно применены в дисциплине реализации RUP.
    Инструкция тестирования XP, для которой требуется проект первого тестирования, особенно хорошо может быть применена для прояснения требований на уровне детализации. Как будет видно в следующем разделе, рефакторинг не очень хорошо масштабируется для больших систем.
  • Непрерывная интеграция: RUP поддерживает эту инструкцию посредством построения подсистем и уровней систем (с повторением). Протестированные на уровне модуля компоненты интегрируются и тестируются в контексте объединяющей системы.
  • Заказчик в группе: Многие из действий RUP могут быть выполнены намного эффективней при наличии в составе группы разработчиков представителя заказчика, которое может сократить количество необходимых промежуточных детализирующих документов. XP делает упор на диалог как предпочтительную форму коммуникации заказчика с разработчиком, которая требует непрерывного и непосредственного общения.
    Однако, при необходимости развития систем, независимо от их величины, необходимо больше, чем только диалог. XP позволяет, например, создавать документы дизайна при завершении проекта. Не запрещая создавать документы или другие артефакты, XP говорит, что создавать нужно только то, что действительно необходимо. RUP соглашается с этим, но не описывает, что является необходимым, когда непрерывность и непосредственность коммуникации не обеспечена полностью.
  • Стандарты кодирования: RUP имеет артефакты, нормативы программирования, которые почти всегда считаются обязательными. (Большая часть профайлов проектного риска, будучи главным движущим механизмом адаптации, должны придерживаться этого.)
  • 40-часовая рабочая неделя: Как и в XP, RUP предлагает исключить ситуацию постоянной внеурочной работы. XP не выдвигает жесткого 40-часового ограничения, допуская отклонения в режиме работы. Общеизвестно, что разработчики программного обеспечения склонны работать внеурочно без дополнительной оплаты, только ради удовлетворения от совершенства создаваемого ими продукта, и менеджерам не обязательно это прекращать. То, чего никогда не должны делать менеджеры, — это пользоваться такой практикой или навязывать ее. Они должны всегда отмечать количество фактически отработанных часов, даже если они не возмещаются. Если журнал проработанного кем-либо времени выглядит превышенным, это необходимо исследовать. Однако, менеджер и работник должны решить это с учетом имеющихся условий, установив, какое отношение к остальному коллективу это может иметь. 40-часов — это только рекомендация, но твердая.
  • Программирование в парах: XP утверждает, что программирование в парах повышает качество исходного кода, и будучи единожды приобретенным, этот навык становится более привлекательным. RUP не описывает в подробностях процесс написания исходного кода, хотя программирование в парах, несомненно, может быть использовано в процессах на основе RUP. Некоторая информация о программировании в парах, также как рефакторинг и тестирование, сейчас предоставляется вместе с RUP в виде официальных документов. Конечно, использование каких-либо из этих инструкций в RUP не является требованием, однако мы рискнем выдвинуть предположение, что в коллективной среде с культурой открытой коммуникации преимущества программирования в парах (в терминах эффективности и стоимости общего жизненного цикла) будет нелегко различить. Люди в слаженном коллективе естественно и без принуждения будут приходить к обсуждению и совместному решению проблем.

Предположение о том, что хороший процесс должен быть навязан на «микро-уровне», часто является отталкивающим и не соответствует некоторым видам корпоративной культуры. Поэтому, RUP не поддерживает строгое принуждение. Однако, в определенных обстоятельствах, работа в парах и некоторые другие инструкции, основанные на принципах коллективной работы XP, являются очевидно выгодными, поскольку каждый член команды может помочь другому. Например:

  • на ранних стадиях формирования коллектива, когда люди приобретают знания
  • в коллективах, не имеющих опыта в какой-либо новой технологии
  • в коллективах, состоящих как из опытного персонала, так и новичков

Инструкции XP, которые плохо масштабируются

Следующие инструкции XP плохо масштабируются для больших систем (XP не требует их применения), так что при этом условии мы не настаиваем на их использовании в RUP.

  • Метафора: Для больших и сложных систем не достаточно представить их архитектуру в виде простой метафоры. RUP предоставляет более разнообразную структуру описания для архитектуры, которая не является просто «системой черных ящиков и их связей», как это описано в Объяснении принципов Экстремального программирования. Даже в сообществе XP в последнее время метафора все меньше употребляется. В XP нет более длительной инструкции (до тех пор пока не понятно, как можно описать это хорошо, метафора может помочь).
  • Коллективное владение кодом: Полезно, чтобы члены коллектива, ответственные за маленькие системы или подсистемы, были знакомы со всем исходным кодом. Но вопрос о том, имеет ли смысл уполномочивать в равной степени всех членов коллектива вносить любые изменения во всем исходном коде, зависит от его сложности. Часто будет быстрее (и безопаснее) поручить внести исправление тому человеку (или паре), который работает над соответствующим сегментом исходного кода. Ознакомленность даже с идеально написанным кодом, особенно алгоритмически сложным, со временем быстро уменьшается.
  • Рефакторинг: В большой системе частый рефакторинг не заменяет недостаток архитектуры. В книге Объяснение принципов экстремального программирования сказано: «Стратегия проектирования XP имеет сходство с алгоритмом поиска экстремума. Вы получаете простой проект, затем немного его усложняете, затем немного упрощаете, потом снова немного усложняете. Цель алгоритмов поиска экстремума состоит в достижении локального оптимума, в котором никакие малые изменения не могут улучшить ситуацию, а большие могут.» В RUP архитектура предоставляет перспективу достижения «глобального экстремума», когда большая и сложная система становится легко управляемой.
  • Быстрые выпуски: Частота, с которой заказчик может принимать и развертывать новые выпуски, зависит от многих факторов, в том числе от размера системы. Это обычно связано с влиянием на бизнес. Двухмесячный цикл может оказаться слишком коротким для некоторых типов систем, и логистика развертывания может это запретить.

Инструкции XP, требующие осторожности

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

  • Простой проект
    XP сильно зависит от функциональности: пожелания пользователя собираются, разбиваются на задачи, а затем реализуются. В соответствии с книгой Объяснение принципов экстремального программирования, проект программного обеспечения в любой момент времени должен удовлетворять всем тестам, не содержать повторяющейся логики, утверждать важность каждой цели для программистов и иметь как можно меньше классов и методов. XP не предполагает добавление к продукту чего-то, что не приносит заказчику пользы в его бизнесе.

    Здесь есть сложность, наподобие проблемы локальной оптимизации, которая в RUP называется «нефункциональными» требованиями. Эти требования также имеют значение для бизнеса заказчика, но их труднее сформулировать. Кое-что из того, что в XP называется ограничениями, попадает в эту категорию. RUP не поддерживает проектирования чего-то, что не является необходимым, любым умозрительным образом, но является сторонником проектирования с архитектурной моделью в уме. Такая модель является одним из ключевых условий удовлетворения нефункциональным требованиям.

    Таким образом, RUP соглашается с XP в том, что «Простой проект» должен включать в себя выполнение всех тестов, но с поправкой: тесты должны демонстрировать удовлетворение программного обеспечения нефункциональным требованиям. Еще раз, это относится к тем случаям, когда размер и сложность системы возрастают, когда архитектура является беспрецедентной, или когда имеются нефункциональные требования. Например, необходимость упорядочивания данных (для оперирования ими в неоднородной распределенной среде) кажется излишне усложняющей исходный код, но это требуется повсюду в программе.

Преобразование артефактов для небольшого проекта

Когда мы приспосабливаем RUP под малый проект и соответственно этому сокращаем требования к Рабочему продукту, как это можно сравнить с эквивалентными артефактами в проекте XP? В таблице 1 приведен типичный набор артефактов RUP малого проекта RUP.

Артефакты XP

Артефакты RUP
(Пример малого проекта)

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

План тестированияТестовый примерТестовый набор (включая Тестовый сценарий, Тестовые данные)
Протокол теста
Сводка тестового вычисления

Программное обеспечение (исходный код) Модель реализации
Выпуски Продукт (Модуль развертывания)
Информация о выпуске
Метафора Документация по архитектуре программного обеспечения
Проект (CRC, схема UML)
Технические и другие задачи
Окончательная документация проекта
Справочная документация		 Модель проекта
Стандарты кодирования Рекомендации связанные с проектом
Рабочая область
Структура тестирования и средства		 Прецедент разработки
Конфигурация среды тестирования
План выпуска
План повтора
Предполагаемые оценки и оценки задачи		 План разработки программного обеспечения
План повтора
Общий план и бюджет Экономическое обоснование проекта
Перечень рисков
Отчеты о выполнении
Временные записи об урочной работе
Показатели (в том числе ресурсы, сфера действия, качество, время)
Мониторинг результатов
Отчеты и замечания на собраниях		 Оценка состояния
Оценка повтора
Проверка записи
Неполадки (и связанные с ними данные) Изменить запросы
Средства управления исходным кодом Хранилище проекта
Рабочая область
Пик (исправление)

Прототипы
Прототип пользовательского интерфейса
Архитектурное обоснование концепции

Само XP (рекомендации и руководство)

Список идей тестирования
Рекомендации связанные с проектом

[Не включенное в XP]

Модель данных
Материалы поддержки пользователя.

Таблица 1: Преобразование артефактов из XP в RUP для малого проекта

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

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

Группы действий

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

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

Соединенные вместе посредством RUP, как это описано в терминах жизненного цикла, артефакты и группы действий составляют «наилучшие инструкции»: принципы проектирования, которые обеспечивают создание качественного программного обеспечения согласно предсказуемого расписания и бюджета. RUP с помощью своих групп действий (и связанных с ними артефактов) поддерживает и осуществляет эти наилучшие инструкции, выполняющиеся в RUP как темы. Это поддерживает ключевые принципы RUP. Заметьте, что XP также использует понятие «инструкции», но, как мы увидим далее, немного в другом смысле по отношению к концепции RUP наилучших инструкций.

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

Так, в XP есть аналог групп действий RUP, но «группы действий» XP формально не определяются и не описываются как таковые. Например, в главе 4, «Пользовательские описания», раздела Экстремальное программирование, находится заголовок «Определите требования с помощью описаний, записанных на карточках», и на протяжении главы дается описание процесса и объяснение того, чем являются пользовательские описания, и как (кем) они должны создаваться. И так продолжается далее, в различных разделах Книг XP (под заголовками, которые совмещают описание артефактов и действий) описаны как «созданные вещи», так и «сделанные вещи», с разной степенью точности и детализации.

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

Имея дело с Группами действий, так же как и с Артефактами, важно не упускать из виду то, чего мы пытаемся достичь. Слепое выполнение действий никогда не является хорошей практикой. Действия и связанные с ними рекомендации даны для использования в тех случаях, когда они могут помочь в достижении поставленных целей, но они не должны применяться для восполнения недостатка в понимании того, что нужно достичь. Этот дух отчетливо выражен в XP, и мы считаем, что его следует применять каждому пользователю RUP.

Роли

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

В книге Объяснение принципов экстремального программирования указано семь ролей, применяемых в XP: Программист, Заказчик, Тестировщик, Наблюдатель, Инструктор, Консультант и Руководитель. Там также описана ответственность и правомочность тех лиц, которые выполняют эти роли. В некоторых других Книгах XP также упомянуты эти роли. Различие в числе ролей в XP и RUP легко объяснить:

  • XP не охватывает всех дисциплин RUP.
  • Роли XP более сопоставимы с должностями в организации (возможно, со многими обязанностями), чем роли RUP. Например, Программист XP фактически выполняет несколько ролей RUP, — Конструктор, Проверяющий кода и Интегратор, — что требует немного разной компетенции.

XP и роли RUP в небольшом проекте

Когда роли RUP применяются в малом проекте, число XP-подобных ролей, которым они соответствуют, сокращается до пяти должностей. В таблице 3 (составленной в RUP) показано это соответствие ролям XP.

Роль XP Пример участника коллектива разработчиков малого проекта RUP RUP Роль
Инструктор
Консультант
Руководитель		 Сэлли Слалом, Старший менеджер Менеджер проекта
Диспетчер развертывания
Технический проверяющий
Менеджер настройки
Менеджер управления изменениями
Заказчик Заинтересованная сторона (как указано в документе Представление)
 Проверяющий управления
Технический проверяющий (требования)
Заказчик
Руководитель
Наблюдатель		 Том Телемарк, Старший разработчик программного обеспечения Системный аналитик
Спецификатор требований
Дизайнер пользовательского интерфейса
Разработчик программного обеспечения
Технический проверяющий
Менеджер тестирования
Аналитик тестирования

Роли разработчика (менее выделенные)

Программист
Тестировщик

Сюзана Сноу, Разработчик программного обеспечения

Генри Халфпайп, Младший разработчик программного обеспечения

 Проектировщик
Конструктор
Технический проверяющий
Интегратор
Проектировщик тестирования
Тестировщик
Технический редактор
Наблюдатель Патрик Павдер, Помощник администратора Ответственный за поддержку Web-сайта проекта, помощь Менеджеру проекта в планировании действий и помощь Менеджеру управления изменениями в управлении изменениями артефактов.   Может также по необходимости оказывать помощь другим ролям.

Таблица 3: Соответствие ролей XP и ролей RUP в малом проекте.

Использование инструкций XP в RUP

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

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

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

Справочник процесса Agile

  • eXtreme Programming (XP) (Более подробная информация находится на web-сайте http://www. extremeprogramming.org/more.html.):

    • Объяснение принципов экстремального программирования. Кент Бэк объясняет концепции и философию экстремального программирования. Эта книга отвечает на вопросы «что» и «почему», но не на вопрос «как».

    • Рефакторинг улучшает существующий исходный код. Первый том, написанный Мартином Фавлером, содержит авторитетное описание рефакторинга. Оно построено на примерах. Есть множество примеров на языке Java. Эта книга объясняет, как осуществить рефакторинг и зачем это нужно.

    • Установка экстремального программирования. Авторы: Рон Джеффриер, Чет Хэндриксон и Энн Андерсен. Эта книга описывает определенные инструкции XP более детально, чем Объяснение принципов экстремального программирования. Она учит стилю программ XP.

    • Планирование экстремального программирования. Авторы: Кент Бэк и Мартин Фавлер. В этой книге приведены самые свежие подходы к планированию программного обеспечения в среде быстрой доставки. Эта книга учит способу выполнения проекта XP.

    • Исследование экстремального программирования. Авторы: Жианкарло Сьюзи и Мишель Марчези. Документы представленные в XP2000. Хорошо подобранный набор документов на большую часть тем.

    • Экстремальное программирование на практике. Авторы: Роберт Мартин и Джеймс Ньюкерк. Реальный проект, использующий XP, описан в мельчайших подробностях.

    • Изучение экстремального программирования. Автор — Вильям Вэйк. Основана на популярном Web-сайте XPlorations. Подробно исследованы определенные темы.

    • Применение экстремального программирования: Игра для победы. Авторы: Кэн Ауэр и Рой Миллер. Опыт первопроходцев применения XP. Публикация в сентябре.

Информацию о других участниках Agile Alliance можно найти на Web-сайте http://www.agilealliance.org.

РУП «БЕЛФАРМАЦИЯ» — Общая информация

Главная/О предприятии / Общая информация

РУП «БЕЛФАРМАЦИЯ»

Самая крупная аптечная сеть Республики Беларусь

РУП «БЕЛФАРМАЦИЯ» сегодня – это динамично развивающееся предприятие включающее 220 аптек, 16 из которых работают круглосуточно, аптечный склад, контрольно-аналитическую лабораторию, информационно-фармацевтический центр.

Государственная аптечная сеть Республики Беларусь

Предприятие включает: 185 аптек, аптечный склад, контрольно-аналитическую лабораторию, информационно-фармацевтический центр.

По состоянию на 1 мая 2022г. списочная численность работников составляет 1955 человека, в том числе 1278 фармацевтических работника.

Задачи предприятия

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

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

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

Осуществление поддержки отечественных производителей.

Организация конкурсов и выполнение централизованных закупок лекарственных средств.

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

Методологическое руководство предприятиями «Фармация», координация и контроль фармацевтической, медицинской, финансово-хозяйственной деятельности и в др. областях.

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

Поддержание устойчивого финансового состояния и эффективного хозяйствования предприятия.

В аптеках РУП «БЕЛФАРМАЦИЯ» впервые среди организаций здравоохранения республики с 2013 года внедрена электронная очередь. Это позволило повысить эффективность работы, обеспечить распределение потока покупателей, сократить время обслуживания, получить консультацию специалиста в условиях конфиденциальности.

С целью повышения культуры лекарственного обслуживания населения в торговых залах крупных аптек установлены «Инфокиоски», где посетители могут самостоятельно без помощи специалиста получить информацию о наличии лекарственных средств в аптеках РУП «БЕЛФАРМАЦИЯ».

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

В Республике Беларусь аптеки РУП «БЕЛФАРМАЦИЯ» первыми с 2014 года стали предоставлять покупателям услугу Интернет-резервирования. С помощью Интернет-заказа Вы можете на сайте PHARMA.BY оформить заказ на приобретение товаров аптечного ассортимента и, получив уведомление, оплатить и забрать его в выбранной аптеке.

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

Все аптеки предприятия реализуют населению лекарственные средства по электронным рецептам. Назначение АИС «Электронный рецепт» - формирование единой базы данных электронных рецептов и обеспечение доступа к информации о назначенных и отпущенных лекарственных средствах в оперативном режиме.

Аптеки предприятия выполняют высоко затратные социальные функции:

Обслуживание пациентов по бесплатным и льготным рецептам

Аптечное изготовление лекарственных средств

Отпуск наркотических и контролируемых психотропных средств

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

C 1 августа 2019 года все аптеки предприятия производят реализацию лекарственных средств отечественного производства с предоставлением скидки в размере 5% с розничной цены.

Всю свою многогранную работу руководство предприятия осуществляет в тесном контакте с общественными организациями: первичной организацией профсоюза, республиканским общественным объединением фармацевтических работников «ФАРМАБЕЛ» и БРСМ.

Награды и дипломы

2016

2 место в республиканском смотре-конкурсе на лучшую первичную профсоюзную организацию по экономии энергоресурсов, сырья и материалов за 2014-2015 годы

2015

Коллектив РУП «БЕЛФАРМАЦИЯ» стал лауреатом премии Федерации профсоюза Беларуси 2015 года в области труда.

2014

Диплом за активное участие в 1-ой Международной выставке спортивной индустрии и здорового образа жизни «Мир спорта и здоровья 2014».

2013

I место в общекомандном зачете III Республиканской спартакиады Белорусского профсоюза работников здравоохранения

2012

За успехи в работе предприятие занесено на Доску почета администрации Советского района Минска по итогам работы за 2012 год.

2011

I место в общекомандном зачете в программе II Спартакиады работников учреждений и организаций здравоохранения.

Все дипломы

Координация государственных предприятий

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

1. ГК «Абхазхлеб»
Генеральный директор Харчилава М.Ч. 
Адрес: г. Сухум, ул. Воронова, 21.
Служебный телефон: 226-31-59  

Паспорт Государственной Компании «Абхазхлеб»

2. ГК «Апсныргылара»
Генеральный директор Ткебучава Т.Е.
Адрес: г. Сухум, ул. Инал-ипа, 10
Служебный телефон: 226-26-85
Электронная почта: [email protected] 


3. ГК «Абхазтоп»

Генеральный директор 
Адрес: г. Сухум, ул. Абазинская, д. 31
Служебный телефон: 226-21-10, 226-41-19
Электронная почта: [email protected] 

Паспорт Государственной Компании «Абхазтоп»

4. ГК «Абхазское пароходство»

Генеральный директор  
Адрес:  
Служебный телефон:  
Электронная почта:

5. РУП «Абхазвторресурсы»
Генеральный директор Пантия Р.Р.
Адрес: г. Сухум, ул. Гулия, 28
Служебный телефон: 226- 26- 82
Электронная почта: [email protected] 

Паспорт Республиканского Унитарного Предприятия «Абхазвторресурсы» 

6.  РУП «Дом печати» 

Генеральный директор Аргун С.Р 
Адрес: г. Сухум, ул. Эшба, 168
Служебный телефон: 222- 50- 62 

Паспорт Республиканского Унитарного Предприятия «Дом печати»      

7. РУП «Сухумская швейная фабрика» 
Директор Харчилава А.А. 
Адрес: г. Сухум, ул. Адыгейская, 87 


8. РУП «Государственная инвестиционная компания» 

Директор Агрба С.З.  
Адрес: ул. Лакоба, д.21 

9. РУП «Сухумский молочный завод» 
Директор Ардзинба А.В. 
Адрес: г. Сухум, ул. Титова, 122  

Паспорт Республиканского Унитарного Предприятия «Сухумский молочный завод»

10. РУП «Абхазуниверсалторг» 
Директор Зантария И.С. 
Адрес: г. Сухум, пр. Мира, 76 
Служебный телефон: 226- 85- 81 
Электронная почта: abkhaztorg@mail. ru  

Паспорт Республиканского Унитарного Предприятия «Абхазуниверсалторг»   

11. РУП «Черноморэнерго» 
Генеральный директор Басария А.Г. 
Адрес: г. Сухум, ул. Гумистинская, д. 1 
Служебный телефон: + 7 (840) 222-51-14 
Электронная почта: [email protected] 
Официальный сайт

Отчет о проделанной работе РУП «Черноморэнерго» за 2017 год
Паспорт Республиканского Унитарного Предприятия «Черноморэнерго»   

12. Завод «Аргонавт»
Директор Чачхалия В.Ш.
Адрес: г. Ткуарчал, ул. Лабахуа, 10

13. Завод «Заря»
Директор Харчилава В.Г.
Адрес: г. Ткуарчал, ул. Чанба, 4

14. РУП «Абхазская железная дорога» 

Директор 
Адрес: 

 

15.  РУП «Международный аэропорт «Сухум» им. В.Г. Ардзинба» 

Директор 
Адрес:

16. РУП «АпсныАвтовокзал» 

Директор 
Адрес: 

17. РУП «Абхазавтодор» 

Директор 
Адрес: 


18. Государственное учреждение Министерства экономики Республики Абхазия «Государственное инвестиционное агентство» 

Директор Гицба И.А.
Адрес: г. Сухум, ул. Пушкина, д. 16, этаж 2, офис № 6
Электронная почта: [email protected]
Официальный сайт


19. ООО «Государственная страховая компания «Абхазгосстрах» 
Генеральный директор Еник Р.Н. 
Адрес: г. Сухум, ул. Чочуа, д.2 
Служебный телефон: 223- 32- 11 
Электронная почта: abkhazgosstrakh@mail. ru 

19. Совместная абхазо-германская государственная автотранспортная компания

Электронный знак — Государственная информационная система маркировки товаров «Электронный знак»