أسألني في مجالي عمل "تحليل وتصميم البرمجيات" وكذلك "هندسة الجودة ومعايير تطوير صناعة البرمجيات".

حقيقة أول مرة أسمع بهذه الجملة في مجالنا العلمي والعلمي كـ"اسم" ومصطلح. ولكنه كـ"معنى" فهو في صميم عملنا طبعا (حتى أني أعجب بهذه "التسمية" فهي حقيقية ومعبرة جدا ما شاء الله أين سمعتها؟ وهل بالعربية أم كانت مترجمة؟)

"التفاضل والتكامل" يساوي أو يناظر (وهو تمثل وتسمية حقا بديعة ما شاء الله) "التحليل والتصميم" نفسه بعملنا.

فما "التحليل" إلا فك وفصل للشيء تحت الدارسة إلى أجزائه الأصغر فالأصغر لسهولة التعامل معها ("المفاضلة" بينها) على حدة في سبيل فهم الشيء نفسه ككل.

وما "التصميم" إلا البُعد المقابل تماما للتحليل فهو جمع وربط وتركيب و"عقد" (من العُقد المربوطة الموثقة ولنذكر مصطلح "أهل الحل والعقد" القديم في تراثنا) للأمور المجزئة المشتتة أو المنفصلة في صورة جمعية مركبة بـ"تصميم" مفيد ونافع.

وهو نفس المعنى والمفهوم الرياضي لعمليني التفاضل والتكامل فعلا بالضبط كما تفضلت مشكورا بارك الله فيك.

هنالك مرحلة ما قبل البيع (presales) وهي التي تعنى بمتاعبة السوق ومتطلبات العملاء وتشمل الاستجابة لطلبات العرض للمشاريع الجديدة وتوفية شروطها والاتفاق عليها إلى آخره.

ثم مرحلة لما المشروع يُتفق عليه ويدخل في حيز التنفيذ فيتكون ويخصص فريق العمل وتحديد الأطراف المعنية (stakeholders) والتوفيق بين الالتزامات والمتطلبات فيما بينهم (أي مرحلة تجهيز أو إعداد "إدارة المشروع") ثم العمل على تحديد إطار العمل والرؤية للمشروع والشروع في وضع خطط زمانية تشمل الموارد ومراحل التنفيذ والمخرجات إلى آخره.

ويبدأ المشروع (في عهد ما قبل الآجايل) بمرحلة "التحليل" جمع المتطلبات وتحليل تفصيلاتها وإعداد دراستها التحليلية. والتي ستسلم لمرحلة "التصميم" في تحديد الخيارات التقنية المناسبة لهذه المتطلبات ووضع تصاميم النظام المطلوب من ناحية الوظائف والخصائص وقواعد البيانات وكذلك الخصائص الغير وظيفية (none functional specifications) المتعلقة بالأمن والهارويد والشبكات وكذلك خصائص السرعة والسعة وقابلية التغيير إلى آخره من تفصيلات كثيرة وهي من أهم عوامل نجاح المشروع بالمناسبة وطبعا تصاميم الجرافيك.

ثم بعد إعداد ووضوع التحليل والتصميم ندخل في طور مرحلة التنفيذ كبرمجة كود وبيانات وشاشات وتفاعلات تكون النظام نفسه في عالم الحوسبة الرقيمية.

ومع مخرجات مرحلة التنفيذ يأتي دور مرحلة الاختبار والجودة (testing). وتؤأمتها دعنا نقول مرحلة الاختبار والجودة لعمل المشروع إداريا (process standardization & improvement) هذه للبرامج كمنتجات للمشروع وتلك للمشروع نفسه وإدارة عمله هندسيا وحسب معايير الجودة بكيان المؤسسة ككل.

ولما ننتهي من كل ذلك تأتي مرحلة "التسليم" والتشغيل. ثم خدمات الصيانة وما بعد التسليم وإدارة طلبات التغيير وما إلى ذلك.

وطبعا دور "إدارة المشروع" (project management) مستمرة تتابع وتدير كل هذه المراحل.

وطبعا طبعا مع لدخول في عصر الآجايل صارت كل هذه المراحلة متداخلة متفاعلة تعمل معا في صورة دورات عمل قصيرة جدا (اختيارنا المفضل عادة يكون 4 دورات iterations كل دورة أسبوع يرى فيها العميل جزء من النظام ولو على شكل prototype أو ماكيت تشملها دورة واحدة release ينتج عنها أصدار لجزئية متكاملة من النظام تشغل وتسلم للعميل يعمل بها)

والسكرام (scrum) واللين (lean) هما من طرق المندرجة تحت مفهوم أو فلسفة (دعنا نقول) الآجايل. الأولى هي الأكثر انتشارا في العالم من بدايات الآجايل وذلك لبساطتها وسهولتها وهي طريقة أمريكية. بينما الثانية هي طريقة يابانية مستقاة من ثقافة ونظام الجودة الأشهر عالميا في عالم السيارات وهو من شركة تويوتا. (المفاهيم من صناعة السيارات ولكنها طوعت وتبلورت لتخدم وتتواءم مع صناعة السوفت وير)

السكرام مشهورة ببساطتها (التي هي ربما أكثر مما ينبغي) وبأدوانتها الأشهر في عالم الآجيل مثل "قصص المستخدمين" user stories والسكرام أقرب ما تكون (توصيفيا) من طريقة إدارة عمل ومشروع.

بينما اللين هي أكثر عمقا وعندها مفاهيم ومباديء وأدوات تقنية وفنية مفيدة للغاية تهتم أكثر بجودة الإنتاج وسرعة انسيابه وفاعلية الأداء فهي أقرب للفلسفية والمفاهيم أكثر منها أدوات ووسائل كالسكرام.

وعليكم السلام ورحمة الله وبركاته

أسئلتك وجهية تماما وفي محلها وبعيدة عن أي سطحية فتح الله عليك.

ERD Entity Relations Diagram هو المخطط البياني التي ترسم ويتحدد فيها معالم ومواصفات "الكيانات" و"البيانات" لتي تمثل عضد وهيكل نظام المعلومات (برنامج الحاسوب المراد تطويره). وهي تأخذ مرحلتين أساستين:

(أ) المرحلة الأولى تسمى بالتصميم المنطقي (logical design) وهي تكون بالمراحل الأولى بالمشروع بالطبع وتكون أثناء مرحلة تحديد المتطلبات وتحليلها ومن ثم وضع تصماميها الأولية هكذا. (في هذه المرحلة وفي هذا التصميم نهتم بفهم واستيعاب ووضع التصور المبدئي الكامل للمحتوى البياني الخاص بالبرنامج ولهذا سمى بـ"المنطقي")

(ب) المرحلة الثانية وهي ستكون عادة بمرحلة البرمجة واالتنفيذ الفعلي في بناء قواعد البيانات أو بمرحلة توسطية بين المرحلتين وهذا التصميم يسمى "التصميم التنفيذي" أو التصميم الفعلي (physical design) وهذا يكون التركيز فيه منصب على تطوير أو تحويل التصميم المنطقي الأولى ليأخذ صورة قاعدة البيانات الحقيقية الفعلية بجداول وعلاقات وبيانات ومفاتيح في صورتها الرقيمية داخل الخوادم والأجهزة الحوسبية.

المرحلة الأولى يقوم بها مهندسو التحليل والتصميم (المنطقي)، بينما الثانية يقوم به فريق التطوير الفني خاصة الجانب الخاص بقاعدة البيانات وبيئة التشغيل وهكذا.

وهو يعتبر جانب من التحليل والتصميم والتطوير التنفيذي لتصميمات وهياكل النظام أو البرنامج ككل، فهناك جانب المحتوى البياني بسؤالك هنا، وهناك المحتوى الوظيفي والذي يشمل وظائف وخصائص وإمكانيات النظام التي ستتعامل مع هذه البيانات، وهناك الجانب الخاص بالوجهة الأمامية للمستخدمين وهكذا جوانب عدة لنفس البرنامج منها جانب "الكيانات البيانية" والتي ستأخذ صورة جداول وبيانات ومفاتيح وعلاقات بينية مكونة قواعد البيانات.

وهذه كانت مقدمة لاعطاء صورة بشكل عام (لك وللأصدقاء عموما هنا) لهذا الجانب من التصميم، ننطلق منها للإجابة على أسئلتك الكريمة ما شاء الله:

(1 & 2) السؤال الأول وربما معه الثاني: لإنشاء برنامج محاسبة مثل دفترة وغيرها هذا الإنشاء يتطلب جانبين من العلوم هنا: جانب ملمّ بعلوم المحاسبة، وجانب ملم بعلوم ومهارات وأدوات التحليل والتصميم في صناعة البرمجيات. والمطلوب هنا توافر الجانبين فليس شرطا أن يلم بهما شخص واحد. فعندنا بشركات تطوير البرمجيات يكون مهندس التحليل والتصميم خبيرا بالجانب الثاني ثم هو خبير بالتعامل مع العملاء بمجالات المختلفة كيف يتفاهم معهم ويستخرج القدر الكافي عن عملهم (المحاسبي في حالتنا هنا) ويوصل لهم القدر الكافي من إلإماكنيات المتوفرة من الناحية التكنولوجية ومن ثم تحديد معهم متطلبات البرنامج المنشود.

وقد يختلف الأمر قليلا عما إذا كان هذا مشروع تطوير برمجيات لمكتب محاسبة أي لعميل يعمل بهذا المجال، أم كونه منتجا (product) مستقلا سيتم تطويره ويطرح في الأسواق.

وقد يختلف الأمر أكثر وهذا غالبا محل سؤالك عما إذا كانت هي شركة تطوير أم إن الأمر مشروع فردي يقوم به فرد أو مجموعة أفراد كعمل حر مثلا. بكل الأحوال وبشكل عام قد لا يتطلب منك كمبرمج أو مصمم برامج أن تتعلم وتأخذ كورسات محاسبة طويلة حتى تنشأ برنامج محاسبة حيث قد يكفيك الاستعانة بهذا الصدد بعميل أو ممثل لعميل له دراية بتلك المهنة وهذا المجال ليقوم بهذا الدور بالتعاون معك تقنيا كما ذكرنا للتو. فاختصارا "المطلوب دراسته" من قبلك أنت سيكون الإ‘لمام بعلوم ومهارات وأدوات ووسائل التحليل ومنهجيات التصميم كـ Use Cases and ERD (Unified Modeling Language ) UML

(3) جزء كبير من إجابة هذا السؤال دخلت فيما سبق هكذا، ولكن دعنا نضيف إنه يمكنك الاطلاع على شيء من المختصرات والملخصات عن هذا المجال وأنظمة العمل به ولو بشكل طفيف مبدئي كما يمكنك البحث والاطلاع ودراسة نظم المعلومات والبرامج التي طورت في هذا المجال والتعرف على الوظائف الأساسية والخصائص في معالجة البيانات والتقارير وما إلى ذلك.

(4) على حسب ما تقصد من "تصاميم جاهزة"، فإذا تقصد تصاميم كتصاميم على ورق وخرائط أو حتى في صورة قواعد بيانات فعلية فلن تجد أو يعز أن تجد، لأنه المعتاد أنك ستجد برامج جاهزة على بعضها في مجالات بعينها كأنظمة مشفى كما ذكرت أو أنظمة حسابات قانونية أو موارد بشرية أو إدارة مصانع أو برامج مخازن ومشتريات إلخ. ولكن هذه عادة ما تكون باهظة الثمن والتكاليف لضخمتها ثم من كونها مقتولة بحثا وتصميما بحيث تمثل أو صارت معايير جودة لهذه المجالات مثل برامج وأنظمة Enterprise resource planning (ERP) وهذه يصعب منافستها أو يكون مجال منافستها أنك ستقدم برنامج محدد على قد حاجة العميل وبسعر أقل كثيرا يغنيها هذه البرامج الضخمة عالية الأسعار. (لكن "ماذا تتوقع"؟ هذه الأنظمة ERPs خاصة من الشركات الكبيرة إذا استطعت مجارتها وتعلمها وكسب خبرة بتقنيتها وفنيتها فقد تكون سبيل للتعلم الذي تبحث هنا وتتساؤل)

لاحظ هنا أن فكرة تواجد تصميمات جاهزة قابلة للشراء صعبة من ناحية أن لكل عميل احتياج خاص به. وفي حالات المجالات التي تحوي مساحات مشتركة من الاحتياجات (كالتي ذكرناها: أنظمة خاصة بالمشافي أو شركات الأدوية أو إدارة مصانع أو محاسبات قانونية إلخ) فهنا يأتي دور الـ ERPs كما ذكرنا وهو مجال خاص بذاته تبزغ فيه شركات عملاقة مثل SAP Oracle تبني هذه البرامج لعملاقة لهذه الأنظمة العامة ومن ثم يتم تخصيصها (customization) حسب استخدام واحتياج المشتري العميل ولهذا فتوزيع مهندس التطوير خاصة مهندس التحليل والتصميم داخل هذه الشركات ستجده توزيع مختلفا عن الذي ذكرناه بأعلى أول الأمر حيث عندهم سيكون كل مهندس يتبع مجال بعينه يتخصص فيه فيكون مهندس أنظمة إي آر بي للمستشفيات أو المصانع وهكذا.

والموضوع كبير فأرحب بك دائما في التواصل والاستطراد بإذن الله.

الشكر موصول لكم جميعا أهل المنصة الكريمة.

الـ"’آجايل" (agile) هي طريقة أو منهجية (أو بالأحرى هي مفهوم مشترك جمع بين عدة طرق مختلفة تجمعت في مفهوم وطريقة عمل واحدة) عمل تتبع في صناعة البرمجيات وهي أول ما ظهرت رسميا 2001 بأمريكا ثم انتشرت انتشارا واسعا لأنحاء العالم دخلت منطقتنا العربية 2007 تقريبا (بشكل رسمي وبشكل غير رسمي قبلها بقليل).

وإجمالا هي طريقة عمل مختلفة تختلف عن سابقتها من الطرق والمنهجيات التي سادت من قبل كثيرا في كونها بدلا من أن تهتم بالرسميات والشكليات: سنفعل كذا على هذا النحو المحدد وبهذا الترتيب والأدوار توزع بالضبط لا انفكاك عنها وسنشتغل بالكتابة والتوثيق على الورق وتحديد كل شيء وبالتفصيل ونأخذ عليه الموافقات قبل أن نشرع في وضع سطر واحد في الكود وهكذا، فهي كانت منهجيات عمل ثقيلة الوزن بطيئة الحركة حتى أن المشاريع فيها قد يمضي منها ثلثها أو شطرها والعميل لم ير منا إلا حبر على ورق ولم يستلم منا إلى ملفات مستندية لا قيمة لها حقيقة في عمله، ومن ثم قد يمضي وقتا وجهدا طويلا قبل أن يطلع العميل على أي جزئية من البرنامج ومن هناك كانت تظهر المفاجأت (وتحين لحظة الحقيقة كما يقولون ولكن متأخرة جدا هكذا) ويبدأ الكلام هل هذا كان المطلوب حقيقة أم لا (غير أن طبيعة عمل العميل نفسه بعد شهور قد تكون متطلباته قد تغيرت) ومن هذا (وغيره كثيرا) كنت مشكلات المشاريع وتعثرها وأحيانا توقفها وفشلها الذريع (وكانت النسب في ذلك مخيفة)

ومن جاءت الآجايل في محاولة لإصلاح ذلك وبشكل جذري.

طرق ومنهجيات الآجايل المختلفة تجتمع أو تشترك على أنها: خفيفة الحركة تواكب التغيير (وليست فقط ترحب به ولكن تسعى إليه من البداية) تهتم بمشاركة العميل من البداية وبشكل مستمر أول بأول وتسعى في عرض وكذلك تسليم أجزاء من النظام تعمل وتجهز في بيئة العمل عند العميل في فترات قصيرة سريعة متلاحقة.

وأهم ما يميز الآجايل دعنا نقول ونجيب من الآخر أنها "value-driven" محرك الشغل فيها والتركيز والاهتمام (ما الذي نفعله؟ وما لا نفعله؟ وما الأوليات؟...) هو أن كل خطوة بالمشروع ودورة عمل وإدارة العمل تكون "ما هي القيمة المضافة" من هذه لخطوة بشكل مجرد عن التزام بأوراق مشروع أو أوراق عمل الشركة سواء مقاييس أو معايير شغل أو أو ... فقط كل مشروع يُعامل كأنه مشروع فريد بشكل مختلف عن غيره (حسب العميل، وحسب حجمه وحسب حجم فريق العمل وتقنيات البرمجة المستخدمة وهكذا.

يعني الآجايل نفسها بتقولك بلاش آجأيل إذا هذا سيقدم قيمة ونفع للمشروع!

_________________

وسؤالك عن لـ user story (قصص المستخدمين) مثال جيد يوضح ما سبق خاصة الفارق بين الآجايل وما قبل الآجايل:

قبل الآجايل: كما ذكرنا كان التحليل والتصميم يأخذ وقتا وجهدا (مستقطعا محسوبا مكلفا من المشروع قد تأخذ 40% من وقت المشروع ككل) لوضع تحليلات متطلبات العمل والمشروع وتحديد مواصفات المنتج وذلك على الورق. (مستندات ورقية ضخمة مليئة بالتفصيل والرسومات والخرائط ووو)

ولكن في الآجايل أشهر أداة تحليل لاقت القبول الواسع في كل طرقها على اختلافها هي أداة ومفهوم "قصص أو حكايات النظام" والمفارقة هنا أنها مجرد index card فقط بحجم كف اليد (يا ترى ماذا يمكن أن يكتب ويدون ويسجل في ورقة صغيرة بحجم كف اليد؟) يكتب فيها "عنوان" المتطلب من العميل (لأمر أو خدمة أو وظيفة أو خاصية يريدها هو في تعامله مع النظام المرتقب) مجرد عنوان وفقرة من عبارة أو عبارتين تصف القصة في سطور قليلة.

والفكرة فيها أنها مجرد "تذكرة" (بكسر الكاف أو فتحها إن شئت) لفريق العمل ومن يتواجد معهم كممثل للعميل وهذه التذكرات أو التذاكر توضع على بوورد دائم بجوارهم طوال الوقت (بوورد مقسمة to-do, doing, done, testing) ولما يأتي دور إحداها هنا يقود المحلل وممثل العميل بالفريق الشرح حولها ورسم الرسومات والخرائط السريعة أمام الجميع وتتم لمناقشة وايضاح كل ما يتعلق بهذه الخاصية المنشودة المطلوبة من النظام ومن ثم يشرع المبرمجين بإضافة وريقات صغيرة مماثلة (sticky notes) تعلق على قصة المستخدم تحت التنفيذ وتسير معها على البوورد في رحلة التنفيذ.

هنا استعاضوا عن المستندات الورقية الثقيلة الطويلة التفصيلية المليئة بالشروحات والتي كان سيرجع إليها في أوقات مختلفة خلال أسابيع طويلة وشهور (وقد يكون قد غادر المشروع أو الشركة من غادر ومن غير تواجد فعلي من طرف العميل) بشروحات آنية لحظية لكل أطراف العمل معا وفي وجود ممثل للعميل وفي وجود العميل نفسه خلال أسبوع أو أسبوعين سيرى نظاما حاسوبيا يشتغل أمامه ونأخذ منه feedback وإذا كمل وضبط يستمله يشتغل في بيئة العمل عنده. (هنا العميل يدفع العميل دفعات أمواله في المشروع مقابل برامج أو أجزاء منها شغالة يشغلها مباشرة ويستفيد منها وليست مجرد أوراق وستنادردز "وأوع وشك" على حد تعبير المصريين الدارج في غير الآجايل)

ونفس ما قيل في "قصص المستخدمين" يقال في "الوير فريمز". الـuser stories استعاضت في الآجايل عن أوراق التحليل الثقيلة الضخمة الرسمية، فالـ "wireframes" هنا هتستعيض عن الرسومات والخرائط الكبيرة المعقدة الرسمية فيما قبل أو غير الآجايل إلى رسومات وتصميمات سريعة خفيفة (قبل أن تكتب الأكواد ورائها وتنشأ قواعد البيانات حولها) بحيث تكون أداة عرض أفكار مبدئية وخيارات لتحديد وظائف وخصائص النظام الأساسية (كما ذكرنا بمساهمة سابقة هنا الأسبوع الماضي عن الفرق بين الـ releases إصدارات النظام كاملة التشغيل وبين الـ iterations دورات عمل سريعة خفيفة تمثل اشكتشات بالقلم الرصاص دعنا نصفها هكذا نستعرض فيها ونراجع الفهم والتصميم لخصائص النظام الذي يريدها العميل على وجهها قبل الشروع في تنفيذها وتصميمها الكامل.)

معذرة على الإطلة ولكنها كانت فرصة حتى نوضح للناس القيمة الحقيقة وراء الآجايل وطبيعة أدواتها ووسائلها في مقابل ما قبل و غير الآجايل.

بالنسبة لمسارهم المعرفي وتحصيل الخبرات أنصحهم بهندسة البرمجيات فهي تعتبر أهم وتشمل أبسط البرامجات والتطبيقات لأكبرها وأعقدها وبتعلّم لغات البرمجة وممارستها. (مجال AI سيأتي دوره لاحقا لمن يريد منهم التخصص فيهم والذي هو دون شك الأكثر طلبا في سوق العمل عالميا)

إجابة السؤال الأول بنعم ولا.

نعم هي تدخل ولكنها تمثل مجرد جزء أو جانب لأن أساس عملنا هو "تحليل متطلبات النظام" النظام كمجموعة وظائف وخصائص وإمكانيات وتفاعلات مع مستخدمين بخدمات مختلفة وتقارير إلخ إلخ (فالبيانات مجرد جانب في الموضوع ولذا من مخرجات مرحلة التحليل والتصميم رسومات وخرائط قواعد البيانات ولكن هنالك المخرجات الأكثر كما وكيفا وهي كيف تتداول وتعالج وتحفظ وتنشر وتجمع وتفصل هذه البيانات من خلال وظائف وخصائص النظام functions and features)

و"لا" لأنه دائما يحصل خلط دائما مع وظيفة ومجال مغاير قليلا وهو "تحليل البيانات" كمحلل بيانات بنك أو في بورصة أو أو.. فهذا المجال ينصب تعامله مع البيانات وغالبا يكون تركيزه في كيفية التعامل والاستفادة مع الكم الهائل والمتراكم من البينات (داخل البرامج والأنظمة وقواعد البيانات) فتشمل عمليات التنجيم data mining مثلا وهو أنك كيف تستخرج من البيانات بيانات ومعلومات جديدة تفيد الكثيريون عن مسار الأعمال وتريندات التعاملات واتجاه المبيعات وكذا إلى آخره فهذا عالم ومجال لحاله (وهو في مجمله يعتمد على الدراسات الإحصائية إلى حد ما دعنا نقول)

فبالنسبة لـ"الذكاء الصناعي" فهو يدخل وبشكل مباشر في مجال "تحليل البيانات" فهو لا يمثل تهديدا بل العكس هو أداة ووسيلة نافعة مفيدة جدا في هذا المجال.

أما بالنسبة لمجال "تحليل نظم المعلومات" فعلاقة الذكاء الصناعي منحصرة لما يكون نظام المعلومات المشروع في تطويره هو يخص مجال الذكاء الصناعي AI machine learning expert systems ولا يمثل أي تهديدا في نظم المعلومات والبرامج الأخرى وهي كثيرة جدا.

وبالنسبة لأبنائنا طلاب البكلوريا راعهم الله فتخصصي يُدخل إليه (رسميا) عن طريق كلية تقنية المعلومات (عندنا بمصر اسمها حاسبات ومعلومات) أو/و كلية هندسة قسم كومبيوتر. ولكن مجال تقنية المعلومات وتطوير البرامج هو يعتبر مفتوح يدخل فيه من كل الكليات عادي والمحك فيه هو التعلم والممارسة وكورسات التدريب التقنية التي تقدمها الآن بوفرة جوجل ومايكروسوفت وأوراكل إلخ. (لكن هاتين الكلتين تحديدا هما الأساس العلمي والأكاديمي الذي يوفر للطالب البناء المعرفي والأسس السليمة لهذا المجال)

وحقيقة في التعينات وتكوين أفراد فريق عمل تطوير برمجيات بكل تخصصاته لا نعبأ كثيرا لا بالشهادة العلمية ولا بالتقدير أكثر من مهارات المتقدم من الناحية العملية (الممارسة والتدريب والتنفيذ أقصد) وقابليته للتعلم والاندماج في فرق العمل بالمكان. (ولكن يبقى حاصلي كلتي الشهادتين أصحاب فرص قبول الأكبر advantage وبالفعل معظم المتميزين يكونون منهم واقعيا)

أدوات ووسائل وآليات عمل المنهجيات المتبناة داخل كل مشروع. وبالفعل عصرا الآجايل وما قبل الآجايل اختلفت فيه الأدوات والتقنيات ووسائل العمل كثيرا كما أوضحت في أكثر من تعليق (مفصل لحد ما) يمكن الرجوع إليه بدلا من الإعادة.

ولكنها في المجمل أدوات تساعد على حسن جمع المتطلبات مع العملاء (business wise) وتصنيفها ثم دراستها وتحليلها فهناك أدوات خاصة بالـ requirements management تسجل فيها المتطلبات وتصنف ويتحدد علاقتها ببعضها البعض بحيث إذا طُلب تغيير بعد ذلك يمكن الرجوع إليها وما سيترتب عليها بدقة ومن ثم حساب الكُلفة بشكل واضح للجميع.

وهنالك أدوات متعلقة برسم النمائج وخرائط البيانات ووظائف النظام وتحديد الخصائص (أدوات مثل CASE tools المشارة بالمساهمة والتي هي مثل الأوتوكاد في هندسة الإنشاءات المعمارية يُرسم فيها أبعاد النظام وتقاسيم محتوايته والعلاقات والمداخل والمخرجات والمعالجات إلخ) والتي إذا تم تفصيلها ومراجعتها (technical wise) من قبل فريق التطوير والمبرمجين والجودة والاتفاق عليها مع العميل فهي تساعد في تخليق الكود وولو بشكل مبدئي يتم البناء عليه تفصيلا بعد ذلك.

وليس شرطا أن تكون الأدوات تقنية داخل الحاسوب، فكثير من أدوات التحليل ممكن تكون على الورق (أو داخل ملفات وورد أو رسومات بـ Microsoft Visio مثلا) وهذه تكون في صورة مفاهيم ومباديء يحذا حذوها أكثر منها أداة تدار وتستعمل.

وحقيقة "الذكاء الصناعي" شحيح الاستعمال هنا في عالم أدوات ووسائل وتقنيات التحليل والتصميم هنا خاصة خاصة في عالم الآجيل لأن عامل النجاح الأساسي مبني على العقل البشري كبشر يتواصلون مع بعضهم البعض ليطلع منهم أفضل ما لديهم من مخططات عمل ونماذج وتصاميم بشكل بشري مباشر دون اللجوء إلى الآلات والأجهزة. (حتى أننا في عملنا كنا نتجادل كثيرا حتى صرنا أشبه بمدرستين واحدة تجنح كثيرا للاستعانة بالأجهزة والاستفادة منها داخل مشاريع الآجايل بينما الآخرون وأنا منهم يفضلون على التواصل البشري المباشرة: فريق عمل مشروع 6-10 أفراد يجلسون في غرفة واحدة حولهم كل لوحات المشروع بأوراقه ورسوماته ومناقشته تتحرك على الحائط خطوة خطوة حتى أن داخل الغرفة لا يحتاج أكثر من نظرة عابرة ليعرف مدة تقدم وانجاز العمل والذي يكون في دورات عمل سريعة أسبوع أو أسبوعين يتم تنفيذ فيها أجزاء من النظام ----->> يعني التركيز على إنتاج وتنفيذ الشغل نفسه وليس إنتاج اتفاقيات بشأنه)

أخبريني إن وضحت الفكرة والصورة أمامك هكذا. (ومعذرة على الإطالة)

برمجة التطبيقات ليست ضمن نطاق عمل "محلل النظم" نظريا. فهو يتعامل أكثر بالجانب الـ logical (المنطقي المعرفي التصميمي) للتطبيق ولذا فهو يمثل خلقة الوصل بين العميل والمستخدمين للنظام يتعامل معهم من واقع البيزنس بتاعهم (تطبيق مستشفيات تطبيق محاماة وقضايا شركة أدوية مصنع وزارة إلخ) ليوصلهم إلى الجانب التقني من ناحية الأخرى مع فريق التطوير والبرمجة وعالم التكنولوجيا نفسها.

ولذا فهو ينبغي أن يكون ملما مؤهلا بالتعامل بين الطرفين ليعبرهم بهم الفجوة الحاصلة فيما بينهم والتي تمثل التحدي الأكبر في أي مشروع تقني لتطوير التطبيقات. (ماذا يريد العميل والمستخدم حقيقة وهو قد لا يدري تماما ماذا أو كيف ستفيده التقنية ؟ وكيف يستوعب فريق العمل الفن

أمي مطالب العميل ويفيدونه بتطبيقهم على الوجه الأمثل)

وعادة لا يتخصص محللوا نظم المعلومات في تخصصه إلا بعد المرور على تخصص البرمجة لفترة مناسبة.

رجوعا لسؤالك: قد نستطيع القول أن "مهندس التحليل والتصميم" في مجال البرمجيات هو نفسه المهندس المعماري في الإنشاءات المسؤول عن تحديد المتطلبات ووضع المواصفات المناسبة للبناء المطلوب. (والمبرمجين هم المهندسون المدنيون بمجال الإنشاءات الهندسية)

أما لغات البرمجة والتطبيق فهي بحر واسع منذ سبعة عقود ولا زالت تتطور ويطلع منها الجديد كل ستة أشهر. وبالطبع اختيار اللغة المناسبة والبلات فورم (technical plate form, such as Java programming language and Oracle data base or Microsoft ) تفرق كثيرا حسب نوع التطبيق ونظام التشغيل ونوعية الاستخدام وعوامل أخرى متعددة تختلف من مشروع لمشروع ومن تطبيق لتطبيق.

دعني أحيلك مبدئيا هنا لجواب وسؤال الصديقة خلود بأعلى هنا. ثم قد استطرد في القول شيئا ما أن:

"تحليل البيانات" (data analysis and analytics) هي قد تعتبر فرعا من "تحليل نظم المعلومات" (information systems analysis). فرعا يتفرع ليستقل بنفسه بتخصص وعلوم وتطبيقات وحتى مجالات عمل خاصة به.

فأنت قد تبدأ بالتعامل مع البيانات بعلوم وتطبيقات قواعد البيانات (data base engine and applications) وتقنيات مثل Microsoft SQL server, Oracle DM...

ومن ثم تتعامل مع البيانات التي تخزن في تطبيقات هذه التقنيات ونظم المعلومات كبيانات مبيعات شركة حسابات مؤسسة منتجات مصنع معروضات متجر سجلات مخازن ومشتريات خدمات عملاء ملفات المرضى مثلا بمستشفيات عيادات وهكذا.

ثم يرتقي الأمر ويتبلور الاحتياج إلى الاستفادة من هذا الكم المتراكم من البيانات هذه مع مرور الوقت. تتعامل مع البيانات المسجلة هذه كما هي لتستخرج منها بيانات جديدة ومعلومات مفيدة كتريند للمبيعات عمل تصنيفات للعملاء ومعدلات شرائهم حساب توقعات مستقبلية (كما بحالة الطقس وتوقع درجات الحرارة بالخمس أيام القادمة وهكذا.

فأنت تبدأ من الاستفادة من إمكانيات الحاسوب في تسجيل وتخزين البيانات. ثم في معالجته وقدرته الفائقة على التعامل مع كم ضخم تراكمي من البيانات وفي ذلك ستسعين بعلوم وقوانين الإحصاء (statistics or operational science) فتدخل وترتقي إلى عالم الـ data mining ثم إلى كيفية الاستفادة من تقنية الحاسوب في التعلّم واستخراج بيانات جديدة بناء على بيانات قديمة مخزونة (machine learning and learning adaptive systems) كما يحصل في مراكز دعم اتخاذ للقرار حيث تختبر وتوضع الاستراتيجيات السياسية والمالية وغيرها بوضع خرائط افتراضية يتم فيها تجميع البيانات ثم توضع افتراضات بتغيير عوامل محددة بعينها (زيادة عدد السكان مثلا، الهجرة غير الشرعية، ..إلخ) ويجعلون خوادم الحاسوب العملاقة تقوم بالعمليات الحسابية المعقدة فينتج عنها صورة مستقبلة لما سيكون عليه الأمر لما ننحو هذا المنحى بتغير هذا العامل وهكذا.

فأنت تنتقل من التعامل مع قواعد البيانات والتطبيقات العادية.

ثم تنتقل إلى تطبيقات المعالجات الضخمة للبيانات لاستخراج بيانات ومعلومات جديدة، ثم توقعات جديدة ووضع مخططات افتراضية وأحيانا "خبرات" جديدة (مثل expert systems في مجال الطب مثلا يغزى بالبيانات اليومية للمرضى وتشخيص حالاتهم من قبل الأطباء وتسجيل العلاج المكتوب ثم مع مرور الوقت يستخدم هذا النظام في التسخيص للحالات المستجدة بعد ذلك وتقديم العلاج المناسب وهكذا)

وما تطبيق chatGPT منا ببعيد (وإن كنت لم يتسنى لي للآن تجربته واختباره وتكوين رأي شخصي حوله)

دعنا نبدأ بثانيا فمن طرفها ستأخذنا بشكل مباشر إلى أولا إن شاء الله.

كما أشرت ببعض تعليقات إجابات الأمس ولكن دعنا نفصل فيها أكثر هكذا:

"مهندس البرمجيات" (software engineer) , و"مبرمج التطبيقات" أو "مطور البرامج" (programmer) هما من المصطلحات أو المسميات الوظيفية اللذان إذا افترقا يجتمعان وإذا اجتمعا يفترقان. (وأول ما حضرني من مثال لهذه القاعدة قدرا هكذا مصطلحا ومسميا "الفقير" و"المسكين": فإذا اطلق أحدهما شمل الآخر معه وكأنهما شيء واحد بينما إذا اجتمعا في عبارة افترقا معناهما والحكم المتعلق بكليهما فيعتبر الفقير مّن يحتاج لـ 10 دولار في معيشته ومعه حوالي 7 بينما المسكين معه 3 فقط فأقل)

فـ"مهندس البرمجيات" و"مطور البرامج" (أو المبرمج) قد يجتمعا ويختلط معناهما واستعمالهما كدلالة إلى شيء واحد وهو التعامل والشغل في تطوير وصناعة البرمجيات. ولكن بنفس الوقت إذا اجتمعا في كلام أو موقف أو عمل (شركة) افترقا معناهما فهما مفترقان بالفعل: افتراق معنى "هندسة البرمجيات" و"البرمجة نفسها والبرمجيات".

فغالبا من يعمل بمفرده (أو في فريق عمل صغير كمجموعة من نظرائه) كمطور تطبيقات (غالبا تكون تطبيقات صغيرة ومحددة كتطبيقات الأندرويد للجوالات أو مواقع بسيطة على الإنترنت) فهو قد يجتمع فيه الوصفين والمسمين عادي وإن المتداول أكثر أنه سيقال عليه مبرمج أو مطور برمجيات programmer or software developer وعادة هيكون متخصصا في لغة برمجة بعينها أو مجموعة صغيرة وبلت فورم وتقنية بعينها خاصة بتطوير صفحات مواقع بالإنترنت مثلا أو نظام صيدلية معمول بشكل مبسط على قدر احتياجات صيدلية بعينها.

ولكن لما نأتي لصناعة البرمجيات كصناعة كبيرة وبشكل احترافي أوسع كبيوت الخبرة والحلول المتكاملة (والشركات بمشاريع متعددة مختلفة وفرق عمل كثيرة) فها هنا يبدأ الأمر في الاختلاف عن الحالة الأولى: فهنا سنتعامل وسنحتاج "هندسة" العمل للمشاريع والمنتجات (كأي خط إنتاج بمصنع يحتاج إلى هندسته وتقنياته بتقسيم العمل وتوزيع المهمات وتوظيف التقنيات لمتاحة ووضع منهجيات ومعاير لسير العمل والتطوير والإنتاج) كما يحصل في شركات مثل IBM، Oracle، Microsoft، Google، ٍSAP ومنتجات ومشاريع ضخمة مثل جوجل كجوجل أو فيسبوك أو خدمات تطوير وتطبيقات هندسية متكاملة كتطبيقات SAP تطبيق تطوّع وتركب لميكنة عمل مستشفى أو وزارة أو مصنع وهكذا.

هنا سينقسم ترم (مصطلح) software engineer لتشمل تقنيات وأدوات ووسائل ومنهجيات "هندسة البرمجيات" من تحليل وتصميم و"برمجة" (برمجة كود وتطوير قواعد بيانات وتطوير نظمة عمل وحلول متكاملة) وفريق عمل الاختبارات والجودة (هذا تخصص لحاله مهم ومستقل) وكذلك هندسة إدارة العمل نفسه هذا ككل بتحديد المعايير ودورات العمل ووضع المنهجيات وطبعا وضع المخططات وإدارة المشروع وخدمات ما قبل البيع وما بعد البيع وهكذا.

لاحظ أن مطور التطبيقات (programmer) لما يشتغل لوحده ويعمل على تطبيق لوحده أو مجموعة عمل صغيرة فهو (وهم) يقومون بهذه الأدوار معا ولو بأشكال بسيطة.

وبنفس الوقت كل هذه الأدوار كلما تعقدت التطبيقات وكبر حجمها وعظم أثرها وقيمتها احتاج الأمر إلى الفصل والتقسيم لكل هذه الأدوار التي تصبح مسميات وظيفية متباينة داخل هذه الشركات والمؤسسات وكلها تحتاج تخصص وكلها فها فكرها وتقنيات عملها ومنهجياتها وخبراتها المكتسبة. وكل هؤلاء يتخرجون في العادة من كلية حاسبات ومعلومات أو علوم الحاسوب كما ذكرت أنت في "أولا" وسؤالك الأول.

فطالب علوم الحاسب يدرس ويتعلم كل هذا، كل هذه التقنيات والتخصصات وما ورائها من علوم وأدوات وتطبيقات هندسية فيدرس ويتعلم كيف يحلل متطلبات عمل التطبيقات وكيف يضع تصاميمها بأنواعها ويدرس ويتعلم لغات البرمجة المختلفة والتقنيات والشبكات وأدوات التطوير وكذا إلى آخره.

ونصيحتي له من البداية (كطالب بأول سنة) أن يهتم على الجانب "العملي" لما يدرسه في دارسته الأكاديمية ولا يركن إلى جانبها النظري أبدأ وحسب. فعليه أن يجرب بيديه ويتمرن ويمارسه ويطبق التطبيقات العلمية لما يأخذه (بل ويسبق إلى ما وراء ما يأخذه) وأن يهتم كثيرا بالتدريبات والكورسات على الإنترنت أونلاين أو حتى أوفلاين بالمنح التي تتوفر ببلده خاصة من الشركات الكبرى مثل جوجل ومايكروسوفت وهي كورسات وتدريبات و"شهادات" سيستفيد منها كثيرا فكريا وعلميا وعمليا بعد ذلك أيما استفادة.

لتطوير برامج إدارة العمل والمشاريع، يمكن البدء بالخطوات التالية:

1. التعرف على متطلبات العمل والمشاريع الخاصة بالشركة الخاصة بك، والتأكد من أن البرنامج الذي تطوره سيجعلها أسهل وأكثر فعالية.
2. البحث عن الأدوات الحديثة والمتوفرة في السوق، والتأكد من أن البرنامج الذي تطوره سيجعلها أكثر فعالية من الأدوات الحالية المستخدمة.
3. تطوير النماذج التصميمية والخلفية للبرنامج، والتأكد من أنه يلبي متطلبات العمل والمشاريع الخاصة بالشركة الخاصة بك.
4. الابتكار في التصميم والتطوير التفاعلي، لجعل البرنامج أسهل الاستخدام وأكثر فعالية.
5. التجربة وتطوير البرنامج، التأكد من أنه يعمل بشكل صحيح.
6. التشغيل الجديد وتحسين البرنامج للتأكد من الجودة.

أكرمك الله وجبر بخاطرك.

بالنسبة لسؤالك يختلف الأمر نوعا إذا كان المراد تطوير برنامج خاص بك أو بمؤسسة عمل تعملين بها مثلا عما إذا أردتيه برنامجا عاما يشتريه الآخرون ويستعملونه في أشغالهم المختلفة (وسيختلف الأمر باختلاف الأشغال وطبيعة العمل واحتياجات المستخدمـ"ين")

ولكن بشكل عام قد يكون العامل أو القدر المشترك بين كل هذا وذاك أنك ستحتاجين للقيام بالآتي مبدئيا:

إعداد دراسة عن طبيعة العمل والمشاريع ومتطلبات الإدارة لها: مَن المستهدفين بالبرنامج سواء المستخدمين أو من سيعود عليهم بالنفع من تنفيذه؟ ثم وضع خطة ولو سريعة في التواصل معهم لاستبيان ومعرفة احتياجاتهم منه ما الذي يفعلونه الآن؟ وكيف سيغير البرنامج ويثري من حياتهم العملية هكذا؟

كيف سيتعاملون مع البرنامج وما سينتظرون منه أن يحققه لهم (مدخلات - معالجة - مخرجات)؟

ما مواصفات هذه المعالجة المطلوبة من البرنامج (وظائف خصائص اعتبارات افتراضات محاذير وهكذا)؟

مع حساب تقديري للجهد والتكلفة (واعتبار المخاطر وكيفية تلافيها أو للتعامل معها وما هي الخيارات التقنية المتاحة إلخ.

وهكذا لما تتضح الصورة بقدر كافي ويتم الاتفاق عليه بين الأطراف المعنية أو الاطمئنان إلى أن هذا الذي سيعود بالنفع المرجو عليهم. فنشرع في وضع خطةللعمل وتوزيع الأدوار والمهام وطريقة العمل ومنهجية التواصل والتسليم إلخ

وهذه بشكل عام قد تختلف تفصيلاته من مشروع لآخر ومن منتج (نظام وتطبيق) لآخر ومن فريق تطوير لآخر وطبعا من عميل لآخر باعتبارات بينية كثيرة مفتوحة هنا.

البرمجة الوظيفية (functional development or programming) تأتي مقابل البرمجة الغير وظيفية (none functional programming)

حيث تشمل الأولى وظائف وخصائص النظام (البرنامج أو التطبيق) من ناحية معالجة البيانات ودورات العمل داخله (كصندوق مغلق تدخل فيه مدخلات وينتظر أن يستخرج مخرجات: مثل ماكينة النسيج هكذا تدخل فيه القطن يخرج منها قماش) وهذه تحتوى على العمليات المنطقية التي ستكون منها البرنامج والتطبيق من معاملات حسابية جمع بيانات إجراء خدمة للعملاء وهكذا من وظائف وعلميات تجرى في أنظمة مخازن ومشتريات خدمات بيع ملفات عملاء إلخ.

فهذا يشمل "ما" سيقوم به النظام أو البرنامج أو التطبيق من عمليات ووظائف وإجراءات (معالجات) للبيانات والمعلومات داخله.

أما الثانية فتشمل "كيف" سيقوم بها النظام من ناحية سرعة المعالجة سعة التخزين عدد المعاملات لحظيا محال الأمن وسلامة البيانات وكيفية حفظها وأرشفتها هل هناك دواعي لتكاملية مع أنظمة أخرى موجودة (أو قد توجد مستقبلا) قابلية التغير (ككود برنامج وقواعد بيانات) التصميمات كجرافيك وألوان وشعار إلى آخره من خصائص ومتطلبات "غير وظيفية" والتي بالمناسبة تفرق السما من العما بين البرنامج والتطبيقات (فالسيارات مثلا كمتطلبات وظيفية تتماثل كثيرا لكن إمكانيات والخائص الغير وظيفية فيها تتباين كثيرا من سعة وجودة محركات مرسيدس لماركات أخرى بخصائص أقل)

تقصدين هنا بـ"هندسة تطوير الصناعة" صناعة السوفتوير (صناعة البرمجيات نفسها) كما بأصل المساهمة أليس كذلك؟

في الواقع المجالان مهمان متكاملان يحتاج كل منهما مَن يركز عليها ويتخصص فيه ويتطور معه باكتساب الخبرات والعلوم والتطبيقات المتعلقة به. هما مجالان مختلفان نوعا ما والشغف بهما قد يختلف من شخص لآخر فعادة أهل البرمجة كمبرمجين ومطوري برامج قد لا يستهويم كثيرا تطوير المنهجيات في العمل وقواعد الشغل ومعايير الجودة ويتركون ذلك للآخرين ويركزون هم على الكود والبرمجة نفسها التي قد تستهويهم وتشبع شغفهم وطموحهم والعكس بالعكس صحيح. وقلما ما تجدين من يجمع ببين المجالاين كحالتي (ولعل السر إني كنت أولع بالـ modeling والتصميم ووضع المتطلبات والمعايير في "هندسة البرمجيات" مما جعلني لا أجد فارقا كبيرا في نفس الأمور المتعلقة بدورات عمل التطوير نفسها)

فهما مجالان متكاملان مختلفان ولكن ليس إلى حد التناقض برأيي هكذا.