Проектирование, системная архитектура

[J++]

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

[zss_vrn]

В Воронеже не нашел. Ездим несколько лет в Москву и Питер, там есть. Бумажки дают. Но эти бумажки мало кому нужны - ценятся бумажки от MS, Оracle.

Можно попытаться договориться с ВГУ или напрямую с Релексом, потому что препы в основном оттуда.

ИМХО, чтение книжек и собственный опыт гораздо более эффективны.

[Billingist]

J++, а что конкретно понимается под "проектированием, системная архитектура"

[J++]

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

Ведь разные комплексы требуют разного.

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

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

Еще много чего интересного на свете бывает.

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

Наводят на эти мысли грустные оценки многих программерских проектов. Как только проект "переваливает" некоторый порог объема и сложности - начинается дурдом (теперешний наш не исключение).

Ведь умудряются же как-то архитекторы планировать и строить целые города.

Если допустили неконтролируемое развитие города, то в нем тоже начинается дурдом. Но все же: если главный архитектор и власти не совсем коррумпированы и не дураки, то есть некий генплан, который пытаются соблюдать, есть понимание - какие магистрали/мощности приблизительно нужны, чтобы обеспечить воду/газ/отопление/электричество/транспорт/соц.сферу. И как-то +- километр, но ведь обеспечивают!

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

Да чего там большие проекты, вот живой пример неверной постановки задачи. Ма-аленькой, как сарай! и то человек умудрился ее сделать непригодной для работы.

Делала я программу для одной мед. конторы. Я ее делала на C++Builder +MSAccess (если честно - что под руку попало, а на Access я программировать не умею, и юзала его только в качестве БД).
До сих пор меня в этой конторе хвалят, хотя времени прошло ХЗ сколько и я там не появляюсь

До меня эту же программу, на Access-е, делал парень, которого я не знаю. Но работать на ней было невозможно.

Человек "завязал" друг на друга два - по сути - абсолютно независимых бизнес-процесса. В результате "второму" процессу приходилось ждать, когда исчерпается очередь "первых". А туда, в очередь - нужно постоянно запихивать что-то новое, и не получается дождаться ее освобождения! Именно так работает эта контора!

Вот и пример - что, он плохой программер? Я видела его код на Access. Даже не зная Access, могу сказать - там вменяемый код (слова-то для меня понятные). Мало того, его вариант - на "чистом" Access - мог быть гораздо лучше, чем моя связка Access и C++Builder, хотя бы из-за отсутствия проблем с глюками BDE, и вообще - нет "слоя" ODBC.

Косяк был ТОЛЬКО в постановке задачи! и все!

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

Тот сказал - окей, я сделаю, и еще решил мою программу переписать с дополненной функциональностью.

Переписал. Функциональность дополнил.
Дня через 3 операторы взвыли и контора перешла опять на мою версию. Несмотря на то, что человек был из "мед. кругов", лучше меня знал специфику работы и т.п. - он умудрился повторить ошибку моего предшественника: связал два несвязанных бизнес-процесса.

На моей версии, конечно, нехватает функциональности (т.к. требования изменились), но на новой работать стало вообще невозможно.

Косяк в программировании еще можно "вылечить" с какими-то затратами, но косяк в постановке задачи, в проекте - это ж@па. Затраты на исправление несравнимы.

Вот и ищу, где можно научиться ставить задачи, планировать коммуникации и т.п. Ведь есть же у нас, допустим, всякие строяки, где учат строить если не города, так микрорайоны и т.п. Не все будут такими вещами заниматься, и не все смогут. Но это будут далеко не единицы - гениальные одиночки! Это будут обычные нормальные люди!

Т.е. ТАМ существует наука - как это делать + есть некая разумная система обучения. А не просто "свободное искусство". Есть нормативы, ГОСТы, СНИПы, на которые можно опереться.

Вот и смотрю - как бы у нас в IT такое найти/сделать?

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

Я лично наблюдала, что при НОРМАЛЬНОЙ организации работы в той же Корее умеют строить весьма качественно и почти не отклоняться от сроков.

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

Думаю, это во многом оттого, что проектирование ПО - пока больше искусство, чем наука. Хочется прибавить немного "науки" к этому делу. Интуиция - это хорошо, когда она опирается на солидную базу знаний и умений вот с этим плохо

[zss_vrn]

J++,
Согласен - проектирование ПО больше искусство, чем наука.

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

Есть старые ГОСТы, которыми я сейчас начал пользоваться. Это помогает не программистам, а заказчикам. Проще общаться на одном языке. Разумеется, я использую только то, что надо - структуру документов, не более.

В умных книгах пишут, что сам процесс написания программы занимает 20% затрат от всего жизненного цикла. ИМХО, не зря пишут.

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

Жизненному циклу ПО сейчас учат, а проектирование программ именно в этом курсе. Но качество обучения... Лучше бы не учили.

[J++]

А чего бы нам умным и красивым не собраться на рюмочку чая (да хотя бы у меня в квартире, у меня нормально, если будет не больше 15 человек), и не подумать-поговорить об этом?

так сказать, провести неофициальную конференцию.

Можно и на базе какой-нибудь фирмы, которая согласится принять народ вечером или в выходной и напоить чаем (кофе, пивом)

Раз нет такой науки - нужно ее создать ))

Каждый сможет рассказать о своем опыте, удачах и неудачах, притащить с собой коллег-друзей (кто был руководителем проектов разного масштаба), обменяться всякими материалами, которые сможем найти в сети или еще где-то раскопать. Материалы размножить для всех - не проблема (у меня дома принтер-сканер-копир A4 стоит, только о бумаге и картридже подумать - или о CD-болванках).

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

Но конечно с каждого "докладчика" нужно попросить небольшой рассказ о том проекте, который он делал (делает).

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

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

Конечно, чистые "установщики Консультант+" нам не нужны, нужны именно разработчики, кому пришлось сильно работать и передними, и задними полушариями головного мозга

Мне кажется, можно будет уже на первом этапе хотя бы примерно расклассифицировать проекты (в моем пред. посте описана по крайней мере пара типов проектов), прикинуть их "аппетиты" по железу и коммуникациям (сеть) в зависимости от масштаба, класса и средств работы, прикинуть какие-то требования/нормы типа строительных СНИПов и т.п.

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

У меня на примете по крайней мере пара человек (не считая меня), которых я уже могу рекомендовать как руководителей серьезных проектов.

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

PS. Сергей, если что, с тебя - ГОСТы и опыт их применения

[zss_vrn]

J++,
Идея неплоха, но реализация мне представляется нереальной.

Представь, 15 человек, даже если использовать правило одного микрофона, захотят рассказать хотя бы по 30 минут. Это 7 часов слушания - тяжело. На обмен мнениями не останется ни сил, ни времени, ни пива.

Я иногда попадаю на всякие конференции - ужас, как правило.

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

[Billingist]

J++, воды очень много но по сути толком я так и не понял чего ты хочешь, насколько я понял интересует методология описания протекающих бизнес процессов, с последующим наглядным выводом постановки задачи?

[J++]

Не столько "методология описания", сколько так сказать, процесс принятия решений.

Допустим, описали основные бизнес-процессы и потоки данных. Но ведь на основе всего этого разные люди могут прийти к совершено разным выводам! Как прийти туда, куда нужно? Куда ведут основные тропинки?

Как ИССЛЕДОВАТЬ и ОПИСАТЬ бизнес-процессы - за этим дело не станет, народ опытный есть, информации полно, языки описания есть - хоть и не очень совершенные.

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

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

Т.е. мне нужен процесс - как все собранные данные проинтегрировать в голове в нечно единое. На что обращать особое внимание, чем можно пожертвовать (найти компромисс), чем пренебречь вообще.

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

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

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

Вот и хочу услышать от других, понять, примерно расклассифицировать системы по "стилям" работы. И как расставлять для них приоритеты. У меня опыт невелик, да и у каждого в отдельности тоже. Вместе можно собрать РАЗНЫХ людей, с РАЗНЫМИ системами "за плечами".

[J++]

Вот, наверное, могу наконец сформулировать так:

У нас есть стандартные ТЕХНОЛОГИИ (и железячные, и софтверные). У нас есть (теперь) некие стандарты и средства для описания бизнес-процессов и т.п.

У нас нет никакой стандартизации процесса принятия решений! Я же думаю, что она впоне возможна - не на все 100%, но до какой-то степени!

Хочу найти способ, как это сделать.

-----------------
Еще пример: есть некая фирма, в которой стоит биллинговая система. Клиентская часть сделана на WEB. Т.е. оператор работает в браузере.

С железом все ОК, машины хорошие, сеть быстрая.

Проблемы начались, когда число клиентов перевалило за сколько-то тысяч. В АРМе есть несколько комбобоксов, которые открывют список абонентов, найденный по некоему критерию (для дополнительного поиска и выбора). Как только этот список становится длиной порядка сотен абонентов - прорисовка комбобокса в браузере становится НУ ОЧЕНЬ МЕДЛЕННОЙ. Смахивает на неторопливую демонстрацию графических возможностей.

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

Сужать критерии поиска и извращаться только ради того, чтобы "удовлетворить" какой-то комбобокс - оператору НЕУДОБНО!

Вот тебе, и вроде все хорошо - технологии как положено, железо ОК, современность и т.п. А оператор матерится, удобство и скорость работы снизились по сравнению с обычной полу-наколенной поделкой на C++Builder. Можно ли было это предвидеть и подстраховаться? Не знаю. Пытаюсь понять - да или нет.

[zss_vrn]

J++,

Про принятие решения, ИМХО, все несколько проще. Есть постановка задачи и есть ресурсы (люди, деньги, время). Задачу можно решить миллионом способов, но только в рамках буджета (ресурсов). Когда сообразишь, что именно ты успеешь сделать (при условии, что заказчик будет доволен), то значительная часть вопросов отпадает.

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

Поддержка и развитие "живого" софта - это как уборка снега. Выпадет новый и придется опять убирать.

[J++]

Эх, блин

Сообщение от zss_vrn

"Есть постановка задачи"

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

Вот это и есть "основной вопрос марксизьма-ленинизьма"


А если серьезно -

Согласна со всем высказанным и почти во всем, что вы еще сможете сказать, т.к. на собственной шкуре выстрадано.

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

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

Вот и подумала о неофициальной конференции как об обмене опытом и вопросами со стороны публики. Правильно заданный вопрос - 0,5 литра ответа, а то и больше плюс другие могут видеть ситуацию несколько иначе, чем она смотрится "изнутри".

Именно неофициальной, т.к. официальные тусовки вырождаются то в подобие съезда ЦК КПСС (от каждого по докладу, каждому по памперсу на 80 кг, чтобы выдержать 8-часовое просиживание ж...), то в рекламную акцию по восхвалению продуктов, технологий и идеологий фирм-спонсоров.

Что до людей... 15 докладчиков - сумасшедший дом. Но я говорила про количество людей, которое способна вместить моя хата, а не про количество докладчиков

докладчиков - даже 5 будет много, 2-3 - было бы идеально, после чего - вопросы со стороны публики и "разбор полетов". Разумеется, неофициальный и без "оргвыводов"

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

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

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

Даже буддистские и христианские монахи не пренебрегают групповой медитацией, ибо человек обладает коллективным разумом, который может ярко проявиться, когда группа людей находится в близком контакте "идеи носятся в воздухе"

В общем, думайте. Я пока попробую отловить пару -тройку знакомых программеров, которым выпала судьба быть архитекторами (хотя бы подсистем) и взять у них интервью. Себя тоже не забуду.

Нужны еще критерии оценки систем, я их уже вверху писала

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

Вот еще -"аппетиты" по железу/коммуникационным параметрам, удаленность офисов/локальность, частота и объем обмена данными между офисами...

Каких-то критериев нехватает. Каких - напишите, кто увидит.

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

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

[tsyplakov]

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

[J++]

Я (пока) собираюсь ориентироваться на конец сентября - начало октября. Это самый оптимистичный срок, но думаю, что можно уложиться не позже Нового года

В это время большинство вернется из отпусков (загорелые, отдохнувшие и добрые) или еще не уйдет

Этот срок - в смысле если кто-то захочет собраться или - если не собраться, то опубликовать (хоть здесь) первые результаты изысканий.

Сейчас (за эти месяцы) я попытаюсь сделать следующее:

1) Выработать хотя бы ориентировочные критерии оценки и классификации систем (часть критериев уже была вверху).
Можно будет их вывесить здесь, чтобы обсуждать и дополнять.

2) Составить вопросы для интервью. Придумать выход - как обезопасить тех, у кого высокие требования со стороны службы безопасности и кто не имеет право разглашать конкретные цифры. Например, разрешить отвечать на вопросы не "в цифрах", а "в диапазонах" (типа от 200 до 500 рабочих мест).

3) Взять сколько смогу интервью у разработчиков (идеологов, архитекторов) различных систем;
надеюсь на то, что большинство из сидящих здесь не откажется ответить? тем более если примут участие в обсуждении критериев.

4) Если данных окажется достаточно, то выполнить хоть какую-то стат. обработку. На последнее, однако, надеяться сложно, потому что даже 10 -12 систем - маловато для статистики. К тому же они будут разнородные. Но постараться уловить хоть какие-то показатели и связи.

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

У меня уже "в ближайшем поле зрения" человек 7-8. Не все, наверное, согласятся, но ведь это ни к чему не обязывает.

[Alexey]

и не лень стока на форумах писать?

[1000w]

Alexey, это копи-паст)

[SteelViper]

Сообщение от tsyplakov

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

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

[Integrator]

Сообщение от J++

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

У нас нет и врядли будут. Можно получить бумажки по базовым практикам тех или иных поставщиков решений.
А так, только опыт и практика!!! ;-)
Есть вопросы, всегда рады помочь ;-) ...

[Integrator]

Сообщение от J++

Думаю, это во многом оттого, что проектирование ПО - пока больше искусство, чем наука. Хочется прибавить немного "науки" к этому делу. Интуиция - это хорошо, когда она опирается на солидную базу знаний и умений вот с этим плохо

Очень интересные изливания ;-) ... но есть тонкий момент ...
Проектирование ПО это немного искусства, немного науки и очень много "ТЕХНОЛОГИИ" ...

А база знаний и интуиция дело наживное ... ;-)

[Integrator]

Сообщение от J++

Раз нет такой науки - нужно ее создать ))

По чему же нет ... есть и очень активно развивается, называется она Software Engineering!

[Integrator]

Сообщение от zss_vrn

J++,
Жизненному циклу ПО сейчас учат, а проектирование программ именно в этом курсе. Но качество обучения... Лучше бы не учили.

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