báo cuối kỳ quản lý dự án phần mềm

TRƯỜNG ĐẠI HỌC VÕ TRƯỜNG TOẢN KHOA CÔNG NGHỆ THÔNG TIN - - BÁO CUỐI KỲ QUẢN LÝ DỰ ÁN PHẦN MỀM Giảng viên hướng dẫn: Lưu Thúy Huỳnh Hậu Giang, 20/9/2013 NHẬN XÉT CỦA GIẢNG VIÊN Xác nhận giảng viên Lưu Thúy Huỳnh Phu luc Báo cáo: Quản lý dự án phần mềm Bảng 1: Actor Actor Summary Multiplier Number of Actors Simple 1 Average Complex Calculated AW Description Simple actors are other systems that communicate with your software via a pre-defined API An API could be exposed through a dll, or as a REST, SOAP, or any web-service API or remote procedure call (RPC) The key element is that you are exposing interaction with your software through a specific, well-defined mechanism Average actors can either be human beings interacting in a well defined protocol, or they could be systems that interact through a more complex or flexible API The original definition of complex actors specifies that users who interact with the software through a graphical user interface are complex actors While that is true, the same classifcation should apply to users who interact with the system in unpredictable ways An AJAX interface that exposes more of the underlying application (and data stores) than would be available through a rigid protocol might introduce similar complexity Individual Actors Multiplier Actor Name Simple Khach Hang Average Nhan Vien Complex Bo Phan Quan Ly Complex Bo Phan Thong Ke Insert additional rows above this row and copy the cell values to automatically update the counts of actors by type Giảng viên hướng dẫn: Lưu Thúy Huỳnh Báo cáo: Quản lý dự án phần mềm Bảng 2: Use case Unadjusted Use Case Points Simple Average Complex Calculated UUCP 11 Individual Use Cases Average Average Complex Average Simple Simple Simple Complex Complex Multiplier 10 15 Multiplier 10 10 15 10 5 15 15 Complex 15 Simple Simple Simple Giảng viên hướng dẫn: Lưu Thúy Huỳnh Number of Use Cases 3 75 Description Simple Use Case - up to transactions Average Use Case - to transactions Complex Use Case - more than transactions Use Case Name Mua Hang Thanh Toan HD Dang Nhap Nhap Thong Tin SP Lap Hoa Don In Hoa Don Quet The Uu Dai Quan Ly TTNV Quan Ly SP QL Khach Hang Than Thien Xoa Thong Tin KH Sua Thong Tin KH Thong Ke SP Báo cáo: Quản lý dự án phần mềm Simple Average 10 Lap Bao Cao Lap Ke Hoach Nhap Hang Insert additional rows above this row and copy the cell values to automatically update the counts of actors by type Bảng 3: Technical Technical Factor Distributed System Required Response Time Is Important End User Efficiency Complex Internal Processing Required Giảng viên hướng dẫn: Lưu Thúy Huỳnh Multiplier 1 Relative Magnitude (Enter 0-5) Description The architecture of the solution may be centralized or single-tenant , or it may be distributed (like an n-tier solution) or multi-tenant Higher numbers represent a more complex architecture The quickness of response for users is an important (and non-trivial) factor For example, if the server load is expected to be very low, this may be a trivial factor Higher numbers represent increasing importance of response time (a search engine would have a high number, a daily news aggregator would have a low number) Is the application being developed to optimize on user efficiency, or just capability? Higher numbers represent projects that rely more heavily on the application to improve user efficiency Is there a lot of difficult algorithmic work to and test? Complex algorithms (resource leveling, time-domain systems analysis, OLAP cubes) have higher numbers Simple database queries would have low numbers Báo cáo: Quản lý dự án phần mềm Reusable Code Must Be A Focus 1 Installation Ease 0.5 Usability 0.5 Cross-Platform Support 2 Easy To Change 1 10 Highly Concurrent 1 11 Custom Security 12 Dependence On Third-Party Code Giảng viên hướng dẫn: Lưu Thúy Huỳnh Is heavy code reuse an objective or goal? Code reuse reduces the amount of effort required to deploy a project It also reduces the amount of time required to debug a project A shared library function can be re-used multiple times, and fixing the code in one place can resolve multiple bugs The higher the level of re-use, the lower the number Is ease of installation for end users a key factor? The higher the level of competence of the users, the lower the number Is ease of use a primary criteria for acceptance? The greater the importance of usability, the higher the number Is multi-platform support required? The more platforms that have to be supported (this could be browser versions, mobile devices, etc or Windows/OSX/Unix), the higher the value Does the customer require the ability to change or customize the application in the future? The more change / customization that is required in the future, the higher the value Will you have to address database locking and other concurrency issues? The more attention you have to spend to resolving conflicts in the data or application, the higher the value Can existing security solutions be leveraged, or must custom code be developed? The more custom security work you have to (field level, page level, or role based security, for example), the higher the value Will the application require the use of third party controls or libraries? Like re-usable code, third party code can reduce the effort required to deploy a solution The more third party code (and the more reliable the third party code), the lower the number Báo cáo: Quản lý dự án phần mềm 13 User Training Calculated TCF How much user training is required? Is the application complex, or supporting complex activities? The longer it takes users to cross the suck threshold (achieve a level of mastery of the product), the higher the value 0.8 Bảng 4: Environmental Environmental Factor Multiplier Relative Magnitude (Enter 0-5) Familiarity With The Project 1.5 Application Experience 0.5 OO Programming Experience Giảng viên hướng dẫn: Lưu Thúy Huỳnh Description How much experience does your team have working in this domain? The domain of the project will be a reflection of what the software is intended to accomplish, not the implementation language In other words, for an insurance compensation system written in java, you care about the team’s experience in the insurance compensation space - not how much java they’ve written Higher levels of experience get a higher number How much experience does your team have with the application This will only be relevant when making changes to an existing application Higher numbers represent more experience For a new application, everyone’s experience will be How much experience does your team have at OO? It can be easy to forget that many people have no object oriented programming experience if you are used to having it A user-centric or use-case-driven project will have an inherently OO structure in the implementation Higher numbers represent more OO experience Báo cáo: Quản lý dự án phần mềm Lead Analyst Capability 0.5 Motivation Stable Requirements Part Time Staff -1 Difficult Programming Language -1 Calculated EF How knowledgeable and capable is the person responsible for the requirements? Bad requirements are the number one killer of projects - the Standish Group reports that 40% to 60% of defects come from bad requirements Higher numbers represent increased skill and knowledge How motivated is your team? Higher numbers represent more motivation Changes in requirements can cause increases in work The way to avoid this is by planning for change and instituting a timing system for managing those changes Most people don’t this, and some rework will be unavoidable Higher numbers represent more change (or a less effective system for managing change) Note, the multiplier for this number is negative Higher numbers reflect team members that are part time, outside consultants, and developers who are splitting their time across projects Context switching and other intangible factors make these team members less efficient This multiplier is also negative Harder languages represent higher numbers We believe that difficulty is in the eye of the be-coder (groan) Java might be difficult for a fortran programmer Think of it in terms of difficulty for your team, not abstract difficulty 0.65 Bảng 5: Final calculations Calculations From Other Tabs TCF Technical Complexity Factor EF Environmental Factor UUC P Unadjusted Use Case Points AW Actor Weighting Giảng viên hướng dẫn: Lưu Thúy Huỳnh 0.8 0.65 75 Báo cáo: Quản lý dự án phần mềm Calculation of Use Case Points UCP Use Case Points Calculation of Estimated Effort Ratio Hours of Effort per Use Case Point Hours of Effort 43.7 20 874 Dự trù thêm 30% rủi ro: 262.08 ngày 150 ngàn đồng Suy 1h = 18.75 Tiền công: 16387.5 Steps to Calculate Use Case Points For all tabs, enter values only in the highlighted cells Enter Technical Complexity Factors on the Technical tab Enter Environemental Factors on the Environmental tab Identify Use Cases on the Use Case tab Identify Actors on the Actor tab Bảng 6: People by role People by role Role Project Leader Giảng viên hướng dẫn: Lưu Thúy Huỳnh Required number Name Hồ Duy Khánh 10 Báo cáo: Quản lý dự án phần mềm Project manager Quality Assurance Quality control A&D tester developers Total 1 12 Hồ Duy Khánh + Nguyễn Thị Phương Yến + Nguyễn Mai Trang Nguyễn Mai Trang Hồ Duy Khánh Hồ Duy Khánh + Nguyễn Thị Phương Yến + Nguyễn Mai Trang Nguyễn Mai Trang Nguyễn Thị Phương Yến + Hồ Duy Khánh Bảng 7: People by skill and Experience Area Total # 0-12 months experience >12 months experience 10 32 20 2 2 12 UML Sql server Visual studio C# Photoshop Total Bảng 8: Hardware and software Hardware Giảng viên hướng dẫn: Lưu Thúy Huỳnh Software Máy bàn (core I3) UML Laptop (core I5) Sql server Ổ cứng (Gam 4GB) Visual studio 11 Báo cáo: Quản lý dự án phần mềm Máy in C# Photoshop Bảng 9: Risk Type Rish and description (Nguy mô tả) Rish change (Mức độ xảy ra) Risk Impact (Mức độ tác động) Risk Priority (Mức độ ưu tiên xử lý) Risk Owner (Người xử lý) Môi trường làm việc Bị rò điện Trung bình Thấp Cao Hờ Duy Khánh Thiết bị Hư hỏng, rò điện Trung bình Thấp Cao Nguyễn Thị Phương Yến Phần mềm Bị lỗi Trung bình Cao Cao Hồ Duy Khánh Record & File Thiếu Thấp Cao Cao Nguyễn Mai Trang Data and Information Chính xác và toàn vẹn Thấp Cao Cao Hồ Duy Khánh Malicious Code Lây truyền virus Cao Thấp Cao Nguyễn Mai Trang Project Thiếu thuộc tính, chậm Thấp Trung bình Cao Nguyễn Thị Phương Yến Giảng viên hướng dẫn: Lưu Thúy Huỳnh 12 Báo cáo: Quản lý dự án phần mềm Nhân sự Thiếu, khơng đủ trình độ, chưa đủ kinh nghiệm Phân tích và thiết kế Khơng có kinh nghiệm Cao Trung bình Cao Nguyễn Mai Trang Cao Cao Cao Nguyễn Thị Phương Yến Sơ đồ phân chia thời gian PRECEDING ACTIVITY Giảng viên hướng dẫn: Lưu Thúy Huỳnh 13 TIME (Ngày) RESOURCER Báo cáo: Quản lý dự án phần mềm ACTIVITY Phân tích Thiết kế Phân tích đề tài Viết đặc tả Thiết kế UML Thiết kế giao diện Thiết kế CSDL 10 Thiết kế xử lý Cài đặt Kiểm thử 11 12 13 14 15 16 17 18 19 Sơ đồ Usecase Sơ đồ lớp Sơ đồ tuần tự Giao diện quản lý Giao diện người dùng 20 21 Thiết kế form Xử lý sự kiện Module đăng nhập Module thêm Module sửa Module xóa Bảng 10: Giảng viên hướng dẫn: Lưu Thúy Huỳnh 14 1 7 7, 7, 8, 7, 8, 2 2 4 7 5 18 5 5 23 2 1 1 1 1 1 1 Báo cáo: Quản lý dự án phần mềm I Tổng quan Nền tảng Trong dự án, người ta thường mong muốn ước tính số lượng thời gian lại là bao nhiêu? Số lượng cơng việc hoàn thành? Chi phí cho dự án trước hoàn thành? Phân tích giá trị thu (EVA) là cách để đo lường số lượng công việc thực dự án, dự báo chi phí dự án và ngày hoàn thành Phương pháp này dựa thước đo quan trọng gọi là giá trị thu hay chi phí ngân sách thực công việc (BCWP) Biện pháp này cho phép tính tốn số hiệu suất chi phí và lịch trình mà dự án thực tương đối so với kế hoạch ban đầu Các số này cho phép dự báo dự án làm tương lai Giá trị thu sử dụng ba giá trị liệu, tính tốn hàng tuần, tháng, Ba giá trị là: - BCWP: ngân sách chi phí việc thực - BCWS: ngân sách chi phí việc theo lịch - ACWP: chi phí thực tế việc thực Định nghĩa ba giá trị bản 2.1 BCWP (ngân sách chi phí việc thực hiện) Đây là chi phí ban đầu tính tốn để hoàn thành cơng việc ngày phân tích Nó trả lời cho câu hỏi “bao nhiêu công việc hoàn thành?” (thu vơ) 2.2 BSWS (ngân sách chi phí việc theo lịch) Đây là tổng chi phí ngân sách ngày phân tích trả lời cho câu hỏi “bao nhiêu công việc hoàn tất ngày này?” BCWS tính từ kế hoạch dự án, xấp xỉ cách nhân tổng ngân sách phần nhỏ toàn thời gian thực dự án thời điểm phân tích 2.3 ACWP (chi phí thực tế việc thực hiện) (chi ra) Đây là chi phí để thực hoàn thành tất công việc ngày phân tích trả lời cho câu hỏi “chúng ta thực thi công việc bao lâu?” ACWP thường xác định từ hệ thống kế toán tổ chức, xấp xỉ cách nhân số người với số giờ, ngày, tuần làm việc Giảng viên hướng dẫn: Lưu Thúy Huỳnh 15 Báo cáo: Quản lý dự án phần mềm Biện pháp tính tốn từ giá trị mô tả trên: - - Phương sai lịch hay độ biến động (Schedule Variance: SV): SV = BCWP– BCWS Nếu là 0, bạn làm tiến độ Nếu nhỏ 0, bạn chậm tiến độ Nếu lớn 0, bạn thực trước thời hạn Chênh lệch chi phí (Cost Variance: CV): CV = BCWP– ACWP Nếu là 0, bạn làm theo ngân sách Nếu nhỏ 0, bạn thực ngân sách Nếu lớn 0, bạn thực ngân sách Giảng viên hướng dẫn: Lưu Thúy Huỳnh 16 ... Required number Name Hồ Duy Khánh 10 Báo cáo: Quản lý dự án phần mềm Project manager Quality Assurance Quality control A&D tester developers Total 1 12 Hồ Duy Khánh + Nguyễn Thị Phương Yến... Huỳnh 14 1 7 7, 7, 8, 7, 8, 2 2 4 7 5 18 5 5 23 2 1 1 1 1 1 1 Báo cáo: Quản lý dự án phần mềm I Tổng quan Nền tảng Trong dự án, người ta thường mong muốn ước tính số lượng thời gian lại... việc hoàn thành? Chi phí cho dự án trước hoàn thành? Phân tích giá trị thu (EVA) là cách để đo lường số lượng công việc thực dự án, dự báo chi phí dự án và ngày hoàn thành Phương

Định dạng
Số trang	16
Dung lượng	331,6 KB