Review of SDLC Project Phases Planning Why build

Review of SDLC

Project Phases Planning (Why build the system? How should the team go about building it? ) p Analysis (Who uses system, what will it do, where and when will the system be used? ) p Design (How will the system work? ) p Implementation (System delivery) p

Planning Identifying business value p Analyze feasibility p Develop work plan p Staff the project p Control and direct project p

Analysis strategy p Gathering business requirements p Requirements definition use cases p Process modeling p Data modeling p

Design selection p Architecture design p Interface design p Data storage design p Program design p

Implementation p Construction n n p Program building Program and system testing Installation n Conversion strategy-变更策略 Training plan Support plan

Processes and Deliverables Process Planning Analysis Design Implementation Product System Request Feasibility Analysis Workplan System Proposal System Specification New System and Maintenance Plan

Waterfall Development Methodology

Project Estimates Based on Industry Standard Percentages Planning Industry Standard For Web Applications Time Required 4 in Person Months Analysis 15% Design 20% 5. 33 Implementation 35% 9. 33 30% 8

Project Phases

Time Allocation by Phase p Remember the 40 -20 -40 Rule p Specification-Implementation-Test Planning Code & Unit Test Integration & Test Commercial DP 25% 40% 35% Internet Systems 55% 15% 30% Real-time Systems 35% 25% 40% Defense Systems 40% 20% 40% Bennatan, E. M, “On Time Within Budget”

Time Allocation by Phase Activity Small Project (2. 5 K Large Project LOC) (500 K LOC) Analysis 10% 30% Design 20% Code 25% 10% Unit Test 20% 5% Integration 15% 20% System test 10% 15% Mc. Connell, Steve, “Rapid Development”

Activities by % of Total Effort

Potential Deliverables by Phase

Pros and Cons of the Waterfall Methodology Pros Identifies systems requirements long before programming begins Minimizes changes to requirements as project progresses Cons Design must be specified on paper before programming begins Long time between system proposal and delivery of new system

Parallel Development Methodology

Pros and Cons of Parallel Development Methodology Pros Cons Reduces Schedule Time Still Uses Paper Documents Less Chance of Rework Sub-projects May Be Difficult to Integrate

Rapid Application Development p Incorporate special techniques and tools: n n CASE tools JAD sessions Fourth generation/visualization programming languages Code generators

Three RAD Categories Phased development n A series of versions developed sequentially p Prototyping n System prototyping p Throw-away prototyping n Design prototyping p

Phased Development Methodology Insert Figure 1 -4 here

Pros and Cons of Phased Development Methodology Pros Users Get a System To Use Quickly Users Can Identify Additional Needs For Later Versions Cons Users Work with a System that is Intentionally Incomplete

How Prototyping Works

Pros and Cons of Prototyping Methodology Pros Users Interact with Prototype Very Quickly Users Can Identify Needed Changes And Refine Real Requirements Cons Tendency to do Superficial Analysis Initial Design Decisions May Be Poor

Throwaway Prototyping

Throwaway Prototyping Methodology Pros Risks are Minimized Important Issues are Understood Before the Real System is Built Cons May Take Longer Than Prototyping

Agile-敏捷 Development: Extreme Programming

Spiral

Spiral Emphasizes risk analysis & mgmt. in each phase p A Series of Mini-projects p Each addresses a set of “risks” n Start small, explore risks, prototype, plan, repeat p Early iterations are “cheapest” p Number of spirals is variable n Last set of steps are waterfall-like p

Spiral p Pros n n n p Can be combined with other models As costs increase, risks decrease Risk orientation provides early warning Cons n n More complex Requires more management

Criteria for Selecting the Appropriate Methodology Clear user requirements p Familiarity with technology p Complexity of system p Reliability of system p Time schedule p Schedule visibility p

Varies by project p Opt for “iterative” or “incremental” p How well are requirements understood? p What are the risks? p Is there a fixed deadline? p How experienced is the team or customer? p

Stakeholders – The Source of System Requirements p People with interest in successful system implementation p Three primary groups of stakeholders: p n Users (use system) n Clients (pay for and own system) n Technical staff (ensure system operation) Every type of stakeholder is identified by analyst

Stakeholders Interested in New System Development

ATM stakeholders p p p p p Bank customers Representatives of other banks Bank managers Counter staff Database administrators Security managers Marketing department Hardware and software maintenance engineers Banking regulators-监管者