<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Yazılım Kalite Güvencede Ara Tasarım Değerlendirme Yaklaşımı</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>İlgi Keskin Kaynak</string-name>
          <email>ikkaynak@aselsan.com.tr</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Anahtar Kelimeler: Yazılım Kalite Güvencesi, Ara Tasarım Değerlendirme, Yazılım Geliştirme Süreci, Yazılım Geliştirme Yaşam Döngüsü, İşlevsel Konfigürasyon Tetkiki</institution>
          ,
          <addr-line>Fiziksel Konfigürasyon Tetkiki</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Programlar ve Tasarım Kalite Yönetimi Müdürlüğü, Kalite Yönetim Dir., REHİS Sektör Bşk. ASELSAN A.Ş</institution>
        </aff>
      </contrib-group>
      <fpage>725</fpage>
      <lpage>732</lpage>
      <abstract>
        <p>Özet. ASELSAN Radar ve Elektronik Harp Sistemleri (REHİS) Sektör Başkanlığı; AQAP-2310, AS9100C, CMMI-DEV v1.3 ve ISO 20000 uluslararası sertifikasyonlarına sahiptir. Bu model ve standartların gereği olarak; ASELSAN REHİS Yönetim Sistemi'nde tanımlı olan tüm süreçler gibi tasarım, geliştirme ve ilgili kalite güvence faaliyetleri de etkinleştirilmektedir. ASELSAN REHİS'te yürütülen kalite güvence faaliyetlerinin etkinliğini arttırmak amacıyla; mevcut yazılım kalite güvence faaliyetlerine ilaveten Ara Tasarım Değerlendirme (ATAD) faaliyetleri tanımlanmıştır. ATAD faaliyetleri ile yazılım kalite güvencesinin yazılım geliştirme yaşam döngüsüne paralel olarak yürütülmesi; böylece süreç ve ürün ile ilgili muhtemel uygunsuzlukların daha erken tespit edilerek gerekli düzeltici faaliyetlerin daha erken aşamalarda başlatılıp tamamlanması hedeflenmektedir. Sonuç olarak; yazılım kalite güvence faaliyetlerinin etkinliğinin artması beklenmektedir. Yazılım seviyesinde gerçekleştirilecek pilot çalışmanın sonucu değerlendirilerek, bu bakış açısı sistem ve donanım geliştirme süreçlerinde de dikkate alınabilecektir.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Giriş</title>
      <p>yazılım geliştirme sürecinin belirli aşamalarında ara değerlendirmeler yapılması ve
proje yaşam döngüsü boyunca yürütülen yazılım kalite güvence faaliyetlerinin
sağladığı katma değerin arttırılmasıdır. Yapılan pilot çalışmada Yazılım Kalite
Güvence faaliyetleri ile olası bulguların daha erken aşamalarda tespit edilmesi ve
daha kısa sürede bulguların çözülmesi hedeflenmiştir. Bu amaçla toplanan ölçümler
analiz edilerek çıkarımlarda bulunulmuştur.</p>
      <p>ATAD faaliyetleri; ilk olarak yazılım geliştirme ve yazılım test faaliyetlerine
uygulanacak, başarılı görülmesi durumunda sistem/donanım geliştirme ve tasarım tedarik
süreçleri için de dikkate alınabilecektir.</p>
      <p>Makalenin organizasyonu şu şekilde özetlenebilir; Giriş bölümünde çalışmanın
amacı ve kapsamına ilişkin açıklama yapılmıştır. Girişin ardından gelen Literatür
Araştırması Bölümü’nde bu konuda daha önce gerçekleştirilmiş olan ve incelenen
örnek uygulamalar hakkında bilgi verilmiştir. Daha sonra bu örneklerin incelenmesi
üzerine mevcut yazılım kalite güvence faaliyetlerine ek olarak yazılım geliştirme
süreci boyunca uygulanan ATAD faaliyetleri açıklanmış ve yapılan pilot çalışma
anlatılarak sonuçları değerlendirilmiştir.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Literatür Araştırması</title>
      <p>Yazılım kalite güvencesi faaliyetleri ile ilgili literatür taraması yapıldığında bu
konuda yapılan pek çok uygulama incelenmiş ve bunlar arasından aşağıda verilen iki
örnek için anlatıma yer verilmiştir. ATAD faaliyetleri tanımlanırken literatürde
karşılaşılan iyi uygulamalar dikkate alınmıştır.</p>
      <p>
        Örnek Uygulama-1: AT&amp;T Bell Laboratuvarları Kalite Güvence Merkezi
tarafından Yazılım Geliştirme Süreç Denetimleri için gerçekleştirilen çalışmada, bir proje
yaşam döngüsü boyunca incelenmiş ve proje yeterince erken denetlendiğinde
bulgulara verilen yanıtların, geliştirilen ürünün kalitesini ve yazılım geliştirme sürecinin
işleyişini iyileştirebileceği değerlendirilmiştir. Denetimlere yazılım mühendisleri ve
yöneticileri katılmıştır. Bu çalışmada projenin, yazılım geliştirme sürecinin ve yazılım
ürünlerinin iyileştirilerek kalitesinin arttırılması için öneriler sunulmuştur. Bunun yanı
sıra denetimlere verilen yönetim desteğinin söz konusu kalite güvence faaliyetlerinin
proje ekibi tarafından tehdit unsuru olarak anlaşılmamasını sağladığı
değerlendirilmiştir.[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]
      </p>
      <p>
        Örnek Uygulama-2: STR LLC and Hilary Benoit, W R Systems, Limited
Şirketi’nde “Kalite Güvence Fonksiyonunu Yazılım Geliştirme Yaşam Döngüsü’ne
Entegre Etme” konusunda yapılan bir çalışmada ise kalite güvence fonksiyonunun
gereksinim yönetimine gereksinimlerin tanımlanması aşamasından itibaren katılım
sağlamasının ve kalite güvence, konfigürasyon yönetimi ve teknik birimlerin
yöneticileri arasında iş birliği sağlanmasının önemi vurgulanmıştır.[
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]
      </p>
    </sec>
    <sec id="sec-3">
      <title>Yazılım Kalite Güvence Faaliyetlerini Etkinleştirme Çalışması</title>
      <p>Bölüm 2’deki örnek uygulamalar dikkate alınarak, kalite güvence fonksiyonu
tarafından değerlendirilen tasarım faaliyetlerinin sadece olumsuz yönlerinin değil, olumlu
yönlerinin de raporlanması kararı alınmıştır. Bunun yanı sıra çalışmaya tasarım ekibi
de dahil edilerek ATAD faaliyetlerinin tanımlanması aşamasında sunulan iyileştirme
önerileri dikkate alınmıştır.</p>
      <p>
        Literatür araştırmasında yer verilen örnekler incelendiğinde yazılım geliştirme
sürecinin başından itibaren bağımsız bir bakışla tasarım faaliyetlerinin daha yakından
takip edilmesinin, kalite fonksiyonunun tasarım süreçlerine dahiliyetini arttıracağı
öngörülmüştür.[
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]
3.1 ATAD Faaliyetleri
Yazılım kalite güvence faaliyetlerinin etkinliğini arttırmak amacıyla mevcut yazılım
kalite güvence faaliyetlerine ek olarak önerilen ATAD faaliyetleri Şekil-1’de
gösterilmektedir. Şekil-1’deki gösterim Yazılım Geliştirme Süreci üzerinden
verilmiştir. Sürecin her bir adımının sonunda yatay/dikey oklar ile belirtilen ATAD
faaliyetleri YKGM tarafından bağımsız olarak yürütülmektedir. “Yazılım Tasarımını
Tanımla” adımı mevcut Yazılım Geliştirme Süreci’nde ayrı bir adım olarak tanımlı
değildir. Yazılım İyileştirme Ekibi tarafından kabul edilen süreç iyileştirme önerisine
istinaden yapılacak pilot çalışma için gösterimde yer verilmiştir.
      </p>
      <p>Şekil 1: Yazılım ATAD Faaliyetleri
Şekildeki gösterim Şelale Modeli’ne göre hazırlanmıştır. SCRUM gibi çevik
yazılım geliştirme yöntemleri uygulanan yazılım geliştirme faaliyetlerinde, ATAD
faaliyetleri herhangi bir sürüm için gerçekleştirilecektir. ATAD faaliyetleri ile
koşularda (iterasyon) gerçekleştirilen yazılım geliştirme yaşam döngüsü adımları detaylı
olarak değerlendirilmiş olacaktır. Böylece sistem entegrasyon testine girecek olan
yazılım sürümleri ile ilgili olası eksiklikler yazılım geliştirme faaliyetlerine paralel
olarak saptanabilecektir. ATAD faaliyetleri şu aşamalardan oluşur:</p>
      <p>Planlama. Yılın her çeyreği için proje takvimine ve tasarım ekibinin iş planına
uygun olarak yapılır. ATAD planı, yazılım geliştirme ve yazılım test ekipleri ile
paylaşılır.</p>
      <p>Hazırlık. ATAD planında değerlendirme dönemine giren proje kapsamında
yazılım geliştirme süreci ve ilgili diğer süreç varlıkları incelenir. Projede uygulanan
yazılım geliştirme yöntemi analiz edilir. ATAD hazırlık sorularına yanıt aranır.
(Örnek için bkz. Tablo-1 Yazılım Gerçekleme ATAD Soru Listesi Bölüm A.)</p>
      <p>Değerlendirme ve Raporlama. Bu aşamada soru listesinin B bölümünde yer alan
değerlendirme soruları sorulur. (Örnek için bkz. Tablo-1 Yazılım Gerçekleme ATAD
Soru Listesi Bölüm B.) Tasarım faaliyetlerinin iyileştirmeye açık yönleri ile birlikte
güçlü yönleri de raporlanır.. YKGM tarafından yapılan değerlendirme neticesinde
(varsa) iyileştirme önerileri ilgili paydaşlara sunulur. Değerlendirmede kullanılan soru
listesinin bir örneği Tablo-1’de verilmiştir.</p>
      <sec id="sec-3-1">
        <title>ATAD # İş Ürünleri Katılımcılar</title>
      </sec>
      <sec id="sec-3-2">
        <title>Girdiler</title>
        <p>K
I
L
R
I
Z
A
H
.</p>
        <p>A</p>
      </sec>
      <sec id="sec-3-3">
        <title>YAZILIM GERÇEKLEME</title>
      </sec>
      <sec id="sec-3-4">
        <title>Elektronik Dosya İçeriği, Yazılım Versiyon</title>
      </sec>
      <sec id="sec-3-5">
        <title>Tanımı, Medya</title>
      </sec>
      <sec id="sec-3-6">
        <title>Yazılım/Yazılım Test Ekip Liderleri, YKB</title>
      </sec>
      <sec id="sec-3-7">
        <title>Sorumlusu</title>
      </sec>
      <sec id="sec-3-8">
        <title>Yazılım Geliştirme Planı (YGP)/Sürüm</title>
      </sec>
      <sec id="sec-3-9">
        <title>Planı, Yazılım Gereksinim Özellikleri</title>
        <p>(YGÖ), Yazılım Tasarım Tanımı (YTT),
(varsa) Veritabanı Tasarım Tanımı (VTTT),</p>
      </sec>
      <sec id="sec-3-10">
        <title>Yazılım Beyaz Kutu Testleri Kayıt Formu,</title>
      </sec>
      <sec id="sec-3-11">
        <title>Birim Test Tanımı (BTET), Birim Test</title>
      </sec>
      <sec id="sec-3-12">
        <title>Raporu (BTER)</title>
        <p>1
2
3
4</p>
        <p>Daha önce yapılan ATAD
faaliyet(ler)inde saptanan ve bu faaliyete girdi
oluşturan uygunsuzluk(lar) kapatılmış mı?</p>
        <sec id="sec-3-12-1">
          <title>Yazılım geliştirme faaliyetleri planlanmış</title>
          <p>ve tüm paydaşların katılımı sağlanmış mı?
Yazılım gerekleri tanımlanarak temeli
alınmış ve tüm paydaşların katılımı
sağlanmış mı?
YTT ve/veya VTTT temeli alınmış ve tüm
paydaşlara duyurulmuş mu?
Yazılım tasarımı ve veri tabanı tasarımı
tanımlamaları yapılarak temeli alınmış ve</p>
        </sec>
      </sec>
      <sec id="sec-3-13">
        <title>ATAD İşlem</title>
      </sec>
      <sec id="sec-3-14">
        <title>Maddeleri</title>
      </sec>
      <sec id="sec-3-15">
        <title>Listesi,</title>
      </sec>
      <sec id="sec-3-16">
        <title>Bildirim Takip</title>
      </sec>
      <sec id="sec-3-17">
        <title>Dosyası</title>
      </sec>
      <sec id="sec-3-18">
        <title>YGP, Gözden</title>
      </sec>
      <sec id="sec-3-19">
        <title>Geçirme Tutanağı (GGT)</title>
      </sec>
      <sec id="sec-3-20">
        <title>YGÖ, DOORS, GGT</title>
      </sec>
      <sec id="sec-3-21">
        <title>YTT, VTTT,</title>
      </sec>
      <sec id="sec-3-22">
        <title>DOORS, GGT</title>
        <p>Tasarım elektronik dosya, medya ve
yazılım versiyon tanımı içerikleri sürüm
planına uygun olarak hazırlanmış ve tüm
paydaşların katılımı sağlanmış mı?</p>
        <sec id="sec-3-22-1">
          <title>YGP'de kullanılması öngörülen kodlama</title>
          <p>standartlarına uygun olarak geliştirme
yapılmış mı?
YGP’de gözden geçirileceği belirtilen kod
kesimleri gözden geçirilmiş mi?</p>
        </sec>
        <sec id="sec-3-22-2">
          <title>Beyaz kutu/birim test yapılacak YKB’ler seçilmiş ve yazılım beyaz kutu/birim testleri yapılmış mı?</title>
        </sec>
      </sec>
      <sec id="sec-3-23">
        <title>Elektronik</title>
      </sec>
      <sec id="sec-3-24">
        <title>Dosya İçeriği, Yazılım</title>
      </sec>
      <sec id="sec-3-25">
        <title>Versiyon</title>
      </sec>
      <sec id="sec-3-26">
        <title>Tanımı, Medya,</title>
        <p>YGP/Sürüm</p>
      </sec>
      <sec id="sec-3-27">
        <title>Planı</title>
      </sec>
      <sec id="sec-3-28">
        <title>YGP, Kaynak Kod Kod GGT, YGP</title>
      </sec>
      <sec id="sec-3-29">
        <title>Yazılım Beyaz</title>
      </sec>
      <sec id="sec-3-30">
        <title>Kutu Test Formu,</title>
      </sec>
      <sec id="sec-3-31">
        <title>YGÖ, Birim</title>
      </sec>
      <sec id="sec-3-32">
        <title>Test Tanımı,</title>
      </sec>
      <sec id="sec-3-33">
        <title>Birim Test</title>
      </sec>
      <sec id="sec-3-34">
        <title>Raporu</title>
        <p>
          Tablo 1. Örnek (Yazılım Gerçekleme) ATAD Soru Listesi
Takip Etme. Katılımcılardan gelen öneriler ve görüşler dikkate alınarak işlem
maddeleri takip edilir ve gerekli düzeltici faaliyetlerin tamamlandığı teyit
edildiğinde ATAD faaliyeti sonlandırılır. Son olarak ATAD performansı
değerlendirilerek ATAD faaliyetlerinin etkinleştirilmesine yönelik önlemler de
alınabilir. Bu önlemler bir sonraki çeyrek yılın planlamasına girdi oluşturur.[
          <xref ref-type="bibr" rid="ref4">4</xref>
          ]
        </p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Pilot Çalışma</title>
      <p>ATAD faaliyetleri Mayıs 2014’te tanımlanmış ve radar, elektronik destek ve
elektronik taarruz alanlarında faaliyet gösteren dört projede uygulanmıştır. ATAD
faaliyetlerinde tespit edilen bulgular ile ASELSAN REHİS Yönetim Sistemi’nde
halihazırda tanımlı olan işlevsel/fiziksel konfigürasyon tetkiklerinde tespit edilen
bulgular kategorilere ayrılarak kapatılma süreleri karşılaştırıldığında Şekil-2’deki
veriler elde edilmiştir. Bulgu kategorileri grafiğin yatay ekseninde belirtilmiştir.</p>
      <p>266 91%
155
8</p>
      <p>88%
165
Şekil-2’de karşılaştırılan İKT/FKT faaliyetleri YKB’ye ait tüm yazılım geliştirme
süreci çıktılarının toplu olarak değerlendirildiği konfigürasyon tetkikleri iken ATAD
faaliyetleri yazılım geliştirme sürecine paralel olarak gerçekleştirilen ara
değerlendirmelerdir. Pilot çalışmadan toplanan veriler ATAD faaliyetlerinde açılan
bulguların kapatılması için geçen gün sayısının, yazılım geliştirme sürecinin sonunda
gerçekleştirilen İşlevsel/Fiziksel Konfigürasyon Tetkikleri’nde (İKT/FKT) açılan
bulgulara göre yukarıda verilen oranlarda kısaldığını göstermiştir. Örneğin
“Sistem/Arayüz Tasarımı” kategorisindeki bulgular İKT/FKT’lerde 155 günde
kapatılırken ATAD faaliyetlerinde saptandığında 8 günde kapatılabilmiştir. Bu durum
önemli ölçüde iyileşme olduğunu göstermektedir. Şekil-2’den de görülebilediği gibi
bulguların kapatılma sürelerindeki iyileştirme yazılım geliştirme sürecinin ilk
adımları için %75-95 civarında iken sonraki adımları için %38-58 aralığındadır.
Bunun nedeni şu şekilde yorumlanmıştır: ATAD faaliyetleri yazılım geliştirme
sürecine paralel olarak gerçekleştilirken İKT/FKT tetkikleri süreç sonlandıktan sonra
gerçekleştirilmektedir. Kalite faaliyetlerinin yazılım geliştirme sürecine paralel olarak
yapılması tasarım faaliyetlerinin planlanmasına ve takibine katkı sağladığı için
tasarım ekibinden hızlı yanıt alınarak bulguların daha kısa sürede kapatılması
sonucunu doğurmuştur. Ortaya çıkan bu sonucun, projenin son aşamalarında yapılan
İKT/FKT’lerde tasarım ekibinin birden fazla projede görev alması nedeniyle, tetkik
edilen projeye geri dönüp bulguları kapatmaya yoğunlaşmasının vakit almasından
kaynaklandığı değerlendirilmiştir. Şekil-2’de ATAD faaliyetlerinde tespit edilen
bulguların kapatılma sürelerinin özellikle yazılımın detaylı tasarımı, gerçeklenmesi ve
doğrulanması aşamaları sırasında artış gösterdiği görülmektedir. ATAD’larda tasarım
ekibine açılan işlem maddeleri SCRUM koşuları boyunca kapatılmakta ve iş takibinin
yapıldığı koşu dosyalarına girdi oluşturmaktadır. ATAD faaliyetlerinde tespit edilen
bulguların planlanan İKT/FKT faaliyetlerine göre kaç gün öncesinde saptandığı ise
Şekil-3’te verilmiştir.</p>
      <p>Şekil 3: Bulgu tespitindeki iyileşme (gün sayısı)</p>
      <p>
        Bulguların ortalama tespit zamanı ve kapatılma sürelerinde görülen iyileşmeler
doğrultusunda ATAD faaliyetlerinin ASELSAN REHİS Yönetim Sistemi’ne katma
değer sağladığı sonucuna varılmıştır.[
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]
5
      </p>
    </sec>
    <sec id="sec-5">
      <title>Değerlendirme ve Gelecekteki Çalışmalar</title>
      <p>
        Bölüm-4’te değinildiği gibi ATAD ve İKT/FKT’lerde saptanan bulgular aynı
kategorilerdeki bulgular olmuştur. Böylece aynı tipteki veriler karşılaştırılarak nicel bir
analiz yapma fırsatı doğmuştur. Bulgu kategorileri yazılım geliştirme sürecinin
çıktıları ile örtüşmektedir. Söz konusu çalışmada yapılan analiz sırasında ATAD
bulguları ile birlikte mevcut İKT/FKT bulguları da daha detaylı olarak incelenmiştir.
Buna göre yazılım/yazılım test planlama, yazılım mimari tasarımı ve test yazılımı
doğrulama gibi sürecin başında yapılması gereken işlem maddelerinin İKT/FKT’ler
sonucunda ortalama olarak 200 günden daha uzun sürelerde kapatılabildiği göze
çarpmaktadır. ATAD faaliyetleri ile bu süre yaklaşık olarak 50 gün civarına
düşmüştür. Buradan aynı tipteki bulguların daha erken tespit edilmesinin bulguların
kapatılma süresine olan etkisi de görülebilmektedir. Bu durum yazılım kalite güvence
faaliyetlerinin etkinliğinin arttığını göstermiştir. Pilot çalışmada toplanan ölçümlerin
analizi ve çalışmaya dâhil olan tasarım ekiplerinden alınan geri dönüşler neticesinde
ATAD faaliyetlerinin kurumsal seviyede yaygınlaştırılmasının uygun olacağı
değerlendirilmiştir. ATAD faaliyetlerinin sırasıyla sistem ve donanım geliştirme süreçlerine
de uygulanması planlanmaktadır.
Yapılan pilot çalışma kapsamında seçilen iki adet tasarım altyüklenici firmanın
ASELSAN REHİS için geliştirdikleri ürünler de değerlendirilmiş ve ilgili firmalara
bulgular açılarak takip edilmiştir. Tasarım altyüklenicileri ile koordinasyonu
arttırması ve teslim alınan ürünlerin kalitesinin arttırılması açısından da ATAD
faaliyetlerinin fayda sağlayacağı değerlendirilmiştir. Bu amaçla ATAD soru listelerinin tasarım
altyüklenici faaliyetleri için uyarlanarak kullanılması uygun görülmüştür.[
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]
      </p>
    </sec>
    <sec id="sec-6">
      <title>Kaynaklar</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>Software</given-names>
            <surname>Development Process Audits - A General Procedure</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Stewart G.</given-names>
            <surname>Crawford &amp; M. Hosein</surname>
          </string-name>
          <string-name>
            <surname>Fallah</surname>
          </string-name>
          , AT&amp;T Bell Laboratories, New Jersey USA
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>Integrating</given-names>
            <surname>Quality</surname>
          </string-name>
          <article-title>Assurance into the Software Development Life Cycle, Leslie Tierstein</article-title>
          ,
          <string-name>
            <given-names>STR LLC</given-names>
            and
            <surname>Hilary Benoit</surname>
          </string-name>
          ,
          <string-name>
            <given-names>W R</given-names>
            <surname>Systems</surname>
          </string-name>
          , Ltd.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3] IEEE 1028
          <article-title>-2008 IEEE Standard for Software Reviews</article-title>
          and Audits
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <source>[4] Survey on Impact of Software Metrics on Software Quality, Mrinal Singh Rawat</source>
          , Arpita Mittal, Sanjay Kumar Dubey, Boeing. USA
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>Software</given-names>
            <surname>Quality</surname>
          </string-name>
          &amp;
          <string-name>
            <surname>Productivity</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          <string-name>
            <surname>Fuchs</surname>
          </string-name>
          &amp; S.G. Chappell, AT&amp;T Bell Laboratories New Jersey USA
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>A</given-names>
            <surname>Theory of Quality Management Underlying The Deming Management Method</surname>
          </string-name>
          , John. C.
          <string-name>
            <surname>Anderson</surname>
          </string-name>
          , Manus Rungtusanatham, Roger G. Schroeder, University of Minnesota
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>