Систем хөгжүүлэлтийг захиалагч болох хэрэглэгч талын хариуцах хамтын ажиллагааны үүрэг гэж юу вэ?

Систем хөгжүүлэх ажил нь хөгжүүлэгдэж буй системийн хэмжээ их байх тусам, олон хүний гар болон цаг хугацааг шаардлагатай болгодог. Иймд тэнд, систем хөгжүүлэх үүрэг хүлээсэн вендор тал болон системийг захиалагч хэрэглэгч талд мөн тодорхой хамтын ажиллагааны үүрэг хүлээлгэх шаардлага гардаг.
Энэ нь энгийн бараа бүтээгдэхүүний захиалга ба хүлээн авалттай харьцуулахад өөр зүйл юм. Жишээ нь, IT систем биш харин захиалгат хувцасны дэлгүүрээс өөрийн хэмжээнд тохируулан хувцас захиалах үед, захиалагч буюу хэрэглэгч тал тусгайлан “үүрэг” хүлээхгүй. “Үүрэг” хүлээх нь зөвхөн захиалгыг хүлээн авсан хувцасны дэлгүүр буюу вендор тал юм. Олон хүний гар болон цаг хугацааг шаардлагатай IT системийн учир, хэрэглэгч тал вендортай “хамтран ажиллах” шаардлагатай байдлыг хэлнэ.
Энэхүү нийтлэлд, вендорт зөвхөн даатгалгүй систем хөгжүүлэх ажилд захиалагч талын хууль ёсны ямар үүргүүд байдаг талаар тайлбарлана.
Өөрийн компанийн систем болохоор бүхнийг “бүтэн бүтэнхийг” шилжүүлэхэд зогсохгүй
Нэг систем хөгжүүлэх төслийн хүрээнд олон хүн болон байгууллага хамрагдах нь элбэг байдаг. Код бичих технологид туршлагатай инженер, программист нар гэх мэтчилэн, тэдгээрийн гаргасан ажлыг нэгдсэн үр дүнд хүргэхийн тулд төслийн менежерийн үүрэг чухал болдог.
Гэвч, вендор тал хэрхэн өндөр техник, зохион байгуулалтын чадвартай байлаа ч, систем хөгжүүлэх ажлыг вендорын ганцаарчилсан хүчээр гүйцэтгэх боломжгүй. Жишээ нь, тухайн компанийн дотооддоо хэрэглэдэг хэллэг эсвэл тухайн компанийн онцлог үйл ажиллагааны мэдлэг зэрэг нь вендор талын ганцаарчилсан хүчин чармайлтаар мэдэх боломжгүй. Томоохон систем хөгжүүлэх тусам, ерөнхийдөө, тухайн системийг ашиглах компани нь олон хүн болон үйл ажиллагааг эзэмшдэг томоохон байгууллага байдаг. Систем хөгжүүлэх төслийг амжилттай болгохын тулд, үнэндээ компьютерийн ажил хийхээс өмнө, эдгээр бизнесийн логикийг зохицуулах нь ихэвчлэн чухал үүрэгтэй байдаг.
Иймд, хэрэглэгч тал “Би IT технологийн мэргэжилтэн биш” гэсэн шалтгаанаар хүлээн зөвшөөрч байхаас илүүтэйгээр, идэвхтэй мэдээлэл өгөх замаар төслийн явцыг зөвхөн тэгш бус, бас тасралтгүй урагшлуулах боломжтой. Энэ утгаараа, систем хөгжүүлэх төслийн хүрээнд хэрэглэгч талын гүйцэтгэх үүрэг гэдэг нь үнэндээ бага зэрэг биш гэдгийг ойлгох хэрэгтэй.
Шүүхийн шийдвэрийг үндэслэсэн хэрэглэгчийн талын хамтын ажиллагааны үүрэг гэж юу вэ

Тэгвэл систем хөгжүүлэлтийн төслийн хүрээнд хэрэглэгчийн талын хамтын ажиллагааны үүрэг гэж яг юу байдаг вэ? Энэ асуудалд шүүхийн өмнөх шийдвэрүүдээс олон чухал заавар үлдээгдсэн байдаг.
Шүүх хуралдаанаар, үйлдвэрлэгчийн талын (буруутай) хүргэлтийн хугацаа хоцрохтой холбоотойгоор, хэрэглэгчийн талын (өмгөөлөгч) шийдвэр гаргахад хоцролт гарсан зэрэг нь хэрэглэгчийн хөгжүүлэлтэд хамтран ажиллах үүргийн байна, байхгүйг маргааны цэг болгон авч үзсэн. Энэ асуудлаар шүүх хэрэглэгчийн талын хамтын ажиллагааны үүргийн зөрчлийг хүлээн зөвшөөрч, үйлдвэрлэгчийн талын гэрээ биелүүлэх үүргийн хариуцлагыг үгүйсгэсэн. (Гэрээг цуцлах талаар зөвшөөрсөн ч, энд ч бас зургаан хувийн алдааг хариуцлагаас хасахыг зөвшөөрсөн байна.)
Энэхүү тохиолдлын компьютерийн систем хөгжүүлэх гэрээ нь хэрэглэгчийн шаардлагад нийцсэн, өөрөөр хэлбэл, захиалгат систем хөгжүүлэх гэрээ бөгөөд ийм захиалгат систем хөгжүүлэх гэрээнд гүйцэтгэгч (вендор) ганцаараа системийг бүрэн боловсруулж дуусгах боломжгүй бөгөөд захиалагч (хэрэглэгч) нь хөгжүүлэлтийн явцад дотоодын саналыг зөв зохицуулж, ойлголтыг нэгтгэсний дараа, ямар чанартай функцүүдийг хүсч байгаагаа тодорхойлж, гүйцэтгэгчтэй хамтран тухайн функцүүдийг судалж, сүүлд нь функцүүдийг шийдвэрлэх, мөн, дэлгэцийн болон тайлангийн загварыг шийдвэрлэх, үр дүнгийн хүлээн авалт хийх зэрэг үүрэг хуваарилалтыг хийх шаардлагатай байдаг.
Токио дүүргийн шүүхийн 2004 (Хэйсэй 16) оны 3-р сарын 10-ны шийдвэр
Энэхүү шийдвэр нь систем хөгжүүлэлт нь хэрэглэгчийн талтай хамтран ажиллах явц болохыг зөвхөн тодорхойлсон биш, “ямар конкрет хэсэгт хамтран ажиллах ёстой вэ” гэдэгт тодорхойлолт өгсөн нь маш сонирхолтой байна гэж бодож байна.
Дээрх шүүхийн шийдвэрийн үгсийг систем хөгжүүлэлтийн IT терминүүдэд хөрвүүлж үзье.
Сүүлд нь функцүүдийг шийдвэрлэх… → Шаардлага тодорхойлох: Ямар чанартай функцүүдтэй систем бүтээхийг хүсч байгаагаа тодорхойлох |
Дэлгэцийн болон тайлангийн загварыг шийдвэрлэх… → Үндсэн төлөвлөгөө: Дэлгэц болон тайлангийн загвар зэргийг, системийг ашиглах хүний өмнөөс харахад системийн гадаад төрхийг төлөвлөх |
Үр дүнгийн хүлээн авалт… → Тест: Үзүүлэлтүүдийг шалгаж, DB дамп зэрэг баримт бичгүүдтэй хамт баталгаажуулж, хүлээн авах. |
Ийм байдлаар зохион байгуулж болно. Эдгээр нь бүгд IT системийн талаарх мэргэжлийн ур чадвар хэрэгтэй ч гэсэн, хэрэглэгчийн хамтын ажиллагаагүйгээр ганцаараа хийж болохгүй зүйлс юм. Хүсч буй функцүүд болон дэлгэцийн зохион байгуулалт ямар байх ёстойг үндсэндээ хэрэглэгч тодорхойлох ёстой бөгөөд мөн хүссэн зүйлсээ хэрэгжүүлсэн эсэхийг зөвхөн хэрэглэгч л шалгаж чадна.
Түүнчлэн, вендорт проектын удирдлагын үүрэг хүлээлгэсэнтэй адил хэрэглэгчид ч хамтын ажиллагааны үүрэг хүлээлгэсэн байдаг тул, хэрэглэгч дээрх процесст хамтын ажиллагааны үүрэг зөрчвөл, эсрэгээрээ вендор хэрэглэгчид гэрээ биелүүлээгүй буюу хууль бус үйлдэлд суурилсан хохирол б compensах төлбөр хүсэх магадлалтай гэж үзэж болно.
Хэрэглэгчийн хийсэн үйлдлийн дараах шаардлага хэрхэн ойлгогдох вэ

Мөн, системийн хөгжүүлэлтийн төсөл нь хэрэглэгч ба ханган нийлүүлэгчийн хамтарсан ажил гэдгийг үндэслэвэл, энэ нь илүү хөгжилтэй хэлэлцүүлэг рүү хөтлөгдөх болно. Тухайлбал, “Хэрэглэгч нь үйлдлийн дараа нэмэлт болон засварын ажлыг хүссэн бөгөөд энэ нь хүргэлтийн хугацааг барихад хүндрэл учруулсан тохиолдолд, эцсийн эцэст хэн хариуцлага хүлээх вэ?” гэсэн асуудал гарч ирнэ.
Системийн хөгжүүлэлт нь ерөнхийдөө, шаардлагын тодорхойлолт эхлэн, үндсэн төлөвлөгөө, дэлгэрэнгүй төлөвлөгөө, үйлдвэрлэл (програм хангамжийн хэрэгжүүлэлт), тест гэх мэт дарааллаар, буцах үйл явц багатай байхаар зорилго тавьдаг (ерөнхийдөө Усан цахилгаан загвар гэж нэрлэдэг). Гэвч ямар нэг шалтгаанаар өмнөх шатанд дутагдал гарсан нь илэрсэн тохиолдолд, явцад буцах үйл явц гарах нь бодит байдлаар тогтмол тохиолддог.
Ийм тохиолдолд хүргэлтийн хугацаанд хүрэхгүй бол яах вэ? Өнгөрсөн шүүхийн шийдвэрийг уншихад, нэмэлт ажлын гарсан цаг хугацааны хамааралтайгаар дүгнэлтэд ялгаа гарч байгаа нь харагдаж байна.
Нэмэлт ажлын гүйцэтгэл нь гадаад төлөвлөгөө болон бусад тодорхойлолтуудаас өмнө байсан тохиолдолд
Өмнөх шүүхийн шийдвэр нь үндсэн төлөвлөгөөний үеэр (програм хангамжийг хэрэгжүүлэх шатнаас өмнө) хэрэглэгчээс ирсэн нэмэлт хөгжүүлэлтийн хүсэлтийг авсантай холбоотойгоор, ийм хүсэлт гаргах нь өөрөө хамтын ажиллагааны үүрэг зөрчсөн гэж үзэхгүй гэдгийг мөн тэмдэглэсэн байдаг.
Хэрэглэгч нь үйлчлүүлэгчид хандахдаа, үндсэн төлөвлөгөөний үеэр байгуулагдах системд холбогдох олон төрлийн шаардлага тавих нь, энэ тохиолдолд шиг систем хөгжүүлэлтийн явцад естой л хэвийн зүйл бөгөөд, түүнчлэн, мэргэжлийн мэдлэггүй хэрэглэгч нь, тухайн шаардлага нь нэмэлт үйлчилгээний хураамж эсвэл хүргэлтийн хугацааг сунгах зэрэг зүйлсийг шаардаж байгаа эсэх, ажлын явцад саад учруулах эсэх гэх мэт зүйлсийг зөв шийдвэрлэх нь хэцүү байсан учраас, хэрэглэгч нь нэмэлт үйлчилгээний хураамж эсвэл хүргэлтийн хугацааг сунгах шаардлагыг хянах ёстой байсан гэж үзэх боломжгүй. Харин хэрэглэгч нь нэмэлт үйлчилгээний хураамж эсвэл хүргэлтийн хугацааг сунгах шаардлага тавьсан бол, төслийн удирдлагын үүрэг хүлээсэн буруутан нь хэрэглэгчид тухайн зүйлийг мэдэгдэж, шаардлагыг татгалзуулах эсвэл хүргэлтийн хугацааг сунгах талаар хэлэлцээр хийх зэргээр хөгжүүлэлтийн ажилд саад учруулахгүй байх ёстой байсан гэж үзэж болно.
Токио дүүргийн шүүхийн 2004 (Хэйсэй 16) оны 3-р сарын 10-ны шийдвэр
Тухайн шийдвэр нь хэрэглэгч талд ч хамтын ажиллагааны үүрэг байгаа гэдгийг зөвшөөрсөн бөгөөд, хэрэглэгч өөрөө систем хөгжүүлэлтийн мэргэжилтэн биш болохыг тооцох ёстой гэж заасан байдаг. Өөрөөр хэлбэл, систем хөгжүүлэлтийн мэргэжилтэн биш хэрэглэгч нь системийн агуулга тодорхой болтол хүлээх хугацаанд (заримдаа захиалга өгөхөд ч дасан зохицоогүй байдаг) жижиглэнгийн захиалга өгөх нь гажиггүй бөгөөд түүнчлэн тухайн захиалгын агуулга нь хүргэлтийн хугацаа гэх мэт зүйлсийг дахин харах шаардлагатай бол “өөрөө анзаарах ёстой” гэдэг нь хэтэрхий хатуу шаардлага гэж үзэж болох юм.
Гэхдээ энд үйлчлүүлэгчийн талд тавигдаж буй үүрэг гэдэг нь хугацааг сунгах шаардлага тавих (эсвэл хугацааг өөрчлөх боломжгүй бол нэмэлт шаардлагыг бууруулах санал тавих) зэрэг харилцааны оролдлого гэж ойлгож болох юм. Иймд, хэрэглэгчийн бүх шаардлагыг хүлээн авч, анхны хугацаанд нь хүргэх үүрэг бүхнийг хамарч байгаа гэсэн утгатай биш гэж үзэж болох учраас, энэ талаар анхаарах хэрэгтэй байх болно.
Үйлдвэрлэл болон тестийн шатны үзүүлэлтийг баталгаажуулахаас хойш нэмэлт ажил гүйцэтгэсэн тохиолдолд
Дээрх шүүхийн шийдвэрийн агуулгыг эргүүлэн тавихад, үзүүлэлтийг аль хэдийн баталгаажуулсан тохиолдолд нэмэлт хөгжүүлэлт хийхэд ямар дүнд хүрэх байсныг таамаглах боломжтой. Тэгвэл энэ тохиолдолд ийм шаардлагууд хүлээн зөвшөөрөхөд хүндрэлтэй болох нь тодорхой. Тиймээс, хэрэглэгчийн тал болон үйлдвэрлэгчийн талын хөгжүүлэлтийн ажилд ойлголт нь ихээхэн зөрүүтэй байгаа нь, үзүүлэлт баталгаажсаны өмнө байсан ч, дараа байсан ч өөрчлөгдөхгүй.
Гэхдээ, үзүүлэлт баталгаажсаны дараа захиалгын агуулгыг өөрчлөх эсвэл нэмэлт хийх нь ажлын дахин хийлгэх шаардлага тавих магадлалтай. Ийм тохиолдолд гарсан хугацаа хоцрохыг “үйлчлүүлэгч болохоор ямар нэгэн шаардлага тавих нь зүйтэй” гэж хамгаалах нь ихэвчлэн хүнд байх болно. Мөн, олон үзүүлэлт өөрчлөлт болон нэмэлт функц нь дараа нь гарч ирсэн нь, үндсэн төлөвлөгөө гэх мэт урьдчилан аль хэдийн дууссан байх ёстой дээд шатны ажилд хэрэглэгчийн талын хамтын ажиллагааны үүрэг зөрчигдсөн байж магадгүй гэсэн эргэлзээг төрүүлдэг.
Эдгээр зүйлсээс харахад, үзүүлэлт нэг удаа баталгаажсаны дараа хийгдсэн өөрчлөлтүүдийг үйлдвэрлэгчийн талын хариуцлага гэж үзэх нь бодит бус гэж үзэж болох юм. Уг шүүхийн шийдвэрийн текстээс энэ утгыг нь унших нь зүйтэй гэж хэлж болно.
Мөн, ийм шийдвэрүүд нь гэрээний бичиг баримт л биш, мөн систем хөгжүүлэлтийн явцад тохирсон хурлын тэмдэглэлүүдийг ч бас баталгаа болгон ашиглах хандлагатай байдаг. Хурлын тэмдэглэлүүдийн талаар доорхи нийтлэлд дэлгэрэнгүй тайлбарласан байдаг.
Холбоотой нийтлэл: Хууль ёсны өнцгөөс харахад систем хөгжүүлэлтэд хурлын тэмдэглэлүүдийг хэрхэн үлдээх вэ[ja]
Дүгнэлт: Шаардлага тодорхойлох нь хэрэглэгчийн талын процесс гэдгийг мартаж болохгүй чухал зүйл
Шаардлага тодорхойлох нь вендорын талын ур чадварыг харуулах боломжтой ч, эхлээд нь энэ нь хэрэглэгчийн талын үйл ажиллагаа гэдгийг санах хэрэгтэй. Тухайн системийг өөрийн компани ашиглах нь, гадны мэргэжлийн хүний тусламжтайгаар бүтээсэн ч гэсэн, энэ нь эрх зүйн хувьд компанийн удирдлага дор байх ёстой салбар гэж үздэг.
Хэрэв хэрэглэгчийн тал хөгжүүлэлтийн явцад хамтран ажиллахад бэлэн бус бол, төслийн явцад асуудал үүссэн ч, шүүх хэрэглэгчийн талд ч хатуу байр суурь илэрхийлэх магадлалтай гэдгийг анхаарах хэрэгтэй.
Category: IT
Tag: ITSystem Development