குறிப்பு:
இந்தப் பதிவைப் படிப்பதற்கு முன்பு,
1)சாப்ட்வேர் டெஸ்டிங் – 5 – எங்கு தொடங்குவது?
2) சாப்ட்வேர் டெஸ்டிங் 6 – சாப்ட்வேர் எங்கு தொடங்குகிறது?
3) சாப்ட்வேர் டெஸ்டிங் – 10 மென்பொருள் உருவாக்கமும் சோதனையும்
ஆகிய பதிவுகளைப் படிக்க வேண்டியது இன்றியமையாத் தேவை.
மென்பொருள் வாழ்க்கை வட்டம்(Software Development Life Cycle) என்பது வாடிக்கையாளரிடம் மென்பொருளுக்கான திட்டத்தை வாங்குவதில் தொடங்கி, நிறைவாக, மென்பொருளை ஒப்படைப்பதில் முடிகிறது. இதில் மென்பொருள் வாழ்க்கை வட்டத்தை எங்கே தொடங்குவது என்பதை ஏற்கெனவே பார்த்திருக்கிறோம். தொடக்கத்தில் உருவாக்கப்படும் ஆவணம் என்ன என்பதையும் நாம் ஏற்கெனவே பார்த்து விட்டோம். அந்த ஆவணத்தில் அடிப்படையில் முறையாகத் திட்டமிட வேண்டும்.
திட்டமிடலின் அடிப்படையில் நிரலர்கள்(Developers) மென்பொருளை வடிவமைப்பது (Design), உருவாக்குவது(Develop) ஆகிய வேலைகளில் ஈடுபடத் தொடங்குவார்கள். வடிவமைப்பு, உருவாக்கம் ஆகியன ஒரே ஒரு நிரலர் செய்யும் வேலை இல்லை; பலரது கூட்டு முயற்சி! ஓர் அணியாகத் தான் செய்ய முடியும். ஒவ்வொரு நிரலரும் தாம் உருவாக்கிய அலகை(Module/Unit) முறையாகச் சோதித்து கிட் போன்ற தளத்தில் ஏற்றி விடுவார்கள். பிறகு ஒருங்கிணைப்புச் சோதனை(Integration Testing) நடத்தப்படும். இதைப் பற்றி விரிவாக நாம் ஏற்கெனவே படித்திருக்கிறோம்.
ஒருங்கிணைப்புச் சோதனைக்குப் பிறகு, முழுமையான சோதனை(Regression Testing) நடத்தப்படும். அதன் பிறகு பயனர் ஏற்புச் சோதனை(User Acceptance Testing) நடத்தப்பட்டு மென்பொருள் வெளியிடப்படும். சுருக்கமாகச் சொல்ல வேண்டும் என்றால்,
1) வாடிக்கையாளர் தேவைகளைப் பெறுதல் (Requirements Gathering)
2) தேவைகளை ஆராய்தல் (Requirements Analysis)
3) திட்டமிடல்(Planning)
4) வடிவமைப்பு, உருவாக்கம் (Design and Development)
5) சோதனையிடல் (Testing)
6) வெளியிடல், பேணல் (Implementation and Maintenance)
ஆகியன தான் மென்பொருள் வாழ்க்கை வட்டத்தின் படிநிலைகள் ஆகும்.
இந்தப் படிநிலைகளை எப்படிச் செயல்படுத்துவது என்று சொல்பவை தாம் சீர்வடிவங்கள்(Models) ஆகும். பல்வேறு மென்பொறியாளர்களின் பட்டறிவின் அடிப்படையில் பல வகை சீர்வடிவங்கள் நடைமுறையில் இருக்கின்றன. அவற்றுள் தலையாய சீர்வடிவங்கள்
1) அருவி(Waterfall) முறை
2) ‘வி‘ (V) முறை
3) தகவெளிமை(Agile) முறை ஆகியனவாகும்.
1) அருவி(Waterfall) முறை
அருவியில் நீர் எப்படிப் பாயும்? மேல் இருந்து கீழாகத் தானே! அதே போன்ற முறை தான் இந்த முறை! மென்பொருள் வாழ்க்கை வட்டத்தின் ஒரு படியில் இருந்து அடுத்த படிக்கு இறங்கி விட்டால் பிறகு, மேலே போகக் கூடாது. அதாவது, வாடிக்கையாளரிடம் எல்லாத் தேவைகளையும் கேட்டுத் தொகுத்த பின்னர், அடுத்து தேவைகளை ஆராயலாமே தவிர, திரும்பவும் வாடிக்கையாளரிடம் போய்த் தேவைகள் பற்றிப் பேசக் கூடாது. இதே போல் தான் அடுத்தடுத்த படிகளும்! மென்பொருளை உருவாக்கிச் சோதனையிடல் படிக்குப் போன பிறகு, திரும்பவும் உருவாக்குதல் படிக்கு ஏறக்கூடாது. இது தான் அருவி(Waterfall) முறை ஆகும்.
இந்த முறையை அறிமுகப்படுத்தியவர் அமெரிக்கக் கணினியாளர் வின்ஸ்டன் டபிள்யூ. ராய்ஸ் ஆவார்.
(பட உதவி: விக்கிப்பீடியா)
எங்குப் பயன்படுத்தலாம்?
அருவி முறையில் அதிகமாகக் கவனிக்க வேண்டிய ஒன்று – ஒரு படியில் இருந்து இறங்கிவிட்டால், மீண்டும் மேலே ஏற முடியாது என்பதைத் தான்! எனவே இந்த நடைமுறை எங்கு பொருந்துகிறதோ அங்கு அருவி முறையில் மென்பொருள் வாழ்க்கை வட்டத்தை அமைக்கலாம். எடுத்துக்காட்டாக, ஏற்கெனவே உருவாக்கப்பட்டு பயன்பாட்டில் உள்ள ஒரு மென்பொருளில் சின்ன மாற்றம் ஒன்றை ஏற்படுத்த வேண்டும் என்றால் அருவி முறையைப் பயன்படுத்தலாம். எ.காட்டாக, விக்கிப்பீடியா – இந்திய மொழிகளில் புதிய மொழி ஒன்றில் தன்னுடைய பக்கங்களை விரிவாக்குகிறது என்று வைத்துக்கொள்ளுங்கள். ஏற்கெனவே தமிழ் முதலிய மொழிகளில் விக்கிப்பீடியா இருக்கிறது அல்லவா? அதாவது, விக்கிப்பீடியா ஏற்கெனவே நிலையான நிரல்களால் உருவாக்கப்பட்டிருக்கிறது. இப்போது நடப்பது விரிவாக்கம் மட்டுமே! இது போன்ற சூழலில் அருவி முறையைச் செயல்படுத்தலாம்.
எங்கு உதவாது?
அருவி முறையைச் செயல்படுத்த வேண்டும் எனில், தொடக்கம் முதல் ஒவ்வொரு படியும் முறையாக, முழுமையாக முடிக்கப்பட வேண்டும் – அதாவது, வாடிக்கையாளர் தேவைகளை நிரலர் கேட்பதில் தொடங்கி, மென்பொருள் வெளியீடு வரை! ஆனால், பெரும்பாலான நேரங்களில் வாடிக்கையாளருக்குத் தம்முடைய தேவைகளை முழுமையாகப் பட்டியலிட முடியாது. மென்பொருளை உருவாக்க, உருவாக்க, வாடிக்கையாளர் – தம்முடைய தேவைகளைக் கூட்டுவது தான் பெரும்பாலான நடைமுறை. எனவே, அருவி முறை பெரும்பாலும் புதிய திட்டப்பணிகளுக்கு(Project)ப் பொருந்தாது.
இது தவிர்த்து, இந்த முறையில் டெஸ்டர்களின் பங்களிப்பு கிட்டத்தட்ட கடைசிக்கட்டத்தில் தான் தொடங்குகிறது. டெஸ்டர்கள் எவ்வளவு முன்னர் களம் இறங்குவார்களோ தரத்தின் அளவு அவ்வளவு நன்றாக இருக்கும். அருவி முறையில் டெஸ்டர்கள் கடைசியாகக் களம் இறங்குவது ஒருவகையில் சின்ன இழப்புத் தான்.
அருவி முறையில் உள்ள இந்தச் சிக்கலைப் போக்க வந்த சீர்வடிவம் தான் ‘வி‘(V) சீர்வடிவம்!
‘வி‘(V) சீர்வடிவம்:
முன்னர் பார்த்த அருவி முறையைப் போன்றதே தான் வி முறையும்! ஆனால் ஒரு குறிப்பிடத்தகுந்த வேறுபாட்டுடன் – டெஸ்டர்கள் முன்னரே களம் இறக்கிவிடப்படுவார்கள் என்பதே அது! அதைத் தான் மேல் உள்ள படம் விளக்குகிறது.
1) பயனர் தேவைகளை வாங்கி, நிரலர்கள் ஆராயும் அதே நேரத்தில் – டெஸ்டர்கள் முழுமைச் சோதனை(Regression Testing)க்கான டெஸ்ட் கேஸ்களை எழுதுவார்கள்.
2) தேவைகளின் அடிப்படையில் உயர் வடிவமைப்பில் (High Level Design) நிரலர்கள் ஈடுபடும் போது, அந்த உயர் வடிவமைப்புக்கேற்ற டெஸ்ட் கேஸ்களை டெஸ்டர்கள் எழுதுவார்கள்.
3) பின்னர் நிரலர்கள் – ஒவ்வோர் அலகுக்கும் விரிவான வடிவமைப்பை(Low Level Design) உருவாக்கும் போது – டெஸ்டர்கள் ஒருங்கிணைப்புச் சோதனைக்கான (Integration Testing) டெஸ்ட் கேஸ்களை எழுதி வைப்பார்கள்.
4) நிரலர்கள் நிரல் எழுதி முடிக்கும் போது, டெஸ்டர்கள் அந்தந்த வகை டெஸ்ட் கேஸ்களை எடுத்து சோதனைகளைச் செய்யத் தொடங்குவார்கள்.
இந்த முறையில், வடிவமைப்பு(Design) நடந்து கொண்டிருக்கும் போதே, டெஸ்டர்கள் டெஸ்ட் கேஸ்களை எழுதத் தொடங்குகிறார்கள் அல்லவா? அருவி முறையைப் போல் அல்லாது, இப்படித் தான் இங்கு டெஸ்டர்கள் முன்னரே களம் இறக்கிவிடப்படுகிறார்கள். இப்படித் தான் வி முறையில் தர மேம்பாடு கொடுக்கப்படுகிறது.
‘வி‘ என்றால் என்ன?
‘வி‘ என்று ஆங்கிலத்தில் சொல்லப்படும் இந்த முறையின் ஒரு இடப்பக்கம் உள்ள வேலைகள் நடக்கும் போது டெஸ்டர்கள் டெஸ்ட் கேஸ்கள் எழுதுவார்கள் அல்லவா? அந்த நிலையைச் ‘சரிபார்த்தல்‘ (Verification) என்று சொல்வார்கள். பின்னர் நிரலாக்கம் முடிந்த பிறகு, டெஸ்டர்கள் சோதிப்பார்கள் அல்லவா? அந்த நிலைக்குச் ‘செல்லத்தக்கதாக்குதல்‘ (Validation) என்று பெயர். Verification, Validation ஆகிய இரண்டிலும் உள்ள முதல் எழுத்துகளைச் சேர்த்துத் தான் ‘வி‘ முறை என்று அழைக்கிறார்கள்.
எங்கு பயன்படுத்தலாம்?
எங்கெல்லாம் அருவி முறையைச் செயல்படுத்த முடியுமோ அங்கெல்லாம் அருவிமுறைக்கு மாற்றாக ‘வி‘ முறையைப் பயன்படுத்தலாம்.
என்ன குறைபாடு?
‘வி‘ முறையும் அருவி முறையில் உள்ள பிற குறைகளைத் தன்னகத்தே கொண்டிருக்கிறது. அதாவது, ஒவ்வொரு படியும் முடிந்த பிறகு தான் அடுத்த படிக்குத் தாவ முடியும் என்னும் குறைபாடு வி முறையிலும் இருக்கிறது தானே!
இன்னும் அண்மைக் காலங்களில் எல்லா இடங்களிலும் பயன்படுத்தப்படும் தகவெளிமை(Agile) முறை பற்றிப் பார்க்க வேண்டியிருக்கிறது. அடுத்த பதிவில் அதைப் பார்ப்போமா?
– கி. முத்துராமலிங்கம்(muthu@payilagam.com)