Chapter 3 Flashcards

1
Q

Predictive software development

A

has big advantages

encourages up-front design

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

Preditctive software development nicknames

A

BDUF (Big Design Up Front)

Because that’s what it encourages

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

Iterative model

A

You build the final application incrementally

Start with minimally viable product and then add pieces to it.

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

Software engineering goals at its most fundamental

A

producing useful applications

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

Iterative software development modesl

A

Unified Process and iterated waterfall

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

Second goal of software engineering

A

producing software quickly

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

Rapid Application Development (RAD)

A

These models incorporate some of the best features of the modesl described in preceding lessons plus new features that get results to the end user quickly

Pushed devs to generate as much high-qulaity code as possible and as quicly as possibly

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

Agile method

A

allow a projects goals to change over time to track changing customer needs

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

Extreme programming

A

uses pair programming to ensure that every piece of code goes through a kind of code review

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

Test driven development model

A

forces programmers to write tests for their code

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

Commit to the development method

A

Unless everyone commits, you’ll have trouble getting success from the model

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

predictive development model

A

Predict in advance what needs to be done and then you go out and do it

– use requirements to design the system and
—- > use the system design to write the code

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

Problems with predictive model

A

Its hard to predict exactly wht a softwarae application needs to do and how you should build it ahead of time

– customer needs change
– if you need to learn programing technique on the fly could lengthen timeframe

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

Adaptive development model

A

Allows you to change projects goals during development

You can periodically reevaluate and change your direction

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

Adaptive model analogy

A

With each new development in the project you reevaluate where you are and decide if you want to keep going the same direction

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

Predictive model works well when

A

the project is small

16
Q

Predictive project Success and failure indicators

A

User involvment - if the users help define the requirmeents, they’re more likelyi to be correct

Clear Vision - if the customers and developers have the same clear vision about the project’s goals, development will stay on track

Limited size - a small size helps the customers and team members see the whole picture all at once. Requirements won’t have time to change

Experienced team – experienced team members are less likely to design something they can’t build. They also won’t wander off writing code that doesn’t work out.

Realistic - if the suers ask for a telepathic user interface they’ll be disappointed

Established technology - if you stick to technology that you’ve used before you’ll udnerstand how to use it correctly

Incomplete requirements - in a predictive porject, if the requirements don’t say you should do sokmething, it won’t get done

Unclear requirements - if the customers and developers don’t all have the same vision of what the application should do, you’ll have trouble satisfying everyone.

Chaging requirmeents - the requirements are like railroad tracks: After they’re set, changing course is difficult

No resources - even if you have clear requirements and a perfect design, a single programmer can’t write a 10,000 line program in one week.

17
Q

Predictive model Advantages

A

Predictability - if everything

Stability

Cost-savings

Detailed design

less refactoring

Fix bugs early

Better documentation

Easy maintenance

18
Q

Predictive model Disadvantages

A

Inflexible – requirements can’t change, so if they need to… you’re in trouble

Later release - you can’t release anything until the project is finished (unlike an adaptive model where incremental releases can occur

Big Design Up Front - you need to defined everything up front, so you can’t start developing until you know everything you’re going to need to do.

19
Q

Pure predictive models

A

Assume each stage of development is finished completely and correctly before the next stage begins

20
Q

Predictive model / BDUF

A

one of the

21
Q

Waterfall model

A

Predictive

The plain vanilla of the predictive model world

You finsih each step completely and thoroughly before you move on to the next step

22
Q

Waterfall analogy

A

Predictive

Each step is a bucket

When one bucket is full the information floods to the next bucket (task) to complete

23
Q

Waterfall model can work well if these assumptions are satisified

A

Predictive

The requirements are precisely known in advance

the requirements include no unresolved high-risk items

The requirements won’t change much during development

The team has previous experience with similar projects

There’s enough time to do everything sequentially

24
Q

Sashimi

A

Predictive

Similar to waterfall structure, but each piece overlaps

In other words, while you’re still working on requirements other teammates can start the Design step

25
Q

Waterfall with Feedback

A

Predictive

Allows you to jump back a step if necessary in order to rework the previous step

26
Q

Advantages of Sashimi

A

1 - People wit different skills can focus on their specialties without waiting for others

2 - It lets you perform a “spike” or “deep dive” into a particular topic to learn more about it. For example, if the clients want some new type of technology added to the requirements that you are not familiar with, you can assign a team to research that while the rest of the team continues with the current requirements and moves on to the Design phase

3 - later phases can modify earlier phases

27
Q

Incremental Waterfall

A

Predictive

Uses a series of separate waterfall cascades

Each cascade ends with a usable application as a deliverable called an “increment”

Each “increment” provides more features than the previous one

It’s essentially going through a full iteration of the SDLC for each “increment”

Actually somewhat adaptive since you can reevaluate your direction at the start of each new “increment”

28
Q

V-Model

A

Predictive

Waterfall in V Shape

Concept < – Operation & Maintenance
Requirements < – Verification & Validation
Design <– Testing
Implementation

29
Q

Software Development Life Cycle

A

AKA the Application Development Life Cycle

Requirements
Design
Implementation
Verification
Deployment
Maintenance

This is a Predictive model actually…. what? I thought it was just the various steps in the life cycle

30
Q

Expanded SLDC

A

Initiation (an idea)
Concept Dev – initiator evaluates the initial idea

Preliminary planning - PM and technical Lead are assigned and start planning

Requirements

High level designs - specify major subsystems, data flow, database needs

Low level design - explains how to build the applications pieces that were defined in the high level design

Development - the team writes the program code. They perform tests all the way

Acceptance testing - customers get to test

Deployment

maintenance

Review - can the development process be improved in the future

Disposal - the application has run its course and can no longer be improved

31
Q

Iterative vs Predictive

A

Predictive models can’t make changes as easily as iterative models

Predictive models spend a lot of time in the beginning making sure you get the project right. So changing that direction after the fact is really difficult and could mean the project is a failure

Predictive models don’t do fuzzy requirements well

Iterative

Iterative modesl handle fuzzy well

They build functioning models for each cycle and then add pieces to it incrementally until the project is finished

The commitment then, is smaller, it is a smaller cycle, so changes are easy to make

32
Q

Prototype

A

A simplified model that demonstrates some behavior that you want to study

33
Q

Evolutionary prototype

A

Demonstrates the features of a an application. As the project develops you keep adding onto the features of the evolutionary prototype until the application is finished

34
Q

Throwaway prototype

A

Demonstrates one aspect of a system and then you throw it away and start coding

35
Q

Incremental Prototype

A

A collection of prototypes that separately demonstrate the applications features. Eventually you combine these prototypes to create the single application

36
Q

Benefits of prototypes

A

Common vision = customers and developers see the same preview of the finished application

Improved requirements = allow customers to see what the finished application will look like

Improved design = developers quickly explore specific pieces of the application to learn what they involve

37
Q

Disadvantages of prototypes

A

Narrowing vision
Customer impatience - if the prototype is good then the customer will think that the final application can be completed relatively quickly

Raised expectations - the prototype might demonstrate features that won’t be included in the final application

Schedule pressure - goes with customer impatience

Code Attachment - developers might become attached to code they’ve produced and become unwilling to change what they’ve written even if something better is available

Neverending prototypes - sometimes developers put too many features and spend too much time on a prototype. throwaway prototypes for example are meant to be thrown away not used as the code base for the application

38
Q
A