Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Организация человеческой памяти




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

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

 

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

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

3. Долговременная память. Это память с самыми широкими возможностями, относительно трудным доступом и крайне ненадежными механизмами хранения (мы забываем иногда некоторые вещи). Такая память используется для "постоянного" хранения информации. Продолжая наше сравнение с компьютерной памятью, можем соотнести долговременную память с дисковыми накопителями.

 

Рис. 22.1. Схема организация человеческой памяти

 

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

Наш познавательный процесс в некоторой степени сдерживается ограниченным размером кратковременной памяти. В классическом эксперименте Миллер (Miller, [237]) определил, что в кратковременной памяти может храниться около семи квантов информации. Квант информации не составляет твердо фиксированной величины, это, скорее, определенная информационная единица, которой может быть телефонный номер, сформулированная цель или название улицы. Миллер также дает описание процесса "образования блоков", во время которого кванты информации собираются в целые блоки.

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

Шнейдерман (Shneiderman, [314]) предполагает, что процесс формирования блоков информации используется и при чтении программы программистом. Читающий разбивает содержащуюся в программе информацию на блоки, построенные по принципу внутренней семантической (смысловой) структуры. Восприятие программы не происходит последовательно от оператора к оператору, если только оператор не представляет собой логический блок. На рис. 22.2 показано, как простая программа сортировки может быть разбита на блоки читающим ее субъектом.

 

Рис. 22.2. Познавательные блоки в программе сортировки

 

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

Знания, которые приобретаются в процессе разработки ПО и сохраняются в долговременной памяти, разделяются на два класса.

 

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

2. Синтаксические знания. Это детализированные знания (подробности) об отдельных объектах и явлениях, например о том, как дать описание объекта в UML, какие стандартные функции доступны в языке программирования, создается ли оператор присвоения с помощью знака "=" или знака ":=" и т.д. Эти знания хранятся в неструктурированном виде.

 

Такая организация знаний показана на рис. 22.3, который был заимствован (и переделан) из книги по проектированию интерфейсов пользователя [315]. Здесь предполагается, что семантические знания и знания о решаемой задаче имеют свою организацию и структуру, которые показаны на схеме в виде логической структуры взаимосвязей между различными фрагментами знаний. В противовес семантическим знаниям, синтаксические являются произвольными (в определенной мере) и не имеют четкой организации. Поэтому именно для данного типа знаний более вероятны ошибки и потеря информации.

 

Рис. 22.3. Синтаксические и семантические знания

 

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

Различные модели приобретения синтаксических и семантических знаний помогают понять, как опытные программисты изучают новый язык программирования. У них не возникает особых трудностей в освоении основных понятий языка, таких, как присвоение, цикл, условные операторы и т.п. Синтаксис нового языка, тем не менее, имеет тенденцию смешиваться с синтаксисом уже знакомых языков. Поэтому программист, владеющий языком Ada, при изучении языка Java напишет оператор присвоения скорее с использованием знака ":=", чем "=".

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

Для примера рассмотрим алгоритм двоичного поиска, в котором осуществляется поиск конкретного элемента в упорядоченной совокупности. Этот алгоритм включает проверку средней точки совокупности и применение знаний о взаимоотношении порядка для проверки местонахождения элемента-ключа – в верхней или нижней части совокупности. Программист, знакомый с этим алгоритмом, без труда напишет его версию на языках Java, Ada или на любом другом языке программирования.

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

Решение задач

 

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

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

 

Рис. 22.4. Решение задачи

 

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

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

 

1. Интеграция существующих знаний о компьютерных технологиях и о поставленной задаче с тем, чтобы создать новое знание и с его помощью разобраться в проблеме. В работе [84] подчеркивается особая роль практического опыта решения прикладных задач на этой стадии.

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

3. Представление модели на любом языке программирования или в системе проектной нотации.

 

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

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

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

* SADT (Structured Analysis and Design Technique)- метод структурного анализа и проектирования [7*, 10*]. Принадлежит к группе методов, реализующих структурный (а не объектно-ориентированный) подход к проектированию ПО. - Прим.ред.

 

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

Мотивация

 

Координация деятельности людей для выполнения определенной работы является одной из основных задач менеджеров. Маслов (Maslow, [230]) считает, что мотивация человека направлена на удовлетворение своих потребностей. Эти потребности имеют иерархическую структуру (рис. 22.5). Самый низкий уровень иерархической структуры представляют основные физиологические потребности в пище, сне, самосохранении и др. Социальные потребности связаны с необходимостью чувствовать себя частью социальной группы. Потребности в оценке ассоциируются с желанием получить определенную степень уважения в обществе, а потребность в самореализации связана с развитием личности. Естественно, приоритетными в реализации являются низшие потребности (утоление голода, например), а затем уже человек сосредоточивается на более высоких потребностях.

 

Рис. 22.5. Иерархическая структура человеческих потребностей

 

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

 

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

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

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

 

Рассматривая мотивацию с психологической точки зрения, автор статьи [28] выделяет три типа профессионалов.

 

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

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

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

 

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

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

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

Групповая работа

 

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

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

Ниже перечислены четыре основных фактора, которые в той или иной степени влияют на групповую работу.

 

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

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

3. Общение в команде. Между членами команды должны быть дружеские отношения.

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

Создание команды

 

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

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

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

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

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

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

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

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

Поделиться:





Читайте также:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...