ENGLISH ABSTRACT: Most people working in the software industry recognise that developing software to predictable schedules is risky and not easy. They experience problems to estimate how long the development of software will take. Underestimation leads to under staffing and setting too short a schedule. That in turn leads to staff burnout, low quality and missed deadlines. Overestimation can be almost as bad: Parkinson's Law that work expands to fill available time comes into action, which means the project will take as long as estimated even if overestimated. Currently people do no put in much effort to estimate jobs and therefore projects take as long as they take. Methods to manage uncertainty lead to putting in excessive safety and then wasting it. Business usually presents a target for the project with tremendous pressure for low 'estimates' during the bidding process and in the end this target becomes the plan. Best practice appears to manage the gap between this target and the estimate as a risk on the project. Without an efficient work breakdown structure (WBS) one cannot accurately estimate. Subject experts should help the project manager to plan the detail of how the work should be done. A functional design by a systems architect helps to break down the technical tasks. This is very important because omitted tasks will not be estimated for. The first step towards sound estimates is to estimate the size. This is extremely difficult at the initial phase but can be overcome if the company store history of size and completion time in a repository. Although lines of code are most often used as a size measure, function points or function blocks appear to be better, especially for the initial estimate. If an organisation has not kept historic data, now is the time to start doing it. The suggested procedure to follow before starting to gather information, is to define what is going to be kept (the norms), to delimit the defined data, to discipline the collection, to deposit it in an established repository and to deliver it in readily usable format. The tool used for storing these metrics must provide building in factors that influence effort like complexity, skills level, elapsed time, staff turnover, etc. There are many different techniques for estimation. The best option seems to use a combination of estimates and include developer opinion and a mathematical method like function point analysis. Estimation of software development, like all other work processes, need management control and this is called metrics management. This process includes establishing some kind of modeL Empirical models, based on a database with data stored by ones own company, give the best results. Two very good models are the Putnam model and the Parr model (for smaller projects). Even the best model and process is never perfect. Therefore the estimation process must be continuously monitored by comparing actual duration times to estimates. Be careful with feedback on how accurate estimates were. No feedback is the worst response. Carefully discussing the implications of underestimation and putting heads together to solve the problem appears to be the best solution. / AFRIKAANSE OPSOMMING: Die meeste mense in die sagteware industrie erken dat om sagteware te ontwikkel teen voorspelbare tydskedules, gevaar inhou en nie maklik is nie. Hulle ondervind probleme om te skat hoe lank die ontwikkeling van sagteware hulle gaan neem. Onderskatting lei tot te min hulpbronne en te kort skedules. Dit veroorsaak uitbrand van mense, lae kwaliteit en einddatums wat nie gehaal word nie. Oorskatting is byna net so erg. Parkinson se Wet dat werk geskep word om beskikbare tyd te vul, kom in aksie en aan die einde beteken dit die projek neem so lank as wat geskat is, selfs al is dit oorskat. Huidiglik doen mense nie veel moeite om tyd te skat op take nie en daarom neem projekte so lank as wat dit neem om te voltooi. Metodes om onsekerheid te bestuur lei tot die byvoeg van oormatige veiligheidstyd net om dit daarna weer te verkwis. Die besigheid verskaf gewoonlik 'n mikpunt vir die projek met geweldige druk vir lae skattings tydens bieery en op die ou end raak hierdie mikpunt die projekplan. Die beste manier om dit die hoof te bied is om die gaping tussen hierdie mikpunt en die skatting te bestuur as 'n projek risiko. Niemand kan akkuraat skat sonder 'n effektiewe metode van werk afbreek nie. Vakkundiges behoort die projekbestuurder te help om die detail van hoe die werk gedoen gaan word, te beplan. 'n Funksionele ontwerp deur 'n stelselsargitek help om die tegniese take verder af te breek. Dit is baie belangrik aangesien take wat uitgelaat word, nie in die skatting ingesluit gaan word nie. Die eerste stap om by gesonde skattings uit te kom, is om grootte te skat. Dit is besonder moeilik in die aanvanklike fase, dog kan oorkom word indien die maatskappy geskiedenis stoor van hoe groot voltooide take was en hoe lank dit geneem het. Alhoewel Iyne kodering die mees algemeenste vorm van meting van grootte is, Iyk dit asof funksie punte of funksie blokke beter werk, veral by die aanvanklike skatting. Indien 'n organisasie nie historiese data stoor nie, is dit nou die tyd om daarmee te begin. Die voorgestelde prosedure om te volg voordat informasie gestoor word, is om te definieer wat gestoor gaan word (norme te bepaal), om die data af te baken, dissipline toe te pas by die insameling, dit te stoor in 'n gevestigde databasis en dit beskikbaar te stel in bruikbare formaat. Die instrument wat gebruik word om hierdie syfers te stoor moet voorsiening maak vir die inbou van faktore wat produksie beinvloed, soos kompleksiteit, vlak van vaardigheid, verstreke tyd, personeel omset, ens. Daar bestaan menige verskillende tegnieke vir skatting. Die beste opsie blyk 'n kombinasie van skattings te wees. Die opinie van die programmeur asook een wiskundige metode soos funksie punt analise, behoort deel te wees hiervan. Soos alle ander werksprosesse, moet skattings vir sagteware ontwikkeling ook bestuur word en dit word metrieke bestuur genoem. Hierdie proses behels dat daar besluit moet word op een of ander model. Empiriese modelle gebaseer op 'n databasis waarin data gestoor word deur die maatskappy self, gee die beste resultate. Twee baie goeie modelle is die Putnam model en die Parr model (vir kleiner projekte). Selfs die beste model en proses is egter nooit perfek nie. Die estimasie proses moet dus voortdurend gemonitor word deur werklike tye met geskatte tye te vergelyk. Wees versigtig met terugvoer aangaande hoe akkuraat skattings was. Geen terugvoer is die ergste oortreding. Die beste oplossing skyn te wees om die implikasie van die onderskatting met die persoon wat die skatting gedoen het, te bespreek en koppe bymekaar te sit om die probleem op te los.
| Identifer | oai:union.ndltd.org:netd.ac.za/oai:union.ndltd.org:sun/oai:scholar.sun.ac.za:10019.1/4652 |
| Date | 12 1900 |
| Creators | Bannister, H. C. |
| Contributors | Brown, C. J., University of Stellenbosch. Faculty of Economic and Management Sciences. Graduate School of Business. |
| Publisher | Stellenbosch : University of Stellenbosch |
| Source Sets | South African National ETD Portal |
| Language | en_ZA |
| Detected Language | Unknown |
| Type | Thesis |
| Rights | University of Stellenbosch |
Page generated in 0.0024 seconds