Проблемы проектирования учетных систем - 4

Для примера можно рассмотреть описание требований учетной системы в ТЗ. В первую очередь возникает вопрос - а какие требования описывать в ТЗ? Если описывать все требования, которые нужны Заказчику (полное ТЗ), это означает, что 90% ТЗ описывает то, что уже есть в типовой программе. И только 10% посвящено реальной разработке. То есть, 90% работы по проектированию будет востребовано только для формального согласования функций, и по-сути, будет дорогим и ненужным бюрократизмом. 

А если описывать только те функции, которые нужно изменить или разработать (ТЗ на отклонения), что действительно необходимо разработчикам, то Заказчик формально остается в неведении о 90% функциональности, которую он получит. Разработчику тут придется ссылаться на документацию к базовой программе и доступность программы для изучения и анализа самим Заказчиком.

Конечно, есть Заказчики, для которых формальное бюрократическое согласование - это главное. Они готовы оплатить работу по проектированию того, что уже давно создано, чтобы не нарушать корпоративные стандарты ведения дел. С их точки зрения ТЗ - это Документ, а на программный код печать и подпись не поставишь.

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

Следующая запись

Предыдущая запись
Начало статьи

Проблемы проектирования учетных систем - 3

Что же мы видим, пытаясь применить эти подходы к учетным проектам? Во-первых, мы не ведем разработку ПО "с нуля", а дорабатываем готовую программу. Во-вторых, гипертрофированную роль внедрения, так как обучение пользователей и настройка уже готового функционала занимают больше времени и сил, чем доработка "под клиента". В-третьих, Заказчик обычно точно представляет себе конечный результат разработки и внедрения.

С одной стороны, Заказчик располагает точными формальными инструментами оценки качества системы. Например, корректная налоговая отчетность, правильный баланс, сравнение с данными старой системы. С другой стороны, массовость и тотальность использования учетных систем, и конкретно, монопольная роль продуктов "1С", дают Заказчику множество примеров внедренных систем и задают определеный стандарт качества разработки и объема функционала.

Следующая запись

Предыдущая запись
Начало статьи

Проблемы проектирования учетных систем - 2

Большинство методик проектирования ПО, которые можно встретить в литературе, рассчитаны на разработку ПО "с нуля", под требования конкретного Заказчика. До начала разработки такого ПО ни Заказчик, ни разработчик не знают, что получится и как это будет работать.

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

Сравнить этот образ будущей программы возможно только с имеющимися аналогами и очень поверхностно, либо вообще нельзя сравнить. Зачастую, разрабатываемое ПО не имеет прямых аналогов, поэтому его и нужно разработать.

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

Это дает разработчику ПО свободу. Какими бы не были объемными функциональные требования, их всегда можно удовлетворить за разумное время, располагая разумными ресурсами. Соответственно, в литературе о проектах все пляски - вокруг времени и ресурсов. Сама по себе фиксация этих требований проблем не вызывает, если речь идет о разработке прикладного ПО.

Следующая запись

Начало статьи

Проблемы проектирования учетных систем - 1

Особенность учетных проектов - огромное количество функций. Один документ 1С по числу функций сравним с таким приложением, как Outlook Express. В 1С:Бухгалтерии таких объектов - десятки, а в УПП - сотни.

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

В результате, требуемое методологией разработки ПО формальное описание функций системы, превращается в гигантскую работу, необходимость которой трудно обосновать Заказчику. И которая, объективно, не очень нужна. Это и порождает вечную проблему проектирования учетных систем.

Следующая запись