Dear All, I have enclosed a real email in which a Project Manager describes a methodology for an information system project. Since I am planning to be associated with this company, I really care about it but I am a little confused. I have been doing a lot of research/reading on OOA&D and methodology (RUP, XP), and although I do not possess much *experience* in this cutting edge stuff, I feel I have a good grasp on the basic principles (I switched to software development 6 months ago). Please read the following excerpt and give your comments or ask any questions, especially with regard to the following: 1. Is this OOAD? If not, why is OOAD better than Structured D.? 2. Is this use-case driven development? 3. Is this Iterative development? 4. How does this fit into the philosopy of RUP and XP? 5. Anything else? Hassan ***********************************************************
It was agreed that with the "Generic Specifications document" provided by *someone* there is no need for detailed info about the UI screens any more. So we will work on Ph-2 and as and when we need any clarification - we will seek it from the on-site team. As for the methodology for Ph-2 to Ph-5, instead of 'completing' each screen of the six screens in a series, here is what we have been doing so far; 1. You are aware that the generalized architecture for the back end divide each of the back end functions into 5 components - descriptor, model, manager, controller and view, we will call it a 'set' in this e-mail. 2. For each component in the 'set', *someone* has designed a template (similar to the one sent to you for UI components) 3. Each screen has it's unique functional requirements and thus each screen has different numbers of descriptors, models, views, managers and one controller. *someone* has prepared a list of the required components for all the six screens in Ph-2. A total of 74 components are identified for the back end functions of Ph-2 screens. 4. For each item in the list, relevant template is filled by *someone* and handed over to a programmer (a part of the team called the code factory), he is instructed on how to use the template to generate the code for that component - this makes the code generation an almost mechanical process requiring minimal thinking or guessing on part of the programmer. 5. Once a 'set' is complete for a specific function of a screen - integrators take over and integrate and test the back end for that function. 6. In the meantime - as more templates are filled by the technical leads, programmers continue to generate more components. Working in the same manner (whenever possible) we will build components for the front end thru our code factory and finally integrate the back end and front end to complete the screens. We see several advantages of working in this manner, major one being that all the available resources are utilized efficiently in parallel (experienced people doing important work such as *someone* designing the templates, technical leads filling the templates, checking the code and integrating the components while relatively inexperienced programmers 'the code factory' doing the bulk of the coding). As we progress into this project, the code factory will become more productive and reliable requiring little or no guidance and minimal rework. We also hope to groom a few more integrators from the team and thus will be able to generate more work for the code factory and check the code produced by them improving overall efficiency of the team. In parallel, we are also exploring the possibilities of writing 'code generating / checking' programs from these templates.
We cannot change unless we survive, but we will not survive unless we change. Evolving tiny ad:
Devious Experiments for a Truly Passive Greenhouse!