Правильная ссылка на эту страницу
http://az-design.ru/Projects/AzBook/AZMicro/index2.shtml

AZMicro2 - или "чего в этих щах не хватает"

       Итак, журнал операций мы вести можем. Оборотную ведомость получить можем. Даже главную книгу получить можем! Но, чего то здесь не хватает.
       Во-первых, пока у нас десять записей в журнале операций, то найти и посмотреть (исправить) ее можно легко. А если их 10000? Или 100000? Как отделить записи по получению денег от записей по продаже товара? Как отличить операции с одним партнером от записей с другим партнером? Таким образом первое "чего в щах не хватает" — аналитический аппарат который бы позволял "разрезать" журнал операций вдоль и поперек.
       Во-вторых, как только с программой начинает работать больше одного человека встает воспрос о безопасности данных. Это не только "черно/белая" бухгалтерия, типичная для России, но и просто ограничение круга лиц, которые имеют доступ к некоторым (секретным пока) операциям.
       Вот и попробуем это реализовать.

Резюме

       Все что сделано до сих пор это очень маленькие базы данных. Предварительного анализа и проектирования практически не было. А ведь нужно было проанализировать:
       — как ведется бухгалтерский учет,
       — как построены документы, их структура и классификация, как они учитываются в журнале операций, как по ним производится аналитика;
       — как классифицированы партнеры, как учеть общие взаимоотношения, когда один и тот же партнер является и поставщиком и покупателем;
       — как классифицированы товары, как анализировать доходы и прибыли от групп товаров, как изменять их цены, как определять цены LIFO, FIFO и другие;
       — как классифицируются Персоны, кто из них работники, а кто покупатели (клиенты), а может быть поставщики, и т.д.
       — и, наконец, права доступа — кто, когда, где, к каким таблицам и записям, как это все взаимодействует друг с другом. Я пока не встречал коробочных продуктов, в которых эта работа была бы проделана разработчиком. Всегда она отдавалась на откуп конечному пользователю, который не имея знаний в этой области, быстренько забывал об этом.
       Но готовый продукт нужно протестировать, все ли было сделано правильно. Причем всегда думается, что тестируется клиентское приложение — это в нем же созданы кнопки и процедуры, это оно чего-то высчитывает и отображает. На самом деле множество проблем закопано в самой базе данных, которую никто не тестирует. Посмотрим, что нужно сделать чтобы проверить правильность системы безопасности, самой простой части нашего приложения.
       У нас записано 22 роли, с которыми пользователь может подключится к базе данных. (На самом деле есть еще роль CREATOR под которой создавалась база данных.) Значит необходимо заполнить журнал операций как минимум 22-мя полноценными сделками, т.е. с полным циклом покупки продажи товара. Для пересечения этих данных с партнерами, нужно иметь как минимум 22 партнера и соответственно 484 сделки. Каждая сделка состоит как минимум из 10 операций. На испытуемой системе необходимо завести 22 пользователя и все эти 4840 операций сделать из под разных пользователей. При изменении данных одним пользователей, нужно убедиться что другим пользователям видно (доступно) только то, что определено их правами доступа. При этом сгенерировать операции случайным образом не получится. При получении оборотной ведомости должна получаться осмысленная картина — баланс должен сойтись. Таким образом, только для этого тестирования потребуется минимум 1 человеко-месяц. При том, что разработка всего проекта заняло не более 2 недель.
       Про тестирование аналитических признаков вообще никто не упоминает и не пробует, а такое исследование на порядки сложнее чем тестирование системы безопасности. Для системы безопасности мы сами построили матрицу прав доступа, сами можем построить матрицу тестов и по этой матрице методично проверить каждый пункт.
       Для тестирования аналитических признаков необходимо исследовать как описываются и классифицируются эти сущности в реальном мире, которым мы управлять не можем.
       В целом в этом проекте так много фундаментальных проблем, что заниматься отладкой (не тестированием) отпадает всякая охота. Отладку этого проекта оставляем читателю. Основное назначение этих двух проектов — продемонстрировать как создаются проекты и какие инструменты при этом используются, чтобы читатель мог поиграться и "заточить карандаш".
       Если отбросить из рассмотрения дизайн интерфейса (красивые картинки) и дизайн коробки, а также рекламные буклеты и ролики, то рассмотренные проекты по сути мало чем отличаются от большинства коробочных продуктов.
       На самом деле это классический пример "проекта Пятикантропа", о котором пойдет речь дальше.

уже скачали 80 раз.

Архангельский Андрей




<<< Пред. Оглавление
Начало раздела
 

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:56 MSK


Постоянный адрес статьи:
http://az-design.ru/Projects/AzBook/AZMicro/index2.shtml