Denne artikkelen undersøker behovet i klasserommet for å lære elevene å programmere uten behov for normalt utsatte teknikker, om ikke med nye forslag som får studenten til å lære på en mer didaktisk måte, med en mer personlig dialog med læreren og på denne måten få ham til å føle seg komfortabel.
Det hjelper også studenten til å bli mer kompetent og finner derfor effektivitet i prosessene relatert til programvareutvikling med denne implementerte metodikken. Betingelser Indeks - XP, programmering, UML, java.
En av vanskelighetene som oppstår innen utdanning i klasserommet på et programmeringskurs og spesielt i Popayán University Foundation; Det er den knappe opplevelsen og disponeringen av studenter til å jobbe eller studere for å lære de fleste programmeringskurs på universitetene.
De fleste studenter forbereder seg for øyeblikket, det er derfor det ikke bare programvaresamfunnet det er bekymret, men også fagmiljøet, siden metodikken deres er for tykk og motstandsdyktig, og de har begynt å jobbe med utvikling av teknikker for å øke studentdeltakelsen.
I stedet for å bruke studieplaner som bare får studenten til å bekymre seg for hvordan han skal vinne et fag, men egentlig med denne metodikken forbereder de dem ikke på utfordringene i dagliglivet, siden det er der kunnskapen virkelig blir brukt.
Mange metoder har blitt brukt av lærere i undervisning i programmering, som:
| En av vanskene ved valg av kurslærebok;
• programvareutvikling legges vekt på • Valg av programmeringsmiljø; lærere til produktet som skal skaffes, og fokuserer ikke på • Variasjoner i undervisningsmetoder; teknikkene og metodene som foreslår kvalitetsløsninger. Variasjoner i oppgaver. Under hensyntagen til det ovennevnte ved behandling Ekstrem programmering eller eXtreme programmering for å introdusere undervisning i et språk på (XP) er en tilnærming til software engineering Programmering, som Java, må vi ta inn formulert av Kent Beck, forfatter av den første boken på grunn av at det er stort mangfold i ferdigheter, fag, ekstrem programmering forklart: omfavne hastighet i læring og egnethet til Endring (1999). Det er den mest fremtredende av studentprosessene, det er derfor oppmerksomheten rundt smidig programvareutvikling. vanskeligheter en person står overfor kan ikke være Det er en smidig metodikk fokusert på å styrke de som lett blir behandlet i en klasse der det er mange mellommenneskelige forhold som en nøkkel til suksess hos elever, på en slik måte at lærere må søke programvareutvikling, fremme arbeid på forskjellige alternative måter som hjelper å studenter som et team, som bryr seg om læring. utviklere og fremme et godt arbeidsmiljø. |
Valget av det første programmeringsspråket;
XP er basert på kontinuerlig tilbakemelding mellom klienten og utviklingsteamet, flytende kommunikasjon mellom alle deltakere, enkelhet i implementerte løsninger og mot til å møte endringer.
XP er definert som spesielt egnet for prosjekter med svært skiftende og upresise krav, og hvor det er en høy teknisk risiko.
Husk at XP er basert på det nevnte, det er der det kan være lønnsomt å gi effektive og effektive løsninger på designmetoder for utdanning; siden de tradisjonelle ikke har vært nyttige så langt.
I dette scenariet oppstår spørsmålet: Hvordan bruke agile metodikk XP (Extreme Programming) for vanlige utdanningsmetodologier i programmering? Det er nettopp i dette scenariet hvor vårt arbeid foreslår en undervisningsmetodikk ved bruk av XP (Extreme Programming), for programmering av studenter ved FUP. For å gjøre dette utfører vi først en diagnose av programmeringskapasiteten til studentene, deretter foreslår vi en smidig XP-metodikk for undervisning i programmering. Denne metodikken brukes hos studentene ved Popayán University Foundation.
I dette arbeidet undersøker vi bruken av den smidige XP-metodikken i utviklingen av pedagogiske aktiviteter som letter læring med det formål å formalisere et rammeverk der faser og aktiviteter gjør det mulig å definere livssykluser som metodisk sikrer deres kvalitet. Vi kommer til å bruke denne rammen for å foreslå praksis som kan gjøre undervisningen mer smidig. Derfor er det ment å fremme en ny metodikk ved University Foundation of Popayán for studenter i systemteknikk, spesielt innen Java-programmering, ved bruk av ekstrem programmering som et verktøy i programvareutviklingsprosesser, siden det reduserer analyse, utvikling og gjennomføringstid. På denne måten forbedres kvaliteten på programvaren produsert av studenter i klasserommet.
II. KUNSTENS STAT
A. Tradisjonell metodikk
ACM og IEEE-CS har i felleskap foreslått et dokument kalt Software Engineering 2004 (SE2004), som gir anbefalinger for grunnutdanning innen programvareteknikk. Dette dokumentet, Software Engineering Education Knowledge (SEEK), inneholder en liste over emner som alle nyutdannede bør vite, samt en rekke retningslinjer for implementering av læreplaner og et sett med foreslåtte kurs. Kunnskapen og ferdighetene som en programvareingeniør skal ha ved endt utdanning, kan oppsummeres i følgende liste:
- Demonstrere mestring av et nødvendig sett med kunnskaper og ferdigheter for å begynne din profesjonelle praksis som programvareingeniør. Arbeid både individuelt og i team for å utvikle og generere kjørbar programvare. Avstem motstridende mål, finn akseptable kompromisser innen kostnad, tid, kunnskapsbegrensninger., eksisterende systemer og organisasjoner Design egnede løsninger i ett eller flere applikasjonsdomener, ved bruk av tekniske tilnærminger som integrerer etiske, sosiale, juridiske og økonomiske aspekter Demonstrerer forståelse og kunne anvende aktuelle teorier, modeller og teknikker som gir grunnlag for identifisering av problemer og analyse, programvaredesign, utvikling, implementering og verifisering Forhandle, jobbe effektivt, ta ledelse når det er nødvendig,og kommunisere godt med ulike interessenter i et typisk programvareutviklingsmiljø Lær nye modeller, teknikker og teknologier når de dukker opp og setter pris på behovet for kontinuerlig profesjonell utvikling.
Under hensyntagen til det nevnte er det vist i tabell nr. 1, den tradisjonelle metodikken som vanligvis brukes til å undervise i programmering til systemingeniørstudenter:
| Tabell 1. Tradisjonell metodikk (Hvordan programmering læres) |
| 1. Objekter og klasser, parametere. |
| 2. Forstå definisjon av klasser: definisjon av klasser, felt, |
| konstruktører, metoder. |
| Samhandling med objekter: objekter som skaper objekter, flere konstruktører. |
| Gruppere objekter i samlinger av fleksible størrelser (ArrayList), samlinger av fast størrelse (Array). |
| Bruker klassebiblioteker |
| Testing og feilsøking |
| Designe klasser: samhørighet, kodeduplisering, gjenbruk av kode |
| Strukturer med arv |
| polymorfisme |
| Abstrakte klasser og grensesnitt. |
| Statiske metoder - hovedmetoden. |
| læreren, som i dette tilfellet utfører klientens funksjoner. |
| Planlegging: I dette tilfellet er læreren den som skal planlegge kravene og i hvilken rekkefølge de skal jobbes med og kontinuerlig gjennomgås. |
| Kundetest: I dette tilfellet foreslår læreren at testene skal valideres hvis miniversjonene fungerer. |
| Små versjoner: På grunn av applikasjonsområdet for forslaget, vil små og nyttige versjoner av programvare bli arbeidet med. |
| Enkel design: Du blir bedt om å utvikle miniversjonene på en enklest mulig måte. |
| Par programmerere: Arbeidsgrupper på to studenter per arbeidsstasjon vil bli dannet og de roterer en gang for hver laboratorieøkt, på en slik måte at koden er kjent av alle medlemmene i prosjektet. |
| Designforbedring: Rotasjonen av par etter klassetimer, gjør det mulig å forbedre programvaredesignen. |
| Kontinuerlig integrasjon: Integrer kontinuerlig miniversjonene i prosjektet. |
| Koden tilhører alle: Alle parene blir rotert og fungerer i miniversjonene av de andre gruppene, og koden vil være eiendommen til alle samarbeidspartnerne til prosjektet. |
| Kodingsstandarder: Oppretthold en felles utviklingsstil (som skal defineres). |
| Metaforer: Hver del av programmet vil bli definert med navn slik at de blir forstått av alle medlemmene i teamet. |
| Bærekraftig rytme: Det vil fungere i alle klassetimer, uten avbrudd. |
| Tabell 2. XP-regler og deres anvendelse i forslaget |
| Fullt team: Fullt lag vil bli dannet av klasserom, inkludert |
B. Ekstrem XP-programmering
Agile programvareutviklingsmetoder fokuserer på den menneskelige faktoren, så vel som på programvareproduktet, som er basert på små versjoner, noe som gir mer verdi for individet, samarbeidsarbeid og programvareutvikling sammen med klienten., som hele tiden kan overvåke programvareproduktet gjennom utviklingen. Ekstrem programmering som sådan er den mest populære smidige programvareutviklingsmetodikken i dag, ettersom den søker å endre det tradisjonelle konseptet med programvareutvikling, der oppmerksomheten rettes mot å etablere alle programvarekravene i begynnelsen av prosjektet på en måte at det ikke krever senere endringer,ved en ny tilnærming der fleksibiliteten til programvaren søkes for modifikasjoner når de anses som nødvendige og at de ikke påvirker prosjektet. Tabell nr. 2 er vist nedenfor, som inneholder reglene for hvilken ekstrem programmering er basert på og hvordan de kan brukes i vår forskning.
Nedenfor er noen av de relaterte verkene som har ledet oss mot vår forskning.
Programvareselskapet Role Model Software har implementert en alternativ modell for å trene programvareutviklere kalt "Software Studio" som i sin struktur ligner det middelalderske håndverksverkstedet, der nybegynnere utviklerne lærer av masterutviklere. Læreren løser problemer ved å verbalisere ekspertløsningsstrategier høyt, mens elevene observerer, lærer og påtar seg mindre oppgaver, og lar læreren være fri til å ta på seg de vanskeligere oppgavene. Etter hvert blir lærlingene utsatt for vanskeligere problemer, og lærer på denne måten sammen med sine jevnaldrende de forskjellige aspektene av deres handel. Denne modellen favoriserer akselerert læring av ekspertferdigheter fra læreren, noe som forbedrer læring fra å lære av ens feil.Ferdighetene som elevene tilegner seg er basert på verdiene, prinsippene og praksisene til XP, som gir en naturlig kontekst for å lære alle aspektene nevnt ovenfor.
Artikkelen vår tar noen strategier fra denne studien, men uten å gi studentene mindre oppgaver og deretter utsette dem for vanskeligere problemer, i dette tilfellet er vi fokusert på å følge en trinnvis metodikk med spesifikke punkter som gjør studenten mer interessert i å lære og utvikle programvare.
Fred Brooks i sin berømte artikkel "No Silver Bullet" som tilsvarer på språket uttrykt som en tilfeldig kompleksitet til en programvare:
- Kommunikasjon: En programvareingeniør må bruke en stor del av tiden sin på å kommunisere med ulike typer samtalepartnere, måtte være i stand til å tilpasse graden av abstraksjon og tekniskhet i samtalene sine etter det språket som motparten dominerer, og han må også kunne lytte til og tolke behovene uttrykt av dem, behov som ofte vil ha betydning for utformingen og implementeringen av programvaresystemet som skal utvikles. Evne til å jobbe i et team: All programvareteknikk utføres i team,
dette er imidlertid noe studentene ikke får opplæring på. Programvareingeniører skiller seg vanligvis ut for individuelle egenskaper, det er grunnen til at XP (Pair Programming) fører personen til å danne et team, dette gjør at folk som blir vant til å utføre individuelle ("heroiske") handlinger, ikke De er bare i stand til å generere produktene (dokumenter, design, moduler) som de er ansvarlige for, men kan også finne et sted i et arbeidsteam.
Teknisk institutt i Lund, i Sverige der to filialer ble utført, en i begynnelsen av graden, like etter de grunnleggende programmeringsgrenene, der teamarbeid blir introdusert gjennom XP, og et annet påfølgende fordypningskurs, rettet mot trening av trenere, hvis praktiske del nettopp er å dirigere lagene det første året. I disse linjene læres ikke bare "kanoniske" XP-praksiser (opprinnelig definert av Kent Beck), men mange andre fremgangsmåter som er foreslått av utviklermiljøet som har tatt i bruk XP, og som utfyller de som er foreslått av Beck.
Studentenes forhåndsoppfatninger versus XP
- Studentene liker ikke ekstraarbeidet som er involvert i tradisjonelle metodologier: Studentene kvier seg ofte for arbeidsintensive prosesser for å produsere mellomgjenstander som detaljert dokumentasjon, spesifikasjoner og design osv., Og det er grunnen til at XP legger vekt på Å produsere funksjonell kode over å generere dokumentasjon gjør det mer attraktivt for studentene. Studentene har en tendens til å presse seg selv for å oppnå størst mulig funksjonalitet, selv om det ikke kreves av dem: Når det gjelder Lund tekniske institutt, er studenter styrt av regelen om "fast tid", det vil si Studentene trenger bare å ha den forhåndsbestemte tiden definert for å gjennomføre kursprosjektene, denne gangen kan de brukes både til å produsere kode og for å lære av gjort feil.i det som utgjør en utmerket tolkning av praksisen "40 timer i uken". Studentene er optimistiske om hvordan koden deres fungerer: Dette fenomenet indikerer at studentene tror at koden deres vil fungere riktig uten behov for å programmere tester. Dette har to forklaringer: Å tro at den interaktive gjennomgangen som følge av feilsøking er tilstrekkelig til å validere de aktuelle sakene, og uvitenhet om problemene som evalueringen av koden kan forårsake. Studentene foretrekker å jobbe i store trinn: Forestillingen om å jobbe i små trinn er motstridende for mange, fordi det antas at hvis du har en komplett løsning designet, er dette bortkastet tid. Denne fordommeren er basert på ideen om at designet er 100% riktig (noe som aldri er tilfelle),og at når et design er definert, vil det ikke endre seg. Ubehag i møte med endringer i krav: Studentene oppfører seg ofte med ubehag i møte med endringer i naturlige krav i alle programvareprosjekter, og tenker ofte at dette vil innebære mer arbeid, og dermed ignorerer den smidige styringsmodellen med variabelt omfang.
I "forfatterne foreslår å utvikle programvare gjennom programmering, ved å bruke den smidige XP-metodikken og på denne måten er det læring; raskt, effektivt og med kunnskap brukt i hverdagen. Dette arbeidet støtter studien vår, da det viser behovet hos studentene for en annen, mer didaktisk metodikk som forplikter studenten til å produsere effektivt og fremfor alt for å bevisstgjøre behovet for å jobbe som et team.
III. GENERELT MÅL
Foreslå en undervisningsmetodikk ved bruk av XP (Extreme Programming), for programmering av studenter på FUP.
- SPESIFIKKE MÅL For å utføre en diagnose av programmeringskapasiteten til studentene.
Implementere den smidige metodikken XP vs tradisjonell metodikk med studentene ved Popayán University Foundation.
V. FORSLAG
I forslaget ble det utviklet en studie som inneholdt følgende informasjon:
Først ble en diagnose stilt, deretter ble metoden brukt og til slutt en tilfredshetsundersøkelse.
Diagnose
For å stille diagnosen ble en undersøkelse benyttet, designet med et spørreskjema med 37 lukkede spørsmål med ett enkelt svarvalg, som ble brukt i fysisk format og de grunnleggende konseptene for Java-programmering, databaser og UML, som inneholdt grunnleggende spørsmål om kunnskapen fra tidligere semestre. Det ble gjennomført til studentene ved University Foundation of Popayán, for Systems Engineering-programmet til VIII dag- og natt-semester. Undersøkelsen produserte til sammen 20 undersøkte studenter, dette er et representativt utvalg av disse studentene.
Statistisk formel
For å beregne resultatene som ble oppnådd i hver av undersøkelsene, ble følgende formel brukt:
v = (x * y) / z
x: Totalt korrekte svar y: Prosentandel z: Totalt spørsmål (hver av undersøkelsene)
- Totalt svar kommer fra den totale summen av hvert av de riktige svarene. Prosentandelen vil alltid være 100% i hver undersøkelse. Totalt spørsmål kommer fra å multiplisere summen av dem med totalen av undersøkelsene som er utført.
- Databaseundersøkelse:
| Riktige svar | 50.4166667 |
| Feil svar | 49.5833333 |
Illustrasjon 1: Resultat oppnådde databaser
I henhold til resultatene oppnådd fra denne grafen der kunnskap om databaser blir evaluert, er det mulig å observere at alle de evaluerte indikatorene er 50% for både riktige og uriktige spørsmål.
- Java-programmeringsundersøkelse:
| Riktige svar | 59.25 |
| Feil svar | 41 |
Illustrasjon 2: Java-resultater oppnådd
I forhold til Java-programmeringsundersøkelsen ble et nøyaktighetsnivå på 59% presentert med hensyn til feil spørsmål evaluert med 41%.
- UML-undersøkelse:
| Riktige svar | 56 | |
| Feil svar | 44 |
Illustrasjon 3: UML-resultater oppnådd
Det er observert at 56% av deltakerne svarte på UML grunnleggende kunnskapsvurderingsundersøkelse med middels nøyaktighetsnivå.
- Generell undersøkelse:
| Totalt svar | 100% | Totalt spørsmål | |||
| 414 | 100 | 740 | |||
| 327 | 100 | 740 | |||
| Generelt nøyaktig | 55.94594595 | ||||
| Generelt feil | 44.18918919 | ||||
Illustrasjon 4: Resultat oppnådd generell undersøkelse
Generelt er indikatorene for riktige spørsmål til den anvendte metodikken over 56%, det er observert at kunnskapen som studentene har tilegnet seg i sine universitetsstudier, gir et lavt akseptnivå.
Forskningshypotese
Hypotesene som skal testes i denne forskningen er:
- Effektiv replikering av et smidig utviklingsmiljø (XP) er mulig i FUP-systemteknikk-klasser: FUP- systemtekniske studenter kan få erfaring som er representativ for smidige metodologier - spesielt Ekstrem programmering - innenfor rammen, ressursene og tiden for et semester av graden. Å utsette elever for autentisk utvikling i et smidig miljø genererer god læring om smidige metoder: Takket være arten av smidige utviklingsmiljøer, som er rettet mot å fremme kontinuerlig læring hos medlemmene for å oppnå større produktivitet, når de trofast gjengis i sammenheng med et systemteknikkurs, oppnås gode resultater i læringen av studentene.
Nedenfor presenteres forslaget fra de foregående hypotesene.
Tabell 3
| Hypotese | Forslag |
| Effektiv replikering av et smidig utviklingsmiljø (XP) er mulig i FUP systemteknikklasser. | En instruksjonsdesign som setter opp en klasse av
Systemteknikk i et arbeidsmiljø representant for XP |
| Å utsette studentene for autentisk utvikling i et smidig miljø genererer god læring om smidige metoder | En konseptualisering av hvordan XP organiserer programvareutviklingsmiljøet for å oppnå harmonisering av de forskjellige komponentene og dermed oppnå en kontinuerlig konstruksjon av kunnskap og verdi. En evaluerende modell basert på den forrige konseptualiseringen, som skal tjene til å måle læringen til studentene som instruksjonsmodellen som er nevnt ovenfor, blir brukt. |
Bilde 1
Evalueringssystem
Evalueringen som foreslås for å gjennomføre XP-metodikken er fokusert på å bli anvendt i løpet av semesteret, den har 3 komponenter og er delt inn i 3 roller med deres respektive planlegging som kan forbedre kvaliteten på undervisningen i studentene på FUP.
komponenter:
Resultatevaluering (Vekt: 30%):
Som ethvert programvareutviklingskurs, bør ikke målet om å oppnå tilfredsstillende programvare på fastsatte tidspunkter og tidsfrister overses. Det er basert på kvaliteten på programvareproduktet som er utviklet, og tar i betraktning kundens mening.
Prosessevaluering (Vekting: 40%):
Denne evalueringen vurderer følgende aspekter:
- Gjennomføring av oppgaver: punktlighet og oppfyllelse av kravene som stilles av læreren Samevaluering: Evaluering mottatt av studenten fra sine jevnaldrende, i henhold til deres engasjement, ansvar og teamarbeidskapasitet.
Eksperimentell evaluering (Vekting: 30%): I gruppe- og individuell form skal studentene reflektere og evaluere metodikken som er lært, med tanke på:
- Bruksområde: graden av bruk og relativ vanskelighet som man har opplevd i hver praksis. Brukbarhet: hvor nyttige ble praksisene undervist.
For å bestå emnet, må studenten oppnå en karakter som er lik eller større enn 4,0 i de tre spesifiserte komponentene. I tilfelle studenten ikke oppnår de 4 i noen av disse emnene, vil han / hun måtte gjøre tilleggsarbeid.
Roller:
Verdsettende illustrasjon 6 kan vi observere rollene som er foreslått for å utføre XP-metodikken, der elevene deltar, læreren som igjen vil være klienten som har kunnskapen om problemet og er den som forklarer, veileder bruken av metodens praksis, prinsipper og verdier.
Illustrasjon 5: Roller Kursplanlegging:
Kursformatet er økter med 4 timers klasseromsarbeid per uke og 8 timer autonomt forskningsarbeid. Det er en lærer og studenter som tidligere er påmeldt faglig, og arbeidet vil bli delt inn i grupper på 2 personer. Som det fremgår av tabell nr. 8, er kurset strukturert i to store seksjoner, som vil bli beskrevet nedenfor. Teoretisk fase (3 til 4 økter)
I denne fasen samarbeider hele kurset for å utforske i detalj hva XP er. Den første sesjonen er diktert av professoren, som presenterer det grunnleggende som ga opphav til smidige metodologier og XP spesielt, og gjør en kort gjennomgang av den moderne teknologiteknikken og understreker årsakene som motiverer fremveksten av dette nye perspektivet. til programvareutvikling.
Tidlig involvering av studenter oppnås på følgende måter:
- De skal diskutere i en gruppe og deretter presentere sin tidligere kunnskap om XPS. En "ekstrem time" eller simulering blir utført for å kunne forstå på en enklere måte hvordan XP-styringsmodellen fungerer. Studenter gjennomfører debatter om XP-praksis i påfølgende økter, helst å velge temaene presentert selv
Tabell 4
| aktiviteter | |||
| I klassetimer | Utenom klassen | ||
| 0 | Innføring i kurset | Rapport om forkunnskaper | |
| en | Innledende presentasjoner | Meningsrapporter og tvil antydet fra det som ble presentert i klassen | |
| to | |||
| 3 | Prosjektutvikling ved bruk av XP |
Testgenerering av XP og applikasjonen Undersøkelser med spesifikke løsninger med hensyn til utvikling eller metodikk. Generering av rapport om programvareutvikling og XP-applikasjon i informasjonssystemet. |
|
| 4 | |||
| 5 | |||
| 6 | |||
| 7 | |||
| 8 | |||
| 9 | |||
| 10 | |||
| elleve | |||
| 12 | |||
| 1. 3 | |||
| 14 | |||
| Endelig presentasjon - gruppe | Rapporter generasjon om anvendelsen av XP i prosjektet og dets
fremtidig projeksjon |
Praktisk fase
I denne fasen begynner den "miniatyriserte" versjonen av XP å bli praktisert, noe som begrenser utviklingen til varigheten av økten (4 timer). Den første økten starter med et "Planning game", der omfanget av iterasjonen er definert.
Deretter har hver økt en lignende struktur, som presentert i tabell 5:
| Øyeblikk | Beskrivelse |
|
Forberedelse av arbeidsmiljøet. |
Den består av å gjøre klasserommet på kurset om til et arbeidsfremmende arbeidsmiljø. Spesielt: Installasjon av utstyr (det som er nødvendig for å undervise i klassen) med nettverkstilkobling.
Oppsett av jobber: |
| uke. Når det gjelder studenter som gikk glipp av økten, er utviklingsoppgavene definert som de må returnere arbeidstiden som kollegene allerede har bidratt med. | |
|
Økt og tilbake til normalitet i rommet |
Arbeidsmiljøet som er satt opp i rommet fjernes: bordene, stolene og datamaskinene blir returnert til normal stilling, brettene er helt rene og informasjonen lagres av studentene slik at den kan brukes av neste klasse. |
| endre arrangementet av bord og stoler for å lette parprogrammering og rotasjon i teamet.
Studentene har på tavlen i rommet brukerhistoriene som de må fullføre |
|
|
Stand-up-møte |
Som XP-praksis tilsier, møtes teamet på beina og fanger opp statusen deres. Deretter blir målene for økten koordinert og distribuert. |
|
Utvikling |
Dette er tiden for selve utviklingsarbeidet. Dynamikken i arbeidet skjer akkurat som i XP: hver utvikler har meldt seg på for å utvikle en spesifikk oppgave, som han ber om hjelp av en kollega til å jobbe par. I tvil om brukerens historie eller metodiske tvil, bør de konsultere læreren.
Brukerhistorier blir også presentert for læreren for godkjenning i henhold til funksjonstestene som tidligere er definert med ham i planleggingsspillet. Ved å respektere prinsippet om tilpasningsevne til endring, kan læreren når som helst endre brukerhistorier. Når det gjelder pauser, i løpet av den teoretiske fasen, er det læreren som definerer en pause midt i økten, derimot, i denne fasen oppfordres elevene til å ta en (rimelig) pause hver gang de har oppnådd prestasjoner, eller som en måte å rydde opp hvis du har blitt fast i et problem for lenge. |
|
Endelig refleksjon og tildeling av lekser for uken |
På slutten av økten oppmuntrer læreren til å avslutte arbeidet, slik at hele kurset kan evaluere hva som har blitt lært i løpet av økten. Dette gjøres i en åpen dialog moderert av læreren.
Som et resultat av refleksjon definerer læreren sammen med hvert team forskningsoppgavene for |
| Tabell 6 | |
| Utmerket | 98 |
| Akseptabel | 57 |
| dårlig | 5 |
| TOTALE SPØRSMÅL | 160 |
Bilde 2
Undersøkelse av hypotese tilfredshet: Resultatene som ble oppnådd presenteres i henhold til hypotesen som er foreslått i vår forskning med studentene ved Popayán University Foundation, VIII Semester of Systems Engineering.
Illustrasjon 5: Målingsresultater oppnådd
Tilfredshet Hypotese
Av de 160 spørsmålene i alt, godkjente 98 av disse spørsmålene som var svart av studentene ved Popayán University Foundation undersøkelsen og hypotesen om forslaget.
VI. KONKLUSJON
Som antydet i begynnelsen av denne forskningen, var denne artikkelen designet for å gjenspeile så nært som mulig et mye mer smidig undervisningsmiljø innen programmering, og spesielt XP. Uformell observasjon av artikkelens undersøkelser viste at studentene satte pris på opplevelsen, og at det ble oppnådd ganske positive resultater fra studentene som deltok i den. Alt det ovennevnte ga opphav til forslaget til denne forskningen, som er beskrevet i kapittel V.
REFERANSER
- Kuljis, "Orientering av undervisningen i en introduksjonsobjektorientert programmering for å oppfylle læringsmålet", presentert på 26. Int. Konf. Informasjonsteknologiske grensesnitt ITI 2004, Cavtat, Kroatia, 7.-10. Juni 2004. Aubin, Verónica Blautzik, Leonardo Dejan, Gustavo Forbedringer i programmeringslæringsprosessen ved bruk av metodologier fra programvarebransjen. No.1. 2011. pp.1.Gabriela Salazar Bermúdez, Challenges of the Software Engineering Course Revista Educación en Ingeniería ISSN 1900-8260 januar til juni 2012, bind 7, nr. 13, pp. 32-43 • © 2012 ACOFI. Talbott, N., Auer, K., "Lærling i et programvarestudio: en gammel og ny modell for utdanning", Educators Symposium, OOPSLA 2000, Minneapolis, Minnesota, USA, 15. til 19. oktober 2000. pp. 49-51 Brooks, Fred. "Ingen sølvkule:Essence and Accidents of Software Engineering ”, Computer, bind 20, nr. 4 (april 1987): 10-19. Hedin, G., Bendix, L., Magnusson, B.,“ Teaching Software Development using Extreme Programming ”i "Book of Scandinavian Pedagogy of Programming Network" på: https://issuu.com/univida8/docs/revista-conciencia_-2015/191, pp. 586-593, 2003. Hedin, G., Bendix, L., Magnusson, B., "Introducing Software Engineering ved hjelp av ekstrem programmering" Fortsettelser av den 25. internasjonale konferansen om software engineering, pp. 586-593, 2003. Williams, L., Upchurch, R. "Extreme Programming For Software Engineering Education?" 31. Årlige Frontiers in Education Conference, 2001. Alfonso og Botia, en Iterativ og smidig prosessmodell for undervisning i programvareteknikk, Forløp av den 18. konferansen om programvareingeniørutdanning og -trening, (CSEET'05)April 2005. pp. 9-16Kent Beck Planning Extreme programmering https://www.researchgate.net/publication/4140018_An_Iterative_and_Agile_Process_Model_for_Teaching_Software_Engineering, 12. oktober 2000, s.160.Patricio Letelier og Mª Carmen Penadés, Agile Methodology for Software Development Program (e), Polytechnic University of Valencia (UPV). No.1. 12. nov 2003. s. 7.L. Ph.D. og MCP Ph.D., "Agile Methodology for Software Development: eXtreme Programming (XP)." 12. november 2003 s. 1-59 Xinogalos, et al., "Re-designing a OOP course based on BlueJ," presentert på den syvende internasjonale konferansen om Advanced Learning Technologies (ICALT'07), 2007.nett / publikasjon / 4140018_An_Iterativ_og_Agile_Process_Model_for_Teaching_Software_Engineering, 12. oktober 2000, s.160.Patricio Letelier og Mª Carmen Penadés, Agile Methodology for Software Development: eXtreme Programming (XP), Polytechnic University of Valencia (UPV) No.1. 12. nov 2003. s. 7.L. Ph.D. og MCP Ph.D., "Agile Methodology for Software Development: eXtreme Programming (XP)." 12. november 2003 s. 1-59 Xinogalos, et al., "Re-designing a OOP course based on BlueJ," presentert på den syvende internasjonale konferansen for Advanced Learning Technologies (ICALT'07), 2007.nett / publikasjon / 4140018_An_Iterativ_og_Agile_Process_Model_for_Teaching_Software_Engineering, 12. oktober 2000, s.160.Patricio Letelier og Mª Carmen Penadés, Agile metoder for programvareutvikling: eXtreme Programming (XP), Polytechnic University of Valencia (UPV) No.1. 12. nov 2003. s. 7.L. Ph.D. og MCP Ph.D., "Agile Methodology for Software Development: eXtreme Programming (XP)." 12. november 2003 s. 1-59 Xinogalos, et al., "Re-designing a OOP course based on BlueJ," presentert på den syvende internasjonale konferansen om Advanced Learning Technologies (ICALT'07), 2007.D., "Agile metodologier for programvareutvikling: eXtreme Programming (XP)." 12. november 2003 s. 1-59 Xinogalos, et al., "Re-designing a OOP course based on BlueJ," presentert på den syvende internasjonale konferansen om Advanced Learning Technologies (ICALT'07), 2007.D., "Agile metodologier for programvareutvikling: eXtreme Programming (XP)." 12. november 2003 s. 1-59 Xinogalos, et al., "Re-designing a OOP course based on BlueJ," presentert på den syvende internasjonale konferansen om Advanced Learning Technologies (ICALT'07), 2007.
