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

Ватерфалл, Эджайл

(0) Книжек с таким названием - пол магазина

(0) [милости прошу сюда, в асю или почту.]
и ты всерьёз полагаешь, что кто-то станет тратить на это время?

Не совсем про разработку программ, но все-таки: Карел Чапек. "Как это делается". Пожалуй, актуально по сей день.

(3) Наставником быть тоже интересно
(1) Ну слова и технологии я себе тоже представляю, хотелось бы вживую посмотреть.
(4) Спасибо, посмотрю.

Недавно прочитал Макконнелла "Профессиональная разработка программного обеспечения", описывает мои проекты и организацию, в которой я работаю (динозавры в смоляной яме + напишем и исправим), но конкретных решений там не нашел.

(0) Посмотри тут http://clck.ru/BqbY

(7) :)

в принципе всё просто
1. логическое проектирование базы данных
максимальный отказ от всяких UML и прочих нотаций
бумага, карандаш, схема таблиц
ессно, нормализованных хотя бы до пятой формы
2. проектирование экранных форм (вьюшек)
3. напейсание, блеять, кода

Сразу чувствуется, что это форум серьезных разработчиков :)

самый трудный этап это логическое проектирование
возьми конфиги ТиС 7.7, УТ 10.3, УТ 11, УНФ
везде по-разному, везде разные парадигмы

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

Бесплатно такой херней никто заниматься не будет.

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

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

(14) ага, а в 11 прямо красота... Не проводится документ который был уже проведен - вот где минное поле.

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

(15) менеджеры боятся кнопки жать))

(17) я всякий раз прихожу в ужас, работая с ут 11

Т.е. я так понимаю, никто не заморачивается, и все хреначат код, изредка поглядывая в сторону проектирования?

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

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

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

(19) Фикси в основном, да. Если ты франч ваяющий нетленку,  что-то пользуют. Ибо более-менее серьезную конфу на коленке не сделать.

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

(23) я с этим не на 100% согласен
все великие вещи делаются одним человеком

гамно делается командой из людей с активной жизненной позицией

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

И у меня возникает множество вопросов, например:
Как определить, спроектировал ли я приложение?
Как доказать заказчику, что приложение спроектировано?
Как добавлять новый функционал, не переписывая 30% написанного кода?
Как сделать приложение удобным для пользователя?
Какую подобрать тикетницу?
Использовать ли системы контроля версий? Какие? Почему?
Отдельный вопрос в тестировании, функциональном и нагрузочном. Как писать такие тесты, каким требованиям они должны отвечать?

и подобные.

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

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

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

(27) Перфекционизмом тоже не стоит увлекаться. Всего сразу не достичь. Но можно постепенно совершенствоваться от релиза к релизу.

(27)
И у меня возникает множество вопросов, например:
>>Как определить, спроектировал ли я приложение?
Приложение должно уметь отражать все бизнес-процессы компании без ошибок

>>Как доказать заказчику, что приложение спроектировано?
Приложение должно уметь отражать все бизнес-процессы компании без ошибок

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

>>Как сделать приложение удобным для пользователя?
У пользователя есть задача. Тебе надо формализовать задачу максимально чётко и сделать максимально чёткую вьюшку.
Например, подбор товара. Таблица товаров, остатков, резервов, цен. Соединяешь их, получаешь вьюшку подбора товаров.

>>Какую подобрать тикетницу?
Не путай приложение с тикетницой

>>Использовать ли системы контроля версий? Какие? Почему?
Храние бэкапы, пиши лог истории, зачем хранить версии гамна?
Каждая новая версия должна быть круче, могуче, сексуальней

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

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

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

а ты не знаешь Елену Кудрявцеву с Кемерово. раньше на радио работала

(31) >А нахрен тесты. Правильно блокируй таблицы и всё
Ай малаца!

(33) >главное это структура таблиц и запись в таблицы
А это правильно. Но еще главнее бизнес требования.

(32) +1
(31)(33) спасибо, подумаю над этим.
(34) нет, не слышал про такую.

Пойду посплю. С утреца еще раз переварю информацию.

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

(37) Скорее в неправильном месте :)

wiki:SOLID_(объектно-ориентированное_программирование)

v8: SOLID в 1С

Скачал книжку "Управление проектами по созданию программного обеспечения" У.Ройса, думаю, будет полезна.

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