IMHO, they are
Some people call this "specification", but if the developers aren't working with the specifiers, misunderstandings and incomplete specifications are guaranteed. "Dry interfaces" without prototypes (UI mock-ups, back-of-the-envelope feasibility tests) are pointless whenever there are any unknowns. The real user expectations are always unknown. Standards are often unknowns, especially when they are new.
Most people differentiate this phase into "design" and "coding". IMHO, this is not possible, as design without coding is moot (such a design is just a different form of specification).
Often called tuning, but IMHO still part of the (micro-) design. The need for optimization is a consequence of design decisions (each design will create different bottlenecks), and improving the performance means modifying the algorithms.
The test phase is something different from the debugging phase, and it would be best if the testers are different people. Programmers don't believe in the presence of bugs, testers expect them.
Once a buggy behaviour is found, the buggy code has to be found, and the buggy algorithm that caused it redesigned.
At a user's site, everything is different: the hardware, the software, the data, the user behaviour ("interaction profile"). Of course there will be bugs found during this phase, and often they will be specification bugs (aka, misunderstandings resulting in unwanted features).
After the first installation, there will be more. Existing installations will be ported to new hardware; machines will be struck by lightning and destruct data sets, new year and February 28, 2000 will come and go.
New revisions of the program will be written, coexisting with old data sets and old versions on other sites. Competitors will write new programs that can use our data sets, or that generate data sets that our programs can use.