ഒരു സോഫ്റ്റ്‌വെയർ നിര്‍മ്മിക്കപ്പെടുന്നതെങ്ങിനെ?

Read Time:29 Minute

ലല്ലു ആന്തൂര്‍

അറിവിന്റെ കലവറയാണ് പുസ്തകങ്ങളും ലേഖനങ്ങളും. എന്നാൽ ഒരു പുസ്തകം അല്ലെങ്കിൽ ഒരു ലേഖനം തയ്യാറാവുന്നതിനു പിന്നിലുള്ള ബുദ്ധിമുട്ട് ചെറുതൊന്നുമല്ല. വിദ്യാഭ്യാസ രംഗത്തേയും പ്രസിദ്ധീകരണ രംഗത്തേയും എല്ലാവരും നേരിടുന്ന ഒരു പ്രശ്നമാണ് തങ്ങളുടെ പ്രബന്ധങ്ങളുടേയും ലേഖനങ്ങളുടേയും മറ്റും പല പതിപ്പുകൾ കാര്യക്ഷമമായി കൈകാര്യം ചെയ്യുക എന്നത്. മറ്റൊരാളുമായി സഹകരിച്ചാണ് എഴുതുന്നത് എങ്കിൽ ബുദ്ധിമുട്ട് വീണ്ടും കൂടും. കൈയ്യെഴുത്തു പ്രതികൾ പലതും മേശപ്പുറം കയ്യടക്കും. ഒടുവിൽ ഒരു ലേഖനത്തിന്റെ ഏറ്റവും പുതിയ പ്രതി ഏതെന്നു അറിയാൻ പറ്റാതെ വരും. ഇതിനു ഒരു പരിഹാരമാണ് കംപ്യൂട്ടർവൽക്കരിച്ച വേർഡ് പ്രോസസ്സിംഗ് സോഫ്റ്റ്‌വെയറുകൾ. കമ്പ്യൂട്ടറിൽ ആവുമ്പോൾ എഴുതി കടലാസ്സ് കളയണ്ട. എല്ലാം ഫയലുകൾ ആയി കമ്പ്യൂട്ടറിൽ സൂക്ഷിക്കാം. എന്നാൽ പലർ ചേർന്ന് ഒരു ലേഖനം എഴുതുമ്പോൾ എന്ത് ചെയ്യും? എല്ലാവരും ഒരേ കമ്പ്യൂട്ടറിൽ തന്നെ എഴുതുക എന്ന് പറയുന്നത് പ്രായോഗികമല്ല. ഒരാൾ എഴുതി കഴിഞ്ഞതിനു ശേഷം അടുത്തയാൾ എഴുതാം എന്ന് വിചാരിച്ചാൽ എഴുത്ത് തീരാൻ വളരെ അധികം സമയം എടുക്കും. എല്ലാവരും അവരുടെ ഭാഗങ്ങൾ ഓരോ ഫയൽ ആയി എഴുതി ഇമെയിൽ മുഖാന്തരം അയക്കുക എന്നതാണ് മറ്റൊരു ഉപാധി. അതിൽ തിരുത്തുകൾ വരുത്തി സഹ എഴുത്തുകാർ മറുപടി അയക്കും. അവസാനം എല്ലാ എഴുത്തുകാരുടെയും കയ്യിൽ ഒരുപാട് ഫയലുകൾ ആവും. കോലാഹലം മേശപ്പുറത്തു നിന്നും കമ്പ്യൂട്ടറിന്റെ ഡെസ്ക്ടോപ്പിലേക്ക് മാറും. 10 ഓ 15 ഓ പേജുകൾ ഉള്ള ഒരു ലേഖനം ആണെങ്കിൽ തന്നെ ഈവിധം കൈകാര്യം ചെയ്യുക അസാധ്യമാകും. അപ്പോൾ 100 ഓളം ആളുകൾ ചേർന്നു നിർമിക്കുന്ന ആയിക്കണക്കിനു ഫയലുകൾ ഉള്ള ഒരു സോഫ്റ്റ്‌വെയർ എപ്രകാരം ആയിരിക്കും കൈകാര്യം ചെയ്യുന്നുണ്ടാവുക? ഉദാഹരണത്തിന് പ്രമുഖ സ്വതന്ത്ര ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ആയ ലിനക്സ് നിർമിച്ചിരിക്കുന്നത് ഏകദേശം അറുപതിനായിരത്തോളം ഫയലുകളിലായി വ്യാപിച്ചിരിക്കുന്ന രണ്ടു കോടി വരികൾ ചേർന്നാണ്.

സോഫ്റ്റ്‌വെയർ എൻജിനീയർമാർ ഈ പ്രശ്‌നം ഏറ്റെടുത്തു. ഇതിനു പരിഹാരം കാണാൻ ഉള്ള ഒരു സോഫ്റ്റ്‌വെയർ അവർ നിർമിക്കാൻ ആരംഭിച്ചു. അതിനായി ആദ്യം അവർ ചെയ്തത് ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയറിന്റെ ഉപഭോക്താക്കളെ കണ്ട് അവരുടെ കാതലായ പ്രശ്നങ്ങൾ മനസിലാക്കുകയും അവർ ആഗ്രഹിക്കുന്ന മികവുകളേയും സൗകര്യങ്ങളേയും കുറിച്ച് മനസ്സിലാക്കുകയുമായിരുന്നു. അടിസ്ഥാനപരമായി അവരുടെ ആവശ്യങ്ങൾ ഇപ്രകാരം ആയിരുന്നു:

ഒന്നിൽ അധികം ആളുകൾക്ക് ഒരേ സമയം മറ്റൊരാളുടെ ജോലിയെ തടസപ്പെടുത്താതെ എഴുതാനും തിരുത്താനും പറ്റണം;
ഒന്നിൽ അധികം ആളുകൾ ഒരേ ഫയലിൽ തന്നെ മാറ്റങ്ങൾ വരുത്തുന്നു എങ്കിൽ അവയിൽ ഏത് വേണം എന്ന് തിരഞ്ഞെടുക്കാൻ പറ്റണം.

ഈ ആവശ്യങ്ങൾ മുൻനിർത്തി ആണ് വേർഷൻ കൺട്രോൾ സോഫ്റ്റ്‌വെയർ എന്ന ഇനം സോഫ്റ്റ്-വെയറുകൾ രൂപം കൊണ്ടത്. എപ്രകാരമാണ് ഒരു സോഫ്റ്റ്‌വെയർ രൂപം കൊള്ളുന്നത് എന്നതിലേക്കുള്ള ഒരു എത്തിനോട്ടം ആണ് ഈ ലേഖനം.

ആവശ്യമാണല്ലോ കണ്ടുപിടുത്തങ്ങളുടെ മാതാവ്. ഏതൊരു സോഫ്റ്റ്‌വെയർന്റെയും തുടക്കവും ഇതുപോലെ എന്തെങ്കിലും ആവശ്യകതയിലാണ്. അതുകൊണ്ടുതന്നെ ഔപചാരികമായി അംഗീകരിച്ച സോഫ്റ്റ്‌വെയർ നിർമാണ പ്രക്രിയയുടെ ആദ്യ പടിയും ആവശ്യകത മനസിലാക്കൽ ആണ് (requirement analysis/gathering). ഇവിടെ സ്വരുക്കൂട്ടുന്ന പ്രശ്നങ്ങളും അവ പരിഹരിക്കേണ്ടതിന്റെ ആവശ്യകതകളും ലിഖിത രൂപത്തിൽ തയാറാക്കുന്നു. സോഫ്റ്റ്‌വെയർ നിർമാണ പ്രക്രിയ ദിശ തെറ്റി പോവാതിരിക്കാനാണ് ഇങ്ങനെ ഒരു കാര്യം ചെയ്യുന്നത്. പലചരക്ക് കടയിൽ സാധനം വാങ്ങാൻ പോയി അവിടെ പത്രം വായിച്ചിരുന്നു ഒടുവിൽ സാധനം വാങ്ങാതെ തിരിച്ച വരുന്ന അവസ്ഥ ഉണ്ടാവരുതല്ലോ. സോഫ്റ്റ്‌വെയർ നിർമാണത്തിലെ തുടർന്നുള്ള എല്ലാ പ്രക്രിയകളും ഈ ലിഖിത രൂപത്തിലുള്ള ആവശ്യകതകൾക്ക് അനുസരിച്ചാവും ചിട്ടപ്പെടുത്തുക. ഈ രേഖ ആണ് എത്തിപ്പെടേണ്ട ലക്ഷ്യം. എന്നാൽ ഇത്തരം ഒരു രേഖ ഒരിക്കലും മാറ്റം വരാത്ത ഒന്നല്ല. സാഹചര്യങ്ങൾക്ക് അനുസരിച്ച് ഈ രേഖയിലും മാറ്റം വരുത്തേണ്ടിവരും. അതിനുള്ള കാരണങ്ങൾ പലവിധമാണ്. നിയമപരമോ സാങ്കേതികപരമോ ആയ ഒരു മാറ്റം ആവാം അത്തരം ഒരു വ്യതിയാനത്തിൽ കലാശിക്കുന്നത്. ഉദാഹരണത്തിന് നികുതി കണക്കുകൂട്ടുന്ന സോഫ്റ്റ്‌വെയറിന് ജി എസ് ടി വന്നപ്പോൾ മാറ്റം വന്നതുപോലെ. മാറ്റം വരാനുള്ള മറ്റൊരു കാരണം ആവശ്യകതയിലുള്ള മാറ്റമാണ്. ഒരു വ്യക്തിക്കോ സ്ഥാപനത്തിനോ വേണ്ടി സോഫ്റ്റ്‌വെയർ നിർമിക്കുമ്പോൾ അവരുടെ ആവശ്യങ്ങളിലുള്ള വ്യതിയാനവും ഇതുപോലെ ഒരു മാറ്റത്തിൽ കലാശിക്കും. പലപ്പോഴും സോഫ്റ്റ്‌വെയർ നിർമാണം പകുതി വഴിയിൽ നിൽകുമ്പോൾ ആവും ഇത്തരം മാറ്റങ്ങൾ വേണ്ടി വരുന്നത്. ഇത് സോഫ്റ്റ്‌വെയർ നിർമാണ പ്രവൃത്തിയെ സാരമായി ബാധിക്കുന്നു. ഇതിനെ എങ്ങിനെ പ്രതിരോധിക്കാം എന്നത് പിന്നീട് അവതരിപ്പിക്കാം.

ഇത്തരത്തിലുള്ള മാറ്റങ്ങൾ മനുഷ്യ ജീവിതത്തിലും സുലഭം. മനുഷ്യ പരിണാമത്തിലെ സുപ്രധാനമായ ഒരു അദ്ധ്യായമാണ് കൃഷിയുടെ തുടക്കം. വേട്ടയാടിയും കാട്ടുപഴങ്ങൾ ഭക്ഷിച്ചും ജീവിച്ചിരുന്ന മനുഷ്യൻ സ്വന്തമായി കൃഷി തുടങ്ങിയതോടെയാണ് നദീതടത്തിലേക്ക് താമസം മാറ്റുന്നതും ജല ഗതാഗതം സ്വീകരിക്കുന്നതും. കൃഷിക്ക് ആവശ്യമായ അധ്വാനം കുറയ്ക്കാനാണ് മൃഗങ്ങളെ ഉപയോഗിക്കാൻ തുടങ്ങുന്നതും പിന്നീട് വ്യാവസായിക വിപ്ലവം വന്നപ്പോൾ യന്ത്രങ്ങളിലേക്ക് തിരിയുന്നതും. മനുഷ്യന്റെ അധ്വാനം കുറക്കുക എന്നതായിരുന്നു ഇവിടെയൊക്കെ പ്രാഥമിക ആവശ്യമായി വന്നത്. കൂടുതൽ ഫലപ്രദമായി ഏറിയ ഭൂപ്രദേശം ഉഴുതു മറിക്കാനുള്ള ആവശ്യകത്തിൽനിന്നാണ് ട്രാക്ടർ എന്ന ആശയം ഉരുത്തിരിയുന്നത്.

പരിഹരിക്കേണ്ട പ്രശ്നങ്ങൾ എന്തെന്നും ആവശ്യകത എന്തെന്നും അറിഞ്ഞു കഴിഞ്ഞാൽ അടുത്ത പ്രക്രിയ ആ പ്രശ്നത്തിനെ എങ്ങിനെ പരിഹരിക്കാം എന്നുള്ള ചർച്ചകൾ ആണ്. ഒരു സോഫ്റ്റ്‌വെയറിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട ഘടകമാണ് അതിന്റെ ഡിസൈൻ. സോഫ്റ്റ്‌വെയറും മറ്റേതൊരു ഉത്പന്നത്തെയും പോലെ ഘടകങ്ങളായാണ് നിർമ്മിക്കാറുള്ളത്. നിർമാണ പ്രവൃത്തിയുടെ ഒരു ഘട്ടത്തിൽ ഈ ചെറു ഘടകങ്ങളെ ചേർത്ത് വച്ച് വലിയ ഒരു സോഫ്റ്റ്‌വെയറിന് രൂപം നൽകുന്നു. ഈ വിധം ഒരു നിർമാണ പ്രവൃത്തി നടക്കണമെങ്കിൽ എല്ലാ ഘടകങ്ങളും ഏത് വിധം മറ്റു ഘടകങ്ങളുമായി ചേർന്ന് പ്രവർത്തിക്കുന്നു എന്നതിന് വ്യക്തമായ ധാരണ തുടക്കത്തിൽ തന്നെ ഉണ്ടായിരിക്കണം. മോന്തായം വളഞ്ഞാൽ അറുപത്തിനാലും വളയും എന്ന് കേട്ടിട്ടില്ലേ. അതുപോലെതന്നെ ആണ് സോഫ്റ്റ്‌വെയർ ഡിസൈനും. ഡിസൈനിൽ പിഴച്ചാൽ സോഫ്റ്റ്‌വെയർ അമ്പേ പരാജയം ആയിരിക്കും. അതിനാൽ ഈ ഘട്ടത്തിന്റെ പ്രാധാന്യം കണക്കിലെടുത്ത് ഡിസൈൻ ചിട്ടപ്പെടുത്താൻ പല രീതികളും സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാർ ഉപയോഗിക്കുന്നു. ഒരു സോഫ്റ്റ്‌വെയർ ഡിസൈൻ ഡോക്യുമെന്റ് വളരെ വ്യക്തമായ ലിഖിത രൂപവും ധാരാളം ചിത്രങ്ങളും നിറഞ്ഞതാവും. ഓരോ ഘടകവും ചെയ്യേണ്ട കടമകളും അത് മറ്റു ഘടകങ്ങളുമായി സംവദിക്കുമ്പോൾ പാലിക്കേണ്ട ചട്ടങ്ങളും കൃത്യമായി രേഖപ്പെടുത്തിയിരിക്കും. ആ സോഫ്റ്റ്‌വെയർ ഒരു ഉപയോക്താവ് ഉപയോഗിക്കുമ്പോൾ ഉണ്ടാവുന്ന ആശയ വിനിമയം (data/process flow) മുതൽ വിവരം ഏത് വിധത്തിലാണ് കമ്പ്യൂട്ടറിൽ സൂക്ഷിക്കുന്നത് (database design), ആർക്കൊക്കെ എപ്പോഴൊക്കെ ഈ വിവരം കാണാനും അതിൽ മാറ്റം വരുത്താനും സാധിക്കും (authentication and authorization), ഏത് രീതിയിലാണ് ഈ വിവരങ്ങൾ ഒരു ഉപഭോക്താവിന്റെ മുന്നിൽ അവതരിപ്പിക്കുന്നത് (user interface/experience design) എന്നിവ അടക്കം പല സുപ്രധാന കാര്യങ്ങളും തീരുമാനിക്കുന്നത് ഈ ഘട്ടത്തിലാണ്. സോഫ്റ്റ്‌വെയർ ഏത് രീതിയിൽ ആണ് ഉപഭോക്താവിന് നൽകുന്നത് (വ്യക്തിഗത കമ്പ്യൂട്ടറിൽ/മൊബൈൽ ഫോണിൽ/ഇന്റർനെറ്റ് മുഖാന്തരം), ഏത് കമ്പ്യൂട്ടർ പ്രോഗ്രാമിങ്ങ് ഭാഷയിലാണ് സോഫ്റ്റ്‌വെയർ എഴുതുന്നത് തുടങ്ങിയ കാര്യങ്ങളും ഈ ഘട്ടത്തിൽ ആണ് തീരുമാനിക്കുക. ഈ തീരുമാനങ്ങളുടെ പ്രാധാന്യവും തെറ്റിയാലുണ്ടാവുന്ന ആഘാതവും കണക്കിലെടുത്ത് ഇത്തരം ജോലികൾ ചെയ്യാൻ ഏൽപ്പിക്കുന്നത് പരിചയസമ്പന്നരായ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാരെ ആയിരിക്കും. ഒരു ചെറു സംഘം സോഫ്റ്റ്‌വെയർ ആർക്കിടെക്ടുമാർ ചേർന്നാകും ഈ ഡിസൈൻ തയ്യാറാക്കുക.

ട്രാക്ടർ നിർമാണ പ്രക്രിയ നമ്മൾ നിരീക്ഷിച്ചാൽ ഇത്തരം ഒരു ഡിസൈൻ പ്രക്രിയ നമുക്ക് അവിടെയും കാണാം. യന്ത്രഭാഗങ്ങളുടെ അളവും ആകൃതിയും രണ്ടു യന്ത്രഭാഗങ്ങൾ ഏതു വിധം തമ്മിൽ ചേർന്ന് പ്രവർത്തിക്കുന്നു എന്നും മുൻകൂട്ടി തീരുമാനിക്കപ്പെടുന്നു. ഏത് പദാർത്ഥം ഉപയോഗിച്ചാണ് യന്ത്രഭാഗങ്ങൾ നിർമ്മിക്കേണ്ടതെന്നും ഈ ഘട്ടത്തിൽ തീരുമാനിക്കപ്പെടുന്നു. മനുഷ്യാധ്വാനം കുറയ്ക്കാൻ ഒരു മോട്ടോർ എൻജിൻ ഘടിപ്പിക്കാൻ തീരുമാനിക്കുന്നു. നനഞ്ഞതോ ഉറപ്പില്ലാത്തതോ ആയ വയൽ നിലങ്ങളിൽ തെന്നിപ്പോവാതിരിക്കാൻ വലിയ പിൻചക്രങ്ങൾ ഉപയോഗിക്കാൻ തീരുമാനിക്കുന്നു. വലിയ പിൻചക്രങ്ങളുടെ കാര്യക്ഷമമായ പ്രവർത്തനത്തിന് എൻജിനിൽ നിന്ന് ഗിയർ മുഖാന്തരം ഊർജം പിൻചക്രങ്ങളിലേക്ക് നേരിട്ട് എത്തിക്കുന്നു. പിൻചക്രത്തിന്റെ ശക്തിയിൽ ട്രാക്ടർ സഞ്ചരിക്കുമ്പോൾ മുൻചക്രങ്ങൾ പൊങ്ങി പോവാൻ സാധ്യത ഉള്ളതിനാൽ എൻജിൻ മുൻചക്രങ്ങളുടെ ഇടയ്ക്ക് വയ്ക്കാൻ തീരുമാനിക്കുന്നു. ട്രാക്ടർ പ്രവർത്തിപ്പിക്കുന്ന ആൾക്ക് ഇരിക്കാൻ ഇരിപ്പിടവും ട്രാക്ടറിന്റെ ഗതി നിയന്ത്രിക്കാൻ സ്റ്റിയറിങ്ങും വേഗത നിയന്ത്രിക്കാൻ കാലുകൊണ്ട് പ്രവർത്തിക്കുന്ന ബ്രേക്കും ആക്സിലറേറ്ററും ഘടിപ്പിക്കുന്നു. ഈ ഭാരവും, കൂടാതെ നിലം ഉഴുതു മറിക്കാനുള്ള അധ്വാനവും താങ്ങാൻ ശേഷിയില്ലാത്ത ഒരു എൻജിൻ ആണ് ട്രാക്ടറിൽ ഘടിപ്പിക്കുന്നതെങ്കിലോ? ചക്രങ്ങൾ ചതുരാകൃതിയിൽ ആയാലോ? ഇരിക്കാനുള്ള ഇരിപ്പിടം ഒരുപാട് വലുതോ ചെറുതോ ആയാലോ? കയറാനുള്ള ചവിട്ടുപടിക്ക് ഉയരം കൂടിയാലോ? ബ്രേക്ക് ചവിട്ടുമ്പോൾ ട്രാക്ടർ നിന്നില്ലെങ്കിലോ? ഇന്ധനം നിറക്കുന്ന ടാങ്കിനു ആവശ്യത്തിനുള്ള ഇന്ധനം സംഭരിച്ചു വയ്ക്കാനുള്ള ശേഷി ഇല്ലെങ്കിലോ? ട്രാക്ടർ നിയന്ത്രിക്കാൻ അതിസങ്കീർണ്ണമായ നൂറുകണക്കിന് ബട്ടണുകൾ നിറഞ്ഞ ഒരു സംവിധാനം ആണെങ്കിലോ? ഇതെല്ലാം ഒരു ട്രാക്ടറിന്റെ പ്രവർത്തനത്തെ പ്രതികൂലമായി ബാധിക്കും. പരിഹരിക്കാൻ ശ്രമിക്കുന്ന പ്രശ്നം പരിഹരിക്കപ്പെടുകയും ഇല്ല മറിച്ച് കൂടുതൽ കഠിനമാവുകയും ചെയ്യും. ഇത്തരം ഒരു ട്രാക്ടർ കടുത്ത പരാജയം ആയിരിക്കും എന്ന് പറയേണ്ടതില്ലല്ലോ.

ട്രാക്ടറിന്റെ ഡിസൈൻ തയ്യാറായിക്കഴിഞ്ഞാൽ അടുത്ത ഘട്ടം അതിന്റെ നിർമ്മാണമാണ്. പല ഭാഗങ്ങളും സമാന്തരമായി ചെറു സംഘം തൊഴിലാളികൾ ചേർന്ന് നിർമിക്കുന്നു. ഉരുക്കിയതും ചൂടാക്കി പഴുപ്പിച്ചതും തണുത്തതും ആയ ലോഹഭാഗങ്ങൾ കൈകാര്യം ചെയ്യാൻ പ്രത്യേകമായി തയ്യാറാക്കിയ പണിയായുധങ്ങൾ ഉണ്ടാവും. എൻജിൻ മുതലായ ഭാഗങ്ങൾ ലോഹം ഉരുക്കി അച്ചിൽ ഒഴിച്ച് തണുപ്പിച്ചാണ് ഉണ്ടാക്കുക. പുകക്കുഴലും മറ്റും ചൂടാക്കി പഴുപ്പിച്ച് രൂപം മാറ്റി എടുക്കുന്നു. ചക്രങ്ങളുടെ ലോഹഭാഗങ്ങളും ട്രാക്ടറിന്റെ പുറംചട്ടയും ഒക്കെ നിർമിക്കാൻ തണുത്ത ലോഹത്തെ ഹൈഡ്രോഫോമിംഗ് എന്നുപറഞ്ഞ ഒരു പ്രക്രിയ ഉപയോഗിച്ച് ആവശ്യമായ ആകൃതിയിലേക്ക് മാറ്റി എടുക്കാറാണ് പതിവ്. പൽ ചക്രങ്ങളും മറ്റും കട്ടിയുള്ള ലോഹത്തെ പല യന്ത്രങ്ങളും ഉപയോഗിച്ച് മുറിച്ചും രാകിയും ആണ് നിർമിക്കുന്നത്. സീറ്റ് മുതലായ തുണി ഭാഗങ്ങൾ നിർമിച്ചു നൽകാൻ ഒരുപക്ഷേ മറ്റൊരു കമ്പനിക്ക് തന്നെ കരാർ കൊടുത്തേക്കാം. റബ്ബർ ഉപയോഗിച്ചുള്ള ടയറിനും ഇത് ബാധകമാണ്. യന്ത്രഭാഗങ്ങൾ ചേർത്തുനിർത്തുന്ന പിരിയനാണികളും പുറമെനിന്ന് വാങ്ങാനാണ് എളുപ്പം. ടയറിന്റെ റബ്ബർ ഭാഗത്തിന് ലോഹഭാഗത്തേക്കാൾ വലുപ്പം കൂടുകയോ കുറയുകയോ ചെയ്‌താൽ പ്രശ്നമാണ്. അതുപോലെ തന്നെ ആണ് എൻജിനിലെ പിസ്റ്റണും സിലിണ്ടറും. ഡിസൈനിൽ പറഞ്ഞിരിക്കുന്ന അളവിൽ നിന്നും തെല്ലിട പോലും വ്യതിയാനമില്ലാതെ അവ നിർമിക്കേണ്ടിയിരിക്കുന്നു.

യന്ത്രഭാഗങ്ങൾ നിർമിക്കുന്ന അതേ സൂക്ഷ്മതയോടെയാണ് ഒരു സോഫ്റ്റ്‌വെയറും നിർമിക്കുന്നത്. സോഫ്റ്റ്‌വെയർ നിർമാണ ഘട്ടത്തെ implementation അല്ലെങ്കിൽ development ഘട്ടം എന്ന് പറയും. ഈ ഘട്ടത്തിൽ മുൻകൂട്ടി തയ്യാറാക്കിയ ഡിസൈൻ പ്രകാരം, നിശ്ചയിച്ചിരിക്കുന്ന പ്രോഗ്രാമിങ് ഭാഷയിൽ സോഫ്റ്റ്‌വെയറിന്റെ അടിസ്ഥാനമായ കോഡ് അഥവാ പ്രോഗ്രാം എഴുതപ്പെടും. ഇത് താരതമ്യേന ലഘുവായ എന്നാൽ ഒരുപാട് സമയമെടുക്കുന്ന ജോലിയാണ്. അതുകൊണ്ടുതന്നെ പൊതുവെ പരിചയം കുറഞ്ഞ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാരാവും ഈ ജോലി ചെയ്യുക. അവർക്ക് വേണ്ടുന്ന മാർഗനിർദേശം നൽകാനും നിർമാണത്തിലെ പുരോഗതി വിലയിരുത്താനും നിർമാണ പ്രവർത്തിയിലെ ബുദ്ധിമുട്ടുകൾ മനസിലാക്കി അവ പരിഹരിക്കാനും പരിചാരസമ്പന്നരായ ഒരു കൂട്ടം സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാരും കാണും. ഡിസൈനിലെ പല ഘടകങ്ങളും സമാന്തരമായാവും ഉണ്ടാക്കുക. അപ്പോൾ പത്ത് ‌പേരോളം വരുന്ന ചെറു സംഘങ്ങളായാണ് ഓരോ ഘടകത്തിലും പണി എടുക്കുന്നത്. ഈ പത്തു പേരിൽ പരിചയസമ്പന്നരായ രണ്ടോ മൂന്നോ പേരുണ്ടാവും. കൂടുതൽ പേരും വലിയ അനുഭവസമ്പത്ത് ഇല്ലാത്തവരാവും. നിർമാണ പ്രക്രിയയിൽ ചിലവാകുന്ന പണം ക്രമീകരിക്കാനാണ് ഇങ്ങനെ ഒരു സജ്ജീകരണം. ചെറുപ്പക്കാരാവുമ്പോൾ ചുറുചുറുക്കോടെ കാര്യങ്ങൾ ചെയ്യുകയും അതിവേഗം നിർമാണം പുരോഗമിക്കുകയും ചെയ്യും. ഇത്തരം ചെറു സംഘങ്ങൾ സ്വതന്ത്രമായ ഘടകങ്ങളും പരസ്പരം ആശ്രയിച്ചു പ്രവർത്തിക്കുന്ന ഘടകങ്ങളും നിർമിക്കുന്നു. പരസ്പരം ആശ്രയം വരുന്ന സാഹചര്യങ്ങളിൽ ഇരു സംഘത്തിലേയും മുതിർന്ന ആളുകൾ കൂടിച്ചേർന്നു ഡിസൈൻ പ്രകാരം എങ്ങിനെ അത് നിർമിക്കാം എന്നും ഏത് സംഘം ഏതൊക്കെ ഭാഗങ്ങൾ നിർമിക്കും എന്നും തീരുമാനിക്കും. ഒരു ട്രാക്ടർ നിർമാണത്തിൽ എന്നപോലെ ഇവിടെയും പണിയായുധങ്ങൾ പലതാണ്. സോഫ്റ്റ്‌വെയറിന്റെ കാതലായ ഭാഗം എഴുതാൻ ഇന്റഗ്രേറ്റഡ് ഡെവലപ്മെന്റ് എൻവയേൺമെൻറ് അഥവാ IDE കൾ ആവും ഉപയോഗിക്കുക. പ്രോഗ്രാമിങ്ങിൽ സാധാരണ കടന്നുവരാറുള്ള തെറ്റുകൾ ചൂണ്ടിക്കാണിക്കാനും ചില തെറ്റുകൾ സ്വയമേ തിരുത്താനും ഇത്തരം IDE കൾ പ്രാപ്തരാണ്. സോഫ്റ്റ്‌വെയറിന്റെ സുരക്ഷ പരിശോധിക്കാനും മറ്റുമായി ചില ടൂളുകൾ വേറെയും ഉണ്ട്. എഴുതുന്ന പ്രോഗ്രാം സൂക്ഷിച്ചുവയ്ക്കാൻ ഉള്ള ടൂളുകളും സുലഭം.

ഒരുകാലത്തു ഇത്തരം ടൂളുകൾ വളരെ വിരളമായിരുന്നു. ലിനക്സിന്റെ പിതാവായ ലിനസ് ടോർവാൾഡ്‌സ് ഇത്തരം ഒരു പ്രശ്നത്തിൽ പെട്ടു. ലിനക്സ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം നിർമിക്കുന്ന തിരക്കിൽ ആയിരുന്നു അദ്ദേഹം. അപ്പോഴാണ് തന്റെ വിപുലമായ പ്രോഗ്രാം സൂക്ഷിക്കാൻ ഉതകുന്നതരത്തിലുള്ള ഒരു ടൂൾ ഇല്ല എന്ന യാഥാർഥ്യം അദ്ദേഹം മനസിലാക്കുന്നത്. അങ്ങിനെ രൂപം കൊണ്ട ഒരു ടൂൾ ആണ് പ്രശസ്ത വേർഷൻ കണ്ട്രോൾ സോഫ്റ്റ്‌വെയർ ആയ ഗിറ്റ് (git). പിന്നീട് അത് പരിഷ്കരിച്ച് ഗിറ്റ് ഹബ്, ഗിറ്റ് ലാബ്, ബിറ്റ് ബക്കറ്റ് തുടങ്ങി ഒട്ടനേകം സേവനങ്ങൾ ഓൺലൈൻ ആയി ലഭിക്കാൻ തുടങ്ങി. ലിനക്സ് ഉൾപ്പെടെ ഒട്ടുമിക്ക ഓപ്പൺ സോഴ്സ് സോഫ്റ്റ്‌വെയറുകളും ഇപ്പോൾ ഗിറ്റ് ഹബ് വഴി ആണ് അവരുടെ പ്രവർത്തനങ്ങൾ നടത്തുന്നത്. ഡെബിയൻ ആവട്ടെ ഗിറ്റ് ലാബിലും.

എത്രയൊക്കെ മുൻകരുതലുകൾ എടുത്താലും ഏതൊരു കാര്യത്തിലും മനുഷ്യസഹജമായ തെറ്റുകൾ വരും എന്നത് സ്വാഭാവികം. സോഫ്റ്റ്‌വെയർ നിർമാണവും അതുപോലെ തന്നെ ആണ്. അതിനാൽ തെറ്റുകൾ എളുപ്പത്തിലും വേഗത്തിലും കണ്ടുപിടിക്കാൻ ഉള്ള ഉപാധികൾ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാർ സ്വീകരിക്കും. ഓരോ ചെറു ഘടകങ്ങളെയും ഒറ്റക്കൊറ്റയ്ക്കും മറ്റു ഘടകങ്ങളുമായി ചേർത്തുവച്ചും ഉദ്ധിഷ്ഠ ഫലം ലഭിക്കുന്നുണ്ടോ എന്ന് ഉറപ്പുവരുത്തും. പുതുതായി ഒരു കാര്യം കൂടെ സോഫ്റ്റ്‌വെയർ ചെയ്യണമെങ്കിൽ അതിനുള്ള കോഡ് കൂടെ എഴുതിച്ചേർക്കേണ്ടിയിരിക്കുന്നു. അപ്പോൾ നിലവിലുള്ള പ്രവർത്തനങ്ങൾക്ക് വിഘ്നം ഉണ്ടാവാത്ത രീതിയിൽ വേണം കോഡ് എഴുതാൻ. സോഫ്റ്റ്‌വെയറിന്റെ ഓരോ ഘടകത്തിലും മാറ്റങ്ങൾ വരുമ്പോൾ ഇത്തരം പരിശോധനകൾ അനിവാര്യമാണ്. അതുകൊണ്ടുതന്നെ ഇത്തരം പരിശോധനകൾ നടത്താൻ പ്രത്യേകം ഒരു കൂട്ടം ആളുകൾ തന്നെ കാണും. അവരെ സഹായിക്കാൻ ഒരു കൂട്ടം ടൂളുകൾ വേറെയും. ഈ ഘട്ടത്തെയാണ് ടെസ്റ്റിങ്ങ് എന്ന് പറയുന്നത്. ഒരു സോഫ്റ്റ്‌വെയർ ഏറ്റവും കൂടുതൽ സമയം ചിലവഴിക്കുന്നത് ടെസ്റ്റിങ്ങ് ഘട്ടത്തിലാണ്. ഏതെങ്കിലും ഒരു ഘടകത്തിലോ രണ്ടു ഘടകങ്ങൾക്കിടയിലെ ആശയവിനിമയത്തിനോ പ്രശ്നമുണ്ട് എന്ന് കണ്ടെത്തിയാൽ അത് നിർമിച്ച ആളുകളെ ബന്ധപ്പെടുകയും ഏത് സാഹചര്യത്തിലാണ് പ്രതീക്ഷിച്ച ഫലം കിട്ടാത്തത് എന്ന് അറിയിക്കുകയും ചെയ്യും. ഒരു വലിയ സോഫ്റ്റ്‌വെയറിൽ ഇത്തരം പലവിധം പ്രശ്നങ്ങൾ ഉണ്ടാവാം. അവയെല്ലാം ഓർത്തുവയ്ക്കുക അസാധ്യമാണ്. അതിനാൽ ഇത്തരം പ്രശ്നങ്ങളെ ബഗ്ഗ് (bug)‌ എന്നാണ് വിളിക്കുക. അവ രേഖപ്പെടുത്താനും അതിന്റെ പുരോഗതി നിരീക്ഷിക്കാനും പ്രത്യേകം ടൂളുകൾ ഉണ്ട്. സോഫ്റ്റ്‌വെയറിന്റെ മറ്റൊരു പ്രത്യേകത എന്നത് അത് ഹാപ്പി ഫ്ലോയിൽ മാത്രം ശരിയായി പ്രവർത്തിച്ചാൽ പോരാ എന്നതാണ്. എല്ലാ ഘട്ടത്തിലും ശരിയായ ഇൻപുട്ട് ഒരു ഉപഭോക്താവ് നൽകുകയാണെങ്കിൽ അതിനെയാണ് ഹാപ്പി ഫ്ലോ എന്ന് പറയുന്നത്. എന്നാൽ ഉപഭോക്താവ് തെറ്റായ ഒരു ഇൻപുട്ട് നൽകിയാൽ ആ സാഹചര്യവും ഒരു സോഫ്റ്റ്‌വെയർ നല്ലരീതിയിൽ കൈകാര്യം ചെയ്യണം. ഉദ്ദേശിച്ച ഫലം ലഭിക്കാതിരുന്നാൽ അത് തന്റെ പ്രശ്നമാണോ സോഫ്റ്റ്‌വെയറിന്റെ പ്രശ്നമാണോ എന്ന് ഉപഭോക്താവിനെ അറിയിക്കാനാണ് ഇത്. ഉദാഹരണത്തിന് ഒരു കാൽക്കുലേറ്റർ സോഫ്റ്റ്‌വെയറിൽ രണ്ടു അക്കങ്ങൾക്ക് പകരം രണ്ടു അക്ഷരങ്ങളുടെ തുക കണ്ടുപിടിക്കാൻ നോക്കിയാൽ ഉത്തരം ഒന്നും ലഭിക്കില്ല. എന്നാൽ അതിനുമപ്പുറം ഉപഭോക്താവിനോട് എന്താണ് പ്രശ്നം എന്നും അത് എങ്ങിനെ പരിഹരിക്കണം എന്നും പറഞ്ഞുകൊടുക്കാൻ സോഫ്റ്റ്‌വെയറിനു സാധിക്കണം.

ഒരു ട്രാക്ടർ നിർമിക്കുമ്പോഴും ഇതുപോലെ ഒരു ടെസ്റ്റിങ്ങ് പ്രക്രിയ ഉണ്ട്. ഓരോ ചെറു ഘടകങ്ങളെയും അതുപോലെ തന്നെ അവ ചേർത്തുവെച്ചതിനു ശേഷവും ഇതുപോലെ ടെസ്റ്റിങ്ങ് നടക്കുന്നു. നിർമാണത്തിന് തിരഞ്ഞെടുക്കുന്ന ലോഹം മുതൽ ഓരോ ചെറു ഘടകങ്ങളും വരെ ഗുണനിലവാരം ഉറപ്പുവരുത്തിയതിനുശേഷമാണ് ഉപയോഗിക്കാറ്. എഞ്ചിൻ പോലുള്ള വലിയ ഭാഗങ്ങൾ നേരിട്ട് ടെസ്റ്റ് ചെയ്യാനുള്ള ബുദ്ധിമുട്ട് കാരണം നോൺ-ഡിസ്ട്രക്റ്റീവ് ടെസ്റ്റിങ്ങ് അഥവാ എൻ ഡി ടി ആണ് ചെയ്യാറ്. ഈ പ്രക്രിയയിൽ എഞ്ചിനിലേക്ക് ശബ്ദ തരംഗങ്ങൾ കടത്തിവിട്ട് അവയെ ചിത്രരൂപത്തിലേക്ക് മാറ്റി എഞ്ചിന്റെ ഘടന ശരിയായ വിധത്തിൽ ആണോ എന്ന് പരീക്ഷിക്കും. മനുഷ്യശരീരത്തിൽ അൾട്രാ സൗണ്ട് സ്കാൻ ചെയ്യുന്നതിന് സമാനമാണ് ഈ പ്രക്രിയ. എഞ്ചിൻ തുടങ്ങിയ ഘടകങ്ങൾ ചേർത്തുവയ്പിച്ചു കഴിഞ്ഞാൽ ട്രാക്ടർ സ്റ്റാർട്ട് ആവുന്നുണ്ടോ, ഗിയർ ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടോ, ചക്രങ്ങൾ കറങ്ങുന്നുണ്ടോ തുടങ്ങിയ പരിശോധനകൾ കൂടി നടത്തും. അവസാനം ട്രാക്ടർ പൂർണമായ ശേഷം ഒന്ന് ഓടിച്ചു നോക്കിയ ശേഷമേ അതിനെ വിപണിയിലേക്ക് ഇറക്കൂ. ട്രാക്ടർ പോലുള്ള ഉപകാരങ്ങളുടെ കാര്യത്തിലും പലയിടങ്ങളിലും ഉപഭോക്താവിന് മനസിലാവുന്ന രീതിയിൽ പ്രശ്നങ്ങൾ പറഞ്ഞുകൊടുക്കുന്ന സൂചകങ്ങൾ കാണും. എഞ്ചിൻ ബാറ്ററി തീർന്നാൽ അല്ലെങ്കിൽ ഇന്ധനം തീർന്നാൽ കത്തുന്ന ഇൻഡിക്കേറ്റർ ലൈറ്റുകൾ ഇതിനു ഉദാഹരണം.

ഇത്തരത്തിൽ നിരവധി മറ്റു സോഫ്റ്റ്‌വെയറുകളുടേയും ടൂളുകളുടേയും സഹായത്തോടെയാണ് ഒരു സോഫ്റ്റ്‌വെയർ രൂപം കൊള്ളുന്നത്. അവയെല്ലാം ചേർന്ന് പ്രവർത്തിച്ച് സുഗമമായ ഒരു സോഫ്റ്റ്‌വെയർ നിർമാണ പ്രക്രിയ പ്രദാനം ചെയ്യുന്നതിന് ശ്രമിക്കുന്നു. സഹായത്തിനുള്ള ഇത്തരം ടൂളുകൾ തിരഞ്ഞെടുക്കുമ്പോഴും ശ്രദ്ധ കൊടുക്കേണ്ടിയിരിക്കുന്നു എന്ന് ചുരുക്കം. പരസ്പരം ചേർന്ന് പ്രവർത്തിക്കാത്ത ടൂളുകൾ ഉപയോഗിച്ചാൽ സോഫ്റ്റ്‌വെയർ നിർമാണം അത്രത്തോളം ശ്രമകരമാവും. ഇങ്ങനെ രൂപംകൊള്ളുന്ന സോഫ്റ്റ്‌വെയർ ആണ് നമ്മൾ എല്ലാവരും ഉപയോഗിക്കുന്നത്. അതിനു പിന്നിലുള്ള പ്രക്രിയ സങ്കീർണവും എന്നാൽ അതിനെ സ്നേഹിക്കുന്നവർക്ക് അത്രത്തോളം ആനന്ദകരവും ആണ്. സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാർ അമാനുഷികരൊന്നും അല്ലെന്നും ഏതൊരു നിർമാണപ്രവർത്തനത്തിലും എന്നപോലെ ഉള്ള സ്വാഭാവികമായ ഒരു പ്രക്രിയ മാത്രമേ ഇവിടെയും ഉള്ളു എന്നും സാരം. നമ്മുടെ സാങ്കേതിക വിദ്യാഭ്യാസ സംവിധാനം ഇത്തരം ഒരു മേഖലക്ക് സജ്ജമാക്കിയാണോ നമ്മളെ ഒരുക്കുന്നത് എന്നത് മറ്റൊരു ലേഖനത്തിലേക്ക് ബാക്കി വയ്ക്കുന്നു.