Below is my own view of things. It is based on my experience as someone who worked in a company that had a successful SDLC long time ago. Funny, I left another large company, because their miss-use of SDLC! I can't say that all what is here is currently valid in today's methodologies and techniques though.
Conceptually SDLC is a set of consistent and integrated processes to deliver a product. The primary goals of a methodology are to:
1 - Define work phases and deliverable so that project management becomes possible.
2 - Define a conceptual platform that the organization could enhance as it grows up using industry best practices.
3 - Stop the organization from re-inventing the wheel with every project by identifying inputs and outputs of each task/stage
4 - Minimize the state of chaos in the development process minimize the dependency on a single or a specific set of people in the organization to know everything - This is achieved by good documentation and involving different levels in the process
5 - Enhances the communication among the product development, management and other parties in the organization by establishing a set of agreed terms, KPIs and tools of communication.
The SDLC achieves its goals by utilizing the best suitable practices and tools at each of its processes.
Setting up/choosing an SDLC is not trivial and performing SDLC tasks is valuable.
UML is not SDLC and vice versa. UML is one of the tools that may be adopted by a given SDLC for producing software products but then again it might not. You will not find too many Mainframe CICS developers using UML for example.
as per your point:
Blockquote
For example, will a domain class diagram, an not anything extra (from design class), be strictly the output from Analysis or Discovery phase? I'm sure many times you will think a bit about the technical implementation too? Else you might end up with a design class diagram later that is very different from the original domain class diagram?
Blockquote
You are correct in some of this. A domain mdoel is not necessarily a design model. The difference between the two is that a domain model (called different things depending on the methodology you use) is supposed to collect important facts and rules for business during the business analysis stage. The concept of an object in analysis is very wide. The objective of such a model would be to store the collected information in a form that can be used by the designers. It is usually built by analysts so if the two class diagrams look similar, then either the subject is trivial, or has one solution only. The objectives of the technical model is different. It inherits the rules, data and business objectives from the analysis model but shapes it toward code generation, specific database requirements, and performance. It is completed by software engineers and not analysts. As a result it is different. For example a Customer Number may be a good key for Customer Enitty in analysis, but in the database it ends to be implemented as a column with unique index and a sequence number is used instead. It is also not uncommon to see the customer class converted to an abstract class and different types of customers get their own classes (or vice versa)!
Regarding your question:
I also find it hard to remember what diagrams are from Initiation,
Discovery, Design etc etc. Plus these phases vary from SDLC to SDLC, I
believe? So I usually will create a diagram when I think will be
useful. Is it the wrong way?
The methodology should define the stages of the development process and which diagrams should be produced by which professionals and which tools to be used for doing this.
For example, should analysis sessions include prototyped web pages? A prototyped web page is definitely not a UML diagram! In general, you need to define and refine your:
Use Case Diagrams
Class Diagrams
Activity Diagrams
State-Machine Diagrams
Each of the above diagrams have a purpose. If you study the purposes well, it will be clear to you when to use it.
and don't forget your Data Model diagram (ERD) - But ERD is not part of UML. Again, UML is not enough, at least, almost always it is not enough. You need integrated tools and a methodology and above all people to get the work done right.
So, you create a diagram when it is useful, that is OK but if you are working in a team with a methodology you need to follow that and don't forget to allocate time for it in a project plan too.
At the end of all this, please distinguish between SDLC, UML, Project Management - They are different things (at least to me!).
Good luck.