Models Object-Oriented Software Engineering CS350.

47
Models Models Object-Oriented Software Engineering CS350

Transcript of Models Object-Oriented Software Engineering CS350.

Page 1: Models Object-Oriented Software Engineering CS350.

ModelsModelsObject-Oriented Software EngineeringCS350

Page 2: Models Object-Oriented Software Engineering CS350.

Types of ModelsTypes of ModelsPrototypesWatefallSpiral

Page 3: Models Object-Oriented Software Engineering CS350.

PrototypingPrototyping1960s and 1970s◦Monolithic development cycle◦Building the entire program first◦Then working out inconsistencies

between design and implementation◦Led to higher software costs and poor

estimates of time and cost◦Called the "Slaying the (software) Dragon"

technique

Page 4: Models Object-Oriented Software Engineering CS350.

Prototyping ProcessPrototyping Process Identify basic requirements

◦ Determine basic requirements including the input and output information desired

◦ Details, such as security, can typically be ignored

Develop Initial Prototype◦ The initial prototype is developed that includes only user interfaces

Review◦ The customers, including end-users, examine the prototype and provide

feedback on additions or changes

Revise and Enhance the Prototype◦ Using feedback both specifications and prototype can be improved

◦ Negotiation about what is within the scope of the contract/product may be necessary

Repeat steps #3 and #4 as needed

Page 5: Models Object-Oriented Software Engineering CS350.

Dimensions of PrototypesDimensions of PrototypesHorizontal prototypesVertical prototypes

Page 6: Models Object-Oriented Software Engineering CS350.

Horizontal PrototypeHorizontal PrototypeUser interface prototypeProvides a broad view of an entire system or

subsystemFocuses on user interaction more than low-level

system functionalityUseful for:

◦ Confirmation of user interface requirements and system scope

◦ Demonstration version of the system to obtain buy-in from the business

◦ Develop preliminary estimates of development time, cost and effort

Page 7: Models Object-Oriented Software Engineering CS350.

Vertical PrototypeVertical PrototypeMore complete elaboration of a single

subsystem or functionUseful for obtaining detailed requirements

for a given function, with the following benefits:◦Refinement database design◦Obtain information on data volumes and system

interface needs, for network sizing and performance engineering

◦Clarifies complex requirements by drilling down to actual system functionality

Page 8: Models Object-Oriented Software Engineering CS350.

Types of PrototypingTypes of PrototypingThrowaway (Rapid) prototypingEvolutionary prototypingIncremental prototypingExtreme prototyping

Page 9: Models Object-Oriented Software Engineering CS350.

Throwaway PrototypingThrowaway PrototypingWrite preliminary requirementsDesign the prototypeUser experiences/uses the prototype,

specifies new requirementsRepeat if necessaryWrite the final requirementsDevelop the real products

Page 10: Models Object-Oriented Software Engineering CS350.

Throwaway PrototypingThrowaway Prototyping “Close-ended prototyping” Creation of a model that will eventually be discarded rather

than becoming part of the final delivered software After preliminary requirements, a simple working model is

constructed Involves creating a working model of various system parts at

a very early stage Usually quite informal Most important factor is speed Model becomes starting point from which users can re-

examine expectations and clarify requirements Then the prototype model is 'thrown away'

Page 11: Models Object-Oriented Software Engineering CS350.

Throwaway PrototypingThrowaway PrototypingCan be done quicklyQuick feedback may enable early refinementCan be extremely cost effective

◦ Nothing at this point to redo

Cost of “fixes” grows exponentially with timeSpeed is crucial in implementing a throwaway

prototype, given limited budget of time and moneyAbility to construct interfaces that the users can

testBy seeing the interface, user can more easily grasp

how the system will work

Page 12: Models Object-Oriented Software Engineering CS350.

Throwaway PrototypingThrowaway PrototypingMore effective manner to deal with user

requirements-related issuesGreater enhancement to software

productivity overallIgnores issues of evolvability,

maintainability, and software structureRequirements can be identified, simulated,

and tested far more quickly and cheaplyPrototypes can be classified according to

the fidelity, interaction and timing

Page 13: Models Object-Oriented Software Engineering CS350.

Evolutionary PrototypingEvolutionary Prototyping“Breadboard prototyping”Main goal is to build a very robust

prototype in a structured manner and constantly refine it

System is continually refined and rebuiltAcknowledges that we do not

understand all the requirementsBuilds only those that are well

understood

Page 14: Models Object-Oriented Software Engineering CS350.

Evolutionary PrototypingEvolutionary PrototypingThis technique allows the development team to add

features, or make changes that couldn't be conceived during the requirements and design phase.

To be useful, system must evolve through useA product is never "done"System defined using where we are nowAssumptions made about the way business will be

conducted and the technology base usedPlan is enacted to develop the capabilitySooner or later, something resembling the

envisioned system is delivered

Page 15: Models Object-Oriented Software Engineering CS350.

Evolutionary PrototypingEvolutionary PrototypingAs opposed to Throwaway Prototypes,

they are functional systemsMay be used on an interim basis until

the final system is deliveredNot unusual to put an initial prototype

to practical use while waiting for a more developed version

User may decide that a 'flawed' system is better than no system at all

Page 16: Models Object-Oriented Software Engineering CS350.

Evolutionary PrototypingEvolutionary PrototypingDevelopers can focus on developing parts

of the system they understandTo minimize risk, developer does not

implement poorly understood featuresUsers detect opportunities for new features

and give requests to developersDevelopers use requests to change the

software-requirements specification, update the design, recode and retest

Page 17: Models Object-Oriented Software Engineering CS350.

Incremental PrototypingIncremental PrototypingFinal product is built as separate

prototypes. At the end the separate prototypes are merged in an overall design.

Page 18: Models Object-Oriented Software Engineering CS350.

Extreme PrototypingExtreme PrototypingUsed especially for developing web

applicationsThree phases:◦Static prototype that consists mainly of

HTML pages◦Screens are programmed and fully

functional using a simulated services layer◦Services are implemented

Page 19: Models Object-Oriented Software Engineering CS350.

Advantages of PrototypingAdvantages of PrototypingReduced time and costs

◦ Can improve the quality of requirements and specifications provided to developers

◦ Early determination of what the user really wants can result in faster and less expensive software

Improved and increased user involvement◦ Requires user involvement

◦ Provides better and more complete feedback and specifications

◦ Prevents many misunderstandings and miss-communications

◦ Can result in final product that has greater tangible and intangible quality

Page 20: Models Object-Oriented Software Engineering CS350.

Disadvantages of PrototypingDisadvantages of Prototyping Insufficient analysis

◦ Can distract developers from properly analyzing the complete project

◦ Can lead to overlooking better solutions

◦ May not scale well

User confusion of prototype and finished system◦ Think that a prototype is a final system

◦ Expect the prototype accurately models performance of final system

◦ Become attached to included features removed for final system

Page 21: Models Object-Oriented Software Engineering CS350.

Disadvantages of PrototypingDisadvantages of PrototypingDeveloper misunderstanding of user

objectives:◦May assume that users share their,

without understanding wider commercial issues

◦May commit delivery before reviewing user requirements

Developer attachment to prototype:◦Become attached to prototypes they have

spent a great deal of effort producing

Page 22: Models Object-Oriented Software Engineering CS350.

Disadvantages of PrototypingDisadvantages of PrototypingExcessive development time of the

prototype◦May try to develop a prototype that is too

complex◦Users can become stuck in debates over details

of the prototypeExpense of implementing prototyping◦Start up costs for building a development team

focused on prototyping may be high◦Many companies tend to jump into prototyping

without appropriately retraining workers

Page 23: Models Object-Oriented Software Engineering CS350.

Disadvantages of PrototypingDisadvantages of PrototypingHigh expectations for productivity with

insufficient effort behind the learning curve

Overlooked need for developing corporate and project specific underlying structure to support the technology

Page 24: Models Object-Oriented Software Engineering CS350.

Best projects to use prototypingBest projects to use prototyping

Analysis and design of on-line systems, especially for transaction processing

Systems with little user interaction, such as batch processing

Systems that mostly do calculationsDesigning human-computer interfaces

Page 25: Models Object-Oriented Software Engineering CS350.

MethodsMethodsDynamic systems developmentOperational prototypingEvolutionary rapid developmentScrum

Page 26: Models Object-Oriented Software Engineering CS350.

Dynamic Systems Development Dynamic Systems Development (DSDM)(DSDM)Framework for delivering business

solutions that relies heavily upon prototyping as a core technique

ISO 9001 approvedPrototypes intended to be incremental

Page 27: Models Object-Oriented Software Engineering CS350.

Dynamic Systems Development Dynamic Systems Development (DSDM)(DSDM)Prototypes may be throwaway or

evolutionaryEvolutionary prototypes may be

evolved horizontally or verticallyEvolutionary prototypes can evolve

into final systems

Page 28: Models Object-Oriented Software Engineering CS350.

Dynamic Systems Development Dynamic Systems Development (DSDM)(DSDM)Four recommended prototypes

categories:◦Business prototypes◦Usability prototypes◦Performance and capacity prototypes◦Capability/technique prototypes

Page 29: Models Object-Oriented Software Engineering CS350.

Dynamic Systems Development Dynamic Systems Development (DSDM)(DSDM)Prototype life-cycle:◦Identify prototype◦Agree to a plan◦Create the prototype◦Review the prototype

Page 30: Models Object-Oriented Software Engineering CS350.

Operational PrototypingOperational PrototypingProposed by Alan Davis as a way to

integrate throwaway and evolutionary prototyping with conventional system development

Page 31: Models Object-Oriented Software Engineering CS350.

Operational PrototypingOperational Prototyping Methodology:

◦ Evolutionary prototype is constructed and made into a baseline using conventional development strategies

◦ Baseline copies are sent to multiple customer sites along with a trained prototyper

◦ Prototyper watches the user at the system

◦ User problems, new feature ideas, or new requirements are logged by prototyper

◦ After user session, prototyper constructs a throwaway prototype from baseline system

◦ User evaluates new system; prototyper removes ineffective new changes

◦ Prototyper writes feature-enhancement requests and forwards them to development team

◦ Development team produces a new evolutionary prototype using conventional methods

Page 32: Models Object-Oriented Software Engineering CS350.

Evolutionary Systems Evolutionary Systems DevelopmentDevelopmentClass of methodologies that attempt

to formally implement Evolutionary Prototyping◦Ex. Systemscraft

Page 33: Models Object-Oriented Software Engineering CS350.

Evolutionary Rapid Evolutionary Rapid Development (ERD)Development (ERD)Developed by the Software

Productivity ConsortiumComposes software systems based

on◦Reuse of components◦Use of software templates◦Architectural template

Continuous evolution of system highlighted by evolvable architecture

Page 34: Models Object-Oriented Software Engineering CS350.

Evolutionary Rapid Evolutionary Rapid Development (ERD)Development (ERD)Use of small artisan-based teams◦ Integrating software and systems engineering

disciplines◦Working multiple, often parallel short-duration

timeboxes◦ Frequent customer interaction

Key to success◦Parallel exploratory analysis and development of

features, infrastructures and components◦Adoption of leading edge technologies

Page 35: Models Object-Oriented Software Engineering CS350.

Evolutionary Rapid Evolutionary Rapid Development (ERD)Development (ERD)Frequent scheduled and ad hoc meetings

with the stakeholdersDemonstrations of system capabilities to

solicit Frequent releases (e.g., betas)Design framework based on existing

published or de facto standardsSystem organized for evolving a set of

capabilities that includes considerations for performance, capacities, and functionality

Page 36: Models Object-Oriented Software Engineering CS350.

Evolutionary Rapid Evolutionary Rapid Development (ERD)Development (ERD)Architecture◦Defined in terms of abstract interfaces

that encapsulate services and implementation (e.g., COTS applications)

◦Serves as a template for guiding development of more than a single instance of the system

◦Allows for multiple application components to implement services

Page 37: Models Object-Oriented Software Engineering CS350.

Evolutionary Rapid Evolutionary Rapid Development (ERD)Development (ERD)Structured to use demonstrated functionality rather

than paper products to communicate stakeholder needs and expectations

Timeboxes: fixed periods of time in which specific tasks (e.g., developing a set of functionality) must be performed

To prevent development from degenerating into a "random walk," long-range plans are defined to guide the iterations

Each iteration is conducted in the context of long-range plans

Once an architecture is established, software is integrated and tested on a daily basis

Page 38: Models Object-Oriented Software Engineering CS350.

ScrumScrumAgile method for project managementFirst described by Takeuchi and

Nonaka

Page 39: Models Object-Oriented Software Engineering CS350.

ToolsToolsEfficient prototyping requires◦Proper tools◦Staff trained to use those tools

Can vary from individual tools to complex integrated CASE tools

CASE tools are often developed or selected by the military or large organizations

Object oriented tools are being developed (Ex. LYMB, GE Research and Development Center)

Page 40: Models Object-Oriented Software Engineering CS350.

ToolsToolsScreen generators, design tools &

Software FactoriesApplication definition or simulation

softwareRequirements Engineering

Environment

Page 41: Models Object-Oriented Software Engineering CS350.

Screen Generators, Design Screen Generators, Design Tools & Software FactoriesTools & Software FactoriesScreen generating programs enable prototypers to

show users screens for non-functionalHuman Computer Interfaces (HCI) can sometimes

be the critical part of the development effortSoftware Factories

◦ Code Generators

◦ Allow you to model domain model and then drag and drop the UI

◦ Enable you to run prototype and use basic database functionality

◦ Can use UI Controls that will later be used for real development

Page 42: Models Object-Oriented Software Engineering CS350.

Application Definition or Application Definition or Simulation SoftwareSimulation SoftwareEnable users to rapidly build lightweight, animated

simulations of another computer program, without writing code

Allows both technical and non-technical users to experience, test, collaborate and validate the simulated program

Provides reports such as annotations, screenshot and schematics

One can also use software to simulate real-world software programs for computer based training, demonstration, and customer support

Page 43: Models Object-Oriented Software Engineering CS350.

Requirements Engineering Requirements Engineering EnvironmentEnvironmentUnder development at Rome

Laboratory since 1985Provides an integrated toolset for

rapidly representing, building, and executing models of critical aspects of complex systems

Currently used by the Air Force to develop systems

Page 44: Models Object-Oriented Software Engineering CS350.

Requirements Engineering Requirements Engineering EnvironmentEnvironmentAn integrated set of tools that allows

systems analysts to rapidly build functional, user interface, and performance prototype models of system components

Modeling activities performed to gain greater understanding of complex systems and

Lessen impact that inaccurate requirement specifications have on cost and scheduling

Page 45: Models Object-Oriented Software Engineering CS350.

Requirements Engineering Requirements Engineering EnvironmentEnvironmentModels can beConstructed easilyAt varying levels of abstraction or granularityComposed of three partsProto, a CASE tool designed to support rapid

prototypingRapid Interface Prototyping System (RIP), a

collection of tools that facilitate the creation of user interfaces

A graphical user interface to RIP and proto intended to be easy to use

Page 46: Models Object-Oriented Software Engineering CS350.

Waterfall ModelWaterfall Model

Page 47: Models Object-Oriented Software Engineering CS350.

Spiral ModelSpiral Model