Documente Academic
Documente Profesional
Documente Cultură
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.
Majority of Organizations and Firms use a specific type of methodology that is tailored to their needs.
Analysis
Information
Gathered and Used to help the development process
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.
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.
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.
3-10
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.
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.
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
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.
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
Advertis ing
Sales
C ustomer
Orde r
Picking Orde r
W arehouse
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
approved order
West Customers
ship order
order
Validate customer
credit
SYSTEM ANALYSIS
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
New Order
N T Server LA
Get an Or der Validate an Or der File an Or der
Order Form
First Order
PB X
Release an Or der
Ethernet LA N/NT
SYSTEM DESIGN
Help +
Customer s
Pr oducts
Or der s
Product Lookup
C lient PC
C lient PC
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 IMPLEMENTATION
Database Technology
Interface Technology
Networking Telchnology
SYSTEM SUPPORT
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.
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.
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.
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.
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.
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.
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
Systems Analysis
Implementation error
Systems Implementation
Systems Design
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.
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
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.
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
Fourth phase
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
Physical Design
Technical specifications
Implementation
Implementation
Hardware and software installation Programming User Training Documentation
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
Advantages
Speed Easier for end-users to learn System changes discovered earlier End-user involvement (ownership)
increased user satisfaction increased user acceptance
Disadvantages
Poor documentation Hard to control/manage (Unrealistic) User expectations
time for final system final system differences
reduced analysis
Alternative methodologies
Construction
Cutover
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) 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.
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.
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
Agile Methodologies
Focuses on
Adaptive methodologies People instead of roles Self-adaptive development process
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.
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.
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).
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.
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
CENTRAL REPOSITORY
Design Generators
Code Generators
Document Tools
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.
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.
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.
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)
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.