goldenfoodsДело, в том что в этом случае наверное нужен системный архитектор, которого нет. Но еще вопрос, где взять эти методологии, паттерны? Есть какой-то ГОСТ или еще что-то?

Конечно нужен системный архитектор. А без труда архитектора делать систему на 70 пользователей и 10 млн зап/год будет авантюрой.

Где взять методологии и паттерны? Они широко известны. Их знает каждый (почти) IT специалист. Информации по ним очень много.
Для паттернов проектирования есть свои каталоги, такие как книга Гамма и др.
http://www.ozon.ru/context/detail/id/2457392/.
По методологиям есть тоже свой блок информации, и программная поддержка. Есть названия этих методологий, Microsft Solution Framework (MSF), Rational Unified Proccess (RUP), eXtreme Programming (XP). И множество литературы, напр. книги Кента Бека. По поводу ГОСТ ов на это как то никогда не интересовался.

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

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

ViPRosMumbo,

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

Да понимаешь, ну странно. Разработать - хотят. А создать условия для разработки? Вроде как и не хотят. Ну как так?

Ведь заказчик себе то не враг. Почему нельзя с ним поговорить и объяснить, что ему нужна информационная поддержка на все время жизни его компании. Что поддержка нужна систематическая, а не какая-то стихиьйная. Что есть модели, как сделать. А 15К и 3 месяца, и потом ожидать ERP на 70 пользователей, это же правда как скотчем автомобиль клеить...

iscrafm,

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

iscrafmпочему других людей? Речь идет только о конкретном нике Mumbo.


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

iscrafmMumboiscrafm,
Насчет прототипирования ты, увы, сам с собой поспорил и несогласен оказался.

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

Не, ты опять врешь. Сам придумал за меня ерунду и сам же ее оспаривал. То есть спорил сам с собой.


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

Bogdanov Andrey,
Миф о крайней легкости процесса разработки крайне выгоден тем аферистам и жуликам, кто собирается играть на чужой доверчивости. Подобно коту Базилио и лисе Алисе, они уговаривают людей закопать их денюжки на их поле чудес. Которое дает волшебные результаты без усилий. По их лживым утверждениям, чудо-средство которое они продают, позволяет осуществлять проекты вопреки всем основным положениям процесса разработки. Якобы, вполне обходясь и без сбора требований, и без проектирования, и без сопровождения, проект будет успешным.
И тут разное понимание успеха. Для кидал описанного типа успехом оказывается срыв проекта. Потому, что он освобождает от ответственности, от сопровождения, на которое при новой разработке приходится до 80% усилий. Кроме того, такой срыв проекта, как создание никому не нужной ерунды, сделанной без управления требованиями, возможно, влечет за собой новый заказ. Получается, что для аферистов чем хуже - тем лучше.
Есть и
Непонимающих того, что управление требованиями, проектирование, сопровождение суть необходимые для успеха проекта (успеха, понимаемого как улучшение

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

iscrafmMumbo,

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

Модели разработки созданы как интеграция лучшей практики ведущих экспертов мира в области разработки ПО. Они являются суммой наиболее успешного опыта. Эти модели уникально поименованы, тщательно проработаны, широко опубликованы, разносторонне обсуждены и повсеместно внедрены в производство.
Сейчас это уже не теория, а успешная, проверенная, современная практика миллионов людей.
И модели эти, среди прочего, регламентируют потоки работ и роли, которые необходимы для полноценной разработки. Поэтому, нет необходимости изобретать какие-то велосипеды. Ролевая структура коллектива уже известна для каждой методологии. Архитектор, как и менеджер продукта, как и программист, как и тестировщик - это совершенно необходимые для полноценной разработки роли.