This is an old revision of the document!
'''Page still under construction''' The development process for a gramar doesn't really involve Gramar until the very end. === Build a Representative Example === There's no magic in Gramar. You have to decide how your software architecture is going to work. That's what Software Architects do. The best way to not only decide on a particular repeatable architecture but to prove it out is to actually write a minimal number of reference implementations that together cover the variations you expect to see over time. This is a key feature in Agile, Iterative and RUP methods: proof of concept using a representative end-to-end implementation thread. It's very important at this stage that the code not be the kind of "Hello, World" examples you see in magazine articles and product development guides. You need to write code the way you expect to deploy it to production. This means you also write your build definitions in Maven, Ant or make and you implement all of your non-functional requirements, too: unit test, logging, input validation, performance concerns, proper naming conventions, etc. In short, you write not just the code but all of the other development artifacts and you write them exactly how you want your developers to write them. === Normalize the Development Artifacts === Consider the pieces in the game of Chess. There are 16 pieces for each side, but there are only six kinds of pieces (King, Queen, Rook, Bishop, Knight and Pawn). You've got one King, two Rooks and eight pawns.
