it4460-slide-chapter 1

1

IT4460 - PHN TCH YU CU PHN MM

Nm hc 2014-2015

Ging vin: PGS. TS.Hunh Quyt Thng

BM Cng ngh phn mm

Vin CNTT-TT, HBK HN

www.soict.hust.edu.vn/~thanghq

2

Chng 1. Tng quan v YCPM v quy trnh TKXDPM

I. Cc khi nim cn bn v nh ngha 1. Cc khi nim v nh ngha 2. Qu trnh pht trin ca phng php tip cn thit

k v xy dng phn mm 3. Phn loi phn mm theo ng dng 4. Quy trnh pht trin phn mm (SDLC) 5. Mt s lu lin quan n YCPM

II. Phn loi cc yu cu phn mm III. Cc thuc tnh cht lng ca yu cu phn mm IV. Quy trnh yu cu phn mm: m hnh, tc nhn, h tr

v qun l, kt qu V. Gii thiu mt s ti liu lin quan n ni dung chng

3

I. Cc khi nim cn bn v nh ngha

1) Cng ngh phn mm (Software Engineering)

2) Yu cu phn mm (Software requirements)

3) Thit k phn mm (Software design)

4) Xy dng phn mm (Software construction)

5) Kim th phn mm (Software testing)

6) Bo tr phn mm (Software maintenance)

7) Qun l cu hnh phn mm (Software configuration

management)

8) Qun tr cng ngh phn mm (Software engineering

management)

9) Qu trnh cng ngh phn mm (Software engineering process)

10) Cc cng c v phng php trong CNPM (Software

engineering tools and methods)

11) Cht lng phn mm (Software quality)

4


1) Cng ngh phn mm (Software Engineering)

Theo t chc IEEE trong IEEE Standard Glossary of Software

Engineering Terminology, IEEE, Piscataway, NJ std 610.12-

1990, 1990.

Cng ngh phn mm c nh ngha (nguyn vn):

(1) The application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance of

software; that is, the application of engineering to software.

T kha: h thng, khoa hc, nh lng, pht trin, s dng v

bo tr phn mm

(2) The study of approaches as in (1)

T kha: nghin cu cc hng tip cn

5


2) Yu cu phn mm (Software requirements)

A requirement is defined as a property that must be exhibited in

order to solve some real-world problem.

T kha: property (thuc tnh/yu cu)

3) Thit k phn mm (Software design) [IEEE610.12-90]:

Design is both the process of defining the architecture,

components, interfaces, and other characteristics of a system or

component and the result of [that] process.

T kha: process; kt qu ca process; kin trc; thnh phn; giao

din; cc thuc tnh ca h thng

4) Xy dng phn mm (Software construction)

Software construction refers to the detailed creation of working,

meaningful software through a combination of coding,

verification, unit testing, integration testing, and debugging.

6


5) Kim th phn mm (Software testing)

Software Testing consists of the dynamic verification of the

behavior of a program on a finite set of test cases, suitably

selected from the usually infinite executions domain, against

the expected behavior.

6) Bo tr phn mm (Software maintenance)

The maintenance phase of the lifecycle commences upon

delivery but maintenance activities occur much earlier. Once in

operation, anomalies are uncovered, operating environments

change, and new user requirements surface.

7



management)

Software Configuration Management (SCM) is the discipline

of identifying the configuration of software at distinct points in

time for the purpose of systematically controlling changes to

the configuration and of maintaining the integrity and

traceability of the configuration throughout the system life

cycle.

Management of the SCM process. It covers the topics of the

organizational context for SCM, constraints and guidance for

SCM, planning for SCM, the SCM plan itself, and surveillance

of SCM.

8



management)

Software configuration identification, which identifies items to

be controlled, establishes identification schemes for the items

and their versions, and establishes the tools and techniques to

be used in acquiring and managing controlled items. The first

topics in this sub-area are identification of the items to be

controlled and the software library.

Software configuration control, which is the management of

changes during the software life cycle. The topics are: first,

requesting, evaluating, and approving software changes;

second, implementing software changes; and third, deviations,

and waivers.

9



management)

software configuration status accounting. Its topics are

software configuration status information and software

configuration status reporting.

software configuration auditing. It consists of software

functional configuration auditing, software physical

configuration auditing, and in-process audits of a software

baseline.

software release management and delivery, covering software

building and software release management.

11



management)

The Software Engineering Management addresses the

management and measurement of software engineering. While

measurement is an important aspect, it is here that the topic of

measurement programs is presented. There are six sub-areas

for software engineering management. The first five cover

software project management and the sixth describes the

software measurement programs.

The first sub-area is initiation and scope definition, which

comprises determination and negotiation of requirements,

feasibility analysis, and process for the review and revision of

requirements.

12



management)

The second sub-area is software project planning, and includes

process planning, determining deliverables, effort, schedule

and cost estimation, resource allocation, risk management,

quality management, and plan management.

The third sub-area is software project enactment. The topics

here are implementation of plans, supplier contract

management, implementation of measurement process, monitor

process, control process, and reporting.

The fourth sub-area is review and evaluation, which includes

the topics of determining satisfaction of requirements and

reviewing and evaluating performance.

13



management)

The fifth sub-area describes closure: determining closure and

closure activities.

Finally, the sixth sub-area describes software engineering

measurement, more specifically, measurement programs.

The topics of this sub-area are: establish and sustain

measurement commitment, plan the measurement process,

perform the measurement process, and evaluate measurement.

14



The Software Engineering Process is concerned with the

definition, implementation, assessment, measurement,

management, change, and improvement of the software

engineering process itself. It is divided into four subareas.

The first sub-area presents process implementation and

change. The topics here are process infrastructure, the software

process management cycle, models for process implementation

and change, and practical considerations.

The second sub-area deals with process definition. It includes

the topics of software life cycle models, software life-cycle

processes, notations for process definitions, process adaptation,

and automation

15



The third sub-area is process assessment. The topics here

include process assessment models and process assessment

methods.

The fourth sub-area describes process and product

measurements. The software engineering process covers

general product measurement, as well as process measurement

in general. The topics are process measurement, software

product measurement, quality of measurement results, software

information models, and process measurement techniques.

16


10) Cc cng c v phng php trong CNPM Software

engineering tools and methods

The Software Engineering Tools and Methods includes both

software engineering tools and software engineering methods.

The software engineering tools sub-area uses the same

structure, with one topic for each of the other nine software

engineering topics. An additional topic is provided:

miscellaneous tools issues, such as tool integration techniques,

which are potentially applicable to all classes of tools.

The software engineering methods sub-area is divided into four

subsections: heuristic methods dealing with informal

approaches, formal methods dealing with mathematically based

approaches, and prototyping methods dealing with software

development approachesbased on various forms of prototyping.

17



The Software Quality deals with software quality

considerations which transcend the software life cycle

processes. Since software quality is a ubiquitous concern in

software engineering, it is also considered in many of the other

topics. The description of this topic covers three sub-areas.

The first sub-area describes the software quality fundamentals

such as software engineering culture and ethics, the value and

costs of quality, models and quality characteristics, and quality

improvement.

18



The second sub-area covers software quality management

processes. The topics here are software quality assurance,

verification and validation, and reviews and audits.

The third and final sub-area describes practical considerations

related to software quality. The topics are software quality

requirements, defect characterization, software quality

management techniques, and software quality measurement.

19


I. Cc khi nim cn bn v nh ngha 1. Cc nh ngha 2. Qu trnh pht trin ca phng php tip cn thit




20

I. 2. Phng php tip cn PTTK phn mm

Hng tip cn: Process-Oriented Tp trung vo cc gii thut v thao tc x l d liu Qu trnh pht trin phn mm tp trung vo th hin cc

phng php x l d liu

Cu trc d liu thng thng khng th hin r Nhc im ca hng tip cn: Cc tp d liu rt kh xy

dng tho mn phn mm

21

I. 2. Phng php tip cn PTTK phn mm

Hng tip cn: Data-Oriented Approach M t t chc ca d liu, m t d liu ly u v s

dng nh th no

M hnh d liu c thnh lp v c m t mi quan h gia cc d liu tng ng ny v cc quy nh v mi quan

h

S dng cc Business rules ch ra phng php x l d liu

22

I.2. Phng php tip cn PTTK phn mm

Hng tip cn: Architecture-Oriented Approach La chn kin trc v cng ngh phn mm thc hin bi

ton

p dng cc phng php Prototyping nhanh chng xy dng c phn mm

S dng cc Pattern kin trc mu ch ra phng php x l d liu

23






24

3. Phn loi phn mm theo ng dng

Phn mm h thng (system)

Phn mm thi gian thc (real-time)

Phn mm qun l (business)

Phn mm cng ngh v khoa hc (engineering and

scientific)

Phn mm nhng (embedded)

Phn mm tr tu nhn to (AI)

Ngun ti liu: [1] Hoffer J. A. Modern System

Analysis and Design. Third Edition. Addison-

Wesley, 2004

25






26

4. Quy trnh pht trin phn mm (SDLC)

M hnh thc nc (Waterfall model) Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

27


M hnh thc nc (1) Phn tch yu cu phn mm v c t / Requirements

analysis and definition

(2) Thit k h thng v thit k phn mm/System and

software design

(3) Thc thi vit m ngun v kim th khi/ Implementation

and unit testing

(4) Tch hp v kim th h thng/Integration and system

testing

(5) S dng v bo tr phn mm / Operation and maintenance

c im: Quay li t cc giai on sau tr v cc giai on

trc chnh sa kt qu thc thi l khng hiu qu.

28


Cc c im ca m hnh thc nc Inflexible partitioning of the project into distinct

stages

This makes it difficult to respond to changing customer requirements

Therefore, this model is only appropriate when the requirements are well-understood

29


ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outline

description

Concurrent

activities

Evolutionary development

30


Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Reuse-oriented development

31

Spiral model of the software process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


Iterative Model

According to Leffingwell

Four phases, Inception, Elaboration, Construction, Transition

Multiple iterations in each phase Each iteration is a sequence of activities with

a plan and evaluation criteria, resulting in an

execution of some type

Each iteration builds on the functionality of the prior iteration

Iterative Lifecycle Phases

Inception Define the scope and business case of the project

Elaboration Refine the requirements, baseline architecture, build feasibility prototype

Construction Build the product

Transition Move the product into end-user community

Iterations and Phases

An iteration is a distinct sequence of

activities based on an established plan

and evaluation criteria, resulting in an

executable release (internal or external)

Risk Profiles

RUPs Iterative Approach

Proposal

Submitted SRR, PDR, CDR

Completed

Beta

Release

Operational

Release

V1.0

Mapping for a large development effort and the major milestones

38





v qun l, kt qu V.Cu hi v bi tp VI. Gii thiu mt s ti liu lin quan n ni dung chng VII. Ni dung c trc cho tun sau

39

5. Mt s ni dung cn lu lin quan n YCPM

IEEE 1997 nh ngha yu cu phn mm:

(1) iu kin hay kh nng cn thit ngi s dng gii quyt c vn hoc mc tiu hay tng ca h

(2) iu kin hay kh nng c hiu l p ng ca h thng hay thnh phn h thng tho mn hp ng, tiu chun, c t hoc cc vn bn bt buc khc.

(3) Vn bn th hin cc iu kin hoc kh nng th hin (1) v (2).

40


Tnh cht hai pha ca Yu cu phn mm v nhu cu xc nh im cn bng

Trn thc t y mt trong nhng vn ca cng nghip phn mm: thiu s nh ngha chnh xc v yu cu phn mm.

Cc yu cu xut pht t ngi s dng chng trnh i vi ngi pht trin phn mm thng thng qu l tru tng, mc cao.

Ngc li nhng m t t pha nhng ngi pht trin i vi ngi s dng li mc qu thp, qu chi tit v ngi s dng li khng hiu ht c.

41


Tnh cht hai mt ca yu cu phn mm: cch nhn v suy ngh v phn mm t pha ngi s dng v cch nhn v suy ngh v phn mm t pha ngi pht trin.

Mt trong nhng iu kin quan trong nht ch ra trong nh ngha ny l tnh c t ca n: phi c c kt li bng vn bn.

C s tham gia v xc nhn ca c hai pha: ngi s dng va ngi pht trin

Qu trnh pht trin v cch hiu ca yu cu phn mm s cho thy tnh y ca nh ngha tho IEEE.

42


Cc nh ngha khc v yu cu phn mm:

Alan Davis (1993): cc nhu cu ca ngi s dng (cc c tnh, chc nng v c im) ca h thng cn phi th hin t cc quan st bn ngoi vo h thng.

Jones (1994): Cc yu cu v pht biu ca ngi s dng khi s qu trnh pht trin phn mm.

Sommervile v Sawyer (1997): Yu cu ca ngi s dng l cc c t m t cn phi lm ci g. Cc c t ny gii thch cc thuc tnh cc c trng ca h thng v cc hot ng chc nng ca h thng.

43






44

Y/c cng vic

Cc yu cu khc

Cc c trng

Yu cu h

thng Y/C

chc

nng

Cc rng buc

Y/c NSD

Ti liu v kh nng, phm vi v gii hn ca phn mm

Ti liu v cc use case hoc kch bn

miu t

Ti liu c t yu cu phn mm (Software Requirement

Specification)

45

II. Phn loi yu cu phn mm

Cc mc (level) ca yu cu Mc 1: Yu cu cng vic (Business

Requirement): th hin cc mc tiu yu cu mc cao ca t chc hay khch hng v kh nng, phm vi ng dng v gii hn ca phn mm

Mc 2: Yu cu ngi s dng (user requirement): th hin cc nhim v c th m NSD cn phi hon thnh, lm c vi phn mm. Thng thng c miu t bng cc trng hp s dng (user case) hoc cc kch bn miu t (scenario description).

46


Cc mc (level) ca yu cu Mc 3: Yu cu chc nng (Functional

Requirement): nh ngha cc chc nng phn mm m ngi pht trin cn phi xy dng c th p ng c tt c cc nhim v miu t trong yu cu ngi s dng mc trn.

Cc yu cu chc nng c vn bn ha bng mt ti liu: Ti liu c t yu cu phn mm (Software Requirement Specification)

47


Cc ti liu trong yu cu phn mm Mc 1: Ti liu v kh nng, phm vi v gii hn

ca phn mm Mc 2: Ti liu v cc use case hoc kch bn

miu t Mc 3: Ti liu c t yu cu phn mm

(Software Requirement Specification): ti liu c t m t y cc hot ng, chc nng cn phi c ca phn mm. i vi cc h thng phn mm ln y c coi l mt thnh phn ca h thng s chuyn giao cho khch hng

48


Cc im lu trong phn loi yu cu phn

mm Cc yu cu khc: (nonfunctional requirement): thng

thng cha cc chun, cc iu chnh, cc iu kin m phn mm cn phi c

Cc rng buc: (constraint): cc quy nh cht ch m cc phn tch vin v pht trin h thng cn phi tun th v gi vng trong qu trnh ph trin phn mm

Cc c tnh cht lng (quality attributes): cc c im xc nh tnh cht v cht lng ca phn mm. Lu cn nn r phng php o v c s thng nht gia NSD v cc PTV v cc c tnh cht lng ny

49






50

III. Cc thuc tnh cht lng ca yu cu phn mm

Cc c im ca tng yu cu phn mm: (1) Hon thin (complete) (2) Chnh xc (correct) (3) Kh thi (feasible) (4) Cn thit (necessary) (5) c sp xp theo th t u tin cc yu

cu. (6) R rng (7) Kim tra c, xc minh c

51

III. Cc thuc tnh cht lng ca yu cu phn mm

Cc c im ca ti liu c t yu cu phn mm: (1) Hon thin (complete) (2) Ph hp (consistent) (3) Sa i c (modifiable) (4) Theo di c (traceable)

52






53

IV. Quy trnh yu cu phn mm: m hnh, tc nhn, h

tr v qun l, kt qu

Requirement

Engineering

Requirement

Development

Requirement

Management

Requirement

Verification

Requirement

Specification

Requirement

Analysis

Requirement

Elicitation

54


tr v qun l, kt qu

Requirement Development: (Pht trin cc yu cu phn mm Pht hin cc yu cu (Requirement Elicitation) Phn tch cc yu cu (Requirement Analysis) c t cc yu cu (Requirement Specification) Kim th cc yu cu (Requirement

Verification)

55


tr v qun l, kt qu

Requirement Management: Qun l cc yu cu phn mm thc hin cc giao tip v tho thun vi NSD v cc yu cu ca phn mm cn thc hin (CMU/SEI 1995) Xc nh gii hn ca phn mm (Requirement

baseline)

Duyt li cc gii hn ca phn mm Qun l cc thay i trong yu cu phn mm

(Requirement Changes)

56

Analyze

Document

Review, Negotiate

Requirement

Change Process

Base Line Requirement Requirement

Management

Marketing

Customer

Management

Requirement

Development

Marketing

Customer

Management

Marketing Customer Management

Requirement

Requirement

changes

Project

changes

57

V. Gii thiu mt s ti liu lin quan n ni dung chng

1. Hoffer J. A. Modern System Analysis and Design.

Third Edition. Addison-Wesley, 2004

2. Sommerville, I.: Software Engineering, 7th ed.

Reading, Massachusetts: Addison-Wesley, 2005.

3. Guide to the Software Engineering Body of

Knowledge 2004 Version. SWEBOK. IEEE project.

4. a ch trang Web: http://www.segvn.org/forum

it4460-slide-chapter 1

Documents