CSE3310 Midterm 1

studied byStudied by 143 people
5.0(2)
Get a hint
Hint

Software Engineering

1 / 105

flashcard set

Earn XP

Description and Tags

106 Terms

1

Software Engineering

Engineering discipline that is concerned with all aspects of software production from conception to operation and maintenance

New cards
2

Differences between CS and SE

CS: Theories and methods/fundamentals of software systems

SE: Practicalities of developing software

New cards
3

Confidentiality

Engineers should respect confidentiality irrespective of whether or not an agreement was signed

New cards
4

Competence

Not knowingly accept work that is outside their skill level

New cards
5

4 fundamental activities of SE

  1. Requirements/specifications

  2. Dev/Design and Implementation

  3. Verification/Validation

  4. Maintenance/Evolution

New cards
6

Requirements/specification

Where customers and engineers define software to be produced and constraints

New cards
7

Development/Design and Implementation

where software is designed and programmed

New cards
8

Verification/Validation

Where software is checked to ensure that it’s what’s required

New cards
9

Maintenance/Evolution

where software is modified to reflect changing customer and market requirements

New cards
10

Why not base project on prototype?

Prototype is to simply answer a question, not part of whole project since it’s build quickly w/ little care

New cards
11

Work products used for/created from REQUIREMENTS

artifacts, specifications

New cards
12

Work products used for/created from IMPLEMENTATION

source code

New cards
13

Work products used for/created from VALIDATION

Test cases, software w/ defects removed

New cards
14

Work products used for/created from EVOLUTION

artifacts, specifications, source code, test cases, software w/ defects removed

New cards
15

Steps of waterfall diagram

  1. Requirements definition

  2. System & software design

  3. Implementation and unit testing

  4. Integration and system testing

  5. Operation and maintenance

New cards
16

Waterfall

plan driven process that requires the previous step to finish b4 starting next one

New cards
17

incremental

based on idea of developing initial implementation, getting feedback, and evolving versions until required system has been developed

New cards
18

integration and config

Dev process focuses on configuring components for use in new setting and integrating them to the system.

New cards
19

Waterfall Pros

  • Good for hardware development/high manufacturing costs.

  • Predictable

  • Good for stuff that requires planning

  • Good for minimal change

New cards
20

Waterfall Cons

  • Does not adapt to change well

  • Lots of documentation

  • If a step is incorrect, redo from said step

  • No visibility

  • Product isn’t ready until after completion

New cards
21

Incremental Pros

  • Parts are working earlier

  • Deliver to customer earlier

  • Get feedback during the design

  • Not as document heavy

  • Better than a waterfall approach for systems whose requirements are likely to change during the development process

New cards
22

Incremental Cons

  • Refactoring problems: Redo structure of the code

  • Lots of rework

  • Erosion in clarity and quality

  • More requirements

  • System structure tends to degrade as new increments are added

New cards
23

Given these: which SDLC best describes this?

  • Requirements known

  • Requirements unchanged

  • Customer desire

  • No visibility

Waterfall method

New cards
24

Given these: which SDLC best describes this?

  • Most functionality

  • Short budget

  • Short schedule

Integration and Configuration

New cards
25

Prototype

An early version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions.

New cards
26

V-Model (photo)

<p></p>
New cards
27

V-Model

shows the software validation activities that correspond to each stage of the waterfall process model.

New cards
28

Requirement

Fundamental to software engineering endeavors. Determine what the customer needs/wants and a basis of your product. Are what the functionality a program needs to have.

New cards
29

Functional Requirement

Something that the system will be able to do. Can you test it?

New cards
30

Nonfunctional Requirement

How the system will do something, and how well it does it.

  1. applies to entire system

  2. not in place

  3. ility: readability, availability, security, efficiency

New cards
31

Elicitation and analysis

Range of system stakeholders to find out about the application domain, services that the system should provide, required system performance, hardware constraints, other systems, etc.

New cards
32

Stages of elicitation and analysis

  • Requirements Discovery

  • Requirements classification and organization

  • Requirements prioritization and negotiation

  • Requirements specification

New cards
33

Validation

Concerned with demonstrating that the requirements define the system that the customer really wants

  • Requirements error costs are high so validation is very important.

    • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

  • Prototyping is an example of this

New cards
34

Management

Process of managing changing requirements during the requirements engineering process and system development.

  • New requirements emerge as a system is being developed and after it has gone into use.

New cards
35

Critiques for requirements

a. Vague

b. Conflicting

c. Not written as a requirement

d. Not testable

e. Non precise

f. More than one requirement in one sentence

New cards
36

Purpose of software process

The activities and processes that are involved in developing and evolving a software system.

New cards
37

Steps of SEI Capability Maturity Model (SEICMM)

  1. Initial

  2. Managed

  3. Defined

  4. Quantitatively managed

  5. Optimizing

    Single arrow from each step pointing to the next one

New cards
38

SEICMM Initial

no process at all, free

New cards
39

SEICMM Managed

Basic schedule and planning, free

New cards
40

SEICMM Defined

Software process is defined, training of individuals

New cards
41

SEICMM Quantitatively managed

Measuring thing and use results to make things better, expensive

New cards
42

SEICMM Optimizing

Able to handle large changes with minimal hiccups, expensive

New cards
43

Stakeholder

Include anyone who is affected by the system in some way and so anyone who has a legitimate interest in it.

New cards
44

user requirements

  1. Client managers

  2. system end users

  3. client engineers

  4. contractor managers

  5. system architects

New cards
45

System requirements

  1. System end users

  2. client engineers

  3. system architects

  4. software developers

  5. stakeholders

New cards
46

problems with natural language specification

  1. Lack of clarity

    1. Precision is hard w/o making doc hard to read

  2. Requirements confusion

    1. Functional and Non-functional requirements tend to be mixed-up.

  3. Requirements amalgamation

    1. Several different requirements may be expressed together.

New cards
47

advantages of natural language specification

  1. Expressive, intuitive, universal

  2. Understandable by users and customers easily

New cards
48

4+1 Model (image)

knowt flashcard image
New cards
49

Way of writing system requirement specs: Natural language

The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.

New cards
50

Way of writing system requirement specs: Structured Natural Language

The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.

New cards
51

Way of writing system requirement specs: Graphical Notation

Graphical models, supplemented by text annotations, are used to define the functional requirements for the system. UML (unified modeling language) use case and sequence diagrams are commonly used.

New cards
52

Way of writing system requirement specs: Mathematical Notation

These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want, and they are reluctant to accept it as a system contract.

New cards
53

Requirements Validation checks

Validity, Consistency, Completeness, Realism, Verifiability

New cards
54

Requirements Validation checks (in depth)

  • Requirements reviews

    • Systematic manual analysis of the requirements

    • Verifiability, Traceability, Comprehensibility

  • Prototyping

  • Test-case generation

New cards
55

Requirements spreadsheet

never reuse requirements ID, each one has a unique ID (UID)

New cards
56

How to determine if requirement ID is active

active flag will be on, or off (strikethrough), test cases for each of the requirements at the bottom

New cards
57

Sequences diagram

Shows interactions between actors and the system and between system components.

<p>Shows interactions between actors and the system and between system components.</p>
New cards
58

Class diagram

Shows the object classes in the system and the associations between these classes

Static type of diagram

<p>Shows the object classes in the system and the associations between these classes</p><p>Static type of diagram</p>
New cards
59

Use case diagram

Show interactions between system and it’s environment.

<p>Show interactions between system and it’s environment.</p>
New cards
60

Be familiar with the following diagrams.

Use Case, Sequence, Class, Generalization, Aggregation, State, Process, Data Flow

New cards
61

context diagram

Illustrates the separational context of a system

Shows what lies outside of system boundaries

based on perspective of center system

<p>Illustrates the separational context of a system</p><p>Shows what lies outside of system boundaries</p><p>based on perspective of center system</p>
New cards
62

Generalization diagram

Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, etc) and learn the characteristics of these classes. (OOP)

<p>Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, etc) and learn the characteristics of these classes. (OOP)</p>
New cards
63

Aggregation diagram

shows how classes that are collections are composed of other classes

similar to part-of relationship in semantic data models

<p>shows how classes that are collections are composed of other classes</p><p>similar to part-of relationship in semantic data models</p>
New cards
64

State diagram

shows how system reacts to internal and external events

<p>shows how system reacts to internal and external events</p>
New cards
65

Process diagram

reveal how system is used in broader business processes

<p>reveal how system is used in broader business processes</p>
New cards
66

Dataflow diagram

Tracking and documenting how data associated with a particular process moves through the system help analysts and designers understand what is going on in the process

<p>Tracking and documenting how data associated with a particular process moves through the system help analysts and designers understand what is going on in the process</p>
New cards
67

When to use: context diagram

Simple, shows dependencies and connections to others systems. Are good to show to managers and clients who don't know about the inner workings of the system.

New cards
68

When to use: use case diagram

Demonstrate the different ways that a user might interact with a system.

New cards
69

When to use: sequence diagrams

where it is important to understand how different objects or components interact with each other over time

New cards
70

When to use: class diagrams

When developing an object oriented system model. Objects are to be used to represent something in the real world

New cards
71

When to use: generalization diagrams

Specifically represent the inheritance hierarchy of classes in a system

New cards
72

When to use: aggregation diagrams

A big object that uses smaller objects but the smaller objects are independent of that big object and can be amongst different big objects.

New cards
73

When to use: state diagrams

Used to show system states and events that cause transitions from one state to another.

New cards
74

When to use: process diagrams

Whenever there is a need to understand, analyze, design, document, or communicate a process. Visualize the steps involved when designing a new process and the relationships between the steps.

New cards
75

When to use: data flow diagrams

Used to show how data flows within the system between processing steps. Simple and intuitive and so are more accessible to stakeholders.

New cards
76

Software Architecture

Concerned with understanding how a software system should be organized and designing the overall structure of the system.

Affects the performance, robustness, distributability, and maintainability of a system

New cards
77

Architectural Quote

"architecture is where non functional requirements are realized"

New cards
78

Why is architecture important?

  • Architecture is where non-functional requirements are realized.

  • The critical link between design and requirements engineering.

  • Identifies main components in a system and relationships between them.

  • Output is an architectural model that describes how a system is organized.

New cards
79

Example of non functional requirements being met by architecture

If system has to be fast, the architecture has to have low overhead.

New cards
80

Layered Architecture

  • Each layer only talks to the layer directly above and directly below it.

  • Easy to switch layers out, only affects adjacent layers.

  • Able to change one layer without touching other layers.

<ul><li><p>Each layer only talks to the layer directly above and directly below it.</p></li><li><p>Easy to switch layers out, only affects adjacent layers.</p></li><li><p>Able to change one layer without touching other layers.</p></li></ul>
New cards
81

Model View Controller

  • Breaks software into 3 pieces (Model, View, and Controller)

  • View is highly changeable. Can easily swap the interface without touching anything else.

<ul><li><p>Breaks software into 3 pieces (Model, View, and Controller)</p></li><li><p>View is highly changeable. Can easily swap the interface without touching anything else.</p></li></ul>
New cards
82

Repository Architecture

  • Generally used for databases.

  • Everything (data/info) goes into a center project repository.

  • Minimizes coupling, components are independent of each other.

  • Single point of failure.

  • May be inefficient.

<ul><li><p>Generally used for databases.</p></li><li><p>Everything (data/info) goes into a center project repository.</p></li><li><p>Minimizes coupling, components are independent of each other.</p></li><li><p>Single point of failure.</p></li><li><p>May be inefficient.</p></li></ul>
New cards
83

Client Architecture

  • Client connects to many servers (many to one).

  • Each service is a single point of failure, but multiple servers allows it to be robust.

  • Modularity benefits and fault tolerant.

<ul><li><p>Client connects to many servers (many to one).</p></li><li><p>Each service is a single point of failure, but multiple servers allows it to be robust.</p></li><li><p>Modularity benefits and fault tolerant.</p></li></ul>
New cards
84

Pipe and Filter Architecture

  • Output of 1 stage goes in as the input of another stage.

  • Batch processing.

  • Really easy to add another stage of processing, you only need to know what goes in and what is going out.

  • Not good for things that demand responsiveness.

  • Compilers are an example.

<ul><li><p>Output of 1 stage goes in as the input of another stage.</p></li><li><p>Batch processing.</p></li><li><p>Really easy to add another stage of processing, you only need to know what goes in and what is going out.</p></li><li><p>Not good for things that demand responsiveness.</p></li><li><p>Compilers are an example.</p></li></ul>
New cards
85

types of client architecture

  • Thin: Client doesn’t have a lot of code/functionality

  • Thick/Fat: More functionality (more JavaScript in a webpage), more responsive

New cards
86

4+1 Diagram: Logical View

Concerned with the functionality that the system provides to end-users.

Class and state diagrams

End user functionality: connects to scenarios and development and process view

<p>Concerned with the functionality that the system provides to end-users.</p><p>Class and state diagrams</p><p>End user functionality: connects to scenarios and development and process view</p>
New cards
87

4+1 Diagram: Development view

Illustrates a system from a programmer's perspective and is concerned with software management.

Package and component diagram

Programmers, software development: connects to scenarios and physical view

<p>Illustrates a system from a programmer&apos;s perspective and is concerned with software management.</p><p>Package and component diagram</p><p>Programmers, software development: connects to scenarios and physical view</p>
New cards
88

4+1 Diagram: process view

Deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the run time behavior of the system.

Addresses concurrency, distribution, integrator, performance, and scalability, etc.

Sequence/communication/activity diagram

Integrators, performance scalability: connects to scenarios and physical view

<p>Deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the run time behavior of the system.</p><p>Addresses concurrency, distribution, integrator, performance, and scalability, etc.</p><p>Sequence/communication/activity diagram</p><p>Integrators, performance scalability: connects to scenarios and physical view</p>
New cards
89

4+1 Diagram: Physical view

PoV of a system’s engineer. Concerned with the topology of software components on the physical layer as well as the physical connections between these components.

Deployment diagram

System engineers, topology, communications: connects to scenarios

<p>PoV of a system’s engineer. Concerned with the topology of software components on the physical layer as well as the physical connections between these components.</p><p>Deployment diagram</p><p>System engineers, topology, communications: connects to scenarios</p>
New cards
90

3 tiered layered web app architecture

In descending order: Display, business logic, database

Display usually at top and database at bottom, rest are interchangeable

New cards
91

Starting point

Base initial design on a generic application architecture. Specialize later for the system being developed.

New cards
92

Design checklist

compare design to generic app architecture, check for consistency

New cards
93

Organizing work

Assign work to people to implement different components within the architecture.

New cards
94

Accessing components for reuse

If there are components that may be reused, compare with generic structures to see whether there are comparable components in the application architecture.

New cards
95

Vocab for discussion

Use the concepts identified in the generic architecture to discuss and compare applications.

New cards
96

4+1 Diagram: Scenarios

Serve as a starting point for tests of an architecture prototype.

Use case diagram

Every other part connects to this, the “+1” part of the 4+1 diagram

<p>Serve as a starting point for tests of an architecture prototype.</p><p>Use case diagram</p><p>Every other part connects to this, the “+1” part of the 4+1 diagram</p>
New cards
97

Integration & Config Pros

  • Cheaper

  • Available right away (faster)

  • Reliable

New cards
98

Integration & Config Cons

  • Does not do exactly what you want it to do.

  • Evolution of the system is harder to do, some components are not controlled by you, so newer versions may not be in sync with what you want to accomplish.

New cards
99

Step 1 of 4 Fundamental Activities of SE

Requirements/Specifications

New cards
100

Step 2 of 4 Fundamental Activities of SE

Development/Design and Implementation

New cards

Explore top notes

note Note
studied byStudied by 5 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 40 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 176 people
Updated ... ago
5.0 Stars(3)
note Note
studied byStudied by 15 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 11 people
Updated ... ago
5.0 Stars(2)
note Note
studied byStudied by 17 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 17 people
Updated ... ago
5.0 Stars(1)
note Note
studied byStudied by 19 people
Updated ... ago
5.0 Stars(1)

Explore top flashcards

flashcards Flashcard35 terms
studied byStudied by 1 person
Updated ... ago
5.0 Stars(1)
flashcards Flashcard20 terms
studied byStudied by 18 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard76 terms
studied byStudied by 8 people
Updated ... ago
5.0 Stars(2)
flashcards Flashcard25 terms
studied byStudied by 5 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard21 terms
studied byStudied by 1 person
Updated ... ago
5.0 Stars(1)
flashcards Flashcard20 terms
studied byStudied by 5 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard37 terms
studied byStudied by 29 people
Updated ... ago
5.0 Stars(1)
flashcards Flashcard43 terms
studied byStudied by 36 people
Updated ... ago
5.0 Stars(3)