Yangi korxona axborot tizimini joriy etish. Korxonada axborot tizimlarini ishlab chiqish va joriy etish. Axborot tizimlarini joriy etish

Ilovalarni ishlab chiqishda boshqa yondashuvlar

Odatda, oxirgi foydalanuvchilar va menejment dizayn jarayoni hech qanday natija bermagan deb hisoblaydi, chunki "teginish" uchun tayyor komponentlar mavjud emas. Ko'pincha buyurtmachi biron bir natija olish va uni imkon qadar tezroq namoyish etish uchun loyihani amalga oshirish bosqichini erta amalga oshirishni talab qiladi. Bunday holda, tezlashtirilgan dastur ishlab chiqish (ERD) yoki birgalikda dastur ishlab chiqish (CWD) ni tanlash uchun katta vasvasa mavjud. Bunday usullar ishchi prototipni ishlab chiqishni va keyinchalik foydalanuvchilarga namoyish etishni o'z ichiga oladi. Foydalanuvchilar nimani yoqtirishlarini va nima yoqmasligini qayd etishadi. Dizayner prototipni sharhlarni hisobga olgan holda yakunlaydi va keyin yana nima bo'lganligini namoyish etadi. Va boshqalar. Jarayon foydalanuvchilar ko'rgan narsalarini yoqtirguncha takrorlanadi va prototip ishchi dasturga aylanadi. Odatda vaqt chegarasi va takrorlanish soni mavjud, aks holda foydalanuvchilar prototipni abadiy takomillashtirib boradilar. Nazariy jihatdan, bu sizga foydalanuvchilar xohlagan tizimni olishga imkon beradi. Amalda, dasturni ishlab chiqishda ushbu yondashuv jiddiy muammolarga duch keladi.

• 
  Barcha e'tibor ekran shakllariga qaratilgan va ma'lumotlarni qayta ishlash qoidalari va tizim funktsiyalari bilan bog'liq bo'lgan narsalar parda ortida qolmoqda. Hisobotlar bilan ishlashni boshlash vasvasasi mavjud, hisobot esa boshlang'ich emas, balki axborot tizimining hosilasi.
  
• 
  Foydalanuvchilar agar prototip varianti kelishilgan bo'lsa, u holda modul tayyor deb hisoblaydi. Aslida, bu faqat tizim funktsiyalariga qo'ng'iroqlar va boshqa modullar bilan o'zaro aloqalar uchun "stub" to'plami bo'lgan rasm bo'lishi mumkin.
  
• 
  Modullar bir-biridan ajratilgan holda ishlab chiqilgan (ehtimol sizning ko'pchiligingiz har bir AWP avtonom bo'lgan va funktsiyalari ko'pincha takrorlanadigan buxgalteriya dasturlariga duch kelgansiz). Buning natijasi modullarning ziddiyatlari, funktsiyalar va ma'lumotlarning takrorlanishi bo'lib, ular faqat modullar majmuasini sinovdan o'tkazishda aniqlanishi mumkin.
  
• 
  Funktsionallik bir necha yo'nalishda parallel ravishda o'rnatiladi, ya'ni ma'lumotlar bazasi tuzilishi qat'iy nazorat qilinishi kerak. RBM bilan ma'lumotlar bazasi sxemasi axlatxonaga aylanadi, bu erda jadvallar shoshilinch ravishda "shakllantiriladi", natijada ziddiyatli va takroriy ma'lumotlar to'plami paydo bo'ladi.
  
• 
  Qoida tariqasida, RBM usulidan foydalanishda hech qanday hujjat yo'q, aksincha tizimni hujjatlashtirish zarurati unutilgan, chunki foydalanuvchi nima bo'layotganini allaqachon tushunib etadigan illyuziya yaratiladi. Ilova foydalanuvchi kutganidan boshqacha ishlay boshlaganda juda ko'p muammolar paydo bo'ladi.
  
• 
  Istisnolardan foydalanish har bir modul uchun har xil.
  
• 
  Barkamol tizim, qoida tariqasida, ishlamaydi; ehtimol, bu shoshilinch ravishda o'zaro bog'liq bo'lgan ma'lum avtomatlashtirilgan ish stantsiyalari to'plami bo'ladi.
  

CPM va PSA usullaridan har doim ham foydalanish mumkin emas, faqat:

• 
  loyihaning ko'lami va biznesga qo'yiladigan talablar aniq belgilangan, o'zgarmaydi va loyihaning o'zi kichik;
  
• 
  loyiha biznesni avtomatlashtirishning boshqa vositalariga bog'liq emas, siz hal qilishingiz kerak bo'lgan tashqi interfeyslarning soni cheklangan;
  
• 
  tizim ekran shakllariga yo'naltirilgan, ma'lumotlarni qayta ishlash va tizim funktsiyalari ahamiyatsiz qism, ekran shakllarining qulayligi loyihaning muvaffaqiyati uchun beshta muhim omillardan biri;
  
• 
  foydalanuvchilar yuqori malakaga ega va a priori yangi dasturiy ta'minot yaratish g'oyasini ijobiy baholaydi.
  

Shu bilan birga, ERM usuli yordamida loyihaning kichik va afzalroq mustaqil qismlarini ishlab chiqish yaxshiroqdir.
Hozirda loyihani tezda yozishning yana bir usuli - ekstremal dasturlash usulini taqdim etishga urinish qilingan. Ushbu yondashuv printsiplari quyida muhokama qilinadi.
O'yinni rejalashtirish. Dasturchilar tomonidan tuzilgan taxminlarga asoslanib, mijoz tizim versiyalarining funktsional imkoniyatlarini va amalga oshirish muddatini belgilaydi. Dasturchilar ma'lum bir takrorlashda tanlangan funktsiyalar uchun zarur bo'lgan xususiyatlarni amalga oshiradilar.
Bunday qaror natijasida tizimning rivojlanishi parda ortida qolmoqda, natijada rivojlanish jarayonida "stublar" qurish va kodni qayta yozish kerak bo'ladi. Mijoz nima uchun amalga oshirish muddatini belgilashi aniq emas, chunki aslida bu loyihalash guruhining bevosita mas'uliyati. Umuman aytganda, buyurtmachi faqat vaqt oralig'idagi istaklarini bildirishi mumkin ("Men buni falon sanaga qadar bo'lishini xohlayman"), lekin faqat dizayner ushbu terminni aniqlay oladi ("falonchidan kam bo'lmagan miqdorda amalga oshiriladi" vaqt »).
Versiyalarning tez-tez o'zgarishi (kichik versiyalar). Tizim ishga tushirilgandan bir necha oy o'tgach, barcha muammolarning yakuniy echimini kutmasdan foydalanishga topshiriladi. Yangi versiyalarning chiqarilishi kunlikdan oylikgacha bo'lishi mumkin.
Hamma narsa yaxshi, faqat bitta narsa bundan mustasno: bunday davrda ozmi-ko'pmi murakkab komponentni sinab ko'rish mumkin emas. Mijoz aslida beta-tester vazifasini bajaradi. Bunday holda, u ishlab chiquvchilar qattiq ishlayotganini va hatto xatolarni tuzatayotganini ko'rishi mumkin. Biroq, oqilona savollar tug'iladi: mijozni ish oqimiga boshlash bunga loyiqmi va ish tizimida tajribalar o'rnatish kerakmi? Yuqorida aytib o'tilganlardan tashqari, shuni ta'kidlash kerakki, bunday tamoyil loyihaning 24x7 ishlashni talab qiladigan qismlari uchun amalga oshirilishi mumkin emas.
Metafora. Tizimning umumiy ko'rinishi metafora yoki metafora to'plami yordamida aniqlanadi, ular ustida mijoz va dasturchilar birgalikda ishlaydi.
Bir tomondan, bu postulat yaxshi ko'rinadi, ammo boshqa tomondan, mijozni rivojlanish guruhining ichki ishlariga bag'ishlash mantiqiymi? Umumiy ko'rinishga (interfeyslarga, hisobotlarga va boshqalarga) tegishli narsa, albatta, mijozning vakolatiga tegishli bo'lishi mumkin, ammo ba'zi tarkibiy qismlarni amalga oshirish xususiyatlari haqida gap ketganda, mijoz zarur bilimlarning etishmasligi tufayli foydali bo'lishi mumkin emas. ...
Oddiy dizayn. Vaqtning har bir lahzasida ishlab chiqilayotgan tizim barcha testlarni bajaradi va dasturchi tomonidan belgilangan barcha munosabatlarni qo'llab-quvvatlaydi, takroriy kodga ega emas va sinflar va usullarning mumkin bo'lgan minimal sonini o'z ichiga oladi. Ushbu qoidani qisqacha quyidagicha ifodalash mumkin: "Har bir fikrni bir marta va faqat bir marta shakllantirish".
Bu g'oya ham yaxshi, lekin u tezda kodni yozish printsipiga to'g'ri kelmaydi. Ehtimol, siz avvalambor ma'lum bir modulni, modullar guruhini qanday yaratishni o'ylab, shundan keyingina kod yozishni boshlashingiz kerakmi?
Sinovlar. Dasturchilar doimiy ravishda birlik testlarini yozadilar. Birgalikda ushbu testlar to'g'ri ishlashi kerak. Takrorlash bosqichlari uchun mijozlar funktsional testlarni yozadilar, ular ham to'g'ri ishlashi kerak. Biroq, amalda bunga har doim ham erishish mumkin emas. To'g'ri qarorni qabul qilish uchun siz ma'lum bir nuqsonli tizimni qaytarish uchun qancha pul sarflashini tushunishingiz kerak va buni nuqsonni bartaraf etishdagi kechikish narxi bilan taqqoslashingiz kerak.
Dasturchilarning o'zlari tomonidan testlarni yozishda (ayniqsa, ortiqcha ish sharoitida) ushbu testlar to'liq ishlamaydi va bundan ham ko'p foydalanuvchi ishlashning o'ziga xos xususiyatlarini hisobga olmaydi. Odatda ishlab chiquvchilar yanada takomillashtirilgan testlar uchun etarli vaqtga ega emaslar. Siz, albatta, o'sha odamlar hamma narsani qiladigan darajada rivojlanish tizimini yaratishingiz mumkin, ammo baribir siz loyihani "O'z rejissyoringiz" teleshousining analogiga aylantirmasligingiz kerak. Aytilganlarga qo'shimcha qilish kerakki, tizimni sinash umuman komponentlar (birliklar) sinovlari bilan cheklanmaydi; ular o'rtasidagi o'zaro ta'sir sinovlari kam ahamiyatga ega emas, xuddi shu narsa ishning ishonchliligi testlariga ham tegishli. Shunga qaramay, ekstremal dasturlash usuli ushbu sinf testlarini yaratishni ta'minlamaydi. Buning sababi shundaki, bunday testlarning o'zi ancha murakkab kodni ifodalashi mumkin (bu, ayniqsa, tizimning haqiqiy ishini simulyatsiya qiladigan testlar uchun to'g'ri keladi). Ushbu texnologiya yana bir muhim test sinfi - qayta ishlangan ma'lumotlarning ko'payishi bilan tizimning xatti-harakatlari testlarini hisobga olmaydi. Versiyalarni o'zgartirish tezligining yuqori darajasi bilan texnologik jihatdan bunday testni amalga oshirish mumkin emas, chunki uni amalga oshirish uchun barqaror va o'zgarmas loyiha kodi kerak, masalan, bir hafta ichida. Umuman aytganda, versiyalar tez-tez o'zgarib turishi sababli bunday sanalarga kafolat berilmaydi. Bunday holda, siz komponentlarning rivojlanishini to'xtatib qo'yishingiz yoki sinov davomiyligi davomida loyihaning parallel versiyasini yaratishingiz kerak bo'ladi, bu o'zgarishsiz qoladi, ikkinchisi esa o'zgaradi. Keyin kodni birlashtirish jarayonini bajarishingiz kerak bo'ladi. Ammo bu holda testni qayta yaratish kerak bo'ladi, chunki ekstremal dasturlash usullari ma'lum o'zgarishlarda tizimning xatti-harakatini bashorat qilishga imkon beradigan vositalarni ishlab chiqishni ta'minlamaydi.
Qayta ishlash tizimi. Tizim arxitekturasi doimo rivojlanib boradi. Amaldagi loyiha o'zgartirilmoqda, shu bilan birga barcha testlar to'g'ri ishlashini ta'minlaydi.
Qiziqarli joy shu erda boshlanadi. Ekstremal dasturlash, uni har doim takrorlashingiz mumkin va hech qanday maxsus xarajatsiz. Biroq, amaliyot aksini ko'rsatadi.
Dasturlashning juftligi. Barcha loyiha kodlari bitta ish stoli tizimidan foydalanadigan ikki kishi tomonidan yozilgan.
Savol tug'iladi: kimdir bir-biriga to'liq o'xshash ikkita dasturchini ko'rganmi, ularning har biri, shuningdek, ish kuni oxirida sherik uchun hujjatlarni yozish uchun vaqt topishi mumkinmi? Hamma narsaga rozi bo'lgan bunday egizak dasturchilarni topa olasizmi?
Va eng muhimi, nega bizga bunday juft dasturchilar kerak? Umuman olganda, buning sababi oddiy: har kim ham haddan tashqari dasturlash orqali yuklangan ishning yuqori sur'atiga dosh berolmaydi, xodimlarning chiqib ketishi muqarrar. Bunday juftlik qandaydir sug'urtani taqdim etishi mumkin - agar kimdir iste'foga chiqsa, ehtimol, ikkinchisi bu masalani oxirigacha etkazadi. To'g'ri, qolganlari yanada qattiqroq vaqt oralig'iga tushib qoladi - axir, ish hajmi bir xil bo'lib qoladi va hech bo'lmaganda bir muncha vaqt o'qimaganlar bo'lmaydi. Buning ortidan ma'lumotni yangi zaxira nusxasiga o'tkazishning tabiiy jarayoni davom etadi, bu yana vaqt talab etadi. Va shunga o'xshash cheksiz.
Doimiy integratsiya. Yangi kod mavjud tizimga bir necha soatdan kechiktirmasdan kiritilgan. Shundan so'ng, tizim bitta butunga yig'iladi va barcha testlar bajariladi. Agar ulardan kamida bittasi to'g'ri bajarilmagan bo'lsa, kiritilgan o'zgarishlar bekor qilinadi.
Ushbu postulat hech bo'lmaganda munozarali tarzda taqdim etilgan, chunki xatolarni kim nafaqat mahalliy, balki kim ham tuzatishi aniq emas induktsiya qilingan noto'g'ri kod. Axir, ushbu bosqichda murakkab sinovlar kutilmaydi, qo'shimcha ravishda xato aniqlangan taqdirda ham o'zgarishlar qoladi. Shu bilan birga, ekstremal dasturlash usuli xatolarni kuzatish tizimini ta'minlamaydi.
Kollektiv mulk Har qanday dasturchi istalgan vaqtda tizimdagi kodning istalgan qismini takomillashtirish imkoniyatiga ega, agar kerak deb hisoblasa.
Bu sizga anarxiyani eslatmaydimi? Ushbu holatda o'zgarishlar muallifini qanday topish mumkin? Katta loyihani ishlab chiqishda, kimdir bunday "barcha savdo-sotiq doklari" bilan uchrashganmi va bunday "hunarmand" o'z ish joyida qancha ushlab turishi mumkin edi? To'g'ri, juda uzoq emas.
Doimiy ishtirok etgan mijoz (saytdagi mijoz). Tizimda ishlash davrida ishlab chiquvchilar guruhida bo'lgan mijoz.
Bu, albatta, yaxshi, ammo maqsadi aniq emas: yoki buyurtmachini masalaning mohiyatiga bag'ishlash yoki uni hammuallifga aylantirishmi? Faqatgina mijozda bunday yuqori malakali mutaxassis bo'lishi ehtimoldan yiroq emas.
40 soatlik hafta (40 soatlik hafta). Ishdan tashqari ish vaqti bir ish haftasidan oshmasligi kerak. Hatto tez-tez takrorlanadigan ishdan tashqari ishlarning alohida holatlari ham shoshilinch ravishda hal qilinishi kerak bo'lgan jiddiy muammolarning signalidir.
Ekstremal dasturlardan foydalanish amaliyoti ko'rsatib turibdiki (ushbu uslub tarafdorlari tomonidan keltirilgan bir qator ijobiy misollarga qaramay), bu yondashuv bilan ortiqcha ish qoida, istisno emas va bu holatda muammolar bilan kurashish doimiy hodisadir. U mahsulotning joriy xom versiyasini keyingi, yana xom, versiyasiga almashtirish davrida kuchayadi. Jarayonga bag'ishlangan mijoz tizim xatolarining namoyon bo'lishining barcha zavqlarini o'zida sezadi. Sizningcha, mijoz ushbu holatda qancha vaqtgacha sabr qiladi? Unga tizim ishlashi kerak ...
Ochiq ish maydoni Rivojlanish guruhi kichik xonalar bilan o'ralgan katta xonada joylashgan. Ish joyining markazida dasturchilar juftlari ishlaydigan kompyuterlar o'rnatilgan.
Bundan tashqari, bularning barchasi, avvalgi printsiplarga binoan, mijozning hududida joylashgan bo'lishi kerak, chunki u rivojlanish jarayonida juda faol ishtirok etmoqda. Savol tug'iladi: bunday muvaffaqiyatli tasodif haqiqatmi?
Faqat qoidalardan boshqa narsa yo'q. Ekstremal dasturlash texnologiyasi bilan shug'ullanadigan guruh a'zolari belgilangan qoidalarga rioya qilishni o'z zimmalariga oladilar. Biroq, bu qoidalardan boshqa narsa emas va agar jamoa a'zolari kiritilgan o'zgarishlar bo'yicha printsipial kelishuvga erishgan bo'lsalar, jamoa ularni istalgan vaqtda o'zgartirishi mumkin.
Ehtimol, oxir-oqibat bitta foydali qoida ishlab chiqilishi mumkin: "avval o'ylab ko'ring, keyin bajaring." Bunday holda, biz "palapartishlik" ga juda o'xshash sxemaga ega bo'lamiz. Negadir ekstremal dasturlash tarafdorlari "sharshara" va uning klonlaridan foydalanishda rivojlanish tsikli uzoq bo'lishi kerakligiga aminlar. Bunday ishonchga nima sabab bo'lganligi aniq emas. Axir, loyihani bosqichlarga bo'lish taqiqlangan emas. Ba'zi sabablarga ko'ra rejalashtirish bir martalik va o'zgarmas bo'ladi, deb ishonishadi, garchi bu haqiqatga to'g'ri kelmasa, shu bilan birga "palapartishlik" holatida ham.
Natijada, biz juda o'zgaruvchan loyiha talablariga juda mos keladigan, ammo shu bilan bir qatorda jiddiy kamchiliklardan xoli bo'lmagan usulni qo'lga kiritamiz. Oxirgi holat ushbu usulni yuqori yoki hech bo'lmaganda operatsion ishonchliligini talab qiladigan loyihalarda foydalanish uchun tavsiya etishimizga imkon bermaydi.
ComputerPress 2 "2002 yil
Tafsilotlar Nashr qilingan: 14.07.2018 21:24: Korporativ axborot tizimlarini joriy etishning asosiy bosqichlari ko'rib chiqilmoqda. Bundan tashqari, har bir bosqich uchun loyiha hujjatlarini ko'rib chiqish amalga oshiriladi va ma'lum bir bosqich ma'lumotlarining keyingi bosqichlar hujjatlariga bog'liqligi namoyish etiladi.