Bài giảng môn công nghệ phần mềm bài 1

Giới thiệu chung Định nghĩa phần mềm và phân loại phần mềm  Khái niệm Công nghệ phần mềm  Lịch sử tiến triển Công nghệ phần mềm  Các giai đoạn sản xuất phần mềm thông thường sẽ bao

Giới thiệu chung về Công nghệ phần mềm

Tài liệu tham khảo môn

học

 R Pressman, Kỹ nghệ phần mềm Tập 1, 2, 3 NXB Giáo dục, Hà Nội,

1997 (Người dịch: Ngô Trung Việt).

 R Pressman, Software Engineering: A Practioner’s Approach 5th Ed., McGraw-Hill, 2001

 I Sommerville, Software Engineering 5th Ed., Addison-Wesley, 1995

 Pankaj Jalote, An Integrated Approach to Software Engineering, Third

Edition, Springer.

 Wendy Boggs, Michael Boggs Mastering UML with Rational Rose

2002 Copyright © 2002 SYBEX Inc.

 Đoàn Văn Ban Phân tích, Thiết kế và Lập trình Hướng đối tượng -

1997 Nxb Thống kê Việt nam.

Giới thiệu chung

 Định nghĩa phần mềm và phân loại phần mềm

 Khái niệm Công nghệ phần mềm

 Lịch sử tiến triển Công nghệ phần mềm

 Các giai đoạn sản xuất phần mềm thông thường sẽ bao gồm:

 Phân tích (yêu cầu)

 Thiết kế (xác định chức năng, development)

 Sửa chữa

 Chuyển giao

 Quá trình phần mềm (software process)

 Quá trình phát triển phần mềm: water fall, unified, agile

 CASE tools :

 Khái niệm CASE Tools

 Phân loại CASE Tools

(2) các cấu trúc dữ liệu trợ giúp CT thao tác với thông tin,

(3) các tài liệu mô tả hoạt động cũng như sử dụng CT.

 “Custom-built”

 Nhóm các hệ quản trị CSDL

Phân loại phần mềm

 Nhóm các chương trình ứng dụng có tính hệ thống:

 Nhóm các chương trình xử lí dữ liệu đa năng: Chương trình hệ chuyên gia, hệ mô phỏng, hệ tự động thiết kế, dạy học và tự học.

 Chương trình xử lí nhận dạng, phân tích, tổng hợp tiếng nói, hình ảnh.

 Tất cả những chương trình điều khiển qui trình công nghiệp.

 Nhóm các phần mềm thời gian thực

 Nhóm các phần mềm nhúng

 Nhóm các phần mềm thông minh

Công nghệ phần mềm

 Công nghệ phần mềm là một lĩnh vực

nghiên cứu của tin học nhằm đưa ra các

nguyên lý, phương pháp, công cụ, phương tiện giúp cho việc thiết kế và cài

đặt một sản phẩm phần mềm đạt được các yêu cầu sau một cách tốt nhất:

 Phải có tính đúng đắn và khoa học.

 Dễ tiếp cận và cải tiến.

 Phổ dụng.

 Độc lập với các thiết bị.

Công nghệ phần mềm

 Công nghệ phần mềm là sự thiết

lập và sử dụng các nguyên lý kỹ thuật đúng đắn để xây dựng các phần mềm một cách kinh tế, tin cậy, và có thể làm việc trên mọi máy tính

Nội dung của CNPM

 Tìm hiểu yêu cầu của bài toán, yêu cầu của khách hàng, thu thập đầy đủ các thông tin và phân tích theo mọi khía cạnh kể cả chiều rộng lẫn chiều

sâu.

 Đối với đặc tả của chương trình, nêu được các

tính chất, đặc trưng của dữ liệu vào và ra mà

không cần quan tâm đến nội dung các thao tác

bên trong của nó Đặc tả có thể sử dụng các công thức hoặc mô hình toán học để đặc tả một cách hình thức hoặc dùng ngôn ngữ tự nhiên để diễn tả một cách phi hình thức hoặc kết hợp cả hai.

 Thiết kế chương trình bằng phương pháp lập trình

có cấu trúc, hướng đối tượng.

Nội dung của CNPM

 Kiểm thử chương trình một cách có hệ

thống: chạy thử chương trình với nhiều bộ

dữ liệu khác nhau, kiểm tra phát hiện lỗi, kiểm tra tính ổn định, kích thước vùng nhớ, vùng nhớ nháp của chương trình và độ

phức.

 Kiểm chứng tính đúng đắn của chương trình.

 Đánh giá chất lượng của chương trình.

 Quản lý việc thiết kế, cài đặt vận hành và bảo trì phần mềm, cung cấp các phần mềm trợ giúp liên quan cho người sử dụng.

Các giai đoạn phát triển

PM

 Tìm hiểu nhu cầu của khách hàng:

 Đây là giai đoạn đầu tiên và không

thể thiếu được trong việc xây dựng

phần mềm cho một hệ thống nào đó

triển tạo ra suy cho đến cùng thì phải đáp ứng được (có thể không phải là toàn bộ) nhu cầu của khách hàng.

Các giai đoạn phát triển

PM

 Xác định rõ các chức năng hệ thống:

 Chia ra từng khối lớn tương đối độc lập

và giao cho từng nhóm người thực hiện

việc thiết kế - sản xuất - thử nghiệm theo một nguyên tắc nhất định và một ngôn ngữ cùng với cơ sở dữ liệu thống nhất

Các giai đoạn phát triển

PM

 Sửa chữa và thử nghiệm nếu thấy cần thiết:

 Đây là giai đoạn mang tính nội bộ của nhóm phát triển phần mềm Hệ thống có thể được chia thành nhiều phần nhỏ (module) rời rạc nhau

 Do vậy khi xây dựng xong chúng ta cần phải thử

nghiệm cho từng module đó Sau đó tiến hành tích hợp các module lại để tạo thành hệ thống hoàn

chỉnh Việc kiểm thử tích hợp phải được tiến hành

 Các thay đổi có thể được thêm vào; các ý kiến đóng góp của khách hàng cũng được ghi nhận và đưa vào trong phần mềm tại giai đoạn cuối cùng này.

Các giai đoạn phát triển

PM

kiến của khách hàng để quyết định nhân bản nếu

nó tốt hoặc là để sửa đổi Đào tạo người sử dụng :

 Trong quá trình từ khi tìm hiểu nhu cầu của khách hàng cho đến khi hoàn thiện, trong thời kỳ trước kia, trung bình mỗi người trong một ngày chỉ làm được 5 hoặc 6 lệnh Khi đó có thể nói “Lập trình phần mềm hết sức nặng nhọc”

 Chính vì vậy người ta phải cố gắng sử dụng những chương trình con (modul) chương trình của những người

đi trước tạo ra (thường để trong thư viện) và đồng thời người ta cũng tạo ra các modul thêm vào thư viện để người khai thác có thể dùng.

Các giai đoạn phát triển

 Giai đọan hỗ trợ (support phase): Hỗ trợ thay đổi có thể xảy ra và bảo trì

hệ thống

• Quá trình phần mềm cung cấp một khuôn khổ cho các hoạt động quản lý đem lại sự dễ dàng trong kiểm soát.

• Quá trình phần mềm hiện đại phải linh hoạt, chỉ yêu cầu những hoạt động, những sự kiểm soát, những công cụ làm việc thích hợp cho nhóm hay sản phẩm

• Các dự án khác nhau đòi hỏi quá trình phần mềm khác nhau

• Các sản phẩm công việc của kỹ sư phần mềm (chương trình, tài liệu, dữ liệu) được sản xuất như là hệ quả của các hoạt động được xác định bởi quá trình phần mềm

• Các chỉ số tốt nhất để đánh giá một quá trình phần mềm là chất lượng, tính kịp thời, khả năng tồn tại lâu dài của sản phẩm phần mềm

Quá trình PT PM

Umbrella Activities

• Software project management (SPM)

• Formal technical reviews (FTRs)

Mô hình Thác nước

Mô hình Thác nước

 Các giai đoạn:

 Giai đoạn xác định các yêu cầu của bài toán

và đề tài.

 Giai đoạn thiết kế.

 Giai đoạn thử nghiệm.

Nhược điểm (chi tiết)

 Mô hình này giả định rằng các yêu cầu của một hệ thống phải được cố định (ví dụ, được vạch rõ) trước khi bắt đầu thiết kế Điều này có thể cho phép tự động hóa thiết kế

hệ thống Nhưng đối với hệ thống mới, xác định các yêu cầu thường khó khăn do người sử dụng thậm chí không biết các yêu cầu Do đó, có yêu cầu không thay đổi là không thực tế đối với các dự án như vậy.

 Cố định các yêu cầu thường đòi hỏi phải lựa chọn phần cứng (bởi vì nó là một phần của đặc tả yêu cầu) Một dự

án lớn có thể phải mất vài năm để hoàn thành Nếu phần cứng được lựa chọn đầu tiên, sau đó do tốc độ công nghệ thay đổi, thì có khả năng các phần mềm cuối cùng sẽ sử dụng một công nghệ phần cứng sắp lỗi thời Điều này rõ ràng là không thích hợp cho các hệ thống phần mềm như vậy.

Mô hình Prototyping

để phát triển sau đó đưa cho người sử dụng đóng góp ý kiến, đưa người dùng dùng thử cho đến khi đạt yêu cầu.

 Ưu điểm: Không có giai đoạn tích hợp, người dùng được tiếp cận với hệ thống ngay từ những giai đoạn đầu để bổ sung hoàn thiện phần mềm theo đúng yêu cầu

Mô hình Prototyping

Các mô hình tiến hóa

 Xoắn ốc

 Tăng dần

Mô hình xoắn ốc

 Gồm có 4 bước hoạt động chính

 Thiết lập mục tiêu: xác định mục tiêu cho từng pha của dự án.

 Lập kế hoạch: đánh giá dự án và pha tiếp theo của

mô hình xoắn ốc sẽ được lập kế hoạch.

 Đánh giá và giảm thiểu rủi ro: rủi ro được đánh giá và thực hiện các hành động để giảm thiểu rủi ro.

 Phát triển và đánh giá: sau khi đánh giá rủi ro sẽ chọn lựa 1 mô hình phát triển cụ thể.

 Có thể xem xét thêm 2 giai đọan nhỏ:

 Hỗ trợ - cài đặt

 Lấy ý kiến khách hàng

Mô hình xoắn ốc (tiếp tục)

Mô hình phát triển tăng

dần

 Phát triển hệ thống càng nhanh càng tốt=> Cải biên hệ thống cho đến khi đạt được yêu cầu đặt ra.

 Là biến thể của mô hình tiến hóa, có

ý tưởng giống với mô hình làm bản mẫu và xoắn ốc, nhưng thực hiện trên từng khối độc lập, mỗi khối đều

có Đặc tả, thiết kế, triển khai tích hợp, Chuyển giao khách hàng.

Mô hình RUP

 Là mô hình dành riêng cho hướng ĐT

 Có 3 đặc trưng:

 Lấy kiến trúc làm trung tâm

 Điều khiển bởi các ca sử dụng

 Lặp lại và tăng dần

 Tương đồng với mô hình xoắn ốc, tuy nhiên mỗi bước lặp của RUP, nội dung hoạt động có nội dung riêng gắn với ngôn ngữ mô hình hóa thống nhất UML

 Giai đoạn:

 Inception phase (giai đoạn khởi động)

 Elaboration phase (giai đoạn soạn thảo)

 Construction phase (giai đoạn xây dựng)

 Transition phase (giai đoạn chuyển giao)

 Production phase (software monitoring and support)

Mô hình UP (RUP)

UP Work Products

• Inception phase

– Vision document

– Initial use-case model

– Inital project glossary

– Inital business case

– Inital risk assessment

– Software architecture description

– Inital risk assessment

– Project plan (phases and iterations)

– Business model

– Prototypes description

– Executable architectural prototype

– Preliminary design model

– Revise risk list

– Project plan (iteration plan, workflow, milestones) – Preliminary user manual

– Delivered software increment

– Beta test reports increment

– User feedback

Mô hình phát triển nhanh RAD

 Là phương pháp luận gộp các hoạt động phân tích, thiết kế, xây dựng vào một loạt vòng lặp phát triển ngắn.

 Hướng đến nhu cầu đưa người sự dụng tham gia vào PTTK bằng cách sử dụng CASE

 Đáp ứng nhu cầu hiệu quả và chi phí bảo trì thấp

 Thích hợp cho đội phát triển nhỏ

Phát triển hệ thống hình thức hoá

 Được mô tả với các bước:

 Xác định yêu cầu

 Đặc tả hình thức

 Biến đổi hình thức

 Kiểm thử tích hợp và hệ thống

 Tư tưởng chính là biểu diễn các đặc tả yêu cầu bằng các ký pháp toán học

 Áp dụng các biến đổi khác nhau để chuyển từ đặc tả hình thức -> chương trình

 Khi chuyển đổi các biểu diễn của đặc tả được chi tiết dần nhưng luôn được đảm bảo tính đúng đắn=> Chương trình là triển khai đúng của đặc tả

 Ưu điểm:

 Có thể áp dụng chứng minh tính đúng đắn của đặc tả

 Chứng minh chương trình đáp ứng được yêu cầu của đặc tả đã cho

 Chi phí đặc tả cao, nhưng chi phí sau đó lại nhỏ hơn nhiều so với phương pháp khác

 Dễ theo dõi các bước nhỏ trong quá trình chuyển đổi

 Nhược điểm:

 Việc đặc tả đòi hỏi trình độ trừu tượng cao

 Việc chứng minh sự đúng đắn là khó khăn

 Phương pháp này là tương đối khó

 Điều chỉnh yêu cầu

 Thiết kế hệ thống với kỹ thuật tái sử dụng

 Xây dựng và tích hợp hệ thống

Các mô hình AGILE

 Các PP Agile được phát triển vào những năm 90s nhằm khắc phục các trì trệ/khóa khăn trong việc tài liệu hóa quá trình PT phần mềm.

 Nguyên lý của các PP AGILE:

 Even late changes in the requirements should be entertained

(small-increment model of development helps in accommodating them)

 Sự làm việc của phần mềm là thước đo chính của sự tiến bộ trong một

dự án

 Để dự án được tiến triển, phần mềm nên được phát triển và chuyển giao nhanh chóng trong từng bước nhỏ

 Thậm chí những thay đổi muộn trong các yêu cầu cũng được hoan

nghênh (mô hình phát triển chia nhỏ giúp chấp nhận chúng)

 Giao tiếp mặt đối mặt được ưa chuộng hơn giao tiếp bằng văn bản

 Thông tin phản hồi liên tục và sự tham gia của khách hàng là cần thiết cho việc phát triển phần mềm chất lượng tốt

 Thiết kế đơn giản và hoàn thiện dần theo thời gian là một cách tiếp cận tốt hơn so với thiết kế tổng quát phức tạp ngay từ đầu để xử lý tất cả các tình huống có thể xảy ra

 Ngày bàn giao sản phẩm được quyết định bởi các nhóm các cá nhân tài năng và có quyền (và không bị chi phối bởi người khác)

CASE tools

 Là các phần mềm khác nhau được xây dựng trên

cơ sở những mô hình và phương pháp cụ thể

Cung cấp sự trợ giúp cho việc tự động hay bán tự động hóa các hoạt động phát triển phần mềm Có

2 mức: bàn thợ và môi trường phát triển, tất cả

được gọi là kỹ nghệ phần mềm có sự trợ giúp của máy tính (CASE).

 Bàn thợ (workbench): Thông tin chúng tạo ra có thể dùng cho công cụ khác hay giai đoạn phát triển tiếp theo.

 Môi trường (Environment): Hệ thống trợ giúp phát triển phần mềm

 Tại sao CASE quan trọng?

CASE tools

 Các hệ thống CASE thường được sử dụng để hỗ trợ các hoạt

động trong quy trình phát triển phần mềm Có hai loại CASE:

yêu cầu và thiết kế

lỗi và kiểm thử

 Ngôn ngữ mô hình hóa thống nhất (UML – Unified Modeling

Language) cung cấp một ngôn ngữ chung cho tất cả các giai đoạn phát triển phần mềm hướng đối tượng: Một số các công cụ dựa trên ngôn ngữ ngày như Rational Rose, PowerDesigner.

 Một môi trường CASE chuẩn bao gồm:

Phân loại các công cụ phát triển phần mềm

 Môi trường phát triển: Môi trường tích

hợp, Môi trường cho tiến trình

Một số CASE Tool thường

dùng

Tài liệu tham khảo bài

giảng

 R Pressman, Kỹ nghệ phần mềm Tập 1, 2, 3 NXB Giáo dục, Hà Nội, 1997 (Người dịch: Ngô Trung Việt).

 R Pressman, Software Engineering: A Practioner’s Approach 5th Ed., McGraw-Hill, 2001 Chapters 1,