بحث و بررسی پیرامون آنالیز و طراحی سیستم های نرم افزاری در سوپر گروه تخصصی :
https://telegram.me/SystemAnalysis/318
https://telegram.me/SystemAnalysis/318
بحث و بررسی پیرامون مدیریت پروژه های نرم افزاری و پایخ به سوالات مرتبط با مهندسی نرم افزار https://telegram.me/joinchat/Bvjv_j9FFJ_Ak9eT5P0_EQ
Algorithms for Generating Permutations and
Combinations
Combinations
Four Useful Algorithms: GCD, Subsets, Permutations and Combinations :
Forwarded from M
کتاب مهندسی نرم افزار ، نوشته راجر اس . پرسمن ، ویرایش هفتم
عنوان کتاب : Software Engineering: A Practitioner’s Approach
نویسنده : Roger S. Pressman
ویرایش : هفتم (SEVENTH EDITION)
زبان کتاب : انگلیسی
تعداد صفحات : ۹۲۶
ساختار فایل : PDF
حجم فایل : ۱۵۰ MB
رمز فایل فشرده : www.irstu.com
http://dl.irstu.com/wp-content/uploads/Education/Academic/Software%20Engineering/Software%20Engineering/EBooks/Persman/SEPA-7Edition.rar
عنوان کتاب : Software Engineering: A Practitioner’s Approach
نویسنده : Roger S. Pressman
ویرایش : هفتم (SEVENTH EDITION)
زبان کتاب : انگلیسی
تعداد صفحات : ۹۲۶
ساختار فایل : PDF
حجم فایل : ۱۵۰ MB
رمز فایل فشرده : www.irstu.com
http://dl.irstu.com/wp-content/uploads/Education/Academic/Software%20Engineering/Software%20Engineering/EBooks/Persman/SEPA-7Edition.rar
نمونه سوالات درس آنالیز و طراحی سیستمهای نرم افزاری :
Forwarded from Batis Ab
Tahlil_Tarahi_Systemha.rar
4.3 MB
Forwarded from ⭕️ @panachannel
طراحی نرمافزار بدون رعایت اصول مهندسی نرمافزار همانند ساخت خانه بدون نقشه استاندارد و مهندسی شده است! متاسفانه در بسیاری از شرکتهای تولید کننده نرمافزار جهت تولید محصولات نرمافزاری اصول مهندسی را رعایت نمیکنند ویا تعدادی از مراحل مخصوصا مرحله تست را از چرخه تولید نرمافزار خارج میکنند. این امر باعث کاهش قیمت تولیدی نرمافزار میشود اما هزینه پشتیبانی و نگهداری آن را چندین برابر میکند. چراکه بسیاری از ایرادهای برنامه در مرحله تست برطرف نمیشوند.
مهندس نرمافزار پیش از اعمال روشها در خصوص موارد تست، بایستی اصول اساسی که تست نرمافزار را هدایت میکند، درک کند. مجموعهای از این اصول عبارتند از:
۱. تست با توجه به نیازمندیهای کاربر: همانطور که میدانید شناسایی نیازمندیهای کاربر اولین گام چرخه تولید نرمافزار میباشد. این نیازها طی یک کار تیمی و روشهای متفاوت با مشارکت مشتریان یا کاربران و توسعهدهندگان شناسایی میشوند. سپس نیازهای عمومی، ضروری، اولویت بالا و حداقل نیازها مشخص میگردد. در این پست به همین توضیح خلاصه بسنده کنیم که این بخش حیطه وسیعی از مطالعه و تحقیق نیازدارد. پس از شناخت نیازمندیها، تستها بایستی تاحد خواستههای مشتری قابل ردیابی باشند.
۲. برنامهریزی قبل از اجرا: پس از شناخت نیازمندیها و مشخص کردن آنها، برای هر بخش نوشتن برنامه تست (test plan) ضروری است. همه تستها را میتوان پیش از تولید هرگونه کد، برنامهریزی و طراحی کرد.
۳. قانون پارتو: این قانون بدین معنا است که در هرچیزی، میزان اندکی (۲۰ درصد) دارای اهمیت حیاتی و بسیاری (۸۰ درصد) کم اهمیت و یا دارای اهمیت ناچیز است. مدیران پروژهها میدانند که ۲۰ درصد کار (اولین ۱۰ درصد و آخرین ۱۰ درصد) ۸۰ درصد زمان و منابع را مصرف میکند بنابراین با تمرکز برآن ۲۰ درصد، ۸۰ درصد نتایج را میتوان تولید کرد. تست هم از این قاعده مستثنی نیست! یعنی ۸۰ درصد خطاهای کشف نشده در ۲۰ درصد کد است. یا به عبارتی ۲۰ درصد نواقص باعث ۸۰ درصد مشکلات میشوند. این اصل به عنوان یک یادآوری روزانه میتواند درخدمت ما باشد و به ما بگوید که زمان و انرژی خود را بر آنچه که واقعا مهم است، متمرکز کنیم.
۴.شروع تست از اجزای کوچک: تست باید از اجزای کوچک شروع شده و به ابعاد بزرگتر گسترش یابد. اولین تستها بر روی هر یک از مولفهها انجام میشوند. با پیشرفت تست، خطاهای مجموعهای از مولفههای مجتمع و سپس کل برنامه یافت میشود.
۵. تست کامل (exhaustive) ممکن نیست: تعداد مسیرهای ممکن برای تست برنامه زیاد است. لذا اجرای هر ترکیبی از مسیرها امکانپذیر نیست. ولی این امکان وجود دارد که برنامه را در حد کفایت پوشش دهیم. غیرممکن است که بتوان یک برنامه را به طور کامل تست کرد.
رعایت اصول تست نرمافزار باعث افزایش زمان تولید و بهرهمندی از متخصصین مرتبط در آن زمینه و افزایش هزینه تولید نرمافزار میشود اما با در نظر گرفتن کاهش چشمگیر هزینههای پشتیبانی و توسعه، نرمافزار تولید شده بسیار مقرون به صرفهتر خواهد بود! تست نرمافزار یکی از فازهای اصلی و گران در چرخه حیات نرمافزار محسوب میشود. رعایت اصول تست باعث کاهش هزینهها میگردد.
۶. انجام تست توسط شخص ثالث بیطرف: برای موثر بودن بایستی تست توسط شخص ثالث بیطرف انجام شود. منظور از موثربودن این است که خطاها را با احتمال بیشتری پیدا کنیم. به دلایلی که در بخشهای بعدی ذکر میکنیم، مهندس نرمافزاری که سیستم را برنامه نویسی کرده است، بهترین کسی نیست که باید همه تستها را انجام دهد. بنابراین برنامهنویس بایستی از تستهای مختلف برنامه خود اجتناب کند.
۷. تستهای اولیه و متناوب: تست در همان ابتدای کار آغاز شده و در طول چرخه حیات نرمافزار ادامه یافته و به صورت متناوب تکرار میشود. تستهای اولیه کمک میکنند تا در مراحل اولیه از فرآیند توسعه نرمافزار، خطاها تشخیص داده شده و تصحیح آنها به سادگی انجام شود. این تستها باعث کاهش هزینه میگردند. این نکته قابل ذکر است که تکرار تست و تناوب آن در طول تولید برنامه بایستی گسترش پیدا کند.
۸. کوهی از خطاها: در پروژههای تست، خطاها توزیع نمیشوند! در جایی از برنامه که خطا کشف میشود این احتمال که خطاهای بیشتری را بتوان پیدا کرد بیشتر است. احتمال اینکه اشکالات بیشتری در قسمتی از برنامه کشف شود متناسب با تعداد اشکالات کشف شده قبلی در آن بخش از برنامه است. به عبارت دیگر هر چه در ماژولی از برنامه خطاهای بیشتری پیدا کنید، احتمال وجود خطاهای دیگر در آن ماژول بیشتر است.
مهندس نرمافزار پیش از اعمال روشها در خصوص موارد تست، بایستی اصول اساسی که تست نرمافزار را هدایت میکند، درک کند. مجموعهای از این اصول عبارتند از:
۱. تست با توجه به نیازمندیهای کاربر: همانطور که میدانید شناسایی نیازمندیهای کاربر اولین گام چرخه تولید نرمافزار میباشد. این نیازها طی یک کار تیمی و روشهای متفاوت با مشارکت مشتریان یا کاربران و توسعهدهندگان شناسایی میشوند. سپس نیازهای عمومی، ضروری، اولویت بالا و حداقل نیازها مشخص میگردد. در این پست به همین توضیح خلاصه بسنده کنیم که این بخش حیطه وسیعی از مطالعه و تحقیق نیازدارد. پس از شناخت نیازمندیها، تستها بایستی تاحد خواستههای مشتری قابل ردیابی باشند.
۲. برنامهریزی قبل از اجرا: پس از شناخت نیازمندیها و مشخص کردن آنها، برای هر بخش نوشتن برنامه تست (test plan) ضروری است. همه تستها را میتوان پیش از تولید هرگونه کد، برنامهریزی و طراحی کرد.
۳. قانون پارتو: این قانون بدین معنا است که در هرچیزی، میزان اندکی (۲۰ درصد) دارای اهمیت حیاتی و بسیاری (۸۰ درصد) کم اهمیت و یا دارای اهمیت ناچیز است. مدیران پروژهها میدانند که ۲۰ درصد کار (اولین ۱۰ درصد و آخرین ۱۰ درصد) ۸۰ درصد زمان و منابع را مصرف میکند بنابراین با تمرکز برآن ۲۰ درصد، ۸۰ درصد نتایج را میتوان تولید کرد. تست هم از این قاعده مستثنی نیست! یعنی ۸۰ درصد خطاهای کشف نشده در ۲۰ درصد کد است. یا به عبارتی ۲۰ درصد نواقص باعث ۸۰ درصد مشکلات میشوند. این اصل به عنوان یک یادآوری روزانه میتواند درخدمت ما باشد و به ما بگوید که زمان و انرژی خود را بر آنچه که واقعا مهم است، متمرکز کنیم.
۴.شروع تست از اجزای کوچک: تست باید از اجزای کوچک شروع شده و به ابعاد بزرگتر گسترش یابد. اولین تستها بر روی هر یک از مولفهها انجام میشوند. با پیشرفت تست، خطاهای مجموعهای از مولفههای مجتمع و سپس کل برنامه یافت میشود.
۵. تست کامل (exhaustive) ممکن نیست: تعداد مسیرهای ممکن برای تست برنامه زیاد است. لذا اجرای هر ترکیبی از مسیرها امکانپذیر نیست. ولی این امکان وجود دارد که برنامه را در حد کفایت پوشش دهیم. غیرممکن است که بتوان یک برنامه را به طور کامل تست کرد.
رعایت اصول تست نرمافزار باعث افزایش زمان تولید و بهرهمندی از متخصصین مرتبط در آن زمینه و افزایش هزینه تولید نرمافزار میشود اما با در نظر گرفتن کاهش چشمگیر هزینههای پشتیبانی و توسعه، نرمافزار تولید شده بسیار مقرون به صرفهتر خواهد بود! تست نرمافزار یکی از فازهای اصلی و گران در چرخه حیات نرمافزار محسوب میشود. رعایت اصول تست باعث کاهش هزینهها میگردد.
۶. انجام تست توسط شخص ثالث بیطرف: برای موثر بودن بایستی تست توسط شخص ثالث بیطرف انجام شود. منظور از موثربودن این است که خطاها را با احتمال بیشتری پیدا کنیم. به دلایلی که در بخشهای بعدی ذکر میکنیم، مهندس نرمافزاری که سیستم را برنامه نویسی کرده است، بهترین کسی نیست که باید همه تستها را انجام دهد. بنابراین برنامهنویس بایستی از تستهای مختلف برنامه خود اجتناب کند.
۷. تستهای اولیه و متناوب: تست در همان ابتدای کار آغاز شده و در طول چرخه حیات نرمافزار ادامه یافته و به صورت متناوب تکرار میشود. تستهای اولیه کمک میکنند تا در مراحل اولیه از فرآیند توسعه نرمافزار، خطاها تشخیص داده شده و تصحیح آنها به سادگی انجام شود. این تستها باعث کاهش هزینه میگردند. این نکته قابل ذکر است که تکرار تست و تناوب آن در طول تولید برنامه بایستی گسترش پیدا کند.
۸. کوهی از خطاها: در پروژههای تست، خطاها توزیع نمیشوند! در جایی از برنامه که خطا کشف میشود این احتمال که خطاهای بیشتری را بتوان پیدا کرد بیشتر است. احتمال اینکه اشکالات بیشتری در قسمتی از برنامه کشف شود متناسب با تعداد اشکالات کشف شده قبلی در آن بخش از برنامه است. به عبارت دیگر هر چه در ماژولی از برنامه خطاهای بیشتری پیدا کنید، احتمال وجود خطاهای دیگر در آن ماژول بیشتر است.