Главная страница
Навигация по странице:

  • Мягкое внедрение

  • Жесткое внедрение

  • "Постановка Задачи"

  • "Интерфейсный прототип"

  • "Архитектурный прототип"

  • 11.2. Этап Уточняющий

  • Разработка, внедрение и адаптация программного обеспечения отраслевой направленности Часть 2. Разработка, внедрение и адаптация программного обеспечения отрас. Тема введение в обеспечение качества программных средств


    Скачать 418.37 Kb.
    НазваниеТема введение в обеспечение качества программных средств
    АнкорРазработка, внедрение и адаптация программного обеспечения отраслевой направленности Часть 2
    Дата15.03.2023
    Размер418.37 Kb.
    Формат файлаdocx
    Имя файлаРазработка, внедрение и адаптация программного обеспечения отрас.docx
    ТипГлава
    #990789
    страница21 из 31
    1   ...   17   18   19   20   21   22   23   24   ...   31

    ГЛАВА 11. ТЕМА 10. МЕТОДИКА МЯГКОГО ВНЕДРЕНИЯ


    Существуют различные методики управления проектами. В данном курсе мы будем придерживаться методики "Мягкого внедрения" ведения проекта. Это методики мягкого и жесткого внедрения.

    Мягкое внедрение    - внедрение в условиях взаимного доверия Заказчика и Исполнителя, при котором проблемы и ошибки Заказчика берет на себя большей частью Исполнитель.

    Жесткое внедрение    - внедрение в условиях жесткого формального управления, пониженного доверия и повышенной ответственности Заказчика и Исполнителя. Жесткое внедрение обычно является следствием сильных политических рисков.

    Данная технология разработки и внедрения имеет следующие проверенные границы применимости:

    Рассчитано на взаимное доверие Заказчика и Исполнителя в пределах не менее одного этапа работ, имеется в виду, что Заказчик или Исполнитель могут блокировать проект, но не более чем в рамках этапа.

    Оптимально для проектов сроком до 3х месяцев и трудоемкостью до 1 чел/года. Для изготовления более сложной системы, необходимо, чтобы ее отдельные модули внедрялись не дольше 3х месяцев, в противном случае методика не применима.

    Учет модели ценообразования. Данная методика разработана с учетом рискованного для Исполнителя и выгодного для Заказчика "ценообразования за весь проект". Это не исключает возможность применения более простой расчетной схемы повременного типа.

    Заказчик готов заплатить больше, но за результат, а не за усилия (время) Исполнителя. Покупка проекта, а не времени Исполнителя позволяет Заказчику снять с себя значительную часть ответственности за свои проблемы и ошибки.

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

    Методика применима для небольших заказных и серийных систем.

    11.1. Этап Постановочный


    Данный этап проводится по договору о консалтинге, т.е. оплата этапа повременная. В виду неопределенности задачи спланировать заранее ее стоимость невозможно. Себестоимость этапа примерно равна 10% себестоимости всех работ.

    Основной продукт этапа - документ "Постановка Задачи"    (Product Vision).

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

    На основе "Постановки Задачи" требуется составить документ "Экономическое обоснование"   .

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

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

    Для оценки рисков требуется разработать как минимум 2 простейших прототипа (они могут быть выполнены как один).

    "Интерфейсный прототип"    - это прототип, имитирующий 1-2 важнейших диалоговых окна программы. Необходимо проанализировать реакцию пользователей с целью  изучения рисков связанных с модификацией их требований.

    "Архитектурный прототип"    - это прототип, проверяющий самые критические места будущей архитектуры. Данный прототип служит для оценки технологических рисков.

    Данные прототипы не должны далее использоваться при разработке системы, требуется начать разработку заново. Это связано с тем, что прототипы служат для нахождения оптимальных решений, но таковыми не являются.

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

    В результате мы имеем нечетко сформулированное задание "Постановка Задачи" и оценку стоимости в "Экономическом обосновании". Риски от нечеткости требований должны быть покрыты пессимистичной оценкой. С точки зрения юридического договора "Постановка Задачи" может играть роль ТЗ   , но с указанием в договоре на то, что более приоритетный документ "Документация пользователя"    (см. ниже) и система будет приниматься по "Приемочным испытаниям"    (см. также ниже)

    Условие завершения этапа: подписание сторонами "Постановки Задачи" и "Экономического обоснования".

    11.2. Этап Уточняющий

    На данном этапе производится создание серии рабочих прототипов, охватывающих всю систему, и согласуются все требования с ключевыми пользователями. Себестоимость этапа составляет примерно 30% разработки. Если на данном этапе производится поиск и разработка целой технологии, то его себестоимость увеличивается примерно в 3 раза.

    Одновременно в виде пошаговых сценариев ("Use case")    пишется "Документация Пользователя", раскрывающая пункты "Постановки Задачи". Сначала создаются сценарии поведения системы в целом. Затем создаются индивидуально направленные сценарии - должностные инструкции пользователям. Запрещается использование в документации слова "должен", время описания выбирается как неопределенное или настоящее. Такие стилистические ограничения необходимы для того, чтобы "Документация пользователя" играла не только роль спецификации, но и роль документации для пользователя, как следует из названия документа.

    Возможны два варианта взаимодействия "прототип-документация":

    1. При относительно четком представлении о функциональности до разработки очередного прототипа должны быть готовы основные пункты "Документации", описывающие его работу. В данном случае "Документация" одновременно играет роль нечеткой спецификации на прототип. Нечеткость заключается в том, что "Документация" может быть исправлена с целью соответствия реализации в прототипе, если прототип реализовал удачное, но не документированное решение.

    2. При отсутствии представления о лучшем варианте реализации по краткому заданию на основе "Постановки Задачи" сначала создается прототип. После одобрения Заказчиком документируется желаемое поведение системы.

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

    Как отмечено выше, "Документация" фактически заменяет классическое ТЗ   . Таким образом на лицо ряд преимуществ:

    • описание программы делается на языке, понятном пользователю.

    • уже на первых этапах разработки программы пользователь включается в анализ своей рабочей документации.

    • нет необходимости править ТЗ и Документацию одновременно.

    • как правило, заботятся в первую очередь о ТЗ, обычно документация далеко отстает от текущего состояния программы. В данном случае этого не наблюдается.

    Условие завершения этапа: этап завершается письменным соглашением Заказчика и Исполнителя о том, что конечная система будет принята, если соответствует последней согласованной версии "Документации Пользователя"; архитектура и требования стабильны, не предвидится изменений более чем на 20% в ходе следующего этапа.

    Важное замечание о юридической стороне. Вполне возможно, что не удается достигнуть согласия ключевых пользователей с прототипом или описанием в Документации. В данном случае Заказчик должен принять волевое решение на уровне топ-менеджера и определиться с требованиями. Если этого не происходит, или если требования выходят за рамки "Постановки задачи" с учетом надбавок на риск, рекомендуется пересмотреть трудоемкость/цену проекта или прекратить его. Указанная возможность прекращения проекта должна быть предусмотрена в договоре.
    1   ...   17   18   19   20   21   22   23   24   ...   31


    написать администратору сайта