Chapter 3 Flashcards
Predictive software development
has big advantages
encourages up-front design
Preditctive software development nicknames
BDUF (Big Design Up Front)
Because that’s what it encourages
Iterative model
You build the final application incrementally
Start with minimally viable product and then add pieces to it.
Software engineering goals at its most fundamental
producing useful applications
Iterative software development modesl
Unified Process and iterated waterfall
Second goal of software engineering
producing software quickly
Rapid Application Development (RAD)
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
Agile method
allow a projects goals to change over time to track changing customer needs
Extreme programming
uses pair programming to ensure that every piece of code goes through a kind of code review
Test driven development model
forces programmers to write tests for their code
Commit to the development method
Unless everyone commits, you’ll have trouble getting success from the model
predictive development model
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
Problems with predictive model
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
Adaptive development model
Allows you to change projects goals during development
You can periodically reevaluate and change your direction
Adaptive model analogy
With each new development in the project you reevaluate where you are and decide if you want to keep going the same direction
Predictive model works well when
the project is small
Predictive project Success and failure indicators
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.
Predictive model Advantages
Predictability - if everything
Stability
Cost-savings
Detailed design
less refactoring
Fix bugs early
Better documentation
Easy maintenance
Predictive model Disadvantages
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.
Pure predictive models
Assume each stage of development is finished completely and correctly before the next stage begins
Predictive model / BDUF
one of the
Waterfall model
Predictive
The plain vanilla of the predictive model world
You finsih each step completely and thoroughly before you move on to the next step
Waterfall analogy
Predictive
Each step is a bucket
When one bucket is full the information floods to the next bucket (task) to complete
Waterfall model can work well if these assumptions are satisified
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
Sashimi
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
Waterfall with Feedback
Predictive
Allows you to jump back a step if necessary in order to rework the previous step
Advantages of Sashimi
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
Incremental Waterfall
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”
V-Model
Predictive
Waterfall in V Shape
Concept < – Operation & Maintenance
Requirements < – Verification & Validation
Design <– Testing
Implementation
Software Development Life Cycle
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
Expanded SLDC
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
Iterative vs Predictive
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
Prototype
A simplified model that demonstrates some behavior that you want to study
Evolutionary prototype
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
Throwaway prototype
Demonstrates one aspect of a system and then you throw it away and start coding
Incremental Prototype
A collection of prototypes that separately demonstrate the applications features. Eventually you combine these prototypes to create the single application
Benefits of prototypes
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
Disadvantages of prototypes
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
