Het softwaresysteem moet zorgen voor de bescherming van gegevens tegen onbedoelde verwijdering en wijziging. Alleen een databasebeheerder of een instructeur met de juiste rechten, die is geregistreerd op de databaseserver en de juiste rollen heeft, mag toegang hebben tot de gegevens.
Voor de betrouwbaarheid van het opleidingssysteem moet het aan de volgende eisen voldoen:
het ontwikkelde programma moet beschermingsmiddelen hebben tegen foutieve acties van gebruikers;
alle fouten moeten worden weergegeven met opmerkingen of tips om ze op te lossen;
zorgen voor de veiligheid van gegevens in geval van storingen in de werking van externe apparaten.
Om de betrouwbaarheid te verbeteren, moeten de volgende maatregelen worden genomen:
hardware en software configureren in overeenstemming met technische vereisten;
maak periodiek een back-up van informatie;
controleer regelmatig de integriteit van de database;
netwerkapparatuur onderhouden.
Vereisten voor de samenstelling en parameters van technische middelen
De minimale hardwareconfiguratie van het systeem die zorgt voor de normale werking van het trainingssysteem mag niet lager zijn dan het volgende:
RAM 128 MB of meer.
Minstens 150 MB vrije ruimte op de harde schijf.
Vereisten voor de computer die wordt gebruikt om configuraties te ontwikkelen:
Processor AMD Athlon 900 MHz of hoger.
RAM 256 MB of meer.
Minstens 250 MB vrije ruimte op de harde schijf.
Bij gebruik van een geautomatiseerd systeem in een lokaal netwerk, moet op een van de computers de Firebird 1.5.3-server zijn geïnstalleerd en draaien met de eerder geïnstalleerde database. Op andere machines moet u de clienttoepassing van het apparatuurboekhoudsysteem installeren.
Vereisten voor informatie en softwarecompatibiliteit
Om het softwareproduct te gebruiken, zijn de volgende componenten vereist:
Besturingssysteem van de Microsoft® Windows®-familie (niet lager dan 2000).
Geïnstalleerde en geconfigureerde softwareproducten MicrosoftSQLServer, IBExpert2004,Borland®C++Builder™ 6.0,Microsoft.NETFrameworkSDKv2.0.
gebruiksvoorwaarden
Het programma moet op werkende hardware draaien. De vereisten voor de bedrijfsomstandigheden van de pc en andere apparatuur die in het complex wordt gebruikt, zijn uiteengezet in de technische documenten die zijn opgenomen in de leveringsset van de apparaten.
Vereisten voor softwaredocumentatie
De programmadocumentatie moet de volgende documenten bevatten.
Handleiding voor de systeembeheerder.
Docentenhandleiding.
Handleiding voor de leerling.
De handleiding voor de systeembeheerder moet beschrijvingen bevatten van de specifieke configuratie van het systeem.
Het softwaresysteem moet een volledige docentenhandleiding bevatten met een beschrijving van de werkscenario's van de docent.
Het softwaresysteem moet een complete handleiding voor de stagiair bevatten met een beschrijving van de scenario's voor het werk van de stagiair.
Stadia van de ontwikkeling van softwaresystemen
De ontwikkeling van een softwaresysteem moet binnen de volgende stappen worden georganiseerd.
ontwikkeling van een implementatieplan;
ontwikkeling testplan;
opstellen van een uitvoeringsplan.
Ontwerp:
logisch ontwerp van softwaresysteemarchitectuur;
ontwikkeling van de databasestructuur;
gebruikersinterfaceontwerp.
Implementatie:
implementatie van de ontwikkelde gebruikersinterface;
implementatie van de belangrijkste functies van het softwaresysteem.
Systeem testen:
structurele testen;
functioneel testen;
bugfixes en verbeteringen.
Systeemimplementatie:
controleren van de beschikbaarheid van de benodigde apparatuur;
systeem installatie;
opleiding.
Systeem onderhoud.
Volgens GOST stelt deze norm (opnieuw uitgegeven in november 1987) de procedure vast voor de constructie en uitvoering van technische specificaties voor de ontwikkeling van een programma of softwareproduct voor computers, complexen en systemen, ongeacht hun doel en reikwijdte.
We moeten uiterst voorzichtig en voorzichtig zijn bij het maken ervan, omdat. vaak vakkundig (en competent) opgestelde TOR bepaalt het succes van al het werk. Het is de TOR die wordt overeengekomen met de klant, die meestal probeert zoveel mogelijk tegenstrijdige en buitensporige eisen te stellen. De taak van de Executeur is juist om zichzelf het leven gemakkelijker te maken. Maar nadat de handtekeningen aan beide kanten zijn gezet, is het te laat om iets opnieuw te spelen.
Algemene bepalingen
Het bestek wordt opgesteld op bladen van A4- en/of A3-formaat, in de regel zonder de velden van het blad in te vullen. Nummers van bladen (pagina's) worden bovenaan het blad boven de tekst aangebracht.Om wijzigingen en toevoegingen aan de technische achtergrond aan te brengen in de volgende stadia van de ontwikkeling van een programma of softwareproduct, wordt er een addendum bij vrijgegeven. Coördinatie en goedkeuring van de aanvulling op het bestek vindt plaats op dezelfde wijze als voor het bestek is vastgesteld.
De taakomschrijving moet de volgende onderdelen bevatten:
- naam en bereik;
- basis voor ontwikkeling;
- doel van ontwikkeling;
- technische vereisten voor het programma of softwareproduct;
- technische en economische indicatoren;
- stadia en stadia van ontwikkeling;
- procedure voor controle en acceptatie;
- toepassingen.
Sectie: Naam en reikwijdte
In hoofdstuk Naam en bereik vermeld de naam, een korte omschrijving van de reikwijdte van het programma of softwareproduct en het object waarin het programma of softwareproduct wordt gebruikt.In de sectie Basis voor ontwikkeling dient het volgende te worden aangegeven:
- document(en) op basis waarvan de ontwikkeling wordt uitgevoerd;
- de organisatie die dit document heeft goedgekeurd en de datum van goedkeuring;
- naam en (of) symbool ontwikkel onderwerpen.
Sectie: Doel van ontwikkeling
In hoofdstuk Doel van ontwikkeling het functionele en operationele doel van het programma of softwareproduct moet worden aangegeven. U kunt zich hier beperken tot een of twee zinnen. Het belangrijkste is om duidelijk te definiëren waar dit programma voor is.Bijvoorbeeld: Het programma is de kern van het geautomatiseerde werkstation (AWP) van de ontwikkelaar van continuous lineaire systemen automatisch besturingssysteem (ACS), waarmee de gebruiker de problemen van het analyseren van eenvoudige modellen kan oplossen.
Hoofdstuk: Technische vereisten voor het programma of softwareproduct
Deze sectie moet de volgende subsecties bevatten: - prestatie-eisen;
- betrouwbaarheidseisen;
- gebruiksvoorwaarden;
- vereisten voor de samenstelling en parameters technische middelen;
- vereisten voor informatie- en softwarecompatibiliteit;
- vereisten voor etikettering en verpakking;
- vereisten voor transport en opslag;
- speciale vereisten.
Sectie: Vereisten voor functionele kenmerken.
Hier moeten de vereisten voor de samenstelling van de uitgevoerde functies, de organisatie van invoer- en uitvoergegevens, temporele kenmerken, enz. Worden aangegeven.Bijvoorbeeld : Het programma moet toelaten ... te berekenen ... te bouwen ... te creëren ...
Begingegevens: een tekstbestand met een gegeven ...
Uitvoergegevens: grafische en tekstuele informatie - de resultaten van de analyse van het systeem ...; tekstbestanden - rapporten over ... het diagnosticeren van de status van het systeem en het rapporteren van eventuele fouten die zijn opgetreden.
betrouwbaarheid eisen. De vereisten voor het waarborgen van een betrouwbare werking (zorgen voor een stabiele werking, controle van invoer- en uitvoerinformatie, hersteltijd na storing, enz.) moeten worden gespecificeerd.
Het is moeilijk om hier iets te "raden". In het beste geval komt er een variant voorbij waarin uw programma alleen werkt met absoluut correcte gegevens. Meestal gaat de Klant hier niet mee akkoord, maar u kunt het proberen.
Bijvoorbeeld: het programma moet werken met een bepaalde uitgebreide incidentiematrix van de grafiek die wordt bestudeerd in overeenstemming met het functionerende algoritme, foutmeldingen geven als de initiële gegevens onjuist zijn gespecificeerd, de interactieve modus ondersteunen binnen het kader van de mogelijkheden die aan de gebruiker worden geboden .
Gebruiksvoorwaarden. De bedrijfsomstandigheden (omgevingsluchttemperatuur, relatieve vochtigheid enz. voor de geselecteerde typen gegevensdragers) moeten worden gespecificeerd waaronder gespecificeerde kenmerken, evenals het type dienst, het vereiste aantal en de kwalificaties van het personeel.
Met dit punt doen zich meestal geen moeilijkheden voor. Helaas wordt het punt over de professionaliteit van de gebruiker noodzakelijkerwijs geïmpliceerd door de klant. Dit is natuurlijk nog een reden om fouten in uw programma te vinden. Hier kunt u zich echter beperken tot zinnen als "De bedrijfsomstandigheden van het programma vallen samen met de bedrijfsomstandigheden van de IBM-pc en compatibele pc's", "Het programma moet zijn ontworpen voor een niet-professionele gebruiker." enzovoort.
Vereisten voor de samenstelling en parameters van technische middelen. Geef de vereiste samenstelling van technische middelen aan met een indicatie van hun technische kenmerken.
Het belangrijkste hier is om aan de ene kant niets te vergeten en alles te voorzien (anders glijden ze wat IBM PC / XT uit met een monochroom scherm en zonder muis), en aan de andere kant ga niet te ver met verhoogde eisen, anders zal de klant een meer meegaande opdrachtnemer vinden.
Bijvoorbeeld: U hebt een IBM PC-compatibele pc met een EGA (VGA) grafische adapter nodig. Vereiste schijfruimte - minimaal 600 KB, de hoeveelheid gratis werkgeheugen- niet minder dan 400 Kb. Het is wenselijk om een EMS-stuurprogramma en een muis te hebben.
Vereisten voor informatie en softwarecompatibiliteit. Kenmerken zijn hetzelfde als in de vorige paragraaf. Hier moeten de vereisten voor informatiestructuren bij de invoer en uitvoer en oplossingsmethoden, broncodes, programmeertalen worden aangegeven. Waar nodig moeten informatie en programma's worden beschermd.
Bijvoorbeeld: Het programma moet autonoom werken onder MS DOS versie 3.3 of hoger. De basisprogrammeertaal is Turbo Pascal 6.0.
De vereisten voor etikettering en verpakking en de vereisten voor transport en opslag zijn nogal exotisch. In het algemeen worden hier de vereisten voor het labelen van een softwareproduct, opties en verpakkingsmethoden aangegeven. En in de vereisten voor transport en opslag moeten de voorwaarden voor transport, opslagplaatsen, opslagomstandigheden, opslagomstandigheden, opslagperioden in verschillende omstandigheden worden aangegeven voor het softwareproduct.
Speciale vereisten zijn een zeer verantwoordelijke zaak. Het is het beste om ze zoveel mogelijk te vermijden. En kondig het meteen aan.
Bijvoorbeeld: Er zijn geen speciale eisen aan de tijdskenmerken van het programma. Er zijn geen speciale vereisten voor de capacitieve kenmerken van het programma.
Technische en economische indicatoren. Dit moeilijkste item voor een programmeur is er niet altijd. Het is vooral nodig wanneer het uw doel is om de enorme effectiviteit en het belang van het uitgevoerde werk te rechtvaardigen. Dit item werkt meestal heel goed voor de klant. Dit is in ieder geval de beste rechtvaardiging voor de timing en kosten van ontwikkeling.
Deze sectie moet aangeven: geschatte economische efficiëntie, geschatte jaarlijkse behoefte (bijvoorbeeld: het geschatte aantal oproepen naar het complex als geheel per jaar is 365 werksessies), de economische voordelen van de ontwikkeling in vergelijking met de beste binnen- en buitenlandse monsters of analogen.
Daarnaast is het wenselijk een definitie te geven van zowel de geschatte kosten van het ontwikkelen van een programma als de definitie van de complexiteit van programmeren.
Stadia en stadia van ontwikkeling (dit wordt hieronder in meer detail besproken) bepalen de noodzakelijke stadia van ontwikkeling, stadia en reikwijdte van het werk (een lijst met programmadocumenten die moeten worden ontwikkeld, overeengekomen en goedgekeurd), evenals, in de regel , de ontwikkelingstijdlijn en het bepalen van de uitvoerders.
De standaard stappen worden hier beschreven. Het belangrijkste is om de timing correct te bepalen. Probeer, indien mogelijk, de etappes gelijkmatig te verdelen in tijd (en hoeveelheid). Vergeet niet dat niet alle projecten waarmaken laatste fase. En rapporten zouden op elke fase moeten zijn. Onthoud ook dat het werkproject de meeste tijd in beslag zal nemen. Als u geen tijd heeft om de documentatie op tijd in te vullen, dan heeft de Klant het volste recht om het werk helemaal niet te accepteren met alle gevolgen van dien.
De belangrijkste en onmisbare stadia en stadia zijn de referentietermen zelf, voorlopig ontwerp, technische en werkprojecten.
Voorlopig ontwerp. In dit stadium worden de structuren van invoer- en uitvoergegevens in detail ontwikkeld, de vorm van hun presentatie wordt bepaald. Ontwikkeld algemene beschrijving algoritme, het algoritme zelf, de structuur van het programma. Er wordt gewerkt aan een actieplan voor de ontwikkeling en uitvoering van het programma.
Technisch project. Het bevat het ontwikkelde algoritme om het probleem op te lossen, evenals methoden om de initiële informatie te controleren. Het ontwikkelt ook tools voor foutafhandeling en het uitgeven van diagnostische berichten, bepaalt de presentatievormen van de initiële gegevens en de configuratie van technische middelen.
Werkend project. In dit stadium worden het programmeren en debuggen van het programma, de ontwikkeling van programmadocumenten, programma's en testmethoden uitgevoerd. Er worden test- en foutopsporingsvoorbeelden voorbereid. Documentatie en grafisch materiaal zijn afgerond. Meestal wordt gespecificeerd dat tijdens de ontwikkeling van het programma de volgende documentatie moet worden voorbereid:
Programmatekst;
Beschrijving van het programma;
Programma en testmethodiek;
Beschrijving van de aanvraag;
Handleiding.
Dit zijn standaard eisen. Als de klant ermee instemt dat niet al deze lijst kan worden ingediend, betekent dit dat zijn bedoelingen met betrekking tot u en uw product niet serieus zijn.
Afbeeldingen kunnen al dan niet beschikbaar zijn. Vooral als je niet gaat rapporteren over de resultaten van je werk. Maar voor serieuze projecten is dit item vereist.
Bijvoorbeeld: tijdens de ontwikkeling van het programma moet het volgende grafische materiaal worden voorbereid:
Technische en economische indicatoren;
Programmastructuur;
Presentatieformaat van de invoergegevens van het programma;
Algemeen schema van het algoritme (2 bladen);
o elementaire rekenalgoritmen;
een voorbeeld van hoe het programma werkt.
In de paragraaf Procedure voor controle en acceptatie staan de soorten testen en Algemene vereisten werk te aanvaarden. Geef indien mogelijk in deze paragraaf aan dat "controle en acceptatie van de ontwikkeling worden uitgevoerd op de door de Klant ter beschikking gestelde apparatuur", anders kan van u worden verlangd dat u de apparatuur meeneemt.
Bijvoorbeeld: Controle en acceptatie van ontwikkeling worden uitgevoerd aan de hand van controletests en debug-voorbeelden. Dit controleert de uitvoering van alle programmafuncties.
Geef in de bijlagen bij het bestek zo nodig aan:
een lijst van onderzoeks- en andere werken die de ontwikkeling onderbouwen;
Algoritmeschema's, tabellen, beschrijvingen, verantwoordingen, berekeningen en andere documenten die kunnen worden gebruikt bij de ontwikkeling;
Andere bronnen van ontwikkeling.
Op verzoek van de klant wordt deze software ontwikkeld voor het Windows-platform. Het programma moet werken onder de hoofdversies van dit platform: Windows98, Windows2000, WindowsXP. Bovendien zou het servergedeelte van het programma voor WinNT-versies moeten werken als een service (werk op de achtergrond).
Het is nodig om de mogelijkheid te waarborgen om de functies van het systeem (openheid voor ontwikkeling en de wijze van verbinden van nieuwe taken) verder te vergroten.
Transport- en opslagvereisten
Het besturingssysteem dat in ontwikkeling is, wordt als kit geleverd bij de verkoop van de RAID-controller. Het moet naar een afzonderlijke cd-rom worden geschreven, die de systeemstuurprogramma's en de benodigde documentatie voor de verkochte controller zal bevatten. Houd er rekening mee dat de grootte van de installatiebestanden niet groter is dan ongeveer 2/3 van een standaard cd-rom (700 MB).
Speciale vereisten
Het servergedeelte van het programma dat de werking van RAID analyseert, moet altijd worden uitgevoerd op een computer met een RAID-systeem. Als deze module wordt gestopt, is het zonder deze module onmogelijk om verbinding te maken met het RAID-systeem en is het onmogelijk om de werking van de RAID te controleren (melding van storingen verzenden en bestanden van de RAID-operatiegeschiedenis bijhouden).
Blokschema van het programma
Het hele softwareproject is gebaseerd op twee onafhankelijke modules. Zoals eerder vermeld, draait een ervan afzonderlijk op de computer met het RAID-systeem en de tweede op de computer van de beheerder. Kortheidshalve noemen we de eerste module tussenpersoon, en ten tweede - manager.
Manager– de gebruikerskant van het programma, die de programma-interface, de eerste installatiewizard en de helpsectie bevat. Manager beheert het RAID-systeem via tussenpersoon.
Tussenpersoon dient voornamelijk om commando's van te verzenden manager RAID-systeem en vice versa. Ook Tussenpersoon houdt zich bezig met het monitoren van de RAID (bijhouden van een logbestand) en het verwittigen van de beheerder in geval van fouten.
Netto
Rijst. 1.2. De hoofdstructuur van het programma GUIRAIDManager
De basisstructuur van het werk van het gehele werk als geheel wordt getoond in Fig. 1.2. Het toont verschillende opties voor de werking van de twee modules. Tussenpersoon En Manager:
Tussenpersoon(C3 ) draait op de computer en analyseert de werking van de RAID-array R2 ;
Manager vanaf een externe computer C2 of C4) kan worden gekoppeld aan A heer(C3) om de werking van de RAID-array te regelen R2 ;
Manager En Tussenpersoon draaien op één computer C1 om de werking van de RAID-array te beheren R2 . Voor deze optie is geen netwerkverbinding vereist.
Structuur van invoer- en uitvoergegevens
De belangrijkste gegevensuitwisseling in het systeem als geheel vindt plaats via twee kanalen:
tussen manager En tussenpersoon via het netwerk met behulp van het TCP / IP-protocol (commando's manager en antwoorden tussenpersoon);
tussen tussenpersoon en een RAID-controller via de RS-232-interface (ondervraging van de controller en reacties ervan).
Het algemene schema van gegevensuitwisseling in het project wordt geïllustreerd in Fig. 1.3.
Rijst. 1.3. Gegevensuitwisseling in het GUIRAIDManager-programma
Gegevensformaat tussen manager En tussenpersoon, maar ook tussen tussenpersoon en RAID-controller wordt beschreven in de paragraaf “Module data format Tussenpersoon» van deze rubriek.
Mijn taak in dit project is het ontwikkelen van een module Tussenpersoon. Laten we daarom de gegevensuitwisseling in de module eens nader bekijken Tussenpersoon tussen manager en RAID-controller. Gemodulariseerde structuur tussenpersoon weergegeven in afb. 1.4
Rijst. 1.4. Gegevensuitwisseling in de Agent-module
Dit diagram laat zien dat de gegevens tussen manager En tussenpersoon passeren de module voor het ontvangen en verzenden van gegevens via het netwerk. Connectiviteit testen manager deze module maakt gebruik van een autorisatieblok. Alle ontvangen gegevens worden geparseerd in het opdrachthandlerblok manager. Afhankelijk van het type opdracht wordt informatie ontvangen in het instellingenblok, of in het geschiedenisbestandsblok, of in de RAID-statuspollingmodule. De laatste dient om commando's naar de RAID-controller te sturen en er reacties van te ontvangen. Als er een fout optreedt tijdens het verzoek of als het antwoord van de controller een kritiek bericht bevat, zal de meldingsmodule de beheerder op de hoogte stellen van deze fout.
De subsectie "Vereisten voor informatie en programmacompatibiliteit" moet de vereisten specificeren voor informatiestructuren bij de invoer en uitvoer en oplossingsmethoden, broncodes, programmeertalen en softwaretools die door het programma worden gebruikt. Waar nodig moeten informatie en programma's worden beschermd.
Voorbeeld. De computer moet een besturingssysteem hebben dat niet lager is dan Windows 98/NT 4.0. De vereiste van informatiecompatibiliteit moet worden gegarandeerd door te werken met bestanden met geometrische informatie van een bepaalde structuur als invoer- en uitvoerinformatie.
Einde van het werk -
Dit onderwerp behoort tot:
Technologie voor softwareontwikkeling
Op de site site gelezen: "Software Development Technology" ...
Als u aanvullend materiaal over dit onderwerp nodig heeft, of als u niet hebt gevonden wat u zocht, raden we u aan de zoekfunctie in onze database met werken te gebruiken:
Wat gaan we doen met het ontvangen materiaal:
Als dit materiaal nuttig voor u bleek te zijn, kunt u het opslaan op uw pagina op sociale netwerken:
| tweeten |
Alle onderwerpen in deze sectie:
prestatie-eisen
De subsectie "Eisen voor functionele kenmerken" moet de vereisten aangeven voor de samenstelling van de uitgevoerde functies, de organisatie van invoer- en uitvoergegevens, de tijdkenmerken
Eisenovereenkomst
Het opstellen van een overeenkomst over eisen - het doel van het tweede deel van het eerste laboratorium werk. Ook is de overeenkomst over vereisten het tweede deel van het cursuswerk. Hieronder wordt gegeven op
Korte productbeschrijving
Kort beschreven en algemene concepten belangrijkste functionele eigenschappen van het product. Als het softwareproduct een uitbreiding is van een bestaand product, worden alleen de nieuwe eigenschappen ervan gekarakteriseerd.
Componenten van productresultaten
IN deze sectie een tabel vergelijkbaar met of gelijkwaardig aan tabel 2.1 wordt verstrekt. In dit geval werd een vooraf voorbereid drukformulier gebruikt, waardoor de tijd voor het voorbereiden van informatie wordt verkort.
Afgewezen aanvragen
Als het doel is om een product opnieuw te ontwerpen of uit te breiden, of om een product met bekende fouten te vervangen, plan dan om de op dat moment gevonden fouten te corrigeren. Daarom in deze alinea
Uitgesloten planitems
Als er planningsinstructies nodig zijn bijzondere eigenschappen en softwaremogelijkheden die niet kunnen worden geleverd als het product is ontwikkeld in overeenstemming met andere vereisten
Inbegrepen planitems
Als de noodzaak om een product te creëren wordt gerechtvaardigd door een document zoals een productvrijgaveplan, een batchvrijgaveplan of een taakbeschrijving, dan wordt ofwel een specifieke plaats uit elk document genoemd, ofwel
Lijst met gebruikersvereisten
De klanten van het product worden aangegeven en er wordt uitgelegd waarom ze het nodig hebben. Dit gedeelte geeft ook de verwachte levensduur van het product aan. Meestal is dit de levensduur van de apparatuur
Overwogen Alternatieven
Een korte beschrijving van de alternatieven voor deze ontwikkeling die zijn overwogen en afgewezen, evenals de redenen voor de afwijzing. Als er programma's moeten worden gekocht, leg dan uit waarom dat niet het geval is
Rendement op investering
De winst die de creatie van het product oplevert, wordt bepaald in termen die overeenkomen met het beoogde doel van de organisatie. Voorbeeld. ABC Services verwacht financiële verkopen
Systeem software
Systeemsoftware is alle andere software, inclusief besturingssystemen, compilers, hulpprogramma's, applicatiepakketten, enz. Het is software
Algemene kenmerken van functies
Het is noodzakelijk om het hele product als één functionele module te beschouwen, zodat het aantal subsecties klein is. Als het onmogelijk is om het product adequaat te beschrijven zonder het op te splitsen in afzonderlijke functies
Externe beperkingen
Geeft een overzicht van alle beperkingen waarvan de reikwijdte ruimer is dan de reikwijdte van het MT; dit omvat bijvoorbeeld branchebeperkingen of productreeksbeperkingen. Mag naar binnen
Compatibiliteitsbeperkingen
Verschillende aspecten van compatibiliteit moeten altijd in overweging worden genomen: brontaal, machinetaal, gegevens- en berichtindelingen, rapportindelingen, lijstindelingen en taakbeheertaal (JCT)-indelingen.
Softwarebeperkingen
Er wordt, indien nodig, aangegeven met welk besturingssysteem het voorgestelde softwareproduct moet werken, evenals andere softwaretools waarmee het in het proces moet worden gekoppeld.
Hardwarebeperkingen
Er wordt een tabel gegeven met apparaten die worden gebruikt bij de werking van het softwareproduct. Voor elk apparaat wordt het minimaal, nominaal en maximaal vereist aantal aangegeven. De nominale waarde is optimaal
Werk resultaten
Alle uitvoergegevens van een softwareproduct of functionele module worden beschreven in termen van hun inhoud en doel - rapporten, bestanden, records, gegevensvelden, berichten, tabellen, vlaggen. Zou moeten
Processen
De bewerkingen die worden uitgevoerd door het softwareproduct worden beschreven, dat wordt beschouwd als een geheel of door functionele modules als een zwarte doos (of een reeks zwarte dozen). Althans door instelling
Betrouwbaarheid
Onder softwarebetrouwbaarheid wordt verstaan het vermogen om de normale werking te herstellen in het geval van fouten en uitval van apparatuur. De bescherming van gebruikersgegevens is van het allergrootste belang. sl
Herstarten
Er zijn mogelijkheden gespecificeerd die het behoud en het gebruik van gegevens garanderen bij het hervatten van de werking na een noodonderbreking, bijvoorbeeld bij het herstarten vanaf een checkpoint. Voorbeeld 1. Programma
Naleving van de klant
Er worden eigenschappen gespecificeerd waarmee een softwareproduct of de uitvoer ervan aan specifieke vereisten kan voldoen. Noem, indien mogelijk, modules die mogelijk niet voldoen aan t
Operationele kenmerken
De belangrijkste variabele of het belangrijkste principe waarmee de effectiviteit van het programma moet worden gemeten, wordt gegeven; specificeert de juiste waarde of het bereik van waarden voor die variabele. Ch
Makkelijk te gebruiken
De eigenschappen die de interactie "mens - machine" voor een persoon gemakkelijk maken, worden beschreven. Voorbeelden zijn vrij invoerformaat, interactieve modus, syntactische compatibiliteit, mogelijk
Gemak van onderhoud
Er zijn maatregelen beschreven om de identificeerbaarheid van modules te waarborgen als dit probleem niet door de norm wordt opgelost. Voorbeeld 1. Elke bron- en objectmodule wordt voorzien van een softwarecodering.
Start de gebruikersinterface opnieuw
Voorbeeld. De systeemstatus voor alle actieve gebruikers (inclusief verbroken, maar nog steeds in gebruik) wordt periodiek op schijf opgeslagen (met een interval gespecificeerd binnen de definitie van tijden
Kenmerken van de gebruikersinterface
Voorbeeld. Ervan uitgaande dat alleen ASK op de machine draait en dat de herstelparameter wordt gekenmerkt door één controlepunt per minuut, moet elke instructie worden uitgevoerd of
Reikwijdte van de gebruikersinterface
Voorbeeld. In een typische sessie met ASK maakt een gebruiker zonder programmeerervaring verbinding met het systeem via een terminal en gaat een dialoog aan waarin hij het volgende definieert:
Gebruikersinterface-algoritme
Voorbeeld. ASK voert elk commando uit in interpretatieve modus en onmiddellijk; dus de accumulatie van commando's is niet toegestaan (met uitzondering van de geheugencommando's, die hieronder zullen worden besproken).
Hardwarebeperkingen
Voorbeeld. Naast de apparaten die nodig zijn voor VSOS ILSAM (zie 2.4.1 b en c), heeft de correctieprocessor de apparaten nodig die worden vermeld in tabel 2.3. Tabel 2.3 - Apparaten
Interne beperkingen
Het is belangrijk om niet alleen te bepalen wat het product zal zijn, maar ook wat het niet zal zijn. Een beperking is een functie (of mogelijkheid) die de gebruiker redelijkerwijs zou verwachten, maar die
Referentie documenten
Afzonderlijk wordt elk plannings- of technisch document aangegeven waarnaar in de ST een koppeling bestaat. Elk van deze documenten moet daadwerkelijk bestaan (en niet in de toekomst worden geïmpliceerd) en
Middelen om de uitvoering te waarborgen
De resources die nodig zijn om het systeem te installeren, worden bepaald samen met de resources beschreven in paragraaf 2.5.
Informatie dragers
Bepaalt het type opslagapparaten voor alle gedistribueerde componenten van het softwareproduct (bijvoorbeeld magneetband, gekenmerkt door het aantal tracks en opnamedichtheid
Vereiste relaties
De eisen die dit softwareproduct aan andere projecten of functies stelt, worden bepaald. gegeven een korte beschrijving van van elke vereiste en geeft aan in welk stadium deze kan worden geïnstalleerd
Geleverde relaties
Dit hoofdstuk is qua structuur vergelijkbaar met het vorige, maar bevat eisen die andere producten aan dit product stellen. Aan elke vereiste in paragraaf 2.6.1.2 moet worden voldaan door een vereiste van tijden
Technische Audit Commissie
Elke TA zou de oprichting van een Technische Auditcommissie (TRC) moeten aanbevelen, met vermelding van de werkplek van elk lid van de commissie en, indien mogelijk, zijn naam, evenals de benoeming
Niveaus testen
Testprogramma's kunnen in drie fasen worden georganiseerd, in drie modi worden uitgevoerd en tien categorieën omvatten (zie hoofdstuk 5 "Testen"). Deze informatie wordt gepresenteerd in de vorm van een tabel. Voor ka
Referenties ter vergelijking
De referentiesystemen waarmee de vergelijking moet worden gemaakt, zijn gedefinieerd. De kenmerken van dit systeem worden aangegeven in relatieve eenheden. Als er geen vergelijkingsstandaard is
Kennisgeving wijziging kalenderdata
Voorbeeld. Projectnaam: Productontwikkeling ASK Projectcode: C013. Productcode: L301A. Productnaam: ASK
Specificaties schrijven
Het schrijven van specificaties is het doel van het eerste deel van het tweede lab. Specificaties zijn ook het derde deel van het cursuswerk. In de specificatiefase
Algemene testprincipes
De testfase is meestal goed voor de helft van de kosten van het creëren van een systeem in financiële termen. Slecht gepland testen leidt tot een aanzienlijke toename van de ontwikkeltijd.
Organisatie van het testen van softwareproducten
Testen wordt niet opgevat als debuggen, dat is bedoeld om vast te stellen waarom een bepaalde fout in het programma optreedt en de oorzaken ervan weg te nemen, maar het proces van het vaststellen van het feit zelf van de aanwezigheid van defecten.
Soorten testen van softwareproducten. Test stadia
Over het algemeen worden tests uitgevoerd in verschillende fasen, gescheiden door de tijd. De eerste fase zijn de klasse A-tests, die worden uitgevoerd aan het einde van de programmeerfase.
Programmeer testmodi
Tests variëren afhankelijk van wie ze uitvoert. Het belangrijkste idee is de onafhankelijkheid van de testfunctie van de ontwikkelfunctie. Testmodus I impliceert vol
Testcategorieën voor softwareproducten
De testfasen geven aan wanneer de tests worden uitgevoerd en de modi bepalen wie ze uitvoert. Testcategorieën bepalen de aard en het doel van de tests. Doordachte indeling en
Testtechnologie, equivalentieklassen
Een manier om de gestelde vraag te bestuderen, is door een teststrategie te bestuderen die black box-strategie, datagestuurd testen of testen wordt genoemd.
Testen bouwen
Het testopbouwproces omvat: 1) het toekennen van een uniek nummer aan elke equivalentieklasse; 2) het ontwerpen van nieuwe tests, die elk aan bod komen
Algemene bepalingen
1.1. De structuur en het ontwerp van het document zijn vastgesteld in overeenstemming met GOST 19.105-78. 1.2. De System Programmer's Guide moet de volgende secties bevatten: -
Programma structuur
Programma "Geautomatiseerd werkplaats reader" bestaat uit de volgende componenten: 1) zcon - een applicatie die de functies van de Z39.50-client implementeert; 2) zgate-CGI-
Programma installatie
Dit document gebruikt de syntaxis die is gedefinieerd door ISO/IEC 9945-1 voor het benoemen van bestanden. In die besturingssystemen die de opgegeven manier van naamgeving aan bestanden in toepassingen niet ondersteunen
Programma controle
Het programma wordt gecontroleerd door de methode van uitvoering. Vanwege het feit dat de specifieke voorwaarden voor het gebruik van het programma (adressen van Z39.50-servers, databasenamen, ondersteunde punten
Extra functies
Een bijkomend kenmerk van het programma is de mogelijkheid om de presentatievorm van records dynamisch te regelen wanneer ze in volledig formaat worden bekeken ("Gedetailleerde informatie") met behulp van
Berichten aan de systeemprogrammeur
Tabel 5.1 toont de berichten die een systeemprogrammeur kan ontvangen tijdens de installatie, de programmaverificatie en een gebruiker tijdens de uitvoering van het programma.