|
Cat2 писал:Не совсем. Заказчика так же может интересовать выписка и ввод первичных документов, отображение оперативной информаци. Причем, часто это, на самом деле, интересует его в первую очередь.
1. Для чего нужен ввод первичных документов?
2. Что есть по-сути "отображение оперативной информации"?
Автор топика поставил вопрос не узко, а наоборот, слишком широко. Однако, он употребил слово "отчет", а у большинства на этом форуме со словом "отчет" связаны вполне конкретные ассоциации.
Т.е. вопрос стоит так: имеем некую исходную информацию - из нее необходимо получить некую конечную информацию как результат работы системы. Такая постановка задачи пойдет под вообще любую информационную систему. :)
Далее - чуть детальнее, но все равно ОЧЕНЬ обще:
1. сбор требований (чего хотите-то?)
2. анализ,
уточнение и пополнение требований на этапе анализа (а в каком виде хотите-то? а еще чего хотите, тут из первого и пятого естественным путем вытекает десятое - нужно? а про двадцатое не забыли? так и запишем...),
выявление ограничений (чем располагаем-то?),
выбор технологий (а я чем располагаю-то? ).
Всё это по кругу вплоть до "сходимости процесса".
далее, на основе анализа:
3. разбивка на подзадачи (блоки/модули, сущности, операции над сущностями), спецификация роли каждого блока/модуля, сущностей, спецификация операций (всем этим вещам нынче даны модные названия, но я по-старинке :) )
4. рекурсивно повторяем предыдущий пункт, дробя задачи, добираясь до простейших неделимых сущностей и операций в рамках предметной области и выбранных технологий;
5. выбираем способ логического и физического представления сущностей (скорее, получаем как результат предыдущей работы);
в процессе пп 3, 4, 5 объективно могут возникать дополнения и уточнения связанные с выбранными технологиями или еще бог его знает с чем, что может умерить "аппетит" или наоборот "подстегнуть" его, возможны возвраты к п 2 и его доработка.
6. параллельно с 2, 3, 4 - разработка и уточнение спецификаций ввода данных в систему:
- автоматический импорт (CSV и др. форматы, e-mail, EDI, репликации и синхронизации с неким источником данных - непосредственный импорт из внешних ДБ);
- полуавтоматический (контроллируемый оператором) импорт, (напр. ввод скан-форм или "натравливание" на входные файлы, т.е. запуск процедур автоматического иморта);
- формы для ручного ввода (поддержка корректности работы операторов, всевозможные хелперы (та же оперативная информация), мастеры, "защиты от дурака" и всё прочее дружественно-интерфейсное);
7. имеем выход программы как результат неких операций/вычислений над сущностями + способ отображения результата (твердая копия, экранная форма, электронный документ, EDI-сообщения, експорт во внешнее хранилище, вывод в OLAP и т.д.) согласованный в пп 1 и 2;
8. имплементация, тестирование, процедура сдачи/приемки - это все тоже целая история, и существует достаточно всякой инфы, советов и трудов на эту тему.
tygra писал:Как раз разработку начинают с того, что спрашивают, чего должна делать программа
разработку начинают с того, что спрашивают - а для чего нужна программа-то, а что вы хотите от программы получить в конечном итоге?
Что она должна в процессе делать - это уже, в большей степени, говорят проектировщики и аналитики (правда, не только лишь самостоятельно, опираясь на "всемирный опыт", но и с помощью специалистов/знатоков тонкостей конкретного бизнеса заказчика, грамотных сотрудников).
То, что многие сразу ударяются в анализ и подробности бизнес-оперций, спрашивая у заказчика, как именно они работают, планируя их просто автоматизировать - не есть гут. Как яркий пример тому - система учета товаров на складах. Почти ВСЕ учетные программы 10 летней давности учитывали товары на складе так же, как это делают кладовщики при ручном учете, т.е. автоматизировали учет по карточкам. Эта схема неплохо работает только в условиях постоянных поставщиков и цен. Компьютерный учет породил совсем другую системы учета - партионную, которая вообще труднопредставима в ведении бизнеса без автоматической вычислительной системы.
Почти в каждом моем проекте мне удавалось находить решения, оптимизирующие и даже реорганизующую некоторые бизнес-процессы заказчика, именно потому, что всегда начинал отталкиваться только от такой схемы:
вход - черный ящик - выход.
|
