Software Development Process… Decoded

[alacmathew]

Hi everybody. I am a project manager with a mid level software development company. Some days back I came across a posting in a forum where a person, otherwise a competent finance professional, wanted to know about basics of software development process

This got me thinking. In today’s world of multitasking, it is not rare to see people from different professional backgrounds converge and collaborate. But there seems to be pain involved in this. Why? Because, as I see, it, today’s highly focused professional education is creating people with one-dimensional capabilities.

So when two such guys meet, more often than not, it is a trial and error sort of on-the-job-learning (they can’t really go back to school, can they?) leading to much heartburn and consequent delays, cost overruns, errors, rework, and lowering of confidence in otherwise very capable people.

I am writing this series of software development basics to help people, especially non-IT professionals understand the way IT projects work. Please do chip in with more inputs.

Let’s start with the basics. It cannot be emphasized enough that a detailed and intelligent process is a must if you are developing software. Process means a guideline description of a repeatable procedure that describes the way that your organization develops software. It also defines your organization because it is the process that will be applied to the development of future projects.

Since Indian companies are choice of most organizations wanting to develop software, it would be wise to emulate their process, as it is the foundation stone of their providing high quality work at almost half the usual cost. Therefore, following is a little glimpse of typical process employed by the leading Indian comp
anies like Infosys, Brick Red , Wipro etc.


Domain Analysis
It is usually the first step in attempting to design a new piece of software. It involves the investigation of the area such as: banking, marketing, retailing, insurance etc., where the software is to be employed.

Know Thy Client
The holy grail of any project, satisfy your client. For that you need to know, what is in his mind regarding his requirements. He is the best person to tell you, what they want. While skilled and experienced software engineers can fill in any incomplete, ambiguous or contradictory information.

Specification
Specification means precisely describing the software to be written in a rigorous way.

Software architecture
The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed.

Implementation (or coding)
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.

Testing
Testing of parts of software is done by a software engineer to check out any bug or error.

Documentation
An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement.

In my next posting, I will discuss methodologies adopted to successfully develop and implement software projects. I hope this posting, though not enough by any stretch of imagination, should give the beginners a little something.

[black_russian]

That pretty much describes any country's software development process.

[kerowo]

Meh. Sounds like OP is writing a book report for his high school English class.

You are going to be getting poorly thought out and poorly written requirements that are going to turn out to be incomplete or just plane wrong.

You are going to have timelines based on the original requirements which were wrong and incomplete and probably based on metrics that if they have any basis in reality are going to be based on a project in a different domain using different people.

You better spend more time testing the code than you did writing it because the second contract is going to be based on your defect rate on the first one. You're also going to be finding more requirements when the users start testing the code.

Mostly you better like paperwork because with process and SOX and QA if you want to write code you're most likely going to be writing 2-3 pages of documentation for every page of code you write. And the documentation doesn't use white space.

Oh, you're also going to deal with managers right out of Office Space and Dilbert. Coworkers with no technical knowledge and not only opinions on how something should be done but the authority to make you do it that way. You'll spend hours a day in meetings on how to get your project on tract instead of on the project.

And to add insult to injury you'll have 3 year old crappy hardware and limited to no internet access during the day.