ANTICHAT — форум по информационной безопасности, OSINT и технологиям

ЗЫ: За 50 - 70, баксов сделаю все за полтора часа.
Чек не воспринимай все близко к сердцу), но я серьезно)

Вернусь к старой теме (подтверждая то о чём постом выше писал De-visible), хочу привести цитату одного из известных архитекторов/ПМ:

Всем кому интересно, рекомендую почитать: http://gaperton.livejournal.com/32772.html

__________________
Я отдал бы немало за пару крыльев,
Я отдал бы немало за третий глаз
За руку на которой четырнадцать пальцев
Мне нужен для дыхания другой газ..

Мой блог:http://qwazar.ru/.

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

Представим что все описанное выше является техническим заданием. В соответствии со стратегией проектирования интерактивных клиент-серверных приложений, проектировочная комманда придерживающиеся правил SSD (Solution Deployment Descriptor)
в первую очередь приступит к реализации концептуального проектирования (в стадии разработки которого входит: анализ требований клиента, бизнес-сценарий реализующий мост между клиентом и разработчиком). Вот на этом моменте мы и вернемся к теме блок-схем. В соответствии со стандартом SSD в бизнес-сценарий входят из множества эти 2 пункта:
- блок-схема нахождения оборудования (не обязательно)
- блок-схема поочередного выполнения бизнес-процессов
В соответствии с этим, можно сделать вывод:

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

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

Qwazar если ты до сих пор думаешь о блок-схемах так же как раньше. То мне тебя жаль и спор продолжать в теме не буду.

procedure, ты тёплое с мягким не путай. Я говорил о блок-схемах в том ключе, в котором началася этот топик. А ты пишешь о бизнес-процессах.

__________________
Я отдал бы немало за пару крыльев,
Я отдал бы немало за третий глаз
За руку на которой четырнадцать пальцев
Мне нужен для дыхания другой газ..

Мой блог:http://qwazar.ru/.

Уважаемый, это ты что перепутал.
Бизнес-процесс неотъемлемая часть любого серьезного приложения. Именно в блок-схемах/документированном виде/и.т.д. проектировочная комманда осуществляет представление разработчикам.

Если бы ты был немного внимательней, ты бы понял, - что я пишу о концептуальном программировании. Если тебе это о чем нибудь говорит.

procedure, прошу не лицемерить, я видел твой коммент у меня в репке.

Я говорю об использовании блоксхем при написании приложений конечным программистом, а ты о чёмто другом.

__________________
Я отдал бы немало за пару крыльев,
Я отдал бы немало за третий глаз
За руку на которой четырнадцать пальцев
Мне нужен для дыхания другой газ..

Мой блог:http://qwazar.ru/.

Вот тут ты проявил свою внимательность получше. Жаль, что не там где надо.

Я тебе объясняю что одним из этапов разработки приложения, является концептуальная разработка, в которую входит составление блок-схем. Которые в свою очередь передаются комманде разработчиков и документацией к проекту.

p.s. читай SDD и не спорь на банальные вещи. Тем более со мной не советую на подобные темы спорить. Я этому посвятил достаточно времени, чтобы быть уверенным в своих словах.

procedure, блин, ну спасибо что объяснил мне, как работают команды программистов. Если ты всё таки почитаешь всё то, что написано выше, у тебя есть шанс понять, что речь идёт не о использовании блок-схем в бизнес процессах, а об использовании блок-схем при разработке.

__________________
Я отдал бы немало за пару крыльев,
Я отдал бы немало за третий глаз
За руку на которой четырнадцать пальцев
Мне нужен для дыхания другой газ..

Мой блог:http://qwazar.ru/.

Qwazar я не знаю это идиоту понятно. Но тебе нет.

Бизнес-процессы являются частью концептуальной разработки! Что непосредственно является частью разработки приложений.

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