மென்பொருட் பொறியியல்

கட்டற்ற கலைக்களஞ்சியமான விக்கிப்பீடியாவில் இருந்து.
(மென்பொருள் பொறியியல் இலிருந்து வழிமாற்றப்பட்டது)
தாவிச் செல்லவும்: வழிசெலுத்தல், தேடல்

வரலாறு[தொகு]

1940களில் கணினியானது வன்பொருளை (ஹாட்வெயார்) வடிவமைப்பதே பகீரதப் பிரயத்தனமாக இருந்தது. முதலாம் சந்ததிக் கணினிகளில் எந்த ஒரு இயங்குதளமும் இருக்கவில்லை. கணினிக்குத் தரவானது சுவிச்களூடாகவும் (switch) காந்த நாடாவூடாகவுமே (Magenetic Tapes) ஊடாகவே உள்ளிடப்பட்டது. 1950 களில் இரண்டாம் சந்ததிக் கணினிகள் உருவாகத் தொடங்கின. இவை சாள்ஸ் டார்வினின் கூர்புத் தத்துவம் போன்று இவை கணினி இயங்குதளத்தைக் கொண்டிருந்ததுடன் இக்காலப் பகுதியில் மேல் தர நிரலாக மொழிகள் (High Level Programming Languages) உருவாக்கத் தொடங்கின. வன்பொருட்களின் திறனானது பலமடங்காகாக அதிகரித்ததுடன் அவற்றில் விலையானது சரமாரியாகக் குறையத் தொடங்கியது. இம்மாறுதல்களால் கணினியில் மென்பொருட்களை உருவாக்குதலில் கூடுதலாகக் கவனம் திரும்பியது. கணினிகள் பல்வேறுபட்ட பிரயோகங்களைக் கையாளும் வண்ணம் உருவாக்கப்பட்டது.

மென்பொருட்கள் இலகுவான நிரலாக்கலில் இருந்து மிகவும் சிக்கலான பரந்து பட்ட தேவைகளுக்காக உருவாகத் தொடங்கியது. இவற்றை உருவாக்குவதிலும் சிரமங்கள் ஏற்பட்டன. சிறிய நிரல்களை உருவாக்குவதற்கு பாவிக்கப்பட்ட உத்திகள் பெரிய மென்பொருட்களைப் உருவாக்கப் பாவிப்பதற்கு உபயோகிக்க முடியாமல் இருந்தது. இதில் முறையாக ஆவணப்படுத்தாமை, சிறப்பான திட்டமிடல் இன்மை, சீர்தரமான நிரலாக்கல் இன்மை, மென்பொருள் விருத்தியாளர்களுக்கிடையிலான கூட்டு விருத்தியாக்கம் இன்மை போன்ற பெரும் பிரச்சினையாக அமைந்தது. இதன் காரணமாக மென்பொருளின் விலை வரம்புமீறீயது, திட்டமிட்ட திகதிக்குள் மென்பொருளை விருத்திசெய்ய முடியாமல் இருந்தது. இதைத் தீர்த்து வைப்பதற்காக மேலும் நிரலாக்கர்கள் திட்டங்களிற்குத் சேர்க்கப்பட்டனர். ஆனால் இதனால் மேலும் மென்பொருள் விருத்தியாக்கம் மேலும் பிற்போடப்பட்டது. இதற்கு முக்கிய காரணம் என்னவெனில் திட்டத்திற்கு சேர்க்கப்பட்ட புதிதான நிரலாக்கர்களை பயிற்றுவிப்பதில் செலவிடப்பட்ட நேரவிரயமும் மென்பொருள் விருத்தியாளர்களுக்கிடையிலான கூட்டிணைவும் இல்லாமையாகும்.

மென்பொருளும் மென்பொருள் பொறியியலும்[தொகு]

மென்பொருள் ஓர் நிரலாக்கலின் சேர்கை (Collection of Programs) அன்று. நிரல் ஆனது பொதுவாக ஓர் குறிப்பிட்ட பிரச்சினையை கணினியூடாகத் தீரத்துவைப்பதற்காக உருவாக்கப்பட்டதாகும். இதைப் பெரும்பாலும் உருவாக்கிய நிரலாக்கரே பாவிப்பதுடன் இது பொதுவாக ஆவணப்படுத்தப் படுவதில்லை.

மென்பொருளானது பல கணினி நிரல்களுடன், அவற்றின் செயன்முறை, விதிகள் மற்றும் அவற்றுடன் இணைந்த ஆவணங்களைக் குறிப்பிடுகின்றது.

மென்பொருட் பொறியியியல் ஆனது மென் விருத்தியில் ஏற்பட்டுள்ள பிரச்சினைகளை அலசி ஆராய்ந்து தீர்த்துவைக்கும் முறையாகும். இது எனைய பொறியியல் நடைமுறைகளில் இருந்து மாறுபட்டதாகும் ஏனெனில் இயற்கையாக (இலங்கைத் தமிழ்: பௌதீகரீதியாக) இவை எவற்றையும் கொண்டிராமல் மென்பொருட்களை அலசி ஆராய்வதாகும். இந்தத் தொடர்பாடல் இடைவெளியே "பகுத்தறிவுத் தூரம்" (Intellectual Distance) என்றழைக்கப்படுகின்றது. மென்பொருட்களின் தோல்வியானது பல காரணங்களால் ஏற்படுகின்றது. அவையான "திட்டமிடல் பிழைகள்", "மென்பொருட் பிழைகள்", தேவைகளில் ஏற்படும் மாற்றங்கள் போன்றனவாகும். மென்பொருட் பொறியியலின் நோக்கமானது சிறந்த மென்பொருளை பொருளாதார ரீதியாக இலாபகரமாக உருவாக்குதல் ஆகும்.

மென்பொருட் பொறியல் ஆனது IEEE இன் வரைவிலக்கணப்படி "ஓர் ஒழுங்குமுறைப்படி மென்பொருளை விருத்திசெய்து, இயக்கிப் பாரமரிப்பதே மென்பொருட் பொறியியல் ஆகும்"

மென்பொருள் விருத்தியில் கட்டங்கள்[தொகு]

எந்தவொரு பிரச்சினையையும் தீர்ப்பதற்கு அந்தப் பிரச்சினையை ஐயம் திரிபு அற அறிதல் வேண்டும். பின்னர் அதை திட்டமிட்டு, நிரலாக்கி இறுதியாக அதைச் சோத்திப் பார்த்தல் வேண்டும். இச்செய்கைகளுக்கிடையிலான ஓர் தெளிவான எல்லைகள் இல்லை. எந்த மென்பொருள் விருத்தியானதும் இந்த நடைமுறைகளைப் பின்பற்ற வேண்டும் பெரிய மென்பொருள் விருத்தித் திட்டங்களில் இவை சம்பிரதாய பூர்வமாகக் கடைப்பிடிக்கப்படும். ஒவ்வொரு நடவடிக்கையும் சிக்கலானதாக இருப்பின் அவற்றைச் சிறு சிறு பகுதிகளாகப் பிரித்துக் கையாளலாம். கீழ்வருவன மென்பொருள் விருத்தியின் முக்கிய படிமுறைகள் ஆகும்.

  1. மென்பொருளை விருத்திசெய்ய இயலுமா என்பதைக் கண்டறிதல்
  2. தேவைகளை அலசி ஆராய்தல்
  3. ஒழுங்கமைத்துத் திட்டம் ஒன்றை உருவாக்குதல்.
  4. நிரலாக்கல்
  5. சோதித்தல்
  6. நடைமுறைப்படுத்தல்
  7. பராமரித்தல்

மென்பொருளை விருத்திசெய்ய இயலுமா என்பதைக் கண்டறிதல்[தொகு]

அளவு கடந்த வளங்களும் அளவு கடந்த நேரமும் இருந்தால் எல்லாத் திட்டங்களும் சாத்தியமானவையே. எனினும் நடைமுறையில் மென்பொருள் விருத்தித் திட்டங்கள் மட்டுப்படுத்தப்பட்ட நேரத்தையும் மட்டுப்படுத்தப்பட்ட நிரலாக்கர்களையுமே கொண்டுருப்பதால் எல்லாத் திட்டங்களும் நடைமுறையில் சாத்தியம் என்பதற்கில்லை. எனவே திட்டமொன்றின் நடைமுறைச் சாத்தியத்தியத்தை அத்திட்டத்தின் ஆரம்பத்திலேயே கண்டறிதல் அவசியம் ஆகும். மென்பொருளை விருத்திசெய்ய இயலுமா எனக் கண்டறிகையில் நான்கு முக்கிய பகுதிகள் கணக்கிற் கொள்ளப்படும்.

  1. பொருளாதாரச் சாத்தியக்கூறுகள் - இத்திட்டத்தை நடைமுறைப்படுத்துதால் ஏற்படும் செலவானது இத்திட்டத்தினால் ஏற்படும் வசதிகள் அல்லது வருமானத்துடன் ஒப்பிடுகையில் போதுமானதா?
  2. தொழில்நுட்பச் சாத்தியக்கூறுகள் - இத்திடத்தை நடைமுறைப்படுத்துவதில் உள்ள நிரலாக்கல் வேலைகள், வினைத்திறன் மற்றும் வேறு இடர்பாடுகள் போன்றன ஏற்றுக்கொள்ளக் கூடிய முறையில் மென்பொருள் ஒன்றை உருவாக்கமுடியுமா?
  3. சட்டரீதியான சாத்தியக்கூறுகள் - இத்திட்டத்தை நடைமுறைப்படுத்துவதில் சட்ட ரீதியான சிக்கல்கள் ஏதும் உள்ளதா?
  4. மாற்றுவழிகள் - இம்மென்பொருளை உருவாக்க மாற்றுத்திட்டங்களை வழிவகுத்தல்.

இந்த மென்பொருளை விருத்தி செய்ய இயலுமா எனக் கண்டறியும் அறிக்கையானது திட்ட நடைமுறைப்படுத்தல் (அமுலாக்கலில்) உள்ள அதிகாரி ஒருவரினால் மீளாய்வு செய்யப்படும். இந்த ஆய்வில் இருந்து மேற்கொண்டு திட்டமொன்றை முன்னெடுப்பதா இல்லையா என்று தீர்மானிக்கப்படும்.

தேவைகளைக் கண்டறிதல்[தொகு]

மென்பொருட் தேவைகளை ஐயம் திரிபற அறிதலானது மென்பொருள் விருத்தியின் வெற்றியைத் தீர்மானிக்கும் முக்கிய ஓர் படிமுறையாகும்.

மென்பொருட் தேவைகளைக் கண்டறியும் ஆய்வுமுறையானது "தேவைகளை ஆராய்ந்து, அவற்றை ஒழுங்கமைத்து, மாதிரிகளை உருவாக்கி மென்பொருட் தேவைகளை வரையறுப்பதாகும்".

இந்த ஆய்வானது மென்பொருட்களின் தேவைகளைக் கண்டறிவதற்காகச் செய்யப்படுகின்றது. இச்செயன்முறையில் மென்பொருள் விருத்தியாளரும் வாடிக்கையாளும் ஒன்றாக அமர்ந்து வாடிக்கையாளரின் தேவைகளைச் சரியாகக் கண்டறியவேண்டும். இவர்களுக்கிடையில் பெரும்பாலும் பலர் தொடர்பாடற் சிக்கல்கள் இருக்கும்.

தேவைகளைக் கண்டறியும் படிமுறையானது ஓர் ஆவணத்தில் அதன் தேவைகள் பதியப்படும். இந்த ஆவணமானது மேலும் சீர் செய்யப்பட்டு "மென்பொருட் தேவைகளை வரையறுக்கும்" ஓர் ஆவணமாக மாற்றப்படும். இத்தேவைகளை நிறைவேற்றும் ஒருவர் சிஸ்டம் பகுப்பாளர் அல்லது சிஸ்டம் அனலைஸ்ட் (System Analyst) என்றவாறு அழைக்கப்படுவார். இந்நிலையில் இரண்டு முக்கிய படிமுறைகள் செய்யப்படும்.

  1. பகுப்பாய்வு செய்தல்
  2. தேவைகளை வரையறை செய்தல்

பகுப்பாய்வு செய்தல் முற்று முழுதாக ஓர் சிஸ்டம் ஒன்றில் பிரச்சினைகளையும் அதன் பொருத்தாமான தன்மைகளையும் கண்டறிதல் ஆகும். அந்த மென்பொருளில் உள்ள தரவுகள் எங்கெங்கெல்லாம் நடவடிக்கை எடுக்கவேண்டும், அதன் தேவைகள், உள்ளீடுகள் மற்றும் வெளியீடுகள் போன்றவை இதுவரை இல்லாத ஓர் சிஸ்டத்தை (System) ஐ விளங்குவது கடிமாகத்தான் இருக்கும். சிஸ்டம் பகுப்பாளர் வாடிக்கையாளருக்கு புதிய சிஸ்டத்தைப் பற்றி எடுத்துரைத்து அதன் அனுகூலங்களையும் அடையாளம் காண உதவுவார்.

இந்தக் கட்டமானது இதன் தேவைகளைச் வரையறுத்தது சரியாக என சரிபார்ப்பதுடன் நிறைவுறுகின்றது. இதன் நோக்கமானது வாடிக்கையாளரில் எல்லாத் தேவைகளும் சரியான முறையில் தேவைகளை வரையறுக்கும் ஆவணத்தில் குறிப்பிடப்பட்டுள்ளதாக எனக் கண்டறிவதாகும்.

சிஸ்டம் வடிவமைப்பு[தொகு]

வடிவமைப்பு (ஆங்கிலம்: டிசைன்) என்பது எந்தவொரு பொறியியற் செயன்முறையில் முதலாவதாகச் செய்யப்படும் ஓர் வழிமுறையாகும். இலகுவான முறையில் இக்கட்டத்தை விபரிப்பதானால் இது ஏற்கனவே "தேவைகளை வரையறுத்த ஆவணத்தின் படி" மென்பொருளை உருவாக்குதலுக்கான திட்டமிடல் நடவடிக்கையாகும். தேவைகளை எவ்வாறு பூர்த்திசெய்கின்றோம் என்பதே இங்கு பிரதானமானதாகும். இக்கட்டத்தின் வெளியீடாக ஓர் திட்டமிடல் ஆவணம் ஒன்று தயாரிக்கப்படும்.

மென்பொருள் வடிவமைப்பு என்பது பல்வேறு பட்ட உத்திகளைக் கையாண்டு அதிலுள்ள சாதனங்கள், செய்கைகள், மற்றும் மென்பொருளின் போதுமான தகவல்களைக் கொடுத்து அது எவ்வாறு தோற்றமளிக்கும் என்பதை வெளிக்காட்டுவதாகும்.

இந்த ஆவணம் ஆனது ஓர் தீர்வொன்றை அளிக்கும் திட்டமொன்றின் திட்டமிடலாகும். இது பின்னர் மென்பொருளை நடைமுறைப்படுத்துவதிலும், சோதிப்பதிலும், பராமரிப்பதிலும் பயன்படுத்தப்படும். இதில் இரண்டு முக்கிய வழிமுறைகள் கையாளப்படும்

  1. சிஸ்டம் வடிவமைப்பு
  2. விரிவான வடிவமைப்பு

பெரிய சிஸ்டமானது சிறிய பகுதிகளாகப் பிரிக்கப்படும். இவை தனியாக விருத்திசெய்யக் கூடியதாக மிகச்சிறியபகுதிகளப் பிரிக்கப்படும். இவ்வாறான அணுகுமுறையானது பிரச்சினைகளைப் பிரித்தாழும் (Divide and Conquer) முறையாகும். ஏனெனில் பகுதிகளானது தனித்தனியே விருத்தி செய்யப்படுவதால் ஏனைய பகுதிகளில் செய்ற்பாடுகள் பற்றிய நல்ல விளக்கம் இருத்தல் அவசியம் ஆகும். இவ்வாறு சிஸ்டத்தைப் பிரிக்கும் போது விருத்தியாளர் ஆனவர் பிரிக்கப்பட்ட பகுதியிலேயே கவனம் செலுத்த வேண்டும்.

இந்த டிசைன் ஆனது மீளாய்வுகளுக்கு உட்படுத்தப்பட்டு சரியென உறுதிப்படுத்தப்பட்டதும் இந்தப் படிமுறையானது நிறைவடைகின்றது..

நிரலாக்கம்[தொகு]

இந்தப்படி முறையின் நோக்கமானது மென்பொருள் வடிவமைப்பில் தரப்பட்ட ஆவணத்திற்கு அமைய பொருத்தமான நிரலாக்கல் மொழியில் சரியாகவும் வினைத்திறனானவும் நிரலாக்காப்படும். இது சோதித்தல் மற்றும் பராமரித்தற் படிமுறைகள் இப்படிமுறையிலே தங்கியுள்ளது. நன்றாக நிரலாக்கப்பட்ட மென்பொருளானது இந்த நோக்கத்தை நிறைவேற்ற உதவுகின்றது. இந்தப் படிமுறையானது கவனமெடுத்துச் செய்யப்படவேண்டும் ஏனெனில் சோதித்தல் மற்றும் பராமரித்தலுடன் ஒப்பிடுகையில் இது செலவு குறைவானதாகும். நிரலாக்கத்தின் இலகுவாக வாசித்து விளங்கக் கூடியவாறு நிரல்களை ஆக்குவதாகும். நிரலாக்கம் ஆனது பிழைகள் அற்றது என மீளாய்வு செய்யப்படும்.

சோதித்தல்[தொகு]

இப்படிமுறையானது மென்பொருட்களில் உள்ள பிழைகளைக் கண்டறியும் வகையில் மென்பொருளை இயக்குவதாகும். இது மென்பொருள் விருத்தியில் முக்கிய தரக்கட்டுப்பாட்டை உறுதிப்படுத்தும் செயற்படாகும். இச்செயற்பாடுகளூடாக மென்பொருளில் உள்ள சந்தேகத்திற்கிடமான அல்லது முரண்பாடான மென்பொருட் தேவைகளைக் கண்டறிவதோடு சிஸ்டம் வடிவமைப்பில் உள்ள பிழைகள் மற்றும் நிரலாக்கலில் உள்ள பிழைகள் கண்டறியப்படுகின்றன. மென்பொருளைச் சோதிப்பதன் மூலம் மென்பொருட் தேவைகளுக்கமைய மென்பொருளானது வடிவமைக்கப்பட்டுள்ளது உறுதிப்படுத்தப்பட்டுள்ளது. அத்துடன் இம்மென்பொருளானது வினைத்திறனாக இயங்குகின்றதா என்பதும் கண்டறியப்படுகின்றது. சோதனையில் இல்லாத அம்சங்கள் இதன் மூலம் கண்டறிய முடியாவிட்டாலும் தற்போதுள்ள மென்பொருளில் உள்ள குறைபாடுகளைக் கண்டறிய உதவுகின்றது.

மென்பொருட் சோதனைகள் இரண்டு வகைப்படும் ஒன்று வெள்ளைப் பெட்டிச் சோதனை (White Box Testing) மற்றையது கறுப்புப் பெட்டிச் சோதனை (Black Box Testing). இதில் கறுப்புப் பெட்டிச் சோதனையில் ஒவொரு பகுதியும் எவ்வாறு இயங்குகின்றது என்பதை உள்ளீடுகளைக் கோடுத்து அதில் வரும் வெளியீடுகளைச் சரிபார்பதன் மூலம் சரியாக இயங்குகின்றதா என்பது கண்டறியப்படும். வெள்ளைப் பெட்டிச் சோதனையில் நிரலாக்கம் ஆனது ஆய்வுசெய்யப்பட்டும். இது தவிர பல்வேறுபட்ட சோதனை மாதிரிகளும் பயன்படுத்தப்படும்.

சோதனையானது ஓர் திட்டமிட்ட வகையிலேயே நடத்தப்படும். அதில் எந்த விதமான சோதனைகள் செய்யப்படவேண்டும், எந்தக் காலப்பகுதியில் செய்யவேண்டும், எவ்வளவு வழங்களை ஒதுக்குதல் வேண்டும் மற்றும் சோதனைகளுக்கான வழிகாட்டல்கள் போன்றவை தீர்மானிக்கப்படும். இச் சோதனையின் முடிவில் சோதனை அறிக்கையும் வழு அறிக்கையும் சமர்பிக்கப்படும்.

நடைமுறைப்படுத்தல்[தொகு]

இந்தக் கட்டத்தில் ஏற்கனவே சோதனையில் ஈடுபடுத்தப்பட்ட மென்பொருளானது வாடிக்கையாளரின் கணினியில் நிறுவதாகும். இக்கட்டத்தில் வன்பொருள் (ஹாட்வெயார்) மற்றும் மென்பொருட்கள் உருவாக்கப்பட்ட இம்மென்பொருட்களுக்கமைய உள்ளதா எனக் கண்டறியப்படும். ஏதேனும் பிரச்சினைகள் கண்டறியப்பட்டால் அவை ஆவணப்படுத்தப்பட்டு விருத்தி செய்யப்பட்ட மென்பொருளானது வாடிக்கையாளரின் எதிர்பார்பிற்கமைய உள்ளவாறு சரிசெய்யப்படும்.

பராமரித்தல்[தொகு]

மென்பொருளின் வாழ்க்கைச் சக்கரத்தில் இது ஓர் முக்கியமான படிமுறையாகும். இது மென்பொருள் நிறுவலிற்குப் பின்னர் மென்பொருளானது சரியாக இயங்குகின்றதை உறுதிப்படுத்தும் எல்லாச் செயன்முறைகளும் இதில் அடங்கும். தேவைகளில் மாற்றங்கள் ஏற்படுவதனாலும் மென்பொருளைப் பராமரிக்கவேண்டி ஏற்படுகின்றது.

சாராம்சம்[தொகு]

பொறியியல் வழிமுறைகளில் (Engineering Methods) ஒழுங்கி மென்பொருள்களை வடிவமைப்பதை மென்பொருள் பொறியியல் (Software Engineering) என்பர். மென்பொருட் தேவைகளைக் கண்டறிந்து மென்பொருட்களை வடிவமைத்து, மென்பொருட்களை உருவாக்கி, மென்பொருட்களைச் சோதித்து பராமரிபதற்கான வழிமுறைகளாகும். மென்பொருட் பொறியியல் ஆனது கணினிப் பொறியியல், கணினி விஞ்ஞானம், முகாமைத்துவம், கணிதம், திட்டமிடம் முகாமைத்துவம், தர முகாமைத்துவம் மற்றும் மென்பொருட் பொறியியல் போன்றவற்றில் இருந்தும் வேண்டிய அறிவினைப் பெற்றுக்கொள்ளவும்.


மென்பொருள் வடிவமைப்பை மரபுசார் பொறியியல் என்று ஏற்றுக்கொள்ள பின்வரும் ஆட்சோபனைகளை சிலர் எழுப்புகின்றார்கள்:

  • மரபுசார் கணித, இயற்பியல், மற்றும் பிற அறிவியல் பாடங்களை கொண்டிருக்காதல்
  • மற்றய துறைகளை போல் இன்னும் சீராக வளர்ச்சியடையாமல் இருத்தல்
  • பாரிய மாற்றங்களுக்கு இன்னும் உட்பட்டு இருத்தல்

சில மென்பொருள் திறனர்கள், மென்பொருள் வடிவமைத்தல் ஒரு கலையெனவும், அச்செயலாக்கத்தை விபரிக்க software development என்ற சொலே பொருத்தம் என்று கூறுகின்றனர்.

அமைப்புக்கள்[தொகு]

"http://ta.wikipedia.org/w/index.php?title=மென்பொருட்_பொறியியல்&oldid=1517902" இருந்து மீள்விக்கப்பட்டது