- About Us
- Web Sites
- Current Issues
- COURSES 16
- General Server Configuration
- Archived Sites
- Pre-Moodle 2
- 2010 Server Rollover
- COURSES 15
- Systems Group
- Data Portal
- Cert Exam App
- Data Updates
- EAHR Advising
- EPSY Grad Application
- Field-Based/Student Teaching
- Grad Review
- HLKN Advising Forms
- Project Achieve
- SPED Prof Phase App
- Student Database
- Student Observations
- Help System
- Windows Utilities
- Linux Utilities
- Hard Drive Data Recovery
- Data Portal Servers
- VM Hosts
- Shutdown Order
- Triplite KVM Switches
- IT Security
Although each project has unique aspects, below is a sample of the tasks required for even the simplest software development task.
- gathering the requirements
- requirement analysis
- architecture inputs
- form design
- object/class design
- implementing the business rules
- data validation and storage
- framework (i.e., code for constants, enumerations, utilities)
- deployment up to user acceptance
Software Development Milestones
For choosing milestones there is only one relevant rule. Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Coding, for a counterexample, is "90 percent finished" for half of the total coding time. Debugging is "99 percent complete" most of the time. "Planning complete" is an event one can proclaim almost at will.
Concrete milestones on the other hand, are 100-percent events. "Specifications signed by architects and implementers," "source coding 100 percent complete, keypunched, entered into disk library", "debugged version passes all test cases". These concrete milestones demark the vague phases of planning, coding, debugging.
Software Project Estimation
- http://www.codeproject.com/KB/architecture/estimate-manhour-software.aspx|Time Estimation
To estimate cost of a project
- Break down project into small parts
- For each part, how similar are they to previous project pieces? or to outside pieces that can be copied/replicated?
General pieces to consider
- What types of events could happen? how will each be handled?
- Exception handling
- What data is involved with each event?
- It's easy to estimate what you know.
- It's hard to estimate what you know you don't know.
- It's very hard to estimate things that you don't know you don't know.
An idea by someone
The goal of a ballpark estimate is to find a value that is within two or three times the actual value.
- Break the project down in the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks.
- Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.
- Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required.
|Small||e.g., HTML for a small form (< 2 hrs)|
- Sum up the estimates for all tasks to get the ballpark estimate.
Better estimates can be determined as the developers better understand the nature and challenges of each task. For projects with multiple -- but similar tasks, once a couple representative tasks are completed they can be used to refine the overall estimate.
- Those who will do the actual work are the best people to do these estimates. One then can add up all the estimates from different people to get the final estimates.
- Ensure you collect estimates on the three variables of time, people, and infrastructure/material needs.
- Break down tasks to as detailed a level as possible. As mentioned previously, it can help to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task. Break tasks down to a granularity of eighty hours or less.
- Review actual time with estimated as tasks/projects are completed and learn from correct and incorrect estimates to make better estimates on future projects.