Báo Cáo Thực Tập Công Ty Thực Tập Fpt Software.pdf

ĐẠI HỌC QUỐC GIA HÀ NỘITRƯỜNG ĐẠI HỌC CÔNG NGHỆ

-BÁO CÁO THỰC TẬP NGÀNH: CÔNG NGHỆ THÔNG TIN

Công ty thực tập: FPT Software

Giảng viên đánh giá: Lê Thanh HàSinh viên: Trần Văn Công

Mã sinh viên: 18020244Lớp: K63-CE

Hà Nội, tháng 9 năm 2021

MỤC LỤC

I Những điều thu hoạch được từ tìm hiểu thực tế ở cơ sở thực tập 4

1 Tổng quan về công ty 4

2.Văn hóa FPT 5

3 Cách làm việc trong một dự án ở Fsoft 6

3.1 Các hoạt động trong dự án phần mềm 6

3.2 Vòng đời của một dự án phần mềm 7

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

4 Bảo mật thông tin ở Fsoft 8

5 Quy trình phân tích yêu cầu phần mềm ở Fsoft 9

6 Quy trình thiết kế ở Fsoft 14

6.1 Tổng quan 14

6.2 Quy trình thiết kế 15

6.3 DesignWork flow 15

6.4 Fsoft Design Documents 18

II Tổng hợp quá trình học tập và công việc trong kì thực tập 19

III Những kiến thức, kỹ năng học tập, vận dụng để hoàn thành nhiệm vụ 22

IV Những kiến thức và kỹ năng cần bổ sung,cần học hỏi thêm để đáp ứng được nhu cầu thực tế 26

Hình 5: Bảo mật thông tin theo ISO27001 11

Hình 6: Giai đoạn đầu tiên của Software Engineering 16

Hình 7: Workflow 17

Hình 8: Tiến trình phát hiện, phân tích yêu cầu phần mềm 18

Hình 9: Quy trình Validate Requirement 20

Hình 10: Theo dõi yêu cầu 21

Hình 11: Quá trình thay đổi các yêu cầu 21

Hình 12: Phân loại yêu cầu 22

Hình 13: Tổng quan quy trình thiết kế 22

Hình 14: DesignWorkflow 23

LỜI CẢM ƠN

Thời gian thực tập tuy ngắn nhưng thực sự em đã học được những kinh nghiệm rất quý báu về kiến thức chuyên ngành, tinh thần đoàn kết, làm việc nhóm và kỹ năng giao tiếp để làm hành trang cho công việc sau này.

Em xin cảm ơn tới cán bộ lãnh đạo, quản lý của công ty FPT Software (FSoft) đã tạo điều kiện tốt nhất cho em được trải nghiệm, làm việc trong môi trường chuyên nghiệp, được tiếp cận tới những công nghệ hiện đại Em rất vinh dự nếu sau khi ra trường được làm việc tại công ty, em sẽ cố gắng hết sức để được gặp các anh chị trong cương vị một người đồng nghiệp.

Em cũng xin cảm ơn Trường Đại học Công Nghệ đã tìm hiểu và tạo điều kiện cho em có được nơi thực tập, đồng thời cảm ơn giảng viên hướng dẫn của thầy PGS TS Lê Thanh Hà đã tận tình giúp đỡ, động viên, giám sát em trong quá trình thực tập này.

Trong báo cáo không tránh khỏi những sai sót, em kính mong nhận được những góp ý quý báu của thầy cô và anh chị để hoàn thiện hơn.

Em xin chân thành cảm ơn.

NHỮNG THU HOẠCH TỪ TÌM HIỂU THỰC TẾ VÀ THỰC TẬPI 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: 18,000(năm 2020)

Doanh thu: 513,6 triệu dollars(năm 2020) Ngày thành lập: Ngày 13 tháng 1 năm 1999 Chủ tịch: Chu Thị Thanh Hà

Giám đốc: Phạm Minh Tuấn Website: www.fpt-software.com

Cấu trúc tổ chức

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 Chất lượng tuyệt hảo Thông tin thông suốt STC phong phú

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.

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 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ố ý.

Hình 5: Bảo mật thông tin theo ISO27001

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

Hình 6: Giai đoạn đầu tiên của Software EngineeringMụ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.

Hình 7: WorkflowPhá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

Tiến trình để phát hiện và phân tích yêu cầu phần mềm

Hình 8: Tiến trình phát hiện, phân tích yêu cầu phần mềmCá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 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

Hình 9: 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.

Hình 10: Theo dõi yêu cầu

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

Hình 11: 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

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

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

Hình 12: Tổng quan quy trình thiết kế

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

-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ế

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

-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

-SRS, URD,và các yêu cầu của khách hàng -Tài liệu thiết kế kiến trúc

-Kế hoạch thiết kế

Các bước:

-Thiết kế màn hình

-Thiết kế các báo cáo -Thiết kế các giải thuật -Thiết kế chi tiết -Mẫu thiết kế(tùy ý)

Các bước:

-Tổng quát hóa các kết quả thiết kế,xem lại các chú ý và định nghiiax thêm công việc.

-Xem xét và phê duyệt các sản phẩm thiết kế trước khi cung cấp cho

-Các sản phầm thiết kế được cung cấp -Báo cáo 2 tóm tắt thiết kế

6.4.Fsoft Design Documents

High-level design

Một High-Level Design cung cấp một cái nhìn tổng quan của một giải pháp,nền tảng,hệ thống,sản phẩm,dịch vụ,hoặc tiến trình.

Như một tổng quan quan trọng trong một multi-project phát triển để đảm bảo rằng mỗi hỗ trợ thiết kế thành phần sẽ tương thích với các thiết kế gần với nó.

Highest level solution design sẽ miêu tả tóm tắt tất cả các platform,hệ thống,các sản

phẩm,các dịch vụ và các tiến trình mànó phụ thuộc và bao gồm mọi thay đổi quan trọng rằng cần để tạo ra chúng.

Một high-level design document sẽ thương bao gồm một biểu đồ kiến trúc high-level để mô tả các thành phần,các giao diện và các network rằng cần để xác định thêm hoặc để phát triển.

Detailted Design

Tài liệu thiết kế chi tiết bao gồm các tài liệu dưới đây: 1.Tài liệu thiết kế màn hình

Chúng ta phải định nghĩa các item dưới đây: Màn hình tiếp theo

Danh sách các thành phần của màn hình Anh màn hình

2.Tài liệu thiết kế dữ liệu

Chúng ta phải định nghĩa các item dưới đây: 3.Tài liệu thiết kế Class

Chúng ta phải định nghĩa các item dưới đây: Khai báo gói chung Xử lý các lỗi và ngoại lệ Gỡ lỗi,theo dõi,log Cơ chế tối ưu hóa hiệu năng Giao diện bên ngoài Khai báo các phương thứ

II Tổng hợp quá trình học tập và công việc trong kì thực tập

Từ ngày 7/7/2021 - 10/7/2021: Thực hiện khóa học dayone của FSoft nhằm nắm bắt được các quy định về bảo mật, an ninh của công ty.

Ngày 11/7/2021: Được training trực tiếp với các anh, chị senior ở công ty: Làm quen các anh, chị đồng nghiệp, được giới thiệu và hướng dẫn cách thực hiện, mục tiêu và thời gian của khóa thực tập.

Quá trình thực tập và làm mock project:Tuần 1 (12/7 - 18/7): GIT

Kiến thức được training: Git basic

Học cách sử dụng git và git tools trong dự án thực tế Git flow và best practice

Kết quả đạt được:

Biết cách sử dụng git và git tools để quản lí mã nguồn Biết cách sử dụng git trong dự án thực tế.

Tuần 2 (19/7 - 25/7): KOTLIN

Kiến thức được training:

Overview về ngôn ngữ Kotlin Basic syntax, control flow, Lambda,

Kotlin OOP (class and interface, extension, data class, …)