Çevik Yaklaşımlar & SCRUM

Standish Group Chaos Report 1994 1999 2001 2004 2010, 2012 1. User involvement 1. Executive mngment support 1. Executive support 2. Executive mngment support 2. Executive mngement support 2. User involvement 2. Executive mnagement support 3. Clear statement of requirements 3. Smaller project milestones 3. Competent staff 3. Clear business objectives 4. Propor planning 4. Competent staff 4. Smaller project milestones 4. Hard-working, focused staff 4. Emotional maturity 5. Realistic expectations 5. Ownership 5. Clear vision and objectives 5. Optimizing scope 6. Smaller project milestones 6. Agile process 7. Competent staff 7. Project management 8. Ownership 8. Skilled resources 9. Clear vision and objectives 9. Execution 10. Hard-working, focused staff 10. Tools & Infrastructure

PMI Certification

Time to Market Yazılım projelerinde, t0 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 t0 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.

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.

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

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

Standish Group Chaos Report, 2012

8th Annual State of Agile - 2013

Scrum Süreci

Waterfall vs. Scrum

8th Annual State of Agile - 2013

8th Annual State of Agile - 2013 Çevik Yöntemler için Kullanılan Araçlar 8th Annual State of Agile - 2013

Scrum Uygulayanlar

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

Overview 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 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.

LIS Coping Strategies 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).

Redevelopment 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.

Wrapping 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.

Migration 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: Testing and Functionality 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: Cut-Over 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 Methods 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 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 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 – Butterfly Methodology

Yazılım Test Süreci

Yazılım test süreci

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.

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)

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.

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ştirici Test birimi

Kara kutu testi (Black-box testing)

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.)

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.

Adım adım entegrasyon testi (Incremental integration testing) A-B-C-D bileşenler. T1, T2, T3, T4 ve T5 de test kümeleri

Test hazırlama 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 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.

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.