فکر کنم یه نفر قرار بود راجع به
BPR,BPE,JSD,OMT,OOSE,ROOM,RIPLE
یه چیزایی بنویسه؟

Myth: "Software Engineering is the same as Software Development"

This is possibly the most common misconception people carry regarding the profession of a Software Engineer. What is more surprising is that significant proportion of the industry and many fresh graduates hold this relation. Software Engineering, Software Development, Software Development Engineering, Programming, and Coding are all terms frequently misused to describe more-or-less a single concept. Software Development, like housing development, is a broad term describing various engineering, management, and both creative aswell as asinine activities and their interactions; it could be a precisely calculated endevaour or an ad-hoc attempt yet still fit under this generalized term. Software Development Engineers build the software or its components. They are the logicians. At a deeper level, various expertise come into play. Algorithm design and analysis, artificial intelligence techniques, performance optimization, testing, and even requirements management are just a small subset of specialties required in software development.

Software Engineering on the other hand, forms the practice of managing complexity in software development. This is a subtle, yet critical, concept. Here, there is an implicit notion that the aim of software development activity is to achieve perfection with respect to certain criteria. That criteria is most commonly the //input// or output of a software development task. The //input// being resources exerted on the task, and output being the quality attributes exhibited by the result of the task. A reasonable case could be the following list: 'quality' w.rt explicit requirements (defined in some metric), effort or cost, desired degree of non quantifiable quality drivers such as overall performance, security, maintainability, readability, portability, usability etc. It is only because of complexity in the task at hand that some or more of the perfection criteria may not be met. In fact, as most architects will advise, there is generally a trade off between non-orthogonal quality attributes. Software Engineering theories, tools, and practices are aimed at managing complexity such that i) a higher degree of quality attributes can be achieved for a given complexity of software development task, or ii) that same degree of quality attributes can be achieved while accommodating a more complex software development task.

Clearly, the task at hand of a software development engineer and a software engineer (two hats often worn by the same person) are disparate; yet rely on each other. Why the distinction may not appear clear is because of relative immaturity of the field.

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

https://www.thedacs.com/
ای کاش از همون اول کتاب (pressman), این لینک رو معرفی می کرد. عجب چیز باحالیه!

کتاب
the one minute manager
رو حتما یه نگاهی بهش بندازین!
حداقلش اینه که مثل کتاب pressman نیست که بعد از خوندنش آدم سرش گیج بره!

People Capability Maturity Model (P-CMM) Version 2.0

چه جالب! من اتفاقا می خواستم تو پروژه ام در مورد مهندسی مجدد(BPR) و مهندسی معكوس هم بنویسم ولی انقدر عجله داشتم برای فارغ التحصیلی(؟؟) كه بی خیالش شدم!

ولی مباحثش خیلی جالب و شیرینه!   

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

ویرایش:  دانلود متن کامل مقاله  مهندسی مجدد (حجم:KB 157 )

پیام در تاریخ 86/2/3 ویرایش شده است.

IBM software suits
www-306.ibm.com/software/rational/offerings/design.html
شش تا بخشه. این یکیشونه. پنج تای بقیه رو می تونید از همون بالا انتخاب کنید.

http://www.nofa.ir/SubjectsInForum-ForumID16.aspx

dare zemn az bahsaye elmi va ghashange shoma motshakeram

man ham matalebe jadid amookhtam

dar zemn age mishe in bahsa ra dar danesh_kadeh va dar yek hamayesh danesh_jooiee sazmandahi koni

albate yek pishnahad ast

bye

ba salam

dar morede exterme programming ke dar vaghe yek methology sabok vazn ast dar soalate miyan terme se1 injaneb dar termhaye ghabl kamel tozih dadeh shodeh

 

ممنون آقای احمدی.
می تونید جوری از این بحث هایی که در مورد RUP می کنید مثال بزنید, تا بشه اون رو درک کرد؟

با کلی مصیبت Rational Method Composer رو از اینترنت گرفتم ولی نصب نمی شه error می ده.
این installation log اون هست


(Mar 18, 2007 5:43:47 PM), Install, com.installshield.wizard.platform.win32.Win32RegistryUpdate, err, An error occurred and product installation failed.  Look at the log file C:\Program Files\IBM\Rational\SDP\Rational Method Composer 7.0\rmc_install.log for details.
(Mar 18, 2007 5:43:47 PM), Install, com.installshield.wizard.platform.win32.Win32RegistryUpdate, err, ProductException: (error code = 601; message="The system cannot find the file specified.
 (2)  Error on line 3")
STACK_TRACE: 13
ProductException: (error code = 601; message="The system cannot find the file specified.
 (2)  Error on line 3")
    at com.installshield.wizard.platform.win32.Win32RegistryUpdate.install(Unknown Source)
    at com.installshield.product.service.product.PureJavaProductServiceImpl.installProductAction(Unknown Source)
    at com.installshield.product.service.product.PureJavaProductServiceImpl$InstallProduct.getResultForProductAc
tion(Unknown Source)
    at com.installshield.product.service.product.Installable//Object//Visitor.visitComponent(Unknown Source)
    at com.installshield.product.service.product.Installable//Object//Visitor.visitInstallableComponents(Unknown Source)
    at com.installshield.product.service.product.Installable//Object//Visitor.visitProductBeans(Unknown Source)
    at com.installshield.product.service.product.PureJavaProductServiceImpl$InstallProduct.install(Unknown Source)
    at com.installshield.product.service.product.PureJavaProductServiceImpl$Installer.execute(Unknown Source)
    at com.installshield.wizard.service.AsynchronousOperation.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:568)

کسی تا حالا اینو نصب نکرده؟؟

فکر نمی کنم به کار بردن واژه methodology برای RUP درست باشه. مخصوصا که چیزهایی که شما گفتید بیشتر در مورد مدل فرایند (process model) بود تا methodology.
واقعا این RUP چیه!
خب بد نیست یه دور مدل های فرایند (یا همون process model) ها رو بررسی کنیم.

waterfall یا همون linear sequential که فازهای مختلفی در نظر گرفته می شه که باید به صورت پشت سر هم انجام بشوند و با انجام و اتمام هر فاز, به سراغ فاز بعدی می رویم.
analysis - design - implementation - test - maintenance
(البته فکر کنم همینا بود. دقیقا یادم نمیاد اون دو تای آخری رو درست نوشتم یا نه. ضمنا یه دونه از استادنماهای دانشگاه هم یه دونه investigation اول این موارد اضافه کرده بود که من تو کتاب مهندسی نرم افزار ندیدم. حالا این رو هم در نظر داشته باشیم شاید یه موقع مفید واقع شد...)

prototyping
در این مدل, سه فاز وجود داره (که اسمشون یادم نیست,) که اول یه چیزی شبیه analysis انجام می دیم, بعد می ریم سراغ implementation و در نهایت مشتری نمونه (منظور همون ماکت هست) محصول رو امتحان می کنه.
در این مدل, نمونه های تولید شده قابل استفاده نیستند, بلکه فقط برای اینکه مشتری درکی از محصول داشته باشه و بتونه نیازهای برآورده نشده خودش رو پیدا کنه و ما بتوانیم در محصول نهایی هم اونها رو در نظر داشته باشیم, نمونه ها رو درست می کنیم. (نمونه منظورم همون prototype هست.)
عیب این مدل هم این است که ممکنه مشتری وقتی ببینه نمونه کارهای مورد نظرش رو انجام می ده, از پرداخت هزینه اضافه برای انجام محصول نهایی صرف نظر کنه و به این موضوع توجه نکنه که فقط یک prototype تولید شده و این prototype اصلا با محصول نهایی قابل مقایسه نیست.

در مدل های evolutionary که به نوعی ترکیبی از prototyping و waterfall model هست, محصول نهایی در یک بار iteration (یا به قول آقای احمدی, تکرار) تولید نمی شود. بلکه محصول نهایی حاصل چندین بار تکرار است.
(و این مدل ها معمولا با نیازهای واقعی مشتریان بیشتر سازگار است. نیاز ها تغییر می کنند. نرم افزار ها باید تغییر کند...)

incremental model
که در هر iteration محصول اولیه ای تولید می شود و بار هر iteration بعدی امکاناتی به محصول اضافه خواهد شد (یا از اشکالات آن کم می شود)
فرق این مدل با waterfall در این است که در waterfall فقط یک بار iteration (یا همون تکرار) داریم, و همچنین در prototyping هم در هیچ کدام از تکرار ها محصول قابل استفاده ای تولید نمی شود, و محصول نهایی پس از چند بار تکرار و بررسی اشکالات نمونه تولید خواهد شد. در حالی که در این مدل, بعد از هر iteration, محصول قابل استفاده ای خواهیم داشت که مشتری می تواند از آن استفاده کند و هر تکرار بر محصول تولید شده از تکرار قبلی متکی است.
(یکی از نکاتی که متوجه نشدم این بود که در نمودار این مدل, design در iteration دوم, بلافاصله بعد از anlysis در iteration اول رخ می داد.
اما تا جایی که از متن توضیحات فهمیدم, iteration دوم بعد از اتمام کامل اولین iteration شروع می شود.
از مثالی هم که زده بود (که از موارد نادر مثال در این فصل بود ) همین موضوع فهمیده می شد.
؟؟؟؟؟؟؟؟)

spiral model
اگر فقط به نمودار ها توجه کنیم, اصلا شباهتی بین مدل های فرایند نمی بینیم! اما اگر واقعا بخواهیم به درک موضوع برسیم, باید به شباهت ها و تفاوت های خود مدل ها توجه کنیم.
بدون توجه به نمودار ها شاید به نظر برسد که spiral model هیچ گونه شباهتی با incremental model ندارد.
اما فرقی که این دو مدل دارند (البته تا جایی که من فهمیدم!) این است که در incremental model از همان اولین iteration ما محصول قابل استفاده ای خواهیم داشت.
اما iteration های اولیه در مدل spiral ممکن است منجر به تولید محصول قابل استفاده نشود و فقط design از محصول آماده بشود. و محصولی که مشتری بتواند از آن استفاده کند پس از دو یا سه iteration تولید می شود و iteration های بعدی برای ارتقای محصول و همینطور رفع عیب آن و ایجاد تغییرات باشد.

winwin spiral model
خداییش اینو نفهمیدم!
اصلا متوجه نشدم این مدل مال process model بود یا اینکه مدل یک قسمت از spiral model یعنی قسمت customer communication بود. یا اصلا یه چیز دیگه ای بود!
من که متوجه نشدم چی بود! ولی حرفش این بود که developer و customer در یک جایی بین میزان هزینه ای که مشتری می پردازد و امکاناتی که developer در نرم افزار قرار می دهد به توافق برسند. win win .

formal model
که در این مدل از ریاضیات برای مدل سازی استفاده می شود. استفاده از این مدل باعث می شود که همه ی جوانب در نظر گرفته بشود و محصول نهایی بر اساس مدل ریاضی به کار گرفته شده عاری از هر گونه عیبی باشد.
ولی عیب هایی هم دارد که
اولا هزینه (مالی و زمانی) اون بسیار بسیار بالاست.
دوما به علت عدم آشنایی مهندسین نرم افزار, احتمالا نیاز به اموزش اضافه ای دارند تا بتوانند در این مدل کار کنند. (مخصوصا اگر از دانشگاه آزاد ساری فارغ التحصیل شده باشند!!)
سوما اون رو یادم نیست.

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

مدل 4GT رو که دانشجوهای دانشگاه ما کاملا با اون آشنا هستند!

و مدل component- based development که به خصوص برای ////object////- orientation ...... (فعل گیر نیاوردم!)
که باعث می شود استفاده از component هایی که قبلا تولید کرده ایم و در library ذخیره شده اند هزینه های تولید نرم افزار رو به شدت کم کند.

(این آخراش رو دیگه خسته شدم. ضمنا شما بحث مهندسی نرم افزار رو ول نکنید. اما من فعلا می رم سراغ جاوا. دوباره بر می گردم...
راستی من اگر بخوام java و RUP رو با هم یاد بگیرم باید چه کاری انجام بدم؟ (شاید خودم مجبور بشم به این سوال جواب بدم! )


پیام در تاریخ 85/12/25 ویرایش شده است.

خیلی خوب بود پ. ناشناس . مرسی . خیلی چیزها آموختیم ;)

موفق باشید .

JAD یا همون Joint Application Development
به طور خیلی خیلی خلاصه این هست که کسانی که از نرم افزار استفاده می کنند رو هم در توسعه نرم افزار وارد کنیم. چون هیچ کسی بهتر از خود اونها نیازشون رو نمی دونن. اینو بخونید بهتر از من می دونه. زیاد هم نیست:
http://en.wikipedia.org/wiki/Jad

در مورد RUP هم سعی کردم با خوندن صفحه ی اون در wikipedia:
http://en.wikipedia.org/wiki/Rup
بفهمم موضوع چیه و حداقل ابهام اون برطرف بشه.
راستش می تونم بگم تقریبا هیچ فرقی با قبل از نگاه کردن به این صفحه نداشت!

هیچ مبحثی در دوران دانشجویی به اندازه مهندسی نرم افزار برام مبهم نبود! و هیچ کتابی سنگین تر از کتاب مهندسی نرم افزار pressman.
بعضی وقتها دو سه صفحه رو همینجور بدون اینکه بفهمم قضیه چیه می خونم تا بفهمم آخرش راجع به چی داشت صحبت می کنه.
گاهی اوقات هم از کلماتی استفاده می کنه که تو همون فصل, دو سه تا معنی مختلف رو با همون یک کلمه بیان می کنه.
تازه خدا می دونه چی چیزهایی تو کتاب بود که من نفهمیدم!
از اساتید گرامی (یا استاد گرامی) که در این زمینه اطلاعات دارند خواهشمند(ی)م  یه مقداری توضیح بدن یا یک کتاب مناسب معرفی کنن که بشه همراه کتاب pressman خوند تا از مباحث اون سر درآورد.
(و همینطور یک کتاب مناسب در رابطه با RUP. چون کسی که نمی دونه این چی هست, نمی تونه کتاب مناسبی انتخاب کنه.!)

فکر می کنم دلیل عمده مبهم بودن قضیه استفاده نکردن از مثال در مباحث هست. (یا در واقع عدم امکان استفاده از مثال در مباحث هست..)