ICSE 2018 kelionės ataskaita: 50 metų programinės įrangos inžinerijai

Dauguma visų 40 ICSE posėdžių generalinių pirmininkų ir programų pirmininkų.

Programinės įrangos inžinerijos tyrimų sričiai šiemet sukanka 50 metų; didžiausia, seniausia ir geriausia programinės įrangos inžinerijos konferencija, Tarptautinė programinės įrangos inžinerijos konferencija, yra 40 metų. Šių metų konferencija buvo puiki proga bendruomenei atsigręžti į praėjusio pusmečio tyrinėjimus ir paklausti: „Ko mes išmokome? Ką mes pamiršome? Ko mums trūksta? “Savaitę praleidau Geteborge, Švedijoje, spręsdama šį klausimą, apmąstydama daugybę įžvalgių pranešimų ir pokalbių, kurie atsakė į šiuos klausimus, bet taip pat pasidaliniau savo mintimis apie tai, kaip judėti pirmyn per dvi pakviestas derybas.

Norėdamas pradėti savo pirmąją pilną dieną, aš daviau pradinį pagrindą Kalnakasybos programinės įrangos saugyklose.

Aš pradėjau laiką ICSE, pateikdamas bendrą diskusiją ICPC 2018 ir MSR 2018 apie didžiulį tarpdisciplininio darbo ir teorijos poreikį programinės įrangos inžinerijos tyrimuose, naudodamas bendruomenes, kurios koncentruojasi į supratimą ir kasybą, kaip šių didesnių taškų pavyzdžius. Apie savo kalbėjimą rašiau ankstesniame įraše, apibendrindamas savo argumentus. Po pokalbio ir visos konferencijos metu aš užmezgiau tikrai įdomius pokalbius tiek su vyresniaisiais tyrinėtojais, kurie stengėsi suvokti, ką turiu omenyje teoriją, tiek kartu su naujaisiais doktorantais. studentai žavisi teorijos galimybėmis padaryti jų darbą efektyvesnį. Turėjau puikų grupės pokalbį su keliais CMU doktorantais apie tai, kas yra teorija, kaip ji atrodo, kaip ji gali paversti mūsų atliekamas studijas ir kaip mūsų rezultatai gali būti gilesni. Aš taip pat kalbėjausi su „Adobe Analytics“ inžinieriumi, kuris stengėsi įgyti vidinius analizės įrankių pritaikytojus. Tai buvo jaudinanti galimybė pabandyti paveikti, kaip naujos kartos tyrinėtojai ir inžinieriai įtraukia teoriją į darbą, tačiau tai privertė susimąstyti, kaip išmokyti efektyviai naudoti teoriją.

Pirmadienį dalį laiko praleidau MSR ir ICPC sesijose, klausydamasis naujausių klaidų pranešimų suvokimo, dizaino modelio supratimo ir kitų pastangų ištirti suprantamumą. Viename darbe pakartotas 121 su kodu susijusio sudėtingumo rodiklio įvertinimas, norint išsiaiškinti, ar jie koreliuoja su pačių kūrėjų suprantama suprantamumo patirtimi, nustatant, kad ilgis ir kintamieji pavadinimai kartu numato kūrėjų įvertinimus. Šiose mažesnėse konferencijose, kuriose pateikiami suprantami ir suprantami klausimai, tikrai protingai naudojami duomenys. Kaip pastebėjau pagrindiniame pranešime, jiems iš tikrųjų reikia supratimo teorijos, tačiau jų rasti modeliai yra geras šių teorijų kūrimo pagrindas.

Pirmadienio popietę aš buvau kniedęs pokalbį su Timu Menziesu apie santykinius giliųjų ir seklių modelių privalumus. Jis iš dalies sureagavo į mano pagrindinę mintį nustebęs, kad aš nepareiškiau gilesnės saugyklų kasybos bendruomenės kritikos, bet taip pat kad nepripažinau kai kurių stulbinamų paprastų, negilių modelių galios optimizuoti ir pritaikyti įvairius sprendimus programinėje įrangoje. inžinerija. Jo argumentas iš esmės buvo tas, kad kai kuriais atvejais, o gal daugeliu atvejų, mums nereikia paaiškinti, kodėl įrankiai, sistemos ar procesai veikia, jie tiesiog turi veikti. Mes išsklaidėme nesutarimus ir galiausiai padarėme išvadą, kad mums greičiausiai reikia visų rūšių gelmių modelių (nuo teorijų iki nepaaiškinamų įstatymų iki neprotingų, bet tikslių nuspėjamųjų variklių). Tokia įvairovė tikriausiai yra sveiko akademinio diskurso ženklas.

MSR banketas Geteborgo pasaulio kultūros muziejuje.

Pirmadienio vakaras vyko kasybos programinės įrangos saugyklų konferencijoje. Turėjau gausų pokalbių rinkinį su Mei Nagappan, Andy Zaidman ir Michaelu Godfrey. Kalbėjome apie viską, pradedant kadencija ir paaukštinimu, CS mokymąsi mastu, mūsų asmeninę istoriją apie mokymąsi programuoti ir mūsų, kaip vartininkų, vaidmenis mokant CS. Man tokie pokalbiai yra gilioji akademinio tinklo esmė: tai pokalbiai apie mūsų gyvenimą, mūsų idėjas ir kaip jie sąveikauja.

Abramas kalbėjo apie laipsniškos mokslo pažangos poreikį.

Antradienio rytą Abramas Hindle'as papasakojo įtakingiausią apdovanojimą už savo darbą: „Ką mums sako dideli komitetai? Didelių komitetų taksonominis tyrimas? “Svarbu šiame darbe yra tai, kad jis buvo vienas iš pirmųjų straipsnių ne tik tobulinti kasybos techniką, bet ir iš tikrųjų užduoti klausimą apie saugyklų turinį, perkeliant lauką į daugiau mokslinių klausimų apie programinę įrangą. inžinerija, ne tik kasybos technika. Man buvo įdomu, kad darbas buvo moksliškai pagrįstas: jis tvirtai tvirtino, kad pašaliniai dalykai yra svarbūs ir jų negalima ignoruoti, o dideli atsiribojantys dalyviai yra tikrai kritiniai rodikliai apie programinės įrangos evoliucijos pobūdį. Jis taip pat išskirtinai sutelkė dėmesį į išsamią įsipareigojimų turinio analizę, kuri buvo (ir vis dar yra) retas metodas atliekant bet kokius duomenų gavybos tyrimus. Abramas taip pat pateikė įtikinamą argumentą, kad dokumentų, atmestų už tuoj pat neturintį rezultatų, atmetimas žlugdo mūsų mokslą, taigi ir mūsų ateitį, ir prieštarauja tam, kas yra stipendija. Klausimų ir atsakymų metu Abramas pateikė keletą įžvalgių pastabų apie tyrimų ekonomiką ir apie tai, kaip jis gali susivokti, kokius klausimus keliame ir kokius mokslinius tyrimus leidžiame.

Per pertrauką Lutzas Precheltas man uždavė įdomų klausimą: kodėl nepaisant to, kad programinė įranga yra tokia sudėtinga, o kūrėjai nėra tokie pasirengę, ši programinė įranga vis dėlto yra kuriama, pritaikoma ir produktyviai naudojama? Akimirką apmąsčiau ir pasidalinau savo grandiozine teorija. Mano paaiškinimas buvo tas, kad programinė įranga, nepaisant to, kad jos vykdymo erdvė yra iš tikrųjų begalinė, ir kūrėjams yra be galo nesuprantama, iš tikrųjų turi tik mažą reikšmingą būsenų erdvę, kurią vartotojai naudoja praktikoje. Tai reiškia, kad nepaisant viso šio sudėtingumo, kūrėjai sugeba įgyti tik pakankamai žinių apie šią aktualią vykdymo erdvę ir užtikrinti, kad programinė įranga jiems būtų efektyvi ir tvirta. Tada, net jei programinė įranga nėra efektyvi ir tvirta, įtariu, kad vartotojai yra atsparūs daugumai nesklandumų, su kuriais susiduria, ieškodami būdų arba pakeisdami tikslus, atsižvelgiant į jų elgesį. Ši atsparumo teorija paaiškina, kodėl programinė įranga yra vertinga, nepaisant to, kad ji trapi. Tai nereiškia, kad programinės įrangos gedimai neturi jokios reikšmės: yra rimtų gedimų, ir jie dažnai kyla dėl to, kad kūrėjai neturi tikslaus supratimo, kokios sudėtingos programinės įrangos sistemos valstybinės erdvės dalys iš tikrųjų yra svarbios šioje srityje. Be to, kūrėjai dažnai neturi įrankių ar duomenų, reikalingų šioms tikslioms žinioms gauti. Be to, yra daugybė visiškai automatizuotų sistemų sudedamųjų dalių, kurias mes turime sugebėti oficialiai patikrinti, kad išvengtume rimtų tolesnių gedimų. Taip pat yra reikšmingų žmogaus „į Loop“ sumetimų, kuriems norint gauti teisingumą reikia skirti ypatingą dėmesį, ir kuriems reikia HCI metodų. Taigi, kaip atsparus trapiai programinei įrangai pasaulis, mes galime ir turime padaryti geriau.

Antradienio pietus pertraukiau, kad kniedžiu pokalbį su jaunesniuoju kolega apie doktorantų patarimus. Jis uždavė puikius klausimus, kurie man buvo puikus pagrindas apmąstyti savo praktiką. Aš daug kalbėjau apie kultūros apibrėžimą ir savo naują strategiją - parašyti integruotą dokumentą, kuris nustato lūkesčius. Aš kalbėjau apie psichologinę saugą kaip pasitikėjimo santykių su savo studentais ir savo komanda kūrimo pagrindą. Kalbėjau apie kritinį poreikį faktiškai įgyvendinti ir modeliuoti savo įmontuotame dokumente esančias normas, kad būtų sustiprinta mano laboratorijos kultūra. Aš pasidaliniau idėjomis apie studentų komandų sudarymą kartu, kad padidinčiau atskaitomybę, idėjų įvairovę ir grįžtamąjį ryšį. Aš taip pat aptariau įtampą iki kadencijos, kuri gali kilti dėl reikalingų leidinių, tačiau taip pat apie tai, ar reikia suteikti studentams erdvės mokytis, ir kaip išspręsti šias įtampas išlaikant atskirą pirmojo autoriaus tyrimų sritį. Svarbiausia, kad kolegai priminiau, kad šis mokymasis nesibaigia. Pažįstu vyresnių kolegų, kurie vis dar klausia patarimo po dešimtmečių mokymosi.

Antradienio vakarą turėjau nuostabią vakarienę su Thomasu LaToza ir Ph.D. studentas Augustas Shi, kuriame mes diskutavome apie pagrindinius ir taikomuosius programinės įrangos inžinerijos tyrimus, socialinių mokslų vaidmenį programinės įrangos inžinerijos tyrimuose ir sąžiningesnių, teoriškai pagrįstų ataskaitų apie pagrindinius šios srities techninio darbo prielaidas poreikį.

Trečiadienį „Ericsson Research“ pirmininkas Magnusas Frodigh'as atidarė pagrindinį pranešimą apie bevielį ryšį ir 5G. Jis pradėjo numatydamas greitą mūsų skaitmeninės patirties pokyčių tempą, bet ir lėtesnį tinklo infrastruktūros pokyčių tempą. Jis tvirtino, kad 5G standarto stabilumas bus visų rūšių naujoviškos IoT infrastruktūros rūšių, įskaitant realaus laiko ryšį tarp mašinų, pavyzdys. Jis gilinosi į 5G infrastruktūros ypatybes, kurios, mano manymu, buvo sausos ir dažniausiai nesvarbios programinės įrangos inžinerijai, tačiau įtikinama vizija, paslėpta pokalbio viduje, buvo neįsivaizduojamas žmonių ir mašinų sujungimo mastas, iš esmės pašalinantis vėlavimą. Magnusas teigė, kad tai žymiai palengvins naujos patirties prototipų sudarymą, nes sistemas galima sudaryti tik per mažai latentines tinklo paslaugas, o ne diegiant aparatinę įrangą.

Trečiadienio ryto pertraukėlės metu Walteris Tichy, Jamesas Herbslebas ir aš produktyviai kalbėjosi apie tai, kaip pakeisti programinės įrangos inžinerijos tyrimų bendruomenės naudojimą ir teorijos plėtrą. Pradėjome stebėdami, kaip srityje yra teorijų, jos yra tiesiog netiesioginės ir, jei jos bus aiškiai apibrėžtos, gali priversti mus permąstyti savo prielaidas ir tyrimų kryptis. Pvz., Lauke yra teorijos apie abstrakcijos galią, klaidų reikšmingumą programavimo kalbos projektavime ir apie tai, kaip veikia programa. Mes tiesiog nepaaiškiname šių teorijų. Jamesas davė pradžią ir teorijai, ir jis, ir aš abu sulaukėme šiltų atsakymų į mūsų raginimus daugiau teorijos, todėl įtariame, kad sritis yra pasirengusi mokytis. Mes svarstėme apie visuomenės švietimo būdus, įskaitant kai kurių lengvų medžiagų, skirtų dėstyti naujiems doktorantams ar suinteresuotiems fakultetams, kūrimą. Mes aptarėme galimą „Dagstuhl“ organizavimą, kad būtų sukurta ir įdiegta ši medžiaga.

Chrisas Parninas aptaria mokymo sudėtingumo pobūdį.

Likusią trečiadienio dalį praleidau lankydamasi programinės įrangos inžinerijos mokymo ir mokymo kursų sesijose (kurioms pirmininkau 2020 m., Tačiau taip pat manau, kad ji yra gana svarbi ir labai svarbi mano pomėgiams skaičiuoti švietimo srityje). Šis leidinys skelbia griežtus, apžvalginius kompiuterių švietimo tyrimus apie programinės įrangos inžineriją. Chrisas Parninas pradėjo pirmąją sesiją, kalbėdamas apie iTrust, didelės kompleksinės programinės įrangos diegimo, naudojimą programinės įrangos inžinerijai. Jis nustatė, kad studentai daug vėliau įvertino kurso gilų įsitraukimą į didelę sudėtingą sistemą, tačiau jiems viso to metu nepatiko. Darbas su senuoju kodu buvo be galo didelis. Jie pakoregavo kursą, suderindami klasės veiklą su pačiu projektu, o tai paskatino kur kas pozityvesnes nuotaikas apie kursą (kaip ir reikėjo tikėtis; studentams reikia nuoseklaus pasakojimo apie klasės veiklą, kad jie galėtų įsitraukti). Kitame pokalbyje paaiškėjo, kad aktyvus vaizdo įrašų žiūrėjimas, kurio metu besimokantieji komentuoja turinį ir komentuoja komentarus, padidina įsitraukimą į vaizdo įrašų žiūrėjimą. Kai kuriose diskusijose daugiausia dėmesio buvo skiriama laboratorijoms, akmeniniams akmenims ir kitiems patirtinio mokymosi projektams. Paprastai šie tyrimai nustatė, kad patirtinį mokymąsi iš tikrųjų sunku atlikti logistiškai, iššūkį padaryti autentišką ir labai sunku žinoti, kaip jį įvertinti. Panašu, kad norint organizuoti šį darbą mums reikia keleto patirtinio mokymosi teorijų.

Reidas Holmesas aptarė dalykus, kuriuos mokiniams patiko mokytis.

Reidas Holmesas pristatė puikų išilginį Kanados patirtinio mokymosi programos, skirtos aukšto efektyvumo informatikos studentams, studijas (bakalauro programos „Capstone“ atvirojo kodo projektai). Tyrimas atskleidė stulbinamai teigiamą patirtį, kai studentai labai vertino savo žinių pritaikymą klasėje realioms, naujoms užduotims, skirtoms realiems projektams su vartotojų bendruomene, kartu gaudami patarimus iš tikrų kūrėjų. Tam tikras šio darbo pagrindas yra tai, kaip atrenkami studentai: programa aiškiai pasirenka geriausius mokinius iš kelių institucijų, taip išvengiant daugelio mokymosi iššūkių, kurie gali kilti su mažiau pasirengusiais studentais.

Visatos lietaus miškas buvo tikrai drėgnas!

Trečiadienio vakaro priėmimas vyko „Universeum“ - gamtos mokslų muziejuje, kuriame pilna gyvūnų, žuvų ir gausu drėgno lietaus miško. Tai buvo išties įdomus priėmimo kontekstas, nes užuot buvusi didelėje atviroje erdvėje rengiamų pokalbių erdvei, ji buvo kupina interaktyvių eksponatų, įtraukiančių dalyvius į žaidimą ir tyrinėjimą. Eksponatai nebuvo ypač kviečiantys ar įtikinantys, tačiau jie buvo pakankamai geri, kad paskatino įvairius įdomius pokalbius, kurių mes, ko gero, nebūtume turėję kitaip. Kalbėjausi su lankytojais apie „Gila“ monstrus, barzdaskutes, medūzas, programinės įrangos eksponatų programinės įrangos priežiūrą ir daugybę cinizmo, įsiliejusių į akademinį informatiką.

Ketvirtadienio rytą pusryčiaujau su Brendan Murphy, Laurie Williams ir UW Ph.D. studentas Calvinas Loncaricas mūsų viešbučio pusryčių kambaryje. Mums teko plati diskusija apie du didžiuosius iššūkius, kurie man brangūs: formalių sistemų, pavyzdžiui, kalbų programavimo, suderinimas su žmogiškosiomis ir socialinėmis sistemomis ir statistinių sistemų, pavyzdžiui, mašininio mokymosi, suderinimas su žmogaus ir socialinėmis sistemomis. Mano manymu, tai yra du svarbiausi didieji kompiuterių mokslo iššūkiai, ir vis dėlto dauguma kompiuterių mokslų žmonių jų nepaiso. Brendanas turėjo daug ką pasakyti apie duomenų analizės ir mašinų mokymosi suvienodinimo su realiais projektais sudėtingumą, Laurie daug kalbėjo apie tuos pačius iššūkius, susijusius su saugumo apskaitos kūrimu programinės įrangos kūrime, o Calvinas svarstė šias problemas savo paties duomenų struktūros sintezės darbe, kur atvirojo klausimai yra sintezuoto kodo suprantamumo ir jo specifikacijos kalbos išmokimo samprotavimai.

Fredas Brooksas jaunesnysis, aiškindamas istoriją.

Buvo du ketvirtadienio ryto pagrindiniai pranešimai. Seminaro „Mitinis žmogaus mėnuo apie programinės įrangos projektų valdymą“ autorius Fredas Brooksas, jaunesnysis, pateikia retrospektyvą. Fredas kalbėjo apie programų, programinės įrangos, programinės įrangos sistemų, programinės įrangos produktų evoliuciją. Tada programinės įrangos inžineriją jis apibrėžė kaip programinės įrangos gaminimo discipliną. Jis papasakojo apie svarbiausias idėjas programinės įrangos inžinerijos istorijoje, įskaitant von Neumanno programas kaip duomenų ir aukšto lygio programavimo kalbas, tokias kaip COBOL ir FORTRAN. Septintajame dešimtmetyje programinės įrangos krizė (didelių sistemų kūrimo iššūkis) paskatino idėją apie programinės įrangos inžineriją kaip inžineriją. Didelis pripažinimas buvo tai, kad projekto sudėtingumas augo netiesiškai. Daug dėl to buvo prisidėta prie sistemų, pavyzdžiui, Tomo Kilburno interaktyvaus derinimo ir Fernando Corbato laiko paskirstymo operacinės sistemos, duomenų bazių sistemų, Roberto Floydo ir Tony Hoare'o oficialaus patikrinimo idėjų bei Simulos objekto orientacijos. Aštuntajame dešimtmetyje slėpėsi Deivido Parno informacija, Barbaros Liskovo abstraktūs duomenų tipai, Harlano Millso ir Niklauso Wirtho laipsniškas patikslinimas, Michaelio Fagano kodų patikrinimai ir programinės įrangos projektų valdymas. Barry Boehmas taip pat uždavė klausimus apie reikalavimus ir reikalavimų patvirtinimą. Jis labai rekomendavo Grady Booch'o ACM žiniatinklio seminarą apie programinės įrangos inžinerijos istoriją ir Barry Boehm'o indėlį per visą gyvenimą.

Margaret Hamilton dalijasi istorijomis apie pagrindinių mainų programavimą.

Antrojo ketvirtadienio ryto pagrindinė pranešėja buvo Margaret Hamilton, įsivaizdavusi frazę „programinės įrangos inžinerija“. Ji buvo matematikos studentė, kai nusprendė stažuotis MIT kuriant LGP30 orų programinę įrangą ir domėtis programine įranga, o galiausiai sukūrė „Apollo“. programinės įrangos sistemos, leidusios JAV nusileisti Mėnulyje. Jos pokalbis „Kalba kaip programinės įrangos inžinierius“ kalbėjo apie dideles problemas: sunku integruotis, vystytis, sunku pakartotinai naudoti, o programinė įranga sugenda. Ji paklausė, kodėl per 50 metų mes padarėme tiek mažai pažangos? Ji teigė, kad yra buvę. Anksčiau nebuvo lauko; dabar yra. Mes apibrėžėme terminus. Tačiau realybė yra ta, kad programinės įrangos inžinerija yra aiškiai žmogiškas, aiškiai socialus ir intelektualus darbas, ir mes vis dar nesužavime daugumos šių veiksnių. Ji pateikė pagrindinių HCI iššūkių, susijusių su interaktyvių žmonių sistemų kūrimu, programinės įrangos, klaidų ir jų atkūrimo pavyzdžių, pavyzdžių ir kaip jie buvo svarbiausi nusileidžiant Mėnuliui. Ji suprato, kad sistemos yra asinchroninės, paskirstytos ir atsižvelgiant į įvykius, ir kad programinės įrangos rašymui naudojamos kalbos turėtų tai atspindėti. Ji tai suderino su diskusija apie planavimo poreikį per architektūrą naudojant daugkartinius ir patikimus modelius. Aš didžiuojuosi, kad klausimuose ir atsakymuose pamačiau bendruomenės pripažinimą istorija, jos vertingumą ir kai kurių didžiausių srities idėjų tolimas ištakas.

Miryung Kim iš UCLA pasakoja apie patrauklų duomenų mokslo vaidmenų tyrimą.

Ketvirtadienį pirmininkavau sesijai pavadinimu „Studijuojame programinės įrangos inžinierių“, kurioje buvo atlikti keturi patrauklūs empiriniai tyrimai, įskaitant du žurnalus - pirmąsias USE publikacijas. Pirmasis, „Kūrėjų poreikių supratimas dėl kalbos nuvertinimo“ (autorius - Anand Sawant, TU Delft), atrado daug naudingų tendencijų, susijusių su nusidėvėjimo funkcijų naudojimu ir netinkamu naudojimu, nustatant nuvertėjimo datų, sunkumų perspėjimų ir didesnės įvairovės poreikių svarbą. įspėjamųjų tipų. Antrajame darbe „Dėl programuotojų derinimo dekreto“ (autorius - Moritz Beller, TU Delftas) išsiaiškinta, kad praktikoje derinimo įrankiai naudojami retai, kad „printf derinimo“ išlieka dominuojanti, o žinios apie derinimo priemones yra gana geros žemas. Pirmajame sesijos žurnale „Programos supratimo matavimas: plataus masto lauko tyrimas su profesionalais“ (Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing ir Shanping Li) paaiškėjo, kad kūrėjai didžiąją laiko dalį praleidžia suvokdami. kodą, kad jie supranta kodą naudodamiesi interneto naršyklėmis ir redaktoriais, ir kuo daugiau patirties turi kūrėjas, tuo mažiau laiko jis skiria supratimui. Paskutiniame pranešimo sesijoje „Duomenų mokslininkai programinės įrangos komandose: šiuolaikinė situacija ir iššūkiai“ (Miryung Kim, Thomas Zimmermann, Robertas DeLine'as ir Andrew Begelis) atlikta 793 profesionalių duomenų mokslininkų apklausa ir rastas tikrai įdomus 9 tipų duomenų mokslo vaidmenų rinkinys: daugiamatiai, duomenų evangelistai, duomenų rengėjai, duomenų formuotojai, platformų kūrėjai, įvairaus laipsnio stebėtojai ir įžvalgos dalyviai, kurie interpretavo duomenis ir panaudojo juos sprendimams priimti. Ši turtinga dekonstrukcija ar skirtingi vaidmenys atrodo išties galingi ir informuojant apie duomenų mokslą.

Paskutinė ketvirtadienio sesija buvo 50-ies metų programinės įrangos inžinerijos šventė. Brianas Randellis 1968 m. Pateikė retrospektyvą apie pirmąją programinės įrangos inžineriją. Brianas papasakojo apie tai, kiek dar nebuvo išrastas kompiuteris; nėra interneto, nėra tinklų, nėra pakartotinio naudojimo. Ir vis dėlto visos problemos buvo susijusios: testavimas, teisingumas, valdymas ir kt. Brianas atskyrė programavimą ir programinės įrangos inžineriją apibrėždamas programinės įrangos inžineriją kaip „kelių asmenų programų, skirtų daugeliui žmonių, kūrimą“ (jis neprisimena to sakydamas). , bet Dovydas Parnas tvirtina, kad jis tai padarė). Jis padarė išvadą, kad laukas išaugo daugiau nei jis subrendo, abejodamas, ar mes pakankamai toli, kad būtume vadinami inžinerijos disciplina, ir paskatinome bendruomenę išrasti dar vieną kalbą ir dar vieną techniką.

Briano pokalbį stebėjo keturių originalių 1968 m. Konferencijos dalyvių grupė. Vienas jų aptartas klausimas buvo tai, ko jie apgailestauja per pastaruosius penkiasdešimt metų. Jie iškėlė nepakankamą dėmesį reikalavimų inžinerijai, nepakankamą dėmesį dezinformacijai, nepakankamą dėmesį programinės įrangos priežiūrai. Šeštajame dešimtmetyje jie buvo nusivylę ir dabar yra nusivylę. Kai kurie komisijos nariai buvo sujaudinti dėl oficialių metodų, tačiau nusivylė, kad jie nebuvo priimti. Jie taip pat nusivylė tuo, kiek mažai sužinojome, kaip vadovautis dizaino sprendimais, susijusiais su programinės įrangos savybėmis. Tačiau iš esmės atrodė, kad nėra sutarimo dėl to, ar viskas pagerėjo, ar ne. Mes tikrai statome sudėtingesnius dalykus, bet ar jie geresni, tinkamesni?

Žuvis, dangtelio juosta ir skaidrių demonstracija

Ketvirtadienio vakaro banketai vyko laivų statykloje ir buvo keista veiklos pastilė. Vyko banketų stiliaus maistas, lauko scena su daktaru. studentai dainavo roko muziką, o švedų grupė - vakarienės metu dainavo 90-ųjų ir 2000-ųjų pop dainas, o šeimininkė šventė programinės įrangos inžinerijos bendruomenę ir kvietė įvairius konferencijų organizatorius į sceną pasakyti ačiū. Vakarienės metu skaidrių demonstracija buvo žaidžiama su visokiais savavališkais programinės įrangos produktų logotipais iš skaičiavimo istorijos, retkarčiais rodomas vaizdo įrašas su programinės įrangos inžinerijos šviestuvų interviu. Tai buvo juokinga, nesusiejanti ir dezorientuojanti, ypač kai būrys dalyvių išvarė renginio vietos kampą šokti.

Programinės įrangos inžinerijos šokių vakarėlis!Robertas McClure'as, vienas iš 1968 m. NATO konferencijos dalyvių.

Penktadienio rytą radau vieną iš ketvirtadienio retrospektyvos komisijos narių Robertą McClure'ą, sėdintį per pertrauką, todėl nusprendžiau pradėti pokalbį. Jis buvo vienas iš originalių 1968 m. Konferencijos dalyvių ir aktyvus pramonės minčių lyderis, pasisakantis už pažangą. Paklausiau jo, kas pasikeitė per 50 metų, kas ne pasikeitė ir kokia yra jo pažangos samprata. Mes turėjome įdomų, platų pokalbį daugeliu pagrindinių programinės įrangos inžinerijos klausimų. Jis pradėjo aptardamas kai kuriuos kritinius skirtumus tarp to, ką programinė įranga sukuria (tam reikia suprasti problemą ir jos kontekstą), inžinerinio projektavimo (kuriam reikia atidžiai nurodyti sprendimą) ir inžinerijos (kuri yra grynas tos specifikacijos įgyvendinimas). Robertas palygino programinės įrangos inžineriją su kitomis inžinerijos disciplinomis, todėl paklausiau jo, kokie, jo manymu, yra esminiai skirtumai, jei tokių yra. Jis teigė, kad tai buvo laipsnio klausimas. Spėliojau, kad kritinis skirtumas yra tas, kokiu laipsniu dizaineris ar inžinierius dizaineris gali būti tikras, kad supranta problemą ar specifikaciją; supratimas apie svetainę, kurioje statote tiltą, priklauso nuo gamtos mokslų, kurie yra nuspėjami tokiu mastu, kuris neatitinka žmogiškųjų, socialinių ir organizacinių sistemų, kurioms paprastai yra sukurta programinė įranga. Šis pasitikėjimo stoka sukuria prototipų kūrimo, grįžtamojo ryšio ir evoliucijos poreikį, kuris nėra toks būtinas kitoms inžinerijos disciplinoms (ir taip pat nėra įmanomas). Mes taip pat kalbėjome apie išsilavinimą, būtiną visiems šiems įgūdžiams, ir apie pokyčių, kurių jis tikėjosi, tempą. Per pastaruosius 50 metų jis tikėjosi daug daugiau pokyčių, nei pastebėjo, ir spėliojo, kad žmogaus prigimtis yra daug atsparesnė pokyčiams, nei kada nors tikėjo. Aš pasiūliau, kad tai gali būti tiesiog nesėkmė veiksmingesniame švietime, kartu su sparčiu kūrėjų skaičiaus padidėjimu nuo maždaug 10 000 1968 m. Iki 30 mln. 2018 m. Jis paskatino mane susitvarkyti savo lūkesčius dėl pokyčių; Aš jam pasakiau, kad būdamas etatiniu profesoriumi aš būsiu jame ateinančius 40 metų ir būsiu kantrus.

Brianas Randellis, programinės įrangos inžinerijos istorikas.

Atsitiktinai taip pat radau Brianą Randellį, ketvirtadienio 50 metų programinės įrangos inžinerijos pagrindinį kalbėtoją, sėdintį vieną. Paklausiau jo, kodėl, jo manymu, 2-oji NATO konferencija taip nuvylė ir koks, jo manymu, buvo jos poveikis ateinantiems programinės įrangos inžinerijos tyrimų ir praktikos dešimtmečiams. Jis teigė, kad didelė problema buvo ta, kad antraisiais metais buvo padalijama po du. Pirma, kai kurie žmonės įsivaizdavo pasaulį, kuriame galėtume atsiųsti visiškai nemokamą programinę įrangą, o kiti manė, kad toks dalykas nėra įmanomas ir turėtume planuoti. Antruoju aspektu, kai kurie žmonės domėjosi programinės įrangos inžinerijos problemos dekonstravimu, o kiti domėjosi įrankiais, metodais ir kitais sprendimais, kurie, jų manymu, galėtų ją pagerinti. Dalyviai, suskirstyti pagal šias linijas, tiesiog negalėjo suspėti. Idealistai ir realistai nežinojo, kaip bendradarbiauti, o į problemą orientuoti žmonės per daug laiko kritikuodavo į sprendimus orientuotų žmonių sprendimus, o į sprendimus orientuoti žmonės buvo atsparūs atsiliepimams. Aš pasiūliau, kad daugelis šių skyrių vis dar egzistuoja šiuolaikiniuose programinės įrangos inžinerijos tyrimuose, ir padėkojau Brianui už tai, kad jis padėjo nušviesti šių skyrių istorinę kilmę.

Ivaras atidaro savo pagrindinį pasakojimą.

Ivaras Jacobsonas, pagrindinis UML ir „Rational Unified Process“ bendradarbis, pasakė kalbą pavadinimu „50 metų programinės įrangos inžinerijai, o kas dabar?“. Jis pradėjo anekdotą apie vieną iš savo pirmųjų programinės įrangos inžinerijos projektų, kur turėjo prisipažinti. , jis nieko nežinojo apie programinės įrangos inžineriją. Ir vis dėlto jis vis dar vadovavo vienam sėkmingiausių švedų produktų istorijoje. Galiausiai programinės įrangos sėkmės interpretaciją lemia verslo modeliai ir kūrėjai, o ne programinė įranga, o ne procesas. Jo požiūris yra toks, kad po 50 metų tai vis dar yra amatas, o ne inžinerijos disciplina. Tiesą sakant, istorijoje jis tvirtina, kad mus kur kas labiau skatina mada nei mokslas: orientacija į objektus, UML, CMMI, Agile ir kas bus toliau, buvo ir bus visa mada. Ivaro argumentas buvo tas, kad visi metodų karai buvo blaškymas. Tikroji problema, pasak Ivaro, yra ta, kad metodai yra iš tikrųjų praktikos kompozicijos, o metodai yra monolitiniai ir įstrigę guru saugomuose kalėjimuose. Ivaro nuomone, tai nesubrendusi ir kvaila.

Jo rekomendacija buvo sutelkti dėmesį į bendrą metodų pagrindą, modifikuoti metodus ir laisvą metodų praktiką. Jis papasakojo apie standartų įstaigą, numatančią praktikos, kuriai būdingi tam tikri sėkmės kriterijai, ir darbo produktų, gaunamų iš veiklos, vertinamos pagal šiuos sėkmės kriterijus, sąvoką. Tačiau jo esmė ta, kad visa tai reikalauja, kad kūrėjai turėtų kompetencijos visais šiais dalykais. Sėkmės kriterijai priklauso nuo klientų poreikių, gaminamo sprendimo ir jo pasiekimo komandos. Jis pateikė dar keletą detalių apie valstybes, kurias išgyvena jo modelis. Tai, ką jis aprašė, skamba kaip mokslinė proceso teorija ir iš šios teorijos išplaukiantis proceso idėjų rinkinys; ką nors išbandyti ir patobulinti, o ne pagal Evangeliją. Galų gale jis iš tikrųjų pavadino ją aprašomąja teorija ir paragino tyrėjus toliau plėtoti ją į nuspėjamąją ir aiškinamąją teoriją.

Iškart po Ivaro pokalbio aš pasakiau savo ICSE „įtakingiausio popieriaus apdovanojimą“. Apdovanojimų sesijos viduryje galėjau pasakyti, kad žmonės pavargę ir pasiruošę savaitės pabaigai. Mano pokalbis buvo niūrus, atspindintis, tačiau padrąsinantis, ir nors tyla po pokalbio buvo kurtinanti, „Twitter“ pašnekovas buvo žvalus, rodantis bendruomenę, kuri tikrai tiki ir vertina tai, ką turėjau pasakyti, ir yra alkanas patarimų dėl kaip tai padaryti.

Andreas pradeda pokalbį apie apdovanojimą

Andreas Zeller kalbėjo iškart po manęs, gavęs SIGSOFT tyrimų apdovanojimą. Jis papasakojo tris istorijas apie savo karjerą, visas dėmesys buvo sutelktas į poveikį. Pirmasis pasakojimas buvo apie pirmąjį jo projektą ir pristatymą, kuriame jis prisidėjo prie problemos sprendimo. Nusivylęs atsiliepimais, jis vėl sukūrė dėmesį sutelkdamas dėmesį į GNU DDD derintuvą, kuris turėjo realų praktinį poveikį. Pirmoji jo epifanija buvo ta, kad tikrų problemų suradimas buvo labai svarbus, tačiau kartu ir puikus būdas paveikti. Antroji jo istorija buvo apie paprastumą. Kažkas vienoje konferencijoje pasipiktino, kad jo idėja dėl deltų derinimo buvo tokia paprasta. Tai privedė prie apsimetėlių sindromo, intelekto nepilnavertiškumo jausmo. Tačiau laikui bėgant jis suprato, kad paprastumas yra galia; sudėtingumas buvo nesėkmė. Paskutinė jo istorija buvo apie darbą, kurį jis pradėjo kartu su Tomu Zimmermannu kasybos programinės įrangos saugyklose. Jis pastebėjo, kad baimės dėl ankstyvo jų darbo rezultatų tiesiog neturi reikšmės, nes tai buvo faktas, kad darbas buvo naujas. Naujovės yra susijusios su tamsiomis neišsamiai, bet svarbiomis pasaulio dalimis. Galiausiai Andreasas teigė, kad vienintelis dalykas, kuris iš tikrųjų yra svarbus, yra poveikis. Jis baigėsi įkvepiančiu raginimu tęsti mūsų svajones ir išlikti.

Atsisveikinant su Geteborgu, sudėtinga apibendrinti viską, ko išmokau šių metų ICSE. Bet vis tiek pabandykime:

  • Galiausiai visi esame šioje bendruomenėje, norėdami patobulinti programinę įrangą. Sutelkime dėmesį į tai, o ne į trumpalaikę metriką.
  • Mums reikia didesnių idėjų, greičiausiai teorijų pavidalu, kurios mus nukreiptų ir nukreiptų mūsų įtaką.
  • Turime galvoti apie tinkamumą, o ne apie skelbimą, kad pasiektume aukščiau nurodytus tikslus.
  • Mes nekreipiame dėmesio į žmogiškuosius programinės įrangos inžinerijos veiksnius.

Tai yra pamokos, kurias kiekvienas mūsų bendruomenės narys turi įtraukti į vidų. Jau praėjo 50 metų, kai supratome jų svarbą ir tik pradedame juos vertinti rimtai.