Brainscape's Knowledge GenomeTM

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


See full index

Software Engineering > Week 1 > Flashcards

Week 1 Flashcards

1
Q

Model Evaluation criteria

A

Some criteria for evaluating models
* Risk Management
* Quality / cost control
* Visibility of progress
* Customer involvement
Overall aim for the one fits your project.

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

What kinds of projects can use Agile
models?

A

Projects that have dynamic requirements
When rapid productions are need
▪ IT companies

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

Sprint prioritization

A

Analyze and evaluate product backlog
* Select sprint goal

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

Sprint planning

A
  • Decide how to achieve sprint goal
    (design)
  • Create sprint backlog (tasks) from
    product backlog items (user stories /
    features)
  • Estimate sprint backlog in hours
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is a process?

A

A process is a set of activities that
interact to produce a result.

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

Software development process

A

Specification Designing Implementing
Testing Maintaining

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

A software process model

A

is a description
of the sequence of activities carried out in
a SE project, and the relative order of
these activities.

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

Code-and-fix model

A

write some code, debug it, repeat until finished

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

Waterfall model

A

a relatively linear sequential approach

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

Iterative Models
* Prototype model

A

used to understand/evolve the requirements

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

Iterative Models spiral

A

Spiral model
* a risk-driven model, assesses risks at each step, and does the most critical action
immediately

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

Agile model

A

Extreme Programming (XP)
* Scrum
focus on process adaptability and customer satisfaction, a good fit in fast
changing environments

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

By changing the SP model, we can improve and/or tradeoff:

A
  • Development speed (time to market)
  • Product quality
  • Project visibility
  • Administrative overhead
  • Risk exposure
  • Customer relations
  • etc.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Code-and-fix model

A

starts with little or no initial planning
➢ usually no documentation
➢ anyone who has knowledge of coding can use this

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

Waterfall model

A

➢ every step is strictly documented and predefined
➢ follow a very strict lifecycle
➢ well defined milestones, outputs
➢ finish one step before moving to the next step

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

Waterfall model pros

A

Simple to use and understand
Has clear deliverables and
milestones
Management is simple
Easy to classify and prioritize tasks

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

Waterfall model cons

A

Too rigid
Non-adaptive design constraints
Ignores mid-process client feedback
Testing in the very end, which does
not give the option of identifying the
problem in advance
no working software is produced
until late during the life cycle

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

Code-and-fix model pros

A

Low overhead
Low expertise, anyone can use it!

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

Code-and-fix model cons

A

No way to assess progress or
manage the project
Does not fit a complex project
Unclear what and when will be
delivered
Low quality

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

Why is waterfall model is not popular now?

A
  • Main assumption: all requirements can be
    determined at the beginning, no change later on
  • This does not correspond to current software development
  • Data shows change rates from 35%–50% for large projects
  • “change” is the most expensive operation in the waterfall model
  • Feedback (from clients, programmers) comes very/too late
  • Note: that doesn’t mean you should fall into the
    opposite extreme and do no planning at all
21
Q

the broken iron triangle

A

scope(features, functionality) -> schedule(time) -> resources (cost, budget)

22
Q

What kinds of projects can use
waterfall model?

A

The requirements are precisely
documented
 aviation system
 warehousing systems
 There are no ambiguous requirements
 Product definition is stable, no changes

23
Q

Prototype model

A

help customers and
developers understand the
system requirements
➢ build a prototype, adjust the
requirements, and revise
the prototype until have a
clear picture

Start -> communication -> Quick planning -> Modeling quick design -> Construction of prototype -> deployment, delivery -> communication

24
Q

Prototype model pros

A

Can help reduce risk of incorrect
user requirements
Missing functionality can be
identified easily
Projects have a higher visibility

25
Q

Prototype model cons

A

Requires extensive customer
collaboration
Difficult to know how long project
will last, users may change
requirements now and then
Easy to fall back into code-and-fix
without proper design, customer
feedback evaluation

26
Q

What kinds of projects can use
prototype model?

A

 When the requirements are unclear
 When the users are involved

27
Q

Spiral model

A

➢ a combination of waterfall and
prototype models
➢ includes risk analysis and risk
management
➢ each iteration identifies and
solves the sub-problems with the
highest risk

28
Q

Spiral model phases

A

 Plan
* communicate with the clients to get the necessary requirements
 Risk Analysis
* identify all the possible risks and alternative solutions
 Engineering
* develop/test the software
 Customer evaluation
* customers/clients evaluate the developed system

29
Q

Risk analysis
Example Risks

A

Personnel shortfalls
Unrealistic schedules and budgets
Developing the wrong software functions
Developing the wrong user interface
Continuing stream of requirement changes
Shortfalls in externally furnished components
Shortfalls in externally performed tasks
Real-time performance shortfalls

30
Q

Spiral model pros

A

Has risk and cost management
More flexible, changing
requirements can be handled
Allows for extensive use of
prototypes
High visibility, users see the system
early

31
Q

Spiral model cons

A

Management is more complex
Large number of intermediate
stages, which requires excessive
documentation
Could be expensive for small
projects
Relies on developers to have risk assessment expertise

32
Q

What kinds of projects can use spiral
model?

A

It is favored for large, expensive, and
complicated systems
 For high-risk projects

33
Q

Agile models

A

plan quickly, develop quickly, release quickly, and revise quickly
➢a user-centered and practicebased model
➢a collection of practices based on
several values and proven
software engineering principles
➢development is divided into small
iterations, at the end of each
iteration, a working product is
delivered

34
Q

The Core of Agile models

A

Core Principles:
* Assume Simplicity
* Embrace Change
* Close Communication between
company and client
Incremental Change
* Model With a Purpose
* Multiple Models
* Maximize Stakeholder
Investment
* Quality Work
* Rapid Feedback
* Software Is Your Primary Goal
* Travel Light
Core Practices:
* Test-Driven Development
* Continuous delivery of software
* Continuous collaboration with
customer
* Continuous update according to
changes
* Continuous integration
* Simple design
* Pair programming
* Sharing the codebase between all or
most programmers
* A single coding standard to which all
programmers adhere

35
Q

Extreme Programming (XP)

A

Emphasises
Individuals and interactions
* Over processes and tools
* Working software
* Over documentation
* Customer collaboration
* Over contract negotiation
* Responding to change
* Over following a plan
* software engineering practices >
project management
XP Practices
* Programming in pairs
* Test-driven development (TDD)
* Continuous planning, change, delivery
* Shared project metaphors, coding
standards and ownership of code

36
Q

XP Advantages

A

Lightweight methods suit smallmedium size projects
Produces good team cohesion
Emphasises final product
Iterative Test based approach to
requirements and quality assurance

37
Q

XP Disadvantages

A

More difficult to scale up to large
projects where documentation is
essential
Needs experience and skill for not to
degenerate into code-and-fix
Programming in pairs is costly
Test case construction is a difficult
and specialized skill

38
Q

Scrum

A

A simple process framework for effective
team collaboration on complex products.
* Lightweight
* Simple to understand
* Difficult to master

39
Q

Scrum has been used for:

A
  • Commercial software
  • In-house development
  • Contract development
  • Research
  • Financial applications
  • ISO 9001-certified
    applications
  • Embedded systems
  • 24x7 systems with
    99.999% uptime
    requirements
  • the Joint Strike Fighter
  • Video game development
  • FDA-approved, life-critical
    systems
  • Satellite-control software
  • Websites
  • Handheld software
  • Mobile phones
  • Network switching applications
  • ISV applications
  • Some of the largest applications
    in use
40
Q

Characteristics agile

A

Self-organizing teams
* Product progresses in a series of month-long “sprints’’
* Requirements are captured as items in a list of “product
backlog”
* No specific engineering practices prescribed
* Uses generative rules to create an agile environment for
delivering projects

41
Q

Scrum overview

A

Product backlog -> Sprint backlog -> Sprint -> Working increment on software
all changes to be made to
the product in future releases
* dynamic & evolves

42
Q

Sprints

A
  • Scrum projects make progress in a series of “sprints”
  • Analogous to iterations
  • Typical duration is 2–4 weeks or a calendar month at
    most
  • A constant duration leads to a better rhythm
  • Product is designed, coded, and tested during the
    sprint
43
Q

planning sprints

A
  • Plan sprint durations around how long you can
    commit to keeping change out of the sprint
44
Q

Scrum framework Roles

A

*Product owner
*ScrumMaster
*Team

45
Q

Scrum Ceremonies

A

*Sprint planning
*Sprint review
*Sprint retrospective
*Daily scrum meeting

46
Q

Scrum Artifacts

A

*Product backlog
*Sprint backlog
*Burndown charts

47
Q

Product owner

A
  • Define the features of the product
  • Decide on release date and content
  • Be responsible for the profitability of the product
    (ROI)
  • Prioritize features according to market value
  • Adjust features and priority every iteration, as
    needed
  • Accept or reject work results
48
Q

The ScrumMaster

A
  • Represents management to the project
  • Responsible for enacting Scrum values and
    practices
  • Removes impediments
  • Ensure that the team is fully functional and
    productive
  • Enable close cooperation across all roles
    and functions
  • Shield the team from external interferences
49
Q

The team

A
  • Typically 5-9 people
  • Cross-functional:
  • Programmers, testers, user experience designers,
    etc.

Software Engineering (9 decks)

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