فرآیند توسعه سیستم عامل ما بر اساس یک رویکرد پنج مرحله ای است

در طول چند سال گذشته، ما مشاوره‌ها و آموزش‌های گسترده‌ای را با تیم‌های توسعه نرم‌افزار انجام داده‌ایم، در حالی که سیستم‌افزاری را برای محصولات و خانواده‌های محصولات موفق و بادوام توسعه می‌دهیم. در حالی که ایجاد معماری سفت‌افزار قوی و معماری مجدد نرم‌افزار قدیمی می‌تواند فرآیندی پیچیده و چند ماهه باشد، ما پنج مرحله کلیدی را شناسایی کرده‌ایم که یک رویکرد گام به گام را تشکیل می‌دهند و تیم ما را قادر می‌سازد در مسیر درست شروع کنند.

مرحله 1: الزامات را تعریف کنید

قبل از طراحی یک سیستم جاسازی شده یا سیستم عامل آن، الزامات روشن ضروری است. الزامات کاملاً تعریف شده مشخص می کند که محصول چه کاری را برای کاربر انجام خواهد داد بدون اینکه جزئیاتی در مورد چگونگی دستیابی به این اهداف ارائه شود. ضروری است که هر عبارت الزامی بدون ابهام و قابل آزمایش باشد. بیانیه بدون ابهام واضح و مختصر است و نیازی به توضیح بیشتر ندارد.

آزمایش پذیری یک عامل کلیدی است. یک الزام خوب نوشته شده باید امکان ایجاد آزمون ساده را برای تأیید تحقق آن فراهم کند. مجموعه مناسبی از الزامات شامل عباراتی است که با «[محصول] باید...» شروع می‌شود، به جای اینکه چگونه به آن دست می‌یابد، بر آنچه مورد نیاز است تمرکز می‌کند و وضوح و آزمایش‌پذیری را تضمین می‌کند. در نتیجه، معماری مؤثر بر الزامات کاملاً تعریف شده متکی است.

مرحله 2: تفاوت بین معماری و طراحی

تجربه ما این بوده است که بسیاری از مهندسان و مدیران آنها در تمایز بین جنبه های مختلف مهندسی سیستم عامل مشکل دارند. معماری سیستم نشان‌دهنده بالاترین سطح HOW است که ویژگی‌های پایدار محصول را تعریف می‌کند و تغییر آن را پس از ایجاد چالش برانگیز می‌کند. این نیاز به بررسی دقیق در مورد استفاده های مورد نظر و مجاز محصول برای اطمینان از انجام صحیح آن دارد.

طراحی یک سیستم نشان دهنده لایه میانی چگونه است. در حالی که معماری ویژگی های گسترده را مشخص می کند، نام تابع یا متغیر را مشخص نمی کند. یک سند طراحی سفت‌افزار این جزئیات را پر می‌کند، از جمله نام وظایف و مسئولیت‌ها در زیرسیستم‌های خاص یا درایورهای دستگاه، RTOS مورد استفاده (در صورت وجود)، و مشخصات رابط‌های بین زیرسیستم‌ها.

مرحله اجرا نشان دهنده پایین ترین سطح سلسله مراتب مدیریت پروژه است. هنگامی که رابط ها در مرحله طراحی به وضوح تعریف می شوند، مهندسان می توانند به طور موازی اجزای مختلف را پیاده سازی کنند. در حالی که چالش ها ممکن است بسته به صنعت متفاوت باشد، آنها معمولاً به سه دسته اصلی تقسیم می شوند: رعایت مهلت های زمانی واقعی، آزمایش، و مدیریت تنوع. این مسائل در سه مرحله پایانی بررسی می شوند.

مرحله 3: مدیریت زمان

برخی از الزامات محصول محدودیت های زمانی صریح را مشخص می کنند. به طور معمول، محصولات شامل ترکیبی از الزامات غیر واقعی، زمان واقعی، و زمان واقعی سخت است. از این میان، ضرب‌الاجل‌های نرم اغلب چالش‌برانگیزترین برای تعریف، آزمایش و اجرا هستند. هنگامی که ضرب الاجل مشخص شد، گام اولیه در فرآیند معماری، تخلیه هر چه بیشتر نیازمندی های حساس به زمان از نرم افزار به سخت افزار است.

جداسازی عملکرد بلادرنگ از نرم افزار اصلی دو مزیت کلیدی را به همراه دارد. در مرحله اول، طراحی و اجرای نرم افزار غیر واقعی را ساده می کند. با حذف محدودیت‌های زمانی از بخش عمده کد، حتی توسعه‌دهندگان مبتدی نیز می‌توانند بدون به خطر انداختن ایمنی کاربر مشارکت کنند. ثانیاً، ادغام عملکرد بلادرنگ تجزیه و تحلیل و اطمینان از رعایت مداوم تمام مهلت‌ها را آسان‌تر می‌کند.

مرحله 4: طراحی با آزمایش در ذهن

آزمایش هر سیستم تعبیه شده در سطوح مختلف ضروری است. در بسیاری از موارد، آزمایش در سطوح مختلف نه تنها ارزشمند بلکه اجباری است.

رایج ترین سطوح آزمایش عبارتند از

1. آزمایش‌های سیستم تأیید کرده‌اند که محصول به‌عنوان یک کل الزامات مشخص‌شده را برآورده می‌کند یا از آن فراتر می‌رود. توصیه می‌شود که این آزمایش‌ها در خارج از بخش مهندسی توسعه داده شوند، اگرچه می‌توان آن‌ها را در یک مهار تست طراحی شده توسط مهندسان گنجاند.

2. تست های یکپارچه سازی برای اطمینان از اینکه زیرمجموعه های زیرسیستم ها، همانطور که در نمودارهای معماری مشخص شده است، به درستی تعامل دارند و نتایج مورد انتظار را به دست می آورند، انجام می شود. این تست‌ها معمولاً توسط یک تیم تست یا فردی در بخش مهندسی نرم‌افزار توسعه می‌یابند.

3. تست‌های واحد تضمین می‌کنند که اجزای نرم‌افزار جداگانه، همانطور که در مرحله طراحی میانی تعریف شده‌اند، همانطور که در نظر گرفته شده‌اند، عمل می‌کنند. این تست‌ها بر روی API عمومی (Application Programming Interface) متمرکز می‌شوند که کامپوننت به اجزای دیگر ارائه می‌دهد. به طور معمول، تست های واحد توسط همان افرادی که کد مورد آزمایش را می نویسند، ایجاد می شود.

از بین سه نوع تست، تست‌های سیستمی ساده‌ترین آنها هستند. ممکن است برای تست‌های مهندسی و پذیرش کارخانه به یک مهار تست نیاز باشد، اما این فرآیند به طور کلی ساده‌تر از تست‌های یکپارچه‌سازی و واحد است، که نیاز به دید داخلی بیشتری در عملکرد دستگاه دارد. برای ساده‌سازی توسعه، استفاده و نگهداری تست‌های یکپارچه‌سازی و واحد، توصیه می‌شود سفت‌افزار را به‌گونه‌ای طراحی کنید که با چارچوب تست نرم‌افزار هماهنگ باشد. موثرترین رویکرد این است که تعاملات بین تمام اجزای نرم افزار را در سطوحی که می خواهید آزمایش کنید، ساختار دهید.

مرحله 5: برای تغییر آماده شوید

در مرحله معماری سیستم عامل، اولویت بندی مدیریت تنوع ویژگی ها و سفارشی سازی محصول ضروری است. برای برنامه ریزی موثر برای تغییر، ابتدا باید انواع تغییراتی را که احتمالاً در محصول شما رخ می دهد، شناسایی کنید. سپس، سفت‌افزار باید به گونه‌ای طراحی شود که این تغییرات را به کارآمدترین شکل ممکن تطبیق دهد. یک معماری خوب طراحی شده امکان مدیریت تنوع ویژگی ها را از طریق یک ساخت واحد با سوئیچ های زمان کامپایل و/یا زمان اجرا فراهم می کند، در حالی که امکان افزودن یکپارچه ویژگی های جدید را بدون ایجاد اختلال در عملکرد موجود فراهم می کند.