Software Process යනු
Process Model ඒකක් නිර්මාණය කිරීම Process ඒක තුළ ඇති නොගැලපීම්, අනවශ්‍ය දේ ආදිය හදුනා ගැනීමට උපකාරී වේ. මෙවන් ගැටළු හදුනා ගෙන නිවැරදි කර ගන්නා හෙයින් Process ඒක වඩා කාර්යක්ෂම වේ. මෙවැනි Software Process Model කිහිපයක් නම්,
Waterfall Model:-
එකිනෙකට වෙනස් තනි පියවරවලින් සැදුම්ලත් රේඛීය අනුක්‍රමික Model ඒකකි. එනම් එක් පියවරක් අවසාන කිරීමෙන් පසු අනෙක් පියවර ආරම්භ කළ යුතුය. මෙහි ප්‍රධාන පියවර 5කි. ඒවා නම්,
- Software ඒකක් නිපදවන සම්පත්, සීමාවන් (Constraints) හා ක්‍රියාකාරකම් අඩංගු වන, කිසියම් අනුපිළිවෙළකට අනුව සකස් කරන ලද කාර්යයන්(Tasks) වල එකතුවකි.
- එය Process ඒක සෑදී තිබෙන ක්‍රියාකාරකම් පරීක්ෂා කිරීමට, අවබෝධ කර ගැනීමට, පාලනය කිරීමට හා වර්ධනය කර ගැනීමට ඉඩ ලබා දෙමින් අපගේ ක්‍රියාවන්ට මග පෙන්වයි.
- Software 1ක සියළුම අවධීන් අඩංගු වන හෙයින් සමහර අවස්ථාවලදී මෙම Process ඒකක් සදහාLifecycle යන නම යෙදේ.
Process Model ඒකක් නිර්මාණය කිරීම Process ඒක තුළ ඇති නොගැලපීම්, අනවශ්‍ය දේ ආදිය හදුනා ගැනීමට උපකාරී වේ. මෙවන් ගැටළු හදුනා ගෙන නිවැරදි කර ගන්නා හෙයින් Process ඒක වඩා කාර්යක්ෂම වේ. මෙවැනි Software Process Model කිහිපයක් නම්,
- Waterfall Model
- Prototyping Models
- Evolutionary Models
- The Spiral Model
- Formal Development
- Incremental Development
- Rapid Application Development
- Unified Process
- Agile Process
- Extreme Programming (XP)
නිපදවන Software එකේ ස්වභාවය අනුව ඒ සදහා ඒ ඒModel සුදුසු විය හැක.
මෙහි Waterfall Model හා Prototyping Models විස්තර වශයෙන් විමසා බලමු.
මෙහි Waterfall Model හා Prototyping Models විස්තර වශයෙන් විමසා බලමු.
Waterfall Model:-
එකිනෙකට වෙනස් තනි පියවරවලින් සැදුම්ලත් රේඛීය අනුක්‍රමික Model ඒකකි. එනම් එක් පියවරක් අවසාන කිරීමෙන් පසු අනෙක් පියවර ආරම්භ කළ යුතුය. මෙහි ප්‍රධාන පියවර 5කි. ඒවා නම්,
- Requirement Analysis & Specification
- Software Design
- Coding
- Testing
- Maintenance
1. Requirement Analysis & Specification:-
ගනුදෙනුකරුගෙන් තොරතුරු විමසීම හරහාSoftware ඒකකින් සිදු විය යුතු සේවාවන්, එහි සීමාවන් (Constraints) හා එහි අරමුණු සනාථ කර ගනු ලැබේ. මෙහිදී Software එකෙහි Domain ඒක හා Functionality, Behavior, Performance, Interface, Security ආදි වූ සියළුම අවශ්‍යතාවන් (Requirements) අවබෝධ කර ගැනීම සිදු විය හැක. පසුව මෙම අවශ්‍යතා, ගනුදෙනුකරුවන් (Users) හා Development Staff යන දෙපක්ෂයටම අවබෝධ කර ගත හැකි ආකාරයකට ඉදිරිපත් කෙරේ.
2. Software Design:-
Design ක්‍රියාවලිය මගින් පෙර පියවරේදී හදුනා ගත් Requirements, Software Tools උපයෝගී කර ගනිමින් ක්‍රියාවට නැංවිය හැකි Software ඒකක නිරූපණයක් බවට පරිවර්තනය කරයි. Design ක්‍රියාවලියේ ප්‍රධානම අභිප්‍රායන් වනුයේ Software Components (කොටස්), Software Architecture, Interfaces, Data Structures හා Algorithms හදුනා ගැනීමයි.
3. Coding (Implementation) :-
පෙර පියවරේදී හදුනා ගත් Design ඒක පරිගණකයට කියවා ගත හැකි (Machine Readable) ආකාරයකට පරිවර්තනය කළ යුතුය. මෙම පියවරේදී Software Design ඒක, Program හෝ Program Unit කාණ්ඩයක් ලෙස ලබා ගැනේ.Software Develop කිරීම සදහා Programming Languages හෝ CASE Tools භාවිතා කළ හැක.Software ඒක සත්‍ය වශයෙන්මImplement කෙරෙන අවධිය මෙයයි.
4. Testing:-
Testing ක්‍රියාවලිය මගින්Software ඒක නිවැරදිව වැඩ කරන බවත් පෙර හදුනා ගත් Requirements සියල්ල තෘප්ත කරන බවත් සහතික කළ යුතුය. පරීක්ෂා කිරීමෙන් (Testing) පසු Software ඒක ගනුදෙනුකාර පාර්ශවය වෙත නිකුත් කෙරේ.
5. Maintenance:-
Software ඒක ගනුදෙනුකාර පාර්ශවය වෙත නිකුත් කිරීමෙන් අනතුරුවද නිශ්චිතවම වෙනස්කම්වලට භාජනය වේ. එහි පවතින දුබලතා නිවැරදි කොට නව අවශ්‍යතාවලට (Requirements) ගැලපෙන පරිදි නවීකරණය කළ යුතුය.
ගනුදෙනුකරුගෙන් තොරතුරු විමසීම හරහාSoftware ඒකකින් සිදු විය යුතු සේවාවන්, එහි සීමාවන් (Constraints) හා එහි අරමුණු සනාථ කර ගනු ලැබේ. මෙහිදී Software එකෙහි Domain ඒක හා Functionality, Behavior, Performance, Interface, Security ආදි වූ සියළුම අවශ්‍යතාවන් (Requirements) අවබෝධ කර ගැනීම සිදු විය හැක. පසුව මෙම අවශ්‍යතා, ගනුදෙනුකරුවන් (Users) හා Development Staff යන දෙපක්ෂයටම අවබෝධ කර ගත හැකි ආකාරයකට ඉදිරිපත් කෙරේ.
2. Software Design:-
Design ක්‍රියාවලිය මගින් පෙර පියවරේදී හදුනා ගත් Requirements, Software Tools උපයෝගී කර ගනිමින් ක්‍රියාවට නැංවිය හැකි Software ඒකක නිරූපණයක් බවට පරිවර්තනය කරයි. Design ක්‍රියාවලියේ ප්‍රධානම අභිප්‍රායන් වනුයේ Software Components (කොටස්), Software Architecture, Interfaces, Data Structures හා Algorithms හදුනා ගැනීමයි.
3. Coding (Implementation) :-
පෙර පියවරේදී හදුනා ගත් Design ඒක පරිගණකයට කියවා ගත හැකි (Machine Readable) ආකාරයකට පරිවර්තනය කළ යුතුය. මෙම පියවරේදී Software Design ඒක, Program හෝ Program Unit කාණ්ඩයක් ලෙස ලබා ගැනේ.Software Develop කිරීම සදහා Programming Languages හෝ CASE Tools භාවිතා කළ හැක.Software ඒක සත්‍ය වශයෙන්මImplement කෙරෙන අවධිය මෙයයි.
4. Testing:-
Testing ක්‍රියාවලිය මගින්Software ඒක නිවැරදිව වැඩ කරන බවත් පෙර හදුනා ගත් Requirements සියල්ල තෘප්ත කරන බවත් සහතික කළ යුතුය. පරීක්ෂා කිරීමෙන් (Testing) පසු Software ඒක ගනුදෙනුකාර පාර්ශවය වෙත නිකුත් කෙරේ.
5. Maintenance:-
Software ඒක ගනුදෙනුකාර පාර්ශවය වෙත නිකුත් කිරීමෙන් අනතුරුවද නිශ්චිතවම වෙනස්කම්වලට භාජනය වේ. එහි පවතින දුබලතා නිවැරදි කොට නව අවශ්‍යතාවලට (Requirements) ගැලපෙන පරිදි නවීකරණය කළ යුතුය.
මෙම Model ඒක භාවිතා කිරීමට නම්අවශ්‍යතාවන් (Requirements) සියල්ල පැහැදිලි විය යුතුය. එක් පියවරක් නිම කිරීමෙන් පසු නැවත වෙනස්කම් සිදු කළ නොහැක. උදාහරණයක් ලෙසDesign ඒක නිම කිරීමෙන් පසුDesign ඒක නැවත වෙනස් කළ නොහැක. මේ නිසා Software Development Process ඒක අතරතුරදී Requirements වෙනස් වන්නේ නම් මෙමModel ඒක සුදුසු නැත.
එනම් Waterfall Model ඒක වඩාත්ම සුදුසු වනුයේ Requirements පැහැදිලි හා ස්ථාවර අවස්ථා වලදීය.
Waterfall Model සම්බන්ධ ගැටළු:-
- සත්‍ය වශයෙන්ම මෘදුකාංග ව්‍යාපෘති මෙවැනි අනුක්‍රමික ප්‍රවාහයක් අනුගමනය කරන්නේ ඉතාම සුළු වශයෙන් වීම.
- බොහෝ අවස්ථාවලදී සියළුRequirements පැහැදිලිව, සවිස්තරව ඉදිරිපත් කිරීමට ගනුදෙනුකරුවන් අපොහොසත් වීම.
- ගනුදෙනුකරුවන් ඉවසීමෙන් බලා සිටිය යුතුය. ක්‍රියාත්මක කළ හැකි Software ඒකක් ලැබෙන්නේ අවසාන පියවරයන් හිදීය.
Enhanced Version of Waterfall Model
Prototyping Models :-
ගනුදෙනුකරුවන් හට නව මෘදුකාංග පද්ධතිය තමන්ගේ වැඩ කටයුතු සදහා යොදා ගන්නා ආකාරය කලින්ම සිතීමට අපහසුය. විශේෂයෙන්ම ඉතා විශාල හා සංකීර්ණ පද්ධතියක් නම් එය නිපදවා භාවිතයට ගන්නා තෙක්ම අපහසු විය හැක.
මේ නිසා මෙම අපැහැදිලි Requirements පැහැදිලිව හදුනා ගැනීමටPrototype ඒකක් (මෘදුකාංගයේ මූලික අවස්ථාවක්) යොදා ගත හැක. මේ සදහා ගනුදෙනුකරුගේ සහභාගීත්වයද ඇතිව මෙමPrototype ඒක විනිශ්චය කළ යුතුය.
Prototyping හි ප්‍රධාන ශිල්ප ක්‍රම 2කි. ඒවා නම්,
ගනුදෙනුකරුවන් හට නව මෘදුකාංග පද්ධතිය තමන්ගේ වැඩ කටයුතු සදහා යොදා ගන්නා ආකාරය කලින්ම සිතීමට අපහසුය. විශේෂයෙන්ම ඉතා විශාල හා සංකීර්ණ පද්ධතියක් නම් එය නිපදවා භාවිතයට ගන්නා තෙක්ම අපහසු විය හැක.
මේ නිසා මෙම අපැහැදිලි Requirements පැහැදිලිව හදුනා ගැනීමටPrototype ඒකක් (මෘදුකාංගයේ මූලික අවස්ථාවක්) යොදා ගත හැක. මේ සදහා ගනුදෙනුකරුගේ සහභාගීත්වයද ඇතිව මෙමPrototype ඒක විනිශ්චය කළ යුතුය.
Prototyping හි ප්‍රධාන ශිල්ප ක්‍රම 2කි. ඒවා නම්,
- Throw-away Prototyping
- Evolutionary Prototyping
1. Throw-away Prototyping:-
මෙහි ප්‍රධාන පරමාර්ථය වනුයේ Requirements පැහැදිලිව අවබෝධ කර ගැනීමයි. මෙහිදී ව්‍යාපෘතිය ආරම්භ කෙරෙනුයේ දුබල ලෙස හදුනා ගත් Requirements වලිනි. නමුත් Requirements පැහැදිලි කර ගත් වහාම Prototype 1 ඉවත් කර System 1 මුල සිටම Develop කෙරේ. නමුත් Prototype ඒක සම්පූර්ණයෙන් ඉවත් කළ යුතු නැත. එහි අවසන් System ඒක සදහා භාවිතා කළ හැකි කොටස් වේ නම් ඒවා භාවිතා කළ හැක.
මෙහි ප්‍රධාන පරමාර්ථය වනුයේ Requirements පැහැදිලිව අවබෝධ කර ගැනීමයි. මෙහිදී ව්‍යාපෘතිය ආරම්භ කෙරෙනුයේ දුබල ලෙස හදුනා ගත් Requirements වලිනි. නමුත් Requirements පැහැදිලි කර ගත් වහාම Prototype 1 ඉවත් කර System 1 මුල සිටම Develop කෙරේ. නමුත් Prototype ඒක සම්පූර්ණයෙන් ඉවත් කළ යුතු නැත. එහි අවසන් System ඒක සදහා භාවිතා කළ හැකි කොටස් වේ නම් ඒවා භාවිතා කළ හැක.
මෙහිදීRequirements හදුනා ගත් පසු අප කටයුතු කරන්නේ Waterfall Model ඒක ආකාරයටය.Prototype ඒක ද ඉවත් කරයි. ඒ නිසාRequirements පසුව වෙනස්කම්වලට භාජනය විය නොහැක.
එනම්Throw-away Prototyping Model ඒක වඩාත් සුදුසු වන්නේRequirements අපැහැදිලි නමුත් ස්ථාවර අවස්ථාවලදීය.
Throw-away Prototyping සම්බන්ධ ගැටළු:-
ක්ෂණිකව Implement කිරීමේදී ඉතා වැදගත් ලක්ෂණPrototype ඒකෙන් මග හැරී යා හැක. කෙසේ වුවත්System එකෙහි සුරක්ෂිත බව වැනි වැදගත් කොටස්Prototype ඒකකට නැංවීම අපහසු විය හැක.
මෙහිදී Implement කිරීමක් සිදු වුවද ඒ සදහා ගනුදෙනුකරු හා Developer අතර නීතිමය වලංගු භාවයක් නොමැත. Implement කිරීමෙන් පසු ගනුදෙනුකරුPrototype ඒක ප්‍රතික්ෂේප කිරීමේ අවදානමක් ඇත.
Prototype Implementation ඒකකදී Reliability, Robustness වැනි ගුණාංග ප්‍රමාණවත් ලෙස පරීක්ෂාවට ලක් කළ නොහැක.
2. Evolutionary Prototyping:-
මෙහි දී ද පෙර පරිදීම Prototype ඒකක් භාවිතයෙන් Requirements පැහැදිලි කර ගනු ලැබේ. ඉන්පසුPrototype ඒකඉවත් නොකරRequirements තෘප්ත වන තෙක් එයම වැඩි දියුණු කරයි. මෙහිදීRequirements වල වෙනස් වීම් වලට ඉඩ දිය හැක. වෙනස් වනRequirements වලට අනුවPrototype ඒක ද වැඩි දියුණු කළ යුතුය.System ඒකසතුටුදායක මට්ටමකට පැමිණි විට ගනුදෙනුකරු වෙත නිකුත් කළ හැක.
මෙහි දී ද පෙර පරිදීම Prototype ඒකක් භාවිතයෙන් Requirements පැහැදිලි කර ගනු ලැබේ. ඉන්පසුPrototype ඒකඉවත් නොකරRequirements තෘප්ත වන තෙක් එයම වැඩි දියුණු කරයි. මෙහිදීRequirements වල වෙනස් වීම් වලට ඉඩ දිය හැක. වෙනස් වනRequirements වලට අනුවPrototype ඒක ද වැඩි දියුණු කළ යුතුය.System ඒකසතුටුදායක මට්ටමකට පැමිණි විට ගනුදෙනුකරු වෙත නිකුත් කළ හැක.
Evolutionary PrototypingModel ඒක වඩාත් සුදුසු වන්නේRequirements අපැහැදිලි හා අස්ථාවර අවස්ථාවලදීය.
Evolutionary Prototyping හි වාසි :-
- Prototype ඒක සදහා දැරූ උත්සාහය අපතේ නොයාම.
- Waterfall Model ඒකට වඩා වේගවත් වීම.
- ආරම්භයේ සිටම ගනුදෙනුකරුගේ සහභාගීත්වය ඉහළ මට්ටමක පැවතීම.
- තාක්ෂණික හෝ වෙනත් ගැටළු ඉක්මනින් හදුනා ගන්නා හෙයින් අවදානම අඩු වේ.
- Prototype ඒක ඉක්මනින් සකස් කෙරෙන නිසා එතරම් හොද Documentation ඒකක් සිදු නොවේ.
- දිගින් දිගටම කෙරෙන වෙනස්කම් නිසා Prototype ඒකෙහි ව්‍යුහයට හානි විය හැක. එමගින් නඩත්තු කිරීම අපහසු හා අධික වියදම් සහිත විය හැක.
- Prototype ඒක සදහා භාවිතා කරන Language ඒක සෑම විටම අවසන්System ඒක සදහා සුදුසු නොවිය හැක.
- කෙටි කලකින් නිම කළ යුතු ව්‍යාපෘති සදහාRapid Application Development සුදුසු වේ.
- ඉහළ නිරවද්‍යතාවයක් අවශ්‍ය වන ව්‍යාපෘති සදහා Formal Development සුදුසුය.
- අවදානම ඉහළ ව්‍යාපෘති සදහාSpiral Model සුදුසුය.