Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
9 views39 pages

SoftwareTesting 02 ENG

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views39 pages

SoftwareTesting 02 ENG

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 39

ソフトウェアテスト

[2] ソフトウェア工学の概要
Software Testing
[2] Overview of Software Engineering

あまん ひろひさ
阿萬 裕久( AMAN
Hirohisa )
[email protected]

(C) 2007-2022 Hirohisa AMAN 1


Role of software
 A computer system is a combination
of hardware and software

Computer system The role of software is to


make full use of the
Software
hardware.
Hardware How to utilize hardware
depends on software

Games are a typical example

(C) 2007-2022 Hirohisa AMAN 2


Software Engineering
 Academic field for efficiently developing
high-quality software
 It's not a way of thinking that ‘if only a few
people try their best, something will happen.’
*So-called super programmers are in a special category, but
such people are rare.

 Academic field to make development work


Theory and technology for Theory and techniques for
efficient and high-quality + successfully managing
requirements analysis, design, development activities
programming, testing, etc. (development management)

(C) 2007-2022 Hirohisa AMAN 3


The Mythical Man-Month
 Man-month = number of people x number of
months * (Ex) 1 man-month
= 1.2 million yen
Unit of labor hours required for development
(Ex) 6 man-months = 2 months of work with 3 engineers
Bad manager
10 more man-months of
work left! However, there is So, should we There is
only half a month left until increase the number chaos at
the delivery date (0.5 of staff by 20 people? the scene!
month)
※ 10/0.5 = 20
An organized development process is important. (Man-hour/month
estimation is also a field of software engineering)

(C) 2007-2022 Hirohisa AMAN 4


Software Liability Is Serious
 The key to safety and security in
everyday life Software reliability
 Software bugs can cause serious damage
 Possibility of impact on electricity, gas, water
supply, transportation, and finance
(Ex) Stock exchange stops → Major damage
 may cause accidents
(Ex) Elevator malfunction → Personal injury

Needs to be tested for a variety of situations


(C) 2007-2022 Hirohisa AMAN 5
Software Features (1/4)
 It is difficult to grasp the actual situation
 Software is logical entity, not physical entity
 In short, It does not actually exist as a
“thing”

 It is difficult to know to what stage


development has progressed and whether
products are manufactured according to
specifications

(C) 2007-2022 Hirohisa AMAN 6


Software Features (2/4)
 Work concentrated on the
development process
 Hardware, the flow is to develop a product
and manufacture it in a factory.
 For software, manufacturing is just a copying
 Quality and cost are centered on the
development process
Hardware: Defective products  During the manufacturing process
Software: Defective products = "Everything is defective from the
beginning" → It's all about not failing during development

(C) 2007-2022 Hirohisa AMAN 7


Software Features (3/4)
 Long period of operation and
maintenance
 Operation (Actually used by users)
 Maintenance (Modify, improve, and
extend functions)
The period of doing is much longer

Ease of maintenance is the key


(C) 2007-2022 Hirohisa AMAN 8
Software Features (4/4)
 Low reuse
 Hardware: It is common to reuse
existing parts
 Software: It is difficult to complete just
by combining parts (requires a lot of
customization)

 There is software that can be reused in


the form of libraries, but it cannot be
used without programming.
(C) 2007-2022 Hirohisa AMAN 9
Reuse
 There are two types of software reuse

 Black Box
No need to worry about the contents, use it
like a part
 White Box
Copy and paste the program and rewrite it
as needed

(C) 2007-2022 Hirohisa AMAN 10


Black box reuse
 Library form
Example, by using an existing function as is
The content of the source code itself does not
matter.
Although it can only be used in a predetermined
manner (according to the manual), it is useful.
#include <xxxx.h>

(Example)
In C language Existing
scanf function or New
code code
printf function

(C) 2007-2022 Hirohisa AMAN 11


White box reuse
 “Copy and paste" the source code
For example, using part of existing source code.
Copy the codes in a book and web page
There is also a risk of copying mistakes (bugs)
and misuse.
Example: Even if you copy and paste a program that
you do not understand, you will only get confused.

copy
Existing New
code code

(C) 2007-2022 Hirohisa AMAN 12


[Exercise 1]
Consider the code clone problem
 Copy and paste the source code as it
is, or change part of it and reuse it
 It is called a "code clone”
 In the software industry, software
with many code clones is regarded as
a problem
Why?

(C) 2007-2022 Hirohisa AMAN 13


What is good software?
 Note that the concept differs
depending on the perspective
Easy to Understand and
user Maintain
friendly
Good
software
Meet the Appropriate
required development
A user Developer
specifications cost and period
or
client
Software engineering is mainly from the developer's perspective

(C) 2007-2022 Hirohisa AMAN 14


User's Perspective (1)
Satisfaction of required specifications
Requirements can be broadly divided into
two types:
 Functional requirements: Functions to
be achieved
Ex: User authentication
 Non-functional requirements : "How" the
requirements should be realized
Ex: Authentication for 500 users must be completed
within 3 seconds
It is not about the function itself, but about how to
realize it such as performance and security

(C) 2007-2022 Hirohisa AMAN 15


User's Perspective (2)
Usability
 In a word, "ease of use”
 Easy to operate
 Easy to understand operation

 Indirectly, operating speed and memory


usage are also related.
(I don't want to use so-called "heavy" systems)

(C) 2007-2022 Hirohisa AMAN 16


Developer's Perspective (1)
Cost and Period
 Low development cost is desirable
 The development period is within the
deadline (by the delivery date)
 It is rare to be able to develop slowly
over time
 Need to finish on time with limited
resources and time
The goal is to develop software that can be developed at low
cost, delivered on time, and meets the required
specifications.

(C) 2007-2022 Hirohisa AMAN 17


Developer's Perspective (2)
Maintainability
 Once completed and put into operation, the
required specifications almost always
change.
 Request for detailed corrections: "I want you to
change this"
 Request for addition or expansion of functions:
"More such functions"
 Bugs may be found
Easy-to-main software is “good” software & Easy-to-understand is
also important because it may be maintained by another person

(C) 2007-2022 Hirohisa AMAN 18


Three characters that appear in
software development workplaces
 QCD
It means three
 Quality important pillars in
 Cost the manufacturing
 Delivery industry.

 KKD
It means a
 Intuition workplace that is
 Experience not managed well.
 Courage
(C) 2007-2022 Hirohisa AMAN 19
Classification of software
 Basic software What the user
 Application software wants to do
 Middleware Application
software
 Embedded software Middleware
Image of these three layers Basic software
built into hardware
What the calculator
can provide?

(C) 2007-2022 Hirohisa AMAN 20


Basic software
 Software that is the basis for using a
computer and executing software
 Operating System
 Compiler/Interpreter
 Service program (utility)
( Ex ) File editing/searching
The basic software cannot perform any specific tasks,
but without it, the story cannot begin in the first place.
(Ex) Just because an OS (Windows, etc.) is installed doesn't mean you can
do anything. However, if it isn't installed in the first place, nothing will work.

(C) 2007-2022 Hirohisa AMAN 21


In other words, “App"
Application software
 Software with a specific purpose
 For example ,
 Securities transaction management
(industry specific software)
 Budget management (business software)
 Spreadsheets, presentations (common
application software)

 Software has become a tool for


accomplishing certain tasks or purposes.
(C) 2007-2022 Hirohisa AMAN 22
Middleware
 Intermediate between basic software
and application software
 Serves as the basis for application software
 For example , Software “for apps”
 Database management system rather than
software that users
 Web server use directly
 Application server
 Rather than using OS functions directly (system
calls, etc.), use higher-level concepts: For
example, in SQL
(C) 2007-2022 Hirohisa AMAN 23
Positioning of middleware
 Ex, suppose you have an application
that processes large amounts of data
on Windows. Search and manage data
by requesting the database
Application software instead of using the
application (using SQL)

Middleware

Return results Database

Windows ( OS )

(C) 2007-2022 Hirohisa AMAN 24


Embedded software
 Software mainly used to control devices
in electronic devices that implement
specific functions (※ It does not run on a
general-purpose computer, but
is built into a specific device )
 Ex: Electrical appliances, car navigation
systems, elevators, etc
 Supplied as an integral part of the
hardware
 It is not easy to install a modified version
 Operating environments are diverse and high
reliability is required
(C) 2007-2022 Hirohisa AMAN 25
[Exercise 2]List the challenges in developing
and maintaining embedded software.
 Thinking about embedded software
for elevator control
 When developing this software, what
is more difficult than general
software?
 Also, what about maintenance?

(C) 2007-2022 Hirohisa AMAN 26


Life cycle
 Life cycle: The Life of Software
Development (Development)
plan
Requirements analysis
External design
Internal design
Implementation
(Programming) This is usually
Test the longest

Operation/Maintenance Discard
(C) 2007-2022 Hirohisa AMAN 27
Software Crisis
 A sense of crisis proposed in 1968
Software development cannot keep up with needs,
hindering the development of computer systems.

 Software development is slow and


hinders computer progress
 Enlargement → Frequent bugs →
Developing into social problems
 Increased development costs
In short, the software is the bottleneck!
(C) 2007-2022 Hirohisa AMAN 28
(1) Obstructing the progress of
computers
 The trend was to let computers do
many things (at the time)

 Let's cheaply mass-produce general-purpose


hardware and let software handle the details
But software is basically "handmade"
 Development is not in time!
 Not enough engineers!

(C) 2007-2022 Hirohisa AMAN 29


(2) Fear of development into
social problems
 As needs for systems increase, software
becomes larger and more complex.

 The risk of human error (so-called bugs)


also increases.
Depending on the system and the type of bug, it may
cause serious damage to social life.

Possibility of affecting electricity, gas, water,


transportation, finance, etc.
(C) 2007-2022 Hirohisa AMAN 30
(3) Increase in costs
 Software development and maintenance
costs are increasing
[Software] Manual
[Hardware] Benefits handling will continue
of technological to increase as demands
advancement and and scale increase
Cost mass production

Period

(C) 2007-2022 Hirohisa AMAN 31


Birth of “Software Engineering”
 Measures are needed to solve such problems
Researching theories and techniques for efficiently
developing high-quality software (until then, it was more
like "craftsmanship")

 Establish theories and techniques related to software


development , systemize them as "engineering" (the
science of manufacturing) to achieve high
productivity and high quality!

(C) 2007-2022 Hirohisa AMAN 32


Current/Future Challenges
 The software industry has developed
through various research and
technological innovations, but difficult
issues still remain.
 Difficulty in Requirements Analysis
 Difficulty in Reusing
 Difficulty in Project Management
 Difficulty in Estimating

(C) 2007-2022 Hirohisa AMAN 33


Difficulty in requirements analysis
 Analyze customer requirements ,
 Correctly This is the first step,
but it is difficult because
 Without ambiguity it is the closest to humans.

 Appropriate as a system for development


purposes It must be written as a specific
specification.
If the customer is a software amateur, he Confusion arises because different fields
or she will make unexpectedly (called domains) have different cultures
unreasonable demands. and languages.

Stories like "I can't There is also a story that


do that" ‘Even if it is obvious to the
other person, we do not
know it.’
(C) 2007-2022 Hirohisa AMAN 34
Difficulty in reusing
 Source code reuse
 Although it is relatively easy to practice, simple
copying and pasting can also cause bugs → Code
cloning
 Which code should I use?
 Design and architecture reuse
 This is reusing knowledge and know-how at a
more abstract level than code, and the hurdles
are quite high.
 Knowledge of design patterns and frameworks
required
(C) 2007-2022 Hirohisa AMAN 35
Difficulty in project management
 In development project management
 Progress management
 Quality management
 Staffing, communication management
Items such as these are issues for project
managers

(C) 2007-2022 Hirohisa AMAN 36


Difficulty in estimating
 In reality, there is still a large degree of
individuality
 In other words, it largely depends on the
experience and abilities of individual engineers.
 It is difficult to estimate man-hours, period, and
costs from this  Delays and cost overruns
 Man-hour estimation model ( COCOMO )
 Development organization maturity model
( CMM, CMMI )
 Prediction using statistics, neural
networks,..
(C) 2007-2022 Hirohisa AMAN 37
Summary
 Software engineering is not only the
study of how to create software, but also
the management that leads development projects to
success.
 Although the software industry is
developing, there are still many issues
to be solved:requirements analysis, reuse,
project management, estimation, etc.

(C) 2007-2022 Hirohisa AMAN 38


Homework

Answer “[2] quiz”


by tomorrow 13:00pm

(Notes: Your quiz score will be a part of your final project


evaluation)

(C) 2007-2022 Hirohisa AMAN 39

You might also like