ಟಿ. ಜಿ. ಶ್ರೀನಿಧಿ
ತಂತ್ರಾಂಶ ರಚನೆಯಲ್ಲಿ ಪಾಲಿಸಬೇಕಾದ ಕ್ರಮ, ನಿಯಮ-ನಿಬಂಧನೆಗಳ ರೂಪುರೇಷೆಯನ್ನು ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರಿಂಗ್ ಪರಿಕಲ್ಪನೆ ಮುಂದಿಡುತ್ತದೇನೋ ಸರಿ, ಆದರೆ ಆ ನಿಯಮ ನಿಬಂಧನೆಗಳು ಯಾವುವು, ಹಾಗೂ ಅವನ್ನು ಪಾಲಿಸುವುದು ಹೇಗೆ?
ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಜಗತ್ತಿನಲ್ಲಿ ಹಲವು ಕಾರ್ಯವಿಧಾನ ಮಾದರಿಗಳನ್ನು (ಪ್ರಾಸೆಸ್ ಮಾಡೆಲ್) ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಮಾದರಿಗಳು ತಂತ್ರಾಂಶ ರಚನೆಯ ವಿವಿಧ ಹಂತಗಳನ್ನು ಹಾಗೂ ಅಂತಹ ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಕೈಗೊಳ್ಳಬೇಕಾದ ನಿರ್ದಿಷ್ಟ ಚಟುವಟಿಕೆಗಳನ್ನು ನಮ್ಮ ಮುಂದಿಡುತ್ತವೆ. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ ತಂತ್ರಾಂಶ ರಚನೆ ಪ್ರಕ್ರಿಯೆಯ ಜೀವನ ಚಕ್ರವನ್ನೇ ನಿರ್ದೇಶಿಸುತ್ತವೆ.
ಮೂಲತಃ ಈ ಎಲ್ಲ ಮಾದರಿಗಳಲ್ಲೂ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರಿಂಗ್ ಪರಿಕಲ್ಪನೆಯಲ್ಲಿರುವ ಮೂಲ ಹೆಜ್ಜೆಗಳೇ (ರಿಕ್ವೈರ್‌ಮೆಂಟ್ಸ್ ಅನಾಲಿಸಿಸ್, ಡಿಸೈನ್, ಡೆವೆಲಪ್‌ಮೆಂಟ್, ಟೆಸ್ಟಿಂಗ್ ಇತ್ಯಾದಿ) ಬಳಕೆಯಾಗುತ್ತವೆ. ಆದರೆ ಪ್ರತಿಯೊಂದು ಮಾದರಿಯಲ್ಲೂ ಈ ಹೆಜ್ಜೆಗಳ ಅನುಷ್ಠಾನ ಮಾತ್ರ ಭಿನ್ನವಾಗಿರುತ್ತದೆ.
ಒಂದು ಉದಾಹರಣೆ ನೋಡೋಣ.
ವಾಟರ್‌ಫಾಲ್ ಮಾಡೆಲ್ ಎನ್ನುವುದು ಇಂತಹ ಮಾದರಿಗಳಲ್ಲೊಂದು. ತಂತ್ರಾಂಶ ರಚನೆಯ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಈ ಮಾದರಿ ಐದು ಹೆಜ್ಜೆಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ: ತಂತ್ರಾಂಶದ ಅಗತ್ಯಗಳನ್ನು ಅರಿತುಕೊಳ್ಳುವುದು ಮೊದಲ ಹೆಜ್ಜೆ. ಆ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕಂತೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಯೋಜಿಸಿಕೊಳ್ಳುವುದು, ಎಷ್ಟು ಸಮಯದಲ್ಲಿ ಕೆಲಸ ಮುಗಿಯಬೇಕೆಂದು ಅಂದಾಜಿಸಿಕೊಳ್ಳುವುದು ಎರಡನೆಯ ಹೆಜ್ಜೆಯ ಕೆಲಸ. ಅಗತ್ಯಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ ತಂತ್ರಾಂಶದ ವಿನ್ಯಾಸ ಹೇಗಿರಬೇಕು ಎಂದು ತೀರ್ಮಾನಿಸುವುದು ಮೂರನೆಯ ಹೆಜ್ಜೆ. ತಂತ್ರಾಂಶಕ್ಕೆ ಬೇಕಾದ ಕ್ರಮವಿಧಿಗಳನ್ನು ಬರೆದು ಪರೀಕ್ಷಿಸುವುದು ನಾಲ್ಕನೇ ಹೆಜ್ಜೆಯ ಚಟುವಟಿಕೆ. ಕೊನೆಯದಾಗಿ ತಂತ್ರಾಂಶವನ್ನು ಬಳಕೆದಾರನಿಗೆ ಕೊಟ್ಟು ಅದರ ಬಳಕೆಗೆ ಬೇಕಾದ ನೆರವು ನೀಡುವುದು ಕೊನೆಯ ಹೆಜ್ಜೆ.
ಇಲ್ಲಿ ಅನುಸರಿಸಲಾಗುವ ಹೆಜ್ಜೆಗಳು ಒಂದಾದ ನಂತರ ಒಂದರಂತೆ - ಬಹುತೇಕ ಏಕಮುಖವಾಗಿ - ನಡೆಯುವುದರಿಂದ ಅದನ್ನು ನೀರಿನ ಹರಿವಿಗೆ ಹೋಲಿಸಿ ಜಲಪಾತ (ವಾಟರ್‌ಫಾಲ್) ಎಂದು ಕರೆಯುತ್ತಾರೆ. ತಂತ್ರಾಂಶದ ಅಗತ್ಯಗಳು ಮೊದಲಿಗೇ ನಿಖರವಾಗಿ ಗೊತ್ತಾಗಬೇಕು ಎನ್ನುವುದು ಈ ಮಾದರಿಯ ನಿರೀಕ್ಷೆ. ಅಗತ್ಯಗಳನ್ನು ಅಂತಿಮಗೊಳಿಸಿದ ನಂತರವೇ ಮುಂದಿನ ಕೆಲಸವೆಲ್ಲ. ಬಳಕೆದಾರರು ಮೊದಲ ಹೆಜ್ಜೆಯಲ್ಲಿ ಏನು ಕೇಳಿರುತ್ತಾರೋ, ಕೊನೆಯ ಹಂತದಲ್ಲಿ ಅವರಿಗೆ ಸಿಗುವುದು ಅದೇ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕ ತಂತ್ರಾಂಶ.
ಇದರ ಅನುಷ್ಠಾನ ಕಾಗದದ ಮೇಲೆ ಸುಲಭವಾಗಿರುವಂತೆ ಕಂಡರೂ ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ ವಾಟರ್‌ಫಾಲ್ ಮಾದರಿಯ ಅನುಷ್ಠಾನ ಬಹಳ ಕಷ್ಟ. ಇದಕ್ಕೆ ಕಾರಣಗಳು ಹಲವು - ಮೊದಲಿಗೆ ಹೇಳುವುದಾದರೆ ಯಾವ ತಂತ್ರಾಂಶವೇ ಆದರೂ ಅದರ ಅಗತ್ಯಗಳು ಮುಂಚಿತವಾಗಿಯೇ ನಿರ್ಧಾರವಾಗುವ ಸಾಧ್ಯತೆ ಬಹಳ ಕಡಿಮೆ. ಇನ್ನು ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಹೊಸ ವಿಷಯಗಳು ಬೆಳಕಿಗೆ ಬಂದು ತಂತ್ರಾಂಶದ ಅಗತ್ಯ ಅಥವಾ ವಿನ್ಯಾಸದಲ್ಲಿ ಬದಲಾವಣೆ ಬೇಕಾಗುವುದೂ ಉಂಟು. ಹೀಗಿರುವಾಗ ಮೊದಲ ದಿನ ಹೇಳಿದ್ದಷ್ಟನ್ನೇ ಗಟ್ಟಿಯಾಗಿ ಹಿಡಿದಿಟ್ಟುಕೊಂಡು ಎರಡೋ ಮೂರೋ ತಿಂಗಳ ನಂತರ ಆ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕ ತಂತ್ರಾಂಶ ಸಿದ್ಧಪಡಿಸಿಕೊಂಡು ಬಳಕೆದಾರನ ಬಳಿ ಹೋದರೆ ಅದು ಸ್ವೀಕೃತವಾಗುವ ಸಾಧ್ಯತೆ ಬಹಳ ಕಡಿಮೆ; ಆಗ ಆತ ಸೂಚಿಸುವ ಬದಲಾವಣೆಗಳನ್ನೆಲ್ಲ ದಾಖಲಿಸಿಕೊಂಡು ಇನ್ನೆರಡು ತಿಂಗಳು ಕೆಲಸಮಾಡಬೇಕಾದ ಪರಿಸ್ಥಿತಿ ಬರುತ್ತದೆ ಅಷ್ಟೆ!
ಇನ್ನು ಕೆಲ ಕಾರ್ಯವಿಧಾನ ಮಾದರಿಗಳು (ಪ್ರಾಸೆಸ್ ಮಾಡೆಲ್) ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ವಾಟರ್‌ಫಾಲ್ ಮಾದರಿಯಲ್ಲಿದ್ದಂತೆ ತಂತ್ರಾಂಶ ರಚನೆಯ ಇಡೀ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಒಂದಾದ ಮೇಲೆ ಒಂದರಂತೆ ಏಕಮುಖವಾಗಿ ನಡೆಯುವ ಹೆಜ್ಜೆಗಳಾಗಿ ವಿಂಗಡಿಸುವ ಬದಲು, ಈ ಹೆಜ್ಜೆಗಳನ್ನು ಕ್ಷಿಪ್ರವಾಗಿ ಪುನರಾವರ್ತಿಸುವುದು ಇಂತಹ ಕೆಲ ಮಾದರಿಗಳ ಉದ್ದೇಶ. ಅಗತ್ಯಗಳನ್ನು ಅರಿತುಕೊಂಡ ತಕ್ಷಣವೇ ತಂತ್ರಾಂಶ ವಿನ್ಯಾಸದ ಯೋಜನೆ ಸಿದ್ಧಪಡಿಸಿಕೊಂಡು ಮೊದಲ ಮಾದರಿಯನ್ನು ಆದಷ್ಟು ಬೇಗ ಬಳಕೆದಾರನಿಗೆ ತಲುಪಿಸಲು ಈ ಮಾದರಿಗಳು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಇಂತಹ ಪ್ರತಿಯೊಂದು ಆವರ್ತನೆಯಲ್ಲೂ ಬಳಕೆದಾರನೊಡನೆ ಸಂಪರ್ಕ ಇಟ್ಟುಕೊಳ್ಳುವುದರಿಂದ ನಮ್ಮ ವಿನ್ಯಾಸದ ಬಗ್ಗೆ ಅವನ ಅನಿಸಿಕೆ ತಿಳಿದುಕೊಳ್ಳುವುದು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಮೂರೋ ನಾಲ್ಕೋ ಬಾರಿ ಈ ಪ್ರಕ್ರಿಯೆ ಪುನರಾವರ್ತನೆಯಾಗುವಷ್ಟರಲ್ಲಿ ಬಳಕೆದಾರನಿಗೆ ನಿಜಕ್ಕೂ ಏನು ಬೇಕು ಎನ್ನುವುದು ತಂತ್ರಾಂಶ ರಚಿಸುವವರಿಗೆ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಅಷ್ಟೇ ಅಲ್ಲ, ಅಂತಿಮವಾಗಿ ಸಿದ್ಧವಾಗುವ ತಂತ್ರಾಂಶ ಬಳಕೆದಾರನಿಗೆ ಇಷ್ಟವೂ ಆಗುತ್ತದೆ!
ತಂತ್ರಾಂಶ ರಚನೆಯಲ್ಲಿ ಪಾಲಿಸಬೇಕಾದ ಕ್ರಮ, ನಿಯಮ-ನಿಬಂಧನೆಗಳ ರೂಪುರೇಷೆಯನ್ನು ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರಿಂಗ್ ಪರಿಕಲ್ಪನೆ ಮುಂದಿಡುತ್ತದೇನೋ ಸರಿ, ಆದರೆ ಆ ನಿಯಮ ನಿಬಂಧನೆಗಳು ಯಾವುವು, ಹಾಗೂ ಅವನ್ನು ಪಾಲಿಸುವುದು ಹೇಗೆ?
ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಜಗತ್ತಿನಲ್ಲಿ ಹಲವು ಕಾರ್ಯವಿಧಾನ ಮಾದರಿಗಳನ್ನು (ಪ್ರಾಸೆಸ್ ಮಾಡೆಲ್) ಬಳಸಲಾಗುತ್ತದೆ. ಈ ಮಾದರಿಗಳು ತಂತ್ರಾಂಶ ರಚನೆಯ ವಿವಿಧ ಹಂತಗಳನ್ನು ಹಾಗೂ ಅಂತಹ ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಕೈಗೊಳ್ಳಬೇಕಾದ ನಿರ್ದಿಷ್ಟ ಚಟುವಟಿಕೆಗಳನ್ನು ನಮ್ಮ ಮುಂದಿಡುತ್ತವೆ. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ ತಂತ್ರಾಂಶ ರಚನೆ ಪ್ರಕ್ರಿಯೆಯ ಜೀವನ ಚಕ್ರವನ್ನೇ ನಿರ್ದೇಶಿಸುತ್ತವೆ.
ಮೂಲತಃ ಈ ಎಲ್ಲ ಮಾದರಿಗಳಲ್ಲೂ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಜಿನಿಯರಿಂಗ್ ಪರಿಕಲ್ಪನೆಯಲ್ಲಿರುವ ಮೂಲ ಹೆಜ್ಜೆಗಳೇ (ರಿಕ್ವೈರ್‌ಮೆಂಟ್ಸ್ ಅನಾಲಿಸಿಸ್, ಡಿಸೈನ್, ಡೆವೆಲಪ್‌ಮೆಂಟ್, ಟೆಸ್ಟಿಂಗ್ ಇತ್ಯಾದಿ) ಬಳಕೆಯಾಗುತ್ತವೆ. ಆದರೆ ಪ್ರತಿಯೊಂದು ಮಾದರಿಯಲ್ಲೂ ಈ ಹೆಜ್ಜೆಗಳ ಅನುಷ್ಠಾನ ಮಾತ್ರ ಭಿನ್ನವಾಗಿರುತ್ತದೆ.
ಒಂದು ಉದಾಹರಣೆ ನೋಡೋಣ.
ವಾಟರ್‌ಫಾಲ್ ಮಾಡೆಲ್ ಎನ್ನುವುದು ಇಂತಹ ಮಾದರಿಗಳಲ್ಲೊಂದು. ತಂತ್ರಾಂಶ ರಚನೆಯ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಈ ಮಾದರಿ ಐದು ಹೆಜ್ಜೆಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ: ತಂತ್ರಾಂಶದ ಅಗತ್ಯಗಳನ್ನು ಅರಿತುಕೊಳ್ಳುವುದು ಮೊದಲ ಹೆಜ್ಜೆ. ಆ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕಂತೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಯೋಜಿಸಿಕೊಳ್ಳುವುದು, ಎಷ್ಟು ಸಮಯದಲ್ಲಿ ಕೆಲಸ ಮುಗಿಯಬೇಕೆಂದು ಅಂದಾಜಿಸಿಕೊಳ್ಳುವುದು ಎರಡನೆಯ ಹೆಜ್ಜೆಯ ಕೆಲಸ. ಅಗತ್ಯಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಿ ತಂತ್ರಾಂಶದ ವಿನ್ಯಾಸ ಹೇಗಿರಬೇಕು ಎಂದು ತೀರ್ಮಾನಿಸುವುದು ಮೂರನೆಯ ಹೆಜ್ಜೆ. ತಂತ್ರಾಂಶಕ್ಕೆ ಬೇಕಾದ ಕ್ರಮವಿಧಿಗಳನ್ನು ಬರೆದು ಪರೀಕ್ಷಿಸುವುದು ನಾಲ್ಕನೇ ಹೆಜ್ಜೆಯ ಚಟುವಟಿಕೆ. ಕೊನೆಯದಾಗಿ ತಂತ್ರಾಂಶವನ್ನು ಬಳಕೆದಾರನಿಗೆ ಕೊಟ್ಟು ಅದರ ಬಳಕೆಗೆ ಬೇಕಾದ ನೆರವು ನೀಡುವುದು ಕೊನೆಯ ಹೆಜ್ಜೆ.
ಇಲ್ಲಿ ಅನುಸರಿಸಲಾಗುವ ಹೆಜ್ಜೆಗಳು ಒಂದಾದ ನಂತರ ಒಂದರಂತೆ - ಬಹುತೇಕ ಏಕಮುಖವಾಗಿ - ನಡೆಯುವುದರಿಂದ ಅದನ್ನು ನೀರಿನ ಹರಿವಿಗೆ ಹೋಲಿಸಿ ಜಲಪಾತ (ವಾಟರ್‌ಫಾಲ್) ಎಂದು ಕರೆಯುತ್ತಾರೆ. ತಂತ್ರಾಂಶದ ಅಗತ್ಯಗಳು ಮೊದಲಿಗೇ ನಿಖರವಾಗಿ ಗೊತ್ತಾಗಬೇಕು ಎನ್ನುವುದು ಈ ಮಾದರಿಯ ನಿರೀಕ್ಷೆ. ಅಗತ್ಯಗಳನ್ನು ಅಂತಿಮಗೊಳಿಸಿದ ನಂತರವೇ ಮುಂದಿನ ಕೆಲಸವೆಲ್ಲ. ಬಳಕೆದಾರರು ಮೊದಲ ಹೆಜ್ಜೆಯಲ್ಲಿ ಏನು ಕೇಳಿರುತ್ತಾರೋ, ಕೊನೆಯ ಹಂತದಲ್ಲಿ ಅವರಿಗೆ ಸಿಗುವುದು ಅದೇ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕ ತಂತ್ರಾಂಶ.
ಇದರ ಅನುಷ್ಠಾನ ಕಾಗದದ ಮೇಲೆ ಸುಲಭವಾಗಿರುವಂತೆ ಕಂಡರೂ ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ ವಾಟರ್‌ಫಾಲ್ ಮಾದರಿಯ ಅನುಷ್ಠಾನ ಬಹಳ ಕಷ್ಟ. ಇದಕ್ಕೆ ಕಾರಣಗಳು ಹಲವು - ಮೊದಲಿಗೆ ಹೇಳುವುದಾದರೆ ಯಾವ ತಂತ್ರಾಂಶವೇ ಆದರೂ ಅದರ ಅಗತ್ಯಗಳು ಮುಂಚಿತವಾಗಿಯೇ ನಿರ್ಧಾರವಾಗುವ ಸಾಧ್ಯತೆ ಬಹಳ ಕಡಿಮೆ. ಇನ್ನು ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಹೊಸ ವಿಷಯಗಳು ಬೆಳಕಿಗೆ ಬಂದು ತಂತ್ರಾಂಶದ ಅಗತ್ಯ ಅಥವಾ ವಿನ್ಯಾಸದಲ್ಲಿ ಬದಲಾವಣೆ ಬೇಕಾಗುವುದೂ ಉಂಟು. ಹೀಗಿರುವಾಗ ಮೊದಲ ದಿನ ಹೇಳಿದ್ದಷ್ಟನ್ನೇ ಗಟ್ಟಿಯಾಗಿ ಹಿಡಿದಿಟ್ಟುಕೊಂಡು ಎರಡೋ ಮೂರೋ ತಿಂಗಳ ನಂತರ ಆ ಅಗತ್ಯಗಳಿಗೆ ತಕ್ಕ ತಂತ್ರಾಂಶ ಸಿದ್ಧಪಡಿಸಿಕೊಂಡು ಬಳಕೆದಾರನ ಬಳಿ ಹೋದರೆ ಅದು ಸ್ವೀಕೃತವಾಗುವ ಸಾಧ್ಯತೆ ಬಹಳ ಕಡಿಮೆ; ಆಗ ಆತ ಸೂಚಿಸುವ ಬದಲಾವಣೆಗಳನ್ನೆಲ್ಲ ದಾಖಲಿಸಿಕೊಂಡು ಇನ್ನೆರಡು ತಿಂಗಳು ಕೆಲಸಮಾಡಬೇಕಾದ ಪರಿಸ್ಥಿತಿ ಬರುತ್ತದೆ ಅಷ್ಟೆ!
ಇನ್ನು ಕೆಲ ಕಾರ್ಯವಿಧಾನ ಮಾದರಿಗಳು (ಪ್ರಾಸೆಸ್ ಮಾಡೆಲ್) ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ವಾಟರ್‌ಫಾಲ್ ಮಾದರಿಯಲ್ಲಿದ್ದಂತೆ ತಂತ್ರಾಂಶ ರಚನೆಯ ಇಡೀ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಒಂದಾದ ಮೇಲೆ ಒಂದರಂತೆ ಏಕಮುಖವಾಗಿ ನಡೆಯುವ ಹೆಜ್ಜೆಗಳಾಗಿ ವಿಂಗಡಿಸುವ ಬದಲು, ಈ ಹೆಜ್ಜೆಗಳನ್ನು ಕ್ಷಿಪ್ರವಾಗಿ ಪುನರಾವರ್ತಿಸುವುದು ಇಂತಹ ಕೆಲ ಮಾದರಿಗಳ ಉದ್ದೇಶ. ಅಗತ್ಯಗಳನ್ನು ಅರಿತುಕೊಂಡ ತಕ್ಷಣವೇ ತಂತ್ರಾಂಶ ವಿನ್ಯಾಸದ ಯೋಜನೆ ಸಿದ್ಧಪಡಿಸಿಕೊಂಡು ಮೊದಲ ಮಾದರಿಯನ್ನು ಆದಷ್ಟು ಬೇಗ ಬಳಕೆದಾರನಿಗೆ ತಲುಪಿಸಲು ಈ ಮಾದರಿಗಳು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಇಂತಹ ಪ್ರತಿಯೊಂದು ಆವರ್ತನೆಯಲ್ಲೂ ಬಳಕೆದಾರನೊಡನೆ ಸಂಪರ್ಕ ಇಟ್ಟುಕೊಳ್ಳುವುದರಿಂದ ನಮ್ಮ ವಿನ್ಯಾಸದ ಬಗ್ಗೆ ಅವನ ಅನಿಸಿಕೆ ತಿಳಿದುಕೊಳ್ಳುವುದು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಮೂರೋ ನಾಲ್ಕೋ ಬಾರಿ ಈ ಪ್ರಕ್ರಿಯೆ ಪುನರಾವರ್ತನೆಯಾಗುವಷ್ಟರಲ್ಲಿ ಬಳಕೆದಾರನಿಗೆ ನಿಜಕ್ಕೂ ಏನು ಬೇಕು ಎನ್ನುವುದು ತಂತ್ರಾಂಶ ರಚಿಸುವವರಿಗೆ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಅಷ್ಟೇ ಅಲ್ಲ, ಅಂತಿಮವಾಗಿ ಸಿದ್ಧವಾಗುವ ತಂತ್ರಾಂಶ ಬಳಕೆದಾರನಿಗೆ ಇಷ್ಟವೂ ಆಗುತ್ತದೆ!
ಜನವರಿ ೩೧, ೨೦೧೪ರ ಉದಯವಾಣಿಯಲ್ಲಿ ಪ್ರಕಟವಾದ ಲೇಖನ
ಕಾಮೆಂಟ್‌ಗಳಿಲ್ಲ:
ಕಾಮೆಂಟ್‌ ಪೋಸ್ಟ್‌ ಮಾಡಿ