Используйте частые билды и быстрые тесты
Регулярное создание билдов решения – наиболее надежный из доступных способов проверки хода разработки проекта и эффективности коллективной деятельности проектной группы. Во время фазы внедрения аналогичной цели служат циклы тестирования пилотной версии.
Частые итерации разработки и внедрения
Решения, используемые в производственной сфере, должны учитывать изменчивость бизнес‑процессов. Для этого решения должны приспосабливаться к непрерывным изменениям нужд заказчика. Частые итерации разработки и внедрения облегчают создание версионированых выпусков и позволяют получить эволюционирующее решение, отвечающее изменяющимся нуждам и требованиям.
Избегайте расползания рамок проекта
Используйте описание концепции и спецификации проекта для того, чтобы сосредоточится на заявленных бизнес-целях и изначальных требованиях. Эти документы должны служить фильтром для всех дополнительных возможностей, которые в противном случае могли бы быть введены в решение без должного анализа их необходимости.
Оценка снизу вверх
В IT-проектах предварительные оценки длительности задач, их стоимости и т.п. должны исходить от тех, кто будет затем выполнять оцениваемую работу. Подход “снизу вверх” (bottom‑up estimating) дает следующие преимущества:
Большая точность. Оценки, сделанные непосредственными исполнителями, являются более точными, поскольку у этих людей есть опыт аналогичной деятельности.
|
|
|
Ответственность. Те, кто использует в работе собственные оценки, чувствуют большую ответственность, как за свою работу, так и за адекватность сделанных оценок.
Уполномоченость (empowerment ) проектной группы. Календарный график, составленный самой проектной группой, а не продиктованный свыше руководством, вдохновляет проектную группу, поскольку он составлен на основе тех оценок, которые сами члены проектной группы считают реалистичными.
Интегрирование представленных проектной группой оценок
Каждый лидер ролевого кластера ответственен за оценку необходимого своему отделу времени. К примеру, лидер команды разработчиков подготавливает оценки времени разработки.
Ролевой кластер “Управление программой” координирует процесс подготовки оценок трудозатрат и проводит их интеграцию в сводный календарный график и бюджет проекта.
Приложение A
Изменения по сравнению с предыдущей версией MSF
Предыдущая версия MSF включала в себя две модели процессов, каждая из которых состояла из четырех фаз и четырех главных вех. Названия и определения фаз и вех различались в зависимости от того, является ли целью проекта разработка приложения (создание) или развертывание инфраструктуры (внедрение). В MSF версии 3.0 эти две дополняющие друг друга модели были объединены в одну общую модель процессов MSF. Слияние двух моделей привело к появлению дополнительной фазы в модели процессов разработки приложений. Эта фаза вбирает в себя деятельность, знаменующую конец разработки и начало внедрения.
|
|
|
Сперва была разработана модель процессов для разработки приложений (Application Development - AD). Ее целью была консолидация всего лучшего из культуры и процессов, использующихся командами продуктов Майкрософт для создания программного обеспечения и его распространения среди заказчиков и партнеров.
Позднее клиенты Майкрософт стали нуждаться в аналогичном руководстве для крупномасштабного внедрения программных продуктов и аппаратного обеспечения на своих предприятиях. Чтобы удовлетворить эту потребность, модель разработки приложений была адаптирована к модели процессов внедрения инфраструктуры (Infrastructure Deployment - ID).
И хотя обе модели продемонстрировали на протяжении ряда лет свою высокую эффективность, возникла необходимость создания единой, целостной модели процессов. Основной мотивацией этого послужило:
|
|
|
Обеспечение взаимодействия моделей AD и ID.
Лучшая поддержка проектных групп, работающих над решениями, специализированными для конкретного предприятия, и разработкой веб-приложений, так как в обоих случаях разработка и внедрение обычно неотделимы друг от друга.
Лучшая поддержка активно развивающих сегодня веб-сервисов и стратегии Майкрософт .NET. Так как веб-сервисы все чаще становятся основными каналами поставки программного обеспечения, разработчики коммерческого программного обеспечения находят необходимым включение процесса установки в жизненный цикл продукта.
Облегчение передачи решения от команды разработки к команде сопровождения, особенно в случае использования MOF.
Заключение
Информация, содержащаяся в настоящем документе, представляет текущую точку зрения корпорации Майкрософт по обсуждаемым вопросам на момент публикации. В условиях меняющейся рыночной конъюнктуры, требующей соответствующей корректировки ведущихся разработок, данную информацию не следует рассматривать в качестве какого бы то ни было обязательства со стороны Майкрософт; корпорация не может гарантировать точность информации, представленной после даты публикации.
|
|
|
Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.
На пользователе лежит ответственность за соблюдение всех применимых в данном случае законов об авторском праве. В целях обеспечения авторских прав никакая часть настоящего руководства ни в каких целях не может быть воспроизведена или передана в какой бы то ни было форме и какими бы то ни было средствами (электронными или механическими, включая фотокопирование и запись на магнитный носитель), если на то нет письменного разрешения корпорации Майкрософт.
Предмет данного руководства может быть защищен патентами, патентными заявками, товарными знаками, авторским правом или иным образом в пользу корпорации Майкрософт. Данный документ не дает разрешения на использование этих патентов, товарных знаков или авторского права, если таковое не оговорено явным образом в каком-либо лицензионном соглашении корпорации Майкрософт.
© Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены.
Microsoft, BizTalk и Project являются либо охраняемыми товарными знаками, либо охраняемым товарными знаками корпорации Майкрософт в США и других странах.
Названия компаний или продуктов, указанные здесь, могут быть товарными знаками соответствующих владельцев.
Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf .
[*] В предыдущей версии MSF процессы разработки (development) и внедрения (deployment) описывались двумя различными, хотя и очень похожими, моделями (прим. редактора перевода).
[†] Что бы подчеркнуть это различие, пару терминов “customer/user” в русских версиях документов по MSF мы переводили преимущественно как “заказчик/потребитель”, хотя иногда и как “заказчик/пользователь” (прим. редактора перевода).
[‡] Следует учесть, что в MSF определения терминов иногда несколько отличаются от определений этих терминов, используемых в рамках некоторых других подходов к управлению проектами. (прим. редактора перевода)
[§] Следует учесть, что в MSF определения терминов иногда несколько отличаются от определений этих терминов, используемых в рамках некоторых других подходов к управлению проектами. (прим. редактора перевода)
[**] Шаблоны и примеры большинства упоминающихся здесь и далее документов свободно доступны на http://www.microsoft.com/msf в разделе “MSF Resource Library ”. Кроме того, очень хороший комплект примеров документов поставляется Microsoft вместе со студенческими материалами курса 2710 Analyzing Requirements and Defining Microsoft .NET Solution Architectures (прим. редактора перевода).
[1] Royce, Winston W., "Managing the Development of Large Software Systems," Proceedings of IEEE Wescon (August 1970): pp 1-9.
[2] Barry Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, Vol.21, No. 5 (May 1988): pp 61-72.
[SB1]Тут у них бага – этот булик пропущен J
[SB2]Тут еще одна бага – эти два абзаца забулечены, хотя ясно, что двоеточие во втором абзаце служит введением нижеследующих буликов J
[SB3]Я, вообще-то, думаю, что имеется ввиду сам процесс группирования, и тогда DCR должно переводиться, наверное, как «организация запросов об изменениях». Но по ихнему тексту получает так, как я перевел.
[SB4]Я не уверен, что понял, что они хотели здесь сказать.
Дата добавления: 2019-01-14; просмотров: 154; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!