Information System Acquisition & Lifecycle: system acquisition process, phases: Initiation, Planning, Procurement, System Development, System Implementation, Maintenance & Operations, and Closeout. development models.

1. Health
Informatics
BCA-2020: Semester-V

2. Module 2:
Chapter 1
INFORMATION SYSTEM
ACQUISITION &
LIFECYCLE
MEDICAL INFORMATION
STRUCTURING
SEARCHING AND
RETRIEVAL

3. Module
Content
 Information System Acquisition & Lifecycle: system acquisition
process, phases: Initiation, Planning, Procurement, System
Development, System Implementation, Maintenance &
Operations, and Closeout, development models.
 Medical Information Structuring: Analysing and Designing
Structure of healthcare information systems, Architectures of
Information Systems.
 Searching and Retrieval: locate or retrieve specific information to
meet an information need, information retrieval techniques.

4. LearningObjectives
 To learn system acquisition process
 Understanding different phases: Initiation,
Planning, Procurement, System Development,
System Implementation, Maintenance &
Operations, and Closeout.
 Studying different development models.

5. System
acquisition
process
 System Acquisition:
 The process a health care organization generally goes through in
selecting a health care information system.
 Acquiring a health care information systems
 Purchasing
 Contracting with an application service provider
 Building a system in-house
 Organizational objectives: type of system or application being sought;
information management needs and plans.
 Background of the organization:
 Overview of the facility: size, types of patient services, patient volume, staff
composition, strategic goals of organization.
 Application and technical inventory: current systems in use, hardware,
software, network infrastructure.
 System goals and requirements: goals for the system and functional
requirements (may be categorized as mandatory or desirable and listed
in priority order).Typically this section includes application, technical,
and integration requirements.

6. Systems-
Development
LifeCycle
 The first development methodology we are going to review is the systems-
development life cycle (SDLC).This methodology was first developed in the
1960s to manage the large software projects associated with corporate systems
running on mainframes. It is a very structured and risk-averse methodology
designed to manage large projects that included multiple programmers and
systems that would have a large impact on the organization.
 Various definitions of the SDLC methodology exist, but most contain the
following phases.
 1) Preliminary Analysis. In this phase, a review is done of the
request. Is creating a solution possible?What alternatives exist?
What is currently being done about it? Is this project a good fit for
our organization?A key part of this step is a feasibility analysis,
which includes an analysis of the technical feasibility (is it possible
to create this?), the economic feasibility (can we afford to do this?),
and the legal feasibility (are we allowed to do this?).This step is
important in determining if the project should even get started.

7. Systems-
Development
LifeCycle
 2) SystemAnalysis. In this phase, one or more system analysts work
with different stakeholder groups to determine the specific
requirements for the new system. No programming is done in this step.
Instead, procedures are documented, key players are interviewed, and
data requirements are developed in order to get an overall picture of
exactly what the system is supposed to do.The result of this phase is a
system-requirements document.
 3) System Design. In this phase, a designer takes the system-
requirements document created in the previous phase and develops the
specific technical details required for the system. It is in this phase that
the business requirements are translated into specific technical
requirements.The design for the user interface, database, data inputs
and outputs, and reporting are developed here.The result of this phase is
a system-design document.This document will have everything a
programmer will need to actually create the system.

8. Systems-
Development
LifeCycle
 4) Programming. The code finally gets written in the programming
phase. Using the system-design document as a guide, a programmer (or
team of programmers) develop the program.The result of this phase is
an initial working program that meets the requirements laid out in the
system-analysis phase and the design developed in the system-design
phase.
 5)Testing. In the testing phase, the software program developed in the
previous phase is put through a series of structured tests.The first is a
unit test, which tests individual parts of the code for errors or bugs. Next
is a system test, where the different components of the system are
tested to ensure that they work together properly. Finally, the user-
acceptance test allows those that will be using the software to test the
system to ensure that it meets their standards.Any bugs, errors, or
problems found during testing are addressed and then tested again.

9. Systems-
Development
LifeCycle
 6) Implementation. Once the new system is developed and tested, it
has to be implemented in the organization.This phase includes training
the users, providing documentation, and conversion from any previous
system to the new system. Implementation can take many forms,
depending on the type of system, the number and type of users, and
how urgent it is that the system become operational.These different
forms of implementation are covered later in the chapter.
 7) Maintenance. This final phase takes place once the implementation
phase is complete. In this phase, the system has a structured support
process in place: reported bugs are fixed and requests for new features
are evaluated and implemented; system updates and backups are
performed on a regular basis.

10. Models of the
System
Development
LifeCycle
 The system development life cycle, known as the SDLC, is the
industry-standard approach to managing phases of an
engineering project.
 Think of it as the equivalent to the scientific method for software
development and other IT initiatives.
 The common breakdown of the SDLC includes seven phases that
trace a product or project from a planned idea to its final release
into operation and maintenance.
 There is flexibility within the SDLC. In recent decades a number of
different models and methods have gained popularity.

11. 1.Waterfall
 The waterfall approach is one of the oldest SDLC models, but it has
fallen out of favor in recent years.This model involves a rigid structure
that demands all system requirements be defined at the very start of a
project. Only then can the design and development stages begin.
 Once development is complete, the product is tested against the initial
requirements and rework is assigned.Companies in the software
industry typically need more flexibility that what the waterfall
methodology offers, but it still remains a strong solution for certain
types of projects especially government contractors.

12. 2. Iterative  The iterative methodology takes the waterfall model and cycles
through it several times in small increments. Rather than
stretching the entire project across the phases of the SDLC, each
step is turned into several mini-projects that can add value as the
product evolves.
 The iterative approach shares many of the same goals as the agile
model, except external customers are less involved and the scope
of each increment is normally fixed.

13. 3. DevOps
 DevOps is one of the newest SDLC methodologies and is being adopted
by many software companies and IT organizations.As its name suggests,
the premise of DevOps is to bring development teams together with
operational teams in order to streamline delivery and support.
 The advantages of such an approach are that changes become more
fluid, while organizational risk is reduced.Teams must have flexible
resources in order for a DevOps arrangement to succeed.

14. 4.V-Model
 An evolution of the classic waterfall methodology, the v-model SDLC
process steps are flipped upwards after the coding phase.The v-model
has a very strict approach, with the next phase beginning only when the
previous phase is complete.
 This lack of flexibility and higher-risk method isn’t recommended for
small projects, but the v-model is easier to manage and control. For
projects where requirements are static and clearly stated, and where
early testing is desired, this approach can be a good choice.

15. 5.Spiral
 The spiral methodology allows teams to adopt multiple SDLC
models based on the risk patterns of the given project. A blend of
the iterative and waterfall approaches, the challenge with the spiral
model is knowing when is the right moment to move onto the next
phase.
 Business that aren’t sure about their requirements or expect major
edits during their mid to high-risk project can benefit from the
scalability of this methodology.

16. 6.Agile
 The agile methodology is the opposite of the waterfall approach. Rather
than treating requirements, design, and testing as large sequential
steps, an agile model makes them all ongoing processes that require
involvement from developers, management, and customers.
 Work is typically broken into 2-4 week segments known as “sprints,” in
which the responsible teams tackle the major needs of their customers
and perform testing as they go. Agile tends to work well in small
organizations, especially startups, where speed and flexibility is
essential.
 The characteristics of agile methods include:
 small cross-functional teams that include development-team members
and users;
daily status meetings to discuss the current state of the project;
 short time-frame increments (from days to one or two weeks) for each
change to be completed; and
 at the end of each iteration, a working project is completed to demonstrate
to the stakeholders.
 The goal of the agile methodologies is to provide the flexibility of an
iterative approach while ensuring a quality product.

17. 7. Lean
 The agile and lean approaches are closely interconnected, as they both
focus on delivery speed and continuous improvement. In contrast, the
lean model is rooted in manufacturing best practices where excess
waste and effort are seen as the largest risk to an organization.
 When it comes to software and projects, the lean SDLC methodology
focuses on reducing waste in every phase, including scheduling, cost,
and scope.This approach is most compelling for organizations with
strict hardware requirements and other procurement needs.

18. 8. Rapid
Application
Development
 Rapid application development (RAD) is a software-development (or
systems-development) methodology that focuses on quickly building a
working model of the software, getting feedback from users, and then using
that feedback to update the working model.After several iterations of
development, a final version is developed and implemented.
 RAD methodology is much more compressed than SDLC. Many of the SDLC
steps are combined and the focus is on user participation and iteration.This
methodology is much better suited for smaller projects than SDLC and has
the added advantage of giving users the ability to provide feedback
throughout the process. SDLC requires more documentation and attention
to detail and is well suited to large, resource-intensive projects. RAD makes
more sense for smaller projects that are less resource-intensive and need to
be developed quickly.

19. 9. Prototype
Model
 A prototype is an early approximation of the final system or
product.This mode is useful for systems where requirements are
not known in detail during development.
 In this model, customers can realize the system requirement after
the prototype is brought into operation. It allows more accurate,
flexible design and development. It takes a low cost in design and
development time.
 Start
 Requirement AnalysisQuick Design Prototype Building
 EngineerThe Product Refine Prototype User Evaluation
 Stop

20. ThankYou!