Introduction to SDLC &

System Analyst Roles

Topic 1
 Project Analysis

Agile Approach Intro to SDLC & System Analyst Roles

Object-Oriented Analysis and Design OUTLINE Phases of SDLC

Structured Analysis & Design System Development Methodology

Introduction to SDLC
and System Analyst
Roles
 Need for System
Analysis and Design

• Many failed systems were abandoned because analysts tried to build

wonderful systems without understanding the organization.
• Installing a system without proper planning leads to great user
dissatisfaction and frequently causes the system to fall into disuse

•The primarily goal is to create value for the organization.

 Need for System
Analysis and Design

• A series of processes systematically undertaken to improve a business

through the use of computerized information systems
• The systems analyst is a key person analyzing the business, identifying
opportunities for improvement, and designing information systems to
implement these ideas.
 System Development
Life Cycle (SDLC)

• SDLC is the process of understanding how an information system (IS) can

support business needs, designing the system, building it, and delivering
it to the users.
• The lifecycle moves systematically through phases where each phase has
a standard set of techniques and activities
• Produces deliverables/output at each phases
• Final results is actual information system
• Managed through a project
• SDLC is a process gradual refinement
• Each phase refines and elaborates on the work done previously
• Deliverable from analysis phase become input and can be refined in design phase

6
 Roles of the
System Analyst

• The analyst must be able to work with people of all descriptions and
be experienced in working with computers
• Three primary roles:
• Consultant
• Give a new perspective
• Supporting expert
• Understand technologies used for business
• Agent of change
• Develop, advocate, and facilitate change in organization

7
 Qualities of the
System Analyst

• Problem solver
• Communicator
• Strong personal and professional ethics
• Self-disciplined and self-motivated

8
 System Analyst
Knowledge, Skill, and
Education
• Technical Knowledge
• State-of-the-art knowledge is extremely important in a rapidly changing business and technical
environment
• Communication skills
• A systems analyst needs strong oral and written communication skills and the ability to interact with
people at all levels, from operational staff to senior executives
• Business skills
• A system analyst must understand business operations and processes, communicate clearly, and translate
business needs into requirements that can be understood by programmers and systems developers
• Critical Thinking skills
• include the ability to compare, classify, evaluate, recognize patterns, analyze cause and effect, and apply
logic
• Education
• Companies typically require systems analysts to have a college degree in information systems, computer
science, or business, and some IT experience usually is required.

9
Phases of SDLC
7-Phases of SDLC

Considering HCI in
each phases

Kendall & Kendall (2020)

 1. Identifying Problems,
Opportunities, and
Objectives

• Activities:
• Interviewing user management
• Summarizing the knowledge obtained
• Estimating the scope of the project
• Documenting the results
• Output:
• Feasibility report containing problem definition and objective summaries
from which management can make a decision on whether to proceed with
the proposed project

12
 2. Determining Human
Information
Requirements

• Activities:
• Interviewing
• Sampling and investing hard data
• Questionnaires
• Observe the decision maker’s behavior and environment
• Prototyping
• Learn the who, what, where, when, how, and why of the current system
• Outputs:
• Know the business functions
• The analyst understands how users accomplish their work when interacting with a
computer and how to make the new system more useful and usable (Functional & Non
Functional Requirement)
• Have complete information on the:
• People, Goals, Data, Process (Procedure) involved

13
 3. Analyzing System
Needs

• Activities:
• Create data flow, activity, or sequence diagrams
• Complete the data dictionary
• Analyze the structured decisions made
• Prepare and present the system proposal
• Output:
• Data and process model for ‘as-is’ system
• System Proposal containing recommendation on what, if anything, should be
done (model for ‘to-be system’)

14
 4. Designing the
Recommended System

• Activities:
• Design procedures for data entry
• Design the human-computer interface
• Design system controls
• Design database and/or files
• Design backup procedures
• Output:
• Database, program, and interface design
• System specification (hardware and software)

15
 5. Developing and
Documenting Software

• Activities:
• System analyst works with programmers to develop any original software
• Works with users to develop effective documentation
• Programmers design, code, and remove syntactical errors from computer
programs
• Document software with help files, procedure manuals, and Web sites with
Frequently Asked Questions
• Output:
• Computer programs
• System documentation

16
 6. Testing and
Maintaining the System

• Activities:
• Test the information system
• System maintenance
• Maintenance documentation
• Output:
• Problems, if any
• Updated programs
• Documentation

17
 7. Implementing and
Evaluating the System

• Activity:
• Train users
• Analyst plans smooth conversion from old system to new system
• Review and evaluate system
• Output:
• Trained personnel
• Installed system

18
 System
Development
Methodologies
 What is a
methodology?

• A methodology is a formalized approach or series of steps to

implementing the SDLC.
• The methodology will vary depending on whether the emphasis
is on businesses processes or on the data that supports the
business.
• Process-centered (system concept as a set of process with information
flowing into and out of the process)
• Data centered (system concept as data models)
• Object-oriented (balance emphasis on data and proses)

Writing code without a well-thought-out system request may work

for small programs, but rarely works for large ones.
20
 System Development
Methodology Category

Tilley (2020)
21
Choosing Which
Method to Use

Kendall & Kendall (2020)

22
Structure Analysis &
Design
 Structured Analysis &
Design

• Structured analysis is a traditional systems development technique that is time

tested and easy to understand.
• Structured analysis uses a series of phases, called the systems development life
cycle (SDLC), to plan, analyze, design, implement, and support an information
system. A step is finished before the next one begins.
• Structured analysis uses a set of process models to describe a system graphically.
• Structured analysis is called a process-centered technique. In addition to
modeling the processes, structured analysis also addresses data organization and
structure, relational database design, and user interface issues.
• A process model shows the data that flows in and out of system processes. Inside
each process, input data is transformed by business rules that generate the
output. The model is a called a data flow diagram (DFD) because it uses various
symbols and shapes to represent data flow, processing, and storage
24
Process Model using DFD
 Waterfall Model
• In the waterfall model, the result of each phase is called a
deliverable, which flows into the next phase. It also known
as SDLC model or traditional model.
• It usually includes five steps:
• systems planning: usually begins with a systems request, which
describes problems or desired changes in an information system
or a business process. A key part deliverable is a feasibility study
that reviews anticipated costs and benefits and recommends a
course of action based on operational, technical, economic, and
time factors.
• systems analysis: the purpose is to build logical model of new
system. The deliverable is the system requirements document
that describe management and user requirements, costs, and
benefits and outlines alternative development strategies.
• systems design: the purpose is to create a physical model that will
satisfy all documented requirements for the system. The
deliverable for this phase is the system design specification, which
is presented to management and users for review and approval
• systems implementation: the new system is constructed. This
phase include systems evaluation to determine whether the
system operates properly and if costs and benefit are within
expectations.
• systems support and security: the IT staff maintains, enhances,
and protects the system. A well-designed system must be secure,
reliable, maintainable, and scalable. 26
 When to Use SDLC
(Structured Design)

• Systems have been developed and documented using SLDC

• It is important to document each step
• Upper level management feels more comfortable or safe using
SDLC
• There are adequate resources and time to complete the full SDLC
• Communication of how new systems work is important

27
Object-Oriented
Analysis & Design
 Object-oriented
approach

• Object-oriented (O-O) systems analysis and design is an

approach intended to facilitate the development of
systems that must change rapidly in response to dynamic
business environments.
• Object-oriented approaches use the industry standard for
modeling O-O systems, called unified modeling
language (UML), to break down a system into a use case
model.
• Each object is a computer representation of some actual
thing or event. Objects may be customers, items, orders,
and so on. Objects are represented by and grouped into
classes that are optimal for reuse and maintainability. A
class defines the set of shared attributes and behaviors
found in each object in the class.
29
 Object-Oriented
Development Model

• Object-oriented methodologies often focus on

small, quick iterations of development,
sometimes called the spiral model.
• Analysis is performed on a small part of the
system, usually starting with a high-priority
item or perhaps the item that has the greatest
risk. This is followed by design and
implementation.
• The cycle is repeated with analysis of the next
part, design, and some implementation, and
this is repeated until the project is complete
 Object-Oriented
Development Phases
1. DEFINE THE USE CASE MODEL. In this phase, the analyst identifies the actors and the major events
2. initiated by the actors. This is called a use case diagram, and it represents the standard flow of events in the system.
Then an analyst typically writes up a use case scenario, which describes in words the steps that are normally
performed.
3. DURING THE SYSTEMS ANALYSIS PHASE, BEGIN DRAWING UML DIAGRAMS. In the second phase, the analyst draws
activity diagrams, which illustrate all the major activities in the use case. In addition, the analyst creates one or more
sequence diagrams for each use case that show the sequence of activities and their timing. This is an opportunity to go
back and review the use cases, rethink them, and modify them if necessary.
4. CONTINUING IN THE ANALYSIS PHASE, DEVELOP CLASS DIAGRAMS. The nouns in the use cases are objects that can
potentially be grouped into classes. For example, every automobile is an object that shares characteristics with other
automobiles. Together they make up a class.
5. STILL IN THE ANALYSIS PHASE, DRAW STATECHART DIAGRAMS The class diagrams are used to draw statechart
diagrams, which help in understanding complex processes that cannot be fully derived by the sequence diagrams.
6. BEGIN SYSTEMS DESIGN BY MODIFYING THE UML DIAGRAMS THEN COMPLETE THE SPECIFICATIONS Systems
design means modifying the existing system, and that implies modifying the diagrams drawn in the previous phase.
An analyst will need to write class specifications for each class, including the attributes, methods, and their
descriptions.
7. DEVELOP AND DOCUMENT THE SYSTEM. Documentation is critical. The more complete the information you provide
to the development team through documentation and UML diagrams is, the faster the development and the more solid
the final production system.
Agile Method
 Agile Approach

• The agile approach is a software development

approach based on values, principles, and core
practices.
• The four values are communication, simplicity,
feedback, and courage.
• A agile methods can ensure successful completion
of a project by adjusting the important resources of
time, cost, quality, and scope.
• An agile method, called Scrum, is a typical sprint
cycle will last between two and four weeks. At the
end of that period, the team is expected to produce
a potentially releasable product.
• Two words that characterize a project done with an
agile approach are interactive and incremental.
33
 Agile Modelling
development process
• Exploration
• During exploration, you explore your environment, asserting your conviction that the problem can and should be approached with agile
development, assemble the team, and assess team member skills
• Customers also are experimenting with writing user stories, to get the customer to refine a story enough so that you can competently
estimate the amount of time it will take to build the solution into the system you are planning
• Planning
• The entire agile planning process has been characterized using the idea of a planning game. Story cards become the pieces in the
planning game that briefly describe the task, provide notes, and provide an area for task tracking.
• Customers decide what the development team should tackle first. Their decisions will set priorities and check functionalities throughout
the process
• Iteration to the First Release
• Typically these iterations (cycles of testing, feedback, and change) are about three weeks in duration.
• One goal is to run customer-written function tests at the end of each iteration.
• Productionizing
• Several activities occur during the productionizing phase. In this phase the feedback cycle speeds up so that rather than receiving
feedback for an iteration every three weeks, software revisions are being turned around in one week.
• The product is released in this phase, but it may be improved by adding other features.
• Maintenance
• New features may be added, riskier customer suggestions may be considered, and team members may be rotated on or off the team

34
 When to use agile

• There is a project champion of agile methods in the

organization
• Applications need to be developed quickly in response to a
dynamic environment
• A rescue takes place (the system failed and there is no time to
figure out what went wrong)
• The customer is satisfied with incremental improvements
• Executives and analysts agree with the principles of agile
methodologies

35