190 likes | 315 Views
Lecture nr 9: Dynamic documentation. TDT4285 Planlegging og drift av IT-systemer Spring 2011 Anders Christensen, IDI. Om du ønsker, kan du sette inn navn, tittel på foredraget, o.l. her. Prosjekt, rutiner og drift. 3rd line. With error. Project. Map. Map’. Large change. Collection
E N D
Lecture nr 9: Dynamic documentation TDT4285 Planlegging og drift av IT-systemer Spring 2011 Anders Christensen, IDI TDT4285 Planl&drift IT-syst Om du ønsker, kan du sette inn navn, tittel på foredraget, o.l. her.
Prosjekt, rutiner og drift 3rd line With error Project Map Map’ Large change Collection of routeins Correction Error situation Routinesr Error correction Large change 2nd line 1st line Terrain Operation Changes within the same map TDT4285 Planl&drift IT-syst
Base-line Change ctrl form Initial work plan Test on test system Review of client Review of manager Review of collegues Backup-out-strategy Test on preprod.sys Final work plan Training Revision of rôles and responsibilities Implementation Change Mgmt Checklist TDT4285 Planl&drift IT-syst
Workflow for CCF Baseline CCF Work plan v1 Taining Test on Test system Customer review Rôles Work plan v2 Management review Test on preprod. Resonsibility Work plan v3 Review among collegues Implementation TDT4285 Planl&drift IT-syst
Baseline (static) dok • Must have a defined baseline in order to plan structured and managed changes. • All needs for changes to the baseline must be identified and handled in advance • When the change is implemented, the documentation is updated, too. TDT4285 Planl&drift IT-syst
The baseline • Server configuration • Software list • Rôles and responsibilities • Sketches of network etc • Installation procedures and logs • Standard operating procedures (SOP) • Change Control Form (CCF) • Backup plans • Disaster recovery plans • Test scripts TDT4285 Planl&drift IT-syst
Change Control Form Customer/user focus: description of: • Implications • Rationale for the change • Overview over implementation To be used in decisions and reviews: • In the customers organisation • In your own organisation • Among the technicians TDT4285 Planl&drift IT-syst
CCF – contents (I) • Definition of problem – why is it that we want to perform this change? What is its purpose? • Description of solution – very briefly, how is this change to be implemented in order to meet the specified problem. • Scope of changes – who and what are effected by these changes, what will the down time be (if any) TDT4285 Planl&drift IT-syst
CCF – contents (II) • Project team – who is part of the team implementing this change, and what are their tasks. • Complexity – how difficult is the change, how many other things may be disturbed by the change. • Impact of not makeing the change – what are the consequences if the change is not implemented? TDT4285 Planl&drift IT-syst
CCF – contents (III) • Estimated downtime – for how long must which machines be partly or completely unavailable, and which services are affected. • Priority– how important is this change, and how should it be evaluated against other changes. TDT4285 Planl&drift IT-syst
CCF contents (IV) • Revalidation plan – how is the system verified that it is working again after the change? • Backout plan – how do one back out of the change if it is impossible to complete the change sucessfully? • Status – how far in the process is this change? TDT4285 Planl&drift IT-syst
CCF – innhold (V) • Notes – various other information, comments, footnotes and warnings related to the process, which do not fit in elsewhere. • Accompanying documentation – list of references to other documentation which may be relevant for this change. TDT4285 Planl&drift IT-syst
CCF Innhold (VI) • Procedure – stepwise list of the implementation of this change, but not in details. Details are written in the work plan, but the translation from this point to a work plan should be nearly self evident. • First step – first sub-step during installation • Second step ... • Third step ... TDT4285 Planl&drift IT-syst
CCF – contents (VII) • Test plan – do you test the new functionality. This plan contains the test scripts that later might be included into the baseline • Notes on implementasjon – technical notes. • Administrative information – like dates, signatures, version numbers etc. TDT4285 Planl&drift IT-syst
Work plan A detailed, stepwise list of actions that make up the change, and which will be the complete recipe for the change. Refined in several versions and tested on a test or preproduction system. Differs from the procedure in the CCF, which is an overall description intended as a basis for management decisions. The work plan is used by techniciens for the actual work. TDT4285 Planl&drift IT-syst
Testing System where the software can be installed for testing in order to find most potential problems, and where the sysadms can train themselves. Development Test system Pre-production System which closely resembles the actual production system, except that critical tasks are not dependant on the pre-production system. Production TDT4285 Planl&drift IT-syst
Formal methods for project mgmt and system administration Basically: ”anything goes” ... but: • .... most projects are small with few participants • .... most projects are interspersed among other work • .... most formal methods are for development, not for system administration • .... some sort of iterative or adaptive methods may suite the task and the people well TDT4285 Planl&drift IT-syst
How to sabotage project mgmt (or what to look out for!) • Claim the change is trivial to avoid project mgmt • Ignore it, produce a fait accompli, in secrecy and hope for forgiveness • Postpone until the deadlines makes the managers so desperate that they accept ’anything’ • Do a shadow project that follow the ’right’ methods, but in parallel you do the real project as you like. • Overplay all the possibilities for red tape in the project method in order to prove its uselessness TDT4285 Planl&drift IT-syst
Possible traps during implementation • Change of goals • Lack of parallelization of subtasks • Lack of information to all concerned parties • Dependencies on persons in stead of dependencies on rôles. • Ad hoc short-cut due to lack of time in a process that used to be structured • One person fills too many rôles TDT4285 Planl&drift IT-syst