دانلود کامل ترین جزوه الکترونیک صنعتی

جزوه تایپ شده الکترونیک صنعتی

دانلود فایل

کاردانی دانشگاه آزاد دانشگاه شریف دانشگاه علم و صنعت امیرکبیر آزمون استخدامی علمی کاربردی دانشگاه پیام نور دانشگاه آزاد کاردانی کارشناسی ارشد دکترا

()، “ً ” “: ”
: : :
: ؟
(): : : ً : ً [می خندد]، : (): بدیم.
وینود: و با کیفیت.
داگ: دقیقا. اما یادتون باشه که محدودیت هایی وجود داره. بازاریابی افزونه نرم افزاری رو که باید تولید بشه، البته با مشورت با ما، تعریف می کنه.
جیمی: خب؟
داگ: خب ما قصد داریم از UML به عنوان رویکرد مدل سازی خودمون استفاده کنیم.
وینود: اما اسناد اضافی رو به حداقل برسونید. داگ: رابط من کیه؟
جیمی: ما تصمیم گرفتیم که وینود پیشگام فناوری باشه؛ اون جزوه الکترونیک صنعتی تجربه رو داره، بنابراین وینود رابط شماست، اما در صورت تمایل می تونین با هر دوی ما صحبت کنین.
داگ (می خندد): نگران نباش، همین کار رو می کنم.

3-24 محصول
مدیر پروژه نرم افزاری در ابتدای یک پروژه نرم افزاری با یک معضل روبرو است. برآورد کمی و یک برنامه سازمان یافته مورد نیاز است، اما اطلاعات محکمی در دسترس نیست. تجزیه و تحلیل دقیق الزامات نرم افزاری، اطلاعات لازم برای برآورد را ارائه می دهد، اما تکمیل تجزیه و تحلیل، اغلب هفته ها یا الکترونیک صنعتی ماه ها طول می کشد. بدتر از آن، الزامات ممکن است سیال باشند و با پیشرفت پروژه به طور منظم تغییر کنند. با این حال، اکنون برنامه ای لازم است! چه بخواهید و چه نخواهید، باید محصول و مشکلی را که قرار است در ابتدای پروژه حل شود، بررسی کنید. حداقل، محدوده محصول باید تعیین و محدود شود.

الکترونیک صنعتی

1-3-24 محدوده نرم افزاری
اولین فعالیت مدیریت پروژه نرم افزاری تعیین محدوده نرم افزار است. محدوده با پاسخ به سوالات زیر تعریف می شود:
زمینه: نرم افزار ساخته شده چگونه در سیستم، محصول یا زمینه تجاری بزرگ تری قرار می گیرد و چه محدودیت هایی تحت تأثیر زمینه اعمال می شود؟
اهداف اطلاعاتی: چه اشیاء داده قابل مشاهده‌ای توسط مشتری، به عنوان خروجی از نرم افزار تولید می شود؟ چه داده هایی برای ورودی مورد نیاز است؟
عملکرد و کارایی: نرم افزار برای تبدیل داده های ورودی به خروجی، چه عملکردی را انجام می دهد؟آیا ویژگی های عملکرد خاصی باید مورد توجه قرار گیرد؟
محدوده پروژه نرم افزاری باید بدون ابهام و در سطوح مدیریتی و فنی قابل درک باشد. عملکرد محدوده نرم افزار، باید محدود باشد. یعنی داده های کمی (به عنوان مثال، تعداد کاربران همزمان، اندازه لیست پستی، حداکثر زمان پاسخگویی مجاز) به صراحت بیان شده باشد، محدودیت ها و/یا محدودیت ها (به عنوان مثال، هزینه محصول، حجم حافظه را محدود می کند) و عوامل کاهش دهنده (به عنوان مثال، الگوریتم های مورد نظر که به خوبی درک شده و در جاوا موجود هستند)، توضیح داده شود. حتی در سیال ترین شرایط نیز، باید تعداد نمونه های اولیه در نظر گرفته شود و محدوده الکترونیک صنعتی نمونه اولیه باید تعیین شود.

دانلود جزوه الکترونیک صنعتی رایگان خلاصه کتاب پی دی اف pdf کامل

2-3-24 تجزیه مشکل
تجزیه مشکل، که گاهی اوقات پارتیشن بندی یا تفسیر مشکل نیز نامیده می شود، فعالیتی است که در هسته تجزیه و تحلیل جزوه الکترونیک صنعتی نرم افزار قرار دارد (فصل های 7 و 8). در حین فعالیت محدوده ، هیچ تلاشی برای تجزیه کامل مشکل انجام نمی شود. بلکه تجزیه در دو حوزه عمده اعمال می شود: (1) عملکرد و محتوایی (اطلاعات) که باید ارائه شود و (2) فرایندی که برای ارائه آن مورد استفاده قرار می گیرد. این کار را می توان با استفاده از لیستی از عملکردها یا موارد کاربری یا در مورد کارهای چابک، با ایجاد داستان های کاربر، انجام داد. انسان ها وقتی با مشکل پیچیده ای روبرو می شوند، استراتژی “تقسیم کنید و پیروز شوید” را به کار می گیرند. به بیان ساده، یک مشکل پیچیده به مشکلات کوچکتر تقسیم می شود که بیشتر قابل مدیریت هستند. این استراتژی با شروع برنامه ریزی پروژه اعمال می شود. عملکردهای نرم افزاری، که در بیانیه محدوده شرح داده شده است، ارزیابی و اصلاح می شوند تا قبل از شروع برآورد، جزئیات بیشتری ارائه دهند (فصل 25). از آنجا که هم برآورد هزینه و هم برنامه زمانبندی، عملکردی هستند، درجاتی از تجزیه اغلب مفید خواهد بود. به طور مشابه ، اشیاء اصلی محتوا یا داده ها به اجزای تشکیل دهنده خود الکترونیک صنعتی می شوند و مفهومی منطقی از اطلاعات تولید شده توسط نرم افزار را ارائه می دهند.
4-24 فرآیند
فعالیت های چارچوبی (فصل 1) مشخص کننده فرآیند نرم افزار، برای همه پروژه های نرم افزاری قابل اجرا می باشد. مشکل، انتخاب مدل فرایندی مناسب برای نرم افزار طراحی شده توسط تیم پروژه است. مدل فرآیند توصیه شده در فصل 4 می تواند نقطه شروع خوبی برای بسیاری از تیم های پروژه باشد. تیم شما باید در مورد مدل فرایند مناسب برای هر یک از موارد زیر، تصمیم بگیرد: (1) مشتریانی که محصول را درخواست کرده اند و افرادی که کار را انجام می دهند، (2) ویژگی های خود محصول و (3) محیط کار تیم نرم افزاری. پس از انتخاب یک مدل فرآیند، تیم برنامه اولیه الکترونیک صنعتی را بر اساس مجموعه فعالیت های چارچوب فرایند تعریف می کند. هنگامی که برنامه اولیه ایجاد شد، فرآیند تجزیه و تحلیل آغاز می شود. یعنی باید یک برنامه کامل و منعکس کننده وظایف کاری مورد نیاز جزوه الکترونیک صنعتی پر کردن فعالیت های چارچوب، ایجاد شود. این فعالیت ها به طور مختصر در بخش های بعدی مورد بررسی قرار می گیرند و در فصل 25، نمای دقیق تری از آن ها ارائه می شود.

1-4-24 ترکیب محصول و فرآیند
برنامه ریزی پروژه با ترکیب محصول و فرآیند آغاز می شود. هر عملکردی که توسط تیم شما مهندسی می شود، باید از مجموعه فعالیت های چارچوبی تعریف شده برای سازمان نرم افزاری‌تان، عبور کند. چارچوب فرآیند ، اسکلتی برای برنامه ریزی پروژه ایجاد می کند؛ و با تخصیص مجموعه ای از وظایف که مناسب پروژه است، اقتباس می شود. فرض کنید که سازمان فعالیت های چارچوب عمومی، ارتباط، برنامه ریزی، مدل سازی، ساخت و استقرار را که در فصل 1 مورد بحث قرار گرفته است، اتخاذ کند. اعضای تیمی که روی عملکرد محصول کار می کنند، هر یک از فعالیت های چارچوب را در مورد آن اعمال می کنند. در اصل، ماتریسی مشابه آنچه در شکل 24.1 نشان داده شده است، ایجاد می شود.
تصویر 1-24
هر یک از عملکردهای اصلی محصول (شکل عملکرد نرم افزار برنامه تناسب اندام که در فصل 2 مورد بحث قرار گرفته است)، یا داستان کاربر در ستون سمت چپ فهرست شده است. فعالیت های چارچوبی در ردیف بالا ذکر شده‌اند. وظایف مهندسی نرم افزار (برای هر فعالیت چارچوبی) در ردیف بعدب وارد می شود. وظیفه مدیر پروژه (و سایر اعضای تیم) برآورد منابع مورد نیاز برای هر سلول ماتریسی، و شروع و پایان تاریخ وظایف مربوط به هر سلول و محصولات کاری است که در نتیجه هر کار تولید می شود.این فعالیت ها در فصل 25 مطرح شده‌اند.

2-4-24 تجزیه فرآیند
یک تیم نرم افزاری باید از انعطاف پذیری قابل توجهی در انتخاب بهترین مدل فرآیند نرم افزاری الکترونیک صنعتی پروژه و اقدامات مهندسی نرم افزار، برخوردار باشد. یک پروژه نسبتاً کوچک که مشابه تلاش های گذشته است می تواند با استفاده از یک رویکرد اسپرینت واحد، به بهترین نحو انجام شود. در شرایطی که مهلت به قدری کم است که نمی توان عملکرد کاملی را به طور منطقی ارائه داد، یک استراتژی افزایشی می تواند بهترین انتخاب باشد. به طور مشابه، پروژه هایی با ویژگی های دیگر (به عنوان مثال، الزامات نامشخص، فناوری پیشرفته، مشتریان سخت گیر یا احتمال استفاده مجدد از اجزای مهم)، منجر به انتخاب سایر مدل های جزوه الکترونیک صنعتی می شوند. پس از انتخاب مدل فرایند، چارچوب فرآیند با آن سازگار می شود. در تمام موارد، می توان از چارچوب فرآیند عمومی که قبلاً مورد بحث قرار گرفت، استفاده کرد.این چارچوب، برای مدل های خطی، برای مدل های تکراری و افزایشی، مدل های تکاملی و حتی برای مدل های مونتاژ همزمان یا اجزا نیز کار می کند. چارچوب فرآیند، تغییر ناپذیر است و به عنوان پایه ای برای تمام کارهای انجام شده توسط یک سازمان نرم افزاری عمل می کند. اما وظایف و اقدامات واقعی متفاوتند. تجزیه فرآیند، زمانی آغاز می شود که مدیر پروژه می پرسد، “چگونه این فعالیت چارچوبی را انجام دهیم؟” به عنوان مثال ، یک پروژه کوچک و نسبتاً ساده ممکن است برای فعالیتهای ارتباطی به کارهای زیر نیاز داشته باشد:
1. تهیه لیستی از مسائل شفاف سازی.
2. ملاقات با سهامداران برای رسیدگی به مسائل شفاف سازی.
3. تهیه بیانیه ای از محدوده با ذکر داستان های کاربر به طور مشترک.
4. بررسی بیانیه محدوده با همه نگرانی های پیرامون آن و تعیین اهمیت داستان هر کاربر برای سهامداران.
5. اصلاح بیانیه الکترونیک صنعتی در صورت لزوم.
این رویدادها ممکن است در مدت زمان کمتر از 48 ساعت رخ دهند و تجزیه فرایندی را نشان می دهند که برای پروژه کوچک و نسبتاً ساده مناسب است. اکنون، یک پروژه پیچیده تر را در نظر بگیرید، که دارای محدوده وسیع تر و تأثیر تجاری قابل توجه تری است. چنین پروژه ای ممکن است به وظایف زیر برای ارتباط نیاز داشته باشد:
1. بررسی درخواست مشتری.
2. طراحی و برنامه ریزی یک جلسه رسمی و تسهیل شده با همه سهامداران.
3. انجام تحقیقات برای مشخص کردن راه حل پیشنهادی و رویکردهای موجود.
4. تهیه “سند کار” و دستور کار جلسه رسمی.
5. برگزاری جلسه.

دانلود رایگان خلاصه کتاب الکترونیک صنعتی PDF

6. توسعه ریز مشخصات منعکس کننده داده ها، جزوه الکترونیک صنعتی و ویژگی های رفتاری نرم افزار به طور مشترک.این کار اغلب با توسعه موارد کاربری که نرم افزار را از دید کاربر توصیف می کند، انجام می شود.
7. هر ریز مشخصه یا مورد کاربری را از نظر صحت، سازگاری و عدم ابهام، بررسی کنید.
8. ریز مشخصات را در یک سند محدوده جمع آوری کنید.
9. مجموعه موارد کاربری را با همه نگرانی های مربوط به آن بررسی کنید و اهمیت نسبی آن ها را برای همه سهامداران تعیین کنید.
10. در صورت لزوم، سند محدوده یا موارد کاربری را تغییر دهید. هر دو پروژه، فعالیت چارچوبی را انجام می دهند که ما آن را ارتباط می نامیم، اما تیم پروژه اول، نصف کارهای مهندسی نرم افزار را به اندازه دومی انجام می دهد.

5-24 پروژه
برای مدیریت یک پروژه نرم افزاری موفق، باید اشتباهات احتمالی درک کنید تا بتوان از مشکلات جلوگیری کرد. جان ریل در مقاله ای عالی در مورد پروژه های نرم افزاری، نشانه هایی از تحت خطر بودن پروژه سیستم های را ارائه می دهد. در برخی موارد، کارکنان نرم افزار، نیازهای الکترونیک صنعتی خود را درک نمی کنند. این امر، منجر به پروژه ای با محدوده نامشخص می شود. در برخی پروژه ها نیز، مدیریت تغییرات ضعیف است. گاهی اوقات فناوری انتخاب شده تغییر می کند یا کسب و کار، نیاز به تغییر دارد و حمایت مدیریت از بین می رود. مدیریت می تواند مهلت های غیر واقعی تعیین کند؛ همچنین ممکن است کاربران نهایی در برابر سیستم جدید مقاوم باشند. مواردی وجود دارد که در آن، تیم پروژه، به هیچ وجه مهارت های لازم را ندارد. و سرانجام، توسعه دهندگانی وجود دارند که ظاهراً هرگز از اشتباهات خود درس می گیرند. متخصصان صنعت Jaded، هنگام بحث خصوصاً در مورد پروژه های سخت افزاری، اغلب به “قانون 90-90” اشاره می کنند: 90 درصد اول یک سیستم، 90 درصد تلاش و زمان اختصاص داده شده را جذب می کند. 10 درصد آخر، 90 درصد دیگر از تلاش و زمان اختصاص داده شده را می گیرد. دانه هایی که منجر به قانون 90-90 می شوند، در علائم ذکر شده در پاراگراف قبل موجود است. اما به اندازه نکات منفی بس است! پروژه های نرم افزاری موفق چه ویژگی هایی دارند؟ قاضی و همکارانش به چندین ویژگی در پروژه های نرم افزاری موفق و جزوه الکترونیک صنعتی در اکثر مدل های فرایند طراحی شده، اشاره می کنند.
1. الزامات واضح و کاملاً درک شده و پذیرفته شده توسط همه سهامداران.
2. مشارکت فعال و مستمر الکترونیک صنعتی در طول فرآیند توسعه.
3. مدیر پروژه با مهارت های رهبری مورد نیاز که قادر است دیدگاه پروژه را با تیم به اشتراک بگذارد.
4. طرح و برنامه پروژه ای که با مشارکت سهامداران برای دستیابی به اهداف کاربر تهیه شده است.
5. اعضای تیم ماهر و مشغول به کار.
7. برنامه زمانبندی واقعی و برآورد بودجه که تحت نظارت و نگهداری قرار می گیرد.
8. نیازهای قابل درک و برآورده شده مشتری.
9. رضایت شغلی بالای اعضای تیم.

6-24 اصل W5HH
بری بوهم در مقاله ای عالی در مورد فرآیند و پروژه های نرم افزاری می گوید: “[شما] به یک اصل جزوه بانکداری الکترونیک نیاز دارید که برای ارائه برنامه های ساده [پروژه] برای پروژه های ساده مقیاس پذیر باشد.” بوهم رویکردی را پیشنهاد می کند که اهداف پروژه، نقاط عطف و برنامه ها، مسئولیت ها، رویکردهای مدیریتی و فنی و منابع مورد نیاز را مورد بررسی قرار می دهد. او آن را اصل W5 HH می نامد. مجموعه سؤالات زیر، منجر به تعریف ویژگی های کلیدی پروژه و طرح پروژه حاصل می شود:
چرا سیستم در حال توسعه است؟ همه سهامداران باید اعتبار دلایل تجاری کار نرم افزاری را ارزیابی کنند. آیا هدف تجاری هزینه افراد، زمان و پول را توجیه می کند؟
چه کاری انجام خواهد شد؟ تعریف مجموعه وظایف مورد نیاز پروژه.
این کار، چه زمانی انجام می شود؟ تیم با مشخص کردن زمان انجام وظایف پروژه و رسیدن به مراحل مهم، برنامه پروژه را تعیین می کند.
چه کسی مسئول یک عملکرد است؟ نقش و مسئولیت هر یک از اعضای تیم نرم افزار تعریف شده است.
این امور، از نظر سازمانی در کجا قرار دارند؟ همه جزوه الکترونیک صنعتی و الکترونیک صنعتی ها در دست متخصصان نرم افزار نیست. مشتری، کاربران و سایر سهامداران نیز مسئولیت دارند.
چگونه کار از نظر فنی و مدیریتی انجام می شود؟ پس از تعیین محدوده محصول، باید یک استراتژی مدیریتی و فنی برای پروژه تعریف شود.
چه مقدار از هر منبع مورد نیاز است؟ پاسخ این سؤال، با برآورد (فصل 25) پاسخ سؤال قبلی بدست می آید.
اصل W5 HH بوهم، صرف نظر از اندازه یا پیچیدگی یک پروژه نرم افزاری، قابل اجرا است. سوالات ذکر شده، یک طرح کلی عالی برای شما و تیم شما ارائه می دهد.

7-24 رویکردهای اساسی
شورای ایرلی لیستی از “شیوه های نرم افزاری مهم برای مدیریت مبتنی بر عملکرد” تهیه کرده است. این شیوه ها “به طور مداوم توسط پروژه های نرم افزاری و سازمان های بسیار موفق مورد استفاده قرار می گیرند و مهم تلقی می شوند؛ و عملکرد نهایی آن ها به طور مداوم بسیار بهتر از میانگین صنعت است”. این شیوه ها هنوز برای مدیریت مدرن پروژه های نرم افزاری کاربرد دارند. اقدامات مهم عبارتند از: مدیریت پروژه مبتنی بر واحدها (فصل 23)، برآورد هزینه و برنامه زمانبندی تجربی (فصل 25)، ردیابی ارزش کسب شده (فصل 25)، ردیابی نقص در برابر اهداف کیفیت (فصل ) (). -() “” ‌