Autor: Hussein

Ülesanded

KiirlLiinki loomise peamised ülesanded:

1. Andmebaaside loomine ja pilveühenduse loomine
2. Disain
3. Arendus
4. Testimine ja viimistlemine

Mida me täpselt teeme:

Meil on ressursid:

X T (Hussein Tahmazov) – tööde juht

Maksim Tsikvasvili – CEO

Need on meie ülesanded, mida me panname:

Andmebaasis ja disainis:

Siin kavandate, kuidas ja kuhu andmed salvestatakse ning kuidas rakendus nendega suhtleb.

Arenduses, testimises ja viimistlises:

• Arendus: Siin kirjutate koodi ja loote rakenduse põhifunktsioonid nagu linkide lühendamine ja kuvamine.
• Testimine ja viimistlus: Siin kontrollite, kas rakendus töötab õigesti, parandate vead ja teete kasutajaliidese lõplikult valmis.

Töö progress:

Kui palju on juba tehtud ja kui palju on veel teha:

Siin on prioriteetide jaotus (jah, kõik on keskmise tähtsusega):

See on foorum, ülesanded on seal loetletud:

Ka viimase aja tegevust on näha – saad vaadata, mis just lisati:

KiirLink SWOT analüüs

Tarkvaraarenduse elutsükkel (SDLC) on struktureeritud raamistik, mida organisatsioonid kasutavad kvaliteetse tarkvara kavandamiseks, arendamiseks ja testimiseks. See defineerib kogu tarkvara tootmisprotsessi alates esialgsest ideest kuni lõpliku juurutamise ja hoolduseni. SDLC peamine eesmärk on luua tarkvara, mis vastab või ületab kliendi ootusi, valmib planeeritud ajal ja eelarve piires ning on tõhusalt hooldatav.

Tüüpiline SDLC koosneb seitsmest põhietapist:

1. Planeerimine ja nõuete analüüs: Projekti ulatuse, teostatavuse ja vajalike ressursside määratlemine.
2. Nõuete määratlemine: Funktsionaalsete ja mittefunktsionaalsete nõuete dokumenteerimine tarkvara nõuete spetsifikatsioonis (SRS).
3. Arhitektuuri projekteerimine: Tehnilise eskiisi loomine, mis sisaldab süsteemi üldist arhitektuuri ja üksikasjalikku loogikat.
4. Arendus (kodeerimine): Etapp, kus tarkvara tegelikult valmis kirjutatakse.
5. Testimine: Vigade leidmine ja parandamine, et tagada vastavus nõuetele.
6. Juurutamine: Tarkvara vabastamine lõppkasutajatele.
7. Hooldus: Jooksev vigade parandamine, uuendamine ja jõudluse optimeerimine.

Erinevad mudelid on vajalikud, kuna projektide vajadused on väga erinevad. Valik sõltub sellistest teguritest nagu nõuete stabiilsus, riskitase, projekti suurus ja turule jõudmise aeg. Näiteks turvakatsetusi nõudev lennujuhtimissüsteem eeldab ranget V-mudelit, samas kui idufirma, mis alles otsib oma kohta turul, vajab Agile’i pakutavat paindlikkust ja kiiret tagasisidet. Sobiva mudeli puudumine võib viia kaootilise arendusprotsessi, eelarve ületamise või vigase toodeni.

SDLC mudelite võrdlustabel

Analüüs

• Milline mudel on parim väikese projekti jaoks? Väikeste projektide jaoks on sobivaim V-mudel, eeldusel et nõuded on stabiilsed. Samuti võib lihtsate projektide puhul kasutada Waterfall-mudelit, kus etapid võivad kattuda. Allikate kohaselt ei sobi iteratiivne ja spiraalmudel väikestele projektidele, kuna nende jagamine väikesteks osadeks on keeruline ja kulukas.
• Milline mudel on parim suurettevõtte jaoks? Suurettevõtetele sobivad mitmed mudelid sõltuvalt projekti iseloomust: Waterfall on kasulik suurte ja keeruliste projektide puhul, kus nõuded on fikseeritud. Samas on iteratiivne mudel parem suurte ja missioonikriitiliste projektide jaoks, kuna see võimaldab paralleelset arendust ja varajasi tulemusi. Spiraalmudel on loodud spetsiaalselt suuremahuliste ja keeruliste süsteemide jaoks, kus riskide analüüs on kriitilise tähtsusega.
• Milline mudel on parim kiiresti muutuvate nõuetega projekti jaoks? Kiiresti muutuvate nõuete puhul on parim valik Agile, kuna see on loodud prioritiseerima paindlikkust ja kiiret reageerimist. Agile tervitab nõuete muutumist isegi arenduse hilises etapis. Ka spiraalmudel on hea kandidaat, kui muudatusi võib vaja minna igal ajal, kuna see on oma olemuselt iteratiivne ja keskendub riskidele. Iteratiivne mudel toetab küll muutusi paremini kui kosemudel, kuid see on vähem paindlik kui Agile.

Mõttekaart

Kontrollküsimustik

e) Kontrollküsimustik

Valikvastustega küsimused (MCQ):

1. Milline mudel on tuntud kui “Verifitseerimise ja Valideerimise” mudel? a) Agile b) Koskmudel c) V-mudel d) Spiraalmudel
2. Mida tähendab “Sprint” Agile-metoodikas? a) Vigade parandamise etapp b) 1–4 nädala pikkune töötsükkel c) Kiire koosolek d) Kliendi esitlus
3. Milline on spiraalmudeli peamine fookus? a) Kiirus b) Dokumentatsioon c) Riskihaldus d) Madal hind
4. Koskmudelis algab testimine tavaliselt: a) Paralleelselt disainiga b) Enne arendust c) Pärast arenduse lõppu d) Iga nädal
5. Milline dokument on SDLC-s “arendusmeeskonna piibel”? a) Projektigraafik b) SRS (Software Requirement Specification) c) Testiplaan d) Eelarvearuanne

Avatud küsimused:

1. Selgitage, miks on vigade leidmine koskmudelis kulukam kui V-mudelis või Agile-is.
2. Kirjeldage spiraalmudeli nelja peamist faasi.
3. Millised on Agile-metoodika suurimad riskid seoses projekti planeerimisega?

Esitlus

Created using FlowPaper Flipbook Maker ↗

Esitlus

Aruteluküsimused klassis

1. Kas on olukordi, kus vana kooli koskmudel on tegelikult parem kui kaasaegne Agile? Tooge näiteid.
2. Kui te arendaksite tarkvara südamestimulaatorile, millise mudeli valiksite ja miks?
3. Agile rõhutab inimeste ja suhtluse olulisust protsesside asemel. Kas see võib suurtes ettevõtetes tekitada probleeme?
4. Kuidas mõjutab tehisintellekti ja automatiseerimise levik traditsioonilisi SDLC mudeleid (nt DevSecOps kontekstis)?
5. Miks on kliendi pidev kaasatus (Agile) mõnikord keeruline teostada reaalsetes äritingimustes?

Isiklik refleksioon

Selle ülesande täitmine andis mulle selge ülevaate, et tarkvaraarendus ei ole ainult koodi kirjutamine, vaid põhjalikult planeeritud protsess. Mind üllatas kõige rohkem Spiraalmudeli keerukus ja see, kui oluline on tegelikult riskide maandamine suurprojektide puhul. Edaspidi oskan paremini hinnata, miks mõni projekt ebaõnnestub – tihti on põhjuseks lihtsalt valesti valitud arendusmudel.

Kasutatud allikad

Artikkel: Agile vs. Waterfall | Pros, Cons, and Key Differences

Veebiallikas: Principles behind the Agile Manifesto

Veebileht: Tutorials Point: SDLC – Iterative Model

Veebiallikas: GeeksforGeeks: Software Development Life Cycle (SDLC)

Veebileht: Wikipedia: Software development process

Veebileht: Guru99: Spiral Model: When to Use? Advantages and Disadvantages

Veebileht: Guru99: V-Model in Software Testing

Tabel: Responsive vs Adaptive Web Design

Koodi näited

Responsive (CSS näide): Üks disain, mis muutub sujuvalt.

/* Põhistiil (Desktop) */
.container {
  width: 100%;
  display: flex;
}

/* Mobiilivaade - elemendid lähevad üksteise alla */
@media screen and (max-width: 768px) {
  .container {
    flex-direction: column;
  }
}

Adaptive (Kontseptuaalne näide): Erinevad fikseeritud laiused vastavalt seadmele (tihti lahendatakse see ka JavaScripti või eraldi CSS failidega).

/* Fikseeritud laius mobiilile */
@media screen and (max-width: 480px) {
  .container {
    width: 320px; /* Kindel laius */
    margin: 0 auto;
  }
}

/* Fikseeritud laius tahvlile */
@media screen and (min-width: 481px) and (max-width: 1024px) {
  .container {
    width: 760px; /* Kindel laius */
    margin: 0 auto;
  }
}

Kokkuvõte (Minu arvamus)

Minu hinnangul on Responsive Web Design (RWD) tänapäeval parem valik enamike veebilehtede jaoks.

• Põhjendus: Google eelistab responsive disaini (SEO sõbralikkus). See on haldamise mõttes lihtsam, kuna on ainult üks koodibaas, mida uuendada. Adaptive disain on õigustatud vaid väga spetsiifiliste ja keerukate rakenduste puhul, kus mobiilikogemus peab drastiliselt erinema arvutikogemusest (nt pangarakendused või keerukad e-poed). Tavalise kodulehe jaoks on Responsive paindlikum ja tulevikukindlam (future-proof).

Kuidas parandada index.html (Responsive muutmine)

Et muuta oma index.html responsive (kohanduvaks), pead tegema kaks asja:

1. Lisama HTML faili päisesse (<head> sisse) viewport meta tagi.
2. Kasutama CSS-is Media Queries reegleid.

Kui sul on kood GitHubis, anna mulle repositooriumi nimi ja ma saan teha sulle Pull Requesti parandustega. Kui mitte, siis siin on juhis, mida pead faili lisama:

1. Lisa see rida <head> siltide vahele:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Ilma selleta kuvab telefon veebilehte nagu väikest arvutiekraani (tekst on kribukirjas).

2. Lisa CSS faili (või <style> sisse) reeglid väikestele ekraanidele:

/* Näide: Muudame menüü vertikaalseks ja pildid paindlikuks */

/* Pildid ei tohi kunagi olla laiemad kui ekraan */
img {
  max-width: 100%;
  height: auto;
}

/* Mobiilivaade (ekraanid kitsamad kui 600px) */
@media screen and (max-width: 600px) {
  /* Peida suur menüü või tee see vertikaalseks */
  nav ul {
    flex-direction: column;
    padding: 0;
  }
  
  nav li {
    margin-bottom: 10px;
    text-align: center;
  }

  /* Tekstisuuruse kohandamine loetavamaks */
  body {
    font-size: 18px;
  }
}