Pertemuan 6 Metodologi Proyek (Fase Desain)
SOFTWARE ENGINEERING ANALYSIS & DESIGN
Project Method (Design Phase)
Topics
•
•
•
•
Communication Principles
Model & Modeling Principles
Requirement Modeling Principles
Design Modeling and Design Modeling
Principles
Software Engineering in Practical Approach #3
2
Communication Principles
• Before customer requirements can be
analyzed, modeled, or specified they must be
gathered through the communication activity.
• A customer has a problem that may be
amenable to a computer-based solution. You
respond to the customer’s request for help.
• Communication has begun. But the road from
communication to understanding is often full
of potholes.
Software Engineering in Practical Approach #3
3
Communication Principles
1.
2.
3.
4.
5.
6.
7.
8.
9.
Listen
Prepare before you communicate
Someone should facilitate the activity
Face-to-face communication is best
Take notes and document decisions
Strive for collaboration
Stay focused; modularize your discussion
If something is unclear, draw a picture
Once you agree to something OR If you can’t agree to
something OR If a feature or function is unclear and cannot
be clarified at the moment, move on.
10. Negotiation is not a contest or a game. It works best when
both parties win.
Software Engineering in Practical Approach #3
4
Model
• We create models to gain a better
understanding of the actual entity to be built.
• When the entity is a physical thing (e.g., a
building, a plane, a machine), we can build a
model that is identical in form and shape but
smaller in scale.
• When the entity to be built is software, our
model must take a different form.
Software Engineering in Practical Approach #3
5
Model
• It must be capable of representing
– the information that software transforms,
– the architecture and functions that enable the
transformation to occur,
– the features that users desire, and
– the behavior of the system as the transformation
is taking place.
Software Engineering in Practical Approach #3
6
Two Classes of Models
• In software engineering work, two classes of
models can be created:
– requirements models and
– design models.
• Requirements models (also called analysis
models) represent customer requirements by
depicting the software in three different
domains:
– the information domain,
– the functional domain, and
– the behavioral domain.
Software Engineering in Practical Approach #3
7
Two Classes of Models
• Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user
interface, and component-level detail.
Software Engineering in Practical Approach #3
8
Modeling Principles
1. The primary goal of the software team is to build
software, not create models.
2. Travel light—don’t create more models than you
need.
3. Strive to produce the simplest model that will
describe the problem or the software.
4. Build models in a way that makes them no problem
to change.
5. Be able to state an explicit purpose for each model
that is created.
Software Engineering in Practical Approach #3
9
Modeling Principles
6. Adapt the models you develop to the system at hand
7. Try to build useful models, but forget about building
perfect models.
8. Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representation
is secondary.
9. If your instincts tell you a model isn’t right even though
it seems okay on paper, you probably have reason to be
concerned.
10. Get feedback as soon as you can.
Software Engineering in Practical Approach #3
10
Requirement Modeling Principles
1. The information domain of a problem must be
represented and understood.
2. The functions that the software performs must be
defined
3. The behavior of the software (as a consequence of
external events) must be represented
4. The models that depict information, function, and
behavior must be partitioned in a manner that
uncovers detail in a layered (or hierarchical) fashion.
5. The analysis task should move from essential
information toward implementation detail
Software Engineering in Practical Approach #3
11
The Elements of Req. Model
• Scenario-based elements.
– The system is described from the user’s point of view using a
scenario-based approach
– Scenario-based elements of the requirements model are often
the first part of the model that is developed.
– As such, they serve as input for the creation of other modeling
elements.
• Class-based elements.
– Each usage scenario implies a set of objects that are
manipulated as an actor interacts with the system.
– These objects are categorized into classes—a collection of
things that have similar attributes and common behaviors.
– Classes need collaborate with one another and the relationships
and interactions between classes
Software Engineering in Practical Approach #3
12
The Elements of Req. Model
• Behavioral elements.
– The behavior of a computer-based system can have a profound
effect on the design that is chosen and the implementation
approach that is applied.
– Therefore, the requirements model must provide modeling
elements that depict behavior.
• Flow-oriented elements.
– Information is transformed as it flows through a computerbased system.
– The system accepts input in a variety of forms, applies functions
to transform it, and produces output in a variety of forms.
Software Engineering in Practical Approach #3
13
The Elements of Req. Model
Software Engineering in Practical Approach #3
14
Design Modeling
• The software design model is analogous to an
architect’s plans for a house.
• It begins by representing the totality of the thing
to be built (e.g., a three-dimensional rendering of
the house) and slowly refines the thing to provide
guidance for constructing each detail (e.g., the
plumbing layout).
• Similarly, the design model that is created for
software provides a variety of different views of
the system.
Software Engineering in Practical Approach #3
15
Design Modeling
• Design is what almost every engineer wants to do.
• It is the place where creativity rules—where
stakeholder requirements, business needs, and
technical considerations all come together in the
formulation of a product or system.
• Design creates a representation or model of the
software, but unlike the requirements model (that
focuses on describing required data, function, and
behavior), the design model provides detail about
software architecture, data structures, interfaces, and
components that are necessary to implement the
system.
Software Engineering in Practical Approach #3
16
From Req. to Design Model
Software Engineering in Practical Approach #3
17
Design Modeling Principles
1. Design should be traceable to the requirements
model.
2. Always consider the architecture of the system
to be built.
3. Design of data is as important as design of
processing functions.
4. Interfaces (both internal and external) must be
designed with care.
5. User interface design should be tuned to the
needs of the end user. However, in every case, it
should stress ease of use.
Software Engineering in Practical Approach #3
18
Design Modeling Principles
6. Component-level design should be functionally
independent.
7. Components should be loosely coupled to one
another and to the external environment.
8. Design representations (models) should be easily
understandable.
9. The design should be developed iteratively. With
each iteration, the designer should strive for greater
simplicity.
Software Engineering in Practical Approach #3
19
Design Modeling Principles
• When these design principles are properly applied, you
create a design that exhibits both external and internal
quality factors.
• External quality factors are those properties of the
software that can be readily observed by users (e.g.,
speed, reliability, correctness, usability).
• Internal quality factors are of importance to software
engineers.
– They lead to a high-quality design from the technical
perspective.
– To achieve internal quality factors, the designer must
understand basic design concepts
Software Engineering in Practical Approach #3
20
About SRS
• A software requirements specification (SRS) is a
document that is created when a detailed description
of all aspects of the software to be built must be
specified before the project is to commence.
• It is important to note that a formal SRS is not always
written. In fact, there are many instances in which
effort expended on an SRS might be better spent in
other software engineering activities.
• When software is to be developed by a third party,
when a lack of specification would create severe
business issues, or when a system is extremely complex
or business critical, an SRS may be justified.
Software Engineering in Practical Approach #3
21
About SRS
• It is better to use a standardized SRS, such as
SRS based on IEEE template.
• But, it is better to write the only requirement
specification needed. Don’t write the useless
things.
Software Engineering in Practical Approach #3
22
Sumber
• BAHTIAR H. SUHESTA
IT Practitioner, Writer-preneur, and Founder of
An-Nabwah Group
Software Engineering in Practical Approach #3
23
Project Method (Design Phase)
Topics
•
•
•
•
Communication Principles
Model & Modeling Principles
Requirement Modeling Principles
Design Modeling and Design Modeling
Principles
Software Engineering in Practical Approach #3
2
Communication Principles
• Before customer requirements can be
analyzed, modeled, or specified they must be
gathered through the communication activity.
• A customer has a problem that may be
amenable to a computer-based solution. You
respond to the customer’s request for help.
• Communication has begun. But the road from
communication to understanding is often full
of potholes.
Software Engineering in Practical Approach #3
3
Communication Principles
1.
2.
3.
4.
5.
6.
7.
8.
9.
Listen
Prepare before you communicate
Someone should facilitate the activity
Face-to-face communication is best
Take notes and document decisions
Strive for collaboration
Stay focused; modularize your discussion
If something is unclear, draw a picture
Once you agree to something OR If you can’t agree to
something OR If a feature or function is unclear and cannot
be clarified at the moment, move on.
10. Negotiation is not a contest or a game. It works best when
both parties win.
Software Engineering in Practical Approach #3
4
Model
• We create models to gain a better
understanding of the actual entity to be built.
• When the entity is a physical thing (e.g., a
building, a plane, a machine), we can build a
model that is identical in form and shape but
smaller in scale.
• When the entity to be built is software, our
model must take a different form.
Software Engineering in Practical Approach #3
5
Model
• It must be capable of representing
– the information that software transforms,
– the architecture and functions that enable the
transformation to occur,
– the features that users desire, and
– the behavior of the system as the transformation
is taking place.
Software Engineering in Practical Approach #3
6
Two Classes of Models
• In software engineering work, two classes of
models can be created:
– requirements models and
– design models.
• Requirements models (also called analysis
models) represent customer requirements by
depicting the software in three different
domains:
– the information domain,
– the functional domain, and
– the behavioral domain.
Software Engineering in Practical Approach #3
7
Two Classes of Models
• Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user
interface, and component-level detail.
Software Engineering in Practical Approach #3
8
Modeling Principles
1. The primary goal of the software team is to build
software, not create models.
2. Travel light—don’t create more models than you
need.
3. Strive to produce the simplest model that will
describe the problem or the software.
4. Build models in a way that makes them no problem
to change.
5. Be able to state an explicit purpose for each model
that is created.
Software Engineering in Practical Approach #3
9
Modeling Principles
6. Adapt the models you develop to the system at hand
7. Try to build useful models, but forget about building
perfect models.
8. Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representation
is secondary.
9. If your instincts tell you a model isn’t right even though
it seems okay on paper, you probably have reason to be
concerned.
10. Get feedback as soon as you can.
Software Engineering in Practical Approach #3
10
Requirement Modeling Principles
1. The information domain of a problem must be
represented and understood.
2. The functions that the software performs must be
defined
3. The behavior of the software (as a consequence of
external events) must be represented
4. The models that depict information, function, and
behavior must be partitioned in a manner that
uncovers detail in a layered (or hierarchical) fashion.
5. The analysis task should move from essential
information toward implementation detail
Software Engineering in Practical Approach #3
11
The Elements of Req. Model
• Scenario-based elements.
– The system is described from the user’s point of view using a
scenario-based approach
– Scenario-based elements of the requirements model are often
the first part of the model that is developed.
– As such, they serve as input for the creation of other modeling
elements.
• Class-based elements.
– Each usage scenario implies a set of objects that are
manipulated as an actor interacts with the system.
– These objects are categorized into classes—a collection of
things that have similar attributes and common behaviors.
– Classes need collaborate with one another and the relationships
and interactions between classes
Software Engineering in Practical Approach #3
12
The Elements of Req. Model
• Behavioral elements.
– The behavior of a computer-based system can have a profound
effect on the design that is chosen and the implementation
approach that is applied.
– Therefore, the requirements model must provide modeling
elements that depict behavior.
• Flow-oriented elements.
– Information is transformed as it flows through a computerbased system.
– The system accepts input in a variety of forms, applies functions
to transform it, and produces output in a variety of forms.
Software Engineering in Practical Approach #3
13
The Elements of Req. Model
Software Engineering in Practical Approach #3
14
Design Modeling
• The software design model is analogous to an
architect’s plans for a house.
• It begins by representing the totality of the thing
to be built (e.g., a three-dimensional rendering of
the house) and slowly refines the thing to provide
guidance for constructing each detail (e.g., the
plumbing layout).
• Similarly, the design model that is created for
software provides a variety of different views of
the system.
Software Engineering in Practical Approach #3
15
Design Modeling
• Design is what almost every engineer wants to do.
• It is the place where creativity rules—where
stakeholder requirements, business needs, and
technical considerations all come together in the
formulation of a product or system.
• Design creates a representation or model of the
software, but unlike the requirements model (that
focuses on describing required data, function, and
behavior), the design model provides detail about
software architecture, data structures, interfaces, and
components that are necessary to implement the
system.
Software Engineering in Practical Approach #3
16
From Req. to Design Model
Software Engineering in Practical Approach #3
17
Design Modeling Principles
1. Design should be traceable to the requirements
model.
2. Always consider the architecture of the system
to be built.
3. Design of data is as important as design of
processing functions.
4. Interfaces (both internal and external) must be
designed with care.
5. User interface design should be tuned to the
needs of the end user. However, in every case, it
should stress ease of use.
Software Engineering in Practical Approach #3
18
Design Modeling Principles
6. Component-level design should be functionally
independent.
7. Components should be loosely coupled to one
another and to the external environment.
8. Design representations (models) should be easily
understandable.
9. The design should be developed iteratively. With
each iteration, the designer should strive for greater
simplicity.
Software Engineering in Practical Approach #3
19
Design Modeling Principles
• When these design principles are properly applied, you
create a design that exhibits both external and internal
quality factors.
• External quality factors are those properties of the
software that can be readily observed by users (e.g.,
speed, reliability, correctness, usability).
• Internal quality factors are of importance to software
engineers.
– They lead to a high-quality design from the technical
perspective.
– To achieve internal quality factors, the designer must
understand basic design concepts
Software Engineering in Practical Approach #3
20
About SRS
• A software requirements specification (SRS) is a
document that is created when a detailed description
of all aspects of the software to be built must be
specified before the project is to commence.
• It is important to note that a formal SRS is not always
written. In fact, there are many instances in which
effort expended on an SRS might be better spent in
other software engineering activities.
• When software is to be developed by a third party,
when a lack of specification would create severe
business issues, or when a system is extremely complex
or business critical, an SRS may be justified.
Software Engineering in Practical Approach #3
21
About SRS
• It is better to use a standardized SRS, such as
SRS based on IEEE template.
• But, it is better to write the only requirement
specification needed. Don’t write the useless
things.
Software Engineering in Practical Approach #3
22
Sumber
• BAHTIAR H. SUHESTA
IT Practitioner, Writer-preneur, and Founder of
An-Nabwah Group
Software Engineering in Practical Approach #3
23