سند تحلیل زنده بسازیم

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

سند تحلیل از دیدگاه رویکرد چابک

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

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

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

تحلیل مبتنی بر تست

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

اجزا سند تحلیل زنده

با این مقدمه ساختار پیشنهادی برای یک سند تحلیل زنده با فرض اینکه در تولید نرم افزار از رویکرد Agile و BDD به صورت همزمان استفاده می شود  به شکل زیر است:

اپیک  : ویژگی های سیستم (Features) را می توان با عنوان اپیک (Epic) نامگذاری کرد. به عنوان مثال یک فرایند سیستمی می تواند یک اپیک باشد.

داستان کاربر (User Story) : بابت هر اپیک، یک یا چند داستان کاربر با فرمتی که در متدولوژی چابک بیان شده نوشته می شود. به عنوان مثال در یک فرایند هر یک از گام های فرایند می تواند یک داستان کاربر باشد.

As a < type of user >, I want < some goal > so that < some reason >

سناریو تست (Test Scenario): مورد دیگری که باید اضافه شود تعریف سناریوهای تست است . هر چند در داستان کاربری تحت عنوان  Acceptance Criteria می توان سناریوهای تست را مستند کرد، اما در رویکرد BDD آنها به صورت ساخت یافته نوشته می شوند و قابلیت ایجاد تست خودکار بر مبنای آن وجود دارد. این سناریوها، در واقع توصیف دقیق تر اتفاقی هستند که به لحاظ کسب و کاری در هر داستان کاربری باید در سیستم رخ دهد و قابلیت تست خودکار نیز داشته باشد.

برای این کار از یک زبان ویژه استفاده می کنیم. زبانی به نام Gherkin. کلیت یک سناریو تست در این زبان به شکل زیر است :

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

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

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

هر چند می توان مدل داده مفهومی سیستم را نیز در سند تحلیل اضافه کرد، اما به دلیل عدم اتصال این مدل به بخش طراحی در ادامه فرایند تولید سیستم، این بخش زنده نخواهد ماند و شاید بهتر باشد از ابتدا سراغ آن نرویم!

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

جمع بندی

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