تالار گفتمان مانشت

به نام او

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

خیلی خلاصه بگم که :
در واقع هر متدولوژی شامل فازهایی هست که بر اساس اون متدولوژی و روش خاص اجرا می شن.
یعنی ما یکسری فاز داریم که در هر متدولوژی به گونه ای خاص اجرا می گردند. (البته مشترکاتی هست)
البته متدولوژی ها زیاد هستند . (در مانشت مطلبی زیبا از دکتر خوندم که به تعداد مهندسین نرم افزار می شه روش داشت.متدولوژی روش انجام هر کاری است. و هر کسی می‌تونه به یه شکل یه کار رو انجام بده. معمولاً نمونه‌های موفق و شرکت‌های بزرگ این متدولوژی‌ها رو می‌سازند و تجربه موفقی پشتشون هست. )

ما باید اول روش ها رو خوب بشناسیم و بعد اونها رو مقایسه کنیم و ببینیم کدوم روش به درد کجا می خوره.
روش هایی که وجود داره :
آبشاری (waterfall)
افزایشی (Incremental)
RUP
R.A.D
XP
حلزونی (spiral)
prototyping
و ...

eXtended Programingاز متدولوژی های Agile (چابک) در تولید نرم افزار است، که بر خلاف متدولوژی های سنگین مثلRUP از مستندات کمتری استفاده می کنند و برای پروژه های کوچک و متوسط کارایی دارند
توضیحات بیشتر با یک جست و جوی ساده در اینترنت قابل دسترسی ست

البته پست قبلی من برای موضوع XP بود، که تاپیکش حذف شد، منم آوردمش اینجا Big Grin

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

اجازه بدید ابتدا یک دسته بندی کلی داشته باشیم

روش های سنگین وزن مانند RUP : دارای مستند سازی زیاد و مخصوص پروژه های بزرگ،

روش های چابک مانند XP, Rapid application development (RAD), Scrum و ...: دارای مستند سازی کم و مخصوص پروژه های کوچک و متوسط

در prototyping نمونه ی کار به صورت آزمایشی ساخته می شود و به مشتری داده می شود تا ببینیم آیا نیازهای او را برآورده می کند یا خیر، در صورت نیاز این مرحله چندین بار تکرار می شود تا به هدف نهایی برسیم و مشتری کار را بپسندد.
مشکل روش هم اینکه ممکنه انتظار مشتری محترم خیلی بالا بره!!

بهترین راه درک این روشها ، ایجاد یک پروژه (هر چند کوچک) بر مبنای هر یک از آنهاست.

یادمه که یه جا از دکتر خوندم سیستم چویر بر اساس متدولوژی xp نوشته شده.
جالبه .

نگاهی به روش آبشاری در تولید نرم افزار :

کد: 

The waterfall model is a model which was developed for software development; that is to create software. It is called as such because the model develops systematically from one phase to other in a downward fashion, like a waterfall.

کد: 

The most probable phases through which it progresses downwards are

•           Definition Study/Analysis

 •           Basic Design

 •           Technical Design/Detailed Design

 •           Construction

 •           Testing

 •           Integration

 •           Management and

 •           Maintenance.

کد: 

Before the advent of this method, the software development in the computer companies suffered from a haphazard integrated software network like cluttered knitting. However with this method they hoped to bring clarity in their projects.

کد: 

About the Phases

As said earlier the waterfall model has been structured on multiple phases especially to help out the software construction companies to develop an organized system of construction. By following this method, the project will be divided into many stages thus easing out the whole process. For example you start with Phase I and according to this model, one only progresses to the next Phase once the previous one has been completed. This way one moves progressively to the final stage and once that point is reached, you cannot turn back; similar to the water in a waterfall.

کد: 

Brief Description of the Phases of Waterfall Model

•           Definition Study / Analysis: During this phase research is being conducted which includes brainstorming about the software, what it is going to be and what purpose is it going to fulfill.

 •           Basic Design: If the first phase gets successfully completed and a well thought out plan for the software development has been laid then the next step involves formulating the basic design of the software on paper.

 •           Technical Design / Detail Design:  After the basic design gets approved, then a more elaborated technical design can be planned. Here the functions of each of the part are decided and the engineering units are placed for example modules, programs etc.

 •           Construction / Implementation: In this phase the source code of the programs is written.

 •           Testing: At this phase, the whole design and its construction is put under a test to check its functionality. If there are any errors then they will surface at this point of the process.

•           Integration: in the phase of Integration, the company puts it in use after the system has been successfully tested.

 •           Management and Maintenance: Maintenance and management is needed to ensure that the system will continue to perform as desired.

Through the above mentioned steps it is clearly shown that the Waterfall model was meant to function in a systematic way that takes the production of the software from the basic step going downwards towards detailing just like a Waterfall which begins at the top of the cliff and goes downwards but not backwards.

کد: 

Advantages of the Waterfall Model

Let’s look at some of the advantages of this model,

 •           The project requires the fulfillment of one phase, before proceeding to the next. Therefore if there is a fault in this software it will be detected during one of the initial phases and will be sealed off for correction.

 •           A lot of emphasis is laid on paperwork in this method as compared to the newer methods. When new workers enter the project, it is easier for them to carry on the work from where it had been left. The newer methods don’t document their developmental process which makes it difficult for a newer member of the team to understand what step is going to follow next. The Waterfall Model is a straight forward method and lets one know easily what stage is in progress.

 •           The Waterfall method is also well known amongst the software developers therefore it is easy to use. It is easier to develop various software through this method in short span of time.

کد: 

Disadvantages of the Waterfall Model

There are many disadvantages to the model as well. Let’s have a look at those,

 •           Many software projects are dependent upon external factors; out of which the client for which the software is being designed is the biggest factor. It happens a lot of times, that the client changes the requirement of the project, thereby influencing an alteration in the normal plan of construction and hence the functionality as well. The Waterfall Model doesn’t work well in a situation like this as it assumes no alteration to occur once the process has started according to plan.

If, for instance, this happens in a Waterfall Model, then a number of steps would go to waste, and there would arise a need to start everything all over again. Of course this also brings about the aspect of time and money which will all go to waste. Therefore this method will not at all prove to be cost effective. It is not even easy to take out the cost estimate of each step, as each of the phases is quite big.

There are many other software developmental models which include many of the same aspects of the Waterfall model. But unlike the Waterfall model, these methods are not largely affected by the outside sources. In the waterfall model, there are many different people working in the different phases of the project like the designers and builders and each carries his own opinion regarding his area of expertise. The design, therefore, is bound to be influenced; however in the Waterfall model, there is no room for that.

•           The other negative aspect of this model is that a huge amount of time is also wasted. For example if we study any software development process, we know that Phase II cannot be executed until Phase I has been successfully completed; so while the designers are still designing the software, time of the builders is completely wasted.

 •           Another disadvantage of this method is that the testing period comes quite late in the developmental process; whereas in various other developmental programs the designs would be tested a lot sooner to find the flaw at a time when a lot of time and money has not been wasted.

 •           Elaborate documentation during the Waterfall method has its advantages, but it is not without the disadvantages as well. It takes a lot of effort and time, which is why it is not suitable for smaller projects.

منبع + توضیحات بیشتر
در
مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.

حوزه دانش مهندسی نرم افزار در زمینه مدل ها و متدها:

مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.

یه توضیح خوب و اجمالی درباره خیلی از این موارد که اینجا گفته شده.

هر کاری راه داره از جمله مهندسی نرم‌افزار .
پس ما باید راه ساختن نرم‌افزار با کیفیت رو پیدا کنیم.

سوای از ماهیت خود نرم‌افزار چیزهای دیگه ای هم هستن که روی روش کار تاثیر میگذارن.

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

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

مهندسی نرم‌افزار پره از این روشها و اینکه هر کدوم کجا و بدرد چه جور کاری میخورن و چه جوری باید اجراشون کرد.
مهندس نرم‌افزار کسی یه که این روشها رو میشناسه و به نقاط قوّت و ضغف‌شون آشناست. میدونه کدوم روش کجا بدرد میخوره و کجا بدرد نمیخوره. اگر لازم شد یک روش رو یک کم تغییر میده تا با شرایط خاصی که باهش روبروست هماهنگ بشه و مهمتر از همه : میتونه اون روش رو اجرا کنه (نه اینکه تنها بلدشون باشه ! ).

خلاصه اینکه : روش و روش شناسی در مهندسی نرم افزار خیلی مهمه.
مهندسی نرم افزار چیزی نیست جر شناختن این روشها و توانمندی در بکار بستن اونها. هدف از این روشها اینه که نرم‌افزاری با کیفیت ساخته بشه.
چرا روشهای مختلف داریم؟ چون شرایط متفاوته! روشی که تو شرایط فلان خوبه شاید تو شرایط بهمان بد باشه.
اگر روش درست رو انتخاب کنید و بهش عمل کنید، نرم‌افزاری با کیفیت در زمان و هزینه‌ی مورد نظر بدست میاد و شما در واقع و براستی مهندسی کردید یعنی یک کار سخت و بزرگ!
واقعا سخت و بزرگ!

------------------------------------------
منبع :

مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.

و ادامه :

با اینکه مهندسی نرم‌افزار خیلی جوونه اما اینقدر پیچیدگی و نکته داره که هنوز هیچ چی نشده کلی نکته و نظریه و تز و از این جور چیزها درباره‌ی روش‌های ساخت نرم‌افزار وجود داره.

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

اما این تنها ظاهر قضیه است !

باطن قضیه اینه که :

همه‌‌ی روشهای مهندسی نرم‌افزار در حقیقت دارن روی یک سری نکات مشخص و مشترک تاکید میکنن و همشون دارن یک حرف رو به زبون‌های متفاوت میزنن. همه‌ این روشها در پایان از یکسری ارزشهای یکسان دفاع می‌میکنند و یک هدف (تضمین کیفیت) رو به روشهای متفاوت دنبال میکنند.

بهترین راه مهندس نرم‌افزار شدن اینه که این مشترکات و ارزشها رو بشناسیم و یادمون باشه توی همه روش‌ها (که خواهیم خواند) مشترک هستن.

اگر این نقاط مشترک رو درست بفهمیم و درک کنیم کارمون درسته و هر روشی رو بسادگی یاد میگیریم و بهش مسلط میشیم و میتوینم اجراش کنیم. من میتونم این مشترکات (که توی این بحث ما بهش میگن : «فاز») رو به ریخت تکی و بیرون از هر روشی و به اصطلاح مجرد و انتزاعی براتون بگم اما کار خیلی سخت میشه. بهتر اینکه که یکی از روشهای خیلی ساده رو گزینش کنیم و این فازها رو توی دل اون روش بشناسیم. سپس خواهیم دید که این فازها در همه روشها هستن تنها شکل و زمان ظاهر شدن و روش انجامشون تفاوت داره. این فازها شالوده و عنصر سازنده همه روشها و فرآیندهای نرم‌افزاری هستن (فرآیند همون روشه). همیشه و همه جا اینا رو میبینین .

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

-------------------------------------------
منبع + مطالب بیشتر :

مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمی‌باشید. جهت مشاهده پیوندها ثبت نام کنید.

(10 اردیبهشت 1391 04:23 ب.ظ)Ferestadeh نوشته شده توسط: [ -> ]البته متدولوژی ها زیاد هستند . (در مانشت مطلبی زیبا از دکتر خوندم که به تعداد مهندسین نرم افزار می شه روش داشت.متدولوژی روش انجام هر کاری است. و هر کسی می‌تونه به یه شکل یه کار رو انجام بده. معمولاً نمونه‌های موفق و شرکت‌های بزرگ این متدولوژی‌ها رو می‌سازند و تجربه موفقی پشتشون هست. )

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

بچه ها کسی در مورد design pattern چیزی میدونه واینکه تقسیم بندی مدل ها (مدلهای ساختاری وسازنده و مدلهای رفتاری )چیه و چه تفاوتی با فازهای و دیسیپلینهای uml داره ؟ احتیاج به کمک دارم ..

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

(19 مهر 1391 03:52 ب.ظ)aryaeei نوشته شده توسط: [ -> ]بچه ها کسی در مورد design pattern چیزی میدونه واینکه تقسیم بندی مدل ها (مدلهای ساختاری وسازنده و مدلهای رفتاری )چیه و چه تفاوتی با فازهای و دیسیپلینهای uml داره ؟ احتیاج به کمک دارم ..

الگوهای طراحی راه حل های متداولی هستند که برای حل یه سری مشکلات متداول در طراحی معرفی شدند. تعدادشون خیلی زیاده ولی با یه جستجوی ساده در اینترنت می تونید خیلیاش رو پیدا کنید.
مدل ها بر سه نوع هستند. مدل های ساختاری که میان ساختار سیستم رو در سطوح ریزدانگی مختلف نشون میدن مثلا در سطح کامپوننت، سیستم و ...
مدل های رفتاری هم بیانگر رفتار سیستم در سطوح مختلف هستند. مثل تراکنش های مختلفی که با هم دارن
UML فاز نداره! UML یک زبان مدل سازی هست که یک سری مدل داره. هر کدوم از مدل ها هم می تونن جزو اون دسته مدل هایی که در بالا اسم بردم دسته بندی بشن. یه سری دیاگراماش رفتاری، یه سری ساختاری و ... هستند
اون چیزی که فاز داره متدولوژی های ایجاد نرم افزار هست که در هر متدولوژی معمولا از یک زبان مدل سازی مثل UML استفاده میشه.

(20 مهر 1391 03:04 ق.ظ)لاله عباسی نوشته شده توسط: [ -> ]آبشار چه ویژگی داره؟یا مثلا حلزون چه ویژگی داره که مثلا اسم یه مدل میشه مدل حلزونی یا آبشاری؟ یعنی بین انتخاب این اسمها با مدل مربوطه چه ارتباطی است؟یا مثلا مدل افزایشی چی افزایش پیدا میکنه؟اگه در اولین مدل افزایشی نیازهای اصلی در نظر گرفته میشه پس چه ضرورتی به ارائه نسخه های بعدی هست؟نیازهای غیر اصلی چی هستند ؟اآیا نیازهای غیر اصلی یا شاید بشه گفت نیازهای ثانویه مهم هستند ؟من فکر میکنم مدل افزایشی وقتی بکار میره که قرار باشه نیازی رو در جامعه ایجاد کنیم مثلا مثل نرم افزارهای افیس .آیا کسی سفارش این محصولو داده بود یا نه خود مایکروسافت خواسته که این محصول رو تولید کنه.و طبق بازخورد مشتری ها هربارنرم افزارکاملتری ارائه میده .شاید به همین دلیله که گفته میشه در مدل افزایشی مشتری دخالت مستقیم نداره چون این کار هزینه بره.میشه تغیری در درس مهندسی نرم افزار داد؟مثلا در همین تاپیک همه دوستان زحمت کشیدن دوباره منابعی رو که میشه با یه سرچ پیداکرد رو دوباره مطرح کردن .بهتر نیست برداشت خودتونو با عبارات و کلماتی فارغ از جزوه استاد محترم ، بفرمایید.من برای این درس چقدر دنبال کتابی گشتم که توش پر از مثال از مدلها باشه ولی پیدا نکردم دوتا کتاب خریدم متن هر دو کتاب خیلی مثل هم بود .از استاد راهنمایی خواستم گفتند:از این کتابا پیدا نمی کنی،نگرد.البته من که خودم توانایی بالای علمی ندارم ولی خوب گفتم به عنوان دانشجویی که خیلی به این نوع کتابای پر از سوال نیاز داره ، پیشنهاد داده باشم .ان شاءاله که استاد شدید بیشتر دانشجوهارو راهنمایی کنید.

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

(09 تير 1391 12:58 ب.ظ)akfe نوشته شده توسط: [ -> ]
(10 اردیبهشت 1391 04:23 ب.ظ)Ferestadeh نوشته شده توسط: [ -> ]البته متدولوژی ها زیاد هستند . (در مانشت مطلبی زیبا از دکتر خوندم که به تعداد مهندسین نرم افزار می شه روش داشت.متدولوژی روش انجام هر کاری است. و هر کسی می‌تونه به یه شکل یه کار رو انجام بده. معمولاً نمونه‌های موفق و شرکت‌های بزرگ این متدولوژی‌ها رو می‌سازند و تجربه موفقی پشتشون هست. )

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

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

- rasool -

hamidkhl

sepid

- rasool -

- rasool -

luna

- rasool -

- rasool -

akfe

aryaeei

لاله عباسی

luna