Kollaborative Klassroom Template

Business Information Systems
Application Development II

The Development Process

Prithwis Mukerjee, Ph.D.

Building Software

Software Development Life Cycle

Iterative Software Development

The Unified Process

What is a process ?

A series of steps that specify the way Clients

Analysts

Designers

Programmers

Would work together to create a new system

A process defines Who is doing What, When and How to reach a certain goal. In software engineering the goal is to build a software product or to enhance an existing one

Various Processes exist SDLC Process / Waterfall Method

Unified Process / Unified Modeling Language

System Development Life Cycle

Functional Specification

Program Review ChecklistComplexityDetermination / EstimateTechnicalSpecification

Test

SupportUnit Test PlanProgram Source CodeCode Bundle / DemoUnit Test ResultsSupport(optional)Pre-Production Support

Technical ReviewClient
Review Client
Review Programmer DrivenUSER DrivenFunctional
Design EstimateTechnical
DesignDeliverTestSupportDevelopMethodology ComponentCommunication & Coordination
(all teams)

Technical Design WalkthroughCode ReviewClient Sign Off

LegendTask With DeliverableTask Without DeliverableOptional Service AreaProcess Checkpoint

The WaterFall Method A simplified view

Analysis

Design

Coding

Test / Deploy

Users define what they wantfrom the system

Programmers re-define what theybelieve the users want in a morestructured manner

Actual program is built usingan appropriate computerlanguage like C, Java, VisualBasic

Application is tested and thendeployed in the end users machine

The WaterFall Method Deliverables

Analysis

Design

Coding

Test / Deploy

Requirements Analysis Documentwritten in simple English language

Systems Specifications written in terms of e.g. TABLES, COLUMNS, METHODS, FUNCTIONS

Programs written in an appropriatelanguage and tested individually.Unit Test Report for each program

All programs tested together toensure compatibility and consistencyIntegration Test Report

Waterfall Process Assumptions

Requirements are known up front before designIn reality, users do not know what they want

They certainly cannot visualise what the final thing will look like

Requirements rarely changeThey always will, however much you hate it

Design can be conducted in a purely abstract space, or trial rarely leads to error

The technology will all fit nicely into place when the time comes (the apocalypse)

Waterfall Process Limitations

Big Bang Delivery Theory

The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced.

Late deployment hides many lurking risks:technological (well, I thought they would work together...)

conceptual (well, I thought that's what they wanted...)

personnel (took so long, half the team left)

User doesn't get to see anything real until the very end, and they always hate it.

System Testing doesn't get involved until later in the process.

What did the customer really want ?

An Iterative Development Process...

Recognizes the reality of changing requirementsCaspers Joness research on 8000 projects40% of final requirements arrived after the analysis phase, after development had already begun

Promotes early risk mitigation, by breaking down the system into mini-projects and focusing on the riskier elements firstAllows you to plan a little, design a little, and code a little

Encourages all participants, including testers, integrators to be involved earlier onAllows the process itself to modulate with each iteration, allowing you to correct errors sooner and put into practice lessons learned in the prior iteration

Focuses on component architectures, not final big bang deployments

An Incremental Development Process...

Allows for software to evolve, not be produced in one huge effortAllows software to improve, by giving enough time to the evolutionary process itself

Forces attention on stability, for only a stable foundation can support multiple additionsAllows the system (a small subset of it) to actually run much sooner than with other processes

Allows interim progress to continue through the stubbing of functionality

Allows for the management of risk, by exposing problems earlier on in the development process

Goals and Features of Each Iteration

The primary goal of each iteration is to slowly chip away at the risk facing the project, namely:performance risks

integration risks (different vendors, tools, etc.)

conceptual risks (ferret out analysis and design flaws)

Perform a mini-waterfall project that ends with a delivery of something tangible in code, available for scrutiny by the interested parties, which produces validation or correctivesThe result of a single iteration is an increment--an incremental improvement of the system, yielding an evolutionary approach

Incremental Model

Non-incremental, e.g. Waterfall, rapid prototyping modelsOperational quality complete product at end

Incremental modelOperational quality portion of product within weeks

Each release adds more functionality, i.e., a new increment

DesignCodingTestDeploymentDesignCodingTestDeploymentDesignCodingTestDeploymentRequirements

Release 1Release 2Release 3

Evolutionary Model

AdvantagesConstant customer involvement and validation

Allows for good risk management

DisadvantagesBuild-and-fix danger

Contradiction in terms

New versions implement new and evolving requirements

DesignCodingTestDeploymentRequirementsDesignCodingTestDeploymentRequirementsDesignCodingTestDeploymentRequirements

FeedbackVersion 1Version 1Version 1

Spiral model

Radial dimension: cumulative cost to dateAngular dimension: progress through the spiralIf all risks cannot be resolved, the project is immediately terminated

The Unified Process

Unified Process (UP) is a methodology proposed by three amigos: Booch, Jacobson, RumbaughThey are also the co-developers of the Unified Modeling Language (UML). They formed a company called Rational which was bought over by IBM

Non Commercial and Free piece of knowledge

Rational Unified Process The proprietory process, based on the Unified Process, along with a suite of tools that allow one to use the process effectively

Commercial Product

What is UML

Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication.

Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge.

It is the result of unifying the information systems and technology industrys best engineering practices (principals, techniques, methods and tools).

UML Consists of a set of Artefacts

Unified Process : 4 Phases

InceptionBusiness case

Scope

Vague estimates

Continue or stop?

ElaborationIdentification of most requirements

Iterative implementation of the core architecture

resolution of high risks

InceptionElaborationConstructionTransition

timeConstructionIterative implementation of lower risk elements

Preparation for deployment

TransitionBeta tests

Deployment

Iterative and Incremental Development

development is organized into a series of iterations short fixed-length mini-projects (2 to 6 weeks)

timeboxed (i.e. fixed length iterations)shift tasks to future iterations if necessary ...

an iteration represents a complete development cycleincl. requirements,

the outcome of each iteration:
a tested, integrated and executable system

PreliminaryIteration

Iter. #1Iter. #2

InceptionElaborationConstructionTransition

Milestone

Release

Final productionrelease

1. Inception Phase

Obtain buy-in from all interested parties

Capture initial requirements

Analyse Cost and Benefits

Analyse Initial Risks

Define Scope of Project

Define candidate architectureLanguage ? RDBMS ? Tiers ?

Develop a disposable prototypeLook and Feel of the application

2. Elaboration Phase

Define System RequirementsDevelop USE CASE MODELSActors

USE CASE

Scenarios

Use Case Diagrams

Use Case Descriptions

Develop Class diagrams

Define Glossary of terms

Refine Risk Assesment

Revised Architecture Document

3. Construction Phase

From paper documents to computer programsCumulative increase in functionality

Increasing depth of implementation Stubs fleshed out

Implementation of bells and whistles

Increasing severity of testingMore and more complex test cases

implement all details, not only those of central architectural value

Analysis continues, but design and coding predominate

4. Transition Phase

Transfer of the system to the user community

Includes manufacturing, shipping, installation, training, technical support and maintenance

Development team begins to shrink

Control is moved to maintenance team

Alpha, Beta, and final releases

Software updates

Integration with existing systems (legacy, existing versions, etc.)

Unified Process Disciplines

ManagementEnvironmentBusiness ModelingImplementationTestDesignPreliminary
Iteration(s) Iter.
#1

PhasesProcess DisciplinesIterations

Iter.
#2 Iter.
#n Iter.
#n+1 Iter.
#n+2 Iter.
#m Iter.
#m+1Deployment

Configuration MgmtRequirements

ElaborationTransitionInceptionConstruction

Supporting Disciplines

Use Case Model : Actors

Actors will interact with the systemInput Information

Request Information

Who could be Distinct individuals

Same individual with multiple roles

Other computer systems

Product Manager

Salesman

ProductionPlanning System

FinancialSystem

Use Case Models

Define the tasks that the Actors will pursue for exampleDefine a Product

Define a new Customer

Create an Order

List of all Outstanding Orders

List of all fulfilled Orders

Create USE CASE diagramUML syntaxStick figures - actors

Ovals use cases

System boundaryNo control on anything outside the system

Product Manager

Salesman

Define Customer

Define Product

Create Order

DisplayOutstandingOrders

Update Order

Use Case Diagrams

Use Case Diagrams describe the functionality of a system and users of the system. These diagrams contain the following elements: Actors, which represent users of a system, including human users and other systems.

Use Cases, which represent functionality or services provided by a system to users.

Scenarios

A USE CASE could consist of a number of scenariosA USE CASE specifies a goalCreate ORDER, Create Customer

A SCENARIO represents a particular outcome when attempting to reach the goal. Create OrderOld customer, good credit rating

New customer, no credit rating

Old customer, bad credit rating

The action to be followed in each case will be different

In a formal development process, each scenario would have its own documentation describing in detail all the events in the scenario

Use Case Descriptions

Detailed Description of what the USE CASE meansThe USE CASE diagram gives the big picture but does not provide detailed description of what is happening

Various formats are possibleParagraph of text

Two Column approachFirst column : Actor action

Second column : System action

More complexity Pre-condition

Post-condition

Sequence of steps

Activity Diagram or Flowchart

Sequence Diagram

Activity Diagram

DisplayOrder EntryScreenDoesCustomer exist ?Order valuewithincredit ?

Define Customer

Add Order RecordDisplayError Message

NO

NO

From Use Cases to Classes

Nouns in the Use Cases are candidates forClasses Order, Customer

Attributes Order number, customer id

Verbs in the Use Cases are candidates for Methods

Identification of Classes, Attributes, Methods is an iterative process

Class Diagram is the connection betweenObject Oriented Programming techniques of the Unified Process and

Data Modelling techniques that result in Entities and Attributes in Third Normal form

Class Diagrams

ORDER

CUSTOMER

ORDER ITEM

PRODUCT

N1Receive, Update, Bill

Create, Deliver

Create, Update, CreditCheck, ...

Create, SetPrice

N1

N1

Mandatory, Must Have

Optional, May Have

Class Diagrams

Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves. These diagrams contain the following elements. Classes, which represent entities with common characteristics or features. These features include attributes, operations and associations.

Associations, which represent relationships that relate two or more other classes where the relationships have common characteristics or features. These attributes and operations.

Sequence Diagram

Salesman

:MainScreen

: OrderEntry Screen

: OrderItem Screen

Order

Order-Item

New

New

Get Data

New

: OrderItem Screen

New

Get Data

New

X

New

Start

Challenge

ID/PW

X

Sequence Diagrams

Sequence Diagrams describe interactions among classes. These diagrams focus on classes and the messages they exchange to accomplish some desired behavior. Sequence diagrams contain the following elements: Class roles, which represent roles that objects may play within the interaction.

Lifelines, which represent the existence of an object over a period of time.

Activations, which represent the time during which an object is performing an operation.

Messages, which represent communication between objects.

UML Diagrams Are Key System Artifacts

Actor A

Use Case 1

Use Case 2

Actor B

Document

FileManager

GraphicFile

File

Repository

DocumentList

FileList

Customer

nameaddrwithdraw()fetch()send()receive()

Forward Engineering(Code Generation)and Reverse Engineering

Executable System

User InterfaceDefinitionDomain Expert

Use Case 3

Source Code edit, compile, debug, link

Use-Case DiagramClass DiagramCollaboration DiagramSequence DiagramComponent
DiagramState DiagramPackage
DiagramDeployment
DiagramClassThe UML provides a single, common modeling language that is useable across many methods, across the entire lifecycle, and across many different implementation technologies. It maps the artifacts between business engineering, requirements capture and analysis, design, implementation, and test. It defines an expressive and consistent notation that can point out omissions and inconsistencies. It scales to support very small to very large systems development. If facilitates effective communications with all members of the development team.

We are beginning the transition from the UML to the RUP. The students are not expected to be able to read this slide. The point is just to summarize all of the UML diagrams used for visual modeling. You might point out that learning the UML and all of its diagrams is not enough for a developer to be successful. It is similar to learning a natural language like English by reading the dictionary. You might know all the words and even the syntax, but you wouldnt be able to effectively communicate. So the UML is a crucial first step as it gives us a common language with which to communicate. But a process is needed to understand how to apply the UML to ensure successful development efforts. Thats why we developed the RUP. Activity diagrams are not shown on the slide. Activity diagrams can be used to model workflows in business process engineering.

Benefits of a Use-Case Driven Process

Use cases are concise, simple, and understandable by a wide range of stakeholdersEnd users, developers and acquirers understand functional requirements of the system

Use cases drive numerous activities in the process:Creation and validation of the design model

Definition of test cases and procedures of the test model

Planning of iterations

Creation of user documentation

System deployment

Use cases help synchronize the content of different models

The important point to get across is that use cases permeate all parts of RUP and are a key mechanism in accomplishing the Managing Requirements best practice.

Summary: Unified Process

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of a software-intensive system

A software development process defines Who is doing What, When and How in building a software product

The Rational Unified Process has four phases: Inception, Elaboration, Construction and Transition

Each phase ends at a major milestone and contains one or more iterations

An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release

Rational Unified Process is a commercial version of this methodology developed by IBM / Rational

Click to edit the title text format

Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline LevelEighth Outline Level

Ninth Outline Level

Prithwis Mukerjee

Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline LevelEighth Outline Level

Ninth Outline Level

Order ID

Item ID

Product ID

Item quantity

Item Deliver Date

???Page ??? (???)02/02/2008, 11:34:44Page / Product ID

Product Desc

Product unit price

???Page ??? (???)02/02/2008, 11:34:44Page / Customer ID

Customer Name

Customer Address

Customer Credit Limit

???Page ??? (???)02/02/2008, 11:43:51Page / Order ID

Order Date

Customer ID

Order Value

???Page ??? (???)02/02/2008, 11:43:51Page /