Sunteți pe pagina 1din 67

Systems Design and Development Methodologies

SDLC
SDLC stands for
Systems Development Life Cycle First, SDLC is a Life Cycle. All systems have a life cycle or a series of stages they naturally undergo.
The number and name of the stages varies, but the primary stages are conception, development, maturity and decline. The systems development life cycle (SDLC) therefore, refers to the development stage of the systems life cycle.

Why are we so interested in the development stage? What about conception, maturity and decline?

Methodologies
Is there a difference between the term SDLC and the term methodology? Whereas the SDLC refers to a stage all systems naturally undergo, a methodology refers to an approach invented by humans to manage the events naturally occurring in the SDLC. A methodology is, in simple terms, a set of steps, guidelines, activities and/or principles to follow in a particular situation.
Most methodologies are comprehensive, multi-step approaches to systems development

What is a Methodology?
Multi-step approach to systems development Influences the quality of the Final product Comprehensive Consistent method with the Organizations management style.

Who Uses Methodologies?


Most Organizations and Firms Today
IBM, Microsoft, Monsanto, NASA, AT&T, Drury Hotels, Edward Jones, A.B.

Majority of Organizations and Firms use a specific type of methodology that is tailored to their needs.

What Are Methodologies Used For?


Systems Development
Guidelines or References Step by Step process
Leads to final product

Analysis
Information
Gathered and Used to help the development process

System Development Life Cycles and Methodologies

The process used to develop information systems is called a methodology.

All methodologies are derived from a logical system problemsolving process that is sometimes called a system development life cycle. A system development life cycle (SDLC) is a logical process by which systems analysts, software engineers, programmers, and end-users build information systems and computer applications to solve business problems and needs. It is sometimes called an application development life cycle.

System Development Life Cycles and Methodologies

What is a Methodology?

A methodology is the physical implementation of the logical life cycle that incorporates (1) step-by-step activities for each phase, (2) individual and group roles to be played in each activity, (3) deliverables and quality standards for each activity, and (4) tools and techniques to be used for each activity. A true methodology should encompass the entire systems development life cycle. Most modern methodologies incorporate the use of several development tools and techniques.

System Development Life Cycles and Methodologies

Why Do Companies use Methodologies?

Methodologies ensure that a consistent, reproducible approach is applied to all projects. Methodologies reduce the risk associated with shortcuts and mistakes. Methodologies produce complete and consistent documentation from one project to the next.

Life Cycle versus Methodology


System life cycle the factoring of the lifetime of an information system into two stages, (1) systems development and (2) systems operation and maintenance. System development methodology a formalized approach to the systems development process; a standardized development process that defines a set of activities, methods, best practices, deliverables, and automated tools that system developers and project managers are to use to develop and continuously improve information systems and software.

3-10

SDLC vs. Methodology


It is confusing, but unfortunately, the term SDLC is frequently used synonymously with the waterfall or traditional approach for developing information systems.
The SDLC approach
This approach essentially refers to a linear sequence of stages to develop a system from planning to analysis to design to implementation. Stages are followed from beginning to end. Revisiting prior stages is not permitted.

Underlying Principles of Systems Development

Principle 1: Get the Owners and Users Involved

Owner and user involvement is an absolute necessity for successful systems development. The individuals responsible for systems development must make time for owners and users, insist on their participation, and seek agreement from them on all decisions that may affect them. Methodologies reduce the risk associated with shortcuts and mistakes. Methodologies produce complete and consistent documentation from one project to the next.

Underlying Principles of Systems Development

Principle 2: Use a Problem-Solving Approach

A methodology is, first and foremost, a problem-solving approach to building systems. The classical problem-solving approach is as follows: Study and understand the problem (opportunity, and/or directive) and its system context. Define the requirements of a suitable solution. Identify candidate solutions and select the ``best'' solution. Design and/or implement the solution. Observe and evaluate the solution's impact, and refine the solution accordingly.

Underlying Principles of Systems Development

Principle 2: Use a Problem-Solving Approach

There is tendency among inexperienced problem solvers to eliminate or abbreviate one or more of the problem solving steps. The result can be range from: solving the wrong problem incorrectly solving the problem picking the wrong solution

Underlying Principles of Systems Development

Principle 3: Establish Phases and Activities


Most life cycles and methodologies consist of phases. In its simplest, classical form, the life cycle consists of four phases: systems survey systems analysis systems design systems implementation A fifth activity, systems support, refines the resulting system by iterating through the previous four phases on a smaller scale to refine and improve the system.

INFORMATION SYSTEMS FRAMEWORK

FOCUS ON SYSTEM DATA

FOCUS ON SYSTEM PROCESSES

FOCUS ON SYSTEM INTERFACES

FOCUS ON SYSTEM GEOGRAPHY

System Development

Business Subjects
Customers order zero, one, or more products. Products may be ordered by zero, one, or more customers.

Business Functions
Marketing

System Context
A ccounts R eceiva ble D ata base C redit

Operating Locations

SYSTEM OWNERS (scope)

Advertis ing

Sales

C ustomer

Orde r

Orde r Management System

Picking Orde r

W arehouse

C redit Vouc her

SYSTEM PLANNING

Orders

Cancellations

Servic es
B ank

Data Requirements
CUST OMER customer-no customer-name customer-rating balance-due PRODUCT product-no product-name unit-of-measure unit-price quantity-av ailable

Business Processes
rejec ted order Customers customer number credit Check credit

Interface Requirements
F irec ra c k er Sa le s

Communication Reqts.
EDI Cust order St. Louis HQ catalog changes Products Catalog

S Y S T E M A N A L Y S T S

SYSTEM USERS (requirements)

order with valid products valid order Validate products

approved order
West Customers

ship order

East Customers credit

order

Validate customer

credit

Orders approved order


LA Office ship order Indy Warehouse service ship order NY Office

ORDER order-no order-date products-ordered quantities-ordered

SYSTEM ANALYSIS

order without valid customer

prices

Products

quantity in stock

Release order

picking ticket

Maintenance Records

Database Scehma
PRODUCT CUSTOMER product_no [Alpha(10)] INDEX customer_no [Alpha (10)] INDEX product_name [Alpha(32)] customer_name [Alpha(32)] unit_of_measure [Alpha(2)] customer_rating [Alpha(1)] INDEX unit_price [Real(3,2)] balance_due [Real(5,2)] quantity_av ailable [Integer(4)]

Application Schema
Or der Pr ocessing Pr ogr am Initiation Routine Pr ocess an Or der Shutdown Routine

Interface Schema
New Customer Customer Form Logon Order Accepted Change of Address

Network Schema
C ommunica tions C ontroller St. Louis Mainframe

SYSTEM DESIGNERS (specification)

New Order

N T Server LA
Get an Or der Validate an Or der File an Or der

Order Help Complete

Order Form

First Order
PB X

Request Order Help

ORDER order_no [Alpha(12)] INDEX order_date [Date(mmddyyyy) CUSTOMER.customer_no

ORDER_PRODUCT ORDER.order_no PRODUCT.product_no quantity_ordered [Integer(2)

Check Customer Cr edit

Check Pr oduct Data

Check Cr edit Data

Release an Or der

Request Product Lookup

N T Server N Y Ethernet LA N/NT

Ethernet LA N/NT

SYSTEM DESIGN

Help +

Request Product Lookup Help


Indy A IX Server C lient PC C lient PC

Customer s

Pr oducts

Or der s

Product Lookup Help Complete

Product Lookup

C lient PC

C lient PC

Enternet LA N AIX/Lan Manager

Database Structures
CREATE TABLE CUSTOMER (customer_no CHAR(10) NOT NULL customer_name CHAR(32) NOT NULL customer _rating CHAR(1) NOT NULL balance_due DECIMAL(5,2) CREATE INDEX cust_no_idx on CUSTOMER CREATE INDEX cust_rt_idx on CUSTOMER

Application Programs
VALIDATE_AN_ORDER. REPEAT UNTIL NO_MORE_ORDERS PERFORM CUSTOMER_VALIDATIO REPEAT UNTIL NO_MORE_ORDER PERFORM PRODUCT_VALIDATI END REPEAT. PERFORM CREDIT_CHECK. IF CREDIT_CHECK 'BAD' THEN

Component Programs
On Event Help.ButtonClick Do Change Focus HelpDialog On Event OKButton Do Begin {proecdure} End On Event CancelButton Do

Network Programs
Create AccountType = SalesClerk Set OrderDir.Rights=full Set CustomerDir.Rights=full Set ProductDir.Rights=read Set OrderAppDir.Rights=copy

SYSTEM BUILDERS (components)

SYSTEM IMPLEMENTATION

Database Technology

Software (and Hardware) Technology

Interface Technology

Networking Telchnology

SYSTEM SUPPORT

Underlying Principles of Systems Development

Principle 3: Establish Phases and Activities

Phases are usually broken down into activities and tasks that can be more easily managed and accomplished. The phases of a project should be completed top-to-bottom, in sequence.

Underlying Principles of Systems Development

Principle 4: Establish Standards for Consistent Development and Documentation

Systems development standards usually describe: activities responsibilities documentation guidelines or requirements quality checks The need for documentation standards underscores a common failure of many analysts the failure to document as an ongoing activity during the life cycle.

Underlying Principles of Systems Development

Principle 5: Justify Systems as Capital Investments


Information systems are capital investments. When considering a capital investment, two issues must be addressed: for any problem, there are likely to be several possible solutions after identifying alternative solutions, the systems analyst should evaluate each possible solution for feasibility, especially for cost-effectiveness.
Cost-effectiveness is defined as the result obtained by striking a balance between the cost of developing and operating a system, and the benefits derived from that system.

Cost-benefit analysis is an important skill to be mastered.

Underlying Principles of Systems Development

Principle 6: Dont Be Afraid to Cancel or Revise Scope

A significant advantage of the phased approach to systems development is that it provides several opportunities to reevaluate feasibility. In the long run, canceled projects are less costly than implemented disasters! Most analysts fail to adjust estimated costs and schedules as scope increases. As a result, the analyst frequently and needlessly accepts responsibility for cost and schedule overruns.

Underlying Principles of Systems Development

Principle 6: Dont Be Afraid to Cancel or Revise Scope

The creeping commitment approach: Multiple feasibility checkpoints are built into the systems development methodology. At any feasibility checkpoint, all costs are considered sunk (meaning irrecoverable) and irrelevant to the decision. The project should be reevaluated at each checkpoint to determine if it is still feasible. At each checkpoint, the analyst should consider:
cancellation of the project if it is no longer feasible reevaluation of costs and schedule if project scope is to be increased reduction of scope if the project budget and schedule are frozen, but not sufficient to cover all project objectives.

Underlying Principles of Systems Development

Principle 7: Divide and Conquer


All systems are part of larger systems (called super-systems). Virtually all systems contain smaller systems (called subsystems). We divide a system into its subsystems in order to more easily conquer the problem and build the larger system. By dividing a larger problem (system) into more easily managed pieces (subsystems), the analyst can simplify the problem-solving process.

Underlying Principles of Systems Development

Principle 8: Design Systems for Growth and Change

Many systems analysts have fallen into the trap of developing systems to meet only today's user requirements. Entropy is the term system scientists use to describe the natural and inevitable decay of all systems. During the support phase, the cost of maintenance exceeds the costs of starting over the system has become obsolete.

Obsolete System

Systems Planning

Systems Support

New 'business' problem or requirement

Systems Analysis

Implementation error

New 'technology' alternative or requirement

Systems Implementation

Systems Design

Underlying Principles of Systems Development

Principle 8: Design Systems for Growth and Change

Systems that are designed to meet only current requirements are difficult to modify in response to new requirements. Many systems analysts become frustrated with how much time must be dedicated to supporting existing systems (often called legacy systems), and how little time is left to work on important, new systems development. Today's tools and techniques make it possible to design systems that can grow and change as requirements grow and change. Flexibility and adaptability do not happen by accident they must be built into a system.

Underlying Principles of Systems Development

Get the owners and users involved Use a problem-solving approach Establish phases and activities Establish standards for consistent development and documentation Justify systems as capital investments Dont be afraid to cancel Divide and conquer Design systems for growth and change

Systems Development Methodology


A standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems
Two categories:
Systems Development Life Cycle - SDLC Alternative methodologies

Systems Development Life Cycle

Approaches to Systems Development


Process-Oriented Approach
Focus is on flow, use and transformation of data in an information system Involves creating graphical representations such as data flow diagrams and charts Data are tracked from sources, through intermediate steps and to final destinations Natural structure of data is not specified Disadvantage: data files are tied to specific applications

Approaches to Systems Development


Data-Oriented Approach
Depicts ideal organization of data, independent of where and how data are used Data model describes kinds of data and business relationships among the data Business rules depict how organization captures and processes the data

Approaches to Systems Development


Which is better, the Process Approach or the Data Approach?

Process Approach: Lets look at all of our processes. Processes take precedence over data. Get the processes correct first. Then well address what data is important. Data Approach: Forget the processes, lets look at the data. Data comes first. Get the data correct, then see how the processes actually use the data.

Databases and Application Independence


Database
Shared collection of logically related data Organized to facilitate capture, storage and retrieval by multiple users Centrally managed Designed around subjects such as Customers or Suppliers

Application Independence
Separation of data from the applications, e.g.
Payroll data is part of the enterprise-wide data model and can be used by many systems, not just the Payroll System

Systems Development Life Cycle


Series of steps to manage development/maintenance of a system Phases are not necessarily sequential. Each phase has a specific outcome and deliverable. Individual companies use customized life cycle.

Systems Development Life Cycle


There are different names for the stages of the SDLC
Usually they stages are
Planning (just after Conception) Analysis Design Implementation Maintenance (starting Maturity)

Systems Development Life Cycle (SDLC)

Maintenance Fifth phase

Planning First phase

Analysis Second phase


Implementation

Fourth phase

Design Third phase

Systems Development Life Cycle


This text highlights 6 distinct phases:
Project Identification and Selection Project Initiation and Planning Analysis Design Implementation Maintenance

Phases of the Systems Development Life Cycle


1. Project Identification and Selection
Two Main Activities
Identification of need Prioritization and translation of need into a development schedule

Helps organization to determine whether or not resources should be dedicated to a project. Two Activities
Formal preliminary investigation of the problem at hand Presentation of reasons why system should or should not be developed by the organization

2. Project Initiation and Planning

Systems Development Life Cycle


Analysis
Study of current procedures and information systems
Determine requirements
Study current system Structure requirements and eliminate redundancies

Generate alternative designs Compare alternatives Recommend best alternative

Systems Development Life Cycle


Design
Logical Design
Concentrates on business aspects of the system

Physical Design
Technical specifications

Implementation
Implementation
Hardware and software installation Programming User Training Documentation

Systems Development Life Cycle


Maintenance
System changed to reflect changing conditions System obsolescence

A good way to learn the stages of the SDLC is to create deliverables (output) of each stage in the process.

Alternative Approaches
Evolutionary or spiral methodology
The *** never gets done! Different versions, always in different stages.

Alternative methodologies
Prototyping
Building a scaled-down working version of the system (i.e. a prototype) Advantages:
Users are involved in design Captures requirements in concrete form

Note: The final system is built based on a good prototype.

Advantages
Speed Easier for end-users to learn System changes discovered earlier End-user involvement (ownership)
increased user satisfaction increased user acceptance

User-analyst communication Early problem detection


reduced development time reduced maintenance

Disadvantages
Poor documentation Hard to control/manage (Unrealistic) User expectations
time for final system final system differences
reduced analysis

Alternative methodologies

Alternative methodologies (cont.)


Joint Application Design (JAD)
Users, Managers and Analysts work together for several days System requirements are reviewed Structured meetings

Rapid Application Development (RAD)


Uses JAD and Prototyping to define. requirements and radically decrease the time needed to design and implement information systems. Key point: delay producing system design until after user requirements are clear.

Rapid Application Development (RAD)

Requirements Planning User Design

Construction
Cutover

Rapid Application Development (RAD)


Overview

Methodology used to decrease time in development process.


Efficient and Cheaper

Allows systems developers and end users work together from the beginning. Becoming a more legitimate way of developing Web Based systems.
E-business applications
VisualAge Generator, Java, WebSphere Stuido etc.

Rapid Application Development (RAD)


Phases
RAD phases are similar to SDLC Shortened and Combined simplifies the development process. Systems are analyzed in isolation to other systems. Eliminates time consuming activities. Coordinating with existing standards and systems during the Design and Development phases RAD focuses on Prototyping similar to JAD Prototyping becomes the basis for the new system

Rapid application development (RAD) a system development strategy that emphasizes speed of development through extensive user involvement in the rapid, iterative, and incremental construction of series of functioning prototypes of a system that eventually evolves into the final system.

Rapid Application Development Strategy

Prototype a small-scale, representative, or working model of the users requirements or a proposed design for an information system. Time box the imposition of a non-extendable period of time, usually 60-90 days, by which the first (or next) version of a system must be delivered into operation.

Rapid Application Development Strategy

Rapid Application Development Strategy


Advantages
User requirements often uncertain or imprecise Encourages active user and management participation Projects get higher visibility and support Stakeholders see working solutions more rapidly Errors detected earlier Testing and training are natural by-products More natural process because change is expected

Disadvantages
May encourage "code, implement, repair" mentality Can solve wrong problem since problem analysis is abbreviated May discourage analysts from considering alternatives Stakeholders reluctant to throw away prototype Emphasis on speed can adversely impact quality

Alternative methodologies (cont.)


Participatory Design (PD)
Emphasizes role of the user Entire user community can be involved in design

Agile Methodologies
Focuses on
Adaptive methodologies People instead of roles Self-adaptive development process

Alternative methodologies (cont.)


Computer-Assisted Software Engineering (CASE) Tools
Automated software tools used by systems analysts to develop information systems Used in alternative methodologies Can be used throughout SDLC

General types of CASE tools


Analysis tools Documentation generators Code generators
Diagramming tools Computer display and report generator

Computer-Aided Systems Engineering (CASE)

What is Computer-Aided Systems Engineering?

Computer-aided systems engineering (CASE) is the application of information technology to systems development activities, techniques, and methodologies. CASE tools are programs (software) that automate or support one or more phases of a systems development life cycle. The technology is intended to accelerate the process of developing systems and to improve the quality of the resulting systems. CASE is not a methodology or an alternative to methodologies. CASE is an enabling technology that supports a methodologys preferred strategies, techniques, and deliverables.

Computer-Aided Systems Engineering (CASE)

The History and Evolution of CASE Technology

The true history of CASE dates back to the early- to mid-1970s. The ISDOS project used a language called Problem Statement Language (PSL) for describing user problems and solution requirements for an information system into a computerized dictionary. A companion product called Problem Statement Analyzer (PSA) was created to analyze those problems and requirements for completeness and consistency. PSL/PSA ran on large mainframe computers. CASE success started with the advent of the personal computer. In 1984, Index Technology (now known as Intersolv) created a PC software tool called Excelerator.

Computer-Aided Systems Engineering (CASE)

A CASE Tool Framework

CASE tools are classified according to which phases of the life cycle they support. The term upper-CASE describes tools that automate or support the upper or earliest phases of systems development the survey, study, definition, and design phases. The term lower-CASE describes tools that automate or support the lower or later phases of systems development detailed design, construction, and implementation (and also support).

Computer-Aided Systems Engineering (CASE)

CASE Tool Architecture

At the center of any true CASE tools architecture is a database called a repository (or a link into such a repository). Around the repository is a collection of tools or facilities to create documentation or other system components. The real power of a true CASE tool is derived from its repository (or its ability to use and update some other tools repository). A CASE repository is a developers database. It is a place where the developers can store diagrams, descriptions, specifications, and other by-products of systems development. Synonyms include dictionary and encyclopedia. Many different CASE tools can share information across a single repository.

OUTPUTS: reports, problems, and analyses

INPUTS: models, descriptions and prototypes

CASE Tool Facilities (on a workstation)

Graphics Tools
Repository Server imported and exported knowledge

links

Description Tools

links

Prototyping Tools

Housekeeping Tools Data Sharing Tools Security and Version Control Tools

Quality Management Tools Decision Support Tools Inquiry and Reporting Tools

check-out/ check in knowledge

Local Repository (on a LAN Server)

CENTRAL REPOSITORY

Design Generators

Code Generators

Document Tools

Computer-Aided Systems Engineering (CASE)

CASE Tool Architecture

CASE tools provide some of the following facilities: Diagramming tools are used to draw the system models required or recommended in most methodologies. Description tools are used to record, delete, edit, and output non-graphical documentation and specifications. Prototyping tools are used construct system components including inputs, outputs, and programs. Inquiry and reporting tools are used to extract models, descriptions, and specifications from the repository. Quality management tools analyze models, descriptions, and prototypes for consistency, completeness, or conformance to accepted rules of the methodologies that the CASE tools support.

Computer-Aided Systems Engineering (CASE)

CASE Tool Architecture

CASE tools provide some of the following facilities: (continued) Decision support tools provide information for various decisions that occur during systems development. Documentation organization tools are used to assemble, organize, and report repository information that can be reviewed by system owners, users, designers, and builders. Design generation tools automatically generate first-draft designs for various system components based on the business requirements recorded in the repository, and technology standards provided by the system designer. Code generator tools automatically generate application programs, or significant portions of those programs.

Computer-Aided Systems Engineering (CASE)

CASE Tool Architecture

CASE tools provide some of the following facilities: (continued) Testing tools help the system designers and builders test databases and application programs. Data sharing tools provide for import and export of repository information to and from other software tools that cannot directly access the repository. Version control tools maintain the integrity of the repository by preventing unauthorized or inadvertent changes, and saving prior versions of various information stored in the repository. Housekeeping tools establish user accounts, privileges, repository subsets, tool defaults, backup and recovery, and other essential facilities.

Computer-Aided Systems Engineering (CASE)

The Benefits of CASE

Some of the most commonly cited benefits include: improved productivity (through automation of tasks and rapid application development) improved quality (because CASE tools check for completeness, consistency, and contradictions) better documentation (mostly because the tools make it easier to create and assemble consistent, high quality documentation) reduced lifetime maintenance (because of the aforementioned system quality improvements combined with better documentation) methodologies that really work (through rule enforcement and built in expertise)

Computer-Aided Systems Engineering (CASE)

The Benefits of CASE

Many information systems organizations provide CASE training and support through a development center. A development center is a central group of information systems professionals who plan, implement, and support a systems development environment for other developers. They provide training and support for both the methodology and CASE tools.

End-User Development
End-user development is a system development effort in which the user is primarily responsible for the development of the system. This is in contrast to the other types of development discussed here, in which a qualified computer professional, such as a systems analyst, takes charge of the system development process. End-user development is feasible only when the system being developed is relatively small and inexpensive. A good example is when a user purchases a PC and develops applications on his or her own. In developing the system, the user might follow a prototyping approach or a method similar to the traditional system development approach.

End-User Development
Certain dangers exist when users develop their own systems in a business environment. Among these are users who do not incorporate proper security measures in their systems, who create systems that interfere with other systems within the organization, and who build systems that cannot effectively be supported. Nonetheless, when computer professionals within an organization are too overloaded to build small important systems to help users, end-user development may be the only alternative.

S-ar putea să vă placă și