1 / 56

Alternative Systems Development Methods

Alternative Systems Development Methods. Parts of Chapter 3, Module A and Module B. (With Major variations) . Top-Down Approach . Very Expensive. Time Consuming. SDLC Summary. Advantages:. Incorporates Company Mission/Strategy. Allows for later modifications .

lam
Download Presentation

Alternative Systems Development Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Alternative Systems Development Methods Parts of Chapter 3, Module A and Module B (With Major variations)

  2. Top-Down Approach Very Expensive Time Consuming SDLC Summary Advantages: Incorporates Company Mission/Strategy Allows for later modifications Emphasizes Planning vs. Maintenance Requires Some User Input Disadvantages: Systems tend to be very cumbersome

  3. 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 Changes Change/Add Code 3. Modify Existing System: 4. Buy the new system: If Possible 5. Outsource: A consideration 6. Build the new system: If unavoidable The alternative methods apply to building the system Don’t Overlook the possibility of using the others !! (Especially Buying the System)

  4. Commercial Off-The-Shelf (COTS) Software The ‘Ultimate’ (according to the Text) is: Enterprise Resource Planning (ERP) A fully integrated collection of Information Systems that span most of the business functions required by most organizations: Accounting and Finance Inventory Management Human Resources Production Planning and Control Sales and Procurement Others Available Packages Include: SAP Oracle Applications PeopleSoft

  5. Commercial Off-The-Shelf (COTS) 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

  6. Commercial Off-The-Shelf (COTS) 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

  7. Support the ‘Upper’ or front-end Activities of the SDLC: Support the ‘Lower’ or Back-end Activities of the SDLC: Support Activities across the SDLC: Computer Aided Software Engineering (CASE): Intended to Automate some of the activities in the SDLC Upper Case Tools 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

  8. 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): 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

  9. Application Workbenches Component Generators Code Generators 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 reengineer 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

  10. Host Server Workstation 1 Network Server Local Repository (Project 3) Local Repository (Project 2) Local Repository (Project 1) Central Repository CASE Programs Librarian Programs Workstation 2 Computer Aided Software Engineering (CASE): CASE Architecture Repositories The ‘Heart’ of any CASE Tool System Developers Database Stores: Also Called: System Models Design Database Detailed Descriptions/Specs Systems Dictionary Other Development Products Systems Encyclopedia

  11. Can be linked to other system models and to Detailed Descriptions (below) Computer Aided Software Engineering (CASE): CASE Facilities Graphics Facilities Context Diagrams Data Flow Diagrams ERDs Etc. 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 (StructuredQueryLanguage) statements QBE

  12. Graphics Facilities Prototyping Tools Description Tools Inquiry and Reporting Facilities Computer Aided Software Engineering (CASE): CASE Facilities Quality Assurance Facilities Analyze Graphs, descriptions, tables for consistency, completeness and conformance to development rules 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

  13. Graphics Facilities Prototyping Tools Description Tools Inquiry and Reporting Facilities Quality Assurance Documentation Facilities Decision Support Facilities Transform Facilities Computer Aided Software Engineering (CASE): CASE Facilities Generators Automatically transform User requirements and/or technical designs into working applications and code Data Sharing Facilities Provide data import and export repository information between different local repositories of the same CASE tool Security and Version Control Facilities Maintain Integrity of the repository information Housekeeping Facilities Establish user accounts and project directories, create user privileges, tool defaults, preferences, back-up and recovery, etc.

  14. Altogether, Round-Trip Engineering 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

  15. Increased Productivity Computer Aided Software Engineering (CASE): Advantages: Decreased Development time Improved Quality Better Documentation Reduced Lifetime Maintenance Disadvantages: Very Expensive (Software and Hardware) A great improvement but still time consuming NOT the silver bullet

  16.  Employees using PCs wasted about 100 minutes a week (about 1 Hr. 40 minutes) during the first month a new system was introduced  “It is a far better to adapt the technology to the user than to force the user to adapt to the technology.” Prototyping Rapid Application Development (RAD) and Testing  Finding:  Suggested Solution:

  17. Prototyping Activities  Investigation/Analysis: ID User Requirements  Quick Requirements Definitions  ID Several Alternatives  Prototype Design: Develop Prototype  Add User Specified Features  Establish Interactive Components  Prototype Testing: Test Prototype  Get User Feedback  Prototype Modification: Revise  Based on User Feedback  Implement and Maintain: Install/Maint.

  18. Quick Development/Implementation Bottom-Up Approach (Code/Test/Patch) Prototyping Advantages: Oooh -- Slap me and call me Shirley !! Cheaper Better User Requirements Identification Users can better Identify requirements if they see what they are getting Disadvantages: More Prone to errors Oh, Oh !! May incorporate user ‘wishes’ not ‘needs’ Potential User Disappointment if wishes omitted I Hate You !! Increased Maintenance Costs

  19. $ Prototyping SDLC Break-Even Point Time SDLC Costs vs. Prototyping Costs (Will the System Last this long??)

  20. Object-Oriented Analysis and Design (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

  21. Person Encapsulation Object Name Last Name First Name Address Object Attributes DOB Gender Height Weight Talk() Walk() Eat() Object Behaviors Sleep() Snore() Get_Sick() Objects:  Object: Anything that is capable of being seen, touched, or otherwise sensed and about which users store data and associate behaviors The Packaging of several items together into one unit The Data associated with an Object The only way to access an object’s attributes is through its behaviors The Procedures associated with an object

  22. What is an Object, really? Consider an object we know: AnOrange We COULD try and describe an orange by its components: Where Part A is the Rind Part B is the Pulp Part C is the Juice Extracted Part D is the Total Weight 12 oz.

  23. That is NOT how we should 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)

  24. Technically, we can also view an object as an ‘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

  25. Consider the following well-known object: A Cube is a 3-dimensional Object, having: A Cube: Where the VOLUME of a cube = Length * Width * Height Length Height Width All Cubes have the same BASIC characteristics, but they can vary:

  26. Object Class Cube length height width Consider the following well-known object: We can define a CLASS of objects called Cube which all have the same characteristics A Cube: The Attributes (data) common to all Cubes create() delete() volume() AND The operations we could perform on a cube

  27. A C++ program for Cubes: #include <iostream.h> // our I/O header file class 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 theclasscube*/ public:// public data members cube (int, int, int);// ourconstructorfunction ~cube ();// ourdestructorfunction int volume (); };// ourqueryfunction /* These memberoperationsare PUBLIC because they can be accessed by other functions (operations) in the program */

  28. A C++ program for Cubes: #include <iostream.h> // our I/O headerfile class 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 (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 /* Let’s ignore our destructor function*/ cube :: ~cube() { }; /* And instead look at our query function*/ int cube :: volume() // this will calculate the volume { return length * height * width; } /* 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(); }

  29. A C++ program for Cubes: How does this work?? The call from the main program Creates the object instance mycube of class cube cube mycube (7, 8, 9); And passes the values: 7 8 9 cube :: cube (int len, int ht, int wid) In the cube constructor function, the values are transferred to our object data members: { length = len; height = ht; width = wid; };

  30. int cube :: volume() { return length * height * width; } A C++ program for Cubes: How does this work?? Our next call is to function volume using our object mycube will print out the results of the operation: cout << mycube.volume(); Length = 7 Where: Height = 8 Function volume will return the product of our data set Width = 9 * * = 8 7 9 504 And print out the returned value 504

  31. Person Class Person Last Name Gender First Name Height Address Weight Inheritance DOB Talk() Sleep() (SuperType) Student Professor Walk() Snore() Student Class Professor Class Class Rank Eat() Get_Sick() (SubType) (SubType) GPA Date Hired Enroll() Lecture() Expel() Research() Tim Dork Ann Rice Bob Smith Jr. Soph. Sr. G.W. Bush A.E. Stein 3.72 0.01 2.69 Full Assist. 1/12/76 9/01/02 Student 1 Student 2 Student 3 Professor1 Professor2 Objects:  Object Class A group of objects sharing the same Attributes and Behaviors

  32. Circle Polygon Triangle Rectangle Square Objects: What is Inheritance?? Inheritance is the process of developing new classes by refining and specializing existing ones. A Shape is a Form Shape A Circle is a Shape. A Polygon is a shape. A Polygon can either be three sided (a Triangle) A Rectangleis a 4 sided Polygon A Square is a Rectangle with equal sides Each inherits the attributes an behaviors of its parent

  33. Product_Line Product Order Customer Prod_Num Prod_L_ID •••• Ord_ID Cust_ID •••• Cust_ID Cust_Addr •••• Prod_L_ID Prod_L_Desc •••• CalcPLSales() CalcProdAmt() CalcAmtDue() CalcBal() 1 1 Includes Places 1..* 1..* Contains * 1..* Objects:  Object/Class Relationships The associations that exist between one or more object/classes (Similar to ERDs)

  34. UML (UnifiedModelingLanguage)  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 Does NOT prescribe a method for developing Systems  Adopted by the Object Management Group as the industry standard in 1997 Still often referred to as a ‘work in progress’

  35. UML (UnifiedModelingLanguage) UML Phases and Tools: Requirements Analysis: Context diagram Use-case diagram Object and Object Relationship Identification: Class Diagrams Essential Use-Case Scenarios Object Diagrams High-Level Object Behavior: Sequence Diagrams State Diagrams Activity Diagrams

  36. UML (UnifiedModelingLanguage) 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.

  37. UML (UnifiedModelingLanguage) 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)

  38. UML (UnifiedModelingLanguage) Object and Object Relationship Identification: 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

  39. UML (UnifiedModelingLanguage) Object and Object Relationship Identification: Sequence Diagrams (Scenario Modeling) Shows the sequence of activities which take place for a given scenario 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.

  40. UML (UnifiedModelingLanguage) Object and Object Relationship Identification: Object Diagrams snapshot of our system frozen in time showing a particular relationship between objects and their state at that time.

  41. UML (UnifiedModelingLanguage) 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.

  42. UML (UnifiedModelingLanguage) 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:

  43. Analysis Construction Testing But these are merely Tools!!! How are they used ??? Object-Oriented Development Life Cycle (OODLC)  Update of the SDLC  Still related to Simon and the SDLC Simon SDLC OODLC System Investigation Intelligence Design System Analysis Choice System Design Design Imple-mentation Implementation Review Maintenance Maintenance

  44. Analysis Design Object-Oriented Development Life Cycle (OODLC)  HOWEVER, Perhaps more closely related to the Prototyping Model Prototyping OODLC Phase Objective ID User Requirements Model User Requirements Develop Prototype Construction Modify Model to Reflect Needs Test & Revise Testing Thorough testing and Revision Install & Maintain Maintenance Fix and Enhance Hey, Life IS a Compromise !!!!

  45.  Project Scope OODLC Analysis Phase  What the system must DO Deliverables: 1. Requirements Model Generally a short paragraph or 2 statement of the project (Longer as necessary) Statement of what the project MUST produce Statement of what the project will do for users Statement of what the project will NOT do (To avoid unwarranted user expectations)

  46. Purchases Supplies Orders Qtrly. Reports OODLC Analysis Phase  What the system must DO Deliverables: 1. Requirements Model  Project Scope  Context Diagram Graphical model showing all of the EXTERNAL ENTITIES (people, organizations, systems) And how they relate to the system Customers Vendors Audio Store Owners

  47. OODLC Analysis Phase  What the system must DO Deliverables: 1. Requirements Model  Project Scope  Context Diagram  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

  48. OODLC Analysis Phase  What the system must DO Deliverables: 1. Requirements Model  Project Scope  Context Diagram  Use Case Scenario  Interface Descriptions Brief Description of dataflows btw. other systems GraphicalUserInterfaces (GUIs) Interfaces to other systems (Legacy Systems) Communication Interfaces (LANS, IntraNets, Internets, etc).

  49. OODLC Analysis Phase  What the system must DO Deliverables: 1. Requirements Model 2. Object (Class) Model  Also known as the Information Model  Consists of initial entity classes  Necessary Interface classes as discovered

  50. OODLC Analysis Phase  What the system must DO Deliverables: 1. Requirements Model 2. Object (Class) Model 3. State Transition Diagram (STD) Model  Tool for examining the life cycle of an object to discover what it does

More Related