View Single Post
 
Old 03-29-2005, 01:02 PM
loquin's Avatar
loquin loquin is offline
Google Hound

Retired Moderator
* Guru *
 
Join Date: Nov 2001
Location: Arizona, USA
Posts: 12,400
Default Alphabet Soup

When I was a kid, I loved making up words with my lunch - you know, arranging the letters in my alphabet soup to send messages to my brother. And, I still like Scrabble.

Still, all the specialized vocabulary that you see in the software field can be daunting, especially since new ones are being made up every day, it seems. There's one that's been around for years, though, that you should really be aware of: SDLC.

So, just what in the heck IS SDLC, anyway? SDLC stands for System(or Software) Development Life Cycle. SDLC is a design methodology that is widely used in the industry. If you want to get ahead, it's well worth your while to really understand it, and to actually apply it. I mean that. Take the time to study it. It can REALLY be your friend, especially when dealing with clients. The problem is, you can't start it in the middle of a project - you need to define the parameters of your project up front. By this, I don't mean that you have to design the project up front, but you DO need to define the stages of your project, and the deliverables at each stage of the project, in the very beginning of it.

The basic concept is of SDLC is this: You define and document, up front, what your application will do, and follow through completely through implementation and test. The first step of SDLC is to define, at a high level, your application. The output of this step is typically known as a Requirements Document. Not only should the requirements document detail just what the expectations are for the application, it should also include the Application Domain (the part of the real world that your app will interface to.) The Application Domain can include the users of the app and their roles, the departments affected within a company, the network, database, or other physical resources required, etc. Another thing that the Requirements Document can (and often should) contain is unanswered questions. It's highly unlikely that you'll be able to answer all the questions about the application at this time, but you should document what you need to find out to complete it. In order to produce the Requirements Document, you'll need to spend time to understand the BUSINESS requirements for the application. Interview the anticipated key users of the system. Talk to the managers to know that what you propose will meet the business objectives of the company. If you can't do this, your "solution" will have the proverbial snowball's chance in Hades of being approved.

Once you've defined the requirements of the app, and gotten client approval, you can then begin the Functional Specification document. This document will have little to no software design, but is the basis for all further system design. In it, you define HOW the application will work. What the users will input (but not how they input it.) What the outputs will be, but not specifically how the outputs will look. What data will be stored, but not HOW the data will be stored. Where/when data will flow from point to point, but not how the data actually flows.

Then, once approval is gained from the client on the functional spec, you can then move into the actual design phases. Produce a database design, application software design, report designs, input screen designs. These design documents will be based on the functional specification. Finally, after you get buyoff on the software design, you can move forward on the software building, testing, and maintenance phases.

You may say to yourself - "What the H&*($ are you doing, going through all these steps before you ever start coding! I can't afford to spend that sort of time!" Well, given the above realities, I would counter with "You can't afford NOT to spend this time in the design and approval process."

Think about it... By going through with these steps, you can limit your exposure to loss. You won't have spent a lot of time designing and coding that will have to be scrapped, re-designed, and re-coded. Because the client will have had the opportunity to review, comment on, and approve each step, they will have a sense of ownership as well, and you will have bullets in your gun when a design change request comes along. "Yes, Mr. Customer - that CAN be done. However, I've already designed and built the software to meet our original specification, so it will cost us X weeks of development time to re-write the code, and the schedule will take a hit." The client can then make the decision to pay for a re-write now, or to wait until the project is done and implement it as a separate, follow-up project.

By spending the time up front establishing the concepts of SDLC, you can also tie your payment into the development as well. i.e., you receive 10% of your quoted price on delivery of a requirements document, 20% on delivery of the Functional Spec, 20% on design completion, 30% on installation completion, and the final 20% on Client acceptance.

Approaching a project this way also has a soothing effect on the client. First, it shows that you are taking a professional approach, and have a definite plan for their project. They are ALSO limiting their exposure to risk. If they wish, they could end the project after the functional spec is released. Then, they could go out for bids with a functional spec to document their requirements, if they so desire. In fact, it's often a good approach on your part to only commit an initial quote to produce a functional spec, because you often won't know the exact parameters of the project until you take the time to produce a functional spec anyway. Then, with a firm understanding of the application requirements, you can bid a project. (And, by actually producing the functional spec, you've got a leg up on the competitors, as you KNOW exactly what needs to be done.) In addition, since you're familiar with the people and the project, you have another leg up on the competitors, which you can turn to your advantage.

Finally, time you spend on the conceptual design of the application is well spent, as you will end up with many fewer of those expensive re-writes, and redesigns later. And, because you've taken the time, in the beginning, to understand the business processes, I contend that the software you produce will be of higher quality than one thrown together without the up-front formalized conceptual design. If you'd like to read more about analysis and design, the Hollis book mentioned in the books thread in the tutors corner has a lot of information about SDLC (even though Hollis doesn't use the term at all.)

So, soup, anyone?


Edit by loquin: Hollis' book allows freely copying and distribution of the templates used within the book, so, here they are, in the ZIP attachment.)
Attached Files
File Type: zip Requirements-funct spec templates.zip (19.8 KB, 45 views)
__________________
Lou
"I have my standards. They may be low, but I have them!" ~ Bette Middler
"It's a book about a Spanish guy called Manual. You should read it." ~ Dilbert
"To understand recursion, you must first understand recursion." ~ unknown

Last edited by loquin; 04-21-2008 at 01:54 PM.
Reply With Quote