Yazılım Gereksinimleri & Sistem Gereksinimleri (tekrar)

Transkript

1 Yazılım Gereksinimleri & Sistem Gereksinimleri (tekrar)

2 DörtDeğişkenModeli [ Four variable models (FVM)] Parnas vemadey1995 Tanımlanacak olan sistem to-be modeli gerçeği otomatik olarak ölçümleyebilir ve kontrol edebilir. sistem-to-be kontrol edilebilir parametreler ile belirlenebilir. Bu ölçümler ve kontroller de giriş ve çıkış aygıtları ile gerçekleştirilebilir(implemente edilebilir). Bunlar: Gözlenmiş değişkenler (monitored variables (M) ): ç:evreyi (environment) gözlemler. Kontrol değişkenleri ( controlled variables (C) ) :çevrenin kontrolünü sağlar Giriş değişkenleri (input variables (I)) : sistemin gözlemledikleri değişkenlerdir. Çıkış değişkenleri (output variables (O) ): sistemin kontrol değişkenini değiştirir.

3 Dört Değişken Modeli FVM Parnas' ın 4 değişken modeli: C, controlled variables; I, input variables; IN, input devices; M, monitored variables; NAT, natural constraints; O, output variables; OUT, output devices; REQ, system requirements; SOFT, software FVM, sistem to-be gereksinimlerini verecektir: Bunlar Sistem-to be gereksinimleri gözlenmiş ve kontrol edilmiş iki tür değişkenden oluşur.

4 Çevreileilgili Dönüşümler (Environment Related Mappings) NAT: (M, C) system davranışı ile ilgili doğal kısıtlamaları çevresel olarak modeller. Kısıtlar sistemin çevresindeki fiziksel kanunlardır. Bu kısıtlar gözlenmiş ve kontrol edilmiş değişkenlerin olası değerlerini verecektir. REQ: (M, C) gözlemlenmiş ve kontrol edilmiş miktarlar arasındaki sistem gereksinimlerini sağlar. Bu gereksinimler sistem tarafından sağlanmalı ve korunmalıdır

5 Etkileşimileilgili Dönüşümler (Interaction Related Mappings) IN: (M, I) giriş aygıtlarını modeller. Bunlar sensörler ya da analog digital dönüştürücüler olabilir. Çevredeki gözlenmiş değişkenlerin değerlerini yazılımın giriş değişkenleri ile ilişkilendirir. OUT: (O, C) çıkış aygıtlarını modeller. Bunlar digital- analog dönüştürücüler veya alıclar (actuators) olabilir. Yazılımın çıkış değerlerinin kontrol değişkenlerinin değerleri ile ilişkilendirilmesidir.

6 SistemleilgiliDönüşümler (System Related Mappings) SOF: (I, O) yazılımı modeller. Giriş değişkenlerini çıkış değişkenlerine dönüştürür. SYS: (M, C) sistemi modeller. Sistem giriş aygıtlarının, yazılımın ve çıkış aygıtlarının birleşimidir Sistem tarafından ölçülmüş (M) fiziksel miktarları ile sistem tarafından kontrol edilmiş ( C) fiziksel miktarlarının ilişkisidir.

7 AmacınAyrıntılandırılması (Goal Refinement) Yüksek düzeydeki amaçlar birinci i kategoride olan bilgiyi oluşturur. Sistem, yüksek düzeyde (high level) tüm yolcular için güvenli bir taşıma sağlayacaktır Trenin güvenliği olarak taşıma gerçekleştirmesinin sağlanmasıdır. Yüksek düzeydeki amaçlar kaba tanecikli (coarser graied) amacı verir. Daha sonra amaç ayrıntılandırılmalıdır. Bu, ince taneli (finer- grain) amaçlar ya da kısıtlardır.

8 Sistem Gereksinimleri ile İlgili Ayrıntılar Sistem gereksinimleri amaçlardır. Yüksek düzeyli amaçlar daha düşük düzeyli amaçlara parçalanmalıdır. Bir amaç kullanılmaya hazır olduğunda, diğer sistem bileşenleri yani kısıtlar, eylem, nesne, alıcı (agent),event, varlık (entity), bileşenler (components) bu amacı gerçekleştirmek üzere sisteme dahil olur ve bazı fonksiyon noktalarını (işlevleri ) gerçekleştirirler. Sistem bileşenleri gerçekleştirdikleri fonksiyon (işlev) noktaları ile sistem bildirimini (spesifikasyonunu) oluştururlar.

9 Amaca Yönelik gereksinimler Mühendisliğinin MetaModeli Metamodel of Goal-Oriented Requirements Engineering Amaca yönelik gereksinimler mühendisliği, hayata geçirilecek sistemin belli bir amacı gerçekleştirecek gözlemlerinden kaynaklanır. Toplantı düzenleme sisteminin amacı.. Tren kontrol sisteminin amacı..

10 Measuredspeed sıfırdan farklı (nonnull) bir değer olduğu sürece, DoorsState her zaman closed değerinde olacaktır; trenin kontrolü bunu gerektirecektir. Diğer taraftan; amaç ya da kısıt, aynı varlık (entity) üzerinde eylem (action) ve eylem ile tetiklenmiş (triggered) giriş-çıkış ilişkisi olarak oluşur. An Examplefor GoalRefinement

11 Sistem-To-Be ile Aktörlerin ilişkisi Sistem to- be, aktörler arasındaki bağlı destekler ve güçlendirir. Örnek: (Car Insurance) Araba Sigorta Sistemi olsun. Bu problemin aktörleri Car Owner(arabanın sahibi), Body Shop(kaportacı), Insurance Company(sigorta şirketi), Appraiser(eksper) olarak tanımlansın.

12

13 Systemas-is den System -to be nin oluşturulması System -to be, system-as-is den, yani mevcut sistemin tecrübelerini yaşamış kişilerin hikayelerden oluşturulabilir. Roles of scenarios. Importance of Interactive Environment

14 Senaryo Odaklı Gereksinimler Mühendisliği Senaryo bir hikaye olabilir ya da gerçek dünya deneyimlerinden hikaye olarak elde edilmiş olaylar (events) örneğidir. Senaryo bir dizi davranış ile ve olası çevresel (bağlamsal) davranışlarla tasarlanmış bir sistemin gelecekteki vizyonu olabilir Senaryo modelin işleyişi süresince bir dizi olayı (event) canlandıran bir görüntü gibi tek bir yolu olabilir. Senaryo bölünmemiş bir bütün olarak (continuum) gerçek dünya tanımlamalarından ve hikayelerinden modellere ve belirtimlere dönüşebilir.

15 Dağıtık Çevik Yaklaşım (Distributed Agile) Distributed: Takımlar takımların birimler arası mesafesi >60 dır. Silo: Fonksiyonel takımlardır. Test uzmanları ya da geliştiriciler >60 mesafede bir takım oluştururlar. Diğer takımlar farklı bir yerdedirler. Dispersed (dağılmış): Takım elemanlarının Tümü ya da çoğunluğu farklı yerlerde çalışmaktadır. Çevik takımlar scrum, kanban, lean kullanabilir.

16 Virtue: Erdem fazilet- doğruluk Dağıtık işbirliğinde önemlidir. İnsanların her noktada yapabilecekleri nasıl daha iyi gerçekleşebilir? Ürün geliştirilirken takım liderleri ve kişiler ayrı ayrı rol üstlenirler.

17 Bilginin iletişim ile yayılmasını sağlama araçları newsletters (haber bülteneleri )? İnsan kaynakları, muhasebe,yönetim, pazarlama takımları tarafından gönderilebilir. Şirketin operasyonel tarafında neler olduğu ile ilgili bilgilenilir. Intranet Şirket websayfası Storyboards: karmaşık problemler daha küçültülerek açıklaştırılır. Prosess flow diyagrams (süreç akış diyagramları) Tweter Live feed: 100 den büyük sayıdaki takımlar Skype ile etkileşebilir. Büyük bir ekranda değişiklikler görüntülenir; böylece diğerleri bilgilendirilir. 30 saniye kuralı (30 second rule) : hem geliştirme takımları, hem de müşterilere uygulanır.

18 Çevik Modellemede Toplantılar Çevik modellemede toplantılar operasyonel düzeyde gerçekleşir. «Product owner», «ScrumMaster» ve takım elemanları sprint planlanırken, demo ve «retrospective» toplantılarında bir araya gelirler. «ScrumMaster» ve team members günlük stand-up ( gerektiğinde product owner da katılır. ) toplantıları yapar.

19 ScrumTanımı Jeff Sutherland Scrum ile ürün geliştirilirken proje yöneticileri yoktur. Proje yöneticisi yerine, takım güçlendirilmiştir. Takım elemanları sonuçtan sorumludurlar ve kendi kendilerini yönetirler. Klasik proje yöneticisi olan patrona, Scrum geliştirme ortamında gerek yoktur. Scrum Master her gün aynı zamanda 15 dakikaya kadar stand-ups toplantılar gerçekleştirir. (Scrum tercihinin gücüdür)

20 Product Owner(PO) Product owner agile metodolojisinde istenilen bir pozisyondur. Product Owner ürünün vizyonunun açık olarak anlaşılmasını sağlar. Bunlar müşteriden, son kullanıcıdan ve iştirakçiler bakış açısından sağlanır. Product Owner ürünün ticari değerini sağlar. Product Owner ürün «backlog» larının yönetiminden ve ürün backlog görünürlüğünden sorumludur.