Дипломная работа: Автоматизация бизнес-процессов продажи билетов ООО "Зритель"
Примеров подобного контроля из области техники можно привести множество (бамперы и дворники автомашин, плавкие предохранители, дублирующие и сети т.д.). В практике конструирования программного обеспечения для предупреждения последствий риска используются строго регламентированные технологические приемы и методы разработки.
Планирование действий в непредвиденных ситуациях. Если шаги, направленные на предупреждение ущерба планируются для данного проекта, их выполнение должно быть проведено как можно быстрее. План действий в непредвиденных ситуациях обеспечивает исключение препятствий на этом пути. Так, чтобы произвести скорейшую замену уволенного работника, у менеджера должен быть заранее готов список лиц, способных занять освобождающуюся вакансию. Составной частью этого плана является резервирование в основном графике работ времени, необходимого для вхождения в курс дела нового исполнителя.
Примерами планирования действий в непредвиденных ситуациях из области техники могут служить запасные детали, а в практике конструирования программного обеспечения — средства отката и архивирования.
Для всех рискованных ситуаций планом управления рисками предусматриваются мероприятия на указанных уровнях в различной комбинации, возможно, дополненные более тонкой реакцией на возникновение риска. Детализация такого плана может быть различной, она зависит от ответственности проекта, его важности для компании и заказчика, с одной стороны, а с другой — от степени новизны проекта, и от наработки технологии его выполнения.
Очень важно, чтобы исполнители проекта были осведомлены о возможных рисках и о плане управления ими. Это создает уверенность в успехе и подготавливает работников к преодолению трудностей. Для менеджера при составлении плана самое важное — не упустить все возможные рискованные ситуации.
Проект с большой долей новаций является рискованным предприятием всегда. По этой причине для него план управления рисками является обязательным и должен быть максимально детализированным в части учета неверных решений, ошибок в оценке ситуаций и т.п.
Многие проекты зависят от окружающих факторов в большей мере, чем от организации дел и подготовленности исполнителей. Анализ рисков в такой ситуации имеет целью компенсации внешней зависимости за счет внутренних ресурсов. И здесь план управления рисками обязателен при подготовке к проекту, но по сравнению с предыдущим случаем в нем несколько смещаются акценты. Так, менеджер должен предусмотреть действия разработчиков, когда оборудование или внешнее программное обеспечение поставляются с задержкой, когда возникают сбои в финансировании, в иных случаях отрицательного внешнего влияния.
По сравнению с традиционным последовательным развитием ориентация проекта на итеративное развитие делает его более устойчивым к рискам, поскольку рабочий продукт каждой итерации планируется не тогда, когда контекст его разработки предсказать можно лишь в общих чертах, а когда он полностью определен. Тем не менее, план управления рисками уместен и здесь. По-видимому, при итеративном развитии наиболее важным для него является распределение реализуемых в проекте требований по итерациям так, чтобы минимизировался риск проекта в целом.
Составление плана управления рисками — это необходимая часть подготовки к началу проекта хотя бы по той причине, что он влияет на распределение ресурсов. Она начинается с фиксации и ранжирования всех возможных рискованных ситуаций и планируемых реакций на них. Кроме того, определяются временные издержки и цена мероприятий, которые планируется выполнять, когда риски проявляют себя. Таким образом, план управления рисками представляет собой перечень рисковых ситуаций с планируемыми реакциями на них, временными издержками и затратами на их проведение. Эти сведения дополняют затратные характеристики проекта и его план-график, тем самым, расширяя схему финансовых и временных потребностей проекта.
Как и в других случаях, при планировании управления рисками детально расписываются рисковые ситуации начала проекта, в том числе, для первой итерации. Грубые оценки рисков последующих периодов корректируются перед каждой очередной итерацией. Другое время, когда целесообразно пересмотреть план управления рисками, — после возникновения рискованной ситуации и ее преодоления. В качестве примера того, что должно быть предусмотрено, можно указать на перераспределение ресурсов, первоначально выделенных на поддержку мероприятий в рисковых ситуациях.
Полезно перед корректировкой планов управления рисками в случае возникновения и преодоления рискованной ситуации провести анализ ситуации. Требуется оценить эффективность предусмотренных, выполненных и невыполненных мероприятий, понять, что могло бы быть лучше организовано, проверить качество предварительных оценок. Опыт, полученный при таком анализе, применяется непосредственно: при пересмотре плана. Это весьма важно, поскольку ситуации, подобные той, которая преодолена, вполне вероятно могут повториться в ходе дальнейшего развития проекта.
Ниже приводится перечень (далеко неполный) ситуаций, которых должен избегать менеджер, и которые он должен учитывать, составляя план управления рисками:
· задержка начала проекта никогда не компенсируется;
· если сетевой график выполняется с большими нарушениями сроков, трудно ожидать создание хорошего продукта;
· если пользовательский интерфейс не является интуитивно понятным и превышает уровень компетенции потребителя изделия, продукт будет плохо распространяться;
· упущенные возможности требуют дополнительных усилий при их более поздней реализации и увеличивают затраты;
· не протестированный продукт снижает репутацию разработчиков;
· не стоит рассчитывать на постоянство пользовательских намерений, никогда нельзя знать, что хочется пользователю и чего на самом деле ему нужно. Как следствие, необходимо планировать время на переделку того, что в начале проекта казалось приемлемым.
2.1.7 Оценка стоимостных параметров проекта автоматизации
При определении финансовых потребностей показатели, задаваемые в ходе выяснения технических и кадровых ресурсов, переводятся в денежное выражение. Для каждого из таких показателей должны быть известны нормативы перевода. Это либо стандартизованные (внешние и внутрифирменные) коэффициенты, либо просто цены используемых в проекте билетов и услуг. Если по каким-либо причинам точных нормативов перевода нет, то вместо них применяются экспертные оценки. Например, при приглашении для участия в проекте конкретного специалиста может оказаться, что требования его заработной платы не соответствуют квалификационной сетке ставок, принятой в компании. Для такого сотрудника приходится вводить индивидуальный норматив перевода почасовой занятости в денежное выражение.
Цены на билеты и услуги также могут варьироваться. В этой связи использование их как нормативов перевода означает не точное определение финансовых потребностей, связанных с приобретением данного билета или с получением услуги, а указание нижней и верхней границ требуемых денежных средств. В практике оценки финансовых ресурсов для программных проектов применяются расчеты следующих видов:
· по минимальной границе цен,
· по максимальной границе цен,
· по средней величине между максимальной и минимальной ценой или
· по средневзвешенной величине.
Последний вариант используется для более точного вычисления, когда удается оценить распределение вероятности приобретения билета или услуги в зависимости от уровня цен.
Составляя минимальную и рациональную схемы распределения потребностей, не следует полагать, что в минимальной схеме затратные характеристики обязательно должны строиться исходя из минимальных цен (хотя и это возможно). Понятие минимальной схемы отражает, прежде всего, результативный аспект рассмотрения заказа, т.е. то, какие минимально необходимые результаты предполагается получить, а с финансовыми расходами оно связано уже во вторую очередь. Полезно для минимальной и для рациональной схем определять как верхнюю, так и нижнюю границы финансовых потребностей проекта.
При использовании цен, как нормативов, нельзя путать вариантность стоимости однородной продукции у различных продавцов и ситуации, когда уровень цены отражает уровень качество билета или услуги. К примеру, более совершенное вычислительное оборудование делает поставку дороже, чем при использовании бытовых аналогов, программная система может работать как в облегченной, так и в полной конфигурации оборудования. Все подобные качественные вариации проекта следует отмечать в документах, отражая их влияние на объем, качество результатов, и сроки разработки.
Финансовые потребности проекта рассчитываются по-разному для краткосрочных и долгосрочных проектов. Это связано с тем, что для длительных проектов начинает играть роль инфляционный фактор, и, как следствие, приходится учитывать дисконтирование. Иными словами, обсуждая проектные решения, необходимо оперироваться информацией, выраженной в сопоставимых ценах.
Приведение поздних затрат к ценам начального периода развития проекта осуществляется путем введения поправочного коэффициента дисконтирования:
Дt = (1 + б) t,
гдеб—дисконт (число из интервала 0…1),
t—время платежа, указываемое от начала проекта.
Этот коэффициент показывает, что сегодняшняя покупка билета за p единиц эквивалентна покупке его за (1 + б) t * p через t лет при условии сохранения сегодняшних денег в банке с банковским процентом б в течение t лет. Примерно в таком соотношении и происходят инфляционные процессы. Величина коэффициента дисконтирования зависит от экономической ситуации, а не условий заключения контракта. В частности, по этой причине невозможно точно сказать, какие сроки проекта характеризуют его как длительный.
Определяя финансовые потребности проекта, надо четко разграничивать ситуации, когда документ предъявляется заказчику и когда он остается во внутрифирменном документообороте. Как указывалось выше, все внешние документы должны проходить через бухгалтерский контроль, в ходе которого они могут претерпеть изменения.
Распределение предоставляемых финансовых средств:
Как бы точно ни была рассчитана финансовая потребность проекта, реальная жизнь вносит свои коррективы в априорный план. В этой связи задача распределения финансовых средств возникает независимо от того, какого типа проект выполняется.
Как и для распределения времени на стадии подготовки к проекту можно говорить не о конкретном распределении финансовых средств, а лишь о стратегии. Основная задача здесь заключается в том, чтобы обеспечить максимально быстрое получение первых результатов, т.е., имея в виду объектно-ориентированный подход, необходимо приложить усилия для скорейшего выполнения первой итерации. Причина здесь в том, что только решение конкретных задач проекта (в частности, ближайших задач, являющихся первыми из них) дает основание для предъявления заказчику счета на проведенные работы. До тех пор все затраты, связанные с проектом носят авансовый характер.
Основой стратегии распределения финансовых средств служат календарный план, сетевой график и рассчитанные финансовые потребности проекта. По ним менеджер составляет смету проекта с привязкой затрат к срокам их проведения. Утвержденная смета — есть фиксированное распределение финансовых ресурсов. Неутвержденная смета требует своего пересмотра, иными словами, перераспределения финансовых ресурсов.
Неутверждённые сметы возможно в трех случаях:
· при обнаружении в ней разного рода ошибок;
· при нарушении общего баланса: суммарные расходы превышают суммарные плановые доходы;
· при локальном (в какие-либо периоды) расхождении предоставляемых средств с объявленной в смете потребностью.
Первый случай неинтересен для рассмотрения: ошибки должны быть исправлены и процедура утверждения сметы повторена. В качестве типичной ошибки менеджера можно указать на нарушение нормативов затрат. Иногда такое нарушение можно обосновать (например, в случае изменения цен на рынке билетов и услуг), и тогда рассмотрение представленной менеджером сметы становится оправданным. В противном случае менеджеру предлагается привести смету в соответствии с принятыми показателями.
Если по смете выходит, что суммарные расходы превышают суммарные плановые расходы (случай 2), то менеджер должен попытаться объяснить руководству причины расхождений и попытаться обосновать предложенный вариант расходов. Если обоснование менеджера принимается, то руководство решает, фирма или заказчик должны нести дополнительные (сверхсметные) расходы. Варианты распределения дополнительных расходов, предлагаемых заказчику, могут быть различными: оплата счетов, включение в итоговые расчеты и т.п. Когда заказчик не соглашается ни на один из вариантов, то либо контракт расторгается, либо дополнительные расходы несет фирма, либо заказ выполняется в сокращенном объеме. Если предусматривается продолжение работ, то от менеджера требуется идентификации ситуаций, в которых проявляется расхождение между объявленной в новой смете потребностью и первоначально выделяемых средств. Таким образом, в указанных условиях случай 2 сводится к случаю 3 или к утверждению новой сметы.
В третьем случае ставится болезненная задача перераспределения ресурсов, найти решение которой необходимо менеджеру. Ниже предлагается один из возможных подходов к перераспределению, согласно которому выполняются следующие шаги:
Выделить работы, которые можно отложить, не нарушая сетевого графика проекта (возможны сдвиги времени планируемого начала работы, изменение фактической продолжительности работы, когда это сокращает ресурсную потребность работы).
Выделить работы, которые можно отложить, c нарушением времени выполнения проекта и за счет этого сократить ресурсную потребность, как это делается на шаге 1. Согласовать с заказчиком перенос сроков.
Выделить части операционных маршрутов сетевого графика, соответствующие работы которых относительно замкнуты и допускают независимую разработку, и оценить их финансовую потребность. Определить наиболее ресурсоемкие из таких частных маршрутов и результирующие работы, выполнение которых не может быть осуществлено без прохождения каждого из них. Установить и согласовать с заказчиком, какими из этих работ можно пожертвовать с незначительной потерей достигаемых целей проекта.
Частный случай предыдущего: произвести переоценку значимости достигаемых целей и соответствующих им работ. Быть может, в проекте чрезмерное внимание уделено демонстрационным задачам, повышению эффективности. Возможно, что проект перегружен за счет работ, ориентированных на переиспользование в будущем. Этот список легко продолжить.
Выделить максимально большую часть работ проекта, которая выполнима при заданном финансировании.
Общий принцип любой стратегии распределения финансов состоит в том, чтобы максимально полно обеспечить финансовую потребность решения ближайших задач проекта.
2.2 Информационное обеспечение задачи
2.2.2 Информационная модель и её описание
Задача использует одну БД, которая размещена вместе с сайтом системы. Ниже (табл. 2.3) приведена таблица наборов данных задачи.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
