DivXچیست؟

مناسب‌ترین روش برای تولید نرم‌افزارهای کوچک

اشاره :
در حقیقت ساختن یک نرم‌افزار فقط نوشتن کدهای برنامه نیست. رویه ساخت نرم‌افزارها مراحل متعددی را دربرمی‌گیرد؛ از جمع آوری نیازهای کاربران گرفته تا طراحی، نوشتن کد و در آخر امتحان نرم افزار. روش تولید نرم‌افزارهای کوچک با نرم‌افزارهای بزرگ متفاوت است و طبعاً رویه تولید نرم‌افزارهای کوچک نیز متفاوت خواهد بود. البته این رویه نباید سنگین و حجیم باشد، باید مستقیماً به تمامی فعالیت‌های لازم برای تولید نرم‌افزاری با کیفیت بالا نظارت داشته باشد و از تمامی رویه‌های آسان و متمرکز استفاده کند. با استفاده از تکنیک‌هایی مفید، از روش‌هایی مانند XP،Scrum و RUP می‌توان رویه‌ای مناسب برای تولید نرم‌افزارهای کوچک به‌وجود آورد. همچنین می‌توان از روش‌هایPSP و TSP نیز که برای تولید نرم‌افزارهای کوچک مناسب هستند استفاده نمود و به‌وسیله این روش‌ها کیفیت و قابلیت‌های نرم‌افزارها را بالا برد و در حداقل زمان ممکن نرم‌افزار را تهیه نمود. این مقاله با بررسی روش‌های جدید و متداول امروزی در تولید نرم‌افزار، بهترین و مناسب‌ترین روش تولید نرم‌افزارهای کوچک را به شما نشان خواهد داد. گفتنی است نوشتار حاضر نتایج تحقیقات من در گروه تحقیقاتی مهندسی نرم‌افزار دانشگاه ساندرلند انگلستان است و آمار و نتیجه‌گیری‌های آن براساس مصاحبه‌های انجام شده با چندین شرکت کوچک و بزرگ تولید نرم‌افزار آن کشور است.


فرایند تولید نرم‌افزار
پیروی از یک رویه منظم تولید نرم‌افزار به تولیدکنندگان نرم‌افزار کمک می‌کند امور مربوط به‌تولید نرم‌افزار را منظم و پروژه را در حداقل زمان ممکن و با کارایی بالایی انجام دهند. در حقیقت یک رویه یا Process از مراحل مختلفی تشکیل شده است. این مراحل فعالیت‌های مربوط به رویه را مشخص می‌نمایند و تعیین می‌کنند که این فعالیت‌ها باید چگونه انجام شوند. پیروی از این مراحل به اعضای پروژه دریابند یاری می‌رساند که چه کاری را چه موقع و چگونه انجام دهند همچنین این کار میان اعضای گروه نیز هماهنگی به وجود میآورد. از آن جایی که منابع موجود و نیازهای کاربران هر نرم‌افزار با دیگری تفاوت دارد، فرایند تولید نرم‌افزارهای گوناگون نیز متفاوت است.

انجمن IEEE رویه یا فرایند تولید نرم‌افزار را این گونه تعریف می‌کند: رویه تولید نرم‌افزار در واقع شامل مراحلی مانند جمعآ‌وری نیازهای کاربران ، طراحی سیستم با استفاده از تحلیل این نیازها و نوشتن کدهای نرم‌افزار با استفاده از طرح نرم‌افزار است. همچنین بر این‌باور است که از آن جایی که کیفیت و بهره‌وری نیروی کار با کیفیت روند تولید نرم‌افزار ارتباط مستقیم دارد، طراحی و مدیریت رویه تولید نرم‌افزار از اهمیت شایانی برخوردار است.

برای طراحی یک رویه تولید نرم‌افزار می توان از روش‌های متفاوتی استفاده نمود و از آن جایی که هر پروژه نرم‌افزاری با دیگر پروژه‌ها متفاوت است، می‌توان گفت که رویه تولید آن پروژه نیز با دیگر پروژه‌ها تفاوت دارد. در واقع می‌توان گفت: انتخاب این روش‌ها رابطه مستقیمی با اندازه گروه در پروژه دارد و نرم‌افزارهای بزرگ و کوچک نیاز به رویه‌های تولید متفاوت دارند.

در ادامه این مقاله روش‌های تولید نرم‌افزارها، به خصوص نرم‌افزارهای نسبتاً کوچک که از گروه‌های تولید نرم‌افزاری کوچک‌تری استفاده می‌کنند، بررسی می‌شوند و مورد ارزیابی قرار می‌گیرند.

روش SCRUM
در روش‌های قدیمی و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض می‌کنند که تمامی نیازهای کاربران سیستم را درک کرده‌اند. اما همیشه نیازهای کاربران سیستم در ابتدا مشخص نیست و کاربران ممکن است در همان مراحل ابتدایی، نیازهای خود را تغییر دهند و این چیزی است که برنامه‌نویسان و طراحان سیستم همیشه از آن شکایت می‌کنند و به دنبال راه‌حلی برای رفع این موضوع می‌گردند. به‌عنوان مثال مدل قدیمی آبشاری (waterfall) را در نظر بگیرید.

این مدل حاوی مشکلات فراوانی است که به صورت مستقیم به غیرقابل ‌انعطاف‌بودن این مدل ارتباط دارد. این مدل مانند یک جاده یک طرفه می‌باشد که وقتی اتومبیل در آن حرکت می‌کند، نمی‌تواند مسیر خود را تغییر دهد و در جهت دیگری حرکت کند. در ابتدای کار کاربر سیستم ممکن است نظراتی در مورد سیستم داشته باشد ولی نمی‌تواند ببیند که سیستم چگونه کار خواهد کرد و در نتیجه ممکن است وقتی که سیستم آماده شد، از ساختار و کارایی آن راضی نباشد و تقاضای تغییر در سیستم را بنماید. در نتیجه اگر بتوانیم کاربر را از ابتدا در جریان ساخت نرم‌افزار قرار دهیم، ممکن است که این مشکل حل شود؛ زیرا می‌تواند نظرات خود را در طول مدت ساخت و قبل از اتمام کار اعلام کنند و در نتیجه از نرم‌افزار تهیه شده راضی باشد.

امروزه یکی از روش‌های تولید نرم‌افزار که به خصوص برای پروژه‌های نرم‌افزاری کوچک مورد استفاده قرار می‌گیرد و توسط بسیاری از اساتید و صاحب‌نظران مورد تأیید قرار گرفته است، روش SCRUM است. با استفاده از این روش که روشی به اصطلاح (iterative تکراری یا چرخشی) می‌باشد، می‌توان نرم‌افزارهای کوچک را با کیفیت بالا تهیه نمود. در این روش که به روش هوشمند یا Agile نیز مشهور است، مدیریت قوی تولید نرم‌افزار وجود دارد که به برنامه‌نویسان اجازه می‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهیه نمایند. اسم Scrum در حقیقت از بازی راگبی گرفته شده است (در بازی راگبی Scrum تیمی متشکل از هشت نفر است که با همکاری بسیار نزدیک با یکدیگر بازی می‌کنند).


در این روش هر عضو از گروه موظف به درک وظیفه خود در پروژه است و باید یک هدف مشخص را در تمامی مراحل عملیاتی یا فازهای اجرایی دنبال کند. لازم به ذکر است که در Scrum هر فاز عملیاتی سیستم به Sprint مشهور است.

روش Scrum همانند پروسه‌های دارای مرحله برنامه‌ریزی مقدماتی یا Initial Planning است. در این فاز اعضای تیم باید یک نقشه مقدماتی و یک معماری سیستم قابل تغییر به وجود آورند. بعد از این فاز یک سری از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود می‌آورند. انجام دادن هر Sprint ممکن است از یک تا چهار هفته به طول بینجامد و مجموع این Sprintها نرم‌افزار کاملی را به‌وجود میآورند.

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

البته درخواست‌کننده می‌تواند از قسمتی از نرم‌افزار که باید در هر مرحله تولید شود بکاهد، اما نمی‌تواند تاریخ تحویل آن قسمت را تغییردهد. شاید بتوان گفت که این کار باعث ایجاد نظم در گروه می‌شود و تاریخ تحویل نرم‌افزار به تعویق نخواهد افتاد. علاوه بر این، در طول هر Sprint گروه موظف است روزانه جلساتی جهت بررسی روند پیشرفت و قابلیت‌های نرم‌افزار داشته باشد که این نیز به هماهنگی بیشتر گروه کمک خواهد کرد. در این جلسات که معمولاً به صورت روزانه است، سه گروه می‌توانند شرکت کنند: گروه تهیه‌کننده نرم‌افزار، مدیریت، و درخواست‌کنندگان نرم‌افزار.

در طول این جلسات مسئول جلسه که اغلب مدیر پروژه است، از تمامی اعضای تیم سه سؤال می پرسد:

1- مسئولیت شما (تکالیف) از جلسه قبلی تاکنون چه بوده است و آیا توانسته‌اید این تکالیف را به اتمام برسانید؟

2- در طول این دوره به چه مشکلاتی برخورده‌اید؟

3- بر طبق فهرست وظایف، مسئولیت شما از حالا تا جلسه بعدی چه خواهد بود؟

مدیر Scrum در حقیقت مسئولیت شناسایی تکالیف محوله به اعضا، بررسی روند تکمیلی ساخت نرم‌افزار، بررسی قابلیت‌های اعضای گروه و فعالیت در راستای کم کردن ریسک در پروژه را داراست.

اما چه تفاوتی بین Scrum و دیگر روش‌های تولید نرم‌افزار وجود دارد؟ در جواب این سؤال باید یادآورشد که در Scrum هر مرحله یا Sprint قسمتی از نرم‌افزار را آماده می کند. در این روش می توان پیشرفت در تولید نرم‌افزار را در هر مرحله به خوبی احساس نمود. علاوه بر این، گروه می‌تواند پس از اتمام هر Sprint تصمیم‌گیری‌کند که آیا می خواهد به کار روی پروژه ادامه دهد یا انجام پروژه مذکور غیرممکن است. روش Scrum وقتی می‌تواند بیشتر مفید باشد که در ابتدای پروژه نیازهای کاربران به صورت دقیق مشخص نباشد و یک گروه کوچک مسئول پروژه نرم افزاری باشد.

نتایج تحقیقاتی که اواخر سال 2005 روی چندین شرکت تولیدکننده نرم‌افزار در کشور انگلستان انجام دادم، نشان‌دهنده این بود که شرکت‌هایی که از Scrum استفاده کرده بودند با حدود چهارصددرصد افزایش در بهره‌وری کار مواجه بودند. البته این رقم در گروه‌های نرم‌افزاری مختلف متفاوت بود و می‌توان گفت عوامل انسانی از جمله مدیر پروژه نقش بسیار مهمی در افزایش یا کاهش راندمان پروژه ها دارند.

شاید این سؤال در ذهن شما به وجود آید که چرا Scrum ممکن است برای تولید نرم‌افزارهای کوچک راه حل خوبی باشد؟ در جواب می‌توان گفت، از آن جایی که در تیم‌های کوچک، اعضای گروه باید از تمامی مسائل پروژه آگاه باشند و در Scrum تمامی مراحل ساخت توسط تمامی اعضای گروه قابل مشاهده است. لذا این روش می‌تواند روش مناسبی باشد.

معایب روش Scram
مزایای استفاده از Scrum بسیار است، اما این روش چند اشکال نیز دارد. از جمله:

1- Scrum روش جدیدی است و با روش‌های مرسوم تفاوت‌های زیادی دارد.

2- برخی از برنامه‌نویسان حرفه‌ای ممکن است از تکالیفی که مدیر Scrum به ایشان می‌دهد راضی نباشند و بخواهند روش قدیمی خود را اجرا نمایند و در صورت اجبار، در روند اجرای پروژه کارشکنی کرده و مشکل‌آفرینی کنند.

3- از آنجا که مدیر Scrum هم از نظر کیفی و هم کمی باید پروژه را مدیریت کند، Scrum نیاز به مدیریت بسیار قدرتمند دارد.

4- Scrum را می‌توان به عنوان روش تولید نرم‌افزار نام برد، اما این روش بیشتر روش مدیریت پروژه هوشمند خوبی است و نمی‌توان آن را به صورت منفرد استفاده نمود و می‌توان گفت برای حصول اطمینان از موفقیت پروژه‌های نرم‌افزاری (به خصوص در سطح کوچک) باید این روش را با روش‌های دیگر ادغام نمود. Scrum را از آن جهت می‌توان روش خوبی برشمرد که روشی تحقیقی براساس تخمین، اولویت‌بندی، عملکرد گروه و بررسی نتایج است که اگر به صورت صحیح مورد استفاده قرار گیرد و قبل از استفاده به صورت کامل آموزش داده شود، می‌تواند راندمان پروژه‌های نرم‌افزاری، به خصوص تولید نرم‌افزارهای کوچک را به صورت بسیار محسوسی بالا ببرد.

روش XP
اشتباه نکنید! منظور از روش اکس‌پی، ویندوزاکس‌پی نیست. اکس‌پی مخفف Extreme Programming یا برنامه‌نویسی سریع می‌باشد که مانند Scrum روشی هوشمند در تولید نرم‌افزار است. در اکس‌پی دو برنامه‌نویس کار را انجام می‌دهند و قبل از اتمام برنامه آن را چندین‌بار امتحان می کنند. اکس‌پی در حقیقت روشی از تولید نرم‌افزار است که براساس آسانی، ارتباط، واکنش و تصمیم‌گیری سریع استوار است. شکل 2 اصول روش اکس‌پی را نشان می‌دهد.

در روش اکس‌پی اعضای گروه (که کاربر سیستم نیز عضوی از آن است) در ابتدا جلسه‌ای تشکیل می‌دهند و اولویت‌های پروژه را مشخص می‌کنند. این گروه ممکن است از چند برنامه‌نویس، امتحان‌کننده نرم‌افزار یا Tester و تحلیلگر سیستم تشکیل شود که با هم از ابتدا تا انتهای پروژه همکاری می‌کنند. معمولاً در اکس‌پی برنامه‌نویسان در گروه‌های دوتایی قرار می‌گیرند و وظیفه تکمیل قسمتی از برنامه را برعهده می‌گیرند و هر دوی این برنامه نویسان در مورد هر کدام از نیازهای کاربران با هم بحث می کنند و قدم به قدم کلاس های برنامه را آماده می‌کنند.

بدین ترتیب که در ابتدا کلاسی را به صورت ابتدایی و بدون هیچ طراحی اولیه به وجود می‌آورند و این کلاس را امتحان می‌کنند. در صورتی که این کلاس فاقد هر گونه اشکال باشد، کد اصلی برنامه را بر آن اساس می‌نویسند. وقتی یکی از برنامه‌نویسان مشغول نوشتن قسمتی از برنامه است، برنامه‌نویس دیگر وظیفه کنترل صحت این کدها را عهده‌دار است و در صورت مشاهده هر گونه اشکال، نویسنده کد را مطلع می‌کند.

مانند Scrum، در اکس‌پی نیز اعضای گروه می‌توانند روند تکمیلی تولید نرم‌افزار را مشاهده کنند و در جریان کار قرار گیرند.اکس‌پی روش مناسبی برای مدیریت پروژه‌های کوچک می‌باشد که از دو تا ده برنامه‌نویس تشکیل شده است. اگر چه اصولاً اکس‌پی هیچ رویه خاص و مراحل پیوسته‌ای را مشخص نکرده اما می توان گفت که اکس‌پی داری چهار مرحله اصلی می باشد:

الف: مرحله زمانبندی پروژه: در این مرحله اعضای گروه با توجه به اندازه نرم‌افزار و کارایی آن برنامه زمانبندی را با هم تنظیم می کنند.

ب: طراحی ابتدایی

ج: نوشتن کدهای برنامه

د: امتحان‌کردن کدهای نوشته شده

مطابق تحقیقاتی که توسط نویسنده انجام شد، مشخص گردید که اکس‌پی در پروژه‌های بزرگ با تعداد اعضای بالای ده نفر اصلاً موفق نخواهد بود و تنها می‌تواند برای پروژه‌های کوچک مفید باشد. دلیل آن را نیز می توان در طبیعت این روش دانست؛ زیرا مستندات چندانی برای نرم‌افزار وجود ندارد و فقط دو نفر یا حداکثر چهار نفر می‌توانند در مورد قسمتی از نرم‌افزار اطلاعاتی داشته باشند. همچنین نرم‌افزار تولیدشده توسط این روش هیچ‌گونه طراحی سازمان یافته‌ای ندارد که این موضوع می‌تواند برای مراحل پس از نصب یعنی تعمیرات و نگهداری سیستم باعث بروز مشکلاتی گردد.

از جمله مزایای اکس‌پی می‌توان به این نکته اشاره نمود که از آن جایی که یک برنامه‌نویس به صورت مستقیم کدهای برنامه را کنترل می کند، می‌توان گفت که کیفیت نرم‌افزار تولیدی بالا می‌رود. همچنین می‌توان گفت از آن جایی که دو برنامه‌نویس با هم کار می‌کنند، آموزش کمتری نیاز است و در نتیجه هزینه تولید نرم‌افزار پایین خواهد آمد. اما این روش مشکلات خاص خود را نیز دارد. مثلاً تصورکنید اگر در یک گروه، یک برنامه‌نویس تمایلی برای کار با برنامه نویس دیگری را نداشته باشد یا در یک روز یکی از دو عضو گروه غایب باشد یا ... در نتیجه چون نمی‌توان با یک برنامه‌نویس به ادامه کار پرداخت، اتمام پروژه با تأخیر مواجه خواهد شد.

طبق نتایج تحقیقات به عمل آمده، وقتی یک برنامه‌نویس در کدهای برنامه به دنبال اشکال می گردد، حداکثر می‌تواند ده تا پانزده‌درصد از اشکالات برنامه را پیدا کند. اما وقتی در روشی مثل اکس‌پی دو برنامه‌نویس با هم کار می کنند و یکی از این برنامه‌نویسان کدها را کنترل می‌کند، بیست تا چهل‌درصد از اشکالات ساختاری برنامه خود را نشان می‌دهد. اما با استفاده از روش‌های PSP و TSP که در ادامه این مقاله توضیح داده می‌شوند حتی می‌توان تا هشتاددرصد اشکالات برنامه (که رقم بسیار خوبی است) را قبل نهایی‌شدن برنامه شناسایی و رفع کرد.

روشRational Unified Process) ‌RUP)

در این بخش یکی از معروف‌ترین رویه‌های تولید نرم‌افزار که توسط شرکت آی‌بی‌ام طراحی گردیده‌است را معرفی می‌کنیم. این روش با نام Rational Unified Process) ‌RUP) در بسیاری از پروژه‌های نرم‌افزاری به کار گرفته می‌شود.
در حقیقت هدف اصلی RUP مطمئن‌شدن از این موضوع مهم است که آیا نرم‌افزار تولیدشده نیازهای کاربرانش را به صورت کامل، با کیفیت بالا‌، در زمان معین و با بودجه مشخص برآورده کرده است یا خیر.

مطابق تحقیقات انجام شده، از آن جایی که RUP به تمامی اعضای تیم، اطلاعاتی مشترک می‌دهد و تمامی اعضای گروه با یک زبان مشترک با هم مرتبط هستند، بازده کاری گروه را بالا می‌برد.

RUP دارای سه جزء اصلی است. جزء اول از مجموع راه‌حل‌های خوب که در رویه می‌تواند مورد استفاده قرار گیرد تشکیل شده است. جزء دوم همان مراحل تهیه نرم‌افزار است و جزء آخر قسمت‌های تشکیل‌دهنده این رویه می باشد.

‌ ‌ RUP شش راه‌حل خوب که می‌تواند در مراحل مختلف این رویه به ما کمک کند را معرفی کرده است. از آن جمله:

1- استفاده از USE CASEها که می‌توانند در جمعآوری نیازهای کاربران مفید باشند.

2- استفاده از معماری نرم‌افزار قابل تغییر‌ (‌component reuse)

3- استفاده از روش‌های تکمیلی و Iterative برای کنترل بهتر و آسان پروژه نرم‌افزاری‌

4- استفاده از نمودارهای UML

5- کنترل تغییرات در نرم‌افزار

6- کنترل کیفیت نرم‌افزار با توجه به درخواست‌های اولیه کاربران

شکل 3 رویه RUP را نمایش می‌دهد. همان‌طور که در این شکل مشخص شده است چرخه تولید نرم‌افزار به چهار قسمت اصلی تقسیم شده است:

الف: Inception phase یا مرحله آغازین:
در این مرحله اهداف پروژه مشخص شده و درخواست‌های اولیه کاربران تعریف می‌شود. از خروجی‌های این مرحله می‌توان به مدل اولیه Use Case، آزمون ریسک در پروژه و برنامه زمانبندی پروژه اشاره کرد.

ب: Elaboration phase یا مرحله مقدماتی:
در این مرحله نیازهای کاربران تحلیل و بررسی شده و راه‌حل کلی طراحی سیستم ترسیم می‌شود. از خروجی‌های این مرحله می‌توان از مدل کامل شده Use Case، فهرست نیازهای کامل کاربران و طرح کلی سیستم نام برد.

ج: Construction phase:
یا مرحله ساخت و توسعه: در این مرحله نرم‌افزار طراحی شده ساخته می‌شود و به اصطلاح، کد برنامه نوشته شده و قسمت‌های مرتبط به هم ارتباط داده می‌شوند. از خروجی این مرحله می‌توان از نرم‌افزار، راهنمای استفاده از نرم‌افزار و مستندات سیستم نام برد.

د: Transition phase یا مرحله تغییرات:
در این مرحله اگر نرم‌افزار به وجود آمده در مرحله ساخت دچار مشکل شود، مشکل رفع خواهد شد.

تمامی مراحل توسط خطوط عمودی از همدیگر جدا شده‌اند و هر مرحله با یک milestone یا نقطه مهم تمام می‌شود. روش RUP با استفاده از مدل‌های مختلف همچنین مشخص می‌کند چه کسی، چگونه و چه وقت چه کاری را انجام خواهد داد.

همان‌طور که در این قسمت ذکر شد، روش RUP روشی انعطاف پذیر، قابل تغییر و پیشرفته است که می‌تواند در صورت استفاده صحیح، باعث افزایش کارایی و کیفیت نرم‌افزار تولیدی گردد. اما آیا RUP می‌تواند رویه خوبی برای تولید نرم‌افزارهای کوچک باشد؟ در جواب باید گفت که RUP را طوری طراحی کرده‌اند که بتواند برای انواع پروژه‌های نرم‌افزاری در هر اندازه مفید باشد و از آن جایی که از ابزارهای خوبی مثل UML نیز استفاده می‌کند، UML) در گروه‌های کوچک که نرم‌افزارهای کوچک طراحی می‌کنند ابزار مدلی خوبی است) می‌تواند باعث همکاری و هماهنگی بیشتر گروه گردد.

اما همان‌طور که در ادامه این بحث خواهید دید، اگر بتوانیم رویه‌های ساده‌تر را با یکدیگر ادغام کنیم، شاید بتوانیم راه حلی با کارایی بالاتری داشته باشیم.
روش های PSP و TSP
PSP یا Personal Software Process در حقیقت روش تولید نرم‌افزار نیست بلکه روشی است نوین که با ملزم نمودن اعضای گروه پروژه‌های نرم‌افزاری به رعایت اصولی مشخص و استفاده از فرم‌ها و تکالیفی مشخص به آن‌ها کمک می‌کند کارایی و بهره‌وری کاری خود را بالا ببرند. این روش همچنین حاوی تکنیک‌های خوبی برای کنترل، ا‌ندازه‌گیری و تشخیص اشکالات می‌باشد که می‌تواند به شخص (مثلاً برنامه‌نویس) کمک کند تا مثلاً با اندازه‌گیری نرم‌افزار، یادداشت میزان فعالیت روزانه و ساعات هدر رفته، و اشکالات به وجود آمده، مشکلات را حل کند و در نتیجه بهره‌وری خود را بالاتر ببرد. TSP یا Team Software Process مانند PSP است، ولی برای یک تیم طراحی شده و با طرح روش‌های منظم جهت کنترل و جمع‌آوری اطلاعات روزانه به اعضای تیم کمک می‌کند تا کارایی خود را بالا ببرند.

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

روش RUP + Scrum
همان‌طور که قبلاً اشاره شد، روش Scrum روشی آسان برای تولید نرم‌افزار است که مدیریت پروژه و نظم موجود در آن می‌تواند بسیار کارگشا باشد. حال تجسم کنید که روش RUP را اجرا و قسمت‌هایی از Scrum را در آن ادغام کنیم. پس از این کار متوجه خواهید شد که روش RUP می‌تواند از مدل Scrum کمک بگیرد و با ادغام این دو می‌توان پروسه‌ای منظم برای تولید نرم‌افزارهای کوچک سازماندهی کرد. اما همان‌طور که می‌دانید نمی‌توان دو رویه ناهمگون را با هم ترکیب نمود. آیا RUP و Scrum با هم شباهت‌هایی دارند؟

همان‌طور که قبلاً بیان شد، هر دو رویه ساخت نرم‌افزار روش حلقه‌ای تکرارکننده یا Iterative را خط مشی خود قرار داده‌اند(البته در RUP تعریف بهتر و کامل‌تری از Iterative شده است). در Scrum تعریف نیازهای کاربران توسط اعضای تیم انجام می‌پذیرد، اما در RUP تنها یک شخصRequirement Engineer) یا مهندس مسئول نیازهای کاربران) است که این مسئولیت را برعهده دارد. در زمینه مدل سیستم اگر چه Scrum مسئولیت انجام این کار را به تمامی اعضای گروه داده است، اما هر دو روش از مدل UML پشتیبانی می‌کنند و استفاده از آن را پیشنهاد می‌دهند.

ضمناً هر دوی این روش‌ها روش‌های هوشمند و Iterative هستند که مدیریت و اندازه گیری کیفیت نرم‌افزار در تمامی مراحل این رویه‌ها به خوبی دیده می‌شود. همچنین هر دوی این روش‌ها انجام تغییرات را در طول پروژه مجاز می‌دانند. البته همان‌طور که در قسمت Scrum توضیح داده شد، این روش تغییرات را در طول مراحل Sprint مجاز نمی‌داند، اما مدیر Scrum می‌تواند تغییرات درخواستی توسط کاربران را جمعآوری و در جلسه بعدی مطرح نماید.

به تازگی RUP نیز ابزارهای جدیدی مانند RUP Builder و RUP modeller را عرضه کرده که به مدیران پروژه‌ها اجازه می‌دهد تا برخی از اصول Scrum را درRUP اجرا کنند. در نتیجه این دو پروسه تولید نرم‌افزار می‌توانند به کمک بیایند و روشی مناسب برای تولید نرم‌افزارها به‌خصوص در اندازه کوچک باشند.


روش RUP + XP
روش دومی که مورد آزمایش قرار گرفت، تلفیقی بود از اکس‌پی و RUP. ولی می‌توان گفت ادغام این دو رویه بسیار متفاوت است.

RUP رویه‌ای بسیار سنگین و اکس‌پی روشی بسیار سبک است. می‌دانید که RUP را می‌توانیم تقریباً برای تمامی نرم‌افزارهای کوچک و بزرگ به کار برد. اکس‌پی نیز همانند RUP براساس Iterationها یا مراحل پیوسته مانند تحلیل، طراحی و امتحان نرم‌افزار استوار است.

از آن جایی که RUP و اکس‌پی از اساس با هم تفاوت‌های زیادی دارند و اکثراً تصور می‌کنند که RUP راه‌حلی برای تولید نرم‌افزارهای بزرگ و اکس‌پی برای تولید نرم‌افزارهای کوچک است، ممکن شما هم تصور کنید که استفاده همزمان از هر دوی این روش‌ها کاردرستی نیست.

اما مطابق تحقیقات انجام شده به نظر می‌رسد که برای تولید نرم‌افزارهای کوچک روشی بین RUP و اکس‌پی نیاز است.در نتیجه با اضافه‌کردن برخی از تکنیک‌های اکس‌پی به RUP می‌توان به رویه‌ای مناسب‌تردست یافت. قبلاً نیز محققانی روی RUP کار کرده‌اند تا آن را برای پروژه‌های کوچک مناسب سازند. مثلاً در سال 2000 یک نسخه از RUP به نام dX معرفی گردید که RUP مختصر شده‌ای بود. برای نرم‌افزارهای کوچک (که اعضای پروژه اغلب در یک محیط کار می‌کنند) اکس‌پی می‌تواند روشی بسیار خوب باشد، اما اگر اعضای تیم پراکنده باشند و سیستم بخواهد توسعه یابد، اکس‌پی قادر به جوابگویی نیست و می‌توان گفت که با استفاده از قسمت‌هایی از روش قدرتمند RUP می‌توان به اکس‌پی کمک نمود.

برای تلفیق این دو روش تصورکنید که پروژه‌ای شروع شده است. در مرحله Inception یا آغازین می‌توان از تکنیک‌های اکس‌پی در زمینه برنامه‌ریزی زمانی و جمع آوری نیازهای سیستم استفاده نمود. البته نمی‌توان گفت که همیشه این دو روش با هم سازگار هستند. مثلاً در اکس‌پی مرحله‌ای به نام طراحی یا Design Phase وجود ندارد. در صورتی که RUP یک مرحله مجزا برای این قسمت دارد.

روش Iterative Process
شاید به نظر برسد که در پروژه‌های کوچک، اعضای گروه نیاز کمتری به ارتباط با یکدیگر دارند. اما از آن جایی که در این گونه پروژه ها ارتباط بین اعضای تیم و کاربر نزدیک‌تر است و عوامل خارجی نیز نقش مهمی را در پروژه‌ بازی می‌کنند، در این پروژه‌ها نیاز به ارتباط بین اعضای تیم محسوس به نظر می‌رسد. همچنین اگرچه پروژه‌های نرم‌افزاری کوچک طبیعتاً نیاز به نوشتن کدهای کمتری دارند و ممکن است به چند مدیر نیاز نداشته باشند اما مانند پروژه‌های بزرگ باید نرم‌افزاری با کیفیت بالا ارائه دهند. در نتیجه می‌توان گفت که روشی برای تولید نرم‌افزار کوچک مناسب‌تر است که تمامی موارد مذکور را در نظر بگیرد و اجرا کند.

رویه Iterative یکی از این روش‌ها است. با استفاده از این رویه دو نوع محصول به نام‌های Actual و by-product تولید می‌گردد. در واقع محصولاتی که در موفقیت پروژه نقش اساسی بازی می‌کنند، Actulas و آن دسته که به وجود آمدن Actualsها کمک می‌کنند را By-Product می‌گویند (مثلاً طرح اولیه سیستم). در این مدل هر عضو از گروه مسئول انجام‌دادن قسمتی از کار می‌شود و این مدل شامل هشت مرحله یا فاز است.

اولین مرحله این رویه جمعآوری اطلاعات از کاربر است. در مرحله بعدی سیستم به صورت جامع تحلیل و آنالیز می‌گردد تا اعضای تیم با مدل کلی سیستم آشنا گردند. سپس در مرحله تحلیل، نرم‌افزار به صورت کلی مورد بررسی قرار می‌گیرد و پس از آن که مرحله معماری سیستم نام دارد، اجزای تشکیل‌دهنده سیستم مشخص می‌شوند و کارایی‌های سیستم مشخص می‌گردند. در مرحله طراحی تمامی اجزای سیستم طراحی می‌شوند و در مرحله بعد کدهای سیستم نوشته می‌شود.

وقتی این مرحله تمام شد و کدهای سیستم نوشته شد، اعضای تیم در فاز جمع‌بندی کدهای سیستم را با توجه به مراحل اول تا پنج مرور می‌کنند. در مرحله آخر نیز اعضای گروه را امتحان می‌کنند تا اولاً نیازهای کاربران را تأمین کرده باشد و ثانیاً فاقد هرگونه اشکال باشد. اگر نرم‌افزار فاقد اشکال باشد، رویه تولید نرم‌افزار به آخر خواهد رسید. در غیر این صورت، اعضای گروه به دنبال منبع مشکل در مراحل قبلی می‌گردند و مجدداً رویه را از آن جایی که فکر می‌کنند باعث بروز اشکال شده است، ادامه می‌دهند.

نتیجه گیری
برای دستیابی به موفقیت در پروژه‌های نرم‌افزاری، اعضای گروه باید از یک رویه یا روش مشخص پیروی کنند. اما برای پروژه های کوچک (برای تولید نرم‌افزارهای کوچک) این رویه باید ساده و آسان باشد. اضافه براین، برای دستیابی به موفقیت در پروژه‌ها تنها داشتن یک رویه آسان و کارا کافی نیست بلکه مدیران پروژه‌های نرم‌افزاری باید به این نکته توجه کنند که اعضای گروه در موفقیت پروژه‌ها از اهمیت شایانی برخوردار هستند و باید در انتخاب این افراد حداکثر دقت را مبذول نمود. در ضمن موقع انتخاب یک رویه مناسب باید اندازه نرم‌افزار را معین نمود و براساس نیازهای کاربران پروسه تولیدی را طراحی کرد. برای تعیین رویه‌ای مناسب در تولید نرم‌افزارهای کوچک باید دقت داشت که این رویه باید بسیار ساده باشد تا به اعضای تیم کمک کند به‌راحتی مراحل تهیه نرم‌افزار را ادامه دهند.

از جمله این رویه‌های ساده می‌توان از Scrum نام برد. Scrum یک تکنیک مدیریت پروژه است که می‌تواند به تیم‌های نرم‌افزاری کوچک که روی پروژه‌های کوچک نرم‌افزاری کار می‌کنند کمک کند راندمان و کارایی بالاتری در کار داشته باشند. اما اگر این روش‌ها را با روش‌های مناسب دیگر ادغام کنیم، می‌توانند بیشتر مفید واقع گردند.

پس از Scrum، روش اکس‌پی توضیح داده شد و به عنوان بهترین راه برای تولید نرم‌افزارهای کوچک از آن نام برده شد. اما این روش به تنهایی کارایی چندانی نخواهد داشت. سپس RUP که می‌تواند در تمامی پروژه‌ها استفاده شود تشریح شد و در ادامه سه روش مناسب برای تولید نرم‌افزارهای کوچک ارائه گردید. اما همان‌طور که بحث شد، داشتن یک روش مناسب به تنهایی نمی‌تواند ضامن موفقیت در پروژه باشد، بلکه انتخاب منابع انسانی مناسب و با تجربه می‌تواند راه را برای موفقیت پروژه‌های نرم‌افزاری هموارتر سازد.

توسط: امین صفائی‌
منبع: ماهنامه شبکه

پشت پرده دنیای هکرها

10 مشکل بزرگ وب

وبی که در پیش روی ماست، در همین عمر تقریباً کوتاهش، به بسیاری از کارهای خسته‏کننده و روزمره ما سرعت و راحتی بخشیده است. اما هنوز برخی مشکلات وجود دارد؛ از قیمت بالای تهیه یک بلیت کنسرت از طریق وب تا نگرانی‏های مربوط به حریم خصوصی کاربران در سایتها. با وجود چنین مشکلاتی، نمی‏توان گفت وب مسیر صحیحش را پیدا کرده است. ما در این مقاله به بررسی 10 مورد از بدترین مشکلات وب می‏پردازیم.
واضح است که مشکلات آزاردهنده وب نظیر اسپمها، صفحات گمراه‏کننده قلابی (Phishing)، ویروسها، برنامه‏های جاسوسی که ریشه برخی از آنها به روزهای اولیه تولد وب بازمی‏گردد هنوز حل نشده است. ما در نظرسنجی‏مان از کاربران پرسیدیم که از نظر آنها چه چیزهایی در وب برایشان ناخوشایند است. سپس بخشی از آن موارد که بیشترین توافق در موردشان وجود داشت را جدا کردیم و مجدداً از کاربران خواستیم (*) به 2 مورد که آنها را ناخوشایندتر از سایرین می‏دانند رای دهند. نتیجه هر کدام از آن موارد بصورت درصد بیان شده است. ما این موارد را از مهمترین به کم‏اهمیترین مرتب کرده‏ایم.

1. تردید نسبت به سیاستهای حریم خصوصی افراد (Privacy Policies) در سایتها
درصد موافقت: 69
بسیاری از سایتهای با اهداف تجاری (خصوصاً در بخشهای مربوط به سلامتی و سرویسهای مالی) اطلاعات خصوصی زیادی را از کاربران دریافت می‏کنند. بسیاری از آنها ضوابط مربوط به نگهداری حریم خصوصی کاربران را در سایت قرار داده‏اند تا بلکه بتوانند از این طریق مشتریان را راضی کنند که نگران ارائه اطلاعات به آن سایتها نباشند. اما جملات حقوقی استفاده شده در این صفحات مشکلتر از آنست که کاربران بتوانند آنها را بدرستی درک کنند و همین موضوع سبب می‏شود که کاربران در آخر نفهمند که خیالشان از بابت ارائه اطلاعات خصوصی‏شان می‏تواند راحت باشد یا خیر.
برای نمونه صفحه حریم خصوصی (Privacy Notice) سایت آمازون (amazon.com) حاوی سندی 2700کلمه‏ایست که خود آن به صفحه‏ای 2600کلمه‏ای مربوط به شرایط استفاده (Conditions-of-Use) که پر از مطالب درهم حقوقی است لینک شده است. خیلی خوش‏شانسید اگر بتوانید از این مطالب حقوقی، اطلاعات مورد نظرتان را برداشت کنید. در برخی سایتها استفاده از اطلاعات شخصی را تقسیم‏بندی کرده‏اند. مثلاً حق استفاده از مطالب خصوصی دریافت شده برای بازاریابی محصولات یا سرویسهای دیگر به اعضای آن سایت، یا به اشتراک گذاشتن آن اطلاعات با اشخاص یا شرکتهای ثالث؛ که خود باعث می‏شوند کاربری که آن اطلاعات را در اختیار آن سایت قرار داده است به نوعی احساس ناامنی کند.
حامیان مشتریان پذیرفتن صحیح بودن این موارد را بسیار مشکل می‏دانند چرا که صاحبان سایت (از طریق این جملات حقوقی) در این موارد تفریط می‏کنند تا نگران جریمه‏های آتی نباشند. البته شما می‏توانید از ارائه اطلاعات به سایتهایی که مظنون هستید و فکر می‏کنید به نوعی سعی در گمراه کردنتان دارند خودداری کنید. اما حتی اگر یک وکیل هم برای بررسی نکات قید شده در قسمت حریم خصوصی سایتها استخدام کنید چطور می‏توانید مطمئن باشید که پیش از آنکه دیر شده باشد، متوجه شده‏اید که ارائه اطلاعات به سایتی نادرست است.

2. پر کردن فرمهای آنلاین
درصد موافقت: 65
پر کردن یک فرم به‏ظاهر ساده آنلاین، از بااهمیتی یک فرم درخواست وام گرفته تا کم‏اهمیتی یک فرم ثبت یک سایت، می‏تواند به یک چرخه بی‏پایان به‏روزرسانی پی‏درپی مرورگر شما منجر شود. دلیل آن هم این است که بسیاری از فرمهای تحت وب، ترکیبی از فیلدهایی است که پر کردن برخی از آنها اختیاری بوده و برخی دیگر اجباری می‏باشند بدون آنکه بدرستی این فیلدها از یکدیگر متمایز شده باشند. حال اگر شما هنگام پر کردن یک فرم، یکی از این فیلدهای اجباری را پر نکرده باشید پس از کلیک بر روی دکمه ارسال (Submit) مجدداً همان صفحه ظاهر می‏شود که به شما اطلاع می‏دهد فیلدی اجباری پر نشده است (در بعضی مواقع مجبورید از نو همه اطلاعات را وارد کنید چرا که صفحه ظاهر شده اطلاعات قبلی‏ای که در فیلدها وارده کرده بودید را در خود ندارد!). اگر بخواهیم منصفانه به این قضیه نگاه کنیم می‏توانیم بگوییم این گونه مشکلات این روزها بسیار کمتر شده‏اند چرا که سایتهای تجاری بخوبی می‏دانند که ناراحتی کاربر چقدر می‏تواند برای تجارت آنها زیان‏آور باشد. اما هنوز در زمانی که حل این مشکلات بسیار ساده است دیدن این موارد در برخی سایتها بسیار تعجب‏آور است. طراحان سایت باید بصورت واضح فیلدهای اجباری را از فیلدهای اختیاری متمایز کنند (انتخاب رنگ قرمز برای این کار مناسب‏تر است) و اگر به هر صورتی کاربری فیلدی اجباری را پر نکرد او را مجبور به پر کردن همه فیلدهایی که قبلاً وارد کرده بود نکنند و تنها آن فیلد پر نشده را با رنگی متفاوت از سایر فیلدها، خالی نمایش دهند.

3. تجاری شدن بی‏حدوحساب وب
درصد موافقت: 62
صفحات کوچک تبلیغاتی‏ای که در مقابل صفحه مورد نظرتان بازمی‏شوند، صفحات کوچک تبلیغاتی‏ای که در زیر صفحه مورد نظرتان بازمی‏شوند، انیمشنهای فلش صدادار برای تبلیغات تجاری، بنرهای تبلیغاتی بزرگ چشمک‏زن؛ تبلیغات ویدویویی که بدون اجازه کاربر شروع به پخش می‏کنند، همه از مسائل روزمره کاربران در وب هستند.
ایده‏ایی که با دریافت آگهی‏های تجاری، خدماتی رایگان را در وب ارائه می‏دهیم منجر به وبی فوق‏تجاری شده است و بسیاری از کاربران را از ادامه مشاهده این سایتها منصرف می‏کند. در MySpace، Yahoo و حتی PCWorld.com! – سایتی که این مقاله در آن منتشر شده است. – تبلیغات بسیار آزاردهنده و به نوعی غیرقابل‏اجتناب شده‏اند. بر روی صفحات وب تبلیغات متعدد در همه جای صفحه هر کدام تلاش می‏کنند که خود را بیشتر از دیگری نمایان کنند در صورتی که کاربر، در واقع، برای مشاهده محتویات آن صفحه به آنجا آمده است. نتیجه، کاهش پهنای باند اینترنت، طولانی شدن زمان بالا آمدن صفحات و کنترل کمتر کاربر بر مرورگرش است.
همچنین تبلیغات بر روی کیفیت محتوای سایتها هم تاثیر گذاشته است. زمانی که مدیران سایت، درجه مفید بودن یک صفحه را تعداد کلیکهای بر روی تبلیغات قرار داده شده در آن صفحه می‏دانند به نوعی بسمتی پیش می‏روند که بجای قرار دادن اطلاعات واقعاً مفید، اطلاعاتی گیشه پسند در سایتشان قرار دهند تا بلکه از این راه بتوانند درآمد بیشتری از راه تبلیغات کسب کنند. "من فکر می‏کنم از بسیاری طرق ما قدرت بالقوه وب را از دست داده‏ایم (همانطور که در مورد تلویزیون هم این اتفاق افتاد)." این جملات Mike Tinsley یک کاربر ناامید از اینترنت در ایندیانا است. او ادامه می‏دهد: "در روزهای اولیه وب، آنچه در آینده آن می‏دیدیم آموزش‏های مفید، اطلاعات رایگان برای همه و حتی سرگرمی بود. هر چند که مانند تلویزیون، وب نیز در چیزهای کم‏ارزش‏تر غرق شد و من بعید می‏دانم دوباره به آن شکوه روزهای اولیه‏اش بازگردد."
صنعت محتوای متمرکز بر تبلیغات، تلاش خود را برای ابداع روشهای جدید برای جلب چشمهای بیشتر بسمت تبلیغات ادامه می‏دهد و بعید به نظر می‏رسد که این مشکلات به این زودی‏ها حل شود. در همین حال، فروشندگان مرورگرها و سایر برنامه‏های سودمند (Utility) شاید بتوانند این مشکلات را تا حدودی و بصورت موقت حل کنند. تولیدکنندگان مرورگر نظیر Microsoft و Mozilla بصورت پیش فرض، باید تبلیغات انیمیشنی و ویدیویی را قبل از آنکه تمام یک صفحه را در سیطره خود در آوردند بلاک کنند تا جستجوگری که بدنبال مشاهده محتوای آن صفحه است بتواند مطلب مورد نظرش را براحتی پیدا کند. حتی اگر این قابلیتها را نمی‏توانند بصورت پیش‏فرض فعال کنند حداقل در تنظیمات مرورگرشان گزینه‏هایی ساده برای کاربر بمنظور بلاک کردن این تبلیغات آزاردهنده قرار دهند.

4. نیاز به استانداردها
درصد موافقت 58
برخی چیزهایی که در صفحات وب نمایش داده می‏شوند خیلی آزاردهنده است؛ مثلاً در یک صفحه وب می‏بینید: "صفحه‏ای که هم اکنون مشاهده می‏کنید برای نمایش صحیح نیاز به Internet Explorer دارد." (تصویری سمت چپ نشان می‏دهد Google Docs در Safari قابل نمایش نیست و ضمن دادن وعده برای پشتیبانی آن به زودی زود، به کاربر توصیه می‏کند در حال حاضر یکی از مرورگرهای رایگان را دانلود کند.)
ریشه تاریخی این مشکل به ناکاملی (و گاهی مشکلات) پشتیبانی Internet Explorer از استانداردهای طراحی یک صفحه وب بازمی‏گردد. چرا که IE سهم بالایی از بازار مرورگرها را در اختیار دارد و بسیاری از طراحان صفحات وب در طراحی‏هایشان بیشتر از آنکه رعایت استانداردها را در نظر بگیرند نمایش درست صفحه طراحی شده‏شان در IE را مد نظر قرار می‏دهند. Firefox در این زمینه موفقتر بوده است چرا که اکثر سایتها (به استثنای بسیاری از سایتهای تحت Microsoft) در مرورگر Mozilla Firefox بدرستی نمایش داده می‏شوند. اما هنوز کاریران Opera و Safari در حاشیه مانده‏اند. از صفحاتی که حاوی فرمهای مالی هستند گرفته تا سایتهای Web 2.0 بسیاری از آنها در همه مرورگرها بدرستی نمایش داده نمی‏شوند؛ مگر آنکه کاربران را مجبور کرد برای مشاهده هر صفحه از مرورگر خاصی استفاده کنند.
اگر سازندگان مرورگرها بر روی استاندارد خاصی توافق کنند ممکن است این سکسکه که اکنون گریبان‏گیر وب است ناپدید شود. هر چند که در نسخه‏های جدید IE، Microsoft تلاش کرده است پشتیبانی از استانداردها را بهبود دهد (در کنار اینکه از استانداردهای تعریف شده قبلی‏اش را نیز پشتیبانی می‏کند.). اما این مشکل همچنان باقی است؛ چرا که بسیاری از طراحان وب تنها استانداردهای تعریف شده از سوی IE و Firefox را لحاظ می‏کنند.
شما با ایجاد یک سند جدید در Google Docs مشکل دارید؟ توصیه سایت بسیار ساده انگارانه‏تر از آن است که مشکل کاربر را حل کرده باشد.
در بین این برنامه‏هایی که در لیست سیاه قرار دارند نامهای Google Docs، Washington Mutual و Yahoo بیشتر به چشم می‏خورد که هیچکدامشان در مرورگرهای Opera و Safari قابل استفاده نیستند.

5. خرابکارهای فارومها
درصد موافقت 58
اینترنت می‏توانست پلتفرم گسترده‏ای برای انواع تبادلات باشد به نوعی که در آن کاربران به شیوه‏های متمدنانه در این مجامع شرکت کنند و به بحث و گفتگو در خصوص موضوعات مختلف بپردازند. اما متأسفانه در وب حاضر این طور نشده است.
"من واقعاً احساس تنفر می‏کنم هنگامی که در یک فاروم، برخی افراد پستهای نامرتبط می‏فرستند و یا در مورد اینکه فلانی چقدر باحال است و یا منطقه‏شان چقدر دنج است صحبت می‏کنند." اینها جملاتی است که یکی از خوانندگان PC World بنام Roberta Dikeman از کالیفرنیا می‏گوید. او در ادامه می‏پرسد: "آیا بعد از آن، ما می‏توانیم به بحث در مورد آن موضوع ادامه دهیم و یا وجود آن جملات احمقانه و بی‏مصرف را در سایتمان تحمل کنیم!"
پنهان ماندن در پشت نامهای کاربری مستعار در وب، باعث می‏شود این خرابکاران براحتی بتوانند بحثهای مفید را مختل کنند. آنها از طریق حرفهای بی‏فایده و بی‏مفهوم، توهینهای شخصی، استفاده از زبان گستاخانه، عمداً فارومها را بسمت بحثهای ناامیدکننده و ناموزن سوق می‏دهند.
این خرابکاران در همه جا هستند. در گروه‏های خبری Yahoo، Google، قسمت نظرسنجی وبلاگها و در فارومهایی که یک شخص سئوالی تخصصی را مطرح کرده است.
یکی از راه‏های آسان و البته مفید مقابله با چنین اقداماتی این است که مدیران این گروه‏ها در جذب اعضایشان حساسیت بیشتری بخرج دهند. دیدگاه دیگر این است که کاربران از طریق حذف موارد نامرتبط و آزاردهنده خود پلیس برقراری نظم در فارومها باشند.

6. گرانی خرید بلیت
درصد موافقت: 54
سایتهایی نظیر Ticketmaster که به منظور مدیریت یکی از بزرگترین ارمغانهای اینترنت (یعنی خرید بلیت و چاپ آن تنها با چند کلیک) بوجود آمده‏اند، اکنون هزینه‏ای مضاعف دریافت می‏کنند. آژانسهای سنتی فروش بلیت، سربارهای مالی زیادی بابت هزینه‏های پرسنل، اجاره، تجهیزات و محیط فیزیکی خود دارند. اما Ticketmaster.com، بزرگترین آژانس فروش آنلاین بلیت جهان، 9 دلار اضافه‏تر بابت هزینه راحتی (Convenience Charge) برای مثلاً هر بلیت کنسرت 32.5 دلاری در سانفرانسیسکو بعلاوه 4.9 دلار هرینه پردازش (Processing Fee) برای هر سفارش دریافت می‏کند. بنابراین برای هر بلیتی که می‏خرید باید 42 درصد مبلغ واقعی بلیت بابت هزینه‏های اضافی‏ای که Ticketmaster از شما دریافت می‏کند بپردازید! اگر فرض کنید تمام بلیتهای کنسرت بفروش نرفته است شما می‏توانید همان بلیت را از باجه فروش بلیت محل برگزاری آن کنسرت با قیمت 32.5 دلار بخرید و نزدیک به 14 دلار صرفه‏جویی کنید.
یکی از دلایلی که Ticketmaster توانسته است این هزینه‏ها را بدون اعتراض از مردم دریافت کند رقابت کم در بازار تجاری فروش بلیت بوده است. این شرکت قراردادهای انحصاری با بسیاری از شرکتهای ایالات متحده دارد. در سال 1994، یک طرفدار موسیقی راک با نام Pearl Jam، در خصوص بالا بودن هزینه‏های دریافت شده از سوی Ticketmaster و تلاش برای انحصاری کردن این صنعت به وزارت دادگستری ایالات متحده شکایت کرد. اما در نهایت این وزارتخانه اعلام کرد که Ticketmaster از هیچ قانونی تخلف نکرده است.

7. راهنمای Web 2.0، کمکی نمی‏کند.
درصد موافقت: 49
تکنولوژی Web 2.0 از برنامه‏های مفیدی که با واسطهای کاربری زیبایی آراسته شده‏اند پشتیبانی می‏کند. اما اگر شما در هنگام کار با این برنامه‏ها بخواهید از راهنمای آنها استفاده کنید و برای این منظور بر روی لینک راهنمای سایت کلیک کنید خواهید دید که در نهایت به بن‏بست خواهید رسید.
دلیل آن این است که بسیاری از پاسخهای قرار داده شده در صفحات راهنما و سئوالات رایج (FAQ) بسیار کلی‏تر و بدیهی‏تر از آن است که مشکلی را حل کنند. برای نمونه یک برنامه ممکن است در یک مرورگر بدرستی کار نکند چرا که یک plug-in مرورگر از کار افتاد است و یا برنامه دیگری که بر روی آن سیستم قرار گرفته با این برنامه جدید ناسازگاری دارد اما در صفحه راهنما و یا سئوالات رایج این سایتها این مشکلات بصورت جزئی پاسخ داده نشده‏اند.
بجای قرار دادن راهنماهای کلی در این سایتها می‏توان از فارومها، اتاقهای چت، ویکی‏ها و سایر مواردی که کاربران بتوانند خودشان از روی تجربیات و یا تخصصشان در خصوص این مشکلات در محیطی ارتباطی به یکدیگر کمک کنند استفاده گردد.

8. گرانی کتابهای الکترونیک
درصد موافقت: 41
هزینه انتشار و توزیع کتابها بصورت الکترونیک باید بسیار کمتر از چاپ و کپی آن به شیوه دشوار سنتی باشد. پس چرا کاربران باید هزینه‏ای برابر و در برخی موارد بیشتر بابت خرید یک کتاب الکترونیک بپردازند؟ برای نمونه نسخه الکترونیکی کتاب The Secret اثر Rhonda Byrne در eBooks.com به قیمت 15.29 دلار بفروش می‏رسد؛ در حالی Amazon.com نسخه چاپی همین کتاب را با جلد رحلی بهمراه ارسال به درب منزلتان 13.17 دلار می‏فروشد که واقعاً عجیب است!
بطور میانگین ناشران قیمت کتابهای الکترونیک خود را بین 8 تا 16 دلار قرار می‏دهند و این همان محدوده قیمتی است که برای نسخ چاپی لحاظ می‏شود. شاید دلیل آنها این است که بخش زیادی از این قیمتها مربوط به هزینه‏ای است که نویسندگان اثر بابت فروش هر کتاب بی‏توجه به نوع چاپ و فروش دریافت می‏کنند. ناشران می‏گویند آنها مشغول طراحی مدلی برای قیمت گذاری فروش کتابهای الکترونیک هستند که نتیجه آن مشخص خواهد کرد مردم چقدر پول بابت خرید یک رمان الکترونیک، باید بپردازند. همچنین آنها مشغول بررسی این موضوع هستند که فروش کتابهای الکترونیک چه اثری بر روی فروش کتابهای چاپی خواهد گذاشت.

9. ویدیوهای ناامیدکننده
درصد موافقت: 38
کیفیت تصاویر فیلمهای ویدیویی تحت وب هر روز بهتر می‏شوند اما کمبود محتویات با کیفیت باعث شده است که کاربران کمتر بتوانند از فیلمهای ویدیویی موردنظرشان بصورت آنلاین استفاده کنند.
برخی شبکه‏ها بخصوص ABC و CBS قرار دادن نمایشهای تلویزیونی خود بر روی اینترنت را آغاز کرده‏اند اما مصرف‏کنندگان هنوز در پیدا کردن برنامه‏های موردعلاقه‏شان با قیمت مناسب دچار مشکل هستند.
در بخش نمایشهای تلویزیونی Apple's iTunes Music Store هر اپیزود یک موسیقی پاپ با قیمت 1.99 دلار بفروش می‏رسد. اما Rafat Ali کسی که بحث رسانه‏های دیجیتال را از طریق PaidContent.org دنبال می‏کند می‏گوید که همه نمایشها در حال حاضر قابل دسترس نیستند چرا که صاحبان آثار بزرگ (نظیر HBO) نگرانند که ارائه نسخه‏های آنلاین از نمایش‏هایشان، فروش برنامه‏هایشان از طریق تلویزیونهای کابلی را تحت تاثیر قرار دهد.
"من نمی‏توانم بصورت آنلاین آخرین نسخه The Sopranos را خریداری کنم چرا که HBO آنرا بصورت آنلاین ارائه نکرده است. این یک ناامیدی بزرگ برای علاقمندان است." Ali ادامه می‏دهد: "هنوز بسیاری شرکتهای مردد، علاقه‏ای به قرار دادن برنامه‏هایشان بر روی وب ندارند."

10. خستگی از دنیاهای مجازی
درصد موافقت: 9
با وجود وعده و وعیدهایی که در خصوص دنیاهای مجازی نظیر Second Life است ما بسیار متعجب شدیم که تعداد کمی از خوانندگان ما به این موضوع علاقه نشان می‏دهند. بیش از نیمی از نظردهندگان ما گفته بودند از کیفیت این محیطها بسیار ناراضی هستند و تنها 25 درصد آنها از کیفیت این محیطها ابراز رضایت کرده بودند.
تحلیلگر Yankee Group، Christopher Collins در این خصوص می‏گوید در زمانی که شبکه‏های اجتماعی نظیر MySpace و Facebook رشد سریعی را شاهد هستند بزرگترین دنیای مجازی، یعنی Second Life از سال 2006 تا کنون نرخ رشد کمتری داشته است.
تازه‏واردان دنیاهای مجازی (که اکثراً از طریق وعده‏های رسانه‏ها به این محیطها پیوسته‏اند) اغلب بعد از مدتی این محیطها را ترک می‏کنند. این محیطها دارای واسطهای کاربری قدیمی و خطاهای نرم‏افزاری زیادی هستند. بر اساس آماری که Second Life در 7 اکتبر 2007 اعلام کرده است این سایت در مجموع 10 میلیون عضو دارد. اما تنها 1.3 میلیون (13 درصد) آنها در طول یک ماه قبلش به سایت وارد شده بودند. و از این تعداد، 338000 نفر در طول هفته پیش از آن به سایت وارد شده بودند.
برای جذب کاربران بیشتر، دنیاهای مجازی ناچار هستند که از واسطهای کاربری جدیدتری استفاده کنند که بسیاری از چیزهای دنیای واقعی را در آن نمایش دهد. آنها شاید بتوانند به این هدف برسند در صورتی که نرم‏افزارهایشان را توسعه و تکنولوژی‏های جدید را بکار گیرند و البته از کاربرانشان نیز درس بگیرند.
وبِ بهبودیافته؛ وب امروز، شایستگی این عنوان را نخواهد داشت مگر زمانی که صاحبان سایتها و کاربران همه با هم تلاش کنند تا این مشکلات را برطرف سازند تا همه بتوانند از آنچه می‏خواهند بدرستی بهره گیرند.

نویسنده : سید حسین محتسبی

حفاظت از اطلاعات در استفاده از خدمات آنلاین مالی و اعتباری

روند انتشار کدهای مخرب بسیار نگران کننده تر از حالتی ست که کاربران معمولی و خانگی اینترنت تصور می کنند. با افزایش تعداد افرادی که بطور تفریحی و یا جدی به نفوذ در سیستم ها و تخریب آنها مشغولند، تنوع کدهای مخرب با ریسک های تخریبی متنوع، به نحو چشمگیری افزایش یافته است. با این وجود، به نظر می رسد که کاربران اینترنت، به ویژه کاربران خانگی آن، در رابطه با حمله های مخرب این کدها نگرانی اندکی دارند و شرایط فعلی، انگیزه مناسبی را برای حفاظت از رایانه ها و اطلاعات موجود در آن ها ایجاد نمی کند .

بر خلاف عقیده کاربران غیر حرفه ای اینترنت، سرفت اطلاعات مالی و اعتباری افراد در هنگام استفاده از خدمات بانکی آنلاین، تنها به علت کلاهبرداری (فیشینگ) و یا عملکرد جاسوس افزارها نمی باشد بلکه عوامل و شرایط دیگری نیز در این خصوص باید مورد توجه قرار گیرند.

یکی از این عوامل مهم، اعتماد بیش از حد کاربران اینترنت به عدم قرارگرفتن در معرض حملات مخرب است. بیشتر افراد گمان می کنند که امکان حمله هکرها به رایانه و تخریب سیستم آنها توسط کدهای مخرب بسیار اندک است. "واقعا کدام هکر به خود زحمت می دهد تا اطلاعات بانکی من را که پول کمی در آن وجود دارد سرقت کند." "هکرها بیشتر به سراغ میلیونرهایی می روند که در حساب بانکی شان پول های فراوانی با ارقام نجومی وجود داشته باشد."

اما این عقیده ای کاملا نادرست است. کاربران باید به خاطر داشته باشند در هنگام اتصال به شبکه اینترنت آنها تنها توسط آدرس های IP خود شناسایی می شوند و نه خصوصیات شخصیتی و یا موجودی حساب بانکی. اصولا برای یک هکر و یا خرابکار اینتنرتی، نفوذ و حمله به رایانه ای با آدرس 12.34.56.78 (مثلا در آمریکا) با ورود غیر مجاز و تخریب رایانه دیگری به آدرس 87.65.43.21 (در بلژیک) کاملا یکسان است. اگر در هر کدام از این آدرس ها، حساب های بانکی وجود داشته باشند که بصورت آنلاین و اینترنتی مورد استفاده قرار بگیرد، حتی با وجود کم بودن موجودی ، باز هم انگیزه خوبی برای هکرها و خرابکاران اینترنتی است که اطلاعات محرمانه مربوط به آن را در اختیار داشته باشند.
کاربران رایانه باید بدانند که بسیاری از مجرمان اینترنتی به پول های اندک نیز قانع اند، و برای آنها مقداری اندک همیشه بهتر از هیچ است.

خطرات و ریسک های امنیتی مربوط به خریدهای اینترنتی، نقل و انتقال پول و بررسی حساب های بانکی بسیار زیاد است. اما خوشبختانه راه های کنترل و حذف این خطرات نیز(در صورت توجه و عملکرد صیح کاربران) وجود دارد.
بیشتر کاربران اینترنت برای پیشگیری از ریسک های امنیتی در معاملات اینترنتی، معمولاً به نصب و استفاده از برنامه های امنیتی با قابلیت ردیابی جاسوس افزارها و تروژان ها اکتفا می کنند. اما متاسفانه آمارهای موجود، نشان دهنده شرایطی است که از وضعیت مورد تصور کاربران بسیار وخیم تر می باشد: خلق و انتشار بیش از هزار گونه مختلف از بدافزارهای رایانه ای به صورت روزانه؛ یعنی تقریبا یک بدافزار در هر دقیقه !! این بدان معناست که کاربران باید تمام وقت خود را تنها به امن کردن محیط کاری خود اختصاص دهند در حالیکه هیچ وقتی برای انجام کارهای دیگر ندارند!

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

با توجه به تمام شرایط و موارد فوق، توصیه آخر کارشناسان امنیتی به کاربران خدمات بانکی آنلاین، این است که قبل از ورود به وب سایت بانک ها و موسسات مالی و دریافت خدمات آنلاین از آنها، حتما با استفاده از آخرین نسخه بروز رسانی شده یک نرم افزار قدرتمند امنیتی، رایانه و محیط سیستم خود را از وجود بدافزارهای فعال پاکسازی کرده و از فن آوری های حفاظت پیشگیرانه مانند TruPrevent برای ردیابی و خنثی سازی کدهای مخرب بسیار جدید، ناشناخته و سریع الانتشار استفاده کنند.

بسته به حجم دیسک های سخت مورد استفاده در رایانه های فعلی و نیز حجم برنامه های مختلف موجود در آنها معمولا زمان بررسی، جستجو و پاکسازی رایانه ها ممکن است قدری زمان بر و طولانی باشد.
برای رفع این مشکل نیز کاربران رایانه می توانند از نرم افزار NanoScan استفاده کنند، این برنامه با قابلیت های پیشرفته و عملکرد سریع خود می تواند در مدت زمان بسیار کوتاهی محیط شبکه و سیستم کاربران را برای انجام معاملات اینترنتی و استفاده از خدمات بانکی آنلاین، امن و نفوذ ناپذیر نماید: www.nanoscan.com

نویسنده : اسماعیل ذبیجی

تفاوت تلویزیون پلاسمایی و LCD چیست؟

بزرگترین تلویزیون جهان در لندن به فروش رسید.این تلویزیون که بوسیله شرکت پاناسونیک ساخته شده و قیمت آن ۵۰ هزار پوند (۹۸۴۶۰ دلار ) است، دارای یک صفحه پلاسمایی ۱۰۳ اینچی با وزن کمرشکن ۲۲۰ کیلوگرم است. این آخرین فرآورده تکنولوژی تفریح خانگی ممکن است از دسترس اغلب ما دور باشد، اما هنوز گزینه‌های بسیار دیگری در بازار موجودند که مشتریان تلویزیون را وسوسه می‌کنند.
● پرسش‌های زیر ممکن است در خریدن تلویزیون برای شما هم مطرح شود:
▪ تفاوت تلویزیون پلاسمایی و LCD چیست؟
هنگامی که می‌خواهید بین خریدن تلویزیون پلاسمایی و LCD(صفحه کریستال مایع) انتخاب کنید، در واقع دارید میان دو تکنولوژی در حال رقابت مقایسه انجام می‌دهید. هر دوی این تکنولوژی‌ها دو روی یک سکه دیجیتال هستند و در تلاش برای رسیدن به نتایج مشابهی هستند: تصاویر شفاف و با رنگ طبیعی .
در تلویزیون‌های پلاسمایی نور از سلول‌هایی منفرد ساطع می‌شود و می‌تواند با ظرافت سایه‌های رنگ‌ها را با جزئیات بیشتری نشان دهد، در حالیکه صفحه‌های LCD از نور پشتی لوله‌های فلورسانس استفاده می‌کنند که از میان یک شاتر کرکره‌ مانند عبور می‌کنند.
این سیستم‌های رقیب در سال‌‌‌های اخیر بازار را به دست گرفته‌اند و اگر شما بخواهید یک تلویزیون جدید بخرید احتمال از یکی از این دو تکنولوژی در آن استفاده شده است.

 
▪ کدامیک از این دو بهترند؟
به زبان ساده به علت آنکه طریقه ساطع‌شدن نور از صفحه‌هایی پلاسمایی، کیفیت و وضوح رنگ از این صفحه‌ها تاثیر بسیار بیشتری در بینندگان در اتاقی ایجاد می‌کند که نور محیطی آن کمتر است مثلا در اتاق نشیمن . اما برعکس اگر می‌خواهید تلویزیونی را برای یک محل پرنورتر مثلا آشپزخانه‌تان بخرید، کارآیی LCD بسیار بیشتر است.
گرچه سازندگان این مسئله را که تلویزیون‌های پلاسمایی برق بیستر مصرف می‌کنند، کارشناسان مستقل مدعی‌اند که برق مصرفی این نوع تلویزیون‌ها تقریبا دو برابر بیشتر است.
▪ آیا بزرگتر زیباتر است؟
شکی نیست که صفحه تلویزیون‌ها دارد بزرگ و بزرگتر می‌شود، اما گروه‌های مصرف‌کنندگان می‌گویند شاهدی وجود ندارد که هرچه صفحه نمایش تلویزیون بزرگتر شود، تصویر ان هم بهتر شود. البته اگر درخشندگی بالا مد نظر باشد، مطمئنا صفحه بزرگتر تاثیرگذارتر است.
در هرحال تردیدی وجود ندارد که یک خانواده متوسط که برای خریدن تلویزیون به فروشگاه می‌رود به اندازه و رنگ تلویزیون و حتی نوع طراحی دستگاه کنترل راه‌ اهمیت بیشتری می‌دهد تا ظرافت‌های چگونگی انتقال تصاویر بر روی صفحه نمایش.

▪ آیا باید تلویزیون را به دیوار آویزان کرد؟
امروزه با دسترس قرار گرفتن صفحه‌‌های نمایش مسطح می‌توانیم آنها را روی دیوار نصب کرد. البته توجه داشته باشید که گیره‌‌ها و وسائل ثابت‌کننده روی دیوار را باید جدا بخرید و معمولا باید از کمک یک کارشناس برای نصب آنها استفاده کنید که مستلزم هزینه اضافی است و نیز بروشورهای بیشتری باید بخوانید.نهایتا باید مطمئن شوید که دیوار قدرت تحمل وزن این صفحه نمایش سنگین را داشته باشد.

 
▪ تلویزیون وضوح بالا چیست؟
وضوح بالا یا HD به معنای سیگنال‌های تلویزیونی است که که با وضوح بیشتری نسبت به قالب‌های سنتی پخش می‌شوند و در نتیجه تصاویر واضح‌تر و زنده‌تری را بوجود می‌آورند.برای مثال در آمریکا که این سیستم برای اولین بار در میانه دهه ۱۹۹۰ ارائه شد و اکنون نیز رواج بیشتری دارد – تلویزیون‌های HD پنج برابر بیشتر نسبت به تلویزیون‌های معمولی اطلاعات ویدئویی بیشتری را به نمایش می‌گذارند. در انگلیس در بسیاری از دستگاه‌های تلویزیون چه پلاسمایی و چه LCD قابلیت HD تلفیق شده است.
اما بسیاری از افراد نمی‌دانند که خریدن یکی از این سیستم‌ها ضرورتا به معنای نشان‌دادن خودکار تصاویر با وضوح بالا نیست. چرا که در حال حاضر تنها مشترکان تلویزیون‌های کابلی و ماهواره‌ای کانال‌های با کیفیت HD را در اختیار دارند ( و برای آن هزینه اضافی می‌پردازند). به عقیده کارشناسان تا زمانی که پخش تلویزیونی زمینی به شکل HD درآید زمان زیادی باقی است.

▪ تلویزیون‌های قدیمی تا کی همچنان کار خواهند کرد؟
سیگنال‌های تلویزیونی آنالوگ قدیمی در انگلیس از سال ۲۰۱۲ به بعد متوقف خواهند شد، به این ترتیب اگر شما تلویزیون غیردیجیتال داشته باشید و مشترک تلویزیون کابلی، ماهواره‌ای یا فرمت‌های گوناگون آنها نباشید، تلویزیونتان در این زمان کاملا بی‌مصرف می‌شود. علت آن است که همه سرویس‌های تلویزیونی کابلی/ماهواره‌ای/رایگان در این زمان با شکل دیجیتال پخش خواهند شد و این فرمت نهایتا" به هنجار معمول پخش تلویزیونی بدل خواهد شد. البته مادامی که مشترک یکی از این فرمت ها باشید، تلویزیون قدیمی‌تان مشکلی ایجاد نخواهد کرد. و لازم نیست نگران HD، LCD و پلاسما و غیره باشید. حتی هنوز می‌توانید تلویزیونهای آنالوگ غیردیجیتال را به خصوص به شکل پرتابل برای اتاق خواب و ... بخرید، اما هنگام خرید این تلویزیون‌ها در نظر داشته باشید که آنها هنگامی که انقلاب دیجیتال در سال ۲۰۱۲ کاملا تحقق یابد، دیگر کار نخواهند کرد .