Need some information about software development life cycle
|
| Author | Content |
|---|---|
| karang Apr 19, 2007 3:34 AM EDT |
Hi I need some information. After we have taken the requirement from the client what is the next thing we should do for development of software. I am asking the simple question becuase whenever I asked this question I got different answer all the time. Kindly advice Karan |
| jimf Apr 19, 2007 3:44 AM EDT |
> whenever I asked this question I got different answer all the time. No wonder. Your question is the equivalent of 'Now that I've been given the circumference of the earth, how do I make it green?'. |
| jdixon Apr 19, 2007 5:17 AM EDT |
> After we have taken the requirement from the client what is the next thing we should do for development of software. What Jimf said. :) Won't that depend entirely on the requirements you've just taken? For example, the development processes will probably differ wildly depending on whether your developing a mainframe application or a desktop application. Likewise for the various operating systems. And that doesn't even get into the details of whatever you're developing. |
| NoDough Apr 19, 2007 5:22 AM EDT |
Karan, As pointed out above, if you ask this question of 100 people you'll probably get 500 different answers. That said, here's my knee-jerk answer. I am assuming that you have already sold your services, and received the project specifications document. If, however, you are still competing for the project then stop reading right now. The following is my opinion. I am not a lawyer and the following should not be construed as legal advice. The next thing you may do is construct a contract agreement that spells out very distinctly all the details that could become points of contention during the project. Including, but not limited to... Rates/Expenses (who pays for what) Scope (exactly what the software will and will not do) Completion (make sure you define what justifies completion of the project) Maintenance (after completion, how will bug-fixes be handled) Ownership (who owns copyrights, retains source code, etc.) Schedule (for the whole project and each phase of development) Expectations (what will be expected from the client and what can the client expect from you) Penalties (missed payments, late deliveries, etc.) Arbitration (in case of disagreements, keep it out of court) etc., etc., etc. Each category should be addressed to all parties. For example, the penalties section should spell out not only the penalties to the client for late payments, but the penalties to the contractor (that's you) for late deliveries. Also, you need to relieve the parties of responsibility for events beyond their control. Some sort of Acts-of-God clause (although I'm pretty sure it's not called that anymore.) Finally, take your notes to a contract lawyer and have them write it up formally for you. I repeat, this is my opinion. I am not a lawyer (IANAL.) |
| dinotrac Apr 19, 2007 6:19 AM EDT |
Karang - By now I see that you have been blessed with much wisdom and few answers. Welcome to the club, and don't feel bad! The "right" way to develop software is something that everybody seems to know and nobody seems to do. As you asked your question in terms of software development -- and not the business aspects -- I will leave out niceties like the contract (Please, don't YOU leave that out!). In real life, it tends to go a bit like this (for better or for worse): You get requirements from the customer. Now, however, because you haven't communicated very well with the client (I don't even know you, but I can almost guarantee that this is true), your next steps will be flawed. Depending on who got the information from the customer -- (some places don't involve developers in the customer communication project at all, relying on so-called project managers and business analysts in the rather idiotic belief that they can better leverage their resource that way) -- you will either put together some kind of puffy document that restates the requirements for the benefit of your developers, but does so in a way that nobody could possibly want to read -- or -- if developers got the requirements -- you start to lay out a design. There can be a whole cycle of design from general design to detailed design, but the process is more or less one of figuring out how you will apply your technology to meet the resources while insuring that what you do is not very good. You may think that last comment is a joke, but, unfortunately, it's not. Most development processes act as if they are designed to turn out nasty fits with the client's actual needs. That is a natural side effect of moving from people who have contact with the customer and no contact with the code to people who have contact with the code and no contact with the customer. One of the best next steps is to stop when you have designed the essentials -- basic functions, interfaces between parts, etc, and get into coding. Do something that you call a prototype -- this is great because you can keep it if it works out well and toss it if it doesn't -- that represents your understanding of key features. Stub out things that are too expensive to code up in this quick "get something running" round, implement others in ways that may be suboptimal but are quick to code and will function properly. Take this prototype and get people who care about the final result to check it out. One hint, though -- It's probably better to put a little extra time into look and feel than in code for this. Non-techies are sensitive to wonky appearance but can more easily overlook slow performance, etc, on a first pass. After that, you probably understand the "real" requirements and can design sufficiently to continue. Not only that, you have a working model which is great for testing ideas, etc. At any rate, that's notion 1,000,001. I'm sure everybody else has a better idea or three. |
| tuxchick Apr 19, 2007 7:29 AM EDT |
hmm, I was thinking 'stealth spammer', but we shall see. |
| tracyanne Apr 19, 2007 1:00 PM EDT |
Quoting: After we have taken the requirement from the client what is the next thing we should do for development of software. Huh!? You've told a client you can do something you don't know the first thing about? |
| jimf Apr 19, 2007 1:52 PM EDT |
> something you don't know the first thing about? Yuh... I was kinda thinking "glad I'm not your customer". |
| dinotrac Apr 19, 2007 2:48 PM EDT |
>Yuh... I was kinda thinking "glad I'm not your customer". Odd, I was thinking SOP. |
| karang Apr 19, 2007 8:32 PM EDT |
Hi I am writing which I have inferred after reading your threads.Please correct me if I am wrong. I am considering a scenario in which I have to make a web application like Employee Management System.Client says I am giving the requirement document. Then I should make the understanding document. After that document is approved then I should go for other documents like design document etc. One more question which is good link for software engineering from where all these things are elaborated(I mean SDLC) Kindly advice Warm regards Karan |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!