Test 1 Flashcards

1
Q

What is software?

A

(1) Instructions: (computer programs) that when executed provide desired features, function, and
performance;

(2) Data Structures: that
enable the programs to adequately manipulate information and

(3) Documentation: that describes the operation and use of the programs.

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

The IEEE definition of software engineering is:

A

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

(2) The study of approaches as in (1).

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

What is the layered technology of software engineering?

A

1: Tools
2: Methods
3: Process Model
4: A “Quality” Focus

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

What is process framework?

A

A structured approach that defines the steps, tasks, and activities involved in software development.

It includes Framework/Umbrella Activities

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

What are the main tasks included in Framework Activities?

A

1: Communication

2: Planning

3: Modeling
*Analysis of requirements
*Design

4: Construction
*Code generation
*Testing

5: Deployment

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

What are the main tasks included in 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
7
Q

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

A

Standard CMMI Assessment Method for Process Improvement
(SCAMPI)

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

What provides a diagnostic technique
for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment [Dun01]?

A

CMM-Based Appraisal for Internal Process
Improvement (CBA IPI)

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

What standard 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. [ISO08]

A

SPICE—The SPICE (ISO/IEC15504)

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

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

A

ISO 9001:2000 for Software

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

What is the Manifesto for Agile Software Development

A

“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
*Individuals and interactions over processes
and tools
*Working software over comprehensive
documentation
*Customer collaboration over contract
negotiation
*Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left
more.”

  • Kent Beck et al
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What is “Agility”?

A
  • Effective (rapid and adaptive) response to
    change
  • Effective communication among all
    stakeholders
  • Drawing the customer onto the team
  • Organizing a team so that it is in control of the
    work performedYielding …
  • Rapid, incremental delivery of software
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What are the Agility Principles

A
  1. Our highest priority is to satisfy the customer
    through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in
    development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of
    conveying information to and within a development team is face–to–face conversation.
  7. Working software is the primary measure of
    progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done – is essential.
  11. The best architectures, requirements, and
    designs emerge from self–organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What is Extreme Programming (XP)?

A

The most widely used agile process, originally proposed by Kent Beck.

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

What is included in XP Planning?

A

Begins with the creation of “user stories”

  * Agile team assesses each story and assigns 
      a cost

  * Stories are grouped to for 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
16
Q

Describe XP Design.

A
  • Follows the KISS principle
  • Encourage the use of CRC cards
  • For difficult design problems, suggests the creation of “spike solutions”—a design prototype
  • Encourages “refactoring”—an iterative refinement of the internal program design
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Describe 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
18
Q

Describe 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
19
Q

What was originally proposed by Schwaber and Beedle?

20
Q

List the distinguishable 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
21
Q

List the Engineering Requirements

A

1) Inception
2) Elicitation
3) Elaboration
4) Negotiation
5) Specification
7) Validation
8) Requirements management

22
Q

Inception…

A

When you ask a set of questions that establish:

  • Basic understanding of the problem
  • The people who want a solution
  • The nature of the solution that is desired, and
  • The effectiveness of preliminary
    communication and collaboration between
    the customer and the developer
23
Q

Elicitation…

A

elicit requirements from all stakeholders

24
Q

Elaboration…

A

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

25
Negotiation...
agree on a deliverable system that is realistic for developers and customers
26
Specification can be....
* A written document * A set of models * A formal mathematical * A collection of user scenarios (use-cases) * A prototype
27
Validation is a review mechanism that looks for......
* Errors in content or interpretation * Areas where clarification may be required * Missing information * Inconsistencies (a major problem when large products or systems are engineered) * Conflicting or unrealistic (unachievable) requirements
28
Inception includes...
 Identify stakeholders * “who else do you think I should talk to?”  Recognize multiple points of view  Work toward collaboration  The first questions * Who is behind the request for this work? * Who will use the solution? * What will be the economic benefit of a successful solution * Is there another source for the solution that you need?
28
Eliciting Requirements includes...
 meetings are conducted and attended by both software engineers and customers  rules for preparation and participation are established  an agenda is suggested  a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting  a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used  the goal is * To identify the problem * Propose elements of the solution * Negotiate different approaches, and * Specify a preliminary set of solution requirements
29
Elicitation Work Products includes...
 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 (preferably organized by function) 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.
30
List the Specific Functional Requirements
 Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?  Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?  Are all output formats specified for web pages, reports, and so on?  Are all the external hardware and software interfaces specified?  Are all the external communication interfaces specified, including handshaking, error- checking, and communication protocols?  Are all the tasks the user wants to perform specified?  Is the data used in each task and the data resulting from each task specified?
31
List the Non-Functional Requirements
 Non-Functional Requirement (NFR) – quality attribute, performance attribute, security attribute, or general system constraint. A two- phase process is used to determine which NFR’s are compatible:  The first phase is to create a matrix using each NFR as a column heading and the system SE guidelines a row label  The second phase is for the team to 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
32
List the Specific Non-Functional (Quality) Requirements
 Is the expected response time, from the user's point of view, specified for all necessary operations?  Are other timing considerations specified, such as processing time, data-transfer rate, and system throughput?  Is the level of security specified?  Is the reliability specified, including the consequences of software failure, the vital information that needs to be protected from failure, and the strategy for error detection and recovery?  Is maximum memory specified?  Is the maximum storage specified?  Is the maintainability of the system specified, including its ability to adapt to changes in specific functionality, changes in the operating environment, and changes in its interfaces with other software?  Is the definition of success included? Of failure?
33
What questions should you ask in regard to the Requirements of Quality?
 Are the requirements written in the user's language? Do the users think so?  Does each requirement avoid conflicts with other requirements?  Are acceptable trade-offs between competing attributes specified-for ex-ample, between robustness and correctness?  Do the requirements avoid specifying the design?  Are the requirements at a fairly consistent level of detail? Should any requirement be specified in more detail?  Should any requirement be specified in less detail?  Are the requirements clear enough to be turned over to an independent group for construction and still be understood?  Is each item relevant to the problem and its solution? Can each item be traced to its origin in the problem environment?  Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?  Are all possible changes to the requirements specified, including the likely-hood of each change?
34
What are the requirements to Completeness?
 Where information isn't available before development begins, are the areas of incompleteness specified?  Are the requirements complete in the sense that if the product satisfies every requirement, it will be acceptable?  Are you comfortable with all the requirements? Have you eliminated requirements that are impossible to implement and included just to appease your customer or your boss?
35
What are the Validating Requirements
 Is each requirement consistent with the overall objective for the system/product?  Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?  Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?  Is each requirement bounded and unambiguous?  Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?  Do any requirements conflict with other requirements? Is each requirement achievable in the technical environment that will house the system or product?  Is each requirement testable, once implemented?  Does the requirements model properly reflect the information, function and behavior of the system to be built.  Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.  Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?
36
Requirements Modeling includes:
 Scenario-based * System from the user’s point of view  Data * Shows how data are transformed inside the system  Class-oriented * Defines objects, attributes, and relationships  Flow-oriented * Shows how data are transformed inside the system  Behavioral * Shows the impact of events on the system states
37
What are Use-Cases?
a scenario that describes a “thread of usage” for a system
38
In Use-Cases, what are actors?
actors represent roles people or devices play as the system functions
39
In Use-Cases, what are users?
users can play a number of different roles for a given scenario
40
What questions should you ask when identifying actors and goals.
 What computers, sub-systems, and people will drive our system? (actors) *examples: Customer, Clerk, Corporate Mainframe  what does each actor need our system to do? * each need may show up as a trigger to a use-case
41
When identifying actors and foals what is the result.
result: a list of use cases, a sketch of the system * Short, fairly complete list of usable system function * Can now draw UML use case diagram for reference
42
Consider software to run a cell phone, what are the use cases vs. the internal features?
Use Cases: * Call someone * Receive a call * Send a message * Memorize a number -Point of view: user Internal Functions: * Transmit / receive data * Energy (battery) * User I/O (display, keys, ...) * Phone-book mgmt. -Point of view: developer / designer
43
What are the qualities of a good use case.
 starts with a request from an actor to the system  ends with the production of all the answers to the request  defines the interactions (between system and actors) related to the function  takes into account the actor's point of view, not the system's  focuses on interaction, not internal system activities  doesn't describe the GUI in detail  has 3-9 steps in the main success scenario  is easy to read
44
What are UML use case diagrams?
 use cases can be drawn as diagrams, with:  actors as stick-men, with their names below  use cases as ellipses with their names below or inside  association indicated by lines, connecting an actor to a use case in which that actor participates  use cases can be connected to other cases that they use / rely on
45
What are the pros and cons of use cases.
pro:  they hold functional requirements in an easy-to-read text format  they make a good framework for non- functional requirements & project scheduling con:  they show only the functional reqs  design is not done only in use case units