لماذا المستشفى بالضبط؟
لما لا؟ هذا مثال جيد. المشروع في كل مكان مشروع: زائد أو ناقص نفس المراحل ، نفس مخطط الإدارة ، إدارة المستندات ، إدارة المخاطر ، مراقبة الجودة ، وما إلى ذلك. في كل مكان هناك متطلبات للمعدات والمباني والبرامج. تسأل ، ما هي متطلبات المباني في نظام المعلومات؟ الأمر بسيط للغاية: موقع محطات عمل المشغل ، الخادم - كلاهما يتطلب تكييف الهواء. فيما يلي متطلبات المبنى. ولا يكاد أي شخص يشك في ما إذا كان المستشفى يحتاج إلى برنامج. إذا كنت ترغب في البقاء على اطلاع ، فستواجه مهمة إنشاء مؤسسة طبية آلية ذات سجلات طبية إلكترونية ، حيث يقوم الأطباء بفحص الأجهزة اللوحية ، على سبيل المثال ، يقوم الممرضون بوضع علامة على المرحاض المغسول ليس على الورقة ، ولكن على الهاتف. سيكون هناك الكثير من متطلبات البرامج في هذه الحالة. وبمجرد الحاجة إلى البرنامج ، ستكون هناك حاجة إلى تثبيت الخادم ، ووضع المشرف والمشغلين في مكان ما. كل شيء مترابط.
لقد اخترنا مشروعًا إنشائيًا لأنه من الأسهل شرح كيفية تصميم عنوان IP. نظام المعلومات مخفي في مكان ما بالداخل ، ولا نراه ، والجدران هنا أمامنا: منحنية ومائلة ، مع ممرات مسدودة ، لأن المشروع تم إجراؤه على الركبة ، وقام العميل بتغيير متطلباته مائة مرة أثناء اللعب.
رمز البرنامج بالداخل (ولكن لا أحد يرى ذلك)ما علاقة المستشفى به إذا قمنا بتطوير برنامج؟
ومن هنا ، أعزائي المطورين ، التنفيذيين ، المحللين ، المختبرين.
ليس البرنامج الذي تقوم بتطويره ... خذ Android ، هذا برنامج. وإذا كان لديك ، على سبيل المثال ، نظام محاسبة ، فأنت تتعامل بالفعل ليس فقط مع البرامج ، ولكن مع نظام المعلومات.
الفرق واضح. إذا قمت بشراء هاتف ، فكل شيء بسيط: قم بتشغيله ، يبدأ رجل أخضر (Android) ، استخدمه. وإذا اشتريت صندوقًا ببرنامج محاسبة ، فمن الواضح أنك الآن بحاجة إلى خوادم ، فأنت بحاجة إلى تكوين الشبكة ، وتهيئة محطات العمل ، وتدريب الموظفين ، ودمج النظام مع عناوين IP للمؤسسات الأخرى ، ودفع النظام في وضع الاختبار. نعم ، والمحاسبون بحاجة إلى الإقناع بطريقة ما بالانتقال إلى البرنامج الجديد ، ليسوا جميعًا مستعدين للابتكارات. بشكل عام ، في أي مشروع لتكنولوجيا المعلومات ، 10-20 ٪ هو تكنولوجيا المعلومات ، وكل شيء آخر هو تدابير تنظيمية وإدارية ، جيد ، كثيف للغاية ، مجوهرات ، العمل مع الموظفين.
نظام المعلومات (هل هو برمجيات فقط؟)وأخيرًا ، نتذكر تعريف النظام من التسعينات البعيدة ، والذي لم يلغه أحد:
النظام المؤتمت: نظام يتألف من موظفين ومجموعة من أدوات الأتمتة لأنشطته التي تنفذ تكنولوجيا المعلومات لأداء الوظائف القائمة.
GOST 34.003-90. تكنولوجيا المعلومات. مجموعة من المعايير للأنظمة الآلية. الأنظمة الآلية. المصطلحات والتعاريف.
أي أن IP في المقام الأول هو الأشخاص ، بالإضافة إلى التكنولوجيا التي تساعد على أتمتة أنشطتهم ، وليس العكس.
كيف تصمم مستشفى
تخيل أنك مؤسسة بناء ، ويأتي إليك عميل ويطلب منك بناء مستشفى في مثل هذا المكان. هل ركضت على الفور لوضع الطوب أو ...؟ إذا نظرت إلى عدد المرات التي يتم فيها إنشاء أنظمة المعلومات ، فهي: يبدأ المؤدون على الفور في "التدخل في الخرسانة وشراء العبوات الزجاجية". مثلًا ، لن يعمل الأمر بهذه الطريقة - سنعيد البناء! سنعيد البناء حتى نحقق النتيجة المرجوة.
ومع ذلك ، إذا كنت مؤسسة جادة ، فقدم أولاً للعميل تصميمًا للبناء. هل توافق على ذلك؟ ولماذا هو خطأ في نظام المعلومات؟ ربما ليس الفرق بين البناء وتطوير البرمجيات ، ولكن في حالة المستشفى نفسه ، يفكرون كثيرًا ويخططون ثم يبنون ، ثم يطورون ثم يفكرون في البرمجيات؟ أليس هذا سبب سماع الكثير عن مبرمجي krivoruky ، ولكن لا شيء عن نفس العمال المهاجرين في موقع البناء؟ يعمل البناؤون في المشروع ، على عكس المطورين.
هكذا دائمًا بدون مشروع ، حتى لو لم يكن مرئيًانحن نعتبر الآن عملية التصميم بمزيد من التفصيل. لديها عدة مراحل. لماذا نحتاج أن نمر بعدة مراحل ، فلماذا لا نفعل ذلك في وقت واحد؟ من أجل الوضوح ، سأعطي مثالًا للمدرسة ... كم عدد السنوات في المدرسة التي كانت تدرس عملية الضرب؟ أنت تقول شهرًا أو شهرين ، وستكون مخطئًا بشكل أساسي. نعم ، كيف تضرب 5 في 6 ، تمر في أسبوع. يتم تعليم وقت معين جدول الضرب. وضرب الكسور ، والأرقام بدرجة ، واللوغاريتمات ، والتعبيرات بين قوسين ، والأرقام المعقدة ، مما يرفع عدد الأشخاص الذين يدرسون؟ تقريبا كل سنوات الدراسة! اتضح أننا ندرس نفس الضرب كل عام من زوايا مختلفة.
ولماذا لا يتم دراسة هذا في الصف الأول؟لذا ، فإن أي عملية للتعلم والتصميم تكون دورية. أولاً ، حصلنا على مفاهيم عامة حول الأرقام ، ثم تعلمنا كيفية أداء إجراءات بسيطة معهم ، ثم تعلمنا عن الكسور وتعلمنا كيفية العمل معهم ، وما إلى ذلك.
أولاً ، أدركنا المشكلة التي يجب حلها بمساعدة نظام المعلومات. ثم حددنا دائرة المهام التي يتعين حلها ، وفهم ما يجب أن يفعله النظام ، وما هي الإجراءات التي يجب على الموظفين القيام بها. ثم فكروا في كيفية قيام النظام بتنفيذ المهام المحددة مسبقًا. يمكنك تخطي هذه الخطوات ، كل ما عليك فعله هو العودة وإعادة كل شيء: قم بالقياس سبع مرات وقطع مرة واحدة أسرع بكثير من العكس ، وستترك مواد أقل.
نعطي مثالا آخر. أنت في الجزء العلوي من الجبل تنظر إلى الأسفل بمنظار قوي وتحاول إنشاء طريق مفصل. في العدسات ، يمكنك رؤية كل حصاة على الطريق ، كل بركة. ولكن هذا هو المسار وما إذا كان يؤدي إلى الأعلى مع مناظير غير مرئية: لا توجد خطة عامة. سيقوم المتسلق المعقول أولاً بتحديد مسارات الهبوط بالعين المجردة ، ثم سيتم فحصها تحت تكبير قوي. بمجرد أن تغوص في التفاصيل ، تفقد وجهة نظرك العامة للمشروع. مع أخذ المنظار على الفور ، من الأفضل أن تصف 10 وظائف ، بينما تنسى الوظائف الأربعين الأخرى ، ولا تذكرها بشكل عام.
يمكن رؤيته بشكل جيد ، ولكن فقط جزء صغيرتعقيد التصميم المرحلي هو أنه في بداية العملية يجب عليك العمل بمفاهيم مجردة. لذلك أريد أن "أشعر" بشيء جاهز ، ولا أتحدث عن متطلبات ووظائف ومهام وعمليات معينة. رسم واجهة المستخدم على الفور أسهل ، ولكن من السهل أيضًا تفويت نصف المتطلبات على الأقل. إذا قمنا في البداية بعمل قائمة تفصيلية بالعمليات التي يجب على المستخدم إجراؤها عند العمل مع نموذج شاشة أو آخر ، فسيتعين على المصمم فقط الرسم وليس التخيل ، كما هو الحال غالبًا.
انتقل الآن أخيرًا إلى مراحل التصميم.
1. وضع المتطلبات العامة
لذا ، لنفترض أنك مصمم. يأتي الزبون إليك ، "أرسل" من قبل بناة مسؤولين. يطلب منك العميل بطبيعة الحال تطوير مشروع مستشفى. اركض إلى Kuhlmann و ... حسنًا ، هذه العصور القديمة - أطلق ArchiCAD وارسم.
ولكن بالطبع لا يتعلق الأمر بك. أنت محترف وتبدأ في طرح مجموعة من الأسئلة "الغبية". وأهمها - لماذا تحتاج لبناء مستشفى؟ ما هو الغرض من البناء؟ إذا لم يكن الهدف واضحًا ، فلن تكون قادرًا على الإجابة على السؤال ، إذا كان مستشفى كبيرًا أو مستشفى صغيرًا ، ما هو الملف الشخصي ، من المجهز. لسوء الحظ ، غالبًا ما يقول العملاء الكثير من الأشياء المثيرة للاهتمام ، باستثناء الشيء الرئيسي - ما هو هدفهم. هنا من الضروري "سحب" منهم في المقام الأول. ويجب عليك طرح سؤال. العميل نفسه ليس متخصصًا ، لديه فكرة ، وعلى هذا يرى دوره يتحقق. إنه لا يفهم ما هو الطريق الذي يتخذه لتحقيق فكرته. كقاعدة ، يتوقع العميل معجزة قديمة جيدة - أن يأتي إلى شاطئ البحر ، يرمي صافيًا (يدفع المال) ، ويصطاد سمكة ، وسوف تحقق رغبته ... ولكن يحدث كما هو الحال في نكتة عن رجل ثري ، بعد أن اصطاد سمكة ذهبية ، طلب تحقيق رغبة واحدة: " أريد أن يكون كل شيء معي! " أجابت السمكة: "لا مشكلة. كان لديك كل شيء ..."
لفهم هدف المشروع ، لا يكفي عمل جملتين مع مجموعة قياسية من العبارات. عادة ما يتم تحديد هدف المشروع على أساس المعارضة: يصفون نموذج المعلومات الحالي (على سبيل المثال ، يجلس الأشخاص في الأرشيف ويرتبون من خلال الأوراق) ، ثم عيوبه (بسبب نقص الأتمتة ، يشارك 10 أشخاص في الأرشيف ، وهو أمر فاضح بشكل واضح ، لا يمكن للأقسام الأخرى تلقيه لأسابيع من الأرشيف المعلومات التي يحتاجونها ، وما إلى ذلك) وتقديم حل (لتقديم برنامج يسمح بإجراء عدد من العمليات في الوضع الآلي ، يجب سرد العمليات). إذا تم تقديم نوع جديد تمامًا من الخدمات إلى السوق ، فمن الضروري دراسة السوق الحالية و "انتقاد" الأدوات المتاحة هناك ، ثم اقتراح حل.
بالإضافة إلى ذلك ، من الضروري في هذه المرحلة تحديد المتطلبات التشريعية التي يجب أخذها في الاعتبار ، وكيفية تنفيذ عمليات معينة بشكل قانوني ، وكيف سيتم تسييل الخدمة الجديدة ، وكيف يتم التخطيط لدخول السوق ، وكيفية الاهتمام بالمشاركين الخارجيين في النظام الجديد.
وبعبارة أخرى ، ينبغي وضع نموذج عمل. من ناحية ، هذه ليست مهمة المطورين ، ولكن من ناحية أخرى ، بدون تعريف واضح للهدف وكيفية تنفيذه ، ليس من الواضح ما هي المهام التي يجب أن يحلها النظام. وإذا لم يقم العميل بنفسه بصياغة واضحة لما يحتاجه ، فمن غير المحتمل أن يكون راضياً عن بعض النتائج على الأقل.
2. اختيار مفهوم النظام
في هذه المرحلة ، من الضروري اختيار الحلول التقنية العامة التي يمكن من خلالها تلبية المتطلبات المقدمة في المرحلة السابقة. سواء كان تطبيق ويب أو عميل أصلي أو عميل كثيف أو قاعدة بيانات رقيقة أو مركزية أو موزعة أو DBMS العلائقية أو noSQL أو الخدمات المتجانسة أو الدقيقة أو Java أو Python. غالبًا ما يتم نسيان مناقشة هذه المشكلات في الوقت المناسب ، ثم اتضح أن أحد المبرمجين اختار أداة معينة بشكل مستقل ، وفي النهاية لا يسمح هذا الحل بتحقيق الهدف.
3. تطوير الاختصاصات
اختار المتطلبات العامة للمستشفى ، اختار المفهوم. "حسنًا" ، سيقول العميل ، "الآن كل شيء واضح ، يمكنك الرسم". هل هذا ممكن؟ المتطلبات عامة ، يجب أن تكون مفصلة. على سبيل المثال ، في الخطوة الأولى ، قررت أنه يجب أن يكون هناك مختبر لفحص الدم. ولكن أي نوع من المعدات سيكون هناك ، وكم تستهلك الكهرباء والهواء المضغوط (ماذا لو؟) ، هل تحتاج إلى مصابيح الكوارتز للتطهير ، طاولات المختبر ، التهوية؟ بدون هذا ، سيكون من الصعب التصميم. هذا هو الأول. وثانياً ، من الضروري وضع خطة لبناء مستشفى وإعداده وتشغيله.
بالنسبة لنظام المعلومات ، فإن تطوير الاختصاصات (TOR) هو الجزء المركزي من المشروع. تصف
الاختصاصات :
- ماذا يجب أن يفعل النظام.
- ما يجب أن يكون الهيكل العام للنظام.
- كيفية إنشاء نظام.
أي أن الاختصاصات تحتوي على متطلبات وظيفية وغير وظيفية ، بالإضافة إلى متطلبات مراحل التطوير والتسليم والقبول والتوثيق. أيضا في ToR يجب أن توصف بإيجاز العمليات التي أتمتة في الواقع.
عند وصف وظائف النظام (وهذا هو الجزء المركزي من الاختصاصات) يجب فهمها - نعطي متطلبات لما يجب أن يفعله النظام ، وليس كيف. بالنسبة لك ، يجب أن يكون اتساع التغطية أكثر أهمية من العمق. على سبيل المثال ، في المرحلة الأولى (إعداد المتطلبات العامة) ، حددنا الحاجة إلى وظيفة حظر تسجيل دخول المستخدم. أشار بيان العمل إلى أن الحساب محظور إذا لم يتم استخدامه لمدة 90 يومًا أو بعد 6 محاولات فاشلة لتسجيل الدخول ، يمكن للمسؤول تقييد الوصول لفترة معينة من الوقت ، عند محاولة دخول مستخدم محظور ، يجب عرض رسالة ، إلخ. وفي المشروع الفني (دعنا نتقدم على أنفسنا) ، سنرسم نموذجًا لبطاقة المستخدم مع علامة القفل وتاريخ إلغاء القفل ، ونكتب برنامجًا نصيًا لتسجيل الدخول إلى النظام ، والذي سيتحقق من الحظر ، ويفتح تلقائيًا بعد فترة محددة ، والحظر في حالة محاولات تسجيل الدخول الفاشلة ؛ دعنا نحدد ما يتم من جانب العميل وماذا يتم من جانب الخادم.
أود فضح العديد من الخرافات المتعلقة بتطوير
المواصفات الفنية .
الخرافة الأولى: تحتوي المعارف التقليدية على متطلبات المقاول فقط.لا ، المعارف التقليدية هي كيفية إنشاء نظام ، وهناك أقسام في الاختصاصات يمكن فيها وصف توزيع المسؤولية.
الخرافة الثانية: في الشروط المرجعية ، غالبًا ما يكون هناك الكثير من "الماء".في الواقع ، غالبًا ما تحتوي المعارف التقليدية على معلومات عامة حول النظام ، لكنها مطلوبة. على سبيل المثال ، ناقشنا وناقشنا متطلبات النظام ، ونتيجة لذلك ، أدرك أحد الفريق أنه من الضروري تطوير تطبيق لنظام Windows ، والآخر للمتصفح. يعتقد أحدهم أن النظام كان يسمى ذلك ، والآخر باسم مختلف. يبدو أن الأمور واضحة ، ولكن يجب أن يفهمها جميع أعضاء الفريق وجميع المتخصصين المعنيين بشكل متساوٍ.
الخرافة الثالثة: متطلبات الموظفين والخوادم وقنوات الاتصال والإداريين وأنماط التشغيل غير ضرورية ، كما هي في مجال مسؤولية العميل.أولاً ، كما ذكرنا من قبل ، يتم كتابة المعارف التقليدية للجميع في وقت واحد ، وثانيًا ، تصف المعارف التقليدية كيفية جعل النظام يعمل ، وليس فقط البرنامج المكتوب. خلاف ذلك ، سيكون هناك صندوق آخر ملقى على رف مع قرص وتعليمات سميكة. وبالتالي ، فإن الجزء التنظيمي من المعارف التقليدية ، والمتطلبات غير الوظيفية ، لا يقل أهمية عن المتطلبات الوظيفية.
نحن نعتبر إعداد المعارف التقليدية بمزيد من التفصيل في مقال منفصل.
إن تطوير الاختصاصات وفقًا لـ GOST 34 سهل وبسيط .
4. تطوير مشروع تقني
لذا ، انتقل. هنا أمامك (اعترفنا أنك مصمم) .الشروط المرجعية لبناء مستشفى مع قائمة ضخمة من المتطلبات. تجلس ، تنظر بحزن إلى 100 صفحة من المعارف التقليدية ، ولا تعرف من أين تبدأ. ثم تبدأ الصورة بالتدريج بالتدريج. أنت تفكر: نعم ، نحن بحاجة إلى العديد من الأمتار تحت الأجنحة ، والكثير تحت المطبخ ، والكثير من المساحة المتبقية ، والمختبر ، وغرف التمريض وما إلى ذلك. ثم يولد الكثير من الرسومات ، والرسومات ، والخيارات ، وتعيد تشكيلها ، وتبديل الغرف ، باختصار ، تبحث عن أفضل نسبة. ثم انتقل إلى التفاصيل - الرسومات والرسومات والمخططات: الجدران والأبواب والنوافذ وقنوات الكابلات والأسلاك والأنابيب والتهوية والأرضيات ومواد الحائط والتشطيبات ... وما إلى ذلك وما إلى ذلك. بشكل عام ، بالتفصيل قدر الإمكان ، حدد كيف يجب أن تبدو المستشفى وتعمل بعد الانتهاء من البناء.
عند تطوير مشروع تقني لنظام المعلومات ، يلزم تقديم وثائق تحتوي على ما يلي: سيناريوهات تفصيلية تصف تشغيل وتفاعل النظام المطوّر والمستخدمين والأنظمة ذات الصلة ؛ التخطيطات التفصيلية لواجهة المستخدم التي تحتوي على وصف لنوع البيانات وسلوك كل عنصر من عناصر الواجهة (القيمة الافتراضية ، والظروف التي يمكنك بموجبها تغيير قيمة الحقل ، والرؤية ، والإجراءات التي يقوم بها النظام عندما يتغير العنصر ، وما إلى ذلك) ؛ وصف البروتوكولات للتكامل مع الأنظمة والمعدات ذات الصلة ، ونماذج التقارير ووصف خوارزمية تكوينها ، وهيكل الخوادم وقواعد البيانات ، إذا كانت هناك عدة.
عادة ما يكون هذا أكثر من كافي لتكون قادرًا على إعطاء المستندات للمطورين والحصول على نتيجة معقولة. توفر النماذج والنصوص التفصيلية معلومات كافية حول سلوك النظام والواجهة ، بالإضافة إلى بنية البيانات. سيتم وضع المطورين في إطار ضيق يمكنك التخيل فيه ، ولكن بعد ذلك لن يخرجوا.
آمل في المقالات التالية أن ندرس بمزيد من التفصيل كيفية إجراء التصميم الفني بطريقة عالية الجودة ، وكيفية تطوير نماذج ، وسيناريوهات ، وما هي المستندات التي يجب وضعها.
5. تطوير وثائق العمل
السؤال المنطقي هو ما هي وثائق العمل للمستشفى؟ حقا تعليمات لتنظيف الممر ؟! يمزح كنكتة ، هل تحتاج للحفاظ على نظام الحريق؟ من الضروري. والمصاعد؟ ماذا عن شبكات الحاسوب؟ وإمدادات المياه؟ "حسنا ، هذا لا ينطبق على مشروع المستشفى!" - تقول. نعم ، هذا صحيح جزئيا. ومع ذلك ، يتم تسليم المستشفى للعميل ككل ، ويجب أن تحتوي جميع الأنظمة على وثائق التشغيل المناسبة. ولكي يكون التغيير سريعًا وناجحًا ، ستضع قائمة بالمتطلبات ، والتي يمكنك مقابلها التحقق مما إذا كان كل شيء على ما يرام.
يعد وجود أدلة المستخدم والمسؤول عن IP معيارًا ، مع كل شيء واضح. ولكن غالبًا ما يفكر العميل في عملية قبول النظام في اللحظة الأخيرة. وعبثا. لهذا ، هناك وثيقة ممتازة ، "منهجية البرنامج والاختبار" ، وعادة ما تتعلق أيضا وثائق العمل. إنها نوع من القائمة المرجعية تحتوي على وصف لإجراءات التحقق. إذا تم إعداد هذا المستند مسبقًا (ويمكن استعارة النص البرمجي ، كأساس ، من المشروع الفني) ، فسيكون لدى المطورين معيار واضح لقبول عملهم. لا تحتاج إلى المبرمجين الخاصين بك أو الاستعانة بمصادر خارجية لإثبات قضيتهم - هناك سيناريو ، يجب العمل عليه. ولن تكون هناك مشاكل مع العميل - فالخيال محدد بالفعل في المستند.
وأين مكان رشيقة؟
بعض الأشخاص الذين لديهم يدين خلف Agile (أو طرق تطوير "مرنة" أخرى) ، والبعض الآخر يعارضها بشدة. كاتب المقال له رأيه الخاص: رشيقة جيدة جدا ، ولكن في صميم الموضوع. وعادة ما يستخدمونها لأغراض أخرى.
أخبرني ، عشاق Agile ، هل من الممكن استخدام هذه التكنولوجيا لتحديد النتيجة التي تحصل عليها في نهاية التطوير والتكلفة والشروط؟ لا؟
حسنًا ، كم عدد الحمقى الذين ستجدهم مثل هؤلاء العملاء الذين يشاركون في العمل بنتيجة وميزانية ومدة غير واضحة؟ هل يمكنك طلب فريق إصلاح شقق باستخدام Agile؟ وهكذا ، رشيقة لديها مكان ، ولكن للمشاريع الداخلية. يمكنك إجراء الإصلاحات بنفسك بقدر ما تريد ومراجعة كل شيء عدة مرات. بالنسبة للعملاء الخارجيين ، هذه عملية احتيال يطلق عليها مصطلح ذكي (أنت ، بالطبع ، لن توافق على هذه الصيغة ، ولكن تحاول إقناع العميل بنفس الشيء).يعتقد الزبون: وكم سيقودوني حول الأنف؟ثانيًا ، إن Agile جيدة في الابتكار ، حيث ليس من الواضح نوع النتيجة التي تريد الحصول عليها ، أو طريقة تحقيقها غير واضحة. هذا يسمى الوسواس القهري ، التطوير التجريبي. أو حتى البحث والتطوير - البحث والتطوير. في أي مصنع هناك ورشة تجريبية حيث يتم الحصول على النماذج الأولية مع ملف ، وإعادة تشكيلها عدة مرات. تخيل أنك بحاجة إلى إعادة تطوير شاشة اللمس وجميع الإيماءات والسلوك. هنا يجب عليك حقا المحاولة والمحاولة ، لا يمكنك وصف السلوك مقدما. ولكن هل تواجه في كثير من الأحيان مهام من هذا النوع؟ يجب التمييز بين الهندسة والبحث. في الأساس ، نحن مهندسون تصميم نظام المعلومات.ثالثًا ، في مشروع كبير ، قد تكون هناك مراحل يتطلب فيها الوسواس القهري ، ثم رشيقة للمساعدة. لا أحد يزعج استخدام العدو السريع على مستوى التخطيط التشغيلي. على العكس من ذلك ، إنها تقنية مريحة للغاية: خطط لمدة أسبوع أو أسبوعين وقم بمراقبة النتيجة باستمرار. على المستوى الاستراتيجي ، التخطيط المتتالي ، على المستوى التكتيكي ، التكراري. ولا تناقضات!لسوء الحظ ، في كثير من الأحيان ، أثناء "الوعظ" لأجيل ، يحاول المطورون إخفاء عدم قدرتهم على تطوير مشروع نظام (أو أنهم لا يعرفون حتى أن هذا ممكن). إنهم يتصرفون بالطريقة الأكثر ملاءمة لهم: سننتهي وننتهي من أجل أموال العميل. في حين أن لا أحد يتحكم في التكاليف ، فإن هذا يفلت تمامًا. ولكن بعد ذلك ، قد يشعر المراقب الخارجي (الرؤساء) أن العملية موجودة ، ولكن لا توجد نهاية وحافة ، ولا توجد نتيجة مرئية. حاول أن تنظر ليس فقط من برج الجرس الخاص بك.أين يمكنني معرفة المزيد عن تصميم نظم المعلومات؟
هناك العديد من الكتب حول هذا الموضوع. سميكة وليس كذلك. لكن الكتاب هو دائمًا تجربة ALIEN. ولديك شخصية مختلفة ، ووضع عظيم ومشروع. هناك مثل هذا النظام TRIZ - نظرية حل المشاكل الإبداعية. يحاول مؤلفها ، Altshuller ، شرح الخطوات التي عليك اتخاذها لابتكار شيء ما. اتضح؟ بشكل عام لا. تنص المبادئ على أنها مثيرة للاهتمام ومفيدة ، ولكن لا يخرج قالب واحد وفقًا للاختراع. كل شخص يفكر ويبدع بطريقته الخاصة ، ومن المستحيل تعليم هذا ، يمكنك التعلم فقط. من الضروري استخدام تجربة شخص آخر ، من الغباء عدم استخدامها ، ولكن يجب أن تكون من ذوي الخبرة (تتم معالجتها) ، وتحول إلى تفكيرك. نسخ المعجزة لن تنجح.إذا كنت ترغب في تعلم التصميم ، أقترح أن تأخذ المواصفات القياسية للدولة من السلسلة 34 كأساس. هذه تحفة حقيقية ، نتيجة عمل معاهد بحثية كاملة. خلال تطوير هذه المعايير ، تمت دراسة العشرات (إن لم يكن المئات) من أكثر المشاريع تعقيدًا لأتمتة الأنظمة المختلفة. تراكمت التجربة الهائلة.من الصعب إتقان هذه المعايير ، ولن تتعلم كيفية استخدامها من لحظة. لذلك ، سنحاول الكشف عن جوهرها في المقالات اللاحقة.اقرأ استمرار: بعض الملاحظات حول تصميم نظم المعلومات .قراءة مقالات أخرى للمؤلف: