Return on Investment in Software Development

Hi I thought I would write a series of articles on a topic that I believe is becoming absolutely critical in the software development industry, that being the magical and mysterious ROI (return on investment) in software development.

As the owner of a programming company here in South Africa, I decided at the outset of the company that a rule of thumb for accepting any software development project would be that I would need to figure out how to measure the ROI in that particular project. Now you may or may not be surprised to know that in most instances my clients don’t actually think of this measure before taking on the project, they know that they have a business problem or business need that needs to be solved with technology and are willing to pay an amount of money for that. Experience over the years however has shown me that the best way to retain that client in the long term and or to make more business from that client is to prove a ROI in some way on that software development project.

I find this measure to be critical because for my companies purposes it shows exactly how successful a project is to my client in monetary terms. The bigger my impact through the software I develop, the more successful I have been at satisfying that clients need, the easier it is for me to go back to that client and offer further services. Contrary to popular belief, I don’t believe that a project coming in on time or under cost is a great measure of the success of that project at all, this is typically what IT companies do. If I really want to do a great job for my client then I always intentionally build a monitoring tool into the software I develop for them and that tool must track the ROI for the client in some way and present a report to the client whenever they want to see what this piece of software really is worth to them, be it through savings, additional income, time savings, it doesn’t matter so long as you track the value.
So how do you go about figuring out the ROI on software development project?

This is the difficult portion because it requires listening to the clients need carefully and scoping there need correctly, once you have done this, it should become fairly obvious what the client is trying to solve by having the software developed, this should then be a clear indication of the measure to be used on ROI. For example,a client of mine wished to have a system developed that automated the process of allowing shareholders in various properties to swap there owned weeks with each other. Before the client came to me they did this process manually, ie called there shareholders to find out if they were willing to exchange a week with a fellow shareholder that already gave an indication that they wanted to swap there week etc. This took a lot of time and for the administration fee that the client asked to do this, I suspect the profit was very little. Once we had developed the system and allowed the shareholders to interact with each other through the website instead of the web system, the ROI was very clear, why?

-We tracked each exchange in the system, each exchange has a monetary value associated to it.

-The clients telephone bill dropped significantly

-More swaps occur because of the ease at which shareholders can swap weeks, instead of having to go through a process of calling the company then waiting etc, this increase in sales is measurable

-Because the client offered the service electronically he could increase his administration fee.

All this information the client could get through there system thereby ensuring that he could very clearly see what his ROI was.
Conclusion

I believe without a doubt that if you truly want to complete a software development project successfully for a client, then you need to build a ROI tool into the software. Convince the client to do this, if you cant do that then build it free of charge, but make sure that you get your client to look at these figures. In the long term this will have a positive effect on your business and keeps your software development projects honest in terms of creativity and keeping the clients needs in mind constantly.

Please offer your comments and views on this topic, I am very sure that peoples opinions and views on this vary quite considerably, I am very willing to listen to other opinions in this regard.

In my next article on ROI and software, I will be describing more specifically how you can measure ROI on certain types of projects, in this case it will be how to measure ROI precisely in SMS campaigns.

Embedded Software Development: Testing Your Software

New designs, innovations, technologies and ideas are shaped every day. Testing is a part and parcel of every design that is created. Especially when it comes to software testing, implementation might go wrong if the software isn’t tested properly. It is very important to test the software as it gives an assurance to the business owners that the embedded software development has been carried out flawlessly by keeping the current trends in mind. Thus, most of the business owners like to get their software tested after the software development is over.

It is very common for the viruses and bugs to attack the system after the software development is done. This might lead to multiple problems like the privacy of the data getting hindered and the system getting hanged. Therefore, it becomes important to scan and debug the system so that the viruses are removed.
Majorly, there are three kinds of testing:

1. System testing: This involves testing of the system as a whole.

2. Unit testing: In this type of testing; the programmer checks every part of source code compared to its description. This testing is very crucial for the system as each part of it is thoroughly verified and tested.

3. Integration testing: The integration testing takes care of the fact that the internal systems interchange data without any problem and confirms whether the system is capable enough to work in-sync with other systems.

4. Other types: There are other types of testing including manual testing and automation testing. Manual testing is done to check the performance of the system and its working. It can be done by anyone working with the system.

Automation testing is done to verify the programming code. When huge data applications have to be tested, automation programming is the best option. These testers types can help the system to work faster and the applications run smoothly.

We are surrounded by many electronic instruments in our day to day lives including mobile phones, washing machines, microwave ovens, computers etc. Most of these devices have embedded software installed in them. Now; no one would like to solve software related problems every day. It rarely happens that the software in these devices goes wrong. This is because most of them are proficiently tested.

It is very significant that the person who tests the software is skilled, experienced and has a complete knowhow of how the software works. One should also check whether the person who is checking the software has been a part of the embedded software development for that particular system. This is because, if he has not created the software, he might not be aware about the loopholes in it. Testing is definitely not an easy job. Thus it is very important for one to find someone who is expert at it.

UML Diagrams As A Tool For A Software Development Team

As we progress into the 21st century, our reliance on computer and information systems to facilitate business is greater than ever before. The global market is much too convoluted and relentless to be run on manpower and note-taking alone; software systems are crucial to a company when handling large amounts of data processing, customer transactions, or client databases. As such, their development and maintenance has become a key component in successful company operations.

To structure, plan, and control the development of these systems, a software development life cycle (SDLC) is developed and adhered to. Different methodologies have evolved to be applied for different purposes, based on technical, organizational, project and team needs, but generally all will use some combination of the following stages:

• Problem analyzing
• Market research
• Requirements analysis
• Design
• Implementation (coding)
• Testing
• Deployment
• Maintenance and bug fixing

How strictly this order is followed, and what level of planning and documentation is reached, will depend on the requirements of the business and capabilities of the software. A ‘waterfall’ approach to the SDLC would see each of these stages carried out in linear order, with detailed planning and risk assessment before coding is even begun. The ‘agile’ approach involves a lot less planning and documentation, and focuses more on coding and continuous re-testing, ideal for a smaller system, or one where new components are being added as an ongoing process.

Modeling software development using UML diagrams

While going through each stage of the SLDC, it can be useful, and necessary, to produce a visual model of that process. A diagram of this kind presents a graphical view of a software system’s structure, components and relationships, which allows the designer to organize and predict certain outcomes, as well as share system information with collaborators and clients.

The accepted standard used when modeling a system is known as Unified Modeling Language (UML), a generic set of notations that are used when creating UML diagrams. These notations can visually represent requirements, subsystems, logical and physical elements, and structural and behavioral patterns, that are especially relevant to systems built using an object-oriented style.

Using UML during the modeling process has a number of benefits – for one, the entire development team can share information and collaborate using common language, diagrams and software, something that’s not possible when using a more task-specific programming language. It allows team members to create system ‘blueprints’, creating diagrams that show system as a unified whole, but also allowing the option to break that system down into component parts or processes.

Currently on version 2.5, UML supports 14 different diagram techniques that are seen as industry standard. These diagrams are broadly divided into two categories; first are static structure diagrams, that describe the physical structure of a system. Then there are behavior diagrams, that depict behaviors and interactions of various system components. Here is a brief description what each diagram is and how it can be applied:

Static structure diagrams

Class diagrams – divides objects into ‘classes’, i.e. parts that share common attributes. Class defines the methods and variables of that object, and diagrams depict relationships and source code dependencies between them.

Component diagrams – displays system components (physical or logical), interfaces and ports, and the connections between them. Allows analysts to replace and system check individual parts rather than designing the process from scratch.

Composite structure diagrams – shows the internal structure of a specific class, the role each element plays in collaboration with others, and how this affects how the class interacts with outside elements.

Deployment diagrams – models the physical deployment of artefacts (software systems) on nodes (normally hardware, e.g. laptop, mobile phone). Execution environment nodes are a ‘node within a node’, a software computing resource that displays hardware characteristics.

Object diagrams – represent a system overview. Similar to a class diagram, the take a snap-show of a system structure at a particular moment in time.

Package diagrams – packages are formed when UML elements are grouped together – classes, objects, use cases, components or nodes. A package diagram shows this grouping, and dependencies between packages that make up a system. An example of use would be when modeling complex source code; packages are used to represent the different layers of code.

Profile diagrams – operates at the metamodel level to show stereotypes as classes, and profiles as packages. Allows the developer to create custom packages.

Behavior diagrams

Activity diagrams – can be said to resemble a flowchart, showing steps in a software process as a workflow. Binary choices from each step, yes/no, true/false, make this a useful medium to describe software and coding logic.

State machine diagrams – describes the current state of a machine, which values are acting upon it. It shows what actions the nodes of a software system take, dependent on explicit events.

Use case diagrams – shows an actual example of system usage. Helps define requirements for a software system, and can describes any possible form of interactions between users and that system.

Interaction diagrams

Communication diagrams – displays the interaction between objects in terms of a set of sequenced messages. It’s used to create a birds-eye view of the collaboration between several objects, for a common purpose within the system.

Interaction overview diagrams – like an activity diagram in that it shows a workflow through a system, but simplifies complex patterns by making each step a nest of interactions within the larger overview of an activity.

Sequence diagram – useful to describe object interactions in a specific time sequence. Can consist of parallel ‘life lines’ that depict an objects state at any given moment, and the sequence of time ordered events that affect that state. From a software perspective, developers use this diagram can show simple run-time scenarios.

Timing diagram – depicts the behaviors of a given set of objects through a certain period of time.