الف – پرداخت وجه بحساب وب سایت ایران ترجمه(شماره حساب)ب- اطلاع جزئیات به ایمیل irantarjomeh@gmail.comشامل: مبلغ پرداختی – شماره فیش / ارجاع و تاریخ پرداخت – مقاله مورد نظر --مقالات آماده سفارش داده شده پس از تایید به ایمیل شما ارسال خواهند شد.
قیمت
قیمت این مقاله: 38000 تومان
(ایران ترجمه - Irantarjomeh)
توضیح
بخش زیادی از این مقاله بصورت رایگان ذیلا قابل مطالعه می باشد.
پس می خواهید یک برنامه تحت وب بنویسید؟ البته می توانید از روش قدیمی دوران مدرسه که در ابتدای فصل ۱ – ایجاد یک برنامه تحت وب با استفاده از ویژگیهای ترکیبی غیررسمی، فوریت، فراست و هنر، شرح دادیم استفاده کنید. اگر همه چیز خوب پیش برود، شما و همکارانتان قهرمان خواهید شد و یک برنامه تحت وب پربار به دنیا خواهد آمد.
اما همیشه همه کارها خوب پیش نمی رود، مخصوصا اگر روش شما فقط بر ویژگیهای غیررسم، فوریت، فراست و هنر تکیه داشته باشد. و وقتی این اتفاق بیفتد، «قهرمان» نابود شده و خواهد سوخت. برنامه تحت وب کاری را که باید انجام نمی دهد؛ ممکن است دیر تحویل داده شود یا اصلا آماده عرضه نگردد؛ یا ممکن است اصلاح، سازگاری و ارتقای آن در چارچوب زمانی که مورد قبول دنیای شتابان وب باشد، سخت یا غیرممکن باشد.
اگر بخواهید همان فلسفه توسعه تحت وب دوران مدرسه را پیش بگیرید، خودتان را در ریسک بزرگی انداخته اید. اگر فقط در مورد شما باشد، ادامه دهید و ریسک پذیر باشید – تاس را بیندازید. ما مشکلی با آن نداریم. اما به ندرت مسئله فقط در مورد شماست. مشتریانتان برنامه تحت وبی می خواهند که نیازهای آنها را برطرف کند، برنامه ای که قابل اعتماد، توسعه پذیر و به دردبخور باشد. مدیریت شما (اگر برای موسسه تجارتی ، آموزشی، یا دولت کار می کنید) احتمالا وجود این برنامه تحت وب را برای استراتژی های تجاری وسیعتری در نظر گرفته است. همکارانتان بر تحویل بموقع برنامه تحت وب تکیه می کنند تا با تا سیستم ها و فرایندهایی که در حال توسعه اش هستند همزمان باشند. اجتماعی از مردم نیاز دارند که با برنامه تحت وب کار کند. آنها ریسکهای بزرگتر را نمی خواهند.
یک راه جایگزین برای روش قدیمی مدرسه وجود دارد – روشی که ریسک را کاهش داده (اما از بین نمی برد) و احتمال موفقیت بالاتری دارد زمانی که بخواهید webApp های صنعتی-باکیفیتی بسازید. روش جایگزین مهندسی وب (webE) است.
مهندسی وب رویکرد حرفه ای فصل ۲
مهندسی وب چیست؟
بگذارید جواب این سوال را بطور مختصر و مفید بدهیم: مهندسی وب چارچوب چابک و با اینحال قانونمندی را برای ساخت webApp های با کیفیت صنعتی ارائه می دهد. به نظر ساده می رسد اما خیلی مهم است که شما این دو کلمه موجود در جواب ما را درک کنید: چابک و چارچوب.
چابک به چه معناست؟
مهندسان وب باید بدانند که تجارت مدرن به مواردی چون تطبیق پذیری، استراتژی های تجاری و فرآیند تغییر سریع قانون، مدیریت تقاضا، پاسخ های تقریبا آنی (حتی زمانی که چنین تقاضاهایی کاملا غیرمنطقی باشند) نیازمند است و افراد ذینفع نفع[۱] حتی به هنگام تقاضا برای اعمال تغییرات سریع ممکن است تصمیم خود را مجددا تغییر دهند. مشتریان به webApp با ویژگی تحویل به موقع توجه دارند، و توجه چندانی به صرف کار انجام شده برای ایجاد یک webApp قابل تحویل نخواهند داشت. با در نظر گرفتن همه اینها، تیم webE باید بر چابکی تاکید داشته باشد. ایوار جاکوبسن [Jac02] مبحث مفیدی را با این مضمون ارائه نمود:
یک تیم چابک تیم فرزی است که قادر است به تغییرات به طور مناسب پاسخ دهد. تغییر چیزی است که توسعه نرم افزار خیلی با آن سر و کار دارد. تغییرات در نرم افزاری که ساخته می شود، تغییرات در اعضای تیم، تغییرات به دلیل فناوری جدید، تغییرات همه چیزهایی که بر محصولی که می سازند یا پروژه ای محصول را ایجاد می کند اثر دارد. حمایت برای تغییرات باید برای تمام چیزهایی که در نرم افزار انجام می دهیم وجود داشته باشد، چیزی است که باید با آغوش باز بپذیریم زیرا این روح و قلب نرم افزار است. یک تیم چابک تشخیص می دهد که نرم افزار با افرادی که در تیم کار می کنند توسعه یافته و اینکه مهارت های این افراد، قابلیت آنها به تشریک مساعی، هسته موفقیت پروژه است.
از دید جاکوبسن، قابلیت سرایت تغییر بصورت سریع محرک اصلی فرآیند چابکی است. مهندسان وب در صورتی که می خواهند با تغییرات سریعی که جاکوبسن می گوید همراه باشند باید سریع باشند.
مهندسی وب رویکرد حرفه ای فصل ۲
چارچوب webE چیست؟
یک چارچوب دربردارنده یک فرایند مهندسی وبی کامل از طریق شناسایی گروه کوچکی از فعالیت های مرتبط با این چارچوب است که برای همه پروژه های webApp، صرف نظر از اندازه یا پیچیدگی شان، قابل پذیرش باشد. علاوه بر این، چنین چارچوبی شامل مجموعه ای از فعالیت های چتری می باشد را که در کل فرایند webE کاربردپذیر است.
عطف به شکل ۲٫۱ هر فعالیت چارچوب از مجموعه ای از اقدامات مهندسی وب – مجموعه ای از وظایف مرتبط که محصول کاری را می سازند (مثلا طراحی یک اقدام webE است) تشکیل شده است. هر اقدام با وظایف کاری جداگانه ای همراه است که تکمیل کننده بخشی از کار مرتبط می باشد.
فعالیت های webE زیر بخشی از یک چارچوب کلی است و برای عمده پروژه های webApp کاربرد دارد.
ارتباطات. شامل اقدامات متقابل و همکاری سنگینی با مشتری ( دیگر ذینفعان) می شود و شامل گردآوری الزامات و دیگر فعالیت های مرتبط می باشد.
برنامه ریزی، شامل طرحی نموی [۲]برای کار webE است. این مورد تشریح کننده اقدامات webE است که نهایتا رخ خواهند داد، یعنی وظایف فنی که باید اعمال شوند، یا ریسک های محتمل، منابع مورد نیاز، محصولات کاری و یک برنامه زمانبندی.
مدلسازی. ایجاد مدل هایی را در بر می گیرد که به توسعه دهنده و مشتری کمک می کند که الزامات webApp و طرحی مرتبط با حصول آن الزامات را بهتر بشناسند.
…
برنامه های کاربردی هوشمند از هر چارچوب باید تشخیص دهند که سازگاری (با مشکل، با پروژه، با تیم، و با فرهنگ سازمانی) برای موفقیت ضروری است. سازگاری بر هر کدام از خصوصیات چارچوب زیر اثر دارد:
جریان کلی فعالیت ها، اقدامات، و وظایف و وابستگی متقابل بین آنها
درجه ای که وظایف کاری با آن در فعالیت چارچوب تعریف شده اند
درجه ای که با آن محصولات کاری شناسایی شده و موردنیاز هستند
روشی که در آن فعالیتهای اطمینان کیفیت اعمال شده اند
روشی که در آن پیگیری پروژه و فعالیت های کنترلی اعمال شده اند
درجه کلی جزئیات و دقتی که پروژه با آن توصیف می شود
درجه ای که با آن مشتریان و دیگر ذینفعان با پروژه درگیر می شوند
سطح استقلال داده شده به تیم پروژه
درجه ای که با آن سازمان تیم و نقش ها تعریف می شود
مهندسی وب رویکرد حرفه ای فصل ۲
اصول دنبال شده به هنگام پذیرش چارچوب
چارچوب پذیرفته شده برای webE باید بر چابکی پروژه تاکید داشته باشد و از مجموعه ای از ۱۲ اصل چابکی پذیرفته شده توسط پیمان چابکی [Agi03] پیروی کند:
اولویت اصلی ما رضایتمندی مشتری طی تحویل زودهنگام و مستمر نرم افزار ارزشمند است.
پذیرای الزامات متغیر، حتی بصورت دیرهنگام در فرآیند توسعه باشید. فرایندهای چابک تغییر را به نفع مزیت رقابتی مشتری دنبال می کنند.
نرم افزار در حال کار را مکررا، از چند هفته تا چند ماه، با اولویت چارچوب زمانی کوتاه تر تحویل دهید.
اشخاص درگیر در تمور تجاری و توسعه دهندگان باید روزانه با هم در طول پروژه کار کنند.
پروژه ها را حول افراد با انگیزه در نظر بگیرید. به آنها محیط لازم و حمایتی که خواستار آن هستند را عطا نموده و برای انجام امور بدانها اطمینان کنید.
اثربخش ترین و کاراترین روش انتقال اطلاعات به و با یک تیم توسعه گفتگوی رو در رو است.
…
مهندسی وب رویکرد حرفه ای فصل ۲
آیا هیچ مزیتی در رویکرد قدیمی دوران مدرسه وجود دارد؟
منطقی است که بخواهیم پارامترهای غیررسمی، فوریت، فراست و هنر در مهندسی وب نقشی داشته باشند. پاسخ یک «بله» قاطعانه است. اما هر کدام از این نیروها می بایست بر مبنای فلسفه مرتبط با کاهش ریسک و در عین حال ارتقا دهنده احتمال موفقیت تعدیل شود.
چابکی به پارامتر حالت غیررسمی کمک نموده و در همان زمان تشخیص می دهد که حسی از فوریت مرتبط با توسعه هر webApp با کیفیت صنعتی وجود دارد. هر تیم webApp باید متناسب ترین چارچوب کلی را که در تناسب کامل با مسئله تحت بررسی است در نظر گرفته و در همان زمان بر فراست و همینطور تجربیات گذشته، برای هدایت روشی که در آن سازگاری رخ می دهد، تکیه داشته باشد. اقدامات webE و وظایفی که اجرا شده بعنوان بخشی از هر چارچوب سازگار شده، روش های فنی تعریف شده ای (برای تحلیل الزامات، طراحی، تولید کد، و آزمایش) مد نظر هستند. هرچند، این روش ها تنها زمانی موفق می شوند که فناوری (تحویل داده شده توسط روش ها) با هنری که هر مهندس وب به کار می برد بصورت همراه و منسجم باشد.
عناصر مهندسی وب
در ابتدا استنباط بحث ما در این فصل بدین صورت مطرح است که مهندسی وب کل چشم انداز شیوه مهندسی نرم افزار و جریان فرایند را در بر می گیرد اما این مورد را به روشی انجام می دهد که فرایند و هر شیوه را با ویژگی های خاص و خصوصیات webApp سازگار می کند.
چگونگی ارائه مهندسی نرم افزار
در میزگرد مجازی منتشر شده در IEEE Software [Pre98]، راجر موقعیت مهندسی وب و مهندسی نرم افزار را تشریح نموده است:
اینطور به نظر من می رسد که فقط محصولات یا سیستم های مهم ارزش مهندسی دارند. پیش از شروع ساختن آن، بهتر است مسئله را بخوبی درک کنید، یک راه حل عملی طراحی کنید، آن را به روشی استوار پیاده کنید، و آن را به دقت آزمایش نمایید. شما احتمالا باید تغییرات آن را در طی کار کنترل کنید و مکانیزمی برای اطمینان از کیفیت محصول نهایی داشته باشید. بسیاری از توسعه دهندگان بحثی در این مورد ندارند؛ آنها فقط فکر می کنند که دنیایشان کاملا متفاوت است و روش های قراردادی مهندسی نرم افزار به سادگی اعمال نمی شوند.
…
مهندسی وب رویکرد حرفه ای فصل ۲
دلایل اهمیت چابکی فرایند WebE
پیش از این اشاره کردیم که مدل فرایند webE (قبلا از آن با عنوان چارچوب یاد کردیم) باید چابک باشد. این به معنی یک روش مهندسی ناب است که در چرخه های توسعه سریع شرکت دارد. هر چرخه منجر به استقرار رشد webApp می شود. آئویاما [Aoy98] انگیزه روش چابک را به صورت زیر شرح می دهد:
اینترنت اولویت اصلی توسعه نرم افزار را از چه چیزی به چه زمانی تغییر داد. کاهش زمان ارائه به بازار یک محصول بعنوان یک ویژگی رقابتی بشمار آمده و شرکت های پیشگام سعی در حصول چنین موردی می نمودند. از این رو، کاهش چرخه توسعه اکنون یکی از مهمترین ماموریت های مهندسی نرم افزار است.
حتی وقتی زمان های چرخه سریع بر تفکر مرتبط با توسعه تاثیر می گذارند، مهم است که تشخیص دهیم چارچوب webE باید در فرایندی تعریف شده باشد که: (۱) پذیرای تغییر باشد، (۲) خلاقیت و استقلال کارمندان توسعه و تعاملات قوی با ذینفعان webApp را تشویق کند، (۳) سیستم هایی را با استفاده از تیم های توسعه کوچک بسازد، و (۴) بر توسعه نموی با استفاده از چرخه های توسعه کوتاه تاکید داشته باشد.
روش های WebE در کجای چارچوب فرایند قرار دارند؟
چشم انداز روش های webE مجموعه ای از وظایف فنی را در بر می گیرد که مهندسی نرم افزار را قادر به درک، تشریح، و سپس ساختن یک webApp باکیفیت می کند. روش های webE (به تفصیل در فصل های ۶ تا ۱۵ بحث شده) می توانند به روش زیر دسته بندی شوند:
روش های ارتباطات. رویکردی را تعریف کنید که برای تسهیل ارتباط بین مهندسان وب و تمام دیگر ذینفعان webApp (مثل کاربران نهایی، مشتریان تجاری، خبرگان حوزه مسئله، طراحان محتوا، رهبران تیم، مدیران پروژه) استفاده می شود. تکنیک های ارتباطی مخصوصا طی جمع آوری الزامات و هر زمان که رشد webApp باید ارزیابی شود، مهم هستند.
روش های آنالیز الزامات. مبنایی برای درک محتوایی که باید توسط webApp ارائه شود را تهیه کنید که شامل کارهایی که باید برای کاربر نهایی انجام گردد، و حالت هایی از تعامل که هر طبقه از کاربران در هنگام استفاده از webApp به آن نیاز دارند خواهد بود.
…
مهندسی وب رویکرد حرفه ای فصل ۲
ابزارها و تکنولوژی مبنای مهندسی وب
ابزارها و تکنولوژی قابلیت فن شناسان برای ساختن سیستم های مبتنی بر کامپیوتر را تقویت می کند. زمانی که به درستی استفاده شوند، ابزارهای خوب به ما اجازه کار کردن سریع تر و ایجاد محصول نهایی باکیفیت تر را می دهند. و به همین دلیل است که همه نسل های فن شناسان عاشق ابزارها و تکنولوژی می شوند. توسعه دهندگان webApp هم استثنا نبوده اند.
اما ابزارها و فناوری را نمی توان در خلاء استفاده نمود. اگر شما واقعا نمی توانید مشکل را درک کنید، در صورتی که هیچ راهی برای کنار آمدن با تغییراتی که متغیرا رخ می دهند ندارید، اگر زمانی را صرف مشخص سازی راه حل نکرده اید، اگر شما از این موضوع مطمئن نمی باشید که «راه حل» اراده شده (با استفاده از ابزارها) نیازهای ذینفعانتان را ارضا می کند یا خیر، پس شما در خلاء کار می کنید. و این مورد در حقیقت نسخه ای فاجعه آمیز است.
[۱] این تکنیک ها، که از آنها با عنوان فعالیت های چتری یاد می شود، در فصل ۴ و ۱۶ تشریح شده اند.
مهندسی وب رویکرد حرفه ای فصل ۲
بهترین شیوه های مهندسی وب
پیش از اینکه وارد بخش های هسته ای این کتاب شویم، برخی از بحث های ساده قابل توجه خواهد بود. ما می دانیم که شما ممکن است از چارچوب و روش های فرایند webE که ما به تفصیل در باقی کتاب بیان می کنیم، استفاده نکنید. ما می دانیم که تیم های مهندسی وب گاهی تحت فشار زمانی شدیدی قرار می گیرند و سعی می کنند از میانبرهایی استفاده کنند (حتی اگر این موارد غیرعاقلانه باشند و منجر به تلاش توسعه ای بیشتر و نه کمتر شوند). همچنین این واقعیت را می پذیریم که برخی تیم های webE می خواهند چیزها را خیلی خودمانی نگه دارند و اعتقاد به چارچوب فرایند و روش های تعریف شده را بطور فلسفی رد می کنند. ما فکر می کنیم این نوع دلیل آوردن ها اشتباه است، اما انتخاب با شماست.
برای درک نیازهای تجاری و اهداف محصول وقت بگذارید، حتی اگر جزئیات webApp مبهم باشند. بسیاری از توسعه دهندگان webApp اشتباها اعتقاد دارند که الزامات مبهم (که بسیار رایج است) آنها را از نیاز به اطمینان از اینکه سیستمی که باید مهندسی کنند دارای هدف تجاری مشروعی می باشد یا خیر، رها می سازد. نتیجه نهایی (اغلب) کار فنی خوبی است که منجر به ایجاد سیستمی اشتباه به دلایلی اشتباه برای مخاطبینی اشتباه می شود. اگر ذینفعان نتوانند نیاز تجاری را برای این webApp مشخص سازند، لازم است تا شدیدا با احتیاط پیش بروید. در صورتی که افراد ذینفع سعی در شناسایی مجموعه ای از اهداف روشن برای محصول (webApp) نمایند، تا زمانی که موفق نشده اند کار را ادامه ندهید. بخش ۴ و ۵ را برای جزئیات ببینید.
توضیح دهید چطور کاربران با استفاده از رویکرد مبتنی بر سناریو با webApp تعامل دارند. ذینفعان باید مجاب شوند سناریوهایی را توسعه دهند (بخش ۴، ۵ و ۷) که چگونگی تعامل کاربران مختلف با webApp را مشخص می سازد. بر این اساس، می توان از این سناریوها استفاده کرد: (۱) برای برنامه ریزی پروژه و رهگیری، (۲) برای هدایت آنالیزها و مدلسازی طراحی، و (۳) بعنوان ورودی مهم برای آزمون های طراحی.
یک طرح پروژه توسعه دهید، حتی اگر خیلی خلاصه باشد. طرح را (بخش ۵) بر چارچوب فرایندی (بخش ۳) پایه ریزی کنید که برای همه ذینفعان قابل قبول باشد. چون خطوط زمانی پروژه بسیار کوتاه هستند زمانبندی را با جزئیات زیاد انجام دهید، مثلا، در بسیاری موارد، پروژه باید بصورت روزانه زمانبندی و ردیابی شود.
…
کجا بودیم . . . به کجا می رویم
وقتی ملاحظات مهندسی وب و چارچوب فرایندی که به عنوان اساس آن عمل می کند، را شروع کردیم، چابکی تبدیل به مفهوم بسیار مهمی شد. بعنوان یک مهندس وب، شما مجبورید سریع باشید. کار شما ساختن webApp با کیفیت – باید پر سرعت باشد. اما همچنان که این کار را می کنید، باید سیستمی را اصلاح کنید که در طول انجام کار پیوسته تکامل یابد. باید چارچوبی کلی را برای هر رشد webApp اتخاذ کرده و مجموعه ای از روش ها و ابزارهای webE را درون چارچوب یکپارچه کنید. شما باید مجموعه ای از اصول چابکی و مجموعه ای از بهترین شیوه ها را دنبال کنید که تیم را به سوی موفقیت هدایت می کنند.
همچنان که وارد بخش ۳ می شویم، شما درباره چارچوب فرایند webE بیشتر یاد می گیرید. مهمتر از این موارد، ما مجموعه ای از اقدامات و وظایف webE را پیشنهاد می دهیم که می توان آنها را به عنوان مباحث اساسی برای اتخاذ چارچوب به منظور مخاطب قرار دادن نیازهای خیلی خاص مسئله، مردم، و پروژه مد نظر قرار داد.
لطفا به جای کپی مقالات با خرید آنها به قیمتی بسیار متناسب مشخص شده ما را در ارانه هر چه بیشتر مقالات و مضامین ترجمه شده علمی و بهبود محتویات سایت ایران ترجمه یاری دهید.
