Think Engineering
تقویم
بهمن ۱۳۹۶
ش ی د س چ پ ج
« فروردین    
 123456
۷۸۹۱۰۱۱۱۲۱۳
۱۴۱۵۱۶۱۷۱۸۱۹۲۰
۲۱۲۲۲۳۲۴۲۵۲۶۲۷
۲۸۲۹۳۰  

مهندسی نرم افزار

* این صفحه به درس مهندسی نرم افزار – دوره کارشناسی اختصاص داده شده است و شامل جزئیات مراحل پروژه، اقدامات انجام شده، پشتیبانی و مقالات پیرامون آن است.

ساختار اسناد و پروژه کلاس چین

شکل زیر ساختار اصلی پروژه و اسناد کلاس چین را نشان می دهد. شکل راهنمای کد گذاری اسناد منتشر شدهه و نگارش های مختلف سامانه کلاس چین است.

برای مشاهده نسخه با کیفیت روی عکس کلیک نمایید.

 

cc12

برنامه فاز بندی پروژه

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

 

نام فاز

هدف فاز

دستاورد ها و فراورده ها

تاریخ اتمام

یک

  • شناخت محدوده سامانه
  • شناخت کنش گرها[۱]
  • شناخت جزئیات موارد کاربرد[۲]
  • نمودار موارد کاربرد[۳]
  • مشخصات موارد کاربرد[۴]
  • فهرست مستندات
  • واژه نامه

۲۰/۱۲/۱۳۹۲

دو

  • کشف نیازمندی های غیر وظیفه ای سامانه
  • کشف نیازهای اظهار نشده
  • کشف نیازهای پنهان
  • درک کلی از ساز و کار سامانه و جزئیات امکانات

  • مشخصات تکمیلی
  • نمونه اولیه واسط کاربری
  • اطلاعات آماری برنامه

۲۷/۷/۱۳۹۲

سه

  • مدل سازی جریان کاری موارد کاربرد در قالب نمودار فعالیت
  • ارائه کلاس ها مورد نظر جهت تحقق آن

  • نمودار کلاس[۵]
  • نمودارهای فعالیت[۶]

۰۵/۰۱/۱۳۹۳

چهار

  • تعیین چگونگی انجام وظایف سیستم توسط کلاس های تحلیل
  • باز مهندسی معماری سامانه
  • برنامه ریزیiteration  های فاز بسط[۷]
  • نمودار ترتیب[۸]
  • طراحی اولیه
  • بسط اولیه

۱۲/۰۱/۱۳۹۳

پنج

  • طراحی package ها و کلاس های فاز طراحی
  • ارتباط بین کلاس ها
  • طراحی اولیه بانک اطلاعات
  • یک نمونه قابل اجرا از برنامه
  • شمای اولیه پایگاه داده[۹]
  • نمونه اولیه قابل اجرا[۱۰] (نسخه آلفا-۱)

۱۹/۰۱/۱۳۹۳

شش

  • تکمیل فاز پنج  (تکمیل نمودار کلاس ها، تکمیل ساختمان پایگاه داده و تکمیل نمونه قابل اجرا)
  • تکمیل نمونه اولیه قابل اجرا (نسخه آلفا-۲)
  • آزمون تست اول
  • نمودار مؤلفه ها

۲۶/۰۱/۱۳۹۳

هفت

  • توصیف دقیق نحوه همکاری کلاس ها در لایه ها
  • معماری MVC  برنامه
  • ارتباط بین لایه های سه گانه
  • نمودار توالی نهایی
  • جزئیات نهایی سامانه
  • نسخه آلفا -۳

۰۲/۰۲/۱۳۹۳

هشت

  • بررسی سطوح نرمال و کارکرد پایگاه داده
  • جزئیات پیاده سازی گزارشات
  • تکمیل سامانه
  • شمای پایگاه داده نرمال شده
  • راهکارهای شبکه و قابلیت حمل سامانه

۰۹/۰۲/۱۳۹۳

نه

  • ارائه مستند جهت کاربرد نرم افزار و استفاده از آن توسط کاربران هدف
  • ایجاد راهنمای برنامه
  • مستند کاربرد
  • نسخه بتا
  • نصب و اجرای آزمایشی در شبکه

۱۶/۰۲/۱۳۹۳

ده

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

۲۳/۰۲/۱۳۹۳

  • پاورقی اصطلاحات:


    [۱] Users and Administrators

    [۲] Use Case Details

    [۳] Use Case Diagram

    [۴] Use Case Description

    [۵]  Class Diagram

    [۶]  Activity Diagram

    [۷]  Elaboration

    [۸]  Sequence Diagram

    [۹]  Database Schema

    [۱۰]  First Prototype) as alpha-1 version)

    جزئیات فازها به زودی منتشر می گردد.

معرفی سامانه نرم افزاری جامع دانشگاهی

UNIVERSAL VIEW

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

منظور از یک نهاد آموزشی در این تعریف، دانشگاه، مدرسه، موسسه های آموزشی آزاد و هر بنیاد آموزشی دیگری از این دست می باشد. در نگاه اول، انتظار وجود یک سامانه واحد و جامع برای سازمان دهی همه موارد ذکر شده، کمی دور از ذهن و تا حدودی نا ممکن به نظر می رسد. در واقع برقراری یک ارتباط منطقی بین اجزا موجود در این سامانه امری مشکل و نیازمند توجه است. این ارتباط در از دو جنبه[۱] متفاوت مطرح و قابل بررسی است.

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

اولین و بارز ترین وجه مشترک، وجود کاربران و افرادی است که با هریک از این سامانه ها در ارتباط اند. در نهاد آموزشی دانشگاه، دانشجویان، اساتید، کارمندان و مدیران، مجموعه همه کاربران را تشکیل می دهند. داشتن اتوماسیون های مختلف برای قسمت های مختلف نیازمند نگهداری اطلاعات به صورت تکراری و همراه با افزونگی، وجود مشکلات به همگام سازی داده و … می باشد. از طرفی کاربر نیز می بایست جهت انجام هریک از کارهای خود به قسمت مربوط مراجعه نماید که بعضا سختی های را به دنبال دارد.

با ریز شدن در تحلیل سیستم ها، می توان وابستگی های دیگر را نیز درک نمود. فرضا این که پایان یافتن ترم در یک دانشگاه، سامانه تغذیه نیز موقتا بسته شود.

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

 


[۱] aspect