Формальная (математическая) постановка учебных целей при системном проектировании дидактических (педагогических) систем

Цель - (Ц) подсистемы ПС (ДС) в объектной модели (проекте) желательно представить не просто в виде некоторой словесной формулировки, а связать её с описанием подсистемы. Ц можно представить как некоторое идеальное состояние исследуемой подсистемы (например, ДС), которое задаётся соответствующим экземпляром описания. Но такое узкое понимание Ц имеет недостатки: 1) идеальное состояние может быть недостижимо; 2) слишком конкретно сформулированная Ц, как правило, является «неустойчивой»; у преподавателя со временем (с изменением условий или собственных взглядов) меняется представление об идеальном состоянии. Поэтому более устойчивым и практичным является представление цели(ей) как вектора в пространстве состояний подсистемы, дополненного требованиями, ограничениями, очерчивающими рамки изменения состояния. Таким образом, Ц представляется в виде совокупности критериев * и ограничений * и включает в себя отдельные подцели и требования, соответствующие этим различным критериям и ограничениям. Формально это можно представить в виде математической модели - (ММ) типа:

Y₁ Þ max; (критерий 1)

Y₂ Þ min; (критерий 2)

{ …………………………….}

Y_n Þ extr; (критерий n) (2а)

A₁₁ £ x₁ £ a₂₁ (ограничение - 1)

A₁₂ £ x₂ £ A₂₂ (ограничение - 2)

{ ………………………………} (2б)

A_{1m £} Х_{m £} А_2m (ограничение - m).

 

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

Ограничения (2б) для атрибутов с количественными значениями могут задаваться в виде совокупности интервалов. А для качественных атрибутов задаётся список допустимых значений. Таким образом, цель задаётся не как экземпляр, а как класс описания подсистемы, порождённый от исходного класса. В рамках этого более узкого класса могут быть порождены различные экземпляры - варианты для достижения поставленной Ц. Цель не должна подменять собой исходный класс, поскольку Ц могут меняться. Поэтому в модели лучше хранить как общий класс описания, так и Ц. Какие же требования и подцели разработчик (преподаватель) должен включить в цель? При задании Ц подсистемы должны быть учтены:

§ внутренние цели самой подсистемы;

§ внутренние ограничения (тенденции, узкие места, проблемы), установленные на этапе анализа;

§ цели и требования со стороны подсистем, входящих в один подуровень с данной подсистемой;

§ межподсистемные ограничения со стороны подсистем, входящих в один подуровень с данной подситемой;

§ внешние цели и ограничения со стороны подситем других подуровней и окружающей среды;

§ цели материнской системы;

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

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

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