Dự án quản lý công nợ

[hai2hai]

Chắc anh sẽ tham gia nhóm khác, vì phần nghiệp vụ anh không rành lắm.
Lê Văn Duyệt

Anh đương nhiên ban đầu là ko rành nghiệp vụ rồi (trả phải anh, em cũng vậy ), nhưng anh tham gia với nhóm, nhóm sẽ cử người viết nghiệp vụ và nhìn vào nghiệp mà anh thiết kế và lập trình. Thế mới gọi là làm việc nhóm chứ. Trong nhóm sẽ có người viết tài liệu nghiệp vụ cho anh đọc và anh sẽ tạo tài liệu thiết kế (dạng gì cũng được, miễn là người lập trình Excel hay ngôn ngữ .NET của anh nhìn vào là biết lập trình ).

Nếu xem tài liệu yêu cầu phần mềm đó mà anh ... đọc ko hiểu để thiết kế được thì nghĩa là có vấn đề ở hoặc: là do tài liệu viết đó ko thỏa mãn là tài liệu SRS, hoặc là do ... người thiết kế ...ko chịu hiểu.

Nhận làm dự án phần mềm mà nói câu "Tôi ko rành về nghiệp vụ" là hỏng rồi đấy anh ạ

 

[levanduyet]

Hi hi hi

Nhận làm dự án phần mềm mà nói câu "Tôi ko rành về nghiệp vụ" là hỏng rồi đấy anh ạ

Đồng ý với em. Nhưng sao các bước đầu các bạn rành nghiệp vụ sau không thấy nói năng gì vậy? Anh có kinh nghiệm trước đây khi anh gọi làm dự án thì các bạn đều bận hết nên cuối cùng dự án đi vào quên lãng!

LVD

 

[handung107]

Xin nhắc lại với các bạn rằng : dự án này là có thật, đã có một cửa hàng bán tạp hóa đặt viết dự án này trên Access, và chị đã nghĩ rằng có thể làm bằng Excel. Rất tiếc vì bận công việc nên chị đã không nhận làm File này mà thôi. Vậy thì các bạn đừng ôm đồm quá nhiều vào việc nghĩ ngợi như phải lên các BC giống như một PM KT. Đơn thuần là họ theo dõi côngnợ của KH mà thôi. Nếu chỉ đơn thuần là cá nhân làm, chắc hẳn chúng ta ai làm cũng được. Vậy mục đích của việc triển khai dự án này là gì ?
Đó là chị muốn học tập cách làm việc chuyên nghiệp hơn để sau này chúng ta sẽ thực hiện các dự án lớn hơn. Chị nghĩ chúng ta nên đi một cách bài bản, dù cho dự án này nhỏ xíu đi chăng nữa, giống như ta xây một cái nhà vậy. Các em đọc những bài viết rất tâm huyết của Hai2Hai, nếu chúng ta muốn, chắc chắn Hải sẽ truyền đạt, chia xẻ tất cả những kiến thức mà Hải có, và chị tin chắc với mục tiêu đề ra như trên, chúng ta sẽ vững vàng hơn rất nhiều trong công việc của chúng ta sau này

 

[OverAC]

Để dự án nàc có thể bắt đầu và đi vào hiện thực cần có nhân sự thực hiện, việc nêu ra ở đây như là một đề bài thách đố, để mọi người cùng nhau làm. Chia đội ra mà thực hiện, rồi từ đó có thể học hỏi lẩn nhau. Mỗi đội sẽ có 1 box cho riêng đội mình, các bài trong box này sẽ chỉ có các thành viên trong đội post được, xem được. (hiện tại các box đã được lập ra nhưng chưa ai được set quyền để thấy nó)
Em xin được là 1 đội, hoan nghinh nếu có ai đó tham gia vào đội của em. Đồng thời em cũng đề cữ bác Đào Việc Cường, bác HYen, Yeudoi, inkpot_pencil lập ra những đội khác để cùng nhau thực hiện và thi thố.

 

[tsf]

Về phần lâp trình, cái này xin lỗi, em chịu thua à nghen. Em sẽ nêu ý kiến và phác thảo về vấn đề công nợ mà thực tế cần đến. Còn nhiều vấn đề chúng ta cần nêu ra thêm, nhưng em nghĩ bao nhiêu đó cũng đã đuối hàng rồi.
Anh Duyệt ơi, 3 con cò làm chung 1 nhóm đi nào.
Ok không 2 con cò kia.

 

[PhanTuHuong]

Tôi đi làm nhiều, bị nợ cũng nhiều.
Bác nào lập ra cái chương trình gì đó để họ trả cho tôi nhanh chóng được ko?

 

[Đào Việt Cường]

Mỗi đội sẽ có 1 box cho riêng đội mình, các bài trong box này sẽ chỉ có các thành viên trong đội post được, xem được. (hiện tại các box đã được lập ra nhưng chưa ai được set quyền để thấy nó)

Dear OverAC,
-------------
OverAC set quyền để "thấy nó" đi, anh chưa biết cơ cấu các đội tuyển khác như thế nào để mà lượng sức!
Hiện tại đội của mình gồm: Đào Việt Cường và WhoamI, lấy tên là đội "Con Gà Đen" (vì nghe đâu con gà đen liên quan đến OK thì phải!)
...
thôi, chắc không nói nữa kẻo lộ hết chiến thuật.

 

[levanduyet]

???

Mọi người ơi ! Hình như ý của các bạn đi hơi bị lệch?
Theo tôi nghĩ, dự án này là chỉ một dự án. Nhưng chia thành những phần nhỏ, và mỗi nhóm thực hiện một phần, chứ không phải chia thành các đội rồi thi với nhau?!
Có phải như vậy không?

Lê Văn Duyệt

 

[handung107]

Dự án này nhỏ, nên chỉ cần 2-3 người là có thể thực hiện. Dự định là có nhiều nhóm nhỏ, mỗi nhóm sẽ tự chọn những ai có thể cùng thực hiện. Thời gian thự chiện là 1 tháng, và khi hết thời hạn, chúng ta sẽ có 3-4 sản phẩm để cùng xem xét và rút kinh nghiệm

 

[handung107]

Như vậy, tạm thời đến lúc này, chúng ta có 3 nhóm :
- Nhóm 1 : 3 con cò adam_tran, Lê Văn Duyệt, tsf
- Nhóm 2 : Con gà đen, Đào Việt Cường, WhoamI
- Nhóm 3 : BìnhOverAC và ...???
Các bạn tiếp tục đăng ký tham gia thành lập nhóm đi nhé

 

[OverAC]

Dear OverAC,
-------------
OverAC set quyền để "thấy nó" đi, anh chưa biết cơ cấu các đội tuyển khác như thế nào để mà lượng sức!
Hiện tại đội của mình gồm: Đào Việt Cường và WhoamI, lấy tên là đội "Con Gà Đen" (vì nghe đâu con gà đen liên quan đến OK thì phải!)
...
thôi, chắc không nói nữa kẻo lộ hết chiến thuật.

Nhóm Con Gà Đen đã được thành lập. Các bác có thể làm việc với nó được rùi.
Hiện tại thành viên nhóm Con Gà Đen gồm có : bác Đào Việt Cường và WhoamI

 

[hai2hai]

Các bạn đã biết các công việc liên quan đến:
1/ Xác định yếu cầu phần mềm
a) Đầu vào: Các tài liệu yêu cầu đã Khảo sát (chính là yêu cầu của chị Dung đưa ra), tài liệu nghiên cứu tham khảo (có thể do ban tham khảo thêm),...
b) Đầu ra:
- Tài liệu yêu cầu cấp cao (cái này mình ko làm)
- Tài liệu đặc tả yêu cầu phần mềm (SRS)

2/ Phân tích thiết kế (với bài toán nhỏ thì làm theo cách làm đơn giản là phương pháp top-down: nghĩa là làm phân rã chức năng từ trên xuống)
a) Đầu vào:
- Tài liệu SRS
b) Đầu ra: (Cái này hơi nhiều nhưng vì ta làm đơn giản nên bỏ bớt đi, làm theo top down thôi)
- Sơ đồ chức năng của chương trình, kèm theo mô tả chức năng đó: điều kiện thực hiện, ai thực hiện, thực hiện như thế nào, thực hiện khi nào, kết quả là gì, những trường hợp đặc biệt (nếu có).
- Sơ đồ phân rã thực thể: Bảng quan hệ giữa các thực thể (sơ đồ dữ liệu: tables, query, relationships,...)
- Bảng mô tả chức năng nào dùng thực thể nào
Ví dụ:
Chức năng nhập hàng sử dụng các thực thể sau:
+ Hóa đơn mua hàng
+ Phiếu nhập hàng
+ Nhà cung cấp
+ Kho hàng
+ Hàng hóa
+ Danh mục thuế
+ Danh mục nhân viên
+ v.v...
Chú ý: Chức năng thì dùng ĐỘNG TỪ, thực thể thì dùng DANH TỪ (giống như thuộc tính thì dùng danh từ, phương thức thì dùng động từ ấy)

3) Lập trình & tự Unit Test (quên, phải gọi là tự kiểm tra từng đơn vị nhỏ nhất của lập trình - là module)
Module ở đây có thể hiểu là 1 chức năng lớn, một hàm tính toán, một method, một màn hình, một báo cáo, v.v... tùy theo mỗi nhóm tự quy định. Thông thường nhóm lập trình tự "unit test" cho phần việc của mình được giao (và theo tài liệu thiết kế chi tiết - nhưng ở đây mình ko làm tài liệu thiết kế chi tiết vì dự án nhỏ và làm thiết kế chi tiết rất tốn time + nhân lực)
Về chuyện nhóm lập trình thì lắm vấn đề lắm nhưng thôi, chắc trong các nhóm nhỏ chỉ có 1 lập trình viên nên coi đó là trưởng nhóm lập trình luôn)
4) Test (Kiểm tra)
A. Kiểm tra tích hợp và kiểm tra hệ thống
Thế nào là kiểm tra tích hợp (Intergration Test): Giả sử làm xong module 1, test xong module 1 thì gọi là Unit Test, làm tiếp module 2, test tiếp module 2 xong thì vẫn gọi là Unit test. Nhưng lúc đó quay lại test xem sau khi làm xong module 2 thì module 1 có chạy tốt ko, phân giao tiếp giữa 2 module đó có hoạt động hay ko? cái đó gọi là kiểm tra tích hợp. Khi kiểm tra tích hợp toàn bộ chương trình thì mình phải dựa vào từng nghiệp vụ cụ thể được mô tả trong tài liệu thiết kế.
Thế nào là kiểm tra hệ thống (System Test)?: Dựa vào tài liệu đặc tả yêu cầu phần mềm, dựa vào các tài liệu thiết kế, trưởng nhóm test sẽ lập ra kế hoạch test trong đó chỉ ra các trường hợp để test (gọi là Test Case). Dựa trên từng test case đó, người thực hiện test (gọi là tester) sẽ thực hiện test từng use case 1 theo kế hoạch.
Ví dụ về kế hoạch test (Test plan)
Usecase 1: Nhập hàng
USC1.1: Thêm phiếu nhập
- Thông tin đầu vào: Số PN, ngày ct, v.v...
- Điều kiện ràng buộc: Bắt buộc: Mã kho hàng, mã thủ kho, v.v...; không bắt buộc: người giao hàng, v.v...
- Kết quả thành công: Chứng từ nhập hàng được ghi sổ, màn hình chuyển sang nhập phiếu mới, con trỏ để ở vị trí Số chứng từ,....
- v.v... nhưng thôi, ta chỉ làm đơn giản thế thôi
USC1.2: Sửa chứng từ
...
USC1.3: Xóa chứng từ
...

USC1.n: v.v....

USC2: Xuất hàng
...

B. Kiểm tra chấp nhận (Acceptant Test)
Thông thường công việc này do 2 bên: Nhà cung cấp và Khách hàng (là chị Dung) cùng thực hiện.

Dựa trên tài liệu SRS đã thỏa thuận giữa 2 bên (NCC & KH), NCC tạo ra 1 tài liệu Acceptant Test List trong đó chỉ ra các công việc cần test khi nghiệm thu chương trình (nghiệm thu xong mới thanh lý được hợp đồng mà )
Sau đó 2 bên đưa ra 1 buổi nghiệm thu kỹ thuật và cứ dựa trên Acceptant Test List & SRS để kiểm nghiệm lại chương trình xem chương trình có chạy đúng hay ko. Nếu OK thì coi như nghiệm thu và HĐ đã được thanh lý (còn thanh lý đến đâu là do 2 bên thỏa thuận với nhau trong HĐ )

Tiếp theo giải đoạn Acceptant Test là giai đoạn go live (Hệ thống sẽ được đưa vào chạy thử (và cũng là chạy thật luôn) để theo dõi tính ổn định, v.v.. gì đó của chương trình - theo như mô tả trong SRS)

Nôm na mọi chuyện nó là như vậy (dĩ nhiên là ko thể đầy đủ hết được). Dĩ nhiên, tùy vào từng tình huống mà ta có thể đơn giản hóa từng khâu (nhưng tốt nhất vẫn nên có các tài liệu đầu ra của các khâu đó cho dù nó đơn giản thế nào đi nữa)

 

[hai2hai]

Ngoài các phương tiện liên lạc nhóm như email, mailling list, chat, voice chat, gặp trực tiếp, v.v... thì các bạn có thể quản lý các dự án một cách online thông qua ứng dụng iteamwork tại: http://www.iteamwork.com/. Đây là 1 ứng dụng dạng webform quản lý dự án online rất hiệu quả.

 

[Pansy_flower]

Hic, nghe các anh chị thảo luận sôi nổi quá. Em cũng muốn tham gia nhưng hơi bị thiếu tự tin.(Hỏng hiểu sao, em ko sử dụng đc smiley của GPE?!)

 

[OverAC]

Secret Grasses ơi, đề nghị câu tham gia vào nhóm của tớ nhé

Các nhóm hiện nay đã có gồm:

 

[Pansy_flower]

Secret Grasses ơi, đề nghị câu tham gia vào nhóm của tớ nhé

Tks! SG tham gia nhóm nào cũng đc nhưng sợ SG ở nhóm nào, nhóm đó sẽ ko giành đc giải thui.

P/S: Bữa nay sao lại "cậu" với "tớ" kỳ quá!

 

[tsf]

Tks! SG tham gia nhóm nào cũng đc nhưng sợ SG ở nhóm nào, nhóm đó sẽ ko giành đc giải thui.

P/S: Bữa nay sao lại "cậu" với "tớ" kỳ quá!

Con nhỏ này, thằng OverAC nó "Câu" em chứ không phải cậu đâu. Sướng nghe.

 

[tsf]

Riêng đây, Chị Dung va anh Hai2Hai, rút lại yêu cầu bài toán và các báo cáo lại một lần nữa luôn đi, để các bạn hình dung cho dễ.
Cám ơn.

 

[hai2hai]

Ơ, Đã là KH thì làm sao mà biết đưa ra yêu cầu nhỉ????

Mọi người là nhà cung cấp, khi có "nhu cầu" từ khách hàng (là chị Dung) thì phải tìm cách mà hỏi chứ. Phải khảo sát nghiệp vụ, nếu chưa rõ điều gì thì lại hỏi "khách hàng" để khách hàng làm sáng tỏ yêu cầu. Sau đó mọi người viết lại những gì mình hiểu vào SRS. Thế mới gọi là nhà cung cấp chứ? Nếu KH mà có thể đưa ra yêu cầu chuẩn ngay từ đầu NCC quá sướng (nhưng mà 100% là ko bao giờ có KH nào có thể đưa rõ ràng mọi yêu cầu ngay từ đầu được )

Các bạn chú ý nhé. Khi đã làm phần mềm cho KH mà làm thiếu thì dĩ nhiên là ko được rồi. Nhưng nếu mà làm thừa thì nghĩa là các bạn đã tốn resources (time, human, money) đấy. Vì thế chỉ làm đúng những gì KH yêu cầu mà thôi (làm thừa đâu có được trả thêm tiền, đúng ko?). Nghĩa là tính năng của phần mềm = đúng yêu cầu của KH.

Ví dụ: KH yêu cầu: Tôi chỉ quản lý công nợ, ko quản lý kho hàng mà các bạn cứ viết vào SRS rồi thiết kế, rồi code là có các tính năng về kho hàng là ... chỉ có các bạn thiệt thôi (mất time, mất nhân lực cho dự án khác, và dĩ nhiên mất cả tiền - vì KH có trả thêm tiền cho những tính năng làm thêm đâu)

Như vậy, người làm nghiệp vụ phải tìm mọi cách xác định phạm vi của bài toán. Sau khi làm xong SRS thì NHỚ CONFIRM LẠI VỚI KHÁCH HÀNG LÀ SRS ĐÓ ĐÃ ĐÁP ỨNG ĐÚNG YÊU CẦU CỦA KH CHƯA NHÉ (gửi SRS cho chị Dung (cc to haixhai@yahxx.com)). Sau đó KH (chị Dung) sẽ review lại tài liệu và 2 bên cùng trao đổi với nhau cho đến khi SRS được TẠM công nhận là đáp ứng đúng yêu cầu. (và lúc đó mới ký kết hợp đồng kinh tế )

Tuy nhiên, đó là cách mà chúng ta làm dự án theo yêu cầu của KH. Nếu chúng ta làm phần mềm mang tính thương mại cao thì phải nghiên cứu tính tổng quát, phải đưa thêm các tính năng mới để đáp ứng số đông - tức là ko chỉ có những yêu cầu của KH (như các PM QL bán hàng, PMKT,... đang có trên thị trường). Dĩ nhiên, tính năng đó nhiều đến đâu thì phụ thuộc vào rất nhiều yếu tố: nào là chiến lược SP & thị trường của cty, nào là khả năng của NCC, v.v.... Điều này chúng ta ko cần đả động đến vội. Chúng ta đang giả sử dự án đầu tiên này là làm theo yêu cầu của KH chứ ko phải dự án phần mềm thương mại. Vì thế chúng ta chỉ làm theo yêu cầu của KH mà thôi.

PS: Các bạn nên confirm tài liệu SRS với khách hàng (chị Dung) nhé. Đừng hục hục làm từ đầu đến cuối mà chẳng liên hệ với KH gì cả. Có thể trong quá trình làm SRS thì cứ thiết kế dần dần nhưng thiết kế chính xác chỉ khi SRS đã được chấp nhận bởi KH.

Trong quá trình làm nên liên tục thông báo tình trạng dự án (làm đến đâu rồi) cho khách hàng nữa.

Bây giờ ai đã có thể đưa ra được 1 bản SRS draft rồi nhỉ?

 

[tsf]

Trên thực tế, chưa hẳn là KH sẽ không đưa ra yêu cầu từ đầu cho NCC. Tôi thấy nhiều KH khi lựa chọn NCC, họ cũng đã dự tính họ sẽ cần gì (vì thực tế đã xảy ra rồi) hoặc là chưa xảy ra nhưng nó đã nằm trong chiến lược của KH.

Ở đây, KH là chị Dung, chị có đưa thêm yêu cầu gì không. Vì trong nhóm dự án, người lập trình có thể là một thôi, có thể chưa hiểu rõ KH mình muốn gì và trải nghiệm ở thực tế nhiều nữa. Đây có thể là trường hợp của anh Duyệt (mà cái ông này hơi bận chị ạ), cho nên cho ổng làm một lúc cho xong. Còn em, đưa ra yêu cầu chi tiết để anh viết chứ. Yêu cầu ít quá, ông Duyệt mập lạng quạng quên luôn đó chứ, hi hi.

Chị Dung nhớ nhe. Cám ơn.