|
|
|
100 اصل در تولید و توسعه نرم‌افزار |
| در تولید نرم‌افزار نکاتی وجود دارد که یا از طریق تجربه بدست می آید و یا از طریق مطالب نهفته در متون علمی. اما به دلیل ماهیت پیچیده و متغیر مفاهیم و روش‌های توسعه و تولید نرم‌افزار، استفاده از تجربیات سایرین در پروژه‌های قبلی می تواند بسیار راهگشا باشد و از بسیاری دوباره‌کاری‌ها جلوگیری نماید. در این مقاله سعی شده است به نکاتی اشاره شود که می‌تواند شما را در اجرای پروژه‌های نرم‌افزاری یاری دهد در پس هر یک از این نکات مطالب بسیاری نهفته است که با دقت در هر کدام از آنها می‌توان بخشی از مشکلات درگیر در زمان اجرای پروژه را مرتفع نمود. یکی از نکاتی که در این مقاله آورده شده این جمله است که «هرچه را می‌خوانید باور نکنید»، بنابراین هر یک از این نکات را به دقت با دوستان و هم تیمیهایتان بحث کرده و آنگاه به کار برید. 1- کیفیت حرف اول را می‌زند. 2- کیفیت در چشمان بیننده است. 3- کیفیت و کارائی دو جز، جدا نشدنی هستند. 4- بالاترین کیفیت در نرم‌افزار امکان پذیر است. 5- قابلیت اعتماد کم، بدتر از کارایی کم است. 6- محصول را هر چه زودتر به مشتری/کاربر بدهید. 7- دائما با مشتری/کاربر در ارتباط باشید. 8- محرکهایی را برای برنامه‌نویسان و مشتریان ایجاد کنید. 9- یک نمونه اولیه درست ارائه نمائید(ProtoType). 10- قابلیت‌های عملیاتی را در نمونه اولیه بسازید. 11- نمونه اولیه را خیلی سریع بسازید. 12- سیستم را به صورت افزایشی تولید کنید. 13- بیشتر ببینید تا احساس ضرورت بیشتری کنید. 14- تغییرات در زمان توسعه نرم‌افزار اجتناب ناپذیر است. 15- در صورت امکان، بجای تولید اجزا، آنها را بخرید. 16- بعد از تولید نرم‌افزار نیاز به یک راهنمای کاربری کوچک دارید. 17- هر مسئله پیچیده ای راه حلی دارد. 18- فرضیاتتان را ثبت کنید. 19- تکنولوژی قبل از ابزار اهمیت دارد. 20- از ابزارها استفاده کنید اما واقع بین باشید. 21- همیشه ابزارهای خوب را به مهندسین خوب بدهید. 22- دانستن «چه موقع» مهم تر از دانستن «چطور» است. 23- زمانی که به اهدافتان رسیدید پروژه را متوقف کنید. 24- روش‌های مرسوم توسعه نرم‌افزار را خوب بشناسید. 25- تکنولوژی را هرگز فراموش نکنید. 26- از استانداردهای مستندسازی استفاده نمائید. 27- هر مستندی به واژه نامه نیاز دارد. 28- هر مستندی به یک فهرست نیاز دارد. 29- برای مفاهیم یکسان از اسامی یکسان استفاده نمائید. 30- مفاهیم را جست‌وجو کنید و سپس انتقال بدهید. 31- مسئولیت پذیر باشید. 32- نیازمندی‌های ضعیف زمینه برآورد هزینه اشتباه است. 33- قبل از ثبت نیازمندیها، مسئله را تعریف کنید. 34- خطاها را در توضیحات نیازمندیها شناسایی و برطرف نمائید. 35- نمونه اولیه، ریسک انتخاب UI مناسب را کم می کند. 36- اینکه نیازمندیها شامل چه چیزهایی هستند را به خوبی ثبت نمائید. 37- زیرسیستم‌ها را به خوبی شناسایی کنید. 38- نیازمندیها را بازبینی نمائید. 39- از طراحی در مرحله شناخت نیازمندیها اجتناب کنید. 40- به نیازمندیها از زوایای مختلف نگاه کنید. 41- نیازمندیها را اولویت بندی کنید. 42- خلاصه نویسی کنید. 43- ابهام را در نیازمندیها برطرف نمائید. 44- قبل از تبدیل به هرگونه مدل رسمی، نیازمندیها را به صورت توضیحات زمان طبیعی بنویسید. 45- انتقال از مرحله شناخت نیازمندیها به طراحی آسان نیست. 46- طراحی بدون مستندسازی طراحی نیست. 47- چرخ را دوباره اختراع نکنید. 48- خطاهای مفهومی بسیار مهم تر از خطاهای Syntax می باشند. 49- طراحی کنید که تغییرات داشته باشید. 50- طراحی را به گونه ای انجام دهید که نگهداری آن امکان پذیر باشد. 51- طراحی بایستی به نحوی باشد که خطاها به راحتی قابل تشخیص باشند. 52- از الگوریتم‌های با کارایی بالا استفاده نمائید. 53- به کاربر فقط اطلاعاتی را نمایش دهید که مورد نیاز وی می باشد. 54- طراحی بایستی چند بعدی باشد. 55- نرم‌افزاری که قصد تولید آن را دارید به خوبی بشناسید. 56- « ورود اطلاعات نادرست –- خروج داده‌های غلط » را در پی دارد. 57- از به کار بردن متغیرهای غیر محلی خودداری نمائید. 58- به شکلی کدنویسی نمائید که بتوان آن را از بالا به پائین خواند. 59- مراقب اثرات جانبی کدی که می نویسید باشید. 60- از اسامی با مفهوم در نامگذاری ها استفاده نمائید. 61- قبل از اینکه به فکر سریع اجرا شدن کد باشید به فکر درست کارکردن آن باشید. 62- قبل از اینکه کد را به پایان برسانید توضیحات آن را بنویسید. 63- هر بخش از کد را جداگانه هم اجرا کنید. 64- کد نوشته شده را ممیزی کنید. 65- از زبان برنامه نویسی مناسب استفاده کنید. 66- کد نویسی را خیلی زود شروع نکنید. 67- تست را از نیازمندیها شروع کنید. 68- نرم‌افزار را خودتان تست نکنید. 69- طرح تست را خودتان ننویسید. 70- نیمی از خطاها در 15 درصد از کدها می باشند. 71- همیشه از تست فشار استفاده نمائید. 72- قبل از تست واحدها یکپارچه سازی را اعمال نکنید. 73- مدیریت قوی بسیار مهم‌تر از تکنولوژی قوی می باشد. 74- هر چه را که می خوانید باور نکنید. 75- نیروی انسانی راه رسیدن به پیروزی می باشد. 76- نیروی انسانی خوب ولی کم بهتر است از نیروی انسانی زیاد ولی ضعیف. 77- به پرسنل تان گوش دهید. 78- به نیروهایتان اطمینان کنید. 79- مهارتهای ایجاد ارتباط بسیار مهم می باشند. 80- به پرسنل تان بوسیله ابزارهای مختلف روحیه دهید. 81- محیط کاری تان را آرام و ساکت نگه دارید. 82- دو چیز قابل برگشت نیستند یکی نیروی انسانی و دیگری زمان. 83- هر چیزی را که در حال انجام آن می باشید می توان به بهترین شکل به اجرا در آورد. 84- موارد غیر ممکن را کنار بگذارید. 85- کار تیمی را هرگز فراموش نکنید. 86- برنامه زمانی پروژه ها را به ریز نگه دارید و همیشه آن را به روز نگه دارید. 87- 10 ریسک اول را شناسایی کنید. 88- برای پروژه حتی در حین اجرا نام و شماره نسخه در نظر بگیرید. 89- همه چیز را ثبت و مستندسازی نمائید. 90- سعی نکنید علائم مربوط به مشکلات را حذف کنید، بلکه آنها را حل کنید. 91- هرچه از عمر نرم‌افزار بیشتر می گذرد پشتیبانی آن سخت تر خواهد بود. 92- برای کنترل پیشرفت نرم‌افزار جلسات بررسی پیشرفت کار را به شکل دائمی برگزار کنید. 93- برنامه نویسانتان را به دو گروه تقسیم کنید : گروه اول برنامه نویسانی که بر روی منطق و الگوریتم نرم‌افزار کار می کنند، گروه دوم آنانی که برروی کارهای روتین و تکراری کار می کنند. 94- برای نوشتن نرم‌افزارهای جدید حتما از مشاور مرتبط با موضوع در تیم تحلیل استفاده نمائید. 95- به افراد تیم تان بیاموزید که این مشتری است که قرار است از نرم‌افزار استفاده نماید نه آنان. 96- استانداردهای لازم جهت مراحل مختلف از قبیل تحلیل، طراحی و برنامه نویسی را قبل از شروع به کار در هر یک از مراحل تدوین نمائید. 97- با توجه به محدوده و بزرگی یا کوچکی نرم‌افزار، متدلوژی توسعه نرم‌افزار را به درستی انتخاب نمائید. 98- قبل از شروع کردن هر پروژه ای، تیم اجرایی آن را به دقت تشکیل دهید. 99- در ابتدای پروژه مسئولیتها و وظایف هر یک از افراد تیم را به روشنی به آنها توضیح دهید. 100- در صورت امکان یک نفر را به عنوان مشاور فنی در تیم در نظر بگیرید. |
منبع : ایتنا - http://www.itna.ir/archives/article/008900.php |
بخش۴ مسائل مربوط به دغدغه‌های متداخل
با وجود اینکه دغدغه‌های متداخل بین چندین پیمانه‌ی برنامه پخش می‌شوند، تکنیک‌‌های کنونی پیاده‌سازی این‌گونه نیازمندیها را با روش‌های یک‌بعدی پیاده‌سازی می‌کنند. در این روش، این دغدغه‌ها در پیمانه‌ی مرکزی پیاده‌سازی می‌شوند. بقیه‌ی نیازمندیها هم به نوعی روی همین بعد پیاده‌سازی می‌شوند. به عبارت دیگر، فضای نیازمندیها یک فضای چند بعدی است، در صورتی که فضای پیاده‌سازی یک بعدی است. چنین عدم تطابقی باعث یک نگاشت نامناسب بین پیاده‌سازی و نیازمندیها می‌شود.
علائم این مشکل
در صورتی که از روش‌های متداول کنونی استفاده کنیم چند عارضه ممکن است در پیاده‌سازی چنین دغدغه‌های متداخلی پیش‌بیاید. می‌توان این مشکلات را به طور کلی به دو دسته تقسیم کرد.
1. در هم پیچیدگی کد: پیمانه‌های مختلف برنامه ممکن است به طور هم‌زمان با چندین نیازمندی سروکار داشته‌باشند. مثلاً اغلب برنامه‌نویسان هم‌زمان درباره‌ی منطق کاری، کارایی، هم‌زمانی، ثبت وقایع، و امنیت فکر می‌کنند. تجمع همه‌ی این نیازمندیها باعث می‌شود در هر بخش از برنامه قسمتی از هر کدام از این دغدغه‌ها پیاده‌سازی شوند که باعث در هم پیچیدگی کد می‌شود.
2. پراکندگی کد: چون دغدغه‌های متداخل، طبق تعریف، بین پیمانه‌های مختلف پخش هستند، پیاده‌سازی مربوط به آنها نیز بین این پیمانه‌ها پراکنده‌است. مثلاً در یک سیستم که از یک پایگاه داده استفاده می‌کند، دغدغه‌ی کارایی ممکن است روی تمامی پیمانه‌هایی که به پایگاه‌داده دسترسی دارند تأثیر بگذارد.
نتایج این مشکل
روی هم رفته، در هم پیچیدگی و پراکندگی کد اثرات مختلفی روی طراحی و ساخت برنامه می‌گذارد:
ضعف در ردیابی: پیاده‌سازی هم‌زمان چندین دغدغه، رابطه‌ی بین یک دغدغه و پیاده‌سازیش را غیرشفاف می‌کند. این کار باعث می‌شود نگاشت بین این دو دقیق و شسته‌رفته نباشد.
بهره‌وری پایین: پیاده‌سازی هم زمان چندین دغدغه تمرکز برنامه‌نویس را از دغدغه‌ی اصلی به دغدغه‌های جانبی جلب می‌کند. به همین دلیل بهره‌وری پایین می‌آید.
کم شدن استفاده‌ی مجدد از کد: از آنجایی که در این شرایط هر پیمانه چندین دغدغه را پیاده‌سازی می‌کند، در سیستم‌های دیگر که همین کارکردها را دارند نمی‌توان از این پیمانه‌ها استفاده کرد. این مسأله بهره‌وری را باز هم کمتر می‌کند.
کیفیت پایین کد: در هم پیچیدگی کد باعث می‌شود مشکلات در کدها پنهان شود. علاوه بر آن وقتی در یک لحظه به چندین دغدغه بپردازیم ممکن است توجه لازم به برخی از آنها نکنیم.
سختی تحول: نگرش محدود و محدودیت منابع در زمان طراحی یک سیستم باعث می‌شود که در طراحی، فقط برخی از دغدغه‌ها مورد نظر قرار گیرند. برای در نظر گرفتن نیازمندی‌های بعدی معمولاً لازم است در پیاده‌سازی دوباره‌کاری کنیم.
راه حل‌های کنونی
برای اینکه برنامه نویسان با دغدغه‌های متداخل به صورت پیمانه‌شده‌ای سروکار داشته‌باشند، راه حل‌هایی با دامنه‌ی محدود مانند frameworkها وApplication Serverها وجود دارد. مثلاً معماری Enterprise JavaBeans دغدغه‌های متداخلی مانند امنیت، سرپرستی، کارایی و ماندگار کردن داده‌ها را برعهده می‌گیرد. برنامه نویسان روی منطق کاری تمرکز می‌کنند و مسئولان جای‌گذاری روی مسائل مربوط به جای‌گذاری، مانند نگاشت داده‌های اشیاء بر روی پایگاه‌داده، کار می‌کنند. در این صورت برنامه‌نویس دیگر لازم نیست به مشکلات مربوط به ماندگاری داده‌ها توجه کند. در این روش ذغدغه‌ی ذخیره‌ی داده‌ها در پایگاه‌داده، در یک واصف مبتنی بر XML پیاده‌سازی می‌شود.
بخش۵ معمای معماری
معماری مطلوب برای یک سیستم به گونه‌ای است که نیازمندی‌های کنونی و آینده را در نظر می‌گیرد و از اینکه پیاده‌سازی برنامه به صورت وصله‌پینه‌ای باشد جلوگیری می‌کند. در این میان یک مشکل پیش می‌آید: پیش‌بینی آیند کار سختی است! اگر یک نیازمندی متداخل را که بعداً ممکن است به‌وجود بیاید از قلم انداخته‌باشیم، مجبور می‌شویم برای در نظر گرفتن آن بسیاری از بخش‌های برنامه را عوض کنیم یا حتی دوباره پیاده‌سازی کنیم. از طرف دیگر، اگر روی تعداد زیادی از نیازمندیها که احتمال نیاز به آنها کم است تمرکز کنیم، ممکن است در نهایت به یک سیستم بی‌دلیل بزرگ، سردرگم کننده و غیر قابل فهم برسیم. در نهایت این معمای غیر قابل حل همیشه وجود دارد که: تا چه حد آینده‌نگری در طراحی لازم است؟ در حال حاضر باید بیشتر از این روی طراحی وقت گذاشت، یا همین حد هم زیاد است؟ و ... .
مثلاً: آیا یک معمار نرم‌افزار باید مکانیزم ثبت وقایع را در یک سیستم که از اول نیازی به این کار ندارد، در نظر بگیرد؟ اگر باید در نظر بگیرد، در چه جاهایی از برنامه باید ثبت وقایع اتفاق بیفتد و چه اطلاعاتی باید ثبت شود؟ اینچنین سؤالی درباره‌ی نیازمندی‌های مربوط به بهینه‌سازی نیز مطرح است. ما معمولاً خیلی کم درباره‌ی محدود کننده‌های کارایی یک سیستم می‌دانیم. معمولاً اول برنامه را می‌نویسیم. سپس آن را تحلیل می‌کنیم و بخش‌های ضعیف‌تر آن را بهینه‌سازی می‌کنیم تا کارایی مورد نظرمان را به‌دست آوریم. در این طرز نگرش لازم است به طور بالقوه بتوانیم بخش‌های مختلفی از برنامه را تغییر دهیم. علاوه برآن، در طول زمان چون الگوی استفاده‌ی یک سیستم تغییر می‌کند، محدود کننده‌های آن نیز تغییر می‌کنند. مسئول معماری یک کتابخانه‌ی نرم‌افزاری با قابلیت استفاده‌ی مجدد حتی از این هم کار سخت‌تری در پیش دارد! زیرا نمی‌تواند تمام سناریوهای استفاده از کتابخانه‌اش را تجسم کند.
به‌طور خلاصه، به ندرت پیش می‌آید که معماران نرم‌افزار تمام دغدغه‌هایی که سیستم‌شان باید مرتفع کند را بشناسند. حتی برای نیازمندی‌هایی که تا کنون شناخته‌شده‌اند نمی‌توان مشخصات دقیق پیاده‌سازی را مشخص کرد. به طور کلی معماران نرم‌افزار همواره با این معمای لاینحل مواجه هستند که چقدر به جزئیات طراحی بپردازند.