Bài giảng Bộ môn Công nghệ phần mềm - Bài 7: Thẩm định và xác minh phần mềm

Bài 7: Thẩm định và xác minh phần mềm. Bài giảng bao gồm các kiến thức liên quan đến công nghệ phần mềm như: Khái niệm V&V, mục đích của V&V, cách thức tiến hành, xác minh tĩnh và động, các loại thử nghiệm, quy trình Debug, ứng dụng của phân tích tĩnh... Nội dung rất bổ ích đối với các bạn học chuyên ngành. Mời các bạn cùng tham khảo.

Th m đ nh và Xác minh ph n  ẩ ị ầ

m m : Verification and Validation ề

BM CNPM – Khoa CNTT – 

HVKTQS 10/2012

Khái ni m V&V (gi i thích) ệ ả

 Th m đ nh ph n m m: ẩ ị ầ ề   Là xem ph n m m cho ầ ề

k t qu  đúng hay không và có th a mãn yêu c u ế ả ỏ ầ

c a ngủ ườ ử ụi s  d ng hay không

 Xác minh ph n m m:  ầ ề Là xem s n ph m có đúng ả ẩ

là s n ph m đả ẩ ược yêu c u không và chầ ương trình 

có đúng v i đ c t  không.ớ ặ ả

 Th m đ nh và xác minh ph n m m là 2 quá trình ẩ ị ầ ềliên  t c,  xuyên  su t  t   lúc  phân  tích  các  yêu  c u ụ ố ừ ầ

c a  khách  hàng  cho  đ n  khi  giao  s n  ph m,  v i ủ ế ả ẩ ớ

m c đích: ụ

không, phát hi n l i c a ph n m m ệ ỗ ủ ầ ề

M c đích c a V&V ụ ủ

 T o s  t  tin v  ph n m m s  đ t  ạ ự ự ề ầ ề ẽ ạ

đ ượ c m c tiêu đ  ra ụ ề

 Đi u này không có nghĩa là s  t o ra  ề ẽ ạ

ph n m m không có l i chút nào ầ ề ỗ

 Ki u s  d ng ph n m m s  quy t đ nh  ể ử ụ ầ ề ẽ ế ị

m c đ  t  tin c n thi t: ứ ộ ự ầ ế

 User expectations

 Users may have low expectations of certain kinds of  software.

 Marketing environment

 Getting a product to market early may be more  important than finding defects in the program.

 Thanh tra ph n m m. Liên quan đ n vi c phân tích ầ ề ế ệ

h  th ng trong  tr ng thái tĩnh (không ch y) đ  phát ệ ố ạ ạ ể

hi n các v n đệ ấ ề (Xác minh tĩnh)

 Có th  s  d ng các công c  phân tích tài li u và phân tích  ể ử ụ ụ ệ

mã ngu n đ  h  tr ồ ể ỗ ợ 

 Ki m  th   ph n  m m.  Liên  quan  đ n  vi c  cho  ch y ể ử ầ ề ế ệ ạ

và quan sát hành vi c a ph n m m (Xác minh đ ng).ủ ầ ề ộ

 H  th ng đ ệ ố ượ c cho ch y cùng v i d  li u ki m th  và hành  ạ ớ ữ ệ ể ử

vi c a nó s  đ ủ ẽ ượ c quan sát

Xác minh tĩnh và đ ng ộ

Formal specification

High-level v design

Requirements

specification

Detailed design

Program

testing Software

inspections

Các lo i th  nghi m ạ ử ệ

 Các lo i th  nghi m: ạ ử ệ

 1. Th  th ng kê: ử ố  cho nhi u b  d  li u khác nhau ề ộ ữ ệ

đ  ch y th  và tính t n su t xu t hi n th t b i  ­> ể ạ ử ầ ấ ấ ệ ấ ạ

ki m tra tính đúng đ n (validation­ th m đ nh)ể ắ ẩ ị

 2. Th  khuy t t t: ử ế ậ  Cho nh ng b  d  li u th t đ c ữ ộ ữ ệ ậ ặ

bi t đ  ch y th  => ph i l a ch n đệ ể ạ ử ả ự ọ ược nh ng b  ữ ộ

d  li u th t đ c bi t. Phép th  đữ ệ ậ ặ ệ ử ược coi là thành công nh t n u ph i đấ ế ơ ược nhi u khuy t t t nh t.ề ế ậ ấ

 3. Th  gi i h n t i(áp l c): ử ớ ạ ả ự  N u ph n m m có gi i ế ầ ề ớ

h n t i, ta th  b ng cách tăng d n t i cho đ n khi ạ ả ử ằ ầ ả ếkhông ch u đị ược.  = Ki m tra đ  tin c yể ộ ậ

 Ki m  th   khuy t  t t  và  g   r i  là  nh ng  ti n  trình ể ử ế ậ ỡ ố ữ ếriêng bi t.ệ

 Th m đ nh và xác minh liên quan đ n vi c xem xét ẩ ị ế ệ

s  t n t i c a các khuy t t t trong chự ồ ạ ủ ế ậ ương trình

 G  r i liên quan đ n vi c xác đ nh v  trí và s a ch a ỡ ố ế ệ ị ị ử ữ

nh ng l i đã tìm th y.ữ ỗ ấ

 Debugging  liên  quan  đ n  vi c  xây  d ng  m t  gi  ế ệ ự ộ ảthuy t  v   hành  vi  c a  chế ề ủ ương  trình  và  ki m  tra  gi  ể ảthuy t đó đ  tìm ra l i.ế ể ỗ

Quy trình Debug

 K   ho ch  ki m  th   nên  ch   ra  các  chu n  c n  s  ế ạ ể ử ỉ ẩ ầ ử

d ng  cho  ti n  trình  ki m  th   thay  vì  mô  t   các  d  ụ ế ể ử ả ữ

li u testệ

L p k  ho ch cho V&V: Mô hình V ậ ế ạ

K  ho ch ki m th ế ạ ể ử

Thanh tra ph n m m ầ ề

 Liên quan đ n vi c ki m tra mã ngu n đ  tìm ra các v n đ  b t  ế ệ ể ồ ể ấ ề ấ

th ườ ng và khuy t t t ế ậ

 Không yêu c u ch y ph n m m tr ầ ạ ầ ề ướ c và khi thanh tra

 Có  th   ti n  hành  thanh  tra  m i  đ i  t ể ế ọ ố ượ ng  c u  hình  c a  ph n  ấ ủ ầ

m m (các b n đ c t  yêu c u, thi t k , d  li u test,…) ề ả ặ ả ầ ế ế ữ ệ

 Là m t k  thu t hi u qu  đ  phát hi n ra l i ộ ỹ ậ ệ ả ể ệ ỗ

 Nhi u khuy t t t khác nhau có th  đ ề ế ậ ể ượ c phát hi n ch  b i m t  ệ ỉ ở ộ

l n thanh tra ầ

 Trong m t l n ki m th , m t khuy t t t có th  ch a đ ộ ầ ể ử ộ ế ậ ể ư ượ c phát 

hi n, vì v y c n ph i ti n hành nhi u l n ệ ậ ầ ả ế ề ầ

 Các lĩnh v c tái s  d ng và tri th c l p trình cho phép phát hi n  ự ử ụ ứ ậ ệ các lo i l i th ạ ỗ ườ ng hay x y ra ả

Thanh tra và ki m th  ph n m m ể ử ầ ề

 Thanh tra và ki m th  b  sung cho nhau, không ph i ể ử ổ ả

là nh ng k  thu t xác minh đ i l p nhauữ ỹ ậ ố ậ

 C  hai nên đả ược s  d ng trong ti n trình V&Vử ụ ế

 Thanh tra có th  ki m tra để ể ược s  phù h p c a ph n ự ợ ủ ầ

m m v i đ c t  nh ng không ki m tra đề ớ ặ ả ư ể ược s  phù ự

h p c a ph n m m v i yêu c u th c t  c a khách ợ ủ ầ ề ớ ầ ự ế ủhàng

 Thanh tra không th  đánh giá để ược nh ng đ c tr ng ữ ặ ưphi ch c năng nh  hi u su t, tính kh  d ng,…ứ ư ệ ấ ả ụ

Thanh tra ch ươ ng trình

 Là cách ti p c n hình th c hóa đ  rà soát tài  ế ậ ứ ể

li u ệ

 Có m c đích rõ ràng là phát hi n khuy t t t  ụ ệ ế ậ (nh ng không ch nh s a) ư ỉ ử

 Khuy t t t có th  là nh ng l i logic, nh ng d   ế ậ ể ữ ỗ ữ ị

th ườ ng trong mã ngu n nh  nh ng tình tr ng  ồ ư ữ ạ sai sót (ví d  bi n không đ ụ ế ượ c kh i t o) ho c  ở ạ ặ

s  không phù h p v i các chu n mã ngu n ự ợ ớ ẩ ồ

Đi u ki n ti n thanh tra ề ệ ề

 Các b n đ c t  đã ph i có và s n sàngả ặ ả ả ẵ

 Các thành viên c a đ i thanh tra ph i n m ch c các ủ ộ ả ắ ắtiêu chu n trong công ty, t  ch cẩ ổ ứ

 Đã có mã ngu n đồ ược vi t không có l i cú phápế ỗ

 Danh sách các l i c n thanh tra đã đỗ ầ ược chu n bẩ ị

 B   ph n  qu n  lý  đã  đ ng  ý  v i  nh ng  chi  phí  phát ộ ậ ả ồ ớ ữsinh do thanh tra

 B  ph n qu n lý không độ ậ ả ược s  d ng k t qu  thanh ử ụ ế ảtra đ  đánh giá nhân viênể

Quá trình thanh tra

Th  t c thanh tra ủ ụ

 Đ i thanh tra độ ược gi i thi u t ng quan v  h  th ngớ ệ ổ ề ệ ố

 Mã và các tài li u kèm theo đệ ược đ a trư ước cho t ng ừthành viên c a đ i thanh traủ ộ

 Thanh  tra ghi chép  l i nh ng l i  đã  đạ ữ ỗ ược phát  hi n ệ

và v  trí c a chúngị ủ

 Các s  s a đ i đự ử ổ ược th c hi n đ  s a ch a nh ng ự ệ ể ử ữ ữ

l i đã đỗ ược phát hi nệ

 Vi c thanh tra l i có th  c n ho c không c nệ ạ ể ầ ặ ầ

Các vai trò thanh tra

 Danh sách các l i chung nên đ ỗ ượ c s  d ng  ử ụ

đ  đi u khi n vi c thanh tra ể ề ể ệ

 Danh  sách  l i  ph   thu c  vào  ngôn  ng   l p  ỗ ụ ộ ữ ậ trình

 Đ n gi n h n là ki m tra ki u trong ngôn ng   ơ ả ơ ể ể ữ

l p trình, ph c t p h n là ki m tra theo danh  ậ ứ ạ ơ ể sách l i. Ví d : Kh i t o, đ t tên h ng, thoát  ỗ ụ ở ạ ặ ằ

kh i vòng l p, gi i h n m ng,… ỏ ặ ớ ạ ả

Inspection checks

Inspection checks (ti p) ế

 Là m t s  tr  giúp r t hi u qu  khi thanh tra  ộ ự ợ ấ ệ ả

 Ch  là m t s  b  sung thêm ch  không thay th  ỉ ộ ự ổ ứ ếthanh tra

Các giai đo n phân tích tĩnh ạ

 Control flow analysis. Ki m tra các lu ng đi u khi n có nhi u l i thoát ể ồ ề ể ề ố

ho c nhi u đi m b t đ u đ  tìm ki m nh ng đo n code không th  truy  ặ ề ể ắ ầ ể ế ữ ạ ể

c p đ ậ ượ c,…

 Data use analysis. Phát hi n các bi n không đ c kh i t o, các bi n ệ ế ượ ở ạ ế

đ ượ c vi t hai l n mà không có ch  gán giá tr  xen gi a, các bi n đ ế ầ ỗ ị ữ ế ượ c  khai báo nh ng không đ ư ượ c s  d ng,… ử ụ

 Interface analysis. Ki m tra tính nh t quán c a đo n ch ng trình, các ể ấ ủ ạ ươ khai báo th  t c và vi c s  d ng chúng ủ ụ ệ ử ụ

 Information flow analysis. Xác đ nh s  ph  thu c c a các bi n đ u ra. ị ự ụ ộ ủ ế ầ Không  c n  phát  hi n  nh ng  đi u  b t  th ầ ệ ữ ề ấ ườ ng  c a  chúng  nh ng  c n  ủ ư ầ làm  n i  b t  thông  tin  v   s   ph   thu c  đó  cho  thanh  tra  rà  soát  mã  ổ ậ ề ự ụ ộ ngu n ồ

 Path analysis. Xác đ nh các l  trình c a ch ng trình và l p danh sách ị ộ ủ ươ ậ các  statements  trong  t ng  l   trình.  Nh ng  danh  sách  này  có  th   s   ừ ộ ữ ể ẽ

c n khi rà soát ầ

 C  hai giai đo n trên đ u t o ra m t l ả ạ ề ạ ộ ượ ng l n thông tin. C n ph i c n  ớ ầ ả ẩ

th n khi s  d ng ậ ử ụ

ng d ng c a phân tích tĩnh

 Có  giá  tr   đ c  bi t  đ i  v i  nh ng  ngôn  ng   ị ặ ệ ố ớ ữ ữ

đ nh  ki u  y u  nh   C,  nh ng  ngôn  ng   này    ị ể ế ư ữ ữ hay đem l i nh ng l i không đ ạ ữ ỗ ượ c phát hi n  ệ

b i trình biên d ch ở ị

 Ít  hi u  qu   cho  nh ng  ngôn  ng   đ nh  ki u  ệ ả ữ ữ ị ể

m nh  nh   Java  do  trình  biên  d ch  đã  phát  ạ ư ị

hi n đ ệ ượ ấ c r t nhi u l i mã ngu n ề ỗ ồ

Các ph ươ ng pháp hình th c ứ

mathematical specification of the system is  produced.

technique.

analysis  of  the  specification  and  may  develop  formal  arguments  that  a  program  conforms to its mathematical specification.

 Producing  a  mathematical  specification  requires  a  detailed  analysis  of  the  requirements  and  this  is  likely  to  uncover errors.

 They  can  detect  implementation  errors  before  testing  when  the  program  is  analysed alongside the specification.

of confidence in a program more cheaply  using other V & V techniques.

development

 The philosophy is defect avoidance rather than defect removal

Construct structured program

Define software increments

Formally verify code

Integrate increment

inspections.

 The state based model is a system 

specification and the inspection process  checks the program against this mode.l

 The programming approach is defined 

so that the correspondence between the  model and the system is clear.

 Mathematical arguments (not proofs) 

are used to increase confidence in the  inspection process.

 Specification  team    Responsible  for  developing 

and maintaining the system specification

 Development  team.    Responsible  for developing  and  verifying  the  software.    The software  is  NOT  executed  or  even  compiled during this process

 Certification  team    Responsible  for  developing 

a  set  of  statistical  tests  to  exercise  the  software after  development.  Reliability  growth  models used to determine when reliability is acceptable

Cleanroom process teams

 The  results  of  using  the  Cleanroom  process  have been  very  impressive  with  few  discovered  faults  in delivered systems.

 Independent  assessment  shows  that  the 

process  is  no  more  expensive  than  other approaches

 There  were  fewer  errors  than  in  a  'traditional' development process

 However,  the  process  is  not  widely  used.  It  is  not clear  how  this  approach  can  be  transferred 

to  an  environment  with  less  skilled  or  less motivated software engineers

Cleanroom process evaluation

Tài li u tham kh o ệ ả

 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.  Chapter  25, 26

 I.  Sommerville,  Software  Engineering.  5th  Ed., Addison­Wesley, 1995. Chapters 9, 19, 20, 21