مشکل در پاسخ دادن به کامنتها

اهالی محترم وبلاگستان، منطقه صنعتی وردپرس اونهم از نوع دات ارگ
با سلام
احتراما اینجانب که از مشتریان پروپاقرص وردپرس.ارگ میباشم، با این نرم‌افزار CMS مشکل دارم! مشکل از اینقراره که با اینکه هر دو آپشن E-mail me whenever یعنی  (Anyone posts a comment و A comment is held for moderation) را فعال کرده‌ام، 2 تا مشکل دارم:
1- بعضی وقتها ایمیل برام نمیاد!
2- قبلا ایمیل که میومد، وقتی reply میکردم، بطور اتوماتیک آدرس ایمیل نویسنده کامنت در قسمت آدرس گیرنده ایمیل قرار میگرفت. اما الآن آدرس  wordpress@midinternet.com در قسمت آدرس گیرنده قرار میگیره!!
لطفا بفرمایید چگونه باید این مشکلات را حل کنم؟؟؟

با تشکر و احترام فراوان
امضا: یک وبلاگنویس کوچک

9 Replies to “مشکل در پاسخ دادن به کامنتها”

  1. خسروبیگی

    با تشکر از رضا بخاطر راهنمایی در تایپ لـله‌گانی!
    برای تکمیل اطلاعات ایشون اینم بگم که:
    با ترکیب Alt و 0157 میتونید نیم‌فاصله تایپ کنید
    این « نیم فاصله » رو با این « نیم‌فاصله » مقایسه کنید!

  2. agha reza lalaegani

    علل اصلي شكست پروژه‌هاي نرم‌افزاري
    Lorin j. May
    ترجمه و تلخيص: وحيد نبى‌ئيان

    چكيده
    اين مقاله به بررسي علل اصلي شكست پروژه‌هاي نرم‌افزاري مي‌پردازد. رويكرد اين مقاله پروژه‌هاي بزرگ نرم‌افزاري است ولي از آنجا كه مسايل مطروحه مبتلابهِ تمام فعاليت‌هاي مهندسي مي‌باشد، توجه به اين مطالب براي عموم مهندسان مفيد و مهم است. اين مقاله پس از بررسي لزوم چنين بحثي به تبيين مصاديق شكست پروژه پرداخته سپس به طرح علل آن، كه هدف مقاله است، مي‌پردازد. نهايتاً با توجه به علل مطروحه به يك نتيجه‌گيري كلي مي‌رسد.
    كليدواژه‌ها: شكست پروژه؛ مهندسي نرم‌افزار؛ طراحي؛ زمان‌بندي؛ تخمين هزينه؛ مديريت؛ مهارت؛ كاربر؛ ارتباطات؛ معماري.
    1) مقدمه
    از آنجا كه بيشتر پروژه‌هاي نرم‌افزاري به نوعي با شكست مواجه مي‌شوند و اين مطلب را آمار تأييد مي‌كند، نياز به بررسي علل و عوامل شكست در پروژه‌ها معلوم مي‌گردد. در يكي از مقاله‌هاي مورد استفاده‌ي تحقيق حاضر كه توسط لورين جي. مي نوشته شده است، با يك بررسي آماري جامع و انجام يك سلسله مصاحبه با مديران و مشاوران پروژه‌هاي نرم‌افزاري و مقايسه و تحليل آنها، مقاله‌اي فراهم آورده است كه در آن به گفته‌ي خود وي راه حل ارائه نكرده است و تنها سعي در تحليل علل و عوامل شكست در پروژه‌ها و معرفي آنها نموده است.
    اين مقاله با توجه به اهميت رعايت اصول طراحي، كه در فازهاي مختلف توسعه‌ي نرم‌افزار مورد توجه است، بر اين بخش از چرخه‌ي حيات نرم‌افزار تأكيد و توجه خاص داشته و سعي در اثبات اهميت و حساسيت مرحله‌ي طراحي در توسعه‌ي سيستم‌هاي نرم‌افزاري دارد.
    2) شكست چيست؟
    ابتدا لازم مي‌نمايد كه بدانيم شكست در يك پروژه به چه معناست. شكست در پروژه‌هاي نرم‌افزاري در هر يك از چهار مورد «هزينه»، «زمان»، «كيفيت» و «دست‌يابي به اهداف» مطرح مي‌گردد؛ بدين معنا كه اگر پروژه‌اي با صرف هزينه‌ي بيشتر يا زمان بيشتر يا با كيفيت پايين‌تر انجام گردد، علي‌رغم به پايان رسيدن پروژه، آن را توأم با شكست مي‌دانيم.
    1-2) آمــار
    طبق آماري كه نويسنده به دست آورده است تنها يك ششم پروژه‌هاي نرم‌افزاري تعريف شده (67/16%) در زمان معين و با هزينه‌ي پيش‌بيني شده به پايان رسيده است. يك سوم پروژه‌ها (33/33%) فوراً متوقف گرديده و نيمه‌ي باقي‌مانده مورد بحث اين مقاله است؛ كه از اين ميان به طور متوسط پروژه‌ها با صرف 89/1 برابر بودجه (%189+) و 22/2 برابر زمان (%222+) انجام شده و تنها به 61/0 مشخصات تعريف شده دست يافته‌اند(61% اهداف).
    بنابراين حساسيت اين مطالعه و لزوم اتخاذ تدابيري جهت بهبود اين وضعيت كاملاً مشهود است. لازم به ذكر است كه آمار فوق تنها از يك جامعه‌ي آماري نمونه به دست آمده و ارقام و اعداد در دنياي واقعي قطعاً بيش از اينهاست، چرا كه اين مطالعه تنها بر مبناي پروژه‌هاي دفاعي نيروي هوايي ايالات متحده‌ي آمريكا انجام گرديده است.
    مطالعات انجام شده مبين اين نكته است كه ريشه‌ي بيشتر علل شكست، در پيش از اولين خط كد نوشته شده يافته شده است، يعني «طراحي». البته اين موضوع را با شرح جزئيات بيشتر مي‌توان كالبدشكافي نمود و جنبه‌هاي مختلفي را متذكر گرديد كه همگي در حيطه‌ي طراحي مي‌گنجد.

    3) علل اصلي شكست پروژه‌ها
    بنا بر اين مطالعه مي‌توان موارد زير را به عنوان «دلايل اصلي عدم توفيق در پروژه‌هاي نرم‌افزاري» ذكر نمود:
    • ضعف ورودي كاربر
    • نيازمندي‌هاي مبهم
    • تخمين دور از واقعيت براي هزينه و زمان
    • ناهماهنگي در مهارت‌ها
    • هزينه‌هاي پنهان
    • شكست طراحي
    • طبقه‌بندي ارتباطات
    • معماري ضعيف
    • تأخير در اعلان شكست
    در بخش‌هاي بعد هر يك از موارد بالا را تشريح خواهيم كرد.

    1-3) ضعف ورودي كاربر
    هنگامي كه مشاهده شود كه سيستم به نيازهاي كاربر پاسخ نمي‌دهد به چنين موردي بر مي‌خوريم. اين ضعف در سيستم از آنجا ناشي مي‌شود كه داده‌هاي اوليه در طراحي از ناظران سطح بالا اخذ گرديده است، كه اينان به طور معمول از سيستم استفاده نمي‌كنند. در اينجا به گفته‌ي «پاول هيويت»، مشاور مركز پشتيباني فني نرم‌افزار (STSC) ، اشاره مي‌كنيم:«پروژه‌ها با مشكل مواجه خواهند شد مگر اينكه كاربران آگاه طي هر فاز استخراج نيازمندي‌ها، طراحي محصول و ساخت، داده‌هاي ورودي با معني به طراح بدهند. كاربر بايد بپرسد: چگونه همه‌ي كارهايم را با سيستم انجام دهم؟ آيا سيستم ابزار درست و كارآمد را براي من تأمين مي‌كند؟ بايد چه چيز به سيستم بدهم و در مقابل چه به دست خواهم آورد؟».
    نكته‌ي ديگر در اين باره را «شاري لاورنس فليگر»، رييس شركت نرم‌افزاري Systems در واشينگتن دي سي بيان مي‌دارد:«… با وجود اين كاربر نبايد به بخش تعيين نيازمندي‌ها بيش از حد نزديك شود. چون باعث بروز تداخل (Conflict) مي‌گردد. كاربران درباره‌ي آنچه مي‌خواهند و تبعات آن فكر نمي‌كنند، اينان تنها به اين مي‌انديشند كه كارها چگونه انجام مي‌شده‌اند و در آينده چگونه انجام خواهد شد.».

    2-3) ابهام در نيازمندي‌ها
    بيانات «ماريا داتيز» رييس Peripheral Visions در هوستون تگزاس، درباره‌ي تجربياتش در اين خصوص مفيد است:«كارفرما درباره‌ي آنچه كه برنامه بايد انجام بدهد ايده‌اي كلي دارد و در آن زمان كه پروژه در دست مطالعه و طراحي است، ايده‌هايش را پالايش و اصلاح مي‌كند. بنابراين در هر مرحله طراحان ناچار به عقب‌گرد مي‌شوند ونتيجه آنكه هزينه‌ي پروژه و كيفيت به سرعت از كنترل خارج مي‌شود، كه البته نهايتاً شركت ما مقصر شناخته مي‌شود! بنابراين بايد از ابتدا scope به حد كافي باريك و محدود باشد.
    همچنين بايد از ابتدايك خط پايه‌ي پايدار (permanent baseline) براي نيازمندي‌ها بنا نمود. هر چند كه در هر صورت نيازمندي‌ها به طور خزنده تغيير مي‌كنند.».
    به هر حال در طي ساخت محصول نيازهاي واقعي خودشان را نشان مي‌دهند. اگر معماري و فرآيندها به طور هم‌گام با يكديگر تغيير نكنند، پروژه به زحمت مي‌افتد. نيز اگر خطوط راهنماي بنا شده نتوانند تعيين كنند كه چه نيازمندي‌هايي افزوده يا حذف شوند، يا تغيير كنند و چه كسي مسؤول اين تغيير و برعهده گيرنده‌ي هزينه‌هاي مربوطه است، پروژه موفق نخواهد بود.

    3-3) تخمين دور از واقعيت براي هزينه و زمان
    پروژه‌هاي نرم‌افزاري همانند همه‌ي فعاليت‌هاي مهندسي ديگر، نيازمند تعيين حداقل هزينه و زمان هستند. يعني يك نقطه‌ي مينيمم براي هزينه و زمان در هر پروژه وجود دارد كه با مطالعه‌ي بيشتر روي آن حتماً مقدارش رشد خواهد داشت. «… اما خست به خرج دادن باعث طراحي‌هاي ضعيف، چگالي بالاي عيوب، دوباره‌كاري و آزمون‌هاي بي‌پايان مي‌گردد. نهايتاً پروژه با پول و زمان بيشتر و كيفيت بدتر انجام خواهد شد.». اين گفته‌ي «رابرت گزلتر» مشاور نرم‌افزار شركت فلاشينگ در نيويورك مي‌باشد.
    «كيپرز جونز» رييس مؤسسه‌ي تحقيقات بهره‌وري نرم‌افزار مي‌گويد:«براي علاج اين مشكل بايد در تخمين هزينه و زمان پروژه از چند ابزار مختلف سود جُسته، پارامترهاي عددي به دست آمده را تركيب كرد تا به تخميني واقعي‌تر دست يافت. حتي گاهي پيش از تعريف دقيق نيازمندي‌ها، برآورد لازم است.».

    4-3) ناهماهنگي در مهارت‌ها
    اين مورد بيشتر در پروژه‌هاي دولتي مشهود بوده است و آن بدين خاطر است كه در پروژه‌هاي دولتي قوه‌ي تصميم‌گيري در دست اشخاصي است كه خبره‌گي فني ندارند.
    پروژه‌هايي كه به فناوري بالا متكي‌اند (High Tech) ، بايد مديراني با مهارت‌هاي فني بالا داشته باشند. اختيارات چنين طرح‌ها و پروژه‌هايي نيز بايد در دست افرادي باشد كه آگاهي فني دارند و ريسك‌هاي فني را مي‌فهمند.
    مجموعه‌ي مهارت‌ها براي مديريت و برنامه‌نويسي از جدا مي‌باشند. مديريت پروژه‌هاي بزرگ نياز به مهارت‌هاي عالي در «طرح‌ريزي»، «سازمان‌دهي»، «افق ديد وسيع و عميق» و «ارتباطات» دارد. استخدام افراد ماهر با حقوق بيشتر، از استخدام افرادي با حقوق كمتر كه مدت‌ها طول مي‌كشد تا صاحب تخصص شوند، به مراتب به‌صرفه‌تر است.
    ماريا داتيز مي‌گويد:«You get what you pay for! ، هر چه پول بدهي آش مي‌خوري! اگر نمي‌تواني يهترين تكنسين‌ها(فني‌ها) را استخدام كني، بهترين مديران را استخدام كن!».

    5-3) هزينه‌هاي پنهان
    ارزان تمام كردن، باعث بُروز هزينه‌هاي پنهان مي‌شود. در تخمين هزينه و زمان بايد متوجه هزينه‌هاي پنهان نيز بود. به عنوان مثال در نظر گرفتن تورم در تخمين هزينه‌ها مؤثر مي‌باشد.

    6-3) شكست طراحي
    عدم طراحي جزئي و تعيين تكليف براي افراد(به طور جزئي)، براي پروژه مشكل‌ساز مي‌شود. برخي مديران و پديدآورندگان نرم‌افزار معتقدند به جاي صرف وقت براي تعيين نيازمندي‌ها و طراحي و بررسي و… بهتر است به كار واقعي(كدنويسي و تست!) پرداخت، كه سريع‌تر به نتيجه برسيم. اما مابين سرعت و پيشرفت تفاوت وجود دارد. در صورتي كه طراحي مناسب باشد، هيچ نيازي به «قهرمان» نخواهد بود.

    7-3) طبقه‌بندي ارتباطات
    تيم‌هاي درگير كار طراحي و كدنويسي بايد با يكديگر مراوده داشته باشند. چون حين انجام كار همواره مشكلات مشابهي پيش مي‌آيد، به خصوص اگر تيم‌ها در سايت‌هاي مختلف كار كنند؛ وجود مراوده و تبادل اطلاعات و مبادله‌ي تجربيات بسيار حائز اهميت بوده، از صرف هزينه و وقت اضافي جلوگيري مي‌كند.
    براي انجام اين امر بايد فردي وجود داشته باشد كه به كل كار محيط بوده و اين هماهنگي‌ها را انجام دهد. در عين حال بايد جلسات متعدد، متناوب و مستمر داشته باشيم تا هر كس بداند جزء كوچكي را كه مي‌سازد در كجاي اين پيكره‌ي عظيم قرار مي‌گيرد.
    ضمناً در طي اين جلسات مشكلات هر تيم بيان شده و احياناً اگر اين مشكلات را حل كرده‌اند راه‌حل‌ها را نيز به اطلاع ديگران رسانيده و اگر در تيم ديگري چنين مشكلي بروز كند آنها راه حل را پيشاپيش خواهند دانست و ناچار به تجربه كردن تجربيات نخواهند بود.
    نتيجتاً سرعت كار بيشتر شده و قطعاً هزينه نيز كاهش مي‌يابد. هزينه‌ي مذكور شامل پول و زمان مي‌باشد.

    8-3) معماري ضعيف
    در بحث «معماري ضعيف» تمركز اين مقاله بر روي انعطاف‌پذيري معماري مي‌باشد. مثلاً نمونه‌ي تجربي موجود در جنگ خليج ديده شده است. موشك «پاتريوت» براي مقابله با موشك «اسكاد» طراحي نشده بود ولي نرم‌افزار قادر به تغيير ساختار(براي پشتيباني از عملكرد جديد) بود.
    در سوي ديگر اين طيف، برنامه‌هاي «حفاظت متون حساس» هستند كه به سيستم عامل وابسته‌اند.
    در طراحي نبايد پروژه چنان طرح‌ريزي شده باشد كه به ساختار ويژه يا سيستم عامل خاصي چنان وابسته باشد كه در پشتيباني و به‌روزرساني و افزودن بخش‌هاي جديد به سيستم دچار مشكل يا صرف هزينه‌ي گزاف شويم.
    گزلتر در اين باره مي‌گويد:«نبايد قايق بسيار زيبايي را در كارگاه ساخت كه از در كارگاه بيرون نمي‌رود!»
    ضمناً بايد توجه داشت كه: «اگر كارت را درست انجام دهي كسي نمي‌فهمد، ولي اگر اشتباه كني … !»
    بنابراين در معماري و طراحي ساختاري سيستم، بايد حداقل‌ها را در نظر گرفته، وابستگي سيستم به platformهاي سخت‌افزاري و نرم‌افزاري را به حداقل رسانيد.

    9-3) تأخير در اعلان شكست
    مورد ديگر در شكست پروژه‌هاي نرم‌افزاري آن است كه پس از مشاهده‌ي برخي عوامل مشكل‌زا، اگر در زمان مناسب تدابير مؤثر اتخاذ نگردد برخي مسايل جبران ناپذير خواهند شد. لذا بايد در زمان لازم موارد خاص را كشف و حل نمود و هيچ‌گاه در اعلان آنها تأخير نكرد. چرا كه اگر موردي كه در آينده مشكل‌ساز خواهد شد به موقع ديده نشده و رفع نگردد، شايد هرگز به رفع آن موفق نشويم. ضمناً مشكل مزبور ممكن است باعث بروز اشكالات ديگر نيز بشود.

    نتيجه‌گيري
    علاوه بر موارد مذكور، مشكلات و موانع بسيار ديگري نيز موجودند. به گفته‌ي جونز:«راه‌هاي شكست بسيارند، در حالي كه تنها راه‌هاي اندكي براي موفقيت وجود دارند.».
    اما با توجه به همين موارد معدود كه شرح آن رفت، مي‌توان تا حدود بسيار زيادي از بروز مشكلات جدي در هر پروژه بالاخص پروژه‌هاي نرم‌افزاري پيش‌گيري نمود.
    من حيث‌المجموع در انجام هر نوع فعاليت مهندسي صرف زمان هنگام طراحي و بررسي كليه‌ي جوانب كار بسيار به‌صرفه‌تر است از صرف هزينه‌هاي گزاف در فازهاي بعدي پروژه، به منظور اصلاح مشكلاتي كه اساساً مي‌توانست پيش نيايد.

  3. agha reza lalaegani

    هفت اصل بيل گيتس

    ________________________________________

    ________________________________________

    «بيل گيتس»، رئيس «مايکروسافت»، در يک سخنراني در يکي از دبيرستان‌هاي آمريکا، خطاب به دانش‌آموزان گفت: «در دبيرستان خيلي چيزها را به دانش‌آموزان نمي‌آموزند». او هفت اصل مهم را که دانش‌آموزان در دبيرستان فرا نمي‌گيرند، بيان كرد.

    به گزارش ايسنا، اصول بيل گيتس به اين شرح است:
    اصل اول: در زندگي، همه چيز عادلانه نيست، بهتر است با اين حقيقت کنار بياييد.
    اصل دوم: دنيا براي عزت نفس شما اهميتي قايل نيست. در اين دنيا از شما انتظار مي‌رود که قبل از آن‌که نسبت به خودتان احساس خوبي داشته باشيد، کار مثبتي انجام دهيد.

    اصل سوم: پس از فارغ‌التحصيل شدن از دبيرستان و استخدام، کسي به شما رقم فوق‌العاده زيادي پرداخت نخواهد کرد. به همين ترتيب قبل از آن‌که بتوانيد به مقام معاون ارشد، با خودرو مجهز و تلفن همراه برسيد، بايد براي مقام و مزايايش زحمت بکشيد.

    اصل چهارم: اگر فکر مي‌کنيد، آموزگارتان سختگير است، سخت در اشتباه هستيد. پس از استخدام شدن متوجه خواهيد شد که رئيس شما خيلي سختگيرتر از آموزگارتان است، چون امنيت شغلي آموزگارتان را ندارد.

    اصل پنجم: آشپزي در رستوران‌ها با غرور و شأن شما تضاد ندارد. پدر بزرگ‌هاي ما براي اين کار اصطلاح ديگري داشتند، از نظر آنها اين کار «يک فرصت» بود.

    اصل ششم: اگر در کارتان موفق نيستيد، والدين خود را ملامت نکنيد، از ناليدن دست بکشيد و از اشتباهات خود درس بگيريد.

    اصل هفتم: قبل از آنکه شما متولد بشويد، والدين شما هم جوانان پرشوري بودند و به قدري که اکنون به نظر شما مي‌رسد، ملال‌آور نبودند.

  4. agha reza lalaegani

    سخنان پند آموزي از شاملو
    عيب کار اينجاست که من”آنچه هستم ” را با ” آنچه بايد باشم ” اشتباه مي کنم ،
    خيال ميکنم آنچه بايد باشم
    هستم،در حاليکه آنچه هستم نبايد باشم

    به خاطر داشته باشیم که :
    عمر کوتاه است رسیدن به خواسته هایمان را طولانی نکنیم.

    راه ما هموار است آن را پیچیده نکنیم .

    نگهداشتن دوستان خوب ، گرانبها است به سادگی از دست ندهیم .

    سخن گفتن سهل است گوش کردن را تمرین کنیم.
    طبیعت پر از لطف است نامهربانی نکنیم.

    زندگی آسان است آن را مشكل نکنیم .

    دنیا پر از زیبائی است چشمانمان را به سادگی نبندیم .

    ذهن ما پر از جواب است سوالاتمان را بپرسیم.
    رسیدن به آرزوها آسان است راه سخت تر را نرويم.

  5. agha reza lalaegani

    آق سلام

    در مورد مشكل تشديدتون با دوتا لام پشت سر هم :
    بين دو لام SHIFT ت را بگيريد تشديد نمي ندازه . آره داداش اينجوري لـله گاني
    البته تو WORD بايد شيفت ف را بگيري تا اينجوري باشه .
    بستگي داره تو چه محيط و نرم افزاري باشي .
    فعلا” باي

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *