HomePractices Page 5 - The Art Of Software Development (part 1): Understanding Need
When Time Is Money... - Practices
Wondering why your software projects are always late, buggyand over budget? Well, this might come as a surprise to you, butprofessional software development involves a lot more than just writingcode. Over the course of this five-part tutorial on software developmentprocesses and practices, find out what you've been missing, and how youcan streamline your development to be more efficient and effective. Thisintroductory article discusses the analysis and documentation ofcustomer requirements.
Once you've got your first cut of the requirements document done, it's also a good idea to prepare a draft project plan outlining the tasks, major project milestones and deliverables. Again, this draft project plan can be as simple or complex as you like; however, you should make it a point to spend some time estimating the time required for the various tasks, and to build in time for unanticipated problems or delays.
Here's a list of tasks that should appear in your project plan - feel free to tailor this list to your specific needs:
Software architecture design
User interface design
System test plan development
Acceptance test plan development
Implementation
Documentation
System testing
Acceptance testing
Delivery and installation
Each of these items should be associated with a specific person or team, and should include an estimate of the approximate time required. This estimate is helpful to you when calculating what you should be charging for the job, and to your customer in obtaining the date on which the software will be available.
You should also budget enough time between the various tasks listed above for customer reviews at critical points. You'll definitely want a customer review of the user interface and the acceptance test plan, and you should also schedule a few reviews at leveraged points during the implementation phase. These reviews serve as a useful way to get feedback from your customer that the project is being implemented as per expectations, and can also provide you with a heads-up on possible problems along the way.
Stifle the urge to be ultra-aggressive with your deadlines in this stage. Sure, your customer wants it yesterday and is more likely to hand the contract to someone who promises that, but you won't score any points by delivering poor software in record time. Most customers prefer vendors who provide realistic schedules and then ensure that they are met without compromising on quality.
It's also important to state the assumptions you've made while developing the project schedule; this can help cover you in case delays occur due to no fault of your own. There are two important assumptions I usually put into the schedule: first, that the schedule assumes customer response to queries within one working day; and second, that the customer will provide all data and report samples prior to implementation. In my experience, if you've estimated the work accurately, most project delays will usually occur because of one of the two reasons above - which is why it makes sense to protect yourself by clearly stating your assumptions in developing the project plan.
The requirements document and project plan sometimes form part of a larger commercial proposal or work agreement. This package is delivered to the customer for approval, and work begins only once this approval is received, and all required assets have been delivered to the project team.
Practices 
/ 6 
