Software Methodologies

5 Steps to a successful transition

2009-01-11T22:14:00.000-08:00

These are the five steps I think essential for any transition post budgeting and deciding on which project to transition. These steps are for the final execution of a transition.

Step 1: Go through documentation.

The first phase of the transition should be reading the documentation. In this phase the team should be advised to read, read and read. They should be reading all the

- Support\development related documentation.

- Manuals for hardware and software systems involved

2. Dealing with people

3. Networking

4. Going live

5. Farewell

(This is incomplte because I want to have inputs from all the readers and contributors)

Processes Vs People

2008-06-04T22:09:00.000-07:00

Processes are meant to make projects people proof. By 'people proof ' I mean a project that is free from any effect occuring due to a team member leaving or joining. This is one factor which always has a considerable affect on the project.

After all it is the people who implement the processes and work on the project.

However, hard we may try to document all the knowledge; always there is that certain percentage of knowledge that remains with a person and is lost when a person leaves the team.

This is a very concerning factor for any sort of firm doing business in a volatile environment like India; where the attrition rates in a team can be as high as 100% in a year.

Web hosting

2008-05-27T20:46:00.000-07:00

Checkout thebestdomainsite for truly superb and cost effective web hosting solutions starting from US$ 3.99 only.

Search for Perfection

2006-11-09T22:39:00.000-08:00

Our entire effort, from the day we enter the education system, is targeted towards getting that dream job. Though the dreams keep changing as we mature the underlying principle remains the same – a job which we enjoy doing. When we start our first job the illusions of a ‘perfect job’ usually vanish within the first few months and we are forced to admit that there is no such thing as a ‘dream job’. For the fortunate few who are able to get that elusive ‘dream job’, stick with your current job and stop reading this article!
Normally all jobs have a positive as well as a negative aspect and if we are forced to define the concept of a ‘dream job’ it would be a job, with as few negatives to it as possible, which we enjoy doing. Read More ...

Communication Skills and SDLC

2006-09-27T09:02:00.001-07:00

In my previous posts I have written a lot about SDLC. How it should be implemented, what are the pitfalls, what to avoid etc etc. Therefore, this post is more on the human part of the SDLC. Since, it is humans or the software development team which makes or breaks a successful life cycle implementation.

When humans are working in a group, 'Communication' is the key factor. Same is true for successful implementation of any SDLC, if the team communicates well, then it can overcome any hurdle.

In reality there is very little or no communication between Software Development teams. As, software engineers do not believe in communicating by default. Even if there are few who do communicate; they are not able to communicate effectively because of lack of time, stress, complexity, ego etc. Sometimes even getting that one email with vital information is a dream.

It is infact amazing while designing these lifecycle models; in so many of them we forget to give enough weightage to most essential ingredient - 'COMMUNICATION'. Communication is not stressed upon, neither in theory nor in practice by Project Managers, Team Leads etc. It is necessary for all the teams to communicate with each other, which includes:

1.Keeping other teams in loop by sending regular update emails.
2.Proper indentation and comments in code
3.Follow the same standards throughout the code
4.Write simple, efficient,easy to understand code. Avoid writing spaghetti code.
5.Try and hold weekly cross training sessions between teams and between team members.
6. Speak calmly and in normal tone. It is good to be assertive but, bad to be aggressive.
Etc...
From these examples we can see that there can be two forms of communication. Firstly passive communication where we document systems and write comments in code. Secondly, active communication where team memers communicate directly face to face or with the use of Instant Messengers, Email, Telephone
Now this may seem very easy for normal fellow human beings. But, this is easier said than done. Software professionals are a complex lot.

Well, these are the standards to be followed while Doing any work, not just writing code. While, this is followed in every other industry - I wonder why not in software industry. An environment where intra teams and inter team communication is smooth is management's responsibility too. They should encourage team building activities, communication skills workshops and all.

To conclude, it is good that you have the knowledge and skills to do all the work on your own. But, until and unless you do not communicate with others, share your ideas with others. Building that world class application or system is not possible. For all the team members, the common goal in building a software should be to build that error free, quality product on time. Not to show their individual programming prowess.

To conclude this post or to write all about significance of communication is beyond the scope of this post and hence in my trademark style I will end this post abruptly.

Importance of Good Design

2006-09-07T23:32:00.000-07:00

Millions of dollars, unlimited man years and what not are spent on new software by many start-up firms, lucky enough to get investors to invest in their ideas.

But again and again what I see is - lack of long term planning. That is developing a good plan, so called design in our Software terminology. Why time and again people do the same mistake. The same people who are taught in colleges; time and again why a particular software failed etc. What needs to be understood here is that you will never have time to fine-tune, polish your product once you go in live phase.

If the design is good - all will come out well, plus even during the R&D phase, making changes are easier and less cumbersome if the design takes care of changing requirements and algorithms. If you never had time in the start, you will never have time and eventually everything will fall apart. It is just like constructing a building, if the foundation is not good - building will fall, no matter how good you make it look.

Sometimes no matter what, we have to follow the procedure; like for operating a patient doctor has to follow a procedure. There is no shortcut way - without threatening the life of the patient. Same is with software development, you may take a shortcut; eventually to kill it in the process.

Added by Azahar:
Code rushes through my head when I hear people talking about various software projects.. that is the wrong way to think.. if you can think DESIGN before you think CODE that means you are a top class computer engineer (or programmer).

But professional design is a tediuous and often time consuming activity which is as important as it is difficult to do well!

Most small projects or dedicated systems, in my experience, are designed on the basis of 'object oriented organization' rather than full blown OOAD (which involves higher level elements such as Design Patterns).
The system is just represented as a set of interacting classes or objects.
This can be very effective, reducing design times as well as making sure most of the good design features are present in the result. But this requires an implicit understanding of what is good OO and what is bad OO!

If you find yourself stringing together classes like a garland one after the other then you are surely doing something mad.. and trust me.. pretty soon that garland is going to start stinking!

The basis of good OO design is how to keep the interfaces of the classes clean and less prone to change and the number of classes themselves to as few (and thus efficient use of code) as possible. Thus it becomes VERY VERY VERY IMPORTANT to understand and keep in your mind AT ALL TIMES the concepts of cohesion and coupling whether you are doing OOO (Object Oriented Organization of your code) or full fledged OOAD.

For those who don't know about Cohesion (Coh.) and Coupling (Cup.):
Coh. means how well organised the code is within a class... how well the code of the class works together to fulfill the functionality of the class. If a class is really bulky and requires access to external code then we say that Coh. is low.

Cup. means the number of connections a class has with other classes.

Usually the best design practice is to INCREASE COHESION and DECREASE COUPLING. This ensures classes remain as stand-alone and re-usable as possible as well as decreasing the 'stringing' effect of dealing with a highly connected set of classes.

The common trick for reducing Coupling is, if you find that two classes have a lot of connections between them, try and merge the two classes together or try and shift the functionality from one class to the other (you can even try merging the functionality from both classes into a third class!).
To reduce cohesion you need to concentrate on the first level analysis of the problem (high level requirements). Often a re-analysis of the problem can lead to a more efficient Class/Object based Design.

Documentation

2006-07-05T03:51:00.000-07:00

Documentation is the most important part of Software Development. Without it your code and program has no meaning. Its like a person without a name, a house without a layout etc. Documentation is the most effective medium to transfer knowledge to a new employee or make a project empolyee independent. This is known to us all, and still we manage to overlook its importance and don't devote that 10 extra minutes; that can make lives so much simpler.

I am amazed to hear that most of the times its the management who asks staff to just go ahead and meet the deadline without completing the documentation (came to know from various many sources). Sometimes it is considered unecessary. It should be noted that even if the deadline is delayed by a day because of documentation; it will save n number of days in future. Thus saving money, which is what management wants at the end of the day.

We all know why, it will save us n number of days and frustration in future!!! We all have been through 1000s of lines of code which make no sense et al. and nobody knows why is it there; it's at that time we sulk at the previous coder for not documenting. Then its only us repeating the mistake.

Any innovative ideas to integrate documentation in the SDLC process, so that it is not as boring as it is. I think there should be regular reporting of your work through small presentations to rest of the team members. This will make documentation essential, because to train your team-mates on your work you will have to write notes - thus documenting it. But, still it is not fun :-D

-Thinking Thinker

Added by Azahar:
Well as they say it requires energy to bring order to Chaos! That is true for any kind of system. In the end it depends on how much spare energy there is.
But then again more energy you spend in bringing order to Chaos less energy you will have to spend in maintaining the order.
The bottom line is.. sometimes even small snippets of comments written as you are coding, can really help you out when you least expect it!

So the bottom line is:
EVEN IF YOUR DOCUMENTATION JUST INVOLVES COMMENTING THE CODE AS YOU GO... DO IT! IT WILL SAVE YOUR ASS ONE DAY!

Welcome to Dell!

2006-05-07T21:45:00.000-07:00

http://www.theregister.com/2006/05/06/dell_india_design/

Dell is ringing India's doorbell! (Sorry for the crap rhyme!)

Here is the negative side:
http://www.theregister.com/2006/03/20/dell_india_grow/

And finally:
The future according to some idiot @ the Register.

http://www.theregister.com/2006/02/24/otto_mexico/

genetic-programming.org-Home-Page

2006-05-03T21:40:00.000-07:00

genetic-programming.org-Home-Page

Good page if you want to get started on Genetic Programming/Evolutionary Systems.

Can these systems, help us come up with foolproof development lifecycle?
OR
The way these systems generate new programs, by following similar process; is it possible to improve current Life Cycle Processes?

Maybe, Azahar can throw some light on this.

Cheers!!!

Now your talking my bread n butter stuff.
The problem is Genetic Programming (GP) is good at building simple programs, structues and functions.
Say you have a data set and you need to find which function fits it the best. Then you can use a GP to find the function for you. If you want to design a circuit with set parameters then you can use GP to build a program to simulate the circuit in some circuit simulation language.
Many such examples have been cited in John Koza's famous books on GP. Those books are the starting point for anyone doing a PhD in GP systems.

But the problem is when you talk about software there is no easy way to figure out what code is correct.
In the above two examples you can easily find out how fit a solution is. In case of function fitting just do a comparision of the points generated using the function with the data points you are trying to model and in case of circuit simulation just run the circuit through the simulator and it will give you the operating parameters of the circuit. In these problems the fitness of the solution is not a digital measure. So it could be that the function is 85% correct (i.e. the error between function generated points and those in data set is 15%) or the circuit is within 95% of the operational values you want.

In case of software it is very difficult to have this kind of smooth measure. How do you know how good a piece of code is? Either it does what you want it to do (100% correct) or it doesnt do what you want it to do (0% correct). It is very difficult to say that a piece of code is '40% correct' (remember in software first we are interested in its functionality and then we look at optimizing the software to make it run faster!)

GP uses a simple programming language called Lisp to create programs. The problem is that programs made in Lisp are hardly of any use to us. We can create simple functions etc. but if we talk about whole program development then its almost impossible.

Also it is very difficult for GP trees to model an object based program (here we are getting to the issue of representation of problems with EA - which is my field of work, look at my work if you are interested) and create an Object Oriented piece of code. Objects are one level up from trees. Object bases systems can be decomposed into trees and sub-trees but the process is quite complex.

As far as working at design level there is work being done in automatic OO design using UML and evolutionary algorithms. This means if you have a set of data types and a set of methods then what is the best way of assembling them into classes such that the design is efficient.
We can use measures like cohesion and coupling (many other metrics are available to define quality of OO design) to split the data types and methods into classes.
But again this kind of work is in its infancy. There are problems with how to get the basic data types and methods? How to put them together in a class which makes 'sense'. In other words how will the computer know that data relating to customer must go in one class and so on.
To get around this we could use interactive evolutionary design systems (IEDS) for complex designs (such as software, buildings, bridges, drug molecules, planes etc). Again this is a field in its infancy. I wont open the IEDS can of worms. You can check out the link I gave since my research involves IEDS as well.
;)
WAKE UP! WAKE UP! WAKE UP! Its over!

SQL vs XML in a database world

2006-05-02T04:09:00.000-07:00

SQL vs XML in a database world

Another old article but worth a read.
Describes how XML is better.

I feel working with SQL and XML in conjuntion is pretty neat.
Without actually giving access to database information can be shared.

Note: Correct me if I am wrong.

Oh My Gosh!!!

2006-05-01T23:01:00.000-07:00

Putting the Enterprise into the Enterprise System

Have a look at the article above.
If you can possibly read it, then please do.

It is amazing how, the author goes on and on about the same thing for 12 pages. I will make no comments any further.

Nice article. Bit too detailed for people in the IT field.
Well probably we would be writing such articles in the years to come!

Also the article is quite old. 1998... way before modern enterprise systems, web services, MoM and distributed databases!
These things were created because people realised that Enterprise systems should fit the enterprise and not the other way around.
With MoM and web services even legacy applications can be bought within the Enterprise systems umbrella.

MoMs here!

Reinventing the Wheel!!!

2006-04-22T00:58:00.000-07:00

It seems that IT/Software Industry is nothing but hyped up version of simpler things in Life/IT/SDLC.

Google is coming up with same things which existed earlier; with little add-ons and creates a lot of hype around them pushing up stock values in process. A good example is link provided by LIPI.

This all, seems to be the trend in Software Development methodologies as well. Looking carefully at all the hype surrounding Agile Methodologies and Extreme Programming etc. One wonders isn't it the normal way of doing things? Why did we come up first with hard and fast rudimentary life cycle models and now going towards the more natural ways of software engineering? In fact it seems, even while following older life cycle models, agile methodology was followed in one way or other. So we are not doing anything new but following the same things, what we did years ago.

Design patterns - is again something, which is over hyped.
Many of us as students even without prior knowledge of design patterns, have used them unknowingly many times.
Example: When 1st Sem project is similar to 2nd Sem project - in terms of design and coding. Same designs are altered to address the problem at hand. Or, we look at older projects in library and alter existing design which suits our needs.

So what's new I wonder?
Was it short-sightedness of people driving IT/Software Industry? OR we dumbly follow whatever is taught in text books.
Or
Software industry is all about representing already existing practices/knowledge in a new manner every now and then?

The Register

2006-04-19T17:24:00.000-07:00

Check out this website for techno stuff explained in a friendly and funny manner!
The Register

2006-04-14T16:17:00.000-07:00

deviating form the agenda ...
well if its a technology blog, how can there be no mention of GOOgle
heres an inetersting site/blog
http://www.fuckedgoogle.com/
check it out .. if u havent already before

Give this a thought

2006-04-08T00:45:00.000-07:00

Swanson Marketing - SDLC Process

Go through the link and the SDLC followed by the above mentioned firm.

The SDLC shown is a mix of waterfall, prototyping/incremental methodologies. These methodologies (except waterfall) cannot be followed as they are, because in real life client demands a definitive quote for the product being developed. Cost, cannot be calculated unless the requirements are frozen.

In such a scenario iterations do occur, but most of the changes are superficial (GUI) or fine tuning of the software. The UPPER LEVEL requiremets remain frozen.

Here is the problem - since client is not sure what to expect of the software the initial requirements done prove to be inadequate. Client learns along the way, what extra features/functionalities can be integrated in the software. We do have SDLC methodologies to address the same, for example - extereme programming or agile methodologies.

But, this raises another question - how do we calculate the cost of software development, in such a scenario? i.e; when using an adpatable SDLC. This leads to serious budgeting and cost issues.

I am yet to come across a methodology which includes a stage in development for costing/budgeting issues as well. Where all these issues can be tackled.

The thinking thinkers think tank...: Extreme Programming: A Gentle Introduction.

2006-04-07T21:08:00.000-07:00

To start off lets start by one of the earlier posts.

The thinking thinkers think tank...: Extreme Programming: A Gentle Introduction.

SDLC - Research P.O.V.

2006-04-07T21:04:00.000-07:00

Procedure is very important especially when attempting something on a large scale.
Plus we have heard all the stuff about having 'repeatability' and 'high quality' in your processes. This is where SDLC comes into the picture.

The most amazing thing is that even though building a software has a finite set of steps with well understood inputs and outputs, we still have a wide variety of SDLCs.
From the simple ones like prototyping to complex ones like RUP.

In terms of research SDLC plays a very imporant role. The most common SDLC used is prototyping since most software built during research (to either support it or as the main research itself) has to undergo many (and frequent) changes before the research is completed. Once the software enters production stage then a whole new SDLC takes over since by then the work to be done is easily understood.

This shows us something very interesting. It shows us that more complex (thus rigid) an SDLC less is the novelty of the projects it can handle. Furthermore the balance of effort between Project Management (PM) and Project Execution (PE) also shifts from PE towards PM.

Thus it is very important for the manager to user the right tools for the right job.
Using a highly complex SDLC for a blue skies project will surely divert resources from PE (where they would be needed) towards PM and make the whole process quite useless for the task at hand.

Bottomline:
Complex projects don't always need complex (or fancy/expensive) SDLCs.

Agenda of the BLOG

2006-04-07T12:26:00.000-07:00

Agenda of this blog is to critically analyse new software development methodologies and remain updated with them. Also, various other related things can be added too.

I would like to take some more contributors if, people are willing to.