Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

Çevik Yaklaşımlar & SCRUM. Standish Group Chaos Report 19941999200120042010, 2012 1. User involvement 1. Executive mngment support 1. User involvement1.

Benzer bir sunumlar

... konulu sunumlar: "Çevik Yaklaşımlar & SCRUM. Standish Group Chaos Report 19941999200120042010, 2012 1. User involvement 1. Executive mngment support 1. User involvement1."— Sunum transkripti:

1 Çevik Yaklaşımlar & SCRUM


3 Standish Group Chaos Report 19941999200120042010, 2012 1. User involvement 1. Executive mngment support 1. User involvement1. Executive support 2. Executive mngment support 2. Executive mngement support 2. User involvement 2. Executive mnagement support 2. User involvement 3. Clear statement of requirements 3. Smaller project milestones 3. Competent staff3. Smaller project milestones 3. Clear business objectives 4. Propor planning4. Competent staff4. Smaller project milestones 4. Hard-working, focused staff 4. Emotional maturity 5. Realistic expectations 5. Ownership5. Clear vision and objectives 5. Optimizing scope 6. Smaller project milestones 6. Agile process 7. Competent staff7. Project management 8. Ownership8. Skilled resources 9. Clear vision and objectives 9. Execution 10. Hard-working, focused staff 10. Tools & Infrastructure

4 PMI Certification

5 Time to Market -Yazılım projelerinde, t 0 anında bir vizyon belirlenir -> Projenin sonuda elde edilmek istenen hedef bir de ğ er. - Waterfall modelinde: Analiz, tasarım, kodlama ve testten sonra (belirli bir süre sonra) proje müşteriye teslim ediliyor. - Araştırma sonuçlarına göre: E ğ er proje başlangıcı ve bitişi arası 6 ay veya daha uzun bir süre ise ve bu sürece müşteriler ve de ğ işim dahil edilmiyorsa, büyük ihtimalle t 0 anında hedefledi ğ iniz de ğ erden daha düşük bir de ğ er elde ederek projeyi bitirirsiniz. Kısaca: Müşteriler ve de ğ işim dahil edilmedikçe, proje süresi uzadıkça -> İ stenilen hedeflerin yakalanma ihtimali düşüyor! Araştırma sonuçlarına göre: Problem görülüp, sürece müşteriler ve de ğ işim katılsa bile, hiçbir zaman ara kapatılamıyor -> Proje başarısızlı ğ a do ğ ru gidiyor.

6 - Pareto prensibi (80-20 kuralı) -> Yazılım projelerindeki fonksiyonalitelerin %20’si, müşterilerin ihtiyaçlarının %80’ini karşılar. - Esneklik: Müşteriyle kısa aralıklarla görüşülüp, ondan fikir alındı ğ ı için, de ğ işiklikler kucaklanmış oluyor.

7 De ğ işim ve Kalitenin Maliyeti Boehm’s Cost of Change Curve

8 Çevik yaklaşım manifestosu Süreçler ve araçlar Kapsamlı dokümantasyon Sözleşme pazarlıkları Bir plana ba ğ lı kalmak Bireyler ve etkileşimler Çalışan yazılım Müşteri ile işbirli ğ i De ğ işime karşılık verme yerine

9 Standish Group Chaos Report, 2012

10 8 th Annual State of Agile - 2013

11 Scrum Süreci

12 Waterfall vs. Scrum

13 8 th Annual State of Agile - 2013

14 Çevik Yöntemler için Kullanılan Araçlar

15 Scrum Uygulayanlar



18 Legacy Information Systems Legacy Information Systems J. Bisbal, D. Lawless, B. Wu, J. Grimson Trinity College, DUBLIN IEEE Software, 1999

19 - Legacy information systems (LIS) are typically the backbone of an organization’s information flow and the main vehicle for consolidating business information. - They are mission critical, and their failure can have serious impact on business. - Definition: Any information system that significantly resists modification and evolution. - They can cause host organizations several problems: -LIS usually run on obsolete hardware that is slow and expensive to maintain. -Software maintenance can also be expensive: because documentation and understanding of system details is often lacking, tracing faults is costly and time-consuming. -A lack of clean interfaces makes integrating LISs with other systems difficult. -LISs are also difficult, if not possible, to extend. Overview

20 - Several solutions have been proposed: -Redevelopment (Big Bang approach): Rewriting existing applications -Wrapping: Wrapping an existing component in a new, more accessible software component -Migration: Moving LIS to a more flexible environment, while retaining the original system’s data and functionality. Overview

21 - Each approach varies in terms of changes required and costs and risks involved. Redevelopment leads to the most changes (system revolution) and wrapping the least (system evolution). LIS Coping Strategies

22 Known as Big Bang approach, Chicken Little approach or Cold Turkey approach. In reality, the risk of failure is usually too great for organizations to seriously contemplate a redevelopment approach. Another very real concern stems from the fact that technology and business requirements are constantly changing. Thus, at the end of a long process, an organization might find itself with a redeveloped system based on obsolete technology that no longer meets its business needs. Redevelopment

23 Most practical solutions focus on wrapping, which surrounds existing data, individual programs, application systems, and interfaces with new interfaces. In essence, this gives old components new operations or a ‘new and improved’ look. The wrapped component acts as a server, performing some function required by an external client that does not need to know how the service is implemented. Wrapping

24 Although it is a much more complex undertaking than wrapping, if successful, migration’s long-term benefits are also greater. Before embarking on a migration project, engineers, management, and users should undertake an intensive study to find the most appropriate approach for solving their organization’s LIS problems. Database population Migration

25 Up to 80% of a migration engineer’s time could quite legitimately spent testing the target system. Given the legacy system’s mission-critical nature, target system outputs must be completely consistent with those of the LIS. Thus, it is inadvisable to introduce new functionality to the target system during the migration project. However, on a practical level, migration projects are often expected to add functionality to justify the project’s expense and risk. In this case, the LIS should be migrated first. New functionality can be incorporated into the target system after the initial migration. Migration: Testing and Functionality

26 The last step in the migration project is the cut-over from the LIS to the target system. 3 different transition strategies have been proposed: The cut-and-run strategy consists of switching off the LIS and turning on a new feature-rich replacement. With the phased interoperability strategy, the cut-over is performed in small, incremental steps: each step replaces a few LIS components (applications or data) with corresponding target components. In the parallel operations strategy, LIS and target systems operate simultaneously, with both systems performing all operations. During this period, the target system is continually tested; once it is fully trusted, the LIS is retired. Migration: Cut-Over

27 1. The Chicken Little Strategy Michael Brodie and Michael Stonebraker propose this strategy, which lets LIS and target systems interoperate during migration using a mediating module, generally known as a “gateway”. The Chicken Little strategy offers an 11-step plan for the cutting over from the LIS to the target system. Each step is incremental: Analyze the LIS Decompose the LIS structure Design the target interface Design the target application Design the target database Install the target environment Create and install necessary gateways Migrate the legacy databases Migrate the legacy applications Migrate the legacy interfaces Cut over to the target information system. Migration Methods

28 1. The Chicken Little Strategy The target system is intially quite small, but grows as the migration progress. During migration, the LIS and target systems form a composite information system. Chicken Little uses a forward gateway to translate and redirect calls to the tarhet database’s results for use by LIS applications. A reverse gateway maps the target data to the LIS database. This mapping can be complex and slow, thus affecting new applications. The Chicken Little approach can use data duplicated accross the LIS and target databases. To maintain data integrity and consistency, a transaction coordinator intercepts all update requests from LIS or target applications and identifies whether they refer to data replicated in both databases. If they do, the update is propogated to both databases using two-phase commit protocol. Although this strategy has the advantage of breaking the migration process into a series of well-designed stages, it can involve highly complex strategies to ensure consistency between the target and LIS databases. Migration Methods

29 2. Butterfly Strategy It assumes that although the LIS must remain operable throughout migration, the LIS and target system need not interoperate during the process -> This assumption eliminates the need for gateways and their potential complexity. The Butterfly methodology focuses on LIS data migration, and develops the target system in an entirely seperate process. Once data migration commences, the LIS data store is set to read-only. The data access allocator redirects LIS data manipulations; the results are stored in a series of auxilary data stores, or TempStores. Migration Methods

30 Migration Methods – Butterfly Methodology

31 Yazılım Test Süreci

32 Yazılım test süreci

33 Test Hazırlık Adımında Neler Yapılmalıdır? ◦ Test edilecek yazılıma ait analiz ve teknik tasarım aşamaları ile ilgili dökümanlar, test ekibi tarafından incelenir. ◦ Yazılım içinde test edilecek (ve edilmeyecek) modüller belirlenir. ◦ Risk analizi yapılır ve yapılan de ğ erlendirmeye göre dinamik test aşamasında uygulanacak olan test teknikleri ve metodları belirlenir. ◦ Dinamik testin uygulanaca ğ ı ortamlar ve bu ortamların ihtiyaçları belirlenip, uygun şartlar sa ğ lanır. ◦ Test ekibi içinde görev paylaşımı ve zaman planlaması yapılır. ◦ Testin sonlandırma kriterleri belirlenir. ◦ Bir programa belirli girdiler verildi ğ inde hangi çıkışların ne şekilde alınması gerekti ğ ini bildiren test case senaryoları belirlenir. ◦ Dinamik testin hangi adımlarla ve ne şekilde uygulanaca ğ ının belirtildi ğ i test planı hazırlanır.

34 Dinamik Test Süreci Neleri İ çermektedir? ◦ Test edilecek yazılımın tipine göre, kullanılacak test yöntemi de ğ işmekle beraber, test yöntemleri genel olarak aşa ğ ıdaki şekilde gruplandırılabilir:  Birim testi (Unit testing)  Entegrasyon/Sistem/Tümleyim testi (Integration/System testing)  Regresyon testi (Regression testing) : Genelde büyük bir miktar kod de ğ iştikten sonra, hata bulmaya yönelik yapılan bir test çeşididir.  Performans / Yük testi (Performance / Stress testing)  Kullanıcı kabul testi (User acceptance testing)  Beyaz kutu testi (White box testing)  Kara kutu testi (Black box testing)

35 Do ğ rulama testi ve hata testinin farkı nedir? Do ğ rulama testi (Validation testing) ◦ Yazılımcının kendisine veya müşteriye, yazılımın isterleri yerine getirip getirmedi ğ ini göstermek için; ◦ Sistemin önceden tasarlandı ğ ı şekilde çalıştı ğ ını ispat etmek; Hata/Kusur testi (Defect testing) ◦ Yazılan programdaki eksik, bozukluk, kusuru bulma amaçlı. ◦ Program, hatalı sonuç vermeye zorlanır. Sıradan olmayan durumlar yaratılır. ◦ Test, hata olmadı ğ ını de ğ il, hatayı gösterir. -> Hata testi sonucu, programın hatasız çalıştı ğ ı yargısına varılamaz.

36 Birim ve sistem testinin ne farkı vardır? Birim testi ◦ Programı oluşturan bileşenlerden birinin testi; ◦ Genelde birimi geliştiren kişi tarafından yapılır (Kritik sistemler hariç); ◦ Geliştiricinin tecrübesiyle şekillenir. Sistem testi ◦ Bileşenlerden ikisi veya daha fazlası bir araya getirilerek yapılan test; ◦ Ba ğ ımsız bir test ekibi tarafından yapılır; ◦ Testler, sistemin spesifikasyonu esas alınarak şekillenir. Birim testi Sistem testi Yazılım geliştiriciTest birimi

37 Kara kutu testi (Black-box testing)

38 Sistem testi (Integration/System testing) - 1 Bileşenler bir araya getirilip, bir alt sistem veya sistem oluştururlar. İ ki aşamadan oluşur: ◦ Entegrasyon testi (Integration testing): Test ekibi, bileşenlerin bir araya gelmesiyle oluşan sistemin kodlarına ulaşabilir. Hata (defect) bulma amaçlıdır. Bir sorun (defect) keşfedildi ğ inde, hangi bileşende sorun oldu ğ u bulunur. ◦ Sürüm testi (Release testing): Müşteriye teslim edilecek programın komple bir versiyonu test edilir. Bakılan şey, sistemin istenilen işi yapıp yapmadı ğ ıdır. Kara kutu test sistemi kullanılır; yani test ekibi sadece sistemin verilen işi yapıp yapmadı ğ ını kontrol eder. Buldukları problemleri yazılımcıya iletilirler. (E ğ er sürüm testine müşteri de dahil edilirse, adı kullanıcı kabul testi (user acceptance testing) olur.)

39 Sistem testi (Integration/System testing) - 2 Bileşenlerin bir araya getirilmesi iki şekilde yapılabilir: Yukarıdan aşa ğ ı entegrasyon (Top-down integration) ◦ Önce sistemin omurgasını oluştur, sonra yavaş yavaş bileşenleri eklemeye başla. ◦ Ör: Önce en çok kullanılan veri tabanı ve a ğ bileşenleri birleştirilir. Üstüne di ğ er fonksiyonlar eklenerek devam edilir. Aşa ğ ıdan yukarıya entegrasyon (Bottom-up integration) ◦ Önce altyapıya ait bileşenler kurulur, üstüne işlevsel bileşenler eklenir.

40 Adım adım entegrasyon testi (Incremental integration testing)

41 Tüm durumları tek tek test etmek imkansız! Olası durumları gösteren alt kümeler oluşturulmalı. ◦ Menülerden ulaşılabilen tüm fonksiyonlar test edilmeli; ◦ Aynı menüden girilen fonksiyon kombinasyonları test edilmeli; ◦ Kullanıcı girdisi gerekti ğ i durumlarda, kullanıcının hem do ğ ru, hem yanlış girdi ğ i durumların ikisi de, tüm fonksiyonlar için test edilmeli. ◦ Sisteme hata mesajı verdirecek girdilerle denenmeli; ◦ Tamponların (buffer) taşmasına sebep olacak şekilde girdilerle denenmeli; ◦ Aynı girdi veya girdi serisini üstüste denemeli; ◦ Geçersiz çıktılar yaratmaya çalışmalı; ◦ İ şlem sonuçlarının çok küçük veya çok büyük olmasına çalışmalı. Test hazırlama

42 Test Sonlandırma Adımı ◦ Yapılan testler sonucu bulunan hatalar düzeltildikten sonra, test hazırlık adımında hazırlanan test sonlandırma kriterleri kontrol edilir. ◦ Tüm kriterler kabul edilebilir seviyedeyse, test aşaması sonlandırılabilir. ◦ Ardından, uygulama müşteri testine (user acceptance test) açılır. ◦ De ğ işmesi gerken yer varsa, yazılımcıya düzelttirilir ve test ekibine yollanır. ◦ Test ekibi tarafından kontrolden geçen yazılım, ürün aşamasına geçer. Yani, yazılım geliştirme sürecinin son basama ğ ına geçilmiş olunur.

43 Test Otomasyonu Test, pahalı bir süreç. Test otomasyon araçları teste harcanan süreyi azaltmak ve toplam maliyeti kısmaya yarıyor. JUnit, IBM Rational Functional Tester, FitNesse, Selenium, soapUI, vb. testleri otomatik olarak yapan araçlar. Ço ğ u test aracı açık kaynak kodlu; çünkü her kuruma/projeye özel şekilde kullanılmaları gerekiyor.

"Çevik Yaklaşımlar & SCRUM. Standish Group Chaos Report 19941999200120042010, 2012 1. User involvement 1. Executive mngment support 1. User involvement1." indir ppt

Benzer bir sunumlar

Google Reklamları