Brainscape's Knowledge GenomeTM

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


See full index

com1001 > software lifecycle > Flashcards

software lifecycle Flashcards

1
Q

Important takeaways

Denver International Airport

A
  • time management is important
  • need time for extensive testing + operations
  • technitcians and software engineers had minimal communication amongst each other
  • software testing is vital
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

International Denver Airport problems

A
  • too much traffic - normal network load 95%
  • poor management due to poor planning during original design
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

basic info and steps

Code and fix model:

A
  • 1950-
  • not an entirely sustainable model
  • was used when computers were much more expensive
  • build first version -> modify until client is satisfied <-> operate -> retirement
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Code and Fix model issues

A
  • no process steps - no specs, docs, tests
  • no separation of concerns - no teamwork
  • no way to deal with complexity
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

main steps

Software Engineering Tasks

A
  1. getting requirements
  2. high-level design
  3. low level design
  4. development
  5. testing
  6. deployement
  7. maintenance
  8. wrap up
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

low-level vs high-level design

A

high level design ->
- what type of system are we going to build?
- what is it going to do and not do
- how is hardware going to implemented, ie how many processes, servers or PCs?

low level design ->
- how is this system going to be built?
- how are teams on different modules going to communicate

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

Testing steps

A
  • is the system working correctly?
  • purpose is to destroy the software
  • important to point out areas of improvement
  • testing as a whole, in different scenarios and similar hardware
  • performance testing - simulating multiple users
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Waterfall model

A
  • expectation is you do it one step at a time
  • in reality requirements need to be revised at times
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Waterfall Method issues

A
  • real projects rarely follow a sequential flow
  • hard to state all requirements explicitly
  • requirements may change
  • customer must have patience
  • any blunder can be disastrous
  • important to be unambigious when it comes to establishing requirements early on
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Waterfall with feedback

A
  • more communication among teams
  • harder to organise large amount of people working
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Sashimi waterfall

A
  • overlap of teams working in different sectors
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Incremental waterfall

A
  • customer can give feedback
  • by the time you’re finished with first project you can develop a new one with improvements in mind
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

V-model

A
  • integration testing to see different components working together
  • system test involves running scenarios from end to end
  • unit, integration and system testing - verification -> tells you that you built what you intended to build
  • acceptance testing - validation -> check from customer if you built what customer had envisioned, customer tests your software and see if it fits their needs, need to make sure project is useful and is fit for the need
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

why are they used vs predictive models

Iterative models

A
  • predictive models don’t handle change well
  • predictive models don’t handle fuzzy requirements well
  • iterative models build programs incrementally
  • iterations are shorter, allowing for change
  • requirements can be refined after iterations
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Prototyping

A

Communication -> Quick plan -> quick design -> prototype construction -> deployment and feedback -> repeat

  • build smaller systems to more effectively list requirements from customer
  • simpler to revise
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Vertical prototypes

A

vertical prototype
- tests particular functionality across all layers
- market team gives feedback while engineering team if its feasible
- check if it is possible to build with conditions that you have
- especially if it is a one-of-a-kind system that hasn’t been built before

17
Q

Horizontal prototype

A
  • customer could provide feedback easier
  • model one page of software at a time
  • tests particular layer (typically GUI) of system
18
Q

Spiral model

A
  • start small, add things and keep going
    1. determine objectives
    1. identify and resolve risks
    1. plan the next iteration
    1. development and test
19
Q

Unified process

A
  • initial requirements stage + have an idea of how business functions with what constraints
  • consider that stages overlap to give opportunity to refine previous decisions
  • team size shouldn’t be too small or too big
  • too small = more time, too big = harder to communicate
  • hard to add new people since time will be spent on educating what has already been done
  • knowledge should be available beforehand to new members
  • additional new people slowed down project further
20
Q

process models

A
  • define the order and transition criteria of different steps of software development are applied
21
Q

name predictive models

A
  • waterfull variants
22
Q

name iterative models

A
  • prototyping
  • spiral model
  • unified process

com1001 (5 decks)

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