Posted on Aug 6, 2011 in 2011, ale | 0 comments

ಬರವಣಿಗೆಯ ಉದ್ದೇಶ :

ಆಧುನಿಕ ಜೀವನ ಶೈಲಿಯಲ್ಲಿ ನಾವೆಲ್ಲರೂ ಒಂದಲ್ಲಾ ಒಂದು ರೀತಿ ತಂತ್ರಾಂಶದ ಮೇಲೆ ಅವಲಂಭಿಸಿರುತ್ತೇವೆ. ನಮಗೆ ಅರಿವೇ ಇಲ್ಲದೆ ನಮ್ಮ ದಿನ ನಿತ್ಯದ ಕೆಲಸ ಕಾರ್ಯಗಳಲ್ಲಿ ಸಾಫ್ಟ್ ವೇರ್ ನ ಬಳಕೆಯಾಗುತ್ತಿದೆ. ಇದು ಕೇವಲ ಐ.ಟಿ ಉದ್ಯೋಗಸ್ತರು ಮಾತ್ರವಲ್ಲದೆ ಜನಸಾಮಾನ್ಯರು ಸಹ ಬಳಸುತ್ತಿದ್ದಾರೆ. ಹೇಗಂತೀರಾ ??? ಒಮ್ಮೆ ನಮ್ಮ ಸುತ್ತ ಮುತ್ತ ಕಣ್ಣು ಹಾಯಿಸೋಣ! ಶಾಪಿಂಗ್ ಮಾಲ್, ರೆಸ್ಟೋರೆಂಟ್, ಕಚೇರಿ, ಬಸ್-ಟ್ರೈನ್ ಕಾಯ್ದಿರಿಸುವ ಕೌಂಟರ್, ಹೀಗಿಯೇ ಪಟ್ಟಿ ಬೆಳೆಯುತ್ತಾ ಹೋಗುತ್ತದೆ. ಸಾಫ್ಟ್ ವೇರ್ ನ ಬಳಕೆಗೆ ದೇವಸ್ಥಾನಗಳೂ ಹೊರತಲ್ಲ.

ಇಷ್ಟೆಲ್ಲಾ ಪ್ರಚಲಿತವಾಗಿರುವ ಸಾಫ್ಟ್ ವೇರ್ ಹೇಗೆ ತಯಾರಾಗುತ್ತದೆ, ಇದರ ಪ್ರಕ್ರಿಯೆ ಏನು? ಕಂಪನಿಗಳು ಸಾಫ್ಟ್ ವೇರ್ ಗಳನ್ನು ಹೇಗೆ ಅಭಿವೃದ್ಧಿ ಪಡಿಸುತ್ತಾರೆ? ಇವೆಲ್ಲಾ ವಿಷಯಗಳನ್ನು ನಿಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳುವ ಸಲುವಾಗಿ, ಜನ ಸಾಮಾನ್ಯರಿಗೆ ಇದರ ಬಗ್ಗೆ ಕಿರು ಪರಿಚಯ ಹಾಗು ಸ್ನೇಹಿತರೊಂದಿಗೆ ನಮ್ಮ ಆಡುಭಾಷೆಯಲ್ಲಿ ತಂತ್ರಾಂಶ ಬೆಳವಣಿಗೆಯ ಜೀವನ ಚಕ್ರವನ್ನು ಮುಟ್ಟಿಸುವ ಹಂಬಲದಿಂದ ಈ ಲೇಖನವನ್ನು ಬರೆದಿದ್ದೇನೆ .

ಪೀಠಿಕೆ :

“ಸಾಫ್ಟ್ ವೇರ್ ಬೆಳವಣಿಗೆಯ ಪ್ರಕ್ರಿಯೆ” ಸಾಫ್ಟ್ ವೇರ್ ನ ತಯಾರಿಕೆಯಲ್ಲಿ ಬಳಸುವ ವಿಧಿ-ವಿಧಾನಗಳ ಒಂದು ಆಯಕಟ್ಟು. ಸಾಫ್ಟ್ ವೇರ್ ರಚನೆಯಲ್ಲಿ ವಿವಿಧ ಹಂತಗಳಿದ್ದೂ, ಇವೆಲ್ಲವನ್ನು ಉಲ್ಲೇಖಿಸುವ ಕಾರ್ಯವಿಧಾನವೆ ಸಾಫ್ಟ್ ವೇರ್ ಡೆವಲಪ್ಮೆಂಟ್ ಲೈಫ್ ಸೈಕಲ್ (SDLC). SDLC ಯಲ್ಲಿ ಹಲವಾರು ಮಾದರಿ(ಮಾಡಲ್)ಗಳಿದ್ದು, ಅವು ತಮ್ಮದೇ ರೀತಿಯಲ್ಲಿ ಸಾಫ್ಟ್ ವೇರ್ ನ ಉತ್ಪನ್ನ ಪದ್ದತಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಹಾಗೆಯೇ ಸಾಫ್ಟ್ ವೇರ್ ಕಂಪನಿಗಳು ಸಹ ಹೇರಳವಾಗಿರುವುದರಿಂದ, ಯಾವ ಕಂಪನಿ ಯಾವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕೆಂಬ ಸಂಧಿಗ್ಧ ಪರಿಸ್ಥಿತಿ ಉಂಟಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಅಂತರಾಷ್ಟ್ರೀಯ ಮಟ್ಟದಲ್ಲಿ ಎಂತಹ ಕಂಪನಿಗಳು ಯಾವ SDLC ಮಾಡೆಲ್ ಆಯ್ಕೆ ಮಾಡಬೇಕು, ಅದನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತರುವ ವಿಧಾನ ಹಾಗು ಅದರ ಸಂರಕ್ಷಣೆಗಾಗಿ ಐ.ಎಸ್.ಓ ೧೨೨೦೭ ಎಂಬ ಆಯೋಗವನ್ನು ರಚಿಸಿದೆ.

ಸಾಫ್ಟ್ ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ವಿವಿಧ ಹಂತಗಳಿರುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಹಂತ ತಮ್ಮ ಮುಂದಿನ ಹಂತಕ್ಕೆ ಬೇಕಾಗುವ ಅಗತ್ಯಗಳನ್ನು ಸಾದರಪಡಿಸುತ್ತದೆ. ಪ್ರಾಯಶಃ ಎಲ್ಲಾ SDLC ಮಾದರಿಯಲ್ಲಿಯೂ ಕೆಳಗೆ ಸೂಚಿಸಿರುವ ಹಂತಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ . ಆದರೆ ಈ ಹಂತಗಳ ಅನುಕ್ರಮ ಪ್ರತಿ SDLC ಯಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ.

ಮೊದಲಿಗೆ ನಾವು ಸಾಫ್ಟ್ ವೇರ್ ಬೆಳವಣಿಗೆಯಲ್ಲಿ ಸಾಧಾರಣವಾಗಿ ಬರುವ ಚಟುವಟಿಕೆಗಳ ಬಗ್ಗೆ ಒಂದು ಪಕ್ಷಿನೋಟ ಹಾಯಿಸೋಣ.

೧. ಗ್ರಾಹಕರ ಅಗತ್ಯಗಳ ಪರಿಶೀಲನೆ (Requirement Analysis):

ಈ ಹಂತದಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್, ಸ್ಟೇಕ್ ಹೋಲ್ಡರ್ಸ್ ರ ಕೊಡುಗೆ ಬಹಳ ಮುಖ್ಯವಾಗಿರುತ್ತದೆ . ಗ್ರಾಹಕರು(ಕಸ್ಟಮರ್ಸ್) ತಮ್ಮ ಬೇಡಿಕೆಗಳನ್ನು ಕಂಪನಿಯ ಮುಂದಿಡುತ್ತಾರೆ. ತಮಗೆ ಬೇಕಿದ್ದ ಸಾಫ್ಟ್ ವೇರ್ ಪ್ರಾಡೆಕ್ಟ್ ನ ಉಪಯುಕ್ತತೆಯನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತಾರೆ . ಬಹಳಷ್ಟು ಬಾರಿ ಇದು ಸಾರಾಂಶ ರೂಪದಲ್ಲಿರುತ್ತದೆ. ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್ ಮತ್ತು ಸ್ಟೇಕ್ ಹೋಲ್ಡರ್ಸ್, clientsನೊಂದಿಗೆ ಜಾಣ್ಮೆಯಿಂದ ಚರ್ಚಿಸಿ ಅವರ ಅಗತ್ಯಗಳನ್ನು ಅರಿತು ಅವರ ಅಗತ್ಯಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪ್ರಾಡಕ್ಟ್ ನ ಬಳಕೆ, ಯಾರು – ಹೇಗೆ ಇದನ್ನು ಉಪಯೋಗಿಸುತ್ತಾರೆ? ಮಾಹಿತಿ ಶೇಖರಣೆ … ಹೀಗೆ ಹಲವಾರು ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸತಕ್ಕದ್ದು. ಇದನ್ನು Requirement Document ಎಂದು ಕರೆಯುತ್ತಾರೆ.

೨. ಡಿಸೈನ್ (Design):

Requirement Analysis ಹಂತದಲ್ಲಿ ಒಕ್ಕೂಡಿದ ಬೇಡಿಕೆಗಳಿಂದ ಡಿಸೈನ್ ರಚನೆ ಆರಂಭವಾಗುತ್ತದೆ. ಆರ್ಕಿಟೆಕ್ಟ್ ಈ ಹಂತದಲ್ಲಿ ಪ್ರಮುಖವಾದ ಪಾತ್ರ ವಹಿಸುತ್ತಾರೆ. ಪ್ರಾಜೆಕ್ಟ್ ನ ಯಶಸ್ಸಿನ ಬಹುತೇಕ ಪಾಲನ್ನು ಡಿಸೈನ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಡಿಸೈನ್ ತಪ್ಪಾದಲ್ಲಿ ಇಡೀ ಪ್ರಾಡಕ್ಟ್ ಹಾಗು ಅದಕ್ಕೆ ಮೀಸಲಿಟ್ಟ ಶ್ರಮ ವ್ಯರ್ಥವಾಗಿ ಹೊಗುವ ಕಾರಣ ಡಿಸೈನ್ ನನ್ನು ಆದಷ್ಟು ಜಾಗರೂಕತೆಯಿಂದ ರಚಿಸಬೇಕು. ಸಿಸ್ಟಮ್ ನ ಕೃತಿ, ಅದು ಕೆಲಸ ಮಾಡುವ ವಿಧಾನ ವಿವರಣೆಗಳನ್ನು ವರ್ಣಿಸುವ ಹಂತ . ಇದನ್ನು UML ಚಿತ್ರದ ರೂಪದಲ್ಲಿ ಬಿಂಬಿಸುತ್ತಾರೆ . ಇದೇ ಡಿಸೈನ್ ಡಾಕ್ಯುಮೆಂಟ್(Design Document).

೩. ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ (Implementation):

ಡಿಸೈನ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಆಧರಿಸಿ ಕೋಡ್/ಪ್ರೋಗ್ರಾಮ್ ಸೃಷ್ಟಿಸುವ ಕಾರ್ಯ ಆರಂಭವಾಗುತ್ತದೆ. ಇದು SDLCಯಲ್ಲಿ ಅತ್ಯಂತ ದೀರ್ಘವಾದ ಅವಧಿಯಾಗಿರುತ್ತದೆ. ಈ ಹಂತದ ಪ್ರಮುಖವಾದ ಪಾಲುದಾರ ಡೆವೆಲೆಪೆರ್/ಪ್ರೊಗ್ರಾಮರ್. ಉತ್ತಮವಾದ ಕೋಡ್ ನ ರಚನೆ ಕಾರ್ಯನಿರ್ವಹಣೆ ಜವಾಬ್ದಾರಿ ಡೆವೆಲೆಪೆರ್ ದಾಗಿರುತ್ತದೆ. ಮೆಮರಿ, ಕಾರ್ಯಕಲಾಪ ಹೀಗೆ ಮುಂತಾದ ಸೂಕ್ಷ್ಮ ವಿಷಯಗಳನ್ನು ಆದಷ್ಟು ಉತ್ತಮರೀತಿಯಲ್ಲಿ ಬಳಸುವ ಕೋಡ್ ನ ಸೃಷ್ಟಿ ಅತ್ಯಗತ್ಯ.

ಮೊದಲಿಗೆ ಹಲವು ಉಪ ಘಟಕ(modules)ಗಳನ್ನು ತಯಾರಿಸಿ ನಂತರ ಇವೆಲ್ಲವನ್ನು ಸಂಕೀರ್ಣಿಸಿ ಒಂದು ಪರಿಪೂರ್ಣ ಪ್ರಾಡಕ್ಟ್ ಅನ್ನು ಹೊರತರಲಾಗುತ್ತದೆ.

೪. ಪರೀಕ್ಷಣೆ (Testing):

ಈ ಹಿಂದೆ ತಯಾರಾದ ಸಾಫ್ಟ್ ವೇರ್/ಅಪ್ಪ್ಲಿಕೇಷನ್ ಅನ್ನು ಪರೀಕ್ಷೆ(Testing) ಮಾಡಬೇಕಲ್ಲವೇ? Requirement Analysis ಹಂತದಲ್ಲಿ ರೂಪಿಸಿದ Requirement document ಅನ್ನು ಆಧರಿಸಿ ಅದರಲ್ಲಿ ದಾಖಲಾಗಿರುವ ಪ್ರತಿಯೊಂದು ಅಗತ್ಯಗಳು ಕಾರ್ಯರೂಪದಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿವೀಕ್ಷಿಸುತ್ತಾರೆ. ಇದಕ್ಕಾಗಿಯೆ ಟೆಸ್ಟ್ ಡಾಕ್ಯುಮೆಂಟ್(Test document) ರಚನೆಯಾಗುತ್ತದೆ. ಪರೀಕ್ಷಣೆ ಹಂತದಲ್ಲಿ ಪ್ರಮುಖವಾದ ಪಾತ್ರ ಪರೀಕ್ಷಕರದಾಗಿರುತ್ತದೆ.

ಪರೀಕ್ಷಣೆ ಕಾರ್ಯವನ್ನು ೩ ಉಪಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:

೧. Unit testing : ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಹಂತದಲ್ಲಿ ಬಿಡಿ ಬಿಡಿಯಾಗಿ ಸೃಷ್ಟಿಸಿದ ಉಪ ಘಟಕಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ.

೨. System testing : ಎಲ್ಲಾ ಉಪ ಘಟಕಗಳನ್ನು ಒಗ್ಗೂಡಿಸಿದ ನಂತರ ಇವುಗಳ ಪರಸ್ಪರ ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ಗಮನಿಸುತ್ತಾರೆ.

೩. Acceptance testing : ಹೀಗೆ ಸೃಷ್ಟಿಯಾದ ಪ್ರಾಡಕ್ಟ್ ಅನ್ನು ಗ್ರಾಹಕರ ಕ್ಷೇತ್ರದಲ್ಲಿ ಇನ್ಸ್ಟಾಲ್ ಮಾಡಿ ಪರಿಪೂರ್ಣ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಅದರ ಉಪಯುಕ್ತತೆಯನ್ನು ಧೃಡೀಕರಿಸಲಾಗುತ್ತದೆ.

ಇಂತಿಷ್ಟೇ ಸಾಮಾನ್ಯವಾಗಿ ತಂತ್ರಾಂಶ ಬೆಳವಣಿಗೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅಡಕವಾಗಿರುವ ಅಂಶಗಳು.
ಬನ್ನಿ… ಈಗ ಒಂದು ಹೆಜ್ಜೆ ಮುಂದಿಟ್ಟು , ಅತ್ಯಧಿಕವಾಗಿ ಕಂಪನಿಗಳಲ್ಲಿ ಚಾಲ್ತಿಯಲ್ಲಿರುವ SDLC ಮಾದರಿಗಳ ಬಗ್ಗೆ ಒಂದು ಕಿರುನೋಟ ಹಾಯಿಸೋಣ.

೧. Waterfall Model (ಜಲಪಾತದ ಮಾದರಿ) :

ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಹಾಗು ಹೇರಳವಾಗಿ ಚಲಾವಣೆಯಲ್ಲಿರುವ ಮಾಡೆಲ್. ಗ್ರಹಿಸಲು/ಅನುಸರಿಸಲು ಕೂಡ ಬಹಳ ಸರಳವಾಗಿದೆ. ಕೆಳಗೆ ತೋರಿಸಿದ ಚಿತ್ರದಂತೆ ಈ ಮಾಡೆಲ್ ವಿವಿಧ ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಆದರೆ ಇಲ್ಲಿನ ವಿಷೇಶವೆಂದರೆ ಪ್ರತಿ ಹಂತವನ್ನು ಪರಿಸಮಾಪ್ತಿ ಗೊಳಿಸಿದ ಮೇಲೆಯೇ ಮುಂದಿನ ಹಂತವನ್ನು ಕೈಗೊಳ್ಳಬೇಕು.ಈ ಮಾಡೆಲ್ ನ ಮತ್ತೊಂದು ಗುಣವೆಂದರೆ ಪರಿಶೀಲನೆ(review). ಎಲ್ಲಾ ಹಂತದ ಕೊನೆಗೆ ಪರಿಶೀಲನೆಯ ಕ್ರಿಯೆ ಜರಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಪ್ರಾಜೆಕ್ಟ್ ಸ್ಥಿತಿಗತಿ, ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಮುನ್ನಡೆಯುತ್ತಿದೆಯೇ ಎಂಬ ಮಾಹಿತಿ ಸಿಕ್ಕಿಬಿಡುತ್ತದೆ. ಹಾಗಾಗಿ ಪ್ರಾಜೆಕ್ಟ್ ಮುಂದುವರಿಸಲು ಅರ್ಹವಿದೆಯೇ ಅಥವಾ ಅದನ್ನು ಇಲ್ಲೇ ಕೈಬಿಡಬೇಕೆ? ಎಂಬುದನ್ನು ತಕ್ಷಣ ನಿರ್ಧರಿಸಬಹುದು.

ಚಿತ್ರದಲ್ಲಿ ಕಾಣುವಂತೆ ಮಾಡೆಲ್ ಜಲಪಾತವನ್ನು ಹೋಲುವುದರಿಂದ Waterfall Model ಎಂದು ಸೂಕ್ತವಾಗಿ ನಮೀಕರಿಸಿದ್ದಾರೆ.

ಆನುಕೂಲಗಳು:

೧. ಪ್ರತಿ ಹಂತ ಒಂದೊಂದಾಗಿ ಅಸ್ತವ್ಯಸ್ತಥೆ ಇಲ್ಲದೆ ಪೂರ್ಣಗೊಳಿಸಬಹುದು.

೨. ಸರಳವಾಗಿ ನಿರ್ವಹಿಸಬಹುದಾದ ಮಾಡೆಲ್.

೩. ಸಣ್ಣ ಪ್ರಾಜೆಕ್ಟ್ ಗಳಿಗೆ ಇಲ್ಲವೇ ಗ್ರಾಹಕ ಬೇಡಿಕೆ ಪರಿಪೂರ್ಣವಾಗಿ ಗ್ರಹಿಸಿದ್ದಲ್ಲಿ ಈ ಮಾಡೆಲ್ ಅತಿಸೂಕ್ತ.

ಅನಾನುಕೂಲಗಳು:

೧. ಸಾಫ್ಟ್ ವೇರ್ ನ ವಿಸ್ತಾರವನ್ನು ಬೆಳವಣಿಗೆಯ ಹಂತದಲ್ಲಿ ಸಮೀಕರಿಸಲಾಗುವುದಿಲ್ಲ, ಹಾಗೆ ಮಾಡಿದ್ದಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್ ವಿಫಲತೆ ಹೊಂದುತ್ತದೆ.

೨. ಧೀರ್ಘಾವಧಿಯ ಹಾಗು ಕಠಿಣವಾದ ಪ್ರಾಜೆಕ್ಟ್ ಗಳಿಗೆ ಈ ಮಾಡೆಲ್ ಹೊಂದುವುದಿಲ್ಲ.

೩. ಆಗಾಗ್ಗೆ ಬದಲಾಗುವ ಅಗತ್ಯ(requirement)ಗಳಿಗೆ ಅಳವಡಿಸಲಾಗುವುದಿಲ್ಲ.

೨. V-Shape Model (ವಿ ಆಕಾರದ ಮಾಡೆಲ್) :

ವಿ ಆಕಾರದ ಮಾಡೆಲ್, ಜಲಪಾತ ಮಾಡೆಲ್ ನಂತೆ ತನ್ನೊಳಗಿರುವ ಹಂತಗಳನ್ನು ಸರಣಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇಲ್ಲಿಯೂ ಸಹ ಒಂದು ಹಂತದ ಸಮಾಪ್ತಿಯ ನಂತರವೇ ಮುಂದಿನ ಹಂತ ಶುರುವಾಗುತ್ತದೆ. ಹಾಗಾದರೆ ಇದು ಜಲಪಾತ ಮಾಡೆಲ್ ಗಿಂತ ಹೇಗೆ ಭಿನ್ನ? ಇಗೋ ಉತ್ತರ ಇಲ್ಲಿದೆ!

Test plan(ಪರೀಕ್ಷಣೆ ಕಾರ್ಯವಿಧಾನ)ದ ಸೃಷ್ಟಿ ಜಲಪಾತ ಮಾಡೆಲ್ ಗೆ ಹೋಲಿಸಿದ್ದಲ್ಲಿ ಈ ಮಾಡೆಲ್ ನ ಲೈಫ್ ಸೈಕಲ್ ನಲ್ಲಿ ಮುಂಚಿತವಾಗಿಯೇ ರೂಪಿಸಲಾಗುತ್ತದೆ. ಬಹುತೇಕ ಅಗತ್ಯ(requirement) ಶೇಖರಣೆಯ ಹಂತದ ಸಮಯದಲ್ಲೇ test plan ಕಾರ್ಯ ಸಹ ಸಾಗುತ್ತದೆ. ಡೆವೆಲಪ್ಮೆಂಟ್ ಶುರುವಾಗುವ ಮುನ್ನವೇ test plan ರಚಿಸಲಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಪರೀಕ್ಷಣೆಗೆ ಹಚ್ಚು ಒತ್ತಡ ನೀಡುವುದನ್ನ ಗಮನಿಸಬಹುದು.

High level design ಹಂತದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಸ್ಥಾಪತ್ಯ(architechture) ಕೇಂದ್ರಬಿಂದು. ಇದೇ ಸಮಾಂತರದಲ್ಲಿ, ಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಿದಂತೆ ಸಮಷ್ಟಿ ಪರೀಕ್ಷಾ ವಿಧಾನ (integration test plan) ರಚಿಸಲಾಗುತ್ತದೆ. ಪ್ರಾಡೆಕ್ಟ್ ನಲ್ಲಿರುವ ವಿವಿಧ ಉಪ ಘಟಕಗಳು ಸಂಕೀರ್ಣವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದೆಂದು ಅರಿಯಲು ಪ್ಲಾನ್ ಸಿದ್ದಪಡಿಸುತ್ತಾರೆ.

Low level design ಹಂತದಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಸಾಫ್ಟ್ ವೇರ್ ನ ಉಪ ಘಟಕಗಳ ಡಿಸೈನ್ ಬರೆಯಲಾಗುವುದು. ಇದೇ ಅವಧಿಯಲ್ಲಿ ಘಟಕ ಪರೀಕ್ಷೆ(unit test) ಪ್ಲಾನ್ ಅಂದರೆ ಅಡಕವಾಗಿರುವ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಲು ಯೋಜನೆ ಸಿದ್ದವಾಗಿತ್ತದೆ.

ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ನಲ್ಲಿ ಈಗಾಗಲೆ ಗೊತ್ತಿರುವಂತೆ ಕೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ. ಇದು ಮುಗಿದ ನಂತರ ಚಿತ್ರದಲ್ಲಿ ತೋರ್ಪಡಿಸಿದಂತೆ V ಆಕಾರದ ಬಲಭಾಗದಲ್ಲಿ ಸೂಚಿಸಿದ ಹಂತಗಳ ಕಾರ್ಯನಿರ್ವಹಣೆ ಕೆಳಗಿನಿಂದ ಮೇಲ್ಭಾಗದೆಡೆಗೆ ಸಾಗುತ್ತದೆ. ಇದೇ V ಮಾಡೆಲ್ ನ ವಿಶೇಷ!

ಹಿಂದೆ ಹೇಳಿದಂತೆ ಪರೀಕ್ಷಣೆ ಕಾರ್ಯವಿಧಾನ ಮುಂಚಿತವಾಗಿಯೇ ತಯಾರಾದ್ದರಿಂದ ಪರೀಕ್ಷೆಗಳನ್ನು ಮುಂದುವರಿಸಬಹುದು.

ಅನುಕೂಲಗಳು:

೧. ಸುಲಭವಾಗಿ ಅನುಸರಿಸಬಹುದಾದ ಮಾದರಿ.

೨. ಟೆಸ್ಟ್ ಪ್ಲಾನ್ ಮುಂಚಿತವಾಗಿಯೇ ಸಿದ್ದವಿರುವ ಕಾರಣ ಜಲಪಾತ ಮಾಡೆಲ್ ಹೋಲಿಸಿದರೆ ಯಶಸ್ಸಿನ ಸಾಧ್ಯತೆ ಇದರಲ್ಲಿ ಹೆಚ್ಚು.

೩. ಚಿಕ್ಕ ಪ್ರಾಜೆಕ್ಟ್ ಗೆ ಅತಿಸೂಕ್ತ.

ಅನಾನುಕೂಲಗಳು:

೧. ಜಲಪಾತ ಮಾಡೆಲ್ ನಂತೆ ನಿಷ್ಟುರ.

೨. ಪರೀಕ್ಷಿತ ಹಂತದಲ್ಲಿ ಏನಾದರೂ ಬದಲಾಯಿಸ ಬೇಕಾದಲ್ಲಿ ಕ್ಲೇಶನೀಯ.

೩. ಧೀರ್ಘಾವಧಿಯ ಪ್ರಾಜೆಕ್ಟ್ ಗೆ ಹೊಂದುವುದಿಲ್ಲ.

೩. Spiral Model (ಮರುಸುತ್ತಿನ ಮಾಡೆಲ್) :

ಜಲಪಾತ ಮಾಡೆಲ್ ಗೆ ಹೋಲಿಸಿದರೆ ಇದರಲ್ಲಿ ಪಾಲ್ಗೊಳ್ಳುವ ಪ್ರಕ್ರಿಯೆ ತೀರ ಅಭಿಮುಖವಾಗಿದೆ. ಇಲ್ಲಿಯ ವಿಷೇಶವೆಂದರೆ ಪ್ರಾಜೆಕ್ಟ್ ಬೆಳವಣಿಗೆಯಲ್ಲಿ ಒಳಗಾಗಬಹುದಾದಂತಹ ಅಪಾಯದ(risk) ಪರಿಶೀಲನೆಗೆ ಹೆಚ್ಚು ಪ್ರಾಮುಖ್ಯತೆ ನೀಡಲಾಗುತ್ತದೆ. ಸ್ಪೈರಲ್ ಮಾಡೆಲ್ ನಲ್ಲಿ ೪ ಪ್ರಮುಖ ಹಂತಗಳಿದೆ.

೧. ಪ್ಲಾನಿಂಗ್ (planning)

೨. ಅಪಾಯ ಪರಿಶೀಲನೆ (risk analysis)

೩. ಇಂಜಿನಿಯರಿಂಗ್(engineering)

೪. ಎವಲ್ಯೂಷನ್ (evolution)

ಸಾಫ್ಟ್ ವೇರ್ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪುನಃ ಪುನಃ ಈ ನಾಲ್ಕೂ ಹಂತದ ಸುತ್ತುಗಳನ್ನು(ಸ್ಪೈರಲ್) ನಿರ್ವಹಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಇದನ್ನು ಸ್ಪೈರಲ್ ಮಾಡೆಲ್ ಎಂದು ಕರೆಯುತ್ತಾರೆ.

ಪ್ಲಾನಿಂಗ್ ಹಂತದಲ್ಲಿ ಗ್ರಾಹಕರ ಬೇಡಿಕೆಗಳನ್ನು ಶೇಖರಿಸಿಡಲಾಗುತ್ತದೆ. ಅಪಾಯ ಪರಿಶೀಲನೆ ನಲ್ಲಿ ಪ್ರಾಜೆಕ್ಟ್ ನಲ್ಲಿ ಅಳವಡಿಸಿದ ಕಾರ್ಯವಿಧಾನದಲ್ಲಿವುಂಟಾಗುವ ಅಪಾಯಗಳನ್ನು ಗ್ರಹಿಸಿ, ಅದಕ್ಕೆ ಪರಿಹಾರವನ್ನೂ ಆಲೋಚಿಸಲಾಗುತ್ತದೆ. ಹಂತದ ಕೊನೆಯಲ್ಲಿ ಪ್ರಥಮ ಮಾದರಿಯನ್ನು(prototype) ತಯಾರಿಸುತ್ತಾರೆ. ಇಂಜಿನಿಯರಿಂಗ್ ಹಂತದಲ್ಲಿ ಸಾಫ್ಟ್ ವೇರ್ ಅನ್ನು ಸಾದರಪಡಿಸಲಾಗುವುದು. ಅಂತೆಯೇ ಸಾಫ್ಟ್ ವೇರ್ ನ ಪರೀಕ್ಷೆ ಸಹ ಹಂತದ ಕೊನೆಯಲ್ಲಿ ಶುರುವಾಗುತ್ತದೆ.

ಎವಲ್ಯೂಷನ್ ಫೇಸ್ ನಲ್ಲಿ ಗ್ರಾಹಕರು, ಉತ್ಪಾದಿಸಿದ ಪ್ರಾಡೆಕ್ಟ್ ನನ್ನು ಎಲ್ಲಾ ರೀತಿಯಿಂದಲೂ ಪರಿಶೀಲಿಸುತ್ತಾರೆ. ಇವೆಷ್ತು ಸಾಫ್ಟ್ ವೇರ್ ನ ಒಂದು ಫೇಸ್. ಸ್ಪೈರಲ್ ಮಾಡೆಲ್ ನಲ್ಲಿ ಸಾಫ್ಟ್ ವೇರ್ ನನ್ನು ಒಮ್ಮೆಗೆ ಸ್ವಾಧೀನಮಾಡುವುದಿಲ್ಲ. ಬಹು ಭಾಗಗಳಾಗಿ(ಫೇಸ್) ಗ್ರಾಹಕರಿಗೆ ನೀಡುತ್ತಾರೆ. ಒಂದು ಫೇಸ್ ಪೂರ್ಣವಾದ ಮೇಲೆ ಪುನಃ ಸಾಫ್ಟ್ ವೇರ್ ನಲ್ಲಿ ತೋರಿಸಿದಂತೆ ನಲ್ಕೂ ಹಂತಗಳೂ ಕಾರ್ಯಗತವಾಗುತ್ತದೆ.

ಅನುಕೂಲಗಳು:

೧. ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದಲ್ಲಿ ಮುಂದೆ ಉಂಟಾಗುವ ಅಪಾಯಗಳ(ರಿಸ್ಕ್) ಪರಿವೀಕ್ಷಣೆ.

೨. ವ್ಯಾಪಕವಾದ ಹಾಗು ಕಠಿಣವಾದ ಪ್ರಾಜೆಕ್ಟ್ ಗಳಿಗೆ ಹೇಳಿಮಾಡಿಸಿದ ಮಾಡೆಲ್.

೩. waterfall ನಲ್ಲಿ SDLCನ ಎಲ್ಲಾ ಹಂತಗಳು ಪರಿಪೂರ್ಣವಾಗುವವರೆಗು ಸಾಫ್ಟ್ ವೇರ್ ಪ್ರಕಟಿಸುವುದಿಲ್ಲ. ಆದರೆ ಸಾಫ್ಟ್ ವೇರ್ ಸ್ವಾಧೀನವನ್ನು ಫೇಸ್ ರೂಪದಲ್ಲಿ ಕೊಡುವುದರಿಂದ ಕಾಯುವಷ್ಟಿಲ್ಲ.

ಅನಾನುಕೂಲಗಳು:

೧. ಅನುಕರಣೆಗೆ ದುಬಾರಿಯಾದ ಮಾಡೆಲ್.

೨. ರಿಸ್ಕ್ ಅನಾಲಿಸಿಸ್ ಗೆ ವಿಶೇಷ ನಿಪುಣರ ಅಗತ್ಯವಿದೆ.

೩. ಪ್ರಾಜೆಕ್ಟ್ ನ ಯಶಸ್ಸು ರಿಸ್ಕ್ ಅನಾಲಿಸಿಸ್ ಹಂತದ ಆಧಾರದ ಮೇಲಿರುತ್ತದೆ.

೪. ಸಣ್ಣ ಪುಟ್ಟ ಪ್ರಾಜೆಕ್ಟ್ ಗಳಿಗೆ ಅನುಚಿತ.

ಇಂತಿಷ್ಟು SDLC ಕುರಿತು ಸಂಕ್ಷಿಪ್ತ ಲೇಖನ. ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿ ಪ್ರಪಂಚಕ್ಕೆ ಇವು ಒಂದು ಆಡಿಪಾಯ, ಮೊದಲ ಹೆಜ್ಜೆ ಮಾತ್ರ! ಇದರ ವ್ಯಾಪ್ತಿ ಅಪಾರ.

ಎಂ.ಕೆ. ರೇಖಾವಿಜೇಂದ್ರ ಕನ್ನಡ ಪ್ರೇಮಿ ಸ್ನೇಹಿತರಿಗೆ ವಂದನೆಗಳು. ನನ್ನ ಸಂಕ್ಷಿಪ್ತ ಪರಿಚಯ: “ನಮ್ಮ ಬೆಂಗಳೂರಿನ” ನಿವಾಸಿ, ವಿದ್ಯಾಭ್ಯಾಸ-ಬಿ.ಇ. ಕಂಪ್ಯೂಟರ್ ಸೈನ್ಸ್, ಉದ್ಯೋಗ-ಸೀನಿಯರ್ ಸಾಫ್ಟ್ ವೇರ್ ಇಂಜಿನಿಯರ್. ತಾಂತ್ರಿಕ ಕನ್ನಡ ಜಗತ್ತಿಗೆ ಈಗಷ್ಟೇ ಅಂಬೆಗಾಲಿಡುತ್ತಿದ್ದೇನೆ. ಸಂಗೀತ ಹಾಗು ನೃತ್ಯದಲ್ಲಿ ಆಸಕ್ತಿ. ಪ್ರವಾಸವೆಂದರೆ ಅಚ್ಚುಮೆಚ್ಚು. ಇಡೀ ಪ್ರಪಂಚದ ನೈಸರ್ಗಿಕ ಸೌಂದರ್ಯವನ್ನು ನನ್ನ ಕಣ್ಣುಗಳಲ್ಲಿ ತುಂಬಿಕೊಳ್ಳುವ ಹೆಬ್ಬಯಕೆ.