Проектный практикум что это
Проектный практикум в вузе. Лучше писать курсач?
Предисловие
Всем привет, меня зовут Егор. Совсем недавно я окончил второй курс радиофака УрФУ по специальности «программная инженерия» и сейчас прохожу стажировку в качестве системного аналитика. Одной из особенностей обучения в моем институте является проектный практикум, о котором я и хочу высказать свои мысли в этом тексте.
Спасибо Даниил
Идея написать нечто подобное созрела у меня в голове где-то полгода назад, но я никак не мог решиться. Но вот недавно мой товарищ Даниил высказал свое мнение на счет проектного обучения в этой статье, чем сподвиг и меня. Не со всеми тезисами согласен, но однозначно рекомендую к прочтению
Структура обучения
Сначала вкратце о самом процессе обучения.
Курсы по выборы делятся на два вида: хардовые (по специальности, например, C++, дизайн интерфейсов и т.п.) и софтовые (психология, маркетинг и т.п.). Курсы проводятся как от университета, так и от партнеров: наумен, банк точка и др. Здесь каждый семестр полная свобода выбора, куда захочешь (и где останутся места на момент записи), туда и пойдешь.
Как все интересно! Раньше такого не было…
Да, действительно, такая модель обучения для России это что-то новое. По крайней мере, среди всех моих знакомых, широко размазанных по вузам страны, ничего подобного нет. И по-моему, это грустно. Такая модель дает удивительную гибкость при обучении. Попробовал фронт? Не понравилось? Ничего страшного, на следующий семестр выберешь DevOps. Учился C++, но ты модный и прогрессивный и хочешь попробовать машинное обучение? Да пожалуйста. И это круто.
Проблемы такого подхода на радике
К сожалению, и на солнце есть пятна. Но пятна «гибкого» обучения разрешимы.
Первое: непонятный первый курс. У нас были общие дисциплины, было программирование на шарпе. Также был очень интересный предмет «профориентация» (точного названия не помню, но суть понятна): приходили специалисты из разных фирм рассказывать о своих профессиях. И это было ужасно. Нет, дело не в специалистах. Просто, очень тяжело объяснить, чем отличается бэк от фронта людям, которые до этого учились только ЕГЭ сдавать. Конечно, были и шарящие ребята, но их мало и в чем интерес слушать такие базовые вещи? И все скатилось в балаган, когда приходил очередной оратор, а его никто не слушал. Грустно.
Вторая причина заключается в отсутствии курсов по аналитике и управлению команды. Подробнее рассмотрим далее, в контексте.
Проектный практикум на бумаге
Проблемы
1. Сайт. Проекты самые разнообразные от «накидать тем для онлайн курса» до «разработать нейронку по распознанию чего-либо». Но большинство, в какой-то степени, да относятся к бизнесу или разработке продуктов, нацеленных на масмаркет. И как в таком разнообразии выбрать подходящий тебе проект? Как удачно, что у нас есть сайт, который призван помочь с этим! Выглядит это так: для каждого проекта заказчик указывать компетенции, которые необходимы для работы над этим проектом. Сам. Ручками по клавиатуре. Думаю вы уже поняли, в чем беда. Да, по итогу сайт хранит кучу мусора: «фигма», «дизайн в фигма», «ui/ux figma», «Figmf», «Figma» и так далее, я думаю вы поняли, это может продолжаться бесконечно. Проблема в том, что потом студенты должны из общего пула компетенций выбрать подходящие им и сервис покажет наиболее уместные проекты. Что получается в итоге прекрасно демонстрирует картинка ниже.
Как я вижу решение этой проблемы? Убрать на второй план компетенции, а во главу угла поставить специализацию. Сейчас, конечно же, указываются роли на проекте: и аналитики, и бек и фронт разработчики, но это просто наборы букв, которые никак не влияют на процесс выбора. Мне кажется, студент должен выбирать только желаемую роль в команде проекта (тимлид, аналитик, фронт, бек, смм и т.д.) и исходя из выбранной роли система будет предлагать проекты, где такой специалист нужен. Появляется новая проблема: заказчикам и модераторам карточек проектов надо с особым вниманием подбирать роли на проект, чтобы не получилось так, что в команде нет аналитика, а проект требует анализ проблемы, рынка, проектирования макетов и т.д.
2. Роли. На мой взгляд, сейчас существуют разногласия между проектным практикумом и обучением в целом. У нас на выбор есть много курсов по коду, но совсем нет курсов по аналитике и руководству технической команды. Конечно, можно начать рассуждения в стиле «технический вуз, неудивительно, что не учат менеджеров», окей, а системный аналитик? Это не айтишник? А продакты, которые ведут ваши проекты, тоже не айтишники? Они не должны разбираться в теме? Я считаю, что IT, как и любая другая сфера, требует от менеджеров достаточно глубокого понимания внутренних процессов и это достигается либо огромным опытом работы в сфере, либо профильным образованием. Но вернемся к проектному практикуму. Многие проекты подразумевают не только написание кода, а анализ проблемы, поиск путей ее решения, общение с заинтересованными сторонами и т.д. Кураторы у каждой команды разные: у кого-то куратор полностью организует работу и тогда тимлид не нужен, а кому-то с куратором не повезло и он вообще никак не реагирует на сообщения. Получается, что задачи решаем бизнесовые, а бизнес составляющей в команде нет.
Безусловно, если человеку понравилось быть аналитиком или дизайнером он сам будет развиваться в этом направлении, но кто-то боится себя попробовать в новой роли, держа в голове мысль, что от него зависят другие люди, кто-то не попадает в проекты, где нужны такого рода кадры и так далее, причин может быть много.
Решение? Профориентация, дополнительные лекции в рамках проектного практикума, обучающие курсы.
Мне кажется, у студентов должен быть выбор. Хочешь ощутить себя в мини стартапе? Иди на проектный практикум. Хочешь разметить супер сложную и насыщенную страницу сайта? Разметь, а потом напиши курсовую работу о том, с какими сложностями столкнулся и как разрешил их. Вообще ничего не хочешь делать, лишь бы тройку получить? Ну тогда будь добр выбери тему для курсача из списка и сдай в конце семестра. Это как один из способов решения.
Вторая идея решения проблемы заключается в том, чтобы ввести рейтинг студентов по проектам. Самое активные и скиловые ребята будут в топе и им будет легче находить друг друга и объединяться в команды. Сейчас очень трудно найти команду, в которой 100% состава скиловые и заинтересованные. Обычно в команде 1-2 вовлеченных участника, которые тащут всех за собой.
4. Заказчики. Довольно часто бывает так, что заказчик кидает ТЗ проекта (часто и тз сделано из под палки) и забивает. Лично мне на последнем проекте мой заказчик говорил «если бы ты не написал, я бы даже не вспомнил, что проект закидывал». Но нам повезло, мы смогли найти общий язык и куратор не пропал посередине проекта (это случилось ближе к концу). На предыдущем проекте заказчик отвалился уже через 1,5 месяца. Мы вот ему отправляем модель БД на одобрение 12 ноября, а 6 декабря он отвечает «норм». Конечно, я понимаю, работа, семья, под дулом пистолета заставили, но люди берут обязательства и не выполняют их. У кого-то кураторы реально помогают, у кого-то теряются еще в начале, а кому-то и вовсе мешают делать проект (да-да и такое бывает). А оценивают проекты одинаково. Никого не интересует какой наставник у тебя был и это, на мой взгляд, неправильно.
Я не вижу простого решения этой проблемы и это не проблема студентов. Это проблема университета и партнеров. Чтобы увеличить заинтересованность заказчиков к проектам надо повышать авторитет вуза перед сторонними компаниями, а компаниям лучше следить за людьми, которые представляют лицо фирмы перед потенциальными работниками.
5. Оценка проектов. За 5 минут расскажите двум людям без лица, что у вас за проект. Звучит очень грубо, но весьма точно отражает суть. Вообще, очень много возмущения по поводу оценки проектов как от студентов, так и от специалистов в комиссии.
Обговорим сразу, да, мне важна оценка за мой труд. Нет, мне не важна цифра, мне важно, чтобы мои усилия оценили по достоинству. Если моя команда работала на отлично я ожидаю и соответствующую оценку.
Формат проведения защиты. Так как сейчас вездесущая удаленка, то и защита проходила у меня 3/4 раз удаленно. Проекты делятся на несколько треков. В последний раз это были: gamedev, Art-design, Application, ML, mobile, web. У каждого трека указаны эксперты (от 1 до 3) и очередь команд. В указанное время команда заходит и у докладчика есть 5 минут чтобы защитить свой проект. Затем вопросы от экспертов и конец. Что должен рассказать докладчик за 5 минут: выделить проблему, обозначить цели, задачи, показать анализ конкурентов, аудитории, рассказать о своем решение, продемонстрировать, что получилось. Если что-то отсутсвует, то обязательно спросят почему. Если заказчик захотел сам сделать велосипед, это его право, но ребят на защите завалят вопросами «зачем вы придумали велосипед?».
Я не был куратором, меня просто позвали послушать проекты. …
…У ребят разный уровень проработанности и не понятно как на такое реагировать, вроде что-то делали, а вроде у других в 2-3 раза больше результата (но тут и от размера команды зависит). …
…Система оценивания в корне не правильная и почти бесполезная. Из тех критериев что там были, это скорее относится к презентации проекта, а не к нему самому. …
Заключение
Задания по проектному практикуму (4 задания)
Описание компании разработчика
Отчетный документ «Описание фирмы» оформить в Word, отчет должен быть понятным и наглядным.
Разработка концепции проекта
Шаблон Концепции проекта
Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. Живые документы должны изменяться по мере эволюции проекта.
На фазе выработки концепции планы имеют форму описания высокоуровневых подходов и по мере подготовки распространяются среди членов проектной группы и других заинтересованных лиц для получения отзывов.
После перехода к фазе планирования документы постепенно дорабатываются, возникающие детальные планы снова поступают на проверку всем заинтересованным сторонам, и описанный процесс повторяется итеративно.
Типы планов и общее количество описывающих их документов могут варьироваться от проекта к проекту.
Обоснование необходимости
Сформулируйте, на разрешение каких проблем и/или удовлетворение каких потребностей заинтересованных сторон направлен проект.
Видение проекта
Видение – это ничем не ограничиваемое представление о том, каким должно быть решение. Видение проекта направлено на формирование у всех вовлеченных в проект сторон единого понимания его концепции. Формулировка видения должна быть достаточно краткой для запоминания, достаточно ясной для понимания и достаточно сильной для мотивирования. Хорошая формулировка видения ориентируется на пять SMART характеристик:
Сформулируйте (максимально кратко, в одной двух фразах) видение проекта.
Анализ выгод
Основываясь на сформулированном выше видении проекта, перечислите, какие выгоды получат заинтересованные стороны по завершении проекта (в результате внедрения и использования решения).
Концепция решения предоставляет общее описание подходов, которые проектная группа предполагает использовать для разрешения проблем и/или удовлетворения потребностей заинтересованных сторон.
Формирование концепции решения начинается с выяснения у заинтересованных сторон, описания и фиксации проектной группой целей проекта. Далее каждая цель разбивается на измеримые компоненты – задачи.
Во взаимодействии с заинтересованными сторонами проекта сформулируйте и утвердите цели решения, на достижение которых направлен проект. Определите задачи, из которых будет складываться достижение каждой цели.
Предположения и Ограничения
В процессе формирования концепции решения проектная группа постоянно взаимодействует с заинтересованными сторонами, собирая необходимую информацию о требованиях к функциональности будущего решения. Тем не менее, неизбежная неполнота информации приводит к тому, что относительно некоторых функциональных возможностей решения могут потребоваться предположения. Помимо функциональных требований заинтересованные стороны могут выдвигать качественные требования, задающие ограничения на создаваемое решение. Также ограничения могут порождаться средой, в которой должно будет функционировать решение после внедрения.
Определите, имеются ли в проекте требования, нуждающиеся в предположениях, если да, сформулируйте их. Определите, имеются ли ограничения на будущее решение. Если да, сформулируйте их.
Анализ использования
Основой формулировки требований является анализ использования, включающий определение пользователей и описание того, как пользователи будут взаимодействовать с решением.
Пользователи
В разработке решения заинтересованы множество сторон, однако непосредственная работа с ним будет выполняться пользователями, поэтому прежде чем приступать к дизайну решения, необходимо определить, кто будет с ним взаимодействовать. В процессе анализа должны быть выделены группы пользователей (например, на основе областей их деятельности, в которых будет использоваться разрабатываемое решение).
Сформируйте список групп пользователей, для которых предназначено решение.
Сценарии использования
Сценарии использования определяют последовательности действий, которые пользователи выполняют при взаимодействии с решением. Один из возможных (и достаточно распространенных) вариантов описания сценариев использования – язык UML.
Для каждой выделенной на предыдущем шаге группы пользователей определите характерные способы их взаимодействия с решением и, используя необходимые диаграммы UML, опишите сценарии использования.
Требования
Требования определяют, что должно делать разрабатываемое решение. Требования могут выражаться в терминах функциональности или в виде правил и параметров, определяющих функциональность.
Требования пользователей
Сформулируйте требования к решению с точки зрения пользователей.
Системные требования
Сформулируйте требования к решению с точки зрения среды, в которой оно должно будет функционировать после внедрения.
Рамки определяют пространство параметров, в котором будет создаваться решение, детализируя функциональность, определяя, что останется за рамками решения и указывая критерии, по которым заинтересованные лица будут судить о готовности решения. Рамки создаются на основе единого видения, являются результатом компромисса между сформулированными целями и условиями реальности и отражают приоритезацию заказчиком имеющихся требований к создаваемому решению. Частью процесса определения рамок проекта является вынесение менее важной функциональности из текущего проекта в планы на будущее.
Рамки решения определяют функциональность решения и его возможности (включая те, что не относятся к программному обеспечению). Возможность (функциональность, составляющая, feature) – это требуемый или желаемый аспект программного или аппаратного обеспечения. Например, предварительный просмотр перед печатью может быть возможностью текстового процессора. Сопроводительные руководства пользователей, интерактивные файлы помощи, операционные руководства и обучение также могут быть составляющими решения.
Рамки проекта определяют объем работ, который должен быть выполнен проектной группой для поставки заказчику каждого из элементов, определенного рамками решения.
Управление рамками проекта критично для его успеха. Советуют определять и фиксировать рамки решения и проекта, используя треугольник компромиссов и матрицу компромиссов проекта.
Функциональность решения
Укажите здесь функциональность в терминах возможностей (features) и функций (functions), которая будет реализована в разрабатываемом решении.
За рамками решения
Укажите здесь функциональность, которая имеется или предполагается в требованиях заинтересованных сторон, но не будет реализована в решении, и опишите причины вынесения данных возможностей и функций за рамки решения (используйте треугольник компромиссов).
Критерии одобрения решения
Сформулируйте здесь критерии, в соответствии с которыми заинтересованные стороны будут принимать готовность решения.
Стратегия архитектурного дизайна
На основе разработанного списка возможностей и функций формируется стратегия архитектурного дизайна, описывающая решение в целом. Она определяет компоненты решения и их взаимодействие. Отличный способ описания решения на этом этапе – использование иллюстрирующих диаграмм (например, UML).
Сформируйте и опишите общий архитектурный проект решения.
Стратегия технологического дизайна
Разработка решения потребует использования определенных продуктов и технологий. Стратегия технологического дизайна описывает, какие технологии и продукты выбраны проектной группой в качестве средства реализации решения.
Аргументировано опишите, какие технологические средства будут использованы в процессе работы над решением.
Проектный практикум
Негосударственное образовательное учреждение
«МОСКОВСКИЙ ПСИХОЛОГО-СОЦИАЛЬНЫЙ УНИВЕРСИТЕТ»
ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Проректор по учебной работе
Рабочая программа дисциплины
230700 – ПРИКЛАДНАЯ ИНФОРМАТИКА
Прикладная информатика (в экономике)
Квалификация (степень) выпускника
Рекомендовано Ученым советом НОУ ВПО «МПСУ»
(протокол № ___ от 20____г.)
(протокол № _____ от 20___ г.)
Зав. кафедрой ______________________________
, кандидат педагогических наук, кафедра «Информационных технологий», для студентов 4 курса, обучающихся по направлению: 230700 – «Прикладная информатика», профиль «Прикладная информатика (в экономике)», степень (квалификация) – бакалавр.
В программе представлены цели освоения дисциплины; место дисциплины в структуре ООП бакалавриата; компетенции обучающегося, формируемые в результате освоения дисциплины; структура и содержание дисциплины; образовательные технологии; учебно-методическое обеспечение самостоятельной работы студентов; оценочные средства для текущего контроля успеваемости, промежуточной аттестации по итогам освоения дисциплины; учебно-методическое и информационное обеспечение дисциплины; материально-техническое обеспечение дисциплины.
1. Цели освоения дисциплины
Целями освоения дисциплины «Проектный практикум» является приобретение умений и навыков методологических основ проектирования информационных систем (ИС) и владения соответствующим инструментарием, приобретение умений и навыков методики системного и детального проектирования ИС.
2. Место дисциплины в структуре ООП бакалавриата
Дисциплина позволяет сформировать системные знания по одной из наиболее важных проблем применения информационных технологий.
Необходимыми и достаточными условиями изучения дисциплины являются:
оснащение лекционной аудитории техническими средствами обучения: персональный компьютер, мультимедийный проектор, проекционный экран;
проведение практических занятий в компьютерной лаборатории, с обязательным оснащением каждого обучаемого автоматизированным рабочим местом с доступом в Интернет;
наличие у обучаемых начальных навыков работы с операционной средой персонального компьютера, прикладным программным обеспечением.
Дисциплина изучается в 7 семестре для очной и заочной форм обучения.
Дисциплины учебного плана, которые идут до изучения данной дисциплины и с ней взаимосвязаны:
«Имитационное моделирование экономических процессов»;
«Проектирование информационных систем».
Данная дисциплина изучается на заключительном этапе обучения в очной форме обучения.
При заочной форме обучения дисциплины учебного плана, которые идут после изучения данной дисциплины и с ней взаимосвязаны::
«Предметно-ориентированные информационные и экономические системы».
3. Компетенции обучающегося, формируемые в результате освоения дисциплины «Проектный практикум»
В результате освоения программы дисциплины «Проектный практикум» студенты должны осуществлять проектирование ИС от этапа постановки задачи до программной реализации с учетом требований профиля подготовки – «Прикладная информатика (в экономике)».
В результате освоения дисциплины обучающийся должен:
о предметных взаимосвязях информационного менеджмента с теорией информационных систем, проектированием информационных систем, базами данных и знаний, системами искусственного интеллекта, производственным и инновационным менеджментом, экономикой информатики, системным анализом операционными системами;
основы информационного менеджмента;
выполнять все виды проектных работ по созданию ИС;
навыками работы с инструментальными средствами моделирования предметной области, прикладных и информационных процессов; навыками разработки технологической документации; навыками использования функциональных и технологических стандартов ИС в области экономики.
В результате освоения дисциплины формируются следующие компетенции:
способен самостоятельно приобретать и использовать в практической деятельности новые знания и умения, стремится к саморазвитию (ОК-5);
способен осознавать социальную значимость своей будущей профессии, обладать высокой мотивацией к выполнению профессиональной деятельности (ОК-6);
способен использовать технологические и функциональные стандарты, современные модели и методы оценки качества и надежности при проектировании, конструировании и отладке программных средств (ПК-7);
способен анализировать рынок программно-технических средств, информационных продуктов и услуг для решения прикладных задач и создания информационных систем (ПК-19);
способен выбирать необходимые для организации информационные ресурсы и источники знаний в электронной среде (ПК-20).
4. Структура и содержание дисциплины «Проектный практикум»
Общая трудоемкость дисциплины: 5 зачетных единиц, 180 часов.
Очная форма обучения (срок обучения 4 года)
Виды учебной работы, включая самостоятельную работу студентов и трудоемкость (в часах)
Формы текущего контроля успеваемости
Форма промежуточной аттестации
Из них аудиторные занятия
Практическ. занятия /семинары
Опрос, проверка заданий, оценка результатов
Тема 2 Предпроектное обследование предметной области.
Опрос, проверка заданий, оценка результатов
Тема 3 Концепция проекта.
Опрос, проверка заданий, оценка результатов
Тема 4 Системная архитектура проекта.
Опрос, проверка заданий, оценка результатов
Тема 5 Оценка затрат проекта.
Опрос, проверка заданий, оценка результатов
Тема 6 Завершение проекта.
Опрос, проверка заданий, оценка результатов, курсовой проект
Заочная форма обучения (срок обучения 5 лет)
Виды учебной работы, включая самостоятельную работу студентов и трудоемкость (в часах)
Формы текущего контроля успеваемости
Форма промежуточной аттестации
Из них аудиторные занятия
Практическ. занятия /семинары
Опрос, проверка заданий, оценка результатов
Тема 2 Предпроектное обследование предметной области.
Опрос, проверка заданий, оценка результатов
Тема 3 Концепция проекта.
Опрос, проверка заданий, оценка результатов
Тема 4 Системная архитектура проекта.
Опрос, проверка заданий, оценка результатов
Тема 5 Оценка затрат проекта.
Опрос, проверка заданий, оценка результатов
Тема 6 Завершение проекта.
Опрос, проверка заданий, оценка результатов, курсовой проект
Данные; информация; информационный процесс; информационная система; классификация информационных систем; общий функционал информационных систем; типовые функциональные компоненты информационных систем; понятие архитектуры информационных систем; требования, предъявляемые к информационным системам.
Тема 2 Предпроектное обследование предметной области.
Анализ первичных документов. Анализ законодательства и управляющих документов. Интервьюирование. Анкетирование. Анализ штатного расписания. Исследование документов и отчетов предметной области. Формирование модели деятельности.
Тема 3 Концепция проекта.
Анализ требований. Разработка технического задания. Документ Видение. Предварительное специфицирование. Контекстное моделирование.
Тема 4 Системная архитектура проекта.
Описательная модель предметной области; жизненный цикл приложения баз данных; определение требований к системе; пользовательские представления; сбор и анализ требований пользователей; типы СУБД и моделей данных; проектирование базы данных; подходы к проектированию базы данных; моделирование данных; этапы проектирования базы данных; концептуальное проектирование: модель «сущность-связь»; расширенная модель «сущность-связь»; разработка приложений; рекомендации по проектированию пользовательского интерфейса; создание прототипов; реализация.
Тема 5 Оценка затрат проекта.
Бизнес-планирование. Операционная деятельность. Инвестиционная деятельность. Финансовая деятельность. Оценка эффективности инвестиций. Функционально-стоимостной анализ процессов. Оценка экономического внедрения программного обеспечения.
Тема 6 Завершение проекта.
Важность грамотного завершения проекта. Как определить момент окончания проекта. Функция руководителя проекта на завершающем этапе. Процесс завершения проекта. Роспуск команды, работавшей над проектом. Закрытие банка данных проекта. Завершение работ. Завершающая проверка и подведение итогов проекта. Сохранение материалов, имеющих отношение к проекту. Постпроектная оценка.
5. Образовательные технологии
Реализация дисциплины «Проектный практикум» сопровождается использованием элементов активных и интерактивных форм проведения занятий (с использованием новейших информационных технологий обучения) на основе следующих педагогических технологий:
Логика проведения занятий:
2. Актуализация субъективного опыта студента.
3. Организация восприятия.
4. Организация осмысления.
5. Первичная проверка понимания.
6. Организация первичного закрепления.
Лекции и интерактивные занятия по дисциплине «Проектный практикум» реализуются с использованием как указанных выше активных, так и интерактивных форм обучения, позволяющих взаимодействовать в процессе обучения не только преподавателю и студенту, но и студентам между собой.
6. Учебно-методическое обеспечение самостоятельной работы студентов. Оценочные средства для текущего контроля успеваемости, промежуточной аттестации по итогам освоения дисциплины.
Перечень примерных вопросов (эссе, рефератов) для самостоятельной работы обучающихся:
1. Понятие данных, информации, информационного процесса, информационной системы.
2. Классификация информационных систем: по масштабу, по сфере применения, по способу организации.
3. Требования, предъявляемые к информационным системам.
4. Понятие архитектуры информационной системы. Способы представления.
5. Понятие жизненного цикла информационных систем.
6. Понятие проекта. Классификация проектов.
7. Фазы проектирования: концептуальная, подготовка технического предложения, проектирование, разработка, ввод в эксплуатацию.
8. Процессы жизненного цикла информационных систем. Основные процессы жизненного цикла.
9. Процессы жизненного цикла информационных систем.
10. Вспомогательные процессы жизненного цикла.
11. Процессы жизненного цикла информационных систем. Организационные процессы жизненного цикла.
12. Структура жизненного цикла информационных систем.
13. Модель жизненного цикла информационных
14. Понятие профиля информационной системы. Принципы формирования профиля информационной системы.
15. Понятие профиля информационной системы. Структура профилей информационных систем.
17. CASE-технологии проектирования информационных систем. Характеристика CASE-средств. Примеры.
18. Построение модели данных.
19. Математическая модель информационной системы. Классификация математических моделей.
20. Имитационная модель информационной системы. Классификация имитационных моделей.
1. Ведение журналов успеваемости и посещаемости
2. Ведение учебной нагрузки
3. Заполнение листка по учету кадров
4. Направление работника в командировку
5. Перевод работника на другую работу
6. Предоставление отпуска работнику
7. Прием работника на работу
8. Прием товара на склад
9. Прием-передача товарно-материальных ценностей
10. Проведение репетиционных занятий
11. Проведение экзамена
12. Составление индивидуального плана
14. Увольнение работника
16. Учет материалов
17. Учет некачественного товара при приеме на склад
18. Учет основных средств и нематериальных активов
19. Учет поступления товарно-материальных ценностей
Вопросы для экзамена:
1. Понятие данных, информации, информационного процесса, информационной системы. Примеры.
2. Классификация информационных систем: по масштабу, по сфере применения, по способу организации. Задачи классификации.
3. Требования, предъявляемые к информационным системам: гибкость, надежность, эффективность, безопасность.
4. Понятие архитектуры информационной системы. Способы представления. Примеры.
5. Понятие жизненного цикла информационных систем. Понятие проекта. Классификация проектов.
6. Фазы проектирования: концептуальная, подготовка технического предложения, проектирование, разработка, ввод в эксплуатацию.
7. Процессы жизненного цикла информационных систем. Основные процессы жизненного цикла.
8. Процессы жизненного цикла информационных систем. Вспомогательные процессы жизненного цикла.
9. Процессы жизненного цикла информационных систем. Организационные процессы жизненного цикла.
10. Структура жизненного цикла информационных систем. Начальная стадия.
11. Структура жизненного цикла информационных систем. Стадия уточнения.
12. Структура жизненного цикла информационных систем. Стадия конструирования.
13. Структура жизненного цикла информационных систем. Стадия ввода в эксплуатацию.
14. Модель жизненного цикла информационных систем. Каскадная модель. Преимущества и недостатки.
15. Модель жизненного цикла информационных систем. Спиральная модель. Преимущества и недостатки.
16. Методология быстрой разработки информационных систем. Основные принципы методологии.
17. Методология быстрой разработки информационных систем. Фазы жизненного цикла информационных систем в рамках методологии. Фаза анализа и планирования требований.
18. Методология быстрой разработки информационных систем. Фазы жизненного цикла информационных систем в рамках методологии. Фаза проектирования.
19. Методология быстрой разработки информационных систем. Фазы жизненного цикла информационных систем в рамках методологии. Фаза построения.
20. Методология быстрой разработки информационных систем. Фазы жизненного цикла информационных систем в рамках методологии. Фаза внедрения.
21. Понятие профиля информационной системы. Принципы формирования профиля информационной системы.
22. Понятие профиля информационной системы. Структура профилей информационных систем.
24. CASE-технологии проектирования информационных систем. Характеристика CASE-средств. Примеры.
25. Построение модели данных. Основные понятия и определения.
26. Построение модели данных. Этапы моделирования. Концептуальное моделирование.
27. Построение модели данных. Этапы моделирования. Логическое моделирование.
28. Построение модели данных. Этапы моделирования. Физическое моделирование.
29. Построение модели данных. Модель предметной области.
30. Математическая модель информационной системы. Классификация математических моделей.
31. Имитационная модель информационной системы. Классификация имитационных моделей.
7. Учебно-методическое и информационное обеспечение дисциплины «Проектный практикум»
а) Основная литература:
Борисов : учебник и практикум для вузов. – М.: Издательский, 2010. – 596 с.
Михеева технологии в профессиональной деятельности. Учебное пособие для студентов учреждений среднего профессионального образования. 10-е изд., изд. Academia. М.: 2012.
Михеева по информационным технологиям в профессиональной деятельности. Учебное пособие для студентов учреждений среднего профессионального образования. 10-е изд.. М.: Academia. 2012.
. Теория экономических информационных систем. Издательство: Финансы и статистика. 2007.
, Барикаев менеджмент. Издательство: Юнити-Дана, 2012.
б) Дополнительная литература:
Исаев технологии. Учебное пособие. – М.: Омега-Л, 2012.
Информационные системы в экономике. Издательства: Форум, Инфра-М, 2009.
в) программное обеспечение и Интернет-ресурсы:
Операционная система Windows XP или выше.
8. Материально-техническое обеспечение дисциплины «Проектный практикум»
Компьютерная учебная аудитория с доступом в Интернет, видеопроектор, мультимедийные презентации, учебно-методический материал в электронном виде.