Управление проектом в системах электронной коммерции.

Содержание:

Введение

Бизнес-проект ставит своей целью организацию бизнеса в сфере электронной коммерции.

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

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

Организационно-правовая форма - индивидуальный предприниматель.

Юридический адрес: г. Москва.

Фактический адрес организации: г. Москва.

Инвестиционная стоимость бизнес-проекта составляет 159690 руб. (из них 37,4% субсидия, предоставляемая на организацию предпринимательской деятельности).

Период окупаемости составляет 13 месяцев.

1. Концепция бизнес-проекта

Бизнес-проект ставит своей целью организацию бизнеса в сфере электронной коммерции, которая, в свою очередь, предполагает:

- наличие системы управления компанией;

- использование электронной рекламы и маркетинга;

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

Предполагается, что IT ORION будет осуществлять следующие услуги:

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

- поставку, установку программного обеспечения;

- услуги по сопровождению эксплуатации программного и системного программного обеспечения;

- веб-дизайн - дизайн сайтов и их отдельных элементов, создание графических рекламных материалов в Internet;

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

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

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

Рассматривая актуальность организации данного бизнеса, стоит отметить, что организация ИП Коляда С.В. будет удовлетворять потребности населения города в качественном сопровождении эксплуатационного процесса системного программного обеспечения, которое ориентировано:

- на создание операционной среды функционирования других программ;

- на обеспечение надежной и эффективной работы самого компьютера и вычислительной сети;

- на диагностику и профилактику аппаратуры компьютера и вычислительных сетей;

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

- всевозможные тесты и т. д.

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

- создает списки пользователей, обращавшихся к сетевым ресурсам;

- фиксирует модификации паролей и параметров регистрации;

- выявляет несанкционированные действия.

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

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

Информационная безопасность имеет три основные составляющие:

1 - конфиденциальность - защита чувствительной информации от несанкционированного доступа;

2 - целостность - защита точности и полноты информации и программного обеспечения;

3 - доступность - обеспечение доступности информации и основных услуг для пользователя в нужное для него время.

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

Управление безопасностью - в сетях - средства, обеспечивающие безопасность данных и защищающие ресурсы сети. Средства управления безопасностью осуществляют:

- шифрование и управление ключами расшифровки;

- регистрацию паролей и их идентификацию;

- обслуживание и анализ файлов безопасности;

- защиту от компьютерных вирусов.

2. Спиральная модель

Спиральная модель

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

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

Обзор главных особенностей

Коротко спиральную модель можно описать как повторяющуюся последовательность циклов разработки с непрерывным контролем рисков.

Для лучшего понимая механизма разработки рассмотрим такую схему:

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

Четыре главные фазы это:

1. Определение целей, альтернатив, ограничений, или фаза планирования. С этой стадии начинается работа над проектом. Команда разработчиков формулирует цели проекта, основные требования (такие как, например, Business Requirement Specifications, или BRS, System Requirement Specifications, или SRS), возможный дизайн и т.д. На последующих спиралях требования формируются согласно отзывам, полученным от заказчика. Именно поэтому постоянная коммуникация между заказчиком и командой крайне важна.
2. Анализ, определение и разрешение рисков является одной из самых значимых стадий разработки. В данном контексте, риски — это возможные события и состояния проекта, препятствующие достижению командой разработчиков поставленных целей. Существует довольно обширный диапазон возможных рисков, от тривиальных и легко преодолимых, до крайне серьезных. Главной задачей для команды разработчиков является выявление всех возможных рисков и присвоение им определенного уровня приоритета на основе их значимости. Следующим шагом является разработка возможных стратегий преодоления этих рисков. В итоге этих действий возможны изменения в последующих стадиях разработки. В качестве результата работы на этом этапе создается прототип.
3. Фаза разработки. На этом этапе происходит разработка и последующее тестирование продукта. Во время первой итерации, когда общие требования еще не так четко сформулированы, разрабатывается так называемый концепция будущего продукта (Proof Of Concept), которая необходима для получения отзыва заказчика. На последующих витках спирали рабочие версии продукта, или билды (builds), отправляются заказчику. Это позволяет получить более детальный отзыв и четче сформулировать требования.
4. Планирование следующей фазы. На этом этапе вся полученная информация используется для планирования дальнейших этапов разработки.

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

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

Спиральная модель на примере GanttPRO

В качестве примера применения на практике спиральной модели, рассмотрим GanttPRO — приложение для удобного управления проектами и задачами.

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

Основными задачами, с которыми столкнулась команда разработчиков GanttPRO были:

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

Исходя из особенностей проекта, был выбран короткий период выпуска релизов продукта: две недели. Как следствие, команда уделила особое внимание снижению рисков, вызванных необходимостью быстрой адаптации к нуждам пользователей и рынка.

Процесс разработки состоял из следующих стадий:

1. Определение общей концепции. На этом этапе разработчики обладали только общим видением продукта, который был бы полезен потенциальным пользователям. Мы хотели иметь возможность получать отзывы от пользователей настолько быстро, насколько это возможно. Это помогло бы нам понять более четко, какие именно требования, выдвигаемые пользователями, являются наиболее значимыми. У нас имелись некоторые аналитические данные о том, какие функции могут оказаться наиболее полезными и должны быть разработаны в первую очередь.
2. Планирование первой итерации. После того, как были определены общая концепция и первоначальное видение архитектуры, команда приступила к планированию первой итерации. Наиболее важные требования были помещены в начале списка требований. Затем мы спросили каждого разработчика, как много из того, что было запланировано, может быть реализовано. После этого мы проанализировали каждое требование и определили наилучший способ его разработки. Для более точной оценки были применены методы моделирования и прототипирования.
3. Фаза дизайна. На этом этапе была разработана модель, описывающая функциональность и основные особенности будущего ПО. Далее, модель была обработана нашим дизайнером. Важно было дать наиболее точное и детализированное описание, чтобы разработчики имели возможность справится с поставленными задачами с минимальными затратами.
4. Конструирование и тестирование. На этой стадии команда разработчиков предоставляет рабочее программное обеспечение, которое соответствует изменяющимся требованиям потенциальных пользователей. Что наиболее важно, команда имела возможность развернуть готовое решение в тестовой среде для проведения интеграционного тестирования системы.
5. Инсталляция. На этом этапе разрабатываются механизмы, дающие пользователям возможность доступа к последней версии приложения.
6. Поддержка. В конце каждой фазы разработки у нас был готов работающий продукт, который мы могли предоставить пользователю, на основе чего пользователи могли предоставить нам свой отзыв о текущем состоянии системы. После того, как эти отзывы были проанализированы, мы могли запланировать изменения в последующих итерациях или же включить в проект новые требования, если это требовалось.

Сильные и слабые стороны спиральной модели

У любой модели разработки ПО есть свои сильные и слабые стороны. В этом отношении спиральная модель не является исключением. Давайте рассмотрим ее основные достоинства и недостатки.

Достоинства:

• Мониторинг рисков является одной из главных особенностей, делающих данную модель особенно привлекательной в том случае, если вам предстоит управление большим, сложным и дорогостоящим проектом. Более того, проект будет более прозрачным, поскольку спиральная модель изначально была спроектирована таким образом, чтобы каждая итерация тщательно анализировалась;
• Заказчик может увидеть работающую версию продукта уже на ранних стадиях жизненного цикла ПО;
• Изменения могут быть внесены на поздних стадиях разработки;
• Проект может быть разделен на несколько частей и те из них, которые, согласно анализу, окажутся более рискованными, могут быть реализованы на ранних стадиях. Такой подход может снизить трудности, связанные с управлением проектом;
  Строгий контроль над документацией, как результат постоянного анализа рисков.

Недостатки:

• Мониторинг рисков требует дополнительных ресурсов, а значит, эта модель может оказаться весьма затратной. Каждая итерация требует отдельной экспертизы, что делает управление проектом сложнее. Именно поэтому спиральная модель плохо подходит для небольших проектов;
• Большое количество промежуточных стадий разработки. Как следствие — большой объем документации;
• На самых ранних стадиях дата завершения работы над проектом может быть неизвестна, что также усложняет контроль над процессом разработки

Заключение

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

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

Список литературы

1)Васина А.А. Финансовая диагностика о оценка проектов/А.А. Васина.-СПб:Питер,2004.- 447 с.
2)Грей К. Ф. Управление проектами./К.Ф. Грей ,Э.У.Ларсон .-М:ДИС,2003.-528 с.
3)Локк Д. Основы управление проектами./ Д. Локк .-М: Hippo,2004.-242 c.
4)Ципес Г.Л. Управление проектами : стандарты, методы, опыт./ Г. Л. Ципес, А.С. Товб.- М: Олипм-Бизнес, 2005 г.-239 с.
5)Шапиро В.Д. Управление проектами./ В. Д. Шапиро, И.И. Мазур , Н.Г. Ольдерогге.-СПб.: ”ДваТрИ”,1996.-664 с.
6)Покровский М.А. Основы управления проектами. Учебное пособие. Под ред. Фалько С.Г. М.: Изд-во МГТУ им. Баумана, 1998, 104 с.
7) 13. Матвеева Л. Г. Управление проектами : учебник. – Ростов н/Д. : Феникс , 2009. - 423 с.
8) Под ред Решке Х., Шеллс Х. Мир управления проектами. М.: "Аланс", 1994 - 303 с.
9)Мазур И.И., Шапиро В.Д. и др. Управление проектами (справочник для профессионалов). М.: "Высшая школа", 2001 - 880 с.
10) Щедровицкий Г.П. Организация. Руководство. Управление. (Оргуправленческое мышление: идеология, методология, технология. Курс лекций / из архива Г.П. Щедровицкого. Т.4). М.: "Путь", 2000 - 384 с.