Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Jan 23, 2006 Posts: 13 Location: San Francisco, CA
Posted: Thu Nov 09, 2006 1:36 am Post subject: FSC vs. FSR
What is the difference between the Forward Schedule of Change and the Forward Schedule of Release other than the amount of detail that goes into the FSR? How do you keep them synchronized? What level of detail to you go into for each?
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Thu Nov 09, 2006 10:51 pm Post subject:
Hi Debbie,
There really is no difference.
A Product, is made up of one or more Release versions. Each Release gets deployed (or "released") to a target environment, as it moves forward, toward the Production environment. A FSR is to schedule the deployment of a "Release" into a specific environment.
A Release is made up of one or more Changes, where the Changes define everything that has been or will be modified by the Release. Sometimes, rather than deploying an entire Release, it makes sense to deploy one or more Changes that are a subset of the Release. A FSC helps to schedule "Changes" to their targeted environments.
NOTE: ITIL, who is all about not re-inventing the wheel, re-invented the terminology for Release in a way that it is ambiguous to how Developers, Engineers and Architects, since they see a Release as a "group of changes that define a new version of a product." Release Management is one of the areas where ITIL is a big vague and inconsisten, and even contradicts other best practices that have been established long before ITIL. We've found that if you try to implement ITIL Release Management in an enterprise, there will almost immediately be contention with how product design and development resources work.
Anyhow, I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
Joined: Jan 23, 2006 Posts: 13 Location: San Francisco, CA
Posted: Tue Nov 14, 2006 1:45 am Post subject: FSC VS FSR
Hi Frank,
Thanks for the feedback. I guess it boils down to who you are talking with. From the ITIL trianing I have received I can't recall anything regarding the FSR...it was always the FSC. However, in talking with others ITIL'ers, I have started to hear more on the FSR and wanted to make sure that I wasn't missing anything. So basically they are the same thing and should be treated as such??
personally I think that Release Management in ITIL is described as bit of an underdog, and they're not going into great detail about it. In real life it's never so clear-cut, and most of the companies use some kind of a development methodology like SDLC. The main difference as I see it is the timespan of a release and a change, and not every change will go through the change management. For example replacing a disk in a server is a change, but not a release. Nevertheless you need to overlay the FSC and FSR to know that you cannot replace that disk on the planned date because a release might go live just on that exact date. It's actually an ISO/IEC 20000 requirement as well.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Nov 14, 2006 1:54 pm Post subject:
Hi Debbie,
The concept of a "Release" is very weak and almost broken in ITIL.
Traditionally, creating a new "Release" means creating a new version of product that you will take to market (or ultimately to your production environment).
ITIL redefined it to be more along the lines of a "deployment" of the product and now seems to conflict with what Release means in SDLC, RUP, etc. This, in my opinion, is an example of where ITIL actually is part of the problem and not the solution.
Also, by defining a Release to be what it is, in ITIL, the definers have missed a very critical point: "A Release is composed of one or more Changes". ITIL makes the "Change" the primary unit of deployment and this is very inconsistent with what software developers and engineers are taught, as they are taught that a Release is the primary unit of deployment.
If you teach your infrastructure teams to define "Release" the way ITIL does, then you will automatically introduce conflict, as you will be going against everything your development and engineering teams have been taught. This means your infrastructure teams will be speaking a different language than your development and engineering teams. Not good...
I personally recommend you go with the RUP/MSF/SDLC/etc. definitions of a Release. They're more universally accepted and there is a very high probability that they are already in place in your enterprise, as most developers will already speak that language. Therefore, a FSR is nothing more than a calendar/schedule of "Releases", which include one or more Changes per Release.
Anyhow, I hope this helps.
Best Regards, _________________ [Edited by Admin to remove link]
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum