هل تصميم/رسم/رسم التنمية حل أولا ثم تطوير ذلك ؟ إذا كان الأمر كذلك كيف ؟ [مغلقة]

Question

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

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

وأنا أعلم أن هذا تتعمق في مجال UML, لكني وجدت أن لدي صعوبة في العثور على دليل مناسب استخدام مختلف أنواع الرسم ، ناهيك عن مساعدة المستخدمين من رجال الأعمال فهم الرسوم البيانية و تتصل بها.

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

Answer 1

ورقة أو السبورة!

بالنسبة وحيد deveoper ، أنصح الورق.على الأقل في البداية ، في نهاية المطاف قد ترغب في إضفاء الطابع الرسمي مع UML, ولكن لا أعتقد اللازمة لها.

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

عندما بدأت لأول مرة تفعل OOP (أو تصميم خوارزمية) ، أود أن تفعل كل شيء في رأسي حين الترميز.ولكن بعد القيام ببعض معقول المشاريع المعقدة أنا بالتأكيد يرون فائدة في رسم التفاعلات بين الكائنات المختلفة في النظام.

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

وجدير بالذكر أن TDD والقيام "سبايك"[1] مشاريع يمكن أن تساعد عند تصميم النظام أيضا.

[1] من البرمجة المتطرفة مغامرات في C#, صفحة 8:

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

Answer 2

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

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

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

Answer 3

تقرأ على Kruchten هو 4+1 الآراء.

هنا يمكنك المضي قدما.

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

2. إعطاء الأولوية لاستخدام الحالات إلى التركيز على قيمة عالية حالات الاستخدام.

3. كتابة الروايات.إذا كنت تريد, يمكنك رسم النشاط البيانية.

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

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

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

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

4. يمكنك رسم عنصر المخططات لتطوير عرض ونشر مخططات عرض المادي.هذه أيضا تكرار مثل مفهوم النظام يوسع وتهذب.

Answer 4

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

بعد المستخدم القصص مسمر, إنشاء الرسوم البيانية لوضع المسارات التي سوف يأخذ الناس عند استخدام التطبيق.

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

الخطوة التالية هي أخذ الرسومات وتحويلها إلى تنظيف شبكية.يمكنني استخدام OmniGraffle على هذه الخطوة -- هو ضوء السنوات المقبلة من Visio.

بعد هذا, قد ترغب في القيام نموذجية مخططات UML أو كائن آخر تخطيطات / وظائف المنظمة ، ولكن الناس لن تهتم كثيرا عن هذا النوع من التفاصيل :)

Answer 5

عندما أضع معا تصميم, أنا قلق مع نقل الأفكار نظيفة بسهولة إلى الجمهور.هذا الجمهور هو من (عادة) مختلف الناس من خلفيات مختلفة.ما لا نريد القيام به هو الوصول إلى "وضع التعليم" تصميم نموذج.إذا يجب أن تنفق قدرا كبيرا من الوقت أقول بلدي العملاء ما السهم مع خالص رأسه يعني وكيف هو مختلف عن الذي هو أجوف أو ما مربع يعني مقابل دائرة ، أنا لا يجعل التقدم - على الأقل ليس التقدم الذي أريد.

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

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

إذا نحن بحاجة إلى إظهار بعض واجهة التفاعل ، سأرمي معا بعض بسيطة نافذة نماذج في Visual Studio - هو سريعة وسهلة.لقد وجدت أن العميل يمكن أن تتصل بسهولة جدا.

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

Answer 6

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

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

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

لا يزال, كل نهج لقد استعملت على مر السنين ، لا شيء يتفوق على المستخدم الحصول على أيديهم على شيء أن تعلم جيدا كيف كنت أفهم المشكلة.

Answer 7

أقترح قراءة جويل المواد على "مؤلم المواصفات الوظيفية".الجزء 1 بعنوان "لماذا؟".

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

نماذج بالأحجام الطبيعية ثم يتم إدراجها في مستند Word التي تحتوي على المواصفات.

Answer 8

من المفاهيمي Blockbusting:دليل أفكار أفضل جيمس L.ادامز:

الكتل الفكرية النتيجة الكفاءة في اختيار التكتيكات النفسية أو نقص الفكرية الذخيرة....1.حل مشكلة استخدام اللغة غير صحيحة (اللفظي, الرياضية, مرئي) - كما في محاولة لحل مشكلة رياضيا عندما يمكن بسهولة أكثر أن يتحقق بصريا

(pg.71, 3rd Edition)

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

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

بالمناسبة المفاهيمي Blockbusting ينصح القراءة.

Answer 9

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

إذا من ناحية أخرى كنت تعمل على مرونة المشروع حيث أنه من الممكن إجراء تغييرات في التعليمات البرمجية بسرعة (و التراجع عن الأخطاء بسرعة), كنت قد تكون قادرة على جعل تطوري النموذج مع جميع الأعمال.التطبيق الخاص بك العمارة يجب أن تكون لينة ومرنة بما فيه الكفاية لدعم التغيير السريع (مثلا ، عراة الأجسام تصميم نمط أو القضبان-نمط MVC).فإنه يساعد على أن يكون ثقافة التنمية التي تشجع على التجريب ، ويقر بأن BDUF ليس مؤشرا العامل البرامج الناجحة.

Answer 10

4+1 آراء جيدة فقط التقني الناس.إلا إذا كانت مهتمة بما فيه الكفاية.تذكر تلك الأخيرة عشرات المرات كنت تكافح من أجل مناقشة هذه المخططات مع العملاء ؟

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

الغريب أن هناك نهجين التي عملت بالنسبة لي:

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

الخيار (1) يمكنك استخدام ما تريد, لا يهم حقا.

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

لقد انتهى من كتابة بلدي نموذج بالحجم الطبيعي أداة مرة أخرى في عام 2005 ، أصبح من شعبية جدا: MockupScreens

و هنا قائمة الأكثر اكتمالا من نموذج بالحجم الطبيعي أدوات أعلم.العديد من هذه الحرة: http://c2.com/cgi/wiki?GuiPrototypingTools