MegaWeb| انواع معماری های نرم افزار

انواع معماری های نرم افزار

معماری و طراحی

تاکنون ، معماری های متفاوتی به منظور طراحی و پیاده سازی متناسب با رشد فن آوری در بخش نرم افزار ارائه شده است این معماری ها از یکطرف برخاسته از امکانات و ماهیت معماری سخت افزار ها در زمان خود و از طرف دیگر بسته به نوع و نگرش در تکنولوژی های ساخت نرم افزاری و انتظارات طرح شده توسط کاربران است هر معماری دارای شاخص ها و ویژگی های منحصر بفرد خود بوده و نرم افزارهائی که با اتکاء بر هر یک از معماری های فوق پیاده سازی می گردنند ، خصایص خود را از معماری بکارگرفته شده به ارث خواهند برد در زیر به شرح مختصری از هر یک از معماری ها می پردازیم مسلما معماری ها و چارچوب های جدید مبتنی بر برنامه نویسی تحت وب لزوم استفاده از معماریهای چند لایه را توصیه می نمایندعلاوه بر این در این نوع معماری عدم وابستگی بین مولفه ها (Components) و نیز سرویسها ( در غالب معماری Service Oriented ) مورد تاکید قرار گرفته است .

معماری چند لایه
در مهندسی نرم افزار، سیستم‌های نرم افزاری را به دلیل کاهش پیچیدگی و ساده تر شدن آنها و همچنین به خاطر تسهیل در امر نگــهداری و اعمال تغییرات در آنها،
به چـند زیر سیستم تقسیم کـرده و قسمت‌های مستقل سیستم را به صورت لایه‌های جداگانه و مستقل از هم طراحی می‌کنند. هر کدام از این لایه‌ها ضمن
اینکه وظیفه خاص خود را دارند، با هم در ارتباط بوده به طوری که هر لایه به لایه‌های بالایی و پایینی خود سرویس داده و از آنها سرویس می‌گیرد. انتقال اطلاعات و داده‌ها در بین این لایه‌ها از طریق Objectهایی که اصطلاحا (DTO (Data Transfer Object نامـیده می‌شوند، انجام می‌گیرد و کاربر نهایی فقط با لایه بیرونی در ارتباط بوده و کاری با لایه‌های دیگر ندارد. به این روش طراحی سیستم‌های نرم افزاری، معماری چندلایه یا N-Tier گفته می‌شود.

N-Tier یا N-Layer

لازم به ذکر است که در برخی منابع از واژه N-Tier به جای N-Layer استفاده میشود و اغلب فکر میکنند که بین این دو واژه تفاوتی وجود ندارد، در صورتی که این تفکر اشتباه است.Tier اشاره به اجزای فیزیکی نرم افزار دارد. یعنی اجزا میتوانند به لحاظ فیزیکی روی چند ماشین به صورت جدا از هم قرار بگیرند و یا اگر در یک ماشین قرار دارند تخصیص حافظه به آنها کاملا جدا و مستقل از هم است.

امّا واژه Layer به تقسیم بندی مجازی اجزاء اشاره دارد و این یعنی اینکه یک Tier خود بصورت داخلی میتواند Layer بندی شده باشد. به عبارت دیگر Tier ها همان اسمبلی پروژه و فایل های .exe و .dll میباشند، اما Layer ها مانند Namespace ها هستند.

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

نیاز به لایه بندی با ظهور سیستم های دو لایه Client-Server بیشتر حس شد. به طوری که لایه Client یک رابط کاربری بود و سرور هم لایه ای بود در ارتباط با پایگاه داده فعالیت می کرد. در روش Client-Server شما تعداد کامپوننت را بر روی صفحه قرار می دهید (خروجی که کاربر آن را مشاهده می کند این بخش را Client می نامند) سپس برای هر کامپوننت شروع به کد نویسی میکنید (Server) که به این بخش Code Behind نیز گفته میشود. در این مثال ساده همه چیز بسیار خوب خواهد بود، اما مشکل اصلی وقتی پیش خواهد آمد که حرف از Domain Logic ( قوانین محاسباتی،Validation ها و business rules ) و سایر مباحث در میان باشد.

بیشتر برنامه نویسان منطق را در لایه Server جای میدهند که این کار باعث تکرار شدن کد ها و طبیعتا، کاهش خوانایی برنامه، سخت شدن مشکل پشتیبانی و توسعه و... میشود به طوری که یک تغییر ساده در کد باعث تغییر در بخش های زیادی میشود.

اولین راه حل موجود استفاده از معماری لایه ای می باشد، برای این کار کافی است بخش های مختلف برنامه را در لایه های متفاوت مدیریت کنید، تفکیک این لایه ها می تواند به روش های زیر صورت پذیرد

1- قرار دادن کدهای مرتبط در کلاس های واحد
2- قرار دادن کلاس ها در Folder ها
3- قرار دادن Folder ها در پروژه های دسته بندی شده
4- قراردادن پروژه ها در فضای های نامی (Namespace)
5- تبدیل فضاهای نامی و پروژه ها به صورت DLL و یا سرویس ها برای جدا سازی واحد ها
6- و...

همانطور که مشاهده می کنید این لایه بندی می تواند به صورت خیلی ابتدایی با یک Folder مدیریت شود و یا در سطوح بالا به صورت سرویس هایی مشخص تفکیک شود.

معماری 3 لایه

همزمان با اینکه معماری Client-Server در محبوبیت به سر می برد، دنیای شی گرایی نیز در حال رشد بود و و به دنبال راه حلی برای حل مشکلDomain Logic و یا به زبان ساده تفکیک منطق برنامه از سایر قسمت ها بود، در نهایت این تلاش ها منجر به معرفی معماری 3 لایه گردید. در این روش شما هر برنامه از سه لایه ی اصلی تشکیل می شود.

Presentation

بالاترین لایه Presentation نام دارد و در واقع لایه ایی است که کاربران آن را مشاهده می کنند. این لایه همان UI برنامه می باشد.

Domain Logic

در لایه دوم منطق برنامه قرار دارد، این لایه Domain Logic نام دارد.
لایه ایی که منطق برنامه شما در انجا قرار می گیرد، در واقع جایی که دستورات، شرطی ها و بررسی های یک فرایند نوشته می شود را Domain Logic می گویند.

Data Access

در نهایت در معماری سه لایه، لایه آخر مربوط به فعالیت های مرتبط با پایگاه داده می باشد و از همین رو نام این لایه را Data Access می نامند.

در این روش شما می توانید به سادگی کدهای هر بخش را از یکدیگر جدا کنید و با استفاده از همین تفکیک پذیری ساده می توانید قسمت های مختلف یک پروژه را با تیم های تخصصی طراحی و پیاده سازی کنید، مثلا از بخش UI درخواست کنید بدون هیچ نگرانی UI صفحات مختلف و یا فرم های مختلف پروژه را طراحی کنند و سپس در بخش دیگر برنامه نویسان کدهای این صفحات و فرم ها را تکمیل کنند.
همچنین با جدا شدن لایه Data Access می توان کدهای کار با پایگاه های داده را در پروژه های مختلف به سادگی استفاده نمود.

معماریMainFrame
معماریFile Server
معماری سرویس گیرنده / سرویس دهنده
معماریTwo-Tier
معماری چندلایه Three-Tier ,N Tier

معماری MainFrame

ویژگی :

- معماری فوق در دهه های 1970-1960 مورد توجه و استفاده جدی قرار داشت
- کامپیوتر اصلی ( Host) مسئولیت انجام تمامی پردازش ها را برعهده دارد.
- کاربران با استفاده از ترمینال ها ، قادر به ایجاد ارتباط با سیستم اصلی (host) می باشند.
- ترمینال ها هوشمند نبوده و صرفا" به یک صفحه کلید و نمایشگر محدود می باشند.
- فشردن کلیدهای صفحه کلید ، تنها چیزی است که ارتباط بین کاربران(ترمینال ها ) و سیستم اصلی را معنی خواهد کرد.
- داده ها و منطق برنامه بر روی یک سیستم (Host) یکسان ذخیره می گردنند.

مزایا :

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

معایب :

هزینه تهیه ، اجاره و پشتیبانی این نوع سیستمها بسیار بالا است .
برنامه ( منطق ) بهمراه داده های مربوطه در یک محل مستقر و از یک محیط پردازش یکسان استفاده می کنند.
اغلب برنامه های نوشته شده بر اساس معماری فوق محیط های رابط کاربر گرافیکی را حمایت نمی نمایند.

معماری File Server

ویژگی :

چرخش180 درجه ای نسبت به معماری MainFrame.
از سرویس دهنده یا سرویس دهند گان متعدد، بصورت متمرکز استفاده می گردد.
منابع متفاوتی نظیر چاپگر و یا فضای ذخیره سازی ( هارد ) به اشتراک گذاشته می شوند.
سرویس دهنده فایل های مورد نیازو ذخیره شده توسط منابع اشتراکی را برای کاربران ارسال خواهد کرد.
کار درخواست شده توسط کاربر ( منطق و داده ) بر روی سیستم کاربر اجراء خواهد شد.
منطق برنامه برروی سیستم کاربر ( سرویس گیرنده ) اجراء خواهد کردید.
داده ها بر روی سرویس گیرنده مستقر خواهند شد.

مزایا :

برای استفاده از معماری فوق نیاز به صرف هزینه های بالا نخواهد بود .
از لحاظ بکارگیری منابع دارای انعطاف پذیری مناسبی است .

معایب :

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

معماری Client Server

ویژگی :

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

مزایا :

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

معایب :

عدم وجود امکانات لازم برای کپسوله نمودن سیاست های راهبردی نرم افزار
کاهش کارائی برنامه همزمان با افزایش تعداد کاربران همزمان
بهبود عملکرد برنامه و یا اعمال اصلاحات مورد نظر همواره یکی از چالش های جدی است .

تاکنون مدل های متفاوتی از معماری فوق پیاده سازی شده است :

1- پردازش های مبتنی بر میزبان مدل فوق بمنزله یک مدل سرویس دهنده / سرویس گیرنده تلقی نشده و مشابه مدل MainFarme است

2- پردازش های مبتنی بر سرویس دهنده در این مدل سرویس دهنده تمامی پردازش های مربوطه را انجام و سرویس گیرنده مسئولیت ایجاد بخش رابط کاربر را برعهده خواهد د اشت.

3- پردازش های مبتنی بر سرویس گیرنده تمامی عملیات بر روی سرویس گیرنده انجام خواهد شدعملیات مربوط به بررسی صحت داده ها و سایر عملیات مربوط به منطق بانک های اطلاعاتی بر روی سرویس دهنده انجام خواهد شد.

4- پردازش های مبتنی بر همیاری .در این مدل سرویس دهنده و سرویس گیرنده بمنظور انجام یک فعالیت با یکدیگر تشریک مساعی خواهند کرد.

معماری Client Server : Two Tier

ویژگی :

مشابه مدل Client Server در بخش قبل می باشد.
در این مدل از یک سرویس دهنده و یک سرویس گیرنده در شبکه استفاده می گردد.
مدل فوق از سه بخش که در دو لایه سرویس دهنده و سرویس گیرنده قرار خواهند گرفت، تشکیل می گردد.
بخش های رابط کاربر ، مدیریت پردازش ها و مدیریت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
منطق برنامه بین دو محل فیزیکی توزیع می گردد.

مزایا :

مناسب ترین روش برای پردازش های توزیع شده در یک شبکه با حداکثر یکصد کاربر
سهولت در امر پیاده سازی
نسبت دهی مستقیم رابط کاربر با منابع تامین داده ها

معایب :

عدم وجود امکاناتی برای کپسوله نمودن سیاست های راهبردی نرم افزار
کاهش کارائی برنامه همزمان با افزایش تعداد کاربران همزمان
عدم وچود انعطاف لازم از بعد انتقال یک برنامه از سرویس دهنده ای به سرویس دهنده دیگر بدون انجام تغییرات اساسی

معماری Multi Tier, Three Tier

ویژگی :

مدل فوق در سال 1990 عرضه شده است .
در این مدل از یک Tier میانی دیگر بین سرویس گیرنده ( رابط کاربر) و سرویس دهنده بانک اطلاعاتی استفاده می شود.
لایه میانی شامل مجموعه ای از ابزارها برای دستیابی به منابع سیستم ، صرفنظر از نوع پلات فورم است
لایه میانی مسئولیت مدیریت پردازش ها را برعهده خواهد گرفت
لایه میانی مسئولیت تجزیه و یا ترکیب نتایج حاصله از منابع داده ئی نظیر بانک های اطلاعاتی را برعهده دارد.
بخش های رابط کاربر ، مدیریت پردازش ها و مدیریت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
لایه میانی خود می تواند به دو و یا بیش از دو بخش با عملکردهای متمایز تقسیم گردد (Multi-Tier) لایه منطق تجاری می تواند برروی سرویس دهنده های متعدد قرار گیرد.
مدل فوق گزینه ای مناسب برای پیاده سازی نرم افزار بر روی اینترنت است .

مزایا :

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

الگوهای برنامه نویسی

اگر بخواهم در مورد الگو صحبت کنم در واقع باید بگم یک الگو راه حلی برای حل مسایل است که در گذشته به عنوان بهترین راه حل ارائه شده، الگوها ساختارها و روش (methodology) های کلی ایجاد میکنند. یک الگو یک abstraction قابل تشخیص است که در موقعیتها و برنامه های کاربردی مختلف تکرار شده و متناوبا استفاده میشود. این موقعیت میتواند مربوط به ساختار (Structure) باشد که مبین الگوی معماری است و یا توصیفی از رفتار (behavior) نرم افزار باشد که تعریفی از الگوی طراحی است و یا در خصوص یک زبان برنامه نویسی خاص باشد که در این صورت الگوی زبان نام دارد.

الگوهای معماری (Architectural patterns)

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

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

انواع Design Pattern :
در اینجا سه دسته از Design Pattern وجود دارد که میتواند برای هر نیازی مورد استفاده قرار بگیرد و آنها عبارتند از :

- Creational Patterns :

این Pattern مکانیزمی را برای ایجاد اشیا یک کلاس بصورت کارآمد تر را فراهم میآورد :

• Factory :
Factory Pattern اشیا را بدون شرح دادن منطق ایجاد آن برای کاربر ، ایجاد میکند و یا استفاده از یک inteface معمولی به اشیا جدید ایجاد شدده ارجاع می‌کند .

• Abstract Factory :
Abstract Factory چیزی نیست جز یک Factory از Factoryها ، که اشیا Factory را بر مبنای Interface بدون مشخص کردن صریح کلاس ، ایجاد می‌کند .هر Factort تولید شده میتواند تحت عنوان Factory Pattern به اشیا داده شود .

• Builder :
بصورت مرحله به مرحله با استفاده از اشیا ساده اشیایی پیچیده را Build میکند .

• Prototype :
با استفاده از cloning (همتا سازی) به ما امکان ایجاد اشیا همتا (duplicate objects) را میدهد . این زمانی موثر است که ایجاد یک شی بسیار پر هزینه است .

• Singleton :
در این Pattern فقط کلاس های واحد - single classes - فقط یک شی را ایجاد و شامل میشوند .

- الگوهای ساختاری -- Structural Patterns :
این الگو مکانیزمی را برای سرو کار داشتن با رابطه های مختلف entityها با یک روش ساده تر ، فراهم می‌آورد .

• Adapter :
این الگو چیزی شبیه یک پل میان دو Interface مستقل است که یک کلاس عملکرد این دو Interface مستقل را به هم متصل می‌کند .

• Bridge :
Bridge Pattern یک abstraction را از پیاده سازی آن جدا میکند ، پس با این وجود این دو قسمت بصورت مستقل و جدا از هم میتوانند کار کنند .

• Composite :
الگوی طراحی مختلط (Composite design patterns) برای ارائه قسمتی ، به خوبی ارائه تمام سلسه مراتب ، یک درخت ساختار را تشکیل میدهد . این الگو یک کلاس ایجاد میکند که گروهی از اشیا خودش را نگه میدارد و راهی برای گسترش و ویرایش این اشیاه فراهم می‌آورد .

• Decorator :
این یک نوع از پیاده سازی کلاس wrapper است که بدون ایجاد تغییر در جریان ، این امکان را به کاربر میدهد که یک عملکرد جدید را به شی اضافه کند ، این الگو با یک کلاس موجود همانند یک wrapper عمل میکند . wrap class ، پیاده سازی اصلی کلاس را محصور و احاطه میکنند و ویژگی های دیگر را برای کلاس فراهم می‌آورند .

• Façade :
این Pattern پیچیدگی های داخلی یک سیستم را پنهان میکند و برای سر و کار داشتن با sub systemهای مختلف یک متد ساده را فراهم می‌آورد . این الگو یک کلاس Single دارد و ان متد delegateهای مختلف را برای متدهای کلاس های مختلف فراهم می‌آورد .

• Flyweight :
این یک factory pattern است که برای کاهش تعداد اشیا ایجاد شده ،دارای یک حافظه داخلی است . قبل از ایجاد یک شی بررسی میکند که اگر یک شی ازین نوع وجود داشته باشد ، آن را به همان ارجاع میدهد .

- الگو های رفتاری -- Behavioral Patterns :

این الگو مکانیزمی را برای ارتباط entity ها با هم ، ارائه میدهد .

• زنجیره مسئولیت -- Chain of Responsibility :

این الگو، یک شی درخواست کننده و دریافت کننده ایجاد می کند که این دو ، زنجیره را به وجود می آورند. اگر یکی از شی ها نتواند وظیفه را مدیریت کند، وظیفه به شی دیگر منتقل می شود ، که این عمل ، مشابه انتقال درخواست ها بین زنجیره ای از شی ها می باشد.

• دستور --Command:

یک درخواست ، در زیر مجموعه ی یک شی خلاصه می شود و به invoker پاس داده می شود تا به این ترتیب ، شی مناسبی که می تواند درخواست تحت دستور را اجرا کند، را پیدا می کند.

• مترجم -- Interpreter:
این الگو راهی برای ارزیابی زبان یا expression فراهم می آورد . این برای تجزیه برخی Syntax ها و Expression ها مفید هستند .

• مکرر -- Iterator :
Iterator pattern یک راه برای پیاده سازی کلاس های Iterator که اشیا را از یک آرایه مجموعه بدون دانستن جزئیات اساسی ، باز میگرداند

• میانجی -- Mediator :
پیچیدگی ارتباطات بین اشیا چندگانه یا کلاس ها را کاهش میدهد . جایی که کلاس ها بصورت مستقیم با هم در ارتباط نیستند . کلاس میانجی همه ارتباطات بین کلاس های مختلف را مدیریت می کند.

• Memento:

این الگو برای نگهداری حالت شی و یا برنامه ها مفید است، که به این معنی است که یک روش برای ذخیره سازی و بازیابی حالت شی ها فراهم می کند.

• راهیاب --Observer:
این الگو برای زمانی مفید است که رابطه بین شی ها یک به چند است و نیاز به تغییر و ویرایش یک شی داشته باشیم. در این حالت، باید شی های وابسته به صورت خودکار از آن تغییر ، مطلع شوند.

• وضعیت -- State :
این الگو ، رفتار کلاس را بر اساس حالت آن تغییر می دهد. روش کار به این صورت است که یک شی ایجاد می کند که حالات مختلف را نمایش می دهد و یک شی context که رفتار آن ، بر اساس رفتار شی ، تغیر می کند.

• راهبرد --Strategy:

این الگو ، راهبرد های مختلف را کپسوله سازی می کند و یک context که رفتار آن به ازای راهبرد های اشیا، مختلف است. شی راهبرد ، الگوریتم اجرایی context را تغییر می دهد.

• Template Method:

این الگو یک کلاس abstract تعریف می کند و یک متد ایجاد می کند که مجموعه ای از متدها را در یک روش تعریف شده، اجرا می کند.

• Visitor:

این الگو یک عملیات بر روی یک مولفه از ساختار شی اجرا می کند و همچنین یک عملیات جدید بدون تغییر سلسله مراتب کلاس تعریف می کند.بنابراین با این روش، تعداد عملیات ها می تواند همزمان با تغییر تعداد visitor ها تغییر کند.

Anti-Pattern چیست

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

بسیاری از شما پروژه هایی را دیده اید که با یک مرور ساده می توانید نحوه کار پروژه را از لحاظ فنی بررسی کنید و برعکس پروژه هایی را دیده اید که برای انجام فرایند ساده فعالیت های پیچیده ای اتفاق می افتد که هیچ تاثیر مثبتی در افزایش سطح فنی پروژه ندارند.

همه ی این نکات خرد و کلان باعث می شوند تا یک پروژه بتواند به موفقیت برسد و یک پروژه با شکست روبرو شود.

نوشته شده توسط :