Appendix A - Requirement Types
Requirements Requirement Types
Make flight reservations for our customers with all the major air carriers
High-level Business
Available 99% of the time Functional or Non-Functional
Make a flight reservation User
The system must support remote users Functional
Confirm Reservation User
The system must provide HTML links to car rental partners (i.e., Avis, Hertz, Budget).
Functional
Functional on a variety of web browsers High-level Business Display the home page within 20 seconds after being
logged on
Non-Functional
The system must provide HTML links to hotel partners (i.e., Marriott, Hyatt, Hilton).
High-level Business
Make seat assignment User
The system must provide the ability to view the current balance of a frequent flyer account.
Functional
The system must provide the ability to issue a boarding pass
Functional
The system must include billing functionality Functional or High-level Business The system must include drop-down lists of possible
values for all coded fields, specifically the airport origin, the airport destination, and “class of service”.
Appendix B - Detailed Requirements
In a project, the customer and mortgage data have to be recorded. Therefore 2 Functional Requirements were written:
1. the system must have a data-entry functionality for customer data 2. the system must have a mortgage selection functionality.
The details of the functionalities are:
1. Customer data consists of: Name (30 char), Address (25 char), City (25 char), Email-address (40 char).
2. There is a list of mortgage types, from which a selection can be made.
So there are 2 Detailed Requirements. Now you can choose to write down the Detailed Requirements in text or to design a screen as a Detailed Requirement. In both choices the Functional Requirement must trace to the Detailed Requirement.
In the illustration both choices are shown.
Customer: -N: -A: -C: -Email…. Type mortgage: REM DSDM Prototype Functional Requirement:
1. the system must have a data-entry functionality for customer data
Customer data consists of: Name (30 char), Address (25 char), City (25 char), Email-address (40 char) and have be entered in a screen.
There is a list of mortgage types, from which a selection can be made through a drop down list.
Ma rke ting Eve nt (*) Be gin Da te End Da te Be gin Time End Time Eve nt Na me Co s t Type
Ma rke ting ID (id1)
Re gis tra tio n (*) Entry D a te P a yme nt Da te S ta tus Cha rge d Amount La s t Upd a te Time P a id Ind Re gis tra tio n Type S e le ct Re c Ind Type
Re gis tra tio n Nbr (id 1)
Conta ct (*) Co mpa ny Na me (id1) Firs t Na me (id1) La s t Na me (id1) Middle Na me (id 1) Te le pho ne Nb r Fa x Nbr Bus ine s s Title Lo ca tion ID S ta te Te le pho ne Exte n Die t Typ e Na m e S uffix P e rs ona l Title Confirma tion (*)
Co nfirma tio n Nbr (id1)
Co nfirma tio n Da te P re s e nta tion (*) As s ig nme nt (*) Vis ua ls (*) ha s (*) is for ha s (*) is for ha s (*) is fo r ha s (*) is for ha s (*) is for us e s (*) a re us e d b y
2. the system must have a mortgage selection functionality.
Appendix C – Requirements categorisation
Group Requirement Type
1. Functional : High-Level Business Requirement
User Requirement Interface Requirement Functional Requirement 2. Non-Functional : Quality
Attributes:
Functionality: Correctness Requirement Completeness Requirement Security Requirement Timeliness Requirement Usability: User-friendliness Requirement
Availability Requirement Suitability Requirement Usability Requirement Reliability: Reliability Requirement
Resilience Requirement Recovery Requirement Degradation Requirement Transfer Requirement Performance: Speed Requirement
Economy Requirement Supportability: Testability Requirement
Maintainability Requirement Portability Requirement Manageability Requirement
Other: Conversion Requirement
Hardware Requirement Compliance Requirement
Appendix D - Traceability
User Requirement
The customer must have the ability to purchase fuel with a credit card. Use Case
Name: Purchase fuel with a credit card
Actor: Customer, system
Description: Purchase fuel is the ability to buy fuel at the pump using a credit card Pre-conditions: Card payment method has been selected Fuel pump in working order Post-conditions: Fuel has been dispensed Payment has been accepted
Normal course: 1. Customer selects to pay with creditcard 2. System requests credit card information 3. Customer provides credit card information 4. System validates credit card information 5. System requests fuel type selection 6. Customer selects fuel type
7. System dispenses fuel 8. System prints receipt 9. Customer takes receipt
Customer actions System Responses
1. Select pay with creditcard
2. Request credit card information 3. Provide credit card information
4. Validate credit card information 5. Request fuel type selection 6. Select fuel type
7. Dispense fuel 8. Print receipt 9. Take receipt
Interface requirements Functional requirements
Traceability User requirement
The customer must have the ability to purchase fuel with a credit card.
Interface requirement Functional requirement 1. Select pay with creditcard
2. Request credit card information 3. Provide credit card information
6. Select fuel type
7. Dispense fuel 8. Print receipt 9. Take receipt
Appendix E – ATR Classification IT
Geldt voor alle classificaties en methoden NZ Nazorg
PL Project management
PR Productie Dit is een milestone (Hierop kunnen geen uren worden geboekt.) DV Budget depot Hierop kunnen geen uren worden geboekt.
Preparation/Project proposal DSD FS Feasibility Study
BS Business Study
ASP SU Start Up/Project Voorbereiding BB Business Blueprint
Internally developed application software (IDAS) DSD FM Functional Model (Iteratie)
DB Design & Build (Iteratie) ST Systeem Test
FA Functionele Acceptance (test) PA Productionele Acceptance (test) IP Implementatie
ASP RE Realisatie ST Systeem Test
FA Functionele Acceptance (test) PA Productionele Acceptance (test)
Externally developed application software (EDAS) DSD FM Functional Model (Iteratie)
DB Design & Build (Iteratie) Ook interne uren tbv ondersteuning van de externe partij. ST Systeem Test Ook interne uren tbv ondersteuning van de externe partij. FA Functionele Acceptance (test)
PA Productionele Acceptance (test) IP Implementatie
ASP RE Realisatie Ook interne uren tbv ondersteuning van de externe partij. ST Systeem Test Ook interne uren tbv ondersteuning van de externe partij. FA Functionele Acceptance (test)
Package Implementation (PI)
DSD FM Functional Model (Iteratie) Ook interne uren tbv ontwikkeling AAB software (bijv. interfaces) DB Design & Build (Iteratie) Ook interne uren tbv ontwikkeling AAB software (bijv. interfaces) ST Systeem Test Ook interne uren tbv ontwikkeling AAB software (bijv. interfaces) FA Functionele Acceptance (test)
PA Productionele Acceptance (test) IP Implementatie
ASP RE Realisatie Ook interne uren tbv ontwikkeling AAB software (bijv. interfaces) ST Systeem Test Ook interne uren tbv ontwikkeling AAB software (bijv. interfaces) FA Functionele Acceptance (test)
PA Productionele Acceptance (test)
Infrastructure
DSD MD (Functional) Model en Design (& Build iteration) Dit is een combinatie van FM en DB . ST Systeem Test
FA Functionele Acceptance (test) PA Productionele Acceptance (test) IP Implementatie
Organisational
DSD FM Functional Model (Iteratie) DB Design & Build (Iteratie) ST Systeem Test
FA Functionele Acceptance (test) PA Productionele Acceptance (test) IP Implementatie
Administrative NDM AL Algemeen
Budget reservation
NDM -- Niet van toepassing. Er zullen geen uren op dit deelproject geboekt worden.
Research
NDM AL Algemeen
Other
Geadviseerde activiteiten per fase
Fase Activiteit / ATR code
Beschrijving Commentaar
AL AL General Miscellaneous activiteiten
BB BB Business Blueprint 2Q Qualiteits controle
BS BS Business Study Alleen voor ‘Preparation/Project proposal’ deelprojecten 3Q Qualiteits controle
HS Herstart
3R Rework
DB DB Design & Build Iteratie
B1 .. B9 Design & Build Iteratie nr. 1 .. 9 Voor elk 200 – 400 uren 5Q Qualiteits controle
5R Rework
EC Exploitatie Componenten FA FA Functionele Acceptance Test
7F Functioneel Acceptatie Test gedurende FM fase 7D Functionele Acceptatie Test gedurende DB fase 7Q Qualiteits controle
7R Rework
FM FM Functionele Modelleer Iteratie
F1 .. F9 Functionele Modelleer Iteratie nr 1 .. 9 Voor elk 200 – 400 uren 4Q Qualiteits controle
4R Rework
FP FP Final Preparation 4Q Qualiteits controle
FS FS Feasibility Study Alleen voor ‘Preparation/Project proposal’ deelprojecten IP IP Implementatie
9Q Qualiteits controle
9R Rework
MD MD (Functioneel) Model en Design (& Build iteratie) Dit is een combinatie van FM en DB.
Alleen te gebruiken door “Infrastructure”
NZ NZ Nazorg
PA PA Productionele Acceptatie Test
8F Productionele Acceptatie Test gedurrende FM fase 8D Productionele Acceptatie Test gedurende DB fase 8Q Qualiteits controle
8R Rework
PL PL Project Management Lopende activiteit
QA Quality Assurance Alleen PQAL uren kunnen hierop geboekt worden. PI Process Improvement
CM Configuration Management EV Post Project Evaluation
SC Subcontract Management Optioneel
SL Service Level Management Optioneel
ID Idle Time
Fase Activiteit / ATR code
Beschrijving Commentaar
3Q Qualiteits controle ST ST Systeem Test
S1 .. S9 Systeem Test van Functie Blok 1 .. 9 Voor elk 200 – 400 uren 6Q Qualiteits controle
6R Rework
6A Additioneel Werk Niet voor DSD
6F Systeem Test gedurende FM fase 6D Systeem Test gedurende DB fase SU SU Start Up/Project Voorbereiding
Appendix F – Role Requirements Engineer
Specifiek benodigde kennis• De business en relevante applicatiedomeinen, gericht op de eisen (wet- en regelgeving) en wensen binnen de organisatie (G)
• De ICT ontwikkelingen binnen de BU NL, businessarchitectuur en de ICT (on) mogelijkheden (U)
• De ontwikkelingen in de markt m.b.t. het eigen kennisgebied (U)
• De ontwikkelingen in de markt m.b.t. onderwerpen waarop het project zich richt (G) • Praktische kennis van de theorie en praktijk van requirements engineering (D) • Praktische kennis van prototyping (G)
• Praktische kennis van de door ABN AMRO gekozen tool voor requirements engineering and management (U)
• Requirements Engineering technieken (D), zoals o Context Diagramming
o Use Case Modeling
o Business Process Modeling (volgens IDEF) o Logical Data Modeling
o Risk Analysis (G) o Requirements Definition o Requirements Decomposition
• UML technieken zoals Object Modeling en Class Modeling (G) • De ergonomische aspecten van systemen (U)
• De Engelse taal (D)
• De impact van de “Engelse dialecten” Indiaas-Engels en Amerikaans-Engels (G)
G = Globale kennis (kennen van de grote lijnen, feiten met geen of nauwelijks onderlinge samenhang) U = Uitgebreide kennis (meer details, feiten en hun achtergronden, gegevens en feiten in onderlinge samenhang)
D = Diepgaande kennis (kennen van alle ins en outs, dwarsverbanden) Benodigde vaardigheden
• Interview-technieken
• Faciliteren/participeren in “facilitated sessions” • Use Case Analysis
Specifieke gedragscompetenties • Probleemanalyse • Overtuigingskracht • Oordeelsvorming • Kwaliteitsgerichtheid • Resultaatgerichtheid • Sensitiviteit • Creativiteit • Luisteren Communicatie
• Is gesprekspartner van de ICT Retained organisatie inzake mogelijke oplossingen.
Bijzonderheden van de rol, als die gespeeld wordt in projecten.
Specifieke resultaten en kernactiviteiten
• Voert een businessstudie uit, waarin analyse van businessprocessen, informatiestromen, werkorganisatie en samenwerkingsverbanden betrokken worden om een Prioritised Requirements List (PRL) samen te stellen.
• Stemt af met de opdrachtgever over mogelijke oplossingen en vertaalt de wensen van de opdrachtgever naar business requirements.
• Verzorgt een dusdanige detaillering van de business requirements dat deze geschikt zijn voor het functioneel ontwerp.
• Vertaalt high-level requirements naar detail requirements en relateert de requirements aan business doelstellingen, business strategy en de business management agenda.
Overige relevante informatie
• De rolhouder zal v.w.b. de invulling van de Requirements Engineering rol met name in de fasen t/m functioneel ontwerp een bijdrage leveren.
Communicatie
• Overlegt met de projectleider en andere betrokkenen over de inhoud van de taakopdracht voor een uit te voeren project, probleemanalyses en mogelijke oplossingen voor problemen e.d.
Bijzonderheden van de rol, als die gespeeld wordt in beheer. Specifieke resultaten en kernactiviteiten
• Ondersteunt de requirements manager bij het opstellen van een Requirements List t.b.v. projecten.
Appendix H – Definitions, descriptions, and deliverables
IntroductionIn this Appendix various aspects are described, as well as various other aspects used in the system development approach or in processes at ABN AMRO and Business Solutions.
Prioritized Requirements List
The Prioritized Requirements List (PRL) is a set of requirements ordered by type and prioritized using the MoSCoW rules. Initially (in the Feasibility Study and the Business Study), the requirements will be high-level; they will be refined and improved throughout the project. In the PRL you can determine the traceability of the requirements in system deliverables. After the Business Study the PRL will be baselined. The baselined PRL is the agreement between Business and IT and the foundation for all project planning.
Nr Finding (Defect, Suggestion, Discussion) Reviewer initials Location (Page nr, Section, Line nr) Description Severity (Major, Medium, Minor) Status (open, accepted, rejected, closed) Remarks
1 Suggestion JKO x.1.1 Suggest to add to acceptance criteria that only those accounttypes have access
Medium
2 Defect JKO x.2 The acceptance criteria does not meet the requirement. Look and Feel are not tested by merely checking if a page comes up, even if it has the expected and correct contents. Suggest to opt for a usability test
Major
3 Defect JKO x.2.1 Typo in the requirement: 'choosen' should be 'chosen' Minor
4 Suggestion JKO x.2.1 I suggest to make this requirement more generic by stating that the WOCA homepage has to support the language the user chooses in IB.
Minor
5 Defect JKO x.2.2 and x.2.3 Typo in the requirement: 'direct' should be 'directs' Minor
6 Suggestion JKO x.2.2 and x.2.3 Suggest to change the word 'proper' in both the requirement and the acceptance criteria with 'correct'
Minor
7 Suggestion JKO x.2.2 and x.2.3 Suggest to change 'left menu' in the requirement with 'left hand menu'
Minor
8 Defect JKO x.2.3 Requirement 2.3 mentions irrelevant menu options. I think that this project is not able to categorise these menu options. I therefore suggest to rephrase into, for example: ...for this process irrelevant menu options…
Major
9 Defect JKO x.2.3 This requirement consists of two requirements really: the new link and the absence of other links. However, since Req 2.2 is a Must Have requirement, the first part of this requirement, Req 2.3, is obsolete
Major
10 Suggestion JKO x.2.4 Suggest ot add to this requirement, or in a sub requirement, that managing the content of this page is is het same as managing other pages. In other words: express that the control of this page is the same as other pages
Medium
11 Defect JKO x.2.4 Typo in acceptance criteria: 'support' should be 'supports'
Minor
12 Defect JKO y.1 In the requirement is stated that there is a button. This is however a link
Minor
13 Defect JKO y.1 Acceptance criteria is incomplete. The correct error message handling is not reflected
Major
14 Suggestion JKO y.1.1 Suggest to add to the acceptance criteria that the page also should be managed
Major
15 Suggestion JKO 1.1 In the acceptance criteria, suggest to change '... can click to …' into '…access…', as it is working now
Minor
16 Defect JKO 1.1.1 Typo in the acceptance criteria: 'esented' should be 'presented'
Appendix J - project characteristics
Define Project CharacteristicsThe sign means that further explanation on the particular question is available in document [Characteristics comments.doc].
Dominant Aspect
Project Size: Results
System
PS-01 Number of requirements
PS-02 Project estimated Function Points
PS-03 Number of business processes affected
Stakeholders
PS-04 Number of stakeholders and their discipline
PS-05 Number of teamleaders
PS-06 Number of user groups affected
Configuration Items
PS-07 Configuration Items new or modified # New, Modified
PS-08 Number of new or modified databases
Other
PS-09 Number of sub-projects
PS-10 Number of sub-systems affected
Size assessment : Small/Medium/Large
Assessment justification
Project Complexity:
System
PC-01 Complexity functionality to be developed/maintained Low/Medium/High PC-03 Number of interfaces with other systems
PC-04 Use of new developing tools Yes/No
PC-05 Use of new (or change of) hardware, infrastructure, tools Yes/No
Stakeholders
PC-06 Number of stakeholder locations
PC-07 Stakeholder experience Poor/Good
PC-08 Additional stakeholder training required Yes/No
PC-09 Resources for entire project available and stable Yes/No PC-10 External obligations applicable (Interpay, DNB etc) Yes/No PC-11 External suppliers involved (subcontract management
applicable) Yes/No
Other
PS-12 Database conversion Yes/No
Complexity assessment : Low/Medium/High
Assessment justification
Project Risks
PR-01 Total number of identified risks.
PR-04 Number of Low risks identified
PR-05 Number of contingency measurements defined
Risk assessment : Low/Medium/High
Assessment justification
Project summary
Each dominant projectfactor is linked with a corresponding weightfactor by the Project Leader. The final assessment rates the project characteristics as seen by the Project Leader and results in a project classification.
Final Assessment
Dominant factor Value
Size Small/Medium/Large
Complexity Low/Medium/High
Risks Low/Medium/High
Project classification
The table below shows a number of predefined classes combinations based on size, complexity and risk, on the assumption that projectsize is the most dominat project aspect followed by complexity and risk. The selected class must be put in the last row in the table below.
For specific additional class 0 characteristics see [PM.GDL.08 - Project Tailoring Guideline.doc].
Class Size Complexity Risk
0 very small low low
1 small low low
1 small low high
2 small high low
2 small high high
2 medium low low
2 medium low high
3 medium high low
3 medium high high
3 large low low
3 large low high
3 large high Low
3 large high high
Characteristics comments
Ps-01 Requirements have different forms, depending on the project type involved, i.e. business, user and functional and nonfunctional requirements. In addition, the level of detail in iterative projects is low, while the level is high in linear projects. Specify the type of requirements involved and the detail level here.
Ps-02 If the project is larger than a half man-year, a function point analysis must be performed. Ps-04 Stakeholders include all parties involved in the project, both internal and external, e.g. internal
parties such as architects and security experts and external parties such as DNB, Interpay, etc. Note that developers are also considered stakeholders.
Ps-05 The number of team leaders is one of the elements used to indicate the size of a project. One or more team leaders are assigned to the project based on the span of control involved.
Ps-07 All components that must be created/modified, including not only source code, but also copy members, header files, JCL components, business rules and that must be transferred to production, either for the first time or anew.
Pc-04 New tools often have a (long) learning curve, which results in longer timelines for pilot projects. Bypasses must be developed for interfaces with legacy systems and for possible product limitations.
Pc-05 Cool:Gen, Java, Component Based Development, Object Orientation, etc.
Determine whether a route map has already been developed for the new product and determine what efforts are required to create procedures and guidelines for the new product. If required, submit a change request to the Advisory Committee Processes (ACP).
Pc-07 Stakeholders with inadequate knowledge and experience are a project risk and this risk must be included in the risk plan. Extra training and monitoring is required to reduce this risk.
FP U re n b u s H a n d .s e l. 3000 2500 2000 1500 1000 500 0 7000 6000 5000 4000 3000 2000 1000 0 S 1486,07 R-Sq 31,4% R-Sq(adj) 28,8%
Fitted Line Plot
Uren bus Hand.sel. = 717,9 + 1,641 FP
Appendix K – Statistical analysis
Fitted line plot compensated dataset business hours / Function points Regression Analysis: Uren bus Hand.sel. versus FP The regression equation is
Uren bus Hand.sel. = 717,9 + 1,641 FP
S = 1486,07 R-Sq = 31,4% R-Sq(adj) = 28,8% Analysis of Variance Source DF SS MS F P Regression 1 27230457 27230457 12,33 0,002 Error 27 59626709 2208397 Total 28 86857166
Fitted line plot compensated dataset business hours / Function points Minus the outlier designated in the previous plot.
Regression Analysis: Uren bus Hand.sel. versus FP The regression equation is
Uren bus Hand.sel. = 970,8 + 0,8114 FP S = 1455,01 R-Sq = 4,6% R-Sq(adj) = 0,9% Analysis of Variance Source DF SS MS F P Regression 1 2643889 2643889 1,25 0,274 Error 26 55043162 2117045 Total 27 57687051 FP U re n b u s H a n d .s e l. 1600 1400 1200 1000 800 600 400 200 0 7000 6000 5000 4000 3000 2000 1000 0 S 1455,01 R-Sq 4,6% R-Sq(adj) 0,9%
Fitted Line Plot
FP U re n b u s a u to . s e l. 3000 2500 2000 1500 1000 500 0 18000 16000 14000 12000 10000 8000 6000 4000 2000 0 S 3610,24 R-Sq 21,1% R-Sq(adj) 17,7% Fitted Line Plot
Uren bus auto. sel. = 1759 + 2,919 FP
FP U re n b u s a u to . s e l. 1400 1200 1000 800 600 400 200 0 12000 10000 8000 6000 4000 2000 0 S 2861,89 R-Sq 0,0% R-Sq(adj) 0,0%
Fitted Line Plot
Uren bus auto. sel. = 2318 + 0,108 FP
Fitted line plot automatic dataset business hours / Function points Regression Analysis: Uren bus auto. sel. versus FP
The regression equation is
Uren bus auto. sel. = 1759 + 2,919 FP
S = 3610,24 R-Sq = 21,1% R-Sq(adj) = 17,7% Analysis of Variance Source DF SS MS F P Regression 1 80146486 80146486 6,15 0,021 Error 23 299777548 13033806 Total 24 379924034
Fitted line plot automatic dataset business hours / Function points Minus the outlier designated in the previous plot.
Regression Analysis: Uren bus auto. sel. versus FP The regression equation is
FP U re n I T h a n d .s e l. 3000 2500 2000 1500 1000 500 0 4000 3000 2000 1000 0 S 538,526 R-Sq 60,6% R-Sq(adj) 59,1%
Fitted Line Plot
Uren IT hand.sel. = 282,2 + 1,085 FP U re n I T h a n d .s e l. 2500 2000 1500 1000 500 S 534,344 R-Sq 28,0% R-Sq(adj) 25,3%
Fitted Line Plot
Uren IT hand.sel. = 354,3 + 0,8406 FP
Fitted line plot compensated dataset IT hours / Function points Regression Analysis: Uren IT hand.sel. versus FP
The regression equation is
Uren IT hand.sel. = 282,2 + 1,085 FP S = 538,526 R-Sq = 60,6% R-Sq(adj) = 59,1% Analysis of Variance Source DF SS MS F P Regression 1 12040576 12040576 41,52 0,000 Error 27 7830277 290010 Total 28 19870853
Fitted line plot compensated dataset IT hours / Function points Minus the outlier designated in the previous plot.
Regression Analysis: Uren IT hand.sel. versus FP The regression equation is
FP U re n I T a u to .s e l. 3000 2500 2000 1500 1000 500 0 8000 7000 6000 5000 4000 3000 2000 1000 0 S 1633,62 R-Sq 41,3% R-Sq(adj) 39,2%
Fitted Line Plot
Uren IT auto.sel. = 870,9 + 2,227 FP re n I T a u to .s e l. 7000 6000 5000 4000 3000 S 1648,94 R-Sq 29,3% R-Sq(adj) 26,6%
Fitted Line Plot
Uren IT auto.sel. = 739,1 + 2,673 FP
Fitted line plot automatic dataset IT hours / Function points Regression Analysis: Uren IT auto.sel. versus FP The regression equation is
Uren IT auto.sel. = 870,9 + 2,227 FP S = 1633,62 R-Sq = 41,3% R-Sq(adj) = 39,2% Analysis of Variance Source DF SS MS F P Regression 1 50745337 50745337 19,01 0,000 Error 27 72055195 2668711 Total 28 122800533
Fitted line plot automatic dataset IT hours / Function points Minus the outlier designated in the previous plot.
Regression Analysis: Uren IT auto.sel. versus FP The regression equation is
Fp Total U re n F M I 1000 800 600 400 200 0 1800 1600 1400 1200 1000 800 600 400 200 0 S 220,649 R-Sq 61,8% R-Sq(adj) 60,2%
Fitted Line Plot
Uren FMI = 82,92 + 1,124 Fp Total
U re n F M I 700 600 500 400 300 200 S 156,028 R-Sq 12,2% R-Sq(adj) 8,2%
Fitted Line Plot
Uren FMI = 152,1 + 0,5302 Fp Total
Fitted line plot compensated dataset IT hours without EDAS / Function points Regression Analysis: Uren FMI versus Fp Total
The regression equation is
Uren FMI = 82,92 + 1,124 Fp Total
S = 220,649 R-Sq = 61,8% R-Sq(adj) = 60,2% Analysis of Variance Source DF SS MS F P Regression 1 1889362 1889362 38,81 0,000 Error 24 1168468 48686 Total 25 3057830
Fitted line plot compensated dataset IT hours without EDAS / Function points Minus the outlier designated in the previous plot.
Regression Analysis: Uren FMI versus Fp Total The regression equation is
Uren FMI = 152,1 + 0,5302 Fp Total
log-log regression analysis of compensated dataset IT hours without EDAS / Function points Minus the outlier designated in the pre-previous plot.
Regression Analysis: Uren FMI versus Fp Total The regression equation is
logten(Uren FMI) = 0,9893 + 0,6232 logten(Fp Total) S = 0,335690 R-Sq = 35,3% R-Sq(adj) = 32,7% Analysis of Variance Source DF SS MS F P Regression 1 1,47852 1,47852 13,12 0,001 Error 24 2,70450 0,11269 Total 25 4,18302 Fp Total U re n F M I 1000 100 10000 1000 100 10 S 0,335690 R-Sq 35,3% R-Sq(adj) 32,7% Regression 95% PI
Fitted Line Plot
Versie: 1.5 Auteur: Bertin Sterk
Copyright Protection
All of the information and images contained in this document are copyright material and the property of ABN AMRO Bank N.V. and/or its affiliated and group companies (“ABN AMRO”) unless otherwise indicated. The document is for internal use only by employees of ABN AMRO. None of the information or images contained in the document may be copied, reproduced, republished, downloaded or distributed either in whole or in part to any person or entity outside ABN AMRO except with the express permission in writing from an authorised representative of ABN AMRO.
By accessing this document you agree to be bound by all of the above terms and conditions.
© 2007 ABN AMRO Bank N.V.
14.2 REVIEW DOOR VENDOR...21 14.3 USE CASE POINTS...21 BIJLAGE A – HANDLEIDING MEER TOOL ...22
BIJLAGE B – REQUIREMENT TYPES ...23
1 Inleiding
In dit document is uitgewerkt hoe de metingen van efficiëntie en effectiviteit van de business analyse(requirement engineering) worden gedaan.
Ten tweede worden de randvoorwaarden en implementatie vraagstukken behandeld.
Ten derde bevat dit document naast deze toelichtingen, instructies voor het verzamelen van gegevens, het uitvoeren van de metingen en rapporteren over de efficiëntie en effectiviteit van requirement engineering. Als in dit document wordt gesproken over de efficiëntie en effectiviteit van een project wordt hier de efficiëntie en effectiviteit van het requirement engineering gedeelte van dat project bedoeld.
2 Doel
Het doel van dit document is:
- Het ondersteunen van het verzamelen van managementinformatie door zoveel mogelijk gebruik te maken van bestaande geregistreerde gegevens.
- De werkmethodes binnen Business Solutions uniform maken;
- De rapportering van gegevens accuraat en ondubbelzinnig maken, om het opbouwen van getalsmatige gegevens te ondersteunen.
8.4 Waarom meten?
In het gehele ontwikkeltraject vinden afwegingen plaats. Of dit nu gaat om de “go/no-go” beslissing om een project door te laten gaan, de project tailoring keuzes die gemaakt worden of welke reviews worden gehouden om de kwaliteit van de deliverables te verhogen. Al dit soort beslissingen zijn gebaseerd op beschikbare informatie. Dit kan bijvoorbeeld een standaard methode zijn of metingen die informatie geven over het proces.
Voorbeelden van gebruikte standaarden zijn DSDM en CMM. Voorbeelden van metingen zijn de functiepuntentelling en benefit tracking.
Het gedeelte van het ontwikkeltraject waar nog geen meting plaatsvindt is het requirement engineering gedeelte in de Business Study en de Functional Model Iteration fase.
Nadelen van het ontbreken van deze meetmethode:
- Er is veel geïnvesteerd in DSDM en in de opleiding van business analisten. Het voorkomen van een fout in de requirement engineering fase is namelijk vele malen goedkoper dan het herstellen van een fout in de bouw of implementatie fase. Helaas kunnen we niet meten of deze investeringen zich ook vertalen in een hoger efficiëntie en effectiviteit.
- Jaarlijks worden er vele miljoenen geïnvesteerd in het ontwikkelen van applicaties. We beschikken momenteel echter niet over een manier om onze afnemers te laten zien dat wij steeds effectiever en efficiënter werken.
- Bij het opstellen van het operational plan ontbreekt het aan ervaringscijfers waarmee de benodigde business capaciteit kan worden geschat.
Om de juiste keuzes te kunnen maken over het gebruik van bijvoorbeeld de DSDM methode of de manier van Requirements Engineering moet er informatie beschikbaar zijn om beslissingen op te baseren.
Meten bij requirement engineering is nieuw en er zijn nog geen standaarden voor. Wel kan door de reeds beschikbare informatie samen te voegen en het gestandaardiseerd bij te gaan houden, de gewenste managementinformatie worden verkregen.
De informatie waar naar zal worden gekeken is:
- CaliberRM voor informatie over requirements. Hierbij moet gedacht worden aan aantallen requirements per type (REM Requirement Types.doc) en totaal aantal requirements.
- Reviews voor informatie over findings. Hieruit zal de informatie over het aantal findings dat is gedaan per soort en severity worden verzameld.(QA.FRM.08 - Review Form.xls)
- Tailoring documentatie. Deze informatie bestaat onder andere uit de project
characteristics(PM.FRM.03 - Project Characteristic.doc). Hiervan zal onder andere gebruik worden gemaakt van de opbouw van de project class. Wat een zwaarte toekent aan het project op basis van grootte, complexiteit en risico’s.
- AIMS zal worden gebruikt voor de urenregistratie. Hiervoor is een nieuwe inrichting gemaakt qua activiteitencodes in AIMS zodat het direct duidelijk is waar iemand zijn/haar uren op moet schrijven.
Hiernaast zal door het verzamelen van gegevens duidelijker worden waar verbeteringen kunnen worden aangebracht, in de in dit document voorgestelde meetmethoden.
8.5 Hoe meten
De hierboven genoemde informatie is nodig om de onderstaande berekeningen uit te kunnen voeren.
ojectClass weging Uren e Efficiënti Pr ) * ( 1−
∑
=De efficiëntie wordt gemeten door de som van de uren uit AIMS te selecteren per (deel)project en per activiteit. Dit te vermenigvuldigen met de weging voor die betreffende activiteit1. Deze weging moet worden ingevuld in het daarvoor bestemde onderdeel in de database.
De som van deze uren vermenigvuldigd met de weging moet worden gedeeld door de projectclass uit de tailoringdocumentatie.
De uitkomst van deze berekening is een getal dat kan worden gebruikt om de projecten met elkaar te vergelijken. Als voldoende informatie is verzameld van verschillende projecten kan een bandbreedte van uren worden aangegeven voor de verschillende projecten per project class. Bijvoorbeeld projecten met project class 2 zitten gemiddeld tussen de 200 en de 600 uur aan requirement engineering(Tabel 1 - voorbeeld bandbreedte)
Tabel 1 - voorbeeld bandbreedte
Project Class ondergrens Bovengrens
0 50 200
1 200 600
2 600 1200
3 >1200
1 De weging voor de activiteiten zal pas gebruikt worden als er na zorgvuldig meten is aangetoond dat de berekening moet worden gecompenseerd. Tot die tijd zal de weging voor de verschillende
∑
∑
−
=
)
*
(Re
)
*
(
1
Weging
quirements
weging
Findings
eit
Effectivit
De effectiviteit wordt gemeten door het aantal findings te vermenigvuldigen met de weging en dit vervolgens te delen door het aantal requirements vermenigvuldigd met de weging.
De wegingen kunnen worden gegeven in het daarvoor bestemde onderdeel in de database.
De findings zijn een consolidatie van de review documenten behorende bij Requirements engineering per project. De requirements worden verzameld uit CaliberRM.
De weging voor de findings wordt gegeven aan de verschillende levels van severity(minor, medium, major)2. De weging van de requirements kan worden gebruikt om per type requirement een weging te geven3. De verschillende types requirements zijn opgenomen in Bijlage B – Requirement types. De uitkomst van deze berekening is een getal dat kan worden gebruikt om de projecten met elkaar te vergelijken.
Tabel 2
Voorbeeld data van het meten van effectiviteit
Findings Requirements Effectivity
Weight Minor(1) Medium(2) Major(3) Non- functional Functional Detailed
Project AA00 5 4 1 20 50 30 84% AA01 10 0 0 20 50 30 90% AA02 5 5 5 20 50 30 70% AA03 0 4 1 20 50 30 89% AA04 4 5 1 20 50 30 83% Total 24 18 8 100 250 150 83%
Voor Project AA00 uit het voorbeeld is de berekening hieronder uitgeschreven:
(
) (
) (
)
84 , 0 16 , 0 1 30 50 20 3 * 1 2 * 4 1 * 5 1 % ) * ( ) * ( 1 = − = + + + + − ⇒ = −∑
∑
y effectivit weight ts requiremen weight findingsBeide berekeningen worden uitgevoerd per project in de database MEER in de Cascade map <*******>. De berekeningen gaan automatisch maar de benodigde data moet vooralsnog handmatig worden verzameld uit de verschillende informatiebronnen.
In hoofdstuk 3 en 10 zal per onderdeel van de berekening worden toegelicht hoe de informatie moet worden verzameld. De informatie is in verschillende fasen in het DSDM proces beschikbaar, zoals getoond in Figuur 1.
2 De weging van de severity levels wordt gebruikt om het verschil te kwantificeren. Standaard zal de weging minor=1, medium=2 en major=3.
CaliberRM
Reviews Tailoring
AIMS
= Projectdata
Feasibility Study Business Study Functional modeling iteration
Design & Build iteration
Business
Acceptance Implementation Post-project >>>>>>>> DSDM >>>>>>>>>>
9 Implementeren
Voor het implementeren van de efficiëntie en effectiviteit metingen zijn de volgende aspecten van belang: - Randvoorwaarden - Kwaliteit - Subjectiviteit - Succesfactoren - Informatiebehoefte stakeholders 9.1 Randvoorwaarden
Als randvoorwaarden zijn de volgende aspecten van belang:
- Het gebruik van CaliberRM is verplicht voor alle projecten bij Business Solutions. Dit wordt afgedwongen door het management en de projectleiding.
- Het registreren van de uren wordt bijgehouden volgens de nieuwe richtlijnen die zijn opgesteld voor projecten bij Business Solutions. Dit wordt afgedwongen door het management en de projectleiding.
- De Project Class wordt voor alle projecten bij Business Solutions verplicht ingevuld. Dit wordt afgedwongen door het management.
- Het reviewen van de PRL is verplicht. Dit wordt afgedwongen door het management en de projectleiding.
- Het gebruik van het Excel review formulier is verplicht. Dit wordt afgedwongen door het management en de projectleiding.
- Het gebruik van de tool MEER en het maken van rapportages wordt gedaan door persoon die zelf inzicht heeft in de geproduceerde rapportages. Dit om te zorgen dat de rapportages niet alleen maar vragen oproepen maar juist ook direct beantwoorden. (zie uitwerking analyses)
9.2 Kwaliteit
De kwaliteit van de data uit CaliberRM, AIMS, reviews en het werkplan is van belang voor de uiteindelijke kwaliteit van de efficiëntie en effectiviteit getallen.
Het is dus van belang om de volledigheid en juistheid van de data te waarborgen zodat de uiteindelijke metingen van efficiëntie en effectiviteit van een hoge kwaliteit zullen zijn.
9.2.1 CaliberRM
Zoals gesteld in de randvoorwaarden is het gebruik van CaliberRM verplicht.
Huidige situatie is echter dat niet alle projecten CaliberRM gebruiken. Dit moet naar de 100% gebruik worden gebracht.
Om dit te kunnen stimuleren en controleren wordt de volgende taak uitgevoerd bij de afdeling Business Acceptatie.
Controle en stimulatie CaliberRM
- Een volledig lijst van nieuw gestarte en beëindigde projecten wordt opgevraagd bij de Portfolioregisseurs (afdeling Management Support).
- Voor de nieuw gestarte projecten word bij de projectmanager geïnformeerd of het project gebruik gaat maken van CaliberRM en of er behoefte is aan informatie of training in het gebruik van CaliberRM.
- Als het project aangeeft geen gebruik te maken van CaliberRM moet dit worden aangevraagd bij de leidinggevende. Leidinggevende kan ontheffing geven voor het gebruik van CaliberRM. Dit wordt dan met opgaaf van reden geregistreerd in de MEER tool.
- Bij de rapportages naar het management wordt gerapporteerd hoeveel procent van de projecten CaliberRM gebruikt.
9.2.2 AIMS
Zoals gesteld in de randvoorwaarden registreren alle medewerkers verplicht uren volgens de nieuwe richtlijnen die zijn opgesteld voor projecten bij Business Solutions.
Huidige situatie is echter dat:
- de gegevens in AIMS-ATR niet overeen komen met de werkelijkheid(data in AIMS is niet gesynchroniseerd met de HR database)
- niet alle medewerkers registreren hun uren
- niet alle medewerkers registreren hun uren op de juiste activiteitencode
Om dit te verbeteren moet er worden gestimuleerd en gecontroleerd. Hiervoor wordt de volgende taken uitgevoerd bij de afdeling Management Support.
Informeren projectmanager over uren registratie gedrag + Update gegevens in AIMS-ATR
- Een volledig lijst van nieuw gestarte en beëindigde projecten wordt opgevraagd bij de Portfolioregisseurs (afdeling Management Support).
- Bij de nieuw gestarte projecten word, bij de projectmanager, gecontroleerd wie er aan het project werken en of deze medewerkers correct in AIMS staan geregistreerd.(lijst uit AIMS)
- Foutieve gegevens worden middels de daarvoor bestemde entry en exit formulieren
gecorrigeerd(http://banknet.nl.eu.abnamro.com/mijn_bedrijfsonderdeel/bss/mcbs/medewerkers/af dmcbsintern_medewerkers.html)
- De projectmanager krijgt om de week een overzicht van de geschreven uren per medewerker ter controle aangeboden.
9.2.3 Project Class
De project class wordt op dit moment nog niet bijgehouden. om tijdig problemen te signaleren bij het beoordelen van de project class zal bij de afdeling Business Acceptatie de volgende taak worden uitgevoerd.
Informeren naar project class beoordeling
- Een volledig lijst van nieuw gestarte en beëindigde projecten wordt opgevraagd bij de Portfolioregisseurs (afdeling Management Support).
- Bij de projecten wordt geïnformeerd naar problemen met de beoordeling van de project class. - Na aanleiding van de gemelde problemen zal actie worden ondernomen. Dit kan door
verbeteringen of structurele problemen te melden aan een PIM(Process Improvement Manager) of het indienen van een PCR(Process Change Request) voor het aanpassen van de projecttailoring documentatie.
9.2.4 Review
Het reviewen is een verificatie en kwaliteitscontrole methode voor de deliverables van een project. Met behulp van reviewen worden fouten vroeg in het project geïdentificeerd om er voor te zorgen dat het juiste product wordt opgeleverd met een hoge kwaliteit. Reviewen voorkomt rework en faciliteert second opinions en het leren van elkaar.
De Huidige situatie kent echter de volgende risico's: - Het reviewen is subjectief.
- Het reviewproces is bedoeld om de kwaliteit te verhogen van de deliverables en niet om de effectiviteit te meten. Een ongewenst effect zou daling van motivatie, argwaan, discussie over accepteren of afwijzen van commentaar, risico dat de reviewer niet teveel findings wil vinden om collega niet af te vallen.
Om dit vast te stellen en vervolgens te voorkomen en verbeteren moeten de volgende taken uitgevoerd bij de afdeling Business Acceptatie en Business Solutions en moet in elk geval paragraaf 9.3 in acht worden genomen.
Eenmalig toetsen subjectiviteit reviews
Eenmalig toetsen om vast te stellen of de huidige reviews daadwerkelijk subjectief zijn. Toetsen wordt op de volgende manier gedaan onder supervisie van Business Acceptatie: - Toetsing: dezelfde review wordt eenmalig gedaan door meerdere reviewers. Blijkt dat de
verschillende reviewers tot dezelfde findings met dezelfde waardering(severity levels) komen. Dan is het huidige reviewproces niet subjectief.
Vinden de verschillende reviewers andere findings en waarderen zij deze ook verschillend dan is het reviewproces subjectief.
o Als de uitkomst van deze toetsing is dat het reviewproces geen subjectieve data oplevert kan het reviewproces worden gebruikt.
o Als de uitkomst van deze toetsing is dat het reviewproces subjectieve data oplevert moet er worden vastgesteld wat de invloed is van deze subjectiviteit.
Aanvulling huidige reviewen
Om risico’s te voorkomen zoals eerder genoemd of om in plaats van het huidige
reviewproces voor meetdata te gebruiken, moet er een formele inspectie worden gehouden aan het einde van de FMI fase.
Bij Business Acceptatie wordt momenteel reeds getest of de opgestelde requirements op meerdere manieren zijn uit te leggen. Deze interpretatie toetsing moet worden
geformaliseerd tot een verplichte toetsing aan het einde van de FMI fase. Deze toetsing wordt gedaan door acceptatie specialisten die niet betrokken waren bij het project. Dit omdat blijkt dat de effectiviteit van de huidige inspecties en reviews, die plaatsvinden tijdens de gehele business analyse afneemt. Dit komt omdat dezelfde club mensen keer op keer dezelfde(verbeterde) set requirements onder ogen krijgt. Op deze manier kan er niet meer objectief naar de requirements worden gekeken.
Voordelen van deze formele inspectie zijn:
- Niet meer op persoonlijk niveau, maar op projectniveau.
- Minder vragen van de vendor omdat requirements maar op één manier zijn te interpreteren.
- Kostenbesparing omdat interpretatie fouten worden gecorrigeerd voordat er wordt gebouwd aan de applicatie.
Voor een goede invoering van deze formele inspectie moet bekend zijn of dat wat er gemeten gaat worden ook nodige en objectieve metingen zijn. Dit kan worden getoetst door middel van een toetsing zoals beschreven bij eenmalig toetsen subjectiviteit reviews. 9.2.5 Standaardisatie requirements
Omdat bij het meten gebruik wordt gemaakt van requirements is het van belang dat er duidelijk is hoe requirements moeten worden opgesteld en wat voor requirements er opgesteld moeten worden. Dit omdat bij het ontbreken van een standaard de kans bestaat dat bijvoorbeeld de typen requirements voor verschillende doeleinden worden gebruikt.
Huidige situatie is dat dit goed is beschreven en dat er al meerdere cursussen zijn gegeven om dit te verbeteren. Ook het reviewen en het gebruik van CaliberRM dwingen een uniforme werkwijze af.
9.3 Subjectiviteit
Omdat de project class en de reviews op zich al mogelijk subjectieve data produceren is het van belang dat de efficiëntie en effectiviteit metingen niet een wedstrijd karakter krijgen, daling van motivatie veroorzaken, argwaan wekken, discussie over accepteren of afwijzen van commentaar brengen en risico’s met zich meebrengen dat de reviewer niet teveel findings wil vinden om collega niet af te vallen. Om deze punten te voorkomen en het wedstrijd karakter niet te stimuleren is het van belang dat de efficiëntie en effectiviteit rapportages alleen bekend worden gemaakt als management informatie.
Voorbeeld:
Het aantal findings uit de reviews kan eenvoudig worden beïnvloed door een defect aan te merken als een suggestion of discussion.
Gevolg hiervan is dat het project een hoger effectiviteit getal krijgt, en dat de verwachte waarde voor toekomstige defects juist stijgt. Veel discussie of suggesties op de huidige requirements kan namelijk leiden tot defects in bijvoorbeeld detail requirements of tot meer vragen van de vendor.
9.4 Succesfactoren
Succesfactoren voor het meten van efficiëntie en effectiviteit:
- Projecten en afdelingen moeten met elkaar en/of in de tijd vergeleken kunnen worden op basis van de efficiëntie en effectiviteit percentages.
- Geleerd kan worden van een project met een hogere of lagere efficiëntie of effectiviteit, door in detail te analyseren wat de afwijking heeft veroorzaakt.
- Requirement engineering gericht en onderbouwd kan worden aangestuurd en verbeterd. - Kan worden aangetoond dat investeringen in het proces ook daadwerkelijk resultaat hebben. - Besteding van middelen kan worden verantwoord aan de interne klant.
- Ervaringscijfers kunnen worden verkregen ter ondersteuning van de resource planning voor het operational plan.
9.5 Informatiebehoefte stakeholders
- efficiëntie en effectiviteit benchmarking informatie betreffende de businessanalyse - onderbouwing voor sturing requirement engineering
- besteding van middelen verantwoorden aan interne klant
3 Meten Effectiviteit
9.6 CaliberRMCaliberRM is het programma waar de projecten verplicht mee werken voor de registratie van
requirements. Uit CaliberRM kan met behulp van de functie “Export to Access” de informatie van het geselecteerde project worden geëxporteerd. Met de Access database MEER kan vervolgens de informatie worden geselecteerd uit de geëxporteerde data.
Dit dient te gebeuren na de FMI fase als alle requirements opgenomen zijn in CaliberRM. Het gaat er hier om dat alle requirement die zijn behandeld in de reviews ook bij deze telling van de requirement worden meegenomen.
In Bijlage C – Handleiding “Export to Access” staat stap voor stap beschreven hoe het exporteren uit CaliberRM werkt.
In de geëxporteerde database zijn de requirements per type te vinden in de tabel “Requirement info”
9.7 Findings
De informatie over de findings komt uit de reviewformulieren die staan opgeslagen in de projectmap in Cascade. Omdat voor het reviewen van één PRL meerdere reviewformulieren staan opgeslagen in Cascade(per Business analist), moeten de individuele formulieren worden geraadpleegd om een totaaltelling te krijgen van het aantal findings op een PRL.
De totaaltelling bestaat uit het verzamelen van de aantallen die staan vermeld in het eerste werkblad van het reviewdocument. Een voorbeeld van het de gegevens is weergegeven in Figuur 2. Deze getallen moeten bij elkaar worden opgeteld voor alle reviewformulieren van een bepaalde deliverable(bv. de PRL). De totaaltellingen kunnen worden genoteerd in het daarvoor bestemde onderdeel in de EEM database.
Figuur 2
Deze handeling dient voor alle reviewdocumenten te gebeuren die betrekking hebben op het requirement engineering proces. Dit zijn de reviews van de volgende documenten:
- Business Process Model (BPM) - Use Cases (USB)
- Prioritized Requirements List (PRL) - Logical Data Model (LDM)
10 Meten efficiëntie
10.1 Project ClassDe project class is de uitkomst van het per project ingevulde formulier “project characteristics”. Dit formulier is een onderdeel van het tailoring proces. De project characteristics zijn opgesteld
doormiddel van een uitgebreide enquête onder projectmanagers om de factoren op papier te krijgen die de zwaarte van het project bepalen.
De project characteristics zijn opgenomen in het werkplan van het betreffende project en is te vinden in de projectmap in Cascade. Uit het werkplan moeten voor de meting de size, complexity en risk assessments worden overgenomen. In Tabel 3 staan de mogelijke waarden die kunnen worden gegeven aan de size, complexity en risk.
Tabel 3
Dominant factor Value
Size Small/Medium/Large
Complexity Low/Medium/High
Risks Low/Medium/High
In de MEER database wordt automatisch de juiste project class geselecteerd op basis van de
ingevoerde waarden bij size, complexity en risk. De mogelijke combinaties met de bijbehorende class zijn weergegeven in Tabel 4.
Tabel 4
Class Size Complexity Risk
0 very small low low
1 small low low
1 small low high
2 small high low
2 small high high
2 medium low low
2 medium low high
3 medium high low
3 medium high high
3 large low low
3 large low high
3 large high Low
3 large high high
Selected projectclass 0/1/2/3 10.2 Urenregistratie
Uit AIMS-ATR moeten de uren worden geselecteerd per project voor de uren behorende bij requirement engineering.
In de nieuwe standaard urenregistratie business moet gebruik worden gemaakt van de methodecode DSB (DSDM-Business). De aanvraag formulieren zijn te vinden op
ms.html). Als deze code wordt gebruikt kunnen de uren gespendeerd aan het werk als solution engineer en requirement engineer uren apart worden geregistreerd. Deze uren staan dan geregistreerd op de activiteitencodes eindigend op een cijfer met daarna de letter S(solution engineering) of een E(requirement engineering).
Voor een overzicht van de uren per activiteit per project kan:
- Business Objects een handmatige selectie worden gemaakt uit AIMS.
- Webintelligence Infoview van een standaard rapportage gebruik worden gemaakt. 10.2.1 Infoview
Voor de handmatige selectie met Business Objects is kennis van Business Objects vereist. De standaard rapportages uit Infoview zijn in vijf eenvoudige stappen op te vragen. Om gebruik te maken van infoview is autorisatie benodigd.
Stap 1: Start de applicatie Webintelligence infoview.
Dit kan via Banknet/Infotheek/Rapportages. Onder het kopje managementinformatie klikken op Webintelligence Infoview.
Stap 2: Log in.
Typ je User-ID (hoofdletters) en SBT-wachtwoord in. Stap 3: Klik het gewenste rapport aan.
Kies de directory waar het bewuste rapport staat en klik op het betreffende rapport.
Dit is in dit geval de rapportage <*******> in de directory <*******>.
Stap 4: Geef de gevraagde inputvariabelen op.
Zodra het rapport is aangeklikt vraagt de applicatie om de voor dat rapport noodzakelijke inputvariabelen. Voor deze rapportage dient bijvoorbeeld de projectcode opgegeven te worden.
Stap 5: Opslaan / Printen
Het opgevraagde rapport wordt zichtbaar op het scherm en kan opgeslagen of geprint worden. 10.2.2 Autorisatie
Om van infoview gebruik te kunnen maken moeten onderstaande zaken zijn geregeld:
1. Uw SBT-beheerder dient uw user-ID te autoriseren voor Business Objects 6 niveau 2 (TSB26) 2. De contactpersoon4 van uw directoraat dient middels een Lotus Notus bericht aan AIMS
Helpdesk te verzoeken uw User-ID toe te voegen aan de Supervisortabel Business Objects op het domein FINS Bij de aanvraag moet worden aangegeven dat de gebruiker rapportages wil opvragen uit AR03 Project, AR04 Subproject en AR05 Time Registration.
3. AV2/Mainframe rechten zijn nodig en kunnen worden aangevraagd bij INSTAP(INtranet Security Aanvraag Procedure). http://eua041.ao.nl.abnamro.com/Applications/S-Z/SAP.nsf
via de link medewerkers autorisaties > persoonlijke autorisaties > mainframe > mainframe overig.
Onder selecteren dient dan het volgende aangevinkt te worden: - BUSINESS OBJECTS VIA AV2 (ABOBJII)
4 Bij de implementatie dient met de AIMS Helpdesk te worden afgestemd welke personen bij welk
Opmerking [A.G.P.1]: Welke rapportage?
- OMVS SEGMENT (OMVS MAINFRAME) - TSO AV2 (ATSOA2U)
Heeft men ooit al gebruik gemaakt van Business Objects dan kan de AIMS Helpdesk het User-ID alleen toevoegen aan de juiste Supervisortabel als het betreffende User-ID zich al in haar domein (FINS) bevindt. Is dat niet het geval dan zal de AIMS Helpdesk namens u een call indienen bij de IBM helpdesk (291900) om uw User-ID beschikbaar te laten maken voor het domein FINS.
10.2.3 Printen
Om een rapport toonbaar op papier te krijgen is het van belang dat de standaard instellingen worden aangepast. Dit kan door op Options te klikken en vervolgens in het tabblad View de optie PDF in Infoview aan te klikken.
10.3 Functiepunten
In het onderzoek “Efficiency and effectivity of the ABN AMRO solution delivery organisation” is de correlatie onderzocht tussen de getelde functiepunten van een project en de uren die zijn besteed in het voortraject(BS en FMI fase). Uitkomst van dit onderzoek was dat er op basis van de huidige gegevens geen significante correlatie kon worden aangetoond.
De gebruikte gegevens voor het onderzoek waren de gegevens van projecten uit 2005. In 2005 werd echter de urenregistratie nog niet volgens de methodecode “DSB” geregistreerd. Om het functiepunten onderzoek te verifieeren met een betrouwbaardere urenregistratie uit 2007 zullen ook de functiepunten verzameld moeten worden.
De functiepunten staan in de universe SPC van AIMS dat is te benaderen via Business Objects. De Functiepunten zijn te vinden in tabel Subproject onder: Subproject > Dashboard > Dashboard events > size measurments.
Voor het uitvoeren van de query in Business objects is een standaard sjabloon gemaakt. Het sjabloon
11 Rapportages
Om uit de MEER database de gewenste managementinformatie op te vragen zijn er een aantal standaard rapportages opgesteld. Deze zijn te benaderen onder het menu “rapportages”.
11.1 Uur/Project Class
Aantal uur delen door de project class. (onderverdelen in size,complexity en risk)
o Op den duur kan inzicht worden verkregen in de benodigde hoeveelheid uren aan de hand van een bepaalde project class.
o Budget aanvragen kunnen worden gecontroleerd op basis van historie.
o Projecten waarvoor wel een juiste projectclass is bepaald maar niet binnen de uren bandbreedte kunnen blijven, leveren waardevolle informatie op over de oorzaak van de afwijking. Bijvoorbeeld een projectteam samenstelling die niet goed is geweest of andere oorzaken die aan het licht kunnen komen door een gesprek met project leiders(doorspreken van de punten uit project class). Het voordeel is dat een gesprek gericht kan worden gehouden met het project dat niet in de bandbreedte qua uren is gebleven.
o Met onderverdeling size, complexity en risk kan worden aangegeven, als projecten afwijken op efficiëntie, waar de oorzaak kan worden gezocht namelijk size, complexity of risk.
Voordelen
Project managers kunnen het inschatten van de benodigde hoeveelheid uren controleren aan de hand van de combinatie uren/projectclass.
Management kan de budget aanvragen controleren aan de hand van de combinatie uren/projectclass. Gericht zoeken naar de oorzaak van een afwijking van het gemiddelde.
11.1.1 Analyse
Zoals in paragraaf 8.5 uitgelegd kan de efficiëntie van een project worden getoetst aan een bandbreedte van uren per project class.
Als voldoende informatie is verzameld van verschillende projecten kan een bandbreedte van uren worden aangegeven voor de verschillende projecten.
Bij analyse van de efficiëntie zijn de volgende opties mogelijk:
- Valt een project buiten de bandbreedte voor de betreffende project class dan is er: o Een afwijking van het gemiddelde van projecten met de betreffende project class.
1. Is deze hoger dan de bandbreedte dan is het project minder efficiënt geweest. 2. Is deze lager dan de bandbreedte dan is het project efficiënter geweest. o Een foutieve project class toegekend aan het project
o Het aantal uren is niet correcte bijgehouden
- Valt een project binnen de bandbreedte voor de betreffende project class dan is er: o Geen afwijking van het gemiddelde
o Een kleine afwijking van het gemiddelde
1. Is deze hoger in de bandbreedte dan is het project minder efficiënt geweest dan het gemiddelde.
2. Is deze lager in de bandbreedte dan is het project efficiënter geweest dan het gemiddelde.
11.2 Findings/requirements
Aantal findings delen door aantal aangeleverde requirements per type. De effectiviteit is bij een laag aantal findings hoger dan een hoog aantal findings. Het verschil in effectiviteit kan:
o Aangeven welk project hoger of lager zit dan de gemiddelde effectiviteit en bij deze projecten gericht zoeken naar de juiste werkwijzen of niet juiste werkwijzen van dat betreffende project.
o Aangeven of er veel discussie/onenigheid was over de opgestelde requirements(totaal aantal findings / defects) hiermee mogelijke problemen opsporen, nu discussie kan onderwerpen van problemen aangeven die gaan komen.
o Aangeven hoeveel van wat voor severity aan defects er zijn gemaakt. Allemaal minor fouten is misschien gewoon slordigheid, allemaal major defects in een project is een teken dat daar een verbetering kan worden gehaald.
o Aangeven in welk type requirement de meeste fouten voorkomen. Blijkt dat de detailrequirements veel findings bevatten kan het zijn dat aan het licht komt dat de hardwarerequirements niet goed zijn opgesteld en dat dit komt door verkeerde adviezen van de vendor.
Voordelen
Gericht zoeken naar juiste werkwijzen.
Aangeven welke projecten onderdelen hebben die voor veel discussie en onenigheid zorgen. Inzicht geven in wat voor soort fouten er worden gemaakt.
Inzicht geven op wat voor gebied(type requirement) fouten worden gemaakt. 11.2.1 Analyse
Zoals in paragraaf 8.5 uitgelegd kan de effectiviteit van een project worden getoetst ten opzichte van andere projecten.
Als voldoende informatie is verzameld van verschillende projecten kan een gemiddelde effectiviteit van projecten worden aangegeven.
Bij analyse van de effectiviteit zijn de volgende opties mogelijk:
- Een project scoort niet hoger of lager dan de gemiddelde effectiviteit van de projecten. - Een project scoort hoger of lager dan de gemiddelde effectiviteit van de projecten.
o Bij deze projecten kan bijvoorbeeld worden gezocht naar juiste werkwijzen of onjuiste werkwijzen.
o Kan worden gekeken op welk type requirement de findings betrekking hebben. Door gebruik te maken van “testdirector” kan de specifieke requirement worden getraceerd. o De overige punten zoals genoemd bij 11.2.
- Een effectiviteitscore is beïnvloed door het foutieve aantal requirements - Een effectiviteitscore is beïnvloed door het foutieve aantal findings of defects
11.3 Extern/Intern
Aantal uren Externemedewerkers in verhouding tot het aantal uren Internemedewerkers per (deel)project. (Externe efficiëntie en interne efficiëntie)
o Deze verhouding tezamen met efficiëntie en effectiviteit geeft aan wat de efficiëntie en effectiviteit is van de geleverde externe medewerkers. Of dat er intern opleidingen op bepaalde gebieden nodig zijn.
domeinkennis een tijdsbesparing oplevert)) het kan ook aantonen dat de efficiëntie juist lager is bij projecten met veel externen omdat de inwerk(leer)tijd moet worden meegenomen(voor domeinkennis).
o Externe benchmark, door intern te vergelijken met extern.
o Effectiviteit + externe en interne uren. Of de effectiviteit hoger is bij een hoger aantal externe uren dan intern, of andersom.
Verhouding requirements per uur + aantal findings per uur.(intern+extern)
o Is sneller werken ook productiever of worden er alleen maar meer fouten gemaakt. o Is dit hetzelfde voor interne en externe medewerkers?
Voordelen
Efficiëntie en effectiviteit van externen. Efficiëntie en effectiviteit van internen.
Verhouding externe efficiëntie en effectiviteit ten opzichte van interne efficiëntie en effectiviteit. Benchmarken door gebruik te maken van deze verhouding intern/extern.
11.4 IT/Business
Door het bijhouden van de uren van IT en van Business in de BS en FMI fase kan:
o Worden bekeken of Business meer of minder efficiënt/effectief is als IT meer of minder meewerkt in de BS en FMI fase.
Voordelen
De verhouding van IT en Business aandeel in de BS en FMI fase kan worden vergeleken.
12 Rollen
Het verzamelen van data is eenvoudig werk maar bij het invullen van de data in de tool moet de afweging worden gemaakt of de data bijdraagt aan de managementinformatie die de tool moet verstrekken. Blijkt dat bij een project geen findings zijn geregistreerd of dat er geen uren zijn geboekt volgens de nieuwe manier van urenverantwoording business is het de taak van degene die de data verzameld om de afweging te maken of het project wel of niet moet worden opgenomen.
Als het gaat om de uren die niet zijn geboekt op de codes Solution engineer en Requirement engineer, kan het ook zijn dat de informatie nog wel kan worden verkregen door de uren uit AIMS te selecteren op persoon. Er is namelijk altijd bekend wie er als business analist hebben gewerkt aan het project. In dit laatste geval kan het project dus wel worden opgenomen, maar is extra werk vereist om tot de juiste data te komen.
Naast het verzamelen van de data moeten er standaard een aantal rapportages worden gemaakt voor het management.
De rol efficiëntie en effectiviteit analist REM (MEERA) wordt vervuld door de Acceptatie
Specialisten van Business Acceptatie. De MEERA’ers werken mee met de projecten en hebben inzicht in de vordering van het project en kunnen inschatten of de benodigde informatie aanwezig is bij het project. De MEERA’er die is toegewezen aan het project is ook degene die belast is met het
zo spoedig mogelijk in de tool te worden ingebracht. Doorgaans zal aan het einde van de FMI of in de DBI fase zeker alle data beschikbaar zijn en dus in de tool moeten worden ingevoerd.
De rol efficiëntie en effectiviteit manager (MEER) wordt vervuld door de BAM’er. De MEER’ers zijn verantwoordelijk voor de verzamelde data en moeten erop toezien dat de data wordt verzameld. De MEER’er maakt 1 maal per kwartaal de rapportages met daarin de nieuwste data en stuurt deze per mail naar de leden van het portfolioteam.
De belanghebbenden kunnen zelf tussentijds ook een rapportage opvragen bij de MEER’er. Overige belanghebbenden kunnen zijn:
- Verantwoordelijke voor inhuur van externen
- Verantwoordelijke voor de opleidingen van business analisten
- Aanspreekpunt dat vragen over van de VC’s beantwoordt over de interne rekeningen - Projectmanagers; inschatten project uren
- VP’s afdelingen development - SVP’s
- ESVP; totale score jaar tot jaar
13 Benchmarken
13.1 ExternExtern benchmarken is momenteel niet mogelijk
13.2 Intern
Intern benchmarken kan op de volgende manieren. Historie
Benchmarken kan na verloop van tijd als er voldoende historie is opgebouwd. De huidige efficiëntie en effectiviteit van een project kan dan worden vergeleken met de efficiëntie en effectiviteit data van reeds afgeronde projecten.
Deelprojecten / Projecten / afdelingen
Een andere mogelijkheid om te benchmarken kan op 3 niveaus.
- deelprojecten met andere deelprojecten binnen een project of tussen projecten - projecten vergelijken met projecten
14 Verbeteringen MEER
14.1 Gedetailleerder bijhouden van requirements
Door het verzamelen van de beschreven informatie zal het mogelijk zijn om op den duur aan te geven of het effectief is om meer informatie bij te gaan houden of in meer detail bij te gaan houden. Bijvoorbeeld het wegen van requirements op detailniveau is momenteel niet mogelijk. Dit zou een verbetering kunnen opleveren als de requirement op detailniveau grote verschillen aan het licht brengen tussen de effectiviteit van projecten. Is er geen verbetering te behalen dan zal het in detail registreren van requirements alleen maar tijd kosten en ook niet effectief zijn.
14.2 Review door Vendor
Het reviewen binnen ABN AMRO wordt gedaan om de kwaliteit van de documenten te verhogen en te waarborgen. Een probleem dat zich kan voordoen bij het gebruiken van de findings afkomstig uit de reviews, is dat er te veel tijd wordt besteed aan het correct aanbieden van requirements voor een review. In dit geval worden de findings niet opgelost door het doen van reviews maar door de extra tijd die wordt besteed aan het opstellen van de requirements. Findings vinden in een door iemand anders opgesteld document is makkelijker dan je eigen findings proberen te vinden. Beide keren zal het document de gewenste kwaliteit hebben maar zal in het geval van zelfcontrole meer tijd hebben gekost.
Dit probleem kan worden omzeild door gebruik te maken van de findings/vragen die de vendor heeft over de aangeleverde PRL.
Bijvoorbeeld TCS die vragen stelt over een aangeleverde PRL.
Deze findings/vragen zeggen dan niet alleen wat over het REM proces maar ook over de review die binnen Business Solutions heeft plaatsgevonden.
14.3 Use Case Points
Use Case Points gebruiken voor de efficiëntie meting in plaats van uren voor een bepaalde project class.
Met behulp van de Use Case Points methode kan op basis van de Use Cases een project grote en benodigde inspanning worden berekenen.
Zoals IT gebruik maakt van functiepunten zou de business gebruik kunnen maken van Use Case punten.(http://www.codeproject.com/gen/design/usecasep.asp)
