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

0% found this document useful (0 votes)
17 views32 pages

FE Development Technology PPT2

Uploaded by

hsint htay
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)
17 views32 pages

FE Development Technology PPT2

Uploaded by

hsint htay
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/ 32

Chapter-4

Development
Technology

1
1 – 1 -2 Software Implementation
Process
i. Software requirements definition process
ii. Software architectural design process
iii. Software detailed design process
iv. Software construction process
v. Software integration process
vi. Software qualification testing process
vii. Software installation process
viii.Software acceptance support process
2
1-2-3 Software Detailed Design
Process
The software detailed design process provides a design
for the software that implements and can be verified
against the software requirements and software
architecture and is sufficiently detailed to permit coding
and testing.

[Activities of software detailed design process]


(i) Software detailed design
(ii) Evaluation and review of software detailed design

3
(1) Software detailed design
(i) Detailed design of software components
Software components are refined into lower levels containing
software units (i.e., a single unit, classes, and modules) that can
be coded, compiled, and tested. It is confirmed that all software
requirements are allocated from the software components to
software units. This is documented in a software detailed design
document (i.e., component detailed design document).
(ii) Detailed design of software interfaces
A detailed design is to be developed and documented for the
external interfaces of the software configuration items, the
interfaces between the software components, and the interfaces
between the software units.

4
Cont’d
(iii) Detailed design for the databases
A detailed design for the database is to be developed and
documented.
(iv) Updating user documentation
User documentation is to be updated as necessary.
(v) Definition of test requirements for software
units
Test requirements and the schedule for testing software units
are to be defined and documented. The scope, test plans, test
procedures, and others of software unit test are to be defined, and a
software unit test specifications document is to be developed. It is
desirable that the test requirements include the stress test of the
software unit at the limits of its requirements. 5
Cont’d
(vi) Updating of test requirements for software
integration
The test requirements and the schedule for software
integration are to be updated.

In software detailed design, software components (i.e.,


programs) are partitioned into the units of coding called
software units.

6
Cont’d
Task (i) described above is also called module design,
because software component is partitioned into modules, which
are the units of development (i.e., coding).
In the module partitioning that is conducted during module
design, structured design using the concept of structuring is
used.
For the module partitioning that is used in structured design,
there are methods that focus on the flow of processing (or data).
In general procedures, higher-level module partitioning is
first performed by using STS partitioning, after which lower-level
modules are partitioned by using transaction partitioning.
After this, the modules are verified, and common functional
partitioning is performed.
7
STS partitioning
This is a technique thatthe models for output data
partitions program flow intohave been collected.
three parts: input (i.e.,
Source), processing (i.e.,
Transform), and output (i.e.,
Sink). Each part becomes a
module. Partitioning in this
case is carried out at the
maximum abstract input point
where input data has been
abstracted, and the maximum
abstract output point where
8
TR partitioning (Transaction
partitioning)
This is a technique that partitions each process as a
module when processing differs according to type of
data. As an example, when processing procedures differ
for males and females in file updating, partitioning can
be performed as follows:

9
Common functional partitioning
• When there are functions that are common to multiple
partitioned modules, this technique partitions these
functions into a single independent module.
Cont’d
In addition to methods focused on the flow of processing (or
data), there are also methods of module partitioning that
focus on data structure.
 Jackson method
This is a technique that analyzes input data and output data, and
partitions modules according to the output data structure. In the
Jackson method, both data structures and program structure are
represented as three basic structures (sequence, selection, and
iteration).
• Warnier method
This is a technique that uses the set theory to analyze input data
structures from the perspective of when and how many times to
perform processing.
Module Strength and Module
Coupling
• Modules partitioned in this way must be evaluated for
independence. Module strength and module coupling
are used as metrics for evaluation.

• Module Strength Or Cohesion


This metric represents the associations of functions
within the module. A better module has a higher
strength. When modules are arranged in order of higher
module strength, the result is as follows:
Module Strength and Module
Coupling
Module Strength Or Cohesion
Module coupling
This metric represents associations with other modules. A
better module has a weaker coupling. When modules are
arranged in order of weaker module coupling, the result
is as follows:
Cont’d
• Partitioned modules are to be evaluated according to evaluation
criteria, such as scope of control and scope of effect of the
module, amount of partitioning of the module (the number of
steps), partitioning into components, and reuse. After that, they
are to be repartitioned as necessary.

Guidelines for amount of module partitioning


• Partition a single component into about 10-200 modules.
• Partition a component so that partitioned modules have a
hierarchical depth of up to 4 levels.
• Partition a component so that the number of modules at the
same depth (i.e., level) is 10 or less.
Cont’d
Module specification design (or program design) is to be performed to
clarify the functions of the partitioned modules. At this time, methods
for representing module specifications include flowcharts, decision
tables, and NS (Nassi-Shneiderman) charts.

In “(ii) Detailed design of software interfaces” (interface design),


physical design is to be performed, which includes responsiveness,
hardware functions, and others along with what have been considered in
architectural design.

In input/output detailed design, as input media, input design to


determine input data checking methods (e.g., numeric checks, limit
checks, format checks, duplication checks, matching checks, balance
checks, logical checks (validity checks)), output objectives, and others
are considered, output media (e.g., display screens, printer forms) is
determined.
Cont’d
• In addition, output design is performed to design
layouts based on the limitations of paper (specialized
paper, general paper), displays, printers, and others.
• In physical data design for files and others, data
property analysis, file organization methods recording
media, the layout of records and others are determined.
• This way of thinking is that same as that in “(iii)
Detailed design for the databases,” and a physical data
model is created with an awareness of the DBMS
product to be implemented.

You might also like