After proof of concept, we could officially kick off with the product development. Creating a software product from scratch, especially when doing it single-handedly, isn’t an easy task. Every software developers has their own way of developing software. Some dive straight into the coding stage. Some prefer to go through formal software development cycles.
I have my own preferred way of developing software. I don’t like to dive straight into programming, but normally I would identify a few areas of concerns and perform a proof of concept first. After that, I would draft out a Requirements Specification document to write down formally the broad objective and the detailed functional requirements. This is important to me as sometimes software developer might lose sight of the initial objective and spent too much effort on the not so important feature during the development phase.
So our objective was to create a software for SMS Marketing and Reminder. And the target audience would primarily be the business owners. Thus, our software should be very easy to use and do not require much IT knowledge. The functionalities shall also serve the main objectives.
Therefore, I drafted down the main components of the system:
• Address Book – Manages customer database
• Scheduler – Manage scheduled SMS
• Template Editor – Manage user-defined message templates
• Transaction Manager – Manage incoming /outgoing SMS
• Automatic Response System – User defined rules to perform tasks upon incoming SMS
• External Interface Manager – Manages all external hardware/software interfaces. At this stage it would mainly deal with the interfacing of gsm modem. At a later client/server stage, the Inter-Process Communication (IPC) library would also fall under this component.
After that, I noted the detailed features under each of the components. For formal documentation, this would be the part where I draw the Use Case Model diagram and detailed the process of each use case. But this was too time consuming so I would rather skip the use case model and go straight to the design document.
For design document, I designed the class diagrams for each of the main components depicted above, as well as the database tables for the system. For formal documentation, this would be the part where I depict the static and dynamic relationships between the classes in terms of class diagrams, sequence diagrams, activity diagrams, etc.
Frankly speaking, I find the full UML model too time-consuming. For me, class diagrams with some text explanation are enough. Scalability and flexibility are the key principles to my design. Thus I normally spent a lot of time thinking and modifying my design, trying to anticipate all possible future expansions and how my system can be designed to easily accommodate them.
Above is the class diagram of one of the main components I designed back in 2004. It utilized some of the common design patterns like Singleton, Abstract Factory, Facade, etc.
The requirements specifications and design stage spanned from Sep 2004 to Nov 2004. It took a bit longer than I expected because I had been doing all these after office hours in order not to interrupt my daily job.
Then at mid Nov 2004, I started the coding stage. Will talk about that in my next post.