|
2 vdimas:
Еще было бы неплохо, по-максимуму использовать тот факт, что соединение будет цифровым, а на стороне клиента будет TV-приставка. (т.е. там будет как минимум 1 процессор!!!)
Все. Именно такая постановка. ...
И что? Еще раз: где здесь именно необходимо искусство? Если вы беретесь в первый или второй раз, то - да, для вас в этом проекте будет много нового и интересного, т.е сплошное творчество, эксперимент и искусство. это понятно. Но вы все-таки путаете необходимость и непрофессионализм заказчика, заключающийся в позволении заниматься вам искусством. Тендер-то он ведь небось не проводил или ваше решение стоит меньше 10 тыс.$$? Вы хотите сказать, что область, к-рой вы занимаетесь новая или передовая? Отнюдь! Это точно. Возможно ваше решение будет значительно дешевле и при этом будет удовлетворять заказчика. Может быть. Но сначала немного истории. Ground matters так сказать немного в тему. А заодно прихвастануть разнообразным опытом (потому что вы поймете о чем речь).
В период 1997-1999 гг. я занимался проектами, посвященными IP-телефонии (IPT, VoIP и прочии технологии). Тогда в России и даже в Москве все это было в новинку. Сначала внедряли не очень дорогие решения (10-30 тыс.$$) на VocalTec TG версий 2.х/3.х, а потом пошли наши разработки - не хуже и дешевле, потом Cisco 2600/3600 начали выдавать под длительный кредит и цены на те же Cisco или VTG 3 упали так, что многие руководители предприятий просто ох..вали как здорово теперь можно экономить на междугородном/международном телефонном трафике пока ММТ нес убытки. И что? Кулибины и первопроходцы (т.е мы) стали не нужны. Сейчас этот рынок IPT-решений в Москве поделен несколькими компаниями и мелким командам там просто делать нечего, если только заказчик не в танке . Может вам не стоит изобретать велосипед, а исследовать рынок подобных решений более досконально? Вот к примеру: в 1997-1999гг у нас основной проблемой, помнится, была большая задержка (>500 ms) на международных и спутниковых каналах, к к-рой IP-телефония очень чувствительна даже несмотря на все ее специальные механизмы. Как мы с ней только не боролись - туннелирование, выделенные порты и таблицы маршрутизации у провайдера, смена провайдера, использование сверхмощных аппаратных кодеков на локальных шлюзах и т.д. и т.п. Сейчас такой проблемы просто нет - качество каналов очень высокое, а цены низкие на те же допуслуги (туннели и тп.). Любая контора, использующая междугородние/международные переговоры, если там не дураки сидят, сейчас использует решения IP-телефонии.
Это, конечно, может не к месту и лирика, НО учтите, что имеется развитие рынка этих решений, за к-рым необходимо следить и заказчик тоже может следить. Так что это не рынок заказных ИС/ПО, к-рый еще очень не скоро насытится.
Дальше больше - решили заняться видеоконференцсвязью и IPTV. Там уже были другие проблемы - требовательность к полосе пропускания (минимум 128 кбит/с) для приемлимого качества. Однако, дело было в 1999гг и такие каналы даже в Москве стоили где-то по-мойму 300-400$ в месяц. Рынок тогда пестрил предложениями различных мощных программно-аппаратных кодеков, тот же MPEG4 и LBRV-кодеки уже набирали обороты, т.е по сравнению с ними MPEG1 и MPEG2 были просто прожорливым дерьмом. Заплатив за плату с таким крутым кодеком (10-20 тыс.$$) можно было передавать видео чутьли не в формате QCIF (20-30 fps) или даже DQCIF (5-10 fps) через канал в 64 кбит/с при цвете RGB 3:2:2 или что-то там такое, т.е достаточно приличная цветопередача. Естественно все заказчики охали и не собирались выкладывать такие "огромные " бабки, хотя мы им всем (ламерам таким) показывали все официальные цены и подробные рассчеты (ТЭО)., что эти средства окупятся уже буквально через год. Поняв, что стену не прошибить начали искать российских Кулибиных и Самоделкиных. Да, нашли и много! Каких только нам кодеков не предлагали. От одного научно-институтского варианта я помню у меня варежка отвалилась даже - что-то типа QCIF (25 fps) через 16 кбит/с! Но проект тот был в стадии разработки и уже лет 5. И остальные проекты также были сомнительны в смысле гарантий завершения - одно дело иметь крутой алгоритм, идеи и т.д, а совсем другое - иметь готовое решение , к-рое установил и смотри. К чему я тут это, разблотался-то? Вот: странно, что вы вроде решаете не простую, но и не новую п роблему, а пытаетесь решить коллективом из 2 человек. Каковы условия проекта? Вы исследовали рынок подобных решений? Т.е прежде чем браться, поискали бы (за счет заказчика) на Западе и по России, авось есть Кулибины, к-рые все это уже сделали и очень неплохо. Исходить надо прежде всего из рациональности затеи. Так же не плохо заручиться поддержкой и гарантией заказчика, чтобы завтра не оказаться у разбитого корыта, когда он найдет более лучшее или дешевое решение на стороне. Мне это желание хорошо знакомо, когда все хочется самому - "покорить Эльбрус" в 1001-й раз. От этого желания надо избавляться. Темы эта очень и очень не нова - DCTV, MMTV и прочие конвергентные IP-технологии. Что вы думаете по этому поводу?
... Границ для фантазии нет. Концепция и реализация полностью в нашем ведении.
Эта фраза подозрительна сама по себе. Вы еще выполняли роль и маркетолога(ов) для заказчика? Поскольку делаются какие-то предварительные выводы о потребностях будущих пользователей - "Концепция ... полностью в нашем ведении" или имелось в виду что-то другое?
Все это уже есть, как отдельные продукты, но нужна все же единая СИСТЕМА. Да и цены нереальные для повсеместного внедрения. На стороне клиента должна стоять TV-приставка стоимостью гораздо меньше $100, чтобы это вообще имело смысл.
Вот-вот и у нас те же проблемы были. Это сегодня нереальные? Может быть, если вы рынок исследовали. А через полгода? Есть хоть какие-то грубые прогнозы или вы абсолютно уверены, что уже закончите проект в срок
В проекте участвует 2 чел, у которых за плечами опыт разработки вдвоем не уступающих по сложности проектов. Несмотря на все мое уважение к Репликанту, именно в нашем случае никак невозможно полностью реализовать предложенный алгоритм (имеем 2 чел на ВСЕ!).
....
UML я использую лишь для проектирования статической структуры классов и схемы БД (как электронщик не в состоянии работать без принципиальной/функциональной схемы, так же невозможно писать программы без схемы классов и БД. )
Если вы имеете в виду "алгоритм" (пункты или стадии анализ...тестирование в посте Дата: вчера, 09:40), то дело не в людях, а в ролях . Я также имею опыть работы в проекте из 2-х человек, где я был аналитиком-проектировщиком и программистом в одном лице. Более того у меня был проект из меня одного (бизнес-аналитик и РБП), ну и еще секретаря для работы с документами. Все. IMO у вас же в корне неправильный или какой-то однобокий подход в проектировании - вы получаете и используете только статическую модель архитектуры. Чтобы понять ЧТО делает ваша система необходимо читать варианты использования, а чтобы понять КАК она это делает - читать исходные тексты на С++ Вы также как-то неявно приравниваете по сути функциональные модели/схемы или потоков данных (DFD) к статическими моделями данных/классов. Эти модели необходимо дополняют друг друга, составляя,кстати, основу структурной методологии SAD
Почему не взять больше людей? А опыт подсказывает, что в подобных проектах (близких по духу к исследовательским) количество людей мало что решает, решает их качество. :)
Опыт не является новым знанием. Если у вас сроки не ограничены жестко, нет необходимости в поддержке системы (закодировал, отдал и все) и если у вас доверительные отношения с заказчиком, т.е он не станет с вас спрашивать доказательства состоятельности вашей архитектуры, то почему бы и не вдвоем?
В одном из предыдущих проектов было задействовано приличное количество людей разной спецификации. Этот проект еле двигался, пока практически совсем не заглох. И только когда 2 чел, изучили в полной мере смежные области, они вдвоем сделали то, что не могли 15 (среди которых были даже доценты, специализирующиеся на предметной области проекта), и причем очень быстро.
Вы вот неявно сетуете на ИТ-науку. А она ведь не может быть неправильной, т.к ее выводы/результаты доказаны и апробированны множеством проектов. Извините, но IMHO в вас говорит отсутствие определенного образования. Можно предположить, что вам не хватает знаний в области инженерии ПО и ИТ-менеджмента. Так зачем пытаться судить? Подобные суждения чем-то напоминают высказывания типа "MSF круче всех" или "Windows - ацтой". Пожалуйста, не уподобляйтесь. Ваш проект мог провалиться из-за десятка причин. Я сразу могу предположить две - неумелое руководство и организация проекта или вообще их полное отсутствие и непрофессионализм нек-рых участников :о(
.. Так что, бывают ситуации, когда слишком хорошее разделение "труда" (в нашей IT области я бы назвал это разделением "знаний"), так вот в некоторых ситуациях черезчур глубокая специализация означает провал, особенно тогда, когда проект лежит на стыке множества технологий.
А так как знать ВСЕ одонозначно НЕВОЗМОЖНО, то работа в таком ключе и есть то самое исскуство, потому как такие понятия как "чутье", "творчество", "вдохновение" преобретают вполне осмысленное и серьезное значение.
Здесь я вам ничего не могу сказать, кроме того, что уже говорил раньше. Я согласен с вами и уже говорил выше, что там, где есть новое и не исследованное , то там есть доля искусства и тем более место для интуиции. Мне сложно судить на сколько сложно было бы использовать промышленный подход именно в вашем проекте поскольку я просто не знаю всех условий проекта, конъюнктуру рынка аналогичных решений, предложения рынка труда и т.д и т.д. Если доказывать, то надо разбираться, а "на пальцах" можно только объяснять что в общем лучше и лучше, чем что
Проект охватывает следующие предметные области:
1. сжатие и кодирование информации.
2. цифровая обработка изображения и звука.
3. операционные системы реального времени.
4. распределенная сетевая инфраструктура, критичная к времени отклика.
5. защита информации.
6. учет и анализ (тот самый учет и тот самый анализ)
7. проектирование аппаратной части (причем там тоже полно подразделов - "узкие" специалисты цифровики или аналогивики или высокочастотники просто не поймут друг друга)
8. проектирование функционального GUI, подходящего для отображения на бытовом TV (я не ошибусь, если скажу, что спецов по последнему пункту просто нет! пока это все только лишь набирает обороты и эти спецы только учаться)
Позволю себе предположить, что 1 и 2 - это задача для одного спеца. 3 и 4 - тоже для одного. 5, 6 и пожалуй 8 - это общие задачи и тоже для одного. 7 - только для одного. Почему? Потому что я могу судить по своим хорошим знакомым, к-рые работают в одной московской конторе, к-рая занимается цифро-аналоговыми устройствами. Правда, их основнй профиль - это цифровые устройства на базе процессоров Atmel, Risc-процессоров Intel, Hitachi, смарткарты, флэшнакопители высокой емкости, заказные сети на базе RS-422, FireWire и т.п. (Иногда за пивом они мне "лекции" читают что там и как у них в жтой области творится.) Также следует учитывать, что, как правило, мало специалистов только по аналоговым или только по цифровыми сигналам и их обработке. Таковыми являются достаточно узкие специалисты, например, по hi-end звукотехнике (колонки/динамики) или спутниковому ТВ (декодеры). Просто, кажется, дажев ВУЗах обучают и тому (A,D), и тому (D/A,A/D). Вроде обычное деление, например, такое: A/D,D/A и только ТВ-приемники, A/D,D/A и только радиосвязь, A/D,D/A и только студийное обородуование или мультимедиа системы. И по-мойму у них у всех очень много смежных или общих знаний. Может я не прав?
... Если Репликант сможет предложить алгоритм работы и используемые средства именно для данного случая, это было бы действительно интересно.
Алгоритм тот же самый! Ваши пункты 1-8 меня просто "слегка" смущают. Возхможны 2 выбора: либо большая команда узких с пециалистов, либо маленькая команда универсалов . Но алгоритм тот же самый потому что он определяет грамотный (инженерный) подход . Совсем другое дело условия проекта. Если бы у вас был срок 3 мес, то в двоем вы бы не справились (скорее всего) поэтоу выбор - большая команда. Если срок 1 год, то можно справиться и вдовем, да еще при этом денег заработать больше. Также и насчет бюджета проекта. Маленький бюджет можно компенсировать уменьшением числа участников и растягиванем проекта во времени. Вот и весь "алгоритм" :о)
У меня складывается такое впечатление, что разработка архитектуры для многих является прямо-таки камнем преткновения. Я уверен, что бизнес-проекты для большинства нужд - торговля, ... и т.д. и т.п. в принципе ДОЛЖНЫ быть однотипны (ну, или поделены на группы по требуемой ропускной способности/масштабируемости)
А что значит "однотипны"? Даже концептуальная модель системы для одной и той же области ФХД (например, бухучет) и компаний одного организационного и целевого типа (например, ООО, в одном городе, торговля ТНП, штат 50 чел) может принципиально отличаться, например, из-за наличия той же двойной и тройной бухгалтерии. Это соответственно сказывается на архитектуре, т.е просто статической/динамической модели проектирования , когда вообще никакой речи о пропускной способности/масштабируемости и не идет.
Что же касается "камня преткновения", то не понятно, что имеется в виду. Но таких камней не должно быть, а главное они не должны создаваться не только для архитектуры, но также и для программных алгоритмов, GUI и т.д
Есть ли у кого-нибудь пример разработки более 3-х бизнес-систем таких, что абсолютно никаких похожих(подобных) моментов в этих системах не было?
Ваш вопрос по сути тривиален поскольку таких программных систем, не содержащих моментов, похожих/подобных моментам в др.системах не существует не то, что в одной конторе, а даже в мире. Даже промышленные, военные, научные, RT и прочие специфические системы имеют очень много общего - десятки похожих архитектурных моментов, если не сотни. Что касается систем для автоматизации ФХД, то там вообще похожих моментов еще больше и проще перечислить, что у них непохожего :о}
|
