خطاي ناشي از طراحي

Factoring:

The process of determining what properties and method belong on an Interface

در صورت عدم اجراي صحيح اين عمليات مطمئنا دچار مشكلات بسياري مي شويد كه طراحي و ساختار برنامه تان را دچار مشكلات پنهاني مي كند كه در زماني كه اصلا انتطارش را نداريد خودش را نشان مي دهد اتفاقي كه اخیرا براي تيم ما رخ داد.
در شركت ما يك Framework براي توليد محصولات وجود دارد كه اخيرا براي افزاريش كارايي-كاهش حافظه مصرفي و افزايش سرعت اجرا - تغييراتي در بخش Plug-in Interface آن انجام شد.نسخه بهينه شده با مجموعه اي از تغييرات ديگر نهاییشد،به همين منظور تيمهاي توسعه نسبت به اعمال تغييرات در سيستم خود اقدام كردند،تا اينجا همه چيز خوب بود تا اينكه هنگام تست سيستمها مشخص شد يكي از plug-in ها هنگامي كه در Shell بار گزاري مي شود درست رفتار نمي كند ،بعد از مدتي بررسي به نكته بسيار جالبي رسيديم ،محل خطا پيدا شد،از آنجا كه محيط توسعه ما .Net است يكي از اعضا تيم توسعه آن Plug-in  براي پياده سازي فاصل Iplugin جديد از فشردن دكمه هايF10 Alt+Shift+ استفاده كرده بود،مطمئنا مي دانيد كه .Net با اين كار تمام متدهاي فاصل را با كدي درون آن كه يك Exception  به بالا پرتاب مي كند ميسازد،دوست توسعه دهنده ما هم متدهايي را كه نياز داشته پياده سازي كرده يك متد را كه مجموعه اي خاص از Command ها را براي نمايش در منوهاي پيش فرض Shell فرا هم مي كرده باز نويسي نكرده در واقع حتي خط پرتاب كننده Exception  را هم پاك نكرده است،چرا كه اصلا به آن نيازي نداشته كه بخواهد به آن متد هم فكر مي كرده چه رسد به اصلاح آن و نتيجتا هنگامي كه shell از اين plugin مي خواسته آن متد را اجرا كند خطايي رخ ميداده است.
 اين خطا ناشي از آن بود كه رفتاري به يك Plugin  داده شده بود كه در ذات plugin هاي ما نبود و بايد آن رفتار به يك فاصل ديگر داده ميشد. تا هر كس آن را خواست پياده سازي كند.
يعني در عمليات factoring صورت گرفته براي آن فاصل متدي اشتباه به آن اختصاص داده شده بود.متدي كه به آن تعلق نداشته است.

كدي كه منشا خطا شده بود و خود حاصل طراحي اشتباه:

Ipugin

{

 Some Methode….

      List GetExtraComamndsForShellDefualtMenu();

}

و راه حل صحيح تر:

IPlugin

{

 Some Methode….

}

 

IExtraShellCommandProvider

{

        List GetExtraComamndsForShellDefualtMenu();

}

نكته آن است كه يك طراحي خوب و صحيح مي توان مانع از بخشي از خطاهاي محتمل در توسعه سيستم باشد  اين يك احتمال بدون قظعيت است ولي عكس اين قضيه يك غالب

 مفهوم معيارهاي كيفيت در نرم افزار

مفهوم معيارهاي كيفيت در نرم افزار

بر اساس مفهوم چرخه ABC معيار هاي كيغي يك نرم افزار را Business  آن سيستم نرم افراري مشخص مي كند.واقعيت آن است كه مهم ترين وظيفه يك نرم افزار بر آورده كردن نيازهاي عملياتي آنست و وقتي يك نرم افزار مورد بازبيني قرار مي گيرد نه برا ي تغيير كاربرد آن كه به منطور بهبود معبار هاي كيفي سيستم است.معماري نرم افزار اولين جايي است كه مي توان به برآورده كردن معيارهاي كيفي نرم افزار انديشيد.

معماري و شاخصهاي كيفي

برآوردن نيازهاي كيفي امري است كه بايد در تمام مراحل طراحي،پياده سازي و استقرار مورد توجه قرار گيرد و به صورت انحصاري و صد در صد منحصر به بك مرحله از توليد و يا راه اندازي نرم افزار نمي باشد.بايد دقت كرد كه معماري مهمترين محل براي بررسي معيارهاي كيفي است ولي به تنهايي قابليت حل چالشها را ندارد.

در برخي از سيستمهاي پيجيده دستيابي به هر يك از معيارهاي كيفي به تنهايي و منحصرا ممكن نيست،در اين گونه از سيستمها دستيابي به يك پارامتر كيفي بر روي ساير معيارها تاثير مي گذازد،تاثير مثبت با متفي.

معماري براي تحقق بسياري از معيارهاي كيفي بسيار مناسب است و اين معيارهاي كيفي بايد در زمان تهيه معماري در نظر گرفته شده و مورد سنجش و بررسي قرار گيرد.بايد در نظر داشت معماري به تنهايي قادر به دستيابي به تمام پارامترهاي كيفي نيست و تنها زيربناي دستيابي به آن معيارها را فراهم مي كند اما اگر به درستي به جزئيات پرداخته نشود اين زيربنا مفيد نخواهد بود.

 

 الگوهای معماری(Architectual Patterns) -مدل های مرجع(Reference Models) - معماری های مرجع(Reference Ar

الگوهای معماری Architectual Patterns

یک الگوی معماری توضیحی از گروهی از اجزا(Element) و روابط بین آنها با مجموعه ای از محدودیتها(Constraint) برا ی استفاده از آنهاست.یک الگو می تواند به عنوان مجموعه ای از محدودیتها بر روی یک معماری در نظر گرفته شود-بر روی اجزا و الگوهای ارتباطی بین آنها-و این محدودیتها مجموعه یا خانواده ای از معماری هایی که آنها را برآورده سازند معرفی می کنند.برای مثال Client –Server یک الگوی معماری معمول است،Client , Server دو نوع از اجزا(Element) هستندعبارت Client –Server نشان دهنده وجود چندین Client است ،خود Client ها و مجموعه فعالیتهای آنها مشخص نمی شوند و تنها پیاده سازی پروتکل ارتباطی آنها بر عهده هریک از Client ها و Server گذاشته می شود در معماری بررسی می شوند.معماری های بیشماری بر اساس این تعریف از نوع معماری Client –Server خواهند بود اما هریک از آنها متفاوت از دیگری است.

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

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

 مدل های مرجعReference Models

یک مدل مرجع تقسیم بندی عملیات سیستم(Functionality) با جریان داده ها بین اجزا سیستم است.در واقع یک مدل مرجع فرم استانداردی از شکستن مسائل بزرگتر شناخته شده از پیش به مسال کوچک تر است که بتوان با حل هر مساله کوچک و جمع بندی آنها نهایتا مساله بزرگتر را حل کرد.مدلهای مرجع در واقع مربوط به حیطه مسایل بزرگ و پیشرفته است.برای مثال بررسی اجزا یک کامپایلر و چگونگی کار کردن آنها با هم و چگونگی جریان دادهها بین آنها در واقع یک مدل مرجع برای سیستم کامپایلر است.

 معماری های مرجعReference Architecture

معماری مرجع در واقع یک مدل مرجع است که بر اجزا و جریان داده(Data Flow) بین اجزا نرم افزار نگاشت شده است.از آنجا که یک مدل مرجع عملیات سیستم را تقسیم بندی میکند یک معماری مرجع آنرا بر اجزا سیستم نگاشت می کند الزاما این نگاشت یک نگاست یک به یک نیست یعنی گاها ممکن است یک عملیات از عملیات های مدل مرجع بر چند جز ار سیستم نگاشت شوند تا آنرا با همکاری هم انجام دهند ویا ممکن است یک جز از سسیستم چند عمل را انجام دهد.

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

 معماری قسمت سوم

نحوه عملکرد چرخه معماری- کسب و کار:  (ABC: Architecture Business Cycle )

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

 2-معماری میتواند بر اهداف تیم توسعه تاثیر گذار باشد.یک نرم افزار موفق میتواند شرکت را قادر سازد که در بازار مربوط به آن نوع نرم افزار جای پای خود را محکم کند و با استفاده از معماری به توسعه موثرتر و بهتر از سیستمهای مشابه بپردازد.

3-معماری می تواند بر نیازمندیهای مشتریان تاثیر گذار باشد.

4-معماری بر مجموعه تجربیات معمار تاثیر گذار است.

جریان کار تولید نرم افزار(Software Process)و
چرخه معماری- کسب و کار(Architecture Business Cycle)

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

ü ساختن موارد کسب و کار برای سیستم(Business Case)

ü درک نیازمندیها

ü ساختن یا انتخاب معماری

ü مستند سازی و بررسی معماری

ü تحلیل و سنجش معماری

ü پیاده سازی سیستم بر اساس معماری

ü بررسی برآورده شدن معیار های معماری و توسعه نرم افزار بر اساس معماری

· ساختن موارد کسب و کار برای سیستم(Business Case)

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

· درک نیازمندیها

برای استخراج نیازمندی ها از ذینفعان روشهای مختلفی وجود دارد ،برای مثال Object Oriented Analysis یکی از این روشهاست،برای انجام این کار بهتر است سیستمهای مشابه سیستم فعلی بررسی شود و از تجربیات آنها برای درک بهتر سیستم استفاده شود،همچنین راه دیگر برای درک بهتر نیازمندیها ایجاد prototype  است ،همچنین معمار باید ویژگیهای کیفیت نرم افزار برای (Quality Attribute )سیستم را شناسایی کند.

· ساختن یا انتخاب معماری

ممکن است بتوان از میان مجموعه معماری های موجود یک معماری را انتخاب واستفاده کرد

· مستند سازی و بررسی معماری

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

· تحلیل و سنجش معماری

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

· پیاده سازی سیستم بر اساس معماری

داشتن یک مستند واضح و صریح معماری برای ایجاد سیستم بر اساس آن اولین گام لازم است
· بررسی پایبندی سیستم ایجاد شده به معماری طراحی شده برای آن
برای اطمینان از بر آورده شدن خواسته های ذینفعان توسط نرم افزارهای پیاده سازی شده لازم است از ایجاد سیستم بر اساس معماری ایجاد شده اطمینان حاصل کرد

 

 Interface Invariance Principle

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

 مجموعه عوامل تاثیر گذار بر معماری

در مطلب قبل چندي از پارامتر هاي موثر بر معماري را مطرح كردم كه اينجا در ادامه به توضيح كوتاهي در باره آنها مي پردازم:

مجموعه عوامل تاثیر گذار بر معماری:

معماری متاثر از StakeHolder  های سیستم است:

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

تصویر:تاثیر خواسته های ذیفعان بر معمار و معماری

داشتن یک سیستم خوب و قابل قبول شامل خصوصیاتی همچون
 performance, reliability, availability, platform compatibility, memory utilization, network usage, security, modifiability, usability  و امکان ارتباط با سایر نرم افزارها و سیستمها است این خصوصیات روی همرفته نیاز های معماری یک سیستم را مشخص می کند، هریک از این خصوصیات بر دیدگاه زیر مجموعه ای از ذینفعان تاثیر گذار است که موجب اظهار نظر آنان در باره معماری بر اساس خواسته های مورد نظرشان خواهد شد.

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

معماری متاثر از سازمان توسعه دهنده (DEVELOPING ORGANIZATION) است :

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

تاثیرات ناشی از سازمان توسعه دهنده بر روی معماری سه نوع است.

کسب و کار فوری و کوتاه مدت(Immediate Business)

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

کسب و کار دراز مدت(Long-Term Business)

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

ساختار سازمانی(Organizational Structure)

برای مثال گاهی ممکن است لازم باشد بر اساس تجربیات سازمان و سازمانهای دیگر بخشی از زیر سیستمها برای توسعه به سایر سازمانها داده شوند این موضوع بر چگونگی

شکستن سیستم به زیر سیستمها و نحوه ارتباط آنها تاثیر گذار است.

 

معماری متاثر از محیط های فنی (Technical Environment)  است

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

 

 جمع بندی عوامل تاثیر گذاری

عوامل تاثیر گذار برروی معماری خواستگاههای متفاوتی دارند بعضی از آنها مفهومی و ضمنی هستند ولی برخی از آنها در تضاد هستند.

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

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

 

تصویر عوامل تاثیر گذار بر معماری

پ ن :

بر اساس قانون دوم نيوتن واقعيت آن است كه همان طور كه معماري از عوامل ياد شده متاثر است خود معماری نيز بر اين عوامل تاثير گذار است اين چرخه تاثير عوامل محيطي بر معماری و تاثير متقابل معماری بر آنها را Business Architecture Cycle  يا به اختصار ABC   مي نامند

 آرامش،زندگي

چند وقتي بود  كه بسيار بد مي خوابيدم،آشفته و پريشان و ميانه شب ونزديك به سحر آشفته از خواب مي پريدم تا اينكه دو برنامه از پيش برنامه ريزي نشده  برايم  پيش آمدند كه بخش عظيمي از اين آشفتگي هاي شبانه و اضطرابهاي روزانه را كاهش دادند،اولي به لطف همسرم بود و دومي به لطف برنامه ه اي مشترك با همسرم  و تني چند از دوستانمان.اولي را كه همسر گرانقدر  مسبب آن بود خربد كارتون بابا لنگ دراز(جودي ابوت) بود،كه طي حركتي انقلابي بنده و ايشان طي سه شب از سر شب تا پاسي از نيمه شب تمامي 40 قسمت اين كارتون را از ابتدا تا به انتها ديديم،بدون تحريف و مميزي و اصلاح،فضاي لطيف و انساني داستان ،نبود خشونت و آن حس نوستال‍‍ژيك و بازژشت به دوران كودكي و نوجواني  چنان آرامشي را برايم حاصل كرد كه شايد بتوانم به جرات بگويم هيچ كتاب و فيلم و نوشته و نمايشي طي 2-3  سال اخير اين كار را نكرده بود ،دومين برنامه هم برنامه باغ لاله گچسر بود كه زمين رنگارنگش هر آنچه آرامش بود را در لاله ها و  شگوفه هايش جمع كرده بود.عكسهاي زير از همين باغ لاله هستند كه همان روز جمعه گرفتيم-من و خانم همسر.

 

 

 

 

 

پ ن:

هرچند هنوز بخش زيادي از كتابهاي فني را كه برنامه مطالعه شان را داشتم نخوانده ام و از برنامه ام عقبم ولي اين 4 روز را به كل از آنها فارغ بودم و حس ميكنم بزرگترين لطفي را كه ميشد به خودم كردم.

واقعا گاهي زندگي به همان معناي سابقش دوست داشتني تر و گاها براي توانايي در ادامه روش نوينش ناگزير است

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

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

همیشه درگیر مفهوم معماری بودم هرچه می خواندم نهایتا به تکنولوژی و پلت فرمهای توسعه و راه حل های تکنیکی بر می گشت ،این روزها درگیر خواندن کتابی هستم با عنوان
Software Architecture in Practice - Second Edition-By Len Bass, Paul Clements, Rick Kazman
که فارغ از تکنولوژی به بحث در باره فلسفه معماری نرم افزار پرداخته است و تازه دلیل بسیاری از چالشهایی را که تا امروز با آنها درگیر بوده ام را می فهمم ،از این پست تا چند پست دیگر گاها گزیده هایی از این کتاب را اینجا مطرح خواهم کرد ، شاید کمکی باشد برای حل همان چالشهایی که من با آنها درگیر بودم از تعریف معماری گرفته تا عوامل موثر بر آن،خواندن این کتاب را به همه دوستان پیشنهاد می کنم .

تعریف

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

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

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

معماری از کجا می آید؟

معماری حاصل مجموعه ای از تصمیمات کسب و کار(Business)  و تصمیمات فنی (Technical) است. در عمل عوامل تاثیر گذار زیادی هنگام کار طراحی یک معماری وجود دارند، این عوامل متاثر از محیطی هستند که معماری باید درآن و برای آن پیاده شود.برای مثال مجموعه تصمیمات طراحی یک معمار برای یک نرم فزار بلادرنگ(Real-Time) که Deadline  های آن بسیار سخت گیرانه هستند متفاوت از مجموعه تصمیمات معماری برای همان سیستم خواهد بود زمانی که آن سخت گیری برای Deadline  های آن وجود ندارد یا اینکه معماری ایجادشده در حال حاضر برای سیستمی با مجموعه نیازمندی های خاص،سخت افزارهای خاص،و تیم پشتیبانی مشخص و منابع نیروی انسانی مشخص متفاوت از معماری طراحی شده برای همین سیستم در 5 سال پیش خواهد بود.

از مهم ترین پارامترهای تاثیر گذار بر معماری می توان به عوامل زیر اشاره کرد:

معماری متاثر از Stakeholder  های سیستم است

معماری متاثر از سازمان توسعه دهنده (DEVELOPING ORGANIZATION) است

معماری متاثر از محیط های فنی (Technical Environment) است

پر واضح است که خود معمار و تجربیات او یا حتی آخرین کتابی که در باره معماری خوانده است به شدت برروی معماری سیستم تاثیر گذار است.گاها پروژهها محلی برای به چاالش کشیدن آموخته های جدید معمار و کسب تجربه است (در این جور مواقع باید خدا به داد پروژه و صاحب آن برسد که نقش آن موجود آزمایشگاهی بیچاره را بازی میکنند)

 

 شروع

  سلام

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

منوی اصلی

صفحه نخست
پست الكترونيك
آرشيو مطالب

آرشیو مطالب

مرداد 1387
تیر 1387
خرداد 1387
اردیبهشت 1387

پيوندها

سماموس
مهندس علي-دوستي خوب و با تجربه
مهندسی نرم افزار
علیرضا
هابل - چشم خيره بشر به فضا

RSS وبلاگ

  RSS  

پشتیبانی