Software Engineering

Thursday, January 15, 2009

12:13 PM
 
Software Engineering
What is software
Programs and any associated documentation
Testing: means running code
Validation: asks the question, have I made the correct software (user, client)
Verification: does the code perform the task it's supposed to (programmer)
Software
Generic: word processor: put out on market without a particular market in mind
Harder because has to satisfy large group of users and has to compete with other
software in the market
Custom software: made for a specific purpose/market
Types of software development
From scratch
Extension
collection
What is good software
MUDE
Usable
Efficient
Time and memory space
Compatible
Dependable
Maintainable
Is your software adaptable
What is software engineering
Software engineering activities
Planning
Requirements gathering
Validation & verification
Ethics
Confidentiality
Competence
The LAW
Intellectual property rights
Computer misuse
 
Process model
Ordered set of activities
Process P.R.D.I.T.E
Set of activities (no particular order) group, collection
(ordered: sequence series array list)
1. *Planning
*added
 2. Requirements (validation most important) the problem
Solicitation (getting requirements)
Analysis
Specification
A description of the problem that you are trying to solve
Developer cannot do requirements on own because validation is
require
validation
3. Design: the solution
Architecture (must know requirements before building architecture
To be read by technical people (diagrams)
2 Verification
3
4
5
6
4. Implementation (verification)
Build the product described by the design
Well documented, reliable, flexible, correct program
Verification
5. Testing (not necessarily verification nor validation)
Running code
Unit testing ("this unit works as asked for…" )
Integration
Acceptance testing (testing in user's environment, validation, users will
do it)
Make sure system is correct
Meets users and clients requirements
6. Evolution/maintenance
1 corrective (fixing errors/bugs)
Error
Mistake in human thought process
Fault
Manifestation of an error in the code
Failure
Upon running the code, not getting the correct result
2 adaptive
Changes in the environment that the software needs to run on
3 perfective
User/client decides that they want something extra or different
4 preventative
Increases system's future maintainability
 
Examples (from requirements)
(developer) writes a list of platforms
Verification non-testing
Get client to sign off on platform list
Validation non-testing
 Tester runs prototypes are met
Verification because the tester is a member of the development and is testing
against the requirements
User runs prototype
Validation and testing
 
 
Individual programming
Writing for yourself or a teacher. Gathering requirements is easy
Requirements : must be measureable/verifiable
Functional and nonfunctional requirements
Functional are easy to verify,
Non functional requirements not easy to measure, have to write
requirement in a measureable way
 Product: P.U.R.E.
M.U.D.E.
Maintainable
Usability
Dependability* not the same as reliability in PURE
Reliable
Secure
safe
Efficient
 Portability
 Usability
 Reliability
 Efficiency
Time and space
Organizational
company standards, delivery date
External
Laws ethics privacy security
Design constraints
Self explanatory
Language
Platform/other systems it will be interacting with
"the system shall" instead of will
Testing
Black box
Clear box
Writing tests for the code structure
 
Differences between System and a Program
System: breadth/depth are greater
Breadth
Multiple users
Depth
Linkage: sharing of data and control issues
 Relationships between items
Technical considerations
Estimation is hard
The more detail you know, the better you will be at estimating
Assignments
Take into consideration skills of developers
Technical skills
Communication skills/personal traits
Ninja skills
Have to learn application domain
Ex: working on bank app, need to understand basic stuff like $ and .$
So developer and client can communicate through the client's language
 
Cohesion (tight)
Relationship between items in a component
Component
More than a function
Coupling (loose)
Relationship between components
All these components that are separate but need work together, maybe not
necessarily sharing
Testing
Unit
Running code on individual functions
Integration
Do the components work together
System
testing conducted on a complete, integrated system to evaluate the system's
compliance with its specified requirements.
Acceptance testing
Acceptance testing generally involves running a suite of tests on the completed
system. Each individual test, known as a case, exercises a particular operating
condition of the user's environment or feature of the system, and will result in a
pass or fail boolean outcome
Regression
Anytime you need to change or redo
May use some of old test
You can never show something is error free
Chapter 3
Project + product failure
Product: the system…
Project: time/budget constraints
NATO had to step in 1968 to provide standards amidst software crisis
1995 Standish Group report
"we study software engineering because it sucks now"
Found that a majority of software engineering projects fail
Reasons for failure
 Incomplete requirements/requirement errors (usually biggest problem because
issues show up later)
User/client issues
Reviews/inspections/prototypes good
Reviewing is reading code
Testing is running
Commitment+ leadership
From members of team
Skilled/experience/dependable consultants
Chapter 4
Process models
 Waterfall method
 
Downsides
Too rigid, doesn’t allow for going back and making changes
Particularly with requirements
 Evolutionary development
Prototyping?
Downside
No design
Bad maintainability
 Formal system development (IBM "clean room")
Once you get requirement you change it into a detailed spec.
Better than waterfall: each step is small
Reviewing constantly
 Spiral development
Emphasizes risk analysis
Able to go back and do all steps again
 
Risk analysis-external handout
Risk- any thing that can go wrong
Budget
Resources
Personnel
Project, product and business
Business risks
Market risks
Excellent product that no one wants
Strategic risks
 
Sales risk
Sales force that doesn’t understand how to sell it
Management risks
Budget risks
In a large project, at most you can deal with 10 risks
 
Test
Traditional process models
 Code and fix bad
 Waterfall method (big systems)
example: Replacing one system with another, where the requirements are
very well known
Downsides
Too rigid, doesn’t allow for going back and making changes
Particularly with requirements
 *Evolutionary development (short life, smaller programs)
example: videogame
Prototyping? Reaction to waterfall. Large user interface software
Downside
No design, using tools restricts you
Bad maintainability
 Formal system development (IBM "clean room")
example: missile guidance systems, need to be very safe and secure
Once you get requirement you change it into a detailed spec.
Better than waterfall: each step is small
Reviewing constantly
Very mathematical
 Spiral development
example: something that’s new, having to investigate if there's a market,
apple making an iPod
Emphasizes risk analysis
Able to go back and do all steps again
 Incremental
Vertical |||
Divide up problem into independent components, and work on those
components
Components shouldn’t be larger than 20,000 lines of code
Then requires significant integration before a release
Horizontal =
Versions , gets to customer at first version
 Chief programmer
A lot of problems
What might be the positives of having a chief programmer
o Agile method
 Family of methods that have something in common, not a process
 Short development cycles
 Change in design, linked to incremental
 NOT the answer to everything
 Characteristics
Short releases and iterations
Incremental design
User involvement
Minimal documentation
Informal communication
Change
 Individuals and interactions over processes and tools
 Page 108
Individual and interaction over processes and tools
Working software takes priority over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
o Capability maturity model (Carnegie Melon)
 Assessing process models
 Groups are ranked, level 1 -5, 5 the best, like being certified
 
 
 
 
 
 
 
 
 
Developer
Writer of software
Client
Paying (i.e. bank)
User
User of software (i.e. atm users)
 
Creeping requirements: requirements that get added late
 
Definitions (Test)
Software
Software engineering
Good software
Software process activities
Process vs process model
Requirements
Functional
Non-Functional: chart
Product
PURE
Organizational
External
Validation: right program
Verification: program does right thing
Cohesion (tight)
Coupling (loose)
Testing
Unit
Integration
Testing coupling
System
 Non functional req's
Risk analysis
 
Test 2
Thursday, February 19, 2009
12:08 PM
 
Test
Agile (extreme programming, crystal)
Diagrams
Chapter 4 & 5
Agile messaging
Page 108
Individual and interaction over processes and tools
Working software takes priority over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Architecture
 
Extreme programming EXTREME!
Agile
Pair programming
Two people 1 screen
One is typing, the other is a backseat driver
Review is the best verification method, better than testing
Refactoring pg 250 ("cleaning it up")
the process of changing a computer program's internal structure without modifying
its external behavior or existing functionality. This is usually done to improve code
readability, simplify code structure, change code to adhere to a given programming
paradigm, improve maintainability, or improve extensibility.
Requirements
Informally
stories
Principles of XP Fundamental truth should be only 5
Pair programming
Unit testing
Integrate everything on a regular basis
Short iterations and releases
In other process models, a lot going on away from coding, XP is all about coding
Embrace change
Simplicity, take simplest possible approach
Concrete experiments
Open honest communication
Main ones
Feedback
Assuming simplicity
Embracing change
 Don't waste time making standards
As long as you have them, it's ok
Diagrams
Data flow diagram (old, functional rather than object oriented)
O circles mean processes
= open ended means storage
-> arrows mean flow between things, need to mark with what the data being passed
is
П rectangles represent external I/O
Level 0 data flow diagrams, DFDs, are also called context diagrams
Just shows system and users
System, O, usually in the middle
Easy for client to read for client
Easy to check for completeness
Level 1, internal
Slightly more in-depth, breaks down processes a little more usually
State transition diagram
Different states of a system, such as with VIM editor, it can be in command mode or
text insertion mode
State mate
Must show errors; what happens if borken
Rational …
Things in a state diagram
States
Arcs from state to state
Action written on arc how to transition state
Relationships
 

Entity, rectangle
Relationship diamond
 Attribute, oval
Relation; n-tuple, has n number of things in it
Types
1-1 no x can have 2+ y values

1-many Regular funtions, many Xs can have the same Y

Many-1 Many Y's can have same X, not possible in function

Many-many Anything goes

Examples
Entity Relationship Entity

Person (n/many) Birth place 1 location

Artist (n) Performs (m) songs

UML Objects diagrams
UML universal modeling language
Scenario
General example. How someone interacts with computer, one situation;
logging on
Use-case
Specific example. Takes care of telling what happens correctly and what
happens when done incorrectly
sequence diagrams (not for clients, mostly for designing)
Unlike data flow, passed information is "messages"
Vertical lines with boxes on them, read top to bottom
Lines between are messages, - -solid sent, - - - dashed are received
Objects rectangles across top
Lines coming down from them
Use case diagrams are separate (good for clients/requirements gathering)
Actors/agents (stick figures) better for more than 1 type of person interacting
with system
Processes (ovals)
No real detail, juts users and parts of the system that they use
Block diagrams
Subsystems with interaction lines
Object collaboration
 
Program documents
Test plan / requirements definition
Requiring justification for requirements usually makes client get rid of 50% of them
Requirements process
Preparation: should this system really be attempted
Elicitation: going to clients, need to have application domain knowledge
 
 
 
  
 
 
 
 
Project
Tuesday, March 17, 2009
12:27 PM
 
Requirements document
Test plan
Team 1
Project with Dr. John, Q&A website thing
Write down source and rationale