Software Process part 2

SOFTWARE PROCESS MODELS

shutterstock-133551053-498-860-500-i

Waterfall process

  • Định nghĩa bởi Royce
  • Sử dụng phổ biến dù có nhiều yếu điểm
  • Thực hiện lần lượt từng pha từ trên xuống, output trên là input dưới
  • Pha dưới bắt đầu khi pha trên đã hoàn tất

1

  • Điểm mạnh:
    • Đơn giản, dễ xài
    • Được ứng dụng nhiều và nhiều người có kinh nghiệm với nó
    • Dễ quản lí vì tính “cứng nhắc” của nó
    • Phân bố tài nguyên dễ, mỗi pha khác nhau, dễ phân bố người
    • Làm việc OK với các project nhỏ khi yêu cầu dễ hiểu
  • Điểm yếu:
    • Yêu cầu phải hiểu rõ từ đầu, không thì gây hại nghiêm trọng
    • Khó tin: chờ lâu để có kết quả và không biết nó chạy đúng ý hay không
    • Không có feedback của stackholder sau khi test: test xong là release sản phẩm, hết trách nhiệm
    • Nhiều vấn đề của hệ thống khó mà phát hiện cho tới cuối quá trình: không test sớm sao biết lỗi???
    • Thiếu tính song song: Test ngồi chơi vài tháng chờ dev làm xong mới làm, quá sướng
    • Sử dụng tài nguyên không hiệu quả: y như ý trên

Interactive and Incremental Development 

  • Mặc dù Waterfall nhiều điểm yếu nhưng phải công nhận một điều là thứ tự các phase phải tuân thủ quy trình căn bản như Waterfall: lấy yêu cầu, design, thực thị và test
  • Khi mà phát triển phần mềm thì sẽ có nhiều vấn đề cần được xem lại, do đó phần mềm thường được phát triển theo vòng lặp (theo chu kì) và dựa trên feedback để phát triển.
  • Sự thật là không có cái gì mà hiểu rõ từ bước đầu. Các iterative process thì tuân theo và chấp nhận điều này.

2.png

  • Sản phẩm của từng iteraction có thể được sử dụng cho nội bộ team dev hoặc cho stackholder, customer dùng, các loại có thể là:
    • Một cái concept, bằng chứng nghiên cứu chỉ ra tính khả thi của dự án
    • Một bản mẫu (prototype)
    • một sản phẩm internal (tool đánh giá, tool giả lập, …)
    • một sản phẩm external cho khách hàng
  • Đối xử với mỗi interaction như một dự án riêng làm ta có thể rõ ràng việc cần làm, chia nhỏ việc. -> Lên kế hoạch và dự tính bước kế tiếp để đảm bảo sản phẩm đáp ứng đúng nhu cầu -> giảm nguy hiểm cho dự án

Prototyping, Feasibility Studies and Proof of Concept 

Lên bản mẫu và Feasibility Studies là những kỹ năng quan trọng trong phát triển phần mềm

Khi bắt đầu dự án, thì có rất nhiều thứ để lo lắng, prototype là cách để kiểm định và xem tính khả thi của dự án

Agile processes có nhiều lợi ích cho prototyping, tuy nhiên không phải tất cả vì prototyping nên làm song song với luồng dự án chính

3.png

Tuỳ theo ước tính tầm giá trị của prototype thì ta sẽ làm prototype khác nhau. Giá trí, chi phí nào nên bỏ ra cho prototype thường tuân theo biểu đồ sau:

4

Lợi ích của prototype:

  • Xác định và hạn chế việc tốn thời gian cho mấy cái không cần thiết mà prototype chỉ ra
  • Hiện thực vài tính năng chính để mình làm được, hạn chế nguy cơ
  • Hạn chế việc customer thay đổi yêu cầu khi thấy sản phẩm của dev
  • Tính toán trường hợp đẹp nhất, xuất nhất của dự án

Thông thường thì prototype được xây dựng nhanh và không cần viết tài liệu.

Feasibility Studies là phân tích về khả năng tồn tại của một ý tưởng. Nó mô tả một nghiên cứu sơ bộ được tiến hành để xác định và ghi nhận sự tồn tại của dự án. Các kết quả của phân tích này được sử dụng trong việc đưa ra quyết định có nên tiến hành dự án hay không.Cho thấy doanh nghiệp sẽ hoạt động như thế nào dưới một giả định, chẳng hạn như công nghệ đã sử dụng, cơ sở vật chất và thiết bị, nhu cầu vốn và các khía cạnh tài chính khác.

Spiral Model

  • Là một trong các iterative model, được biết đến với tên Barry Boehm’s Spiral Model
  • Đây là model hướng nguy cơ – giải quyết nguy cơ của process, khi mà ok rồi thì đi theo waterfall
  • Mỗi iteraction gồm:
    • Xác định các mục tiêu và hạn chế của sản phẩm
    • Đánh giá các dự án và quy trình thay thế để đạt được các mục tiêu
    • Xác định các nguy cơ
    • Tính toán chi phí hiệu quả của một tập hợp các rủi ro bằng cách sử dụng phân tích, thi đua, benmarks, mô hình và nguyên mẫu
    • Phát triển dự án: yêu cầu, thiết kế, thực thi và kiểm chứng
    • Plan cho vòng lặp kế tiếp và tương lai
    • Stackholder review lại sản phẩm của vòng lặp và xác nhận

5.png

  • Lợi thế:
    • Quản lí nguy cơ sớm và trong suốt process
    • Phần mềm tiến hoá theo process, hạn chế lỗi
    • Plan được build trong dự án, phù hợp và theo kịp tiến độ
  • Nhược điểm:
    • Khó dùng, nhiều cái sẽ gây ra sự trùng lắp giữa iteraction
    • Quá to so với project nhỏ

Unified Software Development Process 

  • Được đề cập đến bởi Jacobon, Booch, và Rumbaugh vào năm 1999

6.png

  • Các iteraction chia vào 4 phase:
  • Inception
    • Xác định tính khả thi
    • Làm business cases
    • Xác định tầm nhìn và phạm vi dự án
    • Xác định giá trị, kế hoạch và cái milestone
    • Đánh giá các nguy cơ chính
    • Làm prototype
  • Elaboration (Xây dựng)
    • Xác định yêu cầu chi tiết
    • Tạo baseline
    • thực hiện implement code
    • Đánh giá lại nguy cơ và giải quyết các nguy cơ cao
    • Định nghĩa thước đo dự án
    • Định nghĩa lại plan
  • Construcrion (Xây dựng)
    • hoàn thành các yêu cầu còn lại
    • thực hiện implement các design còn lại
    • Test và chuẩn bị hệ thống deploy
  • Transition (chuyển đổi)
    • Làm beta test
    • Sửa lỗi
    • Viết user manual
    • Chuyển giao sản phẩm
    • Train khách hàng

8

9

Lợi thế

  • Tính toán nhiều khía cạnh của dự án
  • Tồn lại lâu và được sử dụng nhiều và hoàn thiện

Điểm yếu

  • Thiết kế chủ yếu cho project bự
  • Đối với project nhỏ thì quá sức

Agiles

qhcrt3lijr_agile-scrum-belgium

Tuân theo các nguyên tắc:

  • “Cá nhân và sự tương tác hơn là quy trình và công cụ”
  • “Phần mềm chạy tốt hơn là tài liệu đầy đủ”
  • “Cộng tác với khách hàng hơn là đàm phán hợp đồng”
  • “Phản hồi với sự thay đổi hơn là bám theo kế hoạch”

Thường có các đặc tính sau:

  • Team nhỏ và gắn chặt với nhau
  • Thường xuyên và lên lịch gặp gỡ khách hàng lấy yêu cầu
  • Tài liệu thì chỉ ở mức vừa đủ (trừ tài liệu high-level)

10

  • Đại diện khách hàng làm việc trong team
  • User stories là requirement ~ sát với nhu cầu thực tế
  • Refactoring (chap 24)
  • Pair programming
  • unit testing liên tục và UAT theo cài đặt mong muốn của khách hàng

Lợi thế:

  • Luôn có kết quả thấy được
  • Dev có xu hương năng động hơn
  • Khách hàng cung cấp nhiều yêu cầu theo hướng tốt hơn, chính xác hơn

Nhược điểm:

  • Nhiều vấn đề với dự án lớn
  • Tài liệu luôn là câu hỏi, thiếu spec

Open-Source Processes

opensource-development

  • Phát triển và bảo trì dựa nên tinh thần tình nguyện.
  • Mọi thứ được public cho tất cả mọi người

Có nhiều lí do để làm open source

  • Ít tốn tài nguyên
  • Được thoả mãn, ”phê” một cách chuyên nghiệp
  • mở điều kiện chỉnh sửa và tích hợp
  • phục vụ nghiên cứu
  • có nhiều testing mở rộng
  • bảo trì xịn hơn
  • Gây hại cho khách hàng tiềm năng, giựt khách tiềm năng của đối thủ
  • Có kiến thức từ thị trường
  • đáp ứng yêu cầu cốt lõi
  • đáp ứng nhu cầu

Cũng có nhiều lí do không làm

  • Tài liệu thiếu thốn, nghèo nàn
  • Không bảo đả có dev xuất hiện
  • Không có quản lí
  • Không có quản lí yêu cầu
  • Mở cho đối thủ luôn

pros-cons-foss

Lợi thế:

  • Có nhiều người làm free cho mình
  • Dev có xu hướng năng động hơn
  • Được test tốt

Nhược điểm:

  • Public cho mọi người
  • Thiếu tài liệu
  • Tài liệu thiết kế nghèo nàn

One thought on “Software Process part 2

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: