Скачать презентацию Chapter 6 System Development Analyzing designing systems Скачать презентацию Chapter 6 System Development Analyzing designing systems

e38e6683fdeb85fe275ce61f6b74b313.ppt

  • Количество слайдов: 60

Chapter 6: System Development Analyzing & designing systems Prototyping IS project types Chapter 6: System Development Analyzing & designing systems Prototyping IS project types

State of the Industry • There are many good ideas for implementing computer systems State of the Industry • There are many good ideas for implementing computer systems in business • Bringing in a project: on time within budget as specified is very difficult

Software Development Alternatives • • • Code-and-Fix Waterfall Prototyping Spiral Model Rapid Prototyping Others Software Development Alternatives • • • Code-and-Fix Waterfall Prototyping Spiral Model Rapid Prototyping Others like component assembly projects and CASE tool which involve a degree of reuse of previously developed project.

Waterfall Model • • System feasibility Boehm (1988) Software plans & requirements Product design Waterfall Model • • System feasibility Boehm (1988) Software plans & requirements Product design Detailed design Code Integration Implementation Operations & Management

Prototyping – (Evolutionary) • Develop system on a small scale • let user try Prototyping – (Evolutionary) • Develop system on a small scale • let user try the system • User identifies needed improvement Especially good if benefits hard to identify (“better decision making”) also appropriate to compare alternatives

Spiral Model • The spiral model is a systems development lifecycle (SDLC) model used Spiral Model • The spiral model is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. The steps in the spiral model can be generalized as follows: • The new system requirements are defined in as much detail as possible. • A first prototype of the new system is constructed from the preliminary design. • A second prototype is evolved by a four procedure: - evaluating the first prototype in terms of its strengths, weaknesses, and risks; - defining the requirements of the second prototype; - planning and designing the second prototype; - constructing and testing the second prototype. • At the customer's option, the entire project can be aborted if the risk is too great. • The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed. • The preceding steps are iterated until the customer is satisfied. • The final system is constructed, based on the refined prototype. • The final system is thoroughly evaluated and tested.

The spiral Model loops Cycle 1 Cycle 2 Risk analysis Prototype Operation concept Models The spiral Model loops Cycle 1 Cycle 2 Risk analysis Prototype Operation concept Models Requirements plan Software requirements Life cycle plan Requirements validation

The spiral Model loops cont. . Cycle 3 Risk analysis Prototype Models Software product The spiral Model loops cont. . Cycle 3 Risk analysis Prototype Models Software product design Validation & verification Cycle 4 Risk analysis Prototype Models Detail design Coding and unit testing Integration &test plan Integration user acceptance, and implementation

Quotes…. . • Some people make things happen, some watch things happen, while others Quotes…. . • Some people make things happen, some watch things happen, while others wonder what has happened. • Those who do not read are no better off than those who cannot. • Two things are infinite : the universe and human stupidity; and I’m not sure about the universe. ~ Albert Einstein • Vision without action is a daydream. Action without vision is a nightmare. • If I had nine hours to chop down a tree, I’d spend the first six sharpening my ax. ~ Abraham Lincoln • Failures are divided into two classes – those who thought and never did, and those who did and never thought.

Risks and Responses • Personnel best talent training team building • Budget & schedule Risks and Responses • Personnel best talent training team building • Budget & schedule multiple estimates design to budget requirements scrubbing • Wrong functions user surveys, prototype • User interface prototyping, scenarios

Risks and Responses • Excessive features requirements scrubbing • Many changes high change threshold Risks and Responses • Excessive features requirements scrubbing • Many changes high change threshold • External component problems compatibility analysis, benchmarking • Real-time perform simulation, benchmarking prototyping • Technical limits cost/benefit prototyping

Rapid Prototyping - Is a software development methodology that uses minimal planning in favor Rapid Prototyping - Is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive preplanning generally allows software to be written much faster, and makes it easier to change requirements. - It involves methods like iterative development and software prototyping. - Four phases of RAD are: • Requirements planning • User design • Construction • Cutover, testing training and installation

Other Systems Development Options • • • Component Assembly Model (CAM) has a close Other Systems Development Options • • • Component Assembly Model (CAM) has a close resemblance with the Rapid Application Development (RAD) model. CAM uses a lot of previously made components. CAM doesn’t need to develop programs from scratch, but it will be putting together powerful components. All the developers has to do is to know what the customer wants, look for the components to answer the need and put together the components to create the program. • Component Assembly Projects: typically object oriented modules • Rapid Application Development: techniques for compressing the life cycle - Computer Aided Software Engineering - Joint Application Development

Software Development Standards • Standards are the key to effective quality management • They Software Development Standards • Standards are the key to effective quality management • They may be international, organizational or project standards • Product standards define characteristics that all components should exhibit e. g. a common programming style • Process standards define how the software process should be enacted (performed)

Importance of Standards • Encapsulation of best practice- avoids repetition of past mistakes • Importance of Standards • Encapsulation of best practice- avoids repetition of past mistakes • Framework for quality assurance process - it involves checking standard compliance • Provide continuity - new staff can understand the organization by understand the standards applied

PM International Standards • • • CMM, Capability Maturity Model from the Software Engineering PM International Standards • • • CMM, Capability Maturity Model from the Software Engineering Institute. GAPPS, Global Alliance for Project Performance Standards- an open source standard describing COMPETENCIES for project and program managers. A Guide to the Project Management Body of Knowledge. HERMES method, Swiss general project management method, selected for use in Luxembourg and international organizations. The ISO standards ISO 9000, a family of standards for quality management systems, and the ISO 10006: 2003, for Quality management systems and guidelines for quality management in projects. PRINCE 2, PRojects IN Controlled Environments. Team Software Process (TSP) from the Software Engineering Institute. Total Cost Management, Framework, AACE International's Methodology for Integrated Portfolio, Program and Project Management) V-Model, an original systems development method. The Logical framework approach, which is popular in international development organizations. IAPPM, The International Association of Project & Program Management, guide to Project Auditing and Rescuing Troubled Projects.

ISO 9001 of JORDAN ISO 9001 of JORDAN

SEI • The SEI works with industry, academic institutions and the United States government SEI • The SEI works with industry, academic institutions and the United States government to improve the performance and reliability of computer systems by managing pilot programs, conducting tests, offering courses and providing services for licensing and publication. • U. S Defence Dept. funded institute associated with Carnegie Mellon • Mission is to promote software technology transfer particularly to defence contractors • Maturity model proposed in mid-1980 s, refined in early 1990 s. • Work has been very influential in process improvement

Maturity model levels • There are five levels defined along the continuum of the Maturity model levels • There are five levels defined along the continuum of the CMM and, according to the SEI: • Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process. • Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted. • Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions). • Managed - the process is quantitatively managed in accordance with agreed-upon metrics. • Optimizing - process management includes deliberate process optimization/improvement.

The SEI process maturity model The SEI process maturity model

Key process areas Key process areas

SEI model problems (CMM) • It focuses on project management rather than product development. SEI model problems (CMM) • It focuses on project management rather than product development. • It has no formal theoretical basis. • It concentrate on process, but ignores people. • It ignores the use of technologies such as rapid prototyping. • It does not incorporate risk analysis as a key process area • It does not define its domain of applicability

Effect of CMM Level Mc. Connell [1993] Level 1 Cost ($mill) 33 Time (months) Effect of CMM Level Mc. Connell [1993] Level 1 Cost ($mill) 33 Time (months) 40 Quality LOC/hr (def/k) 9. 0 1 2 15 32 3. 0 3 3 7 25 1. 0 5 4 3 19 0. 3 8 5 1 16 0. 1 12

Quote • Quote • "In times of universal deceit (deception, fraud), telling the truth will be a revolutionary act. " • We are what we repeatedly do. • If the idiots hate you, it proves you're not one of them!

IS Project Types • maintenance • conversion • new systems development IS Project Types • maintenance • conversion • new systems development

Mcleod-Smith view IS project differently • System architecture project, strategic system plan for the Mcleod-Smith view IS project differently • System architecture project, strategic system plan for the organization. • End user projects. • Business re-engineering projects, new ways of doing business. • Technology implementation. • Package implementation.

Maintenance Projects by far maintenance projects the most common type of IS • duration Maintenance Projects by far maintenance projects the most common type of IS • duration • training • categories – fixing errors – minor enhancements. – major enhancements, high level of design

Duration of Maintenance Projects • Impact on Organization’s Master Plan biggest factor – if Duration of Maintenance Projects • Impact on Organization’s Master Plan biggest factor – if significant contribution to revenue, more likely to have established maintenance team – can contribute as revenue source (royalties) or as a production tool – if less revenue impact, MORE LIKELY TO HAVE PROJECT TEAM for maintenance

Training & Maintenance Projects • some companies use maintenance as a training ground for Training & Maintenance Projects • some companies use maintenance as a training ground for new employees • exposure to maintenance can make an organization’s operations much clearer

FIXING ERRORS • clear objective - complexity depends on – nature of the system, FIXING ERRORS • clear objective - complexity depends on – nature of the system, error, personnel • BEST CASE: – small system, easily traced – can assign to someone familiar with it • WORST CASE: – nobody familiar with system – very large & complex system – system evolved from earlier versions

MINOR ENHANCEMENTS • • • adding, modifying, deleting data or reports a degree of MINOR ENHANCEMENTS • • • adding, modifying, deleting data or reports a degree of original design constrained by original design usually not under critical conditions therefore, more likely to examine alternative approaches • more likely assigned to those with design capabilities, knowledge of the organization

MAJOR ENHANCEMENTS • design & implementation scope high • wide-scale modification of existing module, MAJOR ENHANCEMENTS • design & implementation scope high • wide-scale modification of existing module, or development of new module • can be a collection of minor enhancements with some common characteristic • need experienced personnel

MAJOR ENHANCEMENTS • EASIEST IF – – personnel know system clear connection to a MAJOR ENHANCEMENTS • EASIEST IF – – personnel know system clear connection to a corporate goal straightforward processes CASE tool used to develop • DIFFICULT WHEN – new personnel – hard to assess criticality of system – no design & implementation standards

CONVERSION PROJECTS • change an existing system (not necessarily computerized) – manual to computer-based CONVERSION PROJECTS • change an existing system (not necessarily computerized) – manual to computer-based – one computer platform to another

Convert Manual to Automated • closest to pure design & development • major pitfalls Convert Manual to Automated • closest to pure design & development • major pitfalls – improper specification – failure to accommodate changes • need knowledge of existing system, desired system, how to make transition

Conversion Change Management • need senior management support • need to convince affected employees Conversion Change Management • need senior management support • need to convince affected employees that the change will lead to better working environment • JOB REDEFINITION • MAY DISPLACE EMPLOYEES - need retraining

Convert to New Technologies • from one computer system to another • NEW JOB Convert to New Technologies • from one computer system to another • NEW JOB DESCRIPTIONS – example - text only to text & image keyboard only to scanning, working with objects • DATA RETRIEVAL changes • Conversion to new or emerging technologies much more involved

Convert to New Technologies • SIMPLEST – – new hardware similar to old new Convert to New Technologies • SIMPLEST – – new hardware similar to old new operating system similar to old existing applications modular vendor supplied routines for conversion • WORST – major change: single task to multi-task – line-oriented to icon-oriented – keyboard to mouse

Language-Based Conversions • translate from one language to another • most from 3 GL Language-Based Conversions • translate from one language to another • most from 3 GL (COBOL) to 4 GL • need experts in both old & new languages – impact on data & code structure – take full advantage of 4 GL

Non-procedural Conversions • instead of sequential control, statements written as rules fired when all Non-procedural Conversions • instead of sequential control, statements written as rules fired when all conditions satisfied • object-oriented approaches – objects control processing • need expertise in old & new languages • more code reuse in object-oriented

Hardware-based Conversions • causes – convert to new platform for marketing purposes – bring Hardware-based Conversions • causes – convert to new platform for marketing purposes – bring in-house a formerly time-shared system – purchase new computing platform • most effort in converting low-level input & output processing routines

Hardware-based Conversions • same vendor - little problem – IBM 32 bit words with Hardware-based Conversions • same vendor - little problem – IBM 32 bit words with 8 bit bytes – CDC 60 bit words with 6 bit bytes – code (even in same language) won’t run same – vendors may supply different codes • BEST CASE - vendor specific I/O localized in routines supplied by vendor • USUALLY some adjustments required

New Systems Development each type of system has different project management characteristics • • New Systems Development each type of system has different project management characteristics • • transaction processing (TPS) management control decision support systems (DSS) group support systems (GSS) executive information systems Enterprise Resource Planning (ERP) Internet Commerce (IC)

Transaction Processing • high volumes of quantitative data, variety of input sources • drive Transaction Processing • high volumes of quantitative data, variety of input sources • drive standard reports, basis for other systems • complexity arises from volume – may involve complex calculations

Management Control more specialized than transaction processing • • monitor manpower allocations monitor project Management Control more specialized than transaction processing • • monitor manpower allocations monitor project activities progress monitor production levels monitor sales by region compare expected with actual if variance too great, trigger action

Decision Support Systems • • explore decision alternatives data from a variety of sources Decision Support Systems • • explore decision alternatives data from a variety of sources may include models Project Team needs expertise in models

Group Support Systems • allow multiple decision makers to work on decision problem • Group Support Systems • allow multiple decision makers to work on decision problem • Process oriented, their primary function is to allow people to communicate: – can be different time, place • Features of GSS includes: – anonymity – brainstorming – consensus building

Executive Support Systems • access to data of all types both in house and Executive Support Systems • access to data of all types both in house and external. • much more subjective data, long range, such periodic government reports. • INTERFACE critical • drill-down data tools for details about the summary data. • trend analysis - graphics & statistics • exception reports

Enterprise Resource Planning • Design to serve all computing needs of an organization. • Enterprise Resource Planning • Design to serve all computing needs of an organization. • Generally implemented in modules. • Not trivial to implement • Vendors are willing to assist.

Internet Commerce • Rethinking the business and its key process • Developing affordable information Internet Commerce • Rethinking the business and its key process • Developing affordable information technology infrastructure • Constructing specific internet products and services.

Recap • IS project management can involve a wide variety of tasks • Need Recap • IS project management can involve a wide variety of tasks • Need to be able to get technical expertise as well as experience with old systems • Apply systems approach

Systems Development Approach Based on a complete Life cycle analysis. Project proposals are measured Systems Development Approach Based on a complete Life cycle analysis. Project proposals are measured on: cost, time, and performance SDLC phases: • Specification • Design • Code (acquisition) • Data conversion • Testing • implementation

Specification • User identifies need • Systems analyst plans solution • Feasibility study: clear, Specification • User identifies need • Systems analyst plans solution • Feasibility study: clear, concise statement of the problem • Statement of work: specification of what is to be done • MOST PROJECTS DIE IN THE SPECIFICATION PHASE

Design • How software will meet requirements (vendors make a living telling clients that Design • How software will meet requirements (vendors make a living telling clients that their system is exactly what the client needs) • OPTIONS: make or buy in-house or outsource • Request for Proposal: specify for bidding • OUTPUT: detailed list of user requirements and system requirements

Xerox Halper (1994) • • Early 1994 outsourced IS to EDS had profit of Xerox Halper (1994) • • Early 1994 outsourced IS to EDS had profit of $620 million on 14. 6 billion shed non-core business reduced IS staff by 2, 000

Code • If acquire, Selection of Builder – Cost…. within the budget – Feasibility…bidder Code • If acquire, Selection of Builder – Cost…. within the budget – Feasibility…bidder can do the project – Experience…bidder’s record on similar project – Reputation… quality work of bidder • cost-benefit study

Data Conversion • Important in data warehousing, data mining • Useful for decision support, Data Conversion • Important in data warehousing, data mining • Useful for decision support, executive information systems

Testing • User evaluates system performance • transfer to user (installation) • TRAINING Testing • User evaluates system performance • transfer to user (installation) • TRAINING

Implementation • Install and check system • User Training is a key to success Implementation • Install and check system • User Training is a key to success – Especially for enterprise-wide systems • User evaluates system performance and any problem detected will be fixed. •

Summary • System analysis & development has evolved a great distance • Many methodologies Summary • System analysis & development has evolved a great distance • Many methodologies exist – Unimportant which – Helps a great deal to focus on one • Standards can increase development productivity • Many types of IS projects • Development of a system a sequence of functional tasks