Thursday, May 10, 2007

Tips for Software Development Cycle Part II

Here is second part of the software development cycle. In the previous part you understand what is exact software development process and the questions arise by clients. Now in this section I want to explain why you need a proper process to develop an application or simply application development.


 


Why You Need a Proper Process to develop an application?

Your process is your channel through a landscape of highly complex, mutually supporting activities and sub-activities. During the lifetime of a project, there will be many tensions and pressures that try to deflect your attentions and efforts from developing good quality, utilizable software applications that is deliver in right time.

Most, the process of application development must be maintained throughout the cycle. A software development process is not a formula that, once written down, is never questioned or changed. It is an instruction that incorporate much of the information from previous projects. Maintaining your procedure is your prospect to feed back the successful, or else, experiences of projects into the future projects of your association. An association that cultivates, compliments, and maintains its software development process is a learning association.

Wednesday, May 9, 2007

Tips for Best Practices in Your Software Development Cycle

In this post you can find out what are the best practices for your software development process. Now question arise what do you mean by Software Development practices. Do you know what they are? Do you make use of them in your everyday application development?



Why is so much software developed unsystematically? Why are best practises in this field ignored? In this post, I first want to give explanation the traditional view for the need of software development process. This is not a big surprise. So why much software’s are still developed unsystematically, either without a process or with disregard to best practises.



What is an exact Software Development Process?

It cannot be stated too often that if you are developing software, you need a process. By process, I mean a guideline description of a repeatable procedure that both describes and prescribe the way that your organization develops software. It describes only the process because the process that works best for your organization is different to the process that works best for another organization. So the process says a bit about how your organization works. It prescribes the way that your organization develops software because it is the process that will be applied to the development of future projects as well.

It is not sufficient just to say that the process is simply:

Cycle 1 >Requirements->

            Analysis->

            Design->

            Implementation->

            Testing->

            Documentation->

            Maintenance

Cycle 2 >Requirements->

            Analysis->

            Design->

            Implementation->

            Testing->

            Documentation->

            Maintenance

And so on.

As this leaves far too many questions open to explanation by customers, managers, and developers alike. For example, what kinds of requirements are gathered in the first Cycle? How detailed is this analysis? Does the design phase wait until the requirements phase is completed before it starts? And many more questions.

 Of course, every association will have its own answers to these and other questions. The answers to such questions should be record in several sort of a document; say a process instruction manual. Then, if a potential customer asks the question "How do you develop software?" etc etc, you can then demonstrate not only that you have thought about it, but that you have a well documented, professional way that works for your association.

Different organizations have different requirements for their processes, so there is not one "correct" process. The developers also need to believe in the process so that they can work together as a team, respecting the boundaries between different parts of the process and the implications of the process on their roles in the overall development.