Forwarded from Batis Ab
03_Object_Oriented_Analysis,_Design.pdf
12.3 MB
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Batis Ab)
☀️ BPMN 2.0 HANDBOOK Second Edition ☀️
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Batis Ab)
white-bpmn2-process-bookmark-web.pdf
1.9 MB
Forwarded from Reza Movarrei
Roger_S_Pressman_Software_Engineering.pdf
87.9 MB
Forwarded from Batis Ab
⚛️ معرفی #کتاب :
✅ Data Structures & Algorithms in JAVA🎖
⭕️ @SystemAnalysis
#️⃣تگ ها 👈 🌀 #الگوریتم 🌀 #ساختمان_داده 🌀 #JAVA
✅ Data Structures & Algorithms in JAVA🎖
⭕️ @SystemAnalysis
#️⃣تگ ها 👈 🌀 #الگوریتم 🌀 #ساختمان_داده 🌀 #JAVA
👍1
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Batis Ab)
data-structures-and-algorithms-in-java.pdf
9.4 MB
⚛️ معرفی #کتاب :
✅ Data Structures & Algorithms in JAVA🎖
⭕️ @SystemAnalysis
#️⃣تگ ها 👈 🌀 #الگوریتم 🌀 #ساختمان_داده 🌀 #JAVA
✅ Data Structures & Algorithms in JAVA🎖
⭕️ @SystemAnalysis
#️⃣تگ ها 👈 🌀 #الگوریتم 🌀 #ساختمان_داده 🌀 #JAVA
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Batis Ab)
⚛️ معرفی #کتاب :
✅ Writting A Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
✅ Writting A Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Batis Ab)
Writing a Business Plan_.pdf
8.2 MB
⚛️ معرفی #کتاب :
✅ Writting A Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
✅ Writting A Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Batis Ab)
⚛️ معرفی #کتاب :
✅ One Hour Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
✅ One Hour Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Batis Ab)
One-Hour Business Plan.pdf
1.4 MB
⚛️ معرفی #کتاب :
✅ One Hour Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
✅ One Hour Business Plan🎖
#️⃣تگ ها 👈
🌀 #SystemAnalysis
🌀 #BusinessPlan
⭕️ @SystemAnalysis
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS (Hope Golestany)
What is DevOps ? @SystemAnalysis
❤1
Forwarded from SQL Server (Hamidreza)
با عرض سلام و ادب خدمت دوستان عزیز
امیدوارم حالتون خوب باشه
احتمالا در مورد Devops شنیدین و دیدین که همایشهای زیادی اخیرا داره برگزار میشه.
و تقریبا به یک موضوع روز در حوزه نرم افزار و ساختار شرکت های نرم افزاری مخصوصا تبدیل شده.
چند نفر از شما عزیزان در مجموعه هایی که تشریف دارین روی این حوزه فعالیت کردین؟ آیا به سمت راه اندازیش رفتین؟
آیا تمایلی به راه اندازی اون دارید؟ و به نظرتون چقدر میتونه در تولید محصولات باکیفیت به شما کمک کنه و چقدر میتونه هزینه تولید نرم افزار در شرکتهای شمارو کاهش بده؟
ممنون میشم نظراتتون رو بامن در میان بذارید
ارادتمند شما
حمیدرضا صادقیان
ID:@Hamidreza_Sadeghian
امیدوارم حالتون خوب باشه
احتمالا در مورد Devops شنیدین و دیدین که همایشهای زیادی اخیرا داره برگزار میشه.
و تقریبا به یک موضوع روز در حوزه نرم افزار و ساختار شرکت های نرم افزاری مخصوصا تبدیل شده.
چند نفر از شما عزیزان در مجموعه هایی که تشریف دارین روی این حوزه فعالیت کردین؟ آیا به سمت راه اندازیش رفتین؟
آیا تمایلی به راه اندازی اون دارید؟ و به نظرتون چقدر میتونه در تولید محصولات باکیفیت به شما کمک کنه و چقدر میتونه هزینه تولید نرم افزار در شرکتهای شمارو کاهش بده؟
ممنون میشم نظراتتون رو بامن در میان بذارید
ارادتمند شما
حمیدرضا صادقیان
ID:@Hamidreza_Sadeghian
👍1
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