Glossary of terms
Table of Contents
ACTIVITY DIAGRAM #WORKFLOW ................................................................................................................ 2
ACTORS .................................................................................................................................................. 2
ADAPTIVE SDLC ....................................................................................................................................... 3
ARCHITECTURE #CENTRALIZED# #COMPUTERNETWORK#MULTI-TIER#EXTRANET PG272........................................ 4
BEHAVIORAL ANALYSIS #SDLCDISCOVERY#SYSUSECASE#STATECHART .............................................................. 4
BLACK BOX TESTING .................................................................................................................................. 4
BUSINESS USE CASE .................................................................................................................................. 5
BUSINESS REQUIREMENTS DOCUMENT (BRD) ............................................................................................... 5
DESIGN PATTERNS #IMPLEMENTATION ......................................................................................................... 5
DESIGN PRINCIPLES #ENCAPSULATE#INFOHIDE#NAVIGATE#COUPLING#COHESION .............................................. 8
DISCIPLINE .............................................................................................................................................. 9
DISCIPLINE (DESIGN) #HI-LOWDESIGN #SOFTWAREARCHITECT#COORDINATEDESIGN........................................... 9
DISCIPLINE (REQUIREMENT) #DOMAINCLASS#EVENTDECOMPOSITION#FUNCTION/NON-FUNCTION ....................... 10
DOMAIN CLASS DIAGRAM #SYSREQUIREMENT ............................................................................................. 10
EVENT DECOMPOSITION #OCCURRENCE&EVENT ........................................................................................... 10
IMPLEMENTATION PLAN #BRD ................................................................................................................. 11
ITERATIVE & INCREMENTAL DEVELOPMENT #SDLCMETHOD#ADAPTIVE #UNIFIEDPROCESS ................................. 12
MODELING ............................................................................................................................................ 13
PACKAGE#ACTOR #USECASE ..................................................................................................................... 13
PREDICTIVE SDLC ................................................................................................................................... 14
THE WATERFALL METHOD ....................................................................................................................... 14
SDLC PHASES ........................................................................................................................................ 14
SDLC INITIATION PHASE #BRD#ROLEMAP#SYSUSECASEDIAG#INITIALCLASSDIAG#BASELINE ............................. 14
SDLC DISCOVERY PHASE #REQUIREMENTS#TESTING#BRD#BEHAVIORAL#STRUCTURAL#BASELINE ....................... 15
SDLC CONSTRUCTION PHASE#DESIGN#IMPLEMENT#TEST............................................................................. 15
SDLC FINAL VERIFICATION & VALIDATION PHASE ......................................................................................... 16
SDLC CLOSEOUT PHASE #DEPLOYMENT#INSTALLING#TRAININGUSERS#INITIALIZEDB ........................................ 16
SPIRAL .................................................................................................................................................. 18
STRUCTURAL ANALYSIS ............................................................................................................................ 19
SYSTEM REQUIREMENT SPECIFICATION ....................................................................................................... 19
SYSTEM SEQUENCE DIAGRAM #INTERACTIONDIAG #REQUIREMENTS #LIFELINE................................................... 19
SYSTEM USE CASE .................................................................................................................................. 19
SYSTEM USE CASE DIAGRAM #EVENTTABLE ................................................................................................. 20
TESTING (DISCOVERY PHASE) #TESTINGINPHASES ......................................................................................... 20
TESTING (FINAL VERIFICATION PHASE)
#DRIVER#STUB#USABILITYTEST#UNITTEST#INTEGRATIONTEST#USERACCEPTANCE ............................................ 21
UNIFIED PROCESS LIFE CYCLE #INCEPT#ELABORATE#CONSTRUCT#TRANSIT#DISCIPLINES#ADAPTIVE#ARCHITECT ....... 23
UNIFIED MODELING LANGUAGE (UML)...................................................................................................... 24
USE CASE REALIZATION #DESIGNCLASSDIAG#SEQUENCEDIAG#MULTILAYER#OBJECTRESPONSIBILITY#CONTROLLE .. 25
USER REQUIREMENT CAPTURE .................................................................................................................. 26
USER REQUIREMENT DOCUMENT ............................................................................................................... 27
WHITE BOX TESTING ................................................................................................................................ 27
1
Activity Diagram #workFlow
Documents the current business workflow i.e. how the business works now (not workflow of the
system you are going to design)
Workflow is the sequence of processing steps that completely handles one business transaction or
customer request.
Activity diagram is simply a workflow diagram that describes the various user activities, the person
who does each activity, and the sequential flow of these activities.
Actors
Used in system use case
Stereotype = Extension of a UML feature
Can invent their own stereotypes to create extended meanings to UML model elements
E.g. <<Actor>>, <<Interface>>, etc
After identifying the actors
Generalize them
•
i.e. find relations amongst these different types – e.g. A manager is a more specific kind
of clerk – Think object-oriented!
Note that actors can also be systems
Role Map:
A diagram used to standardize the treatment of users and external systems
Unlike use-case diagram, only shows actors and how actors are related
The arrow allows user to model actors with overlapping roles
Think of the generalization relationship arrow as “a kind of”
• Example: Clerk, Manager, Accountant are different kind of Employer, Senior
Manager is a kind of Manager
Actors with Partially Overlapping Roles
Can model the manager actor as an abstract actor
• More specifically abstract generalized actor
The term abstract means that the invented actor is not real (i.e. the abstract actor is never
instantiated)
The actor is not a true role but an abstract concept meant to represent the shared aspects of other
roles
2
Adaptive SDLC
When Objectives are Unknown: Agile Methodologies
Agile methodologies prioritize flexibility over a commitment to a predetermined outcome. Whereas
the waterfall method casts its directives in permanent ink, agile planning would typify the use of a
chalkboard and eraser. Agile methodologies emphasize the importance of incremental feedback in
the project development process. Projects are completed in stages, with a series of deliverables
rather than a single final product. As a result, the direction of the project is easily modified according
to the evolving needs of the organization. Indeed, the project resists finality and may be recast,
revised, or restructured indefinitely at the discretion of the organization. Agile methodologies tend to
be well received by participants, as most feel that such techniques lead to improved quality and
productivity.
The steps in agile techniques can vary somewhat based on the exact method employed. However,
agile steps generally include:
 A project brainstorming session
 Production of a functioning component of the project
 Delivery of component for feedback from multiple sources
 Implementation of feedback into project design and goals
 Production of another project component under the redefined project parameters and goals
Agile methodologies may appeal to an organization if:
 The parameters of the project are evolving or undetermined
 The organization easily adapts to change
 The team and/or project is somewhat small
 The timeline is flexible
 The organization represents an industry that is rapidly changing
 There is an experienced project manager
Although agile methodologies are more appropriate for small teams, they can be employed when a
large team is broken into sub-groups. If this is not possible, establish alternative communication
channels to enable broad input into a project from a variety of sources.
Modeling in Agile method
Does not dictate which model to build or how formal to make these models but instead helps
developer to stay on track with their models.
Principles:
Develop software as your primary goal
Enable the next effort as your secondary goal
Minimize your modeling activity
Embrace change, and change incrementally
Model with a purpose
Build multiple models
Build high quality models and get feedback rapidly
Focus on content rather than representation
Learn from each other with open communication
Know your models and how to use them
Adapt to specific project needs
3
Architecture #centralized# #computerNetwork#multi-tier#Extranet pg272
Centralized: describes deployment of all computer systems in a single location. Generally used for
large-scale processing applications, including both batch and real-time applications.
Distributed: modern information system is typically distributed across many computer systems and
geographical locations. Distributed architecture relies on communication networks to connect
geographically dispersed hardware components.
Multi-tier: employs multiple computer systems in a cooperative effort to meet informationprocessing needs.
 Clustered: employs a group of computers with similar hardware and software. Located near
one another, act as a single super computer. Processing load is balanced across all machines.
 Multicomputer: Computers are not as similar as clustered. A suite of application or system
programs and data resources is exclusively assigned to each computer system. Each system
is optimized to the role that it will play in the combined system, such as a database.
Computer network: is a set of transmission lines, specialized hardware and communication protocols
that enables communication among different users and computer systems.
 LAN: less than one km long and connects computers within a single building or floor
 WAN: wide area network can describe any network over 1km, but usually spans cities,
countries or entire globe.
 Internet: global collection of networks that are interconnected using common low-level
networking standrads
 World Wide Web: a collection of resources that can be accessed over the Internet by a
number of standard protocols. The resources of the Web are delivered to users over the
Internet.
 Intranet: private network that uses Internet protocols but is accessible only to limited set of
internal users
 Extranet: is an intranet that has been expanded to include directly related business partners.
One widelyused method for implementing an extranet is the VPN (virtual private network)
Behavioral Analysis #SDLCDiscovery#SysUseCase#StateChart
This is a step in the SDLC discovery phase.
Business analysis analyzes and documents:
1. Details of system use case
(use-case description)
2. State behavior
(state-machine diagram)
Black Box Testing
Black-box testing is a method of software testing that examines the functionality of an application
(e.g. what the software does) without peering into its internal structures or workings.
This method of test can be applied to virtually every level of software testing: unit, integration,
system and acceptance. It typically comprises most if not all higher level testing, but can also
dominate unit testing as well.
Test cases are built around specifications and requirements, i.e. what the application is supposed to
do.
Test cases are derived from external description of the software, including specifications,
requirements and design parameters.
Advantages in discovering errors:
Missing functions
Functions that don’t correspond to spec
Weaknesses in the spec
Interface errors between modules
Initialization errors
Termination errors
4
Business Use Case
A business use-case diagram provides an overview of business processes and the entities involved in
the processes
Business Requirements Document (BRD)
Created during initiation process of general SDLC
Describe business requirements
Acts as a contract between the business and the developer, so it’s important that all the requirements
are documents completely and correctly
If a requirement is not found in the BRD => it’s not part of the contract
The BRD will be revised as the project progresses
Key components of the BRD produced during the Initiation phase include:
• Business use-case descriptions include business use-case diagrams
• Role map
• System use-case diagram
• Initial class diagram describing key business classes
• Activity Diagram
• Milestone/Implementation Plan
Design Patterns #implementation
Used during Implementation phase.
A pattern is essentially a template.
Design patterns range from the abstract to the concrete.
Abstract: the multilayer design pattern: separate system functions into 3 layers of class: graphic layer,
domain layer and data access layer.
Concrete: class definition that is written in code to be used by developers.
4 elements of a pattern:
1. Name
2. Problem
3. Solution
4. Constraints
These design patterns are best practices that consider various factors. Some of them are natural
solution to a problem.
1. Structural Patterns:
Model/View/Controller (MVC)
Model: Domain object (updates the view)
View: Presentation
Controller: receives commands from user and invoke the
model’s methods (direct traffic)
Commonly used for web application
5
Façade
Provides a unified interface to a set of interfaces in a subsystem
Idea is to wrap a complex subsystem with a simplified interface
Adaptor (Wrapper)
An adaptor allows classes to work together that normally
could not due to incompatible interfaces
Idea is to convert the interface of a class into another
interface that the client expects (Wrapper)
Why we need it
For two connected classes, one of them might be
replaced. Tax calculator connected to the system. When
we update from an old tax calculator to new tax
calculator. The new class might have its predefined set of
method signatures that are different from the method
signatures of the old calculator. This is where adapter comes in.
2. Creational Patterns:
Singleton
Restrict the instantiation of the class to ONE object
Purpose: A single controller to control everything. Controller can be instantiated from many places,
thus we must make sure that these instatiations only refer to a single controller.
E.g. only one audio clip to be played at one time, thus manager has to
make sure that it is the only manager (multiple mangers will play one
audio clip each)
However, manager is called from many applications.
Thus, every time they call for the manager, only one manager should be
instantiated and the reference to it is returned to the caller.
Factory
Make use of a Factory class to create
objects
Abstract Factory: A more general
version of Factory design pattern (can
have multiple Factory)
Uses a concrete implementation of the
abstract factory to create concrete
objects
6
Object Pool
Idea: want to reuse and share objects that are expensive to create
Behavorial Patterns:
Strategy
Lets you use different algorithms
(strategy) depending on the
context
Observer
Allow objects to notify other objects about events occurring
Problem: One class has attributes that change that other classes need to know about. However, the
original class does not know which other classes are interested in its internal activity. We want to
allow classes to observe this behavior without coupling them.
E.g. Order view window sends a message to domain order object, but order object should not be able
to send back to order window. (domain class should not be able to navigate to view layer, to prevent
coupling)
Scenario: When customer’s total order for the year exceeds a certain amount, there will be discounts
for the customer. Every time a customer orders, an Order object is updated. Order wants to remind
customer to buy more to take advantage of the discount, but domain class has no access to the view
layer to convey to customer this information. That is where observer comes in.
Solution: The original class has methods to
allow other classes to dynamically register
themselves for particular events
happening in the original class. E.g. when
order amount exceeds the amount for
discount. When this happens, the observer
class will notify all classes that have
registered for the event.
Example:
These two objects interact to play albums and to charge end-users each time an album is played.
The Design Patterns approach uses an abstract Subject class and an Observer interface to break the
dependency between the Subject object (Album) and the Observer (BillingService) objects. It also
allows for multiple Observers for a single Subject. In the example, the Album class inherits from
the Subject class, assuming the role of the concrete subject described in the Observer pattern.
The BillingService class takes the place of the concrete observer by implementing
the Observer interface, because the BillingService is waiting to be told when the Play method is
called.
Notice that there is no more arrow from Album to BillingService. This reduces the coupling.
7
Design Principles #Encapsulate#InfoHide#Navigate#Coupling#Cohesion
Encapsulation
Design concept that each object is a self-contained unit containing both data and program logic
Each object provides a set of services that are invoked by calling the object’s methods
Hides the details of component
Benefit:
Software developer can design the system in a building-block fashion
Object reuse: standard set of objects that are used over and over again throughout the system.
Information-Hiding
Data associated with an object is not visible to the outside world i.e. Object attributes are private
(encapsulation achieves information hiding)
Navigation Visibility
Refers to the ability of an object to view/interact with another object
Interactions between objects can only be accomplished with navigation visibility. One of the
responsibilities of a design is to specify which classes have navigation visibility to other classes
Coupling
Measure of how closely classes are linked to each other / Degree of mutual interdependence
Measured by number of navigation visibility arrows between classes: a qualitative term (cannot be
quantified)
Size: number of connections
Intimacy: Directness of connections
Visibility: Prominence of connections
Flexibility: Ease of changing connections
Highly coupled e.g. can directly access elements of another module without an interface.
Problems with tight coupling:
1. Change in one module forces a ripple effect of change in other modules
2. Assembly of modules require more effort/time due to increased inter-module dependency.
3. A particular module might be harder to reuse/test because dependent modules might be
included
Cohesion
Degree to which elements of a module belong in that module
E.g. Student class has methods that do student-related functions
Cohesion describes how focused a software is. All procedures in a given module work together
towards some end goal.
High cohesion = high readability and high maintainability and high reusability.
 Readability: functions are straightforward
 Maintainability: Not overly-sensitive to change in the system
 Reusability: Can be reused in other contexts.
Separation of responsibilities: A better design is to separate disparate tasks into direct classes.
Cohesion is how focused the software is, coupling is how reliant given piece of software is on other
modules.
8
Discipline
Discipline
Business
modeling
Purpose
Understand and communicate the nature of the
business environment in which the system will be
deployed
Requirements
Understand and document business needs and
processing requirements
Design
Develop the architecture and details of hardware,
networks, software and the database
Models
Organization chart
Location Diagram
Activity Diagram
Business Use Case
Activity Diagram
System use case
Domain model class
diagram
System sequence diagram
Design class diagram
Network diagram
Database schema
Interaction diagram
Package diagram
Discipline (Design) #Hi-LowDesign #SoftwareArchitect#CoordinateDesign
In requirement discipline, analysts build models to understand key business processes and data.
Design discipline refines and creates new models from requirement discipline. However, purpose is
different from requirement discipline.
Design model is interested in the how question:
 How will key processes be performed?
 How will key data be collected and organized?
 How will the new system achieve business objectives?
Design on two levels:
High-level – Architectural design: affects entire system
Low-level – Detail design: encompasses small part of the system with minimal impact on other parts
of the system, such as software design for a single use case
High-level (Usually in early iterations in the elaboration phase)
Design Support Services architecture and deployment environment
Modern info system operate within complex collection of computer hardwares, networks and system
software, which is collectively called the support services architecture and deployment environment.
Thus,
 Must determine whether that architecture can support the new system
 Must adapt the new system and existing architecture to one another, while ensuring that
existing systems continue to function.
 Must address technical issues: reliability, security, throughput, synchronization
Design the Software Architecture
Software architecture refers to the big picture structural aspects of an info system.
Division of software into classes and the distribution of those classes across processing locations and
specific computers.
Heavily constrained by the Support Service Architecture, e.g. software architecture within UNIX
environment is different from that based on Windows.
Design class diagram for the system is created here.
Design use case realization
Previous architectural design defined a framework within which use cases are realized.
Realization design focus on the interactions among the classes that is required to support a use case,
as well as the interactions among software, users and external systems.
Design the database
Design the system and user interfaces
Design the system security and controls
Low-level is part of all the high-level. (Low-level design is spread more evenly throughout the
project)
9
Coordinating the design
Each subsystem has unique design requirements
Project teams are divided into smaller teams to focus on the various subsystems and design issues,
with multiple iterations proceeding in parallel.
Technical issues can be related to all subsystem or only some subsystems.
People may be working at different locations.
Discipline (Requirement) #domainClass#eventDecomposition#function/nonfunction
System requirements are all of the capabilities must have and constraints that the new system must
meet.
Requirement is interested in the “what” question:
 What are the business objectives of the system?
 What info must be collected and processed?
 What are the key processes for collecting and using that info?
Functional requirements are the activities that the system must perform – that is, the business uses
to which the system will be applied. They are based on the procedures and rules that the organization
uses to run its business. E.g. All new employees must fill in the payroll form.
Non-functional requirements are characteristics of the system other than activities it must perform
or support. Below are non-functional requirements
Technical
Performance
Usability
Reliability
Security
Requirements
Requirements
Requirements - UI Requirements
Requirements
operational
Operational
Operational
Dependability of a Describes which
characteristics
characteristics
characteristics
system:
user can perform
related to the
related to
related to user:
How it detects
which system
environment,
measures of
UI
and recovers
function under
hardware and
workload:
Related work
from problems
what condition
software of the
Response time
procedures
organization.
Throughput
Documentation
Requirements can be defined via: Problem Domain class and event decomposition
Domain Class Diagram #SysRequirement
A key concept used to define system requirements
A diagram to note down the information a system needs to store. In OOP, these things become
objects that interact in the system.
Procedure to define things in the system:
1. Use event table and information about each event, identify all of the nouns.
2. Use information from existing systems, current procedures, current reports or forms, add items or
categories of info needed.
3. Refine the list and record assumptions or issues to explore
 Is it a unique thing the system needs to know about?
 Is it inside the scope of the system I am working on?
 Does the system need to remember more than one of these items?
Event Decomposition #occurrence&event
An event:
Occurs at specific time and place
Can be described
Should be remembered by the system
Event Decomposition
A technique that first focuses on the events a system needs to respond to and then looks at how a
system must respond – the system’s use cases.
10
In event decomposition, attention is on the external environment, and the system is viewed as a
black box – this initial view helps keep analyst’s focus on a high-level view of the system (looking at
the scope) rather than inner workings.
Describing a system in terms of events keeps the focus of the system on the business requirements
and the elementary business processes.
3 Types of Events:
External Events
• Occur outside the system
• Usually caused by external agent e.g. customer
Temporal Events
• Occurs when system reaches a point (deadline) in time
State Events
• Events that occur when something happen inside the system that trigger the need for
processing
Perfect technology assumption:
• Unlimited processing and storage capacity
• Equipment does not malfunction
• Users have ideal skill sets
All events might not trigger from something, therefore not all have a source
An event might not have response.
Whether an occurrence is an event or part of the interaction following the event is determined by
whether there is any long pauses or intervals. Can the system transaction be completed without
interruption or is the system at rest waiting for the next transaction? E.g. buying a shirt with cash and
credit card. System does not halt all process waiting for answer.
Implementation Plan #BRD
Included in the Business Requirement Document.
The BRD must include an implementation plan so that steps required when releasing the system
can be planned for in advance
The issues addressed typically include:
• Training
• Conversion
• Rollout
• End-user procedures
Post-implementation follow-up:
• Follow up after implementation to ensure that the project is running successfully
and to verify that the project is achieving high-level goals
11
Iterative & Incremental development #SDLCMethod#Adaptive
#UnifiedProcess
Idea: Develop a system through repeated cycles (iterative) and in smaller portions at a time
(incremental), allowing software developers to take advantage of what was learned during
development of earlier parts or versions of the system.
Learning comes from both the development and use of the system, where possible key steps in the
process start with a simple implementation of a subset of the software requirements and iteratively
enhance the evolving versions until the full system is implemented. At each iteration, design
modifications are made and new functional capabilities are added.
The procedure itself consists of the initialization step, the iteration step, and the Project Control List.
The initialization step creates a base version of the system. The goal for this initial implementation is
to create a product to which the user can react. It should offer a sampling of the key aspects of the
problem and provide a solution that is simple enough to understand and implement easily.
To guide the iteration process, a project control list is created that contains a record of all tasks that
need to be performed. It includes such items as new features to be implemented and areas of
redesign of the existing solution. The control list is constantly being revised as a result of the analysis
phase.
The iteration involves the redesign and implementation of iteration is to be simple, straightforward,
and modular, supporting redesign at that stage or as a task added to the project control list. The level
of design detail is not dictated by the iterative approach. In a light-weight iterative project the code
may represent the major source of documentation of the system; however, in a critical iterative
project a formal Software Design Document may be used. The analysis of an iteration is based upon
user feedback, and the program analysis facilities available. It involves analysis of the structure,
modularity, usability, reliability, efficiency, & achievement of goals. The project control list is
modified in light of the analysis results.
PHASES
Incremental development slices the system functionality into increments (portions). In each
increment, a slice of functionality is delivered through cross-discipline work, from the
requirements to the deployment. The unified process groups increments/iterations into 4 phases.
1. Inception identifies project scope, requirements (functional and non-functional) and risks at a high
level but in enough detail that work can be estimated.
2. Elaboration delivers a working architecture that mitigates the top risks and fulfills the nonfunctional requirements.
3. Construction incrementally fills-in the architecture with production-ready code produced from
analysis, design, implementation, and testing of the functional requirements.
4. Transition delivers the system into the production operating environment.
Each of the phases may be divided into 1 or more iterations, which are usually time-boxed rather
than feature-boxed. Architects and analysts work one iteration ahead of developers and testers to
keep their work-product backlog full.
12
Modeling
Purpose
 Process of creating a model helps analyst clarify and refine requirements and design details.
Analyst learns as he completes and studies the model.
 Information systems are complex and some parts are intangible. Models help simplify the
analyst’s efforts and focus them on a few aspects of the system at a time.
 Models help the analyst explain his work to others.
 Different models relate to different aspects of the system.
 There are even models to model the relationship between models.
Package#actor #useCase
When to use Package?
Common approaches used to group system use cases into packages:
•
Group system use cases by the main actor who uses them e.g. group together into one
package all the system use cases used by the general administration
Create a system use-case package for each business use case
E.g. for an insurance system - “Make a Claim” use case:
•
To the customer, it represents one business goal
•
However, to achieve it, the company’s workers (actor) require a number of discrete interactions
with the computer system such as Record Claim, Validate Policy, Adjust Claim, Pay
Claim
•
Each of these interactions qualifies as a system use case
•
Bundle them all in the use-case package Make a Claim
13
Predictive SDLC
Known projects can usually rely upon a predictive method of planning. Predictive planning provides a
linear, specific development plan structured around producing a pre-determined end result within a
specific timeframe.
When Objectives are Known:
The Waterfall Method
SDLC methodology – predictive - Does not allow
backlogging
The waterfall approach to project management is a
useful approach when the variables and outcomes
of a project are known. In the waterfall method, a
single episode of directive discussion is followed by
a lengthy production or development period,
ending in the delivery of the resulting project.
The steps of the waterfall method:
SDLC Phases
Most general form of software development. All other e.g.
Generalized into 5 different phases:
1. Initiation
2. Discovery
3. Construction
4. Final Verification and Validation
5. Closeout
SDLC Initiation Phase
#BRD#RoleMap#SysUseCaseDiag#InitialClassDiag#Baseline
Objective:
a. To develop the business case for the project
b. To establish project and product scope
c. To explore solutions, including the preliminary architecture
Deliverables:
A single document, the Business Requirements Document (BRD) is produced to describe the business
requirements. This document includes the business use-case descriptions, role map, system use-case
diagram, and initial class diagram.
Steps:
1. Model business use case
• Identify business use cases (business use-case diagram)
• Scope business use cases (activity diagram)
2. Model system use case from business use case
• How?
• Identify actors (role-map diagram)
• Create event tables from business use case (event tables are list of system use cases
triggered by business events)
• Create system use case diagram from actors and events.
3. Set baseline for discovery
• Baselining allows you to see what the requirements looked like at various checkpoints
14
SDLC Discovery Phase
#requirements#testing#BRD#Behavioral#Structural#Baseline
Objective: take project into analysis
Analyze and document requirements of project
Can include some testing activities (validate idea)
Includes Requirements and Testing discipline
Result of Analysis is the Business Requirement Document (BRD)
Steps:
1. Perform Behavioral Analysis
• Describe the system use case
(use-case description)
• Describe state behavior
(state-machine diagram)
2. Perform Structural Analysis
• (domain model class diagram)
3. Specify test plan
4. Specify implementation plan
5. Set baseline for development
Once the BRD is complete, freeze all analysis documentation
Save this “frozen copy” so that team members will be able to refer back to it later
This copy becomes the “baseline” – or beginning point – for the next step: the actual development of
the software.
SDLC Construction Phase#Design#Implement#Test
This is the phase when the business model is turned into a design specification.
Includes Design, Implementation and Testing discipline.
Business analysis activity during this phase depends on the lifecycle approach being used:
• Waterfall projects (predictive)
• Iterative projects (adaptive)
IF Waterfall
 IT BA’s job now is to support quality assurance and validate technical design meets the
requirements
 No requirements analysis in this phase.
IF Iterative
 Requirements analysis and solution development take place over a number of iterations
 The steps described for the Discovery phase are carried out during each iteration of the
Construction phase
Design (UI) and Coding take place
This also means the start of technical work (actual implementation of system)
Discipline
Purpose
Business Modeling Understand and communicate the nature of the business environment in
which the system will be deployed
Requirements
Understand and document business needs and processing requirements
 Focuses on what the system should do
Design
(Used in
construction
phase)
Develop the architecture and details of hardware, networks, software, and
the database
 Oriented towards how the system will be built
 Structural components
 Dynamic interactions
System Design
Discipline of describing, organizing, structuring components of a system
Commonly known as Architectural Design, General Design, or Conceptual Design
See Architecture Design
15
Design System Security and Controls
Ensure system restricts the access rights to different users
User-Interface control
Record transactions, prevent unauthorized access to DB
Ensure network communication is secure
Next: Use-case realization (designing software that implements each use case)
SDLC Final Verification & Validation phase
The IT Business Analyst supports final testing before the completed solution is deployed, reviewing
test plans and results and ensuring that all requirements are tested.
GO TO: Testing(Final Verification)
SDLC Closeout Phase #Deployment#Installing#TrainingUsers#InitializeDB
The IT Business Analyst supports the deployment process, reviewing transition plans and participating
in a post-implementation review to evaluate the success of the change.
Deployment
Activities to make a new system operational
Involve many conflicting constraints
• Costs
• Need to main positive customer relations
• Need to support employees
• Logistical complexity
• Overall risk to the organization
Considerations when planning deployment
• 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
Each deployment approach has strengths and weaknesses
1. Direct deployment (or immediate cutover):
Installs a new system, quickly makes it
operational, and immediately turns off
any overlapping systems
Advantages: Simplicity
Disadvantages: Risk of system
unavailability (no backup)
Used when:
A new system is not replacing an old
system and/or downtime can be
tolerated
2: Parallel Deployment
Operates both old and new systems for an
extended time period
Advantages: Relatively low risk of system
failure, Used for mission-critical applications
Disadvantage: Cost to operate both systems
(hiring temps, assign extra space for computer
equipment
Problems with full Parallel: Inputs to old
system might not fit new system
Usually use partial parallel deployment:
Process only a subset of input data in one of the two systems. However, entails the risk that
significant errors or problems will go undetected.
16
3. Phased Deployment
Installs a new system and makes it
operational in a series of steps or phases
Advantage: Reduced risk – failure of
single phase is less problematic than
failure of system
Disadvantages: Increased complexity –
more activities and milestones, however,
each phase contains a smaller and more
manageable set of activities.
Useful when a system is large, complex,
and composed of relatively independent
subsystems. However, difficult to
implement if the subsystems are not
substantially independent.
Closeout Phase: Acquiring hardware and
system software
Application software must have a supporting infrastructure (which may already be in place)
Acquisition of an entirely new infrastructure includes
• Planning
• Developing a request for proposal
• Evaluating results
• Choosing one or more vendors
• Installation and configuration
Packaging and Installing Components
Components must be:
• Installed on a host server
• Added to a component registry
• Assigned one or more network addresses
May include XML files to store registration and access information
Developers can package and install components using development tools and utilities
Training Users
End users and system operators need training
End user training
• Hands-on training and tutorials
• Group tutorials
System operator training
• Less formal
• Self-study
Training materials are developed as soon as the interfaces are reasonably stable
Converting and Initializing Data
Data needed at system startup can be obtained from:
• Files or databases of a system being replaced
• Manual records
• Files or databases of other systems in the organizations
• User feedback during normal system operation
Existing databases are commonly modified for reuse in new or upgraded systems
Reloading Databases
Complex changes to a database may require reloading the data after the change
2 approaches:
• Initialize a new database and copy the contents of the old database to it
• Use a program or DBMS utility to extract and delete data from an existing database and store
it in a temporary data store
17
Spiral
The
spiral
model
the incremental
is
model,
similar
with
to
more
emphasis placed on risk analysis.
4
phases:
Planning,
Risk
Analysis,
Engineering and Evaluation.
A software project repeatedly passes
through these phases in iterations (called
Spirals in this model).
Phases in spiral
1.
The baseline spiral, starting in the
planning phase, requirements are
gathered and risk is assessed. Each
subsequent spiral builds on the baseline spiral.
2.
Requirements are gathered during the planning phase.
3.
In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A
prototype is produced at the end of the risk analysis phase.
4.
Software is produced in the engineering phase, along with testing at the end of the phase.
5.
The evaluation phase allows the customer to evaluate the output of the project to date before
the project continues to the next spiral.
Advantages of Spiral model:

High amount of risk analysis hence, avoidance of Risk is enhanced.

Good for large and mission-critical projects.

Strong approval and documentation control.

Additional Functionality can be added at a later date.

Software is produced early in the software life cycle.
Disadvantages of Spiral model:

Can be a costly model to use.

Risk analysis requires highly specific expertise.

Project’s success is highly dependent on the risk analysis phase.

Doesn’t work well for smaller projects.
When to use Spiral model:

When costs and risk evaluation is important

For medium to high-risk projects

Long-term project commitment unwise because of potential changes to economic priorities

Users are unsure of their needs

Requirements are complex

New product line

Significant changes are expected (research and exploration)
18
Structural Analysis
Look at Class Diagram
System Requirement Specification
A singular documented physical and functional need that a particular design, product or process must be
able to perform.
Purpose: Identifies a necessary attribute, capability, characteristic, or quality of a system for it to have
value and utility to a customer, organization, internal user, or other stakeholder.
Sets of requirements are used as inputs into the design stages of product development.
For Waterfall model:
Requirements show what elements and functions are necessary for the particular project.
For Iterative model:
System requirements are incrementally developed in parallel with design and implementation.
System Sequence Diagram #interactionDiag #requirements #lifeline
Part of defining requirement for a system
Used to describe the flow of information into and out of the automated system.
Used in conjunction with use case description to help document the details of a single use case.
Can be developed from detailed description of the use case, either in fully developed form or as
activity diagram.
It is a type of interaction diagram.
In interaction diagrams, use object notation, not class notation. I.e. the box refers to an individual
object and not to the class of all similar objects. Messages are sent and received by individual objects,
not by a class.
Steps for developing SSD from activity diagram:
1. ID input messages (the arrows in activity diag)
2. Describe the message from external actor to the system
3. ID and add any special conditions on the input messages, including iteration and true/false
conditions
4. ID and add the output return messages.
 Either a return value on the message itself or
 A separate return message with a dashed-line arrow
System Use Case
An activity a system carries out, usually in response to a request by a user.
In the inception phase, analysts identify many of the key use cases. By the end of the elaboration
phase, they should have identified all use cases and described them in details.
Ways to identify use cases:
1. List all users and think through what they need from the system to do for their jobs.
2. Start with the current system and list all system functions that are currently included, and add any
new functionality requested by users.
The appropriate level of analysis for identifying use cases is one that focuses on elementary business
processes (EBPs). An EBP is a task performed by one person in one place, which adds measurable
business value and leaves the system and its data in a consistent state.
Each EBP (and so each use case) occurs in response to a business event. Events drive or trigger all
processing that a system does, so listing events and analyzing events make sense when you need to
define system requirements by identifying use cases. Thus, we use event decomposition to determine
what the use cases for a system are.
19
System Use Case Diagram #eventTable
After doing the event table, the analysts better understands the business processes. However,
although business events are used to identify use cases, analysts need to make adjustments to
identify the right use cases:
Adjustments from event table:
1. Combine business events into single use case.
E.g. event for adding new customer and event for changing customer information comes under the
use case: Maintain customer information.
2. Split business events into multiple use cases. Additional use cases are identified either
 When they contain the <<include>> relationship and two use cases can be developed from
one large use case
 When another use case is defined from recognizing a common subroutine.
Procedure to import from event table:
1. ID actors for each use case. ID their role as well.
2. Extract info from business events that describe the system response to the business event
Things to note:
 Assume perfect technology
 Use cases are not based on technical activities such as logging onto a system
Testing (Discovery Phase) #testingInPhases
Used to validate idea
Discovery phase includes Requirements and Testing discipline
Testing is any activity aimed at proving that the software system does not do what it is supposed
to.
 The term quality assurance is sometimes used because it suggests that more than the
physical testing of the software may be required
• e.g. verifying a draft of a system use-case description with stakeholders is a testing activity
Discovery testing produces test cases:
• By specifying tests up front, you can add measurable quality requirements to your contract
with the developers
Non-computer-based testing
Structured walkthrough throughout the project
Performed before software is written
Walk through some aspects of the system with a group of participants
Peer-review process for testing
20
Different Testing occur at various of project development:
• Structured walkthroughs are performed throughout the project
• During the Discovery phase, the test cases are designed (test cases are inputs to
determine if system runs correctly)
• During the Construction phase, unit testing (tests of the individual software
components) is carried out.
• As system use-case scenarios are implemented during the Construction phase,
requirements-based (black-box) tests are performed to verify compliance with the
requirements
• Before acceptance of the product, the developers or technical testers perform
system tests
• During the Closeout phase, the user performs and supervises user acceptance
testing (UAT)
Testing (Final Verification Phase)
#driver#stub#usabilityTest#UnitTest#IntegrationTest#UserAcceptance
Testing is a process of identifying defects
Testing activities must be distributed throughout the project:
•
Unit and integration testing occur whenever software is developed, acquired, or combined with
other software
•
Usability testing occurs whenever requirements or design decisions need to be evaluated
•
User acceptance tests are conducted as a final validation of the requirements, design, and
implementation activities
Develop test cases and test data
• A test case is a formal description of
• A starting state
• One or more events to which the software must respond
• The expected response or ending state
• Test data is a set of starting states and events used to test a module, group of
modules, or entire system
Unit Testing
The process of testing individual methods, classes, or components before they are integrated with
other software
Two methods for isolated testing of units
Driver
• Simulates the behavior of a method that sends a message to the method being tested
Stub
• Simulates the behavior of a method that has not yet been written
21
Integration Testing
Evaluates the behavior of a group of methods or classes. Purpose is to identify errors that could not
be detected by unit testing. Such errors can result from:
Interface incompatibility: e.g. one method passes a parameter of wrong data type to another method
Parameter value: A method is passed or returns a value that as unexpected, such as –ve price
Run-time exceptions: A method generates an error such as “out of memory” due to conflicting
resource needs.
Unexpected state interactions: The states of two or more objects interact to cause complex failures.
Integration testing can get very complex. Because an OO program consists of a set of interacting
objects that can be created or destroyed during execution, there is no clear hierarchical structure.
System test (a kind of integration test): test the behavior of an entire system or independent
subsystem. Ensures the system fulfills the developer’s understanding of user requirements.
Usability Testing
Determines whether a method, class, subsystem, or system meets user requirements. Can test on
functional and non-functional requirements. Most commonly evaluates functional requirements and
the quality of a user interface.
Performance test (A type of integration + usability testing)
• Determines if a system or subsystem can meet time-based performance criteria such as:
• Response time specifies the desired or maximum allowable time limit for software
responses to queries and updates
• Throughput specifies the desired or minimum number of queries and transactions that
must be processed per minute or hour
• Complex because they involve multiple programs, subsystems, computer systems and
network infrastructure. Also require large suite of test data to simulate system
operation under maximum load.
User Acceptance Testing
Determines whether the entire system fulfills user requirements
• Involves the end users
Acceptance testing is a very formal activity in most development projects
22
Unified Process Life Cycle
#incept#elaborate#construct#transit#disciplines#adaptive#architect
A popular iterative and incremental software development process framework.
It is a form of adaptive SDLC.
Iterative and Incremental:
UP is iterative & incremental development
process.
The Elaboration, Construction and
Transition phases are divided into a series
of timeboxed iterations.
Each iteration results in an increment,
which is a release of the system that
contains added or improved functionality
compared with the previous release.
Use case driven:
Use cases are used to capture the functional requirements and to define the content of the iterations.
Each iteration takes a set of use cases or scenarios from requirements all the way through to
deployment.
Architecture Centric:
The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the
system. Since no single model is sufficient to cover all aspects of a system, the Unified Process
supports multiple architectural models and views.
Risk Focused:
The Unified Process requires the project team to focus on addressing the most critical risks early in
the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be
selected in order to ensure that the greatest risks are addressed first.
Phases in UP:
Inception
Develop approximate vision for the project, define scope, and product rough
estimates for cost and schedule
Elaboration
Refine vision, identify and describe all requirements, finalize the scope, design and
implement core architecture and functions, resolve high risks, and produce realistic
estimates for cost schedule
Construction Iteratively implement remaining lower-risk, predictable, and easier elements and
prepare for deployment
Transition
Complete beta testing and deployment so users have a working system and are ready
to benefit as expected
When to involve users:
- Business Modeling discipline: they should participate in defining the problem the system
must solve, the system objectives, and benefits
- Requirements discipline: they should help define the problem domain, the requirements and
their priorities, develop the user interface dialogs, and evaluate requirements.
- Testing discipline: they will probably be most involved in usability and user acceptance
testing
- Deployment discipline: they may be involved in training other users
23
Unified Modeling Language (UML)
Unified Modeling Language (UML) combines techniques from data modeling (entity relationship
diagrams), business modeling (work flows), object modeling, and component modeling. It can be used
with all processes, throughout the software development life cycle, and across different
implementation technologies.



UML can describe structure of the source code
UML can describe the run-time behavior
UML is not (normally) executable
UML offers a standard way to visualize a system's architectural blueprints, including elements such as:

Activities / Actors

Business processes / (Logical) components / Database schemas

Programming language statements / Reusable software components
UML is extensible, with two mechanisms for customization: profiles and stereotypes.
UML diagrams
Structural UML diagrams
Emphasize the things that must be present in the system being modeled. Since structure diagrams
represent the structure, they are used extensively in documenting the software architecture of software
systems.

Class diagram: describes the structure of a system by showing the system's classes, their
attributes, and the relationships among the classes.

Component diagram: describes how a software system is split up into components and shows
the dependencies among these components.

Composite structure diagram: describes the internal structure of a class and the collaborations
that this structure makes possible.

Deployment diagram: describes the hardware used in system implementations and the
execution environments and artifacts deployed on the hardware.

Object diagram: shows a complete or partial view of the structure of an example modeled
system at a specific time.

Package diagram: describes how a system is split up into logical groupings by showing the
dependencies among these groupings.

Profile diagram: operates at the metamodel level to show stereotypes as classes with the
<<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype. The
extension relation (solid line with closed, filled arrowhead) indicates what metamodel element
a given stereotype is extending.
Behavioral UML diagrams
Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams
illustrate behavior of a system, they are used to describe the functionality of software systems.
24

Activity diagram: describes the business and operational step-by-step workflows of
components in a system. An activity diagram shows the overall flow of control. Can support
any level of use case description. (level means 1.1, 1.1.1, 1.1.1a etc)

UML state machine diagram: describes the states and state transitions of the system.

Use Case Diagram: describes the functionality provided by a system in terms of actors, their
goals represented as use cases, and any dependencies among those use cases.
Interaction diagrams
Subset of behavior diagrams, emphasize the flow of control and data among the things in the system
being modeled:

Communication diagram: shows interactions between objects or parts in terms of sequenced
messages. They represent a combination of information taken from Class, Sequence, and Use
Case Diagrams describing both the static structure and dynamic behavior of a system.

Interaction overview diagram: provides an overview in which the nodes represent
communication diagrams.

Sequence diagram: shows how objects communicate with each other in terms of a sequence of
messages. Also indicates the lifespans of objects relative to those messages.

Timing diagrams: a specific type of interaction diagram where the focus is on timing
constraints.
Use Case Realization
#DesignClassDiag#SequenceDiag#multiLayer#ObjectResponsibility#Controlle
Continued from SDLC Construction Phase (Design discipline)
This is the design of software that implements each use case.
Realization is the specification of the detailed processing that the system must do to carry out the use
case i.e. making a set of software blueprints.
Steps:
1.
2.
3.
4.
Produce a preliminary version of design class diagrams.
Develop interaction diagrams – resulting in one sequence diagram for each use case or
scenario
• Developing an interaction diagram is a multi-step process of determining which
objects work together and how they work together
Develop method names based on information developed during the design of the
interaction diagrams
Partition the design class diagram into related functions using package diagrams
• There are several ways that a system might be partitioned
1. By Subsystem
2. By Layers: a basic multilayer design consisting of the view layer (userinterface classes), the domain layer (problem domain classes from the
domain model class diagram), and the data layer (database access classes)
• Package diagrams provide an architectural, high-level view of the final system
The design class diagrams and the detailed interaction diagrams use each other as inputs for design
and are developed at the same time.
Design Class Diagram
• The first iteration is done based on the domain model and on engineering design principles
• The preliminary design class diagram is then used to help develop interaction diagrams
• As design decisions are made during development of the interaction diagrams, the results are
used to refine the design class diagram
25
The design class diagram is an extension of the domain model class diagram (More detailed)
Domain model class diagram shows a set of problem domain classes and their association
relationships
•
During specification of requirements, since it is a discovery process, analysts generally do not
worry too much about the details of the class attributes or the methods
During design, it is important to encode the details of the classes
• Private/public attributes etc.
• Parameters that are passed to the methods
• Return values from methods
• Type of the attributes, return value etc.
We complete it by integrating information from interaction diagrams and other models like
requirements.
Objective of requirements was to understand the business need, the focus was only on specifying the
classes that defined the problem domain
To build a complete object-oriented system, we must identify and specify many other design classes.
• e.g. Input window objects and Database objects are additional classes that must be defined
Sequence Diagram
Object responsibility: design principle that indicates which objects are responsible for carrying out
the system processing.
Knowing: what is an object expected to know
Doing: what is an object expected to do or initiate.
Design focus shifts from the big picture structural issues to dynamic interactions required to perform
specific task
Messages define the system behavior - This information is not explicitly shown using class diagrams.
This is where Sequence Diagram comes in.
Use case controller
Collection point for incoming messages, act as in intermediary between outside world and the
internal system.
Reduces coupling between input system and internal system by handling all inputs.
Is an artifact: created for a specific purpose just because it is needed.Analyst needs to focus on the
interactions between the classes
User Requirement Capture


Research undertaken early in a project life-cycle to establish and qualify the scope of the project.
Aim: understand the service from a user’s perspective, and to establish users’ common needs and
expectations.
 Useful for projects that have a lack of focus or to validate the existing project scope.
 Provides an independent user perspective when a project has been created purely to fulfil a
business need.
 The requirements capture findings are then used to balance the business goals with the user
needs to ensure the project is a success.
Advantage:
 Save time and money by validating the scope of a project against its users’ needs and expectations
before any work begins
 Mitigates the risk of the project launching and failing to meet its objectives
 Uncover critical information to improve the end result by answering questions such as, is the
current target audience realistic?
 Gain a deep insight into users and their needs at the very beginning, allowing them to remain
focused on serving users throughout the duration of the project.
Disadvantage:
 Increase time of planning phase
 May highlight conflicts in different user’s needs and expectations
26
User requirement document
The user requirement(s) document (URD) or user requirement(s) specification is a document usually
used in software engineering that specifies the requirements the user expects from software to be
constructed in a software project.
Used to determining what the customer actually wants it to do.
The responsibility of completely understanding what the customer wants falls on the providers of the
product because customer may not really know what they want.
User requirements must be documented as specifically and unambiguously as possible.
Once the required information is completely gathered it is documented in a URD, which is meant to
spell out exactly what the software must do and becomes part of the contractual agreement.
A customer cannot demand features not in the URD without renegotiating and a developer cannot
claim the product is ready if it does not meet an item of the URD.
The URD can be used as a guide to planning cost, timetables, milestones, testing, etc. The explicit
nature of the URD allows customers to show it to various stakeholders to make sure all necessary
features are described.
Formulating a URD requires negotiation to determine what is technically and economically feasible.
Preparing a URD is one of those skills that lies between a science and an art, requiring both software
technical skills and interpersonal skills.
Often a URD includes priority ranking for each requirement. A typical system might be as follows:

M Mandatory requirement. This feature must be built into the final system.

D Desirable requirement. This feature should be built into the final system unless the cost is too
high.

O Optional requirement.

E Possible future enhancement.
White box testing
White-box testing is a method of testing software that tests internal structures or workings of an
application, as opposed to its functionality.
In white-box testing an internal perspective of the system, as well as programming skills, are used to
design test cases. The tester chooses inputs to exercise paths through the code and determine the
appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT).
It is usually done at the unit level. It can test paths within a unit, paths between units during
integration, and between subsystems during a system–level test.
This method of test design can uncover many errors but might not detect unimplemented parts of
the specification or missing requirements.
Clearly better than bb testing on individual small modules because it gets into a level of detail
Discovers extra non-specified functions e.g. non-documented illegal options supplied by malicious
programmer
27