Det finnes ingen problemer -bare løsninger

Utviklingen av ditt system

Programvareutvikling er prosessen med dataprogrammering, dokumentering, testing og feilretting involvert i å skape og vedlikeholde programmer og rammer som resulterer i et programvareprodukt. Programvareutvikling er en prosess for å skrive og vedlikeholde kildekoden, men i bredere forstand omfatter den alt som er involvert mellom oppfatningen av den ønskede programvaren gjennom til den endelige manifestasjonen av programvaren, gjennom en planlagt og strukturert prosess. Derfor kan programvareutvikling omfatte forskning, ny utvikling, prototyping, modifisering, gjenbruk, re-engineering, vedlikehold eller andre aktiviteter som resulterer i programvareprodukter. Programvaren kan utvikles for en rekke formål, de tre mest vanlige å være for å møte spesifikke behov for en bestemt klient/bedrift (tilpasset programvare), for å møte et oppfattet behov for et sett av potensielle brukere (kommersiell og Open source-programvare), eller til personlig bruk.

Wikipedia

I Felagi gjør vi allikevel programvareutvikling i en åpen og gjennomsiktig prosess med kunden. Når vi går videre, vil det være flere ganger hvor vi må diskutere visse saker med kunden vår. Husk at dette er ditt prosjekt, vi gjør det bare for deg!

I Felagi bruker vi bare ressursene som er nødvendige for prosjektet ditt, og vi bruker bare de vi trenger. Ved å planlegge vår ressursbruk over ulike kundeprosjekter kan vi gi deg så kostnadseffektiv utvikling som mulig.

Et typisk utviklingsteam består gjerne av:

Prosjektleder: Hen vil være den overordnede ansvarlige for prosjektet ditt. Prosjektlederen er alltid en erfaren utvikler og vil være den du som kunde har mest å gjøre med. Med mindre prosjektet ditt er stort og består av flere utviklingsgrupper, jobber en prosjektleder sjelden med heltid på prosjektet. I utgangspunktet beregner vi 1/3 del per lag, noe som betyr at et prosjekt samler tre lag, vil trenge en heltids PM.

Gruppeleder: Er den daglige lederutvikleren som også er en erfaren seniorutvikler. Gruppeleder er ansvarlig for oppfølging av SDP (se nedenfor) og for å rapportere tilbake til prosjektleder eller Scrum leder.

Seniorutvikler: En utvikler med minst 5 års relevant erfaring. Det kan være gruppe-lederen som utfører denne funksjonen, avhengig av prosjektets størrelse. Et lag må alltid ha en senior utvikler.

Baksystem utvikler Ansvarlig for SOA-løsningen på baksiden. Svært ofte enten fylt av teamledere eller senior utvikler.

Frontsystem utvikler Ansvarlig for de tingene du ser. Samarbeider tett med både baksystem og HTML-utvikler.

QA ingeniør QA-ingeniøren er ansvarlig for testing av forskjellige utgivelser og følger dem opp med BUG-rapporter til utviklerne. QA er alltid kundens person i teamet og er ansvarlig for å kontrollere at kundens krav er oppfylt. Våre QA inginører er uavhengige av utviklingsavdelingen, og svarer kun direkte til prosjektleder. Vi oppfordrer gjerne kunden til å ta med sitt eget QA lag i prosjektet, men alle utviklingsgrupper må ha en QA-ressurs!

Ytterligere lagressurser ville være:

HTML utvikler

Grafisk designer

Database arkitekt

I Felagi anerkjenner vi alltid at kildekoden er betalende kunders eiendom, og bare dens. Vi bruker aldri kode fra andre kunders prosjekter om igjen.

Imidlertid har Felagi utviklet flere vanlige SOA moduler som for det meste hvert prosjekt inneholder, som person, bruker og adresshåndtering. For å være så kostnadseffektive som mulig for våre kunder, kan vi komme til inkludere noen av disse modulene i løsningen.

Vi er stolte over at hver kunde skal ha en fullt fungerende løsning, selv om de bestemmer seg for å forlate oss og bruke en annen leverandør senere. All nødvendig kode for løsningen din vil bli inkludert, selv de vanlige modulene vi har utviklet utenfor prosjektet ditt. Du har betalt for en fungerendeløsning, og det er det du vil få uansett hva!

Vi bruker Microsoft Team Services for vår kildekodehåndtering, som er en skybasert løsning hostet av Microsoft Azure. Vi gir våre kunder tilgang til kildekoden når prosjektet er betalt for og under testing eller for ekstern revisjon. Noen kunder vil at vi skal bruke andre systemer slik som deres interne Team Foundation-server, som vi vil møte med en positiv holdning.

Agile programvareutvikling beskriver et sett med verdier og prinsipper for programvareutvikling hvor krav og løsninger utvikler seg gjennom samarbeidet mellom selvorganiserende, kryssfunksjonelle lag. Den fortaler adaptiv planlegging, evolusjonær utvikling, tidlig levering og kontinuerlig forbedring, og det oppmuntrer til rask og fleksibel respons på endring. Begrepet agile (noen ganger skrevet Agile) ble popularisert av Agile Manifesto, som definerer disse verdiene og prinsippene. Agile programvareutviklingsrammer fortsetter å utvikle seg, og to av de mest brukte er Scrum og Kanban.

Felagi bruker en fleksibel tilnærming til de fleste av våre prosjekter, men vi er ikke idealister, slik at vi bruker prinsippene av smidig som det passer oss og vår kunde.

Scrum er en iterativ og inkrementell, fleksibel programvareutviklingsramme for styring av produktutvikling. Det definerer "en fleksibel, helhetlig produktutviklingsstrategi hvor et utviklingslag fungerer som en enhet for å nå et felles mål", utfordrer antakelser om den "tradisjonelle, sekvensielle tilnærmingen" til produktutvikling og gjør det mulig for lag å organisere seg selv ved å oppmuntre til fysisk samarbeid -lokalisering eller nært samarbeid mellom alle lagmedlemmer, samt daglig ansikt-til-ansiktskommunikasjon blant alle gruppemedlemmer og involverte disipliner.

I programvareutvikling og produktstyring er en brukerhistorie en uformell, naturlig språkbeskrivelse av en eller flere funksjoner i et programvaresystem. Brukerhistorier er ofte skrevet ut fra en sluttbruker eller bruker av et system. De registreres ofte på indekskort, Post-it notater, eller i prosjektledelsesprogramvare. Avhengig av prosjektet kan brukerhistorier skrives av ulike interessenter, inkludert klienter, brukere, ledere eller utviklingsteam medlemmer. Brukerhistorier er en type grenseobjekt. De letter på kommunikasjon, det vil si, de hjelper programvarelagene å organisere sin forståelse av systemet og dets kontekst. Brukerhistorier er ofte forvekslet med systemkravene. Et krav er en formell beskrivelse av behovet; En brukerhistorie er en uformell beskrivelse av en funksjon.

I Felagi oppfordrer vi kunden til å identifisere brukerhistorier med oss. Vi bruker for det meste ideverksteder for dette formålet.

En serviceorientert arkitektur (SOA) er en stil med programvareutforming hvor tjenester leveres til de andre komponentene av applikasjonen, gjennom en kommunikasjonsprotokoll over et nettverk. De grunnleggende prinsippene for serviceorientert arkitektur er uavhengige av leverandører, produkter og teknologier. En tjeneste er en diskret funksjonalitet som kan nås eksternt og handles på og oppdateres uavhengig, for eksempel å hente et kredittkortoppsett online. En tjeneste har fire egenskaper i henhold til en av mange definisjoner av SOA: Den representerer logisk en forretningsaktivitet med et bestemt utfall. Det er selvstendig. Det er en svart boks for sine forbrukere. Det kan bestå av andre underliggende tjenester. Ulike tjenester kan brukes sammen for å gi funksjonaliteten til et stort program. Så langt kan definisjonen være en definisjon av modulær programmering på 1970-tallet. Serviceorientert arkitektur er mindre om hvordan man modulerer en applikasjon, og mer om hvordan man komponerer et program ved å integrere distribuerte, separat vedlikeholdte og distribuerte programvarekomponenter. Den aktiveres av teknologier og standarder som gjør det enklere for komponentene å kommunisere og samarbeide over et nettverk, spesielt et IP-nettverk.

I Felagi bruker vi SOA-prinsipper for all vår programvareutvikling!

Før vi starter den faktiske programmeringen produserer vi alltid SDP som vår utviklingsgruppe bruker retningslinjer og arbeidsplan. Selv om SDP vurderes å være en intern plan for et utviklingslag, gir vi fullstendig åpenhet til kunden vår om ønskelig.

En SDP er alltid og bare skrevet på engelsk.

En SDP flere deler:

Prosjekt Formål, Omfang og Mål

Forutsetninger og begrensninger

Prosjektleveranser

Organisasjonsstruktur

Eksterne grensesnitt

Prosjektestimater

Prosjektplan

Faseplan

Iterasjonsmål

Utgivelser

Prosjekt tidsplan

Prosjektresurser

Kommunikasjonsplan

Prosjektovervåking og kontroll

Kravsstyring

Planleggings- og budsjettkontroll

Kvalitetskontroll

Rapportering og måling

Risikostyring

Konfigurasjonsstyring