In a plan-driven methodology, where you have the complete requirements up-front, a complete project would satisfy all of the requirements and pass the specified unit, integration, system, and acceptance tests. In a perfect world, the project would end at the end of the plan. However, the health of the project should be tracked as part of the plan, allowing for insight into health and status so that a project that is exceeding cost/time allowed can be cancelled early.
In an iterative and incremental methodology, you often end every iteration with a potentially shippable product, which includes all of the software and associated documentation that is required. The project could end under a number of circumstances - you run out of requirements to ship, you run out of money, the customer ends the project if the cost of a future iteration is less than the earned value, or so on.
You don't want to estimate a percentage of completion, as you can only measure against known requirements, as it doesn't account for unknown requirements or defective requirements. Instead, you want to measure project completion against measurements such as completed requirements, percentage of passing tests (especially acceptance tests), and earned value - these will give a general health/status of the project, regardless of the methodology used.
Depending on your specific methodology, there are a number of measurements and metrics that you might be interested in. A few examples include earned value, velocity, requirements churn (changed requirements/unit of time), defect reports, cost (compare actual to budgeted at each phase of the project), effort, and progress (actual completed tasks vs scheduled completed tasks).
