Brainscape's Knowledge GenomeTM

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


See full index

Software Systems Engineering > Final > Flashcards

Final Flashcards

1
Q

Explain software crisis

A

It refers to the difficulty of writing useful and efficient computer programs within the required time. It was caused by the rapid increases in computer power and the complexity of the problems that arose but existing methods were not sufficient to address them.

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

Define software engineering (IEEE)

A

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

  • Systematic - done or acting to a fixed plan; methodical
  • Disciplined - showing a controlled form of behavior or way of working
  • Quantifiable - capable of being measured
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Explain the motivations for selecting a software development process

A
  • The criticality of the software
  • The desired release date
  • Development team size
  • Project requirements
  • Project size
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Describe the various types of software criticality

A
  • Life-critical or safety-critical software systems
    • Failure may lead to death or injury
  • Mission-critical software systems
    • Failure may lead to financial loss
  • Productivity-critical software systems
    • Failure may lead to loss of productivity
  • Non-critical software systems
    • Failure may lead to minor inconveniences
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Describe the PID phase

A

Used to identify the business value of the system

  1. Give the project a name
  2. Identify the project sponsor(s)
    • Name
    • Contact Information
  3. Identify the business need - what is the problem being solved
  4. Identify the user roles
  5. Identify high-level user requirements
    • Short, focused study that aims to answer several questions
      • Does the system contribute to the overall objectives of the organization
      • Can the system be implemented using current technology and within a given cost and schedule
      • Can the system be integrated with other systems which are already in plac
  6. Identify any special issues
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Describe the software requirements phase

A
  • Analyze the client’s current situation as precisely as possible
  • Determine what software the client needs
  • Design the user interface
  • Create domain model, e.g., analysis model
  • Create the requirements specification, e.g., Software Requirements Specification (SRS)
  • Ensure that the requirements are correct
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Describe the software design and implementation phase

A

Software Design

  • Major activities
    • Architectural design
    • Detailed design
    • System interface design
  • Model produced
    • Design model
  • Documents Produced
    • Design document

Implementation

  • Coding and testing of individual software components
  • Unit and integration testing of software components
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Describe the validation phase

A

Software Validation

  • Ensuring that the software meets the specifications
  • System testing
  • Acceptance testing

Verification

  • The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase

Validation

  • The process of evaluating a system or component during or at the end of the development process to determine whether the system satisfied the specified requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Name, explain, and describe the waterfall models

A
  • First published model of the software development process by Royce in 1970
  • Sometimes called the classic life cycle
  • Suggests a systematic, sequential approach to software development
  • Suggests separate, process stages (Requirements, Design, Implementation, Testing, Maintenance)

Advantages

  • Simple and easy to use
  • Practiced for many years and people have much experience with it
  • Easy to manage, enforced, disciplined approach
  • Facilitates allocation of resources
  • Works well for smaller projects where requirements are very well understood

Disadvantages

  • Requirements must be known up front
  • No feedback of system by stakeholders until after testing phase
  • Major problems with the system are not discovered until late in the process
  • Inefficient use of resources
  • Real projects rarely follow the sequential flow that this model proposes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Name, explain, and describe the evolutionary models

A

Based on the idea of developing an initial implementation, exposing this to user comment and refining it through many versions until an adequate system is developed. These models are both iterative and incremental in nature.

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

Name, explain, and describe the agile models

A

Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.

These methods:

  • Focus on the code rather than the specification
  • Are based on an iterative approach to software development
  • Are intended to deliver working software quickly and evolve this quickly to meet changing requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Explain requirements elicitation

A

The process of using various techniques to gather requirements from a client.

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

Name and explain the elements of an elicitation plan

A
  • Elicitation objectives
  • Elicitation strategy and techniques
    • Decide which techniques to use for each stakeholder group
  • Schedule and resource estimates
    • Identify customer and developer participants
    • Effort and calendar time required
  • Expected artifacts to be created
  • Elicitation risks
    • Identify the factors that may impede elicitation efforts
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Explain how to perform interviews

A
  • Can be performed one-on-one or with a small group of stakeholders
  • They are an effective way to elicit requirements without taking too much stakeholder time because you meet with people to discuss only the specific requirements that are important to them
  • Are helpful to separately elicit requirements from people in preparation for workshops where those people come together to resolve any conflicts.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Explain how to perform workshops

A
  • Facilitated requirements-elicitation workshops that permit collaboration between analysts and customers
  • Can be used to explore user needs and to draft requirements documents
  • Sometime call Joint Application Design, or JAD, sessions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Explain how to perform observations

A
  • Watching users perform their business tasks establishes a context for their potential use of a new application
  • Simple process flow diagrams can depict the steps and decisions involved and show how different user groups interact
  • Documenting the business process flow will help you identify requirements for a solution that’s intended to support that process
17
Q

Explain how to perform document analysis

A
  • Existing documentation can help reveal how systems currently work or what they are supposed to do
  • Documentation includes any written information about current systems, business processes, requirements specifications, competitor research, and COTS (commercial off-the-shelf) package user manuals
  • Reviewing and analyzing the documents can help identify functionality that needs to remain, functionality that isn’t used, how people do their jobs currently, what competitors offer, and what vendors say their software should do
18
Q

Explain business requirement

A

These requirements describe why the organization is implementing the system. That is, the business benefits the organization hopes to achieve.

19
Q

Explain user requirements

A

These requirements describe goals or tasks the users must be able to perform with the product that will provide value to someone. They describe what the user will be able to do with the system.

20
Q

Explain functional requirements

A

These requirements specify the behaviors the product will exhibit under specific conditions. They describe what the developers must implement to enable users to accomplish their tasks (user requirements).

21
Q

Explain nonfunctional requirements

A

These requirements specify constraints on the services or operations offered by the system.

22
Q

Explain quality attribute

A

These requirements describe the product’s characteristics in various dimensions that are important to either the user or to developers and maintainers, e.g., performance, safety, availability, and portability.

23
Q

Explain external interface requirement

A

These requirements describe connections to other software systems, hardware components, users, and communication interfaces.

24
Q

Explain design and implementation constraint

A

These requirements impose restrictions on the options available to developers

25
Q

Explain actors

A
  • Set of roles that users play
  • External systems
  • Try to use actual names from the problem domain
26
Q

Explain use cases

A
  • Describes the system/s behavior under various conditions as the system responds to a request from one of its stakeholders
  • Use a simple verb phrase for the same
27
Q

Explain requirements V&V

A
  • Are we building the system right?
    • Verification (quality control)
  • Are we building the right system
    • Validation (quality assurance)
  • Difference is unimportant
28
Q

Validation techniques

A
  • Inspections
  • Ambiguity reviews
  • Conflict reviews
  • Prototyping
  • Test case/scenario development
29
Q

Explain inspections

A
  • Most widely used technique of requirements validation
  • Involves 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
30
Q

Types of ambiguity

A
  • Missing “else” problem
    • If something happens, no else
  • Reference ambiguity
    • What is the requirement referring to?
  • Omission
  • Logical operator ambiguity
  • Negation ambiguity
  • Built-in assumptions
  • “etc.”
  • “i.e.” and/or “e.g.” confusion
  • Boundary ambiguity
    • 1-4; inclusive or exclusive?
31
Q

Explain conflict reviews

A

Making sure requirements do not conflict with one another

32
Q

Explain prototyping

A
  • Prototypes for requirements validation demonstrate the requirements and help stakeholders discover problems
  • If the prototype was not developed for the requirement elicitation process, it is probably not cost-effective to develop one only for requirements validation
33
Q

Explain test case/scenario development

A
  • Each requirement should be testable
    • It should be possible to define tests to check whether or not that requirement has been met

Software Systems Engineering (4 decks)

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