BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM

BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM

ĐẠI HỌC ĐÀ NẴNG ĐẠI HỌC BÁCH KHOA KHOA CÔNG NGHỆ THÔNG TIN  BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GVHD : LÊ THỊ MỸ HẠNH SVTH : NGUYỄN TRƯỜNG LƯU 09T4 PHAN QUỐC HẬU 09T4 TRẦN ĐỨC TRÌNH 09T4 NHÓM : 10A Đà Nẵng, tháng 11 năm 2012 SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 1 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH BÀI TẬP 1 Đề bài: Công ty IT quyết định sản xuất một máy tính mới để cung cấp một môi trường mô phỏng cho các hệ thống thời gian thực. Công ty cần các công nghệ và hệ điều hành mới để để sản xuất máy tính. Phần mềm hệ thống cung cấp giao diện giữa hệ điều hành và phần cứng cần phải được phát triển. Công ty quyết định sử dụng ngôn ngữ lập trình Java đ ể viết phần mềm hệ thống. Tuy nhiên, Java có một số hạn chế trong lập trình hệ thống. Nhóm phát triển xác định một số tính năng mở rộng cần được tích hợp thêm vào chương tr ình d ịch Java để lập trình hệ thống. Đặc tả yêu cầu có thể thay đổi trong quá trình phát triển dự án. Các thành viên phát triển phần mềm cho máy tính mới cần chương tr ình d ịch Java để biên dịch phần mềm. Hầu hết các yêu cầu của phần mềm đều cần các mở rộng của chương tr ình d ịch Java để chạy trên hệ điều hành mới. Hãy xác đ ịnh mô hình phát triển phần mềm phù hợp để phát triển máy tính mới. Yêu cầu các sinh viên chia nhóm và thảo luận. Mô hình lựa chọn: Mô hình xoắn ốc I. Giới thiệu mô hình xoắn ốc: Mô hình xoắn ốc, ban đầu do Boehm đề xuất, là mô hình tiến trình phần mềm tiến hoá vốn cặp đôi bản chất lặp của làm bản mẫu với các khía cạnh hệ thống và có kiểm soát của mô hình trình tự tuyến tính. Nó cung cấp tiềm năng cho việc phát triển nhanh các phiên bản tăng dần của phần mềm. Dùng mô hình xoắn ốc này, phần mềm được phát triển thành từng chuỗi các lần đưa ra tăng dần. Trong những lần lặp đầu, việc đưa ra tăng dần có thể là mô hình trên giấy hay bản mẫu. Trong các lần lặp sau, các phiên bản đầy đủ tăng dần của hệ thống được k ĩ ngh ệ hoá sẽ được tạo ra. Mô hình xoắn ốc được chia thành một số khuôn khổ hoạt động, c ũng c òn đư ợc gọi là vùng nhiệm vụ. Về cơ bản, có từ ba tới sáu vùng: 1. Trao đổi với khách hàng - nhiệm vụ đòi hỏi thiết lập việc trao đổi có hiệu quả giữa người phát triển và khách hàng. 2. Lập kế hoạch - nhiệm vụ đ òi h ỏi định ngh ĩa các t ài nguyên, h ạn thời gian và các thông tin liên quan tới dự án. 3. Phân tích rủi ro - nhiệm vụ đ òi h ỏi định giá cả những rủi ro k ĩ t huật và quản lí 4. K ĩ ngh ệ - nhiệm vụ đ òi h ỏi xây dựng một hay nhiều biểu diễn cho ứng dụng 5. Xây dựng và đưa ra - nhiêm vụ đ òi h ỏi xây dựng, kiểm thử, thiết đặt và cung cấp sự hỗ trợ cho người dùng (như tài liệu và huấn luyện) 6. Đánh giá của khánh hàng - nhiệm vụ đ òi h ỏi thu được phản hồi của khách hàng dựa trên đánh giá về biểu diễn phần mềm được tạo ra trong giai đoạn k ĩ ngh ệ và được SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 2 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH cài đặt trong giai đoạn cài đặt. Mỗi một trong các vùng đều được đặt vào một tập các nhiệm vụ, được gọi là tập nhiệm vụ, vốn được thích ứng với các đặc trưng của dự án được tiến hành. Với các dự án nhỏ, số các nhiệm vụ công việc và tính hình thức của chúng là thấp. Với các dự án lớn, nhiều căng thẳng hơn, thì mỗi vùng nhiệm vụ lại chứa nhiều nhiệm vụ công việc vốn được xác định để đạt tới mức độ hình thức cao hơn. Trong mọi trường hợp, hoạt động hỗ trợ (như quản lí cấu hình phần mềm và đảm bảo chất lượng phần mềm) sẽ được áp dụng. Khi tiến trình tiến hoá này bắt đầu, tổ k ĩ ngh ệ phần mềm đi v ò ng xoắn ốc theo chiều ngược kim đồng hồ, bắt đầu từ trung tâm. Mạch đầu tiên quanh xoắn ốc có thể làm phát sinh việc phát triển đặc tả sản phẩm; các bước tiếp theo quanh xoắn ốc có thể được dùng để phát triển bản mẫu và thế rồi các phiên bản phức tạp dần thêm. Mỗi bước qua vùng lập kế hoạch lại làm nảy sinh việc điều chỉnh kế hoạch dự án. Chi phí và lịch biểu được điều chỉnh dựa trên phản hồi được suy từ đánh giá của khách hàng. Bên cạnh đó, người quản lí dự án điều chỉnh số việc lặp đ ã l ập kế hoạch cần để hoàn chỉnh phần mềm. Không giống như mô h ình ti ến trình cổ điển vốn kết thúc khi phần mềm được chuyển giao, mô hình xoắn ốc có thể được thích ứng để áp dụng trong toàn bộ cuộc đời của phần mềm máy tính. Một cái nhìn khác có thể được xem xét bằng việc kiểm tra trục điểm vào dự án, như được vẽ trong hình trên. Mỗi hình hộp được đặt theo trục có thể được dùng để biểu diễn cho điểm bắt đầu cho các kiểu dự án khác nhau. "Dự án phát triển khái niệm" bắt đầu tại cốt lõi của xoắn ốc và sẽ tiếp tục (nhiều lần lặp xuất hiện theo con đường xoắn ốc mà vốn gắn với vùng tô đậm trung tâm) cho tới khi việc phát triển khái niệm là đầy đủ. Nếu khái niệm này được phát triển thành một sản phẩm thực tại, thì tiến trình tiến qua hình hộp tiếp (điểm vào dự án phát triển sản phẩm mới) và một "dự án phát triển mới" được khởi đầu. Sản phẩm mới sẽ tiến hoá qua một số lần lặp quanh xoắn ốc, đi theo con đường vốn gắn vùng có tô mầu sáng hơn vùng l õi. V ề bản chất, xoắn ốc, khi được đặc trưng theo cách này, vẫn còn làm việc cho tới khi phần mềm được cho nghỉ. Có những lúc tiến trình này “ngủ”, nhưng bất kì khi nào một thay đổi được khởi đầu, thì tiến trình này lại bắt đầu tại SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 3 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH điểm vào thích hợp (tức là nâng cao sản phẩm). Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển cho các hệ thống và phần mềm qui mô lớn. Bởi vì phần mềm tiến hoá khi tiến trình tiến hoá, nên người phát triển và khách hàng hiểu rõ h ơn và ph ản ứng với rủi ro tại từng mức tiến hoá. Mô hình xoắn ốc dùng cách làm bản mẫu như một cơ chế làm giảm bớt rủi ro, nhưng điều quan trọng hơn, làm cho người phát triển có khả năng áp dụng được cách tiếp cận làm bản mẫu tại mọi giai đoạn trong tiến hoá của sản phẩm. Nó duy trì cách tiếp cận từng bước một cách có hệ thống do cách tiếp cận vòng đ ời cổ điển gợi ý, nh ưng t ổ hợp cách tiếp cận này vào một khuôn khổ lặp lại, vốn phản ánh được sát thực hơn thế giới thực. Mô hình xoắn ốc đ òi h ỏi việc xem xét trực tiếp các rủi ro k ĩ thu ật tại mọi giai đoạn của dự án, và nếu được áp dụng đúng thì nó có thể làm giảm rủi ro trước khi chúng trở thành vấn đề thực sự. Nhưng giống như các mô h ình khác, mô hình xo ắn ốc không phải là một liều thuốc bách bệnh. Có thể khó thuyết phục những khách hàng (đặc biệt trong tình huống có hợp đồng) rằng cách tiếp cận tiến hoá là kiểm soát được. Nó đ òi h ỏi tri thức chuyên gia đánh giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt được thành công. Nếu một rủi ro chính không được phát hiện và quản lí thì không nghi ngờ gì nữa vấn đề sẽ xuất hiện. Cuối cùng, chính bản thân mô hình này c ũng còn chưa đư ợc sử dụng rộng rãi nh ư mô hình trình tự tuyến tính hoặc làm bản mẫu. Cần phải có thêm một số năm nữa trước khi tính hiệu quả của mô hình quan trọng này có thể được xác định với sự chắc chắn hoàn toàn. Ưu điểm:  Mô hình xoắn ốc là một trong những mô hình linh hoạt nhất của vòng đ ời phát triển phần mềm. Các giai đoạn phát triển phần mềm có thể được xác định bởi người quản lý dự án, theo sự phức tạp của dự án.  Dự án được giám sát một cách dễ dàng và hiệu quả. Mỗi giai đoạn là những vòng lặp được chia ra một cách rõ ràng.  Mô hình xoắn ốc hướng đến sự phân tích rủi ro trong từng giai đoạn phát triển phần mềm.  Sự thay đổi của phần mềm có thể được kiểm soát và giải quyết trong từng giai đoạn.  Phù hợp với các dự án có nhiều thay đổi, môi trường làm việc không ổn định. Nhược điểm:  Chi phí áp dụng mô hình xoắn ốc thường rất cao.  Mô hình xoắn ốc phức tạp và khó áp dụng.  Đ òi h ỏi năng lực lãnh đ ạo của người quản lý dự án và năng lực của nhóm dự án cao.  Sự thay đổi từ phía khách hang nên những bản mẫu thường không được sử dụng trong sản phẩm thật. SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 4 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH  Việc dự trù kinh phí khó khăn.  Tài liệu đặc tả phức tạp, do phải chỉnh sửa qua từng giai đoạn khác nhau.  Không phù hợp các dự án có rủi ro thấp. II. Phân tích bài toán: Bài toán đặt ra, công ty IT quyết định xây dựng một máy tính mới với công nghệ và hệ điều hành mới. Phần mềm hệ thống được phát triển bằng ngông ngữ Java. Tuy nhiên, Java có nhiều hạn chế về lập trình hệ thống, nhóm phát triển cần tích hợp một số tính năng mở rộng cho chương tr ình d ịch Java. Các đặc tả yêu cầu có thể thay đổi trong quá trình phát triển dự án. Hầu hết các yêu cầu của phần mềm đều cần các mở rộng của chương tr ình d ịch Java để chạy trên hệ điều hành mới. Qua những yêu cầu trên của bài toán, xây dựng một hệ điều hành và áp dụng công nghệ mới vào hệ thống máy tính mới, đây là một dự án với quy mô lớn. Trước tiên, hệ thống cần tích hợp bổ sung một số tính năng cho chương tr ình d ịch của Java, sau đó mới có thể xây dựng được các phần mềm hệ thống và phần mềm ứng dụng khác. Các tính năng tích hợp này chưa được xác định rõ ràng mà dễ thay đổi bổ sung trong quá trình phát triển dư án. Như vậy, việc lựa chọn mô hình xoắn ốc để phát triển dự án này là phù hợp. Thứ nhất, dự án của bài toán đặt ra có quy mô lớn và tính rủi ro cao, những yêu cầu của phần mềm hệ thống chưa được xác định rõ ngay từ khi phát triển dự án, mà được thay đổi trong quá trình phát triển dự án. Không giống như mô h ình t ăng trư ởng, các thay đổi có nguy cơ dẫn đến sự sụp đỗ toàn bộ hệ thống do kiến trúc hệ thống không rõ ràng mà đư ợc thay đổi qua từng giai đoạn, mô hình xoắn ốc tập trung trước tiên vào việc nghiên cứu tính rủi ro của từng giai đoạn phát triển. Với mỗi giai đoạn phát triển, nhiệm vụ đầu tiên của nhóm dự án, phải xác định tính rủi ro của tính năng được tích hợp vào chương tr ình d ịch Java như thế nào ? Liệu có dẫn đến hậu quả lớn đến toàn bộ hệ thống ? Từ những phân tích rủi ro ban đầu cùng với đánh giá việc tích hợp từ những giai đoạn trước, người quản lý dự án và nhóm phát triển dự án sẽ điều chỉnh và quyết định thích hợp. Thứ hai, dự án sẽ được phát triển qua từng giai đoạn, với mỗi giai đoạn, nhóm dự án sẽ tích hợp dần dần các tính năng vào chương tr ình d ịch Java, để thõa mãn các yêu cầu của nhóm phát triển phần mềm ứng dụng và hệ thống. Nhóm dự án có thể sử dụng bản mẫu để xác định rõ h ơn các yêu c ầu của tính năng cần thêm vào. Như vậy hệ thống sẽ được hoàn thiện qua từng giai đoạn, cùng với phân tích rủi ro, hệ thống đảm bảo được tính kiến trúc. Thứ ba, việc quản lý dự án sẽ dễ dàng và hiệu quả hơn, do sự phân chia rõ ràng của từng giai đoạn phát triển hệ thống. Người quản lý sẽ nắm rõ từng giai đoạn, cũng như những thay đổi đặc tả xuất hiện trong giai đoạn đó. Nếu thay đổi được xuất hiện, người quản lý và nhóm dự án sẽ giải quyết được vấn đề dựa trên kiến trúc của hệ thống ở những giai đoạn trước đó. Qua việc đánh giá rủi ro cùng với sự quản lý dễ dàng, người quản lý biết rõ cần phải quay trở SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 5 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH lại giai đoạn nào một cách chính xác nếu việc tích hợp sự thay đổi là không thể ở giai đoạn hiện tại. Từ những yếu tố trên, việc lựa chọn mô hình xoắn ốc là đúng đắn, đảm bảo vẫn kiến trúc của hệ thống khi tích hợp thêm các tính năng vào. BÀI TẬP 2 NGHIÊN CỨU KHẢ THI – FEASIBILITY STUDY Khi nào chúng ta cần dừng một dự án “không tốt” ? Sau một cuộc khảo sát về 8000 dự án IT, Standish Group báo cáo rằng khoảng 30% tổng số dự án đ ã b ị hủy bỏ ("Charting the Seas of Information Technology," Dennis, MA: The Standish Group, 1994). Capers Jones báo cáo rằng trung bình dự án được hủy bỏ ở Mỹ sau một năm so với kế hoạch và chi phí vượt khoảng 200% so với dự kiến tại thời điểm dự án buộc phải dừng lại (Assessment and Control of Software Risks, Englewood Cliffs, N.J.: Yourdon Press, 1994). Jones ước tính số tiền bỏ ra cho các dự án bị hủy lên đến 15% tổng số tiền U.S bỏ ra để phát triển phần mềm, con số này lên đến 14 triệu $ mỗi năm, điều này quả thật hết sức lãng phí. Mặc dù những thống kê trên đ ã ch ỉ ra một cách chân thực, nhưng việc hủy bỏ một dự án quả thật là điều khó khăn, tuy nhiên nếu việc dừng dự án xảy ra quá trễ sẽ dẫn đến những lãng phí hơn nữa. Do đó, đểm giảm tối thiểu số tiền cần cho các công việc cần thiết, ngay từ những bước đầu của vòng đ ời phát triển phần mềm (Software Development Life Cycle: SDLC) cần phải xác định dự án được tiếp tục hay buộc phải dừng lại. “Press Cancel to Exit or OK to Continue” Làm thế nào để hủy bỏ một dự án phần mềm sớm ? Chúng ta cần tiến hành các nghiên cứu khả thi sớm trong dự án để xác định quy mô dự án là hoàn toàn khả thi. Trước tiên, nhóm dự án chuẩn bị các tài liệu liên quan đến việc nghiên cứu khả thi. Các kết quả của nghiên cứu khả thi là một đánh giá tính khả thi, mà tại đó các nhóm dự án, khách hàng và quản lý dự án quyết định tiếp tục hoặc dừng dự án lại. Việc xem xét tính khả thi thường được quyết định thông qua một buổi họp hoặc đôi khi chỉ dự vào sự quyết định của một cá nhân dựa trên những tài liệu nghiên cứu khả thi. Các thông tin cần thiết hỗ trợ cho xem xét tính khả thi có thể được đưa ra sau khi dự án hoàn thành khoảng 10-20%. Nghiên cứu khả thi là một hoạt động thời gian-thử nhiệm (time-tested practice), nhưng nó không được sử dụng nhiều. Một cuộc khảo sát của KPMG cho thấy rằng 84% các công ty SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 6 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH có dự án runaway (vượt ra khỏi kiểm soát) đ ãđư ợc đề xuất sử dụng nghiên cứu khả thi như là một phương tiện ngăn ngừa các vấn đề trong tương lai ("Runaway Projects—Cause and Effect," Software World, vol. 26, no. 3, 1995). Cuộc khảo sát này cho thấy rằng các công ty đ ã không thực hiện phân tích khả thi trong các dự án runaway của họ. Một lý do mà nghiên cứu khả thi không được sử dụng thường xuyên là do sự hiểu sai về thuật ngữ “nghiên cứu khả thi”. Thuật ngữ “nghiên cứu khả thi” gợi lên câu hỏi về tính khả thi kỹ thuật, và đối với những người thuộc nhóm dự án là những chuyên gia về ngôn ngữ lập trình nào đó trên m ột hệ thống máy tính chủ đạo, thì những câu hỏi về tính khả thi kỹ thuật không thể xuất hiện trong đầu của họ. “Nếu như chúng tôi biết về tính khả thi về mặt kỹ thuật của dự án thì tại sao chúng tôi cần phải tiến hành nghiên cứu khả thi ?”. Đối với một vài dự án, tính khả thi kỹ thuật là một mối quan tâm đáng kể: liệu có khả thi khi xây dựng một Star War để phòng chống tên lữa ? Có khả thi về mặt kỹ thuật khi xây dựng một ngôn ngữ tự nhiên tiếng Anh để phiên dịch tiếng Pháp ? Đối với nhiều dự án, tính khả thi kỹ thuật không phải là mối quan tâm chính, mà cần phải xem xét đến các vấn đề phi kỹ thuật: tổng chi phí cần để hoàn thành dự án, thời gian của dự án, khả năng chi trả của công ty, phần mềm sẽ được sử dụng như thế nào sau khi hoàn thành … Trong giai đoạn nghiên cứu khả thi, chúng ta tập trung vào bốn l ĩnh v ực quan tâm chính: 1. Khả thi về kinh tế: chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống được xây dựng đem lại. Tính khả thi về kinh tế thể hiện trên các nội dung sau: - Khả năng tài chính của tổ chức cho phép thực hiện dự án. - Lợi ích mà dự án phát triển hệ thống mang lại đủ bù đắp chi phí phải bỏ ra xây dựng nó. - Tổ chức chấp nhận được những chi phí thường xuyên khi hệ thống hoạt động Một thuật ngữ hay dùng để chỉ tài liệu nghiên cứu khả thi về kinh tế là luận chứng kinh tế. Luận chứng kinh tế nói chung được coi như nền tảng cho hầu hết các hệ thống (các ngoại lệ là hệ thống quốc phòng, hệ thống luật, các hệ thống phục vụ cho các nghiên cứu đặc biệt). Luận chứng kinh tế bao gồm: - các mối quan tâm, nhất là phân tích chi phí/lợi ích - chiến lược phát triển dài hạn của công ty - sự ảnh hưởng tới các sản phẩm lợi nhuận khác - chi phí cho tài nguyên cần cho việc xây dựng và phát triển thị trường tiềm năng 2. Khả thi về kỹ thuật: khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng tới khả năng đạt tới một hệ thống chấp nhận được. Nói cách khác, khả thi kỹ thuật là xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự định áp dụng hay không. Khả thi kỹ thuật thường là l ĩnh v ực khó thâm nhập nhất tại giai đoạn phân tích. Điều thực chất là tiến trình phân tích và xác đ ịnh nhu cầu cần được tiến hành song SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 7 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH song với việc xác nhận tính khả thi kỹ thuật. Các xem xét thường được gắn với tính khả thi kỹ thuật bao gồm: - Rủi ro xây dựng: liệu các phần tử hệ thống có thể được thiết kế sao cho đạt được chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích không? - Có sẵn tài nguyên: có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang xét không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho việc xây dựng hệ thống không ? - Công nghệ: công nghệ liên quan đ ãđ ạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống chưa? 3. Khả thi về pháp lý: nghiên cứu và đưa ra phán quyết về có hay không sự xâm phạm, vi phạm pháp luật hay khó khăn pháp lý từ việc xây dựng và vận hành hệ thống. Tính khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, ngh ĩa vụ pháp lý, sự vi phạm và vô số các bẫy pháp lý khác mà thường là các nhân viên kỹ thuật không biết tới. Trong nước, vấn đề khả thi về pháp lý vẫn chưa được coi trọng một cách đúng mức mặc dù đ ã có m ột số luật liên quan đến CNTT và bảo hộ bản quyền. 4. Khả thi về hoạt động: đánh giá tính khả thi của việc vận hành hệ thống. Trong mỗi phương án người ta cần xem xét hệ thống có thể vận hành trôi chảy hay không trong khuôn khổ tổ chức và điều kiện quản lý mà tổ chức đó (người dùng, khách hàng) có. Mức độ các phương án được xem xét tới trong nghiên cứu khả thi thường bị giới hạn bởi các ràng buộc về chi phí và thời gian. Trong quá trình nghiên cứu khả thi Trong quá trình nghiên cứu khả thi, nhóm dự án phải tạo ra các tài liệu sau đây: - Thõa thuận rõ ràng với những quyết định quan trọng của nhà sản xuất hoặc nhà điều hành với khách hàng - Tầm nhìn của dự án - Chiến lược kinh doanh phần mềm - Động lực ban đầu và mục tiêu đặt ra - Động lực hiện tại và dự toán kế hoạch - Danh sách các rủi ro và kế hoạch giải quyết từng rủi ro - Chi tiết giao diện người dùng mẫu thử, nếu hệ thống yêu cầu một giao diện cụ thể - Yêu cầu về kỹ thuật - Kế hoạch đảm bảo chất lượng phần mềm - Chi tiết kế hoạch phát triển phần mềm Các tài liệu chỉ ra một hoặc một số mối nguy hiểm đối với dự án. Yêu cầu không rõ ràng, thiếu nguồn tài trợ, lập kế hoạch không phù hợp là những nguyên nhân chính dẫn đến sự SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 8 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH thất bại của dự án được chỉ ra bởi khảo sát của Standish Group. Nếu nhóm dự án không chuẩn bị đầy đủ các tài liệu này cho nghiên cứu khả thi, thì không nên tổ chức cuộc họp đánh giá vì bạn không có đủ thông tin để xác định tính khả thi của dự án. Thời gian cần thiết để hoàn thành các tài liệu nghiên cứu khả thi phụ thuộc chủ yếu vào bao nhiêu công việc là cần thiết để xác định các yêu cầu của phần mềm. Nếu người dùng biết chính xác họ cần những gì ở phần mềm, giai đoạn này có thể chỉ tốn 10% tổng thời gian của lịch trình phát triển phần mềm. Trong nhiều trường hợp điển hình khác, quá trình này có thể mất từ 10-20%. Một số trường hợp khác, khách hàng thậm chí không biết cái học muốn là gì, như vậy nhóm dự án phải giúp người dùng tìm ra những gì họ muốn, và như vậy thời gian bỏ ra có thể lên đến 25% hoặc nhiều hơn. Việc xem xét tính khả thi nên tập trung vào các câu hỏi sau: - Khái niệm sản phẩm là khả thi ? - Liệu có sản xuất được một sản phẩm như tầm nhìn ban đầu ? - Ước tính chi phí hiện tại và chi phí mục tiêu để hoàn thành sản phẩm ? - Chi phí ban đầu, chi phí mục tiêu đặt ra và chi phí hiện tại chênh lệch như thế nào? - Chiến lược kinh doanh của phần mềm là hợp lí khi kinh phí hiện tại và dự toán kế hoạch được xem xét ? - Khi các nguy cơ chính đối với dự án được xác định và họ có thể khắc phục ? - Yêu cầu đặc điểm kỹ thuật đầy đủ và ổn định, đủ để hỗ trợ công tác phát triển còn lại ? - Người sử dụng và các nhà phát triển có thể đồng ý về một mẫu thử nghiệm giao diện người dùng chi tiết ? Nếu không, các yêu cầu có thực sự ổn định? - Kế hoạch phát triển phần mềm hoàn chỉnh và đầy đủ để hỗ trợ công việc phát triển hơn nữa? Công việc này được thực hiện trong thời gian 10-20% đầu tiên của dự án nên đủ để trả lời những câu hỏi này. Từ đó, khách hàng hoặc quản lý dự án có đầy đủ thông tin để quyết định có tiếp tục phần còn lại của dự án. Các lợi ích chính của nghiên cứu khả thi Quyết định hủy dự án vào một giai đoạn nghiên cứu khả thi và một giai đoạn chính phát triển giúp các công ty phần mềm ít nhất ba lợi ích. Thứ nhất, một số người xem bất kỳ dự án bị hủy bỏ như một sự thất bại, nhưng một dự án bị hủy bỏ tại thời điểm hoàn thành 10-20% nên được coi là một sự thành công. Hủy bỏ một dự án sau khi nó hoàn thành 10-20% thay vì 80-90% (hoặc như Jones chỉ ra, 200%), SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 9 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH việc hủy bỏ sớm sẽ giúp công ty tiết kiệm rất nhiều chi phí và dành thời gian khảo sát các dự án tiềm năng khác. Thứ hai, nghiên cứu khả thi giúp cho người quản lý dự án đưa ra các yêu cầu tài trợ chính xác hơn mức trung bình. Đầu tiên quản lý dự án yêu cầu tài trợ cho hoạt động nghiên cứu khả thi, tức là 10-20% đầu tiên của dự án được hoàn thành. Sau khi các tài liệu nghiên cứu khả thi được xem xét và những người tài trợ cho dự án đưa ra quyết định “go”, người quản lý dự án yêu cầu kinh phí tài trợ cho các phần còn lại của sản phẩm. Tại thời điểm này, vẫn có thể xảy ra những sự thay đổi về chi phí dự án, nhưng công việc thăm d ò s ẽ giảm khả năng biến đổi này. Cuối cùng, sự yêu cầu người quản lý dự án hoàn thành 10-20% của một dự án trước khi yêu cầu tài trợ cho phần còn lại của dự án, điều này buộc nhóm dự án phải làm việc một cách nghiêm túc và tập trung vào những công việc ban đầu đảm bảo sự thành công của dự án. Những hoạt động này thường được làm qua loa hoặc bỏ qua, và những hậu quả tai hại sẽ trở nên rõ ràng vào các giai đo ạn cuối của dự án. Nếu đội dự án được yêu cầu hoàn thành các công việc ban đầu quan trọng trước khi tiếp tục dự án, thì rủi ro tổng thể có thể được giảm một cách đáng kể. BÀI TẬP 3 Đề bài: Câu 3.1 Hãy đặc tả bởi điều kiện trước và sau các hàm: a. Sắp xếp một danh sách các số nguyên. b. Đảo ngược các phần tử của một danh sách c.Đếm số phần tử có giá trị e trong một danh sách các số nguyên Câu 3.2 Hãy đặc tả các kiểu trừu tượng: a. Đặc tả kiểu trừu tượng cây nhị phân b. Đặc tả kiểu trừu tượng tập hợp Câu 3.3 Hãy sử dụng ngôn ngữ Z đặc tả một số hệ thống quản lý: a. Quản lý thông tin đo àn viên đơn gi ản có một số tính năng như: thêm, xóa, chỉnh sửa một đoàn viên, t ìm ki ếm (theo nhiều tiêu chí khác nhau)… b. Quản lý th ư vi ện đơn giản gồm một số tính năng như quản lý thêm, sửa, xóa độc giả; thêm, sửa, xóa sách; quản lý việc thuê mượn sách,. [...]...10 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH Bài giải: Câu 3.1 Hãy đặc tả bởi điều kiện trước và sau các hàm: a.Sắp xếp một danh sách các số nguyên Funtion_sort ( a : danh sách kiểu số nguyên Post_condition: size : số phần tử của danh sách ) ∀i , 1 . LƯU 3 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH điểm vào thích hợp (tức là nâng cao sản phẩm). Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển cho các hệ thống và phần mềm. LƯU 1 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH BÀI TẬP 1 Đề bài: Công ty IT quyết định sản xuất một máy tính mới để cung cấp một môi trường mô phỏng cho các hệ thống thời gian thực. . đánh giá về biểu diễn phần mềm được tạo ra trong giai đoạn k ĩ ngh ệ và được SVTH : TR ẦN ĐỨC TR ÌNH – PHAN QU ỐC HẬU – NGUY ỄN TR ƯỜNG LƯU 2 BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH cài