Методы экспертной оценки заключаются в консультации с одним или несколькими экспертами, которые проводят оценку стоимости и других ТЭП нового проекта ПС, используя свой опыт, интуицию и знание содержания проекта. Эти методы, несмотря на свои недостатки, удачно дополняют более точные модели. Из достоинств экспертных оценок следует отметить возможность использования опыта прошлых разработок и их отличия от новых методов, архитектуры ЭВМ, областей применения, предусмотренных в конкретных проектах. Эксперт может учесть также индивидуальные возможности коллектива и взаимодействие разработчиков или другие уникальные стороны проекта.
К недостаткам экспертной оценки следует отнести ее зависимость от компетенции и объективности эксперта, который может оказаться пристрастным, оптимистичным, пессимистичным или незнакомым с существенными аспектами проекта. Трудно выбрать золотую середину между быстро полученной оценкой одного эксперта - своевременной, эффективной, но трудно проверяемой и разумно объяснимой, и строгой, хорошо документированной оценкой в методе группового согласим - тщательно обоснованной и проанализированной, но требующей более длительной проработки, а также трудно повторяемой через некоторое время, особенно когда спецификации проекта отчасти изменены. Из-за множества различных, индивидуальных особенностей экспертов - оптимизма, пессимизма, желания добиться успеха, политических соображений, предпочтительным является метод оценивания несколькими экспертами. Существует много путей объединения индивидуальных оценок в единую - обобщенную. Один путь состоит в получении средних или срединных оценок. Это быстрый метод, но он может выдавать не очень точный результат из-за возможности выбросов значений отдельных оценок. Другой метод состоит в проведении совещания группы экспертов для формирования единой оценки. Этот метод имеет общее преимущество отсеивания оценок, связанных с неосведомленностью, но обладает двумя недостатками. Во-первых, одна группа экспертов может повлиять на оценки другой группы своим красноречием и напористостью. Во-вторых, группа экспертов может лопасть под влияние авторитетной личности или политической ситуации.
Ограничения при прогнозировании определяются, прежде всего, имеющимися обработанными данными, которые могут быть использованы в качестве исходных аналогов или обобщенных характеристик. Дополнительные затраты на обеспечение повышенного качества программ учитываются при анализе сложных ПС СРВ. Анализ проводится для ПС в целом или для крупных этапов работ, и не ставится задача определения нормативов на конкретные операции при выполнении работ отдельными специалистами. Предполагается, что разработка ПС проводится при использовании регламентированной технологии и контроле ее выполнения. При отсутствии такой технологии прогнозирование ТЭП разработок сложных ПС практически невозможно. В этом случае трудоемкость и длительность разработки может возрастать в несколько раз по сравнению с оптимистическими экспертными оценками.
Прогнозирование ТЭП нового ПС в свою очередь требует некоторых затрат. Они составляют обычно не более 1% общих затрат на проект, однако всегда эффективны и могут в ряде случаев обеспечивать снижение совокупных затрат на разработку на десятки процентов. Для повышения достоверности прогнозов целесообразны технико-экономическое сопровождение процесса разработки ПС и последовательное поэтапное прогнозирование сроков завершения работ и соответствующих затрат. Управление процессом разработки ПС на базе фактических затрат на компоненты и этапы разработки и последовательно уточняемая достоверность прогноза ТЭП позволяют не только снижать затраты на данный проект ПС, но и создавать базу аналогов и обобщенных данных для достоверного прогнозирования последующих проектов.
Исходные данные ТЭП и объекта разработки могут различаться по полноте и достоверности, особенно в зависимости от условий и этапов разработки, что позволяет их разделить на следующие группы:
- одиночные аналоги завершенных разработок ПС, характеристики которых, технология и условия создания достаточно близки к подобным показателям вновь разрабатываемого комплекса программ;
- обобщенные ТЭП нескольких в значительной степени подобных разработок ПС, выполненных на одном и том же предприятии, при использовании одинаковой технологии и системы автоматизации коллективами специалистов, близкими по квалификации;
- обобщенные ТЭП ряда родственных предприятий, создающих близкие по классу ПС, с применением собственных технологий и систем автоматизации.
Однако большой разброс производительности труда и других ТЭП разных коллективов, а также более или менее случайный набор усредняемых показателей приводят к тому, что такую группу данных в большинстве случаев трудно использовать для прогнозирования ТЭП конкретных новых разработок. Поэтому ниже предполагается, что обобщенные характеристики ТЭП получены при более или менее однородных условиях разработки, которые достаточно близки к условиям прогнозируемого проекта. Эти однородные условия наиболее полно соблюдаются в пределах предприятия, однако не исключена возможность использования выборочных данных других организаций.
На достоверность прогнозов ТЭП влияет не только точность сведений о предшествующих разработках, но и достоверность характеристик объекта и условий прогнозируемой разработки. С учетом этого целесообразно выделить три вида прогнозов технико-экономических характеристик разработок ПС:
- первичные оценки трудоемкости и длительности разработки при наличии минимально необходимых сведений об объекте и условиях разработки;
- уточненные оценки полных ТЭП процесса разработки ПС на базе обобщенных характеристик предшествующих разработок и уточненного сценария объекта и условий разработки;
- текущие прогнозы основных ТЭП на промежуточных этапах процесса разработки ПС с учетом влияния зарегистрированных и обобщенных предшествовавших данных на текущий момент времени об объекте и условиях разработки и последовательно уточняющегося прогноза на период до завершения разработки.
Последний вид прогнозов предполагает мониторинг и технико-экономическое сопровождение процесса разработки. Оно обеспечивает возможность оперативного перераспределения ресурсов и управления всей разработкой с целью минимизации затрат или длительности создания ПС. Последовательно уточняющееся прогнозирование и использование ТЭП в процессе разработки является одной из компонентов технологии и должно обеспечиваться соответствующими средствами автоматизации. Эти средства служат для автоматизированной регистрации текущих затрат на разработку компонентов в различных разрезах и их обобщения в соответствии с целями прогнозирования и управления разработкой. Реализация таких автоматизированных средств возможна только при достаточных ресурсах используемых ЭВМ и высоких уровнях (четвертый - пятый) автоматизации технологии разработки особо сложных ПС. Тесная взаимосвязь этого вида прогнозирования с технологией разработки и ее автоматизацией приводит к необходимости рассматривать их совместно, что выходит за пределы основной темы книги.
При технико-экономическом обосновании проекта ПС на любом уровне целесообразно применять методы и методики адекватные целям и этапам его реализации. Приступая к разработке комплекса программ, как в любой профессиональной деятельности, необходимо сначала провести реалистическую оценку возможного масштаба проекта - поставленных целей, ресурсов проекта и выделенного времени. Задача управления масштабом состоит в задании базовых требований, которые включают разбитое на компоненты ограниченное множество функций и требований, намеченных для реализации в конкретной версии проекта. Базовый уровень масштаба должен обеспечивать:
- приемлемый для заказчика минимум функций и требований к проекту;
- разумную вероятность успеха с точки зрения возможностей коллектива разработчиков.
При оценивании масштаба следует определить приоритеты функций для установления состава работ, согласованного между заказчиком и разработчиком, которые обязательно должны быть выполнены и для определения базового уровня масштаба конкретного проекта с допустимым риском неуспешной реализации. Сокращение масштаба проекта до размеров, адекватных выделенному времени и ресурсам, может привести к конфликтам заказчиков и разработчиков. Для уменьшения вероятности таких конфликтов целесообразно активно привлекать заказчиков к управлению их требованиями и масштабом проекта, чтобы обеспечить как качество, так и своевременность разработки ПС. При этом следует учитывать, что:
• именно заказчики несут финансовую ответственность за выполнение обязательств перед внешними клиентами и пользователями (пусть и в несколько сокращенном, при необходимости, масштабе);
• комплекс программ, его важнейшие функции и удовлетворяемые требования принадлежат заказчику, а не коллективу разработчиков или поставщику.