Ghidul dumneavoastră cuprinzător pentru dezvoltarea software-ului All Things

Publicat: 2020-08-13

Cât de asemănătoare sunt un etaj de producție din fabrică și un birou de dezvoltatori de software?

Imaginează-ți o cameră plină de programatori care tastează cod în computerele lor. Ce se întâmplă dacă le tratați producția ca widget-uri asamblate dintr-o linie de asamblare din fabrică? Lucrurile care maximizează producția vor funcționa și aici? Sau procesul de dezvoltare seamănă mai mult cu alte discipline de inginerie?

Managerii de proiect au încercat să rezolve acest lucru de când a început dezvoltarea software-ului. Din aceste întrebări a apărut definiția ciclului de viață al dezvoltării software.

Ce este dezvoltarea de software?

Este procesul de creare a software-ului de la zero. În timp ce scrierea codului este activitatea de bază, este mult mai mult decât atât.

Procesul de dezvoltare include ideea și designul înainte de a scrie orice cod. Planificarea este ușor de trecut cu vederea. Nu se simte ca dezvoltarea în felul în care scrie codul. Cu toate acestea, răspunsul la întrebări cruciale întărește mai întâi produsul finit. Merită să fie urmărit proiectul? Dacă da, care este cel mai bun mod de a proceda? Ce caracteristici sunt necesare și ce caracteristici este plăcut să aveți? Răspunsurile oferă proiectului o șansă mai mare de a reuși.

Deși pașii sunt constanti, aplicarea lor variază. Motivul pentru care dezvoltarea de software este o disciplină nouă. Disciplinele de inginerie sunt mature cu sute de ani de istorie. Dezvoltarea software-ului datează abia de la sfârșitul anilor 1940. Este încă o disciplină nouă. Metoda agilă are doar 20 de ani. Cu toate acestea, este unul dintre cele mai influente lucruri care se întâmplă în teoria creării de software. Indiferent, cele șase faze ale ciclului de viață al dezvoltării software sunt comune tuturor sistemelor.

6 etape ale ciclului de viață al dezvoltării software (SDLC)

O echipă de dezvoltare poate folosi ciclul de viață al dezvoltării software pentru un întreg proiect sau o funcție. Evoluția utilizării SDLC a vizat reducerea riscului prin scurtarea duratei fiecărui pas. Peste un moment, ne vom uita mai mult la diferite metodologii. Mai întâi, să examinăm pașii înșiși.

De asemenea, este de remarcat faptul că veți vedea variante în ceea ce privește numărul de pași sau numele acestora. Uneori, pașii sunt îmbinați, cum ar fi dezvoltarea și testarea. Alteori, veți vedea un pas împărțit în două, cum ar fi planificarea care devine planificare și analiză. În cazul nostru, vom rămâne cu aceste șase, deoarece definesc clar fazele.

1. Planificare

Faza de planificare este cel mai important pas. Părțile interesate trebuie să ia în considerare totul, inclusiv fezabilitatea proiectului în sine. Este în regulă să ucizi întregul proiect aici. O organizație sănătoasă va împuternici părțile interesate să facă acest lucru dacă este necesar. Programatorii se vor implica mai puțin în această fază într-un cadru de întreprindere. Proprietarii de produse, analiștii de afaceri și alte părți interesate își exprimă nevoile în acest pas.

2. Design

3. Dezvoltare

Etapa de proiectare include și proiectarea experienței utilizatorului (UX). Dacă aplicația are componente orientate către utilizator, designul UX este o necesitate. Aceasta include cercetarea utilizatorilor prin urmărirea unor persoane reale care interacționează cu machetele produselor. Motivul pentru care acest lucru se întâmplă în faza de proiectare în loc de faza de dezvoltare este sincronizarea. Sesiunile utilizatorilor necesită timp. Adesea, mai multe discuții dus-întors cu părțile interesate de afaceri au loc și din datele adunate.

4. Testare

Apoi, echipa de dezvoltare testează codul. Scriitorul de cod și testerul ar trebui să fie oameni diferiți. Și mai bine este un tester de asigurare a calității non-dezvoltator. Dezvoltatorii tind să se gândească doar la scenarii de drum fericit. Profesioniștii dedicați testării QA tind să se gândească mai bine la modul în care pot sparge software-ul. Este mai probabil să găsească erori înainte de implementare în acest fel. Rezultatul este un software mai stabil la lansare.

Testare automată vs. manuală

Testele unitare și testele de integrare sunt adesea automatizate. Adesea, o platformă DevOps rulează aceste teste pe cod nou înainte de a-l îmbina în ramura principală.

Testarea manuală este departe de a fi învechită. Testele automate fac același lucru iar și iar. Cu toate acestea, o persoană care face testarea manuală poate găsi erori din întâmplare în timpul testării. Variabilitatea testării manuale este punctul său forte.

Testarea unitară

Un test unitar verifică doar o metodă, nimic mai mult. Funcția testată este granița. Dezvoltatorul scrie testele unitare, iar unele cadre SDLC le impun. Programarea extremă le cere. De asemenea, prescrie o dezvoltare bazată pe teste. Aceasta este practica de a scrie mai întâi testele unitare. Apoi scrieți codul programului real.

Testarea integrării

Testele de integrare verifică secțiuni sau caracteristici ale bazei de cod. Ele sunt de obicei automatizate și rulate de platforma DevOps. Ceea ce verifică se întinde pe mai mult decât o singură metodă. Un exemplu este verificarea faptului că un apel API a persistat o nouă înregistrare într-o bază de date. Comparați acest lucru cu un test unitar care verifică și metoda API. Testul unitar ar putea doar să verifice dacă ar trebui să aibă loc un apel la baza de date. Testul de integrare poate dovedi că datele au trecut prin aplicație așa cum era de așteptat.

Testarea sistemului

Forma finală de testare este testarea completă a sistemului. Pentru a recapitula, testarea unitară verifică doar o funcție. Testarea integrării verifică o caracteristică. Dar testarea sistemului tratează întreaga aplicație ca pe o singură unitate. Testarea fumului este o formă ușoară de testare a sistemului. În acesta, testerul interacționează cu sistemul așa cum ar putea face un utilizator natural și se asigură că acesta se comportă conform așteptărilor. În contrast cu testarea completă a sistemului end-to-end, care este mai riguroasă. Un test complet de sistem verifică toate părțile unui sistem ca o singură entitate. De asemenea, o suită de teste de integrare poate servi ca un test complet al sistemului.

5. Desfăşurare

Faza de implementare introduce codul testat în producție. Automatizarea implementării o face mai fiabilă. De asemenea, practicarea implementărilor de producție crește și șansele unei implementări fără probleme. Echipa de dezvoltare practică un mediu de testare numit mediu de pregătire. Ar trebui să fie identic cu cel de producție. Cu cât cele două medii sunt mai asemănătoare, cu atât mai multă valoare are implementarea practicii.

6. Întreținere

Totul până în acest moment în SDLC va reprezenta doar aproximativ un sfert din costul total de proprietate. Costul inițial de dezvoltare al software-ului este de 25% din ceea ce va cheltui afacerea. Faza de întreținere va costa afacerea în jur de 75% din costul total de proprietate. Apărarea împotriva costurilor de întreținere în creștere este mai atentă la fazele anterioare. Aceasta înseamnă o mai bună proiectare tehnică, dezvoltare și testare mai amănunțită. Alternativa este datoria tehnică. La fel ca datoria reală, devine mai scumpă în timp.

5 metodologii principale de dezvoltare software

În timp ce pașii SDLC sunt neschimbați, implementarea lor și ordinea de execuție variază. Să ne uităm la cele mai populare moduri în care organizațiile efectuează procesul de dezvoltare software.

1. Agil

Ceea ce face Agile unic este concentrarea pe oameni. Metodologiile Agile au reorientat atenția industriei. Înainte, accentul era pus pe produs, pe software. Agile a provocat acest lucru și s-a concentrat pe indivizii care efectuează procesul. De asemenea, înainte de Agile Manifesto, Extreme Programming (XP) și Scrum nu aveau nicio legătură. Totuși, după aceea, practicanții lor s-au unit sub steagul Agile.

Agile nu este un cadru în sine. Este un cadru pentru cadre. În esență, este vorba despre concentrarea pe oameni și iterații rapide. Este exact ceea ce spune numele, agil. Făcut bine, există flexibilitate în obținerea rezultatului. Procesele nu se desfășoară niciodată în detrimentul oamenilor, care obțin valoare din ele.

Un alt chiriaș cheie al Agile este o abordare iterativă. Ideea este de a face blocuri de lucru în bucăți mai scurte de timp. În acest fel, afacerea se poate adapta mai rapid la schimbările de pe piață. Abilitatea de a schimba rapid direcția de dezvoltare este ceea ce îl face agil. În același timp, echipa de dezvoltare poate învăța din ceea ce a făcut în fiecare iterație și poate îmbunătăți. Echipele agile fac acest lucru în întâlniri retrospective după fiecare iterație.

2. Programare extremă

Programarea extremă (deseori abreviată XP) a început la începutul anilor 1990. Martin Fowler a fost unul dintre semnatarii originali ai Manifestului Agile. El crede că Agile și-a câștigat popularitatea datorită cadrului XP. În plus, el susține că este cea mai bună modalitate de a începe dezvoltarea de software Agile.

XP își trage numele de la abordarea sa. Este nevoie de bune practici comune de software și necesită ele. Asta îl face „extrem”. XP necesită lucruri precum teste unitare, programare pereche, lansare mai des.

Ceea ce face ca XP o metodă unică este:

Cicluri scurte de iterație (1 până la 2 săptămâni fiind frecvente)
Deschidere la înlocuirea elementelor de lucru în iterația curentă (ceva ce Scrum nu permite)
Accent pe testarea automată și programarea perechilor

3. Slab

Lean nu era Agile din punct de vedere tehnic, dar are o senzație similară în practică. Acum este acceptat ca parte a Agile de majoritatea. Accentul său este diferit de Agile tradițional. Conform manifestului Agile, „Individui și interacțiuni peste procese și instrumente”. Lean se concentrează mai mult pe software decât pe producători.

Rădăcinile sale sunt principiile de producție Lean de la Toyota. Iată cele șapte părți care îl definesc. Dacă sunteți familiarizat cu producția Lean, acestea vor suna similar. Sunt:

Eliminați deșeurile
Amplifică învățarea
Decideți cât mai târziu posibil
Livrați cât mai repede posibil
Dă putere echipei
Construiți integritatea în
Optimizați întregul

4. Scrum

Scrum este cea mai populară metodă Agile. Conform celui de-al 14-lea raport State of Agile, 58% dintre companiile de software folosesc Scrum. Dacă includeți hibrizii Scum, procentul sare la 84%. Ceea ce ridică întrebarea, de ce este cel mai popular?

Răspunsul este că Scrum se referă la realizarea mai multă muncă în mai puțin timp. Asta atrage afacerile. Fiecare iterație în Scrum este un „sprint”. Numele întărește ideea de viteză. De obicei, un sprint durează 2 până la 3 săptămâni. Odată ce o echipă Scrum a planificat un sprint, nimeni nu ar trebui să-l modifice. Munca nouă trebuie să aștepte până la începutul următorului sprint. Acest lucru necesită disciplină din partea părților interesate de afaceri. În practică, această regulă Scrum este adesea încălcată. De aceea, echipele raportează că fac des un hibrid Scrum.

O altă caracteristică a Scrum este Scrum Master. Acesta este un membru al echipei nominalizat pentru a fi responsabil cu menținerea sprintului pe țintă. Adesea, Scrum Master este un dezvoltator din echipa de dezvoltare.

Cea mai comună variantă de Scrum este ScrumBan, care este o combinație de Scrum și Kanban. Kanban își are rădăcinile în procesul de fabricație Toyota japonez, cum ar fi Lean. Este un sistem de lucru just-in-time.

Fiecare lucru este ca o iterație proprie. Un dezvoltator lucrează doar la un singur lucru la un moment dat. Regula este un articol „în curs” pentru fiecare dezvoltator. Această limită strictă de lucru în desfășurare pune în lumină orice blocaj. Dezvoltatorii urmăresc elementele de lucru în desfășurare printr-un panou Kanban. Ca o notă secundară, de aici provine numele. În japoneză, Kanban înseamnă „semnal”.

5. Cascada

Metoda cascadă este cea mai timpurie dintre toate practicile de dezvoltare software. Este anterioară Agile cu cel puțin câteva decenii. Această metodă este, de asemenea, mai veche decât numele ei.

Este modul natural în care companiile au lucrat întotdeauna. Este un proces liniar și începeți de la început. În primul rând, părțile interesate întocmesc cerințe. Ei nu fac asta pentru o funcție sau două. Nu, părțile interesate de afaceri analizează întregul proiect deodată. După aceea, începe munca. Dezvoltatorii fac toată munca fără nicio iterare până la finalizare.

Calea cascadei este cel mai ușor de înțeles conceptual. Oamenii fac câte un lucru pe rând. Acestea fiind spuse, este cel mai riscant pentru succesul afacerii. Dacă ceva nu este țintă, părțile interesate nu îl pot corecta până la finalizarea proiectului. Motivul este că nici măcar nu va fi observat până la finalizarea proiectului.

3 subtipuri de bază de software

Software-ul finit este unul dintre cele trei tipuri. Aceste tipuri sunt software de sistem, programare și aplicație. Pentru a ilustra, iată o analogie cu coacerea prăjiturii. Un mixer sau o spatulă este software-ul de programare. Vă permite să faceți mai multe prăjituri sau mai multe aplicații software în această analogie. La asamblarea unei prăjituri, stratul inferior este software-ul de sistem. Este fundația. Fără el, nu poți avea un tort stratificat. Stratul superior ar fi atunci software-ul aplicației. Este ceea ce este vizibil pentru majoritatea observatorilor ocazionali.

Programul sistemului

Sistemul de operare al unui computer este un software de sistem. Este esențial pentru utilitatea acestuia. Imaginați-vă un computer fără sistem de operare. Veți putea interacționa cu el doar prin limbajul mașinii. Acesta este binar pur - doar unu și zerouri. Ți-ar fi imposibil să lucrezi la orice nivel de scară. Software-ul de sistem deschide utilitatea unui computer.

Windows, macOS și Linux sunt cele mai populare exemple de software de sistem. Driverele de dispozitiv sunt, de asemenea, software de sistem. Acestea extind funcționalitatea de bază a unui sistem de operare. Dispozitivele inteligente fără sistem de operare folosesc firmware pentru a le activa funcționalitatea. Este, de asemenea, software de sistem.

Software de programare

Software-ul de programare este un subset al aplicațiilor software. Orice program pe care un dezvoltator îl folosește pentru a crea programe noi ar clasifica. Acestea variază de la simple editori de text la medii de dezvoltare integrate (IDE-uri) complexe. Majoritatea dezvoltatorilor preferă instrumente software de programare mai complexe. Programe precum Visual Studio de la Microsoft ajută la accelerarea dezvoltării.

Software de aplicație

Aplicația software este cel mai comun tip. Este software-ul care vă permite să faceți lucruri cu un computer. Face computerele utile. Exemple populare sunt programe precum Microsoft Word și Excel.

Software-ul cloud se încadrează și el în această categorie. Google Docs, Dropbox și chiar Instagram sunt aplicații software. Dacă vă simțiți vreodată confuz dacă ceva este sau nu software de aplicație, iată un test simplu. Programul are nevoie de altceva pentru a rula? Windows sau Android nu. Sunt software de sistem. PowerPoint sau chiar un joc precum Call of Duty au nevoie de alte lucruri care rulează pentru a funcționa, ceea ce înseamnă că sunt aplicații software. Fără drivere de dispozitiv și un sistem de operare, acestea nu se pot executa.

Concluzie

Metodele de dezvoltare software sunt încă în curs de maturizare. Cu toate acestea, indiferent de metoda folosită, pașii rămân aceiași. Echipele agile le pot repeta mai repede, iar practicanții Waterfall trec încet de la una la alta. Cu toate acestea, pentru a construi un software mai bun, trebuie să consolidați procesul pentru fiecare pas. Se construiesc unul pe celălalt. Ciclul de viață al dezvoltării software nu este un lucru fără unul dintre pașii săi. Părțile formează întregul.

Gândește-te la ce s-ar întâmpla dacă ai lăsa orice pas afară. Fără a planifica ce faci? Fără design, procesul de dezvoltare va fi întâmplător. Este imposibil să omiteți pasul de dezvoltare. Lipsa testării asigură că produsul nu va funcționa conform așteptărilor. Dacă nu există nicio implementare, nimeni nu va avea acces să utilizeze produsul. O aplicație neîntreținută intră în uz. Fiecare pas este crucial pentru succesul unui produs software.