Glossary of terms

Table of ContentsACTIVITY DIAGRAM #WORKFLOW..............................................................................................................2ACTORS.................................................................................................................................................2ADAPTIVE SDLC.....................................................................................................................................3ARCHITECTURE #CENTRALIZED# #COMPUTERNETWORK#MULTI-TIER#EXTRANET PG272.......................................4BEHAVIORAL ANALYSIS #SDLCDISCOVERY#SYSUSECASE#STATECHART.............................................................4BLACK BOX TESTING................................................................................................................................4BUSINESS USE CASE................................................................................................................................5BUSINESS REQUIREMENTS DOCUMENT (BRD)..............................................................................................5DESIGN PATTERNS #IMPLEMENTATION........................................................................................................5DESIGN PRINCIPLES #ENCAPSULATE#INFOHIDE#NAVIGATE#COUPLING#COHESION.............................................8DISCIPLINE.............................................................................................................................................9DISCIPLINE (DESIGN) #HI-LOWDESIGN #SOFTWAREARCHITECT#COORDINATEDESIGN..........................................9DISCIPLINE (REQUIREMENT) #DOMAINCLASS#EVENTDECOMPOSITION#FUNCTION/NON-FUNCTION.......................10DOMAIN CLASS DIAGRAM #SYSREQUIREMENT...........................................................................................10EVENT DECOMPOSITION #OCCURRENCE&EVENT.........................................................................................10IMPLEMENTATION PLAN #BRD................................................................................................................11ITERATIVE & INCREMENTAL DEVELOPMENT #SDLCMETHOD#ADAPTIVE #UNIFIEDPROCESS................................12MODELING..........................................................................................................................................13PACKAGE#ACTOR #USECASE...................................................................................................................13PREDICTIVE SDLC.................................................................................................................................14THE WATERFALL METHOD......................................................................................................................14SDLC PHASES......................................................................................................................................14SDLC INITIATION PHASE #BRD#ROLEMAP#SYSUSECASEDIAG#INITIALCLASSDIAG#BASELINE............................14SDLC DISCOVERY PHASE #REQUIREMENTS#TESTING#BRD#BEHAVIORAL#STRUCTURAL#BASELINE.......................15SDLC CONSTRUCTION PHASE#DESIGN#IMPLEMENT#TEST............................................................................15SDLC FINAL VERIFICATION & VALIDATION PHASE.......................................................................................16SDLC CLOSEOUT PHASE #DEPLOYMENT#INSTALLING#TRAININGUSERS#INITIALIZEDB.......................................16SPIRAL................................................................................................................................................18STRUCTURAL ANALYSIS...........................................................................................................................19SYSTEM REQUIREMENT SPECIFICATION......................................................................................................19SYSTEM SEQUENCE DIAGRAM #INTERACTIONDIAG #REQUIREMENTS #LIFELINE.................................................19SYSTEM USE CASE.................................................................................................................................19SYSTEM USE CASE DIAGRAM #EVENTTABLE...............................................................................................20TESTING (DISCOVERY PHASE) #TESTINGINPHASES.......................................................................................20TESTING (FINAL VERIFICATION PHASE) #DRIVER#STUB#USABILITYTEST#UNITTEST#INTEGRATIONTEST#USERACCEPTANCE............................................21UNIFIED PROCESS LIFE CYCLE #INCEPT#ELABORATE#CONSTRUCT#TRANSIT#DISCIPLINES#ADAPTIVE#ARCHITECT.......23UNIFIED MODELING LANGUAGE (UML)....................................................................................................24USE CASE REALIZATION #DESIGNCLASSDIAG#SEQUENCEDIAG#MULTILAYER#OBJECTRESPONSIBILITY#CONTROLLE..25USER REQUIREMENT CAPTURE.................................................................................................................26USER REQUIREMENT DOCUMENT..............................................................................................................27WHITE BOX TESTING..............................................................................................................................27

1

Activity Diagram #workFlowDocuments 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.

ActorsUsed in system use case

Stereotype = Extension of a UML featureCan invent their own stereotypes to create extended meanings to UML model elementsE.g. <<Actor>>, <<Interface>>, etcAfter identifying the actorsGeneralize 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 systemsRole Map:A diagram used to standardize the treatment of users and external systemsUnlike use-case diagram, only shows actors and how actors are related

The arrow allows user to model actors with overlapping rolesThink 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 RolesCan model the manager actor as an abstract actor

• More specifically abstract generalized actorThe 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 SDLCWhen Objectives are Unknown: Agile MethodologiesAgile 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 managerAlthough 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 methodDoes 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 goalEnable the next effort as your secondary goalMinimize your modeling activityEmbrace change, and change incrementallyModel with a purposeBuild multiple modelsBuild high quality models and get feedback rapidlyFocus on content rather than representationLearn from each other with open communicationKnow your models and how to use themAdapt to specific project needs

3

Architecture #centralized# #computerNetwork#multi-tier#Extranet pg272Centralized: 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 information-processing 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#StateChartThis 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 TestingBlack-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 functionsFunctions that don’t correspond to specWeaknesses in the specInterface errors between modules Initialization errorsTermination errors

4

Business Use CaseA 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 SDLCDescribe business requirementsActs as a contract between the business and the developer, so it’s important that all the requirements are documents completely and correctlyIf a requirement is not found in the BRD => it’s not part of the contractThe BRD will be revised as the project progressesKey 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 #implementationUsed 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. Name2. Problem3. Solution4. 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: PresentationController: receives commands from user and invoke the model’s methods (direct traffic)Commonly used for web application

5

FaçadeProvides a unified interface to a set of interfaces in a subsystemIdea 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 interfacesIdea is to convert the interface of a class into another interface that the client expects (Wrapper)Why we need itFor 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:SingletonRestrict the instantiation of the class to ONE objectPurpose: 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.

FactoryMake use of a Factory class to create objectsAbstract 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 PoolIdea: want to reuse and share objects that are expensive to create

Behavorial Patterns:StrategyLets you use different algorithms (strategy) depending on the context

ObserverAllow objects to notify other objects about events occurringProblem: 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#CohesionEncapsulation Design concept that each object is a self-contained unit containing both data and program logicEach object provides a set of services that are invoked by calling the object’s methodsHides the details of componentBenefit:Software developer can design the system in a building-block fashionObject reuse: standard set of objects that are used over and over again throughout the system.

Information-HidingData associated with an object is not visible to the outside world i.e. Object attributes are private(encapsulation achieves information hiding)

Navigation VisibilityRefers 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

CouplingMeasure 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 connectionsIntimacy: Directness of connectionsVisibility: Prominence of connectionsFlexibility: Ease of changing connectionsHighly 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 modules2. 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

CohesionDegree to which elements of a module belong in that moduleE.g. Student class has methods that do student-related functionsCohesion 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

DisciplineDiscipline Purpose ModelsBusiness modeling

Understand and communicate the nature of the business environment in which the system will be deployed

Organization chartLocation DiagramActivity DiagramBusiness Use Case

Requirements Understand and document business needs and processing requirements

Activity DiagramSystem use caseDomain model class diagramSystem sequence diagram

Design Develop the architecture and details of hardware, networks, software and the database

Design class diagramNetwork diagramDatabase schemaInteraction diagramPackage diagram

Discipline (Design) #Hi-LowDesign #SoftwareArchitect#CoordinateDesignIn 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 systemLow-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 environmentModern 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 ArchitectureSoftware 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 realizationPrevious 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 databaseDesign the system and user interfacesDesign 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 designEach subsystem has unique design requirementsProject 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/non-functionSystem 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 requirementsTechnical Requirements

Performance Requirements

Usability Requirements - UI

Reliability Requirements

Security Requirements

operational characteristics related to the environment, hardware and software of the organization.

Operational characteristics related to measures of workload:Response timeThroughput

Operational characteristics related to user:UIRelated work proceduresDocumentation

Dependability of a system:How it detects and recovers from problems

Describes which user can perform which system function under what condition

Requirements can be defined via: Problem Domain class and event decomposition

Domain Class Diagram #SysRequirementA key concept used to define system requirementsA 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&eventAn event:Occurs at specific time and placeCan be describedShould be remembered by the systemEvent DecompositionA 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

processingPerfect 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 sourceAn 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 advanceThe 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 #UnifiedProcessIdea: 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 non-functional 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 administrationCreate a system use-case package for each business use caseE.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 SDLCKnown 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 MethodSDLC methodology – predictive - Does not allow backloggingThe 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 PhasesMost general form of software development. All other e.g. Generalized into 5 different phases:

1. Initiation2. Discovery3. Construction4. Final Verification and Validation5. Closeout

SDLC Initiation Phase #BRD#RoleMap#SysUseCaseDiag#InitialClassDiag#BaselineObjective:

a. To develop the business case for the projectb. To establish project and product scopec. 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#BaselineObjective: take project into analysisAnalyze and document requirements of projectCan include some testing activities (validate idea)Includes Requirements and Testing disciplineResult 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 plan4. Specify implementation plan5. Set baseline for developmentOnce the BRD is complete, freeze all analysis documentationSave this “frozen copy” so that team members will be able to refer back to it laterThis 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 placeThis also means the start of technical work (actual implementation of system)Discipline PurposeBusiness 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 DesignDiscipline of describing, organizing, structuring components of a systemCommonly known as Architectural Design, General Design, or Conceptual DesignSee Architecture Design

15

Design System Security and ControlsEnsure system restricts the access rights to different users User-Interface controlRecord transactions, prevent unauthorized access to DBEnsure network communication is secureNext: Use-case realization (designing software that implements each use case)

SDLC Final Verification & Validation phaseThe 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#InitializeDBThe IT Business Analyst supports the deployment process, reviewing transition plans and participating in a post-implementation review to evaluate the success of the change.DeploymentActivities to make a new system operationalInvolve 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 systemsAdvantages: SimplicityDisadvantages: 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 periodAdvantages: Relatively low risk of system failure, Used for mission-critical applicationsDisadvantage: Cost to operate both systems (hiring temps, assign extra space for computer equipmentProblems with full Parallel: Inputs to old system might not fit new systemUsually 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 phasesAdvantage: Reduced risk – failure of single phase is less problematic than failure of systemDisadvantages: 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 softwareApplication 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 ComponentsComponents 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 informationDevelopers can package and install components using development tools and utilities

Training UsersEnd users and system operators need trainingEnd 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 DataData 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 DatabasesComplex changes to a database may require reloading the data after the change2 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 store17

Spiral

The spiral model is similar to

the incremental model, with 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 AnalysisLook at Class Diagram

System Requirement SpecificationA 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 #lifelinePart of defining requirement for a systemUsed 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 system3. ID and add any special conditions on the input messages, including iteration and true/false conditions4. 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 CaseAn 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 #eventTableAfter 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) #testingInPhasesUsed to validate ideaDiscovery phase includes Requirements and Testing disciplineTesting 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 activityDiscovery testing produces test cases:

• By specifying tests up front, you can add measurable quality requirements to your contract with the developers

Non-computer-based testingStructured walkthrough throughout the projectPerformed before software is writtenWalk through some aspects of the system with a group of participantsPeer-review process for testingDifferent Testing occur at various of project development:

20

• 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#UserAcceptanceTesting is a process of identifying defectsTesting 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 TestingThe process of testing individual methods, classes, or components before they are integrated with other softwareTwo methods for isolated testing of unitsDriver

• Simulates the behavior of a method that sends a message to the method being testedStub

• Simulates the behavior of a method that has not yet been written

Integration Testing

21

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 methodParameter value: A method is passed or returns a value that as unexpected, such as –ve priceRun-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 TestingDetermines 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 TestingDetermines 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#architectA 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 scheduleElaboration 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 diagramsEmphasize 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.

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.

24

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#ControlleContinued 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. Produce a preliminary version of design class diagrams. 2. 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 together3. Develop method names based on information developed during the design of the interaction

diagrams4. Partition the design class diagram into related functions using package diagrams

• There are several ways that a system might be partitioned1. By Subsystem2. By Layers: a basic multilayer design consisting of the view layer (user-

interface 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 diagramThe 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

25

• 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 domainTo 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 DiagramObject responsibility: design principle that indicates which objects are responsible for carrying out the system processing. Knowing: what is an object expected to knowDoing: 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 taskMessages define the system behavior - This information is not explicitly shown using class diagrams. This is where Sequence Diagram comes in.

Use case controllerCollection 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

User requirement documentThe 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.

26

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 testingWhite-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 detailDiscovers extra non-specified functions e.g. non-documented illegal options supplied by malicious programmer

27