Introduction to Systems

Analysis & Design

ITOOA3-B11
Objectives
• Be familiar with the different roles played by and the skills
of a systems analyst.
• Understand the fundamental systems development life cycle
and its four phases.
• Understand the evolution of systems development
methodologies.
• Be familiar with the fundamental principles of
object‐oriented systems analysis and design.
• Be familiar with the Unified Process, its extensions, and the
Unified Modelling Language.

2
Introduction
• The systems development life cycle (SDLC) is the process of
understanding how an information system (IS) can support
business needs by designing a system, building it, and
delivering it to users.

3
Introduction
• The key person in the SDLC is the systems analyst, who
analyses the business situation, identifies opportunities for
improvements, and designs an information system to
implement them.
• The primary objective of a systems analyst is not to create
a wonderful system; instead, it is to create value for the
organization, which for most companies means increasing
profits (government agencies and not-for-profit
organizations measure value differently).

4
The Systems Development Life Cycle
• In many ways, building an information system is similar to
building a house.
• There are four fundamental phases: planning, analysis,
design, and implementation.
• The SDLC is a process of gradual refinement.

5
The Systems Development Life Cycle
Planning
A process of understanding why an information system should be
built and determining how the project team will go about building
it. It has two steps:
1. During project initiation
The system’s business value to the organization is identified, in
the form of a system request.
A feasibility analysis will be conducted.
Presented to an information systems approval committee
(sometimes called a steering committee), which decides
whether the project should be undertaken.

6
The Systems Development Life Cycle
2. Project Management
The deliverable for project management is a project plan, which
describes how the project team will go about developing the
system.

7
The Systems Development Life Cycle
Analysis
This phase focuses on of who will use the system, what the system
will do, and where and when it will be used. It has three steps:
1. Analysis strategy
Such a strategy usually includes an analysis of the current system
(called the as-is system) and its problems and then ways to
design a new system (called the to-be system).
2. Requirements gathering
E.g. through interviews or questionnaires
Input from the project sponsor and many other people—leads
to the development of a concept for a new system.
The system concept is then used as a basis to develop a set of
business analysis models.

8
The Systems Development Life Cycle
3. System proposal
The analyses, system concept, and models are combined into a
document called the system proposal, which is presented to the
project sponsor and other key decision makers (e.g., members
of the approval committee) who decide whether the project
should continue to move forward.

9
The Systems Development Life Cycle
Design
Determine exactly how the system will operate. It has four steps:
1. Design strategy - developed by the company’s own
programmers, outsourced or buy an existing software package.

10
The Systems Development Life Cycle
2. Architecture design - hardware, software and network
infrastructure. Interface design.
3. Database and file specifications - what data will be stored and
where they will be stored.
4. Program design - programs that need to be written and exactly
what each program will do.

* A feasibility analysis and project plan are re-examined and revised. Another
decision is made by the project sponsor and approval committee about whether
to terminate the project or continue.

11
The Systems Development Life Cycle
Implementation
In this final phase the system is actually built (or purchased). It has
three steps:
1. Construction
Built and test. The cost of bugs can be immense, testing is one
of the most critical steps in implementation.
2. Installed
Installation - old system is turned off and the new one is turned
on.
Training plan - teach users how to use the new system and help
manage the changes caused by the new system.

12
The Systems Development Life Cycle
3. Support plan
Formal or informal post-implementation review.
Identifying major and minor changes needed for the system.

13
Systems Development Methodologies
• A methodology is a formalized approach to implementing
the SDLC (i.e., it is a list of steps and deliverables). There are
many different systems development methodologies, and
each one is unique, based on the order and focus it places
on each SDLC phase.

14
Systems Development Methodologies
There are many ways to categorize methodologies.
• A process-centered methodology emphasizes process
models as the core of the system concept.
• Data-centered methodologies emphasize data models as
the core of the system concept.
• Object-oriented methodologies attempt to balance the
focus between process and data by incorporating both into
one model.

• Another important factor in categorizing methodologies is

15
Systems Development Methodologies
• We will have a look at three different classes of system
development methodologies: structured design, rapid
application development and agile development.

16
Structured design
1. Waterfall development

17
• The two key advantages of the structured design waterfall
approach are that it identifies system requirements long before
programming begins and it minimizes changes to the
requirements as the project proceeds.
• The two key disadvantages are that the design must be
completely specified before programming begins and that 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)

18
2. Parallel Development

19
• The primary advantage of this methodology is that it can reduce
the time to deliver a system; thus, there is less chance of changes
in the business environment causing rework.
• However, sometimes the subprojects are not completely
independent; design decisions made in one subproject can affect
another, and the end of the project can require significant
integration efforts.

20
Rapid Application Development (RAD)
• RAD-based methodologies attempt to address both weaknesses
of structured design methodologies by adjusting the SDLC phases
to get some part of the system developed quickly and into the
hands of the users.
• Most RAD-based methodologies recommend that analysts use
special techniques and computer tools to speed up the analysis,
design, and implementation phases, such as computer-aided soft
ware engineering (CASE) tools, joint application design (JAD)
sessions, fourth-generation or visual programming languages that
simplify and speed up programming, and code generators that
automatically produce programs from design specifications.
• There is one possible subtle problem with RAD-based
methodologies: managing user expectations. Owing to the use of
the tools and techniques that can improve the speed and quality
of systems development, user expectations of what is possible can
change dramatically. As a user better understands the
information technology (IT), the systems requirements tend to
expand.
21
Rapid Application Development (RAD)
1. Phased Development
• Breaks an overall system into a series of versions that are
developed sequentially.

22
23
• Phased development-based methodologies have the advantage
of quickly getting a useful system into the hands of the users.
Users begin to work with the system sooner, they are more likely
to identify important additional requirements sooner than with
structured design situations.
• The major drawback to phased development is that users begin
to work with systems that are intentionally incomplete.

24
Rapid Application Development (RAD)
2. Prototyping
• Performs the analysis, design, and implementation phases
concurrently, and all three phases are performed repeatedly in a
cycle until the system is completed.

25
• The key advantage of a prototyping-based methodology is that it
very quickly provides a system with which the users can interact,
even if it is not ready for widespread organizational use at first.
Prototyping reassures the users that the project team is working
on the system (there are no long delays in which the users see
little progress), and prototyping helps to more quickly refine real
requirements.
• The major problem with prototyping is that its fast-paced system
releases challenge attempts to conduct careful, methodical
analysis.

26
Rapid Application Development (RAD)
3. Throwaway Prototyping
• Throwaway prototyping-based methodologies are similar to
prototyping-based methodologies in that they include the
development of prototypes; however, throwaway prototypes are
done at a different point in the SDLC. These prototypes are used
for a very different purpose than those previously discussed, and
they have a very different appearance.

27
• Balance the benefits of well-thought-out analysis and design phases
with the advantages of using prototypes to refine key issues before a
system is built.
• It can take longer to deliver the final system as compared to
prototyping-based methodologies, but this type of methodology
usually produces more stable and reliable systems.

28
Agile Development
• All agile development methodologies are based on the agile
manifesto and a set of twelve principles.

29
These principles include the following:
1. Software is delivered early and continuously through the development
process, satisfying the customer.
2. Changing requirements are embraced regardless of when they occur in the
development process.
3. Working software is delivered frequently to the customer.
4. Customers and developers work together to solve the business problem.
5. Motivated individuals create solutions; provide them the tools and
environment they need, and trust them to deliver.
6. Face-to-face communication within the development team is the most
efficient and effective method of gathering requirements.
7. The primary measure of progress is working, executing software.
8. Both customers and developers should work at a pace that is sustainable.
That is, the level of work could be maintained indefinitely without any
worker burnout.
9. Agility is heightened through attention to both technical excellence and
good design.
10. Simplicity, the avoidance of unnecessary work, is essential.
11. Self-organizing teams develop the best architectures, requirements, and
designs.
12. Development teams regularly reflect on how to improve their development
processes.
30
31
Criticisms
1. Business environment
2. Not carefully managed
3. Auditability
4. Large mission-critical systems

32
• Agile approaches should be considered in some circumstances.
• Two of the more popular examples of agile development
methodologies are extreme programming (XP) and Scrum.

33
Agile Development
1. Extreme Programming
• Founded on four core values: communication, simplicity,
feedback, and courage. These four values provide a foundation
that XP developers use to create any system.
• First, the developers must provide rapid feedback to the end
users on a continuous basis.
• Second, XP requires developers to follow the KISS principle.
• Third, developers must make incremental changes to grow
the system, and they must not only accept change, they must
embrace change.
• Fourth, developers must have a quality-first mentality.
• XP also supports team members in developing their own skills.
• Three of the key principles that XP uses to create successful
systems are continuous testing, simple coding performed by pairs
of developers, and close interactions with end users to build
systems very quickly.

34
• Testing and efficient coding practices are the core of XP. Code is
tested each day and is placed into an integrative testing
environment. If bugs exist, the code is backed out until it is
completely free of errors.
• For small projects with highly motivated, cohesive, stable, and
experienced teams, XP should work just fine. However, if the project
is not small or the teams aren’t jelled, the success of an XP
development effort is doubtful.
• XP requires a great deal of discipline, otherwise projects will become
unfocused and chaotic. XP is recommended only for small groups of
developers—no more than ten developers—and it is not advised for
large mission-critical applications.
• Finally, the methodology needs a lot of on-site user input, something
to which many business units cannot commit.

35
Agile Development
2. Scrum

Source: https://www.scrum.org/resources/what-is-scrum

36
Source: https://www.scrum.org/resources/what-is-scrum

37
DevOps
• Another category of systems development methodologies is
DevOps.
• It incorporate ideas from both object-oriented approaches to
systems development and lean manufacturing into the agile
approaches.
• Two of the more popular approaches are DAD and SAFe.
• Include operations personnel as members of the development team.
In this way, non-functional requirements, such as security, can be
addressed during the design of the system to be deployed.
• Deployment is completed when a new chunk of software has
passed a set of relevant tests.
• The new version is deployed in pieces over time; this is also
referred to as a rolling upgrade.

38
Custom Methodologies
• This last category of systems development methodologies supports the
idea of applying both agile and object-oriented ideas to the systems
development methodology itself. The idea behind these approaches is
to support the development team in a way that is customized to their
specific systems development project.
• In this case, only a high-level framework is used to create the project-
specific method. Two of the approaches that have made progress in this
area are based on the work of Brian Henderson-Sellers and of Ivar
Jacobson. Both of these groups allow the team to pick and choose
different components of a methodology from a component repository
to create a custom methodology.
• Care must be taken to ensure that each component is plug compatible.
By that we mean the inputs into a component are compatible with the
outputs of the preceding component in the methodology.

39
Systems Analyst Roles and Skills
• Project members are change agents who identify ways to improve an
organization, build an information system to support them, and train
and motivate others to use the system.
• Understanding what to change and how to change it—and
convincing others of the need for change—requires a wide range of
skills. These skills can be broken down into six major categories:
technical, business, analytical, interpersonal, management, and
ethical.
• Some small organizations still expect one person to perform many
roles, but because organizations and technology have become more
complex, most large organizations now build project teams
containing several individuals with clearly defined responsibilities.
• Business Analyst
• Systems Analyst
• Infrastructure Analyst
• Change Management Analyst
• Project Manager 40
Systems Analyst Roles and Skills
• Business Analyst
• Systems Analyst
• Infrastructure Analyst
• Change Management Analyst
• Project Manager

41
Object-Oriented Systems Analysis & Design (OOSAD)
• Object-oriented approaches to developing information systems,
technically speaking, can use any of the traditional
methodologies. However, the object-oriented approaches are
most associated with a phased development RAD or agile
methodology.
• Attempt to balance the emphasis between process and data.
• Any modern object-oriented approach to developing information
systems must be use-case driven, architecture-centric, and
iterative and incremental.

42
Object-Oriented Systems Analysis & Design (OOSAD)
Use-Case Driven
• Use-case driven means that use cases are the primary modelling
tools defining the behaviour of the system.
• Describes how the user interacts with the system to perform some
activity.
• Identify and to communicate the requirements.
• Simple.

43
Object-Oriented Systems Analysis & Design (OOSAD)
Architecture-Centric
• Architecture-centric means that the underlying software
architecture of the evolving system specification drives the
specification, construction, and documentation of the system.
• Modern object-oriented systems analysis and design approaches
should support at least three separate but interrelated
architectural views of a system: functional, static, and dynamic.
• The functional, or external, view describes the behaviour of the
system from the perspective of the user.
• The structural, or static, view describes the system in terms of
attributes, methods, classes, and relationships.
• The behavioural, or dynamic, view describes the behaviour of the
system in terms of messages passed among objects and state
changes within an object.

44
Object-Oriented Systems Analysis & Design (OOSAD)
Iterative and Incremental
• There is continuous testing and refinement throughout the life of
the project.
• This implies that the systems analysts develop their understanding
of a user’s problem by building up the three architectural views
little by little. The systems analyst does this by working with the
user to create a functional representation of the system under
study.
• Next, the analyst attempts to build a structural representation of
the evolving system.
• Using the structural representation of the system, the analyst
distributes the functionality of the system over the evolving
structure to create a behavioural representation of the evolving
system.

45
Object-Oriented Systems Analysis & Design (OOSAD)

46
Object-Oriented Systems Analysis & Design (OOSAD)
Benefits of Object-Oriented Systems Analysis and Design
• Break a complex system into smaller, more-manageable modules,
work on the modules individually, and easily piece the modules back
together to form an information system.
• Easier to grasp, easier to share among members of a project team,
and easier to communicate to users.
• Creating reusable pieces.
• Save time.

47
Object-Oriented Systems Analysis & Design (OOSAD)
Factors which led to the emergency of Object-Orientation
Bennet et al. (2010: 106) discusses the origins of Object-Orientation
and identifies the following important factors which led to the
development of Object-Orientation:

• Increasing abstraction

• Event-driven programming

48
Object-Oriented Systems Analysis & Design (OOSAD)

• The spread of GUIs

• Modular software

• Lifecycle problems

49
Object-Oriented Systems Analysis & Design (OOSAD)

• Model transitions

• Reusable software

50
The Unified Process
• The Unified Process is a specific methodology that maps out
when and how to use the various Unified Modelling
Language (UML) techniques for object-oriented analysis and
design.
• The Unified Process is a two-dimensional systems
development process described by a set of phases and
workflows. The phases are inception, elaboration,
construction, and transition. The workflows include business
modelling, requirements, analysis, design, implementation,
test, deployment, configuration and change management,
project management, and environment.

51
52
53
The Unified Modelling Language (UML)
• Grady Booch, Ivar Jacobson, and James Rumbaugh worked with
others to create a standard set of diagramming techniques known
as the Unified Modelling Language (UML).
• The objective of UML was to provide a common vocabulary of
object-oriented terms and diagramming techniques rich enough to
model any systems development project from analysis through
implementation.
• Version 2.5 of the UML defines a set of fifteen diagramming
techniques used to model a system. The diagrams are broken into
two major groupings: one for modelling the structure of a system
and one for modelling behaviour.

54
55
56
Exercise
Exercise C on page 30
Look on the Web for different kinds of job opportunities that
are available for people who want analyst positions? Compare
and contrast the skills that the ads ask for to the skills that we
presented in this chapter.

57