‫اﻟﻤﻮﺳﻮﻋﺔ اﻟﻌﺮﺑﯿﺔ ﻟﻠﻜﻤﺒﯿﻮﺗﺮ‪ /‬ﻗﺴﻢ اﻟﺪورات اﻟﺘﻌﻠﯿﻤﯿﺔ‬

‫ﺳﻠﺴﻠﺔ ﻛﺘﺐ اﻟﺪورات اﻟﺘﻌﻠﯿﻤﯿﺔ اﻹﻟﻜﺘﺮوﻧﯿﺔ‬

‫‪C4arab.com‬‬

‫ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت‬
‫‪Software Engineering‬‬

‫ﻓﻲ ﺳﺘﺔ أﻳﺎم‪......‬‬

‫ﺗﺄﻟـــــﯿﻒ‬
‫أﺳﻤﺎء اﻟﻤﻨﻘﻮش‬
‫ﻣﺸﺮﻓﺔ ﺳﺎﺣﺔ ﻟﻐﺎت اﻟﺒﺮﻣﺠﺔ‬

‫ﯾﺴﻤﺢ ﺑﺘﻮزﯾﻊ اﻟﻜﺘﺎب ﻋﻠﻰ ﺻﻮرﺗﻪ اﻹﻟﻜﺘﺮوﻧﯿﺔ ﻟﻜﻦ ﻻ ﯾﺴﻤﺢ ﺑﻄﺒﻊ اﻟﻜﺘﺎب أو ﺗﻐﯿﯿﺮ ﻫﯿﺌﺘﻪ‬
‫إﻻ ﺑﻌﺪ أﺧﺬا إذن ﻣﻦ اﻟﻜﺎﺗﺐ‬
‫اﻟﻤﻮﺳﻮﻋﺔ اﻟﻌﺮﺑﯿﺔ ﻟﻠﻜﻤﺒﯿﻮﺗﺮ واﻹﻧﺘﺮﻧﺖ©‪2000-2005‬ﺟﻤﯿﻊ اﻟﺤﻘﻮق ﻣﺤﻔﻮﻇﺔ ‪-‬‬
 ‫اﻟﺘﻮاﺻﻞ ﻣﻊ اﻟﻘﺮاء‬

‫إﻟﻰ اﻟﻘﺎرئ اﻟﻌﺰﯾﺰ ‪،،،‬‬

‫ﺣﺮﺻﺖ اﻟﻤﻮﺳﻮﻋﺔ اﻟﻌﺮﺑﯿﺔ ﻟﻠﻜﻤﺒﯿﻮﺗﺮ واﻹﻧﺘﺮﻧﺖ _ وﻣﻦ ﻣﻨﻄﻠﻖ اﻫﺘﻤﺎﻣﻬﺎ اﻟﻌﺎم ﺑﻌﻠﻮم اﻟﺤﺎﺳﺐ واﻟﺘﻘﻨﯿﺔ‬
‫واﻫﺘﻤﺎﻣﻬﺎ اﻟﺨﺎص ﺑﺘﻘﺪﯾﻢ ﻫﺬه اﻟﻌﻠﻮم ﺑﺎﻟﻠﻐﺔ اﻟﻌﺮﺑﯿﺔ _ ﻋﻠﻰ ﺗﻘﺪﯾﻢ ﻫﺬه اﻟﺴﻠﺴﺔ ﻣﻦ‬
‫اﻟﻜﺘﺐ اﻹﻟﻜﺘﺮوﻧﯿﺔ اﻟﺘﻰ ﻧﺘﻤﻨﻰ أن ﺗﺤﻘﻖ ﻃﻤﻮﺣﺎت اﻟﻘﺎرئ اﻟﻌﺮﺑﻰ اﻟﺬى اﻋﺘﺎد ﻋﻠﻰ ﻗﺮاءة أﺟﻮد‬
‫اﻟﻤﻄﺒﻮﻋﺎت ﺑﻜﺎﻓﺔ اﻟﻠﻐﺎت اﻟﻌﺎﻟﻤﯿﺔ ‪.‬‬

‫إن اﻟﻤﻮﺳﻮﻋﺔ اﻟﻌﺮﺑﯿﺔ _ﻣﻦ ﺧﻼل ﻫﺬه اﻟﺴﻠﺴﻠﺔ _ ﺗﻄﻤﺢ ﻟﺘﻘﺪﯾﻢ ﺳﻠﺴﻠﺔ ﻣﻦ اﻟﻜﺘﺐ ﺑﻤﺴﺘﻮى ﻋﺎلٍ ﻣﻦ‬
‫اﻟﺠﻮدة ‪ ،‬اﻟﺸﻲء اﻟﺬى ﻟﻦ ﯾﺘﺤﻘﻖ ﺑﺪون ﻣﻼﺣﻈﺎﺗﻜﻢ واﻗﺘﺮاﺣﺎﺗﻜﻢ ﺣﻮل اﻟﺴﻠﺴﻠﺔ _ ﻃﺮﯾﻘﺔ اﻟﻜﺘﺎﺑﺔ ‪،‬‬
‫اﻷﺧﻄﺎء اﻹﻣﻼﺋﯿﺔ واﻟﻨﺤﻮﯾﺔ ‪ ،‬اﻟﺘﻨﻈﯿﻢ واﻟﺘﺮﺗﯿﺐ ‪ ،‬ﻃﺮﯾﻘﺔ ﻧﺸﺮ اﻟﻜﺘﺎب وﺗﻮزﯾﻌﻪ ‪ ،‬اﻹﺧﺮاج اﻟﻔﻨﻰ ‪...‬‬
‫اﻟﺦ‬

‫ﻧﻨﺘﻈﺮ ﺳﻤﺎع أراءﻛﻢ ﻋﻠﻰ اﻟﺒﺮﯾﺪ اﻹﻟﻜﺘﺮوﻧﻲ اﻟﻤﺨﺼﺺ ﻟﺬﻟﻚ‬

‫‪ebooks@c4arab.com‬‬
‫ﻧﺮﺟﻮ ذﻛﺮ اﺳﻢ اﻟﻜﺘﺎب واﻟﻜﺎﺗﺐ واﻟﻄﺒﻌﺔ ﻣﻊ ذﻛﺮ ﻣﻼﺣﻈﺎﺗﻜﻢ ﻟﻨﺎ‬

‫ﺗـــــــــــﻬﺎﻧﻰ اﻟﺴـــــــــــــــــﺒﯿﺖ‬
‫ﻣﺸﺮﻓﺔ اﻟﻤﻮﺳﻮﻋﺔ اﻟﻌﺮﺑﯿﺔ ﻟﻠﻜﻤﺒﯿﻮﺗﺮ واﻹﻧﺘﺮﻧﺖ‬

‫‪1‬‬
 ‫‪ ..‬ﺑﺴــــﻢ اﷲ اﻟﺮﺣﻤــــﻦ اﻟﺮﺣﯿـــــﻢ ‪..‬‬
‫اﻟﺪورات اﻟﺘﻌﻠﯿﻤﯿﺔ ‪ ..‬ھﻲ ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻟﺪورات‬
‫اﻟﺘﻲ ﺗﻘﺪﻣﮫﺎ ﻟﻜﻢ اﻟﻤﻮﺳﻮﻋﺔ اﻟﻌﺮﺑﯿﺔ؛ ﺑﺪأﻧﺎ ﺑﺘﻘﺪﻳﻤﮫﺎ‬
‫ﻓﻲ اﻟﺼﯿﻒ ﺗﺤﺖ ﻣﺴﻤﻰ " اﻟﺪورات اﻟﺼﯿﻔﯿﺔ " وھﺎ‬
‫ھﻲ ﺗﻌﻮد ﻣﻦ ﺟﺪﻳﺪ ‪ .‬ﺣﺮﺻﻨﺎ ﻋﻠﻰ ﺗﻘﺪﻳﻢ دورات ﻓﻲ‬
‫ﻣﺠﺎﻻت ﻣﺨﺘﻠﻔﺔ ﻟﻨﺮاﻋﻲ أﻏﻠﺐ اﻻھﺘﻤﺎﻣﺎت ﻛﻤﺎ‬
‫ﺣﺮﺻﻨﺎ ﻋﻠﻰ اﻧﺘﻘﺎء اﻟﺪورات اﻟﻤﻔﯿﺪة‪ ،‬ﻏﯿﺮ اﻟﻤﺘﻜﺮرة‪،‬‬
‫ﺑﻄﺮﻳﻘﺔ ﺟﺎدة ﺗﻨﻘﻠﻚ إﻟﻰ اﻟﺠﻮ اﻟﺪراﺳﻲ ﻓﻲ ﻗﺎﻋﺎت‬
‫اﻟﺠﺎﻣﻌﺔ و ﺻﻔﻮف اﻟﻤﻌﺎھﺪ و ﻟﻜﻦ ﻓﻲ ﺑﯿﺌﺔ‬
‫إﻟﻜﺘﺮوﻧﯿﺔ! ﻛﻞ ھـﺬا ﻣﺠــﺎﻧـــﺎ! ‪...‬‬
‫ﻳﻮﺟﺪ ﻛﺬﻟﻚ ﺳﺎﺣﺔ ﻣﺘﺨﺼﺼﺔ ﻟﮫﺎ ﺿﻤﻦ ﻣﺠﻤﻮﻋﺔ‬
‫ﺳﺎﺣﺎت اﻟﻤﻮﺳﻮﻋﺔ اﻟﻌﺮﺑﯿﺔ ﻟﻠﻨﻘﺎش واﻷﺳﺌﻠﺔ‪،‬‬
‫ﺗﺠﺪھﺎ ھﻨـــﺎ! ‪...‬‬
‫اﺳﺘﻔﺪ واﺳﺘﺜﻤﺮ وﻗﺘﻚ ﻣﻌﻨﺎ! إذا ﻛﻨﺖ ﺗﺮﻏﺐ ﻓﻲ‬
‫ﺗﻄﻮﻳﺮ ذاﺗﻚ و ﺗﻮﺳﯿﻊ ﻧﻄﺎق ﺛﻘﺎﻓﺘﻚ ﻓﻲ اﻟﺤﺎﺳﻮب‬
‫ﻓﺎﺳﺘﻐﻞ ﻛﻞ دﻗﯿﻘﺔ واﺳﺘﻔﺪ ﻣﻌﻨﺎ! و ﻻ ﺗﻨﺴﻰ أﻧﻨﺎ‬
‫ﻓﻲ ﻋﺼﺮ اﻟﻤﻌﻠﻮﻣﺎت واﻟﺴﺮﻋﺔ‪.‬‬

‫اﺑﺪأ اﻵن !اﻧﺘﻘﻞ ﻟﺼﻔﺤﺔ اﻟﺪورات و اﺧﺘﺮ اﻟﺪورة اﻟﺘﻲ ﺗﻨﺎﺳﺒﻚ‪ ،‬اﻧﺘﻘﻞ ﻟﺼﻔﺤﺔ اﻷﺳﺎﺗﺬة ﻟﻼﻃﻼع ﻋﻠﻰ‬
‫ﻗﺎﺋﻤﺔ اﻷﺳﺎﺗﺬة اﻟّﺬﻳﻦ ﺳﯿﻠﻘﻮن اﻟﻤﺤﺎﺿﺮات ‪،‬اﻧﺘﻘﻞ ﻟﺼﻔﺤﺔ اﻟﺘﺴﺠﯿﻞ ﻛﻲ ﺗﺴﺠّﻞ ﻧﻔﺴﻚ ﻓﻲ إﺣﺪى‬
‫اﻟﺪورات‪ ،‬ﻟﻦ ﺗﺴﺘﻄﯿﻊ اﻟﻤﺸﺎرﻛﺔ ﻓﻲ أي دورة ﻗﺒﻞ أن ﺗﺴﺠﻞ‪ .‬اﻧﺘﻘﻞ ﻟﺼﻔﺤﺔ اﻟﻤﺮاﺟﻊ ﻛﻲ ﺗﻄﻠﻊ ﻋﻠﻰ‬
‫اﻟﻤﺮاﺟﻊ اﻟﻤﻘﺪﻣﺔ ﻣﻦ اﻷﺳﺎﺗﺬة ﺑﺨﺼﻮص اﻟﺪورات اﻟﺤﺎﻟﯿﺔ ‪.‬اﻧﺘﻘﻞ ﻟﺼﻔﺤﺔ اﻟﻤﻠﺘﺤﻘﯿﻦ ﻟﺘﻄﻠﻊ ﻋﻠﻰ ﺑﻌﺾ‬
‫اﻟﻤﻌﻠﻮﻣﺎت ﻋﻦ اﻟﻤﻠﺘﺤﻘﯿﻦ ﻓﻲ اﻟﺪورات‪ .‬اﻧﺘﻘﻞ ﻟﺼﻔﺤﺔ اﺗﺼﻞ ﺑﻨﺎ ﻛﻲ ﺗﺮﺳﻞ ﻟﻨﺎ اﻗﺘﺮاﺣﺎً أو ﻃﻠﺒﺎً‪ .‬ﻧﺤﻦ‬
‫ﺑﺎﻧﺘﻈﺎرك! ﻟﻜﻦ اﻟﻮﻗﺖ ﻣﺤﺪود و ﻋﺪد اﻟﻤﻠﺘﺤﻘﯿﻦ ﻓﻲ ﻛﻞ دورة ﻣﺤﺪود ﻟﺬا ﻻ ﺗﺘﺄﺧﺮ ﻓﻲ اﻟﺘﺴﺠﯿﻞ ﻣﻦ‬
‫ﻓﻀﻠﻚ‪.‬‬

‫‪2‬‬
 ‫ﻫﺬا اﻟﻜﺘﺎب ‪....‬‬
‫ﻟﯿﺲ ﻓﻰ اﻷﺻﻞ أﻻ دورة ﺗﻢ ﺗﺪرﯾﺴﻬﺎ ﻓﻰ ﺳﺎﺣﺔ اﻟﺪورات اﻟﺘﻌﻠﯿﻤﯿﺔ ﺑﺎﻟﻤﻮﺳﻮﻋﺔ‬
‫اﻟﻌﺮﺑﯿﺔ ﻟﻠﻜﻤﺒﯿﻮﺗﺮ واﻹﻧﺘﺮﻧﺖ ‪ ،‬وﺗﻢ ﺟﻤﻊ ﺗﻠﻚ اﻟﺪروس وﺳﻠﺴﻠﺔ اﻟﻨﻘﺎش اﻟﺘﻰ‬
‫دارت ﺣﻮﻟﻬﺎ ﻫﻨﺎ ﻓﻰ ﻫﺬا اﻟﻜﺘﺎب ‪ ،‬وﺗﻢ وﺿﻊ اﻟﻨﻘﺎﺷﺎت ﻋﻠﻰ ﻫﯿﺌﺔ أﺳﺌﻠﺔ‬
‫وأﺟﻮﺑﺔ ﻟﻜﻰ ﯾﺴﺘﻔﯿﺪ اﻟﺠﻤﯿﻊ ﻣﻨﻬﺎ ‪،،،،،،،،،‬‬

‫ﻟﺬﻟﻚ ﺗﻌﺘﺒﺮ ﺳﻠﺴﻠﺔ ﻛﺘﺐ اﻟﺪورات اﻟﺘﻌﻠﯿﻤﯿﺔ ‪:‬‬

‫أول ﺳﻠﺴﻠﺔ ﻛﺘﺎب إﻟﻜﺘﺮوﻧﯿﺔ ﻋﺮﺑﯿﺔ ﺧﺎﺻﺔ ﺑﺎﻟﻤﺒﺘﺪأﯾﻦ‪.‬‬ ‫•‬

‫اﻟﺴﻠﺴﻠﺔ اﻟﻮﺣﯿﺪة اﻟﺘﻰ ﺗﺘﺒﻊ ﻧﻈﺎم اﻷﺳﺌﻠﺔ واﻷﺟﻮﺑﺔ اﻟﻨﺎﺗﺠﺔ ﻓﻌﻼً ﻣﻦ ﻣﺸﺎﻛﻞ ﺣﻘﯿﻘﺔ ﻷﺷﺨﺎص ﻣﻦ ﻣﺨﺘﻠﻒ‬ ‫•‬
‫اﻷﻣﺎﻛﻦ واﻟﺪول ‪ ،‬ﻣﻤﺎ ﯾﻬﯿﺊ ﻋﻨﺪك ﻧﻮع ﻣﻦ اﺳﺘﻌﺪاد ﻷى ﻣﺸﻜﻠﺔ وﻛﯿﻔﯿﺔ اﻟﺘﻌﺎﻣﻞ ﻣﻌﻬﺎ‪.‬‬

‫ﺗﻌﺘﺒﺮ ﺳﻠﺴﻠﺔ اﻟﻜﺘﺎب اﻟﻮﺣﯿﺪة اﻟﻤﺪﻋﻮﻣﺔ ارﺑﻊ وﻋﺸﺮﯾﻦ ﺳﺎﻋﺔ ﻃﻮال اﻟﻌﺎم ‪ ،‬ﻓﯿﻤﻜﻨﻚ اﻻﺳﺘﻔﺴﺎر ﻋﻦ اى‬ ‫•‬
‫ﻣﺸﻜﻠﺔ وﺣﻠﻬﺎ ﻋﻦ ﻃﺮﯾﻖ وﺿﻌﻬﺎ ﻓﻰ ﺳﺎﺣﺔ اﻟﻨﻘﺎش واﻷﺳﺌﻠﺔ ﺑﺎﻟﻤﻮﺳﻮﻋﺔ ‪.‬‬

‫إن ﻫﺬا اﻟﻜﺘﺎب ﻫﻮ ﻣﻦ اﺟﻞ ﻧﺸﺮ اﻟﻤﻌﺮﻓﺔ وﺗﻮﺳﯿﻊ اﻟﺘﻔﻜﯿﺮ اﻟﻤﻨﻄﻘﻰ اﻷﺳﺎﺳﻲ ‪ ،‬اﻻﺣﺘﺮاف ﻫﻮ ﻟﯿﺲ اﻟﻬﺪف‬ ‫•‬
‫ﻓﻰ ﺣﺪ ذاﺗﻪ‪ ،‬ﺑﻞ اﻻﺳﺘﻄﻼع واﻛﺘﺸﺎف اﻟﺬات واﻹﻟﻤﺎم اﻟﺠﯿﺪ ﺑﺎﻷﺳﺎﺳﯿﺎت واﻟﻤﺒﺎدئ اﻷوﻟﯿﺔ‬
‫ﻣﻦ اﺟﻞ ﺷﻖ ﻃﺮﯾﻖ اﻟﻨﺠﺎح ﺑﻜﻞ ﺳﻬﻮﻟﺔ وﯾﺴﺮ‪.‬‬

‫‪3‬‬
 ‫اﻟﻤﺤﺘﻮﻳﺎت ‪..‬‬

‫اﻟﺪرس اﻷول‪ :‬ﻣﺎذا ﻧﻌﻨﻲ ﺑﮫﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت؟‬

‫اﻟﺪرس اﻟﺜﺎﻧﻲ‪ :‬دورة ﺣﯿﺎة ﺗﻄﻮﻳﺮ اﻟﻤﺸﺮوع‬

‫اﻟﺪرس اﻟﺜﺎﻟﺚ‪ :‬دراﺳﺔ اﻟﻤﺘﻄﻠﺒﺎت‬

‫اﻟﺪرس اﻟﺮاﺑﻊ‪ :‬ﺗﺼﻤﯿﻢ اﻟﻨﻈﺎم‬

‫اﻟﺪرس اﻟﺨﺎﻣﺲ‪ :‬ﻛﺘﺎﺑﺔ اﻟﺒﺮﻧﺎﻣﺞ واﺧﺘﺒﺎره‬

‫اﻟﺪرس اﻟﺨﺎﻣﺲ _ اﻟﺤﺰء اﻟﺜﺎﻧﻰ ‪ :‬ﻛﺘﺎﺑﺔ اﻟﺒﺮﻧﺎﻣﺞ واﺧﺘﺒﺎره‬

‫‪4‬‬
 ‫ﺑﺴﻢ اﷲ اﻟﺮﺣﻤﻦ اﻟﺮﺣﯿﻢ‬

‫اﻟﺪرس اﻷول‪ :‬ﻣﺎذا ﻧﻌﻨﻲ ﺑﮫﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت؟‬

‫أھﺪاف اﻟﺪرس اﻷول‪:‬‬

‫ﺳﻮف ﻧﺤﺎول ﺧﻼل ھﺬا اﻟﺪرس اﻹﺟﺎﺑﺔ ﻋﻠﻰ ھﺬه اﻷﺳﺌﻠﺔ‪:‬‬

‫ﻣﺎ ھﻲ ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت؟‬ ‫•‬

‫ﻣﻦ ﻳﺸﺎرك ﺑﮫﺎ؟‬ ‫•‬
‫ﻣﺎ ھﻲ ﻣﻜﻮﻧﺎت اﻟﻨﻈﻢ اﻟﺒﺮﻣﺠﯿﺔ؟‬ ‫•‬
‫وﻛﯿﻒ ﻳﺘﻢ ﺑﻨﺎﺋﮫﺎ؟‬ ‫•‬

‫ﻣﻘﺪﻣﺔ‪:‬‬
‫ﻟﻢ ﻳﻌﺪ ﺧﺎﻓﯿﺎ ﻋﻠﻰ أي ﻣﻨﺎ أھﻤﯿﺔ اﻟﺒﺮﻣﺠﯿﺎت ‪ Software‬ﻓﻲ ﺣﯿﺎﺗﻨﺎ اﻟﯿﻮﻣﯿﺔ ﺳﻮاء ﻓﻲ اﻟﺒﯿﺖ أو اﻟﻤﺼﻨﻊ أو‬
‫اﻟﻤﺴﺘﺸﻔﻰ أو ‪ ...‬اﻟﺦ‪ ،‬ﻓﻨﺤﻦ ﻧﺘﻌﺎﻣﻞ ﻳﻮﻣﯿﺎ ﻣﻊ اﻟﻌﺪﻳﺪ ﻣﻦ اﻷﺟﮫﺰة واﻟﻤﻌﺪات اﻟﺘﻲ ﺗﻌﺘﻤﺪ ﻓﻲ ﻋﻤﻠﮫﺎ ﻋﻠﻰ‬
‫اﻟﺒﺮﻣﺠﯿﺎت وﻣﻦ اﻟﻤﮫﻢ ﻟﻨﺎ أن ﺗﻌﻤﻞ ھﺬه اﻷﺟﮫﺰة وﺑﺮاﻣﺠﮫﺎ ﺑﺎﻟﺸﻜﻞ واﻟﻜﻔﺎءة اﻟﺘﻲ ﻧﺘﻮﻗﻌﮫﺎ ﻣﻨﮫﺎ‪ .‬ﻟﺬا ﻓﺈن‬
‫ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت أﺻﺒﺤﺖ اﻟﯿﻮم أﻛﺜﺮ أھﻤﯿﺔ ﻣﻦ أي وﻗﺖ ﻣﻀﻰ‪.‬‬

‫اﻟﻤﺮﺟﻊ‪:‬‬

‫‪1- Shari Pfleeger, "Software Engineering - Theory and Practice", 2nd Edition‬‬

‫ﻣﺎ ھﻲ ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت؟‬

‫ﻟﻨﻔﮫﻢ ﻣﻌﺎ ﻋﻼﻗﺔ ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت ﺑﻌﻠﻮم اﻟﻜﻮﻣﺒﯿﻮﺗﺮ‪ ،‬دﻋﻮﻧﺎ ﻧﺄﺧﺬ ھﺬا اﻟﻤﺜﺎل ﻋﻦ ﻋﻠﻢ اﻟﻜﯿﻤﯿﺎء واﺳﺘﺨﺪاﻣﻪ‬
‫ﻓﻲ ﺣﻞ اﻟﻤﺸﺎﻛﻞ اﻟﺘﻲ ﻧﻘﺎﺑﻠﮫﺎ ﻓﻲ ﺣﯿﺎﺗﻨﺎ اﻟﯿﻮﻣﯿﺔ‪.‬‬
‫ﻳﮫﺘﻢ اﻟﻜﯿﻤﯿﺎﺋﻲ ﺑﺪراﺳﺔ اﻟﻤﻮاد اﻟﻜﯿﻤﯿﺎﺋﯿﺔ )ﺗﺮﻛﯿﺒﮫﺎ‪ ،‬ﺗﻔﺎﻋﻼﺗﮫﺎ‪ ،‬واﻟﻨﻈﺮﻳﺎت اﻟﺘﻲ ﺗﺤﻜﻢ ﺳﻠﻮﻛﮫﺎ‪).‬‬
‫ﺑﯿﻨﻤﺎ اﻟﻤﮫﻨﺪس اﻟﻜﯿﻤﯿﺎﺋﻲ ﻳﺴﺘﺨﺪم اﻟﻨﺘﺎﺋﺞ اﻟﺘﻲ ﺗﻮﺻﻞ إﻟﯿﮫﺎ اﻟﻜﻤﯿﺎﺋﻲ ﻟﺤﻞ اﻟﻤﺸﺎﻛﻞ اﻟﺘﻲ ﻳﻄﻠﺐ ﻣﻨﻪ إﻳﺠﺎد‬
‫ﺣﻞ ﻟﮫﺎ‪.‬‬
‫ﻣﻦ وﺟﮫﻪ ﻧﻈﺮ اﻟﻜﯿﻤﯿﺎﺋﻲ اﻟﻜﻤﯿﺎء ھﻲ ﻣﻮﺿﻮع اﻟﺪراﺳﺔ ﺑﺤﺪ ذاﺗﮫﺎ‪.‬‬
‫وﻣﻦ وﺟﮫﻪ ﻧﻈﺮ اﻟﻤﮫﻨﺪس اﻟﻜﻤﯿﺎﺋﻲ اﻟﻜﯿﻤﯿﺎء ھﻲ أداة ‪ tool‬ﺗﺴﺘﺨﺪم ﻷﻳﺠﺎد اﻟﺤﻠﻮل ﻟﻤﺸﺎﻛﻞ ﻋﺎﻣﺔ( وﻗﺪ ﻻ‬
‫ﺗﻜﻮن ھﺬه اﻟﻤﺸﻜﻠﺔ ذات ﻃﺒﯿﻌﺔ ﻛﯿﻤﯿﺎﺋﯿﺔ ﺑﺤﺪ ذاﺗﮫﺎ‪).‬‬

‫وﺑﻨﻔﺲ اﻟﻔﻜﺮة ﻳﻤﻜﻦ اﻟﻨﻈﺮ إﻟﻰ ﻋﻠﻢ اﻟﺤﻮﺳﺒﺔ ‪ computer science‬ﺣﯿﺚ ﻳﻜﻮن ﺗﺮﻛﯿﺰﻧﺎ ﻋﻠﻰ اﻟﺤﻮاﺳﯿﺐ وﻟﻐﺎت‬
‫اﻟﺒﺮﻣﺠﺔ ﻟﺪرﺳﺘﮫﺎ وﺗﻄﻮﻳﺮھﺎ ﻓﻲ ﺣﺪ ذاﺗﮫﺎ‪.‬‬
‫أو ﻳﻤﻜﻦ اﻟﻨﻈﺮ إﻟﯿﮫﺎ واﻟﺘﻌﺎﻣﻞ ﺑﮫﺎ ﻋﻠﻰ أﻧﮫﺎ أدوات ﻧﺴﺘﺨﺪﻣﮫﺎ ﻋﻨﺪ ﺗﺼﻤﯿﻢ وﺗﻄﻮﻳﺮ ﺣﻞ ﻟﻤﺸﻜﻠﺔ ﻣﺎ ﺗﻮاﺟﮫﻨﺎ أو‬
‫اﻵﺧﺮﻳﻦ‪.‬‬

‫ﻣﮫﻨﺪس اﻟﺒﺮﻣﺠﯿﺎت ‪ Software Engineer‬ﻳﻌﺘﺒﺮ أن اﻟﻜﻤﺒﯿﻮﺗﺮ ھﻮ أداة ﻟﺤﻞ اﻟﻤﺸﺎﻛﻞ‪problem-solving tool.‬‬

‫وﻋﻠﯿﻪ أن ﻳﺴﺘﺨﺪم ﻣﻌﻠﻮﻣﺎﺗﻪ ﺣﻮل اﻟﺤﺎﺳﻮب وﻋﻠﻢ اﻟﺤﻮﺳﺒﺔ ﻟﻠﻤﺴﺎﻋﺪة ﻓﻲ ﺣﻞ اﻟﻤﺸﻜﻠﺔ اﻟﺘﻲ ﻳﻄﻠﺐ ﻣﻨﻪ‬
‫إﻳﺠﺎد ﺣﻞ ﻟﮫﺎ‪.‬‬

‫‪5‬‬
 ‫ﺷﻜﻞ )‪(1-1‬‬

‫وﻟﻜﻦ وﻣﻦ اﻟﻤﮫﻢ أن ﻧﺘﺬﻛﺮ أن ﻋﻤﻠﯿﺔ ﻛﺘﺎﺑﺔ اﻟﺒﺮاﻣﺞ ﺗﻌﺪ ﻓﻦ ‪ Art‬ﺑﻘﺪر ﻣﺎ ھﻲ ﻋﻠﻢ‪ ،‬ﻟﻤﺎذا؟‬

‫ﻷﻧﻪ ﻳﻤﻜﻦ ﻷي ﺷﺨﺺ ﻟﺪﻳﻪ ﻣﻌﺮﻓﺔ ﻛﺎﻓﯿﺔ ﺑﺄﺣﺪ ﻟﻐﺎت ﺑﺮﻣﺠﺔ اﻟﺤﺎﺳﻮب ‪ hacker‬أن ﻳﻜﺘﺐ ﺑﺮﻧﺎﻣﺞ ﻟﯿﺆدي ﻣﮫﻤﺔ‬
‫ﻣﺤﺪدة‪ ،‬ﻟﻜﻦ اﻻﻣﺮ ﻳﺘﻄﻠﺐ ﻣﮫﺎرة وﻣﻌﺮﻓﺔ ﻣﮫﻨﺪس ﺑﺮﻣﺠﯿﺎت ﻣﺤﺘﺮف ﻟﻜﺘﺎﺑﺔ ﺑﺮﻧﺎﻣﺞ أﻛﺜﺮ ﺗﻨﺎﺳﻘﺎ ووﺿﻮﺣﺎ ‪،‬وأﺳﮫﻞ‬
‫ﻓﻲ اﻟﺼﯿﺎﻧﺔ‪ ،‬وﻳﻘﻮم ﺑﺎﻟﻤﮫﻤﺔ اﻟﻤﻄﻠﻮﺑﺔ ﻣﻨﻪ ﺑﻔﻌﺎﻟﯿﺔ ودﻗﺔ أﻛﺒﺮ‪.‬‬

‫أي أن‪ ،‬ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت ﺗﻌﻨﻰ ﺑﺘﺼﻤﯿﻢ وﺗﻄﻮﻳﺮ ﺑﺮاﻣﺞ ذات ﺟﻮدة ﻋﺎﻟﯿﺔ‪.‬‬

‫ﻣﻦ ﻳﺸﺎرك ﻓﻲ ھﺬه اﻟﻌﻤﻠﯿﺔ؟‬

‫اﻟﻤﺸﺎرﻛﻮن ﻓﻲ ﻋﻤﻠﯿﺔ ﺻﻨﺎﻋﺔ اﻟﺒﺮﻧﺎﻣﺞ‪ ،‬ﻋﺎدة ﻣﺎ ﻳﻨﺪرﺟﻮن ﺗﺤﺖ ﺛﻼث ﻣﺠﻤﻮﻋﺎت‪:‬‬

‫اﻟﺰﺑﻮن ‪ Customer:‬وھﻮ اﻟﺸﺮﻛﺔ )أو اﻟﺸﺨﺺ( اﻟﻤﻤﻮﻟﺔ ﻟﻤﺸﺮ وع ﺗﻄﻮﻳﺮ اﻟﺒﺮﻧﺎﻣﺞ اﻟﻤﻄﻠﻮب‬ ‫•‬
‫اﻟﻤﺴﺘﺨﺪم ‪ User:‬اﻟﺸﺨﺺ )أو ﻣﺠﻤﻮﻋﺔ اﻻﺷﺨﺎص ( اﻟﺬي ﺳﻮف ﻳﻘﻮم ﻓﻌﻼ ﺑﺎﺳﺘﻌﻤﺎل اﻟﺒﺮﻧﺎﻣﺞ‪،‬‬ ‫•‬
‫واﻟﺘﻌﺎﻣﻞ ﻣﻌﻪ ﻣﺒﺎﺷﺮة‪.‬‬
‫اﻟﻤﻄﻮر ‪ Developer:‬وھﻮ اﻟﺸﺮﻛﺔ )أو اﻟﺸﺨﺺ( اﻟﺬي ﺳﻮف ﻳﻘﻮم ﺑﺘﻄﻮﻳﺮ اﻟﺒﺮﻧﺎﻣﺞ ﻟﺼﺎﻟﺢ اﻟﺰﺑﻮن‪.‬‬ ‫•‬

‫اﻟﺸﻜﻞ اﻟﺘﺎﻟﻲ ﻳﻈﮫﺮ اﻟﻌﻼﻗﺔ ﺑﯿﻦ اﻟﻔﺌﺎت اﻟﺜﻼﺛﺔ اﻟﺴﺎﺑﻘﺔ‬

‫‪6‬‬
 ‫ﺷﻜﻞ )‪(2-1‬‬

‫ﻣﻜﻮﻧﺎت اﻟﻨﻈﺎم‬
‫ﻣﺸﺎرﻳﻌﻨﺎ اﻟﺘﻲ ﻧﻄﻮرھﺎ ﻟﻦ ﺗﻌﻤﻞ ﻓﻲ اﻟﻔﺮاغ‪ ،‬ﻓﻌﻠﯿﮫﺎ أن ﺗﺘﻔﺎﻋﻞ ﻣﻊ ﻣﺴﺘﺨﺪﻣﯿﻦ‪ ،‬أﺟﮫﺰة وﻣﻌﺪات ﻣﺘﻨﻮﻋﺔ‪ ،‬ﻧﻈﻢ‬
‫ﺗﺸﻐﯿﻞ وﺑﺮاﻣﺞ وﻣﻠﻔﺎت وﻗﻮاﻋﺪ ﺑﯿﺎﻧﺎت ‪ ....‬إﻟﺦ و رﺑﻤﺎ ﺣﺘﻰ أﻧﻈﻤﺔ ﺣﻮاﺳﯿﺐ آﺧﺮى‪ .‬ﻟﮫﺬا ﻳﺠﺐ ﺗﻌﺮﻳﻒ ﺣﺪود‬
‫اﻟﻨﻈﺎم وﻣﻜﻮﻧﺎﺗﻪ ﺟﯿﺪا ‪.‬أي ﻳﺠﺐ ﺗﻌﺮﻳﻒ ﻣﺎ اﻟﺬي ﻳﺸﺘﻤﻞ ﻋﻠﯿﻪ اﻟﻨﻈﺎم وﻣﺎ اﻟﺬي ﻻ ﻳﺸﺘﻤﻞ ﻋﻠﯿﻪ‪.‬‬

‫أي ﻧﻈﺎم ھﻮ ﻋﺒﺎرة ﻋﻦ ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻟﻜﺎﺋﻨﺎت ‪ objects‬واﻟﻨﺸﺎﻃﺎت ‪ activities‬ﺑﺎﻹﺿﺎﻓﺔ إﻟﻰ وﺻﻒ ﻟﻠﻌﻼﻗﺎت‬
‫اﻟﺘﻲ ﺗﺮﺑﻂ ﺗﻠﻚ اﻟﻜﺎﺋﻨﺎت واﻟﻨﺸﺎﻃﺎت ﻣﻌﺎ‪ .‬ﻣﻊ ﺗﻌﺮﻳﻒ ﻗﺎﺋﻤﺔ اﻟﻤﺪﺧﻼت اﻟﻤﻄﻠﻮﺑﺔ واﻟﺨﻄﻮات اﻟﻤﺘﺒﻌﺔ واﻟﻤﺨﺮﺟﺎت‬
‫اﻟﻨﺎﺗﺠﺔ ﻟﻜﻞ ﻧﺸﺎط‪.‬‬

‫أول ﺧﻄﻮات ﺗﺤﻠﯿﻞ اﻟﻤﺸﻜﻠﺔ ھﻮ ﻓﮫﻢ ﻣﺎھﯿﺔ اﻟﻤﺸﻜﻠﺔ وﺗﻌﺮﻳﻔﮫﺎ ﺑﻮﺿﻮح‪ ،‬ﻟﺬا ﻋﻠﯿﻨﺎ أوﻻ أن ﻧﺼﻒ اﻟﻨﻈﺎم ﺑﺘﺤﺪﻳﺪ‬
‫ﻣﻜﻮﻧﺎﺗﻪ واﻟﻌﻼﻗﺎت اﻟﺘﻲ ﺗﺮﺑﻂ ﺑﯿﻦ ھﺬه اﻟﻤﻜﻮﻧﺎت‪.‬‬
‫‪1.‬اﻟﻨﺸﺎﻃﺎت واﻟﻜﺎﺋﻨﺎت‪ :‬اﻟﻨﺸﺎط ھﻮ ﻋﻤﯿﻠﺔ ﺗﺤﺪث ﺑﺎﻟﻨﻈﺎم وﻋﺎدة ﻣﺎ ﻳﻮﺻﻒ ﻛﺤﺪث ﻳﺘﻢ ﻣﻦ ﺧﻼل ﺣﺎﻓﺰ‪ .‬اﻟﻨﺸﺎط‬
‫ﻳﻐﯿﺮ ﺷﺊ ﻣﺎ إﻟﻰ آﺧﺮ ﺑﺘﻐﯿﺮ ﺧﻮاﺻﻪ )ﺻﻔﺎﺗﻪ)‬
‫ھﺬا اﻟﺘﻐﯿﺮ ﻳﻤﻜﻦ أن ﻳﻌﻨﻰ ﺗﺤﻮﻳﻞ أﺣﺪ ﻋﻨﺎﺻﺮ اﻟﺒﯿﺎﻧﺎت ﻣﻦ ﻣﻮﻗﻊ إﻟﻰ آﺧﺮ‪ ،‬أو ﺗﻌﺪﻳﻞ ﻗﯿﻤﺘﻪ إﻟﻰ ﻗﯿﻤﺔ ﻣﺨﺘﻠﻔﺔ‪.‬‬
‫ھﺬه اﻟﻌﻨﺎﺻﺮ ﺗﺴﻤﻰ ﻛﺎﺋﻨﺎت ‪ objects‬وھﻲ ﻋﺎدة ﻣﺎﺗﻜﻮن ﻣﺮﺗﺒﻄﺔ ﺑﺒﻌﻀﮫﺎ اﻟﺒﻌﺾ ﺑﺸﻜﻞ أو ﺑﺄﺧﺮ‪ .‬ﻣﺜﻼ اﻟﻜﺎﺋﻨﺎت‬
‫ﻳﻤﻜﻦ أن ﺗﻜﻮن ﻣﺮﺗﺒﺔ ﻓﻲ ﻣﺼﻔﻮﻓﺔ أو ﺳﺠﻞ( ﻗﯿﺪ‪).‬‬

‫‪7‬‬
 ‫وﺻﻒ ھﺬه اﻟﻜﺎﺋﻨﺎت ﻧﻮﻋﮫﺎ‪ ،‬اﻟﻨﺸﺎﻃﺎت اﻟﺘﻲ ﻳﻤﻜﻦ إﺟﺮاﺋﮫﺎ ﻋﻠﯿﮫﺎ ‪ ...‬ﻳﺠﺐ وﺿﻌﮫﺎ ﺑﺪﻗﺔ ھﻲ اﻳﻀﺎ‪.‬‬

‫‪2.‬اﻟﻌﻼﻗﺎت وﺣﺪود اﻟﻨﻈﺎم‪Relationships and System Boundary‬‬

‫ﺑﻌﺪ ﺗﻌﺮﻳﻒ اﻟﻜﺎﺋﻨﺎت واﻟﻨﺸﺎﻃﺎت ﺟﯿﺪا‪ ،‬ﻳﻤﻜﻦ أن ﻧﺮﺑﻂ ﺑﯿﻦ ﻛﻞ ﻛﺎﺋﻦ واﻟﻨﺸﺎﻃﺎت اﻟﻤﺘﻌﻠﻘﺔ ﺑﻪ ﺑﺪﻗﺔ‪ .‬ﺗﻌﺮﻳﻒ اﻟﻜﺎﺋﻦ‬
‫ﻳﺘﻀﻤﻦ اﻟﻤﻮﻗﻊ اﻟﺬي ﺳﻮف ﻳﻨﺸﺄ ﺑﻪ)ﻧﻌﺾ اﻟﻌﻨﺎﺻﺮ ﻳﻤﻜﻦ أن ﺗﻜﻮن ﻣﻮﺟﻮدة ﺑﻤﻠﻒ ﺳﺒﻖ اﻧﺸﺎءه‪ ،‬واﻟﺒﻌﺾ ﻗﺪ ﻳﺘﻢ‬
‫اﻧﺸﺎءه ﺧﻼل ﺣﺪث ﻣﺎ)‪ ،‬واﻟﮫﺪف ﻣﻦ اﻧﺸﺎءه)ﺑﻌﺾ اﻟﻜﺎﺋﻨﺎت ﺗﺴﺘﺨﺪم ﻣﻦ ﻗﺒﻞ ﻧﺸﺎط واﺣﺪ ﻓﻘﻂ واﻟﺒﻌﺾ ﻳﻤﻜﻦ‬
‫أن ﻳﺴﺘﻌﻤﻞ ﻣﻦ ﻗﺒﻞ ﻧﻈﻢ آﺧﺮى ﻛﻤﺪﺧﻼت ‪ Input) ,‬ﻟﺬا ﻳﻤﻜﻦ أن ﻧﻌﺘﺒﺮ أن ﻟﻨﻈﺎﻣﻨﺎ ﺣﺪود ‪ boundary‬ﺑﻌﺾ‬
‫اﻟﻜﺎﺋﻨﺎت ﺑﻤﻜﻦ أن ﺗﻌﺒﺮ ھﺬه اﻟﺤﺪود إﻟﻰ داﺧﻞ اﻟﻨﻈﺎم‪ ،‬واﻟﺒﻌﺾ اﻵﺧﺮ ھﻲ ﻣﺨﺮﺟﺎت ﻣﻦ ﻧﻈﺎﻣﻨﺎ وﻳﻤﻜﻦ أن ﺗﺮﺣﻞ‬
‫إﻟﻰ ﻧﻈﻢ آﺧﺮى‪.‬‬

‫ﺑﮫﺬا ﻳﻤﻜﻦ أن ﻧﻌﺮف اﻟﻨﻈﺎم ‪ A System‬ﻋﻠﻰ أﻧﻪ ﺗﺠﻤﻊ ﻣﻦ‪:‬‬

‫·ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻟﻜﺎﺋﻨﺎت‪entities.‬‬
‫·ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻻﻧﺸﻄﺔ‪activities.‬‬
‫·وﺻﻒ ﻟﻠﻌﻼﻗﺎت ﺑﯿﻦ اﻟﻜﺎﺋﻨﺎت واﻻﻧﺸﻄﺔ‪Relationship.‬‬
‫·ﺗﻌﺮﻳﻒ ﻟﺤﺪود اﻟﻨﻈﺎم‪boundary.‬‬

‫ﻛﯿﻒ ﻧﺒﻲ ﻧﻈﺎم؟‬

‫إذا ﻃﻠﺐ ﻣﻨﺎ ﻋﻤﯿﻞ ﺗﻄﻮﻳﺮ ﻧﻈﺎم )ﺑﺮﻧﺎﻣﺞ( ﻟﻪ‪ ،‬ﻟﺤﻞ ﻣﺸﻜﻠﺔ ﻣﻌﯿﻨﺔ ﺗﻮاﺟﮫﻪ ﻓﻲ ﻋﻤﻠﻪ‪ .‬ﻓﻤﺜﻼ ﻳﺤﺘﺎج ﻧﻈﺎم ﺣﻤﺎﻳﺔ‬
‫ﻟﺸﺮﻛﺘﻪ‪ ،‬أو ﻧﻈﺎم ﺻﺮف آﻟﻲ ﻟﺒﻨﻚ‪ ،‬أو ﻣﻤﻜﻦ أن ﻳﻜﻮن ﺻﺎﺣﺐ ﻣﻜﺘﺒﺔ أو ﻣﺘﺠﺮ و ﻳﺮﻳﺪ ﺗﻐﯿﺮ ﻧﻈﺎم اﻟﺒﯿﻊ و اﻟﺸﺮاء أو‬
‫اﻟﻌﺮض ﻟﯿﺘﻢ ﺑﺸﻜﻞ آﻟﻲ‪ .‬ﻋﻠﯿﻨﺎ اﺗﺒﺎع اﻟﺨﻄﻮات اﻟﺘﺎﻟﯿﺔ ﻟﺒﻨﺎء ھﺬا اﻟﻨﻈﺎم‪:‬‬
‫‪1.‬ﻋﻘﺪ اﺟﺘﻤﺎع ﻣﻊ اﻟﻌﻤﯿﻞ ﻟﺘﺤﺪﻳﺪ ﻣﺘﻄﻠﺒﺎﺗﻪ‪ ،‬ھﺬه اﻟﻤﺘﻄﻠﺒﺎت ﺗﺸﻤﻞ وﺻﻒ اﻟﻨﻈﺎم ﺑﺠﻤﯿﻊ ﻣﻜﻮﻧﺎﺗﻪ اﻟﺘﻲ‬
‫ﺷﺮﺣﻨﺎ‪.‬‬
‫‪2.‬وﺿﻊ ﺗﺼﻤﯿﻢ ﻋﺎم ﻟﻠﻨﻈﺎم ﻳﺤﻘﻖ اﻟﻤﺘﻄﻠﺒﺎت اﻟﺘﻲ ﺣﺪدھﺎ اﻟﻌﻤﯿﻞ‪ ،‬وﻋﺮﺿﻪ ﻋﻠﻰ اﻟﻌﻤﯿﻞ ﻟﯿﻮﺿﺢ ﻟﻪ اﻟﺸﻜﻞ‬
‫اﻟﺬي ﺳﯿﻈﮫﺮ ﻋﻠﯿﻪ اﻟﻨﻈﺎم ﻋﻨﺪ اﻻﻧﺘﮫﺎء‪ ،‬و وﻣﺮاﺟﻌﺘﻪ ﻣﻌﻪ ﻷﺧﺬ ﻣﻮاﻓﻘﺘﻪ ﻋﻠﯿﻪ‪.‬‬
‫‪3.‬ﺑﻌﺪ ﻣﻮاﻓﻘﺔ اﻟﻌﻤﯿﻞ ﻋﻠﻰ اﻟﺘﺼﻤﯿﻢ ﻳﺘﻢ اﻟﻌﻤﻞ ﻋﻠﻰ وﺿﻊ اﻟﺘﺼﺎﻣﯿﻢ اﻟﺘﻔﺼﯿﻠﯿﺔ ﻷﺟﺰاء اﻟﻤﺸﺮوع‪.‬‬
‫‪4.‬ﻛﺘﺎﺑﺔ اﻟﺒﺮﻧﺎﻣﺞ‬
‫‪5.‬اﺧﺘﺒﺎره‪ ،‬واﻋﺎدة ﻣﺮاﺟﻌﺔ اﻟﻤﺘﻄﻠﺒﺎت اﻟﺘﻲ وﺿﻌﮫﺎ اﻟﻌﻤﯿﻞ ﻟﻠﺘﺄﻛﺪ ﻣﻦ ﺗﺤﻘﻘﮫﺎ ﻓﻲ اﻟﺒﺮﻧﺎﻣﺞ‪.‬‬
‫‪6.‬ﺗﺴﻠﯿﻢ اﻟﻨﻈﺎم إﻟﻰ اﻟﻌﻤﯿﻞ‪.‬‬
‫‪7.‬ﺑﻌﺪ ﺗﺴﻠﻢ اﻟﻌﻤﯿﻞ ﻟﻠﻨﻈﺎم ﻗﺪ ﺗﻈﮫﺮ ﺑﻌﺾ اﻟﻤﺸﺎﻛﻞ أو اﻻﺧﻄﺎء اﻟﺘﻲ ﻟﻢ ﺗﻈﮫﺮ ﺧﻼل ﻋﻤﻠﯿﺔ اﻻﺧﺘﺒﺎر‪ ،‬واﻟﺘﻲ‬
‫ﺗﺠﺐ ﻋﻠﻰ اﻟﻤﻄﻮر اﺻﻼﺣﮫﺎ ﻓﯿﻤﺎ ﻳﻌﺮف ﺑﺼﯿﺎﻧﺔ اﻟﻨﻈﺎم‪.‬‬

‫ﺧﻼل اﻟﺪروس اﻟﺘﺎﻟﯿﺔ ﻣﻦ اﻟﺪورة ﺳﻨﺘﻌﺮف ﻋﻠﻰ ﻛﻞ ﺧﻄﻮة ﻣﻦ ھﺬه اﻟﺨﻄﻮات وﻛﯿﻒ ﺗﺘﻢ ﺑﺸﻜﻞ ﻣﺒﺴﻂ‪ ،‬وﺳﻮف‬
‫ﻧﺨﻮض ﻓﻲ ﻣﺰﻳﺪ ﻣﻦ اﻟﺘﻔﺎﺻﯿﻞ ﻓﻲ دروس ﻻﺣﻘﺔ ﺑﺈذن اﷲ‪.‬‬

‫( •·‪•·.·´¯`·.‬ﻧﮫﺎ ﻳﺔ اﻟﺪرس اﻷول•·‪) •·.·´¯`·.‬‬

‫‪8‬‬
 ‫( •·‪•·.·´¯`·.‬ﻧﻘﺎش اﻟﺪرس اﻷول•·‪) •·.·´¯`·.‬‬

‫س‪ - 1‬ھﻞ اﻟﻤﻘﺼﻮد ﺑﮫﺬي اﻟﺠﻤﻠﺔ ان اﻟﻤﺒﺮﻣﺞ ﻻ ﻳﺴﺘﻄﯿﻊ ﺣﻞ اﻟﻤﺸﻜﻠﻪ ﻓﻘﻂ ﻣﮫﻨﺪس اﻟﺒﺮﻣﺠﯿﺎت‬
‫ھﻮ اﻟﺬي ﻳﺴﺘﻄﯿﻊ؟؟؟؟‬

‫ﻣﻤﻜﻦ أن ﻳﻮﺟﺪ ﺷﺨﺺ ﺗﻌﻠﻢ اﻟﺒﺮﻣﺠﺔ دون أن ﻳﺪرس ھﻨﺪﺳﺔ ﺑﺮﻣﺠﯿﺎت و ﺷﺨﺺ آﺧﺮ درس ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت‬
‫وﺑﺎﻟﻄﺒﻊ ﻋﻠﻮم اﻟﺤﺎﺳﻮب ‪ ..‬ﻟﻮ اﻋﻄﯿﺖ ھﺬﻳﻦ اﻟﺸﺨﺼﯿﻦ ﻣﺸﻜﻠﺔ ﻣﺎ ‪ ..‬ﺳﯿﻜﻮن ﺣﻞ ﻣﮫﻨﺪس اﻟﺒﺮﻣﺠﯿﺎت‬
‫ﻟﻠﻤﺸﻠﻜﺔ أﻓﻀﻞ ﻣﻦ ﺣﻞ اﻟﻤﺒﺮﻣﺞ اﻟﺬي ﻟﻢ ﻳﺪرس ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت‬

‫"ﺗﺴﺘﻄﯿﻊ أن ﺗﻘﻮل أن ﻛﻞ ﻣﮫﻨﺪس ﺑﺮﻣﺠﯿﺎت ھﻮ ﻣﺒﺮﻣﺞ ﺑﯿﻨﻤﺎ ﻟﯿﺲ ﻛﻞ ﻣﺒﺮﻣﺞ ھﻮ ﻣﮫﻨﺪس ﺑﺮﻣﺠﯿﺎت"‬

‫ﻧﻌﻢ ھﺬا ھﻮ اﻟﻤﻘﺼﻮد‪ ،‬ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﺎت ﻻ ﺗﮫﺘﻢ ﻓﻘﻂ ﺑﻜﺘﺎﺑﺔ ﺑﺮﻧﺎﻣﺞ ﻳﺆدي ﻣﮫﻤﺔ ﻣﺤﺪدة ﻓﺤﺴﺐ‪ ،‬ﺑﻞ أﻧﮫﺎ‬
‫ﺗﮫﺘﻢ ﺑﻤﺎ ھﻮ أﻛﺜﺮ ﻣﻦ ذﻟﻚ "ﺟﻮدة اﻟﺒﺮﻧﺎﻣﺞ"‬

‫ﻛﻠﻤﺔ ﻣﺒﺮﻣﺞ أو ‪ Hacker‬ﺗﻄﻠﻖ ﻋﻠﻰ ﻛﻞ ﻣﻦ ﻳﻌﺮف ﻛﯿﻒ ﻳﻜﺘﺐ ﺑﺮﻧﺎﻣﺞ ﻟﻠﻘﯿﺎم ﺑﺄداء ﻋﻤﻞ ﻣﺎ‪..‬‬
‫وﻟﻜﻦ ﻛﻠﻤﺔ ﻣﮫﻨﺪس ﺑﺮﻣﺠﯿﺎت ﻻ ﺗﻄﻠﻖ إﻻ ﻋﻠﻰ ﻣﻦ ﻳﻜﺘﺐ ھﺬه اﻟﺒﺮﻣﺠﯿﺎت ﺑﺎﺳﻠﻮب ﻋﻠﻤﻲ ﻳﺴﻌﻰ ﻣﻦ ﺧﻼﻟﻪ‬
‫إﻟﻰ أن ﺗﻜﻮن ﺑﺮاﻣﺠﻪ ذات ﺟﻮدة ﻋﺎﻟﯿﺔ‪.‬‬

‫س‪ - 2‬ﻣﺎ اﻟﻤﻘﺼﻮد ﻓﻲ ﻓﻦ ‪ Art‬؟‬

‫اﻟﻤﻘﺼﻮد ﺑﻜﻠﻤﺔ ‪ Art‬ھﻮ اﻟﻔﻦ ‪ ..‬ﻷن ﻛﻠﻤﺔ اﻟﻔﻦ ‪ = Art‬ﺑﺎﻻﻧﺠﻠﯿﺰي‬

‫واﻣﺎ اﻟﻤﻘﺼﻮد ﺑﺎﻟﺪرس ‪..‬‬

‫ھﻮ ان اﻟﺒﺮﻣﺠﺔ ﻓﻦ وﺗﺬوق اﻛﺜﺮ ﻣﻦ ان ﺗﻜﻮن ﻋﻠﻢ ﻓﻘﻂ أي اﻧﻪ ﻳﻤﻜﻦ ﻛﺘﺎﺑﺔ ﻧﻔﺲ اﻟﺒﺮﻧﺎﻣﺞ ﺑﺎﺳﻠﻮب ﻣﺨﺘﻠﻒ ﻣﻦ‬
‫ﺷﺨﺼﯿﯿﻦ ﻣﺨﺘﻠﻔﯿﯿﻦ وﻳﻮدي ﻧﻔﺲ اﻟﻤﮫﺎم‪...‬‬
‫وھﺬا ﻛﻠﻪ ﻳﻌﺘﻤﺪ ﻋﻠﻲ اﺳﻠﻮب اﻟﻤﺒﺮﻣﺞ وﻛﯿﻔﯿﺔ ﺣﻠﻪ ﻟﻠﻤﺸﻜﻠﺔ وﻃﺮﻳﻘﺔ ﺻﯿﻐﺘﻪ ﻟﻠﺒﺮﻧﺎﻣﺞ ‪.‬‬

‫س‪ - 3‬ھﻞ ﻳﻮﺟﺪ ﻓﺮق ﺑﯿﻦ ﻣﮫﻨﺪس ﺑﺮﻣﺠﯿﺎت و ﻣﺤﻠﻞ ﻧﻈﻢ ؟‬

‫ﻧﻌﻢ ھﻨﺎك ﻓﺮق ﺑﯿﻦ ﻣﮫﻨﺪس اﻟﺒﺮﻣﺠﯿﺎت وﻣﺤﻠﻞ اﻟﻨﻈﻢ ﻓﻤﺜﻼ ﻓﻲ اﻟﺪول اﻟﻤﺘﻘﺪﻣﺔ ﻳﻘﻮم ﻣﺤﻠﻞ اﻟﻨﻈﺎم ﺑﺪراﺳﺔ‬
‫اﻟﻤﺸﺮوع اﻟﻤﺮاد ﺗﻨﻔﯿﺬه وﻛﯿﻔﯿﺔ ﺣﻞ اﻟﻤﺸﺎﻛﻞ اﻟﺘﻲ ﺗﻮﺟﻪ ﻛﻤﺎ وﻳﻘﻮم ﺑﺪراﺳﺔ اﻟﺠﺪوى وﻣﻌﺮﻓﺔ ﻣﺘﻄﻠﺒﺎت‬
‫اﻟﻨﻈﺎم ‪...‬اﻟﺦ‬

‫أي اﻧﻪ ﻳﻘﻮم ﺑﺘﺤﻠﯿﻞ اﻟﻨﻈﺎم اﻟﻤﺮاد ﺑﻨﺎﺋﻪ ﺗﺤﻠﯿﻞ دﻗﯿﻖ ‪.‬‬

‫اﻣﺎ ﻣﮫﻨﺪس اﻟﺒﺮﻣﺠﯿﺎت ﻓﯿﻘﻮم ﺑﺒﺮﻣﺠﺔ اﻟﻨﻈﺎم وﺗﮫﯿﺌﺘﻪ ﻛﻲ ﻳﻈﮫﺮ ﻓﻲ اﻟﺼﻮرة اﻟﻨﮫﺎﺋﯿﺔ‪..‬‬
‫أي ﻳﺤﺘﺎج ﻋﻠﻰ اﻻﻗﻞ اﻟﻲ ﺷﺨﺼﯿﻦ ﻛﻲ ﻳﺘﻢ ﺑﻨﺎء اﻟﻨﻈﺎم او اﻟﺒﺮﻧﺎﻣﺞ اﻟﻤﻄﻠﻮب‪.‬‬

‫‪9‬‬
 ‫اﻟﺪرس اﻟﺜﺎﻧﻲ‪ :‬دورة ﺣﯿﺎة ﺗﻄﻮﻳﺮ اﻟﻤﺸﺮوع‬

‫أھﺪاف اﻟﺪرس اﻟﺜﺎﻧﻲ‪:‬‬

‫ﻛﻤﺎ رأﻳﻨﺎ ﻓﻲ اﻟﺪرس اﻻول ﻓﺈن ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت ھﻮ ﻋﻤﻞ إﺑﺪاﻋﻲ ﻳﺘﻢ إداءه ﺧﻄﻮة ﺑﺨﻄﻮة‪ ،‬وﻳﺘﻌﺎون ﻓﯿﻪ ﻋﺪد‬
‫ﻣﻦ اﻻﺷﺨﺎص ﻟﻜﻞ ﻣﻨﮫﻢ ﻣﮫﻤﺔ ﻣﺤﺪدة ‪.‬ﻓﻲ ھﺬا اﻟﺪرس ﺳﻮف ﻧﻨﺎﻗﺶ اﻟﺨﻄﻮات اﻟﺘﻲ ﻳﺘﻢ اﺗﺒﺎﻋﮫﺎ ﻋﻨﺪ ﺗﻄﻮﻳﺮ‬
‫ﻣﺸﺮوع ﺑﺮﻣﺠﻲ ﺑﻤﺰﻳﺪ ﻣﻦ اﻟﺘﻔﺎﺻﯿﻞ وﻧﺒﺤﺚ ﻓﻲ اﻟﻄﺮق اﻟﻤﺴﺘﺨﺪﻣﺔ ﻟﺘﻨﻈﯿﻢ ھﺬا اﻟﻌﻤﻞ )ﺻﻨﺎﻋﺔ اﻟﺒﺮﻣﺠﯿﺎت)‬

‫ﻣﻘﺪﻣﺔ‪:‬‬
‫ﻋﻤﻠﯿﺔ ﺑﻨﺎء أي ﻣﻨﺘﺞ ﺗﻤﺮ ﺑﻌﺪة ﻣﺮاﺣﻞ ﻳﻄﻠﻖ ﻋﻠﯿﮫﺎ ﻋﺎدة "دورة اﻟﺤﯿﺎة‪ ،" Life Cycle‬وﻣﻤﺎ ﺗﻌﻠﻤﻨﺎ ﻓﻲ اﻟﺪرس‬
‫اﻟﺴﺎﺑﻖ ﻓﺈن دروة ﺣﯿﺎة ﺗﻄﻮﻳﺮ أي ﻧﻈﺎم ﺑﺮﻣﺠﻲ ‪ Software development life cycle‬ﺗﺘﻀﻤﻦ اﻟﻤﺮاﺣﻞ اﻟﺘﺎﻟﯿﺔ‪:‬‬
‫‪1.‬ﺗﺤﺪﻳﺪ وﺗﻌﺮﻳﻒ اﻟﻤﺘﻄﻠﺒﺎت‪Requirements analysis and definition‬‬
‫‪2.‬ﺗﺼﻤﯿﻢ اﻟﻨﻈﺎم‪System design‬‬
‫‪3.‬ﺗﺼﻤﯿﻢ اﻟﺒﺮﻧﺎﻣﺞ‪Program design‬‬
‫‪4.‬ﻛﺘﺎﺑﺔ اﻟﺒﺮﻧﺎﻣﺞ )ﺗﻄﻮﻳﺮه‪) Program implementation‬‬
‫‪5.‬أﺧﺘﺒﺎر وﺣﺪات اﻟﺒﺮﻧﺎﻣﺞ‪Unit testing‬‬
‫‪6.‬أﺧﺘﺒﺎر اﻟﻨﻈﺎم‪system testing‬‬
‫‪7.‬ﺗﺴﻠﯿﻢ اﻟﻨﻈﺎم‪system delivery‬‬
‫‪8.‬اﻟﺼﯿﺎﻧﺔ‪maintenance‬‬

‫ﻛﻞ ﻣﺮﺣﻠﺔ ﻣﻦ ﺗﻠﻚ اﻟﻤﺮاﺣﻞ ﺗﺘﻀﻤﻦ اﻟﻌﺪﻳﺪ ﻣﻦ اﻟﺨﻄﻮات أو اﻟﻨﺸﺎﻃﺎت وﻟﻜﻞ ﻣﻨﮫﺎ ﻣﺪﺧﻼﺗﮫﺎ وﻣﺨﺮﺟﺎﺗﮫﺎ وﺗﺄﺛﺮھﺎ‬
‫ﻋﻠﻰ ﺟﻮدة اﻟﻤﻨﺘﺞ اﻟﻨﮫﺎﺋﻲ( اﻟﺒﺮﻧﺎﻣﺞ‪).‬‬
‫دورة ﺣﯿﺎة أي ﻣﻨﺘﺞ ﺗﺒﺪأ ﺑﺄول ﺧﻄﻮة وھﻲ ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت وﺗﺘﺪرج إﻟﻰ ﺑﺎﻗﻲ اﻟﺨﻄﻮات ﻛﻤﺎ ھﻲ ﻣﺮﺗﺒﺔ ﺣﺘﻰ‬
‫اﻟﻮﺻﻮل إﻟﻰ آﺧﺮ ﺧﻄﻮة وھﻲ ﺗﺴﻠﯿﻢ اﻟﺒﺮﻧﺎﻣﺞ وﺻﯿﺎﻧﺘﻪ )إن دﻋﺖ اﻟﺤﺎﺟﺔ(‪ ،‬إﻻ أن اﻟﺘﺠﺎرب اﻟﻌﻤﻠﯿﺔ ﺗﻈﮫﺮ أن ھﺬا‬
‫ﻟﯿﺲ ﺿﺮورﻳﺎ وأن دورة ﺣﯿﺎة ﺗﻄﻮﻳﺮ اﻟﺒﺮاﻣﺞ ﻗﺪ ﺗﺄﺧﺬ أﺷﻜﺎل )أو أﻧﻤﺎط( ﻣﺨﺘﻠﻔﺔ‪ .‬وﻓﻲ ھﺬا اﻟﺪرس ﺳﻮف ﻧﺘﻌﺮف‬
‫إﻟﻰ ھﺬه اﻷﻧﻤﺎط‬

‫أﻧﻤﺎط دورة اﻟﺤﯿﺎة‪Lifecycle Models:‬‬

‫اﻟﻨﻤﻮذج اﻻﻧﺤﺪاري‪Waterfall Model‬‬

‫ﻓﻲ ھﺬا اﻟﻨﻤﻮذج ﺗﺴﯿﺮ دورة اﻟﺤﯿﺎة ﺑﺸﻜﻞ ﺗﺪرﻳﺠﻲ ﺑﺪأ ﻣﻦ اﻟﺨﻄﻮة )‪ (1‬وﺣﺘﻰ اﻟﺨﻄﻮة )‪ ،(8‬وﻛﻤﺎ ﻳﻈﮫﺮ‬
‫ﺑﺎﻟﺸﻜﻞ )‪ (1‬ﻓﺈن ﻛﻞ ﻣﺮﺣﻠﺔ ﺗﺒﺪأ ﺑﻌﺪ اﻷﻧﺘﮫﺎء ﻣﻦ اﻟﻤﺮﺣﻠﺔ اﻟﺘﻲ ﺗﺴﺒﻘﮫﺎ ﻣﺒﺎﺷﺮة‪.‬‬

‫‪10‬‬
 ‫ﺷﻜﻞ )‪(1-2‬‬

‫ﻳﺘﻤﯿﺰ اﻟﻨﻤﻮذج اﻻﻧﺤﺪاري ﺑﺎﻟﺒﺴﺎﻃﺔ‪ ،‬وﻟﺬا ﻓﺈﻧﻪ ﻳﺴّﮫﻞ ﻋﻠﻰ اﻟﻤﻄﻮر ﺗﻮﺿﯿﺢ ﻛﯿﻔﯿﺔ ﺳﯿﺮ اﻟﻌﻤﻞ ﺑﺎﻟﻤﺸﺮوع‬
‫ﻟﻠﻌﻤﯿﻞ )اﻟﺬي ﻋﺎدة ﻻ ﻳﻌﺮف اﻟﻜﺜﯿﺮ ﻋﻦ ﺻﻨﻊ اﻟﺒﺮﻣﺠﯿﺎت( واﻟﻤﺮاﺣﻞ اﻟﻤﺘﺒﻘﯿﺔ ﻣﻦ اﻟﻌﻤﻞ‪ .‬وﻗﺪ ﻛﺎن ھﺬا اﻟﻨﻤﻮذج‬
‫أﺳﺎس ﻋﻤﻞ ﻛﺜﯿﺮ ﻣﻦ اﻟﻤﺆﺳﺴﺎت ﻟﻔﺘﺮة ﻃﻮﻳﻠﺔ ﻣﺜﻞ وزارة اﻟﺪﻓﺎع اﻻﻣﺮﻳﻜﯿ ﺔ‪ ،‬واﺳﺘﻨﺒﻂ ﻣﻨﻪ اﻟﻌﺪﻳﺪ ﻣﻦ اﻟﻨﻤﺎذج‬
‫اﻻﻛﺜﺮ ﺗﻌﻘﯿﺪا‪.‬‬
‫إﻻ أن ﻟﮫﺬا اﻟﻨﻤﻮذج اﻟﻌﺪﻳﺪ ﻣﻦ اﻟﻌﯿﻮب‪ ،‬أھﻤﮫﺎ أﻧﻪ ﻻ ﻳﻌﻜﺲ اﻟﻄﺮﻳﻘﺔ اﻟﺘﻲ ﻳﻌﻤﻞ ﺑﮫﺎ اﻟﻤﻄﻮرون ﻓﻲ اﻟﻮاﻗﻊ‪.‬‬
‫ﻓﺒﺎﺳﺘﺜﻨﺎء اﻟﻤﺸﺎرﻳﻊ اﻟﺼﻐﯿﺮة واﻟﺒﺴﯿﻄﺔ )أي أﻧﮫﺎ ﻣﻔﮫﻮﻣﺔ ﺑﺸﻜﻞ ﺟﯿﺪ ﻟﻠﻤﻄﻮر( ﻓﺈن اﻟﺒﺮﻣﺠﯿﺎت ﻋﺎدة ﻣﺎ ﺗﻨﺘﺞ‬
‫ﺑﻌﺪ ﻗﺪر ھﺎﺋﻞ ﻣﻦ اﻟﺘﻜﺮار واﻻﻋﺎدة‪ .‬ﻓﻲ ﺣﯿﻦ أن ھﺬا اﻟﻨﻤﻮذج ﻳﻔﺘﺮض أن ﻳﻜﻮن اﻟﺤﻞ واﺿﺢ وﻣﻔﮫﻮم وﺳﺒﻖ‬
‫ﺗﺤﻠﯿﻠﻪ ﺑﺎﻟﻜﺎﻣﻞ ﻗﺒﻞ ﻣﺒﺎﺷﺮة ﻣﺮﺣﻠﺔ اﻟﺘﺼﻤﯿﻢ وھﻮ أﻣﺮ ﻳﻜﺎد ﻳﻜﻮن ﺷﺒﻪ ﻣﺴﺘﺤﯿﻞ ﻣﻊ اﻻﻧﻈﻤﺔ اﻟﻀﺨﻤﺔ‪ .‬وﺣﺘﻰ‬
‫إن ﻛﺎن ﻣﻤﻜﻦ ﻓﺈﻧﻪ ﻳﺄﺧﺬ وﻗﺖ ﻃﻮﻳﻞ ﺟﺪا )رﺑﻤﺎ ﺳﻨﻮات!)‬

‫ﺑﺎﺧﺘﺼﺎر‪،‬اﻟﻨﻤﻮذج اﻻﻧﺤﺪاري ﺳﮫﻞ اﻟﻔﮫﻢ و ﺑﺴﯿﻂ ﻓﻲ إدارﺗﻪ‪ .‬ﻟﻜﻦ ﻣﻤﯿﺰاﺗﻪ ﺗﺒﺪأ ﻓﻲ اﻟﺘﺪاﻋﻲ ﺑﻤﺠﺮد أن ﻳﺰداد‬
‫ﺗﻌﻘﯿﺪ اﻟﻤﺸﺮوع‪.‬‬

‫اﻟﺘﻄﻮﻳﺮ ﻋﻠﻰ ﻣﺮاﺣﻞ‪Phased Development‬‬

‫ﺣﺴﺐ اﻟﻨﻤﻮذج اﻻﻧﺤﺪاري ﻓﺈﻧﻪ ﻳﺠﺐ ﻋﻠﻰ اﻟﻤﻄﻮرﻳﻦ إﻧﮫﺎء ﻣﺮﺣﻠﺔ ﺗﺤﻠﯿﻞ اﻟﻤﺸﺮوع ﺑﺸﻜﻞ ﺗﺎم ﻗﺒﻞ اﻟﺒﺪأ ﻓﻲ‬
‫اﻟﺘﺼﻤﯿﻢ‪ ،‬وﻛﻤﺎ وﺿﺤﻨﺎ ﻓﺈن ھﺬه اﻟﻤﺮﺣﻠﺔ ﻗﺪ ﺗﺘﻄﻠﺐ وﻗﺖ ﻃﻮﻳﻞ ﻓﻲ ﺑﻌﺾ اﻟﻤﺸﺎرﻳﻊ وﻗﺪ ﺗﻤﺮ ﻋﺪة ﺳﻨﻮات ﻗﺒﻞ‬
‫أن ﻳﺮى اﻟﺒﺮﻧﺎﻣﺞ اﻟﻨﮫﺎﺋﻲ اﻟﻨﻮر‪ ،‬وﻟﻜﻦ ھﻞ ﻳﻤﻜﻦ ﻟﺴﻮق اﻟﻌﻤﻞ اﻻﻧﺘﻈﺎر ﻛﻞ ھﺬا اﻟﻮﻗﺖ؟!‬

‫اﻻﺟﺎﺑﺔ ﺑﺎﻟﻄﺒﻊ ﻻ‪.‬‬

‫ﻟﺬا ﻛﺎن ﻻﺑﺪ ﻣﻦ اﻳﺠﺎد ﻃﺮق آﺧﺮى ﻟﺘﻘﻠﯿﻞ زﻣﻦ ﺗﻄﻮﻳﺮ اﻟﻤﺸﺮوع ‪ Cycle time.‬أﺣﺪ ھﺬه اﻟﻄﺮق ھﻲ اﻟﺘﻄﻮﻳﺮ‬
‫ﻋﻠﻰ ﻣﺮاﺣﻞ ‪ Phased Development‬ﺣﯿﺚ ﻳﺘﻢ ﺗﻄﻮﻳﺮ اﻟﻨﻈﺎم ﻋﻠﻰ ﻋﺪة ﻣﺮاﺣﻞ‪ ،‬ﺑﺘﻘﺪﻳﻢ إﺻﺪار ﻣﻦ اﻟﺒﺮﻧﺎﻣﺞ ﺑﻪ‬
‫ﺑﻌﺾ اﻟﻮﻇﺎﺋﻒ ﻟﻠﻌﻤﯿﻞ واﻟﻌﻤﻞ ﻋﻠﻰ ﺗﻄﻮﻳﺮ اﻻﺻﺪار اﻻﺣﻖ اﻟﺬي ﺳﻮف ﻳﻘﺪم ﻟﻪ ﺑﻘﯿﺔ اﻟﻮﻇﺎﺋﻒ‪.‬‬

‫ﻳﻮﺟﺪ ﻋﺪة ﻃﺮق ﻳﻤﻜﻦ ﺑﮫﺎ ﺗﻨﻈﯿﻢ ﻋﻤﻠﯿﺔ ﺗﻄﻮﻳﺮ إﺻﺪارات اﻟﺒﺮﻧﺎﻣﺞ‪ ،‬وﻣﻦ اﺷﮫﺮھﺎ‪:‬‬
‫·اﻟﻨﻤﻮذج اﻟﺘﺰاﻳﺪي‪Incremental model‬‬

‫‪11‬‬
 ‫ﺣﯿﺚ ﻳﺘﻢ ﺗﻘﺴﯿﻢ اﻟﻨﻈﺎم اﻟﻤﻄﻠﻮب ﺗﻄﻮﻳﺮه إﻟﻰ ﻋﺪة اﺟﺰاء ﺣﺴﺐ اﻟﻮﻇﺎﺋﻒ اﻟﺘﻲ ﻳﻌﺘﯿﻦ ﻋﻠﯿﻪ اﻟﻘﯿﺎم ﺑﮫﺎ‪ ،‬ﻳﺒﺪأ‬
‫أول إﺻﺪار ﺑﺄﺣﺪ ﺗﻠﻚ اﻻﺟﺰاء وﻣﻊ اﻟﻮﻗﺖ ﻳﺘﻢ إﺿﺎﻓﺔ اﻟﻤﺰﻳﺪ ﻣﻦ اﻻﺟﺰاء )اﻟﻮﻇﺎﺋﻒ( ﺣﺘﻰ ﻳﺘﻢ اﻻﻧﺘﮫﺎء ﻣﻦ ﺗﻄﻮﻳﺮ‬
‫اﻟﻨﻈﺎم ﺑﺸﻜﻞ ﺗﺎم وﺣﺴﺐ ﻣﺘﻄﻠﺒﺎت اﻟﻌﻤﯿﻞ‪.‬‬

‫·اﻟﻨﻤﻮذج اﻟﺘﻜﺮاري‪Iterative model‬‬

‫ھﺬه اﻟﻤﺮة ﻳﺘﻢ ﺗﺴﻠﯿﻢ ﺑﺮﻧﺎﻣﺞ ﺑﻜﺎﻣﻞ اﻟﻮﻇﺎﺋﻒ ﻣﻦ أول ﻣﺮة‪ ،‬وﻟﻜﻦ ﻳﺘﻢ ﺗﻌﺪﻳﻞ وﺗﻐﯿﯿﺮ ﺑﻌﺾ ﺗﻠﻚ اﻟﻮﻇﺎﺋﻒ ﻣﻊ ﻛﻞ‬
‫إﺻﺪار ﻣﻦ اﻟﺒﺮﻧﺎﻣﺞ‪.‬‬

‫ﻣﻦ ﻣﻤﯿﺰات ھﺬا اﻷﺳﻠﻮب أﻧﻪ ﻳﻤﻜﻦ اﻟﻤﻄﻮرﻳﻦ ﻣﻦ اﻟﺤﺼﻮل ﻋﻠﻰ ﻣﻼﺣﻈﺎت وﺗﻘﯿﯿﻢ اﻟﺰﺑﻮن ﻣﺒﻜﺮا و ﺑﺼﻮرة‬
‫ﻣﻨﺘﻈﻤﺔ‪ ،‬ورﺻﺪ اﻟﺼﻌﻮﺑﺎت اﻟﻤﺤﺘﻤﻠﺔ ﻗﺒﻞ اﻟﺘﻤﺎدي ﺑﻌﯿﺪا ﻓﻲ ﻋﻤﻠﯿﺎت اﻟﺘﻄﻮﻳﺮ‪.‬ﻛﻢ أﻧﻪ ﻳﻤّﻜﻦ ﻣﻦ اﻛﺘﺸﺎف ﻣﺪى‬
‫ﺣﺠﻢ و ﺗﻌﻘﯿﺪ اﻟﻌﻤﻞ ﻣﺒﻜﺮا‪.‬‬

‫اﻟﻨﻤﻮذج اﻟﻠﻮﻟﺒﻲ‪Spiral Model‬‬

‫وھﻮ ﺷﺒﯿﻪ ﻟﺪرﺟﺔ ﻛﺒﯿﺮة إﻟﻰ اﻟﻨﻤﻮذج اﻟﺘﺰاﻳﺪي واﻟﺘﻜﺮاري‪ ،‬وﻟﻜﻦ ﻓﯿﻪ ﻳﺘﻢ دﻣﺞ ﻓﻌﺎﻟﯿﺎت اﻟﺘﻄﻮﻳﺮ ﻣﻊ إدارة اﻟﻤﺨﺎﻃﺮ‬
‫‪risk‬ﻣﻦ إﺟﻞ اﻟﺘﺤﻜﻢ ﺑﮫﺎ وﺗﻘﻠﯿﻠﮫﺎ‪.‬‬
‫ﻳﺒﺪأ اﻟﻨﻤﻮذج اﻟﻠﻮﻟﺒﻲ ﺑﻤﺘﻄﻠﺒﺎت اﻟﻌﻤﯿﻞ ﻣﻊ ﺧﻄﺔ اﻟﻌﻤﻞ اﻟﻤﺒﺪﺋﯿﺔ )اﻟﻤﯿﺰاﻧﯿﺔ‪ ،‬ﻗﯿﻮد اﻟﻨﻈﺎم‪ ،‬واﻟﺒﺪاﺋﻞ اﻟﻤﺘﺎﺣﺔ(‪ .‬ﺛﻢ‬
‫ﻳﺘﻘﺪم ﺧﻄﻮة إﻟﻰ اﻻﻣﺎم ﺑﺘﻘﺪﻳﺮ اﻟﻤﺨﺎﻃﺮ وﺗﻤﺜﯿﻞ اﻟﺒﺪاﺋﻞ اﻟﻤﺘﺎﺣﺔ ﻗﺒﻞ ﺗﻘﺪﻳﻢ ﻣﺎ ﻳﻌﺮف ﺑـ "وﺛﯿﻘﺔ اﻟﻌﻤﻠﯿﺎت "‬
‫‪Concept of Operations‬اﻟﺘﻲ ﺗﺼﻒ وﺑﺸﻜﻞ ﻋﺎم )ﺑﺪون اﻟﺪﺧﻮل ﻓﻲ اﻟﺘﻔﺎﺻﯿﻞ( ﻛﯿﻒ ﻳﺠﺐ ﻋﻠﻰ اﻟﻨﻈﺎم أن‬
‫ﻳﻌﻤﻞ‪ .‬ﺑﻌﺪھﺎ ﻳﺘﻢ ﺗﺤﺪﻳﺪ وﺗﺪﻗﯿﻖ اﻟﻤﺘﻄﻠﺒﺎت ﻟﻠﺘﺄﻛﺪ ﻣﻦ أﻧﮫﺎ ﺗﺎﻣﺔ ودﻗﯿﻘﺔ إﻟﻰ أﻗﺼﻰ ﺣﺪ ﻣﻤﻜﻦ‪.‬‬
‫ﺑﺬﻟﻚ ﺗﻜﻮن وﺛﯿﻘﺔ اﻟﻌﻤﻠﯿﺎت ھﻲ اﻟﻤﻨﺘﺞ ﻣﻦ اﻟﻄﻮر اﻷول‪ ،‬و اﻟﻤﺘﻄﻠﺒﺎت ھﻲ اﻟﻤﻨﺘﺞ اﻻﺳﺎﺳﻲ ﻣﻦ اﻟﻄﻮر اﻟﺜﺎﻧﻲ‪.‬‬
‫وﻓﻲ اﻟﻄﻮر اﻟﺜﺎﻟﺚ ﺗﺘﻢ ﻋﻤﻠﯿﺔ اﻟﺘﺼﻤﯿﻢ‪ ،‬أﻣﺎ اﻻﺧﺘﺒﺎر ﻓﯿﺘﻢ ﺧﻼل اﻟﻄﻮر اﻟﺮاﺑﻊ‪.‬‬
‫ﻓﻲ ﻛﻞ ﻃﻮر أو ﻣﺮﺣﻠﺔ ﻳﺴﺎﻋﺪ ﺗﺤﻠﯿﻞ اﻟﻤﺨﺎﻃﺮ ﻋﻠﻰ ﺗﻘﺪﻳﺮ اﻟﺒﺪاﺋﻞ اﻟﻤﺨﺘﻠﻔﺔ ﻓﻲ ﺿﻮء ﻣﺘﻄﻠﺒﺎت وﻗﯿﻮد اﻟﻨﻈﺎم‪،‬‬
‫وﺗﺴﺎﻋﺪ اﻟﻨﻤﺬﺟﺔ ﻋﻠﻰ اﻟﺘﺤﻘﻖ ﻣﻦ ﻣﻼﺋﻤﺔ أي ﺑﺪﻳﻞ ﻗﺒﻞ أﻋﺘﻤﺎده‪.‬‬

‫‪12‬‬
 ‫ﺷﻜﻞ )‪(2-2‬‬

‫( •·‪•·.·´¯`·.‬ﻧﮫﺎﻳﺔ اﻟﺪرس اﻟﺜﺎﻧﻲ•·‪) •·.·´¯`·.‬‬

‫‪13‬‬
 ‫( •·‪•·.·´¯`·.‬ﻧﻘﺎش اﻟﺪرس اﻟﺜﺎﻧﻲ•·‪) •·.·´¯`·.‬‬

‫ﻟﻲ ﻣﻼﺣﻈﻪ و ھﻲ ﻓﻲ اﻟـ‪WaterFall Model ..‬‬

‫ھﻞ ﻣﻦ اﻟﻤﻤﻜﻦ أن ﻳﻜﻮن ھﻨﺎك ‪ back track‬ﻣﻦ ‪ Phase‬ﻷﺧﺮ و ﻛﻠﻤﺎ ﻛﺎن ھﺬا اﻟﺮﺟﻮع أﻛﺒﺮ ﻛﻠﻤﺎ ﻛﺎن ﻣﻜﻠﻒ أﻛﺜﺮ‬
‫ﻣﻦ ﻧﺎﺣﯿﺔ اﻟﻮﻗﺖ و اﻟﺘﻌﺪﻳﻞ و اﻟﻤﺎل ؟؟‬

‫ﻧﻌﻢ ﻣﻦ اﻟﻤﻤﻜﻦ أن ﻳﻜﻮن ھﻨﺎك ‪ back track‬ﻣﻦ ‪Phase‬‬

‫وﻏﺎﻟﺒﺎ ﻣﺎ ﻳﻜﻮن ھﺬا ﻣﺎ ﻳﺤﺼﻞ ﺑﺎﻟﻔﻌﻞ ﻋﻨﺪ اﻟﺘﻄﺒﯿﻖ اﻟﻌﻤﻠﻲ‪...‬‬

‫اﻟـ ‪ backtrack‬ﻣﻤﻜﻦ ﻳﺤﺪث ﻓﻲ ﺟﻤﯿﻊ اﻟـ ‪ models‬وﻟﯿﺲ ھﺬا ﻓﻘﻂ ‪ ..‬ﻓﺒﻌﺪ ﻛﻞ ﻣﺮﺣﻠﺔ ﻣﻤﻜﻦ ﻳُﻜﺘﺸﻒ أن ﻧﺎﺗﺞ‬
‫أﺣﺪ اﻟﻤﺮاﺣﻞ اﻟﺴﺎﺑﻘﺔ ﻟﻢ ﻳﻜﻦ ﺻﺤﯿﺢ وﻳﺤﺘﺎج إﻟﻰ ﺗﻌﺪﻳﻞ‬
‫وھﺬا ﻣﺎ ﻳﺠﻌﻞ أﻧﻤﺎط آﺧﺮى ﻛﺎﻟﻨﻤﻂ اﻟﻠﻮﻟﺒﻲ أﻛﺜﺮ ﺗﻔﻀﯿﻼ‪.‬‬

‫ﺻﻮرة ﻟﻠـ ‪ backtrack‬ﺑﺎﻟﻨﺴﺒﺔ ﻟﻠـ‪Waterfall Model‬‬

‫‪14‬‬
 ‫اﻟﺪرس اﻟﺜﺎﻟﺚ‪ :‬دراﺳﺔ اﻟﻤﺘﻄﻠﺒﺎت‬

‫ﻓﻲ ھﺬا اﻟﺪرس ﺳﻮف ﻧﺒﺪأ ﻓﻲ دراﺳﺔ أول )وﻟﻌﻠﮫﺎ أھﻢ( ﺧﻄﻮة ﻓﻲ ﺗﻄﻮﻳﺮ اﻟﺒﺮاﻣﺞ وھﻲ ﺗﺤﺪﻳﺪ ﻣﺘﻄﻠﺒﺎت‬
‫اﻟﻨﻈﺎم ‪Capturing the requirements.‬‬

‫اﻟﮫﺪف ﻣﻦ ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت ھﻮ ﻓﮫﻢ ﻣﺎ ﻳﺘﻮﻗﻌﻪ اﻟﻌﻤﯿﻞ واﻟﻤﺴﺘﺨﺪم ﻣﻦ اﻟﻨﻈﺎم )ﻣﺎ اﻟﺬي ﻳﻤﻜﻦ ﻟﻠﻨﻈﺎم أداؤه‬
‫وﻣﺎ ﻻ ﻳﻤﻜﻨﻪ أداؤه(‪.‬ﻓﻘﺪ ﻳﻜﻮن اﻟﻨﻈﺎم اﻟﻤﻄﻠﻮب ﺗﺼﻤﯿﻤﻪ ﺑﺪﻳﻞ ﻟﻨﻈﺎم أو ﻟﻄﺮﻳﻘﺔ ﻣﺴﺘﺨﺪﻣﺔ ﻷداء ﻣﮫﻤﺔ ﻣﺤﺪدة‪،‬‬
‫أو ﻣﻤﻜﻦ أن ﻳﻜﻮن ﻧﻈﺎم ﺟﺪﻳﺪ ﻳﻘﺪم ﺧﺪﻣﺔ ﺟﺪﻳﺪة ﻟﻢ ﻳﺴﺒﻖ ﺗﻘﺪﻳﻤﮫﺎ ﻣﻦ ﻗﺒﻞ‪ .‬ﻓﻠﻜﻞ ﻧﻈﺎم ﺑﺮﻣﺠﻲ وﻇﯿﻔﺔ‬
‫ﻣﻌﯿﻨﺔ‪ ،‬ﺗﺤﺪد ﺑﻤﺎ ﻳﻤﻜﻦ ﻟﻪ أن ﻳﻘﻮم ﺑﻪ ﻣﻦ أﺟﻞ أداء ﺗﻠﻚ اﻟﻮﻇﯿﻔﺔ‪.‬‬

‫اﻟﻤﺘﻄﻠﺒﺎت ‪:‬ھﻲ ﺗﻌﺮﻳﻒ ﻟﺸﻜﻞ اﻟﻨﻈﺎم أو وﺻﻒ ﻟﻤﺎ ﻳﺴﺘﻄﯿﻊ ھﺬا اﻟﻨﻈﺎم أن ﻳﻘﻮم ﺑﻪ ﻷداء وﻇﯿﻔﺘﻪ اﻟﺘﻲ‬
‫ﺳﯿﺼﻤﻢ ﻣﻦ أﺟﻠﮫﺎ‪.‬‬

‫ﺧﻄﻮات ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت ‪:‬‬

‫أوﻻ‪ :‬اﻻﺟﺘﻤﺎع ﻣﻊ اﻟﻌﻤﯿﻞ ﻟﻠﺘﻌﺮف ﻋﻠﻰ اﻟﻤﺘﻄﻠﺒﺎت‪:‬‬

‫وھﺬه ﺧﻄﻮة ھﺎﻣﺔ ﺟﺪا إذ أن ﺑﻘﯿﺔ اﻟﺨﻄﻮات اﻟﺘﺎﻟﯿﺔ ﺗﻌﺘﻤﺪ ﻋﻠﯿﮫﺎ ﺑﺸﻜﻞ أﺳﺎﺳﻲ‪ .‬ﻟﺬا ﻳﺠﺐ ﻋﻠﯿﻨﺎ أن ﻧﺴﺘﺨﺪم‬
‫ﻛﺎﻓﺔ اﻟﺘﻘﻨﯿﺎت اﻟﻤﺘﺎﺣﺔ ﻟﻨﻜﺘﺸﻒ ﻣﺎ اﻟﺬي ﻳﻄﻠﺒﻪ اﻟﻌﻤﯿﻞ واﻟﻤﺴﺘﺨﺪم‪ ،‬ﻧﺒﺪأ ﺑﻔﮫﻢ وﺗﺤﻠﯿﻞ اﻟﻤﺸﻜﻠﺔ اﻟﺘﻲ ﺗﻮاﺟﻪ‬
‫اﻟﻤﺴﺘﺨﺪم ﺑﻜﻞ أﺑﻌﺎدھﺎ‪ ،‬ﻧﺘﻌﺮف ﻋﻠﻰ اﻟﻌﻤﻠﯿﺎت واﻟﻤﺼﺎدر اﻟﺘﻲ ﺗﺘﻀﻤﻨﮫﺎ اﻟﻤﺸﻜﻠﺔ واﻟﻌﻼﻗﺎت اﻟﺘﻲ ﺗﺮﺑﻄﮫﺎ ﻣﻌﺎ و‬
‫ﻧﺤﺪد ﺣﺪود اﻟﻨﻈﺎم‪ .‬وھﺬا ﻳﻤﻜﻦ أن ﻳﺘﻢ ﻣﻦ ﺧﻼل‪:‬‬

‫ﻃﺮح اﻷﺳﺌﻠﺔ ﻋﻠﻰ اﻟﻌﻤﯿﻞ‪ ،‬وﻣﻦ اﻟﻤﻔﯿﺪ أﺣﯿﺎﻧﺎ أن ﻧﻄﺮح ﻧﻔﺲ اﻟﺴﺆال وﻟﻜﻦ ﺑﺄﺳﻠﻮب ﻣﺨﺘﻠﻒ أﻛﺜﺮ ﻣﻦ‬ ‫•‬
‫ﻣﺮة ﻓﮫﺬا ﻳﺴﺎﻋﺪﻧﺎ ﻋﻠﻰ اﻟﺘﺄﻛﺪ ﻣﻦ أﻧﻨﺎ ﻧﻔﮫﻢ ﻣﺎ ﻳﻘﺼﺪه اﻟﻌﻤﯿﻞ ﺑﺎﻟﺘﺤﺪﻳﺪ‪.‬‬
‫ﻋﺮض ﻧﻈﻢ ﻣﺸﺎﺑﻪ ﻟﻠﻨﻈﺎم اﻟﻤﻄﻠﻮب ﺳﺒﻖ ﺗﺼﻤﯿﻤﮫﺎ ﻣﻦ ﻗﺒﻞ‪.‬‬ ‫•‬
‫ﺗﺼﻤﯿﻢ وﻋﺮض ﻧﻤﺎذج ﻷﺟﺰاء ﻣﻦ اﻟﻨﻈﺎم اﻟﻤﻄﻠﻮب أو ﻟﻠﻨﻈﺎم ﺑﺎﻟﻜﺎﻣﻞ‪.‬‬ ‫•‬

‫ﺗﻘﺴﻢ اﻟﻤﺘﻄﻠﺒﺎت إﻟﻰ ﻋﺪة ﻋﻨﺎﺻﺮ ﺗﺸﻤﻞ‪:‬‬

‫اﻟﺒﯿﺌﺔ اﻟﻤﺤﯿﻄﺔ ﺑﺎﻟﻨﻈﺎم‪Physical Environment‬‬ ‫•‬

‫وﺟﮫﺎت اﻻﺳﺘﺨﺪام‪Interfaces‬‬ ‫•‬
‫اﻟﻤﺴﺘﺨﺪﻣﯿﻦ وإﻣﻜﺎﻧﺎﺗﮫﻢ‪Users and human factors‬‬ ‫•‬
‫وﻇﺎﺋﻒ اﻟﻨﻈﺎم‪Functionality‬‬ ‫•‬
‫اﻟﺘﻮﺛﯿﻖ‪Documentation‬‬ ‫•‬
‫اﻟﺒﯿﺎﻧﺎت‪Data‬‬ ‫•‬
‫اﻟﻤﺼﺎدر‪Resources‬‬ ‫•‬
‫اﻷﻣﻦ‪Security‬‬ ‫•‬
‫ﺿﻤﺎن اﻟﺠﻮدة‪Quality Assurance‬‬ ‫•‬

‫وﻳﺠﺐ اﻟﺘﺄﻛﺪ ﻣﻦ أن ﻧﻨﺎﻗﺶ ﺟﻤﯿﻊ ھﺬه اﻟﻌﻨﺎﺻﺮ‬

‫ﺛﺎﻧﯿﺎ‪ :‬ﺗﺴﺠﯿﻞ ھﺬه اﻟﻤﺘﻄﻠﺒﺎت ﻓﻲ وﺛﺎﺋﻖ أو ﻗﺎﻋﺪة ﺑﯿﺎﻧﺎت‪ ،‬وﻋﺮﺿﮫﺎ ﻋﻠﻰ اﻟﻌﻤﯿﻞ ﻟﯿﻮاﻓﻖ ﻋﻠﯿﮫﺎ ﺑﺎﻋﺘﺒﺎر أﻧﮫﺎ ﻣﺎ‬
‫ﻳﻄﻠﺒﻪ ﺑﺎﻟﻔﻌﻞ‬
‫اﻟﻤﺘﻄﻠﺒﺎت ﻻ ﺗﺼﻒ ﻓﻘﻂ ﺗﺪﻓﻖ اﻟﺒﯿﺎﻧﺎت واﻟﻤﻌﻠﻮﻣﺎت ﻣﻦ وإﻟﻰ اﻟﻨﻈﺎم‪ ،‬وأﻣﺎ ﺗﺼﻒ ﻛﺬﻟﻚ اﻟﻘﯿﻮد اﻟﻤﻔﺮوﺿﺔ ﻋﻠﻰ‬
‫ﻋﻤﻞ اﻟﻨﻈﺎم‪ .‬وﺑﺬﻟﻚ ﻓﺈن ﻋﻤﻠﯿﺔ ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت ﺗﺨﺪم ﺛﻼﺛﺔ أﻏﺮاض‪:‬‬

‫‪15‬‬
 ‫أوﻻ ﺗﻤﻜﻦ اﻟﻤﻄﻮرﻳﻦ ﻣﻦ ﺷﺮح ﻓﮫﻤﮫﻢ ﻟﻠﻄﺮﻳﻘﺔ اﻟﺘﻲ ﻳﻮد اﻟﻤﺴﺘﺨﺪﻣﯿﻦ أن ﻳﻌﻤﻞ ﺑﮫﺎ اﻟﻨﻈﺎم‪.‬‬ ‫•‬
‫ﺛﺎﻧﯿﺎ ﺗﻮﺿﺢ ﻟﻠﻤﺼﻤﻤﯿﻦ ﻣﺎھﯿﺔ اﻟﻮﻇﺎﺋﻒ واﻟﺨﺼﺎﺋﺺ اﻟﺘﻲ ﺳﯿﻤﺘﺎز ﺑﮫﺎ اﻟﻨﻈﺎم ‪,‬‬ ‫•‬
‫وﺛﺎﻟﺜﺎ‪ :‬ﺗﻮﺿﺢ اﻟﻤﺘﻄﻠﺒﺎت ﻟﻔﺮﻳﻖ اﻻﺧﺘﺒﺎر ﻣﺎ اﻟﺬي ﻳﺠﺐ إﺛﺒﺎﺗﻪ ﻹﻗﻨﺎع اﻟﺰﺑﻮن أن اﻟﻨﻈﺎم اﻟﺬي ﺗﻢ ﺗﻄﻮﻳﺮه‬ ‫•‬
‫ھﻮ ﻣﺎ ﺳﺒﻖ أن ﻃﻠﺒﻪ ﺑﺎﻟﻀﺒﻂ ‪.‬‬

‫ﻟﺬﻟﻚ وﻟﻀﻤﺎن أن ﻛﻼ ﻣﻦ اﻟﻤﻄﻮرﻳﻦ واﻟﺰﺑﻮن ﻣﺘﻔﺎھﻤﻮن ﺗﻤﺎﻣﺎ ﻋﻠﻰ ﻣﺎ ﻳﺠﺐ اﻟﻘﯿﺎم ﺑﻪ‪ ،‬ﻓﺈن اﻟﻤﺘﻄﻠﺒﺎت اﻟﻤﺴﺠﻠﺔ‬
‫ﺣﺘﻰ ھﺬه اﻟﺨﻄﻮة ﻳﺠﺐ أن ﺗﻜﻮن ﻟﮫﺎ اﻟﺼﻔﺎت اﻟﺘﺎﻟﯿﺔ‪:‬‬
‫‪1.‬أن ﺗﻜﻮن ﺻﺤﯿﺤﺔ ‪ Correct‬وﺧﺎﻟﯿﺔ ﻣﻦ اﻷﺧﻄﺎء‪.‬‬
‫‪2.‬أن ﺗﻜﻮن ﺛﺎﺑﺘﺔ ‪ consistent‬ﺑﻤﻌﻨﻰ أن ﻻ ﻳﻜﻮن ھﻨﺎك أي ﺗﻌﺎرض ﺑﯿﻦ ﻣﺘﻄﻠﺐ وآﺧﺮ‪.‬‬
‫‪3.‬أن ﺗﻜﻮن ﺗﺎﻣﺔ ‪ Complete‬ﻳﺠﺐ أن ﻳﺘﻢ ذﻛﺮ ﺟﻤﯿﻊ اﻟﺤﺎﻻت اﻟﻤﺤﺘﻤﻠﺔ ﻟﻠﻨﻈﺎم‪ ،‬اﻟﻤﺪﺧﻼت‪ ،‬اﻟﻤﺨﺮﺟﺎت اﻟﻤﺘﻮﻗﻌﺔ‬
‫ﻣﻨﻪ‪... ،‬اﻟﺦ ‪.‬‬
‫‪4.‬أن ﺗﻜﻮن واﻗﻌﯿﺔ ‪ realistic‬ﺑﻤﻌﻨﻰ أن ﺗﻜﻮن ﻗﺎﺑﻠﺔ ﻟﻠﺘﻄﺒﯿﻖ ﻓﻲ اﻟﻮاﻗﻊ‪.‬‬
‫‪5.‬أن ﺗﻜﻮن ﻣﺘﻌﻠﻘﺔ ﺑﺄﻣﻮر ﺿﺮورة ﻟﻠﻌﻤﯿﻞ‪ ،‬وﻳﺘﻄﻠﺒﮫﺎ اﻟﻨﻈﺎم‪.‬‬
‫‪6.‬أن ﻳﻜﻮن ﻣﻦ اﻟﻤﻤﻜﻦ اﻟﺘﺤﻘﻖ ﻣﻨﮫﺎ‪verifiable‬‬
‫‪7.‬أن ﺗﻜﻮن ﻗﺎﺑﻠﺔ ﻟﻠﺘﺘﺒﻊ‪traceable‬‬
‫ﻳﻄﻠﻖ ﻋﻠﻰ ھﺬه اﻟﻮﺛﺎﺋﻖ "وﺛﺎﺋﻖ ﺗﻌﺮﻳﻒ اﻟﻤﺘﻄﻠﺒﺎت ‪" Requirement Definition Document‬‬

‫ﺛﺎﻟﺜﺎ‪ :‬إﻋﺎدة ﺗﺴﺠﯿﻞ اﻟﻤﺘﻄﻠﺒﺎت ﺑﺸﻜﻞ رﻳﺎﺿﻲ ‪ mathematical‬ﻟﯿﻘﻮم اﻟﻤﺼﻤﻤﻮن ﺑﺘﺤﻮﻳﻞ ﺗﻠﻚ اﻟﻤﺘﻄﻠﺒﺎت إﻟﻰ‬
‫ﺗﺼﻤﯿﻢ ﺟﯿﺪ ﻟﻠﻨﻈﺎم ﻓﻲ ﻣﺮﺣﻠﺔ اﻟﺘﺼﻤﯿﻢ‪.‬‬
‫ﻟﺴﻨﻮات ﻋﺪﻳﺪة ﻛﺎن ﻳﺘﻢ اﻻﻛﺘﻔﺎء ﺑﻮﺛﯿﻘﺔ ﺗﻌﺮﻳﻒ اﻟﻤﺘﻄﻠﺒﺎت )اﻟﺘﻲ ﺗﺤﺪﺛﻨﺎ ﻋﻨﮫﺎ ﻗﺒﻞ ﻗﻠﯿﻞ( واﻟﺘﻲ ﺗﻜﺘﺐ‬
‫ﺑﺎﺳﺘﻌﻤﺎل اﻟﻠﻐﺔ اﻟﻄﺒﯿﻌﯿﺔ( ﻟﻐﺔ اﻟﺒﺸﺮ( ﻟﻮﺻﻒ وﺗﺴﺠﯿﻞ ﻣﺘﻄﻠﺒﺎت اﻟﻨﻈﻢ ﺑﺤﯿﺚ ﻳﻤﻜﻦ ﻟﻠﻌﻤﯿﻞ أن ﻳﻔﮫﻢ ﻛﻞ‬
‫ﻛﻠﻤﺔ ﻣﻮﺟﻮدة ﺑﮫﺎ‪ ،‬إﻻ أن ذﻟﻚ ﻳﺴﺒﺐ اﻟﻌﺪﻳﺪ ﻣﻦ اﻟﻤﺸﺎﻛﻞ واﻟﺘﻲ ﻳﻌﻮد ﺳﺒﺒﮫﺎ ﻓﻲ أﻏﻠﺐ اﻷﺣﯿﺎن إﻟﻰ ﺳﻮء‬
‫ﺗﻔﺴﯿﺮ ﺑﻌﺾ اﻟﺘﻌﺒﯿﺮات ﻟﻠﻤﺴﺘﺨﺪﻣﯿﻦ ﻣﻦ ﻗﺒﻞ اﻟﻤﺼﻤﻢ أو اﻟﻌﻜﺲ‪ ،‬ﻓﻌﻠﻰ ﺳﺒﯿﻞ اﻟﻤﺜﺎل ﻗﺪ ﻳﻄﻠﻖ اﻟﻤﺴﺘﺨﺪم‬
‫ﻋﻠﻰ اﻟﻨﻈﺎم اﻟﺘﻌﺒﯿﺮ )ﻣﺘﻮﻗﻒ ﻋﻦ اﻟﻌﻤﻞ( إذا ﻛﺎن اﻟﻨﻈﺎم ﻣﺸﻐﻮل ﺑﻌﻤﻠﯿﺔ ﺗﺴﺠﯿﻞ اﺣﺘﯿﺎﻃﻲ ‪ backup‬ﺑﺎﻋﺘﺒﺎر أن‬
‫ﻻ ﻳﺴﺘﺠﯿﺐ ﻷواﻣﺮ اﻟﻤﺴﺘﺨﺪم ﻓﻲ ھﺬه اﻟﺤﺎﻟﺔ‪ ،‬ﺑﯿﻨﻤﺎ ﻳﻌﺘﺒﺮ اﻟﻤﺼﻤﻢ أن اﻟﻨﻈﺎم ﻓﻲ ھﺬه اﻟﺤﺎﻟﺔ )ﻣﺴﺘﻤﺮ ﻓﻲ‬
‫اﻟﻌﻤﻞ( ﻷﻧﻪ ﻳﻘﻮم ﺑﻤﮫﻤﺔ أﺳﺎﺳﯿﺔ!‬
‫ﻟﺬا ﻓﺄن اﻻﻋﺘﻤﺎد ﻋﻠﻰ اﻟﻠﻐﺔ اﻟﺒﺸﺮﻳﺔ ﺑﺸﻜﻞ ﺗﺎم ﻗﺪ ﻳﺆدي إﻟﻰ أﺧﻄﺎء ﻛﺜﯿﺮة ﻋﻨﺪ ﺗﺼﻤﯿﻢ اﻟﻨﻈﺎم‪ ،‬وﻳﻨﺘﺞ ﻋﻨﮫﺎ‬
‫ﻧﻈﺎم ﻻ ﻳﻘﺒﻠﻪ اﻟﻌﻤﯿﻞ ﻷﻧﻪ ﻻ ﻳﻠﺒﻲ ﻣﺘﻄﻠﺒﺎﺗﻪ اﻟﺘﻲ ﺣﺪدھﺎ ﻣﻦ ﻗﺒﻞ‪ ،‬ﻟﺬﻟﻚ ﻳﺘﻢ ﻛﺘﺎﺑﺔ ﻧﻮع ﺛﺎﻧﻲ ﻣﻦ اﻟﻮﺛﺎﺋﻖ‬
‫ﺗﺴﻤﻰ "وﺛﺎﺋﻖ ﻣﻮاﺻﻔﺎت اﻟﻤﺘﻄﻠﺒﺎت ‪" Requirement specification Document‬وھﻲ ﺗﻜﺘﺐ ﺑﺎﺳﺘﻌﻤﺎل وﺳﺎﺋﻞ‬
‫وﻃﺮق ﺧﺎﺻﺔ اﺑﺘﻜﺮھﺎ ﻣﮫﻨﺪﺳﻮ اﻟﺒﺮﻣﺠﯿﺎت ﻟﻜﺘﺎﺑﺔ اﻟﻤﺘﻄﻠﺒﺎت ﺑﺎﺳﻠﻮب ﺗﻘﻨﻲ ﺑﺤﺖ‪ .‬ﻣﻨﮫﺎ ﻋﻠﻰ ﺳﺒﯿﻞ اﻟﻤﺜﺎل‪ :‬ﻟﻐﺔ‬
‫اﻟﻨﻤﺬﺟﺔ اﻟﻤﻮﺣﺪة ‪ UML Unified Modeling Language‬و ھﻲ ﻟﻐﺔ ﻧﻤﺬﺟﺔ رﺳﻮﻣﯿﺔ ﺗﻘﺪم ﻟﻨﺎ ﺻﯿﻐﺔ ﻟﻮﺻﻒ‬
‫اﻟﻌﻨﺎﺻﺮ اﻟﺮﺋﯿﺴﯿﺔ ﻟﻠﻨﻈﻢ اﻟﺒﺮﻣﺠﯿﺔ‪.‬‬
‫اﻟﺸﻜﻞ اﻟﺘﺎﻟﻲ ﻳﻌﺮض ﻣﺜﺎل ﻋﻠﻰ اﺳﺘﻌﻤﺎل‪UML‬‬

‫‪16‬‬
 ‫راﺑﻌﺎ‪ :‬اﻟﺘﺜﺒﺖ واﻟﺘﺤﻘﻖ ﻣﻦ اﻟﻤﺘﻄﻠﺒﺎت اﻟﺘﻲ ﺗﻢ ﺗﺴﺠﻠﯿﮫﺎ ﻓﻲ ﻛﻼ ﻣﻦ وﺛﯿﻘﺔ ﺗﻌﺮﻳﻒ اﻟﻤﺘﻄﻠﺒﺎت )واﻟﺘﻲ ﺗﻘﺪم‬
‫ﻟﻠﻌﻤﯿﻞ( ووﺛﯿﻘﺔ ﻣﻮاﺻﻔﺎت اﻟﻤﺘﻄﻠﺒﺎت )واﻟﺘﻲ ﺗﻘﺪم ﻟﻠﻤﺼﻤﻢ )ﻟﻠﺘﺄﻛﺪ ﻣﻦ ﺻﺤﺘﮫﻤﺎ وﺷﻤﻮﻟﯿﺘﮫﻤﺎ وأن ﻛﻼ ﻣﻨﮫﻤﺎ ﻻ‬
‫ﺗﻌﺎرض اﻟﺜﺎﻧﯿﺔ ﻓﻲ أي ﻧﻘﻄﺔ‪ ،‬وإﻻ ﻓﺈن اﻟﻨﺘﯿﺠﺔ ﺳﻮف ﺗﻜﻮن ﻧﻈﺎم ﻻ ﻳﻠﺒﻲ ﻃﻠﺒﺎت اﻟﻌﻤﯿﻞ‪!.‬‬

‫( •·‪•·.·´¯`·.‬ﻧﮫﺎﻳﺔ اﻟﺪرس اﻟﺜﺎﻟﺚ•·‪) •·.·´¯`·.‬‬

‫‪17‬‬
 ‫( •·‪•·.·´¯`·.‬ﻧﻘﺎش اﻟﺪرس اﻟﺜﺎﻟﺚ•·‪) •·.·´¯`·.‬‬

‫_________________أﻗﺘﺒﺎس__________________‬

‫أوﻻ‪ :‬اﻻﺟﺘﻤﺎع ﻣﻊ اﻟﻌﻤﯿﻞ ﻟﻠﺘﻌﺮف ﻋﻠﻰ اﻟﻤﺘﻄﻠﺒﺎت‪:‬‬

‫وھﺬه ﺧﻄﻮة ھﺎﻣﺔ ﺟﺪا إذ أن ﺑﻘﯿﺔ اﻟﺨﻄﻮات اﻟﺘﺎﻟﯿﺔ ﺗﻌﺘﻤﺪ ﻋﻠﯿﮫﺎ ﺑﺸﻜﻞ أﺳﺎﺳﻲ‪ .‬ﻟﺬا ﻳﺠﺐ ﻋﻠﯿﻨﺎ أن ﻧﺴﺘﺨﺪم‬
‫ﻛﺎﻓﺔ اﻟﺘﻘﻨﯿﺎت اﻟﻤﺘﺎﺣﺔ ﻟﻨﻜﺘﺸﻒ ﻣﺎ اﻟﺬي ﻳﻄﻠﺒﻪ اﻟﻌﻤﯿﻞ واﻟﻤﺴﺘﺨﺪم‪ .............،‬اﻟﺦ‬
‫اﺧﺮ ﺷﻲ ﻗﻠﺘﻲ" ‪ :‬وﻳﺠﺐ اﻟﺘﺄﻛﺪ ﻣﻦ أن ﻧﻨﺎﻗﺶ ﺟﻤﯿﻊ ھﺬه اﻟﻌﻨﺎﺻﺮ"‬
‫_________________________________________‬

‫ھﻞ ﺗﻘﺼﺪﻳﻦ اﻟﻨﻘﺎش ﻣﻊ اﻟﻌﻤﯿﻞ!!?‬

‫ﻧﻌﻢ ﻳﺠﺐ ﻣﻨﺎﻗﺸﺔ ﻛﻞ ﻧﻘﻄﺔ ﻣﻊ اﻟﻌﻤﯿﻞ ﻟﻠﺘﺄﻛﺪ ﻣﻦ اﻧﻨﺎ ﻓﮫﻤﻨﺎ ﻣﺎ ﻳﻘﺼﺪه ﺗﻤﺎﻣﺎ‪.‬‬

‫اﻟﺒﯿﺌﺔ اﻟﻤﺤﯿﻄﺔ ﺑﺎﻟﻨﻈﺎم‪Physical Environment ..‬‬

‫ﻟﻢ أﻗﮫﻢ ﻣﺎ ﺗﻘﺼﺪﻳﻦ ﺑﺎﻟﺒﯿﺌﺔ اﻟﻤﺤﯿﻄﺔ؟؟‬

‫ﻳﻘﺼﺪ ﺑﮫﺎ ﻛﻞ ﻣﺎ ﻳﺤﯿﻂ ﺑﺎﻟﻨﻈﺎم وﻟﯿﺲ ﻣﻦ ﻣﻜﻮﻧﺎﺗﻪ ﻣﺜﻼ اﻟﻤﻮﻗﻊ اﻟﺬي ﺳﯿﻌﻤﻞ ﺑﻪ اﻟﻨﻈﺎم‪ ،‬ھﻞ ھﻮ ﺛﺎﺑﺖ ﻓﻲ‬
‫ﻣﻮﻗﻊ واﺣﺪ أﻛﺜﺮ أو ﻳﻤﻜﻦ أن ﻳﺘﻢ ﻧﻘﻠﻪ إﻟﻰ ﻣﻮاﻗﻊ ﻣﺨﺘﻠﻔﺔ )ﻃﺒﻌﺎ اﻟﺤﺪﻳﺚ ﻳﺸﻤﻞ اﻟﻨﻈﺎم ﻛﺎﻣﻞ ‪Hardware +‬‬
‫)‪software‬‬

‫ﻧﺮﺑﺪ ﺗﻮﺿﯿﺢ او ﻣﺜﺎل ﻋﻦ ﺻﻔﺎت اﻟﻤﺘﻄﻠﺒﺎت اﻷﺗﯿﺔ ‪:‬‬

‫‪1.‬أن ﻳﻜﻮن ﻣﻦ اﻟﻤﻤﻜﻦ اﻟﺘﺤﻘﻖ ﻣﻨﮫﺎ‪verifiable‬‬

‫ﺑﻤﻌﻨﻰ أن ﺗﻜﺘﺐ اﻟﻤﺘﻄﻠﺒﺎت ﺑﺤﯿﺚ ﺗﻜﻮن ﻗﺎﺑﻠﺔ ﻟﻼﺧﺘﺒﺎر ﻟﻠﺘﺄﻛﺪ ﻣﻦ ﺗﺤﻘﻘﺖ‪ ،‬ﻓﻤﺜﻼ ﻗﺪ ﻳﺬﻛﺮ اﻟﻌﻤﯿﻞ أن ﻳﺮﻳﺪ ﻣﻦ‬
‫اﻟﻨﻈﺎم أن ﻳﻜﻮن ذا اﺳﺘﺠﺎﺑﺔ ﺳﺮﻳﻌﺔ!‬
‫ﻣﺎ ﻣﻘﺪار اﻟﺴﺮﻋﺔ اﻟﻤﻄﻠﻮب؟‬
‫ﻗﺪ ﻳﺮى اﻟﻤﺼﻤﻢ أن اﻻﻧﺘﻈﺎر ﻟﻤﺪة ‪ 50‬ﺛﺎﻧﯿﺔ ﻣﻨﺎﺳﺐ ﻛﺤﺪ أﻗﺼﻰ‪ ،‬ﺑﯿﻨﻤﺎ ﻳﺘﻮﻗﻊ اﻟﺰﺑﻮن زﻣﻦ اﻧﺘﻈﺎر ‪ 20‬ﺛﺎﻧﯿﺔ ﻛﺤﺪ‬
‫أﻗﺼﻰ!‬

‫‪ 2.‬أن ﺗﻜﻮن ﻗﺎﺑﻠﺔ ﻟﻠﺘﺘﺒﻊ‪traceable‬‬

‫ﺑﻤﻌﻨﻰ أن ﺗﻜﻮن اﻟﻤﺘﻄﻠﺒﺎت ﻣﻜﺘﻮﺑﺔ ﺑﺤﯿﺚ ﻳﺴﮫﻞ ﺗﺘﺒﻌﮫﺎ ﻟﻠﺘﺄﻛﺪ ﻣﻦ أن ﻛﻞ وﻇﯿﻔﺔ ﻣﻄﻠﻮﺑﺔ ﻣﻦ اﻟﻨﻈﺎم ﺗﻢ‬
‫اﺳﺘﯿﻔﺎﺋﮫﺎ ﻣﻦ ﺧﻼل اﻟﻤﺘﻄﻠﺒﺎت‪.‬‬

‫‪18‬‬
 ‫اﻟﺪرس اﻟﺮاﺑﻊ‪ :‬ﺗﺼﻤﯿﻢ اﻟﻨﻈﺎم‬

‫ﻧﻜﻤﻞ ﻣﻊ ﺧﻄﻮات ﺑﻨﺎء اﻟﻨﻈﺎم‪ ،‬وھﺬه اﻟﻤﺮة ﺳﻮف ﻧﺘﺤﺪث ﻋﻦ ﺧﻄﻮة "ﺗﺼﻤﯿﻢ اﻟﻨﻈﺎم "‬

‫ﻣﺎ ھﻮ اﻟﺘﺼﻤﯿﻢ؟‬
‫اﻟﺘﺼﻤﯿﻢ ھﻮ ﻋﻤﻠﯿﺔ إﺑﺪاﻋﯿﺔ ﻹﻳﺠﺎد ﺣﻞ ﻟﻤﺸﻜﻠﺔ‪ ،‬ﻛﻤﺎ ﺗﻄﻠﻖ ﻋﺎدة ﻛﻠﻤﺔ ﺗﺼﻤﯿﻢ ﻋﻠﻰ وﺻﻒ ھﺬا اﻟﺤﻞ‪.‬‬
‫ﺣﯿﺚ ﻧﺴﺘﻔﯿﺪ ﻣﻦ اﻟﻤﺘﻄﻠﺒﺎت اﻟﺘﻲ ﺣﺪدﻧﮫﺎ ﻓﻲ اﻟﺨﻄﻮة اﻟﺴﺎﺑﻘﺔ ﻓﻲ اﻟﺘﻌﺮف ﻋﻠﻰ اﻟﻤﺸﻜﻠﺔ‪ ،‬ﺛﻢ ﻧﺒﺪأ ﻓﻲ‬
‫اﻟﺘﻔﻜﯿﺮ ﻓﻲ اﻟﺤﻞ اﻟﺬي ﻳﻔﻲ ﺑﺠﻤﯿﻊ اﻟﺸﺮوط واﻟﻤﻮاﺻﻔﺎت اﻟﺘﻲ ﺗﺤﺪدھﺎ اﻟﻤﺘﻄﻠﺒﺎت‪ ،‬وﻏﺎﻟﺒﺎ ﻣﺎ ﻳﻤﻜﻦ إﻳﺠﺎد ﻋﺪد‬
‫ﻏﯿﺮ ﻣﺤﺪود ﻣﻦ اﻟﺤﻠﻮل ﻳﻤﻜﻦ ﻟﻨﺎ أن ﻧﺨﺘﺎر أﺣﺪھﺎ و اﻟﺬي ﻧﺠﺪه اﻷﻧﺴﺐ ﻣﻦ ﺑﯿﻨﮫﺎ‪.‬‬

‫ﻋﻨﺪ اﻻﻧﺘﮫﺎء ﻣﻦ ﺧﻄﻮة ﺗﺤﺪﻳﺪ اﻟﻤﺘﻄﻠﺒﺎت‪ ،‬ﻓﺈﻧﻨﺎ ﻧﻨﺘﮫﻲ ﺑﻮﺛﯿﻘﺘﯿﻦ )ﻛﻤﺎ ذﻛﺮﻧﺎ ﻓﻲ اﻟﺪرس اﻟﺴﺎﺑﻖ( اﻷوﻟﻰ ھﻲ‬
‫)وﺛﯿﻘﺔ ﺗﻌﺮﻳﻒ اﻟﻤﺘﻄﻠﺒﺎت( وﻳﺘﻢ ﺗﻘﺪﻳﻤﮫﺎ ﻟﻠﻌﻤﯿﻞ واﻟﺜﺎﻧﯿﺔ )وﺛﯿﻘﺔ ﻣﻮاﺻﻔﺎت اﻟﻤﺘﻄﻠﺒﺎت( وﻳﺘﻢ ﺗﻘﺪﻳﻤﮫﺎ ﻟﻠﻤﺼﻤﻢ‪.‬‬

‫ودور اﻟﻤﺼﻤﻢ ھﻮ ﺗﺤﻮﻳﻞ ھﺬه اﻟﻮﺛﺎﺋﻖ إﻟﻰ ﻧﻈﺎم ﻳﺮﺿﻲ اﻟﻌﻤﯿﻞ )ﻳﻠﺒﻲ اﺣﺘﯿﺎﺟﺎﺗﻪ(‪ ،‬وﻓﻲ ﻧﻔﺲ اﻟﻮﻗﺖ ﻳﺮﺿﻲ‬
‫اﻟﻤﻄﻮر )ﻳﻤﻜﻦ ﺗﻄﺒﯿﻘﻪ‪).‬‬
‫ﻟﺬا ﻓﺈن ﻋﻤﻠﯿﺔ اﻟﺘﺼﻤﯿﻢ ﻓﻲ ﻋﻤﻠﯿﺔ ﺗﻜﺮارﻳﺔ ‪ iterative‬ﻣﻦ ﺧﻄﻮاﺗﯿﻦ‪:‬‬

‫أوﻻ ‪:‬ﻳﺘﻢ إﻧﺘﺎج اﻟﺘﺼﻤﯿﻢ اﻟﺘﺼﻮري ‪ conceptual design‬واﻟﺬي ﻳﻮﺿﺢ ﻟﻠﻌﻤﯿﻞ ﻣﺎ اﻟﺬي ﺳﯿﻘﻮم ﺑﻪ اﻟﻨﻈﺎم‬
‫ﺑﺎﻟﺘﺤﺪﻳﺪ ‪.‬‬
‫وﻓﻲ ﺣﺎل ﻣﻮاﻓﻘﺔ اﻟﻌﻤﯿﻞ ﻋﻠﻰ ھﺬا اﻟﻨﻈﺎم‪ ،‬ﻳﺘﻢ اﻻﻧﺘﻘﺎل ﻟﻠﺨﻄﻮة اﻟﺘﺎﻟﯿﺔ‪.‬‬

‫ﺛﺎﻧﯿﺎ ‪:‬ﺗﺤﻮﻳﻞ اﻟﺘﺼﻤﯿﻢ اﻟﺘﺼﻮري إﻟﻰ وﺛﯿﻘﺔ ﺑﮫﺎ ﺗﻔﺎﺻﯿﻞ أﻛﺜﺮ ﻋﻦ اﻟﺘﺼﻤﯿﻢ ﻳﻄﻠﻖ ﻋﻠﯿﮫﺎ اﺳﻢ اﻟﺘﺼﻤﯿﻢ اﻟﺘﻘﻨﻲ‬
‫‪technical design‬واﻟﺬي ﻳﺠﺐ أن ﻳﻈﮫﺮ ﻟﻠﻤﻄﻮر ﻣﺎ ھﻲ اﻟﻤﻌﺪات واﻟﺒﺮﻣﺠﯿﺎت اﻟﻼزﻣﺔ ﻟﺒﻨﺎء اﻟﻨﻈﺎم‪.‬‬

‫أﺣﯿﺎﻧﺎ ﻳﺘﻄﻠﺐ اﻷﻣﺮ ﻟﻠﻌﻮدة إﻟﻰ اﻟﺨﻄﻮة اﻷوﻟﻰ( اﻟﺘﺼﻤﯿﻢ اﻟﺘﺼﻮري( واﻟﺘﻌﺪﻳﻞ ﻋﻠﯿﻪ‪ ،‬ﻟﺬا ﻓﺄﻧﮫﺎ ﻋﻤﻠﯿﺔ ﺗﻜﺮارﻳﺔ‬
‫ﺣﺘﻰ اﻟﻮﺻﻮل إﻟﻰ اﻟﺘﺼﻤﯿﻢ اﻟﺬي ﻳﺮﺿﻲ اﻟﻌﻤﯿﻞ وﻳﻤﻜﻦ ﺗﻄﺒﯿﻘﻪ ﻋﻠﻰ أرض اﻟﻮاﻗﻊ ﻓﻲ ﻇﻞ اﻹﻣﻜﺎﻧﯿﺎت اﻟﻤﺘﺎﺣﺔ‬
‫ﻟﻠﻤﻄﻮرﻳﻦ‪.‬‬

‫‪19‬‬
 ‫اﻟﺘﺼﻤﯿﻢ اﻟﺘﺼﻮري‪conceptual design:‬‬
‫ﻳﺮﻛﺰ ھﺬا اﻟﺘﺼﻤﯿﻢ ﻋﻠﻰ وﻇﺎﺋﻒ اﻟﻨﻈﺎم ‪ functions‬وﻳﻜﺘﺐ ﺑﻠﻐﺔ ﻳﻤﻜﻦ ﻟﻠﻌﻤﯿﻞ أن ﻳﻔﮫﻤﮫﺎ )ﻟﻐﺔ اﻟﺒﺸﺮ( ﻟﯿﺠﯿﺐ‬
‫ﻋﻦ أﺳﺌﻠﺔ اﻟﻌﻤﯿﻞ ﺣﻮل ﻣﺎذا )‪ (WHAT‬ﻳﻌﻤﻞ اﻟﻨﻈﺎم‪ .‬وﻳﺠﺐ أن ﻳﻜﻮن ﺧﺎﻟﻲ ﺗﻤﺎﻣﺎ ﻣﻦ أي ﺗ ﻔﺎﺻﯿﻞ ﺑﺮﻣﺠﯿﺔ أو‬
‫ﻓﻨﯿﺔ‪ .‬واﻻھﻢ أن ﻳﺤﻘﻖ ﻛﻞ اﻟﻤﺘﻄﻠﺒﺎت اﻟﺘﻲ ﺗﻢ ﺗﺤﺪﻳﺪھﺎ ﺳﺎﺑﻘﺎ‪.‬‬

‫اﻟﺘﺼﻤﯿﻢ اﻟﺘﻘﻨﻲ‪technical design‬‬

‫ھﺬا اﻟﺘﺼﻤﯿﻢ ﺳﻮف ﻳﺘﻢ ﺗﻘﺪﻳﻤﻪ إﻟﻰ ﻣﻄﻮري اﻟﻨﻈﺎم ﻟﯿﻘﻮﻣﻮا ھﻢ ﺑﺘﺤﻮﻳﻠﻪ إﻟﻰ اﻟﻨﻈﺎم اﻟﻤﻄﻠﻮب‪ ،‬ﻟﺬا ﻳﺠﺐ أن‬
‫ﻳﻘﺪم ھﺬا اﻟﺘﺼﻤﯿﻢ إﺟﺎﺑﺔ ﺷﺎﻓﯿﺔ ﻷﺳﺌﻠﺔ اﻟﻤﻄﻮر ﻋﻦ ﻛﯿﻔﯿﺔ )‪ (HOW‬ﺗﻄﻮﻳﺮ اﻟﻨﻈﺎم‪ .‬وﻟﻤﻨﻊ إﻟﻰ ﺗﻀﺎرب ﻓﻲ‬
‫اﻟﻤﻔﺎھﯿﻢ ﻓﺈن ھﺬا اﻟﺘﺼﻤﯿﻢ ﻋﺎدة ﻣﺎ ﻳﻜﺘﺐ ﺑﺎﺳﺘﻌﻤﺎل ﺗﻌﺒﯿﺮات وأﺳﺎﻟﯿﺐ ﺗﻘﻨﯿﺔ‪.‬‬

‫( •·‪•·.·´¯`·.‬ﻧﮫﺎﻳﺔ اﻟﺪرس اﻟﺮاﺑﻊ وﻻ ﻳﻮﺟﺪ ﻧﻘﺎش ﻟﻪ•·‪) •·.·´¯`·.‬‬

‫‪20‬‬
 ‫اﻟﺪرس اﻟﺨﺎﻣﺲ‪ :‬ﻛﺘﺎﺑﺔ اﻟﺒﺮﻧﺎﻣﺞ واﺧﺘﺒﺎره‬

‫أھﺪاف اﻟﺪرس‪:‬‬

‫ھﺬا اﻟﺪرس ﻟﻦ ﻳﻌﻠﻤﻚ ﻟﻐﺔ ﺑﺮﻣﺠﺔ ﻟﺘﻜﺘﺐ ﺑﮫﺎ اﻟﺒﺮاﻣﺞ‪ ،‬وﻟﻜﻦ اﻟﮫﺪف ﻣﻨﻪ اﻟﺘﻌﺮف ﻋﻠﻰ‪:‬‬

‫اﻟﻘﻮاﻋﺪ اﻟﺼﺤﯿﺤﺔ ﻟﻜﺘﺎﺑﺔ اﻟﺒﺮاﻣﺞ‬ ‫•‬

‫ﺧﻄﺔ اﻻﺧﺘﺒﺎر وأﻧﻮاع اﻻﺧﺘﺒﺎرات‬ ‫•‬

‫اﻟﺠﺰء اﻷول ‪:‬ﻛﺘﺎﺑﺔ اﻟﺒﺮاﻣﺞ‪:‬‬

‫ﺑﻌﺪ وﺿﻊ اﻟﺘﺼﻤﯿﻢ ﻟﻠﻨﻈﺎم واﺧﺘﯿﺎر ﻟﻐﺔ اﻟﺒﺮﻣﺠﺔ اﻟﻤﻨﺎﺳﺒﺔ‪ ،‬ﺗﺒﺪأ اﻟﺨﻄﻮة اﻟﺘﻲ ﺳﻮف ﺗﻨﻘﻞ اﻟﺘﺼﻤﯿﻢ اﻟﻤﻜﺘﻮب‬
‫ﻋﻠﻰ اﻟﻮرق إﻟﻰ واﻗﻊ‪ .‬ﺧﻼل ھﺬا اﻟﺪرس ﺳﻮف ﻧﻨﺎﻗﺶ أھﻢ اﻟﻘﻮاﻋﺪ اﻟﺘﻲ ﻋﻠﻰ اﻟﻤﺒﺮﻣﺞ إﺗﺒﺎﻋﮫﺎ أﺛﻨﺎء ﻛﺘﺎﺑﺔ‬
‫ﺑﺮاﻣﺠﻪ‪ .‬وﻟﻜﻦ ﻗﺒﻞ ذﻟﻚ ﻟﻨﺠﯿﺐ ﻋﻠﻰ ھﺬا اﻟﺴﺆال اﻟﺬي ﻻ ﺷﻚ أﻧﻪ ورد ﻋﻠﻰ ذھﻨﻚ اﻵن‬

‫س‪ :‬ﻟﻤﺎذا ﻋﻠﯿﻨﺎ إﺗﺒﺎع ھﺬه اﻟﻘﻮاﻋﺪ؟‬

‫ج ‪:‬إذا ﻛﻨﺖ ﺗﻌﻤﻞ ﻣﻨﻔﺮدا ﻓﻲ ﻛﺘﺎﺑﺔ ﺑﺮاﻣﺠﻚ‪ ،‬ﻓﺈن إﺗﺒﺎﻋﻚ ﻟﻘﻮاﻋﺪ وأﺳﺎﻟﯿﺐ ﻗﯿﺎﺳﯿﺔ ﻓﻲ اﻟﺒﺮﻣﺠﺔ ﺳﻮف ﺗﺴﺎﻋﺪك‬
‫ﻋﻠﻰ ﺗﻨﻈﯿﻢ أﻓﻜﺎرك ﻟﺘﺠﻨﺐ اﻟﻮﻗﻮع ﻓﻲ اﻷﺧﻄﺎء‪ .‬ﻛﻤﺎ أﻧﮫﺎ ﺳﺘﺴﺎﻋﺪك ﻋﻠﻰ اﻛﺘﺸﺎف أي أﺧﻄﺎء ﻗﺪ ﺗﺤﺪث‬
‫ﺑﺴﺮﻋﺔ وﺑﺴﮫﻮﻟﺔ‪.‬‬

‫أم إذا ﻛﻨﺖ ﺗﻌﻤﻞ ﺿﻤﻦ ﻓﺮﻳﻖ ﺑﺮﻣﺠﻲ‪ ،‬ﻓﺈن إﺗﺒﺎع اﻟﻘﻮاﻋﺪ واﻷﺳﺎﻟﯿﺐ اﻟﻘﯿﺎﺳﯿﺔ ﻓﻲ ﻛﺘﺎﺑﺔ أﺟﺰاء اﻟﺒﺮاﻣﺞ اﻟﺘﻲ‬
‫ﻳﻄﻠﺐ ﻣﻨﻚ ﻛﺘﺎﺑﺘﮫﺎ‪ ،‬ﺳﻮف ﺗﺴﺎﻋﺪك وﺑﻘﯿﺔ اﻟﻔﺮﻳﻖ ﻣﻦ ﺗﻨﺴﯿﻖ أﻋﻤﺎﻟﻜﻢ وﺗﻨﻈﯿﻤﮫﺎ‪ ،‬ﻛﻤﺎ أﻧﮫﺎ ﺳﺘﻘﻠﻞ ﻣﻦ ﻋﺪد‬
‫اﻷﺧﻄﺎء ﻓﻲ اﻟﺒﺮﻧﺎﻣﺞ وﺗﺴﺎﻋﺪ ﻋﻠﻰ اﻛﺘﺸﺎف ﻣﺎ ﻳﻘﻊ ﻣﻨﮫﺎ ﻓﻲ اﺳﺮع وﻗﺖ ﻣﻤﻜﻦ‪.‬‬

‫ﺗﻔﺮض اﻟﻜﺜﯿﺮ ﻣﻦ ﺷﺮﻛﺎت اﻟﺒﺮﻣﺠﺔ ﻋﻠﻰ ﻣﺒﺮﻣﺠﯿﮫﺎ إﺗﺒﺎع ﻗﻮاﻋﺪ ﻗﯿﺎﺳﯿﺔ ﻓﻲ ﻛﺘﺎﺑﺔ ﺑﺮاﻣﺠﮫﻢ‪ ،‬وذﻟﻚ ﻟﻀﻤﺎن‬
‫اﻟﺘﻜﺎﻣﻞ ﻓﻲ ﺟﻤﯿﻊ اﻟﺒﺮاﻣﺞ‪ ،‬ﻛﻤﺎ أن ﺑﻌﺾ اﻟﺸﺮﻛﺎت ﺗﻌﯿﻦ ﻓﺮق ﻻﺧﺘﺒﺎر اﻟﺒﺮاﻣﺞ‪ ،‬ﻏﯿﺮ اﻟﻔﺮﻳﻖ اﻟﺬي ﻗﺎم ﺑﺎﻟﺒﺮﻣﺠﺔ‬
‫وﻟﺬﻟﻚ ﻳﺠﺐ أن ﻳﻜﻮن اﻟﻜﻮد اﻟﺒﺮﻣﺠﻲ ﻣﻜﺘﻮب ﺑﻄﺮﻳﻘﺔ واﺿﺤﺔ ﻟﺠﻤﯿﻊ ﻣﻦ ﻳﻘﺮأه‪ ،‬وﻟﯿﺲ ﻟﻤﻦ ﻗﺎم ﺑﻜﺘﺎﺑﺘﻪ ﻓﻘﻂ‪.‬‬

‫ﺑﻌﺾ ﻗﻮاﻋﺪ اﻟﺒﺮﻣﺠﺔ‪Programming Guidelines‬‬

‫ھﯿﺎﻛﻞ اﻟﺘﺤﻜﻢ‪Control Structures‬‬ ‫•‬

‫ﻳﻘﺼﺪ ﺑﮫﺎ ﺗﻠﻚ اﻟﮫﯿﺎﻛﻞ اﻟﺘﻲ ﺗﺘﺤﻜﻢ ﻓﻲ ﻣﺴﺎر ﻋﻤﻞ اﻟﺒﺮﻧﺎﻣﺞ )ﻣﺜﻞ ‪ ، if- else)، Goto‬وأﺛﻨﺎء ﻛﺘﺎﺑﺔ ھﺬه اﻟﮫﯿﺎﻛﻞ‬
‫ﻋﻠﻨﺎ أن ﻧﺤﺎول أن ﻧﺠﻌﻠﮫﺎ واﺿﺤﺔ وﺳﮫﻠﺔ اﻟﺘﺘﺒﻊ‪ ،‬وﺧﺎﻟﯿﺔ ﻣﻦ اﻟﻘﻔﺰات اﻟﻮاﺳﻌﺔ ﻗﺪر اﻹﻣﻜﺎن‪ .‬اﻧﻈﺮ ﻟﮫﺬا اﻟﻤﺜﺎل‪:‬‬

‫;‪benefit = minimum‬‬
‫;‪if (age < 75) goto A‬‬
‫;‪benefit = maximum‬‬
‫;‪goto C‬‬
‫;‪if (age < 65) goto B‬‬
‫;‪if (age < 55) goto C‬‬
‫;‪A: if (age < 65) goto B‬‬

‫‪21‬‬
 ‫;‪benefit = benefit * 1.5 + bonus‬‬
‫;‪goto C‬‬
‫;‪B: if (age < 55) goto C‬‬
‫;‪benefit = benefit * 1.5‬‬
‫‪C: next statement‬‬

‫ﻧﻔﺲ اﻟﻜﻮد ﻳﻤﻜﻦ ﻛﺘﺎﺑﺘﻪ ﻋﻠﻰ ھﺬا اﻟﻨﺤﻮ‪:‬‬

‫;‪if (age < 55) benefit = minimum‬‬
‫;‪else if (age < 65) benefit = minimum + bonus‬‬
‫;‪else if (age < 75) benefit = minimum * 1.5 +bonus‬‬
‫;‪else benefit = maximum‬‬

‫ﻋﺎﻟﻢ اﻟﺒﺮﻣﺠﺔ ھﻨﺎك ﻗﺎﻋﺪة ﺗﻘﻮل أن اﻟﻌﻤﻮﻣﯿﺔ ﻣﯿﺰة‪ ، generality is a virtue‬ﻟﺬﻟﻚ ﺣﺎول داﺋﻤﺎ أن‬ ‫•‬
‫ﺗﺠﻌﻞ ﺷﻔﺮاﺗﻚ اﻟﺒﺮﻣﺠﺔ ﻋﺎﻣﺔ‪ ،‬ﻟﺘﺘﻤﻜﻦ ﻣﻦ إﻋﺎدة اﺳﺘﻌﻤﺎﻟﮫﺎ ﻓﻲ ﺑﻘﯿﺔ ﺑﺮاﻣﺠﻚ ﺑﺄﻗﻞ ﻗﺪر ﻣﻤﻜﻦ ﻣﻦ‬
‫اﻟﺘﻌﺪﻳﻞ‪ ،‬وﻟﻜﻦ ﺣﺎذر ﻣﻦ اﻟﺘﻤﺎدي ﻓﻲ ذﻟﻚ!‬
‫ﻻ ﺗﺴﺘﺨﺪم أﺑﺪا أﺳﻤﺎء ﻻ ﻣﻌﻨﻰ ﻟﮫﺎ ﻟﻤﺘﻐﯿﺮات أو ﺑﺎرﻣﺘﺮات ﺑﺮﻧﺎﻣﺠﻚ ) ﻳﻨﺼﺢ ﺑﻤﺮاﺟﻌﺔ ھﺬا اﻟﺪرس‬ ‫•‬
‫"اﻟﺘﺴﻤﯿﺔ ﻓﻲ اﻟﺒﺮﻧﺎﻣﺞ‪ ،‬درس ﻻﺑﺪ ﻣﻦ أن ﻳﻘﺮأه ﻛﻞ ﻣﺒﺮﻣﺞ! )"‬
‫"أرﻳﺪ ﺑﺮﻧﺎﻣﺠﺎ ﺳﺮﻳﻌﺎ" وﻛﻠﻨﺎ ﻧﺮﻳﺪ ذﻟﻚ‪ ،‬وﻟﻜﻦ ﻣﺎ ھﻮ اﻟﺜﻤﻦ؟!‬ ‫•‬

‫ﻋﻨﺪﻣﺎ ﺗﻔﻜﺮ ﻓﻲ ﺟﻌﻞ ﺑﺮﻧﺎﻣﺠﻚ أﺳﺮع ﻣﺎ ﻳﻤﻜﻦ‪ ،‬ﻋﻠﯿﻚ أن ﺗﻔﻜﺮ ﻛﺬﻟﻚ ﻓﻲ اﻟﺜﻤﻦ اﻟﺬي ﺳﺘﺪﻓﻌﻪ ﻣﻘﺎﺑﻞ ذﻟﻚ‪:‬‬

‫‪ .1‬اﻟﺒﺮﻧﺎﻣﺞ اﻟﺴﺮﻳﻊ ﻗﺪ ﻳﺘﻄﻠﺐ ﻣﻨﻚ ﻛﺘﺎﺑﺔ ﻛﻮد ﻣﻌﻘﺪ ﻳﺘﻄﻠﺐ ﻣﻨﻚ )وﻣﻦ ﻓﺮﻳﻖ اﻟﻌﻤﻞ( اﻟﻤﺰﻳﺪ ﻣﻦ‬
‫اﻟﻮﻗﺖ واﻟﺠﮫﺪ ﻓﻲ ﻛﺘﺎﺑﺘﻪ‪.‬‬
‫‪ .2‬اﻟﻮﻗﺖ اﻟﺬي ﺗﺤﺘﺎﺟﻪ ﻋﻤﻠﯿﺔ اﺧﺘﺒﺎر اﻟﺒﺮﻧﺎﻣﺞ اﻟﻤﻌﻘﺪ ﻓﻲ ﻣﺨﺘﻠﻒ ﺣﺎﻟﺘﻪ‪.‬‬
‫‪ .3‬اﻟﻮﻗﺖ واﻟﺠﮫﺪ اﻟﺬي ﺗﺤﺘﺎﺟﻪ ﻟﺘﻌﺪﻳﻞ ھﺬا اﻟﻜﻮد أو ﻟﺘﻄﻮﻳﺮه‪.‬‬

‫زﻣﻦ ﺗﻨﻔﯿﺬ اﻟﺒﺮﻧﺎﻣﺞ ﻣﺎ ھﻮ إﻻ ﺟﺰء ﻣﻦ ﻣﻌﺎدﻟﺔ ﻛﺒﯿﺮة ﻟﺤﺴﺎب ﺗﻜﻠﻔﺔ اﻟﺒﺮﻧﺎﻣﺞ‪ ،‬ﻟﺬﻟﻚ ﻋﻠﯿﻚ أن ﺗﻌﺎدل ﺑﯿﻦ‬
‫اﻟﺴﺮﻋﺔ‪ ،‬واﻟﺠﻮدة‪ ،‬واﺣﺘﯿﺎﺟﺎت اﻟﺰﺑﻮن‪ .‬وﻻ ﺗﻀﺤﻲ ﺑﺎﻟﺒﺴﺎﻃﺔ واﻟﻮﺿﻮح ﻣﻦ أﺟﻞ اﻟﺴﺮﻋﺔ‪.‬‬

‫اﻟﺘﻮﺛﯿﻖ‪ :‬ﻻ ﺗﮫﻤﻞ أﺑﺪا ﺗﻮﺛﯿﻖ ﺑﺮﻧﺎﻣﺠﻚ‪ ،‬ﻣﺎ ﺳُﻤﻲ اﻹﻧﺴﺎن إﻧﺴﺎﻧﺎ إﻻ ﻟﻨﺴﯿﺎﻧﻪ‪.‬‬ ‫•‬

‫( •·‪•·.·´¯`·.‬ﻧﮫﺎﻳﺔ اﻟﺪرس اﻟﺨﺎﻣﺲ ‪ -‬اﻟﺠﺰء اﻷول وﻻ ﻳﻮﺟﺪ ﻧﻘﺎش ﻟﻪ •·‪) •·.·´¯`·.‬‬

‫‪22‬‬
 ‫اﻟﺪرس اﻟﺨﺎﻣﺲ‪ :‬ﻛﺘﺎﺑﺔ اﻟﺒﺮﻧﺎﻣﺞ واﺧﺘﺒﺎره‬

‫اﻟﺠﺰء اﻟﺜﺎﻧﻲ ‪:‬اﺧﺘﺒﺎر اﻟﺒﺮاﻣﺞ‪:‬‬

‫وﺻﻠﻨﺎ اﻵن إﻟﻰ آﺧﺮ ﻣﺮﺣﻠﺔ ﻓﻲ ﺗﻄﻮﻳﺮ اﻟﻨﻈﺎم‪ ،‬وھﻲ اﺧﺘﺒﺎر اﻟﺒﺮﻧﺎﻣﺞ ﻟﻠﺘﺄﻛﺪ ﻣﻦ أﻧﻪ ﻳﻌﻤﻞ ﻋﻠﻰ اﻟﻨﺤﻮ اﻟﺬي‬
‫ﻳﺘﻮﻗﻌﻪ اﻟﺰﺑﻮن‪.‬‬

‫ﻗﺒﻞ ﺗﺴﻠﯿﻢ اﻟﻨﻈﺎم اﻟﻨﮫﺎﺋﻲ إﻟﻰ اﻟﺰﺑﻮن ﺗﺠﺮى ﻋﻠﯿﻪ اﻟﻜﺜﯿﺮ ﻣﻦ اﻻﺧﺘﺒﺎرات‪ ،‬ﺑﻌﻀﮫﺎ ﻳﻌﺘﻤﺪ ﻋﻠﻰ ﻣﺎ اﻟﺬي ﻳﺘﻢ‬
‫اﺧﺘﺒﺎره ﻣﺜﻼ‪:‬‬

‫(أﺣﺪ ﻣﻜﻮﻧﺎت اﻟﺒﺮﻧﺎﻣﺞ ‪ -‬ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻟﻤﻜﻮﻧﺎت ‪ -‬ﺟﺰء ﻣﻦ اﻟﻨﻈﺎم ‪ -‬اﻟﻨﻈﺎم ﺑﺎﻟﻜﺎﻣﻞ)‬

‫واﻟﺒﻌﺾ اﻷﺧﺮ ﻳﻌﺘﻤﺪ ﻋﻠﻰ ﻣﺎ اﻟﺬي ﻧﺮﻳﺪ ﻣﻌﺮﻓﺘﻪ ﻣﻦ ھﺬه اﻻﺧﺘﺒﺎرات‪ ،‬ﻣﺜﻼ‪:‬‬

‫ھﻞ ﻳﻌﻤﻞ اﻟﻨﻈﺎم وﻓﻘﺎ ﻟﻤﺎ ورد ﻓﻲ اﻟﻤﺘﻄﻠﺒﺎت؟‬ ‫•‬

‫ھﻞ ﻳﻌﻤﻞ اﻟﻨﻈﺎم وﻓﻘﺎ ﻟﻤﺎ ورد ﻓﻲ اﻟﺘﺼﻤﯿﻢ؟‬ ‫•‬
‫ھﻞ ﻳﻌﻤﻞ اﻟﻨﻈﺎم ﻛﻤﺎ ﻳﺘﻮﻗﻌﻪ اﻟﺰﺑﻮن ﻣﻨﻪ؟‬ ‫•‬

‫ﻣﺮاﺣﻞ اﻻﺧﺘﺒﺎر‪:‬‬

‫ﻋﻨﺪ اﻟﻌﻤﻞ ﻋﻠﻰ اﺧﺘﺒﺎر ﻧﻈﺎم ﻣﻦ اﻟﺤﺠﻢ اﻟﻜﺒﯿﺮ‪ ،‬ﻓﺈن ﻋﻤﻠﯿﺔ اﻻﺧﺘﺒﺎر ﺗﺘﻢ ﻋﻠﻰ ﻋﺪة ﻣﺮاﺣﻞ ﻣﻮﺟﺰھﺎ ﻓﻲ ﻣﺎ‬
‫ﻳﻠﻲ‪:‬‬

‫‪ .1‬اﺧﺘﺒﺎر اﻟﻤﻜﻮن ‪ Module Testing‬أو ‪component Testing‬‬

‫أول ﻣﺮاﺣﻞ اﺧﺘﺒﺎر اﻟﻨﻈﻢ‪ ،‬ھﻲ اﺧﺘﺒﺎر ﻛﻞ ﻣﻜﻮن ﻋﻠﻰ ﺣﺪى ﺑﻤﻌﺰل ﻋﻦ ﺑﻘﯿﺔ ﻣﻜﻮﻧﺎت اﻟﻨﻈﺎم‪ ،‬ﻟﻠﺘﺄﻛﺪ ﻣﻦ‬
‫ﻋﻤﻠﻪ ﻋﻠﻰ اﻟﻨﺤﻮ اﻟﻤﺘﻮﻗﻊ ﻣﻨﻪ‪ .‬ﺑﺎﺧﺘﺒﺎر اﻟﻤﻌﻠﻮﻣﺎت اﻟﻤﺘﺤﺼﻞ ﻋﻠﯿﮫﺎ )‪ (output‬ﻣﻨﻪ ﺑﻌﺪ إﻣﺪاده ﺑﺎﻟﺒﯿﺎﻧﺎت اﻟﻼزﻣﺔ‬
‫ﻟﻪ‪(input).‬‬

‫‪ .2‬اﺧﺘﺒﺎر اﻟﺘﻜﺎﻣﻞ‪Integration Testing‬‬

‫ﺑﻌﺪ اﺧﺘﺒﺎر ﻛﻞ ﻣﻜﻮﻧﺎت اﻟﻨﻈﺎم واﻟﺘﺄﻛﺪ ﻣﻦ ﺳﻼﻣﺔ ﺗﺼﻤﯿﻤﮫﺎ‪ ،‬ﻳﺠﺐ أن ﻧﺘﺄﻛﺪ ﻣﻦ أﻧﮫﺎ ﺳﺘﻌﻤﻞ ﻣﻌﺎ ﺑﺸﻜﻞ‬
‫ﺻﺤﯿﺢ وأﻧﻪ ﻻ ﻳﻮﺟﺪ ﺗﻀﺎرب ﺑﯿﻦ ﺑﻌﻀﮫﺎ اﻟﺒﻌﺾ ﺑﺤﯿﺚ أن اﻟﻤﻌﻠﻮﻣﺎت اﻟﻤﻨﺘﻘﻠﺔ ﺑﯿﻦ ھﺬه اﻟﻤﻜﻮﻧﺎت ﺗﺼﻞ ﺑﺎﻟﮫﯿﺌﺔ‬
‫اﻟﻤﺘﻮﻗﻌﺔ ﻟﮫﺎ‪ .‬وھﺬا ھﻮ اﻟﮫﺪف ﻣﻦ اﺧﺘﺒﺎر اﻟﺘﻜﺎﻣﻞ‪.‬‬

‫‪ .3‬اﺧﺘﺒﺎر اﻟﻮﻇﯿﻔﺔ‪Function Testing‬‬

‫وﻳﻘﺼﺪ ﺑﻪ اﺧﺘﺒﺎر اﻟﻨﻈﺎم ﺑﻌﺪ ﺗﺠﻤﯿﻊ ﻛﻞ ﻣﻜﻮﻧﺎﺗﻪ ﻟﻠﺘﺄﻛﺪ ﻣﻦ أﻧﻪ ﻳﺆدي اﻟﻮﻇﯿﻔﺔ اﻟﺘﻲ ﻳﺘﻌﯿﻦ ﻋﻠﯿﻪ اﻟﻘﯿﺎم ﺑﮫﺎ‪،‬‬
‫واﻟﻤﻮﺿﺤﺔ ﻓﻲ وﺛﺎﺋﻖ ﻣﺘﻄﻠﺒﺎت اﻟﻨﻈﺎم ‪.‬ﻋﻨﺪﻣﺎ ﻳﺠﺘﺎز اﻟﻨﻈﺎم ھﺬا اﻻﺧﺘﺒﺎر ﻳﻤﻜﻨﻨﺎ اﻋﺘﺒﺎر ھﺬا اﻟﻨﻈﺎم ﻋﻠﻰ أﻧﻪ‬
‫ﻧﻈﺎم ﻋﺎﻣﻞ‪Functioning System‬‬

‫‪Performance Testing‬‬ ‫‪ .4‬اﺧﺘﺒﺎر اﻷداء‬

‫‪23‬‬
 ‫ﻓﻲ ھﺬه اﻟﺨﻄﻮة ﻳﺘﻢ اﺧﺘﺒﺎر أداء اﻟﺒﺮﻧﺎﻣﺞ ﻓﻲ ﺑﯿﺌﺔ ﻋﻤﻞ اﻟﺰﺑﻮن ﻟﻠﺘﺄﻛﺪ ﻣﻦ أن اﻟﻨﻈﺎم ﻣﺘﻮاﻓﻖ ﻣﻊ ﺑﻘﯿﺔ‬
‫اﻟﻤﺘﻄﻠﺒﺎت ‪.‬ﻋﻨﺪ اﺟﺘﯿﺎز اﻟﻨﻈﺎم ﻟﮫﺬا اﻻﺧﺘﺒﺎر ﻳﺘﻢ اﻟﺘﺼﺪﻳﻖ ﻋﻠﻰ اﻟﻨﻈﺎم ‪ validated system‬وﺑﮫﺬا ﻓﺈﻧﻨﺎ ﻧﻌﺘﺒﺮ أن‬
‫اﻟﻨﻈﺎم أﺻﺒﺢ ﺟﺎھﺰ ﺣﺴﺐ ﻣﻔﮫﻮﻣﻨﺎ ﻟﻤﺎ ﻃﻠﺒﻪ اﻟﺰﺑﻮن‪.‬‬

‫‪ .5‬اﺧﺘﺒﺎر اﻟﻘﺒﻮل‪Acceptance Test‬‬

‫ﻳﺘﻢ إﺟﺮاء ھﺬا اﻻﺧﺘﺒﺎر ﻟﻠﺘﺄﻛﺪ ﻣﻦ أن اﻟﻨﻈﺎم اﻟﻤﺤﻘﻖ ﻣﻮاﻓﻖ ﻟﻤﺎ ﺗﻮﻗﻌﻪ اﻟﺰﺑﻮن‪ ،‬وﺑﻌﺪھﺎ ﻳﻌﺪ اﻟﻨﻈﺎم ﻣﻘﺒﻮل‬
‫‪Accepted system‬‬ ‫ﻋﻨﺪ اﻟﻤﺴﺘﺨﺪم واﻟﺰﺑﻮن‬

‫‪ .6‬اﺧﺘﺒﺎر اﻟﺘﺜﺒﯿﺖ‪Installation Test‬‬

‫اﻻﺧﺘﺒﺎر اﻷﺧﯿﺮ ﻳﺘﻢ ﻓﯿﻪ ﺗﺜﺒﯿﺖ اﻟﻨﻈﺎم ﻓﻲ ﺑﯿﺌﺔ اﻟﻌﻤﻞ اﻟﺨﺎﺻﺔ ﺑﻪ واﻟﺘﺄﻛﺪ ﻣﻦ أﻧﻪ ﻳﻌﻤﻞ ﻛﻤﺎ ھﻮ ﻣﻄﻠﻮب ﻣﻨﻪ‪.‬‬

‫اﻟﺸﻜﻞ اﻟﺘﺎﻟﻲ ﻳﻮﺿﺢ ﺧﻄﻮات ﺗﻄﺒﯿﻖ ﻋﻤﻠﯿﺔ اﺧﺘﺒﺎر اﻟﻨﻈﺎم‪ ،‬واﻟﺘﻲ ﻳﺤﺴﻦ ﺗﻄﺒﯿﻘﮫﺎ ﻋﻠﻰ اي ﻧﻈﺎم ﻣﮫﻤﺎ ﻛﺎن‬
‫ﺣﺠﻤﻪ ﻟﻠﺘﺄﻛﺪ ﻣﻦ أﻧﻪ ﺳﯿﺆدي اﻟﻤﮫﻤﺔ اﻟﻤﻄﻠﻮﺑﺔ ﻣﻨﻪ‬

‫( •·‪•·.·´¯`·.‬ﻧﮫﺎﻳﺔ اﻟﺪرس اﻟﺨﺎﻣﺲ ‪ -‬اﻟﺠﺰء اﻟﺜﺎﻧﻲ وﻻ ﻳﻮﺟﺪ ﻧﻘﺎش ﻟﻪ•·‪) •·.·´¯`·.‬‬

‫ﺗﻤﺖ دورة ھﻨﺪﺳﺔ اﻟﺒﺮﻣﺠﯿﺎت ﺑﺤﻤﺪاﷲ وﺗﻮﻓﯿﻘﻪ ‪..‬‬

‫‪24‬‬