Usability is just a measure of how usable a product is. If you involve your user from the beginning of your software engineering process, then you have a higher chance of succesfully emphasizing usability of the product that you are creating. If you want to ensure that you're going to make a product that will fully meet your user's wants, needs, and aspirations, you want to use a user-centered design process, and you'll need to involve your user from product inception through to completion. If you want to use a user-centered design process, usability testing is but one method that you should use during the process to ensure that you're meeting both your users' needs and your business goals.
Early on, as you're defining what the project is, you should be doing formative user research: interviewing users, conducting an ethnography, job shadowing, diary studies, surveys, and other methods. This allows you to determine what the user actually needs, wants, and aspires to, and how your product will fit into that. Remember: your user doesn't want your product. The user wants to do something, and your product will enable them to do it (or do it better, or do it faster, or in some other way make an improvement over what they're doing now).
After you've defined what the project is and what the scope is, you should continue to conduct user research to ensure that you're meeting your stated user goals and business goals. You can conduct research using paper prototypes of your product, which will help you understand whether the workflows that you have designed are ones that make sense to your users. You can do card sort exercises to ensure that you're grouping related items together in your user interface. Card sorts and paper prototypes are also good points to identify whether you've got terminology issues. All of this is done before the UI code is worked on, because you want to make sure that you've got a solid starting point before the coding starts.
In the early phases of your project, you should use your user research and your product knowledge to determine understand which workflows depend on other workflows. This will help you make decisions about what to cut when that time inevitably comes. If a workflow is of top priority, but depends on the successful completion of a lower-priority workflow, you can use that knowledge when you're making cuts. For example, let's say you have five workflows, W1, W2, W3, W4, W5, listed in priority order. If being able to complete W1 depends on the successful completion of W4, you're more likely to cut W3 than W4 because you need W4 for W1.
After you've got a good understanding of the workflows, you can continue to conduct user research with prototypes of varying fidelity. The lower the fidelity of the prototype, the more feedback you get on its workflow and how the user sees the product fitting into their life. The higher the fidelity of the prototype, the more the user will focus on the look and feel of the user experience, and less on the workflow. Both of these are important, but you want to make sure that you get the workflow right before you get the pixels right. Having the most awesome icons ever won't help if your workflows don't meet your users' needs.
As your code comes together, you should conduct usability studies to ensure that users can complete specific tasks using your code, and you can make updates. If you've been conducting user research all along, you're less likely to get blindsided at this point by a user being entirely confused by what you've created. As more and more code is written and you get closer and closer to your deadline, it gets harder and harder to make major changes. You're limited to small tweaks.
And finally, when your code is all done, you should conduct a final study: a baseline usability study that goes through the most important workflows to determine how well you met your user goals. You can use this to form the basis of the work that you'll do in the next version of your product.
