I'm a university student, but I don't come from an engineering or programming background. I'm doing an academic assignment where I need to estimate how long it would take to develop a website for a delivery service company. The website should have features like user login, map integration and notifications.
I don't have much experience in software development, so I'm after some methods or best practices that'll help me make a realistic forecast, even if it's just a rough estimate.
You can't.
There are techniques for estimating work. Steve McConnell's Software Estimation: Demystifying the Black Art is one of the canonical references and libraries of estimation patterns and techniques. Many techniques, such as decomposition and recomposition, analogies, proxies, and expert judgement, can be used independently or combined.
If you've started to take the overall effort ("develop a website for a delivery service company") into features (login, map integration, notifications) and then those features into smaller units of work, you've already started decomposition. You would then use another technique to estimate the bottom level of work. These other techniques could be historical data (if you've done similar work in the same context), analogies to similar work, or experience and expertise. However, if you've never developed complex software and don't have any historical data or experience, anything would be a guess not based in any reality.
However, even with these techniques, fundamental problems still make realistic forecasting difficult. The most significant problems are around uncertainty and change.
The cone of uncertainty is one concept to be aware of. When estimating very early, the uncertainty and ambiguity in exactly what you must do will make the estimates very wide. As you work to address the unknowns, you can revisit and refine the estimates to be more accurate.
However, it's also essential to consider the nature of software development. People don't often know what they want until they start using it. That means any requirements that you get up-front will be missing key requirements as well as have extraneous requirements. The values and principles of Agile Software Development and Lean Software Development address these characteristics of software development.
I'm doing an academic assignment where I need to estimate how long it would take to develop a website for a delivery service company. The website should have features like user login, map integration and notifications.
OK maybe im misinterpreting you here but. You don't ask "how long will I take to make this website" or "how do I estimate the time", but "how long would it take to develop".
This is easy, phone up 10 web design companies and get quotes. Take the average within each price bracket.
The problem is that there is no set time for a set of features. If someone has done the feature before, or know of a third party library that does the feature, they will be 1000 times faster than someone working it out from scratch.
This is why the guides for developers will say to break the problem down. Because even if you haven't made a delivery website before, you have presumably made a web page, or a form or a style sheet. So you know how long those bits will take.. roughly. You will be just left with the unknowns, say the map. Which you will have to guess, but hope that the overall error has been reduced.
If you ask a company that has done ten delivery service websites before they will give you a very accurate answer.
If you add a feature eg "does the photo have a bird in it?" that they haven't a clue about how to do, even if it seems like a small feature on the surface it will be impossible to estimate.
The most accurate method is to predict the hours of patience you have with the problem. Cram your effort into that window and, regardless of the state of the app, declare it's done when it's due.
That may seem reckless but if the deadline is important this is what you do. Make development choices based on hitting the deadline, not on features. Don't cut corners. The moment it doesn't look like a feature will make the deadline say so. This allows reprioritizing when reality hits.
The moment a feature can be demonstrated do so. Find out if this is headed the right way as soon as you can.
Many people still think estimating is about the problem. It's not. Never has been. It's about how long you have to work on it. After that it's some one else's problem. Give me an hour to build you a shelf and you get the kind of shelf I can build in an hour.
When you work this way, the art is in accurately describing what such a shelf is going to look like. And knowing when to walk away from building a sub par shelf.
First, make sure you understand the difference between an estimate and a guess. An estimate is a range (sometimes implicit or assumed,) and guess is a scalar value.
Second, you'll want to make sure you are differentiating between 'accuracy and precision.' The practical implications of these terms can differ between fields and contexts, but I think this commonly used image is a good illustration at a high level:
These two concepts are often confused. Note the top two dart-board images are both 'accurate' but the one on the right is values that miss the target.
In order to judge the accuracy of an estimate, you need to define your precision. For example, if I am asked to estimate someone's height, here are two possible estimates:
The person's true height is measured to be 1.866 meters. Estimate 1 is accurate but not precise. Estimate 2 is precise but inaccurate.
To sum up, the simple (or simplistic) answer to 'how make an estimate more accurate' is to reduce the precision. The usefulness of an estimate is generally reduced if the precision is extremely low. But before you start with an estimate, figure out what level of precision is required and what level of precision you can manage. If those don't align, you likely don't have enough information.
Otherwise, a good way to start is picking some broad upper and lower bounds. Then repeatedly narrow them until you start to lack confidence in either. At that point you are around your limits of precision.
As candied_orange said, because you can't estimate the time, the work, and the hours per work unit, just give a time estimate and adjust what you deliver accordingly. Another method is refusing any work outside this job if you seem to run out of time. If your boss insists on hitting a deadline, then reports, team meetings etc. suddenly get very secondary.
There is a good technique to estimate the time while work is being done, making the estimate better over time. Split the work into many subtasks. Enter all the subtasks together with an estimate into a spreadsheet.
Then you enter the actual time for each subtask, as it is finished. With a bit of maths, your spreadsheet can compare your estimates vs. actual times, make a guess that the ratios stays the same, make an improved guess how long each subtask, and with that how long the complete task takes.
The problem is that these form a couple of technical functions to develop. Normally one would do a little research, try to realize the basics of a function / feature, guess a relative complexity number and continue.
At the end you get a list of weighted functions. Though maybe not completely implemented (=weighted) as prototype.
At first you need to realize a full build pipeline so you always have an application in initial stage. This might be the first feature on your list.
Now you have all means to guess times, and during progress have an Excel/Calc sheet with % progress. Ensure you have a time diagram with dated progress, which points to a calculated end date.
While working do it pragmatically. Sufficient crude features to make things work. Do not forget smart things, intelligent pieces of code, but maybe not immediately. Normally one has periods of intensive work and periods of taking some breath. Use the latter to beautify spots.
Note that if one functions takes more time than expected (say single-log-on), you may work out-of-order, use dummy implementation to work later steps.
Maybe you might get info on other academic assignments. Try it with saying you made a list, inventory of story points ("agile programming") and ask their estimate ranges.
