What is the software development life cycle (SDLC)?

Software Development Life Cycles

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
4. Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
5. Repeat three times steps 3 and 4.
6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
7. Users find 137 new bugs.
8. Original programmer, having cashed his royalty check, is nowhere to be found.
9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
13. Programmer produces code he believes is bug-free…

ပံုထဲက စကားလံုးမ်ား

ပံုထဲက စကားလံုးမ်ား

လူ႔ဘဝဆိုတာ ဆီးေဆာ့ေပၚ လမ္းေလွ်ာက္ေနတာနဲ႔ တူတယ္။

အျမဲပဲ နိမ့္ရာကေန ျမင့္ရာကို စေလွ်ာက္ရတယ္။
ေျခတစ္လွမ္း လွမ္းတိုင္း ေနာက္တစ္လွမ္းဟာ အရင္တစ္လွမ္းထက္ ပိုခက္ခဲေနတတ္တယ္။

အျမင့္ကိုေရာက္ေလ တည္ျငိမ္ဖို႔ ခက္ေလျဖစ္တယ္။

သင့္ကိုယ္သင္ အျမင့္ကို ေရာက္ေနျပီလို႔ ထင္တဲ့အခ်ိန္ဟာ
ကုန္းအဆင္းကို သင္ စဆင္းေနျပီျဖစ္တယ္။

ဒါေၾကာင့္ သင္ေရာက္ခ်င္တဲ့ အျမင့္မွာ ဘယ္ေတာ့မွ
သင္ အျမဲမရပ္ႏိုင္ဘူးဆိုတာကို သင္သတိျပဳမိလိမ့္မယ္။

တည္ျငိမ္မွတ္ကို သင္ရွာမေတြ႔မခ်င္း အျမင့္မွာ ရပ္ႏိုင္ဖို႔ဆိုတာ
ဘယ္ေလာက္ခက္ခဲေၾကာင္း

သင္အၾကိမ္ၾကိမ္ ေတြေဝျပီးမွ သတိျပဳမိလိမ့္မယ္။

ဘဝရဲ႕ တည္ျငိမ္မွတ္ကို ရွာေတြ႔မွ အဲဒီေနရာသာလွ်င္ အျမင့္ဆံုးဆိုတာကို

တစ္ေန႔ေန႔ တစ္ခ်ိန္ခ်ိန္မွာ သင္ခံစားမိလိမ့္မယ္။

အဲဒီလို အျမင့္ဆံုးမွာ ရပ္ႏိုင္ဖို႔ သင့္မွာ တစ္ျခားနည္းတစ္ခု ရွိေသးတယ္။
အဲတာကေတာ့ ဆီးေဆာ့ရဲ႕တစ္ဖက္မွာ သင့္ကို ေတာင့္ခံ(အားေပး) တဲ့လူ ရွိဖို႔ပဲ…
အဲဒီလူေတြက သင့္မိသားစု၊ သင့္ခ်စ္သူ ဒါမွမဟုတ္
သင့္ရဲ႕ ျပဳိင္ဖက္လဲျဖစ္ႏိုင္တယ္။

ႏိုင္းႏိုင္းစေန

original from: http://www.youthwant.com.tw

This is how we work.

1. How the customer explained it
2. How the Project Leader understood it
3. How the Analyst designed it
4. How the Programmer wrote it
5. How the Business Consultant described it
6. How the Project was documented
7. How operations installed
8. How the customer was billed
9. How it was supported
10. What the customer really needed

ဒီထဲမွာ သေဘာအက်ဆံုးကေတာ့ How the Project was documented နဲ ့ How it was supported ဆိုတာကိုပါပဲ။ ဟုိတေလာကဆို User ေတြ လက္ရွိသံုးေနတဲ့ Software တစ္ခုမွာ ျပႆနာ တစ္ခုတတ္လို ့ Investigation လုပ္ေပးပါတဲ့။ ဒါနဲ ့ လုပ္ေပးမယ္ အဲ့ဒီ Project ရဲ့ Documentation ေလးအရင္ေပးပါ ေျပာလိုက္ေတာ့ လြန္ခဲ့တဲ့ ၃ ႏွစ္ေက်ာ္က ေရးထားတဲ့ Documentation လာေပးတယ္။ ၾကည့္လိုက္ေတာ့ ခုလက္ရွိဟာ နဲ ့ အေတာ္ကို ကြာျခားေနၿပီ။ အေသအခ်ာ ေမးၾကည့္ေတာ့မွ ဒီႏွစ္ေတြအတြင္း အဲ့ဒီ Project ကို Enchantment အၾကိမ္ေပါင္းမ်ားစြာ လုပ္ခဲ့တယ္တဲ့။ အခ်ိန္မရ (Very Tide Schedules) မို ့ ဘာ Technical Documents မွ အသစ္ထပ္ မလုပ္ႏိုင္ခဲ့ဘူး၊ လိုခ်င္ရင္ေတာ့ User Requirement Documents ေတြပဲ ရွိတဲ့ေလ။ ေကာင္းေရာ။ ဒါဆိုလည္း အဲ့ဒီက Function ေတြ ဘယ္လို အလုပ္လုပ္လဲ သိမွျဖစ္မယ္၊ ဒါမွ ဘယ္ေနရာေတြမွာ၊ ဘာမွားေနလဲ သိႏိုင္မွာျဖစ္လို ့ Functional Specification နဲ ့User Guide တစ္ခုခု ေပးပါလို ့ ေျပာလိုက္ေတာ့.. Document အေဟာင္းေတြပဲရွိလို ့ စံုလင္မွာ မဟုတ္တဲ့အတြက္ ဒီမွာ 10 Years ေက်ာ္ Experience ရွိေနတဲ့ BA (Business Analyst) တစ္ေယာက္ကို သိခ်င္တာေတြရွိရင္ သြားေမးပါ၊ ဒီ Software ကို အဲ့ဒီ BA အကုန္သိပါတယ္ေလ။

ပထမဆံုးအလုပ္၀င္ခ်ိန္တုန္းကေတာ့ အဲ့ဒီမွာ Documentation အျပည့္အစံုမရွိတာေတြ ့ေတာ့ ဒီ Company ကေသးလို ့ စည္းစနစ္မက်လို ့ မရွိတာလို ့ပဲ ထင္ခဲ့မိတယ္။ ဒါေပမယ့္ ေနာက္ပိုင္း ၾကာလာေတာ့ Company အေတာ္မ်ားမ်ားက ဒီလိုပါပဲ၊ Documentation ဆိုတာကို ရွိတယ္ ေျပာႏိုင္ရံုေလာက္သာ၊ အျဖစ္သေဘာေလာက္ လုပ္ေနၾကမွန္း သိလာရေတာ့တယ္။

How the Programmer wrote it ဆိုတာေလးကို ျမင္ရေတာ့ Programmer ေတြ တခါတေလမွာ အလြယ္လိုက္ၿပီး ျဖစ္သင့္တာ မျဖစ္သင့္တာကိုလည္း ဂရုမထား၊ အလုပ္ျမန္ျမန္ၿပီးေအာင္လုပ္လိုက္ဖို ့ လြယ္လြယ္ကူကူ ေရးလိုက္တတ္ၾကတာကို ေတြးမိၿပီး ရယ္ခ်င္သြားတယ္။ How the Business Consultant described it ဆိုတာကိုလည္း သေဘာက်တယ္။ ခုအခ်ိန္မွာ ကၽြန္မေဘးနားမွာ ရွိေနတဲ့ သူေတြက အဲ့လို ေတြၾကီးပဲ။ How the customer was billed ကိုျမင္ေတာ့ ပထမဆံုးအလုပ္က Boss ကို သတိရတယ္။

How the customer explained it နဲ ့ What the customer really needed ကိုၾကည့္ၿပီး မွန္လိုက္တာလို ့ ေတြးမိတယ္။ Customer ေတြရွင္းတာ နားေထာင္ၿပီးရင္ ၊ သူတို ့ ဘာလိုခ်င္လို ့ ဘာေတြလုပ္ေစခ်င္ေနမွန္း သိေအာင္ လုပ္ရတာ ေတာ္ေတာ္ခက္တယ္။ ေနာက္ၿပီး တကယ္အသံုးျပဳမယ့္ User ေတြစီက Requirement ေတြ ယူရတာကလည္း အေတာ္ေလးခက္ပါတယ္။ ဒါေပမယ့္ အဲ့ဒီလို Customer ေတြ၊ Actual User ေတြနဲ ့ ေတြ ့ရတာ ေပ်ာ္စရာေတာ့ အေတာ္ေကာင္းသား။

ဒီပံုေလးက ကၽြန္မတို ့ လုပ္ကိုင္ေနရတဲ့ အလုပ္ပတ္၀န္းက်င္ အေၾကာင္းကို ေဖၚျပေပးေနသလို ၊ လူတဦးနဲ ့တဦး ေျပာဆို ၾကရာမွ ကိုယ္ေျပာခ်င္တာနဲ ့ သူနားလည္သြားတာ တူညီဖို ့ဆိုတာ အလြန္အေရးၾကီးေၾကာင္း သိသာေစပါတယ္။

Copy From Nay Nay Naing