Bedrijfsfuncties en ongebruikelijke processen
Naast normale operaties worden anomalieën zoals annulering, terugbetaling, dubbele indiening, netwerkverstoring, ontoereikende toegang en gegevensconflicten geverifieerd.
Home / checklist voor projectbeslissing / Software projectacceptatie
PROJECT DECISION GUIDESoftware project acceptatie checklist: functionaliteit, kwaliteit en hoe de levering te controleren
De software is niet on-line. Effectieve acceptatie en inspectie gaat gepaard met controles op de bedrijfsfunctionaliteit, abnormale processen, gegevenskwaliteit, niet-functionele indicatoren en daaropvolgende ontvangerschap.
Beantwoord de vraag.
Lijst met aanvaarding van softwareprojecten
De acceptatie- en inspectiecriteria moeten vóór het begin van het project in de vereisten en contracten worden opgenomen en voortdurend worden verzoend bij elke mijlpaal. De uiteindelijke aanvaarding moet ten minste betrekking hebben op bedrijfsprocessen, rolprivileges, datamigratie, interfaces, prestaties, beveiliging, compatibiliteit, inzet van terugrollers, bronbestanden en onopgeloste zaken.
DECISION FACTORS
Voor de besluitvorming te controleren sleutelelementen
Ten eerste worden de grenzen van terughoudendheid en verantwoordelijkheid vastgesteld, en worden de technische routes en modaliteiten van samenwerking vergeleken.
Gegevens en interface-samenhang
Vergelijk het aantal migraties, sleutelgebieden, monetaire status, interface-toetsing en verzoeningsresultaten en bewaar gegevens met terugwerkende kracht.
Prestaties en stabiliteit
Responstijd, capaciteit, beschikbaarheid en hersteldoelstelling volgens de werkelijke coproductie, datavolume en belangrijke links.
Autoriteit en veiligheid
Controleer rolgrenzen, gevoelige gegevens, logaudits, voucherbeheer, gap repareren en afhankelijkheid van derden.
Inzet en terugrollen
Automatisering van validatie in doelomgevingen of herindeling, configuratiebeheer, back-upherstel, bewaking van alarmen en terugrolprocessen.
Brondocument en kennisoverdracht
Codes, databases, interfaces, rekeningnummers, ontwerp- en transportgegevens moeten volledig in de controlepositie van de cliënt worden geïntegreerd.
Voorbereiding van aanbevelingen voorafgaand aan de mededeling of beoordeling
Demand-to-acceptance per artikelKernprocessen en uitzonderingen zijn goedgekeurdGegevensmigratie en interface-reconciliatie voltooidDe prestatieveiligheidstest is in overeenstemming met het protocol.Productie-implementatie en terugrol pasVolledige broncode en lijst van derdenGebruiker en vervoersdocumenten geleverdLegacy-kwesties en verantwoordelijkheden inzake kwaliteitsborging zijn bevestigd
Voorgestelde pad naar implementatie
Voorgesteld wordt de aanvaardingen in vier fasen te demonteren, prototypes, iteratieve, piloot- en go-live, en het probleem op te lossen wanneer het zich voordoet. De uiteindelijke aanvaardingen moeten resulteren in schriftelijke verslagen, versiemarkeringen, testbewijs en een lijst van resterende items.
DECISION WORKSHEET
Translating the software project acceptation checklist in afdwingbare besluitvorming
De volgende werkbladen helpen bedrijven om vaag advies te organiseren in leveranciersgebaseerde, interne goedkeuring en project-receiveerbare input.
Bedrijfsfuncties en ongebruikelijke processen
Naast normale operaties worden anomalieën zoals annulering, terugbetaling, dubbele indiening, netwerkverstoring, ontoereikende toegang en gegevensconflicten geverifieerd.
Indien de factor onzeker blijft, moet een diagnostische of kleinschalige validatie worden geregeld en het is niet passend om de niet-variabele vaste totale prijsklasse rechtstreeks op te nemen.
Gegevens en interface-samenhang
Vergelijk het aantal migraties, sleutelgebieden, monetaire status, interface-toetsing en verzoeningsresultaten en bewaar gegevens met terugwerkende kracht.
Indien de factor onzeker blijft, moet een diagnostische of kleinschalige validatie worden geregeld en het is niet passend om de niet-variabele vaste totale prijsklasse rechtstreeks op te nemen.
Prestaties en stabiliteit
Responstijd, capaciteit, beschikbaarheid en hersteldoelstelling volgens de werkelijke coproductie, datavolume en belangrijke links.
Indien de factor onzeker blijft, moet een diagnostische of kleinschalige validatie worden geregeld en het is niet passend om de niet-variabele vaste totale prijsklasse rechtstreeks op te nemen.
Wat moet een vergelijkbare samenvatting van beoordelingen bevatten?
De organisatie van de vereisten komt ten minste overeen met de ontvangstposten per artikel, kernprocessen en uitzonderingen, gegevensmigratie en interface-reconciliaties, prestatie-veiligheidstests worden overeengekomen, samen met een indicatie van het huidige bedrijfsvolume, gemiddelde verwerkingstijd, grote afwijkingen, systemen in gebruik, gegevensprivileges, afhankelijkheid van derden en toegangsvensters. Dezelfde versie van informatie wordt verstrekt aan verschillende leveranciers, en de eis is om afzonderlijk de aannames, uitsluitingen, klantsamenwerking, levering en acceptatie-bewijs te specificeren om te voorkomen dat de totale prijs van slechts één van de ontbrekende grenzen wordt vergeleken.
De onderneming verwacht bijvoorbeeld dat het project 160 uur arbeid per maand zal besparen, maar dit cijfer moet worden uitgesplitst in het aantal taken, eenmalige tijdbesparing, adoptiepercentages en manuele beoordelingsratio's. Als slechts 40% van de gebruikers de eerste periode gebruikt of als het nieuwe proces het herzieningsproces verhoogt, zullen de werkelijke voordelen aanzienlijk lager zijn dan de schijnbare schatting.
Vier soorten bewijs aanbevolen voor ondervraging tijdens de communicatie met de verkoper
Het eerste is het bewijs van de draagwijdte: consistentie van de vraagversies, bedrijfsprocessen, prototypes, interfaces en uitsluitingen; het tweede is technisch bewijs: of soortgelijke technologieën toegankelijke structuren, codebeheer, testen, implementatie en probleembeheermethoden hebben; het derde bewijs is personeel: of de werkelijke deelnemers, inputfasen, verantwoordelijkheden en vervangingsmechanismen duidelijk zijn; en het vierde bewijs is levering: hoe broncodes, gegevens, rekeningnummers, documenten, opleiding, kwaliteitsborging en vervoer worden overhandigd. Het is normaal dat leveranciers niet in staat zijn om de vertrouwelijkheid van klanten in het biedstadium te bieden, maar in staat moeten zijn hun eigen methoden en het bewijs dat in het kader van dit project kan worden ontwikkeld, uit te leggen.
Het verdient aanbeveling de reikwijdte, de kritische afhankelijkheid, de capaciteit van het team, de acceptatie-existentie en de overname op lange termijn afzonderlijk te beoordelen en de basis voor elke score te registreren. Als een programma goedkoper is, wordt de interface, migratie, testen of online verantwoordelijkheid uitgesloten, dan moet het vóór vergelijking in hetzelfde leveringskaliber worden omgezet.
Het beginsel van het vonnis
Deze pagina biedt een besluitvormingskader dat geen vaste aanbieding of prestatietoezegging vormt.
FAQ
FAQs
De meest voorkomende kwesties voor de samenwerking worden duidelijk van tevoren vermeld.
Kun je het controleren als je het er doorheen krijgt?+
Nee. Controle van afwijkingen, gegevens, prestaties, beveiliging, implementatie en onderhoud is ook noodzakelijk, anders kan het probleem van hoge kosten worden blootgesteld wanneer online.
Moet het kleine probleem worden geïdentificeerd als een weigering van aanvaarding?+
Het probleem van het blokkeren van de toegang tot de lijn of het beïnvloeden van kerngegevens moet eerst worden hersteld, en het probleem met een laag risico kan worden aangepakt door de verantwoordelijkheden en termijnen te verduidelijken voordat de legacy-lijst wordt ingevoerd.
Wie moet er bij de inspectie betrokken worden?+
De hoofden van de operaties, de belangrijkste gebruikers, de product- of projectleiders en het technisch en vervoerspersoneel moeten worden betrokken overeenkomstig hun respectieve verantwoordelijkheden, waarbij wordt vermeden dat zij door één enkele rol worden geïdentificeerd.
DECISION FAQ
Kijk eens naar alle 265 vragen.Gemeenschappelijke vraagstukken in verband met lopende projecten
Softwareontwikkeling en outsourcing van projecten
Hoe kan het software-outsourcingproject de kwaliteit van ontwikkeling garanderen?
De kwaliteit kan niet wachten tot het project eindelijk wordt gegarandeerd door een functionele acceptatie. Gemeenschappelijke controles moeten worden omgekeerd vanaf de basis van de vraag, architectuur evaluatie, code management, continue testen, fase demonstratie en online. Ondernemingen moeten zien traceerbaarheid van vraag, gebreken, testen en het vrijgeven van bewijsmateriaal, in plaats van luisteren naar mondelinge vooruitgang.
Volledig antwoord weergevenContracten, betalingen, wijzigingen en projectuitvoeringWelke informatie is nodig voor de acceptatie en inspectie van het softwareproject?
De informatie heeft tot doel aan te tonen dat het systeem voldoet aan overeengekomen normen en dat de cliënt kan blijven werken en overnemen.
Volledig antwoord weergevenSoftwareontwikkeling en outsourcing van projectenHoe lang duurt het voordat een aangepast softwareproject zich ontwikkelt?
De cyclus is afhankelijk van de mate van bepaling van het toepassingsgebied, interface en gegevensvoorbereiding, besluitvormingsefficiëntie en toegangseisen, niet alleen van het aantal ontwikkelde mensen. Kleine interne instrumenten kunnen in weken worden voltooid en kruising tussen systemen en ondernemingsplatforms moeten vaak in fasen over een maand worden geïmplementeerd.
Volledig antwoord weergevenContracten, betalingen, wijzigingen en projectuitvoeringHoe worden software-outsourcingcontracten ondertekend en welke voorwaarden moeten worden overeengekomen?
In de overeenkomst voor het sluiten van software moet ten minste de reikwijdte van de vraag, mijlpalen, betalingen, aanvaarding, wijziging, intellectuele-eigendomsrechten, vertrouwelijkheid, kwaliteitsborging en beëindiging van de overdracht worden gespecificeerd. De functionele lijst moet niet alleen de naam van de module bevatten, maar ook betrekking hebben op de eisen van de versie, interface, gegevens en niet-functionele vereisten. De verantwoordelijkheid van de partijen, de samenwerking van de klant en de afhankelijkheid van derden moet ook in het contract worden opgenomen. Het doel van het contract is niet om alle risico's naar één kant te schuiven, maar om een uitvoerbare basis te bieden voor de verwerking wanneer er veranderingen plaatsvinden.
Volledig antwoord weergevenRELATED
Indiening van de projectevaluatieHoud uw kennis van de diensten
Relevant
Beoordeling en aanvaarding van de leverancier
Volledige beoordeling van softwareleveranciers van pre-samenwerking tot postlevering
Voor meer informatie.RelevantRichtsnoeren voor samenwerking en uitvoering
Inzicht in mijlpalen, resultaten en verantwoordelijkheden inzake aanvaarding
Voor meer informatie.RelevantCentrum van vertrouwen en bewijs
Inzicht in de beginselen van openbaarmaking en levering van zaken van ZhiHua Tech
Voor meer informatie.