Forwarded from ⭕️ @panachannel
چرخه حیات تولید نرمافزار روندی است که تحلیلگران فنآوری اطلاعات با استفاده از آن اقدام به تولید و طراحی سیستمهای نرمافزاری و انطباق آنها با نیازهای مشتریان نموده و در تحلیل خود نیازمندیهای دنیای واقعی را مدنظر قرار میدهند. تحلیلگران فنآوری اطلاعات در تمامی روند تولید یعنی آزمایش، تجزیهوتحلیل و نگهداری، کلیه جنبههای مثبت و منفی را ثبت و موردتوجه قرار میدهند. SDLC حروف اختصاری Software Development Life Cycle است که به معنی چرخه حیات تولید نرمافزار یا سیستم است و برخی از تحلیلگران آن را روند تولید نرمافزار مینامند. چرخه حیات نرمافزار چارچوبی است که کلیه عملیاتی را که در هر مرحله از تولید نرمافزار انجام میگیرد تعریف مینماید. استاندارد ۱۳۳۰۷ یک استاندارد و معیار بینالمللی جهت روند تولید نرمافزارها به شمار میرود. هدف از تدوین این استاندارد تعریف کلیه وظایف مرتبط با چرخه حیات تولید نرمافزارها است.
چرخه حیات تولید نرمافزار چیست؟
چرخه حیات تولید نرمافزار (SDLC) روندی است که در تولید و یا پروژه و یا تجدید طراحی یک نرمافزار در یک سازمان دنبال میگردد. این روند کلیه عملیات ازجمله نحوه تولید، نگهداری، جایگزینی و یا تغییر و یا بهبود کیفی نرمافزار را در برمیگیرد. چرخه حیات معرف شناسایی روش اصلاح و بهبود کیفی نرمافزار و روند تولید همهجانبه آن است.
این راهنمای آموزشی حاوی مدلهای گوناگون چرخه حیات تولید نرمافزار و سناریوهایی است که مدلهای مختلف را مورداستفاده قرار میدهند. اطلاعات این راهنمای آموزشی مدیران پروژه را در انتخاب مدل مناسب پروژه یاری رسانده و همچنین برنامه نویسان و تستکنندگان را کمک مینماید که از اصول اساسی مدلهای تولید آگاهی یابند. در این راهنما کلیه مدلهای چرخه حیات تولید و یا تولید نرمافزار اعم از مدلهای سنتی و یا مدرن بررسی گردیده و در پایان هر مرحله نظرات موافق و مخالف و راههای کاربرد عملی مدلهای چرخه حیات تولید نرمافزار نیز مورد ارزیابی قرارگرفته است. مدل آبشاری و مدل V مدلهای سنتی و از نوع افزایشی هستند. منظور از افزایشی این است که مرحله بعدی صرفاً میتواند پس از تکمیل مرحله قبلی آغاز گردد. این مدلها برای پروژههایی مطلوب هستند که نیازمندیهای محصول روشن و آشکار بوده و این نیازها در طول دوره و تا تکمیل پروژه تغییر نخواهد کرد. مدلهای تکراری یا حلزونی با تغییرات سازگار بوده و برای پروژههایی که نیازمندیها به نحوی تعریف و مشخص نشدهاند و یا نیازمندیهای بازار غالباً دچار تغییر میگردند مناسب میباشند. مدل بیگ بنگ از زمره روشهای نادر در تولید نرمافزار بوده و صرفاً جهت پروژههای کوچک و یا دانشگاهی مطلوب است.
مدل چابک معروفترین مدل در صنعت محسوب میگردد. مدل چابک با استفاده از شیوه مدلسازی توان تحویل سریع محصول به مشتری را دارا است. مدل چابک پروژه را به بخشهای تکراری کوچک که هر یک دارای ویژگی خاصی است تقسیم مینماید. تعامل مشتری، در این مدل ستون فقرات متدولوژی را تشکیل داده و ارتباط باز با حداقل مستندات از مشخصات بارز محیط تولید چابک محسوب میگردد.
مدل تولید سریع و نمونهسازی نرمافزار، تکنیکی نوین در جهت شناخت نیازمندیها در مراحل اولیه چرخه پروژه بشمار میرود. در این مدل و تکنیک، یک مدل نمونه و کاری جهت مشاهده و ارائه نظریات به مشتریان و ذینفعان ارائه میگردد. بازخورد مشتریان با شیوهای منظم و متشکل جهت اصلاح و تکمیل محصول مورداستفاده قرار میگیرد.
چرخه حیات تولید نرمافزار چیست؟
چرخه حیات تولید نرمافزار (SDLC) روندی است که در تولید و یا پروژه و یا تجدید طراحی یک نرمافزار در یک سازمان دنبال میگردد. این روند کلیه عملیات ازجمله نحوه تولید، نگهداری، جایگزینی و یا تغییر و یا بهبود کیفی نرمافزار را در برمیگیرد. چرخه حیات معرف شناسایی روش اصلاح و بهبود کیفی نرمافزار و روند تولید همهجانبه آن است.
این راهنمای آموزشی حاوی مدلهای گوناگون چرخه حیات تولید نرمافزار و سناریوهایی است که مدلهای مختلف را مورداستفاده قرار میدهند. اطلاعات این راهنمای آموزشی مدیران پروژه را در انتخاب مدل مناسب پروژه یاری رسانده و همچنین برنامه نویسان و تستکنندگان را کمک مینماید که از اصول اساسی مدلهای تولید آگاهی یابند. در این راهنما کلیه مدلهای چرخه حیات تولید و یا تولید نرمافزار اعم از مدلهای سنتی و یا مدرن بررسی گردیده و در پایان هر مرحله نظرات موافق و مخالف و راههای کاربرد عملی مدلهای چرخه حیات تولید نرمافزار نیز مورد ارزیابی قرارگرفته است. مدل آبشاری و مدل V مدلهای سنتی و از نوع افزایشی هستند. منظور از افزایشی این است که مرحله بعدی صرفاً میتواند پس از تکمیل مرحله قبلی آغاز گردد. این مدلها برای پروژههایی مطلوب هستند که نیازمندیهای محصول روشن و آشکار بوده و این نیازها در طول دوره و تا تکمیل پروژه تغییر نخواهد کرد. مدلهای تکراری یا حلزونی با تغییرات سازگار بوده و برای پروژههایی که نیازمندیها به نحوی تعریف و مشخص نشدهاند و یا نیازمندیهای بازار غالباً دچار تغییر میگردند مناسب میباشند. مدل بیگ بنگ از زمره روشهای نادر در تولید نرمافزار بوده و صرفاً جهت پروژههای کوچک و یا دانشگاهی مطلوب است.
مدل چابک معروفترین مدل در صنعت محسوب میگردد. مدل چابک با استفاده از شیوه مدلسازی توان تحویل سریع محصول به مشتری را دارا است. مدل چابک پروژه را به بخشهای تکراری کوچک که هر یک دارای ویژگی خاصی است تقسیم مینماید. تعامل مشتری، در این مدل ستون فقرات متدولوژی را تشکیل داده و ارتباط باز با حداقل مستندات از مشخصات بارز محیط تولید چابک محسوب میگردد.
مدل تولید سریع و نمونهسازی نرمافزار، تکنیکی نوین در جهت شناخت نیازمندیها در مراحل اولیه چرخه پروژه بشمار میرود. در این مدل و تکنیک، یک مدل نمونه و کاری جهت مشاهده و ارائه نظریات به مشتریان و ذینفعان ارائه میگردد. بازخورد مشتریان با شیوهای منظم و متشکل جهت اصلاح و تکمیل محصول مورداستفاده قرار میگیرد.
مجموعه ویدیو های MS Project قسمت 57 ⚛️ SYSTEM ANALYSIS AND DESIGN METHODS ⚛️ @SystemAnalysis
مجموعه ویدیو های MS Project قسمت 58 ⚛️ SYSTEM ANALYSIS AND DESIGN METHODS ⚛️ @SystemAnalysis
http://stackoverflow.com/insights/survey/2016 آمار استفاده از سیستم عامل ها توسط توسعه دهندگان
مجموعه ویدیو های MS Project قسمت 59 ⚛️ SYSTEM ANALYSIS AND DESIGN METHODS ⚛️ @SystemAnalysis
Forwarded from 🔵 SYSTEMS ANALYSIS AND DESIGN METHODS
🔲دسته بندی ساختار عمومی تیم های نرم افزاری 🔲
در این نوشتار سه دسته از مهم ترین ساختار عمومی تیم هارا توضیح می دهیم.
نامتمرکز دمکراتیک (Democratic Decentralized)
در این پروژه عموما مدیر پروژه ی ابدی وجود ندارد .هماهنگ کنندگان وظایف برای مدت کوتاهی منسب می شوند.تصمیم گیری بر اساس اجماع گرفته می شود.ارتباط بین افراد افقی است.
نامتمرکز کنترل شده (Controlled Decentralized)
در این ساختار رهبر و دستیار تعریف شده وجود دارد. حل مسئله در گروه، اما پيادهسازي راهحل توسط رهبر بين گروهها تقسيم ميشود.ارتباط بين زيرگروهها افقي؛ ارتباط با رهبر و کنترل عمودي است.
متمرکز کنترل شده (Controlled Centralized)
در این ساختار رهبر و دستيار تعريف شده وجود دارد.حل مسئله در سطح بالا انجام ميشود.ارتباط بين رهبر و اعضاي تيم عمودي است.
در این نوشتار سه دسته از مهم ترین ساختار عمومی تیم هارا توضیح می دهیم.
نامتمرکز دمکراتیک (Democratic Decentralized)
در این پروژه عموما مدیر پروژه ی ابدی وجود ندارد .هماهنگ کنندگان وظایف برای مدت کوتاهی منسب می شوند.تصمیم گیری بر اساس اجماع گرفته می شود.ارتباط بین افراد افقی است.
نامتمرکز کنترل شده (Controlled Decentralized)
در این ساختار رهبر و دستیار تعریف شده وجود دارد. حل مسئله در گروه، اما پيادهسازي راهحل توسط رهبر بين گروهها تقسيم ميشود.ارتباط بين زيرگروهها افقي؛ ارتباط با رهبر و کنترل عمودي است.
متمرکز کنترل شده (Controlled Centralized)
در این ساختار رهبر و دستيار تعريف شده وجود دارد.حل مسئله در سطح بالا انجام ميشود.ارتباط بين رهبر و اعضاي تيم عمودي است.
Forwarded from Batis Ab
Forwarded from Batis Ab
#CrossCloud
♣️ با رشد رایانش ابری تعداد زیادی از شرکتهای کوچک و کاربران بهسمت استفاده از آن سوق داده شدند. رایانش ابری مزایای بسیاری از جمله قابلیت اطمینان بالا دارد. اما مشکل اصلی زمانی نمایان شد که کاربران پس از رو آوردن به این سیستمها متوجه شدند که دیگر قابلیت جابجایی به محیط ابری دیگری ندارند. سرویسهایی که دریافت میکنند چه خوب و چه بد باشد، مجبور به استفاده از آن خواهند بود و حق انتخاب دیگری ندارند. بههمین علت مفهوم جدیدی با نام Cross Cloud متولد شد.
♣️ گذشت زمان به کاربران رایانش ابری جنبههایی از رایانش ابری را نشان داده که شاید تا چند سال قبل هیچ کس از آن آگاه نبود. عدم قابلیت جابجایی بین محیطهای رایانش ابری، به سود شرکتهای سرویسدهنده و به ضرر کاربران نهایی شد. حال با گذشت چند سال از فراگیر شدن رایانش ابری، برای اینکه کاربران بیشتری به موضوع رایانش ابری جذب شوند و حقوق کاربران نهایی رعایت شود، مفهوم Cross Cloud مطرح شد.
@SystemAnalysis
♣️ با رشد رایانش ابری تعداد زیادی از شرکتهای کوچک و کاربران بهسمت استفاده از آن سوق داده شدند. رایانش ابری مزایای بسیاری از جمله قابلیت اطمینان بالا دارد. اما مشکل اصلی زمانی نمایان شد که کاربران پس از رو آوردن به این سیستمها متوجه شدند که دیگر قابلیت جابجایی به محیط ابری دیگری ندارند. سرویسهایی که دریافت میکنند چه خوب و چه بد باشد، مجبور به استفاده از آن خواهند بود و حق انتخاب دیگری ندارند. بههمین علت مفهوم جدیدی با نام Cross Cloud متولد شد.
♣️ گذشت زمان به کاربران رایانش ابری جنبههایی از رایانش ابری را نشان داده که شاید تا چند سال قبل هیچ کس از آن آگاه نبود. عدم قابلیت جابجایی بین محیطهای رایانش ابری، به سود شرکتهای سرویسدهنده و به ضرر کاربران نهایی شد. حال با گذشت چند سال از فراگیر شدن رایانش ابری، برای اینکه کاربران بیشتری به موضوع رایانش ابری جذب شوند و حقوق کاربران نهایی رعایت شود، مفهوم Cross Cloud مطرح شد.
@SystemAnalysis
Forwarded from Batis Ab
WhatIsCrossCloud.pdf
185 KB
Forwarded from Batis Ab
#Android #GoogleChrome
⚛️ چگونه اپلیکیشنهای اندروید را در مرورگر گوگل کروم اجرا کنیم
@AndroidStudyChannel
⚛️ چگونه اپلیکیشنهای اندروید را در مرورگر گوگل کروم اجرا کنیم
@AndroidStudyChannel
مجموعه ویدیو های MS Project قسمت 60 ⚛️ SYSTEM ANALYSIS AND DESIGN METHODS ⚛️ @SystemAnalysis
☻ چرخه تولید نرم افزار
برنامه نويس برنامه نرم افزار را مينويسد و معتقد است كه هيچ خطايي ندارد.
نرم افزار تست ميشود. 20 خطا پيدا ميشود.
برنامه نويس 10 خطا را اصلاح ميكند و به واحد تست توضيح ميدهد كه 10 مورد ديگر واقعاً خطا نيستند.
واحد تست نرم افزار متوجه ميشود 5 مورد از اصلاحات انجام شده كار نميكنند و 15 خطاي جديد هم كشف ميكند.
مراحل 3 و 4 سه بار تكرار ميشود.
به خاطر فشار بازاريابي و اعلام عمومي زود هنگام كه بر اساس زمانبندي خوشبينانه برنامه نويسي انجام شده است، نرم افزار منتشر ميشود.
كاربران 137 خطاي جديد پيدا ميكنند.
برنامه نويس پول خود را دريافت كرده است و ديگر نميتوان او را پيدا كرد.
تيم جديد برنامه نويسي تقريباً تمام 137 خطا را اصلاح ميكند اما 546 خطاي ديگر به نرم افزار اضافه ميكند.
برنامه نويس اصلي به واحد تست نرم افزار كه پول كمي دريافت كردهاند از فيجي يك كارت پستال ميفرستد.
كل افراد واحد تست كار را رها ميكنند.
شركت رقيب فرصت طلب با استفاده از سود حاصل از فروش آخرين نسخه نرم افزار كه 783 خطا دارد، شركت را ميخرد.
مدير عامل جديد تعيين ميشود. او يك برنامه نويس استخدام ميكند تا نرم افزار موجود را بازنويسي كند.
برنامه نويس برنامه نرم افزار را مينويسد و معتقد است كه هيچ خطايي ندارد...
برنامه نويس برنامه نرم افزار را مينويسد و معتقد است كه هيچ خطايي ندارد.
نرم افزار تست ميشود. 20 خطا پيدا ميشود.
برنامه نويس 10 خطا را اصلاح ميكند و به واحد تست توضيح ميدهد كه 10 مورد ديگر واقعاً خطا نيستند.
واحد تست نرم افزار متوجه ميشود 5 مورد از اصلاحات انجام شده كار نميكنند و 15 خطاي جديد هم كشف ميكند.
مراحل 3 و 4 سه بار تكرار ميشود.
به خاطر فشار بازاريابي و اعلام عمومي زود هنگام كه بر اساس زمانبندي خوشبينانه برنامه نويسي انجام شده است، نرم افزار منتشر ميشود.
كاربران 137 خطاي جديد پيدا ميكنند.
برنامه نويس پول خود را دريافت كرده است و ديگر نميتوان او را پيدا كرد.
تيم جديد برنامه نويسي تقريباً تمام 137 خطا را اصلاح ميكند اما 546 خطاي ديگر به نرم افزار اضافه ميكند.
برنامه نويس اصلي به واحد تست نرم افزار كه پول كمي دريافت كردهاند از فيجي يك كارت پستال ميفرستد.
كل افراد واحد تست كار را رها ميكنند.
شركت رقيب فرصت طلب با استفاده از سود حاصل از فروش آخرين نسخه نرم افزار كه 783 خطا دارد، شركت را ميخرد.
مدير عامل جديد تعيين ميشود. او يك برنامه نويس استخدام ميكند تا نرم افزار موجود را بازنويسي كند.
برنامه نويس برنامه نرم افزار را مينويسد و معتقد است كه هيچ خطايي ندارد...
مجموعه ویدیو های MS Project قسمت 61 ⚛️ SYSTEM ANALYSIS AND DESIGN METHODS ⚛️ @SystemAnalysis
مجموعه ویدیو های MS Project قسمت 62 ⚛️ SYSTEM ANALYSIS AND DESIGN METHODS ⚛️ @SystemAnalysis
مجموعه ویدیو های MS Project قسمت 63 ⚛️ SYSTEM ANALYSIS AND DESIGN METHODS ⚛️ @SystemAnalysis