Çevik Yaklaşımlar & SCRUM
Standish Group Chaos Report
1994
1999
2001
2004
2010, 2012
1. User
involvement
1. User
involvement
1. Executive
mngment support
1. User involvement
1. 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 staff
3. Smaller project
milestones
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. 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
Kapsamlı
dokümantasyon
yerine
Sözleşme
pazarlıkları
yerine
Bir plana bağlı
kalmak
yerine
Bireyler ve
etkileşimler
Çalışan yazılım
Müşteri ile işbirliği
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
Çevik Yöntemler için Kullanılan Araçlar
8th Annual State of Agile - 2013
Scrum Uygulayanlar
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
applications
(Big
Bang
approach):
Rewriting
existing
- 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)
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.