Brainscape's Knowledge GenomeTM

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


See full index

Software Systems Engineering > SSE - Oral Exam > Flashcards

SSE - Oral Exam Flashcards

1
Q

What are some elements of a PID?

A

o Finding out and defining the problem to be solved
o Give the project a name
o ID the project sponsor (name, contact info)
o ID the business need – problem being solved
o ID the user roles
o ID high level user requirements
o ID the expected value (feasibility analysis)
 Does the system contribute to the overall objectives of the organization?
 Can the system be implemented using current technology and within given cost and schedule?
 Can the system be integrated with our systems which are already in place?
 Tangible and intangible values
o ID any special issues

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

4 ways to determine the expected value (feasibility analysis)

A

 Does the system contribute to the overall objectives of the organization?
 Can the system be implemented using current technology and within given cost and schedule?
 Can the system be integrated with our systems which are already in place?
 Tangible and intangible values

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

What are elements of software requirements?

A

o Finding out and defining what is required (functionality and constraints) of the software
o Analyze current situation precisely as possible
o Deliver what software client needs
o Design UI
o Create domain model (analysis model)
o Create requirements spec (SRS) – ensure correct

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

3 elements of an SRS - ensure correct

A

 Legal document
 Specifications must not be ambiguous, incomplete, or contradictory
 Must not have phrases like “optimal” or “98% complete”

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

Software Engineering definition

A

• An application of the systematic, disciplined, and qualitative approach to the development, operation, and maintenance of software, or the study of.
o Systematic – done or acting to a fixed plan; methodical
o Disciplined – showing a controlled form of behavior or way of working
o Quantifiable – capable of being measured

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

Generic phases of the software lifecycle

A

Identification and Definition
o Define the problem, scope, needs of the customer, the risks, finding

Software requirements
o The functions required, the existing environment, any new software or application needed

Software design and implementation
o Develop and test
o Can be done in iterations
o May include regression testing after each iteration

Software validation
o Ensures the product follows the requirements and specifications outlined in the first step
o Test and regression testing
o Make sure meets the specs and the customer’s needs

Deployment and evolution
      o	Hand over to the customer
      o	Maintenance
      o	Training
      o	Updates or changes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

General principles of the software engineering process (10)

A
  • Determine the value
  • KISS
  • maintain a clear vision
  • keep in mind that someone else will need to understand what you are doing or have done
  • Plan on reuse
  • think before acting
  • Things change
  • Design to meet those changes
  • Plan ahead
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Key actions of Elicitation

A

o Identify the product’s expected user classes and other stakeholders
o Understanding user tasks and goals and the business objective with which those tasks align
o Learning about the environment in which the new product will be used
o Working with individuals who represent each user class to understand their functionality needs and their quality expectations

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

What are some Elicitation methods?

A 
Workshops / JAD - joint application design
Focus groups
Observations
Questionnaires
System interface analysis
User interface analysis
Document analysis
Prototyping
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

System interface analysis

A

o Analysis of other connecting systems
o Identifies data exchange formats
o Identifies functional requirements

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

User interface analysis

A

o Analysis of existing UI
o Identifies user requirements
o Identifies functional requirements
o User-interface requirements

 Special type of non-functional requirements, which addresses the user interface
 Describes the look and feel of the product.
• “The system shall allow user interaction via a touch-screen.”
• “The system shall be judged by 75% of users to be user friendly.”
• “The system shall be ADA compliant.”

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

Document analysis

A

o Examine the documents that are currently being used – they help identify data elements and processes
o Existing documentation can help reveal how systems currently work or what they are supposed to do
o Can help identify functionality that needs to remain, or isn’t used.
o Can help identify how people do their jobs currently, what competitors offer, and what vendors say their software should do

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

4 steps to create use case documentation

A
  1. Identify the actors in the system
  2. Identify use cases
  3. Create use case descriptions
  4. Create scenarios
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Business requirements

A

Are why the implementation is needed. The business needs the organization hopes to achieve

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

User requirements

A

The tasks and goals the user must be able to perform that will provide value to someone. They’re what the user will be able to do

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

Features

A

• These requirements consist of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements

  • A feature is typically a set of requirements
  • They can be represented using a feature tree
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Analysis Model Elements (4)

A

System Model
o Represents a high-level view of the system architecture and the actors

Data Model (class diagram)
o	The domain objects and their relationships
Functional Model (sequence diagram)
o	The operations that transform data
Behavioral Model (state-machine diagram)
o	The behavior of the system
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

System modeling - use case

A
  • Use a package to represent the system
  • Show the actors and their relationships
  • Show the information flow
  • Use stereotypes where appropriate
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

6 signs that requirements are stabilizing when

A
  • Users can’t think of new use cases
  • New scenarios don’t lead to new functional requirements
  • Users are repeating issues already addressed
  • Suggested features, user requirements, or functional requirements are out of scope
  • New requirements are all low priority
  • Developers and testers raise few questions when reviewing requirements
20
Q

High Level Sequence Diagram

A
  • Can be used to analyze user interactions with the system

* Shows the time ordering of the interactions between the user and the system

21
Q

Characteristics of a good requirements document (8)

A
  • Correct – every requirement stated is one that the software shall meet
  • Unambiguous – every requirement has only one interpretation
  • Complete – all significant requirements; definitions of all responses to all input data; full labels and references
  • Consistent – must agree with higher level documents
  • Ranked for importance and/or stability – each requirement has an identifier to indicate the importance or stability of that requirement
  • Verifiability – every requirement is verifiable (testable)
  • Modifiable – the structure and style of the SRS can be changed easily
  • Traceable – the origin of each requirement is clear and facilitates the referencing of each requirement in future documentation
22
Q

Functional requirements

A

o Describes the computational operations of the system in terms of its inputs, outputs, and actors.

o Describes required behavior in terms of required activities, such as reactions to inputs, and the state of each entity before and after an activity occurs. – Pfleeger & Atlee

23
Q

What are Non-functional requirements?

A

o Describes some quality characteristic that the software solution must possess. – Pfleeger & Atlee
o Define the overall qualities or attributes of the resulting system. – K & S
o Taxonomy - Sommerville

24
Q

Formal methods

A

A particular kind of mathematically rigorous techniques for the specification, development and verification of software and hardware systems

  • Involve complex math and proofs rather than ambiguous language
  • A modeling language (e.g. Z) is used, which makes this an expensive and sometimes complicated process
  • The testing involves proofs as part of the testing
  • Best for critical projects such as safety
  • Requires a developer experienced in the language
25
Q

Semi-formal techniques for detailed specifications

A
  • BNF – static description – Extended Backus-Naur form
  • Class Diagrams
  • Storage requirements
  • Pseudocode
  • Decision tables
  • State machine diagrams
  • Activity diagrams
  • Data flow diagrams
26
Q

Why is V&V important?

A

Requirement error costs are high.

Concerned with assuring that the specified requirements define the system that the customer really needs

27
Q

Requirements validation?

People involved?

A

Certifies that the software requirements specification document is an acceptable description of the system to be implemented

People involved: System stakeholders, requirements engineers, and system designers

28
Q

What are 5 Validation techniques?

A

Inspections
o Most widely used technique of requirements validation
o Involve a group of people who read and analyze the requirements, look for problems, meet and discuss the problems, and agree on actions to address these problems

Ambiguity reviews
o	A requirement is ambiguous if there are multiple interpretations of that requirement
	The missing else problem
	Reference ambiguity
	Ambiguities of omission
	Logical operator of ambiguity
	Negation ambiguity
	Ambiguous statements
	Ambiguities of built-in assumptions – don’t assume the knowledge of the reader

Conflict reviews
o Requirements conflict – the stakeholders involved must negotiate to resolve the conflict

Prototyping
o Demonstrate the requirements and help stakeholders discover problems

Test case/scenario development
o Correctness – is this what the client means? Both client and analyst should review

29
Q

How to determine Quality? (5)

A

Reliable - consistency leads to high quality products

Robust – can accommodate unanticipated changes in tools and environment

Productive – produces results

Evolvable – can accommodate new management and organization technologies

Reusable – can be applied across projects and organizations

30
Q

Verification vs Validation

A

Verification
Products of given phase satisfy conditions imposed at start of phase
Are we building the system right? Quality control

Validation
Ensure software meets specs, system testing, acceptance testing
Are we building the right system? Quality assurance

31
Q

Build and fix model

Pros

Cons

A 
•	Basic and starts with getting the needs form the customer
•	The product is then built and if it meet the needs, then gets deployed, otherwise, modifications take place and then checked again until meets the specs
•	Pros
    o	Good for small projects
    o	Simple and easy to use
•	Cons
    o	Not suitable for large projects
    o	Hard to manage
    o	Not organized
32
Q

Evolutionary models?

Examples?

A
  • Are both incremental and iterative
  • The main concept is to build a functional project
  • Then adding changes or functions as needed
  • Iteration means small releases and if the releases are functional, are incremental
Examples
    o	Incremental development
    o	Rational unified development
    o	Prototyping
    o	Spiral method
33
Q

What is CMMI?

A

Capability Maturity Model Integration
• Provides businesses with essential components of effective processes to improve their performance
• Identifies the business’ strengths and weaknesses and provides process changes to turn weaknesses to strengths

34
Q

CMMI

Staged representation

A
  • Provides a predefined set of process areas to define the organizations’ maturity level
  • The maturity level characterizes the organizations’ capabilities and performance
35
Q

CMMI

Continuous representation

A
  • Allows organizations to select a specific process area to improve its capability level
  • The capability level is the organization’s capability and performance in a specific area
36
Q

CMMI

5 maturity levels – classify organizations

A 
1 – Initial
2 – Managed
3 – Defined
4 – Quantitatively managed
5 – Optimizing
37
Q

CMMI

5 capability levels – process inside of organization

A

0 – Incomplete – the product hasn’t started or is incomplete
1 – Performed – the product is started but does not function well. It has some benefit, but not without overspending and heroics
2 – Managed – managed processes for developing – steps are being tracked and are defined. Also includes 0 and 1 functions
3 – Defined – a better understanding of each step and its purpose. Also a better understanding of where it fits with the business needs. Also including 2, 1, & 0 functions
4 – Quantitatively managed – research help define the process and the needs. Stratistics are gathered to ensure positive product outcome. Managed steps with a clear vision for each step. Also includes function of 3, 2, 1, & 0.
• 5 – Optimizing – seeks improve – continual learning of what works and what doesn’t work. Continually searching for more efficient methods using past experience and research to make changes to the process to increase positive project outcome

38
Q

Software

A

set of instructions that tells the computer to accomplish some task

39
Q

Software Crisis

A

difficulty of writing useful and efficient computer programs in the required time. The crisis is due to a hardware evolving at a pace too quick to keep up

40
Q

Symptoms of a software crisis

A
  • Overbudget project
  • Late projects
  • Inefficient software – wasteful or slow
  • Low quality software
  • Software that did not meet the requirements
  • Unmanageable projects
  • Difficult to maintain code
  • Never delivered software
41
Q

Process

A

a series of actions or steps to build a product

42
Q

Product

A

the actual software being created

43
Q

What is the motivation for picking a process for a project

A
  • Reducing costs while increasing quality
  • The product to be correct and efficiento Correct – for each set of inputs, it results in the correct output
    o Efficient – the correct output uses minimum resources where resources is speed vs memory
    o Integrity
    o Reusable
    o Maintainable
44
Q

What are 4 critical levels?

A
  • Mission – loss of finance
  • Safety – leads to loss of safety
  • Production - productivity
  • Life – failure leads to death
45
Q

What are the 3 types of Non-Functional Requirements?

A

Product Requirements
• Usability, Efficiency, Dependability, Security

Organizational Requirements
• Environmental, Operational, Development

External Requirements
• Regulatory, Ethical, Legislative

Software Systems Engineering (1 decks)

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