<Desc/Clms Page number 1>
Werkwijze voor een tijdsraming voor softwareontwikkeling.
De uitvinding heeft betrekking op een werkwijze voor een tijdsraming, meer bepaald een raming van de tijd nodig voor het ontwikkelen van een softwareproject.
Bij het ontwikkelen van software is het zeer moeilijk om op voorhand de tijd te schatten die deze ontwikkeling in beslag zal nemen. Uiteraard is met het oog op de planning en het bepalen van de prijs van de ontwikkeling een tijdsraming onontbeerlijk.
De uitvinding heeft een werkwijze voor het ramen van de tijd nodig voor het ontwikkelen van een softwareproject als doel die eenvoudig is en een goede schatting toelaat.
Dit doel wordt volgens de uitvinding bereikt doordat parameterpunten worden toegekend aan één of meer gegevensverzamelingen en/of functies van het project, beïnvloedingspunten worden toegekend aan één of meer factoren die dit project beïnvloeden, uit deze parameterpunten en beïnvloedingspunten productiviteitspunten worden berekend, waaruit dan door omzetting, en eventuele bijsturing, de tijdsraming berekend wordt.
Bij voorkeur worden parameterpunten toegekend aan alle logische gegevensverzamelingen gebruikt in het totale project van de softwareontwikkeling, worden parameterpunten toegekend aan alle onderhoudsfuncties gebruikt in dit project, worden parameterpunten toegekend aan uitvoer- en opvragingsfuncties gebruikt in dit project, worden beïnvloedingspunten toegekend aan elke factor van een reeks beïnvloedingsfactoren van het project, productiviteits-
<Desc/Clms Page number 2>
punten worden berekend door middel van een formule waarin voornoemde beïnvloedingspunten en parameterpunten zijn opgenomen,
deze productiviteitspunten omgezet worden in een voorlopige tijdsraming afhankelijk van de ontwikkelingsomgeving van de software en tenslotte een totale raming berekend wordt van de tijd nodig voor het ontwikkelen van software door de voornoemde voorlopige tijdsraming procentueel te verhogen in een aantal welbepaalde gevallen.
Verder kan de totale schatting van de tijd vervolgens worden verdeeld over de verschillende fasen die zullen worden doorlopen bij het project van de softwareontwikkeling.
Met het inzicht de kenmerken van de uitvinding beter aan te tonen is hierna, als voorbeeld zonder enig beperkend karakter, een voorkeurdragende uitvoeringsvorm beschreven van een werkwijze volgens de uitvinding.
Voor het ramen van de tijd nodig voor een project van softwareontwikkeling volgens de uitvinding worden parameterpunten toegekend aan alle logische gegevensverzamelingen.
Logische gegevensverzamelingen zijn bestanden die allerlei gegevens bevatten, bijvoorbeeld over klanten of facturen.
Bij het bepalen van parameterpunten voor deze logische gegevensverzamelingen dient het logische datamodel waarin elk van de logische gegevensverzamelingen is opgenomen in de derde normaalvorm, volgens Codd, te zijn uitgewerkt.
Iedere logische gegevensverzameling die in het logische datamodel is opgenomen, wordt bepaald, met uitzondering van
<Desc/Clms Page number 3>
eventuele indexbestanden en werkbestanden maar met inbegrip van code-tabellen.
Vervolgens wordt voor iedere logische gegevensverzameling, gebruikt bij het ontwikkelen van de software, het aantal velden en het aantal recordtypen geteld. Indien het aantal velden nog onbekend is, wordt een gemiddeld aantal vooropgesteld.
Dan kan voor elke logische gegevensverzameling het aantal parameterpunten worden bepaald volgens onderstaande tabel.
EMI3.1
<tb>
<tb>
Aantal <SEP> recordtypen <SEP> Aantal <SEP> velden
<tb> 1-25 <SEP> 25-49 <SEP> > 49
<tb> 1 <SEP> E <SEP> E <SEP> G
<tb> 2-5 <SEP> E <SEP> G <SEP> M
<tb> > 5 <SEP> G <SEP> M <SEP> M
<tb>
In de tabel komt de letter"E" (Eenvoudig) overeen met acht parameterpunten ; de letter"G" (Gemiddeld) met elf parameterpunten en de letter "M" (Moeilijk) met vijftien parameterpunten.
De som PLG van de parameterpunten van alle logische gegevensverzamelingen wordt gemaakt.
Parameterpunten worden ook toegekend aan onderhoudsfuncties die in het project gebruikt worden.
Een onderhoudsfunctie is een functie voor het bewerken van een logische gegevensverzameling, zoals het aanmaken van gegevens, het wijzigen van gegevens of het verwijderen van gegevens.
<Desc/Clms Page number 4>
Bij het toekennen van parameterpunten aan deze onderhoudsfuncties worden eerst alle onderhoudsfuncties van de logische gegevensverzamelingen bepaald.
Hierbij worden "aanmaken", "wijzigen" en "verwijderen" als drie afzonderlijke functies beschouwd. Een opvraging, zoals het op naam onderzoeken van een klantenbestand, wordt niet als onderhoudsfunctie maar als opvraagfunctie beschouwd, zoals verder wordt verduidelijkt.
Bij iedere logische gegevensverzameling hoort minstens één onderhoudsfunctie. Het feit dat binnen één onderhoudsfunctie meerdere schermen worden doorlopen, is niet van belang voor het aantal functies.
Per onderhoudsfunctie wordt het aantal gegevensverzamelingen die door deze functie kunnen worden bewerkt, geteld en ook het totaal aantal velden die door deze functie kunnen worden gewijzigd. Een veld dat enkel kan worden geraadpleegd en niet kan worden gewijzigd, wordt dus niet geteld.
Dan kan voor elke onderhoudsfunctie het aantal parameterpunten worden bepaald volgens onderstaande tabel.
EMI4.1
<tb>
<tb>
Aantal <SEP> Aantal <SEP> velden
<tb> gegevensverzamelingen <SEP> 1-6 <SEP> 7-19 <SEP> > 19
<tb> 1 <SEP> E <SEP> E <SEP> G
<tb> 2 <SEP> E <SEP> G <SEP> M
<tb> > 2 <SEP> G <SEP> M <SEP> M
<tb>
In de tabel komt de letter"E" (Eenvoudig) overeen met vier parameterpunten ; de letter"G" (Gemiddeld) met vijf
<Desc/Clms Page number 5>
parameterpunten en de letter "M" (Moeilijk) met zes parameterpunten.
De som PO van de parameterpunten van alle onderhoudsfuncties wordt gemaakt.
Verder worden parameters voor uitvoerfuncties en opvragingsfuncties bepaald.
Uitvoerfuncties en opvragingsfuncties omvatten alle vormen van weergave van de gegevens uit de logische gegevensverzamelingen zonder dat deze gegevens kunnen aangepast worden.
Opgavemogelijkheden van selectiecriteria worden eveneens als dergelijke functies beschouwd.
Elke van de uitvoerfuncties en opvragingsfuncties wordt onderscheiden van een andere dergelijke functie door haar lay-out of door haar werking.
Indien bij een bepaalde uitvoer- of opvragingsfunctie enkel de volgorde van de gegevens uit een verzameling verschillend is van de volgorde bij een andere functie, gaat het over dezelfde functie.
Evenals bij de onderhoudsfuncties is het aantal schermen, die bij een uitvoerfunctie of bij een opvragingsfunctie worden doorlopen, niet van belang.
In principe hoort bij iedere logische gegevensverzameling minstens één uitvoer- of opvragingsfunctie.
<Desc/Clms Page number 6>
Per uitvoer- of opvragingsfunctie wordt het aantal gegevensverzamelingen waarin deze functie kan worden gebruikt, geteld en ook het totaal aantal velden die door deze functie kunnen worden geleverd, de velden die het resultaat zijn van een verwerking of berekening inbegrepen.
Dan kan voor elke uitvoer- of opvragingsfunctie het aantal parameterpunten worden bepaald volgens onderstaande tabel.
EMI6.1
<tb>
<tb>
Aantal <SEP> Aantal <SEP> velden
<tb> gegevensverzamelingen <SEP> 1-7 <SEP> 8-22 <SEP> > 22
<tb> 1 <SEP> E <SEP> E <SEP> G
<tb> 2-3 <SEP> E <SEP> G <SEP> M
<tb> > 3 <SEP> G <SEP> M <SEP> M
<tb>
In de tabel komt de letter"E" (Eenvoudig) overeen met vijf parameterpunten ; de letter "G" (Gemiddeld) met zes parameterpunten en de letter "M" (Moeilijk) met zeven parameterpunten.
De som P, j.. van de parameterpunten van alle uitvoer- en opvragingsfuncties wordt gemaakt.
Uiteindelijk worden voornoemde sommen samengeteld :
EMI6.2
p = p + p + p Totaal Benevens voornoemde parameterpunten worden ook pLG + p0 + p U & 0beïnvloedingspunten toegekend aan beïnvloedingsfactoren in functie van hun moeilijkheidsgraad.
Onder beïnvloedingsfactoren worden allerlei problemen verstaan die kunnen optreden tijdens de ontwikkeling van de
<Desc/Clms Page number 7>
software en bijgevolg een invloed kunnen uitoefenen op de duur van deze ontwikkeling.
De beïnvloedingsfactoren waar in de werkwijze volgens de uitvinding een waardering aan wordt toegekend, zijn de volgende : de problematiek met betrekking tot datacommunicatie, gedistribueerde gegevensverwerking, prestatiedoeleinden (namelijk response-of doorlooptijden), beperkingen van het uiteindelijke productiesysteem, transactievolume (aantal te verwerken transacties per tijdseenheid), on line data-entry, gebruikersdoelmatigheid (verhoging van de efficiëntie), het on line updaten van de logische gegevensverzamelingen, een complexe interne verwerking, het hergebruiken van de code, het installatiegemak en de conversie van gegevens, het bedieningsgemak (bijvoorbeeld een automatisering van de back-up, recovery, et cetera),
meerdere locaties/organisaties en tenslotte met betrekking tot de flexibiliteit (de werking is beïnvloedbaar door de gebruikers).
Al deze beïnvloedingsfactoren worden gewaardeerd aan de hand van de volgende beinvloedingspunten : nul punten indien de problematiek niet van toepassing is, twee punten indien de problematiek eenvoudig van aard is, zes punten indien de problematiek een gemiddelde moeilijkheidsgraad heeft en tien punten indien de problematiek moeilijk van aard is.
Evenals van de parameterpunten, wordt ook een som B gemaakt van alle beïnvloedingspunten.
In een volgende stap worden productiviteitspunten berekend aan de hand van de volgende formule :
EMI7.1
productiviteitspunten = ( B + 65) x 1/100) x P lotaal
<Desc/Clms Page number 8>
(0, 5waarbij B de som is van de beïnv10edingspunten en totaal de som is van alle parameterpunten (PTotaal = PLG + PO+PU & O).
Deze productiviteitspunten worden vervolgens omgezet naar een tijd Tvoorlopig afhankelijk van de ontwikkelingsomgeving, bijvoorbeeld de gebruikte programmeertaal.
Bij 3GL's (third Generation Languages) zoals COBOL, PLI, enzovoort, worden 4 uren per productiviteitspunt toegekend, bij 4GL's (fourth Generation Languages) zoals POWERBUILDER, enzovoort, worden 2 uren per productiviteitspunt toegekend en bij integrated casetools en generatoren dient slechts
EMI8.1
één uur per productiviteitspunt te worden gerekend.
De tijd in deze stap werd verkregen, wordt
T 10'dietenslotte nog verhoogd met de volgende percentages in de volgende gevallen.
+ 20 % indien de medewerkers aan het project minder dan de gemiddelde ervaring bezitten ; + 20 % indien een nieuwe werkwijze wordt gebruikt waarmee nog weinig of geen ervaring is ; + 20 % indien nieuwe technieken worden gebruikt waarmee nog weinig of geen ervaring is ; + 10 % indien bij het project meer dan een gemiddeld risico wordt gelopen ; + 5 % indien de levering van een gebruikershandleiding is inbegrepen in het project ; + 5 % indien de levering van een productiehandleiding is inbegrepen in het project.
Op deze wijze wordt de raming Trami verkregen van de tijd die nodig is voor het ontwikkelen van een software.
<Desc/Clms Page number 9>
De verkregen uren worden eventueel omgezet in dagen van een aantal uren, bijvoorbeeld 7, 6 uren.
De raming T raming van de tijd kan verdeeld worden over de verschillende fasen van het softwareontwikkelingsproject.
EMI9.1
Voor activiteitenanalyse en het ontwerpen van het basisprototype van de software" wordt 25 % van de tijd Traming geraamd; voor "de ontwikkeling en het testen raming van de software" wordt 50 % van de tijd Tramping geraamd raming en voor "de invoering en de overdracht" wordt nog eens 25 % van de tijd Teaming geraamd. raming Indien in een volgende fase een verdere detaillering van de behoeftebepaling van het project wordt uitgevoerd, wordt nog eens 7 % aan de verkregen raming Trami toegevoegd.
Indien deze zijn inbegrepen in het softwareontwikkelingsproject worden nog eens 10 % voor projectmanagement en 5 % voor kwaliteitscontroles en reviews bijgeteld bij Traming. raming Deze werkwijze laat een vrij nauwkeurige raming van de tijd nodig voor de ontwikkeling van het project toe.
Het is duidelijk dat de uitvinding geenszins beperkt is tot de hoger beschreven uitvoering doch dat zulke werkwijze in allerlei uitvoeringen kan worden verwezenlijkt zonder buiten het kader van de uitvinding te treden.
<Desc / Clms Page number 1>
Method for a time estimate for software development.
The invention relates to a method for a time estimate, in particular an estimate of the time required for the development of a software project.
When developing software, it is very difficult to estimate in advance the time that this development will take. Naturally, a time estimate is indispensable with a view to planning and determining the price of the development.
The invention requires a time estimation method for developing a software project as an objective that is simple and allows good estimation.
This object is achieved according to the invention in that parameter points are assigned to one or more data sets and / or functions of the project, influence points are assigned to one or more factors influencing this project, productivity points are calculated from these parameter points and influence points, from which then conversion , and any adjustments, the time estimate is calculated.
Preferably, parameter points are assigned to all logical data sets used in the overall software development project, parameter points are assigned to all maintenance functions used in this project, parameter points are assigned to output and query functions used in this project, influence points are assigned to each factor of a range of factors influencing the project, productivity
<Desc / Clms Page number 2>
points are calculated using a formula that includes the above influence points and parameter points,
these productivity points are converted into a preliminary time estimate depending on the development environment of the software and finally an overall estimate is calculated of the time required for software development by increasing the aforementioned preliminary time estimate in a number of well-defined cases.
Furthermore, the total estimate of the time can then be divided over the different phases that will be completed in the software development project.
With the insight to better demonstrate the features of the invention, a preferred embodiment of a method according to the invention is described below, by way of example without any limiting character.
To estimate the time required for a software development project according to the invention, parameter points are assigned to all logical data sets.
Logical data collections are files that contain all kinds of data, for example about customers or invoices.
When determining parameter points for these logical data sets, the logical data model in which each of the logical data sets is included in the third normal form, according to Codd, must be elaborated.
Each logical data set included in the logical data model is determined, with the exception of
<Desc / Clms Page number 3>
any index files and working files but including code tables.
Then, for each logical data set used in developing the software, the number of fields and the number of record types are counted. If the number of fields is still unknown, an average number is assumed.
Then, for each logical data set, the number of parameter points can be determined according to the table below.
EMI3.1
<tb>
<tb>
Number of <SEP> record types <SEP> Number of <SEP> fields
<tb> 1-25 <SEP> 25-49 <SEP>> 49
<tb> 1 <SEP> E <SEP> E <SEP> G
<tb> 2-5 <SEP> E <SEP> G <SEP> M
<tb>> 5 <SEP> G <SEP> M <SEP> M
<tb>
In the table, the letter "E" (Simple) corresponds to eight parameter points; the letter "G" (Medium) with eleven parameter points and the letter "M" (Difficult) with fifteen parameter points.
The sum PLG of the parameter points of all logical data sets is made.
Parameter points are also assigned to maintenance functions used in the project.
A maintenance function is a function for editing a logical data set, such as creating data, modifying data or deleting data.
<Desc / Clms Page number 4>
When assigning parameter points to these maintenance functions, all maintenance functions of the logical data sets are first determined.
Here "create", "modify" and "delete" are considered three separate functions. A query, such as examining a customer file by name, is not regarded as a maintenance function but as a query function, as further explained.
At least one maintenance function is associated with each logical data set. The fact that multiple screens are run through within one maintenance function is not important for the number of functions.
For each maintenance function, the number of data sets that can be edited by this function is counted, as well as the total number of fields that can be changed by this function. A field that can only be consulted and cannot be changed is therefore not counted.
The number of parameter points can then be determined for each maintenance function in accordance with the table below.
EMI4.1
<tb>
<tb>
Number of <SEP> Number of <SEP> fields
<tb> data sets <SEP> 1-6 <SEP> 7-19 <SEP>> 19
<tb> 1 <SEP> E <SEP> E <SEP> G
<tb> 2 <SEP> E <SEP> G <SEP> M
<tb>> 2 <SEP> G <SEP> M <SEP> M
<tb>
In the table, the letter "E" (Simple) corresponds to four parameter points; the letter "G" (Average) with five
<Desc / Clms Page number 5>
parameter points and the letter "M" (Difficult) with six parameter points.
The sum PO of the parameter points of all maintenance functions is made.
In addition, parameters for output functions and query functions are determined.
Output functions and query functions include all forms of displaying the data from the logical data sets without this data being editable.
Specification options for selection criteria are also considered to be such functions.
Each of the output functions and query functions is distinguished from another such function by its layout or by its operation.
If, for a given output or query function, only the order of the data from a set is different from the order for another function, then it is the same function.
As with the maintenance functions, the number of screens that are run through an output function or an inquiry function is not important.
In principle, every logical data set has at least one output or query function.
<Desc / Clms Page number 6>
For each output or query function, the number of data sets in which this function can be used is counted, as well as the total number of fields that can be provided by this function, including fields resulting from a processing or calculation.
Then, for each output or query function, the number of parameter points can be determined according to the table below.
EMI6.1
<tb>
<tb>
Number of <SEP> Number of <SEP> fields
<tb> data sets <SEP> 1-7 <SEP> 8-22 <SEP>> 22
<tb> 1 <SEP> E <SEP> E <SEP> G
<tb> 2-3 <SEP> E <SEP> G <SEP> M
<tb>> 3 <SEP> G <SEP> M <SEP> M
<tb>
In the table, the letter "E" (Simple) corresponds to five parameter points; the letter "G" (Medium) with six parameter points and the letter "M" (Difficult) with seven parameter points.
The sum P, j .. of the parameter points of all output and query functions is made.
Ultimately, the aforementioned sums are added together:
EMI6.2
p = p + p + p Total In addition to the aforementioned parameter points, pLG + p0 + p U & 0 influence points are also assigned to influencing factors according to their degree of difficulty.
Influencing factors include all kinds of problems that can arise during the development of the
<Desc / Clms Page number 7>
software and therefore be able to influence the duration of this development.
The influencing factors that are valued in the method according to the invention are the following: the problems with regard to data communication, distributed data processing, performance purposes (namely response or lead times), limitations of the final production system, transaction volume (number of transactions to be processed). per unit of time), online data entry, user efficiency (increasing efficiency), online updating of logical data collections, complex internal processing, reusing the code, ease of installation and conversion of data, ease of operation (e.g. an automation of the backup, recovery, etc.),
multiple locations / organizations and finally with regard to flexibility (the operation can be influenced by the users).
All these influencing factors are valued on the basis of the following influence points: zero points if the problem is not applicable, two points if the problem is simple in nature, six points if the problem has an average degree of difficulty and ten points if the problem is difficult to nature.
As well as the parameter points, a sum B is also made of all influence points.
In a next step, productivity points are calculated using the following formula:
EMI7.1
productivity points = (B + 65) x 1/100) x P lotal
<Desc / Clms Page number 8>
(0.5, where B is the sum of the influence points and total is the sum of all parameter points (PTotal = PLG + PO + PU & O).
These productivity points are then converted to a time T for the time being depending on the development environment, for example the programming language used.
3GLs (third Generation Languages) such as COBOL, PLI, etc., allocate 4 hours per productivity point, 4GLs (fourth Generation Languages) such as POWERBUILDER, etc., allocate 2 hours per productivity point and integrated case tools and generators only
EMI8.1
one hour per productivity point.
The time obtained in this step is
Finally, T 10 would be increased by the following percentages in the following cases.
+ 20% if the employees on the project have less than the average experience; + 20% if a new working method is used with which there is little or no experience; + 20% if new techniques are used with little or no experience; + 10% if the project involves more than an average risk; + 5% if the delivery of a user manual is included in the project; + 5% if the delivery of a production manual is included in the project.
In this way, the Trami estimate of the time required to develop a software is obtained.
<Desc / Clms Page number 9>
The hours obtained are optionally converted into days of a number of hours, for example, 7.6 hours.
The estimate T estimate of the time can be divided over the different phases of the software development project.
EMI9.1
For activity analysis and designing the basic prototype of the software, "Traming is estimated 25% of the time; for" the software development and testing estimate ", Tramping is estimated 50% of the time and for" the introduction and transfer "Teaming is estimated another 25% of the time. Estimation If further detailing of the project's needs is carried out in a subsequent phase, a further 7% is added to the Trami estimate obtained.
If included in the software development project, a further 10% for project management and 5% for quality controls and reviews are added to Traming. estimate This method allows a fairly accurate estimate of the time required for the development of the project.
It is clear that the invention is by no means limited to the above-described embodiment, but that such a method can be implemented in all kinds of embodiments without departing from the scope of the invention.