1. System Development Phases; Life cycle approach
Chapter Two

2. Chapter content Project identification and selection criteria
Information system development phases

3. Introduction
A project is a temporary endeavor undertaken to accomplish a unique purpose.
Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project.
Attributes of a Project can also be viewed in terms of their attributes: time frame, purpose, ownership, resources, roles, risks and assumptions, interdependent tasks, organizational change, and operating in an environment larger than the project itself.

4. Introduction …
Information system development viewed as project activity which has a definite schedule and deliverables
It requires different individuals with different skill sets.
Although these skills may be different on different projects, a typical project may include the following people:
Project Manager, Project Sponsor, system analyst, system designer, programmer, quality controller

5. Identifying and Selecting Projects
Projects are identified by
Top management
Steering committee
User departments
Development group or senior IS staff
3.5

6. Approaches to project identification
Top-Down Identification
Senior management or steering committee
Focus is on global needs of organization
Bottom-Up Identification
Business unit or IS group
Don’t reflect overall goals of the organization

7. Identifying and Selecting Projects
Classify and rank development projects
Factors for selection:
Perceived needs of the organization
Existing systems and ongoing projects
Resources availability
Evaluation criteria
Current business conditions
Perspectives of the decision makers
3.7

8. The Project Life Cycle & IS Development
The project life cycle (PLC) is a collection of logical stages or phases that maps the life of a project from its beginning to its end
Each phase should provide one or more deliverables.
A deliverable is a tangible and verifiable product of work (i.e., project plan, design specifications, delivered system, etc.).
Deliverables provide tangible benefits throughout the project and serve to define the work and resources needed for each phase.
Projects should be broken up into phases

9. PLC-phases defining the project goal, planning the project,
executing or carrying out the project,
closing the project, and
evaluating the project.
Although projects follow a project life cycle, information systems development follows a product life cycle (analysis, design, development and implementation).

10. SDLC vs PLC
The SDLC is a component of the PLC, and choice of a particular approach for systems development will influence the activities, their sequence, and the estimated time to complete.
In turn, this will directly impact the project's schedule and budget.

11. Which development life cycle is preferable for information system
Which development life cycle is preferable for information system? Justify your selection?
Do you have any experience on the two methods? Reflect for other colleagues?

12. Information System project management
Concerned with activities involved in ensuring that IS is delivered on time and on schedule and in accordance with the requirements of the organizations developing and procuring the software.
Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software.

13. SDLC Variations Many variations of SDLC in practice
No matter which one, tasks are similar
Based on variation of names for phases
SDLC compared to IE compared to Unified Process (UP)
Based on emphasis on people
User-centered design, participatory design
Based on speed of development
Rapid application development (RAD)
Prototyping

14. Life Cycles with Different Names for Phases

15. Six Phases of the System Development Life Cycle(SDLC)
Project Planning Phase
Analysis Phase
Design Phase
Development Phase
Implementation Phase
Maintenance Phase
Daily operation
Periodic evaluation and updating
Assesses feasibility and practicality of system
Design new/ alternative system
Defines system from technical view
New hardware and software is acquired, developed, and tested
System installation and training
Study old system and identify new requirements

16. Phase 1: Preliminary investigation/ Feasibility
All projects are feasible given unlimited resources and infinite time
Unfortunately most projects must be developed within tight budget and time constraint
this means that assessing feasibility of project is a required activity for all projects
feasibility study is carried out to determine quickly with little expense if
the problem is solvable
the problem is worth solving
if a project is not feasible, time, effort, money will not be wasted on a full project

17. Phase …
The task of the feasibility study is NOT to solve the problem, but to gain a sense of its scope and determine if a problem is worth solving.
Feasibility Study ends with a formal presentation to users and management:
GO / NO GO decision must be made

18. Project Feasibility Factors
Six Factors
Economic
Operational
Technical
Schedule
Legal and contractual
Political
3.18

19. Economic Feasibility
Capacity of the business to afford the cost of the new system
Determined by Cost – Benefit Analysis
1.1 Tangible Benefits - Can be measured easily
Examples:
Cost reduction and avoidance
Error reduction
Increased flexibility
Increased speed of activity
Increased management planning and control
1.2 Intangible Benefits - Cannot be measured easily
Increased employee morale
Competitive necessity
More timely information
Promotion of organizational learning and understanding
3.19

20. 3.20

21. Assessing Other Project Feasibility Concerns
Operational Feasibility
Assessment of how a proposed system solves business problems or takes advantage of opportunities
Can the project put into action or operation? What are logistical and motivational (acceptance) considerations
Technical Feasibility
Assessment of the development organization’s ability to construct a proposed system
Can the hardware, software be acquired or developed to the solve the problem?
Schedule Feasibility
Assessment of timeframe and project completion dates with respect to organization constraints for affecting change
Can the project be completed as planned?
Legal and Contractual Feasibility
Assessment of legal and contractual ramifications of new system
Political Feasibility
Assessment of view of key stakeholders in organization toward proposed system
3.21

22. Systems Investigation
A report that summarizes the results of the systems investigation and the process of feasibility analysis and recommends a course of action.
The investigation is usually conducted by a system investigation team and a steering committee.
Steering committee is an advisory group consisting of senior management and users from the IS department and other functional areas.

23. Systems Investigation
Table of Contents for a Systems Investigation Report

24. Phase 2: System Analysis
In depth study of the existing system to determine what the new system should do.
Expand on data gathered in Phase 1
In addition to observation and interviews, examine:
Formal lines of authority (org chart)
Standard operating procedures
How information flows
Reasons for any inefficiencies

25. Phase 2: System Analysis
In depth study of the existing system to determine what the new system should do.
Requirements Analysis
It is the third round analysis.
An assessment used to determine the need of the users, the stakeholders, and the organization.
Converting organizational goals into systems requirements

26. Phase 2: System Analysis
External and Internal Sources of Data
It is the forth and the last round analysis.
The analysis must be very precise.
The results will be used in system design.

27. Systems Analysis Data Analysis
Manipulating the collected data so that it is usable for the development team members who are participating in systems analysis.
Data Modeling
A commonly accepted approach to modeling organizational objects and associations that employ both text and graphics.
Activity (Process) Modeling
A method to describe related objects, associations, and activities.
Data Flow Diagram
A diagram that models objects, associations, and activities by describing how data can flow between and around them.

28. Entity-Relationship Diagram (ERD)
Data Flow Diagram (DFD)
Semantic Description of a Business Process

29. Application Flowchart
Application Flowcharts
Charts that show relationships among applications or systems.

30. Grid Charts Grid Charts
A table that shows relationships among the various aspects of a systems development effort.

31. Systems Analysis Report
Strength and weaknesses of existing system from stakeholders’ perspective.
User/stakeholder requirements for the new system.
Organizational requirements.
Description of what new information systems should do to solve the problem

32. Systems Analysis Report

33. Major Problems in SD
Communication gaps between the user (non-IT) and the developer (IT)
No common language
Lack of IT knowledge (non-IT)
Lack of business sense (IT)
Lack of mutual trust
Lazy

34. Solutions User and developer should have a common ground knowledge
General and essential IT knowledge
General and essential business knowledge
Patient
Quality assurance process

35. Technically How? Spend more time on requirement analysis Documentation
Project plan
Quality plan
Analysis model
Design model
Testing plan
Project schedule
User manual
Maintenance manual

36. Review Questions
What is the difference between system analysis and feasibility study.
What are some criteria or factor you consider system development feasibility? Is it always necessary to undertake feasibility study?
In system analysis, data are collected for further analyzed. Describe in detail the techniques for which the data are collected, and in what situations the techniques can be applied. If necessary, you can add examples to help your discussion.

37. Review Questions
Data flow diagram is an analysis model describing the how data is processed.
Describe, with an example, what are the four components in a DFD.
Describe in detail, step by step, how data flow diagrams are obtained.
DFD, application flowchart, grid charts and screen layouts are four analysis models obtained after system analysis. Describe what are the purposes to obtain such models.
Describe what are the tentative contents that should be included in the System Investigation Report and the System Analysis Report.

38. Phase 3: System Design
Uses specifications from the systems analysis to design alternative systems
Evaluate alternatives based upon:
Economic feasibility - Do benefits justify costs?
Technical feasibility - Is reliable technology and training available?
Operational feasibility - Will the managers and users support it?

39. The Scope of System Design
Problem
Bridge the gap
between a problem and an existing system in a manageable way
System
Design
How?
Use Divide & Conquer:
1) Identify design goals
2) Model the new system design as a set of subsystems
3) Address the major design goals.
Existing System

40. How the Analysis Models influence System Design
Nonfunctional Requirements
=> Definition of Design Goals
Functional model
=> Subsystem Decomposition
Object model
=> Hardware/Software Mapping, Persistent Data Management
Dynamic model
=> Identification of Concurrency, Global Resource Handling, Software Control
Finally: Hardware/Software Mapping
=> Boundary conditions
In Requirements analysis we have beautifully built 3 descriptions of the problem, the models.
Where do the models go in system design? The above list of system design issues looks a little bit random.
But there is a reason behind it:
Nonfunctional Requirements
=> Definition of Design Goals
Functional model
=> Subsystem Decomposition (Subsystems based on functional requirements, coherence & coupling)
Object model
=> Hardware/software Mapping and Data Management (Persistent objects)
Dynamic model
=> Identification of Concurrency, Global Resource Handling, Software Control
Finally: From the Subsystem Decomposition
=> Boundary conditions

41. Example of Design Goals
Reliability
Modifiability
Maintainability
Understandability
Adaptability
Reusability
Efficiency
Portability
Traceability of requirements
Fault tolerance
Backward-compatibility
Cost-effectiveness
Robustness
High-performance
Good documentation
Well-defined interfaces
User-friendliness
Reuse of components
Rapid development
Minimum number of errors
Readability
Ease of learning
Ease of remembering
Ease of use
Increased productivity
Low-cost
Flexibility

42. Stakeholders have different Design Goals
Low cost
Increased productivity
Backward compatibility
Traceability of requirements
Rapid development
Flexibility
Client
(Customer)
End
User
Functionality
User-friendliness
Usability
Ease of learning
Fault tolerant
Robustness
Runtime
Efficiency
Developer/
Maintainer
Minimum # of errors
Modifiability, Readability
Reusability, Adaptability
Well-defined interfaces
Reliability
Portability
Good documentation
Nielson
Usability Engineering
Rubin
Task Analysis

43. Typical Design Trade-offs
Functionality v. Usability
Cost v. Robustness/quality
Efficiency v. Portability
Rapid development v. Functionality
Cost v. Reusability
Backward Compatibility v. Readability
Example: Functionality vs usability. Is a system with 100 functions usable? How about a large scale menu?
Low Cost vs Robustness: A low cost system does not check for errors when the user is entering wrong data
(ebay Entry 5.00 vs 5,00). Let‘s say you bid for 5, 00 Euro
In Germany 5,00 is 5 Euros, if the entry routine expects a „.“, then the „,“ might be overlooked,
and you have bidden. for 500 Dollars!
Efficiency vs Portability: Can you build a portable real-time game? How do you get high framerates. Special graphics routines that access the display buffer! That is usually not portable. If you write portable graphics code, say with the OpenGL, then you sometimes might not get the response times you are looking for. All special graphics code is still hand-tailored for a specific machine or graphics processor.
Rapid development vs. functionality: Let’s say your development time is 5 weeks, you have 5 programmers, your design window is 2 weeks, after design 3 programmers are leaving your company, and your delivery deadline cannot be moved. You are going to reduce the functionality. Not all the use cases in your model can be implemented nor delivered.
Cost vs. Reusability: This is an interesting trade-off, whose validity is changing right now. In the past, if you tried to make your design reusable you had to add extra effort. Recode your data structures (move from array of int to array of Generic). Moving from a 1-1 association to a many-many association involved more coding and more testing. Nowadays, with design patterns, this trade-off is changing a little bit. You can get reusability pretty cheap if you use design patterns!
Backward Compatibility vs Readability.
The same applies to this trade-off. In the past you would guarantee backward compatibility by introducing special switches.
#Ifdef OldSystem then WriteToPaperTapeWriter
#Ifdef Newsystems then WritetoCD-R
Nowadays, again with the use of design patterns, for example, the bridge pattern, you can keep a system backward compatibile and still keep it readable!

44. Design Strategies Functional Design
System Development
Design Strategies
Functional Design
The system is designed from a functional point of view, starting with a high-level view and progressively refining this into a more detailed design
Object oriented design
The system is viewed as a collection of objects rather than as functions

45. Functional Design Decomposition It is a traditional Approach
Also called structured system development
Uses structured analysis and design technique (SADT)
The system is decomposed into program modules
Decomposition
Improves computer program quality
Allows other programmers to easily read and modify code
Each program module has one beginning and one ending
Three programming constructs (sequence, decision, repetition)

46. Functional Design/ Decomposition
Divides complex programs into hierarchy of modules
The module at top controls execution by “calling” lower level modules
Modular programming
Similar to top-down programming
One program calls other programs to work together as single system
Modules are shown with structure chart
Main principle of program modules
Loosely coupled – module is independent of other modules
Highly cohesive – module has one clear task

47. Top-Down or Modular Programming

48. Structure Chart Created Using Structured Design Technique

49. Define what system needs to do (processing requirements)
Structured Analysis
Define what system needs to do (processing requirements)
Define data system needs to store and use (data requirements)
Define inputs and outputs
Define how functions work together to accomplish tasks
Data flow diagrams and entity relationship diagrams show results of structured analysis

50. Data Flow Diagram (DFD) created using Structured Analysis Technique

51. Entity-Relationship Diagram (ERD) created using the Structured Analysis technique

52. Structured Analysis Leads to Structured Design and Structured Programming

53. Object Oriented Design
The system is viewed as collection of objects
It is based on information hiding principle
The system state is decentralized and each object manages its own state information
Objects have a set of its attributes defining their state and operations which act on these attributes
Objects are members of a class

54. Object-Oriented Approach to Systems

55. Object-Oriented Design
Defines object types needed to communicate with people and devices in system
Shows how objects interact to complete tasks
Refines each type of object for implementation with specific language of environment
Object-oriented programming (OOP)
Writing statements in programming language to define what each type of object does
Benefits of OOA include naturalness and reuse

56. Class Diagram with Hierarchy

57. A generalization hierarchy with added detail – Design phase

58. Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment.
You can think of these stimuli as being of two types:
Data Some data arrives that has to be processed by the system.
Events Some event happens that triggers system processing. Events may have associated data, although this is not always the case.

59. Data-driven modeling
Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data input to the system, with relatively little external event processing.
Data-driven models show the sequence of actions involved in processing input data and generating an associated output.
They are particularly useful during the analysis of requirements as they can be used to show end- to-end processing in a system.

60. An activity model of the insulin pump’s operation

61. Order processing

62. Event-driven modeling
Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone.
Event-driven modeling shows how a system responds to external and internal events.
It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another.

63. State machine models
These model the behaviour of the system in response to external and internal events.
They show the system’s responses to stimuli so are often used for modelling real-time systems.
State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.
Statecharts are an integral part of the UML and are used to represent state machine models.

64. State diagram of a microwave oven

65. Phase 3: System Design Tools Used
Computer-Aided System Engineering (CASE)
Automated tools to improve the speed and quality of system development work
Contains database of information about system called repository
Upper CASE - support for analysis and design
Lower CASE - support for implementation
ICASE - integrated CASE tools

66. CASE Tool Repository Contains all System Information

67. Phase 3: System Design Documentation Produced
System Design Report
Describe Alternatives including Inputs/Outputs, processing
Recommend Top Alternative based upon:
System Fit into the Organization
Flexibility for the future
Costs vs. benefits
System design models like static (class diagram) and dynamic models (sequence diagram)

68. Documentation In Structured Systems Analysis and Design
Data Flow Diagrams
Data Dictionary
Process Specifications
To Implementation
Structure Chart

69. Phase 4: System Development
Build the system to the design specifications
Develop the software
Purchase off-the-shelf software OR
Write custom software
Acquire the hardware
Create manuals for users and operators

70. Phase 4: System Development -- Testing
Unit Test
Systems test
Verifies each individual program works by itself
Verifies all programs in application work together
Integration Test
Verifies application works with other applications

71. Phase 5: System Implementation
Convert from old system to new system
Train users
Compile final documentation
Evaluate the new system

72. Phase 5: System Implementation Types of Conversion
Direct/plunge/crash approach – entire new system completely replaces entire old system, in one step
Parallel approach - both systems are operated side by side until the new system proves itself
Pilot approach - launched new system for only one group within the business -- once new system is operating smoothly, implementation goes company-wide
Phased/incremental approach - individual parts of new system are gradually phased-in over time, using either crash or parallel for each piece.

73. Phase 5: System Implementation
User Training
Ease into system, make them comfortable, and gain their support
Most commonly overlooked
Can be commenced before equipment delivery
Outside trainers sometimes used

74. Phase 6: Operations & Maintenance
Types of changes:
Physical repair of the system
Correction of new bugs found (corrective)
System adjustments to environmental changes
Adjustments for users’ changing needs (adaptive)
Changes to user better techniques when they become available (perfective)

75. Phase 6: Operations & Maintenance
Evaluation Methods
Systems audit - performance compared to original specifications
Periodic evaluation - “checkups” from time to time, modifications if necessary

76. Review Questions What is the system development life cycle
What is methodology? What it contains?
Explain the different system design strategies? Explain the pros and cons of these design strategies
What are the tools and techniques at different stages of system development?
What are the main activities during system implementation?