Сравнение методов оценки создания ПО

Публикация № 117924

Методология - Управление проектом

Методы оценки размера проектов (микрооценка и макрооценка)

СРАВНЕНИЕ МЕТОДОВ ОЦЕНКИ ПРОЕКТОВ

МЕТОДЫ ОЦЕНКИ РАЗМЕРА ПРОЕКТОВ

Методы оценки размера проектов разделяются на две основные группы: микрооценка и макрооценка.

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

Методы макрооценки, основанные на функциональных требованиях и/или продукте.

Методы макрооценки:

  • IFPUG FPA
  • COCOMO II
  • модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году

ОСНОВНЫЕ МОДЕЛИ ДЛЯ ОПРЕДЕЛЕНИЯ ОБЪЕМОВ РАБОТ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

...слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо.
Фредерик Брукс

Вероятно, одним из наиболее известных моделей данного рода является конструктивная модель стоимости (Constructive Cost Model - COCOMO), разработанная в конце 70х годов Барри Боэмом (Barry Boehm). Построенная на основе анализа ряда проектов, выполненных в основном в интересах Министерства Обороны США, она устанавливает соответствие между размером системы в тысячах условных строк кода и "классом" проекта, с одной стороны, и трудоемкостью разработки системы, с другой стороны.

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

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

Существенным недостатком данной модели является ее основанность на тысячах условных строк кода, как метрике размера программного комплекса. Видимо, одной из первых попыток отойти от данной метрики размера ПО была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем. Метод был впервые опубликован в 1979 году. В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group - IFPUG), было опубликовано несколько ревизий метода.

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

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

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

ПАРАМЕТРЫ ДЛЯ СРАВНЕНИЯ ОСНОВНЫХ МОДЕЛЕЙ ДЛЯ ОПРЕДЕЛЕНИЯ ОБЪЕМОВ РАБОТ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Перечислим те параметры, по которым можно сравнить описанные выше модели.

Тип модели

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

Доступность репозиториев

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

Время применения

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

Независимая оценка трудоемкости и времени

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

Учет факторов размера системы

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

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

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

Учет функциональной сложности

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

Учет нефункциональных требований к системе

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

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

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

Учет степени новизны

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

Учет использования в разработке типовых элементов

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

Учет реинжиниринга или конверсии

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

Учет интеграции готовых коммерческих продуктов

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

Учет жесткости требований

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

Учет качества управления проектом, организационных факторов, инфраструктурных факторов, персонала

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

Учет зависимости трудоемкости от средств разработки

Желательно, чтобы модель отражала зависимость трудоемкости от средств разработки.

Учет влияния графика на трудоемкость

Желательно, чтобы модель отражала возрастание трудоемкости разработки в более сжатые сроки

СРАВНЕНИЕ МОДЕЛЕЙ ДЛЯ ОПРЕДЕЛЕНИЯ ОБЪЕМОВ РАБОТ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ

В соответствии с вышеизложенным, главными факторами при выборе модели должны являться:

  • Тип модели и доступность репозиториев;
  • Время применения;
  • Учет факторов размера системы;
  • Непрерывная зависимость от сложности проекта;
  • Учет функциональной сложности;
  • Учет нефункциональных требований к системе.

Данные факторы для анализируемых нами моделей сведены в табл. 1 -2.

Таблица 1 Основные параметры качества для анализируемых моделей[ 21]

Параметр

Методика Госкомтруда

COCOMO 2.0

FPA IFPUG 4.1

Тип модели

Закрытая

Закрытая

Открытая

Доступность репозиториев

Не приложимо

Не приложимо

Да, множество репозиториев

Время применения

На протяжении всего жизненного цикла

На протяжении всего жизненного цикла после определения требований

На протяжении всего жизненного цикла после определения требований

Учет факторов размера системы

Да

Да

На основе репозитория

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

Нет

Да

Да

 

Таблица 2 Учет требований к системе в моделях

Параметр

Методика Госкомтруда

COCOMO 2.0

FPA IFPUG 4.1

Учет функциональной сложности

Неадекватный

Да, на основе неcкорректированного количества функциональных точек IFPUG

Да, на основе cкорректированного количества функциональных точек IFPUG

Учет нефункциональных требований к системе

защита информации, распараллеливание вычислений

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

Распределенная обработка, Производительность, Загруженность конфигурации, Частота транзакций, повторная используемость, Множество инсталляций, Упрощение внесения изменений

 

Проанализируем подробнее модели на основе этих факторов.

Время применения и учет факторов размера системы

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

Тип модели и доступность репозиториев

Методика Госкомтруда и COCOMO 2.0 являются закрытыми, а FPA IFPUG 4.1 – открытой. 

Учет функциональной сложности

Функциональная сложность в моделях COCOMO 2.0 и FPA IFPUG 4.1 оценивается на основе подсчета функциональных точек. Таким образом, в этом смысле эти две модели аналогичны.

В нижеприведенной табл. 3 сведено сравнение методик по остальным параметрам:

 

Таблица 3 Сравнение методик

Параметр

Методика Госкомтруда

COCOMO 2.0

FPA IFPUG 4.1

Независимая оценка трудоемкости и времени

Нет

Да

Да, на основе данных репозиториев

Поддержка различных жизненных циклов

Да

Да

Да

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

Да

Да

В зависимости от репозитория

Учет степени новизны

Платформа, средства

Платформа, средства, прикладная область

 

Нет

Учет использования в разработке типовых элементов

Да

Да

Да

Учет реинжиниринга или конверсии

Нет

Да

Да

Учет интеграции готовых коммерческих продуктов

Нет

Да

Нет

Учет жесткости требований

Нет

Да

Нет

Учет факторов, связанных с командой

Нет

Да

Нет, но может являться свойством репозитория

Учет зависимости трудоемкости от средств разработки

Детальный

Интегрированный

Интегрированный

Учет влияния графика на трудоемкость

Нет

Да

Нет

 

IFPUG FPA наиболее предпочтительно применять на стороне заказчика, а СОСОМО II - на стороне разработчика, так как для заказчика разница в конкретных условиях разработки не важна, а для разработчика - важна.

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

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

  • преимущественным применением объектно-ориентированного программирования;
  • привлечением новейших средств разработки и написания программ - Java, SQL, С# и т.д.
  • активным использованием WEB-технологий.

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

 

Скачать файлы

Наименование Файл Версия Размер
СРАВНЕНИЕ МЕТОДОВ ОЦЕНКИ ПРОЕКТОВ ПО СОЗДАНИЮ ПО

.docx 26,23Kb
20.02.12
9
.docx 26,23Kb 9 Скачать

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
0. alsoumars 1 20.02.12 20:11 Сейчас в теме
Методы оценки размера проектов (микрооценка и макрооценка)


Перейти к публикации

1. Сергей Осипенко 20.02.12 20:11 Сейчас в теме
...оценки трудоемкости разработки программных систем, утвержденные Госкомтруда

феерично
2. leha.mos 25.02.12 23:40 Сейчас в теме
Где это можно применить? Для чего вся эта информация!? Хотелось бы хотя-бы один пример использования на практике.
Оставьте свое сообщение

См. также

Перед Стартом проекта автоматизации Промо

Управление проектом 1cv8.cf Абонемент ($m)

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

1 стартмани

02.10.2013    24174    19    pro-rok    110    

Анкеты для проведения обследования по подсистемам 1С:ERP

Управление проектом Финансовый учет и бюджетирование (FRP) Производство готовой продукции (работ, услуг) Учет ТМЦ Финансовый учет и бюджетирование (FRP) Производство готовой продукции (работ, услуг) Учет ТМЦ v8 ERP2 1С:Франчайзи, автоматизация бизнеса Россия УУ Абонемент ($m)

Предлагаем вниманию анкеты, используемые для оценки объема проекта внедрения. Анкеты могут использоваться на этапе экспресс-обследования. На более поздних этапах требуется углублять собираемую с клиента информацию для проектирования системы на базе 1С:ERP Управление предприятием 8.

1 стартмани

03.04.2019    21053    1039    1СERP    38    

Оценка экономического эффекта от внедрения системы электронного документооборота

Управление проектом Документооборот и делопроизводство Документооборот и делопроизводство v8 ДО Россия УУ Абонемент ($m)

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

1 стартмани

22.09.2018    13091    23    mvxyz    5    

Давайте договоримся! Промо

Управление проектом Россия Абонемент ($m)

Как работать с «акулами капитализма»? Часто бывает так, что ваши начальники или топ-менеджеры Заказчика далеки от идеала руководителя. А другой работы в ближайшей перспективе не просматривается. Рассмотрим некоторые риски работы внедренцев и способы защиты с помощью оформления договоров и других документов. Эти простые правила важны не только для сторонних внедренцев (франчайзи или фрилансеров), но и для «фикси».

1 стартмани

22.07.2013    27627    6    PAVI    47    

SWOT анализ кризиса в IT-консалтинге

Управление проектом Абонемент ($m)

SWOT-анализ возможностей и угроз для IT-консалтинга по 1С в эпоху перемен.

1 стартмани

08.01.2016    13116    5    dr-wit    4    

Примеры документации с реального проекта

Управление бизнес-процессами (BPM) Управление проектом Документооборот и делопроизводство Документооборот и делопроизводство Абонемент ($m)

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

1 стартмани

20.11.2014    19282    35    raiml    9    

Первые шаги самостоятельного внедрения «1С:УПП». Этап 1. Определяем цели Промо

Техническое задание Управление проектом v8 1cv8.cf УПП1 Россия Абонемент ($m)

Эта статья содержит необходимый набор шагов для начала внедрения программного продукта «1С:Управление производственным предприятием» собственными силами предприятия без привлечения компаний на аутсорсинг.

1 стартмани

19.06.2013    52513    90    Adapta    46    

[INFOSTART EVENT REVOLUTION] Секция "Практика внедрения учетных систем"

Управление бизнес-процессами (BPM) Управление проектом Бухгалтерский учет Абонемент ($m)

Презентации докладчиков секции "Практика внедрения учетных систем" конференции INFOSTART EVENT 2013 REVOLUTION. Докладчики: Алексей Королев, Юрий Робышев, Ольга Петровская, Лилия Мищенко, Олег Филиппов, Евгений Шумилов, Александр Белов, Юрий Гридунов.

17.11.2013    21473    0    kuntashov    8    

[INFOSTART EVENT REVOLUTION] Секция "Организация командной работы (Системы класса HelpDesk, стандарты ITIL)"

Управление бизнес-процессами (BPM) Управление проектом Управленческий учет (прочее) Абонемент ($m)

Вот и закончилась конференция. По многочисленым просьбам выкладываем в открытый доступ презентации докладчиков на секции "Организация командной работы (Системы класса HelpDesk, стандарты ITIL)"

13.11.2013    25899    0    GSoft    16    

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

Управление проектом Россия Абонемент ($m)

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

1 стартмани

25.09.2013    16583    4    dim777777    4    

Как не обжечься на внедрении 1С. Промо

Управление проектом Абонемент ($m)

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

1 стартмани

11.02.2013    73976    17    pro-rok    75    

Внедрение минимальными ресурсами

Управление проектом Абонемент ($m)

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

1 стартмани

18.07.2013    12832    9    dim777777    3    

Инструменты для ведения проектов версия 1.3.1

Управление проектом Управление взаимоотношениями с клиентами (СRM) Учет рабочего времени Управление взаимоотношениями с клиентами (СRM) Учет рабочего времени v8 Россия Абонемент ($m)

Интеграция 1С и интеллектуальных карт. Внешняя обработка экспортирует структуру конфигурации в набор связанных файлов в формате XMind.

1 стартмани

30.06.2013    26859    22    hobi    49    

Игры на проектном поле (подготовлено к выступлению на INFOSTART EVENT 2012)

Управление проектом Абонемент ($m)

ТЕЗИСЫ: Любое внедрение программного продукта — командная работа. И для достижения положительного результата важно, какая система взаимоотношений сложится в команде. Какие факторы могут препятствовать точной формулировке целей проекта? Какая система управления может быть непреодолимым препятствием на пути успешного внедрения? Этим проблемам посвящено выступление.

1 стартмани

23.11.2012    19131    0    PAVI    149    

УПП: Хроники малобюджетного внедрения (Часть 2) Промо

Управление проектом Бухгалтерские Налоговые v8 УПП1 Россия Абонемент ($m)

Сложилось мнение, что 1С:УПП (Управление производственным предприятием) — для крутых фирм, и внедрять его должны долго и большим коллективом. «Растут лимоны на высоких горах. На крутых берегах для крутых. Короче ты не достанешь». Можно ли внедрять УПП в небольших компаниях с небольшими затратами? Это попытка рассказать об итерационной технологии внедрения на живом конкретном примере, почти в режиме реального времени. Один раз в неделю, на один час, автор связывается с 1С-ником клиента по Скайпу и консультирует его. Результаты перед вами.

1 стартмани

13.07.2012    32264    0    PAVI    63    

УПП: Как мы машины считали

Управление проектом Бухгалтерские Управленческий учет (прочее) Учет ОС и НМА Учет ОС и НМА v8 УПП1 Россия Абонемент ($m)

Опубликовав статью «УПП: История одного внедрения» http://infostart.ru/public/139383/, я обещала подробнее рассказать об учете работы и ремонтов машин и механизмов. Прежде всего, скажу, что УПП я полюбила потому, что для Вспомогательного производства (23 счет) появились равные возможности с Основным производством (20 счет). Трудно передать те муки творчества, которые испытывали мы с мужем, когда в «1С:Бухгалтерии 7.7» выстраивали учет работы и ремонтов для машин и механизмов в сельском хозяйстве. Те, кто в теме, меня поймут. Но ведь на любом, даже небольшом, промышленном предприятии машины и механизмы являются ОСНОВНЫМИ средствами производства. О людях пока не говорим. Поэтому, получив в УПП подсистему Управление оборудованием, я была счастлива. Сразу предупреждаю, что дальнейшее изложение является собирательным образом четырех проектов.

1 стартмани

15.06.2012    31962    9    PAVI    104    

KPI : Сдельно-премиальная мотивация программиста 1С + взгляд работодателя + ссылка на статью по теме

Управление бизнес-процессами (BPM) Управление проектом Зарплата Учет рабочего времени Зарплата Учет рабочего времени Абонемент ($m)

Франчайзи, программист на окладе. Мало. Говорят: ну, напиши, чего хочешь-то. Написал. Отклонили. Ничего личного: такой бизнес. Поэтому сейчас я в приличной конторе на приличном окладе с грустью вспоминаю бесцельно прожитые месяцы. А чтобы не пропал децкий труд - выкладываю, чего написал, сюда. Да уходят программисты из франчайзи. добавляю ссылку: http://habrahabr.ru/post/152445/

1 стартмани

05.06.2012    137723    46    tango    67    

УПП: история одного внедрения Промо

Управление проектом Управление бизнес-процессами (BPM) Управленческие Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) v8 УПП1 Россия УУ Абонемент ($m)

Когда генеральный директор одного предприятия решил внедрить новую учетную систему вместо привычной 1С:Бухгалтерии, он ориентировался на привлекательное название: Управление производственным предприятием (УПП). Франчайзи, которые ему эту систему рекомендовали, затем продали, установили и «внедрили», ограничились привычным джентльменским набором: банк, касса, зарплата, закупки и продажи. Блок производства был представлен внедрением Отчетов производства за смену (итого выпуска продукции за месяц) и Требование-накладная (итог списанного сырья за месяц). Управившись с таким внедрением франчайзи были готовы ежемесячно сами помогать финансовому директору рассчитывать себестоимость. Это «действо» для остальных непосвященных было тайной. Но финдиректор, рассчитав годовой баланс, переутомился и ушел в запой. Встал вопрос о новом финдире. Новый финансовый директор, которого выбрал гендиректор, была женщина. Задача, которую поставил ей гендиректор, была «проста»: ликвидировать воровство на предприятии. Что и говорить: неучтенной продукцией, в частности пластиковыми пакетами, торговали на всех рынках в радиусе 100 км. Не помогали ни высокие заборы, ни видеонаблюдение, ни замена ЧОПов. Естественно, акционер был недоволен и сердился на гендиректора: ведь не помогло и внедрение УПП, проект достаточно затратный. Финдир себе в помощь позвала знакомых фрилансеров (меня и моего мужа). С этого момента внедрение УПП стало переживать новый этап.

10 стартмани

09.06.2012    43868    3    PAVI    150    

Экономический результат от внедрения: технология необходима, но не достаточна

Управление проектом Управление бизнес-процессами (BPM) Управление взаимоотношениями с клиентами (СRM) Управление взаимоотношениями с клиентами (СRM) v7.7 v8 1cv8.cf 1cv7.md Россия Абонемент ($m)

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

1 стартмани

04.04.2011    12088    1    lokhnin    3    

Эссе о внедрении

Управление проектом Управленческий учет (прочее) Россия Абонемент ($m)

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

1 стартмани

10.08.2010    17289    1    Арчибальд    51    

Управление проектом (проектный менеджмент) в организации. Часть I.

Управление проектом Россия Абонемент ($m)

Управление – это широкий предмет, охватывающий каждый аспект руководства действующим предприятием. В числе прочих тем, эта отрасль знаний включает: 1. Финансы и бухучет, сбыт и маркетинг, исследования и разработку, производство и распространение. 2. Стратегическое планирование, тактическое планирование, и операционное планирование. 3. Организационные структуры, организационное поведение, управление кадрами, возмещения, выгоды и карьерное развитие. 4. Управление рабочими отношениями через мотивацию, делегацию полномочий, наблюдение, развитие командной работы, управление конфликтными ситуациями, и другие техники. 5. Управление самим собой через планирование личного времени, управление стрессами, другие технологии. Общие навыки управления обеспечивают значительную часть основания для развития навыков управления проектами. Они зачастую бывают основополагающими для менеджеров проектов. В любом конкретном проекте могут потребоваться навыки в некотором количестве дисциплин общего управления.

1 стартмани

01.11.2009    17253    8    larisab    25