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 летней давности учитывали товары на складе так же, как это делают кладовщики при ручном учете, т.е. автоматизировали учет по карточкам. Эта схема неплохо работает только в условиях постоянных поставщиков и цен. Компьютерный учет породил совсем другую системы учета - партионную, которая вообще труднопредставима в ведении бизнеса без автоматической вычислительной системы.

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

2 Cat2

Именно, о том-то и речь.
Т.е. имеем ту же самую схему:
входные данные - некая обработка - выходные данные

оперативная информация - один из видов выходных данных, т.е. тех, которые получаются в результате вычислений, производимых системой над входными данными. Это отчет о некоторых текущих цифрах/фактах.

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

2 Репликант

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

автор писал:
выбор технологий (а я чем располагаю-то? ).
Всё это по кругу вплоть до "сходимости процесса".
По идее следует уточнить какой процесс имеется в виду
Процесс сбора требований. А ты что подумал? :)
В советской методологии разработки автоматизированных систем, этот этап называется постановка задачи . Именно на этом этапе большинство вопросов преходят из состояния "ЧТО" в состояние "КАК". В те счастливые времена ТЗ были именно тем, чем они должны быть, а именно ТЗ. Если в ТЗ не уточнены некоторые моменты, то именно потому что само это уточнение требует знания технологий (а это уже моя сторона). Вполне нормальной ситуацией было оправить ТЗ на доработку, приложив ворох технических замечаний. Автор топика будет отправлять это все самому себе, пока не утрясуться все детали и не будет четко представлено, КАК именно разрабатываемая система будет выполнять то, ЧТО от нее хотят.

Берем именно описанную ситуацию - есть конкретный человек (один) которому все это делать. И мы ему подсказываем, общий план его действий. У этого человека есть вполне конечный круг технологий которыми он располагает. В результате анализа предметной области, классификации требований он выбирает из тех технологий такие, которые помогут решить заданную задачу с максимальной эффективностью, (или, вообще, помогут решить как таковую :) )
Каждая технология имеет свои сильные и слабые стороны. Сопоставляя возможности выбранных технологий и требования (как явные, так и не явные) мы отчетливо видим, что некоторые вещи "как 2 пальца об асфальт", а некоторые явно займут приличное время. Более того, технологиям свойственно обладать ограничениями , которые вполне объективно могут противоречить входным требованиям (напр. заказчик хочет задействовать в системе имеющийся парк машин и сетевого оборудования и совершенно не собирается покупать именно под эту задачу сервак за $10 000, хотя под заявленное требуемое количество клиентских мест более уместен MS SQL Enterprise, но под него нет машины, а он работает похуже на однопроцессорных машинах, чем Standart Edition, но последний хуже переносит нагрузку одновременно большого числа подключенных клиентов, а выбрать придется именно ее. В этом случае стоит согласовать время отклика в системе. Или выбрать распределенную схему, но тогда убрать из требований пункт "сделать все в одном ящике, который я спрячу" и т.д.). Или наоборот, технологии могут иметь некоторые особенности-преимущества, рассказав о которых заказчику, мы можем напроситься на дополнительные требования/функциональность и дополнительный бюджет.

автор писал:То есть если брать те же UP/RUP, то технология выбирается к концу Начальной фазы, а не к концу 1-й, 2-й или NN-й деятельности анализа
кажется я сказал так: (а я чем располагаю-то? ).
т.е. Автор топика не располагает бесконечным множеством технологий, он располагает некоторыми, из которых ему придется выбирать наиболее подходящие. Вполне возможно пересечение требований и ограничений. см. предыдущий абзац.
В идеале - ты прав. Если есть возможность выбрать из ПРОИЗВОЛЬНОЙ технологии, то да. Но здесь - нет. Я же не советую ему как разрабатывать приложения в общем случае в условиях сильной и "разношерстной" команды. Мы советуем ОДНОМУ человеку, как ему вообще справиться со всем этим... Если не ошибаюсь, то вопрос стоит именно так, хоть автор этого и не озвучил.

автор писал:4. рекурсивно повторяем предыдущий пункт, дробя задачи, добираясь до простейших неделимых сущностей и операций в рамках предметной области и выбранных технологий;

Если брать процессы UP/RUP, то "рекурсивно", а точнее циклически или итеративно повторяются пп.1-6 и 8
Ну, не знаю насчет RUP, но я не приступлю к 3 и 4 ни-за-что , пока не разберусь окончательно с 1 и 2. Ибо это означет только одно - бардак в голове, нет четкого представления задачи. Неумение выбрать оптимальный путь. Перед началом работы работы над 3 и 4 я должен полностью "разложить по полочкам" свои знания о предметной области. Я крайне не люблю ситуаций, когда на этапе проектирования обнаруживается нехватка информации/требований.

Как по RUP - это все еще часть анализа, или уже проектирование??? :)
Или допустимо полуграмотное (с т.з. предметной области) проектирование?

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

Позволь немного уточнить: если брать процессы... (или даже структурный подход), то бизнес-анализ (БА) нужен, например, для того, чтобы лучше выяснить суть бизнеса и это иногда необходимо (особенно при российской специфике, когда "черт ногу сломит"), чтобы сформировать видение, требования и получить те же системные ВИ, т.е лучше понять, что же необходимо автоматизировать.
Ты не обратил внимание на то, что я применяю слово КАК . И могу в очередной раз подписаться под тем, что сказал, так же как в равной степени и под твоим ЧТО , т.к. ни возражений ни противоречий не вижу.

автор писал:Конечно, если это все можно получить без БА, то насаждение БА "грубой силой" - это обычная медвежья услуга, например, с целью обычной наживы
Ну, это немного не то, на чем мне хотелось бы зарабатывать, просто жаль на это времени. Был бы счастлив всю жизнь получать очень внятные ТЗ. В крайнем случае изредка показывать, как его надо составлять, чтобы исполнитель был доволен.

автор писал:Сорри, немного не понял: если ты ему показывал черный ящик (ЧЯ), а он тебе подавал свои данные на вход и получал то, что нужно ему на выходе, то как ты можешь изменить внешнюю среду (контекст), в к-рой существует твой ЧЯ?
Хм... удивительный вопрос. Даже неожиданно...
А что, заказчик только вчера родился? И он ни дня не проработал? У него уже наверняка есть некая учетная система, может быть даже ручная. Весь его учет именно так и работает - получает одни данные, обрабатывает их, и выдает другие.
Это не моя система - "черный ящик" . Это его система для меня должна быть "черный ящик". Т.е. я уверен, что крайне вредно с первых же минут вникать в то, КАК именно заказчик производит свои операции. Это, скорее, психологический момент, но очень важный. Стоит его не соблюсти, и система вместе с заказчиком могут недосчитаться нескольких неплохих идей. Да и сам исполнитель, в конечном итоге тоже. (наработки и удачные решения надо копить :) )

автор писал:Т.е tygra высказал как бы для структурно-функционального подхода, а vdimas - как бы для ООАП, т.е все зависит от подходаМне довелось немало попроектировать с применением обоих подходов.
"Инкапсулированный" ООАП всегда дает много бонусов при разработке, и, чем сложнее система, тем больше бонусов:
(не из учебников, а только лишь из собственного опыта, сплошное IMHO)
- более разумная конечная архитектура и протоколы взаимодействия;
- сильная "системная" часть, сводящая имплементацию даже сложных вещей к тривиальнейшему занятию;
- независимость модулей, возможность безболезненного развития/масштабирования;
- более мелкое дробление сущностей (побочный эффект наследования при правильном проектировании), как следствие - управляемость кода;
- повышенние надежности, естественное изолирование и локализация источников "опасности".

из минусов:
- неудачно спроектированная система "лечению" не подлежит, только на помойку;
- большая трудоемкость на начальном этапе, т.е. первый результат "виден" далеко не сразу (это плата за повышение масштабируемости, надежности, и за уменьшение времени на программирование и отладку алгоритмов.)

tygra пишет клиент-серверные системы на Дельфи. ООП у него - только в GUI.
Большая часть остального приложения оперирует непосредственно рекордсетами. Так что неудивителен различный взгляд на эти вещи.

2 ЦК

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

Если у меня и есть толстые книги (600 и более стр), то это только объективно толстые справочники, (типа справочник администратора MS SQL, справочник по сетевым протоколам, и т.д.).

Насчет Кнута: во-первых, это учебное пособие, во-вторых, он тоже объективно толстый из-за большого количества информации. Сам стиль изложения мне импонирует - минимум воды (не всегда, но в большинстве тем именно так). Так что надо рассматривать не толщину книги, а удельное количество инф-ии на страницу текста.

---
а вообще, хороших книг мало, походы в книжные ряды без определенной цели, с тем чтобы "просто посмотреть чего в мире есть", ничего, кроме разочарования не приносят....