Разработка системы индикаторов раннего выявления угроз проектов в области информационных технологий

Результатом работы менеджера проекта является сбор данных и всех сопроводительных документов, необходимых для формирования плана управления проектом. Все собранные наработки он передает руководителю проекта, который, в свою очередь, сводит всю информацию в единый документ и формирует данный план. В случае нехватки и некачественной проработки какой-либо информации, руководитель проекта возвращает часть работ менеджеру проекта на доработку. Менеджер, в свою очередь, совместно со специалистом определённой функции дополняет документацию. В данном процессе некачественная проработка документации является одним из важнейших рисков, последствием которого является необходимость повторной проработки документации и увеличения сроков работ. Соответственно, основная стратегия, возможная при реагировании на риски по данной группе работ -- это принятия, а именно проведение повторных итераций по сбору и анализу информации о проекте и отработка всех возникших у руководства комментариев. Индикатором оценки степени важности риска является количество реализуемых доработок. Если их число превышает среднее число доработок, которые обычно были необходимы для смежных по тематике проектов, данный риск становится более опасным. Выбранная стратегия принятия риска не способна противодействовать его отрицательным последствиям, и менеджеру необходимо переходить к другим инструментам. Вторая возможная стратегия -- это передача риска, которая представляет собой эскалацию работы на более высокий корпоративный уровень. В данном случае руководитель проекта самостоятельно интервьюирует специалистов функций и вносит доработки в текущие версии документов проекта. Точно такая же система возможна на следующем этапе работ, на согласовании уже готового плана управления проектом на Проектном комитете. Риском является отказ от согласования данного плана. А от количества требуемых доработок зависит степень важности возникшего риска. В случае большого количества доработок, их реализация должна проходить с участием вышестоящего органа, а именно Дирекции розничных продаж.

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

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

2. Предупреждающее воздействие; Внесение изменений, связанных с будущим исполнение планов управления проектом;

3. Исправление дефекта; Намерение действие, связанное с исправлением результатов работы, не соответствующих требованиям.

4. Обновление. Формальное изменение проектной документации.

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

Рисунок 10. План управления проектом. Этап №1 Планирование

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

Этап 2. Реализация (контроль и мониторинг)

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 11. План управления проектом. Этап №2 Реализация

Этап 3. Завершение

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

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

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

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

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

Рисунок 12. План управления проектом. Этап №3 Завершение

Стратегии реагирования на риски ИТ-проектов

Сформированный план управления проектом включает в себя описание процессов управления на всех стадиях реализации ИТ-проекта. В рамках данного плана предусмотрены процессы мониторинга и контроля реализации работ, на основе который возможно выявить различные виды угроз и принять соответствующие меры реагирования. Данные меры определяются исходя из заранее определённых стратегий реагирования на возникающие угрозыдолжны опираться на политики и процедуры, установленные в плане управления рисками[3]. Для части рисков предусмотрено два вида стратегий реагирования. Выбор стратегии зависит от степени угрозы, на основе которых выделяются стратегии первого уровня, когда степень угрозы невелика, и стратегия второго уровня, когда перед для проекта возникает опасная угроза. Перечень стратегий для каждого из вида рисков представлен в таблице.

Таблица 11. Стратегии реагирования на риски

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

В качестве стратегии второго уровня чаще всего принимается стратегия уклонения. Данные меры представляют собой более радикальные меры, нежели стратегии снижения рисков. В рамках стратегии уклонения от рисков руководитель проекта вносит коррективы в план управления и цели проекта. Ключевой задачей данного решения является попытка полностью исключить вероятность воздействия риска. Например, один из рисков, для которого в качестве стратегии второго уровня была выбрана стратегия уклонения, звучит следующим образом: «Непонимание правил работы сервиса со стороны персонала на АЗС». Данный риск становится критичным, если работники АЗС массово не справляются с финальным тестированием после обучения работе с новой системой. Низкий средний балл означает неготовность сотрудников к работе. Если проблема повсеместная, то это означает, что данный сервис сложен для работников в освоении и требует доработки. В рамках стратегии уклонения команда проекта должна принять решение о сокращении функционала системы, чтобы сделать ее проще. В таком случае, для линейного сотрудника исчезнет вероятность совершения ошибки, процесс работы с данной ИТ-системой станет максимально надежным.

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

Система раннего выявления рисков

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

Система раннего выявление рисков - это проактивное действие по реагирование, которое включает в себя три основных шага:

1. Превентивное действие; Это предварительная стратегия реагирования на выявленный риск. Как правило, данная стратегия может включать в себя меры по контролю и мониторингу действующих бизнес-процессов на предмет возможных угроз. Необходимость перехода к основной стратегии реагирования на угрозы определяется исходя из сигналов, которые мы получаем на основе индикаторов.

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

3. Действие в случае наступления события риска. Применение второй стратегии, план Б.

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

Сформированный план реагирования на риски проекта представлен в таблице.

Таблица 12. План реагирования на угрозы проекта

Подобные документы

• Разработка информационной системы ведения проектов строительной компании ООО "Стройтек"

  Описание структуры управления компании. Структура программно-аппаратных средств. Анализ технического задания. Расчет обобщенного критерия эффективности информационной системы ведения проектов строительной компании. Выбор языка программирования и СУБД.
  
  дипломная работа [2,1 M], добавлен 29.06.2013
  

• Формирование требований при разработке ПО

  Проблемы современных проектов разработки ПО. Причины неудач программных проектов. Ошибки требований и стоимость переделок. Основная фундаментальная идея программной инженерии. Типы нефункциональных и эксплуатационных требований к программному обеспечению.
  
  презентация [3,2 M], добавлен 19.09.2016
  

• Разработка проекта базы данных для АИС "Учет Проектов"

  Методология концептуального проектирования баз данных для АИС "Учет Проектов". Построение концептуальной модели. Диаграмма "сущность-связь". Нотация диаграммы "сущность-связь". Спецификация сущностей. Построение логической модели. Формирование запросов.
  
  курсовая работа [524,4 K], добавлен 28.11.2008
  

• Разработка методического сайта для подготовки школьников к написанию научных проектов

  Понятие технологии проектирования информационных систем. Создание Web-приложения по подготовке школьников к написанию научных проектов с использованием различных диаграмм, наглядно отображающих структуру приложения. Методология моделирования IDEFX.
  
  курсовая работа [1,8 M], добавлен 07.01.2014
  

• Характеристики проектов разработки программного обеспечения

  Оценка финансовой, стратегической ценности и уровня рисков проекта. Классификация проектов: "свой" заказчик, продукт под заказ, тиражируемый продукт, аутсорсинг. Организация процесса разработки программного обеспечения, методологии его проектирования.
  
  презентация [82,8 K], добавлен 07.12.2013
  

• Разработка программных средств системы мониторинга автоматов продажи проездных билетов

  Интерфейс системы онлайн-мониторинга стационарного аппарата. Интерфейс автоматизированного рабочего места мониторинга АПБ Московского метрополитена. Архитектура системы ProView, основные сферы применения. Структура графического интерфейса пользователя.
  
  курсовая работа [1,8 M], добавлен 21.03.2016
  

• Разработка онлайн-сервиса для подбора спортивного снаряжения

  Знакомство с особенностями и основными этапами разработки онлайн-сервиса, облегчающего потребителям процесс подбора спортивного снаряжения. Анализ оборудования для вейкбординга. Общая характеристика клиент-серверной архитектуры реализации веб-приложения.
  
  дипломная работа [4,1 M], добавлен 30.09.2016
  

• Информационные системы управленческого консалтинга

  Использование в организации информационных технологий. Характеристика управленческого консалтинга в сфере информатизации. Цели и этапы разработки консалтинговых проектов. Обследование деятельности предприятия, построение моделей и реализация системы.
  
  контрольная работа [77,7 K], добавлен 23.01.2012
  

• Разработка системы мониторинга на основе тестового контроля знаний

  Выбор сервера базы данных, инструментальных средств разработки клиентского интерфейса и технологий. Описание таблиц базы данных системы мониторинга. Разработка инструментальных средств создания элементов системы. Интерфейс генерации тестов. Расчет затрат.
  
  дипломная работа [1,9 M], добавлен 12.03.2013
  

• Разработка информационной системы учета использования оргтехники

  Анализ сред разработки для веб-проектов. Система учета работы элементов информационной инфраструктуры. Создание базы данных и каркаса системы на языке HTML и CSS. Технологии использования и демонстрация работы системы. Экономическое обоснование проекта.
  
  дипломная работа [2,1 M], добавлен 25.06.2014
  

• Тематические "онлайн-магазины"

  Разработка тематических "онлайн-магазинов". Обоснование выбора информационных технологий. Архитектурное решение проекта. Разработка модели базы данных магазина. Схема базы данных на языке SQL. Интернет-магазины "ebay.com", "onliner.by", "eda.by".
  
  курсовая работа [1,1 M], добавлен 24.06.2013
  

• Инструментальные средства автоматизации процесса реализации инновационных проектов

  Ознакомление с современным состоянием и проблемами развития российской инновационной среды. Разработка системы автоматизации управления инновационными проектами на предприятиях. Рассмотрение интерфейса программного продукта и руководства пользователя.
  
  курсовая работа [2,8 M], добавлен 09.04.2012
  

• Разработка информационной системы с Web-доступом для предприятия социально-культурной сферы

  Области применения и реализации информационных систем. Анализ использования Web-технологий. Создание физической и логической модели данных. Проектирование информационных систем с Web-доступом. Функции Института Искусств и Информационных Технологий.
  
  дипломная работа [3,8 M], добавлен 23.09.2013
  

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

  Разработка инструментария для оценки мультипликативного эффекта, возникающего в результате реализации некоторого варианта транспортной стратегии, порождаемого оперативными сценарными расчетами по системе используемых моделей. Требования к программе.
  
  дипломная работа [1,3 M], добавлен 08.12.2013
  

• Разработка проекта внедрения системы автоматизации продаж на примере ООО "Логистика"

  Применение инновационных интернет-технологий при разработке проекта внедрения системы автоматизации продаж с целью повышения эффективности работы региональных представителей компании на примере ООО "Логистика". Особенности организации сбыта в Интернете.
  
  дипломная работа [1,6 M], добавлен 31.01.2015
  

• Разработка проекта внедрения системы контроля и управление доступом

  Технологии управления доступом в помещение. Организационно-управленческая характеристика ООО "Новые информационные технологии". Анализ системы технического и программного обеспечения. Разработка проекта системы контроля и управления доступом "Кодос".
  
  дипломная работа [71,6 K], добавлен 16.01.2014
  

• Разработка автоматизированной информационной системы на примере "МегионСофтОйл"

  Разработка автоматизированной информационной системы для учета и контроля выполнения ремонтных работ, и предоставления услуг по разработке программного обеспечения компании "МегионСофтОйл", разработка алгоритмов приложений программной системы и модулей.
  
  дипломная работа [5,3 M], добавлен 29.06.2012
  

• Разработка веб-сервиса "Записная книжка"

  Создание простой в использовании онлайн записной книжки, позволяющей вести записи, хранить файлы и создавать напоминания. Характеристика пользователей. Требования к системе. Проектная команда, система управления проектом. Реализация логики работы системы.
  
  курсовая работа [391,8 K], добавлен 16.02.2016
  

• Методика проведения профориентационной работы со школьниками на уроках информатики

  Теория и методология профессиональной ориентации школьников. Метод проектов как средство реализации профориентации на уроках информатики, его сущность. Тематическое планирование курса информатики в 9 классе, предусматривающего применение метода проектов.
  
  дипломная работа [156,0 K], добавлен 20.02.2012
  

• Разработка программы Helpopr

  Разработка эскизного и технического проектов программы, ее назначение и область применения, описание алгоритма, организация входных и выходных данных. Выбор состава технических и программных средств, разработка рабочего проекта, спецификация программы.
  
  курсовая работа [159,8 K], добавлен 26.01.2010
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам