Software Development Life Cycle (SDLC) – Implementation


At the Implementation phase we do execution of the blue print Technical Specification (TS) prepared in design phase. Which means care fully developing each and every component of the product as per the given specification. These developments get performed by different developers or engineer depending on the project size. To continue our previous metaphor below are the exact steps which we perform in this phase –

  • We create rechargeable energy cell and assemble it in a way that it takes minimum space and maximum energy.
  • We build the adaptor to convert ac to dc to charge the battery with exact power required.
  • We start building the overall products shape of circle and build other component in such a way that after complete assembly it gets into round shape.
  • We procure heat sustainable light weight glass and cut it in round shape.
  • We prepare the over all circuit with the capacitor timer, AC to DC adopter and battery so that it provides constant heat for given time and power.

After building each of above component we test each individually and make sure it passes the test and if not we fix it. This is called Unit Testing of individual components. Once we are done with unit testing we assemble the component to give it final shape and test the overall working of it. This is called Integration Testing (I&T).


Once integration testing is finished this phase completes and we ship the product for next phase which consist different regress testing steps.

Since you are with us so far we are sure it started making sense, if so please share your feedback with us in comments section or even you think otherwise. We would be covering the testing phase of SDLC in followup post, stay tuned.


Software Development Life Cycle (SDLC) – Design

This is the followup post for previous post about SDLC where we discussed about the Requirement Analysis Phase, you might want to visit before continuing, and if so please visit Requirement Analysis.


In this phase we do systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation. Not simple enough ? Let us continue with the previous example from Requirement Gathering & Analysis phase.

So now by statement of work we know requirement is to design and develop a smokeless light weight stove with automatic timer and consistent heat generator. To suffices the requirement we decide

  • We evaluate different source of energy like
    • Can we build it with electric battery, we think it won’t be a good idea battery will run out eventually and wouldn’t be good for long run.
    • Can we build it with electricity, we think that it wouldn’t be portable enough if we go with this option and what if there is no electricity or at power cut.
    • We decide to use both rechargeable battery which can be charged by electricity would be a good idea.
  • We also look for form factor whether it is going to be square or circle.
    • Square would require more material and unnecessary material would add cost, weight and logistic effort to final product.
  • Material for cook top
    • We evaluate stable & heat sustaining cooktop for surface. We evaluate glass, stone and fibre for same purpose and find glass as our best bet due to high melting point lighter in weight then stone.
  • Electric components & circuits
    • We also identify the electric and electronic component required for our product like ac to dc adaptor to charge battery for stove.
    • We need capacitors and resisters to provide consistent energy for heat.
    • We need timer to keep track of the heating time.

In Above exercise we design the complete, to be architecture and technologies we are going to use. Which summaries the design phase. The takeaway of this phase is a technical blue print of whole to be product called Technical Specification (TS). The TS would be passed to development team, who will execute it and come up with the final product.

Are you with us this far? Does it sounds interesting? Please share your feedback with us in comments section. We would be covering the design phase of SDLC in followup post, stay tuned.


Software Development Life Cycle (SDLC) – Requierment Gathering

Can you articulate Software Design Life Cycle (SDLC) to your child?



The answer to above question is yes if you have a metaphor, simple enough and easy to understand I often get asked what is Software Design Life Cycle (SDLC) and what exactly we do in this complete cycle? To explain in plain simple words I share an interesting metaphor and here it is

The very first phase is requirement gathering and analysis. This phase helps in evaluating the customer on his understanding of the process and requirement to come up with the agreed Statement Of Work (SOW). This is the first contract document between customer and service provider. We also educate the customer to clearly outline their requirement in this phase, for example customer comes with the requirement of a stove because they are sick of the conventional clay stove.

Clay Stove
Conventional Clay Stove

At this point we ask what they want or what were their pain points with previous experience and we list it down

  • It shouldn’t produce smoke, because the traditional one was a pain in  the eyes due to smoke.
  • It shouldn’t need to be watched continuously, so that the person cooking can also do something else while cooking.
  • It should’t over cook or under cook the food should be smart enough to know once food is cooked.
  • It should be portable and easy to clean for obvious reasons.
  • Should be energy efficient.

Provided the above facts we underline the requirement as below

  • It shouldn’t burn the fuel that is the only way to completely eliminate smoke. We need alternative source of smoke less energy.
  • It will need a time counter or timer and an interface to capture the time.
  • Needs a temperature regulator and should be able to provide consistent temperature.
  • Should be made of lightweight heat resistant material.
  • Should consume energy wisely.

Customer need to be educated that it would require consistent source of un-conventional energy such as electricity instead of wood and charcoal. Once agreed and SOW is signed deal is sealed.

What is your metaphor of SDLC let us know in comments, We would be covering the other phases of SDLC in subsequent follow ups of this post stay tuned and share your understanding of it did we succeed to simplify it for your children or we confused you more share your thoughts in comments below.


Emotion Driven Architecture ( EDA )

Even the machines can work on algorithm and structured control flow, It takes wisdom to follow the heart and get driven by emotions”



Would you be surprised? If we tell you “Emotion Driven Architecture (EDA) is new Paradigm shift in Software development approach”. Did we not talk about making paradigm shift if required in our manifesto, this is part of the plan we are up to. In case you wonder why we care so much about EDA, because Great User Experience design’s are mostly build around User’s emotions.

When we say Emotion Driven Architecture we are essentially talking about a frame work which helps to develop product, and user should be able to emotionally associate with it. The rest of the user experience should be designed with keeping this relation in mind. However wizardry it might sound, trust us, it is not rocket science and is completely doable, we are planning to implement Appraisal Theory with right set of cut and mix, here is what we have in mind to implement as first phase of it –

  • User’s experience study for particular use case should be done properly. continuous evaluation and enhancement for future scope should be planned, if any user experience survey for use case available in any inorganic way should be utilised and enhanced or extended, if required to save effort and time.
  • Should have an algorithm which should dynamically choose the flow path, when provided the user experience pattern discussed in above step.
  • Have checkpoint if the flow is proceeding into right path and nothing has been missed, any deviation should be logged tracked and corrective measure should be taken.
    Repeat from step 1.

So this is the initial draft of design idea we have for Emotion Driven Architecture, tell us what you think about it in the comments below and stay tuned for future updates and contact us if you want to be part of the development.



Wise and otherwise way of getting better ratings for apps

Better app ratings can do miracle for your apps, here are few things to consider before launching apps, for better ratings.

Why app rating are important –

  • Number of ratings makes your application more discoverable in app store or play store.
  • Positive rating puts your app at higher position in ranking Page/List in other words gives the app better PR.
  • Improves trustability of your app and makes user more confident to try install and use your app.

Provided the above fact it is important to ask for user’s feedback, rating and ranking. There are basically two approaches to ask user for it, however both have there advantages and disadvantages. where using each approach effectively gives you above mentioned profits, improper use of it may bring your application to doom.

  1. Ask user for feedback with consistent reminder. This approach works well when its free app, user’s usually don’t mind getting annoyed a bit for providing feedback, however don’t beg for it, Ask your self these questions before deciding to go for this approach.
  • Is it a free app?
  • How likely user will provide feedback ?
  • Are you interrupting users experience in any way ? If yes can it be continued after getting feedback?
  • Is the language you use to ask for rating or feedback offensive in any way?
  • Is the experience worth providing feed back?
  • Are you getting any useful information or user’s behaviour out of the provided feedback?

If any of the answer of above mentioned questions are negative you shouldn’t go for this approach or at least make that answer positive before choosing this approach.

  1. Create a page or view where users can share there experience with the app. Most of the user’s mind are already conditioned for not to be annoyed if they paid for application. Below mentioned approach fits mostly for this purpose. Same as before ask these question to yourself –
  • Is it a paid app?
  • Is it interactive easy to use feedback form?
  • Is there any freebie if user provide feedback or ranking?
  • Is the provided feedback worth?

If any of the answer is no, you should think again about going for this approach.  If you can think of better way to handle user’s reaction about the apps share with us as comment to this post. We are going to write the how to guide as follow-up for this post. Till than stay tuned.