In both iteration and waterfall, you need to build on a software architecture, designed and finalized by the development head.
how can i make a good software architecture for may game?
Since it is going to be a very simple and humble beginning, look at making charts for the game coding modules. Sometimes people start with a so called "spider chart" or "wheel chart" which has a hub in the middle and legs or spokes in all directions.
Wheel or Spider Chart
A game dev with fairly simple beginning like you have here should put the main menu and background interfaces connected to it which only the game dev team will be using and seeing in the middle of the chart. At first this can be done with a pen or pencil and a sheet of paper. Put the Main Menu in a box in the middle of the chart. Next place interfaces which only the team will use (invisible or non-existent in the end-user game) around the main menu: Import/Export (mainly art assets), configuration, compiler/decompiler, debugger, and so forth. On the outside perimeter of the chart, put the basic game coding structure: dlls (or jar files in the case of Java), each class file (for example, good guys, bad guys, AI, vehicles, map / level, objects, powers, weapons, etc.), main menu [coding] module, physics, executable file, etc. Just put a label in each box with no description in this chart. This chart will be revised several times as you learn more!
Class Files DLLs or Jar Files
Main Menu ....(Hub or Body of the Wheel or Spider Chart)
Executable File Configuration File
The flowcharts are made next to list the coding libraries and the coding issues involved in each particular FLOW of functions. You can see from the end-user perspective that the flow is from center main menu to the coding modules and returns with each response. Also there will be flowcharts made to connect the modules in the third stage of software architectural planning. Forth stage is the actual design (in detail) of the specific tools used, coding libraries, and issues anticipated.
A) Software Architecture Stage
1) Spider or Wheel Chart
2) Flowcharts (Legs) from hub to modules (Feet)
3) Flowcharts between modules
B) Design Stage
1) Select IDEs, SDKs, and game engine to be used
2) Choose coding libraries to be used ( "template" coding libraries like compilers, deguggers, graphic user interfaces, plug-ins, importers, physics library, and editors, etc. )
3) Decide on art assets to be used
4) Make a flowchart which lists all of these in concise labels
5) Draw art which shows visually each area of the game, such as characters, vehicles, level (map), Main Menu, Splash Screen, Score Board, etc. You may also make scene by scene design art for stages of gameplay. This may be as simple or professional as you feel is necessary. This is a good place to assess the art skill of your teammates and their enthusiasm for the project.
C) Development Stage
1) Chose roles and tasks of the team
2) Start with creating largest art asset or most important one in the game, often the "map" or "level" and the most important coding library for beginning, often the game engine setup. Early art assets can be all placeholders as your team learns to use the development system that you have assembled while at the same time working on the real art assets.
3) Team learns how to use the IDEs, SDKs, and/or game engine by the following sequence:
a) Import the level or map and the main user operated asset (could be the main character, vehicle, weapon, etc.)
b) Make the end-user operated entity moveable, create the input method to manipulate it, and make the Main Menu buttons to start, play, and end this simple game stage.
c) Add more art assets and functions by class files in the coding modules, vetting the game play and background functionality with flowcharts
d) Test each iteration with as many players as needed. Several people should test each iteration because often differences in people will discover any bugs or improvement to be made. Be thorough in testing and have fun with it!
Obviously, there will be times when steps will be skipped or swapped in order, but this will give you a basic outline.
Be sure to keep copies of all your charts in case you need to revisit an issue and also to promote the reality that your team is organized for investors, publishers, and future reference for new teammates.