How is a software team formed and what kinds of roles do the members play?

Question

I am currently working as an intern in a Software farm in India. To me the software development process is somewhat bizarre here.

The steps followed in developing a software are as follows:

(1) A system analyst go to the clients and listens their problem statements. In this case the system analyst is a senior person (holding a post of director or something) with little programming experience, or, is away from coding for quite a while.

(2) The System Analyst identifies the UI modules of the software, draws the block diagram and writes down the description of business processes.

(3) The System Analyst forms a team having a lead programmer and 3/4 junior programmers.

(4) The System Analyst gives away the printed version of his identified modules, block-diagram and description of business process to the team members and discusses about the them.

(5) The team understands the business process and prepares a dummy application.

(6) The dummy application is shown to the client. And the client gives his remarks.

(7) The UI is then modified as per the client-remarks.

(8) Then the programmers (including the lead programmer) design Classes, tables, etc.

(9) The System Analyst observes the ongoing project as the deadline approaches.

(10) Mid-term demo is shown to the client. Their remarks are reflected.

(11) Programmers performs unit-testing.

(12) The QCs test the software.

(13) Programmers corrects additional bugs.

(14) Final product is delivered to the client.

(15) After sales support is given as the time goes by.

Can anyone tell me what is done in countries in Europe and America? How a software team is formed, what kinds of roles do the members play?

Who prepares the UML, who conducts CRC session with whom, who does OOAD, who codes, who designs database?

In my farm, no UML, CRC is done. Classes and tables are designed by programmers.

Answer 1

I don't see anything really out of the ordinary about that process. Every company does things differently, but the process you describe is probably similar to that used by hundreds of companies here (in America).

Answer 2

I suspect any differences in the way things work are down the size and attitude of the company, not the geographic location.

I've only ever worked at small companies, but I've never seen UML in the real world. Classes and tables are always designed by programmers. In fact, very similar to the process you describe.

I'm in London, UK.

Answer 3

I've worked and consulted in lots of British, American & EU companies where what you describe was the norm, and even considered "best practice". Of course, not all of those companies are with us any more...

Answer 4

Welcome to corporate cubicle programming.

It all seems to be prefectly normal for a corporate/outsourced project.All of what you said depends on the complexity of the project.If task is going to be a small one, developer mostly does all the tasks and just get the approval.There is no point then for the process. But in more complex tasks, roles of architects and designers come into scope. But I guess this is different in smaller start-ups.

Answer 5

I've only worked in fairly small companies in the UK and this process sounds a lot more organized than anything I've seen at most of those.

Answer 6

In my experience, this is the standard process as the bosses envision it. In the real world, it eventually breaks down because:

• Customer comes up with new ideas after step #2
• Customer sees result and cries "That's what I said but not what I meant!"
• Developer gets output of step #1-4, tried to make heads and toes out of it and can't because a) some vital information is missing, b) it violates laws of physics or c) it would be insanely difficult to implement that way

That's why Agile was born. In a nutshell, you do the above process every three weeks. Of course, since the iterations are so quick, each step in the process above will be very small. But it allows each party, especially the two most important ones (users and developers) to keep the other parties in check.

Answer 7

Of course, the success and quality depends heavily on the System Analyst, but the interface and later the application makes several round trips to the customer. This is essential to the success of most customer-facing applications which are heavy on human interfaces.

Such an approach might not work well if it is a back end or middleware piece that is heavy on API interfaces and have little or no human interfaces. However these components are much less likely to be outsourced.

As for UML, you'll find it primarily on Gov't projects, bank software, or other highly regulated software where the software process is mandated in some way.

Answer 8

I've had more than a few different ways things go. In the past I've had a couple of different styles:

1) The never ending project - This is where what is being developed never really has a deadline and new features, enhancements and bug fixes are all blurred together to get something out the door. This is the case in a couple of start-ups where there isn't a project manager to run things but rather a VP or other higher up who is running things.

2) Big projects where there is a PM - In this case, there may be months of work done by various developers with the occasional test pass by QA before putting something into production though there are also cases where a bug has to be fixed ASAP that has a sped-up approach where there is still a QA but the turn around is usually only a couple of days compared to months. Where I worked that had this there was a change among the developers to form two groups: 1) Project delivery which would work on big projects that took months and then have a warranty period on those deliverables and 2) Continuing engineering that would take work items on a shorter schedule and delivery more frequently various bug fixes and little projects that could be done in 2 weeks or less.

3a) Enterprise IS the big stuff - This is where I am now where there seems to be a few layers to how something gets rolled out. There are various investigations done among vendors to provide a solution for a big system, such as an ERP, CRM, or CMS, and provide an initial short list and then a recommendation for what to use. Then comes the selection of both the vendor,e.g. Oracle, and a consultant firm as this requires some customization and other changes as the systems are designed to be very flexible; meaning that processes have to be defined and various legacy systems turned down in a controlled manner so there are a few releases of the software as a transition is done from one system to another. The process overall takes years typically and by the time the final release is done it is time to start the process all over again for something else that the company has outgrown as the company gets bigger and things go well though I'm thinking this may not be common these days. ;)

3b) Enterprise IS the not so big stuff - Depending on the size there are a few different buckets the work can be. At the smallest there are support tickets and change requests that are less than a day's work to fix a problem or put in something new that is small. One step up from this is work picked from a committee to handle prioritizing work that takes from a day to a couple of weeks for a single developer to get something done that isn't quite as trivial. Lastly, there are projects that take anywhere from a couple of weeks up to a few months as anything bigger than that should be in the previous category. For example, a proof of concept of various short-list vendors can be a project here while the implementation done in a few phases are each in that 3a camp rather than this area.