Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

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
Prototype model cons
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
What kinds of projects can use prototype model?
 When the requirements are unclear  When the users are involved
27
Spiral model
➢ 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
Spiral model phases
 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
Risk analysis Example Risks
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
Spiral model pros
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
Spiral model cons
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
What kinds of projects can use spiral model?
It is favored for large, expensive, and complicated systems  For high-risk projects
33
Agile models
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
The Core of Agile models
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
Extreme Programming (XP)
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
XP Advantages
Lightweight methods suit smallmedium size projects Produces good team cohesion Emphasises final product Iterative Test based approach to requirements and quality assurance
37
XP Disadvantages
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
Scrum
A simple process framework for effective team collaboration on complex products. * Lightweight * Simple to understand * Difficult to master
39
Scrum has been used for:
* 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
Characteristics agile
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
Scrum overview
Product backlog -> Sprint backlog -> Sprint -> Working increment on software all changes to be made to the product in future releases * dynamic & evolves
42
Sprints
* 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
planning sprints
* Plan sprint durations around how long you can commit to keeping change out of the sprint
44
Scrum framework Roles
*Product owner *ScrumMaster *Team
45
Scrum Ceremonies
*Sprint planning *Sprint review *Sprint retrospective *Daily scrum meeting
46
Scrum Artifacts
*Product backlog *Sprint backlog *Burndown charts
47
Product owner
* 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
The ScrumMaster
* 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
The team
* 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.
© 2025 Bold Learning Solutions. Terms and Conditions