Practical Software Development: From Idea to Delivery

Home / Management / Practical Software Development: From Idea to Delivery

To make a good Business Idea a successful reality, a good management plays its role.

My experience, over the past couple of years, suggests the following flow for delivering any software project (from top to bottom):

1. Gather Requirements

  1. a) Listen to the Client
  2. b) Break the requirements into Pieces / Modules

2. User Interface

  1. a) Make UX Sketches
  2. b) Validate sketches with the Client

3. Architecture

  1. a) Decide API Interfaces (based on UX)
  2. b) Create Database + Tables (based on your API)
  3. c) Code

4. Estimate Time

5. Test

  1. a) In-house testing
  2. b) Performance tuning

6. Deliver

  1. a) UAT

The most interesting part of this flow is the Coding, which is being mentioned almost at the end of the list. It’s because, the code has no worth until your client is fully satisfied with the UX (User Experience) of the App.

1. Gather Requirements

a) Listen to the Requirements

It would be best to let your development team involved in a 1st-hand discussion with the client.

Consider it to be Brainstorming session.

b) Break the requirements into Pieces / Modules

Breaking requirements further may help in properly identifying how the UX / UI will look like.

Group related pieces together and make modules out of them.

2. User Interface

a) Make UX Sketches

UX is an acronym for User eXperience.

Before letting the designer make any design mockups, it would be best to sketch the WireFrames first. WireFrames are best decided by having a cross-questioning within your team.

One of my favorite activity in the project life-cycle is to make UX sketches. I simply do it using color pencils with a sketchbook. Buy a one for you too. Enjoy!

Mockplus is also a great tool if you don’t want to use paper & pencil.

Apart from sketching, following is a great app to learn some of the most trending UX concepts in the market:

http://uxcompanion.com/

b). Validate Sketches with the Client

3. Architecture

a). Decide API Interfaces (based on UX)

Next, by evaluating the UX flow, decide the API Interface. Do your Paperwork.

b). Create Database + Tables (based on your API)

After the UX and API Interfaces are finalized, do the Database and Coding.

A good reference for making ER-Diagrams is as follows:

https://www.tutorialspoint.com/dbms/er_diagram_representation.htm

c). Code

Writing more lines-of-code doesn’t necessarily make one a good programmer.

Effectiveness of a programmer is usually judged by “write less, do more” principle.

Make sure your application code follows some standards. It will help in making team communication and code maintenance easy.

Try to use some good Frameworks available.

4. Estimate Time

Setting Deadlines without Consultation; A Catastrophe

At this point, we have much information about what client needs us to develop. So, it is good to estimate the time required to deliver this project now.

This is usually a mid-point in the Project Life-Cycle. Above this point, we have much client communication; below it, less client communication.

Although, to ensure we are moving in the right direction, we must still show the work-in-progress versions of our ongoing work to the client.

5. Test

a) In-house testing
b) Performance tuning

6. Deliver

a). UAT

UAT is an acronym for User Acceptance Testing.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *