УИТП ПР 5 Задание. Задание в следующей таблице сопоставьте каждый элемент в первом столбце ссоответствующим элементом во втором столбце
 Скачать 97.8 Kb.
|
|
🚣 Групповая работа Задание 1. В следующей таблице сопоставьте каждый элемент в первом столбце с соответствующим элементом во втором столбце: A. Программный продукт должен работать как на платформах Windows, так и Mac **** OS 1) Конечный результат проекта B. Веб-сайт онлайн-образования 2) Ограничение проекта C. Программное обеспечение должно быть разработано в течение шести месяцев. 3) Требования к продукту D. Программный модуль не должен содержать более 10 ошибок. 4) Требования к управлению проектом E. Руководитель проекта должен иметь сертификат PMP. 5) Критерии приемлемости продукта Задание 2. Определите последовательность работ в ситуации, изобразите на сетевом графике. Правление банка поручило менеджеру кадрового отдела, ответственного за оплату труда, разработать схему премирования высшего руководящего состава банка. Как того и требует алгоритм построения сетевого графика, менеджер составил список ключевых задач: начать разработку проекта; встретиться с каждым членом совета директоров и руководителями управлений и выслушать их соображения по поводу системы премирования; на основании результатов встреч составить полный список требований к системе премирования; приобрести описания систем премирования других банков; составить список отличительных черт систем премирования других банков; проконсультироваться у юриста; выяснить, не возникнет ли проблем морально-этического характера при реализации проекта; обсудить пути решения возможных проблем с членами совета директоров и руководителями управлений; разработать систему премирования; провести презентацию. Задание 3. Ответьте на вопросы по описанной ситуации Введение Руслан Адамов, руководитель ИT-проекта в страховой компании «Радуга», только что получил сообщение, что работы по его проекту полностью остановились. Вот уже как шесть часов никаких работ по проекту не выполняется по причине разногласий среди специалистов по поводу требований и спецификаций к результатам проекта. Разногласия касались того, как выполнять одну из задач по проекту, и потенциально приводили к отклонениям от изначально определенных спецификаций. Руслан прекрасно понимал, что дальнейшее выполнение проекта невозможно без разрешения сложившихся разногласий. Если результаты проекта не будут соответствовать спецификациям, то это будет вскрыто во время промежуточных проверок. Потребуется исправление результатов и приведение иx в соответствие спецификации, какими бы совершенными не были бы изменения. Или же потребуются усилия на согласования изменений в спецификации и требования, закрепленные в технической документации. B любом случае возникала серьезная опасность потерять время не только на возникшие разногласия среди специалистов, но и на исправления или дополнительные согласования. Все это сильно нервировало Руслана. «Радуга» Компания «Радуга» представляла собой быстро растущую страховую компанию, предоставляющую широкий спектр услуг. Специфика деятельности компании предполагала сбор большого количества информации от клиентов, проведения различного рода расчетов, исследований и анализов, прогнозирование затрат. B силу этого развитию информационной системы компании руководство уделяло большое внимание. B компании был организован свой собственный ИT-департамент, который решал большое количество задач и управлял практически всеми ИT-проектами компании, привлекая в рамках аутсорсинга ограниченное количество известных компаний для решения узкого спектра задач. B ИT-департаменте была принята понятная и простая линейная модель жизненного цикла проекта. B последние два года компания «Радуга» стремительно развивалась. Количество клиентов выросло с нескольких сотен тысяч до более миллиона. Руководство компании прогнозировало на ближайшую перспективу дальнейший рост клиентской базы и объема операций. Расширение бизнеса и рост количества клиентов означали необходимость управлять все большим и большим количеством информации. До начала проекта, которым руководил Руслан, основным инструментом управления данными о клиентах выступала разработанная сотрудниками ИT-департамента база данных, построенная на СУБД MS Ассеss. Проект Руководство компании прекрасно понимало ограничения данной СУБД и поэтому инициировало проект создания новой базы данных и перенос всех старых данных в нее. После некоторого анализа руководством ИT-департамента остановило свой выбор на СУБД Оrасlе, которая предоставляла необходимую гибкость, надежность, возможность управлять большими массивами данных, возможность расширения. Новая система управления данными клиентами должна была быть построена на основе решений от компании Оrасlе. Создаваемая система должна была быть полностью совместимой с уже существующей системой, построенной на MS Ассеss, так чтобы обеспечить корректный перенос данных. Бюджет проекта был определен в 1 млн. рублей. Плановая продолжительность проекта составила 15 недель. Проект было решено выполнять силами ИT- департамента без привлечения внешних контракторов. Руководителем данного проекта был назначен Руслан Адамов. Он отвечал за все результаты (включая сроки, затраты, риски) по проекту и имел полномочия решать все вопросы с руководителями любого уровня компании. B качестве помощника руководителя проекта выступала Елена Ракитина, которая работала бизнес- аналитиком и взаимодействовала в основном с конечными пользователями, собирая и интегрируя дополнительные требования к создаваемой системе, а также согласуя иx с изначальными спецификациями и переводя иx на язык технических проектов для программистов. Исполнители работ по проекту выделялись в проект из различных отделов ИT-департамента и административно руководителю проекта не подчинялись, работая параллельно и над другими проектами. Линейная модель жизненного цикла проекта Как уже было сказано выше, все проекта ИT-департамента осуществлялись в подавляющем большинстве случаев на основе линейной модели жизненного цикла разработки программных приложений. Проект разбивался на несколько этапов, каждый из которых завершался финальной проверкой. Переход к последующему этапу возможен только при успешном прохождении финальной проверки предыдущего этапа. Финальная проверка осуществлялась специально создаваемой комиссией, в которую входили руководители различных функциональных подразделений компании. Руководитель проекта в приемочную комиссию (даже по промежуточным этапам), как правило, не входил. Основная цель финальной проверки (в том числе и по промежуточным этапам) заключалась в контроле соответствия созданных результатов задокументированным требованиям к создаваемому программному обеспечению, которые часто назвались спецификациями. Спецификации формулируются на основе предварительного анализа требований к программному обеспечению, проводимого за рамками проекта специалистами Отдела системного анализа Решения комиссией принимаются коллегиально и являются обязательными для выполнения руководителем проекта. Без положительного решения приемочной комиссии проект не может переходить к следующему этапу. Проблемы на стадии планирования Этап инициации проекта прошел без особых проблем и разногласий. B рамках Устава были определены рамочные требования к продолжительности и стоимости проекта. Спецификация закрепила основные требования к функциональности, эргономичности и другим характеристикам создаваемого программного продукта. B ходе этапа планирования спецификации по проекту были проанализированы будущими исполнителями. Один из программистов увидел возможности оптимизировать разработку базы данных, что требовало внесения существенных изменений в уже утвержденные спецификации. Его идея состояла в том, чтобы создать программный модуль, позволяющий новой системе безболезненно и корректно использовать данные старой системы без переноса данных из старой системы в новую. Потенциально данное решение может несколько упростить разработку новой системы, но не существенно. Наибольшая экономия усилий и времени от этого предложения могло возникнуть по причине устранения необходимости переноса данных из старой системы в новую. Решение также снижало риски потерь и искажений данных при переносе, снижало затраты на обучение, т.к. старая система могла использоваться на старых рабочих местах. Но при этом возникала дополнительная сложность и риски в системе по причине использования более сложной архитектуры. Хотя по оценке других программистов эти риски были признаны как невысокие. Руслану данная идея пришлась не по душе, так как она явно входила в противоречие с уже утвержденными спецификациями и приводила к дополнительным потерям времени на согласования и пересогласования уже принятых решений. Еще больше идея стала не нравиться, когда Руслан увидел, что идея действительно имеет под собой рациональное зерно и поддерживается другими программистами. На проводимом Русланом специальном совещании программисты стали оказывать на Руслана давление, чтобы он вышел с инициативой пересмотра утвержденных спецификаций с руководством функциональных подразделений компании и отделом системного анализа. Руслан решился не принимать новые идеи и настаивал на том, чтобы все исполнители придерживались ранее утвержденных спецификаций и не искали идеальных вариантов решения задач. Отличное — враг хорошего. Данный тезис Руслан использовал как основной при аргументации своей позиции. На устранение возникших разногласий ушло 1,5 рабочих дня. B первую очередь, по причине того, что несколько программистов видели рациональность в новом предложении, хотя и понимали все административные сложности согласования изменений в спецификации. B конечном итоге, Руслану удалось всех убедить в правильности своей позиции, хотя несколько программистов так и остались при своем мнении, что по видимости серьезно снизило иx лояльность проекту. Проблемы на стадии разработки После устранения всех разногласий Руслан разработал детальный календарный план и бюджет, матрицу ответственности, которые были безболезненно согласованы и утверждены приемочной комиссией по второму этапу проекта. Проект успешно перешел на этап разработки базы данных. Но в ходе выполнения работ программистами и тестовыми аналитиками была обнаружена проблема при переносе данных из старой системы в новую. Решение проблемы требовало дополнительного времени программистов. Для того, чтобы завершить проект, который и так несколько опаздывал, с не очень большим отклонением по срокам требовалось увеличить загрузку двух программистов, Сергея и Евгения, которые были вовлечены в выполнение работ по еще одному приоритетному проекту. Более того, и Сергей и Евгений были из числа тех программистов, которые на стадии планирования были активными сторонниками идеи оставить старую базу и не осуществлять переноса данных. Особого энтузиазма самостоятельно решать вопрос иx дополнительной загрузки по проекту они не испытывали, и Руслану ничего не оставалось как пытаться согласовать данный вопрос с руководителем Сергея и Евгения. Их руководитель, Иван, оказался серьезно занят по другому проекту компании и смог встретиться с Русланом только три дня спустя после обнаружения проблемы с переносом старых данных. B течение этих трех дней опоздание проекта продолжало накапливаться. После получасового разговора Иван согласился выделить Сергея и Евгения на большую часть времени в проект Руслана. Но дополнительная загрузка Сергея и Евгения не помогла избежать серьезных нарушений по срокам выполнения этапа разработки, так как на устранение проблемы ушло значительно больше времени, нежели ранее предполагалось. Этап разработки был завершен с опозданием на 2 недели. Более того, дополнительное время Сергея и Евгения привели к превышению бюджета проекта. Устранить возникшие отклонения в ходе выполнения последующих этапов проекта Руслан практически не имел возможности, так как принятая модель жизненного цикла оставляла мало возможностей для запараллеливания работ в разных этапах. С пессимистическим настроением Руслан приступил к реализации этапа тестирования, несколько нервно ожидая, какие проблемы и вопросы могут возникнуть в ходе выполнения процедур тестирования. Вопросы: 1. Какие преимущества и недостатки линейной модели жизненного цикла проекта (как вообще, так и применительно к рассматриваемому проекту)? 2. Какие аргументы Bы бы использовали для убеждения программистов, уверенных в разумности изменений в спецификации проекта в соответствии с новой идеей на стадии планирования? Как бы Bы поступили на месте Руслана в данной ситуации? 3. Согласны Bы или не согласны с подходом Руслана к решению проблем по проекту? 4. Какие улучшения Bы можете предложить для оптимизации управления ИT-проектами в компании «Радуга»? |