A further complication is the fact that, for industrial-strength software, there are typically a large number of stakeholders who shape the development process, most of whom are completely unimpressed by the underlying technology for technologies sake. These stakeholders will bring to the table a multitude of hidden and not-so-hidden economic, strategic, and political agendas that often warp the development process through the presence of competing concerns.

For software that matters, the requirements of a system will typically change during its development, not just because of reasons of technology churn or resilience, but also because the very existence of a software development project alters the rules of the problem.
Seeing early products such as design documents and prototypes and then using a system at each executable release are all forcing functions that lead users to better understand and articulate their real needs.

At the same time, this process helps developers master the problem domain, enabling them to ask better questions that illuminate the dark corners of a system’s desired behavior.

Because a large software system is a capital investment, we cannot afford to scrap an existing system every time its requirements change (or for that matter, to absorb considerable amounts fo scrap and rework).

Planned or not, large systems tend to evolve continuously over time, a condition that is often incorrectly labeled software maintenance. To be more precise, it is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation. Unfortunately, experience suggests that an inordinate percentage of software development resources are spent on software preservation.

گزیده:

Will you love me for the rest of my life?
No, I’ll love you for the rest of mine. – From Phenomenon

Consider the requirements for the avionics of a multi-engine aircraft, a cellular phone switching system, or an autonomous robot. The raw functionality of such systems is difficult enough to comprehend, but now add all of the (often implicit) nonfunctional requirements such as usability, survivability, and adaptability, indeed, all of the forces that shape a system. These unrestrained, potentially contradictory, external requirements are what amplify the arbitrary complexity ….
This external complexity usually springs from the “impedance mismatch” that exists between the users of a system and its developers: users generally find it very hard to give precise expression to their needs in a form that developers can understand. In extreme cases, users may have only the vaguest ideas of what they want in a software system.

Moreover, developers may not even know exactly the expectations of its user base, especially in the case of emerging, rapidly changing markets.

This is not so much the fault of either the users or the developers of a system; rather, it occurs because each group generally lacks expertise in the domain of the other. Users and developers have different perspectives on the nature of the problem and make different assumptions regarding the nature of the solution.

Actually, even if users had perfect knowledge of their needs, it is intrinsically difficult to communicate those requirements precisely and efficiently.

At one extreme, the development team may capture requirements in the form of large volumes of text, occasionally accompanied by a few drawings. Such documents are difficult to comprehend, are open to varying interpretations, and too often contain elements that are designs rather than essential requirements.

At the other extreme, there will be no stated requirements, only general visions and some specific stories, all retained in the heads of the developers. This may work for exploratory development or ultra-lightweight projects, but it is absolutely impossible to manage a development process against invisible requirements.

گزیده:

A life without love, is no life at all.
– “Ever After: A Cinderella Story”

The difficulty of design, therefore, lies in choosing which design and architectural patterns we should use to best balance the technical, economical, business, political, and emotional forces that swirl around every software-intensive system. To put it in terms of the laws of software, this general problem of design is probably NP-complete: there likely exists some absolutely optimal design for any given problem in context, but pragmatically, we have to settle for good enough. As we as an industry gain more experience with specific genres of problems, then we collectively begin to understand a set of design and architectural patterns that are good enough and that have proven themselves in practice for each particular domain. Thus, designing a new version of an old kind of system is easier, because we have some idea of how to break it into meaningful parts. However, designing a new version of a new kind of system with new kinds of forces is fundamentally hard, because we really don’t know the best way to break it into meaningful parts. The best we can do is to create a design based upon past experiences, plagiarize from parts that worked in similar kinds of situations, and iterate until we get it good enough.

Reference: The Limits of Software, Grady Booch, IBM Fellow, September 2004

گزيده:

“Let our advance worrying become advance thinking and planning.” –
Winston Churchill

Barry Boehm در سخنرانی‏ای با عنوان نگاهی به مهندسی نرم‏افزار در قرن بیستم و بیست و یکم، مطلبی با عنوان چالشهای پيش رو در آموزش مهندسی نرم‏افزار به نکات جالبی اشاره می‏کند.
– به روز نگهداشتن مستمر و مداوم مطالب آموزشی
– پيش‏بينی جهت‏گیری‏های آینده و آماده‏سازی دانشجويان برای آن
– جداسازی اصول لاتغيير از تجربه‏ها و آموخته‏ها
– متناسب‏سازی پروژه‏های کوچک دانشجویی با نيازهای بزرگ و پيچيده صنعت
– انجام و یا مشارکت در انجام تحقيقات و ارائه نتايج آنها در دوره‏های آموزشی
– کمک به دانشجويان برای آن که ياد بگيرند چگونه ياد بگيرند.
– آموزش مداوم‏شاغلان صنعت

فکر می‏کنيد خلأ کداميک از نکات اشاره شده در آموزش فعلی مهندسی نرم‏افزار در کشورمان به چشم می‏خورد؟ منتظر پاسختان هستم (شايد بهتر باشد در اين مورد مباحثاتی داشته باشيم).

گزيده:

There are three types of people in this world: those who make things happen, those who watch things happen and those who wonder what happened.
– Mary Kay Ash

از هفته ديگر دوره Rational Unified Process در شرکت فراتر از دانش شروع می‏شود. يکی از موضوعاتی که می‏خواهم تأکيد بيشتری روی آن داشته باشم، CMMI است. اين امر بهانه‏ای شد تا در این مورد مطلبی بنويسم که در ادامه آمده است.

موضوع خيلی ساده است: «کيفيت سيستم يا محصول به شدت تحت تأثير فرآيندی است که برای توسعه و نگهداری آن به کار گرفته شده است». انستيتو مهندسی نرم¬افزار دانشگاه کارنگی ملون (CMU-SEI به اختصار SEI) طرح مدلهای بلوغ قابليتها را با اعتقاد به اين اصل شروع کرد. نتيجه آن چندین مدل بلوغ قابليت بود که از سال 1991 به بعد تهيه شدند مانند
• SW-CMM(Software Engineering CMM)
•Systems Engineering CMM (SE-CMM)
•People-CMM
نکته‏ی حائز اهميت آن است که پروژه‏ها تحت تأثير سه عامل (People, Process, Tools) هستند که SEI سعی کرد در حوزه‏های ديگر غير از فرآيند نيز مدلهايی ارائه دهد.
تنوع و تعدد مدلها (علاوه بر مدلهای CMM، مدلهای ديگری نيز در صنعت وجود داشت) باعث بروز مشکلاتی شد که طرح مدل بلوغ قابليتهای يکپارچه Capability Maturity Model Integrated یا به اختصار CMMI، برای حل مشکل مذکور پيشنهاد و از سال 1997 شروع شد واولين نسخه آن در سال 2000 انتشار پيدا کرد.
در حقيقت انگيزه SEI از توسعه CMMI ارائه مدل بلوغ قابليتی برای پوشش کارهای مرتبط با توسعه و نگهداری محصول و سرويس که شامل حوزه‏های زير بوده و قابليت گسترش به حوزه‏های جديد را نيز داشته باشد، بود.
-مهندسی سيستم(Systems engineering)
-مهندسی نرم‏افزار(Software engineering)
-توسعه محصول و فرآيند يکپارچه (Integrated product and process development)
-تأمين منابع (Supplier sourcing)
صرف نظر از اين که مدل ارائه شده از ديدگاه تخصصي چه ويژگی‏هايي دارد، چارچوبی را برای بهبود فرآيند توسعه و نگهداری محصول و سرويس در سازمانها ارائه می‏دهد. به عنوان مثال يکی از حوزه‏های فرآيندی که بايد برای بهبود سازمان در نظر گرفت مديريت پيکربندی (Configuration Management) است که مفيد است اگر تعريف آن را با هم مرور کنيم.
هدف:
هدف از مديريتپيکربندی، شناسايی، کنترل و مميزی محصولات کاری و نگهداری يکپارچگی آنها است.
از جمله محصولات کاری می‏توان به موارد زير اشاره کرد:
•طرحها (Plans)
•نيازمندی‏ها (Requirements)
•کدهای برنامه (Code)
•طراحی‏ها (Design)
برای روشن شدن کاربرد، اجازه بدهيد مثالی عرض کنم. فرض کنيد که قرار است نامه‏ای برای يکی از مشتريان ارسال شود. ابتدا نامه توسط کارشناس، تهيه، سپس توسط مدير عامل تأييد و سپس توسط مسئول دفتر مديريت، ويراستاری، ثبت و پرينت می‏گردد. واضح است که نامه بين مدير، کارشناس و مسئول دفترمديريت چندين بار جابه‏جا گرديده تا به نسخه نهايی تبديل گردد. از طرف ديگر پس از ارسال نبايد تغيير کند. آيا نسخه¬های بينابينی (نسخه‏هايی که بين مدير، کارشناس و مسئول دفتر جابه‏جا شده است)، بايد نگهداری گردد(شناسايی و تعيين اقلام پيکربندی). در صورتی که جواب مثبت است، چگونه اين کار را انجام دهيم؟ چه کسانی مسئول کار باشند؟ (فرآيند پيکربندی) چه کسانی حق دسترسی به نامه پس از ارسال يا نسخه‏های ميانی را داشته باشد (ضوابط فرآيند پيکربندی).
سئوال مهم‏تر اين است که آيا چارچوبی برای مشخص کردن نيازهای يک سازمان يا پروژه برای نگهداری اقلام تحت کنترل (اقلام پيکربندی) وجود دارد؟ آيا مرجعی بری کارهايی که بايد انجام دهيم تا اقلام پروژه تحت کنترل باشند، وجود دارد؟ يکی از جوابها و مراجع معتبر، CMMI و حوزه فرآيندی Configuration Management آن است.

توجه داشته باشيد کهCMMI تنها يک مدل است و نه راهکار اجرایی. بلکه بايد متناسب با هر سازمان، پياده‏سازی و عملياتی گردد.
پرواضح است که بيان تمامی ابعاد و کاربردهای CMMI در اينجا ميسر نيست، لذا توصيه می‏شود برای اطلاعات به آدرس http://www.sei.cmu.edu/cmmiمراجعه نماييد.

گزيده:
لغت نامه مهندسين در جلسات كارفرما
كاملا انجام شده يعنى: راجع به 10 درصد كار تنها برنامه ريزى شده !
تمام انتخاب اوليه به كنار گذاشته شد. يعنى: تنها فردى كه اين موضوع را مى فهميد از تيم خارج شده است!
روى چند انتخاب بطور همزمان در حال كار هستيم. يعنى: هنوز تصميم نگرفته ايم چه كنيم!

the OMG Systems Modeling Language (OMG SysML) is a general-purpose modeling language for systems engineering applications.SysML supports the specification, analysis, design, verification and validation of a broad range of complex systems. These systems may include hardware, software, information, processes, personnel, and facilities.
The origins of the SysML initiative can be traced to a strategic decision by the International Council on Systems Engineering’s (INCOSE) Model Driven Systems Design workgroup in January 2001 to customize the Unified Modeling Language (UML) for systems engineering applications.
Currently it is common practice for systems engineers to use a wide range of modeling languages, tools and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers.
SysML reuses a subset of UML 2.1 and provides additional extensions needed to address the requirements in the UML for System Engineering.

گزیده:

Do you know that place between being asleep and awake, where you still remember your dreams? Thats where I’ll always love, that’s where I’ll always wait for you.
– Tinkerbell (Hook)

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

گزیده:
خدایا چنان کن سرانجام کار تو خشنود باشی و ما رستگار