На рисунке 5 изображена пошаговая схема разработки системы показателей в организации.
Предполагается, что у организации уже существует четко определенная система стратегических целей верхнего уровня и стратегия. В этом случае задача построения системы показателей существенно упрощается. Если же стратегия и цели не сформулированы, разработать адекватную систему показателей сложнее.
Прежде всего (шаг 1 ) необходимо определить цели разработки системы показателей. Для чего она будет использоваться? Возможные варианты ответов представлены ниже:
Для контроля реализации стратегии и достижения стратегических целей компании;
Для контроля операционной эффективности и улучшения процессов;
Для формирования отчетности для собственников;
Для разработки системы мотивации персонала.
В зависимости от целей разработки система показателей будет иметь различную сложность. Если, например, у организации нет четко определенной стратегии, то акцент при разработке системы может быть сделан на показатели операционной эффективности.
Если стратегия у организации есть, то на шаге 2 необходимо разработать конкретные показатели достижения стратегических целей. Степень конкретности должна быть такой, чтобы было понятно, кто из менеджеров отвечает за достижение по каждому показателю установленных целевых значений. Одновременно может выполняться шаг 3 , связанный с разработкой (точнее, с пересмотром уже существующих) индикативных показателей уровня организации в целом. Таких показателей в системе должно быть немного. Лучше сосредоточить внимание на конкретных показателях.
Рисунок 5 – Методика разработки системы показателей организации
На шаге 4 на основе конкретных показателей достижения стратегических целей разрабатываются показатели оценки операционной эффективности процессов (для одного и более уровней). Желательно при этом обратить внимание на сквозные процессы и разработать соответствующие показатели. Часть показателей достижения стратегических целей может быть напрямую (без детализации) отнесена к соответствующим процессам.
На шаге 5 необходимо свести все разработанные показатели в единую систему, оформить ее документально и провести серию согласований на различных уровнях управления. Желательно привлечь к этой работе собственников, поскольку менеджмент может быть заинтересован в создании адекватной системы показателей.
При сведении всех показателей в единую систему может оказаться, что некоторые из них излишни по различным причинам (взаимное дублирование, невозможность расчета, низкая информативность и т. п.). Такие показатели исключаются из системы.
Шаг 6 включает в себя необходимость разработать методики расчета для показателей, вошедших в систему. Методика расчета должна содержать все необходимые требования для обеспечения расчета показателя, например, перечень исходных данных и их источники, формулу расчета, его периодичность, ответственных за расчет и т. д.
При разработке методик расчета показателей часто оказывается, что для части из них невозможно получить исходные данные, для других формула расчета является слишком сложной или спорной и т.п. Может выясниться, что ряд показателей дублируется. Поэтому в ходе разработки методик система показателей может измениться.
После того как созданы система показателей и методики их расчета, необходимо разработать формы управленческой отчетности (шаг 7 ). Проще всего их сделать с помощью MS Excel. Поскольку методики расчета содержат формулы для расчета, то последние могут быть использованы при настройке отчетов в Excel.
На завершающем этапе (когда и система показателей, и методики их расчета, и формы отчетности разработаны) они утверждаются и запускаются в работу (шаг 8 ).
После двух-трех циклов планирования и отчетности система показателей, методики расчета и разработанные формы отчетности должны быть скорректированы с учетом опыта их практического использования в организации.
Соглашение об использовании материалов сайта
Просим использовать работы, опубликованные на сайте , исключительно в личных целях. Публикация материалов на других сайтах запрещена.
Данная работа (и все другие) доступна для скачивания совершенно бесплатно. Мысленно можете поблагодарить ее автора и коллектив сайта.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Подобные документы
Оценка и аттестация персонала на предприятии. Взаимосвязь оценки персонала и аттестации с элементами системы управления персоналом. Критерии оценки и стандарты работы. Пример критериев оценки и разработки ее систем. Структура процесса аттестации.
дипломная работа , добавлен 02.02.2009
Основные аспекты оценки работы персонала. Особенности аттестации государственных служащих, процедура и методы ее проведения. Критерии и методы оценки компетентности аттестуемых. Характеристика аппарата Государственной Думы, оценка труда его сотрудников.
дипломная работа , добавлен 11.03.2011
Основные понятия аттестации как метода оценки персонала. Цели аттестации и роль руководителя. Внедрение системы аттестации персонала в организации. Методы и критерии оценки аттестации персонала. Оценка результатов и решение аттестационной комиссии.
реферат , добавлен 22.02.2008
Место аттестации персонала в системе управления организацией, этапы проведения данного процесса, критерии и параметры оценки его практической эффективности. Характеристика исследуемого предприятия, анализ системы управления персоналом и его аттестации.
дипломная работа , добавлен 09.10.2014
Исследование сущности аттестации персонала и критериев ее оценки. Традиционные и нетрадиционные методы аттестации персонала. Изучение организационной структуры предприятия ООО "УГСМ". Оценка показателей развития личностных и деловых качеств сотрудников.
дипломная работа , добавлен 21.12.2014
Особенности проведения оценки и аттестации персонала гостиничного предприятия "Парк-отель Европа", анализ базовых методов и критериев. Направления аттестации руководителей и специалистов в организации. Разработка предложений по ее совершенствованию.
курсовая работа , добавлен 29.04.2014
Критерии оценки персонала. Характеристика организационной структуры, количественного и качественного состава сотрудников организации. Анализ системы аттестации педагогических работников. Выявление ее недостатков и рекомендации по совершенствованию.
дипломная работа , добавлен 10.03.2015
Рассмотрение основных функций аттестации: диагностическая, прогностическая. Общая характеристика деятельности ООО "Ашан", знакомство с особенностями и этапами разработки мероприятий по совершенствованию системы оценки и аттестации персонала организации.
дипломная работа , добавлен 10.03.2015
Известно, что критерий - это правило выбора решения. Критерий призван связать любые действия, осуществляемые в системе, с целями ее функционирования. Критерий позволяет отбирать наилучшим образом средства для достижения цели. Поскольку создание и использование различных средств достижения цели связаны с затратами на их создание и эксплуатацию, критерий должен соизмерить эти затраты с достигаемыми с их помощью результатами по реализации целевых задач. Критерий выступает «полномочным представителем» цели во всей системе. Он описывает задачи системы в более емкой и, как правило, более удобной форме, чем раздельное описание целей и возможных средств их достижения. Требуется лишь периодически анализировать соответствие используемых критериев целям системы, не допуская смещения целевых установок, вытекающих из используемых критериев, от главных целей системы. Это смещение часто становится главной проблемой в различных системах.
В экономических системах критерий приобретает ряд особенностей, связанных с характером общественной организации производства. Центральными задачами экономических критериев являются оценка эффективности принимаемых решений, соизмерение общественной потребности и степени ее удовлетворения, оценка общественной необходимости, общественной полезности создаваемой или используемой системы. Другой важной стороной экономических критериев выступает необходимость соизмерения результатов и затрат на их достижение. Как результаты, так и затраты - материальные, фондовые, трудовые - весьма различны по своему составу и характеру, так что критерий должен «уметь» соизмерять их единой мерой, общим способом. Третья важная сторона экономических критериев - непрерывная сравнительная оценка возможности применения ресурсов, используемых в процессе создания и эксплуатации систем. Для каждой системы существует много вариантов исполнения, различающихся по материало-, энерго-, фондо- и трудоемкости, внутри каждого вида ресурсов существуют большие возможности взаимозамещения. Четвертой важной стороной являются единая стоимостная мера и единый способ измерения на основе закона стоимости. Каждый экономический критерии отражает частные, отдельные стороны экономической системы. Более того, содержание критерия зависит от способа его использования. Системой критериев мы называем взаимосвязанный комплекс экономических, функциональных и физических величин, обладающих определенной размерностью в единой системе инвариантов и измеряющих основные качества системы и всех ее подсистем, управление которыми необходимо и достаточно для достижения цели системы.
В тех случаях, когда в системе критериев выделяется главный, причем допускающий точное количественное выражение, он называется критерием оптимальности. Однако это возможно лишь в очень ограниченном числе случаев. Не следует путать понятия критерия оптимальности - количественной формы отражения любого критерия - и критерия эффективности, отражающего существенные содержательные стороны функционирования системы. Критерий оптимальности, взятый изолированно, может и вообще не соответствовать задаче эффективного развития системы.
Систему критериев всегда разрабатывают в определенном порядке исходя из критериев верхнего уровня системы и далее «сверху вниз», вплоть до процессов функционирования, прямо связанных с основным технологическим процессом. Такой порядок построения позволяет четко определить и выразить в форме критерия нижнего уровня вклад каждого звена в достижение задач, определяемых критерием верхнего уровня. С целью точного выявления факторов, влияющих на значения каждого критерия, и обеспечения их взаимосвязи в составе каждого критерия предусматривается выделение компонентов, соответствующих организационнотехническим мероприятиям, и факторов, соответствующих мероприятиям по совершенствованию управления. Рост эффективности непосредственно связан с ростом мощности систем. Принимая во внимание, что это возрастание мощности протекает всегда в определенный период времени, получаем, что эффективность прямо зависит от величины этого времени. Отсюда вытекает особая важность временных критериев, т.е. критериев, выраженных непосредственно во времени достижения целевых показателей. Можно выделить четыре компонента, входящих в состав любого количественного критерия:
- 1) потенциальное значение критерия;
- 2) компоненты, определяемые экстенсивными факторами;
- 3) компоненты, отражающие факторы научно-технического прогресса и совершенства системы;
- 4) срок достижения заданной величины критерия.
Критерии выявляют содержание процессов функционирования системы, однако практически используются обычно не сами критерии, а построенные на их основе величины - показатели, допускающие простые процедуры расчета. Необозримое множество показателей, используемых в системах, зачастую ставит исследователя в тупик при попытке в них разобраться. Только на одном предприятии можно выделить десятки тысяч показателей, сложным образом сцепленных между собой. Любой показатель лишь приблизительно, косвенно отражает описываемый им процесс.
По характеру отражения элементов описываемого процесса можно выделить три крупные группы показателей:
- 1) отчетные и плановые показатели, непосредственно отражающие основные характеристики элементов процесса в натуральной или стоимостной форме;
- 2) нормативы, нормы и тарифы, являющиеся удельными характеристиками расходования средств, использования мощностей или создания продукции;
- 3) оценочные показатели, или оценки, дающие косвенное, относительное и обобщенное описание элементов процесса.
Все эти показатели, характеризующие один и тот же процесс, тесно связаны между собой.
Оценочные показатели играют особую роль в системе, позволяя в обобщенной форме выражать содержание и условия функционирования, направляя процесс функционирования на достижение наилучших результатов. Есть две принципиальные возможности, два пути формирования системы показателей функционирования системы. Первый состоит в формировании показателей непосредственно по ходу технологических операций основного процесса, а также всех вспомогательных и обслуживающих процессов с учетом их технологии и организации. Второй - в формировании системы показателей на основе изучения и последовательной детализации задач функционирования. Например, в системах управления предприятием, организованных традиционно, преобладает первый способ формирования показателей. Каналы информации в таких системах часто перегружены безадресными потоками данных (показатели, зарегистрированные в ходе производственного процесса, передающиеся с уровня на уровень управления), работникам системы управления просто не хватает времени, чтобы систематически вникать в организацию процесса производства. Системы программного целевого управления, ориентированные на первоочередное достижение целевых показателей, используют второй способ формирования системы показателей. Исходными данными здесь являются перечень основных функций системы - от непосредственного обеспечения основного производственного процесса до формулирования целевых показателей на верхнем уровне; перечень задач, решаемых по каждой из функций системы с указанием перечней входных и выходных данных и критериев их решения (система критериев формируется и отлаживается ранее), а также совокупность моделей формирования показателей в форме текстовых описаний, алгоритмов расчета и построения показателей, вспомогательных экономико-математических моделей, описывающих формирование и использование экономических показателей.
В отличие от показателей сложившейся традиционной системы, структура которых зачастую несопоставима, что вызывает скрытое дублирование показателей, структура показателей для вновь создаваемой системы жестко задана, так что показатели всех уровней и звеньев управления построены по единому принципу. Это облегчает их восприятие и обработку как «вручную», так и в интегрированной системе обработки информации. Если система критериев и показателей проектируется целиком заново, то ее внутренняя согласованность и непротиворечивость «вытекают из построения», как говорят математики. Однако действительность оказывается сложнее теоретических схем, проектируемая система фактически должна встраиваться в уже сложившуюся систему норм, правил, элементов регламентации управленческой деятельности, согласовываться по входным и выходным параметрам со смежными системами, накладываться на сложившуюся систему служебных отношений. Поэтому даже в случае вновь проектируемой системы, а тем более если речь идет об усовершенствовании старой системы показателей, требуется доводка системы критериев и показателей. Иногда это становится центральной задачей, когда в ходе системного анализа процесса функционирования выясняется разлаженность критериев оценки деятельности подразделений, экономических рычагов, стимулов и других хозяйственных механизмов.
Процесс отладки критериев в миниатюре повторяет процесс проектирования системы. Основным инструментом отладки, «регулировочным стендом», также служит комплексная модель системы, в которой, однако, лишь намечается описание основного процесса, функций и задач системы и т.п.
Подробно выписываются показатели, используемые в качестве критериев оценки деятельности или для принятия решений, а также критерии, выявляемые в ходе специального анализа функционирования в различных подразделениях и организациях. Такое исследование проводится путем логического анализа процессов функционирования и системы показателей. При этом надо учитывать, что критерии далеко не всегда осознаются, явно формулируются, но всегда вытекают из интересов отдельных людей и организаций. Иногда для выявления критериев требуется провести анализ множества уже принятых решений.
Выявленный перечень критериев по каждому этапу основного процесса вместе со списком ответственных за принимаемые решения организаций отражается в комплексной модели процесса функционирования.
Анализ системы критериев проводят исходя в первую очередь из целей системы, а также комплекса подцелей, детализированных для каждого этапа процесса. Если удается сформулировать главный критерий для всего процесса или отдельного этапа, то пытаются согласовать с ним остальные критерии за счет изменения системы показателей, распределения ответственности между организациями, изменения экономического механизма. Главное в настройке критериев - чтобы каждый показатель, «работающий» как критерий, выражал вклад звена, деятельность которого он оценивает, в прирост значения главного критерия системы или, если единый критерий системы управления отсутствует, - непосредственно в достижение целевых конечных показателей системы.
Отладка системы критериев и показателей устраняет потери, которые несет система из-за противоречий в направлениях деятельности отдельных звеньев, ликвидирует показатели-фикции, выдает точный «наряд на работу» каждому показателю управления. Нет необходимости придумывать какие-то новые, особые показатели, в наиболее «чистой» форме отражающие задачи экономического управления. Такие показатели, как объемы производства, номенклатура, себестоимость, качество, являются практически «вечными», они в равной степени свойственны и фабрике, построенной еще в прошлом веке, и будущему заводу.
Отладка показателей и критериев обслуживающих и функциональных подразделений, а также показателей, оценивающих деятельность самой системы, производится на основе измерения вклада, вносимого ими в эффективность основного процесса. В то же время необходимо стимулировать наиболее рациональную внутреннюю организацию деятельности, для чего устанавливаются вспомогательные показатели, характеризующие работу функциональных и обслуживающих подразделений как структурного целого; важно найти здесь точную меру между этими двумя группами показателей.
Отладка системы показателей линейных подразделений нижнего звена системы направлена на устранение всех функций и задач, не свойственных этому звену, на достижение которых оно не может эффективно воздействовать.
Отладка системы критериев верхнего уровня производится аналогично отладке системы критериев функциональных и обслуживающих подразделений. Здесь, однако, основное внимание должно быть обращено на обеспечение функций, специфических для верхнего уровня системы: формулирование целей, контроль и текущая подстройка критериев, планирование обновления производимой продукции, организация развития самой системы.
Процедура выбора показателей, достаточно и полно отражающих свойства системы, сложна. На практике для оценки свойств систем и их элементов используется несколько сотен различных показателей: количественные, качественные, экономические, технические, общие, комплексные, частные, основные, вспомогательные, специфические, исходные, производные и т.н.
Для принятия решений и оценки степени влияния данных показателей друг на друга используют различные модели и принципы принятия решений, которые, однако, не позволяют формировать определенные однозначные ответы при оценке эффективности на ранних стадиях создания систем.
Рассмотрим общий подход к формированию показателей, который позволит в дальнейшем систематизировать основные этапы оценки эффективности системы и процедуры принятия решений в процессе ее создания и применения. В соответствии с изложенным выше стратифицированным описанием систем вся совокупность показателей, характеризующих систему, имеет иерархическую структуру:
- П1- показатели, характеризующие систему на уровне моделей страты 1;
- П2 - показатели, соответствующие страте 2;
- ПЗ, П4-Пп - частные технические показатели, соответствующие стратам 3, 4,..., п до принятого уровня подробности исследования системы.
Каждая группа показателей на соответствующем i -м уровне деления включает:
- показатели эффективности, характеризующие суммарный эффект от применения системы или ее элементов, которые рассматриваются как отдельные системы на i-м уровне;
- параметры выбора, включающие показатели внешних свойств системы или ее элементов;
- организационно-экономические показатели ЖЦ, оказывающие непосредственное влияние на значения общего показателя эффективности.
- одноуровневые, определяющие взаимосвязь между показателями эффективности и параметрами выбора каждого уровня;
- межуровневые, определяющие взаимосвязь между параметрами выбора предыдущего уровня и показателями эффективности последующего уровня.
В соответствии с вышеизложенным можно предложить следующие этапы определения показателей системы:
- формулировка, анализ и декомпозиция цели, стоящей перед надси- стемой;
- формирование облика и составление стратифицированного описания системы;
- предварительное определение: показателей, характеризующих эффективность достижения цели; параметров выбора, оказывающих непосредственное влияние на показатели эффективности системы и характеризующих внешние свойства системы, условий выбора, включающих предполагаемые воздействия окружающей среды, возможность комплек- сирования системы с другими системами, наличие дублирующих систем и ограничения на допустимые значения показателей эффективности;
- формирование моделей страты 1, позволяющих исследовать влияние параметров и условий выбора на показатели эффективности, уточнение результатов выбора показателей и облика системы;
- анализ описания системы в пределах страты 2, дальнейшая декомпозиция целей, стоящих перед системой: определение целей подсистем страты 2, определение системотехнических показателей эффективности, характеризующих эффективность достижения целей подсистемами страты 2, параметров выбора, характеризующих внешние свойства, видов обеспечения системы, первичных и вторичных функциональных подсистем, определение условий выбора данных показателей;
- формирование межуровневых зависимостей; исследование с помощью этих зависимостей влияния показателей эффективности страты 2 на параметры выбора страты 1, определение на основе этого требований к показателям эффективности страты 2;
- формирование моделей страты 2, позволяющих исследовать влияние параметров и условий выбора на показатели эффективности страты 2;
- уточнение результатов выбора показателей и облика системы.
При переходе к страте 3 процедура выбора показателей повторяется. Процедура выбора заканчивается после достижения приемлемого равновесия между показателями и моделями всех уровней. Предельная детализация показателей зависит от принятой степени подробности исследования системы.
Разработка контрольных заданий, зачетных и экзаменационных вопросов, заданий для тестирования - важная часть работы преподавателя по разработке учебного курса. Содержание и характер этих заданий определяются программой учебного курса, целями и задачами, которые ставит преподаватель. В процессе этой работы может оказаться полезным уже существующий опыт других преподавателей (Турусова, 1994; Полякова, 1995; Контрольные работы по психологии, 1998; Климов, 1999; Каган, 1999).
При подготовке курса важно заранее спланировать некоторые аспекты оценочной системы.
1. Общий принцип оценивания: по «кривой нормального распределения» или в соответствии с определенными заранее заданными критериями.
2. Из каких проверочных процедур (тестов, контрольных заданий, письменных самостоятельных работ, зачета, экзамена) будет складываться общая оценка успешности изучения студентами курса.
3. Значение, которое будет придаваться различным заданиям и экзаменационным процедурам в оценивании успешности освоения студентом курса в целом.
4. Критерии в оценке успешности выполнения проверочных заданий и сдачи экзамена.
5. Какие «премиальные» и «штрафные» баллы будут начисляться в процессе учебных занятий, выполнения самостоятельных заданий, при сдаче экзамена.
6. Какие «штрафы» будут предусмотрены за более позднюю сдачу заданий, тестов?
7. Каковы минимальные критерии для получения удовлетворительной отметки по курсу?
8. Какие требования существуют в отношении сроков и способов пересдачи неудовлетворительно выполненных заданий?
Подробнее о разработке оценочной системы, проверке и оценке знаний по психологии мы говорили выше.
Рабочая программа, тематический план, критерии оценки знаний студентов необходимы для методического обеспечения работы преподавателя. Однако не менее важно, чтобы они были известны студентам с самого начала учебного курса (желательно с первого дня занятий). В этом случае они будут служить им руководством в изучении курса, напоминанием об основных сроках и заданиях, которые они должны выполнить.
Общий обзор целей, содержания и организации учебного курса, детальное разъяснение рабочей программы, ответы на вопросы студентов дают им отличное введение в курс и обычно занимают значительную часть времени на первом занятии.
8. Планирование отдельных учебных занятий и составление конспектов
Следующей задачей преподавателя является подготовка учебных занятий - лекций, семинаров, практических занятий, уроков, а также разработка заданий для самостоятельной работы. Методика проведения каждого из перечисленных видов занятий имеет свою специфику, что, естественно, отражается и на подготовке к ним. Об этом речь шла в предыдущих главах.
Здесь мы остановимся на некоторых общих моментах. Задачами подготовительной работы преподавателя к занятию являются:
Ø определение целей занятия;
Ø выбор знаний и умений, которые должны быть изучены в ходе занятия;
Ø подбор методов и приемов обучения;
Ø разработка методов контроля и оценки успешности занятия;
Ø планирование этапов занятия;
Ø подготовка конспекта (плана) занятия.
При этом важно обратить внимание на следующие вопросы:
1. Какие цели ставятся на занятии? Что должны узнать студенты (учащиеся), что изучить, какими знаниями овладеть, какие умения приобрести? Какие ценности, личностные (или профессиональные) качества будут развиваться благодаря участию в занятии?
2. Какие знания приобретут студенты (учащиеся)? Какие психологические феномены, эмпирические факты, теории, понятия, связи, закономерности будут изучаться на занятии?
3. Какие примеры и иллюстрации будут использоваться для объяснения данного учебного материала? Будут ли это данные эмпирических исследований, практической психологической работы или примеры из жизни?
4. Каким образом будут демонстрироваться возможности практического применения психологических знаний?
5. Какие умения оперирования психологическими знаниями будут формироваться на занятии?
6. Какие методы учебной работы наиболее подходят для достижения поставленных целей занятия?
7. Какие методические приемы будут способствовать усвоению определенных знаний и умений?
8. Какие раздаточные и демонстрационные материалы потребуются?
9. Какие критерии и процедуры будут использоваться для контроля и оценки успешности занятия?
10. Какие основные этапы будет включать занятие? Каковы цели каждого этапа? Какова их ориентировочная длительность? Какие виды деятельности преподавателя, с одной стороны, и студентов (учащихся), с другой стороны, планируются на каждом этапе?
Заключительным этапом подготовки к занятию является составление его конспекта, в котором обычно отражаются ответы на все вышеперечисленные вопросы. Его полезно писать (или печатать) достаточно четким и крупным шрифтом, чтобы он был читабельным и удобным в использовании в любых условиях учебного занятия. Оформление конспекта может быть разным в зависимости от вида занятий (лекция, семинар, практическое занятие, урок), однако его расположение на листе бумаги должно помогать преподавателю быстро и четко выделять наиболее важные методические аспекты занятия.
Важными задачами при разработке преподавателем заданий для самостоятельной работы студента являются:
1. формулировка цели задания, а также знаний и умений, которые должны быть усвоены при его выполнении;
2. постановка задач, которые должны быть решены при выполнении задания;
3. характеристика средств выполнения задания;
4. характеристика источников, которыми можно пользоваться при выполнении задания;
5. примерная оценка времени, которое потребуется для выполнения задания;
6. определение срока, к которому задание должно быть выполнено, и места, куда оно должно быть сдано;
7. формулировка штрафных санкций за сдачу задания позже назначенного срока;
8. разработка и формулировка критериев оценки выполненного задания.
В соответствии с вышеперечисленными задачами должна быть подготовлена четкая (желательно письменная) методическая разработка указаний по выполнению задания для студентов.
Недавно мой друг, программист, рассказал, что он не читает требования, а вместо этого приглашает аналитика на чашку чая, они вместе садятся, и аналитик рассказывает, что должно быть реализовано. Мой друг - умный человек и хороший программист, и причина, почему он получает знания о требованиях именно так, не в том, что ему лень читать документацию, а в том, что, даже прочитав ее, он до конца не разберется, что же надо сделать. В данной статье я хочу рассказать, как можно написать требования к программному продукту так, что программисты не просто используют требования, но и участвуют в их написании; на основе собственно опыта я хочу показать, каким образом можно описать требования, чтобы эти описания были достаточными для реализации системы.
Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.
Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.
Вся документация на наш программный продукт состояла из следующих разделов:
- Общая часть
Список терминов и определений
Описание бизнес-ролей - Требования
Бизнес-требования- Общие сценарии
- Сценарии использования
- Алгоритмы и проверки
Нефункциональные требования
Требования к интеграции
Требования к пользовательскому интерфейсу - Реализация
- Тестирование
- Руководства
- Управление
Системные требования описывали свойства и методы всех объектов системы.
Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.
Требования к интеграции описывали низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Здесь мы их рассматривать не будем.
Требования к пользовательскому интерфейсу – отдельная большая тема, возможно, для другой статьи.
Также здесь я не буду касаться других разделов документации, которые относятся к реализации, тестированию, руководствам и управлению.
Давайте рассмотрим подробнее, что такое список терминов и зачем он нужен.
Список терминов и определений
Очень часто при обсуждении функциональности системы разговор заходит в тупик. Еще хуже, если стороны расходятся, думая, что обо всем договорились, но в результате имеют разное понимание того, что надо сделать. Это происходит не в последней степени из-за того, что изначально участники проекта не смогли договориться о том, что значат те или иные термины. Бывает, что даже самые простые слова вызывают проблемы: что такое пользователь, чем отличается группа от роли, кто является клиентом. Поэтому в отличие от описания бизнес-ролей для терминов необходимо давать как можно более точные определения.Поясню это на примере термина Пользователь . Википедия дает такое определение:
Пользователь - лицо или организация, которое использует действующую систему для выполнения конкретной функции.
Но нас оно не устраивало по нескольким причинам. Во-первых, в систему может зайти только человек, но не организация. Во-вторых, для нашей системы некорректно настоящее время глагола «использует» - система хранит данные о неактивных или удаленных пользователях, т.е. о тех, которые использовали систему ранее, но не могут в настоящее время. И наконец, у нас есть данные о потенциальных пользователях. Например, мы регистрируем сотрудника компании-клиента, который в дальнейшем может получить (а может и не получить) доступ в систему. Наше определение:
Пользователь
- человек, который имеет, имел, или, возможно, будет иметь доступ в систему для совершения операций.
Теперь программист, прочитав определение, сразу поймет, почему свойство Логин
в объекте Пользователь не обязательное.
Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:
Операция - совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.
Как видите, это определение очень важно для всей системы – оно не только связывает пользователя и его бизнес-действия с тем, что должно быть реализовано, но и накладывает требования на то, КАК должна быть реализована система (это КАК было определено ранее при разработке архитектуры) – бизнес-действия внутри операции должны быть внутри транзакции.
Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное.
Часто бывали случаи, когда приходилось прерывать обсуждение и лезть в требования, чтобы понять, подходит ли обсуждаемая функциональность под существующие определения. И для того, чтобы поддержать непротиворечивость требований, мы в итоге должны были или изменять реализацию, или корректировать описания терминов.
В итоге в списке у нас оказалось порядка 200 бизнес- и системных определений, которые мы использовали не только во всей документации, включая, например, и технический дизайн, разрабатываемый программистами, но и в разговоре, при устном обсуждении функциональности системы.
Второй частью, на которую опиралась вся документация, было описание бизнес-ролей.
Описание бизнес-ролей
Все знают, что используют систему пользователи. Но даже в небольшой системе они обладают разными правами и/или ролями. Наверное, самое простое деление – это администратор и рядовой пользователь. В большой системе ролей может быть несколько десятков и аналитику необходимо заранее об этом подумать и указывать роли при описании общих сценариев (смотри ниже) и в заголовках сценариев использования. Список бизнес-ролей используется для реализации групп и ролей пользователей, назначения им функциональных прав, он необходим тестировщикам, чтобы тестировать сценарии под нужными ролями.Бизнес-роли пользователей нам не пришлось выдумывать, поскольку в компании были устоявшиеся отделы, роли, функции. Описание ролей было дано на качественном уровне на основе анализа основных функций сотрудников. Окончательное наделение ролей конкретными правами происходило ближе к концу разработки, когда набор функциональных прав стал устойчивым.
Пара примеров:
Уровни требований
Одной из важных концепций, которую мы применяли при разработке требований, было разделение их на уровни. Алистер Коберн в книге Современные методы описания функциональных требований к системам выделяет 5 уровней. Мы использовали 4 – три уровня бизнес-требований плюс системные требования:Бизнес-требования
- Общие сценарии (соответствует уровню очень белого у Коберна)
- Сценарии использования (соответствует голубому)
- Алгоритмы и проверки (скорее черный)
Кроме того наши требования представляли из себя дерево (с циклами). Т.е. общие сценарии уточнялись сценариями использования, которые, в свою очередь, имели ссылки на проверки и алгоритмы. Поскольку мы использовали wiki, физическая реализация такой структуры не представляла проблем. Сценарии использования, алгоритмы и проверки использовали объекты, их свойства и методы, описанные на системном уровне.
Такая методология позволяла нам с одной стороны описывать текущий сценарий настолько подробно, насколько нужно на данном уровне, вынося детали на нижний уровень. С другой стороны, находясь на любом уровне можно было подняться выше, чтобы понять контекст его выполнения. Это так же обеспечивалось функциональностью wiki: сценарии и алгоритмы были написаны на отдельных страницах, а wiki позволяла посмотреть, какие страницы ссылаются на текущую. Если алгоритм использовался в нескольких сценариях, то он в обязательном порядке выносился на отдельную страницу. Такие фрагменты программисты обычно реализовывали в виде отдельных методов.
На картинке ниже представлена часть нашей иерархии (о содержании речь пойдет дальше).
Важно отметить, что если системный уровень описывал все без исключения объекты системы, то сценарии были написаны далеко не для всех случаев поведения пользователя. Ведь многие объекты, по сути, являлись справочниками, и требования к ним более-менее очевидны и похожи. Таким образом мы экономили время аналитика.
Интересен вопрос, кому в проектной команде какой из уровней нужен. Будущие пользователи могут читать общие сценарии. Но уже сценарии использования для них сложны, поэтому аналитик обычно обсуждает сценарии с пользователями, но не отдает их им для самостоятельного изучения. Программистам обычно нужны алгоритмы, проверки и системные требования. Вы однозначно можете уважать программиста, который читает сценарии использования. Тестировщикам (как и аналитикам) нужны все уровни требований, поскольку им приходится проверять систему на всех уровнях.
Использование wiki позволяло работать над требованиями параллельно всем членам проектной команды. Замечу, что в один и тот же момент разные части требований находились в разных состояниях: от находящихся в работе до уже реализованных.
Бизнес-требования
Общие сценарии
Корневая страница нашего дерева требований состояла из общих сценариев, каждый из которых описывал один из 24 бизнес-процессов, подлежащих реализации в данном модуле. Сценарии на странице располагались в той последовательности, в которой они осуществлялись в компании: от создания объекта с проданными товарами, до передачи их клиенту. Некоторые специфические или вспомогательные сценарии помещались в конце в отдельном разделе.Общий сценарий – это последовательность шагов пользователя и системы для достижения определенной цели. Описания общих сценариев были значительно менее формальны по сравнению со сценариями использования, поскольку они не предназначались для реализации. Основная цель общего сценария – это обобщить сценарии использования, подняться над системой и увидеть, что же в конечном итоге хочет сделать пользователь, и как система ему в этом помогает. Хочу заметить, что общие сценарии также содержали шаги, которые пользователь осуществлял вне системы, поскольку надо было отразить его работу во всей полноте, со всеми этапами, необходимыми для достижения бизнес-цели. На этом уровне хорошо видна роль системы в работе сотрудника компании, видно какая часть этой работы автоматизирована, а какая нет. Именно здесь становилось ясно, что некоторая последовательность действий, которую мы предлагали выполнить пользователю в системе, избыточна, что часть шагов можно сократить.
Некоторые другие цели общих сценариев:
- упорядочение знаний о работе пользователей и системы
- согласование бизнес-процессов с будущими пользователями
- основа для понимания того, что требования полны, что ничего не упущено
- входная точка при поиске нужного сценария или алгоритма
Как видите, только половина шагов автоматизирована, да и те описаны как можно более кратко. Также из первого шага видно, что ручной перевод задания на печать в статус ‘В работе’ в принципе лишний, можно упростить работу пользователя и автоматически переводить задание в этот статус при печати.
Ссылка «Задание на печать», указывающая на описание объекта в системных требованиях, лишняя, поскольку никому не требуется перепрыгнуть на него из общего сценария. А вот ссылка «пакетная печать документов на груз» важна – она ведет на сценарий использования, формально описывающий действия пользователя и системы.
Наши сценарии использования имели следующий формат:
- Заголовок со следующими полями:
статус (В работе | Готов к рецензированию | Согласован)
пользователи (по описанию бизнес-ролей)
цель
предусловия
гарантированный исход
успешный исход
ссылка на описание пользовательского интерфейса (разработанного проектировщиком интерфейсов)
ссылка на сценарий тестирования (заполнялось тестировщиками) - Основной сценарий
- Расширения сценария
Сценарии использования
Сценарий использования содержал пронумерованные шаги, которые в 99% случаев очевидным образом начинались со слов Пользователь или Система . Нумерация важна, поскольку позволяла в вопросах и комментариях сослаться на нужный пункт. Каждый шаг – это обычно простое предложение в настоящем времени. Проверки и алгоритмы выносились на следующий уровень и часто на отдельные страницы, чтобы упростить восприятие сценария, а также для повторного использования.Приведу сценарий использования, на который ссылается общий сценарий выше.
Часто аналитики рисуют пользовательский интерфейс и на его основе пишут сценарии, объясняя это тем, что так нагляднее. Доля истины в этом есть, но мы придерживались позиции, что интерфейс – это дело проектировщика интерфейса. Сначала аналитик описывает, что должно происходить, а затем проектировщик интерфейса рисует эскиз web-страницы или диалога. При этом бывало так, что сценарий приходилось менять. В этом нет ничего страшного, ведь наша цель - спроектировать все части системы так, чтобы было удобно пользователю. При этом каждый участник проектной команды, будь то аналитик или проектировщик интерфейса, обладая специфическими знаниями и внося свой вклад в общее дело, оказывает влияние на работу других членов команды проекта. Только вместе, объединив усилия, можно получить отличный результат.
Алгоритмы и проверки
Интересная проблема возникла при написании алгоритмов. Аналитик пытался их описать как можно более полно, т.е. включать все возможные проверки и ответвления. Однако получившиеся тексты оказывались плохо читабельны, и, как правило, все равно какие-то детали упускались (вероятно, сказывалось отсутствие компилятора -). Поэтому аналитику стоит описывать алгоритм настолько полно, насколько это важно в плане бизнес-логики, второстепенные проверки программист сам обязан предусмотреть в коде.Например, рассмотрим простой алгоритм ниже.
В алгоритме указана всего одна проверка, но очевидно, что при написании кода метода программист должен реализовать проверки на входные параметры; выбросить исключение, если текущий пользователь не определен и т.д. Также программист может объединить данный алгоритм с алгоритмами переходов в другие статусы и написать единый непубличный метод. На уровне API останутся те же операции, но вызывать они будут единый метод с параметрами. Выбрать лучшую реализацию алгоритмов – это как раз компетенция программиста.
Системные требования
Как известно, программирование – это разработка и реализация структур данных и алгоритмов. Таким образом, по большому счету, все, что надо знать программисту – это структуры данных, необходимые для реализации системы, и алгоритмы, которые ими манипулируют.При разработке системы мы использовали объектно-ориентированный подход, а поскольку в основе ООП лежат понятия класса и объекта, то наши структуры данных – это описания классов. Термин «класс» специфичен для программирования, поэтому мы использовали «объект». Т.о. объект в требованиях равен классу в объектно-ориентированном языке программирования (в скобках замечу, что в паре разделов требований пришлось изгаляться, чтобы в тексте разделить объект-класс и объект-экземпляр этого класса).
Описание каждого объекта располагалось на одной wiki-странице и состояло из следующих частей:
- Определение объекта (копия из списка терминов)
- Описание свойств объекта
- Описание операций и прав
- Данные
- Дополнительная информация
Первая таблица каждого объекта описывала признаки его свойств, необходимые для того, чтобы программист смог создать структуры данных в БД и реализовать объект на сервере приложения:
Название
Названием свойства оперирует как пользователь (например, «я изменил номер счета», Номер – свойство объекта Счет), так и проектная команда. Повсеместно в документации использовались ссылки на свойства в виде простой нотации Объект.Свойство, очевидной для любого участника проекта.
Тип
Мы использовали Datetime, Date, Time, GUID, String, Enum, Int, Money, BLOB, Array(), Float, Timezone, TimeSpan. Тип имел отражение на всех уровнях приложения: на уровне БД, сервера приложения, в пользовательском интерфейсе в виде кода и графического представления. Каждому типу было дано определение, чтобы их реализация не вызывала вопросов у программистов. Например, было дано такое определение типу Money: содержит вещественное число с точностью до 4-го знака после запятой, число может быть отрицательным и положительным; одновременно со значением система хранит валюту; валюта по умолчанию - российский рубль.
Признак редактируемости
Да
или Нет
в зависимости от того, позволяет ли система пользователям менять значение этого свойства в операции редактирования. В нашей системе это ограничение реализовывалось на сервере приложения и в пользовательском интерфейсе.
Признак наличия нуля
Да
или Нет
в зависимости от того, может ли поле не содержать значения. Например, поле типа Bool
должно содержать одно из возможных значений, а поле типа String обычно может быть пустым (NULL
). Это ограничение реализовывалось на уровне БД и на сервере приложения.
Признак уникальности
Да
или Нет
в зависимости от того, является ли это поле уникальным. Часто уникальность определяется на группе полей, в этом случае у всех полей в группе стояло Да+
. Это ограничение реализовывалось на уровне БД (индекс) и на сервере приложения.
