كيفية تحديد نهاية عمر تطبيق الويب؟[مغلق]

Question

يمكن أن يثير هذا السؤال الكثير من الآراء، ولكن ما أود الحصول عليه هو مجموعة من التدابير التي ستساعدني وشركتي في تحديد نهاية العمر الافتراضي للمنتج الذي نبيعه.

نحن نبيع نظام CMS، ومن خلال هذا النظام نقوم بإنشاء عدد قليل من المنتجات الفرعية

• المواقع الإلكترونية
• منشئ الاقتراح
• تعقب الحملات التسويقية

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

من فضلك النصيحة،

جغرافية

---

شكرا للجميع!أنا أقدر حقًا تعليقاتك وآراءك وأفكارك حول هذا الموضوع.

سأتناول بعض الأسئلة المتعلقة بالنشر في القائمة أدناه

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

سأستمر في إضافة الإجابات بينما أقرأ لك جميع الردود.

Answer 1

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

هذه إقتراحاتي:

• اطلب من مطور صغار الانضمام إلى هذا المطور الحالي.
• تفريغ معظم التحديثات المستقبلية على مطور المبتدئين (بمساعدة من Sr. Developer)
• اطلب من المطور المبتدئين القيام بتوثيق عمله
• اطلب من Sr. Developer مراجعة الوثائق

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

.

تمديد هذا الحل مع اقتراح Jefferey أدناه ("في بعض الأحيان إعادة الكتابة هي استثمار جيد.")

إذا كنت لا تزال ترغب في إسقاط التطبيق الحالي وإعادة كتابةه ، فلا تزال بحاجة إلى توثيق النظام الحالي وإنشاء متطلبات لنظام جديد استنادًا إليه.

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

---

وفقًا لتعليقاتك (GEO)

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

• متطلبات العمل لـ CMS
• مواقع الويب
• منشئ الاقتراح
• تتبع حملة التسويق

هذه إقتراحاتي

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

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

Answer 2

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

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

Answer 3

وصل التطبيق إلى نهاية الحياة في اللحظة التي يتم شحنها دون أي نوع من الوثائق. ابدأ التطوير الآن ، وقد ترغب في التفكير في استبدال الشخص الذي يعرف النظام الأصلي. إذا ذهبوا 6/7 سنوات دون إنشاء أي نوع من الوثائق على الإطلاق ، فهي ليست شخصًا تريده في شركتك.

Answer 4

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

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

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

Answer 5

لجعل قصة طويلة قصيرة: أنا في وضع مماثل.

• طالما أن هذا التطبيق يشبه CashCow ، لكن الشركة لا تستطيع تحمل (أو تنوي) تطوير تطبيق جديد ، فلن يموت قبل أن يقرر العملاء شراء نظام أعذب.

• إعادة الكتابة بدون متطلبات (موثقة) يكاد يكون مستحيلًا.

• على الأقل تجربة الإدارات المتخصصة ، ينبغي توثيقها بطريقة مفيدة لمزيد من التطورات.

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

Answer 6

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

Answer 7

هذه هي نوع الأشياء التي قد أفكر فيها عند تحديد ما إذا كان النظام قد يسير "نهاية العمر":

هل الوظيفة التي يوفرها هذا النظام متاحة للمستخدمين النهائيين في نموذج أرخص وأكثر موثوقية أو أسهل في الاستخدام؟ إذا لم يكن الآن ، فمتى يكون هذا محتمل؟ هل هذا المنتج لذلك قابلاً للتطبيق على المدى الطويل؟

هل هذا مكتوب في تقنية سيؤديها العملاء بعيدًا عن ذلك لأنه سيكون من المحرج أن يتفاعلوا مع منتجاتهم ، أو يطلبون منهم تشغيل منصات "عفا عليها الزمن"؟ هل ستعطي العميل المحتمل انطباعًا بأن شركتك بشكل كبير من المحتمل أن لا يزال على ما يرام ، على ما يرام ، حتى في عام 2010 ، ولكن من المحتمل أن لا يكون ذلك على توافق WIN16.

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

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

إذا كان مدعومًا ، فهل يقوم البائعون بشحن علاوة على دعم منصة أقدم؟ إذا لم يكن الأمر الآن ، فكم من الوقت قبل أن يفعلوا؟

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

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

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

Answer 8

مررت بعملية مماثلة. كان لدينا تطبيق ويب تم تشغيله منذ ما يقرب من 8 سنوات. في ذلك الوقت ، تم إجراء الكثير من الصيانة ، وتمديدها بطرق لم نتخيلها. ومع ذلك ، كان النواة جيدة وكان لا يزال قادرا على امتداد.

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

بعد التحليل ، عرفنا أنه يمكننا استبداله في غضون 12 شهرًا بوظائف متطابقة وأن هذه الوقت سيؤتي ثماره بسرعة.

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

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

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