comp 7320

Chuck的复习手记

information system

An information system (IS) is any combination of information technology and people's activities that support operations, management and decision making.

Five Components of IS 人硬软数网

• People, which consists of IT specialists (such as a Database Administrator or Network Engineer) and end-users (such as Data Capture Clerks)

• Hardware, which consists of all the physical aspects of an information system, ranging from peripherals to computer parts and servers

• Software, which consists of System Software, Application Software and Utility Software

• Data, which consists of all the knowledge and databases in the IS

• Networks, which consists of communication media and network
  support

Data, Capta, Information, and Knowledge

• Data
  Facts
  We may or may not focus on
• Capta
  We focus on
  Use cognitive settings to capture
  Add appreciation to the data
• Information
  Relate the capta to other facts
  Understood within a context of interest
• Knowledge
  Information is organized into structures
  May be longer-lasting

System development life cycle (SDLC) process

SDLC: Planning

1. Project Initiation

   • Develop a system request
   • Conduct a feasibility analysis

2. Project Management

   • Develop work plan
   • Staff the project
   • Control and direct the project

Assessing Project Feasibility

Six Categories

• Economic
• Operational
• Technical
• Schedule
• Legal and contractual
• Political

Economic Feasibility

• Development costs
• Operating costs
• Tangible benefits (cost savings and
  revenues)
• Intangible costs and benefits

Assessing Economic Feasibility

• Cost–Benefit Analysis
• Determine Benefits
• Tangible benefits
• Can be measured easily
  
  • Examples
    ▪ Cost reduction and avoidance
    ▪ Error reduction
    ▪ Increased flexibility
    ▪ Increased speed of activity
    ▪ Increased management planning and control

SDLC: Analysis

1. Develop analysis strategy
2. Gather requirements
3. Develop a system proposal

Data Flow Diagramming

• Logical process models describe processes without suggesting how they are conducted
• Physical process models provide information that is needed to build the system
  

Level-0 diagram is a data flow diagram that represents a system’s major processes, data flows, and data stores at a high level of detail.

Decomposition is the process of representing the system in a hierarchy of DFD diagrams

Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

SDLC: Design

1. Develop a design strategy
2. Design architecture and interfaces
3. Develop databases and file specifications
4. Develop the program design

Data model

• Captures the overall structure of data in an organization.
• Shows the relatonship among people, places and things
• Balance with process models

Entity-Relationship data model (E-R model): a detailed, logical representation of the entities, associations and data elements for an organization or business area
Entity-relationship diagram (E-R diagram): a graphical representation of an E-R model

The E-R model

• Data entities in the business environment.
• Relationships or associations among those
  entities.
• Attributes or properties of both the entities and
  their relationships.

Normalization: the process of convertin complex data structures into simple, stabl data structures.

• The result of normalization is that ever nonprimary key attribute depends upon the whole primary key
• Three normalization rules are common

SDLC: Implementatio

1.Construct system
2. Install system
- Implement a training plan for the users
3. Establish a support plan

Six major activities：

• Coding
• Testing
• Installation
• Documentation
• Training
• Support

Transitioning to new systems involves managing change from pre-existing norms and habits
Change management involves:
- Unfreezing -- loosening up peoples’ habits annorms
- Moving -- transition from old to new system
- Refreezing -- institutionalize and make efficient thnew way of doing things

Project Team Roles

Business Analyst

Analyzing the key business aspects of the system
Identifying how the system will provide business value
Designing the new business processes and policies

Systems Analyst

Identifying how technology can improve business processes
Designing the new business processes
Designing the information system
Ensuring the system conforms to IS standards

Infrastructur Analyst

Ensuring the system conforms to infrastructure standards
Identifying infrastructure changes required by the system
Change Management Analyst
Developing and executing a change management plan
Developing and executing a user training plan

Project Manager

Managing the team Developing and monitoring the project plan
Assigning resources
Serving as the primary point of contact for the project

Project Team Skills

• Technical
• Business
• Analytical
• Interpersonal
• Management
• ethical

software development approaches

• SDLC methodology
• Agile methodology

pros

• A linear framework, simple and easy to understand and use
• Easy to manage due to the rigidity of the model . each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

cons

• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing. So risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

pros

• Some working functionality can be developed quickly and early in the life cycle.
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
• Less costly to change the scope/requirements.
• Testing and debugging during smaller iteration is easy.
• Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
• Easier to manage risk - High risk part is done first.
• With every increment operational product is delivered.
• Issues, challenges & risks identified from each increment can be utilized/applied to the next increment.
• Risk analysis is better.
• It supports changing requirements.
• Initial Operating time is less.
• Better suited for large and mission-critical projects.
• During life cycle software is produced early which facilitates customer evaluation and feedback.

cons

• More resources may be required.
• Although cost of change is lesser but it is not very suitable for changing requirements.
• More management attention is required.
• System architecture or design issues may arise because not all requirements are gathered in the beginning of the entire life cycle.
• Defining increments may require definition of the complete system.
• Not suitable for smaller projects.
• Management complexity is more.
• End of project may not be known which is a risk.
• Highly skilled resources are required for risk analysis.

pros

• Changing requirements can be accommodated.
• Allows for extensive use of prototypes
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and more risky parts can be
  developed earlier which helps better risk management.

cons

• Management is more complex.
• End of project may not be known early.
• Not suitable for small or low risk projects and could be expensive for small projects.
• Process is complex
• Spiral may go indefinitely.
• Large number of intermediate stages requires excessive documentation.
  

pros

• Is a very realistic approach to software development
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned context.
• Little or no planning required
• Easy to manage
• Gives flexibility to developers

cons

• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must without which it will not work.
• Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction.
• There is very high individual dependency, since there is minimum documentation generated.
• Transfer of technology to new team members may be quite challenging due to lack of documentation.
  

pros

• Changing requirements can be accommodated.
• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in short time.
• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.

cons

• Dependency on technically strong team members for identifying business requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on modeling skills.
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
• Management complexity is more.
• Suitable for systems that are component based and scalable.
• Requires user involvement throughout the life cycle.
• Suitable for project requiring shorter development times.

When to Use

Linear

• Clearly defined solution and requirements
• Not many scope change requests
• Routine and repetitive projects
• Uses established templates

Incremental

• Same as linear but delivers business value early and often
• Some likelihood of scope change requests

Iterative

• Unstable or incomplete requirements and functionality
• Learn by doing and by discovery