First topic message reminder :

Mong chỉ giáo thêm !!!


http://www.mediafire.com/?q1m9pz2tgyv983f

manhtin2 wrote:4 Trong những nguyên nhân dự án sai kế hoạch thì nguyên nhân nào hay gặp nhất và cách khắc phục khi gặp nguyên nhân đó.Theo các bạn trong kế hoạch xây dựng đường 32 thì có những nguyên nhân nào có thể làm sai kế hoạch?

tình hình là bạn cứ hỏi nữa đi nhưng mà hỏi cái câu nó dễ thôi chứ. Trong những nguyên nhân dự án sai kế hoạch thì nguyên nhân các tiêu chuẩn ko đc tuân theo là hay gặp nhất và cách khắc phục nó là tuân theo các tiêu chuẩn đó. Trong kế hoạch xây dựng đường 32 thì có rất nhiều nguyên nhân có thể làm sai kế hoạch như là vượt kinh phí, ko tuân thủ thời gian thi công, ước tính về các dự đoán để hoàn thiện ko đúng...

manhtin2 wrote:3 .Trong tháp khuôn khổ kiểm soát dự án thì ban chỉ đạo có phải là người nắm vai trò kiểm soát chính hay là người quản lý dự án....và tại sao ????

Tất nhiên là ban chỉ đạo nắm vai trò kiểm soát chính rồi, nhìn cái tháp là biết chứ cần gì pải giải thích nhiều

manhtin2 wrote:Kiểm soát dự án thì có những bướ nào và bước nào là quan trọng nhất

tất cả gồm 7 bước đó là 7 mục trong slide đầu tiên bạn chịu khó đọc lại nhé, trong đó bước thu thập và đánh giá hiện trạng là bước qtrong nhất

Tr Mai wrote:mình hỏi thêm
Nếu coi bài thuyết trình này của các bạn là 1 dự án thì các bạn áp dụng nội dung trong bài của mình vào dự án này như thế nào ?

Cám ơn các bạn nhiều !!!

nếu bài thuyết trình này là 1 dự án thì đầu tiên bạn phải lập kế hoạch cụ thể xác định mục tiêu và mục đích cần làm (nhóm 2 đã thuyết trình).
sau đó bạn phân công công việc (chia nhỏ) để hoàn thành từng phần.và cuối cùng bạn đánh giá dự án (nhóm 7) .còn phân nội dung bài nhóm 6 cậu nên đọc kĩ lại ............thanks câu hỏi

ĐứcQuyết wrote:Cho mình hỏi thêm câu nè nha hjhj
Trong điều kiện khi kết thúc dự án ở bản work các cậu có viết:" Cuộc hop kết thúc thành công là phải biết kết thúc đúng cách "
Vậy cho mình hiểu kết thúc đúng cách ở đây nghĩa là gì hay nói cách khác các bạn hiểu từ " Đúng cách" như thế nào????
Cho mình một VD cụ thể về 1 cuộc họp khi kết thúc đúng cách được ko???

mình xin đc trả lời câu hỏi của bạn như sau: kết thúc đúng cách ở đây nghĩa là cuộc họp đc kết thúc 1 cách thành công và đạt đc thành công như kế hoạch ban đầu đặt ra cho mục đích cuộc họp, đó là giải quyết đc vấn đề đặt ra, thỏa mãn những thành viên tham gia, cuộc họp ko nảy sinh những vấn đề cá nhân...
Ví dụ trong cuộc hop bầu ra ban chấp hành chi Đoàn trường của lớp thì sau lần thứ 3 lớp ta đã kết thúc cuộc họp 1 cacxh thành công và đúng cách đó là bầu đc ra BCH và đc sự xác nhận của Bí thư đoàn trường xác nhận cuộc họp của lớp ta đã kết thúc thành công và làm đúng theo nguyên tắc bầu cử.

ThaiSon wrote:Cho mình hỏi "Quản lý rủi ro" ở phần 3 có giống và khác gì so với quản lý rủi ro ở nhóm 4 đã trình bày

mình xin trả lời câu hỏi của bạn như sau: ở nhóm mình thì quản lý rủi ro sẽ trình bày 1 cách tổng quan về những rủi ro và việc quản lý nó trong những trường hợp ko may xảy ra, còn trong nhóm 4 thì trình bày cụ thể hơn về tuengf trường họp rủi ro trong 1 dự án cụ thể và những phương án giải quyết cũng như nguyên nhân xay ra rủi ro để phòng ngừa rủi ro 1 cách hiệu quả nhất. Điểm giống ở đây đó là cùng nói về những trường hợp rủi ro hay xảy ra và phương án giải quyết chúng.

ThaiSon wrote:Ở phần quản lý rủi ro các bạn chỉ đưa ra cách lập kế hoạch phòng ngừa và các hành động ngăn ngừa rủi ro. Các bạn hãy nêu ra cách khắc phục nếu rủi ro xảy ra.

Mình xin trả lời câu hỏi của bạn như sau: nhóm mình trình bày trong phần này chính là quản lý rủi ro nên chúng mình chỉ đưa ra những trường hợp rủi ro hay xảy ra nhất và những phương án quản lý rủi ro để hạn chế tối đa nó, như đã trình bày ở trên là nhóm 4 đã đưa ra từng trường hợp rất cụ thể các cách khắc phục rủi ro. Bạn vui lòng ghé thăm lại bài tập nhóm 4 tham khảo thêm giúp nhóm mình nhé!!!tks

ThaiSon wrote:Trong cac noi dung cua quan ly chat luong thi noi dung nao la quan trong nhat?vi sao?neu thieu 1 trong cac noi dung thi co anh huong ji den hoat dong quan ly chat luong hay ko?

mình xin trả lời câu hỏi của bạn như sau: trong các nội dung của quản lý chất lượng thì bước đầu tiên lập kế hoạch chất lượng là quan trọng nhất bởi nó chính là cơ sở để tiến hành các bước tiếp theo như thiết lập khung, hay các hoạt động kiểm soát chất lượng...nếu thiếu 1 trong các nội dung đó thì sẽ ko thể hoàn chỉnh khâu quản lý chất lượng cho dự án đc vì các bước đc tiến hành theo tuần tự và bước đầu liên hệ chặt chẽ với bước kế tiếp và nếu thiếu 1 trong mấy bước đó thì hoạt động kiểm soát sẽ ko đc diễn ra.

ThaiSon wrote:Việc quản lý thay đổi và sự kiện của DA là yếu tố chủ yếu trong phạm vi kiểm soát DA. Vậy tại sao 1 hệ thống chính thống, hiệu quả không yêu cầu quá nhiều chi phí hành chính?

Mình xin trả lời: 1 hệ thống chính thống thì đương nhiên trên cơ sở pháp lý nó đã đc thừa nhận vì vậy những chi phí hành chính ko quan trọng hay phát sinh sẽ rất ít nảy sinh do đó 1 hệ thống đc gọi là hiệu quả thì mọi chi phí cho hệ thống đó cũng là tối ưu nhất và hiệu quả nhất.

Tr Mai wrote:cho mình hỏi nhóm nha
câu hỏi thực tế chút
Ví dụ:Một người phát triển phần mềm tới gặp mình: “Mình được đề bạt làm quản lí một dự án nhỏ. Ông chủ của mình bảo hội tụ vào viết mã chứ không lập kế hoạch bởi vì lập kế hoạch là phí thời gian. Viết mã sẽ cho tổn nhiều thời gian hơn để hoàn thành dự án. Câu hỏi của mình là làm sao lập kế hoạch cho dự án mà không phí thời gian và vẫn đạt tới thành công?”

mình xin trả lời câu hỏi của bạn như sau: trong trường hợp này là rất ít xảy ra bởi nguyên tắc của 1 người quản lý dự án phần mềm chuyên nghiệp là phải có kế hoạch và từ đó thực hiện tiến trình cụ thể theo kế hoạch nếu trong quá trình thực hiện có trục trặc gì thì chỉ việc căn cứ vào bản kế hoạch mà sửa chi tiết. Như vậy lập kế hoạch chính là phương án tối ưu nhất để tránh lãng phí thời gian lại vừa hiệu quả khoa học và như vậy hiệu quả công việc sẽ rất lớn.

manhtin2 wrote:2 Theo các bạn có nói "Quản lý cấu hình là:lĩnh vực của quản trị dự án nhằm: Định nghĩa. Xác định. Kiểm tra Cấu hình trong suốt quá trình phát triển phần mềm". Nhưng mình đọc mà không hiểu, mong các bạn giải thích rõ hộ mình nhé! "Quản lý cấu hình" là quản lý cái gì? "Cấu hình" ở đây được hiểu như thế nào?

mình xin trả lời:
- Quản lý cấu hình phần mềm (configuration management)à tập các hoạt
động để quản lý các thay đổi của phần mềm trong suốt vòng đời của nó.Một
loại hoạt động bảo đảm chất lượng phần mềm, được áp dụng cho tất cả các
pha của kỹ nghệ.Bao trùm suốt tiến trình phát triển và tiến hóa của
phần mềm.
Ta có thể tham khảo định nghĩa ngắn gọn sau từ CMM và ISO 15504: “Mục
đích của QLCH là để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm
trung gian cũng như các sản phẩm sau cùng của một dự án phần mềm, xuyên
suốt chu kỳ sống của dự án đó.”Nói cho dễ hiểu và gần gũi, QLCH bao gồm
các công việc về nhận dạng, tổ chức, và quản lý các thay đổi đối với
những sản phẩm đang được xây dựng bởi một nhóm lập trình viên, từ các
sản phẩm trung gian đến sản phẩm sau cùng.
Nội dung quản lý cấu hình phần mềm bao gồm:
Xác định các thay đổi.
Kiểm soát các thay đổi.
Bảo đảm các thay đổi đã được thực hiện.
Báo cáo các thay đổi cho người quan tâm
-Cấu hinh phần mềm: là Các khoản mục cấu thành lên các thành phần phần mềm được tạo ra như là
những chế tác của tiến trình kỹ nghệ phần mềm được tập hợp lại trong
một cái tên chung gọi là cấu hình phần mềm
Các chế tác này có nhiều mức khác nhau
Bộ phận – tổng thể(phạm vi)
Chưa hoàn thiện- hoàn thiện(theo tiền trình chất lượng)
ở các mức tiến hóa khác nhau(các phiên bản-version)

Luuhuyen wrote:Bạn có thể lấy một ví dụ về quản lý cấu hình trong một dự án để mình có thể hiểu hơn về nội dung của phần quản lý cấu hình? thanks

mình xin được trả lời câu hỏi của bạn như sau: mình có thể lấy ví dụ thế này cho bạn hiểu nhé: khi mình sản xuất 1 phần mềm bán hàng chẳng hạn, thì quá trình hoàn thành được sản phẩm không phải là ngày 1 ngày 2 là xong mà phải qua nhiều giai đoạn nhiều bản demo mới có bản hoàn chỉnh. trước khi đưa ra sản phẩm cuối cùng thì phải quản lý tốt cấu hình. mình đưa ra ví dụ nhé trong quá trình mình sản xuất ra phần mềm khi chưa ra bản chính thức mà mình mới có bản demo mà chẳng may bị mất mát hay bi virus thì bạn sẽ làm như thế nào? còn nữa là quản lý cấu hình có phần lưu trữ và bảo trì. nếu bạn không quản lý được cấu hình thì bạn có thể bảo trì được không?

manhtin2 wrote:2 Theo các bạn có nói "Quản lý cấu hình là:lĩnh vực của quản trị dự án nhằm: Định nghĩa. Xác định. Kiểm tra Cấu hình trong suốt quá trình phát triển phần mềm". Nhưng mình đọc mà không hiểu, mong các bạn giải thích rõ hộ mình nhé! "Quản lý cấu hình" là quản lý cái gì? "Cấu hình" ở đây được hiểu như thế nào?

câu hỏi của bạn hình như nội dung nằm toàn bộ trong bản word của nhóm mình hết rồi. bạn có thể đọc tham khảo trong bản word và slide của nhóm mình.

tớ có 1 câu hỏi muốn hỏi các bạn nhóm 6 đây, đề nghị riêng bạn Lân trả lời nhé: Cấu hình tức là như thế nào?

huynh123 wrote:tớ có 1 câu hỏi muốn hỏi các bạn nhóm 6 đây, đề nghị riêng bạn Lân trả lời nhé: Cấu hình tức là như thế nào?

đề nghị nhóm trưởng ko đc chém các thành viên trong nhóm nhé!!! Câu hỏi của bạn đã đc trình bày rất kĩ trong slide và word nhóm mình cũng là nhóm của bạn, mong bạn xem lại giúp mình nhé!!! thank a lot...

Bạn Nguyễn Gia Oai có hỏi nhóm mình như sau:
1.Có bao nhiêu tác nhân gây ra sự thay đổi dự án.Đó là những tác nhân nào?Lấy VD.Đường 32 có các tác nhân nào làm chậm tiến trình dự án.

Mình xin trả lời câu hỏi của bạn như sau:
Có 5 tác nhân gây ra thay đổi:
- Khách hàng
-Các cơ quan/đơn vị liên quan
-Tổ chức dự án
-Người tài trợ
-Chính PM
VD thì nhóm mình đã lấy khá nhiều rồi.Bạn có thể tham khảo những câu hỏi và câu trả lời trước của nhóm mình trong phần trên nhé.Thanks!!

2.Thay đổi quan trọng gồm những vấn đề gì?Trong đó thay đổi nào quan trọng nhất?Tại sao?

Mình xin trả lời câu hỏi của bạn như sau:
Trong thay đổi quan trọng thì có: lịch biểu, đặc tính của sản phẩm, ngân sách, và những gì được xem là quan trọng của dự án.
VD:Nhà tài trợ cắt giảm ngân sách
hoặc: Yêu cầu bổ sung thêm 1 số tính năng của phần mềm
Đó đều là những thay đổi quan trọng vì nó làm thay đổi cơ bản kết quả của dự án.

tình hình là câu hỏi này ko có sẵn trong bài đâu, mà câu hỏi này t đề nghị riêng bạn Lân trả lời cơ mà

Bạn Đinh Thị Hảo có hỏi nhóm mình như sau:
Chúng ta có nên coi trong thay đổi nhỏ hay ko?Tại sao?

Mình xin đưa ra ý kiến như sau:
Thay đổi nhỏ là thay đổi ko làm thay đổi kết quả chung cuộc của dự án, nhưng có thể ảnh hưởng đến sự thành công của dự án.Là 1 PM thì chúng ta ko nên coi thường những thay đổi dù là nhỏ nhặt.
VD như dự án xây nhà:Những phát sinh lặt vặt từ phía khách hàng như xây thêm 1 ô cửa sổ chẳng hạn.Bạn vẫn phải sửa đổi theo ý khách hàng.Tuy ko đáng kể nhưng nó đánh giá chất lượng công việc của bạn.

omaichua wrote:Bạn Đinh Thị Hảo có hỏi nhóm mình như sau:
Chúng ta có nên coi trong thay đổi nhỏ hay ko?Tại sao?

Mình xin đưa ra ý kiến như sau:
Thay đổi nhỏ là thay đổi ko làm thay đổi kết quả chung cuộc của dự án, nhưng có thể ảnh hưởng đến sự thành công của dự án.Là 1 PM thì chúng ta ko nên coi thường những thay đổi dù là nhỏ nhặt.
VD như dự án xây nhà:Những phát sinh lặt vặt từ phía khách hàng như xây thêm 1 ô cửa sổ chẳng hạn.Bạn vẫn phải sửa đổi theo ý khách hàng.Tuy ko đáng kể nhưng nó đánh giá chất lượng công việc của bạn.

hay đấy, cứ thế mà tiến hành nhé!!!

Nhóm 6 nhắn tin tìm bạn "Hoàng Văn Hà " bạn ở đâu qua đây nhanh nhé . Vắng mặt khá lâu rồi

huynh123 wrote:tình hình là câu hỏi này ko có sẵn trong bài đâu, mà câu hỏi này t đề nghị riêng bạn Lân trả lời cơ mà

Tình hình là các bạn nên chú ý lời thông báo của admin các bạn nên đặt các câu hỏi 1 cách tổng quát và xoáy sâu vào bài học những câu hỏi ko có sẵn trong bài tức là ko thuộc phạm vi trả lời của các thành viên trong nhóm. Thứ 2 là để tránh gây mất đoàn kết nội bộ đề nghị nhóm trưởng ko nên lạm quyền đặt riêng câu hỏi cho riêng bất kì thành viên nào cả vì mọi thành viên trong nhóm đều có trách nhiệm và nghĩa vụ trả lời câu hỏi của all member như nhau... Are you ok!!!

slide 31 có viết Kiểm soát rủi ro không nhằm loại bỏ rủi
ro, chỉ nhằm hạn chế tối thiểu thiệt hại của rủi ro
tại sao ko làm cho tối ưu đi

LêHưởng wrote:slide 31 có viết Kiểm soát rủi ro không nhằm loại bỏ rủi
ro, chỉ nhằm hạn chế tối thiểu thiệt hại của rủi ro
tại sao ko làm cho tối ưu đi

Trước hết bạn nên hiểu khái niệm của rủi ro là thế nào?Theo mình thì làm cho tối ưu rủi ro cũng giống như làm hạn chế tối thiểu thiệt hại của rủi ro mà thôi. Vì rủi ro Rủi ro là yếu tố luôn tồn tại trong tất cả các hoạt động nói chung: sản xuất, kinh doanh cũng như trong quản lý dự án phần mềm nói riêng.

Nguyen Tien Thanh wrote:Các bạn nhóm 6 cho mình hỏi là " Thảo luận tận dụng nguồn" là gì? Lấy 1 ví dụ cho rõ nhé ^^ tks

Theo mình hiểu thì : Thảo luận là trao đổi, bàn về vấn đề sử dụng nguồn của dự án như là: Nguồn kinh phí, nguôn nhân lực, nguồn vốn...các nguồn có hạn chế nên ta cần phải tận dụng
Ví dụ: Khi thực hiện chuẩn bị thực hiện 1 dự án nào đó. Điều mà ta quan tâm đầu tiên ở dự án là thời gian thực hiện, nguồn nhân lực, nguồn vốn, nhà đầu tư.....Nhưng mà để dự án được thực thi, ta cần thực hiện nhiều công việc như là xác định dự án, tìm nhà tài trợ....Khi tiến hành dự án thì người quản lý dự cần biết nên sử dụng và tận dụng nguồn như thế nào ....
Theo mình hiểu thì là như thế. Mong các bạn cho ý kiến:)

Bạn Trần Thị Mai có hỏi:
Câu 1:
Chu kỳ của kiểm soát dự án là gi?Có phải tất cả các dự án đều sử dụng chung một chu kỳ kiểm soát hay không?
Câu 2: Có phải tất cả các dự án đều cần phải quản lý rủi ro không? Tại sao vừa cần quản lý rủi ro nhưng lại phải hạn chế lập kế hoạch quản lý rủi ro? Ví dụ?
Mình xin trả lời câu hỏi của bạn như sau:
Câu 1: Câu này A Trọng đã hỏi và nhóm mình đã trả lời rất kỹ ở trên rồi, bạn vui lòng xem lại giúp mình nhé!Có gì k hiểu nhóm mình sẽ bổ xung thêm cho bạn. Thank
Câu 2:Tất các dự án đều phải quản lý rủi ro
Tại vì :
-Quản lý rủi ro có vai trò khá quan trọng trong toàn bộ tiến trình quản lý dự án
-Rủi ro là yếu tố luôn tồn tại trong tất cả các hoạt động nói chung: sản xuất, kinh doanh cũng như trong quản lý dự án phần mềm nói riêng. Nó gây ảnh hưởng không tốt, đôi khi làm dự án thất bại.
- Người quản lý dự án phần mềm nhận biết được các rủi do có thể xảy ra, đưa ra những hoạt động làm giảm thiểu thiệt hại các rủi do gây ra của dự án.
( Và ý này nữa của bạn : " Tại sao vừa cần quản lý rủi ro nhưng lại phải hạn chế lập ra kế hoạch quản lý rủi ro" . mình thấy nó hơi có mâu thuẫn, mh k hiểu ý câu hỏi của bạn ở đây là gì? Nếu có thể bạn vui lòng nói lại ý câu hỏi của bạn được không?)
Ví dụ :
Một dự án dù lớn hay nhỏ đều có thể có rủi ro xảy ra. Tùy thuộc vào độ lớn của dự án, mà ta có thể nhận biết được rủi ro và quản lý được rủi ro. Ví dụ khi mình làm bài tập lớn của môn quản lý dự án phần mềm này nhé. Nhóm mình cũng đã nhận biết được rủi ro như là nhóm mình k thể hoàn thành nó đúng thời hạn do 1 số lý cá nhân bị ốm hay bận công việc gì đó. Và trong quá trình hoàn thành bài tập để post lên forum ấy, không may khi mình đang post đường truyền mạng bị lỗi, minh không thể gửi bài ngay được, phải lùi lại thời gian gửi......
Vì thế nên nhóm mình phải xác định thời gian post bài, và khắc phục ngay khi có sự cố xảy ra, và đó cũng là 1 cách để nhóm mình quản lý rủi ro.