Собственно сабж.

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

Каков на Ваш взгляд, наиболее эффективный полный алгоритм разработки ПО малого масштаба?

Не знаю, так ли я тебя понял, но для моих "програмулин" вот таков алгоритм разработки:
1. Представление в общих чертах.
2. Разбивка на модули.
3. Реализация модулей.
4. Дебаженье каждого модуля по-отдельности с приминением "заглушек" и рандомных параметров.
5. Дебаженье вместе всех модулей по определенно составленной легенде.
6. Отладка GUI.
7. Выпуск альфа-версии и тестирование своими усилиями.
8. Бета релиз и первые "подопытные кролики" - обычно друзья.
9. Исправление багов и выпуск релиза, который выкладываю на всеобщее обозрение.
10. Дальнейшая работа с исходниками, добавление новых опций и исправление багов. Выпуск новых релизов.

Цитата(En_t_end @ 11.8.2005, 20:58)

1. Представление в общих чертах. 2. Разбивка на модули. 3. Реализация модулей. 4. Дебаженье каждого модуля по-отдельности с приминением "заглушек" и рандомных параметров. 5. Дебаженье вместе всех модулей по определенно составленной легенде. 6. Отладка GUI. 7. Выпуск альфа-версии и тестирование своими усилиями. 8. Бета релиз и первые "подопытные кролики" smile - обычно друзья. 9. Исправление багов и выпуск релиза, который выкладываю на всеобщее обозрение. 10. Дальнейшая работа с исходниками, добавление новых опций и исправление багов. Выпуск новых релизов.

Ты совсем забыл от объектно-ориентированном подходе...

Добавлено @ 18:23
Это между прочим очень важный вопрос. Так как многие программисты до конца не дописывают своих программ и бросают их на полпути, только по тому, что изначально неправильно подошли к решению этой проблемы. Или просто вообще не обратили на нее внимание.

Цитата(Pegas @ 11.8.2005, 21:17)

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

Вот, хорошая статья по этому поводу http://russian.joelonsoftware.com/Articles...eSchedules.html

Цитата(Pegas @ 11.8.2005, 22:30)

Вот, хорошая статья по этому поводу http://russian.joelonsoftware.com/Articles...eSchedules.html

Занятно. Отвод часов, а не дней и отслеживание нач-тек оценок выглядят стоящими вещами.
ЗЫ. Только картинки там не к месту. Но хоть текст разрежают - это славно

Цитата

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

Точно. Узнаю себя... Сейчас стараюсь брать себя за я**а и дописывать.

Еще мне кажется, диаграмма классов не помешает даже в малых проектах...

Из статьи:

Цитата

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

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

Это сообщение отредактировал(а) comcon1 - 12.8.2005, 09:03

А не проще ли пользоваться комментариями TODO? Многие IDE поддерживают эту возможность.

Я пользуюсь UML в любом случае. Ну такой вот я человек, больше мыслю образами... и графически.
Даже в самом захудалом проекте найдуться классы, а классы должны между собой пересекаться, и даже для 15-20 классов лучше написать как они будут пересекаться и какие классы вообще будут там.
Кроме того у меня плохая память, и я предпочитаю записывать всё что должна делать программа, либо на бумажку либо в notepad.exe.

Функциональность программы обычно держу в голове. Во время реализации обычно приходит много идей, в том числе когда я далеко от компа. Записывать все подряд не удобно, да и не привык я так делать. Полная структура классов также в голове, хотя, я согласен, это нехорошо. Обычно сложные для понимания иерархии я разрисовываю на бумаге. Надо взять за привычку больше рисовать. UML не пользуюсь. Люблю больше писать руками, а не генерить код. Иерархия классов часто меняется, поэтому придется ее часто перерисовывать в диаграммах. Даже если хорошо все продумать перед кодированием. Довольно сложные фичи делаю не сразу, а попеременно с другими - так приходят новые мысли про оставленные и можно сэкономить на переделывании. По приближении к завершению кодирования тестю, профилирую и выпускаю.

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

Это сообщение отредактировал(а) ida - 28.10.2005, 08:48