PREFACE

This learning module has been designed and developed to assist

students in their pursuit of completing the BSIT program in JHCSC. Pretests,
Mastery Test and Task sheets intend to gauge the students’ prior
knowledge, retention and comprehension skills of the module’s content.
The System Integration and Architecture (SIA)1 module covers the
first part of the SIA course which comprises the System’s (1) Requirements,
(2) Acquisition and Sourcing, (3) Integration and Deployment, and finally
(4) Project Management. This course helps the students to have
supplemental information for other courses’ requirements.
Students’ responses and results will basically indicate their learning
capability in this new normal education setting. Further, all data gathered
from all learners contributes for the enhancement of this module.

i
 ACKNOWLEDGEMENT

The development of SIA1 Learning Module of the JHCSC- School of

Engineering and Technology will not be possible without the joint efforts of
the group members namely, JP ARNOCO TILLO and LOUEJAY BUYCO
SEGUERRA. Whose commitment and dedication, persevere for the
completion of the task.
To the JHCSC Officials and IMs Committee for spearheading the system
wide series of webinars and workshops for faculty members.

ii
 TABLE OF CONTENTS

Preface -------------------------------------------------- i
Acknowledgement -------------------------------------------------- ii
Unit 1 -------------------------------------------------- 1
Lesson 1 Requirements ---------------------------------- 1
Requirements Elicitation, Documentation,
and Maintenance -------------------------- 4
Modeling Requirements -------------------------- 8
Modeling Tools and Methodologies ----------- 10
Testing ------------------------------------------------- 19
Project Lifecycle Phases -------------------------- 24
Lesson 2 Acquisition and Sourcing ------------------ 50
In-sourcing and Outsourcing ------------------ 50
System Architecture: Hardware,
Software, and Virtual ------------------------- 52
Contracts and RFPs --------------------------------- 60
Quality ------------------------------------------------ 63
Unit 2
Lesson 1 Integration and Deployment
Components, Interfaces, and Integration
Infrastructure, Middleware and Platforms
Techniques:
Data warehouses, Extending Frameworks,
Wrappers, Glue, Facades
System Release:
iii
 Pilot and Acceptance Testing and Defect
Repair
System Support Strategies and User Support Plans
Enterprise Integration Approaches, Standards and
Best Practices
Lesson 2
Project Management
Cost Benefit Analysis
Roles, Responsibilities, Accountability
Finance, Estimation, Budgeting
Planning
Risk Management
Scheduling
Tracking
Lessons Learned

References ------------------------------------------------------------ 81
Appendices ------------------------------------------------------------ 82
- Key Answers ------------------------------------ 82
- Approved Syllabus ------------------------------------ 83

iv
UNIT 1
LESSON 1
Requirements
Learning Outcomes
At the end of the lesson, you should be able to:
• Identify correctly and discuss the phases of the Requirements Life
Cycle.
• Illustrate the steps of an existing system using a USE CASE Model.
• Develop an Activity Diagram of an existing system.

PRETEST
Identification - Write your answers on the space provided before each
number.
_______________________1. In systems development, these refer to
statements that identify the essential needs of a system in order for it to
have value and utility.
_______________________2. What phase in Requirement Life Cycle where
there is no transformation of the requirements, but simple classification and
categorization are executed.
_______________________3. It refers to a type of User Requirement that
describes what the system should do.
_______________________4. It is a document that refers to the official
statement of what is required by the system developer.
_______________________5. A modelling tool that describes the proposed
functionality of the new system.
_______________________6. A modelling tool that shows a set of objects and 2
the messages sent and received by those objects.
_______________________7. A modelling tool that illustrates the procedural
flow of actions that are part of a larger activity.
_______________________8. In systems development, it refers to the process
of evaluating a system with the intent to find whether it satisfies the
specified requirement or not.
_______________________9. It is composed of series of activities which are
essential for accomplishing project objectives or targets.
_______________________10. It refers to someone who can influence the
success and failure of the project.

WHAT ARE REQUIREMENTS?

• Requirements are statements that identify the essential needs of a
system in order for it to have value and utility.

CHARACTERISTICS OF GOOD REQUIREMENTS

1. Describes What, Not How.
2. Atomic. i.e., it should have a single purpose
3. Unique.
4. Documented and Accessible.
5. Identifies Its Owner.
6. Approved. After a requirement has been revised, reviewed, and
rewritten, it must be approved by its owner.
7. Traceable. A good requirement is traceable; it should be possible to
trace each requirement back to its source.
8. Necessary.
9. Complete.
10. Unambiguous
11. Quantitative and testable
12. Identifies applicable states
14. States Assumptions. All assumptions should be stated.
15. Use of Shall, Should, and Will. A mandatory requirement should be
expressed using the word shall (e.g., "The system shall conform to all state
laws
16. Avoids Certain Words. The words optimize, maximize, and minimize
should not be used in stating requirements, because we could never
prove that we had achieved them.

3
REQUIREMENTS LIFE CYCLE

Raw Organise Analyse Complete SPECS

Req’ts d Req’ts d Req’ts user
Req’ts
The User

Elicitatio Organizatio Analysi Prototyp Transform

n Phase n Phase s Phase e Phase to spec
 ELICITATION PHASE

The starting point of the requirements engineering process is an

elicitation process that involves a number of people to ensure
consideration of a broad scope of potential ideas and candidate
problems

 ORGANIZATION PHASE

In this step there is no transformation of the requirements, but simple

classification and categorization. For example, requirements may be
grouped into functional vs. nonfunctional requirements.

 ANALYSIS PHASE

This represents a transformation.

4
 PROTOTYPE PHASE

In this way poorly understood requirements may be tested and

perhaps strengthened, corrected, or refined. This activity is often
done as a proof of concept and serves to induce feedback from
both the stakeholders and engineers.

 REQUIREMENTS DOCUMENTATION AND SPECIFICATION

This represents the requirements as the finished product of the

stakeholder requirements team. The requirements are compiled into
a requirements list or into some equivalent document format. These
collected requirements are then transformed into a specification.
1.1.1. Requirements Elicitation, Documentation, and
Maintenance

REQUIREMENTS ELICITATION
• Requirements determination addresses the gathering and
documenting of the true and real requirements for the Information
System being developed.
• Requirements is the wants and /or needs of the user within a problem
domain.

REQUIREMENTS DETERMINATION QUESTIONS

• WHO DOES IT?
• WHAT IS DONE?
• WHERE IS IT DONE?
• WHEN IS IT DONE
• HOW IS IT DONE
• WHY IS IT DONE?

SYSTEMS REQUIREMENTS
• Characteristics or features that must be included to satisfy business
requirements
• Outputs
• Inputs
• Processes
• Timing
• Controls
• Volumes. sizes, and frequencies
• Data/Information collected can be about; people, organization,
work and work environment.
5

FACT – FINDING METHODS

• SAMPLING (OF EXISTING DOCUMENTATION, FORMS, AND
DATABASES).
• RESEARCH AND SITE VISITS. (PARTICIPATION)
• OBSERVATION OF THE WORK ENVIRONMENT.
• QUESTIONNAIRES.
• INTERVIEWS.
• PROTOTYPING.
• JAD/JOINT REQUIREMENTS PLANNING (JRP).
TYPES OF REQUIREMENTS

 User Requirements: these are statements in Natural language plus

diagrams of services the system provides, together with its
operational constraints. These can be categorised into 2; functional
requirements and non-functional requirements
 Functional requirements
 Describe what the system should do
 Non-functional requirements
 Consists of Constraints that must be adhered to during
development (design and implementation)
 Remember ‘Constraints.’
 System requirements
 What we agree to provide
 Describes system services
 Contract between Client and contractor

FUNCTIONAL REQUIREMENTS
• WHAT INPUTS THE SYSTEM SHOULD ACCEPT
• WHAT OUTPUTS THE SYSTEM SHOULD PRODUCE
• WHAT DATA THE SYSTEM SHOULD STORE THAT OTHER SYSTEMS
MIGHT USE
• WHAT COMPUTATIONS THE SYSTEM SHOULD PERFORM
• THE TIMING AND SYNCHRONIZATION OF THE ABOVE

NON-FUNCTIONAL REQUIREMENTS
• Non-functional requirements are global constraints on a computer
system
• e.g. development costs, operational costs, performance,
reliability,
6
• The challenge of Non-functional requirements:
• Hard to model
• Usually stated informally, and so are:
• often contradictory,
• difficult to enforce during development
• difficult to evaluate for the customer prior to delivery
• Define system properties and constraints e.g. reliability, response
time and storage requirements. Constraints are I/O device
capability, system representations.
• Process requirements may also be specified mandating a particular
programming language or development method
 • Non-functional requirements may be more critical than functional
requirements. If these are not met, the system is useless.

EXAMPLES OF NFR
• Interface requirements
• How will the new system interface with its environment?
• User interfaces and “user-friendliness”
• Interfaces with other systems
• Performance requirements
• Time - response time
• Output - transactions per second
• Security
• permissible information flows
• Or who can do what
• Survivability – e.g. system will need to survive fire natural
catastrophes, etc
• Operating requirements
• Physical constraints (size, weight),
• Personnel availability & skill level
• Accessibility for maintenance
• Environmental conditions
• Lifecycle requirements
• Maintainability, Enhanciability, Portability, expected market or
product lifespan
• limits on development
• E.g. development time limitations, resource availability and
methodological standards.
• Economic requirements
• E.g. restrictions on immediate and/or long-term costs.

REQUIREMENTS DOCUMENTATION
• There are basically two types of documents realized from the
requirements elicitation phase. These include;
7
• User Requirements Specification Document
• System requirements specification Document

USER REQUIREMENTS SPECIFICATION –URS/URD

 The URS document outlines precisely what the User (or customer) is
expecting from this system.
 User Requirement Specification may incorporate the functional
requirements of the system or may be in a separate document
labelled the Functional Requirements Specification - the FRS.
The URD has the following information:
 1. Functional Requirements
2. Non-Functional Requirements

SYSTEM REQUIREMENTS SPECIFICATION DOCUMENT

A detailed description of the system services.
• What do we agree to provide?
• A structured document setting out detailed descriptions of the
system services.
• Written as a contract between client and contractor.

TOOLS THAT AID IN DEVELOPING & UNDERSTANDING SYSTEM REQUIREMENTS

• Affinity diagrams
• Force-field analysis
• Ishikawa fishbone (cause-and-effect) diagrams
• Pareto diagrams
• Pugh charts
• Quality function deployment (QFD)

1.1.2. Modelling Requirements

We build models in requirements analysis to understand

• current systems or business processes which we are trying to
automate
• how users will use a new system

The software requirements document is the official statement of what is

required of the system developers.
 • Should include both a definition of user requirements and a
specification of the system requirements.

• It is NOT a design document. As far as possible, it should set WHAT the

system should do rather than HOW it should do it.

Requirements Document Variability

Information in requirements document depends on the type of system and

the approach to development used.

Systems developed incrementally will, typically, have less detail in the

requirements document.

Requirements documents standards have been designed e.g. IEEE

standard. These are mostly applicable to the requirements for large systems
projects.

The Structure of a Requirements Document

Chapter Description

Preface This should define the expected readership of the

document and describe its version history, including a
rationale for the creation of a new version and a summary
of the changes made in each version.

Introduction This should describe the need for the system. It should briefly
describe the system’s functions and explain how it will work
with other systems. It should also describe how the system
fits into the overall business or strategic objectives of the
organization commissioning the software.

Glossary This should define the technical terms used in the

document. You should not make assumptions about the
experience or expertise of the reader.

User requirements Here, you describe the services provided for the user. The
definition nonfunctional system requirements should also be
described in this section. This description may use natural
 9

language, diagrams, or other notations that are

understandable to customers. Product and process
standards that must be followed should be specified.

System This chapter should present a high-level overview of the

architecture anticipated system architecture, showing the distribution of
functions across system modules. Architectural components
that are reused should be highlighted.

System This should describe the functional and nonfunctional

requirements requirements in more detail. If necessary, further detail may
specification also be added to the nonfunctional requirements.
Interfaces to other systems may be defined.

System models This might include graphical system models showing the
relationships between the system components and the
system and its environment. Examples of possible models
are object models, data-flow models, or semantic data
models.

System evolution This should describe the fundamental assumptions on which

the system is based, and any anticipated changes due to
hardware evolution, changing user needs, and so on. This
section is useful for system designers as it may help them
avoid design decisions that would constrain likely future
changes to the system. 10

Appendices These should provide detailed, specific information that is

related to the application being developed; for example,
hardware and database descriptions. Hardware
requirements define the minimal and optimal configurations
for the system. Database requirements define the logical
organization of the data used by the system and the
relationships between data.

Index Several indexes to the document may be included. As well

as a normal alphabetic index, there may be an index of
diagrams, an index of functions, and so on.
1.1.3. Modelling Tools and Methodologies

Unified Modeling Language (UML)

• Use case diagrams
• Class diagrams
• Sequential diagrams
• State Diagrams

USE CASE MODEL

• Describes the proposed functionality of the new system
• Represent a discrete unit of interaction between a user and the
system
• A single unit of meaningful work

Login

<<extends>>

11
Register with
Book Shop
A Use Case may ‘include’ another Use Case’s functionality or ‘extend’
Customer
another Use Case with its own behavior.
UseExample:
Case Model
Login to system
Register with system
Create order

A Use Case description will generally include:

• General comments and notes describing the Use Case
• Requirements- things that the Use Case must allow the user to do such
as
<ability to update order>
<ability to modify order> and others.

A Use Case may include:

➢ Constraints- rules about what can and cannot be done:
➢ Pre-conditions that must be true before the Use Case is run
–e.g. <create order> must precede <modify order>;
➢ Post-conditions that must be true before once the Use Case is run
–e.g. <order is modified and consistent>;
➢ Invariants: these are always true
–e.g. an order must always have a customer number;
➢ Scenarios: Sequential descriptions of the steps taken to carry out
the Use Case. May include multiple scenarios, to cater for
exceptional circumstances and alternate processing paths;
➢ Scenario Diagrams: Sequence diagrams to depict the workflow –
as above but graphically portrayed;
➢ Additional attributed such as implementation phase, version
number, complexity rating, stereotype and status.

An ACTOR:

➢ Is a user of the system

➢ This includes both human user and other computer systems
➢ Uses a Use Case to perform some piece of work which is of value
to the business
➢ The set of Use Cases an actor has access to, defines their overall
role in the system and the scope of their action

12

➢ Actors can participate in a

Is a generalization of generalization with other
actors
Person Student

Register for
➢ Actors may be connected
Courses

Student
 to Use Cases only by
associations

Billing System
Register for
Courses

Student

Registrar

➢ Here we have a Student interacting with the Registrar and the Billing
System via a “Register for Courses” Use Case

Requirements, Constraints & Scenarios

13
➢ Requirements:
These are the formal functional requirements that a Use Case must
provide to the end user. They correspond to the functional
specifications found in structured methodologies. A requirement is a
contract that the Use Case will perform some actions or provide
some value to the system.
➢ Constraints:
These are the formal rules and limitations that a Use Case operator
under, and includes pre- post- and invariant conditions.
A pre-condition specifies what must have already occurred or be in
place before the Use Case may start.
A post-condition documents what will be true once the Use Case is
complete. An invariant specifies what will be true throughout the
time the Use Case operates.
➢ Scenarios:
These formal descriptions of the flow of events that occurs during a
Use Case instance.
Usually described in text and correspond to a textual representation
of the Sequence Diagram.
➢ Includes and Extends Relationships Between Use Cases
▪ May include the functionality of another as part of its normal
processing
▪ It is assumed that the included Use Case will be called every time the
basic path is run.
Example <list order> Use Case may be included every time the
<modify order> Use Case is run.
▪ A Use Case may be included by one or more Use Cases. This helps to
reduce duplication of functionality by factoring out common
behavior into Use Cases that are re-used many times.

SEQUENCE DIAGRAMS
▪ A sequence diagram is an interaction diagram that emphasizes the
time ordering of messages
▪ It shows a set of objects and the messages sent and received by those
objects
▪ Sequence diagrams can be used to document Use Case Scenarios
▪ Captures required objects early in analysis and verify object usage
later in design
▪ Shows the flow of messages from one object to another, and as such
correspond to the methods and events supported by a class/object
▪ Graphically, a sequence diagram is a table that shows objects
arranged along the X axis and messages, ordered in increasing time,
along the Y axis.

14
Sequence Diagrams – Objects Symbols
An Order Line ➢ An object in a sequence diagram is rendered as a
box with a dashed line descending from it.
➢ The line is called the object lifeline, and it represents
the existence of an object over a period of time

Sequence Diagrams – Message Indicators

An Order Line A Stock Item ➢ Messages are rendered as

horizontal {check()} arrows

Check ()

[Check=”True”]
 being passed from object to
object as time advances down
the object lifelines.
➢ Conditions (such as [check =
“True”] indicate when a
message gets passed.
➢ Notice that the bottom arrow is
not solid, and there is no
accompanying message, this
indicates return from a previous
message not new message

Sequence Diagrams – Iteration Marker

An Order Line A Stock Item

*prepare () ➢ An iteration marker, such as *

(as shown) or *[I=1…n],
indicates that a message will
be repeated as indicated

Iteration Marker

15
Sample Sequence Diagrams:
(a)
(b)

16
ACTIVITY DIAGRAM
➢ Models the procedural flow of actions that are part of a larger activity
➢ Used to model system-level functions
➢ Focuses on the action sequence of execution and the conditions that
trigger or guard those actions.
➢ Has a very similar notations to that of a state machine diagram

Customer Calls Ticket Office

➢ An action is indicated by a “capsule” shape – a rectangular object with

semi-circular left and ends.
➢ The text inside it indicates the action (e.g., Customer Calls Ticket Office
or Registration Office Opens).

First Action To Do

➢ The initial state is drawn as a solid circle with a transition line (arrow) that
connects it to the first action in the activity’s sequence of actions.
➢ It is important to note that there can be only one initial state on an
activity diagram and only one transition line connecting the initial state
to an action.

Action 1

Action 2

The Figure above indicates INCORRECT rendering of an initial state within

an activity diagram.

➢ Arrows indicate directions, the transition lines on an activity diagram

show the sequential flow of actions in the modelled activity. It always
point to the next action in the activity’s sequence. 17
Activity Diagram – How a customer books a concert ticket.

Customer Calls
Ticket Office

Tickets Rep Asks What Event

Person Wants Ticket

Customer Tells Rep

Which Event

Ticket Rep Tells Customer

 18

The sample activity diagram documents the activity “Booking a Concert

Ticket,” with actions in the following order:
1. Customer calls ticket office.
2. Ticket rep asks what event person wants ticket for.
3. Customer tells rep event choice.
4. Ticket rep tells customer available seats and prices.
5. Customer tells rep seating choice.
6. Ticket rep reserves seats.
7. Ticket rep asks for credit card and billing address.
8. Customer gives requested information.
9. Ticket rep charges credit card.
10. Ticket rep mails tickets.
The action order is clear from the diagram because it shows an initial state
(starting point), and from that point one can follow the transition lines as
they connect the activity’s action. It is possible for an activity diagram to
show multiple final sates. Unlike initial state symbols, of which there can be
only one on an activity.

Decision points
Typically, decisions need to be made throughout an activity, depending
on the outcome of a specific prior action.
Make Sure
Customer is at
Least 21 years Old
[Drink is Alcoholic]

Customer
Orders Drink

[else] Get Drink for

Customer

➢ Each transition line involved in a decision point must be labelled with

text above it to indicate “guard conditions,” commonly abbreviated as
guards.
➢ Guard condition text is always placed in brackets—for example, [guard
condition text]
➢ A guard condition explicitly tells when to follow a transition line to the 19
next action
Merge points
Sometimes the procedural flow from one decision path may connect back
to another decision path. In these cases we connect two or more action
paths together using the same diamond icon with multiple paths pointing
to it, but with only one transition line coming out of it. This indicate a merge
decision point.

Tell Customer
to Order Non-
Alcoholic
Drink
 [Customer’s Age <21]
Make Sure
Customer is at
Least 21 years
Old
[Customer’s Age >=21]
[Drink is Alcoholic]
Customer
Orders
Drink
[else]
Get Drink for
Customer

A partial activity diagram, showing two decision points:

(“Drink is alcoholic” and “Customer’s Age <21”) and one merge
(“else” and “Customer’s Age >=21”)

1.1.4. Testing

What is Testing?
Testing is the process of evaluating a system or its component(s) with the
intent to find whether it satisfies the specified requirements or not. In simple
words, testing is executing a system in order to identify any gaps, errors, or 20
missing requirements in contrary to the actual requirements.
According to ANSI/IEEE 1059 standard, Testing can be defined as - A
process of analyzing a software item to detect the differences between
existing and required conditions (that is defects/errors/bugs) and to
evaluate the features of the software item.

Who does Testing?

It depends on the process and the associated stakeholders of the
project(s). In the IT industry, large companies have a team with
responsibilities to evaluate the developed software in context of the given
requirements. Moreover, developers also conduct testing which is called
Unit Testing. In most cases, the following professionals are involved in testing
a system within their respective capacities:
 Software Tester
Software Developer
Project Lead/Manager
End User
Different companies have different designations for people who test the
software on the basis of their experience and knowledge such as Software
Tester, Software Quality Assurance Engineer, QA Analyst, etc.
It is not possible to test the software at any time during its cycle. The next
two sections state when testing should be started and when to end it during
the SDLC.
When to Start Testing?
An early start to testing reduces the cost and time to rework and produce
error-free software that is delivered to the client. However in Software
Development Life Cycle (SDLC), testing can be started from the
Requirements Gathering phase and continued till the deployment of the
software.
It also depends on the development model that is being used. For example,
in the Waterfall model, formal testing is conducted in the testing phase; but
in the incremental model, testing is performed at the end of every
increment/iteration and the whole application is tested at the end.
Testing is done in different forms at every phase of SDLC:
➢ During the requirement gathering phase, the analysis and verification 21
of requirements are also considered as testing.
➢ Reviewing the design in the design phase with the intent to improve
the design is also considered as testing.
➢ Testing performed by a developer on completion of the code is also
categorized as testing.

When to Stop Testing?

It is difficult to determine when to stop testing, as testing is a never-ending
process and no one can claim that a software is 100% tested. The following
aspects are to be considered for stopping the testing process:
Testing Deadlines
Completion of test case execution
Completion of functional and code coverage to a certain point
 Bug rate falls below a certain level and no high-priority bugs are identified
Management decision

Verification & Validation

These two terms are very confusing for most people, who use them
interchangeably. The following table highlights the differences between
verification and validation.

S.N. Verification Validation

1 Verification addresses Validation addresses

the concern: "Are you the concern: "Are you
building it right?" building the right
thing?"

2 Ensures that the Ensures that the

software system meets functionalities meet
all the functionality. the intended
behavior.

3 Verification takes Validation occurs

place first and after verification and
includes the checking mainly involves the
for documentation, checking of the
code, etc. overall product.
22
4 Done by developers. Done by testers.

5 It has static activities, It has dynamic

as it includes activities, as it includes
collecting reviews, executing the
walkthroughs, and software against the
inspections to verify a requirements.
software.

6 It is an objective It is a subjective
process and no process and involves
subjective decision subjective decisions
should be needed to on how well a software
verify a software. works.

Software Testing - Myths

Given below are some of the most common myths about software testing.
Myth 1: Testing is Too Expensive
Reality: There is a saying, pay less for testing during software development
or pay more for maintenance or correction later. Early testing saves both
time and cost in many aspects, however reducing the cost without testing
may result in improper design of a software application rendering the
product useless.
Myth 2: Testing is Time-Consuming
Reality: During the SDLC phases, testing is never a time-consuming process.
However diagnosing and fixing the errors identified during proper testing is
a time-consuming but productive activity.
Myth 3: Only Fully Developed Products are Tested
Reality: No doubt, testing depends on the source code but reviewing
requirements and developing test cases is independent from the
developed code. However iterative or incremental approach as a
development life cycle model may reduce the dependency of testing on
the fully developed software.
Myth 4: Complete Testing is Possible
Reality: It becomes an issue when a client or tester thinks that complete
testing is possible. It is possible that all paths have been tested by the team
but occurrence of complete testing is never possible. There might be some
scenarios that are never executed by the test team or the client during the
software development life cycle and may be executed once the project
23
has been deployed.
Myth 5: A Tested Software is Bug-Free
Reality: This is a very common myth that the clients, project managers, and
the management team believes in. No one can claim with absolute
certainty that a software application is 100% bug-free even if a tester with
superb testing skills has tested the application.
Myth 6: Missed Defects are due to Testers
Reality: It is not a correct approach to blame testers for bugs that remain in
the application even after testing has been performed. This myth relates to
Time, Cost, and Requirements changing Constraints. However the test
strategy may also result in bugs being missed by the testing team.
Myth 7: Testers are Responsible for Quality of Product
Reality: It is a very common misinterpretation that only testers or the testing
team should be responsible for product quality. Testers’ responsibilities
include the identification of bugs to the stakeholders and then it is their
decision whether they will fix the bug or release the software. Releasing the
software at the time puts more pressure on the testers, as they will be
blamed for any error.
Myth 8: Test Automation should be used Wherever Possible to Reduce Time
Reality: Yes, it is true that Test Automation reduces the testing time, but it is
not possible to start test automation at any time during software
development. Test automaton should be started when the software has
been manually tested and is stable to some extent. Moreover, test
automation can never be used if requirements keep changing.
Myth 9: Anyone can Test a Software Application
Reality: People outside the IT industry think and even believe that anyone
can test a software and testing is not a creative job. However testers know
very well that this is a myth. Thinking alternative scenarios, try to crash a
software with the intent to explore potential bugs is not possible for the
person who developed it.
Myth 10: A Tester’s Only Task is to Find Bugs
Reality: Finding bugs in a software is the task of the testers, but at the same
time, they are domain experts of the particular software. Developers are
only responsible for the specific component or area that is assigned to them
but testers understand the overall workings of the software, what the
dependencies are, and the impacts of one module on another module.
24

1.1.5. Project Lifecycle Phases

What is Project Life Cycle?

The Project Life Cycle is a series of activities which are essential for
accomplishing project objectives or targets. Projects may have different
dimensions and difficulty level, but, whatever the size: large or small, may
be all projects could be mapped to the given lifecycle structure. This life
cycle for the project includes four phases-
• Initiation Phase
• Planning Phase
• Execution Phase
 • Monitoring, Controlling & Closing Phase

Project Life Cycle Diagram

25
1. Project Initiation Stage
Initiation phase defines those processes that are required to start a new
project. The purpose of the project initiation phase is to determine what the
project should accomplish.
This phase mainly composed of two main activities
• Develop a Project Charter and
• Identify Stakeholders
All the information related to the project are entered in the Project Charter
and Stakeholder Register. When the project charter is approved, the
project becomes officially authorized.
Project Charter
The Project Charter defines the project's main elements
• Project goals
 • Project constraints and Problem statements
• Assign project manager
• Stakeholder list
• High-level schedule and budget
• Milestones
• Approvals
This document allows a project manager to utilize organizational resources
for the sake of the project. To create a project charter, the inputs required
will be enterprise environment factor, business case, agreements, a project
statement of work and organizational process assets.
Identifying Stakeholders
A stakeholder can influence the success and failure of the project. To note
down the information about the stakeholder, a Stakeholder Register is used.
The stakeholder register will have information like
• Type of stakeholder
• Expectation of stakeholder
• Role in Project ( Business Analyst, Tech architect, Client PM)
• Designation (Director, Business Lead, etc.)
26
• Type Communication ( Weekly/Monthly)
• Influence on the project ( Partial/Supportive/Influensive)
The other activities involved in initiating process group are:
• Assigning the project manager
• Determining the stakeholder needs, expectations and high-level
requirements
• Define the project success criteria
• Identify particular budget for particular stage
• Make sure that the project is aligned with the organizations strategic
goal
The stakeholder register and project charter are used as inputs to the other
development groups such as planning process group.
2. Project Planning Stage
Project Planning phase covers about 50% of the whole process. Planning
phase determines the scope of the project as well as the objective of the
project. It begins with the outputs of initiation phase (charter, preliminary
scope statement, and project manager). The output of the planning phase
serves as the input for the execution phase.
The important aspects of planning process are
• Planning phase should not be executed before your initial planning
is finished
• Until the execution process does not start, you should not stop revising
plans
Create Work Breakdown Structure (WBS)
For any successful project WBS (Work Breakdown Structure) is important.
Following are steps to create WBS.
• Conduct a brainstorm to list all the tasks
• Involve your whole team for brainstorming
• Write down the structure tree of the task also known as WBS (work
breakdown structure)
• Further breakdown your top WBS into a hierarchical set of activities,
for instance, categories, sub-categories, etc. For example hardware,
software, trainee, management teams, etc.
27
• Define how to record the items into your WBS
• Ask other people - it can be an expert, experienced personnel, etc.
• Granularity- how detailed your task should you have? Estimating cost
and time for higher granularity is hard while for lower granularity it will
be bogged down with too detailed information
• Granularity should be of right level not too high or not too low
Planning Schedule Management
Plan Scheduling is the process of establishing the procedure, policies and
documentation for planning, managing, executing and controlling the
project schedule. The inputs in these activities include
• Project management plan
• Project Charter
• Enterprise environmental factors
 • Organizational process assets
The output of the Planning Schedule Management includes
• Schedule management plan
Defining Activities
Defining Activities is the procedure for documenting and identifying
specific actions to be performed to produce the project deliverables.

In define activities, each work packages is broken down into individual work
schedule activities. The inputs of the defining activities include
• Schedule management plan
• Scope baseline
• Enterprise environmental factors
• Organizational process assets
While the outputs of these activities are
• Activity list 28

• Activity attributes
• Milestone list
Sequence Activities
Sequence activities is nothing but logically organizing the output of "define
activities". It determines the order in which the activities needs to be
performed.

The main output from the sequence activity process is "Network Diagram".
Network diagram is nothing but posting the task on a board in a logical
order.
For example, you want to start a business in foreign country what will be
your list of activities and what will be the order it should be done?
You will perform activities in these order
1. Choose a country
2. Get business permit
3. Hiring a manager
4. Buying a property
5. Buying the furniture etc.
6. Opening the business
Estimating Activity Resources
This stage explains the process of estimating the work effort and resources
required to complete the task. The other factor that has to be considered
at this stage is the availability of the resources.
While estimating resources, the focus should be on the longest path of the
plan (Critical Path), which going to consume more time and money.
You have to estimate resources for two tasks
29
• Critical tasks
• Floating tasks
Make sure that your critical tasks are accurately estimated (completion
time).
There are five inputs used to estimate activity resources
• Schedule Management Plan
• Activity list
• Resource Calendar
• Enterprise environmental factors
• Organizational process assets
The output of this stage is
• Activity resource requirements
 • Resource breakdown structure
• Project documents updates
NOTE: All the activity that is done so far (define activities + sequence
activities + Estimate activity resources) is going to help in "Develop
Schedule."
Estimating Activity Durations
Estimating Activity Duration is the process of estimating the number of work
periods (weeks/months) required to complete the individual task with
estimated resources. This step defines how much time an individual task will
take to complete.
You cannot calculate activity duration without calculating the work effort
and resources required to complete the task. Estimating process should be
done in this order
• Estimate work effort first
• Followed by estimating the resources
• Followed by Estimating the duration of task
To estimate activity durations, you need inputs
• Activity list
• Activity attributes
• Resource calendars 30
• Project scope statement
• Organizational process assets
• Enterprise environmental factors
While there are two main outputs
• Estimate activity durations
• Estimate activity durations-project document updates
This technique is also referred as PERT (Project Evaluation and Review
Techniques) estimates.
Develop Schedule
Develop Schedule is the process of analyzing activity sequences, resource
requirements, durations and schedule constraints to create the project
schedule model. For scheduling each task, three main factors are taken
into consideration
• Duration
• Task dependencies
• Constraints
Using these factors project calculates the start date and finish date for
each task.
A scheduling software can be used to create a schedule. It generates a
schedule model with planned dates for completing project activities.
The input of this tool includes
• Schedule management plan
• Activity list
• Activity attributes
• Project schedule –network diagrams
• Activity resource requirements
• Resource calendars
• Activity duration estimates
• Project scope statement
• Risk register
31
• Project staff assignments
• Resource breakdown structure
• Enterprise environmental factors
• Organizational process assets
The output from this would be
• Project Schedule
• Project network diagram
• Gantt charts or Bar charts
• Milestone chart
• Schedule baseline
 • Scheduled data
• Project document updates
Control Schedule
The last stage of the planning phase is Control Schedule. It is the process of
monitoring the status of project activities to update project process and
manage changes to the schedule baseline.
If changes are required to the schedule, they must go through the change
control process. The schedule should be managed or controlled by
manager proactively.
There are four main outputs of control schedule process
• Project management plan
• Schedule baseline
• Schedule management plan
• Project schedule
• Work performance information
• Organizational process assets
There are five outputs of control schedule
• Work performance management
• Organizational process assets updates
• Change request 32
• Project management plan updates
• Project document updates
3. Project Execution Stage
The executing phase consists of those activities that are defined in project
management plan. This process involves managing stakeholder
expectations, coordinating with people and resources, as well as
performing other activities related to project deliverables.
During the execution phase, the result may require re-baselining and
updates to existing project requirements. Action taken in execution phase
may affect the project management plan or documents.
Direct and Manage Project Execution
This stage consumes most of the project cost, time, and resources as this is
the process that produce project deliverables.
There are four inputs to Direct and Manage Project Execution
• Project Management Plan
• Approved change request
• EEFs (Enterprise Environmental Factors)
• OPAs (Organizational Process Assets)
While there are five outputs
• Deliverables 33

• Work performance data

• Change request
• Project Management plan updates
• Project documents updates
During this stage, expert's judgments, meetings, and reporting KPI (Key
Performance Indicators) are of prime importance.
Performing Quality Assurance
Performing Quality Assurance is the process of auditing the quality
requirements and the results from quality control measurements. It is the
process of recording and monitoring results of the quality activities to assess
performance. Various tools like control charts, cost-benefit analysis,
flowcharting, run charts, scatter diagrams, inspection & reviews, etc., can
be used for this process.
The main input to this is
• Project management plan
• Quality metrics
• Quality control measurements
• Work performance information
While, the output of this is
• Change request
• Project management plan updates
• Project document updates
• Organizational process assets updates
Acquiring Project Team
During the execution phase, project team acquiring takes place, this is
because it is more likely that individuals with different skill set will be required
during the process.
There are three main inputs to acquire project team
• Roles and responsibilities
• Project organization chart
• Staffing management plan
While there are three outputs 34
• Project staff assignments
• Resource calendars
• Project management plan updates
Develop Project Team
The majority of human resource processes involves in executing process,
developing project team is also a part of it. The main purpose of developing
project team is to improve the overall performance of team members. This
stage must start early on in the project.
The inputs in project development team include
 • Human resource management plan
• Project staff assignments
• Resource calendars
Output of this process include
• Team performance assessments
• EEFs Updates
Manage project team
Managing project team is one of the important parts of project
management. It is the most complex area of project management
because many times managers would not be in direct contact with team
members, in such situation to analyze their performance and deciding their
remuneration becomes difficult.
There are five inputs to manage project team process
• Project staff assignments
• Team performance assessments
• Performance reports
• Project management plan
• Organizational process assets
There are four main outputs
• Organizational process assets updates
• Enterprise environmental factors updates
• Change request 35
• Project management plan updates
Manage Communications
Out of three communication attributes, one falls in the execution process.
In communication management program, there are three main
communication aspects that need to monitor.
1. Project team members to the project manager
2. Project managers to the program manager
3. Program manager to stakeholders or other sponsors
The input of managing communications include
• Communications management plan
• Work performance reports
• EEFs
• OPAs
The output of this stage would be
• Project communications
• Project management plan updates
• Project documents updates
• OPAs updates
Conduct Procurements
In this stage, there are two main roles involved the buyer and the seller.
During the procurement process the activities involved are
1. Issue the bid package to potential sellers
2. Hold bidder conferences
3. Evaluate potential seller proposals
4. Select the winning seller proposals
The output of the procurement process include
• Project management plan
• Conduct procurement documents
• Source selection criteria 36
• Qualified seller list
• Seller proposals
• Project documents
• Make or buy decisions
• Partnership agreement (teaming agreement)
• Organizational process assets
While, you will have six outputs
• Selected sellers
 • Procurement contract award
• Resource calendars
• Change requests
• Project management plan updates
Manage Stakeholder Engagement
This stage includes actively managing stakeholders throughout the project.
To avoid unexpected project delay or abandoning the project in between,
stakeholder expectation is identified and quickly resolved.
There are five inputs to manage stakeholder process
• Stakeholder register
• Stakeholder management strategy
• Project management plan
• Issue log
• Change log
• Organizational process assets
The output of this process include
• Organizational process assets updates
• Change request
• Project management plan updates
• Project documentation updates
Project Phase Review 37
At the end of execution phase, project phase review is done. It helps you
to document in following activities
• Document the result of your project management review
• Inform the sponsor about the progress of the project
• Identifying any risk or issues that impacted the project
• Shows deliverable to stakeholder produced during the project
• Seek approval to proceed to the next phase
4. Project Monitoring and Controlling & Closing Stage
After execution phase, to check the project is on right track, monitoring
and controlling phase becomes active. During this phase various changes
and reviews to enhance the project performance is done.
Monitor and Control Project Work
This stage involves tracking, reviewing and regulating the progress in order
to meet the objective of the project. It also ensures that the deliverables
are according to the project management plan. The main focus of this step
is to identify any changes made from the point of project management
plan to determine appropriate preventive action.
The inputs for this stage include
• Project management plan
• Performance reports
• Cost forecasts
• Schedule forecasts
• Validate changes
• Enterprise environmental factors
• Organizational process assets
While the output includes
• Change requests
• Project management plan updates
• Project document updates
Perform Integrated Change Control
38
It is one of the most important process of project management. It is in this
stage where the impact of any change is assessed against the project. If a
change in this stage occurs at any one part of a project, the whole project
will be assessed. It is better to implement changes at an early stage of the
project, because as the project progresses, the cost of implementing
changes also increases.
The input of this stage includes
• Project management plan
• Work performance reports
• Change requests
 • EEFs
• OPAs
While the outputs are
• Approved change requests
• Change log
• Project management plan updates
• Project document updates
Validate Scope
Validating scope involves verifying whether the deliverables meet the
customer acceptance criteria. The external checking with the customer or
stakeholders are part of Validating Scope Management.
The inputs for validating scope includes
• Project management plan
• Requirements
• Documentation
• Requirements traceability matrix
• Verified deliverables
• Work performance data
While the output of the scope validation includes
• Accepted deliverables
• Change requests
• Work performance information 39
• Project document updates
Control Scope
Control scope ensures that it is the only work identified as being in scope
that is delivered. The actual result is compared against the scope baseline
and ensures that all of the approved scope is in fact being delivered.
The inputs to control scope process includes
• Project management plan
• Work performance information
 • Requirement documentation
• Requirements traceability matrix
• Organizational process assets
While the output includes
• Work performance measurements
• Organizational process assets updates
• Change requests
• Project management plan updates
• Project document updates
Control Schedule
Control Schedule process helps you in many ways. It helps you to capture
current schedule status, determine the variance from the schedule
baseline, understand the nature of the variance and respond by taking
appropriate action.
If changes are needed to the schedule then they must go through the
change control process, the change should be re-evaluated and only then
it should be used to update the schedule baseline.
There are four main inputs to the control schedule
• Project management plan
• Schedule baseline
• Schedule management plan
• Project schedule
• Work performance information 40
• Organizational process assets
The output includes
• Work performance measurements
• Organizational process assets updates
• Change requests
• Project management plan updates
• Project document updates
Control Cost
Control cost is comparing baseline cost for each deliverable against the
actual cost. The cost baseline should change only in response to a change
request that has gone through the Perform Integrated Change Control
process. Control cost ensures that your project stay within funding
limitations.
The inputs for the Control Cost include
• Project management plan
• Project funding requirements
• Work performance information
• Control Cost Organizational process assets
The output for this include
• Earned value work performance measurements
• Earned value budget forecasts in control costs
• Change requests
• Project management plan updates
• Project document updates
• Organizational process assets updates
Control Quality
The control quality ensures that the project and product are delivered with
the quality management plan. It ensures that whether the work is
performed correctly. The major output of the control quality is Quality
management plan. While the other information that will be helpful are
• Existing flowchart 41
• Upper and lower control and specification limits contained within the
control charts
• Information is referenced such as sample criteria, sampling numbers,
measurements and variable sampling
• Quality metrics- it is a standard measurement to meet the quality
requirements
• It ensures that the proper steps are being followed in order to comply
with aspects such as process, policies or regulations
There are four main outputs from the perform quality control process:
• Integrated change control
• Approved change requests
• Approved change requests review
• Validated changes
Control Communications
Control communication ensures that the right information reaches to the
stakeholder. Control communication information includes inputs, tools and
techniques and output that belong to this process.
Control communication can be in any format, it can be
• Trending data
• Tabulated information
• S-curve
• Dashboard formats
• Use histogram
In control communication process, work information is taken from various
other processes, and the performance report is used as an input for various
monitoring and managing processes. The main deliverables from the
control communication process is the performance record.
Control Risks
Throughout the project cycle, risk analysis is a continuous process. It is
important that you continuously analyze, identify and respond to risks. The
activities include in control risk are
• Tracking existing risks 42
• Monitoring residual risks
• Identifying new risks
• Implementing risk response plans
• Continuously evaluating risk process
The input for control risk are
• Risk register
• Work performance information
 • Performance reports
• Reserve analysis
• Risk Audits
The output for the control risk are
• Updating risk register
• Risk management plan
Control Procurements
Out of four procurement plan, the third process of procurement falls in
Monitoring & Executing process group. This stage involves monitoring the
vendor's performance and ensuring that all contract requirements are
being met.
The control procurement process involves verifying
• Whether goods or service being delivered
• Whether it is delivered on time
• Whether invoice charged is for correct quantity
• Whether all conditions of the contract being met
• Whether the relationship between buyer or seller are managed
properly
The major input for procurement process are
• Project management plan
• Procurement documents
• Agreements
• Approved change requests 43
• Work performance reports
• Work performance data
The output for procurements are
• Work performance information
• Change requests
• Project management plan updates
• Project document updates
 • OPAs updates
Control Stakeholder Management
Many project stumble due to inadequate management of stakeholders. If
the stakeholders are managed properly, there are more chances for
project success. In this process, we monitor the current engagement level
of stakeholders and take actions accordingly.
The input and output for all these activities include

Input Output

• Plan Stakeholder Management • Work performance

information

• Issue log • Change requests

• Work performance data • Project management

plan updates

• Project documents • Project documents

updates

• OPAs updates

Closing- Phase
Closing phase is the process that performs a controlled shut down of the
project at the end. In a project, there are three closure activities that are
going on 44
• Closure of the product- Getting the customer to accept the final
deliverables, if the project is external
• Closure of the project- This include formally closing of administrative
procedures, updating project documents and archiving those
databases & documents
• Closure of the resource behind the project- The financial closure of
the project, resources assigned to the project should be returned
The inputs for this process include
• Project Management Plan
 • Accepted Deliverables
• OPAs
The output of this process include
• Final output, service or result transition
• OPAs updates
Close Procurements
For each project development life cycle phase- planning, executing,
monitoring and controlling & closing there is one procurement process. The
final closing procurement is done as per the contract between the seller
and buyer.
The closing activities and deliverables include:
• Project performance reviews including management of risks and
issues
• Updated project management plan to reflect actual results
• Final reports distributed to appropriate stakeholders
The input for closing procurement include
• Project management plan
• Procurement documents
While the output include
• Closed procurement
• OPAs updates
Project Management Ethic of code and conduct
45
In the end, you will come across project management ethic of code and
conduct which deals various human behavioral aspects such as
• Responsibility
• Respect
• Fairness
• Honesty
• Cultural Competence
This code is practiced to induce the confidence and bring a common
frame of behavior in the project manager.
Summary:
Initiation phase defines those processes that are required to start a new
project. It defines what project should accomplish in due course of time.
The initiation phase mainly composed of two main activities
• Develop a Project Charter
• Identify Stakeholders
The stakeholder register and project charter are also useful in other process
groups of project management like planning process.
Planning phase determines the scope as well as the objective of the
project. It involves creating a set of plans that guides you through the
execution and closure phases of the project.
The executing phase consists of those activities that are defined in project
management plan. It is the longest phase of the project life cycle and
consumes maximum energy and resources. Action taken in execution
phase may affect the project management plan or documents.
Key task in execution phase are
• Execute Project Management Plans
• Direct and Manage Project Execution
• Execute Task Assignments
• Conduct Progress Status Meetings, etc.
During the execution phase, the result may require re-baselining and
updates to existing project requirements.
46
Monitoring and controlling stage ensures that the deliverables are
according to the project management plan before closing phase.
The main focus of this phase is to identify any changes made from the point
of project management plan to determine preventive action against any
unexpected result.
Closing phase is the process that performs a controlled shut down of the
project at the end.
 TASK SHEET 1 47
Label correctly the Requirements Life Cycle below and briefly discuss
each of the phase.
1.______________________

2.______________________

3.______________________

4.______________________

TASK SHEET 2 48
Illustrate the steps of the Enrolment System (present system) in the institution
using Use Case Model. Discuss in details your interaction with the system.
Label completely and correctly everything in the diagram. Use your
personal data if needed in your discussion.
 TASK SHEET 3 49
Considering your Use Case Model of the JHCSC Enrolment System above,
make its corresponding Activity Diagram. List down all the actions found in
the diagram.
 LESSON 2 50

Acquisition and Sourcing

Learning Outcomes
At the end of the lesson, you should be able to:
• Identify institutions/organizations in the locality that are
implementing automated systems.
• Differentiate the processes of a manual system and an
automated system.
• Compare the advantages and disadvantages of
Insourcing and Outsourcing Acquisition.

1.2.1 In-sourcing and Outsourcing

The alternative of insourcing is generally recommended when we are
facing very complex contexts that demand a very particular expertise or
when the company is able to respond to the software needs required with
infrastructure, personnel, and a high specialization component.
When the company already has this component of specialization in this
area (because it has a solid development or IT team with qualified
personnel), it can achieve a competitive advantage over its competitors.
Here are some examples where insourcing is convenient:
51
• Complexity and high business specialization: When a business is
focused on a very small or specific market niche, there may be
difficulties in finding specialized personnel, software, or hardware. In
these cases, it is convenient to do an in-house development to
protect this asset.

• Advantage over its competitors: When a company is a pioneer in a

development or business area, it is likely that it will aim to maintain
 this advantage it has over its competitors by resorting to the
personnel within the organization. Something similar happens when
the business demands a constant technological update since it is
important to keep it internal.
• Business confidentiality: There are certain companies in which the
development is a strategic pillar of their business and cannot interrupt
it at any time, or when the information security is vital, so it can lead
to these organizations forming an internal department over which
they have total and absolute control.
• Maintenance savings: Sometimes, the maintenance services of ERP
systems (or similar) can be high, therefore justifying insourcing.
On the other hand, we have outsourcing where an organization delegates
a portion of its business process to a third party since it could be performed
more efficiently by that other company.
Outsourcing frees the organization from this responsibility and helps it to
focus on the core function of its business since the outsourcing company
has the tools and methodologies to work on its client’s software needs.
In line with this argument, here are some of the advantages that IT
outsourcing brings:
• Updating, specialization, and further qualification: A great
advantage of outsourcing is having personnel more qualified in the
development (new technologies, methodologies, programming
languages, testing, etc.). Many times, these capabilities are limited
when the in-house team is small or has little expertise.

52
 • Equal conditions: It allows companies with small structures to
compete and provide services that would otherwise cost them a lot
(time and money) to obtain.
• Good practices: The value that an external company brings is the
sum of its experience in different projects and in diverse
industries/technologies. A large number of successful cases with
other clients and users makes it possible to perceive the origin of
problems and their solutions more quickly.
• Transforming fixed costs into a variable: At first it may not be
noticeable, but in the mid and long term, outsourcing avoids certain
less direct costs, such as staff turnover, holidays, or layoffs, which are
not considered when outsourcing.
• Fast capacity increase: Hiring an external technological
partner permits the company to increase its capacity to develop
certain activities in which it is not specialized, allowing for such
development to be delegated to specialized organizations.
TO SUM UP
With these criteria, choosing an IT outsourcing model over
an insourcing one is more than justified for many small and medium-sized
corporations; however, it is always essential to analyze the pros and cons
that each model brings to your business to make the right choice.

1.2.2 System Architecture: Hardware, Software, and Virtual

➢ The word “architecture” is derived from the Greek word “architecton”,
which means master mason or master builder

➢ Webster’s Dictionary defines architecture as: 53

The art or science of designing or building structures
The structure (in terms of components, connections, and constraints)
of a product, process, or element – The Art of Systems Architecting

➢ An Architecture is the highest-level concept of a system in its

environment – IEEE

➢ Architecture – The fundamental organization of a system embodied in

its components, their relationships to each other and to the environment
and the principles guiding its design and evolution
➢ Systems Architecture – The fundamental and unifying system structure
defined in terms of system elements, interfaces, processes, constraints,
and behaviors – (INCOSE SAWG)
➢ Architecture – The organizational structure of a system of CSCIs,
identifying its components, their interfaces and a concept of execution
among them

➢ The architecture of a system defines its high-level structure, exposing its

gross organization as a collection of interacting components.
➢ Components needed to model a software architecture include:
• Components, Connectors, Systems, Properties and Styles.
Components
▪ The computational elements and data stores of the system
▪ May have multiple interfaces, called ports
▪ Ports define a point of interaction between a component and its
environment

Connectors
▪ Model interactions among components
▪ Runtime perspective: connectors mediate the communication and
coordination activities between components
▪ Connectors may have interfaces that define the roles played by the
participants in the interaction

Systems 54
▪ Graphs of components and connectors
▪ Tend to be hierarchical – components and connectors may
represent subsystems that have their own internal architectures
▪ Bindings map the interfaces of one level of a system to another

Properties
▪ Represent the non-structural information about the parts of an
architecture description
▪ Example: a connector can be a function call, or a network
interaction
▪ Properties can be attached to any architectural element
Style
▪ An architectural style represents a family of related systems
▪ Defines the design vocabulary (and constraints) for the components,
connectors, ports, roles, bindings and properties.

System Architect
▪ The architect is a member of the team that is responsible for
designing and building a system
▪ The architect’s contribution comes in the very early stages of the
systems engineering process
▪ When the operational concept is defined
▪ The basic structure of the system is conceptualized
▪ A system architect, not only knows about the individual components,
but also understands the interrelationships among the components

System Architecting
▪ Systems Architecting has been defined as the process of creating
complex, unprecedented systems
▪ Building systems in today’s world is tenuous at best
o Requirements of the marketplace are ill-defined
o Rapidly evolving technology provides new services at a global
level instantly
55
o Uncertainty is increasing about the way the system will be
used, the components that will be incorporated and the
interconnections that will be made

▪ Generating a system architecture as part of the systems engineering

process can be seen as a deliberate approach to deal with the
uncertainty that characterizes these complex, unprecedented
systems

Traditional Approach to System Architecting

• Many methodologies have been developed to support a traditional
system development model
– Define the requirements
– Consider several options
 – Emerge with a well-defined design through a process of
elimination
– Based on structured analysis and design
• Effective when the requirements are well defined and remain
essentially constant during the system development period
– Cannot handle change well
• If the implementation of the system is long – on the order
of years – the requirements change because of
changing needs and new technology offers different
alternatives and opportunities

The Traditional Approach

Evolutionary Approach
• New approach that is emerging with roots in software systems
engineering
• Deals with uncertainty in requirements and in technology, especially
for systems with a long development time and expected long life
cycle
– Evolutionary development 56
– Build-a-little, Test-a-little
• Requirements are allowed to be more abstract and therefore subject
to interpretation
• Alternative solutions are explored and pursued further as new
technology options become available
• Intermediate designs are saved
• Some intermediate designs are implemented as prototypes but not
operationally implemented while others are implemented in
traditional ways
 • Advantages of Object-Oriented approach:
– Allows flexibility in the design as it evolves over time
• Disadvantages of Object-Oriented approach:
– Requires some early elimination of technology alternatives in
the absence of reliable information

The Evolutionary Approach

Select, Build, and Field
• At any time in the development process, when there is a need to
build a system, the available solution that best meets the current
requirements is selected and implemented using any systems
engineering approach
57
 Select, Build, and Field

How to Define Architecture

• Defining an architecture, especially of an information system,
requires the following items to be described:
– Processes exist that need to take place in order that the system
accomplish its intended functions
– The individual processes transform either data or materials that
“flow” between them
– The processes or activities or operations follow rules that
establish the conditions under which they occur
– The components that will implement the design (hardware,
software, personnel, and facilities must be described)

• Define the Functional Architecture

– A functional architecture is:
• A set of activities or functions that are arranged in a
specific order and when activated, achieves a set of
requirements
• Divide and allocate the functional requirements into
different sub-functions and modes of operation

• Define the Physical Architecture 58

– A physical architecture is:
• A representation of the physical resources
• Expressed as nodes that constitute the system and their
connectivity
• Expressed in the form of links
• Define the technical architecture
– A minimal set of rules governing the arrangement, interaction,
and interdependence of the parts or elements that must
 ensure that a conformant system satisfies a specified set of
requirements
– Provides the framework upon which engineering specifications
can be derived, guiding the implementation of the system
– Analogous to the building code that provides guidance for
new buildings to be able to connect to the existing
infrastructure by characterizing the attributes of that
infrastructure

Operational Concept
• An important task in the architecture development process is to
define the operational concept
– A concise statement that describes how the goal will be met
– How will the system look and act in the operational
environment
• Operational Concept Definition Parts
– How the system operates
– Where in the operating environment the system will be
distributed
– How long the system must operate
– How effective the system’s performance must be
• An operational concept is a shared vision from the perspective of the
system’s stakeholders of how the system will be:
– Developed
– Produced
– Deployed 59
– Trained
– Used and maintained
– Refined
– Retired
• The operational concept includes a collection of scenarios – one for
each group of stakeholders for each relevant phase of the system’s
lifecycle
 – Each scenario addresses one way that a particular
stakeholder will want to use, deploy, fix, etc., the system and
how the system will respond to a produce a desired end
– Scenario - a sequence of events which might occur that
includes the interaction of the product with its environment
and users, as well as the interaction among its product
components

Executable Model
ᴥ The functional, physical, and technical architectures are static
representations that attempt to describe the dynamic behavior of
the architecture
ᴥ In order to analyze the behavior of the architecture and evaluate
the performance characteristics, an executable model is needed

Architecture Development Process

ᴥ The architecture development process consists of three phases:
➢ Analysis Phase – The static representatives of the functional
and physical architectures are obtained using the operational
concept to drive the process and the technical architecture
to guide it
➢ Synthesis Phase – The static constructs are used, together with
descriptions of the dynamic behavior of the architecture to
obtain the executable operational X-architecture (X =
executable property)
➢ Evaluation Phase – Measures of performance (MOP) and
measures of effectiveness (MOE) are obtained

60
 The Three-Process Architecture Development

1.2.3 Contracts and RFPs

An RFP offers your organization the invaluable opportunity to recruit the
best possible vendors for your particular project. Many technology projects
must satisfy a large list of requirements, most of which will have a variety of
possible solutions. Understanding just how each vendor will approach your
specific requirements helps you to understand which vendor — and
solution — is the best fit for your needs. Asking potential vendors to provide
detailed information early on can save your organization a lot of money
and headaches down the road.
Elements of an RFP
Before you circulate your RFP, ensure that it is comprehensive by
considering the following elements.
✔ Organizational Overview
Provide a short description of your organization’s mission and projects. This
gives the vendor some background and focus as to the needs of the
project.
✔ Project Goals
61
Identify the programmatic goals of the project. This allows the vendor to
see how the project will serve the needs of the organization, and whether
it fills a particular niche or program area or is a system that offers general
support to numerous organizational goals.
✔ Target Audience
Describe who will be using the project deliverables and how large that
audience is. Include any significant technical needs your audience may
have. Describe how they will interact with the site, the organization, and
each other throughout the project.
✔ Project Deliverables and Specifications
Identify the major components of the project. Describe the required
features and design of each component, along with the support services
you will require from the vendor both during development and after the
project launch. The more details here, the more accurate the cost
estimates will be. For areas where there are few rigid requirements, outline
your goals and invite proposals for creative solutions.
✔ Project Requirements
Describe the administrative requirements and guidelines for the project,
including completion dates, expectations on project testing and
evaluation during development, intellectual property rights, billing
requirements, and the maximum price range vendors should bid within.
(Note that this price range should be lower than your internal budget for
the project. Always allow yourself space to negotiate up if
necessary.) Indicate where you want vendors to contribute their own
recommended solutions, and where they should adhere to your exact
specifications.
✔ Proposal Format
Describe the elements required in vendor bids, such as budget and cost
breakdown per deliverable; tasks and timeline chart; staff roles and
responsibilities; and vendor description. Outlining these elements ensures
that vendors will give you what you want, and allows you to directly
compare (and filter out) vendors.
✔ Request for References
Describe what information you require in references, such as how recent or
long-term the clients were, what kinds of clients you would like to hear from,
what kind of contact information you need, whether they are current or
past clients, and so on.

62
✔ Proposal Delivery Instructions and Contact Information
To whom should proposals be addressed? How many copies should be
sent? How should they be delivered (fax, email, mail), and who is the point
of contact for phone inquiries? Is this a closed “by invite only” RFP or open,
meaning you allow (or encourage) vendors to share this proposal?
✔ Proposal Evaluation Timeline
Identify the vendor selection process and timeline. Consider that vendors
may provide useful feedback during phone calls that necessitate changing
a part of the RFP — schedule this in so bidders know when to expect more
clarifications. Adhering to a set process communicates to vendors that you
know what you are doing. Vendors often spend non-billable time on
proposal writing, so managing their expectations of your process helps build
harmonious relationships.
Beware of the Feature List
Don’t over-rely on feature lists of the specific functionality you are looking
for! While it is important to outline what you need, too much detail can result
in bidders who simply deliver to your specification, without thinking
strategically. Overly detailed features lists discourage vendors from offering
their best approach to meeting your goals and can lock you into particular
solutions or approaches. A feature list moves you away from goals and
toward technologies — the expertise of the vendor you hope to hire. In
insisting on a specific collection of web tools, you risk missing out on the
best-considered solutions for your particular project.
Disseminating Your RFP
Depending on your project needs, you may choose to target your RFP to
specific firms, or broadly to attract more responses. A closed RFP approach
targets a smaller group of known firms — vendors that have come
recommended from trusted sources or that you have worked with
successfully in the past. By closing the RFP, you are indicating that only
invited firms may respond. This approach works well if you have a network
of vendors already and the project is an overall match to their skill sets.
Working with a consultant can help if you still want a closed process but
need help identifying recommended vendors.
63
Following an open process helps to attract more responses. An open
process can help especially in situations where there may be a wide variety
of approaches to meeting your needs, which can result in bigger cost and
timeline disparities between responses. There are many resources for listing
RFPs, some general and others that target specific industry sectors. Some
example resources include The RFP Database (which you can access
through its main website as well as via LinkedIn), The Foundation
Center(which lists philanthropy/nonprofit RFPs), and FindRFP (which helps
connect government contractors and buyers).

1.2.4 Quality

What is a Quality System?

According to the ASQ glossary, a quality management system (QMS,

alternatively “quality system”) is a mechanism for managing and
 continuously improving core processes to “achieve maximum customer
satisfaction at the lowest overall cost to the organization”. By bringing
together philosophies, standards, methodologies and tools, the QMS helps
an organization achieve its quality-related goals.

A quality system is a specific implementation of quality

philosophies/concepts, standards, methodologies and tools, for the
purpose of achieving quality-related goals. When implemented, a quality
system will be unique to an organization. Its structure, however, may be
similar to quality systems in other organizations (for example, if all ISO 9001
clauses are addressed).

Components of a Quality System

The International Organization for Standardization (ISO) prescribes a

minimum standard for the elements of a QMS through ISO 9001:2000. (This
part did not change in ISO 9001:2015).

To build an ISO 9001 compliant QMS, you need to:

• Identify and map processes (administrative, organizational, operational)

• Determine how processes are interrelated (that is, identify and map cross-
cutting activities that span organizational boundaries)
• Plan for operations and control of these processes, recognizing that the
conditions and specifications for control of each of the processes may be
different from one another,
• Plan for dynamically allocating resources to accommodate the demands
of the operations and control of these processes,
• Apply systems thinking and describe the environment that your
interdependent processes are embedded within, 64
• Identify mechanisms to measure, monitor, analyze and continuously
improve the processes in the context of the organization and its
environment
• Establish an Action Plan for proactively deploying the QMS through the
organization, and
• Ensure that Records are kept that track compliance to the QMS and
changes that are made to the QMS itself.

Characteristics of a Quality System

A quality characteristic is an inherent characteristic of a product that says
something about as aspect of the quality of the product. The use of a set
of quality characteristics is recommended as a way to check for
completeness of your test. It allows you to check that, out of all the aspects
or characteristics of a system or package under test, a careful decision has
been made about whether or not to test these.

This is a list of quality characteristics. This is a general list for software

development - for specific circumstances specific quality characteristics
can be of importance and the list can be expanded to fit your specific
situation.

Connectivity
The ease with which an interface can be created with another information
system or within the information system, and can be changed.

Connectivity is tested statically by assessing the relevant measures (such as

standardization) with the aid of a checklist. The testing of connectivity
therefore concerns the evaluation of the ease with which a (new) interface
can be set up or changed, and not the testing of whether an interface
operates correctly. The latter is normally part of the testing of functionality.

Continuity
The certainty that the information system will continue without disruption,
i.e. that it can be resumed within a reasonable time, even after a serious
breakdown.

The continuity quality characteristic can be split into characteristics that

can be applied in sequence, in the event of increasing disruption of the
information system:

• Reliability:
o the degree to which the information system remains free of
breakdowns
o
• Robustness: 65
o the degree to which the information system can simply
proceed after the breakdown has been rectified
• Recoverability:
o the ease and speed with which the information system can be
resumed following a breakdown
• Degradation factor:
o the ease with which the core of the information system can
proceed after a part has shut down
• Fail-over possibilities:
o the ease with which (a part of) the information system can be
continued at another location.
Continuity can be tested statically by assessing the existence and setup of
measures in the context of continuity on the basis of a checklist. Dynamic
implicit testing is possible through the collecting of statistics during the
execution of other tests. The simulation of long-term system usage
(reliability) or the simulation of breakdown (robustness, recoverability,
degradation and fail-over) are dynamic explicit tests.

Data controllability
The ease with which the accuracy and completeness of the information
can be verified (over time).

Common means employed in this connection are checksums, crosschecks

and audit trails. Verifiability can be statically tested, focusing on the setup
of the relevant measures with the aid of a checklist, and can be
dynamically explicitly tested focusing on the implementation of the
relevant measure in the system.

Effectivity
The degree to which the information system is tailored to the organization
and the profile of the end users for whom it is intended, as well as the
degree to which the information system contributes to the achievement of
the company goals.
66
A usable information system increases the efficiency of the business
processes. Will a new system function in practice, or not? Only the users’
organization can answer that question. During (user) acceptance tests, this
aspect is usually (implicitly) included. If the aspect of usability is explicitly
recognized in the test strategy, a test type can be organized for it: the
business simulation. During a business simulation, a random group of
potential users tests the usability aspects of the product in an environment
that approximates as far as possible the “real-life” environment in which
they plan to use the system: the simulated production environment. The test
takes place based on a number of practical exercises or test scripts. In
practice, the testing of usability is often combined with the testing of user-
friendliness within the test type of usability.

Efficiency
The relationship between the performance level of the system (expressed
in the transaction volume and the total speed) and the volume of resources
(CPU cycles, I/O time, memory and network usage, etc.) used for these.

Efficiency is tested with the aid of tools that measure the resource usage
and/or dynamically implicitly by the accumulation of statistics (by those
same tools) during the execution of functionality tests. This aspect is often
particularly evident with embedded systems.

Flexibility
The degree to which the user is able to introduce enhancements or
variations on the information system without amending the software.

In other words, the degree to which the system can be amended by the
user organization, without being dependent on the IT department for
maintenance. Flexibility is statically tested by assessing the relevant
measures with the aid of a checklist. Testing can take place during the
(user) acceptance test, by having the user create, for example, a new
mortgage variant (in the case of mortgages) or (in the case of credit
cards), change the way of calculating the commission, by changing the
parameters in both cases. It is often tested in this way first, before the
change is actually implemented in production.

Functionality
The degree of certainty that the system processes the information
accurately and completely.

The quality characteristic of functionality can be split into the

characteristics of accuracy and completeness:

• Accuracy:
o the degree to which the system correctly processes the
supplied input and mutations according to the specifications
into consistent data collections and output
• Completeness:
o the certainty that all of the input and mutations are being
processed by the system.
67
With testing, meeting the specified functionality is often the most important
criterion for acceptance of the information system. Using various
techniques, the functional operation can be dynamically explicitly tested.

(Suitability of) Infrastructure

The appropriateness of the hardware, the network, the system software, the
DBMS and the (technical) architecture in a general sense to the relevant
application and the degree to which these infrastructure elements
interconnect.
The testing of this aspect can be done in various ways. The tester’s expertise
as related to the infrastructural elements concerned is very important here.
More on infrastructure testing can be found in InfraTesting with TMap.

Maintainability
The ease with which the information system can be adapted to new
requirements of the user, to the changing external environment, or in order
to correct faults.

Insight into the maintainability is obtained, for example, by registering the

average effort (in the number of hours) required to solve a fault or by
registering the average duration of repair (Mean Time to Repair (MTTR)).
Maintainability is also tested by assessing the internal quality of the
information system (including associated system documentation) with the
aid of a checklist. Insight into the structuredness of the software (an aspect
of maintainability) is obtained by carrying out static tests, preferably
supported by code analysis tools.

Manageability
The ease with which the information system can be placed and maintained
in an operational condition.

Manageability is primarily aimed at technical system administration. The

ease of installation of the information system is part of this characteristic. It
can be tested statically by assessing the existence of measures and
instruments that simplify or facilitate system management. Testing of system
management takes place by, for example, carrying out an installation test
and by carrying out the administration procedures (such as backup and
recovery) in the test environment.

Performance
The speed with which the information system handles interactive and batch
transactions. More on performance testing in the building block.

Portability 68
The diversity of the hardware and software platform on which the
information system can run, and the ease with which the system can be
transferred from one environment to another.

Reusability
The degree to which parts of the information system, or of the design, can
be used again for the development of other applications.
If the system is to a large extent based on reusable modules, this also
benefits the maintainability. Reusability is tested through assessing the
information system and/or the design with the aid of a checklist.

Security
The certainty that consultation or mutation of the data can only be
performed by those persons who are authorized to do so.

Suitability
The degree to which the manual procedures and the automated
information system interconnect, and the workability of these manual
procedures for the organization.

In the testing of suitability, the aspect of timeliness is also often included.

Timeliness is defined as the degree to which the information becomes
available in time to take the measures for which that information was
intended. Suitability is tested with the aid of the process cycle test.

Testability
The ease and speed with which the functionality and performance level of
the system (after each adjustment) can be tested.

Testability in this case concerns the total information system. The quality of
the system documentation greatly influences the testability of the system.
This is measured with the aid of the “testability review” checklist during the
Preparation phase. Also for the measuring of the testability of the
information system a checklist can be used. Things that (strongly) benefit
the testability are:

• Good system documentation.

• Having an (automated) regression test and other testware.
• The ease with which interim results of the system can be made visible,
assessed and even manipulated.
• Various test-environment aspects, such as representativeness and an
adjustable system date for purposes of time travel.

User-friendliness 69
The ease of operation of the system by the end users.

Often, this general definition is split into: the ease with which the end user
can learn to handle the information system, and the ease with which
trained users can handle the information system. It is difficult to establish an
objective and workable unit of measurement for user-friendliness. However,
it is often possible to give a (subjective) opinion couched in general terms
concerning this aspect. User-friendliness is tested within the test type
of Usability.

TASK SHEET 1 70
List down at least three (3) institutions (excluding JHCSC System) that you
have experienced dealing with. Identify their respective automated system
implemented in their operation and discuss 2 of the most used
modules/processes of their automated system.
1.
(a)Name of the Institution:

___________________________________
(b)Automated System:
___________________________________
(c)Modules/Processes:
___________________________________
___________________________________
2.
(a)Name of the Institution:

___________________________________
(b)Automated System:
___________________________________
(c)Modules/Processes:
___________________________________
___________________________________
3.
(a)Name of the Institution:

___________________________________
(b)Automated System:
___________________________________
(c)Modules/Processes:
___________________________________
___________________________________

TASK SHEET 2 71
Considering the Institutions in your Task Sheet1, identify 2 other systems or
processes in each of these institution that are still operating manually. If you
are to suggest an automated system to the owner and management of
the institution:
(1) What will you prefer to suggest to be done with the acquisition, In-
sourcing or Outsourcing?
_________________________
(2) What are the advantages and dis-advantages of your suggest
acquisition?
Advantages:

________________________________________________________________________
Disadvantages:
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

TASK SHEET 3 72
What is the importance of a Request for Proposal (RFP)?
________________________________________________________________________
________________________________________________________________________
____________________________________________
Using the suggested acquisitions in Task Sheet 2, discuss the elements of an
RFP.
1.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
3.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
4.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
5.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
6.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
73
7.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
8.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
9.
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

74
MASTERY TEST
Identification - Write your answers on the space provided before each
number.
_______________________1. In systems development, these refer to
statements that identify the essential needs of a system in order for it to
have value and utility.
_______________________2. What phase in Requirement Life Cycle where
there is no transformation of the requirements, but simple classification and
categorization are executed.
_______________________3. It refers to a type of User Requirement that
describes what the system should do.
_______________________4. It is a document that refers to the official
statement of what is required by the system developer.
_______________________5. A modelling tool that describes the proposed
functionality of the new system.
_______________________6. A modelling tool that shows a set of objects and
the messages sent and received by those objects.
_______________________7. A modelling tool that illustrates the procedural
flow of actions that are part of a larger activity.
_______________________8. In systems development, it refers to the process
of evaluating a system with the intent to find whether it satisfies the
specified requirement or not.
_______________________9. It is composed of series of activities which are
essential for accomplishing project objectives or targets.
_______________________10. It refers to someone who can influence the
success and failure of the project.
_______________________11. An acquisition where an organization delegates
a portion of its business process to a third party.
_______________________12. It refers to the fundamental organization of a
system embodied in its components, their relationships to each other and
to the environment and the principles guiding its design and evolution.
_______________________13. It is the fundamental and unifying system
structure defined in terms of system elements, interfaces, processes,
constraints and behaviors. 75
_______________________14. A member of the team that is responsible for
designing and building a system.
_______________________15. It is a type of approach to System Architecting
that is effective when the requirements are well defined and remain
essentially constant during the system development.
_______________________16. It refers to another approach in System
Architecting that is emerging with roots in software systems engineering.
_______________________17. A model that is needed in order to analyze the
behavior of the architecture and evaluate the performance
characteristics.
_______________________18. In Architecture Development Process, where
the Measures of Performance (MOP) and Measures of Effectiveness (MOE)
are obtained.
_______________________19. It is an Architecture Development Process
where the static representatives of the functional and physical
architectures are obtained.
_______________________20. An element of RFP that provides a short
description of the organization’s mission projects.
_______________________21. It describes who will be using the project
deliverables and how large that audience is.
_______________________22. It identifies the programmatic goals of the
project.
23. It is a mechanism for managing and continuously improving care
processes to achieve maximum customer satisfaction and at the lowest
overall cost to the organization.
_______________________24. A characteristic of a Quality System that refers
to the ease with which an interface can be created with another
information system and can be changed.
_______________________25. It refers to the ease with which the information
system can be adapted to new requirements of the user, to the changing
external environment, or in order to correct faults.

UNIT 2
LESSON 1
Integration and Development
Learning Outcomes
At the end of the lesson, you should be able to:
• Differentiate between build and buy in software and hardware
acquisition.
• Explain the advantages and drawbacks of building and buying.
• Differentiate between in-sourcing and out-sourcing for the
acquisition of IT services, including support.
• Explain the advantages and drawbacks of in-sourcing and out-
sourcing.
• Explain the importance of testing, evaluation and benchmarking in
any IT sourcing decision.
• Explain the primary components in an RFP (Request for Proposal).
• Explain the advantages and drawbacks of using RFPs in an IT
sourcing decision.
• Explain the elements in a well-structured contract.
• Explain the importance of a well-structured contract in any IT
sourcing decision.
• Given an RFP, recommend and justify one or more products that
satisfy the criteria of the RFP.

PRETEST
________
________
________
________
________
________
________

77

2.1.1 Components, Interfaces, and Integration

2.1.2 Infrastructure, Middleware and Platforms

2.1.3 Techniques:
Data warehouses, Extending Frameworks,
Wrappers, Glue, Facades
2.1.4 Testing/Evaluation/Benchmarking

2.1.5 System Release:

Pilot and Acceptance Testing and Defect
Repair
2.1.6 System Support Strategies and User Support Plans

2.1.7 Enterprise Integration Approaches, Standards, and Best

Practices

78

MASTERY TEST
________
________
________
________
________
________
TASK SHEET 1
________
________
________
________

TASK SHEET 2
________
________
________
________

79
LESSON 2
Project Management
Learning Outcomes
At the end of the lesson, you should be able to:
• Explain the key components of a project plan.
• Explain the importance of a cost/benefit analysis to the successful
implementation of a project plan.
• Explain roles and responsibilities for key project personnel and
stakeholders.
• Use appropriate project planning and tracking and tracking tools.
• Discuss the issues involved in creating a project schedule.
• Explain how to identify the lessons learned in a project closeout and
review session.

PRETEST
________
________
________
________
________
________
________

2.2.1 Cost Benefit Analysis

2.2.2 Roles, Responsibilities, Accountability

2.2.3 Finance, Estimation, Budgeting

2.2.4 Planning
80
2.2.5 Risk Management
2.2.6 Scheduling

2.2.7Tracking

2.2.8 Lessons Learned

MASTERY TEST
________
________
________
________
________
________
TASK SHEET 1
________
________
________
________

TASK SHEET 2
________ 81
REFERENCES
https://www.enlightened.com/wp-content/uploads/2017/10/ENL-Build-vs-
Buy-White-Paper.pdf
http://ksuweb.kennesaw.edu/~svandev/AcqLfeCycle.pdf
https://www.tutorialspoint.com/software_testing/software_testing_tutorial.
pdf
https://muele.mak.ac.ug/course/view.php?id=1563
https://opentextbc.ca/projectmanagement/chapter/chapter-3-the-
project-life-cycle-phases-project-management/
https://www.nibusinessinfo.co.uk/content/advantages-and-
disadvantages-outsourcing
https://fourcornerstone.com/middleware-advantages-disadvantages/
http://www.cems.uwe.ac.uk/~kg-doyle/tdrewry/modeling.htm
https://www.slideshare.net/koko3159/modeling-system-requirement
https://www.slideshare.net/meenakshi24/11-system-development-models
*https://www.tutorialspoint.com/software_testing_dictionary/system_testin
g.htm
https://blog.careerminds.com/insource-vs-outsource
https://qualityandinnovation.com/2008/10/18/quality-system/
https://www.tmap.net/wiki/quality-characteristics

82

APPENDICES
A. ANSWERS to PRETESTS
• UNIT 1
 1. REQUIREMENTS
2. ORGANIZATION PHASE
3. FUNCTIONAL REQUIREMENTS
4. SOFTWARE REQUIREMENTS
5. USE CASE MODEL
6. SEQUENCE DIAGRAM
7. ACTIVITY DIAGRAM
8. TESTING
9. PROJECT LIFE CYCLE
10. STAKEHOLDER

83
B. APPROVED SYLLABUS
84
85
About the Authors:
JP A. Tillo is a BSIT graduate at JH Cerilles State College –
CMSE Campus, Lakewood, Zamboanga del Sur. Currently
he is an I-1 faculty member of JHCSC- CMSE Campus,
Lakewood and is handling classes both in Bayog Offsite
Class and Lakewood Campus. He is pursuing his Master’s
Degree in Information Technology in Liceo de Cagayan
University, Cagayan de Oro City.

Louejay B. Seguerra is graduate of Bachelor of Science in Information

Technology at Saint Columban College, Pagadian City. Currently he
is an I-1 faculty member of JHCSC- Lakewood Campus and is handling
classes both in Pagadian Annex and Lakewood Campus. He is
pursuing his Master’s Degree in Information Technology in Liceo de
Cagayan University, Cagayan de Oro City.