75 terms

INFS2603 Chapter 1: Introduction to Systems Analysis and Design

To be added later: - Detailed workflows and phases

Terms in this set (...)

Information system
A set of interrelated components that collect (or retrieve), process, store, and distribute information to support decision making and control in an org
Data that has been shaped to be meaningful and useful
late, over budget or delivered with fewer features than planned
Why do we need a formal process (PADIm)?

- _________ occur (too) often
- Creating systems is not __________
- Projects are _______, over ________ or delivered with __________ features than planned
Four fundamental phases in the SDLC :
1. Planning - what might solve the problem
2. Analysis - understanding the problem specifics
3. Design - designing solution to the problem
4. Implementation - building the solution
- Different projects ______ differently BUT all projects have these elements
- Each phase is composed of ______, which rely upon ______ that produce _______ (documents)
- SDLC is a process of ________
- each phase ________ on work (deliverables) done previously
- Phases are executed ________ or in some other pattern
- emphasise stages
- steps
- techniques
- deliverables
- gradual refinement
- refines/elaborates
- sequentially, incrementally, iteratively
Planning phase

- Why
- value
- How long

- Deliverable for this phase is project plan
- fundamental process of understanding why an IS should be built and determining how the project team will go about building it.

Questions to be answered:
- ______ should we build this system?
- What _____ does it provide?
- _______ will it take to build?

Project Initiation and Project Management
2 Steps in Planning Phase
Project Initiation
1st Step in Planning phase

- Identify the system's business value to the org.
- Most ideas for new systems outside IT dept. (system request).
- The IS dept. works together with person/dept that generated request (project sponsor)
-> feasibility analysis (of technical, economic and organisational feasibility)
-> send to IS approval committee
Project Management

project plan

proposed system.

Project Manager
2nd Step in Planning phase

Once approved - project init.-> ____________
- Develop the work plan, staff the project, monitor and control the project

Deliverable for this is ____________
- How the project team will go about developing the ____________
- __________ identifies the tasks that need to be accomplished and determines how long each one will take,
- Tasks organised within a work breakdown structure
Major Components of Feasibility Analysis
Technical, Economic, Organisational Feasibility
Technical Feasibility
Can we Build it?

Identify risks in the following areas:
- The functional area: Are analysts familiar with this portion of the business?
- The technology: Less familiarity generates more risk
- Project size: Large projects have more risk
- Compatibility: Difficult integration increases the risk
Economic Feasibility
- Identify the costs and the benefits
- Assign values to the costs and benefits
- Determine the cash flow
- Determine the value using one or more methods:
- Net present value (NPV)
- Return on investment (ROI)
- Break-even point
Organisational Feasibility
- Will the users use/accept the system?
- Is the project strategically aligned with the business?
- Conduct a stakeholder analysis
- Project champion(s)
- Organizational management
- System users
- Others
Analysis Phase

- Who
- What
- Where and When

• The deliverable is both an analysis and a high-level initial design for the new system
- answers the questions of who will use the system, what the system will do and where and when it will be used
• Project team investigates current system(s), identifies opportunities for improvement and devs a concept for new system

Questions to be answered:
- _______ will use it?
- ________ should the system do for us?
- _______ and _______ will it be used?

3 steps in Analysis phase
- Analysis Strategy
- Requirements Gathering
- System Proposal
Analysis Strategy



1st step in Analysis Phase

- developed to guide project team's _________.
- Analysis of current system ("_______") and its problems then ways to design new system ("_______")
Requirements Gathering
2nd step in Analysis phase following Analysis Strategy

- dev of a concept for a new system -> dev a business analysis models (e.g. use case).
- Create a business model to represent business data, business processes
System Proposal
- document (containing analyses, system concept, and models) presented to project sponsor/other key decision makers to decide whether to move system forward
- The initial deliverable that describes what business requirements the new system should meet.
Design Phase
- How the system will operate in terms of hardware, software, and network infrastructure; the UI, forms and reports; and specific programs, databases, and files needed.

- The deliverables are the system specifications (architecture design, interface design, DB and file specs, program design)
- At end of phase, feasibility analysis and project plan are reexamined/revised and another approval to continue is required
4 Steps of Design Phase
1. Develop design strategy - clarifies whether the system will be developed in house, outsourced or buy existing software
2. Basic architecture and interface design - describes hardware, software, and network infrastructure to be used. Usually adds/modifies existing infrastructure. Also specifies interface design (how user moves through system)
3. Dev DB and file specs - define exactly what data will be stored and where it is stored
4. Dev program design - defines programs that need to be written and exactly what each program will do
Implementation Phase
- final phase, system is actually built (write the programming code) or purchased. usually the longest/most expensive part of SDLC
3 steps of Implementation Phase
1. System construction - system built/tested to ensure it performs as designed.

2. Installation - old system is turned off and new one is turned on. Includes direct, parallel, phased, and pilot. Important to dev training plan to teach users how to use new system/manage change

3. Dev support plan (maintenance) - Analyst team est. support plan, usually includes formal/informal post-implementation reviews as well as systematic way to identify major/minor changes for system
System Development Methodology (Methodology)
- A formalised approach to implementing the SDLC (list of steps and deliverables)
- Many different ____________ available, some based on formal standards, some sold to clients, others are internal ___________ developed over years
- Process-Centred
- Data-Centred
- Object-Oriented
Different ways to categorise methodologies:

- ___________ emphasises process models as the core of the system concept (e.g. defining the processes first, such as assemble sandwich ingredients)
- ___________ emphasise data models at the core of the system concept (e.g. contents of the storage areas)
- ___________ attempt to balance the focus between process and data by incorporating both into one model (focus first on major elements of system, such as sandwiches/lunches and look at the processes/data involved with each element)
Categorising methodologies by the sequencing of the SDLC phases and the amount of time/effort devoted to each.
- Structured Design
- Rapid Application Development (RAD)
- Agile
Structured Design Methodologies
- - adopt a formal step-by-step approach to the SDLC that moves logically from one phase to the next. Dominant in the 1980s, replacing ad hoc dev. Two basic _________ design categories include:
- Waterfall development
- Parallel development
Waterfall Development
- the original structured design methodology
- Analysts and users proceed in sequence from one phase to the next
- Key deliverables from each phase are typically very long, and presented to the project sponsor for approval before moving to the next phase
- "Waterfall" because it moves forward, not backward
- Also introduces formal modelling/diagramming techniques to describe the basic business processes and the data that support them
Main Advantages and Disadvantages of Waterfall Development
- Main adv:
♣ Identifies system requirements long before programming begins
♣ Minimises changes to the requirements as the project proceeds

- Main disadv.:
♣ Design must be completely specified before programming begins (documentation overload)
♣ A long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system (usually many months or years)
• System may require significant rework because business environment changed
♣ If project team misses important requirements -> expensive post-implementation programming required
Parallel Development
- - Instead of doing design/implementation in sequence, it performs a general design for the whole system then divides the project into a series of distinct subprojects that can be designed/implemented in parallel.
- Attempts to address long delay problem between analysis phase and delivery of system
Main Advantages and Disadvantages of Parallel Development
- Primary adv - can ↓ time to deliver a system -> less chance for changes in business enviro

- Disadvantages:
♣ Subprojects not always independent
♣ Design decisions made in one subproject can affect another
♣ End of the project can require significant integration efforts
Rapid Application Development (RAD)

- Computer-aided software engineering (CASE) tools
- Joint application design (JAD) sessions
- 4G/visual programming languages
- Code generators

- Adv: ↑ speed and quality in development
- Disadv: user expectations must be managed and they tend to change dramatically with access to new tools
- - Attempt to address both weaknesses of Structured Design by adjust SDLC phases to get some part of the system developed quickly and into the hands of the users -> users can suggest revisions to bring system closer to what is needed
- Newer class of systems dev methodologies that emerged in the 1990s

- __________ methodologies recommend analysts use special techniques/tools to speed up analysis, design and implementation phases, such as:

- Main Advantages/Disadvantages?
Phased Development
- breaks an overall system into a series of versions that are developed sequentially.
- Analysis phase identifies overall system concept, and the project team, users, and system sponsor then categorise requirements into versions
♣ Most important and fundamental requirements bundled into the first version of the system
- Once v1 is implemented, work begins on v2. Additional analysis is performed based on the previously identified requirements and combined with new ideas and issues from user exp from v1. V2 is then designed and implemented
♣ This process continues until system is complete/no longer is use
Main Advantages and Disadvantages of Phased Development
- Adv:
♣ Quickly gets useful sytem into hands of users (may not perform all functions but does provide business value sooner)
♣ Because users begin work with system sooner, they are more likely to identify important additional requirements sooner

- Disadv:
Users begin to work with systems that are intentionally incomplete -> vital to identify/include most important/useful features and include them in v1
- - performs analysis, design, and implementation phases CONCURRENTLY, and all three phases are performed REPEATEDLY in a cycle until the system is complete.

- Basics of analysis/design are performed, work immediately begins on system __________ (quick-and-dirty program that provides a minimal amount of features)
- Feedback from sponsor -> used to reanalyse, redesign, and reimplement a 2nd __________ with more features
- Cycle continues until analysts, users, and sponsor agree __________ provides enough functionality to be installed
Advantages and Disadvantages of Prototyping
- Adv:
♣ Very quickly provides a system with which the users can interact, even if its not ready for widespread org use
♣ Reassures the users that the project team is working on the system (no long delays)
♣ Helps quickly refine real requirements

- Disadv:
♣ Fast-paced system releases challenge attempts to conduct careful, methodical analysis
♣ Prototype often undergoes such significant changes that many initial design decisions become poor ones
• Can be problem for complex systems because fundamental issues/problems are not recognised until well into dev process
Throwaway Prototyping
- - similar to prototyping methodologies BUT ______________ done at a different point in the SDLC and used for a very different purpose
- Relatively thorough analysis phase to gather info/dev ideas for system
- BUT users might not understand the features they suggest -> design prototype to represent the system and enable users to understand the issues under consideration
♣ Contains only just enough info for understanding
- Relies on several design prototypes during the analysis/design phases
♣ TP used to confirm issues are understood and then moved on
Advantages and Disadvantages of Throwaway Prototyping
- Adv:
♣ Well-thought-out analysis/design phases + refining key issues
♣ More stable/reliable systems
- Disadv:
♣ Cant ake longer to deliver final system compared to prototyping
Agile Development

working conditions
working software
changing requirements
rules and practices
- - based on the agile manifesto and a set of 12 principles
- Emphasis on the manifesto is to focus the developers on the _________ conditions of the developers, the working ________, the __________, and addressing _________ requirements (instead of focusing on detailed systems development processes, tools, all-inclusive _____________, legal contracts, and__________ plans.)
- Few _________ and __________, which are easy to follow
- Agile methodologies focusing on streamlining system-dev process by eliminating much of the ___________ overhead and the time spent on those tasks
- Projects emphasis simple, iterative application dev

- Two of the more population examples of __________ are:
- Extreme programming (XP)
- Scrum
Twelve principles of agile software are:
1. Software delivered early/continuously via dev process, satisfying customer
2. Changing requirements embraced regardless of when they occur
3. Working software delivered frequently to customer
4. Customers/Devs work together to solve business problems
5. Motivated individuals create solutions; provide them tools/enviro they need, trust to deliver
6. Face-to-face communication within dev teams most efficient/effective for requirements gathering
7. Primary measure of progress is working, executing software
8. Both customers/devs should work at a pace that is sustainable (no worker burnout)
9. Agility is heightened through attention to both tech excellence and good design
10. Simplicity (avoiding unnecessary work)
11. Self-organising teams dev the best architectures, requirements, and designs
12. Dev teams regularly reflect on how to improve their dev process
4 Agile manifesto values
1. Individuals and interactions over processes and tools - this doesn't mean throw processes/tools out the window, it just means a good face-to-face chat should trump rigid workflows and impersonal forms of communication

2. Working software over comprehensive documentation - traditional software development produced extensive documentation before a software was produced for testing. Some documentation is good, but wouldn't it be better to have the program rather than a book describing it?

3. Customer collaboration over contract negotiation - You want to start out with an initial guideline, but instead of locking customers in a cage by defining the exact details of the project before it starts, teams and contractors should work together to find the best solution

4. Responding to change over following a plan - nothing ever goes according to plan, so instead of sticking to something that isn't working, its must better to make adjustments as the situation changes
Positives and Criticisms of Agile Development
Criticisms of Agile:
- Today's business environment of offshoring, outsourcing and subcontracting -> co-location of dev team requirement unrealistic
- If not carefully managed (which by definition it isn't) dev can devolve into a prototyping approach that becomes "programmers gone wild"
- Lack of actual documentation -> issues of auditability of systems created
- Agile may not be suitable to deliver large mission-critical systems

Positives of Agile
- Potential to address application backlog and provide timely solutions to many business problems
- Many techniques/12 agile principles are very useful in OO systems dev
Extreme Programming
- Project begins with user stories that describe what the system needs to do
♣ Then, programmers code in small, simple modules and test to meet those needs
♣ Users required to be available to clear up Qs/issues
♣ Standards v important to minimise confusion, so teams use a common set of names, descriptions, and coding practices
♣ Deliver results sooner than even RAD approaches
4 core values of Extreme Programming
- founded on four core values: communication, simplicity, feedback, and courage. Provide a foundation that ______ devs use to create any system

♣ Communication - devs must provide rapid feedback to end users on a continuous basis
♣ Simplicity - devs must follow KISS (keep it stupid simple) principle
♣ Feedback - devs must make incremental changes to grow the system, and they must not only accept change, but embrace it
♣ Courage - devs must have a quality-first mentality

- _______ also supports team members to dev own skills.
- Three key principles that XP uses to create successful systems are:
♣ Continuous testing,
♣ Simple coding performed by pairs of devs, and
♣ Close interactions with end users to build systems very quickly

- Testing and efficient coding practices are the core of XP
♣ Code tested each day, any bugs -> code backed out until its free of errors
Advantages and Disadvantages of Extreme Programming
- Adv:
♣ Programmers work closely with all stakeholders, and communication among all stakeholders is ↑
♣ Continuous testing of evolving system is encouraged
♣ Incremental/evolutionary manner of dev -> requirements to evolve as stakeholders understand potential that tech has
♣ Estimation is task driven
♣ Programming in pairs -> shared responsibility for each software component
♣ Quality of final product ↑ with each iteration
♣ Excellent for small projects with highly motivated, cohesive, stable, and experienced teams

- Disadv:
♣ If project isn't small/teams aren't jelled -> doubtful success
♣ Above -> doubt of bringing outside contractors into an existing team environment using ________
♣ Requires a great deal of discipline otherwise projects become unfocused and chaotic
♣ No more than 10 devs, not advised for large, mission-critical apps
♣ Only code documentation associated with _________ (also means impossible for large systems)
♣ Methodoly needs a lot of on-site user input, which many business units cannot commit to
- - an agile framework that helps teams deliver customer value early and often in a highly predictable manner

- Based on idea that as soon as software is developed, chaos breaks out + plans out the window
- Works in 'sprints' that last 30 days.
♣ At end of sprint, system is delivered to customer



Scrum meeting


Scrum is the most chaotic approach. To control, scrum dev focuses on a few key practices:

♣ Teams are ____________ (no designated team leader)
• Teams set their own __________ for each sprint (iteration)
♣ Once a sprint has begun, scrum teams do not consider any additional _____________
• New ___________ put on backlog
♣ At beginning of each day, __________ takes place
♣ At end of each sprint, the team demos the ___________ to the client
♣ Based on result of sprint, new ________ is begun for next sprint
Scrum Meetings
- Scrum meetings: daily, anyone can attend, only team members (and possibly mgmt.) can speak
♣ All team members stand in a circle and report on what they did the previous day, what they'll do today and describe anything that blocked progress (which is dealt with within an hour)
♣ Better to make a "bad decision about a block than not make a decision (daily meetings mean bad decisions can be undone)
Elements/Scrum roles involved in Scrum
♣ Stakeholders (Also known as involved group)
♣ Product Owner
♣ Scrum Master
♣ The Team
♣ Product backlog -
♣ Committed team - product owner, scrum master, and the team because they need the project completed
Elements/Scrum roles involved in Scrum: Product Owner
Product Owner - responsible for maximising the business value delivered by the team
• ONE person responsible for the backlog and story priority (anymore and it becomes chaos)
• Accepts or rejects work
• Helps define 'done'
• Knowledgeable (of requirements), empowered (to make decisions), engaged (in the project)!
• Motivates the team, celebrates success!
Elements/Scrum roles involved in Scrum: Scrum Master
Scrum Master - Responsible for facilitating the Scrum process and ensuring the team is delivering value
• Helps build self-organising teams
• Removes impediments
• Keeps the process healthy (helping entire team know process, process/rules followed, product owner engaged, etc.)
• Empowers the team - Servant Leader (don't control, let them get the work done)
Elements/Scrum roles involved in Scrum: The Team
The Team - Responsible for turning the product backlog items into increments of value each sprint
• Cross-functional (not just developers, different roles), 7 (+-2)members
• Self-organising (they know what tasks are set), collaborative
• Committed (to tasks)
• Generalising specialists (moving away from specialised roles, individuals sign up to complete whatever is required to finish the teams goal)
• Deliver value in small chunks
• Focused on Customer, building in quality
Criticisms of Scrum
♣ Questionable whether _______ can scale up to dev very large, mission-critical systems
♣ No more than 7 members
♣ Note: to deal with this -> ________ of ________ - after daily meeting, a representative of each team attends a ________ of ________ meeting (repeated until system complete)
Criteria for Selecting Appropriate Development Methodology
Ability to develop Systems based on:
- Clarity of User Requirements
- Familiarity with Technology
- System Complexity
- System Reliability
- Short Time Schedules
- Schedule Visitbility
Traditional vs Agile Software Development: Areas of Difference

- Core Assumptions
- Control
- Management Style
- Knowledge Management
- Role Assignment
- Communication
- Customer's Role
- Product Lifecycle
- Development Model
- Desired Organisational Form/Structure
- (fully specificable/predictable/meticulous/extensive planning vs adaptive/continuous improvement/testing/rapid evaluation)
- (Process centric vs People centric)
- (Command-and-control vs Leadership-and-collaboration)
- (Explictly documented vs tacit/implied)
- (Individual, specialisation vs self-organising, interchangeability)
- (Formal vs Informal)
- (Important vs Critical)
- (Guided by tasks/activities vs functionalities/features)
- (Lifecycle vs evolutionary model)
Systems Analyst: roles
- Identify how technology can improve business processes
- Must both understand and design new business processes
- Design the information system to add value
- Ensuring that the information system conforms to information systems standards
- Requires specific skill sets
- Biggest task is to implement the new system
- After implementation, they prepare the new users via training/writing manual
- Agents of change - identify ways to improve the organisation, build IS to support them, motivate and train others
Systems Analyst: Skills needs
- Skills needs (can be technical but also managerial, creative):
1. Technical - must understand the technology/how to fit in existing org tech environment
2. Business - must know the business processes, how IT is applied to business situations/delivers real value
3. Analytical - must be able to solve problems
4. Communications - technical and non-technical audiences
5. Interpersonal - leadership and management
6. Ethics - deal fairly and protect confidential information
Business Analyst
- Analyses key business impacts of system
- Identifies how the system will provide business value
- Designing new business procedures and policies
Infrastructure Analyst
- Ensures the IS conforms to infrastructure standards
- Identifies infrastructure changes needed to support the system
Change Management Analyst
- Developing and executing a change management plan
- Developing and testing a user training plan
Project Manager
- Managing the team of analysts, programmers, technical writers, and other specialists
- Developing and monitoring the project plan
- Assigning resources
Integrity and ethics
- Sense of personal integrity and ethics essential
- Analysts often encounter personal information
- Analysts encounter confidential proprietary information
- Keep confidential and sensitive information private
- Improprieties (failure to observe standards of honesty) can ruin an analyst's career
- Personality
- data or processes
- logical units
- user and an analyst or developer
Users typically do not think in terms of ______ or ______; instead, they see their business as a collection of _______ that contain both - so communicating in terms of ______ improves the interaction between a ________ and an ________ or ________
Object Oriented Systems Analysis and Design (OOSAD)
- A popular technical approach for analysing, designing an application, system or business, by applying the OO paradigm and visual modelling throughout the SDLC to foster better stakeholder communication and product quality
- Attempts to balance data and process.
- Utilises the Unified Modeling Language (UML) and the Unified Process.
- Most associated with a phased dev RAD or agile methodology
- Main difference with traditional approach - decompose a problem with objects (with data/processes) vs. process-centric or data-centric
Characteristics of any modern OO approach
- Use Case Driven
- Architecture-Centric
- Iterative and Incremental
Use Case Driven
- use cases are the primary modelling tools defining the behaviour of the system
Use Case
- description of how user interacts with system to perform some activity.
- - underlying software _________ of evolving system specification drives the specification, construction and documentation of the system
♣ i.e. first the devs decide on the framework and then system is built around and upon it. ______________ is enabler/constraint on system dev
♣ Importance because -> dev team iterative w/o undermining stability of system core
• If _________ was modified -> support for some (or most) sys components compromised
- 3 separate but interrelated architectural views of a system
• ____________ (external) - describes behaviour of the system from the perspective of the user
• ___________ (static) - describes system in terms of attributes, methods, classes and relationships
• ___________ (dynamic) - describes behaviour of sys in terms of messages passed among objects and state changes within an object
Iterative and Incremental
- - the system will undergo continuous testing and refinement throughout life of the project
♣ Sys analysts dev their understanding of a user's problem by building up three architectural views little by little (changes in one model effect other models)
♣ Need a definition of 'done', anything else will have to be thrown into next iteration if not complete
smaller, more manageable modules

grasp, share among team members, communicate to users

Benefits of OOSAD:

- Enable analysts to break a complex system into __________, more manageable __________, work on ___________ individually, and piece ___________ back together to form IS
- Modularity -> easier to ________, ________ among team members, __________ to users
- Creates __________ pieces that can be plugged into other systems -> save time
Unified Process
- Framework for assigning tasks and responsibilities
- Its goals is to ensure the production of high quality software that meets the needs of its end users
- Divides the SDLC into 5 phases
- A two-dimensional process consisting of phases and workflows (Activities in both phases and workflows will overlap)
- A specific methodology that maps out when and how to use various UML techniques for OO analysis and design
Unified Process divides the SDLC into 5 phases
1. Inception - Is the project financially viable?
2. Elaboration - project starts to take shape
3. Construction - design model, test plan, support documentation
4. Transition - beta testing/training, feedback
5. Production - monitored, support, requests for change
Phases - time periods in development
- Describe how IS evolves through time.
- In each phase, you perform the standard software activities (business modelling, etc.) but to different extents based on what phase you are in
- Each phase contains a set of iterations
- Each iteration uses various workflows to create an incremental version of the evolving activity
- _________ the tasks or activities that occur in each phase that a dev performs to evolve an IS over time
o Engineering _______ - activities that produce the technical product (i.e. the IS)
o Supporting _______ - activities that focus on managerial aspects of IS dev