Alternative Systems Development Methods

MIT5312: Professor Kirs Alternative Systems Development Methods Slide 1

Alternative Systems Development Methods

Parts of Chapter 3, Module A and Module B(With Major variations)


SDLC SummarySDLC SummaryAdvantages: • Top-Down Approach

• Incorporates Company Mission/Strategy• Allows for later modifications

• Requires Some User Input Disadvantages:

• Emphasizes Planning vs. Maintenance

• Systems tend to be very cumbersome

• Very Expensive• Time Consuming


What are the Alternatives ???• Before Looking at alternatives, recall our preferred order of

system development:

1. Do Nothing: If its not broken, Don’t fix it !!2. Make non-system changes: Procedural Changes3. Modify Existing System: Change/Add Code4. Buy the new system: If Possible5. Outsource: A consideration6. Build the new system: If unavoidable

• The alternative methods apply to building the system

Don’t Overlook the possibility of using the others !!Don’t Overlook the possibility of using the others !!(Especially Buying the System)


Commercial ommercial OOff-ff-The-he-Shelf (helf (COTS) Software) Software• The ‘Ultimate’ (according to the Text) is:

• Enterprise nterprise RResource esource Planning (lanning (ERP))A fully integrated collection of Information Systems that span most of the business functions required by most organizations:• Accounting and Finance• Human Resources• Sales and Procurement

• Inventory Management• Production Planning and Control• Others

• Available Packages Include:• SAP• Oracle Applications• PeopleSoft


Commercial ommercial OOff-ff-The-he-Shelf (helf (COTS) Software) Software• Rationale of the COTS approach:

• Quick Implementation

• Many Businesses can not afford the staffing and expertise necessary to develop in-house solutions

• Due to economies of scale, COTS vendors can afford continuous improvements

• The COTS vendor assumes responsibility for significant system improvements and error corrections

• Most Business functions are more similar than dissimilar for all businesses in a given industry

• World-Class Standards are established and maintained


Commercial ommercial OOff-ff-The-he-Shelf (helf (COTS) Software) Software• Caveats for the COTS approach:

• Packages must be carefully selected• Packages are generally very expensive to purchase and

implement• Packages must usually be customized and integrated into

the system• Unless all programs are purchased from the same

vendor, they are seldom completely compatible• Major systems may require an organization to change the

way in which they work• Commercial packages seldom meet all the user

requirements to their satisfaction• Some in-house modification is often necessary


• Support Activities across the SDLC:

• Support the ‘Lower’ or Back-end Activities of the SDLC:

Computer Aided Software Engineering (CASE):Computer Aided Software Engineering (CASE):• Intended to Automate some of the activities in the

SDLC• Upper Case Tools

• Support the ‘Upper’ or front-end Activities of the SDLC:• Systems Panning• Systems Analysis• General Systems Design

• Lower Case Tools

• Detailed Systems Design• System Implementation• System Support

• Cross-Life Case Tools • Project Management• Estimation• Documentation


Computer Aided Software Engineering (CASE):Computer Aided Software Engineering (CASE):• Uppercase Tools: Systems Planning Activities

• Planned Business Strategies• IT Strategies• Databases Required• Networks Required• Applications Required Around databases and Networks

• Project Scope and Systems Boundaries Definitions• Current Systems Modeling• User Requirements Definitions• Prototype Requirements• Screen/Report Prototyping

The intent is to develop an Global Enterprise Resource Model that can be passed on to any CASE developed systems

• Uppercase Tools: Systems Systems Analysis (early CASE)


Computer Aided Software Engineering (CASE):Computer Aided Software Engineering (CASE):• Lowercase Tools: Systems Design and Implementation

• Help Designers Quickly Develop Code• Help designers quickly Test and Debug Code• Help designers quickly design and generate

components such as screens and databases• Automatically generate complete application

Code

• Uppercase Tools: Systems Support Tools• Helping Programmers restructure existing programs to be more maintainable• Helping Programmers react to changing user requirements• Helping Designers and Programmers reengineerreengineer systems to accommodate

newer technologies• Helping Designers designers determine when the costs of maintaining a

system exceed the benefits of maintaining the system• Help in recovering usable information from older/obsolete systems as a

preface to developing a new system

Application Workbenches

Component Generators

Code Generators


Computer Aided Software Engineering (CASE):Computer Aided Software Engineering (CASE):• CASE Architecture

• The ‘Heart’ of any CASE Tool• System Developers Database

• Repositories

• Stores:• System Models• Detailed Descriptions/Specs• Other Development Products

• Also Called:• Design Database• Systems Dictionary• Systems Encyclopedia

Local Repository (Project 1)



Central Repository

Workstation 1

Workstation 2

Network Server

CASE Programs

Host Server

Librarian Programs


• CASE FacilitiesComputer Aided Software Engineering (CASE):Computer Aided Software Engineering (CASE):

• Graphics Facilities• Context Diagrams• Data Flow Diagrams• ERDs• Etc.

Can be linked to other system models and to Detailed Descriptions (below)

• Description Tools• Used to Record, Edit, Delete, and Output Detailed documentation and

Specifications• Prototyping Tools (described in more detail later)

• Used to design components as inputs, outputs, screens, reports and forms• Inquiry and Reporting Facilities

• Allow User inquiries to be stated as open-ended questions and then be put into simple SQL (Structured Query Language) statements

• QBE



• Analyze Graphs, descriptions, tables for consistency, completeness and conformance to development rules

• Quality Assurance Facilities

• Decision Support Facilities• Provide User selected Data and Models for analysis

• Documentation Facilities• Assemble Graphs, repository descriptions, prototypes, and quality

assurance reports into formal documents

• Transform Facilities• Automate or assist in the transformation of programs or reports into

other types of formats

• Graphics Facilities• Description Tools

• Prototyping Tools• Inquiry and Reporting Facilities



• Graphics Facilities• Description Tools

• Prototyping Tools• Inquiry and Reporting Facilities

• Quality Assurance• Decision Support Facilities

• Documentation Facilities• Transform Facilities

• Automatically transform User requirements and/or technical designs into working applications and code

• Generators

• Provide data import and export repository information between different local repositories of the same CASE tool

• Data Sharing Facilities

• Maintain Integrity of the repository information• Security and Version Control Facilities

• Establish user accounts and project directories, create user privileges, tool defaults, preferences, back-up and recovery, etc.

• Housekeeping Facilities


Computer Aided Software Engineering (CASE):Computer Aided Software Engineering (CASE):• Basic Case Approaches

• Forward Engineering• The typical Development Model• The Analyst/Designer develops system models which are subsequently

transformed into program code

• Reverse Engineering• The case tool reads the existing code and transforms it into a

representative system model which can be modified and refined by the System Analyst/Designer

Altogether, Round-Trip Engineering


• Very Expensive (Software and Hardware)

Advantages:

Disadvantages:

• Improved Quality

• A great improvement but still time consuming

• NOT the silver bullet

Computer Aided Software Engineering (CASE):Computer Aided Software Engineering (CASE):

• Decreased Development time

• Better Documentation• Reduced Lifetime Maintenance

• Increased Productivity


PrototypingPrototyping• RRapid AApplication DDevelopment (RADRAD) and Testing Finding:

Suggested Solution: “It is a far better to adapt the

technology to the user than to force the user to adapt to the technology.”

Employees using PCs wasted about 100 minutes a week (about 1 Hr. 40 minutes) during the first month a new system was introduced


PrototypingPrototyping• Activities

ID User Requirements

Investigation/Analysis: Quick Requirements Definitions ID Several Alternatives

Develop Prototype

Prototype Design: Add User Specified Features Establish Interactive Components

Test Prototype Prototype Testing:

Get User Feedback

Revise Prototype Modification:

Based on User Feedback

Install/Maint. Implement and Maintain:


• Quick Development/Implementation

• Bottom-Up Approach (Code/Test/Patch)

Advantages:

• Cheaper

Disadvantages:

• Better User Requirements Identification

• More Prone to errors• May incorporate user ‘wishes’

not ‘needs’

• Users can better Identify requirements if they see what they are getting

• Potential User Disappointment if wishes omitted• Increased Maintenance Costs

PrototypingPrototyping


SDLC Costs vs. Prototyping CostsSDLC Costs vs. Prototyping Costs

$

Time

SDLC

Prototyping

Break-Even Point(Will the System Last this long??)


Object-bject-OOriented riented Analysis and nalysis and Design (esign (OOAD))• The latest approach to System Development • Structured Analysis approaches have always

(deliberately) separated data from processes(Even though at some point, they must be Synchronized)

• OOAD Attempts to merge the data and the processes into singular constructs called Objects

• The system is developed in terms of the interaction between the objects


Object:Objects:

• Anything that is capable of being seen, touched, or otherwise sensed and about which users store data and associate behaviors

Person• Last Name• First Name• Address• DOB• Gender• Height• Weight• Talk()• Walk()• Eat()• Sleep()• Snore()• Get_Sick()

Object Name

Object Attributes

Object Behaviors

• The Data associated with an Object

• The Procedures associated with an object

Encapsulation• The Packaging of

several items together into one unit

• The only way to access an object’s attributes is through its behaviors


What is an Object, really?Consider an object we know:

An Orange

We COULD try and describe an orange by its components:

WherePart A is the RindPart B is the PulpPart C is the Juice ExtractedPart D is the Total Weight 12 oz.


That is That is NOTNOT how we should how we should think of it!!think of it!!• Once an orange is pulled apart it is no longer an

orange• A picture of an orange is only a picture of an

orange

• The relationship of the parts to the whole, and to one another, are easier to understand when everything is kept together in one wrapper

(Encapsulation)


Technically, we can also view an Technically, we can also view an object as an object as an ‘Entity with Behavior’‘Entity with Behavior’• The parts of an orange have their own attributes

and their own relationships with other parts and other entities

• They are different from simple ‘records’ in a database since we must not only consider the attributes (record fields, or data) but also their behaviors (The operations that can be performed on them)• An object encapsulates the data and the

exclusive functions on that data


Consider the following well-known Consider the following well-known object:object:

A Cube:A Cube is a 3-dimensional Object, having:

LengthWidth

Height

All Cubes have the same BASIC characteristics, but they can vary:

Where the VOLUME of a cube = Length * Width * Height


We can define a CLASS of objects called Cube which all have the same characteristics

Object Class Cubelengthheightwidth

create()delete()

volume()

The Attributes (data) common to all Cubes

AND The operations we could perform on a cube

Consider the following well-known Consider the following well-known object:object:

A Cube:


A C++ program for Cubes:A C++ program for Cubes:#include <iostream.h> // our I/O header fileclass cube // the name we give our class{ int length, height, width; // private data members/* These data members are PRIVATE because they can only be accessed by the operations we will associate with the class cube */

public: // public data members cube (int, int, int); // our constructor function ~cube (); // our destructor function int volume (); }; // our query function

/* These member operations are PUBLIC because they can be accessed by other functions (operations) in the program */


#include <iostream.h> // our I/O header fileclass cube // the name we give our class{ int length, height, width; // private data members public: // public data members cube (int, int, int); // our constructor function ~cube (); // our destructor function int volume (); }; // our query function

cube :: ~cube() { };/* Let’s ignore our destructor function*/

int cube :: volume() // this will calculate the volume

cube :: cube (int len, int ht, int wid){ length = len; // store the value passed to length height = ht; // store the value passed to height width = wid; }; // store the value passed to width

/* And instead look at our query function*/

{ return length * height * width; }

A C++ program for Cubes:A C++ program for Cubes:

/* Now let’s construct and print out an instance of the object*/ int main () { cube mycube (7, 8, 9); // construct the cube cout << mycube.volume(); }


How does this work??

cube mycube (7, 8, 9);The call from the main program

And passes the values: 7

cube :: cube (int len, int ht, int wid)

8 9

In the cube constructor function, the values are transferred to our object data members: { length = len; height = ht; width = wid; };

Creates the object instance mycube of class cube

A C++ program for Cubes:A C++ program for Cubes:


cout << mycube.volume();

Our next call is to function volume using our object mycube will print out the results of the operation:

Function volume will return the product of our data set

Where: Length = 7Height = 8Width = 9

int cube :: volume() { return length * height * width; }

7 * 8 * 9 = 504And print out the returned value

504

A C++ program for Cubes:A C++ program for Cubes:How does this work??


Object Class• A group of objects sharing the same Attributes and Behaviors

Objects:

Person• Last Name• First Name• Address• DOB

• Gender• Height• Weight

• Talk()• Walk()• Eat()

• Sleep()• Snore()• Get_Sick()

Person Class

(SuperType)

Ann RiceSoph.2.69

Bob SmithSr.3.72

Tim DorkJr.0.01

G.W. BushFull1/12/76

A.E. SteinAssist.9/01/02

Student• Class• GPA• Enroll()• Expel()

Professor• Rank• Date Hired• Lecture()• Research()

Student Class(SubType)

Professor Class(SubType)

Student 1

Student 2

Student 3

Professor1 Professor2

InheritanceInheritance


Objects:What is InheritanceInheritance??

• Inheritance is the process of developing new classes by refining and specializing existing ones.

•A Shape is a Form

•A Polygon is a shape. •A Polygon can either be three sided (a Triangle)

•A Square is a Rectangle with equal sides

•A Circle is a Shape. Shape

•A Rectangle is a 4 sided Polygon

Circle Polygon

Triangle Rectangle

Square

• Each inherits the attributes an behaviors of its parent


Objects: Object/Class Relationships

• The associations that exist between one or more object/classes(Similar to ERDs)

1Places1..*

1..*

Contains

*

11..*

Includes

Customer

Cust_IDCust_Addr

••••

CalcBal()

Order

Ord_IDCust_ID

••••

CalcAmtDue()

Product

Prod_NumProd_L_ID

••••

CalcProdAmt()

Product_Line

Prod_L_IDProd_L_Desc

••••

CalcPLSales()


UML (UML (UUnifiednified MModelingodeling LLanguageanguage)) Set of OO modeling conventions

that are used to specify or describe software systems

Attempt to create a single, standard process

Provides notation for OO Modeling

Adopted by the Object Management Group as the industry standard in 1997

• Does NOT prescribe a method for developing Systems

• Still often referred to as a ‘work in progress’


UML (UML (UUnifiednified MModelingodeling LLanguageanguage))UML Phases and Tools:

•Context diagram •Use-case diagram

•Object and Object Relationship Identification: •Class Diagrams •Essential Use-Case•Scenarios•Object Diagrams

•Requirements Analysis:

•High-Level Object Behavior: •Sequence Diagrams •State Diagrams•Activity Diagrams


UML (UML (UUnifiednified MModelingodeling LLanguageanguage))•Requirements Analysis:

•Context Diagram •identifies the system boundaries and responsibilities.•Determines the boundaries, actors and interactions required.

•Use-Case Diagram •identifies high level system functionality (processes) required (equivalent to function points). •identified through discussion with users •From the scenarios, those with common elements can be identified and use cases can be extracted•These are essential use-cases - high level use cases not tied to any particular implementation or technology.


UML (UML (UUnifiednified MModelingodeling LLanguageanguage))•Object and Object Relationship Identification:

•Class Diagrams•Each class identifies the attributes, operations and interfaces associated with that class.•the relationships between classes are also shown.

• Associations:• When a class uses an instance of another class but does not

create or destroy instances of that class (e.g., A User Profile has both an inbox and an outbox)

• Generalizations:• Shows inheritance relationships (e.g., An Inbox and an Outbox

are both types of Mailboxes)



•Essential Use-Case•Captures the essential requirements of the system•Initially we start by just identifying use cases

•Once they are identified we can provide more detail, producing the essential use-case



•Sequence Diagrams

•Shows the sequence of activities which take place for a given scenario

(Scenario Modeling)

•Collaboration Diagrams(Scenario Modeling)

•It shows messages being passed between objects with the messages given a sequence number. •it can also show organizational relationships between objects, by showing associations.



•Object Diagrams•snapshot of our system frozen in time showing a particular relationship between objects and their state at that time.


UML (UML (UUnifiednified MModelingodeling LLanguageanguage))•High-Level Object Behavior:

•State Diagrams•Objects have a start state, from which transitions occur either when event triggers arise or when the source state completes its activity. •Objects also have terminal states from which no further transitions are possible.


UML (UML (UUnifiednified MModelingodeling LLanguageanguage))•High-Level Object Behavior:

•Activity Diagrams•Activity diagrams can be used to demonstrate both code operation, or - quite differently - workflows within an organization. •In our context we will look at a workflow:


But these are merely Tools!!! How are they used ???Object-bject-OOriented riented Development evelopment Life ife Cycle (ycle (OODLC)) Update of the SDLC Still related to Simon and the SDLC

Simon

Intelligence

SDLCSystem

InvestigationDesign System AnalysisChoice System DesignImple-mentation Implementation

Review Maintenance

OODLC

Analysis

DesignConstructionTestingMaintenance


HOWEVER, Perhaps more closely related to the Prototyping Model

PrototypingID User RequirementsDevelop PrototypeTest & ReviseInstall & Maintain

OODLC

Testing

Maintenance

Construction

AnalysisDesign

Phase Objective

Model User RequirementsModify Model to Reflect NeedsThorough testing and RevisionFix and Enhance

Object-bject-OOriented riented Development evelopment Life ife Cycle (ycle (OODLC))

Hey, Life IS a Compromise !!!!


OODLC Analysis PhaseOODLC Analysis Phase What the system must DODeliverables: 1. Requirements Model

• Generally a short paragraph or 2 statement of the project

• Statement of what the project will do for users• Statement of what the project will NOT do

(To avoid unwarranted user expectations)

• Statement of what the project MUST produce(Longer as necessary)

Project Scope


And how they relate to the system(people, organizations, systems)

• Graphical model showing all of the EXTERNAL ENTITIES

Context Diagram

Audio Store

Vendors

Orders

Supplies CustomersPurchases

OwnersQtrly. Reports


Project Scope


Context Diagram


Project Scope

Use Case Scenario• A step-by-step description

of how a user might use the system

• Usually, a sample task is considered, and ALL user actions are enumerated in order


Context Diagram


Project Scope

Use Case Scenario

• Brief Description of dataflows btw. other systems

• Interfaces to other systems (Legacy Systems)

Interface Descriptions

• Communication Interfaces (LANS, IntraNets, Internets, etc).

• Graphical User Interfaces (GUIs)



Also known as the Information Model Consists of initial entity classes

2. Object (Class) Model

Necessary Interface classes as discovered


OODLC Analysis PhaseOODLC Analysis Phase What the system must DODeliverables: 1. Requirements Model2. Object (Class) Model

Tool for examining the life cycle of an object to discover what it does

3. State Transition Diagram (STD) Model


OODLC Analysis PhaseOODLC Analysis Phase What the system must DODeliverables: 1. Requirements Model2. Object (Class) Model3. State Transition Diagram (STD) Model

A Data Flow Diagram (DFD) intended to document very large or complex systems

4. The Functional Model


OODLC Design PhaseOODLC Design Phase HOW the system will do what is intended• Modify Analysis Model to reflect design decisions• Incorporate new information as found• Add new classes that do not directly reflect classes

found in the ‘real-world’ foundDeliverable:

Formalized plan of how the system will deliver the specified requirements


OODLC Construction PhaseOODLC Construction Phase• Coding and Testing• User Training• System DeploymentDeliverable:

An Operational System


OODLC Testing PhaseOODLC Testing Phase• Final Testing of all units• As thorough as possible• Automated Testing (Simulation)Deliverable:

The Working System


OODLC Maintenance PhaseOODLC Maintenance Phase• Fix any bugs found during operation• System Enhancements• Addition of new end-user features

Deliverable: An Improved System

• Automated systems of back-up and recovery• Incorporation of disaster preparedness

procedures


Documents

Alternative Systems Development Methods