Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Computer Science > Software Engineering > Flashcards

Software Engineering Flashcards

1
Q

Traits of Successful Software Engineers

A
  1. Sense of individual responsibility
  2. Aware of the needs of team members and stakeholders
  3. Honest about design flaws and offers constructive criticism
  4. Resilient under pressure
  5. Sense of fairness
  6. Attention to detail
  7. Pragmatic
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Software Engineer

A
  • A software engineer uses engineering principles to plan, design, develop, test, and maintain computer software and mobile applications.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is software?

A

Software is a set of items or objects that form a “configuration” that includes
1. Instruction
2. Data structure
3. Documentation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Software roles

A
  • A product
  • A vehicle for delivering a product
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

why is Software a product

A

o Delivers computing potential
o Produces, manages, acquires, modifies, displays, or transmits information

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

why is software a vehicle for delivering product

A

o Supports or provides system functionality
o Controls other programs
o Effects communication
o Helps build other software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

process pattern types

A

stage pattern, task pattern, phase pattern

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Framework activities

A

o Communication
o Planning
o Modeling
o Construction
o Deployment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Umbrella activities

A
  1. Software Project Tracking and Control
  2. Risk Management
  3. Software Quality Assurance
  4. Technical Reviews
  5. Measurement
  6. Software Configuration Management
  7. Reusability Management
  8. Work Product Preparation and Production
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Importance of software engineering

A
  • The number of people who have an interest in the features and functions provided by an application has grown dramatically
  • The requirements have grown complex, the programs have to be developed by large teams of people
  • Individuals, businesses, and governments rely on software for strategic and tactical decision-making as well as day-to-day operations and control
  • As the perceived value of an application grows, it is likely that its user base and longevity grows, and demands for adaptation and enhancement will grow
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Software process

A

an adaptable approach that enables the software team to choose the appropriate set of work actions and tasks

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

polya’s problem solving

A
  1. Understand the problem
  2. Plan a solution
  3. Carry out the plan
  4. Examine the results for accuracy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Software Engineering Domain

A
  1. System software
  2. Application software
  3. Engineering/ Scientific software
  4. Embedded software
  5. Product-line software
  6. AI software
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Why must software change?

A
  • Software must be adapted to meet the needs of new computing technology
  • Software must be enhanced to implement new business requirements
  • Software must be extended to make it interoperable with other more modern systems
  • Software must be re-architected to make it viable within a network environment
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Software Categories

A

WebApps
Mobile Application
Cloud Computing
Product-Line Software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Task set

A

the actual work to be done to accomplish the objectives of a software engineering action

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Process Pattern Types

A

o Stage pattern
o Task pattern
o Phase pattern

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Process Assessment and Improvement

A
  • Standard CMMI Assessment Method for Process Improvement
  • CMM-Based Appraisal for Internal Process Improvement
  • The SPICE
  • ISO 9001:2000 for Software
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Standard CMMI Assessment Method for Process Improvement

A

provides a five-step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting, and learning.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

CMM-Based Appraisal for Internal Process Improvement

A

provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

The SPICE

A

defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

ISO 9001:2000 for Software

A

a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. The standard is applicable to software organizations and companies.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

describe Prescriptive Process Models

A
  • Prescriptive process models advocate an orderly approach to software engineering
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

state the prescriptive process models

A
  • The Waterfall Model
  • The V-Model
  • The Incremental Model
  • The Evolutionary Model
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Prototyping

A
  • customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features
  • The prototyping paradigm assists to better understand what is to be built when requirements are fuzzy
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Agile Process

A
  • Is driven by customer descriptions of what is required
  • Recognizes that plans are short-lived
  • Develops software iteratively with a heavy emphasis on construction activities
  • Delivers multiple ‘software increments’
  • Adapts as changes occur
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Types of Agile Process

A

Extreme Programming (XP)

Industrial XP (IXP)

Scrum

Dynamic Systems Development Method

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

XP Planning

A

 Begins with the creation of “user stories”.
 Agile team assesses each story and assigns a cost.
 Stories are grouped to for a deliverable increment.
 A commitment is made on delivery date
 After the first increment, “project velocity” is used to help
 define subsequent delivery dates for other increments.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

XP Design

A

 Follows the KIS (Keep It Simple) principle.
 Encourage the use of CRC (class-responsibility-collaborator) cards.
 For difficult design problems, suggests the creation of “spike solutions”
 Encourages “refactoring”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

XP Coding

A

 Recommends the construction of a unit test for a store before coding commences
 Encourages “pair programming”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

XP Testing

A

All unit tests are executed daily

“Acceptance tests” are defined by the customer and executed to assess customer visible functionality

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Extreme Programming consist of?

A

XP Planning, XP Design, XP Coding, XP Testing

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

6 new practices of Industrial XP

A

 Readiness assessment
 Project community
 Project chartering
 Test driven management
 Retrospectives
 Continuous learning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

features of scrum

A

 Development work is partitioned into “packets”.
 Testing and documentation are on-going as the product is constructed.
 Work occurs in “sprints” and is derived from a “backlog” of existing requirements.
 Meetings are very short and sometimes conducted without chairs.
 “Demos” are delivered to the customer with the time-box allocated.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

9 principles of Dynamic Systems Development Method

A

 Active user involvement is imperative.
 DSDM teams must be empowered to make decisions.
 The focus is on frequent delivery of products.
 Fitness for business purpose is the essential criterion for acceptance of deliverables.
 Iterative and incremental development is necessary to converge on an accurate business solution.
 All changes during development are reversible.
 Requirements are baselined at a high level
 Testing is integrated throughout the life-cycle.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Agile Modeling Principles

A
  1. Model with a purpose
  2. Use multiple models
  3. Travel light
  4. Content is more important than representation
  5. Know the models and the tools you use to create them
  6. Adapt locally
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Agile Unified Process Activities

A
  • Modeling
  • Implementation
  • Testing
  • Deployment
  • Configuration and project management
  • Environment management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

what is a software prototype?

A

A software prototype is a preliminary version of a software application or system that is developed for the purpose of testing, evaluating, and demonstrating concepts or functionalities.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Describe function of analysis model

A

provide a description of the required informational, functional, and behavioural domains for a computer-based system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

elements of analysis model

A

scenario-based models
class models
behavioral models
flow models

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

list the classes of models that
can be created

A

Requirements models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain.
Design models represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level
detail.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

List the Requirements Modeling Principles

A

Principle #1. The information domain of a problem must be represented and understood.

Principle #2. The functions that the software performs must be defined.

Principle #3. The behavior of the software must be represented.

Principle #4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers
detail in a layered fashion.

Principle #5. The analysis task should move from essential information toward implementation detail.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

what are inception and elicitation?

A

it provides you with the information
you’ll need to begin writing use cases.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to:

A

Identify stakeholders.

Define the scope of the problem.

Specify overall operational goals.

Establish priorities.

Outline all known functional requirements.

Describe the things (objects) that will be manipulated by the system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

what is use-case

A

A scenario that describes a “thread of usage” for a system.
Actors represent the roles people or devices play as the system functions.
Users can play a number of different roles in a given scenario.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

describe class-based modeling

A

Class-based modeling represents:
Objects that the system will manipulate.
Operations that will be applied to the objects to effect the manipulation.
Relationships between the objects.
Collaborations that occur between the classes that are defined.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

describe the Manifestations of Analysis Classes

A

Analysis classes manifest themselves in one of the following ways:
External Entities that produce or consume information.
Things that are part of the information domain for the problem.
Occurrences or Events that occur within the context of the system operation.

Roles played by people who interact with the system.

Organizational Units that are relevant to an
application.

Places that establish the context of the problem and the overall function.

Structures that define a class of objects or related classes of objects

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

List Out the Potential Classes

A

Retained Information.
Needed Services.
Multiple Attributes.
Common Attributes.
Common Operations.
Essential Requirements.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Operations can be divided into four broad categories:

A

Operations that manipulate data in some way
Operations that perform a computation
Operations that inquire about the state of an object
Operations that monitor an object for the occurrence of a controlling event

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

state the function of the CRC model

A

Class-responsibility-collaborator (CRC) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

describe inception

A

ask a set of questions that establish:
1. Basic understanding of the problem
2. The people who want a solution
3. The nature of the solution that is desired
4. The effectiveness of preliminary communication and collaboration between the customer and the developer

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

describe Elicitation

A

elicit requirements from all stakeholders

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

describe elaboration

A

create an analysis model that identifies data, function and behavioral requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

describe the modeling principles

A

two classes of models can be created:
Requirements models (analysis models) represent the customer requirements by depicting the software in three different domains: the information
domain, the functional domain, and the behavioral domain.

Design models represent software characteristics that help practitioners construct it effectively: the architecture, the user interface, and component-level detail.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

describe specification in requirement engineering

A

it can be:
1. A written document
2. A set of models
3. A formal mathematical
4. A collection of user scenarios (use-cases)
5. A prototype

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

describe validation in requirement engineering

A

a review mechanism that looks for:
1. Errors in content or interpretation
2. Areas where clarification may be required
3. Missing information
4. Inconsistencies
6. Conflicting or unrealistic requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

what is done during requirement gathering

A
  • Meetings are conducted and attended by both software engineers and customers
  • Rules for preparation and participation are established
  • An agenda is suggested
  • A “facilitator” (customer, developer, or outsider) controls the meeting
  • A “definition mechanism” is used
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

what is the goal of requirement gathering

A
  1. To identify the problem
  2. Propose elements of the solution
  3. Negotiate different approaches
  4. Specify a preliminary set of solution requirements
59
Q

Describe Quality Function Deployment

A
  • Function deployment determines the “value” of each function required of the system
  • Information deployment identifies data objects and events
  • Task deployment examines the behaviour of the system
  • Value analysis determines the relative priority of requirements
60
Q

list the elicitation work product

A
  • A statement of need and feasibility
  • A bounded statement of scope for the system or product
  • A list of customers, users, and other stakeholders who participated in requirements elicitation
  • A description of the system’s technical environment.
  • A list of requirements and the domain constraints that apply to each
  • A set of usage scenarios that provide insight into the use of the system or product under different operating conditions
  • Any prototypes developed to better define requirements
61
Q

Describe Non-Functional Requirement

A
  • Non-Functional Requirement (NFR): A two-phase process is used to determine which NFR’s are compatible:
    1. Create a matrix using each NFR as a column heading and the system SE guidelines a row labels
    2. The team should prioritize each NFR using a set of decision rules to decide which to implement by classifying each NFR and guideline pair as complementary, overlapping, conflicting, or independent
62
Q

describe the analysis model

A
  • The intent of the analysis model is to provide a description of the required informational, functional, and behavioural domains for a computer-based system.
  • The model changes dynamically as you learn more about the system, or other stakeholders understand more about what they require
63
Q

state the Building the Analysis Model

A
  • Elements of the analysis model:
    o Scenario-Based Elements
     Use-case — descriptions of the interaction between an actor and the system
    o Class- Based Elements
     Implied by a set of objects.
    o Behavioural Elements
     State Diagram — depicted the behaviour of modeling elements
    o Flow-Oriented Elements
     Data Flow Diagram — illustrated the flows of data throughout the system
64
Q

describe negotiation

A
  • Customers and users may ask for more than can be achieved, given limited business resources.
  • Different customers or users may propose conflicting requirements.
  • These conflicts have to be reconciled through a process of negotiation
  • Customers, users, and other stakeholders are asked to rank requirements and discuss conflicts in priority.
  • The conflicting requirements are eliminated, combined, and/or modified to achieve some measure of satisfaction for all parties
65
Q

Requirements monitoring Includes?

A
  • Distributed debugging – uncovers errors and determines their cause.
  • Run-time verification – determines whether software matches its specification.
  • Run-time validation – assesses whether evolving software meets user goals.
  • Business activity monitoring – evaluates whether a system satisfies business goals.
  • Evolution and codesign – provides information to stakeholders as the system evolves.
66
Q

state the functions of requirement analysis

A

o Specifies software’s operational characteristics.
o Indicates software’s interface with other system elements.
o Establishes constraints that software must meet.
- Requirements analysis allows the software engineer to:
o Elaborate on basic requirements established during earlier requirement engineering tasks.
o Build models that depict user scenarios, functional. activities, problem classes and their relationships, system and class behaviour, and the flow of data as it is transformed.

67
Q

state the objectives of requirements analysis

A
  • To describe what the customer requires
  • To establish a basis for the creation of a software design
  • To define a set of requirements that can be validated once the software is built
68
Q

state the focus of requirements analysis

A
  • What user interaction occurs in a particular circumstance?
  • What objects does the system manipulate?
  • What functions must the system perform?
  • What behaviours does the system exhibit?
  • What interfaces are defined?
  • What constraints apply?
69
Q

describe what a good design should exhibit

A

Firmness: A program should not have any bugs that inhibit its function.

Commodity: A program should be suitable for the purposes for which it was intended.

Delight: The experience of using the program should be a pleasurable one.

70
Q

what is design?

A

Explaining the idea/concept of something

Usually with graphical diagrams

With the intention to build from the explanation

So a design is a representation of a product or a system with sufficient detail for implementation

71
Q

Describe Designing Software

A

From our understanding of the problem, we start building the software

Translate the analysis model into the design model

Map the information from the analysis model to the design representations - data design, architectural design, interface design, component-level design

72
Q

state Software Engineering Design

A

Data/Class design – transforms analysis classes into implementation classes and data structures

Architectural design – defines relationships among the major software structural elements

Interface design – defines how software elements, hardware elements, and end-users communicate

Component-level design – transforms structural elements into procedural descriptions of software
components

73
Q

how to maintain design and quality

A

the design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.

the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.

the design should provide a complete picture of the
software, addressing the data, functional, and behavioral domains from an implementation perspective.

74
Q

state the design guidelines

A

A design should exhibit an architecture that (1) has been created using recognizable architectural styles or patterns, (2) is
composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion

A design should be modular; that is, the software should be logically partitioned into elements or subsystems

A design should contain distinct representations of data, architecture, interfaces, and components.

A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data
patterns.

A design should lead to components that exhibit independent functional characteristics.

A design should lead to interfaces that reduce the complexity of
connections between components and with the external environment.

A design should be derived using a repeatable method that is
driven by information obtained during software requirements
analysis.

A design should be represented using a notation that effectively
communicates its meaning.

75
Q

list the design principles

A

The design process should not suffer from ‘tunnel vision.’

The design should be traceable to the analysis model.

The design should not reinvent the wheel.

The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world.

The design should exhibit uniformity and integration.

The design should be structured to accommodate change.

The design should be structured to degrade gently, even when aberrant
data, events, or operating conditions are encountered.

Design is not coding, coding is not design.

The design should be assessed for quality as it is being created, not after the fact.

The design should be reviewed to minimize conceptual (semantic) errors.

76
Q

Describe Separation of Concerns

A

A concern is a feature or behavior that is specified
as part of the requirements model for the software

By separating concerns into smaller, and therefore
more manageable pieces, a problem takes less effort
and time to solve.

77
Q

describe Modularity

A

modularity is the single attribute of software that allows a program to be intellectually manageable

In almost all instances, you should break the design into many modules, hoping to make understanding easier and as a consequence, reduce the cost required to build the software.

78
Q

State the use of Information Hiding

A

Reduces the likelihood of “side effects”.

Limits the global impact of local design decisions.

Emphasizes communication through controlled interfaces.

Discourages the use of global data.

This leads to encapsulation—an attribute of high quality design

Results in higher quality software.

79
Q

describe Functional Independence

A

Functional independence is achieved by developing modules with “single-minded” function and an “aversion” to excessive interaction with other modules.

80
Q

describe cohesion

A

Cohesion is an indication of the relative functional strength of a
module.

A cohesive module performs a single task, requiring little
interaction with other components in other parts of a program.
Stated simply, a cohesive module should (ideally) do just one
thing.

81
Q

describe coupling

A

Coupling is an indication of the relative interdependence among
modules.

Coupling depends on the interface complexity between modules,
the point at which entry or reference is made to a module, and
what data pass across the interface.

82
Q

describe refactoring

A

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.

When software is refactored, the existing design is examined for
Redundancy
Unused design elements
Inefficient or unnecessary algorithms
Poorly constructed or inappropriate data structures
Any other design failure that can be corrected to yield a better design

83
Q

state the type of design classes

A

Analysis classes are refined during design to become entity classes

Boundary classes are developed during design to create the interface that the user sees and interacts with as the software is used.

Controller classes

83
Q

state the OO Design Concepts

A

Design Classes:
Entity Classes
Boundary Classes
Controller Classes

Inheritance—all responsibilities of a superclass is immediately inherited by all subclasses.

Messages—stimulate some behavior to occur in the receiving
object.

Polymorphism—a characteristic that greatly reduces the effort
required to extend the design.

84
Q

state the Design Class Characteristics

A

Complete - includes all necessary attributes and methods
Primitiveness – each class method focuses on providing one service
High cohesion – small, focused, single-minded classes
Low coupling – class collaboration kept to a minimum

85
Q

describe behavioural modeling

A

The behavioral model indicates how software will respond to external events or stimuli.

To create the model, the analyst must perform the following steps:

Evaluate all use-cases to fully understand the sequence of interaction within the system.

Identify events that drive the interaction sequence and understand how these events relate to specific objects.

Create a sequence for each use-case.

Build a state diagram or sequence diagram for the system.

Review the behavioral model to verify accuracy and consistency.

86
Q

describe the interaction model

A

Composed of four elements:

use-cases

sequence diagrams

state diagrams

a user interface prototype

86
Q

describe sequence diagram

A

Indicates how events cause transitions from object
to object

Represents the flow of events (sequence), and
which objects are involved

The objects are represented by the vertical lines,
and the arrows show the events/messages between
the objects

86
Q

state the requirement modeling for web and mobile apps

A

Content Analysis. The full spectrum of content to be provided by the App is identified, including text, graphics and images, video, and audio data. Data modeling can be used to identify and describe each of the data objects.

Interaction Analysis. How the user interacts with the App is described in detail. Use cases can be developed to provide detailed descriptions of this interaction.

Functional Analysis. The usage scenarios (use-cases) created as part of interaction analysis define the operations that will be applied to App content and imply other processing functions. All operations and
functions are described in detail.

Configuration Analysis. The environment and infrastructure in which the App resides are described in detail.

Navigation Analysis. The overall navigation strategy for the App.

86
Q

describe the configuration model

A

Server-side:

Server hardware and operating system environment must be specified.

Interoperability considerations on the server side must be considered.

Appropriate interfaces, communication protocols, and related collaborative information must be specified.

Client-side:

Browser configuration issues must be identified.

Testing requirements should be defined.

87
Q

describe Patterns for Requirements Modeling

A

Software patterns are a mechanism for capturing domain knowledge in a way that allows it to be reapplied when a new problem is encountered

domain knowledge can be applied to a new problem within the same application domain

the domain knowledge captured by a pattern can be applied by analogy to a completely different application domain.

87
Q

state representation of behavioral modeling

A

The state of each class as the system performs its function, and

The state of the system as observed from the outside as the
system performs its function.

88
Q

describe the function model

A

The functional model addresses two processing elements of
the Web/Mobile App:

User-observable functionality that is delivered by the Web/Mobile App to end-users.

Operations contained within analysis classes that implement behaviors associated with the class.

88
Q

describe the content model

A

Content objects are extracted from use-cases

examine the scenario description for direct and indirect references to content

Attributes of each content object are identified

The relationships among content objects
and/or the hierarchy of content maintained by a Web/Mobile App

88
Q

describe navigation modeling

A

Navigation modeling considers how each user category will navigate from one Web/Mobile App element to another.

The following questions should be considered:

Should certain elements be easier to reach than others? What is the priority for the presentation?

Should certain elements be emphasized to force users to navigate in their
direction?

How should navigation errors be handled?

Should navigation to related groups of elements be given priority over navigation to a specific element?

Should navigation be accomplished via links, via search-based access, or by some other means?

Should certain elements be presented to users based on the context of previous navigation actions?

Should a navigation log be maintained for users?

89
Q

describe Design model

A

Data/class design > Architectural design > Interface Design > Component-level Design

90
Q

state the design model elements

A

Data elements
Architectural elements
Interface elements
Component elements
Deployment elements

91
Q

Describe the architectural elements

A

The architectural model is derived from 3 sources:
information about the application domain for the software to be built
specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand
the availability of architectural patterns and style

92
Q

Describe the data elements

A

Data design – creates a model of data and/or information that is represented at a high level of abstraction

The data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system

93
Q

Describe the Interface Elements

A

Interface is a set of operations that describes the externally observable behavior of a class and provides access to its public operations

Important elements:
- User interface (UI)
- External interfaces to other systems
- Internal interfaces between various design components

Modeled using UML communication diagrams

94
Q

describe the component elements

A

Describes the internal detail of each software component
Defines:
Data structures for all local data objects
Algorithmic detail for all component processing functions
Interface that allows access to all component operations

Modeled using UML component diagrams, UML activity diagrams, pseudocode (PDL), and sometimes flowcharts

95
Q

describe the deployment elements

A

Indicates how software functionality and
subsystems will be allocated within the physical computing environment

Modeled using UML deployment diagrams

Descriptor form deployment diagrams show the computing environment but does not indicate configuration details

Instance form deployment diagrams identifying specific named hardware configurations are
developed during the latter stages of design

96
Q

describe the purpose of data design

A

the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications

97
Q

describe data design

A

Use logical representations of data objects (entity classes) identified during requirements definition and specification

Well-designed data can lead to better program structure and modularity and reduced procedural complexity

Elaborate the classes with implementation details such as data types, processing attributes, relationships

Create a data dictionary to represent the database elements to be developed

98
Q

why is architecture important

A

Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.

The architecture highlights early design decisions that will have a profound impact on all software engineering work that
follows and, as important, on the ultimate success of the system as an operational entity.

Architecture “constitutes a relatively small, intellectually graspable mode of how the system is structured and how its components work together”

99
Q

state the description of the architecture

A

to establish a conceptual framework and vocabulary for use during the design of software architecture

to provide detailed guidelines for representing an architectural description

to encourage sound architectural design practices.

100
Q

Describe Architectural Design

A

The software must be placed in the context

the design should define the external entities that the software interacts with
and the nature of the interaction

101
Q

describe architectural structure

A

Develop a modular program structure and represent the control relationship between modules
Can be represented by:
Hierarchy of modules
Structure chart
Component structure

102
Q

describe architecture review

A

Assess the ability of the software architecture to meet the system quality requirements and identify potential risks

Have the potential to reduce project costs by detecting design problems early

Often make use of experience-based reviews, prototype evaluation, and scenario reviews, and checklists

103
Q

state the architectural considerations

A

Economy – The best software is uncluttered and relies on abstraction to reduce unnecessary detail.

Visibility – Architectural decisions and the reasons for them should be obvious to software engineers who examine the model at a later time.

Spacing – Separation of concerns in a design without introducing hidden dependencies.

Symmetry – Architectural symmetry implies that a system is consistent and balanced in its attributes.

Emergence – Emergent, self-organized behavior and control.

104
Q

describe architectural complexity

A

the complexity of a proposed architecture is assessed by considering the dependencies between components within the architecture

Sharing dependencies represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers.

Flow dependencies represent dependence relationships between producers and consumers of resources.

Constrained dependencies represent constraints on the relative control flow among a set of activities.

105
Q

describe architectural genre

A

Genre implies a specific category within the overall software domain.

106
Q

state the type of architectural styles

A

Data-centered architectures

Data flow architectures

Call and return architectures

Object-oriented architectures

Layered architectures

107
Q

describe ADL

A

Architectural description language (ADL) provides a semantics and syntax for describing a software architecture

Provide the designer with the ability to:
decompose architectural components
compose individual components into larger architectural blocks
represent interfaces between
components.

108
Q

describe architectural patterns

A

Concurrency—applications must handle multiple tasks in a manner that simulates parallelism
Persistence—Data persists if it survives past the execution of the process that created it
Distribution— how systems or components within systems communicate with one another in a distributed environment

109
Q

what are Controller classes designed to manage?

A

Controller classes are designed to manage

the creation or update of entity objects

the instantiation of boundary objects as they obtain information from entity objects

complex communication between sets of objects

validation of data communicated between objects or between the user and the application

110
Q

State the type of mobile apps

A

Native apps
built for a specific mobile operating system, usually iOS or Android.
better performance and a more finely-tuned user interface(UI), and usually need to pass a much stricter development and quality assurance process before they are released

Web apps
Run through a browser (HTML5 or CSS)
User is redirected to a specific web page, and all information is saved on a server-based database
Require a stable connection to be used.

110
Q

describe Mobile App Architecture

A

Presentation layer / Client Layer
User Interface (UI) and User Experience (UX)

Application Layer / Business Layer
logic and rules responsible for data exchange, operations, and workflow regulation

Data Layer
data utilities, service agents, and data access components to support data transactions

111
Q

State the Mobile Development Considerations

A

Multiple hardware and software platforms

Many development frameworks and programming languages.

Many app stores with differing acceptance rules and tool requirements

Short development cycles

User interface limitations

111
Q

State the MobileApp Development
Process Model

A
  1. Formulation
  2. Planning
  3. Analysis
  4. Engineering
  5. Implementation and testing
  6. User evaluation
112
Q

State the MobileApp User Interface Design Considerations

A

Define user interface brand signatures

Focus the portfolio of products

Identify core user stories

Optimize UI flows and elements

Define scaling rules

Create user performance dashboard

Rely on dedicated champion with user interface engineering skills

112
Q

State the MobileApp Design Mistakes

A

Kitchen sink
Inconsistency
Overdesigning
Lack of speed
Verbiage
Non-standard interaction
Help-and –FAQ-itis

112
Q

Best Practices of MobileApp Design

A

Identify the audience
Design for context of use
Recognize line between simplicity is not laziness
Use the platform to its advantage
Allow for discoverability of advanced functionality
Use clear and consistent labels
Clever icons should never be developed at thenexpense of user understanding
Long scrolling forms trump multiple screens

113
Q
A
113
Q
A
113
Q
A
113
Q
A
113
Q
A
113
Q
A
114
Q
A
115
Q
A
115
Q
A
115
Q
A
115
Q
A
115
Q
A
115
Q
A
115
Q
A
115
Q
A
115
Q
A
116
Q
A
116
Q
A
117
Q
A
117
Q
A

Computer Science (6 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions