Når du danner en teknisk oppgave, må den nødvendigvis liste opp alle kravene til et informasjonssystem, ellers vil ikke utvikleren ganske enkelt vite for hvilket formål produktet er laget, hva det er ment å oppfylle og hvordan. Oppgaven med å formulere krav ligger hos kunden, selv om i praksis lederne som bestillingen gjennomføres vanligvis hjelper med dette. Men studenter som er involvert i å skrive semesteroppgaver, avhandlinger, skal kunne selv lage slike lister.
Felles forståelse
Prosessen med å lage IP er ganske komplisert, består av mange påfølgende stadier. Spesialister som jobber med prosjektet, blir tvunget til å håndtere en rekke vanskeligheter. Til en viss grad kan dette forenkles ved å formulere krav til informasjonssystemet nøyaktig. Det er ikke alltid åpenbart hvorfor problemene oppstår, spesielt når du jobber med innovative produkter, og det å lage en omfattende beskrivelse av alle handlingene produktet er beregnet på er ofte en vanskelig oppgave.
Oppmerksomhet på alle detaljene
Et komplett bilde av produktets funksjonalitet er den komplette listen over krav til et informasjonssystem. Det inkluderer også aspekter som kunden foreslår, og programmereren implementerer når han oppretter prosjektet. Prosessen med å bygge muligheter, deres analytiske forskning, dokumentasjon, testing av arbeidskapasitet er utvikling av krav, hvor det er mulig å identifisere alle begrensningene nøyaktig og komme til enighet mellom "Jeg vil" og "virkelig mulig". Det er viktig å huske at moderne ingeniører ikke er tryllekunstnere, men mennesker som bruker tilgjengelige tekniske verktøy, hvis funksjoner dessverre også er begrenset. Tidsaspektet er ikke mindre viktig, siden arbeid med å opprette og implementere krav krever betydelige tidskostnader - måneder og noen ganger år.
Hvilke er det?
Det er vanlig å snakke om system- og brukerkrav til et informasjonssystem. Naturlig språk beskriver de som er presentert av en bestemt bruker. For å tydeliggjøre ordlyden, kan du ty til diagrammer med ulik grad av kompleksitet. Dette lar deg gjøre et generelt inntrykk av funksjonene som IP-en er beregnet på å implementeres, og begrensningene du vil møte i arbeidet ditt.
Systemkrav er de spesifikke egenskapene til prosjektet, og kunnskapen om dette lar deg omsette ønsker fra klienten til virkelighet. Disse tekniske kravene til informasjonssystemet inkluderer en presentasjon om utstyrets funksjoner, dets kraft, samt valget til fordel for et spesifikt arkitekturalternativ. Mange andre aspekter kan tilskrives systemdelene, som ikke er åpenbare for brukeren, men som regulerer hva det endelige produktet blir.
Krav: hvor får du dem?
Oppgavene med å formulere og godkjenne krav til et informasjonssystem er ikke så enkle som det kan virke ved første øyekast. Begrepet brukes for å betegne en så kompleks strukturert prosess, innenfor rammen som dokumentasjon opprettes, bekreftet av kunden, entreprenøren, som tydelig regulerer alle produktspesifikasjoner. Utvikling er delt inn i fire trinn på rad:
- analytiske aktiviteter for å bestemme graden av gjennomførbarhet av den planlagte;
- oppretting, analytisk studie av kravene direkte;
- formulering av krav til dannelse av støttedokumentasjon;
- sertifisering av datasystemkrav for informasjon, samt andre betingelser, regler for prosjektgjennomføring.
Ikke så enkelt
Hvis kravene til sikkerhet for informasjonssystemer, informasjonsinnhold, format, styringsoppgaver og andre aspekter ved prosjektets funksjon en gang er etablert, betyr ikke dette at de vil forbli uendret før den "seirende slutt". Arbeidsflyten er ofte ledsaget av en endring i etablerte spesifikasjoner og krav. Dette skjer ikke bare på initiativ fra kunden, men også av entreprenøren, som blir møtt med visse tekniske begrensninger som forhindrer implementering av en rekke planlagte aspekter. Det er viktig å ta hensyn til funksjonene i prosesskontroll. Endringsledelse er et av de viktigste aspektene ved å utvikle krav og implementering av disse innen en spesifikk IP.
Et viktig aspekt ved å jobbe med krav er definisjonen av de med påfølgende allsidig informasjonsanalyse. For dette brukes en generalisert arbeidsmodell. Innenfor rammen av en bestemt bedrift implementeres et unikt krav til styringssystem for informasjonssystemer, som gjør det mulig å formulere, justere, godta, avvise de valgte forholdene. Mye avhenger av kvalifikasjonen til arbeidstakere, typen IP de jobber med, standardene som brukes i arbeidsflyten.
Hvordan ser det ut?
I praksis innebærer ordlyden, analysen av kravene til sikkerhet for informasjonssystemer, datautfylling, struktur (og andre system- og brukeres) først å identifisere funksjonene i et bestemt emneområde. Det undersøkes av kvalifiserte analytikere og bestemmer de spesifikke parametrene for applikasjonssektoren for det utviklede produktet i fremtiden. Etter det begynner de å samle foreløpige krav, og jobber med personer som formulerer slik informasjon. Parallelt fortsetter de å jobbe med foredling av fagområdet.
Det neste trinnet i formulering av krav til kommunale informasjonssystemer, private, brukt i offentlige etater, er å lage et hierarkisk system med identifisert informasjon. Hvis den innledende innsamlingen av informasjon gir et kaotisk kompleks av data, blir det innenfor rammen for systematisering bestilt, og skaper grupper av elementer som har logiske forbindelser med hverandre.
Fortsatt arbeid
Det neste trinnet i spesifikasjonen av informasjonskrav i informasjonssystemer, prosjektets struktur, funksjonelle, interne funksjoner er å identifisere motsetninger og løse konflikter. Når de mottar informasjon fra et bredt spekter av tredjeparter om arbeidet med den designet IP, møter de følgende problem: hver person har sine egne unike ideer om prosjektets evner og dets formål. Ofte kommer ideer mottatt fra forskjellige mennesker i konflikt med hverandre, og motsier også logikken, de eksisterende tekniske evnene som systemet implementeres gjennom. For å effektivisere situasjonen, etter en grundig analyse, er det nødvendig å identifisere alle motsetningene og finne den optimale kompromissløsningen for å løse dem.
Å identifisere motsetninger og analysere gjennomførbarheten til alle krav, er det også nødvendig å utarbeide et prioriteringssystem. Det er alltid viktigere og mindre betydningsfulle blant det generelle kravet. Utviklerenes oppgave er å samarbeide tett med de som skaper krav for å identifisere hvilke av de etablerte aspektene ved produktets funksjon som er de mest betydningsfulle og hvilke som kan vente eller bli fullstendig kansellert hvis negative ytre forhold bidrar til dette (for eksempel mangel på tid). Etter å ha laget et prioriteringssystem, kan vi begynne å sjekke de identifiserte aspektene for fullstendighet, kompatibilitet seg imellom og konsistens.
Trinn for trinn
Krav til informasjonssystemer (personopplysninger, informasjon om virksomhetens arbeid og eventuelle andre) er formulert som del av en syklisk prosess. Alle trinn er koblet både direkte og omvendt. Trinnene er beskrevet ovenfor: først må du identifisere funksjonene i emneområdet, deretter gradvis gå til trinnet med å bestemme kompatibiliteten til kravene imellom, samt deres fullstendighet og andre parametere, slik at vi kan snakke om anvendeligheten av de oppnådde forholdene i praksis for utviklere. Hvis du klarer å lage et fullverdig bilde av fagområdet, setter det allerede arbeidsforholdene, spesielt funksjonen. Gjentakelsen av syklusen gir et mer nøyaktig, dyptgående bilde av området, den tredje syklusen vil gjøre det mulig å formulere krav enda tydeligere. Gjentagelse er nødvendig til alle deltakere i arbeidsflyten forstår nøyaktig hva systemet er designet for og hvordan det vil fungere, hva som må implementeres når du jobber med et prosjekt.
For at prosessen med å danne krav skal være effektiv, og resultatene av den skal være anvendelige i arbeidet, er det nødvendig å følge allment aksepterte algoritmer for å formulere forhold.
Referansepunkter
Dette er den grunnleggende metoden for å identifisere krav til statlige informasjonssystemer, spesielt - kort sagt, absolutt hvem som helst, uavhengig av hvor de brukes. Som en del av definisjonen av forhold, er det nødvendig å anerkjenne som en innledende betingelse at synspunktene på spørsmålet kan variere. De identifiseres og brukes som grunnlag for formuleringen av den første prosessen med å samle krav, og deretter de faktiske forholdene.
Synspunktet er et ganske vagt konsept, så det er utviklet flere tilnærminger som tolker det annerledes. Den enkleste tolkningen av konseptet er en datakilde som beskriver hvordan IP-en vil fungere. Referansepunkter blir grunnlaget for modellering av IP og bruk av informasjon i produktet. Innsamling av krav innebærer identifisering av alle viktige referansepunkter som videre brukes i prosessen med å bygge produktet. Den tar også hensyn til hvordan teknikkene vil bli brukt til å behandle dataene.
Alternativ tilnærming
En annen tolkning av begrepet “synspunkt” innebærer oppfatningen av begrepet som en representasjonsstruktur. Dette er faktisk et element i produktmodellen. Ulike synspunkter lar deg lage en rekke modeller av endelige tilstandsmaskiner, interaksjoner mellom enheter og forholdene mellom dem i et spesifikt prosjekt. Spesifikasjonene av omfanget av prosjektet tas i betraktning.
Synspunktet kan bety en mening fra den eksterne mottakeren av tjenesten implementert gjennom IP. Basert på TK er det mulig å identifisere data som brukes i implementeringen av systemtjenester, deres styring. Denne tilnærmingen regnes som den mest effektive. Det dannet grunnlaget for den synsvinkelorienterte kravdefinisjonen - en spesifikk metode for å identifisere krav som lar deg bestemme informasjon og effektivt analysere den.
Arbeid med synspunkter
Først må de identifiseres, samt å bestemme alle tjenestene som er knyttet til et bestemt punkt. Da er systemet strukturert på en hierarkisk måte, gruppering av synspunkter imellom, og avslører vanlige tjenester for IP. De rangert som det høyeste hierarkiske nivået. De vil arves av alle TK på et lavere nivå.
Støttende TK må dokumenteres. For denne informasjonen er tydelig beskrevet, gitt resultatene av identifikasjonen. Etter det er det mulig å lage et TK-system der alle IP-objekter identifisert fra den innsamlede informasjonen vil bli reflektert.
Ta deg god tid!
Som regel begynner arbeidet med IP med en storstilt brainstorming-sesjon designet for å bestemme alle mulige krav til et prosjekt. Det er nødvendig å være klar på forhånd at det er nesten umulig å bestemme alle mulige krav med en prosedyre. Jo mer komplekst systemet er, jo mer vil slike prosedyrer være nødvendig.Bare hvis gjentatte brainstormingsøkter som involverer både kunden og entreprenøren ikke gir nyttig informasjon, antar de rimelig at støttende TOR-er er blitt identifisert og kravene er formulert, kan vi begynne å implementere dem på tekniske måter.
Sertifisering av krav
Denne prosedyren lar deg forstå i hvilken grad kravene samsvarer med kundens ideer om sluttproduktet. Verifisering er et av de viktigste trinnene for å oppdage en feilaktig spesifikasjon og eliminere den på forhånd. Ellers vil endringen måtte utføres på det stadiet når systemet allerede er konstruert og konstruert, noe som medfører både midlertidige og andre ressurstap. De største problemene gir feil oppdaget etter introduksjonen av produktet i bedriften.
Generelt sett er arbeidet med å gjøre justeringer av systemet vurdert til å være mye høyere enn påvisning og korrigering av unøyaktigheter i stadiet med utforming av IP, kodingsfunksjonalitet. Endring av krav i de fleste tilfeller provoserer imponerende strukturelle endringer, inkludert et grunnleggende nivå. Dette betyr at etter at du har gjort endringene, må du gå gjennom et komplett spekter av bekreftelse og testing for å sikre at alle designede verktøy fungerer som de skal.