лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки
Скачать 4.41 Mb.
|
Принципы совершенствованияВ [14.3] сформулированы следующие принципы совершенствования качества программных систем: поэтапность, непрерывность, цикличность, наличие стимула, ориентация на цели, проектный подход. Мероприятия по совершенствованию процессов следует вводить поэтапно. Людям нередко бывает тяжело отказываться от старых привычек, привыкать к новому. Предложенные изменения должны пройти проверку опытом; не все из предложенного обязательно даст эффект, какие-то новации придется пересмотреть, от чего-то - отказаться. Непрерывность - один из ключевых принципов управления качеством: часто мероприятия проводятся в виде кампании, которая затухает после получения сертификата. Организация, которая стремится к лидерству, должна поддерживать "дух качественной работы" постоянно. Бизнес-процесс улучшения требований характеризуется цикличностью (см. Процесс совершенствования): его основные этапы повторяются на все более высоком уровне. Циклы оптимизации в софтверных организациях удобно приурочивать к проектам, выполняемых в рабочих группах. Анализ недостатков целесообразно производить тогда, когда они в "оперативной памяти" группы проекта, например - один раз в середине проекта и один - сразу после его окончания. Каждый проект по-своему уникален и несет в себе потенциал для улучшения процессов. Основным стимулом к изменениям К.Вигерс считает трудности, с которыми столкнулась команда проекта, например: разработчики не уложились в график, потому что непонятные и неоднозначные требования попали к ним поздно; разработчикам пришлось много работать сверхурочно, потому что непонятные или расплывчатые требования были уточнены слишком поздно в процессе разработки; попытка тестирования системы не удалась, потому что тестировщики не понимали, что продукт должен делать; нужная функциональность была реализована, но пользователи не удовлетворены вялой производительностью, неудобством работы или другими недостатками качества продукта; организации пришлось пойти на высокие расходы на сопровождение, потому что клиентам потребовалась масса дополнительных функций, которые следовало определить во время составления требований; организация-разработчик ПО приобрела плохую репутацию поставщика продуктов, которые не нравятся клиентам. Изменения технологических процессов должны быть целеориентированы. Примеры целей: уменьшение объема работы, вызванного проблемами с требованиями; повышение точности планирования и реалистичности планов; снижение (исключение) числа ситуаций появления новых требований на финишных этапах проекта. Действия по совершенствованию процессов должны планироваться, контролироваться и управляться, как мини-проекты. Это упрощает выделение требуемых ресурсов, отслеживание перемен и оценки результативности изменений. Процесс совершенствованияНа рис. 14.2 показан типовой цикл совершенствования процессов при создании программного обеспечения [14.3]. Рис. 14.2. Оценка текущих приемовВ соответствии с принципом целенаправленности, в работы по совершенствованию необходимо начать с формулировки целей и оценкой, насколько существующие процессы соответствуют данным целям. Для целей оценки применимы известные в бизнес-моделировании и анализе требований методы и приемы: от проведения интервью и постановочных семинаров до фиксации модели "Как есть". Эффективным способом является привлечение внешних консультантов, которые могут составить непредвзятый взгляд на положение в вашей компании. Результатами оценки является список обнаруженных сильных и слабых сторон в текущих процессах, а также, начальные рекомендации по совершенствованию (переходу к модели "Как надо"). ПланированиеВ соответствии с принципом проектного подхода к проведению мероприятий по совершенствованию, для мини-проекта совершенствования необходимо проделать все то, что обычно делается при инициации проектов: осуществить декомпозицию работ; выделить ресурсы, назначить исполнителей; создать планы работ. Стратегический план описывает общую программу совершенствования процессов в вашей организации. Тактические планы действий затрагивают конкретные области совершенствования, например процесс сбора требований или процедуру назначения приоритетов [14.3]. В каждом плане действий должны быть указаны цели действий по совершенствованию, участники и отдельные задачи. План также дает возможность отслеживать выполнение процесса совершенствования, отмечая выполнение отдельных задач. В плане действий не должно быть более 10 пунктов; срок его реализации не должен превышать 2-3 месяца. Ниже приведен шаблон декомпозиции задачи управления требованиями [14.3]. составить проект процедуры управления изменениями; проверить и модифицировать процедуру управления изменениями; провести пробное испытание процедуры управления изменениями для проекта; модифицировать процедуру управления изменениями на основе обратной реакции по пробному испытанию; оценить инструментальные средства выявления проблем и выбрать одно из них для поддержки процедуры управления изменениями; приобрести выбранное инструментальное средство выявления проблем и настроить его для поддержки конкретной процедуры; внедрить новую процедуру управления изменениями и инструментальное средство в организации. Создание и апробация новых процессовПринцип поэтапности призывает не делать "революций" в совершенствовании процессов. Любая новация, описание которой найдено в литературе, заимствована из опыта коллег или разработана лично вами, должна пройти испытание на вашей команде и ваших проектах. Известный неполиткорректный принцип "что русскому хорошо - то немцу смерть" на языке современного менеджмента IT-проектов звучит, как "учет системы ценностей, принятых в команде разработчиков" [14.5]. Апробация на реальных задачах - единственный гарантированный способ проверить - годится ли тот или иной инструмент для вашей команды. Чтобы не вовлекать в масштабные эксперименты значительные ресурсы существует способ пилотных (пробных) проектов. К.Вигерс предлагает следующие методические приемы при апробации новых процессов: выбирайте для участия в пробных проектах людей, которые будут относиться к новым приемам беспристрастно и смогут дать им оценку. Это могут быть как сторонники, так и скептики, но они не должны быть ярыми противниками предлагаемых приемов; чтобы результаты было легко истолковать, определите количество критериев, по которым команда будет оценивать пробный проект; определите заинтересованных лиц, которых следует проинформировать о том, что представляет собой пробный проект и почему он выполняется; подумайте о возможности испытания новых процессов по частям в разных пробных проектах. Так вам удастся вовлечь в испытание больше людей, что увеличивает осведомленность, количество откликов и сторонников; для более полной оценки поинтересуйтесь у участников пилотных проектов, что бы они почувствовали, если бы им пришлось вернуться к существующим приемам работы. Оценка результатов и принятие решенийОценка результатов апробации новых процессов должна показать - достигнуты ли поставленные цели, стоит ли осуществлять широкомасштабное внедрение новаций, апробированных на пилотном проекте, либо "овчинка выделки не стоит". Среди ключевых вопросов в области оценки результатов можно выделить следующие [14.3]. Насколько гладко прошли пробные проекты и как эффективно они разрешили неопределенности в отношении новых процессов? Собираетесь ли вы менять что-либо в следующих пилотных проектах? Как прошло общее внедрение новых технологических процессов? Удалось ли вам довести до сведения каждого информацию о пользе новых процессов или шаблонов? Смогли ли участники понять и эффективно применить новые процессы? Собираетесь ли вы менять что-либо при проведении следующего внедрения? При оценивании результативности достижения поставленных целей следует различать мероприятия, польза от которых проявляется сразу и те, выгода от которых проявится через значительное время. Необходимо учитывать эффект "кривой обучения" (learning curve) [14.3]: производительность падает, пока люди приспосабливаются к новым способам работы. Кратковременное падение производительности, иногда называемое "лощиной отчаяния" - в - это часть необходимого вклада, который ваша организация вносит в совершенствование процессов. Невзирая на все возможные трудности, мероприятия по улучшению качества при внимательном к ним отношении неизбежно приведут к повышению эффективности работы команды. Требования в управлении проектом Чтобы определить сметную стоимость и продолжительность работ по проекту автоматизации без грубых ошибок, необходимо выявить и проанализировать требования, а также сформировать архитектурную основу, крайне желательно создать прототипы. И это - как минимум. Иными словами, для того, чтобы создать АИС, сначала нужно проанализировать возможность создания. Такая постановка вопроса вполне логична и обоснована, это подтвердит любой Разработчик. Однако, она вызывает много вопросов, например: Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение? Кто оплатит работы по анализу требований? (очевидно, Заказчик) Как быть, если цена вопроса окажется непомерной и от проекта придется отказаться - кто возместит Заказчику убытки на проведение исследований? Разумный Заказчик сможет найти выход из этого непростого положения, например: подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остается); взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в "каскадных" схемах разработки) - путь прогнозирующих методологий разделив с Разработчиком ответственность за конечный продукт, приготовившись день за днем работать с ним рука об руку вплоть до появления результата - путь гибких (Agile) методологий. |