ارزش نقش ارتباط رسانهای فنی در توسعه سیستم های اطلاعاتی

ارزش نقش ارتباط رسانهای فنی در توسعه سیستم های اطلاعاتی
چکیده: طیف نقشهای اجرا شده توسط ارتباط رسانهای فنی در فرآیند توسعه سیستم ها شناسایی شده و براساس یک تحقیق توسط ارتباط رسان های فنی استرالیایی در سال 1997 منتشر شد. تحقیق موردی پس از آن بررسی توسعه 20 سیستم اطلاعاتی جدید را انجام داد. هدف تحقیق، کمیت بخشی به مشارکت ارتباط رسانان منفی از دیدگاه بیرونی توسعه دهندگان و کاربران -این مقاله یافته های عمده از این تحقیق را شرح می دهد- نتایج، حاوی یافته های تحقیق 1997 است که در آن ارتباط رسانان فنی مشارکت مثبتی در توسعه سیستم های اطلاعاتی داشتند. نتایج به طور کمیتی نشان می دهد که کاربران به طور برجسته در جائیکه ارتباط رسانان فنی در فرآیند توسعه حضور داشتند.
اصطلاحات شاخص سیستم های اطلاعاتی ارتباط سازمان فنی
چرخه عمر توسعه سیستم های سنتی، نیاز به گزارش سازی کاربر را شناسایی کرده اما به طور کل نگارش این موضوع بر مراحل بعدی چرخه پیش از مرور دوباره سیستم و شروع دوباره چرخه، منتقل می کند مراجع مربوط به نقش ارتباط رسانان فنی به دلیل عدم حضور آنها در ادبیات سیستم های اطلاعاتی آشکار و واضح است. در ادبیات ارتباط فنی، وضعیت ارتباط رسانان فنی در سیستم های توسعه نیز به مقدار کم گزارش شده است. این تعجب برانگیز نیست بنابراین، توجه کم به حوزه حضور ارتباط رسان فنی در فرآیند توسعه سیستم و وقتی که این مشارکت حداکثر ارزش را دارد. داده شده است. کار اخیر با حمایت مالی انجمن ارتباط فنی با هدف نحوه عمل ارتباط رسانان در افزایش ارزش اجرا شده Redigh از این مطالعه گزارش می دهد که در حوزه تکنولوژی اطلاعات، کار ارتباط سازان فنی به کاهش هزینه های تعمیرات و نگهداری و زمان برنامه ریزی، هزینه های کمتر آموزشی و حمایتی و کاهش خطاهای کاربر منجر شد. مثالهای دیگری توسط ادبیات ارائه شده اند، که حمایت بیشتری را در مورد اینکه ارتباط رسانان فنی موجب افزایش ارزش فرآیند توسعه می شوند ، ارائه می کنند.
یک مقاله ای که زودتر در یک تحقیق ملی از ارتباط رسانان فنی گزارش شده هدف آن شناسایی نقش ارتباط رسانان فنی در توسعه سیستم های اطلاعاتی در استرالیا است. مقاله گزارش دادکه نقشهای زیر به طور وسیع توسط ارتباط رسانان فنی اجرا شده است.
– عمل به عنوان حامی کاربر
– نگارش کمک آنلاین
– نگارش وویرایش سیستم و پیامها و
– ارائه توصیه به طرح رابطه
این مسئله در دیگر مطالعات گزارش شده در ادبیات ارتباط فنی ثابت است که معتقدند ارتباط رسانان فنی مهارت اجرای نقشها را دارند.
نتایج تحقیق 1997 بیشتر از قبل نشان داد که برای حضور کارآمد ارتباط رسانان فنی و برای مشارکت آن با حداکثر ارزش، آنها باید در مرحله آغازین فرآیند توسعه حاضر شوند. و آغازین یعنی، پیش یا در مرحله طراحی- مقاله گزارش داد که 66% ارتباط رسانان فنی در پیش یا در مرحله طراحی حاضر شدند.
در حالیکه تحقیق می توانست به طور واضح شناسایی کند که نقشهای ارتباط رسانان فنی کدام است و در چه زمان آنها در فرآیند توسعه حاضر شده اند، نتایج جزئیات بیشتری را از نحوه مشارکت این نقشها یا افزایش ارزش در توسعه سیستم ها، خصوصاً از یک دیدگاه کاربر را ارائه نکرده اند- کار مطالعه موردی بیشتر برای شرح و ارائه جزئیات بیشتر تاثیر کار ارتباط رسان فنی طراحی شد.
روشها
کار تحقیق 1997 و تحقیق گزارش شده در اینجا بخشی از کار آرایه ای انجام شده از طریق مدرسه سیستم های اطلاعاتی دانشگاه Monash، ملبورن، استرالیا است. مطالعه موردی بررسی توسعه 20 سیستم اطلاعاتی را شامل می شد. نیمی از سیستمها در طول توسعه، یک ارتباط رسان فنی را حاضر کردند، که با سیستم های نوع A شناسایی می شدند و نیمی دیگر سیستم های نوع B بودند که از حضور آنها استفاده نکردند.
مصاحباتی با حدود 4 و 7 نفر برای هر سیستم انجام شده و توسعه دهنده کاربران و ارتباط رسان فنی را شامل می شود و هر جا که قابل کاربر بود ، مصاحبه با 90 نفر انجام شده و 40 ساعت از نوارهای ضبط شده جمع آوری می شدند.
برای تضمین اینکه یک ساختار مرتبط و ثابت برای جمع آوری اطلاعات حفظ شده بود. یک کتابچه درآغاز ایجاد شد که تمام پرسشهای، موضوعات گوناگون را شامل می شد، از مصاحبه شوندگان خواسته شد تا برخی بخشهای کتابچه را در طول مصاحبه کامل کنند. یادداشتهای اضافی یا مشاهداتی نیز در طول فرآیند مصاحبه در کتابچه ثبت شدند. اگر چه از مصاحبه شوندگان پرسش های مشابهی پرسیده شد، آنها به کیفیت بخشی شفاهی پاسخهای کتبی خود تشویق شدند، زمانیکه آنها پرسشهای کتابچه را پاسخ می دادند، پرسشهای دیگری هم مطرح شدند که نتیجه آنها داده های کمی و کیفی بود.
یک نمونه از کتابچه را می تواند در سایت زیر ببینید.
http//:www.manah.edu au/blsslab/j f protocol
روش تجزیه و تحلیل های مطالعه موردی
مصاحبه ها توسط 20 توسعه دهنده، 66 کاربر و 10 ارتباط رسان فنی انجام شدند. از متاماتریس ها برای تحلیل داده های کیفی استفاده شد، یک متاماتریس، طبق شرح Huberman, Miles ضرورتاً پیوند دو لیست است که با ردیفها وستونها تهیه شده است. متا ماتریس ها داده های مشروح برنامه ریزی نمودارهای اصل در یک فرمت استاندارد هستند- این روش یک ابزار دارای ساختار از طراحی نتایج کمی از لیست های اطلاعاتی از جمله اطلاعات مصاحبه را به دست می دهد.
از spss برای تحلیل آماری داده های کمی استفاده شد. تستهای جزر Chi برای اهمیت P<0.05 او تست T برای مقایسه ابزار استفاده شدند.
بحث در مورد یافته ها
کاربران و ارتباط رسانان فنی در اکثر موضوعات توافق داشتند. اما توسعه دهندگان اغلب جوانب سیستم های خود را در درجاتی بالاتر از کاربران، رده بندی کرونر – مورد زیر، ارائه دهنده نتایج بوده و براساس 4 نقش اصل ارتباط رسانان فنی سازمان یافته است، درک دیدگاه کاربر، نگارش کمک آنلاین، مشارکت در طراحی سیستم و رابط کاربر و پیغامهای خطا.

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

دیدگاه های کاربر:
به طور کل کاربران بهترین قضاوتها برای اکثر جوانب سیستم هستند، خصوصاً آنها که در این مقاله بحث شدند – به طور خلاصه، کاربران سیستم های نوع A، که در آن از ارتباط رسان فنی استفاده شده است، راضی تر بوده و در برابر کاربران سیستمهای برون ارتباط رسان فنی، موفق تر بوده اند. کاربران "کمک" آنلاین را در درجه بهتر رتبه بندی کرده و وقتی که یک ارتباط رسان فنی "کمک" را نوشته بود، استفاده بهتری از آن کردند. کاربران با رابطهای سیستمهای نوع A راحت تر بودند، اما متن پیغامهای خطا یک جنبه از سیستمهای بررسی شده بود که در آن ارتباط رسانان فنی کم بوده و تعجب آور نبود که کاربران به طور از کیفیت وضعیت سیستم و مقررات پیام خطا راضی نبودند.
رضایت کلی: یک تست کلیدی از تاثیرات یک سیستم، نظر کار بر نسبت به آن سیستم است. یک سری سوالات از کاربران پرسیده شد و با تعدادی گزارشات ارائه شد تا تعیین شود که آیا آنها به بهتر شدن سیستم خود درنتیجه حضور یک ارتباط رسان فنی عقیده داشتند- از کاربران سوالات زیادی پرسیده شد که آنها چقدر موفق بوده و چقدر از سیستم خود راضی بوده اند – دو سوال اول:
1- آیا سیستم موفق است؟
2- آیا از سیستم خود راضی هستید؟
از کاربران خواسته شد تا براساس یک مقیاس سه درجه ای پاسخ دهند- که پاسخها بدین شکل بود؛ بله(3)، خیر(1) نه بله ونه خیر(هیچکدام) (2) – یک تست آن نمونه با مقایسه میانگین های دو گروه اجرا شد . نتایج میانگین و انحراف میانگین (SD) در جدول 1 آمده اند.
نتایج دو پرسش اول نشان می دهد که رتبه بندی موفقیت کاربر میان دو گروه و در (P<0.05) و در 0.00041 مثل سطح رضایت در 0.0103 برجسته است.
دو پرسش دیگر مطرح شده:
3- میزان رضایت شما از سیستم چقدر است؟
4- میزان موفقیت شما در این سیستم در حوزه کاری خودتان چقدر است؟
هر دو پرسش لازم و داشت که کاربران براساس یک مقیاس 5 درجه پاسخ دهند، که در آن 1، خیلی ناموفق، یا خیلی ناراضی، 5 خیلی موفق و راضی.
این مسئله بیشتر از قبل نتایج سوالات 1 و2 را تایید کرد. جدول 2 نتایج را ارائه می کنند نتایج نشان داد که یک تفاوت آماری مهم در سطح رضایت کاربران از سیستم ها وجود داشت جائیکه یک ارتباط ساز فنی حاضر بوده است، سیستم های نوع A در مقایسه با نوع B مقایسه شده اند. همچنین یک تفاوت آماری مهم میان دو گروه در مورد سوالات موفقیت وجود داشت.
نتایجی را که می توان از نتایج این 4 سوال به دست آورد:
کاربران سیستم ها جائیکه یک ارتباط ساز فنی در طول فرآیند توسعه وجود داشته ، سیستم های خود را در رده موفق قرار دادند.
کاربران نسبت به گروهی که از حضور ارتباط ساز فنی استفاده نکرده بودند، رضایت بیشتری را در مورد سیستم خود نشان دادند.
به کاربران همچنین تعداد زیادی گزارش داده شد و از آنها خواسته شد تا براساس یک مقیاس 5 درجه ای سطح توافق یا عدم توافق خود را با هر یک از گزارشات اعلام کنند ( 5 مورد بسیار موافق و 1 مورد بسیار مخالف). جدول 3 ، یک مقایسه میانگین های میان کاربران سیستم نوع A و B را برای 8 گزارش و دو سوال کاربر نشان می دهد.
یک تست T دو نمونه ای، میانگین های دو گروه را در تمام موارد به جز آخرین گزارش، هیچ تفاوت آماری را نشان نمی دهد- کاربران سیستم هایی که از حضور ارتباط ساز فنی استفاده کرده بودند، به طور برجسته با رابط سیستم های خود راحت تر از کاربران بدون حضور رابط فنی بودند (2 تست پی در پی برای اهمیت )
تعداد سیستم های استفاده کننده از ارتباط ساز فنی، کلاً مسئول نگارش "کمک" آنلاین کم بود(4) اما کاربران این سیستم ها نسبت کیفیت "کمک" آنلاین را بالاتر از، "کمک" نوشته شده توسط دیگران اعلام کردند. میانگین "کمک" آنلاین نوشته شده توسط یک ارتباط ساز فنی 3.75 بوده و "کمک" آنلاین نوشته شده توسط دیگران 2.91 بود- یک تست T دو نمونه به کار برده شد، که در مقایسه با نسبت میانگین روی گزارش مرتبط با کیفیت داده شده توسط کاربران 4 سیستم مقایسه شده با کاربران سیستم های دیگر انجام شد. نتایج تفاوت آماری مهمی داشتند اگر چه برخی از نتایج در جدول III آمد، و به نظر مهم می رسند، اندازه کوچک و انحراف میانگین بزرگ به دست آمده این نتیجه را به شکل غیرمعقول ارائه می کند- در هر حال آ‎ن برای تمام گزارش ها به جز دو مورد سودمند است، کاربران سیستم نوع A یک نسبت مساوی یا بالاتر نسبت به کاربران سیستم های B را به سیستم خود اختصاص دادند. این خودرا به عنوان محلی برای تحقیق کمی بیشتر پیشنهاد می دهد. مورد زیر پاسخ کاربران به جوانب خاص سیستم های تحقیق شد و خلاصه می کند نظر در مورد "کمک" آنلاین- عامل دیگر درتعیین کیفیت "کمک" آنلاین حوزه ای است که کاربران آن را استفاده می کنند. از کاربران پرسیده شد، چه تعداد دفعات شما از "کمک"آنلاین استفاده می کنید؟ از کاربران خواسته شد تا براساس یک مقیاس 4 درجه پاسخ دهند، که 4= به دفعات و 1= هرگز، نتایج پیشنهاد می دهد که به طور کلی "کمک" آنلاین را در جائیکه ارائه شده استفاده نمی کنند، اکثریت کاربران نشان دادند که آنها یا به ندرت یا هرگز از "کمک" استفاده نمی کنند. نسبت میانگین 1.97 بود.
اما جائیکه ارتباط ساز فنی "کمک" آنلاین را نوشت، کاربران علاقه بیشتری به استفاده از "کمک" دشاتند. (میانگین 2.666 بود). برای سیستم هایی که ارتباط ساز فنی، "کمک" را نوشته بود، کاربران علاقه کمتری به استفاده از آن داشتند، میانگین 1.734 بود. یک تست T دو نمونه، میانگین های داده شده را مقایسه می کند که از لحاظ آماری مهم بود. (P<0.05) در 0.0004
این خصوصیات به طور قوی پیشنهاد می کند که برای کاربران، کیفیت بهتر است و کاربران برای استفاده از "کمک" آنلاین نوشته شده توسط ارتباط سازمان فنی آماده تر هستند. نظر در مورد طرح رابط کاربر: به استثناء فقط دو مورد، توسعه دهندگان نشان دادندکه ارتباط ساز فنی، مشارکت مهمی در طرح رابطه داشته است. سپس سوال این است، که آیا این مشارکت، ارتقاء دهنده سیستم از دیدگاه کاربران است؟ از کاربران پرسیده شد آیا کاربری سیستم دوستانه است؟ پاسخها با کد 3= بله، هیچکدام (نه بله و نه خیر)=2 و خیر=1 بود- کاربران سیستم نوع A که ارتباط ساز فنی حضور داشت. نسبت دوستانه بوده را بالاتری از نسبت به کاربران سیستم نوع B بدون حضور ارتباط ساز فنی ارائه کردند.(2.18)
یک تفاوت آماری مهم (P<0.05) میان دو گروه وجود داشت (0.0111) این مورد به شدت پیشنهاد دهنده نقش ارتباط ساز فنی در ارتقاء رابط کاربر از دیدگاه کاربر است.
نظر در مورد سیستم و پیغامهای خطا
از کاربران سوال شد آیا شما فهمیده اید که در زمان کار با سیستم، پیغامها شما را در مورد کار سیستم در اکثر زمانها آگاه می کند؟ دوباره یک مقیاس 5 نقطه ای استفاده شد که، 5= زیاد و1= هرگز بود- به طور کل کاربران معتقد هستند که آنها کار خود را با نسبت میانگین 3.47 از 5 انجام می دهند. مقایسه میان سیستم ها جائیکه یک ارتباط ساز فنی برای نگارش سیستم و پیغامهای خطا و سیستم هایی که فرد دیگری آن را برعهده گرفته انجام شد، سیستم های اندکی از ارتباط ساز فنی در این نقش استفاده کردند و در اکثر موارد، ارتباط ساز فنی فقط یک نقش ویرایشگر داشت- اگر چه هیچ نتیجه ای را نمی توان با توجه به حضور ارتباط ساز فنی و کیفیت سیستم و متن پیغام خطا ایجاد کرد، در سیستم هایی که ارتباط ساز فنی مشارکت داشته، کیفیت پیغامها بسیار بالاتر بوده است.
تجزیه و تحلیل داده های کیفی کاربر:
داده های کیفی، طبقه بندی شده و در سلولهای یک ماتریس قبلاً شرح داده شد وارد شد. طبقه بندی داده ها یک شمارش از تمام پاسخهای مثبت و منفی کاربران در ارتباط با رابط، "کمک" آنلاین، و پیغامهای خطا را ارائه داد- اینها در بررسی، نواحی بودند که یک ارتباط ساز فنی می تواند بیشترین تاثیر را داشته باشد.
جدول IV تعداد نظرات مثبت و منفی کاربران در جوانب خاص است نوع A کاربرانی هستند که از حضور ارتباط ساز فنی بهره برده و نوع کاربران سیستم های دیگر هستند. متن پیغام خطا، منفی ترین نظرات کاربران را با وجود 36% کاربر با نظر منفی نشان داد. کمک فنی نوشته نشده توسط یک ارتباط ساز فنی 4 نظر مثبت و 16 نظر منفی را جذب کرد. در مقایسه کمک آنلاین نوشته شده توسط ارتباط ساز فنی ،11 نظر مثبت و 4 نظر منفی را به خود جلب کرد. رابط های کاربر، جائیکه یک ارتباط ساز فنی حضور داشت فقط یک نظر منفی کاربر را جلب کرده و در مقایسه با 11 نظر منفی کاربرانی که از حضور ارتباط ساز فنی استفاده نکرده بودند- در مصاحبه با 66 کاربر، این نتایج قویاً نشان می دهد که مشارکت ثبت و مهم ارتباط سازان فنی در "کمک آنلاین"، طراحی روابط و سیستم و پیغامهای خطا وجود داشته است.
دیدگاه های توسعه دهندگان برای مطالعه موردی با 20 توسعه دهنده مصاحبه شد. به طور کلی توسعه دهندگانی که از حضور ارتباط ساز فنی استفاده کرده بودند، حضور آنها را مهم بررسی کرده و در آینده از آنها استفاده خواهند کرد.
نقشهای ارتباط ساز فنی – از یک لیست نقشها ادبیات موجود، وجود عملکرد ارتباط سازان فنی را شناسایی کرد، از توسعه دهندگان خواسته شد تا نشان دهند از نظر آنها چه نقشی، بخشی از کار ارتباط سازان فنی بوده است. جدول V ارائه دهنده نتایج است. اعداد نمایانگر تعداد توسعه دهندگانی است که نشان دادند نقش، آن است که با آن همراه بودند یک ارتباط ساز فنی وجود داشته است.
تمام توسعه دهندگان معتقد بودند که نگارش گزارش کاربر یک نقش ارتباط ساز فنی بوده است. 16 نفر فکر می کردند که ارتباط داشتن با کاربران، یک نقش بوده است و 15 نفر فکر کردند که ارتباط سازان فنی می توانند کمک آنلاین را بفرستند- این نشان می دهد که به طور کامل متخصصان IT توانایی و ارزش ارتباط سازان فنی را درک کرد اند. بخش بعدی ارائه دهنده یک بررسی کل از پاسخهای کیفی ارائه شد متوسط توسعه دهندگانی است که به نقشهای کلیدی شناسایی شده توجه دارند.
درک دیدگاه کاربر- تمام توسعه دهندگان عقیده داشتند که ارتباط ساز فنی دیدگاه کاربر را درک کرده است، اما 5 توسعه دهنده اشاره کردند که این به دلیل این بوده که ارتباط ساز فنی یک فرد "فنی" نبوده است و یک توسعه دهنده شرح داد!
مهمترین مسئله در مورد سارا ( ارتباط ساز فنی) این است که او یک فرد غیرفنی و یک غیرتوسعه دهنده نرم افزار است. او دیدگاه متفاوت دارد و این دیدگاه متفاوت خیلی مهم است. برخی فرضیه ها که من می سازم این است که چگونه افراد باید اشیاء را ببینند و استفاده کنند در حالیکه روشن ضروری آنها نیست- او یک دیدگاه راه حل را ارائه داد، او بازخوردی را در مورد اینکه " چرا آن رخ می دهد" ارائه کرد- حضور یک دادگاه از یک غیر توسعه دهنده بسیار مهم بود.
توسعه دهنده دیگر انعکاس داد که او به اندازه کافی از ارتباط ساز فنی استفاده نکرده بود. در این مورد ارتباط ساز فنی، در فرآیند توسعه احضار شد، او گفت ارتباط ساز فنی به طور موفقیت آمیز مفاهیم خیلی پیچیده را به حضار غیرفنی توضیح داده است. نظر او این بود: ارتباط ساز فنی ارزش برجسته ای دارد وقتی که حفار پس زمینه فنی نداشته و شما سعی دارید که با آناه ارتباط برقرار کنید – و وجود هیچ زمینه و پایه دانش برای شروع با آن را فرض نمی کنید.
از طرف دیگر یک توسعه دهنده که از یک ارتباط ساز فنی استفاده نکرده، در مورد نیاز به فردی که دیدگاه کاربر را بگیرد، نظر داد. او انعکاس داد که در طول فرآیند توسعه کاربران عملاً آنچه راکه توسعه دهندگان در حال طراحی بوده اند را نفهمیده اند.
طراحی کمک آنلاین: توسعه دهندگان به طور کل موافق بودند که ارتباط سازان فنی باید کمک آنلاین را بنویسند، اما از 20 سیستم، 15 مورد کمک آنلاین داشتند اما فقط 4 توسعه دهنده از ارتباط ساز فنی برای نگارش کمک استفاده کردند- در میان توسعه دهندگانی که از ارتباط ساز فنی استفاده نکرده بودند، سه نفر نشان دادند که در آینده این کار را خواهند کرد و یک نفر گفت که یک ارتباط ساز فنی در حال نگارش سیستم کمک است. یک توسعه دهنده گفت که مشارکت ارتباط ساز فنی در کمک آنلاین و پیغامهای خطا کاملاً حیاتی بوده و یک عامل تعیین موفقیت سایت و حرفه ای گرایی است، عملکرد و نگاه آن.
طراحی رابط کاربر: در میان نمونه های مطالعه موردی، فقط یک ارتباط ساز فنی، به طور خاص مسئول طراحی رابط بود. در 8 سیستم دیگر، توسعه دهندگان گفتند که ارتباط ساز فنی یک مشارکت داشته است. یک توسعه دهنده دلیل آور که یک ارتباط ساز فنی باید در طراحی رابط حاضر شود چون "بخشهای زیاد رابط پایه" شفاهی دارند- تصمیم گرفته شد که ما باید واقعاً کسی را داشته باشیم که بتواند کار نگارش را به خوبی انجام دهد.
تنظیم تمرینات طراحی استاندارد برای رابط توسط دو توسعه دهنده به عنوان کار انجام شده توسط روابط ساز فنی اشاره شد- یک توسعه دهنده گفت این کار بسیار موثر بوده است – او (ارتباط ساز فنی) استانداردهایی را برای عناصر رابط کار بر گزارش داد، خصوصاً نحوه فکر شما در مورد چیزهایی مثل فایل های لود، آنچه که در زیر فایل صفر (لیست) می آمده و اینکه چه نوع لغاتی را به شما استفاده می کنید.
ارتباط ساز فنی برای یک سیستم به دفعات با رابط کاربر مشورت می کرد، این ممکن بود چون او یک کارمند تمام وقت بود- توسعه دهنده شرح داد که چگونه ورودی او مدیریت شده است.
ارتباط ساز فنی بسیار مهم است چون رابطه من با او مهم بود- من کارهای را انجام دادم، من راه خود را برای ارائه صفحه خواهم داشت و من عادت داشتم که به سارا بگویم " در مورد این چه فکر می کنی؟" به این طرح یک نگاه بکن و این چگونه کار می کند؟ ما عملاً زمانی را صرف می کنیم و او می گوید، "آن واقعاً برای این صفحه مناسب و مشابه نیست، به نظر می رسد و حس می شود غیر استاندارد باشد یا ممکن است کاربر را گیج کند یا تضادهایی وجود دارند. سارا (ارتباط ساز فنی) بسیار مهم بود چون او اولین باز خورد من برای کاری که انجام داده ام بود- من با چیزی را روی تکه کاغذ طراحی می کردم و من از او خواستم که آیا این به نظر او نتیجه می دهد. به نظر می رسید که در مراحل کار می کرد. من باید کاری بکنم او باید آن را بررسی کند و مشتری خواهد آمد آنها در مورد کل محصول نظر خواهند داد که برخی از آن نگاه و حس بوده و من باید آن را برگردانم.
موثر بودن طرح جریان کار به عنوان یک بخش شناخته شد که ارتباط سازان فنی در آن حضور داشتند و با توجه به جهت یابی سیستم به طور ویژه افزایش یافت، این موثر بودن رابطه میان موارد سرعتی را شامل می شد نیاز به متخصصان دیگر از جمله ارتباط سازان فنی توسط یک توسعه دهنده شناخته شد. او بر دستوری تاکید داشت که سیستم آنها سریع و کاملاً مقاوم باشد چون یک سیستم شرط بندی آنلاین بود.
تضمین اینکه طرح برای کاربران درونی و حدس است، مهم بود. توسعه دهنده سیستم شرط بندی آنلاین شرح داد که کاربران از صفحات کمک استفاده نمی کنند، بنابراین رابط باید طراحی شود و کمک آنلاین غیرضروری بود.
ارتباط ساز فنی تایید کرد که آنها روی چیزهایی نظر داده اند مثل طراحی صفحه، رنگ، و اندازه فونت، اگر چه او معتقد بود که مشارکت آنها منع شده بود چون آنها زودتر فراخوانده نشدند. زمان بعدی، او معتقد بود که چیزها متفاوت خواهند بود.
توسعه دهنده یک سیستم وب، از متخصصان دیگری به همراه ارتباط سازان فنی استفاده کرد، تا رابط سایت وب را طراحی کنند. دلیل او برای این کار این بود، آن یک مهارت ویژه است برای طراحی صفحات وب و نوع کیوسک صفحات، چون یک رابط عمومی است- برنامه نویس ها این مهارت را نداشته و نباید داشته باشند. ما از آنها انتظار نداریم که در این مرحله این تخصص را داشته باشند.
طراحی سیستم و پیامهای خطا، از توسعه دهندگان خواسته نشد که در مورد سیستم و پیغامهای آن نظر بدهند، اما یک توسعه دهنده گفت او قویاً معتقد بود که نقشی برای ارتباط سازان فنی در این بخش وجود داشته است. او به این نکته اشاره کرد که:
مطمئناً داشتن فردی مثل شرکت (شرکت تهیه گزارش شده) برای آمدن و بررسی پیغامها سودمند است. به همین دلیل است که آنها از این افراد استفاده کرده اند، آنها یک تصمیم فنی دارند آنها صحبت می کنند، کاربر صحبت می کند، آنها می دانند نیاز کاربر به ایران چه چیزی است. اگر ما یک برنامه نویس را بفرستیم که این کار را انجام دهد، او خواهد گفت، مهم است بدانید که فایل پر است، خوب این کار کاربرنیست، چرا کاربر باید آن پیغام را ببیند.
آیا پیام نیز باید فقط یک پیام باشد، چرا نمی تواند بگوید تنظیم چیست؟ شماره مشتری غیرمعتبر است، بنابراین من در مورد آن چکار باید بکنم؟
ارزش افزوده توسط ارتباط سازان فنی – از توسعه دهندگان خواسته شد تا به دو سوال مربوط به مشارکت ارتباط ساز فنی در کمک آنلاین پاسخ دهند، طرح رابط کاربر و پیغامهای خطا- از آنها خواسته شد تا نشان دهند که مقدار ارزش این مشارکت چقدر بوده است، با یک مقیاس 10 درجه ای ،1= بدون مشارکت، 10= یک مشارکت مهم
جدول VI ارائه دهنده نتایج میانگین در دو سوال برای 10 سیستم نوع A است. سوال با توسعه دهندگان سیستم های نوع B مربوط نبود.
نتایج نشان داد که توسعه دهندگان به طور کل به مشارکت ارتباط سازان فنی در توسعه سیستم عقیده دارند و مشارکت آنها به مقدار ارزش خصوصاً در نواحی طرح رابط و کمک آنلاین اضافه کرد- فقط در بخش طراحی سیستم و پیامهای خطا مشارکت آنها کمتر از حد اهمیت بود- یعنی توسعه دهنده گفت ارزش مشارکت کمتر از 5 بود.
باید به این نکته اشاره شود که تعداد کمی ارتباط ساز فنی در واقع برای نظر دادن در مورد سیستم و پیامهای خطا دعوت شده بودند و بنابراین بعید است که مشارکت آنها مهم شود. آیا توسعه دهندگان مجدداً از یک ارتباط رسان فنی استفاده می کنند، اگر توسعه دهندگان نشان دهند که دوباره از یک ارتباط رسان فنی استفاده می کنند این یک نشانه واضح است که ارتباط رسانان فنی ارزش فرآیند توسعه را افزایش می دهند اگر چه توسعه دهندگان بطور رسمی سوال شده اند، اگر آنها دوباره از ارتباط رسان فنی استفاد کنند آن در مورد اکثر مصاحبه کنندگان رخ داده و بطور غیررسمی از دیگران سوال شده بود، پنج مورد از بیست سیستم یک ارتباط رسان فنی دارند به عنوان یک کارمند دائمی که یک تصدیق واضح نیاز به این نقش است در موارد دیگر توسعه دهندگانی که در گذشته از ارتباط رسان فنی استفاده کرده بودند گفتند که دوباره این کار را انجام می دهند. توسعه دهندگان دو سیستمی که از حضور ارتباط رسان استفاده نکرده بودند هر دو گفتند که نیاز به این مهارت را دیده و برای سیستم های آینده از ارتباط زمان فنی استفاده خواهند کرد تعدادی از توسعه دهندگان این عقیده را بیان داشته اند که آنها در فرآیند توسعه در آینده از ارتباط رسان فنی در زمان زودتر استفاده خواهند کرد. دو نظریه از نظر توسعه دهندگان در مورد این موضوع دارای ارزش ارائه کردن است. چون آنها حس قوی و تعهدی را که این توسعه دهندگان خاص در مورد نقش ارتباط رسان فنی دارند دارند نشان می دهد.
نقش دارای اهمیت بود که آنها در سیستم بر عهده داشتند ( ارتباط رسان فنی، خواندن گزارشات، بررسی سیستم، صحبت با کاربران و سعی برای ارائه دقیق کار سیستم من دوباره از یک ارتباط رسان فنی استفاده خواهیم کرد، آنها یکی از ستارگان پروژه بودند.
آیا یک ارتباط رسان فنی ارزش دارد، اگر کسی مثل پل در آغاز حضور داشته او از دیدگاه کاربران نیازها را برطرف کرده است.
فقط یک توسعه دهنده که از یک ارتباط رسان فنی استفاده کرده بود، مطالبی را در مورد نقش بیان کرد او بطور اساسی نیاز به یک ارتباط رسان فنی را تایید کرد اما آن را شکستی می دید که برنامه نویسان او نمی توانستند گزارش کاربر را از یک استاندارد به اندازه کافی بالا تولید کنند.
حضور اولیه ارتباط رسانان فنی: نکته ای که ارتباط رسان فنی در فرآیند توسعه حاضر شده ارتباط قوی با مشارکتی که آنها ایجاد کردند داشت، هفت نفر از ده ارتباط رسان فنی از قبل حاضر بودند یعنی قبل یا در مرحله طراحی جدول VII نسبت های میانگین داده شده توسط توسعه دهندگان هفت سیستم که در آن ارتباط رسانان فنی و خبری شرکت داشتند را ارائه می کند.
در مقایسه با اطلاعات ارائه شده در جدول VI هر چقدر که ارتباط رسانان فنی زودتر حضور یافتند احتمال اینکه توسعه دهندگان بخواهند. الف – نظر ارتباط رسان فنی را بپرسند و نیز توصیه او را و ب- ارزش این ورودی را بررسی کنند بیشتر خواهد بود در سه سیستم ارتباط میان فنی حاضر نشد تا زمان طراحی مستقیم و در هر سه مورد، در مورد مشارکت قضاوت انجام شده ارزش محدود شده ای را نشان می داد.
بحث: اطلاعات جمع آوری شده از توسعه دهندگان و کاربران که بعداً یافته های تحقیق را تایید کردند که ارتباط رسانان خبری مشارکت مثبتی در توسعه سسیتم ها داشتند، اطلاعات جمع آوری شده از اطلاعات موردی نشان می دهد که:
کاربران رضایت بیشتری داشته و در زمان حضور ارتباط رسان فنی، نسبت موفقیت سیستم بود.
کاربران کمیت کمک آنلاین را بالاتر دانسته و علاقه بیشتری به کار برد کمک آن لاین داشتند اگر توسط یک ارتباط رسان فنی نوشته شده بود. کاربران نظرات منفی تری را در مورد رابط کاربر و کمک آن لاین داشتند. اگر ارتباط رسان فنی حضور نداشت.
اکثریت توسعه دهندگان عقیده داشتند ارتباط با کاربران نگارش کمک آن لاین و مشاوره در مورد طراحی رابط بخشی از کار ارتباط رسان فنی است.
توسعه دهندگان تایید کرده و مشارکت ارتباط رسان فنی را قدردانی می کند و می توانند این مشارکت را کمیت بخشند. اکثریت توسعه دهندگانی که از ارتباط رسان فنی استفاده کرده بودند از آنها خواسته شد تا نظر خود را ارائه کرده و مشارکت مهمی در طراحی کمک آن لاین و توسعه رابط کاربر داشتند. تمام توسعه دهندگانی که از ارتباط رسان فنی استفاده کردند مجدداً علاقه به انجام داشته و در برخی موارد آنها را زودتر حاضر کرده و حضور آن ها در وظایفی که در حال حاضر به آنها مربوط نمی شود استفاده کردند.
توسعه دهندگان مشارکت ارتباط رسان فنی را مهمتر بررسی کردند وقتی که ارتباط رسانان فنی زودتر حضور یافتند.
همچنین با حضور زودتر ارتباط رسانان فنی مشارکت بیشتری در کمک آن لاین داشتند و نیز در رابط کاربر و پیامهای خطا.
نتیجه: نتایج گزارش شده در این مقاله کاربردهای مهم و مستقلی برای پروژه های توسعه سیستم تهیه منابع و مدیریتی دارد. یک تغییر مثبت و مهم در پذیرش کاربر و نظر در مورد سیستم ها وجود دارد جایی که یک ارتباط رسان فنی حضور داشته است. توسعه دهندگانی است که از حضور قوی ارتباط رسان فنی استفاده کردند نیاز به نقش او را شناختند، یافته های تحقیق نیاز به بررسی بیشتر نقش متخصصان غیر IT در توسعه سیستم ها خصوصاً در بخش کاربردی سیستم را نشان می دهند. تحقیق بیشتری نیز برای کمیت بخشی واضح تر ذخیره هزینه برای کاربر ارتباط رسان فنی مورد نیاز است، برای ایجاد بهترین سیستم های اطلاعاتی آینده ارتباط رسانان فنی باید ترکیب شده و مشارکتهای سریع در تیم ها داشته باشند.
جولی فیشر-
استادیار و رئیس اداره سیستم های اطلاعاتی در دانشگاه تکنولوژی ویکتوریا، ملبوان، استرالیا است. علاقه تحقیقی جولی در حوزه ارتباط فنی است. رساله دکترای او، نقشهای ارتباط سازان فنی در توسعه سیستم های اطلاعاتی را آزمایش کرده است. جولی کارهای خود را در معادلات IEEE در ارتباط حرفه ای و در ارتباط فنی منتشر ساخته است.

کاربرد سبک های یادگیری در تهیه گزارش نرم افزار:
اصطلاحات شاخص: طرح گزارش، سبک های یادگیری می نیمم مالیسم، وظایف کاربر.
بهترین چیزهایی که من در مورد کاربرد یک سیستم دی تی پی خالص مطالعه کرده ام مقالاتی توسط تام آراه در مجله انگلیسی PcPRO بوده از او در چهار صفحه مشکلات را به شما می گوید، چرا شما باید به روشی که او شرح می دهد آغاز کنید، چه خصوصیاتی دارد، وظایف مشترک را چگونه انجام دهید و اینکه گاهی اوقات چه کارهایی اشتباه است من مطمئن هستم که می توانم از آن نرم افزاری برای آنچه که او شرح می دهد استفاده کنم، اگر چه که هیچ نیازی به من و برای انجام آن فشار وارد نمی سازد و البته من ممکن است در مورد سودمند بودن کاربرد آن اشتباه کنم.
چرا من این مقالات را دوست دارم، بر طبق تئوری دیوید کال دلیل این است که من یک ترکیب خاص از سمت های سبک یادگیری دارم بنابراین من مطالعه متنی را که من را گرم می کند دوست دارم من آن را یک تجربه ارزشمند یافتم، آن چیزی بیشتر از یک دانش است، معامله انتقال. من شک دارم که آلن مالینگ تحسین کننده می نی مالیسم، جان کارون یک ترکیب از جهت گیری های مختلف من داشته باشد و بطور کل از خواندن مقالات رنج نبرد مگر اینکه بخواهد از سیستم DTP مورد بحث استفاده کند و او احتمالاً حتی بعداً هم آنها را تمام نخواهد کرد در این مقاله من پیشنهاد می کنم که راهنماهای می نی مال برای هر کس کاربر نخواهد داشت و این تغییر می نی مالیسم ها را نمی توان شناسایی و حمایت کرد.
برخی پس زمینه ها: هستر گلاسیک در دانشگاه اوت رچ آزمایشی را با ده نفر دارای اولویت های قوی سبک یادگیری انجام داد پنج نفر یک نوع سبک یادگیری داشتند و پنج نفر دیگر نوع متفاوت او یک راهنمای می نی مالیسم را ایجاد کرده ( با برخی مشکلات) و دریافت که مردم با اولین سبک یادگیری فقط وقتی راهنما را می خوانن که گرفتار شده باشند و آن را به راهنماهای رایج ترجیح دادند اما افراد با سبک یادگیری متفاوت کل راهنما را خوانند چون در آن نوشته شده بود برخی از آنها حتی سعی کردند دستورالعمل ها را در جدول رفع خطا انجام دهند اگر چه که آنها هیچ اشتباهی نداشتند. آنها مشکلات جدی و جدی تری نسبت به موضوعات تحقیقی داشتند، اکثر این مشکلات بر اثر کمبود موضوع مقدماتی و بر اثر ناقص بودن برخی دستورالعملها بوجود آمده بودند می نی مونیسم برای هر کس نتیجه نمی دهد، اکثر مردم یک راهنما را انتخاب نکرده و با انتخاب خود آن را ورق می زنند. سود بحث نکردن در مورد عملکردهای کلی چیست؟ مثلاً در زمان کاربرد نرم افزار پردازش لغت چرا بالانویس ها و زیرنویس ها در صفحات وجود ندارند. من می خواهم جواب آن را در راهنما پیدا کنم. چرا هیچ بحثی در مورد بهترین کاربرد خصوصیات وجود ندارد یا در مورد مشکلاتی که ممکن است بوجود آیند.
یک ارزیابی ازبهترین روش کسب نتیجه خاص با استفاده از یک محصول بسیار سودمندتر از کارکردن با شرح خصوصیات آن می باشد من این را می گویم چون اگر چه مثل وظایف کاربر مشخص شده اکثر راهنماها بصورت ساده خصوصیات را شرح می دهند، چگونه بالا نویس ها و زیر نویس ها را تنظیم کنیم در بخش سیستم WP دلخواه شما می تواند این کار را انجام دهد بجای اینکه بهترین راه تکرار متن در کل نامه مقاله و کتاب شما این است.
آن یک مشکل بزرگ است اگر شما نتوانید وظایف کاربر را توضیح دهید ( و با نرم افزار چند منظوره آن بسیار مشکل است) سپس نمونه های حقیقی تطابق سختی خواهند داشت و اینها در خصوصیات عمده راهنماهای می نی مولیسم بر طبق مالینگ هستند.
یادگیری تجربی: بنابراین ما برای کمک به کجا نگاه کنیم. کارول تحت تاثیر تئوری های کالب جونگ، جان دوری، کرت لوئین، جین پیوگت ودیگران قرار گرفته است. کالب نیز تاثیرات مشابهی دارد یک بحث و خلاصه مشارکت آنها در کالب و میولند وجود دارد. بنظر می رسد که یک مطالعه کالب و در این زمینه بطور کلی می تواند مشارکت می نی مولیسم را در استراتژی نگارشی نویسنده واضح بیان کند.
تی پولوژی ها: کالب تئوری خود را در کتابش بنام یادگیری تجربی شرح می دهد، کار او توسط مطالعات در زمینه معماری توسط یک گروه شامل جمیز هابل در دانشگاه سال فورد و پل نیولند در دانشگاه فوردز موت توسعه یافته اند هانی و مان فورد از کار کالب در یک زمینه تجاری استفاده کردند.
کالب مردم را به دو دسته بر طبق سبک یادگیری آنها تقسیم می کند که به انواع روان شناسی بدست آمده از جونگ از طریق پیرگت مربوط می شود، مارگرسیسون و لویس یک ارتباط مهم میان سبک های یادگیری و انواع روان شناسی از طریق فهرست نوع مایزر بی ریگز ( ام بی تی آی) و فهرست سبک یادگیری کالب تایید کردند (LSI) تقسیمات پاول و نیولند توسط ادغام انواع سبک یادگیری کالب با انواع شخصیتی تی موتی لیری ایجاد شده اند. که توسط تئوری میان شخصی، شخصیتی او ابراز شده اند این یک چهار واژه از استراتژی های آگاه بخشی شخصی است که ضرورتاً با سبک های یادگیری کالب مشابه است خود سبک های یادگیری اسامی گوناگونی را توسط نویسنده بدست آورده اند. جدول بالای این صفحه رابطه ها را نشان می دهد و نیز انواع روان شناسی لیری، من از اصطلاحات نیولند و پاول در این مقاله استفاده می کنم هانی و مان فورد یک لیست از فعالیتهای مناسب را ارائه داده اند ( پایین صفحه بعدی را نگاه کنید)
یکی از نکاتی که آنها ایجاد کرده اند در تعلیم دادن است (یعنی تلاش هایی یک به یک متخصص برای بهبود تلاش های فرد با تجربه کم) تفاوت ها در سبک یادگیری احتمال دارد که حیاتی باشند ( درتعیین موفقیت و شکست)
بعنوان مثال یادگیرندگان پویا ممکن است در برابر دستورالعمل مستقیم ناشکیبا باشند و احتمالاً دستورالعمل را فراموش کرده و فقط تجربه کنند. یادگیرندگان متمرکز احتمالاً در برابر یک آموزش قدرتمند بسیار واکنش نشان می دهند یادگیرندگان متفکر اصرار دارند که مربیان شواهدی را برای ادعاهای خود ارائه دهند یادگیرندگان بسیار دقیق پاسخ خوبی به دستورالعمل کامل آماده شده نشان داده اما به جلسات بدون برنامه قبلی پس از دستورالعمل آنها می خواهند شانس کار بر روی فرآیند، به خودشان اختصاص دهند.
تاثیر و نویسندگان: اشاره به این مطالب مهم است که اکثر مردم مخلوطی از سبک های یادگیری را نشان می دهند وقتی که فردی سبک یادگیری پویا دارد یعنی که خصوصیات پویای قوی تری را نسبت به خصوصیات دقیق متمرکز و متفکرانه ارائه می کند.
نویسندگان با سبک های یادگیری پویا می خواهند که خواننده را علاقه مند سازند. آنها از عقاید یا طرح های جدید برای جلب توجه خواننده استفاده می کنند و اغلب جملات آنها کوتاه و مختصر بوده و علاقه دارند راه حل هایی را برای مشکلات واقعی ارائه دهند تمایل آنها به ارائه گزارشات سودمند و قوی است. (شما چه چیزی را با این بدست می آورید، آ‎ن چه چیزی را برای شما انجام خواهد داد) و دوست دارند یک کار را به تنهایی تا پایان انجام داده و رابطه آن با یک طرح بزرگتر را اجرا کرده یا فراموش کنند. آنها علاقه ای به تست های اطلاعاتی، سخنرانی ها، توصیه یا مراجع مقطعی ندارند. شغل مطلوب آنها نوشتن کپی تبلیغات است.
نویسندگان با سبک های یادگیری متمرکز توجه خاصی به طرح گزارش نشان نمی دهد بجز اینکه آنها طبقه بندی های ساختاری عمیق اطلاعات را دوست ندارند. مثل چیزی که اغلب در کتاب های قطور دیده می شود جایی که اطلاعات در سطوح پایین تر به متن آن و مفهوم اطلاعات داده شده در سطوح بالاتر بستگی دارد. آنها از یک سبک نگارش بدون حساسیت و زرق و برق استفاده می کنند تا دستیابی سریع را ارائه دهند. آنها نمونه هایی مشابه زندگی واقعی را و نیز اطلاعات مربوط به موضوع و اطلاعات مربوط به کار را علاقه دارند( نحوه بهبود کارآیی و اقتصاد) اما اگر نیاز به جزئیات کامل وجود داشته باشد آنها یک طرح و یک مثال را ارائه می کنند. شغل ایده آل آنها نگارش بیوگرافی می باشد.
نویسندگان با سبک های یادگیری متفکرانه یک تن خنثی و شرحهای نیمه از تسهیلات را دوست دارند، آنها به طور ویژه، از ارائه اطلاعات مربوط به کار لذت نمی برند- آنها سعی دارند که مقتدر و تقریباً راهنما باشند، اما هدف اصلی آنها تحویل یک تصویر کامل است شغل ایده آل آنها کارکردن به عنوان بخشی از یک گروه به عنوان تدوین یک دیکشنری است.
نویسندگان با سبک های یادگیری محکم و جدی، خواهان تاثیرگذاری بر خوانندگان خود با اقتدار خود هستند. توجه عمده آنها راضی کردن عقاید خود در مورد سبک یادگیری و مناسب است. آنها خواهان پیشرفتهای منطقی هستند و شرحهای اصول و فرضیه ها و یک روش نسبتاً رسمی ، آنها بی نهایت ها یا بی اهمیت ها یا چگونگی اطلاعات را بدون شرح را دوست ندارند- شغل ایده آل آنها نگارش یک کتاب فیزیک است.
تغییردادن سبک ها
در طول سالهای زیاد و تحقیقات زیاد، سبک یادگیری ترجیح داده شده برای اکثریت کلی جمعیت، نوع متمرکز بوده است. این می تواند شرح دهد که چرا راهنماهای مینی مالیست موفقیت هایی را داشته اند، چون شکل آنها با قدردانی یادگیرنده متمرکز از اقتصاد و تمایل برای نمونه های واقعی تطابق دارد. مشکل یک خواننده گزارش و سندسازی، این است که نویسندگان به عنوان یک گروه حرفه ای ، سبک یادگیری متفاوتی با جمعیت عادی دارند. تحقیق محدود من نشان می دهد که نویسندگان فنی مخلوطی از سبک های پویا و جدی (دقیق) هستند. برای آنها جای دادن نیازهای حضار متمرکز خود سخت است، نه حداقل به خاطر اینکه مردم با سبک هی یادگیری دقیق و پویا مستعد بی حس بودن در برابر آرزوهای دیگران هستند و تمایلی به انعطاف پذیر بودن ندارند.
برای تقویت جنبه پویا، حداقل هفته ای یکبار کار جدیدی انجام دهید. ( تحرکی را در کار ایجاد کنید) در ساعت ناهار به دویدن بروید، لباس که عجیب وغریب است بپوشید، روزنامه ای را بخوانید که معمولاً از آن اجتناب می کنید.
برای تقویت جنبه متمرکز: تکنیک ها را جمع آوری کنید ( تحلیل های کاری، تحلیل های سود هزینه، غلبه بر استرس) تولید طرحهای فعالیت ، آزمایش چیزی جدید، مطالعه افراد دیگر و الگوبرداری از فرد موثق، گرفتن توصیه از متخصصان و انجام یک پروژه Dly (یادگیری تایپ، تعمیر یک تکه مبل، یادگیری نحوه کار اتومبیل خود)
جدول
تقویت جنبه متفکرانه، تمرین مشاهده جلسات، مطالعه عادت مردم، برنامه یادداشت و تحلیل کارهای روزانه- تحقیق برخی موضوعات در کتاب خانه که نیازمند جمع آوری اطلاعات زیاد است، تمرین نگارش طرحهای متعد( یک گزارش یا مقاله تا وقتی که کار نمونه ای ارائه شود) سپس خواندن آن یک هفته بعد و نگارش مجدد آن، نگارش بحثها به نفع و برعلیه یک موقعیت – تقویت خود برای مناسب بودن در هر کدام تقویت جنبه دقیق- خواندن مطلب مشکل (فلسفه تحلیل های زبان شناسی و منطق) و خلاصه کردن آن با مقایسه داستانهای 2 روزنامه متفاوت و خلاصه عقاید آنها، تحلیل یک موقعیت پیچیده، جمع آوری تئوری های در مورد چیزی ( هر چیزی که مخالفت را ایجاد کند) و تحلیل توسعه آن. تمرین پوشش در مورد سوالات تحقیقی (توجه به پاسخها)
تکنولوژیها اما اینها اهداف دراز مدت هستند- در حال حاضر، هر چه که در مورد لیست تکنیک ها است، براساس اولویت های سبک یادگیری، که ممکن است به نویسندگان در به کارگیری حضار کمک کند؟ این یک تلاش اولیه است.
مقدمه ها را کوتاه کنید. فوائد و نمونه هایی را در متن اصلی بیاورید و خلاصه های جزئیات یا عملکردهای مشکل را به صورت بالقوه ارائه دهید.
مردم کمی مطالب گفته شده در مقدمه را به یاد می آورند، بسته به این که چقدر شگفت آور بوده باشد- خلاصه هایی که گزارشات سود واضح مرتبط با خوانندگان پویا، متمرکز و جدی را شامل می شود ( البته به دلایل گوناگون) چرا از آنها خواسته می شود که به این مشکل عمل کنند.
خوانندگان دقیق و متفکر از حس تکمیل، خلاصه ها لذت می برند- خوانندگان متمرکز مثالها را دوست دارند- خلاصه ها نباید به سادگی تکرار مطالب قبلی باشند اما باید کار را به مشکلات ارتباط دهند نه فقط:
در این بخش شما یاد گرفتید که چگونه بالانویس ها و زیر نویس ها را به گزارش اضافه کنید.
بلکه همچنین:
در این بخش شما یاد گرفتید که چگونه اطلاعات را در یک صفحه وارد کنید که خارج از جریان متن است. اطلاعاتی مثل شماره گذاری صفحه، تاریخ های بررسی مجدد و یا تهیه عناوین بخش ها و کتاب – به یاد داشته باشیم که بالانویس ها و زیرنویس ها را می توان برای نشان دادن هر اطلاعات ثابت یا متغیر به کار برد.
داشتن لیست های موضوعات برجسته و عناوین موضوع که وظایف را شرح می دهند، و ترکیب لغات و عباراتی که ساختار حمل – کار نرم افزار را نشان می دهند این سخت تر از ظاهرش است. اگر چه مانیتگ نمونه هایی از آنچه که عناوین باید باشند را آزمایش کرده است. تعریف وظایف کاری آسان نیست و اغلب شما باید بر کاربرانی تاکید کنید که کار تعریفی شما را می شناسند. اما آنها که ممکن است در ابتدا درک نکنند( شاید چون آنها هنوز زبان مخصوص را نمی دانند) – برخی مردم یک عقیده واضح ندارند که چه کاری می خواهند انجام دهند، تا وقتی که کار نرم افزار را تحقیق کنند. مثلاً قرار دادن نمودار روی صفحه
شما می توانید از Wishword برای قراردادن نمودارها در هر جایی روی صفحه استفاده کنید. داخل یک جعبه با موقعیت ثابت، یا داخل یک جعبه سیال – شما می تواند مشخص کنید که نمودار یک حاشیه طراحی شده دارد یا نه- برای ثابت کردن موقعیت یک بلوک از متن مرتبط با یک نمودار، بهترین راه کاربرد امکان Fix Box است. یک FixBox برای عنوان گذاری ، جایگذاری دقیق متن براساس بخشهای نمودار شرح عملیات پیچیده در یک سطح بالا بنابراین عملکرد نقشه واضح است. ارائه جزئیات فقط درجائیکه لازم است. ارائه اطلاعات بازیابی کامل. این کم و بیش موقعیت مینی مالیست است. به طور مطلوب، وقتی که تهیه گزارش یک عملکرد کاربر لازم است، نویسنده باید اهمیت و مشکلات آن را حرج دهد ، سپس توجه خواننده به بخش ویژه را بطور کاربر و تنظیم نکات تست با اطلاعات بازیابی مفید برای وقتی کارها، اشتباه انجام می شوند- اما دستیابی به این ایده آل غیرممکن است به جز با وجود ساده ترین و بهترین نگارش نرم افزار طراحی شده برای یک تعداد محدود حضار.
برای اکثر ما گفتن مقدار اطلاعاتی که باید شامل شود و محل آنها دشوار است.
مثلاً چرا در راهنما ( یا حتی در منو (لیست)) یک پاراگراف شرح دهنده و تنظیم کننده سازمان لیست وجود ندارد! این کار می تواند مورد علاقه اکثر خوانندگان دقیق باشد.
مطمئن شوید که حس یک پاراگراف بر عنوان آن تکیه ندارد.
این یک عقیده خوب نیست که فرض کنید که خواننده می تواند یا رابطه ای را میان یک عنوان و متن آن برقرار خواهد کرد، خصوصاً وقتی که پویاها علاقه به بررسی زیر عنوان ها سرفصل ها و مقدمات به روش خود دارند تا کل مطالب را به دست آورند. در مثال زیر، خوانندگان اندکی ارتباط میان چند کاره بودن و کارهایی که متقارن هستند را ایجاد می کنند. ارتباط باید صریحاً در متن بیان شده باشد مثلاً
نگارش یک سیستم چند کاره- در یک کاربرد نمونه، یک مجموعه از پردازش اطلاعات و عملیات کنترل سیستم همگی نیازمند کنترل همزمان است. یک راه برای برآورده ساختن این نیاز نگارش وظایف جداگانه است که با یکدیگر و با استفاده ازعملکردهای استاندارد است. برای نگارش این کارها:
اطلاعات ضروری برای تکمیل کارگر را تکرار کنید، از مراجع برای اشاره به پس زمینه و اطلاعات مرتبط استفاده کنید.
وجود این عقیده که خوانندگان می توانند کار خاصی را بدون رجوع به محل دیگر انجام دهند، به جز شاید بخش دیگر صفحه مشابه است.
در مثال زیر، مراجع خوانندگان متمرکز، دقیق و متفکر را، دوباره مطمئن می سازد که نامگذاری اصول دلخواه نیست- اکثر آنها موضوع مربوط به مرجع را نمی خوانند اگر چه برخی خوانندگان دقیق برای کسب مهارت این کار را انجام می دهند.
نام کار را تایپ کرده و OK را کلیک کنید. اسامی کار باید همگی با حروف بزرگ باشند مثل TASK1 نکته : ورودی را تایپ کرده و OK را کلیک کنید هر ورودی باید یک نسخه مورد پایین تر از نام کار باشد task 1
ضمیمه2 ، شرح دهنده رسوم نامگذاری استاندارد به طور کامل است. آن همچنین شرح می دهد که چگونه اسامی توسط سیستم استفاده شده اند و نشان می دهد چرا آن اهمیت ویژه ای برای کاربرد رسوم برای کارها و نکات ورودی دارد.
استفاده از جملات با ساختار خوب و نوشته شده به صورت خلاصه و سبک نسبتاً رسمی.
این تنها و مهمترین نکته است- انواع متمرکز، پویا و دقیق نیازمند شرحهای واضح هستند: گروه متمرکز و دقیق به بحث اغواء کننده پاسخ می دهند- هیچ جانشینی برای جمله متفکرانه و ساختار پاراگراف وجود ندارد. حضور نثر به مدلیت ها یا جداول یا فقط کاهش تعداد لغات کمک نخواهد کرد.
زیاد خوب نیست- بررسی پنجره دید موضوع برای این پروژه عملاً هیچ تفاوتی میان این پروژه و مورد آخر وجود ندارد . ما هنوز هم یک کار کاربر منفرد داریم ( این بار با نام تست برای صندلی و یک نمودار حلقه ای)
بهتر:
پروژه موجود (P2) بسیار مشابه (P1) است. با قراردادن P1 و P2 در پنجره های objectview ( دیدن موضوع) به صورت جداگانه ، شما می توانید آنها را مقایسه کنید، فقط اسامی کارها و ورودی ها متفاوت هستن.
من این تکنیک ها را تست کرده در یک آزمایش کوچک که نتایج امیدوار کننده ای داشته آنها مطمئناً می توانند پالایش شده و با تحقیق بیشتر بهبود یابند.

گرایشات در تولید گزارش اتوماتیک
اگر چه برخی از کاهش آن حمایت می کنند، گزارشات کارآمدترین روش و راه ترجیح داده شده برای ارتباط اطلاعات در هر نظم مهندسی است گزارشات ( چه کپی چه الکترونیک باشند) شاهدی هستند که وظایف مهندسی اجرا شده اند.
تهیه گزارش عامل عمده هزینه نرم افزار است. بر طبق Capers jones، هزینه های مقاله می تواند بیشتر از 50 درصد کل هزینه توسعه باشد( ارزیابی نرم افزار کاربردی، تضمین بهره وری و کیفیت – Hill -1191) دیگران گزارش دادند که چگونه گزارش سازی ضعیف می تواند به طور برجسته هزینه توسعه نرم افزار و هزینه های نگهداری را افزایش دهد ( Hanna، استفاده از گزارش به عنوان یک ابزار چرخه زندگی، جمله نرم افزار، دسامبر 1992 ( Gook , Viscont ، مدل کامل فرآیند گزارش سازی سیستم، S) ، دانشگاه ایالت Oregoh 1992)
کاربرد اتوماسیون در کاهش هزینه های گزارش سازی یک عقیده امیدوار کننده است. اما اتوماتیک کردن تولید گزارش، اغلب به عنوان موضوع تسهیل تبادل اطلاعات میان ابزار توسعه نرم افزار و سیستم های انتشار گزارش دیده شده است. به عنوان یک توسعه دهنده ابزار تولید گزارش اتوماتیک شده، من می دانم که مشکل پیچیده تر از این است.
اتوماسیون کارآمد تولید گزارش به حمایت جدی از یک فرآند توسعه کامل و تصریف شده بستگی دارد. پس از آن است که می توان هزینه های تهیه گزارش را توسط تولید گزارشات به عنوان محصول فرعی این فرایند کاهش داد.
پیشینه: اتوماسیون تولید گزارش نیازمند دیدن برخی روش توسعه تصریف شده و ابزاری است که آن روش را اجرا می کند و نیز استانداردهای گزارش.
روشها: از اوائل دهه 1970، اکثر روشهای مهندسی تعریف شده، از جمله تکنیک مدل دهی موضوع ، Rumbangh ( – طراحی و مدل دهی هدف موضوع) توسعه یافته اند. این روشها فعالیت های توسعه نرم افزار را با نظم و دقت، تشدید کرد. به طور نمونه هر روش یک علائم دارد که انواع عناصر گرافیکی و متنی را شامل می شود. این عناصر ممکن است برخی بافت های مورد نیاز برای ایجاد گزارش را به دست دهد.
ابزار: ابزارهای توسعه به مهندسان کمک می کند تا اطلاعات را بر طبق روشهای اجرای ابزار توسعه دهند- این ابزار برای اتوماسیون تولید گزارش، به دلیل اطلاعات مهندسی که دارند (بافت) حیاتی هستند، اطلاعاتی که در مکانیسم ها و منبع ارائه شده برای حفظ الکترونیکی آن وجود دارند.
استانداردها: یک استاندارد دیدگاه اطلاعات مهندسی را با ویژه ساختن نوع اطلاعات بافت( بافت) تعریف می کنند، جائیکه باید قرار گیرد ( ساختار) و چگونه ارائه شود ( فرمت) این قوانین را می توان اتوماتیک کرد. استانداردها زمان ارزشمند و تلاش را ذخیره کرده و چون موجب کاهش نیاز به تولید مجدد گزارش و توانایی های ضروری برای تولید اتوماتیک آنها می شوند. اکثر سازمانهای حرفه ای و دولتی – مثل اداره دفاع آمریکا، سازمان بین المللی استاندارد سازی و IEEE – استانداردهایی را برای رسمی ساختن این ارتباط ارائه کرده اند. اکثر شرکت ها اوج استانداردها را پذیرفته یا خودشان آنها را توسعه داده اند. توسعه دهندگان به طور نمونه استانداردها را تحقیر می کنند چون مقدار زیادی تلاش غیرمهندسی برای تولید یک گزارش دارای استاندارد در بر دارد. اما استانداردها کلید اتوماسیون تولید گزارش هستند نه یک مانع.
کشیدن یا فشار دادن: بسته های گزارش سازی تجاری زیادی وجود دارند که می توانند به شمار در تعریف یک فرمت گزارش و ساختار آن کمک کنند هر کدام را که شما انتخاب کنید تعیین کننده نوع توانایی های موجود و ارائه زیربنای گزارش است ( برای یک تحقیق در مورد این ابزار، به بخش ابزار گزارش سازی نمونه توسط Melew ski، مجله نرم افزار 1992 مراجعه کنید.)
روشهای موجود برای اتوماسیون کردن تولید گزارش براساس توسعه امکانات ابزار توسعه نرم افزار و سیستم های انتشار گزارش هستند. اگر چه این روشها نوع اتوماسیون را ارائه می کنند، آنها هنوز هم وابسته به کارگر هستند- روشهای امروزی را می توان براساس "کشیدن یا فشار دادن" طبقه بندی کرد.
فشار دادن: در این روش، ابزار توسعه اطلاعات منبع خود را درون سیستم نشر گزارش وارد می کند- این توسعه دهندگان لیست تمام اطلاعات مهندسی و ساختار گزارش را در یک محل منفرد ذخیره می کنند. اما روش فشار دادن گاهی اوقات محدودیت هایی دارد.
اکثر ابزار توسعه بسیاری از خصوصیات نشر – گزارش را ارائه نمی دهند، مثل رابط Wysiwyg یا امکانات خدمت رسانی و فقط امکانات محدود کم را برای ویژه ساختن فرمت و ساختار گزارش ارائه می دهند.
اکثر توانایی های سیستم های نشر گزارش را نمی توان با ابزار توسعه کنترل کرد که این یعنی توسعه دهندگان باید گزارشات ایجاد شده را اصلاح کنند. بنابراین توسعه دهندگان تلاش زیادی را برای اصلاح مکرر نسخه های گوناگون گزارش ایجاد شده تلف می کنند.
برای بدست آوردن اطلاعات ضروری مهندسی و تولید یک گزارش، کاربر باید به طور نمونه ابزاری را برنامه ریزی کرده و بقیه را توسعه دهد.
اغلب کاربران باید همچنین برنامه ریزی میان ابزار توسعه و اطلاعات منبع آن و جای آن در یک گزارش را مشخص کنند.
وقتی ابزار متعدد توسعه استفاده می شوند، توسعه دهندگان باید امکانات تولید گزارش را دوباره ایجاد کنند چون توانایی ها در یک ابزار نمی تواند دوباره برای دیگری استفاده شود.
کشیدن: در این روش، سیستم و نشر گزارش، اطلاعات را از منبع ابزار توسعه بیرون می کشد این روش نیز محدودیت هایی دارد.
برخی سیستم های نشر گزارش نیاز دارند تا توسط توسعه دهندگان یک گزارش را با استفاده از لیست ها و برای درآوردن نمونه های کوچک اطلاعات مهندسی از منبع ایجاد کنند- این وابسته به کارگر است.
اغلب، کاربران باید فرمت و ساختار گزارش را با استفاده از سیستم تولید گزارش تعریف کنند.
معمولاً کاربران باید برنامه های اطلاعات در منبع ابزار و جای آن در یک گزارش را تعیین کنند.
سیستم های نشر گزارش اکثر توانایی های نمونه یافت شده در ابزار توسعه را ارائه نمی کنند(مثل درک و توانایی های گرافیکی ویژه روش) کاربران نمی توانند با اطمینان اطلاعات مهندسی را با این ابزار اصلاح کنند.
وقتی کاربران اطلاعات مهندسی را اصلاح می کنند در سیستم نشر گزارش آن را نمی توان در منبع اطلاعات ارتقاء داد.
توسعه دهندگان باید توانایی های گزارش سازی اتوماتیک را برای هر سیستم نشر گزارش و جفت ابزار توسعه، توسعه دهند.
یک روش بهتر- چه کشیدن، چه فشار دادن، روشهای حاضر، نیازمند تلاش ویژه برای طراحی گزارش است. یک روش بهتر باید برای ترکیب بهترین های روشهای کشیدن و فشار دادن و نیز اطلاعات موجود، باشد. هدف این روش گزارش سازی اتوماتیک مهندسی است. این هدف سه منظور دارد. کاهش تلاش، افزایش انعطاف پذیری و ارائه یک رابط مشترک و رایج کاربر.
کاهش تلاش: مهندسان باید تلاش خود را در مورد مهندسی، توسعه دهند. تلاش ضروری برای برخی وظایف گزارش سازی را می توان با ارائه نمونه های گزارش سازی کاهش داد، که ساختار و فرمت مورد نیاز توسط استانداردهای قابل کاربرد را در بردارد آن همچنین به شامل کردن دستورالعملها در مورد چگونگی توسعه گزارش و متن پیش فرض کمک کنند- مهندسان فقط نیازمند پیگیری دستورالعمل ها برای تکمیل گزارش هستند.
دریافتهای بسیار و بیشتر را می توان توسط پرکردن اتوماتیک گزارش با اطلاعات مورد نیاز به دست آورد. اما این دریافتها را فقط وقتی می توان به دست آورد که مهندسان از ابزار توسعه نرم افزار استفاده کرده و اجرای این ابزار را به روشهای تعریف شده و متصل می کنند که تولید کنند. گزارش بتواند آنها را در گزارشات ترکیب کند.
برای اتوماتیک کردن کارآمد تولید گزارش، اطلاعات زیر باید شناخته شوند:
– نوع اطلاعاتی که مهندسان توسعه می دهند.
– نحوه دستیابی به آنها.
– جایگاه مورد نیاز آنها و فرمت یک گزارش و
– فرمت دهی تسهیلات موجود
توسعه دهندگان ابزار تولید گزارش باید بدانند کدام ابزار توسعه نرم افزار و روشها به کار گرفته شده اند، چه گزارشاتی باید تولید شوند و چه نوع سیستم نشرگزارش به کار رود. آنها سپس می توانند این اطلاعات را با تولید کننده گزارش اتوماتیک شده توسط توسعه مجموعه های دانش برای هر ترکیب قابل کاربرد از ابزار توسعه، روش، استاندارد و سیستم نشر گزارش، ترکیب کنند. تصویر 1 جریان اطلاعات در این سیستم را نشان می دهد. نمونه های گزارش نگهدارنده های فضا برای اطلاعات مهندسی که استاندارد اجرایی نیاز دارد را شامل می شوند با استفاده از مجموعه های اطلاعاتی، تولید کننده گزارش اتوماتیک شده این نگهدارنده های محل برای اطلاعات ارائه شده توسط ابزار گوناگون توسعه طراحی می کند. سپس ایجاد کننده گزارش اتوماتیک، اطلاعات لازم را به دست آورده و آنها را فرمت می کند و آن را در گزارش وارد می کند بنابراین همزمانی نگهدارنده محل با اطلاعات خاص یک ترکیب روش ابزار خاص را به وجود می آورد.
انعطاف پذیری ایجاد کننده گزارش اتوماتیک باید به اندازه کافی انعطاف پذیر باشد تا اطلاعات را از منابع گوناگون ابزاری به طور همزمان تهیه کند و گزارشاتی را برای سیستم های نشر گزارش معروف ایجاد کرده و انواع گزارشات را تولید کند. بنابراین باید اطلاعات در موارد روشهای زیادی ، ابزار توسعه، استانداردها، گزارشات و سیستم های نشر گزارش داشته باشد. به علاوه کار بر باید بتواند به آسانی مجموعه های اطلاعاتی رابه کار ببرد. ایجاد کننده گزارش اتوماتیک شده باید یک مجموعه غنی و انعطاف پذیر از وسایل که کاربر بتواند برای دریافت اطلاعات کاربردی از هر ابزار توسعه به دست آورد را ارائه کند.
به علاوه، ایجاد کننده گزارش باید نمونه های گزارش را برای استانداردهای بین المللی، بازرگانی و دولتی ارائه دهد. کاربران باید بتوانند این نمونه ها را با استفاده از سیستم های معروف نشر گزارش اصلاح کند. نمونه های گزارش توسعه یافته توسط کاربر باید توسط ایجاد کننده گزارش اتوماتیک پذیرفته شود.
تولید گزارشات به طور کلی یک فرآیند تکراری است. نسخه های جدید گزارش برای ترکیب تغییرات در بافت گزارش توسعه یافته اند- این موضوع را می توان توسط ارائه کاربر، توانایی اجرای ساختهای گزارشات محدود اجرا کرد.
رابط کاربر مشترک- طراح گزارش اتوماتیک شده باید یک رابط کاربر ثابت و آشنا را ارائه دهد. این هدف دو بعد دارد ابتدا رابط کاربر باید با استانداردهای رابط – کاربر و پذیرفته شده در سطح وسیع تطبیق داشته باشد. دوم اینکه آن باید با رابط های کاربر و ابزار توسعه و سیستم های نشر گزارش که با آن ارتباط دارد، پیوسته و همراه باشد.
تهیه گزارش برای توسعه نرم افزار و نگهداری آن ضرورت دارد، اما آماده سازی دستی آن گرانقیمت است. روشهای موجود می توانند گزارشاتی را برای موارد کم هزینه تر نسبت به آماده سازی دستی تولید کنند، اما نتایج بیشتری را می توان به دست آورد. دانش روشها، استانداردها و ابزار توسعه نرم افزار و سیستم های نشر گزارش را می توان به وظایف گزارش سازی با اتوماسیون بیشتر اعمال کرد.
لاری اشتاین، نائب رئیس خدمات فنی در ATA ، توسعه دهنده بیان گزارش، یک تولید کننده گزارش اتوماتیک شده است.

فهرست مطالب
ارزش نقش ارتباط رسانهای فنی در توسعه سیستم های اطلاعاتی 13
اصطلاحات شاخص سیستم های اطلاعاتی ارتباط سازمان فنی 13
روشها 14
روش تجزیه و تحلیل های مطالعه موردی 15
بحث در مورد یافته ها 15
دیدگاه های ارتباط رسانان فنی 16
دیدگاه های کاربر: 20
نظر در مورد سیستم و پیغامهای خطا 23
تجزیه و تحلیل داده های کیفی کاربر: 23
کاربرد سبک های یادگیری در تهیه گزارش نرم افزار: 31
تغییردادن سبک ها 34
گرایشات در تولید گزارش اتوماتیک 39

1

45