Key design guidelines for software

development.

October 2014

Prepared by
Delhi Integrated Multi-Modal Transit System Limited
1st Floor, Maharana Pratap ISBT Building,
Kashmere Gate, Delhi 110 006
Tel: + 91 11 43090100, Direct: +91 11 43090207, Fax: +91 11 23860966

Table of Contents
Version Information ...................................................................................................................................... 3
Objective ....................................................................................................................................................... 3
Application .................................................................................................................................................... 3
Application architecture ........................................................................................................................... 3
Web ........................................................................................................................................................... 4
Desktop ..................................................................................................................................................... 4
Data Processing ......................................................................................................................................... 5
Databases ...................................................................................................................................................... 5
Network ........................................................................................................................................................ 6
Performance ................................................................................................................................................. 6
Operations .................................................................................................................................................... 6
References .................................................................................................................................................... 6

Version Information
S.No
1

Purpose/Change
Initial version

Author
Piyush Jain

Date
28th October, 2014

Objective
Objective of the document is to state the developer of any application to look at the below points and
cover them while developing a solution, so that the solution is robust in all aspects. The points below
may/may not be applicable in all context, but this is a high level guideline. He may decisively choose to
exclude any point (on a reasonable justification) with the consent of his peer/manager group.
Since this document does not cover technology specific coding specifications and best practices, it is
expected that the development team follows the standard guidelines prescribed by framework
developer group (ex apache, Microsoft, oracle etc)
This document is divided into various sections of a typical software system including operations.

Application
Application architecture
a) Use MVC framework.
b) Use an ORM framework for data access, else use binded queries for data access. In no case, use
inline queries.
c) Try to use RESTful framework for presentation layer.
d) For master data, try caching framework. This will get the master data loaded in the application
layer and reduce hits on database.
e) Do not perform high computation activities on web thread or on demand. Configure these as
jobs of which results can be seen later.
f) Code review Make sure your code is reviewed by a code buddy. This will ensure the best
outcome and reduce chances of errors in the same.
g) Check on resource intensive objects.
a. Check for object formation in the application using profiler when the application is in
load test mode. There should be minimum life of the object created in request scope.
b. Use database connection pool. You may also use startup process to form the
connections initially to save overhead of forming a connection later when request
comes.
c. Use string buffer/builder while manipulating strings, instead of string object.
d. Minimize the scope of variables in the class. Variables should be created in the method,
and destroyed when method use finishes.

e. Choose collection objects wisely. For example, arraylist may be a good choice, when we
need to store strings in sequence, instead of vector which can hold objects (in Java).
h) Code maintenance
a. Maintain a register of the code changes done in the module/class, stating the date,
Programmer, and WHY the change was done.
b. Always use source control software like TFS, SVN for maintaining code versions.
c. Lock the software version which is in production and any further change should be done
in new branch.
d. Before rolling out to production, do a manual check of the code differences and verify if
they are legal and intended changes.
i) Exception handling
a. Decide whether you want to catch or throw exception and bubble up for user
information.
b. Do not leave any exception without logging in the message. If you do so somewhere, it
may happen to break sometime later and you will not be able to trace it.
c. Do not make deep hierarchy in exception classes design. It adds to complication and
reduces performance.
d. Exception if interrupts business, should show proper message on user interface and not
programming code or syntactical error message.

Web
a) Aim to use a framework that uses MVC pattern for development. This will help you keep
business logic and presentation layer separate. Follow the rules of MVC to design classes.
b) Use appropriate javascript validations on the frontend. Make sure these validations are
confirmed at backend, before processing the request.
c) Use a Javascript framework like JQuery, MooTools, Dojo for enhanced and feature rich UI.
d) Use CSS 3.
e) Keep minimal javascript processing on the page, else the page will become unresponsive.
f) Security
a. Check access levels granted on URLs. Open URL should be validated for access check.
b. Session validation must be present on the application.
c. Session must be invalidated (killed) on timeout or logoff.
d. On backend, the access levels to data should be checked again.
e. If payment is involved in the application, it must be through SSL communication, ie
implement SSL certificate for HTTPS communication.
f. Keep strong passwords and expire them at an interval.
g. Log the pages that are accessed by the users. Monitor them at an interval to identify any
malicious intent.
h. Check all default parameters of the server settings and those can impact
security/performance.

Desktop
a) Try to keep minimum or no business logic processing in the desktop application client end.

b) Do not create database connection from desktop application to the database. Instead use
web services connectivity or socket connectivity.
c) When the application starts, check the version which the backend supports for the same. In
case there is version mismatch, force the user to upgrade the same.
d) During development, check for memory usage on client side and reduce it to minimal using
good coding practices.
e) Compress the data transmission from either side. This will help your application reduce
network latency.
f) Keep a log of activities on the client machine too. It may be helpful recreating an issue if
reported.
g) If possible maintain a small database on the client end, for him to be able to see some data
incase he is offline.

Data Processing
a)
b)
c)
d)
e)

Try to keep separate repository for processing reports.

Run data processing activities at lean time like night when traffic is the least.
Do the clean up of temporary tables. logs etc, after the processing is done.
Keep error and transaction log separate.
In the start monitor the processing activity for CPU usage, time taken. Try to optimize it.
Keep tuning it at regular intervals.
f) In case the processing takes more time/cpu or fails, send out an alert by email/sms to all
stakeholders.
g) If possible, keep a backup of database before processing and after processing.
h) Keep enough checks and balances that ensure the wrong data is not processed.

Databases
a) Identify and Keep audit fields in the tables for created (on/by), modified (on/by) or any
other relevant details.
b) Keep an eye on other aspects while designing the DB, like partitioning, indexing, archiving,
clustering etc.
c) Initially the performance may be good as DB size and transaction volume is low but with
time, it need to be monitored on indexes, performance and other tuning parameters.
d) Login from application must have least privilege principles.
e) Database should not have external IP. IPs accessing the DB should be marked.
f) Do not fire bulk updates as that can lock the tables and ongoing processes.
g) Try to keep queries simple.
h) Keep database access transactional in nature. Start and end the transaction in the program
and rollback/commit in case of failure/success.
i) Use parameterized queries.
j) In case of streaming data, keep a check on database, that in case data do not come since a
while (for example in 5/10 min) then an alert email should be fired.

k) Keep a stringent eyes on backup process. It should not fail. If it does, it has to be attended at
highest priority. Also perform restoration drill at periodic intervals to make sure things are
fine in case this has to be done at time of live DB crash/failure.

Network
a) Size the tentative network requirements for the application to run for public usage.
b) Check the number of hops required to reach our servers from the public space. This should
be minimum and work with infra team for the same.
c) Check from external source if the servers are reachable or not. Application may be working
but the servers may not be reachable. Alerts should be set for the same.

Performance
a) Keep all stake holder informed if there is a technical limitation on achieving a normal
performance, and what the best can be done.
b) Keep a record of performance with increase in hit/volume of data. You may need to tune
the application/database for improving the same.
c) Check network latency for performance bottlenecks. It may be that application/database
are working fine, but network bandwidth is limited and increasing to the latency.
d) Try to separate out the operation in terms of batch/online processing. Batch processes can
be moved out to different machine or given different time slot for not choking the CPU for
online requests.

Operations
a) Prepare a checklist of items to be scanned daily for health check by operations/production
support team.
b) Scan bulk data for capture outliner cases and detect business logic errors in initial stages.
c) Make sure all scheduled activities run on time. In case of failure of any of them, intimate the
stakeholders, find the RCA and correct it.
d) Regularly scan the application and database logs to identify unusual trends and initiate
corrective action.
e) Envisage on which business cases you would need reports to identify outliners or on- going
trends. This would help identify erratic behavior of an entity in the system.

References
Java coding guidelines and practices - http://www.oracle.com/technetwork/java/seccodeguide139067.html
.Net framework guidelines and Best Practices - http://msdn.microsoft.com/enus/library/ms184412(v=vs.110).aspx
http://bellouti.wordpress.com/2009/08/28/guidelines-for-consistent-exception-and-error-handling/

http://en.wikipedia.org/wiki/Exception_handling
http://www.javacodegeeks.com/2012/04/exception-handling-guidelines-best.html
http://www.sei.cmu.edu/news/article.cfm?assetid=77817&article=268&year=2013