Forwarded from Software Science and AI
این کتاب به شما می آموزد که تحلیل نیازمندی ها را در پروژه های نرم افزاری به چه روشی انجام دهید. کتاب حاصل اجرای چند باره روش در پروژه های نرم افزاری و تجربیات آموزشی در دانشگاه ها و شرکت های نرم افزاری و کارگاه های تخصصی است.
لینک دسترسی به کتاب فوق:
http://www.eshraghipublishing.ir/NAFAjaxSearch/Detail/68356/%d9%83%d8%aa%d8%a7%d8%a8
لینک دسترسی به کتاب فوق:
http://www.eshraghipublishing.ir/NAFAjaxSearch/Detail/68356/%d9%83%d8%aa%d8%a7%d8%a8
Eshraghipub
فروشگاه کتاب اشراقی
روش كاربردي تحليل نيازمندي هاي نرم افزار (بي بالان) صفار
Forwarded from Hamidreza
سلام و عرض ادب خدمت دوستان عزیز
بحثی مطرح شده بود در خصوص طراحی دیتابیس های یکپارچه که به نظرم ذکر چند نکته خالی از لطف نباشه.
ببینید در سیستمهای Enterprise الزاما بحث یکپارچه بودن به معنی یکسان بودن و یکی بودن دیتابیس نیست! این مورد رو همین الان در تفکراتتون اصلاح کنید.
منظور از یکپارچگی این هست که دیتای تکراری در کل نرم افزار نباشه، هر زیر سیستمی بتونه به اطلاعات زیرسیستم های دیگه در صورت نیاز دسترسی داشته باشه ، بتوان گزارشات جامع و یکپارچه طراحی کرد. این ساختار اصلا در تضاد با جداسازی دیتابیس ها نیست.
مزایای دیتابیس واحد :
- شما کافیه فقط از یک دیتابیس بکاپ تهیه کنید.
- در زمان جابجایی خیلی دردسر خاصی روی دیتابیس نخواهید داشت.
- دسترسی ها بر روی یک دیتابیس اعمال میشن -
- نصب و راه اندازیش به مراتب راحتتره.
معایب دیتابیس واحد :
- بحث بکاپ گیری تفکیکی از زیر سیستم های مختلف
- عدم جابجایی بخشی از دیتابیس و منتقل کردن بخشی از بار بر روی سرورهای دیگه.
- امنیت پایین و در خطربودن تمام اطلاعات
- نگهداری دشوار در حجم های بالا
مزایای دیتابیس های غیر متمرکز :
- امکان تجزیه بار نرم افزار بر روی سرورهای مختلف
- امکان بکاپ گیری از هرزیر سیستمی از نرم افزار
- کم حجم بودن بکاپ ها و مدیریت آسان آنها
- نگهداری راحتتر دیتابیس ها
در این جا من بخشی از مزایا و معایب هر دو روش رو ذکر کردم.
دوستان اشکال وارد کردند که مثلا ممکنه مراکز هزینه تعریف بشه و جای دیگه نیاز باشه باید داده هاش تعریف بشه. خیر به این صورت نیست.
در دیتابیس های غیرمتمرکز یک دیتابیس به عنوان Master Data قرار میدن که تمام اطلاعات پایه که نیاز هست همه سیستم ها ازش استفاده کنن داخل اون تعریف میشه. و به محض تغییر داده ها همه سیستم ها میتونن ازش استفاده کنن و نیازی به نگهداری این اطلاعات ندارن.
هر زیر سیستمی فقط اطلاعات مربوط به خودش رو داره. و اینکه فرض کنید اصلا در یک زیرسیستمی شما نیاز دارید که از دیتابیس NoSQL استفاده کنید. که با این روش به شدت دست شما باز خواهد بود و به راحتی این امکان رو بهتون میده. هیچ افزونگی در سیستم ایجاد نخواهد شد .
اگر در طراحی این سیستم ها به مشکل برخوردین احتمالا طراحیتون درست نبوده.( این دلیل نمیشه که چون شما موفق نبودین این روش مناسب نیست)
مثلا شما Sharepoint رو نگاه کنید. نزدیک 10 تا دیتابیس مختلف میسازه. یعنی واقعا مایکروسافت خودش نمیدونست و نمیتونست بیاد همه اینهارو داخل یک دیتابیس نگهداری کنه؟؟؟؟
ولی در سیستم های متوسط و کوچک خیلی شاید کارایی نداشته باشه و میشه همه ساختارها داخل یک دیتابیس باشه. چون اکثر شرکتها و سازمانها خیلی نیازی به این پیچیدگی معماری ندارند و همونطور که مهندس ابهری هم فرمودن برای انتخاب یک معماری ، باید نیاز اون سیستم مشخص بشه.
ارادتمند
بحثی مطرح شده بود در خصوص طراحی دیتابیس های یکپارچه که به نظرم ذکر چند نکته خالی از لطف نباشه.
ببینید در سیستمهای Enterprise الزاما بحث یکپارچه بودن به معنی یکسان بودن و یکی بودن دیتابیس نیست! این مورد رو همین الان در تفکراتتون اصلاح کنید.
منظور از یکپارچگی این هست که دیتای تکراری در کل نرم افزار نباشه، هر زیر سیستمی بتونه به اطلاعات زیرسیستم های دیگه در صورت نیاز دسترسی داشته باشه ، بتوان گزارشات جامع و یکپارچه طراحی کرد. این ساختار اصلا در تضاد با جداسازی دیتابیس ها نیست.
مزایای دیتابیس واحد :
- شما کافیه فقط از یک دیتابیس بکاپ تهیه کنید.
- در زمان جابجایی خیلی دردسر خاصی روی دیتابیس نخواهید داشت.
- دسترسی ها بر روی یک دیتابیس اعمال میشن -
- نصب و راه اندازیش به مراتب راحتتره.
معایب دیتابیس واحد :
- بحث بکاپ گیری تفکیکی از زیر سیستم های مختلف
- عدم جابجایی بخشی از دیتابیس و منتقل کردن بخشی از بار بر روی سرورهای دیگه.
- امنیت پایین و در خطربودن تمام اطلاعات
- نگهداری دشوار در حجم های بالا
مزایای دیتابیس های غیر متمرکز :
- امکان تجزیه بار نرم افزار بر روی سرورهای مختلف
- امکان بکاپ گیری از هرزیر سیستمی از نرم افزار
- کم حجم بودن بکاپ ها و مدیریت آسان آنها
- نگهداری راحتتر دیتابیس ها
در این جا من بخشی از مزایا و معایب هر دو روش رو ذکر کردم.
دوستان اشکال وارد کردند که مثلا ممکنه مراکز هزینه تعریف بشه و جای دیگه نیاز باشه باید داده هاش تعریف بشه. خیر به این صورت نیست.
در دیتابیس های غیرمتمرکز یک دیتابیس به عنوان Master Data قرار میدن که تمام اطلاعات پایه که نیاز هست همه سیستم ها ازش استفاده کنن داخل اون تعریف میشه. و به محض تغییر داده ها همه سیستم ها میتونن ازش استفاده کنن و نیازی به نگهداری این اطلاعات ندارن.
هر زیر سیستمی فقط اطلاعات مربوط به خودش رو داره. و اینکه فرض کنید اصلا در یک زیرسیستمی شما نیاز دارید که از دیتابیس NoSQL استفاده کنید. که با این روش به شدت دست شما باز خواهد بود و به راحتی این امکان رو بهتون میده. هیچ افزونگی در سیستم ایجاد نخواهد شد .
اگر در طراحی این سیستم ها به مشکل برخوردین احتمالا طراحیتون درست نبوده.( این دلیل نمیشه که چون شما موفق نبودین این روش مناسب نیست)
مثلا شما Sharepoint رو نگاه کنید. نزدیک 10 تا دیتابیس مختلف میسازه. یعنی واقعا مایکروسافت خودش نمیدونست و نمیتونست بیاد همه اینهارو داخل یک دیتابیس نگهداری کنه؟؟؟؟
ولی در سیستم های متوسط و کوچک خیلی شاید کارایی نداشته باشه و میشه همه ساختارها داخل یک دیتابیس باشه. چون اکثر شرکتها و سازمانها خیلی نیازی به این پیچیدگی معماری ندارند و همونطور که مهندس ابهری هم فرمودن برای انتخاب یک معماری ، باید نیاز اون سیستم مشخص بشه.
ارادتمند
Forwarded from Software Science and AI
هنر بریدن، چیدن و کوتاه کردن
وقتی تیمور لنگ شروع به کشور گشایی کرد، هدفش فتح دنیا نبود. او فقط به قلعهی بعدی فکر میکرد. عجیب آنکه سر آخر تا پشت دیوار چین هم پیش رفت. تنها چیزی که او را از ادامهی پیروزی باز داشت مرگش بود.
مدیریت پروژه فرق زیادی با کشور گشایی ندارد. وقتی پروژهای بیش از حد بزرگ باشد، انجام یکباره آن غیر ممکن خواهد بود.
بسیاری از کافرماها بر این اصرارند تا تحویل گیرنده یک پروژهی کامل یا تقریبا کامل باشند. آنها لیستی به شما داده و انتظار داشته تا با نسخهی تقریبا کامل رویایشان بازگردید؛ در حالی که هیچکدام از شرکتهای تولید کنندهی نرمافزار در هیچ کجای دنیا از چنین روشی استفاده نمیکنند. آنها از سر و ته یک رویا زده تا پروژه در قالب زمان و هزینه قرار گیرد.
ایدههای مبتنی بر نرمافزار، محصولات یکبار تولید نیستند. ساده ترین سایت هم نیازمند بروزرسانی است. حتی اگر جاهلانه تصور کنیم که تکنولوژی پایدار (Stable) میماند، حادثهای برای سرور رخ نمیدهد و...، خود کار فرما به ایدههای جدیدتری خواهد رسید. به قول "جیسون زباسی" ایدهها قطعات سازنده ایدهها هستند.
مهم نیست که انتظار کارفرمای شما چه باشد. شما باید از آن کم کنید. کارفرماها معمولا (چه به لحاظ فنی و چه به لحاظ غیر فنی) رویاهای بزرگی در ابعاد آمازون، فیسبوک، یوتیوب یا حتی کمی کوچکتر و وطنی مانند اسنپ، کافهبازار و... دارند. به آنها یادآوری کنید که هدفِ اول باید فتح قلعهی بعدی باشد. اینکه آیا در نهایت به دیوار چین میرسید یا نه به آینده وابستگی دارد.
کانال مهندسی نرم افزار و هوش مصنوعی
@MKavehnia
وقتی تیمور لنگ شروع به کشور گشایی کرد، هدفش فتح دنیا نبود. او فقط به قلعهی بعدی فکر میکرد. عجیب آنکه سر آخر تا پشت دیوار چین هم پیش رفت. تنها چیزی که او را از ادامهی پیروزی باز داشت مرگش بود.
مدیریت پروژه فرق زیادی با کشور گشایی ندارد. وقتی پروژهای بیش از حد بزرگ باشد، انجام یکباره آن غیر ممکن خواهد بود.
بسیاری از کافرماها بر این اصرارند تا تحویل گیرنده یک پروژهی کامل یا تقریبا کامل باشند. آنها لیستی به شما داده و انتظار داشته تا با نسخهی تقریبا کامل رویایشان بازگردید؛ در حالی که هیچکدام از شرکتهای تولید کنندهی نرمافزار در هیچ کجای دنیا از چنین روشی استفاده نمیکنند. آنها از سر و ته یک رویا زده تا پروژه در قالب زمان و هزینه قرار گیرد.
ایدههای مبتنی بر نرمافزار، محصولات یکبار تولید نیستند. ساده ترین سایت هم نیازمند بروزرسانی است. حتی اگر جاهلانه تصور کنیم که تکنولوژی پایدار (Stable) میماند، حادثهای برای سرور رخ نمیدهد و...، خود کار فرما به ایدههای جدیدتری خواهد رسید. به قول "جیسون زباسی" ایدهها قطعات سازنده ایدهها هستند.
مهم نیست که انتظار کارفرمای شما چه باشد. شما باید از آن کم کنید. کارفرماها معمولا (چه به لحاظ فنی و چه به لحاظ غیر فنی) رویاهای بزرگی در ابعاد آمازون، فیسبوک، یوتیوب یا حتی کمی کوچکتر و وطنی مانند اسنپ، کافهبازار و... دارند. به آنها یادآوری کنید که هدفِ اول باید فتح قلعهی بعدی باشد. اینکه آیا در نهایت به دیوار چین میرسید یا نه به آینده وابستگی دارد.
کانال مهندسی نرم افزار و هوش مصنوعی
@MKavehnia
Forwarded from Software Science and AI
جامعه نرمافزاری ما (ایران) در لوپِ سينتكس و فريمورک گير کرده است. انگار همهمان برده ابزار و زبان شدهايم. كار اصلی مهندسین این حوزه، تحليل اطلاعات، پژوهش و توليد دانش است. کار با ابزار های پیادهسازی سیستمهای نرمافزاری در مراحل بعد از برنامهریزی، تجزیه، تحلیل، طراحی و معماری قرار دارد.
مطالعه نسخه آخر این کتاب برای توسعهدهنگان وباپلیکیشن های مدرن به ویژه .Net کارها توصیه میگردد.
@SystemAnalysis
@SystemAnalysis
Forwarded from Software Science and AI
معماری تکامل یا Architecture Evolution
برای درک اینکه چرا معماری پاک (Clean Architecture) بهتر، محبوب تر و اصولی تر یا غیر استاندارد تر از دیگر معماری های مطرح امروز و چند سال اخیر در جهان است، باید به نحوه تکامل معماری های نرم افزاری مختلف (تصویر بالا) نگاهی بیندازیم.
در صورت ممکن در آینده و در پست های بعد، ما چندین گروه از معماری های محبوب را مورد بحث قرار خواهیم داد.
کانال مهندسی نرم افزار و هوش مصنوعی
@MKavehnia
برای درک اینکه چرا معماری پاک (Clean Architecture) بهتر، محبوب تر و اصولی تر یا غیر استاندارد تر از دیگر معماری های مطرح امروز و چند سال اخیر در جهان است، باید به نحوه تکامل معماری های نرم افزاری مختلف (تصویر بالا) نگاهی بیندازیم.
در صورت ممکن در آینده و در پست های بعد، ما چندین گروه از معماری های محبوب را مورد بحث قرار خواهیم داد.
کانال مهندسی نرم افزار و هوش مصنوعی
@MKavehnia
Forwarded from راه پرداخت
Blockchain-way2pay.jpg
1.6 MB
Forwarded from Programming?
Packt_Java_EE_8_Design_Patterns.pdf
6.8 MB
سلام و عرض ادب خدمت دوستان
امروز به این مقاله برخورد کردم ، به نظرم خالی از لطف نیست یک نگاهی بهش بندازید و مطالعه بکنید.
https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/
ارادتمند
حمیدرضا صادقیان
امروز به این مقاله برخورد کردم ، به نظرم خالی از لطف نیست یک نگاهی بهش بندازید و مطالعه بکنید.
https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/
ارادتمند
حمیدرضا صادقیان
Joel on Software
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Ever wonder about that mysterious Content-Type tag? You know, the one you’re supposed to put in HTML and you never quite know what it should be? Did you ever get an email from your friends in…
Forwarded from SQLLand (Vahid Ghorbani)
#معرفی_کتاب
مرجعی کامل جهت بهبود عملکرد و کارایی در SQL Server 2017
#PerformanceTuning #SQL #QueryOptimization
@SQLLand
مرجعی کامل جهت بهبود عملکرد و کارایی در SQL Server 2017
#PerformanceTuning #SQL #QueryOptimization
@SQLLand
👍1
Forwarded from SQLLand (Vahid Ghorbani)
SQL Server 2017 Query Performance Tuning, 5th Edition.pdf
32.2 MB
Forwarded from SQLLand (Vahid Ghorbani)
#معرفی_کتاب
آموزش کاربرد انواع داده ای پیشرفته در SQL Server
XML, JSON, HierarchyID, Spatial
#PerformanceTuning #SQL #QueryOptimization
@SQLLand
آموزش کاربرد انواع داده ای پیشرفته در SQL Server
XML, JSON, HierarchyID, Spatial
#PerformanceTuning #SQL #QueryOptimization
@SQLLand