|
|
- (bkz. mcad)
(bkz. mcsd)
- programcılıkla karıştırılmaması gereken, kodlama ile minimum ilgisi olan, asıl işi tasarım ve proje yönetimi olan mühendislik dalı.
çok baba bir örneği için (bkz. feza buzluca)
ayrıca (bkz. software engineering)
- coder tayfasının fütursuzca bok atmaktan geri kalmadığı meslek grubu. öte yandan ben yazılım mühendisi çıktım kod yazmadan takılayım yemişim turbo c'yi gibi düşünceler çok yanlıştır ,zira bu işin pişme kısmı projelerde kod yazmaktan geçiyor.
- microsoft'un , sertifikasını neredeyse bakkalda bile satılacak hale getirerek içine sıçtığı meslek.
- karşı cinse yazmak için yapılması gereken hesapların, planların ve çözüm yollarının öğretildiği mühendislik dalı.
kızlar için öğretim süresi 3 gün (garantili,son gün bitirme projesi),
erkekler için öğretim süresi 10 yıldır (garanti yok, yüksek yapılırsa bir 5 yıl daha uzayabilir).
- "günümüzde yazılım sistemleri, bankacılıktan otomotiv sanayisine, sağlık bilgi sistemlerinden şirket yönetimine, telekomünükasyon sistemlerinden hava taşımacılığına, çok geniş alanlarda kullanılan bilgisayar sistemlerinin çok önemli ve kritik bir parçasını oluşturmaktadır. yazılım mühendisliği 1968 yılından bu yana var olan yeni bir mühendislik alanı olup, yazılım sistemlerinin mühendislik prensipleri çerçevesinde tasarımı, üretimi ve işletilmesini hedefler. bilgisayar sistemleri artık günlük hayatın her alanında yoğun ve etkin bir şekilde kullanılmakta olduğundan, yazılım mühendisliği tüm disiplinlerde uygulamaları olan bir alandır."
(bkz: http://www.cmpe.boun.edu.tr/...)(çarut, 04.06.2005 23:57)
- atılım üniversitesinde bulunan bölüm
(sharp, 04.08.2007 10:26)
- tübitak marmara araştırma merkezi bilişim teknolojileri enstitüsünde dibine vurulmuş olan mühendisliktir. insan 1000 satır kod için 2000 sayfa döküman hazırlar mı ya?
- geceleri sabah ettirir makina karşısında.
- mesleğim gereği yazılım mühendisliği gibi bir disiplinin neden geliştiğini, ne kadar önemli olduğunu, nelerle uğraştıklarını biliyor ve takdir ediyorum. onlar olmadan aya insan gönderemezdik bundan eminim.
ama bu kadar eğitimden sonra bile yazılım mühendisliği ile ilgili bir kitabı ya da siteyi açtığımda içinde geçen bütün kelimelerin anlamlarını bildiğim, gramerini de anlayabildiğim ama kendisi bana hiçbir şey ifade etmeyen cümlelerle dolu büyük kelimelerle süslenmiş paragraflar dolusu yazıyı görünce de "ulan ne demeye bunlarla uğraşıyorsunuz be, bunları yapacağınıza iki satır kod yazsanız proje bitmişti çoktan şerefsizim." diyecek eşekliğim de bakî kalmış bende.
gerçek yazılım mühendisleri alınmasın, ben çakma kitap yazarlarına laf ediyorum.
- gerçeği de çakması da alınabilir.
iş yapmayalım, haydi süsleme yapalım, ciddiyetli olalım amacı güderler. aslında kod yazmak da öyle baştan savma bir iş değil demek amaçlıdır. saçı sakalı birbirine karışmış, ya göbeği kendinden önde giden, ya da artık postürü kaymış kemikleri çıkmış, gözleri pörtlemiş neomsu tiplerinden elinden alıp canım kodlama işini, gidip de takım elbise giymiş çakma işletmecilerin eline vermek.
öyle bir yapmacık, öyle bir soğuk...
- david budgen'in software engineering kitabının ikinci edisyonundan bir paragraf:
"this reinforces the earlier point that the structure of a system should allow it to be modified fairly easily, so that it can be adapted to cope with likely changes (or, at least, with perfective and adaptive changes; it would be difficult to make much useful allowance for likely corrective changes!). this is a principle that has been common in many other branches of engineering for a long time. (examples of the design of components undergoing frequent revision can often be found in the design of cars and electronic goods.) as already observed, such practices may create constraints that limit the
‘solution space’ available to the designer, so increasing the initial cost while decreasing the long-term cost. unfortunately, the way in which most organizations budget for software production is too short term for such practices to be adopted as effectively as might be desired."
57. sayfanın yarısını bu paragrafa ayırmış bay budgen. soruyorum size yukarıdaki paragrafta "hadi canım, öyle şey mi olur?" diyeceğiniz bir şey var mı? yok. hepsi de gayet makul laflar. öte yandan bunlar arasında bir mühendis olarak bilmediğiniz ne vardı? bence hiçbir şey yoktu. hepsi de beylik laflar. alın bakın:
"bu, üretim yaparken kullandığınız tarifte gerekli değişiklerin yapılmasını olanaklı kılar ve kolaylaştırır. bu sayede nutella üretiminde malzeme kalitesindeki değişikliklere bağlı olarak üretim süreçlerini uyum sağlamaya hazır bir şekilde değiştirir konuma gelirsiniz. bu prensip sadece nutella üretiminde değil gıda sektörünün hemen her alanında kullanılan bir prensiptir...."
- bence yazılım mühendisliği böyle, kitaplardan öğrenilecek bir şey değil. kitaplardan notasyonu öğrenirsiniz, kullanılacak programların detaylarını öğrenirsiniz. bir yazılım mühendisinin bu prensipleri öğrenmesi ve ezberlemesi değil, içselleştirmesi gerekir. özellikle bilgisayar mühendisleri için konuşuyorum, tuğla büyüklüğünde bir kitapta zaten bilmediği bir şeyi bulma olasılığı sıfıra yakındır. en fazla zaten tanıdık olduğu ama ismini bilmediği bir prensibi görür, ha ismi bu muymuş der geçer. eğer meslekî hayatında o prensipleri kullanmıyorsa zaten ismini bilse ne olur bilmese.
yazılım mühendisliği yaşanarak öğrenilecek bir şey. derslerde proje yaparak öğrenebileceğiniz bir şey. proje tanımları kasıtlı olarak eksik bırakılmalı mesela. öğrenciler gruplar hâlinde çalışmaya zorlanmalı ama grup içi iş bölümünün nasıl yapılacağı tamamen havada bırakılmalı. insanlar sorunlarla karşılaştıkça ve o kitaplarda ismi konan prensiplerin aslında hayatlarını kolaylaştıracak bir kurallar bütünü olduğunu anladıkça yazılım mühendisliğinin hakkını verebilirler.
işte ancak bu bilince ulaşmış bir yazılım mühendisi adayını kitaplarla tanıştırmak ve meslekî tarih boyunca ortaya çıkmış birbirinden farklı yaklaşımların neler olduğunu öğretmek gerekiyor. ancak bu seviyedeki birisi fusion method ile unified process arasındaki farkın ne olduğunu gerçekten anlar, ezberlemez.
- amacı program yazmak olmayan daha çok yazılacak olanı tasarlamakla uğraşan kişilerdir.
fakat programcı olarak da iş görenleri vardır, zaten ufak ve orta ölçekli yazılım tasarımları, tecrübeli programcılar ve ne istediğini bilen müşteriler ya da alan uzmanları bir araya getirilerek çıkarılabilir. büyük projelerde ise yazılım mühendislerine önemli görevler düşer. programcı, sistem yöneticisi, veritabanı uzmanı gibi belli konulardaki teknik bilgileri iyi olan kişiler büyük projelerde proje tasarımıyla uğraşmamalıdır yani asıl işi yapan bu elemanlara yük fazla bindirilmemelidir.
türkiye şartlarında geliştirilen yazılımların ölçeği dikkate alınırsa, yazılım mühendislerinin programcılığa kayması anormal olmaz. firmalar hem tasarlayan hem kodlayan elemanları tercih etmektedirler, en azından dev haline gelmeyen firmalar.
işten anlamayan, bürokrasi bağımlısı olan kişilerin proje yöneticisi olup programcıların canına okumasındansa, yazılım mühendislerinin proje yöneticisi olması çok daha iyidir. kendilerini beşeri konularda da yetiştirmelidirler.
(bkz: talk is cheap show me the code)
- köklerinin 1968'lere, yani şu güzelim kodlama işi ellerinden alınan heriflerin birçoğunun tevellüdünden daha eskiye dayanıyor olması da daha bir ilginçtir hani.
- günümüzde, bilgisayar mühendisliğinin önüne geçmek için az bir yolu kalmış olan mühendislik dalı. iş ilanları ve firma arayışlarına dikkat edilirse, yazılım hakkında daha spesifik bilgisi olan elemanlar revaçta.
(bkz: spesifik)
|
