شناخت یک راهکار یا محصول نرمافزاری و انتخاب یک تهیه کننده و یا ارائه دهنده مطمئن، تنها بخشی از یک فرایند انتخاب صحیح یک نرمافزار است. بهترین حالت این است که به شکل موازی همه فاکتورها را باهم بررسی نماییم. در زیر فاکتورهایی که باید در رابطه با خرید یک محصول نرمافزاری در نظر گرفته شود، به صورت مختصر مورد بررسی قرار گرفته است. آنچه میخوانید مقالهای است از شرکت فناوری داده پویشگر از شناختهشدهترین شرکتهای تولید و طراحی نرمافزارهای حرفهای در صنعت در و پنجره که با سپاس از مدیریت این شرکت، پنجره ایرانیان شما را به مطالعه این مقاله دعوت میکند.
استانداردهای انتخاب نرمافزار:
همانطور که اشاره شد شناخت یک راهکار یا محصول نرمافزاری در انتخاب یک تهیه کننده و یا ارائه دهنده مطمئن، تنها بخشی از یک فرایند انتخاب صحیح نرمافزار است. بهترین حالت این است که به شکل موازی فاکتورهای دیگر را نیز ارزیابی کنیم. در اینجا سعی شده است معیارهای انتخاب یک نرمافزار مورد ارزیابی قرارگیرند:
نرمافزارباید ازجهت فناوری و معماری دارای امکانات و قابلیتهایی بشرح زیر باشد:
بررسی قابلیتها و توابع عملیاتی نرمافزار
نرمافزار از دیدگاه قابلیت و توابع عملیاتی باید پاسخگوی این قبیل موارد زیر باشد، آیا این محصول مناسب با نیازهای ما بوده و آن را پوشش میدهد؟ برای مشخص شدن این موضوع باید شاخصهای زیر را بررسی کنیم:
ازدیگر نکاتی که باید مورد بررسی قرار گیرد بحث خدمات و پشتیبانی آن شرکت نرمافزاری میباشد:
تیم اجرایی شرکت ارائه دهنده، برای پیاده سازی و ارائه محصول باید آمادگیهای لازم در زمینههای مختلف از جمله تعداد کافی پرسنل فنی، قابلیت کار به شکل تیمی، رعایت اصول ساختار لایهای و سایر موارد تجربه کافی داشته باشند.
نرمافزار مناسب برای پیاده سازی پروژه
در طراحی یک نرمافزار رعایت اصول استاندارد طراحی، استفاده از الگوهای آماده و بهرهگیری از روشهای نوین بسیارمهم است، ولی نکته مهم این است که در اصل کاربران، باعث میشوند یک پروژه نرمافزاری به نتیجه برسد، یعنی فناوری و پروسه استفاده شده، در حقیقت در رده دوم اهمیت قرار دارند.
برخی از مشکلات نرمافزارهای ناموفق:
عدم توانایی تولیدکنندگان در تشخیص نیازهای کاربران، وجود ایرادهای (error ها) تکراری، تأخیر در ارائه محصول و... از طرف دیگر، مشتریان اینگونه نرمافزارها از عدم دقت در ارائه برنامه زمانبندی دقیق از طرف طراحان سیستم، کیفیت پایینِ نرمافزارهای تولیدی و افزایش هزینهها شکایت دارند.
در این پروژهها برنامه نویسان ساعتهای زیادی را صرف تهیه نرمافزاری میکنند که مملو از مشکل است و تلاش آنان چنان که باید، مؤثر نیست. وقتی با این مشکلات مواجه میشویم، به این فکر میافتیم که باید در کار خود روش و رویهای درست داشته باشیم که فعالیتهای مربوط به پروژه در آن مشخص و منظم باشد، نیازهای کاربران در آن مشخص باشد و خروجی نرمافزار و محصولات پروژه با موفقیت تولید شوند. برای این کار میتوانیم به تجربیات کسب شده در پروژههای گذشته خود مراجعه کنیم و فعالیتهای موفقی که در آن پروژهها انجام شده است را دوباره انجام دهیم و از کارهایی که باعث مشکل در آن پروژهها گشتهاند، پرهیز کنیم.
البته نمی توانیم با این کار از عدم وجود مشکل در نرمافزار خود مطمئن باشیم؛ زیرا مشکلات، چه بخواهیم چه نخواهیم، بروز خواهند کرد و از آنجایی که در کار رویهای ثابت نداریم و تنها از تجربیات قدیمی خود استفاده میکنیم، نمی توانیم انتظار داشته باشیم که نرمافزارهای ما بدون اشکال باشند؛ زیرا ممکن است با مشکلی برخورد کنیم که تا به حال با آن برنخوردهایم و تجربهای در رفع آن نداریم.
اوایل سال ۲۰۰۱ تعدادی از محققان و صاحب نظران نرمافزار، گروهی به نام Agile Alliance را تشکیل دادند که توانست راه حلی برای تیمهای نرمافزاری پیدا کند تا به سرعت و با کیفیت بالا نرمافزار تولید کنند و بتوانند اگر تغییری در قسمتی از نرمافزار به وجود آمد، آن را کنترل کنند و اصلاحات لازم را اعمال نمایند. آنها مدعی هستند که راه بهتری برای تولید نرمافزار پیشنهاد کردهاند که کار ما برنامهنویسان را آسان کرده است.
آنها چند اصل مهم را به عنوان مانیفیست یا بیانیه خود در نظر گرفتهاند. از جمله: اهمیت نقش اعضای تیم در پروژه نرمافزاری، تولید مستندات مناسب برای نرمافزار، اهمیت نقش کاربران سیستم و استفاده از آنها در مراحل ساخت نرمافزار، و توانایی اعمال تغییرات در نرمافزار در تمامی مراحل تولیدی آن.
تولید مستندات
کدهای برنامه نمیتوانند به تنهایی و بدون راهنما و مستندات توسط دیگر افراد قابل فهم باشند. طراحان نرمافزار باید مستنداتی فراهم کنند که بتواند به کسی که بعدها به آن کدها مراجعه میکند نشان دهد که طراحان اولیه این سیستم چگونه ساختار برنامه را درست کردهاند. البته درست کردن مستنداتِ زیاد و غیرضروری کار درستی نیست و وقت تلف کردن است. مهندسان نرمافزار اصطلاح خوبی برای مستندات دارند و میگویند: مستندات نرمافزار باید «کوتاه» و «ساکت» باشد. منظور از کوتاه این است که باید مختصر و دقیق باشد و منظور از ساکت این است که نباید خیلی به جزئیات غیرضروری بپردازد و خواننده را خسته نماید.
اهمیت نقش کاربران سیستم در پروژه
نرمافزار را نمی توان مانند اجناس دیگر سفارش داد. نمی توانید انتظار داشته باشید که شرح فنی نرمافزاری را بنویسید واز کسی بخواهید آن را در مدت زمان معین و با قیمت معین به اتمام برساند. پروژههای نرمافزاری که اینگونه سفارش داده شدهاند، اکثراً شکست خوردهاند. پروژههای موفق پروژههایی هستند که در آن کاربران به صورت مستقیم درمراحل اجرایی پروژه دخیل اند و نظرات مشتریان که همان کاربران سیستم باشند، از ابتدا مورد توجه قرار گرفته است.اگر کاربران سیستم در تمامی مراحل تولید و پیاده سازی نرمافزار حضور داشته باشند و در مورد کار و محصول به دست آمده تا آن زمان اعلام نظر کنند، میتوان مطمئن بود پس از اتمام کار انتظار بالاتری از سیستم نخواهد داشت
اصول تولید نرمافزار به روش Agile Development
نشریه پنجره ایرانیان، سال هفتم، شماره 84،مهرماه 1393