Ugrás a fő tartalomra

Minőségellenőrzési módszerek -SW fejlesztési folyamat


Minőségellenőrzési módszerek
A dokumentumminősítési szempontok teljesülése, illetve a szempontoknak való megfelelés mértéke nem állapítható meg
 9
közvetlenül. Ezért a dokumentumok tulajdonságait további olyan jelenségekre kell bontani, melyek közvetlenül vizsgálhatók.

A vizsgálandó jelenségek kiválasztásakor a gyenge pontokra való figyelemfelhívás, és a jelenségeknek egy tetszőleges dokumentumra érvényes rendszerezése az elsődleges kiindulási szempont.  A jelenségek csoportosítása a dokumentáció – dokumentum – fejezet - kijelentés hierarchiát követi.  A jelenségek rögzítésének és osztályozásának segédeszköze a hibalista. A hibalistában a hiányosságoknak három osztálya különböztethető meg az általuk előidézhető káros események súlyosságától függően, ezek: a súlyos, a közepes és az enyhe hiba. 

Súlyos hibáról akkor beszélünk, ha az általa dokumentált rendszer hibás alkalmazásához vezet.  Közepes hiba az, amely kétséget ébreszt az olvasóban a dokumentum elkészítésének gondosságát, a benne található információ megbízhatóságát és helytállóságát illetően.  Minden más hiba enyhe hibának számít. 

A kijelentésekre vonatkozó hibák lehetnek súlyos hibák (tényszerűleg hibás, nem teljes, nem világos, félreérthető, felületes, formálisan hibás), közepes hibák (nem biztosan elégséges, nyelvtanilag hibás) és enyhe hibák (a szóhasználat nem teljesen megfelelő, felesleges, túl részletezett).
 10
A kijelentéseket egymáshoz való viszonyuk, környezetükkel való konzisztenciájuk szempontjából is vizsgálni kell. Ez a következő hiányosságok fennállásának ellenőrzését igényli: • Súlyos hibák: – ellentmondás valamivel,        – hibás utalás,        – hiányzó magyarázat; • Közepes vagy enyhe hibák:   – a dokumentumban idegen a kifejezés,  – a magyarázat nem folyamatos,  – nem megfelelő a sorrend,  – nem egységes szövegezésű más kijelentéssel,  – nem egységes jelölésű más kijelentéssel,  – felesleges ismétlése valaminek.

A következő vizsgálandó hierarchiaszint a fejezet. Ennél a következő, pozitív ismérvek meglétét kell ellenőrizni:  – teljesség,  – áttekinthetőség,  – a tartalom homogenitása,  – az ábrázolás pontossága,  – érthetőség az adott részen belül,  – témahűség,  – olvashatóság,  – a leírás pontossága. 

Címkék:

Megjegyzések

Megjegyzés küldése

Népszerű bejegyzések ezen a blogon

SW Documentation: Requirements

Requirements Nonfunctional Requirements Q&A FEBRUARY 17, 2010  ~  ANDREW STELLMAN ~  3 COMMENTS Non-functional requirements Q&A: We answer questions from readers about using  nonfunctional requirements  on a real software project, and how to use them on a real software project. Non-functional requirements: Planning out how well your software will work A couple of months ago I wrote a post called  Using nonfunctional requirements to build better software . It’s basically a step-by-step guide for creating an easy, practical technique to use nonfunctional requirements on a real software project, treating them in a way that’s similar to how a lot of Agile teams treat user stories, scenarios and other functional requirements: by sticking them on index cards and using them to do some lightweight planning. Since then, I’ve gotten a lot of questions about nonfunctional requirements (or, as some people call them, non functional requirements...
Megjegyzés küldése
További információk

Privacy Notice for Visitors to Our Users’ Sites

Privacy Notice for Visitors to Our Users’ Sites Sections Who’s Who and What This Privacy Notice Covers Information We Collect About Visitors to Our Users’ Sites Information a Visitor Provides to a Site Information We Automatically Collect from the Site Other Information Provided by Our Users How We Use Visitor Information How We Share Visitor Information Other Tools Other Resources Hi there! This Privacy Notice explains how we, at Automattic, process information about the visitors of our users’ websites in connection with the services we provide through WordPress.com, Jetpack (including WooCommerce Services), IntenseDebate, Polldaddy.com, and Akismet. Read on! Who’s Who and What This Privacy Notice Covers Let’s talk first about who we are at Automattic, what we do, and what this Privacy Notice covers. We are the folks behind a variety of products and services designed to allow anyone–from bloggers, to small business owners, and enterprises–to create, publ...
Megjegyzés küldése
További információk

THE RIGHT WAY TO WRITE A SINGLETON

THE RIGHT WAY TO WRITE A SINGLETON July 17, 2015 by   Hector Matos Even though I've written about the woes of managing state in my previous post, sometimes there's just no way we can avoid it. One example of managing state is something we're all quite acquainted with - The Singleton. The problem we find in Swift is that there are SEVERAL ways of implementing them. But which way is the right way? In this post I'm going to show you the history of the singleton and then show you the right way to implement the singleton in Swift. If you want to see the right way to implement the singleton pattern in Swift along with proof of it's "right-ness", you can scroll to the bottom of the post and see it there. :) A TRIP DOWN MEMORY LANE Swift is a natural evolution of Objective-C. In Objective-C, this is how we implemented the singleton: @interface Kraken : NSObject @end @implementation Kraken + ( instancetype ) sharedInstance { ...
Megjegyzés küldése
További információk