Under årens lopp har jag blivit säker på min förmåga att uppskatta programkostnader och scheman. Jag antar att ett sådant förtroende kommer till oss i branschen som har utvecklat hundratals uppskattningar. Vi har naturligtvis infört mogna processer, mätmetoder och uppskattande modeller för att åstadkomma denna bedrift på ett disciplinerat och repeterbart sätt. Vi har investerat i datainsamling och justerat processerna, förfinat mätvärdena och kalibrerat modellerna för att uppnå våra mål för förutsägbarhet och kontroll. Under de senaste månaderna har jag hittat ett sätt att bli av med min självsäkerhet. Det var enkelt; jag försökte uppskatta kostnaden och schemat för en webbutveckling. Utvecklare verkar generera programvara för webben med hjälp av hypertext markup språk (html), Java applets/script och visuella programmeringsspråk i en blixt av ett öga. Sådana projekt besegrar mina processer, trotsar mina modeller och gör mina storleksmått föråldrade. De genererar och gör tusentals webbobjekt operativa under perioder på bara några månader. När vi går till webben och omfamnar e-handel affärsmodeller, hur bedömer vi kostnaderna och tidtabellerna för programvaruprojektet? Hur undersöker vi brytpunkterna och rättfärdigar de investeringar som krävs för att föra in det pris som kommer från den elektroniska handeln? Viktigare, hur anpassar vi våra befintliga processer, storleksmått och modeller och får dem att fungera? Fokus i detta dokument är att ge svar på dessa frågor. Jag märkte en banner på min webbplats som meddelade att förra året elektronisk handel nådde $ 3 miljarder i försäljning förra året. Det är en fantastisk prestation. Men i goda nyheter finns det också dåliga nyheter. Och den dåliga nyheten är att rubriken förebådar en förändring av hur vi går tillväga för att utveckla programvara. Tabell 1 sammanfattar dessa förändringar. Det belyser övergången till komponentbaserad mjukvaruutveckling, systematisk återanvändning och visuell teknik. Den identifierar ett steg mot en snabb utveckling. Istället för att utveckla programvara från krav via vattenfallet, dessa moderna webbutvecklingsprojekt lim byggstenar och återanvändbara komponenter tillsammans med hjälp av snabba tillämpning utvecklingsmetoder och kontinuerlig prototyper. Du kommer också att märka att webbutvecklingen verkar bristfällig inom områdena process och uppskattning. Det beror på att drivkraften att flytta till webben är ny och teknik som Software Engineering Institutes Capability Maturity Model (CMM) 3 har inte anpassats för att ta itu med sådana projekt. Inom området uppskattning kommer du också att märka att Software Line Of Code (SLOC) och funktionspunkt uppskatta modeller som COCOMO 4, PRIS-S 5, SLIM 6 och SEER 7 är de viktigaste verktygen som används för traditionell utveckling. Orsakerna till detta är enkla och inkluderar: § Den fenomenologi som förknippas med utveckling och de parametrar som driver kostnader har studerats ingående, § Estimering modeller som tar hänsyn till denna fenomenologi har d utlopp, valideras och kommersialiseras under en period av 20+ år, och § Modellerna har kalibrerats med hjälp av historiska data för att exakt förutsäga kostnad och schema. § Processer som införlivar modellerna i de planerings- och kontrollprocesser som företag använder för att hantera sin verksamhet har utvecklats, förfinats och optimerats.
Reifer REF föreslår webbobjektens storleksmått och en anpassning av COCOMO II-uppskattningsmodellen WebMo för att uppskatta ansträngningen och varaktigheten för webbapplikationer.
Development: Estimating Quick–to-Market Software
{'venue': 'IEEE Software', 'journal': None, 'mag_field_of_study': ['Computer Science']}