When software defect is found by customers, it is reported to Service Desk and handled as an Incident (Fault). How about defects found during development? Are they handled by Incident Management, Problem Management or other process? Or Project Management? In other words, they are outside IT Service Management.

Defects found during development are nothing to do with service management because a program (or anything else) in development is not providing a service.

If you develop programs, you will have a development regime that controls how you perform your development function._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

ITIL is about service management. Essentially, Service Management assumes that software has been developed. Service Management becomes concerned with software when there is a proposal to introduce it into service. Then it has to be validated as to function, reliability, robustness, operability, compatibility, performance, etc.

Software development, on the other hand, (seeing this future validation ahead of it) has to be designed and tested to address these points if it is to succeed.

From the Service Management point of view, in-house software is much like bought-in software. However it would be prudent to create links with the in-house development function to help ensure the fitness of the software products without going through costly iterations, and without costly accommodations by the infrastructure for example.

In other words it is good to develop integrations within the organization, but the processes for control during development have to be appropriately designed for that purpose and should not impinge on Service Management which has its own role in the real world.

This is not to say that the same software might not be useful (although I would expect software designed for the purpose would normally be a better bet), just that you would use a separate instance and you would not use Service Management staff to manage the processes.

When Service Management staff are at the coal face doing their day to day job, they care not a jot about what is going on in development and in fact the development department is probably one of their customers in terms of keeping their servers and networks running._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

Stuff found and fixed during development stays outside Incident and Problem Mgmt. After all, these ITSM processes focus on IT services in production, not on development or test.

However, there is one thing to keep in mind. Often, new or enhanced systems go live while the project that built it knows that there are some issues. The pressure to deliver on time is big and a few (not too major) errors here and there are then often foregiven. When these known issues make it into production, I would advise to track them through Problem Mgmt, either as a problem record (to drive investigation) or as a known error (if the root cause is already known). Any available workarounds should be documented along with these problems and known errors.

Doing this provides Incident Mgmt with visibility into all problems and known errors with their workarounds in the environment. Incidents triggered by these problems/known errors can be properly associated and resolved by using the workarounds. This approach also facilitates the hand-off from a development project to a standing maintenance organization._________________Manager of Problem Management
Fortune 100 Company
ITIL Certified

How does the development/issues live/incidents boundary apply to customers partaking in early adopter (aka beta II) testing? Does the 'service' start as soon as they receive software from you, or only when it is launched in their live environment?

Regardless of where the testing / qa / development defects is found...it is still development / testing and outside of Problem mgmt (operations) and inside in Software development lifec cycle_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

How does the development/issues live/incidents boundary apply to customers partaking in early adopter (aka beta II) testing? Does the 'service' start as soon as they receive software from you, or only when it is launched in their live environment?

You build appropriate early adopter protocols specific to your project.

Whether and how these integrate or parallel your service protocols is absolutely down to specific cases and has to be fully planned and managed involving all parties affected._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718