- Требования к программным системам

Презентация "Требования к программным системам" по информатике – проект, доклад

Слайд 1
Слайд 2
Слайд 3
Слайд 4
Слайд 5
Слайд 6
Слайд 7
Слайд 8
Слайд 9
Слайд 10
Слайд 11
Слайд 12
Слайд 13
Слайд 14
Слайд 15
Слайд 16
Слайд 17
Слайд 18
Слайд 19
Слайд 20

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

Слайды презентации

Требования
Слайд 1

Требования

Особенности разработки требований к программным системам. Разработка требований – это первый из основных процессов создания программных систем. Этот процесс состоит из следующих основных этапов
Слайд 2

Особенности разработки требований к программным системам

Разработка требований – это первый из основных процессов создания программных систем. Этот процесс состоит из следующих основных этапов

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

Общие положения

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

Общая модель разработки требований
Слайд 4

Общая модель разработки требований

Подготовка разработки требований
Слайд 5

Подготовка разработки требований

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

Определение бизнес-требований

Бизнес-требования определяют основные задачи и цели проекта, в рамках которых определяются все детальные требования к проекту и являются основой раздела об образе и границах проекта спецификации требований являются Подходы к разработке бизнес-требования разрабатываются заказчиком самостоятельно: Недостатки: зачастую бизнес-требования, разработанные заказчиком, не обладают требуемыми характеристиками, что в последствии, при разработке детализированных требований, приводит к конфликтам и необоснованным затратам времени и ресурсов Исключительная прерогатива изменения бизнес-требований принадлежит заказчику. совместная разработка бизнес-требований на начальной стадии процесса разработки требований: информация, касающаяся бизнес-требований, должны поступать от лиц, четко понимающих, почему они взялись за проект. Это может быть непосредственный заказчик и/или его топ-менеджер. При разработке бизнес-требований необходимо: формулировать бизнес-цели в количественном и измеряемом виде, иначе по завершении проекта будет очень сложно доказать его успешность формулировать критерии успеха, в соответствии с которыми заинтересованные лица будут определять и измерять успех проекта установить факторы, которые максимально влияют на успех проекта – и те, которые вы можете контролировать, и те, которые находятся вне сферы вашего влияния четко определить меру для оценки того, были ли достигнуты бизнес-цели

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

Определение образа и границ проекта

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

Ключевые слова для определения образа продукта
Слайд 8

Ключевые слова для определения образа продукта

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

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

Определение классов пользователей и их характеристик. Чтобы не упустить из виду потребности отдельных пользователей, их необходимо подразделить на характерные группы – классы пользователей. Пользователей продукта можно подразделять по таким признакам: по частоте использования продукта по опыту в пре
Слайд 10

Определение классов пользователей и их характеристик

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

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

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

Определение представителей пользователей. В процессе выявления требований аналитикам придется в той или иной мере общаться с большинством пользователей, но для эффективной разработки требований необходимо более тесное взаимодействие. Естественно организовать такое взаимодействие со всеми пользовател
Слайд 12

Определение представителей пользователей

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

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

Определение лиц, принимающих решения

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

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

Выбор способов выявления требований

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

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

Разработка Плана-графика

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

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

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

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

Планы, как правило, расходятся с действительностью. Поэтому современные методологии так и говорят - да, планы будут меняться, да, этого не избежать, просто нужно организовывать процесс так, чтобы минимизировать потери и минимально снизить стоимость внесения изменений в проект. Именно этой проблеме обязаны своим появлением целое семейство "agile" методологий (XP - яркий тому пример), Microsoft-овский MSF раскололся на две ветви, Agile и Formal, да что там, даже у тяжеловесного RUP появились agile направления, например dX, разработанный одним из авторов Agile-манифеста Робертом Мартином. Методологии существуют, но вот цитата из доклада "Хаос" компании Standish Group (статистика по 364 американским компаниям и 23 тысячам проектов): "Только 16.2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52.7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31.1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%".

Допущение первое: в 8-ми часовом рабочем дне 8 рабочих часов. При планировании аксиоматично под рабочими часами понимается то время, когда человек занят именно работой: кодирует, пишет документацию, принимает участие в совещаниях и т.п. Но все мы понимаем, что указанные выше 8 часов далеко не "
Слайд 18

Допущение первое: в 8-ми часовом рабочем дне 8 рабочих часов

При планировании аксиоматично под рабочими часами понимается то время, когда человек занят именно работой: кодирует, пишет документацию, принимает участие в совещаниях и т.п. Но все мы понимаем, что указанные выше 8 часов далеко не "рабочие". Так сколько же рабочих часов в 8-ми часовом рабочем дне? Ведь для того, чтобы найти ответ, не достаточно просто использовать какую-нибудь систему учета времени. Как правило, рассчитанные по ней результаты идеально совпадают с 8 часами. Странно? Вовсе нет. Большинство систем учета времени построено на самооценках, причем зачастую некая форма заполняется после выполнения работ (в конце рабочего дня или на следующий день). Сотрудник абсолютно искренне пытается разделить отработанные 8 часов на задачи, которые он решил. И даже если фиксировать время чаще, точнее становится только список задач, идея обычно остается прежней - прикинуть, как разделить между ними отработанные 8-мь часов. Причем следует заметить - это не попытка скрыть время, когда человек бездельничал. Вовсе нет! Это просто психологический парадокс. Недаром в более приземленных, не столь "высокотехнологичных" отраслях за станочником обычно наблюдал нормировщик, а не он сам заполнял форму! Люди не роботы и избежать потерь времени невозможно! Этого не удается сделать даже на конвейере при выполнении рутинных, механических операций. Что же можно сказать о работе с высоким уровнем "творческого" компонента. Да, мы отвлекаемся, хотя часто это тоже работа. Просто другая. Мы разбираемся с коллегами, с их проблемами, советуем что-то, иногда возникают срочные задачи, и мы переключаемся на них. И это тоже правильно – вы объяснили что-то соседу и сэкономили ему пару часов времени. А завтра он посоветует что-то вам. Вы отвлеклись на возникшую проблему, но иначе простаивало бы несколько человек... По статистике, в наиболее продвинутых компаниях с жестко поставленным процессом и направленной на это корпоративной культурой за день работе отдается до 7-и часов. Это лучший результат. Том Демарко в своей культовой книге "Peopleware: Productive Projects and Teams" приводит цифру 75%, т.е. примерно 6 часов, как пример хорошей организации. Хотя существует достаточно много организаций, где на работу тратится 5, а то и 4 часа в день. Вывод первый: составляя планы, не забывайте, что даже при хорошем раскладе в рабочем дне не восемь, а скорее всего лишь 6 часов, на которые вы и можете рассчитывать.

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

Допущение второе: все рабочее время будет затрачено на выполнение запланированных работ

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

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

Еще одна проблема утечки времени: хаотичность поддержки

Эта проблема специфична именно для организаций - разработчиков программного обеспечения. Если только планируемый проект у вас не первый, у вас неизбежно существует необходимость поддержки реализованных проектов. Время от времени у каждого из ваших заказчиков возникают вопросы - он чего-то не знает, сделал что-то неправильно и теперь не знает, как это исправить, он думает, что у него проблемы с приложением, хотя на самом деле - это проблемы с аппаратурой... или все-таки с приложением? Да мало ли. Подобные вопросы возникают не так уж часто, поэтому тратить чье-то время на постоянную поддержку просто жалко. Да и работа это не самая интересная и добровольцы находятся редко. Более того, обычно заказчик звонит или пишет человеку, с которым он привык общаться, - например, менеджеру проекта или аналитику, чем несказанно их радует. Причем заказчик всегда считает, что его проблемы критичны по времени и легко приходит в раздражение, заслышав слова "обратитесь в пятницу" или что-то вроде этого... По мере роста компании рано или поздно все же приходят к необходимости создания соответствующего подразделения поддержки, остальные же зачастую пускают решение вопросов поддержки на самотек, что и порождает незапланированные "утечки" времени. Как с этим можно бороться? Вот несколько организационных приемов, могущих если не минимизировать потери времени на поддержку, то хотя бы сделать их прогнозируемыми (а, следовательно, такими, которые можно учесть): Все-таки выделить сотрудника (сотрудников), который будет тратить часть своего времени на поддержку реализованных проектов. Ввести график обращения по вопросам поддержки и ознакомить с ним своих заказчиков Разработать шаблон документа, который необходимо заполнить при обращении по вопросам поддержки (Это поразительно! Если вместо простого набора номера и разговора "по душам" необходимо затратить всего 10-15 минут на заполнение формы, количество вопросов существенно сокращается!). Вывод третий: не оставляйте вопросы поддержки на самотек. Или создайте службу поддержки и избавьте сотрудников, занятых в проекте от решения вопросов поддержки, или организуйте поддержку так, что бы затраты времени на нее можно было учесть.

Список похожих презентаций

Требования к современному ПО

Требования к современному ПО

Что же такое «Программное обеспечение»? (Википедия) Програ́ммное обеспе́чение (допустимо также произношение обеспече́ние) (ПО) — все или часть программ, ...
Требования к творческой работе

Требования к творческой работе

ТВОРЧЕСКАЯ РАБОТА: ЦЕЛЬ. Творческая работа – это самостоятельно выполненная законченная научно-исследовательская работа, освещающая одну из актуальных ...
Требования к сейфам и хранилищам документов и ценностей

Требования к сейфам и хранилищам документов и ценностей

Определения. Сейф - ящик для хранения, который защищает содержимое от взлома, и, в закрытом состоянии, имеет, как минимум одну внутреннюю сторону ...
Требования к проектированию аппаратных (серверных комнат)

Требования к проектированию аппаратных (серверных комнат)

Главным хранителем самого ценного ресурса компании — информации — является аппаратная, она же серверная комната. На основании существующей нормативной ...
Требования к оформлению презентаций

Требования к оформлению презентаций

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

Требования к условиям реализации ООП

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

Требования к оформлению презентации

Цели и задачи. Цель. Познакомить с требованиями к оформлению презентации. Задачи: Научить работников образования : эффективно использовать цвет; грамотно ...
Требования к компьютерной презентации

Требования к компьютерной презентации

1. Презентация создается в программе PowerPoint. 2. Презентация предназначена для иллюстрации устного выступления на докладной секции (проецируется ...
Компьютерные вирусы и антивирусные программы

Компьютерные вирусы и антивирусные программы

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

Компьютерные вирусы и антивирусные программы

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

Компьютерные вирусы и антивирусные программы

Компьютерные вирусы. Это программы, которые создают программисты специально для нанесения ущерба пользователям ПК. Их создание и распространение является ...
Компьютерные вирусы и антивирусные программы

Компьютерные вирусы и антивирусные программы

Компьютерные вирусы. Компью́терный ви́рус — вид вредоносного программного обеспечения, способного создавать копии самого себя и внедряться в код других ...
Компьютерные вирусы и антивирусные программы

Компьютерные вирусы и антивирусные программы

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

Компьютерные вирусы и антивирусные программы

Вирусы. Что такое компьютерный вирус? Компьютерный вирус — вид вредоносного программного обеспечения, способного создавать копии самого себя и внедряться ...
Алгоритмы и программы для исполнителя Кукарача

Алгоритмы и программы для исполнителя Кукарача

Программирование — удивительный род человеческой деятельности, который сродни волшебству. Несколько заклинаний на языке посвящённых, и «твёрдый» металл ...
Антивирусные программы

Антивирусные программы

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

Азы программы WORD

Итак, начнём занятие. Во-первых, необходимо открыть программу Microsoft Word. Есть несколько способов. Мы рассмотрим один из них: щёлкаем левой кнопкой ...
Алгоритмы и программы

Алгоритмы и программы

КОМАНДЫ ДЛЯ КОМПЬЮТЕРА. Компьютерная программа представляет собой список команд, которые указывают компьютеру , что он должен делать.Некоторые    программы ...
Авторские системы мультимедиа

Авторские системы мультимедиа

Согласно классификации можно выделить восемь типов авторских систем, использующих следующие метафоры: язык сценариев (Scripting Language); изобразительное ...

Советы как сделать хороший доклад презентации или проекта

  1. Постарайтесь вовлечь аудиторию в рассказ, настройте взаимодействие с аудиторией с помощью наводящих вопросов, игровой части, не бойтесь пошутить и искренне улыбнуться (где это уместно).
  2. Старайтесь объяснять слайд своими словами, добавлять дополнительные интересные факты, не нужно просто читать информацию со слайдов, ее аудитория может прочитать и сама.
  3. Не нужно перегружать слайды Вашего проекта текстовыми блоками, больше иллюстраций и минимум текста позволят лучше донести информацию и привлечь внимание. На слайде должна быть только ключевая информация, остальное лучше рассказать слушателям устно.
  4. Текст должен быть хорошо читаемым, иначе аудитория не сможет увидеть подаваемую информацию, будет сильно отвлекаться от рассказа, пытаясь хоть что-то разобрать, или вовсе утратит весь интерес. Для этого нужно правильно подобрать шрифт, учитывая, где и как будет происходить трансляция презентации, а также правильно подобрать сочетание фона и текста.
  5. Важно провести репетицию Вашего доклада, продумать, как Вы поздороваетесь с аудиторией, что скажете первым, как закончите презентацию. Все приходит с опытом.
  6. Правильно подберите наряд, т.к. одежда докладчика также играет большую роль в восприятии его выступления.
  7. Старайтесь говорить уверенно, плавно и связно.
  8. Старайтесь получить удовольствие от выступления, тогда Вы сможете быть более непринужденным и будете меньше волноваться.

Информация о презентации

Ваша оценка: Оцените презентацию по шкале от 1 до 5 баллов
Дата добавления:31 марта 2019
Категория:Информатика
Содержит:20 слайд(ов)
Поделись с друзьями:
Скачать презентацию
Смотреть советы по подготовке презентации