Intro to Software Engineering Flashcards
First Step in software development
Getting requirements of customers
Why create requirements document
It tells customers what they are getting and project members what they’re building
What is the 2nd step of software development?
Gather high-level design of software
What does the high-level design include?
Information about what data design to use: 2-tier or 3-tier or direct access.
2 tier is client-server architecture
3-tier is client-server where there is a presentation, data processing and data storage tiers
data process
What do you do in the high level design?
break the project into large pieces that handle the project’s major areas of functionality.
What happens in the development step?
Programmers continue refining the low-level design until they know how to implementt those designs in the code
What are the parts of the deployment step?
New computers for the back-end database
Special data maintenance chores to keep the old and new databases synchronized
On-site support while users get to know the new system
New computers for users
A new network
User training
Parallel operations while some users get to know the new system and other users keep using the old system
Massive bug fixing when 250 users discover dozens or hundreds of bugs that testing didn’t uncover
What step comes after the deployment step?
The maintenance step
What is a formal definition of software engineering?
An organized, analytical approach to the design, development, use, and maintenance of software
Why is Software Engineering Important?
It lets you control what otherwise might seem like a random whirlwind of chaos
What is the Waterfall development model?
Requirements
Analysis and Design – high-level design
Development / Coding
Testing
Deployment and Maintenance
Waterfall approach is based on
The process of manufacturing products
True or False? The Waterfall model has well-defined checklists, processes, and tools and comprehensive documents
True
Requirements gathering
You need to find out who the customers are, what they want, and what they need.
requirements Documents
These documents tell the cusotmers what they will be getting, and the project members what they will be building
High Level Design
includes such things as decisions about what platforms to use (desktop, laptop, table, or phone), what data design to use (direct access, 2-tier, or 3-tier) an dinterfaces to other systems (such as external purchasing systems.
Should also include information about the project architecture at a relatively high level. This might include modules or classes to build
Low Level Design
Should take the chunks of the high-level design and break each of those down into manageable pieces for each team involved in the development.
Like the database for a Student grades site, should include tables for the Student, available student Courses, and the Grades in those courses for each Student
Development
Programmers continue refining the low-level design until it would be easier just to write the code instead.
testing/bug hunting also occurs during this phase
Testing
Break the code into pieces
- Developers test it
- testers test it (people who didn’t develop the code)
- once the code seems to be working then the code is inserted back into the main file and the whole thing is tested.
Good testing practice
Anytime you change the code you need to test it to make sure everything works as it should
Speaking about finding and fixing bugs, what is one of the most important rules of software engineering
The longer a bug remains undetected, the harder it is to fix
When is testing critical?
At every stage of development
Deployment (to a company) might involve any of the following:
New computers for the back-end Database
A new network
New computers for the users
User training
On-site support for the users to get to know the new system
Parallel operations (while some users still use the old system and some are learning the new one)
Special data maintenance (to keep the old and new DBs synchronized
Massive bug fixing as users uncover problems with bugs that hadn’t been fixed yet (by testing)
Other unpredictable things
Deployment
When you roll your software out to your customers
Maintenance
Killing bugs and adding enhancements, improvements, and new features
Wrap up
Conduct a post-mortem of the project
Requirements
important for setting a projects direction
Document Management features that are less common but still useful (not the REQUIRED features of good document management system)
- ability to access documents over the internet
- ability for multiple people to cllaborate on documents
- integration into other tools (like MS Office)
- document branches so you can split a document into two paths for future changes
- user roles and restricted access lists
- email change notification
- workflow support and document routing
change control board
they review, approve, or reject change requests
Should usually have a final arbiter to make final decisions on the requests
Document management system should have, at minimum:
- People can share documents so that they can all view and edit them
- Only one person can edit a document at a given time
- You can fetch the most recent version of a document
- You can fetch a specific version of a document by specificying either a date or version number
- You can saearch documents for tags, keywords, and anything else in the documents
*You can compare two versions fo a document to see what changed, who changed it, and when the change occurred.
What is the purpose of documentation?
To be sure that everyone is headed in the same direction
source code control system
Allows all developers to use the code, a dveloper checks out a module of code and can work on it, and other developers can still use the most recently saved version but can’t make updates until the developing developer releases it
Source code is written for
People. Computers don’t understand it until it has been compiled or interpreted
JBGE
Code documentation should be Just Barely Good enough – if you provide too much documentation and comments it will be difficult to maintain.
summary token
explains the method’s purpose
param tokens
describe the method’s parameters
application documentation
documentation to help explain what the application does, and how.
training manuals
user manuals
cheat sheets
marketing materials
quick start guides
executive champion
or
executive sponsor
the highest ranking executive who supports your project
executive champion duties include
Providing necessary resources
* Making “go/no-go” decisions
* Giving guidance on high-level issues such as how the project fits into the company’s overall business strategy
*Helping navigate any administrative hurdles required by the company
* defining the business case
* working with users and other stakeholders to get buy-in
* providing feedback to developers about implemented features
*buffering the project from external distractions
*refereeing between managers, users, devlopers and others interested in the project
* supporting the project team
* staying out of the way
Project Manager
the highest-ranking member of the project team. Monitors the project’s progress to ensure that work is heading in the right direction at an acceptable pace and meets with customers and stakeholderst to verify that the finished product meets their requirements
Project manager duties
- Helping define the project requirements
- Tracking project tasks
*Responding to unexpected problems - Managing risk
- Keeping users up-to-date on the project’s progress
- Providing an interface between customers and developers
- Managing resources such as time, people, budget, hardware, and software tools
- Managing delivery
Software Development Lifecycle
SDLC
Requirements
High Level Design
Low Level Design
Development
Testing
Deployment
Maintenance
Wrap up
Project manager
- ensures that work is heading in right direction and at an acceptable pace
- meets with customers and stakeholders to verify that the finished product meets their requirements
Osborn method
Focus on Quantity
Withhold Criticism
Encourage unusual ideas
Combine and improve ideas
Also known as “brainstorming”
Functional requirements
Describe a project’s capabilities
Things the application should do
Non functional requirements
Statements about the quality of the application’s behavior or constraints on how it produces a desried result
Prototype
A mockup of some or all of an application
Document control system
Prevents two people from making changes to the same document at the same time
UML
Let’s you specify how parts of the system should work.
It uses several kinds of diagrams to represent different pieces of the system. Some represent program items like classes.
Others represent behaviors, like how data flows through a system
Unified Modeling Language
Audience oriented requirements
Categories of requirements that focus on different audience and the different points of view that each audience has
List the Audience-Oriented Requirements
Business requirements
User requirements
Functional requirements
Nonfunctional requirements
Implementation requirements
Functional requirements
Things the application should do
Nonfunctional requirements
How the applications produces the desired result - specifying things like the application’s performance, reliability, and security characteristics
