Жизненный цикл проекта (фазы, стадии)

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

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

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

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

          3.3 Модели жизненного цикла программного обеспечения (каскад, спираль и др.)

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

Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

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

Этапы проекта в соответствии с каскадной моделью:

Формирование требований;

Пректирование;

Реализация;

Тестирование;

Внедрение;

Эксплуатация и сопровождение.

          Преимущества:

Полная и согласованная документация на каждом этапе;

Легко определить сроки и затраты на проект.

Недостатки:

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

Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения.

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

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже».

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

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

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;

необходимость выполнения ещё одной итерации;

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

целесообразность прекращения проекта.

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

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

Дефицит специалистов.

Нереалистичные сроки и бюджет.

Реализация несоответствующей функциональности.

Разработка неправильного пользовательского интерфейса.

Перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток изменений.

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

Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

Недостаточная производительность получаемой системы.

Разрыв в квалификации специалистов разных областей.

ЗАКЛЮЧЕНИЕ

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

Список использованной литературы:

1. Басовский Л.Е. Теория экономического анализа: Учебное пособие. – М.: ИНФРА-М, 2006.

2. Бузова И. А., Маховикова Г. А., Терехова В. В. Коммерческая оценка инвестиций /под ред. Есилова В.Е. — СПб.: Питер, 2006.

3. Дитхелм Г. Управление проектами. В 2 т. Т. II: Пер. с нем. – СПб.: Издательский дом Бизнес-пресса, 2005.

4. Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: Учеб. Пособие для вузов. Под общ. Ред. И.И. Мазура. – М.: ЗАО Издательство Экономика, 2007.

5. Максимова В.Ф. Инвестиционный менеджмент М.: Московская финансово-промышленная академия, 2005.

6. Ханс-Д. Литке и Илонка Кунов. пер. с нем. М.Э. Реш. Управление проектами/– М.: Издательство Омега-Л, 2006.

2