คำถามติดแท็ก reporting

ก่อนอื่นฉันอยากจะบอกว่านี่เป็นคำถาม / ประเด็นที่ถูกทอดทิ้งดังนั้นหากคำถามนี้ต้องการการปรับปรุงให้ช่วยฉันทำสิ่งนี้ให้เป็นคำถามที่ดีที่จะเป็นประโยชน์ต่อผู้อื่น! ฉันกำลังมองหาคำแนะนำและความช่วยเหลือจากผู้ที่ใช้งานโซลูชันที่แก้ไขปัญหานี้ไม่ใช่แค่แนวคิดที่จะลอง จากประสบการณ์ของฉันมีแอพพลิเคชั่นสองด้าน - ด้าน "งาน" ซึ่งส่วนใหญ่ขับเคลื่อนด้วยโดเมนและเป็นที่ที่ผู้ใช้โต้ตอบอย่างล้นหลามกับโมเดลโดเมน ("เอ็นจิ้น" ของแอปพลิเคชัน) และด้านการรายงาน รับข้อมูลตามสิ่งที่เกิดขึ้นในงาน ในด้านงานเป็นที่ชัดเจนว่าแอปพลิเคชันที่มีรูปแบบโดเมนที่หลากหลายควรมีตรรกะทางธุรกิจในรูปแบบโดเมนและฐานข้อมูลควรใช้เป็นหลักในการคงอยู่เป็นส่วนใหญ่ การแยกข้อกังวลหนังสือทุกเล่มเขียนเกี่ยวกับเรื่องนี้เรารู้ว่าต้องทำอะไรดีเลิศ แล้วด้านรายงานล่ะ คลังข้อมูลยอมรับได้หรือไม่หรือมีการออกแบบที่ไม่ดีเพราะรวมตรรกะทางธุรกิจไว้ในฐานข้อมูลและข้อมูลเอง ในการรวบรวมข้อมูลจากฐานข้อมูลลงในข้อมูลคลังข้อมูลคุณต้องใช้ตรรกะทางธุรกิจและกฎกับข้อมูลและตรรกะและกฎนั้นไม่ได้มาจากรูปแบบโดเมนของคุณมาจากกระบวนการรวบรวมข้อมูลของคุณ มันผิดหรือเปล่า? ฉันทำงานกับแอปพลิเคชันการจัดการทางการเงินและโครงการขนาดใหญ่ซึ่งมีตรรกะทางธุรกิจที่กว้างขวาง เมื่อรายงานข้อมูลนี้ฉันมักจะมีการรวมจำนวนมากที่ต้องทำเพื่อดึงข้อมูลที่จำเป็นสำหรับรายงาน / แดชบอร์ดและการรวมมีตรรกะทางธุรกิจจำนวนมาก เพื่อประสิทธิภาพฉันได้ทำกับตารางรวมที่สูงและขั้นตอนการจัดเก็บ ตัวอย่างเช่นสมมติว่ารายงาน / แดชบอร์ดจำเป็นต้องแสดงรายการของโครงการที่ใช้งานอยู่ (จินตนาการ 10,000 โครงการ) แต่ละโครงการจะต้องมีชุดของตัวชี้วัดที่แสดงพร้อมตัวอย่างเช่น: งบประมาณรวม ความพยายามในวันที่ อัตราการเผาไหม้ วันหมดงบประมาณที่อัตราการเขียนปัจจุบัน เป็นต้น แต่ละรายการเกี่ยวข้องกับตรรกะทางธุรกิจจำนวนมาก และฉันไม่เพียงแค่พูดถึงการคูณตัวเลขหรือตรรกะง่ายๆ ฉันกำลังพูดถึงเพื่อที่จะได้รับงบประมาณคุณต้องใช้แผ่นอัตราที่มี 500 อัตราที่แตกต่างกันหนึ่งรายการสำหรับเวลาพนักงานแต่ละคน (ในบางโครงการโครงการอื่น ๆ มีตัวคูณ) ใช้ค่าใช้จ่ายและมาร์กอัปที่เหมาะสม ฯลฯ ตรรกะนั้นกว้างขวาง การรวบรวมและการปรับแต่งแบบสอบถามใช้เวลามากในการรับข้อมูลนี้ในเวลาที่เหมาะสมสำหรับลูกค้า ควรดำเนินการผ่านโดเมนก่อนหรือไม่ แล้วประสิทธิภาพล่ะ …

44 mvc  architecture  domain-driven-design  reporting  data-warehouse 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ในคำถามอื่นผมถามเกี่ยวกับสาเหตุที่นักพัฒนาอาจไม่ชอบทะเลาะกันทุกวัน เราได้พูดคุยกับนักพัฒนาและเราตัดสินใจที่จะไม่ทำการต่อสู้ทุกวันชั่วขณะหนึ่ง (เพื่อให้ลองและการต่อสู้ที่กำหนดเองในความพยายามครั้งแรกของเรา) นี่คือผลลัพธ์ของการปรึกษากับนักพัฒนาโดยตรง ในทางกลับกันเราไม่ต้องการเสียส่วนที่ดีของการทะเลาะกันทุกวันเช่นการได้รับโอกาสในการประสานงานผู้พัฒนาทุกวันหรือดูความคืบหน้าการทำงานเช่นตัวบ่งชี้ประสิทธิภาพหลักเพื่อดำเนินการก่อน เพื่อเป็นทางเลือกแทนการต่อสู้รายวันเรากำลังคิดที่จะขอให้ผู้พัฒนาจัดทำรายงานรายวันโดยมีเงื่อนไขดังต่อไปนี้: ไม่จำเป็นต้องทำตามรูปแบบเฉพาะ ยอมรับทุกรูปแบบและทุกรูปแบบ แม้ว่างานจะไม่เสร็จ แต่เราต้องการฟังความคืบหน้า ไม่จำเป็นต้องพูดถึงเวลาที่ใช้ในแต่ละภารกิจ ควรกล่าวถึงข้อกำหนดในการพัฒนาอุปสรรคและการประสานงาน ไม่จำเป็นต้องหมกมุ่นอยู่กับรายงานประจำวัน มันไม่ได้เข้มงวดอย่างนั้น คุณคิดว่าสิ่งนี้สามารถลดความสามารถในการผลิตได้หรือไม่? คุณเคยมีประสบการณ์การรายงานประจำวันบ้างไหม? คุณมีข้อเสนอแนะใด ๆ สำหรับเราเพื่อให้แน่ใจว่าเราไม่ได้เป็นจุลภาคหรือไม่?

18 productivity  management  scrum  meetings  reporting 

เรามีแอปพลิเคชั่นที่รวบรวมข้อมูลจำนวนมากและได้รายงานการอบเข้ามา การทำซ้ำครั้งแรกคือการรวม Crystal Reports ซึ่งทำงานได้ดี สร้างรายงานในตัวออกแบบ Crystal Report จากนั้นอิมพอร์ตไฟล์ RPT ไปยังแอปพลิเคชัน สิ่งนี้ใช้ได้ดี แต่ผู้ใช้ต้องการแอปพลิเคชันเพื่อเรียกใช้รายงานและผู้ใช้เพิ่มเติมไม่สามารถสร้างรายงานได้ เราได้เพิ่มตัวกรองตัวเรียงลำดับและการจัดกลุ่มเพื่อให้ไฟล์ RPT สามารถปรับแต่งได้ แต่พวกเขาไม่สามารถสร้างได้ตั้งแต่เริ่มต้น Interation ที่สองคือโซลูชันบนเว็บโดยใช้ SSRS, SSAS และเครื่องมือสร้างรายงานจาก Microsoft สิ่งนี้ต้องการงานฐานข้อมูลบางส่วนและงานบางอย่างเพื่อเรียกใช้คิวบ์และเรียกใช้จากสคีมา OLTP แต่ในท้ายที่สุดมันง่ายกว่ามากในการสร้างรายงานการยกเลิก อย่างไรก็ตามเรายังต้องสร้างรายงานโดยใช้เครื่องมือสร้างรายงานเผยแพร่แล้วเป็นต้นนอกจากนี้เรายังเพิ่มตัวกรองตัวเรียงลำดับและกลุ่มเพื่อทำให้ "ปรับแต่ง" ในมหาสมุทรทั้งสองนี้เรามีรายงานประมาณ 30 ถึง 50 รายการที่สร้างขึ้นเมื่อเวลาผ่านไป ขณะนี้มีการสนทนาเกี่ยวกับการเพิ่มรายงานเฉพาะกิจเพื่อให้ผู้ใช้สามารถสร้างรายงานตั้งแต่เริ่มต้นได้ทันที ตอนนี้โมเดลข้อมูลของเราซับซ้อนมากและต้องการความรู้ในการทำงานที่ดีเพื่อให้เข้าใจได้ หากต้องการทำสิ่งนี้อย่างน้อยที่สุดจะต้องใช้จำนวนงานที่ดีในการทำให้ตัวแบบข้อมูลเป็นแบบแผนที่ "รายงานมากกว่า" และเข้าใจได้ง่ายขึ้น ฉันไม่คิดว่าแอปพลิเคชันของเราเหมาะสำหรับการรายงานแบบเฉพาะกิจ (ไม่คุ้มกับความพยายาม) มีใครบ้างที่ประสบความสำเร็จในการจัดทำรายงานเฉพาะกิจ? คุณใช้ชุดเครื่องมือใด มีผลกระทบต่อความสำเร็จของแอปพลิเคชันของคุณหรือไม่

16 business  reporting 

ฉันมีปัญหาในการรายงานความคืบหน้าต่อนายจ้างของฉัน ฉันเป็นโปรแกรมเมอร์แบบพาร์ทไทม์จัดการโครงการซอฟต์แวร์สำหรับแผนก (ที่ไม่ใช่ด้านเทคนิค) ของโรงเรียน บุคคลที่ติดต่อ: 1. พนักงานที่ใช้ซอฟต์แวร์จริงและส่งคำขอคุณสมบัติ 2. เจ้านายของฉัน (ไม่ใช่โปรแกรมเมอร์) และเธอไม่ใช่ผู้ใช้ซอฟต์แวร์ ลักษณะของโครงการ: เป็นซอฟต์แวร์สำเร็จรูปที่ซื้อจากบุคคลที่สาม ฉันต้องแก้ไขหรือเพิ่มคุณสมบัติ / ฟังก์ชั่นซอฟต์แวร์นี้เพื่อตอบสนองความต้องการของแผนก นี่คือซอฟต์แวร์ที่จำเป็นต้องใช้ตลอดภาคการศึกษา ไม่จำเป็นต้องใช้ฟีเจอร์ทั้งหมดในตอนเริ่มต้น ดังนั้นเราจึงใช้โมเดล Agile: เมื่อพนักงานต้องการคุณสมบัติบางอย่างพวกเขาขอเพิ่มและฉันทำการเปลี่ยนแปลง ในตอนท้ายของภาคการศึกษาฉันคิดว่าคุณสมบัติที่จำเป็นทั้งหมดจะได้รับการยกระดับและนำไปใช้งาน ปัญหา: ทุกครั้งที่เจ้านายของฉันถามฉันถึงความคืบหน้าฉันตอบไม่ได้เพราะฉันไม่รู้ว่าจะตอบอย่างไร ฉันไม่มีรายการที่สมบูรณ์ของคุณสมบัติที่จำเป็นทั้งหมด แม้ว่าฉันจะมีฟีเจอร์ที่เพิ่มขึ้นเมื่อสัปดาห์ที่แล้ว แต่ฉันก็ยังไม่สามารถบอกได้ว่าบอสของฉัน "เสร็จ" เพราะฟีเจอร์ใหม่กำลังเข้ามาด้วยและฉันก็ไม่รู้เหมือนกัน ฉันไม่สามารถบอกได้ว่า "เรามีจำนวน% ที่จะสำเร็จ" หรือ "เราจะดำเนินการให้เสร็จภายใน xxx" บางครั้งจากคำขอ 3 คำขอฉันจัดการให้เสร็จสมบูรณ์ 2 ฉันจะบอกหัวหน้าของฉันว่า "ฉันได้ทำ 2 เสร็จแล้ว แต่ยังมีฟีเจอร์หนึ่งที่ยังไม่เสร็จสมบูรณ์" หลังจากผ่านไปนานฉันก็ดูเหมือนว่า "ฉันมักจะมีบางสิ่งบางอย่างไม่เสร็จ แต่หลังจากนั้นไม่นาน" การไม่สามารถรายงานความคืบหน้าได้ทำให้ฉันดูแย่มาก มันไม่เกี่ยวกับว่าฉันทำไปมากแค่ไหน ถ้าฉันเป็นผู้จัดการและพนักงานของฉันล้มเหลวในการรายงานความคืบหน้ากับฉันเป็นเวลาหลายเดือนฉันจะรู้สึกว่าผู้ชายคนนี้ก็ไม่สามารถเช่นกัน …

15 project-management  agile  reporting 

ฉันเข้าใจสิ่งที่พวกเขาพิจารณา แต่มีประโยชน์จริง ๆ หรือไม่ที่จะมอบหมายสิ่งเหล่านั้นให้กับปัญหาที่พบ? ฉันหมายถึงมันจำเป็นต้องแก้ไขอย่างรวดเร็วหรือไม่ ฉันรู้วิธีการตั้งค่าจัดหมวดหมู่ ฯลฯ ฉันรู้ว่า IEEE / ISO จำเป็นต้องทำเช่นนั้น ฉันไม่เห็นว่าทำไม

11 testing  reporting  defect 

บางครั้งทีมงาน QA ของฉันรายงานข้อบกพร่อง แต่ฉันหรือพวกเขาไม่มีความคิดเกี่ยวกับวิธีการทำซ้ำ สิ่งนี้นำไปสู่เซสชันการดีบักที่ยาวและน่าผิดหวังซึ่งบางครั้งไม่ได้ผลลัพธ์ ซอฟต์แวร์ของฉันเชื่อมโยงอย่างหนักกับฮาร์ดแวร์ที่เป็นกรรมสิทธิ์ดังนั้นข้อบกพร่องอาจมาจากหลายทิศทางพร้อมกัน ฉันควรคาดหวังจากพวกเขามากกว่า "ซอฟต์แวร์ของคุณล้มเหลวเมื่อฉันกดปุ่ม" หรือฉันควรจะคิดเองว่าเกิดอะไรขึ้น? แก้ไข: เพื่อนร่วมงานคนหนึ่งของฉันชี้ให้เห็นว่าเราอาจเป็นนักพัฒนาซอฟต์แวร์ทั้งหมดที่นี่ดังนั้นผลลัพธ์อาจได้รับอคติเล็กน้อย

10 testing  bug  qa  reporting