text:
                             højesterets dom
                           afsagt torsdag den 25. april 2013
sag 309/2010
(2. afdeling)
forsvarets materieltjeneste
(kammeradvokat karsten hagel-sørensen og advokat kasper mortensen)
mod
saab ab
(advokat carsten raasteen)
i tidligere instans er afsagt dom af sø- og handelsretten den 10. september 2010.
i pådømmelsen har deltaget fem dommere: per walsøe, niels grubbe, jens peter christensen,
hanne schmidt og oliver talevski.
påstande
appellanten, forsvarets materieltjeneste, har nedlagt påstand om, at indstævnte, saab ab,
skal betale 187.100.783 kr. med procesrente af 143.024.826 kr. fra den 26. marts 2008 til den
3. november 2010 og af 187.100.783 kr. fra den 4. november 2010.
saab ab har påstået stadfæstelse, subsidiært betaling af et mindre beløb.
sagen for højesteret
forsvarets materieltjeneste (fmt) har den 24. september 2010 opfyldt sø- og handelsrettens
dom og betalt i alt 44.075.957 kr. inkl. renter og sagsomkostninger til saab.
fmt‟s påstand udgør således summen af fmt‟s tilbagebetalingskrav efter kontrakten på
143.024.826 kr. og tilbagebetalingskravet på 44.075.957 kr. vedrørende opfyldelsen af sø- og
handelsrettens dom, i alt 187.100.783 kr.
                                               - 2 -
sagen er blevet behandlet sammen med højesterets sag nr. 310/10, saab danmark a/s mod
forsvarets materieltjeneste, der angår spørgsmålet om betaling for saabs deltagelse i mip
samarbejdet.
supplerende sagsfremstilling
efter fiat og frem til indgåelse af kontrakt den 29. juni 2007
i en e-mail af 23. maj 2007 fra claus nordendorff til henrik juul krogh er det anført, at det
på styregruppemødet den 16. maj 2007 blev besluttet at anbefale at indarbejde mip block 3 i
daccis leveringen, og at beslutningen var truffet under forudsætning af, at det ikke ville øge
projektrisikoen, at det ville være økonomisk neutralt, og at det ikke ville forsinke projektet ud
over det, der var aftalt i hensigtserklæringen.
det fremgår af parternes korrespondance under forhandlingerne om en ny kontrakt, at de gik
ud fra, at man skulle gå over fra mip block 2 til mip block 3. under forhandlingsfasen skete
der imidlertid en ændring, således at mip block 2 igen skulle være en del af kontrakten. der
er herom fremlagt et skærmprint af udkast til bilag 1 – statement of work. dette skærmprint
viser et ændringsforslag i det daværende udkast. det var david wadell fra saab, som den 26.
juni 2007 havde lavet ændringsforslaget, der senere indgik i bilag 1 til parternes kontrakt af
29. juni 2007. det hedder således i ændringsforslaget bl.a:
       ”this contract will deliver c2, database and replication to blk2 standards as achieved
       in bilag 3 – annex c. (note saab is proceeding at risk with jc3iedm database modifi-
       cations to reduce overall programme costs). an additional contract (or amendment to
       this contract) implements the replication mechanism to blk3 standards to achieve at
       least mslt-1 compliance…”
parterne afholdt i uge 20 i 2007 en workshop, i hvilken forbindelse der blev udarbejdet en
”scenario list” (bilag 81). denne liste indeholdt 11 scenarier, hvoraf 8-11 angik mip.
kontrakten af 29. juni 2007
det fremgår af kontraktens § 10, stk. 8, at ingen betaling, gennemgang, kommentering eller
godkendelse fra fmt‟s side af nogen prøve kunne tages som udtryk for en ændring af de
krav, der kunne stilles efter kontrakten. efter kontraktens § 11, stk. 1, skulle saab dokumen-
tere alle processer i projektet, og dokumentationen skulle være til fmt‟s rådighed.
                                                 - 3 -
der var ikke i kontrakten fastsat regler om en afhjælpningsret eller afhjælpningspligt for saab
med hensyn til mangler mv. konstateret ved milepæl oc. i § 13 var der derimod fastsat en
afhjælpningsret på 60 arbejdsdage for fejl og mangler konstateret ved milepæl fc eller efter
den endelige godkendelse af systemet.
§ 33 om sædvaner havde følgende ordlyd:
       ”33.1 de i denne kontrakt fastsatte bestemmelser er de eneste gældende for denne
                leverance, idet det udtrykkeligt mellem køber og sælger er aftalt, at der
                ses bort fra hidtil fulgte sædvaner ved kontrakters indgåelse og praktiske anven-
                delse, inklusive forespørgsel, tilbud og købers og sælgers generelle ind-
                købs- og salgsbetingelser.
       33.2 såfremt køber eller sælger i enkelte tilfælde under afvikling af denne
                kontrakt undlader at gøre sin ret gældende, skal dette ikke tages som udtryk for
                afkald på denne ret i andre eller lignende tilfælde.”
efter kontraktens § 38, stk. 2, havde partene aftalt følgende prioritetsrækkefølge i tilfælde af
indbyrdes uoverensstemmelse mellem kontrakten og den hertil hørende tekniske dokumenta-
tion i form af bilag:
1. hovedkontraktens ordlyd.
2. engelsk oversættelse af kontrakten.
3. kravspecifikation (system specification and requirements matrix), bilag 3.
4. statement of work, bilag 1.
5. øvrige bilag.
i kontraktens bilag 1, statement of work, punkt 1.3.1.f.i., er der fastsat følgende:
       ”1.3.1 the objective is to provide a system which:
       …
       f. has technical and operational interoperability with other command support systems,
       achieving compatibility with the multilateral interoperability programme as detailed in
       bilag 3 – specifications; in summary:
       i. this contract will deliver c2, database and replication to blk2 standards as
       achieved in bilag 3 – annex c. (note saab is proceeding at risk with jc3iedm data-
       base modifications to reduce overall programme costs”.
i punkt 1.3.1.f.ii er det fastsat, at:
                                                - 4 -
       “an additional contract (or amendment to this contract) implements the replication me-
       chanism to blk3 standards to achieve at least mslt-1 compliance”.
tilsvarende er som nævnt i sø- og handelsrettens dom fastsat i kontraktens bilag 3, punkt
2.1.7.
i kontraktens bilag 3, punkt 2.1, hedder det bl.a.:
       “2.1.1 the scope of this system specification is to define the requirements for daccis
       6.6 under this initial contract and identify the scope of the future planned functionality
       to be implemented under contract amendment as daccis 6.6+ (full capability) see
       appendix e.
       …
       2.1.4 the requirement matrix defines what is included as a requirement to this contract
       for daccis 6.6 and extended scope for daccis 6.6+.
       2.1.5 the requirement matrix defines what is the current contract scope of this contract
       and intended future scope that will be realized after contract amendment to implement
       the 6.6+ functionality when all requirements will then come within the “shall” be deli-
       vered scope.
       2.1.6 the schedule of the daccis 6.6+ release is dependent on the defined require-
       ments as defined in the requirement matrix. if a contract cannot be resolved for the ex-
       tended requirements the daccis 6.6+ cannot be delivered…”
punkt 7.24 og 7.25 indeholdt bl.a. følgende om henholdsvis mip compliancy og replication:
       ”7.24 mip compliancy
       name                        id and description
       symbology (full)            cor675x it shall be possible to send and receive information
                                   to render the same symbols according to mip tactical inter-
                                   operability requirements (mtir) version 3.6 annex g. to the
                                   same extent as proven by daccis at mip block 2 slt3 test
                                   for detailed information see appendix c, e and ref [3].
       operational                 cor676x daccis shall to the same extent as at mip block 2
       information                 slt3 test support creation and dissemination of the following
       groups (oig)                mip block 3 oig’s:
       (full)                           - friendly and neutral (organisational)
                                        - friendly and neutral (non-organisational)
                                        - uncorrelated enemy and unknown
                                        - correlated enemy and unknown
                                   for further details, refer to appendix c and e.
       jc3iedm data                cor678x daccis shall support the domain model
                                              - 5 -
      model (full)               jc3iedm version 3.1a to the same extent as proven by
                                 daccis at mip block 2 sl3 test.
                                 for further details, refer to appendix c and e.
      7. 25 replication
      name                       id and description
      support for data           cor600 support for data integrity and availability shall in-
      integrity and availabil-   clude at least support for the concept of ownership of data,
      ity                        support for mirroring and replication, applying the mip dem
                                 replication, and support for fully automated recovery.
                                 generally, the procedures behind the mip dem are followed.
                                 for replication contracts a daccis specific solution is pro-
                                 vided in addition to a mip compliant solution
      mip/dem                    cor601x the replication mechanism of daccis shall be
      replication to a non-      based on the mip replication mechanism (dem) specified in
      daccis mip                 mtidp version 3.3 and mir, enabling communication with a
      system(full)               mip block 3 compliant replication.
      mip/dem                    cor601 the replication mechanism of daccis shall be
      replication to a non-      based on the mip replication mechanism (dem) specified in
      daccis mip                 mtidp version 2.2, enabling communication with a mip
      system(6.6)                block 2 compliant replication.
      mip/dem                    cor602 the replication mechanism of daccis shall sup-
      replication within         port mip/dem replication with daccis national exten-
      daccis (6.6)               sions.
      replication within         cor602x the replication mechanism shall to the extent
      daccis (full)              possible use mip/dem
      “
i kontraktens bilag 8, punkt 1.2.1, er det om projektlederens kompetence bestemt, at:
      ”only the project managers have the authority to make decisions regarding issues,
      within the framework of the agreement and within their allocated delegations, derived
      respectively from:
      a. delivery;
      b. timetable; and
      c. price;
      hereinafter known as the main factors.”
om styregruppens kompetence er det videre i bilag 8, punkt 1.2.2, bestemt, at:
      ”the parties‟ representatives in the project steering group will have the authority to
      make all neccessary decisions, including judgements pertaining adjustments to the
      main factors.”
for så vidt angår ændringer af kontrakten fremgår af kontraktens bilag 8, annex a, at der skal
udarbejdes en såkaldt ccp (contract change proposal). punkt 1.1.1 og 1.1.2 har følgende
ordlyd:
                                              - 6 -
       ”1.1.1   a contract change proposal shall identify separately the cost of preparation of
                the contract change proposal and any proposal variation to the contract price
                and, where approved, the cost of preparation shall be taken into account in cal-
                culating the varied contract price.
       1.1.2    where this contract change proposal relates to changes of an administrative
                nature which have no impact upon the contract price or on the statement of
                work, the contractor may provide minimal details of the change. responses
                are only required for headings denoted as mandatory.”
perioden fra kontraktindgåelse til oc-testen
i en project management plan (bilag aaz), som saab har udarbejdet, hedder det om oc-te-
sten bl.a:
       ”release 2 of the system (termed the ”operational capability”) continues to stabilize
       the daccis core/fw and to add funcionality to get an operational product capable
       of use by the customer. the phase ends with an acceptance test to be executed at the
       customer site.”
det fremgår af referatet af projektledermødet afholdt den 9. oktober 2007, at saab fik udleve-
ret notater af henholdsvis 4. og 9. oktober 2007 fra fmt med henblik på at fremkomme med
bemærkninger. notaterne var udarbejdet af jeppe nyløkke fra ifad, og han gav i notatet af
4. oktober 2007 udtryk for, at 28 funktionelle krav og 26 ikke-funktionelle krav, herunder
kravene til mip block 2, ikke var dækket af scenario eventlisten. i notatet af 9. oktober 2007
pegede han bl.a. på, at alle verifikationsmetoder fremstod som rent interne for saab, og at
saab ikke planlagde, at fmt skulle involveres i verifikationen.
af saabs operation capability observation report fra 19. oktober 2007 fremgår, at der var 13
f1 og f2 fejl vedrørende mip og 15 f1 og f2 fejl vedrørende bdm.
i mailen af 30. oktober 2007 fra torben dixen møller til bl.a. finn hansen vedrørende parter-
nes møde samme dag fremgår ud over det, som er anført i sø- og handelsrettens dom, at fmt
på mødet ”præsenterede vores bekymringer og fremlagde ganske klart, at vi holder os til kon-
trakten og at forsinkelser og skred i omkostningerne ikke er en option”.
der er fremlagt et referat af 15. november 2007 af et alignmentmøde mellem parterne, der
efter det oplyste blev afholdt den 13. november 2007. i mødet deltog for fmt klaus vester,
                                               - 7 -
henrik juul krogh og lars abild. til stede var endvidere jeppe nyløkke fra ifad. saab var
repræsenteret af henning hay sørensen og richard hallie. til brug for mødet havde saab i en
joint review report af 9. oktober 2007 indarbejdet saabs kommentarer til jeppe nyløkkes
notater af 4. og 9. oktober 2007. der er endvidere fremlagt en rapport fra saab fra 26. novem-
ber 2007 benævnt system test procedure, hvis formål er at beskrive ”the system verification
procedure for the daccis 6.6+ operational capability”.
fmt‟s afvisning af saabs forslag til kontraktsændringer skete ved brev af 20. november 2007
og ikke ved brev af 22. november 2007 som anført i sø- og handelsrettens dom.
henning hay sørensen sendte den 26. november 2006 en e-mail til klaus vester vedrørende
den dokumentation, som saab havde indført i ”groove”. henning hay sørensen oplyste bl.a.,
at saab havde offentliggjort ”the system test procedure on groove”. hvis fmt havde be-
mærkninger hertil, ville saab gerne drøfte dem inden projektledermødet i slutningen af uge
49.
i brevet af 30. november 2007 fra saab til fmt er det anført, at hvis fmt fortsat forlangte, at
bdm og mip ”er indeholdt i oc, vil saab gennemføre leverancetesten med bdm og mip
integreret på det foreliggende udviklingsniveau”. saab anførte videre, at dette ikke var en
ønskværdig situation, og at saab kunne ”forudse, at der kan være mange kritiske fejl, i en
størrelsesorden, vi endnu ikke kender”.
testen i uge 51/2007
på testens anden dag, tirsdag den 18. december 2007, sendte peter wimmerström en intern e-
mail til nogle medarbejdere i saab, hvoraf det bl.a. fremgår, at han havde talt med finn han-
sen fra fmt, og at testen ville blive gennemført uden mip og bdm.
på testens tredje dag, onsdag den 19. december 2007, sendte henning hay sørensen en e-mail
til klaus vester og lars abild, hvor han forespurgte, om der var en e-mail på vej angående
tekniske detaljer for fmt‟s mip reference system. lars abild sendte herefter en e-mail til
henning hay sørensen med tekniske detaljer for mip reference systemet, som ville være
nms. kl. 14.23 samme dag svarede henning hay sørensen til klaus vester og lars abild, at
saabs folk ville gøre klar til mip test fredag. kl. 23.54 samme dag sendte henning hay
sørensen en e-mail til klaus vester m.fl., hvori det hedder bl.a.:
                                               - 8 -
       ”vi har på baggrund af denne information analyseret situationen, og på baggrund af
       denne analyse har vi besluttet ikke at gennemføre testen af mip og bdm i denne uge.”
der blev samme dag, onsdag den 19. december 2007, afholdt et møde mellem parterne vedrø-
rende spørgsmålet om fortsættelse eller ophævelse af kontrakten mellem parterne. i saabs
oplæg til mødet er anført bl.a.: ”current oc testing to be completed without mip/bdm”. af
referatet af mødet punkt 5 fremgår, at der var en pause, hvorefter torbjörn wingårdh fra saab
fremlagde et udkast til hensigtserklæring. det var heri bl.a. anført, at oc-testen i uge 51
skulle gennemføres uden mip og bdm. af punkt 7 i mødereferatet fremgår, at fmt efter en
kort drøftelse om testforløbet bemærkede, at oc-testen var saabs ansvar, og at beslutninger i
relation hertil alene var saabs egne. fmt var fortsat til rådighed for testene, også hvis dette
indebar, at der skulle arbejdes sent eller lørdag.
onsdag den 19. december 2007 kl. 20.38, efter mødet mellem parterne, sendte bjarke hei-
berg-iürgensen en e-mail til bl.a. peter wimmerström, vedrørende spørgsmålet om en hen-
sigtserklæring. af punkt 3 i e-mailen fremgår, at:
       ”fmt medvirken til formalisering af kontrakttillægget kan, såfremt der ikke opnås
       enighed herom, ikke fortolkes som en frafaldelse af nogen rettigheder, nogen form for
       accept af kontraktbrud eller passivitet.”
den 20. december 2007 blev der på ny afholdt et møde mellem parterne, hvorunder der blev
udarbejdet et udkast til hensigtserklæring. i punkt 2.3 om vilkår for mip block 2 test hedder
det bl.a.:
       ”parterne er enige om, at ovennævnte krav til mip block 2 afkræver en nærmere ana-
       lyse i forhold til de nuværende krav i hovedkontrakten, idet der kan være tale om en
       udvidelse eller præcisering af hovedkontraktens bilag 3, annex c.”
der er fremlagt et omfattende dokument (bilag aad) vedrørende operative scenarier til brug
for oc-testen. saab har udarbejdet dette dokument.
tiden frem til fmt’s ophævelse den 25. februar 2008
kategorisering af fejl
saab udarbejdede den 11. januar 2008 en rapport vedrørende testen i uge 51, hvoraf det frem-
går, at saab havde fundet 6 f2 fejl inden testen i uge 51 og 4 yderligere f2 fejl under testen i
                                                 - 9 -
uge 51. i alt nåede saab op på 11 f2 fejl. det fremgår videre, at 54 ”shall” krav ikke var te-
stet under oc-testen i uge 51.
på et møde afholdt mellem parterne den 15. januar 2008 fremlagde saab testrapporten, og der
skete en ”walkthrough of observations”. fmt kom den 18. januar 2008 med yderligere kom-
mentarer til saabs klassificering af fejl mv. heri var det bl.a. angivet, at der ikke var tale om
en fuld og endelig oc-test, og at fmt ikke kunne godkende testen. af følgebrevet fremgår
bl.a., at ”fmt arbejder videre med klassificering af fejl”.
saab sendte den 12. februar 2008 et nyt udkast til testrapport til fmt, hvor f2 fejl var angivet
til 12, heraf 7 fejl vedrørende perioden inden testen i uge 51 og 5 fejl fundet under testen i uge
51. fmt kommenterede dette udkast den 18. februar 2008 og anførte:
       ”the test was not a full and final test oc-test and consequently dalo has not made an
       internal revision of the test results with the view of approval of the test but only read
       and discussed the results on the basis of the test report made by saab. the implication
       hereof is still pending discussion between dalo and saab”.
fmt anførte endvidere med hensyn til observationerne før uge 51, at dette krævede “baseline
classification by fmt and saab”.
forhandlingerne om en tillægskontrakt i henhold til hensigtserklæringen
af saabs mip-analyse af 10. januar 2008 fremgår bl.a.:
       ”3    summary of findings
             mip compliancy on the four mentioned areas can be enhanced, but not within ex-
             isting contract for daccis 6.6.
             the enhancements needed will require clarification of requirements followed by
             design, implementation and test. in some areas this will also effect design changes
             in the system.
             enforcing changes of this kind at the current point in time will jeopardize the
             projects ability to meet the milestones.
             saab recommends to stick to the current contractual scope and address roadmap as
             a separate issue. in this respect, to maintain the usability of the system, it is crucial
             to achieve an agreement on what to do with the parts of the system that cannot be
             mip compliant. it is not recommended to remove everything that is not compliant,
             because then our system will become a mip test system and not a fully functional
             operational system.”
                                               - 10 -
i en intern e-mail af 16. januar 2008 fra hanne thode til bl.a. finn hansen er det anført, at
”saab havde leveret en analyse, der ikke lever op til hensigtserklæringens punkt 2.3”. dette
blev fulgt af en e-mail af 17. januar 2008 fra hanne thode til ingvar krafft. det anføres her
bl.a.:
       ”thank you for your email. from our meeting yesterday we understand that saab can
       and will deliver a daccis system that includes mip requirement. however, we also
       understand that saab do not intent to adhere to the requirements in the loi.
       as we underlined at our meeting this is a new situation that is different from what was
       agreed in december. it is, consequentially, required that a decision is made in our orga-
       nisation as to whether we intent to accept a contract addendum, including the changes
       proposed by saab, or we wish to terminate the contract.
       in order for us to address this issue in our organization we therefore requested that you
       advise us on how you see the negotiation as to which terms and conditions, including
       changes – if needed – in the time schedule and major milestones, that will make it
       possible for you to adhere to clause 2.3 of the “hensigtserklæring”. this information is
       needed if our organization only wish to continue daccis if mip block 2 is included.
       as you know, due to the many delays, time is now crucial. obviously, we will prefer
       that no changes are made and we adhere to what was agreed in december. however,
       from ingvar krafft we understood that if you are to include mip, you will need to adjust
       the time schedule to include an extra test, and also request an additional payment. we
       understood that the time schedule should probably be extended with an additional 6
       months. please let us know immediately if this is no longer the case.”
denne e-mail skal ses i sammenhæng med to alternativer, som saab havde udarbejdet om
mip block 2. efter det første alternativ skulle fc udskydes til uge 50, og prisen ville være 10
mio. kr. efter det andet alternativ skulle tidsplanen forlænges i 6 måneder, og prisen ville
være 25 mio. kr.
ingvar krafft svarede ved e-mail af 18. januar 2008. det hedder heri bl.a.:
       ”as stated in previous meeting we can and wish to deliver the daccis system accord-
       ing to what is in current contract scope and with extended mip block 2 scope. we also
       honor what was said during the meeting in december and what is reflected in your
       minutes of the meeting. this is also our interpretation of the loi.
       we have provided your steering committee chairman claus nordendorff with pre-draft
       plans for a new release with added functionality compared to current contract (alterna-
       tive 2) and one plan who reflect if you wish to prolong the date of the current fc
                                              - 11 -
      (alternative 1). this means that saab has provided fmt with three different possible
      ways of how to continue. since no direction has been given by fmt, saab can‟t
      continue to update the written part of master schedule. saab awaits comments from
      fmt on the ccp delivered by saab the 11th of january and 16th of january, in
      accordance with the actions of our meeting before we can ontinue the process with
      updating ccp.”
parterne holdt herefter et møde den 21. januar 2008. af mødereferatet fremgår bl.a.:
      ”
             hensigtserklæring valid through 7 february 2008.
             oc moved in accordance with the hensigtserklæring.
             fc moved to week 50, 2008 ending 12. december 2008. new test requirements
              to include high degree of mip block 2 compliance.
             end of correction period after fc, week 12, 2009.
             saab ab decide whether to reduce testing and ie. remove pre-fiat test or oth-
              ers to make more time available for development. bilag 4 annex b to be ad-
              justed .
             payments remain according to hensigtserklæring.
             high degree of mip block 2 compliance to be incorporated and detailed in order
              to live up to the hensigtserklæring item 2.3. high degree to be defined in the
              contract, as it is complex and more crucial in some functionalities than in others.
              saab ab mentioned commented – the overall goal of 80 % mip block 2 com-
              pliance. finn hansen did notagree that 80% mip block 2 compliance was suffi-
              cient in all eventualities. high degree of mip block 2 compliance means that the
              system is usable in international operations, fx positions and friendly fire must
              be accurate. the subtask “action task” will not be part of mip block 2 deli-
              very.”
parterne fortsatte herefter forhandlingerne om et kontrakttillæg i henhold til hensigtserklæ-
ringen, og der blev i den forbindelse som anført af sø- og handelsretten holdt en fælles work-
shop den 15. februar 2008.
i rapporten fra workshoppen hedder det i afsnittet om schedule:
      ”this change of documentation can not be in place for oc week 24, where saab den-
      mark will then need to sustain previous achieved mip block 2. mslt 3 results as the
      basis for verification and acceptance.
      a draft version can be delivered for review in week 24 with the purpose of supporting
      the customer and demonstrating progress in the process.”
som nævnt i dommen holdt parterne et møde den 19. februar 2008. under dette møde tilbød
saab:
                                             - 12 -
      ”…that the final specification in bilag 3 appendix e as per its distributed proposal
      could be prepared by week 20 including mapping of the mip msrs requirements to the
      daccis cor requirements and the slt tests. fmt questioned the mapping to the
      operational scenarios and saab advised that further clarification of the fmt
      expectations was required by saab to be able to commit to a schedule.”
i bjarke heiberg-iürgensens e-mail til saab efter mødet er der anført bl.a. følgende om fmt‟s
fortsatte bekymringer (concerns):
      ”4. the areas that saab needs to clarify can be summarized as follows:
      - dalo does not consider that the analysis called for in the loi/hensigtserklæring
           regarding mip block 2 was performed by saab in the way intended.
      - this leads to concerns about saab ability to describe the mip block 2 requirements
           with reference to the msrs/sys references. in particular the additional require-
           ments listed in the loi/hensigtserklæring need to be decribed so that it is clear that
           they are covered by the contract, how they are referenced, and how the test re-
           quirements will be.
      - dalo further needs saab clarification on the degree of mip compliance related to
           the key functional areas in order to assess and evaluate if the intentions of the mi-
           nutes of the 21 january 2008 meeting concerning a higher and differentiated degree
           of mip compliance will be guaranteed by saab.”
peter dan hansen fra fmt sendte den 20. februar 2008 kl. 8.37 en e-mail til bl.a. bjarke hei-
berg-iürgensen og flemming agerskov vedhæftet peter dan hansens og saabs anbefalinger
fra workshoppen afholdt den 15. februar 2008. e-mailen blev samtidig sendt til orientering til
en række medarbejdere hos saab, bl.a. ingvar krafft. bjarke heiberg-iürgensen sendte kl.
11.44 samme dag en e-mail til bl.a. ingvar krafft vedhæftet fmt‟s og saabs anbefalinger fra
workshoppen og oplyste samtidig, at fmt havde foretaget to mindre ændringer heri. kl.
14.13 samme dag sendte ingvar krafft en mail til bjarke heiberg-iürgensen, hvoraf fremgår:
      ”does this mean that you also agree on the process recommended by the workgroup?”
bjarke heiberg-iürgensen svarede herefter i en mail sendt til ingvar krafft kl. 15.56 samme
dag:
      ”dalo agrees to the process described. the schedule proposed by saab still leave
      dalo with the concerns as discussed yesterday and confirmed by dalo mail 19. feb-
      ruary 2008 23:06”.
                                              - 13 -
som nævnt i sø- og handelsrettens dom holdt parterne den 21. februar 2008 et forhandlings-
møde. saab fremkom i den forbindelse med følgende svar på de tre ovenfor citerede bekym-
ringer:
      ”concern 1:
      saab answer:
      saab is confused by the continual dalo statements relating to the analysis. in discus-
      sions it appears that dalo was seeking an analysis from an operational perspective and
      this has been driving ongoing discussions without stating a specific approach to resolve
      the situation.
      it appears to us that what was sought by dalo is definitely not described in the loi as
      the loi seeks only an analysis of the testing alternatives and implementation of those
      tests.
      concern 2:
      saab answer:
      saab initially described the mip block 2 requirements for the new loi scope in the
      same way as the rest of the original contract.
      during negotiations saab has additionally delivered:
      1. a mip block 2 analysis in the 4 additional functional areas requested in the loi and
          its consequences.
      2. a mip block 2 requirement specification according to the 4 areas described in the
          loi.
      3. a new approach to the requirements definition requested by dalo, and an example
          of requirement specification of the four areas described in the loi.
      4. a proposal for the mapping of the requirements to the operational scenarios and the
          slt test cases.
      saab does not understand what else needs to be described or how this can be better de-
      tailed. please put the needs in writing to us for further understanding.
      this is seen by saab as change of interpretation by dalo of the loi requirement, nev-
      ertheless saab has undertaken the additional deliveries and commited to the new me-
      thodology in “good faith” to attempt to meet dalo‟s needs. the msrs link has never
      been a contractual requirement and is not an obvious activity in the requirements speci-
      fication for mip block 2.
      unfortunately the re-presentation of the mip requirements from the current contract
      with the additional msrs linking was not identified until very late in the negotiation
      process and consequently the engineering process is not able to be completed prior to
      contract signature.
      saab has proposed a schedule which would provide dalo with full visibility and inte-
      raction during the finalization of the translation of the requirements and their linking to
      the operational scenarios and slt test requirements. as this translation does not in-
                                              - 14 -
      clude any additional functionality other than that introduced by the loi. saab believes
      that the contract baseline is established.
      concern 3:
      saab answer:
      saab understands from the loi that the high degree of mip compliance to be delivered
      under the contract is defined by the combination of the functionality from:
      a. the existing contract, and
      b. the additional functionality defined from the loi.
      to this end saab is representing the mip requirements from the current contract with
      the additional msrs linking and links to the slt and operational scenarios.
      it appears from your continued statements on this matter that this still may not meet
      your needs – but saab is not aware of any additional steps we can undertake to further
      clarify dalo„s needs. please put the needs in writing to us for further understanding.”
syn og skøn
der er til brug for sagens behandling i højesteret indhentet skønserklæring af 16. november
2012 fra skønsmændene torben falholt og carsten gomard. af erklæringen fremgår:
      ”skønstema - svar på parternes spørgsmål
      introduktion
      nærværende dokument er udarbejdet af skønsmændene carsten gomard og torben
      falholt i deres arbejde med højesterets sag 309/2010 på baggrund af skønstema af 6.
      marts 2012. sagen står mellem forsvarets materieltjeneste og saab ab - herefter
      parterne.
      følgende personer har deltaget i udarbejdelsen af svarskriftet: rune funch søltoft og
      poul marcussen. begge var under udarbejdelsen ansatte som funktionærer i virksomhe-
      den asseco danmark a/s.
      læsevejledning
      parterne har udviklet et skønstema med en række spørgsmål som besvares i nærværende
      dokument. til hver af besvarelserne er spørgsmålet eller en forkortet udgave heraf (ved
      lange spørgsmål) indledningsvis gentaget. for spørgsmålenes fulde og dækkende ordlyd
      henvises til skønstemaet.
      kommentarer fra skønsmænd
      vi har som udpegede skønsmænd i sagen 309/2010 (højesteret) nedenfor besvaret de af
      parterne stillede spørgsmål jf. skønstema af 6. marts 2012.
      besvarelsen har fundet sted efter gennemgang af sagens dokumenter og på baggrund af
      besvarelserne af de af os stillede spørgsmål til parterne samt visning af dele af systemet
      under en præsentation afholdt hos kromann reumert d. 11. september 2012 med delta-
      gelse af repræsentanter fra begge parter i sagen.
                                            - 15 -
     vi skal gøre opmærksom på, at vi ikke under arbejdet med besvarelsen af spørgsmålene
     ikke har inspiceret den leverede løsning, og vi har ikke gennemført egentlige test eller
     afprøvning af systemet eller gennemgang af kode og kodedokumentation. besvarelsen
     er således i al væsentlighed baseret på den forelagte skriftlige dokumentation i sagen
     (kontrakt, kontraktsbilag, leverancebilag, referater og korrespondance mellem parterne)
     og ikke på en egentlig teknisk gennemgang og afprøvning af den udviklede løsning.
     vores svar er udtryk for vores overbevisning og vurderinger på baggrund af vores fag-
     lige kompetencer og erfaringer i forhold de dokumenter m.v. vi har haft adgang til med
     fokus på de dokumenter, som parterne specifikt har henvist under de enkelte spørgsmål,
     og under disse omstændigheder udtryk for vores bedste saglige skøn.”
af skønstemaet fremgår, at skønsmændene bedes svare på følgende spørgsmål 1:
     ”1. spørgsmål relateret til den overordnede struktur i systemet og sammenhængen mel-
     lem mip- og bdm-funktionaliteter og de øvrige funktionaliteter i daccis
     1.1 skønsmanden bedes, på et overordnet plan, beskrive de trin, der typisk skal tages i
     en udviklingsproces, hvor et virksomt, operationelt system skal udvikles i overensstem-
     melse med brugerkrav. skønsmanden bedes i tilknytning hertil oplyse, om den såkaldte
     "v-model" sædvanligvis anvendes ved udvikling af et system som daccis, samt i be-
     kræftende fald beskrive indholdet af modellen.
     a) (ad appellantens spørgsmål 1.1) skønsmanden bedes efter gennemgang af do-
     kumenterne "daccis 6 project master plan" (sagens bilag aay), "daccis 6.6+
     project management plan" (sagens bilag aaz) og "daccis 6.6+ quality assurance
     plan" (sagens bilag aaæ) samt den dokumentation og eventuellespørgsmål til parterne,
     skønsmanden måtte finde nødvendig, redegøre for, om den aftalte og reelt fulgte udvik-
     lingsmodel for daccis var i overensstemmelse med god it-skik på det tidspunkt, hvor
     den aftaltes henholdsvis fulgtes.
     1.2 skønsmanden bedes besvare spørgsmål a) alternativt ud fra den udviklingsmodel for
     daccis, der kan udledes af de fremlagte bilag, uden hensyn til hvad skønsmanden
     måtte mene, der var aftalt mellem parterne vedrørende valg af udviklingsmodel.
     1.3 skønsmanden bedes orientere sig i materialet på https://mipsite.lsec.dnd.ca i folde-
     ren public document library under baseline_2.0 og overordnet beskrive den funktion,
     mip interoperabilitet (i mip block 2 regi) tilfører et command and control (c2) sy-
     stem som daccis.
     b) (ad appellantens spørgsmål 1.3) skønsmanden bedes gennemgå open systems
     interconnection reference model (osi-modellen) udviklet af international organization
     for standardization (iso) re (iso 7498-1, se f.eks. http://da.wikipedia.org/wiki/osi-
     model). på den baggrund bedes skønsmanden kort redegøre for de syv niveauer (lag),
     som modellen inddeler kommunikation mellem it-systemer i, samt på hvilke af disse
     niveauer hhv. mip compliancy og replication kan indplaceres (punkt 7.24 og 7.25 i
     bilag 3 til dacciskontrakten, samt anneks d hertil, sagens bilag 1).
     c) (ad appellantens spørgsmål 1.3) skønsmanden bedes gennemgå dokumenterne på
     https://mipsiteisec.dnd.ca i folderen public document library under "baseline_2.0",
     særligt "mtemp-tewg-edition 2.2", "msltp-tewg-2.1 draft og "meb2r-nl-msg-
                                       - 16 -
edition2_1 060608 1400" (afsnit 4 benævnt "block two testing"). skønsmanden bedes
ligeledes gennemgå bilag aaaa samt indstævntes beskrivelse af daccis-kontraktens
opdeling af mip "interoperabilitet" i mip replikering og mip compliancy i indstævntes
ankesvarskrift af 6. december 2010, punkt 2.1.3. på den baggrund bedes skønsmanden
redegøre for de forskellige niveauer af interoperabilitet i mip block 2 og relatere
("mappe") disse niveauer til de to niveauer anvendt i daccis 6.6-kontaktens kravspe-
cifikation, mip replikering og mip compliancy, (punkt 7.24 og 7.25 i bilag 3 til dac-
cis-kontrakten, samt anneks d hertil, sagens bilag 1).
d) (ad appellantens spørgsmål 1.3) skønsmanden bedes gennemgå dokumenterne
på https://mipsiteisec.dnd.ca i folderen public document library under "base- line
2.0", særligt" mtemp-tewg-edition 2.2", "msltp-tewg-2.1 draft" og " meb2r-
nl-msg-edition2_1 060608 1400" (afsnit 4 benævnt "block two testing") (fælles),
"mslt-annex c 1 -mslti dem s1 final 2.1
"mslt-annex c2-mslt1dem s2 final 2.1" og "mslt-annex c3- mslt1dem s3 fi-
nal 2.1" (mslt1), "mslt-annex d 1-mslt2dem_s1 final 2.1", "mslt-annex d2-
mslt2dem s2 final 2.1" og "mslt-annex d3- mslt2mem final 2.1" (mslt2), "m—
slt-annex e1-mslt3_final 2.7" (mslt3), samt alle dokumenterne i "olt1.zip",
"olt2.zip" og "olt3.zip" (olt) og bilag aaaa. på den baggrund bedes skønsmanden
redegøre for følgende:
i. hvordan afvikles testen mslt i og hvilke niveauer af interoperabilitet af-
prøves ved denne test.
2. hvordan afvikles testen mslt2 og hvilke niveauer af interoperabilitet afprøves ved
denne test.
3. hvordan afvikles testen mslt3 og hvilke niveauer af interoperabilitet afprøves ved
denne test.
4. hvordan afvikles testen olt og hvilke niveauer af interoperabilitet afprø-
ves ved denne test.
5. forudsætter testene mslt3 og olt anvendelsen af deltagernes command
and control systemer, i danmarks tilfælde daccis?
6. hvilke niveauer af interoperabilitet er omfattet af kravene cor600,
cor601 og c0r602 under overskriften "replication" i punkt 7.25 i bilag 3 til daccis-
kontrakten, samt anneks d hertil (sagens bilag 1).
7. hvad er forskellen mellem på den ene side niveauet af interoperabilitet omfattet af
kravene cor600, cor601 og c0r602 og på den anden side niveauet af interoperabi-
litet omfattet af kravene cor600x, cor601x og cor602x.
8. hvilke niveauer af interoperabilitet er omfattet af kravene cor675x,
cor676x og cor678x under overskriften "mip compliancy" i punkt 7.24 i bilag 3 til
daccis-kontrakten, samt anneks d hertil.
                                       - 17 -
9. hvad er forskellen mellem på den ene side niveauet af interoperabilitet omfattet af
kravene cor600, cor601 og c0r602 og på den anden side niveauet af interoperabi-
litet omfattet af kravene cor675x, cor676x og cor678x.
1.4 skønsmanden bedes besvare spørgsmål c) og d) alternativt ud fra den forudsætning,
at der ikke nødvendigvis eksisterer flere "niveauer" af interoperabilitet, som defineret af
saab jf. spørgsmål c).
1.5 skønsmanden bedes, ud fra mip block 2 datamodellen (c2iedm) og en orientering
i dokumenterne mtidp (mip technical interface design plan) og mir (mip imple-
mentation rules) på https://mipsite.lsec.dnd.ca i folderen public document library un-
der baseline_2.0, beskrive kompleksiteten i mip block 2, herunder beskrive eventuelle
ligheder med andre, kendte typer af informations- udvekslingsstandarder, samt hvor
kompleks mip block 2 er i sammenligning med disse.
1.6 hvis det lægges til grund, at datamodellerne for mip block 2 og daccis er for-
skellige, bedes skønsmanden beskrive, hvordan interoperabilitet i regi af mip kan ud-
vikles, herunder beskrive om og i hvilket omfang det vil være nødvendigt at udvikle et
såkaldt oversættelses- eller integrationslag.
e) (ad appellantens spørgsmål 1.6) skønsmanden bedes gennemgå dokumentet
"msltp-tewg-2.1 draft" på https://mipsite.lsec.dnd.ca i folderen public document
library under "baseline_2.0". på den baggrund bedes skønsmanden redegøre for,
hvorvidt et oversættelseslag mellem daccis og mip block 2 synes forudsat af mip-
samfundet. skønsmanden bedes videre redegøre for, om oversættelseslag ("gateway")
normalt anvendes ved kommunikation mellem itsystemer programmeret efter forskel-
lige standarder. skønsmanden bedes i den forbindelse redegøre for, hvad alternativet til
et oversættelseslag ville være, og hvilke konsekvenser en ændring af den fælles kommu-
nikationsstandard (her mip block 2) ville have for det bagvedliggende system (her
daccis), hvis der ikke anvendes et oversættelseslag.
1.7 skønsmanden bedes - uafhængigt af kontraktforholdene - beskrive, på hvilket trin i
udviklingsprocessen indarbejdelsen af funktionaliteter relateret til mip bør ske, hvis et
virksomt system i overensstemmelse med kravspecifikationen skal opnås, således at ri-
sici i udviklingsprocessen minimeres.
f) (ad appellantens spørgsmål 1.7) skønsmanden bedes besvare appellantens
spørgsmål 1.7 vedrørende "interoperabilitet" sådan, at der sondres mellem henholdsvis
1) mip replikering og 2) mip compliancy.
g) (ad appellantens spørgsmål 1.7) skønsmanden bedes forudsætte, at daccisog mip
block 2 ikke er specificeret samtidig, men derimod (i) at daccis er blevet udviklet si-
den 1998 efter nationale standarder, (ii) at mip block 2 blev færdigspecificeret af mip-
samfundet i 2006 og, (iii) at ønsket om mip interoperabilitet med udenlandske hæren-
heders egne nationale systemer først blev introduceret i august 2005, jf. processen be-
skrevet i punkt 2.1.3 i indstævntes ankesvarskrift af 6. december 2010, og på den bag-
grund besvare appellantens spørgsmål 1.7 samt indstævntes spørgsmål f).
1.8 skønsmanden bedes besvare spørgsmål g) alternativt ud fra den forudsætning, at
daccis' udveksling af information med internationale systemer var forudsat allerede i
kontrakt af 10. marts 1998 mellem hmak og mærsk data a/s, hvilken kontrakt saab
                                             - 18 -
     overtog, og at mip block 2 konkret blev introduceret i kontrakten ved fmt's bestilling
     af daccis 6.2 den 30. juni 2004, jf. fmt's processkrift 3 af 18. november 2011 s. 9
     sidste afsnit.
     1.9 skønsmanden bedes orientere sig i daccis 6.6 ssrs basis data manager (bilag
     75) og overordnet beskrive den funktion, basis data manager (bdm) udgør i et system
     som daccis.
     h) (ad appellantens spørgsmål 1.9) skønsmanden bedes redegøre for:
     1. forskellen mellem bdm og basis data.
     2. om et system som daccis kan testes operationelt uden tilstedeværelsen af basis
     data.
     3. særligt under hensyntagen til kravspecifikationen for daccis (anneks d, bilag 3 til
     daccis-kontrakten, sagens bilag 1) samt "system design specification for daccis"
     (sagens bilag aam), hvilke krav i kravspecifikationen for daccis, der relaterer sig til
     bdm og hvilke der relaterer sig til basis data. skønsmanden bedes redegøre for, i hvil-
     ken grad hvert krav relaterer sig til hhv. bdm og basis data.
     1.10 skønsmanden bedes beskrive - uafhængigt af kontraktforholdene - på hvilket trin i
     udviklingsprocessen indarbejdelsen af funktionaliteter relateret til bdm bør ske, hvis et
     virksomt system i overensstemmelse med kravspecifikationen skal opnås, således at ri-
     sici i udviklingsprocessen minimeres.
     i) (ad appellantens spørgsmål 1.10) skønsmanden bedes besvare appellantens
     spørgsmål 1.10 vedrørende "bdm" sådan, at der sondres mellem hhv. 1) basis data
     manager og 2) basis data.
     1.11 i forlængelse af svaret på spørgsmål 1.7 og 1.10 bedes skønsmanden belyse de
     konsekvenser, det har eller kan få for udviklingsprocessen, såfremt indarbejdelsen sker
     senere i forløbet end angivet.
     j) (ad appellantens spørgsmål 1.11) i forlængelse af svaret på appellantens
     spørgsmål 1.8 og 1.10 samt indstævntes spørgsmål f) til i) bedes skønsmanden redegøre
     for i hvilken grad, det får konsekvenser for udviklingsprocessen, såfremt indarbejdelsen
     af henholdsvis 1) mip replikering, 2) mip compliancy, 3) basis data og 4) basis data
     manager sker på et andet tidspunkt i forløbet end angivet i svarene.”
af skønsmændenes svar på spørgsmål 1 fremgår følgende:
     ”1.1 skønsmanden bedes, på et overordnet plan, beskrive de trin, der typisk skal tages i
     en udviklingsproces
     de procestrin, der typisk skal gennemløbes, er konceptudvikling, kravspecifikation,
     analyse, design, udvikling og test, integrationstest, systemtest, accepttest og idriftsæt-
     telse. forud for idriftsættelse forventes en større opgave omkring etablering af infra-
     struktur, som kan/skal medvirke til at imødekomme en række non-funktionelle krav.
     etablering af en forsvarlig dækkende infrastruktur til en forsvarlig operation af et it-sy-
     stem er ikke medtaget i vores besvarelse.
                                        - 19 -
kravspecifikationen kan opdeles i funktionelle og non-funktionelle krav. såfremt der er
specifikke krav til valg af teknik, f.eks. en speciel server eller en speciel protokol, kan
dette anføres som et non-funktionelt krav. non-funktionelle krav dækker dog også em-
ner som oppetid og transaktionsmængder, antal af samtidige brugere (herunder transak-
tionsmængder på kritiske applikationsinterfaces som måtte interagere med systemet).
det er sædvanligt at anvende v-modellen som procesmodel for skabelsen af et system
som daccis. en tegning af v-modellen findes under svaret til spørgsmål a) umiddel-
bart herunder.
da daccis er et safety-critical system (et “sikkerhedskritisk system”), bør v-modellen
eller anden gængs procesmodel til sædvanlig systemudvikling ikke stå alene. udvikling
af et sikkerhedskritisk system medfører: krav om hazardanalyser, skærpede krav om
sporbarhed, nye funktionelle og non-funktionelle krav, samt skærpede procedure om-
kring validering og verificering. hazardanalysernes rolle er at identificere og afbøde ri-
sici. det er oplagt, at non-funktionelle krav har en vigtig rolle i et sikkerhedskritisk sy-
stem bl.a. for at sikre systemets robusthed under utilsigtede omstændigheder. et eksem-
pel på et sikkerhedskritisk projekt, hvor man løbende har måttet revurdere sikkerheds-
aspekter er københavns metro, hvor f.eks. introduktionen af førerløse togsæt medførte,
at man måtte genoverveje systemets sikkerhed.
disse krav til tilrettelæggelsen og udførelsen af daccis-projektet, der
følger af dets status som et sikkerhedskritisk system, kan ikke ses at være opfyldt. vi
mener, at parterne burde have lagt langt større vægt på dette perspektiv i såvel aftale-
tekst som den reelt gennemførte proces. dette er en klar afvigelse fra god it-praksis,
som i sig selv betyder, at et evt. “færdigt” system udviklet ved de beskrevne og fulgte
processer og metoder ikke ville kunne betragtes som et operationelt system til sikker-
hedskritiske formål men måtte betragtes som et system til brug for træning, undervis-
ning og som prototype.
a) skønsmanden bedes redegøre for, om den aftalte og reelt fulgte udviklingsmodel for
daccis var i overensstemmelse med god it-skik
                                          - 20 -
  tegningen ovenfor viser hvorledes projektets dokumenter (ud fra bilag aay project
  master plan) er placeret i v-modellen. “kontrakten” og “hazardanalyse” er indsat i kur-
  siv og er ikke med i aay men sat ind for at vise, hvor disse passer i v-modellen. v-
  modellen kan bruges som en iterativ process, hvor v-forløbet udføres gentagne gange
  gennem projektforløbet. venstre ben af v-modellen definerer, hvorledes kontraktens
  overordnede krav analyseres, opdeles, spores og detaljeres gradvis, indtil et konkret
  modul kan programmeres/kodes. højre ben af v-modellen definerer, hvorledes det veri-
  ficeres, at de programmerede moduler lever op til specifikationerne på alle niveauer,
  integreres korrekt og fungerer i sammenhæng og ultimativt (svarende til kontrakt-ni-
  veau) giver et anvendeligt, operationelt system i drift i virkeligheden.
  det har været svært at finde dokumentation for hvordan “v‟et” kalendermæssigt er om-
  sat til praksis. hvornår man er startet, og hvornår man er sluttet. hvor mange gennem-
  løb af v‟et man har foretaget over de 10 år, hvor udviklingen har pågået, og hvornår
  blev v-modellen indført.
  hverken den beskrevne eller fulgte model er i overensstemmelse med god it-skik. med
  hensyn til den faktisk fulgte model, så er systemet blevet til ved en proces, der har
  strukket sig over lang tid. sandsynligvis har proces og metode (og i hvert fald teknik)
  ændret sig en del, siden man påbegyndte udviklingen, så fokus for de fremlagte doku-
  menter formodes at være den seneste udvikling, der har fundet sted. man må formode,
  at de ældre dele af koden er blevet til i en proces, der har været mindre stringent og
  mindre komplet beskrevet end den del af processen, vi har kigget på.
  der er synlig forskel på den fulgte model og den beskrevne model, hvilket i sig selv er
  en elementær afvigelse fra god it-skik. det er eksempelvis en krumtap i certificering af
  projektorganisationers modenhed, at et projekts processer er veldokumenterede og do-
  kumenterbart efterleves i praksis.
  de foreliggende dokumenter er ikke altid sammenhængende og komplette, og de inde-
  holder talrige referencer, der dog ikke altid bibringer læseren en fornemmelse af at krav
  (kan) spores systematisk gennem materialet. ved en række lejligheder efterlades læse-
  ren med det indtryk, at dokumenterne er udarbejdet i den modsatte rækkefølge i forhold
  til v-modellens ånd og bogstav. eller med andre ord: i en række tilfælde synes krav- og
  designdokumentation at være udarbejdet efter, at den faktisk implementering af (del-
  )systemet har fundet sted.
  den manglende eksplicitte hensyntagen til, at systemet er sikkerhedskritisk, er som tid-
  ligere nævnt under spørgsmål 1 også en afvigelse fra god it-skik.
  de foreliggende aftaledokumenter er generelt udarbejdet på et meget overordnet niveau.
  ved udviklingen af et system af daccis‟ omfang, hvad angår funktionalitet, tids-
  ramme og økonomiske ramme, ville god it-skik foreskrive en langt mere detaljeret af-
  tale mellem parterne. denne observationer gælder en lang række aspekter, herunder
  kravspecifikation, use cases og projektplaner, som jo også efterfølgende har givet an-
  ledning til diskussioner parterne imellem få måneder efter aftalens indgåelse.
  herunder følger en række mere detaljerede eksempler på afvigelse fra god skik:
 der er ikke kongruens mellem dokumenterne. f.eks. har sds (sagens bilag aam) en
  anden opfattelse af hvilke krav, der er i scope for bdm, end sagens bilag 75 har. der er
  i begge dokumenter medtaget krav, der ikke er medtaget i det andet dokument.
                                            - 21 -
 i bilag aay afsnit 3.6.3.1 beskrives det, hvordan der arbejdes med trace (sporbarhed).
  trace af krav er meget mangelfuldt beskrevet i aay, og der er uoverensstemmelser
  dokumenterne imellem. det er ikke berørt hvordan krav traces (spores) til
  implementering, og det er svært at se, hvordan krav traces til test eller omvendt. det er
  netop denne sporbarhed, det at man kan følge krav ned i “v-et” og op i “v-et”, som
  kendetegner modellen. når sporbarheden er væk, forsvinder gennemskueligheden. dette
  forhold bidrager væsentligt til de fundamentale forskelle mellem parternes opfattelser af
  krav og forventninger. mere stringens i sporbarheden kunne have bidraget til at forenkle
  diskussionerne.
 factory acceptance testing bilag aay afsnit 3.5.1.3
  der stilles krav om en test per krav, hvilket er utilstrækkeligt. hvert krav kan have
  vilkårligt mange test relateret til sig for at sikre, at det og systemet lever op til formålet.
  med krav af overordnet karakter, er en test per krav under alle omstændigheder et meget
  lavt antal. beskrivelsen af factory acceptance test er svag med med flere referencer,
  som gør det meget svært at forholde sig til for en læser med f.eks. en review-rolle.
 der mangler sstrer (sub system test reports) til dokumentation af testgennem-
  førelse.
  den i sagens bilag aay beskrevne model omtales som en v-model men har en række
  mangler i forhold til gængs opfattelse af en v-model.
  afvigelser fra v-modellen som modellen er beskrevet i bilag aay er dokumenteret i
  bilag 1.
  1.2 skønsmanden bedes besvare spørgsmål a) alternativt ud fra den udviklingsmodel for
  daccis, der kan udledes af de fremlagte bilag
  svaret til a) er også gældende som svar for 1.2.
  1.3 skønsmanden bedes overordnet beskrive den funktion, mip interoperabilitet tilfører
  et c2-system
  c2-systemer (c2is) er bistår forsvarspersonale med informationer om militære enheder
  og operationer. c2is fastholder informationer om placering af tropper og materiel samt
  oplysninger om mulige ændringer (hypoteser).
  hensigten med mip er at give separate militære enheder (f.eks. lande) med hver deres
  c2is mulighed for at lave en struktureret udveksling af information. mip hjælper der-
  med til koordination og udveksling af operationel information mellem allierede parter
  og deres c2is‟er.
  block 2 (mip block 2) tilføjer c2is‟er mulighed for at kommunikere med andre syste-
  mer, der understøtter mip block 2.
  b) skønsmanden bedes kort redegøre for de syv niveauer (lag) i osi samt på hvilke af
  disse niveauer hhv. mip compliancy og replication kan indplaceres
  tegning nedenfor viser de 7 lag i osi modellen (kilde:
  http://www.infrateket.dk/4a/ap009-1.htm).
                                            - 22 -
   lay           applica-           program, der tager imod eller sender data
   er 7          tion
   lay           presen-            dataformateringslag med oversættelse mellem forskellige
   er 6          tation             standarder for datarepræsentation
   lay           session            opretter, håndterer og lukker for forbindelsen
   er 5
   lay           transport          står for pålidelig dataflytning over netværk
   er 4
   lay           network            håndter dataruten gennem netværket
   er 3
   lay           data link          procedure og funktionalitet til at flytte data mellem net-
   er 2                             værksenheder.
   lay           physical           det fysiske netværk f.eks. kabler.
   er 1
  generelt er det i sagens dokumenter ikke muligt at finde en entydig og udbredt defini-
  tion af begreberne “replication” og “compliancy/compliance/compliant”. det præciseres
  derfor, at der herunder sigtes eksplicit til kravene i afsnit “7.24 mip compliancy” hhv.
  “7.25 replication”, når det forsøges at mappe disse krav til osi-modellens lag.
  kravene i punkt “7.24 mip compliancy” og “7.25 replication” i bilag 3 til daccis-
  kontrakten (sagens bilag 1) samt anneks d hertil kan ikke mappes ind på distinkte lag i
  osi modellen. der er krav i begge afsnit, der hører til i lag 6, og krav i begge afsnit, der
  hører til i lag 7. der er i begge afsnit krav, der slet ikke er relateret til osi modellen.
  gennemgang af kravene i punkt 7.24
 cor675x omhandler både transmission og grafisk repræsentation. dette indebærer, at
  “mapping” mellem daccis data format og mips format er påkrævet. i de tilfælde hvor
  dataformatet er det samme, er denne mapping blot “pass through”, og denne mapping
  hører til i lag 6 og selve transmissionen i de underliggende lag. den grafiske
  repræsentation (rendering) er et applikationsanliggende og hører til i lag 7.
                                           - 23 -
 cor676x omhandler applikationsfunktionalitet (oprettelse af oig‟er) og dataformat.
  førstnævnte er ikke relateret til osi, dvs. funktionaliteten kunne bestå uden
  kommunikation. sidstnævnte er indirekte relateret til osi, idet den vil påvirke
  implementationen af syntakslaget (lag 6).
 cor678x omhandler dataformat og relaterer sig i osi sammenhæng til lag 6.
  gennemgang af kravene i punkt 7.25
 cor600 stiller krav til dataformat ifm. udveksling af data, og dette er et krav til lag 6.
 cor601 og cor601x stiller krav til dataformat og udveksling af data. det er begge
  krav til lag 6. da det samtidig også er krav til forskellige versioner af dataudvekslingen,
  er dette implicit et designkrav om at kunne håndtere flere dataformater. designkrav
  opstår af både de krav, der stilles til nuværende version, og tager sandsynlige ændringer
  med i scope for designet. dvs. god skik vil være at have et let udskifteligt lag 6
  afhængig af konteksten for kommunikationen.
 cor71 har ingen relation til osi modellen
 cor91 stiller krav til brugerfunktionalitet ifm. dataudveksling. dette er en del af lag 7.
  da der lægges op til at bruge tcp som transportprotokol, så afviger implementationen
  fra osi modellen på de lag der ligger under lag 6, idet tcp til dels slår lag 5 og 4
  sammen. se f.eks.
  http://en.wikipedia.org/wiki/osi_model#comparison_with_tcp.2fip_model.
  c) niveauer af interoperabilitet i mip i forhold til kravspecifikationen i forhold til krav-
  specifikationens begreber om replication og compliancy
  i sagens dokumenter er det som tidligere nævnt ikke muligt at finde en entydig og ud-
  bredt definition af begreberne “replication” og “compliancy/compliance/compliant”.
  det præciseres derfor, at begreberne her anvendes som defineret ved opdelingen af
  mip-kravene i kravspecifikationen i afsnit “7.24 mip compliancy” hhv. “7.25 replica-
  tion”.
  i mip-materialet defineres “niveauer” (levels) af interoperabilitet som en del af beskri-
  velsen at det testforløb, der skal vise at et nationalt c2-system er kompatibelt med mip-
  samfundets krav. testplanen for mip definerer niveauerne “teknisk interoperabilitet”,
  “procedural interoperabilitet” og “operationel interoperabilitet”.
 teknisk interoperabilitet verificeres gennem testen mslt1 og indebærer, at en national
  implementering af en mip-gateway kan udveksle dataelementer korrekt med en
  modpart.
 procedural interoperabilitet verificeres gennem testen mslt2 og indebærer, at en
  national implementering af en mip-gateway teknisk og funktionelt korrekt kan udveksle
  strukturerede data mellem egen implementering af mip-datamodellen c2iedm (ref.
  block 2) og modparternes implementering af den samme datamodel, c2iedm (igen
  specifikt block 2)
 operationel interoperabilitet verificeres gennem testene mslt3 og olt. mslt3
  verificerer, at data kan skabes og behandles af brugere i en national c2 og meningsfyldt
  kan udveksles med modparters c2-systemer, der ligeledes betjenes af brugere. olt
  testen forudsætter derudover testforhold, der ligner en faktisk operationel situation.
  det fremhæves nogle gange i denne rapport, at kravspecifikationen er udformet på et
  vel overordnet niveau i forhold til at være et komplet grundlag for at definere og im-
  plementere et virksomt system. dog er der grundlag for at sige, at kravene i afsnit “7.25
  replication” fører i retning af kunne bestå af mip-tests mslt1 og mslt2 og kravene i
                                         - 24 -
afsnit “7.24 mip compliancy” fører i retning af at kunne bestå mip-test mslt3 og si-
denhen olt.
d) spørgsmål om sammenhænge mellem mip-samfundets test, interoperabilitet og
kravspecifikationens krav
1)
mslt1 gennemføres i 3 dele: test af henholdsvis “dataoverførsel og protokol”, “ud-
veksling af operationelle data” og “management events”. testplanen beskrevet i
msltp-tewg 2.1 draft omtaler dette niveau som “technical interoperability”.
2)
mslt2 gennemføres i 2 dele: test af “multilaterale test cases and data replication” og
“technical procedures”. testplanen beskrevet i msltp-tewg 2.1 draft omtaler dette
niveau som “procedural interoperability”.
3)
mslt3 indebærer en bred mængde test af funktionelle og tekniske aspekter af interope-
rabilitet og en prætest af hardware- og softwarekonfigurationen for olt. det er ikke
helt entydigt, om mip-samfundet anvender udtrykket “operationel interoperabilitet bet-
ween c2is‟s” om succesfuld deltagelse i denne test. en tilsvarende fortolkning kan
anlægges for succesfuld deltagelse i olt.
4)
testen olt gennemføres som et uddrag af de forudsatte tests (msltp 1+2+3), der
gennemføres under virkelighedsnære forhold. efter succesfuld gennemførelse af testen
vil daccis have opnået interoperabilitetsgraden kaldet 4.a.
5)
ja, både mslt3 og olt forudsætter anvendelse af deltagernes command and control
systemer.
hele testsetuppet i msltp-tewg-21 draft tager udgangspunkt i at afprøve kommuni-
kationen mellem c2is systemer. formålet er således beskrevet:
“the mip system level test plan (msltp) describes the tests to be carried out within
the multilateral interoperability programme to prove interoperability between the c2is
of the participating mip nations by means of physical and logical interfaces”.
målet med mslt 3 beskrives således:
“the purpose of this test level is to test the timely end to end transfer of operationally
meaningful information between national c2iss”.
målet med olt er at bruge systemerne i operationelle scenarier og i kontekst af slut-
brugerne for at se, om slutbrugerne kan bruge systemerne i operationelle sammen-
hænge. dette indebærer, at det er c2is, der benyttes.
6)
spørgsmålet er beslægtet med spørgsmål c), hvor der bl.a. svares, at kravspecifikationen
er udformet på et overordnet niveau i forhold til at være et komplet grundlag for at defi-
nere og implementere et virksomt system, men at der dog er grundlag for at sige, at kra-
vene i afsnit “7.25 replication” fører i retning af kunne bestå af mip-tests mslt1 og
mslt2. her stilles stort set samme spørgsmål blot for en delmængde af kravene under
                                         - 25 -
“7.25 replication”, og svaret er følgelig, at kravene cor600, cor601 og cor602 le-
der tankerne i retning af mslt1 og mslt2 uden dog, at disse 3 krav definerer et “ni-
veau af interoperabilitet”.
7)
de opregnede krav (cor600, cor601, cor602) hhv kravene (cor600x, cor601x,
cor602x) definerer ikke specifikke niveauer af interoperabilitet, se også svaret til
punkt 6) umiddelbart herover.
forskellen på cor601 og cor601x er hvilken version af mip, de relaterer sig til: blok
2 hhv blok 3. cor602 og cor602x definerer i hvilken grad, mip/dem skal anvendes
hhv. supporteres. cor600x eksisterer ikke.
8)
også dette spørgsmål er beslægtet med spørgsmål c), hvor der bl.a. svares, at kravspeci-
fikationen er udformet på et vel overordnet niveau i forhold til at være et komplet
grundlag for at definere og implementere et virksomt system, der er i afsnit “7.24 mip
compliancy” krav der skal overholdes for at at kunne bestå mip-test mslt3 og siden-
hen olt. samtidig er der krav, der ikke relaterer sig til mslt1-3. f.eks. indebærer
cor676x krav om at kunne tegne givne symboler på skærmen.
9)
svaret er en simpel sammenstilling af svarene på punkt 6) og 8) umiddelbart herover:
kravene cor600, cor601 og cor602 leder tankerne i retning af mslt1 og mslt2
uden dog, at disse 3 krav definerer et “niveau af interoperabilitet”. kravene i afsnit
“7.24 mip compliancy” fører i retning af at kunne bestå mip-test mslt3 og sidenhen
olt
1.4) supplerende spørgsmål om sammenhænge mellem mip-samfundets test, interope-
rabilitet og kravspecifikationens krav
i mip-materialet defineres “niveauer” (levels) af interoperabilitet som en del af beskri-
velsen at det testforløb, der skal vise at et nationalt c2-system er kompatibelt med mip-
samfundets krav. disse definitioner af “niveauer” er anvendt som udgangspunkt for de
ovenstående svar, og det ville forekomme meget konstrueret at forudsætte en situation,
hvor mip-materiale var udformet anderledes. svarene til punkt c) og d) er derfor også
dækkende for 1.4).
1.5) mip i forhold til andre informationsudvekslingsstandarder: ligheder og sammenlig-
ning af kompleksitet
mip kan på nogle områder sammenlignes med andre protokoller for udveksling af data
og præsentation af data. f.eks. kunne man sammenligne med http for udveksling af
data og html for præsentation af data. hvor de enkelte nationers c2is kan sidestilles
med forskellige browsere. de enkelte c2is/browsere vil til tider have forskellig opfat-
telse af specifikationerne. idet datamodellen for mip er større end for html, må mip
anses for mere kompleks på præsentationsniveauet. dog er den organisatoriske opgave
trods alt enklere, idet alle leverandører af c2is formentlig har fælles mål, hvor leveran-
dørerne af browsere har modstridende interesser.
                                                      - 26 -
        mip kan også sammenlignes med andre standarder for interfaces såsom bbr1 inter-
        face. begge formater har til formål at udveksle data mellem to parter. bbr og mip be-
        skriver et flow for udveksling af data. begge systemer er baseret på mange forskellige
        datatyper
        mip er mere kompleks, eftersom:
       mip har et i detaljen defineret data flow
       mip ikke har faste retningslinjer omkring f.eks kryptering af data.
       mip har væsentligt flere forretningsregler.
       mip har en unødvendigt kompleks dokumentation.
        1.6) hvordan udvikles interoperabilitet i mip-regi, evt med et oversættelses- eller inte-
        grationslag
        i et system hvor der er integration til eksterne systemer er det normalt at have et for-
        tolkningslag.
        dette hører hjemme i osi modellens lag 6 (præsentationslaget).
        det vil være god skik at implementere et oversættelseslag (“gateway”) mellem daccis
        og mip protokollen, og i det konkrete tilfælde er det den eneste gode og rimelige løs-
        ning.
        e) (ad spørgsmål 1.6) er et oversættelseslag forudsat af mip-samfundet, og hvilke kon-
        sekvenser ville et evt. alternativ have
        et oversættelseslag (“gateway”) er forventet af mip samfundet. mtidp-main-3.1.2.pdf
        figur 4.2 viser oversættelseslaget.
        hvis ikke der var et oversættelseslag, ville selv små ændringer af mip datamodellen
        kunne påvirke daccis datamodellen. et oversættelseslag mindsker risikoen for at
        dette sker og vil i øvrigt gøre det enklere at tilpasse det samlede daccis-system til
        ændringer i mip-standarderne. se også svaret til spørgsmål 1.6).
        1.7) på hvilket trin i udviklingsprocessen bør mip-funktionalitet indarbejdes
        jo tidligere i udviklingsprocessen en væsentlig funktionalitet integreres, desto mindre er
        risikoen for, at fejl påfører store omkostninger. uanset valgene af udviklingsproces og
        udviklingsmetode, vil det ved designet af daccis og daccis‟ datamodel være vigtigt
        at være bevidst om status for mip-samfundets datamodel(ler) og udviklingsplaner.
        dette vil mindske kompleksiteten af specifikt gateway‟en og de øvrige tværgående af-
        hængigheder. sent opdagede og/eller gennemførte ændringer i daccis som følge af
        mip-krav, kan vise sig meget ressourcekrævende.
        den valgte procesmodel (v-model) og den valgte udviklingsmetode (scrum) tager
        begge udgangspunkt i den tidlige indarbejdelse og afprøvning. en senere indarbejdelse
        end den tidligst mulige vil derfor være en afvigelse fra både procesmodellen og udvik-
        lingsmetoden. hvilket vil være i modstrid med god skik. det er her værd at bemærke, at
        procesmodellen, som den er beskrevet i bilag aay, tager elementer fra w-modellen
        med. w-modellen adskiller sig fra v-modellen ved at lægge endnu højere vægt på den
1
  bygnings- og boligregisteret blev i 2009 udbudt via et nyt it-system med en åben defineret brugergrænseflade
(til anvendelse såvel for personer som for andre it-systemer).
                                          - 27 -
tidlige afprøvning i form af skrivebords-reviews. den valgte procesmodellen vægter
således den tidlige indarbejdelse højt.
som udgangspunkt bør en funktionalitet implementeres i såkaldte vertical slices, således
at den funktionalitet i brugergrænsefladen, der er afhængig af mip, udvikles sammen
med mip og integreres løbende gennem hele udviklingsprocessen. brug af vertical sli-
ces er et af grundprincipperne for scrum, og det betyder, at v‟et i udviklingsproces-
sen gennemløbes mange gange i løbet af projektet.
alternativet til vertical slices er horizontal slices. i forhold til osi og mip er vertical
slices at implementere alt fra lag 1 til 7 for en enkelt funktionalitet (f.eks. udveksling af
oplysninger om ingeniørtropper fra anden c2 til symbolet bliver vist i daccis) mens
en horizontal slice ville være at implementere lag 1 fuldt derefter lag 2 og så fremdeles.
i praksis vil de nedre lag i osi-modellen (basal udveksling af data over netværk) blive
implementeret horisontalt, og de øvre lag omfattende kontraktens funktionelle og repli-
keringstekniske krav vil naturligt blive implementeret vertikalt. i forbindelse med olt
lægges der i mip sammenhæng også op til, at man udvikler og afprøver iterativt
(mtemp-tewg - edition 2.2 side 17). dette viser en ganske vidtgående præference
for vertikale slices i mip-samfundet, for man kunne argumentere for, at det vil være
praktisk omstændeligt på olt-niveau, der involverer virkelighedsnære scenarier og
flere involverede parter.
hvis projektet omvendt havde valgt vandfaldsmodellen som udviklingsmetode i stedet
for scrum, så ville indarbejdelsen om muligt skulle ske i analysefasen, som (i prin-
cippet) kun ville blive udført én gang.
f) (ad spørgsmål 1.7) på hvilket trin i udviklingsprocessen bør mip-funktionalitet indar-
bejdes, hvis der specifikt sondres mellem mip replikering og mip compliancy
svaret til 1.7 er uafhængigt af, om der med særligt eftertryk sondres mellem mip repli-
kering og mip compliancy, hvor begreberne her defineres ved kravene under over-
skrifterne til afsnit 7.25 hhv 7.24 i kravspecifikationen. en sådan sondring ændrer ikke
på, hvilken fremgangsmåde der er hensigtsmæssig ved udviklingen af systemet.
en sådan sondring ville desuden være i modstrid med den valgte udviklingsmetode
(scrum), der dikterer, at udviklingen struktureres efter overkommelige delleverancer
af funktionalitet, der kan afprøves og anvendes af brugere.
sondringen understreger dog et tilsyneladende paradoks i den foreliggende aftale og ud-
førelsen af projektet: aftalen definerer en vej hen imod en operationel accepttest, oc,
hvor der skal udveksles data med fremmed(e) c2-system(er). endvidere dikterer udvik-
lingsmetoden scrum vertikalt struktureret udvikling og test af mindre leverancer af
brugerfunktionalitet. det er vanskeligt at se, hvordan disse forhold kan harmonere med,
at kravene i afsnit 7.24 “mip compliancy” er fravalgt.
g) (ad spørgsmål 1.7) på hvilket trin i udviklingsprocessen bør mip-funktionalitet ind-
arbejdes, hvis ønsket om mip-interoperabilitet er kommet til sent i daccis-forløbet
mip bør i den kontekst udvikles på en sådan måde, at man løbende integrerer mip ind i
det eksisterende system. hvorledes denne integration sker er et designanliggende. som
udgangspunkt for designet bør man kigge på, om det er funktionalitet, der udskiftes el-
                                            - 28 -
  ler, om systemets funktionalitet udvides. i det omfang, mip funktionalitet skal erstatte
  eksisterende funktionalitet, gøres dette i så små delleverancer som muligt og ikke i et
  big bang. i de tilfælde, hvor mip funktionaliteten skal understøtte ny funktionalitet er
  svaret til 1.7 stadig gældende, og da enhver kommunikationsstak (herunder mip) må
  anses som et subsystem, bør ændringerne ikke have nogen indflydelse på systemets
  kerne, medmindre ændringer til mip specifikationer er i modstrid med eksisterende
  specifikationer og på den måde gør det umuligt at overholde begge specifikationer sam-
  tidig.
  mip samfundet har taget højde for dette bl.a. ved at forvente et oversættelseslag.
  1.8) på hvilket trin i udviklingsprocessen bør mip-funktionalitet indarbejdes, hvis ud-
  veksling af information med internationale systemer var forudsat fra starten
  implementeringen af det oprindelige system bør i den kontekst have taget højde for, at
  der må komme en implementation af mip (eller anden protokol) og eksplicit gøre de
  ovenfor omtalte “små delleverancer” lette at indføre i systemet. specifikt vil det være
  vigtigt, at
 kommunikationen med andre systemer bør allerede være baseret på et subsystem, og
  man kunne meget vel lægge designet op ad osi modellen eller tilsvarende. på den måde
  kan man nøjes med ændringer til et lag, hvis der kun er tale om ændringer af f.eks. data
  format
 daccis‟ datamodel designes med henblik på den fremtidige udveksling af data baseret
  på mip-samfundets datamodel. dette vil især gøre den meget omdiskuterede
  problemstilling om “mip compliancy” mere håndterbar
  1.9) beskriv basis data manager (bdm) i daccis
  basis data manager har to overordnede funktioner
  1.       vedligeholdelse af basis data (uc227 configure basis data)
  2.       vedligeholdelse af order of battle (uc68 maintain order of battle)
  ad 1) dette funktionsområde er oprettelse, nedlæggelse og ændring af data type, såsom
  hvilke typer af faciliteter eller materiel, der kan vælges mellem i (2)
  ad 2) her organiseres data typer i hierarkier, så som units og subordinate units
  h) (ad appellantens spørgsmål 1.9) skønsmanden bedes redegøre for:
  1) forskellen mellem bdm og basis data
  jvf. bilag 75, er basis data det katalog af typer, der er tilgængeligt. f.eks hvilke typer af
  faciliteter eller materiel, der er tilgængelig for maintain order of battle.
  bdm er det subsystem af daccis, der opretter og vedligeholder basis data.
  2) om et system som daccis kan testes operationelt uden tilstedeværelsen af basis
  data.
  nej. dette forekommer at være både indlysende og ubestridt.
  3) skønsmanden bedes redegøre for, i hvilken grad hvert krav relaterer sig til hhv. bdm
  og basis data.
  det var vist sig vanskeligt at formulere et direkte svar med blot en rimelig grad af sik-
  kerhed.
                                        - 29 -
der er ikke uenighed om, at bdm er det subsystem, der opretter og vedligeholder basis
data, og at basis data er det katalog af typer, der er tilgængeligt i daccis for registre-
ring af information om egne og fjendtlige enheder. parterne har dog hver sin opfattelse
af i hvilket omfang, basis data kan antages at være statisk ved brug af daccis og der-
med af behovet for bdm under almindelig operativ anvendelse. indstævnte giver ud-
tryk for, at daccis fødes med et sæt basis data og, at det er disse, der er til rådighed
ved registrering af informationer om egne og fjendtlige enheder. appellanten giver ud-
tryk for, at det er en dynamisk proces at skabe og ændre de typer af materiel, organisati-
oner mm, der skal beskrive den aktuelle situation for egne og fjendtlige enheder.
skønsmændene er ikke nået frem til at afgøre, hvilken udlægning der er i bedste over-
ensstemmelse med det aftalte og rimelige forventninger. uanset hvor frekvent brugen af
bdm vil være ved sædvanlig daglig brug, forekommer det dog noget besynderligt at
skulle gennemføre en test så højt oppe i v‟et uden at have adgang til at kunne redigere i
så væsentlige data (altså daccis‟ basis data) direkte i systemet.
materialet er heller ikke i intern overensstemmelse mht hvilke krav, der er relevante for
bdm. kravlisterne i sds (bilag aam, afsnit 4.5.1) og ssrs (bilag 75 afsnit 2.1) er
forskellige på en række punkter. eksempelvis indeholder ssrs kravet cor49 orbat,
der ikke indgår i sds.
1.10) på hvilket trin i udviklingsprocessen bør bdm-funktionalitet indarbejdes
det er både ubestridt og indlysende, at basis data er nødvendige for enhver brug af sy-
stemet, hvad enten der er tale om test eller operationel brug. hvis designet af basis data
ikke er hensigtsmæssigt, kan det have omfattende konsekvenser for øvrige dele af sy-
stemet. det virker derfor mest naturligt at udvikle funktionaliteten, der manipulerer ba-
sis data (bdm) så vidt muligt i tids- og tankemæssig sammenhæng med designet af
selve basis data.
dette er også helt i tråd med det generelle synspunkt, at datamodeller og den funktiona-
litet der bygger på denne bør udvikles i vertikale slices.
i) (ad spørgsmål 1.10) med sondring mellem bdm og basis data
svaret til 1.10) skelner allerede mellem basis data og bdm, og således er svaret til 1.10
også gældende for i).
1.11) konsekvenser af sen indarbejdelse af mip og bdm
på et projekt med den kompleksitet og størrelse som daccis har vil det have betyde-
lige konsekvenser for projektets ressourceforbrug.
det antages typisk, at for hver fase i v-modellen, der går før en fejl bliver fundet, at tids
forbruget til udbedring stiger med en faktor 5-10. at vente med integrationen af modu-
ler eller subsystemer, til de er færdigudviklet, vil øge risikoen for at fejl først findes me-
get sent i processen. specielt må det påregnes, at der er mange integrationsfejl, hvis man
ikke har testet integrationen undervejs.
j) (ad appellantens spørgsmål 1.11) konsekvenser af sen indarbejdelse af mip og bdm
- yderligere detaljering
konsekvensen vil generelt være, at det tager længere tid at udvikle systemet, og at om-
kostningerne ved (design-)fejl vil blive forøget som beskrevet under spørgsmål 1.11).
specifikt,
                                             - 30 -
    hvad angår 1) mip replikering og 2) mip compliance ligger den forøgede risiko ved sen
     udvikling og integration i, at det først sent opdages, om daccis og andre c2-systemer
     har forskellige opfattelser af datastrukturer.
    hvad angår 3) basis data, kan systemet ikke eksistere uden basis data, så sen tilføjelse af
     dette element kan ikke lade sig gøre
    hvad angår 4) basis data manager, består risikoen i, at det kan vise sig særdeles
     omkostningstungt at rette op, hvis manipulation af basis data med bdm afslører
     designmangler i den grundlæggende udformning og håndtering af basis data”
af skønstemaet fremgår, at skønsmændene bedes svare på følgende spørgsmål 2:
     ”2. spørgsmål relateret til udarbejdelsen af tekniske systemkrav for, og udvikling af,
     funktionaliteter relateret til mip
     2.1 skønsmanden bedes på et overordnet plan beskrive, hvilke typer af kravspecifikatio-
     ner der sædvanligvis opereres med ved udviklingen af et system som daccis, herunder
     beskrive forskellen mellem brugerkrav og tekniske kravspecifikationer vedrørende en-
     kelte funktionaliteter i systemet.
     k) (ad appellantens spørgsmål 2.1) indstævnte er af den opfattelse, at en "sub sy-
     stem requirement specification/ssrs" ikke nødvendigvis er det samme som en "teknisk
     kravspecifikation". skønsmanden bedes beskrive forskellen mellem på den ene side srs
     (system requirement specifications) og på den anden side ssrs (sub system require-
     ment specifications), samt forskellen mellem på den ene side brugerkrav og på den an-
     den side tekniske krav, herunder om udarbejdelsen af ssrs for brugerkrav normalt for-
     udsætter kundens medvirken og godkendelse.
     1) (ad appellantens spørgsmål 2.1) udgør sagens bilag aaø en ssrs (sub sy-
     stem requirement specification), som redegjort for i spørgsmål k), for mip replikering,
     som beskrevet i kravspecifikationens krav til "replication" (punkt 7.25 i bilag 3 til
     daccis-kontrakten, samt anneks d hertil, sagens bilag 1).
     2.2 skønsmanden bedes, ud fra en orientering i materialet på https://mipsite.lsec.dnd.ca
     i folderen public document library under baseline_2.0 og brugerkravene i bilag 3 med
     annex a-e til kontrakt af 29. juni 2007 (bilag 1) beskrive, hvilke tekniske kravspecifika-
     tioner det it-fagligt var nødvendigt/hensigtsmæssigt at tilvejebringe, førend udvikling
     af funktionaliteter relateret til mip kunne påbegyndes, henholdsvis afsluttes i overens-
     stemmelse med kravspecifikationen, og således at risici i udviklingsprocessen minime-
     res.
     m) (ad appellantens spørgsmål 2.2) skønsmanden bedes forudsætte, at daccis og mip
     block 2 ikke er specificeret samtidig, men derimod (i) at daccis er blevet udviklet
     siden 1998 efter nationale standarder, (ii) at mip block 2 blev færdigspecificeret af
     mip-samfundet i 2006 og, (iii) at ønsket om mip interoperabilitet med udenlandske hæ-
     renheders egne nationale systemer først blev introduceret i august 2005, jf. processen
     beskrevet i punkt 2.1.3 i indstævntes ankesvarskrift af 6. december 2010. på den bag-
     grund bedes skønsmanden beskrive henholdsvis redegøre for følgende vedrørende krav-
     specifikationerne for daccis:
 1. beskrive kravspecifikationernes opbygning og struktur relateret til brugerkrav og
     tekniske krav.
                                             - 31 -
 2. redegøre for, om kravspecifikationerne er udformet med en it-fagligt hensigtsmæssig
     og fyldestgørende struktur.
 3. redegøre for, hvordan krav til mip compliancy ville kunne indarbejdes i denne
     struktur.
     2.3 skønsmanden bedes besvare spørgsmål m) alternativt ud fra den forudsætning, at
     daccis' udveksling af information med internationale systemer var forudsat allerede i
     kontrakt af 10. marts 1998 mellem hmak og mærsk data a/s, hvilken kontrakt saab
     overtog, og at mip block 2 konkret blev introduceret i kontrakten ved fmt's bestilling
     af daccis 6.2 den 30. juni 2004, jf. processkrift 3 s. 9 sidste afsnit.
     2.4 skønsmanden bedes, i forlængelse af svaret på spørgsmål 2.2, beskrive hvordan
     brugerkrav til daccis bringes i overensstemmelse med specifikationerne for mip (på
     https://mipsite.lsec.dnd.ca), herunder hvordan konflikter mellem specifikationerne for
     mip og brugerkrav sædvanligvis forudsættes håndteret i itfaglig sammenhæng.
     n) (ad appellantens spørgsmål 2.4) skønsmanden bedes redegøre for, om skøns-
     mandens besvarelse af appellantens spørgsmål 2.4 er eneste sædvanlige metode, samt
     om metodevalget sædvanligvis er et spørgsmål om parternes aftaler og faktisk fulgte
     praksis.
     2.5 skønsmanden bedes overordnet beskrive processen for tilvejebringelse af tekniske
     kravspecifikationer til brug for udviklingen af funktionaliteter relateret til mip block 2,
     samt til design, udvikling og test af den funktionalitet, der gør daccis interoperabelt i
     regi af mip block 2, idet det forudsættes at datamodellerne for mip og daccis er for-
     skellige, og at udviklingen af mip interoperabilitet forudsætter udviklingen af et over-
     sættelses- eller integrationslag.
     o) (ad appellantens spørgsmål 2.5) skønsmanden bedes redegøre for, om skøns-
     mandens besvarelse af appellantens spørgsmål 2.5 er eneste sædvanlige proces, samt
     om valget af proces sædvanligvis er et spørgsmål om parternes aftaler og faktisk fulgte
     praksis.
     2.6 skønsmanden bedes gennemgå dokumentet "daccis 7 ssrs replication" af 21.
     november 2006 (bilag aaø) samt redegøre for,
     i hvilket omfang dokumentet er udtryk for en tilstrækkelig teknisk kravspecifikation til
     brug for udvikling af funktionaliteter relateret til mip, og
     i hvilket omfang dokumentet er udtryk for, at brugerkrav er bragt i over-
     ensstemmelse med specifikationerne for mip.
     p) (ad appellantens spørgsmål 2.6) skønsmanden bedes redegøre for om doku-
     mentet "daccis 7 ssrs replication" af 21. november 2006 (bilag aaø) efter sit ind-
     hold foregiver at være en tilstrækkelig teknisk kravspecifikation til brug for udvikling af
     funktionaliteter relateret til mip.”
af skønmændenes besvarelse af spørgsmål 2 fremgår følgende:
     ”2 spørgsmål relateret til udarbejdelsen af tekniske systemkrav for, og udvikling af,
     funktionaliteter relateret til mip
     2.1 sædvanlige typer kravspecifikation for et system som daccis
                                          - 32 -
der arbejdes generelt med to typer af krav: funktionelle og non-funktionelle krav.
funktionelle krav kan f.eks. nedfældes som use cases, og non-funktionelle krav deles
gerne i de “overordnede” og de use-case-specifikke, samt andre krav som f.eks. doku-
mentationskrav. såfremt use-cases indeholder interaktion med brugere, kan man med
fordel supplere use cases med udkast til skærm/computer interaktion - nogle gange be-
nævnt story boards. diskussion og dokumentation af skærmdialogen mellem systemle-
verandøren og brugerrepræsentanter kan være en pædagogisk vej til at opstille og de-
taljere (funktionelle) krav. særligt hvis brugerrepræsentanterne i deres dagligdag ikke er
it-implementeringseksperter men er deltagerer i projektet, fordi det nye system skal ind-
passes i deres fagområder.
det kan være fordelagtigt ikke at stille krav til teknik, da dette giver systemleverandø-
ren friheden til at vælge den rette teknik til opgaven. praktikken gør dog, at der i alle
projekter også er nogle tekniske forudsætninger og nødvendigheder, som så dokumente-
res som non-funktionelle krav. såfremt et teknisk krav står til hindring for en succesfuld
implementering, er det systemleverandørens opgave at påpege problematikken med den
ønskede teknik i forhold til opgavens målopfyldelse. det sidste forhold gør sig udpræget
gældende når der er tale om sikkerhedskritiske systemer.
det er hyppigt, at man i forløbet nedbryder krav. man starter med use cases på et rela-
tivt højt niveau, som så nedbrydes og specificeres i detaljen helt ned til det niveau, hvor
en use case eller dele heraf kan tildeles en programmør til kodning. interaktion med
brugerne er meget værdifuldt, fordi man i fællesskab får stillet forventningerne til,
hvordan resultatet ser ud/virker. ligeledes er det fordelagtigt, hvis man på lavt niveau
(dvs. nede i “v‟et”) kan få kunden til at sige god for, at målet er nået - nemlig det mål
som han for ganske kort tid siden har nikket til. hvis der går lang tid fra, at forventnin-
gen er stillet (dvs. kravet er deltaljeret) og til, kunden skal nikke til resultatet, stiger
sandsynligheden for, at der er væsentlig afstand mellem kundens forventninger og det
opnåede resultat.
k) (ad appellantens spørgsmål 2.1) om forskelle mellem srs og ssrs og mellem bru-
gerkrav og tekniske krav
ethvert system kan beskrives som et system af forbundne systemer. en srs er et kravs-
dokument til hele systemet, mens en ssrs er et kravsdokument til et subsystemet. det
system, der er beskrevet ved srs‟en, kan sagtens selv kan være et subsystem i en større
sammenhæng. f.eks. er daccis et subsystem i mip sammenhæng, hvor de andre nati-
onernes mip implementeringer er andre subsystemer i koalitionens samlede system.
der er derfor konceptuelt ikke nogen forskel på en ssrs og en srs. afhængighederne
for dokumenterne er forskellige. ssrs‟en arver (eller sådan burde det være) sine krav
fra srs‟en, mens srs‟en (typisk) arver sine krav fra omverdenen.
dokumenterne i et it projekt kan deles i to domæner. problemdomænet og løsningsdo-
mænet. kravsdokumenter beskriver det problem, der skal løses og hører derfor til i pro-
blemdomænet. når problemet analyseres, skabes der et design af løsningen, som foran-
kres i et antal designdokumenter. designdokumenter hører derfor til i løsningsdomænet.
løsningsdomænet er leverandørens område, mens det er kunden, der er eksperten, når
det kommer til problemet. derfor skal kunden optimalt set være forfatter eller, hvis
dette ikke er muligt, så reviewer (godkender) på alle dokumenter i problemdomænet.
kunden bør deltage i udarbejdelsen af alle kravsdokumenter og bør ligeledes godkende
til lavest mulige niveau (ideelt set helt ned til unitspecifikation med tilhørende test ca-
ses) med sporbarheden i behold helt fra toppen i v‟ets venstreside og retur op ad v‟ets
                                         - 33 -
højereside. med en lagvis nedbrydning ned i v‟et og en lagvis enighed om målopfyl-
delse op ad v‟ets højreside.
l) (ad appellantens spørgsmål 2.1) er bilag aaø en ssrs?
nej sagens bilag aaø er ikke fyldestgørende som ssrs. de fleste use case‟s er ufuld-
stændige og/eller så fejlbehæftede at dokumentet reelt er uanvendeligt til at implemen-
tere et (sub)system efter.
i uc 229 er post condition skrevet som
  a) the node is added to local topology
  b) the node is deleted from the local topology and removed from all receiver lists of
existing contracts
det vil normalt betyde at både a og b skal være opfyldt. dog er uc229 skrevet mod-
strid med generel skik for use cases. en use case bør beskrive opfyldelse af netop ét for-
retningsmål. i dette tilfælde er der tale om at man beskrivre to. det at tilføje en node og
det at slette en node. så man kunne vælge at sige at den en “post codition” gælder det
ene forretningsmål og den anden det andet forretningsmål. uce case flowet at tilføje en
node er at angivet med bogstavet b mens use case flowet at slette en node er angivet
med bogstav a. det vil derfor være rimeligt at forvente at der er sammenhæng mellem
post condition a og use case flow a.
uc230 tager ikke stilling til hvad der skal ske hvis nogle af de valgte receivere accep-
tere mens nogle af dem afviser ændringerne.
i nogle variationer er der et sidste skridt “the use case ends” mens der i andre ikke er et
tilsvarende skridt. det efterlader tvivl om hvad der skal ske ved afslutningen af de alter-
nativer der ikke har dette skridt. stopper use casen eller fortsætter den i basic flow? b10
i uc230 fortsætter ved a4 der er dog ikke tale om et alternativ da alle veje der fører til
b10 også fører til a4. det må derfor forventes use casen efter at a4 er gennemført fort-
sætter ved b11 (da denne ellers slet ikke ville være nødvendig) det medfører imidlertid
at kontrakten oprettes to gange, numereringen i uc230 for det til at se ud som om at
man er nødt til at oprette en daccis kontrakt før man kan oprette en mip kontrakt.
i uc232 view/edit contract vil det at man fjerner eller tilføjer “receivers” medfører at
systemet opretter en ny kontrakt (alternativ a5)
2.2) hvilke tekniske kravspecifikationer er nødvendige for mip-udvikling
kravsdokumenterne skrevet af mip samfundet samt kontraktens bilag om krav bør
sammenfattes i srs‟en med sporbarhed til de oprindelige dokumenter. ssrs‟en for
mip nedarver sine krav fra srs‟en og et review af denne ssrs skal sikre, at den er
komplet. udover kravspecifikationerne (ssrs‟en) bør der også foreligge designdoku-
mentation, som beskriver subsystemets arkitektur på en sådan måde, at det hjælper ud-
viklerne med at implementere løsningen i overensstemmelse med både krav og arkitek-
tur. kunden kan med fordel inddrages i udarbejdelsen af test cases, inden kodning sæt-
tes i gang.
der er use cases i c2, som er afhængig af faciliteter i susbsystemet “replication”. sam-
spillet mellem de to subsystemer bør defineres tidligt (interface) evt. udvikles en “stub”,
der simulerer et færdigt replications subsystem, men som bare sender kendte svar til-
                                           - 34 -
   bage på nuancerede forespørgsler. på denne måde kan man udvikle begge sub-systemer
   i parallel og samkøre dem, når praktikken fordrer det.
   m) (ad appellantens spørgsmål 2.2) om kravspecifikationer for daccis under forud-
   sætning af, at daccis-udvikling startede længe før mip-introduktionen
1. kontraktens bilag 3 har ikke en opdeling i brugerkrav og tekniske krav. kontrakten
   opdeler i funktionelle krav og non-funktionelle krav. der kan ikke sættes lighedstegn
   mellem tekniske krav og non-funktionelle krav. typisk vil tekniske krav være at finde
   under non-funktionelle krav, men kontrakten og øvrige dokumenter har ikke nogen for
   os synlig konsekvens på området.
2. kravspecifikationerne i kontraktens bilag 3 og i ssrs‟erne er ikke it-fagligt hen-
   sigtsmæssigt udformede. kravene i kontraktens bilag 3 er ofte ufuldstændige og/eller
   ikke testbare.
   use casene i ssrs‟erne er ofte i intern modstrid:
o f.eks. bilag aaø uc228.1 det alternative flow a1 starter efter main flow step b3. på
   det tidspunkt har brugeren ikke valgt at importere nogen noder endnu, men systemet
   skal fortælle brugeren, om han har valgt dubletter. variationen afsluttes ved, at de nye
   noder overskriver de gamle men i det tilfælde, at der også er unikke værdier, bliver
   disse ikke gemt i variationen, mens de ville være blevet gemt, hvis ikke der var
   dubletter. intentionen med use case‟ne kan udvikleren muligvis gætte sig til, men
   intentionen kan ikke overholdes samtidig med, at kravet overholdes.
o som eksempel på ufuldstændigheder kan samme use case bruges. det er ikke angivet,
   hvordan systemet skal opfører sig, hvis nodernes properties er overlappende, kun
   hvordan systemet skal opføre sig, hvis sættet af properties er identisk.
3. det forudsættes, at der med “mip compliancy” menes de krav, der er i kontraktens
   bilag 3, afsnit 7.24. indarbejdelsen som funktionelle krav er i overensstemmelse med
   den struktur, der er beskrevet ovenfor. det må formodes, at disse use cases skal lægges i
   et eller flere af c2 subsystemerne. det vil så have forudsætninger om at kunne interface
   med replications subsystem. som tidligere beskrevet, bør det være muligt at udvikle
   disse i parallel, men det kræver, at forventningerne til hvert subsystem er afstemt på
   forhånd.
   2.3) spørgsmål m) gentaget under forudsætning af, at udveksling af data med internati-
   onale systemer var forudsat fra starten
   spørgsmålene kredser en del om betydningen af det tidspunkt, hvor det stod klart eller
   burde stå klart, at daccis skulle udveksle information med internationale systemer (og
   ikke bare med instanser af sig selv). det forekommer dog ubestridt, at det var forudsat,
   at (instanser af) daccis systemer ikke skulle stå alene men måtte forventes at inter-
   agere og udveksle informationer ved replikering med andre instanser af daccis eller
   andre c2-systemer. derfor har det under alle omstændigheder været oplagt, at der op-
   bygges et subsystem til at varetage dette formål og som samtidig kan beskytte c2-delen
   af systemet så vidt muligt mod løbende ændringer og udvikling i den eksterne udveks-
   ling af information.
   ikke at have medtaget de skitserede forudsætninger ville være i modstrid med god skik.
   når der udvikles systemer med dataudvekslinger mellem subsystemer eller med eks-
   terne systemer, bør der altid tages højde for at kunne skifte protokol. dette er også en
   del af motivationen for arkitekturer som osi, hvor det er muligt at skifte et lag ud uden
                                        - 35 -
at påvirke de andre lag. f.eks. kan præsentationslaget (lag 6) skiftes ud, uden at appli-
kationslaget (lag 7) skal ændres.
under alle omstændigheder vil det have en betydning for udformningen af den dac-
cis-interne datamodel, hvornår de(n) internationale standard(er) for datamodel har væ-
ret kendt. det vil mindske kompleksitet tidligt at vælge en daccis-datamodel, der lig-
ner de internationale datamodeller, og det vil specifikt gøre det enklere at efterleve kra-
vene i kravspecifikationens afsnit 7.24 mip compliancy.
2.4) hvordan brugerkrav til daccis bringes i overensstemmelse med specifikationerne
for mip
det er en god ide at isolere integrationsfladen over for mip i et subsystem. mip anbe-
faler også, at man udvikler en mip gateway. ideen er, at mip gatewayen løbende ud-
vikles til at følge med den internationale udvikling (block 2, block 3 etc.), mens man
forsøger at holde grænsefladen mellem c2 og mip-gateway nogenlunde uforandret. når
mip begynder at opstille krav til brugergrænsefladen i c2, bør man i det c2 subsystem,
der ligger naturligt for den pågældende funktionalitet, lave en use case på mip imple-
menteringen.
der er ingen vanlig praksis for selve processen på dette område. hvis arbejdet er uden
for kontraktens omfang, er det et ændringsønske til systemet, og parternes aftalte prak-
sis for ændringsønsker bør derfor være fulgt.
n) (ad appellantens spørgsmål 2.4) er der alternativer til svaret på spørgsmål 2.4?
spørgsmålet er besvaret i 2.4. som sagt kan der være flere veje til at opnå det ønskede
resultat. vi betragter dog vores svar 2.4 som værende best practice.
2.5) tilvejebringelse af tekniske kravspecifikationer til brug for udvikling af mip-inte-
roperabilitet
den proces, der bør gennemløbes, er beskrevet i beskrivelsen af v-modellen. mip-ori-
enteret funktionalitet adskiller sig ikke fra andre funktionaliteter, hvad udviklingsproces
angår. man kan sagtens udvikle den brugernære funktionalitet parallelt med de øvrige
nødvendige systemdele, da det udelukkende er et spørgsmål om at have fastlagt de rele-
vante subsystem-interfaces tidligt.
o) (ad appellantens spørgsmål 2.5) er der alternativer til svaret på spørgsmål 2.5?
nej, det er ikke den eneste mulighed. parterne kan aftale, hvad de vil, men i dette til-
fælde er det sagens bilag aay, der definerer procesmodellen.
2.6) i hvilket omfang er dokumentet “daccis 7 ssrs replication” fyldestgørende
nedenfor bruges den definition af “brugerkrav” som blev angivet i email fra frederik
bue johnsen d. 28.08.2012 til skønsmændene:
fbj: “med "brugerkrav" i spørgsmål 2.6 b menes kravene til daccis, dvs. de krav,
som kravspecifikationen (srs, kontraktens bilag 3) er udtryk for.”
a.
                                                - 36 -
        bilag aaø (daccis 7 ssrs replication) er ikke tilstrækkelig kravspecifikation til
        udvikling af funktionaliteter relateret til mip. der er adskillige væsentlige krav i mip
        dokumentationen, som ikke er indeholdt i ssrs‟en (bilag aaø).
        f.eks. er krav req_id 2652 ikke behandlet.
        req_id 265 kræver at et givent c2is skal kunne håndtere dubletter af den samme
        entitet, en situation der eksempelvis kan opstå, når den ene er oprettet lokalt og den
        anden efterfølgende replikeres fra ejeren af data.
        som et andet eksempel, beskrives det heller ikke, hvordan man ønsker at overholde
        req_id 266, “aggregation methods”.
        uklarheden om daccis‟ håndtering af mip-krav øges af, at en række mip-krav
        formuleres ved henvisning til, at krav skal være opfyldt i samme omfang som ved
        tidligere gennemførte tests (se ref bilag 3, annex c). disse henvisninger forekommer
        under afsnit 7.24 mip compliancy i kravspecifikationen.
        b.
        brugerkrav kan ikke siges at være bragt i overensstemmelse med specifikationerne.
        som nævnt under punkt a. herover, findes der mip-krav, som ikke er dækket. det kan
        ikke udelukkes, at summen af parternes aftaler og forventninger tilsammen skaber et
        dækkende billede af daccis‟ håndtering af mip-krav, men dette overblik og den
        nødvendige sporbarhed skabes ikke af bilag aaø eller kontrakten.
        p) (ad appellantens spørgsmål 2.4) foregiver “daccis 7 ssrs replication” at være
        en teknisk kravspecifikation
        det er en velbegrundet forventning, at bilag aaø med referencer skulle være dækkende
        for en teknisk kravspecifikation til mip replication. (i spørgsmål 2.6 er der svaret, at
        dokumentet dog ikke lever op til denne forventning.) f.eks. står der på side 10/51 i bi-
        lag aaø “..the replication shall support a 100% compliant mip/dem baseline 2 repli-
        cation..”. undtaget er implementeringen af krav relateret til compliancy.
        da ssrs‟en er det samlende kravsdokument for et subsystem, er det også her alle krav
        er forankret dvs. enten beskrevet direkte i dokumentet eller via reference til en beskri-
        velse, der findes andetsteds. dette gælder uanset, om kravene allerede i srs‟en er krav,
        eller om de kommer til senere som designbeslutninger i forbindelse med ssrs‟en.
        spørgsmål 2.6 er besvaret ud fra denne forventning til øverste kravsdokument for et
        subsystem, og i den henseende udgiver bilag aaø sig for at være teknisk kravsdoku-
        mentation. konkret beskriver bilag aay ssrs‟erne med
        “purpose: technical basis for system”
        dette underbygges også af, at bilag aay ikke beskriver andre dokumenter, der alterna-
        tivt kunne have rollen som det tekniske grundlag for implementeringen af et subsy-
        stem.”
af skønstemaet fremgår, at skønsmændene bedes besvare følgende spørgsmål 3:
        ”3. spørgsmål relateret til testproceduren
2
  ref. msrs-main-3.1.6
                                           - 37 -
   3.1 skønsmanden bedes, på et overordnet plan, beskrive testproceduren, herunder
   beskrive hvilke niveauer af tests der typisk skal gennemføres, ved udviklingen af et
   system som daccis.
   q) (ad appellantens spørgsmål 3.1) skønsmanden bedes redegøre for, om skøns-
   mandens besvarelse af appellantens spørgsmål 3.1 er eneste sædvanlige testprocedure,
   samt om den valgte testprocedure sædvanligvis er et spørgsmål om parternes aftaler og
   faktisk fulgte praksis.
   3.2 skønsmanden bedes, i tilknytning til besvarelsen af spørgsmål 3.1, beskrive de
   metoder for verifikation og godkendelse af systemets enkelte funktioner, der skal være
   på plads i de enkelte faser af udviklingsprocessen, hvis et virksomt system i
   overensstemmelse med kravspecifikationen skal opnås.
   r) (ad appellantens spørgsmål 3.2) skønsmanden bedes redegøre for, om skøns-
   mandens besvarelse af appellantens spørgsmål 3.2 er eneste sædvanlige metode, samt
   om metodevalget sædvanligvis er et spørgsmål om parternes aftaler og faktisk fulgte
   praksis.
   s) (ad appellantens spørgsmål 3.2) skønsmanden bedes efter gennemgang af ho-
   vedkontakten (sagens bilag 1), "product acceptance plan" (bilag 6 til hoved-
   kontakten), master test plan (sagens bilag aaå) og system test procedure (sagens
   bilag aav) samt den dokumentation og eventuelle spørgsmål til parterne, skønsmanden
   i øvrigt måtte finde nødvendig, redegøre for, om den aftalte og fulgte metode for
   verifikation og godkendelse for daccis var i overensstemmelse med god it-skik på det
   tidspunkt, hvor den aftaltes henholdsvis fulgtes.
   3.3 skønsmanden bedes besvare spørgsmål s) alternativt ud fra den metode for ve-
   rifikation og godkendelse, der følger af de fremlagte bilag, uden hensyn til hvad
   skønsmanden måtte mene der var aftalt mellem parterne vedrørende verifikation og
   godkendelse.
   3.4 skønsmanden bedes overordnet redegøre for, hvilken betydning det har eller kan
   have, at funktionaliteter udelades ved en samlet systemtest af et it-system som daccis.
   t) (ad appellantens spørgsmål 3.4) skønsmanden bedes redegøre for, hvorledes
   besvarelsen af appellantens spørgsmål 3.4 vil være, hvis det forudsættes, at der ved 0c-
   testen i uge 51, 2007, ikke skulle foretages en "samlet systemtest", men
   i stedet en midtvejs fremdriftstest, hvor ikke alle systemets krav skulle testes.
   3.5 skønsmanden bedes oplyse, om der it-fagligt er særlige karakteristika knyttet til
   begrebet "operational capability test", og i bekræftende fald redegøre nærmere for den
   almindelige it-faglige forståelse af begrebet.
   u) (ad appellantens spørgsmål 3.5) skønsmanden bedes gennemgå dokumenterne
   på https://mipsiteisec.dnd.ca i folderen public document library under "baseline2.0",
   særligt dokumenterne til brug for den operative afprøvning af mip block 2 ved den
   såkaldte olt test ("olt1.zip", "olt2.zip" og "olt3.zip"), samt de operative scenarier
   anvendt som grundlag for 0c-testen i uge 51 (sagens bilag aad) og bilag aaaa.
   skønsmanden bedes på den baggrund redegøre for følgende:
1. hvorvidt scenario list fra workshop i uge 20, 2007 (sagens bilag 81)
                                           - 38 -
   umiddelbart, dvs, uden nærmere beskrivelse og yderligere bearbejdning, kan danne
   grundlag for en operativ test.
2. hvorvidt afprøvningen i scenarie 8-11 i scenario list fra workshop i uge 20, 2007
   (sagens bilag 81) er mere eller mindre omfattende end (eller svarende til) afprøvningen
   ved olt i regi af mip-samfundet.
   v) (ad appellantens spørgsmål 3.5) skønsmanden bedes redegøre for, om det er
   god it-skik at teste daccis ved en "operational capability test" (forstået som
   gennemførelse af et operativt forløb, hvorved relevante funktionaliteter testes som led i
   forløbet, men uden at samtlige krav til systemet testes krav for krav) ved en midtvejs
   fremdriftstest som 0c-testen i uge 51, 2007. hvis svaret af-
   hænger af, om 0c-testen i uge 51, 2007 var en fremdriftstest af udvalgte dele af
   systemet eller en accepttest af det fulde system, bedes dette angivet.
   3.6 skønsmanden bedes besvare spørgsmål v) alternativt ud fra den forudsætning, at
   0c-testen i uge 51 ikke var "en fremdriftstest af udvalgte dele af systemet, eller en
   accepttest af det fulde system", men var en integreret, operativ bruger- test, således som
   der er redegjort for i fmt's processkrift 3 af 18. november 2011, s. 2 og s. 11.
   w) (ad appellantens spørgsmål 3.5) skønsmanden bedes under den forudsætning, at oc
   testen i uge 51 var en operativ brugertest redegøre for, om det under en sådan operativ
   test normalt er muligt at afprøve ikke-funktionelle krav til systemet.
   x) (ad appellantens spørgsmål 3.5) skønsmanden bedes under den forudsætning, at oc
   testen i uge 51 var en operativ brugertest redegøre for, om det under en sådan operativ
   test er normal praksis at afprøve og dokumentere afprøvning af hvert enkelt krav i
   kravspecifikationen, eller om der er andre afprøvningstyper, hvor afprøvning af hvert
   enkelt krav i kravspecifikationen er mere udbredt, eksempelvis en factory acceptance
   test.
   3.7 skønsmanden bedes beskrive de forskellige typer af tests den funktionalitet, der gør
   daccis interoperabelt i regi af mip block 2, typisk skal gennemgå.
   y) (ad appellantens spørgsmål 3.7) skønsmanden bedes i tillæg til spørgsmål d)
   beskrive, hvordan hver af de tests af funktionerne, der gør daccis interoperabelt, dvs.
   hhv. 1) mip replikering og 2) mip compliancy, typisk foregår i mipsamfundet,
   herunder hvornår og hvordan det nærmere testomfang, inkl. testparter, fastlægges.
   z) (ad appellantens spørgsmål 3.7) skønsmanden bedes besvare appellantens
   spørgsmål 3.7 vedrørende "interoperabilitet" sådan, at der sondres mellem henholdsvis
   1) mip replikering og 2) mip compliancy.
   æ) (ad appellantens spørgsmål 3.7) skønsmanden bedes redegøre for, om skøns-
   mandens besvarelse af appellantens spørgsmål
   3.7 er eneste sædvanlige typer af tests, samt om valget af testmetode samt omfanget
   heraf sædvanligvis er et spørgsmål om parternes aftaler og faktisk fulgte praksis.
a) skønsmanden bedes gennemgå dokumentet "actual test bed description" af 9. november
   2007 (i bilag p) og, under de forudsætninger at den pågældende test gennemføres 7-8
   måneder før endelig aflevering af systemet til kunden, at testen baseres på operationelle
                                            - 39 -
   scenarier, at testen har en planlagt varighed på 4
   dage, og at testen gennemføres med deltagelse af brugergruppen i hele forløbet,
b) beskrive hvorvidt en sådan test er it-fagligt egnet til test af funktionaliteter, der alene
   testes på separate maskiner uden forbindelse med det samlede system, beskrive den
   værdi, i kontekst af typisk it-faglig test af systemer, en sådan test har, hvis det lægges
   til grund at test af funktionaliteter relateret til mip interoperabilitet samt bdm alene
   testes på separate maskine uden forbindelse til det samlede daccis system, og
c) beskrive den værdi, i kontekst af typisk it-faglig test af systemer, en sådan test har, hvis
   det lægges til grund at test af funktionaliteter relateret til mip interoperabilitet samt
   bdm testes med versioner af daccis, der adskiller sig fra den version, som i øvrigt
   testes.
   ø) (ad appellantens spørgsmål 3.8) skønsmanden bedes redegøre for, hvorledes
   besvarelsen af appellantens spørgsmål 3.8 vil være under følgende forudsætninger:
1. oc-testen i uge 51 var en fremdriftstest.
2. oc-testen i uge 51 havde en varighed på 5 dage, ikke 4, hvoraf der alene var planlagt
   test af mip og bdm på 5. dagen.
3. testen af mip og bdm ville ske ved brug af samme daccis-software, som anvendt de
   4 foregående dage, og med de testdata, der var genereret gennem de 4 foregående
   dages test, men med mip og bdm modulerne tilføjet i samme testopstilling.
   å) (ad appellantens spørgsmål 3.8) i tillæg til besvarelsen af appellantens spørgsmål
   3.8 samt spørgsmål ø), og under samme forudsætninger, bedes skønsmanden redegøre
   for, om test af mip kræver en (kommunikations)modpart. i bekræftende fald bedes
   skønsmanden i kontekst af en typisk it-faglig fremdrifts- test af it-systemer som
   daccis redegøre for følgende:
1. om en sådan modpart efter god it-skik normalt vil være aftalt i kontrakten mellem kun-
   den og leverandøren.
2. om det efter god it-skik er normalt, at kunden først under selve testen,1-2 dage før af-
   prøvningen ønskes gennemført, oplyser leverandøren om den modpart, kunden ønsker
   testen gennemført i forhold til.
3. om det efter god it-skik er normalt, at leverandøren ikke forud for selve afprøvningen
   har fået adgang til at teste i forhold til den pågældende modpart.
   skønsmanden bedes redegøre for, om det gør en forskel for besvarelsen, om der er
   knyttet ophævelsesadgang til testresultatet.
   aa) (ad appellantens spørgsmål 3.8) i tillæg til besvarelsen af appellantens spørgsmål
   3.8 samt spørgsmål ø) og å) ovenfor, bedes skønsmanden redegøre for hvorvidt den for
   en mip-test eventuelt nødvendige modpart er forudsat i dokumentet "actual test bed
   description" af 9. november 2007 (i bilag p) eller i de anvendte operative scenarier 1-7
   (se oversigten i "scenario eventlist", bilag p, samt de faktiske scenarier i bilag aad).
   bb) (ad appellantens spørgsmål 3.8) skønsmanden bedes redegøre for, om det er
   sædvanlig it-faglig praksis at afholde en præ-test forud for den egentlige test. uanset
   hvad skønsmanden måtte svare hertil, bedes skønsmanden redegøre for, hvilken
   betydning en sådan aftalt præ-test har for den efterfølgende egentlige test, herunder
   særligt testomfang og testmetode ved præ-testen i forhold til testomfang og testmetode
   ved den efterfølgende egentlige test.
                                           - 40 -
   3.9 skønsmanden bedes beskrive, på hvilket tidspunkt i udviklingsprocessen og under
   hvilke omstændigheder funktionaliteter relateret til mip interoperabilitet typisk bør
   testes adskilt fra det øvrige daccis system, og i denne forbindelse beskrive,
a) under hvilke omstændigheder en sådan adskilt test er it-fagligt korrekt og hensigtsmæs-
   sig,
b) hvorvidt en sådan adskilt test typisk indebærer, at målingen af eventuelle fejl bliver
   retvisende, både for så vidt angår fejl relateret til mip interoperabilitet som fejl ved
   systemets øvrige funktionaliteter, og
c) i hvilket omfang en sådan adskilt test er egnet til at vise fremdrift i udviklingen af det
   samlede system.
   cc) (ad appellantens spørgsmål 3.9) skønsmanden bedes redegøre for, hvorledes
   besvarelsen af appellantens spørgsmål 3.9 vil være under følgende forudsætninger:
1. oc-testen i uge 51 var en fremdriftstest.
2. testen af mip og bdm ville ske ved brug af samme daccis-software, som anvendt de
   4 foregående dage, og med de testdata, der var genereret gennem de 4 foregående
   dages test, men med mip og bdm modulerne tilføjet i samme testopstilling.
   dd) (ad appellantens spørgsmål 3.9) skønsmanden bedes redegøre for, hvorledes
   besvarelsen af appellantens spørgsmål 3.9 vil være under forudsætning af, at alle
   tidligere afprøvninger af mip i parternes samarbejde - herunder ved tidligere
   accepttests af daccis - var foregået i regi af mip-samfundet samt at parterne ikke -
   specifikt - havde aftalt anden afprøvning af mip.
   3.10 skønsmanden bedes beskrive de forskellige typer af tests, den funktionalitet, der
   gør det muligt, som en integreret del af det samlede daccis-system, at skabe og ændre
   systemets basisdata i overensstemmelse med kravspecifikationen for bdm, typisk skal
   gennemgå.
   ee) (ad appellantens spørgsmål 3.10) skønsmanden bedes redegøre for, hvorledes
   besvarelsen af appellantens spørgsmål 3.10 vil være under følgende forudsætninger:
3. oc-testen i uge 51 var en fremdriftstest.
4. testen af bdm ville ske ved brug af samme daccis-software, som anvendt de 4
   foregående dage, og med de testdata, der var genereret gennem de 4 foregående dages
   test, men med bdm modulet tilføjet i samme testopstilling.
   ff) (ad appellantens spørgsmål 3.10) skønsmanden bedes redegøre for, om
   skønsmandens besvarelse af appellantens spørgsmål 3.10 er eneste sædvanlige typer af
   tests, samt om valget af testmetode samt omfanget heraf sædvanligvis er et spørgsmål
   om parternes aftaler og faktisk fulgte praksis.
   3.11 skønsmanden bedes beskrive, på hvilket tidspunkt i udviklingsprocessen og under
   hvilke omstændigheder funktionaliteter, der gør det muligt, som en integreret del af det
   samlede daccis-system, at skabe og ændre systemets basisdata i overensstemmelse
   med kravspecifikationen for bdm, typisk bør testes adskilt fra det øvrige daccis
   system, og i denne forbindelse beskrive,
a) under hvilke omstændigheder en sådan adskilt test er it-fagligt korrekt og hensigtsmæs-
   sig,
                                              - 41 -
 b) hvorvidt en sådan adskilt test typisk indebærer, at målingen af eventuelle fejl bliver
     retvisende, både for så vidt angår fejl relateret til bdm som fejl ved systemets øvrige
     funktionaliteter, og
 c) i hvilket omfang en sådan adskilt test er egnet til at vise fremdrift i udviklingen af det
     samlede system.
     gg) (ad appellantens spørgsmål 3.11) skønsmanden bedes redegøre for, hvorledes
     besvarelsen af appellantens spørgsmål 3.11 vil være under følgende forudsætninger:
 1. oc-testen i uge 51 var en fremdriftstest.
 2. testen af bdm ville ske ved brug af samme daccis-software, som anvendt de 4
     foregående dage, og med de testdata, der var genereret gennem de 4 foregående dages
     test, men med bdm modulet tilføjet i sammetestopstilling.
     hh) (ad appellantens spørgsmål 3.4, 3.8, 3.9 samt 3.11) skønsmanden bedes gennemgå
     kravspecifikationen i bilag 3, anneks d, til kontrakten (del af sagens bilag 1). under
     forudsætning af, at ikke alle krav er markeret som "shall"-krav til oc, og at alle krav er
     markeret som "shall"-krav til fc, bedes skønsmanden redegøre for, hvorvidt 0c-testen
     udgør en samlet systemtest.
     ii) skønsmanden bedes gennemgå punkt 5 i "daccis status report #49" fra august
     2007 (side 11 i sagens bilag 50) samt tidslinjen for test af daccis i præsentationen fra
     7. september 2007 (side 7 i sagens bilag s). skønsmanden bedes på den baggrund
     redegøre for følgende:
 1. hvad forstås it-fagligt i den pågældende situation ved at "koden bliverlåst" (også kendt
     som "code freeze").
 2. er det it-fagligt sædvanligt at "låse koden" forud for et testforløb som oc-testforløbet.
 3. er det god it-faglig praksis ikke at foretage ændringer i systemer med
 4. "låst kode" forud for testen af systemet.
 5. vil det være sædvanligt eller hensigtsmæssigt at udskyde test af funktioner, som kunden
     kræver ændret efter, at "koden" er blevet "låst”.”
af skønsmændenes besvarelse af spørgsmål 3 fremgår følgende:
     ”3. spørgsmål relateret til testproceduren
     3.1 overordnet beskrivelse af testprocedure for systemer som daccis
     for hvert processkridt på venstre siden af v-modellen skal der være et antal testskridt
     på højresiden, der relaterer til hvert processkridt. dvs., når man trinvis opdeler
     venstresiden af v‟et i system → subsystem → modul → unit, bør der som minimum
     være unittest, modultest, modulintegrationstest, subsystemtest, subsystemintegration og
     systemtest på højresiden.
     hertil kommer test af ydeevne (performance) i forhold til de opstillede non-funktionelle
     krav (forventninger til antal brugere, antal transaktioner m.m.), stabilitetstest (som skal
     verificere, at systemet fungerer over længere tid med passende load og brugsmønster)
     installationstest, accepttest o.lign. inddelingen og tilrettelæggelsen er typisk et
     kontraktsanliggende på niveauet over systemtest, men det er god it-skik at adressere alle
     disse forhold, og efter vores skøn nødvendigt, hvis man skal i mål.
                                          - 42 -
  de nævnte testskridt er alle dynamiske afprøvninger, hvilket betyder, at koden eller dele
  af koden eksekveres. derudover bør alle dokumenter være underlagt statisk afprøvning,
  altså et review foretaget ved skrivebordet. kravsdokumenter reviewes i samarbejde med
  kunden, mens designdokumenter reviewes internt. udover de afprøvninger, v-modellen
  lægger op til, vil der typisk også blive aftalt, hvordan accepttest udføres. den statiske
  afprøvningen af dokumenter er sandsynligvis taget fra eller inspireret af w-modellen.
  denne del af w-modellen indgår i beskrivelse af procesmodellen i bilag aay.
  q) (ad appellantens spørgsmål 3.1) alternative testprocedurer
  under v-modellen er der plads til variationer af ovenstående. f.eks. er det ikke
  ualmindeligt, at modulintegrationstest og subsystemtest afvikles som én test. men
  overordnet set så er ovenstående den dynamiske afprøvningsstrategi, det vil være
  nødvendigt at følge for at kunne sige, at man lever op til v-modellen.
  3.2) metoder for verifikation og godkendelse af systemets enkelte funktioner
  hvis begrebet faser forstås som analyse, design og implementering er svaret i 3.1
  gældende for 3.2. hvis der med begrebet faser menes de enkelte iterationer eller sprints
  i et agilt projekt, så gennemløbes v-modellen inden for hver iteration. dvs., at man har
  analyse, design og implementering i hver iteration, og de tilsvarende tests op til
  systemtest gennemløbes. hvis man specifikt anvender scrum, kan demoen, som
  ligger efter systemtesten, betragtes som en begrænset brugeraccepttest, der afvikles efter
  hvert sprint.
  det fremgår af materialet i sagen, at projektet angiveligt anvender scrum - mere
  retvisende havde det nok været at sige, at man anvender visse elementer fra scrum,
  men det står ikke helt klart, hvilke scrum-elementer, der er henholdsvis til- og
  fravalgt.
  r) (ad appellantens spørgsmål 3.2) alternative metoder til verifikation af funktioner
  den i 3.2 (og 3.1) beskrevne metode for verifikation er et uddrag af den valgte
  procesmodel og i kontekst af den valgte procesmodel, så er verifikationsmodellen som
  beskrevet i 3.1 og 3.2. der er mulighed for variationer som beskrevet i q, men
  variationer derudover vil kræve afvigelse fra den aftalte procesmodel. sådanne
  afvigelser må - ud over at være fagligt fornuftige - aftales tydeligt og eksplicit, hvis der
  skal være tale om god praksis..
  s) (ad appellantens spørgsmål 3.2) var den aftalte og fulgte metode for verifikation og
  godkendelse god it-skik
  den aftalte og fulgte procedure for verifikation/test er ikke i overensstemmelse med god
  it-skik.
  identificerede uhensigtsmæssigheder ved unit test
 manglende opfølgning på coverage (= dækning).
  der måles eksekveringscoverage som er forskellig fra test coverage, og man forholder
  sig ikke til, hvad den reelle test coverage er. 100% eksekveringscoverage kan dække
  over 0% testcoverage og uden manuel verifikation af måleresultaterne kan man derfor
  ud fra eksekveringscoverage ikke udtale sig om testcoverage og altså heller ikke, om de
  angivne mål er opfyldt eller ej.
 målene for coverage er vagt defineret idet udvikleren selv skal vurdere, hvor høj cove-
  rage for den givne unit skal være.
 det er svært at se rationalet bag de tre niveauer af coverage, der opereres med (50%,
  75% og 100%). eksempelvis er simpel kode let at få fuld coverage på, og alligevel er
                                           - 43 -
  målet kun 50%. fejl i simpel kode er lige så kritisk som fejl i kompleks kode, det er
  svært at se hvilket argument, der begrunder den lavere coverage.
  identificerede uhensigtsmæssigheder ved system test
 “what to do” kolonnen i dokumentet system test procedure (bilag aav) specificerer,
  hvad testene skal gøre på meget overordnet plan, kolonnen “expected result” er i en
  række tilfælde overordnet beskrevet eller efterladt helt tomt, hvilket vanskeliggør eller
  ligefrem umuliggør opfølgning på testresultater. (“actual result” er også efterladt tomt,
  men det kan og bør have en helt naturlig årsag, hvis de faktiske testresultater er opført
  andetsteds.)
 manglende overensstemmelse mellem use cases og test cases. se også konkret
  eksempel herunder.
 der stilles ikke krav til testdækning på niveauer over unit tests.
  identificerede uhensigtsmæssigheder ved styring af testomfang
 test casene er mangelfuldt udarbejdet
 der er ikke taget højde for “exploratory testing” (= supplerende test, der ikke følger et
  forud defineret skript)
 der tages ikke aktiv stilling til, hvordan den målte eksekveringsdækning ved unit test
  relateres til testdækning trods de specifikke krav til testdækning. de nævnte krav til
  testdækning er vagt defineret.
  herunder følger et eksempel på den manglende sammenhæng mellem use cases og test
  cases. det er ikke muligt at finde trin i testen som følger use casen. hvis testen fejler
  vil det ikke være muligt at finde, hvor i use casen at testen fejlet. testens mangler på
  “expected result” gør testen umulig at udføre. som læser af dette, kan man ikke undgå
  at få den tanke, at test casen og use casen aldrig i realiteten er blevet brugt til udvikling
  og efterfølgende verifikation.
  3.7 uc 231 start/stop contracts
  precondition
  a) start: the receiver(s) on the contract must be in a stopped state.
  b) stop: the receiver(s) on the contract must be started.
  uc231.1 daccis specific: basic flow contracts in bulk mode
  b1. the actor selects the receiver(s) on a contract to start.
  b2. the actor selects to start the receiver(s) on the contract in bulk mode.
  b3. the system changes the state of the receiver(s) on the contract from stopped to bulk
  pending.
  b4. the system updates the status to bulk in progress when data is being processed.
  b5. when the bulk is processed, the system changes the state for the receiver(s) on the
  contract to incremental mode.
  post condition:
  a) start bulk: the bulk data is transferred to the receiver(s) and the receiver(s) is in
  incremental mode.
  b) start incremental: the receivers on the contract are started in incremental mode.
  c) stop: the receiver(s) on the contract are in stopped state.
  testen:
  3.1.19 cor085: replication contract activation and deactivation
                                          - 44 -
  1 run sysman
  2 activate and deactivate a replication contract.
  de trin, der er beskrevet i use casen, skal kunne genfindes i test casen. use casen
  beskriver, hvordan systemet bør virke, mens test casen skal verificere dette. hvis ikke
  use casen er at genfinde i test casen, fortæller testresultatet ikke noget om, hvorvidt
  kravene forankret i use casen er i overensstemmelse med specifikationen.
  3.3) besvarelse af spørgsmål s) ud fra fremlagte bilag
  svaret til spørgsmål s) er gældende som svar på 3.3
  3.4) betydningen af udeladelse af funktionaliteter ved systemtest
  ved at undlade dele af systemet fra en test, kan testen ikke længere opfattes som en
  systemtest. en systemtest ligger højt oppe i v‟et, og det er en væsentlig pointe for en
  systemtest, at der testes et komplet system. test af dele af systemet forudsættes udført i
  tidligere faser. det skal understreges, at der med “komplet” selvsagt menes komplet i
  forhold til det aftalte omfang for systemet på det givne stade af projektet.
  spørgsmålet har en generisk natur, og svaret må derfor i sagens natur blive en kende
  generisk. men herunder følger nogle konkrete eksempler på risici, der opstår ved at
  udelade funktionaliteter fra en systemtest:
 fejl i den ikke afprøvede funktionalitet vil selvsagt ikke blive fundet.
 det må forventes, at der er integrationsfejl, der ikke findes ved systemafprøvningen,
  som ellers ville være blevet fundet, hvis testen var udført på et samlet system. integra-
  tionsfejl er hyppigere alvorlige fejl end ikke-integrationsfejl
 timingen mellem subsystemer, speciel ved asynkron kommunikation kan være årsag til
  fejl. ved ikke at teste systemet som et hele, testes denne problematik ikke.
 hardwarekrav vil normalt vokse med ekstra subsystemer, og det vil betyde, at den
  valgte platform ikke bliver verificeret, hvis systemet ikke er komplet under test
 systemets samlede stabilitet kan ikke vurderes
 systemets performance kan ikke vurderes
  t) (ad appellantens spørgsmål 3.4) alternativt svar, hvis oc er en “fremdriftstest”
  besvarelsen vil ikke ændres af disse forudsætninger. det forekommer indlysende og
  ubestridt, at der ved oc efter kontrakten skulle testes et system, der defineres ved
  “shall”-kravene i kravspecifikationen. disse krav definerer således et system, og dette
  system er mindre omfattende end det system, der skulle testes ved fc. specifikt fremgår
  dette af bilag aaz project management plan afsnit 2.3 (release 2), hvor oc omtales
  som en accepttest af et komplet system defineret af shall kravene stillet til oc.
  begrebet “fremdriftstest” anvendes i en række spørgsmål i skønstemaet. begrebet er
  ikke et etableret begreb i it-verdenen, og der følger således ikke særlige forventninger
  med, hvis man omtaler en test som en fremdriftstest. omvendt løftes der heller ikke
  specifikke byrder bort ved at omtale en test som en fremdriftstest.
  ved diskussionen af karakteren af oc-testen og forventningerne til den, må man derfor
  kigge på de konkrete aftaler om omfanget af det system, der skal testes, og de kriterier
  for godkendelse/accept, der er er knyttet til testen. da der er acceptkriterier knyttet til
  testen, forekommer det mere naturligt at anvende den sædvanlige term “accepttest” om
  oc, hvilket sagens materiale da også gør sine steder. heller ikke dette forhold ændrer
                                           - 45 -
   dog på, at vurderingen af omstændighederne om oc må tage udgangspunkt i de
   konkrete aftaler om omfang, fremgangsmåde, acceptkriterier og konsekvenser.
   3.5) begrebet “operational capability test”
   begrebet “operational capability test” er ikke et sædvanligt anvendt begrebet med
   særlige forventninger knyttet til sig.
   mip samfundet har en operational level test (olt), som i kontekst af daccis er det
   begreb, der kommer tættest på operational capability test. olt i mip samfundet er den
   systemtest som påviser at et c2is fungerer operationelt i forhold til mip-samfundet.
   olt er beskrevet som en test, der efter gennemførelsen af en række andre tests, skal
   demonstrere, at integrationen til mip fungerer i kontekst af virkelighedsnære,
   operationelle scenarier.
   ifm. research af “operational capability test” (oct) termen har vi som konkrete
   eksempel fundet afprøvningen af et nyt led lysanlæg til indflyvning i en lufthavn. i
   den forbindelse blev oct udført ved at systemet blev taget i brug og bla. overfløjet for
   at kontrollere lysforholdene fra cockpittet. altså en fuld system test i en operationel
   kontekst.
   intet af det ovenstående ændrer på, at oc i daccis-sammenhæng må forstås og
   vurderes ud fra det konkrete aftaler og forventninger, der findes mellem parterne.
   u) (ad appellantens spørgsmål 3.5) omfang og anvendelighed af scenario list i forhold
   til en operativ test
1. hvis en operativ ønskes udført ved brug af testcases, så vil scenario list (bilag 81) ikke
   umiddelbart kunne danne grundlag for en sådan test. hvis en operativ test ønskes udført
   ved exploratory test, så vil scenario list godt umiddelbart kunne danne grundlag for en
   sådan test. olt baseres på exploratory test.
2. det er vores skøn at de scenarier, der er indeholdt i olt i mip-regi er væsentligt mere
   omfattende end dem, der er beskrevet i bilag 81 - det er med forbehold for, at skøns-
   mændene har begrænset indsigt i militære operationer. olt forudsætter endvidere, at
   man har gennemført og bestået mslt1-mslt3.
   v) (ad appellantens spørgsmål 3.5) er det god skik at teste daccis ved en
   “operational capability test”
   som beskrevet under svaret til spørgsmål t) bærer begrebet fremdriftstest ikke en særlig
   betydning, der har betydning på svaret. det må endvidere præciseres, at spørgsmålets
   henvisning til “det fulde system” i oc-sammenhæng må gælde det system, der
   defineres ved shall-kravene til oc. det virker endvidere rimeligt at tale om oc som en
   accepttest, da dette begreb er sædvanligt for tests, hvortil der er knyttet acceptkriterier.
   (det er dog ikke sædvanligt, at et antal tilladte fejl angives med et cirka-tal som i dette
   tilfælde.)
   det er god skik at have en sådan test, hvor testen er baseret på operationelle scenarier.
   det er ikke i sig selv diskvalificerende for testen, at alle systemets krav ikke testes
   systematisk. på et så fremskredent tidspunkt i testforløbet må det forventes, at sådanne
   systematiske test er udført i rigt omfang, før tidspunktet (for den oc-lignende test. hvis
                                         - 46 -
dette modsat ikke er sket, så vil det være et klart brud på god it-skik og dermed også
nedbringe værdien af den operationelle test.
3.6) spørgsmål v) under alternative forudsætninger
svaret til v) er også gældende som svar til 3.6
w) (ad appellantens spørgsmål 3.5) afprøvning af ikke-funktionelle krav til systemet
det vil være normalt at afprøve non-funktionelle krav under en oc test. parterne synes i
øvrigt at være enige om dette, da der i anneks d til kontraktens bilag 3 er mange
eksempler på, at non-funktionelle krav er medtaget som shall til oc. f.eks er alle
performance-, dokumentations- (med undtagelse af to), sikkerheds- og kvalitetskrav
markeret som shall til oc.
systemet havde været under udvikling i ca. 9 år på afprøvningstidspunktet, og efter
planen var der ca et halvt år til final capability test. det er derfor et naturligt
spørgsmål, hvornår man ellers skulle tage fat på test af ikke-funktionelle krav i
driftslignende situationer.
x) systematisk test af kravspecifikationen ved en operativ brugertest
fokus for en sådan operativ brugertest vil typisk være på at gennemføre brede,
virkelighedsnære scenarier, der kommer godt rundt i det samlede systemet. som
beskrevet i svaret til v) vil det være helt naturligt at forudsætte, at tidligere tests har
testet de enkelte krav minutiøst. en test med betegnelsen factory acceptance test
kunne meget vel indgå i et sådant forløb.
der er ikke noget usædvanligt i at teste alle krav i en operativ brugertest og
dokumentere resultatet. i det konkrete tilfælde forstærkes dette af, at antallet af krav i
kravspecifikationen er ganske behersket i forhold til til omfanget af udviklingsindsatsen.
det vil også kunne have indflydelse på valget af niveau for nidkærhed under oc,
hvordan det tidligere testforløb har været tilrettelagt og er forløbet, men dette aspekt har
vi ikke vurderet særskilt.
3.7) test af funktionalitet, der går daccis mip-2 interoperabel
den type af test som mip implementeringen bør gennemgå er dels beskrevet i afsnittet
om v-modellen, og dels har mip samfundet en række test, navngivet ilt, mslt1-3 og
olt. disse test er kort beskrevet under svaret til spørgsmål d). mip-testene eksekveres
under udviklingen og mip-samfundet lægger op til, at dette kan foregå iterativt. f. eks.
skrives der i mtemp-tewg edition 2.2:
“the assessment of operational aspects can be incremental and will start as early as
possible in the development process”.
mslt1-3 og olt kan ifm udvikling ikke afvikles fuldstændig som beskrevet i mip
dokumentationen, men kan i det store hele bruges som udgangspunkt for test af
systemet, hvor man enten bruger et referencesystem som modpart(er) eller sit eget
system som modpart(er)
y) (ad appellantens spørgsmål 3.7) testomfang og testparter for test af mip-
interoperabilitet
                                          - 47 -
 test                          afvikling
 mslt1                         kan afvikles over internet eller lan. mip-samfundet
                               specificerer test cases men ikke konkrete test data eller valg af
                               testpart. udføres bilateralt.
 mslt2 & mslt3                 kan afvikles over internet eller lan (mulitlaterale test kun
                               via lan).
                               mslt2 og mslt3 minder i sin specifikation meget om
                               mslt1. dog tages der i mslt2 og mslt3 i højere grad
                               højde for testdata.
 olt                           et uddrag af mslt3 gennemført under virkelighedsnære
                               forhold
fælles for alle testene er, at omfanget set i relation til antallet af krav i mip srs er
meget lavt, og omfanget derfor må betragtes som lille.
fælles for alle testene er endvidere, at de med fordel kan bruges internt under udvikling
til at teste systemet op imod mip samfundets opfattelse af specifikationen. mtemp-
tewg edition 2.2 lægger også op til dette.
z) (ad appellantens spørgsmål 3.7) sondring mellem replikering og compliancy ved test
af funktionalitet
emnet har været berørt fra en række vinkler i skønstemaet. der er ikke en komplet
korrespondance mellem kravene i kravspecifikationens afsnit 7.24 mip compliancy
henholdsvis 7.25 replication på den ene side og mip-samfundets testsuite på den anden
side. det er dog også her rimeligt at pege på, at kravene afsnit 7.25 replication peger
hen mod at bestå testene mslt1 og mslt2, og at kravene i afsnit 7.24 mip
compliancy herefter peger i retning af at kunne bestå mslt3 (og evt olt).
æ) (ad appellantens spørgsmål 3.7) alternative valg af testmetode
det er ikke eneste sædvanlige metode, men det er den metode, der lægges op til via
projektets procesbeskrivelse og mip-dokumentationen. man må endvidere formode, at
man i forbindelse med mip-samfundet er nødt til at følge deres retningslinjer, hvilket
begrænser metodefriheden en del i praksis.
3.8 egnethed og værdi af testen beskrevet i bilag p
a.
for et stort system som daccis med mange års gennemført udvikling skal en test af
denne karakter foretaget 6-7 måneder før den endelige aflevering være test af et fuldt
integreret system. i fuld overensstemmelse med denne vurdering, ligger testen ligger
højt placeret i v‟et. det er derfor en rimelig forudsætning for testforløbet, at der forud
er gennemført grundige test, herunder integrationstest, i et konstrueret testmiljø (i
modsætning til et virkelighedsnært, operationelt miljø). selv med denne forudsætning,
vurderes de 4 dage at være et overraskende kort tidsrum, som stiller skærpede krav til
forudgående test og smidigheden af de 4 dages test.
                                        - 48 -
det virker meget svært at se en god, it-faglig begrundelsen for, at en sådan test skal
gennemføres på andet end med et integreret system sat op i et virkelighedslignende,
integreret teknisk miljø.
b.
en sådan test af separate systemdele er på rette tidspunkt fuldt ud meningsfuld, men en
sådan test er længere nede på højre side af v-modellen og må derfor forudsættes at være
gennemført før oc-testen. der vil så være tale om en sub-system test og af et komplet
sub-system. en sub-system test er normalt en intern test, som følger efter unit/modul
test og ligger før systemintegrationstest, og som derfor ligger før kundens formelle test
af systemet.
c.
værdien af en sådan test vil være væsentligt ringere end en test af et samlet system.
de væsentligste fejl findes typisk som intergrationsfejl, og da testformen ikke tester alle
integrationer, må det påregnes, at væsentlige fejl vil blive overset. det er et almindeligt
anerkendt faktum for store it-projekter, at det kan være vanskeligt og bekosteligt at få
sub-systemer i forskellige versioner til at fungere sammen og bestå de såkaldte
regressionstest, der skal sikre konsistens efter versionsskifte.
ø) (ad appellantens spørgsmål 3.8) egnethed af test under alternative forudsætninger
1.
som beskrevet bl.a. under svaret til spørgsmål t) har begrebet fremdriftstest ikke en
selvstændig mening, der ændrer forudsætningerne for at vurdere forløbet i forbindelse
med testen.
2.
det springende punkt er, at mip og bdm ikke bliver testet som integrerede moduler i
en samlet test af et samlet system. som nævnte under andre svar, er det på dette punkt af
testforløbet en rimelig forudsætning, at subsystemerne (herunder mip, bdm, m.fl.) er
blevet testet både separat og som integreret (del-)system i diverse testopstillinger. fokus
for oc var en samlet systemtest under virkelighedsnære forhold, og de opstillede
forudsætninger for spørgsmålets punkt 2. påvirker derfor ikke svaret til 3.8.
3.
svaret til punkt 2. gælder også i uændret form for dette spørgsmål.
å) (ad appellantens spørgsmål 3.8) identifikation af modpart før testforløb
det er tidligere nævnt, at fremdriftstest ikke er en term, der sætter eller løfter særlige
forventninger for testen, og besvarelsernes udgangspunkt være, at oc er en systemtest,
(se evt. aaz afsnit 2.3), hvortil der er knyttet visse kriterier for accept.
1.
i nærværende sammenhæng opnår testen den største værdi, såfremt man ikke på forhånd
har kendskab til, hvilke modparter der i øvrigt deltager. som generel betragtning vil det
være god skik at aftale hvilke kommunikationsmodparter, der er relevante for et system.
hvis der er tale om en åben gruppe af kommunikationsmodparter, der opfylder en
bestemt standard, vil det er det indlysende nødvendigt - og god skik - at have en præcis
beskrivelse af standarden til rådighed. i det konkrete tilfælde er det meningen, at
                                         - 49 -
daccis skal understøtte kommunikation via mip med alle andre (c2) systemer, som
også understøtter mip. ideen med mip er, at når man understøtter mip, så behøver man
ikke kende unødvendige detaljer om modpartens/den allieredes c2 system. derfor skal
daccis fungere mod et vilkårligt c2 system der understøtter mip, og i princippet
kræves ingen nærmere forkundskab om den konkrete modpart - det skal bare virke.
derfor behøver man ikke have noget kendskab til hvilket c2 system, der testes op imod
- tværtimod ville det forringe værdien af testen og give indikationer på dårlig kvalitet,
hvis man havde brug for at kende modparten inden.
universet af c2-systemer og mip-implementationer er tydeligvis ganske komplekst, og
i praksis vil man sandsynligvis opleve, at billedet er mere grumset end beskrevet
umiddelbart herover. som eksempel blev der registreret ganske forskellige testresultater
over for forskellige mip-modparter under testene i foråret 2006 som dokumenteret i
bilag 3, annex c. hvis den situation antages at være repræsentativ for det generelle
billede, så vil god skik fordre, at parterne aftaler hvilke modparter, som daccis skal
kunne kommunikere med under mip. hvis mip-modparterne ikke kan antages at
udgøre en helt homogen gruppe, er den eneste mulighed for at sikre succesfuld mip-
kommunikationen med alle modparter at lade testforløbet inkludere test mod alle
deltagerne i gruppen. alternativt må daccis‟ egen implementering af mip-interfacet
være så robust over for både standardsituationer og fejlscenarier, at eventuel manglede
homogenitet i landenes mip-implementeringer kan håndteres på denne vis.
da oc-testen ligger højt på v‟ets højre side og må det forventes, at både
standardsituationer og fejlscenarier kan håndteres robust. hvis en implementering af et
interface er robust og tager højde for fejlscenarier er kendskab til modpartens
implementering af interfacet ikke afgørende. det må forventes, at der før dette punkt
netop er gennemført test mod relevante referencesystemer. at disse tests er gennemført,
før kunden involveres i accepttest vil være sædvanlig praksis
2. svaret til punkt 1. beskriver situationen.
3. svaret til punkt 1. beskriver situationen.
svaret er baseret, på hvad der er it-fagligt forventeligt. der er i princippet ikke nogle
forskelle baseret på ophævelsesadgangen, dog understreger tilstedeværelsen af
hæveadgang og testens høje placering i v‟et, at parterne for at have en klar aftale og
fornuftig retsstilling må forventes at have en præcis forståelse om testmodparter eller
fokus på test mod specifikationer.
ved tilrettelæggelsen af det samlede testforløb må forventes at være sikret, at man kan
køre op i mod alle kendte modparter, inden kunden involveres i en accepttest.
alternativt kan en klar situation skabes ved at sikre, at implementationen sker op imod
specifikationen og ikke mod en kendt implementation af denne. ved ikke at kende
modparten på forhånd sikres det, at der implementeres op imod specifikationen. en
efterfølgende analyse af observerede “fejl” vil så kunne afgøre, om de formodede
fejlsituationer tilskrives fejl i daccis eller fejl i modpartens system.
aa) (ad appellantens spørgsmål 3.8) om modparten er forudsat i “actual test bed
description” eller “scenario eventlist”
der forudsættes en modpart i scenarierne, men der stilles ikke krav eller forventning til
et specifikt c2is.
                                        - 50 -
bb) (ad appellantens spørgsmål 3.8) om præ-test
der er ikke sædvanlig praksis på området. svaret til punkt 1. under spørgsmål å) giver
et billede af situationen om kendskab eller ej til den eller de konkrete modpart(er) og
forventningerne til forudgående testforløb.
konkret er det i tilfælde af en accepttest er det almindeligt, at leverandøren gennemfører
en prætest. det er sandsynligt, at leverandøren vil være mere velforberedt til den
egentlige test, hvis der er lavet en prætest, men der er findes også andre gængse måder
at forberede sig på. en prætest bør ikke have nogen indflydelse på testmetode og
omfang af den efterfølgende, egentlige test. prætesten er typisk et for leverandøren
internt anliggende.
3.9) om test af mip interoperabilitet adskilt fra det øvrige daccis system
jvf. procesmodellen kan og bør der være en afprøvning af de enkelte subsystemer
adskilt fra resten af systemet, før systemet integreres. det er ift. den i bilag aay
beskrevne model et internt anliggende hos leverandøren at udføre dette - og det er god
it skik at udføre sådanne.
a.
såfremt der er tale om en subsystem, er det it-fagligt korrekt og hensigtsmæssigt. i
daccis-sammenhæng har man dog officielt for mip-delen deltaget i afprøvninger i
mip-samfundet med mslt1 og mslt2, der kan betragtes som en delvis test af mip
subsystemet.
b.
en sådan adskilt test er velegnet til at finde visse fejl inden for subsystemet, men den vil
ikke være dækkende og retvisende for subsystemets funktion som en del af det
integrerede system.
c.
en sådan adskilt test er ikke egnet til at vise fremdrift af det samlede system. den kan
være en forudsætning for, om det er relevant at prøve at samle systemet. vores skøn er
at daccis-projektet har haft rimeligt held med at lave, hvad der svarer til mslt1 og
mslt2, da de har bestået en del test i mip-samfundet.
cc) (ad appellantens spørgsmål 3.9) om separat test under alternative forudsætninger
1.
svaret er enslydende med svaret på spørgsmål 3.9. jvf diskussionen af begrebet
fremdriftstest, gør brugen af termen ingen forskel.
2.
det gør ikke nogen nævneværdig forskel. vi skønner, at man kun kan opnå et
retvisende billede ved at teste systemet i sin helhed på dette meget fremskredne
tidspunkt i forløbet.
dd) (ad appellantens spørgsmål 3.9) separat test af mip i lyset af historik for mip-test
                                        - 51 -
det gør ingen forskel. det er dog betryggende, at man med mip-gatewayen har været i
stand til at gennemføre en del succesfulde test i mip-regi. men mip kræver ilt
(implementation level testing) udført før man kan deltage i mslt1, og mip-samfundets
materiale lægger generelt vægt på, at landene er velforberedte, når de mødes for at teste
i mip-regi.
3.10) forskellige typer test af bdm
den type af test som bdm implementeringen bør gennemgå er beskrevet i afsnittet om
v-modellen. bdm er blot et af flere subsystemer.
ee) (ad appellantens spørgsmål 3.10) forskellige typer test af bdm under alternative
forudsætninger
1.
brugen af termen fremdriftstest ændrer ikke på svaret, som bliver enslydende med
svaret på spørgsmål 3.10
2)
disse forudsætninger/præciseringer ændrer ikke svaret
ff) (ad appellantens spørgsmål 3.10) alternative valg af typer af test for bdm
svaret i 3.10 er ikke det eneste mulige svar, men svaret er et udtryk for god praksis og i
overensstemmelse med parternes aftale om brug af v-modellen.
3.11) omstændigheder for separat test af bdm
svaret på spørgsmål 3.9) er også dækkende som svar på spørgsmål 3.11)
gg) (ad appellantens spørgsmål 3.11) omstændigheder for separat test af bdm under
visse forudsætninger
svaret på spørgsmål cc) er også dækkende som svar på spørgsmål 3.11)
hh) (ad appellantens spørgsmål 3.4, 3.8, 3.9 samt 3.11) er oc-testen en samlet
systemtest?
oc-testens placering i v‟et gør det til en helt klar forventning, at der er tale om en test
af et samlet system. lige så klart er det ved læsning af kravspecifikationen, at der er tale
om et mindre system end det fulde system, der skal testes ved fc og siden anvendes i
egentlig drift.
der er dog funktionelle leverancer på “shall” niveau fra samtlige subsystemer til oc,
hvilket viser at parterne ved oc har ønsket at kunne teste bredt ud i systemets dele (men
altså ikke med fuld funktionalitet). det har endvidere været et formål med oc, at have
et produkt, som kunne bruges i brugerens “rigtige” miljø, jvf f.eks.projekt management
planen i bilag aaz, hvor afsnit 2 bl.a. læser: “to get an operational product capable of
use by the customer”
ii) code freeze - definition og praksis
                                              - 52 -
     1.
     “code freeze” er et begreb man anvender i større udviklingsprojekter. code freeze
     indikerer, at man har færdiggjort den funktionelle udvikling og nu koncentrerer sig om
     at samle systemet (og subsystemer) til en fungerende helhed. dvs. at ændringer, som
     f.eks. er nødvendige for at et sub-system kan/skal integreres vil blive accepteret, mens
     at ny hidtil ukendt funktionalitet ikke kan prioriteres. hvis det alligevel vurderes
     hensigtsmæssigt at prioritere ny (brugervendt) funktionalitet, vil man forsøge at lægge
     disse i nye spor (branches), som så ekskluderes, når man samler systemet til den
     forstående aflevering. disse ændringer kan man så først teste i sammenhæng ved en
     senere lejlighed. dvs. ved code freeze op til en leverance skal man have færdiggjort
     udviklingen af al “shall” funktionalitet - ellers vil man have inkonsistens i sin
     leveranceplan. det er bemærkelsesværdigt, at der besluttes en code freeze allerede i
     august måned (med virkning fra uge 38, 17-21 september) kort tid efter at kontrakten er
     indgået. hvis leveranceplanerne skulle være konsistente, må det være baseret på en
     forventning om, at shall-funktionaliteterne til oc kunne være færdige til uge 38, men
     dette har vi ikke undersøgt nærmere.
     2.
     ja det er it-fagligt sædvanligt. perioden er dog i dette tilfælde ganske lang. en
     motivation for dette kunne være, hvis projektet har vurderet, at der var en betydelig
     opgave i at fejlrette og stabilisere koden, men dette er ikke undersøgt nærmere.
     3.
     det er almindeligt at arbejde videre på koden i en anden brach (anden version i
     versionsstyringssystemet), mens man har code freeze til en given release. det er ikke
     almindeligt at arbejde videre med funktionelle krav i den version af koden, der er
     omfattet af freeze. det er hele pointen med freeze. der ændres ikke funktionelt på den
     version af koden, før den aktuelle freeze-periode er overstået - typisk i forbindelse med
     en konkret milepæl for projektet.
     4.
     i det øjeblik, der vedtages en code freeze (typisk op til en konkret milepæl), vil det være
     god skik at sikre, at der foreligger en konsistent leveranceplan med overensstemmelse
     mellem forventningerne til den freeze-omfattede kode, hvad angår funktionalitet og
     testomfang. udgangspunktet vil selvsagt være at teste funktionaliteten, som den
     oprindeligt var aftalt, og hvis beslutningen om code freeze kunne give anledning til at
     ændre dette, må det håndteres via procedurerne for ændringsønsker til projektet. hvis
     man bliver enige om at medtage nye funktionelle krav med efter freeze, kan der med
     fordel teste mod de nye krav også. evt. afvigelser ift. de nye krav vil dog kun figurere
     som ændringsønsker i rapporten (i daccis termer som f5).”
af skønstemaet fremgår, at skønsmændene bedes svare på følgende spørgsmål 4:
     ”4. spørgsmål relateret til øvrige ikke-testede krav
     4.1 skønsmanden bedes ud fra brugerkravene i bilag 3 med annex a-e til kontrakt af
     29. juni 2007 (bilag 1) redegøre for, om det forhold, at et brugerkrav eventu-
     elt ikke er testet, er ensbetydende med, at der potentielt er 1 yderligere fejl ved
     systemet, eller om flere fejl potentielt kan hidrøre fra samme brugerkrav.
                                              - 53 -
     4.2 skønsmanden bedes gennemgå dokumenterne "testforløb i relation til de påståede
     ikke testede core-krav" (bilag x) og "testforløb i relation til de yderligere 12 påståede
     ikke testede core-krav" (bilag ar) samt redegøre for, om bilag x og bilag ar er udtryk
     for en i it-faglig sammenhæng korrekt og sædvanlig måde at foretage verifikation af
     brugerkrav.
     jj) (ad appellantens spørgsmål 4.2) skønsmanden bedes gennemgå redegørelserne for
     hvert krav i bilag x og ar og eventuelle spørgsmål i den forbindelse bedes afklaret ved
     interview af parterne. skønsmanden bedes herefter anføre for hvert omtalt krav med
     hvilken grad af sikkerhed, det kan bekræftes, at kravet blev verificeret som opfyldt.
     4.3 såfremt skønsmanden ikke ser sig i stand til at besvare spørgsmål 4.2 på det fore-
     liggende grundlag, bedes skønsmanden oplyse, hvilket materiale skønsmanden har be-
     hov for at modtage for at kunne besvare spørgsmålet.
     kk) (ikke aftalt afprøvning af dokumentation) skønsmanden bedes forudsætte, 1) at oc
     testen i uge 51 var en operativ brugertest samt, 2) at der ikke ved denne test var aftalt
     afprøvning af dokumentationen henvist til i c0r128, c0r129, c0r133, c0r134 og
     c0r135. skønsmanden bedes på det grundlag redegøre for, om det under en sådan test
     er normal praksis at verificere og rapportere verifikation af dokumentation så som do-
     kumentationen henvist til i cor128, c0r129, cor133, c0r134 og c0r135.
     ll) (aftalt afprøvning af dokumentation) skønsmanden bedes forudsætte, 1) at der ved
     oc testen i uge 51 var aftalt afprøvning af dokumentationen henvist til i cor128,
     cor129, cor133, cor134 og cor135, eller 2) at sådan afprøvning er normal prak-
     sis, jf. svaret på spørgsmål ide). skønsmanden bedes på det grundlag redegøre for,
     hvordan en fejl eller mangel ved - herunder manglende tilstedeværelse af- dokumentati-
     onen henvist til i c0r128, c0r129, c0r133, cor134 og cor135 normalt vil blive ve-
     rificeret og rapporteret at være verificeret.”
af skønsmændenes besvarelse af spørgsmål 4 fremgår følgende:
     ”4. spørgsmål relateret til øvrige ikke-testede krav
     4.1) er der potentielt en eller flere mulige fejl per krav
     der kan være flere fejl i relation til et krav. typisk er der mange krav uden fejl og få
     krav, der har forholdsvis mange af de rapporterede fejl. i et stort system som daccis
     med en temmelig overordnet kravspecifikation, er det ganske afgjort en realistisk mu-
     lighed, at der er mere end én fejl per krav. kravspecifikationen i bilag 3, annex d, har
     ca 175 krav anført som shall-krav til fc, men det vil være en temmelig fjern tanke, at
     tallet 175 på nogen måde skulle udgøre en overgrænse for det antal fejl, man kan fore-
     stille sig i systemet.
     et brugerkrav vil som regel udmunde i en use case med multiple flow endpoints. hver
     af disse flows bør testes af brugerne med de fejlmuligheder, det måtte indebære.
     4.2) er bilag x og ar udtryk for korrekt og sædvanlig verifikation af brugerkrav
     bilag x og ar bruger en argumentativ metode for at eftervise, at et givet krav er blevet
     testet.. test er en bevidst handling med det formål at finde fejl. det kan ikke udføres in-
                                         - 54 -
direkte. at man kan påvise eller sandsynliggøre, at en funktionalitet eksisterer eller
“virker” i såkaldt “sunny day” er ikke det samme som, at den er testet. man har blot
fundet i hvert fald én kontekst, hvor den virker som forventet. testcases og testdata skal
udvælges nøje. som tommelfingerregel kan man regne med 4 eller flere tests pr. ækvi-
valensklasse i input data. værdierne skal vælges på grænserne af klasserne, da erfaring
viser, at det typisk er her fejlene opstår. det mest brugte argument, “det blev brugt uden
anmærkninger” er ikke et validt argument for, at det er blevet testet. det er kun et ar-
gument for, at det er blevet brugt, og at der eksisterer ét fungerende scenarie relateret til
kravet.
jj) (ad appellantens spørgsmål 4.2) om krav i bilag x og ar kan bekræftes som verifi-
cerede
hvis et krav skal være “verificeret som opfyldt” af en given proces, så må dette opfyl-
des ved en sædvanlig it-faglig test. det vil, som beskrevet i svaret til spørgsmål 4.2),
ikke være tilstrækkeligt at sandsynliggøre, at kravet er opfyldt i en bestemt, udvalgt si-
tuation. ved gennemgangen af kravene i bilag x og ar er der derfor søgt efter, om det
er sandsynliggjort, at der er gennemført handlinger, der kan sidestilles med en systema-
tisk søgen efter fejl i et passende udvalg af relevante situationer.
 krav                                                verificeret ja/nej
 cor47                                               nej
 cor48                                               nej
 cor49                                               uvist
 cor50                                               nej
 cor94                                               nej
 cor99                                               nej - der er dog foretaget arbejde, som
                                                     med god vilje kan sidestilles med test,
                                                     idet man tilsyneladende bevidst har søgt
                                                     efter fejl
 cor102                                              nej
 cor108                                              uvist
 cor109                                              uvist
 cor110                                              nej
 cor111                                              uvist
 cor111                                              nej
 cor2                                                nej
 cor679 og cor59                                     nej
                                - 55 -
cor60                                 nej
cor601 og cor602                      nej
cor78, 79, 81, 83, 84, 8·5. 99        nej
cor89                                 nej
cor90                                 nej
cor97                                 nej
cor103 og cor104                      tilsyneladende
cor105                                uvist
cor106                                uvist
cor107                                nej
cor113                                nej
cor116                                delvist verificeret. hvorvidt “most im-
                                      portantly, it holds operational and tacti-
                                      cal data” er opfyldt, kan vi ikke udtale
                                      os om
cor117                                ja
cor118                                nej, væsentlige mangler i forhold til
                                      sds og det database subsystem, som er
                                      beskrevet der. for at kunne verificere
                                      cor118 skal olt kunne gennemføres
cor120                                nej
cor213                                uvist
cor122                                nej
cor123                                uvist
cor124                                nej
cor125                                uvist
cor126                                uvist
cor128                                nej
cor129                                nej
cor131                                nej
cori32, 133, 134 135                  uvist
                                            - 56 -
      cori40                                            nej
      cor141                                            ja
      cor142                                            nej
      cor143                                            nej
      cor144                                            nej
      cor145                                            uvist
      cor146 & 147                                      nej
      cor148                                            nej
      corl50 &151                                       uvist
      cor152                                            uvist
      cor153                                            nej
     4.3) behov for supplerende materiale?
     spørgsmål 4.2 er besvaret på det foreliggende grundlag.
     kk) (ikke aftalt afprøvning af dokumentation)
     forudsætning 2) er i modstrid med kontraktens bilag 3 annex d, så hvis forudsætnin-
     gen skal holde, må det andetsteds være aftalt at fravige dette.
     det ville være almindeligt at verificere dokumentationen beskrevet i de nævnte krav
     tidligere i processen. et dokument bør verificeres umiddelbart efter tilvejebringelse af
     dokumentet, sker dette ikke, vil det være oplagt at verificere de dele af manualer, der
     har med et givet scenarie at gøre samtidig med, at man afprøver selve scenariet.
     dokumentationen skal selvfølgelig være korrekt og færdigredigeret til en accepttest og
     fejl i dokumentationen kan sagtens være væsentlige og kræve behandling på niveau med
     andre væsentlige fejl.
     ll) (aftalt afprøvning af dokumentation)
     jvf. svaret til spørgsmål kk) vil denne afprøvning typisk være sket inden selve testen.
     afprøvningsformen for dokumenter er uanset hvornår, den sker, et formelt review, hvor
     observationer dokumenteres i rapporten, og hvor fejl registreres på linie med alle mulige
     andre fejl i systemet. fejl i dokumentation kan medføre, at brugerne anvender systemet
     utilsigtet med uforudsigelige konsekvenser til følge.”
af skønstemaet fremgår, at skønsmændene bedes svare på følgende spørgsmål 5:
     ”5. spørgsmål relateret til ændringer i systemets arkitektur
                                              - 57 -
     5.1 skønsmanden bedes gennemgå dokumentet "architecture briefing" af 5. oktober
     2007 (bilag 0) samt beskrive omfanget af og arten af de ændringer i systemets arkitek-
     tur, som dokumentet lægger op til.
     5.2 såfremt skønsmanden ikke ser sig i stand til at besvare spørgsmål 5.1, bedes skøns-
     manden oplyse, hvilket materiale skønsmanden har behov for at modtage for at kunne
     besvare spørgsmålet.”
af skønsmændenes besvarelse af spørgsmål 5 fremgår følgende:
     ”5. spørgsmål relateret til ændringer i systemet
     5.1 omfang af og arten af de ændringer, der lægges op til
     dokumentet er på et overordnet niveau og bruger ikke den navngivning, som eksisterer
     i de øvrige til kontrakten/projektet hørende dokumenter. derfor kan det være lidt svært
     med sikkerhed at sige hvilken kontekst, at præsentationen skal ses i. det er uklart for os,
     om præsentationen udelukkende hidrører arbejdet med kontrakten af 29. juni 2007 eller
     om den i højere grad skal ses som et sagsindlæg i det generelle samarbejde parterne
     imellem. at dokumentet kunne omhandle arbejde ud over/uden for kontrakten tilskri-
     ves, at den indeholder aktiviteter i forhold til mip block 3 implementering.
     dokumentet viser, at der udestår væsentligt refactorering (omkodning) af c2 og mip
     gateway (sub system replikering) for, at den kan leve op til den struktur som er skitseret
     i sds‟en (system design specification).
     arkitekturændringerne vil medføre følgende:
    der flyttes funktionalitet mellem sub-systemer. de involverede sub-systemer er c2 ser-
     ver (ukendt), bdm og mip-gateway (ukendt - men der sigtes sikkert på “replikering”).
     det forekommer, at funktionalitet nu lægges i de subsystemer, hvor de i henhold til
     sds‟en allerede burde være
    oprydning i koden. det ser ud til, at flere komponenter hidtil har været ude i samme
     ærinde, og nu ønsker man at fokusere arbejdet i de dertil indrettede subsystemer, hvilket
     forekommer indlysende fornuftigt. det kan dog undre, at dette ikke har været på plads
     langt tidligere, oprydningen må være betinget af, at systemet har været under udvikling i
     10 år. det ville have været god skik at gennemføre denne oprydning løbende over de 10
     år, specielt taget i betragtning at arbejdet handler om at implementere systemet i over-
     ensstemmelse med sds.
    oprydning i databaser. dokumentet giver indtryk af, at projektet tilsyneladende er i fuld
     gang med at implementere jc3 - dvs. mip block 3, som ikke er omfattet af den frem-
     lagte aftale.
     på interfacesiden taler man nu om servere og klienter, hvor man ellers i sagens materi-
     ale taler om funktionalitet i og interfaces mellem forskellige sub-systemer. det fore-
     kommer ikke klart, hvorfor der introduceres client/server begrebet, som inden for it-
     mæssigt er et meget rummeligt begreb. de implementeringsmæssige konsekvenser af
     dokumentet kan have været meget omfattende. det er svært at se denne væsentlige flyt-
     ning af funktionalitet og oprydning for at stabilisere systemet være meningsfuld sam-
     menholdt med det vedtagne code freeze op mod oc.
                                             - 58 -
     dokumentet synes ikke at foreslå andet mht struktur, end det man allerede kunne for-
     vente: nemlig subsystemer som angivet i sds‟en med tilhørende funktionalitet. at gå
     ind og tale om at minimere antallet af persistente databaser i en struktur, hvor man har
     et database sub-system, burde ikke være en arkitektur ndring men en intern oprydning i
     database-subsystemet.
     5.2 behov for supplerende materiale?
     spørgsmålet er besvaret med svaret på spørgsmål 5.1 herover.”
af skønstemaet fremgår, at skønsmændene bedes svare på følgende spørgsmål 6:
     ”6. spørgsmål relateret til kategoriseringen af fejl
     6.1 skønsmanden bedes, for hver omtvistet observation beskrevet i bilag aac redegøre
     for,
 a) om den pågældende fejl kan siges alene at vedrøre forvrængning af information,
     præsenteret for brugeren,
 b) om den metode for omgåelse, der er anført, er 1t fagligt korrekt og forsvarlig ved
     operationel test af et it-system med kompleksitetsgrad som daccis,
 c) om den metode for omgåelse, der er anført, kan bruges uden at påføre brugeren, hvad
     der it-fagligt må anses for en uacceptabel arbejdsbyrde eller forringelse af brugerens
     arbejdsmæssige effektivitet,
 d) om den metode for omgåelse, der er anført, er selvindlysende, dvs, anvendelig uden at
     brugeren i den konkrete situation adviseres om den pågældende metode, og
 e) om besvarelsen af spørgsmål 6.1. b, c og d vil være anderledes, såfremt brugeren på
     forhånd er blevet oplyst om omgåelsesmetoden, f. eks. i forbindelse med uddannelse el-
     ler angivelse i brugervejledningen.”
af skønsmændenes besvarelse af spørgsmål 6 fremgår følgende:
     ”6 spørgsmål relateret til kategoriseringen af fejl
     6.1 omtvistede observationer
     for en god ordens skyld skal det præciseres, at der i overensstemmelse med spørgsmå-
     lets ordlyd anvendes sædvanlige it-faglige kriterier ved vurderingen af de enkelte del-
     spørgsmål. der er således ikke taget hensyn til de eksempler på f3-fejl, der er anført i
     bilag aac eller parternes indlæg om dette emne i tilknytning til f3-eksemplerne.
     observation mdd00014590
     a) ja, der er tilsyneladende tale udelukkende om en forvrængning
     b) nej, omgåelsen er uacceptabel.
     c) det er en uproblematisk byrde.
     d) nej, det er ikke selvindlysende, at man skal benytte en anden funktionalitet for at få
     verificeret at data er valide.
     e) såfremt fejlen er evident, altså hvis det må være indlysende for brugeren, at et kort
     uden symboler er en fejlsituation, og brugeren derigennem er specifikt “advaret” om, at
     man skal tilvælge g3 tera, og der gives forudgående undervisning, der underbygger
                                        - 59 -
denne proces vil det være en forbedring. svarene til de øvrige spørgsmål vil ikke være
påvirket af forudgående uddannelse.
observation mdd00014389
a) ja, der er tilsyneladende tale udelukkende om en forvrængning
b) ja
c) ja, det er en uproblematisk byrde
d) ja
e) nej
observation mdd00014473
a) systemet bør slet ikke acceptere invalide data, så der er ikke kun tale om forvræng-
ning.
b) uacceptabel omgåelse.
c) nej
d) nej
e) nej. denne fejl er i systemets forretningsregler for håndtering af forkerte datainput.
observation mdd00014569
a) ja, der er tilsyneladende tale udelukkende om en forvrængning
b) nej. der tegnes tilsyneladende et skærmbillede, som ikke i sig selv er indlysende
forkert for en bruger, der ikke har frisk kendskab til sessionens kontekst. man kan såle-
des ikke altid vide, hvornår det er nødvendigt at trykke f5.
c) ja
d) nej
e) nej
observation mdd00014475
a) nej, der er tale om en funktion, som ikke findes
b) nej, der er ikke angivet en metode for omgåelse
c) n/a
d) n/a
e) nej.
observation mdd00014558
a) ja, der er tilsyneladende tale udelukkende om en forvrængning
b) nej, der tegnes tilsyneladende et skærmbillede, som ikke i sig selv er indlysende for-
kert for en bruger, der ikke har frisk kendskab til sessionens kontekst. man kan således
ikke altid vide, hvornår det er nødvendigt at benytte omgåelsen
c) ja
d) nej
e) nej
observation mdd00014559
a) ja, der er tilsyneladende tale udelukkende om en forvrængning
b) nej, der kan tilsyneladende produceres et print, som ikke i sig selv er indlysende for-
kert for enhver læser. man kan således ikke vide, hvornår det er nødvendigt at anvende
omgåelsen.
c) ja
d) ja
e) nej
                                        - 60 -
observation mdd00014620
a) ja, der er tilsyneladende tale udelukkende om en forvrængning
b) nej, at genstarte klienten er ikke acceptabelt
c) nej
d) nej
e) ja, svaret på delspørgsmål d) kan blive “ja”, hvis det er korrekt, at den sorte farve al-
tid entydigt kan identificeres som en fejl, og der gennemføres relevant undervisning
observation mdd00014644
a) ja, der er tilsyneladende tale udelukkende om en forvrængning
b) ja
c) ja
d) ja
e) nej
observation mdd00014513
a) nej, det er en grundlæggende data fejl.
b) nej
c) nej
d) nej
e) nej, men brugerne af systemet bør uddannes for at afbøde eventuelle uønskede kon-
sekvenser ved fejlen
observation mdd00014567
a) nej, spørgsmålet omhandler performance
b) nej, der er ikke anvist nogen omgåelse
c) n/a
d) n/a
e) ja, svaret på delspørgsmål d) kan være “ja”, hvis brugerne på forhånd ved, at denne
funktion kan tage meget lang tid.
observation mdd00014393
a) nej, der er tale om uoverensstemmelse mellem krav og implementation
b) nej, der er ikke angivet nogen metode for omgåelse
c) n/a
d) n/a
e) n/a
observation mdd00012290
a) nej, observationen gælder kapacitet og ydeevne
b) nej, der er ikke angivet nogen metode for omgåelse
c) n/a
d) n/a
e) n/a
observation mdd00014466
a) nej, observationen gælder kapacitet og ydeevne
b) nej, der er ikke angivet nogen metode for omgåelse
c) n/a
d) n/a
                                              - 61 -
     e) n/a
     observation mdd00014480
     a) nej, observationen gælder manglende funktionalitet, tilsyneladende med baggrund i
     inkonsistente opfattelser af systemtid
     b) nej, der er ikke angivet nogen metode for omgåelse
     c) n/a
     d) n/a
     e) n/a
     observation mdd00014138
     a) nej, observationen gælder vanskeligheder i forbindelse med installation
     b) det er ikke helt klart. i bilag aac anføres det under “description”, at en geninstalla-
     tion ikke er pålidelig trods systemets bekræftende tilbagemelding, omvendt anføres det
     under “saabs bemærkninger”, at geninstallation gav det ønskede resultat
     c) nej
     d) dette er uklart. se svaret til delspørgsmål b).
     e) nej, men den de relevante (super-)brugerne af systemet bør uddannes for at afbøde
     eventuelle uønskede konsekvenser ved fejlen
     observation mdd00014312
     a) nej, observationen gælder vanskeligheder i forbindelse med installation
     b) ja
     c) nej
     d) ja.
     e) nej, men den de relevante (super-)brugerne af systemet bør uddannes for at afbøde
     eventuelle uønskede konsekvenser ved fejlen
     observation mdd00014806
     a) ja, der er tilsyneladende tale udelukkende om en forvrængning
     b) nej, der er ikke angivet nogen metode for omgåelse
     c) n/a
     d) n/a
     e) n/a
     observation mdd00014138
     a) ja, der er tilsyneladende tale udelukkende om en forvrængning
     b) nej, der er ikke angivet nogen metode for omgåelse
     c) n/a
     d) n/a
     e) n/a”
af skønstemaet fremgår, at skønsmændene bedes svare på følgende spørgsmål 7:
     ”7. spørgsmål relateret til daccis' operationelle anvendelighed på tidspunktet for oc
     mm) skønsmanden bedes gennemgå kravspecifikationen i kontraktens bilag 3, anneks d
     for hvilke funktioner, der var "shall-krav", hhv, ikke var "shall-krav", til oc, og eventu-
     elle spørgsmål i den forbindelse bedes afklaret ved interview af parterne. skønsmanden
                                             - 62 -
     bedes herefter redegøre for, om et system baseret alene på "shall-kravene" til og ville
     have operationel det ville kunne bruges i krig”.
af skønsmændenes besvarelse af spørgsmål 7 fremgår følgende:
     ”7. spørgsmål relateret til daccis' operationelle anvendelighed på tidspunktet for oc
     mm)
     en gennemgang af kravene markeret som “shall” under oc viser, at krav relateret til
     basal systemfunktionalitet er prioriteret til oc. for de enkelte grupper af krav i bilag 3,
     annex d, er det herunder angivet, i hvilken grad shall-kravene til fc også er shall-krav
     til oc. noget forsimplet kan det opsummeres, at følgende, overordnede områder har en
     høj andel af shall-krav:
    registrering, organisering, strukturering og visning af enheder (områderne: general,
     operational order textual part, taks organisation, general situation)
    basal planlægning (områderne: planning process og g3 operation plan tactical layer)
    håndtering af kort (områderne: map handling og g2 gis functionality)
    håndtering og udveksling af data (områderne: basis data, database, replication,
     synchronisation)
    projektets standarder og kvalitet (områderne: general, performance, documentation,
     installation, quality, configuration, reliability, usability)
     et system, som implementerer de krav der er markeret som “shall” under oc i bilag 3,
     kan sandsynligvis ud fra et funktionelt synspunkt i et vist omfang finde anvendelse til
     operationelle opgaver som registrerings- og dataudvekslingsværktøj, da det understøtter
     registrering, visning og udveksling af de grundlæggende datatyper. project management
     plan i bilag aaz omtaler resultatet af oc som “an operational product capable of use
     by the customer”. der må dog også siges at være enighed mellem sagens parter om, at
     et fuldt anvendeligt system kræver en mere omfattende funktionalitet, nemlig som defi-
     neret af den endelige leverance ved fc. givet, at så mange af de funktionelle krav ud
     over de helt grundlæggende funktionaliteter ikke er shall-krav til oc, må det formodes,
     at den praktiske gavn af et “oc-system” ville være begrænset i en krigssituation.
     det skal for en god ordens skyld fremhæves, at svaret her - i overensstemmelse med
     spørgsmålets formulering - er baseret på, hvad man kunne forvente af et system, der op-
     fylder alle shall-krav til oc. der er ikke foretaget en vurdering af den faktiske leverance
     til oc.
     andel af shall-krav til oc i forhold til fc i de enkelte kravgrupper i bilag 3, annex d:
    general: høj andel
    planning process: ca halvdelen
    operational order textual part: alle
    taks organisation: alle
    pre planning: ingen
    general situation: alle
    search: ingen
    g2 intelligence situation: ingen
    g3 operation plan tactical layer: alle
    g3 operation situation: lav andel
    g3 airdefence plan tactical layer: ingen
                                           - 63 -
     g3 airdefence situation: ingen
     g3 engineer plan tactical layer: ingen
     g3 engineer situation: ingen
     g3 firesupport plan tactical layer: ingen
     g3 logistics plan tactical layer: ingen
     g3 logistics situation: ingen
     g9 cimic plan tactical layer: ingen
     g9 cimic situation: ingen
     syncronisation: alle
     basis data: alle
     c2 gis functionality: høj andel
     replication: høj andel
     roles and rights: alle
     system management: alle
     map handling: alle
     import/export operational data: ingen
     database: alle
     krav under overskriften non-functional herunder:
     general: alle
     performance: alle
     documentation: næsten alle
     security: ingen
     installation: alle
     quality: alle
     configuration: alle
     reliability: alle
     usability: alle”
til skønserklæringen er der udarbejdet følgende ordforklaringer, bilag 1 og bilag 2:
      ”ordforklaringer
       “unit test”                    en unit er den mindste selvstændige del/enhed af et pro-
                                      grammel. det er udbredt at man tester en “unit” automa-
                                      tisk ved hjælp af andet programmel i en såkaldt “unit
                                      test”
       mip                            multilateral interoperability programme. mip er et inter-
                                      nationalt program der definerer hvordan allierede parter
                                      kan udveksle data om kampzoner mellem c2is-syste-
                                      mer.
       safety-critical system         et system der ved fejl kan medføre tab af meneskeliv,
                                      legemsbeskadigelse eller medføre væsentlige skader på
                                      materiel, bygninger eller miljø. se f.eks. mil-std-498
                                      sektion 4.2.4.1. denne standard har været aktiv for mi-
                                      litær anvendelse siden 1994-1998 og er stadig i brug
                           - 64 -
product backlog item pbi anvendes i defacto standarden/metoden scrum til
(pbi)                at beskrive de enkelte krav som lægge ind i et udvik-
                     lingsteam.
daccis               danish army command and control information sys-
                     tem
c2is                 command and control information system
trace                sporbarhed. i udviklingsprojekter søger man at bevare
                     overblik ved at fastholde hvor hver komponent kommer
                     fra (krav) og hvilke øvrige ting komponenten ting som
                     den er afhængig af (det kunne f.eks. være test-data). i et
                     projekt med mange medarbejdere og mange versioner
                     over tid er dette afgørende.
bbr                  bygnings og boligregisteret. med reference til en it
                     grænseflade som blev åbnet i 2009.
oig                  operational information group. er det sæt af informati-
                     oner af operationel karakter - det kunne f.eks. være et sæt
                     af data om en fjendtligt “organisation” - noget der be-
                     skriver operationelt relevante data for en fjendtlig enhed.
ilt                  implementation level test. implementation level test
                     refererer til de test et land skal foretage under deres ud-
                     vikling af mip relateret it inden man mødes i mip regi
                     for at foretage test af system (slt) og operation(olt).
slt                  system level test. er nogen test som man kan udføre
                     sammen med andre mip deltagere. man mødes med sine
                     allierede ved forskellige lejligheder og udføre disse tests.
                     system retter sig mod en systematisk gennemgang af
                     tekniske og funktionelle egenskaber der verificeres i
                     modsætning til olt (se nedenfor) hvor det er operatio-
                     nelle (kamp indsatsafprøvning) perspektiver der lægges
                     vægt på.
olt                  operational level test. se også slt.
srs / sds            system requirement specification / system design spe-
                     cification
ssrs /ssds           sub system requirement specification / sub system
                     design specification
swds                 software design specifikation
swtp/r               software test procedure / report
sstp/r               subsystem test procedure / report
                                         - 65 -
 stp/r                              system test procedure / report
 sstr                               sub system test report
bilag 1: uddybning af baggrund for svaret på spørgsmål a) om udviklingsmodel
der bruges i flere sammenhæng termen scrum. scrum er en process model, der
blandt andet kan bruges til softwareudvikling. der er imidlertid mange afvigelser fra
scrum i projektets dokumenter, at det henvisningerne til scrum nærmer sig det
misvisende.
afvigelserne er blandt andet at finde i qa plan.
f.eks. nævnes der “...design and development scrum teams.” i scrum er et vilkår-
ligt team ansvarlig for hele processen fra kravet er defineret til det er leveret, og der kan
ikke være tale om et “design team” eller et “development team”. product owner i
scrum-termer er en person, der kan relatere sig til brugen af systemet og kan priori-
tere de enkelte product backlog items (krav) ift. forretningsværdi. product owner er
derfor typisk en repræsentant for kunden og kan ikke være en del af udviklingsteamet.
arkitekten i daccis er beskrevet som product owner.
der skrives også “the purpose is to assure that the developed system is in principle
ready for delivery to the test team”, men et scrum team er ansvarligt for leverancen
helt til kunden og ikke kun til test. test er en integreret del af hver product backlog
item.
disse kommentarer om afvigelserne fra scrum tager ikke stilling til, om den proces-
model, der er beskrevet under navnet scrum, kan fungere lige så godt som scrum,
men termerne er i hvert fald ikke anvendt stringent.
det skal dog nævnes, at det i en tid, hvor “scrum” nærmest er blevet et mode-begreb,
er der en del procesmodeller, der i daglig tale omtales som scrum, og løs brug af ter-
men er således udbredt. uanset begrundelse er det kritisk ift. projektets fremdrift og
kvaliteten af det leverede, at product owneren fejlagtigt er placeret som en del af ud-
viklingsteamet.
der er uoverensstemmelser mellem modellen på side 13 i bilag aay og listen af arte-
fakter i de følgende afsnit. f.eks nævnes der både en “system requirements sepcifica-
tion” og “baselined system requirements specification” i modellen side 13, mens der i
tabel afsnit 3.5.1.5 kun omtales en “system requirements specification”. forkortelsen
på “baselined system requirements specification” på side 13 og for “system require-
ments specification” i afsnit 3.5.1.5 er srs, men titlen brugt i afsnit 3.5.1.5 matcher
imidlertid et andet dokument nævnt på side 13. det er derfor ikke entydigt, hvilke do-
kumenter der kan forventes som artefakter, og om srs refererer til “system require-
ments specifications” eller “baselined requirements specifications”. da “baselined
system requirements specifications” er resultatet af fælles review fra både kunde og
projekt er det vigtigt, at det er “baselined system requirements specifications” der ef-
terfølgende benyttes.
i afsnit 3.5.2.4 omtales der “interface specifications”. disse fremgår ikke af modellen på
side 13. de omtales som værende en del af ssds, som indgår både på side 13 og i af-
snit 3..5.2.4. integrationsproblemer er en hyppigt forekommende fejlkilde, og da de
også er input til integrations test design, anbefales det normalt at have fokus på interfa-
ces i sin udviklingsmodel. hvilket modellen side 13 ikke giver udtryk af.
                                         - 66 -
beskrivelsen i afsnit 3.5.3.1 matcher ikke modellen på side 13. afnit 3.5.3.1 beskriver,
at der både burde være et kravsdokument og et designdokument mens side 13 kun om-
taler design dokumentet.
i afsnit 3.5.4.3 omtales to artefakter, som ikke fremgår af modellen side 13. “generic
unit test check list” og “ticked off checklists”
forventningerne til resultatet af hver fase er på denne måde ikke entydigt beskrevet,
hvilket er i modstrid med god praksis.
faserne i v-modellen
afsnit 3.3.1 beskriver en opdeling af systemet på baggrund af størrelsen af de enkelte
subsystemer, hvor størrelsen måles i estimerede timer til udviklingen. afsnittet bør være
en overordnet strategi for, hvordan systemet opdeles i subsystemer, hvordan subsyste-
mer opdeles i moduler, og hvordan modulerne opdeles i units. dermed bør afsnittet be-
skrive, hvordan det gøres og ikke, hvad resultatet af opdelingen er. afsnittet opfylder
ikke formålet.
der omtales to grænser for størrelse. dels, at et subsystem ikke må tage mere end 700-
1200 timer at udvikle. denne rettesnor anses for at være så vag qua det store spring, at
den reelt ikke hjælper læseren.
det beskrives, at en unit i et modul ikke må tage mere end 200-300 timer at udvikle. i
afsnit 3.4 beskrives en unit som f.eks. 1 c# klasse. en c#klasse tager typisk nogle dage
at udvikle incl. afprøvning. afsnit 3.4 og afsnit 3.3.1 punkt 2 må anses for at være i
konflikt med hinanden og kravet om at stoppe opdelingen, når arbejdet er under 300 ti-
mer må anses for at stoppe væsentligt tidligere, end der forudsættes i beskrivelsen i af-
snit 3.4.
system analyse 3.5.1.1
afsnittet giver indtryk af, at målet er at producere systemkravene. det vil være almin-
deligt at opfatte systemkravene som input til systemanalysen og ikke som et resultat af
systemanalysen. hvis ikke systemet allerede er beskrevet, er der ikke noget at analysere.
afsnittet kommer derfor til at fremstå som om, man har samlet to processkridt i et, hvor
det ene processkridt, “produktdefinitionen”, bør have kunden som ansvarlig og det ef-
terfølgende, selve systemanalysen, bør have projektet som ansvarlig. da der ikke er be-
skrevet input til fasen, er det dog ikke muligt at se, om dette er tilfældet.
factory acceptance testing 3.5.1.3
der skrives i sidste sætning i dette afsnit, at der vil være en test pr. krav (“these tests
will be one to one related to the system requirements document”), det er aldrig nok
med en test per krav, og en en-til-en relation er en dårlig teststrategi. der eksisterer ikke
et dokument med titlen “system requirements document”, og det er derfor uvist, hvil-
ket dokument der rent faktisk henvises til. testene bør som et minimum tage “baselined
system requirements specification (srs)” og “system design specification” som in-
put. det er almindeligt, at der i designdokumenter tages designbeslutninger, som har
status af krav til de underliggende subsystemer, og srs‟en kan derfor ikke stå alene
som input til testdesign.
performance test.
beskrivelse af omfang er vag og beskriver blot, hvad man ofte gør med vendinger som
                                         - 67 -
f.eks. “...often described...” og “...usually only...” afsnittet burde afgrænse ift. det kon-
krete projekt eller som minimum beskrive, hvor man kan finde den afgrænsning.
unit testing 3.5.4.2
sidste bullet henviser til afsnit 3.6.2 for information om, hvilke værktøjer det bliver
brugt til måling af code coverage ifm. unit test. afsnit 3.5.2 omhandler aktiviteten “co-
ding”. under samme aktivitet i tools i tabellen i sektion 3.6.2 er der nævnt en række
værktøjer, men det er dog fra listen svært at se hvad den tiltænkte anvendelse af de en-
kelte værktøjer er, og der mangler versionsnumre på værktøjerne. formålet med listen
bør være at gøre det muligt for læseren at forholde sig til, om projektet har en passende
tooling til at løfte de definerede opgaver. dette er ikke muligt ud fra 3.6.2. f.eks. kan
det udfra listen ikke ses, hvilke værktøjer der bruges til code coverage af hhv. c#, c++
eller vb6.
requirements management
i sektion 3.6.3.1 beskrives det, hvordan der traces fra srs til tilsvarende test dokumen-
ter, og hvordan der traces til ssrs. det beskrives ikke, hvordan der traces til modulde-
sign eller fra moduldesign til detailed design. dette er en mangel, da man uden denne
viden ikke vil være i stand til at udtale sig om, hvilke moduler der kan være påvirket af
en kravsændring.
dette er problematisk, da man ikke vil kunne udtale sig om, hvordan specifikke ændrin-
ger af systemkravene vil påvirke systemet. f.eks. kan man ikke uden den viden, der
ville ligge i trace udtale sig om, hvad det vil betyde at ændre fra mip blk 2 til mip blk
3. denne information kan være tilgængelig via anden kilde, men god skik vil fordre, at
man kan spore fra krav og minimum til moduldesign. der er ingen sporbarhed fra ssrs
til sstp, og det er derfor væsentligt besværliggjort at udtale sig om coverage af subsy-
stemtestene. der er hverken i project master plan eller qa master plan stillet krav til
denne coverage, og at man ikke tracer indikerer, at man ikke har haft denne måling. det
er ikke acceptabelt, hvis projektet ikke har kunnet udtale sig om dækningen af kravene i
de forskellige testfaser.
system test team
det nævnes, at systemet skal bygges ved hver bi-weekly release. det har ikke lykkes at
finde information om, hvorvidt hele systemet bygges oftere end dette byg af systemtest
teamet. systemet bør bygges ved hvert commit og i tilfælde af, at byggeprocessen tager
længere tid end, der gennemsnitligt er mellem to commits, bør det bygges så hyppigt
som muligt (såfremt der er committet ændringer)
sektion 4.2.2.7
sektionen er noget rodet. f.eks. nævnes fat og fiat flere gange, der bruges en for-
kortelse der ikke er defineret i dokumentet (funcxx), og det er ikke defineret, hvem
der er ansvarlig for fiatp. hvis det er hensigten, at delivery teamet ikke skal være det,
ville det have været på sin plads at skrive dette.
4.2.2.9 track teams
“creation of a cleaned up requirements base” beskrives som en af track teamenes op-
gaver. der er som en del af system level aktiviteterne beskrevet en proces for at sikre en
entydig kravsdokumentation, og at denne danner baggrund for opdeling af subsystemer,
der i sidste ende resulterer i allokering af krav til track teams. det er modstridende, at
track teams skal udføre opgaver, som er beskrevet som system level aktiviteter.
                                        - 68 -
bilag 2: noter med baggrundsinformation om centrale, sædvanlige begreber
v-modellen
v-modellen er en procesmodel der anvendes i forbindelse med software udviklings-
projekter. et projekt vil typisk vælge en procesmodel til at beskrive, hvilke faser udvik-
lingsforløbet skal igennem og vælge en udviklingsmetode. metoden kan påvirke hvor-
dan procesmodellen implementeres. se f.eks. scrum nedenfor.
der er forskellige udgaver af v-modellen afhængig af kilden.
i wikipedia udgaven fremstilles modellen på følgende vis:
det er hyppigt forekommende at betragte modellens faser i forhold til de artefakter, som
hver fase resulterer i og man vil typisk snakke om systemet som er det endelige produkt
bestående af et antal subsystemer, moduler og units.
subsystem
et subsystem er en del af det endelige system, som er klart adskilt fra det resterende sy-
stem. f.eks. kan der være et hardware subsystem og et software subsystem. et subsy-
stem kan være inddelt i flere subsystemer. disse subsystemer vil typisk være adskilt
enten som (web)services eller som minimum køre i separate processer.
inddelingen i subsystemer er en del af den overordnede systemarkitektur
et subsystem kan eksekveres uafhængigt af andre subsystem. det vil sige, at det kan ek-
sekveres og først ved en evt. afhængighed af et andet subsystem, vil det fejle eller helt
terminere.
modul
et subsystem inddeles i et eller flere moduler. i modsætning til subsystemer kan et mo-
dul ikke eksekveres uafhængigt af subsystemets andre moduler. et softwaremodul er
typisk en samling af kompilationsenheder, der afgrænser et lag i arkitekturen eller et
funktionsområde. inddelingen i moduler kan anses som arkitektur eller som detailed de-
sign. hvordan, det anskues, veksler fra projekt til projekt. denne vekslen afspejles også
i forskellige kilders gennemgang af v-modellen.
unit
et modul inddeles i en eller flere units. en unit er den mindste kompilerbare enhed, man
har i et software projekt. hvad, den mindst kompilerbare enhed er, er afhængig af det
valgte sprog og teknologi. i c# er den mindste kompilerbare enhed en klasse (“class”).
inddelingen, udvikling og verifikation af units anses som implementation.
                                               - 69 -
      verifikation
      højresiden af v-modellen beskæftigere sig med verifikation af det implementerede. der
      bør være en verifikationsfase for hver implementationsfase, hvor hver verifikationsfase
      har som formål at teste og verificere de artefakter, der er produktet af den tilsvarende
      implementationsfase på venstre side af v‟et.
      unit
      verifikationen af den mindste enhed, unit, betragtes oftest som en del af implementatio-
      nen. den hyppigst anvendte form for verifikation er unit test. en unit test er en test, der
      eksekveres automatisk. det er god skik at udviklerne selv eksekverer unit test lokalt på
      udviklingsmaskinerne, og at der er en byggeserver, der ved hver commit til versionssty-
      ringssystemet eksekverer alle unit tests. ideelt bør der ikke forekomme fejl ved eksekve-
      ring af unit test, men det vil forekomme og er i sig selv ikke en indikation af mangel-
      fuldt udført arbejde. hastigheden, hvormed byggefejl og unit test fejl på byggeserveren
      rettes, ses som en bedre indikation for udviklingsteamets modenhed. der findes flere
      mål for hvor god dækning af koden man har ifm. unit testing. alle målemetoder er ene
      og alene indikationer, og det eneste, de med sikkerhed kan fortælle, er, hvilken del af
      koden man ikke har dækning af. som minimum bør man have mål for stidækning også
      kaldet enten branch coverage eller condition-decision coverage.
      da målingerne ikke kan stå alene, og fordi de kan være meget misvisende3, må målin-
      gerne ikke stå alene. der er nødt til at være andre foranstaltninger, der sikrer, at man re-
      elt får testet koden. dette gøres typisk ved peer review af testene. dvs en anden udvikler
      gennemgår testene og sikrer, at de reelt tester funktionaliteten af den unit, der verifice-
      res, og at de testdata, der bruges er velvalgte, dvs man håndkører4 test casene for at se,
      om man har opnået den ønskede dækning, og om de valgte input svarer til grænsevær-
      dier for de identificerede ækvivalensklasser.
      ud over selve afprøvningen bør der som en del af verificeringen også udføres peer re-
      view af koden.
      dokumentationen af disse reviews er typisk uformel, enten som kode kommentarer eller
      via dedikerede værktøjer. formålet med peer review af koden skal som minimum være
      at sikre, at kode guidelines er overholdt, og at den implementerede funktionalitet er im-
      plementeret i overensstemmelse med kravene, funktionelle såvel som non-funktionelle,
      og at al input til eksponerede metoder valideres.
      for hver unit skal det sikres, at alle metoder (incl. properties på .net platformen) aldrig
      kan efterlade objektet i en tilstand, der strider mod forretningsregler og objektets invari-
      anter generelt. det er specielt vigtigt at være opmærksom på exception håndtering og
      sikre, at tilstandsændringer er atomare også i tilfælde af exceptions.
      modul
      modulverifikation sker ofte på en vis, der minder om unit verifikation. forskellen er
      blot, at det er hele moduler, der verificeres. der lægges derfor mere vægt på, om modu-
      lerne opfylder kravene til det detaljerede design og om interfacene er i overensstem-
      melse med kravene. der bør være stor fokus på fejlscenarier ifm. integrationen mellem
      units ,og at modulets interface kontrollerer input og begrænser input til valide værdier.
      modultests afvikles typisk automatisk ligesom unittests og er ofte skrevet med brug af
3
  f.eks. kan en kode enhed måles til at have fuld dækning uden overhovedet at være testet
4
  teoretisk afvikling, hvor man i hovedet følger det flow, programmet ville have haft, hvis
man eksekverede det
                                         - 70 -
de samme værktøjer. det bør være muligt at afvikle modultest på udviklingsmaskinerne,
og de bør ligesom unit tests afvikles på byggeserveren ifm. commits.
en del af modulverifikationen er review af de design dokumenter, der ligger til grund
for modulet. det detaljerede design, der ligger for modulet, bør være reviewet før mo-
dulimplementationen påbegyndes. hvis alle moduldesign er i et samlet dokument, re-
view‟es dokumentet som en helhed.
dette review er typisk formelt og dokumenteres i en review rapport. der bør som mini-
mum laves review af en udvikler, en arkitekt og en qa‟er.
subsystem
når modulerne er samlet til subsystemer, er der tale om en selvstændigt eksekverbar
enhed. verifikationen kan typisk inddeles i fire kategorier.
fælles for alle kategorierne er, at det er målet at sikre, at integrationen af modulerne er
korrekt, og at subsystemet opfylder kravene til funktionalitet, de non-funktionelle krav
og at subsystemet er implementeret i overensstemmelse med arkitekturen.
review
her review‟es dels, at system interfacet (api) er i overenstemmelse med arkitekturen, at
den komplette funktionalitet er implementeret, og at arkitekturen er i overensstemmelse
med systemkravene (funktionelle som non-funkitonelle). arkitektur og design review‟es
før implementering påbegyndes og foregår normalt som et formelt review med dertil
hørende review rapport.
test cases
test casenes formål er dels at lave standadiseret test af ny funktionalitet samt at fungere
som regressionstests for allerede eksisterende funktionalitet, således at det kan verifice-
res, at eksisterende funktionalitet ikke ødelægges, når ny funktionalitet tilføjes, eller når
anden eksisterende funktionalitet rettes.
der bør være fokus på interfaces, når der testes. både interfaces mellem subsystemets
moduler og subsystemets interface ud ad til (api‟et). som med de før nævnte tests læg-
ges der vægt på at få testet med grænseværdier fra de identificerede ækvivalensklasser.
test case afvikling kan ofte automatiseres. kan det lade sig gøre at automatisere afvik-
lingen af test cases, bør dette gøres, og afvikling bør så som minimum ske på byggeser-
veren ved hvert commit. hyppigheden kan dog afviges, såfremt det tager meget lang tid
at afvikle dem. i dette tilfælde bør de afvikles så ofte som muligt (dog maks en gang pr.
commit).
de test cases, der ikke kan automatiseres, afvikles som en del af hver release cycle. dvs.
udvikles der i sprints - som f.eks. ved scrum - afvikles test casene som minimum før
sprint demoen.
er der mange test cases, der skal afvikles manuelt, kan der udtages en udvalg til brug
for regressionstest.
test cases skal være reproducerbare
eksploratorisk test
i modsætning til test cases er der ikke et fast script at følge, når man udfører testene, der
angives derimod ofte et funktionsområde. det er så op til testere at prøve at finde så
mange fejl som muligt inden for dette funktionsområde. hvert område skal dækkes af
mindst et test charter.
                                         - 71 -
scriptede test, som test cases, kan ikke stå i stedet for eksploratorisk test. når der findes
fejl ved eksploratorisk testning, kan man med fordel skrive en test case, der kan frem-
bringe fejlen. denne test indgår fremover som en del af regressions test suiten.
verifikation af non funktionelle krav
som en del af verifikationen af et subsystem skal det verificeres, at subsystemet lever
op til de non-funktionelle krav. f.eks. performancekrav, reliability og platformskrav.
system
verifikationen af systemet sker ofte af to omgange. en hos leverandøren og en sammen
med kunden. ofte kaldet fabrikstest og accepttest.
fabrikstesten kan gennemføres på leverandørens hardware eller hardware stillet til rå-
dighed af kunden, mens accepttesten altid afvikles i det miljø, systemet skal bruges i.
(hvis systemet skal bruges i mange miljøer, er det typisk kunden, der er ansvarlig for at
stille et representativt system til rådighed).
test og reviews er i det store hele som for subsystem, blot er det dokumenter og funkti-
onalitet på systemniveau, der har fokus for verifikationen.
den i project master plan (bilag aay) beskrevne model kan siges at være inspireret af
w-modellen, som må anses for en bedre model end v-modellen. det er almindeligt at
omtale w-modellen som v-modellen. v-modellen beskæftiger sig primært med dyna-
misk testning (test hvor systemet eller dele af systemet eksekveres), men tager ikke
højde for statisk testning, såsom test af kravspecifikationen, system design eller det de-
taljerede design. i 1993 formaliserede paul herzlich en variation af v-modellen kaldet
w-modellen. denne model tager også højde for den statiske testning. ved statisk test-
ning forstås testning, der ikke kræver eksekvering af systemet, f..eks. review af kravs-
dokumenter. modellen beskrevet i project master plan beskriver også review af doku-
menterne dog på et mindre formelt niveau, end man typisk ville se i w-modellen.
udviklingsmetoder
i dette afsnit beskrives kort forskellige udviklingsmodeller. generelt sondres mellem to
former for udviklingsmodeller: iterative og vandfalds modeller.
vandfald
udviklingsmodellen, der typisk kaldes vandfaldsmodellen, gennemløber v-modellen
(eller anden valgt processmodel) en gang i projektets levetid.
produktiviteten følger ofte en s-kurve. der er en opstartsfase, hvor man bliver bekendt
med den funktionalitet, der skal implementeres, en fase hvor man fokuseret arbejder på
leverance af (næsten) færdig funktionalitet og slutteligt en fase, hvor der primært er tale
om færdiggørelse af funktionaliteterne og fejlrettelse.
iterativ
et iterativt projekt kan betragtes som en serie af ganske små vandfaldsprojekter, hvor
hver iteration/projekt har en varighed på typisk en til fire uger.
længerevarende iterative projekter har mange af de samme karakteristika som vand-
faldsprojekter. f.eks. følger de også en, omend ofte fladere, s-kurve. et af målene ved at
køre iterativt er netop at opnå denne fladere s-kurve for at have en bedre afrapportering
til styregruppe og projektledelse og for at nå i mål hurtigere pga. mindre såkaldt rework.
altså tid, der bliver brugt på at lave allerede funktionelle (men typisk fejlbehæftede)
dele af systemet om eller rette fejl i dem længe efter, at de er blevet implementeret.
                                              - 72 -
      i iterative projekter gennemløbes hele processen for systemet for hver iteration. dvs. en
      iteration afsluttes sædvanligvis med en systemverifikation.
      scrum
      en variation af den iterative model kaldet scrum har en lidt anden tilgang til hvordan
      fremgang måles. efter en given iteration siges et antal opgaver at være “done”. i
      scrum sammenhæng betyder dette, at de er klar til produktion, og at man ikke skal
      bruge mere tid på (dele af) funktionaliteten.
      systemverifikationen i slutningen af hver iteration sker gennem en demo.
      ved en demo i scrum-sammenhæng deltager product owneren aktivt forstået på den
      måde, at det er product owneren (og andre stakeholdere), der bruger systemet og gør
      sig fortrolige med de nye features. vægten er på de features, der er tilføjet i den seneste
      iteration.
      product owneren kan efter demoen forkaste iterationens resultat eller acceptere enkelte
      eller alle tilføjede features.
      de dele som product owneren accepterer efter demo‟en skal være i en sådan stand, at
      man er klar til release af et samlet system uden yderligere arbejde.
      product owneren i et scrum projekt er en rolle, som kunden enten selv besætter eller
      udpeger en repræsentant til at besætte. rollen kan ikke hensigtsmæssigt besættes af en
      person fra den implementerende del af scrum projektet.
      et vigtigt princip i scrum er, at man arbejder i såkaldte vertikale slices. dvs. man ud-
      arbejder en del af en feature fra det nederste lag, f.eks. databasen op til det øverste lag,
      typisk brugergrænsefladen som en samlet opgave. i modsætning til horisontale slices
      hvor man f.eks. først gør datalaget i applikationen færdigt for hele featuren, før man in-
      tegrerer det med de ovenliggende lag.
      et scrum hold består af 2 roler udover holdet:
     product owner (po).
     scrum master.
      hertil er der nogle grundlæggende dele af processen, som et scrum hold skal udføre for
      at kunne sige, at holdet benytter scrum:
     backlog - opgaverne som holdet skal arbejde på. product owner har prioriteret listen
      hele tiden til at passe pos behov.
     holdet har en fælles forståelse af ordet “done”, der fortæller resten af holdet tydeligt,
      hvad man har skabt i løbet af et sprint. så når man fortæller po at disse opgaver er
      done, så vides det, hvilken tilstand opgaven er i. det normale er, at koden er produkti-
      onsklar, hvis man ikke definerer andet.
     planning poker - holdet estimer kompleksitet/størrelsen af en opgave.
     restrospective - holdet fortæller, hvilke processer der kører godt for holdet, og hvad der
      skal forbedres.”
skønsmændene har den 4. december 2012 udarbejdet supplerende bemærkninger til skønser-
klæringen. heraf fremgår:
      ”supplerende bemærkninger til dokumentet "skønstema - svar på parternes spørgsmål"
      som fremsendt til parterne fredag d. 16. november 2012.
      dette dokument indeholder nogle supplerende og/eller korrigerende bemærkninger til
      nogle af de afgivne svar på parternes skønstema. bemærkningerne er affødt af spørgs-
      mål fremsat på et møde 28. november, hvor parterne over for skønsmændene kommen-
      terede de afgivne svar på skønstemaet.
                                        - 73 -
ad svaret på spørgsmål a), side 4, nederst.
indstævnte spørger, om det kan være en overfortolkning, at skønsmændene har konklu-
deret, at der skal være en testcase per krav ud fra formuleringen "one-to-one" i bilag
aay, afsnit 3.5.1.3.
det må medgives, at teksten i afsnit 3.5.1.3 ikke er krystalklar, og at alternative tolknin-
ger ikke kan udelukkes. det er dog på ingen måde klart, hvad det pågældende skriftsted
ellers skulle betyde, hvis ikke skønsmændenes oprindelige tolkning skulle være korrekt.
det fremgår af teksten, at fat'en består af et antal tests, og at disse er "one-to-one re-
lated" med srs. et par stikprøver i "system test procedure" viser en en-til-en relation
mellem krav i srd og test cases. dette understøtter (selv om det ikke kan siges at be-
vise) skønsmændenes formodning om hensigten med bilag aay, afsnit 3.5.1.3.
ad svaret på spørgsmål 0, (ad spørgsmål 1.7).
indstævnte spørger, hvorfor der refereres til oc i tredje paragraf af svaret på et generelt
spørgsmål, om hvornår mip-funktionalitet ideelt set bør indarbejdes under visse forud-
sætninger.
en hurtig kommentar er, at de to første paragraffer vil være dækkende som svar på
spørgsmål f). man kan således se bort fra tredje paragraf og blot anse denne paragraf
for at være skønsmændenes supplerende
refleksioner.
ad svaret på spørgsmål s) (ad spørgsmål 3.2)
indstævnte beder om referencer til bilag. hvor kommer de use cases og test cases, der
refereres i svaret fra?
use cases kommer fra bilag aaø. test case kommer fra bilag aa
ad svaret på spørgsmål w) (ad spørgsmål 15)
indstævnte minder skønsmændene om, at spørgsmål w) som eksplicit antaget forudsæt-
ning har, at "... oc testen i uge 51 var en operativ brugertest ...", og spørger om det gi-
ver anledning, til at svaret bør være anderledes.
for en god ordens skyld vil skønsmændene gerne præcisere, at det vil være normalt at
afprøve non- funktionelle krav under en operativ brugertest. hvis det er spørgsmålets
præmis, at oc anses for at være en operativ brugertest, så synes parterne i øvrigt at
være enige om dette, da der i anneks d til kontraktens bilag 3 er mange eksempler på,
at non-funktionelle krav er medtaget som shall til oc. f.eks er alle performance-, do-
kumentations- (med undtagelse af to), sikkerheds- og kvalitetskrav markeret som shall
til oc. dette er ikke usædvanligt for operative brugertests, at der testes krav fra disse
kategorier. omvendt vil man også kunne finde eksempler på non-funktionelle krav, som
må testes i anden sammenhæng, f.eks. under en dedikeret stress- eller volumentest.
ad svaret på spørgsmål aa) (ad spørgsmål 3,8)
indstævnte spørger til, om der - som angivet i svaret - overhovedet forudsættes en
modpart i de refererede scenarier.
                                              - 74 -
       scenarierne indeholder en række skridt, der tester replication-krav, og disse forudsætter
       tilstedeværelsen af en modpart. der er ikke i scenarierne stillet eksplicitte krav til eller
       forventning om en specifik (type) modpart.
       spørgsmål hit) (ad spørgsmål 3.4 3.8 3,9 3,11)
       indstævnte spørger, hvordan det fremgår af sagens materiale, at oc er placeret højt i
       v'et, hvilket indgår i formuleringen af svaret er baseret på.
       oc er en accepttest, og dokumenterne bilag aaz: project management plan, bilag
       aay: project master plan, og bilag aaå: master test plan fastlægger ved beskrivelser
       og diagrammer testens placering i v'et.”
forklaringer
til brug for højesteret er der afgivet supplerende forklaringer af finn hansen, ib bager,
bjarke heiberg-iürgensen, henrik juul krogh, klaus vester, lars abild, peter dan hansen,
ingvar krafft, björn haar, morten binderup, eva senderovitz, peter wimmerström, henning
hay sørensen og peter krag-sander. der er endvidere afgivet forklaring af hanne thode og
skønsmændene carsten gomard og torben falholt.
finn hansen har forklaret bl.a., at han deltog i forhandlinger mellem saab og fmt i foråret
2007. formålet med forhandlingerne var at få et system, der virkede. der havde været en test i
februar 2007, hvor systemet havde fejlet. systemet skulle være klart i foråret 2008, hvor der
skulle være nogle store øvelser, og i praksis skulle det være endeligt færdigt i forbindelse med
en nato beredskabsperiode i 2010.
for forsvaret var stabilitet altafgørende, fordi de havde fået et system, der hele tiden brød
sammen. fmt skulle se, om systemet virkede, eller om de skulle have et helt andet system.
det var afgørende for fmt, at der ikke blev lagt nye funktioner på. den grundlæggende plat-
form skulle virke. det afgørende var, at der var en stabil platform. de eksisterende ting skulle
virke. der blev aldrig testet en basiskerne. da basiskernen indtil version 6.7 ikke virkede,
valgte fmt, at der ikke skulle videreudvikles. der skulle være en fastpriskontrakt.
i efteråret 2007 var det afgørende for fmt at få et system, der virkede. man var nu kommet
så langt, så fmt ikke ønskede at komme ud af kontrakten. det var ikke et spørgsmål om
manglende ressourcer. der var på dette tidspunkt mange materielprojekter, hvor der var pro-
blemer. der var derfor stor politisk bevågenhed omkring projektet. fmt havde committed sig
på politisk niveau. fmt ville ikke hælde flere penge i projektet, førend det virkede.
                                               - 75 -
fmt havde ikke indgået nogen aftale med saab om, at mip og bdm ikke skulle testes sam-
men med daccis. mip og bdm skulle testes sammen. fmt havde heller ikke indgået no-
gen aftale med saab om, at oc testen skulle afbrydes undervejs, så mip og bdm ikke blev
testet sammen med daccis.
ib bager har forklaret bl.a., at han i forbindelse med kontraktforhandlingerne i foråret 2007
ingen rolle havde. han fulgte forhandlingerne på sidelinjen og var med i drøftelserne på hæ-
rens føringsstøtteskole. det var først efter sommerferien i august 2007, at han fandt ud, at der
var tale om en mip block 2 løsning. han havde aldrig set kontrakten, men han syntes, at det
var en god ide, fordi han i opløbet til kontraktforhandlingerne havde anbefalet en så konser-
vativ tilgang som muligt til de forpligtelser, som saab påtog sig, således at saab kunne være
på sikker grund. han havde året før set, at mip block 2 fungerede ved testen i den tyske by
greding, så han fandt, at det var en fornuftig løsning at holde sig til. fordelen ved mip block
2 var, at man så havde noget, der var kendt. mange andre lande var ikke kommet så langt med
implementeringen af mip block 3, som man havde håbet, og derfor var der ikke nogen større
skade sket ved, at det blev en mip block 2 løsning.
den 7. september 2007 deltog han i et møde i styregruppen. han var ikke medlem af styre-
gruppen, men han var rådgiver for hok. det fremgår af referatet herfra, at levering af en mip
block 2 løsning blev drøftet. der var flere forhold, der gjorde sig gældende. hæren ville gerne
bruge en mip block 2 løsning, hvis det var muligt, og derfor havde man spurgt saab, om der
kunne leveres en mip block 2 løsning, fordi det var det kontraktuelle grundlag. han fandt
aldrig rigtigt ud af, om saab kunne levere en mip block 2 løsning. dette er også reflekteret i
referatet, hvoraf det fremgår, at saab siger: ”if possible”. han fik dog en fornemmelse af, at
saab af den ene eller anden årsag ikke kunne levere en mip block 2 løsning. men han ved det
ikke, og derfor gik de på mødet ind i drøftelser, om hvad man så skulle gøre, f.eks. om man
skulle forfølge en mip block 3 løsning. diskussionen om en mip block 3 løsning endte med,
at man enedes om, at styregruppen skulle anbefale saab at fremsende en anmodning om en
ændring til kontrakten, også kaldet en ccp, således at chefen for fmt kunne træffe en be-
slutning på dette område. styregruppen havde ikke kompetence til at træffe en så vidtgående
beslutning som en kontraktændring. det blev anbefalet saab så hurtigt som muligt at frem-
sende en ændringsanmodning til fmt. derfor står der også i refereratet, at en mip block 3
har ”priority”. det var ikke hans opfattelse, at det for fmt var afgørende, om man nåede en
                                               - 76 -
mip block 2 løsning, hvis man fik en mip block 3 løsning (decision 3). det var afgørende
for forsvaret, at man fik en mip løsning.
styregruppen anbefalede, at saab, hvis det var muligt, skulle levere en mip block 2 løsning i
midten af februar 2008. dette var under forudsætning af, at saab arbejdede videre med en
mip block 3 løsning. den 3. oktober 2007 blev han bekendt med, at saab fremsatte et over-
slag over udgifterne ved et skifte til mip block 3. han stiftede kendskab hertil via en e-mail,
der var sendt til hærens føringsstøtteskole herom. e-mailen blev sendt cc til ham. han blev
endvidere orienteret af sin sagsbehandler. e-mailen blev modtaget efter mødet i styregruppen.
han husker, at overslaget var i størrelsesorden 20.000 timer, og at hans reaktion herpå var, at
hvis det var ham, der skulle have truffet beslutningen, så ville han have sagt nej tak. dette
skyldtes, at det tal, han havde i sit hoved fra foråret 2007, var et tal mellem 6-8 mio. kr. for-
svaret havde på dette tidspunkt ikke noget ønske om at komme ud af kontrakten med saab.
tværtimod. det var forsvarets ønske at få et kommando/kontrolsystem, der kunne gøre livet
lettere på slagmarken. man havde gjort alt, hvad man kunne i foråret 2007 for at skabe
grundlag for dette, og derfor havde hæren et stort ønske om at få sit kommando/kontrolsystem
og troede på, at man kunne få det.
daccis var designet til, at man fra divisionsniveau kunne kommunikere uden begrænsninger
med divisionens dispositionsenheder frem og tilbage samt med udenlandske enheder, som
måtte blive underlagt divisionen. det gælder også enheder, der måtte blive sammensat til lej-
ligheden under operationen. der var også et ønske om at bruge systemet i afghanistan for
dermed at kunne interoperere uden begrænsninger med den engelske foresatte myndighed
forudsat, at denne også havde en mip løsning.
bjarke heiberg-iürgensen har forklaret bl.a., at forsvaret havde holdt et møde med peter
wimmerström den 30. oktober 2007, som han dog ikke selv deltog i. det var fmt‟s og hans
opfattelse, at de på mødet havde gjort det meget klart, at der ikke var mulighed for ændringer.
kontrakten skulle efterleves præcist, som den var indgået den 29. juni 2007. de havde den
opfattelse, at kontrakten i sig selv med en tilbagebetalingsklausul på 170 mio. kr. kunne mo-
tivere saab til at opfylde kontrakten præcist. da han den 30. november 2007 sent om efter-
middagen lige inden weekenden blev orienteret af klaus nordendorff om et brev fra saab,
blev han meget chokeret/overrasket. saabs topchef, peter wimmerström, havde på mødet den
30. oktober 2007 på ingen måde indikeret, at saab var i problemer. det var hans opfattelse, at
                                               - 77 -
fmt, dvs. både hans kontraktsektion og claus nordendorff som styregruppeformand, var
nødt til straks at tale med saab, og derfor tog han initiativ til, at der skulle holdes et møde
med saab, og claus nordendorff arrangerede et møde den 4. december 2007.
på mødet den 4. december 2007 opfattede han det, som om det var ham, der sad for borden-
den fra forsvarets side. det gjorde han, fordi det – som det havde været saab bekendt i mange
år – er således i forsvaret, at der er nogen, der gennemfører projekter inden for mål og ram-
mer, og andre, der tager stilling til ændringer. den styregruppe, claus nordendorff repræsen-
terede, var den gruppe, der skulle gennemføre projektet i henhold til kontrakten. mens alle
ændringer i en kontrakt skulle forelægges det, han kalder fmt‟s basisorganisation, dels pro-
jektorganisationen, dels fmt‟s kontraktsektion, og de refererer ad hver sin vej til admiralen. i
hans verden tilkendegav saab allerede med brevet af 30. november, at man ikke kunne leve
op til milepæl oc (oc-leverancen) før 6 måneder senere. det gav to muligheder. enten
kunne fmt ensidigt hæve kontrakten på forsinkelsen, eller man kunne lave et kontrakttillæg.
det indebar, at fmt havde brug for en retvisende beskrivelse fra saab af, hvad der foregik,
eller af, hvad der var foregået, og en retvisende beskrivelse af, hvad der fremadrettet var reali-
stisk muligt. men han var også helt bevidst om, at saab i mødet den 4. december 2007 ledte
efter et hvilket som helst halmstrå, de kunne bruge til at sige, at fmt havde lovet dem en
forlængelse. på mødet den 4. december 2007 blev der skrevet et udkast til et brev. saab prø-
vede hele tiden at få et løfte ud af ham og halve løfter ud af claus nordendorff. derfor følte
han ikke, at det var nok, at han i forbindelse med åbningen af mødet havde sagt, at de ikke
skulle tage stilling til sagen. de skulle udelukkende have sagen belyst. han havde lagt et pres
på saab. dette var han helt klar over. saab havde skrevet, at de var 6 måneder forsinket, og
for fmt indebar det, at man havde en klar hævebeføjelse på forsinkelse, og det følte han et
behov for at gentage på mødet. saab forsøgte at få fmt til at love dem noget. saab spurgte,
om de kunne regne med at få en forlængelse af fristen for oc med 6 måneder, hvis de skrev
sådan eller sådan. hertil svarede fmt klart nej. fmt svarede tre gange klart nej. der blev ik-
ke underskrevet noget brev på mødet, men alene lavet et udkast hertil. baggrunden herfor var,
at saab på mødet var repræsenteret ved medarbejdere fra underleverandøren, saab danmark.
fmt havde indgået kontrakten med saab ab, og det var også saab ab, som fmt havde ind-
kaldt til mødet. fmt ville have, at afsenderen af brevet skulle være saab ab. derfor valgte
saab danmark at forelægge brevet for peter wimmerström. sætningen i sø- og handelsret-
tens dom om, at de talte om, at steffen jakobsen før kontraktsindgåelsen havde tilkendegivet,
at fmt var villig til at se på forskellige forhold, går ikke på tiden efter kontraktindgåelsen.
                                               - 78 -
han afviste dette på mødet, og det blev ikke til diskussion. saab accepterede dette synspunkt
ved at annullere skrivelsen af 30. november med skrivelsen af 4. december. saab var ikke ble-
vet lovet noget. han sluttede mødet med igen at markere, at saab måtte finde ud af, hvad de
ville. han lagde hermed op til, at saab måtte finde ud af, om saab ville sende det brev, der
forelå udkast til, eller om saab ikke kunne stå inde for det. på mødet den 4. december gav han
på ingen måde saab løfter om, at fristen for oc ville blive udskudt, hvis saab sendte det brev,
der forelå udkast til. der var heller ikke andre repræsentanter fra forsvaret, der gav sådanne
løfter. der var ingen løfter om imødekommenhed. han ville med udkastet til brevet have klar
besked, så han kunne indstille, hvad fmt skulle gøre fremadrettet på et så godt grundlag som
muligt, og det var hans opfattelse, at det, der stod i brevet, også var et udtryk for den reelle
opfattelse, som alle saabs repræsentanter havde af situationen.
materielkommandoen havde tidligere indgået aftaler om leverancer, som var safety critical,
f.eks. dehawk missilsystem. han husker ikke, om det fremgik af dehawk kontrakten, at det
skulle være safety critical, eller om dette fremgik af andre tidligere kontrakter, hvor der havde
været tale om safety critical systemer. han tror, at det fremgår af almindelige industristandar-
der, som det forventes, at leverandørerne kender. han mener, at når det fremgår af kontrakten,
at der er tale om et operativt system, som skal anvendes i krig, ligger det heri, at systemet skal
være safety critical.
henrik juul krogh har forklaret bl.a., at det var vanskeligt at se, om der egentlig var nogen
forhandlinger i foråret 2007 med saab efter fiat. der var en form for limbo i og med, at
daccis var dumpet ved den afsluttende test. de kørte videre for at holde momentum. de
vidste ikke, om projektet skulle fortsætte eller ej. det vil sige, at der blev lagt nogle følere ud,
men ikke på hans niveau. han var projektleder. hans opgave var at sørge for, at forsvaret
stillede mandskab og materiel til rådighed, hvis saab manglede noget.
da forhandlingerne gik i gang, sad han i en projektgruppe. hovedformålet med arbejdet i
projektgruppen var, at hvis der var en kontrakt, skulle der ske en genlevering i forhold til det,
som systemet skulle kunne, som det ikke kunne i slutningen af februar 2007, hvor systemet
var dumpet. før der blev talt om at ændre i kontrakten, var det mip block 2, der skulle leve-
res.
                                               - 79 -
på projektmøde i april 2007 foreslog p. d. hansen, der havde styr på det teknologiske, om det
ikke var lettere for saab at levere en mip block 3 løsning. der var tale om en venlighed fra
forsvarets side. mip block 3 var en mere enkel løsning. mødet blev umiddelbart afbrudt, og
man gik hver til sit. saab ville tænke over det. han mener, at saab tog det med sig hjem. det
var hans opfattelse, at saab var meget positive. saab meldte tilbage, at der var en interesse for
at levere en mip block 3 løsning. saab skulle vise en systemarkitektur, og der skulle foreta-
ges en uofficiel briefing. hvis man kom frem til, at der skulle leveres en mip block 3 løsning,
ville det efter saabs opfattelse kræve en kontraktændring. i øvrigt havde projektgruppen ikke
kompetence til at træffe beslutning. den skulle træffes på styregruppeniveau.
på styregruppemødet den 16. maj 2007 blev der givet en arkitekturbriefing. på styregruppe-
mødet blev mip block 2 ikke fravalgt. til oc skulle mip block 2 præsenteres, og til den
endelige test, fc, skulle mip block 3 præsenteres.
da realitetskontraktforhandlingerne var begyndt i maj/juni 2007, sagde man, at man godt
kunne gå efter en mip block 3 løsning. fra forsvarets side var der tre meget vigtige forudsæt-
ninger herfor. de tre forudsætninger var følgende: for det første måtte det ikke øge projekt-
risikoen at gå fra mip block 2 til mip block 3, for det andet skulle det være økonomisk neu-
tralt, og for det tredje måtte det ikke forsinke projektet ud over det, der var aftalt i foråret i
letter of intent. dette accepterede saab den 23. maj 2007, og dette fremgår direkte af en e-
mail, der blev sendt internt i forsvaret.
i begyndelsen af juni 2007 var han, lars abild, p. d. hansen og claus nordendorff til et
møde hos saab i titangade. saab var repræsenteret ved helena melander, der var deres pro-
jektleder, david wadell samt hans olaf hougaard. han er ikke sikker på, om henning hay
sørensen også var til stede. det var helena melander og david wadell, der førte ordet. he-
lena melander og david wadell var kaldt ind for at forstærke saab og hele projektet. bilagene
blev gennemgået, og uden varsel blev det sagt, at man ikke kunne gå over til en mip block 3
løsning, fordi det ville øge projektrisikoen. det var aftalt, at der skulle være stabile og sikkert
virkende funktioner. man skulle hele tiden have muligheden for at gå tilbage til sit udgangs-
punkt. det var helena melander støttet af david wadell, der sagde, at man ikke kunne gå til
en mip block 3 løsning, og at man derfor ville fastholde mip block 2 løsningen. baggrunden
for, at det skulle være en mip block 2 løsning, var, at det var et skiveopdelt forløb, hvor man
hele tiden skulle være sikker på, at det virkede. det blev tydeligt sagt fra saabs side, at ved ic
                                               - 80 -
og oc skulle det være en mip block 2 løsning, og ved fc skulle det være en mip block 3
løsning under forudsætning af, at man ved fc havde forhandlet en form for vedligeholdel-
ses/tillægskontrakt på plads. saab ville ikke have, at der skulle udarbejdes en tillægskontrakt
til mip block 3. i tilfælde af, at der ikke blev udarbejdet en tillægskontrakt, skulle det være
mip block 2 ved fc.
forsvaret havde ikke så mange overvejelser efter mødet i juni 2007. hovedformålet var at få
en genlevering, som var en mip block 2. det kunne de leve med, fordi det ville indikere, at
forsvaret ville få et sikkert og stabilt system, som virkede. de kunne sagtens bruge et system,
der var baseret på block 2, fordi de havde planer om at bruge det i foråret 2008 til ce og
cwid. til disse øvelser regnede forsvaret med, at de kunne komme med daccis med mip
block 2.
det var uheldigt, at man havde en bestemt datamodel ved oc (mip block 2), og et halvt år
senere ved fc en anden datamodel (mip block 3) end den, der blev testet og godkendt ved
oc. det ville øge projektrisikoen ganske betydeligt. det, der var vigtigt for ham, var hensynet
til forsvarets brugere. det var vigtigt for ham, at der blev leveret et system, der virkede, og
som var stabilt.
på styregruppemøde den 7. september 2007 blev det sagt, at øvelserne i foråret var med mip
block 2.”decision 3: maintain the schedule and the mip bl3 is priority 1” betød, at tidspla-
nen skulle holdes. det er således, at interoperabilitet har 1. prioritet i forhold til specifikke
nationale krav.
han husker mødet med saab den 1. oktober 2007, hvor de lige netop drøftede en tillægskon-
trakt/vedligeholdelseskontrakt vedrørende muligheden for at gå fra en mip block 2 løsning til
en mip block 3 løsning rent kontraktuelt. der blev oplyst et prisoverslag fra saabs side, der
gik ud på, at saab kunne lave en tillægskontrakt, men det ville koste 20-21 millioner kr. alle
havde indtil da antaget, at man ved en billig og simpel tillægskontrakt kunne få en block 3
løsning. det ville få ødelæggende virkning for en block 3 løsning, således at der ville blive
tale om en block 2 løsning ved fc.
forsvaret skulle ikke bruge mip block 2 ved cwid og ce i foråret 2007. selvfølgelig skulle
mip block 2 anvendes operationelt på et senere tidspunkt.
                                              - 81 -
indtil den 2. oktober 2007 var man gået ud fra, at der skulle udvikles en mip block 2 løsning.
i perioden indtil den 2. oktober 2007 havde han ikke viden om, at der blev arbejdet på en
block 3 løsning. det ville være gisninger og spekulationer. han havde ikke indsigt i, om saab
arbejdede mod en block 3 løsning, men han kunne have en ubekræftet formodning herom.
han deltog i projektledermødet, der blev holdt den 23. august 2007. saab sagde, at man ville
ændre til en mip block 3 løsning, men han ved ikke, om dette er ensbetydende med, at de var
ved at udvikle en block 3 løsning.
klaus vester har forklaret bl.a., at saab havde meldt ind, at de var klar til at teste i uge 51.
det var saab, der havde ansvaret for afvikling af testen. fmt ville deltage loyalt ved testen.
fmt lagde op til, at det var saab, der skulle tage den endelige beslutning om, hvorvidt testen
skulle stoppe. han ville ikke have, at det skulle være op til ham, om testen skulle stoppes.
saab skulle træffe denne beslutning, hvis saab mente, at man havde opnået det resultat, som
man gerne ville have. mailen af 19. december 2007 fra henning hay sørensen er ikke udtryk
for en aftale med fmt om ikke at gennemføre testen af mip og bdm. tværtimod fremgik
det af den testplan, som de havde modtaget om fredagen, at saab ville demonstrere, hvor langt
de var nået. det var derfor nyt, at saab alligevel ikke ville demonstrere dette.
lars abild har forklaret bl.a., at han og p.d. hansen på et formøde kom med forslag om, at
man skulle gå over til block 3 alene for at forenkle systemet. saab lyttede og tog det som et
godt forslag. de ville gå hjem og overveje det. saab kom med en tilbagemelding i foråret
2007, da man i fællesskab besluttede, at det var den løsning, som man ville gå efter. saab
skulle ved en mip block 3 løsning levere den samme mip-kompatibilitet som ved en mip
block 2 løsning. det var helt klart en begrænsning af saabs leveringsforpligtelse. forsvaret
kunne ikke forvente at få leveret samtlige mip block 3 funktionaliteter, men alene de samme,
som skulle leveres ved en mip block 2 løsning. mip block 3 ville ikke blive taget i brug i
forbindelse med ce og cwid, men først på et senere tidspunkt.
forhandlingerne, der fandt sted i juni 2007, udgjorde et intenst forløb. de fik stedse præsente-
ret nye kontraktudkast. forslaget om, at det skulle være en block 2 kontrakt, blev præsenteret
på et møde, hvor helena melander, david wadell, henrik juul krogh og han selv deltog. i
kontraktudkastet stod der nu block 2. de spurgte, om det ikke var en fejl. de var noget forun-
                                               - 82 -
dret over det. david wadell meddelte, at det ikke var en fejl. saab ønskede at gå til oc på et
kendt grundlag.
det var hans opfattelse, at der skulle laves en tillægskontrakt, og det var hans opfattelse, at
der ville blive opnået enighed om en tillægskontrakt. det var det, man ville fra brugerniveau,
leverandørniveau og fra fmt‟s side. ved forhandlingerne i foråret havde man også indlagt
den tid, som man skulle bruge i tidsplanen. den pris, der på det tidspunkt blev nævnt, var en
pris, som fmt forventede, man kunne klare over driften. tallet, der blev nævnt, var et sted
mellem 5-8 millioner kr. det var en repræsentant fra fmt, der på mødet nævnte, at man
kunne klare udgiften over driften. han ved ikke hvad, repræsentanten mente med dette.
da kontrakten af 29. juni 2007 blev indgået, var der meget fokus på, at det, som stod i kon-
trakten, var gældende. hvis der ikke blev indgået en tillægskontrakt, var det derfor en block 2
løsning, der ville blive leveret. som bruger ønskede han en mip block 3 løsning, men det var
det, der fremgik af kontrakten, som var gældende.
han husker, at saab på mødet den 2. oktober 2007 præsenterede en powerpoint, hvor der stod,
at saab ville bruge mellem 20-21.000 timer på en mip block 3 løsning. de kunne hurtigt
regne ud, at det ville koste mere end 20 millioner kr.
han foreslog i forbindelse med korrespondancen den 19. december 2007 om testning af mip
block 2, at testen skulle svare til den test, der fremgår af kravspecifikationerne, jf. annex c til
kontraktens bilag 3. så vidt han husker, har han ikke været i kontakt med saab forud for af-
lysningen af testen af mip og bdm. han blev derfor overrasket, da han modtog e-mailen
herom.
peter dan hansen har forklaret bl.a., at han i perioden 2002-2006 gennemførte en ingeniørud-
dannelse. efter afslutningen af uddannelsen vendte han i foråret 2006 tilbage til forsvarets
tjeneste, hvor han straks blev tilknyttet daccis-projektet. projektet havde på dette tidspunkt
været i gang i et stykke tid.
i april 2006 deltog han som observatør for hok i en test for daccis i den tyske by greding,
hvor forskellige nationer deltog. han vidste på dette tidspunkt meget lidt om mip. testen
foregik i et ganske almindeligt klasserum. hver nation havde opstillet en bærbar pc, hvorpå
                                               - 83 -
nationens kommando/kontrolsystem kørte. den bærbare pc var tilknyttet et almindeligt lokalt
netværk. testen bestod af en suite, hvor der blev gennemført test af system level 1, 2 og 3,
hvor fokus var på system level test 3. resultatet af testen i greding fremgår af kontraktens
bilag 3 – annex c. der var opstillet forskellige testkriterier. var et felt markeret med grønt,
betød det, at daccis havde bestået casen. hvis alle eller langt overvejende alle testkriterier
blev imødekommet, bestod daccis test casen. et felt markeret med gult betød, at daccis
delvist havde bestået casen. et rødt felt betød, at test casen ikke var bestået. dette var
tilfældet, hvis testkriterierne ikke eller kun i meget ringe omfang var imødekommet. de felter
i oversigten, der var markeret med sort og med påskriften ni, betød, at funktionaliteten ikke
var implementeret i den enkelte nations system, hvorfor det ikke gav mening at afholde testen.
i foråret/forsommeren 2007 deltog han i et forhandlingsforløb med saab. han var rådgiver for
projektleder henrik juul krogh, og samtidig repræsenterede han hok. som repræsentant for
hok skulle han naturligvis melde tilbage til sin chef om, hvordan forhandlingerne skred
frem. han deltog i møder med repræsentanter fra saab. det var hans opfattelse ved forhand-
lingernes opstart, at den generelle forventning var, at saab skulle levere et mip block 3 sy-
stem. senere meldte saab ud, at saab ville levere et mip block 2 system, hvilket var til for-
svarets store overraskelse. baggrunden for, at saab gik efter en mip block 2 løsning, var, at
der var gennemført resultater, på baggrund af hvilke saab mente, at det var mindre risikofyldt
at levere et mip block 2 system. man opfattede det ud fra projektrisikovurdering som en
mere sikker løsning. derudover var udgivelsen af mip block 3 specifikationerne blevet for-
sinket. inden forsommeren 2007 havde forsvaret haft en forventning om, at mip block 3 ville
være baselined, og at forsvaret ville være i stand til at møde sine koalitionspartnere i såvel
afghanistan som irak i et mip block 3 miljø. det viste sig i foråret 2007, at mip block 3 ikke
var baselined. mip block 3 var på mange områder færdiglavet, men ikke endeligt godkendt,
baselined. endnu værre var det, at de danske koalitionspartnere endnu ikke var klar med deres
mip block 3 system. hvis saab i 2007 havde leveret et mip block 3 system, ville danmark i
en international operation have stået i en situation, hvor det ikke havde været muligt at kom-
munikere med andre nationer. så ud fra denne betragtning valgte forsvaret at acceptere saabs
udmelding.
fra hok var der en klar forventning om, at våbensystemet skulle give en værditilvækst i de
operationer, som soldaterne deltog i. på daværende tidspunkt og også i dag er de absolutte
                                              - 84 -
primære aktiviteter for forsvarets internationale operationer i rammen af en koalition af natio-
ner.
det er korrekt, at daccis kunne anvendes på divisions- og brigade niveau. der er mellem
10.000-20.000 mand i en fuldt oprettet division, men som han husker det, var selve staben for
danske divisioner en koordinerende myndighed, der arbejdede på vegne af hok. det vil sige,
at danmark ikke ville være i stand til at stille en fuld division. daccis skulle ikke kun an-
vendes på divisionsniveau. det skulle også anvendes på brigadeniveau. en brigade er på papi-
ret en enhed på mellem 2.000 og 4.000 mand. hok havde en forventning om, at ledelsen af
en brigade, staben, også skulle udrustes med daccis. danmark har på intet tidspunkt ud-
sendt en samlet styrke på hverken brigade- eller divisionsniveau. men allerede dengang ud-
sendte danmark det, der kaldes kampgrupper. en sådan kampgruppe er på bataljonstørrelse
og består af ca. 400 mand. det, der kendetegner en kampgruppe, er, at den skal operere selv-
stændigt på samme måde, som en brigade skal det. derfor har ledelsen af kampgruppen
samme størrelse som en brigadestab. af den grund var det hok‟s forventning, at en sådan
kampgruppeledelse skulle udstyres med daccis.
i 2007 blev der i uge 51 gennemført en test, hvor han var til stede, men han deltog ikke aktivt
i testen. hans funktion var at stå for klargørelsen af hrn nms, hvilket tidligere er omtalt
som sitaware. hrn nms var også et c2 system, der kunne tale via mip block 2. han havde
ingen drøftelser med saab omkring afbrydelsen af testen i uge 51.
han har ikke har været med til at forhandle hensigtserklæringen. det var hans chef, flemming
agerskov, der deltog i møderne vedrørende hensigtserklæringen. han drøftede punkt 2.3
”vilkår for mip block 2” test med flemming agerskov.
han gennemgik sammen med flemming agerskov oversigten over resultaterne fra testen i
greding, fordi oversigten uden nærmere forklaring ikke umiddelbart giver mening. flemming
agerskov spurgte ind til de ikke-grønne felter i oversigten. flemming agerskov ønskede at få
afklaret, hvad det var, systemet ikke kunne. han forklarede på baggrund af oversigten, hvad
det var, systemet ikke formåede. på baggrund af hans vejledning, vurderede flemming ager-
skov, at der ud fra en operativ vurdering skulle lægges større vægt på håndtering af symboler.
funktionerne ”task organisation”, ”compose (single) plan” og ”enemy order of battle”
skulle understøttes. de fire forhold dækker kun en del af de ikke-grønne felter. vejledningen
                                               - 85 -
om indholdet af oversigten var, så vidt han husker, hans eneste rolle i forbindelse med hen-
sigtserklæringen. så vidt han erindrer, rådgav han flemming agerskov, inden hensigtserklæ-
ringen blev udfærdiget.
det var hans klare opfattelse, at saabs mip analyse var alt for overfladisk. et eksempel på
dette er, når der under afsnit 4.2 ” expected behavior” udelukkende er angivet procentsatser
for understøttelsen. fra operativ side har man brug for at vide, præcis hvilke symboler der
ikke understøttes, idet man skal være i stand til at advare sine koalitionspartnere om, hvilke
symboler de ikke må udveksle med en. hvis f.eks. en koalitionspartner ser en bestemt fjen-
detype og vil advare den danske styrke om fjenden, er det yderst alvorligt, hvis fjenden rap-
porteres med et symbol, der ikke understøttes af daccis. dette er blot et eksempel på, hvor-
for han fandt oplægget som værende alt for overfladisk.
der blev ikke fundet en teknisk løsning på workshoppen. det er ukorrekt gengivet i hans for-
klaring for sø- og handelsretten. det, de blev enige om på workshoppen, var en metode til,
hvorledes man kunne etablere den savnede sporbarhed mellem kravspecifikationerne og
daccis og mip specifikationerne og testresultaterne. på workshoppen blev der opnået enig-
hed om en fremgangsmåde, der var acceptabel for begge parter.
punktet ”schedule”, der er en del af dokumentet ”mip requirements definition in daccis”,
blev ikke blev drøftet på selve workshoppen. der blev orienteret om dette punkt ved et efter-
følgende møde mellem fmt og saab. orienteringen skete få dage efter workshoppen, mindre
end en uge efter. han anså oplysningen om, at ”this change of documentation cannot be in
place for oc week 24” for yderst alvorlig, fordi saab i januar/februar 2008 meddelte, at der
kun var få tekniske hindringer for en aflevering af daccis. udmeldingen afslørede for ham
at se, at saab intet overblik havde over det grundlæggende kravkompleks, særligt for så vidt
angår mip og daccis. det betød, at hvis saab i februar 2008 ikke havde overblik over kra-
vene, så var saab i hans øjne milevidt fra at kunne aflevere et stabilt velfungerende system.
med ”manglende kendskab til det grundlæggende kravkompleks” mener han, at saab ikke
havde et overblik over kravspecifikationerne. det er for forsvaret i en operativ sammenhæng
vigtigt at vide, hvilke informationer der sendes videre til koalitionspartnerne, og hvilke infor-
mationer koalitionspartnerne ikke kan se. hvis f.eks. den operative bruger udfylder 20 felter,
men det kun er 10 felter, der kan ses af koalitionspartneren, så er det utroligt vigtigt for for-
svaret at forholde sig til dette. den eneste, der kan give disse oplysninger, er leverandøren.
                                                - 86 -
den metode, som de fandt frem til på workshoppen, var en metode, hvorpå leverandøren
kunne besvare ovenstående på en struktureret måde, og hvor de efterfølgende kunne teste det.
han har godkendt referatet, men punktet ”scedule” havde han ikke set, og det kom som en
overraskelse for ham.
hanne thode har forklaret bl.a., at hun var sagsbehandler for bjarke heiberg-iürgensen, og at
hun var ansat i kontraktafdelingen. baggrunden for det møde, der fandt sted den 4. december
2007, var, at fmt den 30. november 2007 havde modtoget et brev fra saab, hvor der efter
forsvarets opfattelse kunne være tale om en misligholdelse fra saabs side. for at få helt styr
på, hvad det var, saab mente med brevet, blev der afholdt et møde. indholdet af brevet blev
drøftet på mødet. det var ikke de deltagendes opgave at træffe den endelige beslutning om,
hvad der skulle ske i det videre forløb. det var op til forsvarets øverste ledelse. for at
tilvejebringe et klart grundlag for forsvarets øverste ledelse blev mødet afholdt. på mødet blev
saab ikke stillet en kontraktændring i udsigt, hvis saab påtog sig ansvaret for situationen. hun
udarbejdede et udkast til et kontrakttillæg. det blev udarbejdet efter mødet. hun husker ikke
præcist, hvornår hun udarbejdede udkastet, men hun kan ud fra dokumentoplysningerne kon-
statere, at dokumentet er oprettet den 4. december 2007 kl. 16.24. baggrunden for, at kon-
traktudkastet blev udarbejdet, var, at fmt ikke anede hvilken vej, det ville gå. enten kunne
kontrakten blive hævet, eller samarbejdet ville fortsætte. det hele gik så hurtigt. kontraktud-
kastet blev udarbejdet til brug for det tilfælde, at det af forsvarets øverste ledelse blev beslut-
tet, at kontrakten skulle fortsætte.
ingvar krafft har forklaret bl.a., at han deltog i forhandlingerne om letter of intent i januar og
februar 2008, og at han ledte forhandlingerne fra saabs side. årsagen til, at der stod noget om
”test” i letter of intent punkt 2.3, var, at man ved at teste skulle se, hvilken grad af mip
compliance man havde i forhold til standarderne. fmt havde på dette tidspunkt indset, at de
havde meget lav compliance, og de ville have mere compliance. fmt ønskede mere
compliance end den, man havde aftalt i daccis 6.7 kontrakten. man ønskede et system, der
var operationelt lige så godt, som det bedste system, man kunne se. pointen i punkt 2.3 var, at
der skulle laves en analyse af graden af compliance og daccis systemet. saab leverede
analysen den 11. januar 2008. analysen omtalte, hvilken grad af compliance systemet havde.
den samlede anbefaling i analysen var, at man skulle gennemføre ændringerne i et separat
spor, fordi der var tale om store ændringer. saab ville bibeholde stabiliteten i systemet. fmt
svarede ikke på analysen af 11. januar 2008. der var en frist til den 16. januar 2008. det ene-
                                               - 87 -
ste svar, der blev givet, var, at dette ikke var, hvad man havde forventet. saab konstaterede, at
de var uenige, og det eskalerede til højere ledelsesniveau. den 21. januar 2008 var der møde
med finn hansen, hvor de blev enige om, at de skulle implementere de 4 områder, som står i
hensigtserklæringens punkt 2.3. de havde et forhandlingsmøde den 22. januar 2008, hvor de
læste aftalen, der var fra den 21. januar 2008, igennem, og saab fik til opgave at skrive en
kravspecifikation for mip block 2. kravspecifikationen skulle leveres den 29. januar 2008,
og fmt skulle svare den 31. januar 2008. fmt svarede ikke den 31. januar 2008. herefter
flyttede man opgaven om, at fmt skulle læse kravspecifikationen, til den 4. februar 2008.
den 4. februar 2008 havde fmt ikke læst kravspecifikationen. det blev flyttet til den 6. fe-
bruar 2008. den 6. februar 2008 havde fmt ikke gennemgået kravspecifikationerne. det blev
aftalt, at der skulle holdes en workshop den 15. februar 2008. på workshoppen blev man enige
om den måde, hvorpå kravspecifikationerne skulle opbygges. fmt ville have, at kravspecifi-
kationerne skulle være negative forstået på den måde, at de krav, som ikke blev opfyldt, blev
beskrevet. sådan skrives en kravspecifikation ikke i udviklingsverdenen. saab skriver de
krav, som saab skal opfylde for, at man kan teste kravene. dette blev man også enige om på
workshoppen den 15. februar 2008. dette kaldes en positivliste.
efter mødet skulle de have gennemgang af kravspecifikationerne den 19. februar 2008. fmt
var ikke enige i kravspecifikationerne. man blev herefter enige om, at der blev indført refe-
rencer til mip block 2 standarder og referencer til testspecifikationerne. den 20. februar 2008
var de enige om, hvordan kravspecifikationerne skulle se ud. den 21. februar 2008 var der et
nyt møde, hvor saab havde fået en e-mail fra fmt med deres bekymringer. saab var ikke
enige i bekymringerne. dette fremgår af referat af mødet den 21. februar 2008. der er en be-
skrivelse af mip block 2, som det er beskrevet i originalkontrakten, og så har man gennem-
ført mip block 2 analysen for de fire omtalte områder. saab gennemførte en mip block 2
kravspecifikation for de fire områder. saab lavede et forslag til, hvordan man krydsrefererer
til operationelle scenarier og slt test case. dette betyder, at fmt havde fået alt det, der
fremgik af hensigtserklæringen og mere til. de fik det gratis. saab kunne ikke have gjort
mere. saab gav indrømmelser. baggrunden herfor var, at saab etablerede sig i danmark den
1. januar 2007. saab så danmark som sit nye hjemmemarked. saab så fmt som en meget
vigtig kunde og daccis som et meget vigtigt produkt for internationale relationer. saab
behøvede fmt som referencekunde for internationale affærer.
                                               - 88 -
han er bekendt med betegnelsen safety critical. saab har tidligere lavet systemer, der var sa-
fety critical. betegnelsen safety critical fremgår normalt altid af aftalen. hvis det ikke fremgår
af aftalen, er det ikke ensbetydende med, at man ikke får det, men man har altid talt om det
under kontraktforhandlingerne, hvis der skulle leveres en systemsikkerhedsanalyse. hvis sy-
stemet skal være safety critical, vil der altid være en systemsikkerhedsanalyse. dette var der
ikke for daccis. hvis man skal lave et system, der er safety critical, skal man anvende en
bestemt metode, når man udvikler. det påvirker prisen og projektorganisationen. det påvirker
endvidere graden af verifikation og analyse. med baggrund i egen erfaring er det hans opfat-
telse, at der ikke var tale om et safety critcal system. han har arbejdet med flere safety critical
systemer.
björn haar har forklaret bl.a., at han er jurist i saab danmark, og han deltog i kontraktfor-
handlingerne med fmt. fokus for fmt var, i lyset af fiat-testen i februar 2007, primært på
stabiliteten i systemet. fiat-testen var gået dårligt. dette var også baggrunden for, at man fik
en kontrakt med to fremdriftsprøver. det blev gjort klart under forhandlingerne, at fmt lagde
vægt på to fremdriftsprøver i form af ic og oc og en afsluttende accepttest i forbindelse med
leverancen. mip og bdm var ikke i fokus for fmt. mip og bdm var ikke tidskritisk i for-
bindelse med kontraktforhandlingerne. fmt var villig til at fravælge funktionalitet for at få
stabilitet. han var ikke involveret i forhandlingerne om, hvorvidt man skulle bevæge sig fra
mip block 2 til mip block 3. han var bekendt med, at man diskuterede mip block 2 og mip
block 3. han er ikke helt klar over, hvornår man skiftede. han tog sig mest af det juridiske og
ikke funktionaliteten. han lagde ikke mærke til forholdene generelt omkring mip block 2 og
mip block 3, fordi man ikke tillagde dette særligt meget vægt på det tidspunkt. han var ikke
bekendt med, at der i kravspecifikationerne stod, at mip block 2 var et særkrav til oc.
han kender betegnelsen safety critical. han har hørt den før. i foråret 2007 diskuterede man
ikke, at daccis skulle være safety critical. det fremgår ikke af kontrakten, at daccis skal
være safety critical.
der havde været lignende bestemmelser i tidligere kontrakter med fmt som den, den er fast-
sat i punkt 16.4 i kontrakten af 29. juni 2007. det var ikke hans opfattelse, at der her skulle
gælde en anden beslutningskompetenceregel. de havde haft et langt kontraktforhold med
fmt, og der havde udviklet sig en kutyme for, hvordan man samarbejdede. det var derfor
klart, at når man kom til ændringer, så havde man en håndtering for, hvordan man fik formali-
                                              - 89 -
seret ændringerne. det vil sige, at ændringer skulle være nedfældet i en ccp for at være gæl-
dende mellem parterne, men det havde jo været sådan, at man tidligere i styregrupperne havde
haft kompetence til at træffe sådanne beslutninger. disse blev efterfølgende formaliseret. det
var hans opfattelse, at det samme skulle være gældende i denne kontrakt for daccis.
i forbindelse med mødet den 4. december 2007 blev der lagt op til, at saab skulle påtage sig
skylden for at få en udskydelse af oc til maj 2008.
morten binderup har forklaret bl.a., at han deltog i daccis før den nye daccis 6.6 kon-
trakt. styregruppen før den nye daccis 6.6 kontrakt havde kompetence til at træffe beslut-
ning vedrørende tid, pris og ydelse. projektgruppen før daccis 6.6 kontrakten havde kom-
petence til at træffe beslutning inden for rammerne af pris, tid og ydelse. projektledelsen
kunne træffe beslutning inden for rammerne, men på tværs af mindre milepæle kunne pro-
jektgruppen godt planlægge så længe, at det blev inden for kontraktens rammer. hvis man
flyttede en milepæl undervejs i projektet, kunne projektledelsen beslutte dette, så længe det
ikke gik ud over den endelige milepæl. i den nye daccis 6.6 kontrakt blev der ikke truffet
ændringer i forhold til den tidligere daccis kontrakts bestemmelser vedrørende beslut-
ningskompetencerne.
han mener, at kompetencen i styregruppen fremgik af et underbilag til kontrakten. som han
husker det, strider ordene i hovedkontrakten mod ordene i bilagene. han husker ikke præcist,
i hvilket bilag det står, men han mener, at det var i bilaget vedrørende projektstyring. i praksis
fulgte man underbilaget, ligesom man altid havde gjort. det drejede sig ikke kun om små æn-
dringer, men også større ændringer, som f.eks. at man udvidede tidsforbruget ganske betyde-
ligt og dermed også omkostningerne ved projektet, ligesom leverancer blev udsat med flere
måneder. disse eksempler er efter den gamle kontrakt, men der er nøjagtig de samme formu-
leringer i de to kontrakter. han mener, at der er tale om copy and paste. det var praksis, at
man fulgte ordene i underbilaget. han mindes ikke, at der var indgået en egentlig aftale.
typisk blev kontrakten rettet til langt senere.
han var med til alle de indledende møder vedrørende indgåelsen af den nye daccis 6.6
kontrakt. de indledende møder og debriefing blev holdt på hans kontor. han var ikke med
ved selve forhandlingerne. det primære fokus med den nye daccis 6.6 kontrakt var stabili-
tet. fokus på stabilitet betød, at de som leverandører kunne skære systemet til, så det blev sta-
                                                - 90 -
bilt, og derefter kunne de lægge funktionaliteter på. ved oc-testen skulle saab levere et sy-
stem med meget begrænset funktionalitet. der var en hel række funktionaliteter, som normalt
skulle vises, der ikke skulle med, herunder fjendebilledet og logistik og flere andre funktioner.
ved oc i uge 51 blev der testet langt mere funktionalitet end shall-kravene. stort set alt
”should have” og ”nice to have” blev testet. systemet var meget stabilt ved oc. han har al-
drig set et system testet, der var så stabilt. han fornemmede, at brugerne syntes, at det var
irriterende stabilt.
et skiveopdelt system var et billede, som fmt anvendte. man sagde, at man skar systemet
helt ind til kernen, og lagde funktionaliteter på skive for skive, så man var sikker på, at man
bevarede stabiliteten.
han deltog i styregruppemøde 47 den 16. maj 2007. saab var blevet bedt om at komme med
en opdateret leveranceplan/projektplan med mip block 3. det var denne, der blev diskuteret
på styregruppemødet. det blev på mødet besluttet at følge den fremlagte plan. mip block 3
var indeholdt i planen. dette fremgår af referatet fra mødet under punkt 3, hvor der står: ”sty-
regruppen anbefaler at følge leverandørens fremlagte leveringsplan for daccis 6.6, men der
er behov for afklaring af vedligehold for 2008 specielt med fokus på løbende tilpasninger i
mip block 3” samt punkt 4. dette betød, at mip block 2 var ude af planerne. mip block 2
var testet i februar i tyskland. der var en stram projektplan, derfor var det vigtigt med en
afklaring på, hvordan udviklingen skulle foregå. mip samfundets specifikationer til block 3
var ikke klar på dette tidspunkt, herunder testspecifikationerne. de var under udvikling i mip
samfundet. det var ikke realistisk at teste mip block 3 og have det klar til oc, da de grund-
læggende replikeringstest (slt 2) først skulle gennemføres primo 2008 efter oc-testen. saab
startede på tidspunktet for styregruppemøde 47 med at udvikle block 3. det var først meget
sent i forløbet, at fmt sagde, at de gerne vil have block 2. saab fremsendte contract change
proposal midt i november 2007. sidst i november 2007 ”statede” fmt helt klart, at de vil
have en test med mip block 2. på dette tidspunkt var det urealistisk at gå tilbage til block 2.
man var rigtigt langt inde i testforløbet med klargøring af test til oc. man kunne ikke bare
tilføje en sådan komponent. det ville være en alt for stor risiko.
fmt kunne ikke indgå en kontrakt, der indeholdt nye funktionaliteter end dem, der blev testet
i februar 2007. mip block 3 er ny funktionalitet i forhold til block 2. politisk blev det krævet,
at der ikke kunne indgås kontrakt om nye funktionaliteter. derfor gik man ind og skrev mip
                                               - 91 -
block 2 i kontrakten, men det ændrede ikke ved beslutningen på styregruppemøde 47. der var
fælles forståelse for, at de tillægskrav, der vedrørte block 3, skulle kontraheres umiddelbart
efter på en tillægskontrakt. forsvaret ønskede på dette tidspunkt fortsat block 3. krav til mip
compliancy kom ind som et tillægskrav. i selve kontrakten er der kun krav til replikering.
han deltog i styregruppemøde den 7. september 2007. dette var første styregruppemøde efter
den nye kontrakt. det blev understreget på mødet, at man fortsat arbejdede mod mip block 3.
det, der blev diskuteret på mødet, var projektplanen. det man talte om, var komponenten mip
replikering. man talte ikke om nationale specifikke krav. fmt kunne godt finde på at sige, at
mip var vigtigere end nationale krav, men når man kom til specifikke nationale krav, var det
altid de specifikke nationale krav, der fik prioritet. på mødet forholdt man sig til det, der
fremgår af kontrakten vedrørende levering af mip block 2 ved oc. hok sagde, at man
havde planlagt at deltage i øvelser med block 2, fordi det fremgik af kontrakten. han gjorde
straks opmærksom på, at dette var en fejl. det blev besluttet, at der skulle skrives en ccp om
kravmatricen vedrørende block 2. det skulle rette op på den fejl, der var i kontrakten. fmt
protesterede ikke herimod. der havde været mange møder både styregruppe- og projektleder-
møder, hvor man havde præsenteret grafiske planer for leverancer, og der havde man farvet
de ting, der ikke skulle leveres rødt. mip har altid været farvet rød ved oc og ic. dette var
også tydeligt ved, at kundens repræsentant på styregruppemødet ydmygt spurgte ind til, om
man kunne lave en alternativ leverance i foråret 2008. fmt var henover sommeren blevet klar
over, at øvelserne, der skulle afvikles i foråret 2008, cwid og ce, skulle gennemføres med
block 2. da man indgik kontrakten, forventede man, at øvelserne skulle gennemføres med
block 3.
han husker ikke at have hørt om, at fmt i maj 2007 havde tre forudsætninger i forhold til
mip block 3. det ville ikke kunne lade sig gøre at skifte til mip block 3 uden meromkost-
ning. de økonomiske forudsætninger blev diskuteret inden kontraktindgåelsen. indholdet af
drøftelserne var, at man havde svært ved at estimere omkostningerne til block 3, da specifi-
kationerne til block 3 ikke var fuldstændigt færdige.
han deltog i mødet den 4. december 2007. formålet med mødet var at diskutere et brev, som
saab havde sendt til fmt den 30. november 2007. fmt var meget utilfredse med det brev,
fordi der stod en sætning omkring tvivl i brevet. fmt kunne ikke leve med tvivl om, hvorfor
situationen var opstået, fordi det pegede på dem. det var et rimeligt ubehageligt møde. det
                                              - 92 -
var første gang, at han mødte bjarke heiberg-iürgensen. bjarke heiberg-iürgensen var meget
sur over, at saab havde bragt fmt i denne situation. dette blev nævnt mange gange. det vir-
kede, som om der var karriere på spil på dette møde. det var et meget presset møde. fmt
truede mange gange med at hæve kontrakten. stridens kerne var oc-testen. fmt kunne godt
leve med, at man udsatte oc til maj, hvis saab påtog sig skylden. saab blev bedt om at for-
mulere et nyt brev, der skulle erstatte det gamle brev, hvor saab entydigt påtog sig ansvaret.
hvis saab entydigt påtog sig ansvaret, ville fmt gå med til, at oc blev udskudt til maj. på
mødet kom de ind på den formulering, som saab skulle lave i deres brev, og de kom tillige
ind på formuleringen i det brev, som saab ville modtage som svar fra fmt. der var udkast
fremme på mødet omkring formuleringerne, både de formuleringer, som saab skulle udfær-
dige, og dem, som fmt skulle udfærdige.
saab fulgte den udviklingsmodel, som man kalder v-modellen. det er den model, der er af-
spejlet i bilag aay. denne model gjaldt ikke for den nye daccis 6.6 kontrakt. for den nye
kontrakt gælder pmp. pmp henviser til en udviklingsmodel i saab danmarks kvalitetssik-
ringssystem. den pmp, der gælder for den nye kontrakt, fremgår af bilag aaz. udviklings-
modellen er løbende blevet tilpasset efter aftale med fmt. ssrs‟er var kravspecifikationer
for subsystemer/delsystemer af det samlede system. der var i modellen andre dokumenter,
f.eks. sds, ssds, swds osv. der blev programmeret på grund af swds. saab fulgte den
aftalte udviklingsmodel. saab programmerede aldrig uden en plan eller et grundlag. dette
kunne ikke lade sig gøre.
fmt var involveret i saabs udviklingsproces. udviklingsprocessen fremgik som regel af
kontrakten og bilagene. herudover havde fmt deres egne tekniske eksperter med. de revie-
wede og godkendte rigtig mange af de dokumenter, der blev produceret som et resultat af pro-
cessen. fmt gennemlæste dokumenterne og afgav kommentarer. der var endvidere revision,
hvor fmt kom på besøg og kontrollerede beskrivelsen af processen og kontrollerede, at pro-
cessen blev fulgt. dette skete på samme vis, som når dansk standard har revision. der var
flere kontrolbesøg i løbet af processen. fmt har løbende set den dokumentation, der lå til
grund for daccis. fmt har mange gange været uenige i dokumenter, men han husker ikke,
at fmt har været uenige i processen. når der var uenighed om dokumenter, blev det diskute-
ret på review-møder. forfatteren, som typisk var saab, tog sig af dokumentet og lavede de
rettelser, der skulle til. nogle dokumenter blev herefter reviewet, og andre blev sendt til for-
                                              - 93 -
svaret. det er et af de projekter, hvor han har oplevet, at fmt var tættere på processen, end
hvad man typisk så fra forsvarets side.
han kender prince 2. man styrer risikoen ved med jævne mellemrum at opsamle projektrisks
og klassificerer dem efter projektpåvirkning og sandsynlighed. dette giver ikke i sig selv
kunden indsigt, men en anden del er, at man deler de væsentligste risks på fælles styregrup-
pemøder og projektgruppemøder. saab benyttede prince 2 efter ønske fra fmt.
eva senderovitz har forklaret bl.a., at da man begyndte at udvikle daccis, tænkte man in-
teroperabilitet ind. man baserede centrale komponenter på internationale standarder. den
standard hedder atccis. meningen var, at man fra starten ville lave et system, der kunne
kommunikere med andre c2 systemer. man ville lave et system, der var forberedt på at kunne
kommunikere med andre c2 systemer, men det kunne det ikke på dette tidspunkt, fordi der
ikke var stillet krav herom. forsvaret ønskede at anvende egne metoder og arbejdsgange. for-
svaret prioriterede ikke international interoperabilitet. daccis var ikke mip-interoperabelt,
før block 2 replikeringen blev introduceret. dette var, fordi forsvaret prioriterede nationale
krav over internationale krav. mip block 2 replikeringen blev introduceret ved rekvirerin-
gerne 6.1 og 6.2 i sommeren 2004. det blev introduceret i forbindelse med en større afleve-
ring af daccis, der dækkede første fase. nu skulle man tage fat på næste fase.
mip block 2 replikeringen var underlagt retningsliner fra mip samfundet i form af specifika-
tioner samt de retningslinjer, der var gældende for hele daccis projektet, for så vidt angår
udviklingsmodel og metoder. mip block 2 replikeringsmekanismen blev løbende testet, dels
ved interne test og dels ved internationale test i mip samfundet. disse test fulgte de aftaler,
der var indgået med fmt. dette kaldes v-modellen. replikeringsfunktionaliteterne blev inte-
greret løbende i daccis. hun er ikke enig i kritikken i skønsrapporten om, at ssrs‟en for
replikering ikke indeholder tilstrækkelig specifikation. ssrs‟en blev brugt som udgangspunkt
for deres udvikling af replikeringsmekanismen. i tillæg til ssrs replikeringer anvendte de
også de internationale specifikationer fra mip samfundet. det var et krav, at deres
replikeringsmekanisme skulle bygge på mip standardens specifikationer. i ssrs‟en er der
referencer til mip samfundets specifikationer. der står i ssrs‟en, at man skal følge den. det
er hensigtsmæssigt, at man i ssrs‟en henviser til mip samfundets specifikationer i stedet for
at kopiere dem ind, idet de opdateres løbende. ssrs‟en var godkendt af fmt. den blev an-
                                               - 94 -
vendt til at udvikle replikeringsmekanismen. hvis der var uklarheder, så blev de diskuteret
med kunden og løst løbende.
mip block 2 replikeringen er ikke tilstrækkelig til at gøre daccis interoperabelt. der
mangler compliancy i c2 systemer. compliancy kommer ikke automatisk med i mip replike-
ring. mip replikering håndterer udveksling af data, mens compliancy er systemets evne til at
vise og forstå data for slutbrugerne. fmt havde ikke bestilt compliancy. compliancy blev
introduceret til daccis ved, at saab adresserede det på et projektledermøde i sommeren
2005, hvor de kunne se, at der var konflikter inden for området. saab forklarede, at der ikke
var stillet tydelige krav inden for området, og der var forskellige præferencer for, hvad der
skulle være gældende. de kom videre med compliancy ved, at de på projektledermødet be-
sluttede, at der skulle afholdes en workshop, hvor de skulle informere om problemet, og
sammen skulle de finde en vej fremad. resultatet blev, at man skulle arbejde videre med mip
compliancy. på mødet blev der udarbejdet en plan for at få forudsætningerne om compliancy
etableret i systemet. i forsvaret var der forskellige ønsker til compliancy. brugergruppen
havde fokus på egne arbejdsgange og prioriterede ikke interoperabilitet. brugergruppens op-
gave var at specificere kravene til systemet. på den anden side var der hss, som syntes, at
interoperabilitet var det vigtigste for daccis. i 2005 havde man en konflikt mellem
nationale ønsker og brugen af mip. konflikten skulle løses ved, at forsvaret definerede
tydelige krav, og forsvaret skulle træffe nogle valg, der skulle afspejles i dets handlinger.
denne opgave løste forsvaret ikke. den blev ikke løst, fordi det ikke blev prioriteret fra
forsvarets side. projektet kom videre med compliancy ved, at man kørte i to spor, et kortsigtet
og et langsigtet spor. det kortsigtede spor havde til formål at få daccis til at gennemføre de
internationale mip test og gik ud på at implementere en kortsigtet løsning, hvor saab
arbejdede på at gøre en begrænset del af systemet interoperabelt. den langsigtede løsning
omhandlede at definere krav tydeligt og derefter implementere interoperabilitet i systemet.
den langsigtede løsning blev også kaldet daccis 6.7. det kortsigtede spor lykkedes ved, at
man gennemførte mip block 2 test med de mål, der var sat. der er tale om samtlige test.
dette arbejde blev dokumenteret og testet. man havde dog ikke udgangspunkt i brugerkrav,
fordi sådanne ikke var defineret. brugerkravene skulle defineres og tydeligt formuleres i
daccis 6.7. der kunne udvikles uden krav, fordi designet var baseret på, at systemet skulle
være interoperabelt. dette var fmt opmærksomme på. mip konsolideringsaftalen var en
midlertidig lappeløsning. et af formålene med aftalen var at finde ud af, hvordan man kom
videre med mip compliancy. de udarbejdede en analyse og en anbefaling til, hvordan
                                               - 95 -
interoperabiliteten skulle indarbejdes. anbefalingen bestod af tre faser, hvoraf nogle kunne
implementeres med det samme, og nogle burde vente til mip block 3. fmt accepterede og
var enige i anbefalingen, herunder at noget skulle vente til block 3. daccis 6.7 var den
rekvirering, der skulle tilføre compliancy. dette betyder, at daccis 6.7 skulle løfte daccis
fra en relativ lav compliancy til en relativ høj compliancy. tanken var den, at daccis 6.7
skulle gøre daccis anvendelig i internationale operationer. det var midt i 2006, at arbejdet
gik i gang under daccis 6.7. man nåede ikke særligt langt, før det blev sat på hold.
daccis 6.7 var ikke en del af det system, der var med ved fiat-testen i 2007.
da man indgik den nye kontrakt vedrørende daccis 6.6, blev der indført mip compliancy
krav til block 3. det er de krav, der er efterfulgt af et x. der var ikke mip compliancy krav til
block 2 i daccis kontrakten. de krav, der var til block 3, svarede til de krav, der var til
compliancy til block 2. der var tale om slt 3 niveau. mip block 3 skulle leveres ved den
endelige aflevering af fc – den endelige aflevering af systemet. udviklingsmæssigt giver det
god mening, at der ikke var krav til mip block 2 compliancy i daccis 6.6, da man etable-
rede det tekniske fundament ved replikeringen. når der kun er replikering, kan man ikke
bruge det operationelt, fordi der ikke er nogen informationer at udveksle. compliancy til
block 2 fremgår af daccis 6.7 kontrakten. det vil sige, at daccis 6.7 var en kontrakt, der
først skulle leveres, når daccis 6.6 var leveret. fuld mip compliancy skulle først leveres,
når den nye daccis 6.6 kontrakt var leveret. cor x krav i daccis 6.6 er krav til mip block
3. mip block 3 replikering blev udviklet under en rekvirering, der kørte parallelt med dac-
cis projektet og i henhold til gældende processer og metoder for daccis. det var på samme
måde, som mip block 2 var udviklet. mip block 3 replikering blev også løbende testet in-
ternt og internationalt i henhold til mip samfundets rammer. udviklingen fulgte den såkaldte
v-model. der forelå en ssrs for replikering, som også omfattede mip replikering. den blev
ikke opdateret til at pege på block 3 i stedet for block 2. det var ikke et problem for udvik-
lingen, fordi ingen var i tvivl om, at de skulle udvikle block 3 replikeringsmekanismen, og
det, der var væsentligt, var at forstå mip samfundets specifikationer. der var andre vigtige
underliggende dokumenter, som de udviklede internt, og så var der mip samfundets specifi-
kationer, som blev fulgt. block 3 mekanismen blev færdigudviklet, og den virkede.
saab udførte noget specifikationsarbejde vedrørende mip block 2 i forbindelse med hensigts-
erklæringen fra december 2007. en væsentlig del af det specifikationsarbejde, der skulle udfø-
res, var det samme, som skulle laves under daccis 6.7 kontrakten og dertil lidt på kryds og
                                               - 96 -
tværs. det betød, at der herved blev indført krav til compliancy i daccis 6.6. kontrakten.
dette havde der ikke været tidligere. fmt var klar over dette. det betød, at en stor del af
daccis 6.7 kontrakten ikke længere var relevant. fmt skulle ikke betale for disse nye krav.
hvis daccis var leveret med block 2 til fc, og de allierede også anvendte block 2, ville
daccis have været begrænset operativt anvendeligt, fordi der var mangler ved mip block 2
standarden. der var mangler vedrørende planlægningsdelen og den del, der vedrørte opera-
tionsordrer. dette ville blive løst ved mip block 3.
hun deltog i afprøvning af daccis i mip samfundet. test niveauet og indholdet er defineret
af mip samfundet. visse test udførtes over internettet, og visse test foregik i den tyske by
greding, hvor man møder op med sit system, der skal prøve at interoperere med andre landes
systemer. daccis havde deltaget i test på samtlige niveauer, men nåede ikke at gennemføre
den sidste olt test, fordi forsvaret valgte, at daccis ikke skulle deltage. testen lå i marts
2007. konsekvensen af, at daccis ikke deltog, var, at daccis ikke blev
færdigtestet/færdigudviklet i mip-regi. det betyder reelt, at man ikke kan bruge daccis i
block 2 regi. daccis i block 2 skulle have været brugt ved internationale øvelser i 2007.
dette valgte forsvaret fra. efter fiat i 2007 var der ikke grund til at lægge tid og penge i
olt. daccis havde bestået alle de test i mip samfundet, som daccis havde deltaget i.
integrationen af block 2 i forhold til daccis blev foretaget løbende. saab opdagede i løbet
af efteråret 2007, at mip samfundets tidsplan for block 3 var blevet udskudt. hun mener, at
det var omkring september 2007.
mip block 2 miljøet og standarden omkring testen og processen var temmelig kaotisk. den
var ikke klokkeklar og ren. standarden var ikke tilstrækkelig klar og moden. specifikatio-
nerne var tilgængelige på mip samfundets hjemmeside. man kunne sagtens give sig til at
programmere uden at være med i mip samfundet, men sandsynligheden for, at det ville lyk-
kes, var lille, fordi standarden ikke var utvetydig og tilstrækkelig moden. for kompatibiliteten
med andre landes systemer var det afgørende, at man havde deltaget i processen i mip sam-
fundet. universet af c2 systemer og mip er ganske komplekst, og billedet er grumset. det var
særligt grumset under block 2 perioden. der er virksomheder, som har udarbejdet mip sy-
stemer udelukkende på baggrund af mip specifikationer uden at have deltaget i mip samfun-
det selv. dette er ikke gået ret godt. det er gået dårligt, fordi mip specifikationerne er meget
svære at forstå, hvis man ikke har deltaget i hele det arbejde, der ligger rundt om specifikatio-
                                              - 97 -
nerne. dette betyder, at uden deltagelse i mip samfundet ville daccis ikke reelt have kun-
net anvendes med mip. det samme gælder hvis man ikke nøje fulgte mip samfundets tids-
plan.
fmt fortalte på intet tidspunkt, hvad de forventede af saabs mip analyse ud over det, der
stod i hensigtserklæringen, hvoraf det fremgik, at man skulle analysere vilkårene for test af 4
udpegede områder. det var det, der blev leveret til fmt. dette var ikke godt nok. fmt ville
have noget andet. fmt kommenterede ikke analysen til at begynde med, men de udtrykte
bekymring. det eskalerede. saab forstod, at det ikke blot var en analyse, der skulle leveres,
det var en kravspecifikation for de 4 områder. dette var væsentligt mere end det, der stod i
hensigtserklæringen. det er korrekt, når det konkluderes, at der kun var få tekniske forhin-
dringer tilbage efter workshoppen, der blev holdt den 15. februar 2008. da de i februar 2008
afgav deres endelige analyse og tidsplan, fremgik det, at de skulle have til uge 24 i 2008 for at
etablere dokumentationen, fordi alle ressourcer hos dem var allokerede til mange andre ting,
der skulle laves i daccis projektet. for at undgå at øge risikoen for de allerede planlagte
daccis opgaver, kunne de ikke påtage sig yderligere. den metode, man blev enige om på
workshoppen den 15. februar 2008, var en positivliste over krav. denne metode havde man
ikke fundet på før, fordi dette var et arbejde, der skulle udføres under daccis 6.7 kontrak-
ten, der var sat på hold.
hun har deltaget i udviklingen af andre systemer til militært brugt. hun kender betegnelsen
”system safety critical”. ikke alle militærsystemer er koblet til potentielle tab af liv. for så
vidt angår de systemer, der er koblet til potentielle tab af liv, er det den sammenhæng, som de
indgår i, og den måde, som de anvendes på, der er afgørende for, om de er kategoriseret som
safety critical. det er kunden, der afgør, om systemet skal kategoriseres som safety critical,
idet det er kunden, der forstår den sammenhæng, som systemet indgår i, og det, der ligger
rundt omkring. hvis et system skal være safety critical, fremgår det af kontrakten. der stilles
meget strenge krav til udviklingsprocessen for systemer, der er safety critical. kontraktmate-
rialet er tillige mere omfattende. daccis var ikke et safety critical system. det ved hun,
fordi daccis aldrig i hendes tid er blevet specificeret som safety critical. militæret har be-
stilt andre safety critical systemer hos saab. i løbet af daccis‟ udvikling har de adresseret
emnet security. de har lavet et security studie. men security og safety er to forskellige ting.
forskellen mellem safety og security er, at system safety adresserer beskyttelse af systemets
omgivelser, hvis systemet ikke fungerer, som det skal. system security har mere at gøre med
                                               - 98 -
at beskytte selve systemet, som f.eks at man sikrer, at hemmeligt stemplet data sendes ud af
systemet.
peter wimmerström har forklaret bl.a., at ikke han deltog i mødet den 4. december 2007. han
var i sydafrika. han blev kontaktet sent om aftenen, da deres sælger i danmark, hans ole
hovgaard, der sad i møde med fmt, ringede til ham. hans ole hovgaard fortalte, at fmt
ville gå med til en udskydelse af oc til maj 2008, hvis saab påtog sig ansvaret. hans ole
hovgaard så et udkast til en beslutning, som formelt skulle godkende kontraktændringsforsla-
gene. hvis saab ikke påtog sig ansvaret, ville fmt hæve kontrakten.
han skrev brevet af 4. december 2007, hvor saab formelt påtog sig ansvaret, fordi det jo var
det, fmt havde krævet. han ville aldrig have skrevet brevet, hvis de ikke havde fået en ud-
sættelse af oc til 2008. i stedet for at give den udsættelse, som fmt havde lovet, tog fmt
brevet som indtægt for, at man kunne hæve aftalen.
den 18. december 2007 havde han en telefonsamtale med finn hansen. samtalen drejede sig
om, hvilke testkonfigurationer der skulle anvendes. fmt havde synspunkter om de testkonfi-
gurationer, som blev anvendt ved oc-testen. han talte med finn hansen om oc-testen. de
blev enige om at fortsætte oc-testen. det skulle ske uden mip og bdm komponenterne. finn
hansen ville have en kompensation. de diskuterede, hvori kompensationen skulle bestå, og
de blev enige om, at saab skulle levere mip block 3 gratis. samme aften sendte han en e-mail
ud til alle i saab, som var berørt, både chefer og testpersoner. der var tale om en rabat på
mellem 20 og 30 millioner kr., når mip block 3 blev leveret gratis.
saab havde drevet projektet på den måde, som det var blevet besluttet på møderne i styre-
gruppen. hovedansvaret hviler på fmt, fordi det var dem, der tog de formelle beslutninger i
styregruppen. ved at påtage sig ansvaret gjorde saab det, som fmt forlangte for, at projektet
kunne fortsætte. det forhold, at saab tilbød en rabat, var ikke ensbetydende med, at saab på-
tog sig ansvaret. saab ville fortsætte projektet, fordi saab havde enorme økonomiske interes-
ser i danmark. på dette tidspunkt pågik der forhandlinger om indkøb af nye kampfly i folke-
tinget. saab koncernen var interesseret i at bevare deres relation til danmark. på dette tids-
punkt havde saab et salg i danmark til det danske forsvar på 1 milliard kr.
                                             - 99 -
mødet den 19. december 2007 mellem saab og fmt handlede meget om, hvordan de gen-
nemførte testene. på mødet aftalte man en frist for at blive enige om et letter of intent. man
var enige om at udføre testene, men uden bdm og mip. når det af referatet fra mødet frem-
går, at ”fmt bemærkede til ref. c. og en kort drøftelse om testforløbet, at oc-testen var saab
ab ansvar, og at beslutninger i relation hertil alene var saab ab egne. fmt var fortsat til
rådighed for testene også hvis dette indebar, at der skulle arbejdes sent eller lørdag”, betød det
at testene, som pågik, skulle gøres færdige.
henning hay sørensen har forklaret bl.a., at de første gang opdagede, at der var problemer
med arkitekturen i daccis ved fiat i 2007. deres reaktion var, at de måtte analysere, hvad
det var, der var gået galt. fmt var helt klar over, at der var problemer. fmt vidste dette i
februar 2007. fmt var enige i, at der blev iværksat undersøgelser. formålet med undersøgel-
serne var at finde årsagerne til nedbruddene. deres konklusion var, at der var et antal områ-
der, som der skulle gøres noget ved. herefter gik de i gang med at løse problemerne. de ori-
enterede løbende fmt. der var styregruppemøde i maj 2007, hvor han havde en liste med
over årsager og status på fremdriften i forhold til at løse problemerne. det var en del af det
samarbejde, som de havde. det var saabs analyse. ic-testen foregik i uge 25 i 2007. denne
test viste noget om arkitekturen. formålet var at se fremdriften i stabiliteten. testen viste, at
der var klar forbedring i stabiliteten.
på projektledermødet den 23. august 2007 blev arkitekturen drøftet, og saab fortalte, hvor de
var kommet til. de fortalte, at de måtte skrive en del af systemet om, som vedrørte databa-
serne. dette betød, at de ikke kunne nå at blive færdige med bdm til oc. herpå reagerede
fmt således, at dette ikke var det vigtigste for dem. det var vigtigere for fmt, at mip block
2 var med til oc. det blev aftalt på mødet, at der skulle skrives en indstilling til styregruppen
om, at man skulle flytte testen af bdm fra oc til fc. det blev aftalt, at der skulle holdes en
workshop om arkitektur, fordi fmt gerne mere detaljeret ville vide, hvad saab havde fundet
ud af. saab ville også gerne underrette herom.
på projektledermøde i oktober 2007 blev der fra saabs side givet en præsentation på arkitek-
turworkshoppen samt konklusionerne på en intern analyse i saab. fmt‟s reaktion var, at
fmt hørte på, hvad der blev sagt, og deres repræsentant, p. d. hansen, og deres konsulent fra
ifad, jeppe nyløkke, så på hinanden og nikkede og sagde, at det så fornuftigt ud. ifad var
med på alle de møder, der blev holdt, dvs. styregruppemøder og projektledermøder og på ar-
                                               - 100 -
kitekturworkshoppen. fmt var klar over, at der var arkitekturproblemer, og at der var be-
stræbelser på at finde en løsning. fmt var interesserede i at finde en løsning. det var hele
projektets formål.
han deltog på styregruppemøde 47, der blev afholdt den 16. maj 2007. mip blev diskuteret på
mødet. fmt havde bedt saab om at lave en plan for implementering af block 3. den plan
blev fremlagt på mødet. det blev besluttet, at de gik efter block 3. dette fremgår af referatet
fra styregruppemødet, idet der her står, at: ”styregruppen anbefaler at følge leverandørens
fremlagte leveringsplan for daccis 6.6, men der er behov for afklaring af vedligehold for
2008 specielt med fokus på løbende tilpasninger i mip block 3.” leveringsplanen for block 3
blev fastlagt på dette møde. det var vigtigt for ham, fordi han var projektleder. det var endvi-
dere vigtigt for ham at vide, hvad de skulle arbejde hen imod. der skulle bruges mange timer
på dette, og det var derfor vigtigt for ham at vide, at hans folk derhjemme lavede det rigtige.
han husker tydeligt, at oberst bager kiggede rundt på alle i kredsen, og at alle nikkede til, at
planen var, at det var block 3, der skulle arbejdes efter. på dette tidspunkt var parterne enige
om, at det var block 3, der skulle anvendes fremover. block 2 skulle ikke bruges mere. på
mødet blev der refereret til nogle af de sager, hvor forsvaret havde købt forkert ind. forsvaret
ønskede ikke at stå med et system, der var forældet, når det blev leveret. allerede i marts
måned havde fmt meddelt, at block 2 ikke skulle bruges mere. baggrunden herfor var, at
block 2 udelukkende skulle anvendes ved to øvelser i foråret 2007, hvor de ikke skulle
deltage. block 2 skulle aldrig mere anvendes operationelt. begge parter forventede, at block 3
var lige på trapperne. han husker, at han blev hånet på et projektledermøde i marts 2007 af
fmt‟s repræsentant lars abild, fordi han kunne være så dum at foreslå, at de skulle deltage i
en mip øvelse med block 2.
efter kontraktunderskrivelsen blev det bekræftet, at man arbejdede efter block 3. be-
slutningen var truffet både før og efter kontraktunderskrivelsen. det var det, saab arbejdede
på. han husker ikke, at det blev aftalt, at det skulle være block 2 til oc og block 3 til fc.
daccis kunne ikke i praksis arbejde med block 2 til oc og block 3 til fc. det var også
derfor, at det var vigtigt for ham at få et klart mandat. det fremgik også af den grafisk
fremlagte plan, at der slet ikke var mip med til oc. han kan ikke nikke genkendende til, at
det fra forsvarets side havde været en forudsætning for at acceptere block 3, at
projektrisikoen ikke måtte blive forøget, at det skulle være økonomisk neutralt, og at det ikke
måtte forsinke projektet. han kender ikke til disse tre forudsætninger. forudsætningen om
                                               - 101 -
økonomisk neutralitet gav ikke mening, idet det var saabs holdning, at der skulle penge på
bordet. for så vidt angår forudsætningen om, at der ikke måtte ske en forsinkelse af projektet,
husker han, at de drøftede, om der var andre funktionaliteter i systemet, som de kunne rykke
for at få tid til at lave block 3 til fc. henrik juul krogh var fmt‟s projektleder og dermed
hans direkte samarbejdspartner. det har været kendt for henrik juul krogh, at de arbejdede
mod block 3. dette var fælles viden, og det havde været gældende på alle de møder, der var
blevet holdt. hvis man ser på block 2 som system indtil kontraktindgåelse, kunne det være
brugt til ce og cwid i foråret 2007, da det var blevet testet i greding og godkendt.
der er krav til mip block 3 compliancy i daccis 6.6 kontrakten. det er de krav, der kaldes
x-krav mod block 3. de nåede ikke at udvikle ret meget, da det først skulle leveres ved fc.
mip replication, infrastrukturen i systemet, kom de ret langt med. udvikling af mip
compliancy skulle dokumenteres. det var planen, at mip compliancy blev implementeret i
ssrs‟erne for hvert subsystem, hvilket er i overensstemmelse med skønsrapportens anbefa-
ling. de var ikke nået til at skrive ind i ssrs‟erne, hvordan det skulle samarbejde med mip,
fordi det først skulle ske til fc. specifikationer for mip block 3 fra mip samfundet kom først
senere end forventet.
han deltog i styregruppemøde nr. 48, der blev afholdt den 7. september 2007. saab fremlagde
på dette møde, at de ville flytte testen af bdm fra oc til fc. baggrunden herfor var, at de
nødvendige arkitekturændringer var omfattende, samt at bdm ikke var vigtigt for fmt. det
blev besluttet at gå videre under følgende betingelser: fmt ville kigge dem over skulderen
undervejs, og de skulle demonstrere basisdata manager undervejs. basisdata var i systemet.
hvis der skulle ske ændringer, kunne saab gøre det. det blev ikke aftalt at aflevere block 2 til
oc. det, der var vigtigt, var, at de kunne have en version i foråret 2008 til ce og cwid. med
hensyn til bdm ville det i den forbindelse være vigtigt at kunne indføre nye basisdata i syste-
met. den gamle block 2 og den nye block 3 kunne ikke sameksistere, fordi der var lavet
fundamentalt om i systemet. den fundamentale ændring i systemet var gennemført henover
sommeren. det, der skulle til for, at de kunne levere block 2 til oc, var, at de implemente-
rede en block 2 efter den nye arkitektur. de var nået et langt stykke hen ad vejen. der var
ikke tale om en uoverstigelig opgave på grund af arkitekturen. de gik i gang med block 2 til
oc, fordi de blev presset til det i den sidste fase op til jul. han blev presset af sin top mana-
gement. han havde ikke kontakt til forsvarets top management. det var forsvarets top mana-
gement, der pressede hans top management. det undrede ham, fordi det var i strid med den
                                              - 102 -
aftale, som han havde indgået med styregruppen, hvorefter han skulle lave block 3 til fc.
presset opstod efter mødet den 4. december 2007. han deltog i dette møde, hvor det blev det
aftalt at flytte oc til foråret 2008. de møder, der var aftalt med fmt om forberedelse til oc,
blev aflyst af fmt. når fmt begyndte at aflyse møder, var det hans konklusion, at det var en
fællesaftale, at oc var flyttet.
i ugen efter mødet den 4. december var parterne fortsat i kontakt. forsvaret ønskede ikke at
leve op til den aftale, der var indgået den 4. december. hans top management vidste ligesom
ham, at det var en anden aftale, der var indgået. det var fælles viden, at det, der skete, var
forkert. han gjorde derfor ikke opmærksom på det.
de mødereferater, som de optog under møderne med fmt, blev efterfølgende godkendt af
fmt. hvis fmt havde indvendinger, rettede de referatet, inden det blev underskrevet. refe-
ratet af projektledermøde 90 af 27. april 2007 blev godkendt af fmt. fmt havde ingen ind-
vendinger. årsagen hertil var, at det var fmt selv, der havde bedt dem om at udarbejde en
plan for, hvordan de kom til block 3. saab har aldrig modtaget de referater, som ifad udar-
bejdede.
prince 2 er en projektleder metode. styregruppens beslutningskompetence er, at de skal be-
slutte det, der ligger uden for de fastlagte rammer. styregruppen kan beslutte alt vedrørende
tid, penge og kvalitet. projektledelsens beslutningskompetence er at agere inden for rammerne
af tid, penge og kvalitet. prince 2 blev anvendt i forbindelse med daccis. dette var fmt‟s
ide.
der var en aftale om oc-testen. det skulle være en operationel test. dette fremgår af kon-
trakten og kontraktens bilag. den skulle gennemføres som en militærøvelse. ved testen blev
der præsenteret en situation og en plan, også kaldet et operationelt scenarie, og så blev uret sat
i gang. de hændelser, der var planlagt, blev meddelt undervejs af øvelsesledelsen. det var
fmt, der skulle levere de operationelle scenarier til testen. det var en kundeleverance. men
fmt leverede ikke de operationelle scenarier. han rykkede personligt via en e-mail til henrik
juul krogh i begyndelsen af september 2007. lars abild meddelte hertil via e-mail, at der var
to uger til levering, og han forstod derfor ikke, hvorfor der blev rykket. på baggrund af lars
abilds besvarelse var det hans klare opfattelse, at fmt var klar over, at det var fmt, der
skulle levere de operationelle scenarier. da fmt ikke leverede de operationelle scenarier,
                                                - 103 -
skrev saab deres egne operationelle scenarier. mip var ikke en del af scenarierne 1-7, som var
dem, der var planlagt til oc. det var afgørende, at det var samme test, der blev udført ved præ
oc, som til oc, fordi de ikke ville møde op uden at have afprøvet accepttestene i forvejen.
de afholdt en præ oc for at være sikre på, at de var klar til oc, og for at finde eventuelle fejl.
præ oc fremgik af kontrakten og tidsplanen. fmt deltog i præ oc. mip og bdm blev ikke
afprøvet ved præ oc. fmt havde ikke indvendinger herimod. oc-testen var en accepttest,
fordi der var tilknyttet acceptkriterier til testens resultat. men det var fremdriften, der skulle
vurderes. det var ikke systemet som sådan. det havde hele tiden været aftalt, at det skulle
være en fremdriftstest. præ oc gik fantastisk, bedre end nogensinde. fmts projektleder hen-
rik juul krogh tilkendegav, at det havde været en god uge for begge parter. dette bed han
mærke i, fordi det var ikke tit, at man hørte ham sige sådan.
i daccis havde man løbende reviewet dokumentationen. der var tale om fælles review, der
foregik på den måde, at saab sendte dokumenterne til fmt, som kom med deres kommenta-
rer, og herefter mødtes de og blev enige. det var en løbende proces efterhånden, som doku-
mentationen blev klar. i forbindelse med review blev de enkelte dokumenter gennemgået. de
havde endvidere joint review møder, hvor de udfærdigede joint reviewreports, hvoraf review-
kommentarer fra fmt, saabs svar og den fælles beslutning på mødet fremgik. herefter ret-
tede de det enkelte dokument. at der var tale om et endeligt rettet dokument, fremgik af revi-
sionshistorien.”author” er den, der har ført pennen og lavet rettelserne på revisionen. under
punktet ”description of revision” fremgår baggrunden for den revision, der har fundet sted.
der var ikke planlagt en særlig afprøvning af dokumentationen i forbindelse med oc-testen.
der var en milestone i januar, hvor dokumentationen skulle gennemgås. der blev forud for
oc gennemført en systemtest, hvor man testede de overordnede krav fra kunden et for et in-
ternt i saab. der var ikke krav herom i kontrakten. der var først krav herom til fc. der blev
fundet fejl ved testen, som blev medtaget i testrapporterne for oc i uge 51. testrapporterne
indeholdt samtlige fejl, der blev fundet ved daccis både før og under oc. saab kategorise-
rede selv de fejl, som blev fundet af saab internt. sammen med fmt kategoriserede saab de
fejl, der blev fundet ved præ oc og oc. fmt har set disse fejl. fmt har først efter, at kon-
trakten blev hævet, gjort opmærksom på, at de var utilfredse med kategoriseringen.
når det af skønserklæringen af 16. november 2012 fremgår, at ”factory acceptance testing”,
og at ”these tests will be one to one related to the system requirements document.”, betyder
                                              - 104 -
dette, at der ikke for hvert kundekrav kun er planlagt en test i form af en test case, men en
samling af test cases, test step, der er nødvendige for at teste det pågældende krav.
den 19. december 2007 sendte han en e-mail, fordi de havde fået besked fra et top manager-
møde om, at der skulle gennemføres oc til foråret. idet deres folk og forsvarets folk var
spændt op i tiden før jul, ville de ikke teste den sidste dag. det var ikke nødvendigt at gen-
nemføre testen, fordi oc var flyttet til foråret. der var en aftale mellem forsvaret og saab om,
at de ikke skulle gennemføre testen. baggrunden for, at han tog ansvaret i e-mailen, var, at
forsvaret i den uge ikke ønskede at tage ansvaret for noget som helst. forsvaret vidste godt,
hvad der foregik. flemming agerskov fra forsvaret deltog i morgenbriefingen for alle test-
deltagerne. flemming agerskov fortalte dagen efter, at han havde sørget for, at der ville blive
gennemført en ny oc-test til foråret, og han havde sørget for, at forsvaret fik block 3 gratis.
han har også set et internt notat fra forsvaret, hvoraf det fremgik, at der den 19. december var
en gensidig aftale mellem parterne om udskydelse af testen. flemming agerskov var den
højst rangerende officer ved testen i uge 51. oc var oprindeligt planlagt til at vare to uger.
den var tænkt som en generalprøve på fiat-testen, som lå til fc. men i løbet af efteråret bad
forsvaret dem om at skære testen ned til en uge. det blev diskuteret, om der efter nytår kunne
gennemføres en fælles fiat lignende test på to uger som generalprøve på fc.
han deltog ikke i kontraktforhandlingerne umiddelbart op til kontraktindgåelsen i juni 2007.
han læste dokumenterne, men deltog ikke i møderne. han læste de kladdeversioner, der endte
med at blive det endelig kontraktgrundlag. det var især david wadell, der forhandlede kon-
trakten sammen med folk fra saab danmark. block 2 var en del af systemet, og for block 3
skulle der laves en tillægskontakt. på dette tidspunkt var han opmærksom på, at der skulle
laves en tillægskontrakt før levering af block 3.
der blev udarbejdet 4 contract change proposals (ccp‟er). han husker ikke deres nummere-
ring, men han husker, at der blev udarbejdet en om, hvordan testene skulle foregå, en anden
vedrørte, at bdm skulle flyttes, en tredje var oversættelse af kontrakten samt en fjerde om, at
ordet ”shall” i kontrakten for mip block 2 til oc skulle ud. ordet ”shall” skulle ud af kon-
trakten, fordi det var en fejl. teksten i kontraktdokumenterne skulle ændres. dette ville par-
terne have en ccp på. det var hans opfattelse, at der var truffet en endelig beslutning på mø-
det den 7. september 2007, og at de bare kunne fremsende ccp‟erne, så ville forsvaret god-
kende dem over telefonen. det var hans opfattelse, at det var en formalitet, at der skulle sen-
                                              - 105 -
des ccp‟er. han fik også efterfølgende til præ oc i uge 44 af projektleder claus vester med-
delelse om, at forsvaret ville godkende ccp‟erne telefonisk. han anså det også forinden som
en formalitet. han husker ikke, hvordan ordene faldt på mødet den 7. september 2007, men
det er hans opfattelse, at der var tale om en endelig beslutning på mødet. han husker ikke, om
ccp‟erne vedrørte, at man skulle gå over til block 3, idet han ikke husker formuleringen. for
det var ccp‟erne vedrørende bdm og mip, der var de vigtige. han husker ikke, hvad der
blev aftalt vedrørende de resterende to ccp‟er.
i marts 2007 gik de i gang med planerne for block 3. på styregruppemøde den 16. maj 2007
fik han bekræftet mandat til at gå i gang med udviklingen af block 3. den tillægskontrakt, der
tales om i hovedkontrakten, var blot en formalitet. dette vidste han, fordi han havde læst do-
kumenterne.
peter krag-sander har forklaret bl.a., at baggrunden for, at arkitekturændringen i daccis
blev udviklet, var, at systemet fejlede i februar 2007. efter testen i 2007 gik de i saab tilbage
for at undersøge årsagerne til, at systemet fejlede. arkitekturændringen gik ud på at forenkle
systemet, så de fik skåret de dårlige ting fra. det gjorde de ved, at de forenklede arkitekturen
for systemet. i februar 2007 havde systemet flere tilgange for data. dette begrænsede de til én
tilgang for data. formålet med arkitekturændringen var at øge stabiliteten. stabiliteten blev
øget ved, at man lod data tilgå systemet via de samme dele, som resten af systemet, således
også for mip og bdm. de anvendte de samme komponenter, som den almindelige c2 klient
anvendte. de dele skulle genanvendes ved mip og bdm. de skrottede de andre elementer.
dette var implementeret ved oc-testen i uge 51 i 2007. mip og bdm ville i den nye arkitek-
tur være almindelige klienter i hovedsystemet på samme måde som c2 klienten. det vil sige,
at data fra mip og bdm skulle tilgå systemet på samme måde som andre data. dette betyder,
at kernen af den nye arkitektur var på plads ved oc. der er ikke forskel på datatilgangen for
mip og bdm i forhold til de øvrige dele af systemet. de dele, hvor data skal fødes ind i sy-
stemet, blev testet grundigt ved oc-testen. da c2 klienten anvendte de dele, og de dele blev
anvendt over fire dage, kunne man se, at arkitekturændringen var på plads. ellers havde testen
ikke kunnet gennemføres. bdm blev ikke testet ved oc. de dele af bdm, som vedrørte til-
førsel af data til systemet, blev testet ved brug af c2 klienten. systemet var meget stabilt ved
oc i uge 51 som følge af arkitekturændringen.
                                             - 106 -
de havde påbegyndt arkitekturændringen lang tid før udarbejdelsen af dokumentet ”archi-
tecture briefing”. det var ikke som sådan en omfattende arkitekturændring. der blev ikke ret-
tet sql koder i forbindelse med arkitekturændringen. det centrale af arkitekturændringen var
på plads ved code freeze.
basisdata er systemets grunddata. det er data, som resten af systemet er baseret på. bdm er
et program til at administrere basisdata. basisdata var indlagt ved installationen af systemet,
som foreskrevet af kunden. daccis kan ikke fungere uden basisdata. formålet med basis-
data var ikke, at en almindelig bruger skulle kunne ændre basisdata. men en person med ad-
ministrative rettigheder kunne ændre basisdata. forventningen var ikke, at ændring af basis-
data skulle ske hyppigt. da basisdata er grundlaget for brugen af systemet, skulle brugerne
være bekendte med disse. det er svært at forestille sig, at man vil bruge bdm akut. hvis ba-
sisdata skulle ændres akut, kunne man indføre basisdata direkte via databasen. det ville saab
kunne hjælpe kunden med. bdm skal give kunden mulighed for at tilrette basisdata selv. idet
basisdata er fællesgrundlag for brugen af systemet og bruges til at beskrive situationer og pla-
ner i systemet, skulle brugerne være bekendte med disse basisdata, før man indførte dem i
systemet. det er kun den gruppe af brugere, som skulle anvende de ændrede basisdata, der
skulle være bekendt med dem.
det er ham, der har udarbejdet ”redegørelse for påtænkt test af mip og bdm ved oc-testen i
uge 51, 2007”. redegørelsen viser, hvorledes det var påtænkt at teste mip og bdm ved oc-
testen. de havde tænkt sig at gøre dette ved at tilføje de to komponenter til den eksisterende
opsætning, som var anvendt over de forudgående 4 dage. det betyder, at mip og bdm ville
blive integreret med testopstillingen. data i systemet ville være de samme som det, der var
skabt over de sidste 4 dage. de ville ikke køre den helt samme test igennem bare med mip og
bdm. de ville, for så vidt angår mip, teste funktionaliteterne ved brug af testcases fra
mslt3. bdm skulle ikke reelt testes, men blot demonstreres. de dele af arkitekturen, der var
blevet ændret, ville blive anvendt af mip og bdm under test og demonstration. det, der ikke
var med ved oc, var noget der ikke skulle testes. kernefunktionaliten ved mip og bdm var
til stede ved oc.
når man udviklede en ny funktionalitet hos saab, testede man på flere forskellige niveauer, jf.
v-modellen. saab testede på kode niveau, unit niveau, modul niveau, subsystem niveau, og
system niveau. dertil er der test i fællesskab med kunden som operativ test, factory accep-
                                              - 107 -
tance test, og field acceptance test. dette betyder, at hver gang man har en specifikation af et
krav, har man også en test. når saab fandt en fejl, afhang det videre forløb af, i hvilken test
fejlen blev fundet. hvis fejlen blev fundet ved en unit test eller modul test, som blev afholdt
hver nat, ville udvikleren blive gjort bekendt med fejlen via en e-mail om morgenen, og fejlen
ville blive rettet med samme. der kunne også findes fejl ved subsystem test, system test og de
test, hvor brugeren deltog. i disse tilfælde blev fejlen registreret i saabs fejlhåndteringssystem
og efterfølgende rettet i prioriteret rækkefølge. saabs testniveauer og metoder var dokumen-
teret i saabs kvalitetssikringssystem/procedure. saabs kvalitetssikringssystem var certificeret,
og der var udført ekstern revision på det. op mod fiat-testen i februar 2007 viste saabs
kvalitetssikringssystem, at der var stor risiko for, at testen ville fejle. op til oc-testen i uge 51
i 2007 viste kvalitetssikringssystemet et stabilt system, som ville bestå testen.
han har været med til at specificere bilag 6 til kontrakten af 29. juni 2007 internt i saab. han
har blandt andet beskæftiget sig med den del, der hedder fejlkategorier. hvis noget er en f1
fejl, kan den dække over andre fejl. en f1 fejl kan f.eks. være, at systemet slet ikke starter op.
det er naturligt, at hvis systemet var startet, kunne der teoretisk set være andre fejl i systemet,
men det kan ikke testes, når systemet ikke starter. f2 fejl kunne også dække over andre fejl.
det er der ikke taget højde for i kontrakten. i tilfælde af, at systemet går ned, er det efter hans
opfattelse en f1 fejl. manglende implementering af en funktionalitet ville han kategorisere
som en f2 fejl, fordi funktionen fejler i at starte op.
han ledede system engineering gruppen i saab danmark. den arkitekturanalyse, der omtales
i referat af projektledermøde nr. 92, der blev afholdt den 23. august 2007, var en analyse, som
se-teamet udførte. se-teamet opererede med et dokument, som beskrev det, de kaldte insta-
bility suspects, hvilket er et holder-dokument, hvori de diskuterede fejlområder, så de kunne
holde fast i dem. i forbindelse med den diskussion var der også tale om at finde løsninger på
fejlene. det var det dokument, de arbejdede på henover foråret/sommeren. han husker ikke
omfanget af dokumentet.
powerpoint præsentationen ”architecture briefing” af 5. oktober 2007 er et sammenkog af de
løsninger, som de valgte at gå efter for at løse problemet. den fulde arkitekturændring ville
være fuldt på plads, når mip og bdm var med, men hoveddelen af arkitekturændringen var
på plads ved code freeze til oc.
                                              - 108 -
han kender dokumentet excel-dokumentet ”daccis 6.6 + scenario-eventlist” ”scenario 2”,
”event id 14”. ”event id 14” vedrører bdm, som skulle bruges til at administrere basisdata.
når det står under ”scenario 2”, skal det anvendes under ”scenario 2”. det forhold, at det
tidligere er nævnt, at bdm skulle testes på femtedagen, er en ændring i forhold til tidligere,
men det følger meget godt det, der skete ved præ oc. præ oc havde heller ikke bdm med i
forbindelse med scenario 2. demonstrationen af bdm skulle forløbe som en integreret del af
det eksisterende system, som var testet de fire forudgående dage. der var, som han husker det,
ikke lavet en officiel test case/scenario, som skulle danne grundlag for den demonstration af
bdm, som han har forklaret om. det krævede noter. den, der skulle demonstrere bdm, ville
have noterne. det er vedkommende fra saab, som skulle forestå demonstrationen, som ville
have udfærdiget noterne.
han var involveret i at gøre mip block 2 klar til oc. det var hans opfattelse, at det var en
anspændt situation. han fornemmede et pres. de nåede næsten i mål for så vidt angår mip
block 2. de manglede at teste den om fredagen, så de nåede ikke helt i mål. de fik det heller
ikke integreret, da testen stoppede om torsdagen. de ville være klar med daccis med block
2 ved oc-testen om fredagen. de arbejdede på det helt op til, at testen skulle begynde. og af
den årsag – netop af den årsag – at det ikke havde været igennem deres normale kvalitetssik-
ringssystem, var det planlagt til at blive kørt om fredagen.
skønsmændene carsten gomard og torben falholt har forklaret bl.a., at ”exploratory test,”
der er nævnt i rapportens afsnit u), er karakteriseret ved, at testeren inden for nogle givne
rammer selv vælger, hvad han eller hun vil teste. dette er i modsætning til ved test cases, hvor
det er præcist defineret, hvad man skal gøre som tester, og hvilket resultat man skal forvente
fra systemet.
for så vidt angår ”systematiske test”, forskriver sagens dokumenter meget fornuftigt, at der
finder en systematisk test sted før oc. en sådan test foreskrives f.eks. af dokumentet ” dac-
cis 6.6+master test plan” appendix a. en sådan systematisk test skal sikre, at opfyldelsen
af alle relevante systemkrav afprøves. typisk er testen baseret på test cases, således at den er
reproducerbar, og således at omfanget af testen kan aftales og verificeres.
en operativ test karakteriseres ved, at den baseres på virkelighedsnære scenerier eller situatio-
ner. den oc, som de har set beskrevet, ser de som en operativ test baseret på scenarier. de
                                              - 109 -
operative scenarier, der fremgår af sagens bilag aad, vil kunne danne grundlag for en opera-
tiv test. oplægget til oc, herunder opstillingen i bilag aad, giver kraftige indikationer på, at
parterne har forsøgt at arbejde sig frem mod at finde nogle relevante måder at afprøve syste-
met på i praksis. de tog i denne forbindelse det forbehold, at de er valgt, fordi de er it-faglige
og ikke soldater.
dokumentet, der omtales i skønsrapportens punkt 5.1, 1. afsnit er dokumentet ”architecture
briefing”. det er deres opfattelse, at den arkitekturændring, der er omtalt i ”architecture brie-
fing”, er klart betydelig, fordi det er en ny datamodel. der flyttes rundt på subsystemer, f.eks.
bdm og mip gateway. ændringerne omfatter sql. man går til databasen via sql, og det
betyder, at alle de steder, hvor der er data behov, skal man ind og ændre koden. det er mange
steder, og det kræver dermed en stor testindsats efter ændringerne.
det undrede dem, at man fra saabs side har introduceret dokumentet ”architecture briefing”,
på dette tidspunkt, fordi det var for sent. beslutningen burde have været implementeret inden
aftalens indgåelse. det er en arkitektændring, som ligger inden for rammerne af, hvad leve-
randøren kan beslutte. ved ”architecture briefing”, involverer saab kunden i overvejelser om,
hvordan leverancen skal frembringes. da dette er leverandørens eget ansvar, forstår skøns-
mændene ikke, at kunden blev involveret. det væsentligste ankepunkt er det sene tidspunkt,
hvorpå ændringen introduceres.
at daccis er et safety critical system, har de baseret på, at parterne er fremkommet med
positive tilkendegivelser på, at dispositioner eller fejl på systemet, kunne bringe menneskeliv i
fare. de har tidligere været med til at udvikle safety critical systemer til civilt brug – til farma-
ceutisk brug, f.eks. en pacemaker. de har ikke tidligere været med til at udvikle safety critical
systemer til militært brug.
kontrakten angiver ikke at være undergivet mil-std 498. det er deres vurdering på bag-
grund af formålet med daccis, som fremgår af hovedkontakten, at daccis er et safety
critical system.
de ikke har set kontrakten vedrørende de førerløse tog til metroen. de ved ikke positivt, at de
førerløse tog var et safety critical system. de førerløse tog til metroen er givet som et eksem-
pel på, hvor en ikke proaktiv projektstyring kan danne baggrund for, at man overser, at der i
                                             - 110 -
implementeringen kan opstå livstruende situationer. det gør efter deres vurdering ingen for-
skel, at metroens tog kører automatisk, og at der i daccis er menneskelig indblanding. det
ville ikke have gjort nogen forskel for deres vurdering, hvis de havde vidst, at parterne tidli-
gere havde indgået aftale om udvikling af safety critical systems, men at parterne ikke har
gjort det her. hvis systemet ikke er safety critical, stilles der ikke de samme strenge krav, som
de har indfortolket. forskellen fremgår eksplicit af svaret på spørgsmål a.
når det af skønserklæringen på side 4, 2. afsnit in fine, fremgår, ”eller med andre ord: i en
række tilfælde synes krav- og designdokumentation at være udarbejdet efter, at den faktiske
implementering af (del-)systemet har fundet sted” kan det godt tænkes at skyldes, at de do-
kumenter, de har set, har foreligget ved implementeringen, men at de er blevet opdateret efter-
følgende. men efter deres opfattelse er de ufuldstændige. det er endvidere snarere deres for-
nemmelse, at de er skrevet efterfølgende. det forbliver gisninger, hvordan dokumenterne er
blevet til. de har ikke spurgt parterne, om de dokumenter, der fremstår, som om de er lavet
efterfølgende, også rent faktisk er lavet efterfølgende.
for så vidt angår deres svar på spørgsmål d8, må der skulle stå cor675x i stedet for cor
676x. der er sandsynligvis tale om en skrivefejl. der står i cor675x noget vedrørende
mslt3. der kan ses bort fra sætningerne ”samtidig er der krav, der ikke relaterer sig til
mslt1-3. f.eks. indebærer cor676x krav om at kunne tegne givne symboler på skærmen” i
deres svar på spørgsmål d, punkt 8 på side 9 i skønsrapporten, da de i hvert fald er
overflødige. uden de to sætninger er besvarelsen i orden. der kan være berettiget tvivl om de
to sidste sætninger.
testen i foråret 2007 viser, at saab havde udviklet en fungerende gateway i forhold til den
daværende arkitektur. det må formodes, at saab ville kunne udvikle en fungerende gateway
med den nye arkitektur.
det er ikke dokumenteret, at eller hvordan scrum-principperne nærmere er anvendt. de har
fundet, at man i visse testrapporter omtaler sprint, som er et konkret scrum-begreb.
for så vidt angår deres besvarelse af spørgsmål f, afsnittet: ”aftalen definerer en vej hen
imod en operationel accepttest, oc, hvor der skal udveksles data med fremmed(e) c2-
                                               - 111 -
system(er)”, fremgår det af deres supplerende bemærkninger af 28. november 2012, at 3.
afsnit i svaret på spørgsmål f udgår.
for så vidt angår cor47 og cor48, så synes disse tydeligt at omhandle applikationen bdm
og dens virkemåde. cor49 omhandler visningen af de strukturer, der skabes af cor47 og
cor48. cor50 omtaler tilknytningen af et sæt symboler til disse strukturer. cor49 og
cor50 kunne vel i teorien høre hjemme andre steder end bdm, men mapningen mellem
krav og usecases i bilag 75 synes at placere opfyldelsen af disse krav i applikationen bdm.
dette valg forekommer naturligt. denne placering understøttes af henvisningen til single
bdm ud for cor49 og cor50 i bilag 3, annex d, og ligeledes er cor49 og cor50 gruppe-
ret sammen med de øvrige bdm krav. cor47 og cor48 omhandler skabelse og editering af
basisdata. cor49 vedrører visning af basisdata. cor50 er udtryk for tilknytning og grafisk
repræsentation til basisdata.
kundens medvirken og accept er vigtig ved udarbejdelsen af de relevante kravspecifikationer
og testdokumenter. omfanget af kundens medvirken er normalt aftalt på forhånd.
metodevalget er sædvanligvis et spørgsmål om parternes aftale og den faktisk fulgte praksis.
det er sædvanligvis parternes aftale. der kan være andre metoder, men det er primært parter-
nes aftale. forudsat at det, der aftales, er god it-skik, så er det, der aftales, som følges. der kan
være andre varianter, end det der er beskrevet i spørgsmål 2.4. hvem der har ansvaret for, at
det aftalte ligger inden for god skik, afhænger af parternes it-kundskabs niveau. heraf følger,
at der påhviler leverandøren et særligt ansvar for at god skik følges.
i det omfang, at testprocedurerne overholder kravene til god it-skik, er det parternes aftale, der
følges. med hensyn til den fulgte praksis vil det være dårlig it-skik ikke at følge det aftalte.
med hensyn til den faktisk fulgte praksis skal denne overholde god it-skik og være i overens-
stemmelse med det aftalte. det afhænger af parternes it-kundskab, hvem der har ansvaret for,
at god it-skik følges. der påhviler leverandøren et særligt ansvar for, at god it-skik følges.
det er torben falholts opfattelse, at kunden i dette tilfælde har haft et lavt it-kundskabsni-
veau. carsten gomard bemærkede hertil, at der er mange ting i det foreliggende materiale,
som ikke er i overensstemmelse med god it-skik, hvor man kunne forvente, at en kunde med
et højt it-kundskabsniveau ville have gjort indsigelser. de er enige i hinandens udsagn. det er
                                                - 112 -
i dette tilfælde ikke muligt for dem at sondre mellem kundens og kundens rådgivers kund-
skabsniveau, så svaret udgør en helhedsbetragtning. basis for deres vurdering er, at kunden
burde være kommet med mange flere indsigelser, og materialet burde have været meget mere
detaljeret.
det ikke er muligt at svare ja eller nej til, om det er en systemtest, hvis man tester nogle af-
talte moduler samlet. en systemtest er en sen og samlet test af et system eller en del af et sy-
stem, der udgør et sammenhængende hele. at systemtesten er sen indebærer, at den følger
efter en række andre test, eksempelvis integrationstest og modultest. at det er et samlet hele
indebærer, at det testede (del)system funktionelt og teknisk kan siges at være sammenhæn-
gende og meningsfyldt. det er en systematisk gennemgang af funktionelle og nonfunktionelle
krav.
ordet fremdriftstest bærer efter deres opfattelse ikke en selvstændig mening. forudsætningen
om, at ikke alle systemets krav skulle testes, synes ikke at have nogen betydning. det er jo
netop særdeles veldokumenteret, hvilke krav der skulle testes ved oc, nemlig shall-krav. det
var ikke et færdigt system, der blev testet ved oc. der var funktionaliteter, der først kom til
senere. dette gør ingen forskel på, at begrebet fremdriftstest ikke er selvstændigt meningsbæ-
rende. som teoretisk betragtning giver det absolut mening at gennemføre en test med det for-
mål at vurdere fremdrift i et systemudviklingsprojekt. i den konkrete situation må vurderinger
af forholdene omkring en sådan test bero på, hvad der specifikt er aftalt. det er ydermere en
forudsætning for at overholde god it-skik, at forventninger til testen og testens resultater er
veldefinerede og veldokumenterede og efterfølgende måles ud fra et funktionelt og nonfunk-
tionelt synspunkt. dette er overordnede teoretiske betragtninger. det er udtryk for en trivia-
litet. det er ikke unormalt, at kunder og leverandører aftaler testforløb. dette er helt normalt.
torben falholt bemærkede hertil, at den test, man lavede ved oc, var overflødig. den havde
ikke nogen værdi. carsten gomard bemærkede, at han ikke er enig i betragtningen om, at den
test man lavede ved oc, var overflødig, og at den ikke havde nogen værdi. torben falholt
uddybede sin betragtning om, at testen ikke havde nogen værdi, og forklarede, at den faktisk
afholdte test ingen projektmæssig værdi havde. hvis man havde afholdt testen, som den er
beskrevet i dokumenterne, havde den haft en værdi med det forbehold, at en detaljeret beskri-
velse af, hvordan kunden rent faktisk skulle verificere, at det kunden rent faktisk fik, svarede
til det, der var bestilt, ikke er angivet i dokumenterne.
                                              - 113 -
de har forholdt sig til de tre faser som projektet er opdelt i, og til den underopdeling, der er
angivet i bilag 4 til sagens bilag 1, annex a.
det er på baggrund af sætningen i punkt 2.3 i bilag aaz ”…to get an operational product
capable of use by the customer”, at de fortolker, at der er tale om et komplet system. dette
fremgår tillige af skønsrapporten på side 43. det er et system, der udgør et eller andet, der
hører sammen. der er ikke nødvendigvis tale om et færdigt system, men komplet i forhold til
oc-kravene. de læser sætningen “release 2 of the system (termed the “operational capa-
bility”) continues to stabilize the daccis core/fw and to add functionality to get an
operational product capable of use by the customer” således, at der er tale om en del af
længerevarende proces, og det er et mål at opnå et ”operational product” til oc. generelt
forekommer det dem veldefineret, hvilke krav der skulle være opfyldt til oc, og hvad
acceptkriterierne var. denne definition af oc står tydeligere end de overordnede tolkninger.
torben falholt uddybede deres konklusion på side 43 i skønsrapporten, hvor det fremgår, at
"givet, at så mange af de funktionelle krav ud over de helt grundlæggende funktionaliteter
ikke er shall-krav til oc, må det formodes, at den praktiske gavn af et “oc-system” ville
være begrænset i en krigssituation", med, at på det funktionelle aspekt, er der vægt på den
manglende replikeringsfunktion, og dens integration er vægtet tungt i et system, der er tænkt
til at indgå i internationale operationer. systemet kunne ikke replikere i forhold til
internationale systemer. internationale systemer er i betydningen at indgå i alliancer med
fremmednationer. dette vidste han, fordi man lagde testen af replikeringsfunktioner på den
sidste dag ved oc. det er hans skøn, at man ikke ønskede at replikere samtidig med, at man
lavede andre test. man frygtede at teste funktionaliteter samtidigt med de øvrige operationer.
han ved, at international replikering blev testet ved testen i greding. dette leder ham til at tro,
at der har været problemer forbundet med det pågældende subsystem og dets integration.
skønsmændene tilføjede vedrørende testparter, at mslt 1 skal testes mod fem forskellige
parter. mslt 2 skal udføres mod tre forskellige modparter, og mslt 3 skal foregå mod to
forskellige færdige systemer, og det forudsættes, at man er fysisk til stede.
det forekommer at være helt naturligt ud fra en it-faglig og sundfornufts-betragtning, at det
må forventes, at der er klarhed omkring kriterierne for testen og dens beståelse. det må forud-
sættes, at der er en eller flere modparter, men det er ikke eksplicit i de anførte dokumenter, at
det er en mip-modpart. det er deres vurdering, at deres besvarelse af spørgsmål bb er dæk-
                                             - 114 -
kende, men de tilføjede, at en præ-test giver mulighed for at øge kvaliteten af forberedelserne
til den egentlige test. oc udgør ikke en samlet systemtest, når man ser på hele systemet, dvs.
alle shall-kravene og i forhold til de 175 krav, er svaret trivielt, da ikke alle krav er shall-krav
til oc.
anbringender
parterne har gentaget deres anbringender og er fremkommet med supplerende bemærkninger i
lyset af bevisførelsen for højesteret, herunder skønserklæringen.
fmt har anført bl.a., at godkendelse af oc-milepælen forudsatte gennemførelse af en sy-
stemtest i betydningen test af et system, der blev defineret af de shall-krav i kravspecifikatio-
nen, der skulle være opfyldt ved oc. dette følger af almindelig læsning af kontrakten og un-
derstøttes af skønserklæringen. en opdelt eller fragmenteret test, dvs. en test bl.a. uden mip
og bdm, kunne ikke anses for en sådan systemtest. dette fremgår klart af skønserklæringen.
saabs anbringende om, at mip block 2 ikke kunne testes ved oc, fordi der – i modsætning til
mip block 3 – ikke var defineret krav til ”compliancy”, er forkert. kravene vedrørende ”com-
pliancy” udgør ikke en positiv beskrivelse af en funktionalitet, men en begrænsning af syste-
mets kompatibilitet, dvs. systemets evne til at oversætte og vise de informationer, der udvek-
sles med andre landes systemer via mip. det følger af kontraktens bilag 3, hvor der henvises
til annex c, at kompatibiliteten under mip block 2 skulle være baseret på de slt3 test cases,
som daccis havde bestået i februar og april 2006, hvilket ville svare til den samme grad af
kompatibilitet, som ville være gældende i tilfælde af skift til mip block 3.
oc-testen blev ikke bestået, idet testen ikke omfattede samtlige de krav, som i henhold til
kravspecifikationen skulle opfyldes ved oc. testen omfattede således ikke en test af mip og
bdm, som er to centrale funktionaliteter.
endvidere omfattede testen ikke en række yderligere shall-krav til oc, hvilket skarpt kritise-
res af skønsmændene. fmt har ikke accepteret, at disse shall-krav ikke skulle testes ved oc-
testen, og fmt har heller ikke accepteret, at de ikke-testede krav var verificeret på anden
måde. skønsmændene har i besvarelsen af spørgsmål 4.2.jj. konstateret, at alene to af de 64
krav, som saab har påstået er verificeret, kan anses for verificeret. for 40 kravs vedkom-
mende udtrykker skønsmændene, at de ikke er verificerede, mens konklusionen for de øvrige
                                              - 115 -
kravs vedkommende enten er, at verifikationen er uvis, eller at kravene er delvis eller tilsyne-
ladende verificeret. dette forhold støtter i sig selv fmt‟s anbringende om, at testen i uge 51
ikke kunne betragtes som en gennemført, endsige en bestået oc.
fmt har ikke accepteret saabs kategorisering af fejl, og kategoriseringen var ikke korrekt, jf.
skønsmændenes svar på spørgsmål 6.1. for så vidt angår de fejl, som saab har kategoriseret
som f3 fejl, fremgår det af skønsmændenes svar, at der for 17 observationers vedkommende
må ske en omklassificering til f2 fejl. lægges disse fejl til de 12 f2 fejl, som efter saabs op-
fattelse udgjorde fejlmængden, ses en samlet fejlmængde på 29 f2 fejl, dvs. en klar overskri-
delse af acceptkriterierne for oc. fmt er ikke enig i, at 8 af de 17 fejl enten ikke er i shall-
scope til oc eller er duplikater af andre fejl. selv om de pågældende fejl holdes ude af opgø-
relsen, må imidlertid mindst 9 fejl siges at være kategoriseret forkert af saab. dette bringer
antallet af f2 fejl efter saabs egen opgørelse op på 21, og dette viser i sig selv, at oc-testen
ikke blev bestået.
fmt bestrider, at der efter hensigtserklæringen var kontrakttvang, allerede fordi hensigtser-
klæringen udtrykkeligt forudsatte en forhandling mellem parterne og fastlagde konsekven-
serne af, at parterne ikke blev enige.
saab har anført bl.a., at der generelt skal ses bort fra skønserklæringen, idet den er af ringe
faglig kvalitet. skønsmændene delegerede opgaven til andre, og der er eksempler på intern
modstrid i erklæringen, faktuelle fejl, uunderbyggede og forhastede konklusioner, overskri-
delse af skønstemaets rammer, sjusk og manglende besvarelse af spørgsmål.
det fulgte af parternes aftale, at oc-testen var en fremdriftstest. der var derfor ikke belæg for
fmt‟s krav om ”integreret” test i kontrakten. skønsmændenes bedømmelse af dette spørgs-
mål er irrelevant, da den strider mod parternes aftale.
der var ikke kontraktmæssig hjemmel til at teste mip block 2 ved oc. det skyldes, at der i
kontrakten ikke var specifikke krav om mip-kompatibiliteten for mip block 2, men kun om
mip-kompabiliteten for mip block 3. for så vidt angår mip block 2 indeholdt kontrakten
alene krav til ”replication”. dermed havde fmt ikke krav på udvikling af mip-kompatibilitet
og derfor heller ikke krav på test af mip ved den operationelle oc-test i uge 51.
                                              - 116 -
parterne var enige om kategoriseringen af de fejl, der blev observeret forud for og under oc-
testen i uge 51. der var tale om 12 f2 fejl i alt, hvilket ikke berettigede til ophævelse af kon-
trakten. fejl observeret inden oc-testen skal endvidere ikke medtælles. skønsmændenes be-
mærkninger om kategoriseringen af fejl kan ikke tillægges betydning, idet skønsmændene så
bort fra parternes aftale ved vurderingen og lagde vægt på ”sædvanlige it-faglige kriterier”.
hertil kommer, at en række af de fejl, som skønsmændene havde bemærkninger til, er dupli-
kater eller falder uden for shall-scope.
det fastholdes, at parterne havde aftalt, at kravene til mip block 2 og bdm ikke skulle testes
ved oc.
parterne havde endvidere aftalt, at en række yderligere shall-krav ikke skulle testes under
selve oc-testen i uge 51, men forud herfor, og det blev også aftalt, hvordan testningen af
disse krav skulle verificeres. alle disse shall-krav blev testet og verificeret, således som par-
terne havde aftalt. angivelsen i et bilag til testrapporten om, at en række shall-krav ikke var
testet under oc-testen, er ikke udtryk for, at de ikke er blevet testet forsvarligt inden, således
som parterne havde aftalt. der må derfor også i denne henseende ses bort fra skønserklærin-
gen.
højesterets begrundelse og resultat
sagens baggrund og problemstilling
hærens materielkommando og mærsk data a/s indgik i 1998 en aftale om levering af et it-
system benævnt daccis til forsvaret. daccis står for danish army command and control
information system. fase 2 af dette system, som denne sag vedrører, blev iværksat i 2004.
leverancen blev delt op i forskellige dele benævnt daccis version 6.1, 6.2, 6.4 og 6.6. de
enkelte dele skulle testes samlet i en field acceptance test (fiat), som efter en forsinkelse
blev gennemført i februar 2007. testen viste, at daccis systemet ikke kunne fungere, idet
det var ustabilt og havde for mange fejl. på dette tidspunkt havde saab a/s, der er et datter-
selskab af saab ab, overtaget projektet fra mærsk defence a/s (tidligere mærsk data a/s),
ligesom forsvarets materieltjeneste (fmt) havde overtaget projektet fra hærens
materielkommando. forsvaret havde foreløbigt betalt i alt 130.524.826 kr. for daccis fase 2
systemet.
                                              - 117 -
fmt og saab ab indgik herefter den 29. juni 2007 en ny kontrakt om saabs levering af
daccis fase 2, version 6.1, 6.2, 6.4 og 6.6. kontraktsummen blev aftalt til 40 mio. kr. heraf
skulle 12,5 mio. kr. betales i forbindelse med fmt‟s godkendelse ved milepæl ic (initial ca-
pability), yderligere 12,5 mio. kr. i forbindelse med fmt‟s godkendelse ved milepæl oc
(operational capability) og resten ved den endelige godkendelse af systemet efter fc-testen
(full capability-testen).
efter kontraktens § 9, stk. 1, litra a, var fmt berettiget til at hæve kontrakten, ”såfremt den
aftalte dato for godkendelse af milepæl oc overskrides”. hvis fmt ophævede kontrakten ef-
ter denne bestemmelse, havde fmt krav på at få de betalte dele af omkostningerne til syste-
met tilbage fra saab, jf. § 9, stk. 2.
ved brev af 25. februar 2008 til saab ophævede fmt kontrakten og anmodede saab om at
tilbagebetale 143.024.826 kr. svarende til det beløb, som forsvaret havde betalt, dels efter den
tidligere kontrakt, dels i forbindelse med godkendelsen ved milepæl ic. fmt anførte i brevet,
at saab ikke inden for den aftalte frist havde ”gennemført milepæl oc” efter kontraktens be-
stemmelser.
sagens hovedspørgsmål er, om fmt‟s ophævelse af kontrakten var berettiget.
i bekræftende fald er parterne enige om, at fmt kan kræve det nævnte beløb på 143.024.826
kr. tilbagebetalt. parterne er endvidere enige om, at fmt i så fald kan kræve yderligere
44.075.957 kr. tilbagebetalt. beløbet svarer til, hvad fmt har betalt til saab til opfyldelse af
sø- og handelsrettens dom.
saabs forpligtelser efter kontrakten af 29. juni 2007
saab har anført, at saab og fmt havde aftalt, at saab ikke skulle levere mip block 2, og at
en række shall-krav til dette system derfor ikke skulle være opfyldt ved milepæl oc i decem-
ber 2007. disse krav skulle dermed heller ikke testes ved oc-testen, som skulle afholdes i
uge 50 i 2007, men som senere blev rykket til uge 51 i 2007. saab skulle i stedet levere mip
block 3, som skulle testes i forbindelse med fc-testen i sommeren 2008. saab har endvidere
anført, at oc-testen var en fremdriftstest, og at der ikke i kontrakten var grundlag for fmt‟s
krav om, at der skulle gennemføres en ”integreret” test ved milepæl oc.
                                               - 118 -
efter kontraktens § 2, stk. 1, skulle saab levere alt det programmel og al den dokumentation,
der var nødvendig til etablering af systemet, og som opfyldte alle krav beskrevet i kontraktens
bilag 3 eller i kontrakten i øvrigt. det fremgår af kontraktens bilag 3, punkt 2.1.7, at saab
skulle levere ”c2, database and replication to blk2 standards as achieved in bilag 3 – an-
nex c”. i en parentes er det anført, at saab “is proceeding at risk with [mip block 3] database
modifications to reduce overall programme costs”. det er i punkt 2.1.7.2 endvidere anført, at
der kræves en tillægskontrakt eller en ændring af kontrakten for at implementere ”the replica-
tion mechanism to blk3 standards”. tilsvarende er anført i kontraktens bilag 1, punkt 1.3.1
f. i og ii. i annex d til bilag 3 er det opregnet, hvilke krav systemet skulle opfylde, og det er
med et ”shall” angivet, om disse krav skulle være opfyldt ved milepæl oc. det fremgår heraf
bl.a., at tre krav vedrørende mip block 2 ”replication” (cor 600, cor 601 og cor 602)
skulle være opfyldt ved milepæl oc. efter bevisførelsen, herunder de afgivne forklaringer, er
der efter højesterets opfattelse ikke grundlag for at fastslå, at parterne – i strid med det, som
fremgår af bilag 1 og 3 – under forhandlingerne om kontrakten havde aftalt, at de nævnte krav
til mip block 2 ikke skulle være opfyldt ved milepæl oc, men at saab i stedet skulle levere
mip block 3 og først opfylde en række krav hertil i forbindelse med fc-testen i sommeren
2008. højesteret finder herefter, at saab efter kontrakten af 29. juni 2007 var forpligtet til at
opfylde shall-kravene til mip block 2 ved milepæl oc.
efter kontraktens § 10, stk. 1, skulle der finde en afprøvning sted i forbindelse med bl.a. mile-
pæl oc, og efter § 10, stk. 2, skulle fmt udstede en skriftlig godkendelse, hvis oc-testen op-
fyldte godkendelseskriterierne, som var fastsat i kontraktens bilag 6, punkt 3.5.2.b. højesteret
finder, at saabs forpligtelser ved denne test bestod i at integrere de enkelte subsystemer, såle-
des at it-systemet kunne blive testet samlet. i den forbindelse skulle der ske afprøvning af alle
shall-kravene ved milepæl oc, jf. annex d til bilag 3, herunder kravene vedrørende bdm
(cor 47, cor 48, cor 49 og cor 50) og de ovennævnte krav vedrørende mip block 2.
der henvises herved til skønserklæringens punkt 3 vedrørende testproceduren samt skøns-
mændenes forklaringer herom. det forhold, at der i relation til mip block 2 – i modsætning til
mip block 3 – ikke var fastsat udtrykkelige bestemmelser om ”compliancy”, kan efter
højesterets opfattelse ikke berettige saab til at undlade testning af shall-kravene til mip
block 2.
forløbet fra kontrakten af 29. juni 2007 til oc-testen i december 2007
                                             - 119 -
saab har anført, at saab og fmt efter kontraktens indgåelse havde aftalt, at shall-kravene
vedrørende bdm eller mip block 2 ikke skulle være opfyldt ved milepæl oc. højesteret
finder imidlertid, at saab ikke har godtgjort, at parterne havde indgået en sådan aftale. fmt
afviste således ved brev af 20. november 2007 saabs forslag af 14. november 2007 til æn-
dringer af kontrakten, hvorefter bl.a. shall-kravene til bdm og mip block 2 ikke skulle være
opfyldt ved milepæl oc. det bemærkes i øvrigt, at hverken fmt‟s projektleder eller fmt‟s
repræsentant i styregruppen efter kontrakten havde bemyndigelse til at træffe afgørelse om
begrænsning af de shall-krav, der skulle opfyldes ved milepæl oc, herunder vedrørende
bdm og mip block 2. de pågældende havde heller ikke bemyndigelse til at træffe beslutning
om levering af mip block 3, hvilket efter kontraktens bilag 1 og 3 som nævnt krævede en til-
lægskontrakt. der henvises herved til kontraktens § 16, stk. 3 og 4, § 22, stk. 1, og § 23. den
fremgangmåde, som parterne tidligere måtte have fulgt med hensyn til indgåelse af aftale om
ændring af kontrakten, skulle der fremover ses bort fra, jf. kontraktens § 33.
saab har endvidere anført, at fmt efter kontraktens indgåelse havde udvist en sådan adfærd,
at shall-kravene til bdm og mip block 2 ikke skulle være opfyldt ved milepæl oc. efter hø-
jesterets opfattelse giver bevisførelsen ikke grundlag for dette. det var først på projektleder-
mødet den 23. august 2007, at saab oplyste, at det som følge af en række forslag til arkitek-
turændringer blev nødvendigt at flytte shall-kravene vedrørende bdm fra ”oc til fc”, og at
saab ikke ville opfylde shall-kravene til mip block 2 ved milepæl oc, fordi man allerede var
gået i gang med at implementere mip block 3. hverken på dette projektledermøde eller på
styregruppemødet den 7. september 2007 gav fmt‟s repræsentanter udtryk for, at shall-kra-
vene til bdm eller mip block 2 ikke skulle være opfyldt ved milepæl oc. det kan højst læg-
ges til grund, at fmt‟s repræsentanter under disse møder lovede at undersøge disse spørgs-
mål nærmere, og ved brev af 5. oktober 2007 tilkendegav fmt over for saab, at fmt ville
følge kontrakten, og at oc-testen skulle omfatte mip block 2 og bdm. dette blev fastholdt i
det efterfølgende forløb, herunder ved fmt‟s breve af 16., 20. og 27. november 2007. det
forhold, at prætesten i uge 44 i 2007 blev afholdt uden afprøvning af bdm og mip block 2,
kan efter højesterets opfattelse ikke have givet saab en berettiget forventning om, at shall-
kravene vedrørende bdm og mip block 2 ikke skulle opfyldes ved milepæl oc. på dette
tidspunkt var saab bekendt med fmt‟s brev af 5. oktober 2007. det fremgår desuden af
skønserklæringens svar på spørgsmål 3.8.bb, at prætesten typisk er et internt anliggende for
leverandøren.
                                              - 120 -
saab har anført, at mip block 2 ikke skulle testes ved milepæl oc, da fmt ikke havde leve-
ret de ”operational scenarios”, der skulle anvendes til testen, da oc-testen skulle gennemfø-
res på dansk jord, og da saab først meget sent i forløbet blev bekendt med, hvilket reference-
system der skulle indgå i testen. højesteret finder, at saab ikke med henvisning til disse for-
hold kunne undlade testning af mip block 2 ved milepæl oc.
resultatet ved milepæl oc og ophævelsesgrundlaget
oc-testen blev som nævnt afholdt i uge 51 i 2007. saab havde planlagt at teste kravene til
bdm og mip block 2 ved en separat test sidst på ugen, men saab aflyste denne test. højeste-
ret finder det efter bevisførelsen ikke godtgjort, at aflysningen skete efter aftale med fmt.
saab testede således ikke shall-kravene vedrørende bdm eller vedrørende mip block 2 ved
milepæl oc. det bemærkes herved, at højesteret ikke kan lægge til grund, at nogle af kravene
til bdm indirekte blev afprøvet som led i den gennemførte test, jf. skønserklæringens svar på
spørgsmål 4.2.jj. højesteret lægger til grund, at shall-kravene vedrørende bdm og mip block
2 angik væsentlige funktioner ved it-systemet, og at kravene hver især ville kunne udløse
mange kritiske fejl. saab har da også i brevet af 30. november 2007 til fmt erkendt, at der
ved testning af bdm og mip block 2 på det daværende udviklingsniveau ”kan være mange
kritiske fejl, i en størrelsesorden, vi endnu ikke kender”.
saab havde ved milepæl oc fundet 12 kritiske fejl benævnt f2, og efter skønserklæringens
svar på spørgsmål 4.2.jj lægger højesteret til grund, at et betydeligt antal shall-krav, der
skulle være opfyldt ved milepæl oc, ikke blev testet behørigt.
efter kontraktens § 13 havde saab en afhjælpningsret på 60 arbejdsdage for så vidt angår fejl
og mangler konstateret ved milepæl fc eller efter den endelige aflevering af systemet. der
var ikke i kontrakten fastsat en afhjælpningsret for saab for så vidt angår fejl og mangler i
forbindelse med milepæl oc, og højesteret finder, at kontrakten må forstås således, at saab
ikke ved milepæl oc havde en afhjælpningsret i forhold til de krav, der på dette tidspunkt
skulle være opfyldt. det skal ses i lyset af, at kontrakten blev udarbejdet efter de væsentlige
mangler ved daccis fase 2, version 6.1, 6.2, 6.4 og 6.6, som blev konstateret ved fiat-te-
sten i februar 2007. det skal endvidere ses i lyset af, at milepæl oc havde til formål ved af-
prøvningen af en forholdsvis begrænset mængde krav i en midtvejstest at give fmt mulighed
for at bedømme, om der var en sådan fremdrift i projektet, at fmt kunne have tillid til, at
saab kunne præstere et tilfredsstillende resultat ved den endelige levering af it-systemet.
                                              - 121 -
der er efter højesterets opfattelse heller ikke noget i forløbet efter kontraktens indgåelse, som
kan give saab ret til en frist for afhjælpning af mangler i forbindelse med milepæl oc. i øv-
rigt havde saab i november og december 2007 oplyst, at kontraktens krav til bdm og mip
block 2 ikke kunne testes ved en oc-test før ultimo maj 2008.
på denne baggrund finder højesteret, at milepæl oc ikke var bestået, og at fmt således
havde ret til at ophæve kontrakten i henhold til § 9, stk. 1, litra a.
det er herefter ikke nødvendigt at tage stilling til, om antallet af observerede fejl ved milepæl
oc var større end det, som saab har anerkendt, jf. herved punkt 3.5 i kontraktens bilag 6 om
acceptkriterierne.
hensigtserklæringen mv.
parterne indgik den 21. december 2007 en hensigtserklæring, som skulle formaliseres i et
kontrakttillæg senest den 24. januar 2008. kontrakttillægget skulle bl.a. angå vilkårene for
mip block 2 testen, jf. nærmere hensigtserklæringens punkt 2.3. fristen blev senere forlæn-
get, således at parterne kunne fortsætte forhandlingerne, men parterne blev ikke enige om et
kontrakttillæg.
det følger af hensigtserklæringens punkt 3, at såfremt parterne ikke i ”good faith” forhandlin-
ger kan opnå enighed om et kontrakttillæg, skal den respektive parts medvirken til udarbejdel-
se af hensigtserklæringen ikke forstås eller fortolkes som et frafald af nogen rettigheder under
kontrakten eller som passivitet, navnlig i relation til kontraktens § 9. efter bevisførelsen må
det lægges til grund, at fmt ikke indgik aftale om et kontrakttillæg, fordi fmt ikke havde
tillid til, at saab inden for en overskuelig fremtid kunne identificere de krav, der skulle opfyl-
des for at forsyne daccis-systemet med en høj grad af mip block 2 kompatibilitet, og at
saab herefter kunne implementere disse krav inden for de forudsatte tidsrammer. der er såle-
des ikke grundlag for at fastslå, at fmt ikke forhandlede i ”good faith”. det forhold, at hen-
sigtserklæringen ikke resulterede i et kontrakttillæg, kan herefter ikke føre til, at fmt har
mistet sin ret til ophævelse efter kontraktens § 9.
herefter, og da det, som saab i øvrigt har anført, ikke kan føre til en anden vurdering, finder
højesteret, at fmt‟s ophævelse af kontrakten ved brevet af 25. februar 2008 var berettiget.
                                            - 122 -
konklusion
højesteret tager herefter fmt‟s påstand til følge.
sagsomkostninger
i sagsomkostninger for sø- og handelsretten og højesteret skal saab betale i alt 12.900.751
kr., hvoraf 10.000.000 kr. vedrører dækning af advokatudgift, 375.000 kr. vedrører dækning
af retsafgift, 10.000 kr. vedrører dækning af udgift til gebyr til voldgiftsinstituttet, 81.543 kr.
vedrører dækning af udgift til bistand fra software improvement group, og 2.434.208 kr. ved-
rører dækning af udgift til syn og skøn.
udgiften til advokatbistand er fastsat skønsmæssigt efter en vurdering af, hvad der kan anses
for rimeligt også under hensyn til sagens omfang og karakter samt arbejdets omfang og det
ansvar, der er forbundet med sagens førelse.
der er ikke påvist særlige forhold, som kan berettige fmt til at få godtgjort udgifterne til bi-
stand fra it-konsulentfirmaerne ifad og pdh consult, jf. højesterets kendelse i ufr 2009 s.
762.
                                     thi kendes for ret:
saab ab skal til forsvarets materieltjeneste betale 187.100.783 kr. med procesrente af
143.024.826 kr. fra den 26. marts 2008 til den 3. november 2010 og af 187.100.783 kr. fra
den 4. november 2010.
i sagsomkostninger for sø- og handelsretten og højesteret skal saab ab betale 12.900.751
kr. til forsvarets materieltjeneste.
de idømte beløb skal betales inden 14 dage efter denne højesteretsdoms afsigelse.
sagsomkostningsbeløbet forrentes efter rentelovens § 8 a.