ஒரு பெரிய மென்பொருள் திட்டத்தின் பல பணி நீரோடைகளை ஒருங்கிணைப்பதில் டெவலப்பர்கள் எதிர்கொள்ளும் சிரமத்திற்கு மென்பொருள் சிக்கல் வரும்.
ஒருங்கிணைந்த மேம்பாட்டு செயல்முறை (RUP) இந்த சிக்கலுக்கு ஒரு தீர்வாகும், ஏனெனில்:
- ஒரு குழுவின் செயல்பாடுகளை ஒழுங்கமைக்க ஒரு வழிகாட்டியை வழங்குகிறது. ஒவ்வொரு டெவலப்பரின் பணிகளையும் தனித்தனியாக அணியின் பணிகளையும் வழிநடத்துகிறது. உருவாக்கப்பட வேண்டிய கலைப்பொருட்களைக் குறிப்பிடுகிறது. தயாரிப்புகள், தயாரிப்புகளின் அளவீட்டு மற்றும் திட்ட நடவடிக்கைகளுக்கான அளவுகோல்களை வழங்குகிறது.
RUP மென்பொருள் திட்டங்களைத் தயாரிக்க UML ஐப் பயன்படுத்துகிறது மற்றும் நன்கு வரையறுக்கப்பட்ட இடைமுகங்களின் மூலம் ஒருவருக்கொருவர் ஒன்றோடொன்று இணைந்த மென்பொருள் கூறுகளை அடிப்படையாகக் கொண்டது. இதன் முக்கிய அம்சங்கள் என்னவென்றால், இது பயன்பாட்டு நிகழ்வுகளால் இயக்கப்படுகிறது, கட்டிடக்கலை மீது கவனம் செலுத்துகிறது மற்றும் மீண்டும் செயல்படுகிறது மற்றும் அதிகரிக்கும். வேலையை சிறிய பகுதிகளாக அல்லது சிறு திட்டங்களாகப் பிரிப்பது நடைமுறைக்குரியது, அங்கு ஒவ்வொன்றும் உற்பத்தியின் அதிகரிப்பு அல்லது பதிப்பில் விளைகின்றன.
ஒரு திட்டத்தின் வாழ்க்கைச் சுழற்சி நான்கு கட்டங்களைக் கொண்டுள்ளது: கருத்தாக்கம், விரிவாக்கம், கட்டுமானம் மற்றும் மாற்றம். ஒவ்வொரு கட்டமும் ஒரு மைல்கல்லுடன் முடிவடைகிறது, அங்கு ஒரு கலைப்பொருட்கள் (ஆவணங்கள், மாதிரிகள், இயங்கக்கூடிய குறியீடு போன்றவை) உள்ளன, அதன் மிக முக்கியமான நோக்கம் திட்ட மேலாளர்கள் அடுத்த கட்டத்திற்கு தொடர முடிவுகளை எடுக்க முடியும். வாழ்க்கை சுழற்சி கட்டங்களின் முடிவில், தயாரிப்பின் பதிப்பு முடிந்தது.
கருத்தரித்தல் கட்டத்தில், ஒரு நல்ல யோசனையின் அடிப்படையில் இறுதி தயாரிப்பு பற்றிய விளக்கம் உருவாக்கப்பட்டு தயாரிப்புக்கான வணிக பகுப்பாய்வு வழங்கப்படுகிறது.
வளர்ச்சி கட்டத்தின் போது, பெரும்பாலான தயாரிப்பு பயன்பாட்டு வழக்குகள் விரிவாக குறிப்பிடப்படுகின்றன மற்றும் கணினி கட்டமைப்பு வடிவமைக்கப்பட்டுள்ளது. இந்த கட்டத்தின் முடிவில், நடவடிக்கைகளைத் திட்டமிடவும், திட்டத்தை முடிக்க தேவையான ஆதாரங்களை மதிப்பிடவும் இயக்குனர் தயாராக உள்ளார்.
கட்டுமான கட்டத்தில் தயாரிப்பு உருவாக்கப்பட்டது, கட்டிடக்கலை ஒரு முழுமையான அமைப்பாக வளர்கிறது மற்றும் ஏற்கெனவே ஒப்புக்கொள்ளப்பட்ட அனைத்து பயன்பாட்டு நிகழ்வுகளையும் கொண்டுள்ளது.
மாற்றம் கட்டத்தில், குறைபாடுகள் மற்றும் குறைபாடுகளைக் கண்டறிய கணினி சோதனைகள் குறைந்த எண்ணிக்கையிலான பயனர்களுடன் மேற்கொள்ளப்படுகின்றன. டெவலப்பர்கள் பிழைகளை சரிசெய்து பரிந்துரைக்கப்பட்ட மேம்பாடுகளை அறிமுகப்படுத்துகிறார்கள்.
ஒவ்வொரு கட்டமும் பல மறு செய்கைகளைக் கொண்டிருக்கலாம், மேலும் ஒவ்வொரு மறு செய்கையும் பல பணிப்பாய்வு செயல்முறைகளை உள்ளடக்கும்.
ஒரு செயல்பாட்டு வழியில் பணிபுரியும் மென்பொருள் மேம்பாட்டுக் குழுக்கள் சில உறுப்பினர்களைக் கொண்டிருக்கின்றன, அவை திட்டமிடலுக்கு அப்பாற்பட்டவை மற்றும் பிற்கால மறு செய்கைகளுக்கான இலக்குகளின் தொகுப்பை அடைகின்றன. ஒன்றுடன் ஒன்று மறு செய்கை நுட்பம் புரிந்து கொள்ளப்பட்டு சரியாக கையாளப்பட்டால் நன்மை பயக்கும்.
நிலையான மறு செய்கைகள் எல் 1, எல் 2 மற்றும் எல் 3 ஆகியவை இடமிருந்து வலமாக தொடர்ச்சியாக நிகழ்கின்றன, ஒவ்வொரு மறு செய்கையுடனும் தொடர்ச்சியாக கீழ்நோக்கி நிகழ்கின்றன (தேவைகள், வடிவமைப்பு, குறியீடு மற்றும் சோதனை).
பின்வரும் வரைபடம் காண்பிக்கும்போது இந்த மறு செய்கைகள் ஒன்றுடன் ஒன்று சேரலாம்:
கீழே உள்ளவை நேர-பெட்டி நுட்பத்தால் கட்டுப்படுத்தப்படும் ஒன்றுடன் ஒன்று மறு செய்கைகளைக் காட்டுகிறது:
இந்த ஒன்றுடன் ஒன்று மறு செய்கை நுட்பம் பின்வரும் அபாயங்களைக் கொண்டுள்ளது:
- வேலையை அதிகரிக்கிறது ஒரு திட்டத்தை ரத்து செய்வதற்கான செலவை அதிகரிக்கிறது மன உறுதியைக் குறைத்தல் மேம்பாட்டு செயல்பாட்டின் தாக்கம் ஒழுக்க மனப்பான்மை நீர்வீழ்ச்சியின் ஆபத்து
திட்டத்தில் ஒன்றுடன் ஒன்று மறுதொடக்கம் செய்வதைத் தவிர்க்க, ஊழியர்களைப் பயன்படுத்தலாம்:
- இரண்டு திட்டங்கள். பல பாத்திரங்கள். நேரத்தை வீணடிக்கும் சூழ்நிலையை ஏற்றுக்கொள்ளுங்கள். குழுவின் அளவைக் குறைக்கவும்.
ஒன்றுடன் ஒன்று மறு செய்கைகள் பெரிதும் உதவக்கூடும், ஆனால் அவை கடுமையான கட்டுப்பாட்டைக் கொண்டிருக்க வேண்டும், இதனால் அவை இரட்டை முனைகள் கொண்ட வாளாக மாறாது, இதற்காக நீங்கள் இந்த இரண்டு முக்கியமான விதிகளையும் பின்பற்ற வேண்டும்:
- கட்டுமானத்தின் போது, விரிவாக்கத்தின் போது மறு செய்கைகளை ஒன்றுடன் ஒன்று அனுமதிக்க வேண்டாம். கட்டுமானத்தின் போது ஒரு மறு செய்கைக்கு அப்பால் செல்ல அனுமதிக்காதீர்கள்.
நூலியல் குறிப்புகள்:
பிலிப் க்ருச்ச்டென். "பகுத்தறிவு ஒருங்கிணைந்த செயல்முறை: ஒரு அறிமுகம்". அடிசன் - வெஸ்லி. 2000.
பாரி போஹம். "சுறுசுறுப்பான முறைகளுக்கு தயாராகுங்கள்". கணினி, பக். 64-69, 2002.
