Software Engineering Flashcards
1
Q
Traits of Successful Software Engineers
A
- Sense of individual responsibility
- Aware of the needs of team members and stakeholders
- Honest about design flaws and offers constructive criticism
- Resilient under pressure
- Sense of fairness
- Attention to detail
- Pragmatic
2
Q
Software Engineer
A
- A software engineer uses engineering principles to plan, design, develop, test, and maintain computer software and mobile applications.
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
4
Q
Software roles
A
- A product
- A vehicle for delivering a product
5
Q
why is Software a product
A
o Delivers computing potential
o Produces, manages, acquires, modifies, displays, or transmits information
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
7
Q
process pattern types
A
stage pattern, task pattern, phase pattern
8
Q
Framework activities
A
o Communication
o Planning
o Modeling
o Construction
o Deployment
9
Q
Umbrella activities
A
- Software Project Tracking and Control
- Risk Management
- Software Quality Assurance
- Technical Reviews
- Measurement
- Software Configuration Management
- Reusability Management
- Work Product Preparation and Production
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
11
Q
Software process
A
an adaptable approach that enables the software team to choose the appropriate set of work actions and tasks
12
Q
polya’s problem solving
A
- Understand the problem
- Plan a solution
- Carry out the plan
- Examine the results for accuracy
13
Q
Software Engineering Domain
A
- System software
- Application software
- Engineering/ Scientific software
- Embedded software
- Product-line software
- AI software
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
15
Q
Software Categories
A
WebApps
Mobile Application
Cloud Computing
Product-Line Software
16
Q
Task set
A
the actual work to be done to accomplish the objectives of a software engineering action
17
Q
Process Pattern Types
A
o Stage pattern
o Task pattern
o Phase pattern
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
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.
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
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
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.
23
Q
describe Prescriptive Process Models
A
- Prescriptive process models advocate an orderly approach to software engineering
24
Q
state the prescriptive process models
A
- The Waterfall Model
- The V-Model
- The Incremental Model
- The Evolutionary Model
25
Prototyping
* 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
26
Agile Process
- 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
27
Types of Agile Process
Extreme Programming (XP)
Industrial XP (IXP)
Scrum
Dynamic Systems Development Method
28
XP Planning
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.
29
XP Design
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”
30
XP Coding
Recommends the construction of a unit test for a store before coding commences
Encourages “pair programming”
31
XP Testing
All unit tests are executed daily
“Acceptance tests” are defined by the customer and executed to assess customer visible functionality
32
Extreme Programming consist of?
XP Planning, XP Design, XP Coding, XP Testing
33
6 new practices of Industrial XP
Readiness assessment
Project community
Project chartering
Test driven management
Retrospectives
Continuous learning
34
features of scrum
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.
35
9 principles of Dynamic Systems Development Method
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.
36
Agile Modeling Principles
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
37
Agile Unified Process Activities
- Modeling
- Implementation
- Testing
- Deployment
- Configuration and project management
- Environment management
38
what is a software prototype?
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.
39
Describe function of analysis model
provide a description of the required informational, functional, and behavioural domains for a computer-based system.
40
elements of analysis model
scenario-based models
class models
behavioral models
flow models
41
list the classes of models that
can be created
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.
42
List the Requirements Modeling Principles
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.
43
what are inception and elicitation?
it provides you with the information
you’ll need to begin writing use cases.
44
Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to:
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.
45
what is use-case
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.
46
describe class-based modeling
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.
47
describe the Manifestations of Analysis Classes
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
48
List Out the Potential Classes
Retained Information.
Needed Services.
Multiple Attributes.
Common Attributes.
Common Operations.
Essential Requirements.
49
Operations can be divided into four broad categories:
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
50
state the function of the CRC model
Class-responsibility-collaborator (CRC) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements.
51
describe inception
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
52
describe Elicitation
elicit requirements from all stakeholders
53
describe elaboration
create an analysis model that identifies data, function and behavioral requirements
54
describe the modeling principles
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.
55
describe specification in requirement engineering
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
56
describe validation in requirement engineering
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
57
what is done during requirement gathering
* 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
58
what is the goal of requirement gathering
1. To identify the problem
2. Propose elements of the solution
3. Negotiate different approaches
4. Specify a preliminary set of solution requirements
59
Describe Quality Function Deployment
* 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
list the elicitation work product
* 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
Describe Non-Functional Requirement
* 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
describe the analysis model
- 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
state the Building the Analysis Model
- 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
describe negotiation
- 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
Requirements monitoring Includes?
- 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
state the functions of requirement analysis
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
state the objectives of requirements analysis
- 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
state the focus of requirements analysis
- 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
describe what a good design should exhibit
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
what is design?
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
Describe Designing Software
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
state Software Engineering Design
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
how to maintain design and quality
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
state the design guidelines
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
list the design principles
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
Describe Separation of Concerns
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
describe Modularity
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
State the use of Information Hiding
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
describe Functional Independence
Functional independence is achieved by developing modules with "single-minded" function and an "aversion" to excessive interaction with other modules.
80
describe cohesion
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
describe coupling
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
describe refactoring
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
state the type of design classes
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
state the OO Design Concepts
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
state the Design Class Characteristics
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
describe behavioural modeling
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
describe the interaction model
Composed of four elements:
use-cases
sequence diagrams
state diagrams
a user interface prototype
86
describe sequence diagram
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
state the requirement modeling for web and mobile apps
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
describe the configuration model
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
describe Patterns for Requirements Modeling
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
state representation of behavioral modeling
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
describe the function model
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
describe the content model
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
describe navigation modeling
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
describe Design model
Data/class design > Architectural design > Interface Design > Component-level Design
90
state the design model elements
Data elements
Architectural elements
Interface elements
Component elements
Deployment elements
91
Describe the architectural elements
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
Describe the data elements
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
Describe the Interface Elements
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
describe the component elements
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
describe the deployment elements
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
describe the purpose of data design
the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications
97
describe data design
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
why is architecture important
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
state the description of the architecture
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
Describe Architectural Design
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
describe architectural structure
Develop a modular program structure and represent the control relationship between modules
Can be represented by:
Hierarchy of modules
Structure chart
Component structure
102
describe architecture review
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
state the architectural considerations
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
describe architectural complexity
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
describe architectural genre
Genre implies a specific category within the overall software domain.
106
state the type of architectural styles
Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures
107
describe ADL
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
describe architectural patterns
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
what are Controller classes designed to manage?
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
State the type of mobile apps
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
describe Mobile App Architecture
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
State the Mobile Development Considerations
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
State the MobileApp Development
Process Model
1. Formulation
2. Planning
3. Analysis
4. Engineering
5. Implementation and testing
6. User evaluation
112
State the MobileApp User Interface Design Considerations
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
State the MobileApp Design Mistakes
Kitchen sink
Inconsistency
Overdesigning
Lack of speed
Verbiage
Non-standard interaction
Help-and –FAQ-itis
112
Best Practices of MobileApp Design
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
113
113
113
113
113
114
115
115
115
115
115
115
115
115
115
116
116
117
117
