The way that I was taught, there is a clear difference between the two.
A software process model is an abstract representation of a process methodology. Waterfall1 is a process model. Iterative methodologies are process models. They don't specify how to do things, but outline the types of things that are done and sequencing for things. For example, Waterfall identifies the phases that a project goes through - requirements, design, implementation/unit testing, integration testing, system testing, deployment - without saying what artifacts to produce or what tools to use (although the output of code is implied). Agile defines core values in the form of the Manifesto for Agile Software Development, time-boxed iterations, and continuous response to change, but it doesn't say how long your iterations should be or how you go about responding to change. The Spiral model is a third software process model.
A software process methodology is a specific way of conducting a software project. These are things like the Rational Unified Process and Scrum. They define exactly what, when, and/or how various artifacts are produced. They might not be entirely explicit with all regards - for example, Scrum doesn't identify what documents to produce or not to produce, since it's focus is on delivering value to the customer - but they define, in some way, the actions that members of the project team must deliver.
However, in actuality, the point is often moot. Many times, process methodologies are presented as frameworks in which you tailor to the needs of your customer and development team, based on requirements and resources. On top of this, organizations might deal with regulatory or legal guidelines that dictate certain aspects of what must be produced or how to go about performing certain tasks (especially related to verification and validation activities).
It frequently becomes more important to discuss each team or organization's process in terms of plan-driven versus agile or amount of formality and ceremony. Discussing the terminology difference between a "process model" and a "process methodology" is mostly useful during academic discussions of process models.
1 I'm referring to the traditionally taught Waterfall, not the more explicitly defined Waterfall in Winston Royce's paper.
Best Answer
Yes this is just a term that is thrown around by management types but if you strip away the management language what he's saying is that he wants a department that is seen as using and embodying industry best practices in a way that others aspire to and is doing so to deliver great solutions people like.
(This last bit is important - if you're not actually delivering it doesn't matter how great everything else is and your manager won't be around long).
The complexity comes in two main ways:
1) Does he want this because he understands that it's the right way to develop software and that this is how you produce great products, or does he want it because he wants to be able to brag about it?
2) Will he accept the up front cost (time, money, credibility and risk) that comes with implementing best practice? It's fine to say "let's go agile" but he's laying his reputation on the line that it will improve things and is going to have to spend a lot of time selling it into the organisation. Almost always the benefits are long term, the costs are short term and that's the tough bit. Ultimately is he really serious about it?
In terms of what would it look like, well, that depends what you're doing but you need to be thinking in terms of what your development and project management processes are, what tools you're using, what kit people have and so on. The Joel Test is always a good place to start and in particular I'd want to see a really solid version control process, really good bug tracking and really good build processes.
I'd also look at whether agile methodologies are right for you (SCRUM in particular), to what extent automated testing could help (without starting a religious war there are differing beliefs about the point at which the complexity of the tests outweighs the benefits they provide) whether you've got the necessary tools and kit to do the job. Generally I'd suggest that you want tools to be on the leading but not bleeding edge. It's worth stressing that this isn't about having toys, it's about giving everyone in the team the tools to be as productive as possible for as much of the working day as possible. The most obvious example is bad PCs - is it really excellent to pay developers to watch a cursor while their project takes 5 minutes to build when they build it half a dozen times a day?
A few other things that are probably going to be visible in a centre of excellence: I'd suggest a software centre of excellence has likely got a pretty good training programme - maybe not formal courses but certainly book budgets, study time, mentoring and the like.
And I'd suggest that it's probably also doing a small amount (at least) of R&D. By that I don't mean completely blue sky stuff, but giving the developers room to try new things out and evaluate new tools and languages without the continual pressure of delivery to the client. That's how you move forward and stay good next year, the year after and so on.
How can you measure it? Ah, the age old question. Ultimately measuring software development is hard, if not impossible and measuring excellence in software development is similarly hard.
The only thing I can really suggest that I think would be useful that is widely adopted by a lot of companies is customer and staff satisfaction. It's an indirect measurement but my take would be that if you're not excellent, it's unlikely that you'd be getting really great levels of customer satisfaction and really great levels of staff satisfaction.