new system be responsive to unanticipated issues agile and...
TRANSCRIPT
ITM 305 NOTES
Week 2: Chapter 1: introduction to systems development
SDLC
Information systems development process
Agile development
Neither team members nor the user completely understands the problems and complexities of a
new system
Be responsive to unanticipated issues
Agile and flexible
Allow, anticipate, embrace changes and new requirements during development process
Iterative development
“grown” in an organic fashion
Piece by piece
Core components developed first, additional components are added
One big project, with many mini-projects
Week 2: Chapter 8: Approaches to System Development
Predictive approach to the SDLC
Can be planned and organized
New information system can be developed according to the plan
Phases
o Project initiation
o Project planning
o Analysis
o Design
o Implementation
o Deployment
o support
Waterfall model
o Assumes phases can be carried out and completed sequentially
o No going back
o Rigid planning, final decision-making at each step
Adaptive approach
Assumes project must be more flexible and adapt to changing needs as project progresses
System requirements needs aren’t well understood
Cant be planned completely
Spiral model
o Some analysis, some design, some implementation
o More analysis, more design, more implementation
o Even more analysis, even more design, even more implementation
Incremental
Based on iterative life cycle
System is built in small increments
Walking skeleton
Provides complete front to back implementation of the new system but with only “bare bones”
of functionality
Later adds flesh
Gets working software into hands of the user early
Extensive user texting and feedback
Iterative is also adaptive
Predictive waterfall includes a support phase but adaptive and iterative SDLCs don’t
System development methodology
Set of comprehensive guidelines for SDLC
Includes models, tools, techniques
Models
Record or communicate information
Representation of an important aspect of the real world
o Inputs, outputs, processes, data, objects, object interactions, locations, networks,
devices
o Gantt chart
Tools
Software support that helps create models or other components required in the project
Integrated development environments
Includes many tools to help with programming
Smart editors, context-sensitive help, debugging tool
Visual modeling tools
Techniques
Collection of guidelines that helps an analyst complete an activity or task
Step by step instructions for creating a model
Advice
Methodology includes a collection of techniques that are used to complete activities
Within each phase of the systems development life cycle. The activities
Include the completion of a variety of models as well as other documents and
Deliverables. Like any other professionals, system developers use software tools
to help them complete their activities.
Software construction and modeling
Structured approach
o For predictive approach
o Programming approach where each module has one start/end point, uses sequence,
decision, repetition constructs only
Top-Down Programming
o Divides complex program into hierarchy of modules
Structure design, chart, analysis
o Loosely coupled
o Highly cohesive
o Easier to understand what each modules does and whether it affects the outcome of
any other modules
Data flow diagram
Object oriented approach
o Collection of interacting objects that work together to accomplish tasks
Chaordic (chaos and order)
Week 3: Chapter 9: Project Planning and Project Management
Finishing on time, within budget, effectively meet the need
Oversight committee – clients and key managers who review the progress and direct the project
Ceremony -level of formality of the project
PMI(Project Management Institute)
Agile Project Management (APM)
PMBOK (Project Management Body of Knowledge
Project scope management
Time
Cost
Quality
Human resource
Communications
Risk
Procurement
Integration
System vision document (scope)
Problem description
Anticipated business benefits
System capabilities
Business benefits – contains the results that the org. anticipates it will accrue from a new system
System capabilities – support the realization of the beliefs, helps identify the size and complexity of the
new system and project that will be required
Net present value
Payback period
Tangible benefit
Intangible benefit
Determine project risk and feasibility, review with client and obtain approval
Establish project environment, schedule work, staff and allocate resources
Evaluate work processes, monitor, make corrections
Week 3: Chapter 2: Investigating System Requirements
Technology architecture
The set of computing hardware, network hardware, and topology, and system software
employed by the org.
Application architecture
The info systems that supports the org. (info systems, subsystems, and support tech)
Consolidated Sales and Marketing System (CSMS)
Goal is to modernize technology and functionality
Add more customer-oriented functionality
Four subsystems
o Sales subsystem
o Order fulfillment subsystem
o Customer account subsystem
o Marketing subsystem
System analysis activities
Gather detailed information
Define requirements
Prioritize requirements
Develop user-interface dialogs
Evaluate requirements with users
System requirements – the activities a system must perform or support and the constraints that the
system must meet
Separate into functional/non-functional requirements
Functional requirements – the activities that the system must perform
Business functions the users carry out, use cases
Non-functional requirements – characteristics of the system other than those activities it must perform
or support
Constraints and performance goals
To differentiate functional and non-functional use FURPS
Functional requirements
Usability requirements
Reliability requirements
Performance requirements
Security requirements
Model - representation of some aspect of a system
Textual models – something written down, describes requirements, detailed
Graphical models – use pictures for graphs, layouts, maps
Mathematical models - -use numbers, formulas, algorithms
Unified Modeling Language (UML) – standard set of model constructs and notations defined by the
Object Management Group
Stakeholders – ppl w/ interest in successful implementation of system
Internal (persons inside org.)
External (persons outside org.)
Operational (regularly interact w/ system)
Executive (use the info for financial interest)
Gathering information
Interviews w/ users and stakeholders
Distribute and collect questionnaires
Review inputs, outputs, and documentation
Observe and document business procedures
Research vendor solutions
Collect active user comments and suggestions
Documenting workflows with activity diagrams
Workflow – sequence of processing steps that completely handles one business transaction or
customer request
Activity diagram – describes user/system activities, sequential flow
Week 4: Chapter 3: Use Cases
Use case – an activity that the system performs, usually in response to a request by a user
User goal technique
o Determines what specific goals/objectives must be completed by a user
Identify all potential users
Classify potential users in terms of their functional role
Classy potential users by organizational level
Identify their goals
Organize use cases by type of user
Look for duplicates/inconsistencies
Identify where different types of users need same use cases
Review
Event decomposition technique
o Determines the external business events to which the system must respond
External event
Temporal event
State event
o Event vs sequence of prior conditions to an event
o Perfect technology assumption External events to look for include:
√ External agent wants something resulting in a transaction
√ External agent wants some information
√ Data changed and needs to be updated
√ Management wants some information
Temporal events to look for include:
√ Internal outputs needed
√ Management reports (summary or exception)
√ Operational reports (detailed transactions)
√ Internal statements and documents (including payroll)
√ External outputs needed
√ Statements, status reports, bills, reminders
For state events, what will the system respond to, internal state changes trigger use cases
Do not use events that involve login, logout, change pass, backup, restore
CRUD (create, read, update, delete) archive
Technique to validate, refine, cross-check use cases
o Identify all data entities/domain classes involved in new system
o Verify that a use case has been identified that creates a new instance, updates existing
instances, reads or reports values of instances, and deletes an instance
Use Case Diagram Steps
Identify all stakeholders and users who would benefit by seeing a use case diagram
Determine what each stakeholder or user needs to review in a use case diagram: each
subsystem, for each type of user, for use cases that are of interest
For each potential communication need, select the use cases and actors to show and draw the
use case diagram. There are many software packages that can be used to draw use case
diagrams
Carefully name each use case diagram and then note how and when the diagram should be used
to review use cases with stakeholders and users
Week 5: Chapter 5: Extending the Requirements Model
Use Case Diagram – lists and describes the processing details of a use case
Use case name
Scenario
Triggering event
Brief description
Actors
Related use cases
Stakeholders
Preconditions
Post conditions
Flow of activities
Exception conditions
Scenarios/ use case instances
Interaction diagram – shows interaction between actors and objects within the system
System Sequence Diagram (SSD) – showing the sequence of messages b/w an external actor and the
system during a use case /scenario
UML sequence diagram (unified modeling language)
SSD Notation
Lifeline
Loop frame
True/false condition
Opt frame (based on true/false condition)
alt frame (if/then else condition)
Developing SSD
1. identify input message
2. describe message from external actor to the system using message notation
3. identify special conditions on input messages
4. identify and add output return values
State Machine Diagram – shows the life of an object in states and transitions
state
transition
action expression
pseudo state (starting point)
origin state
destination state
guard condition
Concurrent states
Composite states
Concurrent Paths (multiple paths in concurrent states)
Developing State Machine Diagram
1. review the class diagram, select classes that might require state machine diagrams
2. make list of status conditions
3. identify transitions
4. sequence the states in correct order
5. review paths and look for independent concurrent paths
6. look for additional transitions, test both directions
7. expand each transition with appropriate message event, guard condition, action expression
8. review and test state machine diagram
MIDTERM
Chapter 4: Domain Classes
Problem domain
The specific area of the user’s business need that is within the scope of the new system
“Things” (domain classes)
Those items users work with when accomplishing tasks that need to be remembered
Products, sales, shippers, customers, invoices, payments
Brainstorming Technique
Use checklist of all usual types of things typically found and brainstorm to identify domain
classes of each type
Steps
1. Identify user & set of use cases
2. Brainstorm to identify things involved when carrying out the use case—which information
should be captured by the system.
3. Use the types of things (categories) to systematically ask questions about potential things, such
as the following: Are there any tangible things you store information about? Are there any
locations involved? Are there roles played by people that you need to remember?
Noun Technique
Identify all nouns that come up when the system is described and determine if each is a domain
class, an attribute, or not something we need to remember
finding, classifying, refining a list of nouns that come up in discussions or documents
Popular, systematic
Ends up with long lists + many nouns that may not be used
Difficult identifying synonyms and things that are really attributes
Good place to start when there are no users available to help brainstorm
Steps
1. Using the use cases, actors, and other information about the system— including inputs and
outputs—identify all nouns.
For the RMO CSMS, the nouns might include customer, product item, sale, confirmation,
transaction, shipping, bank, change request, summary report, management, transaction
report, accounting, back order, back order notification, return, return confirmation…
2. Using other information from existing systems, current procedures, and current reports or
forms, add items or categories of information needed.
For the RMO CSMS, these might include price, size, color, style, season, inventory
quantity, payment method, and shipping address.
Details about Domain Classes
Attribute – one piece of information about each instance of the class
o Customer has first name, last name, phone number
Identifier or key – one attribute that uniquely identifies an instance of a class, required for data
entities, optional for domain classes
Compound attribute – two or more attributes combined into one structure to simplify the
model
o Address rather than number, street, city, state, zip separately
CLARIFICATION!
Called association on class diagram in UML
o Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many
o We are emphasizing UML in this text
Called relationship on ERD in database class
o Cardinality is term for number of relationships in entity relationship diagrams: 1 to 1 or
1 to many
Associations and Relationships apply in two directions
o Read them separately each way
o A customer places an order
o An order is placed by a customer
Minimum & Maximum Multiplicity
Associations have minimum & maximum constraints
o If mini = 0, association is optional
o If mim > 1, association is mandatory
Types of Associations
Binary association
o Two diff classes
Course section includes students
Members join club
Unary association (recursive)
o b/w 2 instances of the same class
person married to person
part is made using parts
ternary association (three)
n-ary association (b/w n)
Semantic Net
shows instances and how they are linked
The Domain Model Class Diagram
class
o category of classification used to describe a collection of objects
domain class
o classes that describe objects in the problem domain
class diagram
o a UML diagram that shows classes with attributes and associations (plus methods if it
models software classes)
domain model class diagram
o a class diagram that only includes classes from the problem domain, not software
classes so no methods
Domain Class Notation
domain class has no methods
class name is always capitalized
attribute names are not capitalized and use camelback notation
More Complex Issues about Classes
generalization/specialization
o a hierarchical relationship where subordinate classes are special types of superior
classes
superclass
o the superior or more general class in a generalization/specialization hierarchy
subclass
o the subordinate or more specialized class in a generalization/specialization hierarchy
inheritance
o the concept that subclasses inherit characteristics of the more general superclass
More Complex Issues about Classes: Whole Part Relationships
Whole-part relationship— a relationship between classes where one class is part of or a
component portion of another class
Aggregation— a whole part relationship where the component part exists separately and can be
removed and replaced (UML diamond symbol, next slide)
o Computer has disk storage devices
o Car has wheels
Composition— a whole part relationship where the parts can no longer be removed (filled in
diamond symbol)
o Hand has fingers
o Chip has circuits
Three types of UML Relationships
Association Relationships
Whole Part Relationships
Generalizations/Specialization Relationships
o inheritance
Entity Relationship Diagrams CARDINALITY SYMBOLS
An ERD shows basically the same information as a domain model class diagram
It is not a UML diagram, but it is widely used by data analysts in database management
There really is no standard notation, but most developers use the entity and crows feet notation
shown in this text
An ERD is not good for showing generalization/specialization relationships and whole part
relationships
Ch 10: Object-Oriented Design: Principles
OO design: process by which a set of detailed OO design models are built to be used for coding
Design models are created in parallel to actual coding/implementation w/ iterative SDLC
Agile approach says create models only if they are necessary
Simple detailed aspects don’t need a design model before coding
UML Requirements vs Design Models
o Diagrams are enhanced and extended
Architectural design
o Enterprise level system
A system that has shared resources among multiple people or groups in an
organization
o Options are client-server or internet based
Each presents different issues
Component diagram
o Type of design diagram that shows the overall system architecture and the logical
components within it for how the system will be implemented
o Identifies logical, reusable, transportable system components that define system
architecture
o Essential element of a component diagram is the component element with its API
o Application program interface (API)
o The set of public methods that are available to the outside world
Detailed design (use case realization)
o Design and implement use case by use case
Sequence diagram – extended SSD w/ added controller + domain classes
Design class diagram – extend from domain model class diagram and update
from sequence diagram
class definition – written in the chosen code for the controller and the design
classes
UI classes – forms/pages are added to handle user interface b/w actor +
controller
Data Access Classes – added to handle domain layer requests to get/save data
to the database
Design Classes in Detailed Design
o Elaborate attributes – visibility, type, properties
o Add methods + complete signatures
OO Detailed Design Steps
Design Class Diagrams
o Stereotype – way of categorizing a model element by its characteristics, indicated by
guillemots (<<>>)
o Persistent class – class whose objects exist after a system is shut down (date
remembered)
o Entity class – design identifier for a problem domain class (usually persistent)
o Boundary class/view class – class that exists on a system’s automation boundary, such
as an input window for, or web page
o Control class – class that mediates b/w boundary classes and entity classes acting as
switchboard b/w view layer and domain layer
o Data access class – class that is used to retrieve data from and send data to a database
Class Stereotypes in UML
Notation for a Design Class (syntax for name, attributes, methods)
Notation for Design Classes
o Attributes
Visibility ( + not public or - private) whether attribute can be accessed directly
by another object
Attribute name – lower case camelback notation
Type expression – class, string, integer, double, date
Initial value – if applicable the default value
Property – if applicable, such as {key}
Ex:
- accountNo: String {key}
-startingJobCode: integer = 01
o Methods
o Visibility—indicates (+ or -) whether an method can be invoked by another object.
Usually public (+), can be private if invoked within class like a subroutine
o Method name—Lower case camelback, verb-noun
o Parameters—variables passed to a method
o Return type—the type of the data returned
o Examples:
+setName(fName, lName) : void (void is usually let off)
+getName(): string (what is returned is a string)
-checkValidity(date) : int (assuming int is a returned code)
Notation for Design Classes
o Class level method – applies to class rather than objects of class (static method) is
underlined
+findStudentsAboveHours(hours): Array
+getNumberOfCustomers(): Integer
o Class level attribute—applies to the class rather than an object (aka static attribute).
Underline it.
-noOfPhoneSales: int
o Abstract class– class that can’t be instantiated.
o Only for inheritance. Name in Italics.
o Concrete class—class that can be instantiated.
Notation for Design Classes (method arguments and return types not shown)
Notation for Design Classes (navigation visibility)
o Ability of one object to view + interact w/ another object
o Accomplished by adding an object reference variable to a class
o Shown as arrow head on association line
o Navigation Visbility Guidelines
o One-to-many associations indicate a superior/subordinate relationship are usually
navigated from superior to subordinate
o Mandatory associations, objects in one class cant exist w/o objects of another class,
usually navigated from more independent class to dependent
o When object needs info from other object, navigation arrow might be required
o Navigation arrows may be bidirectional
First Cut Design Class Diagram
o proceed use case by use case, adding to diagram
o pick domain classes that are involved in use case (see pre/post conditions for ideas)
o add controller class to be in charge of use case
o determine initial navigation visibility requirements using guidelines + add to diagram
o elaborate attributes of each class w/ visibility + type
o note that often the associations and multiplicity are removed from the design class
diagram as in text to emphasize navigation, but are often left on
designing w/ CRC cards (classes, responsibilities, collaboration cards)
OO design is about assigning Responsibilities to Classes for how they Collaborate to accomplish
a use case
Usually a manual process done in a brainstorming session
o 3 x 5 note cards
o One card per class
o Front has responsibilities + collaborations
o Back has attributes needed
CRC Cards Procedure
o Process is design/realize a single use case, start w/ unused CRC cards, add a controller
class
o Identify problem domain class w/ primary responsibility for this use case that will
receive the first message from the use case controller
o Use first cut design class diagram to identify other classes that must collaborate w
primary object class to complete use case
o Have use case descrips and SSDs handy
o Start w/ class that gets first message from controller, name responsibility
o What does first class needs to carry out responsibility, assign other classes
responsibilities to satisfy each need
o Add collaborators to cards showing which collaborate with which, add attributes to back
when data is used
o Eventually add user interface classes or data access classes
o
o Fundamental Design Principles
o Coupling
Quantitative measure of how closely related classes are linked (tightly/loosely
coupled)
Two classes are tightly coupled if there are lots of associations with another
class
Two classes are tightly coupled if there are lots of messages to another class
Best to have loosely coupled
o Cohesion
Quantitative measure of focus/unity of purpose w/in single class (high/low
cohesiveness)
One class has high cohesiveness if all of its responsibilities are consistent and
make sense for purpose of the class (a customer carries out responsibilities that
naturally apply to customers)
One class has low cohesiveness if its responsibilities are broad or makeshift
Best to have highly cohesive
o Protection from Variations
Design principle that states parts of system unlikely to change are separated
(protected) from those that will surely change
Separate user interface forms + pages likely to change from application logic
Put database connection + SQL logic that is likely to change in a separate classes
from app logic
Use adaptor classes that are likely to change when interfacing w/ other systems
Better to choose one w/ protection from variations
o Indirection
A design principle that states an intermediate class is placed between two
classes to decouple them but still link them
A controller class between UI classes and problem domain classes is an example
Supports low coupling
Indirection is used to support security by directing messages to an intermediate
class as in a firewall
If deciding between two alternative designs, choose the one where indirection
reduces coupling or provides greater security
o Object responsibility
A design principle that states objects are responsible for carrying out system
processing
A fundamental assumption of OO design and programming
Responsibilities include “knowing” and “doing”
Objects know about other objects (associations) and they know about their
attribute values. Objects know how to carry out methods, do what they are
asked to do.
Note that CRC cards and the design in the next chapter involve assigning
responsibilities to classes to carry out a use case.
If deciding between two alternative designs, choose the one where objects are
assigned responsibilities to collaborate to complete tasks (don’t think
procedurally).
Chapter 11: Object Oriented Design: Use Case Realizations
Discussion of OO software design at more advanced lvl
3 layer design uses sequence diagrams, communication diagrams, package diagrams, and design
patterns
Design is shown to proceed use case by use case, and w/in each use case, layer by layer
Detailed Design of Multilayer Systems
o CRC cards focus on business logic (problem domain layer of classes)
o Include view layer, business logic/problem domain layer, data access layer
How do objects get created in memory?
How does the user interface interact with other objects?
How are objects handled by the database?
Will other objects be necessary?
What is the lifespan of each object?
Design Patterns – standard design technique + template popular
o Pattern name
o Problem that requires solution
o Pattern that solves problem
o Example of pattern
o Pros + cons
Controller pattern
o problem: how to handle all messages from view layer to classes in problem domain layer
to reduce coupling
o Sol: assign one class b/w view layer + problem domain layer that receives all messages +
acts as switchboard directing messages to problem domain
Use case realization w/ sequence diagrams - process of elaborating detailed design of use case
w/ interaction diagrams
o UML sequence diagrams
o UML comm. Diagram
o Sequence diagrams (use case realization sequence diagrams), extend the system
sequence diagram (SSD) to show:
View layer objects
Domain layer objects
Data access layer objects
Assumptions
o Perfect technology assumption
o Perfect memory assumption
o Perfect solution assumption
o Separation of responsibilities
Developing a Multilayer Design
o View layer (Forms, pages)
Data Access Layer
o Persistent classes need mechanism for storing + retrieving state from a database
o Separate layer required when business logic is complex
Updating Design Classes
o Focusses on domain layer
o When object of a class receives a message, that message becomes a method in the class
on the DCD
Implementation Issues (3 layer design)
o View layer class responsibilities
Display electronic forms and reports
Capture such input events as clicks, rollovers, key entries
Display data fields
Accept input data
Edit/validate input data
Forward input data to domain layer classes
Start/shut down system
o Domain layer class responsibilities
Create problem (persistent) classes
Process all business rules w/ appropriate logic
Prepare persistent classes for storage to the database
o Data access layer class responsibilities
Establish and maintain connections to database
Contain all SQL statements
Process result sets into appropriate domain objects
Disconnect gracefully from database
More design patterns
o Adapter
Like an electrical adapter
Lace an adapter class b/w your system and an external system
o Factory
Use factor class when creation logic is complex for a set of classes
o Singleton
Use when only one instance should exist at a time and is shared
Chapter 13: Operational
implementation includes programming and testing activities
deployment includes system tests, converting data, training, setting up production environment,
deploying solution
testing – process of examining a component, subsystem , or system to determine its operational
characteristics and whether it contains any defects
test case – a formal description of a starting state, one or more events to which system
responds to and expected response/end state
test data- set of starting states and events used to test a module, group of modules, or entire
system
unit testing
o unit test – tests of an individual method, class, component before it is integrated w/
other software
o driver- method/class developed for unit testing that stimulates behaviour of method
that sends a message to method being tested
o stub – method/class developed for unit testing that simulates the behaviour of a
method invoked that hasn’t yet been written
integration testing
o tests of a behaviour of a group of methods, classes, components
interface incompatibility (one method passes parameter of wrong data type to
another method)
parameter values – pass/return value of unexpected value (neg. num for price)
run time exceptions – method generates error due to conflicting resource needs
unexpected state interactions – states of two/more objects interact to cause
complex failures
o methods, classes, objects
usability testing
o determines whether a method, class, subsystem, system meets user requirements
o often required b/c they involve functional/non-functional requirements
o evaluates functional requirements use case by use case
completed in each iteration
test ease of learning + ease of use
test accuracy
feedback
system, performance, stress testing
o system test- integration test of entire system/independent subsystem
performed at end of each iteration
performed more frequently
often tested + improved
o performance test – integration + usability test that determines whether a system
/subsystem can meet time-based performance criteria
response time
throughput
user acceptance testing
o test performed to determine whether system fulfills user requirements
o performed near end of project
o formal activity
o details of acceptance tests included in request for proposal (RFP) + procurement
contract
converting + initializing data
o operational data requires fully populated database to support ongoing processing
o data needed at system startup can be obtained from:
files, databases of system being replaced
manual records
files/databases from other systems in organization
user feedback during normal system operation
Training users
o For end users + system operators
o Emphasize hands-on use for specific business processes or functions (order entry,
inventory control, accounting)
Hands on training, practice excercises, questions + answers, tutorials
o System operator training can be much less formal when operators aren’t end users
Development order
o Input, process, output – implements input modules, process modules, output modules
o Top-down development – development order that implements top-lvl modules first
o Bottom- up development – development order implements low-lvl detailed modules
first
Source Code control
o Automated control for tracking source code files + controlling changes to those files
o Read-only mode & read/write mode
o Only one programmer at a time
Planning & Managing (Implementation, testing and deployment)
o Packaging, installing, deploying
Issues
Incurring costs of both systems in parallel
Detecting + correcting errors
Disrupting company & operations
Training personnel & customers w/ new procedures
Different approaches
Direct deployment – installs new system, quickly makes it operational,
immediately turns off any overlapping systems
o High risk, lower cost
Parallel – operates old & new systems for extended time period
o Low risk, high cost
Phased – installs new system, makes operational in series of steps
o Submitting error reports & change requests
Standard reporting methods
Review of requests by manager/committee
Extensive planning for design/implementation
o Impleneting change
Identify what parts need change
Secure resources/personnel
Schedule design/implementation activities
Develop test criteria/test plan
o Change & version control – tools & processes handle the complexity associated w/
testing & supporting a system through multiple versions
Alpha- incomplete but ready for some rigorous integration/testing
Beta – stable version to test by end uses over extended period of time
Production version, release version/production release – system version that is
formally distributed to users or made operational for long-term use
Maintenance release- a system update that provides bug fixes and small
changes to existing features
Chapter 13: Making the System Operational
testing – the process of examining a component subsystem, or sytem to determine its
operational characteristics and whether it contains any defects
test case – aformal descript of a starting state, one or more events to which software must
respond, and expected response or ending state
o defined based on well understood functional and non-functional requirements
o must test all normal and exception situations
test data- set of starting states and events used to test a module, group of modules, entire
system
o data will be used for test case
unit testing
tests of an individual method, class, component before it is integrated w/ other software
driver – a method or class developed for unit testing that simulates behaviour of method that
sends message to method being testsed
stub – a method or class developed for unit testing that simulates the behaviour of a method
invoked that hasn’t yet been written
integration testing
integration test – tests of the behaviour of a group of methods, classes, components
o interface incompatibility – one method passes parameter of wrong data type to another
method
o parameter values – method is passed/returns a value that was unexpected, such as neg.
num for price
o run-time exceptions – a method generates an error, such as “out of memory” or “file
already in use” due to conflicting resource needs
o unexpected state interactions – the states of two or more objects interact to cause
complex failures
integration testing of object-oriented software is very complex b/c an object-oriented program
consists of set of interacting objects
o Methods can be (and usually are) called by many other methods, and the calling
methods may be distributed across many classes.
o Classes may inherit methods and state variables from other classes.
o The specific method to be called is dynamically determined at run time based on the
number and type of message parameters.
o Objects can retain internal variable values (i.e., the object state) between calls. The
response to two identical calls may be different due to state changes that result from
the first call or occur between calls.
usability testing
Usability test – test to determine whether a method, class, subsystem, system meets user
requirements
Many usability tests are required b’c they involve functional + non-functional requirements
Most common type evaluates functional requirements, use case by use case
o Can be completed in each iteration as use cases are implemented
o Can test ease of learning and ease of use
o Can test whether results match actual requirements
o Key type of feedback from users throughout project
Testing
System test – an integration test of an entire system or independent subsystem
o Can be performed at the end of each iteration
o Can be performed more frequently
o Build and smoke test – a system test that is performed daily or several times a week
The system is completely compiled and linked (built), and a battery of tests is
executed to see whether anything malfunctions in an obvious way (“smokes”)
Automated testing tools are used. Catches any problems that may have come
up since the last system test
System, performance, and stress testing
Performance test or stress test – an integration and usability test that determines whether a
system or subsystem can meet time-based performance criteria
o Response time – the desired or maximum allowable time limit for software response to
a query or update
o Throughput – the desired or minimum number of queries and transactions that must be
processed per minute or hour
User acceptance testing
User acceptance test – a system test performed to determine whether the system fulfills user
requirements
May be performed near the end of the project (or at end of later project iterations)
A very formal activity in most development projects. Payments tied to passing tests
Details of acceptance tests are sometimes included in the request for proposal (RFP) and
procurement contract
Converting and Initializing Data
An operational system requires a fully populated database to support ongoing processing
Data needed at system startup can be obtained from these sources:
o Files or databases of a system being replaced
o Manual records
o Files or databases from other systems in the organization
o User feedback during normal system operation
Training Users
Training is needed for end users and system operators
Training for end users must emphasize hands-on use for specific business processes or functions,
such as order entry, inventory control, or accounting
Widely varying skill and experience levels call for at least some hands-on training, including
practice exercises, questions and answers, and one-on-one tutorials
System operator training can be much less formal when the operators aren’t end users
Experienced computer operators and administrators can learn most or all they need to know by
self-study
Planning and Managing
Implementation, Testing, and Deployment
Development Order
o Input, process, output (IPO) – a development order that implements input modules first,
process modules next, and output modules last
o Top-down development – a development order that implements top-level modules first
Use stubs for testing
o Bottom-up development – a development order that implements low-level detailed
modules first
Use drivers for testing
Source code control
o An automated tool for tracking source code files and controlling changes to those files
A programmer checks out a file in read-only mode when he or she wants to
examine the code without making changes (e.g., to examine a module’s
interfaces to other modules)
When a programmer needs to make changes to a file, he or she checks out the
file in read/write mode
The SCCS allows only one programmer at a time to check out a file in read/write
mode.
Packaging, installing, and deploying components
o Issues to consider when planning
Incurring costs of operating both systems in parallel
Detecting and correcting errors in the new system
Potentially disrupting the company and its IS operations
Training personnel and familiarizing customers with new procedures
o Different approaches
Direct deployment
Parallel deployment
Phased deployment
Direct Deployment– a deployment method that installs a new system, quickly makes it
operational, and immediately turns off any overlapping systems
o Higher risk, lower cost
Parallel deployment – a deployment method that operates the old and the new systems for an
extended time period
o Lower risk, higher cost
Phased deployment - a deployment method that installs a new system and makes it operational
in a series of steps or phases
Submitting Error Reports and Change Requests
o Standard reporting methods
o Review of requests by a project manager or change control committee
o For operational systems, extensive planning for design and implementation
Implementing a Change
o Identify what parts of the system must be changed
o Secure resources (such as personnel) to implement the change
o Schedule design and implementation activities
o Develop test criteria and a testing plan for the changed system
Change and Version Control – tools and processes handle the complexity associated with testing
and supporting a system through multiple versions
o Alpha version – a test version that is incomplete but ready for some level of rigorous
integration or usability testing
o Beta version – a test version that is stable enough to be tested by end users over an
extended period of time
o Production version, release version, or production release – a system version that is
formally distributed to users or made operational for long-term use
o Maintenance release – a system update that provides bug fixes and small changes to
existing features