højesterets dom

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.

1. 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
2. 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.
3. 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).
4. 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).
5. 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
6. c)og
7. 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.
8. 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.
9. 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.
10. g)(ad appellantens spørgsmål 1.7) skønsmanden bedes forudsætte, at daccisog mip block 2 ikke er specificeret samtidig, men derimod (
11. i)at daccis er blevet udviklet si- den 1998 efter nationale standarder, (
12. 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
13. 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.
14. 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.
15. 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.
16. 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
17. f)til
18. 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
19. 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.
20. 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
21. a)alternativt ud fra den udviklingsmodel for daccis, der kan udledes af de fremlagte bilag svaret til
22. 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.
23. 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‟
24. 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.
25. 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.
26. 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
27. c)og
28. 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.
29. 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.
30. 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(
31. 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.
32. 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