در چرخه توسعه نرم افزار، پس از تحلیل نیازمندی ها و تدوین مستندات مربوط به آن مانند SRS، نوبت به مرحله طراحی می رسد. طراحی نرم افزار مرحله ای است که در آن ساختار سیستم، معماری ماژول ها، پایگاه داده ها و نحوه تعامل اجزای مختلف مشخص می شود. خروجی این مرحله سندی به نام Software Design Document (SDD) است.SDD در واقع نقشه فنی پروژه محسوب می شود و مرجعی رسمی برای توسعه دهندگان، تست کنندگان و حتی تیم های نگهداری نرم افزار است. بدون وجود این سند، توسعه پروژه می تواند دچار آشفتگی و ناسازگاری شود زیرا هر بخش از تیم ممکن است برداشت متفاوتی از طراحی داشته باشد.
نکته مهم:
مخاطب عزیز، اگر فرهنگ استفاده از مستندات فنی و بیزینسی محصول در آن تیم یا شرکت وجود ندارد یا تا کنون نیازی به این مستندات نبوده است، قبل از شروع تهیه این سند، ابتدا قوانین داخلی آن تیم یا شرکت را تنظیم کنید و شرایط را برای استفاد صحیح و بروزرسانی این مستندات مهیا کنید.در هر شرکت یا تیمی باید حداقل یک شخص مسئول جمع آوری و نگهداری و بروزرسانی این مستندات باشد.(تفکر سیستمی)
Software Design Document سندی است که طراحی سطح بالا (High Level Design) و طراحی سطح پایین (Low Level Design) نرم افزار را به طور کامل توضیح می دهد.
این سند معمولا شامل موارد زیر است:
معماری کلی سیستم و اجزای اصلی آن
توضیح ماژول ها و مسئولیت هر ماژول
نمودارهای معماری و جریان داده ها
طراحی پایگاه داده شامل جداول و ارتباطات آن ها
واسط های کاربری و طراحی کلی رابط ها
واسط های برنامه نویسی (API) و نحوه تعامل اجزا
محدودیت های طراحی و فناوری های انتخاب شده
1. فراهم کردن مرجع واحد برای تیم توسعه
2. کاهش خطاها و دوباره کاری در زمان پیاده سازی
3. کمک به تست کنندگان برای درک معماری سیستم
4. کمک به تیم نگهداری و پشتیبانی در آینده
5. ایجاد شفافیت در مورد فناوری ها و ابزارهای مورد استفاده
1. مقدمه (Introduction)
در این بخش هدف سند طراحی، محدوده سیستم و تعاریف اصلی ذکر می شود. همچنین ارتباط سند با سایر مستندات مانند SRS مشخص می گردد.
2. معماری کلی سیستم (System Architecture)
اینجا نمای سطح بالای سیستم شرح داده می شود. معماری ممکن است لایه ای (Layered)، سرویس گرا (SOA)، میکروسرویس یا ترکیبی باشد. معمولا با نمودار معماری کلان، اجزای اصلی و روابط بین آن ها نمایش داده می شود.
3. طراحی ماژول ها (Module Design)
هر ماژول نرم افزار معرفی شده و وظایف آن به طور دقیق شرح داده می شود. برای هر ماژول ورودی ها، خروجی ها و وابستگی ها تعریف می گردد.
4. طراحی دیتابیس / پایگاه داده (Database Design)
مدل دیتاها شامل ERD (Entity Relationship Diagram)، جداول، کلیدهای اصلی و خارجی و روابط بین جداول مشخص می شود. این بخش تضمین می کند که ساختار دیتا ها با نیازمندی های نرم افزار همخوانی داشته باشد.
5. طراحی رابط کاربری (User Interface Design)
در این بخش نمای کلی صفحات، فلوهای اصلی کاربر و قوانین مربوط به رابط کاربری توضیح داده می شود. گاهی نمونه های اولیه (Wireframe) یا ماکاپ ها نیز ضمیمه می شوند.
6. طراحی واسط ها (Interfaces)
اگر نرم افزار با سیستم های دیگر یا سرویس های خارجی تعامل دارد، این بخش نحوه ارتباط، پروتکل ها، API ها و فرمت داده های تبادلی را توضیح می دهد.
7. محدودیت ها و تصمیمات طراحی (Design Constraints)
فناوری های انتخاب شده، محدودیت های سخت افزاری یا نرم افزاری، استانداردهای مورد استفاده و هرگونه فرضیات مهم در این بخش آورده می شود.
در چرخه توسعه نرم افزار یک جایگاه مشخص دارد و معمولا بعد از تحلیل نیازمندی ها و مستندات مربوط به آن تهیه میشود، ترتیب قرار گیری جایگاه این سند (زمان فرارسیدن تهیه سند) به صورت زیر است:
BRD → PRD → SRS → FRD → SDD
Software Design Document (SDD)
Project: Online Library Management System
Version: 1.0
Authors: Development Department, Product Team,
Date: [2025/09/23]
1. مقدمه (Introduction)
1.1 هدف
این سند طراحی نرم افزار معماری و طراحی سیستم مدیریت کتابخانه آنلاین را توضیح می دهد.
هدف اصلی این سند ارائه نقشه فنی سیستم برای تیم توسعه و تست است تا اطمینان حاصل شود همه اعضا دیدگاه یکسانی نسبت به ساختار نرم افزار دارند.
1.2 محدوده سیستم
سیستم مدیریت کتابخانه آنلاین امکان ثبت نام کاربران، جستجوی کتاب ها، امانت گرفتن و برگرداندن کتاب ها، مدیریت موجودی کتاب و مدیریت کاربران توسط کتابدار را فراهم می کند.
1.3 تعاریف
کاربر: عضو ثبت نام شده کتابخانه
کتابدار: مدیر سیستم و مسئول مدیریت منابع کتابخانه
امانت: فرآیند ثبت شده برای قرض گرفتن کتاب توسط کاربر
2. معماری کلی سیستم (System Architecture)
2.1 نمای سطح بالا
سیستم از سه لایه تشکیل شده است:
Presentation Layer: رابط کاربری وب و موبایل
Business Logic Layer: منطق اصلی شامل مدیریت کاربران، مدیریت کتاب ها و فرآیند امانت
Data Layer: دیتابیس SQL برای ذخیره اطلاعات
2.2 نمودار معماری (High Level Architecture)
(اینجا یک فلو فنی جامع از معماری /منطق سیستم کشیده می شود. توضیح متنی:)
کاربر از طریق مرورگر یا اپلیکیشن موبایل وارد سیستم می شود، درخواست به سرور ارسال می شود، منطق کسب و کار پردازش می شود و داده ها از دیتابیس واکشی یا ذخیره می شوند.
3. طراحی ماژول ها (Module Design)
3.1 ماژول ثبت نام و ورود کاربر
ورودی: نام کاربری، رمز عبور، ایمیل
خروجی: تایید هویت موفق یا خطا
وابستگی: دیتابیس کاربران
3.2 ماژول جستجوی کتاب
ورودی: عنوان، نویسنده یا ISBN
خروجی: لیست کتاب های یافت شده
وابستگی: دیتابیس کتاب ها
3.3 ماژول امانت کتاب
ورودی: شناسه کاربر، شناسه کتاب
خروجی: تایید امانت یا پیام خطا (مثلا کتاب موجود نیست)
وابستگی: دیتابیس امانت و کتاب ها
3.4 ماژول مدیریت کتابدار
افزودن، ویرایش و حذف کتاب ها
مدیریت کاربران و مشاهده وضعیت امانت ها
4. طراحی دیتابیس (Database Design)
4.1 جداول اصلی
Users
UserID (PK)
Username
Password
Role (User / Librarian)
Books
BookID (PK)
Title
Author
ISBN
AvailableCopies
Loans
LoanID (PK)
UserID (FK)
BookID (FK)
LoanDate
ReturnDate
4.2 ارتباط ها
هر کاربر می تواند چندین کتاب امانت بگیرد (ارتباط یک به چند بین Users و Loans).
هر کتاب می تواند چندین بار امانت داده شود (ارتباط یک به چند بین Books و Loans).
5. طراحی رابط کاربری (User Interface Design)
صفحه ورود: فرم ورود با نام کاربری و رمز عبور
داشبورد کاربر: نمایش لیست کتاب های امانتی و امکان جستجو
صفحه جستجو: فیلدهای جستجو و نتایج کتاب ها
پنل کتابدار: مدیریت کتاب ها و کاربران
6. طراحی واسط ها (Interfaces)
6.1 API ها
POST /login → تایید هویت کاربر
GET /books?query=... → جستجوی کتاب ها
POST /loan → ثبت امانت کتاب
POST /return → بازگرداندن کتاب
6.2 فرمت دیتاها
API ها از JSON برای تبادل دیتا استفاده می کنند.
7. محدودیت ها و تصمیمات طراحی (Design Constraints)
دیتابیس باید PostgreSQL باشد.
زبان برنامه نویسی سمت سرور: Java Spring Boot
رابط کاربری: ReactJS
اپلیکیشن موبایل: React Native
سیستم باید قابلیت پشتیبانی حداقل ۵۰۰۰ کاربر همزمان را داشته باشد.
/پایان سند/
استفاده از سند طراحی نرم افزار (SDD) تا حد زیادی به اندازه تیم، پیچیدگی پروژه و ساختار سازمان بستگی دارد.
تیم های کوچک یا استارت اپ ها
در تیم های کوچک که معمولاً کمتر از ۱۰ نفر هستند و سرعت اجرای ایده اهمیت بیشتری از مستندسازی دارد، ممکن است نیاز به SDD کامل و رسمی نباشد. در چنین شرایطی گاهی مستندات سبک تر یا حتی نمودارهای ساده کافی است. با این حال، اگر محصول قرار است در آینده گسترش یابد یا سرمایه گذاران و ذی نفعان خارجی درگیر باشند، وجود یک SDD حتی در مقیاس کوچک بسیار ارزشمند خواهد بود.(شرکت های خارجی یا داخلی سرمایه گذار به این سند نیاز دارند)
شرکت های متوسط
در سازمان هایی با تیم های توسعه بزرگ تر (۲۰ تا ۵۰ نفر یا بیشتر)، هماهنگی بین افراد بدون وجود مستند طراحی دشوار می شود. در این سطح، SDD تبدیل به ابزاری ضروری برای مدیریت پیچیدگی و کاهش خطا می شود. زیرا چندین تیم ممکن است به صورت همزمان روی ماژول های مختلف کار کنند و باید مرجع مشترکی برای معماری و طراحی وجود داشته باشد.
شرکت های بزرگ و سازمان های سازمانی (Enterprise)
در شرکت های بزرگ که تیم های صدنفره یا بیشتر دارند، مستندسازی کامل از جمله SDD امری اجتناب ناپذیر است. این شرکت ها معمولاً استانداردهای سخت گیرانه برای کیفیت و امنیت دارند و هر تغییری در سیستم نیازمند مستند رسمی است. علاوه بر این، طول عمر پروژه ها در چنین سازمان هایی طولانی است و تیم های مختلف در بازه های زمانی مختلف روی سیستم کار می کنند. بنابراین SDD به عنوان یک مرجع تاریخی و فنی ضروری است.
پروژه های کوتاه مدت و آزمایشی (Prototype / MVP)
در پروژه های آزمایشی که هدف تنها اثبات ایده یا ساخت نمونه اولیه است، معمولاً نیازی به تهیه SDD کامل وجود ندارد. در این موارد مستندات سبک تر و انعطاف پذیرتر کفایت می کند. اما اگر همین پروژه به فاز تولید برسد، تدوین یک SDD جامع ضرورت پیدا خواهد کرد.
جمع بندی
SDD یا Software Design Document یکی از مهم ترین مستندات فنی در چرخه توسعه نرم افزار است. این سند با ارائه توضیح جامع از معماری، ماژول ها، پایگاه داده و رابط ها، مسیر توسعه را شفاف می کند. وجود یک SDD جامع باعث کاهش خطا، صرفه جویی در هزینه و زمان، و در نهایت افزایش کیفیت محصول می شود.البته در ایران این سند در بعضی شرکت ها بصورت نمادین در ویترین شرکت ها وجود دارد و فقط کمک به زیباسازی نمای اتاق مدیران میکند. :)
