Introduction
The domain of software development is so huge that there are numerous books, best practices, process etc are available for the developers to follow and adhere too. Some suits them well and in few instances it does not cater to their needs. But in general, most of the software development caters to a scenario where a "software" is written for external "End users" and it is expected to run flawlessly and seamlessly for months if not years (untill the next update/patch).
There is one scenario of software development which is often neglected and my aim is to discuss that aspect and share my experience. I am talking about writing the software written for hardware engineers to test their design or to validate its reliability in a engineering company. The hardware can be anything from a subsystem of PCBA's to single individual sensors. These softwares are for internal use which is never given outside to so called "End users".
The main characteristic of such software and its developement are
- Internal audience (especially Engineers)
- Shorter turnaround time
- One time use/ low shelf life
- Data files triumphs appearance
- Automation for minimal human interference during long hours of testing
In a typical case you are required to prepare a small but reliable software test this hardware with minimal human monitoring or interference. There would be no proper SRS document to start working on implementation. This software would be required to test a part of hardware in the overall Engineering hardware development.. As a developer you are expected to complete the software by donning various hats from requirement gathering to final executable. This would take longer development cycle but time is not a luxury in such environment. And in the end that software will be discarded after its intented one time use.
Background
One of the driving force for writing this article was, the hardship I faced during my transition from proper SDLC to a "quick-fire" development cycle and wanted to chronicle the step I took to overcome it. This may be helpful to people who are working on similar environment.
I have been working for 10 years writing desktop application for Telecom and banking industry. There we had to follow the complete SDLC process and had all the support from the other department with required documents and instruction. So when I moved to Reliability Engineering, one of my task was to write the software to test the electronics boards under various environment conditions. Well I thought it should be a cakewalk since I have been in development business for a decade. Surprisingly It was journey full of roadblocks and potholes. It took me nearly half a year to realize the mistakes and the unnecessary baggage I was carrying from my past work experience. I had to fine tune my working methods and wanted to share this to a bigger audience.
What went wrong?
So after moving to the new job and learning the ropes of new technology, I was ready to jump in into the project. So one fine day I get a meeting invite for a project kickoff. I enter the room with confidence and sit through it.
H/W Engineer : Super, Our board is ready with new pressure and temperature sensor. We need to test its reliability and design issue over a month at various temperature. I would like to see the trend of the sensor reading over period of time
Me : No problem. Can I have the requirement document for the software.
H/W Engineer : Why? I ll explain what the boards does and steps do the functional test.
Me : Hmm....Ok. How should the GUI look like?
H/W Engineer : Its upto you. Just make sure that there is no loss of data and send me the data in csv file so that I can use matlab to analyse it. And make sure the software so that test can be started in a week.
After the meeting, I literally had a panic attack. There is no SRS document, no GUI layout and I need to finish the software in 5 days, But anyway I started like a classical Software developer. I spend some time preparing a complete SRS document and the GUI layout. I was happy with the screen design ans SRS. It was thoroug and complete but took 3 days. Next day I got another invite from another Engineer from same project, to prepare the software for his board so that it can be tested and finally combine with earlier board for a complete system test. It was a same secenario with no proper SRS and guideline.
To cut the story short, I missed the deadline by miles but the software came out very good. But Project team was not happy as their time to market got delayed due to the bottleneck from my side. They commented that the software was good but did not serve the purpose.
After discussing with various people and other developers I got an idea where I went wrong. Few of them in no particular order were
- Failure to recognize the audience for the software
- Misconception about the intend of the software
- Misguided focus on the wrong priority
- Depending on the classical "Waterfall" SDLC.
So I had to tweak my development style to suit this environment for future project.
"New" approach
If I had a time machine, then I would have done this project in a different way from my lessons learnt. As with all software development, if the initial approach is wrong, there is a high possibility that it would end up in delays. So one of my main change was not to focus on the GUI. Below are few of the changes I incorporated.
Prioritization of Requirements
I decided to create a color coded requirement document. For any software to be useful It should always satisy the basic Red coded requirements and at most the Orange color code automation . Remaining requirements can be implemented if there is time to implement.
So what is this color coding system? I use the below diagram as my reference
I make sure that all the requirement fall into specific colour schemes and make sure that there is some kind of understanding from the Project team especially the Engineer.
Core functionality is generally derived from the hardware to be tested and I make sure I always add two other attributes as this is always expected in a engineering project
- Redundancy for data write operation in files.
- No I/O error when file is opened by other users.
The idea behind is that people expect to see the intermediate data when the test is running and most probably keep the files open which results in the write error.
So more or less my requirement sheet looks like this
Agree this is no different approach with normal SDLC with respect to SRS. But the focus here is to make sure you have identified the "basic minimum" requirements which needs to implemented at any cost. A simple document gives a clear idea and requires minimal effort for such software.
"KISS" principle for GUI.
In general, one time software has a very short shelf file. In many instances the software is discarded after one time use. Engineers don't care too much about the GUI data appearance but rather prefer data in some form of file. So It makes no sense to spend days on creating a perfect GUI if there is no use for them. So for the above example you can come with two GUI's.
Basic GUI
Advanced GUI
Above example is just to show the difference in approach. Basic GUI will more than suffice for such software. Most probably this software would be running in lab with nobody looking into screen every few minutes.
As mentioned before , most of the engineers look for data trends over a period of time and other stress factor affecting their hardware . It makes sense to have your GUI as simple/minimal as possible and build it on top of it. More effort and time should be involved in getting the data in file in correct format. Basic GUI is part of the core requirement and everything else can be part of the "ease of use" and "Bells and whistle" section. Engineering team are more concerned with the content of the book rather than the cover of it.
Design and implementation.
There is a famous saying that
Quote:
A chain is no stronger than its weakest link
In a complex Engineering project, our minute albeit important task should not be slowest link. So it is very important to provide reliable software in shortest turnaround time. We do not have a luxury for a long rework effort. So we have to start in a right manner. As we are going to work on requirement in layers, each colour coded module has to be modular and scalable. Therefore they should be loosely coupled but tightly cohesive.
So if push to shove, "Core Functionality" module should be able to work as an independent software. So for project team software should be considered more than completed if "Automation" is also implemented.
In other words, your software should be relaible and complete when the "core functionality"module is implemented and available in executable.
No compromise.
This may look like that the article supports the idea to discard the time tested SDLC and follow the "on the fly" programming. This is not entirely true. All process aim to bring a quality software to the end users. But in some scenario where time is the essence, the "Quality" is more synomous with "useful and timely". This does not mean, we throw Quality out of the window. The following operation attributes of software still hold true and should not be comprimsed.
- Intergrity
- Stabilty
- Reliabity
- Correctness
With minimal requirments in scope, the chance for failure and bugs tend to be low. There is no point in increasing the chances for bugs with adding features which is not important for the harware development.
Minimal development time is the essence here.
A word of advice
This article does not advocate abandoning the typical SDLC nor it says software needs to be "quick and dirty". Only thing this article states is to approach the software development in the right manner based on the target audiences and its intent.
Whatever industry we work on, we need to have a deep understanding on the technology/languages used. There is no short cut for knowledge acquired. If we do not have a proper understanding on basic architectures and pitfalls of bad programming, software development will always be a nightmare.
