content analysis
reflection journal on System analysis. i have also attached a sample and week slides.(3000 words)
Table of Contents
Introduction
2
Background
2
Content analysis:
2
Week 1: Systems Analysis introduction
2
Theoretical Discussion
2
Interpretations of the contents
Interpretations of the contents
2
Outcome 2
Week 2: model design
2
Theoretical Discussion 2
Interpretations of the contents 2
Outcome 2
Week 3: database design
2
Theoretical Discussion 3
Interpretations of the contents 3
Outcome 3
Conclusion (50 words)
3
Introduction
Talk about why you are creating this document
Background
Your subject that you are learning
Content analysis:
Week 1: Systems Analysis introduction
Theoretical Discussion
0. Important topics covered – objectives
0. Definitions – definition of Systems Analysis and design
Interpretations of the contents
0. What are the most important/useful/relevant information about the content?
Systems analysis and design, Systems Analysis role, design tools, Computer Aided Design
Outcome
Outcome
0. What have I learned from this?
This topic has given me the idea about systems analysis and design
Week 2: model design
Theoretical Discussion
0. Important topics covered – objectives
0. Definitions – definition of Systems Analysis and design
Interpretations of the contents
0. What are the most important/useful/relevant information about the content?
Systems analysis and design, Systems Analysis role, design tools, Computer Aided Design
Outcome
0. What have I learned from this?
This topic has given me the idea about model design
Week 3: database design
Theoretical Discussion
0. Important topics covered – objectives
0. Definitions – definition of Systems Analysis and design
Interpretations of the contents
0. What are the most important/useful/relevant information about the content?
Systems analysis and design, Systems Analysis role, design tools, Computer Aided Design
Outcome
0. What have I learned from this?
This topic has given me the idea about systems analysis and design
Conclusion (50 words)
Nirmal Reflective Journal Page | 1
Assumptions
Under lying Agile Softwar e Development
Pr ocesses
Abstract
Agile processes focus on facilitating early and fast production of working code,
and are based on software development process models that support iterative,
incremental development of software. Although agile methods have existed for a
number of years now, answers to questions concerning the suitability of agile
processes to particular software development environments are still often based
on anecdotal accounts of experiences. An appreciation of the (often unstated)
assumptions underlying agile processes can lead to a better understanding of the
applicability of agile processes to particular situations. Agile processes are less
likely to be applicable in situations in which core assumptions do not hold. This
paper examines the principles and advocated practices of agile processes to
identify underlying assumptions. The paper also identifies limitations that may
arise from these assumptions and outlines how the limitations can be addresses by
incorporating other software development techniques and practices into agile
development environments.
1. Introduction
As more organizations seek to gain competitive advantage through timely deployment of
services and products that meet and exceed customer needs and expectations, developers are
under increasing pressure to develop new or enhanced implementations quickly [15]. Agile
software development processes were developed primarily to support timely and economical
development of high-quality software that meets customer needs at the time of delivery. It is
claimed by agile process advocates that this can be accomplished by using
development
processes that continuously adapt and adjust to (1) collective experience and skills of the
developers, including experience and skills gained thus far in the development project, (2)
changes in software requirements and (3) changes in the development and targeted operating
environments. Examples of published agile processes are
Extreme Programming (XP)
[3][7][8][22][29][39], the Crystal process family, [13], SCRUM [33][34], Adaptive Software
[TFR05] D. Turk, R. France, B. Rumpe.
Assumptions Underlying Agile Software Development Processes..
In: Journal of Database Management, Volume 16, No. 4, pp. 62-87, October-December 2005
Idea Group Inc., 2005
www.se-rwth.de/publications
Understanding Agile Software Development Processes – page 2
Development [19], and AUP (Agile Unified Process) [23] which has grown out of work on the
UML [21][31][38].
Proper use of agile processes requires an understanding of the situations in which agile
processes are and are not applicable. One way of determining whether an agile process is
applicable in a particular situation is to check whether the assumptions underlying the process
hold in that situation. If the assumptions do not hold then use of the agile process may not be
appropriate. Prevailing descriptions of agile processes seldom present the underlying
assumptions explicitly and thus it is difficult for developers and project planners to determine the
applicability of agile processes to their projects and environments.
This paper identifies some of the assumptions underlying agile processes that can be used to help
determine the applicability of agile processes to particular situations. The paper also discusses
some of the limitations that may be inherent in agile approaches because of these assumptions.
The assumptions were identified by examining published work on Extreme Programming (XP)
[3][5], Scrum [34], the Agile Unified Process (as described by Craig Larman) [23], critiques of
agile processes [10][27], and the principles stated by the Agile Alliance.
It is important to note that our critique of agile processes is concerned with identifying
assumptions underlying a family of agile processes. Other critiques of agile processes have been
published (e.g., see [10],[27]), but none of the critiques we have examined have focused on
identifying assumptions underlying agile processes for the purpose of determining the scope of
their applicability. For example, in the book “Questioning Extreme Programming” McBreen [27]
presents a critique of XP in which he poses some important open questions and provides answers
to other questions based on his personal experience, but he does not explicitly identify
assumptions underlying agile processes. McBreen’s critique was used as a source in our work
along with other experience reported elsewhere (e.g., see [14], [24]).
The remainder of the paper is structured as follows. In section 2 we give an overview of a typical
agile process, eXtreme Programming, to give the reader a concrete example of an agile process.
In section 3 we describe the assumptions that we have identified. In section 4 we identify some
of the limitations that arise in situations in which these assumptions are not met and suggest how
they can be addressed by adapting some of the agile process techniques and practices. We
conclude in section 5 with an overview of the results of our work and an outline of issues that
require further investigation.
2. Overview of eXtreme Programming – A Representative
Agile Process
There are a variety of software development processes that currently claim to be agile. Space
does not allow us to give an overview of all of the agile processes we have reviewed. However,
Understanding Agile Software Development Processes – page 3
since Extreme Programming (XP) is probably the most well-known agile process, we use it to
illustrate representative agile process concepts.
Extreme Programming (XP)
It can be argued that the popularity of XP helped pave the way for other agile processes. Kent
Beck, one of the chief architects of XP, states that XP is a “lightweight” development method
that is tolerant of changes in requirements. It is “extreme” in that “XP takes commonsense
principles and practices to extreme levels” [5, p. xv].
XP is based on the following values:
‚ Communication and Feedback: Face-to-face and frequent communication among
developers and between developers and customers is important to the “health” of the
project and the products under development. Feedback, through delivery of working code
increments at frequent intervals, is also considered critical to the production of
software
that satisfies customer needs.
‚ Simplicity: XP assumes that it is more efficient to develop software for current needs
rather than attempt to design flexible and reusable solutions. Under such an assumption,
developers pursue the simplest solutions that satisfy current needs.
‚ Responsibility: The responsibility of producing high-quality code rests ultimately with
the developers.
XP consists of technical and managerial practices that are integrated in a complementary manner.
The architects of XP take great care to point out that the individual techniques and practices of
XP are not new; it is the manner in which they are woven together that is unique. They also
stress that the techniques and practices have proven their worth in industrial software
development environments.
XP Pr ocess and Pr actices
The four core activities of XP are (1) coding, (2) testing, (3) listening to the customer and to
other developers, and (4) designing as an implicit part of the coding process. XP encourages an
informal design specification process in which developers discuss solutions by sketching
informal models on some presentation medium (e.g., whiteboard, flip chart). These models are
created primarily to help developers understand and communicate ideas during development, and
are not intended to be precise descriptions of the solution.
In order to support the five fundamental principles of XP / namely rapid feedback, simplicity,
incremental changes, embracing change, and quality work / XP offers a number of practices.
The early accounts of XP [7] offered twelve practices, but since then the number of practices has
increased (see [26],[40]). We give an overview of some of the original practices in what follows.
Understanding Agile Software Development Processes – page 4
Pair programming, one of the more well-know XP practices, is a technique in which two
programmers work together to develop a single piece of code. The two programmers typically
work together at one computer, collaborating to design, implement and test a software solution
(program) [18][41][42]. At any point in time one programmer is directly working on the code,
while the other observes, provides alternative approaches, acts as a reviewer and provides instant
feedback. The two programmers switch their roles often, sometimes even after just a few
minutes. This approach has been shown to yield significantly higher productivity and code
quality than is achieved by two programmers working separately [40]. The intent is that two
programmers working and evaluating the code and design are likely to complement each other’s
skills, continually propose and evaluate alternatives and are more likely to recognize errors in the
code while it is being developed [41, p. 328]. Pair programming is based on two assumptions: (1)
active reviews are the most effective way to detect errors, and (2) different people see a problem
from different perspectives and will thus have a combined approach to problem-solving that is
more effective than individually applied approaches.
Refactoring, unit and acceptance tests, collective code ownership, and continuous integration
together tackle the problem of evolving code during XP-based development. Refactoring occurs
when a change to the internal structure of a system preserves the externally observable
functionality of the system. Refactoring is especially effective when large changes can be
decomposed into smaller steps that can be carried out using refactorings that have been
developed by Fowler and others [17]. These refactorings can be viewed as code transformation
patterns, and their use allows one to reduce the task of validating code after a complex change to
validation of smaller change steps.
After a refactoring, tests are run to ensure that parts that should not be affected by the changes
are intact and that the changes are implemented correctly. Collective code ownership allows
developers to appropriately change parts of the code that they did not write in order to implement
a change, while continuous integration allows developers to demonstrate the current status of
development more frequently.
XP: An Assessment
Although XP is considered an extreme process it is not devoid of rigor. In particular, XP’s focus
on code should not be interpreted as an endorsement of code “hacking”. XP stipulates that
developers follow all its practices in order to realize the benefits of agile development. As has
been pointed out by McBreen and others [27], it takes enormous discipline to apply XP and,
for
this reason, some projects may find it difficult to adopt an XP-compliant process.
A significant problem with XP is its reliance on source code for documentation. This usually
leads to situations in which in-depth knowledge of software products (e.g., design rationale,
trade-off considerations) exist only in the heads of the developers who developed the products.
Understanding Agile Software Development Processes – page 5
Loss of these developers could lead to significant organizational memory loss that could impair
an organization’s ability to complete projects in a timely manner.
XP specifically targets small- to medium-sized projects. XP proponents claim that XP’s unique
composition of best practices, and its omission of time-intensive software engineering activities
(e.g., detailed specification or modeling of requirements and design), can help downsize
otherwise large projects. There have also been proposals for scaling the XP process to large
projects (e.g., see [14]), including an approach that involves hierarchically structuring XP and
installing a steering committee to guide the individual projects [20].
To date, there are few objective surveys of projects claiming to use XP. One such survey [32]
was conducted on 45 projects that were labeled as XP projects by the developers. The results
show that XP is still in the “hype phase”: it was not clear whether the claimed successes were
based on developer enthusiasm or on the XP practices. A summary of the survey results is given
below:
‚ More than 90% of the projects claimed to be successful (as judged by the developers, not
by the customers)
‚ All surveyed said they would like to use XP again. None blamed failures on XP.
‚ The unavailability of customers was frequently the highest risk identified.
‚ Use of unit tests and pair programming were considered important practices.
‚ 33% used XP because it seemed more attractive than alternatives; 28%, because it fit the
project requirements best; and 9% because the management or customer wanted it.
The results of this survey also indicate that there may be situations in which the basic
assumptions underlying XP are valid. XP assumes that the cost of change slowly approaches
some limit over time, rather than increasing exponentially as has been traditionally assumed [7].
XP practices are based on the assumption that correcting requirements errors and design flaws
later does not cost significantly more than if they were detected and removed earlier. This
assumption allows developers to do less than thorough analysis and design in the early phases
and, instead, make improvements throughout the course of the project by refactoring the
code.
There is no objective evidence that this assumption is valid in general, but it can be argued that
the cost of change curve can be flattened by using reusable design experiences in the form of
architectural and design patterns, and capitalizing on new technologies supporting rapid program
development (e.g., libraries, components and frameworks, and more powerful compilers that
enable short and incremental compilations).
In the testing area, an issue that XP practitioners face is determining the tests needed to
adequately cover the code. It has been recognized by some advocates that knowledge of
systematic testing techniques can be beneficial when developing unit and acceptance tests in XP
[27].
Understanding Agile Software Development Processes – page 6
The set of tests developed for an application can be viewed as a model of the system: it describes
an exemplar set of data with intended behavior. The tests are not necessarily readable by
customers, but developers can use the tests to gain understanding of code they did not write, by
exercising the code using the tests. This implicit model of the system is a necessary prerequisite
for collective code ownership and refactoring techniques. However, if the rationale behind a test
is not documented, over time it may become unclear what aspects are being tested.
3. Identifying Assumptions Underlying Agile Processes
In recent years a number of processes claiming to be “agile” have been proposed in the literature.
To avoid confusion over what it means for a process to be “agile”, seventeen methodologists and
proponents of agile processes met to discuss and come to an agreement on what “agility” means.
The result of the meeting was the formation of the Agile Alliance and the publication of a
manifesto that included a list of principles agile processes should support [1]. A summary of
these principles (numbered and in order as reported by the Agile Alliance [1] are given in Figure
1 below.
1. “Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.”
2. “Business people and developers must work together
daily throughout the project.”
3. “Welcome changing requirements, even late in
development.”
4. “Deliver working software frequently.”
5. “Working software is the primary measure of progress.”
6. “Build projects around motivated individuals. Give them
the environment and support they need, and trust them
to get the job done.”
7. “
The best architectures, requirements, and designs
emerge from self-organizing teams.”
8. “The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.”
9. “Agile processes promote sustainable development.”
10. “Continuous attention to technical excellence and good
design enhances agility.”
11. “Simplicity is essential.”
12. “Project teams evaluate their effectiveness at regular
intervals and adjust their behavior accordingly.”
Figur e 1: Pr inciples of the Agile Alliance
Understanding Agile Software Development Processes – page 7
The manifesto of the “Agile Alliance” is a condensed definition of the values and goals of “Agile
Software Development” and is detailed through these principles which can be viewed as a set of
policies and rules that should be supported by processes claiming to be “agile”. These principles
provide a good base for identifying assumptions underlying agile processes. In the next section
we review these principles and identify assumptions that appear to be made when accepting these
principles.
Principles, Practices, Assumptions, and Limitations
Figure 2 summarizes our view of the relationship between Principles, Practices, Assumptions,
and Limitations. We have taken the view that there are assumptions, usually unstated, that led to
the acceptance of the Agile Alliance’s principles. There are also assumptions made by
developers (again unstated) regarding what these principles mean and their relative importance.
Based on these principles and assumptions, development practices are set in place. Whether
intended or not, these assumptions lead to limitations in the resulting agile processes. The
limitations discussed later in this paper are based in part on our assessment of the assumptions
that exist behind agile process principles and practices. In this section we identify assumptions
underlying the Agile Alliance principles, as we perceive them. The discussion in this section is
organized around clusters of related principles, where each cluster gives rise to a distinct set of
assumptions. We also identify examples of situations in which the assumptions may not hold.
Assumpti ons
Assumptions
Principle
Practice
Limitations
Principles
Practices
based on
based on
derived from
lead to
support
have
Figur e 2: Relationships Between Pr inciples, Pr actices, Assumptions, & Limitations
Pr inciple 1. “Our highest pr ior ity is to satisfy the customer thr ough ear ly and
continuous deliver y of valuable softwar e.”
Pr inciple 4. “Deliver wor king softwar e fr equently.”
Pr inciple 5. “Wor king softwar e is the pr imar y measur e of pr ogr ess.”
The prominence of Principle 1 serves to remind developers that software is developed to perform
services that add value to users at the time of delivery. (Principles 4 & 5 can be viewed as
consequences of principle 1, and thus are discussed together here.) Developers and project
Understanding Agile Software Development Processes – page 8
planners need to keep in mind that customer needs evolve through use of systems. Support for
Principle 4 allows developers to gauge and address evolving customer needs. Agile processes
provide support for these principles by structuring development activities into short fixed-time
iterations that each produces working code. These fixed-time iterations make agile processes
predictable along the time dimension. The price paid is that product scope can be unpredictable:
in meeting an iteration deadline, developers can choose not to implement features originally
marked for implementation in the iteration. Agile processes utilize practices that help developers
minimize the time it takes to realize elicited requirements in working code. In XP, these practices
include building simple designs, continuous integration, collective code ownership, and
refactoring.
The frequent delivery of working code gives the project visibility in terms that the customer can
relate to (i.e., in terms of an evolving executable product), rather than in terms of evolving plans
in the form of requirements and design documents that are often not presented in terms a
customer can relate to or understand. Customers can use the increments delivered by iterations as
the basis for (1) determining project progress as specified by Principle 5 and (2) clarifying and
refining requirements. Short iteration lengths facilitate timely customer feedback that can help
ensure that the end product will meet customer needs at time of delivery.
The importance of involving end-users and customers in the software development process is
widely recognized, and was the primary motivation of work in the early 1980s on “end-user”
software development [12]. Much of this early work focused on developing mechanisms that
would allow end-users to directly contribute to the development of requirements and designs,
and understand the artifacts created by software designers. The work at that time focused on
developing requirements and design notations that are “customer-friendly”, that is, that can be
used to create requirements specifications and designs that provide customers with significant
insight into requirements and designs. Mechanisms such as fourth-generation programming
languages (4GLs) and executable requirements [4][30][35][36] and design specifications were
considered to be enabling technologies for end-user software development. Rather than
emphasize technical facilitators of customer interaction, agile processes emphasize continual
collaboration of developer and customer teams.
Assumptions Under lying Pr inciples 1, 4, and 5
Visibility Assumption: Project visibility can be achieved solely through delivery of working
code.
Visibility of software development projects is traditionally accomplished through reports,
specifications, and measures of quality and productivity, and the working application (code) is
only seen after the developer has done a large amount of work and spent a great amount of time
working on the project. For customers, it is easier to gain a sense of whether the project is
Understanding Agile Software Development Processes – page 9
progressing in the direction needed if they can actually see the user interface and actually see the
software do the things they need it to do, rather than simply relying on reports, specifications,
and other measures. Because it is the end-product the customer really cares about, the primary
measure of progress in agile processes is based on the code developed in the project.
This works well for software that is equipped with user interfaces that evolve over time. In
projects in which the user-interface is not always part of a deliverable increment, or projects
concerned with developing systems with no human interface (e.g., embedded systems) some
other means of visibility is needed. For such projects, software simulations, coverage of
acceptance tests, and formal reviews and inspections of deliverable increments can provide some
visibility.
Iteration Assumption: A project can always be structured into short fixed-time iterations.
Agile processes require developers to group required features into loosely coupled bundles that
can each be addressed in short, fixed-time iterations. Such decomposition is usually based on an
implicitly imposed architecture consisting of loosely-coupled modules and is thus desirable. The
assumption here is that the developing application can be broken into small, discrete increments,
that can be developed and demonstrated in short fixed-time intervals, and that after each of these
iterations the customer will be able to observe additional functionality in the product. Because of
this, the customer will be able to give frequent feedback as to the progress of the project,
indicating whether it is being developed as needed / expected or not.
Structuring work in small bundles that can be implemented quickly may not always be possible.
For example, in some complex systems an application may be required to interface with a
number of subsystems in complex ways just to provide basic services that are of value to
customers. In these situations it may not be possible create small enough bundles of features to
tackle in an iteration because of the tight dependencies.
Pr inciple 2. “Business people and developer s must wor k together daily
thr oughout the pr oject.”
The interaction between developers and end-users in agile processes is concerned primarily with
resolving feature-related issues and determining the scope of effort. This interaction does not
occur only at the start of a project; it occurs throughout the process. Specifically, agile processes
advocate interactions that could involve customers (1) providing inputs in the form of informal
descriptions of expected behavior (for example, stories in Extreme Programming), (2) answering
questions about desired features, (3) collaborating with developers in resolving issues pertaining
to features to be implemented, and (4) collaborating with developers to evolve project plans
Understanding Agile Software Development Processes – page 10
One of the most important effects of this close collaboration between users and developers is the
better understanding of each other’s problems and needs, which reduces human interaction
problems and thus significantly enhances the chance for a successful project result.
This principle is not only applicable to the interactions between developers and customers; it also
extends to interactions among developers as well. Frequent interaction allows developers to
quickly resolve problems and misunderstandings, and to more quickly and reliably move forward
on the project.
Assumptions Under lying Pr inciple 2
Customer Interaction Assumption: Customer teams are available for frequent interaction when
needed by developers.
Some major assumptions here are that the customer is available at the time the developers need
to interact with them, and that the customer can always reschedule other work so that there is
time for frequent interactions with the developers. The reality is that it may not always be
possible for a customer to reschedule other work.
Team Communication Assumption: Developers are located in time and place such that they are
able to have frequent, intensive
communication with each other.
This assumption is very similar to the Customer Interaction Assumption, but is focused on the
ability of developers to interact with each other. Just as the Customer Interaction
Assumption
assumes a certain amount of common time, place, resources, and availability, so does the
Team
Communication Assumption. Time, place, resources, and availability must all be coordinated
and provided in order to allow this principle to be supported. Examples of projects in which this
assumption does not hold are plentiful. It is not unusual to have development teams on a single
project that are dispersed in wide geographical areas involving many time zones.
Pr inciple 8. “The most efficient and effective method of conveying infor mation
to and within a development team is face-to-face conver sation.”
In agile processes, face-to-face communication is emphasized over formal and precise
documentation, but also over tele-/video-conferences or email conversations. The agile process
community claims that more is gained through informal personal communications than through
communication based on formal documentation, even though the ability to track all information
disappears. An advantage of face-to-face communication is that the parties involved can change
the direction of the discussion as needed to gain insights into the topic under discussion, and can
observe and respond to non-verbal communication cues as developers and/or customers interact.
Understanding Agile Software Development Processes – page 11
Even though formal and technical communication mechanisms are discouraged, protocols or “to
do” lists should be used to keep track of things that have been discussed.
Assumptions Under lying Pr inciple 8
Face-to-Face Assumption: Face-to-face interaction is the most productive method of
communicating with customers and
among developers.
It is hard to imagine Principle 8 being realized without having co-located customers and
developers and without schedules that allow frequent interaction during a project. If customers
and developers are all co-located, even to the extent they can walk down the hall and talk with
each other, then any time questions, issues, or problems arise, they can be addressed immediately
and clear resolution may be immediately obtained. Without face-to-face contact there is
increased potential for mis-communication, and there is always the difficulty of getting in
contact – the “telephone tag” or “e-mail tag” problem.
The de-emphasis of documentation as a communication aid is based on an assumption that tacit
knowledge is to be valued over externalized knowledge. Proponents point out that developers
need to internalize externalized knowledge to make it useful and that learning can be
accomplished by sharing of tacit knowledge through conversations [27]. Critics have argued that
the focus on tacit knowledge makes projects that use agile processes dependent on experts [10].
Another concern is that valuing tacit knowledge over externalized knowledge can lead to
corporate memory loss and a reduced ability for an organization to systemically learn from its
collective experience. An organization that is concerned with its ability to effectively learn from
past experience needs to value both tacit and externalized knowledge and understand their
interactions. Tacit knowledge is critical to building externalized knowledge, as pointed out by
Nonaka [25][37], and externalized knowledge can interact with tacit knowledge to reveal hidden
or create new tacit knowledge. Organizations that value systemic learning need to foster
environments that not only support the sharing of tacit knowledge but also support externalizing
tacit knowledge.
Documentation Assumption: Developing extensive (relatively complete) and consistent
documentation and software models is
counter-productive.
Given agile developers’ code-centric focus (see principles 1, 4, & 5 above), this downplaying of
documentation and software models is not surprising. The assumption is that it is more reliable
to determine specifications and design from code than from other documents – especially since
specifications, requirements, design documents, and models may not be kept up-to-date when
code is changed. Thus, the code is the most accurate and reliable description of what a system
does and how it was
designed.
Understanding Agile Software Development Processes – page 12
A reason for the agile process community’s disenchantment with modeling may be a result of
prior experiences with commercial modeling tools that were nothing more than tailored drawing
environments. Such tools provided very little support for the more difficult tasks of maintaining
(1) traceability links across models and (2) consistency between models and their
implementations. Current modeling tools have moved somewhat beyond this and now provide
support for code generation and round-trip engineering. More importantly, major tool vendors
are currently extending their offerings to support the Object Management Group’s model-driven
software development approach, known as the Model-Driven Architecture (MDA) [28]. MDA is
based on a separation of platform-specific system details from platform-independent details.
MDA-based tools provide mechanisms for mapping platform-independent details to platform-
specific implementations, with a significant portion of the mapping being automated through the
use of patterns, templates, and other forms of reusable experiences. In the MDA approach,
models are the central artifacts, and the use of MDA tools can help speed up development
through automated generation of significant portions of application and middleware code and by
raising the level of abstraction at which developers work.
For customers who contract with developers to provide systems, precise models may not be
necessary. However, there are situations in which models are valuable in their own right, and in
which it would be beneficial to maintain these models for future use. Some of these situations are
described below:
‚ Evolving large complex systems that have long life cycles: The availability of good models
can reduce the cost and effort of modifying such systems. Without these models, developers
are forced to analyze source code to understand it and determine the impact of change.
Studies have shown that a significant portion of the effort required to evolve systems is spent
understanding the code. Good models can help ease this task.
‚ Managing enterprise systems to ensure alignment with business goals: Good models of
business processes and systems can be used by enterprise architects to (1) check that planned
and implemented systems align with business goals, (2) identify how existing systems
services can be composed to create new services, (3) identify redundancies in systems
(particularly when organizations or sub-organizations merge with other organizations or sub-
organizations), (4) identify reusable development experiences, and (5) determine the impact
of change on existing systems. Business- and system-level models, well-defined mappings
between them, and the correspondence with code, can greatly enhance the management of
enterprise systems.
Good models and documentation can also be used to bring new hires up to speed on the business
and the systems being developed, and help component users determine whether a software
component really addresses their requirements.
Understanding Agile Software Development Processes – page 13
Pr inciple 3. “Welcome changing r equir ements, even late in development.”
Requirements will change during software development to reflect changes in (1) the environment
in which the software will be implemented, and in (2) the development environment. This has
been widely recognized (within and outside of the agile process community) and is one major
reason for rejecting the simple waterfall model. Evolving requirements is often viewed as an
inherent problem of software development. The agile process community views requirements
changes as providing opportunities for evolving software that can enhance the customer’s
competitiveness in a rapidly evolving environment. Development teams that can handle such
changes and produce software that is useful to the customer at the time of delivery (rather than at
the start of the project) are more likely to have satisfied customers. Short iteration cycles and the
“plan one iteration at a time” approach are claimed to provide the flexibility needed to
accommodate changes in agile processes. Agile process proponents claim that adhering to this
principle significantly increases the competitiveness of a company.
Assumptions Under lying Pr inciple 3:
Changing Requirement Assumption: Requirements always evolve, because of changes of
technology, customer needs, business domains
or even acquisition of new customers.
The assumption here is basically a re-statement of the principle. Changing requirements are not
regarded as necessarily bad, but are welcomed as an opportunity to satisfy customer needs even
better than when inflexibly sticking to old requirements. If customer needs change late in the
project, then making sure that the project adapts to these changes is important to making the
project a success.
Cost of Change Assumption: Cost of change does not dramatically increase
over time.
Agile processes challenge the widely-accepted belief that errors introduced early and detected
late in the process have significantly higher costs than errors detected early. Agile process
proponents argue that appropriate use of new development technologies and practices can reduce
the cost of uncovering errors late in the development process. One can make a credible case that
the use of technologies and practices such as (1) very fast compilers with sophisticated type
systems, (2) integrated development environments, (3) systematic improvement of code through
refactoring, and (4) automated test suites can help manage the cost of detecting and removing
errors even when the errors are uncovered late in the process. It is also clear that the cost of
correcting errors that can be fixed by localized changes – that is, changes with limited impact –
should be relatively stable over time. On the other hand, it is also clear that certain types of errors
– for example, architectural design flaws that seriously compromise the integrity of the design, or
errors that require corrective actions that have wide impact – are more costly to correct the later
they are uncovered.
Understanding Agile Software Development Processes – page 14
Pr inciple 6. “Build pr ojects ar ound motivated individuals. Give them the
envir onment and suppor t they need, and tr ust them to get the job done.”
Pr inciple 7. “The best ar chitectur es, r equir ements, and designs emer ge fr om
self-or ganizing teams.”
Pr inciple 12. “Pr oject teams evaluate their effectiveness at r egular inter vals
and adjust their behavior accor dingly.”
Agile processes such as XP and Scrum emphasize the need to shelter developers from
distractions so that they can focus solely on project activities. Management’s role is to facilitate
development by ensuring that developers have the resources they need when needed, and that
they are not distracted by concerns outside the scope of the project. Management should also
refrain from imposing and micro-managing the development team: developers should be trusted
to get the work done using a process that is based on their collective experiences (i.e., the team
should be self-organizing). Motivation is one of the most important properties humans need in
order to achieve ambitious goals with good quality results.
It can be difficult to transform a traditional team into an agile, self-organizing team. In some
agile processes this can require team leaders to transfer some of their traditional responsibilities
to team members. The short iterations of agile processes allow the project leader to test transfer
of responsibility, and thus incrementally build trust in a team’s ability to get the job done.
It is claimed that support for Principle 6 leads to products that are of higher quality, meet
customer requirements at delivery time, are better structured, and require less effort to build than
those created using more predictive (heavy-weight) processes. However, we are not aware of any
empirical studies that provide evidence of improved quality and reduced effort as a result of
using
agile processes.
The frequent reviews advocated by agile processes focus on the products and the process used to
develop the products. The planning of iterations also allows for reflection on previous results and
adjustment of future iterations. As the customer is continuously involved, different viewpoints on
the effectiveness of the project team can be obtained and flexible reaction to this reflection is
possible. The agility in agile processes is achieved through self-examination of the processes
used and corresponding adaptation of the process.
A self-evaluation and adjustment of a project, however, needs a project environment that allows
flexible adaptations. If the environment is “hostile”, this means it is inflexible to change, its
customers are not willing to actively participate, its contractors insist on written specifications to
be fulfilled, etc. It becomes much more difficult to act in an agile manner.
Understanding Agile Software Development Processes – page 15
Assumptions Under lying Pr inciples 6, 7, and 12
Team Experience Assumption: Developers have the experience needed to define and adapt their
processes appropriately.
Another way of saying this is that an organization can always form a team consisting of bright,
experienced problem solvers capable of evolving their process effectively. A development team
that (1) consists of developers with solid programming skills and relevant process and product
experience, and (2) has the ability to converge through rational discussions will likely be able to
effectively define and adapt their project processes. Unfortunately, not all development
teams
have these qualities. Some need guidance in determining appropriate processes. For such teams,
a “standard” process may work better than an adaptable process that they could find difficult to
control. Indeed, the Team Experience Assumption is critical to the success of agile development
projects.
It is generally accepted that there is no single process that will be applicable to all projects. On
the other hand, there are a number of best practices, techniques, and experiences that developers
can use in appropriate situations. Software development teams that consist of leading members
that understand the situations in which particular processes and practices are applicable are more
likely to be successful within an agile environment. It is therefore the responsibility of future
agile developers to develop such an understanding by gaining experiences with a variety of
approaches. Teams consisting of developers with these skills are more likely to benefit from the
use of agile processes.
Embedded within the Team Experience Assumption there seem to be two more assumptions:
The Self-Evaluation Assumption and the Self-Organizing Assumption.
Self-Evaluation Assumption: Teams are able and willing to evaluate
themselves.
A team must evaluate its process if it hopes to be able to adapt and/or improve the process. The
assumption is that the team is able and willing to do this. This is difficult in a project culture,
where less than optimal behavior is regarded as a serious liability, and thus team members may
be reticent to rive honest self-evaluations. Furthermore, even if the team is willing to self-assess,
the team also needs to have the skills to do so. This basically boils down to the necessity of the
team members having gained experience in previous successful projects to be able to compare
this project’s effectiveness with previous ones and identify possible improvements.
Self-Organization Assumption: The best architectures, requirements, and designs emerge from
self-organizing teams.
Understanding Agile Software Development Processes – page 16
The assumption here is that not only are the best architectures, requirements-elicitation, and
designs produced from self-organizing teams, but that the resources exist for self-organizing
teams to be created, and that management allows and supports this approach.
While this assumption is basically a restatement of Principle 7 it should not be regarded as
simply redundant. It is assumed that teams will self-organize, drawing from the most highly-
qualified talent-pool available, thus creating teams of diverse capabilities, and thus the ability to
create the best products possible. The concept of self-organizing teams is very different from
how many organizations work. Thus, if an organization expects to gain the most from applying
Agile processes it should be aware that its management of teams may need to be radically re-
designed.
Pr inciple 9. “Agile pr ocesses pr omote sustainable development.”
Pr inciple 10. “Continuous attention to technical excellence and good design
enhances agility.”
Using agile processes, developers focus on delivering just the functionality needed and timely
evolution of the software in response to changes in customer needs and the market. Agile
process advocates stress the importance of fostering a development environment that continually
stimulates and motivates developers. Rules, such as XP’s 40 hour weeks and No-Overtime,
target this principle.
The primary quality control activities in agile processes are code testing and customer feedback.
Frequent review meetings are advocated in processes such as Scrum, while Extreme
Programming advocates continuous reviews through pair-development of code. Extreme
Programming also advocates the building of test cases before the building of code, and the use of
regression tests to ensure that implemented changes do not have undesirable effects.
As systems grow through time, an initially well-designed architecture may become increasingly
blurred. Extreme programming uses the refactoring technique to constantly redesign the system
and therefore keep the design quality at an optimum. This keeps implementations enhanceable
for further iterations and maintainable for the future.
Assumptions Under lying Pr inciples 9 and 10
Quality Assurance Assumption: Evaluation of software artifacts (products and processes) can be
restricted to frequent informal
interviews, reviews and code testing.
XP replaces the traditional review with pair programming, collective code ownership, and a
rigorous “test first” approach. These approaches provide opportunities for continuous review and
improvement of the product during development. Scrum and Crystal advocate the frequent use of
Understanding Agile Software Development Processes – page 17
workshops, review meetings, and interviews to evaluate products and the process, and use the
results to adapt the process accordingly.
Despite their apparent strengths, it seems that the informal evaluation techniques of agile
processes may not be sufficient for establishing the quality of safety-critical systems – systems in
which in which failure can result in direct injury to humans or cause severe economic damage.
Development and testing techniques which are more formal and/or rigorously planned may help
ensure the quality of these types of systems. Those, however, require significantly more effort
and are thus a lot more expensive. Validating an implementation against its requirements
through analysis techniques, for example, means that a precise and detailed specification model
must be derived from the requirements.
Continuous-Redesign Assumption: Systems can be continuously redesigned (refactored) and
still maintain their structural and conceptual integrity.
One major assumption behind agile development is that a design can and should be continuously
redesigned. Day after day the design is re-evaluated, and as better designs are determined,
refactoring and re-development are carried out. Of course, a big assumption for this is that this
redesign can be carried out for a significant amount of time without destroying the structural and
conceptual integrity of the design and the product.
Pr inciple 11. “Simplicity is essential.”
This principle is a direct reaction to what is perceived as unnecessary complexity imposed by
heavyweight processes. Agile processes therefore advocate simplicity both in the code and the
tools used. Code generators or frameworks are advocated only if they provide clear value to the
project. Of utmost importance, the design is to be kept simple to support future iterations.
Therefore, a focused architecture satisfying today’s needs is preferred to a general architecture
that is “designed for the future”. This follows the idea that future changes are almost absolutely
unforeseeable and it therefore makes little sense to plan for a future that might not happen.
Furthermore, redesign is encouraged if it simplifies the system and removes unneeded
functionality.
Application-Specific Development Assumption: Reusability and generality should not be goals
of
application-specific software development.
Part of keeping an application simple is to stay focused on current requirements and needs rather
than trying to build a more general system that will “more easily be adapted to future needs”.
Building a more general and “adaptable” system tends to make the system more complex.
Understanding Agile Software Development Processes – page 18
Agile processes encourage the use of reusable artifacts (e.g. design frameworks, patterns) only
when it is clear that their use can help reduce costs or increase quality. Building a generalized
piece of code (one that can be used in a number of situations) is encouraged in agile processes
when it is clear that such generality can be used in the same project (e.g. factoring common
method parts). Many agile process advocates claim that a focus on creating general solutions can
result in efforts on making systems amenable to changes that may never occur. This is true
especially of those developers who adopt the XP approach to agile development; it is not
necessarily inherent in the principle itself. By focusing on building software that implements the
specific requirements at hand, and keeping this well-designed, agility for completing this
development is enhanced.
Part of this assumption is the idea that the long-term costs of development are smaller if at any
given time the focus is on current requirements rather than on generalization. Of course, this
assumption is debatable, since it may turn out that if the original design had been more general, it
would have been easier, and thus less costly, to add and adapt features over time. But this
viewpoint must be held in contrast to the view that it is hard to know what future changes will be
required, and thus that developers may be investing in generalizations that will never be needed.
Continuous-Redesign Assumption (re-iterated):
Systems can be continuously redesigned
(refactored) and still maintain their structural and conceptual integrity.
Generally, when a system is first designed it is in its simplest state. Over time, and after many
changes have been made, the design typically degrades and thus the system becomes more
“complex”. The assumption here is that this continuous re-design actually keeps the system
simpler.
Figure 3 below summarizes the assumptions identified in this section that lie behind the
principles of the Agile Alliance.
Understanding Agile Software Development Processes – page 19
1. The Visibility Assumption Project visibility can be achieved solely through
delivery of working code.
2. The Iteration Assumption A project can always be structured into short
fixed-time iterations.
3. The Customer
Interaction
Assumption
Customer teams are available for frequent
interaction when needed by developers.
4. The Team
Communication
Assumption
Developers are located in time and place such
that they are able to have frequent, intensive
communication with each other.
5. The
Face-to-Face
Assumption
Face-to-face interaction is the most productive
method of communicating with customers and
among developers.
6. The
Documentation
Assumption
Developing extensive (relatively complete) and
consistent documentation and software models is
counter-productive.
7. The Changing
Requirements
Assumption
Requirements always evolve, because of changes
of technology, customer needs, business domains
or even acquisition of new customers.
8. The Cost of Change
Assumption
Cost of change does not dramatically increase
over time.
9. The Team Experience
Assumption
Developers have the experience needed to define
and adapt their processes appropriately.
10. The Self-Evaluation
Assumption
Teams are able and willing to evaluate
themselves.
11. The Self-Organization
Assumption
The best architectures, requirements, and designs
emerge from self-organizing teams.
12. The Quality
Assurance
Assumption
Evaluation of software artifacts (products and
processes) can be restricted to frequent informal
interviews, reviews and code testing.
13. The Application-
Specific
Development Assumption
Reusability and generality should not be goals of
application-specific software development.
14. The Continuous-
Redesign
Assumption
Systems can be continuously redesigned
(refactored) and still maintain their structural and
conceptual integrity.
Figur e 3: Summar y of Assumptions Behind Pr inciples of the Agile Alliance
4. Tackling Limitations of Agile Processes
From the discussion in the previous section it should be clear that the assumptions underlying
agile processes do not hold in all software development projects and environments. This should
not be surprising: Agile approaches are not process silver bullets. Because these assumptions are
Understanding Agile Software Development Processes – page 20
not met in all organizations and/or development environments, agile approaches, in their current
forms, do have limitations. It is possible to extend agile processes to address their limitations.
Such extensions can involve incorporating principles and practices often associated with more
predictive, plan-based, or “traditional” development processes into agile processes. In general,
users of agile processes need to ensure that practices based on assumptions that are not valid in
their development environments are modified accordingly.
In this section we identify some limitations associated with the assumptions made by agile
processes and discuss how some of these limitations can be addressed. For each limitation we
characterize the situations in which the assumptions that lead to the limitation do not hold and
discuss how agile processes can be modified to extend the applicability of agile processes. Not
all the assumptions identified in the previous section lead directly to limitations discussed in this
section.
Figure 4 below summarizes the relationships between the limitations discussed in this section
and the relevant assumptions identified in the previous section. We have identified two
categories of limitations: Personnel-related limitations and Product-related limitations. The
assumptions that are people-oriented tend to lead to limitations in the Personnel category, while
assumptions about the types of artifacts produced in a project lead to limitations in the product
category.
Understanding Agile Software Development Processes – page 21
Agile Pr ocess Limitations
Per sonnel Limitations Pr oduct Limitations
Assumptions
Limited support
for distributed
development
environments
Limited support
for
subcontracting
Limited support
for
development
involving large
teams
Limited support
for building
reusable
artifacts
Limited support
for developing
safety-critical
software
Limited support
for developing
large, complex
software
Customer
Interaction
Assumption
X X X
Team
Communication
Assumption
X X X
Face-to-Face
Assumption
X X X
Changing
Requirements
Assumption
X
Documentation
Assumption
X X X X X X
Quality
Assurance
Assumption
X X X
Iteration
Assumption
X
Application-
Specific
Development
Assumption
X
Continuous
Redesign
Assumption
X X X
Figur e 4: Limitations of Agile Pr ocesses and Related Assumptions
Limited Support for Distributed Development Environments
Distributed development environments are environments in which the developers are not all
located at the same geographical location, or are not located in close geographical proximity to
each other. Likewise, if the development team is not located in close geographical proximity to
the customer similar issues can result.
Geographical dispersion leads to various issues that do not exist when everyone is located at the
same site, or, at least, are located relatively close to each other (e.g., in the same city or in two
cities that are not far apart). Distributed development typically makes communication more
difficult, because people are not able to interact at the same time and/or same place. Even if
communication is not harder, distributed development requires special supporting tools,
Understanding Agile Software Development Processes – page 22
technologies, and communication mechanisms in order to address the unique requirements and
characteristics of such an environment.
In distributed development environments, the Customer Interaction, Team Communication,
Face-to-Face, and Documentation assumptions may not hold. The first three assumptions
presume that it is very easy for developers to interact with each other and with customers. In
fact, the Face-to-Face assumption assumes that developers and customers are all together where
they can meet face-to-face – that they are co-located – since agile developers believe this is the
most productive way to interact.
Geographical distribution makes interactions harder because of varying work schedules,
differences in time zones, and because developers and clients cannot always see each other’s
reactions, and share ideas as flexibly and as clearly. The emphasis on co-location in agile
processes does not fit well with the drive by some industries to realize globally distributed
software development environments. Differential labor costs in other regions or other countries
may motivate customers to employ offshore developers, or may motivate developers to use
offshore labor. Development environments in which team members and customers are physically
distributed may not be able to accommodate the face-to-face communication advocated by agile
processes. In such cases, one can at least approximate face-to-face communication using
technologies such as video-conferencing, chat and on-line whiteboards, conference calls, etc., but
these technologies can be expensive and are not always as effective as one would hope.
Face-to-face communication can be as important in distributed environments as non-distributed
ones. Such meetings must be planned in advance to ensure that all involved can participate and
that the discussions are effective and not too time consuming. One can use such face-to-face
meetings as major synchronization events in which geographically dispersed developers (1) are
made aware of the progress made by others and (2) discuss plans for further evolving the
product. In between such meetings, documentation (beyond code) may become the primary form
of communication, with e-mail, chat, and video-conferencing technologies supplementing.
Good documentation of requirements and designs, produced and maintained in a timely manner,
is essential to ensure that the distributed team members all maintain the same vision of the
product to be built. This should not be interpreted as a requirement to document or model all
aspects of software. Documentation and models should be created and maintained only if they
provide value to the project and project stakeholders.
Agility is not always possible if communication is restricted to exchange of formal
documentation due to legal reasons or due to world-wide distributed development. In these cases,
only elements of agile process can be introduced locally, with formal processes being used to
coordinate the larger, distributed project.
Understanding Agile Software Development Processes – page 23
Unfortunately, in distributed environments especially, documentation is even more important
because of differing time and place work activities, and different people and teams
simultaneously and sequentially working on the same project. Documentation becomes more
important because of the limited ways in which developers and customers can interact The focus
on minimizing documentation thus creates limitations in how well distributed development can
be done following agile processes.
Limited Support for Subcontracting
Outsourcing of software development tasks to subcontractors is often based on contracts that
precisely stipulate what is required of the subcontractor. Subcontracted tasks have to be well-
defined in the cases where subcontractors have to bid for the contract. In coming up with a bid, a
subcontractor will usually develop a plan that includes a process – with milestones and
deliverables – in sufficient detail to determine a cost estimate. The process could follow an
iterative, incremental approach, but the subcontractor will likely have to make the process
predictive by specifying the number of iterations, and the deliverables associated with each
iteration, in order to compete. Because of this, the Customer Interaction, Team Communication,
Face-to-Face, Documentation and Changing Requirements assumptions may not hold when work
is subcontracted in a project.
As discussed above, the first three assumptions presume that developers and customers are all
co-located so they can have face-to-face interaction whenever needed. It may not be possible to
co-locate subcontractors with developers and customers. In these cases, the same issues that
were identified for distributed development exist for subcontracting as well.
By requiring subcontractors to co-locate with the primary developers and the customer, these
issues can be addressed.
As was discussed above, the documentation assumption states that documentation (other than
actual program code) should only be created when absolutely necessary. In subcontracting, as
was described for distributed development environments, documentation is important because
people and teams who do not work together on a day-to-day basis must communicate and
provide information so that others (other subcontractors, the main developers, the customer, etc.)
can interact with what has been done and evaluate its acceptability within the project.
Given the greater “distance” between the main developers and subcontractors, and between the
subcontractors and the customer, the assumption that documentation is not so important is easily
seen to be invalid.
There is not much an agile development organization can do to address this issue other than to
increase its documentation, or to require subcontractors to co-locate with them.
Understanding Agile Software Development Processes – page 24
The changing requirements assumption states that requirements always evolve. However,
subcontractors typically have won an award to develop software for a fixed set of requirements.
If requirements change frequently, the contract has to change frequently, and this can lead to
significant cost increases, since contracts typically state that there will be extra charges for each
change to the contract. The basis of the contract used by agile developers and that of
subcontractors is fundamentally different, since one assumes changing requirements and the
other assumes a fixed set of given requirements.
In order to address this issue, it is possible that contracts can be written that allow a
subcontractor some degree of flexibility in how they develop the product within time and cost
constraints. This is certainly possible if the subcontractor has a good track record and can be
trusted by the contracting company to develop a product that meets the contracting company’s
needs. A contract supporting agile development in the subcontractor environment might ought to
consist of two parts:
‚ Fixed Part: This part defines (1) the framework that constrains how the subcontractor will
incorporate changes into the product (e.g., cost- and time-based criteria for accepting or
rejecting changes to the Variable Part (see below) of the contract, (2) the activities that must
be carried out by the subcontractor (e.g., quality assurance activities), and (3) requirements
that are to be considered fixed and deliverables that must be delivered.
‚ Variable Part: This part defines the requirements and deliverables that can vary within the
boundaries defined in the Fixed Part. This part can evolve within the constraints defined in
the Fixed Part. At the time the contract is signed, a description of prioritized deliverables and
requirements should be included.
Limited Support for Development Involving Large Teams
Large teams often have many sub-teams of specialists, and these may exist at different
geographically-distributed locations. Large teams typically focus on very large projects, where a
large amount of human resources are needed for solving the project’s problems. Because of
these issues, large teams require more interactions among their members and a higher degree of
focus in order to manage them. In these environments, the Customer Interaction, Team
Communication, Face-to-Face, and Documentation assumptions may not hold.
The size of teams can limit the effectiveness and frequency of face-to-face interactions. Agile
processes support process “management-in-the-small” in that its coordination, control, and
communication mechanisms are applicable to small to medium sized teams. With larger teams,
the number of communication lines that have to be maintained can reduce the effectiveness of
Understanding Agile Software Development Processes – page 25
practices such as informal face-to-face communications and review meetings. Large teams
require less agile approaches to tackle issues particular to “management-in-the-large”.
There is not much that can be done to address this assumption other than to attempt to minimize
the size of the team and to maximize the interaction that occurs, while at the same time not
allowing the amount interaction to overwhelm the developers and the customer(s).
With large teams, more documentation is inherently needed, simply for coordinating among the
large number of team members. Given their belief that any documentation other than code is to
be minimized, agile development processes provide limited support for development involving
large teams.
Traditional software engineering practices that emphasize documentation, change control and
architecture-centric development are more applicable for large teams. This is not to say that agile
practices are not applicable in such environments. There may be opportunities for large teams to
use agile practices, but the degree of agility possible may be less than that found in smaller
projects. For instance, the large overall team may have strict requirements for documentation,
but, within this, it may be possible for small teams to apply agile development methods while
they work on their project. After the project is completed, or at certain time intervals, the team
may document certain aspects of the project so as to be in line with the large team’s
requirements. This would allow most of the work to be done in an agile manner, and only at the
end (or other specified points) to produce required documentation.
Limited Support for Building Reusable Artifacts
Reusable artifacts are code and other components (analysis and design documents, patterns, etc.)
that can be reused from one project to another, in their entirety or at least in a major part. In
order to create components that are reusable, a big-picture view must be taken while they are
being developed, rather than simply focusing on the current application. What other types of
systems / applications might be able to benefit from this component? How many different ways
might one want to use it? What are the requirements of the domain, in contrast to simply this
application in the domain? These are a few of the questions that must be asked when thinking
about making components reusable and more general-purpose. When developing reusable
artifacts, agile development’s Documentation, Quality Assurance, Application-Specific
Development, and Continuous Redesign assumptions may not be valid.
If documentation other than actual code is minimized, it may be harder to determine when and
where a given artifact can be reused. Additional documentation may be needed to help indicate
the reuse possibilities for an artifact. In order for agile processes to support development of
reusable artifacts, they may need to increase the amount of documentation created.
Understanding Agile Software Development Processes – page 26
Agile processes such as Extreme Programming focus on building software products that solve
specific problems. Development in “Internet time” often precludes developing generalized
solutions even when it is clear that this could yield long-term benefits. In such an environment,
the development of generalized solutions and other forms of reusable software (e.g., design
frameworks) is best tackled in projects that are primarily concerned with the development of
reusable artifacts. This separation of the product-specific development environment from the
reusable artifact development environment is a primary feature of the reuse-oriented framework
called the Experience Factory developed by researchers at the University of Maryland at College
Park [5]. The wide applicability of a reusable artifact requires that the process used to build the
artifact emphasize quality control because the impact of low quality (in particular, severe errors)
is as wide as the number of applications that reuse the artifact. On the other hand, timely
development of reusable artifacts is desirable.
Continuous redesign is difficult when not developing application-specific artifacts. The
opportunity for customer feedback is lessened, and thus the improvements in quality and design
are reduced. In order to address this issue, agile developers must put in place specific processes
that are intended to obtain this type of feedback so that the design and quality of the reusable
artifacts can be enhanced.
It seems apparent that agile development does not naturally fit well for building reusable
artifacts. However, with some careful attention, and some key adjustments made to agile
processes, as mentioned above, it may be possible to successfully adapt and apply agile
processes to development of reusable artifacts.
Limited Support for Developing Safety-Critical Software
Safety-critical software is software where people’s lives, health, or safety may be compromised
if the quality of the software is not extremely high. Some examples include aviation control
software, and software/firmware to control x-ray machines. In these types of environments it is
important to know that software has been tested extensively, and has been designed to guarantee
that there will not be failures that affect the ability to correctly and safely use and control the
machinery. It is not acceptable for a machine to be allowed to give doses of x-rays that would be
fatal to the patient receiving them, or for a pilot to be unable to fly the airplane because of
software failure, for instance. In situations like these, the Documentation, Quality Assurance,
and Continuous Redesign assumptions of agile development may not be valid.
Formal specification, rigorous test coverage, and other formal analysis and evaluation techniques
included in software engineering approaches provide more robust, but also more expensive,
mechanisms to tackle the development of safety- or business-critical software. These approaches
can more reliably “guarantee” that appropriate tests have been run, and code has been analyzed,
so that developers and users are confident in the safety and reliability of the system.
Understanding Agile Software Development Processes – page 27
Applying some agile evaluation practices to such software can also be beneficial. For example,
(1) test-first approaches requires one to define unit tests before writing code, (2) the early
production of working code supported by the iterative, incremental process structure of agile
processes supports exploratory development of critical software in which requirements are not
well-defined, and (3) pair-programming can be an effective supplement to formal reviews.
Therefore, it can be assumed that agile and formal software development are not incompatible,
but can be combined when needed: Formal techniques may be used in combination with agile
processes to handle critical pieces of the software to increase quality and confidence.
Limited Support for Developing Large, Complex Software
Large, complex software is software that includes large amounts of code (many hundreds of
thousands, millions, etc., of lines) and/or may involve very intricate interrelationships between
the various parts of the system to ensure data integrity and to make certain that all parts of the
system interact reliably and run as intended. Development of large, complex software generally
requires a higher degree of management control and a greater amount of more “formalized”
processes to make sure everything fits and works together, and is runs reliably. The
Documentation, Quality Assurance, Iteration, and Continuous Redesign assumptions of agile
development may not be valid in these situations.
As was discussed above regarding large development teams, when developing large, complex
software, it is likely that there is an increased need for documentation. This is necessary for
simply documenting the larger set of requirements, features, and design decisions, as well as for
providing a knowledge base for the larger teams that are likely to be working on such systems.
Focusing almost exclusively on the code for the documentation can lead to a serious lack of
understanding about the system, and the more difficult task of training new team members
during and after the project is completed. If agile developers take the conscious effort to
document key decisions, designs, etc., then this limitation may be able to be avoided.
Likewise, the assumption that informal testing and reviews can ensure the required level of
quality in large complex systems is probably not valid. If the agile approach of creating tests
before writing code (test-first) is carried out, and the process used in coming up with these tests
is thorough and well-documented, then there may not be a problem. However, this needs to be
ensured in order for quality in large, complex systems to be maintained.
The Iteration assumption may not be valid, either, when developing large, complex software
because there may be systems in which functionality is so tightly coupled and integrated that it
may not be possible to develop the software incrementally. In these cases an iterative approach in
which code is produced in each iteration can still be used, but the code produced in each iteration
will include all the pieces in various states of incompleteness.
Understanding Agile Software Development Processes – page 28
Finally, the assumption that code refactoring removes the need to design for change may not
hold for large complex systems in particular. In such software there may be critical architectural
aspects that are difficult to change because of the critical role they play in the core services
offered by the system. In such cases, the cost of changing these aspects can be very high and
therefore it pays to make extra efforts to anticipate such changes early. The reliance on code
refactoring (an application of the Continuous Redesign assumption) could also be problematic
for such systems. The complexity and size of such software may make strict code refactoring
costly and error-prone. Models can play an important role here, especially if tools exist for
generating significant portions of the code from the models. This view of models as the central
artifacts for evolving systems is at the heart of the Object Management Group’s (OMG) Model-
Driven Architecture (MDA) approach [28].
5. Open Questions, Conclusions, and Future Work
This paper has discussed claims made by agile developers, and some of the underlying principles
and assumptions upon which agile development proceeds. Some of these assumptions have been
questioned, and implications discussed. Some assumptions may always be true, but in other
cases, these assumptions could lead to situations where agile development may not be applicable,
or even where agile development may fail. In any case, there are a variety of questions that
remain open and future work that needs to be done regarding agile development.
Open Questions
While advances in software technologies and development tools have helped launch new
generations of software products, it is also the case that new generations of software products
drive the development of more sophisticated development infrastructures. It seems natural to
assume that development might become more efficient and effective as the development
infrastructure becomes more sophisticated. It would seem that development processes should
improve over time as they adapt to the increasing sophistication of the development
infrastructure. This raises the following open questions related to software development
infrastructures and agile and “non-agile” processes:
‚ Do non-agile processes have a lot of ‘overhead’ because of the ‘less-sophisticated’
development infrastructure that existed at the time the processes were developed?
‚ Do agile processes work well because of the more sophisticated infrastructure that currently
exists (e.g., component/class libraries, design frameworks, fast incremental compilers)?
‚ Would agile processes work so well if this infrastructure were not in place?
‚ What aspects of this infrastructure are key to making agile processes successful, and what
aspects of agile processes themselves are responsible for their success? (The “nature-
nurture” question.)
Understanding Agile Software Development Processes – page 29
Answers to the above questions are not easy to obtain, but obtaining them can lead to a deeper
understanding of development processes and their evolution.
Need for Empirical Studies
While it appears that there have been many software development project successes based on
agile processes, so far most of these success stories have only anecdotal evidence. For a more
conclusive assessment of these new techniques, a sound scientific evaluation based on a
statistically significant number of comparable case studies would be necessary. This could not
only help one better understand unsolved and pressing problems in software engineering, but
would also allow project managers to guide their decisions on process selection in a better way.
It is invaluable to have hard numbers and data upon which to base our decisions about whether to
adopt agile approaches to software development or not. Therefore, it is necessary to collect and
analyze data about projects that have used agile processes. A first such step was done in [32].
Such studies will lead to a better understanding of how agile processes work, how they differ
from “non-agile” processes, and under what conditions agile processes are applicable and are
most successful.
Empirical data comparing the effectiveness and limitations of agile and non-agile approaches
would greatly enhance our understanding of the true benefits and limitations of agile processes.
In this paper we presented a list of limitations derived from our analysis of principles and
assumptions underlying agile processes. It appears that certain domains are more amenable than
others to agile development processes. Among them are Internet application domains, in which
there are significant time-to-market pressures and the costs of upgrading to the next release are
minimal. However, it also appears that companies that develop long-lasting, large, complex
systems may not be able to use agile processes in their current form.
Spectrum of Development Approaches
In general, some aspects of a software development project can benefit from an agile approach
while others can benefit from a less-agile or more predictive approach. From this perspective,
practical software development processes can be created by drawing techniques from agile as
well as traditional approaches, rather than considering “agile” and “traditional” as discrete
process classification points. Some projects can benefit from techniques that are more purely
predictive, plan-based, “traditional” processes in which the process steps are defined in detail
early in the project, and project goals remain relatively stable throughout the execution of the
process. At the same time, these projects may also benefit from techniques that are more “agile”
in which process steps and project goals are dynamically determined based on analyses of (1)
experiences gained with previously executed process steps, (2) similar experiences gained
outside of the project, and on (3) changes in the requirements and development environment.
From this perspective, the agility of a process is determined by the degree to which a project
team can dynamically adapt the process based on changes in the environment and the collective
experiences of the developers.
Understanding Agile Software Development Processes – page 30
Barry Boehm [10], in his analysis of agile practices, has proposed a process spectrum that is
based on the degree of flexibility one has in developing process plans. Another way of looking
at development processes might be in matrix form, with “agile” characteristics listed across one
dimension and “traditional” ones listed across the other. The actual process used would be a
combination of the characteristics selected from each of the two dimensions. This approach
would fit in the vein of method engineering [16] where the specific processes and techniques that
are desired for a project are selected from a catalog (method base) of available options.
Most agile process practices are adaptations of practices that have been touted by methodologists
over the last two decades and that can be found in more rigorous “traditional” processes. This
has been recognized by agile process advocates who point out that the differences lie not in the
individual practices, but in how they are put together. The cobbling together of best practices to
create processes that fit a development environment’s values and development goals has been
advocated by a number of methodologists and has resulted in at least one tailorable process
framework, known as OPEN [16]. In this light, agile processes can be viewed as reference points
along a spectrum of processes by those seeking processes that have the values embodied in the
agile processes.
Practical processes lie somewhere in between the purely agile and purely predictive extremes of
the process spectrum. Current agile processes are close to the purely agile end of the spectrum,
but they are not purely agile because they provide a process framework that constrains the form
of processes that developers must follow. For example, most published works on agile processes
stipulate an iterative, incremental process and advocate practices such as test-first code
development, pair-programming, and daily review meetings with particular formats.
Conclusions
It is important to be aware that agile development approaches are built on many, possibly
implicit, assumptions, and that these assumptions are probably not appropriate for all
organizations or development projects. When the assumptions made by agile development
methods are not in alignment, or even directly conflict, with those of the organization, managers
in charge of development need to take steps to adapt the agile development process if such an
approach is adopted, or be confident in choosing a “traditional” approach, knowing that it will
better fit their environment. If this is not done, an agile development approach may very likely
provide less than desirable results because of the limitations that result from these assumptions.
6. References
[1] Agile Alliance. (2002). http://www.agilealliance.org. Visited 2002 Aug
9.
[2] Ambler, S. (2002). Agile Modeling: The Official Agile Modeling (AM) Site.
http://www.agilemodeling.com. Visited 2002 Aug 9.
[3] Auer, K.; & Miller, R. (2002). Extreme Programming Applied. Boston: Addison-Wesley.
Understanding Agile Software Development Processes – page 31
[4] Barghouti, N.S.; & Kaiser, G. (1992). “Scaling Up Rule-Based Software Development
Environments.” International Journal of Software Engineering and Knowledge Engineering,
2:1 (March), 59-78.
[5] Basili, V.; Caldiera, G.; & Rombach, H. D. (1994). “The Experience Factory. ” In:
Marciniak, J. (ed.) Volume 1 of the Encyclodepdia of Software Engineering. John Wiley
Sons. Chapter X, pp. 469-476.
[6] Basili, V.; & Turner, A. (1975). “Iterative Enhancement: A Practical Technique for Software
Development.” IEEE Transactions on Software Engineering, 1:4.
[7] Beck, Kent. (2000). Extreme Programming Explained. Boston: Addison-
Wesley.
[8] Beck, K.; Fowler, M. (2001) Planning Extreme Programming Applied. Boston: Addison-
Wesley.
[9] Boehm, B. (1986). “A Spiral Model of Software Development and Enhancement.” ACM
SIGSOFT Software Engineering Notes, 11:4 (August), 22-42.
[10] Boehm, B. (2002). “Get Ready For Agile Methods, With Care.” IEEE Computer, 35:1
(January), 64-69.
[11] Boger, M.; Baier, T.; Wienberg, F.; & Lamersdorf, W. (2001). “Extreme Modeling.” In:
Succi, G.; & Marchesi, M. (eds.) Extreme Programming Examined. Boston: Addison-
Wesley.
[12] Briefs, U.; Siborra, C.; & Schneider, L. (eds.) (1983). Systems Design For, With, and By the
Users. Amsterdam: North-Holland.
[13] Cockburn, A. (2001). Agile Software Development. Boston:
Addison-Wesley.
[14] Crocker, R. (2001). “The 5 Reasons XP Can’t Scale and What to do About Them.” In:
Proceedings of XP 2001.
[15] Cusumano, M.; & Yoffie, D. (1999). “Software Development on Internet Time.” IEEE
Computer, 32:10 (October), 60-69.
[16] Firesmith, D. G.; & Henderson-Sellers, B. (2000). The OPEN Process Framework. An
Introduction. Addison-Wesley.
[17] Fowler, M. (1999). Refactoring.
Boston: Addison-Wesley.
[18] Fraser, S.; Beck, K.;Cunningham, W.; Crocker, R.; Fowler, M.; Rising, L.; & Williams, L.
(2000). “Hacker or Hero? – Extreme Programming Today.” Addendum to the Proceedings
of the 2000 ACM Conference on Object-Oriented Programming, Systems, Languages, and
Applications (OOPSLA 2000), Mineapolis, MN, USA, October 15-19, 2000, pp. 5-7.
SIGPLAN Notices, 35:10 (October), 2000.
[19] Highsmith, J. (2001). Adaptive Software Development: A Collaborative Approach to
Managing Complex Systems. Dorset House Publishing.
[20] Jacobi, C.; & Rumpe, B. (2001). “Hierarchical XP – Improving XP for Large Scale
Projects”. In: Succi, G.; & Marchesi, M. (eds.) Extreme Programming Examined. Boston:
Addison-Wesley.
[21] Jacobson, I.; Booch, G.; & Rumbaugh, J. (1999). The Unified Software Development
Process. Addison-Wesley.
Understanding Agile Software Development Processes – page 32
[22] Jeffries, R.; Anderson, A; & Hendrickson, C. (2001). Extreme Programming Installed.
Boston: Addison-Wesley.
[23] Larman, C. (2001, 2
nd
ed.). Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and the Unified Process. Prentice-
Hall.
[24] Lindvall, M.; Basili, V.; Boehm, B.; Costa, P.; Dangle, K.; Shull, F.; Tesoriero, R.;
Williams, L.; & Zelkowitz, M. (2002) “Empirical Findings in Agile Methods” In:
Proceedings of Extreme Programming and Agile Methods – XP/Agile Universe 2002,
August 2002, Springer, pp. 197-207.
[25] Nonaka, I; & Hirotak, T. (1995). The Knowledge Creating Company. Oxford: Oxford
University Press.
[26] Martin, R. C. (2003). Agile Software Development. Principles, Patterns, and Practices.
Prentice Hall.
[27] McBreen, P. (2003). Questioning Extreme Programming. Addison-Wesley.
[28] MDA (Model-Driven Architecture). (2002). http://www.omg.org/mda. Visited 2002 Aug
9.
[29] Newkirk, J.; & Martin, R. C. (2001). Extreme Programming in Practice. Boston:
Addison-Wesley.
[30] Osterweil, L. (1987). “Software Processes are Software Too.” Proceedings of the 9
th
International Conference on Software Engineering (ICSE’97), April.
[31] Rational Corporation. (1998). “Rational Unified Process: Best Practices for Software
Development Teams”. A Rational Software Corporation White Paper.
http://www.rational.com/media/whitepapers/rup_bestpractices . Visited 2002 Sep 16.
[32] Rumpe, B.; & Schröder, A. (2002). “Quantitative Survey on Extreme Programming
Projects.” In: Proceedings of the Third International Conference on Extreme Programming
and Flexible Processes in Software Engineering (XP2002), May 26-30, Alghero, Italy, pp.
95-100, 2002.
[33] Rising, L.; & Janoff, N. (2000). “The Scrum Software Development Process for Small
Teams.” IEEE Software, 17:4 (July/August), 2000, pp. 26-32.
[34] Schwaber, K.; & Beedle, M. (2001). Agile Software Development with Scrum. Prentice
Hall.
[35] Sutton, S.M., Jr.; Heimbigner, D.; & Osterweil, L. (1995). “APPL/A: A Language for
Software Process Programming.” ACM Transactions on Software Engineering, 4:3 (July),
221-286.
[36] Sutton, S.M., Jr.; Osterweil, L. (1997). “The Design of a Next-Generation Process
Language.” Proceedings of the 6
th
European Software Engineering Conference (ESEC’97);
5
th
ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE’97), Sep
1997, Zurich, Switzerland, 142-158.
[37] Takeuchi, H.; & Nonaka, I. (1986). “The New Product Development Game.” Harvard
Business Review, pp. 137-146, 1986.
[38] UML (2002). “OMG Unified Modeling Language Specification”, Version 1.4.1, ad/02-06-
22. Object Management Group (OMG). http://www.omg.org. Visited 2002 Aug 12.
Understanding Agile Software Development Processes – page 33
[39] Wake, W. (2002) Extreme Programming Explored. Boston: Addison-Wesley.
[40] Wells, D. (2002) http://www.extremeprogramming.org/. Visited 2002 Aug 12.
[41] Williams, L.; Kessler, R.; Cunningham, W.; & Jeffries. R. (2000). “Strengthening the Case
for Pair Programming.” In: IEEE Software, 17:4 (July/August), 2000, pp. 19-25.
[42] Williams, L.; & Upchurch, R. (2001). “In Support of Student Pair-Programming.”
Proceedings of the 2001 ACM Special Interest Group on Computer Science Education
(SIGCSE 2001) Conference, Charlotte, NC, USA, February, 2001, pp. 327-331.
Systems Analysis and Design
1
1th Edition
Chapter
2
Analyzing the Business Case
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
1
Explain the concept of a business case and how a business case affects an IT project
Describe the strategic planning process and why it is important to the IT team
Explain the purpose of a mission statement
Conduct a SWOT analysis and describe the four factors involved
Explain how the SDLC serves as a framework for systems development
2
Chapter Objectives
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
2
List reasons for systems projects and factors that affect such projects
Describe systems requests and the role of the systems review committee
Define operational, technical, economic, and schedule feasibility
Explain the factors that affect project priorities
Describe the steps and the end product of a preliminary investigation
3
Chapter Objectives (Cont.)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
3
Business case: Justification for a proposal
Requires consideration of the organization’s:
Overall mission
Objectives
IT needs
Systems development process
Systems request
Preliminary investigation
Findings are submitted to management
4
Introduction
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
4
5
A Framework for IT Systems Development
Strategic Planning Overview
Strategic planning: Process of identifying long-term organizational goals, strategies, and resources
Starts with a mission statement
Must reflect the firm’s vision, purpose, and values
Critical success factor: High-priority objective
What Is SWOT Analysis?
Strengths, weaknesses, opportunities, and threats
Examines a firm’s technical, human, and financial resources
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
5
6
A Framework for IT Systems Development (Cont. 1)
FIGURE 2-1 A SWOT analysis might produce results similar to those
shown here.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
6
7
A Framework for IT Systems Development (Cont. 2)
FIGURE 2-2 This SWOT analysis example focuses on a specific asset, such as a company patent.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
7
8
A Framework for IT Systems Development (Cont. 3)
Strategic Planning for IT Projects
Careful planning can help assure that:
The project supports overall business strategy and operational needs
The project scope is well-defined and clearly stated
The project goals are realistic, and tied to specific statements, assumptions, constraints, factors, and other inputs
Planning tools
Microsoft Word and Excel
CASE tools
Visible Analyst
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
8
9
A Framework for IT Systems Development (Cont. 4)
FIGURE 2-3 The Visible Analyst CASE tool supports strategic planning and allows a user to enter many kinds of planning statements. Notice the four SWOT categories highlighted in the list.
Screenshots used with permission from Visible Systems Corporation.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
9
10
A Framework for IT Systems Development (Cont. 5)
The Changing Role of the IT Department
Management and IT are linked closely
Remarkable changes have occurred in both areas
Today, systems development is much more team- oriented
The IT department is responsible for screening and evaluating systems requests
Larger firms may use an evaluation team or systems review committee
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
10
11
What Is a Business Case?
A business case should:
Be comprehensive and easy to understand
Describe the project clearly, provide the justification to proceed, and estimate the project’s financial impact
Questions answered by a business case
Why are we doing this project?
How much will it cost and how long will it take?
Are there any risks involved?
How will we measure success?
What alternatives exist?
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
11
12
Information Systems Projects
FIGURE 2-4 Six main reasons for systems requests.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
12
13
Information Systems Projects(Cont.)
FIGURE 2-6 Internal and external factors that affect IT projects.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
13
14
Evaluation of Systems Requirements
Systems requests are evaluated by a systems review committee or a computer resources committee
Systems Request Forms
Streamline the request process
Ensure consistency
Easy to understand
Include clear instructions
Indicate the required supporting documents
Submitted electronically
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
14
15
Evaluation of Systems Requirements (Cont. 1)
FIGURE 2-10 Example of an online systems request form.
Source: Florida Institute of Technology
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
15
Systems Review Committee
A broader viewpoint enables a committee to establish priorities more effectively than an individual
One person’s bias is less likely to affect decisions
Disadvantages
Action on requests must wait until the committee meets
Members might favor projects requested by their own departments
Internal political differences could delay important decisions
16
Evaluation of Systems Requirements (Cont. 2)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
16
Feasibility studies can be simple or exhaustive
Effort required depends on the nature of the request
Initial fact-finding involves:
Studying organizational charts
Performing interviews
Reviewing current documentation
Observing operations
Surveying users
17
Overview of Feasibility
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
17
18
Overview of Feasibility (Cont. 1)
FIGURE 2-11 A feasibility study examines operational, technical, economic, and schedule factors.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
18
Operational Feasibility
A proposed system will be used effectively after it has been developed
Can be affected by organizational culture
Cannot be accurately measured but requires careful study
Questions that can help predict a system’s operational feasibility
Is the project supported by management and users?
Will the new system result in a workforce reduction?
Do legal or ethical issues need to be considered?
19
Overview of Feasibility (Cont. 2)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
19
Economic Feasibility
Projected benefits of a proposed system out-weigh total cost of ownership (TCO)
Determination of TCO requires cost analysis of:
People, including IT staff and users
Hardware and equipment
Software
Formal and informal training
Licenses and fees
Consulting expenses
Facility costs
20
Overview of Feasibility (Cont. 3)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
20
Tangible costs are measured in dollars
Intangible costs can significantly affect organizational performance
Tangible benefits can result from a decrease in expenses or an increase in revenues
Intangible benefits are important to the company despite the inability to measure them in dollars
21
Overview of Feasibility (Cont. 4)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
21
Technical Feasibility
Technical resources required to acquire and use the system
Questions analysts should ask
Does the company have the necessary hardware, software, and network resources?
Does the company have the required technical expertise?
Does the proposed platform have sufficient capacity for future needs?
Will a prototype be required?
22
Overview of Feasibility (Cont. 5)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
22
Schedule Feasibility
A project can be implemented in an acceptable time frame
Issues that can affect schedule feasibility
Interaction between time and costs
Can the company or the IT team control the factors that affect schedule feasibility?
Has management established a firm timetable for the project?
What conditions must be satisfied during the development of the system?
Will an accelerated schedule pose any risks?
23
Overview of Feasibility (Cont. 6)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
23
Identify and weed out systems requests that are not feasible
Some feasible requests may not be necessary
Requests that are not currently feasible can be resubmitted as new hardware, software, or expertise becomes available
24
Evaluating Feasibility
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
24
Factors that Affect Priority
Will the proposed system reduce costs?
Will the system increase revenue for the company?
Will the systems project result in more information or produce better results?
Will the system serve customers better?
Will the system serve the organization better?
Can the project be implemented in a reasonable time period?
Are the necessary financial, human, and technical resources available?
25
Setting Priorities
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
25
Discretionary and Nondiscretionary Projects
Discretionary projects: Projects where management has a choice in implementing them
Nondiscretionary projects: Management has no choice in implementing a project
Most of these projects are predictable
Annual updates to payroll
Tax percentages
Quarterly changes
26
Setting Priorities (Cont.)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
26
Interaction with Managers and Users
Meet with key managers, users, and IT staff to describe the project, explain responsibilities, answer questions, and invite comments
Focus on improvements and enhancements, not problems
27
Preliminary Investigation Overview
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
27
28
Preliminary Investigation Overview (Cont. 1)
FIGURE 2-13 Six main steps in a typical preliminary investigation.
FIGURE 2-12 Model of a preliminary investigation. Notice the importance of fact-finding in each of the four areas.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
28
Planning the Preliminary Investigation
Step 1- Understand the problem or opportunity
Develop a business profile that describes current business processes and functions
Understand how modifications will affect business operations and other information systems
Identify the departments, users, and business processes involved
Consider using a fishbone diagram
29
Preliminary Investigation Overview (Cont. 2)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
29
30
Preliminary Investigation Overview (Cont. 3)
FIGURE 2-14 A fishbone diagram displays the causes of a problem. Typically, you must dig deeper to identify actual causes rather than just symptoms.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
30
Planning the Preliminary Investigation (Cont.)
Step 2 – Define the project scope and constraints
Define the specific boundaries, or extent, of the project
Define project scope by creating a list with sections called must do, should do, could do, and won’t do
Avoid project creep
Project creep: Process by which projects with very general scope definitions expand gradually, without specific authorization
Identify constraints
Constraint: A requirement or condition that the system must satisfy or an outcome that the system must achieve
31
Preliminary Investigation Overview (Cont. 4)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
31
32
Preliminary Investigation Overview (Cont. 5)
FIGURE 2-15 Examples of various types of constraints.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
32
Planning the Preliminary Investigation (Cont.)
Step 3 – Perform fact-finding
Gather data about project usability, costs, benefits, and schedules
Analyze organization charts, conduct interviews, review documentation, observe operations, and conduct a user survey
Analyze the data
Pareto chart
XY chart (scatter diagram)
33
Preliminary Investigation Overview (Cont. 6)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
33
34
Preliminary Investigation Overview (Cont. 7)
FIGURE 2-17 A Pareto chart displays the causes of a problem, in priority order, so an analyst can tackle the most important causes first. In this example, the part number issue would be the obvious starting point.
FIGURE 2-18 An XY chart shows correlation between variables, which is very important in problem solving. Conversely, a lack of correlation suggests that the variables are independent, and that you should look elsewhere for the cause.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
34
Planning the Preliminary Investigation (Cont.)
Step 4 – Analyze project usability, cost, benefit, and schedule data
Factors to consider
What information must be obtained, and how will it be gathered and analyzed?
Who will conduct the interviews? How many people will be interviewed?
Will a survey be conducted? Who will be involved? How much time will it take to tabulate the results?
How much will it cost to analyze the information and prepare a report with findings and recommendations?
35
Preliminary Investigation Overview (Cont. 8)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
35
Planning the Preliminary Investigation (Cont.)
Step 5 – Evaluate feasibility
Operational feasibility
Technical feasibility
Economic feasibility
Schedule feasibility
Step 6 – Present results and recommendations to management
Prepare a report that includes:
An evaluation of the systems request
An estimate of costs and benefits
A case for action
36
Preliminary Investigation Overview (Cont. 9)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
36
Planning the Preliminary Investigation (Cont.)
Format of a report
Introduction
Systems request summary
Findings
Recommendations
Project roles
Time and costs estimates
Expected benefits
Appendix
37
Preliminary Investigation Overview (Cont. 10)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
37
38
Chapter Summary
Systems planning is the first phase of the systems development life cycle
A business case should:
Describe the project clearly
Provide the justification to proceed
Estimate the project’s financial impact
Factors that affect systems projects
User requests, top management directives, existing systems, the IT department, software and hardware vendors, technology, customers, competitors, the economy, and government
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
38
Analysts evaluate the systems request and determine whether the project is feasible from an operational, technical, economic, and schedule standpoint
Steps in the preliminary investigation
Understand the problem or opportunity
Define the project scope and constraints
Perform fact-finding and analyze project usability, cost, benefit, and schedule data
Evaluate feasibility and present results and recommendations to management
39
Chapter Summary (Cont.)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
39
Chapter 5: Data and Process Modeling
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Chapter Objectives
Describe data and process modeling concepts and tools, including data flow diagrams, a data dictionary, and process descriptions
Describe the symbols used in data flow diagrams and explain the rules for their use
Draw data flow diagrams in a sequence, from general to specific
3
Chapter Objectives
Explain how to level and balance a set of data flow diagrams
Describe how a data dictionary is used and what it contains
Use process description tools, including structured English, decision tables, and decision trees
Describe the relationship between logical and physical models
4
Introduction
Logical Model: Shows what the system must do, regardless of how it will be implemented physically
Physical Model: Describes how the system will be constructed
5
6
Overview of Data and Process Modeling Tools
Systems analysts use graphical techniques to describe an information system
Data flow diagram (DFD) – Uses various symbols to show how the system transforms input data into useful information
6
7
Data Flow Diagrams
A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps
A set of DFDs provides a logical model that shows what the system does, not how it does it
7
8
Data Flow Diagrams (Cont. 1)
DFD Symbols
Four basic symbols represent processes, data flows, data stores, and entities
Gane and Sarson: Used in data
flow diagrams
Processes, data flows,
data stores, and external
entities all have a unique symbol
Yourdon: Used in data flow
diagrams
Processes, data flows, data stores, and external entities each have a unique symbol
FIGURE 5-1 Data flow diagram symbols, symbol names, and examples of the Gane and Sarson and Yourdon symbol sets
8
9
Data Flow Diagrams (Cont. 2)
Process Symbol
Must have at least one input and at least one output
Contains business logic that transforms the data
Process name identifies its function (verb)
Examples” : “apply rent payment” or “calculate commission
In DFDs, a process symbol can be referred to as a black box
9
10
Data Flow Diagrams (Cont. 3)
Data Flow Symbol
Represents one or more data items
The symbol for a data flow is a line with a single or double arrowhead
FIGURE 5-3 Examples of correct combinations of data flow and process symbols
10
Data Flow Symbol
Following data flow and process combinations must be avoided
Spontaneous generation
Black holes
Gray holes
11
Data Flow Diagrams (Cont. 4)
FIGURE 5-4 Examples of incorrect combinations of data flow and process symbols. APPLY INSURANCE PREMIUM has no input and is called a spontaneous generation process. CALCULATE GROSS PAY has no outputs and is called a black hole process. CALCULATE GRADE has an input that is obviously unable to produce the output. This process is called a gray hole
11
12
Data Flow Diagrams (Cont. 5)
Data Store symbol
Represent data that the system stores
A DFD does not show the detailed contents of a data store — the specific structure and data elements are defined in the data dictionary
A data store must be connected to a process with a data flow
12
13
Data Flow Diagrams (Cont. 6)
FIGURE 5-5 Examples of correct uses of data store symbols in a data flow diagram
FIGURE 5-6 Examples of incorrect uses of data store symbols: Two data stores cannot be connected by a data flow without an intervening process, and each data store should have an outgoing and incoming data flow
13
14
Data Flow Diagrams (Cont. 7)
Entity Symbol
Shows how the system interfaces with the outside world
A DFD shows only external entities that provide data to the system or receive output from the system
DFD entities also are called terminators because they are data origins or final destinations
Each entity must be connected to a process by a data flow
14
15
Data Flow Diagrams (Cont. 8)
FIGURE 5-7 Examples of correct uses of external entities in a data flow diagram
FIGURE 5-8 Examples of incorrect uses of external entities. An external entity must be connected by a data flow to a process, and not directly to a data store or to another external entity
15
16
Data Flow Diagrams (Cont. 9)
FIGURE 5-9 Examples of correct and incorrect uses of data flows
Keep in mind:
All flow lines must be labeled
Large processes can be broken down into smaller components
16
17
Creating a Set of DFDs
Create a graphical model of the information system based on your fact-finding results
First, you will review a set of guidelines for drawing DFDs
Then you will learn how to apply these guidelines and create a set of DFDs using a three-step process
17
18
Creating a Set of DFDs (Cont. 1)
Guidelines for Drawing DFDs
Draw the context diagram so that it fits on one page
Use the name of the information system as the process name in the context diagram
Use unique names within each set of symbols
Do not cross lines
Provide a unique name and reference number for each process
Ensure that the model is accurate, easy to understand, and meets the needs of its users
18
19
Creating a Set of DFDs (Cont.2)
FIGURE 5-10 Context diagram DFD for grading system
Step 1: Draw a Context Diagram
20
Creating a Set of DFDs (Cont. 3)
FIGURE 5-11 Context diagram DFD for an order system
20
Step 2: Draw a Diagram 0 DFD
If same data flows in both directions, you can use a double-headed arrow
Diagram 0 is an exploded view of process 0
Parent diagram
Child diagram
Functional primitive
21
Creating a Set of DFDs (Cont. 4)
FIGURE 5-13 Diagram 0 DFD for the order system
21
Step 3: Draw the Lower Level Diagrams
22
Creating a Set of DFDs (Cont. 5)
FIGURE 5-14 Diagram 1 DFD shows details of the FILLORDER process in the order system
22
Must use leveling and balancing techniques
Leveling examples
Uses a series of increasingly detailed DFDs to describe an information
system
Exploding, partitioning, or decomposing
23
Creating a Set of DFDs (Cont. 6)
FIGURE 5-15 This diagram does not show the symbols that connect to data flows entering or leaving FILL ORDER on the context diagram
23
24
Creating a Set of DFDs (Cont. 7)
FIGURE 5-16 The order system diagram 0 is shown at the top of the figure, and exploded diagram 3 DFD (for the APPLY PAYMENT process) is shown at the bottom. The two DFDs are balanced because the child diagram at the bottom has the same input and output flows as the parent process 3 shown at the top
24
25
Creating a Set of DFDs (Cont. 8)
FIGURE 5-18 In the next level of detail, the process 0 black box reveals three processes, two data stores, and four internal data flows — all of which are shown inside the dashed line
FIGURE 5-17 Example of a parent DFD diagram, showing process 0 as a black box
25
26
Data Dictionary
A data dictionary, or data repository, is a central storehouse of information about a system’s data
An analyst uses the data dictionary to collect, document, and organize specific facts about a system
Defines and describes all data elements and meaningful combinations of data elements
26
27
Data Dictionary (Cont. 1)
Data element: Smallest piece of data that has meaning within an information system
Called data item or field
Are combined into records, also called data structures
Record: Meaningful combination of related data elements that is included in a data flow or retained in a data store
Called data structures
27
28
Data Dictionary (Cont. 2)
Using CASE Tools for Documentation
More complex the system, more difficult it is to maintain full and accurate documentation
Modern CASE tools simplify the task
A CASE repository ensures data consistency
28
29
Data Dictionary (Cont. 3)
Documenting the Data Elements
Every data element in the data dictionary should be documented
Objective – To provide clear, comprehensive information about the data and processes that make up a system
29
Documenting the Data Elements
Data element name and label
Alias
Type and length
Default value
Acceptable values – Domain and validity rules
Source
Security
Responsible user(s)
Description and comments
30
Data Dictionary (Cont. 4)
FIGURE 5-20 A Visible Analyst screen describes the data element named SOCIAL SECURITY NUMBER.
Source: Visible Systems Corporation.
30
Documenting the Data Flows
Data flow name or label
Description
Alternate name(s)
Origin
Destination
Record
Volume and frequency
31
Data Dictionary (Cont. 5)
31
32
Data Dictionary (Cont. 6)
Documenting the Data Stores
Data store name or label
Description
Alternate name(s)
Attributes
Volume and frequency
FIGURE 5-21 Visible Analyst screen that documents a
data store named IN STOCK
Source: Visible Systems Corporation.
32
Documenting the Processes
Process name or label
Description
Process number
Process description
33
Data Dictionary (Cont. 7)
FIGURE 5-22 Visible Analyst screen that describes a
process named VERIFY ORDER
Source: Visible Systems Corporation.
33
Documenting the Entities – Data dictionary describes all external entities that interact with the system
Characteristics include
Entity name
Description
Alternate name(s)
Input data flows
Output data flows
34
Data Dictionary (Cont. 8)
34
35
Data Dictionary (Cont. 9)
Documenting the Records
Record or data structure name
Definition or description
Alternate name(s)
Attributes
FIGURE 5-23 Visible Analyst screen that documents a
record, or data structure named CREDIT STATUS
Source: Visible Systems Corporation.
35
Data Dictionary Reports – Following can be obtained
Alphabetized list of all data elements by name
Report describing each data element and indicating the user or department that is responsible for data entry, updating, or deletion
Report of all data flows and data stores that use a particular data element
Detailed reports showing all characteristics of data elements, records, data flows, processes, or any other selected item stored in the data
36
Data Dictionary (Cont. 10)
36
37
Process Description Tools
Process description: Documents the details of a functional primitive and represents a specific set of processing steps and business logic
Tools – structured English, decision tables, and decision trees
Used in object-oriented development
O-O analysis – combines data and the processes that act on the data into things called objects, and similar objects can be grouped together into classes
O-O processes are called methods
37
38
Process Description Tools (Cont. 1)
Modular Design
Based on combinations of three logical structures, sometimes called control structures, which serve as building blocks for the process
Sequence
Selection
Iteration – looping
FIGURE 5-26 Iteration structure
FIGURE 5-25 Selection structure
FIGURE 5-24 Sequence structure
38
39
Process Description Tools (Cont. 2)
Structured English
Rules
Use only the three building blocks of sequence, selection, and iteration
Use indentation for readability
Use a limited vocabulary
standard terms used in the data dictionary
Specific words that describe the processing rules
FIGURE 5-27 The VERIFY ORDER process description
includes logical rules and a structured English version of
the policy. Notice the alignment and indentation of the
logic statements
Source: Visible Systems Corporation.
39
40
Process Description Tools (Cont. 3)
Decision Tables
Show a logical structure, with all possible combinations of conditions and resulting actions
Every possible outcome should be considered to ensure that nothing has been overlooked
Number of rules doubles each time a condition is added
Can have more than two possible outcomes
Are the best way to describe a complex set of conditions
40
41
Process Description Tools (Cont. 4)
FIGURE 5-29 Example of a simple decision table showing the processing logic of the VERIFY ORDER process
FIGURE 5-28 The Verify Order business process has two conditions. For an order to be accepted, the product must be in stock and the customer must have an acceptable credit status
41
42
Process Description Tools (Cont. 5)
FIGURE 5-31This table is based on the Verify Order conditions shown in Figure 5-30. With three conditions, there are eight possible combinations, or rules
FIGURE 5-30 A third condition has been added to the Verify Order business process. For an order to be accepted, the product must be in stock and the customer must have an acceptable credit status. However, the credit manager now has the authority to waive the credit status requirement
42
43
Process Description Tools (Cont. 6)
FIGURE 5-32 In the first table, dashes have been added to indicate that a condition is not relevant. In the second version, rules have been combined. Notice that in final version, only four rules remain. These rules document the logic, and will be transformed into program code when the system is developed
43
44
Process Description Tools (Cont. 7)
FIGURE 5-34 This decision table is based on the sales promotion policy in Figure 5-33. This is the initial version of the table, before simplification
FIGURE 5-33 A sales promotion policy with three conditions. Notice that the first statement contains two separate conditions – one for the 5% discount, and another for the additional discount
44
45
Process Description Tools (Cont. 8)
FIGURE 5-35 In this version, dashes have been added to indicate that a condition is not relevant. At this point, it appears that several rules can be combined
45
46
Process Description Tools (Cont. 9)
FIGURE 5-36 This example is based on the same Sales Promotion Policy shown in the decision tables in Figures 5-34 and 5-35 on the previous page. Like a decision table, a decision tree shows all combinations of conditions and outcomes. The main difference is the graphical format, which many viewers find easier to interpret
Decision Trees
Graphical representation of the conditions, actions, and rules found in a decision table
Show the logic structure in a horizontal form that resembles a tree
Provide the same results as decision tables, but in different forms
46
47
Logical versus Physical Models
While structured analysis tools are used to develop a logical model for a new information system, such tools also can be used to develop physical models of an information system
A physical model shows how the system’s requirements are implemented
47
48
Logical versus Physical Models (Cont. 1)
Sequence of Models
Systems analysts create a physical model of the current system and then develop a logical model of the current system before tackling a logical model of the new system
Performing extra step allows to understand the current system better
48
49
Logical versus Physical Models (Cont. 2)
Four-Model Approach
Develop:
A physical model of the current system
A logical model of the current system
A logical model of the new system
A physical model of the new system
Disadvantage – Additional time and cost
49
50
Chapter Summary
During data and process modeling, a systems analyst develops graphical models to show how the system transforms data into useful information
The end product of data and process modeling is a logical model that will support business operations and meet user needs
Data and process modeling involves three main tools: data flow diagrams, a data dictionary, and process descriptions
50
Data flow diagrams (DFDs) graphically show the movement and transformation of data in the information system
DFDs use four symbols
A set of DFDs is like a pyramid with the context diagram at the top
The data dictionary is the central documentation tool for structured analysis
51
Chapter Summary (Cont. 1)
51
Each functional primitive process is documented using structured English, decision tables, and decision trees
Structured analysis tools can be used to develop a logical model during one systems analysis phase, and a physical model during the systems design phase
52
Chapter Summary (Cont. 2)
52
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
53
53
Chapter 7:Development Strategies
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Learning Objectives
Describe the concept of Software as a Service
Define Web 2.0 and cloud computing
Explain software acquisition alternatives, including traditional and Web-based software development strategies
Describe software outsourcing options, including offshore outsourcing and the role of service providers
3
Learning Objectives
Explain advantages and disadvantages of in-house software development
Discuss cost-benefit analysis and financial analysis tools
Describe a request for proposal (RFP) and a request for quotation (RFQ)
Describe the system requirements document
Explain the transition from systems analysis to systems design
4
5
Development Strategies Overview
Earlier, certain work functions in the company required:
Development of software by in-house efforts
Employing the services of external entities
Today, organizations have following choices for software acquisition
Application service providers
Web-hosted software options
Firms that offer enterprise-wide software solutions
Selecting the best development path is an important decision
Today
5
6
The Impact of the Internet
Software as a Service (SaaS)
Software deployment model that hosts an application as a service provided to customers over the Internet
Reduces the customer’s need for software maintenance, operation, and support
6
Traditional vs. Web-Based Systems Development
Service-oriented architecture (SOA)
A way of engineering systems in which reusable business functionality is provided by services through well-defined interfaces
Technically, not software architecture but an architectural style
7
The Impact of the Internet (Cont.1)
7
Traditional vs. Web-Based Systems Development
Traditional Development
System design is influenced by compatibility issues
Systems are designed to run on local and wide-area networks
Systems often utilize Internet links and resources
Development typically follows one of three main paths:
In-house development
Purchase of a software package with possible modification
Use of outside consultants
Scalability is affected by network limitations and constraints
8
The Impact of the Internet (Cont.2)
8
Traditional vs. Web-Based Systems Development (Cont.)
Web-Based Development
Systems are developed and delivered on an Internet-based framework
Treats the Web as the platform rather than just a communication channel
Web-based systems are easily scalable and can run on multiple hardware environments
Used for customer relationship management, order processing, and materials management
Treats software applications as services that are less dependent on desktop computing power and resources
9
The Impact of the Internet (Cont.3)
9
Traditional vs. Web-Based Systems Development (Cont.)
Web-Based Development
Requires additional layers, called middleware, to communicate with existing software and legacy systems
Middleware: Connects dissimilar applications and enables them to communicate and exchange data
Open more complex security issues that should be addressed
10
The Impact of the Internet (Cont.4)
10
Evolving Trends – Web 2.0, Cloud Computing, and Mobile Devices
Web 2.0: second generation of the web that enables people to collaborate, interact, and share information much more effectively
Enhances interactive experiences
Cloud computing: Online software in which applications and services are accessed and used through an Internet connection
Mobile devices: Smartphones, tablets, and other computing devices that are not permanently tethered to a desk
11
The Impact of the Internet (Cont.5)
11
12
Outsourcing
Transfer of information systems development, operation, or maintenance to an outside firm
The Growth of Outsourcing
Service provider: Offers outsourcing solutions Application service provider (ASP)
Delivers a software application or access to an application by charging a usage or subscription fee
Internet business services (IBS)
Also called managed hosting
Provide web-based support for transactions
12
Outsourcing Fees
Fixed fee model: Uses a set fee based on a specified level of service and user support
Subscription model: Has a variable fee based on the number of users or workstations that have access to the application
Usage model or transaction model: Charges a variable fee based on the volume of transactions or operations performed by the application
13
Outsourcing (Cont.1)
13
Outsourcing Issues and Concerns
Mission-critical IT systems are outsourced if the result is a cost-attractive and reliable business solution
Overseas outsourcing can raise issues with control, culture communication, and security
Reviewing the outsourcing firm’s history and financial condition is vital
Outsourcing clients can be affected by mergers and acquisitions
Employee job security is a major concern
14
Outsourcing (Cont.2)
14
Offshore Outsourcing
Called global outsourcing
Shifting IT development, support, and operations to other countries
Reason – Lower bottom-line costs
Risks and concerns
Impact on the economy
Project control
Security issues
15
Outsourcing (Cont.3)
15
16
In-House Software Development Options
Software development options
Develop own systems
Purchase, possibly customize, and implement a software package
Most important consideration is the total cost of ownership (TCO)
Companies can develop user applications based on commercial software packages
16
In-House Software Development Options (Cont.1)
Make or Buy Decision
Refers to the choice between developing and purchasing
A company’s IT department makes, builds, and develops in-house software
A software
package is
obtained from
a vendor or
application
service provider
17
FIGURE 7-8 Instead of outsourcing, a company can choose to develop a system in-house, or purchase and possibly customize a commercial package.
17
Make or Buy Decision (cont.)
Software package: Obtained from a vendor or application service provider
Software vendors: Develop software for sale
Value-added reseller (VAR): Enhances a commercial package by adding custom features and configuring it for a particular industry
Horizontal application: Can be used by many different types of organizations
Vertical application: Developed to handle information requirements for a specific type of business
18
In-House Software Development Options (Cont.2)
18
In-House Software Development Options (Cont.3)
19
FIGURE 7-10 Companies consider various factors when comparing in-house development with the purchase of a software package.
19
Developing Software In-House
Satisfies unique business requirements
Not possible with standard commercial software packages
Minimizes changes in business procedures and policies
Installing a new software package almost always requires some degree of change in how a company does business
Meets constraints of existing systems
Any new software installed must work with existing systems
20
In-House Software Development Options (Cont.4)
20
Developing Software In-House (Cont.)
Meets constraints of existing technology
The new system must work with existing hardware and legacy systems
Develops internal resources and capabilities
Companies can develop and train IT staff who understand the organization’s business functions and information support needs
21
In-House Software Development Options (Cont.5)
21
Purchasing a Software Package
Lower costs
A software package is less expensive than the one developed in-house
Requires less time to implement
Packages have already been designed, programmed, tested, and documented
Proven reliability and performance benchmarks
Major problems would have been detected and corrected by the vendor
22
In-House Software Development Options (Cont.6)
22
Purchasing a Software Package (Cont.)
Requires less technical development staff
Companies can reduce the number of programmers and systems analysts on the IT staff
Future upgrades provided by the vendor
Improvements and enhancements are included in regular updates
Input from other companies
Users in other companies can be contacted to obtain their input and opinions
23
In-House Software Development Options (Cont.7)
23
Customizing a Software Package
Purchase a basic package that vendors will customize to suit project requirements
Negotiate directly with the software vendor to make enhancements to meet project needs by paying for the changes
Purchase the package and make project-specific modifications
Ensure modifications are permissible under the terms of the software license
24
In-House Software Development Options (Cont.8)
24
Creating User Applications
User application: Utilizes standard business software
User interface: Enables effective interaction with the application
Service desk or information center (IC): Provides user support
Screen generators and report generators: Allow users to design their own data entry forms and reports
Appropriate controls must be provided to ensure data security and integrity
25
In-House Software Development Options (Cont.9)
25
26
In-House Software Development Options (Cont.10)
Figure 7-11 Microsoft Access includes Form Wizard and a Report Wizard tools that ask a series of questions and then create the form or report.
Source: Screenshots used with permission from Microsoft
27
The Systems Analyst’s Role
Based on decisions taken by the organization in the systems development process
Current and future needs are considered
Evaluation and selection of alternatives is a complicated process
Forecasting actual costs is difficult
Evaluation and selection team: Selects hardware and software, includes systems analysts and users
Ensures that critical factors are not overlooked and that a sound choice is made
27
28
Analyzing Cost and Benefits
Financial Analysis Tools
Payback analysis
Determines the time taken for an information system to pay for itself through reduced costs and increased benefits
Return on investment (ROI)
Percentage rate that compares the total net benefits (the return) received from a project to the total costs (the investment) of the project
Net present value (NPV)
Total value of the benefits minus the total value of the costs
28
29
Analyzing Cost and Benefits (Cont. 1)
Figure 7-12 In this example, the HP interactive TCO calculator is used to determine the ROI of migrating to an Infrastructure-as-a-Service (IaaS) environment in the cloud from a traditional server environment
Source: Hewlett-Packard Development Company, L.P.
Cost-Benefit Analysis Checklist
List each development strategy being considered
Identify all costs and benefits for each alternative
Consider future growth and the need for scalability
Include support costs for hardware and software
Analyze various software licensing options
Apply the financial analysis tools to each alternative
Study the results and prepare a report
30
Analyzing Cost and Benefits(Cont. 2)
30
31
The Software Acquisition Process
Step 1 – Evaluate the Information System Requirements
Identify key features
Consider network and Web-related issues
Estimate volume and future growth
Specify hardware, software, or personnel constraints
Prepare a request for proposal or quotation
Request for proposal (RFP): Describes the company, lists the IT services or products needed, and specifies the features required
Request for quotation (RFQ): more specific than an RFP
31
The Software Acquisition Process (Cont.1)
32
FIGURE 7-13 Volume estimates for an order processing system showing current activity levels and two forecasts: one based on the existing order processing procedures and another that assumes a new Web site is operational.
32
The Software Acquisition Process (Cont.2)
33
FIGURE 7-15 The three vendors have the same initial ratings, but the two evaluation models produce different results. In the unweighted model at the top of the figure, vendor A has the highest total points. However, after applying weight factors, vendor C is the winner, as shown in the model at the bottom of the figure.
33
Step 2 – Identify Potential Vendors or Outsourcing Options
The Internet contains information on all major products and acquisition services
The organization can avail the services of a consulting firm that help companies select software packages
Online forums or newsgroups provide opinions and ideas
Google Groups
Yahoo Groups
34
The Software Acquisition Process (Cont.3)
34
Step 3 – Evaluate the Alternatives
Existing users
Provide feedback about their experiences
Application testing
Users in the organization may be able to test the product
Benchmarking
Benchmark: Measures the time a package takes to process a certain number of transactions
Each package is matched against RFP features and the choices are ranked
35
The Software Acquisition Process (Cont.4)
35
Step 4 – Perform Cost-Benefit Analysis
Identify and calculate total cost of ownership (TCO) for each option being considered
Study the conditions of use that come along with the software license
If a software package is purchased, consider a supplemental maintenance agreement
36
The Software Acquisition Process (Cont.5)
36
Step 5 – Prepare a Recommendation
Evaluate and describe alternatives along with:
Costs
Benefits
Advantages
Disadvantages
Submit a formal system requirements document and deliver a presentation
37
The Software Acquisition Process (Cont.6)
37
Step 6 – Implement the Solution
Implementation tasks will depend on the solution selected
Before the new software becomes operational, complete all implementation steps
Loading
Configuring and testing the software
Training users
Converting data files to the new system’s format
38
The Software Acquisition Process (Cont.7)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
38
39
Completion of Systems Analysis Tasks
System Requirements Document
Called software requirements specification
Contains the requirements for the new system
Describes the alternatives considered
Makes a specific recommendation to management
Similar to a contract
Identifies items that system developers must deliver to users
Format and organize the systems document
Easy to read and use
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
39
Presentation to Management
Helps take key decisions that affect the future development of the system
Suggestions for effective presentations
Start with a brief overview
Summarize the primary viable alternatives
Explain why the evaluation and selection team chose the recommended alternative
Allow time for discussion
Obtain a final decision from management or agree on a timetable for the next step in the process
40
Completion of Systems Analysis Tasks (Cont.1)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
40
Presentation to Management (Cont.)
Depending on management’s decision, a systems analyst will do one of the following
Implement an outsourcing alternative
Develop an in-house system
Purchase or customize a software package
Perform additional systems analysis work
Stop all further work
Post presentation and management decision, the project begins a transition to the systems phase of the SDLC
41
Completion of Systems Analysis Tasks (Cont.2)
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
41
42
Transition to System Design
Preparing for Systems Design
Systems design requires accurate documentation
Provide detailed specifications for output, input, data, processes, and other requirements
Logical and Physical Design
Logical design: Defines what must take place
Physical design: Describes the actual process of entering, verifying, and storing data
Logical and physical designs are closely related
Accurate systems analysis is required
42
43
Chapter Summary
A new trend views Software as a Service (SaaS), rather than a product
Traditional systems must:
Function in various hardware and software environments
Be compatible with legacy systems
Operate within the constraints of company networks and desktop computing capability
Companies that choose to handle their own software development needs can:
Create in-house systems
Commercially purchase software packages
43
The systems analyst’s role in the software development process depends on the specific development strategy
The most important factor in choosing a development strategy is total cost of ownership (TCO)
Financial analysis tools include:
Payback analysis
Return on investment (ROI)
Net present value (NPV)
44
Chapter Summary (Cont. 1)
44
Acquiring software involves a series of specific steps
The system requirements document is the deliverable, or end product, of the systems analysis phase
45
Chapter Summary (Cont.2)
45
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
46
46
Chapter 9 – Data Design
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Prescribed text
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Prescribed reading
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Chapter Objectives
Explain file-oriented systems and how they differ from database management systems
Explain data design terminology, including entities, fields, common fields, records, files, tables, and key fields
Describe data relationships, draw an entity- relationship diagram, define cardinality, and use cardinality notation
3
Icon courtesy: https
://www.iconfinder.com/icons/3999982/database_development_platform_service_software_web_icon
Chapter Objectives
Explain the concept of normalization
Explain the importance of codes and describe various coding schemes
Explain data warehousing and data mining
Differentiate between logical and physical storage and records
Explain data control measures
4
Icon courtesy: https
://www.iconfinder.com/icons/3999982/database_development_platform_service_software_web_icon
Data Design Concepts
Data Structures
Framework for organizing, storing, and managing data
Comprises of files or tables that interact in various ways
Each file or table contains data about people, places, things, or events
5
Icon courtesy: https
://www.iconfinder.com/icons/3999982/database_development_platform_service_software_web_icon
Mario and Danica – A Data Design Example
Mario and Danica – A Data Design Example
Mario’s auto shop uses file-oriented systems
MECHANIC SYSTEM uses the MECHANIC file to store data about shop employees
JOB SYSTEM uses the JOB file to store data about work performed at the shop
Danica’s auto shop uses a relational model
SHOP OPERATIONS SYSTEM – Tables are linked by a common field named Mechanic No field
6
Icon courtesy: https
://www.iconfinder.com/icons/3999982/database_development_platform_service_software_web_icon
Mario and Danica – A Data Design Example
7
Mario’s Auto Shop
FIGURE 9-2 Mario’s shop uses two separate systems, so certain data must be entered twice. This redundancy is inefficient and can produce data errors.
Danica’s Auto Shop
FIGURE 9-4 Danica’s SHOP OPERATIONS SYSTEM uses a database design, which avoids duplication. The data can be viewed as if it were one large table, regardless of where the data is stored physically.
Data Design Concepts
Is File Processing Still Important?
Used by some companies to handle large volumes of structured data on a regular basis
Cost-effective in certain situations
8
FIGURE 9-4 A credit card company that posts thousands of daily transactions might consider a file processing option.
Data Design Concepts
The Database Environment
Database management system (DBMS): Collection of tools, features, and interfaces that enables users to add, update, manage, access, and analyze data
DBMS advantages
Scalability – System can be expanded, modified, or downsized
Economy of scale
Database design allows better utilization of hardware
9
Figure 9-5 In this example, a sales database can
support four separate business systems.
Data Design Concepts
Enterprise-wide application
A database administrator (DBA) assesses overall requirements and maintains the database
Stronger standards
Standards for data names, formats, and documentation are followed uniformly throughout the organization
Better security
Only legitimate users can access the database
Different users have different levels of access
Data independence
Systems that interact with a DBMS are relatively independent of how physical data is maintained
10
Icon courtesy: https://www.processmap.com/solutions/sustainability-performance-management/
DBMS Components
Interfaces for Users, Database Administrators, and Related Systems
Users
Work with predefined queries and switchboard commands
Use query languages to access stored data
Database administrators
Responsible for DBMS
management and support
Related information systems
DBMS provides support to related information systems
11
FIGURE 9-6 In addition to interfaces or users, database administrators, and related information systems, a DBMS also has a data manipulation language, a schema and subschemas, and a physical data repository.
DBMS Components
Data Manipulation Language (DML)
Controls database operations
Schema
Descriptions of all fields, tables, and relationships
Subschema: Portions of the database that a particular system or user needs or is allowed to access
Physical Data Repository
Contains the schema and subschemas
Can be centralized or distributed at several locations
Uses open database connectivity (ODBC)-compliant software that enables communication among the systems and DBMSs
12
Icon courtesy: https://itsoftware.com.co/content/que-es-una-base-de-datos/
Web-Based Data Design
Connecting to the Web
Databases are created and managed by using languages and commands that have nothing to do with HTML
Objective – To connect the database to the Web and enable data to be viewed and updated
Middleware is used integrate different applications and allow them to exchange data
Data Security
Web-based data must be secure, yet easily accessible to authorized users
13
Icon courtesy: https://support.office.com/en-us/article/use-the-azure-diagrams-template-efbb25e7-c80e-42e1-b1ad-7ef630ff01b7
Web-Based Data Design
14
FIGURE 9-8 A Web-based design characteristics include global access, ease of use, multiple platforms, cost effectiveness, security issues, and adaptability issues. In a Web-based design, the Internet serves as the front end, or interface, for the database management system. Access to the database requires only a Web browser and an Internet connection.
Web-Based Data Design
15
FIGURE 9-9 When a client workstation requests a Web page (1), the Web server uses middleware to generate a data query to the database server (2). The database server responds (3), and middleware translates the retrieved data into an HTML page that can be sent by the Web server and displayed by the user’s browser (4).
Data Design Terms
Definitions
Entity – Person, place, thing, or event for which data is collected and maintained
Table or file: Contains a set of related records that store data about a specific entity
Field (attribute) – Single characteristic or fact about an entity
Common field: Attribute that appears in more than one entity
Tuple (record): Set of related fields that describes one instance, or occurrence, of an entity
16
Icon courtesy: https://stackoverflow.com/questions/39060709/changes-of-product-price-in-database-design
Data Design Terms
Key Fields
Primary key: Field or combination of fields that uniquely and minimally identifies a particular member of an entity
Called a combination key
Candidate key: Any field that could serve as a primary key
Foreign key: Field in one table that must match a primary key value in another table for a relationship between the two tables to exist
Secondary key: Field or combination of fields that can be used to access or retrieve records
17
Icon courtesy: https://stackoverflow.com/questions/39060709/changes-of-product-price-in-database-design
Data Design Terms
Referential Integrity
Set of rules that avoids data inconsistency and quality problems
18
FIGURE 9-11 Microsoft Access allows a user to specify that referential integrity rules will be enforced in a relational database design.
Entity-Relationship Diagrams
Drawing an ERD
List the entities that were identified during the systems analysis phase
Consider the nature of the relationships that link them
19
FIGURE 9-12 In an entity-relationship diagram, entities are labeled with singular nouns and relationships are labeled with verbs. The relationship is interpreted as a simple English sentence.
Entity-Relationship Diagrams
Types of Relationships
One-to-one relationship: Exists when exactly one of the second entity occurs for each instance of the first entity
Abbreviated 1:1
20
FIGURE 9-13 Examples of one-to-one (1:1) relationships.
Entity-Relationship Diagrams
One-to-many relationship: Exists when one occurrence of the first entity can relate to many instances of the second entity
Each instance of the second entity can associate with only one instance of the first entity
Abbreviated 1:M
21
FIGURE 9-14 Examples of one-to-many (1:M) relationships.
Entity-Relationship Diagrams
Many-to-many relationship
Exists when one instance of the first entity can relate to many instances of the second entity, and vice versa
Abbreviated M:N
22
FIGURE 9-15 Examples of many-to-many (M:N) relationships. Notice that the event or transaction that links the two entities is an associative entity with its own set of attributes and characteristics
Entity-Relationship Diagrams
23
FIGURE 9-16 An entity-relationship diagram for SALES REP, CUSTOMER, ORDER, PRODUCT, and WAREHOUSE. Notice that the ORDER and PRODUCT entities are joined by an associative entity named ORDER LINE.
Entity-Relationship Diagrams
Cardinality
Describes the numeric relationship between two entities
Shows how instances of one entity relate to instances of another entity
Crow’s foot notation indicates various possibilities using circles, bars, and symbols
24
FIGURE 9-17 Crow’s foot notation is a common method of indicating cardinality. The four examples show how you can use various symbols to describe the relationships between entities.
Entity-Relationship Diagrams
25
FIGURE 9-18 In the first example of cardinality notation, one and only one CUSTOMER can place anywhere from zero to many of the ORDER entity. In the second example, one and only one ORDER can include one ITEM ORDERED or many. In the third example, one and only one EMPLOYEE can have one SPOUSE or none. In the fourth example, one EMPLOYEE, or many employees, or none, can be assigned to one PROJECT, or many projects, or none.
Entity-Relationship Diagrams
26
FIGURE 9-19 An ERD for a library system drawn with Visible Analyst. Notice that crow’s foot notation has been used and relationships are described in both directions.
Data Normalization
Normalization: Process of creating table designs by assigning specific fields or attributes to each table in the database
Table design: Specifies fields
Identifies the primary key in a particular table or file
Stages in a normalization process
Un-normalized design
First normal form
Second normal form
Third normal form
27
Icon courtesy: http://www.c-jump.com/bcc/common/Talk/SQL/SQL_50_Joins/SQL_50_Joins.html
Data Normalization
Standard Notation Format
Used to show a table’s structure, fields, and primary key
The primary key field(s) is underlined
NAME (FIELD 1, FIELD 2, FIELD 3)
Recognition of repeating group fields is important
Repeating group: Set of one or more fields that can occur any number of times in a single record
Each occurrence would possess different values
28
Icon courtesy: https://stackoverflow.com/questions/1671607/er-diagram-drawing
Data Control
A well-designed DBMS must provide built-in control and security features
Forms of data protection
Providing limited access to files and databases
Use of user ID and password, permissions and encryption
Backup copies of databases must be retained for a specified period of time
Recovery procedures can be used to restore the file or database
Maintain audit log files and audit fields
29
Icon courtesy: https://www.plutustree.com/data-management-icon/
Data Control
A well-designed DBMS must provide built-in control and security features
Forms of data protection
Providing limited access to files and databases
Use of user ID and password, permissions and encryption
Backup copies of databases must be retained for a specified period of time
Recovery procedures can be used to restore the file or database
Maintain audit log files and audit fields
30
Icon courtesy: https://www.plutustree.com/data-management-icon/
Chapter Summary
A database consists of linked tables that form an overall data structure
DBMS enable users to add, update, manage, access, and analyze data in a database
DBMS designs are more powerful and flexible than traditional file-oriented systems
Components include interfaces for users, database administrators, and related systems
In an information system, an entity is a person, place, thing, or event for which data is collected and maintained
31
Icon courtesy:
https://www.venturetechsolutions.com/it-infrastructure/backup-strategies/lg-icon-it-infrastructure-db-admin/
Chapter Summary
Key fields include primary keys, candidate keys, foreign keys, and secondary keys
An entity-relationship diagram (ERD) is a graphic representation of all system entities and the relationships among them
Relationship between two entities is referred to as cardinality
Normalization is a process for avoiding problems in data design
A code is a set of letters or numbers used to represent data in a system
32
Icon courtesy:
https://www.venturetechsolutions.com/it-infrastructure/backup-strategies/lg-icon-it-infrastructure-db-admin/
Chapter Summary
Logical storage is information seen through a user’s eyes, regardless of how or where that information actually is organized or stored
File and database control measures includes:
limiting access to the data
data encryption
backup/recovery procedures
audit-trail files, and
internal audit fields
33
Icon courtesy:
https://www.venturetechsolutions.com/it-infrastructure/backup-strategies/lg-icon-it-infrastructure-db-admin/
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
34
34
Chapter 6: Object Modeling
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Prescribed text
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Prescribed reading
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Learning Objectives
Explain how object-oriented analysis can be used to describe an information system
Define object modeling terms and concepts, including objects, attributes, methods, messages, classes, and instances
Explain relationships among objects and the concept of inheritance
Draw an object relationship diagram
3
Learning Objectives (cont.…)
Describe Unified Modeling Language (UML) tools and techniques including use cases, use case diagrams, class diagrams, sequence diagrams, state transition diagrams, and activity diagrams
Explain the advantages of using CASE tools in developing the object model
Explain how to organize an object model
4
5
Overview of Object-Oriented Analysis (Cont.1)
Object-Oriented Terms and Concepts
Unified modeling language (UML)
Method of visualizing and documenting an information system
Attributes: Characteristics that describe an object
Methods: Tasks or functions that the object performs
Message: Command to perform a specific function
A class is a group of similar objects
Instance: Specific member of a class
5
Objects
Represented as a rectangle
The object name is at the top, followed by the object’s attributes and methods
6
Overview of Object-Oriented Analysis (Cont.2)
FIGURE 6-1 Objects have attributes, can send and receive messages, and perform actions called methods.
6
7
Overview of Object-Oriented Analysis (Cont.3)
FIGURE 6-2 The PARENT object includes four attributes and two methods. Mary Smith, Ahmed Ali, and Anthony Greene are instances of the PARENT object.
8
Overview of Object-Oriented Analysis (Cont.4)
FIGURE 6-3 The CHILD object includes five attributes and five methods. James Smith, Amelia Ali, and Misty Greene are instances of the CHILD object.
8
Attributes
Describe the characteristics of an object
The number of attributes required depends on:
Business requirements of the information system
Requirements of users
Attributes of an object are defined during the system development process
Objects possess a state
State: Describes the object’s current status
9
Overview of Object-Oriented Analysis (Cont.5)
9
Methods
Specific tasks that an object can perform
Identify functions performed
Describe the functions performed
10
Overview of Object-Oriented Analysis (Cont.6)
FIGURE 6-4 The MORE FRIES method requires the server to perform seven specific steps.
10
Message
A command that tells an object to perform a certain method
Polymorphism: Concept that a message gives different meanings to different objects
11
Overview of Object-Oriented Analysis (Cont.7)
FIGURE 6-5 In an example of polymorphism, the message GOOD NIGHT produces different results, depending on which object receives it.
11
Message (cont.)
A message to the object triggers changes within the object without specifying how the changes must be carried out
An object can be viewed as black box
Encapsulation: Idea that all data and methods are self-contained, as in a black box
12
Overview of Object-Oriented Analysis (Cont.8)
Figure 6-6 In a school information system, an INSTRUCTOR object sends an ENTER GRADE message to an instance of the STUDENT RECORD class.
Classes
An object belongs to a group or category called a class
All objects within a class share common attributes and methods
Subclasses: Categories within a class
Super-class: A class belonging to a general category
13
Overview of Object-Oriented Analysis (Cont.9)
13
14
Overview of Object-Oriented Analysis (Cont.10)
FIGURE 6-7 The VEHICLE class includes common attributes and methods. CAR, TRUCK, MINIVAN, and SCHOOL BUS are instances of the VEHICLE class.
14
15
Overview of Object-Oriented Analysis (Cont.11)
FIGURE 6-9 At the fitness center, the PERSON superclass includes common attributes and methods. EMPLOYEE is a class within the PERSON superclass. INSTRUCTOR is a subclass within the EMPLOYEE class.
15
16
Relationships Among Objects and Classes
Relationships
Enable objects to communicate and interact as they perform business functions and transactions
Describe what objects need to know about each other
Inheritance
The strongest relationship
Enables an object to derive one or more of its attributes from another object
16
17
Relationships Among Objects and Classes (Cont.1)
FIGURE 6-10 An inheritance relationship exists between the INSTRUCTOR and EMPLOYEE objects. The INSTRUCTOR (child) object inherits characteristics from the EMPLOYEE (parent) class and can have additional attributes of its own.
17
Object Relationship Diagram
Displays objects and how they interact to perform business functions and transactions
18
Relationships Among Objects and Classes (Cont.2)
FIGURE 6-11 Object relationship diagram for the fitness center.
18
19
Object Modeling with the Unified Modeling Language
UML uses a set of symbols to represent graphically the various components and relationships within a system
Use Case Modeling
Use case: Represents the steps in a specific business function or process
An external entity, called an actor, initiates a use case by requesting the system to perform a function or process
19
20
Object Modeling with the Unified Modeling Language (Cont.1)
Use Case Modeling (Cont.)
UML symbol for a use case is an oval with a label that describes the action or event
The actor is shown as a stick figure, with a label that identifies the actor’s role
Use case description: Documents the name of the use case, the actor, a description of the use case
Provides a step-by-step list of the tasks and other key descriptions and assumptions
FIGURE 6-12 In a medical office system, a PATIENT
(actor) can MAKE APPOINTMENT (use case).
Use case description: Documents the name of the use case, the actor, a description of the use case, a step-by-step list of the tasks required for successful completion, and other key descriptions and assumptions
20
21
Object Modeling with the Unified Modeling Language (Cont.2)
FIGURE 6-13 When a student adds a class, PRODUCE FITNESS-CLASS ROSTER uses the results of ADD CLASS to generate a new class roster. When an instructor changes his or her availability, UPDATE INSTRUCTOR INFORMATION uses the CHANGE AVAILABILITY use case to update the instructor’s information.
21
22
Object Modeling with the Unified Modeling Language (Cont.3)
FIGURE 6-14 The ADD NEW STUDENT use case description documents the process used to add a current student into an existing class.
22
Use Case Diagrams
A visual summary of several related use cases within a system or subsystem
The first step is to identify the system boundary which is represented by a rectangle
System boundary: Shows what is included in the system (inside the rectangle) and what is not included in the system (outside the rectangle)
23
Object Modeling with the Unified Modeling Language (Cont.4)
23
24
Object Modeling with the Unified Modeling Language (Cont.5)
FIGURE 6-16 A use case diagram to handle work at an auto service department.
24
Class Diagrams
Show the object classes and relationships involved in a use case
Each class appears as a rectangle, with the class name at the top, followed by the class’s attributes and methods
Lines show relationships between classes and have labels identifying the action that relates the two classes
Includes a concept called cardinality
Cardinality: Describes how instances of one class relate to instances of another class
25
Object Modeling with the Unified Modeling Language (Cont.6)
25
26
Object Modeling with the Unified Modeling Language (Cont.7)
FIGURE 6-17 Examples of UML notations that indicate the nature of the relationship between instances of one class and instances of another class.
26
27
Object Modeling with the Unified Modeling Language (Cont.8)
FIGURE 6-18 Class diagram for a sales order use case (attributes and methods omitted for clarity).
27
Sequence Diagrams
Dynamic model of a use case, showing the interaction among classes during a specified time period
Graphically document the use case by showing the classes, the messages, and the timing of the messages
Include symbols that represent classes, lifelines, messages, and focuses
28
Object Modeling with the Unified Modeling Language (Cont.9)
28
Sequence Diagrams (Cont.)
Classes
Send or receive messages
Shown at the top of the sequence diagram
Lifelines
Represent the time during which the object above it is able to interact with the other objects in the use case
An X marks the end of the lifeline
Messages
Include additional information about the contents
Focuses
Indicate when an object sends or receives message
29
Object Modeling with the Unified Modeling Language (Cont.10)
29
30
Object Modeling with the Unified Modeling Language (Cont.11)
FIGURE 6-19 A sequence diagram with two classes. Notice the X that indicates the end of the CLASS 2 lifeline. Also notice that each message is represented by a line with a label that describes the message, and that each class has a focus that shows the period when messages are sent or received
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
30
31
Object Modeling with the Unified Modeling Language (Cont.12)
FIGURE 6-20 The sequence diagram for the ADD NEW STUDENT use case. The use case description for ADD NEW STUDENT is shown in Figure 6 14.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
31
State Transition Diagrams
Show how an object changes from one state to another, depending on events that affect the object
All possible states must be documented in the state transition diagram
States appear as rounded rectangles with the state names inside
32
Object Modeling with the Unified Modeling Language (Cont.13)
FIGURE 6-21 An example of a state transition diagram for a bank account.
Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
32
Activity Diagrams
Show actions and events as they occur
Show the order in which the actions take place and identify the outcomes
33
Object Modeling with the Unified Modeling Language (Cont.14)
FIGURE 6-22 An activity diagram shows the actions and events involved in withdrawing cash from an ATM.
33
Business Process Modeling (BPM)
Represents the people, events, and interaction in a system
Can be used anytime during the systems development process
Compatible with object modeling
34
Object Modeling with the Unified Modeling Language (Cont.15)
34
35
Object Modeling with the Unified Modeling Language (Cont.16)
FIGURE 6-23 The Bizagi Modeler tool supports business modeling and simulation using the standard BPM notation.
Source: bizagi.com
35
CASE Tools
Provide an overall framework for documenting the system components
Object modeling requires many types of diagrams to represent proposed systems
CASE tools speed up the process
Ensure consistency and provide common links
Once objects are described and used in one part of the design, they can be reused multiple times without further effort
36
Object Modeling with the Unified Modeling Language (Cont.)
36
37
Organizing the Object Model
Develop an object relationship diagram that provides an overview of the system
Support each diagram or object definition with clear and relevant documentation that can be accessed easily
Organize use cases and use case diagrams so they can be linked to the appropriate class, state transition, sequence, and activity diagrams
Maintain accuracy
37
38
Chapter Summary
Object modeling is a popular technique that describes a system in terms of objects
Object-oriented terms include classes, attributes, instances, messages, and methods
Objects can send messages, or commands, that require other objects to perform certain methods, or tasks
38
The Unified Modeling Language (UML) is a widely used method of visualizing and documenting an information system
Use case describes a business situation initiated by an actor, who interacts with the information system
At the end of the object modeling process, the use cases and use case diagrams are organized and class, sequence, state transition, and activity diagrams are created
39
Chapter Summary (Cont.)
39
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
40
40
Chapter 10 – System Architecture
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Prescribed text
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Prescribed reading
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Chapter Objectives
Provide a checklist of issues to consider when selecting a system architecture
Trace the evolution of system architecture from mainframes to current designs
Explain client/server architecture, including tiers, cost-benefit issues, and performance
Compare in-house ecommerce development with packaged solutions and service providers
3
Chapter Objectives cont.….
Discuss the impact of cloud computing and Web 2.0
Define network topology, including hierarchical, bus, ring, star, and mesh models
Describe wireless networking, including wireless standards, topologies, and trends
Describe the system design specification
4
Architecture Checklist
Issues that influence the architecture choice
Corporate organization and culture
Enterprise resource planning (ERP)
Initial and total cost of ownership (TCO)
Scalability
Web integration
Legacy system interface requirements
Processing options
Security issues
Corporate portals
5
Architecture Checklist
Corporate Organization and Culture
A successful system performs well in a company’s organization and culture
Enterprise resource planning (ERP)
Objective – To establish a company-wide strategy for using IT that includes:
a specific architecture
standards for data
Processing
network, and
user interface design
6
FIGURE 10-1 Oracle offers ERP solutions as a cloud-based service.
Source: Oracle
Architecture Checklist
Companies are extending internal ERP systems to their suppliers and customers, using supply chain management (SCM)
Initial Cost and TCO
TCO includes tangible purchases, fees, and contracts called hard costs
TCO analysis answers questions about the validity, effectiveness, and new trends in systems planning
May affect the initial cost and TCO for a proposed system
7
Architecture Checklist
Scalability (Extensibility)
A system’s ability to expand, change, or downsize easily to meet the changing needs of a business enterprise
Web Integration
A web-centric architecture enables a company to integrate new applications into its ecommerce strategy
Legacy Systems
A new system might have to interface with legacy systems
Involves analysis of data formats and compatibility
8
System Architecture: Then and Now
Functions of a business information system
Manage applications that perform the processing logic
Handle data storage and access
Provide an interface that allows users to interact with the system
While planning system design:
Determine where the functions will be carried out
Identify the advantages and disadvantages of each design approach
9
System Architecture: Then and Now
Mainframe Architecture
Server: A computer that supplies data, processing services or other support to one or more computers called clients
Earliest servers – Mainframe computers
All data input and output occurred at a central location
Advances in technology enabled installation of terminals at remote locations
10
FIGURE 10-3 In a centralized design, the remote user’s keystrokes are transmitted to the mainframe, which responds by sending screen output back to the user’s screen.
System Architecture: Then and Now
Impact of the Personal Computer
Individuals could work in stand-alone mode
The workstation performed all the functions of a server
Lesser IT assistance resulted in increased productivity in certain tasks
Absence of a central storage location raised concerns about data security, integrity, and consistency
Network Evolution
Local area network (LAN): Allows sharing of data and hardware resources
Wide area network (WAN): Spans long distances and can connect LANs that are continents apart
11
System Architecture: Then and Now
12
FIGURE 10-4 A LAN allows sharing of data and hardware, such as printers and scanners.
FIGURE 10-5 A WAN can connect many LANs and link users who are continents apart.
Client/Server Designs
Client/Server Architecture
Includes systems that divide processing between one or more networked clients and a central server
Client handles the entire user interface
Server stores data and provides data access and database management functions
13
FIGURE 10-6 In a client/server design, data is stored and usually processed on the server.
Client/Server Designs
14
FIGURE 10-7 Comparison of the characteristics of client/server and mainframe systems.
Client/Server Designs
The Client’s Role
Client/server relationship must specify how the processing will be divided between the client and the server
Fat client (thick client) design: Locates all or most of the application processing logic at the client
Thin client design: Locates all or most of the processing logic at the server
Provides better performance as the program code resides on the server
15
Client/Server Designs
Client/Server Tiers
Two-tier design
User interface resides on the client
Data resides on the server
Application logic can run either on the server or on the client, or be divided between the client and the server
Three-tier (n-tier) design
User interface runs on the client
Data is stored on the server
Has a middle layer between the client and server
Processes the client requests and translates them into data access commands
Considered an application server
16
Client/Server Designs
17
FIGURE 10-8 Characteristics of two-tier versus three-tier client/server design.
Client/Server Designs
18
FIGURE 10-9 The location of the data, the application logic, and the user interface depend on the type of architecture.
Client/Server Designs
Middleware
Enables communication between the tiers
Referred to as glueware
Used to connect two or more software components in a federated system architecture
Integrates legacy systems and Web-based and/or cloud applications
Represents the slash in the term client/server
Cost-Benefit Issues
Client/server systems offer the best combination of features to meet information system requirements
19
Client/Server Designs
Enable firms to scale the system according to the environment
Enable transfer of applications from expensive mainframes to less-expensive client platforms
Reduce workload and improve response times
Performance Issues
Knee of the curve
Response time to requests increases significantly as the system nears its capacity
Client should contact the server only when necessary in a client/server system
Distributed database management system (DDBMS) helps improve client/server performance
20
The Impact of the Internet
In an Internet-based architecture, the entire user interface is provided by the web server in the form of HTML documents
Shifting the responsibility for the interface from the client to the server simplifies data transmission and results in lower hardware cost and complexity
21
The Impact of the Internet
Cloud Computing
The concept envisions a cloud of remote computers providing a total online software and data environment that is hosted by third parties
Eliminates compatibility issues and provides scaling on demand
22
FIGURE 10-10 Cloud computing
The Impact of the Internet
Web 2.0
Second generation of the web
Enables people to collaborate, interact, and share information more dynamically
Considered a step towards the semantic web
Wiki: Web-based repository of information
Run by social collaboration
Users collaborate and add new layers of information to the Internet operating system
23
Ecommerce Architecture
In-House Solutions
Benefits
A unique website, with a look and feel consistent with the company’s other marketing efforts
Complete control over the organization of the site
A scalable structure to handle increases in sales and product offerings in the future
More flexibility to modify and manage the site
The opportunity to integrate the firm’s web-based business systems with its other information systems
24
Ecommerce Architecture
25
FIGURE 10-11 Guidelines for companies developing ecommerce strategies.
Ecommerce Architecture
Packaged Solutions
Viable alternative for medium- to large-sized firms
Less complex than an in-house effort
Service Providers
Application service provider (ASP) – Provides applications or access to applications by charging a fee
Many ASPs offer full-scale Internet business services for companies that decide to outsource functions
26
Network Models
The Open Systems Interconnection (OSI) Model
Describes how data moves from an application on one computer to an application on another networked computer
Provides physical design standards that assure seamless network connectivity, regardless of the specific hardware environment
27
Network Models
Network Topology
Topology – Physical or logical view of the network
Physical topology: Actual network cabling and connections
Logical topology: Describes the way the components interact
Hierarchical network
Departmental servers control lower levels of processing and network devices
Bus network
A single communication path connects the central server, departmental servers, workstations, and peripheral devices
28
Network Models
Ring network
Resembles a circle where the data flows in only one direction from one device to the next
Star network
Has a central networking device called a switch which manages the network and acts as a communications conduit for all network traffic
Mesh network
Each node connects to every other node
29
Figure 10-15 Although these computers form a physical circle, the physical layout has no bearing on the network topology, which might be a bus, ring, star, or other logical design.
Network Models
30
FIGURE 10-16 A hierarchical network with a single server that controls the network.
Network Models
31
FIGURE 10-18 A ring network with a set of computers that send and receive data flowing in one direction.
FIGURE 10-17 A bus network with all devices connected to a single communication path.
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
32
32
Kent Institute Australia Pty. Ltd.
Assessment Brief ABN 49 003 577 302 CRICOS Code: 00161E RTO Code: 90458
Version 2: 11th October, 2019 Page 1 of 3 TEQSA Provider Number: PRV12051
ASSESSMENT BRIEF
COURSE: Bachelor of Business (Information Systems Specialisation)
Unit Code: SYAD 310
Unit Title: Systems Analysis and Design
Type of Assessment: Assessment 3 – Content Analysis (Reflective Journal)
Length/Duration: 3,000 words
Unit Learning Outcomes
addressed:
1. Able to apply iterative incremental systems software development processes
2. Describe and apply iterative incremental systems software development
processes, such as structured, object-oriented and agile approaches
5. Evaluate and choose appropriate software designs to compose the design of
an information system
7. Understand and communicate business requirements and information
system designs effectively
Submission Date: Week 14
Assessment Task:
Students are required to analyse the weekly lecture material of weeks 1 to 11
and create concise content analysis summaries of the theoretical concepts
contained in the course lecture slides.
Total Mark: 50 Marks
Weighting: 50% of total unit marks
Students are advised that submission of an Assessment Task past the due date without a formally
signed approved Assignment Extension Form (Kent Website MyKent Student Link> FORM – Assignment
Extension Application Form – Student Login Required) or previously approved application for other
extenuating circumstances impacting course of study, incurs a 5% penalty per calendar day,
calculated by deduction from the total mark.
For example. An Assessment Task marked out of 40 will incur a 2 mark penalty for each calendar day.
More information, please refer to (Kent Website MyKent Student Link> POLICY – Assessment Policy &
Procedures – Student Login Required)
https://kentinstituteaustralia.sharepoint.com/sites/Policies%26Forms/SitePages/Home.aspx?RootFolder=%2Fsites%2FPolicies%26Forms%2FPolicies%20and%20Forms%2FStudent&FolderCTID=0x012000E6C01ECDB12ACE448B94EB84A9F93758&View=%7B148054E0%2D0936%2D4517%2D8B3E%2DD0CCDC7CD88F%7D
https://kentinstituteaustralia.sharepoint.com/sites/Policies%26Forms/SitePages/Home.aspx?RootFolder=%2Fsites%2FPolicies%26Forms%2FPolicies%20and%20Forms%2FStudent&FolderCTID=0x012000E6C01ECDB12ACE448B94EB84A9F93758&View=%7B148054E0%2D0936%2D4517%2D8B3E%2DD0CCDC7CD88F%7D
Kent Institute Australia Pty. Ltd.
Assessment Brief ABN 49 003 577 302 CRICOS Code: 00161E RTO Code: 90458
Version 2: 11th October, 2019 Page 2 of 3 TEQSA Provider Number: PRV12051
ASSESSMENT DESCRIPTION:
Students are required to analyse the weekly lecture material of weeks 1 to 11 and create concise content
analysis summaries of the theoretical concepts contained in the course lecture slides.
Where the lab content or information contained in technical articles from the Internet or books helps to fully
describe the lecture slide content, discussion of such theoretical articles or discussion of the lab material should
be included in the content analysis.
The document structure is as follows (3000 Words):
1. Title Page
2. Introduction (100 words)
3. Background (100 words)
4. Content analysis (reflective journals) for each week from 1 to 11 (2750 words; 250 words per week): a.
Theoretical Discussion
i. Important topics covered
ii. Definitions
b. Interpretations of the contents
i. What are the most important/useful/relevant information about the content? c.
Outcome
i. What have I learned from this?
5. Conclusion (50 words)
Your report must include:
• At least five references, out of which, three references must be from academic resources.
• Harvard Australian referencing for any sources you use.
• Refer to the Academic Learning Skills student guide on Referencing.
ASSESSMENT SUBMISSION:
The assignment must be submitted online in Moodle. Where additional documents need to be attached, all
materials MUST be submitted electronically in Microsoft Word format. Other formats (e.g., pdf or MAC file) may
not be readable by markers. Please be aware that any assessments submitted in other formats will be considered
LATE and will lose marks until it is presented in MS Word. No paper based or hardcopy submission will be accepted.
GENERAL NOTES FOR ASSESSMENT TASKS
Content for Assessment Task papers should incorporate a formal introduction, main points and conclusion.
Appropriate academic writing and referencing are inevitable academic skills that you must develop and
demonstrate in work being presented for assessment. The content of high quality work presented by a student
must be fully referenced within-text citations and a Reference List at the end. Kent strongly recommends you
refer to the Academic Learning Support Workshop materials available on the Kent Learning Management System
(Moodle). For details please click the link http://moodle.kent.edu.au/kentmoodle/mod/folder/view.php?id=3606
and download the file titled “Harvard Referencing Workbook”. This Moodle Site is the location for Workbooks
and information that are presented to Kent Students in the ALS Workshops conducted at the beginning of each
Trimester.
Kent recommends a minimum of FIVE (5) references in work being presented for assessment. Unless otherwise
specifically instructed by your Lecturer or as detailed in the Unit Outline for the specific Assessment Task, any
paper with less than five (5) references may be deemed not meeting a satisfactory standard and possibly be failed.
Content in Assessment tasks that includes sources that are not properly referenced according to the “Harvard
Referencing Workbook” will be penalised.
http://moodle.kent.edu.au/kentmoodle/mod/folder/view.php?id=3606
Kent Institute Australia Pty. Ltd.
Assessment Brief ABN 49 003 577 302 CRICOS Code: 00161E RTO Code: 90458
Version 2: 11th October, 2019 Page 3 of 3 TEQSA Provider Number: PRV12051
Marks will be deducted for failure to adhere to the word count if this is specifically stated for the Assessment Task
in the Unit Outline. As a general rule there is an allowable discretionary variance to the word count in that it is
generally accepted that a student may go over or under by 10% than the stated length.
GENERAL NOTES FOR REFERENCING
References are assessed for their quality. Students should draw on quality academic sources, such as books,
chapters from edited books, journals etc. The textbook for the Unit of study can be used as a reference, but not
the Lecturer Notes. The Assessor will want to see evidence that a student is capable of conducting their own
research. Also, in order to help Assessors determine a student’s understanding of the work they cite, all in-text
references (not just direct quotes) must include the specific page number(s) if shown in the original. Before
preparing your Assessment Task or own contribution, please review this ‘YouTube’ video (Avoiding Plagiarism
through Referencing) by clicking on the following link: link:
http://moodle.kent.edu.au/kentmoodle/mod/folder/view.php?id=3606
A search for peer-reviewed journal articles may also assist students. These type of journal articles can be located
in the online journal databases and can be accessed from the Kent Library homepage. Wikipedia, online
dictionaries and online encyclopaedias are acceptable as a starting point to gain knowledge about a topic, but
should not be over-used – these should constitute no more than 10% of your total list of references/sources.
Additional information and literature can be used where these are produced by legitimate sources, such as
government departments, research institutes such as the National Health and Medical Research Council (NHMRC),
or international organisations such as the World Health Organisation (WHO). Legitimate organisations and
government departments produce peer reviewed reports and articles and are therefore very useful and mostly
very current. The content of the following link explains why it is not acceptable to use non-peer reviewed websites
(Why can’t I just Google?): https://www.youtube.com/watch?v=N39mnu1Pkgw
(thank you to La Trobe University for access to this video).
MARKING GUIDE (RUBRIC):
Your answers for the final examination questions will be assessed as per the following marking criteria. Please
read carefully each section/level and marks weightage.
Marking Criteria Marks
Content precisely presented based on references. 40 Marks
Presentation (Layout, no grammatical errors, reads well, etc.) 5 Marks
Cited references 5 Marks
Total marks for content analysis assignment 50 Marks
http://moodle.kent.edu.au/kentmoodle/mod/folder/view.php?id=3606
https://www.youtube.com/watch?v=N39mnu1Pkgw
http://www.youtube.com/watch?v=hqjJyqfceLw
Chapter 1: Introduction to Systems Analysis and Design
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Learning Objectives
Describe the impact of information technology
Define systems analysis and design and the role of a systems analyst
Define an information system and describe its components
Explain how to use business profiles and models
Explain Internet business strategies and relationships, including B2C and B2B
3
Learning Objectives cont.…
Identify various types of information systems and explain who uses them
Distinguish among structured analysis, object-oriented analysis, and agile methods
Explain the waterfall model, and how it has evolved
Discuss the role of the information technology department and the systems analysts who work there
4
Introduction
Information helps companies:
Increase productivity
Deliver quality products and services
Maintain customer loyalty
Make sound decisions
Use of information technology is vital for organizational success
5
FIGURE 1-1 These headlines show the enormous impact of information technology on our lives.
What Is Information Technology?
Information Technology (IT)
Combination of hardware, software and services
Used:
to manage
To Access
To communicate, and
To share information
6
FIGURE 1-2 An employee clocking in with a punch card in 1953.
ClassicStock.com/Superstock
What Is Information Technology? Cont.….
Changing Nature of Information Technology
Change is dramatic and continuous
Advances influence change in business organizations
7
FIGURE 1-2 An employee clocking in with a punch card in 1953.
ClassicStock.com/Superstock
Systems Analysis and Design
Systems Analysis and Design is a Step-by-step process for developing high-quality information systems
Then what is an Information systems?
An Information Systems is a combination of:
Technology
people, and
data to perform certain business functions
8
What Does a Systems Analyst Do?
Plans, develops, and maintains information systems
Manages IT projects, including tasks, resources, schedules, and costs
Conducts meetings, delivers presentations, and writes memos, reports, and documentation
9
Information system components
A System is a set of related
components that produces
specific results
A Mission-critical systems are
vital to a company’s operations
For example, an order processing system
10
Figure source: https
://www.iconfinder.com/icons/374556/cogwheel_configuration_control_equipment_gears_options_preferences_process_setting_settings_system_tool_tools_upload_work_icon
Information system components
All systems require input data
For example, a computer receives data when a key is pressed
Data consist of Basic facts
Information is Data, transformed into output that is valuable to the users
11
Figure Source: https
://www.fastcompany.com/3066288/how-facebooks-home-grown-data-centers-serve-billions-of-users-now-and-in-the-f
Information system components
An information system has five key components:
Hardware
Software
Data
Processes and
people
12
FIGURE 1-5 An information
system needs these components.
Information System Components
Hardware
Physical layer of the information system
Moore’s Law was integral to the development of hardware
Software
Controls hardware
System software
Application software
Horizontal system
Vertical system
Legacy system
13
FIGURE 1-6 Server farms provide the enormous power and speed that modern IT systems need.
dotshock/Shutterstock.com
Information System Components
Data
Stored in tables
Processes
Describe the tasks and
business functions performed to achieve specific results
People
Stakeholders: Individuals interested in an information system
14
FIGURE 1-7 In a typical payroll system, data is stored in separate tables that are linked to form an overall database.
Business Today
Influenced by:
Rapidly increasing globalization
Technology integration for seamless information access
Rapid growth of cloud-based computing and services
All trends are Internet-centric
15
Business Today
The Internet Model
Ecommerce (electronic commerce)
User interface – Enables communication between a data-base management software and a web-based server
Mobile devices interact with the system using apps
Sectors
B2C (business-to-customer)
B2B (business-to-business)
16
Business Today
B2C (Business-to-Customer)
In a single convenient session, customers can:
Do research and compare prices and features
Check availability and arrange delivery
Choose payment methods
B2B (Business-to-Business)
Ecommerce was initially carried out using electronic data interchange (EDI)
Most firms use supply chain management (SCM) software, which helps businesses manage inventory levels, costs, alternate suppliers
17
Modeling Business Operations
Business Profile
Overview of a company’s mission, functions, organization, products, services, customers, suppliers, competitors, constraints, and future direction
Business Process
Specific set of transactions, events, and results that can be described and documented
Business process model (BPM)
Business process modeling notation (BPMN)
18
Modeling Business Operations
19
FIGURE 1-8 A simple business model might consist of an event, three processes, and a result.
FIGURE 1-9 This sample uses business process modeling notation (BPMN) to represent the same events, processes, and workflow shown in Figure 1-8.
Source: Drawio.com
Business Information Systems
Current Method
All employees use office productivity systems
Operations users require decision support systems
Systems are defined by their functions and features
Enterprise Computing
Supports company-wide operations and data management requirements
Enterprise resource planning (ERP) systems provide cost-effective support for users and managers throughout the company
20
Business Information Systems
Transaction Processing (TP) Systems
Processes data generated by day-to-day business operations
Examples – Customer order processing, accounts receivable, and warranty claim processing
Business Support Systems
Provide job-related information support to users at all levels of a company
Can work hand-in-hand with a TP system
21
FIGURE 1-11 A single sales transaction consists of six separate tasks, which the TP system processes as a group.
Business Information Systems
Management Information Systems (MIS)
Radio frequency identification (RFID)
Uses high-frequency radio waves to track physical
objects
Knowledge Management
Uses a knowledge base and inference rules
Knowledge base: Large database that allows users to find information by entering keywords
Inference rules: Identify data patterns and relationships
22
FIGURE 1-12 With an RFID tag, items can be tracked and monitored throughout the shipping process.
© nullplus/photos.com
Business Information Systems
User Productivity Systems
Technology that improves productivity
Groupware: Enables data sharing and coordination of efforts
Systems Integration
Combination of transaction processing, business support, knowledge management, and user productivity features
23
What Information Do Users Need?
24
FIGURE 1-14 A typical organizational model identifies business functions and organizational levels.
What Information Do Users Need?
Top Managers
Use IT to develop long-range strategic plans
Require information such as economic forecasts, technology trends, competitive threats, and governmental issues
Middle Managers and Knowledge Workers
Middle managers provide direction, resources, and performance feedback to supervisors and team leaders
Require more detailed information than top managers
Knowledge workers provide support for the organization’s basic functions
25
What Information Do Users Need?
Supervisors and Team Leaders
Oversee operational employees and carry out day-to-day functions
Require decision support information, knowledge management systems, and user productivity systems
Operational Employees
Rely on TP systems to enter and receive data they need to perform their jobs
Empowered to handle tasks and make decisions that were assigned previously to supervisors
26
Systems Development Tools
Modeling
Graphical representation of a concept or process
Business model
Data model
Object model
Network model
Process model
27
FIGURE 1-15 Microsoft Visio allows you to drag and drop various symbols and connect them to show a business process.
Source: Microsoft Visio 2010
Systems Development Tools
Prototyping
Early working version of an information system
Disadvantage – Important decisions might be made before business or IT issues are thoroughly understood
A prototype based on careful fact-finding and modeling techniques can be an extremely valuable tool
28
Systems Development Tools
Computer-Aided Systems Engineering (CASE) Tools
Known as computer-aided software engineering
Provide an overall framework for systems development
Support design methodologies
Structured analysis
Object-oriented analysis
Generate program code
Speeds the implementation process
29
Systems Development Methods
30
Structured Analysis
Object-Oriented (O-O) Analysis
Agile/Adaptive Methods
Systems Development Methods
Structured Analysis
Time-tested and easy to understand
Uses the systems development life cycle (SDLC)
Based on predictive approach
Process-centered technique
Uses process models to graphically describe a system
31
FIGURE 1-18 This Visible Analyst screen shows a process model for a school registration system. The REGISTER STUDENTS process accepts input data from two sources and transforms it into output data.
Source: Visible Systems Corporation
Systems Development Methods
Addresses data organization and structure, relational database design, and user interface issues
The SDLC describes activities and functions that all systems developers perform, regardless of which approach they use
32
Systems Development Methods
FIGURE 1-19 Development phases and deliverables are shown in the waterfall model.
The circular symbols indicate interaction among the phases
33
Systems Development Methods
Steps in the SDLC Model
Systems planning
Initiated by a systems request
Goal – To perform a preliminary investigation
Feasibility study: Reviews anticipated costs and benefits and recommends a course of action
Systems analysis
Goal – To build a logical model of the new system
Requirements modeling: Analyst investigates business processes and documents the functions to be performed by the new system
Deliverable – System requirements document
34
Systems Development Methods
Systems design
Goal – To create a physical model that satisfies all documented requirements
User interface is designed and application architecture is determined
Outputs, inputs, and processes are identified
Deliverable – System design specification
Management and user involvement is critical
35
Systems Development Methods
Systems implementation
New system is constructed, programs are written, tested, and documented, and the system is installed
Deliverable – A completely functional and documented information system
Includes systems evaluation
Systems support and security
IT staff maintains, enhances, and protects the system
A well-designed system must be secure, reliable, maintainable, and scalable
36
Systems Development Methods
Object-Oriented Analysis
Combines data and the processes that act on the data into objects
Object: Member of a class, which possesses properties
O-O methodology provides easy transition to O-O programming languages like Java
37
FIGURE 1-20 The PERSON class includes INSTRUCTOR and STUDENT objects, which have their own properties and inherited
properties.
Systems Development Methods
FIGURE 1-21 In a typical O-O development model, planning, analysis, and design tasks interact continuously to generate prototypes that can be tested.
38
Systems Development Methods
Agile Methods
Involve building and constantly adjusting a series of prototypes to user requirements
Use a spiral model
Spiral model: Series of iterations based on user feedback
Feedback from prior steps is incorporated in each incremental step
Allow developers to be more flexible and responsive
39
Systems Development Methods
Disadvantages
Riskier than traditional methods
Weak documentation and blurred lines of accountability
Lack of emphasis on the larger business picture
Other Development Methods
Joint application development (JAD)
Focuses on team-based fact-finding
Rapid application development (RAD)
A compressed version of the entire development process
40
The Information Technology Department
41
FIGURE 1-23 Depending on its size, an IT department might have separate organizational units for these functions, or they might be combined into a smaller number of teams.
The Information Technology Department
Application Development
Systems are developed by teams consisting of users, managers, and IT staff members
Systems Support and Security
Provides vital protection and maintenance services
User Support
Provides users with technical information, training, and productivity support
Known as a help desk
42
The Information Technology Department
Database Administration
Involves data design, management, security, backup, and access systems
Network Administration
Includes hardware and software maintenance, support, and security
Web Support
Web support specialists design and construct Web pages
Monitor traffic and manage hardware and software
Link Web-based applications information systems to the company’s information systems
43
The Information Technology Department
Quality Assurance (QA)
QA team reviews and tests all applications and systems changes to verify specifications and software quality standards
44
The Systems Analyst
Investigates, analyzes, designs, develops, installs, evaluates, and maintains a company’s information systems
Constantly interacts with users and managers within and outside the organization
45
The Systems Analyst
Roles
Acts a translators to managers and programmers
A company’s best line of defense in an IT disaster
Most valuable skill – The ability to listen
Seeks feedback from users to ensure that systems do not deviate from accomplishing set objectives
Knowledge, Skills, and Education
Technical knowledge
Communication and business skills
Critical thinking skills
46
The Systems Analyst
Education – A college degree in information systems, science, or business
Some IT experience is required
Certification
Helps IT professionals learn new skills and gain recognition for their efforts
47
The Systems Analyst
Career Opportunities
Companies will need systems analysts to apply new information technology
Explosion in e-commerce will fuel IT job growth
Important factors:
Job titles
Company/organization
Company size
Salary, location and future Growth
Corporate culture
48
Trends in Information Technology
IT is one of the fastest evolving industries
Knowledge of current trends is vital to a systems analyst
Key trends:
Agile methods
Cloud computing
Mobile devices and apps
IT firms now offer a mix of products, services, and support
Social media
49
Chapter Summary
IT – Combination of hardware and software resources
Used by companies to manage, access, communicate, and share information
Essential components of an information system
Hardware, software, data, processes, and people
Successful companies offer a mix of products, technical and financial services, consulting, and customer support
50
Chapter Summary cont.….
Types of information systems
Enterprise computing systems, transaction processing systems, business support systems, knowledge management systems, or user productivity systems
Organization structure includes top managers, middle managers and knowledge workers, supervisors and team leaders, and operational employees
51
Chapter Summary cont.….
Systems analysts use modelling, prototyping, and computer-aided systems engineering (CASE) tools
Popular system development approaches
Structured analysis, object-oriented analysis, and agile methods
In addition to technical knowledge, a systems analyst must understand the business, think critically, and communicate effectively
52
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
53
53
Toolkit B – The Systems Analyst’s Toolkit CASE Tools
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Learning Objectives
Explain CASE tools and the concept of a CASE environment
Trace the history of CASE tools and their role in a fourth-generation environment
Define CASE terms and concepts, including a repository, modeling tools, documentation tools, engineering tools, and construction tools
3
Learning Objectives
Explain an integrated development environment (IDE) and application life cycle management (ALM) solutions
Provide examples of CASE tool features
Describe CASE tool trends, and how they relate to object-oriented analysis and agile methods
4
Overview of CASE Tools
Every type of work requires specific tools to do the job properly
Carpenters use hammers, drills, or screwdrivers
Chefs use measuring cups, knives, or spatulas
System development is no different
CASE tools reduce costs, speed up development, and provide comprehensive documentation for future maintenance or enhancements
5
Source: https
://ooprw-software-entwicklung.de/enterprise-architect/
Overview of CASE Tools
CASE Tools History
Traditional code was written in procedural programming languages such as COBOL
Modern languages are non-procedural or event driven programming languages
Make it easier to implement an object-oriented design
Fourth-generation language environment includes modern CASE tools
System developers can deliver high quality software, shorten the timetable, and reduce expense
6
Overview of CASE Tools
The Marketplace for CASE Tools
There is a wide variety of vendors and products
No one tool dominates the market
7
FIGURE B-2 Visual Paradigm offers a free UML diagramming tool.
Source: Visual Paradigm
Overview of CASE Tools
Selection of a CASE tool depends on:
The type of project
The size and scope of the project
Possible budgetary and time constraints
Preferences and experience of the system development team
8
CASE Terms and Concepts
Repository
Database that serves as a central storage location for all information about the system being developed
Once a data element has been defined in the repository, it can be accessed and used by processes and other information systems
9
CASE Terms and Concepts
FIGURE B-3 A Visible Analyst repository search for the data element named CUSTOMER NUMBER. The results will show all instances of the data element.
10
CASE Terms and Concepts
Individual Tools
Used to model, document, engineer, and construct the information system
Modeling tools
Unified Modeling Language diagrams and functional decomposition diagrams (Chapter 4)
Data flow diagrams (Chapter 5)
Object diagrams (Chapter 6)
Entity-relationship diagrams (Chapter 9)
Structure charts (Chapter 10)
11
CASE Terms and Concepts
Documentation tools
Used to check for inconsistent or incomplete information in forms, reports, and diagrams
Engineering tools
Forward engineering: Translating business processes into applications
Reverse engineering: Helps break down an existing application into diagrams, structure charts, and source code
12
CASE Terms and Concepts
Construction tools
Application generator (code generator): Used to develop computer programs rapidly by
translating a logical model directly into
code
13
FIGURE B-4 IBM Rational Rhapsody can generate source code from UML diagrams.
Source: IBM Corporation
CASE Terms and Concepts
Screen generator (form painter): Helps design a custom interface, create screen forms, and handle data entry format and procedures
Report generator (report writer): tool for designing formatted reports rapidly
14
FIGURE B-5 SAP Crystal Reports is a popular report generator that can display business analytics and support decision making.
Source: SAP SE
Development Environments
Mix of software tools, methods, and physical resources used to create an information system
Integrated Development Environment (IDE)
Uses built-in tools provided by the software vendor that make it easier to create applications based on their products
15
FIGURE B-8 Xcode is free IDE for all of
Apple’s platforms.
Source: Apple Inc.
Development Environments
Application Life Cycle Management Environment
Start-to-finish approach to planning, designing, developing, deploying, managing, and maintaining an information system
Part of product life cycle management (PLM)
16
FIGURE B-9 HP provides a full range of application lifecycle management software solutions.
Source: Hewlett Packard Enterprise Development LP.
Development Environments
FIGURE B-10 PLM encompasses numerous disciplines, and is broader than ALM.
Source: Florida Institute of Technology.
17
Development Environments
Pros and Cons of Integrated Development Tools
An integrated development tool is highly effective in a specific software environment as it is built into the vendor’s software package
Non-specific CASE tools such as Visible Analyst or Rational System Architect can be used in any development environment
Disadvantage – Each IDE is different
Requires a learning curve and skills that might or might not be readily transferable
18
CASE Tool Trends
New Products and Features
CASE tool vendors constantly offer more features and greater flexibility
Framework: Organizes and documents system development tasks
Helps transform business processes into an information system
Example – Zachman Framework
Microsoft Visio – Models networks, business processes, and diagrams
Cloud-based development environments
Example – Heroku platform
19
CASE Tool Trends
FIGURE B-11 The Zachman Framework in Visible Analyst provides an easy-to-follow matrix that helps system developers work on specific areas, and then integrate the results into an overall model.
Source: Visible Systems Corporation.
20
CASE Tool Trends
21
FIGURE B-12 Microsoft Visio can create many different types of diagrams.
Source: Microsoft Corporation.
CASE Tool Trends
22
FIGURE B-13 The Heroku platform in the cloud.
Source: Salesforce.com
CASE Tool Trends
Method-Specific CASE Tools
Each development approach has a set of tools that works especially well for that method
Structured development relies heavily on DFDs and structure charts
Object-oriented methods use diagrams, such as use case, class, sequence, and transition state diagrams
Agile methods use spiral or other iterative models
Structured analysis – Traditional approach that is time tested and easy to understand
23
CASE Tool Trends
Object oriented analysis and design (OOAD)
O-O CASE and UML-based modeling tools provide seamless development from planning to actual coding
Include modular design and reusable code
Agile methods
Agile developers use a wide range of modeling tools including CASE tools
CASE tools will continue to evolve and become more powerful
System developers may choose simpler, low-tech methods and techniques as modeling tools
24
Toolkit Summary
CASE stands for computer-aided systems engineering
CASE tools help design and construct information systems
Modern languages are non-procedural
Components of a fourth-generation environment
Repository is a database that serves as a central storage location for all information on the system being developed
Main source of system documentation
25
Toolkit Summary
Forward engineering means translating business processes and functions into applications
Reverse engineering helps examine and break down an existing application
IDE uses a built-in CASE tool included by vendors
Vendors are calling attention to ALM concepts and tools
Cloud-based toolsets will continue to grow in popularity
26
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
27
27
Chapter 8: User Interface
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Chapter Objectives
Explain the concept of user interface design and human-computer interaction, including basic principles of user-centered design
Explain how experienced interface designers perform their tasks
Describe rules for successful interface design
Discuss input and output technology issues
3
Chapter Objectives
Design effective source documents and forms
Explain printed output guidelines
Describe output and input controls and security
Explain modular design and prototyping techniques
4
5
Systems Design Phase Overview
Goal of systems design – To build a system that is effective, reliable, and maintainable
A system is:
Effective if it supports business requirements and meets user needs
Reliable if it handles input errors, processing errors, hardware failures, or human mistakes
Maintainable if it is flexible, scalable, and easily modified
5
Will It Succeed?
Suggestions for successful design
Think like a user
Carefully examine any point where users provide input or receive output
Anticipate future needs and provide flexibility
Anticipate possible expansion
Offer several alternatives
Manage data effectively
System should enter and verify data as soon as possible
Input data must be close to its source
A secure system must include audit trails
6
Systems Design Phase Overview (Cont.)
6
7
Chapter Overview
Users can design their own output
System designers are more aware of user needs and desires
Centralized IT departments no longer produce reams of printed reports
Customer-designed output is the current trend
The user interface has evolved
Most user information needs can be met with screen-generated data
Continues to evolve with the use of mobile and wearable devices
7
8
What Is a User Interface?
Describes how users interact with a computer system
Comprises features that affect two-way communications between the user and the computer
Central to usability
In a user-centered system, the distinction blurs between input, output, and the interface itself
FIGURE 8-2 Apple has long been a leader in creating elegant user interfaces for its products.
Source: Apple
8
Human-Computer Interaction (HCI)
Describes the relationship between computers and people who use them to perform their jobs
Early user interfaces – Complex commands and graphical user interface (GUI)
Transparent user interface: Does not distract the user
Objective – To create a user-friendly design that is easy to learn and use
9
What Is a User Interface?(Cont.)
Figure 8-3 HCI is essential to employee productivity, whether the work is done in a traditional office setting or on a construction site like the one shown in this figure.
Goodluz/Shutterstock.com
9
10
Seven Habits of Successful Interface Designers
Understand the Business
The interface designer must understand:
The underlying business functions
How the system supports individual, departmental, and enterprise goals
Maximize Graphical Effectiveness
A well-designed interface enables rapid learning
Think Like a User
The designer must see the system from a user’s perspective
10
Use Models and Prototypes
Designers can present initial screen designs to users in the form of a storyboard
Users should test the design and provide feedback
Focus on Usability
Include main options in the opening screen
Offer a reasonable number of choices that a user easily can comprehend
11
Seven Habits of Successful Interface Designers (Cont. 1)
FIGURE 8-5 The opening screen displays the main options for a student registration system. A user can click an option to see lower-level actions and menu choices.
11
Invite Feedback
Monitor system usage and solicit user suggestions
Determine if system features are being used as intended by observing and surveying users
Document Everything
Document all screen designs for later use by programmers
User-approved sketches and storyboards can be used to document the user interface
12
Seven Habits of Successful Interface Designers (Cont. 2)
12
13
Guidelines for User Interface Design
Create an Interface That Is Easy to Learn and Use
Focus on system design objectives
Create a design that is easy to understand and remember
Provide commands, actions, and system responses that are consistent and predictable
Allow users to correct errors easily
Clearly label all controls, buttons, and icons
13
Create an Interface That Is Easy to Learn and Use (Cont.)
Select familiar images that users can understand
Provide on-screen instructions that are logical, concise, and clear
Show all commands in a list of menu items
Dim any commands that are not available to the user
Make it easy to navigate or return to any level in the menu structure
14
Guidelines for User Interface Design (Cont. 1)
14
Enhance User Productivity
Organize tasks, commands, and functions in groups that resemble actual business operations
Create alphabetical menu lists or place the selections used frequently at the top of the menu list
Provide shortcuts for experienced users
Use default values if the majority of values in a field are the same
Use a duplicate value function, but allow users to turn this feature on or off as they prefer
15
Guidelines for User Interface Design (Cont. 2)
15
Enhance User Productivity (Cont.)
Provide a fast-find feature
If available, consider a natural language feature that allows users to type commands or requests in normal text phrases
Provide Users with Help and Feedback
Ensure that help is always available on demand
Provide user-selected help and context-
sensitive help
Provide a direct route for users to return
to the point from where help was requested
Include contact information
16
Guidelines for User Interface Design (Cont. 3)
16
Provide Users with Help and Feedback (Cont.)
Require user confirmation before data deletion
Provide an “Undo” key
When a user-entered command contains an error, highlight the erroneous part
Use hypertext links to assist users
Display messages at a logical place on the screen
Alert users to lengthy processing times or delays
Allow messages to remain on the screen long enough for users to read them
Let the user know whether the task or operation was successful or not
17
Guidelines for User Interface Design (Cont. 4)
17
18
Guidelines for User Interface Design (Cont. 5)
Figure 8-7 This menu hierarchy shows tasks, commands, and functions organized into logical groups and sequences. The structure resembles a functional decomposition diagram (FDD), which is a model of business functions and processes.
Figure 8-8 The main Help screen for a student registration system.
Provide Users with Help and Feedback (Cont.)
Provide a text explanation for an icon or image on a control button
Use messages that are specific, understandable, and professional
Create an Attractive Layout and Design
Use appropriate colors to highlight different areas of the screen
Use special effects sparingly
Use hyperlinks that allow users to navigate to related topics
Group related objects and information
19
Guidelines for User Interface Design (Cont. 6)
19
Create an Attractive Layout and Design (Cont.)
Display titles, messages, and instructions in a consistent manner
Ensure that commands and similar mouse actions will have the same effect
Require the user to confirm the entry by pressing Enter or Tab
Remember that users are accustomed to a pattern of red = stop, yellow = caution, and green = go
Provide a keystroke alternative for each menu command
Avoid complex terms and technical jargon
20
Guidelines for User Interface Design (Cont. 7)
20
Enhance the Interface
Opening screen is important as it introduces the application
The starting point can be a switchboard with well-
placed command buttons for navigation
Use a command button to initiate an action
Try to create customized menu bars and toolbars
Add a shortcut feature that lets a user select a menu command
If variable input data is needed, provide a dialog box that explains what is required
21
Guidelines for User Interface Design (Cont. 8)
21
Enhance the Interface (Cont.)
A toggle button makes it easy to show on or off status
Use list boxes that display the available choices
Use an option button, or a radio button, to control user choices
If check boxes are used to select one or more choices from a group, show the choices with a checkmark or an X
When dates must be entered, use a calendar control
22
Guidelines for User Interface Design (Cont. 9)
22
23
Guidelines for User Interface Design (Cont. 10)
FIGURE 8-10 A data entry screen for the student registration system. This screen uses several design features that are described in the text. When a user clicks the Find Student command button, a dialog box is displayed with instructions.
23
Focus on Data Entry Screens
Use the form filling method whenever possible
Restrict user access to screen locations where data is entered
Provide a way to leave the data entry screen at any time without entering the current record
Provide a descriptive caption for every field
Provide a means for users to move among fields on the form in a standard order or in any order they choose
Allow users to add, change, delete, and view records
24
Guidelines for User Interface Design (Cont. 11)
24
Focus on Data Entry Screens (Cont.)
Design the screen form layout to match the layout of the source document
Display a sample format like MMDDYY and use an input mask
Require an ending stroke for every field
Do not require users to type leading zeros for numeric fields or trailing zeros for decimals
Display default values
Provide users with an opportunity to confirm the accuracy of input data before displaying it
25
Guidelines for User Interface Design (Cont. 12)
25
26
Guidelines for User Interface Design (Cont. 13)
FIGURE 8-12 Microsoft Access provides various input masks for dates, phone numbers, and postal codes, among others. In addition, it is easy to create a custom mask using the characters shown here.
26
Focus on Data Entry Screens (Cont.)
Use a default value when a field value will be constant for successive records or throughout the data entry session
Use Validation Rules
Sequence check: Used when the data must be in some predetermined sequence
Existence check: Applies to mandatory data items
Data type check: Tests to ensure that a data item fits the required data type
Range check: Used to verify that data items fall between a specified minimum and maximum value
27
Guidelines for User Interface Design (Cont. 14)
27
Use Validation Rules (Cont.)
Reasonableness check: Identifies values that are questionable, but not necessarily wrong
Validity check: Used for data items that must have certain values
Combination check: Performed on two or more fields to ensure that they are consistent or reasonable when considered together
Batch controls: Totals used to verify batch input
28
Guidelines for User Interface Design (Cont. 15)
28
29
Guidelines for User Interface Design (Cont. 16)
FIGURE 8-13 Microsoft Access provides validation rules can improve data quality by requiring the input to meet specific requirements or conditions.
29
Reduce Input Volume
Input necessary data only
Do not input data that the user can retrieve from system files or calculate from other data
Do not input constant data
Use codes as they are shorter than the data they represent
30
Guidelines for User Interface Design (Cont. 17)
30
31
Source Document and Form Design
Garbage in, garbage out (GIGO): Quality of the output depends on the quality of the input
Source document: Collects input data, triggers an input action, and provides a record of the original transaction
A good form layout makes the form easy to complete and provides enough space
Information should flow on a form from left to right
and top to bottom
31
Order and placement of printed fields should be logical
Totals should be identified clearly
32
Source Document and Form Design (Cont.)
FIGURE 8-14 Source document zones.
32
33
Printed Output
Questions to be considered before designing printed output
Why is this being delivered as printed output?
Who wants the information, why is it needed, and how will it be used?
What specific information will be included?
Will the printed output be designed for a specific device?
Do security or confidentiality issues exist?
33
Overview of Report Design
Organizations strive to reduce the flow of paper and printed reports
Users find it handy to view screen output, then print the information they need
Printed output is used in turnaround documents
Reports must be easy to read and well organized
Database programs such as Microsoft Access include a variety of report design tools to create reports quickly and easily
34
Printed Output (Cont. 1)
34
Types of Reports
Detail reports: Produce one or more lines of output for each record processed
Can be quite lengthy
Exception reports: Display only those records that meet specific conditions
Useful when the user wants specific information
Summary reports: Reports that provide comprehensive data
35
Printed Output (Cont. 2)
35
User Involvement
Users must approve all report designs in advance
A mock-up, or prototype, can be prepared for the users to review
Report Design Principles
Every report should have a report header and footer
Report header: Identifies the report, and contains the report title, date, and other necessary information
Report footer: Contains end-of-report information
36
Printed Output (Cont. 3)
36
Report Design Principles (Cont.)
Page headers and footers
Page header: Includes the column headings that identify the data
Page footer: Displays the report title and the page number
Repeating fields
Users’ opinion helps provide clarity
Consistent design
Look and feel are important to users, so reports should be uniform and consistent
37
Printed Output (Cont. 4)
37
38
Printed Output (Cont. 5)
FIGURE 8-15 The Employee Hours report is a detail report with control breaks, subtotals, and grand totals. Notice that a report header identifies the report, a page header contains column headings, a group footer contains subtotals for each store, a report footer contains grand totals, and a page footer identifies the page number.
38
39
Technology Issues
Output Technology
In addition to screen output and printed matter, output can be delivered in many ways
Actual forms, reports, and documents have to be created to be accessible from workstations, notebooks, tablets, smartphones, and other devices
Internet-based information delivery
Allows users to download a universe of files and documents to support their information needs
Companies use a live or prerecorded webcast to reach prospective customers and investors
39
Output Technology (Cont.)
Email – An essential means of internal and external business communication
Blogs: Web based logs
Useful for posting news, reviewing current events, and promoting products
Instant messaging – Useful for team members in a collaborative situation
Wireless devices – Data can be transmitted using the Internet across a wide array of devices
40
Technology Issues (Cont. 1)
40
41
Technology Issues (Cont. 2)
Output Technology (Cont.)
Digital audio, images and video
Can be captured and stored in digital format
Can be attached to an email message or inserted as a clip in a Microsoft Word document
Podcasts
Used as sales and marketing tools, and to communicate with the employees
Automated fax or faxback systems
Allow a customer to request a fax using e-mail, via the company Web site, or by telephone
41
42
Technology Issues (Cont. 3)
Output Technology (Cont.)
Computer output to microfilm (COM)
Used by large firms to scan and store images of original documents to provide high-quality records management and archiving
Computer output to digital media
Used when many paper documents must be scanned and stored in digital format for quick retrieval
42
Output Technology (Cont.)
Specialized forms of output
Portable, Web-connected devices that can run multiple apps
Retail point-of-sale terminals that handle credit card transactions
Automatic teller machines (ATMs) that can process bank transactions
Special-purpose printers
Plotters that can produce high-quality images
Electronic detection of data embedded in credit cards, bank cards, and employee identification cards
43
Technology Issues (Cont. 4)
43
44
Technology Issues (Cont. 5)
FIGURE 8-17 Input devices can be very traditional, or based on the latest technology.
44
Input Technology
Batch input: Data entry is performed on a specified time schedule, such as daily, weekly, monthly, or longer
Online data entry
Enables immediate validation and availability of data
Source data automation combines online data entry and automated data capture using input devices such as RFID tags, magnetic data strips, or smartphones
Fast and accurate, and minimizes human involvement in the translation process
45
Technology Issues (Cont. 6)
45
Input Technology (Cont.)
Examples of source data automation
Point-of-sale (POS) terminals equipped with bar code scanners and magnetic swipe scanners
Automatic teller machines (ATMs) read data strips on
bank cards
Factory employees use magnetic ID cards to clock
on and off specific jobs
Hospitals imprint bar codes on patient identification
bracelets and use portable scanners when gathering data on patient treatment and medication
Retail stores use portable bar code scanners and libraries use handheld scanners
46
Technology Issues (Cont. 7)
46
Input Technology (Cont.)
Trade offs
Manual data entry is slower and more expensive than batch input
Performed at the time the transaction occurs
Often done when computer demand is at its highest
Decision to use batch or online input depends on business requirements
47
Technology Issues (Cont. 8)
47
48
Security and Control Issues
Output Security and Control
Companies use output control methods to maintain output integrity and security
Output security protects privacy rights
Shields the organization’s proprietary data from theft or unauthorized access
Security solutions
Diskless workstation: Network terminal that supports a full-featured user interface but limits the printing or copying of data
Port protector: Controls access to and from workstation interfaces
48
Input Security and Control
Input control ensures that the input data is correct, complete, and secure
Information should be traceable back to the input data that produced it
Procedures must be put in place for handling source documents to ensure that data is not lost before it enters the system
Data security policies and procedures protect data from loss or damage
Companies should have a records retention policy that meets all legal requirements and business needs
Audit trail files and reports should be stored and saved
49
Security and Control Issues (Cont.)
49
50
Where Do We Go From Here?
Modular Design
Individual components, called modules, connect to a higher-level program or process
Designed to perform a single function
In a structured design, each module represents a specific process
Shown on a data flow diagram (DFD) and documented in a process description
Prototyping
Involves a repetitive sequence of analysis, design, modeling, and testing
50
Prototyping (Cont.)
System prototyping
Produces a full-featured, working model of the information system
Design or throwaway prototyping
Used to verify user requirements and is discarded
51
Where Do We Go From Here (Cont. 1)
FIGURE 8-21 The end product of system prototyping is a working model of the information system, ready for implementation.
51
Prototyping (Cont.)
Benefits
Users and systems developers can avoid misunderstandings
System developers can create accurate specifications for the finished system based on the prototype
Managers can evaluate a working model more effectively than a paper specification
Helps in developing testing and training procedures
Reduces the risk and potential financial exposure that occur when a finished system fails to support business needs
52
Where Do We Go From Here (Cont. 2)
52
Prototyping (Cont.)
Potential problems
Rapid pace of development can create quality problems which may not be discovered until the finished system is operational
System requirements, such as reliability and maintainability, cannot be tested adequately using a prototype
In complex systems, the prototype can become unwieldy and difficult to manage
Clients may want to adopt the prototype with few to no changes, leading to increased maintenance costs later in the SDLC
53
Where Do We Go From Here (Cont. 3)
53
54
Chapter Summary
Purpose of systems design
To create a physical model of the system that satisfies the design requirements that were defined during the systems analysis phase
User interface design must be based on the perspective of the user
Types of printed reports
Detail, exception, and summary reports
54
Various zones in a document
Heading zone, control zone, instruction zone, body zone, totals zone, and authorization zone
Input methods include data capture and data entry
Security and control plays an important role in designing
55
Chapter Summary (Cont.)
55
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
56
56
Requirements Modeling
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 CRICOS Code: 00161E
RTO Code: 90458 TEQSA Provider Number: PRV12051
Version 2 – 18th December 2015
1
Prescribed Text and recommended readings
Prescribed text
Rosenblatt, H. J. (2016), Systems Analysis and Design.11th Edition, Cengage Learning, Boston MA
Prescribed reading
Robertson, S. and Robertson, J. (2013), Mastering the Requirements Process: Getting Requirements Right, 3rd Edition, Addison Wesley, Upper Saddle River, NJ
IIBA (2015), Guide to the Business Analysis Body of Knowledge, BABOK Version 3.0, International Institute of Business Analysis, http://www.iiba.org/BABOKGuide.aspx
2
2
Learning Objectives
Describe systems analysis phase activities
Explain joint application development (JAD), rapid application development (RAD), and agile methods
Use a functional decomposition diagram (FDD) to model business functions and processes
Describe the Unified Modeling Language (UML) and examples of UML diagrams
List and describe system requirements, including outputs, inputs, processes, performance, and controls
3
Learning Objectives (cont.…)
Explain the concept of scalability
Use fact-finding techniques, including interviews, documentation review, observation, questionnaires, sampling, and research
Define total cost of ownership (TCO)
Conduct a successful interview
Develop effective documentation methods to use during systems development
4
Systems Analysis Phase Overview
Objectives
Understand the proposed project
Ensure that it supports business requirements
Build a solid foundation for system development
Systems Analysis Activities
Requirements modeling
Involves fact-finding to describe the current system and identification of the requirements for new system
Data and process modeling
Graphically represents system data and processes
5
Systems Analysis Phase Overview cont.…
Object modeling
Involves creation of objects to represent people, things, transactions, and events
Development strategies
Include software trends, development alternatives, and outsourcing
6
FIGURE 4-1 The systems analysis phase consists of requirements modeling, data and process modeling, object modeling, and consideration of development strategies. Notice that the systems analysis tasks are interactive, even though the waterfall model generally depicts sequential development
Systems Analysis Phase Overview cont.…
Systems Analysis Skills
Strong analytical and interpersonal skills
Team-Based Techniques
Goal – To deliver the best possible system at the lowest possible cost in the shortest possible time
Some of the Team-based techniques are: JAD, RAD, and Agile Methods
Joint application development (JAD) brings users into the design process
Rapid application development (RAD) is a condensed version of the system development life cycle
Agile methods stress intense interaction between developers and users
7
FIGURE 4-2 Photo Source: Web design and development by venimo on @creativemarket
Joint Application Development
Brings users into the development process as active participants
User Involvement (formal or informal)
Helps create a successful system
JAD Participants and Roles
Project leader and one or more members
Participants should be insulated from distractions of day-to-day operations
8
FIGURE 4-3 photo credit: @freepik.com
Joint Application Development
9
FIGURE 4-4 Typical JAD participants and roles
Joint Application Development
10
FIGURE 4-5 Typical agenda for a JAD session
Joint Application Development
JAD Advantages and Disadvantages
Disadvantages
More expensive than traditional methods
Can be cumbersome if the group is too large
Advantages
Allows key users to participate effectively
Users are more likely to feel a sense of ownership
Produces a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system
11
Rapid Application Development
Uses a group approach like JAD
End product – New information system
Complete methodology
Includes a four-phase life cycle that parallels the traditional SDLC
Reduces cost and development time
Increases the probability of success
Relies on prototyping and user involvement
Prototypes are modified based on user input
12
FIGURE 4-4 Rapid Application Development (RAD)
Photo Credit: https://www.wavemaker.com/rapid-application-development-model/
Rapid Application Development
13
FIGURE 4-5 The four phases of the RAD model are requirements planning, user design, construction, and cutover. Notice the continuous interaction between the user design and construction phases.
Rapid Application Development
RAD Objectives
Cut development time and expense
Involve users in every phase of systems development
Must have the right IT resources, skills, and management support
RAD Advantages and Disadvantages
Advantage – Helps develop systems quickly with significant cost savings
Disadvantages
Does not emphasize the company’s strategic business needs
Less time to develop quality, consistency, and design standards
14
FIGURE 4-6 Rapid Application Development (RAD)
Photo credit: http://yourtelecast24.com/2019/10/09/global-rapid-application-development-market-size-will-observe-substantial-growth-by-2025/
Agile Methods
Attempt to develop a system incrementally, by building a series of prototypes and adjusting them to user requirements regularly
Developers revise, extend, and merge earlier versions into the final product
Emphasize continuous feedback
Each incremental step is affected by what was learned in the prior steps
15
FIGURE 4-7 Agile Development methodology
Photo Credit: https://www.piicomm.ca/agile-methodology-improves-mobile-device-testing/
Agile Methods
Scrum
A rugby term
Pigs include the product owner, the facilitator, and the development team
Chickens include users, other stakeholders, and managers
Scrum sessions
Have specific guidelines that emphasize time blocks, interaction, and team-based activities that result in deliverable software
16
FIGURE 4-8 In a rugby scrum, team members prepare to lunge at each other to achieve their objectives.
fotograf.lv / Shutterstock.com
Agile Methods
Agile Method Advantages and Disadvantages
Advantages
Very flexible and efficient in dealing with change
Frequent deliverables constantly validate the project and reduce risk
Disadvantages
Team members need a high level of technical and interpersonal skills
Lack of structure and documentation can introduce risk factors
May be subject to significant change in scope
17
Modeling Tools and Techniques
Involve graphical methods and nontechnical language that represent the system at various stages of development
Systems analysts:
Build fact-finding results into models
Study the models to determine whether additional fact-finding is needed
Functional Decomposition Diagrams (FDD)
Top-down representation of a function or process
Help analysts show business functions and how they are organized into lower-level processes
18
Modeling Tools and Techniques
19
FIGURE 4-9 This Visible Analyst FDD shows a library system with five top-level functions. The Library Operations function includes two additional levels of processes and sub processes. Source: Visible Systems Corporation.
Modeling Tools and Techniques
Business Process Modeling (BPM)
Represents one or more business processes
Business process modeling notation (BPMN)
Models that use a standard language
Includes shapes and symbols to represent events, processes, and workflows
20
FIGURE 4-10 Using the Visible Analyst CASE tool, an analyst can create a business process diagram. The overall diagram is called a pool, and the two separate customer areas are called swim lanes.
Source: Visible Systems Corporation.
Modeling Tools and Techniques
Data Flow Diagrams (DFD)
Show how the system stores, processes, and transforms data
Additional levels of information and detail are depicted in other, related DFDs
21
FIGURE 4-11 This Visible Analyst DFD shows how books are added and removed in a library system. Source: Visible Systems Corporation.
Modeling Tools and Techniques
Use Case Diagrams
Represent the interaction between
users and the system
22
FIGURE 4-12 This Visible Analyst use case diagram shows a sales system, where the actor is a customer and the use case is a credit card validation.
Source: Visible Systems Corporation
Modeling Tools and Techniques
23
FIGURE 4-12 This Visible Analyst use case diagram shows a sales system, where the actor is a customer and the use case is a credit card validation.
Source: Visible Systems Corporation
FIGURE 4-13 This table documents the credit card validation use case shown in Figure 4-12.
Modeling Tools and Techniques
Sequence Diagrams
Show the timing of interactions between objects as they occur
24
FIGURE 4-14 This Visible Analyst sequence diagram shows a credit card validation process.
Source: Visible Systems Corporation
System Requirements Checklist
Output Examples
The Web site must report online volume statistics every four hours, and hourly during peak periods
The contact management system must generate a daily reminder list for all sales reps
The purchasing system must provide suppliers with up-to-date specifications
25
System Requirements Checklist
Input Examples
The department head must enter overtime hours on a separate screen
Student grades must be entered on machine-readable forms prepared by the instructor
Each input form must include date, time, product code, customer number, and quantity
26
System Requirements Checklist
Process Examples
The student records system must calculate the GPA at the end of each semester
The human resources system must interface properly with the existing payroll system
The prescription system must automatically generate an insurance claim form
27
System Requirements Checklist
Performance Examples
The system must support 25 users online simultaneously
Response time must not exceed four seconds
The system must be operational seven days a week, 365 days a year
28
System Requirements Checklist
Control Examples
The system must provide logon security at the operating system level and at the application level
The system must maintain separate levels of security for users and the system administrator
All transactions must have audit trails
The system must create an error log file that includes the error type, description, and time
29
Future Growth, Costs, and Benefits
Scalability
A system’s ability to handle increased business volume and transactions in the future
A scalable system offers a better return on the initial investment
Information required to evaluate scalability
Projected future volume for all outputs, inputs, and processes
30
Future Growth, Costs, and Benefits
Total Cost of Ownership
Important if the development team is evaluating several alternatives
Problem – Cost estimates tend to understate indirect costs
Systems analysts should try to identify indirect costs and include them in TCO estimates
31
FIGURE 4-15 Total cost of ownership when migrating to the cloud can be significantly less than current computing platforms.
Fact Finding
Fact-Finding Overview
Identify the required information – Typical questions to ask
What business functions are supported by the current system?
What are the benefits and TCO of the proposed system?
What transactions will the system process?
Must the new system interface with legacy systems?
Develop a fact-finding plan
32
Fact Finding
Who, What, Where, When, How, and Why?
Systems analyst must first understand the current situation
Will help him/her tackle the question of what should be done
33
FIGURE 4-16 Sample questions during requirements modeling as the focus shifts from the current system to the proposed system.
Fact Finding
The Zachman Framework
Helps managers and users understand the model
Ensures that overall business goals translate into successful IT projects
34
FIGURE 4-17 Visible Analyst uses the Zachman Framework for Enterprise Architecture. The Zachman concept presents traditional fact-finding questions in a systems development context.
Source: Visible Systems Corporation
Interviews
Steps involved
Step 1 – Determine the people to interview
Step 2 – Establish objectives for the interview
Step 3 – Develop interview questions
Step 4 – Prepare for the interview
Step 5 – Conduct the interview
Step 6 – Document the interview
Step 7 – Evaluate the interview
35
Interviews
Step 1 – Determine the People to Interview
Select the right people and ask the right questions
Consider candidates from both formal and informal structures
Decide on group and/or individual interviews
Step 2 – Establish Objectives for the Interview
Determine the areas to be discussed
List the facts that need to be gathered
Objectives depend on the role of the person being interviewed
36
Interviews
Step 3 – Develop Interview Questions
Decide what to ask and how to phrase the question
Avoid leading questions
Open ended questions encourage spontaneous and unstructured responses
Close ended questions limit the response
Used to verify facts
Range-of-response questions limit the response
Use a numeric scale
37
Interviews
Step 4 – Prepare for the Interview
Careful preparation is essential
Limit the interview to no more than one hour
Verify time, place, length, and topics via e-mail
If there are questions about documents, ask the interviewee to have samples available at the meeting
38
Interviews
39
FIGURE 4-19 Sample message to a department head about interviews.
Source: 2015 Apple
Interviews
40
FIGURE 4-20 Sample message to confirm an interview.
Source: 2015 Apple
Interviews
41
Step 5 – Conduct the Interview
Develop a specific plan for the meeting
Begin by introducing yourself, describing the project, and explaining your interview objectives
Practice engaged listening
Allow the person enough time to think about the question and arrive at an answer
After an interview, summarize the session and seek a confirmation
Interviews
42
Step 6 – Document the Interview
Note taking should be kept to a minimum
After conducting the interview:
Record the information quickly
Send memo to the interviewee expressing your appreciation
Note the date, time, location, purpose of the interview, and the main points you discussed so the interviewee has a written summary and can offer additions or corrections
Step 7 – Evaluate the Interview
In addition to recording the facts obtained in an interview, try to identify any possible biases
Interviews
43
Unsuccessful Interviews
No matter how well you prepare for interviews, some are not successful
Misunderstanding or personality conflict could affect the interview negatively, or the interviewee might be afraid that the new system will eliminate or change his or her job
Other Fact-Finding Techniques
Document Review
Review of baseline documentation
Helps an analyst understand how the current system is supposed to work
Observation
Provides additional perspective and a better understanding of the system procedures
Should be planned in advance
44
Figure 4-21 The Hawthorne study suggested that worker productivity improves during observation. Always consider the Hawthorne Effect when observing the operation of an existing system.
Monkey Business Images/Shutterstock.com
Other Fact-Finding Techniques
45
Questionnaires and Surveys
Make sure that the questions collect the right data in a form that can be used to further the fact finding effort
Can be traditional forms, fill-in forms, or forms from online survey websites
Fill-in form: Template used to collect data on the Internet or a company intranet
Other Fact-Finding Techniques
46
Suggestions for designing a questionnaire
Keep the questionnaire brief and user-friendly
Provide clear instructions
Arrange the questions in a logical order
Phrase questions to avoid misunderstandings
Try not to lead the response
Limit the use of open-ended questions that are difficult to tabulate
Limit the use of questions that can raise concerns about job security or other negative issues
Include a section for general comments
Test the questionnaire on a small test group before finalizing it and distributing to a large group
Other Fact-Finding Techniques
47
FIGURE 4-22 Online version of a sample questionnaire. Does it follow the suggested guidelines?
Created by author using Adobe Online Forms, Adobe Systems Incorporated
Other Fact-Finding Techniques
48
Interviews versus Questionnaires
Interview is more familiar and personal
Costly and time-consuming process
Questionnaire gives people the opportunity to provide input and suggestions
Recipients can answer the questions at their convenience
Brainstorming: Small group discussion of a specific problem, opportunity, or issue
Structured brainstorming
Unstructured brainstorming
Other Fact-Finding Techniques
49
Sampling
Systematic sample: Selection of every tenth customer for review
Stratified sample: Selection of five customers from each of four postal codes
Random sample: Selection of any 20 customers
Objective of a sample
To ensure that it represents the overall population accurately
Other Fact-Finding Techniques
50
Research
The Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments
Attending professional meetings, seminars, and discussions with other IT professionals
Site visits
Documentation
51
The Need for Recording the Facts
Principles for documentation
Record information as soon as it is obtained
Use the simplest recording method
Record findings in a way that they can be understood by someone else
Organize documentation so related material is located easily
Documentation
Software Tools
CASE tools
Productivity software
Word processing
Spreadsheets
Database
management
Presentation
graphics
Collaborative
software programs
52
FIGURE 4-23 This histogram displays the results from Question 2 in the questionnaire shown in Figure 4-22.
Documentation
Graphic Modeling Software
Help create charts and diagrams
Popular software
MS Visio
53
FIGURE 4-24 This Microsoft Visio drawing uses drag-and-drop shapes to represent a business process.
Source: Microsoft, LLC
Information Management Software
Personal Data Management Software
Microsoft Outlook
Includes a personal calendar, a to-do list with priorities and the capability to check off completed items, and powerful contact management features
Can manage email and appointments, and supports collaboration and team projects
Novell’s GroupWise
54
Figure 4-25 Evernote offers a free version of its popular information management software for most computing platforms, including smartphones and on the web.
Source: www.evernote.com
Documentation
Project Data Management
Microsoft OneNote
Handles different types of input, including text, handwritten notes, images, audio and video recordings, and web links
Microsoft Word
Recent versions provide note taking feature
55
FIGURE 4-26 The analyst is using Microsoft Word to store fact-finding results. During the interview with Joy Brooks, the analyst recorded part of the discussion and stored it as a document annotation.
Source: Microsoft Corporation.
Preview of Logical Modeling
56
At the conclusion of requirements modeling, systems developers should have a clear understanding of business processes and system requirements
Next step – To construct a logical model of the system
IT professionals have differing views about systems development methodologies, and no universally accepted approach exists
Chapter Summary
57
The systems analysis phase includes:
requirements modeling
data and process modeling, and
consideration of development strategies
Objective is to understand the proposed project, ensure that it will support business requirements, and build a solid foundation for the systems design phase
Popular team-based approaches includes:
JAD
RAD, and
agile methods
Chapter Summary
58
The fact-finding process includes:
Interviewing
document review
Observation
Questionnaires
sampling, and
research
Systems analysts should carefully record and document factual information as it is collected, and various software tools can help an analyst visualize and describe an information system
kent.edu.au
Kent Institute Australia Pty. Ltd.
ABN 49 003 577 302 ● CRICOS Code: 00161E ● RTO Code: 90458 ● TEQSA Provider Number: PRV12051
59
59