BÁO CÁO THỰC TẬP KỸ THUẬT CÔNG TY FPT SOFTWARE

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

.......................

BÁO CÁO KẾT QUẢ THỰC TẬP
Thời gian từ 17/6 đến 15/07

Họ và tên sinh viên:
Lớp:Công nghệ thông tin 1

Điện thoại: 01663916836

Email:

Cơ sở thực tập:
Tên cơ quan: FPT Software Co.,Ltd.
Địa chỉ: Tòa nhà FPT,đường Duy Tân,quận Cầu Giấy,Hà Nội ,Việt Nam.
Người giao nhiệm vụ thực tập:
Viện công nghệ thông tin-Trường Đại Học Bách Khoa Hà Nội
Giáo viên theo dõi:Nguyễn Hồng Phong

Hà Nội ,07/2013


LỜI MỞ ĐẦU
Thực tập là cơ hội cho sinh viên có được cái nhìn thực tế về công việc trong tương lai của
mình.Giúp sinh viên thấy được những gì mình được học trên trường có ý nghĩ gì cho công việc
sau này.Là cơ hội để sinh viên có thể được đi vào những gì án thực tế của công ty,cho sinh viên
thấy mình cần những gì,những thiếu sót cũng như những kỹ năng cần thiết trong công việc.Nó
không chỉ là các kiến học trên giảng đường mà còn cả về các kỹ năng khác như kỹ năng làm việc

nhóm,kỹ năng trình bày,tác phong công việc…Nhận thấy được điều đó nhà trường đã tạo điều
kiện cho sinh viên được thực tập từ sớm.Vì thế, em xin cám ơn nhà trường và cơ quan mà em
được thực tập.Chuyến thực tập đã giúp em nhận ra được rất nhiều điều và đặc biệt là tìm được
hướng đi cho công việc sau này của mình.

Chữ ký của công ty thực tập

Chữ ký của sinh viên thực tập



NHỮNG THU HOẠCH TỪ TÌM HIỂU THỰC TẾ VÀ THỰC TẬP
I.Những điều thu hoạch được từ tìm hiểu thực tế ở cơ sở thực tập
1.Tổng quan về công ty

FPT Software

Tên công ty:FPT software Co.,Ltd
Trụ sở : Tòa nhà FPT,đường Duy Tân,quận Cầu Giấy,Hà Nội,Việt Nam
Nhân viên:4,100(năm 2012)
Doanh thu:81,5 triệu dollars(năm 2012)
Ngày thành lập:Ngày 13 tháng 1 năm 1999
Chủ tịch:Hoàng Nam Tiến
Giám đốc:Nguyễn Thành Lâm
Website:www.fpt-software.com
 Cấu trúc tổ chức


 Tổ chức Fsoft năm 2012

Tổ chức lãnh đạo


2.Văn hóa FPT
 Tầm nhìn FPT: FPT mong muốn trở thành một tổ chức kiểu mới, giàu mạnh bằng nỗ lực lao
động sáng tạo trong khoa học kỹ thuật và công nghệ, làm khách hàng hài lòng, góp phần hưng
thịnh quốc gia, đem lại cho mỗi thành viên của mình điều kiện phát triển tốt nhất tài năng và một
cuộc sống đầy đủ về vật chất, phong phú về tinh thần.
 FPT Gen
 Cho đến nay, Văn hóa FPT được miêu tả rõ nhất trong FPT Gen.
 “Văn hóa STC”, thường được biết đến thông qua các bài hát STC, chỉ là một thành phần
của FPT Gen.
 FPT Gen = Văn hóa FPT, thể hiện trong “làm” và “chơi”, trong công việc và cuộc sống.
 5 Thành phần của FPT Gen
 “Sâu – sáng – tuyệt – thông – phong”
 Triết lý sâu sắc
 Lãnh đạo sáng suốt
 Chất lượng tuyệt hảo
 Thông tin thông suốt
 STC phong phú
 Tinh thần FPT
“NGƯỜI FPT CHÚNG TA TÔN TRỌNG CÁ NHÂN, ĐỔI MỚI VÀ ĐỒNG ĐỘI. ĐÂY LÀ
NGUỒN SỨC MẠNH TINH THẦN VÔ ĐỊCH, ĐEM ĐẾN CHO FPT THÀNH CÔNG NỐI
TIẾP THÀNH CÔNG. TINH THẦN NÀY LÀ HỒN CỦA FPT. MẤT NÓ ĐI, FPT KHÔNG
CÒN LÀ FPT NỮA. BỞI VẬY, MỖI NGƯỜI FPT CÓ TRÁCH NHIỆM BẢO VỆ ĐẾN


CÙNG TINH THẦN FPT. LÃNH ĐẠO CÁC CẤP – NGƯỜI GIỮ LỬA CHO TINH THẦN
NÀY, CẦN CHÍ CÔNG, GƯƠNG MẪU VÀ SÁNG SUỐT. LÀM ĐƯỢC VẬY, FPT SẼ
PHÁT TRIỂN VÀ TRƯỜNG TỒN CÙNG THỜI GIAN.”

 Quy trình chất lượng
 Định hướng khách hàng
o Hiểu biết sâu sắc nhu cầu của khách hàng, kể cả nhu cầu tiềm ẩn, và đáp ứng một
cách tốt nhất các nhu cầu đó.
 Tham gia của mỗi thành viên
o Mỗi người ở từng vị trí phát huy cao nhất năng lực và sáng tạo của mình.
 Nhất quán và đa dạng
o FPT là một thực thể thống nhất trong mục tiêu nhưng đa dạng trong hành động.
 Thước đo thực tiễn
o Các quyết định và đánh giá dựa trên việc phân tích các dữ liệu và thông tin.
 Cải tiến và đổi mới liên tục
o FPT không ngừng nâng cao năng lực tổ chức và cá nhân, chất lượng sản phẩm và
dịch vụ thông qua đổi mới, cải tiến và sáng tạo liên tục.
 Hệ thống thông tin
 Cấu thành
o Kiến trúc hệ thống
o Hạ tầng ICT
o Các trình ứng dụng
 Các nguyên lý
o Tin học hóa toàn diện và triệt để
o Đảm bảo cao nhất kiến trúc tập trung và tính tích hợp
o Hạ tầng ICT tiên tiến
o Xây dựng các hệ hỗ trợ ra quyết định
o Đảm bảo mềm dẻo, dễ mở rộng, nâng cấp
o Đầu tư mạnh dạn và hợp lý
3.Cách làm việc trong một dự án ở Fsoft
3.1 Các hoạt động trong dự án phần mềm
 Engineering(Kỹ sư)
 Phân tích yêu cầu
 Thiết kế

 Coding
 Kiểm thử
 Quản lý cấu hình
 Triển khai cài đặt
 Bảo trì
 Hỗ trợ khách hàng
 Project Management(Quản lý dự án)
 Lập kế hoạch
 Theo dõi
 Kết thúc dự án
3.2 Vòng đời của một dự án phần mềm


Kế hoạch phát triển phần mềm

Kế hoạch bảo trì phần mềm

3.3 Các trách nhiệm và vai trò của dự án
Tổ chức dự án


Quản lý dự án
 Kỹ thuật/Các trách nhiệm của trưởng nhóm
 Các vấn đề & giải pháp
o Thiết kế
o Giải pháp kỹ thuật
 Quản lý nhóm
o Phân công nhiệm vụ
o Theo dõi & Báo cáo
o Cố vấn, đào tạo thành viên trong nhóm

 Các trách nhiệm của DEV
 Phân tích yêu cầu
 Sửa lỗi,Coding
 Kiểm thử đơn vị
 Các trách nhiệm của Tester
 Phân tích yêu cầu
 Test case
 Thực hiện kiểm thử
 QA-Quality Assurance(Dảm bảo chất lượng)
 Xem lại các sản phẩn của dự án,các tài liệu
 Xem lại các hoạt động quản lý dự án,các cột mốc,các tài liệu
 Thực hiện kiểm toán,kiểm định cuối cùng
4.Bảo mật thông tin ở Fsoft
 Các quy định bảo mật thông tin
1. Ra vào nơi làm việc
2.

Sử dụng máy tính

3.

Sử dụng thiết bị ngoại vi

4.

Sử dụng thiết bị ghi hình ghi âm

5.

Sử dụng thông tin mật của công ty

6. Sử dụng thông tin cá nhân


7.

Sử dụng mạng nội bộ, file server và intenet

8.

Sử dụng email

9.

Phòng chống virus

10. Ý thức về bản quyền
 Bảo mật thông tin theo ISO27001
FPT Software nghiêm khắc theo ISO27001 để bảo vệ thông truy nhập của của công ty,các khách
hàng và các nhà cung cấp từ tất cả các mối đe dọa,cả bên trong lẫn bên ngoài,vô tình hay cố ý.

4.1 Quy định ra vào nơi làm việc
1. Đeo thẻ nhân viên có ảnh trong suốt thời gian làm việc.
2. Nghiêm cấm sử dụng hoặc mượn thẻ của người khác để ra
vào công ty
3. Yêu cầu quẹt thẻ khi ra/vào khu vực làm việc
•

Khi mất thẻ thì Nhân viên thực hiện các bước sau:
+ Ghi vào sổ tại lễ tân

+Báo ngay Admin hoặc CBQL thẻ về việc mất, khoảng thời gian để quên.
+ Mượn thẻ Backup tại quầy lễ tân

4.2 Sử dụng máy tính
1. Chỉ được sử dụng máy tính do Công ty cấp cho công việc và tuân thủ theo các yêu cầu
bảo mật của Công ty


2. Không tự ý tháo lắp máy tính; không cài đặt và sử dụng phần mềm ngoài danh
sách White-list của IT. Trong trường hợp cần cài đặt hay sửa chữa, hãy liên hệ
với Ban Mạng và Máy tính để nhận được sự trợ giúp.
3. Không được để máy qua đêm. Phải xin phép Quản trị dự án & được phê duyệt
khi có nhu cầu để máy qua đêm phục vụ công việc
4. Phải đăng ký sử dụng máy tính xách tay cá nhân: xin phê duyệt của lãnh đạo
đơn vị, IT cài đặt và cấu hình theo chuẩn bảo mật của Fsoft

4.3 Sử dụng thiết bị ngoại vi
1. Các thiết bị ngoại vi: thiết bị mạng có dây và không dây, thiết bị lưu trữ thông tin như ổ cứng
ngoài, ổ USB, ổ CD/DVD
2. Không được sử dụng các thiết bị nhớ ngoài; Trường hợp cần thiết sử dụng thiết bị nhớ ngoài, phải
xin phép sử dụng và phải đăng ký sử dụng thiết bị này
3. Không lưu thông tin mật vào các thiết bị nhớ ngoài nếu không sử dụng biện pháp mã hoá dữ liệu
phù hợp

4.4 Sử dụng thiết bị ghi hình ghi âm
•

Tuỳ theo đặc thù sản xuất của mỗi Đơn vị sản xuất phần mềm, việc sử dụng các thiết bị ghi hình,
ghi âm (VD: máy ảnh kỹ thuật số, điện thoại có chức năng chụp ảnh, máy ghi âm…) sẽ bị hạn
chế hoặc bị cấm sử dụng trong khu vực làm việc.

4.5 Dấu hiệu nhận biết thông tin bảo mật của công ty

4.6 Sử dụng thông tin cá nhân
Nên cẩn trọng khi tiết lộ thông tin cá nhân trong và ngoài công ty:
a) Kinh nghiệm làm việc
b) Lương thưởng
c) Kỹ năng làm việc


4.7 Sử dụng mạng nội bộ
•

Mạng nội bộ:
a) Không được kết nối các thiết bị vào mạng khi chưa được phép
b) Không được tự ý cài đặt và cấu hình các thiết bị mạng
c) Không được tự ý thay đổi cấu hình mạng của PC
d) Không được chia sẻ tài liệu dự án trong mạng nội bộ
e) Chỉ lưu các dữ liệu của dự án trên server

•

Internet:
a) Phải sử dụng proxy của công ty để kết nối internet
b) Chỉ truy nhập các trang web hay dịch vụ mạng được cung cấp bởi IT
c) Nghiêm cấm sử dụng các công cụ như FreeProxy, FreeGate,
UltraSurf,… để vượt tường lửa và proxy

4.8 Sử dụng Email

1. E-mail @fsoft.com.vn là tài sản thông tin của Công ty
2. Chỉ được sử dụng e-mail của mình cho mục đích công việc, không được sử dụng đăng ký vào các
forum hay mạng xã hội
3. Phải thiết lập «Important Notice» ở phần chữ ký của e-mail
4. Trước khi gửi e-mail cần kiểm tra:
 Địa chỉ e-mail của người nhận
 Thông tin CC, BCC; Sử dụng BCC khi cần thiết
 Tiêu đề email và nội dung e-mail
 Scan virus


4.9 Phòng chống Virus
Nguồn lây nhiễm:
1. Copy/dowload phần mềm hay dữ liệu từ bên ngoài
2. Máy tính không được cập nhật các bản patch cho Hệ điều hành và chương trình
AntiVirus
3. Cài đặt các môi trường test (kể cả máy ảo) nhưng không cài đặt và cấu hình chương trinh
Antivirus đúng qui định của Cty
4.

Sử dụng máy tính cá nhân không đăng ký và kiểm tra bởi IT

5. Các thiết bị lưu trữ ngoài chưa đăng ký và kiểm tra
6. Kết nối VPN đến máy tính của khách hàng không được cài đặt AntiVirus đầy đủ
Cách phòng tránh:
1. Kiểm tra và update các bản vá lỗi của hệ điều hành & các phần mềm (được cài
trên máy) ngay khi có bản cập nhật
2. Kiểm tra máy tính đã cài phần mềm diệt virus Symantec hay McAfee; được
update tự động từ server không?
3. Không được tự ý remove chương trình AntiVirus trên máy tính

4. Không tự ý download dữ liệu, phần mềm từ internet
5. Không truy nhậpvào các trang web không rõ nguồn gốc, không phục vụ công việc
6. Không mở file không rõ địa chỉ người gửi, mà phải xoá ngay.
7. Nếu nghi ngờ máy tính nhiễm virus, nhanh chóng tháo dây mạng LAN hoặt tắt Wireless và
báo cho Ban Mạng và Máy tính.

4.10 Ý thức về bản quyền
1. Không được copy, phát tán, sử dụng phần mềm không bản quyền


2. Không được cài đặt và sử dụng các phần mềm không có trong danh sách phần mềm white-list của
Fsoft
3. Các phần mềm khác muốn sử dụng phải thông qua phê duyệt của trưởng đơn vị và kiểm tra bởi
IT
4. Lưu ý sử dụng các phần mềm opensource

SỰ CỐ BẢO MẬT
TIN

XỬ LÝ
THÔNG

1. Phải báo cáo sự cố cho cán bộ quản lý trực tiếp/ISMS team trong vòng 2 tiếng
2. Không được tự ý giải quyết bằng cách của mình
3. Lưu giữ cẩn thận dấu hiệu, bằng chứng của hiện tượng/sự cố đã xảy ra để tường trình
chính xác thời gian, hiện tượng xảy ra, các hành động đã thực hiện.
4. Xác định nguyên nhân gốc rễ, hành động khắc phục, hành động phòng ngừa và các bài
học tránh việc lặp lại
5. Mọi nhân viên phải có trách nhiệm trong xử lý sự cố về bảo mật thông tin
Mức xử lý kỷ luật người vi pham BMTT tối đa là sa thải

BA NGUYÊN TẮC BẢO MẬT THÔNG TIN
1. Không được mang tài sản thông tin ra khỏi khu vực làm việc

2. Nếu thật sự cần thiết mang tài sản thông tin ra ngoài thì phải được
phép của cán bộ quản lý

3. Khi mang tài sản thông tin ra ngoài phải có biện pháp bảo mật
phù hợp

5.Quy trình phân tích yêu cầu phần mềm ở Fsoft
 Giai đoạn đầu tiên của Software Engineeing






Mục đích:
 Nhằm đảm bảo rằng các yêu cầu cho sản phẩm phần mềm được định nghĩa và
hiểu rõ ràng.
o Để biết yêu cầu của khách hàng là gì?
o Hiểu những gì khách hàng cần và mong đợi
 Để tạo SRS- Thiết lập và duy trì các yêu cầu thỏa thuận với những người yêu cầu
và các nhóm được tác động
 Để đảm bảo rằng các yêu cầu đã được tìm thấy
 Các yêu cầu được lập thành tài liệu và kiểm soát để thiết lập a bước cơ bản cho
phát triển phần mềm và sử dựng quản lý dự án.
Workflow:







Phát hiện và phân tích yêu cầu phần mềm
 Thỉnh thoảng được gọi là khám phá các yêu cầu
 Các yêu cầu không thường xuyên sẵn cho bạn,bạn phải phát hiện ra chúng.Phải
làm việc với khách hàng và các bên liên quan để phát hiện ra:
o Các dịch vụ mà hệ thống sẽ cung cấp
o Các ràng buộc mà hệ thống sẽ phải đáp ứng
 Phân tích yêu cầu hoàn thành để:
oPhát hiện và xử lý các xung đột giữa các yêu cầu
oKhám phát các giới hạn của phần mềm và làm thế nào nó tương tác với
môi trường của nó.
oXây dựng các yêu cầu hệ thống để lấy được các yêu cầu phần mềm.
Nguồn để phát hiện và phân tích yêu cầu phần mềm
 Tiềm năng các bên tham gia
 Người dùng cuối
 Các nhà quản lý
 Các chủ sở hữu
 Các khách hàng của khách hàng
 Kỹ sư sau này sẽ dùng phần cho khách hàng
 Các tổ chức công đoàn
Tiến trình để phát hiện và phân tích yêu cầu phần mềm







Các vấn đề trong phát hiện và phân tích yêu cầu phần mềm
 Các vấn đề về phạm vi
 Giới hạn của các hệ thống các rủi ro được phát hiện
 Các khách hàng/người dùng không cần thiết chi tiết kỹ thuật vì có thể
nhầm lẫn giữa mục tiêu của các hệ thống
 Các vấn đề về sự hiểu biết
 Các khách hàng/người dùng không hoàn toàn chắc chắn những gì cần
 Có một sự hiểu biết nghèo nàn về khả năng và giới hạn của môi trường
tính toán của họ.
 Không hiểu biết đầy đủ về vấn đề tên miền,có một số phiền toái cần giao
tiếp của kỹ sư hệ thống.
Các kỹ thuật để phát hiện và phân tích yêu cầu phần mềm
 Các kỹ thuật phát hiện
o Nghiên cứu tên miền ứng dụng
o Đưa ra câu hỏi và phỏng vấn
o Hội thảo và thảo luận
o Quan sát
o Use cases
 Các kỹ thuật phân tích
o Mô hình hóa hệ thống
o Tạo nhanh các mẫu
Các tài liệu yêu cầu-SRC
 Tài liệu yêu cầu phần mềm là tài liệu chính thức của những gì được yêu cau cho
hệ thống

 Thông thường chỉ bao gồm các yêu cầu hệ thống nhưng thỉnh thoảng có thể cũng
có các yêu cầu của người dùng












 Nó không phải là tài liệu thiết kế.Miêu tả hệ thống sẽ phải làm gì hơn là sẽ phải
làm như thế nào.
 URD-User Requirement Definition
 Địa chỉ những gì người dùng cần để làm cho công việc của họ
 Được sáng tác tất cả các yêu cầu công việc,các nguyên tắc công việc và
các ràng buộc khác.
 SRS-Software Requirement Specification
 Một tập hợp các yêu cầu phần mềm khi hoàn thiện,phù hợp và đúng
khi có thể,từ quan điểm của các nhà phát triển.
 Tài liệu sau khi cơ bản,phổ biến tham khảo cho khách hàng,nhà phát
triển,tester và PM(Project manager)
 Lợi ích của một tài liệu tốt
 Thỏa thuận cơ bản giữa các khách hàng và nhóm những gì sản phầm
phần mềm làm.
 Giảm các nỗ lực phát triển
 Cung cấp một ước tính giá,lịch trình cơ bản.

Các hoạt động và các bước
 Nghiên cứu URD
 Phân tích yêu cầu người dùng
 Chuẩn bị danh sách Q&A để lọc những yêu cầu không ro ràng với
khách hàng
 Gọi/Phỏng vấn khách hàng nếu cần
 SRS:
 Phát triển Use cases,yêu cầu hệ thống
 Phát triển đặc tả các chức năng
 Xem lại và phê duyệt SRS:
 Mời hội thảo để xem lại
 Ghi âm buổi hội thảo
Các kỹ thuật phát triển SRS
 Xác định rõ các yêu cầu sử dụng “structured natural language”
 Các yêu cầu chức năng có thể được xác định rõ sử dụng mô hình hóa-một tập
hợp các kí hiệu đồ họa và ngôn ngữ tự nhiên có cấu trúc
 Use cases
 Use case diagram
 Use case specification
 Các yêu cầu không chức năng không thể được mô hình hóa=>chỉ suer dugj
ngôn ngữ tự nhiên có cấu trúc
Phát triển SRS-SRS Review Checklist
 Để xem lại các yêu cầu của chính khách hàng
 Đảm bảo khách hàng hoàn toàn hiểu rõ các yêu cầu
 Template
Mục đích-Validate Requirements
 Chắc chắn rằng các yêu cầu miêu tả hệ thống mà khách hàng thực sự muốn
 Các lỗi về yêu cầu có giá rất cao,do đó validation là rất quan trọng
Quy trình-Validate Requirement







Các kỹ thuật-Validate Requirement
 Xem lại các yêu cầu
 Phân tích có hệ thống hướng dẫn của các yêu cầu
 Liên quan đến các nhân viên phát triển,khách hàng và các bên liên quan
 Nguyên mẫu
 Sử dụng một mô hình có thể thực hiện được của hệ thống để kiểm tra các
yêu cầu
 Model Validation
 Xác nhận chất lượng của các mô hình được phát triển trong khi phân tích
 Test-case generation
 Triển khai kiểm tra các yêu cầu để kiểm tra tính có thể kiểm tra
Quản lý các yêu cầu
 Requirement Management Sheet,Exel sheet,được xử dụng để theo dõi tình
trạng,quan hệ và những thay đổi trong toàn bộ dự án.
 Một tài liệu bắt buộc(dynamic version of SRS)
 Phân loại yêu cầu thành yêu cầu chức năng/yêu cầu không chức năng
 Để duy trì như một tài liệu chung cho các bên
 Để theo dõi tiến trình dự án(tình trạng của yêu cầu)
 Để theo dõi các thay đổi(bao gồm yêu cầu thay đổi)
 Để tập hợp các yêu cầu có số liệu liên quan cho việc báo cáo
 The sheet được tạo lần đầu tiên khi yêu cầu của khách hàng đến.
Theo dõi yêu cầu
Tại sao theo dõi là cần thiết?

 Các yêu cầu có thể thay đổi ở bất kỳ giai đoạn nào trong vòng đời của sản phẩm.
 Nếu các yêu cầu được theo dõi,sau đó khi các thay đổi xảy ra,nó dễ dàng tìm
thấy.




Quản lý các yêu cầu thay đổi
 Thay đổi các yêu cầu(CR-Change Request)
 Các yêu cầu ưu tiên từ các quan điểm khác nhau thay đổi trong quá trình
phát triển
 Các khách hàng có thể xác định rõ yêu cầu từ một quan điểm công việc vì
vậy xung đột với yêu cầu người dùng cuối
 Môi trường kỹ thuật và công việc của hệ thống thay đổi trong khi nó phát
triển.
 Quá trình thay đổi các yêu cầu



Phân loại yêu cầu
 PM/TL/BA đại diện đặc tả yêu cầu phần mềm cho các thành viên trong nhóm lam
việc
 Tự nghiên cứu tài liệu liên quan:cách tiếp cận top-down
 Sử dụng FSOFT’s SRS review checklist
 Phân loại các mục không rõ ràng,sử dụng Q&A
 Thảo luận với các thành viên khác
 Thông báo PM/TL/BA về
 Tất các các yêu cầu xung đột
 Các thay đổi,so sánh với phiên bản cuối cùng

6.Quy trình thiết kế ở Fsoft
Quy trình kỹ thuật ở Fsoft
6.1 Tổng quan


Mục đích:
 Khai thác các giải pháp yêu cầu
 Tạo kiến trúc thiết kế,cấp cao và tài liệu thiết kế chi tiết

6.2 Quy trình thiết kế
Phát triển thiết kế


AD/HLD, DD:Các bước và các hoạt động
o Xem lại và phê duyệt thiết kế ở mức cao:
 Chuẩn bị cho việc xem lại HLD,báo và gửi tài liệu,các bản ghi tới người
xem lại đó.
 Review:Phương pháp thiết kế,kiến trúc hệ thống,tính khả thi của quá
trình thiết kế chi tiết và coding
 Phê duyệt HLD
o Thiết kế chi tiết:
 Thiết kế màn hình,báo cáo,các giải thuật và các modul khác.
 Tại tài liệu thiết kế chi tiết
6.3 DesignWork flow
 Tổng quan




Bước 1-Lập kế hoạch

Mục đích:Nó để thành lập kế hoạch thiết kế
Trigger:Dự án được mở và quản lý dự án được bổ nhiệm
Đầu vào:
-Kế hoạch dự án
- Các yêu cầu của khách hàng
Các bước:
-Nghiên cứu yêu cầu thiết kế:các mẫu và mô tả;các chuẩn.các quy định,hướng dẫn,các
thiết kế tương tự và có thể sử dụng lại,các công cụ.
-Nghiên cứu các đầu vào(hiệu năng và các yêu cầu chức năng;các quy định và các yêu
cầu pháp lý; các yêu cầu khác),các quyết định yêu cầu chưa rõ ràng và chưa thống nhất
-Tạo kế hoạch thiết kế:Phạm vi và mục đích,các nhiệm vụ và kết quả,các gia đoạn và cột
mốc,lịch trình và nguồn lực,các giao diện,các tiêu chuẩn thiết kế và tiêu chí.
Đầu ra:
-Kế hoạch thiết kế được tạo và phê chuẩn:Quá trình thiết kế,nguồn lực cho thiết kế,các
tools được sử dụng,lịch trình.
-Các chuẩn,mẫu và checklist được sử dụng cho thiết kế đã được thành lập.




Bước 2-Develop High Level Design
Mục đích:
Để phát triển kiến trúc thiết kế
Trigger:
Kế hoạch cho thiết kế được phê duyệt
Đầu vào:
-Nghiên cứu các tài liệu phân tích công việc và đặc tả yêu cầu người dùng
-Định nghĩa các điểm chính của kiến trúc hệ thống như mô hình ky thuật,mô hình
hoạt động,mô hình cơ sở dữ liệu,mô hình cấu trúc chương trình,nguyên mẫu(nếu cần)
 Thiết kế dữ liệu

 Thiết kế các chương trình
 Thiết kế các giao diện
 Cài đặt các tool chi việc thiết kế
 Tạo tài liệu thiết kế kiến trúc
Đầu ra:
-Các mẫu yêu cầu phần mềm
-Mô hình phần mềm,nguyên mẫu(nếu có)
-Các kết quả thiết kế chương trình
-Các kết quả thiết kế giao diện
-Các kết quả cài đặt của các tool cho việc thiết kế
-Tài liệu thiết kế kiến trúc





Bước 3-Review,Appove High Level Design
Mục đích:
Để làm ro và xác nhận kiến trúc thiết kế
Trigger:
Kiến trúc thiết kế sẵn sàng để xem xét và phê duyệt
Đầu vào:
-Tài liệu thiết kế kiến trúc
-Chuẩn,các yêu cầu thiết kế
Các bước:
-Chuẩn bị cho high level design review,thông báo và gửi tài liệu,các bản ghi tới
người xem xét.
-Review high level design:Giải pháp thiết kế,các tool và các chuẩn,kiến trúc hệ
thống,tính khả thi của quá trình thiết kế chi tiết và coding
-Phê duyệt high level design và thay đổi yêu cầu(nếu cần)

Đầu ra:
-Design Checklist
-Review Report,yêu cầu thay đổi(nếu cần)
-Thiết kế kiến trúc được phê duyệt và các yêu cầu thay đổi của nó
Bước 4-Develop Detail Design
Mục đích:
Để phát triển thiết kế chi tiết