Chris, Great start on the goals document. Beyond the currently ongoing bug-fixing and addition of minor features, you're basically saying, "let's make something entirely new." There's an existing code base, but once you make the decision to scrap it and re-implement the entire thing, the primary purpose of the existing code base becomes: * Provide a list of features that are to be implemented (the new code should provide the same features as the existing code), and * Serve as an initial validation test document (the new code should provide the user with the same abilities). Of course, the above isn't entirely true: the existing code does a couple of things wrong, and should do a couple of things more. However, these modifications might be viewed as a separate task compared with the task of re-implementing the code. So, I propose that now you've decided to re-architect and re-implement LedgerSMB, there are a few tasks that should be performed first in order to guarantee a successful re-implementation: 1. Identify and list all of the requirements for the new software. Obviously, most of the requirements can be gleaned from the current code, so this is (at least compared with requirements development in general) a reasonably trivial task. It may make sense to develop the features into technical requirements. (By "developing requirements" I mean turning statements such as "a heavy door" into technical specifications such as size and weight.) It might make sense to divide the features into "current" and "future" features. 2. Describe the architecture; more specifically, identify which major components the software should be split into. Also, make sure to identify major algorithms and major data structures. Agree on an interface strategy. Agree on a code strategy. (Your goals document already makes some initial thoughts.) When there are multiple solutions, make sure to list all of those that make sense and explain why you deselecte those options. 3. Allocate requirements to the components: for each requirement, determine which component is responsible for providing this particular requirement. This is basically where you start requirements traceability: for each requirement, it must be possible to show that the architecture will cause this requirement to eventually be implemented. It may sound like a difficult task, but a spreadsheet is really all it takes as long as you have version info in your requirements and architecture documents. Next comes detailed component designs, but let's wait with that. :) As an example of deselecting options, your vision statement states that you'll put lots of functionality into the database. It might be worthwhile explaining why this is such a good idea that it justifies the difficulties that will arise if LedgerSMB is to be used on servers running, say, MySQL, Oracle, or Microsoft SQL Server instead of PostGreSQL. Another example would be the choice of programming language. Perl is powerful, but it's also very code monkey friendly (meaning any idiot can code in Perl, and many do). Choosing the same programming language as the poorly coded base application might tempt implementers to copy and past bad code sections, not realizing that the sections should be rewritten. It might be a good idea to summarize why you selected Perl for this particular application. You mention that Java and Python have been discussed, so it might be a good idea to summarize this discussion in the architecture document. My two cents (debit LedgerSMB, credit time). --Ole > Hi all; > > This is an attempt to summarize for the record our current architectural > approach. If there are no concerns, comments, are clarifications needed, I > would like to put it on our web site. >
Attachment:
pgpotEPMVAsWP.pgp
Description: PGP signature