Прежде всего, поздравляю с разработкой проекта. Надеюсь, вы найдете это полезным. Я также рекомендую вам зарегистрироваться в Stackoverflow, чтобы вы могли дать себе осмысленное имя (или, по крайней мере, что-то более значимое, чем user339481) и легко отслеживать ваши вопросы и ответы. Я уверен, что у вас будет больше по ходу процесса.
Чтобы ответить на ваш вопрос, методология разработки программного обеспечения - это ОЧЕНЬ, ОЧЕНЬ обширная тема, поэтому дать вам исчерпывающий взгляд на все это было бы практически невозможно. Я бы посоветовал вам взглянуть на такие вещи, как Agile и Waterfall и SDLC (жизненный цикл разработки программного обеспечения) для общей картины.
Короче говоря, водопад работает лучше, когда вы имеете дело с четко определенными статическими требованиями, которые точно соответствуют желанию конечного пользователя. Agile (и другие итеративные, динамические методы) работают лучше, когда вы имеете дело с реальностью.
Выполняя работу
В качестве обзора очень высокого уровня рассмотрим следующие моменты:
- Соберите все требования, которые вы можете сначала .
Требования могут и делать изменяться во время разработки (особенно для внутренних бизнес-приложений, в несколько меньшей степени для продуктов с термоусадочной пленкой), но вы хотите максимально уменьшить это. Старайтесь не позволять вашим источникам определять, как приложение на самом деле будет выглядеть (они определенно захотят это сделать, так что будьте осторожны), если только конкретный взгляд на самом деле не повлияет на удобство использования. Это почти универсально , а не . Существует «лучший дизайн», и очень вероятно, что пользователь понятия не имеет, что это такое. Соберите информацию о том, что должна делать система и как должны выглядеть ее результаты. К счастью для вас, у вас, вероятно, уже много этой информации, поскольку у вас уже есть продукт.
- Сделайте свой общий дизайн до того, как начнете кодировать, но не становитесь жертвой паралича анализа или чрезмерного проектирования.
Это так же заманчиво переусердствовать в решении проблемы, как и прыгнуть с пистолета и начать кодирование без четко определенного направления или цели. Сохраняйте вещи максимально простыми, не мешая себе, когда дело доходит до будущего расширения. Если то, что ты пишешь, хорошо, ты захочешь сделать это лучше в будущем! Я говорю это без посторонней помощи, но эти две вещи являются двумя наиболее трудными для разработки программного обеспечения. Изящество спасения в том, что их легко сделать приемлемо ну, просто сложно их очень хорошо. Используйте свое суждение и не бойтесь отступать и задыхаться, если кажется, что вы движетесь в неправильном направлении.
- Протестируйте свое программное обеспечение самостоятельно, но протестируйте его люди, которые знают, что они делают
Вам необходимо тщательно протестировать свое программное обеспечение, но даже если вы являетесь экспертом в данной области (другими словами, это было то, что вы написали, чтобы облегчить вашу работу), вам нужно больше чем ваши собственные глаза, смотрящие на это и проверяющие это. Позвольте людям, которым вы доверяете, выполнять работу, которая предназначена для того, чтобы помочь вам использовать ваше программное обеспечение, и дать вам обратную связь
Планирование работы
Звучит так, как будто вы хотите создать UML-диаграмму о том, как написать программное обеспечение , и я бы не рекомендовал это делать. Это не поможет, и вы потратите на это гораздо больше времени, чем на программное обеспечение.
Что может быть полезным, однако, UML-диаграмма , как программное обеспечение должно работать . Хотя это в значительной степени зависит от типа приложения, которое вы пишете (оно очень хорошо подходит для автоматизированных систем обработки, где все действительно состоит из последовательности шагов, выполняемых в цикле, хотя это не так полезно для приложений с интенсивным пользовательским интерфейсом) , но даже если это бесполезно для отображения системы целом , это может быть полезно для отображения ее частей. Если вы решили использовать UML для описания какой-либо части вашего приложения, , вы должны поддерживать его актуальность и точность . Диаграмма будет бесполезной (на самом деле, она, скорее всего, будет помехой), если она не отражает того, что должно произойти. Если вы сделали свою работу правильно, она также должна отражать то, что на самом деле происходит !
В заключение ...
Я не уверен, насколько я вам здесь помог, но, надеюсь, это даст вам по крайней мере некоторую полезную информацию. Если у вас есть более конкретные вопросы, воспользуйтесь огромным объемом знаний, которые мы имеем здесь, на SO: найдите ваш вопрос, а затем опубликуйте его, если еще никто не думал его задать. Здесь много знающих людей, включая людей, которые работают в команде Microsoft C #, и других, которые пишут книги об этом для жизни. Вы не найдете недостатка в ответах практически на все, что сможете придумать.
Удачи!