Жизненный цикл it проекта реферат

Обновлено: 02.07.2024

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

Результаты проекта

При выполнении проекта по информатизации организация преследует одну или несколько целей из следующего списка [1]:

· снижение издержек (экономия) в сфере ИТ; Пример 1: внедренный проект позволил высвободить 2 рабочих места среди ИТ-специалистов, которые теперь можно использовать на другие цели. Результат проекта (экономия): заработная плата 2 специалистов, расходы на содержание их рабочих мест, расходные материалы, амортизация оборудования – компьютеры, принтеры, программное обеспечение и т.д. (суммы, руб.) Пример 2: Внедренная информационная система позволила использовать меньшее количество ИТ-ресурсов (компьютеры, принтеры, расходные материалы) Результат: суммы экономии этих ресурсов.

· снижение издержек (экономия) в бизнес-процессе (процессах) производственной, коммерческой, управленческой или другой сферы на предприятии; Пример: внедренный проект позволил отказаться от ручного ввода информации специалистом отдела продаж, что занимало 40% его рабочего времени ( 40% от суммы оплаты труда), снизить затраты на маркетинговые исследования, на непроизводительные транспортные расходы, снизить затраты на производство, отказаться от услуг сторонней организации (сумма оплаты их услуг)

· получение прибыли, непосредственно связанное с использованием нововведений в сфере ИТ; Пример 1: создан новый Интернет-проект, который позволил продавать новую или существующую продукцию. Полученная прибыль от этого – это результат внедрения проекта. Пример 2: В банке создана система электронных платежей с помощью пластиковых карточек. Полученная от операций прибыль – это результат проекта.

· получение прибыли в бизнес-процессах производственной, коммерческой, управленческой или другой сферы на предприятии; Пример: внедрение проекта позволило делать улучшенную продукцию, продавать ее дороже, предоставить дополнительный платный сервис, увеличить объем сбыта (суммы за каждую из этих позиций)

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

Таким образом, первая задача – определить, какие из вышеперечисленных результатов способен дать проект (один или несколько). (Следует иметь в виду, что в вышеприведенном списке сложность подсчета несколько возрастает от первых к последним ).

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

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

Жизненный цикл ИТ-проекта

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

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

Оценивать инвестиции принято с точки зрения проекта в целом, а значит, на весь период, когда планируется внедрять и использовать ИТ и ИС. Повторим, если какой-либо этап не будет учтен, то не будут учтены и затраты (и/или результаты) на этом этапе, а значит, расчет эффективности будет неверным, а эффективность завышенной (заниженной). Поэтому первым шагом становится определение сроков реализации проекта. [3]

Желательно сделать это с максимально большей подробностью, как по отдельным составляющим стадий (этапов), так и по их срокам.(см. примеры – Табл.1 и 2)

Период Стадия
01.01.05 - 30.04.05 01.01.05 – 01.02.05 01.02.05 – 01.03.05 01.03.05 – 01.04.05 01.04.05 – 01.05.05 Создание технического задания (заказа) Выдвижение руководством идеологии и основных задач будущей системы Информирование руководителей отделов Согласование заявок руководителей отделов Общее согласование и утверждение плана будущей информационной системы
01.05.05 – 31.10.05 01.05.05 -01.08.05 01.08.05 -01.10.05 01.10.05 -31.10.05 Приобретение/изготовление -блок А -блок Б и С - блок Д
01.11.05 – 15.05.06 01.11.05 -01.12.05 01.12.05 -01.04.06 01.04.06 -15.05.06 Внедрение/настройка -блок А -блок Б и С - блок Д
16.05.2006 – 16.05.2012 16.05.06 -15.05.07 16.05.07 -16.05.12 эксплуатация мощность 200 единиц мощность 400 единиц
(? - ?) ( общий срок - 45 дней) Вывод из эксплуатации (замена)

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

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

Если содержание этапов и процессов жизненного цикла ориентировать на стандарт ISO/IEC 12207, таблица сроков реализации может иметь следующий вид. (См. таблицу 2)

Гост

ГОСТ

Введение

Управление ИТ-проектами – это осуществление контроля над решением целого ряда задач, таких как:

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

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

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

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

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

Готовые работы на аналогичную тему

Моделирование при разработке ПО

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

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

К основным моделям жизненных циклов ПО относятся:

  1. Каскадная (водопадная) модель.
  2. V-образная модель.
  3. Инкрементная модель.
  4. Спиральная модель.
  5. Гибкая модель.
  6. Модель-скрам.

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

Виды моделей жизненных циклов ПО

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

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

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

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

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

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

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

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

Жизненный цикл проекта в IT – непрерывный процесс, который заканчивается, лишь когда его решают закрыть. Если вы придумали идею продукта и обратились к команде разработчиков, приготовьтесь, впереди много работы. О Силиконовой долине помечтаем позже. : )

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

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

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

Итак, что же входит в жизненный цикл продукта?

Жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC) – условная схема, включающая фазы создания программного обеспечения. Цикл разработки предлагает шаблон, использование которого облегчает проектирование, создание и выпуск качественного программного обеспечения. На выходе должен получиться экономически выгодный продукт, отвечающий требованиям заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жизненный цикл проекта в IT – непрерывный процесс, который заканчивается, лишь когда его решают закрыть. Если вы придумали идею продукта и обратились к команде разработчиков, приготовьтесь, впереди много работы. О Силиконовой долине помечтаем позже. : )


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

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

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

Итак, что же входит в жизненный цикл продукта?

Жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC) – условная схема, включающая фазы создания программного обеспечения. Цикл разработки предлагает шаблон, использование которого облегчает проектирование, создание и выпуск качественного программного обеспечения. На выходе должен получиться экономически выгодный продукт, отвечающий требованиям заказчика.

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

Последовательность фаз, из которых состоит жизненный цикл


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

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

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

этапы жизненного цикла

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

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

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


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

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

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

Почему важно правильно воспринимать жизненный цикл продукта


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

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

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

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

Подпишитесь

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

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