So in programming there is the concept of product development and how to manage it's life cycle. The one I'm more or less doing is SDLC. It divides up the project into a couple of phases. This is important, good programmers don't just "write stuff" when a customer asks them to do something. They actually fix a problem or even better prevent one. The life cycle is how to identify what steps to take and get a decent chance of succeeding. IS departments don't have a great track record of this because a lot of programmers where taught syntax instead of development. Ok, bored.
1 The preliminary phase (wouldn't it be cool if I knew if the print serverr was hung up so I could reboot it?)
2 The analysis phase (Is it feasible?->is it worth doing->how do we do it to a *very* fine level. This should be down to writing and providing a flow chart. (easy enough, monitor it and if it stops responding email myself an alert).
3 Development phase (turning the logic and flowchart into objects and actions and then the objects and actions into actual reliable and fully functional code - query the box and if it does not respond in x seconds reboot it - no I'm not going to write a script to do that, there is already a framework* that does 95% of this for me).
4 Implementation phase (set it up with identified and managed dependancies, make sure it's able to handle a working load and is actually functional for the user).
5 Audit and maint - watch to make sure it remains functional and provide updates (is it running? Does it meet efficiency metrics (some apps make sense if they require a big frigging box, some make sense if you can run them as a 5 minute cronjob, some neither, figure out the right metric) and can it be improved (instead of mailing me can the job reboot the server for me and only THEN mail me if it does not come up?
1 The preliminary phase (wouldn't it be cool if I knew if the print serverr was hung up so I could reboot it?)
2 The analysis phase (Is it feasible?->is it worth doing->how do we do it to a *very* fine level. This should be down to writing and providing a flow chart. (easy enough, monitor it and if it stops responding email myself an alert).
3 Development phase (turning the logic and flowchart into objects and actions and then the objects and actions into actual reliable and fully functional code - query the box and if it does not respond in x seconds reboot it - no I'm not going to write a script to do that, there is already a framework* that does 95% of this for me).
4 Implementation phase (set it up with identified and managed dependancies, make sure it's able to handle a working load and is actually functional for the user).
5 Audit and maint - watch to make sure it remains functional and provide updates (is it running? Does it meet efficiency metrics (some apps make sense if they require a big frigging box, some make sense if you can run them as a 5 minute cronjob, some neither, figure out the right metric) and can it be improved (instead of mailing me can the job reboot the server for me and only THEN mail me if it does not come up?
No comments:
Post a Comment