1 2

References
[1] ISO/IEC FDIS 12207, Systems and software
engineering — Software life cycle processes.
ITSS SOFTWARE DEVELOPMENT
1. SOFTWARE DEVELOPMENT PROCESS

1 2

3 4

Content Content
1. Software Life Cycle Process 1. Software Life Cycle Process
2. Software Implementation Process 2. Software Implementation Process
3. Object-Oriented Analysis and Design 3. Object-Oriented Analysis and Design
4. Software Development Models 4. Software Development Models

3 4

1
 5 6

1. Software Life Cycle Process What are International Standards?

• “ISO/IEC 12207:2008, Systems and software engineering — Software ◆In ISO, all industry standards, including Information
life cycle processes” Technology, are developed.
• The latest and International Standard Software Development Process
◆In the field of Information Technology, in ISO/IEC JTC1,
• “The life cycle begins with an idea or a need that can be satisfied
wholly or partly by software and ends with the retirement of the international standards are developed.
software.” ◆ISO/IEC JTC1 has 32 principal member bodies which
• Standard implementation works PROCESS develop the international standards, and 44 observer
• hierarchically as processes member bodies.
ACTIVITY 1 … ACTIVITY N ◆Some abbreviation
• ISO: International Organization for Standard
• IEC: International Electrotechnical Commission
TASK 1.1 … TASK N.1
• JTC1: Joint Technical Committee

TASK 1.N TASK N.N

5 6

7 8

Why International Standards? Software Life Cycle Process

• “This International Standard groups the activities that may
◆Standards are important, especially in ICT be performed during the life cycle of a software system into
• Basis of common understanding such as frameworks, seven process groups”[1]*:
and terminology / definitions 1. Agreement Processes: 2 processes
• TBT Agreement of WTO recommends the use of ISO 2. Organizational Project-Enabling Processes: 5 processes
Standards for governmental purchase in affiliate 3. Project Processes: 7 processes
countries 4. Technical Processes: 11 processes
5. Software Implementation Processes: 6 processes
• Based on some standards, the certifications can be got,
• Purpose: “to produce a specified system element implemented
and they make some appeal points in international as a software product or service” [1]**.
transaction 6. Software Support Processes: 8 processes
7. Software Reuse Processes: 3 processes
WTO: World Trade Organization
TBT Agreement: Agreement on Technical Barriers to Trade

[1]*: clause 5.2.1; pp. 13, [1]**: clause 7.1.1.1; pp. 57,

7 8

2
 9 10

2. Software Implementation Process

Content
System Requirements Analysis Process and System
1. Software Life Cycle Process Architectural Design Process are achieved just before
Software Implementation Process .
2. Software Implementation Process
3. Object-Oriented Analysis and Design Software Implementation Process includes the following
lower-level processes:
4. Software Development Models 1. Software Requirements Analysis Process
2. Software Architecture Design Process
3. Software Detailed Design Process
4. Software Construction Process
5. Software Integration Process
6. Software Qualification Testing Process

9 10

11 12

2.1. Software Requirements Analysis process 2.2. Software Architectural Design process
• Purpose: “to establish the requirements of the software • Purpose: “to provide a design for the software that
elements of the system” [1] implements and can be verified against the requirements”
• Main items written on the brief requirement description [1]
• System environmental conditions under which the software is to • Software architecture is designed from the software
perform. requirements
• The functional requirements and the interface requirements.
• Main items
• Data definition and database requirements.
• a top-level structure of the software and the software components
• Some non-functional requirement items such as reliability, which constructs the software
usability, time efficiency
• a top-level design for the interfaces external to the software and
• Qualification requirements: The requirements are used as criteria between the software components
or conditions to qualify a software product as complying with its
• a top-level design for the database
specifications.

[1]: Session 7.1.2.1; pp. 59 [1]: Session 7.1.3.1; pp. 61

11 12

3
 13 14

2.3. Software Detailed Design process 2.4. Software Construction process

• Purpose: “to provide a design for the software that • Purpose: “to produce executable software units that
implements and can be verified against the requirements properly reflect the software design” [1]
and the software architecture and is sufficiently detailed to • Main items to be developed:
permit coding and testing” [1] • Each software unit and database
• A detailed design for each software components are • Test procedure and test data for software unit and database
developed. In the detailed design, the following items are • Unit tests and database test
developed: • The implementer shall evaluate software code and test
• each component is refined into software units that can be coded, results considering internal external consistency, test
compiled, and tested coverage of units and, traceability to the requirements and
• the interfaces external to the software item, between the
design of the software.
software components, and between the software units

[1]: Session 7.1.4.1; pp. 62 [1]: Session 7.1.5.1; pp. 63

13 14

15 16

2.5. Software Integration process 2.6. Software Qualification Testing Process

• Purpose: “to combine the software units and software • Purpose: “to confirm that the integrated software product
components, producing integrated software items, meets its defined requirements” [1].
consistent with the software design, that demonstrate that • Qualification testing in accordance with the qualification
the functional and non-functional software requirements requirements for the software item is conducted
are satisfied on an equivalent or complete operational • Tests, test cases, and test procedures
platform” [1]
• The implementer supports audit(s) to conform the
• Main tasks
software meets to the qualification requirements
• An integration plan, including test requirements, test procedure,
• If it is successful completion of the audits, the implementer prepare
and test cases/data.
the deliverable software product for System Construction process
• Integration of software units/components
• Program/software/integration test

[1]: Session 7.1.6.1; pp. 64 [1]: Session 7.1.7.1; pp. 66

15 16

4
 17 18

Summary Learning points

• “Software Life Cycle Process – SLCP” is the “The customer’s business success depends on the system
international standard processes focused on the development success.”
development and support of Application Software.
BA Software is one of the major components of the BA
• SLCP can be used as a common language among the System.
stakeholders such as acquirers and suppliers. They can
communicate or order the software development using What are the main factors for the system development success?
SLCP. For example, we can say “To order the software 1. The Software to be developed meets to functional
detailed design process or later software requirements → ?
implementation processes of new library system”. 2. To keep appointed date of delivery → ?
3. Meets the required quality such as Reliability, Usability,
Performance, Maintainability → ?
4. Necessary to provide maintenance activity during the system
operation period → ?

17 18

19

Content 2.1. Modeling

1. Software Life Cycle Process • A model is a simplification of reality.

2. Software Implementation Process

3. Object-Oriented Analysis and Design
4. Software Development Models

19 20

5
 Why Model? The Importance of Modeling
Less Important More Important
• Modeling achieves four aims [1]:
• Helps you to “visualize a system as you want it to be”.
• Permits you to “specify the structure or behavior of a system”.
• Gives you “a template that guides you in constructing a system”.
• “Documents the decisions you have made”.
• You build models of complex systems because you
cannot comprehend such a system in its entirety.
• You build models to better understand the system you are
developing.
Paper Airplane Fighter Jet

[1]: Chapter 1, Section 1.1

21 22

2.2. Unified Modeling Language (UML) The UML Is a Language for Visualizing
• “The UML is a language for • Communicating conceptual models
• Visualizing to others is prone to error unless
• Specifying everyone involved speaks the same
• Constructing language.
• Documenting • There are things about a software
the artifacts of a software-intensive system” [1]. system you can’t understand unless
you build models.
• An explicit model facilitates
communication.

[1]: Chapter 2, Section 2.1

23 24

6
 The UML Is a Language for Specifying The UML Is a Language for Constructing
• UML models can be directly connected to a variety of
• The UML builds models that are precise, unambiguous,
programming languages.
and complete.
• Maps to Java, C++, Visual Basic, and so on
• Tables in a RDBMS or persistent store in an OODBMS
• Permits forward engineering
• Permits reverse engineering

25 26

The UML Is a Language for Documenting

History of the UML
UML 2.0
• The UML addresses documentation of system (2004)

architecture, requirements, tests, project UML 1.5

(March, ‘03)
planning, and release management
Use Case Diagram Deployment Diagram UML UML 1.1
ºÐ» ê ȯ °æÀÇ Çϵå¿þ ¾î¹× ³×Æ ®¿÷À¸·ÎÀÇ Á¤ º¸ ½Ã½ºÅÛ ¿¬ °á ¸ð µ¨
Partners’ (Sept. ‘97)
- À©µµ¿ì 9 5 : Ŭ ¶ó À̾ð Æ ®
- À©µµ¿ì NT: ÀÀ¿ë¼¹ö

- À¯ ´ нº ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ ÀÌŸ ¼¹ö , Åë½Å ¼¹ö

Expertise
- IBM ¸Þ ÀÎÇÁ·¹ÀÓ: µ¥ ÀÌŸ ¼¹ö , Åë½Å ¼¹ö

Win d o w9 5
Win d o ws9 5
UML 1.0
(Jan. ‘97)
Win d o ws9 5

Use Case 1

¹®¼°ü ¸®
Ŭ ¶ó À̾ð Æ ®.EXE
¹®¼°ü ¸® ¾ÖÇø´

Win d o ws
NT

Actor A Actor B S o laris

Use Case 2
¹®¼°ü ¸® ¿£ Áø .EXE

Alp h a
UNIX
UML 0.9 and UML 0.91
(June ‘96) (Oct. ‘96)
ÀÀ¿ë¼¹ö .EXE

Win d o ws

NT

IBM

M ain frame

Use Case 3

µ¥ ÀÌŸº£ À̽º¼¹ö

Unified Method 0.8

mainWnd fileMgr : document : gFile repository
F ileM g r
Do cu men tList

Do cu men t
(OOPSLA ’95)
FileMgr Document
user
ad d ( )
n ame : in t

fetch Do c( ) d elete( )
d o cid : in t
so rtBy Name( )
n u mF ield : in t

1 : Do c v iew req u est ( ) g et( )

Æ ¯ Á¤ ¹®¼¿¡ ´ ëÇÑ º¸±â¸¦
» ç¿ëÀÚ°¡ ¿äû ÇÑ´ Ù. read () fill th e
o p en ( )

co d e..
clo se( )

Booch ’93
2 : fetch Do c( ) read ( )
F ileList

OMT - 2
so rtF ileList( )

fList

Booch91 (Grady Booch):

create( )
3 : create ( )

fillDo cu men t( )

ad d ( )

Sequence Diagram
d elete( )

1
4 : create ( )

5 : read Do c ( )

Class Diagram
Conception, Architecture
Other
ÈÀÏ°ü ¸®ÀÚ´  Àоî¿Â 6 : fillDo cu men t ( )
¹®¼ÀÇ Á¤ º¸¸¦ ÇØ´ ç ¹®¼
°´ ü¿¡ ¼³Á¤ À» ¿äû ÇÑ´ Ù.

rep

7 : read F ile ( )

Rep o sito ry
F ile

Methods OOSE (Ivar Jacobson): Use cases

Booch ‘91
8 : fillF ile ( )

OOSE OMT - 1
(fro m P ersisten ce)
read ( ) Grp F ile

È¸é °´ ü´  ÀоîµéÀÎ n ame : ch ar * = 0

OMT (Jim Rumbaugh): Analysis

9 : so rtBy Name ( )
°´ üµé¿¡ ´ ëÇØ À̸§º°·Î

Á¤ ·ÄÀ» ½ÃÄÑ È¸é¿¡

read ( )
º¸¿©ÁØ´ Ù. read Do c( )
o p en ( )
read F ile( )
create( )

fillF ile( )

27 28

7
 30

Inputs to the UML UML Views

Rumbaugh Booch Jacobson • “A view is simply a subset of UML modeling constructs
Meyer Fusion
that represents one aspect of a system” [2]
Before and after Operation descriptions, • Four areas
conditions message numbering
• structural classification,
Harel Embley • dynamic behavior
State charts Singleton classes, • physical layout,
High-level view
• and model management.
Gamma, et.al Wirfs-Brock
Frameworks, patterns, Responsibilities
notes

Shlaer- Mellor Selic, Gullekson, Ward Odell

Object lifecycles ROOM (Real-Time Classification
Object-Oriented Modeling)
[2]: Part 2, Chapter 3, Section 3.1

29 30

31 32

UML Views [2]

Static View vs Dynamic View
Major area View Diagram
Static view Class diagram Role of component parts and How the components interact
Design view Internal structure, how they are related to one with one another and/or change
Structural Collaboration diagram
Component diagram another state internally over time
Use case view Use case diagram
State machine view State machine diagram
Activity view Activity diagram
Dynamic
Interaction View Sequence Diagram
Communication Diagram
Physical Deployment View Deployment Diagram
Model Management Package diagram
Model View
Management
Profile Package Diagram

[2]: Part 2, Chapter 3, Section 3.1, Table 3.1 (extracted)

31 32

8
 33 34

2.3. Analysis and Design Object-Oriented Analysis and Design

The purposes of Analysis and Design are to:

• Transform the requirements into a
design of the system-to-be. Design Model
• Evolve a robust architecture for the
Use-Case Model Analysis and
system.
Design
• Adapt the design to match the
implementation environment, designing
it for performance.

Architecture
Document
Glossary
Supplementary
Specification

Data Model

33 34

35 36

Analysis and Design Are Not Top-Down or Bottom-Up Analysis and Design Steps
Analysis and Design
Activity Step Description Doer
Define a candidate • Once at early Elaboration
1. Architectural Analysis • Skip if architectural risk is low
Architect
architecture
Top
Analyze behavior 2. Use case Analysis • Per Use case Designer
Down Subsystems
3. Identify Design • Coupling and cohesion
Elements • Reusability

Refine the 4. Identify Design

• Design patterns Architect
architecture Mechanisms
5. Describe Run-time • Skip if not multi-threading
Use Cases Analysis Classes
(Define a Architecture • Process View
Bottom middle level) 6. Describe Distribution • Physical Architecture
Up 7. Use case Design • Per Use case
Design
8. Subsystem Design
components Designer
Design Classes 9. Class Design
Design DB 10. Database Design

35 36

9
 37 38

Content Homework
1. Software Life Cycle Process • Compare some common software development
2. Software Implementation Process models
• Waterfall model
3. Object-Oriented Analysis and Design
• Iterative model
4. Software Development Models
• Prototype model
• Spiral model
• Ration Unified Process (RUP)
• Agile methodology
➔ Submit report individually

37 38

39 40

The Waterfall/Linear Model Iterative Waterfall/Linear Model

Requirement Requirement
Analysis and
Linear, No feedback Analysis and
Definition Definition

System and System and

software design software design

Implementation Implementation
and unit testing and unit testing

Integration and Integration and

system testing system testing

Installation Installation

Operation and Operation and

maintenance maintenance

39 40

10
 41 42

Iterative Model Prototype model

• Each iteration produces an executable

3. Requirements
4. Analysis & Design
2. Planning
1. Initial
Management 5. Implementation
Planning
Environment
(on-going)
6. Test
8. Evaluation

7. Deployment
Each iteration
results in an
executable release

41 42

43 44

Spiral model Agile methodology

• “Agility is the ability to both create and respond to change
in order to profit in a turbulent buisness environment.”
• [Jim Highsmith, Agile Software Development Ecosystems, Preface XXIII]

=> Goal: Outline values and principles to allow software

teams to:
• develop quickly and
• respond to change.

43 44

11
 45 46

The Agile manifesto The Agile principles (1)

• Individuals and interactions over processes • 1. Our highest priority is to satisfy the
and tools customer through early and continuous
delivery of valuable software.
• Working software over comprehensive
• 2. Welcome changing requirements, even
documentation
late in the development. Agile processes
• Customer collaboration over contract harness change for the customer’s
negotiation competitive advantage.
• Responding to change over following a • 3. Deliver working software frequently, from
plan a couple of weeks to a couple of months,
with a preference to a shorter time scale.

45 46

47 48

The Agile principles (2) The Agile principles (3)

• 4. Business people and developers must work • 7. Working software is the primary measure of
together daily throughout the project. progress.
• 5. Build projects around motivated individuals. • 8. Agile processes promote sustainable
Give them the environment and support their development.
need, and trust them to get the job done. • 9. The sponsors, developers, and users should
• 6. The most efficient and effective method of be able to maintain a constant pace indefinitely.
conveying information to and within a • 10. Continuous attention to technical excellence
development team is face-to-face conversation. and good design enhances agility.

47 48

12
 49

The Agile principles (4)

• 11. Simplicity – the art of maximizing the
amount of work not done – is essential.
• 12. The best architectures, requirements,
and designs emerge from self-organising
teams.
• 13. At regular intervals, the team reflects on
how to become more effective, then tunes
and adjusts its behaviour accordingly.

49

13