ذكرنا في تغريدات سابقة بداية تخصص هندسة البرمجيات وكيف إنه هذا التخصص ساعدنا في إنشاء إطارات تطوير مختلفة ممكن تسهل علينا عملية بناء السوفتوير ونوعاً ما مضمونة النتائج إذا إتبعت بشكل صحيح
في هذه السلسلة رح نتعرف أكثر على أشهر هذه الإطارات وميزاتها
#برمجة #هندسة_البرمجيات #swe
في هذه السلسلة رح نتعرف أكثر على أشهر هذه الإطارات وميزاتها
#برمجة #هندسة_البرمجيات #swe
في نهايات القرن الماضي .. كانت أغلب إطارات التطوير تنتمي للـ plan-driven models وأشهرها طبعاً الـ waterfall model .. واللي يركز بشكل أساسي على تقسيم حياة تطوير السوفتوير إلى عدة مراحل منفصلة تماماً بحيث ما تبدأ أي مرحلة جديدة بدون الانتهاء من المرحلة القديمة بشكل كلي
تتمحور الـ plan-driven models حول نقطتين أساسية .. الأولى (من إسمها) ممكن تلخيصها بعبارة مشهورة وهي
(plan your work .. work your plan)
بمعنى لازم تركز بشكل مكثف على عملية الـ planning بحيث تطلع بخطة تشمل المرحلة اللي رح تشتغلوا عليها بالكامل من بدايتها وحتى نهايتها
(plan your work .. work your plan)
بمعنى لازم تركز بشكل مكثف على عملية الـ planning بحيث تطلع بخطة تشمل المرحلة اللي رح تشتغلوا عليها بالكامل من بدايتها وحتى نهايتها
النقطة الثانية هي الـ documentation .. واللي يعتبر أهم النقطتين .. الـ waterfall model يقدس شي إسمه documentation وإنه لازم يكون عملك منظم ومدروس .. بحيث قبل ما تبدأ تشتغل على المرحلة الأهم وهي مرحلة البرمجة .. يكون عندك نظرة شاملة على السوفتوير من عدة جوانب مهمة
الكلام هذا جميل .. لكن بدأت تظهر مشاكل الـ waterfall model لما بدأنا نحسب تكلفة إضافة أو تغيير requirement معين حتى لو كان بسيط .. لأنه هذا التغيير رح يكلفك أكثر كونه رح يرجعك للبداية وتضطر على الأقل تعيد دراسة الـ components اللي رح تتأثر بإضافة هذا الـ requirement
لذلك الـ requirements stability نقطة مهمة جداً إذا حبيت تتبنى هذا الإطار .. لكن هذا الكلام غير واقعي بالمرة .. متى كان آخر مشروع إشتغلت عليه ما كان فيه تغيير في الـ requirements وأحياناً تكون تعديلات كبيرة جداً لدرجة تتضطر لعمل contract جديد إذا كنت شغال على مشروع مع جهة ثانية
أيضاً من مشاكل هذا الإطار هي قلة الـ feedbacks أوالـ customer involvement
من أساسيات نجاح أي مشروع سواء كان تقني أو لا .. هي
1-الـ communication عشان تعرف الطريق الصحيح اللي لازم تمشي عليه
2- والـ feedback المستمر عشان تضمن إنك مازلت ماشي على الطريق الصحيح اللي اخترته
من أساسيات نجاح أي مشروع سواء كان تقني أو لا .. هي
1-الـ communication عشان تعرف الطريق الصحيح اللي لازم تمشي عليه
2- والـ feedback المستمر عشان تضمن إنك مازلت ماشي على الطريق الصحيح اللي اخترته
أغلب العمليات أو الـ processes اللي نسويها بشكل يومي .. يا تكون defined processes بمعنى إذا عطيتها الـ inputs الصحيحة ومشيت على الخطوات الخاصة بهذه الـ process .. فـ (حتماً) رح تحصل على الـ desired outputs .. وإذا كان في أي مشكلة .. فغالباً لأنك عطيت الـ process مدخلات خاطئة
والنوع الثاني من العمليات هو الـ empirical processes واللي تعتمد على فكرة إدخال Inputs لـ process معينة .. وبعدين ناخد الـ outputs ونقارنها مع الـ desired outputs ونشوف هل نحتاج أي تعديل على المدخلات ونرجع نعيد العملية حتى نوصل للـ desired outputs
غالباً ما تكون عملية بناء السوفتوير فيها كثير من الـ Empirical Processes واللي زي ما ذكرنا نحتاج فيها إلى feedback عشان نعرف هل نحن إتخذنا القرارات الصح .. أو نحتاج نعدل في بعض الأمور .. وبالتالي نحتاج إلى الـ feedback المستمر من العميل حتى لو كان بسيط
للأسف .. هذه النقطة تستخدم بشكل محدود في هذا الإطار .. أي ambiguity ولو كانت بسيطة في الـ requirements ممكن تسبب تباين كبير بين تصور العميل لنقطة معينة وفهم مهندس البرمجيات لنفس النقطة لذلك صرنا نحتاج إنه يكون فيcustomer involvement ولكن من المهم تقنينه حتى لا يساء استخدامه
طبعاً الفجوة اللي تكلمنا عنها صرنا نقدر نحلها عن طريق الـ mock-ups والـ prototypes البسيطة .. وخصوصاً إنه صار عندنا برامج متخصصة في هذا الشي تسهل علينا بناءها .. وبالتالي نقدر نقول إنه هذا المشكلة ما صرنا نشوفها كثير .. لكنها ما زالت موجودة
ومازلنا مع المشاكل .. وحدة من أصعب الأمور اللي ممكن تسويها لما تتبنى واحدة من الـ plan-driven models هي قياس الـ progress .. أو نسبة الإنتهاء من المشروع اللي شغال عليه
في عالم الـ waterfall .. من الصعب إنك تعطي نسبة محددة وخصوصاً إنه أطول فترة رح يعيش فيها المشروع التقني .. هي فترة التطوير والإختبار .. واللي غالباً تكون آخر فترتين والوقت اللي رح يُستغرق في هذه المرحلتين صعب جداً تقيسه قبل ما تبدأ .. وغالباً رح تعتمد على خبرتك في عمل هذا القياس
كل هذه المشاكل وأكثر كانت السبب في إننا نشوف إطار ثاني مع بداية الألفية .. في عام 2001 .. بدأنا نسمع عن إطار الـ Agile بشكل كبير وبدأنا نشوف كثير من الشركات تتبنى هذا الإطار في مشاريعها التقنية .. وخصوصاً إنه يحل كثير من المشاكل اللي كنا نعاني منها مع الـ plan-driven models
مبدأ الـ Agile مبني على نقطتين رئيسية ..
- الـ rapid development .. بمعنى .. حاول إنك تبدأ تكتب الكود من أول يوم ..
- الـ customer involvement في كل خطوة صغيرة أو كبيرة .. وهذه تعتبر نقطة جيدة إذا اعتبرنا إنه الـ customer واحد من أهم الـ stakeholders في أي مشروع
- الـ rapid development .. بمعنى .. حاول إنك تبدأ تكتب الكود من أول يوم ..
- الـ customer involvement في كل خطوة صغيرة أو كبيرة .. وهذه تعتبر نقطة جيدة إذا اعتبرنا إنه الـ customer واحد من أهم الـ stakeholders في أي مشروع
فكرة الـ agile طلعنا منها بأكثر من models كلها تتبع لفكرة الـ agile وتختلف في تفاصيل بسيطة .. وأهمها طبعاً الـ scrum model وأيضاً الـ spiral model واللي يركز شوي على الـ risk management في حال كان المشروع يتطلب هذه العملية ..
لكن الـ model الأشهر لما نذكر الـ agile .. هو الـ scrum model .. واللي يعتمد على تقسيم المميزات اللي رح يقدمها السوفتوير إلى تاسكات أصغر وأصغر .. يتم إعطاء كل تاسك priority معينة .. وبعدها كل أسبوع أو أسبوعين رح يكون في عندنا sprint نحاول ننجز فيها التاسكات المطلوبة ..
مبدأ الـ agile حل أغلب المشاكل اللي كنا نواجهها في الـ waterfall .. أهمها طبعاً الـ requirements stability .. إذا كان الـ customer حابب يعدل على نقطة معينة .. ممكن فريق التطوير بكل بساطة يسلمها في الـ sprint القادم وبتأثير جداً بسيط ولا يقارن مع الـ waterfall model
مع تطبيق فكرة الـ agile رح يقدر الفريق التقني يعطي progress واضح لعملية التطوير .. وأيضاً بعد كل sprint رح يكون الفريق قادر على إعطاء تقديرات أفضل للوقت والجهد اللازم لتطوير feature معينة كونه صار عندنا خبرة من الـ sprints الماضية وهذا طبعاً رح يحسن من دقة الجدول الزمني للمشروع
لكن .. مع تطبيق فكرة الـ rapid development بدأنا نشوف بعض الآثار الجانبية .. مثل الاستغناء عن الـ documentation كونك ممكن تصرف وقت طويل عليه بدل ما تركز على عملية الـ development .. وهي نقطة غير مقبولة أبدأ وخصوصاً لما تتعامل مع شركات كبيرة أو على مشاريع كبيرة
أغلب هذه الشركات تفكر في مرحلة ما بعد التطوير .. وهي مرحلة تشغيل المشروع واللي ممكن تسند إلى شركة ثانية غير الشركة اللي طورت .. عدم وجود مستندات تشرح آلية عمل وبناء السوفتوير من الألف للياء معناها ضياع وقت وجهد على مرحلة الـ reverse engineering for documenting software components
من الآثار الجانبية اللي بدأنا نواجهها أيضاً هي جودة السوفتوير .. وهذه نقطة مهمة جداً .. ممكن ألخصها بتعليق قرأته قبل فترة .. إذا قلت لمجموعة من مهندسي البرمجيات وهم على وشك ركوب الطيارة بأنه عملية تطوير نظام الطيران الآلي كانت agile .. غالباً مارح يركبوا في الطيارة 😁
السبب إنه الـ agile model ما يتوسع بشكل كبير في عملية إختبار السوفتوير وغالباً رح يقتصر على الـ feature level اللي رح تطلقها .. لكن إختبارات الـ integration والـ system ومعرفة تاثير هذه الـ feature على باقي الخدمات اللي كانت أصلاً موجودة .. فمهمشة تقريباً
هذه المشاكل بدأنا نقلل من حجمها مع تطور أدوات الـ CI أو الـ continuous integration .. واعتماد مبدأ الـ TDD أو الـ test driven development .. واللي حاولت تخلق توازن يساعدنا في زيادة جودة الـ softwares اللي تعتمد على الـ agile models
أخيراً .. لكل نمط مميزاته وعيوبه .. وتبقى مهمتك الأساسية هي تحديد النمط المناسب لفريق التطوير وإمكانياته وجودته .. وأيضاً طبيعة المشروع وحجمه .. كلها عوامل رح تأثر في إختيارك 👍
#انتهى
#انتهى
جاري تحميل الاقتراحات...