Sådan bruges Systems Engineering til at opbygge en vellykket webapp

Hvis du forstår, hvordan det fungerer, er det lettere at bygge det

Så du har endelig afsluttet dit design i Adobe XD, Figma, Sketch eller InVision, men stadig kæmper med ideen om, hvordan du implementerer funktionaliteten. Bare rolig, vi har tænkt i et stykke tid, at den eneste måde at opbygge web-apps på er at begynde med UI / UX-design sammen med prototype-skitser.

Heldigvis viser det sig, at der er andre og bedre teknikker, vi kan bruge til at beskrive web-apps uden at understrege, hvilke positioner, størrelse eller afstand elementerne på en side har brug for.

Lad mig introducere dig til noget, der er blevet brugt af virksomheder inden for luftfarts-, sø-, forsvars-, bil- og telekommunikationsområdet for at få en bedre forståelse af, hvordan systemer opfører sig og interagerer. Jeg taler ikke om X antal tip og tricks til, hvordan du forbedrer UI / UX, men hvilke teknikker du kan anvende fra Systems Engineering (SE) -arsenalet til at opbygge vellykkede web-apps.

Disse teknikker har mange fordele, men den vigtigste er, hvor hurtigt man kan udtrykke ideer og forstå, hvordan ting fungerer.

I slutningen af ​​denne artikel kan du bruge nogle af disse SE-teknikker til at opbygge bedre apps.

Her er fire praktiske og relevante SE-teknikker, du kan anvende.

Hvis du vil blive en bedre webudvikler, starte din egen virksomhed, lære andre eller blot forbedre dine udviklingsevner, sender jeg ugentlige tip og tricks af høj kvalitet til de nyeste websprog på markedet.

Et praktisk eksempel - Online læringsplatform

For at gøre eksemplerne intuitive og anvendelige opbygger vi en foregive online læringsplatform. En platform, der giver folk mulighed for at udgive indhold, det samme koncept som Medium, YouTube, Unsplash osv.

Bemærk: Ideen med at bruge disse teknikker er at beskrive det nok, så udviklere nemt kan implementere disse funktioner, hvilket betyder, at vi ikke behøver at gå i detaljer.

Her er nogle gode tip at være opmærksom på i de tidlige faser af appen.

1. Start ikke med detaljeret design

I tidlige faser begynder de fleste udviklere naturligvis med at definere løsningerne først og bliver dermed fanget med detaljer, der ikke rigtig betyder noget for slutproduktet. Det fører os i den forkerte retning, og vi glemmer det sande formål med appen.

Design er vigtigt, men ikke noget, vi skal fokusere på i tidlige stadier. Det er ikke rettet (og ændres ofte) - for eksempel farven på en knap, elementernes placering, skrifttype og så videre. Hvad der ikke ændrer sig er web-appens underliggende adfærd, såsom den måde en person autentificerer, den måde, de uploader noget på en side, trinene til at behandle en betaling osv. De grundlæggende dele forbliver de samme.

2. Start med problemet

Identificer først problemet: omgivelserne, hvem der er interessenter, appens adfærd og kontekst (omfanget).

Vi bygger ikke apps baseret på løsninger, vi bygger dem, fordi der er et problem, problem eller en udfordring, der skal løses. I de fleste tilfælde er klienten ligeglad med løsningen, bortset fra at den fungerer. Løsningen skal identificeres, når udviklerne forstår, hvordan appen opfører sig og interagerer.

Problemet kan for eksempel være, at den nuværende kommunikationsplatform er for langsom, hvilket påvirker arbejdsgangen. Et andet problem kan være, at lederen ikke har et klart overblik over, hvilke opgaver medarbejderen arbejder med og så videre.

Husk, at problemet fortæller os, at der er behov, men ikke giver nogen løsninger. Problemet er, hvad der udløser udviklingsprocessen. Så start med problemet først, før du starter med løsningerne.

Lad os se, hvilke teknikker vi kan bruge til at beskrive vores online læringsplatform.

1. Kontekstdiagram

Definer grænserne

Formålet med kontekstdiagrammet er at definere grænserne inden for appen eller dele af appen og give en klar forståelse af, hvilke enheder den interagerer med.

Som vist kan vi se, hvilke typer interessenter (brugere) der interagerer med appen og interaktionstyperne mellem dem. Bemærk, navnene på interessenterne er ikke nævnt, og heller ikke hvilken type database vi har at gøre med. Vi ønsker ikke at blive fanget i detaljer, der kan ændre sig i fremtiden.

Afklar komplekse apps

Hvis du har at gøre med en ret kompleks app, der består af mange dele, så er et kontekstdiagram et godt alternativ, der giver dig mulighed for at forenkle ting. Det er også en god måde at minde os selv om, hvad formålet med appen er, og fjerne ting, der giver ringe værdi for appen. Det er en måde at træde tilbage og fokusere på, hvad der er vigtigt.

2. Brug sagsdiagram

Bemærk, vi nævner ikke noget om elementernes layout, størrelse eller placering. I SE er det vigtigt, at tingene er modulære, hvilket betyder, at vi kan ændre ting uden at påvirke appen - vi ønsker ikke, at tingene skal være faste og uforanderlige.

En udvikler, der har brug for at bygge fungerende software, skal kunne læse en brugssag og få en god fornemmelse af, hvad softwaren skal gøre. Kilde.

Beskriv interaktionerne

Formålet med use case-diagrammet er at beskrive, hvordan brugeren interagerer med webappen på en verbal måde. Dette er et godt værktøj til at forstå, hvad kunden har brug for, og også hvilke funktioner udvikleren skal implementere.

Udarbejde en brugssag (handling)

Som vist ovenfor er brugeren indholdsproducent og udfører fire handlinger. En handling er en funktion, der skal implementeres. Use case-diagrammet beskriver ikke appens adfærd undtagen interaktionen mellem brugeren og appen eller dele af den.

For at beskrive adfærden kan vi tage en handling og uddybe den gennem diagrammer som aktivitet, tilstandsmaskine, sekvensdiagrammer og så videre.

For eksempel kan vi oprette et aktivitetsdiagram til at beskrive de nødvendige trin for at udføre handlingen "upload indhold". Der er et eksempel på dette i afsnit 3 og 4.

Fokus på forskellige brugsscenarier

Appen vil sandsynligvis blive brugt af brugere med forskellige roller som en administrator, indholdsproducent, redaktør, analytiker og så videre. Og hver rolle har et sæt unikke behov med forskellig brugssag (interaktioner). Det er vigtigt, at vi dækker disse interaktioner, ellers slutter vi med en statisk app, der er tilpasset til en bestemt brugerrolle.

3. Aktivitetsdiagram

Beskriv adfærd

Formålet med et aktivitetsdiagram er at beskrive rækkefølgen af ​​aktiviteter, der er nødvendige for at opfylde en brugssag. Den valgte brugssag er "upload indhold" fra use case-diagrammet, som vist ovenfor.

Du kan frit bestemme, hvilken brugssag du vil udvide og uddybe - pointen er ikke at lave et aktivitetsdiagram for enhver brugssag, men dem, der er vanskelige at forstå eller implementere.

Beskriv trinene for at nå målet

Det er svært at forudsige, hvad brugeren gør, og i hvilken rækkefølge. Af den grund hjælper et aktivitetsdiagram os med at kortlægge, hvilke aktiviteter brugeren udfører, og dækker også beslutninger, som vi måske ikke er opmærksomme på. Det kan også bruges til at beskrive aktiviteter fra en ikke-bruger, for eksempel en del af appen, der venter på noget, før den kan udføres. Fokus er at beskrive arbejdsgangen.

Udtryk ideer gennem design

Da jeg arbejdede i et team, overgav en senioringeniør mig et aktivitetsdiagram over en funktion, han ønskede at blive implementeret. Hele udviklingsprocessen blev meget lettere, fordi jeg ikke behøvede at gætte, hvordan appen opfører sig, adfærden blev allerede beskrevet gennem et aktivitetsdiagram.

Generelt er det et godt værktøj til at udtrykke ideer og tanker for mennesker snarere end blot at stole på verbal kommunikation.

4. Stat-maskindiagram

Definer staterne

Formålet med tilstandsmaskindiagrammet er at beskrive appens diskrete opførsel. Forskellen mellem et aktivitetsdiagram og et tilstands-maskindiagram er, at førstnævnte beskriver trinnene for at opnå noget (workflow), mens sidstnævnte beskriver, hvordan tilstandene for et objekt ændres i løbet af dets levetid.

Begge er nyttige teknikker til at beskrive appens adfærd og er nyttige for klienter og udviklere til at få fælles forståelse af, hvordan ting fungerer.

Afsluttende tanker

Design er i konstant bevægelse og udvikler sig og ændrer sig gennem hele udviklingsprocessen. Som nævnt ovenfor er det vigtigt at tackle designproblemer som UI / UX og prototype skitser, men det beskriver ikke rigtig, hvordan de underliggende dele af appen fungerer eller kommunikerer. Det kræver også at have uddannede grafiske designere og mange ressourcer.

Af den grund har vi brug for noget, der ikke er designafhængigt, noget der ikke fokuserer på mindre detaljer såsom skrifttyper, boksskygger, farver og så videre.

Vi har brug for teknikker til systemteknik til at beskrive, hvordan appen opfører sig og interagerer, for at udtrykke ideer, forenkle udviklingsprocessen og hjælpe folk med ikke-teknisk baggrund med at forstå appernes adfærd.

Bemærk, at der er et sæt regler, der skal følges, når du opretter sådanne diagrammer, men de fleste mennesker, jeg har arbejdet med, forstår ikke eller er ligeglad med disse regler. Så det bedste tip, jeg kan give, er at sikre, at du følger formålet med diagrammet, men træk dig ikke ind i reglerne, som om linjen skulle ende med et pilehoved, diamant osv.

Her er et par andre artikler, jeg har skrevet om webøkosystemet sammen med personlige programmeringstip og -tricks.

  • En praktisk guide til ES6-moduler
  • Sådan udføres HTTP-anmodninger ved hjælp af Fetch API
  • En sammenligning mellem Angular og React
  • Forøg dine færdigheder med disse vigtige JavaScript-metoder
  • Et kaotisk sind fører til kaotisk kode
  • Udviklere, der konstant vil lære nye ting
  • Lær disse centrale webkoncepter
  • Programmer hurtigere ved at oprette brugerdefinerede bash-kommandoer

Du kan finde mig på Medium, hvor jeg udgiver ugentligt. Eller du kan følge mig på Twitter, hvor jeg sender relevante tip og tricks til webudvikling.