Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

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

Benzer bir sunumlar


... konulu sunumlar: "Legacy Information Systems Legacy Information Systems J. Bisbal, D. Lawless, B. Wu, J. Grimson Trinity College, DUBLIN IEEE Software, 1999."— Sunum transkripti:

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

2 - 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

3 - 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

4 - 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

5 Known as Big Bang 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

6 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

7 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

8 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

9 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

10 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

11 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

12 Migration Methods – Butterfly Methodology

13 Yazılım Test Süreci

14 Yazılım test süreci

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

16 Test Senaryolarının Önceliklendirilmesi (Prioritization)

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

18 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)  Kara kutu testi (Black box testing)  Beyaz kutu testi (White box testing)

19 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/Entegrasyon 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

20 Kara kutu testi (Black-box testing)

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

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

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

24 Kim hangi testi yapar? Ne testi?Kim?Ne zaman?Otomasyon? BirimYazılımcıKodlarkenHer zaman SistemTest uzmanıTest sürecinde Mümkün RegresyonYazılımcı / Test uzmanı Test sürecinde Mümkün KabulMüşteri / KullanıcıTeslim ederken Mümkün Stres/ Performans Test uzmanıTeslim ederken Her zaman

25 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

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

27 Test Otomasyonu Test, pahalı bir süreç. Test otomasyon araçları teste harcanan süreyi azaltmak ve toplam maliyeti kısmaya yarıyor. Ço ğ u test aracı açık kaynak kodlu; çünkü her kuruma/projeye özel şekilde kullanılmaları gerekiyor. Ne testi?Örnek araçlar BirimNunit, Junit, Mock, DBUnit SistemSelenium, Fit, WET, Watir, WatiN RegresyonBirim ve sistem test araçları KabulFIT, FitNesse Stres/ PerformansJmeter, Httperf

28 Jharna Software : The Move to Agile Methods

29 Özet - Ismail Khan, Jharna Software’in genel müdürü. - Jharna Software,180 çalışanı olan orta ölçekli bir Hint yazılım firması. - Şirketin ABD’deki takımı sistem analizi ve tasarımını yapıyorlar. - Hindistan’daki takım ise, yazılımı geliştirmenin di ğ er aşamalarını yapıyorlar. - Hindistan’da, özellikle de böyle bir işi ihraç ettikleri için, birçok performans ödülü almışlar. Ancak ABD’deki müşteriler şirketi daha kısa zamanda ve daha az bütçeli yazılım geliştirme metodları benimsemeleri konusunda çok zorluyorlar. - Ismail Khan, kullandıkları plan-odaklı yazılım geliştirme metodunun (waterfall) kötü taraflarını zaten biliyor, ama yeni ve çevik (agile) bir metodun uygulanmasında karşılaşılabilecek risklerden de endişeli. - Bu basit bir karar de ğ il! Hemen alınması gereken, stratejik önemi olan bir karar!

30 ...Jharna Yazılım ve Stratejileri ’da San Fransico’da 20 kişilik firmaları var. - Ayrıca Hindistan’a vergi avantaji da getiriyorlar. Çalışma izni olan yazılımcılar Amerika’ya gidiyorlar, izinleri bitince yerine di ğ erleri gidiyor. - Haftada 6 gün, günde 8 saatten fazla çalışıyorlar. - Periyodik olarak proje liderleri ve müşterilerle, gece gündüz farketmeden toplantı yapıyorlar. Sonuçlar, herkesin haberi olsun diye tüm çalışanlara iletiliyor.

31 Jharna Yazılım Geliştirme Metodu - Klasik bir plan-odaklı (Waterfall) yaklaşım kullanıyorlar. - Başlangıçtaki gereksinimler genelde müşterinin yanında belirleniyor. Daha ayrıntılılar, Hindistan’da belirleniyor. - ABD’deki grup müşteriye gidiyor, konuşuyor ve ilk isteklerini alıyor. Sistemin kısıtları belirleniyor. - Bu isterlere bakarak, sistemin fizibilitesi yapılıyor ve birbiriyle çelişen isterler olup olmadı ğ ı kontrol ediliyor. - Ardından bunlar Hindistan’a yollanıyor. Orada gereksinim dokümanı hazırlanıyor. Ardından ABD’deki grup tekrar müşteriye gidip gereksinimleri tekrar tartışıyorlar.

32 ...Jharna Yazılım Geliştirme Metodu - Gereksinimler üzerinde mutabakat sa ğ landı ğ ında, proje lideri ve senior yazılımcılar toplanıp, bir ekip oluşturuyorlar. - Yazılım geliştirme Hindistan’da başlıyor. Proje yöneticisi hem projenin gidişatını kontrol edip yönetiyor, hem de müşteri ile ilişkileri götürüyor. - Genelde bir proje iki ya da üç modüle ayrılıyor ve her birinin başına bir takım lideri koyuyorlar. Genelde her takım liderine ba ğ lı 2-3 yazılımcı Hindistan’da, 1-2 yazılımcı da Amerika’da oluyor. - Proje yöneticisi ise, Jharna’nın genel proje yöneticisine düzenli olarak rapor veriyor. - Proje hazır oldu ğ unda ve Hindistan’daki testleri geçtikten sonra, ABD’deki yazılımcılara yollanıyor. Yazılımcılar orada sistemi birleştiriyorlar ve müşterinin sistemine entegre ediyorlar. Son kabul (acceptance) testleri ABD’de yapılıyor. -Tüm bu aktiviteleri koordine etmek için, Jharna doküman hazırlanmasından sistem testlerine kadar her aktiviteyi standartlaştırıyor. - Her haftanın sonunda bir rapor, projenin tüm elemanlarına gönderiliyor.

33 ...Jharna Yazılım Geliştirme Metodu - Jharna, döküman hazırlama konusunda çok titiz. Böylece, projenin ortasında çekip giden birinin projeye olan zararı minimize edilmiş oluyor. - Ayrıca Jharna, dünya çapında benimsenmiş şablonlar kullanıyor. (Bunlar zaten CMM sertifikalarının gerektirdi ğ i şeyler.) Sistemin entegrasyonunun çok zor olması ve ço ğ u zaman çok zaman alması - Bu plan kullanılırken, Khan’ın kafasını kurcalayan sorun: Sistemin entegrasyonunun çok zor olması ve ço ğ u zaman çok zaman alması. Sistemdeki hataların bulunması ve onarılması, ço ğ unlukla beklenenden daha uzun sürüyordu. Her seferinde proje yürütücüleri bir takım bahaneler öne sürüyorlardı. - Khan bunun çok kısa bir sürede çözülmesi gereken bir sorun oldu ğ unu biliyordu.

34 ...Jharna Yazılım Geliştirme Metodu -Takım liderlerinden biri: -Takım liderlerinden biri: Entegrasyondaki problemlerin başında, farklı zaman dilimlerinde iletişim kurmak geliyordu. Hindistan ve ABD arasındaki 10 saat zaman farkından dolayı, en iyi iletişim yolu e-postalardı. - Yazılımcıların en büyük şikayetlerinden biri, her sabah karşılaştıkları yo ğ un e- postalardı. E-posta sadece zaman alan birşey de ğ il, aynı zamanda yanlış anlaşılmalara da sebep olan birşeydi. Dolayısıyla beraber çalışılması daha etkin olabilirdi. - Ayrıca, birlikte çalıştıkları için, yazılımcılar arkadaş da olabilirler. Birbirleriyle bilgi alışverişi yapmaları daha kolay olur. Bu yazılım projesi için de ğ eri biçilemez bir katkı olabilir.

35 ...Jharna Yazılım Geliştirme Metodu - Fakat ço ğ u proje yöneticisi, sorunların iletişimden çok sistem spesifikasyonlarının belirlenmesiyle ilgili oldu ğ unu düşünüyordu. Bir proje yöneticisi: - Bir proje yöneticisi: Sistem spesifikasyonlarındaki eksiklikler, sistem entegrasyonunda ortaya çıkıyor. Günümüzde ço ğ u zaman, müşteri isterlerini bitirmeden, projeye başlamak zorunda kalıyoruz. Hemen hemen hergün müşteri ile konuşsak da, müşterinin asıl istedi ğ i şeyi ö ğ renmek çok zor oluyor. Artık müşteriler projenin son evrelerinde isteklerini de ğ iştirmeye başladılar. Bu sistem entegrasyonunu daha da çok zorlaştırıyor. Biz, entegrasyon sırasında da sistem üzerinde büyük de ğ işiklikler yapmak zorunda kalıyoruz, bu da hem proje yöneticileri hem de yazılımcılar üzerinde büyük stres yaratıyor. Bunlar dışında, beraber çalışmanın iyi sonuç verece ğ ine inanmıyorum. Çünkü e ğ er Hindistan’daki ve ABD’dekiler beraber çalışsalar, dokümantasyonlara daha az önem verecekler. Oysa dokümanlar, hataların bulunmasında çok etkili. Ayrıca çalışanların birbirleriyle iyi geçinememe riski de var.

36 Çevik Metodlar: Bir Alternatif Olabilir mi? - Gitgide, klasik plan-odaklı metodlardan, daha çevik, daha hızlı metodlara geçme gereksinimi duyuldu. Bu iki tip metod birbirinden birçok yönüyle farklı. - Projenin en başında uzun bir süre boyunca ayrıntılı olarak prosesleri planlamak yerine, çevik metodlar de ğ işikliklere uyumlular. Başka bir deyişle, çevik metodlar people-oriented, klasik metodlar process-oriented. - Khan’ın çevik metodlara geçip geçmemeye çok çabuk karar vermesi gerekiyordu. Orta ölçekli bir şirket olduklarından, başlıca müşterileri sayesinde ayaktaydılar. - Son iki senedir, ABD’li müşteriler Khan’ı, çevik metodlara geçmesi yönünde uyarıyorlardı. - ABD’deki müşterisi continuous integration kullanıyordu, yani yazılımcılar her an koda ekleme yapabiliyorlardı (en azından günde bir kere). Böylece, entegrasyon sırasında ortaya çıkacak hatalar ilk baştan görülüyordu. Büyük hacimlerde kodla u ğ raşmaktansa, daha ufak miktarda kodla u ğ raşarak ilerliyorlardı.

37 ...Çevik Metodlar: Bir Alternatif Olabilir mi? - Hindistan’a döndü ğ ünde, Khan ortakları ve üst düzey yöneticileriyle bu konuyu tartışmış, ancak ortaya farklı düşünceler çıkmış. - Orta ğ ı, çevik metodların, Jharna şirket kültürüne uygun olup olmadı ğ ından emin de ğ ildi. Örne ğ in XP’de, her yazılımcı, kodun istedi ğ i bölümünü de ğ iştirebilme olana ğ ına sahip. Ancak onların slogan: “Get it right the first time”. Ayrıca, projenin kontrol altında tutulmasının da çok zor olaca ğ ını düşündü, nitekim herkes istedi ğ i zaman istedi ğ i yere ekleme yapabilecekti. - Di ğ er bir ortak ise, şirketin isminin waterfall manasına geldi ğ ini, ama bu metodun de ğ iştirilince uyumsuzluk olaca ğ ını söyledi. Ama bunu çok önemsemediler, nitekim o isim firma ilk kuruldu ğ unda verilmişti.Ayrıca ABD’li müşteriler Jharna’nın manasını zaten bilmiyorlardı.

38 ...Çevik Metodlar: Bir Alternatif Olabilir mi? Operasyon müdürü - Operasyon müdürü, dokümantasyonla ilgili konular üzerinde durdu. Çevik metodlara geçilirse, dokümentasyona olan gereksinim en aza inecekti. Müdür uzun vadede bilginin kaybolaca ğ ını söyledi. E ğ er dokümantasyon olmazsa, yeni gelen yazılımcıya nasıl ö ğ retilecekti? Kim anlatacaktı? Bilenlerin hepsi gitti ğ inde ne olacaktı? - İ ş kaynakları müdürü - İ ş kaynakları müdürü ise, çevik metodların çalışanların moralini yüksek tutaca ğ ını söyledi. Jharna gibi orta ölçekli firmalar, iyi iş gücünü tutmak zorunda olduklarından yüksek maaş veriliyor. Çevik metodların kurallarından biri de haftada 40 saattten fazla çalışılmasına izin vermemesi. Bir di ğ er konu da, proje yöneticilerinin çevik metodlarla ilgili bir tecrübelerinin olmaması. - Finans müdürü - Finans müdürü: Şu andaki düzende, bütçe ve takvimlemeyi proje başlamadan önce yapıyoruz. Yapılan tasarımsal de ğ işikliklerle ilgili, proje yöneticisinden onay almamız gerekiyor, çünkü bütçe ve takvimlendirme içinde kalınması gerekiyor. Ama çevik metoda geçersek, gereksinimler sürekli de ğ işecekler ve herşey esnek olacak. Dolayısıyla bütçe ve zamanla ilgili tahminleri tutturmak da çok zor olacak.

39 Ismail Khan’ın Önündeki Seçenekler

40 Seçenek 1: Halihazırda kullanılan metodu kullanmaya devam etmek Avantajlar: - O anki müşterilerini elde tutabilir, çünkü e ğ er çevik metoda geçerse bu müşteriler artık onları tercih etmeyebilirler. Orta ölçekli bir firma oldu ğ undan, halihazırdaki müşterilerini, özellikle büyük müşterilerinin gereksinimlerini karşılamak hayatlarını sürdürebilmeleri için çok önemlidir.Dezavantajlar: - Müşteri gereksinimleri gün geçtikçe daha de ğ işken olabilir. Bu gereksinimler genelde projenin neredeyse ortalarına geldikten sonra ortaya çıktı ğ ından, plan- esaslı metod bununla baş edemeyebilir. - Sistem gereksinimlerinin belirlenmesi ve sistem entegrasyonundaki problemler yine çözülmemiş olur. - Jharna, çevik metod kullanmasını isteyen müşterileri kaybetmiş olur.

41 Seçenek 2: Çevik metod kullanılan projeleri outsource etmek Avantajlar: - Çevik metod isteyen müşteriler tatmin olur. Aynı zamanda, Jharna eski metodunu kullanmaya devam edebilir.Dezavantajlar: - Finansal olarak pek de uygulanabilir bir çözüm de ğ il. Rekabet sonucu, Jharna’nın kar marjı zaten çok düşük. - Müşteriler memnun olmayabilirler. Neden do ğ rudan çevik metod kullanan bir yazılım şirketine gitmektense, Jharna’ya gelsinler? - Jharna outsource etti ğ i projelere dahil olsa bile, çevik metod kullanımını ö ğ renebilmesi pek de mümkün de ğ il.

42 Seçenek 3: Hem çevik metodu, hem de klasik plan-esaslı metodu paralel olarak kullanmak Avantajlar: - Her türlü gereksinime cevap verebilecek bir yazılım geliştirme metodu yoktur. Dolayısıyla, her iki metoda da ihtiyaç vardır. Jharna, her iki metodda da uzmanlı ğ ını geliştirebilir.Dezavantajlar: - Jharna’nın çevik metodlarla ilgili bir tecrübesi veya uzmanlı ğ ı yok. - Plan-esaslı metodu kullanan yazılımcılarla, di ğ erleri arasında bir çatışma olabilir. İ nsan kaynakları yönetiminde bir sorun demektir bu. Özellikle orta-ölçekli bir yazılım şirketinde kabiliyetli elemanları tutmak büyük bir meseledir. - Jharna, hem klasik yöntemin, hem de çevik metodun dezavantajlarını bir arada yaşamaya başlayabilir.

43 Seçenek 4: Klasik metodu atıp, çevik metoda geçmek Avantajlar: - E ğ er Jharna, ABD’li müşterilerinin tavsiyelerine uyarak, çevik metodları başarıyla uygularsa, müşterilerini kesinlikle etkileyecek ve dilden dile yayılacak bir üne sahip olacaktır. Hem de, çevik metodların getirdi ğ i daha az maliyet ve esneklik gibi faydalardan da yararlanacaktır.Dezavantajlar: - Jharna’nın bu konuda hiç bir deneyimi yok. Bununla birlikte, Jharna’nın e ğ itim programlarını, performans de ğ erlendirme sistemini ve bütçe planlamasını tamamen de ğ iştirmesi gerekecektir. -Jharna’nın kurum kültürünü de de ğ iştirmesi gerekmektedir. Örne ğ in, yazılım geliştiriciler artık kodda de ğ işiklikler yapmayı normal olarak görmelidirler. Ayrıca proje yöneticilerinin ve ekip liderlerinin de ğ işen görevleri de, tartışmalara yol açabilir. -Bilgiyi kaybetme riski do ğ abilir. İ mkansız olmasa da, gerekli her türlü bilgiye sahip olacak ve yönetecek bir kişiyi bulmak çok çok zordur. Çünkü bir insan sadece tek bir konuda o derece bilgi sahibi olabilir.

44 Seçenek 5: Çevik metod kullanan bir şirketle stratejik bir birlik oluşturmak Avantajlar: - Jharna, stratejik orta ğ ı sayesinde, çevik metodlarla ilgili daha fazla şey ö ğ renebilir.Dezavantajlar: - Stratejik ortaklıktan dolayı meydana gelecek zorlukları yaşar. Özellikle ortaklık bittikten sonra, kendi müşterilerini bu stratejik orta ğ ına kaptırma riskine sahiptir. - Jharna’nın halihazırdaki metodla olan problemleri aynen devam eder.


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

Benzer bir sunumlar


Google Reklamları