اصول مهندسی نرم افزار – Software Development Life Cycle (SDLC) طراحی و معماری

رودمپ و چک‌لیست مراحل قبل از کدنویسی (Pre-development Phase)

مرحله ۰: ایده‌پردازی و کشف نیازها (Ideation & Discovery)

تعریف مسئله (Problem Definition) – دقیقاً چه مشکلی را حل می‌کند؟
شخصیت‌های کاربر (User Personas) – چه کسانی از نرم‌افزار استفاده می‌کنند؟
تحلیل رقبا (Competitor Analysis) – مشابه‌های موجود چه نقاط ضعف و قوتی دارند؟
MVP (Minimum Viable Product) – حداقل قابلیت‌هایی که باید در نسخه اول باشد.

مرحله ۱: جمع‌آوری و تحلیل نیازمندی‌ها (Requirement Gathering & Analysis)

نیازمندی‌های وظیفه‌ای (Functional Requirements) – سیستم چه کارهایی باید انجام دهد؟.
نیازمندی‌های غیروظیفه‌ای (Non-functional Requirements) – عملکرد، امنیت، مقیاس‌پذیری، سازگاری با مرورگرها.
سناریوهای کاربر (User Stories / Use Cases) – مثال: «به عنوان کاربر، می‌توانم وارد شوم».
قوانین کسب‌وکار (Business Rules)
برآورد اولیه هزینه و زمان – با تکنیک مشابه‌یابی (Analogy Estimation).
تحلیل ریسک – فهرست ریسک‌های فنی، انسانی، سخت‌افزاری

مرحله ۲: طراحی معماری و جریان داده (System Architecture & Data Flow)

نمودار بافت (Context Diagram) – سیستم شما با چه سیستم‌های خارجی ارتباط دارد؟
نمودار جریان داده (Data Flow Diagram – DFD) – سطح ۰، سطح ۱.
فلوچارت فرآیندها (Process Flowchart) – برای هر قابلیت اصلی.
الگوریتم بخش‌های حیاتی (Algorithm Design) – مثلاً نحوه محاسبه قیمت یا تطابق الگوها.
تعریف محدوده هر ماژول (Module Scope) و وابستگی‌هایش
مودار توالی (Sequence Diagram)برای ۳ سناریوی بحرانی
نمودار ماشین حالت – برای موجودیت اصلی (مثلاً سفارش: ثبت → پرداخت → ارسال → تحویل)

مرحله ۳: طراحی منطق داده (Logical Data Modeling)

شناسایی موجودیت‌ها (Entities) – مانند User, Product, Order.
تعریف ویژگی‌ها (Attributes) و نوع داده (Data Types).
تعیین روابط (Relationships) – یک به یک، یک به چند، چند به چند.
شناسایی کلیدهای اصلی و خارجی (Primary Key, Foreign Key).
نرمال‌سازی (Normalization) تا فرم سوم (3NF) حداقل.
مفهوم Flag / Status – وضعیت رکورد (مثل is_active, status).
عیین استراتژی اعتبارسنجی (Validation Strategy) – سمت کلاینت، سرور، دیتابیس
پیش‌بازی مهاجرت دیتابیس (Migration Strategy) – وقتی فیلد جدید اضافه می‌شود

مرحله ۴: طراحی فیزیک دیتابیس (Physical Database Design)

زبان/سیستم دیتابیس – PostgreSQL، MySQL، MongoDB یا …؟
نمودار ER (Entity-Relationship Diagram) – رسم در ابزارهایی مثل Draw.io, dbdiagram.io
ایندکس‌گذاری (Indexing Strategy) برای جستجوی سریع.
طراحی قوانین اعتبارسنجی (Constraints) – NOT NULL, UNIQUE, CHECK.

مرحله ۵: طراحی رابط کاربری و تجربه کاربری (UI/UX Design)

وایرفریم (Wireframe) – ساختار ابتدایی صفحات بدون جزئیات بصری.
ماکاپ (Mockup) – طرح ثابت با رنگ، فونت و چیدمان واقعی (Figma, Adobe XD).
پروتوتایپ (Prototype) – نمونه کلیک‌شدنی و تعاملی (مثل Axure, Figma Prototype).
کاربرگه سبک (Style Guide) یا Design System – رنگ‌ها، تایپوگرافی، فاصله‌ها.
نمودار جریان کاربر (User Flow Diagram) – مسیرهای حرکت کاربر در اپلیکیشن.
انتخاب معماری لایه‌های کد (Layered Architecture) – Presentation → Business → Persistence
اعمال اصول SOLID روی اجزا – مثلاً Dependency Inversion برای ارتباط با دیتابیس
شناسایی الگوهای طراحی مورد نیاز – (مثلاً Repository Pattern، DTO، Factory)

مرحله ۶: معماری فنی و تصمیمات پشته فناوری (Technical Architecture & Stack Decision)

معماری کلی (Architecture Pattern) – لایه‌لایه (Layered)، میکروسرویس (Microservices)، یا مونولیت (Monolith)؟
انتخاب فریم‌ورک بک‌اند – Django، Laravel، Spring Boot، Express.js، …
انتخاب فریم‌ورک فرانت‌اند – React، Vue، Angular یا SSR مثل Next.js.
انتخاب پایگاه داده (در مرحله ۴ کامل می‌شود)
کش (Caching Strategy) – Redis، Memcached.
صف پیام (Message Queue) – برای کارهای غیرهمزمان (RabbitMQ، Kafka در صورت نیاز).

مرحله ۷: مستندسازی و آماده‌سازی کدنویسی

مستندات API (اگر معماری جداست) – OpenAPI/Swagger.
تعریف قراردادهای کدنویسی (Coding Conventions) – لینتر، فرمتر.
تنظیم محیط توسعه (Dev Environment Setup) – Docker، دیتابیس لوکال.
تقسیم کار به تسک‌ها (Task Breakdown) – برای هر تسک یک کارت در GitHub Projects / Trello / Jira.
انتخاب کنترل نسخه (Version Control) – Git + GitHub/GitLab.
تعریف استراتژی تست – (Unit, Integration, E2E, Load)
نظیم CI/CD Pipeline – مثلاً GitHub Actions
مدیریت پیکربندی محیط‌ها – (development/staging/production)
برنامه بازیابی فاجعه (Disaster Recovery) – بکاپ، ریپلیکا
مستندات معمار (Architecture Decision Records – ADR) – برای تصمیمات کلیدی

چک‌لیست نهایی پیش از نوشتن اولین خط کد

مرحله	وضعیت	اصطلاح کلیدی
۰. تعریف MVP و Personas	⬜	Product Discovery
۱. نیازمندی‌های وظیفه‌ای و غیروظیفه‌ای	⬜	SRS (Software Requirements Spec)
۲. فلوچارت و DFD برای فرآیندها	⬜	Data Flow Diagram
۳. موجودیت‌ها، فیلدها، Flag و روابط	⬜	Logical Data Model
۴. نمودار ER و نرمال‌سازی	⬜	Physical Data Model
۵. وایرفریم + ماکاپ + پروتوتایپ	⬜	UI/UX Prototype
۶. انتخاب پشته فناوری و معماری	⬜	Tech Stack & Architecture
۷. مستندات + تسک‌ها + محیط توسعه	⬜	Ready to Code

نظم پیشنهادی (روش انجام)

مرحله ۰ و ۱ را با مداد (غیرقطعی) شروع کن.
مرحله ۲ (فلوچارت) را برای سناریوی خوش‌بینانه و بدبینانه رسم کن.
مرحله ۳ و ۴ (دیتابیس) را با توجه به فلوچارت‌ها انجام بده – اینجا متوجه می‌شوی که چه flag هایی لازم داری (مثل is_deleted, statu, is_verified).
مرحله ۵ (پروتوتایپ) – حتی با قلم و کاغذ. تأیید کاربر روی این مرحله خیلی مهم است.
مرحله ۶ (معماری فنی) – بعد از تأیید پروتوتایپ.
مرحله ۷ – فقط زمانی که بالای ۹۰ درصد موارد قبلی بسته شده باشد.

اگر تیم ندارید، برخی از این مراحل (مثل Style Guide یا Message Queue) را می‌توانید ساده یا حذف کنید، اما هرگز فلوچارت و دیتابیس‌لاگیک را حذف نکنید.

نکات تکمیلی

در مرحله ۲ تفاوت Data Flow Diagram با Process Flowchart در این است که، اولی برای ترسیم مسیر حرکت کلی کاربر در برنامه ایجاد شده است. و دومی برای ترسیم مسیر شرطی حرکت برنامه به ازای هر ویژگی یا فیچر یا قابلیت یا برای هر سناریوی کاربر (Use Case) یک فلوچارت یا الگوریتم داریم و بیشتر برای منطق (Logic) آن قابلیت در سیستم و کد می‌باشد.
در مرحله ۲ و ۵ تفاوت Data Flow Diagram با User Flow Diagram در این است که، اولی بصورت ذهنی و کلی است در حالیکه دومی در فیگما یا ابزارهای مشابه بصورت گرافیکی کاربر با کمک منو یا دکمه یا هر چیز دیگری این مسیر رو طی می‌کند
در مرحله ۵ می‌توان. به جای Style Guide یا Design System بصورت کلی از Design Kit استفاده کرد.
در مرحله ۳ منظور از تعریف Entities یعنی ساخت جداول پایگاه داده است. و منظور از Attributes همان ستون‌های جداول می‌باشد.
در مرحله ۶ و بخش بک‌اند باید به ازای هر Entity یا جدول پایگاه داده یک Model ایجاد کرد و سپس برای این Model یک Controller با حالت CRUD و سطح دسترسی ساخت.
در مرحله ۷ و مستندسازی بایستی ۳ نوع مستند ایجاد کرد. اولی داخل کدها مانند توضیح کوتاه یک API یا Function یا متد یا کلاس یا متغیر و یا غیره، دومی مستندات Web API یا HTTP API است و سومی یک مخزن مستندات در سایت شخصی یا گیت‌هاب می‌باشد.
Flag = فیلد بولی یا وضعیت گسسته که یک حالت خاص را نشان می‌دهد.
نرمال‌سازی یعنی حذف داده‌های تکراری. که شامل: فرم اول (1NF): هر سلول یک مقدار. | فرم دوم (2NF): وابستگی کامل به کلید اصلی. | فرم سوم (3NF): حذف وابستگی ترانزیتی.
اصل ایندکس‌گذاری باید روی فیلدهایی که در WHERE و JOIN زیاد می‌آیند تعریف شود.

سطح‌بندی پوزیشن‌های کاری نرم‌افزار

مهندسی نرم‌افزار: از نیازسنجی تا طراحی و نگهداری (حلقه توسعه)
معماری نرم‌افزار: اجرای مراحل کلی،شامل: الگوی معماری، ویژگیهای کاربردی، کاربردها، تعاملات، تکنولوژی‌ها و زبان‌ها
طراحی سیستم یا طراحی نرم‌افزار: اجرای مراحل جزئی‌تر طراحی، شامل: ui/ux، پایگاه داده، جزئیات کلاس‌ها، متدها و ویژگیها
معماری سیستم: همان طراحی سیستم ولی در قسمت سخت‌افزار و ارتباط و تعامل آن با نرم‌افزار
برنامه نویسی: پیاده‌سازی ویژگیها و تعاملات و جزئیاتی که در طراحی سیستم مشخص شده
کدنویسی: لول پایین‌تر برنامه‌نویس و فقط مسلط به یک زبان
مدیریت پروژه: مدیریت تمامی مراحل و نسخه‌بندی و بررسی ویژگیهای جدید

تفاوت «اصول مهندسی نرم‌افزار» و «اصول طراحی نرم‌افزار»

محور	مهندسی نرم‌افزار (Software Engineering)	طراحی نرم‌افزار (Software Design)
تمرکز اصلی	کل چرخه حیات (مدیریت، فرآیند، کیفیت، تیم، هزینه، زمان)	ساختار داخلی، اجزا و روابط آنها برای حل مسئله
خروجی اصلی	برنامه اجرایی + مستندات + پایپلاین + تست + نگهداری	دیاگرام کلاس‌ها، معماری ماژول‌ها، الگوهای طراحی (Design Patterns)
سؤال کلیدی	چگونه محصول را با زمان و هزینه مشخص و با کیفیت بالا تحویل دهیم؟	چگونه کد را انعطاف‌پذیر، قابل فهم و تغییرپذیر بنویسیم؟
نمونه اصول	اصول مدیریت پروژه (چابک/آبشاری)، تضمین کیفیت، کنترل نسخه، CI/CD	SOLID، DRY، KISS، YAGNI، Encapsulation، Coupling/Cohesion

نکته طلایی:
«اصول طراحی نرم‌افزار» یک زیرمجموعه از «اصول مهندسی نرم‌افزار» است. مهندسی سقف بزرگتری دارد.

اصول تولید محصول یا Production

نیازسنجی: زبان، تکنولوژی، دیتابیس، ویژگیها، تهیه پروپوزال
طراحی رابط‌کاربری: ui/ux، wireframe، kit، components
طراحی فرانت‌اند: کدنویسی، اصول BEM، انیمیشن، svg
طراحی بک‌اند: طراحی فلوچارت یا الگوریتم‌های تمامی ویژگیها، ساختارها، صفحات و بخش‌ها، طراحی دیتابیس و دیتاها، طراحی ساختار فایل‌های پروژه، انتخاب دیزاین پترن‌های مناسب، کدنویسی
ریفکتور: code review، بهینه‌سازی front و back و کدنویسی تمیز، بهینه‌سازی performance، تست کد و خطایابی، بررسی امنیت، مستندسازی، ورژ‌ن‌بندی اولیه
مراحل استقرار: نسخه‌بندی نهایی، بکاپ، داکر، ci/cd، نگهداری و توسعه

اصول SOLID

اصل	نام کامل	معنی ساده	مثال در سیستم ما
S	Single Responsibility	هر کلاس فقط یک دلیل برای تغییر داشته باشد	کلاس `TaskRepository` فقط وظیفه ارتباط با دیتابیس را دارد. کلاس `TaskValidator` فقط وظیفه اعتبارسنجی. تغییر فرمت دیتابیس نباید روی Validator تأثیر بگذارد.
O	Open/Closed	کلاس برای توسعه باز، برای تغییر بسته باشد	یک اینترفیس `Notifier` بساز. برای ایمیل یک کلاس، برای پیامک کلاس دیگر. بعداً اضافه کردن اعلان پوش نوتیفیکیشن بدون تغییر کد موجود.
L	Liskov Substitution	زیرکلاس بتواند جایگزین کلاس پدر شود	اگر کلاس `FileAttachment` از `Attachment` ارث‌برداری کند، باید بتواند هر جا `Attachment` استفاده شده، قرار بگیرد.
I	Interface Segregation	اینترفیس‌های اختصاصی بهتر از یک اینترفیس بزرگ	به جای `ITaskOperations` (شامل create, delete, assign, comment, attach)، اینترفیس‌های کوچک: `ICreatable`, `IDeletable`, `ICommentable` بساز.
D	Dependency Inversion	ماژول‌های سطح بالا به انتزاع وابسته باشند نه جزئیات	سرویس `TaskService` نباید مستقیماً از `PostgreSQLTaskRepository` استفاده کند. یک اینترفیس `ITaskRepository` بساز و به آن وابسته باش. بعداً می‌توانی به MongoDB هم براحتی تغییر دهی.

پترن اصلی سیستم (Architecture Pattern)

وقتی در مرحله ۵ چک‌لیست می‌گوییم «پترن را انتخاب کن»، منظور پترن معماری کلی (Architectural Pattern) است، نه الگوهای طراحی جزئی (Gang of Four patterns).

سطح	نام	مثال	تعداد در یک سیستم
معماری (Architectural)	معماری کل سیستم	Layered, MVC, Microservices, Hexagonal	معمولاً ۱ الی ۲ عدد
طراحی (Design)	الگوهای جزئی	Factory, Repository, Observer, Strategy	به تعداد نیاز (مثلاً ۱۰ تا ۲۰ عدد)

پترن‌های طراحی (Design Pattern)

بخش / مسئله	پترن پیشنهادی
چطور به دیتابیس وصل شوم؟	Repository + Unit of Work
چطور اشیای پیچیده بسازم؟	Factory یا Builder
چطور رفتارها را عوض کنم؟	Strategy
چطور رویدادها را مدیریت کنم؟	Observer یا Event Bus
چطور درخواست‌ها را فیلتر کنم؟	Chain of Responsibility
چطور رابط کاربری به روز شود؟	MVC یا MVVM یا Observer
چطور عملیات سنگین را غیرهمزمان کنم؟	Command + Queue

پترن	جایگاه استفاده	مثال در سیستم ما
Repository	دسترسی به دیتابیس – کل سیستم	همه جدول‌ها (User, Task, Project) ریپازیتوری خود را دارند. فیچر «افزودن تسک» از `TaskRepository.create()` استفاده می‌کند. فیچر «تغییر وضعیت» از `TaskRepository.update()` استفاده می‌کند.
Factory	ساخت اشیای پیچیده – در چند جا	اگر تسک انواع مختلف دارد: `TaskFactory.create(type='simple')` و `TaskFactory.create(type='recurring', interval=7)`. فیچرهای مختلف از همین Factory استفاده می‌کنند.
Strategy	الگوریتم‌های قابل تعویض – یک بار تصمیم گرفته می‌شود	استراتژی مرتب‌سازی تسک‌ها: `SortByDueDateStrategy` و `SortByPriorityStrategy`. می‌توانی در رانتایم عوض کنی.
Observer	رویدادها و اعلان‌ها – برای کل رویدادهای سیستم	وقتی تسک به `done` تغییر کرد، همه شنوندگان (Observer) مثل `EmailNotifier` و `LoggingService` خبردار شوند.
DTO (Data Transfer Object)	انتقال داده بین لایه‌ها – برای تمام APIها	هر فیچر از DTO مخصوص خود استفاده می‌کند اما الگوی DTO ثابت است: `CreateTaskDTO`, `UpdateTaskStatusDTO`

ترکیب پترن‌ها در یک سیستم

در یک سیستم نرم‌افزاری واقعی، شما همیشه از ترکیب چندین الگوی طراحی (Design Patterns) استفاده می‌کنید، نه فقط یک الگو.

این باور اشتباه که «یک پروژه باید یک پترن داشته باشد» رایج اما نادرست است. الگوهای طراحی مانند ابزارهای مختلف در یک جعبه ابزار هستند – هر کدام برای حل یک نوع مسئله خاص طراحی شده است.

بخش سیستم	پترن مناسب	چرا؟
دسترسی به دیتابیس	Repository	لایه دسترسی به دیتابیس را از منطق کسب‌وکار جدا می‌کند
ساخت اشیای پیچیده	Factory	ساختن تسک با انواع مختلف (ساده، تکراری، وابسته)
تغییر رفتار در رانتایم	Strategy	روش‌های مختلف مرتب‌سازی تسک‌ها (بر اساس ددلاین، اولویت، وضعیت)
اعلان رویدادها	Observer	وقتی تسک تمام شد، ایمیل/پیامک/لاگ بفرست
واسط بین لایه‌ها	DTO (Data Transfer)	انتقال داده بین API و سرویس و دیتابیس
مدیریت درخواست‌ها	Chain of Responsibility	بررسی متوالی دسترسی کاربر: آیا لاگین است؟ آیا مجوز دارد؟ آیا تسک متعلق به اوست؟
ذخیره وضعیت قبلی	Memento	قابلیت Undo در تغییر وضعیت تسک